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.

The talk is titled “Dogfood your API” and is about the Podio API and how our entire web application is based on the API, never making a single direct database call. The API is written in Python and the web app in Ruby in Rails, so we will be able to touch upon both languages and frameworks in our talk.

I’ll be presenting with Christian Holm, the lead developer of Podio and main developer of the API. He will explain the evolvement of the API and some of the decisions made along the way, whereas I will talk mainly about the Ruby API client and something we call ActivePodio, which is an attempt to get interacting with a RESTful API to feel a bit like using ActiveRecord.

The talk is in Poznan, Poland on October 14th. If you can’t make it there, but are near Copenhagen, you can also see our rehearsal of the talk at the Copenhagen Ruby Brigade meeting on October 10th.

Podio is currently a mix of PHP and Rails (talking to a Python-driven API), and these automated tests of course had to work independently of whether a certain page was in PHP or Rails. Also it would be nice if our QA didn’t have to have the sites running locally to run the tests. These things ruled out running Capybara inside the Rails application, so I opted for making a seperate, Ruby-only test-suite for automated QA running against our staging server. There is a ton of challenges in this that I haven’t fully solved yet, most importantly how to manage test data on a separate server. This article only outlines how to get a simple Ruby application (without Rails) up and running that can test a remote site.

First step is to install the bundler gem, create a Gemfile in the root of the application and run the bundle command:

The gotcha here is that the “trunk” version of the Capybara gem on Github should referenced in the gemfile for compatibility with RSpec 2.

Second step is to setup a spec_helper.rb file. I created a spec folder in my application directory and put it there:

I have some things in my spec helper you might not want: In line 6 I require all files in spec/factories. This is where I put method for generating test data. This has to be done “by hand” through Capybara as I am testing against a remote server. In line 10 I configure Capybara to save page snapshots in a directory called snapsshots so I can git ignore the files Capybara generates when using the save_and_open_page method. In lines 20-27 I configure RSpec to open a snapshot of the current page if an exception is raised during a test.

Lastly I place the actual specs within the spec/requests directory, following the RSpec naming conventions for this type of tests:

One important gotcha here is that the describe block must be followed by the :type => :request option to trigger Capybara. It’s only within Rails that this type is automatically set for all specs in the requests directory.

What I have now is still very far from the holy grail of automated testing from a user perspective, but it feels like a step in the right direction. If we decide to pursue a setup like this on Podio I’ll most likely do another blog to follow this one up. If not – and there unfortunately many things making tests like these very brittle and hard to maintain – the quest for more and better automated tests continues :)

I joined the Podio team just three months ago, and leading up to this launch we have been working our asses off to provide a top-quality product to make a serious impact on the U.S. market and the rest of the world. The culmination of all this hard work was this launch week in San Francisco and of course the launch party Thursday which more than 300 people showed up for. There is plenty of photos from the week on the Podio account on Flickr.

Bearing that in mind it might seem an obvious choice now, but I wasn’t at all considering becoming a full time employee when the opportunity of Podio showed itself little more than a month ago. I was not headhunted by Podio, although I would have liked to say that I was. Rather I was asked by them if I knew any Ruby developers that might be interested in applying for a position and that peaked my curiosity. Podio went out of stealth mode in the summer of 2010 and generated a fair amount of hype boasting both high ambitions and leading employees with a proven track record. But technically it was quite uninteresting to us Ruby-worshippers, as it was written in PHP using the Drupal platform. So why was Podio suddenly seeking Ruby-developers?

Podio is a social work platform that allows users to build their own data structures, workflows and reports. Some call it Facebook for companies, other call it yet another project management tool. You can use it for both of those purposes if you like – but you can also use it in a complete different way. This is how Podio really differentiates itself from competitors such as Basecamp and Highrise, which are great tools for project management and CRM but works only like 37signals thinks they should – take it or leave it. In truth I am still struggling with explaining Podio, but if you try it you will see what I mean.

It turned out that Podio had decided to ditch PHP and Drupal and had already rewritten the entire backend to Python. The next step was to rewrite the entire frontend to Ruby on Rails and that challenge was too exiting for me to resist. So I can now count myself amongst the lucky few in Podio’s development team and employee no. 15 in the company. I look forward to learn a lot from new colleges, put a lot of hard work into the product and help make Podio realize its full potential as a platform built in Ruby/Python right here in Copenhagen.

Happy New Year!

Each year around Christmas and New Years I like to find the time to combine my interests in music and video into some sort of of greeting. This year it seems my interest in Apple’s products has also played a key part ;)

I wish you all a very merry Christmas and a happy New Year.

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.

Events in jQuery works just like you would expect. You can subscribe to events and you can trigger events. Triggering custom events is not something that javascript natively supports, and for that reason it is easy to overlook that jQuery actually makes this very easy. This is a more complex example, and this explains jQuery a bit more visually.

But back to how I used event-driven javascript to sort out the list page on Lokalebasen.dk. First I defined to javascript “classes” representing the two central business entities of the page: Location and PostalDistrict. I’m not really sure this is best way to define “classes” in javascript (I think there’s a more “jQuery” way of doing it), but here’s some of the Location definition:

The PostalDistrict “class” was declared in much the same way. Then I went on to define managers for each UI component on the page:

Each manager was responsible for binding to the user-driven events of its UI component (clicks, keypress, etc.) and of triggering appropriate “abstract” events as a result. The Postal District Manager, for instance, would bind to the click event of each check box, and when a new postal district was selected it would load the new locations in the district into a global client-side collection of locations, update it’s own UI component and trigger a global event: $(document).trigger('postal_districts.filterChanged');. All the other managers would in turn be subscribing to this event, since, when new locations are added, the both map and table must be updated to show them, and size and price filters must recalculate number of locations available in each interval.

Another example is that the location must be highlighted on the map when the cursor hovers over the location’s row in the table, and visa versa. So the Map Manager subscribes to the events “table.rowMouseOver” and “table.rowMouseOut”, and the Table Manager subcribes to “map.markerMouseOver” and “map.markerMouseOut”.

To bind it all together, I created a Locations Manager which was responsible for instantiating the other managers and for handling the overall state of the locations. This manager figures out which locations are currently visible by asking the different filter managers about their state, and it also reports the actions of the user back to the server for tracking purposes.

As you have probably realized, a seemingly rather simple list page with a map and some filters can result in a rather complex system of interactions and dependencies between various UI components. The publish/subscribe pattern has been used by most desktop applications for decades, and as our web applications grow to be more complex we will have adopt and rediscover more of these mature, yet still incredibly useful patterns.

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.