Archive for the ‘ruby’ category

Deploying GitHub gems to AppFog

February 28th, 2013

Mega-big thanks to georgebrock on this Stack Overflow question.

I was trying to deploy to AppFog using a Ruby Gem that wasn’t published on  Well, it was, but this was someone else’s fork of it.

To make that work, in your Gemfile, don’t use the “git@” version of a GitHub repo’s URL.  Use the “git://” version.  For example:

gem 'best_in_place', 


gem 'best_in_place', 

Apparently, that’s how you deal with it on Heroku too.

postgresql rails and rake db:test:prepare

August 23rd, 2012

I am very new to postgresql.  Lots of folks use it and swear by it.  I have no complaints with it as a database and query engine.  I struggle with the administrative aspects of it.

A rails project I’m working on uses postgresql and uses databases with UTF8 encoding.  Well, if you’ve ever dived into what rake db:test:prepare does, you’ll know that along the chain it drops and recreates your databases.  That, of cource, necessitates that your user have sufficient privileges to create databases.  Straightforward stuff.

Well, today when trying to run my tests I was getting the generic error:

Couldn’t create database for {“adapter”=>”postgresql”, “database”=>”ha_ya_right”, “password”=>”nopes”, “pool”=>5, “timeout”=>5000, “username”=>”uh_uh”}

That was at the end of the reams of backtrace.  The magic was at the top of those reams:

PG::Error: ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)

HINT:  Use the same encoding as in the template database, or use template0 as template.

Yeah, templates.  I missed that error and ended up using ruby-debug (best. gem. ever.) and breaking right in the postgresql connection adapter.  I’ll have to remember to remove that line.

Anyway, my system is running Ubuntu 12.04, PostgreSQL 9.1.4, Ruby 1.9.2, and Rails 3.2.3.  I had to get the database connection to use template0.  It’s quite easy:

  adapter: postgresql
  database: ha_ya_right
  password: nopes
  pool: 5
  timeout: 5000
  username: uh_uh
  template: template0

That last line is the money line. I mentioned all my environment specs, because some folks in the blogs I came across said that solution didn’t work for them. Hopefully this can save you some time.

Testing ActiveResource::HttpMock with basic auth

August 3rd, 2012

ActiveResource::HttpMock is somewhat of a lesser-known part of Rails testing.  If you use ActiveResource, it can be your friend.

At least until you try testing against an API that requires Basic Authentication.  As the docs illustrate, you use HttpMock by explicitly declaring what I’ll call a request signature for every request that your software will make.  That signature request includes the path, HTTP verb, and request headers.  Basic Authentication is sent in the request headers, but the API docs do not show how to do that.

So here’s how you do that:

encoded_vals = Base64.encode64("#{<basic auth username>}:#{<basic auth password>}").gsub("\n",'')

auth_headers = {
  'Authorization' => "Basic #{encoded_vals}",
  'Accept'        => 'application/json'

ActiveResource::HttpMock.respond_to do |mock|
  mock.get "/awesome_api/users/1.json", auth_headers, <expected results and so forth>

1/2 of the magic is on the line where we set encoded_vals.  The credentials need to be Base64 encoded.  The one trick is to remember to remove the newline characters encode64 will insert.  The other 1/2 is constructinga hash with appropriate keys and values, which we do with the auth_headers hash.

Lastly, we make the actual call to set up our mock.  You include your path and verb, include the headers, and then include your other arguments.  In this particular example, we’d probably expect a JSON blob back, so we’d want to have a valid JSON string.  You can further include status codes and so forth as the documentation describes.

Happy coding!

Rake running tests in development mode

August 2nd, 2012

This issue is well-known, but the solution doesn’t show up in google searches very easily.

Rails 3.2.7 introduced a change which loads the Rails config as part of the rake bootup process (ht: GitHub user krsmurata).  This means that by the time rspec runs, the Rails environment is already set to development, meaning your tests attempt to run in development.  This means that you could see some neat failures and that your development database may get blown away.

The core team is currently rushing Rails 3.2.8 out the door to address this problem and remove a number of deprecation warnings that 3.2.7 added.  The RC was put out this morning, I believe, and the release is scheduled for this Friday (tomorrow 3 August 2012).

In the meantime, if you’re using RSpec, you can change a line in your spec_helper to get you through this.  Change the line which reads:

ENV["RAILS_ENV"] ||= ‘test’


ENV["RAILS_ENV"] = ‘test’

Alternatively you can just go back to Rails 3.2.6.(ht:

Big gotcha with Carrierwave and custom versions/processors

October 17th, 2011

Short version: Make bloody sure your versions don’t have the same name as your methods you call with process:

Long version:

I forget the exact sequence that brought me to this problem, but I was doing baby steps through setting up some custom versions and processes with Carrierwave.  I had set up the following (roughly):

class PreviewUploader < CarrierWave::Uploader::Base

version :detail_bob do

process :detail_bob => ‘bob’

I had an included file in lib that defined “detail_bob.”  I was getting the error:

ArgumentError: wrong number of arguments (1 for 0)

The best part was that I’d get THAT error even if I removed the include for my library file that defined detail_bob!  I would have expected something more along the lines of “undefined method,” or something like that.

Anyway, it turned out that giving the version and the process call the same name was causing the problem.  I suspect that the process call was invoking method “detail_bob” that was defined by the version call.  Since the lib file was included before the call to version (naturally), the version overrode the lib file version.

Hopefully this can save you some grief.

RVM woes on Ubuntu 11.04

May 19th, 2011

Having had an epiphany the other day, I needed this morning to start work on a new prototype.  This post isn’t about that prototype.

It IS about the new setup I was using to do that prototype.  I figured this was a good chance to try out RVM in a Rails project, as well as try out Ubuntu 11.04, as well as install the OS in French.  So, with the new VM up and running, I follow RVM’s installation instructions, anticipation building with each scrolling character.  And then… BAM!

ethan@ubuntu11:~/rvmsource$ bash < <(curl -s
Cloning into rvm…
remote: Counting objects: 4765, done.
remote: Compressing objects: 100% (2433/2433), done.
remote: Total 4765 (delta 3086), reused 3183 (delta 1672)
Receiving objects: 100% (4765/4765), 1.57 MiB | 322 KiB/s, done.
Resolving deltas: 100% (3086/3086), done.
Could not source ‘/home/ethan/.rvm/scripts/base’ as file does not exist.
RVM will likely not work as expected.
Could not source ‘/home/ethan/.rvm/scripts/version’ as file does not exist.
RVM will likely not work as expected.
Could not source ‘/home/ethan/.rvm/scripts/selector’ as file does not exist.
RVM will likely not work as expected.
Could not source ‘/home/ethan/.rvm/scripts/cd’ as file does not exist.
RVM will likely not work as expected.
Could not source ‘/home/ethan/.rvm/scripts/cli’ as file does not exist.
RVM will likely not work as expected.
Could not source ‘/home/ethan/.rvm/scripts/override_gem’ as file does not exist.
RVM will likely not work as expected.
cat: /home/ethan/.rvm/VERSION: Aucun fichier ou dossier de ce type

A few Google searches turned up a few people having a similar problem but no solutions.  But whould’ve thunk it that installing the OS in French would actually have some practical value?  Google must’ve seen that and then dumped me on to this forum, wherein one of the posters linked to this post, which basically says to just follow the directions that RVM spit out as part of the big error message.  Who’d've thunk THAT?  I sure didn’t.  I just focused on the error message itself in my searches.

WARNING:  you have a ‘return’ statement in your ~/.bashrc
This could cause some features of RVM to not work.

This means that if you see something like:

‘[ -z "$PS1" ] && return’

then you change this line to:

if [[ -n "$PS1" ]] ; then

# … original content that was below the ‘&& return’ line …

fi # <= be sure to close the if at the end of the .bashrc.

# This is a good place to source rvm v v v
[[ -s "/home/ethan/.rvm/scripts/rvm" ]] && source “/home/ethan/.rvm/scripts/rvm”  # This loads RVM into a shell session.

It looks like RVM tries to run outside of a standard shell session, and the way .bashrc is configured by default on Ubuntu 11.04 prevents that sort of thing.  When you’re done with your edits your .bashrc should look something like this:

# ‘[ -z "$PS1" ] && return’ <—– delete this line.  It isn’t commented out in the original

if [[ -n "$PS1" ]] ; then

# the rest of your old .bashrc contents


[[ -s "/home/ethan/.rvm/scripts/rvm" ]] && source “/home/ethan/.rvm/scripts/rvm”  # This loads RVM into a shell session.

After making that change I re-ran the installation instructions, and PRESTO!  Or maybe I should say, Voilà!  As always, YMMV.  I really don’t think it was the double install that fixed the problem.  And be sure to replace “ethan” with whatever your actual path is.  That happens to be mine, because, well, that’s my name.

Deprecation warnings in Rails

March 22nd, 2011

Are you working on an ever-evolving code base? Did your project start with an initial engineering effort to fix a specific problem / explore the solution space? As requirements are more fully understood, are you increasingly annoyed with the older code to support different data formats and the like? Do you want to get developers and others to stop using those old formats?

Well, you too can have access to what Rails uses to put deprecation warnings in the log file.

ActiveSupport::Deprecation.warn("Stop calling me!")

It of course takes a good team policy to require all such warnings to be removed, but I was delighted to find that this is readily available and usable for my own deprecation warnings. It sure beats using Rails.logger, because the intent is clearer, and such warnings will get shut off when all deprecation warnings are turned off anyway.

When having trouble installing the mysql gem on OSX

April 21st, 2010

And you get an error like:

*** extconf.rb failed ***

Go read:

Paperclip/ImageMagick/RMagick error: “is not recognized by the ‘identify’ command”

December 30th, 2009

If you’re using the above combination, and you’re getting the above error, make sure that you’ve configured Paperclip to find ImageMagick in the right place.  Create an initializer file, RAILS_ROOT/config/intializers/paperclip.rb, and put “Paperclip.options[:image_magick_path] = ‘path/to/image_magic’” inside of it.  On Mac or a *nix system, type “which identify” to find the right folder.

Big thanks to avit on this forum for the solution.

Installing Ruby gems that require building native extensions on Snow Leopard

December 18th, 2009

I haven’t tested this on all “machines” running Snow Leopard, but on the brand new one I had to get today for work, I found that the default Ruby / Gems install doesn’t support installing gems that require building native extensions. The error message I was treated to contained the following:

MacBook-Pro-de-Ethan-Garofolo:~ juanpaco$ sudo gem install thin
Building native extensions. This could take a while...
ERROR: Error installing thin:
ERROR: Failed to build gem native extension.

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb install thin
mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ruby.h

Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/eventmachine-0.12.10 for inspection.
Results logged to /Library/Ruby/Gems/1.8/gems/eventmachine-0.12.10/ext/gem_make.out

The solution was hyper-intuitive. Install XCode. Because of course that's the first thing you think of.