SVWJUG: Actors in AKKA

I went to a talk titled "Composable Futures With Akka 2.0" at the Silicon Valley Web Java Users Group at the famed Googleplex.  It was by Mike Slinn who has this new book with the same title.  Akka is a concurrency library for Scala and Java.

To AVOID the code-equivalent of this
race-condition, use Akka Futures.

One of the more interesting features of futures is that if you take quotes out of context, they can be hilarious:
"[You can] attempt to change the future, you will fail." --Mike Slinn, apparent determinist

It was a highly technical talk revolving around concurrency, everything that can go (easily) wrong and how to make sure that it goes right.  Mike was a great guy and posted his slides as well.

The tl;dr: Futures will let you have deterministic multi-threading.  If you can't tell, this is a big deal in that you can be confidant that your unit tests will mean that the app works correctly in production (no tricky race conditions!)  However, futures don't scale to multiple mother-boards so it isn't a grid-computing solution.  Futures are also composable and immutable (see quote above).

Concurrency is going to be increasingly important as the clock speed of silicon has basically been maxed out and Moore's Law is only continuing due to more cores, so if you want your program to run faster in the future than it does today you'll need to use concurrency.  If you're going to use concurrency, make it as predictable and repeatable as possible (e.g. eliminate race conditions).  Akka Futures let you do this.

Update: Mike Slinn also has a related article on InfoQ.

A Technique on Comments: The Separation Banner

In a lot of commenting best practice articles much ballyhoo is made of commenting in the small (single lines or methods) or at the class level (headers, footers, etc), but it seems hard to find anything in between (e.g. what is a good way to separate major parts of a single class).  This article will explain a technique I've seen used, but haven't seen named before or expounded upon: The Separation Banner.

Quite simply, a separation banner is used when you need to demark major blocks of a class or other source-file (assuming you aren't using Java) to aid in visual navigation and in keeping the class in order.  The pattern I've seen the most is a line of slashes (i.e. enough to fill up to the 80 column), two slashes + text, and another line of slashes.  E.g.

  //////////////////////////////////////////////////////////////////////////////
  // IFoo Implementation
  //////////////////////////////////////////////////////////////////////////////

Other examples for the text inside can be things like "Accessors" "Static Methods" or "Inner Classes".

Humorous Image brought to you by
Digital Storytelling and The Simpsons

In general, I have found the separation banner to be quite useful, and created an Eclipse code completion entry for it so I can avoid adding all of those slashes every time.  As always, you can have too much of a good thing so having one banner for every five methods or more (roughly) has worked for me.

So, next time you frequently get lost in the inner muckings of a class, consider adding some additional structure with a separation banner.

Best of Perl - Plain English if Statements

I worked with Perl for a couple of years and I miss being able to write code that feels like plain English.  I've managed to capture a bit of this into plain old Java by using self-documenting booleans instead of actual statements in if statements, as in the following:

final boolean fooExists = foo == null;
if (fooExists) {
  // code here
}

Hater's Gonna Hate at Zoitz.com

This seems almost too simple to deserve the declaration, but you can also write more complex statements like "if (fileIsOpened)" or "if (stringHasContents)" (i.e. not null and not empty / blank).  In particular, it helps when re-factoring someone elses code to understand what an if block actually does or MEANS.

NOW I See: The Realized Benefits of Unit Testing

We all know the things that we are supposed to do, but don't as much as we should: eat fiber, cut down on sugar, don't be sedentary, exercise, eat fruit, unit test.  Blegh!

Not my exact point, but pictures about
unit testing are hard to find!
(Image from Reportnet)

For the last part at least, I came across some actual useful results.  Before, whenever I wanted to unit test a class, I didn't write a test for it before and usually had to ramp up on another technology to boot (JUnit3 vs JUnit4, HttpUnit, DBUnit, Mocking) or realize that I really wanted an integration test (jMeter, Selenium).

This time however, I spotted what looked like incorrect code and there was already a unit test for the class!  I was able to write a short test that verified the bug (i.e. wrote a failing test), fixed it and reran the test successfully!  All this in less time it would take to run mvn verify (including deployment to WebLogic)!

I'll be a bit less loathe to write tests in the future now, since I actually SAW that "it's better in the future" thing they say about testing.

Maven Reporting Configuration

A small cheviot caused me a lot of problems with Maven Reporting.  As it turns out, configuration in the pom.xml file under project/build is completely ignored when running mvn site!  

Live and learn.

Character

In software engineering, as in much of life, there is no substitute for good old-fashioned character.

Reference.com has a definition of "moral or ethical quality: a man of fine, honorable character."  In particular (for creating great software), exemplifying the virtues of industriousness, truth and courage.  The practical application of industriousness is obvious (even when your code is compiling), but truth and courage are needed when a deadline isn't going to be made, or a critical bug is found.

Thanks to Motifake.com.

Character is especially important, as the client or boss frequently has less technical knowledge, and counts on our trustworthiness and expertise (see also, information asymmetry).

This may sound disingenuous from an author who shamelessly plugs this blogs in comments and posts demotivational posters for the links (I mean, for the readers), but even though this is a new profession, lessons from ancient Greece about virtue and character still hold true.

Thank you.

Drop-down Form Submissions in Trinidad

I've recently been doing this the very wrong way.  So I'll be going over the wrong way, and the right way.

The embarrassingly wrong way, is to have an Apache Trinidad drop down followed by a command link.  You set the onchange of the drop down to document.getElementById('commandLinkId').click() and have the command link do the submission.  I swear I found some webpage that recommended this, but I can't find it anymore.  As a side note, if you're doing things REALLY WRONG you can put the value of the dropdown as a variable instead of a property and try to read it in the actionListener of the command link.  This method may truly be Daily WTF worthy.

The less wrong way (using Trinidad), but the seemingly standard way to do it in normal JSF to do it would be use onclick="this.form.submit()".  This is a decent way for normal (non-Trinidad) JSF, but Trinidad makes it even easier!

The RIGHT way is to use Trinidad's autoSubmit feature.  This not only fixed a bug (doing it the VERY WRONG WAY resulted in a race condition with the version I was using), but saved lines of gristly code, avoids JavaScript (being used directly) and cuts out an invisible commandLink.

Please, please avoid my foolishness.