Comfort for Application Developers from Tom de Marco

Thanks to a tweet from @flowchainsensei, I've just been enjoying an excellent article by Tom de Marco. It's well worth a read; I took away two key thoughts.

1. Developing software is much harder than developing hardware
2. Software developers spend much of their life feeling bad about late delivery when it's usually not their fault.

To put his core conclusion another way, most software projects are a waste of effort. They have such low marginal utility that they are doomed never to show a return for the organisation that funds them. If we just didn't do them the world would be better off.

Of course, we'd need to find work for the ex-developers.  Maybe they could learn to teach. We could certainly use a few more skilled IT teachers.

I2C on the Beagleboard xM

It's really easy driving I2C™ devices from the Beagleboard. I'm using the Trainer-xM from tincantools; that takes care of shifting voltage levels from the 1.8v used by the Beagleboard to the 5v levels that my I2C boards expect.

There are a few I2C coding examples on the web; since my BB image includes python and geany, I've written the I2C code in Python and can edit and test it on the board. Much faster than an edit-compile-upload-test cycle.

Here's the code:

import i2c, time

extender = i2c.I2C_device(0x20)
extender.begin_transmission()
extender.send(chr(0))
time.sleep(5)
for count in range(0, 16):
    extender.send(chr(count))
    time.sleep(0.5)
extender.end_transmission()

See it running.

From little Acorns do great Raspberries grow

I recently re-discovered an old friend: the great-great-grandfather of the ARM-based Raspberry Pi . It's the original Acorn micro-computer (ca. 1979). Acorn went to on make a succession of machines, including the BBC Micro and the Archimedes.

The Archimedes was based on a proprietary RISC chip which is the grandfather of today's ARM chips. The Raspberry Pi is part-funded by Dave Braben, who wrote Elite (arguably the most famous BBC micro game). Broadcom, who are make the Pi's ARM chip, have strong historic links with Acorn.

I'll try the micro out in a day or two; I still have the (fairly minimal) original documentation, and there is more information on Wikipedia. The micro was arguably one of the best investments made by Cocking and Drury; my colleague Jonathan Barman used it to learn assembler, and went on to master 370 Assembler, through which he landed us a major contract with a national brewery.

Blogging from the Beagleboard

I'm posting this using the Midori browser running under a custom Angstrom image on my brand-new Beagleboard Xm. The Beagleboard continues to amaze me.

Setting up a fresh sd card with a custom image has proved a little tricky; it's taken about 4 hours, of which one was spent waiting for a very slow Kingston microSD card to get configured on first boot. I'll write up the process and post it later this weekend.

Busy with the BeagleBoard

Yesterday I decided that the time had come to get to grips with embedded Linux. I ordered a BeagleBoard Xm from Farnell, a suitable wall-wart from Maplin, and started counting the hours until they arrived.

Both turned up this morning and my brand new BeagleBoard is up and running. My biggest worry was the possibility of blowing the board by connecting the power supply the wrong way round; maybe the manual tells you about the required polarity of the power plug, but I couldn't find the information anywhere. As usual, Google was my friend; it turns out that the board requires a centre-positive, earthed shield plug. The Maplin PSU is configurable, but the required polarity is the opposite of what the Maplin markings suggest is the norm. I strongly advise you to check the polarity of the plug with a multi-meter before you plug it into your precious BeagleBoard.

I'm still waiting for a couple of microSD cards; Argos has them at at three times the price I paid on Amazon, and for now I'm happy playing with the test distribution which comes with the kit.

The test distribution is a usable version of Angstrom. I followed the great getting started guide on IBM developerworks. It's helpful, but a little out-of-date; it suggests that the test distro is ram-disk based and loses changes to the filesystem on re-boot, but that's not the case. I took the screenshot shown below during my first session and it was still sitting on my desktop when I rebooted.

As you can see from the screenshot, the distro comes with a lightweight but functional web browser and many of the tools you'd expect to find in a desktop environment. It doesn't come with the nano editor; perhaps I'll finally get to grips with vi. (Doh. It's got gedit. I can stay a mouseman). It does include Python, which makes me very happy.

I started writing this post while the distro was updating. It's now finished.

This inexpensive board has much, much more computing power than the Atlas - a supercomputer I programmed in the late 60s. When the first Atlas was commissioned, people said that the UK's computer power doubled overnight.

I'm looking forward to a couple of months' happy play research with the BeagleBoard - and by then, with any luck, I'll be able to play with a Raspberry Pi.

VMWare: how to lose a customer in one easy lesson

A while ago, when I was developing a lot of courseware, I got hooked on virtualisation. Virtual Machines are a great way to create a repeatable course environment, and if your course is Linux-based you can distribute the course images freely. I started off using VMWare; their Windows workstation was inexpensive, and their player was free.

I stuck with VMWare for years, and used it for more and more applications. In the good old days, when Dell were after market share rather than margin, I picked up a couple of servers for about £250 each - dual-core machines with 4Gb of ram and decent hard drives. I ran Ubuntu on them, and used VMWare Server to host several virtual machines.

All worked fine until VMWare announced that  Server had reached end-of-life, and their remote desktop stopped working with current browsers. I found myself with a set of unusable VMs which represented many weeks of development and configuration.

At the time I was working on a contract a few desks away from Stuart Ervine, and he suggested I try VirtualBox. It's proved to be a more-than-adequate replacement for VMWare, who won't be getting business from me or the clients I advise in future. Of course VMWare were within their rights to end-of-life a free product, but they caused me enough grief to destroy six years of brand loyalty at a stroke.

Leiningen and Eclipse

I'm now fairly comfortable with leiningen, though I still feel a frisson of anxiety whenever I run it. I know that Maven is lurking there somewhere, and my experiences with Maven have not been happy.

I'm also a bit leery of letting lein download and install arbitrary software from external sources. I'll need to set up a local repository, which will mean a closer brush with Maven that I've had before.

It's annoying, but seems unavoidable. Clojure libraries and tutorials generally assume that you're using leiningen.

At least the lein/Eclipse combo makes it simple to create and populate an Eclipse Clojure project.

Here's what you do:

1. In the directory in which  you want to create your project, run lein new
2. cd to the newly-created directory
3. open project.clj in your text editor of choice
4. add :dev-dependencies [[lein-eclipse "1.0.0"]]
5. save the file
6. run lein deps
7. run lein eclipse
8. import your newly-created project into eclipse

At the end of stage 4, your project.clj file should look like this

(defproject hadoop-spike "1.0.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.2.1"]]
  :dev-dependencies [[lein-eclipse "1.0.0"]])

WabbitMQ runs too

Off to a good start this morning;I set up a Clojure spike using WabbitMQ and got a simple test running in a few minutes. Now I can link up my Python and Clojure components. Eeeeeeeexcelent.

Run, RabbitMQ, run Rabbit, run, run, run

I'm about to do some more work on Sknoman (a personal knowledge management application) and need to link together several disparate subsystems. Some are written in Python, but I'm developing one in clojure.

Nat Pryce speaks highly of RabbitMQ, so I decided to give it a try.

For reasons too boring to explain, I'm developing on a Ubuntu Lucid virtual machine. Lucid is almost as old as I am, so the packaged version of RabbitMQ is seriously out-of-date.

Once I'd installed an up-to-date version from the RabbitMQ Debian repo, I had the RabbitMQ Python send/receive example running in about five minutes. While that's hardly an exhaustive test, it's very reassuring.

I'll be trying a Clojure client next, but I'm hoping this is going to be painless.

PrecisionIR - great service, terrible software

PrecisionIR - how not to run a service

I've been using the free annual reports service provided by PrecisionIR. It's a great service; you can get hundreds - no, thousands - of free annual reports and daily updates about the companies that you are interested in.

Twice now PrecisionIR has emailed me a survey abut their service. They say it's a short survey, and it is.  Each time it's crashed on the second response.

The second time it happened I decided follow the advice in the error page and email support at PrecisionIR. The email bounced.

I guess they don't do a lot of testing.