Formos is partnering with
SkillsMatter to provide open enrollment Tapestry training. The training will take place at the SkillsMatter offices in downtown London.
This is the same course materials that I use for my on-site Tapestry training ... and I'll be debuting a new lab on Ajax techniques.
I'll be talking about Clojure and Cappuccino at NoFluffJustStuff Pacific Northwest Software Symposium, which runs from Sept. 18th to the 20th in Redmond, WA.
I seem to have the 'C's covered, but how about the 'T's? If you are attending NFJS or you absolutely, positively, 100% would attend if I was speaking on Tapestry there ... provide some feedback to Jay!
I've just uploaded my slide deck from JavaOne this year:
As usual, embedded animations and screencasts don't work, but there's a lot of value here regardless.
This presentation was a slightly extended version of the Webinar.
Here's the slides for my Clojure talk at Open Source Bridge:
The upload to SlideShare was confused by parts of the slide deck, but you can follow the gist of it.
Presenting Clojure in 45 minutes is a challenge, and I'll need to be even briefer at OSCON next month.
I recently had an e-mail exchange with a Tapestry user; after congratulating me on creating Tapestry, he went on with the following observation on his organization:
The company I work at unfortunately chose JSF for their big app. The reason was that Tapestry was "brittle" in the sense that, if one developer breaks something, on a page or a service, very often the whole site won't come up because the initial registry startup will fail. Or for example, if page A has a pagelink to page B, and page B is broken, then page A won't render. While I agree that we shouldn't ship unless the whole app is working, this is a thousands of pages big app with hundreds of mediocre (as in likely to break things) developers. They'd rather have 80% of the thing working than nothing at all. I never thought of this for my own projects, and haven't had the time to examine the truth of their claims. What's your take?
I provided the following response:
Early failures are absolutely, 100%, the only path towards code quality. You may have heard the phrase "no broken windows" (see "The Tipping Point" by Malcom Gladwell for more details) but the short form is that when errors go uncorrected (whether they are broken windows in an abandoned building, or broken code in an application) they tend to multiply quite rapidly.
The things that will "break" a link from page A to page B are substantial problems such as invalid templates, references to unknown properties or components, or compile errors in the page B class ... things that no other developer should ever see when page B's developer is working and checking in code. That is, problems that should never be checked into trunk, but instead kept in a local workspace or a private branch.
An organization that thinks that fail early is a problem is an organization that isn't prepared to develop a large application in any technology. The image I'm getting is one where there is no build server, no continuous integration, at best CVS for source code management (or possibly one of those "shared directory" monstrosities) .... i.e., a chaotic environment where errors are allowed to be checked in to the trunk and can go unnoticed for some time.
The solution to coding errors in pages or components is not to wait until your testers (or end users) find the bugs, but to identify and fix the bugs early. That's called "engineering discipline" and the reality is that even self-professed "mediocre" developers can do it. Tapestry helps because it fails early and has great exception reporting to guide you right the problem so that you can fix it.
Another factor here is enforced helplessness. If only Fred understands page B and he's out when it's broken, then all development stops waiting for Fred to get back. I hit this problem myself, years ago working on a large Struts application (those words give me the heebie jeebies now!). We had lots of code, a fragile and slow build process, and many little code "fiefdoms". I spent too much wasted time twiddling my thumbs.
Nobody should "own the code"; if page B is is broken, Julie (who normally develops page A) should be free to fix it. Julie will need to understand the page B code well enough to fix it, but also you need an overall environment with shared source, no repository locks (that is, nothing that says "Only Fred can change this file"), and no management PHB's getting in the way. Pair programming is the best way for Fred and Julie to share knowledge so that they can understand each other's code. Even if pairing occurs only part time, it's very effective at knowledge transfer as well as ordinary coding.
The idea that "mediocre" developers should use JSF as it is more tolerant of errors is absurd! Tapestry 5 is designed to improve productivity for all developers, by streamlining, simplifying, being smart and being concise ... not to mention live class reloading and best-of-breed exception reporting, which makes it fast to identify and fix those errors.
If your doctor tells you to eat less red meat, that doesn't mean you should switch to a diet of fried chicken three meals a day! Likewise, if you have concerns with code quality from your developers, you should not switch to a less agile, more code-intensive, less supportive development model and hope to catch all the bugs in QA. Sweeping problems under the rug is never a winning strategy.
Coming down off my soap box, I should also add that Tapestry 5.1 works a little bit differently than 5.0 in this respect, so it does (in fact) defer more of the page loading and validation until a link is actually clicked. This is more for performance reasons than to shield developers from application problems. Even in 5.0, the loading and validation was the "reach" from page A to pages explicitly referenced (usually via PageLink during the rendering of page A), so it's a highly unlikely case that a single error in a 1000 page application will keep the application from starting up, unless the start page of the application links to all 999 other pages.
Re-reading the above post I can't emphasize enough: you can't ignore quality problems. Quality problems lead to development failures, schedule slips, missing functionality, low morale and high turnover. Saying "we don't have time to fix the quality problem first" is to ignore the second law of Thermodynamics. You are expecting a miracle, literally writing it into your project plan.
Formos addresses this issue two ways: First, we use Scrum and deliver on (typically) 4 week cycles. Thus we set real deadlines and have a constant check on quality (we're providing working code constantly). We don't even try to predict what we'll be doing six months or two years from now, we just deliver a steady, manageable stream of software.
Secondly, Formos uses Tapestry precisely for all the reasons that the anonymous developer's organization rejected it, and for many, many more reasons besides.
Just got back last night from training in Madison WI. This was primarily an intro to Tapestry 5 for Tapestry 4 developers (and a couple of new-to-web-programming developers) and a lot of hands on pair programming to get them going with their conversion work. It was a lot of fun, and as usual, I learned a bit.
I have a couple of weeks respite now before OSCON which will be followed with training in York, UK, then Estonia, then London.
I'm continuing to hold off on code changes to Tapestry 5, though I hit enough minor annoyances that I'm considering a 5.1 bug fix release before starting 5.2 in earnest.
I have a backlog of work related to Tapestry360 and then my main emphasis is going to be Documentation, Screencasts, Articles, Documentation and Documentation, plus some additional Documentation. It may be a while before I start with new features for 5.2.
I'll be speaking about Clojure at Open Source Bridge on June 17th here in Portland.
In addition, I'll be speaking on Clojure at OSCON, on July 23rd. OSCON has left its traditional home, Portland, in favor of San Jose, alas. If you are thinking of attending, use my friends, co-workers and family discount code, os09fos, and save 20%.
This week, I'm in Madison, Wisconsin doing some on-site Tapestry training and mentoring. I've been here before and remember it as a pretty cool little college town. In any case, if you want to get together one night this week and chat Tapestry, Java, Open Source, Clojure or anything like that, drop a line!
This has been making the rounds on YouTube:
As a vendor, I can identify with this ... but I think a lot of clients out there (those not using Formos, for example) are ordering and charged for the Filet and receive the Tacos. Seriously ... multi-year development efforts are a different beast than purchasing a DVD, which is why short iterations and agile development keep everyone's expectations (of both cost and functionality) inline and satisified.