My Ruby on Rails capstone project for my bootcamp is a budget app with a calendar component. I decided to keep some info in a monthly date format and other info in a weekly date format (more on the pros and cons of that decision in my next article). Basically I had two sets of incompatible data with no easy way to integrate them, which I needed to do any of the math in my budget. This was really annoying.
Then one day, toward the end of the bootcamp we had a class on how to make your own gem. We used plenty of gems but I had no idea how easy it was to make one. All you do is write some code in your terminal and then code it up in Ruby.
In reality the reason I decided to make a gem for my capstone was because I thought it would be awesome! (I’ve been using these things for weeks and now I can make one!) But I wanted to share some insights I’ve gained from the process.
- Want to understand how languages work? Make a gem!
- When should you make a gem for your own code?
- Why you should just write code and not make a gem (most of the time).
In other words, creating a gem is a way to be a part of the process. Though I am brand new at this, I’ve always assumed that understanding how these languages work and where they’ve come from would be a pretty great way to deepen yourself as a programmer and prepare you for learning new languages.
Fundamentally, a gem is a completely removed from the app you are working on. It is basically another app that is really easy to link to your current app. This means that it is more difficult to update your code, which can be a pain. On the other hand when it is more difficult to update your code, you can force yourself to leave the code alone which can be just what you need.
In my case, I had one specific problem that was actually pretty simple; I needed to convert from a year-date format to a week-date format and vice-versa. Aside from any bug fixing I knew I wouldn’t need to change that functionality and it would be handy to code it up and set it aside so I didn’t have to worry about it. After working on it for a little bit I realized it is also really easy to set up RSpec tests and run your own tests to test the functionality of the gem. If you find yourself with this kind of a problem, there isn’t a solution already out there you are happy with, and it’s a problem you might have in the future with a different app, it might be worth considering making a gem.
Of course there are plenty of downsides. The main one I found was that after using it for a while, I realized that my documentation for how to use the gem wasn’t complete and I still haven’t updated it as thoroughly as I should. There is a little more upkeep. It’s not difficult, just a hassle to remember.
This brings me to my last point. In Rails there are so many ways you can solve a problem. For simple ones like mine I could have easily made a model method that would have done the same thing. In reality the only time you 100% should make a gem is when the code is too complicated to hold in an app or too useful to hold in one app. For my personal preferences, making a gem made it easy to stay organized and focus on my other code (which needed some help). I also don’t know the impact of using a gem on things like computation speed and app size.
Please feel free to make any comments, correct any errors, or offer better explanations. I am happy to receive any feedback. I’m brand new at this and would love to get better. For those coders out there who have always dreamed of making a gem, but have been held back by naysayers: Do it! Live your dreams! I’m proud of you!