The blog has moved to a new location: www.freshblurbs.com

I do not know any developers that have created more than a couple web applications in Java/J2EE and has not gotten frustrated by JSP. JSP sucks - on all fronts! JSP is created to decouple presentation from the program code but nobody except a programmer can handle JSP!!! It is presentation for ... programmers. Who wants it? It is ugly and limitted. Just to name a few: tag can not be an attribute of another tag, you can not easily load JSP from a JAR, JSPs need to be compiled, it is too verbose and designers HATE it, is not friendly to any WYSIWYG HTML editors.

Being frustrated, I was, naturally, looking to alternatives. First I looked at Tapestry. As far as templating goes - it is nice, and smart. But it is a full-blown MVC framework too. General rule - more functionality tools take on them, more limitting they are, because they enforce their "best practices" and that may not be the best way always. Also, my current application is, already, written in Struts and moving to or integrating with Tapestry, while possible, is going to suck.

Going around and around, I finally, decided to take a deeper look at the Jakarta Velocity. After all - I have heard too much of it and two tools I use all the time - Confluence and Jira, both use Velocity - so WTH?

And....

Well, to put it short: writing templates with JSP and Velocity is like writing your persistence with raw JDBC or using Hibernate. YES! That's the kind of difference! Just like Hibernate, Velocity brings a huuuge simplification, is highly extensible, flexible and leaves you space to using alternatives, if you will so. Last but not least - it does integrate with Struts, too.

I am very, very happy. I think my journey, in search for a good templating engine has come to end and I found it - Velocity is the way to go!

I can not, possibly, blog in more detail about a rich engine like Velocity, but it's not necessary, either. There's a wonderful, brilliant book about Velocity written by Rob Harrop - Pro jakarta Velocity.This book is how I learnt Velocity and there is nothing I could add to it. Highly recommended

 

Martin Fowler blogged about ErraticTestFail. I can not say the name is very descriptive :) but the problem is interesting. Such buggy tests arise, mostly, from static mocks or stubs shared by several test methods or cases. Now, ideally, your tests should be independent but there is a performance tradeoff - sometimes initalization takes too much time. The last thing you want  - your test suite to take too much time to run. That can lead to productivity degradation and the temptation of running test suite less often or (oh, God!) - not at all.

I think logic unit tests should be mocked enough not to need costly initializations, so if it is true - the problem would arise, mostly, in functional and integration tests.

JUnit allows to reload the run of each test. You would, usually, have it turned off for the performance reasons. But because of the ErraticTestFail possibility, it is  may be a good practice to:
1) Run daily tests on an integration server where JUnit reloads for each test run. Test may be fine-tuned to share setUp() and be faster but they must be written so that if each test is ran in a new classloader - they still work (even if slower).
2) When and if you notice something suspicious (like Martin's case) turn on reloading and see what happens, before you go on blaming your IDE, compiler or whatever is easier to blame :)

 Andrew has been working on PodCasting (audio RSS feeds for iPod) for a while now. He blogs that John Edwards has done a podcast. Yes, this is the same Edwards that was running for vice-presidency under Kerry, just several months back.

This is MAJOR! Both for the Internet community+iPod community and the US/World politics.

WOW! Hope this is not the first and last (don't think so).

I am very excited to see how this thing goes.

<style type="text/css">
input:focus { background-color: #FFFF99 }
textarea:focus { background-color: #FFFF99 }
</style>

Sony Mathew has described the best my concern with the Dependency Injection (e.g. in Spring Framework). I like it so much, that I think it is well worth quoting here:

"... externalizing an entire object graph seems over ambitious and counter productive. This type of glue work is considered core functionality and may be subject to business requirements and testing procedures and exposing it as an untyped descriptor file can make the application very brittle. Finally, this core functionality type glue work should be reusable and extensible just like any other part of the application that represents the business domain."

Whoa! Here goes the prize for the dumbest shit of the year!
I never liked Adidas, anyway, but they have really, really outperformed theirselves... but, not the way they think.

Listen, idiot, I DO NOT WANT MY SHOE TO HAVE A CPU, get it?

As a side comment: their promo-site SUCKS. It is one of the most user-unfriendly and obscure sites, I have seen in a while. It gives almost zero information about the benefits of their "innovation"...  well, which I kinda understand - I doubt there are any.

Mighty God, is the whole world going nuts, or (hopefully) is it  just the CEO of Adidass?

http://www.linuxos.sk/downloads/wallpapers/Kill%20Bill%201024.jpg

"Life is what happens to you while you're busy making other plans" - John Lennon

It seems that the formula of the cannabis has been figured out:
R:=(1+sin(t))(1+.9cos(8t))(1+.1cos(24t))

Graphic of the function in polar coordinates:

The Redmond company (a.k.a M$) has begun a new campaign, represented by this image banner on their website.

The truth is, in reality, you should read that banner, in a slightly changed manner:

Do not allow developers to sneak-in untested code:
http://www.cenqua.com/clover/

The version 2 of Digi is going to be all about simplification and the productivity of code-creation. Personally, I think, we have achieved quite rich feature-support in version 1 and left place for bigger enhancements to be possible. What we have come short (and I am not surprised or disappointed as it's just version 1) is the ease-of-development. So, now it's time to Simplify.

As the simplifications go, there are two obvious things, in my mind:

1) Struts coding is too verbous. I would like to see more defaults implemented in Digi, so that if you follow naming conventions (roughly: your view file has the same name as your action class and form bean etc.), in 80% of standard cases you would not need to write anything in a struts-config.xml. For the rest 20% (or a large part of it) it would be nice to have something simpler than a bloated XML config. For example, Apache Beehive looks quite interesting for this task.

2) JSP is a pain. We've had enough of it. I like Tapestry UI approach much more. Let's see if we can painlessly swap it in.

and I, also, want:
3) Simplified module customization capabilities. Let's prove Oracle dudes, that modules can be customized beyond the UI layer, and it is not such a rocket-science.* The Proof of Concept code, we have, makes me quite optimistic. Let's see...

--------------------
*This is in regard with an Oracle session, held in Wash, DC, where Thomas Kurian, the SVP of Development, Oracle, told me that when they talk about flexible customization features in Oracle portal suite, they just mean the UI layer, by far, and beyond that - it is too complicated. This reply has disappointed me as much as he seemed to have hated my question :-)

Since I became a Mac-addict, I seem to be sturving to anything Apple. Today, while wondering around the Borders bookstore in Pentagon City, I ran into a wonderful book about Mac history, by Andy Hertzfeld, one of the "fathers" of the Mac. It is a great book, with a great print quality for an amazing price, so I advice to get it even to non Mac fans.

Anyway, the book is about the software engineering, too, so I found some interesting stuff in it, not directly related to Apple, so I thought mentioning it. This particular one demonstrates that the Lines of Code is a bullshit measurement. I know some may not need demonstrations of that, and I, myself, think it is so obvious - I might not bother to quote this large story, if not being a witness, couple of weeks ago, how three of our team were seriously trying to measure effort by "Lines of Code" and using some stupid "calculator" software. Seems like, not everybody gets it, so here goes the real-life story:

Page 65 of the book:

"In early 1982, the Lisa software team was trying to buckle down the big push to ship the software within the next six months. SOme of the managers decided it would be a good idea to track the progres of each individual engineer in terms of code they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code written that week.

Bill Atkinson, the author of QuickDraw and the main user interface designer, who was by far the most important Lisa implementer, thought lines of code was a silly measure of software productivity. He thought his goal was to write a small and fast a program as possible, and the lines of code metric only encouraged writing sloppy, bloated, broken code.

He had recently worked on optimizing QuickDraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm - which, after some tweaking, made region operations almost six times faster. As a byproduct, the rewrite also saved around 2,000 lines of code.

He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2,000

I'm not sure how the managers reacted, but I do know that after a couple more weeks they stopped asking Bill to fill out the form, and he gladly complied."

The new buzzword (well, not THAT new but...) on the Net is Ajax. It's like a web-developer's dream: "richer" client but with the standard technologies. No plugin to install, just POS (Plain Old Stuff) like: standards-based XHTML, CSS; XML, DOM and some XMLHttpRequest with some Javascript. That's promising to deliver almost the same kind of interactivity as Macromedia Flex, for example, but with the nice POS approach, rather than ad-hoc plugin from a single vendor. Way better!

Anyway, what is the list of the browsers supported? Well, Ajax is not a technology, itself - it's a collection of them (see up) used in a smart way, so it depends a lot on - how you use them, how smart you use them. And yet, considering that Google Maps and Google Suggest are two shining example of the "Ajax-way", we can guess the answer, and here is how:

MS IE on Mac is the worst browser ever :) The reason why people use IE on Windows is: it supports more "features" (all of them - non-standard, the M$ way, of course) than other browsers so pages created in Windows IE deliver "richer" experience. This is not quite true for Mac version of IE. It does not have the same featureset on Mac that it has on Windows. Actually it is quite poor and, IMHO, plain sucks. So, if we open maps.google.com in Mac IE, we will get a Google response, saying this browser is not yet supported, with the list of the browsers (Google has always been polite enough!) that it does.

And here is the list:

* IE 5.5+ (Windows)
* Firefox 0.8+ (Windows, Mac, Linux)
* Safari 1.2.4+ (Mac)
* Netscape 7.1+ (Windows, Mac, Linux)
* Mozilla 1.4+ (Windows, Mac, Linux)
* Opera 7+ (Windows, Mac, Linux)

This, IMHO, is a good approximation of the current compliance state of so-called Ajax.

Not bad, by the way, eh?

ThoughtWorks has been known for two things: First, that's where the modern maestro and guru of Java - Martin Fowler works at. Second, that's the creator of the CruiseControl continuous integration suite.

Thoughtworks has delivered the third member of the trinity: Selenium - an automated functionality-testing engine for web-applications.

Having such tool for a web-development greoup is priceless. I have been pushing Doug to buy a SilkTest license, for quite some time, now. SilkTest has been one of the leaders in the area. Unfortunately, Doug is being, for what seems to me, overly cautious (I am not gonna say, "greedy" as he may read this post LOL. Just kidding) sometimes so it never happened.

Selenium is open-source. That's good news. I think it is, probabely far from SilkTest, yet (just a guess, did not have a chance to look at it, yet) but knowing ThoughtWorks, I guess it will not take them too long to make it a nice tool.

Wonderful! Considering that our QA-to-be guy will, probably, not know neither SilkTest, here is a chance to adopt something for free (yeah, I know it's not like "in beer", but it usually is).

Kudos to ThoughtWorks.

I assume this thing has been around for a long while and I was living on the moon for the last X months or years, but I suspect I may not be the only one, and anyway, I often use my blog to mark interesting stuff, so if I forget - I can come back and find quickly, so....

Forget about that silly bookmark importer/exporter/whatevers :)

http://del.icio.us/

You can put your bookmarks online, easily so you can access them, categorized,
from anywhere. And you can, also, see what sites other people like (that can
possibly lead you to interesting ones, you never heard of) - can come quite handy.

While, in my never-ending arrogance (heh), I find the current Digi security system quite robust and extensible, as well as, well-integrated with the main JAAS principles, it is not enough.

There are two things that were purposefully disregarded, in the rush of providing the solution to those who needed it, and that should be revisited.

First is the Security API from the JSR-168. As much as I am sceptical about the version 1.0 of any specification, JSR-168, in particular (arrogance, again), for things like the security it may be beneficial to, at least, consider being compliant. Well, if that does not harm, more valuable assets.

Second is the fact that if anything, security is the component/service that would benefit from being as pluggable, extensible and de-coupled as possible. While, it would be hard to clain that the current implementation is rigid, Digi Security is still using only the plain-old approach of coding to interfaces. There is space for more flexibility, widely known as the introduction of the Dependency Injection techniques. This could make things more de-coupled, with less code.

From a quick glance and research, it seems that Acegi Security System for Spring is a good example of employing DI techniques for a Security System implementation.

As I do not have time for all these, right now, I am posting this as a note (reminder) to myself here. Somebody thinking about improving his/her own security system may, also, find this information useful.

One of my recent assignments has been to come up with a presentation for our software engineers about the benefits of using unit-testing in their code and demonstrating how it should be done properly. Easier said than done. How can you explain, to inherently, professionally lazy people, in an hour and 20-30 pages of Powerpoint (or Apple Keynote :P) things that are mostly intuitive and come only with experience, as well as from reading a whole bunch of books + examples and then doing it every day, for each piece of code?

It's been a real challenge and I was still thinking if I should give up, when I ran into this wonderful piece of code on TheDailyWTF:



and everything became clear! Hell with JUnit, forget about Cactus, who cares about Mock Objects? God bless try-catch.

My presentation is going to be just one page with the screenshot of this code and a large, stupid smile to go with it.

Seriously, you can not write more error-proof code, can you? ;)

:)

I have first tried Eclipse 2 years ago, and totally hated it :) Since JBoss released its integrated JBoss IDE package, based on Eclipse, it has become interesting, again and I installed them on my Mac. It has become especially important as my Mac Mini, as much as I love it, does not have much resources and an IDE that goes easy on resources is good.

I was very impressed with JBoss features. You can smoothly launch and debug your web application inside the IDE itself. Yes, I have used similiar features in both JBuilder and InteliiJ IDEA (this one is definitely not for a limited-resources machine like Mini, if you are working on a large server application) but the truth is - they are nowhere close to what JBoss IDE can provide. Just change a line of code in your java files, you do not even need to explicitely rebuild if everything is set up correctly, refresh page - and you will see your changes. No server restart, no hussle!

rulzzzzzzzzzzzzzzzzzzzzzzz

I guess I am gonna stick with JBoss IDE/Eclipse from now on (and until something better appears -if, heh).