I got to thinking today about how my manager has given me quite a bit of leeway to refactor some code behind an application I need to write.  I strive to show him plenty of progress on the actual application, including screen shots and the like, but at the same time I also work to improve the code internals.  I think he knows I enjoy it, and that it actually promotes my overall productivity in the long run.

I think what my manager is applying is a variation on Google's "20 percent time policy", and a clever one at that.  Rather than spending 20 percent of the time on my own projects, I get to spend 20 percent of the time, doing things that need doing, but in my own way.  This is a sort of happy medium for companies smaller than Google.  It transfers some control to the employee while still providing tangible value to the company.  If instead I was into documentation, well certainly by allowing me go off on a documenting tangent once in a while, that too would benefit the company.

It would appear my manager is onto something.  Or maybe he's just figured out I'm going to do things my own way anyway so he may as well go with the flow ;)

Javascript programming has finally come to be considered enterprise-ready due to the advent of Ajax.  Sadly though the Oreilly "Ajax Hacks" book threatens to reverse this upsurge in Javascript understanding.  Case in point is "Hack 22. Validate a Text Field or textarea for Blank Fields."  The author naively suggests you check form field values in a boolean context such as "if (this.value) .... "  I'd not encountered this particularly egregious faux pas in a book in a couple of years; such "validation" code is easily circumvented by entering spaces.  You should actually check for any non-whitespace characters with a regular expression such as "if (/\S/.test(this.value)) ...."  Shame on OReilly for letting this get to print and potentially undoing the current Javascript renaissance.

In 2004 I wrote an article on devpapers.com about installing ColdFusion Express on Linux.  I made a point of providing links to where Linux and Windows versions of ColdFusion Express could still be downloaded from the allaire.com domain.  They worked all the while after Macromedia bought Allaire, but now that Adobe has bought Macromedia, those links no longer work.

Alas I don't have a Linux copy, but from my ColdFusion Express book I have the Windows version from the CD rom.  And now I will provide this from my site as long as I don' t hear from any lawyers as to why I can't redistribute free software ;)

Download ColdFusion Express for Windows

Last year I published one entry regarding "BEA Workshop Annoyances".  I've moved on to other projects as of three months ago, but I was reminded of another Workshop annoyance I encountered, by a Bruce Eckel's article posted on reddit, which the author began with some observations about the DRY principle, the one that says "Don't Repeat Yourself".

In a nutshell, I had devised a system whereby I populated an array with values from the database, and this array was used both to populate a drop down menu, and to validate the value provided for the same field.  This was necessary because of an extraordinary use case, where the data entry form could be populated from an uploaded Excel spreadsheet, in which case it was entirely possible that the uploaded data might not match the choices from the pulldown menu.

In which case the validation message printed properly, that "blahblah" wasn't a valid value, but the framework also performed some highly undesirable magic under the hood.  It added the invalid value to the array of possible values and displayed it in the drop down menu.

So I would like to thank Workshop/Beehive/NetUI for making me look like an idiot in front of the project manager after I'd been proudly pontificating about the DRY principle.  No wonder, as Bruce Eckels put it, the principle is practically ignored: when it should work some corporate mandated framework steps in to make sure it won't.

Actually there was a workaround, I don't remember it precisely, but it was some sort of horrible hack that had to be implemented on the client side, involving looping over the array either through JSP scriptlet or Javascript code, and removing the unwanted element.  The shame of it is, that otherwise Workshop did some wonderful things.  Through its use of "annotations" (this was pre Java 1.5 so they were not annotations in that sense), I never had to touch a struts xml configuration file.  I even had a subsequent phone interview with a leading Struts author, and he wanted to pick MY brain about this.

If only the developers of this, and other frameworks (Ruby on Rails included from what I hear), could consistently do just enough for the developer, and then get out of the way, instead of performing some magic they think makes sense.  Whereas I was attempting to adhere to DRY, these framework developers need to adhere to the principles of test driven development.  Surely the developers of Workshop/Beehive/NetUI did not create a test that added the unwanted element to the source array of elements for the UI widget, and then conclude that the test passed.

Just my $0.03.  Inflation.

Forgive me for rehashing such a hackneyed idiom, but I can explain why Python makes sense for web development in one statement:

data = {"foo": "bar"}

Executing the above in Python, followed by: print(data["foo"])
results in the output:  "bar"

This would be mind numbingly straightforward except for the following exercise, which should be able to be completed by even more readers than the above, because they don't have to have Python installed.

Copy the statement: data = {"foo": "bar"}

In between script tags within the head tags of an HTML document, then set the onload attribute of the body tag to: alert(data["foo"])

This too results in the output: "bar"

Furthermore, not only do Javascript and Python share the same general syntax for defining the above literal representation of an associative array -- Javascript "objects" and Python "dictionaries", but they also share the same syntax for defining literal ordinal arrays:

arr = ["foo", "bar"]

Now, in either language, accessing: arr[0]
results in: "foo"

It gets better.  These structures can be arbitrarily nested within one another.  JSON, or "Javascript Object Notation", starts with an associative array as its outermost structure, but there's no reason to not start with an ordinal array:

superbowls = [{}, {"winner": "Green Bay", "loser": "Kansas City", "score": "35-10"}]

After defining the above in either language, the statement: superbowls[1]['winner']
results in the same output in both: "Green Bay"

Javascript and Python do not necessarily allow all types of data to represented identically, so in order to take advantage of their commonalities subsets of each would be required.  As a for instance, in Javascript booleans can be represented by the barewords true and false, whereas in Python the same values would be represented by the capitalized versions True and False.  Both languages however evaluate 0 as false and non-zero integers as true, so this case is easy enough to work around.  It won't always be so easy, but still it seems promising and worthwhile.  One carefully constructed Javascript/Python data structure could be used to configure both client side and server side functionality, debunking the myth that the two tiers must be engineered in two entirely different manners, thereby doubling development costs, etcetera.

On this 300th anniversary of Benjamin Franklin's birth, it strikes me.  Watching a tv program about him on the History Channel, it was noted that Franklin did not patent, and therefore did not profit from, a couple of his most prominent inventions, the "Franklin" stove and the lightning rod.

Wouldn't this make Ben Franklin the father of open source, albeit hardware?

From Joel Spolsky's forward to a new book regarding software startups aka "MicroISV"s, his first and presumably most important piece of advice is: "Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain."  On the very same web page however -- on all the web pages on joelonsoftware.com in fact -- there is a pane in the left hand column the first link of which is "more about (Joel)".  Following that link leads to a paragraph with the heading "Fog Creek Software" (Mr Spolsky's own software startup) in which he recounts:  "We didn't start with a particular product in mind...."

There's no mention of this in the foreword.  Too bad, because an explanation of this seeming change of heart is probably what could have made this piece meaningful, instead of a misplaced plug for CommonLisp.  Indeed, these inconsistencies and irrelevancies smack of nothing more than jumping on the Paul Graham bandwagon.

So which is it Mr Spolsky?  Do as you say?  Or do as you do?

Javascript's "prototype" driven nature allows programmers to alter the behavior of built-in types thusly:

String.prototype.isEmpty = function() { return /^\s+$/.test(this); }

Just because you can, doesn't mean you should though.  For instance, a method you add to String's prototype might require two arguments, but a future update to the language itself might add the very same method with the arguments reversed.

Consider this alternative:

function FormValue(str) { this.str = str}
FormValue.prototype.isEmpty = function() { return /^\s+$/.test(this.str); }
var test = new FormValue(" ");

Note you must explicity instantiate a FormValue instance, rather than implicitly operating on a String (primitive).  Consider this a feature.  For instance, Python has popularized the acronym EIBTI, or "explicit is better than implicit."  No wonder MochiKit, "a production-quality framework that brings powerful and well-known Python idioms to JavaScript," rightfully leaves String.prototype alone.

First let me say before you flame me or give me "bad karma" on reddit.com, that I support Paul Graham's "Summer Founders" program.  I like to think that I'm not just bandying the verb "support" when I write this, but that I actually tangibly support the program.  After all, I'm a reddit reader ;)  Furthermore, I've promoted kiko on this site.

But I really have to question whether, as he claims, Mr Graham has tangibly (there's that word again) tested his hypothesis about which he most recently has written in his essay "What I Did This Summer" at http://www.paulgraham.com/sfp.html, which, by the way, I discovered through reddit.  That hypothesis being, and I quote "that success in a startup depends mainly on how smart and energetic you are, and much less on how old you are or how much business experience you have."

Mr Graham immediately goes on to state that "the results so far bear this out. The 2005 summer founders ranged in age from 18 to 28 (average 23), and there is no correlation between their ages and how well they're doing."  Well I'm glad he said "so far" because, even with my rudimentary statistics knowledge, I know that his sample "so far" has been nowhere near large and varied enough to really test his hypothesis.

Now there is going to be the "Winters Founders" program and so the sample size will increase.  But personally I have doubts as to whether it will become more varied.  From everything Mr Graham has written so far, his programs definitely seem slanted towards attracting young talent.  That of course is his prerogative, and presents a great opportunity for these youngsters, which I gather is the real point, as opposed to proving some theory.  Get some subjects in their 30's and 40's into the sample, and I'll take his hypothesis more seriously.

No HotScripts newsletter column is due from me this month as they got a month behind with sending them out.  Therefore I've decided to try something different.  For October I plan to provide a journal of my "enterprise" Java development experiences.  I got this idea over the weekend, and something I've run into just now has inspired me to create my first such entry.

From the title you see that I'm using BEA Workshop; this is not by choice.  I began by using Spring for the first month and a half on this project, but then per corporate edict got forced into using Workshop a couple of months ago.  It's not ALL bad, but....

This morning I'm creating a new Workshop "control".  I've created several of these over the past couple of months while I learned Workshop.  For all intents and purposes they are ordinary Java code, but the file extension is something different, ".jcs" for my particular instance this morning.  My high level understanding of what happens to this code, is that when you "build" your application, Workshop creates proxies based on these controls with non-standard extensions.

In the past this had constrained me from performing tasks in certain ways.  For instance, I tried to create a general purpose form validator using Reflection.  However, this seems to have created a conflict, I'm guessing because Java proxies are themselves reflection-based.

This morning however I'm not trying to do anything as advanced as Reflection.  I'm just trying to overload a method.  This is for a use case where data can either be uploaded, or it can be keyed directly into a form.  In the end I want to represent this data the same way, for both validation and manipulation ("CRUD": create, read, update, delete) purposes.  In the "keyin" use case I want to pass the data directly from the form, but in the "upload" use case I want to pass in a two-dimensional string array return by parsing the uploaded CSV file.

So I simply want to overload the same method, to take keyed-in data as it's input in one case, and uploaded CSV data in the other.  But this is the error I get from Workshop:

"Weblogic Workshop does not permit overloaded methods in Workshop classes"

This sort of thing is the reason why, two months after switching to Workshop from Spring, I'm barely further along then I was at the outset.  Under Workshop I'm continually having to come up with workarounds because of constraints it places on developers.  Maybe I'll touch on some more of these constraints later this month (or even just later this week), but for now it's back to work.  I just had to blow off some steam though, its just ridiculous to me that BEA has chosen to disabled such a basic object oriented feature as method overloading.

The August 2005 issue of a prominent ColdFusion magazine wastes several pages on OO with ColdFusion.  Let's face it, CFC's are about as object oriented as PHP4: neither are enterprise-ready.  For one, they both lack the "Interface" construct, an absolute must for genuinely robust object oriented architectures.  There are other shortcomings as well, but interfaces provide an acid test as to developers' understanding of objects: if you don't grok interfaces, you shouldn't be leading an enterprise OO project.  All is not lost for ColdFusion however, it's advantage over PHP4 being it's foundation: Java.  Let Java do the OO "heavy lifting", and then leverage the servlet API's getServletContext().getRequestDispatcher() functionality to subsequently forward both request and response to ColdFusion templates.  OO with ColdFusion itself is not necessary to its continued thriving, rather it can provide the view component of MVC under Java.

Several technologies integral to the explosion that is "the web" are ten years old as of 2005, including ColdFusion, Java & PHP.  But let's not forget Javascript -- or, on second thought, let's.  Because Javascript came into being to enable client side form validation, and after ten years we are hardly closer to doing this correctly than in 1995.  AJAX is not the answer -- other than for simple logins where interaction with server side data is necessary anyway -- because AJAX introduces potential network latency and thereby defeats the original purpose.  JSON, being parsable on both the client and server, gets us partway, but not all the way there, as regular expressions, which are vital to form validation, are prohibited.  And that's too bad for JSON, because with vision beyond being yet another data exchange format, it could rival AJAX for buzz and utility.

How to start developing servlets under ColdFusionMX7 (in 150 words or less ;)

Plain JSPs, with business, data access, and view logic rolled into one, should never be used for anything but the quickest and dirtiest prototype.  Period.

JSON's unfortunate reliance on Javascript's eval() method calls for a new standard: JSON++