Tuesday, May 20, 2008

The Sound of Music: Podcast Themes

For a random sidebar...

What are some favourite podcast themes? No, not the content per se, but the catchy bumpers at the beginning and end of the casts.

Some thoughts on podcasts on my playlist:

  • I'm a guitar fan so the theme at Software Engineering is a winner, and the inspiration for this post. The music is punchy, upbeat, and they always seem to fade it in and out just right. By the way, this week's guest is Anders Hejlsberg.
  • I really like the end theme/outro for Java Posse. The retro synthesized voice is delightful. The famous opener is sufficiently catchy and irritating to burrow deep into your consciousness, which is really the point.
  • Man, the band phoned it in for CNet's Buzz Out Loud. The theme is musically bankrupt, and they barely let it play, which may be merciful. However, I'm always suckered in by Molly Wood's brisk whirl through the subtitle "podcasts of indeterminate length". Nice.
  • For the Google Developer Podcast, the immediate opening isn't for me: it's punchy but something is not quite there. But when the wah guitar kicks and the woman begins to sing, I'm completely on board. Great voice and a cool vibe. The fade in is very erratic in terms of length, but at least they give the tune lots of space as the outro.

Monday, May 19, 2008

Fitness as a Competitive Advantage

Jeff Atwood blogged recently about cleaning the monitor and the keyboard.

Some quick thoughts:

  • A big +1 on not touching the monitor. I cringe every time anyone touches any monitor. It actually distracts me during code reviews.
  • Keyboard manufacturers should figure out a way that the electronics can be removed easily (like a cartridge) to enable dishwasher use.
  • Jeff mentions "my" keyboard: I guess he doesn't work in a public war-room. Believe me, that is a whole new, fascinating ballgame. More to come sometime.
  • I don't condone filth, but I'm not convinced the neat-freaks have it right, especially with those cleaners that clean 99.5% of bacteria. Hmmmm.... no training for the immune system and we leave The Nasties to party. Is that a good idea? (As an aside, check out this article on germ factories (aka children) and the beneficial effects on parents and pediatricians.)
On to the point: presumably, Jeff wants to clean his keyboard so that he doesn't get sick. However, that is only half of the equation.

It is well-documented that moderate exercise can boost the immune system. So one could argue that we owe it to our teams, our careers, and our families to get out there and work out.

Maybe you do so. Maybe you do more than me. But if not, I'm not talking about doing an Ironman (though a sprint triathlon is a fantastic accomplishment, and much easier). I'm suggesting a 30 minute session 3 times a week, where the heartrate is elevated. Don't go for a walk: that's ok, but if you want to fight germs, aim higher.

There are other benefits as well:
  • You know those "aha" moments in the shower? Well, athletes shower more often: more aha moments.
  • It's not quite as magical as the shower, but if you swim or run, it is a phenomenal way to work out problems, without trying. The whole subconscious/background cooking thing.
  • I hate the pseudo-verb "network" but if you find your niche, you'll meet all kinds of new people. Bonus.
  • I have friends/colleagues who train in mixed martial arts: that's gotta be a stress reliever.
I ain't preachin'. I ain' teachin'.

I'm just sayin'.... Something to consider.

For those who are active: what do you like to do?

Monday, May 12, 2008

Logical Fallacies Considered Harmful: You Should Learn New Languages

Gustavo Duarte recently posted an article about the folly of dabbling in new languages.

The post is an earnest one, and thought-provoking, but I realized this evening that it is a masterpiece of logical fallacy.

Problem #1: Begging the Question

Gustavo argues that "dabbling" in new languages gives superficial results to your career. To dabble is to "work at something in a superficial manner". So, the argument is that a superficial investment in something yields superficial results. Hmmm... this seems like begging the question to me.

Note that I don't mean the popular usage of "that begs the question: yada yada" but rather the classical sense of proving something that is implicit in the premise.

Problem #2: The Strawman Argument

Gustovo condemns the Pragmatic Programmers' advice to "learn a new language every year". But he goes on to set up that advice as though they are saying "Open an editor, screw around with some syntax, and wait for the enlightment to hit you". Then he knocks that Strawman down, with ease.

I just checked the Prag Prog book: it is relatively terse on this point. I may be guilty of my own "Ironman Argument" here but, having seen Dave Thomas speak on several occasions, I doubt if they intended for us to take a full year to merely mess around with some core language syntax. My guess is that they will agree with the examples in the next item.

Problem #3: False Alternative

Gustavo seems to set up two choices: either noodle around aimlessly with a new language, or learn something specific with your current language, such as algorithms, math, or AI.

Wow. We have hit the trifecta now with the fallacy of false alternative.

There are more than two choices. Let's assume that we only know Java. How about these examples:

  • Write an implementation of a Red-Black tree in Scala.
  • Compute Pi to a million decimal places in jRuby. Then check an online source to see if you are right.
  • Develop a simulator for Tic-Tac-Toe that uses genetic algorithms to evolve a winning strategy. Use Groovy.
Sounds fun to me! Personally, I would learn (or dust off) something from all of these examples. And we would learn a new language along the way.

Problem #4: When timeless arguments aren't timeless

This isn't a formal logical fallacy, but Gustavo hints at some classic, timeless elements such as Lisp and the "Gotos Considered Harmful" article.

One might think that his arguments are timeless: nope. He asserts that:

In reality learning a new language is a gritty business in which most of the effort is spent on low-value tasks with poor return on time invested. You need to get to know the libraries, struggle with the environment, find or tune a text editor, look for tools, and so on.

This was true in the past, but with languages on the JVM and the CLR, we are in a golden age. As proof, consider the 3 examples above: all of those languages are a simple drop of a jar file and allow the use of the Java libraries. They run on the JVM. (Ted Neward has given entire keynotes on this idea.)

I will grant that the debugging/IDE facilities won't match Java, but this argument is completely bogus.

Problem #5: Confusing Momentum with Inertia

Again, this isn't a fallacy per se, but I take issue with this:

There’s another pernicious effect to language hopping: it hurts your momentum. Every time you rely on your current languages you get a little better.

Last year, I blogged about using Groovy to interrogate an OODB. My team still uses that tool. Anyone on the team could have written it in Java, but in the span of 5 years, no one had done so.

That's not momentum. That, my friends, is inertia. My little Groovy program is one of the biggest contributions I've made to that team: people ask me for it all the time.

The Upshot

Gustavo ends by recommending that we learn languages that are orthogonal to each other. I agree completely. And, for the record, I agree that merely dabbling is dangerous: I have probably been guilty of it myself.

But I heartily recommend learning a new language. And learning as much as you can about logical fallacies. They are everywhere (in this post?).

Monday, May 5, 2008

Satire Development Kit: Democrats Use Groovy To Pick Candidate

This is our first SDK: a Satire Development Kit that allows you, dear reader, to create your own satire, tailored to your own taste.

In this case: political taste. And we'll will learn a bit of Groovy along the way.


The SDK is based on these steps:

  • No matter where you may lie on the political spectrum, you may agree that the process to pick the next Democratic presidential candidate (in the USA) is complex. It involves a mix of delegates and super-delegates.
  • Groovy is apolitical, but uses delegates to resolve references in closures. Since delegates may be objects, they may be derived from other objects, which we'll dub super-delegates.
  • Punchline: this is up to you. We just provide the tools.

Minimalist Example

class Foo {
def bar() { println "hello" }

def c = { bar(); }
c.delegate = new Foo() // delegate is a keyword

def candidates = [ "Clinton", "Obama" ]
candidates.each( c )

In the above example:
  • candidates is an array that has a closure, c, applied to each element
  • the closure calls bar()
  • Groovy will search for bar(), first in the owning scope of c (the script itself), and then, if necessary, in c's delegate
  • Groovy will not find bar() in the owning scope, but does find it in the delegate, which we assigned as a Foo

Full Example

Below, we have a full example where a self-named Delegate object acts as the, well, delegate and derives from the SuperDelegate, which can pledge (or not?) for a candidate.

class SuperDelegate {
def clintonPunchline = "TODO: fill in"
def obamaPunchline = "TODO: fill in"

def pledge(def candidate) {
if( candidate == "Clinton" ) {
println clintonPunchline
} else if ( candidate == "Obama" ) {
println obamaPunchline

class Delegate extends SuperDelegate {
// defer to base class

def convention = { it -> pledge(it); }
convention.delegate = new Delegate()

def candidates = [ "Clinton", "Obama" ]
candidates.each( convention )

The Upshot

Simply fill in the punchlines in the above Groovy script, and you're all set to lampoon (or support) one of the Democratic nominees -- or both -- via a dynamic language on the JVM. The direction of your satire is up to you. Impress friends and family no matter if you are a Democrat, Republican, independent, or international observer.