Social Media for the non-geeky

I've made an interesting discovery over the last few weeks.

1. Most business people have little idea what social media could do for them. 
2. If they do know, they don't know where to start.

Some geeks do, and so do some Marketing Professionals, but to most of the business world social media = alien and threatening.

So today I am trying out an experiment. I'm meeting my accountants - a firm called MurraYoung. I've been a client of theirs since they started up, and I've known one of the partners since the 80s.

They want to know more about how I use social media for my new start-up, and I'm hoping to identify ways in which their business can benefit from some extra exposure via twitter, FaceBook and Google+.

Preparing a talk or presentation? Here's a great idea

Energized work just made an irresistible offer for anyone in the London area who is working on a talk or conference presentation aimed at an agile audience - a chance to try it out on a friendly audience before the paint has dried, so to speak.

Details here.

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.

Catching the train in J

My mini array engine in Clojure is coming on apace, and another day should give me the functionality I want to right now.

I've been checking my specification against the behaviour of J, and this has had an interesting side effect.

I've tried to learn J several times. Each time I quickly mastered the basics but then hit a brick wall in understanding.

This time around the wall has collapsed.

The concept I was missing was that of a train of verbs. A verb in J is another name for a function. A train is an isolated sequence of verbs. For some reason I couldn't grasp why these were needed or how they worked, but now the need and its solution seem obvious. As a result I can read (and write) programs in J which previously eluded me.

Old habits die hard, if ever

I've taken a bit of a break from electronics, and have been having great fun with Clojure.

In the distant past I spent about 19 years programming in a (fairly) functional programming language, so Closure feels very comfortable. The thing I miss most is a Romilly-friendly multi-dimensional array library.

There are high-performance numeric libraries in Java, and some of them have been wrapped in Clojure, but their authors don't think the way I do.What I want is a library that works like the array engines in APL or J wrapped in a Clojure API.

For now I value expressiveness more than performance, and it looks as if I can implement a useful subset of APL primitives in a couple of days.

When performance becomes an issue there are two tempting possibilities. Closure allows you to use native Java arrays performantly; and a Clojure wrapper for OpenGL looks as if it may allow easy access to a workstation's GPU. This might permit array operations that run faster than they would in Java or C++.

This blog has moved

This blog is now located at http://romillycocking.blogspot.com/.
You will be automatically redirected in 30 seconds or you may click here.

For feed subscribers, please update your feed subscriptions to
http://romillycocking.blogspot.com/feeds/posts/default.

Host your own Windows7 launch party?

At a loose end? Why not host your own Windows7 launch party? Here's how.

Thanks to Neil Hume of FT Alphaville for this.

What shall we do with Gordon Brown?

Moonwalker Buzz Aldrin says a global leader should commit to sending a man to Mars.

Go for it, President Obama. And may I suggest Gordon Brown as the lucky spacefarer?

IBM says world will drown in data next year

According to IBM, "Experts predict that by 2010, the amount of digital information will double every 11 hours."

That's really, really scary. If the amount of data were to double every 11 hours, it would quadruple every day. Over a month the quantity of data would increase by a factor of 36,893,488,147,419,103,232 (roughly speaking). Over a year it would increase by a factor of ...

No, I'm not going to work it out. But if anyone from IBM reads this please can you buy a calculator for the marketing department.

Element 112 needs a name

A German team is looking for a name for an element that's just about to join the periodic table.

Element 112 is super-heavy and very unstable. It falls apart in milliSeconds.

Gordonium?

Oh, the Coder and the Tester can be Friends, can be Friends...

(with apologies to Oklahoma!)

Elisabeth Hendrickson just tweeted about a thought-provoking analysis by Michael Bolton of the much-vaunted Continuous Deployment at IMVU.

I'm a big fan of TDD, Automated Tests and Continuous Integration, but I'd hate to develop without help from good Testers. A couple of years ago I worked on a dream project; a very small, highly skilled team which included a couple of developers, a tester and a business analyst. We were pair-programming, and my pairs came from a pool that included some of the best agile developers in the UK. The Tester and Business Analyst were also outstanding.

Our defect rate was very low: five defects in UAT, none in production over a twelve-month period. There's no doubt that this was a team effort; the Tester and the BA both caught many defects that were caused by problems we developers hadn't though of, and therefore never tested for. Equally, the developers tested so thoroughly that the Tester and BA could focus on the hard stuff, where their skills contributed maximum value.

For reasons that need not concern us, the application initially went into production on a machine that was controlled by the developers. We could have done continuous deployment, but we didn't. We always asked our Tester to do a final check-through on our staging box; mostly he found nothing, but once or twice he found defects that would have been real embarrasments in production. Of course, that wasn't his only contribution; our acceptance tests were the product of very close collaboration by the whole team.

So it was no surprise to read to read about Michael Bolton's experience when he did some manual testing of the IMVU site. IMVU practise Continuous Deployment, and claim to rely entirely on Automated Tests. Read Bolton's 50 Deployments A Day and The Perpetual Beta and see the consequences.