In v3.6 MongoDB rolled out Change Streams, which allow you to easily subscribe to all data changes on a collection, database, or entire deployment. This tutorial is an adaption of a tutorial put out by the good folks at Pusher.com. In fact, it uses the exact same front-end React app (because my purposes is exploring the backend implementation). The idea is to create a simple TODO list application that recieves real-time updates via Pusher web-sockets.

I recently decided to pick up Clean Code by Rober C. Martin (a.k.a Uncle Bob). This is one of those seminal books in software development all devs are encouraged to read. As one of the top selling books on software development since it was published in 2009, there are no shortage of reviews. So I don’t think there’s anything I can add there. I will just say that I enjoyed it and you should read it.

One of the design patterns that we’ve been using throughout the New Visions’ Data Portal API is modeled after Rails’ Active Record Callbacks. The basic idea is that when instances of a given model are created, updated, deleted, etc. you have these hooks that allow you to take additional actions: Active Record callbacks allow you to attach code to certain events in the life-cycle of your models. This enables you to add behavior to your models by transparently executing code when those events occur

In Clean Code, Robert C. Martin (a.k.a Uncle Bob), devotes a short chapter to what he calls “boundaries”, which are the places in your code that directly interact with third-party code like APIs, packages, or libraries that you do not have control over. Two key ways to keep your boundaries clean, according to the chapter, are to: limit the amount of your code that interacts directly with this foreign code, and write tests that confirm it works the way you expect it too By encapsulating third-party packages in your own well-tested classes, you can be alerted to any breaking changes caused by package upgrades early and limit the amount of code you need to refactor to get things working again if they have broken.

Developers are supposed to have blogs, so here’s mine. I hope to post on everything from software architecture and coding problems/solutions to devOps strategy and infrastructure to team organization and management. I’ll also include my thoughts on books I’ve read and whatever else comes to mind. About this site I’m not a designer and I’m not really a frontend developer. I have a fair bit of experience with AngularJS, but I’ve always leveraged frameworks like Bootstrap or Angular Material to do the heavy lifting around design/styling/layout.