I then noticed the date - turns out the article is only a few days old! Color me confused, could that article really have been written in 2009? I thought we had left the FUD-spreading behind us.

In an effort to educate Javier - and hopefully others - I decided to rewrite the Rails part of his article the way he would have written it had he had more knowledge and experience with Rails.

First order of business when creating a Rails application is to generate the basic structure. This sets up our directory structure, configuration file, and all the other goodness that makes it easy to find ones way around a Rails project:

$ rails cookbook2
      create  
      create  app/controllers
      ...
$ cd cookbook2

We need to store recipes and categories, so let’s create two models with their database tables. Since Javier doesn’t like passive code generation, I’ll try to limit that in this tutorial, hence I am using the model generator rather than the scaffold generator for this:

$ ./script/generate model Recipe category_id:integer title:string description:string instructions:text
$ ./script/generate model Category name:string
$ rake db:migrate

This creates our models and the relevant database tables with the specified fields. No SQL is required, no need to mess around in more or less usable database GUIs. We’re also getting the inklings of an eventual test suite created for us.

Controllers

At this point we need to create some controllers we can access through a browser. The easiest way - at least the way that’s easiest to describe in words - is to simply use the controller generator twice:

$ ./script/generate controller recipes
$ ./script/generate controller categories

This creates two controllers of 2 lines each - obviously trivial to do by hand. I’ll leave that as an exercise for the code generation wary reader.

The not so secret ingredient

It’s time to install the secret ingredient, which is what Javier really wanted to be comparing his project with. Streamlined is a framework (seems everything is these days?) that “… allows you to quickly generate useful user interfaces, declaratively”:

$ ./script/plugin install git://github.com/relevance/streamlined.git

In order to hook Streamlined properly into our application, a few files need to changed (we’re actually writing code now, for the first time). First, add one line to the Application Controller:

# app/controllers/application_controller.rb:
class ApplicationController < ActionController::Base
  ...
  layout 'streamlined'
  ...
end

Both the controllers we created before needs a single line added, increasing their line count by 50%!

# app/controllers/categories_controller.rb:
class CategoriesController < ApplicationController
  acts_as_streamlined
end

# app/controllers/recipes_controller.rb:
class RecipesController < ApplicationController
  acts_as_streamlined
end

The next step is optional, and you can skip it if you like navigating by changing the URL in the address bar of your browser. If you prefer navigation you can click on, add a single method to the ApplicationHelper:

# app/helpers/application_helper.rb:
module ApplicationHelper
  def streamlined_side_menus
    [
      ['Recipes', {:controller => 'recipes'}],
      ['Categories', {:controller => 'categories'}]
    ]
  end
end

Time to start our application and see how it looks

$ ./script/server

Wow, look at that. Note that you can filter the entries, sort the columns, export to a variety of formats, and pagination is built in. Looks almost production ready, doesn’t it?

Looking back, it looks like I wrote a massive 9 lines of code (3 if you skipped the optional step, 13 if you created the two controllers manually). No unused application code has been generated.

Little work, polished result indeed.

Adding a relationship

Let’s round this article off by refuting yet another false claim in Javiers article. To create a relationship - or association, as we call it in the Rails world - all you need to do is add a single line to your model:

# app/models/recipe.rb:
class Recipe < ActiveRecord::Base
  belongs_to :category
end

Now refresh the page for creating a new recipe. Voila, there’s a dropdown box for assigned categories to recipes. There is no need to write any HTML, restart the server, or recompile anything for that matter.

Conclusion

Interestingly enough, while Javiers article is filled with inaccuracies and is based on his lack of knowledge of Rails and its ecosystem, I don’t particularly disagree with his conclusion.

Rails does use passive code generation, and yes, if you want to extend or refine the generated code you have to actually edit it. You know, that sounds an awful lot like programming to me.

That said, I seriously disagree with the idea that productivity can be measured using contrived examples, and that a technology can be evaluated based on cursory knowledge gained from a 2 year old tutorial.

Lokalebasen allows realtors and other providers of offices, warehouses and production facilities to connect with companies looking for a location to buy or rent in Denmark. And so far, the site has been successful.

This is really a testament to agile and test driven development (well, actually BDD to be specific). It basically means Lokalebasen have been able to fund part of the development of the site with actual revenue from the site itself.

That sure beats waiting for income for a few more months while we perfect the site. A big win for releasing early, releasing often - and in particular for the client.

Thar be monsters in them woods

It quickly turns out that pretty much every email client renders HTML differently than the next. It’s sort of like cross-browser issues, but without the comfort of CSS hacks, conditional comments, UserAgent checking, and IE-specific stylesheets.

Instead, you find yourself facing more email clients than there are browsers, many used by enterprises that don’t mind running several year old versions of programs. Realistically speaking, it’s only feasible to have access to a fraction of those email clients.

Litmus

This is where Litmus, a web application for cross-browser testing enters the stage. While Litmus doesn’t magically make all email clients render HTML the same way, it allows you to at least see how your email appears in the most used email clients, ranging from Hotmail (remember that one?) over Mail.app to several versions of Outlook and Lotus Notes.

That’s all fine and dandy when you’re testing “static” emails, which are basically HTML files on your local machine. However, when your email is built dynamically in a web application and you’d like to see how it might appear to your users, it gets a bit tedious.

Sure, you can receive the emails yourself and forward them to your Litmus account. However, don’t expect the result to be representative of what your users will actually see. Your email client will probably do stuff to the email it received before fowarding it, so we need to cut the middleman (in this case, ourselves) out of the equation.

Rails, Github and plugins save the day

Litmus has a nifty little feature (hidden under “Extras”) that gives you a single email address you can send emails to and have them tested in the available email clients. Our task then became getting all emails from the application sent to the same email address.

We dug around, and ended up using the Sanitize Email plugin. That allowed us to configure our local machines to send all emails created in development environment directly to our Litmus account, while in test and production environments the application respectively doesn’t send emails and sends emails to their actual recipients.

We can then either use the development app as a user would and see the emails in Litmus, or we can trigger individual emails directly from the console.

About the Sanitize Email plugin

We did end up having to modify the plugin ever so slightly to have it work with our application, which is running Rails 2.2.3. Through the wonders of Git and GitHub forking, you can get the modified version at http://github.com/koppen/sanitize_email/tree/master.

Eternal bliss?

One thing that would make this workflow a lot better, is if we could somehow get Litmus to not create a new test for each email we send, but rather add new versions to an existing test of that same email. I imagine it might be possible by looking at just the email subject line.

While the above is not the perfect workflow, and the feedback cycle is still kinda slow (building screenshots for 27 email clients does take some time), it sure is nice to be able to actually see what ones users will see on their screens - without having to invest in superfluous software like Microsoft Office and Lotus Notes.

Back then, I pointed out that basing your designs on the width of the screen was pointless. Far from every visitor would actually use the full width of their screen for their browser - only 66% on average. The wider your screen, the less likely you were to maximize your browser.

Even though massive flatscreen monitors regularly appear in cereal boxes and as Kinder surprises these days, the reality isn’t much different from what it was 2 years ago; Make your designs wider than 800 pixels and expect a good chunk of your visitors to get a horizontal scrollbar.

Choosing a design width

When determining what width to give your design the primary goal must be that as many visitors as possible should be able to view the entire design without getting a horizontal scrollbar (scrolling horizontally is bad, mmkay).

The following chart shows the percentage of visitors that will not get a horizontal scrollbar for specific pixel widths. It also shows the figures from my 2006 study:

It’s interesting to note, that the available width has clearly increased since 2006. Back then, if you were to make your design 800 pixels wide, roughly 10% of your visitors would get a horizontal scrollbar. Today, that number is around 5%. It’s getting easier to justify going above the 800 pixels mark.

Another interesting thing to note is the two steep drop-off points occuring in both graphs after 1000 and 1250 pixels. Both of those correspond pretty well to a maximized browser in the two most widespread screen widths; 1024 and 1280 pixels.

The remnants of a drop-off is also visible right before the 800 pixel mark, but it’s almost not visible indicating that 800 pixels wide screens are becoming a thing of the past.

What does a smart designer do?

The above numbers are based on my statistics gathered from mentalized.net. A smart designer will obviously measure this on the actual site in question before making a desicion.

Unfortunately, many statistics packages still only provide the useless screen size metric instead of the useful viewport width one. Mint is still the only one I know of that tracks viewport widths - and that’s through a plugin pepper.

What does a lazy designer do?

If you’re stuck with a statistics package that doesn’t provide you with the figures you need to make a decision, you’ll have to settle for my advice - just like I did when designing the Substance Lab website (a rare case of me doing what I say, I admit).

Back in 2006 I recommended that you “optimize your designs for a width of 770 pixels while making sure they scale […] to 960 pixels”. Now, more than 2 years later, that recommendation hasn’t changed much, unfortunately.

With a design width of 770 pixels only 2% of your visitors should encounter the dreaded horizontal scrollbar. At 960 pixels, the number has climbed to 7% - that’s 1 in every 14th visitor.

Personally, I don’t see the value in optimizing for 2% of my visitors. I wouldn’t, however, be happy knowing that 7% of my visitors were getting a less than optimal experience. You have to decide for yourself - and for your customers - where your accepted cut-off point is.

My reaction was to cut down on my dayjob, leaving me with more time to focus on my own clients (and less time to focus on BiQ, forcing us to hire another developer).

However, it was only a matter of time before I’d run into that luxury problem again. Once again, having to turn down cool new projects due to lack of time left me with the same choice I took roughly a year ago. And once again, I decided to cut down on my dayjob.

Half a dayjob minus half a day job equals…?

Do the math and you’ll notice that it leaves me no time to work for BiQ. And you’d be correct. Starting this December, I will be a full time independent web application developer. I am super excited (and slightly scared) about this change.

If you have a great idea for a website, why don’t you drop me a line and we’ll talk about it - I love giving good ideas the execution they deserve.

What you get is a Rails Camp, and the above recipe was cooked with great success last weekend. Thomas Watson has a bunch of pictures from the event.

Retrospect

Like Chopmo I enjoyed meeting members of the still growing Ruby community I hadn’t met before.

Looking back at the event, I might as well add a few observations - probably mostly echoing Chopmos post.

Internet access

My biggest pet peeve before the actual event was the notion that everyone seemed so worried about not having internet for the two days. To me, that was part of the fun. In the end, though, we did indeed have Internet access at the cottage.

Luckily, it wasn’t a terribly fast connection, but it was bearable, and I must admit I liked the infusion of emails and IMs from the outside world. That said, I think we could easily have come better prepared (like having the *jour stuff installed and working) and have managed without internet just fine.

Geeks are introverts, even the Rails-kind

I am not sure how much the presence of an Internet connection contributed to this, but as geeks go, we spend a lot of time staring into our own laptop screen. I realize I am as guilty of this as the next guys, but just doing something by yourself is the path of least resistance, and you can do that at home. Rails Camp should shake up the old patterns.

Improvements?

Demos/presentations

I like the idea of scheduling things. Make everyone give a demo or presentations of sorts. Thing is, it doesn’t have to be Steve Jobs keynote quality - as Laust clearly proved ;) Demos are best as it can often be done without any preparation.

The main benefit of this is to drag people away from the screen and focus attention on something shared between the group. Perhaps do this every other hour for like 15 minutes.

Games

Okay, so I am a gamer, which obviously biases me in this direction. I do, however, think that having Guitar Hero or a Wii or something else present to drag people away from their laptops would be a good idea. Again, break the existing molds.

Shared projects

I luckily managed to -sucker-convince another person into working on the Bottleships project with me (I’ll post more about that eventually), which was awesome. I would have loved to see more people contributing, though, but so be it.

One way to perhaps achieve this, would be to take a Barcamp style approach to projects. Everyone writes their project idea somewhere, perhaps pitches it to the group, and then people vote on what project they’d prefer to work on/help with, and only the top projects are picked.

People whose project didn’t get picked should be encouraged to go to one of the other projects so noone is left sitting around for one self.

Don’t get me wrong

I had lots of fun, and I’ll definitely attend the next camp if possible. Thanks a lot to all who attended, and especially thanks to Henrik for getting it all organized.

2 hours to go

The time is getting close to midnight and my eyelids are getting to close to the floor - or so it feels. We’re done, there’s no way we can manage any more improvements.

The last hour we’ve been doing bugfixes by deleting the stuff that’s not working. When something is buggy with no time (or energy) to fix it, and you refuse to deploy low quality stuff, that’s the way to go about it. Oh well.

Rails Rumble 2008 is over for us, looking forward to going through all the apps - some of them are looking really amazing.

3.5 hours to go

Fatigue is definitely setting in now. We’re doing stupid mistakes and things aren’t moving nearly as quickly as it has been. But, we’ve been able to check off some of the items on the “nice to have” list, which is… well… nice. Looks like my ability to blog doesn’t increase the more tired I get, either.

Anyways, the site has been deployed, and we don’t want to risk doing anything major to it for the remainder of the contest - we’re bound to break something if we do.

So without further ado I give you Quotagious - the most awesome way to store and find quotes.

7 hours to go

Uh oh, less than a regular day of work left. Actually, a lot less as it’s highly unlikely we’ll stay awake until the deadline, it being at 2AM our time and tomorrow being a work day.

Funny how tons of small things crop up as we get closer to the deadline. Luckily we have the features we aimed for done. And they would’ve been deployed had it not been for the fact that something took the server down. Oh well, with no staging environment stuff like that happens.

Thomas has been working on Twitter integration for the last few hours. We didn’t want to be the only Rails Rumble app not hooked up to Twitter somehow… Performance optimizations and even more usability improvements have been my focus for the last few hours - our beta testers are ruthless, thanks guys :)

In related news, we’re now down to 99% Ruby code, 1% Javascript :(

12 hours to go

75% through the competition. So far I have been focused on usability and making the site look nice. Thomas has started on one of the fancier features, and my wife has been doing beta-testing for us.

Having someone outside the team look over the application is invaluable, even if done remotely. We’ve already implemented some changes, primarily in relation to wording and program flow in order to make it clearer what the application is and how it works.

The application is pretty solid, and we’ve added a “stable” tag to it. So if we end up messing it totally up the last twelve hours, at least we’ll have something to deploy. We’ve also started working purely in feature branches (yay Git) to lessen the risk that we end up deploying something half-implemented and broken.

Day 2 - 17 hours to go

Good morning, time to dive back into the code after a short nights sleep. Unfortunately, the more interesting stuff will have to wait, as the nights beta-testing revealed a few serious issues that needs to be fixed; primarily usability-wise. I have a feeling that we won’t get many favourable votes if people cannot sign up or log in.

26 hours to go

Yawn, tiredness is definitely setting in, but we’ve come a long way by now. The core functionality is working and seems solid - although I am sure it’s all an illusion that shatters the moment a real user gets involved. We’ve even got around to adding the majority of the UI theme.

UI-wise we had originally decided on just buying a stock theme somewhere, but we ended up doing it ourselves. I had some visual ideas I wanted to try out, and most the themes we could find in the short time we’d put aside for it, didn’t feel right and/or would need too much modification after the fact. So we’re rolling our now - support for IE6? Yeah, right.

For the last couple of hours we’ve been mainly doing minor stuff, none of us really feel like tackling the bigger ToDo items. Looking at the bright side, this means we’ve got a fairly complete’ish application now not even halfways through the competion.

The plan for tomorrow is to dig into the more interesting stuff; the features that move the application away from “meh, this is just a script/generate scaffold job” and into Championship belt status - or at least, that’s the plan.

The plan for right now: Sleeping.

32 hours to go

The first long workday (and then some) has passed - and we’re still going strong. However fatigue is becoming noticeable and I suspect we’ll be heading away from the computers to do something different very soon.

The application is really shaping up. We’re dealing with a bunch of fairly intricate edge cases we discover as we learn more about data model, and Test Driven Development is really helping us out here.

Our To Do list for today is growing thin, and it looks like we might be able to start working on polish and cool stuff already today.

37 hours to go

5 hours in, and we’ve started questioning our data model. It’s not even that it’s that complex. We’ve got 5 models, but it should probably be just 4. Too bad we can’t figure out if it’ll make things easier or harder cutting the one model.

Another thing we’ve been running into is the desire to make things too good. When you’re facing a 48 hour deadline you have to settle for good enough. There’s simply no time to go “Hrm, that URL doesn’t like exactly like I’d like it to, let’s just tweak it a liiiiiiittle bit…” - before you know it, you look at the clock and it’s an hour later.

42 hours to go

Due to the competition starting at 1AM our time we figured we’d be wiser to start the competition by sleeping, so by now we’ve only been at it for roughly 3 hours. Progress so far: Breakfast has been eaten, and a basic application skeleton has been deployed to our server, running a very, very, very basic version of our core functionality.

We’ve used Bort (as I am sure a ton of other teams has as well) as the base for the application, and I am sure we’ve have saved some time doing just that.

Next time around I’ll probably take a look at the base application before actually basing an application on it, though. Not that there has been any issues, but we did waste some time figuring out some Bort details. Luckily, it’s time to dig into the meat of the application now.

Luckily my co-worker, Laust Rud Jensen, had that same itch and decided to scratch it. Unfortunately he doesn’t have a website to post about these things, so I am posting it for him:

Laust speaks

Itch: specs are slow and RSpec progress feedback is either extremely verbose, or you have to wait for the full spec run to complete before you can see what failed.

Scratch: I’ve hacked together a new simple RSpec formatter called ImmediateFeedbackFormatter, with code based on the existing SpecdocFormatter.

My spec/spec.opts file now contains:
--require
spec/rspec_immediate_feedback_formatter.rb
--format
Spec::Runner::Formatter::ImmediateFeedbackFormatter
--colour
--loadby
mtime
--backtrace

The require and format options are needed to use the ImmediateFeedbackFormatter.

This new formatter will print full error details as soon as they are found. Successful or pending examples are written only as a dot in the output. Name of a spec group is only printed if errors occur within the group, so much less unnecessary output is generated.

Download it

For now, you can get the basic formatter here - hopefully it’ll sneak into RSpec proper or end up somewhere more accessible (and with tests and whatnot).

Install it by putting it somewhere in your project (spec/ for example), and require it in your spec.opts as shown above.

I’ve worked with Christopher, one of the founders, and the rest of the team for the last few years, going from a static website with just 5 pages to an increasingly complex Ruby on Rails application helping people make sense of their medical bills and providers.

These guys (and gals) are the real deal. They are in this to change healthcare for the better - publishing a free PDF book and getting on CNN are just a few of the steps on the way.

Congratulations.

Ah well, at least the Gates/Seinfeld episodes were somewhat amusing.