I learned that, like Rails, gem building is opinionated, for good reason.

Reflections, Writing My First Ruby Gem

This week marks my one year anniversary of working professionally with Ruby and Rails. It's been one hell of a year. Programming aside, a lot has been happening; however, Ruby has always been there. It's the friend that sticks with you through the thick and thin while you read through one-hundred-line Java methods that the professor handed you. The light at the end of the tunnel, so to speak.

One year celebrations are a good time to look back and see how far you've come. When I think about a year ago, I had no bearing on what software was. I hadn't read any material on software design or theory. I hadn't built any products that saw the light of day. I had no will to contribute to open source because it was a sea of projects I didn't understand.

My problem when I first started out is that Unix is just a huge wall. Getting stuff done is not easy at first. I had never worked with computers through a terminal before, and Unix requires an immense amount of patience and reading. It wasn't easy learning about directory structure, all the commands, shell scripting, etc. Once I got over this, working on a computer without a terminal felt odd and disjunct.

As for open source, this was impossible until I started building things. Github influenced me a lot, and I wanted to get in there and write some code. It didn't happen until I started writing my own web app. I made thesetimes.info over the course of a couple days. This app and other things I was working on were very Javascript heavy, and I started looking for a way to test it. Here's where my gem comes in.

Writing the Gem

Writing a gem is hard—at least, that's what everything made it seem like. My first resource was Google. Blog posts abounding, none of them were consistent. Do I use hoe? New gem? What's this business about gemcutter? Jeweler? Which version of Rubygems is accepted right now? So many questions...

My gem idea was pretty simple, but it wasn't until I had bphogan explain it to me that I was able to build the gem. I learned that, like Rails, gem building is opinionated, for good reason. He taught me all about gemspecs, folder structure, putting my classes in modules, and how to require all the files.

I can't stress how much we need this sort of explanation out there.

Javascript testing is also hard. The few accepted projects out there include qunit and Jasmine. My thoughts are, if qunit is to Test::Unit as Jasmine is to rspec, then they're both equally important. Having a TDD framework and a BDD framework at your disposal is necessary—just like in Ruby.

The gem is called qunit_gen. It manages a QUnit javascript test suite on a project-to-project basis. It's not nearly as sophisticated as the Jasmine ruby gem, but it does the job for now. I'd like to provide some of the same features that Jasmine does for the qunit gem.

The project is on GitHub.

I'd like to thank Brian Hogan for helping me through a lot of programming questions. He's been the best mentor and teacher I could have thought of. And, to many more years of programming!

Contact

Follow me on Twitter

Send me an email at godin.aaron@gmail.com.

Go up to the top or back home.