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)