Skip to content

NFJS, the Magazine Publishes First 2012 Issue and Big News

March 9, 2012

NFJS, the Magazine - March 2012 CoverThe first issue of 2012 has arrived and it comes with good news for the thousands who will attend No Fluff Just Stuff stops this year—every attendee will receive a 2012 subscription to the magazine as part of their registration fee.

The March issue is a strong start to the year and includes two Scala articles, a look at one of the biggest new features of Groovy 2.0 and a demonstration of application portfolios for enterprise architects. Abstracts to the articles are below.

If you’re intrigued enough to want the full articles, you can get a full 2012 subscription here for U.S. $50.






Safe and Sound with Groovy 2.0

Hamlet D’Arcy

The big news in the Groovy world is the upcoming release later this year of Groovy 2.0. It’s been five years since the 1.0 release, and in that time we’ve seen five minor updates to the Groovy language, the most recent being version 1.8 last year. Don’t worry, the major release is backwards compatible with previous Groovies. The 2.0 increment is earned because of the size and scope of its biggest features: modularization, invoke dynamic support, and most importantly an upgrade to the static type system. Groovy 2.0 will contain a static type checker which validates your code as part of the compiler, similar to what you’re familiar with from Java. The final class files and bytecode produced is still the same as before, but with this feature you have the safety you expect from Java with the conciseness and expressiveness of Groovy. Let’s explore this feature and see what it’s all about.

Log4JFugue ReWrite, Part 1

Brian Tarbox

It’s the old chicken and the egg problem: until you have experience using a new language you can’t convince anyone to let you use the language. You can learn a language’s syntax from a book or a class but only experience with the language can give you proficiency.

The Cloud and Application Portfolios for Enterprise Architects

Ken Sipe

There is much diversity in the software applications that run the enterprise. The diversity can be recognized through a large number of factors from mission critical to supportive, from complex to simple, from costly to relatively inexpensive. Often organizations tend to treat all or many of these applications with the same level of commitment and support. But does that make sense? Would there be value in understanding which applications are part of our core business? And which ones merely support our business? By better understanding the business applications, their costs in terms of software and hardware, their classification in terms of supportive or core to our business and the level of their maturity and stability, we can better access our choices in software and platform selection to maximum the business ROI. That is what application Portfolios are all about. It is the collection of this intelligence in one report which can help us to be more responsible with our resources.

Scaling up and out with Akka

Nilanjan Raychaudhuri

Hanging by a thread is the punishment for shared state concurrency

– Gilad Bracha

Let’s face it, building a concurrent or parallel application is hard. Only a handful of programmers can actually write a “correct” and well-behaved concurrent application. We can all roll our sleeves up and build a multi-threaded application but will it function correctly? Will be it free of deadlocks? What about livelocks? Not to mention the hours we have to spend in debugging issues. The culprit is mutable state. Actually, it will be easy to write a correct concurrent application using threads if we don’t have to share data or state between running threads inside an application. Think about it for a moment, no shared state means no locks and no synchronized. It’s like all the lanes are open in a road and other cars block no car. It’s quite hard to imagine that because threads encourage shared state concurrency. In fact, I will argue that threads are a much lower abstraction for building concurrent and parallel systems. We need much higher abstractions and building blocks to build applications that help programmers to build concurrent applications easily without worrying about too many details.

Leave a Comment

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: