A Random Walk Down NFJS Street

Here are a collection of thoughts (and useful references) from the recent NFJS Gateway Software Symposium.

See my other posts for my motivation, background, and disclaimers. In brief, I'm a 7-timer and enjoy these intense weekends.

Groovy and Grails

I didn't see many Groovy or Grails talks. I'm a fan of both, but I know Groovy and I've seen enough of Grails to know that I need some "flight time in the cockpit" more than another session.

But make no mistake: these topics were a big part of the conference. Many sessions in the 'G-space' and a lot of buzz among the audience and the speakers.

Did you know: the literature has caught up to Groovy's frenetic pace. For an introduction, see Programming Groovy by Venkat Subramaniam. For a how-to manual, check out Groovy Recipes by Scott Davis. Both guys are top-shelf, entertaining speakers on NFJS.

For Grails, how about this for a summer blockbuster: the 2nd edition of the Definitive Guide to Grails.

Transactions

I went to a good session on Transaction Design Strategies with Mark Richards. Essentially, he would assign an ownership role to a given tier (e.g. the client) and then the transactional responsibilities logically followed from that.

For example, if the client assumes the role of ownership, and the system uses declarative transactions, then one can annotate a service layer with MANDATORY. In fact, it is probably an error if the service layer is not designated as such, with this particular strategy.

Interesting stuff. During the session, I couldn't help but wonder if one could use a static-analysis tool to check the annotations by logical inference, for a given strategy. It would scan a section of the codebase, producing appropriate warnings for transaction declarations (based on the strategy indicated). Think of FindBugs -- for transaction boundaries. Is there such a thing?

Mark has a book available via free PDF at InfoQ.

YSlow

One bolt-of-lightning session was on YSlow by Scott Davis. The quote of the day, by Scott:

• YSlow doesn't tell you that your website sucks: it tells you why your website sucks.

In short: download Firebug. Then download YSlow. Point it to a URL and check out the advice. If you need more, check out this book or check out Scott's fantastic talk.

Afterwards, you will point YSlow, like a cosmic xRay gun, at every website you ever worked on. If you have moved on from the project, you will laugh -- nay, cackle -- at the ridiculous last-minute demands placed by the marketing department and the consequent slow-down.

Restlets

I caught a cool talk by Brian Sletten on the Restlet API. It's a framework/API from the RESTafarians. Really slick. Check out the Uniform class in the Javadoc. This is not only a brilliant pun (on the insistence of strict RESTies for a uniform interface) but a microcosm of the REST spirit. It inspired this thought:

• Programs on a Turing machine boil down to a handful of actions. In REST, protocols boil down: the opcodes for a given web service ends up as a grand orchestration of simple GETs, PUTs, DELETEs, etc. That Uniform class is REST distilled.
  

The Keynote

I mentioned the presentation by Scott Davis in an earlier post: How to Lie with Open Source. Very entertaining, thoughtful, and an object lesson on a good keynote, in terms of dynamic presentation and cadence.

In StL, we saw the premiere: watch for it coming to a city near you.

The Panel

It is impossible to re-capture the spirit of a NFJS panel. Irreverent and funny.

Some themes were: tremendous collaboration on the language front (even among Sun and Microsoft), concern for the fractious debate in Java 7, and some tired (IMO) showdowns between Eclipse and Idea.

I remember 2 books that were highly recommended: Flow and The Riddle. On my list.

Scala

Due to session conflicts and having seen some talks previously, I missed several favourite speakers and barely caught Ted Neward.

The Scala talk was a good fit: a chance to hear Ted and continue the Scala theme after an excellent JUG presentation by Tim Dalton.

I was mostly interested in Scala's concept of Actors (for concurrency), but some lights went on this time around. I didn't realize just how functional Scala is: I was always focused on its static type inference (versus Groovy and jRuby). This language will stretch you, especially if you're only familiar with Java and its ilk.

As Ted says, this is a "different breed of cat". For more info, check out his "Busy Java Developer's Guide" series.

Quick Notes

• I saw one talk on Groovy: a DSL session. It is amazing how un-Groovy like the DSLs can be now, with the high-powered dynamic mojo in Groovy 1.5.x. However, I think that ANTLR is tough to beat if the DSL is high-profile and used by non-developers.
  
• I saw a session on JMS. I suspect this is one of the most underrated pieces of Java EE. It is really strong stuff! Naturally, being a Groovite I wondered what the examples would look like in Groovy. Stay tuned. I swear, there is an entire cottage industry in taking Java examples and implementing them in Groovy.
• There were two sessions on Terracotta: an intro and one on caching with Hibernate. I had seen one and am planning on seeing the other at the St Louis JUG (see previous post). If you haven't seen it, come check it out. The wow factor is high.
  
• A session on OSGi opened my eyes to that space. There are no books or classes on it per se, but versioning is one timeless mofo of a problem for computer science. In brief, my take on OSGi is that it is as explicit and demanding as the classpath is implicit and subtle: but for versioning, that's what you want.
• The Birds of a Feather on Dynamic Languages was great fun... A lot of people were new to the game. In the BoF, but also in general, there was some anxiety over "which language should I learn, given finite resources?". That's a tough call. I am partial to Groovy, but as I write this, my answer is: it doesn't matter. It is more important to get in the game with one of them than to sit back and wait on the sidelines. Even if you pick "wrong" the experience can transfer, to some extent, over to any future languages. Just experiment and have fun!
  

The Upshot

Another winner: I'm still tired from the brain exercise and from being engaged for 2 1/2 days.

Stay tuned for some more thoughts from the show. I hope to work out some exercises of some the technology.

Upcoming Events in St Louis

Check out the StL JUG this month (3/13) : Terracotta by Alex Miller. This isn't an amateur presentation: Alex works for Terracotta, and gives a talk for No Fluff Just Stuff. If you haven't seen Terracotta, it will blow your mind.

Bonus: an iPod Shuffle is being given away!

(Ed's note: Alex originally wanted to raffle off Skip Lists but there were logistic difficulties. JK.)

Later in the month (3/27), there is an inaugural meeting for the St Louis Spring Users Group. I've never heard of a group dedicated to a framework (or more accurately, its philosophy) before. I'm going to try and check that out as well.

Programming in Sock Feet

At the NFJS/Gateway Software Symposium, one speaker gave two fantastic talks: in sock feet.

Love, love, love it. In a way, it embodied the experience: comfortable, yet productive.

It gave rise to these thoughts...

Public Speaking

As a senior in my undergrad, I took a terrific class in public speaking: the iconic Dale Carnegie class. Seriously, it changed my life.

One of the minor tips is to ditch the equipment: the watch, the cellphone, the wallet, etc. The goal is to be comfortable when "on stage" (plus it removes a tendency to fiddle nervously with stuff).

I absolutely ditch my footwear if I can get away with it. Hell, I'd speak in a bathrobe if I could.

Programming

I work in the same way: I currently work in a public war-room, unencumbered by any devices. I kick off my shoes all the time (your "code smell" joke has been anticipated: hopefully my grooming practices allow me to do this without offense).

Give it a shot today: stow your stuff. You don't need to be weighed down like Stormtrooper with all that equipment. (No, you don't really need to be constantly available via cell -- you weren't for the 1990s and got away with it.)

Free your body and your mind will follow.

Languages

A major theme from NFJS was the notion of Low Ceremony, as coined by Stu Halloway. The gist is that the dynamic languages, and "convention over configuration", remove the formal, baroque practices of the last few years.

For example, why go through the "high formality" of public getters/setters: Groovy gives them to you for free. Do we really need semi-colons as a statement separator? Must we declare the type of a variable all the time? Imagine introducing yourself, shaking hands with your family every morning: needless ceremony.

This is a stretch, but my metaphor for this revolution is "programming in sock feet". Much of Java, XML, and so on feels like formal shoes that don't fit right and are often too fancy for the occasion.

The Upshot

Slip those shoes off. Whether it's public speaking, or programming, there is nothing wrong with sock feet -- especially if it improves your performance.

Notes from NFJS: Day 1

Briefly, day 1 of NFJS St Louis was good. Great to see some old faces but I was surprised by the number of new faces in the crowd.

My favourite part of the conference is the inspiration: in each talk, I come out with some ideas for the blog, both serious and spoofs. Often, I also emerge with a hunger to study up on some topic.

Highlights of the day included:

• Another great keynote by Scott Davis (theme: applying the book "How to Lie With Statistics" to open source and IT)
  
• A good, solid "meat and potatoes" comp sci talk -- replete with the big-O notation! -- on Collections/Data structures by Alex. Java 5 and 6 have added some interesting new stuff to Collections. If you blithely type List list = new ArrayList(); without much thought, this is a must-see.
  
• An interesting session on open-source licensing. I wonder if they cover licenses in schools these days. They should. (Trivia: did you know that Bill Joy innovated the BSD License circa 1977? That guy was destined to be a major influence.)
  

The absolute highlight was during dinner: conference organizer Jay Zimmerman announced that a couple of Java geeks were celebrating their 15th wedding anniversary this very evening: at a Java conference!

It was a delightful moment. I'll offer to take their pic if I can find them again during the weekend.

Rhapsody in Blue: the Colour of BGGA Closures

Background

• Many people claim that the various Java closures proposals are difficult to read.
• Others claim that Java is a blue-collar language and should stay true to its roots circa 1997.
  
• The BGGA proposal refers to Tennent's Correspondence Principle which gives return (and other keywords) a different meaning than their use in anonymous inner classes.
• This article and many others represent the syntax in simple black text. Some claim that cut-and-pasting legacy code (anonymous inner classes) into new BGGA closures would introduce errors.
  

The Idea

• Java may or may not be a blue-collar language, but modern Java IDEs are certainly not blue-collar. They are very sophisticated.
  
• This post by Weiqi Gao is one of the few to show BGGA as we might eventually see them: in colour.
• Syntax highlighting make BGGA closures easier to read, and may mitigate the tension between Tennent's Correspondence Principle and anonymous inner classes.
• Read on for details and decide for yourself. Note that the use of colour is completely arbitrary. I don't know if it is possible (or timely) in an IDE (but it seems reasonable).

Note: Code examples use the latest BGGA prototype, explained in this post by Zdeněk Troníček. The use of "==>" versus "=>" is intentional.

An Example

Here is a contrived example, simply intended to illustrate the idea (this is not my submission for the Turing award).

Click on the screenshots for a better image.

This method uses a BGGA closure to build a list of Employees from a list of Strings within a transaction. With the latest version of the BGGA prototype, the ==> symbol means that the closure is unrestricted; that is, we can use keywords such as return, break, and continue (though this is not fully implemented yet).





Here is a trivially easy block with a driver method perform that shows usage. The => symbol denotes a restricted closure (explained at the end of this post).





The concept of the closure syntax is that it is a series of statements, ending in an expression (i.e. no semi-colon). The expression is returned to the calling method. If we mentally substitute the closure code into the calling method (shown below), this seems (somewhat) intuitive.



The Problem

Here, the issue of Tennent's Correspondence Principle (TCP) comes in. The idea is that any code or keywords used in the closure should behave the same as though the code were situated inside the calling method. If you think about it in terms of substitution, this seems reasonable.

However, for unrestricted closures, this means we can have return statements that are non-local: that is, they do not simply return from the closure itself, but instead from the calling method (e.g. withTransaction above).

Because this behaviour is different from older anonymous inner classes, some people are very concerned about cut-and-paste errors and a general misunderstanding of the code.

In my opinion, this is a good debate. However, no one seems to address the issue that syntax highlighting can offer visual cues to the reader. In other words, syntax highlighting doesn't have to follow the TCP.

We may be able to use context to render code differently.



Complex Block

Let's take our contrived example one step further. Imagine the list of names can contain a poison pill that alerts the program to stop creating Employees.

Here is the code, as is typically shown on blogs:



I know: gaaaah! It's rough on the eyes and the return statement seems very strange: we want to reconcile the return with the ending expression that results in an Employee.

Remember, it works like this:

• if the poisonPill is given, the return is non-local and so withTransaction will return (think substitution)
• if the poisonPill is not given, the ending expression is, well, returned, though in terms of substitution one might say it is used.
  

Tricky, yes? Indeed. But how would we view this code in real-life? Eventually, we would see it through the lens of an IDE; I contend that this lens could use colour to provide visual cues to the user:




That is, return may behave the same inside a closure (satisfying TCP) but it doesn't have to be displayed in the usual way.

The Upshot

Colour your world: syntax highlighting may mitigate Tennent's Correspondence Principle and soften the syntax of all the closure proposals (not just BGGA).

P.S.

With the new prototype, restricted closures (which use =>) are not allowed to use the keywords return, break, continue. Unrestricted closures (with ==>) are allowed.

Though foreshadowed by Neal in the past, this is a new development.

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".