Sunday, April 29, 2012

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.

Tuesday, April 17, 2012

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.

Sunday, April 15, 2012

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
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.

Tuesday, April 10, 2012

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.