Patterns in a Rails Gemfile
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.
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).
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:
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 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!