« October 2002 | Main | November 2002 »

October 2002 Archives

October 1, 2002

Inst.Ant Open Source Project

Occasionally I get some ideas for OSS Projects that would be nice to do but I never attempt because I lack the time (If I do more than 50 hrs of coding and such and productivity drops dramatically, plus I don't think my wife would appreciate it).

One that has been with me for about 2 years is one I call 'Inst.ant', basically it is a set of tasks and other tools to allow people to build an installer built almost entierly out of Ant build files. From definition of the GUI splash screens and such all the way down to the actual instiallation code itself. The name is sometimes as importiant as the project itself so that is where the name comes from -- Inst for Install and .ant for the fact it is totally Ant centric.

Of course like all kewl ideas like that I never have enough time to execute them. Another de-motivator for me is that there is already another open source jva installer izPack. It's not a total category killer though, since it is GPL and Inst.ant would probobly be Apache Licence. A perfect opportunity to throw gasoline on the open source licence holy war.

October 2, 2002

DRM: Digital Restrictions Management

After reading a story from the San Jose Mercury News linked by Slashdot I got a new favorite phrase for DRM, Digital Restrictions Management. Then it struck me how the word "rights" is as confusing as "free," and in fact how the confusion is almost the same.

In "free" software we are stuck with the english problem that the free part exists on two really differnet areas. Free Beer and Free Speach. Rights is almost the same. Consider my Rights to view a DVD I purchased, and the Rights that exist to distribute that media. The right I have to view it is free as in speech. But the rights the MPAA, RIAA, and the other alphabet soup groups are exerting are free as in beer, except it's not free and they really want their money.

It is liberty v.s. money all over again.

October 4, 2002

Developer Testing

I was going to write a big old rant about developers who refuse to test their code or feel it is QA job or who feel that we need to hire someone to write these junit tests. But it would have been a pointless and long vent that went no where. So let me just say that I am a big advocate of the apporach that XP has to Testing. not jus thte unit test everrything but the whole additude that the developer is the principal responsable agent to chatch bugs. They cannot catch everything, so you have QA people to help there (but QAs real job IMHO should be to test things like scaleability, durability and non-happy-path items the developers tend to developed blinders for, not test-script monkeys). A Developer who doesn't test their code is like a gun without a saftey: an accident waiting to happen.

So waht brought this on? Well testing one's on code can brign greate peace of mind. I am mantianing and expanding on some code that I inherited after a layoff when the previous owner got re-assignemd. Some code changes can have effects across thousands of generated xml files when I intendede them to have effects in a few. To combat this I use a set of validation programs to make sure that all of the XML is internally consistant with what I expect and a diff tool to diff it against a previous know good generation. It is a load off of my shoulders when I can run it agianst the 4,000 some odd generated XML files and find out that, yep, only the 40 files I ment to meddele with were indeed the only ones that got changed. Which reduces the number of files I need to examine by hand 1000 fold.

Testing increases quality and saves time and money. And I sure am liking the saves time part right about now.

Inst.Ant -- Some Ideas

After writing my previous entry on Inst.ant I have does some more thinking on it and may go forth with a simple and non-aggressive plan. Who knows how far I will get on it with the time available.

  1. Inform.ant - This is the first baby step. It will be a set of Ant tasks that create wizard-type forms and can call other ant targets and embed other ant tasks as part of their execution. The idea is that ant properties would be set and tasks would be called from them. I have some thoughts on this that I will detail later. The name is a play on the word "form" as windows folks like to call GUI frames.
  2. Compon.ant/Propell.ant - The next step would be self-packaging of the install scripts (but not totally self sustaining). Compon.ant would assemble the nesscicary files into jars and handle the accessing of them at run-time when the installer is run. All-in-one packageing would not be addressed in this stage but a single jar presuming a jre would. The Propell.ant part would be the changes and redundant ant tasks that would be needed to handle URL and input-stream based tasks, such as unjar, copy, filter, et. al. (all of those are currently file based only). And yes, I know component is the real spelling, but I got a theme going here
  3. Dist.ant - This would be the final stage. Each built on each other and useful on their own. This stage would address all in one packaging including specifially the embedding of the JRE needed to run the Inst.ant archive. Shell scripts for unix and .EXEs for windows. I know some shell tricks for unix but windows would be more involved.

Of course this may be pipe-dreaming because it is a function of available and budgeted free time.

October 6, 2002

Inform.Ant Initial Design Steps

After thinking about it it looks like Inform.ant will consisit of 2 (maybe 3) ant tasks. One for a splash screen, one for a wizard, and possibly one to handle random dialogs. There is also a longer term goal that the forms defined by Inform.ant could be used with a variaty of methods. The first will be swing, the second command line (possibly with pre-answered questions). Then possibly SWT and or ANT (for 1.1.7 jview run installs) but those would be after compon.ant and propell.ant. So where it makes sense I am also thinking about these in context of a headless or scripted mode.

Splash task -
The task definition itself will only handle the details of the window it is a slapsh for. Size, location, etc. The children will be the actual content and the tasks to be performed with it. I imagine a <image> and <htmlPage> child to support an image or a HTML page as the splash screen. Then either a tasks element (subbing off of sequence), sequence and paralell themselves, or the other tasks themselves as children.
The reason behind not putting the splash stuff all under attributes to the spalsh task would be because sometimes the spalsh content may want to change as the work progresses. Much like your typical symantic install process. The sizing attributes would have to take into account multiple size images and htmlPage possibly too.

Wizard task -
This is, quite clearly, the more complex task of the two. The idea would be the same, the outer wizard task would just contain frame information and stuff like the name of an ant task to do on cancel and such. The Children would contain the guts of the wizard and the aditional tasks to be done durring the wizard.
This task could be quite involved, especially since I am going to be following the Java Look and Feel Guidelines for wizards. I would like to allow for as much of the functionality describes there as possible.
As for the form components themseles, I will probobly follow a sub-set of XForms, except that the fields will be tied in to Ant Proeprties instead of an XML instance. From those proeprties different tasks for different install options can be triggered.
I should also provide an interface to be impementd so that custom pages can be defined in Java themselves. But a goal would be that 80% of the uses of Inform.ant could be done declaritivly in the Ant Script itself. To do this however I may need to enlist the help of the script tag and re-defining of ant variables.

As for dialogs, I don't know about what I will do. Prohaps I will just support the 4 basic ones from JOptionPane with no wierd stuff (like custome fields). I can see how I would need those.

My current plan however is to get the splash tag written and then get some more design done for the wizard tag.

October 8, 2002

Inform.Ant: instsplash drill down

Time to drill down onto the <image> and <htmlPage> sub elements of the <instSplash> task.

<image> - href, file, or resource are required and mutually exclusive.

  • href [java.net.URL] - A URL to the image to use.
  • file [java.io.File] - A File containing the image to use.
  • resource [String] - A java class resource resolved via ClassLoader.getResource().
  • classpathref [String] - A ref to a named classpath element. This classpath will be used to get the image if the resource attribute specifies the source.
  • <classpath> - As per the standard classpath element. First the classpathref, then each of these in document order will be used to find an image specified by a resource attribute.
  • resize [String] - One of "center", "stretch", or "tile". If the splash panel is not the same size as the image this is how the size discrepancy will be addressed.
  • backgroundcolor [String] - The background color of the splash screen for this image. Useful for images with transparency and center resize policies. The value must return a color from either java.awt.Color.getColor(String) or java.awt.Color.decode(String) (in that order) or the default panel color will be used.
  • #PCDATA - Will be used if the installer is run in "Headless" mode (either by a future configuration or a java.awt.HeadlessException). Contents will be output to the console. (this will need another look for i18n).

<htmlPage> - href, file, or resource are required and mutually exclusive.

  • href [java.net.URL] - A URL to the HTML Page to use.
  • file [java.io.File] - A File containing the HTML Page to use.
  • resource [String] - A java class resource resolved via ClassLoader.getResource(). There are implications with relative URI references here, so it will definitely be addressed later rather than sooner.
  • classpathref [String] - A ref to a named classpath element. This classpath will be used to get the HTML Page if the resource attribute specifies the source.
  • <classpath> - As per the standard classpath element. First the classpathref, then each of these in document order will be used to find a HTML Page specified by a resource attribute.
  • <html> - The actual content of the HTML page in XHTML(may be cut out). This seems to be a pipe dream since Ant does hardcore parsing of all of the elements and I cannot just pass in the children as a org.w3c.dom.Node or NodeList and flatten it to text. But this is what I would like to do.
  • #PCDATA - Will be used if the installer is run in "Headless" mode (either by a future configuration or a java.awt.HeadlessException). Contents will be output to the console. (This will need another look for i18n).

Those are the end-user use case for the instSplash task. The design would need to use a factory to handle whether it is being run in Swing, console, SWT, or AWT mode. I'll address that later should I start writing code for this.

Inform.Ant: Splash Task

After reading the new Appendix E from the Ant 1.5.1 distribution I realized that there is already a task named "splash" in the optional tree. I went and looked at it, but it is not what would be needed for installer type items. I want more!. It is a coole idea, with the progress bar and such but (a) the progress bar incraments one value per build event rather than a 100% progression and (b) it's locked into images only with a pack and center approach only. The progress bar has some implications for the Propell.ant portion.

Here's the sort of stuff I would put into the Inform.ant splash task, which would need to be called something like instSplash:

  • zoom [String] - How the splash page would be shown, one of "fullscreen", "packed", or "fixed".
  • width [int] - Width of the spash panel, for zoom="fixed" only.
  • height [int] - Height of the spash panel, for zoom="fixed" only.
  • decorated [boolean] - Whether or not the spash window should have decorations (frame border, open/close/zoom buttons, etc). A flag for either calling setUndecorated(true) or putting the frame in a JFrame or a JWindow.
  • <image> - Shows an image in the spash window (more detail tomorrow).
  • <htmlPage> - Shows an HTML page in the spash window (more detail tomorrow).
  • <sequence> - As per the existing sequence tag: do the embeded items singularly in order.
  • <parallel> - As per the existing parallel tag: do the embeded items in parallel and join threads at the end.

The child tags could be put in any number and what the instSplash screen will do is show each image or html page as they are reached, and then do the intervening tasks. Much like some old school installers would do when you press the "install" button: showing adverts for other products by the company as the install progressed.

Foosball (and those who dislike it)

Another guilty pleasure I have at work.
Q:What do you do when you are waiting for a 5 minute build to complete?
A:Play a 20 minute game of foosball.

Foosball has quite a legacy at my work. To Celebrate the competing of a milestone early in our 1.0 cycle our CTO got us a Foosball Table (A Tornado) for us to play, when we first started playing almost all of us stunk, quite bad. But after year(s) of practice we are much better.

When we first got the foosball table a new VP of Engineering had just started working for us. He was from Massachutces so he wasn't quite the dot-com type fun loving executive you would expect. (The grey hair kind of gave it away). He hated the amount of time we spent playing foosball so much to the point that after 1.0 shipped and we were starting on 2.0 that one day he pulled in every regular foosballer he could into his office to have a "talk." (I was working at home that day, probably dealing with the clowns form Adelphia). This "talk" was a bit of beating around the bush asking us not to play foosball durring work hours. Play on the foosball table that one of the founders bought for us to play at work. And the irony was that four of the people he got in had, just a few weeks earlier, won the Chariman's Award for the work they had done for 1.0, while playing foosball durring comapny hours. Needless to say that was not a way to inspire morale amoung the masses. Productivuty dropped for a bit too. That was yet another reason we all put on our "reasons we hate (too strong) reasons we dislike (too surgar coated) reasons we wish our VP would move back east" list.

There is some silver lining to this though. When the layoffs came Mr. VP was the first to recieve a Pink Slip. Technically he complied with a request by the board to submit his resignation (they let him keep his dignity). So when we had a problem with one of the adjoining confrence rooms being busy with sales meetings (the table was loud enought to cause problems in that room) some of us decided to move the table. Of all of the places we could choose we moved it into the old VPs office.

The good part is that now we are more productive. With the table so much closer we don't waste as much time going there.

October 9, 2002

And the Records Indicate...

Woo Hoo, I got my first quote today [rebelutionary].

Boy am I glad I didn't post names of current/former co-workers.

October 11, 2002

The Future is Now

I've only really had my head stuck in the blogsphere for only two weeks and already I am convinced that it is truly the future of content on the internet. At least as far as Geek stuff goes. Or maybe I am just noticing that Slashdot is no longer the leading edge of geek news that it once was.

Consider these two stories that I first found on my RSS feeds I aggregate, the first was The Parable of the Languages. I had read it two days earlier. Then there was Tuning Java Swing Apps for Mac OSX, again something I had read days earlier. It is kind of ironic though, since slashdot could be considered one of the most well known web logs out there. Cmdr Taco once said himself when people were bitching and moaning about the quality of teh content when OSDN bought them that they really started out and would continue to be posting news that entertainer Hemos and himself.

I guess that means that the poineers never truly lead forever, witness PARC and Cray as more evidence. The bleeding edge has scabbed over slashdot and has now surpassed them into the realm of the independent web logger. But slashdot is still worthwhile for a good laugh now and then

The future was now.

October 12, 2002

Assholes and Free as in Beer Software Development

Apparently Mr Stevens is now so famous he has his own "Excuse for being an asshole" page. Amusing! [rebelutionary]

Well, I need to put my two cents in as a former Jakarta committer. Jon's demeanor on the mail lists is at times as a total asshole, but I would have to say as an equal opportunity asshole (give him an opportunity and he'll be an asshole). The fan club page makes a persuasive argument that Jon will be Jon and what you should do rather than complain about Jon is to contribute to the project (and state that he's probably a nice guy in person).

But therein lies the problem, there is somehow the implication that if there is a problem with Jon, it's your problem. And you should just get over it and contribute to Jakarta. And it implies that this is only a small barrier to entry in the Jakarta project (which is your duty to join anyway). But it is not just an outside facing problem.

As you noticed I identified myself as a former committer, even thought if you look on the Who we are site I am listed as a committer, and even though I haven't done squat for nearly 2 years. Apparently the membership clause which reads "A Committer that has been inactive for 6 months or more may lose their status as a Committer" interprets the word MAY in accordance with RFC standards which means "basically never." That and my e-mail is about a year out of date too. But I digress. Why am I a former committer? To say it is because of Jon's behavior would be unfair and inaccurate. Blame it on the real job, the serious girlfriend, and the ensuing marriage. I just didn't have enough time to contribute to Jakarta for free (as in beer), I would much rather spend my free (as in liberty) time enjoying it. Those things alone would keep me out, but throw in Jon and people like him (he's not the only one, just the most famous) and it goes from a "probably not" to a "hell no". Andrew Oliver also reflects some of my feelings on the politics that keep me away (the 6 Sep entry to be specific).

I'm not bagging on Jon just to bag on Jon however. Where I want to go with this is an inherent problem with free (as in beer) software development. It's amazing how much thicker your shell gets when it is padded with a few pay stubs. Is Jon the biggest asshole I've ever seen? Not by a long shot. I've even worked with bigger assholes than Jon, willingly and happily. All the resentment that comes with working with an asshole goes away when the rent check clears. I probably would get along just fine with Jon if I worked with him in a paying job. Sure, we would have our moments, just like everyone at my work tends to have with each other at one time or another. Would I deal with the crap that goes with being an active participant on an Open Source project for free? Not unless my life dramatically changes. Would I do it for money? I already do on a daily basis (for a proprietary project that is).

But for the fan club page to trivialize the problem as not a poblem is IMHO the wrong solution and sullies the good name of the... umm... oh nevermind.

October 14, 2002

JView Swing Suprise

Color me suprised! I downloaded Swing 1.1.1 from the java web site and ran it against Microsoft's JView program, and my splash stuff worked with only Java 1.1 level tweaking! I also ran the SwingSet test and was suprised that the performance was fine! (1Ghz and 512MB of ram may have figured intot that however...)

The upshot of this is twofold: first I will be able to comply with the Apache Ant Task Design Guidelines and write the Inform.ant portions to conform to Java 1.1. Second is that Inst.ant can be writting to run on a "stock" Windows machine without having to got to an AWT parallel solution. Just include the classes in swingall.jar and you are good to go. So the odds of seeing a SWT version also fell to near zero as well since I won't be plugging anything but console and GUI, where GUI means swing. Being able to run on JView was the whole point of designing with multiple GUIs in mind, so now I can go with a "write once, debug many times" solution.

Sourceforge is set up

I got the sourceforge stuff set up for the Inst.ant project. The info page is at http://www.sourceforge.net/projects/instant/. Hopefully by Saturday I will have some code up. Some progress is coming on the splash task but that is small cookies compared to what should exist for the inform.ant piece. But there will need to be a good amount of forward design before I start to code the wizard.

October 15, 2002

Inform.Ant: Wizard Task and XForms

Just printed out the XForms working draft specification, it is quite a beast at 169 pages. I was thinking that when I did the wizard I would do some sub-set of this, but the functionality it calls for is another open source project in and of itself. It tries to cover every possible use of forms under the sun and under the moon. So when I design the wizard task I will be using some subset of the controls from XHTML 1.0 which is to say HTML 4.01.

Not that I wouldn't mind implementing XForms, since it specifies a standard model of the widget dynamically interacting with each other. Most complex installers have that to some degree (like checking the "use proxy" checkbox on one page and then all of the other items enable themselves). But I would rather have some Compon.ant, Propell.ant, and Redund.ant parts complete before I would come back to address that (in about a year or two when the spec is complete anyway).

So then what will be available is check boxes, radio buttons, text boxes, text areas, password boxes, selects, lists, and labels all syncing their values to project properties. Items can be enabled or disabled but on the first pass through that will only be evaluated on next/back transitions.

What was I doing in 1993?

What were you doing in 1993? [Russell Beattie Notebook]

Not too interesting: My life as a greek introduced me to the first girlfriend that wanted to marry me. The thought was so diturbing at the time that I ran off and joined a bike gang in rural Tennessee. In 1998 I met the second girl that wanted to marry me, and now I am married to the third one (but for a change I had to ask to find out).

October 16, 2002

Response: Rickard's AOP thoughts

Rickard posted some thoughts on AOP and I must say it is amazing how some of those items could be done in non-java without the pre-processors (thought not in the same language). To me AOP is just like OOP and structured programming before it: principally a practice. It is also a practice that is re-enforced and simplified by language constructs.

(However I would like to say that EJB is an example of seperation of concers; as long as what you are concerned about what EJBs are concerned about.)

Here goes. AOP, to me, is two things: first, you get to pick objects apart into smaller parts each of which has a nice clearly defined purpose. These parts can then be assembled to form big objects. [ Random Thoughts ]

As you go on to read further what started registering in my head was *hushed*tone* Multiple Inheritance *gasp*. What it is closer to however, is the OOP pattern composition. I haven't seen this achieved that often except in rather brittle examples. When you think about it though composition is a OOP way to achieve separation of concerns. It was the casting example that made me jump out and say that it can also be accomplished via multiple inheritance. But in that case you lose the possibility of composing the object of sub-classes of the pieces, like a V-8 engine for a Denali v.s. a 3-cylinder for a Geo Metro. At a cursory glacne it appears that using AOP to gain this type of composition also suffers from this flaw. What if I want Unix type User-Group-Other ACLs on some and NTFS every-possible-permutation style ACLs on other objects? You could flatten out the classes and make two ACL type. But this false when that choice varies not based on type of object but arbitrarily per object. For example: some pages kept on client A's extfx system and some on client B's NTFS but both aggregated in the same place. That's why I don't see how (ACL)page has any intrinsic value (other than aesthetics) over page.getACL(), in fact it seems that the latter is better in that sense.

However, this is a red herring over what AOP is providing, in that when following the principals of AOP you can do either to achieve composition. What is important is that you don't litter the ACL code special cases in with the other items and keep ACL code i the ACL. It seems to me that if you cannot keep ACL code in one place perhaps the concerns are not separated properly or they are not separable. Keeping the concerns separated is alot easier when the language and framework are designed with separation of concerns in mind.

Second, AOP is also about what most people would call "interceptors". That is, doing stuff before and after a method call on an object. [ Random Thoughts ]

What came to my mind from this paragraph is function pointers, or as Microsoft calls them toady delegates. Also C macros are quite crafty in that regard. For function pointers you could write a method to do the work around the method and then call the other method, and store it with the other method. But to do it arbitrarily to arbitrary code you would need (1) to make all function call through pointers and (2) some place to store what the previous function was. To accomplish 2 you would need to pass some overhead like a pointer to a stack of methods to know what the next one is, which is exactly what AspectJ and what Rickard's code example do.

It is crucial to remember here that while the object being referenced in client code may implement 10 interfaces, there is no class (beyond the dynamic proxy class) that actually implements all of those. They only implement one interface, and the AOP framework takes care of the routing from this big happy I-got-it-all "object" to these smaller objects. All of that is transparent to the developer though. [ Random Thoughts ]

One object that can accept any message... hmm... doesn't SmallTalk allow any message to be sent to any other object? Seems to me more and more AOP languages are talking the shiniest pieces of other languages and making them their own. Sure you could do it in C, but you wouldn't want to since void * is a great way to fumble the memory heap.

This feels like going through the candy store and throwing out the blue SweetTarts, M&Ms with peanuts, and anything made with dark chocolate. How can anyone like dark chocolate?

October 17, 2002

Many ways to skin a cat

Ok, how does one determine the size of a text field from the maxInclusive="12345" field of a XML Schema xsd:element? Does one do this (packed into one statement or many as tastes dictate)...

String maxInclusive = element.getAttribute("maxInclusive");
double d = Double.parseDouble(maxInclusive);
d = Math.log(d + .9); // for the case of 100, we need 3 not 2
d /= Math.log(10);
d = Math.ceil(d);
return (int)d;

That's what I intially did. Too much time spent in math classes in high scool and college I guess. That blinded me to the more elegant solution... return element.getAttribute("maxInclusive").length(). And I even spent time looking online to verify that log10(x) is ln(x)/ln(10) after the guy with a degree in statistics couldn't remember for certian!

October 18, 2002

Inform.Ant: Wizard first design steps

p>When designing the wizard I am trying to keep three different wizard look and feel design in mind: The Java Look and Feel Guidelines, Gnome Human Interface Guidelines, and Microsoft Windows. The good news is that they all jump out and shout Border Layout. The particulars of the imaging and the wording deigned by the wizard specs can be left to the user. There will be some design trade offs, however. Gnome specifies that the cancel button should be on the left, Windows and Java say on the right. Gnome loses this battle and (for now) will not be supported and the buttons will be on the right.

Java on the other hand has some particular allowances for what can be put on the left pane which segues nicely into some of the functionality that a wizard needs, namely to skip some pages base on user values or other reasons. For example when you select "standard" install you shouldn't get the pages with all of the custom component selections. This will be handled by the child <step> type of the <wizard> task, which will be able to contain all of the same children that the wizard task contains. These would both support "if" and "unless" attributes.

The next thing we need to handle is "next" and "back". This would be handled by a <prompt> element that would indicate the buttons that can be showed and their state. Then we would need <do> and <undo> elements based on what the user selected in the prompt. These would just be re-named sequential elements with "if" and "unless" attributes. (cancel would unwind to the beginning and exit).

Well, I got to go meet my wife for dinner so I'll go deeper later this weekend.

First CVS drop

Normally I wouldn't post about every CVS drop of Inst.ant, but this is the first one. Not a whole lot is there yet, but the splash task is as done as I'm going to make it until I either get the wizard task in working order or new bugs are reported against it.

Most of the interesting stuff is, as always, in the CVS. I have only posted the compiled jar and the docs for the one task, but the CVS has source code and a few test cases I wrote for it. Once wizard is in some working shape I'll do a better web site for it.

Inform.Ant: Wizard Initial Design continued

Back from dinner. We tried a local mexican restaurant that seems to be good, better than the chain sit-down establishments we have tried.

Now, back to to body content of the <wizard> task. In addition to the operational tasks we need to update the images along the way, so we add <header>, <sidebar>, and <page> elements to handle the top, left and middle portions of the traditional wizard. <header> and <sidebar> will be treated in a similar way as the splash pages, except that they will show for the duration of the wizard or until a <header> or <sidebar> with a new attribute display="false" is encountered. The border and sidebar panes will be missing before one of these is encountered and after display="false" is encountered.

The <page> element is where most of the interesting stuff happens. Previously I stated that I was going to use HTML 4.01 forms for the content model of that page, I changed my mind. First, <input type="ugly"/> looks heinous. Second the Java Look and Feel suggestions for wizards mention context sensitive help, like one for each form element if needed. XForms in it's current rendition includes a help element that goes with each control. It also contains hint elements that I intend to use as tool tips. So what I plan to use is an arbitrary sub set of XForms with some changes of my own. The first being that the "upload" control will be re-named "fileChoose" and will be able to select directories.

So that looks like the gist of what will be there, sans attributes.  I'll invent some hacked up BNF/DTD representation as a summary:

wizard : %wizChildren%
step : %wizChildren%
%wizChildren% : (step | header | sidebar | page | prompt | do | undo)+
header: (image | htmlPage)
sidebar: (image | htmlPage)
page : %inst.form%
prompt : -emptey-
do : %antTasks%
undo : %antTasks%

October 20, 2002

Productivity is the name of the game

Last night while I was starting to write some of the GUI code for inst.ant I initially tried to code it all by hand, to be as IDE agnostic as possible. However I came to the (not so quick) conclusion that coding guis by hand sucks. So after a brief struggle with my ReplayTV I came back and fired up the GUI editor on NetBeans 3.4 and within half an hour was a lot longer along than I had been all night with coding by hand. After a little more work today I've got some more of the frame working like I want it, and I feel it would have taken me two to five time as long as by hand. The downside of this is that some of the generation stuff is going to wind up in the CVS tree. But after getting so much done I don't care as much as I used to.

It's not that I am a neanderthal and feel that machine generated code is the spawn of the devil. At my paying job I use the NetBeans GUI designer any time I do GUI work. But since the only other guy doing UI coding comes from a MFC background machine generated code is not a problem for him (as long as it comes from a wizard). And if any of the other people I work with have a problem with it (which they haven't yet ) I would just say that "If you want it done your way then you better do it yourself." and laugh as they work self-inflicted 80 hour weeks. Back in the day when GUI meant AWT I would always code my GUIs by hand, but that is because back then GUI editors sucked real bad.

It's amazing though how ingrained the feeling of "if it's not hard I am not really coding" can be sometimes. It makes me remember the time I was in Chemistry class arguing with one of my friends at the time the merits of high level languages over assembly (I was on the side of C++, this was pre-java). He just wasn't getting that time==money, and argued that you could do anything with assembly that could be done in any higher level language because it gets compiled to that anyway, so why not jsut start with assembly? He also had a hard time grasping the concept of showering daily to impress chicks.

But once the light bulb turns on it can become a blinding searchlight. A little less than a year ago a Windows consultant realized that "The power of Java (and therefore the power of .NET) is that it provides a major productivity boost for the programmer." (He directs the rest of the blog entry at dot net granting the same power). A coherent toolkit for the right problem can be like dynamite is to mining ore. Yes you could use a pick axe to build a tunnel, but if you had dynamite you could safely use you wouldn't want to.

(edited after a good nights sleep for comprehension)

October 21, 2002

Wizard task revisited

My original concept of the wizard task children was a set of items that would be evaluated in forward or reverse order based on what the user said at the prompt elements, but based on what I have coded it will not quite work. Consider pseudocode of my first approach in my test file...

sidebar image A
prompt 1
sidebar image B
prompt 2
sidebar hide
prompt 3

This would describe three wizard pages, the first with sidebar image A, the second with sidebar image B, and the third with no sidebar. You would expect that if you go to page 3 and go back to page 2 that you would see sidebar image B, well in the simple algorithm I coded you would stop at prompt 2 but no sidebar image would be produced. Going backwards from prompt 3 you would encounter sidebar hide and then get to prompt 2. Back again would bring you to sidebar image B and then to prompt 1. But sidebar image A would never be seen once passed. This can be coded around...

sidebar image A
prompt 1
sidebar image A
sidebar image B
prompt 2
sidebar image B
sidebar hide
prompt 3

But this sends a shiver down my spine as being (a) ugly and (b) brittle due to code duplication. Clearly just going forwards and backwards will never work, and I never realized that because how often do you write code that is intended to be run backwards as well as forwards? Even when you kick out of a transaction the code is read forward but you just unlock in reverse order you gained the locks. It's like a stack, going back down in it is still coded in a forward fashion.

So here is my current thinking (but the names of the elements may change, suggestions welcome):

<wizard> : wizChildren
<step> : wizChildren
wizChildren : (<step> | <prompt> | <do> | <undo> | <doDisplay> | <undoDisplay>)+
<do>: ant tasks
<undo> : ant tasks
<prompt> : promptChildren
<doPrompt> : promptChildren
<undoPrompt> : promptChildren
promptChildren : <sidebar>?, <header>?, <centerPane>
<sidebar> : splashChildren
<header> : splashChildren
<centerPane> : splashChildren, <formPage>

Rather than having the sidebar and panel be direct children of the wizard task, they are direct children of the prompt element, or the two new ones doDisplay undoDisplay. This makes what should be a "page" more atomic, and also separates the page from the transition code between those pages. The doDisplay and undoDisplay elements allows for the wizard page to be changed during execution of long tasks without soliciting "must respond" interaction. There are still some nuances for cancelable tasks and ordering, but those don't look offensively ugly like the first approach. Given this re-design the pseudo code would look like...

prompt 1
    sidebar image A
prompt 2
    sidebar image B
prompt 3
    sidebar hide

It doesn't look too different from the initial but this is a simple example. A more complex example would have betrayed just how bad my first look (it would border on un-readable). Hopefully it would also show just how much better this new approach seems too me right now, bit I haven't coded any really complex stuff.

On a different note I have decided on an initial goal and litmus test for deciding when the various parts of Inst.ant are soup: Can it install Tomcat? For inform.ant it will be can it gather all the install data for Tomcat. For propell.ant it will be when it has the tasks to do all of the nifty platform specific stuff like application menu items, service/daemon instillation, proposal of good default locations on Windows, Linux (ReadHat 7.3), and Mac OS X. For compon.ant/redund.ant it will be single-jar instillation of the precious. And for dist.ant it will be native executables for the same, although that task looks kind of distant.

October 22, 2002

AOP and polymorphism again

It looks like my ramblings have been noticed. A post where I was discussing how several AOP patterns could be done in non-AOP frameworks and languages (much like OOP and non-OOP) was responded to in a fashion of "My AOP is not like that! AOP is the second third fourth coming of High Level Language Nirvana!" Ok, it really wasn't that extreme but it was really fun writing and editing the last sentence. However I do feel that some of my comments were misunderstood in the response.

Rickard's response focuses entirely on my composition comments, first starting with my analogy of the Denali and the Geo Metro.

When you think about it though composition is a OOP way to achieve separation of concerns. It was the casting example that made me jump out and say that it can also be accomplished via multiple inheritance. But in that case you lose the possibility of composing the object of sub-classes of the pieces, like a V-8 engine for a Denali v.s. a 3-cylinder for a Geo Metro. At a cursory glance it appears that using AOP to gain this type of composition also suffers from this flaw.
It doesn't, not in my framework anyway. You can either specify a default implementation for an interface, or you can specify that a particular implementation of an interface is to be used in a specific composition. This accomplishes what is outlined above. [ Random Thoughts ]

My analogy wasn't perfect, although it serves some purpose. A better example may be a Saturn VUE. You can get one with a 4 cylinder or V6, and you can get 4WD or AWD. A few sentences after the quote rickard had I mentioned that this can be solved by flattening out the hierarchy, as Saturn does. All four possible compositions have their own class. At this level the combinatorics aren't that bad. Now let's consider that each car can have any of 3 stereo systems, 2 interior colors, 7 exterior colors, and about 5 other options. 2*2*3*2*7*2*2*2*2*2=5376 possible ways to have your saturn. Now what if we added a third type of braking system (Anti-Injury Inertial Dampening Brakes)? One of those 2's become a 3 and we need over 2000 more ways a car can exist, and creating one class per car type is expensive in the hierarchy alone!This is what I meant from flattening the hierarchy. (Full disclosure: we are 2 Saturn family, but don't own a VUE.)

Having not seen Rickard's code, I cannot be sure if he is creating a concrete class for each combination, but there are two possibilities I see from reading his posts. The first is that he is only creating the 10 particular concrete instances he would use out of the huge combination space. Which is fine if you can statically prove that those 10 would fit your needs. The second is that he is storing them and the class is actually a proxy, and the cast to (ACL) is casting to a proxy that forwards all requests to the concrete class. Instead of writing or dynamically generating that big old proxy class why not just write one interface ACLable with one method, getACL()?

Neeext.
What if I want Unix type User-Group-Other ACLs on some and NTFS every-possible-permutation style ACLs on other objects? You could flatten out the classes and make two ACL type. But this false when that choice varies not based on type of object but arbitrarily per object.
I don't think that is very realistic. What is realistic is that a bunch of objects in a system are somehow similar and have the same way of handling the ACL interface. [ [ Random Thoughts ]

It wasn't the realism I was trying to address with this example, which was not about how the files are stored but about the ACL itself. In the next section Rickard describes how he solves this is to flatten the hierarchy into 3 cases, which is what I described as well more or less. I could find a more realistic example but apparently they are not in your system. I was trying to describe a composition that was not binary (ACL v.s. no ACL) but had more complexity, in this case trinary (Unix ACL, NTFS ACL, no ACL). The fact that the example dealt with file systems and storage was what was focused on rather than the implications of the different ACL schemes that they have. Both can validate create, read, update, delete permissions but have wildly different ways of coming to those decisions and different data sets to draw from. But this seems to be more the realm on the Strategy Pattern that the Composition pattern, which is another design pattern that can use and abuse polymorphism and late binding. Objects requiring arbitrarily changeable components may not be the case in your system, but when you really need them you really need them.

Well, I really need to get work done today.

October 23, 2002

So that's what's in a name

My little bit about names sure made a quick round. I learned two cool things, the first being how you can use google to get people's real names from their e-mails. But I tried it and root@localhost gives me so many confusing results I wonder if it's a bogus e-mail address, so I guess ThongGirl73 lied to me in the chat room the other day :(

The other thing that Russell Beattie mentioned about a "personal brand." For kicks I occasionally do web searches on myself to see who is referenceing me. I learn all sorts of things like a presentation I presented nearly 7 years ago on Class Loaders is still alive on someone else's web site, and that one of the first Java classes I worte was also used on a JIT benchmark. That and I also learned that apparently I whine alot ;). But I diregess. The top search on shemnon was a really old open source project I did just before Jakarta was announced, JCCSP, which I did mostly because I was playing with grammers at the time and thought they were cool. But my current weblog? Fifth. And searching for my name? Weblog no where. My "personal brand" is not associated with my current writings.

So what is the value of a personal brand? Let me run a few names by you: James Duncan Davidson, Jon Stevens, Russell Beattie. Because of the strong associations with those names you know who they are. And if they ever need to look for jobs then recognition like that can help immensley, even in Jon's case. Especially in Jon's case because people know what they would be getting into up front and there is a lot of value in prior knowledge, it's mutually benificial for both parties.

Such a personal brand could be useful. And if someone find's your weblog you don't want it to incriminate you. My weblog title is bad enough, I'm just glad I didn't name it "... By My Show Stopping Bugs" or "... By My Arithmetic Errors That Lead To Kernel Panics" or even "... By My Total Aversion to Production Worthy Code." The reason I didn't use those is probobly because they don't describe me even if they would be rather funny. You know I probobly should consider changeing the name of my web log.....

What's in a name?

Ahh... Apparently my high quality page design has caused some confusion about what my name is. It is now out there, on the right underneath contact info. My name was easy to find when I was using the default grey theme, but I changed that and missed putting some info in, and I just barely did it yesterday, how timely. I also just finally got around to making some non-default bookmarks anyway. I thought about putting my picture on the right as well, but Anthony has file uploads turned off on his roller installation, can't say I blame him. Besides, that's not really an accurate picture anyway, the photographer thought the goggles might be cooler than glasses.

So what is my name? Apparently I confused Rickard and all the info he had available was "The Speling Error guy" (good guess, I am a guy, although references to a wife aren't always a dead give away). Where did I get the name for my blog "And They Shall Know Me By My Speling Errors" anyway? Well I was listening to the Music Choice Alternative they had a blurb come up about a band named "And They Shall Know Us By the Trail of Dead" commonly know as "...Trail of Dead." I've probably heard one of their sons at sometime but I couldn't place it. Anyway the place they got their name was from some ancient Mayan writings. I thought the name concept was incredibly cool (except for the killing part) and decided to make it my own. Since they got their name from some Mayan writings I wasn't stealing from them but really from the Mayans, and since copyrights are only good for 50 75 100 years and they Mayans are long gone they cannot sue me. And rather than killing people I have a bad habit of mis-speling words. (Full disclosure: that last one was intentional) (Full disclosure: I have ieSpell installed on my machine and you can see the good it does). Boy, I really like that "Full disclosure" bit. I picked it up from RatcliffeBlog when he was ripping on webloggers who went to Mobeous 2002 and didn't disclose it on their sites. (Full disclosure: I didn't go but would not have turned it down, assuming it was paid for). And to think that Ratcliffe thinks he knows more about the PDA market than I do! (Full disclosure: I am sure he does)

Another person referred to me simply as shemnon (I'll link it later when I find it. It was about a week ago and have long since reclaimed that weak reference). Where did I get shemnon from? Well, there is that legendary racer Shemnon Patterson who races at Wenatchee Valley's Super Oval, but it's not him. There is another obscure reference that google would help you find.

Which brings us to my real name..... which is not Danno. It's Daniel. How do you go from Daniel to Danno? Well, first your mom shortens it to Dan, then when you are two you are pretty dang certain that you mom keeps calling you Danno when in fact she is saying Dan, no! Cute story eh? Ultimately wrong, like the origins of another name we have all heard: cute, but ultimately wrong. The real story about how I started going by Danno has to do with my high school debate coach and the state tournament my junior year. It's not as exciting a story as the others I've told, and since I've already spent too much time writing this I should probably go now. I hope you have as much fun reading this as I have had writing it!

October 24, 2002

(not so) Inst.Ant Update

Things have been slow on the Inst.ant front. Most of my free time this week has been spent either playing with my paintball team's website or re-installing XP on my home computer. Explorere.exe was blowing up every 10 minutes and I couldn't change my desktop wallpaper. That is probably a result of my installation being an upgrade from Windows ME. I'de also like to thank Erik for getting some Mac OSX integration going on.

Roller Upgrade: Thanks Anthony!

Anthony upgraded the version of Roller today to version 0.9.6 today, and I have a big "thank you" to send to him. There is now a posting HTML editor, so I can see when my itallics, bold , and strike tags end without posting (althouthg I had to go into source mode to get strike). There are also referrer logs (visible on the right if you are actually on my page) and the annoying problem with &amp;, &apos;, and &quote; are gone in my news aggrigator Aggie (I know, I am contributing to the problem by using dot net).

Happy day!

October 27, 2002

Inform.Ant: Wizard Framework Working

I now have the Wizard task working more or less how I like it. As per my previous posts putting header and footer inside of the prompt made for a more intuitive look and feel. I also added if and unless attributes to do, undo, prompt , doPrompt, and undoPrompt. To see all this in action you can downlaod the CVS and run "ant test". Documentation is non-existant, but I never intended to address that until it was truly ready for public consumption.

I also added another task, plaf, that takes a single argument name. This sets the Swing looka nd feel the the class named in name. There are also two magic values, "system" and "cross-platform" which will set it to the native look and feel or the java look and feel respectivly. I've tested with system, cross-platform, and kunststroff and it seems to work just fine.

The next target will be to get some semblance of the formPage element working for the prompts, so some interactive pars can begin and I can start trying to make a real install wizard for something usefull.

October 29, 2002

Eclipse and Ant

If you use Ant with Eclipse , you might want to check out these two new plugins Antview and Planty.

The Eclipse folks liked both these tools so much, they've asked the author if the would consider donating them to the project. It looks like Antview's author has accepted, so the next release 2.1 will include some or all of AntView [ A cup of joe ]

I may have to actually look at eclipse again. Support for ant like what they had in the screenshot was my #1 complaint about it. Now if they just had keyboard shortcut re-mapping.....

October 31, 2002

Loads of Ant 1.5 Goodness

At my work we finally got around to getting Ant 1.5 into the build process and taking advantage of the new features, which are just what we need. As a co-worker said "Ant seems to be writing the solutions to the problems we are having in the build as we develop them." I've only had a chance to put two of the major new features in, and boy are they good ones:

  • filterchain expandproperties
    This has eliminated about 200 lines of build.xml, all of them lines like <filter name="property" value="property"/>. This also eliminates a point of breakage where a config file depends on a new property, and we forget to put the values in wherever they are needed.
  • classfileset
    This eliminated another 100 lines of build.xml. And also helped get rid of about 100 classes from the applet jar we have. And if we create a new dependency to some class in a different part of the code tree? No build file changes! I used to use jini's classdep tool to ge this data but now I can just have Ant do it automatically, as a fileset even!
Given features like this it amkes build maintenence a treat to watch things optimize themselves, rather than haveing a dedcated makefile engineer.

About October 2002

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in October 2002. They are listed from oldest to newest.

October 2002 is the previous archive.

November 2002 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33