Code To Joy

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?