Log in

No account? Create an account
latest entries related journals calendar about the author My life in pictures older entries older entries more recent entries more recent entries
To Dream of Real-Time Ruby? - My Thoughts Today
An ill-used association of words and pictures
To Dream of Real-Time Ruby?
My RubyConf 2009 proposal which alas didn't make the cut.


Ruby is a beautiful language, and because of that beauty we tend to ignore the fact that it's also highly disruptive. In recent years it's revolutionised the world of web development and changed the direction of the Java Virtual Machine, but we've only scratched the surface of what's possible. By marrying the elegance of Ruby with a knowledge of the environment in which our software will execute a whole new class of system-level applications lies open to us.

Whether your interest is in leveraging the power of multicore CPUs or creating your own distributed processing network, understanding how Ruby integrates with its environment will free you from reliance on brittle tools written in legacy languages and suggest elegant solutions in keeping with the Ruby Way.

So come on a gentle code safari with London-based hacker Ellie to see just how low-level Ruby code can go and why knowing this will not only make you a better programmer but transform the systems you build.


The title of this presentation reflects a dilemma I've been pondering for many years now: is Ruby capable of tackling low-level and realtime problems, especially of the sort found in embedded systems. When I first started playing with the language back in 2001 my commercial work revolved around embedded control systems in a mix of C and Visual Basic, and part of what attracted me to Ruby was its elegance compared to these languages.

I don't yet have a good answer to the question itself, although my gut instinct tells me that Ruby can and should be pushing into this area. Just remembering the impact Rails had on the web development space makes me positive that if Ruby can be pushed down the stack we'll see a radical change in the way that everything from the operating system upwards is coded. But how to get there?

Unfortunately this presentation won't be able to answer that, but I'm hoping that by reaching the RubyConf audience I'll be able to inspire a few others to experiment in this territory with all the benefits that'll bring.

Mostly I'll be talking about Unix as that's the platform I work with these days. Whilst I consider myself far from being an expert, I've been performing informal experiments in Ruby-Unix integration for several years now and back in the spring I started putting a public face on these with a series of conference presentations: "The Ruby Plumber's Guide to Unix". The idea behind them is to encourage Ruby developers to treat systems coding as nothing more than kernel scripting, an approach which I hope will make it seem less daunting to those who lack a background in C.

Trying to make this accessible to a broad audience is itself proving an interesting challenge and the reception to date has been mixed: hardcore coder geeks love it, especially the discovery of DL.malloc and all that flows from that, but I'm still trying to pitch to the level I really want to reach which is those who lack a hacker background and have only ever seen the machine as a black box running Rails applications. The latter group are the ones who really need this knowledge because it could significantly alter the way in which their system architectures evolve.

By the time RubyConf rolls around I hope to have completed all of the technical research I currently have planned for the "Plumber's Guide" and I'd really like to wrap the whole project up with a presentation that's less focused on the specific technical detail and more on its significance: the former will by then be more than adequately documented online.

As I'd like this to be a presentation that will encourage more developers to investigate the options open to them and spark their imaginations it's also going to be something of a departure from my usual style and, well, it may not even have much code in it... although my idea of not much code could still involve a couple of dense slides with detailed examples suited to off-line study.

In terms of format, I have ample material with which to fill several hours and so would be happy to give a tutorial if the option exists. But I can also prune this to the forty-five minute mark.

Tags: , ,
today I am mostly: annoyed