Beethoven Didn't Use PowerPoint

Lots of people think songs without singing is not a song. Tell Beethoven that and he'll kick your @ss. -- Eddie Van Halen

I have seen a lot of technical presentations over the years. I have given some, but not recently. I've been thinking that it is time for another, to broaden my horizons.

I have a fantasy to try and pull off a technical presentation without any slides or demos.

I suspect that "lots of people think presentations without slides or demos is not a presentation" (see quote above)....

Is it possible -- no slides? no demos? Consider:

• A truly good speaker just needs a stage and a chalkboard. After all, professors have communicated sophisticated ideas for centuries without PowerPoint.
• I have blogged before that the best takeaways from a presentation are not bullet items nor code snippets. Give me ideas.
• Though I'm no expert, I have taken some acting classes and improv classes. One might say I'm a thespian trapped inside a man's body. The improvisation class in particular was an object lesson for the argument "less is more". A stage and 2 people: go! Hijinx ensues.

Admittedly, there are lots of good reasons for slides, and especially demos, but I'm intrigued. Especially since the SD West 2001 conference in San Jose, where I saw a master at work.

Cliff Stoll gave a keynote address that was fantastic. One part Einstein and one part Robin Williams, he ran around the stage frenetically, talking at 90 MPH, with his arms folded over his head. He ran into the audience, with his disheveled hair bouncing all over the place. He waved his arms; he yelled. He showed a home-built radar detector and ran towards it. A lot of running.... And a lot of very interesting points, often punctuated by a pause: the point would be brought home in a quiet voice, with a direct, knowing look into the audience. The subtext was often: "No, I'm not crazy. I'm dynamic." He spoke for 90 minutes, and received a standing ovation. It was truly spectacular.

Now, it is indeed true that the presentation was about abstract ideas, and not, say, the Java 3D API or Guice annotations.

Plus, it was a high-end keynote: I don't see myself building a radar dectector for a local Java SIG meeting, and running around in front of puzzled Java fans as though I'm in a play, talking crazily to unseen characters offstage.

But, still...... Beethoven didn't use PowerPoint.

Turbocharge Your Command Line

I enjoy modern Java IDEs and most graphical programs.

But you will have to pry my shell, command-line windows from my cold, dead hands. I use the shell mostly for flying around directory structures and using find/grep in combination.

No Powershell for me, thanks. Just give me Bash aliases -- especially via CygWin's Bash on Windows.

Here are some favorite tricks... IMHO they can really improve productivity for navigating directory structures and copying files across parallel structures. (All of these aliases go into my .bashrc in my $HOME directory)

Moving up N directories

Have you ever been deep down in a directory structure and just want to get out of there? e.g. Something like this ( 7u = "7 up" )

$ pwd
/measter/bin/this/is/a/dir/structure/that/is/so/deep/im/scared
$ 7u
/measter/bin/this/is/a/dir

Here's how:

alias i='echo ; ls ; echo ; echo ; pwd '
alias 2u='cd ../.. ; i'
alias 3u='cd ../../.. ; i'
alias 4u='cd ../../../.. ; i'
alias 5u='cd ../../../../.. ; i'
alias 6u='cd ../../../../../.. ; i'
alias 7u='cd ../../../../../../.. ; i'
alias 8u='cd ../../../../../../../.. ; i'

Dynamically assigning directories

How about assigning directories to a local "clipboard" (CB) variable for later use?
In this case, 'cb' assigns the directory and 'gcb' = 'go to the CB directory'.

$ pwd
/measter/bin/this/is/a/dir/structure/that/is/so/deep/im/scared
$ cb
CB = /measter/bin/this/is/a/dir/structure/that/is/so/deep/im/scared
$ cd /measter ; pwd
/measter
.... do some more work ...
$ gcb ; pwd
/measter/bin/this/is/a/dir/structure/that/is/so/deep/im/scared

Here's how:

# show clipboard vars

alias showcb='echo  CB  is $CB'
alias showcb1='echo CB1 is $CB1'
alias showcb2='echo CB2 is $CB2'
alias cbs='showcb ; showcb1 ; showcb2'

# assign clipboard directories

alias cb='export CB=$PWD ; cbs'
alias cb1='export CB1=$PWD ; cbs'
alias cb2='export CB2=$PWD ; cbs'

# change to clipboard directories

alias gcb='cd $CB ; cbs'
alias gcb1='cd $CB1 ; cbs'
alias gcb2='cd $CB2 ; cbs'

Publishing dynamic directories to another shell

Imagine that we have assigned 2 directories, CB and CB1, in Shell A using the above tricks. Now we need those directories over in Shell B. Something like:

# from shell A
$ cbs ; # display the CBs
CB=/measter
CB1=/measter/bin/this/is/another/dir
$ putcbs ; # publish the CBs

# from shell B
$ getcbs ; # get published CBs
$ cbs ; # show CBs
CB=/measter
CB1=/measter/bin/this/is/another/dir

Here's one way to do it:

# placed on multiple lines for readability
alias putcbs=' rm /tmp/cbs_list ; touch /tmp/cbs_list ;
              echo "export CB="$CB >> /tmp/cbs_list ;
              echo "export CB1="$CB1 >> /tmp/cbs_list ;
              echo "export CB2="$CB2 >> /tmp/cbs_list '

alias getcbs='. /tmp/cbs_list ; cbs '

The Gist

Use these and other ideas with aliases to save time and energy on your command-line:

• Increase the # of dynamic CBs to as many as you like. I use 3
• Use alias for common places in your project. E.g. gpro = 'cd /measter/project/home ; i'
• Always use the 'i' alias (defined above) for your "goto dir" aliases. Saves typing 'ls'
• Even shortening something with acc = ' ant clean compile ' can save precious millis.

What are your tricks?

'Live to Code' versus 'Code to Live'

The Thought

Do people in your city "live to work" or "work to live" ? That is, does your city prioritize "the rat race" and climbing the corporate ladder, or does it stop and smell the roses, celebrating la joie du vivre ?

Which cities fit either description, in your view?

Often the answer depends on: (a) do you live there or vacation there (b) where you are in life (student, parent, etc) and, frankly, (c) the power of the media and their tourism marketing.

There is a Canadian city which I associate with "live to work". It is a truly great city, though, so I won't knock it by naming it. But, man, it is hustle-and-bustle all the time.

For me, the "work to live" is Paris. My biases are that I've had 2 fantastic vacations there, and recently saw the delightful, whimiscal indy movie, Paris, je t'aime.

They smell the roses in Paris. And the food, and the wine, my God, the wine. The unique sense of style: you want to approach strangers in the street and apologize for being under-dressed ("I didn't know there was a dress code!"). Art and music are highly prized endeavours. From a magnificent art gallery to the most modest bakery, there is a spirit in the air: a vibrancy, a passion. One can feel the same energy that inspired so many great philosophers, artists, chess players.

Once, along the Seine river, I approached an old man who was sketching. In my rusty French, I told him I was from Canada, and found Paris to be everything I had read when I was young. He breathed deeply, closed his eyes, and savoured the essence of the city, the moment. Oui, oui.... merci monsieur.

(I said something similar, but more romantic, to a tour guide, but suffice it to say that I made her day.)

The Point

Do you "code to live" or "live to code" ? Is coding fun -- something you want to do on your own time, or does it just pay the bills? Does a todo list of new languages (e.g. JRuby, Groovy, Erlang, JavaFX) turn your crank or make you roll your eyes?

I suspect that many readers may be like me: mostly "code to live" but sometimes stray and need to have the passion re-ignited. Though I'm in a good place right now, I have come to learn that the "ebb and flow" of that feeling -- joy to code (*) -- is natural.

I'm always interested in ways that people use to get the fire back... What do you do that makes software development feel like walking along the Seine in Paris?

Here are some of mine:

Birds of a feather. Whether it is a small Java users' group or a full-blown conference, it is energizing to catch the vibe of a group and of others' experiences. Most of my "down times" are when I'm too busy to go to meetings.

Bookstores. It is a derivative intellectual pursuit, but I enjoy merely browsing comp sci books. If you read just 10 introductions at your local bookstore, it is amazing what you can pick up. And for free, no less. What a scam! A double bonus is to actually (wait for it...) buy a book.

Testing. If you want to sneak a new technology into an organization, and still be productive, there is no better place than testing. Managers love the sound of it, and few people really care much about which technology is used -- particularly for exotic integration or performance testing. I once wrote a fun tool in Python that would hammer a web server.

Find a Problem. I blogged before about getting unhooked from a game, but there are other neat problems to solve. Solve Sudoku puzzles. Implement a domain-specific language for your Mom. The options are endless (Dr Dobb's has oodles) but especially when combined with a new language.

The Gist

That's some of the ways that I like to keep things exciting, to ensure that I "code to live".

How about you?

(*) Note: "code to joy" is different, rare and sublime... See the first post.

POJOs Gone Wild and the 2nd Law of Thermoblogs

A reminder and a few random notes:

POJOs Gone Wild

The "Win a Sticker" contest ends on June 29! Enter today... Remember, international readers, that CodeToJoy pays shipping.

Captain Neato, Twenty Thousand Bytecodes under the Sea

Here is a neat Java Powered Submarine.

Rumor has it that the team tried the software in C++, but the sub sank due to memory leaks. (not really)

Then they tried it with Scheme, but the sub kept lisping at 20 degrees to starboard.

This might be fun. Share your ideas why they couldn't use Ruby, JavaFX, etc...

The 2nd law of Thermoblogs: Entropy == Flame wars

This law of the Net is entirely isomorphic to the Second Law of Thermodynamics. Simply perform these substitutions:

• the "system" and "process" becomes the "blog" (or "post")
  
• "entropy" becomes the "flame war" (or "flames")
  

e.g. 1. To paraphrase Clausius:

The flames of a blog post not in equilibrium will tend to increase over time, approaching a maximum value at equilibrium.

e.g. 2. To paraphrase Bazarov:

The law of existence of flame wars in every blog and of its never decreasing in isolated blogs for any posts whatsoever.

As illustrated on Cafe Au Lait via the "initially interesting yet doomed to thermal death" post on Checked Exceptions

JSR 3000: Annotation Closures

(Inspired by a post by Weiqi Gao and Wired magazine's Artifacts from the Future).

CtJ Newswire
Parody City, CA
June 2010

Several industry leaders announced today that they will support JSR 3000, an initiative to add closures to the JML (Java Metadata Language). The effort ends much debate among heavyweights in the Java community,which began with the hotly-contested JSR 1969 and bitterly-disputed JSR 2001, which added control structures and objects, respectively, to the JML.

Said one industry leader, "Not only has the JML become a full Turing machine with OO capabilities, but now with annotated closures, we should see entire web frameworks in a single class file. The amount of true Java code will be miniscule, and javac and apt will do most of the work. Once we solve the problem of distributing javac and apt to customers, we will have truly arrived in a new age".

The press announcement offered the following as an example of the new syntax. The JCP website was briefly shutdown due to overwhelming volume.

// print lines of file
@MyFileTraverser extends Object
@Field("file", private)                                                                           
@Field("myClosure", private)
@Method("traverse", public)
    @Invoke("myClosure", "file")
@
@If.exists(args[0])
    @New("myTraverser", MyFileTraverser)
    @Set("file", args[0])
    @Set("myClosure", 
       @{ String line => System.out.println(line)} )
    @Invoke("myTraverser", "traverse")
@Else
    @Exit("usage: please pass a file name to apt")    
public class HelloWorld {
   static public void main(String args) {
      System.err.println(
          "error: raw JVM bytecode reached.");
      System.err.println(
          "error: please contact system admin");
   }
}

IoC: Inversion of Cognition

Eric has a post on Sets, since some people weren't familiar with LinkedHashSet. What I found interesting is that he quickly got into a pet example to illustrate his point.

My guess is that a lot of people skimmed the Collections API and saw LinkedHashSet, but it didn't stick with them because they didn't have a pet example. They were looking through a toolbox, seeing a bazaar of solutions, without a particular problem to solve.

In my experience, it can be very useful to "invert one's cognition" and think in terms of problems, rather than solutions. This is pretty much the same as the O'Reilly Cookbook philosophy. Both as a reader, and as a writer, it is highly effective.

Some better examples come from the Goetz (et al) book, Java Concurrency in Practice (JCiP):

Deque

I had read about a Deque for a long time. Alrighty: a double-ended queue, pronounced "deck". And that's all I knew. To be honest, I had no idea why anyone would use it, and I've taken the same hardcore data structures/algorithms classes that we all did.

Then I came across a scenario in JCiP: deques can be used for work-stealing. The scenario is multiple producers and consumers with a deque per consumer. When one consumer becomes available, it may "steal" work from the deque of another consumer, by removing a task from the tail. Bingo: deques come alive for me. I'll never forget that problem/solution, because it was expressed in terms that resonate. Note that this is more than just an example: it is a concept/problem that is genuinely solved by the tool.

Exchanger

Another part of the book talks about various barriers. It's kind of cool but I can tell that my mind is starting to go numb. Yes, if I had been writing example code that would help, but again, the text inverts the cognition for me with a nice, portable idea that I can tote around.

The idea in this case is a situation where 2 threads share a data-buffer: one writes, one reads. An exchanger is a 2-party "barrier" that allows the two parties to exchange objects in a thread-safe way. Great! Another example that I can stuff in my mental attic. Who knows when it will come in handy.

The gist: thinking in APIs is ok. Thinking in examples is better. But sometimes thinking in problems really rocks.

Win a Sticker: I *heart* POJOs (with pics!)

Write a clever or insightful answer to this question, and you could win a sticker, "I *heart* POJOs" (see pics):

Do you *heart* POJOs ? Why or why not?

Send your answers to codetojoy at gmail . See details in previous post. Feel free to add comments on the blog, but send a parallel email if you want to enter the contest.

ps. Eric Burke coined the phrase.

pps. Thank you to the ladies of St Louis (hello, Westport!) for modeling the prize! Y'all should write to me as well (codetojoy at gmail)

Coming soon.... A Contest for Readers

The readers of Code to Joy aren't fools: they demand more than the usual geek discussion and humor on their tech blogs. They want innovation and creativity!

And so Code to Joy is pleased to announce a new contest idea: Win a Sticker.

The first contest will be announced soon, but here are the rules, for reference:

• Readers are invited to submit a brief answer to a Contest Question. The answer may be an honest technical insight, or witty: it's up to you. (Note: this contest is for writing; it is not a coding contest.)
  
• Winners will receive a sticker! The winning entries are judged for eloquence or wit, subject to the mood and taste of the judge(s). All selections are final.
  
• To celebrate the international following of Code to Joy, there will be no more than one winner per country.
  
• Entries should be sent to "codetojoy" at Google's email (gmail). Blog comments are welcome but not eligible for prizes.
  

Stay tuned...

Here's some more info of note:

• This is a fun experiment. Despite a "grandiose writing style", this blog is not a business.
• The winner is wholly responsible for the use of the prize. I would not recommend putting the sticker on one's car.
  
• Participants must agree to allow their entry be posted to this site.
• The number of winners will be small. i.e. not every country will necessarily be represented.
  
• Winners will be contacted for their shipping info. Code To Joy pays shipping. No information will be retained or shared.

JSR 181: simplifying Web Services

This may be self-serving, but in case this is useful to readers of Code to Joy...

Here is an article on JSR 181, Metadata for Web Services. (I'm the author.)

The nano-summary:

• There are several JSRs within JAX-RPC and JAX-WS. The article surveys the landscape, and gives the context for JSR 181.
• JSR 181 acts as a facade pattern for JAX-WS: an easy interface for common WS tasks.
• With the use of annotations, JAX-WS joins EJB, Seam and Guice in the rising tide against XML configuration.
  
• Simple examples are provided, requiring only Java 6 and Ant 1.6.x

Poll: Comments on Tech Blogs (aka Diablogue)

Tech blogs are a mix of fact and opinion. A writer will receive criticism (rightly or wrongly) as sure as a hockey player will get hit: it's just part of the gig.

Because of the "fact" aspect, and because geeks are cool, a given post can turn into a useful 2-way thread between the author and commentators.

Call it *pause*... having a diablogue. (Bonus: it may also be Spanish for "evil post").

But what's the best way to conduct a diablogue, in terms of logistics? What do you think:

Option 1: Consolidated.

The gist: Use the comment feature of the blog exclusively, like a moderated micro-forum.

Pros: Easier for readers. One-click shopping -- the post, the comments, the rebuttal, all right there

Cons: Harder for writers. Most blogs' comment editors really, really bite (*). And if it's harder for writers, that ultimately impacts readers.

Option 2: Distributed.

The gist: Post a comment saying "check out the post on my site"; write the post with a link back to original.

Pros: Commentators can "stretch out" and write comfortably in their own environment.

Cons: Things can get scattered across multiple posts and sites. A good conversation might branch into its own micro-web.

Option 3: the Write-in candidate.

Some kind of hybrid of 1 and 2 is obvious, but is there another option?

Vote: Which one do you prefer?

(*) I recently spent 1/2 hour writing a thoughtful comment only to see it marred by formatting problems (and I couldn't change it). No preview, no revision, no fun.

The Zen of Code Virtuosity

(To repeat readers: if you read the initial Ether/DI post, check it out as it has been edited/clarified. I screwed up.)

As many know, this blog draws a parallel between software development and composing music, particularly with respect to the spectrum from "master" or "virtuoso" to "apprentice".

In my experience, I have learned that the masters say curious things sometimes. Here are a few key phrases. I think the masters say these more often than the apprentices.

"I was wrong"

My unofficial definition of intellectual honesty is an effort to prioritize truth over one's own ego. It's not easy: everyone falters at times. But the masters seem to have enough confidence and passion for excellence that they can keep their egos in check.

Also, they aren't afraid of failure. Beethoven's original manuscripts were marked up tremendously as he continually refined his ideas (for months, years), polishing them and making them right.

"I don't know (yet)"

This phrase echoes intellectual honesty too, but also curiosity. The masters are often intrigued by new, cutting edge ideas that are outside of their comfort zone. They're thinkers, philosophers.
If there is something we aren't sure about, as developers, then we probably aren't pushing our boundaries enough. Or we are boorish goons.

"You have five fingers on each hand just as healthy as mine."

It might be apocryphal, but legend has it that old man JS Bach said this to a student. The point is his modesty. He was Bach for freak's sake, and yet felt that it was sheer hard work that separated him from the rest. That's ego management.

I have heard similar tales about some fantastic modern guitar players. One favorite is Joe Satriani. He can blow you off the stage, pal, and yet is a regular "Joe" and a zen-like teacher in his own right.

The Upshot

I'm not a master, but I'm going to try these phrases in my next meeting. If they don't seem to fit the situation, then let's go with this Zen dandy:

I'm listening to the sound of one file merging.

Out of the Ether: Dependency Injection

I enjoy Frank Kelly's blog. He has a recent post about Dependency Injection. I had been sitting on a thought for awhile with respect to DI, and thought I'd write it out here instead of in a comment window.

(Editor's note: be sure to see the post script for strong criticism against the example and the post.)


Here's how I think of DI. We all know this is bad:

class MyClass {
private HashMap myMap = new HashMap();
}

because we should program to the interface, yes? Like so:

class MyClass {
 // more flexible, in theory
 private Map myMap = new HashMap();
}

The conventional wisdom was always:

Program to the interface, since it will be easy to change the implementation.

True that. But then the implicit kicker was:

And when you are done with your application and have been given a couple of weeks by management to tweak performance while wearing your PJ's and drinking a fine Chardonnay, you can go through the code and select the implementation that's right for you.

Whoa, Nelly! *throws RealityCheckException*. When would that be, again?

What if we tried this:

class MyClass {
   private Map myMap;

   public MyClass( ... , Map myMap ) {
       this.myMap = myMap;
   }
}

The beauty of this, IMHO, is truly profound; it took me a long time to appreciate it. Clearly, the class just uses the interface and there is less coupling, more flexibility, etc. But there is more:

The Ether

The power of DI is twofold:

(1) a given class is simplified and works with a minimal contract (the interface)

(2) there are tremendous tools available, outside the class, that allow us to really, truly make different implementations available, and swap 'em out easily. Essentially, these tools control the creation of the MyClass object, and allow us to dictate the given implementation for an interface (e.g. Map). Where are these implementations? Where do they come from? The answer is, from the view of the class: we don't know, they come out of the ether.

And that ether is powerful stuff: DI tools allow us to create mock implementations, single-threaded implementations, file-based implementations, DB implementations, carrier-pigeon implementations -- you name it. The configurations (or annotations) make it truly possible, unlike the hypothetical "free 2 weeks of tweaking paradise" mentioned earlier. You could potentially run several entirely different testing suites, simply by swapping out the ether.

To press the point even further, take the Map interface used above and now multiply this idea by any and all interfaces in your application. That ether is strong mojo.

Whether you use Guice or Spring: tap into this ether and re-discover the power of interfaces. If you're like me, you may discover they are cooler than we ever realized.

Final Score: Dependency Injection 1 Management 0

Post Script

Eric and others have made valid criticisms. See the article/comments, but here is a summary:

• I blew it on the phrase "any and all interfaces". The coolness of DI doesn't give one license to inject everything. A better version is: consider all of the interfaces in your project and then apply DI judiciously.
• My example was poor. I wanted to concentrate on the ether, and didn't have the energy to construct a "real-world" example so I went with Ye Olde Collections. I think it is an ok example to illustrate the ether, as long as one understands the criticisms against it. In fact, it might even be a better example because of the criticisms (though this was not by intent: mea culpa).
  
• I have used Spring's XML configuration, and have wondered about losing encapsulation as a danger of DI. I haven't yet tried Guice or any of Spring's newer stuff, so I don't know how that might mitigate the issue.
  

JML: JSR Modeling Language

This month, I've been writing an article on JSR 181: metadata for Web Services (WS).

A big part of the learning experience was untangling the knot of JSRs that make up the WS space: it's complex.

Actually it's a testament to the vibrancy of the Java community, and the success of the JSR/JCP process. But I think we have reached a point where the number of JSRs are unwieldy.

Because of the volume of JSRs, and also because of the relationships among them, I think we need to start looking at JSRs graphically. In fact, I think we should borrow from our friends in the UML and design pattern camp.

Consider JML: the JSR Modeling Language. Check out the examples in the diagram.


That JAXB uses annotations is an easy example, but it took me days to realize that JSR 181 is essentially the facade pattern for JSR 224! It also took some time to realize that these relationships need not apply to objects: they can apply to JSRs. (Note that many original design patterns came from architecture, not OO.)

The diagram is crude, but I tell you: whoever illustrates a schematic of JSRs on a nice, large poster will make money.

Yet another profitable idea from Code To Joy... if only there were more hours in the day. Alas, I don't have time so I donate the idea to you all.