Presenting at TheServerSide Symposium

I've been invited to present at TheServerSide Symposium this May in Las Vegas, NV. Of course, I'll be accepting. They're looking for two sessions from me (probably an intro to Tapestry and an intro to HiveMind) and possibly a third "real world example" session (perhaps "why writing a book will take 200% longer than you expect").

It would have been nice to run it in Boston again ... well, convienient for me, anyway. Vegas is nice but strange ... I was just there in November for ApacheCon and will be there again in October for my friend Scott's 40th birthday extravaganza. And I don't gamble.

My meeting with Harish

It's kind of like Pokemon ... I'm slowly managing to meet, in person, all the members of the Tapestry team. Last night I met up with Harish Krishnaswamy, one of the more recent members added to the team. We chatted about Tapestry and HiveMind for two hours at a bar in Waltham. Short hours for me, long hours for my wife, Suzanne.

Harish is a decent, quick witted, friendly guy. He literally came out of nowhere a bit over a year ago, and was suddenly answering newbie questions and providing patches, which is the growth path to becoming a team member. He works for a biotech company in Connecticut and leads a small team using Tapestry (and HiveMind, when it is available again).

When you are immersed in open-source, you kind of get used to working with "people" that are no more than a stream of e-mailed characters. I think the magical thing about open source (and something perhaps more obvious to an outsider) is just how egalitarian it is ... meritocracy rules (in terms of coding ability, communication ability, and professionalism) but all other barriers (such as physical location, age, sex, race, religon, and so forth) are beyond irrelivant, they are invisible. Mind Bridge takes this to an extreme, working behind a pseudodym to protect his identity (he wrote the introduction to the book, so his secret will be out shortly).

A recent article (which I wish I had bookmarked) drew some parallels between open-source development and scientific research. As with open-source, publishing research papers has no direct financial benefit to the author (though, of course, everyone in that realm is seeking tenure). In science, and in open-source, the coin of the realm is appreciation from your peers. I find open-source to be even more, well open, than science research because the barriers to entry are phenominally low.

More marketing ...

I've set up a resume web site for myself, HowardLewisShip.com. I'm actually pretty proud of it ... it may only be a single page, but I designed it myself. It has complex layout and NO TABLES, just smart positioning using CSS.

Anyway, before I start using this more widely (I may buy some Google ad words to point to it), I'd appreciate any feedback!

Update: had to scrap the "no tables" layout because I couldn't get it to render properly except in IE. There's some big differences in nested <div> layout between IE and Mozilla and I think IE is doing it right.

More on Tapestry and JSF ... and greater issues, such as the JCP and the future of Sun and Java

Andrew Oliver has latched onto the discussion of Tapestry and JSF and come in with more well informed opinions. He has identified one of the key goals of Tapestry: simplicity and compared it against the complexity of JSF. Much as we developers often pay for location agnosticism (when using EJBs) or language agosticism (when using XML-based web services rather than RMI), JSF is making us pay for framework agnosticism.

Tapestry is simple because it is focused. It does HTML apps (yes, it has support for XML, WML, FooML, or whatever, but the deepest groove runs through the HTML code). It creates the minimum abstraction away from HTML and HTML markup. It automates that mechanical aspects of developing a web application, particularily server-side state management. It starts you at the place where, if you started from scratch, you would eventually reach (through much pain, effort and trial and error). And it's always meant to be useable with no special tools (or, off-the-shelf tools, such as standard WYSIWYG HTML editors).

JSF pretty much begs for tool support. Although Kitto Man claims that tools are not so necessary, the development story from Sun and the JCP is that we'll have Microsoft-style tools that write our code for us, based on what we drag and drop.

Additionally, Andrew has recast the Tapestry vs. JSF discussion into the larger context of imposed standards versus simple, effective solutions. JSF is a big, proprietary, complex specification that arose out of private discussions by a "group of experts". As with EJBs (especially entity EJBs), the Java community is expected to accept JSF as the single, definitive approach based on an unearned level of trust. Can we wait another 3 - 5 years for Sun and the JCP to straighten out this mess? We don't know how JSF was designed, how decisions were made, what deals were cut or who the whole thing is supposed to serve. This kind of secrecy of course leads to paranoid theories ("JSF exists to support tool vendors"). Personally, I think the JCP and the JSF is Sun's best attempt to do things properly ... but I think they are quite misguided.

My own personal level of irritation with this endless raft of imposed specifications from Sun and the JCP is running out. JCP specifications are anonymous, a team of experts throws a specification over the wall and loudly proclaims: this is how you will now work. Tapestry and other major open source projects are personal --- they are backed by known individuals whose reputations are on the line in terms of the code they provide, but also in all the ancilliary aspects such as documentation, online support, and speaking engagements.

Futher, if the name of the game is beat Microsoft then Sun's strategy is way off. From my point of view, Sun hopes to win the war by providing the better technology and more options. Unfortunately, you can't win that war without winning the tools battle. The JCP doesn't provide tools, it attempts to create a market where others create the tools. But the tools are proprietary, and the properitary JSF tools (vaporware, but likely coming) will lock users into proprietary implementations of JSF. BEA may allow drag-and-drop development of JSF apps inside BEA Workshop, but those dragged-and-dropped components are going to be proprietary to BEA so what have you gained vs. using Microsoft's cohesive, integrated, properitary approach? Nothing I can see.

So what is Sun supposed to do? I don't think the JCP can continue to exist as both an incubator and a standards body: choose one --- standards body. Allow the industry and/or open source movement to come forward to provide completed specifications for new technologies, based on existing art. Allow submitting groups to form their own process prior to submission. Set the guidelines for accepting specifications based on public review, and a transparent process leading up to the submission of the specification.

But I don't have a good solution for Sun itself. They need a more compelling hardware story if they aren't going to be consumed by vast clusters of linux boxes (if Google can run on cheap hardware, anyone can!). They've never made money on software, and only lost money on Java. Meanwhile, IBM has been coming around and embracing Linux, Java and open-source. If IBM can do for Java in general what they've done for IDEs (with Eclipse, as an independent open-source software project) then more power to them .. IBM should buy Java, or buy Sun itself to get it.

Work on the book is winding down

Wow ... writing a book is a lot of work. When I finished at NLG, I thought another two weeks would be all it would take. It's been over a month. Mixed into that month has been a lot of fun, and a lot of deferred house stuff ... plus some quality time playing Splinter Cell) -- but even so, it has again been much more work than I could have guessed!

I'm now at a point where the remaining work is responding to copy edits and the like. The Beast (how I think of the book now) is dieing by inches. Ok, so the book is going to be about six months late (I originally expected it to be out around September 2003). I'm pretty darn sure the book will be in stores in March (I believe Manning has some kind of pre-order from Barnes and Noble, which has turned the pressure up). I can finally begin to shift gears to other things (like a quick ski trip) ... not to mention, finding a way to actually make some income.

The other Tapestries

Tapestry is just too cool a name (confirmed by Gavin King), so there's many unrelated projects named Tapestry ... but this Tapestry is extra-special cool.

Kito Mann Interview about JSF

TheServerSide has just published an interview with Kito Mann, author of JavaServer Faces in Action. Of course, I'm not a fan of JSF -- my limited research shows that it does too little and requires too much code, but I suggest you read the article yourself. It's gratifying to me to see how, over the last two years, Tapestry has migrated to the front of any discussion concerning web application development.

I think one of the key words that comes up in the interview with respect to Tapestry is mature (and stable). Tapestry has grown into its current state in fits and starts ... a significant core has not changed radically in the last four years (Tapestry started in January 2000), but quite a bit of Tapestry today has come about in response to actual user's needs and requests. In fact, starting with a small, smart, involved user base meant that Tapestry could make some significant (and non-backward's compatible) changes early in its life.

I think some of the JSF challenges Mr. Mann mentions, particularily proper JavaScript support, are more complicated than he realizes. Lack of compatibility with JSPs, not to mention occasional non-backwards compatibility, has given Tapestry the freedom to find the right solution to a number of problems. Nowadays, backwards compatibility is much more important than it was three years ago, but the process of seeking out better and better solutions should continue indefinately.

Andrew C. Oliver's Parting Words

Andrew C. Oliver was invaluable in helping Tapestry form into a true community and helping us navigate through the Apache bureaucracy and become a Jakarta project. He sent one final message before unsubscribing from the Tapestry Developer mailing list:

Tapestry is now a thriving community and my preferred way to develop webapps. Howard is now a member of the ASF and of the Jakarta PMC. I'd encourage Tapestry to seek top level project status in the near future. That being said, I prefer to avoid writing web apps. My roll here has spanned a year and I have been watching this project quietly in the background. Should y'all ever need my help you need but ask, but I have every confidence that you will continue to succeed. Thanks for bringing the best damn webapp development framework ever to Apache and sharing it with open source.

(My bold) I So there you have it -- a guy who avoids writing web applications likes Tapestry. I guess that's good :-) Also, I know I'm an ASF member but I can't track down whether I'm actually, legitimately on the Jakarta PMC. Though if Tapestry does become a top-level project, that will no longer matter.

People are continually impressed that on the Tapestry mailing lists, people ask questions and they get answers. Not every question gets answered (the question must be understandable and either easy or interesting), and a lot of the time, the response is quick (a link to online documentation perhaps). Still, there are repeated comments about the very, very high signal-to-noise ratio on the Tapestry lists. Makes me proud.

Mr. Tapestry ... meet Mr. Forrest

Thanks to Tetsuya Kitahata (and a full day of work on my part), Tapestry's web site now builds using Forrest. This is a big step up from the old L&F, which was a pain to maintain and ugly and inconsistent to boot. There's still some rough edges to work out, and there's an awfully large number of moving parts inside Forrest (but nothing is quite as bad as Maven).

At this time, the component reference is still raw, ugly HTML. It has to be, because it has in-place examples that require full HTML ... not the tiny slice that Forrest's xdoc format transforms into. Perhaps we'll need to create an extended xdoc for Tapestry with extra elements (to create iframes and load example HTML from them perhaps?). Sometimes I get ideas while I type ...

In addition, we could concievable convert the users guide and the future tutorial to use the book format supported by Forrest. It looks like their own take on DocBook ... but the important thing is figuring out how to get Forrest to generate single-page HTML, chunked HTML or PDF from the same source the way DocBook does.