... And They Shall Know Me By My Speling Errors

John Lam was remarking about how OOP and such are mostly used for abstractions now rather than for re-use when he said:

But is it enough? As most of you reading this have experienced, there are limits to what you can do with Patterns, OOP, and structured programming. You find that there are features that cut across your well-designed class hierarchies and object graphs. These are the warts in your program that spring to life innocently enough, but then spread as your program becomes increasingly more complex. It is these warts that make it hard for you to comprehend your software. It is these warts that make it hard for you to extend your software's functionality. [ IUnknown.com ]

After getting a better feel of XForms I have decided to roll my own form pages rather than using an existing XML format. I initially didn't want to create yet another xml to widget mapping, but nothing quite matches what I need. I even took a look at jelly-swing but there is way to much binding to the swing architecture when you consider that a console mode and non-swing GUI are in the initial design premise. So I am going to roll my own. Case and point, how does one make a checkbox show up with XForms? You do either (a) <input ... /> that is bound to an xsd:boolean value in the model, (b) <select appearance='full'> with one <item/> child. Both are counter-intuiotive to me and I would rather have one <checkbox /> element. I will use some ideas from XForms: like the nested label and help elements though.

That was Problem #1. Problem #3 was roller eating my post because of session expiration. But problem #2 is how to handle ant properites. Anyone who has done much with a ant build.xml knows that the variables ant users are set conter to the typical programming: the first setting of the variable sticks and later sets are totally ignored. This actually makes sense when put in context of a user-overridden values on the command line. But when taken in context of a "back" button in a wizard a first-set-win policy demolishes the concept of going back and changing values. There are two tasks, ant and antcall, that break that rule, and wizard will have to be another one. Overcoming the rules isn't that much of a problem with the ant APIs.

The true problem comes in unsetting the properties, there is no way via the APIs. You can get a Propeties object but that is just a copy, not the local value. So you cannot un-set a value. But the if and unless atributes go by whether the property is set or not set. I considered making some of my elements sensitive to true/false values, but the target would not be sensitive. This would make using properties to drive the dependent component installs impossible, which was the whole point to me of using ant to do the installs: to declaritively determiine the needed dependencies. But it's not insurmountable. The magic of introspection allows me to forcably introspect the values and change them. For anyone who thinks that RTTI is wrong, add me to your list of violaters.

I almost got my evil scheme to work...

try {
    Field fieldProp = Project.class.getDeclaredField("properties");
    fieldProp.setAccessible(true);
    Hashtable props = (Hashtable) fieldProp.get(project);
    props.remove(property);
    fieldProp.setAccessible(false);
} catch (Exception e) {
    project.log("I got caught with my hand in the cookie jar: " + e);
    project.setProperty(property, "");
}

I can access the properties object, but only in jdk 1.2+. The API I need to access a private field is java.lang.reflect.AccessableObject, which wasn't present in JDK 1.1.

So I am at a crossroads... and what I am leaning towards is to drop JDK 1.1 support. It kinda works but will be rather broken for most install tasks. The other option is to try and add a removeProperty method to the Project class, but I would either need to fork it or get it into Ant 1.6. Forking for a legitamite API reason is just as unpallitable to me as forking for political reasons. As for the other path I bet that a bug for adding a removeProperty method would get shot down for design reasons, and I couldn't say I'de blame them on that one either. Oh well...

Yep, just as I suspected my request to add a remove properties api was rejected (as a duplicate to a non api variaty of the request). No schocker really.

But I do have a better idea how I can better handle this without resorting to evil (but really useful) hacks. First the wizard task will keep it's own set of properties outside of the ant Project, reflecting non-user properties as pre-existing defaults. The Do and Undo elements will behave more like antcall, they will have a target attribute that an instance of the project will be created with the properties from the wizard task, like antcall. Body tasks will still be supported in lieu of the targ attribute (if the code isn't to henious), but a synthetic target will be created in the project containing all of those tasks.

The strange things you find in referrer logs: someone did a Yahoo search for "some ones hacked me.how can be free and he does not has hacked me?in farsi" and all they got was my page. I guess that's better than ANT & Install & Errors.

Referral logs are cool, you can figure out where people are finding your site from. You can also tell what web searches lead tme to you. Some of them are quite funny, this will be an ongling list of the funnier ones...

• Yahoo Search : some ones hacked me.how can be free and he does not has hacked me?in farsi
• Google Canada : ANT & Install & Errors
• Google : thonggirl73
• Google Germany : paintball gatling per minute
• AOL Search : how to do good on my speling test
• Google : foosball girl
• Yahoo Search : foosball table, child saftey
• Yahoo Netherlands : web log farsi [#1 listing, interestingly enough]
• Google : Nerf darts 4000
• Google : h4x0r swedish chef
• Google : what do aop sales targets stand for?
• Comet Search : how to build foosball table

As absurd as some of these are, these hits are 100% legitamate!

The slowdown must be getting real bad, because someone at Google has too much free time. You can customize your preferences to show everything in Klingon, Pig Latin, h4x0r, Elmer Fudd, The Swedish Chef, and Esperanto.

Wait... I think that last one was legit...

I've slowly been adding form controls to the form element over the past few evenings. With the addition of a text area control and a file chooser I now can create a wizard shell that could install Tomcat. It's not soup yet in may ways though. There is quite a bit of work to do for a weekend project (but if I had 40 hours a week time to spend on it I could belt it out in a couple of weeks, maybe one if there are no suprises). That is the problem with free (as in beer) software development, there's times I would much rather watch Harry Potter and I do.

The potential todo list on the immediate horizon (rest of Q42002) is as follows... (mind you that doesn't mean it will get done in Q4).

• Support radio buttons, and by condequence buttons groups. I would support one property-multiple values across the group and multiple properties-one value as well.
• Add if and unless attributes to all of thw form controls. Useful for summary and confirmation pages. Also for user data pages where another component may require extra info for a group of data.
• Add a progress bar widget that listens to do and undo steps and progeresses it. Also a text line that shows the last info level log from ant would be nice.
• Add console suppot for the wizard, right now there is no console support. None at all.
• Have at least some version of compon.ant out, so a single-jar install can be done.
• Lowest on my list is to refactor the properties to be held in the wizard model, as discussed in my Skinning a Cat Any Other Way... entry.

If anyone is following the CVS there are two new targets that may be of interest: demo and demo.tomcat. The first gives a short tour of all of the form controls (this is mostly what I use to test). The second shows the work in progress for a Tomcat installer, except for the fact it doesn't actually install anything. I am using it to gauge the look of the GUI. It looks better using kunststoff so I am using that in the Tomcat installer.

A better set of distributables and descritive web site will be coming when the code is closer to soup. I'de hate to have a page (other than my weblog) promising good stuff and sitting stagnet for a year.

All of us can point to at least one point in theier lives that they can call a turning point. One of those happened to me in late October of 1999 that prompted me to drop out of college. What could possibly cause that? A Movie, not just any movie. It is a movie that every one at my work can quote and re-create at the drop of a hat. That movie?

Office Space

I'm not kidding, as horrible as it made working life look it was utterly hillarious. Why is it so funny? Because it's so true. Almost all of the things they joke about could happen at a real company. And why is it such a turning point? It made me realize how much more I liked working than doing mini fire drill homework assignments that just get round filed when your done. And also, becuase if I had waited to graduate I am fairly certian that I would be Steve, the unemployed software engineer selling magazines. Timing was everything in catching enough of that wave to bring you to shore.

p.s. Anyone got some money they want to launder?

We recently got some new checks with an error in the street address. Not a problem, just call them up and ask for a correction right? So my wife calls (at 9pm, they got 24 hour service) and corrects them. Well, they ask her for both her SSN and her driver's license number. Both her and my instincts rise, why do they need both? Not even our bank needed the driver's license number, and what if it is some miminum wage call center person writing that info on a sticky note beside them prepping to commit identity theft? So she "can't find" her license and hangs up saying she'll call tomorrow. It bothers me so much that I can't even wait 5 minutes before calling up and asking for a supervisor/manager.

It turns out that it was standard procedure, but the kicker is they can process it without it. I find this out after some vocal objection. It turns out they can verify the information with the bank, it will just be 2 days slower. WTF!?! Why don't they tell that up front? Why do the need information that not even my bank has. Seriously, if the call script went "If you give us your Social Security Number and driver's license number we can process this request faster. Would you like to give that info?" I wouldn't be writing this.

Way to make your customers paranoid Clarke America!

Update : after talking with my bank it turns out they still call the bank to verify whether the get the info or not. WTF!?! And they even tried to charge me for the re-print too... Grrr....

I had an intersting hallway discussion with a co-worker last night about unit testing and follwoing coding conventions. The readers digest version is that he is against both of them unless he happens to like them. (Why didn't the get him durring the layoffs? Oh yea, he's a team lead...). His defenses are that (a) he doesn't have time to write them and (b) be tests his code when he writes it. The problem with (a) is that he tops the foosball stats with games played. The problem with (b) is that it is a manual process, and he claims that he doesn't have the problem of unintended consequences because he "takes the time to understand his code." So when confronted with the argument of change of code ownership (which happens here alot, but not with him yet) he says "well then the developer should take the time to understand the code before he changes them." Holy Concieted CMM Level 0 Heroic Effort Batman! That is practically a profession of faith against repeatable engineering process, equvilent in value to the typical high school hackers, who he took the time to slander. I wish I could remember exactly what he said because it was so derogitory to people who wern't as good as he was (apparently he never took the sensitivity training that our ex-VP said he needed in his annual review). This discussion occured while he was packing up his laptop and heading home so it ended with him in a huff leaving.

The irony of this is that this morning I found a perfect example of how unit testing protects against the law of unintended consequences, which he says "good" developers never do. A unit test that I do involving schema validation was breaking. Not only was I fixing the coding conventions in those files but our IT/SCM/Build/Developer guy (layoffs do wierd things to job responsibilities...) was upgrading the tools we use used to build and such (being between release and such) including Xerces up to 2.2.1. Unit tests to the rescue! First I reverted all my edited files, still breakes. Then I use older version of Xerces, still breaks, even the version I had before the upgrades. After some head scratching I descide to revert the whole build tree to the last known good point and run the unit test. It works! (I would have been screaming if it wasn't because that shows there is a SCM hole). So I sync one commit list at a time, and it turns out the point it breaks is when... not my code changed, not when Xerces was upgraded, before both of those even happened. It occured when Xalan was upgraded. It turns out that 2.4.1 ships with Xerces 2.2.0, which has a schema realted bug in it. The way the tools tree was set up the jar loading was taking the xerces jar from xalan ($#@&ing manifest files) rather than what the classpath said. Because of the Automated Unit Tests I was able to narrow down the breakage to a single checkin, and then the "Ah-Ha!" moment came much easier. With the reliable test it took me an hour, but wihtout it I would have beens scratching my head all day over waiting for that "Ah-Ha" to occur. not knowing where the breakage really started. And it wasn't that a bad developer was being a code cowboy either, it was that law of unintended consequences striking again when a seemingly innocent change to the system wasn't so innocent.

IMHO accepting and embracing processes like unit testing is what seperates a Software Engineer from a simple developer or programmer. There is a difference.

It looks like I will need to implement the <wizard> local properties definition and the ant call model for <do> sooner than I had intended. It turns out that the nature of immutable properties runs very deep in the ant code. When most of the core tasks are first initialized and run they resolve all of their properties, and if they are asked to initialize again some jsut ignore the request. Change a property and re-run the task and it doesnt take, because the propery value isn't supposed to change! (echo and condition are two examples).

I came across this trying to implement the install type to components mapping, when selected one, saw what was selected, went back and changed my decision. The radio buttons regarding my selection were preserved, but the do section activating the other properties executed the same as whatever my first selection was. Implementing the nested properties will also need to entail a build listener that listens to new property values that are applied to the project set of proeprties as they are set, a simple antcall clones (in a circuitious but needed fashion) the current build project and there is no passing back of the resultant propeties. There are tricks that can be done to get those properties but they seem too much to impose on the end user, it should be integrated and magically work.

The more I do this project the more I feel that there is a significant impediance mis-match between ant and an installer.

The economy cannot be that bad, and the layoffs at Sun cannot be that bad off if they still can afford to have marketing people like this working for them...

Date: Tue, 19 Nov 2002 17:29:43 +0100
From: "Robert Demmer" <robert.demmer@sun.com>
To: "Danno Ferrin" <shemnon@yahoo.com>
Subject: Re: Your Web Log

Sorry Danno, that was sarcasm. I was just trying to get random user feedback for 3.4. As for my research efforts, I found your page didn't I? Once again, sorry for any inconvience and the taking of your time.

-Rob Demmer

Danno Ferrin wrote:

I feel the best thing that can be done is that the marketing team can do their homework a bit better...

(a) My name is Danno, not Dannon (I am not a yogurt)
(b) The only problems I described in that web log entry were with my Replay TV, not NetBeans. In fact I discussed the GUI designer in that entry and nothing about startup.

--Danno


--- Robert Demmer wrote:

---

Hello Dannon,  I just came across your site at http://www.freeroller.net/page/shemnon/20021020 where you mentioned NetBeans 3.4.  I work for NetBeans marketing and I was wondering how you like it?  As I understand you have a bit of a problem (mildly said) with the startup.  Can you tell me a bit about how you use it, plus some positive and negitive aspects of 3.4?  Your help would be appreciated.

Regards,

-Rob Demmer
NetBeans/Sun Microsystems

The truth be told, I haven't touched Inst.Ant for the past few days (not that I get more than an hour when I do). It was almost feeling like a second job how hard I was wanting to push it out as soon as possible. So given that and some technical issues with making a real quality piece of code out o Inst.Ant I think I am going to lay the project aside for a while. Who knows how long I will leave it there, but IMHO it seems that the technical reasons are enough...

Immutable Properties

This one has been bothering me the most of all of them. There are several ways that I can get around it, but none of them feel quite right. Each feels like I am shaving a different corner of the peg called Installer Framework or mis-shaping the hole that a set of tasks on top of Ant should fit into. I've seen some mention of somethnig called "dynamic proeprties" in the "embed" proposal in the Ant cvs tree and maybe ehtat is what is neede, but I haven't looked into it.

Lack of Transactions

I've seen Steve Loughran mention that a time or two, even recently on the Ant mailing lists. This really is a biggie... what if the first most base component you are installing fails, or a middle component? Do you quit with half an install? Do you continue? Do you roll-back? All three of those should be available to the install writer (in increasing order of preference). But there is no way to really group the dependencies together as an atomic transaction which at some level is essential for a good install. True, you could add <try> and <catch> fron Ant-Contrib, but then it ceases to be a declerative build script and becomes a programming language. Go write a custom progam at that point.

Maybe some time away may give me time too look at it from a different perspactive too... Maybe even I am approaching this wrong and I sohuld be writing a Java app that wraps ant and uses it as the work engine when it is assigned. Maybe some time will help me find the right peg, or the right hole may show up, or I may realize that the peg I am holding is sideways. Maybe I'll continue to enjoy Neverwinter Nights as well...

I got a look at the dynamic properties code in the "Embed" proposal in the Apache Ant tree, and it looks like it will do quite nicely. It's actually better than I thought it was going to be: a AOP style interceptor pattern. Basically you register an PropertyInterceptor that intercepts the property get and set methods in a PropertyHelper class. This allows me to make properties set inside of or called by the wizard task mutable without affecting the rest of ant.

There are also some more rather interesting uses of the dynamic properties that are already in embed, the most interesting being the use of JXPath in properties, so you can do a property like ${/target[name='init']/@description} to get the description of the init task. Hopefully this will make the 1.6 release. I may start building Inst.Ant off of embed pretty soon, just as soon ans I stop playing Neverwinter Nights...