A short one
Friday 23 February 2007 @ 2:24 pm
Filed under:

Here are a few lines of code I found in an application that I’m currently maintaining. I don’t know who wrote this code originally.

// Values read from somewhere
int budgetSpent = ...;
int budget = ...;

// Compute percentage of budget spent
int percentage = Math.round(budgetSpent * 100 / budget);

The last line of code is wrong. Can you tell me why? Every Sun Certified Java Programmer should be able to anwer this.

— By Jesper de Jong   Comments (6)   PermaLink
Java Scripting
Tuesday 12 December 2006 @ 4:31 pm
Filed under:

Currently i am attending the JavaPolis 2006. A nice event with interesting topics and nice interesting people to meet. It is located at a nice venue in Antwerp called ‘Metropolis‘. If you are in the neighbourhood it is surely worth a visit and grab a movie if you are there. Enough said about the venue lets talk Java.. Yesterday the JRuby guys had a nice talk about the current state of the JRuby platform and possibilities. The current JRuby implementation and Rails framework are more or less available ontop of the JVM. It is interesting because it opens possibities using the Ruby language ontop of a robust JVM environment so we can program Ruby using the possibilities the Ruby language gives us and combine this with the awsome power of Java. I cannot wait to get my hands on JRuby and start creating some applications.

— By Marco Pas   Comments (3)   PermaLink
NLJUG Masters of Java 2006
Wednesday 29 November 2006 @ 2:33 pm
Filed under:

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.

— By Mark van den Bergh   Comments (0)   PermaLink
All I want is coffee flavoured coffee!
Wednesday 22 November 2006 @ 3:03 pm
Filed under:

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?

— By Okke van 't Verlaat   Comments (3)   PermaLink
ui, gui, yui …. and beyond
Tuesday 26 September 2006 @ 11:41 am
Filed under:

Some people seem to have either too much time in their hands or are exorbitant effective spending time and energy in order to produce beauty in a browser. Take a look at YUI in combination with Yahoo.ext: just for the sake of showing an example, Jack Slocum, the creator of Yeahoo.ext, has build a rich frontend on top of a well known php based discussion system. Prabably the first time I see a rich internet framework/toolset/library coming with a decent and out of the box useful example. Pretty cool I think!! (now sit and wait untill the GWT’s, the Echo2’s, the Dojo’s and the whatever ajax branded yet to come personal-but-o-so-aha-good-looking-investments are coming with their version of dynamic skins for phpBB :-) )

— By Okke van 't Verlaat   Comments (0)   PermaLink
happy birthday alphaworks
Tuesday 26 September 2006 @ 9:41 am
Filed under:

happy happy happy, joy joy joy

This should have been posted yesterday but just listen to the podcast or read the transcript from the team that gave use one of my favourive programming toys.

— By Okke van 't Verlaat   Comments (1)   PermaLink
A short bandwagonesque view on python and ruby.
Monday 18 September 2006 @ 1:52 pm
Filed under:

[bandwagonesque mode on]

Back in the nineties OO Developers were either hard core c++ hackers or a more modest but effecient python programmers (or maybe japanese lone wolf ruby writers). Nowadays, script language practitioners are called script-kiddies and real developers use Java or C#. Ten years ago programming was all about compiling your human readable files into native machine code, today we talk about managed execution. Meanwhile dynamic langauges have always been subject to native interpreters, which during the years have been optimized in every possible dimension to get them performing. But also this niche of software development is moving. 2006 will be known as the year microsoft shipped IronPython and sun brought in the JRuby developers (Does that mean after the movement from sourceforge to codehaus, the project will move again to java.net???) Within a few years C# and java developers will become the old fashioned hackers and the rest of the programming population does OO in a more dynamic way. Want to follow the buzz?, see google’s visualizations here and here (and probably in the future here also) 

[bandwagonesque mode off]

By the way, do not forget to attend the JRuby on Rails Javapolis session this year. And another by the way, and that is why I used the bandwagonesque tags, non-mainstream languages and the concept of managed execution is not something new. Boo  and Groovy are just two codehaus examples but I think Scala and Nice are also worth mentoning. And as a final by the way, this slightly sceptical view on scripting languages just made me realise I started my career ten years ago with the most underappreciated scripting language in existence :-)

— By Okke van 't Verlaat   Comments (1)   PermaLink
what you describe, is a mess not an environment.
Sunday 10 September 2006 @ 9:49 pm
Filed under:

Sometimes a simple one liner found deep down in some active message forum thread is worth a seperate blog entry.

> Apollo is cross-platform desktop technology mix that
> allows you use Flex/xHTML/Ajax/PDF on desktop, use
> filesystem, DBs, networking and so forth.

“what you describe, is a mess not an environment.”

This quote, coming from (yet another) Javalobby discussion about the future of java on the desktop, hits the nail right on the spot. Due to the lack of a decent environment for application distribution we’re trying to fullfil the needs of richness with a mess of browser techniques that make application development look ancient again. We have spoiled our end users with the most fabulous human-being to machine interfaces and meanwhile, due to some rediculous narrowminded views on how end-users are allowed to access applications (actually do their job), we have been selling ‘no, sorry, not possible, technically unattainable’ for too many years. And instead of looking at a feasible solution for this problem, which indeed must be found in an environment and not in a trick, we keep on messing around with whatever technique as long as it is applicable within a browser. At this years JavaOne, Aerith has shown what is possible. The future of Java on the desktop is not a question, it is an idle void waiting to be filled. Maybe it is time to replace the internet browser for the sake of richness?

— By Okke van 't Verlaat   Comments (3)   PermaLink
Having fun with Spring AOP II
Wednesday 6 September 2006 @ 5:42 pm
Filed under:

After my initial explorations of the AspectJ-support offered by Spring, someone (actually, I think it was google again) pointed me to this article about the drawbacks of proxied aop. A good read written by Vincent Partington that shows the internals of  how and why a proxy based aop framework can ignore your carefully injected aspects. A ‘must-be-aware-of’ for every Spring 2.0 user!

One commenter on Vincent’s entry suggested one could use the not so stunning but efficient AopContext.getCurrentProxy() call instead of refering to the ‘this‘ pointer. Besides being not beautiful (actually it is butt ugly but that’s a matter of taste which reminds me that programming just like cooking is actually all about (good) taste), getting hold of a proxied twin is in complete contradiction with all principles of aop: Code and cross cutting concerns should be seperated. The fact code needs to be aware of being proxied is more a showstopper than a workaround.

Nevertheless, once accepted this contradictious aproach, the idea came in mind to address this as just an aspect of implementation, an architectural constraint so to speak: ‘Every class or method that is subject of being proxied must be aware of its proxy object‘ (Note, I still do not agree with this rather bold statement, it is just a hypothetical aspect that I’m using for the sake of the nation to have some fun with Spring AOP). How can such an aspect being implemented using Springs AOP features?
First of all, somehow a mechanism must be in place to denote proxy aware classes. To do so, I introduced a special annotation:

public @interface Proxied {}

And of course some point cuts reflecting the usage of this annotation are required:

public void withinProxiedType() {}

public void executingProxiedMethod() {}

The first pointcut refers to classes declared with the @Proxied annotation, the second one refers to the execution of methods decorated with this annotation. Note the subtile difference, the second pointcut gives a fine grained approach were to intercept and were not.

After the pointcut definitions, it is time for some goofy advice how to deal with the proxied execution of methods:

@Before(”(withinProxiedType() || executingProxiedMethod()) && this(proxy)”)
public void beAwareOfProxiedExecution(JoinPoint jp, Object proxy) throws Throwable {
  // ….. ????

A dirty (but what the hack, the whole problem smells) trick injecting the proxy into the usual suspecious subjects can be used at the // ….. ???? location. And for that, I’ve mixed the advice with some reflection sugar under the assumption every proxy aware class has declared a member field called ‘proxy’. The code is to long to post here but without field caching and exception catching it looks like this:

jp.getTarget().getClass().getField(”proxy”).set(jp.getTarget(), proxy);

Instead of using ((MyService)AopContext.getCurrentProxy()).someMethod it is now possible to use this.proxy.someMethod and as a bonus not every but only an exclusive set of classes is effected.

So what have I learned from this expedition? Well, not so much about the dangers of proxied aop, the previously mentioned article already let me frown. And not so much about proxy awareness either, that seems to be some kind of wicketness by nature. But more about the possibility to define annotations and put the actual semantics of these annotations in seperate aspects. And whether that is evil or not, is probably again a matter of taste. But at least it is a funny and even elegant way of processing annotations using Spring AOP.


Attached Files:

— By Okke van 't Verlaat   Comments (1)   PermaLink
a few quick (must) reads ….
Monday 28 August 2006 @ 10:54 am
Filed under:

Five habits of highly profitable software developers for those who might think writing code can be career limiting

Or are we doing something wrong?


— By Okke van 't Verlaat   Comments (0)   PermaLink
« Previous PageNext Page »


Blog Categories

Browse by Date
August 2007

Upcoming Events

Monthly Archives

Recent Comments


XML Feeds Option

Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS