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/.

I like behavior driven development. Even though I still using Ruby and Rails built-in testing framework, I write test names descriptive of behavior.

But I have stopped using should.

Should has become a bunch of noise in BDD that needs to be expunged. What’s wrong with test_should_move_resource_lower_and_return_to_edit_exhibit? One alone is fine, but to read a bunch of should phrases over and over is mind-numbing:

test_should_require_email_on_signup
test_should_require_password_confirmation_on_signup
test_should_require_password_on_signup
test_should_remember_me

What a lot of noise! Who wants to keep hearing the word “should” in their head over and over? Or writing it over and over? Not me!

Use the Active Verb!

So how do I write my test names? Using the active verb:

test_moves_resource_lower_and_returns_to_edit_exhibit
test_requires_email_on_signup
test_requires_password_confirmation_on_signup
test_requires_password_on_signup
test_remembers_me

Much easier to read, the ugly repetition of should is gone, and the method names are shorter. Recently, at Rails Edge in Reston, VA, Jim Weirich gave a test-first presentation where he used active verbs instead of should. I went up after and thanked him profusely.

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])

Last week I attended The Rails Edge Reston. I can honestly say that it was the best workshop or conference I have attended. I’ve been to 3 or 4 No Fluff, Just Stuff conferences, Rails Conf, and Ruby Conf. It’s true that I’ve seen many of the same speakers at these other events. Perhaps the presenting team has gelled into some sort of uber-team, but the pacing of the event and the little touches by Mike and Nicole put it over the edge for me.

It’s often said that Ruby has a very strong and positive community. The Rails Edge bore this out. One small example of this was during the MacBook Pro give-away. When the winner was announced, I heard nothing but wild, enthusiastic cheering for him.

As I told Mike Clark and a few others, this is the first conference I have attended where I was not disappointed by a single presentation. Highlights for me were all of Dave Thomas’s and Jim Weirich’s presentations. I also liked the presentation team of Chad Fowler and Bruce Williams. But as I said before, I was not disappointed in any of the presentations. The lightning and VGA presentations were fantastic, too. Quick exposure to what the some of the participants are doing with Ruby and Rails was an invaluable part of the conference.

Thanks to all the presenters and attendees, and especially Mike and Nicole for organizing the event.

HTML Element Names as Helper Methods

Summary

repository: http://svn.dangosaur.us/svn/elemental/

Introduces builder-like syntax to rhtml:

1
2

<%= p @item.content %>
<%= p span @person.first_name, :id => dom_id(@person, "name_") %>

1
2
3
4

<% table do @list.each do |item| tr do %>
  <%= td item.name %>
  <%= td item.content %>
<% end end end %>

Elemental allows you to use XHTML Transitional tags as helper methods in your rhtml. With traditional ERb, the code above would be written:

1
2

<p><%= @item.content %></p>
<p><span id="<%= dom_id(@person, "name_") %>"><%= @person.first_name %></span></p>

1
2
3
4
5
6
7
8

<table>
  <% @list.each do |item| -%>
  <tr>
    <td><%= item.name %></td>
    <td><%= item.content %></td>
  </tr>
  <% end %>
</table>

That’s more code, more noise as angle-brackets (especially embedded inside the html tag), and more lines. Elemental’s syntax is also cleaner and terser than when using content_tag:

1
2

<%= content_tag "p", @item.content %>
<%= content_tag "p", content_tag "span", @person.first_name, :id => dom_id(@person, "name_") %>

and you can’t send a block to content_tag

1
2
3
4
5
6
7
8
9

<table>
  <% @list.each do |item| -%>
  <tr>
    <%= content_tag "td", item.name %>
    <%= content_tag "td", item.content %>
  </tr>
  <% end %>
</table>
<table>

Usage

Elemental has three basic usages:

1. Self-closing tags: no argument, or hash only for argument:

1
2

<% br %>
<% br :class => "someClass" %>

2. Content tags: first argument is the value of the content:

1
2

<%= p "some content" %>
<%= p "some content", :id => dom_id(@object) %>

3. Content tags with a block argument:

1
2
3

<% div :class => "some-class" do %>
      ...
<% end %>

You can nest Elemental methods:

1
2
3
4
5

<%= p span @object.value %>
  or
<%= p(span(@object.value)) %>
  generates:
<p><span>the object's value</span></p>

The same thing with attributes (pay attention to your parentheses):

1
2
3
4
5
6
7

<%= p span @object.value, :id => "some_id", :class => "some_class" %>
  generates:
<p><span id="some_id" class="some_class">the object's value</span></p>
  while
<%= p span(@object.value, :id => "some_id"), :class => "some_class" %>
  generates:
<p class="some_class"><span id="some_id">the object's value</span></p>

You can nest the methods in blocks:

1
2
3
4
5
6

<% p do %>
  <% span :class => "someClass" do %>
    Lorem ipsum dolor sit amet, consectetur adipisicing elit, 
    sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
  <% end %>
<% end %>

1
2
3
4

<% p do span :class => "someClass" do %>
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, 
  sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
<% end end %>

1
2
3
4
5
6

<p>
  <span class="someClass">
    Lorem ipsum dolor sit amet, consectetur adipisicing elit, 
    sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
  </span>
</p>

This is useful for loops:

1
2
3

<% ul do ['one', 'two', 'three'].each do |item| %>
  <%= li item %>
<% end end %>

1
2
3
4
5

<ul>
  <li>one</li>
  <li>two</li>
  <li>three</li>
</ul>

Options/Attributes Hash

Options are converted to regular html attributes. None are filtered, so you can certainly insert invalid attributes.

1
2
3

<%= span :id => "some_id", :bogus_attribute => "some_value"%>
  generates:
<span id="some_id" bogus_attribute="some_value"></span>

Omitted Tags

Rails’ ActionView::Helpers already defines form, select, and input, so these are omitted from Elemental.

Motivation

Afer using Markaby a bit, I decided there were situations where I wanted a Markaby or Builder-type syntax within rhtml’s context. I had been using content_tag quite a bit for convenience, but wanted more legible and concise code, espcially for loops.

Acknowledgments

_why for Markaby and its list of XHTML and XHTML Transitional tag lists, which I used.

I finally finished the basic change-over to Mephisto tonight. Looks like I’ll need to restyle the code examples, as they are puny and lack any syntax-coloring.

Today would be my father’s 88th birthday, if he were still alive. Happy Birthday, dad!

Bill was a heavy-duty programmer in the early days of computing, contributing quite a lot to linear programming. He wrote a book on it and co-authored at least one article on the Simplex Method with George Danzig.

I decided I wanted all 356 rows of a table dumped to a fixture, but CSV was a disaster. So:

1
2
3
4
5
6
7

require 'yaml'
js = Journal.find_all
File.open ('dump.yml', "w") do |f|
  js.each do |j|
    f.print YAML.dump ({"j_#{j.id}" => j.attributes})
  end
end

(I actually did it from script/console.) The only caveat is I got a line of “-” between each entry that I had to delete.

A couple of days ago my MacBook Pro started shutting down randomly while running on battery. I called Apple, they had me reset the power manager and the PRAM. The next day, it shut down again, so I called Apple and they agreed to ship a new battery. Yesterday, while still on the original battery, I noticed my clicker acting funny-it felt scratchy. Today it got worse-it wouldn’t push down very far. Then I remembered a buddy who had had the same issue (our machines were made and shipped together—they tracked together all the way from Shanghai). First his MBP randomly shut down on battery power. Then the battery swelled. The swelling was so bad, it caused permanent damage to his clicker. I pulled out my battery, and sure enough, my clicker returned to normal. I looked sideways at the battery. It’s started bulging in the middle and the aluminum bottom is starting to separate.

How can there not be a recall on these batteries yet?

Here’s Anoop’s post. I have the same heat and whine issues. Apple agreed to service it a few months ago, but I’ve needed it too much to send it in. Hopefully in July.

I’ve been working on some javascript code for a client site and found a good use for binding event listeners through javascript rather than inline. There are several pages I need to add javascript code to expand each textarea on focus and collapse it on blur. So I wrote this simple function using Prototype:

1
2
3

var expandTextArea = function(event){
    Event.element(event).rows = 10;
}.bindAsEventListener(this);

The part I was unfamiliar with was .bindAsEventListener(this). It comes from the Prototype framework and is defined:

1
2
3
4
5
6

Function.prototype.bindAsEventListener = function(object) {
  var __method = this;
  return function(event) {
    return __method.call(object, event || window.event);
  }
}

While studying this, I found Simon Willison’s A Reintroduction to Javascript. I highly recommend it. At the bottom of his discussion of custom objects, he describes how to use apply() and call(). I’m not sure if my understanding is correct, but it reads to me as:

• this is passed as the Window object to bindAsEventListener(this)
• bindAsEventListener() returns a function that when called back by the event
• attaches expandTextArea(event) (in this case) to object (Window) and then calls the method.

The callbacks and closures are really interesting, if a bit difficult to understand, in Javascript. I welcome comments!

I’ve been playing with Markaby the past few nights. I love it! I’m in the camp that would rather write everything in Ruby rather than mix with html and ERb. I find reading this code:

1
2
3
4
5
6
7
8
9
10
11
12
13

error_messages_for 'laptop'

p do 
  label "Name", :for => "laptop_name"
  text_field 'laptop', 'name'
end

div do
  label "Condition", :for => "laptop_condition"
end
div do 
  collection_select("laptop", "condition_id", @conditions, "id", "description")
end

much easier and enjoyable than this code:

1
2
3
4
5
6
7
8
9
10

<%= error_messages_for 'laptop' %>

<p><label for="laptop_name">Name</label><br/>
<%= text_field 'laptop', 'name'  %></p>

<div><label for="laptop_condition">Condition</label>
<div>
<%=  collection_select("laptop", "condition_id", @conditions, "id", "description") %>
</div>
</div>

The ERb code is much noisier and therefore harder to read. The Markaby code is cleaner and more elegant.

While looking at the source code for Capistrano today, I came across a nice idiom for making class-level accessors:

1
2
3
4
5
6
7
8
9
10
11
12

class Actor  
  class << self
    attr_accessor :connection_factory
    attr_accessor :command_factory
    attr_accessor :transfer_factory
    attr_accessor :default_io_proc
  end

  self.connection_factory = DefaultConnectionFactory
  self.command_factory = Command
  self.transfer_factory = Transfer
end

Now you can use these class-level accessors:

1
2
3

Actor.connection_factory
Actor.command_factory
...

See my personal blog.