05.20.09
Someone stole her Frosties
Pretty spectacular.
05.10.09
Paranoid code
I’ve been wrestling with some legacy Java ME code in which the author doesn’t seem to have grasped the “do or throw” pattern.
That is, a method either returns a valid object OR throws a exception. You do not need to check the return value of a method satisfying this criterion as it can never be null.
e.g:
Thread t = Thread.currentThread();
if ( t != null )
t.sleep( seconds * 1000L );
That could be simplified to just:
Thread.sleep(seconds * 1000L);
There’s something existential about code that wonders if it’s the current running thread.
OOM is dead (part 1)
When I joined Symbian in 1999, OOM (out of memory) and OOD (out of disk) testing was heavily engrained in the culture company’s as a continuation of the Psion product development activities.
Before I joined Symbian I was writing lots of Java code but had also written oodles of C code which didn’t bother to check the pointer from malloc().
My formative years at Symbian really taught me the value and skill of being able to write exception safe (and exception sensible) atomic/revertible state code. Although the particular dialect and naming scheme of Symbian’s exception handling framework (leaves, traps and the infamous clean-up stack) may not be the most popular, the general lessons learnt can be applied in any kind of software.
When writing software for an OS, it’s incredibly important to write robust code and consider every possible failure. As a pertinent example. I was assigned to fix a defect in customer’s phone in which the device sometimes failed to boot and had to be re-flashed – a problem that if happened on a consumer device may result in a costly replacement of the device at a service centre.
The bug was due to a customer modification of the phone application which was doing the following:
1. Write 80 bytes of data to a file during the shut down of the phone
2. Read 80 bytes of data from a file when the phone boots up
A very simple piece of code but the problem occurred when there was <80 bytes free. Lets say it managed to write 40 bytes.
When the device rebooted, it tried to read 80 bytes and got a Eofexception which propagated all the way up to the phone application’s constructor. Since the phone app is a critical process, the device tried to reboot in the hope that it would solve some issue.
Putting aside the inherent problems of having customers adding new code to system components. Once I found the offending code, It was pretty easy to deduce by sight that the code would fail under low disk, low memory and also fail in the case of a corrupted/zero length/missing file.
I probably spent a further hour or two fixing the code up and before releasing it, I wanted to test under low disk. I mapped the emulator’s C: drive to a USB pen drive and filled that drive with a dummy file which was just shy of the full capacity.
I then spent the rest of the day raising bugs against other components which stopped the emulator from loading in the OOD state.
Now you may ask what the value is in OOM and OOD testing now that mobile devices are packed with oodles of RAM and disk. And that’s a fair question. Aside from OOM and OOD still being a fairly common occurrence on mobile, the other answer is that is that it’s fairly easy to test OOM and OOD and code which deals with those conditions reliably is often better equipped to deal with any sort of failure.
This sort of thing is not very glamorous, but distinguishes* software engineering from hobby programming. As a core skill, exception safety and writing atom/transaction oriented code applies to anything from embedded code to the integrity of high bandwidth web back ends.
An astonishing amount of time is spent on phone projects trying to track down ‘mysterious’ unreproducible problems which turn out to be something similar to the above.
Just remember kids : Code that ‘mostly works’ is worse than code that doesn’t work at all.
*at least should
05.08.09
Search friendly APIs
Google is one of the best tools for a developer – particularly on mobile where APIs behave so erratically across devices. You can save an awful lot of time by searching for problems that other people have already encountered and solved (worked around or gave up).
I’m doing a bit of work on Java ME and Qt C++ at the moment and one thing that really struck me was how much easier it is to find example code, eratas and forum troubleshooting for Qt APIs.
Java APIs have fairly simple verb and noun naming scheme so you end up with very English “Object” and “Connector”, where as with Qt, all classes are prefixed with a ‘Q’.
Words beginning with anything other than ‘Qu’ are very rare in English (see here for a list of exceptions) so a search for QObject leads directly to the TrollTech site.
Forget semantic web – just come up with obscure prefixes for everything.
05.06.09
Learn from the experts (swine flu avoidance)
Ron Jeremy has the solution (via Paul Willmott’s blog):
“Apparently, and I emphasise that I only have his word for this, that when two porn stars meet on set instead of shaking hands, for who knows where those hands have been, they touch right elbow to right elbow”
Don’t forget to check Ron’s insurance service also…
via videosift.com