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;
 }
}

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.

Doing Wheelies

In a vain effort to remedy the situation where my friends are starting to call me names like boring, settled, and overall rather linear; I attended a wheelie class this weekend. If that sounds odd, well it is. I don't think there are that many such schools in existence.

It was a one day, 8-hour class and let me tell you, by the end of the day I could have not been more tired.



The instructors definitely knew what they were doing. The bikes were outfitted with a dual-stage limiter. It had settings 1-5 each at a progressively higher angle. Once the limiter was hit, the center cylinder (of the 3 cylinder speed triple) was turned off. So you rose up, hit the limiter, and then the engine lost 1/3rd power usually sending you back down.

After that at level "6" another limiter engaged that hit the back brake. The bar you see on the back (btw, that pic is of Simon my classmate as it was sort of hard getting a pic of myself whilst wheelie-ing and all) is not a hard stop bar, its merely there to engage both limiters.

I flipped a dirtbike a few years back screwing around which always instilled a good deal of respect in me for wheelies. Now the limiter was there to not let me do it again. By the end of the day I was at level 5 with pretty consistent wheelies. I really did go from nothing to finding the balance point in one very tiring day (I can't believe how sore I am today).

If you think this all sounds dangerous, well it can be. While I was standing by the side of the run, one of the students came out of a wheelie and in the process of trying to stop, locked the front brake and washed the front tire. He and the bike hit the ground doing about 50mph. The bike went skidding on its side right off the cement into a field like a hockey puck. The rider tumbled awhile and came to rest with (luckily) just a broken wrist (we were all wearing head-to-toe leather armor plus helmet).

That was an unfortunate cap to the day. Although I do get to add wheelies to my ever-increasing list of possibly interesting but mostly useless skills. :)

Sprint Customer Support

I've had my share of bad customer support experiences, but this one is special. :)

A few months back I logged onto sprint.com to turn off receiving text messages on my phone. I was simply getting too many spam texts. Not being able to receive friendly texts however eventually turned into a problem. At times, friends would text me and rely on the fact that I received it. Sprint doesn't notify the sender the message isn't delivered. This caused a few annoying instances.

Anyway, I decided I needed to turn texting back on and simply accept the spam (seems like spam would be relatively easy to stop on an SMS network, but then again phone companies also make money on that spam, so maybe they're not all that motivated to do so. Who knows - regardless, I was getting a fair bit).

I went to the website again (now a few months later) and tried to login so I could turn texting back on. Well, as I'm wont to do with websites I dont login to for months at a time, I forgot my password. I cheerfully clicked the "forgot your password?" link which asked for my phone number.

Ok.. I entered my phone number which then gave me a message - "We have sent you your password via text message!".

Um. Hey smarty-head - your database has a bit that says my text messages are turned off. Maybe you could, ya know, CHECK THAT BIT before you go off and send me my password via text message so that I could login with the sole purpose of turning my text messaging back on. (Hey btw... I have a new advertising campaign for you: "Don't have any access to a phone whatsoever but want one? Call us!")

So.... off we goto customer support. I dial their customer support number and funny enough the first thing the automated system does is to ask me is to enter my phone number.

Um. Dear Sprint - this is YOUR phone service. Maybe you should spring for caller ID for yourself and then check the incoming number against your database (you have this database thingie turned on right? Its the big pretty box that says "Oracle" on it) and then ask that given I'm on a Sprint number, maybe thats the number I'm calling about. You never know - it just might work.

From here I deftly navigate their convoluted automated phone tree (which consisted of just pressing 0 a LOT) and sat on hold for about 20 minutes.

Finally, I get a customer support person. She greets me... and then.. with what I perceived as a tint of "this is gonna be good" in her voice, she asks:

"What's your phone number?"

WTF. So.. you're Sprint. Its your line. You'd think you'd have caller ID. If not, You just made me enter my phone number 20 minutes ago (prior to hold) and the first thing the real live person does is ask me again?

If this system was designed to frustrate customers away from using it, its pure user interface art.