A new year, and a new toy to begin it.

This all began when Tom started tweeting the prose from the back of a chocolate box.

One look at that and, having gagged a little on the truly purple prose, there was only one obvious continuation: a machine to churn out chocolate descriptions infinitely.

Which was as good a time as any to play with Markov chains. Wikipedia will explain in more detail, but if you’ve never encountered them, a very rough explanation is: Markov chains are systems that model what the next item in a list will be based on the previous ones. The more previous items you have, the better it can predict the next thing.

They’re often used in toy text generators. You give them source text to seed them, randomly pick a word from the source text, and then start choosing what should come next. What’s nice about this is with nothing other than a piece of maths, and a tight corpus, we can produce things that usually read like English without having to teach a computer something as complex as grammar. Of course, sometimes you get grammatical-yet-nonsensical English out, but that’s hardly in a problem in our case.

So I took the full prose from the back of Tom’s chocolates (Thornton’s Premium selection, for reference), some Markov text-generation code from an illuminating installment of Rubyquiz, and fiddled for a bit.

A short piece of work later and I had Markov Chocolates.

Roughly once every four hours (but it varies), you’ll get a fresh, tasty new Markov Chocolate in your Twitter feed. It’s another of my daft toys, but it still makes me chuckle. I’m thinking of expanding the corpus soon, and I hear the Markov coroporation are keen to branch out into new product lines. For now, you can get your chocolate fix here.

Music Hack Day London this weekend. Tom, Blaine and I ended up making a thing which didn’t demo perfectly, called Drivetime.

It solves a common problem: how do I listen to the same classic pop and rock anthems on a Friday afternoon as people in other studios? The answer is with the Drivetime app.

Drivetime is a Spotify app. You drag a playlist into it to start broadcasting – you set your station name with a simple text field. Then, anyone loading the app can click on your name and hear what you’re playing. Not just the current track – it’ll start the track for others at exactly the point you’re currently at, and it’ll advance through the playlist when a track finishes. At any point, you can stop listening, and choose another song to listen to.

That’s it, really: a simple broadcast/listen system, all built into Spotify as a native application.

The front-end is just HTML/CSS/Javascript, which is how Spotify apps are built; the communication with the client is via socket.io, on top of node.js on the server. Tom and Blaine wrote the back-end; I wrote a bunch of the front-end, which Blaine promptly made much better, and did all the hot pink neon. We all played a lot of Tina Turner in the hacking rooms, and we went home to bed betimes on the Saturday night.

All the code’s in github. The Spotify app only runs (at the moment) if you’re a Spotify developer. We might see if we can get it a bit further and release itspot, so people can listen to one another’s classic rock selections.

It was a fun hack, even if my explanation of it was incoherent, and part of a great weekend – so many superb hacks, large and small, on display.

I was all ready to get really worked up about this post from Wieden + Kennedy, on “why we’re not hiring creative technologists any more; we’re hiring coders”.

Then I went and read it, and basically agreed with it all very fundamentally. In a nutshell: it’s not resisting the name, or the approach; it’s resisting the idea that it’s something you can pick up quickly on a course to teach you to become one. Which is, like so many similar things, nonsense; I hadn’t realised we’d hit that point on the sliding scale. When Igor says

“Only hire people to work at the crossover of creative and technology if they have strong, practical, current coding skills.”

I say: of course; why would you do otherwise? I thought that’s what that job title meant. I seriously didn’t realise that was happening, and I’m very concerned it does. This is worth taking very seriously: if you want people to think through software, they need to be able to make that software. Not wave their hands around and have ideas about technology. We think with our hands, be we artists, designers, developers, or writers. Having another layer of people to “have ideas” is not what you need. Ideas are free.

I still use that particular title to describe myself a lot, simply because I’m not best at being your average Joe Developer. I can; I have been; it’s just not my sweet spot. I’ve made reasonable scale projects that work well; I understand how to go from a fragile prototype and turn it into solid reality, and what making things work under load looks like: and yet the bit I’m good at, the bit I care about, is the going-from-nothing-to-something-working. How will you know what a thing is until you’ve held it in your hand? How fast can you change it as you learn from it? When’s it best to step away from vim and go back to pen and paper? That’s me.

So: I totally agree with Igor about the fact that whatever you call that role, it has to have solid, actual coding chops. Not a smattering of Processing here and some weak PHP there: actual, full-on, end-to-end skills. Code that’s live in the world.

But: the most interesting thing in the article wasn’t even the stuff about Creative Technology. It was about what it means to be an agency – or, being honest, a company – that wants to engage with technology through staff members like these.

While you don’t need to become an engineering company, you face some of their challenges. You need to understand, accept and embrace some of the nuts and bolts of software development, and take on board the work dedicated shops are doing on its processes. You need such a strong streak of code running through the atmosphere that coders want to come to you, and everyone else gets code spilling over them.

This is so true. You can’t just slap technologists or developers into a company to become a technology company. Technology has its own heartbeat, its own demands. You have to begin to wrestle with the processes of an engineering company, of an attitude that leads to better work. You have to learn how it’s going to shape your culture – by which I mean, how you want it to. You get to choose; you get to control these things. It will change it, that’s for certain, but you get to hae some control over it. And similarly: you have to resist it just enough to stop becoming nothing but a software house; to retain the “creative” streak you were trying to hang onto when you started hiring for that job title.

The article it ends in this nugget:

this is hard, and it’ll take time. It’s not just procedural, but cultural, so a big part of doing it comes down to who you hire and how you let them do their thing. But that’s exactly the point. That’s why it’s most important, way before you get all that fixed, and as the first major step on that road: just don’t hire “creative technologists” who aren’t strong coders.

Yep. That’s his real point: the headline is attention-grabbing, but here’s the meat, and the most important line here is this is hard and it’ll take time.

It’s a cracking post. It’s all true. I’m going to stick to my guns and say I’m a technologist, of some kind: what I am best at is not one thing, but a mish-mash of things, and I’m better for the diversity of them. But I’ll also stick my head up and say yes, at the end of the day, if you want the Whole Thing Just Made: I will do that. I can do that. That’s why I get to use the T-word.

My only other advice for filling these positions: you don’t just need people who can do these things; you need people who can’t not do these things. Their instinct when faced with problems ought to be “let’s see what works; let’s check the assumptions we’re making are true by Just Doing It.” It’s not about jumping the gun: it’s recognising when you need to feel something, rather than guess something. And you don’t want to have to train that: you want people who just have to know for themselves.

So yeah, if you’re in one of those places that isn’t a software company, but you increasingly need to be a software company because, as Igor says, we have to be – that’s what the modern world now looks like – then it’s a really, really sharp piece of writing. I went in sceptical, but really: it was telling me what I already believed, and confirming it, and that’s a good thing, because it’s a message that needs to be written, not just assumed we all know. Good stuff.

A while back, I was interviewed for The Setup, and that interview is now up on the site. In it, I talk about what I use to get stuff (vaguely) done. Almost none of it will be surprising if you know me and what I do, but worth linking to nontheless.

If you’re working in Ruby, you’re probably using Bundler. And if you’re using bundler, you’ll probably know that typing bundle install foo will install your bundle to a directory called foo.

Of course, the problem is that Bundler remembers this configuration, and if you now run bundle install, you’ll install your bundle to… foo.

This is annoying. It’s especially annoying if you never meant to install to foo, and that was just a typo.

So: if you want to reset bundler to installing to the default location – which is your system’s current gem folder – you’re going to spend up a good hour messing around on Google looking for a plain English solution.

Can you guess who did this, and who this article is written for? That’s right, it’s me in the past!

Your solution: just run bundle install --system. That’ll install your bundle to the default system location – and continue to do so in the future. Problem solved.

(As usual, when I write about how to do something technically, it’s because I couldn’t find the answer. That’s all.)

So, here’s a thing I’m making.

My Nikon D90 can be triggered by the cheap ML-L3 IR remote. It costs about £15. You point it at the camera, push the button, and it takes a picture.

This remote works with everything from the D90 down (so, towards the D3100/D40 end of the line).

What these cameras don’t have built in, however, is an intervalometer: a timer that will make the camera take a picture every n seconds or minutes. (The D300 and up (and, I believe, the new D7000) have a built-in intervalometer.)

I thought it might be interesting to build one. The project had a few criteria:

• It couldn’t be hard-wired to a computer. It had to be a stand-alone, battery-powered device
• It had to have a half-decent way of controlling it; ideally, not just stabbing at buttons.
• I wanted it to have a 16×2 LCD screen, mainly because I wanted to both design for that constraint, and work out how to control said screen
• Ideally, it wouldn’t require taking apart an ML-L3 remote to build.

Here’s where we are:

End-to-end: it works. Note that I said “making” earlier, though: it’s still not finished, because it’s not packaged. And whilst packaging is difficult, I think that’s what’ll make it feel finished for me: a black box I can easily take into the field.

You turn it on, rotate an encoder to set a time, and click the encoder in to arm it. Hold the encoder to disarm. The time varies from 1 second to 15 minutes – after 90 seconds, it increases in minute chunks. (15 minutes is the maximum time the D90 will stay on before powering down).

Most people ask me why it says “SAFE” and “ARM”. Well, it sounds a bit threatening, but I genuinely believed that OFF and ON were inaccurate, in that the device is “on” if the screen’s on. So I was just referring to the state of the timer. And something that fitted into four characters would work well with the layout of the screen I’d chosen.

How it works

There’s very little componentry here, but each section of the Intervalometer was a neat little thing to learn on its own.

First, the IR trigger itself. Nikon’s IR remote is relatively simple: a button, some circuitry, and an IR LED. Pushing the button doesn’t just light up the IR LED; it fires a very short “coded” burst of light, so that the only thing it’ll trigger will be a Nikon camera.

Fortunately for our needs, there’s an Arduino library called NikonIRControl, which emulates that coded burst in software – so a single command will send the appropriate burst to a digital output pin. That’s our IR trigger sorted, and all we’ve had to buy is an IR led. Which feels better – and cheaper – than just soldering two wires to a Nikon remote.

The screen is a 16×2 LCD, with a serial “backpack” pre-attached. That means I can just send serial data to it over a single wire, which again, keeps the number of wires from the Arduino down. I’m using the NewSoftSerial library to talk to it, which makes life easy.

The main controller is a quadrature rotary encoder with a push-switch in it. The switch is easily read, like any momentary push-switch on an Arduino. The encoder is a little trickier, because it’s encoded. In the end, I read it off an interrupt, using code from this page – and then smoothed it out a bit by making it only read every other click.

Finally, there’s just the case of the timer. Timers are a bit more fiddly than I’d have liked. You can’t just use delay, because that delays all code on the chip. I tried doing various things including counting milliseconds, but in the end, relied on the TimedAction library, which works well enough, and does a similar thing without my broken code.

Once each piece was in place and working, it was just a case of pulling it all together. The code – which is available on Github – is broken down into a series of files, pretty much one for each section of the project. I found this much easier to manage than the tyranny of One Big File.

For piecing the hardware together, I built a simple “shield” out of a piece of Veroboard. I got a lot of laughs when I said I was using veroboard, but it worked very well for me. With some headers soldered in, it was quite easy to line it up with the Arduino – making it easily changed, but also swappable. The usual electronics-debugging issues aside, this went fairly smoothly, and it only took a battery pack to give me a portable – if fragile – working intervalometer.

What’s next? Obviously, packaging it up – something sturdy and black, with an obvious power switch and that big knob. I was considering moving it to an Arduino Mini, for size reasons, but am not sure I can face more electronics debugging. Similarly, I’m not sure I’ll build a dedicated PCB or anything like that, yet.

But: if I can get this lot into a box, that’ll be good. Also: I should take some timelapses with it.

So whilst it’s not what I would call “finished”, it is an end-to-end demo – and that feels like good enough to share with the world.

(And, of course: if you’d like to use – or build on – my code, you’re more than welcome to.)

Silly 30-minute weekend project: this led to this. It usually raises a smile, but every now and then (as above) it’s solid gold.

(Also, I found a neat pattern for decoupling all the OAuth keys so that it’s much easier to distribute/opensource the sourecode, which I’ll probably do at some point).

It’s been around the internet a bit already, but I can now show you what I’ve been working on for much of the time since I joined Schulze & Webb.

Enter Shownar:

What’s Shownar? Matt explained it over at Pulse Laser, the Schulze & Webb blog:

Shownar tracks millions of blogs and Twitter plus other microblogging services, and finds people talking about BBC telly and radio. Then it datamines to see where the conversations are and what shows are surprisingly popular.

And over at the BBC Internet Blog, Dan Taylor quotes the about page:

First, it will help you find shows that others have not only watched, but are talking about. Hopefully it’ll throw up a few hidden gems. People’s interest, attention and engagement with shows are more important to Shownar than viewing figures; the audience size of a documentary on BBC FOUR, for instance, will never approach that of EastEnders, but if that documentary sparks a lot of interest and comment – even discussion – we want to highlight it. And second, when you’ve found a show of interest, we want to assist your onward journey by generating links to related discussions elsewhere on the web. In the same way news stories are improved by linking out to the same story on other news sites, we believe shows are improved by connecting them to the wider discussion and their audience.

Of course, I didn’t work on this alone; as Matt points out, there was a good-sized team from both the BBC and Schulze & Webb, and it was great to work with so many talented and sharp people, all of whom have left their mark on the project.

People have been pretty enthusiastic so far, which is always nice to see. It’s also great been watching stories emerge – stories of what we found to watch or listen to in the office, ways our viewing and listening habits have changed, and there’s not much better praise than constantly wanting to use a thing you’ve made.

So there we go, Shownar. Another thing in the world.

CodeIgniter really is turning out to be The Little PHP Framework That Could. I’ve now dived pretty deep into it and still have few complaints; as I’ve said before, it makes all the boring stuff easy, has almost no “magic”, and stays out of the way.

As the application moves towards production, though, I began to miss a few things from Rails – notably, its ExceptionNotifier plugin. ExceptionNotifier will send you an email every time there’s an error on the site, which is really very useful with production applications.

So I investigated alternatives for CodeIgniter. I stumbled across this Stack Overflow post, which basically outlines exactly what I was looking for.

Except it doesn’t work.

Never mind! We can fix that, and the end result is MY_Exceptions.php:

(You might want to “view raw” on that – there’s some funky syntax-highlighting going on).

This really does work out-of-the-box with CodeIgniter 1.7.x. You just drop it into system/application/library, call it MY_Exceptions.php, and it’ll extend the existing Exceptions library. Obviously, you’re going to need to change a lot of the obvious details like email addresses you want things sent to, and the name of the production domain you’ve configured in your app’s config.php. You also need to make sure the error log level is set to “1″ or higher in that config.php file. But that’s about it; it really does work, and means that in production alone, you’ll get email from your app when a PHP error gets thrown, along with not only the line number and file the error was thrown in, but the URL that the user was accessing to generate the problem.

Not bad for an hour’s work. And, because it’s a Gist, you can either copy and paste, or just clone it straight into your application.

You can now find out what Schulze – or anyone else, for that matter – is listening to (as described in this post) on the web; just head on over to http://wotlisten.heroku.com.

The utility of the original command-line script is now diluted even farther – mainly because you now have to go to the website to scrape the web – but that wasn’t really the point of putting wotlisten online; the point was to see just how easy deploying to Heroku really was.

The answer is: remarkably so. I wrapped the original script into a little Sinatra application, with two views, and a tiny bit of error handling for convenience. Sinatra’s something I’ve been playing with for a while now: it’s really excellent for wrapping small scripts into little webapps with the bare minimum of extra code, and when combined with lightweight tools like DataMapper, and sqlite, just powerful enough for the lightweight tinkering I seem to do so much of. If you’re a Ruby developer and you haven’t played around with Sinatra, you owe it to yourself to check it out – it’s a lovely library to have in the toolbox.

With the webapp written, I installed the heroku gem, which helped me create a new remote git branch pointing at my Heroku account. Deployment is trivial – far simpler than using something like Capistrano; all that is necessary is to push my master branch to the heroku remote, and upon a successful push, Heroku notices that I’ve pushed out a Rack application – and it directs requests to it automatically.

It took about ten minutes to write the Sinatra app, and another ten to get it up and running on Heroku; the single snag I ran into was the same as Tom did – the need to unpack haml into a vendor directory.

I’m very, very impressed. It’s all very well being able to build small, trivial toys like wotlisten, but it’s often a hassle to deploy or configure them. Heroku really takes most of that pain away, and makes setting a tiny Sinatra app live a trivial task. It’s definitely going into my toolbox – or, perhaps, that should be toybox – for the near future.