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.

The Art of Flame War: DoS Attack

Every night is Halloween on the Internet -- Anon

'Twas a dandy day for dueling posts about various technologies. Unfortunately, the flame war du jour is extraordinarily vacant: no insight, neither satire nor parody, and no bumper stickers :-O It's not even especially funny (though a recent parody post got a chuckle).

Website hits are the currency of the tech blogosphere, except there are no debits: only credits.

Counter flame-bait, posts of outrage, etc only offer up more hits and service the ego of the originator. There is no bad PR, as they say (especially if you have a book coming out).

From this corner: no links, no names, no outrage. Just a yawn of indifference.

Denial of (ego) service starts now, as I turn the page. Join me!

Tycoons of Screen Real Estate

An Investigative Report
Exclusive to CodeToJoy
September 2007


CodeToJoy recently went on location to a local IT shop to investigate, in the words of one developer, an "arms race" of screen real estate.

All developers know the luxury and productivity gains of having two monitors. Some time ago, an enterprising developer supplemented standard-issue corporate equipment with a personal monitor. Not to be out done, teammates soon followed.

Before long, the 2 monitor barrier -- long considered a theoretical limit -- was broken. Said one coder, "Yeah, things kind of escalated".

Months later, we now document -- for the first time -- the culmination of this pixel parade, these Monitor Mansions.

Dear readers, here are The Tycoons of Screen Real Estate, and their design patterns. No photo editing has been used. These are real cubes with displays for a single computer.

The Letterbox



The Sports Bar

Dijkstra On Silver Bullets

As an aside I would like to insert a warning to those who identify the difficulty of the programming task with the struggle against the inadequacies of our current tools, because they might conclude that, once our tools will be much more adequate, programming will no longer be a problem. Programming will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness, we will find ourselves free to tackle the problems that are now well beyond our programming capacity.


-- E.W. Dijkstra, 1972 (emphasis added), from this site

ps. On the bright side, there shall be job security!

Calling Ham Radio Operators: jMorse

I recently visited a friend and colleague who showed me his ham radio gear in the basement of his house. This was a delightful surprise. Although I didn't get into it, my father has been a hobbyist forever, and my grandfather built crystal sets many years ago. The ham radio scene always seemed to have cool people who shared the same pioneering spirit as the early Netizens. (Do you remember when it was a minor miracle that you received an email from someone from across the world? Hams knew that feeling ages ago, and with a lot of homebuilt stuff.)

Bonus: my friend has a project on SourceForge for generating Morse code from input text. Check out jMorse here. I've only dabbled with it so far but it worked right from the command line. Cool stuff!

(Interestingly, this is not the same person who embedded Morse code into the comments of a production program. See previous post.)

Crazy Code Comments: Adventures in the Margin

Some colleagues and I were recently talking about Fermat's Last Theorem and how an innocuous comment in the margin, "I have a truly marvelous proof of this proposition which this margin is too narrow to contain", sparked a chase for the proof that lasted centuries. This book is a delightful, mainstream work on the proof and the history of the theorem.

The conversation led me to think about our margins as developers: comments. It's quite a tangent but surely these are the modern-day margins: the untamed jungle of writing where not even the mighty compiler can pass judgement.

What are some of the craziest things you've seen in the comments? Here are some select themes from my experience.

Fermat Wanna-bes

Whenever I see a code-comment that uses the word 'obviously', then it is either a silly, needless comment or they are following in Fermat's footsteps. Something to the effect:


// Obviously, we need to serialize the data and convert to
// Latin-2 and then one's complement for reasons that are
// perfectly clear and need not be specified.


Pseudo Source Control

I'm probably guilty of this one: checking in code with an older implementation contained in the comments. Code subjected to this treatment does not age very well. Ugh.

Flame Wars

A favourite:

• Person A has a comment explaining a code segment.
• Person B writes an editorial comment on the approach, and leaves in the original comment.
• Person C (or better: Person A) retorts with a defense of the original code!
  
• The chaotic fun continues with a flame war, replete with threads, right in the code.
  

If You're Reading This, It Must Suck To Be You

I've seen comments to the effect:

// The hyper-flyweight-quantum-double-dispatch pattern was
// attempted here but later it was discovered it wasn't a good fit.

Yikes... That's never good but at least they get kudos for intellectual honesty.

Small World

It's always interesting to read a comment with a name of someone you once worked with, or know in your city. Bonus: comments that you wrote in a previous life.

Equine Esoterica

In my undergrad studies, we used a textbook that cited this infamous comment as a bad example:

// horse string length into correctitude

Oh, I love that line. For that class, I ensured that all of my programming assignments had that in there somewhere.

The Best Yet

I never thought I would see anything to beat the last one, but this did it. This is a real example from the wild:

// .... . .-.. .-.. ---  .-- --- .-. .-.. -..
// begin section
// .... . .-.. .-.. ---  .-- --- .-. .-.. -..

If you look closely, the bookmarked lines are in fact Morse Code. Brilliant... absolutely brilliant. (I'll let you figure it out. See this post for a hint)

Fermat would have been proud.

The Great Tenor

I don't know much about opera or Pavarotti, but when a man can transcend that genre into the mainstream, that's saying something.

I've seen some tributes this past weekend and it only seems fitting (given the musical sub-theme of this blog), to mention the passing of Luciano Pavarotti.

I'll offer two quotes that often characterize the true virtuosos, independent of their chosen profession. I'm reasonably certain that he said the first, and I'll paraphrase the second from an interview I saw this weekend.

I'll leave the interpretation and analogies up to you.

On Modesty

Am I afraid of high notes? Of course I am afraid. What sane man is not?

On Bringing The 'A' Game

I have heard many musicians stress the importance of playing as best as one can at all times: never relent. In this interview, Pavarotti was talking about that importance and how the past was no guarantee of a given, future performance. He said something to this effect:

I treat every night as an exam. I stand before them and must do my best.

His combination of talent, charisma, and humility was extraordinary. All too late, I am starting to understand the hoopla.

Pecha Kucha and Blaise Pascal

Wired Magazine strikes again by alerting us to a recent phenomenon over in Japan, that is spreading through Europe: a presentation format called Pecha Kucha.

Think of it as haiku for the PowerPoint crowd: 20 slides for 20 seconds each, for a total of 6 min 40 seconds.

(I wonder if this can be applied to screencasting?)

Generally, I find brevity fascinating. I love the mental exercise of trying to make a small, simple program even more terse. I often wonder if creativity can be more fun within the rules of a framework (such as haiku or, say, the fugue musical form) or if it more satisfying to "smash the rules" entirely (such as free verse). I could write an entire essay on how musicians such as Mozart and Randy Rhoads were brilliant within musical frameworks whereas Beethoven and Edward Van Halen joyfully kicked the doors down.

The irony, of course, is that brevity is deceptive. The following quote applies just as much to writing as it does to programming. From the written word of Blaise Pascal:

I would have written a shorter letter, but I did not have the time.