I’m not exactly a javascript guru, and this article is not exactly rocket science. However, I have done web development for the past 10 years and almost all projects has involved a decent amount of javascript hacking. The past couple of years jQuery has been the obvious choice, but what’s both good and bad about this framework is that it doesn’t enforce any specific style of javascript development. Javascript is an amazingly flexible scripting language, and can used both strictly object-oriented, mind-bendingly function-oriented – and everything in between. I don’t have a very consistent style other than the basic rule of thumb of “namespacing” by wrapping functions within an object to minimize the risk of clashing method definitions.
One of the most advanced javascript-driven pages I have developed is the list page of Lokalebasen.dk (it’s in Danish only, sorry). The page shows a number of locations available for rent in a Danish postal district, and allows you to select more postal districts – adding more locations to the map and the list – and to filter the locations by both size and price, thus limiting the number of shown locations. Furthermore any location can be added to the “shopping cart”, and behind the scenes all changes of postal districts and filters are reported back to the server for tracking purposes.
The initial javascript driving the page was developed interchanging by me and another developer on the fly as more features was added to the page. It is one of the most important pages on the site, so it has been through many iterations in attempts to both improve usability and optimize business goals. After almost 2 years in production, the javascript for the page reached a complexity level where it started to seemingly make its own decisions about when to do what, and older browsers and slow computers started to have problems handling the page as more and more locations was added. We decided to drastically refactor the javascript, and I realized that an event-driven approach was what we needed to handle all the complex interaction between the different components of the page.
A few days ago a new Danish community for book lovers and consumers seeking the best book prices was launched: bog.nu (which translates to “book.now”.) The website has (of course) been implemented in Ruby on Rails during the last couple of months by Jesper Hvirring and yours truly for the Danish publisher Forlagsgruppen Bindslev.
On one level it can be used simply to compare the prices of one or more books at the leading Danish internet bookstores. The site allows the user to put several books on her virtual bookshelf, and then make a price search showing where she can get all the books cheapest in total, including shipping and handling.
On another level bog.nu collects all the latest reviews of new Danish books, and calculates a “meta score” from 0-100 based on all reviews. This allows users to rank their searches not just by typical parameters, but by how well they have been reviewed. This makes it easy to find, say, the best Danish comics.
Jakob Skjerning, Laust Rud and I has just finished the 48 hour coding marathon that is Rails Rumble. In just two days we have build a web based space trading game from scratch in Ruby on Rails called SpaceShippers. It’s online, it’s working and some even think it’s rather fun. Jakob live-blogged about it.
So why did three guys choose to spend their weekend hacking away at space game? Not because we expect fame, riches and the 1st prize in Rails Rumble, that’s for sure. Before the weekend, none of us had even checked what the competition prizes was. Not because it’s our only chance to code Ruby on Rails – all three of us do that in our professional working life every day. But all three of us are consultants, and we mostly code what other people want us to, not what we want to. And let’s be honest, inside every highly professional business programmer there’s a little game developer trying to get out. Computer games are great fun, and they don’t need fully fledged 3D environments to be good – although it often helps. We considered many other ideas, but I think we ended up during a game because we knew it would be motivating to build something to be entertaining, rather than just another tool or mash-up site.
Hello, I'm Casper Fabricius. I have developed for the web for 10 years, and have been enjoying Ruby on Rails for the past 5.
My experience covers communities, shopping solutions, multi-language sites, heavy back-end lifting and a wide selection of more traditional websites. I like to integrate Ruby with Java and .NET through JRuby and IronRuby when it makes sense. I am passionate about test- and behavior-driven development, but at the same time I am pragmatic and believe in getting things done.
I live in Copenhagen, Denmark, where I work for a fantastic company: Podio. I do not currently take on freelance assignments.