Skip to main content

Posts

Showing posts from May, 2016

Your Job Isn't to Write Code

Solving problems is the role of software developers first and foremost. The most interesting aspect is that in many cases it is possible to perform this role without writing a single line of code.Low TechI once worked with a digital dashboard which monitored applications. One of the yet to be implemented features was a key to highlight which each chart related to. During this period many employees would ask which graph related to which feature. The solution was a few weeks a way so as a temporary fix I stuck a post it note to the screen. This was by no means the solution, but it was good enough for the time being. The questions went away and eventually the dash was updated to include a digital version. Total lines of code? Zero.Problem Solving without a ComputerA common experience that many developers encounter is solving a problem while not actually at the computer, programming. In fact this technique of simply taking a break such as going for a walk can yield some impressive results…

Foreign Key Constraints and Microservices

Database constraints when used in relational databases are great. They ensure data integrity at the lowest level. No one would argue against using them in practice. Essentially constraints can be thought of as assertions against your database. Rules such as requirement, default values and foreign key constraints double check your use of the database. This ensures your application is interacting in a sane manner. Databases often out live applications therefore constraints also ensure integrity long after the application has been replaced or modified.Distributed SystemsDistributed systems change how foreign key constraints should be considered. As distributed systems own their data, each piece of data that is mastered by a single service should ensure integrity via foreign key constraints. However outside of this boundary the use of foreign keys should be avoided. This sounds disturbing at first. Especially given the traditional approach of a single system backed by a single database.E…

Past Mistakes - Out of Process Commands

Some of the best lessons you can learn are from failure. I figured a series on mistakes I've made in the past would highlight where I went wrong and more importantly what to remember going forward. These real life examples vary from my early days of programming all the way up until present day.I once wrote a feature that sent email to users on their behalf. On localhost this was fine. Fast, stable and good enough to get the job done.Despite early successes, under load in a live environment, things were different. Sometimes the process would out right fail, requiring the user to retry. Other times it would be slow to process. This meant the users browser would hang while the email was being sent.It was hard to replicate these problems. The actual code itself was pretty simple, there was nothing to optimize it seemed.MistakesThe core mistake was performing an operation out of process from within the life cycle of a HTTP request.When sending the email was slow, the HTTP response was …

You Rarely Need Custom Exceptions

Implementing custom exceptions usually gives a hint as to why you rarely need custom implementations. They are often nothing more than sub classes where the only difference is the type name and containing message.In this C# example there is a lot of code for nothing. When checking logs or handling bugs you will read the message and the stack trace. The first line containing a bespoke name rarely matters. Within the code throwing the exception very little context is gained from the type of exception - instead most of the details will be present within the error message.Each custom exception you introduce adds overhead from source lines of code (SLOC) to compilation and execution.AlternativeSimply do not create custom exceptions except in the rarest of occasions. Instead rely on the standard library of the language you are using. Take Python as an example [Video]. ~200,000 lines of code yet only ~165 exceptions. This works out at about one exception for ~1200 lines of code.If battle har…