September 2008 Archives

Thanks to Tim @ Omni for pushing out a quick fix to allow this script to be. I've already used it half a dozen times:

-- schedule a followup of the selected items 7 days from now... more to come

tell application "OmniFocus"
  tell first document window of front document
    set thetrees to selected trees of content
    repeat with idx from 1 to count of thetrees
      set atask to value of item idx of thetrees

      set newtask to duplicate atask to after atask

      set due date of newtask to (due date of newtask) + (86400 * 7)
      set name of newtask to "Followup: " & name of newtask
    end repeat
  end tell
end tell

Flay is Coming

| | Comments (2)

Imagine having a tool that points out these two methods as potential duplicates and therefore candidates for refactoring:

def save(path)
  File.open path, 'wb' do |f|
    f.write to_blob
  end
end

versus:

def write(file); File.open(file, 'wb') { |f| f.write to_s }; end

Are they different? Sure! One calls #to_s and the other calls #to_blob. Is that enough difference to not consider them for refactoring? No, not in the slightest...

Flay... it is coming...

Letting Go

| | Comments (1)

I was having a discussion on irc the other day with apeiros about a number of topics and we had a minor tangent about control:

apeiros_  : I don't like it
apeiros_  : simply because it inverts control
apeiros_  : and causes havoc on bug detection
apeiros_  : surprises me actually that you're not one of
            those who'd prefer having control
zenspider : actually, I'm fairly anti-control
apeiros_  : with your variant, it *might* be that you *might*
            have wanted it, but maybe not.
zenspider : "might" is key... that is the lack of control...
            I'll let the objects sort it out.
apeiros_  : so your objects know more than you?
zenspider : yes... they often do
apeiros_  : ouch, then.
zenspider : not ouch... that's their job
apeiros_  : to know more than you?
apeiros_  : I doubt that :)
apeiros_  : you should have the whole picture.
            objects should only know what their concern is.

Tonight I came across a quote that struck a chord with me (no pun intended):

"The thing about musical instruments is that it should be on the verge of falling apart. That is where the line is. If it's on the edge of falling apart, you've probably made a pretty good instrument."

Danny Ferrington, Master Luthier, DVD Extras on The Ladykillers.

The message I was trying to convey was very related. If you build a guitar that is too strong, it won't actually move any air and no (or bad) music comes out. If you build your software in a similar manner, it won't do anything or it will do it so poorly you don't want to use it (and you certainly don't want to work on it anymore).

Instead, think of objects as having their own responsibility. It is your job to bring objects together, but let them do their jobs w/o micromanaging. My best software has always been written such that I bring objects together, and just say "now, go" and let them do their thing.

It is that time of year again! (yes, I'm a bit late posting this)

There is a certificate course at the UW starting this fall. It is 3 quarters long starting at rubynewb, then rails/web development, then rubyjedi. no, not the real titles. You are not required to take all three courses. do what feels right. For more info:

http://www.extension.washington.edu/ext/certificates/rby/rby_gen.asp

There is space available. apparently, plenty of space... so to make this a success, if you are interested or suspect someone you know is interested, PLEASE, help make it happen.