Category archives: Rails

Restarting Rails

12Dec10

I’ve been in my comfort zone for far too long now. Over roughly the last one and a half years, I’ve acquired a lot of cruft. Physical cruft. Mental cruft. Things I should have adopted a while ago but didn’t. Stuff I should have stopped doing but still do. Ugly hacks and workarounds I’ve gotten used to. Small to medium pains I’ve ignored too long.

A few examples:

  • not using Rails 3, Bundler and Ruby 1.9
  • proper integration testing
  • copy and pasting stuff from old projects into new ones
  • new project setup in general
  • still using Apache, Passenger 2 and system-wide RVM for deployment
  • setting up new Rails projects takes me about an hour by
  • and so on, and so on …

It’s time for all this to change. I’ve already spent around three days reading up on various topics, and boy, it’s a lot to take in. So in order to help me remember what I’ve learned and what’s still on the list, I will accompany this process with a series of articles.

Some of these will not be much more than a list of hand-filtered and commented links, or a bunch of free-form notes. I had originally hoped to get away from WordPress before starting this, but I haven’t. In the end it’s just a tool, it will suffice, and putting off writing because of it would be nothing but an excuse for more procrastination.

So on with it! The rough outline of the series will be as follows:

  • Rails 3, Ruby 1.9 and Bundler
    • architecture
    • what’s new
    • gotchas
  • Rails application templates
  • Improving my testing habits
  • Hosting and deployment
    • Passenger 3, custom RVM gemsets and Capistrano
  • Better code reuse
    • Writing and publishing my own gems
  • Frontend
    • Paul Irish’s HTML5 Boilerplate
    • Improving my asset management: better JS and CSS delivery
    • HAML: worth it?
  • Development, workflow and good practises
Filed under miscellaneous, Rails, web development| Tagged | No Comments

Ruby Enterprise Edition on OS X – a Quick Caveat

22Sep09

The gist: when trying to install RubyEE, remove all gems installed to ~/.gem first. Otherwise you will encounter exceptions like 

[BUG] cross-thread violation on rb_gc()

Installing Ruby Enterprise Edition on OS X is pretty easy and straight forward; it installs itself to /opt/ruby-enterprise-<version>, along with its own copy of RubyGems.

RubyGems installed with the standard MRI Ruby do not work with RubyEE and have to be installed a second time using /opt/ruby-enterprise-<version>/bin/gem.

The caveat: both /usr/bin/gem and /opt/ruby-enterprise-<version>/bin/gem try to load gems from your personal gem path at ~/.gem first before looking in their respective gem paths. For example, if you have bluecloth installed to ~/.gem using the standard MRI ruby, RubyEE will try to load it and throw exceptions like 

[BUG] cross-thread violation on rb_gc()

To solve this, you can either remove ~/.gem from your GEM_PATH environment variable, or simply uninstall all gems from there and reinstall them properly to /usr/lib/ruby using sudo gem install.

Filed under flotsam & jetsam, Rails| Tagged | No Comments

Rails on the menu(bar)

06Sep09
The Rails API in your Mac's menu bar

The Rails API in your Mac's menu bar

Today I learned that Fluid, the Mac app that lets you create Single-Site Browsers, has the ability to create custom menu bar items as well — sweet!

So, how does “ajax-powered Rails API documentation in your menu bar, complete with keyboard shortcut” sound? Take a look at this short screencast, courtesy of yours truly:

Filed under OS X, Rails| Tagged , , , | 1 Comment

Rails, Postgres, Snow Leopard and 64bit: a word of warning

31Aug09

After zipping through a painless upgrade to OSX 10.6 Snow Leopard on both my Macs, I found myself banging my head against the wall trying to get my Rails + Postgres stack running again.

There is a lot of great information out there on how to get everything up to 64bit goodness, and I merrily began the uninstall/recompile/reinstall dance. What followed was an excruciating eight hours of trying to get Postgres to compile to 64bit, and the pg gem — or any Postgres adapter for that matter — to link against it.

Long story short: make sure you actually have a 64bit Mac. Let me say that again: make sure your Mac is actually running Snow Leopard in 64bit.

As embarrassing as this, at some point I finally realized that both my Macs used Core Duo chips, not Core 2 Duos – which makes my Snow Leopard a plain-old 32bit installation. Markus Winter on A hat full of sky has a lot of great information on the subject matter, as well as a program that shows you exactly what mode your system is running in, and why.

So, us 32bit cat owners still have to compile pg with

sudo env ARCHFLAGS='i386' gem install pg -- --with-pgsql-dir=/usr/local/pgsql

- just as we had to on 10.5 Leopard.

What I hope to have learned from this:

  1. Postgres is a fifteen year old project, crafted in ten thousands of man hours by countless programmers all smarter than me
  2. Next time it tells me it does not want to compile in 64bit, I’ll listen.
Filed under OS X, Rails| Tagged , , | 3 Comments

How to change the output directory of metric_fu

15Aug09

I would like to treat the great reports generated by metric_fu as documentation and keep them in my repository. So how do we convince it to save its output in doc/ instead of tmp/ ?

Stew Welbourne has the answer:

MetricFu::Configuration.run do |config|
  config.base_directory     = 'doc/metrics'
  config.scratch_directory  = File.join(config.base_directory, 'scratch')
  config.output_directory   = File.join(config.base_directory, 'output')
  config.data_directory     = File.join(config.base_directory, '_data')

  config.saikuro  = { :o utput_directory => File.join(config.scratch_directory, 'saikuro'),

  # the rest of your configuration goes here
end

Just make sure that your new target directory is two folders deep, as the original tmp/metric_fu is, or you may get in trouble with the graphing part of metric_fu. Voilà!

Filed under Rails| Tagged , , | No Comments