Testing microservices in node.js

I gave this talk about testing microservices using node at RVA.js on November 2nd, 2018. Here’s the description from the conference program:

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):

Microservices in node.js: practices, pitfalls, and prevention

I gave this talk at NationJS 2017. It consists of an introduction to microservice architecture, a discussion of techniques for effectively building microservices in node.js, and some guidelines for avoiding some of the common problems and mistakes that teams make when they first decide to make the plunge.

Here’s a recording of the talk:

Modernizing legacy codebases with Redux

I had the opportunity to speak at ReactNL 2016, which was a very fun conference; I wrote about it at length on npr.codes.

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:

Commit to review, review to commit

As software developers, we strive to write code that’s readable, maintainable, logical, and functional. While this can be a daunting task, there are tools and processes that make it easier to achieve these goals: version control systems facilitate code and feature management; IDEs help us find and fix syntactic and semantic errors, even when using dynamic languagestesting frameworks help us prove to ourselves that our code actually does what we expect it to; and continuous integration helps us automate the creation of builds and the deployment of our finished product.

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:

  • Use tools to make it easier. Chances are pretty good that whatever version control system in use by your team supports some way of reviewing code. At NPR, we use Crucible to create, comment on, and moderate code under review, and GitHub provides great tooling for reviewing pull requests.
  • Reviewing code thoughtfully takes time. It’s easy to spend 5 or 10 minutes looking at a chunk of code and leaving superficial comments questioning variable names or codesmithing conditional blocks into ternary expressions, but it generally takes a bit longer to understand the greater structure of a new feature or system well enough to give constructive feedback. Our dev team dedicates one day per 2-week scrum cycle to code reviews, and everyone from product to design understands its importance and gives us the time to make sure it’s done right. (N.B. I don’t mean to imply that variable names and coding in the small shouldn’t be discussed as part of code reviews, as such considerations are also critical to readability and style.)
  • Choose review material carefully. It’s very possibly the case that your team writes more code in a cycle than can reasonably be reviewed. As such, it’s important to use your code review budget judiciously when deciding what code merits review and what does not. (Ideally, no code would make it to production without being reviewed, but depending on your team’s size and resources, that may not be practical.) There’s no hard-and-fast rule about what code should be reviewed, but work that falls in to any of the following categories is probably a good candidate:
    • The creation of a new feature
    • A large-scale refactoring of an existing feature
    • Code written by developers new to the team
    • Code for systems with which most of the team is unfamiliar (this may be more about knowledge-sharing than the quality of the work under review, which is fine)
  • When appropriate, make time for design reviews. Before embarking on the construction of a new major feature or system, it’s appropriate for the dev or project team doing the work to put together a high-level design document outlining their intended technical approach. This doesn’t have to be hugely elaborate — as little as a few paragraphs, and possibly a diagram or two, may suffice — but it’s very helpful as a sanity check. It’s terrible to find out in the context of a code review that you’ve wasted a week by taking a completely backwards approach to whatever you’ve been working on, and design reviews help in avoiding such situations by validating the overall plan before a single line of code is written.
  • Code reviews > no code reviews. Don’t let the perfect be the enemy of the good. If your current workflow doesn’t include any sort of code reviews, find some way, no matter how small, to let your developers review each others’ work. The benefits of establishing a shared sense of ownership and understanding of the finished product far outweigh whatever process or tooling-related considerations might be holding you back.

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.

Side project memory lane, part 1: move It!

It’s only by looking into the past that we’re able to measure just how far we’ve come, and it’s in that spirit that I’m going to be posting a series of personal projects that I’ve worked on over the years. I’ll try to provide a (mostly) working link for each, as well as a copy of the source code on Github. The only guarantees I can make regarding the quality of the projects and the code is that they will be uniformly non-uniform, occasionally entertaining, and generally downright awful (or at least pretty dated).

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?

Screen Shot 2014-04-20 at 8.35.06 AM

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.