ÜberConf

Why an Agile Project Manager is Not a Scrum Master

Johanna Rothman — Wed, 01 Feb 2012 10:01:00 CST

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

Explain that velocity is not a productivity metric
Say No and explain why
Play the Double Your Velocity schedule game
Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

LinkedIn Etiquette

Howard Lewis Ship — Fri, 27 Jan 2012 10:07:08 CST

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 you aren't forced to customize the message. As far as I'm concerned, the default message is like no message at all, and its a sign that you are just trolling for contacts. Just like you should always write a cover letter for a resume.

So the first rule of LinkedIn is: always customize the message. You chances of a connection go up significantly (at least with me) ... and with the default message, your chances drop down to near zero.

Tapestry Advantages

Howard Lewis Ship — Thu, 26 Jan 2012 12:26:50 CST

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.

Github Ribbons in CSS

Terry Ryan — Wed, 25 Jan 2012 15:55:00 CST

Github has these cool ribbon images that you can use if you want to encourage forking your project on your site. They're great and I wanted to use them on a little project I am working on. However, one of my goals was not to use any images, but rather produce all display elements with CSS.

It was a little bit of trial and error but I got it working. Basically you do the following:

Create a link in a div with an id of "banner"
Force div#banner to be 149px x 149px.
Set overflow to "hidden"

This creates a square display area that won't show things that stretch out past the bounds of the box.

Create an A link
Tilt it using a CSS transform
Use relative positioning to pull the ribbon into place
Use CSS shadows to tweak the text and ribbon shadows
Finally I use a CSS gradient in the background of the ribbon to give it the bands that run along the edge.

Issues:

It's not a pixel perfect representation.
It doesn' work on IE before 9. It doesn't appear at all.

I'm not sure if I'm going to use this. I'll sound judgmental here, but the fact that it doesn't show up on IE less than 9 seems like a good thing. Do I want a developer on my project that isn't using the latest browser? Probably not.

Demo
See the live demo here.

Update

A couple people pointed out that there was a weird doubling of the letters on their browser (Chrome on Windows, and Safari on iPad.) Looks like it was caused by a slight text-shadow I had on the text. The text on the original banner has some anti-aliasing going on, and on some browsers, the text shadow helps it look a little smoother, but on others you get that doubling. So I've removed the text shadow. Display should be a little more consistent.

Agile Lifecycles for Geographically Distributed Teams, Part 2

Johanna Rothman — Wed, 25 Jan 2012 10:06:00 CST

Example 2: Using a Project Manager with Kanban, Silo’d Teams

This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.

This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.

The New York developers had a problem biting off more than they could chew. So nothing moved across their board. The Italy developers had a board where the work did move across the board. The teams took pictures of their boards every day and shared the work across a project-based wiki. That allowed the New York-based developers to see the work move across the Italy board. And, that encouraged the New Yorkers to call the Italians and ask some questions. That helped the New Yorkers to change the size of their work by working with the product owners.

Now, why did the New Yorkers have such trouble originally? Because the developers “knew better” than the product owners, so they changed the stories into architectural features when they had originally received them. (Now they don’t. They leave the stories as real stories.)

Release planning: Management in California plan with agile roadmaps. They have features planned specifically week-by-week for the next 6 weeks, and have more of a quarter-by-quarter approach after that.

Iteration planning: No iteration planning because they are using kanban.

Daily commitment: No daily commitment needed because they use kanban. They do have a checkin a few times a week with each other as a technical team to make sure they don’t create bottlenecks and that they respect the WIP (work in progress) limits.

At one point, both the New York and Italy developer teams created automated tests so that the testers could catch up and stay caught up with regression tests. They add a story like that every couple of weeks, and they are paying down their automated testing debt.

The Project manager keeps an eye on the WIP, work in progress. Project manager also shepherds the product owner into keeping the queue of incoming work full and properly ranked. The product owner is notorious for changing the incoming work queue all the time. Project manager makes sure the team does retrospectives and is a little unclear how to do them in such a distributed team. The project manager is not so sure their retrospectives are working, and has started an obstacle list, to make sure the team has transparency for their obstacles.

Measurements: cumulative flow, average time to release a feature into the product.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Tapestry 5.4: Focus on JavaScript

Howard Lewis Ship — Wed, 25 Jan 2012 09:46:00 CST

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.

Tapestry 5.4: Focus on JavaScript

Howard Lewis Ship — Tue, 24 Jan 2012 19:24:33 CST

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 r2eloading, 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.

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

Modularizing JavaScript

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

Change page initializations to use modules

Here's an example component from the TapX library:

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.

Conclusion

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

Howard Lewis Ship — Tue, 24 Jan 2012 12:32:18 CST

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!

Agile Lifecycles for Geographically Distributed Teams, Part 1

Johanna Rothman — Tue, 24 Jan 2012 07:09:00 CST

I’ve been working with geographically distributed and dispersed teams for the past couple of years. Some of them on quite large programs, some of them reasonably small. What they all have in common is that they all want to transition to agile.

Most of them start this way: someone takes a Scrum class, gets all excited. This is good. Then reality hits. Scrum is meant for collocated geographically cross-functional teams. Uh oh.

Almost all of these teams are separated by function: the developers are in one place, the testers are in another, the business analysts are in a third place, the project managers are in a fourth places, and if there are product owners (or what passes for product owners) they are often in a fifth location. It’s not uncommon for every single function of the team to be separate from every other member of the team. So, the teams don’t fit the Scrum criteria. Uh oh.

Since Scrum has so much brand recognition, these people think if they can’t do Scrum, they can’t do Agile. Nope, not so. What they need to do is start from the values and principles of the Agile Manifesto, and go from there. They create their own lifecycle, and their very own brand of Agile.

When I worked with one client, that client thought they could extend their iteration. Nope, if anything, that means you keep the iterations even shorter, because you need more frequent feedback when no one is in the same place. Well, there were words. And more words. But, if you start from the values, you see that short iterations are the way to go if you want to be agile. Otherwise, you get staged delivery, which is a lovely lifecycle, but not agile.

I’m blogging a series of examples. Please don’t ask me why the people ended up in these locations. I have no idea. All I know is that’s where the people are.

Example 1: Using a Project Manager With Iterations, Silo’d Teams

One IT organization has teams with developers in the Ukraine, testers in India, product managers and project managers in the UK, and enterprise architecture and corporate management in the eastern US.

This organization moved to two-week iterations. The developers were 3.5 hours ahead of the testers, which was not terrible. This organization had these problems:

The product managers had to learn to be product owners and write stories that were small enough to finish inside one iteration.
The enterprise architects had to stop dictating the architecture without features to hang off the architecture.
The developers and testers had to learn to implement by feature so the architects could help the team see the evolving architecture.

This organization had a ton of command-and-control to start. The project managers needed to facilitate the teams, not control them. The architects needed to help the teams see how to organize the product, not to tell the developers what to do. The testers needed to not be order-takers, as in taking orders from the developers.

You might ask why the organization wanted to move to agile. Senior management wanted agile because the releases got longer and longer and longer, and could not accommodate change. Agile was a complete cultural shift. The two-week iterations, along with an agile roadmap of features helped a lot.

The pilot project team consisted of the developers, testers, a product manager, and a project manager. The team rejected the enterprise architect as a member of the team because the architect refused to write code.

Release planning: The project manager and the product manager do an initial cut at release planning as a strawman and presented it to the team. “Can you do this? What do you think?”

Iteration planning: The team does iteration planning together, making sure every story is either small, medium, or large, where a large story can be done by the entire team in fewer than three days. The team makes sure they get every started story to done at the end of the iteration.

Daily commitment: The team does a daily checkin, not a standup. They timebox the checkin to 15 minutes. They ask these questions:

What did you complete and with whom yesterday? (reinforces the idea that people work together)
What are you working on and with whom today?
What are your impediments?

The project manager who acts as a servant leader, not a command/controller manages the impediments.

The pilot project has two experienced agile people: the project manager and a developer. Both act as servant leaders.

Measurements: burnup charts, impediment charts

The pilot team has been together for six months now, and is successful. This is not Scrum. It’s not Kanban. It’s agile and it’s working. They are ready to start another project team, working by attraction.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Speaking in Philly this Week

Terry Ryan — Mon, 23 Jan 2012 12:57:00 CST

I'll be speaking in my hometown this week. I'll be presenting at the Philadelphia Area New Media Association (PANMA) meeting for January.

Topics:

jQuery Mobile
PhoneGap
Typekit
Edge
CSS Shaders

Description:

Adobe and HTML5

In the past few months, there has been a number of new tools and new services from Adobe for HTML5. Some of these tools, like PhoneGap Build and jQuery contributions are aimed at developers and some, such as Edge, are more focused on designers. Adobe Evangelist Terry Ryan will give an overview and demos of these and other tools.

The meeting is on Thursday, January 26th at 6:00PM. It will be at the Huntsman Building at 38th and Walnut on Penn's Campus.

Venn Diagram entirely in CSS

Terry Ryan — Mon, 23 Jan 2012 11:56:00 CST

A friend of mine alerted me this weekend to just how much I have a weird fascination with Venn diagrams. I decided to roll with it. So yeah, I have an irrational love of Venn diagrams. But that begs the question, can I make a Venn diagram with just CSS?

I found a couple of examples out there:

But I felt like they had a bit too much fluff in the HTML markup. Not that there is anything technically wrong with their implementations. I prefer complexity in my CSS and not in my HTML. It's probably just a subjective thing, but I do.

So how do you do it?

First you create 3 divs. 1 for each Venn circle, and 1 for the overlap section. Each div contains a p with content in it.

Then you go to style each of the circles. Give them matching heights and widths, and a border radius of half of the height. This creates the circle. Then give each one an opacity below 1. This will ensure that when they overlap they will form a new color.

I then created two rules based on the nth child css selector to color each of the circles. I also padded to ensure that there would be a space to write in the overlap section.

Finally I styled the overlap section using relative positioning and pulled it back towards the center.

The real trick is to watch the pixel counts because a couple are directly related.

To create a circle:

width must equal height
border radius must equal 50% of width.

To overlap circles:

Circle 2 must have negative x left margin
(Or Circle 1 must have negative x right margin)
Each circle must have x padding-left or x padding-right to ensure its text doesn't spill over borders

It looks like the example works across modern browsers, including IE 9, but not previous versions.

Grails: Bootstrapping data with DomainBuilder

Andres Almiray — Mon, 23 Jan 2012 06:35:00 CST

A few days ago I was discussing the topic of builders during a Grails training session. After surveying the usual suspects found in the standard Groovy distribution (MarkupBuilder, SwingBuilder, Antbuilder and ObjectGraphBuilder) we jumped into Grails' DomainBuilder. Once we got familiar with it the team seized the opportunity to refactor an existing application they've been working on for a few weeks. The idea was to remove a very verbose data setup during the bootstrap sequence.

Like many other applications out there, this one requires setting up users and roles to secure access to some areas. The User and Role classes looked like the following ones
class User { String username String name static hasMany = [roles: Role] static constraints = { username(nullable: false, blank: false, unique: true) name(nullable: false, blank: false, unique: true) } } class Role { String name static constraints = { name(nullable: false, blank: false, unique: true) } }

Nothing complex really. Now, during bootstrap there were a handful on instances of both classes being created and saved. A few users would share roles which meant keeping a reference to the common role to later use Grails relationship methods. This caused the code to be not so much DRY, and while it's good to be WET from time to time this wasn't the case. Let me show you how the code looked like before we added the builder
import com.acme.* class BootStrap { def init = { servletContext -> User user1 = new User(username: 'user1', name: 'Regular') User user2 = new User(username: 'user2', name: 'Super') User user3 = new User(username: 'user3', name: 'Über') User user4 = new User(username: 'user4', name: 'Admin') Role role1 = new Role(name: 'Observer') Role role2 = new Role(name: 'Executor') Role role3 = new Role(name: 'Collector') Role role4 = new Role(name: 'Administrator') user1.addToRoles(role1) user2.addToRoles(role1) user2.addToRoles(role2) user3.addToRoles(role1) user3.addToRoles(role2) user3.addToRoles(role3) user4.addToRoles(role4) role1.save() role2.save() role3.save() role4.save() role1.save() user2.save() user3.save() user4.save() } }

We could have saved a few lines by collecting all domain classes in Lists then applying *.save() on the lists, however that would still have left the relationship methods being defined explicitly. This is where DomainBuilder came in. With it we were able to define the domain instances and the relationships at the same time. We ended up with code looking like the following one
import com.acme.* import grails.util.DomainBuilder class BootStrap { def init = { servletContext -> DomainBuilder builder = new DomainBuilder() builder.classNameResolver = 'com.acme' builder.identifierResolver = { 'nodeId' } builder.registerFactory 'list', new ListFactory() builder.childPropertySetter = new CustomChildPropertySetter() List instances = builder.list { role(nodeId: 'role1', name: 'Observer') role(nodeId: 'role2', name: 'Executor') role(nodeId: 'role3', name: 'Collector') role(nodeId: 'role4', name: 'Administrator') user(username: 'user1', name: 'Regular') { role(refId: 'role1') } user(username: 'user2', name: 'Super') { role(refId: 'role1') role(refId: 'role2') } user(username: 'user3', name: 'Über') { role(refId: 'role1') role(refId: 'role2') role(refId: 'role3') } user(username: 'user4', name: 'Admin') { role(refId: 'role4') } } instances*.save() } }

DomainBuilder understands perfectly well the relationships between domain class instances. It also makes some assumptions on how the model is setup, but we still need to give it a few hints. In line 7 we can see a classNameResolver set on the builder. By convention the builder will use an strategy to construct fully qualified classnames out of node names. If the classes happen to be defined inside a package then you must define a custom classNameResolver. In our case the classes we're interested in live under the same package so we only need to specify it, the builder will do the rest to figure out the correct class name.

Next, we must set a custom identifierResolver because the id property is of semantic meaning to domain classes. The builder can keep references to all instantiated nodes, it will use the id property by default, assuming that's a synthetic property. This means it will treated in a different way than the rest of properties. Because id is used by domain classes we set a different synthetic property named nodeId. Finally we define a custom factory to serve as the root of the object graph. This custom factory requires additional setup to handle its children, which is why we also register a custom ChildPropertySetter on the builder. These two helper classes can be seen in the following snippets
private static class ListFactory extends AbstractFactory { Object newInstance(FactoryBuilderSupport builder, Object name, Object value, Map attributes) { [] } }private static class CustomChildPropertySetter extends DomainBuilder.DefaultGrailsChildPropertySetter { void setChild(Object parent, Object child, String parentName, String propertyName) { if (parent instanceof List) { parent << child } else { super.setChild(parent, child, parentName, propertyName) } } }

Basically the code inspects the type of the parent node. If it's a List then we append the child to it, otherwise we let the standard behavior take control. You can read more information on the builders used at FactoryBuilderSupport and ObjectGraphBuilder.

Keep on Groovying!

Drum Roll: Public Workshop April 17-18, 2012

Johanna Rothman — Fri, 20 Jan 2012 08:04:00 CST

I’m so pleased to announce that Shane Hastie and I are leading a workshop on Working Effectively In Geographically Distributed Agile Project Teams, April 17-18, 2012 in Pleasanton, CA. Yes, that is Elisabeth Hendrickson’s Agilistry Studio.

Shane and I first delivered this workshop last year in Australia, when I was there for Software Education‘s SDC. We had a great time, and so did many of the participants. We have since evolved the workshop, to address the needs of the participants who did not have a great time, and to make sure we covered the topics we need to cover.

This is an experiential workshop. You will learn by doing and debriefing. If you’ve taken my one-day versions over the past year, you’ve had a taste of what we do in the two-day. You will learn even more from both of us. Remember, we developed this as a geographically distributed pair.

One of the benefits of signing up for the workshop is the informal consulting you can obtain, not just from us, but from the other people there. You’ll hear what other people are doing, what’s working and what’s not working. If you want, you can hear from Shane and me about what’s working and not working at our clients as they transition to agile and explore more agile approaches.

Do check out the syllabus. And, if you’re ready to sign up, please register.

Pragmatic Manager and InfoQ Video Posted

Johanna Rothman — Thu, 19 Jan 2012 06:51:00 CST

I have posted last week’s Pragmatic Manager, Are You Being Guilted Into Doing More?.

At Agile 2011, I had a great video conversation with Shane Hastie about agile project portfolio management. The chair is big, I’m not so short. The chair is big, I’m not so short. How many times do you think I have to say that to make it true? The chair is big, I’m not so short. That ought to do it.

Speaking at Webvisions Next Week in NYC

Terry Ryan — Fri, 13 Jan 2012 15:57:00 CST

I was originally scheduled to help out my colleague Kevin Hoyt as a TA. Turns out that there was a slight scheduling SNAFU and I'm taking a full slot. My topic:

The Future of HTML5 Motion Design

HTML5 and CSS3 are hot, driven by an explosion of new, Internet connected devices. While they offer many new features that should allow you to do the types of things that you previously did in Flash, actually making it happen is really hard. Until now.

If you weren't sure, I'll be talking about Adobe Edge, our HTML5 animation tool. It's currently in beta, and looking pretty cool.

So if you're in NYC, and want to get some dirt on where Adobe is going with HTML animation or just to get close to some of the foremost experts on the web, you really got to check out Webvisions.

Hackergarten in PDX - Friday January 20th

Howard Lewis Ship — Fri, 13 Jan 2012 10:06:36 CST

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!

Elvis carried away by spaceships

Kenneth Kousen — Fri, 13 Jan 2012 00:25:00 CST

I love teaching Groovy to existing Java developers, because they have such a hard time holding back Tears Of Joy when they see how much easier life can be. Today, though, I did a quick demo that resulted in a line of Groovy that was so amusing I had to post it here.

Consider a trivial POGO (Plain Old Groovy Object) called Course:

class Course
    String name
    int days
    String toString() { "($name,$days)" }
}

The goal was to take a collection of courses and sort it by the number of days. That’s really easy in Groovy:

def courses = [
    new Course(name:'Groovy',days:4),
    new Course(name:'Grails',days:3),
    new Course(name:'Spring',days:4),
    new Course(name:'Hibernate',days:3)
]

assert courses.toString() == '[(Groovy,4), (Grails,3), (Spring,4), (Hibernate,3)]'

courses.sort { it.days }

assert courses*.days == [3, 3, 4, 4]

The sort method in the java.util.Collection class is part of the Groovy JDK, meaning it’s one of the methods Groovy adds to the standard Java libraries. It takes a closure of either one or two arguments. In this case, I’m using the one-argument closure, which is used to select a property on which to base the sort. By specifying it.days in the closure, I’m telling the sort method to sort the courses based on their days property. Then I verify that the sort worked by checking that the courses are the right order, using the spread-dot operator to just look at the number of days.

In class the question that always comes up is, can I sort by days and then by name? In other words, if two courses have the same number of days, can I then sort by the name property?

That’s what the two-argument closure on the sort method is for. The two arguments are references to any pair of courses, and the closure should return a negative number, zero, or positive number according to whether the first course is less than, equal to, or greater than the second.

Here’s where things get amusing. The sort I want is:

courses.sort { a,b ->
    a.days <=> b.days ?: a.name <=> b.name
}

assert courses.toString() == '[(Grails,3), (Hibernate,3), (Groovy,4), (Spring,4)]'

The body of the closure on sort uses the spaceship operator <=>, which returns -1, 0, or 1 depending on whether the left side is less than, equal to, or greater than the right side. I use spaceship to compare the days properties. Then I add the Elvis operator ?: which means if the days comparison is not zero, use it, but otherwise use the following comparison, which uses another spaceship to compare by name.

It’s only after writing the code in class that one of the students pointed out that I had Elvis in between two spaceships, leading to the following observations:

The spaceships are there to return Elvis to his home planet
It takes two spaceships, working in tandem, to carry Elvis away, in much the same way two swallows can carry a coconut in tandem
Therefore, the Elvis being carried away must be the fat Elvis from the 70s, rather than the thin, cool Elvis from the 50s

Either way, after the sort is finished, Elvis has left the building.

Thank you, thank you very much.

Who’s Playing Agile Schedule Games Posted

Johanna Rothman — Wed, 11 Jan 2012 06:18:00 CST

My new Gantthead column is up, Who’s Playing Agile Schedule Games?

If you liked the schedule games from the more traditional projects, you’ll love the agile schedule games. Please comment over there.

Pragmatic Manager Posted: Are Your Shoulds Driving Your Decisions

Johanna Rothman — Tue, 10 Jan 2012 09:08:00 CST

I posted my most recent Pragmatic Manager: Are Your “Shoulds” Driving Your Decisions?

Yes, in case you couldn’t tell, I am doing a series on project portfolio management, so that you do take a look at my Peer Project Portfolio Coaching. Several people took advantage of the early bird pricing. We’re in the not-quite-early-bird pricing now. And, if you sign up with a buddy, you can still get early bird pricing for the two of you. It’s a steal.

If you are struggling with too much to do, sign up. If you are overwhelmed with your workload, sign up. If you are trying to do it all, sign up. You cannot succeed. You are making yourself crazy.

We will use agile and lean approaches and help you overcome the guilt, the sunk cost syndrome, and the “you’re not playing with the team” nonsense that other people will pull on you. You’ll get the support you need from your peers.

Join us. You won’t be sorry.

Using Spring to Receive JMS Messages

Bruce Snyder — Tue, 10 Jan 2012 00:26:00 CST

Have you ever had a need to create your own JMS consumer? Or will you have this need in the future? If you answered yes to either one of these questions, this post will simplify your life.

In the previous post, I discussed Using the Spring JmsTemplate to Send JMS Messages. As a follow-on, in this post I will demonstrate how to receive messages using Spring JMS. Although the previously mentioned JmsTemplate can receive messages synchronously, here I will focus on asynchronous message reception using the Spring message listener container architecture, specifically the DefaultMessageListenerContainer.

The DefaultMessageListenerContainer (DMLC) is another wonderful convenience class that is part of the Spring Framework's JMS package. As you can see in the Javadoc, the DMLC is not a single class, but a well-abstracted hierarchy for the purpose of receiving messages. The reason for this is that the DMLC takes its inspiration from Message Driven Beans (MDB).

MDBs were originally defined in the EJB 2.0 spec as a stateless, transaction aware message listener that use JMS resources provided by the Java EE container. MDBs can also be pooled by the Java EE container in order to scale up. In short, MDBs were designed for asynchronous message reception in a way that the Java EE container could manage them. Although the intention was good, unfortunately the disadvantages of MDBs are numerous including:

MDBs are static in their configuration and creation (they cannot be created dynamically)
MDBs can only listen to a single destination
MDBs can only send messages after first receiving a message
MDBs require an EJB container (and therefore the Java EE container)

Although the Spring DMLC took its inspiration from MDBs, it did not replicate these disadvantages; quite the opposite, in fact. The Spring DMLC is commonly used to create what have become known as Message-Driven POJOs (MDP). MDPs offer all of the same functionality as MDBs but without the disadvantages listed above. The Spring DMLC provides many features including:

Various levels of caching of the JMS resources (connections and sessions) and JMS consumers for increased performance
The ability to dynamically grow and shrink the number of consumers to concurrently process messages based on load (see setConcurrentConsumers and setMaxConcurrentConsumers) for additional performance
Automatically re-establishes connections if the message broker becomes unavailable
Asynchronous execution of a message listener using the Spring TaskExecutor
Support for local JMS transactions as well as an external transaction manager around message reception and listener execution
Support for various message acknowledgement modes, each providing different semantics

For some situations, it is important to understand the additional error handling and the redelivery semantics that are provided by the DMLC. For more information, see the AbstractMessageListenerContainer JavaDoc.

The reason I recommend the DMLC (or even the SimpleMessageListenerContainer) is because writing JMS consumers can be a lot of work. In doing so, you must manually handle and mange the JMS resources and the JMS consumers, any concurrency that is necessary and any use of transactions. If you've ever done such work you know how arduous and error prone it can be. Certainly MDBs provide some of these features but with all their disadvantages. By creating MDPs using the Spring DMLC, I have seen users save a tremendous amount of time and increase their productivity significantly. This is because the DMLC offers much flexibility, robustness, a high amount of configurability and it has widespread deployment in businesses all over the world (so it has been widely tested).

Compared to MDBs, use of the Spring DMLC is actually surprisingly simple. The easiest way to get started is to using an XML configuration as the Spring DMLC provides JMS namespace support. Below is a Spring application context that demonstrates the configuration to use the Spring DMLC with Apache ActiveMQ:


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jms="http://www.springframework.org/schema/jms"
       xmlns:p="http://www.springframework.org/schema/p"
       xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-3.0.xsd">

  <!-- A JMS connection factory for ActiveMQ -->
  <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"
  p:brokerURL="tcp://foo.example.com:61616" />

  <!-- A POJO that implements the JMS message listener -->
  <bean id="simpleMessageListener" class="com.mycompany.SimpleMessageListener">

  <!-- The Spring message listener container configuration -->
  <jms:listener-container
      container-type="default"
      connection-factory="connectionFactory"
      acknowledge="auto">
    <jms:listener destination="TEST.FOO" ref="simpleMessageListener" method="onMessage" />
  </jms:listener-container>
</beans>

For folks who are already familiar with the Spring Framework, the XML above is quite straightforward. It defines a connection factory bean for ActiveMQ, a message listener bean and the Spring listener-container. Notice that the jms:listener contains the destination name and not the listener-container. This level of separation is important because it means that the listener-container is not tied to any destination, only the jms:listener is. You can define as many jms:listener elements as is necessary for your application and the container will handle them all.

Below is the message listener implementation:


import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;

import org.apache.log4j.Logger;

public class MyMessageListener implements MessageListener {

  private static final Logger LOG = Logger.getLogger(MyMessageListener.class);

  public void onMessage(Message message) {
      try {
       TextMessage msg = (TextMessage) message;
       LOG.info("Consumed message: " + msg.getText());
      } catch (JMSException e) {
          // TODO Auto-generated catch block
          e.printStackTrace();
      }
  }

}

The message listener implementation is deliberately simple as its only purpose is to demonstrate receiving the message and logging the payload of the message. Although this listener implements the javax.jms.MessageListener interface, there are a total of three options available for implementing a message listener to be used with the Spring DMLC:

The javax.jms.MessageListener - This is what was used in the example above. It is a standardized interface from the JMS spec but handling threading is up to you.
The Spring SessionAwareMessageListener - This is a Spring-specific interface the provides access to the JMS session object. This is very useful for request-response messaging. Just be aware that you must do your own exception handling (i.e., override the handleListenerException method so exceptions are not lost).
The Spring MessageListenerAdapter - This is a Spring-specific interface that allows for type-specific message handling. Use of this interface avoids any JMS-specific dependencies in your code.

So not only is the Spring message listener container easy to use, it is also full of options to adapt to many environments. And I've only focused on the DefaultMessageListenerContainer here, I have not talked about the SimpleMessageListenerContainer (SMLC) beyond a simple mention. At a high level the difference is that the SMLC is static and provides no support for transactions.

One very big advantage of the Spring message listener container is that this type of XML config can be used in a Java EE container, in a servlet container or stand alone. This same Spring application context will run in Weblogic, JBoss, Tomcat or in a stand alone Spring container. Furthermore, the Spring DMLC also works with just about any JMS compliant messaging middleware available. Just define a bean for the JMS connection factory for your MOM and possibly tweak a few properties on the listener-container and you can begin consuming messages from different MOMs.

I should also note that the XML configuration is certainly not a requirement either. You can go straight for the underlying Java classes in your own code if you wish. I've used each style in various situations, but to begin using the Spring DMLC in the shortest amount of time, I find the Spring XML application context the fastest.

Update: I have made all of the code for these examples available via a GitHub repo.

Chameleon

Terry Ryan — Mon, 09 Jan 2012 23:08:00 CST

Just because some skeptics are irrational about something, doesn't mean that they don't know they are being irrational. They know that if they gave the real reason for their resistance that people would find their objections unacceptable. In short if someone's reason for not accepting that your company should support the iPhone and invest in iOS apps is that they think "Apple users are obnoxious hipsters," they're going to get dismissed out of hand. They know it, so they resist by bringing up "the Evil Walled Garden" argument. If you are able to mount a solid case against the "Walled Garden" argument, they switch to opposing Apple because "Android hardware would be cheaper"

Now to be clear, I'm not saying any objection to Apple is irrational. I'm saying if you specifically are going to resist Apple in an honest business focused decision for the specific reason "Apple users are obnoxious hipsters," you are being irrational. I'm also not saying "the Evil Walled Garden" or "Android hardware is cheaper" are right or wrong arguments. I'm saying they can be rational arguments (with evidence and justificaiton) but that arguing those things without believing or weakly believing in them to cover up for an irrational objection is the problem here.

Scenario
I worked with a guy who stated "I don't believe in indices [in a relational database]."

I know. We can argue many things: what columns to index, clustered or unclustered, whether we should even be using relational databases... But we can all agree that if you are using relational databases at some point you need to use indices.

But that was this guy's beef. He resisted any sort of argument that he needed an index on any of his tables. He showed us articles that said "YOU DON'T HAVE TO USE INDEXES... on tables with many more writes than reads". When performance was effected by a lack of an index, he said the performance was acceptable. When performance was still an issue he went into a long diatribe about how hardware upgrades on the server side would make his performance issues go away in an acceptable timeframe.

Then we introduced ORM (object relational mapping) into the environment. He objected.... loudly. Why? "The performance tradeoffs are too great."

Clearly his issue with ORM wasn't really performance. He had no problem waiting for performance to be enhanced by hardware upgrades, which is itself kinda silly. And his acceptance of poor performing SQL was not because he hated indices. It was because his real resistance was based on something else.

What was that real reason? I don't know but I have my theories. (I became much friendlier with him later, and it never came up.) I think in general the truth had more to do with trying to limit the number of new technologies and techniques so that he could keep a handle on the environment as he was also doing a fair amount of managerial, administrative, and business work as well. When you're stretched so thin, you have to figure out a way to contain complexity. But that's just my theory.

Ultimately his real reason doesn't matter. Because like all of the Irrational types, you should ignore them.

It's tough though, because these guys masquerade as rational types before you realize what's going on. So how do you spot them?

A few signs:

Drastically changing objections, did these guys start out as Burned, and then change to Time Crunched when confronted with evidence?
Dramatic reversals of objections raised in previous discussions, did they go from indifference to performance to performance being the only thing?
Being a Chameleon in the past, if they have done this to you before, and you haven't figured out a root cause then it is likely that they are repeating.

In general these guys and gals suck. They waste a lot of time because you are fooled into arguing with them rationally since they act rational. But if you suspect you're face to face with a chameleon: cut your losses - move on to try and convert someone else. Either they are Irrational, and you saved yourself some grief, or they aren't, but they'll be easier to bring around with more converts on your side.

A Custom Textarea for Finicky in HTML5

Terry Ryan — Mon, 09 Jan 2012 14:17:00 CST

I'm doing more work on bringing Finicky to HTML. Another interface that I wanted to reproduce was a custom input for note fields. It's basically a hand-drawn top and bottom to user editable notes with a hand writing font. As you fill the notes, the area expands and the bottom moves with the expansion. It's another cool UI tweak that my designer came up with that I want to honor in this version.

My first pass at it tried to use border images to fill the images as border-top and border-bottom on a textarea. I had one giant problem with that: CSS Border images are very unsupported. I couldn't get them to work on Chrome, and they don't appear to be accessible on a lot of browsers yet including the mobile browsers I am targeting.

My next pass was using a textarea. I got a little further along, but textareas are static. They don't expand to fit the content. In fact, that's sort of the opposite of their intent. They are supposed to stay static to accommodate large amounts of content. I'm sure I could do something with JavaScript to make that happen, but I hate doing that. No rational reason for that. I just feel that every time I use JavaScript to handle a display/style issue, I die a little on the inside. If I can do it in CSS, so be it.

My next attempt used the new HTML5 attribute "contenteditable." Contenteditable basically says that the content in a given element is editable by the user. This means that I can just create a div that is user editable. The div has the added benefit of being able to dynamically resize itself when new content comes in. This is exactly what I am looking for.

It works perfectly until I actually go to use it in my mobile app. Surprise, surprise, contenteditable isn't supported on Android yet.

So it's back to textarea and JavaScript manipulation. (And a little piece of me dies.) There is a jQuery plugin that will make a text area expand with more content, but it seemed a little heavy since I'm not using jQuery in this application. The basic method is pretty straightforward:

Create a placeholder for a mirror of the textarea content
Create a function for onkeyup for the textarea that:
- Sets the mirror content to be the content of the textarea
- Grabs the height of the mirror
- Sets the textarea height to that height

Code snippet - HTML for textarea post on Snipplr

Code snippet - JavaScript for textarea post on Snipplr

The basic solution is spelled out in this post on the textArea jQuery Plugin.

I went one step further and created a CSS transition that smooths out the height change of the textarea.

Code snippet - CSS for textarea post on Snipplr

That's a long road to getting it done, but it works. Here's a working demo of it.

Circular Button with Photo Mask Using CSS

Terry Ryan — Fri, 06 Jan 2012 15:23:00 CST

I'm currently working on porting Finicky over to HTML5 as a training exercise for building real applications (as opposed to more demoware) with HTML5 for mobile. It's going fairly well, but there was one piece of UI that I was really worried about. It was a little complicated to render in ActionScript, and I feared it might be impossible in HTML. In fact it's one of the few things I found much easier.

On the edit page there is a button for prompting you to take a picture of an item that you want to save. When you haven't taken a picture, you see a little camera icon on the button. When you have already selected an image, you see a circular mask of the picture inside a circular frame created by the button. Look at the picture; it's a lot easier to show than to explain. My designer really did a cool job there on that piece of UI, and I wanted to replicate it.

My first instinct should have been to look up "css mask" as it would probably be the easiest way if it was implemented. I didn't. I instead went with using border radius to shape my button into a perfect circle and positioning it on top of the original button. In reviewing information on CSS Masking, I don't think it would be the perfect solution. The images that I'll be using in my final product are going to come from source images of different sizes. My method allows me to drop in any size/proportioned image into the background-image CSS property of my link and have it still work as a perfect circle. However, my research there makes me want to explore CSS masks more.

Anyway, back to the main point, how did I accomplish this?

First, I make an a link that I'll use an a as the interactive part of the UI, as well as the holder for my picture. And I'll wrap it in a div that will hold the button graphics.

Code snippet - Circular Button in CSS - HTML on Snipplr

I give the containing div a background-image containing the button graphic and I hard set the size to match the image size.

Code snippet - Circular Button in CSS - Wrapper on Snipplr

Once the container is done, I turn the a link into a circle by giving it a border radius of 50% of the height and width of the element. (I also used a background-color to see where I was putting it. )

Code snippet - Circular Button in CSS - CSS for link on Snipplr

Then I set the positioning to relative, to offset it within the containing div. I then fiddled with the top and left until the circle link was pretty equidistant from all sides of the containing div. It wasn't just straight math because the drop shadow in the graphic made the blue circle of the button not completely in the center of the png file.

Finally I made a class with the picture I wanted to place in the background-image of the button.

Couple things to note here:

I hard coded the CSS for demonstration purposes, in my app, I'll just add the background-image dynamically via the DOM.
This, like all awesome things, won't work in versions of IE earlier than 9.
However, it has much more support than using masks, so I think it also wins on that account.

Here's a demo with the full source.

CSS Tables and Responsive Design

Terry Ryan — Wed, 04 Jan 2012 15:29:00 CST

It's been more than a decade since the call to abolish table-based layouts was started. Many, if not most, designers and developers have come over to the CSS way of doing things (or at least doing it most of the time while occasionally resorting to a table layout when they couldn't get the CSS to work.) Mixed in with the pragmatic use of tables is the occasional person pointing out the advantages of table-based layouts.

Tables do things when laying out that CSS designs with floats and padding and negative margins haven't been able to duplicate with the same simplicity: dynamic grids, rows that are all the same height, and vertical centering. There are grid systems, and frameworks that have handled this problem for awhile but they have their warts. CSS-based tables are a good solution to this problem, and have a lot of other benefits. But even then I've heard angst about CSS-based solutions (frameworks or CSS tables) basically being the same amount of work and angst as a table for the same result.

Here's a colleague (Greg Rewis) of mine complaining about the main angst of all of these solutions:

@garazi: Okay, CSS Grids, can we just go back to tables...?! I mean, really?! #nodiff

On the other hand objections to using tables are usually based on semantics, SEO, and accessibility:

tables are for tabular data
tables in layout are incredibly hard for screen readers to deal with
table markup adds a lot of cruft to markup

The problem with these issues is that for many people they just aren't compelling enough. Correct semantics is a lofty goal, but it's not a goal that clients care about. Accessibility takes a back seat because most of us never bother to fire up a screen reader. Cruft is usually seen as bad, there are other ways to improve page performance and SEO, so this argument sometimes helps but not enough.

Therefore, I've added a new reason not to use tables focusing on the current zeitgeist around responsive design:

Once you go table, you cannot go back.

Once you wrap your stuff in tables you cede a lot of control of the presentation to the browser. And most browsers don't linearize info in a table well because by wrapping it in table markup, you've effectively said "don't linearize this content". So if you are going to display this info on a mobile device with a smaller width you get scrunched content that is hard to read. Either that, or the mobile browser keeps it wide, but allows you to horizontally scroll, which as you know is a fate worse than death.

Live Demo: Table Design

Your first attempt to deal with this is to handle this with floats and padding and whatnot. You set everything to float left, so when the screen contracts, things slip under each other. This works very well if you know or hard-set the dimensions of your content beforehand. Otherwise you end up with weird outcomes and odd configurations of your grid. Even if it does work well, typically you've needed to add extra structural markup to make it work. Adding the cruft that not doing tables was supposed to take away. And it's all div's so it gets hard to keep track of where you are.

Live Demo: Float Design

Ideally, you want something that acts like a table when you have a wide screen and acts like simple block divs when you are on a small screen. So you take some good semantic HTML, combine it with CSS tables and boom, you have a layout that acts like tables when you are wide, and acts linear when you are small. It also lacks the weird layout issues you get from floating.

Live Demo: CSS Table Design

There are issues with this approach as well. IE 7 and below doesn't support it. So that is something to contend with. I choose not to. In browsers that don't support this, it just looks like the linearized version, which I'm pretty cool with as it is suboptimal, not broken. I've also seen a weird issue with it not laying out things correctly when I resize the screen. (If you refresh after resizing, it draws it correctly.) Still tracking this down.