Rich Internet Applications (RIA)

Speaker: Václav Pech, JetBrains (makers of the IntelliJ IDEA IDE)

Václav begins by citing author of findBugs tool bug categories.

He goes on to presents some nice examples of each of these bug types. Then shows Intellij plugin for static code analysis with on both demand and on-the-fly analysis (very comfortable for the developer).

Adding bug detection to the tool means specifing an undesirable pattern in the program’s AST. Speaker demonstrates creation of a new rule using „PMD rule designer“.

After naming three of the most popular tools (findBugs, CheckStyle, PMD), Václav demonstrates the use of these tools in NetBeans. The SQE plugin integrates the above tools into a unified view. Nice.

Then, just to prove he’s not all about IntelliJ, he shows FindBugs and PMD in Eclipse.

Now back to IDEA again: We see a powerful code analysis and quick-fix tools in IDEA, as well as the ability to define new tools.

Next up: New JetBrains language-aware annotations, which can also provide language-specific code completion in cases where SQL, CSS or any variety of languages are held in a Java string. Very nice, although limited to Strings as opposed to derivations of CharSequence (StringBuffer, StringBuilder).

Václav’s slides are available here.

Summary: This talk presented a useful overview of static cod analysis tools. A sales pitch for IntelliJ? To some extent, perhaps. But having used NetBeans, Eclipse AND IntelliJ in the past twelve months, I can testify to IDEA’s superior support wen it comes to code analysis (as well as other things.) And no, I am not being paid to write this.

Speaker: Mario Fusco, LambdaJ creator

What makes me think this talk is going to have something do to with the lambda calculus, a subject I recall enjoying greatly during my Comp-Sci degree?

So… the heavily accented Mario describes the motivation for creating LambdaJ: To create a way to select beans of particular properties without all the hassle of loops i.e. iterating.

The result: A DSL to manipulate collections in pseudo-functional, statically-typed way.

LambdaJ comprises 2 main features: forEach and sort. Each of these methods are importable via static import.

forEach(personsInFamily.setLastName(„Fusco“);
sort(persons, on(Person.class).getAge());


The result is a compact was to express collections-based operations as a single line of code as opposed to using a sometimes complex loop, locally declared variables etc.

Mario shows several examples, which make this compactness quite clear.

However, he goes on to points out that LabmdaJ five times slower (average) than pure Java with his examples. Performance takes a because of all the reflection that goes on. However, he performance hit thinks this is unlikely to prove to be the bottleneck in practice.

Some other limitations:
• Cannot infer type to be returned because collection class parameter is not reified at runtime.
• Cannot use with final classes because cannot create dynamic proxy for final class.

The LambdaJ project is open-source and is hosted at Google Code.

Question raised: Why not use hibernate criteria query API? Mario: Yes, can use this.
LambdaJ is typically used in business layer after data has been fetched from DB (e.g. via hibernate.)

Presumably, then – for LambdaJ to be worth while to use in practice – you need to have a situation where multiple evaluations are performed against a previously fetched result set. This would then (potentially) save multiple fetches against the DB, depending on the queries involved.

Mario’s slides, which show plenty of code-samples, are available here.

Summary: I sense a slight buzz of skepticism emanating from the audience and my feeling is reenforced when very few questions are posed. Whilst LambdaJ code is significantly less verbose than its Java equivalent, I suspect the situations in which it could be used are relatively few in number.

Oh: And I was totally off about LambdaJ being in someway related to the Lambda Calculus. Neither have loops, that’s true, but the commonality ends there.

Full title of talk: Rapid Dynamic Modular Application Development with Impala, the Simple Approach to Dynamic Modules with Spring

Speaker: Phil Zoio, Impala creator

Phil begins by highlighting a major weakness of basic Spring: The single address-space available to all the beans, which becomes increasingly unwieldy as number of classes/beans increase. Impala enables the developer to group beans into logical modules, which can be subsequently swapped out dynamically.

Phil goes on to demo runtime-changes to a spring config as well as a bean implementation class, which result in Impala automatically re-loading the modules concerned. This is achieved by breaking the static (compile-time) coupling between client and implementation code.

Phil now shows a neat little interactive test runner, which I assume is part of the Impala package. One of the commands enables the user to explicitly reload a particular module, which is obviously more efficient than reloading the entire app. Using this in conjunction with the dynamic replacement of code results in extremely fast test/fix-roundtrips.

Phil now talks about the difference between the Impala and OSGi approaches. No third-party library versioning with Impala – in contrast to OSGi. OSGi, however, is more complex was never conceived for large enterprise systems.

Phil’s slides are available here.

Summary: An informative even if (again) somewhat dry talk about a potentially interesting tool. Of course, one can’t judge the effectiveness of the tool on the basis of a single presentation, especially when it comes from the tool’s inventor.

One final thing: Phil didn’t mention JSR294. Methinks the discussions on how to best modularise Java are going to persist a while…

Speaker: Matt Brasier, Principal Consulting LTD
Speaker/company background: Non-functional requirements.

Matt’s philosophy:
• Good understanding is the best performance/tuning tool
• Common & open source tools
• Observe, hypothesize, tweak, test
• Trust no-one

He goes on to describe three case studies, which demonstrate how he puts this philosophy in practice.

Matt’s slides (which also outline the case studies) are available here.

The key message for me is the application of systematic analysis, hypothesis formulation and testing. This can, in fact, be described as a scientific approach, which gets a big thumbs up from me.

A second key message was the high value of a centralized repository of problems/solutions. This is apparently what Matt’s company has set up, and the repository now represents significant intellectual capital for the company.

Summary: I found Matt’s didactic style a tad dry and bullet-pointy; but all in all the substance made up for this and for that the talk was indeed worthwhile.

Expectations are high as Thought Works’ Neil Ford takes to the stage. The title of his keynote: Predicting the Future

Neil wants to advise us how to avoid becoming IT-dinosaurs… and I have to confess I’ve chuckled at the occasional COBOL-developer joke on more than one occasion. So I’m all ears!

Yes, we’re bad at predicting future outcomes. Neil cites the classic Monty Hall problem, which shows human ineptitude when it comes to evaluating conditional probabilities.

Talking about paradigm shifts, he cites the iPhone, and notes that the big hit applications have generally exploited not just the device itself, but have combined numerous features of the iPhone platform.

He notes that Moore’s law can no longer by relied upon to give us a doubling in app performance over an 18 month period, and that WE – the developers – will need to achieve greater parallelism in our software if we are to profit from multicore processors.

Functional languages have an important contribution to make here (names Haskell, Scale, Clojure, F# as examples) as they to not suffer from (or are less susceptible to) synchronization and locking issues, which is what makes thread-programming in languages such as Java so difficult to get right. IN particular, Ford names Clojure as a potentially exciting intersection between dynamic and function languages in the sense that it gets the best of both worlds.

We are then reminded that warfare is frequently a source of (destructive) innovation; and are then advised to heed the warnings of Dick Feynman (physics genius, communicator and contributor to the Manhattan project) and George Orwell (author of 1984 and prophet of pervasive government surveillance).

[So where are we going with all this Neil? It'll be killer robots next!]

Well… there you go.

Now here’s an interesting prediction from Ford: Apple to become the world’s biggest bank. It’s true: The iPhone has increasingly shown it’s ability to generate huge turnovers via micro-payments.

The final quote in this quote-heavy keynote comes from from management guru Peter Drucker: „Best way to create the future is to create it.“

Summary: Neil’s got the gift of the gab and he’s a role model for effective presentation style (bullet-point suckers take note). However, on this occasion his chosen collection of weighty quotes and iconic images did not quite add up to a the kind of coherent narrative on “Predicting the Future” I would have liked. As for how to avoid my own dinosaurification: I’m gonna build me a killer robot!!!

So here I am at my first ServerSide conference in beautiful Prague in the Czech Republic.

In the next few posts I’ll be blogging my impressions of TSSJS.

It’s a relative small gathering and a relatively small program (2 days.)

For the record, here’s the agenda.

TheServerSide editor Peter Varhol kicks things off by introducing Keynote speaker Neil Ford…