No evidence...

One thing that I was thinking about when I read about scientists recovering old texts is what would be left for future people to learn about the lives we're living right now. Out knowledge is being stored more and more in electronic format which is pretty fragile. No stone tablets for us. Our books are printed on paper with a high acid content and degrade very quickly compared to old paper which lasts (at least) 100's of years. (Ya, I read it somewhere... no proof on this blog).

What's likely going to be left? Environmental damage? Landfills with diapers, broken plastic toys and food wrappers? Probably just evidence of our own stupidity and not much else. Sad really.

Instead of being the Achilles' heel, maybe the thing that will actually save human knowledge will be the digitization revolution - all knowledge being at least in digital format. Redundant, distributed libraries so the loss of one building won't have such a huge impact. We'll have to see how things turn out with the digitization and the copyright laws. ;-)

Crapsticks

We were planning to go away for a family cottage weekend. However, the strong storms lately have taken out the power at the cottage and it will be too difficult on the cottage to have that many people there without power. Estimated time for the power to back on? Sunday night. :-(

I'm a bit sad. 1) I won't see some family that I really only see a couple of times a year (this is one of them) and 2) it's rare that we have the chance to get away to the cottage.

Dammit.

Now I have to figure out what to do with the food that I have bought.... at least it hasn't been too much so far... anyone know good things to do with 3 doz eggs? I'm thinking lots of egg salad and souffles... *sigh*. At least I have frozen the bacon (and I know that will be used without a problem). Oie.

It's all new again

One of the interesting things working with Java web apps is that the "best practices" keeps on changing. Frameworks that at one time are looked at as the shining example of doing things well turn into "old school" and clunky in a handful of years. The idea of "Enterprise" solutions get thrown out in favour of lighter, cleaner frameworks. Pattern overload gets turfed in favour of KISS. Vendor lock-in gets tossed for plugablility. Even the language is changing relatively quickly: they're on v6 beta 2 at the time of this writing and expecting to release it in the fall. There is always more to learn, better ways to do things. Status quo just means that you'll be left behind.

Keeping it neutral

One of the things that I feel that I have to work on is keeping things neutral and not losing my patience, even if I am frustrated. I don't think that it helps the situation in the long or short term. I know that I have not liked it in the past when people have lost their patience with me, and I don't want to become like that. I think that this will require more effort on my part.

And if it gets really bad? I guess I should just walk away for a couple of minutes and come back, but that's not always an option. :-(

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. ;-)