Archive for the ‘Rails’ category

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’
end
end

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.

 

No comments »

Posted in Rails, ruby

Tags:

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 https://rvm.beginrescueend.com/install/rvm)
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.
WARNING:
Could not source ‘/home/ethan/.rvm/scripts/base’ as file does not exist.
RVM will likely not work as expected.
WARNING:
Could not source ‘/home/ethan/.rvm/scripts/version’ as file does not exist.
RVM will likely not work as expected.
WARNING:
Could not source ‘/home/ethan/.rvm/scripts/selector’ as file does not exist.
RVM will likely not work as expected.
WARNING:
Could not source ‘/home/ethan/.rvm/scripts/cd’ as file does not exist.
RVM will likely not work as expected.
WARNING:
Could not source ‘/home/ethan/.rvm/scripts/cli’ as file does not exist.
RVM will likely not work as expected.
WARNING:
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

fi

[[ -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.

2 comments »

Posted in Linux, Rails, ruby, software

Tags:

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.

No comments »

Posted in Rails, ruby, Uncategorized

Tags:

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.

4 comments »

Posted in Rails, ruby, software

Tags:

Renaming a database in Rails

December 14th, 2009

Hooray for a non-rant post!

The heart of this method works outside of Rails, but there’s one particular convenience method that Rails provides.  Find some way to mimic that behavior, and the rest would apply.  Also, this is a MySQL-specific solution.  I haven’t tried it with any other DB systems.

We “rename” a database by moving all of its tables into a new database.  We do so via MySQL’s RENAME TABLE command.  Basically, create an empty database with the new name.  We then use our ActiveRecord connection’s “tables” method to loop over all the tables in our database, executing a RENAME TABLE from the old to the new with each iteration. “Tables” is the convenience method I mentioned above. Encapsulating this in a method we get:

def rename_database(old_db_name, new_db_name)
    ActiveRecord::Base.connection.execute "CREATE DATABASE #{new_db_name}"
    ActiveRecord::Base.connection.tables.each do |table|
        ActiveRecord::Base.connection.execute
            "RENAME TABLE #{old_db_name}.#{table} TO #{new_db_name}.#{table}"
    end
    ActiveRecord::Base.connection.execute "DROP DATABASE #{old_db_name}"
end

Error checking is left as an (important!) exercise to the reader.  Also, you may prefer to monkey patch this into ActiveRecord itself as opposed to some odd method floating around in global space.

This presupposes that the new database destination will be on the same server.

Another way to rename a database is to mysqldump the old one to a file and then reimport it to the renamed database.  The method presented in this article is advantageous if your database has a large amount of data.  Renaming a table is almost instant.  Dumping millions of rows and reimporting them is not so instant.

No comments »

Posted in Databases, Rails, ruby, software

Tags:

uninitialized constant Thin::Server::Forwardable

July 2nd, 2009

I may be getting batty in my old age here, but for whatever reason Thin decided to just stop running on my system.  When trying to invoke thin to further development on the code behind my awesome website, I was treated to the following:


ethan:ethang juanpaco$ thin start
/Library/Ruby/Gems/1.8/gems/thin-1.0.0/lib/thin/server.rb:51: uninitialized constant Thin::Server::Forwardable (NameError)
from /Library/Ruby/Gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:38:in `initialize'
from /Library/Ruby/Gems/1.8/gems/thin-1.0.0/bin/thin:6:in `new'
from /Library/Ruby/Gems/1.8/gems/thin-1.0.0/bin/thin:6
from /usr/bin/thin:19:in `load'
from /usr/bin/thin:19

I didn’t like that.

I went to the line number where the error occurred (/Library/Ruby/Gems/1.8/gems/thin-1.0.0/lib/thin/server.rb:51), and found:
extend Forwardable

Not knowing what Forwardable was, and for giggles, I went to irb and typed “Forwardable” thinking I’d get the class object.  Not defined.  So I try “require ‘forwardable’.”  There was no period in what I typed, but I haven’t figured out how to get Ruby and English to play well together.  Anyway, that worked, and a subsequent typing of “Forwardable” returned the object. So then I tried putting require ‘forwardable’ at the top of server.rb in thin’s gem.

And then it worked.

I’m not sure why it used to work and then suddenly didn’t.  This was after several install/uninstall, swear off programming moments.  Weird.  So, if you’re struggling with this same problem, perhaps the above can be of service.

2 comments »

Posted in Rails, software

Tags:

Debuggin’ in Rails

December 26th, 2008

This is a for-my-benefit-reference post like the last 2.  Perhaps I’ll do a better write-up of ruby-debug at a later time.

“info breakpoints” to see the list of set breakpoints.

No comments »

Posted in Rails

Tags:

Multiple versions of Rails on the same machine

September 3rd, 2008

One of the purposes of this blog is a place where I can catalogue stuff and find it again later.  That is one of the purposes of this post.

I have multiple versions of Rails on my computer, and I wanted to create a new sandbox application with one of the older ones.  I didn’t know how to do it, until I found this post.

That post is more in-depth.  The quick and dirty is the command:

rails _<railsversion>_ <app name>

Example: rails _1.2.3_ test

Note that there is a space between “rails” and the first underscore, as well as one between the last underscore and “<app name>.”

Hat is off to you SIDDHARTH.

No comments »

Posted in Rails

Tags:

Production mode cluster conundrum

July 16th, 2008

I wish I had some cool screenshots for this one, but hopefully a text-based description will suffice.

So I fixed a bug at work, where certain AJAX calls were failing.  It turns out that our view templates were making some assumptions that they ought not to have been making.  I fixed that error, and our QA team pushed that code out to our test servers (along with other things– I wasn’t that important).  Well, the error, or at least its symptoms, showed up again.  Now, it only showed up sometimes, and only on the test server.  “It works on my machine,” not being much of a solution to a bug, I started investigating.

I looked into the error logs that were being generated, and saw what looked like the sort of error you get when you call a helper method which doesn’t exist.  As part of the bug fix, I added a helper method.  We checked manually the code that was running on the server, and it had the helper method and the full new version of the code.  At this point I began suspecting the work of some foul dark wizard– or at least a gremlin.  I mean, why else would a view template not be able to find a helper method that is there after the server has been restarted?

I’ll tell you why.  We have a cluster configuration, and Capistrano or something else, hadn’t shut down every process running the old code.  Since AJAX calls are full-blown server requests that just happen not to refresh the whole browser page, some of those calls were directed to server processes that hadn’t actually been restarted.  Rails doesn’t auto-refresh code in production mode (Good Thing), so those old processes quite naturally didn’t find the new code.  We killed the old processes and, presto!  The world is right again.

So, if you ever find yourself wondering why your view template can’t find your helper method, check to make sure that your server restart restarted ALL instances of your application. We’re still not entirely sure why all instances didn’t restart though.

So, Dark Wizards may still be involved.

No comments »

Posted in Rails

Tags: