Ruby & Rails

Hendrik Mans - January 30, 2013

How I set up new Rails applications

Just in case you care – and you probably don’t – here’s a bunch of notes on how I set up new Rails applications. I’m posting this mostly to get my own perspective out and hopefully get some feedback from my peers. My peers, are you listening? Peers? Hello, peers? Oh well, here we go.

Initializing the new Rails app

Probably the least exciting part. This is how I initialize pretty much all of my Rails apps:

rails new appname -d mysql -T

The only thing worth noting here may be the -T flag, which is short for --skip-test-unit. I don’t really want to get into the whole RSpec vs. Test::Unit/MiniTest thing, but I am a heavy RSpec user and use it in pretty much every project, so by using this flag I’m making sure Rails doesn’t create Test::Unit stubs I’d have to manually remove later.

Also, yup, the rumors are true – I’m a heavy user of MySQL, and not Postgres like all the other kids. I’m kind of hoping I’ll get a chance to try Postgres with some project, but this hasn’t happened yet. It’s a difficult cycle to break; I’m very familiar with MySQL, so using MySQL mostly means speedy development, which I’m willing to accept in spite of all its supposed shortcomings. A lot of interesting things are happening right now in the Rails/Postgres world, so here’s hoping.

Disabling generators I don’t need

Out of the box, whenever you use rails generate to create stubs for models, controllers or resources, Rails will generate a whole bunch of extra files you may not really need, depending on the project and/or your personal development style.

Personally, I don’t need controller-specific helper classes, CoffeeScript files or Scss stubs, so I disable all that stuff:

1# ./config/application.rb
2config.generators.stylesheets = false
3config.generators.javascripts = false
4config.generators.helper      = false

Adding my favorite gems

Everybody has their favorite set of Rails gems. Here’s mine.

  • Slim, and I kind of hate myself for it. I hugely prefer Haml’s syntax over Slim’s. To most people, the difference is subtle (“Slim is better because you don’t need to type % all over the place”, yadda yadda), but after a couple of months of using it, it’s become clear to me that Slim’s syntax is, simply put, broken – for reasons I will happily detail in another blog post. So, why am I still using it? Because it’s faster. And by faster, I mean 10 times as fast as Haml. I love Haml so much, but it’s slow. I’ve spent some time profiling Haml, hoping to find an easy fix, but eventually realized you’d need to apply some major rewriting in order to get it to comparable performance levels. Yup, life is hard, and even with its out of whack syntax, Slim is good enough, so there you go.
  • simple_form. I love simple_form and can’t imagine working without it. Highly recommended. A lot of people also like Formtastic, but I haven’t used it yet so I can’t comment on it.
  • Compass. I love Sass/Scss, and Compass makes it ultra-powerful. Once again, can’t imagine working without it.
  • better_errors, a new kid on the scene. Replaces Rails’ awkward error pages with error pages that are made of pure awesome. They even include a Ruby shell you can use as an ad-hoc debugger. Very, very recommended.
  • quiet_assets, which will drop all asset requests from your development log file, making it much easier to read.
  • slodown for processing user input. It’s a rendering pipeline gem I recently extracted from, and it does all sorts of useful things including rendering Markdown, applying syntax highlighting to code blocks and more.
  • InheritedResources (or similar). I believe that RESTful controllers should be thin, and too much code in a RESTful controller is a code smell. You may think different, but that’s how I roll, suckers! Controllers should be stupid! Yeah! After years of using InheritedResources, I’m currently working on a gem called Resourcery which has a simple composition-based approach. It’s coming along nicely and should see a first proper release soon.
  • Allowance for authorization, my own personal take on CanCan with a focus on ActiveModel scopes. Just like Resourcery, it’s coming along nicely. I’m using it in all my projects, but if you want to stick with production-ready code, I recommend CanCan, which served as the inspiration for Allowance.
  • Finally, for testing, my weapons of choice are RSpec (of course), FactoryGirl and the beautiful Ffaker (for generating random data).

I absolutely recommend adding these to your Gemfile before you start generating models et al, since most of these gems hook into the Rails generators in some way or the other (remember to use the Rails bridge gems – rspec-rails will automatically generate specs, factory_girl_rails will automatically generate factories and so on.)

So much for how I get started with new Rails apps. I’m going to follow this up with a couple of posts on my favorite Rails development patterns, some of which you probably won’t find in books because, hey, it’s me. :)~


Developer dude from Hamburg, Germany. Among other things, runs Not good with descriptions. Don’t follow me on Twitter. ★

Loading comments...

Please sign in to post a comment.