Go back to the main page

Create a Ruby Gem. Real World, play by play. Part 2

This article is over 2 years old. Proceed with caution.

Regards ♨ – Minimul

 

 


Code from screencast and tutorial is available on Github.

Part 2 of the Gem creation tutorial that follows the conception of a real Gem.

In Part 1 I went over some of the basics in why you would want to create a Gem, naming the Gem, namespace considerations, directory structure, .gemspec file details, and setting up a basic Rspec test. In part 2, I start to dig into the challenges proposed by the code that I would like to formulate into a Gem.

In addition, I started with some code that I am already using on a project. The name of the file is qb_base.rb. I am going to be cutting and pasting that code over to my new Gem. The first stumbling blocks I run into is that the code is hard-wired to its environment. I need to find a way to overcome these obstacles and make the Gem generic "enough" to easily include into another application's surroundings.

  1. First, I open the code that I want to translate into a new Gem.
  2. I am going to start by simply copy and pasting the 'initialize' as well as the methods associated with 'init_intuit_connection' over.
    I changed some of the methods names to be more descriptive and accurate.
  3. Before I get to ahead of myself and add to much code over from the source qb_base.rb file, I run the spec again to test my modifications.
  4. Get some red saying wrong number of arguments.
    I got the red because an argument was added to the initialize method. Add in a account double() and pass it in to get back to green.
    I start running the specs at 10:48 mark in the screencast.
  5. Next, I spec the generate_quickbooks_ruby_namespace method.
  6. Oops, I guess I can't spell accout, I mean account.
    I fix the account spelling and re-run the spec but I get another error, undefined method: camelcase.
    The String.camelcase method is from ActiveSupport, which shouldn't be a problem to use because quickbooks-ruby requires ActiveSupport. The issue is that I don't have quickbooks-ruby included as of yet.
  7. Requiring quickbooks-ruby brings in ActiveSupport so camelcase works as expected. The other generate_quickbooks_ruby_namespace method also passes so I move on.
  8. Passing the generate_quickbooks_ruby_namespace spec is at 16:00 mark.
  9. It is time to tackle the tricky oauth_client method.
  10. This method is a challenge because it involves feeding in data from a persistent location, which may be very different from app to app. How can we generalize this?
    I settle on a design that the user can configure the persistent locations of the OAuth secret, token, and Intuit company id.
  11. To accomplish the configure design and to keep the Gem code organized, I create a new file to handle this.
  12. Creating the configuration.rb is at 17:40 mark.
    The new file configuration.rb goes inside of the base folder.
    I handle the persistent information in a class_eval and also add a way to handle setting the global $qb_oauth_consumer variable.
    After adding extend Configuration to base.rb and re-running the spec I get an error uninitialized Constant Quickbooks::Base::Configuration
    There is no auto-loading as in Rails, therefore, I need to include the configuration.rb. Remember to use require_relative for code inside of the lib/ directory. The spec is now green.

Great, I am half-way finished implementing the wily oauth_client method, which is a good place to stop for Part 2.

In the next installment, I will begin to integrate these configuration capabilities within the oauth_client method. Please note that the last 2 screencasts in the series are already completed so check'em out:

Comment on this article?