Node and Callbacks

One of the fears people have with Node is the callback model. Node operates as a single thread: you must never do any work, especially any I/O, that blocks, because with only a single thread of execution, any block will block the entire process.

Instead, everything is organized around callbacks: you ask an API to do some work, and it invokes a callback function you provide when the work completes, at some later time. There are some significant tradeoffs here ... on the one hand, the traditional Java Servlet API approach involves multiple threads and mutable state in those threads, and often those threads are in a blocked state while I/O (typically, communicating with a database) is in progress. However, multiple threads and mutable data means locks, deadlocks, and all the other unwanted complexity that comes with it.

By contrast, Node is a single thread, and as long as you play by the rules, all the complexity of dealing with mutable data goes away. You don't, for example, save data to your database, wait for it to complete, then return a status message over the wire: you save data to your database, passing a callback. Some time later, when the data is actually saved, your callback is invoked, and which point you can return your status message. It's certainly a trade-off: some of the local code is more complicated and bit harder to grasp, but the overall architecture can be lightening fast, stable, and scalable ... as long as everyone plays by the rules.

Still the callback approach makes people nervous, because deeply nested callbacks can be hard to follow. I've seen this when teaching Ajax as part of my Tapestry Workshop.

I'm just getting started with Node, but I'm building an application that is very client-centered; the Node server mostly exposes a stateless, restful API. In that model, the Node server doesn't do anything too complicated that requires nested callbacks, and that's nice. You basically figure out a single operation based on the URL and query parameters, execute some logic, and have the callback send a response.

There's still a few places where you might need an extra level of callbacks. For example, I have a (temporary) API for creating a bunch of test data, at the URL /api/create-test-data. I want to create 100 new Quiz objects in the database, then once they are all created, return a list of all the Quiz objects in the database. Here's the code:

It should be pretty easy to pick out the logic for creating test data at the end. This is normal Node JavaScript but if it looks a little odd, it's because it's actually decompiled CoffeeScript. For me, the first rule of coding Node is always code in CoffeeScript! In its original form, the nesting of the callbacks is a bit more palatable:

What you have there is a count, remaining, and a single callback that is invoked for each Quiz object that is saved. When that count hits zero (we only expect each callback to be invoked once), it is safe to query the database and, in the callback from that query, send a final response. Notice the slightly odd structure, where we tend to define the final step (doing the final query and sending the response) first, then layer on top of that the code that does the work of adding Quiz objects, with the callback that figures out when all the objects have been created.

The CoffeeScript makes this a bit easier to follow, but between the ordering of the code, and the three levels of callbacks, it is far from perfect, so I thought I'd come up with a simple solution for managing things more sensibly. Note that I'm 100% certain that this issue has been tackled by any number of developers previously ... I'm using the excuse of getting comfortable with Node and CoffeeScript as an excuse to embrace some Not Invented Here syndrome. Here's my first pass:

The Flow object is a kind of factory for callback wrappers; you pass it a callback and it returns a new callback that you can pass to the other APIs. Once all callbacks that have been added have been invoked, the join callbacks are invoked after each of the other callbacks have been invoked. In other words, the callbacks are invoked in parallel (well, at least, in no particular order), and the join callback is invoked only after all the other callbacks have been invoked.

In practice, this simplifies the code quite a bit:

So instead of quiz.save (err) -> ... it becomes quiz.save flow.add (err) -> ..., or in straight JavaScript: quiz.save(flow.add(function(err) { ... })).

So things are fun; I'm actually enjoying Node and CoffeeScript at least as much as I enjoy Clojure; which is nice because it's been years (if ever) since I've enjoyed the actual coding in Java (though I've liked the results of my coding, of course).

Plastic: Advanced Example

Plastic is Tapestry's built-in Aspect Oriented Programming library, which primarily operates at the byte code level, but shields you from most byte code level thinking: normally, your code is implemented in terms of having method invocations or field reads and writes passed to callback objects that act as delegates or filters.

Sometimes, though, you need to get a little more low-level and generate the implementation of a method more directly. Plastic includes a fluent interface for this as well: InstructionBuilder.

This is an example from Tapestry's Inversion Of Control (IoC) container code; the proxy instance is the what's exposed to other services, and encapsulates two particular concerns: First, the late instantiation of the actual service implementation, and second, the ability to serialize the proxy object (even though the services and other objects are decidedly not serializable).

In terms of serialization, what actually gets serialized is a ServiceProxyToken object; when a ServiceProxyToken is later de-serialized, it can refer back to the equivalent proxy object in the new JVM and IoC Service Registry. The trick is to use the magic writeReplace() method so that when the proxy is serialized, the token is written instead. Here's the code:

To kick things off, we use the PlasticProxyFactory service to create a proxy that implements the service's interface.

The callback passed to createProxy() is passed the PlasticClass object. This is initially an implementation of the service interface where each interface method does nothing.

The basic setup includes making the proxy implement Serializable and creating and injecting values into new fields for the other data that's needed.

Next, a method called delegate() is created; it is responsible for lazily creating the real service when first needed. This is actually encapsulated inside an instance of ObjectCreator; the delegate() method simply invokes the create() method and casts the result to the service interface.

The methods on InstructionBuilder have a very close correspondence to JVM byte codes. So, for example, loading an instance field involves ensuring that the object containing the field is on the stack (via loadThis()), then consuming the this value and replacing it with the instance field value on the stack, which requires knowing the class name, field name, and field type of the field to be loaded. Fortunately, the PlasticField knows all this information, which streamlines the code.

Once the ObjectCreator is on the stack, a method on it can be invoked; at the byte code level, this requires the class name for the class containing the method, the return type of the method, and the name of the method (and, for methods with parameters, the parameter types). The result of that is the service implementation instance, which is cast to the service interface type and returned.

Now that the delegate() method is in place, it's time to make each method invocation on the proxy invoke delegate() and then re-invoke the method on the late-instantiated service implementation. Because this kind of delegation is so common, its supported by the delegateTo() method.

introduceMethod() can access an existing method or create a new one; for the writeReplace() method, the introduceMethod call creates a new, empty method. The call to changeImplementation() is used to replace the default empty method implementation with a new once; again, loading an injected field value, but then simply returning it.

Finally, because I feel strongly about including a useful toString() method in virtually all objects, this is also made easy in Plastic.

Once the class has been defined, it's just a matter of invoking the newInstance() method on the ClassInstantiator object to instantiate a new instance of the proxy class. Behind the scenes, Plastic has created a constructor to set the injected field values, but another of the nice parts of the Plastic API is that you don't have to manage that: ClassInstantiator does the work.

I'm pretty proud of the Plastic APIs in general; I think they strike a good balance between making common operations simple and concise, but still providing you with an escape-valve to more powerful (or more efficient) mechanisms, such as the InstructionBuilder examples above. Of course, the deeply-nested callback approach can be initially daunting, but that's mostly a matter of syntax, which may be addressed in JDK 8 with the addition of proper closures to the Java language.

I strongly feel that Plastic is a general purpose tool, that goes beyond inversion of control and the other manipulations that are specific to Tapestry ... and Plastic was designed specifically to be reused outside of Tapestry. It seems like it could be used for anything from implementing simple languages and DSLs, to providing all kinds of middleware code in new domains ... I have a fuzzy idea involving JMS and JSON with a lot of wiring and dispatch that could be handled using Plastic. I'd love to hear other people's ideas!

Tests: Auto Launch Application, or Expect Running?

Does your test suite launch your application or expect it to be running already? This question came up while working on a client project; I launched the Selenium-based test suite and everything failed ... no requests got processed and I spent some time tracking down why the test suite was failing to launch the application.

I chatted about this with my client ... and found out that the Selenium test suite expects the application to already be running. It starts up Selenium Server, sure, but the application-under-test should already be running.

And suddenly, I realized I had a Big Blind Spot, dating back to when I first started using Selenium. For years, my testing pattern was that the test suite would start up the application, run the Selenium tests, then shut it down ... and this makes perfect sense for testing the Tapestry framework, where the test suite starts and stops a number of different mini-applications (and has to run headless on a continuous integration server).

But an application is different, and there's a lot of advantages to testing against the running application ... including being able to quickly and easily reproduce any failures in the running application. Also, without the time to start and stop the application, the test suite runs a bit faster.

Certainly, the command line build needs to be able to start and stop the application for headless and hands-off testing. However, the test suite as run from inside your IDE ... well, maybe not.

So ... how do you handle this on your projects?

LinkedIn Etiquette

I've used LinkedIn for many years now, long before I joined Facebook ... I liked the concept of never losing contact information with business contacts and technologist. It just seemed like a good idea (though I do sometimes wonder if LinkedIn has any particular purpose).

I tend to only connect with people I've met in person, or at least talked to on the phone.

One thing that drives me crazy about LinkedIn is that when requesting a connection, you aren't forced to customize the greeting message from the default "I'd like to add you to my professional network."

As far as I'm concerned, this default greeting is like no greeting at all, and it's a sign that you are just trolling for contacts. Just like you should always write a cover letter for a resume, you should always customize this greeting message.

Your chances of successfully making a connection go up significantly if you do customize the message ... and with me, if you don't, your chances drop to near zero.

Tapestry Advantages

A summary of a discussion about the advantages of Tapestry over Struts:

• Exceptional exception reporting
• Significantly less code
• Live class reloading
• Sensible defaults, especially for SEO-friendly URLs
• Great community
• Flexibility and customizability

Interestingly, the quality of Tapestry's documentation was mentioned ... favorably! Between the revised home page, and Tapestry JumpStart (and Igor's coming book), I think we're headed in the right direction in terms of documentation going from a liability to an asset.

Tapestry 5.4: Focus on JavaScript

Tapestry 5.3.1 is out in the wild ... and if Tapestry is to stay relevant, Tapestry 5.4 is going to need to be something quite (r)evolutionary.

There was some confusion on the Tapestry developer mailing list in advance of this blog post; I'd alluded that it was coming, and some objected to such pronouncements coming out fully formed, without discussion. In reality, this is just a distillation of ideas, a starting point, and not a complete, finalized solution. If it's more detailed than some discussions of Tapestry's evolution in the past, that just means that the mailing list discussion and eventual implementation will be that much better informed.

In posts and other conversations, I've alluded to my vision for Tapestry 5.4. As always, the point of Tapestry is to allow developers to code less, deliver more, and that has been the focus of Tapestry on the server side: everything drives that point: terseness of code and templates, live class reloading, and excellent feedback are critical factors there. Much of what went into Tapestry 5.3 strengthened those points ... enhancements to Tapestry's meta-programming capabilities, improvements to the IoC container, and reducing Tapestry's memory footprint in a number of ways. I have one client reporting a 30% reduction in memory utilization, and another reporting a 30 - 40% improvement in execution speed.

Interestingly, I think that for Tapestry to truly stay relevant, it needs to shift much, much, more of the emphasis to the client side. For some time, Tapestry has been walking a fine line with regards to the critical question of where does the application execute? Pre-Ajax, that was an easy question: the application runs on the server, with at most minor JavaScript tricks and validations on the client. As the use of Ajax has matured, and customer expectations for application behavior in the browser have expanded, it is no longer acceptable to say that Tapestry is page based, with limited Ajax enhancements. Increasingly, application flow and business logic need to execute in the browser, and the server-side's role is to orchestrate and facilitate the client-side application, as well as to act as a source and sink of data ultimately stored in a database.

As Tapestry's server-side has matured, the client side has not kept sufficient pace. Tapestry does include some excellent features, such as how it allows the server-side to drive client-side JavaScript in a modular and efficient way. However, that is increasingly insufficient ... and the tension caused by give-and-take between client-side and server-side logic has grown with each release.

Nowhere is this more evident than in how Tapestry addresses HTML forms. This has always been a tricky issue in Tapestry, because the dynamic rendering that can occur needs to be matched by dynamic form submission processing. In Tapestry, the approach is to serialize into the form instructions that will be used when the form is submitted (see the store() method of the FormSupport API). These instructions are used during the processing of the form submission request to re-configure the necessary components, and direct them to read their query parameters, perform validations, and push updated values back into server-side objects properties. If you've ever wondered what the t:formdata hidden input field inside every Tapestry forms is about ... well, now you know: it's a serialized stream of Java objects, GZipped and MIME encoded.

However, relative to many other things in Tapestry, this is a bit clumsy and limited. You start to notice this when you see the tepid response to questions on the mailing list such as "how to do cross-field validation?" Doing more complicated things, such as highly dynamic form layouts, or forms with even marginal relationships between fields, can be problematic (though still generally possible) ... but it requires a bit too much internal knowledge of Tapestry, and the in-browser results feel a bit kludgy, a bit clumsy. Tapestry starts to feel like it is getting in the way, and that's never acceptible.

Simply put, Tapestry's abstractions on forms and fields is both leaky and insufficient. Tapestry is trying to do too much, and simply can't keep up with modern, reasonable demands in terms of responsiveness and useability inside the client. We've become used to pages rebuilding and reformatting themselves even while we're typing. For Tapestry to understand how to process the form submission, it needs a model of what the form looks like on the client-side, and it simply doesn't have it. There isn't an effective way to do so without significantly restricting what is possible on the client side, or requiring much more data to be passed in requests, or stored server-side in the session.

The primary issue here is that overall form submission cycle, especially combined with Tapestry's need to serialize commands into the form (as the hidden t:formdata field). Once you add Ajax to this mix, where new fields and rules are created dynamically (on the server side) and installed into the client-side DOM ... well, it gets harder and harder to manage. Add in a few more complications (such as a mix of transient and persistent Hibernate entities, or dynamic creation of sub-entities and relationships) into a form, it can be a brain burner getting Tapestry to do the right thing when the form is submitted: you need to understand exactly how Tapestry processes that t:formdata information, and how to add your own callbacks into the callback stream to accomplish just exactly the right thing at just exactly the right time. Again, this is not the Tapestry way, where things are expected to just work.

Further, there is some doubt about even the desirability of the overall model. In many cases, it makes sense to batch together a series of changes to individual properties ... but in many more, it is just as desirable for individual changes to filter back to the server (and the database) as the user navigates. Form-submit-and-re-render is a green screen style of user interaction. Direct interaction is the expectation now, and that's something Tapestry should embrace.

What's the solution, then? Well, it's still very much a moving target. The goal is to make creating client-side JavaScript libraries easier, to make it easier to integrate with libraries such as jQuery (and its vast library of extensions), make things simpler and more efficient on the client side, and not sacrifice the features that make Tapestry fun and productive in the first place.

Overall Vision

The overall vision breaks down into a number of steps:

• Reduce or remove outside dependencies
• Modularize JavaScript
• Change page initializations to use modules
• Embrace client-side controller logic

Of course, all of these steps depend on the others, so there isn't a good order to discuss them.

Reducing and removing outside dependencies

Tapestry's client-side strength has always been lots of "out of the box" functionality: client-side validation, Zones and other Ajax-oriented behaviors, and a well-integrated system for performing page-level initializations.

However, this strength is also a weakness, since that out of the box behavior is too tightly tied to the Prototype and Scriptaculous libraries ... reasonable choices in 2006, but out-of-step with the industry today. Not just in terms of the momentum behind jQuery, but also in terms of very different approaches, such as Sencha/ExtJS and others.

It was a conscious decision in 2006 to not attempt to create an abstraction layer before I understood all the abstractions. I've had the intermediate time to embrace those abstractions. Now the big problem is momentum and backwards compatibility.

Be removing unnecessary behaviors, such as animations, we can reduce Tapestry's client-side needs. Tapestry needs to be able to attach event handlers to elements. It needs to be able to easily locate elements via unique ids, or via CSS selectors. It needs to be able to run Ajax requests and handle the responses, including dynamic updates to elements.

All of these things are reasonable to abstract, and by making it even easier to execute JavaScript as part of a page render or page update (something already present in Tapestry 5.3), currently built-in features (such as animations) can be delegated to the application, which is likely a better choice in any case.

Modularizing JavaScript

Tapestry has always been careful about avoiding client-side namespace polution. Through release 5.2, most of Tapestry's JavaScript was encapulated in the Tapestry object. In Tapestry 5.3, a second object, T5 was introduced with the intention that it gradually replace the original Tapestry object (but this post represents a change in direction).

However, that's not enough. Too often, users have created in-line JavaScript, or JavaScript libraries that defined "bare" variables and functions (that are ultimately added to the browser's window object). This causes problems, including collisions between components (that provide competing definitions of objects and functions), or behavior that varies depending on whether the JavaScript was added to the page as part of a full-page render, or via an Ajax partial page render.

The right approach is to encourage and embrace some form of JavaScript module architecture, where there are no explicit global variables or functions, and that all JavaScript is evaluated inside a function, allowing for private variables and functions.

Currently, I'm thinking in terms of RequireJS as the way to organize the JavaScript. Tapestry would faciliate organizing its own code into modules, as well as application-specific (or even page-specific) JavaScript modules. This would mean that de-referencing the T5 object would no longer occur (outside of some kind of temporary compatibility mode).

For example, clicking a button inside some container element might, under 5.3, publish an event using Tapestry's client-side publish/subscribe system. In the following example, the click events bubble up from the buttons (with the button CSS class name) to a container element, and are then published under the topic name button-clicked.

Consider this an abbreviated example, as it doesn't explain where the element variable is defined or initialized; the important part is the interaction with Tapestry's client-side library: the reference to the T5.pubsub.publish function.

Under 5.4, using the RequireJS require function, this might be coded instead as:

Here, the t5/pubsub module will be loaded by RequireJS and passed as a parameter into the function, which is automatically executed. So, this supports JavaScript modularization, and leverages RequireJS's ability to load modules on-the-fly, as needed.

Notice the difference between the two examples; in the first example, coding as a module was optional (but recommended), since the necessary publish() function was accessible either way. In the 5.4 example, coding using JavaScript modules is virtually required: the anonymous function passed to require() is effectively a module, but its only through the use of require() (or RequireJS's define()) that the publish() function can be accessed.

This is both the carrot and the stick; the carrot is how easy it is to declare dependencies and have them passed in to your function-as-a-module. The stick is that (eventually) the only way to access those dependencies is by providing a module and declaring dependencies.

Change page initializations to use modules

Tapestry has a reasonably sophisticated system for allowing components to describe their JavaScript requirements as they render, in the form of the JavaScriptSupport environmental (an environmental is a kind of per-thread/per-request service object). Methods on JavaScriptSupport allow a component to request that a JavaScript library be imported in the page (though this is most commonly accomplished using the Import annotation), and to request the initialization functions get executed.

Part of Tapestry's Ajax support is that in an Ajax request, the JavaScriptSupport methods can still be invoked, but a completely different implementation is responsible for integrating those requests into the overall reply (which in an Ajax request is a JSON object, rather than a simple stream of HTML).

Here's an example component from the TapX library:

The @Import annotation directs that a stack (a set of related JavaScript libraries, defined elsewhere) be imported into the page; alternately, the component could import any number of specific JavaScript files, located either in the web application context folder, or on the classpath.

Inside the afterRender() method, the code constructs a JSONObject of data needed on the client side to perform the operation. The call to addInitializerCall references a function by name: this function must be added to the T5.Initializers namespace object. Notice the naming: tapxExpando: a prefix to identify the library, and to prevent collisions with any other application or library that also added its own functions to the T5.initializers object.

The JavaScript library includes the function that will be invoked:

Under 5.4, this would largely be the same except:

• There will be a specific Java package for each library (or the application) to store library modules.
• The JavaScriptSupport environmental will have new methods to reference a function, inside a module, to invoke.
• Stacks will consist not just of individual libraries, but also modules, following the naming and packaging convention.

Embrace client-side controller logic

The changes discussed so far only smooth out a few rough edges; they still position Tapestry code, running on the server, as driving the entire show.

As alluded to earlier; for any sophisticated user interface, the challenge is to coordinate the client-side user interface (in terms of form fields, DOM elements, and query parameters) with the server-side components; this is encoded into the hidden t:formdata field. However, it is my opinion that for any dynamic form, Tapestry is or near the end of the road for this approach.

Instead, it's time to embrace client-logic, written in JavaScript, in the browser. Specifically, break away from HTML forms, and embrace a more dynamic structure, one where "submitting" a form always works through an Ajax update ... and what is sent is not a simple set of query parameters and values, but a JSON representation of what was updated, changed, or created.

My specific vision is to integrate Backbone.js (or something quite similar), to move this logic solidly to the client side. This is a fundamental change: one where the client-side is free to change and reconfigure the UI in any way it likes, and is ultimately responsible for packaging up the completed data and sending it to the server.

When you are used to the BeanEditForm component, this might feel like a step backwards, as you end up responsible for writing a bit more code (in JavaScript) to implement the user interface, input validations, and relationships between fields. However, as fun as BeanEditForm is, the declarative approach to validation on the client and the server has proven to be limited and limiting, especially in the face of cross-field relationships. We could attempt to extend the declarative nature, introducing rules or even scripting languages to establish the relationships ... or we could move in a situation that puts the developer back in the driver's seat.

Further, there are some that will be concerned that this is a violation of the DRY pricipal; however I subscribe to different philosophy that client-side and server-side validation are fundamentally different in any case; this is discussed in an excellent blog post by Ian Bickling.

Certainly there will be components and services to assist with this process, in term of extracting data into JSON format, and converting JSON data into a set of updates to the server-side objects. There's also a number of security concerns that necessitate careful validation of what comes up from the client in the Ajax request. Further, there will be new bundled libraries to make it easier to build these dynamic user interfaces.

Conclusion

In this vision of Tapestry's future, the server-side framework starts to shift from the focus of all behavior to the facilitator: it paints the broad stokes on the server, but the key interactions end up working exclusively on the client.

I'm sure this view will be controversial: after all, on the surface, what the community really wants is just "jQuery instead of Prototype". However, all of the factors described in the above sections are, I feel, critical to keeping Tapestry relevant by embracing the client-side in the way that the client-side demands.

I think this change in focus is a big deal; I think it is also necessary for Tapestry to stay relevant in the medium to long term. I've heard from many individual developers (not necessarily Tapestry users) that what they really want is "just jQuery and a restful API"; I think Tapestry can be that restful API, but by leveraging many of Tapestry's other strengths, it can be a lot more. Building something right on the metal feels empowering ... until you hit all the infrastructure that Tapestry provides, including best-of-class exception reporting, on-the-fly JavaScript aggregation and minimization, and (of course) live class reloading during development. java

I'm eager to bring Tapestry to the forfront of web application development ... and to deliver it fast! Monitor the Tapestry developer mailing list to see how this all plays out.

Review: Gradle Class with Luke Daley

Last week, Luke Daly arrived in Portland to teach a three day Gradle class; the folks at Gradleware were nice enough let me audit the class (so it only cost me a couple of thousand dollars of lost billing revenue to attend). My goals for the class was to gain a deeper understanding of how Gradle works, so that I could write more efficient builds, diagnose problems, and write my own plugins. The class scored very high on all of those counts!

Much of the first day was spent on basics, including a very useful introduction to the Groovy programming language (which is the basis of the Gradle DSL). Even though I have used Groovy pretty extensively for testing purposes over the last couple of years, there were features I've glossed over in the past that turned out to be very useful.

The class is taught largely bottom up: from the basics of declaring tasks, then actions on tasks, and gradually working up towards defining tasks inputs and outputs. Compiling Java came pretty late, which seems curious since that's the primary job of Gradle, but this makes sense from a bottom-up approach as SourceSets can then be described correctly.

The class alternates between lecture and discussion, and short focused labs. At the end of the third day, we worked on tuning up our own builds, passing the video projector cable around ... we had a good time making the Tapestry build more efficient and readable, as well as adding new features to it.

I'm feeling very good about my Gradle skills after attending the course; I've already been able to make further improvements to the Tapestry build subsequently, and I have plans for more involving things going forward.

The return on investment for this class is a bit tricky; Gradle simply does so much straight out of the box, and even without a strong understanding of its structure, you can kind of get it to do what you want just by guesswork and Googling. If you've been using Gradle for a while, I give this a cautious recommendation: getting back the three days of invested time may take a while to pay off. On the other hand, if you are currently dependent on Ant or Maven ... sign up for the next class and get yourself switched over, today!

Hackergarten in PDX - Friday January 20th

Merlyn Albery-Speyer is organizing a Hackergarten while Luke Daley (creator of Geb, and Gradle committer) is in town to run an in-depth Gradle training. I'll be there, working on Tapestry, or Gradle, or a video game, or something.

Please see Meryln's blog to RSVP. I look forward to meeting and coding with more PDX peeps!

Adding "Ajax Throbbers" to Zone updates

A common desire in Tapestry is for Zone updates to automatically include a throbber (or "spinner") displayed while the Ajax update is in process. This is, unfortunately, a space where the built-in Tapestry 5.3 Zone functionality is a bit lacking. Fortunately, it's not too hard to hard it in after the fact.

This solution involves a JavaScript library, two CSS stylesheet files (one is IE specific), plus the "throbber" image. Typically, you'll bind all of these things together in your application's Layout component.

First, the JavaScript. We need to intercept links and forms that update a Zone. When such a request starts, we add a <div> to the top of the Zone's client-side element. When the update from the server arrives, the entire content of the Zone's element will be replaced (so we don't have to worry about clearing the <div> explicitly).

When a form is submitted with Ajax, to update a Zone, Tapestry fires a client-side event on the Form; the Tapestry.FORM_PROCESS_SUBMIT_EVENT constant provides the event name. The primary handler for this event is the code that actually performs the XmlHTTPRequest and sets up a handlers for the response; the above code adds a second handler that adds the Ajax overlay.

Likewise, when a link is used to update a Zone, there's a second client-side event; again, the primary handler for the event does the actual Ajax work, but the same logic allows the Zone to be decorated with the overlay.

The overlay consists of a <div> that will visually mark the entire zone's content and consume any mouse clicks during the Ajax update. The CSS associated with the zone-ajax-overlay CSS class sets up a translucent background color and the spinning Ajax throbber.

Next up is the CSS:

This little bit of CSS is doing quite a bit. Firstly, if the Ajax request is very quick, then there will be an annoying flicker; to combat this, we've set up a simple CSS animation to delay the animation momentarily, long enough that fast requests will just see the new content pop into place. There's probably a bit of room here to tweak the exact timing.

Alas, in the current world, we need to do a bit of work to support both Firefox (the -moz prefix) and WebKit (Safari, Chrome, the -webkit prefix). This is really calling out for a SASSy solution.

You'll also see an animated image for the throbber. I used ajaxload.info to create one.

But what about Internet Explorer? It doesn't understand the animation logic, and it does CSS opacity differently from the others. Fortunately, we can segregate those differences in a separate CSS file.

Lastly, we put all this together inside the application's Layout component:

The @Import annotation does the easy imports of the main CSS and JavaScript.
Tapestry 5.3 supports IE conditional stylesheets ... but this requires just a bit of code as the @Import annotation doesn't support adding a condition, as this is a fairly rare requirement.

Instead, the IE-specific CSS is injected into the page as an Asset object; this can be combined with StylesheetOptions to form a StylesheetLink, which can be imported into the page.

With this in place, every page will include both CSS stylesheets (one as an IE-only conditional comment) and the necessary client-side logic ... and every Zone update will get this uniform treatment.

There's some limitations here; in Tapestry it's possible for the server-side to push updates into multiple Zones. The client-side doesn't even know that's happening until it gets the reply, so there's no universal way to add overlays to multiple zones when the request is initiated.

Secondly, in rare cases, a Zone update may only update other Zones, and leave the initiating Zone's content unchanged. In that case, you may find that the Zone's throbber is still in place after the response is handled! I'll leave it as an exercise to the reader on how to deal with that.

Dissecting a Tapestry Operation Trace

I'm helping out a client who is having a problem using Spock and Tapestry 5.3 together. The Spock/Tapestry integration was created for Tapestry 5.2, and some subtle change in the Tapestry 5.3 IoC container has boned the integration, so running even a simple test results in an exception, with a very big stacktrace:

The part at the top (the numbered entries) are the operation trace: Tapestry tracks what its doing at all times (using a stack stored inside a ThreadLocale) just so it can report this information in case there's an error. That's part of Tapestry's commitment to useful feedback. The operation tracing was enhanced a bit in Tapestry 5.3 to be a bit more verbose and all-reaching.

The operation trace is providing a wealth of information about how Tapestry got to the point where an exception was thrown. This is much more useful than just the huge stack trace (about 400 frames!) since Tapestry, by design, tends to call through the very same methods repeatedly; stack traces are less useful when what counts are the parameters to the methods, rather than the methods themselves.

It takes a while to figure out, but the key operations are:

That operation corresponds to invoking this method:

Translated to English, this code says:

When starting up the Registry (the odd name for the Tapestry IoC container), execute this block of code, that checks to see if early startup of Hibernate is desired and, if so, forces the initialization of Hibernate by invoking the getConfiguration() method (otherwise, the initialization would happen lazily the first time a request needed to use the Hibernate Session).

The @Symbol annotation means that the parameter's value is derived from a Tapestry configuration symbol, which is a flexible, late-binding way to configure services as they are instantiated. In other words, because of the use of a symbol, rather than a constant, the actual value passed in can't be determined until runtime ... which is a good thing; it means a developer can configure the symbol's value locally, but a different default value is in effect for the production application. Sometimes you want early startup, sometimes you don't.

In order to resolve the value of a symbol, Tapestry must instantiate the SymbolSource service; it has its own configuration that depends on other services, including ApplicationDefaults, FactoryDefaults, as well as a few other simple objects that implement the SymbolProvider interface, but are not services.

There's also a hidden dependency here: Starting in Tapestry 5.3, Tapestry will attempt to type-coerce contributed values (in this case, symbol values contributed to ApplicationDefaults or FactoryDefaults) from their actual type, to the expected type. That shows up in operation 14:

Those integers and booleans need to be converted to Strings; Tapestry 5.3 invokes the full machinery of the TypeCoercer service to do this coersion, seen as operation 15.

At operations 21 - 23, Tapestry sees the ThreadLocale service (which stores the active Locale used during processing of the request; something that can vary on a request-by-request basis). The ThreadLocale service uses a special service lifecycle that enforces that the instance is stored as a per-thread singleton, not a per-Registry singleton, and will be discarded at the end of each request.

The ServiceLifecycleSource service is the source for these ServiceLifecycle objects.

At operation 28 - 31, the Spock/Tapestry integration code is getting involved. It adds a special service lifecycle just for values that are part of a Spock specification ... and we're finally reaching the problem point!

The Spock/Tapestry integration is using the addInstance() method, which instantiates a class with dependencies; this is operation 30. This is the problem point, but it's not obvious why its causing an eventual exception.

Because of the use of addInstance(), Tapestry must locate and inject the dependencies of the PerIterationServiceLifecycle class, including the IPerIterationManager service (operation 31).

In Tapestry, there is a mechanism to replace services with overrides; this is the ServiceOverride service and its configuration. It's super handy for extending Tapestry in completely unexpected ways.

That brings us to some code, new in Tapestry 5.3, at operation 38:

And that brings us to the actual cause. Notice the @Symbol annotation ... remember way back to operation 7, that required the TypeCoercer (operation 15) ... well, we're not done with that yet, but this production override code has a @Symbol annotation that requires the TypeCoercer ... which is still in the middle of being instantiated.

Yes, this takes a lot of detective work ... this is something of an Achilles' Heel of Tapestry's IoC container; since much of the functionality of the container is defined in terms of other functionality of the container, you can get into these hidden dependency cycles when tweaking some of the more fundamental aspects of Tapestry, such as TypeCoercer contributions, or adding new service lifecycles. This is unfortunate, since so much else in Tapestry's web framework and IoC container Just Works^TM.

In terms of fixing this ... turns out the Spock/Tapestry integration has some other dependencies on 5.2, making use of internal classes and constructors that no longer exist in 5.3. I'll be forking their code shortly to produce a 5.3 compatible version.

However, my take-away here is: the system works, the emphasis on feedback, and the generation of useful operation traces, makes this detective work even possible. The alternative would have taken far, far longer ... using the debugger to try and work backwards to what Tapestry was trying to do. It's so much better to have Tapestry simply tell you what you need to know!

Mac Tips: Preventing Aperture from Launching

Since I tend to connect and disconnect my Android phone to my Mac pretty often, I got frustrated that it kept launching Aperture every time (it used to do the same with iPhoto, before I switched).

In any case, the solution for this is easy enough; with the phone connected, launch the ImageCapture.app: select the phone, and choose "No application" from the drop down list in the bottom left corner:

This is under Lion; your mileage may vary under earlier versions. Hope it helps!

Gradle Training in Portland

It's no mystery that I'm a big Gradle fan ... it's by far the best build tool I've even seen. Build scripts are concise and readable, and Gradle the easiest build tool to configure and extend, as well.

I fought an uphill battle with the other Tapestry developers to replace Maven with Gradle. Yes, we had an existing Maven build and it worked (most of the time, until it didn't). Now past the switchover, we're really reaping the benefits: faster builds, fewer headaches, and it's much easier to add new sub-modules. Despite the achievements I've made with Gradle, there's a lot about this powerful tool I still need to learn. So I was surprised and pleased when Tim Berglund contacted me to help find a venue in Portland, Oregon for Gradle training.

They're now advertising that the three-day training is coming January 17-19, 2012; details here.

I've seen Tim speak at a number of No Fluff Just Stuff and Uberconf sessions; he's very good. If you are frustrated using Ant or Maven, you need to learn Gradle, and I can't see how getting an intensive brain dump won't do anything but save you time and money.

Some Tapestry Stories

A ways back, I published a call for anyone interested in free Tapestry 5 Laptop stickers (that call is still open!). You get the stickers, I get a story. Here's a few highlights, in no particular order:

Robert B., USA

The SC Medicaid Web Portal enables doctor's offices and hospitals, using the Web, to enter and submit claims for patients enrolled in Medicaid in South Carolina.

Steve E., Singapore

We're producing an on-line matching system for Non Deliverable Forwards (NDFs) in the currency finance market for a brokerage firm. (Or I guess in layman's terms, a gambling system!)

Kejo S., Switzerland

We are working now since almost 3 years with T5 and we created an application platform for ABB with it and really a lot of other projects. I think we wrote already far more than 1 million lines around your framework! Often your framework is fun and sometimes pain, but it's always amazing how lean and clean your source is! Overall I think it is the best frontend framework in the java ecosystem right now! Great Work!

Ivan K., Belarus

We just started new project on t5 - online collectible card game.

Michael L., Germany

We started a Tapestry5 project to build our extranet application, that links into the ERP to provide realtime information to stake holdersaand supporting internal workflows. We're just at the beginning and implementing more and more stuff. However, we looked at different Web-Frameworks but Tapestry5 simply rocked!

Greg P., Australia

I'm using Tapestry to create liftyourgame.com. A site that allows people to achieve their goals.

Szymon B., Poland

We use Tapestry 5 in our economic information service neurobiz.pl. It gives users access to the information about businesses operating in Poland and registered in National Court Registry.

Dominik Hurnaus, Austria

Working on a large CRM system for an automotive customer.

James S., USA

My team and I are working on a web-based interface for a fuzzy lookup and matching engine we've developed. I've also started messing around Tapestry for a few of my personal projects. I started using T5 a couple months ago, and so far I'm loving it.

Nenad N., Serbia

I am working with 5 other developers on mobile portals developed with Tapestry for multiple clients.

Dragan S., Macedonia

I was a GSOC developer and now I'm trying to do new cool stuff with Tapestry like websocket integration with node.js and rabbitmq.

Volker B., Austria

Our project is a dealer management system which supports dealers and workshops of the VW Group's brands and the Porsche sports car brand in all sorts of operational processes in a modern and flexible way ... in our company I think there are about 80-100 people that are using Tapestry.

Daniel J., Canada

Assessment dashboards for schools in southwest SK, Canada

William O., USA

We are working on a number of cool Facebook apps using Tapestry. One's called My Social Rankings ( mysocialrankings.com ), and the other is called Blingville (blingville.com).

Peter P., Slovakia

We are developing web applications for broker companies using Tapestry 5, and its great to develop with Tapestry.

Pablo N., Argentina

We are using Tapestry for http://www.squidjob.com (migrating out of GWT). The site is THE place for finding service providers for anything.

Joost S., the Netherlands

Yanomo is time tracking, project management and invoicing software for the rest of us. Use it and "You know more" :)

Alexander G., Belarus

We have been using Tapestry for about 6 years in our projects. Our current project is web administration console for RadiumOne Display (www.radiumone.com) platform. We are very happy with our stack consisting from Tapestry5+Spring+Hibernate+jQuery.

As usual, I see a lot more Tapestry adoption outside the US; I wonder if its about programming culture ... or about Tapestry localization support? I tend to see the Europeans developers as having more freedom to work with less mainstream technologies ... but when I ask them about this, they always seem to think that it's the US developers who have that freedom. I guess the grass is always greener.

Tapestry 5.3 Maven Archetype

After struggling most of yesterday day, I finally have the Maven archetype working.

Use the command:


mvn archetype:generate -DarchetypeCatalog=http://tapestry.apache.org/


This points Maven at the Tapestry-specific Archetype Catalog, you want the first option ("Tapestry 5 Quickstart Project"), then choose the fourth option ("5.3-beta-20").

I need to fix something broken in the CSS of the archetype; otherwise it's working nicely, and demonstrates a bunch of new features in Tapestry 5.3; it also makes use of up-to date features, such as using the @Import annotation (instead of the now removed @IncludeStylesheet annotation), and some Ajax features on the first page.

I may switch things around to make use of Twitter's Bootstrap CSS stylesheets.

Here's a full session of creating the application and getting it running; it took less than 30 seconds:

Things You Didn't Know About Tapestry 5.3

I missed the JavaOne Comparing Web Frameworks talk and was appalled at some out-of-date information in it ... though reviewing his slides, it looks like he talked about Tapestry 5 but showed out-of-date Tapestry 4 examples. With Tapestry 5.3 ready very soon now (and less than a year after 5.2) it seemed like a good time to share some cool things about Tapestry:

Tapestry Release Compatibility

Tapestry 5.3 will be available soon; and for the majority of users, the upgrade is simply a matter of changing the version number in their pom.xml or build.gradle. Release compatibility was certainly a major headache from Tapestry 3 to Tapestry 4; and there is admittedly no direct upgrade path from Tapestry 4 to Tapestry 5 ... but Tapestry 5 was created from the ground up to prevent the kind of pain experienced in prior Tapestry releases. To wit:

• Services and dependency injection allows a fine-grained, not monolithic, approach to evolving the framework
• Metaprogramming of components allows new behaviors to be gradually introduced, bypassing the fragile base class problem
• Tapestry 5 has always carefully separated internal interfaces (which is not guaranteed to be stable between releases) from stable public interfaces. Literally, in packages named .internal. so there's no guesswork about what's public and what's internal
  

Tapestry Makes It A Snap To Work With Hibernate and JPA

Tapestry has built-in modules for supporting both Hibernate and JPA. You get lots of stuff for free, including automatically configuring entities (just put them in the right package), easy transaction management, and smart encoding/decoding of entities ... Tapestry knows how to convert back and forth between entity instances and primary keys when building URLs.

Tapestry Works Great With Spring

Tapestry integrates very cleanly with Spring. You can inject Tapestry services into Spring beans, you inject Spring beans into Tapestry services and components.

Tapestry Plays Well With Others

Tapestry doesn't care if you have other servlets running in the same web application. You can fine-tune how it builds URLs, or even put Tapestry in a box so it doesn't collide with other servlets or filters. You can also easily share information with other applications.

Tapestry Likes HTML5

Starting in Tapestry 5.3, <!DOCTYPE html> works perfectly in Tapestry.

Tapestry Hot Deploys

Tapestry (since 2006) has had live class reloading; change a template or a Java file and Tapestry reloads it instantly. And since its integrated into the framework, Tapestry can be very efficient about loading and reloading resources. Since 5.2, Tapestry has also live reloaded (most) service implementations. So code away! Tapestry can keep up with you.

Tapestry Loves Ajax And JavaScript

Tapestry (currently) bundles Prototype and Scripaculous, but you can swap that out for jQuery quite easily. Tapestry has most common Ajax use-cases built in, and uses a uniform approach to rendering full pages, or individual snippets. Tapestry does a lot of other tricks, such as combining your individual JavaScript files into a single JavaScript stack (on the fly, at runtime). In addition, Tapestry has an extensible framework for organizing your JavaScript and initialization code (partly on the server-side, partly on the client-side).

Tapestry 5.3 adds vastly improved reporting of server-side exceptions, along with an easy way of presenting alerts to users.

Tapestry Is Polyglot

Tapestry doesn't care if your classes are written in Java, Scala or Groovy ... if it's bytecode, that's all that counts.

Tapestry Is Fast And Getting Faster

Tapestry has been getting faster and leaner with each release. 5.2 introduced page singletons (where a single page instance can be safely shared across many threads, even though it contains mutable fields) and 5.3 boosts the performance in a bunch of ways large and small. Tapestry 5.2 scored right at the top of this performance comparison, and Tapestry 5.3 is around 30% faster.

Tapestry Has The Best Feedback Of Any Framework, Period

Tapestry's approach to feedback goes far, far, far beyond any other framework or toolkit; it goes beyond the comprehensive exception report page and extends to small concerns throughout the framework:

• Tracking what the framework is doing, and why, at all times
• Including extra checks for common errors and building real messages that identify what went wrong and how to fix it
• Built-in pages to allow simple application monitoring

Tapestry Really Gets Localization

Localization support isn't an add-on; it's built-in from the ground up. Tapestry allows templates and other assets to be localized automatically: just follow the naming convention and Tapestry uses the correct file. Tapestry has localized messages for 14 languages and counting.

Tapestry Is Customizable

Tapestry's architecture, based on lots of individual services and dependency injection, means that almost any service or other logic in Tapestry can be overridden. Don't like how Tapestry builds URLs? Replace it seamlessly. Dont' like how Tapestry reports exceptions? Replace it! Tapestry is designed specifically so that you can augment or replace any behavior in the framework.

Tapestry is a Meta-Programming Monster

And I mean that in a good way; Tapestry has powerful support built-in for meta-programming at the services layer and at the component layer. Tapestry lets you get in and modify method invocations and field access, without getting your hands dirty with the ugly bytecode details. All the cool things Tapestry does with naming conventions and annotations is wide open for application-specific things. Meta-programming provides a critical alternate avenue of code reuse.

Tapestry IoC Works Great On Its Own

Tapestry's IoC library works great on its own, separate from the web framework itself. That includes live class reloading, meta-programming capabilities ... even a simple job scheduler.

... that's enough for now. The point is that Tapestry has a lot going on ... to paraphrase Philip Greenspun:

Any sufficiently complicated servlet or JSP web application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Tapestry.

... and half is being very generous!

Tapestry: Feedback!

I often say that the three cornerstones of Tapestry are Simplicity, Consistency, Efficiency, and Feedback. Although all four of these concepts work in concert with each other, it's Feedback (keeping the developer informed when things go wrong) that is one of the most distinguishing features of Tapestry, and that's only gotten better in Tapestry 5.3.

Exception Reporting

First off, there's Tapestry's default exception report page. When an exception is thrown during a request, most often a coding error in a Tapestry page or template, Tapestry moves heaven and earth to report the exception properly. For example, in Tapestry it is not allowed for a component sub-class to define a parameter with the same name as a parameter from a base class, as this creates an ambiguity. When this situation occurs, an exception is thrown from deep in the bowels of Tapestry:

That's a start, but it's not great feedback; you'll be doing a lot of work to figure out what was going on in Tapestry leading up to the exception, and from there, figuring out how to fix it; there's lots and lots of noise in the repeated stack traces (caused by nested exceptions). However, you can see a glimmer of hope in those first few lines, the ones that start Registry [ 1], Registry [ 2], ...

Tapestry goes to a lot of trouble to track what is going on during the handling of a request; it keeps a stack of operations which describe what Tapestry is doing at any particular time. There's still a lot of internal details, but the gist of it is that Tapestry needed to create an instance of the ParameterConflictDemo page, and hit an error while doing something with the ParameterSubClass component (sorry for the ugly names, I'm using examples from Tapestry's internal test suite).

However, parsing apart the console output is NOT what a Tapestry developer does; instead they'll get all those details, and more, from the Tapestry exception report page:

Ah, much better. We're seeing the essential details from the stack of exceptions; we're seeing the associated template snippet that defines the parameter with the exception, we're seeing that operations stack neatly formatted. We see that stack of operations here as well, formatted for readability. Scrolling down, we see the stack trace of the deepest exception, formatted:

The frame in bold blue? That's a frame in the application's package, rather than code in inside Tapestry. That highlighting is very useful for letting the developer quickly figure out if the cause of the exception is a minor problem inside their code, or something more involved that shows up inside the Tapestry framework code.

Scrolling further down, we start seeing even more relevant information: all the details of the incoming request:

... well, you get the idea. Where a framework that takes feedback less seriously might give you a simple stack trace and leave the process of determining the underlying cause entirely up to you (after all, you have a debugger, right?) Tapestry fully embraces the importance of feedback: giving you all the information you need as soon as you need it (and yes, you don't have to show all that to your end users). More than that, there's attention to detail throughout Tapestry to provide real exception messages. For example, if you provide a component type name that doesn't match some component, Tapestry responds with a detailed message, including a list of all the known component types:

Again, Tapestry doesn't want you to have to put on your detective's hat to figure out what's wrong and how to fix it. It's providing all the details you need right when you need them.

Live Application Introspection

What if your problems are more subtle? How do you track down other issues, like performance problems or memory utilization? Well, Tapestry provides some introspection to address those questions as well. Tapestry 5.3 adds the Page Catalog, a special page for providing information about what pages have been loaded into memory, and a few details about how big they are, and how long they took to assemble:

Likewise, the Service Status page gives you feedback about the services defined inside the Tapestry Inversion of Control container, helping you determine what services exist, and in what state:

Deep Details

And what if you are tracking down something even more subtle? Well, by enabling some logging, Tapestry will output that operations trace as each operation starts and finishes. It's an avalance of information, much of it about instantiating services ... below is a log of just what happens when you first startup a Tapestry application, before it even processes it's first request:

Because Tapestry operates lazily, instantiating pages and services only as needed, even more happens when the first page request arrives:

Conclusion

In any case, the point of all this is that Tapestry provides you with the key tool, information, at all stages of development. This is central to Tapestry as a tool to be used: a framework that gets in the way, that makes any aspect of development harder or slower than it should be, is a framework that should not be used ... and I feel quite strongly that Tapestry is a framework meant to be used!

Changes to Cascade, and a cautionary tale about defrecord

Since I've been talking more about Clojure lately, I've spent a little more time working on Cascade. I've been stripping out a lot of functionality, so that Cascade will no work with Ring and Compojure, rather than being in competition. Its Clojure, after all, ... there's less of a reason to build a full framework since its so easy to simply assemble your functionality from proper libraries.

It's also been a chance to update some of my code with more modern constructs. For example, the earlier version of Cascade used a (defstruct) for the DOM nodes; the new code uses (defrecord).

Along the way I discovered something interesting about defrecord. Consider this code:

Technically, this is just an optimized way to define a Clojure Map. If I have an instance, I can (:text node) to get the text out of the map.

However, (defrecord) does one other thing that is barely mentioned in the documentation (and not referenced, that I can tell, in Joy of Clojure). Notice the implementation of the stream function (part of the NodeStreaming protocol). It just says text; not (:text node). Inside a protocol method, the fields of the record are bound to local variables, making them easy to use ... another benefit.

I actually found this the hard way, when writing a more complicated example, for the Element DOM node:

Notice the use of clojure.core/name to convert a keyword to a string; originally this was (name (:name node)) and returned nil. This confused me quite a bit!

What ended up happening was that name was bound to the keyword from the record's name field. However, Clojure keywords can be used as functions,and was incidentally passed itself, which is to say (for an Element node representing a <p> element): (name (:name node)) --> (:p :p) --> nil.

So, (defrecord) giveth, but it also taketh away, at least, the first time. In other words, watch out for name collisions between the names of the record's fields, and the names of functions you want to reference from your protocol method implementations.

Back to Cascade; I don't have any metrics available about performance changes with the new code (using records and protocols), but I suspect its faster and more efficient.

A lot of the features that were in Cascade are gone and will come back soon. Ultimately, I'll have Cascade flavors of context and classpath assets from Tapestry, as well as mechanisms similar to Tapestry for adding JavaScript libraries and CSS stylesheets, along with a mechanism similar to Tapestry for organizing them into stacks.

Looking further forward, adding support for Enlive, both reading parsed XML templates in as DOM structure and allowing Enlive transformations onto the DOM structure, seems like a good direction.

When will all this happen? I'm not certain, but I hope that Cascade will become a "must-have" layer on top of Compojure, adding some of the industrial strength concepts from Tapestry into the fast-and-loose world of Clojure web applications.

Tapestry 5 Laptop Stickers

I'm the kind of guy who does a lot of self-expression on my laptop:

Hey, what's that at the bottom? A Tapestry 5 laptop sticker? Cool!

Want one? Drop me a line at hlship at gmail dot com with the subject "T5 STICKER". Provide me with a quick (one-line summary) of your project and a snail-mail address (outside the US is OK) and how many laptop stickers you need (keep it reasonable, as in, how many of your project developers will actually put one on their laptop).

First come, first serve, supplies are limited, offer may be rescinded at any time!

Update: I'm really enjoying seeing all the stories of people using Tapestry; if it's OK, I'd like to generate a list of people (just first name and last initial), country, and a one-line project summary, to post on this blog, or on tapestry.apache.org.

If you do NOT want to be publicized, please indicate that in your email.

How They See Us, How We See Them

Stumbled across this great graphic on GlobalNerdy Blog.

Sorry my blog layout gets in the way, try the direct link to the image.

Clojure: Towards the Essence of Programming

My talk from the What's Next Paris conference, Clojure: Towards The Essence of Programming is now online at InfoQ. This is the full talk ... video plus slides. See if you can spot the point where I almost pass out from jet lag!