Opening Day: the original Greenfield App

Opening Day is a minor holiday in many baseball cities, including St Louis.

It is the original Greenfield application: a fresh start, where hope springs eternal. No legacy baggage. No vendor or framework lock-in.

A true story: many years ago, I had taken a vacation day to go to see the Cardinals play their home opener. Due to an IT crisis, I was called in that morning for an emergency meeting for a valued, troubled customer.

After 1.5 hours, we had our plan. Upon leaving, someone pointed out that I was technically on vacation. I told the group that I didn't mind -- if they would do one favour.

I asked them to sing "Take Me Out to The Ball Game".

And in a dark conference room that had rarely, if ever, enjoyed the sound of music, they slowly, grudgingly started to sing. By the end of the first verse, they were into it, and beginning to smile. At the end, they were belting out the tune like school-children.

Here's to a new season....

Lorem Ipsum in Scala (or 'how Weiqi Gao took my Friday night')

"Gah!!!!", our hero grits his teeth and slams a hand on the keyboard, " Darn you, Weiqi Gao....".

It is late on a Friday night. Our hero has decided to give the dreaded Friday Scala Quiz a shot. Even though the challenge was clearly in jest, the temptation is just too great. Why not try? However, there is just one problem: despite attending several presentations on the language, he has only recently downloaded Scala, and tried only a simple HelloWorld program.

"What was that syntactic sugar for a method call?", he muses aloud, pouring another shot of gin into a tumbler filled with Red Bull. Whirling to the desk, he rifles through some notes from one of the presentations -- aha!

" obj.method(param) can be written as obj method param ! ", he cackles gleefully.

Hours later, with his head in his hands, he stares at the enigmatic error message from the sentient being that is the Scala type-inference engine. It mocks him. Miles away, Weiqi looks up from an abstract algebra textbook and smiles.

Some time later, the problem space is reduced considerably. The goal is now: a working Scala program that has the following, simple Latin phrase:

Lorem ipsum dolor sit amet , consectetur adipisicing elit. Ut enim

It contains some key ingredients: the comma, the period, and capitals. True, it does not contain an ending period, the word "do", or many of the other words.

Time passes.... Much is learned, or at least inferred, about Scala -- far more so than a "Hello World 2" program. And finally.... a modest success:

object Lorem {
 def ipsum(x: Any) = this
 def sit(x: Any) = println("Darn you, Weiqi!")
}

class Consectetur {
 def adipisicing(x: Any) = this
 def enim() = "It is late on a Friday"
}

class Elit {
 def Ut() = this
}

object Runner {
 def main(args: Array[String]) {
     var dolor, sit, amet = null
     var consectetur = new Consectetur()
     var elit = new Elit()     
  
     println( Lorem ipsum dolor sit amet ,
              consectetur adipisicing elit. Ut enim )
 }
}

The intrepid developer smiles at the output:

Darn you, Weiqi!
((),It is late on a Friday)

Quietly, he turns to the window and watches the clouds pass across a moon-filled sky. An evening well-spent.

ps. This is a good exercise for a newcomer to Scala. Though the next logical step is much more interesting: write a Scala program that accepts the Latin text as input and generates a Scala program that can use the phrase as a pseudo DSL.

Your Parents are making me buy a Mac

I've needed a new computer for awhile, and I've been long debating some issues. One is laptop versus desktop, but the primary issue is To Mac or Not To Mac.

There have been plenty of reasons to consider going with Apple:

• For years, the NFJS gang of hoodlums have been touting the Macbook Pro. I can't tell you how many impromptu, unpaid testimonials I've seen in the middle of a presentation.
• OCI has a sizable, passionate group of Mac folks. I've heard a rumour that they want to change the local traffic light near OCI HQ to be horizontal and Aqua: like the OS X window buttons (not really).
  
• If Charlie Rose can take one for the team when falling, so as to protect his Macbook Air, then surely I can learn to use one mouse button.
• The brick-and-mortar Apple Store is a temple for materialism: I am absolutely sucked in by the products, the ambience, and gorgeous lighting. Against the backdrop of bland Banana Republics, Foot Lockers, and food courts, The Store stands out like a beacon in the mist: an oasis of cheerful, productive humanity in an otherwise bleak and desolate existence. During a visit, I believe that I will be successful, cool, happy -- nay, complete -- if only I surrender to the inevitable and swipe that credit card.
  

Powerful stuff. But the real deal-maker is the following:

• I have heard N developers vow, after independent episodes of installing a new computer for their parents, that they want to have nothing to do with Vista.

That's my tipping point: N is sufficiently large. I'm seeking asylum from Vista, without even having tried it. (Send me the hate mail. Until I get the Mac, I'm lonely.)

I can't bear the thought of more Windows problems. I have not done my homework on my current Windows problems (I've been meaning to really understand the Registry for years now) and the issues simply accrue.

I need brand-new problems (I'm sure OS X has some?) and a fresh start.

I'll report on The Purchase and how things are going. And I'll send your folks a thank-you.

M.

ps. Yes, Linux is an option. I do own SuSe here at CtJ HQ but I'm simply caught in an iTractorBeam.

Groovy 201: How to Win a Bar Bet on Copy-Paste

A Java program and a Groovy program walk into a bar.

The barkeeper says "Hey fellas.... One check or should I just copy-paste Java's and start removing semi-colons?"

Ha ha! How quaint. (Kinda) Funny, because with Groovy's syntax, you can just copy-paste Java programs into Groovy and start from there. Right?

Whoa Nelly

Well, almost. Some Groovy 101 articles will state this. Sometimes they say "you can copy-paste virtually any Java program..."

The 2%

If you are in a pub or bar, and someone makes the first claim, and you sense that they aren't simply being brief, you should have a ready retort.

You could win some cash, or a drink.

This is not a criticism of Groovy, but there are some differences (on the order of 2% or smaller), as enumerated here on the Groovy website.

The Pub Winner

Here is the example to keep in your head. Consider the following Java program:

public class Mirror {
   private String image;

   public Mirror(String image) { this.image = image; }

   @Override
   public boolean equals(Object rhs) {
       Mirror rhsMirror = (Mirror) rhs;
       return this.image.equals( rhsMirror.image );
   }

   // TODO: hashCode()

   public static void main(String[] args) {
       Mirror a = new Mirror("you");
       Mirror b = new Mirror("you");

       if( a == b ) {
           System.out.println(" same object! ");
       } else {
           System.out.println(" different objects ");
       }
   }
}

As you know, in Java, this will print "different objects".

If you copy this file from Mirror.java to Mirror.groovy, it will run, even with annotations.

But the output will be different.

The Upshot

Groovy identity is different from Java identity. There is a good write-up on this philosophy on the Groovy site (again, here).

I don't judge, in this case. I simply give facts. Now, go out and win some bar bets.

Does Beta Mean 'Escaped' ?

When talking to non-geeks, I'm hard-pressed to explain what a "Beta version" really means.

At some shops, Beta seems to mean "Time is up! Put it into production for a client."

At Google, it seems to have this ambient air of modesty that quietly implies to the competition: "we can crush you without fully trying".

I'm beginning to think it may mean "escaped". This is based on a quote from a colleague on a past gig:

Software isn't released: it escapes. -- Anon

A case in point (and a plug): a friend has developed a site called Online Task List. It's a fine, free site for tracking tasks: I use it for my weekend agenda and reminders; some of our team uses it at work as a "task messageboard".

Though past Beta now, he originally put a Beta version online. He considered the site closed, and quietly worked on it. Soon, he had users signing up. He was surprised at the speed with which people found it. Now, he has dozens upon dozens. One explanation, of course, might be that Google eventually indexed it and it was turning up for the trendy "online task" searches (a la the GtD book).

I prefer a more romantic theory: it saw an opening.... and escaped.

Members of the CodeToJoy Nation

(Ed's note: We are suffering from illness at CtJ HQ, so time for some lighter fare.)

At the recent NFJS stuff conference, I met a developer, Seth, who:

• regularly sees a car in his neighbourhood with a "I *heart* POJOs" sticker
• has a cube neighbour who proudly displays his allegiance to CodeToJoy (via a sticker)

Naturally, Seth was given his own sticker. No word yet if it adorns his vehicle.

The upshot: slowly, but surely, the CodeToJoy Nation is growing. A merry, rag-tag band of developers bound not by nationality, not by language, but by the credo of the Joyous:

Putting the Thrill back in Code.

Some examples follow.

An international operative visits the mini-Eiffel Tower in Lyon, France:



A Joyous vehicle proudly sings the tune....



See contact info on the margin if you're interested in joining CtJ Nation: I'll send you a free sticker.

Haiku for PostgreSQL on Windows (a cautionary tale)

reckless Stop Service
faq shave yaks reinstall rage
select * from pain

A Random Walk Down NFJS Street

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

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

Groovy and Grails

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

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

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

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

Transactions

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

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

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

Mark has a book available via free PDF at InfoQ.

YSlow

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

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

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

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

Restlets

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

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

The Keynote

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

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

The Panel

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

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

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

Scala

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

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

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

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

Quick Notes

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

The Upshot

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

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

Upcoming Events in St Louis

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

Bonus: an iPod Shuffle is being given away!

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

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

Programming in Sock Feet

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

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

It gave rise to these thoughts...

Public Speaking

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

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

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

Programming

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

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

Free your body and your mind will follow.

Languages

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

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

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

The Upshot

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

Notes from NFJS: Day 1

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

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

Highlights of the day included:

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

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

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

Rhapsody in Blue: the Colour of BGGA Closures

Background

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

The Idea

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

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

An Example

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

Click on the screenshots for a better image.

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





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





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



The Problem

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

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

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

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

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



Complex Block

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

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



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

Remember, it works like this:

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

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




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

The Upshot

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

P.S.

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

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