August 28, 2012 by Chris Jones
While trying to develop our Ruby on Rails standards, part of the work involves looking at various Ruby Gems and assessing how much we can standardise on their usage. This would assist developers and make our applications more standardised and therefore easier to maintain and support.
As a starting point in order to evaluate a particular gem, there are a number of elements I’ve tried to take into consideration.
- What functionality does it offer (for the current development and beyond).
- What versions of Ruby and Rails does it support.
- What is the documentation like?
- Gauge what the developer community are currently using? ie looking at github and stackoverflow.
- Try and obtain a feeling of where the developer community is going? ie perhaps a particular gem has reached its peak and maybe its worth looking at up and coming replacements.
- How active is the github repository, ie when was it last updated.
As you can see above there are numerous considerations and this is also clearly a very fast moving target (especially in the Ruby world). To complicate matters even further, you can decide on one particular gem, only to find it conflicts with another gem within the application. I’ve had a recent experience with ActiveAdmin (that uses kaminari) and a conflict with will_paginate. It seems to me strict standardisation will prove difficult. Perhaps we should offer our developers recommended Ruby Gems, but allow the flexibility to assess things on a per project basis and update our recommended gem list accordingly. Also worth noting that any recommended Gem list will require a high level of maintenance.
I’m sure there will be plenty of debate of how best to achieve our Ruby on Rails standards as we built up the Architecture.