Code To Joy

Groovy Talk

2011-11-14T16:30:00.000-08:00

I recently gave an "Intro to Groovy" talk for a local CIPS chapter.

It was a special evening: I returned to my alma mater, re-united with old friends, and met enthusiastic students.

I assumed the audience wasn't familiar with Java, and so the narrative was a high-level report of the blossoming ecosystem on the JVM over the past few years, with examples in Groovy. The material is available here.

My thanks to those who attended!

Strange Loop Videos

2011-11-12T13:23:00.001-08:00

This won't be news to most readers, but if, like me, you were not able to attend Strange Loop 2011: take heart. The videos are being released online at InfoQ. Here is the schedule.

The lineup is truly outstanding. For more about the conference, check out Weiqi Gao's review.

Blogger, OpenID, and Stack Exchange

2011-09-20T16:31:00.000-07:00

I'm a big fan of Stack Exchange and have invested a fair amount of time on various accounts on there (mostly Stack Overflow, less on English and Music).

However, I have to admit that I do not keep up with their various escapades with OpenID. I hear about it on the podcast/blog, but I haven't paid much attention.

However, every now and then, it seems as though I can't get into my accounts via my Blogger URL. Not good.

Strictly speaking, I should research OpenID, Blogger's implementation thereof, and then study the trials and tribulations of Stack Exchange. Then, I could summarize it for you, dear reader, and we could reflect, philosophically, on the sharp corner-cases of the web while enjoying a beverage in a local pub.

This isn't one of those posts. This one is simply intended as a modest link-post of gratitude (aka "this worked for me!").

The Problem

When I visited a Stack Exchange site recently, I couldn't login via my Blogger URL, and may not have even been presented with the familiar login icon that I had been using.

One Solution

Follow the steps in this post on JMPinline, including creating a Google Profile and updating with the new links.

Presumably, Stack Exchange uses OpenID 2.0 now and this will upgrade your Blogger OpenID to that version.

Either way, I was immediately able to login to Stack Exchange. My sincere thanks to the original author!

HTH

Your Blog... Sucks

2011-09-05T08:04:00.000-07:00

Hello CodeToJoy Nation!

Yes, yes, it has been too long since the last post. The internet has weighed in, and we have noticed.

Your friend and mine, Weiqi Gao, notes that "Nobody I know posts much any more".

The inimitable Nate Neff wrote to me with a succinct critique of my writings in the last year:

Your blog... sucks.

Well. On the evidence, assuming small, frequent updates are important (which is fair): guilty as charged.

However, I don't consider this blog defunct at all; in fact, I often talk about "the glory days" from a few years back.

I've been grappling with writing an annual retrospective, now that I have been pursuing a new chapter for over a year. The trick here is that challenges and triumphs have been much more on the soft side of software: team dynamics instead of technical innovation. I wrote an article along these lines for the NFJS magazine back in April. The article drew on years of experience, but the inspiration originated in my new world.

As I write this, I realize that I'll have to shelve that post and simply post smaller chunks. Stay tuned! I'm still here.

Maritime DevCon 2011

2011-06-19T05:06:00.001-07:00

I'm back from a jaunt to Fredericton, New Brunswick, for Maritime DevCon. Here's a post that lies between a 'random walk' and a review.

Background

From PEI originally, I've spent most of my career in St Louis/USA. I've been an active member of the user group/conference scene there. When I moved to the Maritimes in 2010, I wondered if I could find 'my people' who can/read write in the original Geek.

The upshot is: these are my people. This one-day event was a gem. The organization was first-class (good food, killer door-prizes). The topics were interesting and straddled the fence between pragmatic and esoteric-but-neat (reminiscent of Strange Loop). Most importantly: the 'spark' was there; that palpable energy that naturally spins out of conversation between interesting techies.

Venue

Maritime DevCon was held at the Wu Centre at the University of New Brunswick. About 70 people attended, notably giving up a Saturday to spend time talking tech.

Talks

Here is the schedule. I attended these talks:

OpenStack 101 (by Sandy Walsh)

I'm not especially familiar with cloud computing, or virtualization, so I was surprised to learn that Open Stack is a huge initiative among big players (e.g. Intel, Cisco, and... NASA!?). The architecture involved here is mind-blowing: will the real platform please stand-up?

Random thoughts:

I often wonder if programming language X will be the Next Big Thing. Though it is in a different scope, virtualization is Right Now. Every time I think I have an appreciation for its influence, I see another talk where the landscape has changed ever further.
Pythonistas unite! Though thinking at this level often reduces the programming language to an implementation detail, I was delighted to hear that the underlying system is written in Python.

Redis (by Peter Doan)

At other conferences, I've missed talks on Redis, the key-value store. On the way to NB, I listened to a changelog interview with the author, Salvatore Sanfilippo. Consequently, I expected a simple, near-minimalist API, and Peter confirmed that with his code examples. Works for me.

Natural Language Processing with Java (by Chris Nicholls)

Interesting piece on the state-of-the-art in NLP, especially sentiment analysis. The two main libraries are LingPipe (not free) and Apache's OpenNLP. I hadn't thought about NLP in a long time, and certainly not with respect to Twitter: (a) Twitter could be a gold-mine (b) '#' is a legit, vital punctuation mark.

Git (by Chris Dail)

This was a thoughtful, solid intro to Git. I've been away from Git for awhile, so this was useful refresher, and pulled together a couple of tectonic plates floating in my consciousness.

I especially enjoyed a section described branching in terms of highway lanes rather than trees. I appreciated anecdotes about using the Git client for Subversion as a rebel effort to 'subvert Subversion'. Note that Chris has a detailed blog post about migrating from Subversion to Git.

Node.js (by Justin Vaillcourt)

Node is another topic that I haven't seen yet. For this talk, as my friend Weiqi Gao would say: you had to be there. This was pure, unadulterated hackage, executed by a pack of young, feral dogs with unbridled enthusiasm for technology.

Justin grinned though an abbreviated talk that ranged wildly. Just when frat-house interactions with his posse threatened to steal the show, out came jaw-dropping illustrations of Node.js.

A key example used the socket.io package:

a visitor hits a website and scrolls around
an admin console shows a thumbnail of page the visitor is viewing
as the visitor scrolls, navigates in his/her browser, the thumbnail scrolls in the admin console

This was done about 150-200 lines of Javascript. I don't know if this is a strong Node example. I'm still trying to wrap my mind around it.

MongoDB (by Derek Hatchard)

As with Redis and Node, I'm familiar with the buzz of MongoDB but hadn't looked into it. From the perspective of presentation techniques, this was a strong talk. A good arc from the motivation through to code examples, with images instead of bullet-lists.

Like Redis, the MongoDB API is deceptively simple. It's hard to appreciate the power. I was happy to see explanation of sharding with MongoDB, and very happy for an introductory theme on "no silver bullet", applied to relational DBs and NoSQL tools.

Suggestions

My main suggestion is that the sessions should have written evaluations. This benefits the speakers, the organizers, and ultimately the attendees. Also, there should be an overall conference evaluation.

Bottom-line

It is non-trivial to travel from PEI to Fredericton, but DevCon was worth it. The material and the energy felt like events in larger urban centers, and that's saying something.

A shout-out to Derek Hatchard, other organizers, and sponsors: thanks! I'll be back next year, as an attendee (or possibly as a speaker?): after all, these are my people.

Random Walk Down NFJS (2011)

2011-06-12T17:29:00.000-07:00

Long-time readers know that I am a big fan of No Fluff, Just Stuff. There are many posts on this blog regarding reviews, keynotes, pianos, and so on.

Often, I start writing a "random walk" post, intending it to be quick and whimsical, but I end up writing a full review. This one will be quick, otherwise it won't be written, alas. Here we go...

I returned to St. Louis (again!) in May to attend the Gateway Software Symposium. As you can imagine, it was fantastic to catch up with old friends in a familiar environment. Just like old times.

Code As Proof

I attended Venkat Subramaniam's talk on concurrency without pain in Java. The talk was all-code with no slides. A few small examples began with "synchronized and suffer" (his phrase) model and scaled through various techniques, including locks, STM, and actors.

All interesting stuff, but I was especially taken with the elegance of the examples. If you've studied math, you may know the minimalist charm of a proof: there is no excess fat; everything is a direct line from A to B. As a presentation style, Venkat's talk recalled that spirit. Every example added one element to get to the next point.

HTML5

HTML5 officially has my attention. I saw a few talks, and was taken especially with Nathaniel Schutta's session on mobile jQuery. As someone who is notoriously divided on choosing Android versus iOS as a development platform, this blew my mind. A unified UI experience for mobile! I'm still trying to get my mind around the idea (and how to monetize it in the various app stores).

Sonar

The headline: Apache applies Sonar to its projects, as shown here. Matthew McCullough's talk convinced me that this isn't merely a collection of code metrics. With experience, I think a Sonar guru can transcend the raw data and see interesting patterns over time, such as the impact of summer weather on code quality (!). This is a Freakonomics-like enabler.

Crafting Software

Two paraphrased thoughts that really stuck (I hope I've captured the essence).

One from Peter Bell, along the lines of: on initial estimates for a project, give enough time to do the minimum spec, and include time to polish based on feedback from the first cut.

From your friend and mine, Ken Sipe: two major problems with software teams are (1) poorly defined acceptance tests and (2) dysfunction in the daily stand-up. When someone with Ken's experience distills things down to two items, that's powerful stuff.

And The Gradle Will Rock

Ken also spoke on Gradle. I'm a fan, and gave an intro talk back at GSS May 2010. The interesting story here is the growth. There is a lot of industry momentum here, and the training/book offerings are ramping up big-time.

Where's The Groovy!?

I caught Venkat's talk on Spock, and liked it very much. I didn't catch any Groovy or Grails talks, only because I'm very familiar with them. It was interesting to reflect on the history of these technologies. Grails has been 1.0 since Feb 2008! They grow up so fast.... *sniff*

Anapestic Tetrameter!

Nothing stresses me out like poetic meter (pun intended). It is one of a handful of high-school subjects that I just Could Not Understand. When I saw Tim Berglund's tweet that he was working in anapestic tetrameter, I shivered out of reflex. Gah!

Then, at NFJS, Jay Z showed the video. All is forgiven. Tim crafted an ode to Kent Beck's Implementation Patterns. Vote for Tim's vid on DZone. Vote it up on YouTube. It is wonderful.

Thanks

This may sound like trite, blanket statement, but I can't mention everyone. The weekend truly was chock-full of heartfelt re-unions and conversations, on many levels. See you again soon!

Meet Me In St. Louis

2011-05-04T16:34:00.000-07:00

Hello, Code to Joy Nation (esp. those in Saint Louis)!

Next week, I'll be returning to Saint Louis to attend the NFJS Gateway Software Symposium. I can't wait to be back in town and see everyone!

Long-time readers know I'm a fan of the tour, and think the speakers are top-shelf. Many keen insights and fond memories over the years.

A fond highlight was speaking at the Saint Louis show in 2010. This spring, I wrote an article for the NFJS magazine. Both were true growth experiences for me.

Last year, knowing I would be leaving, I wrote a personal 10 year retrospective, highlighting a certain piano at the Marriott West. Well, tune 'er up! I've missed it.

If you're at the conference, be sure to say hello...

Local Website as Tool Belt

2011-03-29T15:14:00.000-07:00

Quick, answer this: on your dev machine, how many keystrokes does it take for you to find the documentation for the String class in your current language?

As I've paired with developers over the years, I've noticed a few patterns:

Just Google It

Gah! Consider working on a roof-top, say, at replacing shingles. Imagine needing a tool, and having to go down the ladder to get it. Now, imagine going down the same ladder every time you need the tool. For a professional, that strikes me as painful.

Bookmarks

Much better. If organized well, bookmarks are undoubtedly terrific. A minor downside is that navigating a bookmark hierarchy still takes time. I can't criticize someone who chooses this style, but I can't do it. It's as though we have a toolbox up on the roof, but that it's 10 feet away from where I'm working.

Local Website

I worked with a developer circa 2003 who ran a local copy of Tomcat. He curated his own web pages according to his needs. I thought it was pretty crazy at first, but I adopted the idea.

True, this ain't "rocket surgery", but I just love it. It strikes me as a tool belt, where everything is within reach. Here's why:

Use the home page for your bookmarks

Rather than organizing my bookmarks in a given browser, I simply put my favourite sites on my home page. (As you might guess, the Javadoc for Java, Groovy, etc are front and center.)

The advantages are:

You can see a lot more information immediately, just by hitting that big, inviting Home button. I have a geek column, an intranet column, and so on. Rather than navigate a hierarchy, I let my brain pattern-match on the shapes of the categories.
You may end up collecting more links that you would normally bookmark. e.g. I would never bookmark the 2011 calendar, and yet this way, I have a link for it.
You can add various text, such as the phone extensions of teammates.

Portability

When pairing with someone, often you are at their workstation. How will you find your bookmarks from there? With a local website, you can point them to your page (while you're at, have them bookmark it).

Beyond Web Pages

By having Tomcat on your machine, you are opening a world far larger than mere web pages and links. You can start to share Groovlets with your team. This can be a big productivity boost, and a subtle way to introduce the concept to others. (I've been working on a writing assignment that explores this further. Stay tuned.)

Another bonus: if you need to work up a sanity check with CSS or jQuery, you already have Tomcat installed and running.

The Point

As developers, we love shortcuts in our IDE because we strive for "typing at the speed of thought". If you google something more than twice a week, consider putting it on a local web page. Over the years, I've found it to be very useful.

As always, I'm interested in your tips for productivity gains. Share 'em!

Software Archeology And Video Time Capsules

2011-01-31T17:04:00.000-08:00

I was recently listening to Episode 338 of the Java Posse podcast, which is a recording of a session at the Roundup 2010. Near the 19:30 mark, a chap draws an analogy between software maintenance and archeology. Assuming the original team leads are no longer available, he asks (paraphrased):

What was the culture of the team?
What were the designs/philosophies of the original architect?
How can we make those thoughts more explicit?

Software Archeology

I found the moment to be eloquent, and reminiscent of an episode of SE Radio, where Dave Thomas uses a similar metaphor: code maintenance ultimately requires us to understand a culture by analyzing artifacts. Call it software archeology.

Artifacts

We can all name the usual artifacts: an architecture document, UML diagrams, sequence diagrams, and so on. If we are lucky, perhaps there are tests.

Unfortunately, all too often, documentation is formal and poorly written. Reading it for culture is like trying to understand a society by reading its laws: useful, but abstract and without soul. Worse, the documentation may be out of date and only vaguely relevant.

A Potential Solution?

As consumers, we spend untold amounts of money on video equipment, which is both powerful and easy to use. We think nothing of uploading staggering amounts of video to the cloud, documenting our lives, and yet in the corporate environment, nothing. This strikes me as absurd.

In addition to striving for new wikis, language constructions, and formal diagrams, why don't we use video?

Consider this: what if the team lead gave a 1-hour architecture overview, once per release, and it was recorded and checked-in to source control? What if s/he took an afternoon to make a screencast of a random walk through the IDE? That is, what if we treated video time capsules as project artifacts?

For future software archeologists, they would be worth their disk space in gold. Imagine the simple nuances and gems that are so difficult to express otherwise (e.g. "yes, we are bending the usual use of aspects here, but there was a trade show deadline. We hope to address this technical debt").

Note that in my vision, the production quality would be low: these could be one-take, banzai attempts. Naturally, no one can possibly explain all of the corners of a code-base, but this isn't about corners: this is about culture.

Counterpoint

This strikes me as so obvious, that I must be missing something. Perhaps I am simply naive. Arguing against this idea, the main deterrents that I can see:

Companies may not be prepared to buy and manage video equipment. In terms of acquisitions and stewardship, it just isn't part of their DNA.
Managers may fear that video is somehow less secure than source-code.
For highly regulated industries, what happens if a team-lead describes a design flaw or technical debt? Could this be a legal liability? (This could be a major deal-breaker, but certainly not for all companies?)
There is no incentive for a team to prepare others for future maintenance. Even if video time capsules are effective, the status quo is good enough, and between leads, developers, and managers, no one will demand better.

What do you think? Does your team use video?

Koans

2011-01-03T13:14:00.000-08:00

First, note that my former employer has a new look to its monthly newsletter, Software Engineering Tech Trends. I've always appreciated the articles (and wrote two), but now that I live in an area without many local user groups, I count on SETT when planning my study path.

January's article is a fantastic example. Your friend and mine, Mario Aquino, introduces us to koans, covering exercise packages in Ruby, Javascript, and Clojure (see comments for Groovy resources, Editor).

The Javascript example is especially easy to start and work with. A browser and a text-editor: it could scarcely be easier!

This is neat stuff. Read Mario's article for the full scoop on about martial arts training and Eastern philosophies. I'm definitely a newbie, but so far, I've noticed:

Testing as a contract

The koan style appears to embrace the view that testing is a useful prism for viewing an object. In normal software testing, the object is software, but here the focus is understanding. Despite a different focus, the tests as a concrete contract.

Not that we needed more evidence of being in a post documentation-centric era (post to follow?!), yet here it is.

Zork

Both the interactivity and the sense of Zen paradox reminds me of early text-based adventure games, such as Zork. It would take serious work and creativity, but I envision a learning app that combines the spirit of the koans with a sense of an adventure game. Potentially a great way to introduce kids into programming (or to their 2nd language etc).

Fun

Most of all, this stuff is outright fun. It's a potent combination of learning along with the electrochemical reward for passing tests. That's some mojo right there. What's not to love?

Pro Tip: Ask for a 999 Cut

2010-12-23T15:08:00.000-08:00

Hello CtJ Nation!

A short post to wish readers a splendid holiday season and a happy New Year. Thanks for staying with me through 2010. It has been a hectic year, and I've been unusually quiet.

As a light-hearted thank you, I'm sharing some links from the Strange Passions sessions at the recent Strange Loop 2010 conference.

I once thought I was an interesting person, but after seeing these talks, one is humbled and entertained at the same time. Wonderful, wonderful stuff.

My favourites are Entering Without Breaking (it inspired the title of this post) by Galen Collins and The Science of Musical Counterpoint and Illusion by Daniel Spiewak. (If it matters, GC's talk is rated-R for occasional language.)

All of the videos are available here.

Be safe, and be joyous.

Language Panel

2010-11-30T17:49:00.001-08:00

Here is a must-see video from Strange Loop 2010. It features a panel of icons and rock-stars, with another as guest host. The topic is the future of programming languages. It was a true treat to be there.

Some quick thoughts on the video:

Introductions part 1

Notice how the panelists didn't feel the need to list the languages they've worked with. Relative to their achievements, their intros are brief.

There is a calm confidence in brevity. I first noticed this when Dave Thomas introduced himself on the NFJS tour with: "I'm a programmer".

This separates the amateurs from the pros. Pros don't introduce themselves with the number of languages they know (a pet peeve of mine). It is assumed that everyone has worked with a dozen or more. It is true, no matter how impossible, that for every person in the room, there is someone else who has seen more languages.

Introductions part 2

Kudos to Alex Payne for paying respect. It struck me as sincere.

Introductions part 3

Guy Steele is one classy guy. Note his emphasis: he likes all languages. Each one has value and its own charming quirks. We get the sense that Guy is more interested in solving problems than the current fashion of the industry. He has an air that inspires me to take the high road, and stay above the language wars.

Language Wars

Alas, Guy's angelic aura only lasts for so long. The unvarnished truth is that I'm weak, and I can't resist language wars. Though the gang were rough on Perl, Crockford's irreverent non-comment on Parrot, near the 30:00 mark is priceless.

My Non Question

I nearly asked a question about escaping the surly bonds of ASCII in future programming languages. Unfortunately, I became distracted by my inner voice:

Is this a dumb question?
Am I asking this to impress the panel? To impress the audience?
Didn't Guy Steele, in a keynote, have a Unicode symbol in Fortress? Why wasn't I paying closer attention?
How could I travel 1800 miles for a conference and not have prepared a few questions?

And so on. In the end, I played it safe and sat on my hands. Though I may have avoided an embarrassing moment, I also passed up a chance at potential insight.

Lesson learned: brevity rocks; reticence sucks.

https download with Internet Explorer

2010-11-12T17:04:00.000-08:00

I strive to link to posts that have saved my team's bacon, as a modest payback. It might help search engines, and will certainly help me remember the experience, in the event I encounter it again.

The problem: Internet Explorer won't download a document (e.g. an Excel report) via https.

The cause: probably cache-prevention in the headers, per Eric Law's post.

The bonus: Eric mentions Fiddler. That tool might be very useful in general, though I haven't tried it.

Keynote to 2-up PDF

2010-11-12T16:55:00.000-08:00

This post is simply grateful linkage to a useful post by Alex Miller.

For a conference or business presentation, you may be asked for a 2-up B&W PDF. If you are like me, the first question is: "what is 2-up?" That question is answered here.

Easy. The next question is: how do I do that in Keynote? Alex's post gives the steps.

JavaScript and Expense Reports

2010-11-07T13:44:00.000-08:00

This is a loosely-connected collection of thoughts stemming from the recent Strange Loop conference and a book purchase.

Background

For years now, I've known that thoughtful developers:

separate the JavaScript language from the DOM and wretched browsers
appreciate JavaScript as a lovely language inspired by (surprise!) Lisp

So, I thought I "got it". Aside from the usual web development, I've even written significant production code in ActionScript in 2003-4.

But I didn't truly learn the language.

It fell into the dreaded Multi-Month Void of Cognitive Decay (MMVCD).

Here's what I mean: I only faced JavaScript every 3-6 months or so. When it did show up, the situation was urgent, and I felt as though I had to re-learn the basics. Previous 'lessons learned' were quickly lost in the fog of war. I gradually associated the frustration of re-learning with the topic itself.

In this sense, poor JavaScript joined CSS and expense reporting software, falling into the dreaded MMVCD, a random window of cerebral entropy lasting between 3 and 18 months.

(However, even in its worst hour, JavaScript was certainly better than either expense reports or CSS, both of which occupy the darkest corners of MMVCD)

Motivation

Many friends have been interested in JavaScript (some in a career-altering way, no less). Many recommend Douglas Crockford's JavaScript: the Good Parts. It is mentioned frequently at conferences and user groups.

The tipping point was this review by Witek Radomski:

I used JavaScript as a garnish for web development... I was afraid of it. I knew I needed to confront the language and learn it properly.

Yow. This person saw into my soul. In fact, that review led to my recognition of the MMVCD.

JavaScript: the Good Parts

This isn't a book review, but: the book is a delight. Minus the appendices, the book is 100 pages in 10 chapters. That is an object lesson for authors and publishers alike! (I would love to know if Crockford faced pressure to add pages.)

What's more, the premise is a winner: a language can contain a beautiful, subset within a complex, (at times) unappealing landscape.

Random Thought #1: Chained Dictionaries

On SE-Radio, someone once joked that Lisp is nothing more than an abstract syntax tree. Funny stuff, and not entirely fair (I believe it is a comic reduction of an earnest point by Paul Graham, though I have no link to support that). Yet there is certainly a grain of truth in it.

My mental model of JavaScript: it has collections of properties. JavaScript does not call them dictionaries; I will. Dictionaries can be chained. A property may be a function. That's it: simple, elegant. Though this is neither fair nor accurate, that idea leaps to mind frequently.

Random Thought #2: Inheritance is an Interface

Scott Bale gave an excellent talk at Strange Loop 2010, based on Crockford's book. During the talk, it struck me: when we learn that a language offers inheritance, it is a fallacy (and audaciously Java-centric) to assume the existence of classes. Classes are merely one implementation of inheritance.

To wit, inheritance is an interface. It is a conceptual contract.

As most will already know, JavaScript offers prototype-based inheritance. This is a different ballgame, but must be understood, if we are to comprehend JavaScript. Crockford banishes the pseudo-class-based inheritance of JavaScript out of the Garden of Good Parts.

(As an aside, Crockford uses the terms 'prototypal' and 'classical'. I think this is a poor choice. To me, 'classical' has connotations of timelessness or an ideal. It took me a long time to realize Crockford doesn't mean to imply that.)

The Upshot

If, like me, you find JavaScript to be in the Multi-Month Void of Cognitive Decay, Crockford's book is a gem. I'll be working through it.

I realize there is now a book on HTML and CSS, but I don't think I have the stomach for it. Ping me when Expense Reports: the Good Parts is available.

Postscript

Be sure to check out the comments for interesting links on JavaScript material by Lambda Loungers.

Strange Loop and Campus Memories

2010-10-17T16:20:00.000-07:00

I've returned from Strange Loop 2010 in Saint Louis.

For photos, presentation materials, and other reviews, check out the Twitter feed.

This year, I'm not writing a full review or even my usual "random walk" through the conference. This is a quick, lyrical appreciation of the vibe. Future posts may include personal insights, one at a time. This is to serve my readers, who (correctly) point out the declining frequency of posts on here.

First Days on Campus

Recall your first days on a university campus, or imagine them from a Hollywood film.

It is a brilliant autumn afternoon. The crisp bite of the morning chill is gone, and the trees display their fiery leaves in the sun.

Everywhere, there is energy. Outside, people hustle and bustle from one building to another. Along the paths and roads, the chatter is constant. Some are merely coordinating the next stop. Where is it? When is it?

But most are sharing ideas. The ideas initially come from respected professors, who set student minds ablaze. Then new thoughts arrive via inspiration; others are borne through rigorous debate. Somehow, they culminate in a virtuous cycle of intelligence and enthusiasm. Like the morning chill, cynicism and defeat cannot exist in this environment. The energy burns them off.

In a season of change, humanity and nature join in a triumphant, zen sense of here and now.

Strange Loop 2010

The 2-day conference brought me back to my first days on campus at grad school.

That was the vibe. In my mind, there is no higher praise.

Postscript

For those not on Twitter, a final shout-out to all my tech friends in Saint Louis and beyond. It was terrific to catch up, and I only wish I had more time to chat. See you again soon.

Reviews

For details, my friends Weiqi Gao and Mario Aquino have posted excellent reviews.

Moving Details

2010-09-25T08:33:00.000-07:00

Background

In case this helps anyone, Here are details about my recent international move. This is definitely a niche topic: no worries on skipping it. I wish I had this info when I started, and want to contribute back to the hive-mind.

Disclaimer

This is a journal of my experience, and not advice. I hope this opens eyes to topics of research, but ultimately, you are on your own.

Although the experience was a lot of research, with seemingly unending paperwork, this post is not intended as criticism toward Canada or the USA. Any comments disparaging either country will be deleted.

Executive Summary

I am a Canadian who returned after working for several years in the USA (legally, on TN Visas). I have no dependents and didn't own a house.

I found that there were three areas of concern:

stuff
finances
car

My stuff was straight-forward. My finances were difficult. My car was surprising.

My Stuff

I went with professional movers for my furniture and books. I packed important things (e.g. guitars) into my car and drove separately.

Following instructions from Canada Border Services, I prepared a manifest that enumerated each box / item, with an estimated value for each. Per instructions, it isn't necessary to list "each pair of socks". My approach was to generalize clothes and books per box, but to list electronic equipment and guitars separately.

The list has two sections: stuff in my car and stuff "to follow" (that is, on the moving truck).

I arrived at the border before the truck, and showed the Canadian border guards the list. I paid duty on the vehicle (see below), but IIRC, I was exempt from duty on my belongings, given (a) everything was older than 6 months and (b) I was granted credit for every year that I was away.

Despite having a delivery window of 3 weeks, the movers arrived 6 weeks later. I met them at an airport, which served as a port of entry / customs. I presented my manifest list and also the paperwork I had signed at the border.

The downside of pro movers is the expense and the high likelihood of delayed arrival. I had considered U-Haul but that approach has its own issues, which are obvious.

My Finances

I'm not going into gory details here. My main lesson is that I was wise to check with financial institutions about becoming a non-resident. First, it will be an extremely good test of a brokerage's customer service: it is an exotic question.

From what I can tell, a US resident can certainly have holdings with a financial institution, but upon leaving, there are restrictions on activity. e.g. One cannot make transactions. It was never clear to me if one could simply leave the account open, without doing further trading. Most of my moving research was spent on this question.

Another option is to liquidate. Depending on market conditions, this could be suicidal. For 401K accounts, it is definitely painful and drastic.

A final option, for residents of Canada and the USA, is a cross-border brokerage. They are typically licensed to trade in both countries. However, these brokerages have a niche, affluent market and have the leverage to charge steep fees.

Note that I haven't mentioned taxes. For me, that research lays ahead, due to the timing of my move.

My Car

First, a car is not automatically welcome in another country. e.g. Canada does not accept all US cars. I checked mine against the list at the Registrar of Imported Vehicles (RIV). Thankfully, it is welcome (as most are).

For the Canadian side, I did the following:

Before moving, get a letter from your local dealer that any recall work has been performed on the car, or that it is clear of recalls.
Estimate the value of your car in the destination of your move. This will be used to calculate duty at the border.
After crossing the border, within 30-45 days (check documentation), the car must undergo a federal inspection. The paperwork is faxed to the RIV. The RIV will mail a sticker that affirms the car is formally a Canadian vehicle.
The car must also undergo the typical provincial inspection and registration.

That's some work, but wait, there's more!

There is an American aspect to vehicles: one must contact the American border (at the point of departure), 3 days in advance, to alert them that you are leaving the country. They want VIN, title, etc, faxed to their office.

I discovered this about a week before my departure. Be sure to verify that they received the information. Vehicle titles are a challenge for a fax machine. There is no charge on the American side. (This is probably a procedure to curb theft.)

Summary

I've already blogged about my personal decision and my admiration for both countries. This post is sheer logistics, without the sentiment.

If I were to do it again, I would consider selling my car before the move, paring down my belongings to an absolute minimum, and choosing U-Haul.

I would also be very careful about investing in a country without a long-term plan (e.g. for retirement).

The ultimate lesson is to do homework, and find professionals that you can trust. Just as you need a doctor and a dentist in life, in this arena, you need a cross-border accountant, an immigration attorney, and a financial planner.

Strange Loop 2010: a rhapsody

2010-08-05T17:00:00.000-07:00

"Dammit, Alex!" Our hero sets down his glass of Crown Royal, and rubs his eyes. The LCD monitors glow, lighting the dark cottage like a cyber fireplace. Outside, a loon's forlorn call pierces the still night, echoing along the moonlit, glassy lake. Soon, it will be daybreak.

With a furrowed brow, our man returns to planning his trip. We know this much: he will visit Saint Louis in the fall. A triumphant reunion with friends and, perhaps, with an unrequited love from Spain (with whom he might have had a torrid fling, if not for an unfortunate Google translation of 'NP-Hard problems', over tapas).

"Focus, man!" The question is: when?

The sentimental choice is mid-November. He could celebrate his birthday with friends. The Saint Louis International Film Festival doubles the allure, providing a perfect book-end to last year, when a wretched Romanian movie gave him startling insight. Late October works too, when cherished non-tech friends will gather to remember a weekend spent, with no electricity and a lone bottle of absinthe, in a Kansas City bus terminal. Nasty stuff, that KC.

And then, there is the rub: Strange Loop on October 14-15. Our hero is torn. It would be great to see his geek compadres again, and Alex Miller has assembled a line-up that is a tech Murderers' Row. But, the timing is tricky. As are the logistics. There are other choices: SLIFF, Halloween, la mujer! There are a dozen reasons why it just won't work!

With drink in hand, he rises to his feet and looks down at 'Coders At Work', laying open on the desk, radiant in the cyber glow. Zounds: the table of contents reveal interviews with Guy Steele and Douglas Crockford.

Both men are keynote speakers at Strange Loop 2010. Early-bird registration ends August 6th.

"Well done, sir.", our hero smiles. "Checkmate."

Settling In and Spooling Up

2010-06-28T15:39:00.001-07:00

This post is overdue, but as a shout-out to friends to whom I've not yet emailed, I've made it to eastern Canada, even if my belongings have not -- yet.

It has been a long journey, from a touching series of farewells in Saint Louis, though the ~1800 mile drive that touched 11 states and 2 provinces.

Though not completely 'settled in' just yet, I am definitely spooling up: I've been at the new gig for over a week now.

Because of the job search and subsequent move, there is a fairly large backlog of ideas for blog posts. We'll see how far I get, but I suspect the next post will be a public service to a distinct niche audience: detailing the aspects of an international move. I'll post some of the facts that I wish I had known when I started.

A New Chapter

2010-05-31T07:32:00.000-07:00

For most of us here being islanders is a terminal condition.
But those who go away aren't cured.
They simply die of the same ailment on alien soil.

-- Frank Ledwell, The North Shore of Home

After more than a decade in St Louis, and much introspection, I am moving back to my home province, Prince Edward Island.

My friends and family know that I have been torn between (a) terrific friends and an increasingly hot tech scene in St Louis and (b) the distance from family and the tortures of holiday air travel. Thankfully, the burgeoning tech community on PEI has opened doors for me, and I've summoned the courage to recognize priorities outside of my career.

I'm tempted to thank individual people in St Louis, but the list is simply too long and I'll be sure to miss someone. Though there is some overlap, here are some key groups, relating to tech:

I've been attending the St Louis Java User Group for many years, and countless presentations. It is such an enduring fixture in St Louis, and I appreciated the sponsors (and frequent speakers) so much that I applied to work there (see below).

As a big Groovy fan, I've enjoyed the Gateway Groovy Users Group. It terrific to have a dedicated group for Groovy and Grails, and the organizers are first-class.

The biggest splash in the last few years is, undoubtedly, the Lambda Lounge. Some wondered if the St Louis area could support a user group dedicated to eclectic, hardcore nerdiness. The answer is a resounding yes!

A big thanks to everyone at OCI / Advantage. I've grown so much in terms of interesting clients, writing, giving presentations, and from observing my colleagues do the same. I love the college-style culture, and am simultaneously inspired and humbled by your talent.

Most of all, thanks to my friends from the various gigs, user groups, conferences, and pub nights. It has been a great run, with some fun stunts along the way.

I plan to visit regularly, so between this blog, Twitter, and return trips, we'll stay in touch.

To the geeks in the Maritimes: please get in touch! I'll be eager to meet up and talk tech.

ps. The quote is by the late Frank Ledwell, a former English prof at UPEI, and a beloved Island poet. I found the poem both charming and haunting when I first read it, in 1991, and have never forgotten it.

10 Thoughts as an Attendee at NFJS

2010-05-24T19:24:00.000-07:00

(Full disclosure: I work for a sponsor of the Gateway Software Symposium and, this year, was also a speaker).

Background

Rather than write about obvious trends (e.g. document databases are hot) or review big name speakers (how can you not know Ted Neward, Neal Ford, and Ken Sipe !), I thought I would write some quick thoughts about GSS 2010 as an attendee. Another post will be about my initial stint as a speaker.

Use Evaluations

Jay Zimmerman made an excellent point: when speaking, take every opportunity to use evaluations at your talks, including your local JUGs. If your JUG doesn't have evals, then make your own!

LiquiBase and My Team

I really enjoyed a talk on LiquiBase and Agile DB Development by Tim Berglund. He described a category of problems / solutions with which I was only barely aware. He highly recommends the book Refactoring Databases, and I'll definitely check it out.

Interestingly, when describing the talk to a close friend and colleague, my friend told me that his team was using LiquiBase. I was stunned. We work on the same floor, and yet I didn't know this. We all know conferences bring people together, but often it is within the same department.

Hawthorne Effect / Psychology

Several talks reminded me of how much psychology (and neuroscience) comes into play in software development. As one example, check out the Hawthorne Effect (as explained to us by Neal Ford). What's more, use it on your team, and in your personal life. e.g. For me, I exercise more often if I track my distance / rate, so that I know where my personal trend is headed.

Visualizing Code

Neal Ford gave a talk that listed a dozen tools for viewing code in weird and wonderful ways. The best part is that I wasn't familiar with any of them. It feels like a violation of intellectual property to enumerate them here in a garish list, but as one example, check out Code City.

Books == Quality

A former mentor of mine said that he has noticed that he can tell the best developers by what they read. Always ask your friends what they are reading. Seek recommendations everywhere. Some favourites from the NoFluffers are Predictably Irrational and the Design of Every Day Things.

Virtualization Imperative

Virtualization is going to be commonplace. I realized the following, during a excellent talk by Pratik Patel: with free options for virtualization software and the OS, we have no excuse not to try this at home. We should experiment so that we are ready for the inevitable in a corporate environment.

Fault Lines

Tim Bergland gave a talk on Decision Making that included team dynamics. He used an analogy of fault lines to represent the divisions that can occur across teams. Wonderful stuff. This is precisely the phenomenon that happens between DBAs and devs, testers and devs, and, of course, managers and everyone else.

I don't have time to explore this idea further, but are there hidden fault lines? Do we intuitively partition our teams across sociological lines that, strictly speaking, do not belong in the workplace? (e.g. age, religious views, political stance). It's something to consider, and the answers may not be pretty.

Failure

Brian Gilstrap asked the Expert Panel about specific instances of failure. It was interesting to see how the panelists chose to define failure, and how the scope could range from the individual, team, or organization. Though good stories come from brilliant innovation or clever design, the best tall tales come from failures.

Nate Schutta made a great point: civil engineers around the world will study a report on why a bridge collapses. Though proprietary code is an issue here, why don't software engineers do the same?

Don't Fear Reinforcement

I noticed several friends attended talks on subjects with which they were familiar, as they wanted to pan for a few more gold nuggets from the talk. e.g. James Carr gave a great talk on Mockito. I've been using Mockito for some time now. There is an argument for me to broaden my horizons, but I went to the talk and had some revelations about Mockito's Spy object.

10 Year Arc

I attended NFJS shows in St Louis for nearly a decade, and almost always in the same venue. It's become a fascinating reference point as the years go by.

Technically, if we had an animated graph across that timeline, you would see some technologies appear and disappear (XSLT), while others grow strong (Grails). Some of them are continually berated and yet refuse to die (Swing).

I've seen speakers make a point in a given conference room, where Dave Thomas made the same point, possibly in the same room, years before. I've seen Mark Volkmann ask the expert panel "what is the next big thing?" circa 2004. Today, we would find the answers either quaint or downright prescient (re: languages on the JVM).

There is a piano in the lobby of the Marriott West. Once, I wondered how marvelous it would be to play it. Though barely an intermediate, I now brazenly sit down at it, and gleefully bang out a hamfisted tune.

Over the years, that piano has seen a lot of speakers, attendees, trends, and technologies.

But mostly, it has seen changes. I will remember it fondly.

No Fluff, Just Stuff in St Louis

2010-05-19T19:47:00.001-07:00

Like James Carr, the upcoming Gateway Software Symposium will be a mix of new and old for me: I've attended many (probably every one of them) over the years; this year, I will be speaking on Gradle.

I've been studying Gradle exclusively in the past months, and look forward to exploring my findings in the session. I'll have gone full circle from a heckler in the back (not really) to being up front and center.

Just as much, though, I look forward to the energy from the speakers and the crowd. I have always been an unabashed fan of NFJS: it was an excellent idea right from the start. Be sure to say hello at the show....

Just Do Something

2010-05-02T18:54:00.001-07:00

Hello from CtJ HQ! It has been a long spell since posting. There are reasons why, but mostly pedestrian excuses.

As many do, I have spells when I break out of my usual rhythm. Usually, this pertains to exercise or practicing a musical instrument.

In these cases, I've learned to "just do something".

For example, if I'm out of my routine for the gym, the experience of being a (former) triathlete makes me feel like my first work-out should be a dandy. This leads to pressure, which causes fear, etc. The "deal" is that it is OK to just run a couple of miles, at any pace I want. The true goal is to start again, with a pleasant experience; the means to the end is: just do something.

This simple idea has helped me tremendously in the past, and now via this post.

Rosetta Stone for Java Build Tools

2010-01-27T19:20:00.000-08:00

A previous post introduced the idea behind Easter's Eggs: quality examples that I'll use for reference and am sharing with the world.

My latest effort is a modest work in progress. The idea is to build a Rosetta Stone example for Java build tools. In particular: Ant, Ivy, Maven, Gant, and Gradle.

It's called Easter's Eggs for Build Tools and is hosted on GitHub. (You can download without an account.)

My main motivation is that most build tools have solid examples, but when dealing with build issues, chances are, I'm in a hurry. I don't have time to understand some new, contrived example. And for new tools, I don't care about bells and whistles. I just want to see something that works!

Consequently, I decided to develop the same examples across different tools.

Currently, it features only a simple project containing a POJO, a Hibernate mapping, and an integration test. This project is expressed in several forms, and the test should pass in each one. (Consult the respective README.txt)

I don't envision many more projects, but I'd like to develop a multi-project example and probably a war file.

Some of the examples took serious effort, as I'm a newbie to some of these tools. I sincerely hope this helps someone who is looking for a foothold.

Feedback is always welcome.

Syntax Highlighting on Blogger

2010-01-25T18:32:00.000-08:00

A big shout-out to your friend and mine, Ken Sipe, for his recent post on adding syntax highlighting to Blogger. (And many thanks to Alex Gorbatchev for the original work.)

Some notes:

My experience matches Ken's, in that it is best to put the links just before the </head> tag.

The highlighting doesn't take effect when writing the post, or in preview mode (presumably because the templating engine isn't emitting the head section). You have to publish it.

One trick for initial testing is to add highlighting to an older post that contains code, and republish.

Finally, don't limit yourself to the list on this excellent post. Chances are, your language has support (e.g. Groovy).

5 Words on Test Organization

2010-01-25T18:22:00.000-08:00

Instead of this:


void testCallListReportData() {
   controller.programService = programService
   def program = Program.findByName(Keys.PROGRAM_ABC)
   assertEquals Keys.PROGRAM_ABC, program.name
   def student = Student.findByLastName(Keys.STUDENT)
   assertEquals Keys.STUDENT, student.lastName
   mockParams.id = program.id
   def reportData = controller.callListReportData()
   assertEquals Keys.PROGRAM_ABC, mockParams['PROGRAM_NAME']        
   assertNotNull reportData
   def thisMap = reportData[0]
   assertEquals student.fullName(), thisMap['STUDENT_NAME']
   assertEquals Keys.CONTACT_EMAIL, thisMap['CONTACT_EMAIL']
}

Prefer this:


void testCallListReportData() {
   controller.programService = programService
   def program = Program.findByName(Keys.PROGRAM_ABC)
   assertEquals Keys.PROGRAM_ABC, program.name
   def student = Student.findByLastName(Keys.STUDENT)
   assertEquals Keys.STUDENT, student.lastName
   mockParams.id = program.id
  
   // test
   def reportData = controller.callListReportData()
  
   assertEquals Keys.PROGRAM_ABC, mockParams['PROGRAM_NAME']        
   assertNotNull reportData
   def thisMap = reportData[0]
   assertEquals student.fullName(), thisMap['STUDENT_NAME']
   assertEquals Keys.CONTACT_EMAIL, thisMap['CONTACT_EMAIL']
}

Easter's Eggs for Groovy

2010-01-11T10:20:00.000-08:00

This blog receives many hits for "Groovy file" and "Groovy IO". To help newbies with Groovy, and for my own reference, I've started a small project over on GitHub called Easter's Eggs for Groovy. (Note: You don't need an account to download the project.)

No, these eggs are not hidden tricks to unlock functionality. Define an "egg" to be a small example to get you started with an idea. This project has some basic eggs for Groovy. It is by no means exhaustive, but does offer the following:

eggs for Groovy collection methods, regex's, and IO
examples of testing in Groovy. In fact, most of the code is in the tests!
a build structure using Gant

Please let me know if there are any examples you'd like to see, or if this is useful for you.

Grails tip for internet connections

2010-01-08T10:19:00.000-08:00

I encountered the following issue when configuring Grails, and am posting in case it helps anyone via The Google. Thanks to Matt Taylor for the info.

If you receive this error message for a grails command:


Error reading remote plugin list [Connection timed out: connect], building locally...
Unable to list plugins, please check you have a valid internet connection:
Connection timed out: connect

you may think the plugin site is down. Probably not: it's more likely that you're behind a proxy server. Try this command:


grails set-proxy

To determine the values requested, do the following steps:

In FireFox, go to Tools -> Options -> Advanced -> Settings and find the value for 'Automatic proxy configuration URL'
View the URL and determine the values used for your IP

Enjoy!

Friday

2009-12-19T17:11:00.000-08:00

A recent post has been deleted from this space. It was a sincere, if boring, piece, by a guest writer, with an underlying message on the importance of logging out of all browsers on shared computers, even when at home on holidays.

In its stead, I offer this: my thanks to you, the CodeToJoy nation, for another fun year, and best wishes ahead in 2010. If you are travelling, may you be safe and on time. Keep laughing (often, that's all you can do.)

On Analogies: Mozart, Mondrian, Kandel

2009-12-06T18:31:00.001-08:00

After the Strange Loop conference, Michael Galpin wrote (as an aside) that he doesn't like analogies to software engineering.

I've been meaning to write for awhile; this post celebrates analogies and provides a few of my current favourites.

Background

I've been making analogies for a long time. My favourite teachers made them, and as an undergrad, when tutoring others in calculus, they came naturally to me. To this day, I'm always trying to frame problems in some other context, either to non-IT people or domain experts. I'm convinced that there is a biochemical reward for nailing one. E.g. when another techie says "that's exactly right". (The reward is probably a cousin to that of making an excellent pun.)

To be fair, Michael talks about romantic analogies to software engineering, whereas many of my analogies have the granularity of problems in software engineering. But no matter: be it an analogy, metaphor, or allegory, you can count me in. This is especially true for keynote presentations, which should be thoughtful and imaginative. If a tech talk is a pop song, a keynote speech is a symphony. (There I go again, but hey this blog was started on a musical analogy.)

Now, I happily grant that analogies have their place. If you're working at a start-up, frenetically trying to hit some deadline, then no one wants to hear how your design was inspired by a Chopin nocturne. There's a time for straight-talk. I'm with Michael there.

With that background, here are some ideas that have lit my fire lately. They may or may not be pure analogies, but they have sparked my imagination.

Mozart's K 522 - A Musical Joke

Wolfgang wrote a piece, A Musical Joke (K. 522), that satirizes clumsy composition. It intentionally uses common "mistakes" made by inept composers.

Ever since the vending machine shoot-out at the Lambda Lounge, I've wanted to write a spoof version in Java: my own modest K. 522. Its ostensible goal is a functional style of the vending machine spec: no side-effects or mutable state.

However, in my spoof, the poor author goes off the tracks, because all computation is done by throwing checked exceptions. The program will be absolutely gorgeous in its wretchedness!

I've started this project, but unfortunately it quickly became so painful that I couldn't bear it. However, I hope one day to have an entire theme of K. 522 projects over on github.

Mondrian and De Stijl

I'm no connaisseur of fine art, but I've taken a class or two and enjoyed learning about its history. My major discovery (blogged elsewhere) is that much of art occurs in reaction to a prior context. It dawned on me that at a gallery, a new exhibit can often be a major "screw you" to the establishment of the time. What appears to be a simple painting, when viewed in context, can be startlingly rebellious or profound.

Consider this:

'Picture by Hay Kranen / CC-BY'.

This image is inspired by Piet Mondrian's work, a founder of the De Stijl style (also known as NeoPlasticism).

As a quick primer on De Stijl: it's a Dutch art movement founded circa 1918, intended as an intellectual response to the chaos of war. As noted in their manifesto (!), the artists sought to find inner harmony within themselves and universal laws of simple geometry.

I have a few thoughts on this. The obvious one is apparently everyone needs a manifesto, from artists in 1918 to software artisans in the 21st-century (exhibits A, B, and C).

The second reaction, from a software standpoint, is REST. Agreed, it's clearly insane to compare WS-*, SOAP, etc with the horrors of World War I, but consider how simple this URL is:

http://esite.com/product/show/1

Call me crazy, but I genuinely sense a kind of abstract connection to the orthogonal lines in Mondrian's work, especially against the busy, noisy chaos of Web Services. Imagine standing outside a giant, enterprise-y WS conference with that URL on a large placard. Reaction to a prior context.

Finally, recall that the REST movement similarly came from an explicit intellectual genesis, famously being a PhD thesis.

Note that, above, I said abstract connection: this is not equating art to software engineering. They just rhyme for me, in some weird way.

Kandel and Aplysia

I'm currently reading an excellent book, In Search Of Memory, by Eric Kandel, a Nobel-Prize winner in neuroscience. Part biography, and part history of his scientific journey, it is wonderful.

In a key chapter of his career, Kandel sought to understand the biological mechanism behind short-term memory. In the early 1960s, the conventional wisdom favoured mammals over invertebrates for research. The thinking was to stay as close to the goal (the human brain) as possible.

Kandel went in the other direction. He wanted a reductionist approach that explained short-term memory in a minimalist setting. He ultimately chose a sea slug called Aplysia Californica. This species matched his instinctual desire to keep things simple: Aplysia has a small number of neural cells, which are quite large (i.e. easier to study). It also has a simple reflex (withdrawing its siphon, and inking) which ultimately proved to respond to forms of learning (e.g. habituation and sensitization).

It was a wise choice. By 1969-1970, Kandel and his colleagues had discovered several major principles of the cell biology of learning and memory. In essence, they built a entire conceptual framework for learning and memory, and were able to verify it in the "laboratory" of the Aplysia. The humble sea slug was a gold mine for his career and for science.

Although completely glorious in its own right, my take on this for us, humble software developers, is this: Kandel not only discovered terrific scientific ideas, but provides an object lesson on how to do research. This is the absolute embodiment of KISS.

For example, imagine that you are struggling with a concurrency concept in a large project. Or the precise mechanism of transaction propogation in Spring. Or the dreaded gridbag layout in Swing. You may be resistant to starting a new tiny project -- your very own Aplysia -- for the sake of isolating the exact issue of concern.

"Who has that kind of time?", you may cry, as I often have. Well, if you want the real answer, make the time. Think of Kandel. Reduce, reduce, reduce: KISS.

The Upshot

Though I can enjoy art and music as pure pleasure, I love finding parallels between disparate subjects. Often, the best way to convey these psychic fingerprints are through analogy. So, sign me up.

As mentioned above, I realize these are abstract connections. I don't fancy myself as a composer, artist, or neuroscientist. I don't equate my career to such enterprises to make it more glamorous. Thankfully, I already find my career to be glamorous, as it grants me elements of both art and science.

All I'm saying is: a torus is like a mug.

Career Cultivation and Creativity

2009-11-08T18:52:00.000-08:00

Dean Wampler wrote an excellent article about the importance of cultivating your career, and provides some ways to do so. A thoughtful piece with some great ideas.

In classic piggyback style, I thought I might add some suggestions. I'll keep this brief, as I fear an audience mismatch: those who might benefit most from these kinds of blog posts are the people who don't read blogs. This means, sadly, we may well be yammering to ourselves in a cyber echo chamber.

Developing Experience

Dean suggests trying new technologies at work (testing is a great opportunity), or an open-source project.

One other option is a public repository such as GitHub. In my experience, posting a project on a public server really forces you to dot the i's: you want a good build process, unit tests, clean/idiomatic code and so on. The public nature of the effort removes the laziness that can happen on homegrown "Sunday night" projects.

Another option is to build a website. If you want to learn Rails, then really use it. Hosting is cheap, as a career investment.

You might protest: What would I build? All the great ideas are taken! Well, first remember that you aren't trying to get rich, you're trying to get experience. That said, it will take some creativity. All too often we concentrate on creative technical solutions, but do not apply it to our careers. In this instance, there are lots of ideas: consider a single service site, help a volunteer organization, etc.

If you play it right, you might learn something and make a name for yourself in the process. A friend of mine wrote Online Task List: he learned a ton about web development and now has hundreds of real-life users (including me).

Use Technology

Everyone talks about social media, but there are many other technologies such as screencasting and the mighty YouTube.

As an aside, I am stunned that it is 2009 and I see 6-page résumés: each job has the same lengthy details, no matter if it is a senior position in 2008 or an intern level gig in 1999. There is a painful list of technologies that includes things like log4j. I realize résumés are tuned for search engines, but no one cares that you know log4j!

What I'd like to see is someone on YouTube standing at a white-board, taking 5-10 minutes to explain the inverse=true concept in Hibernate. Or your definition of unit tests versus integration tests. What is your favourite data structure? Anything! If you're good, you will shine through.

If I were to receive a minimalist résumé with contact info and a URL to your YouTube vid, I guarantee you'll have my attention. (Here, I'm assuming a thoughtful, tailored cover letter as part of the offering.)

The Upshot

In both solving problems and cultivating careers, don't discount creativity.

We are only bounded by our imaginations.

A Random Walk On A Strange Loop: Day 2

2009-10-27T18:27:00.000-07:00

Full Discloseth:

All of this may or may not matter to you: "A Longer Post" is an anagram of "Strange Loop". I live in St Louis, MO. Some speakers and the organizer are friends of mine. I work for a sponsor of the recent Strange Loop conference.

This is a continuation of some thoughts on the conference. See many more resources here.

Hamlet D'Arcy: Groovy Compiler Metaprogramming...

(slides here)

Hamlet gave a splendid talk on the power of manipulating Groovy's AST. As a warm-up to Groovy, he showed a quine: absolutely perfect for this conference. Looking back, I'm surprised they weren't all over the place.

Hamlet's main example was to introduce code into the AST during one of Groovy's compilation stages. I was reminded of a comment on Java Posse where someone said that AOP had to be invented in Java to solve a particular problem, and that the problem simply didn't exist in dynamic languages. This talk exemplified this in spades.

As an aside, Hamlet was a real trooper with the microphone. It was an awkward set-up, but he handled it gracefully. (I tend to get rattled under such conditions, so big props...).

Matt Taylor: jQuery, the Javascript Library of the Future

(slides here)

This talk wins the prize for making me want to a buy a book on the subject. If you haven't seen Javascript for awhile, good news: the libraries are fantastic, with jQuery arguably leading the way.

Matt's presentation and slides (featuring a hall-of-fame Twittch comic) were right on target, but the money maker is the demo. Seriously: check it out now.

It may be simple jQuery in a browser, but it is really a clever layout and a testament to jQuery. Matt showed some snazzy selectors and hinted that you can do more if you know CSS. I maintain that if you don't know CSS, you could use something like this to explore and learn more about it. The demo is a bit like an IDE for the browser. Also, if you are using a giant template system (ahem), then jQuery might be useful to introspect pieces of the HTML fractal with which you must deal.

I'm sold. I hate CSS and a lot of web design but this library looks great.

Michael Galpin: Mobile Development 101...

(slides here)

Michael gave a classic, spot-on talk on 2 major platforms: iPhone and Android. I say 'classic' in the sense that the trade-offs were presented in a balanced and honest manner. This is one talk where I wish there was more time for questions. There were many.

After all, there is a big fork in the road for mobile development, and you can't take both paths. Choosing one is a big decision. I'd especially liked to have heard more about development as a potential side-venture, rather than within an enterprise, and the necessary resources (e.g. accountant, attorney, trademark, etc). Not very techie, but mobile is the new gold-rush.

I respected that Michael didn't proselytize which path to choose: he just laid out the options. I have the high respect for people who can present both sides of a topic without tipping their hand (even if they are passionate in one direction).

Alex Payne: Keynote on 'Minimalism in Software'

I've been somewhat scooped by Michael Galpin (above) on this one: I also give Alex high marks and found his keynote to be really thought-provoking, even if it was disagreement. I may write a critique in later a post. However, unlike Michael G, I do like artistic/musical analogies. If anything, I wonder if Alex went far enough with his analogy.

More later, after the web has a chance to see Alex's talk. The nano-gist: after an introduction to Minimalism (versus minimalism), Alex listed some methods to achieve it in technology (see the slides or this recap by Weiqi Gao).

Regrets and 2nd Chances

I saw some other talks but want to focus on regrets -- actually, second chances -- as the content will be online. I'm looking forward to the Strange Passion sessions, talks by the senseis Jeff Brown and Ken Sipe, and definitely James Williams' talk on Griffon.

The Upshot

Yes, yes, Alex Miller likes nachos. But I once read that he also likes building things, including events, and bringing people together. Strange Loop really was a dandy, and we are all better for it. Congrats! And thanks...

Full Discloseth:

I work for a sponsor of the recent Strange Loop conference. Some speakers and the organizer are friends of mine. I live in St Louis, MO. "Lagoon Strep" is an anagram of "Strange Loop". All of this may or may not matter to you.

Go Steal Porn.

A Random Walk On A Strange Loop: Day 1

2009-10-26T18:27:00.000-07:00

Full Discloseth:

I work for a sponsor of the recent Strange Loop conference. Some speakers and the organizer are friends of mine. I live in St Louis, MO. Finally, I've run "strange loop" through an anagram generator and laughed for hours at the various and sundry output. All of this may or may not matter to you.

As always, all opinions are solely mine, and genuine.

A Random Walk

I'm not a journalist and won't try to report on the conference. Chances are, it would be a futile endeavour. I use the "random walk" title as signal that this post is an Impressionist, personal experience.

The Vibe

I do want to set the scene: the event was held at the Tivoli in University City. "The Tiv" is a 1920s era movie theater with lots of unabashedly glitzy character. It was a marvelous choice and worked out really well. About 300 people attended, cramming the lobby and the facilities: the geek vibe was strong. (There was much more room in the theatres; i.e. during the talks.)

There were also cameras! The talks will be on video, thanks to DZone. I'll post them here along with any links to slides.

Mario Aquino: Zen Mind/Warrior Spirit

(slides are here)

One measure of a good movie is how long it stays with you afterwards. Mario's talk passes that same test. In a lyrical style with captivating slides, he combined ideas from Zen philosophy and a 'warrior code' to forge parallels to agile teams in software development.

Among my revelations:

The struggle of meditation is to quiet the inner voice. Pure TDD is similar, as the inner voice always wants to write 'the real code' first. Testing first is meditation. Perhaps that's why it takes focus.
Team culture is more than the sum of its parts. Like a warrior clan, there is a sense of something larger. Good teams have a sense of the 'common good' (aka convention) and the discipline to stay with it.
I once read about an Allied WW2 bombing squadron that suffered terrible losses over Europe. Despite being decimated, the remaining planes returned to Britain in formation. I think of this often when I work, alone, in a team war room on a weekend.
Mario mentioned Corey Haines, who lives a nomadic existence as a programmer. This reminded several of us about Paul Erdős, a rockstar mathematician who lived the same lifestyle.

Mark Volkmann: Tackling Concurrency with STM

(slides are here)

Mark gave an excellent overview: the pros and cons of lock-based concurrency versus using Software Transactional Memory (STM). I especially liked the open question of whether its time has come: after all, garbage collection took many years to become mainstream. The unvarnished truth is that we don't know, but things certainly seem to be brewing.

Mark examined the details of STM in Clojure, using diagrams to give a sense of the internal representation. It is hard to recreate here, but I left with a better sense of Rich Hickey's position that the time dimension is vital to concurrency (see Hickey's slides here).

Charles Nutter: Ruby Mutants

(slides are here)

I don't know Ruby, but I couldn't pass up a chance to see Charles. He's a class act in the Ruby community and obviously a major force. Not knowing Ruby, I was definitely a stranger in a strange land -- in fact some goons at the door frisked me, finding a Grails book and some Python code in an inside pocket. Not necessary, gang! (also: not true)

Charles mentioned "Java Next" and his criteria for choosing a Java successor. I loved that some popular JVM languages -- claimed by others as Java Next -- did not meet his criteria. He respected said languages but stated, matter-of-fact, that they didn't meet his aesthetic. This is a clear sign that the JVM community is healthy.

He went on to examine two Ruby mutants: Duby and Surinx. There are some compelling slides that compare and contrast these two 'unfortunately named' mutants to Ruby itself. I'm struggling here to capture the essence of this talk, but do check it out: I thought it was fantastic stuff and an object lesson as a presentation, in terms of pace, tone, and code samples.

Bob Lee: Keynote on Future of Java

(slides are here)

There is one aspect of Bob's keynote that I found especially noteworthy, and I'm dedicating this section to it. It was an excellent talk, with lots of interesting material, but this really resonated.

A friend of mine once kept a log, for years, about bugs that he found. Over time, he compiled evidence about software development in a given language. Based on this record, he developed a philosophy towards his coding conventions. (More to come in a subsequent post about evidence-based software practices: it ain't gonna be easy.)

I was impressed at the time, and impressed again by Bob, when he argued for ARM blocks. He began with some Java puzzlers, to show the difficulty of correctly using IO and try-catch-finally blocks. All well and good. But then he reported examinations of large codebases, including the JDK itself: there are plenty of instances where the code does not behave in a strictly-correct manner.

More than Java 7 features, this is the big take-away: when presenting a case to an audience (be it a keynote, or your team), do the research and present evidence. Compelling.

Strange Passions

Sadly, I didn't make it to the Strange Passions track, or the party at Blueberry Hill. However, there was a lot of buzz about the track idea (which is fantastic) and the individual talks. Sounds like it was a huge hit. I hope the passion talks are on video.

More to come, re: Day #2.

Full Discloseth:

All of this may or may not matter to you: "go steal porn" is an anagram of "strange loop". I live in St Louis, MO. Some speakers and the organizer are friends of mine. I work for a sponsor of the recent Strange Loop conference.

A Longer Post.

Ignorance is Bliss

2009-10-12T18:44:00.000-07:00

Like many, I have loved Calvin and Hobbes for a long time. Not that this blog compares, but the spoofs on here are influenced by Calvin's weird, wonderful world where we only bounded by our imaginations.

I recently found a post that contains, my all-time favourite C&H. I probably shouldn't encourage a likely violation of copyright, but I'm weak. I've tried, in vain, to describe this one to people dozens of times. I laugh out loud (especially the visual of frame 5, "I don't want to know about it") every time since I first saw it in the early 1990s.

This comic is such biting satire toward software development that I no longer hang it up at work gigs, lest it is interpreted as some kind of protest.

The genius is that it has no ties to IT: a friend once commented that her mother, a judge, had it laminated and placed prominently on her refrigerator. Truly philosophical, it is timeless and universal.

I love Dilbert too, but if I had to choose: you can keep it. Give me Calvin and Hobbes, please. I only wish that Watterson would come out of retirement and do a few more, whenever his muse strikes.

The Emperor's New Prose: Duct Tape Blogging

2009-09-29T04:31:00.000-07:00

I've been a fan of Joel Spolsky's for a long time. He has written some excellent, influential stuff. Unfortunately, his latest blog entry, The Duct Tape Programmer, falls short of the mark, and has sparked some debate throughout the web.

I wasn't going to respond until I saw supportive tweets such as 'thoughtful, provoking essay'. (Damn you, Twitter, now you've drawn me into this.)

Joel's piece isn't a thoughtful, provoking essay. This one is, but Duct Tape Programmer is just a quick rant. Like I said, I'm a fan of Joel, but let's not be sycophants here!

The Gist

I freely admit that I haven't read the book, Coders At Work, but here is Joel's article. Here's my summary of his points:

Keep things as simple as possible, but no simpler.
'Simple as possible' is context dependent.
It's the features, stupid.

The first item is a favourite quote of mine, often attributed to Einstein (though I have not verified that). An example in software: your webapp may not need GWT on a full blown J2EE stack, but you'll probably need a database. The first case is not simple as possible; yet without a DB, it is too simple.

His other point is that the definition of 'simple as possible' depends on circumstances: the context of a start-up company is much different than a mature app at a large enterprise. Naturally, the start-up will have a much more stringent definition of 'simple as possible'.

Finally, Joel admires those that concentrate on features, and who ship code.

The Surprise

I agree with Joel. His thesis isn't particularly original, but as I see it, it is virtually indisputable.

However, I take issue with some of the details. My point is that this just isn't a thoughtful post.

At Issue: What is Duct Tape?

Joel gives lots of examples of complex technologies: multi-threading, COM, and CORBA. Hard stuff, no doubt. He goes on to write:

... any kind of coding technique that’s even slightly complicated is going to doom your project.

However, against the backdrop of extremely complicated technologies, he doesn't define 'slightly complicated'. There's not even an example! From what I can tell there isn't even an example of duct tape!

Is OO slightly complicated? AOP? Functional programming? Transactions? Languages without garbage collection? with garbage collection? The notion of 'simple' is much more nuanced than Joel implies.

This rhetoric reminds me of the straw-man argument and definitely is the logical fallacy of false alternative. Joel assured me on Twitter that the COM example is real, and not a straw-man. I'm sure it is true (I didn't think Joel was being deceitful), but berating the most extreme case with no comment on the middle-ground does not make a thoughtful article.

At Issue: Design Patterns

Quick -- what is the most commonly used design pattern, using the vocabulary of the seminal work, Design Patterns?

I don't know, but I'd wager that it is the Iterator. In fact, if you work with Java, it is so common that it may not 'count' in your mind. And yet, there it is: a freaking commodity, no less.

Joel takes a shot at a 'Design Patterns meet-up'. It's true that people can go crazy with esoterica, but again, nuances are lost with broad strokes. It is easy to deride the architecture astronauts!

There may well be times when a design pattern is the right fit, and it is our job as professionals to be prepared. True -- we have to be intellectually honest and disciplined -- but that doesn't mean we shouldn't be informed.

At Issue: Unit Tests

Hoo-boy, Joel fired a shot across the bow of the agile ship. A brave man.

I'm a big fan of unit testing and am convinced that they helps us make better software. However, if the context is a start-up in an ultra-competitive space, and we are racing for the '50% good' mark, then I agree that unit tests would slow things down. If I were in that environment, I would shower every 2 hours just to get the smell off me.

The issue here is that most of us are not in that context, and the post implies that unit tests are used for 'endless polishing' to get to the '99% sparkling' mark. That's just bogus.

Unit tests are the first client of any software. They find bugs. They highlight problems in an API. They serve as executable documentation. They get us to the X% mark faster, where X is way higher than 50 and not as obsessive as 99. Most projects are shooting for X.

The Upshot

We all agree that simplicity and features are of paramount importance. We all agree that we shouldn't listen to architecture astronauts with high-falutin', ego-driven schemes that are not appropriate for the situation. As usual, the devil is in the definitions (what is appropriate?).

But to the Twitterverse: just because an excellent writer wrote a piece, it doesn't make it excellent. Call them out, when they have no prose, and write your own 'duct tape post' instead of broad, incendiary brush strokes.

STM and Clojure: An Article Recommendation

2009-09-14T18:45:00.000-07:00

Your friend and mine, Mark Volkmann, has written an excellent, thorough article over at the OCI Java News Brief (I work for an affiliate of OCI).

The article first places Software Transactional Memory (STM) within the milieu of other concurrency techniques. I especially like the emphasis on transactional, as I found that as a stumbling block in the past. (It does not necessarily mean a database!)

The article goes on to work though some serious study of STM in Clojure. Great stuff....

PostgreSQL and Unicode

2009-09-14T18:30:00.000-07:00

I ran into this recently and thought I would post it, just in case in helps someone.

In PostgreSQL 8.3, the chr() function accepts a Unicode codepoint. This is useful to insert (or in our case, correct) Unicode strings.

You might think that this feature has been around since... version 6, or 7, or surely 8.2 ?

No. Be careful: the documentation for 8.2 mentions only ASCII.

Vending Machine: A DSL in Groovy

2009-09-13T17:16:00.000-07:00

In a previous post, I explained a modest example of the Vending Machine in Groovy. I've since taken the code and tried my hand at writing an internal DSL.

I'm a relative newbie to internal DSLs, but I've pushed my example up to GitHub (here). (This post is light on explaining the details, since the code is available.)

Observation #1

The best discovery is the magic of disappearing code. In this example, the main program simply evaporates and becomes this:


// load the DSL engine/rules
def dslEngine = new File("${args[0]}").text

// load the command input
def input = new File("${args[1]}").text.toLowerCase()

// dslEngine creates 'machine', which accepts the input:
def dslScript = " $dslEngine ; machine.accept { $input } "

// let Groovy do the rest!
new GroovyShell().evaluate(dslScript)

Amazing! There are 2 input arguments to the program. One is the DSL "engine" or context. It looks something like this:


class Machine {
   def machineState = new MachineState()

   def service(def coinList, def inventoryMap) {
      machineState.availableChange = new MoneyState(coinList)
      machineState.inventoryState = new InventoryState(inventoryMap)
   }

   def getN() { machineState.addInsertedMoney(MoneyState.NICKEL) }
   def getD() { machineState.addInsertedMoney(MoneyState.DIME) }
   def getQ() { machineState.addInsertedMoney(MoneyState.QUARTER) }

   def getCoin_return() { machineState.insertedMoney = MoneyState.ZERO }

   // snip
}

The other argument is the set of commands. For example:


SERVICE ([50, 50, 50, 50], [ [N:'A', P:'65', C:'10'] ])

VERIFY "[50, 50, 50, 50] [0, 0, 0, 0] [ [N:'A', P:'65', C:'10'] ]"

Note that the SERVICE command looks like a method call, with parentheses and a comma. That's because it is a method call. Similarly, VERIFY is as well, though no parentheses are necessary for the single string argument.

The other commands are simpler:


N ; D ; Q ; a$ ; COIN_RETURN

These are direct method/property calls as well (e.g. machine.getN()).

Observation #2

Articles on internal DSLs often talk about the contortions that one must go through to simplify the syntax for the end-user. Often, one uses techniques that would otherwise be considered poor style. (Venkat Subramaniam jokes that "designing the DSL" is "finding the right tricks").

I discovered that as well. In Groovy, it is relatively easy to have a decent DSL, but there is a never-ending desire to improve upon it. In the current version, I ran into a wall for using the dollar-sign as a token (see the compromise above: quoting that character in this post is giving Blogspot fits). Along with the parentheses on SERVICE, this pains me. I literally think about it while running on a treadmill.

Observation #3

In the first example, I adopted a file based approach for the input, over an interactive command-line. This has paid off in spades, because my suite of input files act as acceptance tests. Morphing the Java-esque example into a DSL was considerably easier with the existence of those files.

The upshot

With the right support and on the right scale, internal DSLs are terrific. For example, parts of (or, all of?) Grails and Gant are internal DSLs and I love it.

On a smaller scale, I'm not so sure. I'm still disturbed about the issue of Domain Specific Error messages. That is: can a domain expert (without development skills) really handle the power of an internal DSL (including the errors)?

Either way, internal DSLs are undeniably a fun exercise and a great way to learn more about a language.

Groovy Console App and WIDE

2009-08-30T18:38:00.000-07:00

In April 2008, I blogged about the WIDE: web-enabled IDE. I wondered if web tools might augment some of the standard stuff available in the IDEs.

(I realize many have 'scratchpads' but I wanted something more. Also, by environment, I don't mean a single app).

In particular, I've thought about a website dedicated to string and regex utilities. Whenever I find myself writing a little script to parse a data string, or to toy with a regex, I always think "there must be a better way".

Well, we're one huge step closer: check out the Groovy Web Console, by Guillaume Laforge.

It laughs at basic string utilities:


def s = "does this string fit into a 32-char column?"
println s.size()

And provides a test-bed for regular expressions:

(Note, this is a Java-Groovy hybrid. It's only somewhat 'Groovy'. Making it Groovier is left to the reader)


import java.util.regex.Pattern

def s = "1 - 314-867- 5309"
def p = Pattern.compile(/.*1.*(\d\d\d).*(\d\d\d).*(\d\d\d\d).*/)
def m = p.matcher(s)
if (m.matches()) {
  println "area code = ${m[0][1]}"
  println "exchange = ${m[0][2]}"
  println "digits = ${m[0][3]}"
}

Count me in... I'm definitely going to have this site at hand in my environment.

The IDE is a Browser: Neuroscience and Language Design

2009-08-30T17:23:00.000-07:00

Lizard Brain Web Design

Last winter, I saw a great talk by Scott Davis called "Lizard Brain Web Design". The theme was to apply psychology and neuro sci ideas to web sites, and to explain why simplicity and good design can really work. For example, we want the site to stay "out of the way" so that the users stay in a primal, "lizard" mode of consciousness with respect to the site. In this way, they can concentrate on what matters.

During the talk, I remember thinking that all of the principles discussed apply to more than surfing content on the web. They also apply to surfing code in an IDE. That is, topics such as:

Whitespace is a critical aspect of design
Group related items (locality of reference)
Our minds can only stack N items (N = 7 ?)
Principle of least surprise

apply just as well to our APIs, our code organization, and coding conventions.

For months now, I've wondered if there were studies that applied neuro sci to developers.

Subitizing

Let's play a game: as you add a parameter to a method, how many parameters triggers your sense of "this is too many -- I need to refactor this".

Seriously, go ahead, think of a number, N, for your threshold.

You probably said N = 3 or 4. True, that's what everyone says, but here is one reason why. The delightful book Mind Hacks discusses subitizing (item #35): given a set of N objects, where N is 4 or less, we process counting in a much faster way. The book claims 250 ms for the first 4 items and a full second (!) for every 4 items after that.

There is debate as to how this works (see Mind Hacks for academic references), but one conjecture is that when N <= 4, the "counting" is a side effect of visual processing: i.e. it is done by the lizard, reptilian level of the brain. When N goes past 4, we have to do some work.

Now, let's be clear: the book talks about counting shapes. Stars, circles, beads on an abacus. I have no idea if this applies to Java or C# parameters.

But I'm willing to bet money that it does.

Eye-Tracking and Variable Names

This article came across the transom recently, and dovetailed with the above ideas. The gist is that the researchers used scientific techniques (e.g. eye-tracking) to evaluate productivity of programming styles.

The claim in the paper is that the Scala style of using comprehensions is more productive than Java's iterative loops. Also, for small code blocks, well-named intermediate variables may not matter.

I didn't read the paper, and I have no idea of the validity of the science. However, I find the approach to be very fascinating. I'm sure scientific methods have been used for a long time with respect to lines of code, and productivity, but I wonder if neuroscience will have a future impact on language design?

It would be fascinating to see if researchers start hooking up developers to functional MRI machines, to see how the brain works while coding. (I know that my amygdala lights up when I see a 80-line method!)

The Upshot

Imagine a geek conference where a new language is unveiled: instead of its design being driven by a sense of tradition or aesthetic, what if its design was modeled on hard evidence from a neuro lab?

Neat stuff.

An Understated Feature in Groovy

2009-08-25T10:09:00.000-07:00

Background

I have worked with Groovy for awhile, but have been averse to one feature: the implicit return of the last expression evaluated. For example:


def getFoo() {
    def foo = null

    if (something) {
        foo = new Foo()
    }

    foo // no 'return' necessary
}

In the above code, I would use return because it felt safer to me. I tended to agree with Eric's post (with respect to explicit returns).

Revelation

I get it now, and it's all thanks to the enhanced collection methods in Groovy.

Consider the collect method. It transforms a list by applying a function. In pseudocode:


[ a, b, c, d] => [ f(a), f(b), f(c), f(d) ]

With that in mind, here's another example:


class Composer {
    def name
    // def era, etc
}

def list = [ 'Bach', 'Beethoven', 'Brahms' ]

// the closure returns the new Composer object, as it is the last
// expression evaluated.

def composers = list.collect { item -> new Composer(name : item) }

assert 'Bach' == composers[0].name

The idea is simply to build a list of Composer objects from a list of strings. As noted in the comment, the closure passed to collect uses the implicit return to great effect. At one time, I would have taken 3-4 lines to express that idea.

But now, this code is not merely concise: it is truly elegant. Very reminiscent of other languages such as Python.

The Take-Home Message

There are many lists of excellent Groovy features. However we rarely see 'implicit return' listed. I'm a fan: it greases the wheels for other features.

I realize it is available in many languages: I just haven't used it in Groovy. I suspect in a few weeks I won't be able to live without it.

The Case for Grails

2009-08-17T17:54:00.000-07:00

David Jacobs, a friend and colleague, posted a comment in response to other comments on a previous post. The comments focused on scaffolding in Grails.

I thought it was worthy of a full-blown post, and he has kindly granted me permission. David's thesis is that there is much more to Grails than just scaffolding and quick demos.

By David Jacobs:

I've now been using Grails on my primary project for about 16 months (not just toying with it--this is at my "real job" on a large project for one of the 50 largest companies in America). My appreciation of it has continued to grow, and I have complete confidence in it as an appropriate choice for 95%+ of business applications.

Scaffolding is NOT a primary benefit of Grails. It enables cool 5 minute demos, but the real world benefits of Grails are much deeper. There are simplified (auto-wired) conventions, built in tools, or plugins for nearly every aspect of web development. This enables a massive increase in productivity by enabling and encouraging clean solutions that don't re-invent the wheel. Perhaps even more importantly, this keeps the code lean, which is very important for long-term maintenance, refactoring, and preventing "sleeper defects" that tend to hide in bloated code.

I needed to add caching for some web service calls to improve performance: 11 lines of code (entirely declarative).

To meet a versioning requirement (lock, copy as new revision), I needed to implement deep cloning of a persistent domain tree with child associations (mostly collections) five levels deep, with multiple branches, touching about 30 persistent objects. Some needed to be copied by reference (for example, a createdByUser association), and some cloned as new (recursively deep cloned). My implementation is completely generic and won't require changes if the domain model is changed. Pass the method a domain object instance, it hands you back a copy with all of the children copied and properly attached to their new parents. Then you call .save(), and all of the new ids are generated and your database has been updated. This one is a testament to the power of Grails metaprogramming with GORM and Groovy: 22 lines of code.

I needed to create a utility application for mocking a third-party SSO module to enable logins on staging/demo servers. It validates user inputs, makes an AJAX request to the target app with modified request headers to initiate a browser session, and launches it with the intended user now logged in. It uses a proper MVC architecture, the layout is configured with SiteMesh, it has configuration/build management and versioning, URL mapping/redirection to keep it friendly, and log4j integrated and configured. From creating the project to building the WAR file, it took 4 hours.

Point proven?

Vending Machine: A Modest Groovy Example

2009-08-16T19:14:00.000-07:00

I wasn't ready for the Language Shootout at the Lambda Lounge, but I've completed an example of the vending machine, and placed it up at GitHub. (The Language Shootout used a small specification to illustrate languages ranging from Haskell to Fan, and everything in between.)

Highlights

As Lambda Loungers know, these examples are not intended to be submissions for the Turing Award. My example is a modest program, but offers this to Groovy newbies:

The project uses Gant, has test cases, and is fairly complete.
The program accepts an input file, and supports a VERIFY action to "assert" the expected state of the machine. In some ways, the file could be an acceptance test (reminiscent of FIT).
One interesting idea (IMHO) is the execution of data as code. More below.
The example has some internal uses of Expando, and many uses of the elegant closure-based iterations.

Evaluating Data

Consider a command like so:


// N = Name, P = Price, C = Count
SERVICE [5,5,5,5] [[N:'A', P:'65', C:'10'],[N:'B', P:'100', C:'10']]

The pattern here is: Action Coins Inventory. In this example, Coins is evaluated as a Groovy list; Inventory is a Groovy map. This not only simplifies parsing, but affects the architecture of the example. This is hardly new (hello, Lisp!), but a powerful tool.

Java-esque

As with many languages, Groovy supports a wide-range of styles. I've dubbed this example as "Java-esque". Here's why:

Actions (like SERVICE) are objects. This is a nod to Java's style.
It does not use the MOP (see Matt Taylor's example), and is not really a DSL.
It eschews some common Groovyisms (e.g. using an expression as the return value, without specifying the return keyword).

Known Issues

There is no REPL-loop or interaction with the user: only file input. Also, it emits no output per se, and does not acknowledge corner-cases, such as requiring exact change. It simply allows verification of expected state.

Lessons Learned

I love evaluation of data as code. I always have.
Tests are essential with Groovy, and they become inextricably tied to your experience as a developer. This is hard to explain, but because of the dynamic types, the tests cement themselves into your dev cycle in a way that is much stronger than Java. If you cheat with a large method that does not have a test, you'll probably pay for it.
It is important to read the output when a test fails. Often, I just scan it and blithely assume I know where the problem is. This usually leads to frustration, until I realize that the test was trying to help me all along.
As an aside, this is my first project in Git. It is excellent and definitely worth studying.

The Gist

I hope this example helps someone. I hope to write some others, including a full-on Groovy MOP version.

More On Code Reviews

2009-07-29T05:43:00.000-07:00

Your friend and mine, Mario Aquino, has an excellent post on material for code reviews. In classic blogger tradition, why leave a comment when I can write a post?

I agree with his points, and will add my own below. Don't leave a comment saying 'what about unit tests?'. Mario has already covered a lot, so consider his post.

I once wrote about the Universal Issues that affect a software project. They influence this list.

Architectural Harmony

Mario writes about harmony within a source-file. One can expand that to the level of architecture: is this code in the proper place, with respect to the architecture? Is it in the right package/module?

Client-Side Specifics

Does the code follow known conventions for a GUI? e.g. In a Swing app, does it use the event-dispatch thread appropriately? What about i18n?

Server-Side Boundaries

Similar to the architectural harmony above, is the code correct with respect to transactions? concurrency? In a framework situation, these are often handled at an outer scope, but it is important to place ourselves in the appropriate context.

Concurrency is a fun topic because developers have an involuntary reflex: we look upwards to the ceiling whenever asked about multi-threading. Try it, and see for yourself.

Data Is Immortal

As I've said before, versioning is the toughest problem in software engineering, especially given that data lives forever. I've been on projects where data must persist across versions, and in this case, it is vital to give consideration to this aspect during a code review. The gotchas are downright ghostly and ghastly: i.e. hard to see, and expensive.

A Thought On Delivery

It is dangerous to riff through such a list in every code review. It will frustrate the developer and eventually turn people off from asking for code reviews. Though always wise to keep these things in mind, it is important to know when to ask out loud. That is a true art, and can only be gained by experience and a sensitivity to the working conditions.

The Strange Loop (Why You Need To Be In St Louis, Oct 09)

2009-07-28T19:49:00.000-07:00

Alex Miller is organizing a terrific conference in St Louis (October 2009). Check out all the details over at the website.

If you are in the midwest USA, you won't find a better value. Hell, if you are on another continent, you won't find a better value. Come on over.

You may think I'm biased, but check out the session list, and see for yourself. Lots of interesting, off-the-beaten-path stuff by first class speakers, with even more to be announced: I believe the 'Strange Passions' track is still open.

Alex envisioned an esoteric conference that he would like to attend -- and the dream is forming right before our eyes. Check it out!

The Case for Groovy

2009-06-11T10:24:00.000-07:00

This month's StL JUG features Matt Taylor speaking on TDD with Groovy (tonight!).

Like last month's post on Clojure, I'll play law professor, and try my hand at making some arguments that Groovy is the JVM-based language you should learn (if you can only pick one). Like last time, I'm treating this as an exercise, though this is easy, as I am a Groovy fan.

Grails

Long ago, I would say that the first reason for Groovy was its learning curve. That is still important (see below), but my new first reason is: Grails.

I imagine most readers are familiar with Grails: a Rails-influenced web framework that stands on the shoulders of giants -- namely, Hibernate and Spring. The reason I put this item up front and center is that you can make money with it. There are real jobs to be had here, folks. This is a powerful framework with plenty of momentum.

Griffon, GORM, Gradle, Gant, ...

In addition to Grails, there are several other projects that are intimately related to the Java platform. e.g. Griffon brings Grails-like conventions to Swing apps. Straight from Grails, GORM is a DSL for Hibernate mappings. Gradle is a next-gen build system that stands on top of Ant and Maven, without all that nasty XML. Gant is somewhat similar, used by Grails.

The upshot is that the Groovy community is vibrant and doing many different things: surely something will be useful to your project.

The Language

Up to this point, I haven't written about the language itself. IMO, Groovy seems familiar to Java, but with all of the ceremony stripped away. Tremendous amounts of boilerplate are removed: getters/setters are gone; access modifiers have reasonable defaults; regular expressions are trivially easy; and so on.

But there's more: dynamic typing, closures, the Meta-Object Protocol, and other features provide a rich feature-set that is quite different from a merely trimmed Java.

Tools and Testing

Scott Davis has written an excellent book with the subtitle "Greasing the Wheels of Java". That is spot-on. For XML, web services, scripting Java libraries, etc, Groovy is amazingly useful and effective.

One of these aspects is testing (this is where Matt's talk applies). Groovy has tremendous support for unit-tests, including mocks and stubs. The dynamic nature of the language offers a lot of options. Come on out to the talk to see more on this item.

A Gentle Learning Curve, With Growth

If you know Java, Groovy is extremely easy to learn: in fact, almost all Java will run as Groovy. The curve actually goes downhill (in a good, effortless way).

Now, you may dismiss this. As a reader of this and other fine blogs, you may be confident that you can learn any language, thanks. I'm sure you can. The usefulness of the learning curve is that your work (e.g. a utility) is far more likely to be used by other Java developers. In a team environment, that's important. Groovy is unmatched in this regard: it promotes social computing.

That is, if you want it to do so. If you want to do something wild, Groovy allows you to grow into that as well. In this spirit, it is reminiscent of Python: the curve is always reasonable but seems to climb forever. As mentioned, the dynamic nature of the language will definitely, quickly, take you to places that you haven't been using only Java.

The Upshot

I realize there are no code samples in this post. I apologize. Again, this is a quick list of 'arguments' for learning Groovy as your next language on the JVM. There is a ton of material out there, both in free documentation and in books.

(Full disclosure, some of the following authors are friends.)

For Groovy books, start with either Programming Groovy or Groovy Recipes. For Grails books, pick up either Grails: A Quick-Start Guide or the ultimate reference, The Definitive Guide to Grails.

Either way, give Groovy a shot, or come on out to the StL JUG. It is time well-spent.

Haskell and MacRuby at Lambda Lounge

2009-06-04T06:17:00.000-07:00

A quick reminder that tonight's Lambda Lounge features talks on Haskell and MacRuby. Both speakers are friends: they really know their stuff, so it should be a fantastic evening.

For more details, check out this post over on the LL site.

Beware Of Mumpsimus

2009-05-28T19:44:00.000-07:00

In first year of university, I took a class that used the wonderful book Becoming A Master Student. The book had many stories that have stayed with me over the years.

One is the story of mumpsimus. You can read more at the link, but the gist is that a monk used a Latin word, mumpsimus, for decades before discovering it was bogus. Upon the revelation, the monk replied that he didn't care: he had been using it for 40 years and so it would it remain.

In my freshman year, I was an uncomfortable chemistry major. Little did I know that I would be writing about that story many years, later vis-a-vis computer science. (The story itself may go back centuries!)

I mentioned mumpsimus in the comments of the last post. I had speculated on using protected methods over private methods. The feedback was unified in its rejection of the idea, yet I mused that I would probably continue my style. Ouch. That is mumpsimus indeed: after seeking opinions, I launched a heroic denial of the responses and continued on my merry way. Nice.

Another example is the defeat of mumpsimus. Years ago, in C++, I would define class members like so:


class Person {
  int m_id;
  string m_name;
  int m_age;
}

When I turned to Java, I held on to that style -- for about 1 day. When I saw what IDEs could do for automatically generating getters and setters, it became obvious that the prefix had to go. Thankfully, logic carried the day over mumpsimus.

The Upshot

The point here is that we have a name for a particular mindset, and a reminder that it is important to re-evaluate ideas with an honest understanding of our biases.

Java Methods: protected is the new private?

2009-05-27T04:32:00.000-07:00

In code reviews (including my code), when I see a Java method marked as private, I ask if there are any unit tests for it.

Since tests are written in other files in parallel packages, the answer, of course, is no.

I've recently realized that I've obtained the following habit: my methods are either public or protected. I have no use for default or private. I don't like default because I feel compelled to write a comment saying that it is package-level access; I don't like private because of the lack of testing options.

Before you start hammering in comments, here are some thoughts:

This is not for a formal API to another team or other 3rd party. In that case, I would be more careful and rigid. You may argue there is no distinction, in which case: commence hammering.
I realize that protected is not default and that it is leaking encapsulation somewhat. I can cheerily say that I don't care. I like scanning a file and seeing either public or protected.
I'm not trumpeting that I write more unit-tests than others on my team. Just because a method is protected doesn't mean that I've written the tests!

What do you think? Has your style changed over the years, with respect to access modifiers on methods?

The Case for Clojure

2009-05-13T19:16:00.000-07:00

Background

At NFJS shows, a common question is "I only have time to learn one new language on the JVM: which should I pick?".

The easy answer is true: it doesn't matter. Just pick one already!

However, I think people can reasonably ask for more information.

Even though my personal favourite is Groovy, I fancy that, like a good law professor, I could argue a decent case for any of them.

In this post, I'll write a bit on Clojure. To be honest, the title is deceiving: I don't know Clojure, and this isn't a full-blown legal case. I'm really inviting you to some resources (see below).

However, I know enough to see the benefit. This is an earnest post.

Mark Volkmann is giving a Clojure talk on Thursday at the St Louis JUG. Quoting from his intro, Clojure is a dynamically-typed, functional programming language that runs on the JVM.

From past talks, and from Mark's intro, here are some reasons I think Clojure is worthy of your consideration:

Let's Lisp Again, Like We Did Last Semester

If you liked Lisp back in university, welcome back: Clojure has a Lisp-like syntax and style. Both the syntax and functional programming seems new again, in part thanks to Stuart Halloway's book.

Here, 'new' means a shot-in-the-arm to the FP community and a welcoming online scene. Let's face it: it can be lonely when studying older languages.

Got Lisp?

If you don't know Lisp or functional programming, adding Clojure to your repetoire is almost like right-brain thinking. It is profoundly different from Java, C#, and other imperative languages. This is important in order to truly grow. To borrow from natural languages: it's cool if you know French and Spanish, but it's cooler if you know French and Chinese (or Spanish and Chinese).

Bonus: though not unique to FP, Clojure can execute data as code. This is powerful, and quite underrated, IMHO. This goes all the way back to grand-daddy Lisp, so you'll be learning from one of the undisputed giants. What's more both Lisp and Clojure have a minimal, consistent syntax. Though it is, er, mind-expanding at first, many people become true fans of the philosophy.

Software Transactional Memory

Concurrency is the new memory management. Memory management was a beast until garbage collection evolved, over decades, to be a shining sword.

Now, on the JVM, we've tamed the memory beast and wrestle with concurrency. Consider books like this: JCiP is an outstanding book, but it is a tough go, in part because the developer must coordinate lock-level tools. Or, worse, a team of people must coordinate lock-level tools.

What if we had something really different -- a pseudo-intelligent agent like a garbage collector, except aimed at concurrency? That's what Clojure offers: a unique alternative that might (and that's all we can say: might) slay the beast of our time.

The Upshot

Come on out to the JUG on Thursday, or if you aren't in St Louis, check out Mark's excellent article on Clojure. It is quite thorough, and has received kudos from the Clojure community.

Mandatory Listening: Michael Nygard on SE-Radio

2009-05-13T10:17:00.000-07:00

Ted Neward has told us to buy Michael Nygard's Release It.

I have told you to listen to Software Engineering Radio.

Perhaps you haven't listened. Perhaps you've been busy, or perhaps you reject advice from respected IT leaders (and me) on principle.

Well, now there are no excuses: check out SE-Radio episode 134 with Michael Nygard. You may not refute an implicit double recommendation!

Believe me, you won't regret it. Then read the book and check out his talks on the NFJS tour.

Language Shootout At Lambda Lounge

2009-05-05T20:36:00.000-07:00

Gmail has been recommending "vending machines" ads to me for some weeks now.

Here's why: the Lambda Lounge has issued the Vending Machine exercise as a way to showcase the idioms of different languages (and there has been good discussions on the mailing list, hence the Google ads).

If you are in St Louis, drop by on Thursday night (details here), to see some live demos! There are a wide variety of languages on display.

For best results, take a shot with a language of your choice. Though somewhat behind, I've been working on a Groovy version.

Stay tuned to the website (or the mailing list) to find resources to examples.

What is this, the developer's version of The Onion?

2009-04-24T05:19:00.000-07:00

I've started a new venture: Patently False. Tech headlines and gossip from the cutting edge of satire.

Here is an RSS feed and here is a Twitter feed.

The Story

CodeToJoy's model has been, vaguely, Calvin and Hobbes, with posts that range from the earnest to the absurd. Long-time readers can stay with me, and adjust easily as the sincerity scale changes.

However, I realize that it's difficult for newbies to pin down the vibe. The title of this post is a comment that was left on Reddit or DZone, months ago. For CodeToJoy, the answer is "it depends on the post".

Though my writing certainly doesn't compare to genius of C&H or The Onion, I've decided to branch out. Patently False will be all absurdity, all the time -- a resounding yes to this post's title. To combat ambiguity, I put a disclaimer right in the title.

The Organization

Also, I've decided to go ultra-lightweight: headlines only, on Twitter. On Google Reader, I've noticed that The Onion can make me laugh with a good headline. Sometimes, the stories seem like a forced, obligatory exercise.

There is a blog site, with an official introduction and explanation of the interrobang, but for now that is mostly a holding area.

The Upshot

Subscribe today.... I reserve the right to do longer, full spoof pieces on CodeToJoy: this blog won't change. After all, the nation of The Joyous must be served!

Top Ten Reasons Java Developers Fear The Oracle Buyout

2009-04-20T17:25:00.000-07:00

It is huge news indeed, and so without further ado, here are the Top Ten Reasons why Java developers fear the Oracle buyout:

#10 Any Java class with the name Table in it will have a 30 character limit

#9 Your favorite open-source IDE will become a Toad plugin

#8 Applications will become known as Enterprise Stored Procedures

#7 Ignoring silly hexadecimal, the CEO will insist the venerable CAFEBABE header be changed to IAMLARRY

#6 Prospective JavaOne speakers will need to win a yacht race as part of the acceptance process. JavaOne itself will be held on a desert island.

#5 The beloved Java Posse will suddenly resurface as the PL/SQL Posse

#4 The classloader will become a fork of MySQL and require a series of certification tests before modification

#3 The next version of Java will be known as JDK 7g

#2 A new Swing API will replace EventListener with TNSListener, requiring annoying server configuration.

and the top reason Java developers fear the Oracle buyout:

#1 DBAs will park in reserved slots, acquire window offices, and gleefully demand that everything goes into Fourth Normal Form.

If you like this kind of humor, come on over to a brand-new Twitter feed...

Introducing @patentlyfalse (read more here).

Even if you aren't on Twitter, here is an RSS feed.

Historical Footnote on Design Patterns

2009-04-19T13:26:00.000-07:00

When it rains, it pours. I recently attended an excellent talk on "Design Patterns Reconsidered" by Alex Miller. Around the same time, I was listening to a Software Engineering radio podcast (on Adrenalin Junkies) and heard a comment that merits amplification.

Many people know (or would know, if they attended Alex's talk) that the seminal book, Design Patterns, was heavily influenced by books on architecture by Christopher Alexander. In Design Patterns, the now-famous Gang of Four certainly discuss Alexander, and list patterns-based literature of the era, vis-a-vis software architecture -- but there isn't much on the semantic gap between architecture and computer science. How did we discover Alexander in the first place?

On the podcast, a woman points out that Peopleware is one of the first known books on software to reference Alexander's works (though note that the context is organizing office space).

Tom deMarco acknowledges the comment, but states that Edward Yourdon was a major factor in bringing the book into consciousness of IT (in the early 1970s). Though he can only comment for himself (and not the Gang of Four), deMarco goes on to say that he owes "a personal debt" to Yourdon.

Perhaps, we all owe thanks?

Trimming a string column in PostgreSQL

2009-04-18T11:01:00.000-07:00

In case this helps anyone... I had to figure it out recently and though it isn't hard, it isn't obvious either.

Here's how to truncate a string column in Postgres. Assume the column is of length M where M > N and we want it to be N with simple trim:

alter table T alter column C type varchar(N)
      using substring(C from 1 for N);

The key is that C references both the column name (in the first instance) and the value (in the second instance).

Monads 102: using Haskell online (or 'Finding your inner Klingon')

2009-04-16T17:29:00.000-07:00

The Goal

This post is a long-delayed follow-up to a talk I gave at the Lambda Lounge. It will use a simple code example to show some intermediate ideas of monads in Haskell.

The best part is that the code can be pasted into Codepad (no affiliation) and tinkered with. No download necessary!

(Note that a recent review of RWH calls Haskell "like Klingon, but with math". Hence the subtitle.)

Where is Monads 101?

There is no Monads 101 post on this blog. This is part of the zen of monads, as explained in Monads are Burritos. I did my best at the Lambda Lounge, and have some fun ideas for the future, but for now, this post is intended for readers who have some background in Haskell.

Ok, ok, as a super brief recap, check out this photo. Recall that

1. m is a type constructor (i.e. it is a generic type that wraps another type)

2. a -> m a is a function that injects/wraps something of type a into something of type m. In Haskell, this is called return

3. m a -> (a -> m b) -> m b is a function that takes a monad m a and another function, a -> m b. It returns m b. Loosely speaking, it breaks the inner type out of m and applies the function, resulting in a computed value back inside another m. The 'breaking out of' part is unspecified and unique to each monad. This whole doozie is called bind and uses this symbol: >>=

It is vital to understand that a, b, and m above are types (e.g. Integer, String). Haskell has a gorgeous fluidity between data variables and type variables that can be confusing at first.

A monad is a type that supports all three of the above. I warned you that this was Monads 102. If you aren't comfortable at this point, that's fine. This is non-trivial stuff.

The Goals

We'll take a code example that defines a trivial function called tuple. This example won't change but we'll send in some different monadic values and see what happens.

Example: Maybe (with Integer)

Here is the full example... Paste this into Codepad:


-- see comments below
tuple mx = mx >>= \x -> return (x, x + 1 )

mx = Just 10

main = (print (tuple mx))

Here is a version with comments:


-- In English, tuple accepts a mx, a monad.
-- The monad pulls x out, and builds a simple tuple
-- which is returned in a monad of the same type.
-- Here mx is a variable name. It is of type 'm a'
-- where m and a are types
--
-- 1. tuple takes m a and returns m (a, a)
-- 2. note that \x -> ... is a lambda expression
--    with a parameter 'x'. This expression is
--    the function a -> m b that is passed to bind.
-- 3. >>= is called 'bind' because it binds the
--    value of x
-- NOTE: mx defines the way >>= behaves!!!

tuple mx = mx >>= \x -> return (x, x + 1 )

-- mx is of type Maybe Integer

mx = Just 10

-- main just prints the result

main = (print (tuple mx))

The output should be:

Just (10,11)

Try some other values for mx. Experimentation here will be worth a zillion words and comments.

Example: Maybe (with Double)

In the Codepad editor, change the value of mx to:


mx = Just 3.14

and run again. Since Haskell is Klingon-esque about types, this is a big deal. The tuple function works with Maybe Integer as well as Maybe Double. In fact, it should work with any m a where a supports addition.

Example: Maybe (with Nothing)

Now, again in Codepad, change the value of mx to:


mx = Nothing

The output should be the same: Nothing. What is happening? Recall that the monad supplies the bind function by 'breaking out' the inner type: but each monad can define that behaviour.

In the case of Maybe, that behaviour is defined in part as: if the value is Nothing, then don't even bother calling the supplied function! Hence, the result is Nothing.

Example: List

Here's where things get fun... Let's wish Maybe a fond farewell and use another monad: List. Remember that tuple isn't going to change here.

In Codepad, do this:


mx = [1,2,3,4]

Try and guess what the output should be, then run it.

You should see:

[(1,2),(2,3),(3,4),(4,5)]

The reason for this is that the List monad uses a different definition for 'breaking out' when applying >>= / bind. Clearly, the List definition is to apply the provided function to each element in the list.

Conclusion

The upshot here is that tuple isn't changing. The monads are changing. (Or for you Zen types, your mind is changing. For Klingons, the semantics of the syntax is bending to your will.)

It is important to note that tuple is indeed a lame function with no utility. The types Maybe and List are useful; as monads, they are very basic. If you were to describe the 'breaking out' in pseudocode, they seem trivial:

Given m >>= f where m is m a and f is a -> m b

When m is Maybe: if it has something, it applies f; else it does nothing.
When m is List: it applies f for each element in the list.

Don't be fooled! There are other monads in Haskell that are much more sophisticated (an intense example is the STM monad for software transactional memory).

The important thing is to understand that the power is in the 'breaking out', which is individual to the monad. Yet against that flexibility, we have seen with tuple that monadic code remains constant.

That's monads in a nutshell: rigidity and flexibility in a powerful combination.

I love the Deep Fried Bytes, man!

2009-04-15T10:22:00.000-07:00

(The title of this post comes from a quote by Dick Wall, professing his love for Groovy in the face of charges to the contrary.)

A while back (on Twitter), I made a comment about the podcast Deep Fried Bytes. There was a brief exchange with the guys at DFB: it was friendly, but I felt like we weren't communicating. I allow that to happen 2-3 times before I bail and use email or the blog.

(Random tangent: It is mystifying why others try to debate religion or politics in 140 chars. It comes across as an intellectual boxing fight, except with Nerf gloves. Or an obscure debate between two Zen masters).

I first heard of the podcast during a talk by Ken Sipe (on F#). I loaded up on episodes for F#, C#, and some other Microsoft technologies. I'm not proud of this, but I'm not familiar with the dotNet space; I haven't used Visual Studio in years.

I loved the podcasts because they were geeky, but also because the topics are a new world to me. I felt like a spy listening in on a secure line. This is not a criticism: the 'casts are a great way to catch up on what is happening over there.

I have since learned that the podcast isn't solely Microsoft: e.g. they have a great episode on architecture with a guy from Digg, one with the Rails Rumble champs, and so on. Also, the April 1 podcast is simply brilliant.

So, I invite you to join me and sit on the porch with these guys and have some iced tea. They have asked me about some topics of interest but I refuse to offer any: I want them to surprise me and stretch my boundaries.

Keep up the good work, mates.

Dear Speaker: 10 Thoughts Beyond 'Make Eye-Contact'

2009-04-13T18:13:00.000-07:00

The Motivation

Recently, I read a post by James Duncan Davidson called Dear Speakers. He tweeted criticisms about speakers (no names used) and later blogged his thoughts. The tweets were not mean-spirited but also not inside jokes among friends.

I believe that James is offering earnest advice, but the post really irritates me. Here's why:

Critiquing a speaker during a presentation, even without using names, is both gutless and rude. I wonder if James offered any advice, in person, to the speakers afterwards. New technology doesn't excuse us from acting like civilized adults. True, I'm the guy that does this (yes, juvenile). But I asked first and looked people straight in the eye.
James provides some random, tactical details as advice. They are fine tips but they strike me as being mere trees in the forest. I have wanted to write about the forest for some time now, so here I am.
However, the post really irks me because I attended a technical talk by JDD on the No Fluff Just Stuff tour, circa 2002. I won't comment on it here, but: if we had the technology back then, how would JDD feel if I tweeted, even without mentioning his name?

What are my qualifications to talk on this?

Frankly, I'm no more qualified to talk about this than anyone else.

FWIW, I have emceed a couple of weddings, and have given some technical talks, all with widely mixed results. In my team's war room, I'm not at all shy about launching into an impromptu lecture on whatever I find interesting. I have taken the venerable Dale Carnegie course on public speaking (highly recommended). All of this may or may not impress you.

[Editor's note: I have since spoken at the Gateway Software Symposium 2010 and the Lambda Lounge. This still may or may not impress you.]

I fully concede I have broken many of the following rules. Sometimes, it has haunted me for weeks afterwards.

So I'm a modest presenter. However, I have seen dozens of talks: tech talks, conference sessions, keynote addresses, etc. I've attended my local JUG and NFJS for years, and am lucky to see terrific speakers on a regular basis via my employer.

It is very hard to describe what works, but I know when I see it. The best analogy is music: I can't tell you why I admire certain guitar players. There is no formula, and it is highly subjective, yet there seem to be common elements across my favourites.

Writing about this is like describing a dream: it's impossible to articulate the elements of my favourite guitar players, or my favourite speakers. But spurred to action by James' post, here are 10 things to consider.

1. Take a class

Before you can give a tech presentation, you should be able to give a presentation. JDD's post, and the comments, concentrate on things like pacing, pause words ("um", "so"), eye contact, etc. A lot of advice is written as "just keep these 1000 things in mind the next time you are feeling the adrenalin rush of the flight-or-fight syndrome while in front of a crowd".

Gee, thanks. Here's some real advice: if you want to learn to be a better speaker, with a chance to receive genuinely constructive criticism, take a class. There are classes at your local college. There are higher end classes like Dale Carnegie and Toastmasters. Or take an improv class.

It doesn't matter: just pick one and get out there.

(I have no affliation with Dale Carnegie, but a quick plug. When I was 13, I was so shy that I had to steel my resolve to call a store and ask about their hours of operation. I took Dale C at age 22 and have never looked back. No one describes me as shy now.)

2. Know your audience

I learned this one the hard way. Above, I mentioned several types of talks: tech talks, keynotes, etc. Be sure to think about your gig, and match your preparation to it.

For example, at a brown bag tech lunch, you have about 3 minutes to show some code. These people are voyeurs, and code is their porn. If you show up with 10 slides about cargo cults and the history of computing, they aren't going to be happy. Similarly, if you are up for a keynote, and don't have some kind of polish, things are going to be rough as well.

Also, you need to understand the technical level of your audience. This should be fairly obvious, as I'm sure you suffered through mismatches as an attendee.

3. Know your audience, seriously

I'm repeating this one because of the hidden audiences.

At NFJS, Scott Davis recently joked about those long, gorgeous Flash intros on artsy/marketing websites. He said, "who are those for? Everyone clicks Skip Intro".

My first thought was: they are for other people who write Flash intros. It is an arms race among a small elite to impress each other. This is an example of a hidden audience.

As an example, a fancy Keynote presentation can be very slick and alluring, but if you have 3D dancing slide transitions that emit pyro-lasers onto the ceiling, are you trying to impress the audience, or are you trying to impress other speakers? or other Keynote users? or your own ego?

That is to say, who is your real audience?

Always, always, always keep the real audience as priority #1. Be slick, be funny, be wacky, but only insofar as it advances your message.

4. Steal

If you don't play guitar, you might think that each solo, each lick, is its own creative snowflake, a sonic fingerprint that is unique in the universe.

This is just one of many lies you've been led to believe.

Guitarists copy, steal, and nick from each other all the time, and always have. The reason you may not be able to tell is that the good ones are clever about it: they take the essence of an idea, and make it their own.

With respect to speaking, I'm not talking about stealing content. I'm talking about style. Once you've identified your style (see below) think about who you like as a speaker, and why. Then, pattern your talk using similar elements.

A great example for keynote addresses is referencing a topic far removed from the ostensible subject, and then tying it in. A fantastic example is Dave Thomas' talks and writings on cargo cults.

5. Be true to yourself

This item is in a delicious tension with the previous one.

Some speakers are animated and theatric. Some are dry and yet genuinely funny. Some are no-nonsense and try to maximize the amount of content provided to you. This is all fine and well.

No one should label or box themselves in, but it is wise to think about the speaker you want to be. If you have a naturally dry sense of humor, then it may be futile to try and speak as a different character. Public speaking is inherently outside our comfort zone, so there is no need to double that by pretending to be someone you're not.

That said, it can be electrifying to go on stage. Many entertainers have alter egos that appear out of nowhere when the lights go up. If that happens, great, but it isn't necessary.

The upshot: take risks but follow your intuition.

6. Have a message

Everyone knows the old saw, "tell 'em what you're gonna tell 'em, then tell 'em, then tell 'em what you told 'em". That's good stuff.

The key point: have something to tell them.

I'm old-fashioned but I was taught that an essay should have a thesis statement. A movie should have a story. A novel should have a narrative, and so on.

In the same way, I think that a talk should have an essential message that can be condensed into a short outline or a simple phrase. If someone asks "what was your talk about?", you should be able to answer, coherently, in 30 seconds.

This may seem obvious for an expansive keynote address, but I think it applies even to the humble brown-bag tech lunch. My goal for such a lunch is to present a topic to the audience so that they can decide if they want to pursue it further. Consequently, the message is invariably along the lines of "This tool offers A, B, and C, but suffers from X. If you value X, then you may want to wait but if, like me, you value A above the others, then check this out".

The good news is that thinking about this up front will focus your preparation. As well, a creative challenge is to express your message without actually saying it, but this can be tricky (see the last item).

7. Prepare

This one is cheap and easy, but I am compelled to write it.

Prepare your talk. Practice, rehearse, check your time. Remember that time can evaporate on stage, especially if there are questions.

More than this, though, take every opportunity to prepare the equipment. If possible, go to the venue days beforehand. On the day of the talk, get there very early, and remember to test your equipment! Just showing up isn't enough!

I once had a golden opportunity to rehearse with some equipment, on the day before an event, and passed up the chance. It was a major error. The mic was hard to use and I didn't find out until "go time", despite having ample opportunity to prepare. Shameful.

8. Respect questioners, but keep it moving

Assume that a questioner is at the right technical level and earnestly trying to advance the cause of the talk on behalf of you and the audience.

If they are, no problem: be polite and answer the question.

However, it might not be true, or may become apparent after a couple of questions. E.g.

The person might not be at the right level technical level for the group (e.g. if someone asks 'does CSS support aspect-oriented monads?' or 'what is a database?').
The person might have their own hidden audience and start to grand-stand to impress others or themselves.
Everyone is a comic. Often, this sets a warm atmosphere, but one can go out of control after scoring some laughs.

(The unvarnished truth is that I'm guilty of all of these, as an audience member. Hopefully not too often!)

I defer to your intuition on how to be graceful, but it is important in these instances to acknowledge the person, be respectful, and then move on. The goal is to convey your message to the group.

Squash the impasse with the venerable "let's go offline". If you really follow-up later in an earnest manner, it is better for everyone.

9. Learn from criticism

I'm paraphrasing the master, Dale Carnegie, on this one, as he said it best.

There are two ways to handle criticism: if it's accurate, learn and adapt from it; if it isn't accurate, be a duck and let that water just roll off your back.

The trick is to identify accuracy. This is difficult but clearly it requires objective reflection. And a keen sense for the difference between fact and opinion.

I think there is an asymptotic effect here: if you give a sufficient number of talks (see item #1!), and adapt, earnestly and honestly, to enough criticism, the curve will invariably tend towards you being an excellent speaker.

10. Break the damn rules

Just like in music, the most creative and wonderful things come when we break the rules. (Note that here I mean tactical rules like "use slides", and not themes, e.g. "respect your audience".)

However, it isn't just a matter of ignoring the rules like a bull in a china shop. To truly break the rules, one should first understand them.

In this way, one becomes a master. Note that the road is not easy: for every brilliant, rule-breaking, game-changing creation, there are countless disasters laying in the ditch. Talk is cheap: you must be prepared for failure if you try something crazy.

Again, it comes back to intuition: if you feel you're ready and can accept the consequences, go for it.

Rule-breaker? A Masterful (and high risk) Example

I'm bummed that someone, in the comments on JDD's post, already pointed out the video below. A friend and I saw Clifford Stoll at SD West circa 2000. It was the single best talk I have ever seen, and represents my own Platonic ideal as a speaker. I've searched for it but no luck. (I tried to capture its spirit in Beethoven didn't use Powerpoint).

Talking about it is like trying to describe a dream. Or for someone to describe seeing Stevie Ray Vaughn play live.

The version below is similar in nature. It doesn't (can't!) compare to the dream I saw, but it is great stuff.

I include it also for the duality: on one hand, this breaks all of the little tactical rules ('make eye-contact'); on the other hand, it preserves -- even illustrates -- the core principles behind a great presentation.

Though again, you better be careful about running around your conference room like a mad scientist, I conclude with these questions:

Did he think about his thesis?
Did he know his audience? (a slide-rule!?)
Do you think he was earnest in conveying his message?

(Hint: yes).

Cult attacks OpenJDK, demands deified generics in Java

2009-04-01T07:45:00.000-07:00

CodeToJoy Newswire
Parody City, CA
April 1, 2009

The OpenJDK team announced today that its source-control system received a "prolonged, sustained attack". The attack came from a small sect of developers who are strangely zealous about strong, runtime typing. The group's attempted upload to the site repeatedly stated "Give us deified generics in Java!".

One insider reported: "Apparently these people are not capable of submitting a reasonable proposal, nor are they satisified with mere reified generics. They are continually attempting to inject a syntax such as:


class MyCollection<we_kneel_before_thee T> extends Collection<T>;

which we think is both unpleasant and inappropriate."

There is no word on the affiliation behind the deification of generics, but sources say they suspect the misfits have ties to the ML-family of languages.

Conficker inspires F# team to release immutable browser

2009-04-01T06:15:00.000-07:00

CodeToJoy Newswire
Parody City, CA
April 1, 2009

Hot on the heels of the worldwide Conficker scare, insiders reveal that Microsoft has asked its nascent F# team to improve web security by writing an immutable browser.

Code-named Atom, the browser will allow users to manually type in a URL, and to scroll the results, but there is no mouse support within the HTML.

Said someone close to the team: "The aim is to bring pure functional programming to the web. Atom will have no support for Ajax or any other Javascript. In fact, the users are not allowed to click on the page, or to have plugins of any kind. This will thwart the hacking community and save untold numbers of person-years."

When pressed on the utility and security of having to manually enter URLs, the source replied, "It is definitely less convenient, but since we cannot secure the OS level, this really the next best route. Plus, we are excited to bring the principles of functional programming to the desktop".

In early market trading, shares of URL-shortening sites tinyurl.com and is.gd went up 4109%.

Monads are Burritos

2009-03-30T06:00:00.000-07:00

Earlier in the month, I gave at talk at the Lambda Lounge. The title was Monads are Burritos.

The slides are here. Some example code in Haskell is here. (I have provided examples both with and without the do-syntax: the latter is much cleaner and easier to use, but only once you understand the former. Be warned: the examples are rough, if you don't know Haskell).

The following are among my goals when it comes to talks:

I usually have a small set of ideas that I want to state, much like a thesis statement in an essay.
I strive to make the experience of attending a talk vastly different from the raw material on the slides. A goal is to reward those who come to my party. Imagine a 1920s ballroom on a Sunday morning. The slides should be like empty beer bottles, overturned tables, and bras hanging from the ceiling fan: mere artifacts indicating that something larger has taken place.

I may or may not have achieved these goals, but the result is the same: the slides will seem odd. So, here is an overview of my thesis points.

Monads are not Burritos

Brent Yorgey has a wonderful post on the tarpit of writing monad tutorials. Generally, someone goes off into the mountains for a few weeks, works hard, and has some kind of epiphany: say, for example, that monads are like burritos. Afterwards, they rave like a lunatic to puzzled listeners/readers.

To me, monads have nothing to do with burritos, but I liked the post so much that I named my talk after it.

Find your own Burrito

Some have challenged the FP world to explain monads in 2 sentences. I can't do that, but in 1993 I couldn't have done it for objects. In my freshman year, I couldn't have done it for recursion.

In other words, even if I did think that monads are burritos, it doesn't matter. You have to do the work and find out your own revelation. That is to say, you have to find your own burrito. Just as we did for polymorphism, encapsulation, inheritence, and so on.

Dude...

The comic Demitri Martin has a puzzle wherein he wonders what the smartest thing anyone has said that starts with "Dude...". My favourite of his: "Dude, these are isotopes". (FWIW, he means "dude" here in a gender-neutral, skater-scene tone.)

I have two offerings (one of which was given at the talk):

Dude, a monad is a burrito, if a burrito is a functor-like object with a generic type, a sense of encapsulation, and the ability to combine small computations into larger ones!
Dude, a monad is a programmable semi-colon!

Examples?

This post won't give examples, or even really try to explain the zen of monads. This is really intended as an explanation for the beer bottles and overturned tables. (Here are some more).

I may post some code later on, as a supplement to those who were there for the talk.

Applying Project Coin to Agile Development

2009-03-26T19:20:00.000-07:00

Project Coin

As noted in Alex Miller's various Java7 posts, Project Coin is a set of small language changes proposed for Java7. As noted on a recent Java Posse podcast, these changes should be on the same order of magnitude as the new for-loop in Java 5. That is to say, the change should be small: a coin, as it were.

All well and good, but this post is not about Java. This post is about the reaction to the project. Though I prefer Project Coin it could also be called Project Breathmint, because it is refreshing (even fun) to talk about small features that do not ignite the flames of debate as much as say... *pause for effect* closures. These are lightweight changes that can really make a pleasant difference.

The Idea

My proposal is to consider your own Project Coin for your project.

The Background

There are many casualties in the lack of communication between developers and the stakeholders of a project, even on agile teams. One such casualty is this: customers, domain experts, and especially support staff often despise a given defect or quirk that is quite easy to fix. A recent case for me is a recurring exception trace in a log file (it occurs often because of a poor API design: the exception is thrown in a reasonable, normal situation). The support staff have learned to pattern-match it, but it gives them fits.

The Execution

We should not lose focus of the main money-maker: delivering maximum bang-for-the-buck features to customers, where said features are prioritized by stakeholders. However, it seems reasonable for a team to draft a Project Coin once per quarter. The first benefit will be reaped immediately: communication. Even if an item proves to be too large to be a coin, the dialogue among the team will be worth it.

Once the list is compiled, the team could shoot for one coin per iteration (e.g. every 2 weeks). Naturally, if an item doesn't make it, that is acceptable: these are literally bonus points.

The Project Coin items are perfect for newcomers to the project, for junior developers, or for Friday afternoons when we need a break. A danger is that someone will go hog-wild with a complete framework to fix a small problem, but daily stand-ups and code reviews should keep that in check. (Your team does have dailies and code reviews, right?)

The Upshot

I can't say that I've put this into practice. However, my team has talked about this idea in nebulous terms. Now that we have the coin metaphor from Java, perhaps it can become a reality for many agile teams.

Ada Lovelace Day: Grace Hopper

2009-03-24T18:18:00.001-07:00

Full Disclosure

New readers may want to know that this blog is on this list for posting photos of women holding geeky stickers. For what it's worth, this blog also features photos of men holding geeky stickers. Are any of them geeks? I have no idea: I didn't have time to find out. A geek is not defined by gender or looks; a geek is defined by characteristics such as:

Wondering, incredulously: "Did MIT really ditch Scheme in 6.001?"
Being able to answer "is 47 a prime number?" in a blink of an eye
Enjoying weird puzzles like "what does a nanosecond look like?"

Ada Lovelace Day

I think Ada Lovelace Day is a good idea. Ironically, despite being on a male privilege list, I (sadly) recognize many of the issues listed. Moreover, I have two young, wonderful cousins (girls), and I would like to help to ensure that computer science and mathematics is welcoming to them. If posts like this help the cause, then why not...

The Star

This post is about a wonderful pioneer of computer science. She was brilliant, witty, and an influence on me as a undergraduate student, via print and film.

She also happened to be a woman. Though Ada L Day is a motivating factor, I have long wanted to write an appreciation, because of her abilities, contributions, and style.

She is Grace Hopper, one of the first rock star programmers. I post this for a younger generation, lest we forget.

I've decided not to write a biography: peruse the achievements on Wikipedia. They are stunning. She easily had more on her resume by 1941 than your most of your CS profs, here in 2009. Suffice it to say that she would go on to work on the Harvard Mark I and the UNIVAC. She also helped design COBOL (laugh if you must, but see below).

When I think of her, I think of these influences:

She famously demanded to see a nanosecond: she would hand out wires that were the length traveled by light in 1 nanosecond. To this day, I try to use props whenever possible in discussions.
I once read the transcripts from a language symposium in the 1970s. Grace said something along these lines "... if you remember one thing from this, remember that COBOL was a temporary proposal. We did not intend for that version to be the final draft." This is fascinating but also a great presentation technique. Again to this day, I use that phrase for effect "if you remember just one thing....".
She didn't take any crap from anyone. See her interview with David Letterman below. Though it is dumbed-down for pop culture, notice her matter-of-fact style. There is no need to showboat for TV: these are the facts, and it is all perfectly logical. I love it.

Setting an Example

Grace Hopper was fantastic, plain and simple. To me, her example for my young cousins -- and everyone else -- is this: if you are a geek, be the best you can be. Embrace it, live it, love it. Be so good that you transcend labels, because no one can stop a geek who simply kicks ass.

No Fluff Just Stuff St Louis: A Review

2009-03-14T12:40:00.000-07:00

Ed's note: I work for a sponsor of the StL NFJS and many of the local speakers are friends. That said, I have attended the Gateway NFJS for 8 years, most of which were through a previous employer. If you know me in person, you know I enjoy these shows tremendously.

The Gist

Last weekend, I attended the 2009 St Louis NFJS show. As long-time readers will know, I really enjoy both the content of these shows as well as the energy from talking to other attendees.

In this recap, I will try to highlight my experience with the assumption that you are familiar with the format and the NFJS tour. If not, there are many resources on the web describing the basic idea of a "conference near you".

The Sessions

Here are some highlights from the sessions I attended. Note that later posts will have thoughts/questions that arose from these talks.

Sporting a Hawaiian shirt "made from an amalgam of sofas", Alex Miller gave a talk on Java 7. With his Java 7 website, it is hard to imagine someone with a more complete view of the big picture. One slide included all potential features, and the current status of each. I especially enjoyed the background behind Project Coin, JSR 310 (Date/Time), and the fork-join frameword (jsr166y).
Alex is hardcore into concurrency, and gave some talks in this space as well. This is essential stuff. It is not clear to me if Java will be the longterm answer for concurrent programming on the JVM, but right now it certainly is: if you do threading, you need to see Java Concurrency Gotchas.
Ken Sipe gave several talks on understanding garbage collection and tweaking the JVM. I saw the one on GC in the past, and it helped me solve a tricky memory leak at a client site. I went back for more this year. If you want to be a problem solver for your project in production, his material is top shelf. Who else points to a graph spike and says with a devilish grin: "we are now watching a star die" ?
I caught Scott Davis' talk on Lizard Brain Web Design. This was one of the most fun, as Scott is a terrific speaker and the topic is about the nebulous nexus of practicality and aesthetics, outside of the machinations of the IDE. Anyone can simply read the pop psych books but I enjoy how Scott brings it together into a coherent, relevant narrative. This stuff just comes alive.
My colleagues Mark Volkmann and Tim Dalton gave excellent talks on Clojure and Scala, respectively the cutting-edge of languages on the JVM. I've seen precursors to these talks before so the material was familiar: I really want to see 'part 2' where each talks about concurrency and/or software transactional memory.

Some other major themes included Groovy, JMS, and agile practices. Incredibly, I didn't attend any Groovy sessions as I feel very comfortable with the language, and with Grails. I've seen the JMS talks before (recommended) and others were casualties of scheduling.

The Vibe

My main sources for the "vibe" of the conference are the Birds of a Feather sessions, the polls during the expert panel, and just interacting with other attendees:

I attended the BoF on dynamic languages. The discussion was solely centered on funcational languages. Several people wondered about the allure, and if the masses could make the leap. Again, a theme was the potential sea-change with respect to concurrency. I told one chap that if we could learn object-orientation (recall how tricky polymorphism was in 1994?), then we can learn FP.
Jay Zimmerman took some interesting, informal polls. e.g. The majority of attendees wrote unit tests and used agile practices. Agile seemed non-controversial and an ideal, much different from an NFJS from, say, 2003.
A common theme among conversation was: which new language should I choose? Venkat Subramaniam said it best: it doesn't matter. Just pick one and go with it. It is more important to learn ideas (from any language) than mere syntax from any one in particular. He cited the conventional wisdom that it is important to know a language from each major school (e.g. functional, object-oriented, etc).

The Keynote

Venkat gave the keynote: Facts and Fallacies of Everyday Software.

After discreetly kicking off his shoes, he launched into a comical tirade about the collisions between common sense and stupidity, using some clever photos to shine the spotlight of logic on absurdity (e.g. a "No Fishing" sign on a bridge that is 1000 feet above the ground). I've seen some dandy keynotes in the past (including the Chairman of the Board) but this was the closest to a good stand-up comedy routine.

In between the laughs, the thesis emerged: think! Observe and challenge the requirements, the process, and the software.

The Upshot

I like to clown around but I truly enjoy sharing experiences about software. This NFJS was energizing, as usual, because of the quality of the speakers and the participants. There were so many conversations and ideas that it is difficult to capture here.

David Geary has a great line about GWT that applies to this past weekend: it makes writing sofware fun again.

Make Money with tonight's StL JUG

2009-03-12T06:36:00.001-07:00

The mobile platform is the new gold rush: there's gold in them thar hills (*).

As you know, there are 2 potential goldmines: the iPhone and Android. I won't tell you which one to pick, but consider this depiction of the battle.

Tonight, at the StL JUG, Eric Burke will introduce us to one of the major players: Android. Come on out and see what is possible. You are only bound by your imagination.

If you can't make it, check out the related videos on OCItv

(*) For those who are not American, it is not clear if you can actually make money with the Android app store: international business is tricky. But surely (?) you can do some free stuff and get your name out there. Often, name recognition will open doors.

Get Gregarious: Grok Griffon at Gateway Groovy Group

2009-03-10T10:04:00.000-07:00

First, you should meet the nascent Gateway Groovy User Group: it has been started by Dave Klein, a friend, upcoming JavaOne speaker, and all-around class act.

On Wednesday night, March 11, the GGUG will feature Matt Taylor, speaking on Griffon. Matt is not only a friend but also an excellent speaker and is seriously involved in Groovy, working for G2One/SpringSource. As I understand it, Griffon is a Grails-like framework for desktop applications.

Cool people, an interesting topic, and free: that's hard to beat. Come on out and socialize! I'll see you there.

ps. For the artistic types, Griffon is having a logo contest until March 22. Imagine the fame if you won...

The Faces of Gateway NFJS 2009

2009-03-09T04:35:00.000-07:00

Here are some photos from the recent No Fluff Just Stuff show in St Louis. Stay tuned for a review and some thoughts stemming from the conference. In a nutshell, it was an excellent show with an energetic crowd.

These are my people: smart geeks who consider Java/JVM technologies as a way to spice up an otherwise dull and dreary weekend. No boredom here!

NFJS attendees report the final score:

Speakers Scott Davis, Venkat Subramaniam, and Ken Sipe ham it up to form the MVC pattern:

NFJS attendee (Jeff G), and speakers Mark Volkmann, Tim Dalton speak to the importance of functional programming and concurrency:

NFJS attendees report the score from the lobby:

NFJS attendee, speakers Alex Miller and Mark Volkmann define a monad (from functional programming):

NFJS attendee, and NFJS organizers form the MVC pattern:

That's how we roll on a geeky, tech weekend....

Beyond TGIF: TGI NFJS

2009-03-06T05:31:00.000-08:00

I've had a lot going on (including a fun night at the Lambda Lounge), and have neglected to mention that No Fluff Just Stuff returns to St Louis this weekend.

This will be my 8th one here in St Louis (i.e. all of them, I think).

I'm pumped! Long-time readers will know that I'm a fan of NFJS, both in terms of the content and especially the energy from the crowd.

I'm looking forward to many of the speakers, including my friends and the Gateway's own Alex Miller, Ken Sipe, and Mark Volkmann.

I don't have an iPhone or G1, so live pics and tweets will not happen. However, I do hope to document some of the vibe, and I'll be loaded with various and sundry stickers. Stay tuned or check out my Twitter feed (@codetojoy)

See you soon!

The Brilliance of Type Signatures in Haskell

2009-02-27T03:48:00.000-08:00

I've been soaking up some Haskell lately, and have rediscovered the beauty of type signatures. As I vaguely remember from university, the ML-family of languages are truly profound in this regard.

Background

A type signature for a function in Haskell is somewhat like a method signature in Java (particularly with generics). However, they make stronger statements, due to:

Haskell is a pure functional language: there are no side effects (for the sake of this post). The expression (foo 5) is mathematical in nature.
Haskell does not support type coercion (see comments).
Haskell cannot introspect a given type.

Examples

Like many languages, Haskell provides tuples: e.g. (1,"hello") or (3.14, True). Consider this type signature for the function fst:


fst :: (a, b) -> a

This reads in English "fst accepts a 2-tuple of types a and b and returns something of type a". It is vital to understand that a and b are types: e.g. Int, String, etc.

If you guessed that fst returns the first element in the tuple: bingo. This is intuitive and natural.

However, there's more, as explained in Real World Haskell. Because of the purity of Haskell and its strong type system, it is true that the only possible behaviour for a non-pathological version of fst is that it returns the first element. In this example, there is no other option. That is mind-blowing; this kind of reasoning predicates some of the optimizations possible in Haskell.

Consider this example, noting that [a] is a list of a in Haskell:

concat :: [[a]] -> [a]

What does it do? In Java, I might provide Javadoc (which could be false) but even a method signature doesn't tell the whole story: the method might quietly log to a file, write to a database, or launch missles. Here, we might intuit that concat flattens a list (Ed's note: or the first level -- see comments):



concat [ [1] , [2,3], [4] ] = [1,2,3,4]

Bingo.

As one works more and more with Haskell, the type signatures become vital, and simply fascinating.

A final, complex example. A Haskell monad has a combining function. For simplicity, I'll call it myChain. It has a type signature of (where m is a Monad):

myChain :: m a -> (a -> m b) -> m b

For this post, m is a generic type. In Java, think of WeakReference<T> or List<T>.

In English, we say that myChain accepts a monad m of type a, and a function that accepts type a and returns a monad of type b. The result of myChain is a monad of type b.

If we stare at this long enough, we can guess the following about this function, without knowing anything about monads: it probably pulls out the item of type a from the first parameter and applies the function provided as the second parameter.

This is true. We've been able to intuit something about the mighty monad simply from the type signature.

Brilliant.

The Upshot

There has long been a tension between dynamically-typed languages and statically-typed languages. In the last few years, the dynamic languages have become the media darlings. What's not to love? They are productive and mind-bending in their own way.

However, don't sell the statically-typed languages short: especially, the functional languages with strong, static typing. This is deeply profound stuff. As I work more and more with type signatures in Haskell, I feel the psychic fingerprints of abstract algebra and other math theory: it is as though we prove programs rather than write them.

ps. myChain is known as >>= in Haskell, and is usually called bind.

Best Invite Acceptance of 2009

2009-02-26T10:27:00.000-08:00

At my client site, I offered a dry-run of an upcoming talk on Monads (stay tuned for more info). In my email to the team, I gave some fair warnings that the talk would be über-geeky.

One wag responded:

Oooh... a brown bag on material that's inherently dry, well outside my comfort zone, and irrelevant to my future? I'M IN!

This is a wonderfully succinct definition of being a geek. These are my people.

ps. Before you begin to riot, Haskell/FP fans: neither my respondent nor I truly think monads are irrelevant.

A Keep-Alive Post

2009-02-15T15:40:00.000-08:00

Though it has no formal name, every blogger eventually writes a post to reassure readers that yes, s/he is still alive and well. Call it a keep-alive post that pings on the socket between the writer and the audience.

Such a time has come for this blog: the CtJ Nation has been clamouring for something -- anything -- to put some spice in their otherwise quiet browsing.

Things have been busy at CtJ HQ. It is a busy time for some personal pursuits, and also in preparing for a talk at the Lambda Lounge in March. I also confess that I've been distracted by the evil, seductive Twitter, much as I had feared.

Here are some quick notes on ideas in store for CtJ. Drop a line if any of these resonate with you:

My upcoming talk is on monads, and so I've been cramming Haskell from Real World Haskell. This is a gorgeous language, and shares some psychic fingerprints with Unix, in that _everything_ is on its terms. Once you accept that, Haskell makes a very good case for the power of strong, static typing.
I have been working in a war room for a couple of years now. This is fertile ground for blogging, but I generally avoid any subject that might seem personal towards my colleagues. However, I think I have enough experience (direct, or overheard) that I can safely abstract themes and episodes in a way that is essentially fiction. I'm considering a series called Adventures in Agility.
Ted Neward has written about women in IT. I've been thinking about something similar for a long time, since I am on this list about male privilege. It pains me deeply that I'm on there, as I agree that some of the items are issues. I'm a free spirit at the pub, but I'm genuinely mortified to offend anyone in the workplace, on any criteria. I've been trying to reconcile this with the famous sticker posts. I'm considering a piece on the criteria I use to rate someone as a geek (hint: it has nothing to do with gender, race, religion, etc).

And that's the news from CtJ HQ. Stay tuned!

Thursday Night's Alright for Byting

2009-02-03T19:16:00.000-08:00

If you're in St Louis, have had it with the discipline, and want to get a little action in, then check out these events:

Thursday, Feb 5, there is only one game in town: the burgeoning Lambda Lounge will feature talks on Javascript (from an FP perspective) by Nate Young, and Actor concurrency in Erlang by Alex Miller (speaker at NFJS, Java One, and occasionally outside, at the corner of Terra and Cotta).

Thursday, Feb 12, the venerable StL JUG features another NFJS speaker, Ken Sipe, with a talk on Spring 3 Annotations.

For more write-ups, events, and a great local calendar, see this post over at Alex Miller's blog. There is a lot going on in the coming weeks in the "Gateway Valley". Come on out and take real steps towards diversifying your career!

Seattle jazz players urge Microsoft to rebrand F# as Gb

2009-01-21T20:02:00.000-08:00

CtJ Newswire
Parody City, CA
Jan 22, 2009

In a press conference held near Seattle, a group of jazz musicians urged Microsoft to rebrand its nascent language, F# (pronounced F-Sharp), as Gb (G-Flat).

Said a spokesperson for the group: "It is abundantly clear that Microsoft employees are primarily guitarists or pianists. When horn players look at both F# and C#, we see the vibe: there is no love coming our way here. All those sharps: we just don't think that way."

Another protester recognized the technical details: "Look, we understand that there is a language called D, and that Db might have implied some kind of inferiority. So we stayed silent on C#. But there is no language called G, and so F# is a slap in the face. What's more, if the top-brass at Microsoft want to trumpet support for a functional programming language with monad-like structures, lambda expressions, and strong static typing, then all we ask is that they use an appropriate key for we horn blowers."

At this time, there is no word if Microsoft will comply with the musicians' plea.

Your company's first bug of 2009

2009-01-08T19:53:00.001-08:00

I bet I can guess a bug at your company. You may not even know it. Nor your customers, or your marketing department.

It's probably in your code. It might be on your website. It is probably completely innocuous until you need it most, and then, well, your legal staff will tell you all about it.

If you haven't guessed yet, it's your copyright text. Most likely, it says something like:

ABC Company copyright 2002-2008. All rights reserved.

or even possibly "... (c) 2002-2004" if it is in code.

What does this mean? Does it really matter?

Good question. The facile answer is that if it was important enough to merit a copyright notice from 2002 to 2004, then it is probably important enough to update now. A more sophisticated question is if there is any legal standing for the years after a copyright notice. To be honest, I don't know.

All I know is that one team lead (who I respect) once speculated that omitting a copyright notice on new code was grounds for dismissal. I thought that was crazy then, and I do now: but it underscores the importance of this legal business. (As an aside, it just looks plain bad when the year is off on a website.)

I invite clarifications on the ramifications of letting copyrights 'expire' (if that is the correct term), but for now the takeaway is: update the darn year, and give your lawyers some backup support.

Executive Summary: the Origin of MicroBenchmarks

2009-01-05T05:42:00.000-08:00

Inspired by a recent post about JavaFX being 25x faster than some other languages. (No link provided because it doesn't merit more attention.)

The Obscenity of New Syntax

2008-12-22T07:46:00.000-08:00

Background

A couple of weeks ago, I attended the Lambda Lounge for a talk on OCaml. I decided to be proactive, so before the talk, I downloaded the runtime and kicked the tires.

For days, during compilations and Fit tests, I would play with the language. I had used ML years ago, but had forgotten much of it (aside from a vague memory of an ultra-strict, Klingon type system that was both a high-grade irritant, and yet oddly reassuring).

By the end of a week, I wasn't much further ahead with OCaml. I had written some basic functions and expressions, but nothing substantive.

The Experience

During the talk, I realized that the experimentation was more useful than I had imagined.

The presenter showed something like this:


# let sphere_surface = fun x -> x *. x *. pi;;
val sphere_surface : float -> float = fun

The questions flew immediately: why is there a double-semi (;;) ? are we running as root? how do we interpret the output?

These were natural questions by smart newbies to the language. I had two thoughts:

Naturally, it helps to prepare for a talk, but I was surprised by how far my modest time investment had taken me. I couldn't have answered all of the questions, but I could place myself in both mindsets: one of the questioner (what the heck?) and also the presenter (oh, see it works like this).
The first few examples struck the audience as obscene. I don't mean morally, and I don't mean that as a slight to OCaml per se. I mean in an artistic sense: well-known symbols that were beloved in other contexts had now been thrown together in a way that was jarring and almost repulsive. It takes some time to get past that shock of illiteracy.

The Upshot

This post is a reminder to myself: if a language talk is on the calendar, it is vital to download the environment and write some toy examples before attending, even if you only have a couple of hours to spare. The idea is not to learn the language but to embrace the obscenity and overcome it: celebrate the dissonance! As one music teacher put it: the Hendrix chord would have been considered hideous, even dangerous, in other eras. Now, it rocks.

Next Up: JavaFX

You may have several opportunities to see presentations on a new language in the near future: JavaFX. If you subscribe to the idea behind this post, you might be interested in an article by my friend Weiqi Gao: it is a top-shelf article on JavaFX as a language.

I'm going to be giving it a whirl over the holidays. The goal is to sing Auld Lang Syntax on New Year's Eve!

ps. Best holiday wishes to all readers... Here's a toast to a fine '09

Island Rhubarb Dessert (Favourite Holiday Recipe Meme)

2008-12-08T10:17:00.000-08:00

I've been tagged by Eric on the Favourite Holiday Recipe meme. Here is mine: it is not difficult compared to other family recipes but it is excellent. It works best with rhubarb grown on Prince Edward Island, but if not possible, work with the freshest stuff you can find.

I'm tagging:

Matt
Stef
Dale
Nate
and Dave

Island Rhubarb Dessert

This a 4-layer pan dessert.

Put on some favourite holiday music and pour a beverage of your choice.
Prepare separate packages of dreamwhip and a 6 oz package of vanilla pudding.
Eat some vanilla pudding, to set the stage.
Crust layer: Mix 1 1/2 cups graham crumbs, 1/4 cup soft margarine, and 1/4 cup brown sugar. Spread in 9 x 11 inch pan. Bake at 350 F for 5 to 8 minutes. Let cool.
Filling layer 1: 4 cups fresh or frozen rhubarb, 1 cup white sugar, 1/2 cup water, 3 tablespoons cornstarch, and 2 tablespoons strawberry jello powder. Boil until cooked and thick to a sauce. Spread on crust. Let cool.
Filling layer 2: Cover with prepared dreamwhip and add 1 1/2 miniatures marshmellows if desired.
Top layer: spread prepared vanilla pudding over the dreamwhip layer.
Refrigerate.
Enjoy with friends.

Lambda Lounge Lures Legion of Licentious Linguists

2008-12-06T06:15:00.001-08:00

As many others have mentioned, the first meeting at the Lambda Lounge was a big hit! It was clear from the turnout (30+) that (a) a lot of people have a thirst for something more exotic than Java and (b) the IT community in StL is thriving and sophisticated. We all agreed that we are 'promiscuous' regarding computer languages (hence the post title).

Appistry served as gracious host and formed a fitting backdrop for the evening, and the vibe was palpable; there was an energy similar to the NFJS conferences.

The content was excellent stuff: Matt Taylor discussed categories and mixins in Groovy; Ryan Senior gave an overview of OCaml.

Overheard at the meeting (paraphrased) :

Java is wonderful, boring, and the new COBOL, all at the same time. (Editor's note: perhaps it is the new C ?)
I wish OCaml didn't use # as the prompt. I feel like we're the root user and something crazy is about to happen.
10 years ago, we turned out in gatherings like this because we were stoked about Java. Now we turn out to get away from Java.
The opposite of a functional language is a dysfunctional language.
They should name OCaml's web framework to be ODromedary.

Bottom-line: Come on out to the January meeting if you want a piece of this. Time well spent with cool people.

Child suspended for EJB taunt

2008-12-03T05:12:00.001-08:00

CtJ Newswire
Parody City
December 3, 2008

A district schoolboard reported today that a Grade 2 student has been suspended indefinitely for calling his teacher "the EJB of school" in class.

The announcement comes on the heels of a heated exchange between the teacher and the student as to whether cursive writing was important.

The principal of the school, Edgar J. Boyle, provided a brief statement: "We aren't exactly sure what EJB is, but after consulting with the IT industry, we understand that it implies a high degree of excess proportion and baroque complexity, ultimately leading to failure. In some circles, it is a taunt of the highest order. We believe this kind of language was learned in the home, but we refuse to stand for it in the classroom."

There is no word if the parents will appeal the decision, despite rumors of a protest website being constructed with Grails, a nascent IT solution.

A First Look at Android (video)

2008-11-30T18:56:00.001-08:00

Here is a tech talk by the nefarious comic artist, Eric Burke (we're friends/colleagues/blog rivals).

Eric discusses his initial experimentation with Android. He's been working with Ed Burnette's e-book 'Hello Android', and has some good stuff over at his blog.

It is not news that the mobile platform is the Next Great Battlefield, but intro material on Android is news. With all of the massive players in this space, it is important for us to pick a horse and bet on it with a time investment and experimentation.

I won't tell you which one to learn, but Android is a reasonable choice. You can see why in the video...

Spice up your week with the Lambda Lounge

2008-11-30T10:14:00.000-08:00

Looking for something more exotic than Java or C++ ?

Need an oasis of pure computing in an otherwise bleak and desolate week of software engineering?

If you are in St Louis, Alex Miller has something for you: the nascent Lambda Lounge, a monthly celebration of developments in the world of functional and dynamic languages.

As mentioned on the website, the basic idea is to explore new developments in programming languages and libraries. Note that the subjects are not necessarily bound to the JVM or the DLR from dot Net. I'm looking forward to the weird and wonderful stuff at this meeting. The first one is Thursday, December 4. Check the website for details.

On a sidenote, I quite like the logo. I'm not sure of the symbolism of the bits at the top. My interpretation is that they are eyeglasses. If true, I love this because it reminds me of the styles of the chess grandmasters of Europe in the late 19th century, and particularly the cafes in Paris where intellectuals would congregate to discuss philosophy and other subjects.

That said, this meeting will be much less pretentious than those gatherings of yore! No word if there will be sword-play based on heated language debates.

Car-pooling with eBay, Erlang, and Haskell

2008-11-20T19:39:00.000-08:00

I bought a new stereo for my car, and I'm enjoying listening to tech podcasts on my commute and errands.

My favourite is still the beguiling Java Posse, but I have been extremely impressed with Software Engineering Radio. This is world-class stuff. Be sure to check out the episodes with eBay's Randy Shoup, Erlang guru Joe Armstrong, and Haskell maven Simon Peyton Jones.

Outstanding. I'm going to be donating to the cause via PayPal.

Groovy is to Grails, as X is to Y ?

2008-11-07T04:45:00.000-08:00

Consider the following: Groovy is to Grails, as X is to Y.

I recently tweeted "... as C is to Unix". Though Mario quite rightly pointed out that much of Grails is written in Java, my thinking is that both Groovy and C enjoy greater popularity because of the success of their sibling application/system. i.e. It seems that Grails, as Unix once did, acted as a driving force beyond that of pure language development, which propels innovation and gives focus to an emergent style.

Dave Klein has his own tasty analogy about butter and pancakes.

And you? What are your values for X and Y ?

Ruby fans are invited to play the same game, with respect to Rails. Are there any values for X and Y which resonate for Ruby/Rails but not for Groovy/Grails (or vice-versa)? That one is very interesting.

Kudos to ActiveMQ

2008-11-04T05:33:00.000-08:00

At CtJ HQ, we try to spotlight any projects that have a pleasant "getting started" experience.

Today's winner is ActiveMQ, an open-source JMS implementation. After following the installation instructions, I went to a "Getting Started" web page that explains how to start the basic consumer and producer examples. The instructions are clear, and the code is a perfect "foothold": something to help me get a leg up. It is simple and yet has several options to show various JMS patterns.

My thanks to those involved!

Snatching Open Source Licensing from the Jaws of Legal Marginalization

2008-11-03T05:00:00.000-08:00

A recent issue of DDJ has an fascinating article on the case of Jacobsen versus Katzer, pertaining to the legal strength of open-source licenses.

To quote author Michael Swaine: it's a big deal.

The nano-gist is:

Katzer threatened legal action on a supposed patent violation by Jacobsen.
Jacobsen looked at the facts (including that K had used parts of J's software), marshalled resources from the open-source community, and launched a pre-emptive lawsuit.
A U.S. district court judged in a manner that severely limited monetary damages awarded to J, based on a legal distinction between a condition and a covenant.
Later, an appeals court overturned the decision. i.e. The good guys win.

I didn't know about the case, so although the article is brief, it almost reads like the story-board for a thriller. I hope that, somehow, it is made into a documentary.

Overview of Hadoop

2008-11-02T16:33:00.000-08:00

My friend Tom Wheeler has written an excellent article over at the OCI Java News Brief.

The article has not only an overview but also many reference links and some outstanding examples of Hadoop in the wild. Examples include the New York Times Machine project and a record-setting cluster with 4000 nodes.

As neat as this all is, I'm more excited about the notion of people solving problems in a different way, via the Map-Reduce strategy. Tom gives a counter-intuitive example of a word count algorithm: in the small, it is awkward and slow; in the large, it scales seamlessly to colossal proportions.

Back in university, a favourite class was the Theory of Computation. I recall the strategy of proving a problem was NP-Hard: if one can express it in terms of another problem that is known to be NP-Hard, then one could argue that if one can solve the original problem in polynomial time, then one could solve the set of NP problems in polynomial time (I'll let commenters distinguish between NP-Hard and NP-Complete and other subtleties). As an understated aside, solving this problem would be 'good for one's resume'.

Solving a problem with Map-Reduce isn't the same thing, but there is an abstract, psychic thread that seems to tie them together: the notion of thinking about problems in a certain mindset. Very cool stuff. I hope to find time to explore that further.

Lurker Exposed 2: Giving Twitter a shot

2008-11-01T08:43:00.000-07:00

Despite my rant, I'm giving Twitter a shot, due to peer pressure and sketchy coercion from a man with ties to the intelligence community.

My thinking:

Don't knock it till you've tried it (though that generally doesn't stop me)
Who's kidding? When it comes to blog hits, I'll prostitute myself as much as the next person.
Since I am genuinely interested in others' status, it should be more efficient than being a lurker.
Dopamine rushes and other biochemical reactions aren't a bad thing

Fear not, non-tweeters (especially those for whom the rant may have resonated) !

I am only visiting the dark side, and will fight assimilation.

Lurker Exposed: Why I wasn't on Twitter

2008-11-01T07:22:00.000-07:00

Many of my friends know that I am not a fan of Twitter, and yet I lurk on there. Here are some quick thoughts on the site.

First, I should point out that I think I 'get it': the sense of community, particularly if you work with people remotely. I also understand that if I don't like it, I can just stay away.... so we're in full Unsolicited Opinion Mode here (and somewhat tongue-in-cheek).

Twitter killed the blogging star

Gah! With blogs everything was going great: people wrote paragraphs, and others commented. Flame wars were so large that the flames danced into the night sky, harkening back to Usenet and other media of yore. Twitter strikes me as a threat (hopefully a short-lived one) to the Great Conversations, banzai stunts, and comics.

To paraphrase Stephen Wright, Twitter strikes me as HDADD : High-Definition Attention-Deficit Disorder. There's hardly any focus, but when it is there, it's "140 characters of amazing clarity" *eye roll*

The War Room

My current team works in an open "war room" where there is a healthy peer pressure regarding minimal browsing. Plus, I can't speak for you, but I seek simplicity when at work: no IM, no phone, and sometimes even no shoes. Sure, I have guilty pleasures but I don't need another.

Navel Lint

Does anyone really want my status? What if I'm wondering why navel lint is never the same colour as the garments one has been wearing? Strangely, I do enjoy others' navel-gazing.... until one random tweet puts me off, and then I'm back into rant mode.

Sharing Links

I no longer care about websites that have been sent to me in email. Same thing for twitter. I've noticed that the best sites are those that people mention here. Essentially, your collective memories serve as my spam filter because if you remember it well enough to talk about it, it's probably good.

Who knew that you've been working for me? Awesome. Now, let's go to a cafe, pub, or tech talk and have a real conversation.

Politics

Hoo-boy. Many smart people bemoan the lack of nuance in the mainstream media (especially in North America) but then try to chat about issues in 140 characters? Yikes. Even better is the lack of threaded conversations. As a lurker, I'm clicking all over the place to try and connect the dots on a pseudo-conversation.

Firing of Dopminergic Neurons... Wheels down on a dopamine rush

I have a feeling that when one is tweeted by another who is "higher on the geek pecking order" that it fires reward sensors in the brain that can be interpreted as insight, or a meaningful connection. It is neither! It's merely a biochemical reaction! Can't you people see what is happening? You may say twitter is a "convenient, asychronous chat-room where the whole is greater than the sum of its tweets". I say it is a delusion, a vacuous sham of humanity that takes us one step closer to the Borg.

Conclusion

OH: Twitter sucks.

That said, you may be interested in the next post, where I'll tell you why I can't resist, and why I'm giving it a shot.

Simply Groovy (How to gain Competitive Advantage on Weiqi Gao's Friday Java Quiz)

2008-10-13T18:19:00.000-07:00

Weiqi Gao runs the popular Friday Java Quiz. He provides puzzles and invites us to ruminate on bed-time reading of the Java Language Specification, or to recall a Java Puzzler that may have been discussed over dinner. (He would be dismayed if he knew that we occasionally just watch TV.) Often, he absolutely forbids us from using the compiler.

Whatever: if you're like me, you take your best, thoughtful guess and then fire up an editor to check. Often, this is rushed, because it would be nice to be the first one to post a comment. All too often, I don't get to the verification stage because it is just too much effort. I only have so many public static void mains in me.

These days, I just use Groovy's command-line. It gives me an advantage in terms of speed, and it often makes the problem more fun, because I have to formulate it in a different way.

For example, in the latest quiz, Weiqi says that it can't get much simpler.

In Java, the code is (mostly) as simple as possible:


import java.io.*;

public class Foo {
    public static void main(String[] args) {
        Serializable bar = null;
        System.out.println(bar instanceof Serializable);
    }
}

Yet with Groovy's -e parameter, life is much easier (and faster):


$ groovy -e " Serializable bar = null ; \
         println (bar instanceof Serializable) "

The snippet above has 2 cool elements: (a) Groovy auto-imports java.util.* and java.io.* (e.g. Serializable) for you and (b) it will evaluate an expression on the fly. Because Groovy accepts most Java, this is a handy way to beat the masses to the answer of the Friday Java Quiz.

More than that, it is a great way to answer many quick questions in Java. I often use it in my team's war room when a question arises.

Note: I'm not sure, but I think that -e may have a bug in 1.5+ on a Windows machine. A single statement works fine, but this:


groovy -e " println 'hi' ; println 'there' "

seems to have trouble on a Windows box. Drop a line on your experience.

Ant vs Maven, Episode 2 : Gant or Gradle?

2008-10-08T10:01:00.000-07:00

In June, I gave a tech talk on Gant. Gant is a Groovy layer on top of Ant -- essentially Groovy's AntBuilder on sterioids.

My thesis was:

We are in a post-Ant world, and at a crossroads. One road involves continuous integration tools such as Hudson. Another road concerns project framework builds such as Maven. A final road is for general purpose build tools such as Ant. These roads may intertwine, and even build on one another.
However, with respect to the latter road: we need a new general purpose build tool. We owe a tremendous debt to Ant, and it is still useful, but it has serious problems. First, XML is not a programming language. Second, the Ant community can't decide if it is declarative or imperative: e.g. properties are immutable, except when they aren't. Finally, some of Ant's built-in tasks (e.g. javac) are great: call them "big iron" workhorses; however, the act of "machining" a new task is prohibitively difficult.
Enter Gant: it rests on top of the "big iron" tasks of Ant, but allows us to work with a real programming language (Groovy) so that simple logic is trivial and new tasks are like working with modelling clay. Put another way, if Ant is a rigid, metal clock, then Gant is weirdly fluid -- yet both keep time.

That was June. Now, alas, it isn't so simple: Gant has had a competitor named Gradle. Gradle is more 'heavyweight' than Gant: it uses a full Directed Acyclic Graph (DAG) and aspires to be closer to something like Maven or SCons. In terms of formal build theory, Gradle is more powerful than Gant.

The question, posed on the Groovy mailing list, is how to unify the forces. It is a fascinating debate, and rather important to the Groovy community. I haven't used Gradle so I can't choose, but I will say that I think this direction is the future for build tools: dynamic languages are a great fit for builds.

Here is a quick (hopefully correct) rundown:

Gant rests on top of Ant. It is lightweight and is used as a task management framework in Grails (quite a pedigree there).
Gradle has strong Ant integration, but aspires to be more than a scripting language for Ant. It has DAG support and targets a space closer to, and actually beyond, Maven.
In simple terms, Gant is analogous to Ant ; Gradle is analogous to Maven. And so many of the usual arguments apply. However, an open question is if Gradle can serve Gant's position as a lightweight tool (where lightweight itself is open to definition).

If you want to be on the bleeding edge, check out this debate. I'm happy to see that the discussion is civil and intelligent: these are cool blokes. Very interesting.

Razz Your Friends : the best Java Exception ever

2008-10-08T09:49:00.000-07:00

Hey! what is this mess? You are totally throwing a CME!

Where CME is defined here (and used metaphorically)

Thanks to CtJ correspondent Steve Holdener for the tip.

I have seen the Future and its name is Ruby

2008-10-06T14:04:00.000-07:00

Well, I haven't seen the future, but this guy has... I defer to Future Man for an update on the current state of the language:

ps. Be sure to see the outtake (?) at the end.

Thank You, Java 5

2008-10-05T19:19:00.000-07:00

Alex Miller polled Java users and a fair number are still using JDK 1.4. This post is intended for those folks: have hope, there is truly useful stuff in Java 5.

In this post, I will mention a couple of my favourites. These have been well-documented, and are not even the 'coolest' features, but my respect for them has been well-earned over the last few months.

Background

I've been part of a team that has been moving a project from JDK 1.4 to Java 6, and introducing Hibernate/Postgres to replace (in incremental steps) an existing, legacy framework that works with an OODB. This has been a serious refactoring and fairly risky. My analogy is that of putting in a subway transit system into a modern city: it is a massive job, but will be well worth it.

Ten months later, we appear (knock wood) to be finished with a major version of this migration. I've used the following Java 5 features before, but now I am truly fond of them.

The For Loop

When I first saw the new for loop, I yawned:


List<String> list = new ArrayList<String>();

// snip  

for( String s : list ) {
    System.out.println(s);
}

It was a nice bit of syntactic sugar, but I was unimpressed. Now, I can't stand to see an old-style loop. The new loop is so much cleaner. A major bonus for us is that it works with arrays:


String[] array = new String[]{ "abc", "def" };

for( String s : array ) {
    System.out.println(s);
}

As we have refactored, the code literally looks washed and waxed afterwards. Very nice.

Generics

When I first saw generics in Java, I was unimpressed. With a background in C++ and other languages, I understood the point but felt that Java had lost some of its Smalltalk influence, and that the syntax was plain ugly. When I realized the "wall of erasure" (as coined by Brian Gilstrap), I was even less enthused:


List<String> list = new ArrayList<String>();

list.add("Cubs swept by Dodgers.");
list.add("any team can have a bad millenium!");
  
// on a static page, generics allows us to avoid the cast,
// which is boring, and compile-time checking. 
// The biggest advantage is in a good IDE
// where this information comes alive:

String first = list.get(0);

Now, I am an absolute fan. Yes, the corner cases are sharp, and the FAQ is very long for a reason. Yes, we may well need reified types to get full generic capabilities. I don't care: the new static typing of collections saved our project. Seriously. We were wading through dozens of collections in the legacy code and would have never been able to untangle all the knots without Java generics and Eclipse. I repeat: generics saved us, and I am grateful.

The Upshot

We shouldn't suspend our critical thinking and skepticism when it comes to new language features. However, we should also believe that people are earnestly trying to add value when new features are proposed. For one, I am going to keep an open mind when it comes to looking at the new features for Java 7+. Who knows: the features which cause us to roll our eyes may well be our future favourites.

ps. This is another post but unit testing and integration testing (with dbUnit) was equally essential to our success. Of the bugs in new code, my guess is that 90% were in code that was not tested.

pps. We have barely used static imports, but Eric has done some cool things with them. They are underrated, IMO.

Timeout bug with Corba and Java

2008-09-26T10:45:00.001-07:00

Just in case this helps anyone searching The Google:

If you see an error message like this (snipped):

WARNING: (COMM_FAILURE) Read of full message failed : bytes requested = X bytes read = Y max wait time = 3,000 total time spent waiting = 3,190

and are using Java 1.5+ with CORBA, then be sure to check out this post.

Essentially, it involves a timeout value on a socket. Changing this property:

com.sun.CORBA.transport.ORBTCPReadTimeouts

is the key, as described in the linked post. Mercifully, we came across this quickly during a recent troubleshooting. It could have consumed days.

A fascinating quote attributed to James Gosling

2008-09-24T18:35:00.000-07:00

I have been sitting on this post by Ken Arnold for months now, trying to figure out a way to write about it. I thought of it again today and decided to carpe blogem with some quick thoughts.

Random Thoughts

James Duncan Davidson has always been too apologetic and too harsh on Ant. Sure, it isn't perfect and may not have been his finest hour, but it delivered us from 'make'; and for that, I'm forever grateful.
IMO, Gant may well be the next generation of build tools. I'm not sure that it allows the Unix pipes that Arnold mentions, but it is much closer than Ant will ever be. (My Maven friends will, no doubt, chime in here.)

The quote by Gosling

I love the (paraphrased) quote attributed to Gosling:

James Gosling once said that every configuration file becomes a programming language, so you might as well think that way.

First, I should point out that I have not authenticated this quote, but Arnold is a reputable source, and this seems consistent with Emacs. Presumably, this was well before 2003, the date of Arnold's post.

This quote shows the power of philosophy: without knowing it, Gosling anticipates the success of Rails and Grails over Struts, and to a lesser degree, the possibility of a triumph of Gant over Ant.

True, this doesn't talk about "convention over configuration" or even web frameworks per se, but it clearly suggests that solutions with static configuration suffer an asymptotic disadvantage, compared to solutions with dynamic, programmatic configuration. The dice are loaded from the start.

Every time I work with Grails or Gant, I think of this quote.

Quotes from an agile War Room : the anti-project

2008-09-20T09:44:00.000-07:00

Several developers stand at a white-board, recalling the problems of a previous project.

One after another, anti-patterns are noted and discussed, involving threading issues, micro-level transaction management, absurdly slow unit tests, and scalability flaws.

Says one developer, "Friends, that thing had so many anti-patterns that it was an anti-project".

Observations of a Surfer (in 2008)

2008-09-15T18:57:00.000-07:00

Two recent observations that imply that web surfing isn't exactly 'there' yet as a user experience:

Captcha

When I submit a comment to someone's blog, I usually copy my well-crafted, thoughtful comment before running the gauntlet of submit/captcha because I have a subconscious fear, based on hard experience, that things are going to go very, very wrong.

Web 2.0 and Ajax

I have a habit of clicking on a window before scrolling, to ensure that it is 'active'. This was never a problem until all the Ajax stuff: now, that real estate is often a latent feature or gizmo that is just waiting to fire.

I've become subconsciously afraid to click in a browser window: it is a minefield.

The Upshot

I don't know what to do with this information. This may be a silly rant, but it is intended as a sudden realization.

Possibly the Best Quote Ever for Code Maintenance

2008-09-12T06:00:00.000-07:00

From the brilliant Top Gear (see 3:00 to 3:30, on this clip of absurd custom limousines):

It is an ingenious solution for a problem that never should have existed in the first place.

Google releases Giant Hadron Collider

2008-09-09T21:03:00.000-07:00

CtJ Newswire
Parody City, CA
Sept 9, 2008

While the scientific community waits in anxious anticipation for the commencement of CERN, the Large Hadron Collider, insiders report a stunning development: Google will release their own, open-source particle accelerator. The project is reputed to be a Giant Hadron Collider (GHC), a monstrous piece of engineering powered by thousands of V8 engines. The giant, code-named CHRERN, features 54 km (34 mi) of tunnels, most of which run through the search engine's large, secure data centers over HTTP.

Many scientists have questioned the need for a rival, upstart effort to mimic the Big Bang, but others feel that it is consistent with Google's philosophy. Said one insider, "I suspect that Google has already found the Higgs boson (aka God particle) internally, and are developing the GHC for more ambitious applications".

Claimed another, "it may seem pugnacious at first, but they are basing the GHC on open, scientific standards, and that can only mean good things for science and humanity".

Mini Black Holes? Process Isolation

Skeptics wonder if the GHC is even more prone to creating black holes or singularities, threatening the Earth's very existence. "This is highly unlikely, since the architecture of the GHC partitions each singularity into its own multi-dimensional process. So, if a process goes awry, it will not harm the rest of the universe", reported a chief research scientist. She continued: "this is a distinct advantage over other accelerators, which work in the same process as the known universe. Moreover, it allows concurrent particle acceleration for truly, well, smashing throughput."

Despite all the buzz, there is no word yet if Google plans to explore sub-atomic space with Ad Sense.