Over the last decade I have been involved in several software projects for medical applications. This has ranged from a non-invasive diagnostic product all the way up to a full-blown life critical if-it-fails-the-patient-dies type device. As a result, I have also had some exposure to the business and regulatory environment one encounters when marketing a medical product, and have made a few observations there that I think are interesting.
In their book The Pragmatic Programmer Andrew Hunt and David Thomas discuss what they term “Software Entropy”. By this, they mean the seemingly unavoidable and ever increasing disorder and decay in a piece software. They draw a parallel with the Broken Window Theory, described as follows:
In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .
A broken window.
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment - a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
While I have some relevant experience in a bunch of programming languages (C, C++, C#, Perl, Java, Python), the majority of my time has been spent programming in C++. This has been both a blessing and a curse. C++ as a language is immensely powerful, and I absolutely love it. It allows me to choose the abstraction level I want, from dabbling in the low-level realm of bits and registers, all the way up to template based meta-programming. Some of the things I can do in C++ are unmatched in other languages. And while that is without a doubt partly due to my familiarity with the language compared to others, I cannot help but feel there is something inherently powerful about C++ that makes it possible.
There is currently much ado about the changes to Twitter’s API TOS. The short of it is that they are essentially killing off any competition to their own client apps by restricting the number of users that can use a specific app. This is leading many to huff and puff about how this is harmful to users, reducing choice and stifling innovation.
While all this is probably true, it may also be largely irrelevant. With situations such as these I am always reminded of a quote I heard quite some time ago (although I forget who said it):
If something is offered to you for free, always assume your are not the customer, but the product.
From time to time, most developers some across pieces of code that makes them go “Why on earth did you do it THAT way?!” at whoever wrote it. And it’s a dirty little secret that sometimes that thought is followed up with “Oh, it was me”. So for that reason I am not in the habit of harshly criticizing a developer I’ve never met, who wrote a piece of code the way they did for reasons I don’t know.
Still, sometimes people write stuff that makes me go “Why did you do it THAT way?!”, and last week was one of those times. I came across a piece of code that fired off two asynchronous calls at once, and then waited for both results before continuing. This was done in a Java application, and went roughly (simplified) as follows:
In my previous post I showed how I got everything working on the breadboard. Next, it was time to move the circuit over to a more permanent medium. While I considered plain old perfboard, I was also interested in the process of designing a custom PCB using a program like EagleCAD and methods for quick and cheap PCB fabrication at home.
So I took the plunge, and started learning EagleCAD. Anyone who has gone through the same process will confirm that Eagle has an pretty steep learning curve. Many things are just a little bit different from how more everyday applications work, such as how to deal with multiple objects. Also, finding the right components in the component libraries is difficult, unless you already know where everything is (this external parts search engine proved invaluable). In the end though, I managed to produce a schematic that represented the mess of wires on my protoboard in a more orderly fashion:
Inspired by several others who have done the same, I have been using several Asus routers running the MPD music server on top of OpenWRT as networked music players for some time now, both for streaming radio and for playing my own MP3 collection. So far, I was content with doing the software conversion only, and leave the routers in their original case. This meant I always needed external amplification/speakers to hear anything at all, and a remote MPD client such as the browser based PhpMp or the Android app MPDroid to control the player.
Recently, I decided I wanted to delve a little bit into the electronics side of microprocessors. I am a professional software engineer, and I usually write software that controls some kind of machine, but my area of interest normally stops at the OS level. I thought it would be interesting to broaden my horizon by diving into the electronics side of the products I work on.
Looking for an interesting project, I quickly realized that taking one of my MPD players and using it in combination with my old Logitech speaker set to build a standalone WiFi capable networked boombox would be an excellent way to learn about microcontroller electronics.