Monday, June 25, 2007

Using Tricky Assertions

I'm not sure why, but I never got much in the habit of using the java assert keyword. Its a nice idea, but I somehow just checked what I wanted the old fashioned way.

And, although I'm a big fan of IDEs and I love debuggers, I still find having some print statements here and there sometimes is really helpful.

Of course, print statements suck when you're done and you no longer want them. That is, you need to go delete (or comment them out) all over the place.

I've sort of combined these ideas into a pretty obvious trick (which I seem to get asked about a fair bit, hence this post). Its basically a comment-out-less, performance-free debugging (or stats, or logging, or whatever) facility.

Simply:

assert(Debug.out("test code val="+val));
or
assert(Stat.increaseHitCount());

The only trick is that the method (like "Debug.out") must always return true. Now run the app with assertions turned on "java -ea Main" and you get the messages. For production, simply don't run with -ea and the VM will ignore those statements (I hope) altogether.

This basically gives you an application-wide, command-line way to turn on or off (with no performance hit if the VM is smart) some code. If you think about, there's many possible uses for such a thing.

Edit: Code for Debug.out would look something like:

class Debug {
 public static boolean out(String x) {
  System.out.println(x);
  return true;
 }
}

Sunday, June 24, 2007

Been Reading Crappy (Half)Books

I don't read a lot of books. At least under the definition of, you open it, flip pages over several days or weeks, get to the last one, read the last sentence, say "huh", and put it down. I mean, I don't finish a lot of books, at least nowhere near the number I start.

I *do* read a lot of half books - that is I only get half-way through. I have a feeling I'm rather hard on books - I expect a lot.

The problem I see is that there is simply an absolute deluge of books that should be articles. Simply said, books are about ideas. However (fixing the english of that last sentence), every book should be about multiple ideas.

So so so so many (half)books I read are only about one idea. They have a wispy chapter 1 introduction, chapter 2 introduces the idea (which sometimes is so simple it takes a paragraph), and then the rest of the book cites contrived/researched/induced examples about how that idea is so great.

That's fine and all. Some of those ideas are pretty luminary (i.e. Freakonomics comes to mind) but one single idea has to be pretty damn big to make a book. (Meta-note: the idea that books should be about multiple ideas and not just one idea is probably not a big enough idea to be a book, just an article, or maybe even a stinky little blog post).

I read a lot of technical books (not halves usually) and technical books are pretty hard to be stuck on one idea. Brian Goetz' Java Concurrency in Practice is a great example. If you're a Java techie, this is an incredible page turner. (Another amazingly great techie book is Warren's Hacker's Delight .)

I also read a lot of (half)books about business. I just read a (half)book called Selling Blue Elephants. The basic idea was to do market research using actual customer testing. Cool. Good idea. They even gave a spiffy acronym to try to add it to the world's business vocabulary (much like "tipping point" and "long tail" have done in the past few years).

But that was about it. The rest was case studies on how customer testing helped a bunch of products. Yip.

I also have been listening to Good to Great lately, a pretty heavily lauded book. I don't usually do books on CD but it was a gift. There was a lot of solid empirical research in it which was helpful but it seemed (much like Built to Last) to be fraught by survivorship bias. And I don't discount the strong research, but the results were somewhat expected (that's no ones fault, its just that everyone loves a plot twist).

The entire section devoted to how people in "great" companies tend to be stay friends is what really ended up ejecting the CD however. It almost seemd to imply was almost that if you were only in a "good" company, you'll never make any friends.

My expectations are probably too high. Business vs. technology is largely analogous to art vs. science - and its damn hard to write about art (as compared to science). Its just too subjective.

Becoming a great businessperson is analogous to becoming a great techie. It simply takes some level of innate talent that can't be replaced by hard work (and after you have that, then you still need a lot of hard work). After that however, the tech stuff is arguably easier to document.

Now I definitely might be too hard on books but how I figure it, I only get so many days on this planet (and this planet is the only one I know with books). I really can't afford to waste time on any book I find anything less than insanely great (Influence by Cialdini).
Ah well, onto the next - maybe I'll read some Call of Cthulhu. Or even better, "How to run a business like Cthulu would" - I bet there'd be more than one idea in there.