John Topley’s Weblog

My name’s John Topley and I have a little secret that I want to share with you today. No, not that one. The fact is that I’m addicted to buying computer books, to the extent that I often buy them but never finish them. I could spend days in the Computing section of one of the big bookshops in Charing Cross Road.

It gets worse though because not only do I have a poor record at finishing them, sometimes I don’t even start them! This is a problem for me, because if I fork out for a book then I jolly well feel obliged to read it from cover to cover. Then I feel guilty when I invariably don’t get time to do so.

I usually read every day, but it tends to be a fiction book at bedtime. I don’t like reading technical books before going to sleep because they set my mind buzzing and keep me awake.

Another excuse for my shocking record at completing computer books is that invariably most of them go out of date pretty quickly. For example, probably half of the Ruby on Rails books in my bookcase are obsolete now as the framework has evolved so rapidly.

Listed below are a selection of the computer books that I’ve started, half read, read completely or realistically will never read. Incidentally, the book title hyperlinks will take you to the Amazon UK page for that book. I am an Amazon Associate but I won’t make any money if you click on those links and decide to buy these fabulous books, because I couldn’t be bothered to work out what the associate URLs should be. So rest assured that this hasn’t all been a cunning plan to make me rich. With that stated, read the list and weep dear reader.

Books That I’ve Started But Have Yet To Complete

The Art of Rails

This was the book that was going to buck the trend; I vowed when I bought it that I was absolutely going to finish it. After all, it’s less than 300 pages; how hard could it be? Needless to say, other things got in the way, but I’m definitely ready to start chapter three.

Design Patterns Explained: A New Perspective on Object-Oriented Design

I got about half-way through this book by reading it during some downtime at work. It’s pretty good.

Ruby For Rails

I’m actually about halfway through this one, but the trouble is that I read the half nearly two years ago, so have forgotten it. I met the author of this book—David A. Black—at Berlin airport the morning after RailsConf Europe 2008 finished.

The Rails Way

This tome weighs in at over 800 pages, although some of that is an API reference. The big deal about this volume when it came out was that it was one of the few books to cover the then-new Rails 2.0. It’s been a handy reference.

Books That I Mean To Start

Design Patterns: Elements of Reusable Object-Oriented Software

The famous Gang of Four book that kick-started the whole software design patterns movement. Whilst there are undoubtedly many programming pearls in here, it’s kind of hard to find them because the text isn’t written in the most accessible way and the examples use C++. Hence a whole industry seems to have sprung up around writing books that present this material in an easier to digest format.

Refactoring: Improving The Design of Existing Code

According to my Amazon UK order history, I bought this book nine years ago! I’ve dipped into it numerous times and when doing so have always thought that I really must read it properly, but obviously it’s not happened yet. Now I have a excuse—I lent it to a member of my team at work to read, so I actually don’t have it to hand.

Programming Ruby: The Pragmatic Programmer’s Guide

The classic “Pickaxe” book and the definitive guide to the Ruby programming language. I look things up in this book fairly frequently.

TextMate: Power Editing for the Mac

I’ve been using TextMate as my programming editor on the Mac since early 2006. However, as I only use about 5% of its capabilities I thought it would be a good idea to learn more about it so that I could leverage its power and become super-productive. I haven’t read the book yet but three years on I’m probably up to 6%.

The Mythical Man Month: Essays on Software Engineering, Anniversary Edition

This book should need no introduction. It’s the classic text on software engineering. I actually have this sat on my computer desk right in front of me as a reminder to read it. I’m sure it will be very good when I do so.

The Pragmatic Programmer

I really like this book and I expect I’ll like it even more when I finally sit down to read it properly.

Books I Own But Will Never Read

Applying Enterprise JavaBeans, Second Edition

I bought this when I was really into Enterprise Java in quite a big way. In other words, when I didn’t know better. I’ve never actually written an EJB and never intend to. Maybe I’ll take it to a charity shop where it will nestle nicely alongside the celebrity keep fit videos and Take That CDs.

Dive Into Python

I bought this after reading the tip in The Pragmatic Programmer book that you should learn one new programming language a year. So I got this book and then went and learned Ruby.

Expert One-on-One J2EE Design and Development

This is the book that laid down much of the thinking that would evolve into the highly successful Spring framework, which is much used in the J2EE and .NET worlds. I found it a bit heavy going. Much like Spring itself, come to think of it.

High Performance MySQL

I couldn’t really tell you why I bought this. I think it was when I first learned Rails and I probably thought that having a hugely successful website on my hands was imminent.

Microsoft Visual C# .NET Step by Step

I bought this book in 2002 back when .NET was new and exciting and it looked like my employer might embrace the technology for their modernisation programme. They went with J2EE instead, hence the Java books.

Books That Against The Odds I’m Proud To Have Read Completely

Code: The Hidden Language of Computer Hardware and Software

If you’re a computer programmer then you really owe it to yourself to read this book, as it does a very good job of explaining how computers actually work. Unfortunately I made the mistake of reading it at bedtime, so the later chapters lost me completely and I also had a lot of sleepless nights. I’d like to read it again when I have the time to blast through it in a week.

Peopleware: Productive Projects and Teams

I bought this book because it’s highly rated by Joel Spolsky. It is a great book but I found it a bit dispiriting, in the same way that an owner of a beat up old banger might feel if a shiny new Porsche 911 parked next to them.

So there you have it, that’s a glimpse at my computer book addiction. I may not have actually read all that much of them, but I certainly enjoyed buying them and dipping into them. By the way, did I mention that I really like screencasts too…

A fortnight ago I flew to Edinburgh to attend Scotland on Rails. In spite of his best efforts, I managed to persuade my friend John Conners to come along too, so that he could find out why I’ve been nagging him to take a look at Ruby on Rails for years. Although John’s an experienced software developer with C++ and .NET under his belt, I thought he might find it interesting to learn more about a dynamic and purer OO language such as Ruby.

I’d only been to Edinburgh once before, on a day trip with my parents about twenty years ago and I’d forgotten what a beautiful city it is, albeit very cold in March! There’s lots of great architecture with wide streets and imposing buildings. It’s definitely worth a visit.

The conference itself was held over two days at the University of Edinburgh. John and I also attended a charity tutorial day, in aid of CHAS, a very worthy cause for which the conference raised over £7,000.

Day One

The speakers on the charity tutorial day were Chad Fowler and ex-Rails core team member Marcel Molina, both of whom donated their time for free. These guys are both big guns in the world of Ruby and Rails, so it was great to hear them speak. Although billed as an introduction to Ruby and Rails, it was actually mainly a talk about Ruby’s metaprogramming facilities, with demonstrations of some of the neat things Ruby lets you do. Chad and Marcel are great speakers—in spite of being jet-lagged—and had an engaging way of bouncing ideas off each other. I learned a lot from this day, particularly about Ruby’s binding and block mechanisms.

Day Two

The first day of the conference proper opened with a keynote from Marcel Molina, who explained that where previously he might have conveyed some expert knowledge of Rails itself, there are now so many resources available for getting that information that the only unique insight he could really offer was stories from the early days. So that’s what he did. We were regaled with tales from the genesis of Rails, illustrated with various postings that David Heinemeier Hansson made to the Ruby newsgroup as he learned Ruby and started to grow his framework. It was actually kind of fascinating to see how it all came about and to see the evolution of DHH’s abilities.

Next, we attended a very fast-paced talk from Scott Chacon about the Git version control system. This was mainly for John to realise that not only should he be using Rails, but he should also be using Git instead of Subversion (!) and Scott presented plenty of compelling arguments for doing so.

Rails core team member Yehuda Katz talked about the forthcoming Rails 3, which will bring with it a substantial refactoring of the framework so that it becomes more modular, more performant and incorporates the best ideas from Merb. It was interesting to compare the approach of not being afraid of breaking things in order to correct old wrongs with the Microsoft approach of maintaining backwards compatibility at all costs.

After lunch we went to a talk by Evan Light on Test Driven Development. Sadly, I found this talk to be content light and just didn’t get much from it. Maybe my mind was still on my lunch, but it just seemed to be a lot of stating the obvious.

Far better and more entertaining was Joseph Wilk’s presentation on using the Cucumber BDD testing framework, which lets you describe how your application should behave in plain text and execute tests against that description. Cucumber looks worthy of further investigation, I think.

Abdel A. Saleh gave a talk from the trenches about how the BBC use Rails for their Programme Information Tool (PIT), which provides programme metadata to their iPlayer software amongst other things. Abdel gave the impression that the whole thing is a bit of a nightmare because PIT has to integrate with lots of legacy applications and there’s little scope for doing the sorts of things that Rails is famous for being good at. In spite of this, there is a strong impetus from the people involved to continue to use Rails because they like it so much.

The last presentation of the day was perhaps the most interesting one. Scott Raymond spoke about his experiences of building PackRat, an intriguing card collecting and swapping game on Facebook. This was a talk jam-packed with detail about what it takes to build and run a Rails application with ~30,000 users that services about twelve million requests a day (hint: it all runs on Amazon’s infrastructure).

Day Three

The final day of Scotland on Rails opened with a keynote from Michael Feathers. This was a thought-provoking talk that looked at the evolution and dare I say it, maturation of the software industry and compared and contrasted the whole spectrum of different software communities that Michael has worked with, ranging from the Microsoft world to the open-source world.

After the keynote we went to hear Rory McCune tell us how to make Rails applications more secure. The good news is that Rails does quite a lot for you in this area out of the box. The bad news is that as application developers we still have to do some work ourselves. A good starting point on learning more about this subject is to read the OWASP Top 10 and Rory’s blog.

Jonathan Weiss gave a fairly dry presentation on deployment strategies and configurations for Rails applications. To be frank, I don’t really remember much else about that session!

A personal highlight was hearing the original Programatic Programmer Dave Thomas explain the Ruby object model. Although I’d already seen most of this material, I still got a lot from this session because Dave is an excellent speaker. It reinforced some important ideas about how Ruby is a true OO language in the Smalltalk tradition, whereas Java and C# are really Class-Oriented languages. I found it particularly interesting to see how many people in the room didn’t know that Simula 67 was the first object-oriented programming language and didn’t know who Alan Kay is and why he matters. Perhaps everyone was just shy.

The best two sessions of the final afternoon started with Cory Forsyth doing some serious image manipulation using Ruby. He demonstrated the amazing Seam Carving algorithm, also known as content-aware image resizing. I believe this is a major feature of the latest version of Photoshop and it was really quite interesting finding out more detail on how it actually works and watching the impressive demonstrations. John was in his element here, having come across a lot of these image manipulation techniques whilst developing John’s Background Switcher.

The biggest laughs of the conference came during the wrap-up session by Joe O’Brien and Rake author Jim Weirich. This took the form of a live code review…with a difference! Jim played the straight man who was undertaking the code review and Joe played the client with some awful code that used and abused Ruby’s metaprogramming power. It was a very cleverly constructed talk that was simultaneously hilarious and educational. Look out for it if the conference video is made available, you won’t regret it!

Scotland on Rails was a very enjoyable, interesting and useful conference, perhaps less intimidating and friendlier than last year’s RailsConf Europe, although I did have a great time in Berlin too. It was also a very well organised and run event and still a nice size, in spite of having approximately twice the number of attendees as last year’s event.

I’ve been writing Java code on and off for about nine years now. I started out writing simple Java applications as part of an Open University course and for the past few years I’ve been employed professionally to write user interface code using Apache Struts for an internal enterprise Java application that weighs in with about one million lines of code.

Increasingly I find myself subscribing to the You Ain’t Gonna Need It (YAGNI) philosophy. Maybe it’s as a result of learning Ruby on Rails, but nowadays I find that what I call the Big Up-Front Flexibility (BUFF) approach that characterises enterprise Java development rarely justifies the effort, at least in my experience. Which is not to say that you will never need the three things I’m going to write about, but you should carefully consider what value they add and think about pursuing alternatives where practicable. I feel confident stating that I could have done so within the codebase I work on with no short or long-term ill effects.

Reconfiguring XML Configuration Files

XML configuration files are the scourge of enterprise Java. In case you didn’t realise, the reason for their prevalence is that they’re supposed to let you change how your Java classes are wired together or how the routing works in your Web application without having to recompile or redeploy any code. I think the idea is that when the customer changes their requirements you make a quick edit to your XML glue, restart the application server and before you can say dependency injection pico container you’re in business! And you know what? I’ve never needed to do that, it’s simply a use case I’ve not come across.

However, I have suffered from having to write reams of XML boilerplate just to put the simplest Web application together. It’s something of a joke that enterprise Java programmers are “XML programmers” first and Java coders second. No wonder Ruby on Rails was like a breath of fresh air with its Convention over Configuration approach. The lesson here for Java’s architecture astronauts is that when building frameworks you should make the defaults cater for the 80% use case, not the 20%.

Too Much Indirection/Over Use Of Constants

Indirection is a powerful fundamental of computer science. It’s also beloved of the enterprise Java world, where instead of going from A to B your code has to go from A to a constant in B that refers to an XML element in D that names another XML element in E that refers to a Java class in F!

Struts 1.x is a great example of too much indirection (I can’t comment on Struts 2 as I haven’t used it and hope I never will). Your MVC controller code executes in an Action class and then returns an ActionForward that represents where to go next. You’re encouraged to hold the names of these forwards in a constants class, even though they’ll never change so you may as well just use a String.

The value in that constants class of ActionForward names is actually the name of an element in the Struts configuration XML file that maps to the path of a JSP that’s the view template for the actual screen the user eventually sees. It’s not that simple though, because you’re likely using Struts’ Tiles companion, which is a plug-in that provides view templating and introduces another XML configuration file into the mix.

Compare and constrast to Ruby on Rails, where by default and convention the controller method renders a view template that has a file name that’s the same as the method name and that’s it. You can of course override the template to use if you need to. Another example of how Rails got it right by catering for the majority case out of the box.

Something else I’ve seen encouraged a lot in the Struts books at least is defining another class of constants for the names of attributes stored by Action class code in the HTTP request or session for use by JSPs. Unfortunately this idea soon falls apart because you have to jump through hoops to use those same constants from within the JSP. Nowadays I just use a String and forget about it.

Getters And Setters

This is probably the most controversial and debated idiom of the three. If you’ve ever used Java then you’ve written code like this:

public class Account {
  private long balance;

  public long getBalance() {
    return this.balance;
  }

  public void setBalance(long balance) {
    this.balance = balance;
  }
}

The argument goes that rather than making the balance instance variable a public field, you should encapsulate access to it using the getter and setter methods, because if you ever need to change how the balance is calculated or stored then you can go right ahead and change it without affecting any code that uses the Account class.

That’s all well and good, but I can tell you now that in nine years I have never, ever needed to change the implementation of a getter or setter method and therefore the balance might as well just be public:

public class Account {
  public long balance;
}

I would estimate that 95.5% of the hundreds of getter and setter pairs that I (or my IDE!) must have written over the years have been simple instance variable reads or assignments as per the Account class example above. So why not just do away with the surrounding methods and save lots of code?

I’ve never particularly liked Java’s getter/setter approach because I think it makes classes dumb, because if you’re not careful they can just end up as data structures instead of proper OO classes with state and behaviour. There’s even a name for this pattern: the Data Transfer Object (DTO). I understand that they have this pattern in the .NET world too, but at least C# has a proper language construct for a dumb data holder with its struct type, not to mention a less verbose property mechanism than Java’s.

One caveat to this revelation is that I’ve always had control over the client code that uses my classes. If I were writing a framework or API for other people to use then I’d almost certainly use getters and setters, just to give me wiggle room to change the implementation in the future if required. Actually, I’d favour immutability and not have any setters at all if possible, preferring to use constructor arguments instead. The difference with this framework/API scenario is that once an interface is published in the public domain then it should be considered frozen forever. For everything else, just make the instance variable public or protected as appropriate. If you do need to add some logic around it then use your IDE to refactor how the instance variable is used. Eclipse or IntelliJ IDEA can handle this sort of thing with the minimum of fuss.

With the new year comes a new commitment from me to start practising Test-Driven Development (TDD) for my Rails’ projects. Up until this point I’ve usually put off writing tests until towards the end of my projects, which obviously doesn’t lead to some of the benefits that TDD brings, such as increased confidence during refactoring or a cleaner model API design.

Therefore it’s timely that John Nunemaker over at RailTips has just initiated Test Awareness Month and is blogging about how to go about testing Ruby on Rails applications. One thing that caught my eye in one of John’s examples is that he’s using the more readable BDD-style syntax for his test/unit examples i.e:

test "should test something" do
  ...assertion goes here
end

—instead of the old school way:

def test_should_test_something
   ...assertion goes here
end

For no particular reason I decided to dig into the Rails’ source code to see how this alternative syntax is implemented. I came across a wonderful 21 lines of code from Rails core member Jeremy Kemper that serves as a great example of the power and beauty of Ruby. Here’s the code (from activesupport/lib/active_support/testing/declarative.rb):

module ActiveSupport
  module Testing
    module Declarative
      # test "verify something" do
      #   ...
      # end
      def test(name, &block)
        test_name = "test_#{name.gsub(/\s+/,'_')}".to_sym
        defined = instance_method(test_name) rescue false
        raise "#{test_name} is already defined in #{self}" if defined
        if block_given?
          define_method(test_name, &block)
        else
          define_method(test_name) do
            flunk "No implementation provided for #{name}"
          end
        end
      end
    end
  end
end

This code adds a method named test to the Declarative module within ActiveSupport’s Testing module. Modules in Ruby let you share code between classes. They’re a bit like interfaces in Java or C#, except they can have implementation.

The test method accepts two parameters: the name of the test and a Ruby block containing the test implementation (everything between the do and end keywords in the example above). The test name is sanitized using a regex so that all spaces are replaced with underscores and then the to_sym method converts the name to a Ruby symbol, which is a sort of memory-light string that’s handy for identifying objects.

The method then checks to see if an instance method of the same name already exists, in which case it bails out by raising an exception. Finally, if a block was passed containing the test method implementation, then Ruby’s define_method method is invoked to dynamically create a method with the appropriate name and implementation. Otherwise, define_method is again used to create the test method, only this time the implementation is neatly set to flunk the test.

So in summary that’s a handful of lines of code that uses a little Ruby metaprogramming magic to support an alternative syntax for defining test methods by dynamically converting the new syntax to the old one behind the scenes. Good luck with doing that using Java!

Apple recently introduced Safari 3.2 via Mac OS X’s Software Update feature, somewhat surreptitiously adding a new anti-phishing feature in the process. The feature uses the same “Safe Browsing” Google technology as Firefox. Fortunately if—as I did—you find that it slows Safari down, then you can turn it off by visiting the Security tab of Safari’s preference pane and unchecking Warn when visiting a fraudulent website:

MacWorld have the full skinny on how the feature works. Be safe out there!



The Ford Ka is about to be replaced after an incredible twelve years in production. Incredible because to my eyes it still looks as fresh as the day it launched. Its New Edge styling was hard for a lot of people to stomach in 1996, but I think it’s aged rather well and the public must have agreed, for Ford have shifted lots and lots of them and have evidentally had a bit of a hard time replacing it.

I love the Ford Ka. It’s the quintessential brilliant modern small car. Its mechanicals are ordinary and like a lot of old Fords its engine is the weak spot—would you believe it can trace its heritage all the way back to the that used in the 1960s’ Ford Anglia! However, the Ka makes up for it with a great chassis and individual styling.

Consider for example the interior door panels. Like many inexpensive cars the Ka has painted metal on the interior side of its doors, but unlike some competitors it proudly draws attention to the fact by using the circle of the window winder space to cut into the metal and make an interesting shape.

Talking of styling, another reason to love the Ka is that its design looked to the future with all those bold, discordant feature lines that somehow managed to hang together as a cohesive whole. The original Beetle, Mini and Fiat 500 all looked to the future too, unlike their bloated, modern-day re-inventions.

The original Leyland Mini had weld seams on the outside to maximize the interior space, whereas today’s BMW Mini is bigger than an old Ford Escort, or put another way, punching about two classes above where it should be, both size and weight-wise. To be fair, at least some of that is down to modern safety legislation, but manufacturers could be cleverer too. Mercedes-Benz leads the way, as both the A-Class and Smart Car feature a twin floor arrangement that’s designed to swallow the engine in a frontal crash, allowing a bigger interior space for a given length.

Back to the Ka. Even the name is interesting and somewhat contentious: is it the Kar or the Kay-A? I’ve always gone for the former, but with a truncated pronounciation to rhyme with “Ha!”, which amusingly enough was probably a common reaction when first setting eyes upon one. The earlier variants with the grey plastic bumpers and starfish wheels are my favourites.

For me something of the design charm was lost with the later versions that have body-coloured bumpers and slightly flared wheel arches. The curve of the Ka’s bumpers is an important part of the design, so you do need that colour contrast. Those curves are also encoded in the typography of the Ka’s badge. You probably didn’t realise, but the cross-bar of the K is a deliberate echo of the Ka’s roofline and the leading curve of the A intentionally mirrors the curve of the back bumper as it sits above the rear wheel arch. Ingenious, eh?

The replacement Ka looks pretty funky at first glance, but lacks this sort of design integrity when you dig deeper. Essentially it’s a new Fiat 500 skinned to look like a smaller version of Ford’s brilliant new Fiesta. As an aside, I really wish that Ford had followed through from the concept car and used the Verve name for their new Fiesta, in recognition of it being a clean break from its boring predecessor. I guess the draw of the trusty Fiesta name was just too strong, but they did have the cojones to bin the Escort name when they pulled a similar move with the Focus in 1998.

You can see the 500 in the overall stance of the Nu-Ka (keyword: stubby) and in spite of Ford’s best efforts, the centre console is pure Fiat, with the gearlever sprouting from the dashboard rather than the floor. They’ve even managed to spoil the design of that lovely badge, making it look like a creepy-crawly version of the old one.

It’s a shame that with the Nu-Fiesta/Nu-Ka combination Ford have decided to return to the corporate design aesthetic practised in the eighties and early nineties that led to a manufacturers’ entire range looking like upsized or downsized versions of the same car. There was a big outcry in the motoring press about it back then and we got some interesting looking vehicles again, such as the Fiat Bravo/Brava and the Ford Ka and Puma. The zenith of this counter-reaction was undoubtedly the original Ford Focus, which was a complete volte face from the nadir of the crushingly dull, last-of-the-line Escort. Ford should recall that people buy a car, not a range of cars and inject some individuality back into each model within their range. Let’s hope that we’ve not seen the back of cars like the wonderfully original Ford Ka.

I’m in Berlin attending RailsConf Europe 2008. Today was the first day of the conference proper, following an optional day of tutorials yesterday. Following a welcome by Ruby guru David A. Black, the conference started with an hour-long keynote from Ruby on Rails creator David Heinemeier Hansson (DHH).

David Heinemeier Hansson photo credit: James Duncan Davidson

David used his keynote to explore the traditional ideas and attitudes towards legacy code. Continuing his long-running theme of optimizing programmer happiness, David went into some detail looking at why programmers feel unhappy about legacy applications and sometimes even trapped by them. The point is that the code itself doesn’t change; rather the programmer who wrote it does, because they have evolved and learned new things.

He put forward a compelling argument that actually any code that you write will inevitably become legacy code and that when looking back at old code we should not despair, but instead rejoice at how far our knowledge has progressed.

The most interesting part of the presentation was when DHH went into more detail with respect to the 37signals applications. He pointed out that by definition 37signals have the oldest Ruby on Rails application in the world i.e. Basecamp (the Rails framework was extracted from the Basecamp application).

Events took a practical turn when David fired up TextMate and showed us real examples of code in both Basecamp and Highrise that he calls garbage cans. He explained the factors and mistaken ideas that had led to the code going down that path and how he’d refactor it knowing what he does now. He was careful not to show us too much of the source code though! Kudos to him for showing us some of his crap code and proving that he is actually as infallible as the rest of us.

DHH is a confident and compelling public speaker and I really enjoyed his talk. I was fortunate enough to get to spend some time chatting to him this afternoon in the foyer, both as part of a small group and for a brief period individually. I asked David if he gets nervous before such talks, as he always appears very confident. He said that he does get a little nervous but finds that any nerves disappear once he gets going. He also said that he doesn’t rehearse his talks a great deal beforehand, preferring just to run through what he intends to say in his mind.

David Heinemeier Hansson photo credit: James Duncan Davidson

I found that for someone who’s often accused of being arrogant or worse, DHH is actually a really nice guy, who in spite of being jetlagged was genuinely friendly and interested in what others were doing. A personal highlight.

Following the keynote I went to an interesting talk by Matthew Deiters on minimizing network traffic through various caching and optimization techniques, followed by a session on the jQuery JavaScript framework by Yehuda Katz. I didn’t know much about jQuery before today, but like many Rails developers, I’m impressed by how powerful jQuery is given its small distribution size, particularly when compared with Prototype. Although I really enjoy using Prototype, I shall probably migrate to jQuery for future Rails projects. It definitely seems to be edging ahead of Prototype in terms of becoming the modern JavaScript framework of choice.

Juggernaut is an ingenious combination of an invisible Flash file and push server that you can add to a Rails application—it’s actually framework-agnostic—to give it pseudo-realtime capabilities. Alex MacCaw and Stuart Eccles illustrated this with a rather compelling Google Maps mashup, whereby session attendees dropped pushpins representing where they’d come from onto the map and everyone else could see them appear instantly. They also demonstrated a minimal chat application that uses the technology. This is one that I shall definitely be investigating further.

Jonathan Weiss gave a good run down on the top security issues facing Rails applications and how to fix them, although unfortunately he ran out of time at the end.

Following a fairly short talk from Nick Sieger about Sun Microsystems and JRuby, the closing keynote of today was by Jeremy Kemper, who spoke about his recent experiences of optimizing the performance of the 37signals applications. Although not an inspirational speaker like his colleague DHH, Jeremy has a likeable, almost casual speaking style and gave some good detailed tips on how to find and remove the performance bottlenecks within a Rails application. That wraps it up for today, just time to catch some sleep before tomorrow’s packed schedule!

The Peugeot 308 and “Glove” from The Beatles’ film “Yellow Submarine”:

I’ve been beta testing Jeff Atwood’s and Joel Spolsky’s latest venture, Stack Overflow. In case you haven’t heard, Stack Overflow is a new site where programmers can go to get their programming questions answered by other programmers. It’s a similar idea to sites like Expert Sexchange [sic], but without the pay wall and general crapness.

I really like what I’ve seen so far. I think Stack Overflow is very well put together and even during the current beta stage it’s pretty slick. The reputation and badges system whereby you gain points and virtual awards for the contributions you make, is fun and strangely addictive. Most importantly though, it’s already genuinely useful. However (and you knew this was coming), one aspect of the implementation of Stack Overflow troubles me somewhat: it appears the site is using numeric database IDs within URIs.

Note that I use URI rather than URL because one of the stated aims for Stack Overflow is that its content be readily indexable by search engines, so that people can enter their specific programming question into Google and hopefully amongst the top results should be the definitive answer on Stack Overflow. It’s known that Google does place importance on URIs, so you want them to be meaningful and immutable.

URIs in Stack Overflow look like this:

http://stackoverflow.com/questions/13204/why-doesnt-my-cron-job-work-properly

—As you can see, there’s a number, followed by a Google-friendly version of the question title, which is often called a “slug”.

It’s generally considered A Bad Idea to expose your database IDs in URIs and here are several reasons why:

• If you have to move the site to a different box, can you guarantee that those database IDs will remain the same?
• If you have to restore the site’s data from a backup, can you guarantee that those database IDs will remain the same?
• If you have to switch to a different database server (say from Microsoft SQL Server to Oracle), can you guarantee that those database IDs will remain the same?

If you answered “no” to any of the questions above, then you’ve broken a fundamental rule of URIs (permalinks), which is that they’re supposed to stay the same forever! Including database IDs exposes implementation detail to the world. It might give me an idea of how many questions or answers there are and I might feel inclined to start hacking around, putting different numbers in to see if anything interesting happens.

URIs should be meaningful, not cluttered with meaningless information. Another example of this is URIs that include pseudo file extensions. For example, .do (Struts) or .aspx (ASP.NET). Why should a site’s visitors care what technology it’s implemented in? Think about what information you’d want your URIs to divulge if you were able to look at them in a hundred year’s time and discard everything else. Keep them meaningful and clean.

I did question the use of database IDs using the Stack Overflow Feedback Forum and got the following official response:

“without the numeric ID, it’d be nearly impossible to map text to database IDs.”

Now unless I’m fundamentally misunderstanding a key part of how Stack Overflow is implemented—which is entirely possible for I have no access to the project team or source code—I find it difficult to understand this statement. Surely all that’s required is an indexed database column that stores the question slug that forms the end of the URI. The slug itself can easily be automatically generated when a new question is saved. Then you can simply retrieve a question by its slug. Using the ActiveRecord dynamic finders in Ruby on Rails it might look like this:

question = Question.find_by_slug params[:id]

—Now you have a fully-formed Question instance and you can go off and get its answers etc. Of course in production code you’d want to make sure that the incoming request parameter is trustworthy rather than passing it straight to the finder method, but that’s not the point of the example. The key point is that the slug in the URI is the key that’s used to get hold of your model object; everything can still be stitched together using numeric database IDs under the hood, just don’t expose that to your site’s visitors. Please don’t pollute your URIs with implementation specifics.

Continuing the “What’s In Your Wallet?” meme started by my good friend John Conners, here are the contents of my wallet at the time of writing:

• A credit card
• A debit card
• A cashpoint card that is actually obsolete because I can use the debit card for withdrawing cash, but my bank still send me a new one every few years
• A Citibank card that I think I have to use if I ring them up
• A bronze award blood donor card
• A Homebase loyalty card that I relunctantly accepted because it meant saving money on some kitchen furniture and which I never intend to use again
• A Hilton HHonors [sic] card that I’ll probably never use
• My National Insurance card
• An NHS European Health Insurance card
• A £1 BT Phonecard, valid until December 2002
• A list of “important telephone numbers” card from my bank
• £45 in cash
• A return train ticket to Newport, South Wales, purchased through work for my meeting tomorrow
• A dental appointment card reminding me that my next check-up is on the 2nd December 2008 at 4.30 PM
• A business card for a local taxi firm that I never use
• A receipt from South West Trains for the last train ticket to London Waterloo I purchased
• A £25 Next voucher from Christmas 2005
• A complementary Moo card given to me at the Future of Web Apps conference 2007
• A business card from the Financial Advisor who arranged my mortgage
• A piece of paper with a list of my relatives’ addresses on that I invariably look at on holiday when writing postcards
• A Tandem Ticket to The Caves of Nottingham/The Tales of Robin Hood, valid until 10 August 2000
• A “Beat Excess Stress” leaflet from my last job, kept because I thought it was hilarious
• A photocopy of my birth certificate that I probably used as proof of age to get into rubbish nightclubs
• An official poll card for the 1992 parliamentary election, that I probably used as back up proof of age
• A map of Norwich city centre from one of my earliest dates with my partner
• My front door key
• A key for my Kensington laptop lock
• A tiny key for one of those small suitcase padlocks that you could probably cut through using nothing more than a big pair of scissors

The wallet itself is a black leather one that I’ve had for as long as I can remember. It must be at least eighteen years old and I seem to recall it was a present. It’s only whilst writing this list that I’ve come to realise how much crap I carry around in it, but there’s something strangely reassuring about having a core set of items in there that never change!