Here is my recipe, tested under OS X 10.5.5 with postgres 8.3.4:

Find an unused Group and User IDs. My system has two “login users”.  I want to add another user and need to find a number not in use.  The trick is to create a new user that does not show up on the OS X login dialog.   I found tips from here: http://macosx.com/forums/mac-os-x-system-mac-software/297377-add-user-can-not-seen.html

> sudo dscl . -list /Groups PrimaryGroupID
> sudo dscl . -list /Users UniqueID

On my system, ID 503 is not in use, I’ll use this for my postgres Group and User IDs. Note: OS X should give you an error on the following commands if you screw up and pick an ID already in use.

Create OS X Group and User for postgres using ID 503 (substitute a different ID if this is taken):

> sudo dscl . create /Groups/postgres
> sudo dscl . create /Groups/postgres PrimaryGroupID 503
> sudo dscl . create /Groups/postgres RealName 'Postgres Admin Group'
> sudo dscl . create /Users/postgres
> sudo dscl . create /Users/postgres UniqueID 503
> sudo dscl . create /Users/postgres PrimaryGroupID 503
# not sure if this next command is necessary.
> sudo dscl . create /Users/postgres NFSHomeDirectory /usr/local/pgsql
> sudo dscl . create /Users/postgres Password '*'
> sudo dscl . create /Users/postgres UserShell /bin/bash
> sudo dscl . create /Users/postgres RealName 'Postgres Admin User'

Install postgres.  Download latest source from http://www.postgresql.org/ftp/source/ We’ll assume postgresql-8.3.4.tar.gz for this example.

> tar zxf postgresql-8.3.4.tar.gz
# check your umask. 0002 or 0022 is good.
> umask
> cd postgresql-8.3.4
> ./configure
> make
> sudo make install
> sudo mkdir /usr/local/pgsql/data
> sudo chown postgres:postgres /usr/local/pgsql/data
# switch to postgres user to initialize the database
> sudo su postgres
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> exit
# setup the logs directory
> sudo mkdir /usr/local/pgsql/data/logs
> sudo chown postgres:postgres /usr/local/pgsql/data/logs
> sudo chmod 700 /usr/local/pgsql/data/logs
# setup OS X launch script
# paths assume you are still in the postgresql-8.3.4 source root
> cd contrib/start-scripts/osx
> sudo /bin/sh ./install.sh
# to keep postgres from starting at OS X system start, edit /etc/hostconfig file:
# change POSTGRESQL=-YES- => POSTGRESQL=-NO-
# to manually stop postgres
> sudo /Library/StartupItems/PostgreSQL/PostgreSQL stop
# to manually start postgres
> sudo /Library/StartupItems/PostgreSQL/PostgreSQL start
# add /usr/local/pgsql/bin to your PATH
# in my ~/.bash_profile I have a line near the top which I changed to
# PATH=$HOME/bin:/usr/local/pgsql/bin:$PATH:
# after PATH change, exit shell and reopen or re-source .bash_profile
# test if you can connect
> psql -Upostgres
# type \q to quit

Install pgcrypto. Basic digest and crypto functions are not in the default compile. You must install them separately. Its best to do this now as the install requires the config options created from the core install above.

# from postgresql-8.3.4/contrib/pgcrypto
> make
> sudo make install
# The above install creates /usr/local/pgsql/share/contrib/pgcrypto.sql which must be imported to each schema (YOUR_DB_NAME) where the functions are used.
> psql -Upostgres -d YOUR_DB_NAME -f /usr/local/pgsql/share/contrib/pgcrypto.sql

The first thing I have encountered is a key difference in defining unique indexes.

In 0.2.5 ( or 0.3) you would write something like this:

class User < DataMapper::Base
property :email, String, :index => :unique
property :display_name, String, :index => :unique

which would produce SQL indexes (for postgres) as:

Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"users_display_name_key" UNIQUE, btree (display_name)
"users_email_key" UNIQUE, btree (email)
"users_display_name_index" btree (display_name)
"users_email_index" btree (email)


doing a fairly straightforward conversion to datamapper 0.9 yields the following:

class User
include DataMapper::Resource
property :id, Integer, :serial => true
property :email, String, :index => :unique
property :display_name, String, :index => :unique

which generate these SQL indexes (postgres):

Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"index_users_unique" btree (email, display_name)


This creates a single unique index on the combined fields email and display_name; not what I want. I assume this is quite possibly an intended effect as this is how combined key fields gets handled in the new dm 0.9. After a few minutes looking through the very clean datamapper 0.9 source, I find there a constraint type called unique_index. When I use this as follows:

class User
include DataMapper::Resource
property :id, Integer, :serial => true
property :email, String, :unique_index => true
property :display_name, String, :unique_index => true

I get indexes generated as:

Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"unique_index_users_display_name" UNIQUE, btree (display_name)
"unique_index_users_email" UNIQUE, btree (email)


much better!!!

One of things you will encounter when using the coolest and latest technologies is that they might contain bugs ;). It is what we encountered in using datamapper 0.2.5 and do_postgres 0.2.3 in our merb 0.9.2 development stack for ShellShadow.

Here’s a quick look at how we add our patches into our merb app.

One of nasty bugs existing in datamapper 0.2.5 or 0.3.0 is that it will interpret NULL integer fields from a table as 0. It was a huge issue for us and had to be patched.

Turns out the culprit is not datamapper but in do_postgres. Many thanks to Adam French for pointing this out on #datamapper irc channel.

The buggy code was in [GEM_PATH]/gems/do_postgres-0.2.3/lib/do_postgres.rb in class Reader < DataObject::Reader method typecast(val, field_type).

The code in questions was:

when "INT2", "INT4", "OID", "TID", "XID", "CID", "INT8"
val.to_i


This should read:

when "INT2", "INT4", "OID", "TID", "XID", "CID", "INT8"
val == "" ? nil : val.to_i


The fix was a one liner but we needed to replace the entire method it was in.

This is how you apply your monkeypatch:

1. Add your patch file under <your_merb_project>/lib. Lets call it do_postgres_patch.rb. We put our modified copy of typecast in this file.
2. In <your_merb_project>/config/init.rb, you’ll see at the very bottom


Merb::BootLoader.after_app_loads do
### Add dependencies here that must load after the application loads:
# dependency "magic_admin" # this gem uses the app's model classes
end

In this block, add:
require 'core_extensions'

That’s it. Easy and all patched up!!!

Last October, I tried every ruby debugger I could find (except the windows-only Sapphire Steele). At that time, only NetBeans 6 beta had any form of working debugger and for the most part, the command line ruby-debug was a better choice.

We were re-writing ShellShadow in merb (the old site was Rails).
Now that I’m exploring merb and datamapper and sequel, I find I need a GUI debugger. Unless you have an internalized mental model of the framework (e.g. you’re the creator), you won’t get far fast enough with command line debugging.
Aptana’s latest release on what was RadRails does the job.

Here are a few things to get you going:

1. Download and install Aptana. This is a multi-step process where you need to install Aptana and then from the intro page, install the RadRails plugin. There may be updates to Aptana. Just let eclipse work its magic and update to the latest patches.
2. install ruby-debug-ide.
   gem install ruby-debug-ide. You will want to run this as “sudo gem install ruby-debug-ide” if you are installing to your global gems setup.
3. On OS X 10.5, I needed to create a link (the following is a one line command)
   sudo ln -s /usr/bin/rdebug-ide /System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/rdebug-ide
4. Config the ruby debugger in Aptana. Open the eclipse/aptana preferences dialog from “Windows->Preferences…”. In the section “Ruby>Debugger”, turn on the checkbox “Use ruby-debug library.
5. Setup your app. I didn’t create a Rails project. I create a ruby project (its for merb). I have my aptana/eclipse workspace outside of my ruby project and simply point the working directory of my project to the right place. You’ll want to set your debug setting for this project to run /usr/bin/merb or whatever your app is. This approach litters my merb project directory with two files: .loadpath and .project. You’ll probably want to tell your version control system of choice to ignore these files.

Its not perfect, but this seems to be as good as it gets at the moment for a GUI ruby debugger. Here are a few things of interest:

1. Breakpoint removal is flaky. We found that sometimes when you turn off a breakpoint, it doesn’t go away. We had to edit the code to force aptana/eclipse to refresh itself.
2. Interactive console isn’t great. IRB has a cleaner expereince but the apatana console does work.
3. Missing ability to eval expressions in the debugger. This would be a great feature and hopefully it gets added someday.

Many thanks to the Aptana RadRails team!!