I enjoy running my own blog at codinginthetrenches.com because I am a technologist that likes to write. Unfortunately, sometimes my interests as a technologist get the better of my interests as a writer. This last week my competitive interests resulted in my blog being visually broken for several days. Furthermore, the competition has resulted in a few select articles being mis-formatted and visually broken for much longer than a week. Today’s post is about what I’ll be doing to avoid these problems and how they can apply to your own writing platform. ...

We often think about best practices while developing software. Sometimes it is also instructive to contemplate what not to do when writing software. Today’s post covers some logic in AngularJS services which should be avoided save for rare exceptions. ...

Developing new software involves resolving a frequently unknown quantity of problems of unknown complexity. Even when working on existing projects, new initiatives and features can contain a unknown total amount of complexity. While being appealing modern product management methods, scrum and other related methodologies focus on relative estimation which has limitations when starting brand new work. Today’s post looks at some of our limitations when it comes to estimation and what is implied by those limits. ...

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. ...

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. ...

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. ...

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. ...

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. ...

A 1stgeneration 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 1stproduct 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 1stone) in the right way so that the 2ndproduct can be built better, faster. ...

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; ...