Going to Gem Med School: Open Source ruby projects with Dr. Nic Williams

Grooving with Dr. Nic, and digging in to some projects

Going with the Flow

Despite my feelings that the title Dr. should be strictly reserved for those that save lives, Dr. Nic Williams does have plenty of good advice to offer (and he offers it in a nice format on his website). After having made some of the same mistakes and asked the same questions he has, I decided to try out the new and improved open-source project workflow. There are several things to be achieved from these open-source projects:

  • Have fun
  • Learn something new
  • Share code

There are also some thing that should be avoided, less favorable outcomes:

  • Write code, but don’t go the full 9 yards to distribute + share it
  • Spend too much time on setup/distribution
  • Tie yourself down with maintaining your projects (they should set you freeeeee!)

Two great presentations can help you achieve these goals, and avoid the pitfalls. The first is a a great presentation about what an open-source project should be, what it shouldn’t be, and how they can make your life better, not worse.

The next presentation is about how to quickly and effectively distribute and share your projects.

In order to get this all down, the good Dr. describes a workflow and a set of tools for each step.

The Project

I decided to write a little ruby wrapper for the ‘ddate’ command, part of the ‘util-linux-ng’ package, that convert Georgian dates to Discordian dates. Why? Because I like it, and if you are going to pick a project to learn on, it might as well be ridiculous. I got attached enough as it was to this project, even though I don’t think anybody could come up with an excuse to use Discordian dates, let alone happen to be using ruby.

Snafoos

One thing that started to bug my is the gem, class, module, and github repository names. It seems simple enough, but sometimes you are so excited to get you idea down in code that you rush through this first step. It will be around for a while, and is kind of a pain to change once you get it all set up. So take a few minutes and think about a name. One without WeIRd caps or anything that might annoy you in the future.

I also found newgem to be a little wonky. It a nice tool to have around, but I think (rightly so) it is tailored to Dr. Nic’s workflows, and might not work for everybody.

Lastly, I found myself wresting with Hoe. The ‘rake pacakge’ task was failing if I added the Hoe require statement, and runcoderun was failing without the statement. That brings me to a little tangent. I didn’t really dig into what was going on there, but this is an example of something that is unexpectedly not idempotent; you should be able to require and require and require, then run some code and everything should be fine and dandy. I’m not sure how or why requiring Hoe (when it is clearly used, anyway) would break anything, and it almost annoys me enough to find out. Almost.

Good stuff

I like RunCodeRun. It is simple continuous integration that makes sense. I also like the blog badge, although it currently looks horrible on my blog.

Stuff I’ll add

Speaking of blog badges, I want to see if I can get the github projects blog badge working. Associating myself with a project is another step for creating a fully-rounded project. This badge helps integrate that step right into the existing workflow.

For learning projects, I plan on adding some non-standard notes to the README, including sections about what I learned and what would have done differently. Open source the code, and open source the learning process. Its not like I have any customers to scare away with honest comments.

As Nic Williams said, “Don’t attach your self-worth to your code – your code probably isn’t that good.” Its true. I am a better software developer than I am a coder, and I aim to be. You can write code quite a few different ways and it all compiles down to the same thing. To me, nailing the workflow and the tools is the hard part, and the part that deserves the most attention.

Working with software, your code will always improve and you will keep learning new tricks. But too many people let their workflow and tool-set become stagnant, which can leave you further behind than knowing a few extra tricks in this language or that one.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>