Flatiron Week 4: creating my own Ruby CLI gem: a tale of fear and Git
By: Joan Indiana Lyness
Tags: Ruby, Flatiron School, Git, Bundler

So it’s week 4 and we are all working on our first portfolio project, a CLI (command line interface) Gem (that’s Ruby for “app”). Our gems are supposed to scrape a website and then provide a way for the user to play with the data! That could range from displaying information (top 10 articles on The Economist? NYTimes best sellers?) … to creating something like a trivia game based on the data.

Overcoming Fear

The first lesson I learned about this project was overcoming fear. A lot of us were slightly horrified to hear from people who had spent 30+ hours on their Gem (we get a week to do it). That made it hard to even look at the scope of the project, but I decided to read a bit ahead of time, anyway.

The README looks pretty bulky — you have to wade through a lot of project requirements which seem intimidating because before you begin, you assume all of it will be hard. The actual instructions start about halfway! through the README. First directive: watch Avi Flombaum’s walk-through video of how to create a Gem from scratch.

I watched it and .. was greatly heartened to see that Avi was able to complete a Gem that would satisfy the project requirements, in an hour and five minutes. I figured if he could do it that quickly, I, as a somewhat over-confident-until-beaten-down neophyte, could probably complete one in what … max … 20 hours?

Other folks in my cohort agreed that watching the video made the project a whole lot less scary.

Me vs. Ruby’s gem Bundler

Thanks to the video I was able to get a good start — I wrote down in English what I wanted my GEM to do, I roughed out some classes and methods … and then I thought, OK, let’s get this up to Github — which Avi doesn’t talk about in this video. The Flatiron curriculum covered Github early on, and at one point I knew it, but I had since forgotten just about everything. Luckily we can always redo past lessons, or … just Google. I did both.

The whole process of setting up the files scared me, so I tried it again for this blog post, with a new project called “Best_Sellers”

The workflow goes like this:

Open up your terminal program and navigate: cd to the folder where you want the local version of your project to live (My projects liv in a “dev” folder, so I typed cd dev to get there). Then automate the entire process of setting up your Gem files by using Ruby’s gem bundler. But first you have to install it.

Following instructions online, I typed gem install bundler and got an error.

Sudo

What, no permissions? This is not a good start! Then I read that you can get around this error by starting the command with sudo . What’s that? Hint: it is not the Sudan Social Development Organization! It is an instruction to the computer to treat you as a ‘super user’ who does have permissions after all. So I ran it again, this time as sudo gem install bundler and it asked me for a password.

Not knowing any other relevant password, I tried my computer password. But as I typed, I didn’t see anything! No blinking cursor, no black dots to hide my password from view, no characters, nothing. I figured I was doing something wrong, so instead of typing in all of my password, I stopped, tried again, failed again, and finally took a leap of programming faith: maybe the computer is receiving my keystrokes even though it’s not showing any signs of doing so?

That was it. I typed my password … and a few seconds later, it worked!! Here’s what it looks like in the terminal:

And here’s what I looked like:

Once Bundler is installed, you basically have an automated system for setting up Ruby Gems. Without bundler, you’d have to manually set up a file tree of with three folders, one sub-folder and more than a dozen files. With bundler, you get to do it all in a few seconds by typing

bundle install Best_Sellers

Name your Gem in snake_case!

Hint: use snake_case! (with an underscore between words) for the name of your Gem (if the name has more than one word). Otherwise, with dashes between words, the bundler will think you are making a project called “Best” with a sub-folder of “Sellers.” The easiest way to fix that (yes, it happened to me, just as it did to Avi, in his video) is to delete everything and run bundle install again.

It’s amazing what that one command creates:

These new files include a README, an MIT license … In other words, with just that one command, I completed about one-fourth of the requirements for the CLI project (your project must include a README file, with a link to the license, etc.). Before running bundler, I assumed I’d have to manually create everything.

So now what? Now you open up your new project in your code editor (file>open etc). Here’s how mine looked in Atom:

Git up and go

If you take a closer look at the terminal picture showing all the files that were created, you’ll notice this line:

Initializing git repo in /Users/Joan/Dev/best_sellers

That means that bundler initialized a local Git repo, one that lives on your computer. What’s a ‘repo’? (It has nothing to do with losing cars for lack of payment) A repo, or repository, is a place where your project lives. You can keep it on your local computer, but it’s a better idea to connect it to your Github account, so your work will be safe even if …your computer dies …or your toddler drops it in the toilet … or your cat …

plots against it…. or in case you want to make it easy for others to contribute to your project in an organized way.

If you type git status into your terminal, you’ll get a list of all new files that were automatically added by Bundler, but have not yet been committed:

First Commit

You can commit them with git commit -m "first commit", where ‘m’ stands for message and the message in quotes describes what you’ve changed since the last commit. Since this is was my first commit for this project, my message was “first commit.” Git then listed what was changed.

Great, so you’ve got a git repo. But it’s only a local repo.

Connect to Github

Next step: connect our local repo to Github. To do that, surf to Github, log in (create a free account if you don’t already have one) and click on that large green NEW button to create a new repository (remote workspace for your project).

You’ll see this:

Use the *same name* you chose for your local repo. Since your local repo already includes a .gitignore file and a license, you don’t need to add them.

Click “create repository.”

Curtain #1, #2, #3 or #4?

You’ll see four choices. I’m going to assume that if you’re still reading this, you haven’t done this kind of thing before, so skip the first choice (Quick setup).

The second choice tells you how to create a local repo from your command line — we already did that with bundler. So skip that.

The fourth choice definitely doesn’t apply. We’re not import anything from another repository.

That leaves us with curtain number three: Push an existing repository from the command line. Copy and paste those two lines of code into your terminal.

Yes, you can paste both lines in at the same time and hit ‘enter’ just once.

Voila! You have now connected your local repo to Git!

Now you can code. If your clueless about what to put into some of those new files that bundler created for you, make sure to watch Avi’s walkthrough video.

Git back (to where you once belonged)

If you are like me and you periodically break your Gem and then make things worse by making new commits of your broken code … you will probably want, at some point, to revert to a past commit where you knew the code was working.

For this … git reflog is your friend!

It retrieves a list of all previous commits, each with a unique ID. Here’s what it looks like on my CLI Gem project, which has many commits. The most recent commits are on top.

The yellow characters are the ID for each commit. If you look near the middle you can see this line:

6ceda4b HEAD@{8}: reset: moving to 6ceda4b

This is where, after making some mistakes and making them worse with more mistakes … I was desperate to go back to a previous version. If you want to completely destroy everything since your last commit (the nuclear option), here’s how.

Type git reset --hard plus the number at the left.

In my case:

git reset --hard 6ceda4b

Blink once and your local repo looks just like it did as of the commit you just reverted to. It really is like time travel. For more info on git reflog, check out this blog post and this blog post.

Some other time I’ll write about the actual CLI coding process. At this point, I’m just about finished, and I’m pretty happy with what I’ve created. Sure, I ended up spending more like 60+ hours on my Gem, but that’s mostly because

I enjoyed adding features, which put me in what seems like an infinite loop — improve, break, fix, repeat … and

2. it took me a LONG! time to just set up my project and get it connected to Github. Hopefully this blog post will make that task easier for you!

Happy Coding!

Next: CLI Gem Part 2: Scope and Flow!