At the time I thought Chocolat might be the next big thing, but after only two rather frustrating days I went back to Textmate. I still had to present Chocolat at the meetup, but wasn’t able to say many nice things about it. I also showed off a few features in the Textmate 2 alpha such as multiple carets (uuh), but as Jesper Christiansen was quick to show us, Sublime Text 2 could easily match these. During the meetup I started to realize that Sublime Text seemed to be everything many of us had hoped for in Textmate 2, but in software that was available today in a polished, fully functional version, not a just a rather buggy alpha preview.

So I decided to dedicate last week to Sublime Text 2. I installed it Monday and purchased it Friday without looking back. And I’m still using it today. As a heavy user of Textmate for the past 6-7 years I felt right at home. ⌘+T brings up a file switcher that is slightly more clever and drastically faster than PeepOpen, and with that working I could start writing code straight away without feeling less productive than in Textmate. Speaking of the file switcher, I also really like that it instantly shows the file you highlight as a preview without actually opening it in a tab. This makes it easy to quickly browse around for the right file without opening a horde (a circus?) of tabs.

Other things that has already increased my productivity is the split view and auto completion. Textmate must be the last decent editor on the planet not to have split view, and now that I’ve started using it view and stylesheet, model and test and so on, I can’t believe I’ve lived without this feature for so long. I’ve printed out some useful shortcuts for Sublime Text and taped them to the side of my monitor, and it pays off to learn the shortcuts for managing and switching split views and tabs. Auto completion may not be that much better than Textmate’s for a language such as Ruby, but the fact alone that it displays suggestions all the time helps me remember that I can save some typing by pressing tab.

Of course Sublime Text 2 is not perfect out of the box, especially not when you are an old programmer that don’t want things to change too much too quickly. As friendly people where quick to point out to me on Twitter, the package manager is the first package you want to install, and the only one you want to install manually. It is also true that the default icon for Sublime Text does look a lot like the one for the Terminal, so I was quick to follow suit and replace it with a more distinctive one.

Essential packages includes SublimeLinter, ZenCoding and the Soda Theme, but coming from Textmate I also liked Textmate ERb style blocks, even though it’s not exactly perfect. Notice how I don’t link to those packages, since you just have to enter the name in the package manager to install them. All settings are managed through text files, and while that did seemed a bit primitive to me when I just encountered it, I quickly realized that it makes perfect sense for developers to manage their settings like this – as long as it is not XML files! Some helpful settings include trim_trailing_white_space_on_save, ensure_newline_at_eof_on_save, file_exclude_patterns and folder_exclude_patterns. A nice site effect of having settings in plain text files is that it’s easy to synchronize the settings between multiple computers using Dropbox. This guide explains how it’s done – it works beautifully.

If you haven’t tried out Sublime Text 2 yet I suggest you do so right now. If you’re a power user I’m sure you wouldn’t mind sharing a few tips in a comment.

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.

Taking this further, bog.nu even allows it users to review any book or title they have read. This is where the social aspect comes in. To being with, a user’s review score won’t change the total meta score much, but he gains more trust on the site his reviews can eventually grow to impact the meta score as much as the ones of the professional reviewers.

On a technical level I can tell that the site is fully PostgreSQL-based, including all search functionality. We evaluated the various tools available for full text indexing and searching, but we ended up simply using what’s build into Postgres, and we haven’t regretted that decision. I can also reveal that we crawl all prices live from the bookstore’s sites by running a separate, lightning-fast crawler application based on Cramp and Eventmachine. Tests are written in RSpec 2 with Factory Girl for fixtures and RR for stubbing and mocking.

If you like books – and you know Danish – you should definitely checkout bog.nu!

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.

The game still needs a work in terms of balance, usability, interaction between players and so on, but considering the limitations, I think it safe to say that we are all very pleased with the result. So how did we do it? What have we learned from our Rails Rumble?

First of all: Planning works. We have had a lot of meetings before the rumble, first deciding what to build and then preparing as much as we could: A flow chart of how the player would progress through the game screens. Mockups of all important screens. A database diagram, which we actually more or less stuck by. We spend quite some time on naming up front, and that meant no time wasted on philosophical naming discussions during the rumble. An overview of the central urls in the game and how they would map to controllers and actions. Central calculations needed for the game mechanics. And very importantly: A breakdown of all functionality into user stories.

Secondly: Agile is (of course) the way to go. Agile doesn’t mean chaos or changing everything all the time. Not at all. Quite the opposite in fact. We organized our two days into four sprints of about 6 hours each, not including eating and other breaks. We prioritized our backlog of user stories by assigning a business value between 1 and 13 (Fibonacci scale) and put the highest prioritized user stories into the first two sprints before the rumble. To last two sprints we planned Sunday morning, where we could take into consideration all the new user stories we had come up with during the first day. We made sure we had a working game after the first sprint, and that it was deployed after the second sprint, so server setup wouldn’t be a last minute thing. Also, with an early version online we were able to ask a few people to start playing and provide us with feedback.

In real life sprints are often 14 days long, starting each day with a standing status meeting (sometimes called a scrum). We decided to make each “working day” one hour long, and thus have a standing meeting once every hour. To emphasize this, we always had a big timer counting down to the meeting, and a another timer counting down to the final deadline. This helped us to stay focused and motivated. Even though we talked and helped each other all time – sitting in the same room and all – having a meeting once every hour was a great opportunity to report and reflect and make important decisions. I can help wonder how things would be if we had a 2-3 minutes meeting once every hour during a normal work day …

Thirdly: We build a working game without writing a single test. That’s kind of sad, because all of us a great fans of test-driven development in our professional work life. There were a few times where tests would have saved us a bit of time, but the fact is that the code base you can produce in two days doesn’t get large and old enough to make tests really important. Tests are critical for maintainability and as documentation, and if we chose to work on with the game we will pay price for having no tests later. But as it where, not writing tests did help us feeling a bit more “off-work” and productive during the rumble.

Last, but not least: As many others have said, having a dedicated designer/front-end developer during a Rails Rumble is essential. Even more when you build a game. Jakob was our designer, and I believe he didn’t write a single piece of “back-end” code. Okay, that’s not true, because he did make adjustments and fixed bugs during crunch time, but I don’t think he fully implemented any “back-end” stuff. That gave him the time that is needed to get a great design and front end implemented, and I think he rather enjoyed completely ignoring the existence of Internet Explorer and using all the newest HTML 5 and CSS 3 features. To be fair, Jakob was also our dedicated system administrator – he setup the server and wrote the deployment script, and that all just worked. It’s a funny mix, but I think all Rails Rumble projects needs to have a person assigned to both design and system administration, although the last thing shouldn’t take up all that person’s time.

On the technical side, I learned a bit more about Git from Laust (you can never too much about Git , and we were quite happy using Janrain Engage and the SpaceShippers is recieved by the Rails Rumble judges, but several people I know (including myself) has already had great fun playing the game, and that makes it all worthwhile.

Devise is a pretty amazing authentication system. It’s modular, flexible, highly configurable and lots of extensions have already been built. It does, however, make the assumption that you want to redirect the user to a new page after he has been authenticated. When sign in takes place in a dialog that is submitted via AJAX, a redirect to the frontpage or somewhere else is not of much use. In this case we need to respond with a javascript snippet that either makes a client-side redirect, or – better yet – simply closes the sign in dialog and updates any elements on the page that depends on sign in status.

For this particular web application, the scenario was even more complicated. When an unauthenticated user wanted to comment on something, the sign in box would have to pop up in a dialog. If the user wasn’t registered with the site, he could click a link to get the sign up shown – still in the same dialog. Whether the user registered or just signed in, the dialog should finally display the form for writing a new comment. All this would have to take place through AJAX without the actual page location ever changing, and here is how I implemented it.

Devise relies on Warden for the actual bread-and-butter authentication, and Warden operates purely at the Rack level without knowing anything about your Rails app as such. When Warden encounters a user that is not signed in on a page where he was supposed to be, it will invoke a failure app: A small rack application that decides what to do with unauthenticated users. A core part of Devise is the Devise::FailureApp, which generally stores where the user wanted to go and then redirects to the sign in page. Not so for an AJAX request – or or believe the more correct term is XHR request. In this case, Devise returns a HTTP basic authentication pop-up – yikes! This even happens when http authentication has been disabled by putting config.http_authenticatable = false in config/initializers/devise.rb. Usually, we don’t want our users to get this ugly basic authentication box, so first step is to build a custom failure app that ensures that http authentication never happens through Devise:

We configure Warden to use this failure app in the devise initializer:

The observant reader will have noticed that the redirect_url method is also overridden in CustomFailure. This is necessary because Devise doesn’t pass on the format of the original request when it redirects, and we need to know in subsequent requests that we are dealing with an XHR request so we can render javascript in response rather than HTML.

That’s pretty neat so far. However, Devise is still redirecting when the user has authenticated, rather than responding with javascript to close the dialog and update the page. So we need to control what happens after a successful authentication, and that can only be done by overriding the sign_in_and_redirect method of the Devise’s SessionsController and RegistrationController. We do this by creating our own set of controllers in app/controllers/sessions_controller.rb and app/controllers/registrations_controller.rb. Our new SessionsController looks something like this:

I’ve got to admit that this is not exactly the prettiest Ruby code I have written, but I’ll leave it as an exercise to the reader to write a beautiful regular expression that can replace lines 10-12. The first couple of lines are unfortunately duplication of the original method, but the information is needed further down. If the action is invoked with an XHR request, the method takes any redirect url (the page the user originally wanted to go to) stored by Devise and makes sure that it’s called with the “js” format. Further it adds an after_authentication=true query string which was needed in this case, because the redirect was going to the CommentsController, which needed to know that it should close the sign in dialog before proceeding with displaying the comment dialog.

If there is no stored url to redirect to, we simply render the after_authentication partial, which in my case closes the sign in dialog and updates the page to indicate that the user has been logged in. If the action is invoked as a standard HTML call, the method simply redirects to super, so that we can still sign in the old fashioned way. Since I needed exactly the same code in my RegistrationsController, I put the method in a module and included that in both of the controllers. You might want to do that too.

The final missing piece is to configure Devise to use our new custom controllers rather than the built-in ones. We do that in routes.rb by means of Devise’s controller options:

Even though I’m not a big supporter of AJAX sign up and sign up – or of much use AJAX anywhere where a standard page refresh makes just as much sense – I must admit that the result was a pretty nice user experience in this case. I hope that Devise gains better support for rendering a response rather than redirecting. Until then, you can use this method.

• The endpoint for federated OpenID login for Google Apps is https://www.google.com/accounts/o8/site-xrds?hd=[myappsdomain.com].
• For the Ruby OpenID gem to play nicely with Google Apps, Google’s own extension gem for this purpose must be loaded and required with require 'gapps_openid'.

The story

I’ve been working on a client project consolidating most of their various internal databases, spreadsheets and ad-hoc lists into a coherent and centralized web application – employee lists, inventory and so on. Early on the client said to me: “Since we are using Google Apps for email, calendar, document sharing and pretty anything else it can do, it would be really nice if we could simply login to the application you are building using our Google Apps logins.” I said: “Sure, how hard can it be?” It was a fair request that made a lot of sense. After all, everybody hates another login to remember, so wouldn’t it be nice if the employees was simply – “as by magic” – instantly signed in to this new application?

I knew a lot of people was doing sign in with ordinary Google accounts. I had also implemented it myself for darebusters, although the easy way using the very nice RPX solution from JanRain. I could see that I could integrate with Google Apps using both OpenID and OAuth. I had some vague ideas about OAuth being “newer” and “cooler” than OpenID, and also I was using Warden and Devise for authentication, for which a nice OAuth extension existed, so I set out to authenticate against Google Apps with OAuth.

Big mistake: OAuth stands for Open Authorization, not Open Authentication. It says so, right there in the big green box. OAuth is not well suited for authentication, because the standard dictates that new security tokens are generated for every request. The OAuth extension for Warden comes with a nice example for Twitter and my guess is that this works fine. Twitter apparently doesn’t follow this aspect of the OAuth standard and allows the same security tokens to be used over and over again. This in turn makes it possible to save these tokens in a local database and use them for subsequent authentications without asking the user to sign in again. Not so for Google.

But that’s what I thought, and so I went ahead and implemented OAuth authentication using the extension for Warden. This was quite a pain to implement, as you mostly get HTTP errors without much detail back when you don’t do things exactly right. Remember that I didn’t know that OAuth is not meant for authentication and I was a bit confused as to how I went ahead and simply asked if the user was signed in. I ended up with a solution where I asked Google’s API for the user’s email address, since I in turn needed the email to identify the user in my own application. My working implementation was something on the lines of this, a mechanism that would in fact be very useful if I needed authorization to grab some data from the user’s Google account. If you want to go down this road, here is a few useful links.

I must admit I only realized my error when I tried out the implementation thinking as a user. I started asking my self why I had to choose a Google account and authorize the application to retrieve my email every single time I signed in. That was not how this fancy single sign-on thing was supposed to work. That’s when I took the time to read the aforementioned green box, and Google’s explanation of when to OAuth and when to use OpenID. So back to square one: I needed Google Apps authentication, and now I knew that OpenID was the way to go. From there it was it was easy to find the devise_openid_authenticatable gem which adds OpenID support to Devise in the same nice and modular fashion we have come to expect from this great authentication library. Everything is very nicely explained in the readme – that is, assuming you want to sign in using a “normal” OpenID service such as Google Accounts. To make it work with Google Apps, however, there are two minor snags to overcome – plus an annoyance that can be easily solved:

The OpenID sign in process starts by submitting an identity url to Devise as explained in the readme. For applications offering any OpenID account to authenticate, this identity is left to the user to enter. In this case, however, I wanted a big shiny “Google”-button that took the user directly to Google Apps authentication. Easily done by putting the identity_url in a hidden field, but what to use as an identity url (or end point, which was really the case here) for Google Apps – specifically, what to use to allow only login for the client’s specific Google Apps domain? A lot of searching – so much that unfortunately can’t point to the exact place I found this viable piece of information – gave me the solution: https://www.google.com/accounts/o8/site-xrds?hd=[myappsdomain.com].

Next problem: Ruby OpenID was acting all up, throwing errors and telling me that it couldn’t authenticate http://myappsdomain.com/openid?id=100664348167999321563. Huh, no wonder. There was no OpenID server running on my client’s domain. Google was doing that for us. Long story short, Ruby OpenID expects the user’s identity url and the end point for authenticating the user to match. I believe they do so on most OpenID services – it makes a lot of sense – but not so on Google’s. Luckily Google has created a gem that patches Ruby OpenID to handle this specific scenario: Apps Discovery. As soon as I installed this gem and required it in my application.rb (it was a Rails 3 app, it would be environment.rb in a Rails 2.x app) with require 'gapps_openid', things started working. Yay!

Since Devise requires an email to create a user, I couldn’t use the create_from_identity_url method suggested in the devise_openid_authenticatable readme for creating new users. Rather, I needed to initialize the user here, and then only create him or her later when I also had the email. This gist shows how I did it.

And the annoyance? Well, since Google’s OpenID server runs https, you get a lot of warnings from the OpenID library about missing a certificate for ensuring the security of the connection. One way to solve this it to copy the certificate bundle from Google’s gem into, say, /config/certs/ and then configure OpenID to use it: OpenID.fetcher.ca_file = "#{Rails.root}/config/certs/ca-bundle.crt".

I also use DJ to send out emails, and a typical asynchronous call sending a message from one user to another – scheduling a delayed job – used to look like this:

UserMailer.send_later(
  :deliver_message,
   @recipient,
  current_user,
  params[:message]
)

Since darebusters.com is an internationalized website currently offering users the choice between English and German, this has proved a slight challenge, however. We have the usual internationalization (i18n) bells and whistles: Flags to select the language, and remembering the user’s language selection in session, cookie and in the users database table. By default, a delayed job will simply run with the default locale of the site. It has no way of accessing the context it was invoked in, so it cannot set the locale from session or cookie. The job only knows what it can work it from the arguments it was created with.

It looks like an easy problem to solve. DJ shouldn’t have to know about locales, the code should just set I18n.locale from @recipient.locale. That’s exactly how I initially thought I had solved it: In the UserMailer.message method I set the locale, and then passed parameters to render the mail. The catch is, however, that I use a slight hack to get support for localized ActionMailer templates, i.e. when the locale is set to de it will render the message.de.text.plain.erb view rather than the message.en.text.plain.erb view. The template to render is selected before UserMailer.message is invoked, so at that time it’s too late to set the correct locale. In fact, I needed the entire job to run in a locale specified when the job as scheduled.

For this purpose, I created a custom delayed method to be invoked by DJ: LocalizedJob.

This code should be placed in /lib/. I want the send_later_with_i18n to be available on all objects just like DJ’s own send_later, so I also also created an initializer to extend the Object class:

This code should be placed in /config/initializers/. I am now able to replace all my send_later calls with send_later_with_i18n calls, storing the required locale with job to be extracted when it’s run:

UserMailer.send_later_with_i18n(
  :deliver_message,
  @recipient.locale,
  @recipient,
  current_user,
  params[:message]
)

So on darebusters.com, Germans get all their mails in German – no matter what locale the sender used (although the actual message written by the sender is of course not translated – and everyone else gets mails in English. Now that was a real Ruby fairytale.

Bundler (Github | Website) is the new way to manage gem dependencies in Rails and other Ruby applications. If you haven’t heard about it, there is (of course) a great introduction at Railcasts. It’s pretty easy and straight-forward to use, especially if you are used to the config.gem format of Rails.

However, one very common use case in Bundler’s Gemfile that is not explicitly documented anywhere I’ve seen, is how to configure gems to be installed in both development and test environments, but not in staging and production environments. You have probably seen the examples of how you can assign a gem to a specific environment using the :group option or method. So you’d probably write something like this:

group :test do
  gem "rspec-rails", ">= 2.0.0.beta.1"
end

group :development do
  gem "ruby-debug"
end

The gems you don’t need on the server are usually all those related to testing, debugging and perhaps generating fake data and so on. But wait a minute. You also need the RSpec in the development environment so you can use it’s generators, right? And you need Ruby Debug in the test environment so you can put breakpoints in your tests.

Luckily there is a very easy, and – once you know it – obvious solution to this: You can pass multiple environments to the group method, just like this:

group :development, :test do
  gem "rspec-rails", ">= 2.0.0.beta.1"
  gem "ruby-debug"
end

And that's probably the only grouping of gems you'll need in many Rails projects. Most gems installed and required in all environments, and a few just in the development and test environments. Happy Rails 3 coding.

Community Day in Copenhagen is back again this year, so reserve May 27 if you are near Copenhagen and like free tech-talks, networking and beer. This year Daniel Frost, the Microsoft evangelist that makes it happen, has involved me and several other developers actively in the planning of the day. With CD ’10 we have raised the level of ambition – bigger venue, more people, more talks and if course more fun.

We will have 20 sessions distributed on four concurrent tracks covering a surprisingly wide number of topics – very few of the talks are on Microsoft-technologies, in fact so few that we might loose a few of those .NET consultants who thinks anything non-MS are not worth listening to Still, if you are doing anything at all related to the web (and most of us are, right?) you will surely find topics such as HTML 5, Single Sign On, Azure, Advanced jQuery etc. interesting.

I will be giving a talk with the rather bold title “Replace ASP.NET with IronRuby on Rails”. It will give me an excuse to seriously dive into IronRuby and how to make a Rails site talk fluently with .NET libraries and assemblies. Coming from a serious amount of ASP.NET development myself, I really think a lot of web-based .NET projects could benefit from Ruby on Rails. The only time I was really happy with ASP.NET was when I switched to that from classic ASP – but since then, it hasn’t evolved that much. Granted, ASP.NET MVC has rescued developers from the annyoing “webform” structure, but it still has a long way to go.

I’m getting ahead of myself here, come watch the session – sign up for Community Day ’10 now!

For me, the situation is like this: My standard version of Ruby on my development machine is 1.8.7. I deploy to many different environments, some (the ones I have a degree of control over) runs 1.8.7 and others (such as Heroku and some customer’s servers) runs 1.8.6. I can test and code away happily only to get some ugly exceptions when I deploy because I have called count on an array instead of length. Further, I also want to play with the new features of Ruby 1.9 and run Rails 3 on it. And that’s not to mention that I also use alternative Ruby implementations such as JRuby for projects where I need to tap into Java libraries.

So that’s at least four different versions and implementations of Ruby I want to use at various times. I need to compile gems separately for each of them, and I don’t want them to clutter up my default and very functional Ruby 1.8.7 installation which I still use most of the time.

Ruby Version Manager (rvm) to the rescue! This very welcome open source project allows us to easily install, manage and switch between multiple Ruby versions and implementations with a single command. The software itself is also easy to install:

sudo gem install rvm
rvm-install

Once you have followed the instructions and pasted the line of script into the correct file and restarted (or sourced) your shell, I recommend that you upgrade to the edge version of rvm by running this command:

rvm update --head

This gives you access to the newest versions of the installation scripts, and that is needed if you for instance want to install JRuby:

rvm install jruby
rvm jruby

That second line is all you need to switch between ruby implementations – here we switch to JRuby. Note that this is not a system-wide change – the switch is done simply by changing a few environment variables in your current shell so ruby, rake and so on now refers to the JRuby versions.

One gotcha is that gem will installed the wrong place if you have the —user-install flag in your .gemrc file. The only current resolution I know is to remove the flag.

Never the less, I will highly recommend that you install Ruby Version Manager and play with different Ruby version and implementations – it has never been easier.

Enjoy the new decade – take care of our world.