This is a story about the power of Rails.

It all started two days ago, when Seth Godin and Guy Kawasaki blogged about Appmakr.com. It allowed you to have an app in the Appstore based on your own RSS feed. The price they ask for this is $199,-

I believe that the appstore shouldn’t be polluted with RSS feeds. They should be websites instead of apps. Websites can have their own icon on the iPhone’s home screen.

With this in mind, I started to scaffold on my way back home. Commute by train is a bless.

The following gems were already installed:

• simple-rss
• recaptcha
• paperclip

I had used http://code.google.com/p/iui/ before.

Within two hours, http://iphonify.net/ was born. It allows anyone to claim their own url. For example, the iPhone version of this blog can be found at http://iphonify.net/ifdev.

If it weren’t for Rails - and the amazing plugins - I would have never been able to build this site that fast.

Last year we talked about pair programming with Obie Fernandez at Rails Underground. He was very enthusiastic about this practice, to the extent that the developers at his company Hashrocket, pair up full time. Inspired by this, we decided to try out pair programming ourselves. And we got quite excited about it too. So we chose to write a series of blog posts, or at least one, to spread the word and share our experiences. In this first post on this subject, we give a global introduction and we talk about our personal experiences with pair programming at Innovation Factory.

Pair programming is a software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer or navigator. The two programmers switch roles frequently.

While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.

Here are our experiences so far:

Martijn Lafeber: I really enjoyed pair programming. Especially because we’re working on several projects - it allows you to get familiar with new ones pretty fast. You get distracted less than when you would work on your own; it forces you to stay focused.

Sam Aaron: I think that the main benefit of pair programming is that it forces you to externally communicate your ideas and code with another. This makes it the best vehicle for sharing programming-level domain knowledge I’ve yet found. I also love the fact that it provides you with an opportunity to learn and share lots of small little tips and tricks that you don’t normally find the time to talk about.

Lukas Spee: I have experienced lots of benefits from pair programming. Two brains know more than one and two pairs of eyes see more than one pair. So you make better design decisions — which gives you more confidence — and you discover errors earlier on — which saves you time. Another nice thing is that knowledge sharing takes place on the spot, as you code. And perhaps most importantly: it’s way more fun than solo programming.

Sjoerd Andringa: To me the power of pair programming lies in keeping each other focused and continuous communication. If a pair isn’t talking all the time they’re probably not getting the maximum out of pair programming. Ongoing code reviews and knowledge sharing are key. However, pair programming also poses challenges. It can for instance be difficult to adapt the right role. When do you intervene? When do you ask questions? The perfect balance is different for every partner. Also staying focused all day (e.g. not letting your partner down by being distracted by things like email) requires a lot of energy. Be sure to take short breaks.