# WebSocket connection closures or remember that networks are unreliable

Networks are unreliable. Put more precisely, TCP networking can experience many different types of failures with resulting loss of connectivity. Do not let the linked post’s title fool you, it goes on to list a number of real-world computer networking failures. HTTP is a great way to communicate over the public internet, where failures may occur at any time, because the protocol itself is stateless and does not rely on a persistent connection. HTML5 WebSockets, however, do use a persistent TCP connection. A connection that can cut or closed without warning. Today’s post is a short commentary on adding error handlers and heartbeat messaging to WebSocket clients and servers.

# Why log?

It is a good practice to add logging capabilities to applications as they are built. There are a lot of good tutorials on how to setup logging within various applications and software frameworks. It is also instructive to discuss why something is a good practice since understanding why can lead to new insight in how, when, and where to apply said ‘thing.’ The point of today’s post is to discuss some scenarios for why application logging is important. This post will be mostly non-technical because the how of logging can be learned with some decent web searches and there is already a wealth of information on logging software on the web.

# DNS Round Robin Failures

Round robin DNS records are a technique for distributing load across public facing web servers. As an experiment we tried using them in order to distribute load inside of a cluster. We found this approach didn’t work. In this post I’ll discuss round robin load balancing, how it works at a high level, what we did with DNS, why it didn’t work, and what can be done instead.

# Class hierarchy design

For the love of all that is dear to software development avoid parallel but separate class hierarchies.

Today we’re going to talk a little bit about type hierarchy design and why composition is useful to consider in certain scenarios.

# NodeJS counter implementation

Performance counters can be implemented in applications to help operators determine where bottlenecks are in the design. Microsoft has a decent page, that’s somewhat Windows centric, about performance counters. This post is about implementing the most basic type of counter, a value which monotonically increases, in JavaScript for NodeJS and the performance implications of different designs.

# Building it wrong and wronger

A 1st generation software product will likely miss the mark. It might have missed being that best that it could be by costing too much, being too complex, or just not targeting the right market. In any case, a 1st product may lead to another, 2nd, product that is cheaper, simpler, or just hits the right notes with the intended customer. Today’s post is about building the wrong product (the 1st one) in the right way so that the 2nd product can be built better, faster.

# NodeJS modules should export object constructors

Note I didn’t say always should export objects, but for the sanity of everyone involved, in many cases a required module should return a constructor and not a fully instantiated object. Today’s post is about why your NodeJS modules should look like this:

/**
* @constructor
*/
function myConstructor(someDependency) {
//setup my object here
}
module.exports = myConstructor;


and not this:

var myObj = {
myService: new MyService()
};
myObj.myFunction = function(foo) { //do stuff with foo here };
module.exports = myObj;


# Logging and Monitoring

Operational monitoring of a software application is one of the activities the ensures a successful public launch. Too often it seems like a service’s course to public availability looks something like, Conceptualization → Development → … → SHIP IT. The “…” component is an important step at large enterprises with large public services (like Expedia, Amazon.com, etc) and involves developing a way to monitor an application whilst running it. At smaller organizations though I have seen this smaller step get discarded or not looked at. Today’s post offers a few thoughts on what logging and monitoring looks like today.

# SRV records as service locators

Recently I began work on a project to manage the deployment of a product built using a [microservices][1] architecture. As a result of our chosen architecture we have a large number of services which will communicate to each other over HTTP/S. Instead of using fixed IPs we decided to used [DNS SRV][2] records to indicate where services could contact their dependencies. Today’s post goes into using SRV records in a little more detail and the problem they solve.