12 October 2005
Paul Graham's Self Fulfilling Prophecy
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.
Posted by htmatters at 1:17 PM | Comments (7)
3 October 2005
BEA Workshop Annoyances
Weblogic Workshop does not permit overloaded methods in Workshop classes
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.
Posted by htmatters at 11:52 AM | Comments (3)