Robby on Rails: Tag postgresql

Installing Ruby on Rails and PostgreSQL on OS X, Third Edition

Robby Russell — Tue, 22 Jan 2008 11:55:00 -0600

Over the past few years, I’ve helped you walk through the process of getting Ruby on Rails up and running on Mac OS X. The last version has been getting a lot of comments related to issues with the new Apple Leopard, so I’m going this post will expand on previous installation guides with what’s working for me as of January 2008.

The following guide is how our development team at Planet Argon prefers to setup our development workstations

During this installation, we’ll have what we feel is the optimal development stack for building Ruby on Rails applications with our favorite database server, PostgreSQL.

Ready? Let’s get started…

Phase One

During this initial phase, we’re going to install the underlying dependencies that we’ll be building off of.

XCode 3.0

The first thing that you’ll need to install to get far with this process is XCode tools, which is distributed by Apple. You can find this on the DVD that your Leopard installer is on. You can also download the latest version from Apple’s developer site.

http://developer.apple.com/tools/download/

The current version (3.0) is 1.1 GB.. so the download time will vary depending on your connection speed. I would encourage you to drink some tea and/or read a book

Once you finish the installation, you can move forward. The rest of these installation will not work until XCode is installed. :-)

MacPorts

In this next step, we’ll install MacPorts (formerly known as DarwinPorts). The MacPorts web site describes itself as, “an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system.”

This tool is about to become one of the most important tools on your operating system as it’ll be used time and time again to maintain your libraries and many of the Unix tools that you’ll be using. If you’re from the Linux or BSD world, you are likely familiar with similar tools… such as: apt-get, port, and yum.

First, you’ll want to download MacPorts and install the “dmg” disk file for Leopard at the following link.

http://www.macports.org/install.php

Once downloaded, you’ll want to run the installer and install it on your workstation.

Work you way through the installer until successfully installed.

Once this finishes, you can open up your favorite terminal application and run the following to test that it installed properly.

In my case, I’m now using Terminal.app.

Issue the command: /opt/local/bin/port version

If it responds with a version number like mine did in the screenshot above, we’re moving along nicely.

Environment Paths

When we install MacPorts, the command to install/update ports installed to /opt/local/bin. We had to provide the entire path as this isn’t currently showing up in the default $PATH on Leopard. Let’s quickly remedy this by modifying the file /etc/profile.

If you have Textmate installed, you can run the following from your terminal: mate /etc/profile

Add the following line to the bottom of /etc/profile.

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

You can use your favorite editor to update this file. Once you save it, you’ll want to restart your terminal application (or open a new tab) to create a new session. When your new terminal opens, run the following to verify that port is showing up in your $PATH.

which port

You should see /opt/local/bin/port show up as the result of this command.

Great, let’s continue to move forward.

Hiding Apple’s Ruby, Gems, and Rails

Before we install Ruby from MacPorts, we’ll go ahead and hide Apple’s Ruby installations.


    :~ robbyrussell$ sudo su -
    Password:
    :~ root# mv /usr/bin/ruby /usr/bin/ruby.orig
    :~ root# mv /usr/bin/gem /usr/bin/gem.orig
    :~ root# mv /usr/bin/rails /usr/bin/rails.orig
    :~ root# logout

If you ever decide to remove MacPorts, you can just rename ruby.orig back to ruby and you’re back where you started… and the same for the others listed.

Phase Two

During this next phase, we’re going to install Ruby and Ruby on Rails.

Installing Ruby via MacPorts

Now that we have MacPorts up and running, we’re going to use it for the first time. We’ll start by using it to install Ruby and the Rubygems package.

$ sudo port install ruby rb-rubygems

Okay, this will take a little while. I’d suggest that you step out to get some fresh air.

How was it outside? What’s the weather like there today? It’s currently 2:30am PST so it’s dark and an 28F outside so I didn’t stay outside very long.

If you’re still waiting for it to install, perhaps you could watch the following video. I might encourage you to check out more of Jam, which was recommended a few years ago to me by James Adam at Canada on Rails.

Be warned… it’s a strange show, but I find strange things like this funny. :-)

If you prefer something a bit more lighthearted…

Okay… when Ruby finishes installing, you’ll want to test that you can run it.

$ ruby -v

Great, let’s move forward!

Installing Ruby on Rails via RubyGems

We’re now going to install the libraries that make up Ruby on Rails via RubyGems.

$ sudo gem install --include-dependencies rails

This will install the following gems.

rails-2.0.2
rake-0.8.1
activesupport-2.0.2
activerecord-2.0.2
actionpack-2.0.2
actionmailer-2.0.2
activeresource-2.0.2

Excellent, let’s move forward…

If you haven’t already purchased it, I recommend that you take a look at The Rails Way (Addison-Wesley Professional Ruby Series) by Obie Fernandez.

Installing Mongrel via RubyGems

Let’s now install Mongrel, which is an excellent Ruby-based web server for Ruby on Rails applications. We use it in development and production at Planet Argon and it’s also what we recommend to our hosting customers.

$ sudo gem install --include-dependencies mongrel mongrel_cluster

Note: Be sure to select the proper platform for mongrel. (hint: OS X is NOT mswin32)

My terminal output:


Select which gem to install for your platform (i686-darwin9.1.0)
 1. mongrel 1.1.3 (java)
 2. mongrel 1.1.3 (i386-mswin32)
 3. mongrel 1.1.3 (ruby)
 4. mongrel 1.1.2 (ruby)
 5. mongrel 1.1.2 (mswin32)
 6. mongrel 1.1.2 (java)
 7. Skip this gem
 8. Cancel installation
> 3
Select which gem to install for your platform (i686-darwin9.1.0)
 1. fastthread 1.0.1 (mswin32)
 2. fastthread 1.0.1 (ruby)
 3. Skip this gem
 4. Cancel installation
> 2
Building native extensions.  This could take a while...
Building native extensions.  This could take a while...
Successfully installed mongrel-1.1.3
Successfully installed gem_plugin-0.2.3
Successfully installed daemons-1.0.9
Successfully installed fastthread-1.0.1
Successfully installed cgi_multipart_eof_fix-2.5.0
Installing ri documentation for mongrel-1.1.3...
Installing ri documentation for gem_plugin-0.2.3...
Installing ri documentation for daemons-1.0.9...
Installing ri documentation for fastthread-1.0.1...

No definition for dummy_dump

No definition for dummy_dump

No definition for rb_queue_marshal_load

No definition for rb_queue_marshal_dump
Installing ri documentation for cgi_multipart_eof_fix-2.5.0...
Installing RDoc documentation for mongrel-1.1.3...
Installing RDoc documentation for gem_plugin-0.2.3...
Installing RDoc documentation for daemons-1.0.9...
Installing RDoc documentation for fastthread-1.0.1...

No definition for dummy_dump

No definition for dummy_dump

No definition for rb_queue_marshal_load

No definition for rb_queue_marshal_dump
Installing RDoc documentation for cgi_multipart_eof_fix-2.5.0...
Successfully installed mongrel_cluster-1.0.5

Great, you have almost all of the essentials.. except a database.

Phase Three

In this phase, we’re going to get our database server, PostgreSQL, installed and the libraries that Ruby needs to communicate with it.

Installing PosgreSQL with MacPorts

At Planet Argon, we design and develop our applications on top of PostgreSQL. I’ve been advocating the adoption of this awesome open source database in the Rails community for quite some time now.

The current version available of PostgreSQL via MacPorts is 8.3, which is what we’ll now install with the port command.

$ sudo port install postgresql83 postgresql83-server

This will download and install the necessary libraries to run PostgreSQL server and the client utilities.

Configuring PostgreSQL

When PostgreSQL is finished installing, it’ll tell you to run the following commands to create a new database instance.


 sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
 sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
 sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

Adding PostgreSQL to launchd

If you’d like to have PostgreSQL automatically startup after a system restart, you can load it into launchd, which comes with OS X. By running the following command, PostgreSQL will startup automatically on the next system restart.

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

Adding PostgreSQL to your $PATH

For some reason, the MacPort for PostgreSQL doesn’t get the programs in your path automatically, so we’ll it now.

mate /etc/profile

Modify the PATH that we changed earlier to include /opt/local/lib/postgresql83/bin@.

export PATH=/opt/local/bin:/opt/local/sbin:/opt/local/lib/postgresql83/bin:$PATH

Save the file and then open a new terminal. To test this, you should get the following output when you run which psql.


  $ which psql
  /opt/local/lib/postgresql83/bin/psql

Creating a new PostgreSQL user

When I’m working on Rails applications in my development environment, I really don’t want to have to specify a username and password in every config/database.yml file for each of our ongoing client projects. When PostgreSQL was installed, it created a superuser named postgres, which is great, but I’d like one that matches my system username, so that I’m not prompted at all for a username or password to connect to PostgreSQL.

To do this, we’ll use the createuser command, which comes with PostgreSQL. As you can see, I’m creating a new user with superuser privileges (and will hopefully be the last time I have to do a -U postgres).


  $ createuser --superuser robbyrussell -U postgres
  CREATE ROLE

Let’s take a quick moment to test this out.


  # create a new database
  $ createdb my_test_db
  CREATE DATABASE

  # drop the database
  $ dropdb my_test_db
  DROP DATABASE

Great, everything looks good here.

We now have a running installation of PostgreSQL with a new user account. All we need to do now is install the appropriate RubyGem to allow our Ruby applications to connect to it.

Installing PostgreSQL Libraries for Ruby

You can install postgres gem by running the following command.

$  sudo gem install --include-dependencies postgres

Great. We’ve now built a professional development environment for working with Ruby on Rails. Can you feel the excitement? :-)

Closing Thoughts

Like the previous versions, I hope that a few people find this useful. I didn’t have to make a lot of changes from the second edition, but there were enough to warrant a new post. I’ve been setting up my workstation like this for about three years now and I’m looking forward to seeing how a fresh install on Leopard works out for me.

If you have any problems, feel free to ask a question in the comments below.

PGCon 2008 - Call for Papers

Robby Russell — Fri, 28 Dec 2007 10:58:00 -0600

Are you using PostgreSQL (the world’s most awesome open-source database server) with Ruby on Rails? Do you have any interesting experiences that you might want to share with an audience? Well, you might consider submitting a talk proposal for PGCon 2008, which is taking place in Ottawa, Canada.

Details follow…

PGCon 2008

PGCon 2008 will be held 22-23 May 2008, in Ottawa at the University of Ottawa. It will be preceded by two days of tutorials on 20-21 May 2008.

We are now requesting proposals for presentations.

If you are doing something interesting with PostgreSQL, please submit a proposal. You might be one of the backend hackers or work on a PostgreSQL related project and want to share your know-how with others. You might be developing an interesting system using PostgreSQL as the foundation. Perhaps you migrated from another database to PostgreSQL and would like to share details. These, and other stories are welcome. Both users and developers are encouraged to share their experiences.

Here are a few ideas to jump start your proposal process:

novel, unique or complex ways in which PostgreSQL are used
migration of production systems to PostgreSQL
data warehousing with PostgreSQL
tuning PostgreSQL for different work loads
replicating data on top of PostgreSQL

Both users and developers are encouraged to share their experiences.

The schedule is:

19 Dec 2007 Proposal acceptance begins
19 Jan 2008 Proposal acceptance ends
19 Feb 2008 Confirmation of accepted proposals
19 Apr 2008 Final papers/slides must arrive no later than this date

Instructions for submitting a proposal to PGCon 2008 are available from: http://www.pgcon.org/2008/submissions.php

This

Master/Slave Databases with Ruby on Rails

Robby Russell — Thu, 15 Nov 2007 16:02:00 -0600

Not terribly long ago, I announced Active Delegate, which was a really lightweight plugin that I developed to allow models to talk to multiple databases for specific methods. The plugin worked great for really simple situations, like individual models.. but when it came time to test with associations it fell apart. I haven’t had a chance to work on any updates and knew that it was going to take more work to get it going.

Earlier this week, we helped one of our bigger clients launch their new web site¹. For the deployment, we needed to send all writes to a master database and a reads to slaves (initial deployment is talking to almost 10 slaves spread around the globe!). We needed something to get integrated quickly and decided to ditch Active Delegate for the time being and began looking at the following options.

I spoke with Rick Olson² and he pointed me to a new plugin that he hasn’t really released yet. So, I’m going to do him a favor and announce it for him. Of course… I got his permission first… ;-)

Announcing Masochism!

Masochism³ is a new plugin for Ruby on Rails that allows you to delegate all writes to a master database and reads to a slave database. The configuration process is just a few lines in your environment file and the plugin takes care of the rest.

Installing Masochism

With piston, you can import Masochism with:


  $ cd vendor/plugins
  $ piston import http://ar-code.svn.engineyard.com/plugins/masochism/

To learn more about piston, read Every Second Counts with a Piston in your trunk

You can also install it with the old-fashioned way:


  $ ./script/plugin install -x http://ar-code.svn.engineyard.com/plugins/masochism/

Configuring Masochism

The first thing that you’ll need to do is add another database connection in config/database.yml for master_database. By default, Masochism expects you to have a production database, which will be the read-only/slave database. The master_database will be the connection details for your (you guessed it…) master database.


# config/database.yml  
production:
  database: masochism_slave_database
  adapter: postgresql
  host: slavedb1.hostname.tld
  ...

master_database:
  database: masochism_master_database
  adapter: postgresql
  host: masterdb.hostname.tld
  ...

The idea here is that replication will be handled elsewhere and your application can reap the benefits of talking to the slave database for all of it’s read-only operations and let the master database(s) spend their time writing data.

The next step is to set this up in your environment file. In our scenario, this was config/environments/production.rb.


# Add this to config/environments/production.rb
config.after_initialize do 
  ActiveReload::ConnectionProxy.setup!    
end

Voila, you should be good to go now. As I mentioned, we’ve only been using this for this past week and we’ve had to address a few problems that the initial version of the plugin didn’t address. One of our developers, Andy Delcambre, just posted an article to show how we had a problem with using ActiveRecord observers and masochism, which we’re sending over a patch for now.

As we continue to monitor how this solution works, we’ll report any findings on our blog. In the meantime, I’d be interested in knowing what you’re using to solve this problem. :-)

¹ Contiki, a cool travel company we’re working with

² Rick just moved to Portland… welcome to stump town!

³ The Masochism plugin README

Installing Ruby on Rails and PostgreSQL on OS X, Second Edition

Robby Russell — Tue, 19 Jun 2007 13:54:00 -0500

It’s been just over a year since I posted the article, Install Ruby, Rails, and PostgreSQL on OSX and it still gets quite a bit of traffic. Unfortunately, there have been a few changes in the install process that have caught people.

Today, I am leaving my PowerBook G4. It’s being replaced with a MacBook because the logic board is on the fritz. So, guess what that means? I get to install Ruby, Ruby on Rails, PostgreSQL on OS X again! I figured that I would post a revised version of my previous article for those who may go through this same process in the near future.

WARNING: This post contains some outdated instructions. Please read Installing Ruby on Rails and PostgreSQL on OS X, Third Edition, which is focused on Installing Ruby on Rails on Leopard.

Step Zero: Install iTerm (optional)

You’ll spend a lot of time in your terminal as a Rails developer. I’m not a big fan of Terminal.app as it lacks tabbed windows¹ and you’ll often find me with around ten tabs open. I’ve been using iTerm for a few years and it’s definitely improved in the past year and doesn’t seem to crash nearly as often as it used to.

Download the latest iTerm release

Once installed, I always change the default color scheme as I prefer the white on black schema. The menus in iTerm are lacking some thoughtful interaction design, but I’ve figured out the right way to do it (after a long time of stumbling on it by accident). In iTerm, you’ll want to edit the Default bookmark, which you can access by going to Manage Bookmarks under the Bookmarks Menu.

Set the Display value to classic iTerm and you’re golden.

Now… let’s get to business…

Step 1: Install Xcode Tools

Without installing Xcode tools from Apple, we’re not going to get very far. First, you’ll need to grab a copy of Xcode, which you can download on Apple’s Developer Connection site. It’s almost a 1GB download, so you’ll want to start your download and use your multi-tasking skills and grab a Viso, read some blog posts.

Download Xcode (dmg)

I’m going to make the assumption here that you know how to install a dmg on osx. Once this is installed, you can move on to the next step!

Step 2: All Your MacPorts are Belong to Us

MacPorts (formerly known as DarwinPorts) is a package management system for OS X. This is what we’ll use to install most of the necessary programs to develop and run your Ruby on Rails applications. If you’re from the Linux or BSD world, you are likely familiar with similar tools… such as: apt-get, port, and yum.

You’ll want to download MacPorts and install the dmg file.

Now that this is installed, we should test it.

With a new terminal, run the following:


$ port version
Version: 1.442

Success! Let’s get going…

Step 3: Installing the Ruby on Rails development stack

We’re going to go through a series of small steps, which may take some time depending on how fast your internet connection and computer is.

Install Ruby and RubyGems

In order to install Ruby, we’re going to use MacPorts with the port command, which is now available for installing various packages on our OS X machines.

$ sudo port install ruby rb-rubygems

It’ll probably take a while to download and install Ruby and all of it’s known dependencies. In the meantime, check out some funny code. KTHXBYE!

Still waiting for it to install, perhaps you could do something like… begin writing a comment on this post, writing your own blog post, watch a funny video, or recommend me. I walked to Backspace with Gary to get an Americano… and it’s still not done. :-p

(minutes/hours/weeks later)

Okay… I trust that it finished installing Ruby and RubyGems without any hiccups. Let’s test them from our terminal to make sure.

Let’s check the version…


$ ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]

Now, let’s make sure that Ruby is working properly…

$ irb
irb(main):001:0> x = 1     
=> 1
irb(main):002:0> puts "wee!!!" if x == 1
wee!!!

Great, we’re on a roll. Let’s get the rest of the stack installed.

Install Ruby on Rails

We’re going to install Ruby on Rails with the gem command that installing RubyGems provided.


$ sudo gem install -y rails

This command should produce an output similar to the following.


Successfully installed rails-1.2.3
Successfully installed rake-0.7.3
Successfully installed activesupport-1.4.2
Successfully installed activerecord-1.15.3
Successfully installed actionpack-1.13.3
Successfully installed actionmailer-1.3.3
Successfully installed actionwebservice-1.2.3
Installing ri documentation for rake-0.7.3...
Installing ri documentation for activesupport-1.4.2...
Installing ri documentation for activerecord-1.15.3...
Installing ri documentation for actionpack-1.13.3...
Installing ri documentation for actionmailer-1.3.3...
Installing ri documentation for actionwebservice-1.2.3...
Installing RDoc documentation for rake-0.7.3...
Installing RDoc documentation for activesupport-1.4.2...
Installing RDoc documentation for activerecord-1.15.3...
Installing RDoc documentation for actionpack-1.13.3...
Installing RDoc documentation for actionmailer-1.3.3...
Installing RDoc documentation for actionwebservice-1.2.3...

Install Rails-friendly gems

Mongrel

If you’re developing with Rails, it’s highly recommended that you use install and use Mongrel for your development and production environments. The following command will install the mongrel and mongrel_cluster gems (including their dependencies).

$ sudo gem install -y mongrel mongrel_cluster

* Note: Be sure to select the proper platform for mongrel. (hint: OS X is NOT mswin32)

My terminal output:


$ sudo gem install -y mongrel mongrel_cluster
Password:
Bulk updating Gem source index for: http://gems.rubyforge.org
Select which gem to install for your platform (i686-darwin8.9.1)
 1. mongrel 1.0.1 (mswin32)
 2. mongrel 1.0.1 (ruby)
 3. mongrel 1.0 (mswin32)
 4. mongrel 1.0 (ruby)
 5. Skip this gem
 6. Cancel installation
> 2
Select which gem to install for your platform (i686-darwin8.9.1)
 1. fastthread 1.0 (ruby)
 2. fastthread 1.0 (mswin32)
 3. fastthread 0.6.4.1 (mswin32)
 4. fastthread 0.6.4.1 (ruby)
 5. Skip this gem
 6. Cancel installation
> 1
Building native extensions.  This could take a while...
Building native extensions.  This could take a while...
Successfully installed mongrel-1.0.1
Successfully installed daemons-1.0.6
Successfully installed fastthread-1.0
Successfully installed gem_plugin-0.2.2
Successfully installed cgi_multipart_eof_fix-2.1
Installing ri documentation for mongrel-1.0.1...
Installing ri documentation for daemons-1.0.6...
Installing ri documentation for gem_plugin-0.2.2...
Installing ri documentation for cgi_multipart_eof_fix-2.1...
Installing RDoc documentation for mongrel-1.0.1...
Installing RDoc documentation for daemons-1.0.6...
Installing RDoc documentation for gem_plugin-0.2.2...
Installing RDoc documentation for cgi_multipart_eof_fix-2.1...
Successfully installed mongrel_cluster-0.2.1

Step 4: Installing the World’s Most Advanced Database Server… PostgreSQL!

At PLANET ARGON, we develop our applications on top of PostgreSQL. I’ve long been advocating the adoption of this awesome open source database in the Rails community. Just over a year ago, Jeremy Voorhis (PLANET ARGON alumnus) and I were interviewed on the Ruby on Rails podcast and had the opportunity to discuss our preference of PostgreSQL over the alternatives (mysql, sqlite, firebird, etc.).

We’re going to install PostgreSQL 8.2 from MacPorts by running the following command.

$ sudo port install postgresql82 postgresql82-server

While this is installing, you might take a moment to check out some space shuttles.

Setting up PostgreSQL

You may have noticed the output of the previous port installation of PostgreSQL 8.2, suggested that you do the following. Let’s do that now…


$ sudo mkdir -p /opt/local/var/db/postgresql82/defaultdb
$ sudo chown postgres:postgres /opt/local/var/db/postgresql82/defaultdb
$ sudo su postgres -c '/opt/local/lib/postgresql82/bin/initdb -D /opt/local/var/db/postgresql82/defaultdb'

Have PostgreSQL start automatically on system start-ups

Unless you’re concerned about extra applications running in the background, I’d encourage you to add PostgreSQL to launchd, which will start it automatically after system reboots.

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql82-server.plist

Adding PostgreSQL commands to your $PATH

For some reason, MacPorts doesn’t add the PostgreSQL programs to the default bash PATH, which means that you can’t run psql, pg_dump, or createdb/dropdb without specifying the full path to where they were installed. What we’ll do is add them to our default terminal profile.

sudo vi /etc/profile

(you can use mate, emacs, joe or any other preferred editor to do this)

This file gets loaded every time a new terminal session is started.

Let’s add /opt/local/lib/postgresql82/bin to the end of the value for PATH.


PATH="/bin:/sbin:/usr/bin:/usr/sbin:/opt/local/lib/postgresql82/bin"

Save the file and then open a new terminal. To test this, you should get the following output when you run which psql.


$ which psql
/opt/local/lib/postgresql82/bin/psql

Creating a new PostgreSQL user

When I’m working on Rails applications in my development environment, I really don’t want to have to specify a username and password in every config/database.yml file for each of our ongoing client projects. When PostgreSQL was installed, it created a superuser named postgres, which is great, but I’d like one that matches my system username, so that I’m not prompted at all for a username or password to connect to PostgreSQL.

To do this, we’ll use the createuser command, which comes with PostgreSQL. As you can see, I’m creating a new user with superuser privileges (and will hopefully be the last time I have to do a -U postgres).


$ createuser --superuser robbyrussell -U postgres
CREATE ROLE

Let’s take a quick moment to test this out.


# create a new database
$ createdb my_test_db
CREATE DATABASE

# drop the database
$ dropdb my_test_db
DROP DATABASE

Great, everything looks good here.

We now have a running installation of PostgreSQL with a new user account. All we need to do now is install the appropriate RubyGem to allow our Ruby applications to connect to it.

Installing the Ruby Postgres gem

UPDATE: Hydro posted a commented, which lead me to the ruby-postgres gem.

You can install ruby-postgres gem by running the following command.


$ sudo gem install -y ruby-postgres

Let’s take a moment to test that this installed properly.


$ irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'postgres'
=> true

If this returns true, than we should be good to go. We’ve now built a professional development environment for working with Ruby on Rails. Doesn’t that feel great?

Test your install

You can look back at my older post to walk through the process of testing out your setup with a new Rails application.

Closing thoughts

I hope that this post has been useful for you. It took me a few hours to walk through this process and it’s how all of our designers and developers at PLANET ARGON installs and configures their development environment.

We also install the following programs on new machines.

TextMate
Subversion: sudo port install subversion
RSpec: sudo gem install -y rspec
...amongst other gems that are needed on specific projects

Until next time… have fun!

¹ Rumor: Mac OS X Leopard will give Terminal.app tabs! (see screenshot)

Install Ruby, Rails, and PostgreSQL on OSX

Robby Russell — Mon, 29 May 2006 09:46:00 -0500

WARNING: This post contains some outdated instructions. Please read Installing Ruby on Rails and PostgreSQL on OS X, Second Edition.

Our Creative Director, Allison Beckwith, picked up a new black MacBook this weekend and I had the luxury of getting it setup to model our standard setup. We all try to keep our setups fairly similar so that we don’t hit too many issues when working together on projects.

I’ll try to keep this short and to the point… because if you’re like me… you just want to start playing with Rails! ;-)

The steps I followed to get her setup like the rest of the development team at PLANET ARGON went something like this.

XCode and DarwinPorts

Download and install iterm (the Universal dmg)
Download and install XCode tools from Apple (dmg)
Download and install DarwinPorts (dmg)
Start up iterm.

In this step we are going to modify the default bash profile so that every user on the machine that uses bash will get the path for darwinports in their bash_profile.

sudo vi /etc/profile

Modify the following line to include /opt/local/bin in the PATH… save the file (see vim documentation for details)


  PATH="/bin:/sbin:/opt/local/bin:/usr/bin:/usr/sbin"

Ruby and Rails

Open up a new iterm tab (apple-t)
Install ruby with darwinports with: sudo port install ruby rb-rubygems
Install Ruby on Rails and all its dependencies with: sudo gem install -y rails

PostgreSQL and Ruby libs

Install PostgreSQL8 with: sudo port install postgresql8
We need to modify the /etc/profile file again because the postgresql8 install doesn’t add programs like pg_ctl to /opt/local/bin. Change the PATH to now look like this and save.


  PATH="/bin:/sbin:/opt/local/bin:/usr/bin:/usr/sbin:/opt/local/lib/pgsql8/bin"

Install the postgres gem with: sudo gem install postgres
- Oh NO!!! You should see an error about it not finding libraries… what will we do?


  cd /opt/local/lib/ruby/gems/1.8/gems/postgres-0.7.1
  sudo ruby extconf.rb --with-pgsql-include=/opt/local/include/pgsql8 --with-pgsql-lib=/opt/local/lib/pgsql8
  sudo make && sudo make install
  # for good measure...
  sudo gem install postgres

Successfully installed postgres-0.7.1

Configure PostgreSQL for single user

In our development environments, we don’t find it necessary to keep PostgreSQL running all the time on our servers. We only want it running when we’re doing development. We also typically install it per user on a machine to keep us from needing things like usernames and passwords to connect to it from an application we’re running on the machine. Let’s setup PostgreSQL the PLANET ARGON way!

Open up iterm and go to your home directory
Init your new PostgreSQL database with: initdb -D pgdata
Start up PostgreSQL with: pg_ctl -D pgdata -l pgdata/psql.log start
Create a new database with: createdb argon_development
Test the new database with: psql argon_development
Did it load up your new database? If so, great! If not… check your steps… :-)

Test Rails + PostgreSQL

Navigate to a directory where you don’t mind sticking projects… mkdir development; cd development
Generate a new Rails application with: rails -d postgresql argon
Navigate to new Rails application directory. cd argon
Generate a new model to test with: ./script/generate model Argonista
Edit and save the migration that was generated ( db/migrate/001_create_argonistas.rb ) file with your favorite editor…


  class CreateArgonistas < ActiveRecord::Migration
    def self.up
      create_table :argonistas do |t|
        t.column :name, :string
        t.column :blog_url, :string
      end
    end

    def self.down
      drop_table :argonistas
    end
  end

Edit config/database.yml to look like the following… you’ll notice that we don’t need to supply a username or password.


  development:
    adapter: postgresql
    database: argon_development

  test:
    adapter: postgresql 
    database: argon_test

  production:
    adapter: postgresql
    database: argon_production

* Run the migration with: rake db:migrate


  $ rake db:migrate
  (in /Users/allisonbeckwith/development/argon)
  == CreateArgonistas: migrating ================================================
  -- create_table(:argonistas)
  NOTICE:  CREATE TABLE will create implicit sequence "argonistas_id_seq" for serial column "argonistas.id" 
  NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "argonistas_pkey" for table "argonistas" 
     -> 0.0399s
  == CreateArgonistas: migrated (0.0402s) =======================================

* Test your new model from console


  $ ./script/console 
  Loading development environment.
  >> a = Argonista.new
  => #<Argonista:0x24569dc @attributes={"name"=>nil, "blog_url"=>nil}, @new_record=true>
  >> a.name = 'Robby'
  => "Robby" 
  >> a.blog_url = 'http://www.robbyonrails.com'
  => "http://www.robbyonrails.com" 
  >> a.save
  => true
  >> exit

* Great, let’s go look at our database table…


  $ psql argon_development
  Welcome to psql 8.1.3, the PostgreSQL interactive terminal.

  Type:  \copyright for distribution terms
         \h for help with SQL commands
         \? for help with psql commands
         \g or terminate with semicolon to execute query
         \q to quit

  argon_development=# SELECT * FROM argonistas;
   id | name  |          blog_url           
  ----+-------+-----------------------------
    1 | Robby | http://www.robbyonrails.com
  (1 row)

There we go, we’ve setup Ruby, Rails, and PostgreSQL on a brand new Intel MacBook without breaking a sweat!

Extra Goodies

Subversion: sudo port install subversion
Lighttpd: sudo port install lighttpd
ImageMagick: sudo port install ImageMagick (known to take a while…)
GraphicsMagick: sudo port install GraphicsMagick
Install the rmagick gem: sudo gem install rmagick

Have fun!

PostgreSQL: An elephant wearing a hula skirt and I find it sexy

Robby Russell — Thu, 20 Apr 2006 18:30:00 -0500

Last week, I gave a live presentation to ~250 people, which was basically me walking through the process of using Ruby on Rails to talk to a legacy database¹. For my example, I used the Dell DVD database... the PostgreSQL version. You can review some comments about my presentation by reviewing this entry on the blog of Ryan Davis. I wrapped quite a bit of the database in a few minutes and then showed what another 45 minutes of work could do with Rails. I’ll tarball that code and post it online soon.

Alex Bunardzic found it practical. I’ll take that as a compliment. ;-)

Earlier, I noticed this blog entry by Chris… where he said, “PostgreSQL also seems to be growing more briskly among the database category, while MySQL declines modestly. I guess that’s good news for Robby.” What exactly made me happy? This bullet made by Tim O’Reilly on Radar in his post, State of the Computer Book Market, Part 2.

“A surprise to many may be the strong growth of PostgreSQL, up 84% over a year ago. We’ve also been hearing some signs of growth in the Postgres market from our “alpha geek” radar, with reasons given including better support for geo data, and better handling of very large data sets. New companies like Greenplum and EnterpriseDB have also brought a little focus to this market. We’re updating our PostgreSQL book, and watching this market closely.”

That’s awesome! Go PostgreSQL!

Then to my surprise, I was contacted by CRN (again) to get my thoughts on MySQL’s awesome storage-engine plugin system... which showed up a few hours later in this article. The writer of that article managed to goof my last name (Robby Hill?)... and hopefully that gets resolved soon. ;-)

As I said at Canada on Rails in front of 250 people, “I find databases… sexy.”

(free desktop wallpaper!)

Why Rails? Why PostgreSQL?

Rails.. that’s a no-brainer.

PostgreSQL? Well.. they have compatible licenses… no dual-license smell when your trying to sell your application as a complete solution… and as Rails is database agnostic... there is no reason not to give PostgreSQL a try.

Who uses PostgreSQL on Rails?

CDBaby
Shopify
PLANET ARGON (on almost every project we work on…)
you…?

If your using PostgreSQL on Rails… email me... I’d love to hear and share your story on my O’Reilly blog, like I did with Derek Sivers and Jeremy Kemper of CDBaby a few months ago, which you can read here.

again… I find databases sexy...

If your a PLANET ARGON hosting customer… you can follow these instructions to install PostgreSQL on your PLANET ARGON hosting account.

¹ According to the Rails convention (and by me)... any database created pre-Rails or doesn’t follow the conventions is considered legacy. ;-)

I Repeat... Do Not Use PostgreSQL!

Robby Russell — Tue, 14 Mar 2006 09:16:00 -0600

Why is everybody interested in using PostgreSQL? We all know that it’s a pain to install, a pain to maintain, and Rails only works with MySQL. So, why do we bother?

This article titled, Five reasons why you should never use PostgreSQL. Ever. clears up these questions.

My favorite is… “Reason #5: You (don’t) get what you (don’t) pay for”

Imagine if we said the same thing about Ruby on Rails?

Localization with Rails and PostgreSQL, part 1

Robby Russell — Wed, 30 Nov 2005 12:36:00 -0600

One of the client projects that PLANET ARGON is working on requires that it work in about 20 different languages. Jeremy has been investigating different plugins for Rails to help us accomplish this. He came across Globalize.

Globalize is a Ruby on Rails plugin designed to support multilingual applications. It’s under the MIT License, same as Ruby on Rails.

Locale.set( 'en-US' )
d = Diet.find( 1 ) 
d.name -> "Vegetarian"

... we want to pull back the German version. No, it doesn’t translate it for you.. just pulls back another version of the object with the desired locale.

Locale.set( 'de-DE' )
d = Diet.find( 1 ) 
d.name -> "Vegetarier"

Pretty cool, right?

Well, we’re primarily working with PostgreSQL and the Globalize plugin didn’t pass tests with it. That’s now fixed as I found out from Jeremy that he was given COMMIT rights to the Globalize plugin and it now passes all tests against PostgreSQL!

We’ll keep you updated on how well it works as we dig deeper into using it. :-)

Interviewed by CRN regarding Oracle, MySQL, and PostgreSQL

Robby Russell — Sat, 12 Nov 2005 21:49:00 -0600

I was interviewed by CRN regarding my personal thoughts on how the release of Oracle Express might compete with MySQL and PostgreSQL.

Read the short article…

Oracle Express… {yawn}

Rails Migrations and PostgreSQL Constraints

Robby Russell — Fri, 11 Nov 2005 10:42:00 -0600

A question was posed on the Rails mailing list concerning how one would go about adding CONSTRAINTs to the database tables with ActiveRecord::Migration.

One argument was raised stating that it is easier to handle these in plain SQL schema files. I disagree. :-)

Migrations to the Rescue

Databases evolve and I have recently found the Migration structure to be perfect for handling iterations and schema changes. Using the #execute method has helped move more of my code into the Ruby/Rails framework… and that just makes things easier to manage in the long-run. This is the approach that we are using at PLANET ARGON with some of our current client projects.

# db/migrate/6_add_foreign_key.rb
class AddForeignKey < ActiveRecord::Migration
  def self.up
    execute "ALTER TABLE bees ADD CONSTRAINT beehive_id_fkey FOREIGN KEY
(beehive_id) REFERENCES beehives (id);"
  end

  def self.down
    execute "ALTER TABLE bees DROP CONSTRAINT beehive_id_fkey;"
  end
end

This gives us an easy way to use the standard, #create_table syntax for building our tables with Ruby… and then we can slap these constraints on later.

This would add the constraints…


rake migrate VERSION=6

...run tests…


rake

...roll back…


rake migrate VERSION=5

I have found that this approach is really useful with testing in Rails. When I think that I have everything working great (without CONSTRAINTS in PostgreSQL), I run another migration to add a bunch of foreign key and data constraints to the tables and… run my tests again.

Let’s give Active Record a Hug

This has helped me gain some trust in Active Record while still giving me that comforting feeling that PostgreSQL is acting as the body guard for my data.

Even if you don’t end up using Migrations to handle these types of database schema changes, I would highly suggest that you model your implementation after this. I’ve worked with many database schemas and this just makes it easy to add your new change and run one command to commit it to the database.

...and now I go play with beehives…

PostgreSQL 8.1 was released!

Robby Russell — Wed, 09 Nov 2005 18:21:00 -0600

Just a quick announcemnet:

Yesterday, the PostgreSQL team released version 8.1. Take a peak at the latest changes and enhancements.

Yes, we’re offering PostgreSQL 8.1 Hosting and Support for it now at PLANET ARGON. :-)

Interview with CD Baby

Robby Russell — Wed, 02 Nov 2005 16:25:00 -0600

Last month I conducted an interview with Derek Sivers and Jeremy Kemper of CD Baby… this is the result.

Migrating from MySQL to PostgreSQL in 60 seconds (with Rails)

Robby Russell — Sat, 29 Oct 2005 14:23:00 -0500

I do quite a few MySQL to PostgreSQL migrations for clients of PLANET ARGON and over the years I have gone through different methods of handling this procedure. Typically, it involved exporting data, re-importing it through some shell script that does its best to take into consideration the slight differences between the two databases.

While working on a recent project that was to be migrated from MySQL to PostgreSQL, but after some Refactoring had been done to the code base. I had been meaning to spend a few hours coming up with some simplified process of taking data from MySQL and replicating it to a new PostgreSQL database, while maintaining referential integrity.

My original idea was to build a script that referenced two seperate databases and then copied data out and inserted it into the new db after performing a few data changes. This seemed like too much work and I knew that I should be able to harness the power of Ruby and Rails in my process. My next thought? RailsFS.

In a perfect world, I would mount one instance of the application with a mysql database and another with a postgresql database… and just copy the yaml files to the postgresql and bam, it’d work, right? Well, it doesn’t quite work that way. So, I ruled out that idea.

Then I had another idea. I would build a task in my Rakefile that… imported each of those YAML files into PostgreSQL!

We can now type in the following commands:

This first creates my PostgreSQL database tables using Migrations.

rake migrate VERSION=1

then…

rake mysql2pgsql

mysql2pgsql runs…and approx 60 seconds later, I had an exact copy of the MySQL database in PostgreSQL. But wait! PostgreSQL has SEQUENCES… so I then run:

rake migrate VERSION=2

...and my SEQUENCES are ALTER’d.

Yes, I will post some code in the near future. But all I am doing is basically running through all the YAML files that are available from RailsFS and adding them into the new database. It automatically figures out the model name…and is fairly generic at the moment. However, I’d like to spend a bit more time stress-testing it before I post it. :-)

I want to try to work on a RailsFS-less version as well so that I can run this on my PowerBook.

Until next time… have fun!

Using Named Placeholders in Ruby

Robby Russell — Fri, 21 Oct 2005 00:53:00 -0500

Insert Hip Quote Here:

“In ancient times, hundreds of years before the dawn of history, an ancient race of people… the Druids. No one knows who they were or what they were doing… “ – Nigel Tufnel, Spinal Tap

Story Time…

Earlier, I was giving a customer of ours, Jared from CommunityWalk.com a quick tutorial on some of the features script/console… which lead to helping him with a SQL query. When I provided him with some working code he was curious about what I had done in the SQL query string that I was passing to find_by_sql.

WARNING

If you have ANY SQL queries that resembles the following, PLEASE READ THE REST OF THIS. :-)

values = params[:search]
RockLegend.find( :all, :conditions => "first_name = '#{values['first_name']}'" )

If you are doing that… then you are opening yourself up to some security problems. Let’s take a few minutes and discuss how you can make this more secure and still keep your code readable. (the best of both worlds!)

The ? Placeholder

Many of you are probably familiar with this approach…

RockLegend.find( :all, :conditions => ['first_name = ?', 'Nigel'] )

RockLegend.find( :all, :conditions => ['first_name = ? AND last_name = ?', 'Nigel', 'Tufnel'] )

You can pass it a hash as well.. and as long as you put everything in the same order as the ?s are placed… then all is well.

My only real problem with this approach is that it requires you to keep things in a specific sequential order… and who wants to keep track of that? So, I would like to recommend that you use named placeholders. Aside from that, it looks magical and I don’t like magical-looking code. I like easy to read code. :-)

Named Placeholders

If you already use these… you know how useful they can be in your SQL queries. If you haven’t seen them before… it’s because the Rails docs don’t really mention it and is something that comes from the underlying database library in Ruby. So what is so great about these?

Let’s first replace the above code with named parameters…

RockLegend.find( :all, :conditions => ['first_name = :first_name', { :first_name => 'Nigel' } ] )

We are passing a hash with a matching key to the conditions option. Pretty neat, right? In this case with just one placeholder we just increased the amount of code to do the same thing. So, it might always be the best solution… but it is easier to read.

Let’s try another with multiple keys in our hash… infact, we’ll build the hash prior to calling find.

values = { :first_name => 'Nigel', :last_name => 'Tufnel'}
RockLegend.find( :all, :conditions => ['first_name = :first_name AND last_name = :last_name', values ] )

It will happily match the hash keys to the named placeholders in the conditions string. Again, nothing terribly exciting…but it is easier to read.

Who cares about order? Not named placeholders!

Okay, let’s mix things up a bit…

values = { :last_name => 'Tufnel', :first_name => 'Nigel' }
RockLegend.find( :all, :conditions => ['first_name = :first_name AND last_name = :last_name', values ] )

The hash keys were not added in the same order… but it still works!

Okay, now for one last quick example (it’s late and I am tired…).

I have a search mechanism on a site that allows you to search for a string of text across multiple fields. So, I have one string… but several fields to compare against.

Here is a string that I will pass to the find method.

conditions = "role = :role AND (first_name ~* :str OR last_name ~* :str OR nick_name ~* :str)"

Note: this string is using PostgreSQL regular expressions... (~*).

Here is a hash that with that matches the keys, :str and :role

values = { :str => '^(Nigel|Tufnel)$', :role => 'Guitar' }

If you look above, you’ll see that the conditions string contains four named placeholders… but the hash only has two keys. With the ? placeholder, we would have to pass the same vaule three times… which isn’t any fun to read or maintain. ;-/

So, with our new friends, named parameters, we can call find (or any find-like method) using this technique for placeholders.

RockLegend.find( :all, :conditions => [ conditions, values ] )

...and hopefully this is useful to you. :-)

Have fun!

New Active Record Options for Associations

Robby Russell — Wed, 19 Oct 2005 18:00:00 -0500

Two months ago today I posted about a bug in Active Record. A bug that reminded me to remain cautious about how much trust I put into a database abstraction layer. I am happy to now say that this particular bug has been fixed, and I got to help! In the process, I also got to add some new features. (see my original rant, Active Record, I love U but I still trust my database server a tiny bit more.

I discovered this bug when I was working on a chapter in my book on Active Record. I’m known to gladly take advantage of database constraints and triggers, and it was when I decided to test my code without these constraints, I discovered the bug. “Hey, Active Record isn’t doing what it’s supposed to!” I’ve since had a number of people ask me if what a more pragmatic way to work around this issue is, rather than go my route by adding a constraint/trigger.

You can now DO AWAY with ON DELETE CASCADE! (sort of)

The new release of Rails 1.0 Release Candidate includes some new options for the has_many and has_one declarations.

Previously, you could do the following:

class Customer < ActiveRecord::Base
  has_many :orders, :dependent => true
end

This was supposed to nullify the dependent records, but it didn’t!

My patch not only fixes this, but also gives more control with what :dependent does. Now, you can pass the :dependent option to the has_many and has_one declarations with either :nullify or :destroy. This has a similar affect as ON DELETE CASCADE in those fancy RDBMs like PostgreSQL.

Let’s take a closer look at these new options:

has_one

A spider has_one web, and the web belongs_to one spider. If you destroy the spider, you would most likely want to destroy the web as well.

class Spider < ActiveRecord::Base
  has_one :web, :dependent => :destroy
end

On the other hand, in the case of a snail that has_one shell (and the one shell belongs_to the snail), if you destroy the snail, you may want to keep the shell. Remember, your crazy Aunt Ruby collects snail shells.

class Snail < ActiveRecord::Base
  has_one :shell, :dependent => :nullify
end

Now, for every snail we destroy, the shells, though once dependent on the snail, are now available for Aunt Ruby.

has_many

The same rules apply to the has_many association. Most people assume that if you destory a beehive that you would destroy all the bees. I’d like to think that they wander around until they find a new beehive to join. So, we can :nullify their relationship when the beehive is destroyed, thus making them homeless, but available for future hives.

class Beehive < ActiveRecord::Base
  has_many :bees, :dependent => :nullify
end

Sadly, some people might want to destroy the bees along with the destruction of the beehive. So, those people can pass the :dependent option, :destroy.

class Beehive < ActiveRecord::Base
  has_many :bees, :dependent => :destroy
end

Don’t worry, your usage of :dependent => true will now work, even though it wasn’t working before.

I’m going to try to put more trust into Active Record now, and I hope that this new addition to the library finds itself useful for you. :-)

Take a peak at the cool new features in the latest version of Rails and see the Active Record CHANGELOG for more information.

Enjoy!

A PostgreSQL tip

Robby Russell — Wed, 05 Oct 2005 01:07:00 -0500

I promised that I would send a link out or something… so here goes.

Tonight at the Portland Ruby Brigade meeting, the question about having Active Record READ from one database and WRITE to another database was brought up. The discussion was going in the route of, “How can we make AR do this?”

I chimed in with my usual PostgreSQL bias. “pgpool.”

Let something else handle this. Infact, with PgPool, you don’t have to change any code in your Rails application to make this work. :-)

So, take a look at: pgpool

Enjoy!

Portland Ruby Brigade meets CD Baby

Robby Russell — Wed, 05 Oct 2005 00:25:00 -0500

This is what happened to the Portland Ruby Brigade today:

Got double booked on meeting night with the PHP group
Got asked to leave after getting threats of the lights being turned off
Stayed almost til closing time at a brew… we heard, “Last Call!” and still continued talking…

Tonight I finally got to meet Ben, Caleb, Justin Watkins, Marcus Estes, Lennon Day-Reynolds, Jeremy Kempter (bitsweat), Aaron Johnson, and Peat Bakke-each for the first time. I also got to see Scott Laird (of Typo fame) and John Labovitz again. Scott and I met at FOSCON and John once found me when he was trying to hack people at a coffee shop and saw that I was on the wireless network. Okay, he wasn’t hacking… but found me at Urban Grind. :)

We had about ~25 people show up. I don’t think that there was a head count made. We sat around in a big circle and fired questions at both Derek Sivers and Jeremy Kemper. Topics ranged from how Derek found his way to PostgreSQL to why he thinks that he is an amazing web designer (smirk) to why Ruby and Rails was picked as the platform to move to from a PHP/MySQL system. Jeremy shared some insights into some problems with Rails that need to be worked on (boolean-stuff for example), tips on debugging, and many other things that I don’t recall off the top of my head.

It was a very relaxed and open conversation with some cool local developers who are working on getting their Rails/PostgreSQL system finished.

After we got kicked out of FreeGeek most of migrated to the Lucky Lab Pub… and then we realized that Derek and Jeremy didn’t show up. So, we found our ways to a big table and broke up into smaller conversations. I got stuck at the table with Ben, Scott, Caleb, and John. Actually, it was quite enjoyable. Scott talked about his work with Typo and Ben and I gave him some of our thoughts on things.

This is a horrible summary of the whole evening. It’s what I remember… and it’s late and I look forward to getting to hang out with this gang again in the future. I think that it was great to get to finally meet a few of the people that I have worked on some smaller projects with. If everything works out well, expect there to be some more projects coming out of the PDX.rb in the coming months. :-)

Thanks again to Derek Sivers and Jeremy Kemper for taking time out of their busy schedule to meet & greet with the Portland Ruby people. :-)

The bitter-sweet taste of agnostic database schemas

Robby Russell — Tue, 27 Sep 2005 08:41:00 -0500

If you know me at all by now… you might know that I am a huge fan of PostgreSQL. Coming to the Rails camp was a bit of an eye-opener./ Working with PostgreSQL used to save me quite a bit of work and let me sleep at night. I have dealt with the problems that many developers face while working with MySQL. Like many of us in the Open Source world, I was exposed to MySQL more often than PostgreSQL. For several years, I convinced myself that MySQL was awesome because it was fast… but speed isn’t always the most important factor in the technology world. Otherwise, we’d all be coding in C. What PostgreSQL provided to me as a developer was better relational integrity. Foo cannot exist unless Bar does, or vice versa. ON DELETE CASCADE was a godsend and saved me quite a bit of work when building an application. Triggers… Procedural Languages… oh so beautiful.

PostgreSQL was (and is) the Open Source database server that both the Enterprise DBA and Developer could agree on.

Enter Ruby on Rails

At first, I just ignored my instincts and jumped in head first. Pluralization? Primary keys named id? Blasphemy! Yet, I moved forward. After a few days of consistently reminding myself of these new-fangled conventions (I even printed out a little cheat sheet and taped it to my monitor)... I was hooked. Rails worked with PostgreSQL. Let me say that again.

RAILS WORKS WITH POSTGRESQL!

Don’t freak out. Yes, the person who started the Rails project is a MySQL fan... but Rails is database agnostic. It’s true.

I wanted to write an entry to clear up a few myths about Rails.

Table names are not forced
Primary Key field names are not forced
Foriegn Key field names are not forced
Legacy databases can work with Rails
Active Record (like much of Rails) can be customized for your particular application’s needs

I was, and still am, concerned about trusting Active Record with handling my relational data… because in some cases it wasn’t doing what it should. But, that is being worked on… and because Rails is Open Source, the issue is transparent for us developers to see and help fix.

In the past, you might have found me advocating the addition of business logic in your database server, whenever possible. It is the gate keeper. The key master. It is not meant to be flexible with your data. If business rules are to change, you change them there so that if you have one or more INPUT streams into your database, the data will not get into your server unless your business rules are met. PostgreSQL even provides you with a nice ERROR message, which some other servers do not. If you can control everything through one INPUT stream (Application Database), then putting these constraints solely in your database abstraction layer is a-ok. However, if you are interfacing with your server through a variety of avenues (Integration Database), you probably already know that your system is going to be a pain to maintain in the long run. So, what are you to do?

Handling Legacy systems is going to be a headache, regardless of what you do… but you can’t always rebuild the whole thing and migrate your data. Add that to your Someday-Maybe list.

When you’re adding new pieces to your application, start by using good tools, frameworks, and practices. For example, try your best to follow the Application Database path to pragmatic enlightenment. Begin working on a new layer for your legacy database. Add on web services that use this layer. Refactor your existing applications. Can they use these new services? ReThink everything. That is… if you have the time and resources to do so.

If you are questioning whether or not to put your business logic in your database abstraction layer, stop. Just do it™. But, do it with caution. Test it. Test it well. I’ll admit that I still add some constraints into my database schemas-~~I am not ready to give up that extra layer of data security. But, that’s just me. :~~)

PostgreSQL works with Rails!

...and I promise to show you how to do some fun legacy stuff with Rails in my book. :-)

Hurricane shelter uses Rails and PostgreSQL, thanks open source

Robby Russell — Sat, 24 Sep 2005 07:45:00 -0500

I came across this weblog entry on a website that is offering shelter for victims of Hurricane Katrina.

The author writes:

How do you measure the ROI on a project like this? How do I get PostgreSQL or Ruby-on-Rails credit for reuniting a twelve year-old girl with her father who had been missing for three weeks or any of the other amazing stories we heard everyday at Windsor?

It’s great to hear that Open Source is used for situations like this. The money that would have been spent on commercial applications and support would be better spent on the people that they are trying to help.

I tried to figure out exactly which page might be using Rails (as they are using Gallery, WordPress, etc for a few other pieces of their system). I found this, which looks like it might be based in Rails.

Disclaimer I couldn’t find too much information about this, just their blog and a few links from it. If you find more information, please comment and I’ll update this entry. :-)

UPDATE

I got an email from Rudi Cilibrasi from Katrina Help. They are using Ruby on Rails for their people search.

CDBaby Q&A at next Portland Ruby Brigade meeting

Robby Russell — Fri, 23 Sep 2005 15:06:00 -0500

I just posted on the Portland Ruby Brigade blog that Derek Sivers and Jeremy Kemper (bitsweat) will be coming to the next PDX.rb user group meeting. Derek and Jeremy will field questions from all of us in regards to their complete rewrite of CD Baby from PHP+MySQL to Ruby+Rails+PostgreSQL. (my favorite open-source projects!)

This will take place at FreeGeek in Portland, Oregon on October 4th, 2005!

For more information, see the Portland Ruby Brigade website