The list of gems I work with… And a little bit of gem history

03Feb12

Following a discussion on Twitter mentionning this article 24 Extremely Useful Ruby Gems for Web Development which I don’t really agree with…

Indeed, the title is misleading: it talks about webdev but includes some gems that targets sysops or speaks about omniauth but includes authlogic (wtf?).

So, here is the set of gems I usually work with :

  • haml : at Novelys, we really love the pythonesque POV that ideally matches the XML nature of modern HTML documents
  • sass : the loyal companion of haml. Web designer usually loves the combination of haml and sass.
  • coffee-rails : to be able to write Coffeescript and integrating this code in the asset pipeline. From our POV, Coffeescript is not a revolution but a better way to deal with javascript. However, it’s not a magical solution : you still need to know how to code cleanly in javascript…
  • sprockets : to bundle, compress and “digest” your js/css/sass files it’s the default solution since rails 3.1. We were using jammit before
  • mongoid : when dealing with the MongoDB database. During 2010 the mongoid gems was experiencing some NDE but a team was formed and then it came out of the limbo and quickly improved.
  • mongoid_session_store : the usual companion of mongoid to maintain session in the MongoDB database
  • devise : it’s the swiss army knife authentication framework. We were using aaa (acts_as_authenticated), authlogic (that didn’t support multiple database backends) and eventually come to devise which we don’t regret : it’s very flexible and works with nearly any database backend.
  • omniauth and omniauth-* : when dealing with external authentication (Facebook, Twitter, OpenID, etc etc) omniauth is the ubiquitous solution. It’s now separated as omniauth (the core library) and several other omniauth-* lib (like omniauth-facebook).
  • koala : when dealing with the facebook API, we usually use this gem that includes everything we needed so far.
  • cancan : want to deal with authorization ? Here is a clean gem. Tightly integrates with devise.
  • resque : asynchronous jobs at its best. We used nfo-resque-mongo (MongoDB backend) or the regular resque (Redis backend).
  • will_paginate : dealing with pagination. Never felt the need to use kaminari. Use will_paginate_mongoid to be able to use it with mongoid.
  • paperclip : Having used file_column and acts_as_attachment, paperclip is really the culmination of the recent years of experience when dealing with file attachment. During a few months (or years ?) paperclip used the right_aws or aws-s3 gem to deal with the AWS S3 backend. And these gems didn’t really love european buckets. We used a combination of the s3 gem or monkey patching to circumvent that problem. We also tested the dragonfly gem, but paperclip just seems right… Fortunately, since a few months, paperclip integrates the fog gem, a modern and clean way to work with different cloud providers, but it’s no advertised a lot. And for good reason: there’s now 2 backends to deal with S3 : the old which use aws-s3, and the new one which uses fog. Don’t forget to add mongoid-paperclip to be able to use paperclip upon mongoid.
  • ruby-debug : debugger your webapp like “real” developpers debug their C/C++ program.
  • awesome_nested_set/nested_set : tree structure in a SQL database
  • state_machine : state machine for you Active Record or Mongoid models.
  • friendly_id : sluggify your urls
  • meta_search : easy way to do searching and build search form using SQL fields
  • thinking-sphinx : interacts with Sphinx fulltext search engine
  • acts_as_taggable_on_steroids, acts_as_favable, acts_as_commentable : Active Record (Active Model?) extensions for tagging, favoriting and commenting
  • wicked_pdf : PDF generation based on wkhtmltopdf

Deployment ?

  • capistrano : THE deployment tool that every other software communities envy us (fabrik/capifony anyone ?).
  • capistrano-ext : capistrano extension to manage different environments (staging, production, etc)
  • production_chain : OK OK, it’s not a gem, but it will soon be. A set of rake tasks and capistrano recipes to fetch different environments data.

Testing ?

Production hosting ?

  • passenger : Apache/Nginx module similar to mod_php. If you don’t want to hassle.
  • unicorn : better performance than passenger in our own environment
  • rainbows : a fork (extension?) of unicorn tailored for long standing requests (for example when you call another external API in the background). Difference is major compared to unicorn when you’re in the target usage of rainbows.
  • whenever : the easy way to write crontabs
  • asset_sync : sprockets do a great job to bundle and compress your staic files. Why not upload the on S3 and use multi asset hosting ?
  • airbrake : interacts with the airbrake.io web services to gather all your exceptions. Really really really useful. Essential.


6 Responses to “The list of gems I work with… And a little bit of gem history”

  1. Nice list, some I use, some I know, some I probably should use. I like the “swiss knife”-like list : you got gems for every case, from development to deploy.

    Thanks,

    Martin

  2. 2 Christian

    Good list. My comments:
    rspec: too much magic. minitest is best for me.
    paperclip: I’ve had many issues with file upload/image processing libraries and lost many productive hours. I roll my own now. Yes, I’ve used CarrierWave. Didn’t like it, too much magic. Will never touch another image processing library.
    will_paginate: using Kaminari now. Never going to look back.
    devise: too much magic and too many dependencies. Breaks often.
    sprockets: Don’t like it as it is. Still rough around the edges. Needs to be simplified and made more robust.
    haml: slim has a lot better syntax. Wouldn’t use HAML, use ERB only for special situations.
    thinking-sphinx: mucho magic. migrated to ElasticSearch and TIre. Won’t look back.
    friendly-id: too heavy for what it does. I roll my own.

    My personal opinion is to use as little plugins and gems as possible, because gems tend to be complex and do a lot of magic. Plugins also force you to upgrade or migrate to the latest and greatest alternative. Ruby seems to be aging and now has the same problem Java had in 2004. Too many alternatives, of which most are broken.

    • Well, that was the point of this blog post : sharing some knowledge about what currently works well for us. And finally you’ll see that there isn’t a “lot” of alternatives.

  3. Great list.

    I’ll suggest a gem to add to your deployment toolchain: Cape (http://rubygems.org/gems/cape). It allows you to mirror Rake tasks as Capistrano recipes, with recipe options, remote environment variables, and Rake task arguments integration.

    My team has its own common recipes collection: http://rubygems.org/gems/ninja-deploy.

  4. Hey,

    I prefer Carrierwave than Paperclip. I really don’t like to call a method with a big options hash in my models. I feel than creating a nice class which can be easily extended is so much cleaner…

    I used to like dragonfly but you lose its main advantage when storing your files on S3 or Rackspace Cloud and want to link directly.

    will_paginate or kaminari? I had to integrate a custom and weird pagination markup in one project and with kaminari you can create your own themes just by editing some partials..! that was so much easier than creating a custom Paginator in Ruby using WillPaginate…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: