Posts tagged Javascript

Selected (belated, extended) Saturday Links

The past two weeks haven’t really left time to compile my selected links, though there have been many. A few days at SxSWi (on which more, later) followed by travelling with the family and the inevitable work backlog moved blogging way down the priority list. So here’s a mammoth selection to get me caught up. Particularly interesting has been the discussion around the future of newspapers (represented here by Clay Shirky, Steven Johnson and Russell Davies), which seem to have finally pushed beyond “how t ind a good business model for papers” to looking at where the real value for society lies and how we can preserve and extend that in a changing landscape.

Book Review: Pro Javascript Design Patterns

Pro Javascript Design Patterns sleeveAccording 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.

Book Review: Learning jQuery

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.

Solvent: Semantic data from almost any page

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.

More WiFi Google Mapping

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’.