NFJS 1 Boredom 0 (a No Fluff Just Stuff review)

Here's a disclaimer from my review of March 2007:

This is NFJS #6 for me. The first 4 years, I worked with a previous employer. This year, I attended while employed by an affiliate of a sponsor. Over 5 years, I have paid some of my own $; other times, an employer covered the cost. All 6 times, my own, personal weekends were consumed. As you know, these opinions are solely mine.

The Skinny

If you are new to NFJS, see my review from March 2007 for a general overview. This review will assume you're familiar with the shows and are interested in the current 'vibe'.

The upshot, like last time, is that this is a no-brainer if your company will foot the bill. If not, then it is a personal decision. I believe it is a good value, and am glad I attended. I felt it was a weekend well-spent because:

• I love the energy from a concentration of developers.
• Though the show is more familiar now, and one can't recapture the wide-eyed wonder of seeing these speakers for the first time, the content is topical and good stuff.

Plus, it's fun.

Editor's note: In this CodeToJoy exclusive, Jay Zimmerman (organizer), Ted Neward (keynote speaker), and a computer (Ted's infamous Mac) report the result of the weekend:



The Vibe

From my perspective, the prevailing themes of the show were:

• The energy around the Language Renaissance is palpable. Everyone wants to try out at least one of Scala, Erlang, Haskell, etc for fun. To paraphrase panelist Jeff Brown: Groovy and Ruby are now required. (Ed: see Jeff's clarification of context in the comments. 'Twas a fun remark that got a big laugh, though IMHO it is a reasonable statement.)
  
• Both open-source solutions and agile methods are increasingly accepted in the workplace. The level of discourse is much different than even 2 years ago.
• Yes, the buzz around Rails and Grails is still strong. Increasingly, speakers are talking about making money by working on these kinds of projects.
  

The Keynote

Ted Neward talked about how the next 5 years will be about languages. (Fellow speaker Alex Miller has a post which contains a link to a similar talk and some of his own commentary).

Ted's thesis was that the Big Runtimes (the JVM and CLR) act as a bridge between the academic language lawyers and the problem solvers in the field: the academics can experiment with language syntax and exotic semantics; the problem solvers can use these languages and rely on the venerable runtime libraries to get things done.

I enjoyed the talk thoroughly. Ted paced to-and-fro like a giant cat: if NFJS is Narnia, then Ted is Aslan, except very hungry, and with a mild-case of rabies. Many good jabs toward, well, everybody. He's an equal-opportunity offender (and a big softie underneath it all.)

Editor's note: In this shot, the popular veteran speaker Stuart Halloway concurs with the result:



The Panel

The panel discussion (during a lunch break) covered the language issue, and the Rails/Grails progress, but also discussed:

• Is the JCP a good thing? e.g. Should Spring go under a JSR? Would it have succeeded if it originated that way? (Opinions were mixed: many agreed that the JCP has done cool things, particularly for language development (e.g. annotations), but most think it is too bureaucratic to have spawned something like Spring).
• Sun goes open-source with the JDK/JVM: good or bad? There was disagreement on whether or not there would be forks, but most felt this wouldn't be harmful.
• A favorite is the panel's picks for tools and books. I'll try to summarize the books in a future post. Major props to the seminal JCiP and many 'psychology of design' books.
  

The Sessions

I can't cover them all or even half, but some memorable sessions for me:

• Jeff Brown had a very cool session on Metaprogramming in Groovy. I have some experience with Groovy, so it all just clicked for me (e.g. the ExpandoMetaClass). I think that this is strong mojo, and probably best used in frameworks (versus apps). But it's powerful... I am planning a post on the effect of mind-bending warps through the JVM as one 'thinks' in Groovy and then in Java.
• You can't go wrong with Stuart Halloway: I saw at least 2 sessions on agile development. The pace is animated and brisk; sometimes it's like doing mental wind-sprints, but the ideas just flow.... One takeaway was that Stuart's company really, really does agile in a major way. How about this: the CI build breaks if it detects that the 'code complexity' constraints are violated. Here's a thought: comments often describe what the code is doing, but the code should really be so expressive that it describes what the computer is doing.
• I caught a session on Terracotta caching for Hibernate with Alex Miller. Highly recommended. I don't know a lot about clustering, but there were demos and stats that were made the case in a compelling fashion. I'm still blown away by the very nature of Terracotta. I thoroughly enjoyed getting to hear Alex talk about it and some of the internals. I recommend keeping on eye on this project.
  
• Michael Nygard won me over during the panel discussion, and created some after-session gossip. That is, he told stories about enterprise failures (often involving holiday online sales), and, later, people would share these nuggets like ghost stories around the campfire. I saw his talk on 'Design for Operations'. The gist was that developers aren't done when QA gets the deliverable: it goes into production. Yet it is amazing how corporations act as though Dev and Ops are 2 entirely separate, disjoint entities. The thought is that there are a variety of ways to get them closer together: true person-to-person communication (!), and designing for monitoring (e.g. JMX) are just two examples.

Final Score

At NFJS #1, I saw Dave Thomas for the first time. I heard my first "Ted Neward Insult Of Irreverence". One can't recapture that kind of magic, which was kinda like geek sex.

NFJS #6 was a different kind of experience, but because now _I'm_ different and the 'speaker circuit' is more familiar. It was a fun weekend and worth the investment.

If I hadn't been there, I'd either have been on a treadmill or watching a baseball team which has already missed the playoffs. There's no contest:

NFJS 1 Boredom 0

Raw Cookie Dough from NFJS

I just came out of the weekend conference at the No Fluff Just Stuff/Gateway Software Symposium.

I hope to post a review later, but first here are some fun quotes and 'half-baked' thoughts that I had during the show. Some of these ideas may become future blog posts; they are 'half-baked' not in the sense of crazy, but 'not fully-cooked'.

Quoteth (actually: paraphraseth)

• I think the Macs are good, but the experience is oversold. -- a Mac owner (Hallelujah!)
• Best practices are average practices, because everyone does them. -- Stuart Halloway
• An enterprise app has two sets of users: end-users and operations staff. -- Michael Nygard
• That pen extends Throwable. -- Brilliantly witty attendee commenting on Ted Neward's penchant for throwing pens during keynotes
• Scala, Erlang, and Haskell should be on your list for experimentation, and, well, Groovy and Ruby are simply required. -- Jeff Brown (Ed: this was a wry remark in jest, see Jeff's comment on the review post).
  

Half-Baked Cookie 1: What is 'Slow' ?

I wonder if there are any studies in cognitive psychology or neuroscience that offer insight into our perception that a computer experience is slow. It seems that as computer scientists, we have a wealth of empirical evidence and tactics (e.g. make a home page for website ultrafast), but what do the brain people have to say?

Half-Baked Cookie 2: Latency _is_ zero

Ted Neward mentioned that we repeatedly fall into the trap that distributed computing is easy: latency is zero, the network is reliable, and other Big Fallacies. It seems to me that part of this problem is that as developers, we optimize our work environment so that these fallacies are true. e.g. We write mock unit tests so that we don't have to suffer the inconvenient network; if we manually test an app on a network, we scream blue murder that our internal network is slow.

It makes sense that we want to develop software without obstacles, but we build an ivory tower that is far removed from the network. This Development-Production Gap is why we fall into the trap over and over again.

Half-Baked Cookie 3: Observing Software in the Wild

Based on a cool presentation by Michael Nygard on Operations in the enterprise, I think that a dev team should have a monthly review of log files from a production machine. There will be surprises and warnings of future trouble.

Half-Baked Cookie 4: JVM Decorators

Though I prefer the term 'JVM Tunnelers', there is an argument that many of the new languages hosted on the JVM are implementing a macro-level decorator pattern (of sorts) for the JVM. The JVM (and libraries) are still there, but there's now a lot of syntactic window dressing (and ideas) on top.

Groovy is to Java, as BufferedFileReader is to FileReader ?

Half-Baked Cookie 5: Packets in the Wind

Whenever 4 or more developers discuss real life while dining, one (often me) has to draw a parallel to computer science. This is especially true for traffic patterns in St Louis and networking analogies (often broken routers and YouTube saturation).

Half-Baked Cookie 6: Security Manager as Code Police

Ted Neward talked about using the Java Security platform to enforce that a webapp is not able to call System.exit() (which would be, um, bad).

I wonder if this can be extended to other code, during CI builds/unit testing. Assume that there is a class/method in your project that you don't want others to call. Perhaps Spring or something demands that a setter is public. Does it make sense to use a security policy that would fail CI if that contract was broken?

Half-Baked Cookie 7: Ruby Evangelism

Stuart Halloway mentioned a fact that is well-known to NFJSers. Dave Thomas deserves a lot of credit for the Ruby Rage. For years, he has spoken at NFJS (primarily a Java conference), and has proudly proclaimed that he doesn't know Java. He was (and is) an old-time preacher going around from town-to-town, literally, and conducting powerful sermons on the redemptive powers of Ruby.

It worked. Before RoR, there was Dave T.

Sublime By Contract

Over and over again, I am amazed by the genius of separating the What from the How.

From the micro-level of interfaces to the grand schemes of protocols, the inherent beauty of The Contract is cool. For two reasons:

• it clearly defines the expectations
• the brilliant, creative solutions to Gettin' It Done

Example 1: The History of Couriers

The contract: get stuff from A to B, in X time units, for money. Classic.

From the Pony Express to banzai bicycle messengers, onward up to FedEx and UPS, each step of the courier business is an intriguing story. I don't know if there is a popular history of couriers but there should be. The pioneering spirit is abundant and the technology is outrageous. Fascinating.

Example 2: IP over Avian Carriers

It is a silly example but delights me now as much as it did when I first read about it, ages ago. Birds and nerds team up for some networking mojo.

Example 3: Inversion of Control

In the early days of Java, it was very neat to use Collection, List, and other interfaces because of the latitude of changing the implementation; e.g. one might go from a HashMap to a TreeMap, based on profiling. Swing and distributed computing use 'em all over.

For straight-up apps, though, it seemed like we never really changed the implementation, even with factories, but it was cool nonetheless. We could change them if we wanted to.

Then came the IoC containers and the interface had a resurgence: Version 2.0. Now, it's very easy to change out implementations. It's a great feeling to use a set of mock objects for daily unit tests and a full-blown DB implementation during nightly integration testing. More than just using a contract, it's the tactile sense of different implementations. A sense of change.

Example 4: Terracotta

I recently went through the Hello Terracotta exercise on Alex Miller's blog. Check it out.

Terracotta is the latest mind-altering idea I've come across. I'm not even sure that I understand the implications of what it does, just yet. It really makes one say 'wow' and 'huh?' at the same time.

I do understand that it is sublime by contract. Get this: it honours the semantics of the Java Memory Model, and yet in doing so, it dopes up your (designated) classes and JVM so that it can shuttle your data to a central service (this phenomenon is called Network Attached Memory). In the simple example, one's app/JVM can go up and down and yet work with 'persistent' objects.

The kicker is that your code doesn't need to know: there is some serious mojo under the hood, and yet the contract of the Java Memory Model still holds.

If the standard JVM is a bike courier, Terracotta is UPS. Your stuff still gets done, but more efficiently.

There are some ideas that wouldn't occur to me even if I were on a desert island for 100 years. One of them is separating -- in such a weird way -- the contract of Java memory semantics from the implementation.

That's sublime.

No Fluff Just Stuff Redux

I'm looking forward to this weekend: the fall edition of the Gateway Software Symposium (aka No Fluff Just Stuff).

As I blogged back in March, I really enjoy NFJS; this will be my 6th!

The list of speakers is top notch, as always. Two favorites are Ted Neward and Stuart Halloway. I'm looking forward to meeting Alex Miller and seeing my colleagues Jeff Brown, Mark Volkmann, and Tom Wheeler.

If there's interest, I'll try and blog on a day-by-day basis. The flow of ideas in these conferences are really great.

Hope to see you there!

Yo Classpath, It's Globbering Time !

This post isn't rocket science: it is mostly for my own reference, but you might find it useful.

I've written a small, easy Groovy script that scans a directory (recursively) and builds a CLASSPATH from scratch.

We'll call it a jar globber. This really appeals to me:

1. Sometimes, it's great to go 'minimalist' and start from scratch

2. setting the CLASSPATH is the first step to cool scripting with the 'JVM Tunnelers' such as Groovy

In this post, I'll show the Groovy script and then use it to glob jars in the Jini project, and write a tiny script as a demo.


Here's the Groovy version of Jar Globber:

// Usage:
// groovy jarGlobber [targetDir]
//
// e.g. groovy Which c:\YourProject\lib

// Closure: if file is a jar, emit string
myEmitter = { file ->
    if( file.isFile() && file.canRead() ) {
        fileName = file.getName();
  
        if( fileName.indexOf(".jar") != -1 ) {
            // easily changed for Unix
            println "set CLASSPATH=%CLASSPATH%;" + file;
        }         
    }
}

////////////////////////////////////////////////
// static void main(String args[])
//
// TODO 1: sanity check arguments
// TODO 2: add param for Windows versus Unix
def fileName
searchDir = args[0]

println "set CLASSPATH=."
new File(searchDir).eachFileRecurse(myEmitter)

Easy stuff, thanks to Groovy's ability to iterate over files. (Yes, you Bash hounds, there are easier ways to do it.) Using Jini's lib directory as the target, the output looks like this:

set CLASSPATH=.
set CLASSPATH=%CLASSPATH%;c:\jini2_1\lib\browser.jar
set CLASSPATH=%CLASSPATH%;c:\jini2_1\lib\checkconfigurationfile.jar
set CLASSPATH=%CLASSPATH%;c:\jini2_1\lib\checkser.jar
set CLASSPATH=%CLASSPATH%;c:\jini2_1\lib\classdep.jar
set CLASSPATH=%CLASSPATH%;c:\jini2_1\lib\classserver.jar

ETC

If I output this to a BAT file and execute it, I'm ready to roll.

Here's a screenshot of a Groovy shell session where I start scripting Jini objects and interacting with them. (Note: I have started the Jini service elsewhere.)



You can click on the screenshot but here's the gist:

def loc = new net.jini.core.Discovery.LookupLocator('jini://localhost')
def registrar = loc.getRegistrar()
println registrar

We shoot, we score! Dynamic Jini objects. So, now it is Game On (or Flame On?) for experimenting with Jini, since the CLASSPATH was clobbered....

The cool part is that there is nothing particular here about Jini. We're ready to roll with any given project. Try your project at work. It is truly amazing to start scripting Java classes.

Zen Python: The Sound of One Record Appending

Recently, I tried to make a Python program ultra-terse, as a fun puzzle.

I re-discovered two things:

• I love Python. I hadn't used it in years and yet I was "back in gear" within a few minutes.
• Python just seems to work. It is like a substance that can be a solid or a liquid, depending on your requirements, and at the same time.

In particular, I found that Python V 2.5 has some pretty cool ways of handling empty maps, or 'dictionaries' (in the Python parlance). This is elegant stuff, and yet easy enough that you need not know Python.

Consider a problem where we want to organize participants in a triathlon: a person has a name, gender, and age. Age groups will be 20s, 30s, 40s, etc.

By using a lambda expression (think anonymous function), on a defaultdict method, we can specify the default behaviour of a dictionary when there is no entry for the key.

myEasyMap = collections.defaultdict (lambda:[])

In this case, myEasyMap will create an empty list and insert it, when a key is not found. For example:

myEasyMap = collections.defaultdict (lambda:[])
myEasyMap[30].append("John Smith")

The above example appends "John Smith" into the list of triathletes in the 30s, even though there were not yet any listed.

The really cool thing is that we can chain these default dictionaries:

myData = collections.defaultdict (lambda: collections.defaultdict (lambda:[]))

myData["M"][30].append("John Smith")
myData["F"][20].append("Barbara Doe")

Above, myData is a map that resolves to a map of lists. There are two outer keys ("M" and "F"); the inner keys are the age ranges.

Should we do this in production? Probably not. But it is gorgeous.

Below, we iterate over some records and organize athletes:

myData = collections.defaultdict (lambda: collections.defaultdict (lambda:[]))

records = []
records.append( { 'name': "John Smith", 'age': 35, 'gender': "M" } )
records.append( { 'name': "Axl Rose", 'age': 45, 'gender': "M" } )
records.append( { 'name': "Britney Doe", 'age': 25, 'gender': "F" } )

for record in records:
   name = record['name']
   age = record['age'] % 10
   gender = record['gender']
   myData[ gender ][ age ].append( name )

Neato with a capital 'O'.

Ruby has similar behaviour, which is not surprising (see Porsches and Ferraris) but I don't know many languages that can do this. (e.g. I don't know of a way to do it in Groovy. Do you, Groovy readers?)

Porsches and Ferraris

I once wrote about Alligators versus Crocodiles, which was a metaphor for the religious wars of syntax.

Recently, some colleagues have been experimenting with a number of programming languages. I hope to write more on this, but essentially it has renewed my interest in a variety of languages.

And, the discussion spawned another analogy.

The main thought is this: often, in CS or not, there are 2 camps
with rabid proponents. The debate between the two can get
quite heated. What gets lost in the shuffle is that both camps
are truly sublime, and that the rivalry and competition brings
parity, in terms of excellence.

Two examples outside of CS: Porsche versus Ferrari, and a
Fender Stratocaster versus a Gibson Les Paul.

I'm sure there are message boards all over the net, filled with
flames on all sides. I have my own preferences, and might even weigh into the debate, but another part of me asks: Are you kidding me? How can you knock any of these? At the same time, there are nano-level differences that polarize people.

The CS example (du jour) of 'Porsches versus Ferraris' is Python and Ruby. They have many, many similarities at the "forest level", even if the trees look different. And yet I don't know many (if anyone) who has one foot in each camp.