New email worm

It looks like my strategy of dropping mail with no message Ids paid off today.

Dropping message with no messageId: Approved (Ref: 38446-263), from: support@microsoft.com
Dropping message with no messageId: Your password, from: support@microsoft.com
Dropping message with no messageId: Re: My application, from: support@microsoft.com
Dropping message with no messageId: Re: Document, from: big@boss.com
Dropping message with no messageId: Approved (Ref: 38446-263), from: support@microsoft.com
Dropping message with no messageId: Your password, from: support@microsoft.com

I do lose some legitimate email (e.g. NY Times mails) but I can live with that in the battle against virus emails and spam.

Ant as a Scripting Language

Duncan, the original author of Ant, blogs about the origins of Ant and the addition of script features, primarily the if attribute on the element. Check it out and follow the links for some interesting discussions (although note that the Mike Cannon-Brookes page crashes my Mozilla).

Although misidentified by Duncan, someone does state there that “ANT is the absolute worst.”. Ant wasn’t supposed to be a scripting language but without those features, would Ant have been able to cope with the spectrum of build scenarios that it does today? Is a simple declarative build description powerful enough? I suspect it isn’t. Maybe it is and we just haven’t come across the right way to express the build complexity. The question is how to provide the power required in an elegant manner, without turning Ant into an XML scripting language?

My typical approach is to move complexity into tasks. My original contributions to Ant were tasks for building EJBs because I didn’t like how I had to build them using Ant’s build files and available task primitives. Tasks that express iteration, such as apply are also examples of successfully moving the control complexity into tasks. Yet, it seems Ant user’s don’t want to create tasks so much – they prefer to put the complexity right into their build files. What is the balance between a <doConorsPistonProjectBuild> task and a build file full of complexity?

Today we also have script-like tasks such as foreach possible (though not part of the Ant distribution), and the <script> task for embedded scriptlets. If you wish to, you can write pretty much arbitrary complex logic using Ant. I don’t encourage it.

So, the question is, how should it be done? How can the power be provided for dealing with complex build situations without ending up with a scripting language? Or, is a scripting language the real answer? How would the structure of a build then be expressed? I don’t know. I continue to dislike the addition of if and failonerror attributes to every task but I’m not sure how to meet the needs of the users who want these.

If you wanted the perfect build system today, unconstrained by compatibility, current mindset or other issues, what would it look like? Would it be like make, like Ant or something different? How would it describe a build, how would it deal with the arbitrarily complex operations that seem to be required in some builds?

Let me know what you think.

Back on deck

I’m back on deck now. I’ve had a lot of things to do recently as you might imagine. It’s not all bad though, I’ve had some great laughs with my brothers, listened to some old music, thought about what’s important, etc. Time for a few changes? Maybe …

All Good Things …

My Dad had a way with words. When we would arrive home from some journey, he would always announce “Home again to old St Mallow …”. It always marked the end of our journey, though I’ve no idea where he got that saying from.

Today his journey has ended. He is home again – rest in peace.

RedHat 9

I installed RedHat 9 tonight. It’s nice, although a little trouble with PPP and fonts – sorted out now, I think. I noticed a funny little typo in the installer slide show. Apparently at RedHat training you can “lean more”. Sounds good to me.