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:

According to wikipedia:

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Design patterns, and particularly their application in dynamic languages can be a controversial topic, and every now and again another round of blog posts bubbles up appalled at the way a new group of programmers have become infatuated with design patterns. Applied without care design patterns can quickly lead to over-engineered code that seems designed as much to draw on as many of the established patterns as possible as to solve the intended problem. But if applied with care, and with consideration of how a pattern applies in the context of your chosen language they can be a helpful way to draw on the wisdom of the coders that came before you, and make your code easier to understand to those who may inherit it.

Written by Dustin Diaz (of Google) and Ross Harmes (of Yahoo), Pro Javascript Design Patterns builds on experience of building complex, high profile javascript applications. That experience shows as each pattern is introduced with solid examples and sample code and then refined to provide looser-coupling, more flexibility and/or better performance.

Early on in the book I was concerned that some of the solutions could become too heavy and the early introduction of interfaces hinted at something akin to the early approaches to pattern usage in PHP, which often looked more like an attempt to turn PHP into Java than a way to use PHP’s own features better. As the book goes on the usefulness of those interfaces, particularly for large development teams, becomes clear and most of those concerns are allayed, especially as the authors offer pros and cons for the use of each pattern and are clearly focussed on how these patterns can help produce more robust solutions.

Most of the patterns will have a fairly immediate impact for developers new to them, and even for those who have used them in other contexts it is helpful to see how they have been applied in JavaScript. Most modern JavaScript libraries rely on several of these patterns to abstract out handling of different browser quirks or adding new event types, and even if you rely heavily on one or more of the major libraries this guide may well help you understand their internals better.

I’ve sometimes been skeptical about books claiming to be targeted at an advanced target. Labels like “pro” are often handed out far too easily. But in this case it seems deserved. While the book does a good job of quickly introducing approaches to object-oriented programming in JavaScript, that’s based on an assumption of a solid knowledge of the language and of OO development in at least one language. If you’re a newcomer to JavaScript or just looking for a way to add a few fancy features to your web pages this isn’t be book for you. But if you have some serious JavaScript development experience and are needing a way to tighten up your code to make it more modular and more maintainable, this book is well worth your time.

Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at apress, amazon US, amazon UK and all sorts of other places.

Recommend this post:

Among other things, I’m currently working on a relatively large CMS/membership site. At the project’s initiation I decided to steer clear of off-the-shelf solutions, partly because I wanted to take myself through the learning curve that the project was sure to involve, partly because none of the CMS or framework options I looked at really appealed to me, and partly because it seemed as though the customisations required to manage this dataset would take nearly as much time as a from-scratch solution.

So far, the development has gone pretty smoothly, but for the past couple of days I’ve been revisiting a few early design decisions with the hope of making the site more flexible. Since google has yet to provide much of use when it comes to this aspect of PHP and Design Patterns, I’m going to try and document my thinking here.

This is by far the largest project I’ve undertaken since developing an awareness of MVC and other design patterns, and I’ve been trying to toe the fine-line of being informed but not defined by them. The largest challenge so far seems to have come as I try to loosen the ties between the layers.

I want to make it easier to add alternative representations of various resources. In some cases, that means atom feeds, in others it may mean FOAF or other RDF representations, and right now it means reusing View classes within the management system. I’ve spent most of the morning reworking my Dispatcher/Controller, and building some sample classes to work with it, and what I have at present is:

1. Dispatcher uses switch statement to call Controller which builds a model. There are a number of generic model classes, as well as a few specific-use ones
2. Dispatcher queries request to see if we’re asking for a particular representation, defaulting to XHTML
3. Dispatcher calls a factory to retrieve a View object, passing the type and a reference to the model
4. Factory first checks for generic model types and then for specifics, and returns an appropriate View
5. Dispatcher asks View to produce the output

This is largely achieving the required result, but it’s relying on several large ’switch’ statements. There’s one in the dispatcher to choose a Controller/Model, there’s one to check the request type, and there’s one to select the appropriate View. I’m trying to work out whether there’s a good way to combine some of that logic, and thereby make it easier to add new Views and new actions.

When it comes to location-awareness, my hunch is that I’d be best off doing some parsing of the referer and the request_uri to work out where we are, and who called us, and then allowing each View to apply its own logic to decide on a template to show and a place to return the user to. Here, I need to work out how best to do that while keeping the system as portable as possible and ensuring code-reuse.

Recommend this post: