What I couldn’t find is a complete example that helped me understand what was going on and worked properly on OS X.

Here’s what I did, and maybe you’ll find it useful.

ESC="\033" # This is the escape sequence
NO_COLOR="$ESC[0m"
IRED="$ESC[1;31m" # ANSI color code for intense/bold red
IGRN="$ESC[1;32m" # ANSI color code for intense/bold green

# From http://railstips.org/blog/archives/2009/02/02/bedazzle-your-bash-prompt-with-git-info/
# I had to change 'git-symbolic-ref' to 'git symbolic-ref'
function parse_git_branch {
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  echo " ["${ref#refs/heads/}"]" # I wanted my branch wrapped in [], use () or <> or whatever
}

# from http://ariejan.net/2010/04/25/ruby-version-and-gemset-in-your-bash-prompt-yes-sir
function rvm_version {
  local gemset=$(echo $GEM_HOME | awk -F'@' '{print $2}')
  [ "$gemset" != "" ] && gemset="@$gemset"
  local version=$(echo $MY_RUBY_HOME | awk -F'-' '{print $2}')
  [ "$version" != "" ] && version="$version"
  local full="$version$gemset"
  [ "$full" != "" ] && echo "${full}:" # the colon at the end is a delimiter, you could use a space instead
}

#PS1="\h:\W \u\$" # For reference, here's the default OS X prompt
#export PS1="\$(rvm_version)\W \$(parse_git_branch)\$ " # Without the colors

# I had to put the \[ and \] down here, as opposed to $IRED, to avoid wrapping funkiness.
export PS1="\[$IRED\]\$(rvm_version)\[$NO_COLOR\]\W\[$IGRN\]\$(parse_git_branch)\[$NO_COLOR\] \$ "

I encountered all kinds of weirdness getting the colors to work. The problems all centered around getting the \[ and \] correct. If you’re having problems where the wrapping is wrong, or arrow keys or the backspace causes your prompt to disappear, check your \[\]‘s. The rule of thumb is the characters you’re escaping should be wrapped in them. Keep in mind, the color codes don’t seem to include a ] at the end.

I got my color codes from here. At the bottom of that page is a dandy script which prints out all the colors and backgrounds making it easy to find a good color combination for your terminal.

References:
Ruby version and gemset in your Bash prompt? Yes sir!
Bedazzle Your Bash Prompt with Git Info

If you are going to work through the examples, just be warned, they aren’t going to work out of the box. I don’t know who was supposed to be checking they work, but they dropped the ball.

This is where I’m going to keep track of all the things I had to change/tweak/massage to get it to work.

Chapter 1: Implementing and Consuming Your First Service

• You also need Rack-Test gem install rack-test
• The Rackfile and spec/service_spec.rb won’t work. I have created a gist where you can view my comments about what I had to add.

Several Google searches turned up precisely zero answers. After poking around I found the .htaccess file that WordPress so kindly generates for you:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

What this little guy is doing is displaying a nice pretty 404 page, instead of a plain old ugly Apache page. It does this by looking to see if there is a file or directory matching the file name in the request.

Obviously, there aren’t files and directories to correspond with your web app urls. The solution is, quite simply, to tell Apache not to go looking for files and directories when the request needs to go to your web application. So how do you that? Like this:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/myrailsapp.*
RewriteRule . /index.php [L]

Voila! Now Apache won’t try looking for any files or directories when the request begins with “myrailsapp.”

Here’s how I “fixed” it. I added the following to root’s crontab:

17 3 * * * /bin/cat /var/db/swupd/html/content/catalogs/index.sucatalog.apple | /usr/bin/sed 's/swcdn.apple.com/10.0.5.100:8088/' > /var/db/swupd/html/content/catalogs/index.sucatalog
19 3 * * * /bin/cat /var/db/swupd/html/content/catalogs/index-leopard.merged-1.sucatalog.apple | /usr/bin/sed 's/swcdn.apple.com/10.0.5.100:8088/' > /var/db/swupd/html/content/catalogs/index-leopard.merged-1.sucatalog
23 3 * * * /bin/cat /var/db/swupd/html/content/catalogs/index-leopard-snowleopard.merged-1.sucatalog.apple | /usr/bin/sed 's/swcdn.apple.com/10.0.5.100:8088/' > /var/db/swupd/html/content/catalogs/index-leopard-snowleopard.merged-1.sucatalog

Keep in mind this is the crontab for the root user (I used sudo crontab -e), not the system crontab, which is normally located in /etc/crontab. Speaking of which, where the hell did that go?

Seriously, Apple, WTF? Why is it so friggin’ hard to make a service that pulls a bunch of files off the web and generates an XML file? If I weren’t pressed for time, I’d replace swupd_syncd with a hundred lines of Ruby code.

When it comes to OS X Server, I’m aghast at how difficult it is to get the simplest things to work. The “enterprisey” Apple stuff is awesome in theory, but horrible in practice. It took days to get the OpenDirectory stuff to work properly.

Even still I have all kinds of problems. For some reason OpenDirectory decides it’s just going to take a nap, and it will take three minutes (or more) for anyone on the network to do anything. Imagine how fun it is trying to change tabs in Workgroup Manager and it takes three minutes between each mouse click.

Here’s another: periodically OpenDirectory will decide to disable a mobile user. For those of you who’ve never experienced this, when that happens, the client machine will disable the local user account. And good luck getting that re-enabled (after you enable it in WGM). You can run this command a bunch of times:

sudo pwpolicy -a LOCAL_ADMIN_SHORTNAME -n /Local/Default -u USER_SHORTNAME -enableuser

But it only works 25% of the time. The rest of the time you get messages about user not being disabled or not having a shadowhash. Sometimes if you just reset the user’s password that will re-enable the account. Otherwise reboot it a whole bunch of times until it finally figures out the account is enabled in OpenDirectory.

First I restarted my app, and let it run for a bit, then I used “passenger-status” to see what the threads were doing:

----------- General information -----------
max      = 30
count    = 3
active   = 0
inactive = 3
Waiting on global queue: 0

----------- Domains -----------
/srv/rails/myapp/current:
  PID: 9734    Sessions: 0    Processed: 48      Uptime: 18m 54s
  PID: 9704    Sessions: 0    Processed: 49      Uptime: 19m 5s
  PID: 9706    Sessions: 0    Processed: 57      Uptime: 19m 2s

I’d basically just run it again every few minutes to see what was happening, and then I got this:

----------- General information -----------
max      = 30
count    = 4
active   = 0
inactive = 4
Waiting on global queue: 0

----------- Domains -----------
/srv/rails/myapp/current:
  PID: 9822    Sessions: 0    Processed: 34      Uptime: 4m 57s
  PID: 9706    Sessions: 0    Processed: 103     Uptime: 26m 43s
  PID: 9704    Sessions: 0    Processed: 107     Uptime: 26m 46s
  PID: 9734    Sessions: 0    Processed: 75      Uptime: 26m 35s

Mon May 17 13:54:20 MDT 2010

(I actually started running passenger-status; date so I could have the time I ran the command). The above tells us that at roughly 13:49 Passenger spun up another thread. Refreshing NewRelic, I saw this:

I spent more time investigating, and it does seem that the queue wait spikes, roughly correspond to times that Passenger starts more threads.

If you peruse the Factory Girl docs, it mentions associations, but only how to handle a simple “belongs to” or maybe “has one” sort of association. My good friend led me to this thread on StackOverflow.

Basically, the user fowlduck came up with the solution of having an “after_build” block.

My problem couldn’t be solved with a simple “has_many/belongs_to” association, because in this case I needed to ensure the invoice seller matched the producer of the product being invoiced. Here was my solution:

Factory.define :invoice do |i|
  i.after_build do |invoice|
    invoice.buyer = Factory.create :consumer unless invoice.buyer
    next if invoice.seller
    invoice.line_items = [Factory.create(:line_item)]
    invoice.seller = invoice.line_items.first.product.producer
  end
end

So first, notice the “unless invoice.buyer” and “next if invoice.seller” these allow me to override these values in my tests. You’re gonna wanna keep that in mind. Next, I create a LineItem, which automatically creates a product, which in turn, creates a producer. After that I can just set the seller to be the producer of the product in the first line item. Voila, product line_item producer matches invoice seller.

I’ve found this tremendously useful. Here’s another example of how I’ve used it:

Factory.define :user do |a|
  name = Faker::Name.name
  a.real_name { name }
  a.username { Faker::Internet.user_name(name) }
  a.password 'secret-1'
  a.password_confirmation 'secret-1'
  a.email_address { Faker::Internet.email(name) }
  a.after_build do |login|
    next if login.valid?
    next unless login.errors.invalid?(:username)
    login.username = Faker::Internet.user_name(login.real_name)+String.random(4)
  end
end

I did this because, everyone once in a great while my tests would fail because the same username is used more than once. But now, if this happens, I just tack on 4 random characters. Since i did this, I haven’t had the test fail.

Are you using the fetcher plugin and Capistrano for deployment? Hey, me too! Apparently I’m the only one in the world who didn’t immediately know how to make them work together though.

Here are my Capistrano tasks for starting/stopping/restarting my fetcher daemons:

after "deploy:restart", "fetcher:restart"

namespace :fetcher do
  desc "Stop the fetcher_mailer daemons"
  task :stop, :roles => :app do
    run "RAILS_ENV=#{rails_env} ruby #{current_path}/script/mailer_daemon_fetcher stop"
  end

  desc "Start the fetcher_mailer daemons"
  task :start, :roles => :app do
    run "RAILS_ENV=#{rails_env} nohup /opt/ruby-enterprise/bin/ruby #{current_path}/script/mailer_daemon_fetcher start", :pty => true
  end

  desc "Restart (cycle) the fetcher_mailer daemons"
  task :restart, :roles => :app do
    stop
    start
  end
end

The real key here is on the :start task, there are two things you need to do to get the shell to let go of the process.:

1. Add the nohup to your command. If you don’t do this the process goes into the background, and as soon as the shell exits the OS says “SIGHUP” (“you don’t have to go home, but you can’t stay here.”)
2. The second thing is the :pty => true. This tells Capistrano to request a pseudo terminal. I don’t know all the nitty gritty, and have neither the time nor the inclination to dig in and find out why.

So there you go, add a nohup and :pty => true and then you can get your fetcher daemon backgrounded.

The error occurred while evaluating nil.url_for

The problem, it turns out is ActionView::TestCase doesn’t like url_for, it seems to expect you’re using named routes. So, in your helper, instead of doing something like:

def link_to_awesomeness(my_object)
  if my_object.awesome?
    link_to 'Awesomeness', :action => 'show_awesomeness', :id => my_object
  else
    link_to 'Make Awesome', :action => 'make_awesome', :id => my_object
  end
end

Try something more like this:

def link_to_awesomeness(my_object)
  if my_object.awesome?
    link_to 'Awesomeness', awesomeness_path(my_object)
  else
    link_to 'Make Awesome', make_awesome_path(my_object)
  end
end

Of course this implies you’ve created those named routes in your config/routes.rb, e.g.:

map.awesomeness 'my_objects/:id/awesomeness', :controller => 'my_objects', :action => 'show_awesomeness'
map.make_awesome 'my_objects/:id/make_awesome', :controller => 'my_objects', :action => 'make_awesome'

script/generate model CreditCard ... encrypted_expiration_date:date ...

Chugging along writing my tests I wrote a test like this:

class CreditCardTest  < ActiveSupport::TestCase
  context "A CreditCard instance" do
    subject { CreditCard.new(:expiration_date => new_expiration_date) }
    should("ensure expiration_date is encrypted") do
      assert_equal expiration_date_cipher_text, subject.encrypted_expiration_date
    end
    def new_expiration_date; Date.today+90; end
    def expiration_date_cipher_text; "!!!EXPIRATION_DATE_CIPHER_TEXT!!!"; end
  end

And the model looking something like this:

class CreditCard < ActiveRecord::Base
  def expiration_date=(exp_date)
    @expiration_date = exp_date
    self.encrypted_expiration_date = encrypt(exp_date)
end

The test would fail every time like:

Finished in 0.030941 seconds.

  1) Failure:
test:  should encrypt expiration_date. (CreditCardTest)
    [test/unit/credit_card_test.rb:53:in `__bind_1261076018_868915'
     shoulda (2.10.2) [v] lib/shoulda/context.rb:351:in `call'
     shoulda (2.10.2) [v] lib/shoulda/context.rb:351:in `test:  should encrypt expiration_date. ']:
<"!!!EXPIRATION_DATE_CIPHER_TEXT!!!"> expected but was
.

1 tests, 1 assertions, 1 failures, 0 errors

Can you guess the problem? Ten points to Gryffindor if you said it's because the column type is date. And another five points if you can say it's because ActiveRecord is tries to parse it to be a date object, which fails, and returns nil.

In the the article they suggest limiting the addresses from which the admin can be accessed. If you’re using Apache, here’s one way using the <Location> directive:

<Location /wp-admin>
   Order Deny,Allow
   Deny from all
   Allow from example.com 10.211.34.83
</Location>
<Location /wp-login.php>
   Order Deny,Allow
   Deny from all
   Allow from example.com 10.211.34.83
</Location>