Thursday November 23rd, 6:30 am. Eric Ettes and I are on our way to Rotterdam to compete in the “Masters of Java 2006” contest (MOJ) organized by the “Dutch Java User Group” (NLJUG). Because of the bad weather, and the thousands of MOJ spectators crowding the Dutch freeways 
, we arrive a few minutes after 10am. We missed the coffee and test round.
A short description of the environment we just entered: the contest is held at a games shop in the center of Rotterdam. One of the sponsors’ description: “MOJ, held at the GameSyndicate in Rotterdam. A place with an excellent hackery feel to it - and bad lighting”. The room is filled with computers, in some corners PS2’s, Xbox360’s or GameCubes can be found. A big screen displays the remaining time for the current assignment, along with a list of the competing teams. Also visible is which team is currently compiling or running unit-tests (accompanied with the green/red lights for succeeded and failed tests).
About ten minutes after acquiring a computer, the first round begins. An automated gong marks the start of the round, the assignment pops up on our screen. For convenience a paper version of the assignment is handed out to all teams. The first assignment is not too much of a hassle, same goes or assignment two. At least we’re not going home with zero points. After each assignment a graph is shown to display the points each team scored (total score including the last assignment). The faster you finish the more points you score. The difference between the teams is not big, however there are a few teams not finishing the first assignments in the available time (30 minutes per assignment). Not really noticeable in the score graph, maybe to ease the pain. A short chat with one of the contest organizers points out the assignments go from (relatively) easy to difficult. This is repeated after the lunch, so the first assignment after the lunch (six assignments for the entire day) will start relatively easy again.
We misjudge the third assignment, but we’re determined to make up for the loss after the lunch. We’re lucky because the forth assignment seems to use familiar techniques, we soon have an idea of what the solution must be. In our enthusiasm we miss a hint in the assignment. After fifteen minutes this appears to be crucial as some of the teams already submitted their solution. We didn’t even run a unit-test yet… we don’t finish the assignment in time, zero points 
. I’ll leave the remaining two assignments out of the review, we didn’t score that well (read: zero points ).
This doesn’t really matter, we went for fun and fun we had. The atmosphere was good and the assignments were fun and challenging. After each assignment the solution was reviewed and the background was explained. Leading to “ah, of course!” reactions. To get an impression, the assignments of the 2004 and 2005 contests are available on http://mastersofjava.2en40.nl/Assignments.html. Together with the contest software (same URL) these assignments can be tried on your own computer.
Overall it was a pleasant, inspiring and most of all fun experience in an appropriate setting. Next year Eric and I will be present again, then for a higher end ranking. Maybe we’ll see you there.
External links:
http://www.nljug.org/pages/events/content/moj_2006/ - MOJ homepage
http://www.gamesyndicate.nl/ - The setting this all took place in (link: Foto albums). http://mastersofjava.2en40.nl/ - The competition software is available here, also available are the assignment of 2004 & 2005.
Never thought I would ever quote Denis Leary in a J2EE context but I’m dying for coffee-flavoured-coffee right now. Just one (damn strong) taste of coffee which strikes the tongue and keep you awake. I’ll try to explain
The immediate cause: InfoQ’s has published an interview with Gaving King about the evolution of Seam, Gavin’s version of a framework telling you how to build (web) applications. I’ve written about Seam before and at that time in my opinion the framework was based on some interesting ideas and principles but lacked simplicity mainly caused by hard to set-up working examples. Never looked at it again (although the intentions were there ….) and I’ll point out immediately I’ll probably won’t look at it right now. So what’s so interesting about the interview? Besides some nice food for thoughts about the implications of a fine grained AJAX approach on database load and some old insights about the effects of state management on clustered environments, not very much. Except for one small comment Gavin makes as a reply to someone commenting exactly what has hit me one year ago. Let me quote:
Comment: I haven’t gotten the time to try out the new Seam release but I hope that setting up a project has gotten easier.
Gavin King’s reply: seam-gen makes it *super* easy, at least for EJB3 on JBoss users. We will be working on expanding the functionality of seam-gen to support other usecases (JavaBeans+Hibernate, Tomcat, J2EE, etc).
And that answer shows exactly what is completely wrong with the so called enterprise edition of java: There is no simple straightforward one-way road for doing things! Choices, choices, choices and a lot more choices that make life easy to model but hard to implement. Isn’t the power of application frameworks that choices are made four you? I would expect a framework like Seam dictates me to take the EJB3 route and pave things in such a way I really start to like the usage of EJB’s. Gavin, seam-gen is okay the way it is, actually it is right what was missing in your initial try. Instead of focusing on other choices, focus on more/better/advanced code generation! Expand into real functionality and help developers by filling room instead of giving it. Another illustration from the exact same interview: the different JSF frameworks Gavin lists. They seem to talk with each other to guarantee smoothness. Gavin calls this maturity, I rather use the term abstemious. A small sidestep without going into a fully blown JSF discussion but isn’t it remarkable (that’s the right word for maturity!) within EE we need a standard (JSR 299) as a glue between two other standards (JSF and EJB) in order to deal with application components in a unified way.
Right now I see a lot of developers (technical designers, architects, name them) spending too much ineffective hours on the which framework to utilize and which standard to adopt question. (not even mention the effort that can be thrown away due to steep learning curves and unexpected showstoppers after the answer to this question once again has lead to unknown trails). One can argue technical design is all about decision making and deciding what to apply is part of it. But in my point of view, technical design is all about the decisions that need to be made in order to translate a business problem into a technical solution. It’s not about choosing frameworks for every layer we can think of. Why are we programming Java? Not because at the start of every project we reconsider it. Nope it’s because we know the language and we know the language is capable of building what is desired in a (cost) effective way. And maybe once in a while we enter some self reflective mode to find arguments that reach beyond the arguments needed to make choices in a project context. And once in a while we pick up innovations, jump on bandwagons and maybe leave the paths we’re walking. Simply because we (as in the average software developer) know that when we do this every day, we can not keep pace with those who don’t.
Why is it frameworks and standards are treat in a different manner? What makes the adoption of yet another framework or standard so tempting? The steps of changing seem to be relatively small. Due to the it’s all Java isn’t it and hey we have a new project so what the hack we’re here to learn aren’t we mentality, risks are not identified clearly. And as a result, unified application development is a farce and for every different twist, more glue is needed. And as soon as the need for glue is identified by more than one developer, new frameworks and standards arise.
Note, this blog entry is not meant to bash Seam nor the interview. It is meant to address a fundamental problem that has been floating around for a while and has been addressed in the past but seems to be persisting enough to get repeated every now and then. And Seam just functioned as a trigger (this time). Everyone who like to use Seam, go ahead, fine with me. If you do not mind, I’ll focus (projectwise) on a Spring based application design until Rails has really swallowed the way I think 
. But if you use Seam, stay with it at least the coming years (and so, stay with EJB3 and push Gavin to put all his energy in this choice instead of serving all other ways to technically layout an application).
A final thought: Is it a coincident Joel on software has published an article about choices (=headaches) on the exact same date as the interview publication? It probably is. But what Joel describes (15 ways to shut down your laptop) is exactly how we (as in the java community) build applications. Nuff said. Where’s my coffee?
