things i'm paying attention to

Yeah, Yeah, I know: a list of things I'm "paying attention to" is just another way of saying that I have no ideas or opinions of my own at the moment.   Sort of like the tour guide at the Duff Brewery when he says, "We've got a lot of exciting new ideas in the works."  Homer presses him on it, "Like what?"   The guy is dumbfounded by the probing question and stands mute while we see a single pipe in the background originating from one big vat of beer and then splitting off into three chutes labeled Duff Dry, Duff Dark and Duff Regular.  Sort of like that.

Actually, I have a lot of opinions and even some hair brained ideas.  Most of my technology-related opinions today are centered on the increasingly important constructs enabling software to run efficiently and correctly under truly (and highly) concurrent conditions.  Lots of adjectives there.  This is increasingly important for (at least) two reasons: 1.) More and more machines have more processors and more cores per processor and 2.) More organizations have the need for larger scale systems, generating more data, requiring significantly more parallel (read: concurrent) processing in order to match its scale.  Often this is distributed concurrency (which has its own challenges) but within that larger framework exist increased needs for in-process concurrency.    Ya can't really scale up and take advantage of additional processors on a box if the software itself was not designed to execute concurrently.  That means doing it efficiently and correctly or suffering the consequences.

Java 5 provided a whole host of high-order concurrency capabilities to the JDK with java.util.concurrent and Java 7 is adding the fork/join construct (the master of java concurrency, Brian Goetz, explains the latter here).  Still, even when we get to the point where Java 7 goes first GA and then mainstream (a few years off), all of this good stuff is still fundamentally built on the concept of synchronizers guarding shared, mutable data, and that's pretty darn low level for your average developer to be able to reason about consistently.  One slip-up and you've got a ticking time bomb.  A time-bomb that often doesn't go off until you're in production running on machines with more and faster processors with additional cores than ya had in development or QA.

Concurrency is something where Scala shines. I've written elsewhere on this blog about my love-hate relationship with Scala, but for highly concurrent capabilities running on a JVM, it's only love-love I have for this half-breed OO/functional concoction.  After all, Scala is short for scalable.  The reasons for this are two-fold: 1.) Scala's Erlang actor framework provides a high level mailbox messaging construct that is easy to reason about when it comes to formulating software that is correct in the face of concurrency and 2.) Scala's functional programming heritage means it's easier and more efficient to make your data immutable than it is with Java, and we all know immutable data is one of concurrency's best friends.

I said I was just going to list the things I'm paying attention to today, and so now I will:

• Elastic Search
• Scala 2.8
• Heroku
• Akka Project
• How to Measure Scale (an "oldie" but a goodie)
• Comparison of grid frameworks
• InfoQ Comparison of Spring MVC and JAX-RS
• InfoQ: Automating Operations with Spring Batch and Spring Integration
• InfoQ: The Future of Flash
• JClouds
• IBM's Java Concurrency Practice Series by Brian Goetz, et. al.