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.

For the last few months I have been working on a UAV project with three other guys - the project is called "Project Andromeda" and the goal is to design and manufacture a small UAV suitable for low-cost civilian aerial operations such as search and rescue, mapping and aerial survey. The project has been underway for 2-3 years now, and it is nearing the stage of commercialization.

I have a couple of ideas for projects that could be done on the Netduino. I initially heard about these devices through Scott Hansleman's podcast a few months ago. More recently I came up with a few ideas that could leverage the small form factor, with the wireless Xbee networking options. Having now actually SEEN a Netduino device, I realise they are HEAPS smaller than I imagined. The possibilities are endless, and I've started formulating a plan of action to develop these things into something useful. Some ideas I have for open source libraries in .NET: