For many the idea of bringing design patterns to ruby is a terrifying one. Having taken refuge from over-engineered java projects (or for that matter, attempts to apply java engineering approaches to a somewhat dynamic language like PHP) the baggage that often goes along with design patterns isn’t what a recent convert is looking for. But as I mentioned in my last review of a design patterns volume, and series editor Obie Fernandez highlights in his foreword, design patterns don’t have to be used that way and maintain merit when used as a source of collective experience and shared language.

Russ Olsen’s book does a good job of stepping through the key patterns from the Gang of Four’s initial offering, showing how they can be applied to and simplified with Ruby, introducing along the way various uses of blocks, mix-ins, and other powerful features of the language that may be unfamiliar to newcomers. Each chapter highlights how the pattern can be used or abused, sounding a note of caution to dissuade unthinking embrace of every pattern between its covers. It’s clearly written with a nice balance of code to prose.

Towards the end of the book a couple of “new” patterns are offered, particularly “internal DSLs”, “meta-programming” and “convention over configuration.” Opinions differ over whether of those can really be considered patterns in the general sense of the term. Certainly those concepts are examples of a community gradually refining its approaches to common problems, but at least two of them are considerably more conceptual and abstract than most of the other patterns in the book. Perhaps the best way to understand them is as giving an insight into the working patterns of the ruby community approaches problems, and pointers to topics worthy of more exploration.

That usage of the final few chapters gives some indication of the probable audience for this book. It seems best suited to those who have dabbled with ruby but don’t yet have much experience. A general sense of syntax is all you’ll need going in, but you’ll come away with a much stronger sense of the language’s features than that. Similarly it’ll work well for those with a general sense of the major patterns but who could do with a refresher, maybe while transitioning from java or other “enterprisey” development to ruby.

While it won’t have the same general appeal of other titles in the series like The Ruby Way and The Rails Way, this is a handy volume in a series that is making strong contributions to the ruby book market.

Disclaimer: I was sent a copy of this book for review by the publisher. There were a few pages missing due to a printing defect so I wan’t able to read parts of chapters 13 or 14. You can find it at amazon US, amazon UK and all sorts of other places.

Recommend this post:

Working with a number of non-profits I frequently find myself tasked with extending or upgrading drupal. Each new version of drupal has been a significant step forward and I’m usually keen to get up to date but there’s the small matter of the suite of modules most sites use that need to catch up with changing APIs. With the release of Drupal 6 a few weeks back I found myself wanting a tool that would help me check if my chosen modules were ready for the upgrade yet.

The quick solution I came up was a screen-scraper that will take a YAML file listing the relevant modules and their URLs and check to see if a Drupal 6 version has been released as yet. I wrote it in ruby, because after all that PHP work it’s nice to slip back into a language that feels so comfortable. (and hpricot is delightful for quick scraping solutions).

In case it’s helpful for anyone I’ve popped the ruby code and a sample yaml file up as pasties. Currently it’s invoked from the command line (providing you have ruby and hpricot set up) with:

./drupal-modules.rb my-file.yaml

A couple of nice enhancements would be to either grab the list of modules from an existing drupal database, or to set this up as a little web service where people input the modules they use and can check a web page or receive an email when there’s a status update. It could even lead into some discussion of where certain older modules should be considered redundant and/or replaced with newer options. Time’s not likely to let me build that, but I’d love to hear if someone else does.

Recommend this post:

With its complex yet penetrating arcs and careful unravelling of a fictionalised but well-rooted version of Baltimore, The Wire quickly became my favourite television show of recent years. So following its recent conclusion I’ve naturally been devouring every article I can find, not quite ready to let go.

The following paragraphs from a piece by executive producer David Simon struck me as an unintended example of why newspapers (his previous profession) have generally fared so poorly over the past few years, and a reminder of how easy it can be to miss the possibilities new technologies :

It would not have been easy for a veteran police reporter to pull all the police reports in the Southwestern District and find out just how robberies fell so dramatically, to track each individual report through staff review and find out how many were unfounded and for what reason, or to develop a stationhouse source who could tell you about how many reports went unwritten on the major’s orders, or even further — to talk to people in that district who tried to report armed robberies and instead found themselves threatened with warrant checks or accused of drug involvement or otherwise intimidated into dropping the matter.

These are areas that the technologies we use on the web should have helped papers become more effective. Improved scraping, syndication, and the tools that make sites like EveryBlock possible make it easier for people to track the data and offer new ways to identify potential grounds for investigation. The technology doesn’t remove the need for beat reporters, but it might let them find the leads more quickly, and help newspapers find the story. Instead, too many have simply looked to the short-term, aiming to raise ad revenue by becoming increasingly generic.

The story is the same outside the confines of the newspaper world. When approaching new web projects we need to make sure we’re not simply being reactive, but proactive. How can we take what we do well, and do it better?

Recommend this post:

• Is MySpace Good for Society? A Freakonomics Quorum - Freakonomics - Opinion - New York Times Blog
  Not really about MySpace, more about social networking sites in general. A good set of quotes on the value/effects of social networking site usage.
  (tags: freakonomics myspace socialnetworking sociology)
• Net, Blogs and Rock’n'Roll: Recommender systems meet festivals
  Last.FM will look at your listening and build you a list of recommendations for which SXSW bands to see. Nice idea.
  (tags: last.fm livemusic recommendation)

Recommend this post:

Yesterday, Matt Patterson and I moved into the office space we’re going to be sharing. In London’s fashionable Hoxton, right next door to a startup we like a lot, it’s a good place to be. We currently have space for one more full-timer to share the office with us, so let us know if you’re looking for a place to work.

Having worked from home for several years now I’d grown accustomed to the easy commute, the flexibile hours, and the various other comforts, but over the past few months my home internet connection has become more and more unreliable, and with a lot less space here than we had in the US, it’s not quite so easy to spread out. So the office feels like a good move. More sociable, more separate from home life, and with better facilities.

Blogging may continue to be light as unpacking and arranging furniture vies for my time with the deluge of work the past few weeks has brought, but I hope to return to a more regular schedule before too much longer.

Recommend this post: