Yesterday I was pairing with Patrick, our new intern. He's great,
 smart as a whip, and willing to learn. (When I told him we write tests
 first, he laughed, incredulously, but then I said No, really, I'm
 actually serious, and he listened, and later, he said, Oh, now I see.)
 At the end of a long successful refactoring (turning a clutch of
 static methods into instance methods), we were sort of buzzing and
 didn't want to stop, were casting about for other refactorings to do
 in the same class. I suggested a technique I only just then gave a
 name to, that I've done occasionally on my own for a long time, but
 hadn't yet taught: Zen Refactoring.

 "Just let your eyes unfocus and scroll through the code and look for
 refactorings. Look for duplication; look for too-long or
 too-deeply-indented code blocks. When you notice something odd, don't
 read it, just select it, hit Extract Method (ctl-alt-M), and hit
 random keys for the name. Then focus your eyes again and see what
 you've done."

 I demonstrated. The first time we hit a bunch of print statements with
 repeated formatting -- it worked, but the refactoring was tedious,
 with marginal payoff. But the second time was golden. I saw a blurry
 if-else block; the first arm meandered for 15 or 20 deeply-indented
 lines, the second for fewer; their logic appeared opaque and disjoint.
 But after extracting the first block as a method, lo and behold:

 if (something() || other()) {
  customerId = sdlfjds(x, y, z);
  } else {
    user = someOtherExistingMethod();
    customerId = user.getUserId();
 }

 IDEA had figured out that the result of that meander was a single
 value, and returned it from the new method. It was instantly clear
 that we should rename the extracted method
 customerIdForSomethingOrOther", and extract the whole conditional as
 "getCustomerId". Shift-F6, ctl-alt-M, high five.

 Then it was Patrick's turn. Not quite as much of a slam-dunk but still
 a worthy refactoring. I can't wait to get an incredulous laugh from
 the next one I spring this on...

 When I talk with CEO and CFO types, I generally emphasize that XP /
 Agile projects focus on the delivery of running, tested, actual
 software, along the lines of my article /A Metric Leading to
 Agility/, http://www.xprogramming.com/xpmag/jatRtsMetric.htm

Thanks to Sven for emailing me this link .. a good overview article about Tiger. arstechnica.com/reviews/os/macosx-10.4.ars

Die Larry Ellison Puppe k?mpft gegen "Big Iron" und sagt "Let’s go in and kick some proprietory ass!"

ROTFL

 I've written a very nuts+bolts article on metaclasses (aka virtual
 classes or metaobjects), since they still lurk under a shroud of fear
 and enigma.

whytheluckystiff.net/articles/seeingMetaclassesClearly.html

 I'm hoping this will help uncover the truth.  If anything is unclear,
 please report it.  Shed a light.

 Heh, that reminds me of a time in the late 70's, when IBM came out with a
 new "mini-computer".  We put Forth on it for a customer.  Our standard
 system came with a database capability, multitasker, multi-user support,
 lots of other features.  Another customer was considering this machine, and
 we made a presentation on our software.  Some IBM engineers were also there.
 They said, "This machine has only been on the market for a few months.  We
 have 300 engineers writing software for it in Boca Raton (Florida), and they
 only have a macro assembler and simple executive running so far.  How could
 you have done all this with only one engineer?"

 Well, I said something about having a standard design implemented in high
 level that was easy to port, but of course the real answer is that 300
 engineers would take forever writing anything!