Jazzon 2011, Day 3 – Spring 3.1 in a Nutshell – Sam Brannen

26. June, 2011

Spring 3.1 in a Nutshell – Sam Brannen

Sam gave an overview of Spring 3.1. If you don’t like XML, this one is for you.

Along with Servlet 3.0, it’s possible to write web apps that need no XML (not even web.xml).

Profiles and environments allow to use the same code in test and production. There are more concise ways to replace properties in your config. The MVC API has learned a couple of new tricks. Good stuff and probably not too far off.

Jazzon 2011, Day 3 – The Power of Retrospection – Linda Rising

26. June, 2011

The Power of Retrospection – Linda Rising

After the keynote the day before, I decided to skip “What’s next in the Java Webtier,” “Giving Your Application a Social Life with Spring Social and Spring Integration” and “Tricks of the Trade – What Every Developer Should Know About Application Security“. A hard decision but worth it. Technical details can always be learned later (or never) but social knowledge is eternal.

What’s retrospection? Well, a manager asked what the second guy did while pair programming. Answer: Thinking. Manager: “We don’t have time for that!”

In the struggle of an ongoing project, we are often too busy to stand back for a minute and consider: Are we achieving something or only spinning our wheels?

This isn’t about problem solving, it’s more like a scientific experiment. It’s considering the options, making an assumption, considering ways to disprove the assumption and then doing just that.

See, many problems we face today have no solution. If they had, they wouldn’t be problems in the first place. Customer too dumb and you want to hit them over the head with a cluebat? How could you possibly “fix” that?

But you can try different approaches to improve the situation. Maybe someone else in the team has better social skills to handle a difficult customer? Or you can hire someone to handle them? Or call in an expert to train you on the topic. Or maybe buy a book. Talk to your wife/friends/ask in an Internet forum? Piss the customer off so badly that they never dare to call you again – ever?

As you can see, ideas can start to flow as soon as you power down and sit back to … think for a minute. Maybe none of them works. Chances are: One of them will. But you’ll never know if you don’t take that hour off, walk the stress out of your system and sit down to stare at nothing and think.

That’s a retrospection. It’s a look back. What was good, bad, surprising? What do you want to do more? It’s about fine tuning, not changing the world. Even if you’re Facebook, changing the world does take years.

It’s not about consensus either. If everyone agrees, nothing ever changes.

It’s about reaching closure. It’s about that wall in Washington DC that lists the names of every soldier killed in the Vietnam War. Imagine standing there, reaching out, trying to grasp what all those names mean, what the wall means, how horrible must have happened. And world is still turning …

Your project is killed after two years of effort, huge amounts of personal stress and overtime. Well, at least it’s finally over.

You should think about everything that went bad but don’t soak in it. Also remember what went well. No time? Five minutes can be enough. In fact, it can be better than a two hour retrospective because it will be much more focused.

Keep in mind the Prime Directive of retrospections:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.


Jazzon 2011, Day 3 – Behind the scenes: Microsoft and Open Source – Gianugo Rabellino

26. June, 2011

Behind the scenes: Microsoft and Open Source – Gianugo Rabellino

Disclaimer: I have M$.

According to Gianugo, M$ knows a lot about open source. Sounds good? Maybe. “Know your enemy” 😉 Well, of course they know. OSS is a threat to their business model so they early applied their usual tactics of “embrace, extend and extinguish” to handle it.

When that didn’t work (and they found it wasn’t necessary because most people don’t understand OSS), they gave it up so they can now pretend to be “good guys” (or maybe “better guys” than they were before the year 2000).

My main objection is their definition of open: “Open” for them seems to mean “honest” or “listening to customers” or “doesn’t cost anything.”

That’s wrong. Open means: I can solve my problems myself. Example: Say I found a bug in Word. I know how to fix it. Will it be fixed? No. Why not? Because I’m just one of 300 million Word customers. My tiny complaint is simply drowned in the majority’s cry for more features.

Open source means: If I know how to fix it, I can. If I don’t, I can ask for a fix. If the original developers can’t help, and I still need the fix, I can hire someone to fix it for me! I have options. With M$ (and any other big company for that matter), I have none. For me, these people are an endless source of frustration.

Why I have M$ more than most? Because they make my life miserable every day for the past 25 years. Every day, I get Office documents that LibreOffice can’t open. And I can’t run Office on Linux. I could run it in a VM but that would infest my pretty secure computer with a viruphile OS that is hard to maintain, update and use.

Where was I? Oh yes, the presentation.

One slide said that they were open for interoperability and standards. M$ is member of a whole lot of standards committees. Which sounds great. But big companies usually become members of standards committees to make sure either theirunderstanding of the technology because the standard (so everyone else has to catch up and/or pay them royalties)  or to make sure nothing is every agreed upon. Since every committee contains at least one member of both groups … you get the idea.

It’s like religion. Question: Who goes to hell? Answer: Everyone. Proof: There are at least two religions which believe that anyone who doesn’t share their specific belief goes to hell.

Anyway. M$ is driven by money. If there is money to be made, they jump. If not, they can’t be bothered. So if the customers want interoperability, M$ couldn’t care less. If the customer pays for this, sure, why not.

For these reasons, IE9 is not OSS. But at least they’re trying to be compatible to HTML(5) – since no one really is, it doesn’t really matter. The point is that customers are running away to other browsers like Firefox and Chrome. On top of that, FF and Chrome have been leading innovation in the browser market (I’m sure the M$ marketing department disagrees and next year, we’ll see a lot of ads says that “M$ invented HTML, the Internet and Walking Upright(tm)”).

What M$ also cares for is wasting money. Support is such an area. So they decided to split IE9 into the stable, basic product for John Doe. Developers can download all kinds of cool extensions from some website (links anyone?) to tamper with the bleeding edge. When the bleeding edge has been dulled from all the blood (= something has emerged and a lot of people want it), M$ can move it into the IE9 installation package (or an update) and claim to have invented that, too.

Nice idea. I actually like it, even though I worry what it means for fragmentation of web development. But making people “trust IE9” because the base product is stable, fast and dependable, that should help to move people more quickly away from IE6 and that’s always a good thing. Of course, this mess is also M$’s fault in the first place. But at least for once, they try to clean it up.

The talk did contain two items which I agree: WebSockets are the best and the worst of HTML(5). They are a great idea and would solve a whole lot of problems that web developers face today. Unfortunately, they’re also a huge security risk.

The other thing is that cloud means “I don’t care.” Cloud computing really means that you want to concentrate on the few things that you do best and leave the rest (network administration, backups, fault tolerance, installing updates, etc.) to someone else.

Funny fact: All slides had “Microsoft Confidential” on them.

Conclusion: Gianugo sold his soul well. I talked a couple of minutes to him after the presentation. We didn’t agree but at least we did it in a civilized manner.

Jazoon 2011, Day 2

26. June, 2011

It’s day 2 and it starts with a very interesting keynote.

Jazoon 2011, Day 2 – Jazoon Rookie Award

26. June, 2011

Benjamin Muskalla showed a better workflow to handle patches by OSS contributors using Eclipse MylynSee this video for an introduction to the idea.

After him, Alessandro Nadalin showed some advantages of using REST (and when not to use it). My criticism is that HTTP caching is brittle as it stands and can cause all kinds of problems. So, yes, if the caching works, REST is great. But if it breaks, all kinds of havoc can ensue. Worse, many problems simply don’t well with REST. Twitter and RSS feed downloads? Yes. Web conversations? No.

Lastly, we had Ivo  Neskovic demonstrating Project FoX which allows to define mathematical rules to which some code has to comply. The demonstrated example (a buffer) was simple enough. As always, there was no telling how amount of work grows with code size. Most of these tools suffer from the problem that a) the effort grows exponentially (so you need 4 times the effort to handle twice as much code) and/or b) there is an explosion of test cases (so you might have all the tests but it would take years to run them).

Jazoon 2011, Day 2 – Compositional CRUD: A novel approach for doing CRUD in Enterprise/SOA Environments – Rene Mas and Thipor Kong

26. June, 2011

Compositional CRUD: A novel approach for doing CRUD in Enterprise/SOA Environments – Rene Mas and Thipor Kong

One of the advantages of CRUD is that each operation is simple to understand and implement. Every developer knows thatdependencies are bad. The disadvantage is that the operations are so simple. If you need something more complex, you have to execute many of them and this can get complex in its own right. Worse, the usual CRUD APIs only allow to execute the operations individually.

The idea behind Compositional CRUD is to be able to build arbitrarily complex commands from simple CRUD operations. All of them can be executed as a single operation (within one transaction, for example). This applies the ideas of the command patternand Promise Pipelining.

Seems like such an obvious idea, it’s probably already patented …

Jazoon 2011, Day 2 – How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn

26. June, 2011

How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn

Sander talked about frameworks and the usual problems with them:

  • How to choose the best framework from over 9’000?
  • Some frameworks integrate only specific things (like logging or building a UI), others include everything and the kitchen sink. Which is better?
  • How do you convince your management to buy a framework, train the developers, testers, support people for it?
  • How do you get the other developers to agree to your choice?

After selecting a framework, the trouble starts:

  • What do you do it an important feature is missing? Do you add it? How do you maintain it? Do you file a bug report? What if it’s being ignored?
  • Half along the project, you find a framework that is better suited.
  • How do you handle bugs in the framework?
  • When do you upgrade after a new version comes out? What if the new version has dramatic changes that break a lot of your code?
  • What if development of your favorite framework stops? Do you take over or walk away?
  • If one framework isn’t enough, you’ll find that dependencies tend to kill you because all the problems above multiply.
  • Sometimes, framework A has a hidden dependency on logging framework B but your company uses logging framework C.

The way to answer these questions:

  • Know your architecture. What do you need where?
  • Instead of using the framework directly, put in an abstraction layer that says what you want and does it using the features of the framework. If “something” happens, chances are you only have to change the abstraction layer.
  • Use dependency injection to clean up your code from unwanted dependencies.

Jazoon 2011, Day 2 – JavaFX 2.0 With Alternative Languages – Groovy, Clojure, Scala, Fantom, and Visage – Stephen Chin

26. June, 2011

JavaFX 2.0 With Alternative Languages – Groovy, Clojure, Scala, Fantom, and Visage – Stephen Chin

Stephen showed how to use JavaFX 2.0 with other programming languages like Groovy or Scala. This is possible because the next version of JavaFX has a pure Java API for everything.

It was nice to see how well Groovy and Scala fared versus JavaFX itself. Even a dedicated Xtext-based DSL might not yield much better results.


Jazoon 2011, Day 2 – Java Concurrent Animated – Victor Grazi

26. June, 2011

Java Concurrent Animated – Victor Grazi

One picture says more than a thousand words. Now imagine what an animation can say. Victor did several for us to better understand the classes in java.util.concurrent. You can find the software on sourceforge: javaconcurrenta

Here is an example:

Very nice. I know a lot about threads and concurrency (the Amiga had preemptive multitasking back in 1986) but even I was surprised by the ReentrantReadWriteLock example: If you have a writer waiting for the lock and another reader comes along, should it get the lock immediately or should it wait for the writer to complete?

My first instinct was to get all the (quick) readers out of the way but chances are that, when all readers have been processed, another one might have come along, effectively starving the writer.


Jazoon 2011, Day 2 – NoSQL – Schemaless Data-stores Not Only for the Cloud – Thomas Schank

26. June, 2011

NoSQL – Schemaless Data-stores Not Only for the Cloud – Thomas Schank

Thomas gave an overview of some NoSQL databases and the theoretical background of it.

The main points are: SQL databases get inefficient as the data grows and if you need to split the data between instances (how do you join tables between two DB servers? Even if you can, performance is going to suffer).

But there are new problems: Data can be inconsistent for a while (keyword: MVCC).

OTOH, these databases don’t need locks and, as Amazon demonstrated, any kind of lock will eventually become a bottleneck:

Each node in a system should be able to make decisions purely based on local state. If you need to do something under high load with failures occurring and you need to reach agreement, you’re lost. If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually become your bottleneck. Take that as a given.

Werner Vogels, Amazon CTO and Vice President

And since the servers can heal inconsistencies, broken connections don’t mean the end of the world. The acronym of the hour is BASE: Basically Available, Soft-state, Eventually consistent.

Interesting stuff, especially since every company owns a super-computer today. My own team has one with 64 cores, 64GB of RAM and 16TB of disk space sitting in 8 boxes spread under the desks of the developers. Not much but it only costs $8 000. And if we need more, we can simply buy another node. Unfortunately, it’s hard to leverage this power. I’ll come back to that in a later post.

One thing to take with you: If you can’t stand JavaScript but you need to write it, have a look at CoffeeScript.