casperfabricius.com

One dark evening in January around 30 geeks gathered at Podio for the monthly meetup in the Copenhagen Ruby Brigade. The only topic on the agenda was a grand showdown between code editors, but with such different editors as Emacs, Vim, Textmate 2, Chocolat, Sublime Text 2 and RubyMine in play, it was more than enough to cover an entire evening.

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.

Read the rest of this entry »

I’m glad to announce that I have been selected to speak at RuPy 2011 with a colleague of mine. RuPy is a conference in Poland about both Ruby and Python, and since we use both at Podio it seemed like a good conference to visit. Also we have yet to hire our first employee from Poland or any other East European country at Podio, so it could be a good chance for some networking.

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.

Inspired by a recent Railscast on Capybara, I decided to satisfy my holiday coding urges by looking into how Capybara might help us automate more testing at Podio. We are lucky enough to have a full time resource doing quality assurance, and we have often talked about how something like Selenium might help her automate a number of “sanity checks” that we could run before deployments. When I realized how well Capybara work with Selenium’s web driver, I had to investigate a bit more.

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.

Read the rest of this entry »