TimShadel.com

Mike Clark is wondering:

Which RubyGems are you sporting?

So my current list is down below. I imagine it will change soon — maybe tomorrow.

gem list | grep “^[a-zA-Z]“

actionmailer (1.3.2, 1.3.1, 1.2.5)
actionpack (1.13.2, 1.13.1, 1.12.5)
actionwebservice (1.2.2, 1.2.1, 1.1.6)
activerecord (1.15.2, 1.15.1, 1.14.4)
activesupport (1.4.1, 1.4.0, 1.3.1)
aws-s3 (0.3.0, 0.2.0)
BlueCloth (1.0.0)
builder (2.0.0)
capistrano (1.4.0, 1.3.0, 1.2.0)
cgi_multipart_eof_fix (2.1)
daemons (1.0.4, 1.0.3)
ezcrypto (0.7)
fastthread (0.6.3)
gem_plugin (0.2.2, 0.2.1)
hoe (1.2.0)
hpricot (0.5, 0.4)
libxml-ruby (0.3.8.4, 0.3.8)
mechanize (0.6.4)
mime-types (1.15)
mongrel (1.0.1, 0.3.13.4)
mongrel_cluster (0.2.1)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.0.10)
rails (1.2.2, 1.2.1, 1.1.6)
rake (0.7.1)
RAliasFile (0.1.0)
rubyforge (0.4.0)
rubyosa (0.2.0, 0.1.0)
sources (0.0.1)
wirble (0.1.2)
xml-simple (1.0.10)
ZenTest (3.4.3)

1. Download winstone from it’s Sourceforge Files page
2. Download the Hudson war file from its Java.net Release page
3. Then run java -jar winstone-0.9.6.jar --warfile=hudson.war --httpPort=8081
4. You should see something like the screenshot below.
5. Play.

One of my favorite features of Hudson is the ability to watch the console output of a build in progress, like this one:

Other cool things include:

• No more messing around with XML
• I can setup a Hudson job and use it to run mvn release:clean release:prepare on my branch code. (Haven’t tried this beyond tinkering yet, though. Could possibly be manual or nightly job it seems.)
• It’s easy to have several builds for different branches and see them all at once.
• There’s a really cool build history graph that shows both the time it took to build each release, and whether it passed or failed — makes it easy to see your build trends on the team.

I’m looking forward to investigating it’s publishing of Javadoc and JUnit test results. I also want to see if it’ll do anything with Maven’s site generation. If so, that’d be a big win. I’ve fiddled with Continuum, but this just feels like a better setup to me, and the author seems eager to add Maven2 integration to it.

After having it around for a couple weeks, I’ve tentatively switch our build to use it. It’s just so easy to turn on, that it seems like a no brainer. If it doesn’t pan out then we can always turn CruiseControl back on, but I don’t anticipate that outcome. Something else I might try is to drop Hudson into Tomcat if winstone seems to strain, but I don’t think we’ll need that either. It’s built our stuff plenty fast in that little servlet container for a few weeks now, so I’m not anticipating any load increase to it — simply more publicity for it among our team.

Try it out. Let me know if you think it’s worth the switch.

This morning I experimented a bit with overriding the default HTML generated by validation errors in Rails. Instead of wrapping the <input> tag inside a <div class="fieldWithErrors"> indiscriminately (which was breaking the layout I wanted), I wanted to simply inject a new CSS class onto the HTML element.

I found one email showing how to use regular expressions to get the job done. It may work, but I wanted something that seemed a little less blunt. I’ve also been playing around with Hpricot lately as well. So I decided to try to combine the two. Here’s the first draft of what I came up with:

require ‘hpricot‘

Rails::Initializer.run do |config|
  . . .
  ActionView::Base.field_error_proc = Proc.new do |html_tag, instance|
    doc = Hpricot(html_tag)
    elem = (doc/“/“).first
    css_class = elem.attributes['class']
    css_class ||= ““
    css_array = css_class.split(“ “)
    css_array << “fieldWithErrors“
    elem.attributes['class'] = css_array.uniq.join(“ “)
    doc.to_s
  end
end

I then changed the CSS ever so slightly from the default scaffold.css:

.fieldWithErrors {
  border-color: red;
  background-color: #ffcccc;
}

The result looks like this:

The layout I had before is completely preserved, and I have the chance to color the input the way I want. I haven’t tried it with a <textarea>. Also, I tried to adjust for the possibility of other CSS classes already existing on the element, but I’ve only checked it in irb. Let me know if you’ve got improvements to this approach; I’d love to hear ‘em.