Object Daddy

Posted by rick Tue, 27 Nov 2007 15:14:00 GMT

I’m posting at a new site (b.logi.cx) ... more news on that later. The first article is about a new piece of software I’m developing called Object Daddy, meant to do away with the need for Ruby on Rails fixtures and to greatly ease ActiveRecord model testing. The article about it is LONG, but don’t let that scare you, it’s all in good fun.

Tags daddy, flawed, logic, logicx, object, ogconsulting, output, rails, ruby, testing | no comments

A couple of random Rails tips

Posted by rick Wed, 03 Jan 2007 00:07:00 GMT

UPDATE: I edited the autotest hook to (1) fix a bug, and (2) to make it more readable (not sure if I succeeded, but worth a shot).

I figured out a couple of things that were useful enough to me that I thought I’d share.

First off, if you’re a big user of autotest (and if you’re not, you might oughta should be), and you’re working on a really large application, maybe you’ll find this useful:

Drop this in your ~/.autotest file:

Autotest.send(:alias_method, :real_find_files, :find_files)
Autotest.send(:define_method, :find_files) do |*args| 
  real_find_files.select do |k,v| 
     (ENV['AUTOTEST'] and ! ENV['AUTOTEST'].empty?) ?   
        Regexp.new(ENV['AUTOTEST']).match(k) : true
  end
end

% AUTOTEST='users' autotest    # run all tests with 'users' in the name
% AUTOTEST='digital.*cont'  autotest   # run all the digital signaturing functional tests
% AUTOTEST='party|digital'   autotest  # run all tests for parties or digital signaturing

This allows you to focus in on a small area of concern and still get the rapid feedback autotest gives you. Be sure to periodically run your entire test suite to make sure you’re not missing action-at-a-distance errors.

The other tip is a purely Rails tip. If you’re ever used ActiveRecord’s polymorphic associations then you may have run into a situation where you want many many many things to be able to be on the other (has_many) end of the polypmorphic association. I ran into this while doing work with digital signatures: I want to be able to associate a signature with almost any model object in my system. I should be able to retrieve the signatures (if any) for an object by just saying “object.signatures”.

This would normally require a “has_many :signatures, :as => signable” in every signable class in the system. Maybe reasonable, but if I were to forget to add the has_many to a class signaturing would stop working. It’s actually worse in my case since the signing algorithm can sign a web of related objects, so forgetting the has_many in one class would result in failures in related but not identical classes.

I decided to add functionality to have this happen automatically. At first I tried just opening ActiveRecord::Base and adding the call, which doesn’t put the call in the right scope for the subclasses (as don’t a variety of other AR::Base hacks I tried). I realized at some point that I needed to use Ruby’s “inherited” method to get the subclass at the right time, but AR::Base already uses inherited for other nefarious purposes. It turns out, this is the incantation that works:

class ActiveRecord::Base
  def self.inherited_with_signaturing(subclass)
    self.inherited_without_signaturing(subclass)
    subclass.send(:has_many, :signatures, :class_name => 'DigitalSigDigest', :as => :signable) unless subclass.name =~ /^DigitalSig/
  end

  class << self
    alias_method_chain :inherited, :signaturing
  end
end

As you’ll notice, my signaturing model is actually DigitalSigDigest. Also, I have other DigitalSig-something classes lying around that are part of the signaturing library, and using inherited this way allows me to actually conditionally include/exclude which classes get the signaturing has_many relationship. That’s cooler than I expected. Chalk up another one for Ruby.

By the way, you’re probably also going to be interested in this ticket if you’ve got STI classes with polymorphic stuff linked to them.

Tags autotest, polymorphic, rails, ruby | no comments

autotest + growl

Posted by rick Tue, 12 Sep 2006 11:48:00 GMT

Corey and I hacked some glue last night to attach AutoTest to Growl. Really simple, but putting those two cool tools together is really powerful.

Tags autotest, growl, output, rails, test | no comments

MacBook

Posted by rick Sat, 02 Sep 2006 21:21:00 GMT

My faithful iBook G4 has been growing a bit long in the tooth and it’d finally crossed the pain threshold a few weeks back and so I started pricing a MacBook. At work we’re building a large Rails application, and our test suites need to be run regularly. We have a continuous integration server which will run on each check-in, but unless you’re running the tests on your own machine it’s gonna be a pain when you commit broken code. Our (intel + Linux) build server can run the test suite in about 2 minutes, the MacBook 2.0Ghz systems and the MacBookPro’s all come in around 2 minutes as well. The g4 Powerbooks are coming in at around 6 minutes (painful), but my iBook G4 runs the tests in right at 10 minutes (OUCH). If I were using the laptop for just email and web browsing it would be fine, but having TextMate, Firefox, the entire Ruby/Rails server and development environment, Postgres, and often iTunes, SubEthaEdit, iChat, etc., all going, it’s not suitable for a developer machine.

So, I bit the bullet and bought a MacBook today. I first went to the Apple Store here in Nashville. That was full-on Noe Valley-style mayhem. I could swear I saw an arm dog or two, and, was it just me or were those toddlers both named Tyler? Regardless, they informed me that they had absolutely zero of the white MacBooks in stock (white being important because they’re the cheaper ones, and the black ones are a rip off: $200 extra gets you 20GB of extra disk and a coat of black paint). Damn!

So, I rolled out of Noe Valley and hit the CompUSA over at “leading economic indicator mall” (aka “100 Oaks”), which mall seems to be indicating a pretty hard economic spell ahead. Anyway, CompUSA was almost a ghost town, but they did have the MacBook I wanted, for the mandated same price, and I said “hook me up, yo.”

As an aside, CompUSA, if our store is any indication, is a shortable stock (are they even publicly traded? Presumably—too lazy to look). What few customers are there seem to be frustrated most of the time. When I went to check out they took me to the business checkout area where they apparently have the laptops sequestered, and there was some problem with the register over there so the guy walked me back to the main registers. None of those registers were staffed and there were about 5 or 6 people (the entire customer population of the store I’m guessing) obviously trying to figure out how to get checked out. One lady exclaimed, ” You work here! Wow. How can we get checked out?” To which the man leading me around the store said, “I’m about to open a register”, adding that he was going to check me out first (which seemed to cause some exasperation amongst the customer population, but, well, I just smiled as politely as I could and let the man fulfill his little prophecy).

Point being, on a Saturday, when people are throwing so much cash (er, probably credit, actually) down the street that the Apple Store can’t keep the hardware in stock, CompUSA has plenty of stock and noone to buy it—at essentially the same price. And when people do come in and are ready to pay for a purchase, there’s not enough staff on hand to actually take their money in a timely manner.

That’s a sign of a store that’s adrift, and I’m guessing that it’s a sign of the company at large being adrift.

But, I’m pretty damn happy, because I got the item I wanted with no hassle, for the same price as anywhere else, got good advice from their Mac guy, and was checked out as a priority (because I was buying a big-ticket item I’m going to presume).

So, I’ll be spending some time this weekend configuring my new laptop. Thanks go to Corey for documenting (yet again) the process of setting up a MacBook for Rails development.

More later.

Tags macbook, output, rails | no comments

high-speed ruby debugger inline-able in Rails

Posted by rick Thu, 13 Jul 2006 01:07:00 GMT

Kent Sibilev posted a cool article, Tutorial on ruby-debug ,which shows off his new Ruby+C hybrid debugger suitable for use with large applications, such as Rails apps, where the debug.rb debugger was just too slow to be useful.

This brings most of the slickness of the breakpointer (just drop a line in your code and wait for the prompt to appear) to the power of the debugger (pop up and down stack frames with ease, step, breakpoint, watchpoint, whatever). Just gem install the thing and hack++.

Looks like the only thing is missing is the DRuby hooks to let the new debugger work with FastCGI (etc.) when there’s no console waiting, and I’m guessing someone will get to that before my lazy butt gets around to scratching that particular itch.

Very cool.

Tags input, rails, ruby | no comments

Our software project makes front page of Tennessean Business section

Posted by rick Tue, 16 May 2006 00:48:00 GMT

Our CEO was profiled on the front page of the Tennessean’s business page this morning. It’s quite a long article, and in the last 1/3rd of it he talks quite a bit about the software project I’m managing. He doesn’t mention it, but it’s (to our knowledge) the largest Ruby on Rails project on the planet, and one of the higher profile ‘we switched from Java’ cases you can find as well.

So, um… W00t!

Tags input, rails | no comments