Sometimes a new Ubuntu image will pop-up messages like:
man: can't set the locale; make sure $LC_* and $LANG are correct
It doesn't stop anything from working, it just gets annoying. It seems to be an release problem, and can be quickly fixed by adding an LC_ALL and LANG definition to /etc/environment like this:
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
Other valid values is "en_GB.UTF-8" and "en_AU.UTF-8".
After adding those lines, I had to regenerate the locales with:
$ sudo locale-gen en_US
$ sudo locale-gen en_US.UTF-8
Check out Ubuntu's Environment Variables if you want to know more.
Friday, December 14, 2012
Tuesday, December 13, 2011
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:
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:
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:
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:
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.
# 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.
Tuesday, November 22, 2011
"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
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).
Wednesday, November 16, 2011
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.
not. anymore.
Monday, November 14, 2011
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
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
Sunday, November 6, 2011
Saturday, November 5, 2011
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)
Subscribe to:
Posts (Atom)