Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Starting MySQL after upgrading to OS X Leopard

Posted by Sat, 27 Oct 2007 10:13:00 GMT

If you upgraded to OS X Leopard and are running MySQL from the installer1, you might be having some problems with starting it from the GUI interface. There isn’t a fix from MySQL yet, so to get around that… you can run it from the command-line.

Start MySQL from the command line

cd /usr/local/mysql; ./bin/mysqld_safe &

This should get MySQL up and running for you. If someone wants to share a tip on how to get this to start automatically on reboot, please post a comment and I’ll help get the word out.

1 I didn’t have this problem as I installed MySQL via MacPorts... but this came up for a few members of PLANET ARGON after they upgraded to Leopard.

Using MacPorts Ruby and Rails after Upgrading to OS X Leopard

Posted by Sat, 27 Oct 2007 09:43:00 GMT

If you previously followed my article, Installing Ruby on Rails and PostgreSQL on OS X, second edition and are now upgrading to OS X Leopard, you’ll want to make a few adjustments to your setup.

First of all, it’s great that Apple has decided to provide Ruby on Rails out of the box.

~ > gem list rails                                                                                                                                                                   
  *** LOCAL GEMS ***

  rails (1.2.3)
      Web-application framework with template engine, control-flow layer,
      and ORM.
How many gems does it come with?

~ > gem list|grep '^[a-z]'|wc -l                                                                                                                                                     

It’s really great that Apple shipped Leopard pre-installed with 29 gems, especially if you don’t have your entire Rails stack setup already. In my case and for those that have followed my installation process, you don’t need to switch over to this new development stack (yet). I have a lot of time invested in my fully-functionaly MacPorts installation process (PostgreSQL, MySQL, RMagick, Subversion, Git, etc. Since this all working fine on my machine, I’m not ready to make the switch to Apple’s installation.

Don’t Fix it… if it’s not broken!

So, the the first thing that I did was modify my PATH environment variable, which has /usr/bin as the first path that it’ll look at when you try to run commands like ruby, mongrel_rails, gem, etc. You’ll want to modify this and prepend /opt/local/bin: to the front of PATH in your shell configuration. If you’re using bash, this would be… ~/.bashrc. If you’re using zshell like me, ~/.zshrc.

Now, when you start a new Terminal and run gem list, you’ll see all of the gems that you already have installed.

~ > gem list rails                                                                                                                                   < new-host

*** LOCAL GEMS ***

rails (1.2.5, 1.2.4, 1.2.3, 1.1.6)
    Web-application framework with template engine, control-flow layer,
    and ORM.

Back to my happy gems…

~ > gem list|grep '^[a-z]'|wc -l                                                                                                                                                              < new-host

Great! Now I can get back to work and spend time playing with the new features in Finder,, and iChat instead of installing all of the software dependencies that our development projects have. :-)

OS X Leopard Tip: Skitch on Every Space

Posted by Sat, 27 Oct 2007 02:43:00 GMT

If you’re using Skitch and the new Spaces in OS X Leopard, I would encourage you to set the following up.

This will allow you to use Skitch on any Space without needing to move it around. Took me a few minutes to figure out that I could set it up like this.

As you can see… I’m on Leopard now… only took three tries.

Chad Fowler's Dirty Little Secret?

Posted by Sat, 06 Oct 2007 19:00:00 GMT

I saw this photo of the Microsoft team from 1978 on Anselm’s flickr and thought, “Hmm, that looks like Chad Fowler!”

Could this be Chad Fowler’s dirty little secret?..

Happy Saturday!

Spice up your Terminal with colored grep pattern results

Posted by Sat, 06 Oct 2007 16:43:00 GMT

Earlier, I came across a post by Garry Dolley, which he shows how to acheive colorized grep matches in bash. I recall having color matches when I used to use Linux on a daily basis as my primary work environment, but haven’t gotten around to setting this up on my MacBook, which is where I do almost all of my development work.


If you don’t already have colors, a grep in your terminal might look something like the following screenshot.

While, I have a very small output here, this gets much crazier when you’re using egrep across an entire project. It’s hard to scan through all of the results for the inline pattern matches.

So, taking Garry’s suggestion (for bash), I did something similar with my favorite shell, Z shell.

Add the following to your ~/.zshrc file to begin experimenting with the colors.

  export GREP_OPTIONS='--color=auto' 
  export GREP_COLOR='1;36'


With the new variables defined in my .zshrc, I can now start to see colors showing up in my grep results.

Pretty cool, huh?


To save you the trouble of trying tons of combinations yourself, which I suspect you’ll do anyways, here are some other variants.


If you change the first number in GREP_COLOR to 5, you’re matches will blink!

You’ll have to experiment with this yourself as I’m not going to make a video for you. ;-)

  export GREP_COLOR='5;35'

Inverted Colors

You can also invert the colors so that the background color changes on your pattern matches.

For example:

To achieve this, you can set the first number in GREP_COLOR to 7.

...and so much more

I decided to write a quick and ugly ruby script to iterate through the color combinations that I was trying.

Anyhow, I’ll leave you on that note. If you figure out how to do any other fun things with grep colors, do let me know. :-)

Multiple Database Connections in Ruby on Rails

Posted by Fri, 05 Oct 2007 21:54:00 GMT

We have a client that already has some database replication going on in their deployment and needed to have most of their Ruby on Rails application pull from slave servers, but the few writes would go to the master, which would then end up in their slaves.

So, I was able to quickly extend ActiveRecord with just two methods to achieve this. Anyhow, earlier today, someone in #caboose asked if there was any solutions to this and it prompted me to finally package this up into a quick and dirty Rails plugin.

Introducing… Active Delegate!

To install, do the following:

cd vendor/plugins;
piston import

Next, you’ll need to create another database entry in your database.yml.

login: &login
  adapter: postgresql
  host: localhost
  port: 5432

  database: rubyurl_development
  <<: *login

  database: rubyurl_test
  <<: *login

  database: rubyurl_servant
  <<: *login

  database: rubyurl_master
  <<: *login

At this point, your Rails application won’t talk to the master_database, because nothing is being told to connect to it. So, the current solution with Active Delegate is to create an ActiveRecord model that will act as a connection handler.

  # app/models/master_database.rb
  class MasterDatabase < ActiveRecord::Base
    handles_connection_for :master_database # <-- this matches the key from our database.yml

Now, in the model(s) that we’ll want to have talk to this database, we’ll do add the following.

  # app/models/animal.rb
  class Animal < ActiveRecord::Base
     delegates_connection_to :master_database, :on => [:create, :save, :destroy]

Now, when your application performs a create, save, or destroy, it’ll talk to the master database and your find calls will retrieve data from your servant database.

It’s late on a Friday afternoon and I felt compelled to toss this up for everyone. I think that this could be improved quite a bit, but it’s working great for the original problem that needed to be solved.

If you have feedback and/or bugs, please send us tickets.

Older posts: 1 2