Microservice architecture is becoming an increasingly popular choice among platform architects, and for good reason: when implemented correctly, it can increase team velocity, facilitate technological diversity, and enforce good abstractions. However, writing good tests for a microservice-based platform is often a tough task, due to the complexity of the interactions between services and of the system as a whole.
In this talk, Justin will present an introduction to microservice architecture, as well as an overview of the various types of automated test suites and their place in conventional application development. He will then discuss the role of each type of test in the context of microservice-based systems, and will close with a number of recommendations for writing efficient and effective tests. Along the way, Justin will highlight various JavaScript tools that are helpful when writing tests for Node.js applications and microservices.
Here are the slides from my talk (also available on SpeakerDeck):
]]>Here’s a recording of the talk:
]]>My talk was about the lessons we learned from implementing NPR.org’s new in-page audio player using React and Redux, as well as the general strategies we developed for using these technologies in the context of a legacy frontend stack.
Here are the slides from my presentation:
]]>Ultimately, while these tools can be quite helpful in ensuring that the code in question works as expected, there’s no better way of verifying that code is readable and maintainable than getting it in front of other developers (that may someday be charged with its maintenance!) for feedback. Code reviews provide a number of benefits to teams; in addition to helping to find and fix bugs before they make their way into production, they allow developers to learn more about systems they might not be directly working on, and serve as jumping-off points for discussions about best practices that might otherwise never transpire.
If you’re thinking about instituting code reviews as part of your team’s processes, here are some points to consider:
I’ve actually found code reviews to be so helpful in improving my ability to critique and write clean code that I’ve incorporated them informally into my own coding practices. Rather than waiting for “official” team code reviews to take a good look at whatever I’ve written, whenever I’m about to commit or push code, I take a few moments to review what I’ve done to make sure that everything is as it should be. It’s amazing how many errors I’ve caught by doing this, even when I’m writing a tiny amount of code or am sure that I got it right the first time. It also requires very little effort; I’ve aliased ‘gdx’ to ‘git diff | gitx‘, which means that a nice visual diff of the changes I’m about to commit is only 4 keystrokes away. At this point, quickly reviewing my code prior to committing feels as natural as proofreading email prior to sending, and the return on investment is absolutely worthwhile.
]]>To that end, today I present to you Move It!, which is a simple puzzle game I wrote in 2008 to teach myself Actionscript 3. I still think that the gameplay is strangely innovative and addictive, and one of these days I’d like to port it to iOS. The trickiest part of that venture, I think, would be in making key UI decisions; what’s the best way to map arrow keys to touch controls? Directional swipes? Virtual buttons? Simply tapping the square you want to move to?
When I set out to build the game, a good friend of mine gave me some great advice, saying that the quality of the game would depend a great deal on the quality of the levels, and as such, building an intuitive, easy-to-use level editor would be key to its success. His words were prescient; the PHP/MySQL/Flash level editor that I built to accompany the game saw a great deal of use, and a lot of the best levels were actually created by my friends. If I do rebuild it for iOS at some point, I’d almost certainly recreate a good level-editor interface to support it. (Contact me if, for some godforsaken reason, you want access to the editor.)
You can find the full source code (to both the game and the editor) on GitHub.
]]>