Don't Make Me Think: A Common Sense Approach to the Desktop

I haven't read this book, but I often use the brilliant title during code reviews and when talking about software. It's a fine variant on the KISS principle.

Lately though, I've come to implement the gist of the idea when it comes to refactoring. Particularly with respect to colour.

Background

It is well-known (especially since Blink) that when we are in 'the zone', we aren't thinking: sure, we may form strategy but really we are reacting.... flowing. I think it's important, on our desktops, to recognize the cognitive speed bumps that disrupt that flow.

Lately, I've been working on a major refactoring of a large project. Here are some basics:

• We're using a task branch in the source-control tool. Often we have 2 IDE instances running: one for the main branch (pre-refactor), and one for the task branch (the new work).
• We often run servers, alternately, for both projects on the Desktop.
  

The IDE

We are using Eclipse 3.2. Some of my teammates have changed the configuration files so that the window title will read "Task Branch" or "Main Branch" as appropriate.

That's fine, but that still seems like a speed bump to me. When I am frenetically switching from one IDE instance to the other, studying code, I don't want to look all the way up to the top left corner. I don't like mouse dragging and when I'm cookin', I don't like eye dragging.

This is hardly rocket science, but I use different highlight colours in the instances.

Check out this example of an Employee class in a fictional main branch. I use orange as a subliminal warning (i.e. don't change this one).



For the task branch/refactoring, I like green:



Before long, these colours become effortless and subliminal. No eye-dragging! It's like a mini Heads-Up Display.

Btw, discovering how setting this in Eclipse 3.2 is not trivial. Here's how:

Windows -> Preferences -> General + Editors + Text Editors + Annotations, and select Occurrences.

Server Windows

Again, no rocket science here: it is trivially easy to change the background/foreground of windows in your operating system.

But do it for your JBoss/Tomcat/Console windows. Make version 1.6 white-on-blue... Make version 2.0 yellow-on-burgundy. Or choose the team colours of your team or alma-mater.

I often use command shells for a given branch, and it freaks me out when I temporarily 'cd' from version X to version Y in the wrong colour. The ambient information becomes another tool in your arsenal.

The Upshot

Colour your world! It's an easy and effective way to keep things straight.

I'm interested in any tricks that you use in this regard.

ps. This doesn't involve colours per se, but my true love for reducing speed bumps is the use of Bash aliases on the command line. If you type more than 2 characters to 'cd' to your project's home directory, then you may want to check out this older post.

Scala Chip: Coffee Giants Unveil Boutique Ice Cream

CtJ Newswire
Satire City
Feb 29, 2008


Today, giants in the coffee industry announced a new, upscale ice cream: Scala Chip.

The news surprised insiders in both the coffee industry and software development alike.

In a press statement, researchers claim the move reflects technology gains with the upstart Scala.

An excerpt: "We admire Java and are grateful for that relationship, yet we look ahead to Scala with a palpable sense of excitement. There are many advantages of moving to Scala Chip:

• First and foremost, its purity is delightful to the refined palate. In legacy formulations, there were often primitive impurities such as int and long: not so with Scala -- everything is a chip.
  
• From a marketing standpoint, Scala Chip plays a functional role in luring back sophisticated consumers who pine for an elite dessert experience. Previously, we couldn't infer the type of consumer demographic; this inference is easy with Scala Chip. And the types are static: we want that loyalty.
  
• Research proves that Scala Chip closes over free variables of creams and sugars. This, and other traits, not only taste great but offer intriguing mix-in advantages with a wide variety of flavours, e.g. Curry Chip.
  
• Finally, from a pure business perspective, Scala Chip offers big wins in terms of production: due to its nature, we see highly concurrent processes and yet we can leverage our Java recipe libraries. We are continually monitoring the state of our quality control, but we're told there isn't really state with Scala Chip -- that's a big win. "

Critics Quick to Retort

The word spread quickly, sparking outrage throughout a variety of camps.

Naturally, the Java Ice Cream Producers Union fired the first salvo. "It's an outrage to suggest that Java Ice Cream isn't sophisticated! Popularity doesn't mean we produce a blue-collar product!", wrote one. Another: "The firm claims to reuse the production lines but where is the tooling, I say!? Show me the tooling!". Academics shouted in a chorus: "Java will soon close over free cream-and-sugar variables -- it does now somewhat, as long as the choices remain final."

Cultural watch-dogs joined the fray. Music critics wondered aloud, with horror, at the potential monoculture of a successful Scala Chip ice cream. "What next? ", wrote one critic, " Will cafes play only spoken-word CDs by Martin Odersky?"

Perhaps most ominously, a Thespian Guild is threatening legal action, based on rumours that the industry will rename concurrent-shift line workers as "Actors".

Coming Soon: No Fluff Just Stuff 2008

Background/Disclaimer: I have attended 6 NFJS's and received some nice schwag (a bomber jacket). The first 4 years, I worked with a previous employer. Since then, I've been employed by an affiliate of a sponsor. My views are my solely mine (but you knew that).


The last few weekends have been rather busy with (indoor) triathlons, and I'm happy to note that the next weekend will be busy as well: I'm attending the big show at the NFJS Gateway Software Symposium.

I look forward to NFJS like a major rock concert. Actually, there are many similarities:

• Many fans have a "concert number". e.g. "Dude, I've seen Dave Matthews 12 times". My NFJS number will soon be 7. I believe that's all of the St Louis events.
• There will never be a recording medium that can compare to live music: partly because of acoustics and partly because of the energy of a congregation. Same thing for tech talks. I love the feeling of being with geeks.
  
• As is well-documented, NFJS tours all over, with a motley crew of talented speakers. I heard that they once trashed a conference venue because they found brown M&M's in a bowl near a projector (not really).

So I'm looking forward to the mayhem this time around... It will be fun to see the likes of Ted Neward and Scott Davis again, along with great local speakers (and friends): e.g. Alex Miller, Jeff Brown, and Mark Volkmann. (Jeff and Mark are fellow OCIers, a sponsor).

Let me know if you are attending, and especially if you want a CodeToJoy sticker! codetojoy @t gmail

Examining Chaos with Hibernate

Alex Miller recently wrote a good introduction to CyclicBarriers. Here's one usage that wouldn't go into production, but can be illuminating.

Background

The Hibernate book has 2 large sections: one on structure; the other, on behaviour. It is easy to come up with a good, isolated example for explorations of mapping structure (e.g. collections). It's not as easy to isolate behaviour with respect to isolation levels and concurrency (e.g. simultaneous inserts to the DB).

However, with the threading tools, it is definitely possible (and fun) to create some homegrown chaos in isolation. Consider this scenario:

• Several threads each open a transaction against the database
• Each thread creates a new object with a common value in a field designated as unique in the DB
• Each thread then attempts to commit its record into the DB: chaos!
  

One might try writing a small multi-threaded example that might cause the collision, and then run it repeatedly, analyzing the log to see what happened.

CyclicBarrier

However, with the CyclicBarrier, we can precisely hold up the threads until the Moment of Maximum Pathogenesis. In this case, after the creation but before the commit.

It is easy to use Alex's driver program to execute several of worker threads. The gist is as follows:

• Initialize Hibernate's SessionFactory
• Create a ThreadPoolExecutor
• Create a CyclicBarrier of size N
• Create N workers (see below): each one receives a handle to the
  SessionFactory and CyclicBarrier
• Pass the workers into the executor

The example uses a simple Owner POJO (from a car example). In the DB, the Owner table simply has a surrogate key and a my_name field which has a unique constraint.

The individual worker looks like this:

class MyTask implements Runnable {

private int taskId;
private CyclicBarrier barrier;
private SessionFactory sessionFactory;

// omitting ctor and emit() method
// for brevity

public void run() {
 try {
    emit("waiting to start");

    // begin Txn
    Session session = sessionFactory.openSession();
    Transaction tx = session.beginTransaction();
  
    // create new persistent object 
    Owner owner = new Owner();
    owner.setName("CodeToJoy");
    session.saveOrUpdate(owner);

    // barrier: wait for all threads
    emit("waiting...");
    barrier.await();

    // unleash the hounds!

    tx.commit();
    session.close();

    emit("done");
 } catch(Exception ex) {
    emit("caught : " + ex.toString() );
 }
}

}

Here is example output (cleaned-up considerably):

starting....
task 1 : waiting to start
task 2 : waiting to start
task 3 : waiting to start
task 4 : waiting to start
task 5 : waiting to start
task 4 : waiting...
task 3 : waiting...
task 5 : waiting...
task 1 : waiting...
task 2 : waiting...
barrier reached  (NOTE: from a println the CyclicBarrier itself)
(NOTE: thread ids may not match primary key)
task 5 : done
task 1 : insert into Owner (my_name, id)
      values (CodeToJoy, 1) was aborted.
task 3 : insert into Owner (my_name, id)
      values (CodeToJoy, 5) was aborted.
task 4 : insert into Owner (my_name, id)
      values (CodeToJoy, 4) was aborted.
task 2 : insert into Owner (my_name, id)
      values (CodeToJoy, 2) was aborted.

(NOTE: list all records in the DB. Task 5 won and received id = 3)
owner id   = 3
ownername = CodeToJoy

The Upshot

In this way, the threading utilities can be used to come up with many weird and wonderful situations. Implementing these ideas can illuminate the concepts in the Hibernate book (and in the Java concurrency libraries).

King of Kong (a documentary film)

Whether it's an earnest post, or satire, CtJ aims to bring excellence on technical topics and the art of software composition.

Every so often, though, there is a bolt of geek lightning in the entertainment world that merits attention.

Check out the documentary King of Kong: A Fistful of Quarters (a review is also here at DDJ). It is an excellent documentary in its own right, but especially if you ever played the classic arcade games like Donkey Kong, Pacman, Defender, etc.

In essence, it's a look into the world of 'competitive gaming', where an incredible amount of thought and time goes into defeating an arcade game (Donkey Kong). At first, the viewer is bemused at the interesting characters but soon gets sucked into the dramatic chess-match between an upstart and a defending champion.

Highly recommended.

Bjarne's Last Laugh

I haven't done C++ in a long time but I recently thought of something Bjarne Stroustrup said at a keynote address in 2000. It is essentially the same as this quote from his FAQ.

Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation- dependent extensions or libraries.

-- Bjarne Stroustrup, circa 2000

The part about implementation-dependency was wrong, but the complexity prediction was well-put. I'm a Java fan (and am not put off by the complexity), but credit is due when credit is due.

The Busy Developer's Guide to Steve Yegge: The N00b Post

With apologies to Ted Neward, here is my recap of Steve Yegge's N00b post:

Clarity and brevity are often opposing forces, but there is a sweet-spot where they combine to form beauty.

We spend our entire careers chasing that sweet-spot. It moves.

My Ultimate Interview Question (or How Would You Resolve Mount Fuji?)

Jon Galloway has an interesting post on phone-screen interview questions, criticizing a list by Steve Yegge. Essentially, Galloway says it's a fallacy to assume 2 people are colleagues within the same context or technology.

Jon came this close to describing a favourite interview question of mine.

As background, at a previous gig, I was a tech lead at a small ISV in the midwest. I've probably interviewed about 20 people. No, not a large number, and it was not at the level of Google or Microsoft. No moving Mount Fuji problems here. (However, I do have some experience in talking to strangers. A 'street psychologist', as it were.)

My interview involves the usual: background, real code samples, tell me what you read, etc. Then, I have this little doozie at the end:

Describe a situation of conflict at one of your previous gigs, and explain how it was resolved.

I usually ask for "conflict on technical issues", but I'll take anything. I reassure the interviewee that it is an open question without a correct answer (and that I don't need names!).

Let me tell you, it has been fascinating. It is great way to assess communication, to determine what kind of run-ins the person has had, and to hear some real-world stories that, often, give a view to the person behind the interview facade.

Often, I will explicitly give the candidate a chance to describe a situation that they merely observed (yet were not part of), and they will still go ahead and open up about some particular incident, often revealing their personality (for better or worse). Sometimes, they become passionate for the first time in the interview.

The bottomline: I don't care if you can move Mount Fuji, or survive in a blender, if you can't work on a team. This question is the best way I've come across for trying to figure that out.

ps. There is a runner-up question to the Ultimate, but that is another post.

pps. Share your favourite episodes in the comments... That could be a fun thread.