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:

As a rails developer most of my experience with javascript libraries has been with prototype and scriptaculous, but I’ve never been quite happy with them. The helper methods built into ActionView make simple tasks a breeze, and I’ve played with the UJS plugin to improve the separation of content and behaviour, but even then the weight of the libraries and the comparable simplicty of tasks like iteration offered by jQuery has always made the grass over there look quite a bit greener.

So when Karl told me that he and Jonathan Chaffer were working on a book about jQuery and offered to send me a copy that seemed like the perfect opportunity to begin making the switch. (that comment should be taken as a disclaimer, by the way.) In the end the timing was fortuitous as I’ve ended up working on a couple of drupal projects (jQuery is included with drupal from version 5 onwards) and having to integrate some jQuery code into a rails project, so I’ve needed to take the lessons learned from the book and quickly put them into practice.

The book takes a gradual pace, introducing the library, and how it handles selectors, events and effects, before moving into DOM manipulation, AJAX and handling forms. Standardistas will be pleased that there is a strong emphasis on progressive enhancement, always starting with pages that achieve their basic intent and then using jQuery to improve the user experience. The authors place considerable emphasis on the importance of providing all users with a solid basic experience and show how jQuery makes it very easy to do so.

More experienced javascript developers may find the pace of the book a little slow (and might prefer to look out for the companion reference volume). The core audience is likely to be those who may have dabbled with the odd snippet, or perhaps used tools that generated javascript for them, but want a step-by-step tutorial that shows how to use jQuery to do things cleanly while building general understanding. Nevertheless, the coverage of more advanced topics like closures is solid and a good reminder even for the more experienced developer.

There were a couple of areas that could have done with a little more exposition, such as the fairly cursory coverage of the difference between GET and POST in HTTP requests (being a purist, I was really looking for mention of PUT and DELETE too), and the fact that without more work one of the shopping cart examples could leave the user thinking their updates had been saved when there was no mechanism to actually make the updates on the server-side. That said, hopefully by that point in the book most readers will be alert to such things and know that the examples are not necessarily production code.

If you’re looking to consolidate your javascript skills and like the look of jQuery, or, like me, you find that sometimes sitting down and reading a book is the best way to familiarise yourself with something, Learning jQuery is well worth your time and money. You can find it at packt, amazon US, amazon UK and all sorts of other places.

Recommend this post:

Spending a weekend in Chicago last month and looking for a non-starbucks coffee shop in the loop, I was frustrated to find that the otherwise very handy delocator.net didn’t have an option to limit a search to a radius of less than 5 miles or to plot a group of results on a map. We eventually gave up and went to one of the many Starbucks highly visible in our immediate vicinity.

Of course, I could have written a scraper to pull the data off delocator’s results page and produce a map from it, but it would likely have taken more than the 5 minutes I had available. What I needed was Solvent. According to its creators at the Simile project, Solvent is “a Firefox extension that helps you write Javascript screen scrapers for Piggy Bank” and their screencast displays someone solving exactly the problem I found myself faced with.

As the screencast shows, extracting data from any page that has some structure to it is as simple as firing up the plugin, highlighting a few lines and selecting an appropriate description for them. The interface will feel familiar to anyone who’s worked with javascript debuggers, and it only takes a couple of minutes to get the data off the page, into PiggyBank and—thanks to PiggyBank’s google maps integration—onto a map.

For those who are comfortable with the DOM and Javascript, this is a fantastic tool. Along with the growing suite of microformats and the Greasemonkey scripts Mark Pilgrim is writing to parse them, this project shows that we’re rapidly moving towards a world where a decentralized store of semantically-rich information is possible.

Simile even have a companion project, Semantic Bank, that provides long-term storage of the captured data. It would be nice if users were prompted to set up an account with that (or other semantic banks) when they first install Piggy Bank. Coupled with some UI developments to make both Solvent and Piggy Bank more accessible to the non-technical user, and we could quickly see publishing data to the Semantic Web become as simple as blogging.

Recommend this post:

There has been much jubilation since Google announced their javascript-based maps API yesterday. I’ve been playing with it a little and have updated the Grand Rapids WiFi google map to use the new API. The web pages produced this way are much more responsive than those using the old hacks, and it’ll be great to see what people produce now we have official support.

I’m hoping to shortly release a new version of the WiFi site which allows search results to be plotted on a map (or viewed as a list as at present). Until then, this implementation remains ‘experimental’.

Recommend this post:

For the past few weeks I’ve been meaning to play with myGmaps, and last night I finally got the opportunity. I’d introduced a map view to Grand Rapids WiFi a few months ago, but I’ve never been entirely satisfied with the map in use or the flexibility of the zoom, so I decided to explore what it would take to move that data onto a google map.

Generating the required XML was very straightforward. Between this piece at Engadget and the tools at myGmaps it was very simple to add a new Smarty template to the site and get everything up and running. It’s a shame google didn’t go with some more standardised vocabularies (it would be wonderful to be able to pipe the existing RDF version of the site straight in), but at least the format is simple.

What I did find, however, was that my browsers quickly became unstable. I’d never seen Firefox’s “A script is making Firefox become very slow, should I terminate it?” warning before last night, but plotting around 40 points on such a map triggered it. Reducing that to five points with an SQL LIMIT helped considerably, but at the cost of much of the map’s utility. The full maps is nice, but nowhere near stable enough to make a regular part of the site (I may put a link to it, but it will be with provisos).

I hope there’s a way to reduce the weight of this toolkit, as it’s definitely a far better map. If google were to launch a public API, perhaps we could start building more advanced applications which integrate directions and other tools. For now, it’s back to the drawing board for me, to try and work out a UI that lets me reduce the number of points plotted while still being useful for the user.

For those with plenty of RAM, you can find the full map at grwifi.net/gmaps/.

Recommend this post: