Following on from my previous post about logging this one will go a bit deeper into the logging story. There's a fine line between too much and too little when it comes to logging. On the one hand you don't want to skip logging something that might make it easier to diagnose a problem later one and on the other hand you don't want to create so many verbose log entries that you just can't find the information you need.

If there was going to be a "silver bullet" that will make your applications more supportable I think I would suggest that appropriate logging would be it. There are obviously a lot of other things you can do to make applications easier to support, monitor, debug and develop - but without logging you're shooting yourself in the foot before you even start.

Once an application is running in a production environment it can become more complicated to access the systems the application is running on. For example that the web servers might be running in a DMZ where the developers don't have access to easily view logs (though this shouldn't be the case if you read the previous article about log management). Another example is when you have a website or application which has down-stream system dependencies such as APIs or back-end database systems, and you want to know if these systems are healthy to determine the health of your own application.

Working in a large company where we do most of our own software development in-house we have a wide range of coding practices and various levels of supportability. For example, much of the older code doesn't make use of any IOC and this is fair enough, it was written in the days of ASP.NET web forms, or windows forms, dependency injection wasn't a common practice a few years ago, and unit testing wasn't much of a consideration at the time either.

Isolating performance issues or tracing web traffic problems can be a challenge. Modern browsers have excellent developer tools and 3rd party tools like Fiddler are also great for this job, but they only give you so much information. Sometimes you want to get more in-depth information around the request processing times, or the configuration variables on the server.

Throughout the month of November 2013 I spent three weekends at three different Salsa and Latin competitions running the SerenityOne scoring system.

I've now been working on and developing my SerenityOne Dance Competition Scoring Software for a number of years. It has grown from a concept simply to help speed up the data entry and remove the chances of human error, to a fully automated tablet-based system. From a simple WinForms app with hand-written score sheets, through a number of iterations and rewrites to a server-based system relying upon ServiceStack for REST and Serialization coupled with a Xamarin.Android application running on a fleet of up to ten 9" Android tablets.

I recently tried to upgrade my ProxMark III to the latest CDC firmware to try out some of the new features. In the process I somehow managed to brick it into a boot loop whereby it would just hardware reset ever 2-3 seconds.

There are some other instructions around on the net (see references below) on how to do this using a bus pirate also, and some of the instructions on the proxmark website explain how to flash the s19 files. I found that the s19 firmware files didn't work for me, but if I followed the bus pirate instructions using the Olimex OpenOCD instead, everything worked nicely.

In both my professional life, and through using open source projects I've come across what I think are some really simple code quality practices that anyone can follow. I wrote these down one day in a moment of frustration after previously fixing a build at work so that it had no "warnings" in the build, only to discover about 3 months later that other team members didn't see the 130+ yellow warnings on their visual studio errors pane. (The cool thing with visual studio is that of course you can untick the box and never see warnings... it's bliss, you never need to see the mess! It's the IDE equivalent of dust under the mat)

So I've been thinking, every time I run the scoring for a dance competition my conscience is destroyed by the fact that I have to print so many judging marksheets out. For example, if there are 6 judges, with 20 competitors that's 120 bits of paper… 20 competitors is quite small for a salsa competition, and some of the competitions I've been doing recently have 8-10 judges. So it quickly blows out to 100's of pages.