I had a terrific time spreading the word about Clojure tonight, followed by some fun and spirited discussions over dinner. People are intrigued by Clojure, even as they struggled with a strategy for bringing it into their organization.
If you attended, please rate my talk at SpeakerRate!
Quite a few people have commented on Ten Years of Tapestry, many to note some of the many other great projects being built with Tapestry as a foundation.
We keep a list of tutorials and extensions on the Tapestry home page, with many other sites noted on the wiki (here and here).
Meanwhile, a particular comment from Peter Rietzler was so compelling, it deserves to be top level, so here it goes:
Although our web application uses Tapestry we are using all the Tapestry support stuff far beyond the web tier - I thought that it might be interesting to see that the Tapestry framework is pretty useful in other environments too :)
First and most noteworthy Tapestry IOC got our first choice as dependency injection container, both because of its simplicity and the power of contributions and service overrides. We are building a highly modular (and massively unit- and integration- tested) application where Tapestry IOC's concept of modules and contributions has proven a perfect choice for us. I've written a couple of blog entries about this issue about a year ago when we were searching for a light-weight alternative to OSGi: Is OSGi going to become the next EJB ? and How to Design Software for Flexibility, Reusability and Scalability without loosing KISS principles!
We wrote and contributed Tapestry extensions for popular unit testing frameworks: Unitils (included in next release) and the Spock framework.
Additionally we are heavily using Tapestry services (such as pipelines and chains) in our core services.
Even the type coercion infrastructure has proven very useful for us. We developed a quite powerful Groovy DSL for Enterprise Data Mediation which is targeted to non-developers and we use Tapestry type coercion (with some extensions) tightly embedded in our DSL to free our e-business managers from the burden of providing correct types.
Our whole project heavily relies on small contributions of commands that are instantiated in high volumes at runtime and need environmental stuff injected - another point where Tapestry IOC has proven to be very useful.
Cheers and many thanks for your awesome work,
Peter
btw: I've forgot to mention that we presented our module system with Tapestry IOC at the Austrian Enterprise Java User Group meeting along with another talk about Spring DM and OSGi held by Sam Brannen last autumn.
I recently realized that the first prototype of Tapestry was written ten years ago! It all started as a home project in my living room, with the original inspiration coming from some brief exposure to WebObjects.
Even the "new" codebase, Tapestry 5, is well over three years old at this point.
How long can I ride this dragon? Pretty far, I think ... Tapestry keeps getting better, I keep learning new things, and the community keeps growing. I'm also very impressed by the other Tapestry committers, who have really been stepping up to the plate, not just with code, but with infrastructure issues and the backporting of bug fixes.
I think there are a lot of exciting things afoot in the larger Tapestry world right now. Powerful new features are in the 5.2 code base (still in alpha), including enhancements for JSR-303 (bean validation) and a lot of (backwards compatible) changes to the way component classes are enhanced at runtime. I'm also steaming ahead with a number of big improvements to how JavaScript is organized in the rendered page.
Outside of the core project, there's quite a lot going on. Here's a few things that have caught my attention recently:
First off, there's Wooki, a sizable Tapestry application (open source, on GitHub) for collaborative book writing. It's very pretty to look at, and the code looks quite ship-shape (no pun intended). I think Wookie is not only going to prove useful on its own terms, but is also going to serve as a great example code base for Tapestry.
Next up is Tynamo ... think Rails/Grails meets Tapestry. It's an extension to Tapestry that supports even faster RAD development, automatically creating CRUD (Create Read Update Delete) pages for Hibernate entities. These same people have been building REST support for Tapestry as well as conversational state. Lots of good stuff here (though I haven't had a chance to try it out in detail).
I've been busy with my own Tapestry Extensions project at GitHub. I'm in a lucky space ... I'm adding features to Tapestry and TapX to fit my client's needs.
We're also seeing the deployments of some very large Tapestry 5 applications, such as SeeSaw which is the UK's answer to Hulu ... streaming video on demand. This is expected to be one of the highest bandwidth sites in Europe once it leaves beta.
The shame of it is ... I'm just the creator of the framework; I don't know 1% of what's going on with applications developed in Tapestry. If you are working on something cool, please drop me a line!
I'll be presenting Clojure: Towards the Essence of Programming on Monday Feb 8th at 19:00, in Paris. The event will be held at Zenika, SkillsMatter's partner in France. You must register for the talk ahead of time.
I'm really excited about this talk; I've had a chance to "preview" it at CodeMash, and have used the feedback to make it even stronger.
Along with my upcoming Tapestry training at SkillsMatter, there
is now a session w/ Ben Gidley on March 23: In the Brain of Ben Gidley: Tapestry 5 In Action. Ben will be talking about project SeeSaw, a video-on-demand service built on top of Tapestry 5. He'll be going into depth about converting Struts developers to Tapestry 5, dealing with large volumes of users and large numbers of complex pages, and many of the other factors of bringing a premier web application to deployment.
Another great talk about Clojure and functional programming; larger room, more people, great (and difficult) questions. I made James Ward's head hurt.
If you attended, please rate my talk at SpeakerRate.
Just finished my talk on Tapestry at CodeMash ... very fun, very successful, very good questions and we finished (just barely) on time.
Please jump over to SpeakerRate to rate or comment on the talk. Feedback is very welcome!
On the flight out to CodeMash I started working on some refinements to how Tapestry does runtime class transformation. My long term goal is to move away from Javassist and towards something a bit simpler ... like ASM. Why? Javassist does not have a good, responsive, supportive community, and it has been increasingly flaky since JDK 1.6.
Previously, I've blogged about how invaluable Javassist is, and I stand behind that early pronouncement. Tapestry IoC and Tapestry Core both use Javassist extensively to create new classes at runtime, as well as modify classes as they are loaded into memory. However, I've also been finding new ways to apply meta-programming without exposing all the gory details of Javassist. As usual, simplicity follows complexity: I'm finding ways to simplify work I've done the hard way, previously, to make these techniques easier for others to leverage.
That's the pattern I'm trying for: none of the explicit Java psuedo-code used by Javassist, instead, defining ways to add behavior to methods, or individual fields, in terms of simple callback interfaces. For the moment, the under-the-covers wiring is still Javassist (underneath the Tapestry ComponentClassTransformation interface), but eventually all the parts that are truly tied to Javassist (i.e., those parts of the API where a Javassist pseudo-code string are provided) can be phased out, deprecated, and eliminated.
The advantage of this revised approach is that the amount of runtime-generated code decreases and simplifies. Less behavior is created via Javassist pseudo-code, and fewer fields need to be created or injected into the component class. Further, more runtime code will be in standard objects, compiled by the standard Java compiler, and less code will be compiled by Javassist. Intuitively speaking (always dangerous), it makes sense that standard Java code will be optimized better by Hotspot: Reportedly, some aspects of Hotspot are tied to the exact form of bytecode produced by the Sun Java compiler).
I've heard from some specific Tapestry users who are building and deploying very large, very complicated applications, that live class reloading is problematic for them to use: their pages consist of hundreds (possibly thousands) of deeply nested components, and they are seeing 30+ second delays reloading a page after a change. Whenever a component class changes, Tapestry must discard the old ClassLoader, and create a new one, and lazily re-instrument all the component classes; this isn't a big deal with only dozens of pages and components, but I want Tapestry to be effective even for the largest, most complicated web applications. Simplifying and revising Tapestry's approach to bytecode enhancement is just the latest in a series of internal changes targeting improved performance.
Meanwhile. the CodeMash conference goes on around me ... and shortly, back to the waterpark.
There's a late change for my talk at CodeMash 2.0.1.0
: my Clojure talk is now Friday at 1:45 in room D. Aaron's talk on Compojure follows at 3:35 in the same room ... which is good, because I can explain a bit about Clojure and it's syntax and Aaron can follow on with a practical application. It's a good change.
I'll be posting my slides up to Slidehsare after the sessions; check back here for links to that, and to the SpeakerRate site.
So, Clojure 1.1 is now available, with lots of cool new features, including transients, pre & post conditions, futures, promises and a boat load of other stuff. Rich Hickey has put together release notes.
Meanwhile, if you are curious about some of these new features, check out this series of videos by Sean Devlin.
I'll be speaking about Clojure and Tapestry at
CodeMash 2.0.1.0 this year, January 13-15.
