As many know Matt Aimonetti presented a risque set of slides at GoGaRuCo comparing software developers to porn stars. I'll leave as an act to the interested finding the slides.

The presentation somewhat, but the reaction of Matt and some other Rails leaders, DHH in particular, to the reactions of those who were offended by the presentation has engendered an uproar of significant proportions. On April 28th Matt posted his public response to the controversy, and later followed up with the following on twitter: "I obviously made a mistake. I didn't mean to offend anyone but since I did, I failed." Which he also posted to his blog as a followup to his previous public statement.

Today is the day. I have been working on a new project called Modal Tracker. A system to track intermodal shipments. We are starting our FREE beta officially today.

Modal Tracker is an online system for tracking shipments done via steamship carriers. Modal Tracker features automatic updating of your shipment's information from online sources. You don't need to do the manual work. Modal Tracker is web-based software, so it's easy to get started. There's nothing to install. No servers to buy. Just enter a bill of lading number and you're started.

When testing an ActiveRecord model that validates_uniqueness_of using Shoulda's should_validate_uniqueness_of macro it needs to be wrapped in a context where an instance of the model is created in the database. If there is no record in the database to validate against you'll get an error.

For more information see: Lighthouse Ticket.

Yesterday we got Cucumber working to test an older J2EE application that uses EJB 2.1 for its persistence layer. This application because of the J2EE EJB 2.1 beans has been very hard to near impossible to test in the past. I've been hearing about Cucumber for a while and we decided it was time to take a deeper look.

We plan on adding new features to this application using Rails, and over time porting the existing functionality to Rails. So, having a test suite written in Ruby that can test the application regardless of the underlying implementation was necessary. Cucumber with Webrat to the rescue. The general outline below will work with web applications written in any language. All of the interaction with the application happens at the HTTP protocol level.

Nokogiri's #xpath != Hpricot's #xpath

In Hpricot you can call xpath on a node to get the XPath that will retrieve that node from the document. In Nokogiri that equivalent is path.

I ran into this trying to figure out the xpath to a node in an HTML document. My normal routine is to load up the document in IRB and poke around to find the things I need.

I was recently reading Martin Fowler's Refactoring. While I was reading Introduce Local Extension (p. 164) all I could think of was how simple it is to implement in Ruby.

Motivation

As Fowler says in the motivation section writers of classes and libraries are not omniscient. Inevitably some class that you're using will be missing some feature you want. Using Introduce Local Extension you can add that additional functionality when you need it.

In a statically typed language, like Java, this refactoring would involve creating either a wrapping class or a descendent of the original class. In Ruby we will accomplish the same thing using a mixin.

There are a decent number of books out there on Ruby. In my mind I consider Chapter 11 of The Ruby Way, 2nd Edition the most important chapter you can read.

Mastery in Ruby involves moving past regular programming and embracing the dynamic features of the language. The dynamic nature of Ruby goes far beyond dynamic typing. Frequently programmers coming to Ruby from languages like Java, C++/C#, PHP, VB.Net, and other statically and dynamically typed languages think that dynamic typing is the extent of what is dynamic about Ruby[1]. Chapter 11 of The Ruby Way will greatly disabuse them of this notion and put them on the pathway to Ruby mastery.

After reading The power of JRuby and the discussion that ensued I was inspired to write about why I chose Ruby and particularly JRuby as my company's primary development platform.

I didn't write this post as a knock on Groovy. If it wasn't for Groovy I doubt I'd be working in Ruby today. For me Groovy was my "gate-way drug" into the dynamic language realm. My reason for this post is to explain why someone might want to use Ruby on the JVM over Groovy.

After working with Groovy for quite a while I started dabbling in Ruby. At first I really didn't get it. Then I watched a presentation by Dave Thomas and the lights went on. A world of possibilities opened up for me, and they were easily in reach.

I'm in the process of porting an application from Java/Groovy to Ruby on Rails. All of our times are stored in the database in local time. So, I needed ActiveRecord to store a time without converting it to UTC, which 2.2 does by default. (I'm not sure when UTC became the standard though, could have been before 2.2.)

After some Googling and asking on IRC it was suggested I try:

config.active_record.default_timezone = :local

This sets the ActiveRecord::Base.default_timezone class attribute. Unfortunately that didn't seem to have the desired effect. Dates were still stored in UTC but when retrieved via accessors they were converted to local time. Not what I wanted.

Sometimes I'm embarrassed for my nation. I'm not an Obama supporter, for policy reasons, but this type of blind ignorance is frightening: Misconceptions of Obama fuel Republican campaign - 13 Oct 08. Unfortunately this blind ignorance and prejudice has provided fuel to stoke the fires of yet more prejudice, that between the Muslim world and the United States.

I'm a Republican. I have been my whole life. But my fellow Republicans need to get over it. Barack Obama is probably going to be our next president. We as Americans need to make peace with that collective national decision.