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.

Tempers Erupt at Conference: Multi-Line Strings in Java

CodeToJoy Newswire
Satire City, CA
Jan 30, 2008

At a recent Java conference, tempers flared and developers ultimately took to the streets in protest over a controversial feature proposed for Java 7.

Prior to the conference, the proposition of multi-line string literals seemed benign: the concept is not new, and is found in many languages. An example:

String thePoint = """
i still
love
java""";

Unfortunately, the issue exposed deep philosophical divisions within the Java community, and civic unrest ensued.

The School of Grafters

At the main presentation, one academic group pitched their proposal for multi-line string literals. Their thesis:

• "In another thirty years people will laugh at anyone who tries to invent a language without multi-line strings."
  
• This new feature will free programs of much of their accidental concatenationicity.
  
• Multi-line strings can be seamlessly woven/grafted into the language, without an extension to the existing Java type system.
  

Though the other speakers showed signs of dissent, the presentation went well until the final point:

• The implementation of multi-line strings could be a straight-forward application of Generics.

At this point, the crowd began to shift uneasily and talk amongst themselves. Several presenters from the panel began to openly question the proposal. Finally, after a moment of chaos, the moderator brought the segment to a close, and introduced the next speaker.

The Block Camp

From the outset, it was clear that this group was more conservative, and desired to block the proposition. The presenter made the following points:

• The usage of multi-line strings will encourage an exotic style of string concatenation, possibly fostering dialects and hindering string portability.
• A new feature should have a minimal addition to the lexical surface area: surely the + symbol has a higher power-to-weight ratio than """.

Again, the speaker was persuading the audience until the final point:

• James Gosling wrote, circa 1997, that Java is a "blue collar language" which modestly gets the job done. It's practical, not theoretical!
  

At this point, an audience member yelled, questioning a rumor that Gosling was a member of the School of Grafters. Another asked what Gosling thought of the issue in 2008 (versus 1997). Chaos threatened to erupt again, until security guards ominously appeared at the door of the auditorium.

The Junkies and Dead-ends

Finally, the last speaker on the panel walked to the podium. In a quiet voice, he confessed that he was a feature junkie and that he represented a group of developers who were irrationally drawn to new features such as multi-line strings. He described the inner turmoil of being a junkie: living with both feature lust and also the burden of backward compatibility. His only solace was to consider Java a dead-end with respect to new features.

It was a tender moment, until his conclusion:

What's the big deal anyway? Why not use multi-line strings in Scala, compile the code down to bytecode, and just use that?

At this point, the crowd erupted for the final time, streaming past the guards, and spilling into the streets. Soon, they carried placards and bull-horns, appealing for unity.

The mob protested for several hours until, finally, local police brought in staff from JetBrains to hand out free IntelliJ licenses.