skip to main |
skip to sidebar
"Laziness is a virtue." - Eric S. Raymond
"Premature optimization is the root of all evil." - Donald Knuth
Word. So, I'm imagining breakfast with Eric and Donald...
8:30am
Don: We're out of eggs. I'm going to the store.
Eric: O.K. I'll wait here.
9:15am
Don: There's no bread. I'm going to the store.
Eric: Yeah. Whatever.
10:00am
Don: Ooops. Out of OJ. I'll be right back.
Eric: Could you move to one side? I'm watching the game.
10:45am
Don: Damn. No toilet paper. Breakfast will have to wait a bit longer.
Eric: Could you pick up some beer?
And now a "a word of warning" (sic) from the ActiveRecord API docs:
Don‘t create associations that have the same name as instance methods of ActiveRecord::Base. Since the association adds a method with that name to its model, it will override the inherited method and break things. For instance, attributes and connection would be bad choices for association names.
Reading that was another one of those "No. Really." moments.
The second time an undetected collision of this type got me (note to self: don't name a database column "errors" unless you have an afternoon to spare) I really considered some shell (better yet Perl, heh) scripts to grep out all the method names from all the plugins + my code and check for collisions. I now instinctively avoid any obvious or intuitive sounding name for a column or method. Since we're up to a dozen+ plugins, it's probably in use already.
The interpreter could issue a warning of some kind when overloading and a test flag was set, I suppose. HEY! Agile means no whining. Suck it up and KEEP TYPING!
I don't know how I missed this but I did. This morning it bit us, hard.
Ruby constants aren't constant. Well, actually, the constant is a reference to an object. That's immutable, but you can use it to change the object it will refer to. Really. It's a feature:
"Ruby, unlike less flexible languages, lets you alter the value of a constant, although this will generate a warning message." - from Programming Ruby, by Dave Thomas
Umm, isn't that what's usually meant by "variable?" So you mean that...
irb(main):001:0> CONST = "foo"
=> "foo"
irb(main):002:0> CONST = "bar"
(irb):2: warning: already initialized constant CONST
=> "bar"
Yeah. Well, I vote we get rid of that annoying error message. It kinda spoils the thrill.
Another day, another few hours of googling Ruby blogs to figure out how to accomplish some seemingly trivial task. This time it's making some minor adjustments to the XML rendering of an ActiveRecord model when the controller is being supplied by ActiveScaffold. Don't get me wrong, I love automagically created applications. It's just that, sometimes, all you want to do is change... this one... freaking detail...API says you can pass options to to_xml. As in:
my_model.to_xml :except => [:ugly_field]
Problem is, the to_xml method is getting called by the ActiveScaffold ApplicationController and you don't really want to edit that. If you just want to make a small adjustment and not rewrite the entire rendering method the best option you have is to overload this method in the model class, add the options to the passed array and call super()
def to_xml(options={})
options[:methods] = [:get_formatted_value, :other_value]
options[:except] = [:irrelevant_accession_number]
super(options)
end
Should have been obvious, I suppose, but I spent some of my (dwindling) wattage on it. Oh well, here's hoping the next rubie finds this on a google search for "activescaffold xml rendering."
