My First Ruby Gem Part 1: Brainstorming

I recently embarked on a quest to build my first Ruby gem. I wanted to learn more about these little libraries that many people probably take for granted and to learn how to contribute more to the open source community.

Researching the tools we use on a daily basis is something all developers can learn from; especially new ones. I’ll bet there are many developers out there learning Rails without fully mastering Ruby. They have no idea what’s happening under the hood — which is fine, until something breaks and they have to go debugging. It’s hard to fix a Ferrari when all we know is how to change a spark plug and fill up the gas.

For those that want to skip ahead and just check out the gem I built, here’s the link:

Introducing RubyTutor

For everything else who’s more interested in learning about gems and building one yourself, keep reading.

What Should Your Gem Do?

Chris, one of the instructors as Launch School, says that you need to be competitive, not necessarily with other people, but with yourself. It was this thought that lead me to create a gem in the first place.

I had thought that building gems was mainly done by professionals and that I was over my head. But after doing some research, I realized gems were not necessarily anything amazing. They’re just tools. While some may be more complex, flexible and/or useful to a user, each tool has it’s place in the toolbox.

So what did I want my tool to do?

I think this is where many people can get trapped, especially when they’re doing something for the first time. I’m the sort of person that immediately leaps to thoughts of grandeur. However, that’s often not the way to go.

My advice for someone wanting to build a gem but doesn’t know where to start is:

1. KISS. Keep It Simple Stupid.
2. Do what you know.
3. Try to fix a small problem or bit of redundancy.

In the end, if you’re just building a gem to learn more and have fun, it doesn’t really matter what you do. Just pick something and see it through.

Brainstorming

While I found a couple different articles showing simple gems that could be made, I knew I wanted to create something more substantial than a “Hello World” gem.

I’ve been a tutor for many years of my life and I enjoy teaching. Seeing as how more and more people are becoming interested with programming and Ruby specifically, I wanted to build something they might find useful. While I absolutely love Ruby and think everyone should learn it, it has some quirks that can trip up veteran and novice programmers alike.

One of the best ways to learn a language is to experiment with it and create small programs. The best experimental playground in Ruby is the REPL(Read-Eval-Print Loop), IRB(Interactive Ruby Shell). Newcomers will spend many hours playing around in there, solving basic problems and getting the hang of the whole “everything is an object” concept. Therefore, I wanted my gem to be used exclusively in IRB.

Another great, albeit less fun, way to learn about a programming language is to read the documentation. I have ruby-doc.org bookmarked in my browser and visit it several times a day.

Unfortunately, novices are often intimidated by documentation. Telling a completely green programmer to “go read the docs” is essentially saying, “here is a website with terrible design, a not-so-intuitive layout, and lines and lines of text that you need to filter through. Have fun.”

Yes, documentation is an invaluable tool and every programmer eventually comes to love it. But they are a beginner’s worst nightmare.

How nice would it be to bring a bit of the documentation to IRB? So instead of having to job back and forth between IRB and the docs, there’s a liaison that can provide information one needs to know in a friendly and easy format.

Thus, RubyTutor was born.

After we figure out what we want our gem to do/solve, it’s time to think of a name. While it’s not pertinent that we think of the name at this stage, it will make things easier. Mainly because our next step will be to use the Bundler gem to auto generate all the basic files we will need, which will require a name.

Bundler is a great tool to assist us with gem creation. Like most other things in programming, there is a lot of setup before we can get to the fun stuff. Bundler automates a lot of that monotony for us.

To use Bundler’s gem support, we will use the bundle gem command on our command line followed by a name.

For example: bundle gem rubytutor

This creates the working directory along with all the files we’ll need:

➜  rubytutor git:(master) ✗ tree .
├── Gemfile
├── LICENSE.txt
├── README.md
├── Rakefile
├── bin
│   ├── console
│   └── setup
├── lib
│   ├── rubytutor
│   │   └── version.rb
│   └── rubytutor.rb
├── rubytutor.gemspec
└── test
    ├── rubytutor_test.rb
    └── test_helper.rb
4 directories, 11 files

(Side note: If you decide to change the name of your gem after running this command, it will be a hassle. Bundler autofills many of the files with the name you provide, so you will need to comb through it and replace every name. Depending on how far along in the gem development you are, it would just be easier to copy the code somewhere and create a new directory using bundle gem again)

As we can see, Bundler has provided us with quite a bit. What we won’t see in this tree, but is very important to know, is that Bundler initialized a git for us and there is a hidden .git file. Make sure you do not run bundle gem inside an already existing git project.

For someone who has never built a gem before, all of these files and directories can be overwhelming. If you’re feeling panic, don’t worry. We will go through all of it one by one. That may sound like a lot, but it will be worth it.

Continue to Part 2 where we take a look at all the moving parts that make a gem, a gem.