agination is a recurring problem that developers have to deal with when implementing data access layers for APIs. It can be particularly tricky with the more traditional RDMS like MySQL or Postgresql. For example, let's say we had an API endpoint that allowed consumers to search a data base of moves. We could search by title, director, starring actors, etc. Our data base has millions of movies, and we know we don't want to return all all the potential matches for every search request.

We only want to return the top 25 or so records and indicate in the response that there are more results to query for:

{
  meta: {
    total: 12000
  , limit: 25
  , next: <URL TO NEXT PAGE&

orking with timers a distributed system is a really nasty problem that pops up more often than most people would like. Something as simple an useful as setTimeout / clearTimeout becomes brittle, unreliable and a bottle neck in today's stateless, scalable server mindset. Basically, I need to be able to set a timer somewhere in a cluster with out knowing or caring about what server. And reversely, I need to be able to cancel that timer **without** having to know where in the cluster that timer lives. But before we can start to understand possible solutions, let's dive into a use case to understand the problem and why existing solutions aren't suitable replacements.

Scenarios

Un-send an email  - A simple

ver the years I have had a handful of times where I have had the need for Multicasting. It usually comes about in service or node ( application ) discovery. Or if you are lucky enough, the dreaded distributed setTimeout / clearTimeout. Every time find a need for it, I spend hours in the documentation trying to remember how to use it, remembering the Node.js Docs for dgram - which are virtually void of any useful explanation or examples. Finally resorting to finding googling around for the 1 or two examples of multi casting out there and hack something together. It shouldn't like that. It is actually really easy to do with Node.js. Let's give it a shot.

Let's say

eroMQ has its fair share of quirks and oddities. It manages everything in a global state, requires things be manually grouped into `Contexts`, allocates a thread per context (making it not thread-save) , transports are baked into the library, and so on. It can be a bit clunky to work with at times. As a result, one of the original developers on the ZMQ project, Martin Sustrik, started a new project that evolved into a complete re-write / re-realization of the ZMQ project, called nanomsg.

Nanomsg aims to resolve many of the underlying short comings of the zeromq library, but remain compliant with the ZMTP spec. It provides many of the messaging patterns ( which are refereed to as scalability patterns ) as

omains have been the red-headed step child of error handling in Node.js It is a library that has been deprecated since v0.12 and has been awaiting a suitable replacement ever since ( we are at v6.5 at the time of writing ). Until one has been implemented by the Node Core team, it is still de-facto way to deal with error propagation. As Node.js supports more and more ES6 features, I have been upgrading my open source projects where it seem appropriate. In my command line tool package, seeli, I was doing some updates and came across some exceptionally odd behavior around ES6 Promises and implicit Domain binding. In a nutshell - It's broke.

Monkey Patch (ˈməNGkē

IT has been my SCM tool of choice for white a number of years. Along with it, VIM has always been my intermediate editor for doing commit messages, viewing diffs and resolving merge conflicts. Recently, I have made the switch to Neovim as modern replacement for VIM. The nice thing with vim is that it came with a number of handy aliases, such as vimdiff. Which was unfortunate, because I really liked VIM's diff support for GIT. I wanted to replicate that, but that would require some manual work on my part to get the two to play nice. Luckily, it isn't really that hard - turns out you can define any custom diff / merge tool for GIT. Here

ne of the more tricky and debated topics in API circles is how to handle relational data. How deep into your data tree should it go, how to accept it from the client and how much to return to the client. One could choose to treat each resource as a silo and force the client to individually create each object and piece all of the relations together. However, that is not a great user experience. It also leads to a very large number of requests and data transfer, which has been a blemish on the idea of a REST API for a while. The emergence of modern mobile devices which limited bandwidth and performance profiles need a more streamlined

icroservices are becoming the de-facto way of building out large applications. If you haven't worked on a project that has migrated monoliths to micro-services, you are most likely working on a microservice of some flavor or another. And as you might imagine, Docker containers are the preferred way of delivering these services. Managing all of these containers and services is no easy task and has lead to the rise of private PAaS projects, operating systems, and orchestration framewoks like Deis, Mesos, Kubernetes - A new one is popping up every month.

Choosing a framework, or a stack is, in it of itself, no simple task.  Personally, I have been following CoreOS, both the company and the operating system as

ne of the major components of a tastypie resource is the data preparation cycle, or hydration cycle. The hydration cycle is the aspect of a resource that is responsible for massaging raw user input into data objects suitable for saving to a data source, and vice versa.

The hydration cycle also encompasses the serialization machinery of the resource which is responsible for converting data object into standard data formats ( JSON, xml, etc ) and vice versa.

Serializtion Cycle

Each Tastypie resource has a Serializer instance which it uses internally to convert data between well formatted string and javascript objects. This behavior is defined in the serialize and deserialize resource methods A serializer class defines how
data is converted to and

cess control is apart of virtually every application. Certain users should be able to see / do X, but never be able to do Y. Usually these kind of requirements are expressed in overly simple terms, such as:

Admin users should see that button but regular users should not.

--Every Product Manager. Ever

With traditional RDBM Systems, the direct approach is to set up a Many-To-Many relation ship between Users and Roles Where roles are basically like tags. Subsequently code paths are created to check if a user has a role named admin . Which gets very ugly as these sorts of simple checks quickly have to cover increasingly complex logic for users with multiple roles and for roles that