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.
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
The gotcha here is that the “trunk” version of the Capybara gem on Github should referenced in the gemfile for compatibility with RSpec 2.
I have just returned from a full week of work, socializing and excitement in San Francisco with my colleagues from Podio, leading up to official launch of Podio: The product is now open for everyone to try out, and a physical store is open in San Francisco where people can walk right in and get started with Podio. I don’t think anyone ever done something quite like to launch a software product, and it has generated a fair amount of PR with articles in TechCrunch, FastCompany, Inc. Magazine and Mashable just to mention a few.
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.
Everybody likes to do a bit of reflection by the turn of the year, so I’ll take the risk of posting yet another non-technical article to this weblog. Since I graduated from Copenhagen Business School 2,5 years ago I’ve been living out the dream of working full time with Ruby on Rails as a freelance developer. I been lucky enough to work with several entrepreneurs and be part of some very exiting projects from their very beginnings. I’ve learned that I’m quite good at getting a project from nothing to something, but that the real challenge is get it from something to Something Great. I’ve also learned that I enjoy development more when I have other developers to work with, and that a team effort yields better results of a higher quality than when I hack on something all by myself. What a surprise.
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?
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.
A few days ago a new Danish community for book lovers and consumers seeking the best book prices was launched: bog.nu (which translates to “book.now”.) The website has (of course) been implemented in Ruby on Rails during the last couple of months by Jesper Hvirring and yours truly for the Danish publisher Forlagsgruppen Bindslev.
On one level it can be used simply to compare the prices of one or more books at the leading Danish internet bookstores. The site allows the user to put several books on her virtual bookshelf, and then make a price search showing where she can get all the books cheapest in total, including shipping and handling.
On another level bog.nu collects all the latest reviews of new Danish books, and calculates a “meta score” from 0-100 based on all reviews. This allows users to rank their searches not just by typical parameters, but by how well they have been reviewed. This makes it easy to find, say, the best Danish comics.
Jakob Skjerning, Laust Rud and I has just finished the 48 hour coding marathon that is Rails Rumble. In just two days we have build a web based space trading game from scratch in Ruby on Rails called SpaceShippers. It’s online, it’s working and some even think it’s rather fun. Jakob live-blogged about it.
So why did three guys choose to spend their weekend hacking away at space game? Not because we expect fame, riches and the 1st prize in Rails Rumble, that’s for sure. Before the weekend, none of us had even checked what the competition prizes was. Not because it’s our only chance to code Ruby on Rails – all three of us do that in our professional working life every day. But all three of us are consultants, and we mostly code what other people want us to, not what we want to. And let’s be honest, inside every highly professional business programmer there’s a little game developer trying to get out. Computer games are great fun, and they don’t need fully fledged 3D environments to be good – although it often helps. We considered many other ideas, but I think we ended up during a game because we knew it would be motivating to build something to be entertaining, rather than just another tool or mash-up site.
I would never recommend a client to have login and registration in “pop-up” dialogs instead of plain pages, but sometimes clients choose to kindly ignore my well meant advise and ask me implement such things anyway. I’ve just finished version 1 of an upcoming web application implemented with Rails 3 and – of course – Devise for authentication, and this app just happens to have sign in and sign up taking place in dialogs (or overlays) and submitted to the server via AJAX. I expected this use of Devise to be pretty common use case, but the implementation turned out be pretty tricky.
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.