Ruby, my dear

I recently acquired a new computer programming book entitled Seven Languages in Seven Weeks (by Bruce A. Tate, published 2010 by the Pragmatic Programmers; ISBN: 978-1-934356-59-3).  As the name suggests, this is an introduction to not one but seven different programming languages and is designed to be worked through (it’s very much a hands-on kind of book) in a fairly short space of time.  Rather than purporting to provide complete coverage of each language (which would be impossible, probably even for a single one of them, in just one book) it aims to give a fairly general introduction to each one and demonstrate some of it’s particular characteristics, leaving the reader to hit Google in search of further documentation etc.  As well as giving you a broad exposure to a range of different programming paradigms, this book is intended to equip you to pick up the elements of a new language quickly and efficiently.

The seven languages covered by the book are (in order of appearance): Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell.  I’ve just started working on the Io section of the book and, if all goes according to plan, I intend to write a blog post about each of the languages once I’ve finished the relevant section.  For now, I’ll focus on Ruby.

Of all the languages in the book, Ruby is the only one that I already have a reasonable amount of familiarity with (although I’ve played a bit with Prolog and I’m fairly sure I had a quick look at Haskell once too).  I have already written a handful of, admittedly fairly small, real world programs (as opposed to tutorial exercises) in Ruby, which could reasonably be described as a general purpose scripting language.  At the moment, I would probably describe it as my second choice go-to language for general purpose programming; Python would be my first choice, largely because I’ve been using it for somewhat longer, am a lot more familiar with it and have a bit more dead-tree-format reference material for it; they are both excellent languages (each with several definite pros and cons relative to the other) and I’d rather get reasonably proficient at both than concentrate exclusively on either one of them.

The particular (though by no means unique) feature of Ruby that Tate focuses on in his book is metaprogramming, which (he says) “means writing programs that write programs”.  I’ve come across the idea before, mainly in my studies of Lisp (although I didn’t quite get as far as doing any metaprogramming for myself).  I still don’t feel that I entirely grok the concept, but I think it’s definitely something worth exploring further and it appears that Ruby will be a good vehicle for it.

A nice, slightly quirky feature of the book is that Tate likens each programming language to a film (or TV series in one case) character that he feels epitomises similar characteristics.  In the case of Ruby, the chosen film is Mary Poppins.  Tate describes the titular character (and hence also Ruby) as “sometimes quirky, always beautiful, a little mysterious and absolutely magical.” [Actually, to be pedantic, he applies that description to Ruby and then says “Think Mary Poppins.]

I fairly recently started (or rather restarted, as it’s an old project I started and abandoned several years ago) a programming project using Python, so I’ll probably try to get it finished in that language.  However, the next time I have a real-world problem to solve with a script, there’s a good chance I’ll reach for Ruby.


Raspberry Tea

I am writing this on my Raspberry Pi, which is currently hooked up to my monitor at work (it’s now my lunchbreak and I’ve, once again, successfully resisted the temptation to play with my Pi all morning).

As I mentioned the other day, my first attempt at directly hooking up the I/O hardware (rather than going in via SSH or VNC to a headless setup) failed because my HDMI cable and DVI adaptor combo was too big to fit in the space at the back of my monitor.  I suppose the proper geek solution to this problem would have been to dismantle the cable and adaptor and see if I could wire them together directly and make the whole thing short enough to fit.  Instead, I opted for the slightly-less-exciting but also considerably-more-likely-to-work-without-frying-myself-or-my-monitor approach of buying a new cable with a HDMI connector at one end and a DVI connector at the other.  This has now arrived and works fine.

My Pi is beautifully quiet compared to my desktop PC, as it has no fan to make lots of noise (the chip is sufficiently cool-running not to need one) but it’s also noticeably slower (as it has a lot less memory and probably a much slower processor), so I won’t be trying to persuade my boss to let me replace my office computer with a Raspberry Pi, nor ditching my home PC in its favour.  However, it’s certainly an excellent little bit of kit for the price.

I’m still trying to think of actual GPIO based projects that I might want to use in real life, but I’ve now come up with an idea that is at least a step up from just making LEDs flash in pretty patterns.

Several  years ago, I wrote (and then, over the space of a few years, gradually modified) a simple little tea timer script.  As I recall, it started life as a shell script but was soon reworked in Python and has remained in that language to this day.  There are plenty of tea timers in existence but none of the ones I could find did quite what I wanted (which, initially, was mostly to allow me to run it from the command line without a GUI environment to hand, although I later added a GUI option too).

My script works reasonably well and I still use it occasionally, although these days if I want a countdown timer (whether for brewing cups of tea or other purposes) I usually reach either for my mobile phone or my mechanical kitchen timer.  However, one problem I always found with it was that it’s all too easy to miss the alarm bleep and the console message or dialog box that appears when the timer is finished.

It occurred to me the other day (or perhaps it was this morning?) that a nice shiny LED to indicate when the tea is done would be a lot more eyecatching and, with the Raspberry Pi’s GPIO facilities, it wouldn’t be very difficult to set up.  In fact, I’m intending (once I get home to my electronics stuff) to rig up two separate LEDs – one (probably red) to shine while the timer is operating (to show that it’s working) and the other (probably green) to switch on when it finishes.  I may further refine it by making the first LED flash as well if you don’t switch the timer off after a minute or so.

Due to the nature of the hardware and software involved, it’s unlikely to be possible to produce a very accurate timer, but it certainly should work well enough for purposes such as brewing a cup of tea.

Another slice of Pi

I mentioned the other day that I’d got myself a new Raspberry Pi computer and promised to say more about it soon, especially the fun I’ve been having with its GPIO port. This post was slightly delayed due to the pressing need to write about other Pi-related stuff at the end of last week, but here it is now.

GPIO (short for General Purpose Input / Output) is the name for pins on various integrated circuits (or chips) that are available to be programmed by the user. Essentially it’s a convenient way to interface your chip with a wide range of hardware. The Raspberry Pi FAQ defines GPIO as “a pin that can be programmed to do stuff.”

The Broadcom BCM2835 chip at the heart of the Raspberry Pi has 8 GPIO pins (as well as several other pins that are accessible by the user for various purposes that I haven’t yet figured out) and a nice, shiny 26-pin (IIRC) connector to make all of the pins accessible. Unfortunately that includes about half a dozen pins that can fry your chips if you connect stuff to them. Also, it’s not terribly convenient to connect wires directly to these pins. For these reasons, I decided to invest in a cheap, simple and potentially extremely useful accessory called a Slice of Pi (NB I have no connection to Ciseco, the company that sells this product, apart from being a satisfied customer). This is described as a “breakout board” and plugs in to the GPIO port on the PI, providing nicely labelled female connectors (i.e. sockets rather than pins) for the pins you can usefully use while hiding the ones that are liable to destroy the processor.

The Slice of Pi comes as a PCB with a bunch of loose connectors that need to be soldered into place. As well as being, presumably, slightly cheaper for the company to produce, this gives you the flexibility to only include the connectors you actually need. Fortunately it is not a particularly difficult soldering task to assemble the board, as my soldering skills are not the greatest.

Armed with my new Slice of Pi and a bunch of electronics stuff that I’ve had for years (since a previous occasion when I got interested in electronics), I have been able to wire up a few simple circuits to test out the GPIO capabilities of my Pi. So far, this has amounted to a few LEDs and a switch (plus a bunch of resistors and some wires) and all I’ve done with them is to make the LEDs flash in pretty patterns (hopping from one pattern to the next at the press of the switch) but I look forward to being able to move on to bigger and better things soon.

Pi Led #3

On the software side, the GPIO port is controlled by a library for your programming language of choice. At least, I assume there are GPIO libraries available for several languages. So far I’ve only looked at Python, which is the Raspberry Pi’s language of choice (and the reason for the “Pi” bit of the name, although they don’t tie you into using just one language) as well as one of my own favourite programming languages (and probably my strongest, to boot).

Having accomplished my first goal of getting the Pi to flash LEDs in pretty patterns, my next task is to figure out some actually useful things to do with the GPIO port.