Pulp Nonfiction: Defending the Transient Book

First, there was this attack on books: they are too long and have high-falutin' ideas versus the immediate gratification of raw code. After 2 days, I still cannot tell if it is a satirical piece.

Then, Jeff Atwood defends the timeless classics (e.g. Pragmatic Programmer) which stay on his bookshelf for 5+ years. Fine. This is the blog equivalent of shooting fish in a barrel.

I, too, enjoy the classic books and use online resources (such as these, by my colleagues) all the time.

However, someone has to stick up for some friends of mine: the excellent programming books that are highly relevant to me right now, but yet are not timeless. These books, call 'em Pulp Nonfiction, may well not be as useful in 5+ years. They aren't cheap, and I will probably clear them out for new editions. *sigh* What a pain! What an expense!

And yet you will have to pry them from my cold, dead hands.

I'm not talking about Dummies books, or "How to Learn X in N Days". I'm talking about books like Thinking in Java, Java Persistence with Hibernate, and Java Concurrency in Practice. And other books that may or may not be useful in 5+ years like the delightful duo of Groovy Recipes and Programming Groovy.

Here are some defenses for these wonderful works of Pulp Nonfiction. The following is brief because I fear that those "who be needin' it won't be readin' it".

The Forest and the Trees

A good book will offer up not only the tree-oriented detail that you need right now, but will give you a view of the forest. Consider concurrency in Java 5: there is no way that you can pick up the overall themes and issues from online docs. By understanding the forest, you'll always have a sense of context for the particular trees that you are dealing with.

Often, when confronted with a climbing a particular tree (i.e. solving a problem at hand), you'll know that it isn't about the answer, but a rephrasing of the question. That is, the real answer involves another tree entirely.

Timeless Tranquility

Sure, it takes time to read books, but the payoff is that the author has the chance to expand on ideas. For centuries, a book has been a thoughtful discussion in an intimate setting. Imagine having a dinner series with Gavin King!

It's a good example: the Hibernate online docs are terrific, but the book is better. The writing is more thoughtful and the background and issues are explained very well.

Getting Things Done

The book remains the ultimate mobile device. Yes, they are hard to search. Yes, they are a proprietary format and have limited storage (i.e. 1 book). But y'all can keep your Kindles and iPhones. When I am waiting for my car to be serviced, I'll take Effective Java, thanks. (Possibly the best example of Pulp Nonfiction, with a new release due).

The Great Conversation

When loaded up with the ideas and vocabulary of the times, you can engage in the discussions. And from these spirited conversations, we learn new ideas and views.

This isn't about elitism or impressing those at the local user group: it's about participation. And fine-tuning your B.S. detector so that you can protect your project, and minimize your time spend talking to posers.

(Note: it is true that the online stuff is vital on this point.)

The World is Flat

Imagine that you are at an interview for a new position. You need to read the Pulp Nonfiction because your competition already has done so. Give 'em hell.

Better Reader, Better Writer

Perhaps best of all, the more one reads, the better one can write. And that goes for prose, code, you name it. Don't scoff at this one: effective email communication is extremely important to your career.

The Upshot

Sure, use online resources. Absolutely, read the timeless classics.

But don't discount the transient books.

Discount most of them, but find the best, because they'll change the way you think. That's profound stuff. And if that comes for $40 and with a 3-year shelf-life, so be it. That's a steal.

iSurrender: a new chapter with a Macbook Pro

As posted in the past, I have been seeking refuge from Windows Vista and have been drawn to the autonomous collective known as the Mac community.

Tonight, I have joined them. This is my inaugural post from CtJ HQ on a spiffy new Macbook Pro.  (17 inch, matte display)

So far, so good... The out-of-box experience has actually matched the substantial coin I just put down. Up and running in a few minutes...

To my Mac friends at OCI and throughout St Louis: you are on notice! As Ted Neward once posted, you got me into this and I expect substantial helpdesk support ;-)

M.E.

ps. I haven't had the fun of exploring a new machine and OS in a long time. Like Linux, only more so, this machine takes me back to the true Wonder Years of my youth, when computing was truly fascinating and possibilities seemed endless.

The Golden Rule of Testing and JUnit Assumptions

The Golden Rule of Testing:

• There are two times when all the unit and integration tests must run and pass: immediately prior to a check-in and on the build server.

Great. But what about the time when the developer is actively working on a task? That zone of "dev time" is a gray area.

I think most developers run the particular unit test for the class of interest. Lately, I have been running integration tests with the wonderful dbUnit.

In this case, each test is working with Hibernate transactions. It is very important that each test perform its setup and teardown properly, as one error can impact other tests, and this is tricky to debug. Consequently, during dev time, I want to run all of the tests fairly often.

Well, all of them except one called Test Q. Test Q takes 90+ seconds. It has become my nemesis, my rival. I see it running when I close my eyes at night. It haunts me.

Options

There are plenty of options for dealing with Test Q. We could break it up into different tests. We could write a test suite. And so on.

However, with an article and a JUG presentation, Charles Sharp has opened my eyes to the possibilities in JUnit 4.x.

Assumptions

JUnit 4 (and other modern testing frameworks) have a concept of theories and assumptions. These ideas are interesting, but outside of the scope of this post. Check out this article for more.

For my needs, suffice it to say that an assumption is used to declare assumptions about the data coming into a unit test. If the assumption is not true, then the test automatically passes.

Here's an example:

import org.junit.*;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assume.*;

public class AssumeTest {
    @Test
    public void testA(){
        int x = 1;
        assumeThat( x, is(7) );
        System.out.println("assumption is true!");
    }
}

The assumeThat statement assumes that x is 7. If not (as in this silly example), the test will quietly pass. This may seem horrifying, but it makes sense within the realm of theories.

It also blows the door open in terms of dev time. There are two advantages: (a) the test passes and (b) x is a runtime variable. Compare this to another approach with a timeout variable.

public class AssumeTest {
    @Test(timeout = 5000)
    public void testALongRunningTest() {
    }
}

In the above example, the test will timeout after 5 seconds. However, the test will fail and the timeout value must be a constant. During dev time, I don't want Test Q to fail; during the Golden Rule, I don't want it to timeout. Effectively, I want to skip it on my terms.

Configuration via Assumptions

I don't know yet if what follows is merely a parlour trick. I have not yet used it in production, but one can do some pretty cool things with these assumptions, outside of the theory arena. We can make assumptions about the state of the JVM in order to determine if we are in "dev time".

For example, we can do the following:

• Configure a test so that it can be disabled via a JDK parameter (take that Test Q!).
• Configure tests so that only a given percentage of them will run at a given time.

Both can be done with assumptions. And in both cases, the Golden Rule is not violated.

Here is an example of the first configuration:

import org.junit.*;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assume.*;
import static java.lang.System.*;

// class under 'test'. I work in biology
class Bacteria {}

public class BacteriaTest {

    @Before
    public void setUp() {
        out.println("hello from setup");
    }

    @After
    public void tearDown() {
        out.println("hello from teardown");
    }

    @Test()
    public void veryLongTestA() throws Exception {
        // if DEV is defined, then skip and auto-pass
        assumeThat( System.getProperty("DEV"), nullValue() );

        out.println("running long test A");
        Thread.sleep(90 * 1000);
    }

    @Test
    public void reasonableTest() {
        out.println("reasonable test");
    }
}

To run this example (with JUnit 4.4+ on the classpath):

apt BacteriaTest.java
java org.junit.runner.JUnitCore BacteriaTest
OR
java -DDEV=true org.junit.runner.JUnitCore BacteriaTest

The idea is simple: when the Golden Rule applies, no JDK params are provided and everything runs. But the dreaded test can be skipped when needed.

Admittedly, it does require code within the test, but I'm not sure that it is intrusive.

This is especially true in the next example, which combines both ideas: the one mentioned above but also another. This second idea is: during dev time, can we run some of the tests? The thought is that we don't want to run them all but don't want to run only one either. Think of it as a testing heuristic of sorts. The example below is neat in that the choice of tests is random.

Here's the code:

import org.junit.*;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assume.*;

import java.math.*;
import static java.lang.System.*;

// class under 'test'. I work in biology
class Bacteria {}

abstract class BaseTest {
    // if DEV is defined, auto-pass test (i.e. skip)
    public void binarySwitch() {
        assumeThat( System.getProperty("DEV"), nullValue() ); 
    }

    // if random value < THRESHOLD, auto-pass test (i.e. skip)
    public void probabilitySwitch() {
        int threshold = 101;
        String thresholdStr =  System.getProperty("THRESHOLD");

        if( thresholdStr != null ) {
            threshold = Integer.parseInt( thresholdStr );
        }

        int value = (int) Math.floor( Math.random() * 100 );
        boolean doRun = ( value < threshold );
        assumeThat( doRun, is(true) );
    }
}

public class BacteriaTest extends BaseTest {

    @Before
    public void setUp() {
        out.println("hello from setup");
    }

    @After
    public void tearDown() {
        out.println("hello from teardown");
    }

    @Test()
    public void veryLongTestA() throws Exception {
        binarySwitch();

        out.println("running long test A");
        Thread.sleep(90 * 1000);
    }

    @Test
    public void reasonableTest() {
        probabilitySwitch();

        out.println("reasonable test");
    }
}

Again, to run this example (with JUnit 4.4+ on the classpath):

apt BacteriaTest.java

// Golden Rule
java org.junit.runner.JUnitCore BacteriaTest

// or Dev Time
java -DDEV=true -DTHRESHOLD=25 \
org.junit.runner.JUnitCore BacteriaTest

In this case, we've refactored the first idea into the binarySwitch() method and introduced the probability heuristic into the probabilitySwitch() method. The reasonableTest() might run and it might not. This is silly in the small example, but consider it over a large test base.

Again, this doesn't violate the Golden Rule because the assumptions will be true. But it may have potential for development time, when they can be falsified. Because JUnit 4.x completely supports the 3.x format of tests, I might try swapping out the jars at my day gig.

Test Q, you are going down!

Homework: visit your old CS department

First, some interesting news: in Fall 2008, the University of Waterloo will teach first-year comp sci courses with Scheme (and some C and Python).

UW isn't the first school to do so, but gives a shot in the arm to the growing ranks of schools that are moving away from teaching OO languages in the first year. Professor Prabhakar Ragde notes in the comments that this will impact 400 CS majors a year, plus about 700 non-CS Math majors.

I didn't do my undergrad at UW, but I was there for an intense, wonderful 2 years in the graduate program. When I saw the familiar name of Professor Ragde, I started poking around the website for old times' sake. (Sadly, I didn't take any classes with Ragde. He has a great reputation.)

Wow. Memories came flooding back, and I discovered that many professors have their own blogs. The little surfing expedition consumed hours.

Here's your homework assignment:

Visit your old school today! There's a chance that some of your favourite professors are still there and have blogs.

It's like Googling for Ex's Lite: all the nostalgia, without that "creepy feeling" aftertaste.

The WIDE: Web-enabled IDE ?

Weiqi recently posted some sample C code as the Friday Quiz.

It has been a long time since I have done C: it isn't installed here at CtJ HQ. Being lazy, I wondered if there was a way to do it over the web.

There is. Ryan Ginstrom referred readers to the Codepad site by Steven Hazel. Very cool.

I don't think Codepad is going to overtake Eclipse anytime soon as an IDE, but I have long wondered if the Web would come to play a larger part of software development than merely being a reference. Call it the WIDE. Here, we have a "syntax scratchpad". In itself, the utility is debatable, but it is also a scratchpad for, say regular expressions, if you are familiar with Perl/Python/etc.

I have some of my own ideas in this regard, but alas I have been lazy and somewhat stymied by my Internet host on a side-project. (This site is hosted on Blogger and not said host.)

Discussion

For now, a question: will the web become so integral to software development that the IDEs actually include a browser as a view?

After all, we generally have Firefox open all the time, and with neatness like Codepad, I think that trend will only continue.

ps. Stephen kindly invites us to try to break his website ;-) Unleash the hounds!

Code to Joy: a User's Guide

The recent jJava post was written intentionally for April Fools, but wasn't really intended to fool people per se. There are several parodies on here, and jJava may well re-appear.

I've come to realize that first-timers (and possibly loyal readers) may not understand where some posts are coming from. This post is an aside from the usual work, and is a reference: a user's guide, of sorts.

Inspiration

A major influence on this blog is the comic strip Calvin and Hobbes. Though Dilbert is pure genius and The Far Side is wonderful, C&H is the best. The writing is exquisite and the ideas are often profound.

However, what I love most about C&H are the various themes: the snowmen, Spaceman Spiff, and especially the big Sunday, colour editions drawn as a different, adult comic (e.g. where Calvin is a T-Rex).

The point is: if you read a book of C&H, you never really know what might appear on the next page. But when you encounter a familiar theme, the experience is doubly wonderful.

Themes

This blog certainly does not compare to the brilliant C&H. Nor does it even have comics: that's Eric's bag.

The influence of C&H is that I hope repeat readers will have a similar experience: not knowing what will come next (serious vs satire), and recognizing familiar themes. (Weiqi Gao's Friday Quiz is a great example.)

That said, here are some emerging themes (beyond the usual geek stuff):

Newswire

Anything from the CtJ Newswire is going to be a parody: look closely at the city in the header. I'm not trying to fool you. Hopefully, even though the post isn't serious, it will still share some kind of insight.

Stickers

I get bored in bars and I get bored writing standard blog-fare: the sticker posts are pure rebellion -- and fun (especially on vacations). Almost all subjects are strangers.

True, most subjects are female (hey, I'm a single, straight guy in a bar), but I try my best to keep things equal. The intent is solely to combine geek stuff and nightlife. Photoshop is never used.

The CodeToJoy Nation

Any mention of HQ, "our hero", or general ego-centrism is simply to spice up the text.

The CodeToJoy Nation is an ongoing attempt to 'franchaise' readers of the blog and enhance the sense of community.

Outrage

I rarely blog in anger. This is a rant-free zone. I rant enough in real life and there is enough grousing on the Web, n'est-ce-pas?

Any 'outrage' is going to be mock outrage. Usually, it is a theatrical spoof of envy/vanity (a la Daffy Duck) that a friend (usually Eric, Weiqi, or Alex) is getting more hits on a given day.

For example, I'm still trying to figure out how Weiqi gets correspondents. What a scam!

The Upshot

HTH ! Thanks for visiting.

Oh, by the way: rediscover Calvin and Hobbes.

When we are only bounded by our imaginations, it's a Magical World.

Open-Source group announces jJava

CodeToJoy Newswire
April 2008
Satire Valley, CA

An open-source project surprised industry insiders today by announcing an implementation of the Java programming language on the JVM.

The language, dubbed jJava, reflects the current trend for using the JVM as a systems platform for various languages.

Wearing t-shirts featuring the jJava logo (a pair of Jacks), team members displayed the obligatory HelloWorld program to a group of interested developers:


Consequently, the team discussed some key advantages of the nascent language:

Flat Learning Curve

The jJava platform is an easy-entry point for busy Java programmers who simply don't have time to learn a new syntax. The team provided a comparative analysis with other languages on the JVM:


Leverage JVM libraries

As with other JVM tunnelers, the developer has access to the venerable Java libraries including IO, Reg Ex, collections, and concurrency.

Static Typing, Compilation

Though dynamic languages and type-inference are gaining mindshare, many developers prefer the tried-and-true comfort of a compiled language with static types. This plays to jJava's strengths.

Modern Features... Closures?

jJava contains annotations, generics, and state-of-the-art concurrency constructs. Closures are not yet supported in the language, but may be arriving soon, depending on the outcome of a spirited debate within the community of the parent, reference language.

Tooling

On this point, the team-spokesperson adopted a hushed tone, in order to underscore the passion and importance of their point: jJava enjoys a tremendous advantage in tooling. Because jJava is Java on the JVM, all modern IDEs, build tools, and code-coverage software will work with jJava.

Performance

When asked about performance, the team exchanged knowing glances and beamed. Insisting that the results were as-yet unofficial, the team crowed that improvements to the JVM in Java 6 may result in jJava being faster than Java.

Said one jJava developer, "We were really surprised by this. It is quite counter-intuitive, but the numbers look terrific."

Release Date

The team conceded that jJava is not yet available for public consumption, but is coming soon.

Off-the-record, a tech lead hinted that the team is hoping to complete a web framework, as a companion download to the language itself.