From Skeleton to ColoradoTrails — my first Ruby CLI gem
By: Chrstph Grnr
Tags: Flatiron School, Ruby, Rubygems, Cli Gem, Cli

As part of Flatiron School’s Online Software Engineering Program you have to write a small Ruby gem with a CLI and some scraping, along with giving the user the option to display more info about one of their menu choices.

This is a short recount of my experience writing this gem.

As you progress through the curriculum for the first few weeks, every week you feel like you learned so much the week prior, and now, you’re comfortable in what you know. That’s Monday morning, before you open your new assignments for the week and wonder what they are all about. Shortly thereafter you realize that you know nothing and you’re floating in an ocean of information and need to drink it all. And so it was on CLI project week. You saw it coming the week before, with the calendar already filled with lectures about that ominous gem. And then, you get started. And here is where it gets weird. You know what the individual parts of the gem are supposed to do. You practiced it all the weeks before and know how they should work as individual snippets of code. What they output to the terminal, how they communicate with each other, what data and info gets send from point A to point B and viceversa.

BUT. But that doesn’t mean you quite know how it will all work as a ‘team’. At least for me it was like that. I tried explaining this to my wife just last night. Here is where the skeleton comes in.

We all have seen and/or goofed around with the skeletons in biology class, haven’t we? They are just that, a skeleton. And that’s how the beginning of that gem felt like. The parts were there in my mind, they all had a function to some degree and most made sense in how to write them. But then, the rest was totally not there yet. And in a sense, the skeleton from biology class is a great analogy. All the snippets of code that were going to make up the working gem are represented by the bones of that skeleton. But without connecting tissue, without muscles, tendons, nerves etc. that skeleton will never have any control over its own extremities. So, it was up to me to figure out how to write that connecting code.

How, for instance, to connect the CLI class to the Scraper class(lots of code talk there…). If you go and check out the gem (you can do so here or here) you’ll see what I mean. As mentioned before, the requirements for this project are that you create a CLI (Command-Line-Interface, basically a way for a user to communicate with a piece of software through a terminal), and said CLI will give you the option to get more data based on a choice you make in one of the menus. So I had to write Scraping and CLI classes, along with a storage class for all the data a user would get a chance to look at.

I watched quite a few videos of people (all of whom are way better coders than me) writing gems in relatively short time. One of those, by Avi Flombaum — founder of Flatiron School, was only 1! hour. He wrote that gem, including setting up all the required files and file structure in 1! hour. I watched it early on during the project phase and was like, “Yeah, if he does it in 1 hour, I can do it in 25…” false

But what I saw in that particular video made a lot of sense for me, it actually got me to a point where I knew how to start writing it. Here is what Avi did in that video lecture: After setting up all the files and had all the requirements figured out (NOT easy, I tell you, not easy at all) he began hardcoding his CLI interface. Hardcoding means, he just wrote some output in a method and let the terminal spit it out once a user made a choice for that data. It’s something that’s never going to hold up in a real world app, but it gets your thoughts flowing. And so he wrote more and more code, and slowly started replacing those hardcoded pieces with code that can actually scrape a website to display data that’s real. But, with one difference. The structure staid the same. The framework of the app didn’t change. He just reworked it to interact with new parts he wrote. So, in the skeleton analogy, he started with just the skeleton. Not able to move much at all, very awkward in how it walks and goes about (ever seen a skeleton move? right). Then, slowly but surely he connects the individual parts and gives them functionality to interact with each other and other objects.

That’s exactly what I did as well. I started with a simple CLI interface, no scraping, no fancy colors or anything. Once I got that working I moved on and so it went. Interestingly enough, if I look at any of the code now, I need to take a moment and think what I am actually looking at. I don’t know it right off the bat. Which is very weird, after all, I wrote it!

Anyway, at the end of this project week I sent my gem over to a fellow student and asked for him to run it. I didn’t hear back from him right away, went to do other things. Then I get this message and in it he shows me, how my app has a bug — but low and behold, I actually knew right there, standing in the kitchen with a mouth full of peanuts, what the error was all about. I knew exactly what code was affecting this. So, I guess I feel a bit better about not knowing exactly what I am looking at every time I look at the code.

One thing that has been a common theme throughout this coding experience is that you always get to a point where you are comfortable. You think you got it. Then you turn a corner, and it is a whole different ballgame. But it doesn’t matter, as long as you don’t just give up right then and there. Persevere, try, read, study…after a little while, it will feel like you got it. And then, rinse and repeat. I feel very strange in saying so, but I like that. I like that it has that ongoing struggle to make sense of something that just a moment ago seemed easy.

Don’t get me wrong, there were LOTS of struggles with this. Until this point in the program, most labs and assignments were test driven. Meaning, there was always an indicator as to what your code is missing or not doing the desired way. This time around, it’s on you to figure out how the code you are executing is not performing what you want.

C’MON! I know this should work!

But after all, it was a very rewarding week. The highlight being Saturday afternoon, sitting at my desk for a few hours already, trying to get my gem published to RubyGems.org. It wasn’t working and the error messages I kept getting I had never seen before. Google, unlike usually when I got to something like this, was of no help at all. It was another one of those moments of feeling like I just had this, now it’s completely over my head. But I did what the program has taught me so far. Sit there, read the code, read the error, and keep on googling. Find somebody who had a similar problem (believe me, you are NEVER the first to encounter this error), read the solutions people have offered, and keep on trying different things. When I finally got it to do what I want, meaning the publishing actually happened and it worked, I was over the moon. At this point, anybody out there can install this gem from their command line. Given they have Ruby and RubyGems installed. But they can. And it works!

If you are interested, I already linked it somewhere above, but here it is again.

Github: https://github.com/ChrstphGrnr/colorado_trails

RubyGems: https://rubygems.org/gems/colorado_trails

Also, if you have ruby and rubygems installed, you can just run gem install colorado_trails in your command line.

Thanks for reading and I hope you can look at skeletons again without thinking of Ruby.