- Feature Articles
- Other Articles
Comments are rough. I always take the stance that code should always be clear enough to explain what it does, but you’ll may need a comment to explain why it does that. I recently attended a talk by Sean Griffin (maintainer of Rails) who argued that commit messages should accomplish that goal, since they can contain far more content than a code comment, and while code comments and code can drift apart and cease to be accurate, commit messages are always linked to the point-in-time when they were made. Donald Knuth, on the other hand, might argue that code should annotate comments instead of the opposite.
Regardless of the method we use, I think most of us would agree that code needs some documentation in the same way it needs tests: it should exist, but we don’t want to have to create it.
Let’s talk about maintainability.
Those of you that know me know that in my civillian identity, I work as a SQA professional. QA gets a bum rap sometimes; manual functional testing can be one of the most boring parts of software engineering, but while there’s plenty of button-pushers who will be happy to poke at an application for minimum wage, there’s a lot more to quality than simply functionality. One of the commonly overlooked aspects is maintainability: the ease with which changes can be made to the software system.
Let’s talk a little bit about front-end development. Even at its best, it’s terrible- decades of kruft mixed with standards and topped off with a pile of frameworks that do their best to turn this mess into a cohesive whole.
Jameson is suffering through this, and his suffering is the special level of front-end suffering known as “Angular”. Angular bolts Model-View-Controller semantics on top of HTML/JS/CSS, and its big selling point is that it makes two-way data-binding trivially easy.
As web developers, we spend a fair amount of time protecting our valuable server resources from the grasping tentacles of Internet ruffians and malfeasants. Occasionally, we're tasked with exposing data endpoints to the public Internet. This is generally a carefully crafted solution of whitelists, authentication, authorization, escaping input, limiting access and other protective measures.
Let’s say you have a collection of objects which contain geographic points. You want to find a specific item in that collection, and then extract the lat/lon of that item. You might write code like:
var point = userGeoPositions.Where(x => x.userId = userId); decimal lat = point.Latitude; decimal lon = point.Longitude;
If you get the rare luxury to start a new project from scratch, there's something deep down inside you that makes you want to do it right. You pick the right people, equipment and tools so that you have the best chance of success. Unfortunately, sometimes incorrect decisions are innocently made and a technical time bomb is placed in the code.
About 20 years ago at Big Money Inc., such a project was started and such a mistake was made. In this case, the mistake revolved around choosing a messaging platform that failed miserably when asked to pump more messages than was intended. The original developers knew not of this otherwise widely-known limitation.