Patterns in a Rails Gemfile

programming, rails, ruby

Rails Rumble

The 2013 Rails Rumble concluded last week and like in previous years, Dwellable analyzed the Gemfiles of the submitted projects.

While it’s not an indication of the only gems used in the Ruby community, it’s a pretty good summary of the most common needs in a typical Rails app.

  • The majority of the projects used Rails defaults of Coffeescript, Sass, jQuery, and ERB

  • Only 37% of the projects used Bootstrap. I thought this number would be higher. It feels like every MVP out there starts with bootstrap.

  • Only 33% used HAML. I thought this number would be higher as well. I’m not a huge fan of HAML, but it seems like it’s the default templating language for most Rails developers I’ve worked with.

  • Around 1/3 of the projects turned off Turbolinks. I’ve spent a little bit of time using Turbolinks and while I’m not opposed to it, there are a handful of common practices that I was used to that didn’t work with Turbolinks. I suspect this was the case for many teams and just chose to turn it off out of frustration or interest in making progress elsewhere. I’ve definitely done this in the past when I just wanted to get something out the door.

  • Usage of MySQL and Postgres was even. This, to me, is great news. The more Postgres is used in the community, the more available it will be hosting services (Heroku has done a great job promoting the usage of Postgres).

  • Javascript front-end frameworks were barely used. 7% is a pretty small number. Part of me believes this number would’ve been larger if the teams had more time to devote to development, but with many people believing JS is the future of the web, I’m still surprised more projects weren’t largely JS-based. With the 1.0 release of Ember.js behind us, perhaps next year will support a continuing movement towards these types of frameworks.

  • Sidekiq was the overwhelming favorite for background jobs! I love Sidekiq (full disclaimer: I’m a contributor), but I thought usage of Resque would be closer to that of Sidekiq.

My Gemfiles

Most developers have a handful of gems that they rely on during development. This got me thinking about the gems that I most commonly used in my own projects.

I tend to write a lot of small apps, so I create new Rails projects all the time. The first hour is always spent setting up the project with the gems I’m most familiar with. I know there are some tools that could make this process easier (Rails templates and AppScrolls ), but I haven’t spent the time to implement them in to my workflow.

Below is the Gemfile of an app I recently started:

Gemfile
source 'https://rubygems.org'

ruby '2.0.0'
gem 'rails', '4.0.1'

group :production do
  gem 'pg'
  gem 'rails_12factor'
end

group :test do
  gem 'factory_girl_rails'
  gem 'capybara'
  gem 'selenium-webdriver'
  gem 'database_cleaner'
  gem 'shoulda-matchers'
end

group :development do
  gem 'quiet_assets'
  gem 'rails_best_practices'
  gem 'rack-mini-profiler'
  gem 'bullet'
  gem 'better_errors'
end

group :development, :test do
  gem 'rspec-rails'
  gem 'pry'
  gem 'sqlite3'
end

gem 'sass-rails', '~> 4.0.0'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.0.0'
gem 'jquery-rails'
gem 'turbolinks'
gem 'anjlab-bootstrap-rails', :require => 'bootstrap-rails',
                              :github => 'anjlab/bootstrap-rails'
gem 'font-awesome-rails'
gem 'unicorn'

gem 'sidekiq', require: "sidekiq/web"
gem 'sinatra'
gem 'yajl-ruby', require: 'yajl/json_gem'
gem 'newrelic_rpm'

A few comments:

  • Most of my apps end up on Heroku, at least to start, so, for ease, I tend to developing locally using SQLite, while using Postgres on Heroku. As far as deployments go, I haven’t seen any easier than Rails on Heroku.

  • My testing stack is what I would consider to be the standard Rspec setup with integration specs using Capybara. I never got on the Cucumber bandwagon. I’ve experimented with using Minitest, but I always end up back with Rspec for one reason or another. Mostly, for no other reason than I’m more comfortable with Rspec and can things done faster as a result.

  • I’ve found bullet and rack-mini-profiler to be essential for optimizing SQL and notifying me of the poor decisions I’ve made with regards to database calls. There’s really no downside to trying either of these. Give them a shot if you haven’t!

  • I’m still baffled that the logs from assets are so noisy. quiet_assets removes this noise allowing you to focus on the logs that matter.

  • I typically add Font Awesome and bootstrap to start. The above includes 2 gems that merge these assets in to the Rails asset pipeline seamlessly.

  • I love the Pry gem. I probably use less than 10% of its designed functionality. But, to me, it’s king of debugging both live requests and tests. I used to use the debugger gem, but got frustrated with its dependencies when using different versions of Ruby. The pry gem has never been a problem in that regard.

When I encounter code I’m not familiar with, the Gemfile is often one of the first places I explore to feel out what’s going on. It’s almost like a personal signature. There are so many gems, and so little time…I feel like I’m just scratching the surface for awesome functionality.

Leave a comment let me know what your favorite gems are!