Picking a gem for fun and learning

Recently I’ve been working on a small rails project that handles uploads and imports of Microsoft Excel files.
File upload is a very common scenario and, as most rails developers already know, there are plenty of gems to ease the job. Some of them like Paperclip, Carrierwave or Dragonfly are so well established that you really can’t go wrong with any of them, they’re complete and easy to use, with great documentation and a huge user base; in short, they’re a perfect tool for the job.

Parsing MS Excel files is not as common but I have already done it a few times through the years and there are many gems for this task as well, new and old. The good old spreadsheet gem is the one I used most in the past, but the most promising and interesting one is axlsx, to be paired with axlsx_rails if you plan to use it inside a rails application.

I eventually decided to use a different one, a small unpolished gem named creek. Why? One reason is that, unlike any of its competitors, it builds an hash structure for each document row instead of using an array, so you get something like this:

  {"A1" => "First Row, first col", "B1" => "First row, second col", "C1" => nil}, 
  {"A2" => "Second Row, first col", "B2" => "Second Row, second col", "C2" => nil}

instead of:
  ["First Row, first col", "First row, second col", nil],
  ["Second Row, first col", "Second Row, second col", nil]

I think this is a nice feature for speeding up the debugging process because having explicit cell coordinates makes the mapping to the original document so much easier, at least for me, especially when the XLS file has many columns and data is repeated or very similar among them.

Anyway, there are many other reasons I can think of, for example:

  • the gem is two years old, which means that it’s not in its early development stage so I can assume that most of the relevant bugs have already been worked out
  • github shows recent activities for this gem, which means that it’s not abadonware and the author is still taking care of the maintenance, answering promptly to programmers issues and merge requests
  • the codebase is simple and small, so modifications and updates should be easy when needed
  • there are a few tests written with rspec, which means that the gem developer follows the ruby community best practices and I can easily add new ones following the existing patterns
  • it’s easier to get involved when the project is very small: you can easily think about new features to add or make some simple refactoring activities which will probably be welcomed by the author

I think the last point is one of the nicest facets of open source programming: it’s easy to get involved and contribute with some small modifications that can improve the original codebase, make new acquantaintances in the process, and start a learning experience for some of the involved programmers, may that person be you or the original developer. If you’re more skilled you probably can teach some nifty pattern, trick or refactoring to the gem creator, while if he’s more skilled than you he can guide you in the process of improving the gem or show you why your modifications cannot be accepted (i.e. did you write tests for them? Are your changes too much coupled to your specific needs?).

Of course your mileage may vary, but I think that sometimes choosing a rather unknown gem instead of the most famous and celebrated one can be a great choice, especially when you’re on a small project and you feel confident that you can fix issues when they arise. It will surely be a more interesting and rewarding experience; of course we’re in the business because we are fast in delivering code that works, but nobody mandated that we should not have fun while doing it 😉

Happy coding!

Leave a Reply

Please Login to comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.