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.

Presenting ... my card

In case anyone whose reading this blog isn't aware, I left the safe confines of my ordinary, salaried job for the unpredictable consulting space. I haven't had much of a chance to market myself, but I have made up some business cards: I've blurred out my home address (just out of fear of identity theft).

So, consider this the first salvo in marketing Howard Lewis Ship; more is coming, building on some   good   notices. You want to build good Tapestry applications ... and I want to help.

Spindle / Tapestry Sweatshirt

Geoff may be a Real Smart Guy for creating Spindle, but he's a Total Genius for creating the Spindle Sweatshirt!

Freedom!

I'm done at NLG ... at least until 2004. I have no day job to go to! I can finish the revisions and copy editting of the book. I can go skiing. I can sleep in. I can visit friends. I can see Return of the King. I can write the rest of the Tapestry reference docs. I can update the unit test suite. I can push Tapestry to 3.0 final. I am free --- from everything, but my inner taskmaster. I can live with that. Freedom!

Large scale Tapestry approaches

In a previous post I mentioned some ideas that came out of my talks with the folks at Intelligent Works.

Their problem, which is not too uncommon, is that they are adding additional lines of business to their existing app. They already have about 100 pages, most of which are CRUD (Create Read Update Delete) for their existing object model.

Now they are adding new lines of business that extend their object model with new subclasses. In many cases, the high level looks very similar, and they are only seeing differences fairly low in the navigation tree. That is, a Work Order looks much like a Purchase Order (with a couple of fields swapped out), and the real differences don't crop up until you drill down to the line item level or below.

So, I came up with some solutions off the top of my head ...

Smart Components

Use the same pages, but have smart components that are responsible for editting the details of the object. These smart components, built around Block and RenderBlock, can mix-and-match a user interface on the fly, drawing appropiate components from Blocks on secondary pages.

This kind of approach means that WYSIWYG preview goes out the window, the page becomes a kind of shell whose job is to just set the stage: what object is being editted and how. At multiple layers below, the smart components are complex conditionals to provide the right UI for the particular type of object being editted.

For IW, there might be an EditAnyOrder page used for editting both Work Orders and Purchase Orders. Again, within this single page, and even within components within other components within the page, there will be dynamic logic to choose the right UI (both static and components).

This is a very powerful approach that leverages the dynamic nature of Tapestry. I'm concerned, however, that finding and fixing bugs will be too complex ... that there will be too much detective work to find where a particular text field comes from ... and too many unwanted side-effects of changes because components and code are being shared in an obscure way.

Dynamic Page Assembly

Tapestry has a bunch of hooks that allow a careful developer to extend or even replace the way Tapestry locates page and components specifications and templates. In theory (and I haven't tried this yet), you could magically "brew up" an EditPurchaseOrder page on the fly. The framework would not care that the specifications and even templates were constructed on the fly, rather than read from static files.

There could be a bit of magic involved in this ... parsing the page name ("EditPurchaseOrder") to figure out how to create the necessary page (some kind of template for "Edit", plus the PurchaseOrder type, plus specific extensions for editting Purchase Orders). What this kind of mapping would look like is more than I can come up with on my feet.

Template Driven Development

The question is: do you need to really assemble it all on the fly? If you know you are going to need an Edit page for Work Orders and Purchase Orders, can you use a templating system to do it. I've been using XDoclet at work lately, and it seems reasonable to use XDoclet to create page and component specifications from Java classes ... if you can figure out XDoclet and come up with the necessary rules, you could have a single Java class (public abstract class EditAnyOrder ....) and from that, generate more Java classes and page specifications (EditWorkOrder, EditPurchaseOrder).

Perhaps Velocity, in the guise of VPP (Velocity Pre-Processor) is more appropriate for generating page and component templates.

I tend to like this solution, because it moves the difficult decision making into the build phase. There are still lots of unknowns.

Other ideas

Long time Tapestry user Jiri Lundak has built a framework on top of Tapestry to address these issues: MetaworkX. I haven't looked at the code or design (yet -- so much to do!) but he's been at this for a while and probably has something clever up his sleeve.

My visit to Intelligent Works

Over the weekend, I visited snowy Ottawa, Canada to meet with Geoff Longman (creator of Spindle).

This wasn't a social trip (though it could have been as Geoff is a cool guy) ... it was a chance to meet with another team of people who are aggresively using Tapestry, and who may be needing Tapestry training in the future (or, potentially, involved in training yet more folks). There's a lot of opportunities brewing north of the border for Tapestry, for myself, and for Intelligent Works, Geoff's company.

There were several people in attendance, here's a writeup from Chris about my talk:

From: Geoff Longman <glongman <at> intelligentworks.com>
Subject: Fw: Howard's talk...
Newsgroups: gmane.comp.java.tapestry.user
Date: Tue, 16 Dec 2003 11:36:12 +0000


We were lucky enough to have Howard pop up to visit Intelligent Works here
in Ottawa last weekend and give us a very informative (~4 hour) session
focused on Tapestry and Hivemind.

I asked Chris Justus, a consultant working with Tapestry here, to jot down
his thoughts..

Geoff

Geoffrey Longman
Intelligent Works Inc.

P.S. I agree totally, bit I must add that the Hivemind portion of the
session was equally as informative!

----- Original Message -----
From: "Chris Justus" <cjustus <at> alceatech.com>
To: <glongman <at> intelligentworks.com>
Sent: Tuesday, December 16, 2003 11:26 AM
Subject: Howard's talk...

> I've been working with Tapestry for 6 months, and we have been building
> an application that currently consists of about 100 tapestry pages and 50
tapestry
> components... Howard's talk was good in terms of explaining some ideas
> and concepts behind Tapestry.  Having worked with other frameworks in
> the past, I consider the idea of using the jwcid attribute a real
> solution to a very real problem of having designers and developers work
> together on an application...
>
> In addition: We are also now at the cusp of some major work in which I
> was considering using a body of 30 pages, 30 templates, and 30 class
> files as a base for 2 other areas of the application - this would result
> in the creation of 200 additional files within the project.  I spent 3
> minutes explaining our application to Howard, the internal object model,
> and the layout of our tapestry pages... In just a minute or two, Howard
> had suggested several alternatives to the plan that was going to be
> implemented, which will save us tens of hours up front, and likely
> hundreds of hours in maintenance down the road... This provides a very
> quantifiable savings on the order of tens of thousands of dollars in
> development and maintenance.
>
> Overall Howard's visit was very beneficial... Anyone doing serious
> Tapestry work would be wise to meet with Howard and get feedback on how
> they are implementing various aspects of their application...
>
> Chris
>

As usual, I enjoy talking about Tapestry (and HiveMind), especially to an audience that really gets it. I also enjoy hearing about user's business models and making suggestions about how to best use Tapestry. In fact, thinking on my feet there, I came up with some very nifty approaches that I'll summarize soon.

Tapestry in Action -- First MEAP chapter available

Tapestry in Action's first chapter is available via MEAP (for-pay early access in PDF format).

Love to see that support!

In the way that all discussions on TheServerSide tend, a book review of The Art of Java Web Development has drifted into a chest-thumping "my framework is better than your framework" slog-fest. A couple of years back, I was accused of doing this kind of thing, so now I'm extra careful to hang back and let others fight my battles for me :-) ... or, at least, let others bring up Tapestry first.

Jason Cox, a familiar name on the Tapestry mailing lists, has offered a particularily nice description of the advantages of Tapestry, joining some similar notes by Erik Hatcher and MindBridge. Always nice to see new evangalists come on board!

The Art of Java Web Development

New on TheServerSide is a review of The Art of Java Web Development by Neil Ford.

This book covers a number of important open-source frameworks, including Struts, WebWork (1.0) and Tapestry (2.2).

I reviewed the Tapestry chapters over the summer; I was dissapointed that he used such an old release of Tapestry though it probably wasn't reasonable for him to write a book about 3.0 while it is still changing.

I think he hit the major points, but sometimes the focus was off; his examples spent too much code fretting about setting up Log4J (that's what log4.properties is for) which undermines the "hey, where did my code go?" aspect of Tapestry development. If I remember correctly, there was also too much duplicated code concerning database connection pools in the example page classes (that could easily have been moved to the engine or visit -- or in 3.0, to the global object).

I'll need to get a copy of this book to see what's changed since I reviewed it. I'm also hoping he followed my suggestion to reference the substantial improvements in Tapestry 3.0 over Tapestry 2.2.

Still, it's nice that Tapestry is treated to the same level of coverage as Struts, WebWork, Velocity and so forth. And it's great to see anything Tapestry in print.

NHL.com - Powered by Sun, Tapestry and Cayenne

The NHL.com - The National Hockey League Web Site is powered by Tapestry (version 2.3) plus Cayenne. It receives more than 5 million hits a day and uses a mixture of live Tapestry and pre-rendered pages (Perl scripts "scrape" Tapestry generated pages at scheduled intervals). Hats off to Eric Schneider at Central Park Software (hey look -- their home page is a Tapestry app, too).

Resting on my laurels (more from my visit to Darden)

Jamie Orchard-Hays was another person attending my two-day fun-filled Tapestry training session at Darden, and had more favorable comments to go along with Erik Hatcher's.

The name: Tapestry

Some amusing thoughts by Gavin King about how to name software projects (and about my sense of theater).