Sexy Charts FTW in Rails (+ making a Shopify App)

I was applying for a job at Shopify and decided that the best way to woo them was with Sexy Charts™.

Charting Options for Rails
I think the sexiest Sexy Charts™ out there right now are Highcharts, but their commercial pricing is a bit steep. As part of the application process I was making a Shopify App, and while the aim isn't to sell it on the store in the short-term, you never know right? Because of this I didn't want to use Highcharts, and risk incurring their Licensing Wrath. The next-best option was Google Chart API, which I had wanted to try for a while. I was pleasantly surprised to find out they had gotten a whole lot sexier than the last time I looked at them (check out the home page for examples, and make sure you mouse-over the graphs).

Building a Shopify App
If you're in to Rails like I'm in to Rails, a great place to start is the guide on Shopify's site. The most important thing to do is run the shopify_app generate on a fresh Rails project, as it clobbers a bunch of stuff to give you a running app skeleton in record time.

I really can't improve on it, so go have a look at it and come back when you're done. Go. Go now.





...aaaaaaand we're back.

Environment Variables and Herkou
The only thing I changed from the standard shopify_app generator was to move my environment variables (my app's Secret, Shopify Secret Token, and Shopify API keys) in to an external file which was NOT checked in to source control (Git). This meant I could host the project on GitHub for Fun and Profit, without giving up mah secretz.

I started out using Tammer's steps, but found that putting the load in config/environment.rb (as he suggests) this didn't load the variables in time for the Shopify config settings in config/application.rb. I ended up having to put the load in just before the Shopify config options are set (in application.rb), so it looks like this:

     ...

    # Heroku env variables - for development/test
    heroku_env = File.join(Rails.root, 'config', 'heroku_env.rb')
    load heroku_env if File.exists?(heroku_env)

    # Shopify API connection credentials:
    config.shopify.api_key = ENV['SHOPIFY_API_KEY']
    config.shopify.secret = ENV['SHOPIFY_SECRET']

    ...


If anyone has a better way of doing this, please let me know (I tried a bunch of other stuff, but this was the only way which worked and wasn't too nasty). Once you've added that, you'll need to create a file config/heroku_env.rb with your secretz. Mine looks something like this:

# DO NOT CHECK THIS FILE INTO VERSION CONTROL

ENV['SHOPIFY_API_KEY'] = '12345678912345678912345678912345'
ENV['SHOPIFY_SECRET'] = '12345678912345678912345678912345'
ENV['SHOPIFY_SECRET_TOKEN'] = '12345678912345678912345678912345123456789123456789123456789123451234567891234567891234567891234512345678912345678912345678912345'


Make sure you add the line config/heroku_env.rb to your .gitignore file, otherwise you're going to have a few issues when you deploy to Production... This setup also means you can use different values in the file to what you set in Heroku, and keep your prod and dev environments completely separate (== WINNING). It would also work well with things like AWS keys, and anything else you don't really want to be publicly visible on a GitHub-hosted project.

Making a Shopify App
Once you've got that all down, you're ready to start making your own app. The important thing to remember with a Shopify App is that by "installing" your application on their store, all the store owner is doing is giving your app (in this case, a Rails app) permission to access their Shopify data. They're not actually copying any of your code, etc to their Shopify store.

If you've set your application up as in the document above, store owners who install and log in to your application will be directed to the home#index action. Actually, they're being directed to the page they came from OR the root route (which by default is points to home#index). You can change this by modifying the root route in config/routes.rb, or change the final redirect (on success) in the login#finalize action (if you don't want to change the default route). You can also update the views that the shopify_app gem created for you in app/views/home/.

The API is quite simple, and there's a few good examples in the default home#index view (app/views/home/index.html.erb). Once all the setup steps have been completed (in the login controller, provided by the Shopify gem), getting a list of the store's customers (once the owner has logged in) is as simple as:

@customers = ShopifyAPI::Customer.find(:all)


The same works for products, and a bunch of other resources. See a full listing of possible requests on the API documentation page. The magic happens with the around_filter that Shopify gives you:

around_filter :shopify_session


If you want to access Shopify data from your own controllers, just add this around filter to your controllers, and get busy!

API Limit
There's a limit of 500 API calls every 5 minutes, which is perfectly reasonable (there's a funny write-up about it on their wiki). Even with a nice fat limit like that, requesting all the info you need every single time is LAME and SLOOOOW, so I stored some of the data locally for my own processing. That being said, I tired to store as little Shopify data in my app's database because I don't really want to be responsible for it - I keep just as much as is needed to make my app work.

Publishing the App
I'm still putting the finishing touches on my app, but the MVP is almost done - not bad for playing with the Shopify API/gems for only two days (along with my normal work). The next step in the plan is to get some shop owners to test and comment on the app, so that I can get validated learning - gotta keep it LEAN. Hopefully it'll be in the Shopify App Store soon, it's called (imaginatively!) Customer Demographics.

"WARNING: Cucumber-rails required outside of env.rb. The rest of loading is being defered until env.rb is called." with Bundler prerelease (1.1)

Had a real 'fun' time (ie. not fun) getting around this error every time I tried to run 'bundle exec spork cucumber' (which would then die):
Using Cucumber

Preloading Rails environment
WARNING: Cucumber-rails required outside of env.rb.  The rest of loading is being defered until env.rb is called.
  To avoid this warning, move 'gem cucumber-rails' under only group :test in your Gemfile
Loading Spork.prefork block...
undefined method `allow_rescue=' for ActionController::Base:Class (NoMethodError)

I couldn't find any erroneous require's of cucumber-rails outside my :test group in my Gemfile, but eventually I stumbled across the solution in the comments of this pull request (for a separate issue).

I had to change the line in my Gemfile to:

gem "cucumber-rails", "~> 1.0", require: false

For the error message to go away, and spork to run properly. It seems to have been caused by a way the new (prerelease/1.1) version of Bundler loads gems - what a bitch (but it is a lot faster than the older versions, so I'm still using it).

Testing objects in Cucumber

it always takes me a search and a few clicks to find this article on how to use FactoryGirl with Cucumber: https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md

not. anymore.

WARNING: i18n methods within step definitions are deprecated

When running some older step definition files with a newer version of Cukes, I kept getting the message "WARNING: i18n methods within step definitions are deprecated..." even though I couldn't see any il8n methods in my cucumber files.

After a bit of digging, I found that you need to update your steps files so that you don't use any And/Then/When/Given methods inside your steps, and instead use the method step - but this only applies inside your step definitions. For example this:

When /^I sign in as "(.*)\/(.*)"$/ do |email, password|
  Given %{I am not logged in}
  When %{I go to the sign in page}
  And %{I fill in "Email" with "#{email}"}
  And %{I fill in "Password" with "#{password}"}
  And %{I press "Sign in"}
end

Changes to:

When /^I sign in as "(.*)\/(.*)"$/ do |email, password|
  step %{I am not logged in}
  step %{I go to the sign in page}
  step %{I fill in "Email" with "#{email}"}
  step %{I fill in "Password" with "#{password}"}
  step %{I press "Sign in"}
end

Even GitHub Loves Sctoch

Behold, ScottoCat!

Using GitHub to get better at Ruby

Aside from being a great site to host open source software, GitHub is a great place to review other people's code. By following all the repositories you're interested in, you get to see all their latest updates on your dashboard when you log in. I've found it useful for writing better specs/scenarios - when I get writer's block, I go look at some of the bigger Ruby-based projects on Github for ideas.

Another cool thing to do is search repos for specific gems/libraries that you are interested in using, or trying to get your head around. When you search GitHub, you can do a search with very specific parameters.

For example: Search "Code" with language "Ruby" and term "require savon" to see other projects using the Savon gem - because consuming SOAP services in Ruby are so much fun! I mean, it's almost as good as getting teeth pulled... (Savon makes it bearable)

Rails 3.1, Spree, and "rake aborted! Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes"

I keep getting the following error when trying to run Rails 3.1 with Spree commerce, right when running my first rake command 'rake db:create':
$ rake db:create

rake aborted!
Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes.


(See full trace by running task with --trace)

The solution is to manually add the following gems to your gem file (and run the obligatory 'bundle install' afterwards):
gem 'execjs'
gem 'therubyracer'

Hope that helps.

Bundle Install gives Gem::Exception: Cannot load gem at

While trying to install someone else's Rails 3.0.x app on my dev server, the 'bundle install' command kept failing, with an error about the cache location for gems.
$ bundle install

Fetching source index for http://rubygems.org/


Gem::Exception: Cannot load gem at [/usr/lib/ruby/gems/1.9.1/cache/rake-0.8.7.gem] in /home/rowan/newprj
An error occured while installing rake (0.8.7), and Bundler cannot continue.
Make sure that `gem install rake -v '0.8.7'` succeeds before bundling.

After reading a StackOverflow post on a similar error message I found that the way around it is to do a bundle install as root:

$ sudo bundle install

This isn't the right way to do it normally, and I don't recommend it, but it does seem to be necessary at the moment because Ubuntu (11.x) has Ruby 1.9.2 packaged under the 1.9.1 label/location.

We don't need no stinkin' web steps!

I spent my first attempts back in BDD-land wondering why all the examples I was reading kept referring to Capybara's web_steps.rb file, and why I didn't have it. It all made sense when I finally found this article by Aslak.

The file web_steps.rb was originally in Webrat (which is what I used last time I was doing Rails apps in Rails 2.3). It contained a bunch of pre-defined, regex-dependent steps which could be incorporated in to your scenarios for quick development of - but ultimately limiting - your scenarios.

Read the article for the full reasons behind it. It seems a bit of an inconvenience for someone starting out, but seeing as Aslak created Cucumber, I'm not going to argue with him about the finer points of BDD.

The Capybara API is what you should be using instead to replace web_steps.rb functionality in the future.

Forcing the system update command for ruby gems on Ubuntu 11.04

If you try run Ruby Gem's command to update itself ($ sudo gem update --system) on Ubuntu you get a pretty stern warning that it's not recommended, and you might have issues blah blah blah.

There's a bunch of gems which complain if your gem version is out of date (and the default version with Ubuntu is), and I don't know when the official package will be updated.

Just so I know for next time, the command to force it to upgrade (at your own risk) is:
$ sudo REALLY_GEM_UPDATE_SYSTEM=1 gem update --system

I haven't had any problems from this on 11.04, but as always YMMV.

Getting VCR to work with Rspec

I'm writing an SOAP API wrapper in Ruby, and there's no test system to use during development. Being about to use something like VCR to record the request/response from the service is great, because I can do it a controlled fashion the first time (and record it), and then do stupid things to it without getting in to trouble. It also helps my features and tests run much faster than if I had to actually ping the server every time.

I found Cucumber and VCR's official documentation good, but over-complicated for what I wanted to do. Here are the steps it actually took me to get it working quickly and simply in my features (using fakeweb).

1. Create the file 'features/support/vcr.rb' with the following contents:
require 'vcr'

VCR.config do |c|
  c.stub_with :fakeweb
  c.cassette_library_dir = 'features/cassettes'
end

2. Inside the step definitions (in my steps files under 'features/steps/'):
VCR.use_cassette 'name' do
  ...
end

This will create the cassette file 'name' in the 'features/cassettes' directory. After recording your request/response the first time, any additional communications will be stopped by VCR, because the default options for VCR sets record to 'new episodes'.