Dangosaur.us

Recently I’ve been using Capistrano to deploy projects to Solaris. One client uses a Joyent Accelerator (OpenSolaris) and another (University of Virginia) uses Solaris 5.8. The Accelerator is great as it has ZFS, the new Solaris Services, speed, etc. But Solaris is not the same as Linux or FreeBSD when it comes to certain common utilities and this has caused me problems on both servers.

ln

The main culprit is ln. Capistrano use ln -nfs all over the place to make soft links. Unfortunately, the version in Solaris’s /usr/bin does not remove existing soft links with this command. Oy. My first response was to rewrite the tasks like :symlink and :on_rollback to add rm -rf in front of the link command. After forgetting to do this once or twice in new deploy scripts, I posted to the TextDrive forums. Someone mentioned that the Blastwave version of ln (gnu’s version) worked. Well I’m using Blastwave (and you should too), but I don’t remember seeing that. It turns out that gnu’s ln is in /opt/csw/gnu/, not /opt/csw/bin/.

So I just needed that in front of my path, but when Capistrano logs in through ssh, it doesn’t pick up either /etc/profile or ~/.profile. (I don’t have links handy, but apparently this depends on how bash was compiled.) There are two ways of dealing with this. You can add a path to your ssh config (here’s some info), but I prefer making the change in /etc/default/login. I want the Blastwave stuff to take precedence all the time.

I was reading a post to Rails Studio mailing list today when I came across this:

If you’re using mocha/stubba, you can say: @user_notifier.expects(:deliver_activation).never

If you’re using flexmock, you can say: flexmock(@user_observer).should_receive(:deliver_activation).never

Which would I rather use? Disregarding the frameworks, if you read my previous post, you know the answer: use the active verb! expects is far preferable to should_receive.

_why has started a new and interesting project: Hackety Hack: the Manifesto. The accompanying blog is http://hackety.org/.

This week I found the FormTestHelper plugin by Jason Garber. It both enhances and simplifies form testing in Rails functional and integration tests. The great thing is the FormTestHelper tests the form, not just the submission of the form data. For example, if you try to set a form element that doesn’t exist, an error is thrown.

Here’s my first pass at using FormTestHelper:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

assertions = proc do |response|
  assert_response(response)
  assert(exhibit = assigns(:exhibit), 
   "Should have assigned :exhibit")
  assert(exhibit.errors.empty?, 
   "@exhibit should not have errors: #{exhibit.errors.inspect}")
end

exhibit_count = Exhibit.count
get(:new)
assertions.call(:success)

submit_form('new_exhibit') do |f|
  f.exhibit.title = "New Exhibit"
  f.exhibit.exhibit_type_id = 1
  f.exhibit.license_id = 1
  f.exhibit.annotation = "Exhibit notes."
end

assert_equal(exhibit_count += 1, Exhibit.count )
assertions.call(:redirect)
assert_redirected_to(edit_exhibit_path(assigns(:exhibit)))
assert(flash[:notice])