DEPRECATION WARNING: assert_invalid_column_on_record is deprecated and will be 
removed from Rails 2.0 (use assert(record.errors.invalid?(column)) instead)

DEPRECATION WARNING: assert_invalid_column_on_record is deprecated and will be 
removed from Rails 2.0 (use assert(find_record_in_template(key).errors.invalid?(column)) instead)

<br />assert_invalid_column_on_record "user", :password<br />

<br />assert(find_record_in_template("user").errors.invalid?(:password))<br />

java.net: Migrating from EJB 2.x to EJB 3.0

The EJB 3.0 specification makes programming much simpler. It makes the container do more work and the developers do less work. It decreases the number of programming artifacts for developers to provide, eliminates the requirement to implement ejb callback methods, and reduces the complexity of the entity bean programming model.

I finally figured out the problem I had with fixtures in my unit and functional tests yesterday, so I thought I should share.

Our Rails application is deployed on Oracle, but the developers tend to use MySQL, because we use Intel iMacs, and using a PPC Locomotive bundle with the PPC Oracle driver is not exactly the fastest way to develop.

Our unit and functional tests evolved over time, to test some of the weird differences between MySQL and Oracle, just so we can catch problems at build time, instead of when we roll out to the staging/test server and inflict them on our tester. And, over time, we have come to use very few fixtures, because they always seem to cause problems in the Oracle build. We never really understood why they caused problems, we just wanted to make things work, so we put up with the need to create objects on-the-fly, and found ways to do it that were not too repetitive.

But NOT any more. Because I figured out the root cause of the fixture problems with Oracle yesterday. This week I’m working with both Rails 1.1.6 and Rails 1.2RC2 in order to prepare for the release of Rails 1.2. And I kept running into this circular pattern of test failures, where I would make a change to fix a failure in one test, and then a completely different test would fail when I switched to Rails 1.2. Fix that one, and another test would fail when I ran against Oracle. Fix that one, and another completely different test would fail back with Rails 1.1.6 and MySQL. I was really tearing my hair out. After a liberal sprinkling of debugging statements, the light bulb finally went off.

The id’s being used by my fixtures were clashing with the id’s being auto-generated by the Oracle sequences. So, I just ran through my fixture files, and altered all the id’s to be huge numbers, so they would never clash with the auto-generated id’s. And magically, all my weird test failures went away.

So, I’ll have to go back through some of my tests now, and remove some of the on-the-fly object creation, and just rely on fixtures again. I’m looking forward to it, now that I understand.

Work on a Mac notebook.  Plug in to an external monitor with a higher native resolution than your notebook screen.  While Eclipse is maximized to fill your external monitor, close it.  Unplug external monitor.  Start Eclipse again.  See the magic of having a window that is maximized, on all sides, beyond the edges of your screen.  Enjoy the dysfunction, because it cannot be fixed.  You cannot get to any menu or screen edge, which will allow you to resize or move the window.

After you’ve pulled sufficient hair out trying to fix this, hopefully you’ve Googled for a solution, and found this page.  You can’t resize your “too large” Eclipse window, but you can wack the wonky settings by closing Eclipse, deleting this file, and letting Eclipse regenerate it when you restart:

.../workspace/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml

Capistrano is an amazing tool for the remote deployment of Rails applications, but it doesn’t stop there.

capistrano-ext is an example of a set of extension tasks for Capistrano. I found out about them when I was reading a presentation that Mike Clark created. But, there are some details missing. One page says

gem install capistrano-ext

cap watch_requests

require 'capistrano/ext/monitor'

I spent way too much time last week figuring out why :validates_length_of was not working after I added the :allow_nil option to it. Basically I have some optional fields, but if the user chooses to fill in those optional fields, they need to fall within a specific range, like this:

:validates_length_of :some_field, :in => 6..20, allow_nil => true

If you put this into a model in your Rails application, you would expect that on a form submit, this would allow the user to not enter anything, or to fill in a string from 6 to 20 characters in length. Instead, when you do not enter a value, the validation throws a range error.

Personally, I’d call this a BUG. But someone out there thinks it should be an enhancement:

#3375 (blank form fields pass empty params causing AR validations with :allow_nil to fail) – Ruby on Rails – Trac

blank form fields pass empty params causing AR validations with :allow_nil to fail

So, what is the real problem here? You aren’t getting a nil back from the form when “Submit” is pressed. You get the empty string. And since ”” != nil …

I am disturbed that this so-called enhancement has been moldering for months without resolution. It’s not an enhancement, it is a BUG. Rails does NOT do the logical/expected thing here. Perhaps the solution to the bug is to implement an enhancement (like :allow_blank or :allow_empty), but AT A MINIMUM, someone needed to get in and document that :allow_nil does not work on form validations.

Meanwhile, you can work around this problem by implementing a before_validation method that assigns nil to any blank/empty strings from your form that require this kind of validation.

I followed a link from Tim Bray’s blog, about Sun hiring the JRuby developers, and ended up here. Interesting charts, but I wonder if book sales are a good indicator.

O’Reilly Radar > Programming Language Trends

Programming Language market share trend in computer books

I wrote yesterday about the rise of Ruby and Javascript, driven by the move towards Web 2.0 applications. Also worthy of note in these graphs is the long, slow decline of Java and C/C++, and the continuing rise in market share of C#. You can see how Ruby’s sharp ascent follows the introduction of Rails, and that PHP’s fortunes reversed before book sales showed that web developers in search of rapid development languages moved over to RoR (and Microsoft’s ASP.Net suite of technologies.)

A J2EE Moment of Zen – Miguel de Icaza

Microsoft’s Avalon is the J2EE of GUI APIs

Interesting. Even more interesting is the plea for the “Rails of GUI”. Now that’s what I’m talking about. Rails is gaining popularity because it is “opinionated” software which favors convention over configuration. What this means for the programmer, is that the plumbing is just assumed to be there, and it works.

Why not a “Rails of GUI”? How hard could it be?