Posted on
by

Opinion: If you embark on building a major project without implementing some sort of automated testing/regression testing framework along side then you are a fool.

What?

Regression testing is nothing more than a set of automated tests that are written to test certain parts of your code. Tests can be written to test core bits of functionality, or be written to replicate certain bugs.

Crucially, these tests are run automatically – perhaps daily or on code commit – and make sure that core functionality remains functional as your development moves forward, and that known bugs don’t re-surface.

There are numerous test suits out there, but in all honesty you don’t have to be fancy. In my projects I often find myself reusing a test suite I initially put together in an afternoon (and have improved on ever since) and which is far from the most sophisticated bit of software ever written (although it is nonetheless exceedingly powerful if I do say so myself!).

Why?

Primarily, this sort of testing gives you confidence in the code you write.

It requires a little discipline from your team – namely that you write a test as part of your development process as you build out new features or squish bugs – but this actually fits quite nicely into the development workflow (afterall, you have to test your code somehow).

However, once you’ve got into the habit of doing it you can then rest easy to know that a new feature hasn’t silently broken something you wrote ages ago, or that a nasty bug hasn’t resurfaced.

In other words, your code is provably correct – this saves you time, as well as saving you the embarrassment and cost of inconveniencing paying customers.

Tests are also (quickly) repeatable, systematic and deterministic.. unlike the standard “run once and click a few buttons” method of testing adopted by many software developers out there.

An Example

Here’s a personal example of the ass-saving power of having a regression testing framework in place..

A couple of weeks ago I was deep in Latakoo’s server infrastructure making all kinds of performance optimisations to the page loading and database handling code. To get some more data as to where some of the bottlenecks were I performed extensive profiling (more on that later) and added sections of debug to collect statistics on various parts of the system.

All good stuff.

However, one apparently minor change I made had an unexpected and not immediately visible effect of completely breaking the Latakoo API. This API is what all the clients use to get video into our infrastructure, and so had this code change made it through to our production servers it would have prevented anyone from using our service and have cost the company untold $ in lost revenue.

The performance of the API is something that is naturally tested by the regression testing framework, and no sooner had I applied the patch on our test server than I received an email telling me that I had broken the API.

A quick fix later and a potentially costly and embarrassing show stopper of a bug was caught and fixed before anyone else knew it existed.

The moral of the story…

Bugs happen. Software development is hard and even the best of us make honking mistakes from time to time. What matters is that you acknowledge this and have the necessary early warning systems in place to prevent them becoming a serious problem.

All it requires is a little discipline and this is what grown-ups do.

So write those damn tests already!

Posted on
by

It is the little differences between the US and the UK that really interest me.

I was out in Berkeley visiting a friend, it was late and we were sharing a few beers in his apartment before we retired.

On thing I notice is that Americans, contrasted with much of the rest of the world, seem to have much more faith in technology than most. I’m not sure what it is, perhaps just a symptom of the infectious American optimism and the idea that all technology is fundamentally a positive and infallible force.

Perhaps it was the beer.

Anyway,  in a moment of inspiration I realised this sort of bathroom lock (pictured) – which I’ve not seen anywhere outside of America – may be the perfect example of this sort of optimistic faith in technology.

When in the bathroom, you push the central button in order to lock the door from the outside. A twist of the handle springs the lock and opens the door.

What was interesting to me was that there was no feedback as to whether the lock was actually engaged. You pushed the button, and that was it.

There is no way to test it since twisting the handle would automatically disengage the lock. In other words, you had to trust that the mechanism was working as it should… which to my European software engineer’s mind left me with nagging doubts as to whether or not I would be interrupted while in the middle of something, so to speak.

This is to my mind a very good example of how an attempt to create a simple interface unintentionally creates a poor user experience.

Perhaps its just a cultural difference (which is nonetheless an important consideration), but I think many would find feedback comforting in this sort of situation.

Posted on
by

Apple Airprint is a technology (a zeroconf implementation under the bonnet) which allows apple devices to detect, configure and print without any overt configuration on the part of the user.

The bad news is that in only works for a handful of airprint printers natively. But never fear, Linux to the rescue!

At this point I’m going to assume that you have a Linux box somewhere on your network acting as a file and print server (pretty regular kit in most geek homes).

Set up your printer

The first step is to set up CUPS on your linux server and then installing the appropriate printer driver for your printer.

I won’t go into detail here as there are numerous guides out there on the wider web, but mostly this is a matter of installing cups and foomatic and then visiting the cups configuration website on the server (localhost:631 usually) and adding your printer.

Make sure that the printer is shared. Print a test page.

One gotcha I found is that my default configuration only allowed connections from the local machine, even though the printer was marked as shared (although frankly I was cheating since most of my computers printed to my server over a Samba relay, but that’s by the by).

Take a look at /etc/cups/cupsd.conf and make sure that has an Allow From from your local network. E.g.


<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 192.168.0.0/24
</Location>

Export the printer

The next step is to install the zeroconf demon, which is called Avahi. This varies from system to system, but on debian this is pretty much a matter of apt-getting avahi-daemon. You may also want avahi-discover so you can browse the exported devices on your network.

Assuming you’ve correctly set up and shared your printers in CUPS the next step is to generate an avahi configuration for it. Thankfully, there’s a handy Python script called airprint-generate, available on github which does much of the donkey work.

Copy the resultant file to /etc/avahi/services and restart the avahi demon.

If your printer is password protected, you will want to add a <txt-record>air=username,password</txt-record> field to the file before doing so. Where username and password is the literal cleartext strings sent.

Profit!!!

Theoretically that should be it. After the configuration, and restarting the various demons involved your printer should be available to the various iOS devices kicking around your network.

Let me know if you have any questions!

Update for IOS6 users

If you are using IOS6 and are seeing a “no airprint printers found” when you try and print (even when ios5 devices can print fine), you must make a small configuration change to CUPS.

Create two extra files in /usr/share/cups/mime:

airprint.types

image/urf urf string(0,UNIRAST<00>)

airprint.convs

image/urf application/pdf 100 pdftoraster

Then restart CUPS before regenerating the avahi configuration file for your printer using airprint-generate as documented in the steps above. Replace your existing avahi printer configuration with this new one and restart avahi.

You printer should now be visible again to both ios5 and ios6 devices via airprint.