Just received my new lens from AC-Foto in Germany. Fast internet service, UPS-shipped, reasonably priced, and what a difference with my previous elderish Nikkor 80-200 lens: contrast and color are great! It took me some time to stop longing for more expensive 80-200 f2.8 glass from either Nikon or Sigma, but given my current time and ambitions, this lens seems more appropriate for my modest photography endeavours. The focussing isn't as fast as my D70 kit lens, and quite noisy even compared with the older one, but the quality sure is better. We're leaving this weekend for the Ardennes with a couple of friends, and I hope the weather will be good (and my companions won't get bored with me photo-geeking away).

More often than not, I have troubles understanding Sam's short, insinuating, future-telling posts about OSS ecologies. My take is that Dave shouldn't worry too much about opening up Frontier: its main USP is that it is a proprietary product, which creates a following of loyal users willing to make the most of their precious dollars - even form a community to that effect. About the same as what will happen to Movable Type 3, for which I'm not going to order an upgrade (just because I'm too lazy to figure out whether I actually need one - I hate complicated license schemes, and complicated really means that I need to count users/blogs and so). Frustrated, I was hoping to find out how we are/should be doing in this list, but alas it was again a list for large enterprises and not for small shops such as ours. Oh well - at the very least you now all know about my bedtime reading. ;-)

Here we go for our yearly dose of camp. Warning: I'm not even trying to be nice here. It's Eurosong after all.

1. Spain: another boring Latin song, not even poppy. Yawn.
2. Austria: none of the three singers is able to sing in tune.
3. Norway: bombastic powerslow, and his English is funny.
4. France: comb your hair, boy, and what's that white women-object doing on stage? The song ain't that bad - according Eurosong norms of course.
5. Serbia & Montenegro: a stylish but bloodless attempt to mimic Belgian's 2nd place of last year: Urban Trad.
6. Malta: with a booty like that, she should stop wiggling. A very awkwardly feeling popduet (oh - not in tune as well). First song we actually started giggling - naaah, make that: laughing.
7. Netherlands: a very bad version of an already trashy song "More than words" from Extreme.
8. Germany: yes, he's ugly. And the song is boring, too. Not too bad for a soul song however, but definitely not Eurosong. And he shouldn't attempt high notes as well, as he's almost dying while trying.
9. Albania: fat arms! I'm missing volume - and she's pulling notes through all sorts of bends. Sing through the mike please!
10. Ukraine: I was expecting more actually. Messy. And I hate the shouting. Still, people will love it.
11. Croatia: hey, the German is back? This, my dear friends, is a very boring song. And singing in tune is becoming a scarce commodity in the new EU.
12. Bosnia & Herzegovina: singing becomes murmuring. Oh no, if he sings it becomes worse. This is really very bad, and his pink dancers won't help. Bring this man to a decent end please.
13. Belgium: this was her worst vocal performance so far, alas. But still it's a hell of a song.
14. Russia: a circus act won't help a badly sang song.
15. FYR Macedonia: why am I thinking of Harry Potter? Still, besides a lot of repetitive parts, it's a halfway decent song. The guy knows how to sing. Messy arrangements though.
16. Greece: a typical Eurosong top 10 finalist. Sergio did that podium trick two years ago. Why do I forget about all these songs the moment they are finished?
17. Iceland: tune! Tune! And very boring as well. A tearjerker that keeps your eyes dry. Hurt! Pain!
18. Ireland: this is the silky smooth remake of the Iceland failure. Same tears, but now artificial. Balls! I need balls!
19. Poland: A reggae version of Russian Housewives looking for European Husbands.
20. United Kingdom: a bloodless Johnny Logan. Not a bad voice, but there must be a milkyway full of ballads like this.
21. Cyprus: not a big podium act - she's afraid to sing out of tune if she moves. Has a voice though, and a good one. Whitney Houston-style ballad. And fat as well: I see a trend appearing.
22. Turkey: ska! It feels somehow fake to see a Turk with a Johnny Rotten-style pair of pants, but this was one of the better performances so far. There must be a penalty for standing upright, though.
23. Romania: let's face it: she would be better off wearing nothing. And we as well. She's a blond come-and-get-me. In terms of build-up, the song is conventional, but quite professional.
24. Sweden: she owns the camera. Boring song. She reminds me of a trashy version of Julia Roberts. She really needs it, but I have a headache tonight.

Voting starts now. My candidates: Ukraine, hopefully Belgium, Greece, Cyprus, Sweden. Romania gets extra points for being extra campy. Wow, that lady needed a fix.

Oh BTW: the televoting was flawed - I submitted two SMS votes within the first 5 minutes of the voting window, and both of them bounced after 15 minutes telling me I hadn't voted during the voting window. Hurray for Proximus!

Talk about clueless: here's the translation of a sample marketing newsletter from Apple, as shown in Apple's own Mail.app:
You're using an email application where the HTML version of this mail can't be correctly displayed. Apple advises you to download this mail from http://blablabla, in order to have an enjoyable read of the email.
Will I click through and see what they are talking about? Well, duh. :-)

Dear friend Bertrand posts a rebuttal test to my Flow performance observations of yesterday, showing Flow performance isn't necessarily bad. Of course, his Flow example doesn't do much, and I haven't explained a lot about what ours does. Suffice to say that ours is a bit more complicated, but not in the JavaScript sense: all of the hard stuff actually happens in some Java components that are used by both the FlowScript and the Action version. If you put the two versions side-by-side, it's almost line-by-line identical code, apart from syntax of course. Still, we have a 60 ms penalty in the JavaScript version.

My father used to be working in a psychiatric clinic. My wife works with mentally challenged people. I have a natural curiosity for deviations of the human psyche, and think the internet is really showing all of humanity's little dark corners. Back in the nineties, I witnessed the long-winded monologue of someone who eventually committed suicide - documented on alt.suicide.methods, with someone posting the newspaper article as sinister proof. The human race is a wonderful, if not frightening species to observe.
With both of my parents working in or around healthcare, I had a childhood of articles and pictures on wound treatment methods, surgical procedures and all that being passed around the Sunday lunch table. I can confidently state that I have a strong stomach when it comes to blood, splatter and gore.
Don't turn on the sound however when watching Nick Berg's murder.
Think about pictures from Abu Ghraib, think about embedded journalism, think about how media is shaping and guiding these Modern Times. Don't fear the machines, fear the rage that is hidden in every person, and fear the power of (home-made) journalism stirring up tensions into full-blown atrocities. And know that media won't last long without an audience. Make up your own mind before others do it for you.

Yesterday, I was at the J-Spring conference of the freshly minted Dutch JUG. I lost a previous version of my trip report because of my misconfiguration of ecto, so I'll briefly summarize here. I only saw a few talks since I spent much more time in the corridors chatting with people, but still it seemed like a genuinely interesting event. The opening keynote was about Java Studio Creator, which is a draw/drag/drop IDE made out of the Raven project. Jim Laden from Sun came over from the UK to present it, and Sun really could have sent a more experienced speaker, or at the very least someone better-acquainted by the tool. His presentation and demo were quite bad, and running JSCreator on an underpowered laptop didn't do much justice to the tool. Underneath, JSCreator generates JSF-code, and it was fun comparing that with what we have in Cocoon Woody/Forms: I think we captured all of what JSF does, minus the JCP stamp of course. I also went to another JSF talk, and to the closing keynote about Groovy. In the hallways and during the reception, I chatted with the MMBase guys, primarily about content management (duh) and open source licenses. Definitely a bunch of fun guys to hook up with.
My talk went well, primarily since it was the third or fourth time I delivered it, and I was right after the keynote which was that bad that it was quite easy to do a bit better. I had plenty of impromptu chats with newbie Cocoon users and explorers during the day, and inevitably they all came up with the same two main remarks or concerns: performance and documentation.
While there exists plenty of documentation for Cocoon, it is quite unorganized and requires some perseverance from its readers to locate what they need. This is caused by the main problem of Cocoon itself - which is the huge number of options to tackle a specific problem. While the "Power Trio" application development model is being pushed these days, all of the other/older options still exist, and must sometimes be used in combination with the Trio to attain a certain goal. Users find this confusing at best: they feel Cocoon is a huge beast and that they need to learn all about it before being able to make a good application design. If I contrast this with the amount of Cocoon components we use on a daily basis, which shouldn't be more than 30%, it's easy to smile when people make this remark and tell them they should hire us for a workshop, but in the end it is clear that there's a lot of cruft in Cocoon and we should somehow address this. I sometimes feel that there's too much friendliness in the Cocoon community: we simply fail to delete someone's code -- afraid of hurting that guy's feelings. Also, while some application problems can be solved in multiple ways, these ways don't necessarily work well with each other, because of slight overlap or total orthogonality. The request for Cocoon books was there as well yesterday: we really need up-to-date 2.1 books.
Another recurring question was performance: because of its perceived complexity, people fear Cocoon will be much slower than low-level-Struts-based application. While people obviously are messing up performance by chaining multiple XSLT transformations or using complex XSLT on top of very large documents, Cocoon has a certain overhead because of all of the machinery that comes with it. Also, some of the newer Trio stuff clearly hasn't been checked for performance-sanity, like FlowScript. I've been encountering this myself this week.
As some of you may know, we are currently building a not-so-easy Cocoon application, and we've been using the FlowScript/CForms combo for that. On Monday, out of sheer boredom and because I just found out about ab, I started testing the publishing-only side of this application, which uses FlowScript to connect to a Java client object, which on its turn uses HTTP (Jakarta httpclient) and XML to retrieve a document from the backend. Since all this HTTP and XML (de)serialization stuff comes with an overhead, I expected a difference between talking directly against the back-end's HTTP stack, and looking at the same document retrieved from the back-end by Cocoon, with some further (lightweight) transformation applied on top of it for display. I hadn't expected however the difference to be this big:

(average response time/request over 100 requests, no concurrency)
Out of experience, I know I'm able to get response times of 15 ms for a simple Cocoon pipeline on my test machine (just my laptop, duh): that must be the inherent overhead of using Cocoon on my hardware. Our backend application seems to be in the same range for normal-sized documents: about 15 ms as well. So we have a baseline response time of about 30 ms to account for in any case, and the rest of the response time will be needed for HTTP connection set up, retrieving the XML data from the backend, parsing it, and providing it to the publishing pipeline.
Bruno also hacked together a Cocoon Action-based variant of the original FlowScript version, so that I was able to add that one to the comparison mix. As you can see, the FlowScript approach seems to have an average, built-in 60 ms penalty. 60 ms is huge in my mind, and since the Rhino stuff in Cocoon is now a bit abandoned and left on its own, and you encounter all sorts of integration mess between the Java- and the JavaScripting-world, we're not so convinced anymore that JS/FlowScript is a conceptually -and- technologically sound way to develop web applications.
I'm personally still quite sold on the continuations idea, but its implementation clearly seems to require some major overhaul, perhaps based on a different (non-scripting?) language to be useful in serious production environments: JavaScript FlowScript makes your application between two and three times slower than using plain old Java (in Actions or pipeline components - we haven't ventured in the recently committed JavaFlow yet). Of course, raw performance isn't always the best way to gauge software quality, but at the very least it learns us that speed problems haven't been encountered yet in a production environment, or else we would have heard about it. Hence we're doubting about its use beyond playtime projects at all. Beware however that it perhaps wasn't too smart of us to use FlowScript for mere publishing-oriented behaviour, and we should have made the switch to plain Java code before. OTOH, 80% of our application is about interactivity, forms and all that, and we expect/plan/design this to be fast as well. Besides, there's the constant, time-consuming, frustrating exploration of the current continuation/flow implementation in Cocoon - and the lack of time, energy and funding to come up with ways to address those issues. Oh, and the fact that we got grilled during our previous (premature and under-researched) attempt to do something about it, of course. But we're big boys with thick skins, and some time, some day, I'm sure something will happen.

I love conferences with open WiFi access! :-)

(Fisk via Rik)
Doom, Quake and mass murder ... is this war or someone playing a video game?
What has technology brought to mankind so far?

Nice statistical roundup... and for the lazy ones: that's 96.18 kg. Mine is 26.2 at 190 cm. Must have something to do with nutritional preferences.

Why software projects fail: Matthew blames the Real Programmers. Not being one, but heavily surrounded by them now for many years, let me explain why I fail to find one single valid point in his reasoning. Obviously, Matthew is talking about software development inside commercial projects, so you'll have to scale his and my reasoning to your particular situation. Even more obviously, I can only speak from my own experience, which seems very different from his. There must be different types of Real Programmers, so it seems.

I'll start with collapsing his first two points:

There's still some big truth in these points, in that projects often fail because of a lack of a clear vision, and the requirements contained by this vision. These requirements often never materialize because of sheer laziness: both the customer and the programmer are too lazy to descend into one another's mindset, in order to really understand enough of each other's work to come up with a set of effective requirements.
Computers are dumb things, and it requires skill to flex them towards a resolution of your problem. By not being able (or willing) to precisely state your exact problem, in a way that it fits in the limited execution context of a computer, you will decrease the chances for a potential solution to effectively happen. Since one cannot expect the customer to have full knowledge of the execution environment, it is the task of the programmer to make him aware of enough context to be able for the customer to state the problem in a way that both parties are communicating in a common language, and are stating a precise and minute set of requirements.

Customers are not expected to go a lot into implementation details - they should even be advised not to state many implementation requirements. What I have seen many times in my small career, were customers who wanted to hear all the fancy buzzwords, who wanted to feel part of the programming crew, yet who were not able to exactly state what they wanted, and ended up demanding immense flexibility: a recipe for disaster. "I can't make up my mind, yet I want you to do it."

Also, programmers love precise specs. They might be frightened by the complexity of them, or become aware of inconsistencies which will make them ask annoying questions to the customer, but in the end, their job becomes much easier if they know what to do.

In companies I used to be working for, this communication problem was often solved by some middleman: an analyst. One could expect from analysts to be able to talk to customers and make abstraction of the implementation noise the customer was trying to inject into the requirements, and also them to be able to go into enough technical detail to not come up with inconsistent problem domain models to explain the task at hand to the developers. A good analyst could make or break the project. Another recipe for disaster was putting a project manager or sales person in the role of the analyst. For obvious reasons, these roles would always walk the customer's walk, rather then trying to help the developer along. The developer would feel bad because this would simply mean an increase of the number of customers in the project to him, rather than a communication bridge to the customer. So don't staff your failing projects with more infrastructural roles, but try to hire good analysts on beforehand. I know some, but they tend to be a scarce resource.

For larger projects, programmers also can't take up the analyst role, since their brain will simply melt because of dimensional overload: when you have to look at a problem from too many sides at once, while also worrying about minute implementation details, your perception will become heavily distorted and you'll suffer from neurological collapse. Being able to decompose large problems into composable solutions is the main skill of a developer, but you cannot add the task of defining the problem space to his job description - that would be God-like. In the end, writing down requirements should be nothing more than that: a thorough write-up of the problem space. The developer can then focus on designing the solution space.

• Asking a Real Programmer how long he/she needs to write a component/application causes the same brain cells to fire that would be involved if you asked them (in a bar) how often they have sex. Albeit in the opposite direction numerically speaking
• Whatever the reply to the previous point, management will think they are exaggerating and reduce the numbers

• Decomposition is your friend. Make sure you have a clear vision (see above) of what needs to be achieved, and think of the different building blocks this would require. Try to make identically-sized blocks if possible, and reduce each block until you come up with week estimates for each of them: one week, two weeks, never more than a few of them. Building blocks cannot be specified using manmonths: that's too big a unit.
• Design to budget. By doing your own homework like this, you can budget easy or obvious things easily, and make difficult things optional. You can explain to your customer that he will get 80% of the project for a fixed (and mutually safe) fee, but that you're unable (yet) to come up with precise guestimates for the remaining 20%. Sell those separately. Explain the problematic blocks so that he understands what they will buy him (or not). Also, keep an eye on the total amount of days/weeks/months, both in terms of full-time equivalents and lapse time. Your team size and their exhaustion rate is part of your budget, and you can easily deplete it. You cannot expect someone to be focussed on building a single building block for more than a couple of weeks, and you need a variety of varying blocks to keep someone focussed on a single project for more than three or four months. After that period, it's death row marching unless the variety helps in pushing fresh (and sufficiently isolated) problems into the developer's mind working area.
• Don't expect someone to decide when his own work will be finished. We are all proud people, and live to love what we do. Parting from our child is difficult, since there's always little things we know that we still want to tweak, or where some refactoring would be applicable, if only to find out what the result of this refactoring would be. In a sense, the journey is much more interesting than the destination, and we want the journey to last as long as possible. Programmers however do like planning, since it gives them some organisational context for their work, and also since planning very often decides on interfacing moments, where people are to be confronted with their work or its progress. They need feedback, and deadlines are a way to look forward to that feedback. By deciding on a planning, a project organizational structure is established, and people will feel effectively pulled into the project team, knowing they can depend on people to deliver them raw material in due time, and also knowing they have to deliver somewhere and sometime. Planning is a great motivational and teambuilding tool, if correctly executed, and based on feasible guestimates. See above.

(to be continued - off to sleep now)

Werner folds down his own company and goes working for the VRT. Congrats on what must have been a difficult decision!

I had to try as well:

You are a GRAMMAR GOD!

If your mission in life is not already to
preserve the English tongue, it should be.
Congratulations and thank you!

How grammatically sound are you?
brought to you by Quizilla

How's that for a non-native speaker?