Don't kid yourself: that's coupling

One of the books that I was reading (I think that it was Lighter, Faster Java) was talking about coupling. When working with a language like Java, it's a good idea to try and deal with interfaces instead of concreate classes. Especially with method signatures. But that's another rant about the joy's of the Java Collections.

Back on topic. Working with interfaces is a good idea, just don't kid yourself when you are doing it. For example, if you have some code like this:
Set mySet = new HashSet();
it is no less coupled to HashSet than code that is written like this:
HashSet mySet = new HashSet();

So, using interfaces in method calls / signatures: good. Using interfaces where you create a new concreate object (not using a factory or something like that): pointless.

Crraaazy stuff...

Just when I think that I'm pretty good at biking, I see something like this. Oie.

Pretty funny stuff on the net... like Bush singing "Sunday Bloody Sunday". Not as catchy as Taking the Hobbits to Isengard though...

Side Effects

When I have been writing testing code, I have let the data be saved to the db. I know that this goes against the idea in unit testing that you test should have no side effects. And frameworks that have testing built in like RoR or Spring help make sure that your work doesn't have any side effects by rolling back the transaction when the test is done.

This helps make it so that your tests can run in any order, etc., but I don't really like that. Why? Because I have found more bugs with leaving data in the db than clearing it out all the time. My test data has some randomness to it (another no-no), but it helps show bugs. Like what happens if you have a first name in all CAPITALS? CamelCase? lowercase? What about accents?

Another benifit I have seen is when I use reflection to "fill" out a java object, save it, and then display it to the UI. I can find cut and paste errors of the html (struts) form fields or where you are displaying this data. This comes from the fact that I hate manual testing, espically creating the data.... I can't help it, I'm lazy. If I've already set up my test suite to create "valid" data, why can't I leverage that functionality? Maybe I can, but I don't see how to yet.

I'll post if I do find out how to do it. ;-)

What the brain can do...

Olny srmat poelpe can raed tihs.

cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy,

it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit pclae. The rset can be a taotl mses and you can sitll raed it wouthit a porbelm.

Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. Amzanig huh? yaeh and I awlyas tghuhot slpeling was ipmorantt! if you can raed tihs psas it on !!

I feel so small...

Ever thought that you are big? Important? Check out the scale of things and tell me if you still feel that way. ;-)

My Golden Hammer

I've been reading Better, Faster, Lighter Java and (like it many tech books) they always warn against a tool becoming a golden hammer. Which has got me wondering... is unit testing my golden hammer?

Any (programming) task I have, I try my best to write a test for it. Is this a bad thing? I never thought so. I write tests for resource files, to test config files, anything that I can write a test for, I do. I've just been thinking about this because someone was surprised that I was writing tests to test my Commons Validator configuration. Strange? Maybe. Documenting how the app is supposed to work? I think so.

Relying on Config

My biggest beef with J2EE apps is how much you have to rely on config files. Yes, using config files allows you to be super flexible and "plug" in the features that you need. My gripe is that there is only run-time checking if you've configured something properly. No compile time checks.

Configuration sounds like a great idea. Here's the catch: with (struts) web apps, you're got config files tied to each other, tied to resource files, tied to Java classes, tied to just about everything. And if you're misconfigured something and you're lucky, the error message has something to do with your misconfiguration.

If you read this blog, then you know that I can't spell. I rely heavily on auto-complete to catch spelling and typing errors. That's why I don't like config files.

I also don't like manual testing. I love unit testing. I don't like coding without a test to show what and why I am changing code. So, when I am configuring the Commons Validator, I want to know that it's set up correctly and checking the right thing. That means I was looking for a nice way to check the validation in a unit test, without having to drive through the action class. I want to test it as a unit, in isolation (as much as possible). I am pretty disappointed that I have not found an example of how to check that things are being validated correctly without using strutstestcase and building up a request string. :-(

Which brings me to my original point. I'm okay with things blowing up with they are configured properly (fail early, fail fast). I'm not cool with the potential for validation to be skipped because of a mis-configuration, especially without having any unit tests. Manually testing isn't an option. I don't like getting any bugs back from QA.

The Validator isn't a new tool. There should be examples out there. If they are, I just have not found them yet. When I find the example, or make one of my own, I'll post it here.

Lack of unit tests isn't an option.

Planetarium

One of the cool things that I have found with my stumble upon plugin is planetarium. It allows you to set the date, position, etc. and take a look at the night sky. You can rotate, mouse over stars (and get info), ... lots of cool stuff. Nice. ;-)

Quiz - What would you do?

You are driving in a car at a constant speed. On your left side is a valley and on your right side is a fire engine traveling at the same speed as you. In front of you is a galloping pig which is the same size as your car and you cannot overtake it. Behind you is a helicopter flying at ground level. Both the giant pig and the helicopter are also traveling at the same speed as you.

What must you do to safely get out of this highly dangerous situation?
(click continue for the answer)

Answer:
Get off the children's carousel and, next time, don't drink so much.

Struts 1.2.9, html:cancel and hours of fun

Let the rant begin.

I've had lots of fun today with struts html:cancel button. Too much fun. *cough*

My problem with the widget is that it is designed to be a cancel button only when you don't specify a value for the "property" attribute. But it allows you to specify a value for that.... let me say that again a different way: it allows you to remove all it's functionality if you just specify an attribute that you would on just about every other control. Why you ask? I have no idea.

I find the whole thing funny and sad at the same time. You have methods designed to check for a specific pram. Then they make it super easy to remove the pram. I'm just ticked off about the time that I wasted today.

And I am not even talking about how much time I wasted to find out the if I want to use above mentioned cancel button I will have to make note of it in my mapping file. No, it doesn't print a helpful message (that I saw), it just seemed to die. It wouldn't even enter in the cancelled method in my LookupDispatchAction. No, it just throws an exception.

Whew... for all that struts does for me, some times (most times) I wish that I didn't have to manage it so closely and know all the in's and out's. I've been using it for a while now and I am still learning most days. Not because I am dumb (I hope), but that it's just so freaking big. Design gone wild to be able to be the utmost flexable...

Sometimes I don't want a swiss army knife. Sometimes I just want a really big hammer.