6 Tips for Full Stack Open Source RubyGems Development

Call me old fashioned but up to really recently I used to write my rubygems the old way: manually. 

You know, the .gemspec, the various directories, everything.

It was kinda boring, and that’s why my contributions to the gems ecosystem became scarcer than ever.

Around last December though I wanted to start working on a new project, ruby-lol (more on it in a new article), and I wanted to have everything people expect on a modern gem:

  • continous integration badge
  • coverage badge
  • gem version badge
  • code quality badge
  • gem dependency badge

The most important thing though was minimizing the effort I had to put in to obtain all of that.

So, without further ado, here’s a list of tips to streamline your gems development:

1. bundle gem your-gem-name

This won’t be big news for anyone, but the best way to start developing a gem is calling

$ bundle gem your-gem-name

from the terminal. It will create a directory with everything you need to start coding in there. Edit the license, the readme, and few fields on the gemspec and you can start happily tapping on your keyboard.

2. use a gem version badge

Once you release your gem (hint: gem build your-gem-name.gemspec && gem push your-gem-name-version.gem) you can add a gem version badge to your readme. It’s pretty simple, open the gem page on rubygems.org (i.e. ruby-lol) and click on the badge link. 

You’ll be redirected to badge.fury.io, where you can pick your favorite choice of markup and paste the badge in your readme file. Commit, push and you’re done :)

3. continous integration with travis-ci.org

I am officially in love with Travis. No one can not be in love with a working and easy to use hosted continous integration service that is FREE for open source development. 

So how do we set it up? Easy. Sign in travis-ci.org with your github account and give it access to your public projects. Follow the three simple steps and you’re done.

After you have your build up and running remember to copy and add the badge markup to your readme.

4. easy code metrics with code climate

Code quality is something that usually makes people argue. I know I do a lot. Code quality metrics are even worse. I know people that swear by them, and people that think they’re worthless.

I don’t know where you are with this, but I like showing off the quality of my code, and easily finding weak spots I overlooked.

Code climate is a (pricey) service that is very good at analyzing your code and allowing you to navigate around its issues. I am a paid subscriber, but like many companies they also have a free way to check the code quality of gems.

Their add github repository page is what you’re looking for. 

As for the other services remember, when you’re done, to add the badge to your readme.

5. test coverage, some love it, some hate it

As with code metrics, test coverage is something that at least makes people talk.

I like keeping track of the coverage of my tests/specs, because knowing that everything I have written is covered by tests makes me work with a more relaxed state of mind.

Coveralls.io is another great service, free code coverage for opensource projects, easy to setup, it integrates perfectly with Travis.

Once again, setting it up is easy. Signup with github, give access to public projects, get the badge and put it in your readme.

6. keep up with your dependencies

Last but not least, Gemnasium is a service that allows you to keep track of your gem dependencies and notifies you when you become outdated.

Free for open source projects, you might be familiar with the set up process. Sign in with github, copy the badge when you’re done :)

Gemnasium ends the list of our list of tips. If you want, let me know what you think of it and whether there are more easy-to-set-up and useful services. Have fun!

Notes

  1. sato-ryu reblogged this from mikamayhem
  2. mikamayhem posted this