The Zend Framework Poster

I can't stand advertisement of any kind, but I've promised to do it, so here we go. Seriously, it's no advertisement but just a favor I do to this nice guy who sent me this cool poster and a set of pretty cool planning cards.

In the following pic you see two happy developers in front of the brand new Zend Framework poster which has been sponsored by Mayflower, one of the very major PHP players around. They always have nice ideas, one of them hangs on this white wall. Empty white walls I can't even stand more than advertisement, so it's a nice win-win situation. Go get your own copy of this poster at http://mayflower.de/en - I hope they still provide it.

What I Miss About The New JVM Languages

It's not the lingual finesses or cool features of them that I miss, because the guys who create them are pretty well knowing what they're doing. No, it's not that.

It's the experience with them from the point of view of the ops. I have hardly found an article telling me how to operate for example a Clojure & Co. app concerning, let's say, the heap strategies. They say, it's the same as Java, but I don't believe it since they do too many things behind the scenes which I would do with Java explicitly - classes etc.

On the other side, the very important design principle "Design for ops" still seems to be secondary. But I think what is actually the case is that these languages, maybe except Groovy, are still elaborating on themselves (lingual and programmatic things) not being ready for the wide operational acceptance.

Look at the millions of Java language based applications installed all over the world - on clients, servers etc. We know how to operate them, and we have collected this experience all through the years, so we know how we would operate the next one or at least where we would look for operational issues and solutions for all those protocols, web-services, XMLs, heaps etc.

All this knowledge we still don't have around the new languages though they run on the same JVM. Why? Well, please point me to the articles describing in detail how I should optimize the heap for Clojure's first-class functions based upon existing experience, not pointing me just to the profiler and debugger and telling me to find it out on my own. Exactly.

I am really happy that the JVM enables cool new languages or nice remakes of the old ones to run on it, and some of them I will definitely have to learn next time, but before I will really use them for professional solutions, I want to see the real life experience reports about how to operate the solutions based on them since I'm pretty sure that their behavior for example under high load might be completely different than that of the standard Java apps where I can predict for example the heap usage based on existing experience of how objects get allocated, moved from one heap generation to the other and garbage-collected and which pitfalls I should avoid.

I'm sorry to say that, but through my job I'm seldom an early adopter. I'm more the guy who has to wait for a technology to jump over the first major barrier - become operable and wider accepted, and then take it - still in its early development phase.

I still miss this phase about almost every new JVM language. I might be wrong, but this is my honest opinion. Any corrections and suggestions are, of course, welcome.

Real Life Example Of Tight Coupling

Long time no blog, huh? Actually, the 2nd book and the coming up talks eat up the time since I have a day job.

Now back to the blog post topic. I have noticed that it's sometimes fun to illustrate programming paradigms with real life examples instead of trying to explain them using a UML diagram - which also works, of course.

Most people, I noticed, like the car metaphors. IT is the engine, driver / co-driver and blah blah blah. I'm absolutely not into cars, even despite the fact that I'm currently working for a car rental company. I think, cars as such are just means of moving my torso from A to B in a protected way so that I don't get cold. That's basically it.

So I usually try to avoid examples and metaphors from this area and to invent more interesting ones. And recently trying to explain the tight coupling to a young colleague, I found a nice example from the real life which I would like to describe here briefly.

Imagine, you want to rename a city. This happened for example quite often in the former USSR - the city now called Volgograd has changed its name 3 times in one century.

So you now have a huge effort to modify the maps, addresses etc. But this is at least what concerns the city itself. Now you have a lot of companies having the city name in their names. What now? If you really want to get rid of the old name, those names have also to change, which is followed by a chain reaction.

And now even worse: it's a common practice to call streets or districts in other cities after a city - either these are partner cities or the renamed one is bigger or whatever. Now you can imagine the chain reaction you start since they also have to change maps, addresses and so on.

If the old city name really has to disappear, the effort to change the references to it everywhere is enormous. And now imagine the effort to change it in people's heads. This is an example of tight coupling.

Actually, you should avoid renaming cities. Really. Or, at least, the references to the city names shouldn't appear in company or street names which is very difficult since it's a common practice and can mean something special.