Files were being uploaded fine, but my thumbnail and other variations were not generating. The documentation says that the whiny_thumbnails option defaults to true, but my reality seems to dictate otherwise.

After I added that…

has_attached_file :receipt, 
                  :styles => { :medium => "600x600>", :thumb => "100x100>" }, 
                  :whiny_thumbnails => true

…I was at least getting an error:

/tmp/stream.13496.0 is not recognized by the 'identify' command.

At long last, I figured that the error message is totally inaccurate. What it really meant is “I’m looking for ‘identify’ in /usr/bin instead of /opt/local/bin even though /opt/local/bin is in your user path”.

For fixing:

cd /usr/bin
sudo ln -s  /opt/local/bin/convert convert
sudo ln -s  /opt/local/bin/identify identify

You’ll probably only have this problem if you installed ImageMagick via MacPorts (as I did). I probably could have fixed it by adding /opt/local/bin to the $PATH used by the web server user, but whatever. This worked.

With some of the recent discussion surrounding “monkey patching” in Ruby, I think that the timing seems about right, for some serious thought to be given about the long-term effects of maintaining Ruby-based code-bases, should prolific “monkey patching” continue to be used haphazardly by many of the libraries, plugins, gems and other code that makes (sometimes critical?) modifications to the underlying core language classes.

Nick Sieger has crafted a thoughtful response to Avdi, which includes the quote:

[Monkey patching is] still a basic part of the Ruby programming culture, like it or not.

While Nick is totally correct, and Ruby does give you the power to shoot, maim and otherwise pillage and murder yourself in a bazillion different ways – that doesn’t take away the fact that it is still an incredibly powerful, elegant and syntactically beautiful programming language.

At the risk of sounding like a trite broken record (for the 485,000 time), I think that once again it boils down to using and choosing the right tools for the job. If the consequences of Ruby’s dynamism (among whatever other consequences) outweigh the positive benefits that a Ruby solution provides – then choose a different tool.

You can complain about the verbosity of a language like Java all you want (heck, I know I do at times), but I come back to Java sometimes after working with Ruby for a few months, and I’m all of a sudden thankful for strict, static typing, always knowing what I’m gonna get.

What continues to irk me are the folks who seem completely hell-bent that their way is the only One True Wayâ„¢.

I was in a job interview the other day (company name shall be kept confidential) at a place that does extensive software development in many languages including Java, C, C++, Perl and PHP (at the very least). Near the end of the interview, we were discussing different languages, and I mentioned how sometimes I really enjoy the dynamic typing facet of Ruby, as opposed to the statically typed facet of Java. At this statement, one of the interviewers piped up to tell me that the fact that I enjoyed dynamic typing at times was “the most brain-dead thing” he’d ever heard anyone say.

It seems so strange to me, to be on the receiving end of an insult like that, coming from a company that performs extensive development in PHP (which is not only dynamically typed, but also weakly typed, as opposed to Ruby which is strictly typed).

At any rate, all of that comes to some sort of summary that everyone should already know by now:

1. there is no silver bullet
2. think before you choose your tool/language/whatever
3. don’t hate the unknown simply because it’s unknown
4. don’t call someone brain-dead if they sometimes enjoy a programming language that is dynamically typed, it hurts their feelings
5. read Avdi’s series on sustainable development in Ruby.

It turns out this was reported as JRUBY-2018 and resolved, but there wasn’t a release of activerecord-jdbc that contained the fix.

Being impatient like I am, I grabbed the head from svn and built it myself. So if you ever find you need to build yourself an activerecord-jdbc gem from subversion, here you go:

First make sure you have hoe installed.

jruby -S gem install hoe

Grab the source from svn.

svn co http://jruby-extras.rubyforge.org/svn/trunk/activerecord-jdbc

Build the .gem

jruby -S rake package

Install the generated .gem file.

jruby -S gem install activerecord-jdbc-adapter-[version].gem

MAKE SURE YOU UNINSTALL YOUR PREVIOUS VERSION

The chances that you’ll have to do this are very slim. Nick Sieger is usually super-on-top of making sure things are up and working the way they should be, but just in case.

James Duncan Davidson has a great overview article (that needs no further explaining from myself), titled Sandboxing Rails With MacPorts. Another similar article can be found here.

My problem is that I work on a lot of projects that use ImageMagick / RMagick, and that’s not discussed here.

No worries, I’ll install ‘em and give it a go:

sudo port intall ImageMagick
sudo gem install rmagick

CRAP! I don’t know what happens for you, but ImageMagick installs perfectly for me, and then RMagick craps out and dies something like this:

/opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:321:in `get_type_metrics': 
unable to read font `(null)' (Magick::ImageMagickError)
 from /opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:321:in `render'
 from /opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:696:in `text'

Now, for the solution I am going to give all credit to Jakob Skjerning, because I found the solution on his site after doing some Googling.

Do this instead:

sudo port install ImageMagick
sudo port install rb-rmagick

Done. Works. Thank goodness.