This is a short description of how I am using TSA to help my clients rebuild their web applications to become more flexible and to be built quicker.
I recently started working with a new client in Stockholm who needed to revamp their administrative dashboard for their customers (it's an ad network company). Currently they have a fairly classical Struts application which rebuilds the whole page on every click. The dashboard is very graph and chart intensive, whose graphics had been created by JFreeChart on the server.
The first things I would like to comment on here is the time it takes to make changes. Any change to any file results in a 15s. restart of the local Tomcat to see that it doesn't break anything immediately, and then the built WAR is ssh'ed over to the live system (where the large databases reside, which are not to be used for development but which is needed to see any non-trivial results), which takes about a minute. yes it's slow. Yes, I know. But that's the way it is.
Sometimes you have to restart the server on that side as well when hot deploy doesn't work properly, but that's life. It doesn't happen very often. However, just to see how a change looks on the server takes at least two minutes, possibly more, and that's not a long time, really. it's just that it breaks the concentration of the programmer.
What I did was to arrange with the person responsible for the Struts application (which, incidentally was both smarter and cooler than I was, having done quite a lot of server, demo scene and mobile coding and understood or clarified everything I came up with to talk about, something I really like and don't get enough of. Really :) and managed to get a couple of actions from the server which only returned XML. Naturally we talked a bit of the content, but it was fairly quickly sorted out.
Then I copied the output
of each action and saved to a local file under a directory I called "mock-server". The I made a custom Dojo widget for each action, to massage and dress up the data as need be, which used "Ajax" to read the file from the local directory instead, but which used a parameters to set the url, so it would be simple to change when in production.
The point I'm being very long-winded in making, is that I can now make any number of changes to my widget, using real(ish) data, without breaking my concentration. Also, local page reloads are about as fast as you get when it comes to turn-around time.
What happened at the same time was that there was no way that changes to the server, a reboot of the dev environment, et.c. would bother me in the least. Also, any changes I doodle with locally have no impact on any testing going on, _and_ we just agreed upon a protocol to use, instead of an API, which is much more flexible.
Consider that one of their customers would like to use the data that we use to create Grid tables directly and pipe it into their SOA framework. Go ahead. it's already there. And it took us all of fifteen minutes to agree upon and document it. We have also separated the View from the rest of the logic and put the View on the client (in the browser), which makes things *snappy*.
One of the components was a customized Dojo grid with some formatters for pictures and links, and the other was a fairly large wrapper for several types of chart (You have to look up the Charting API examples in Dojo 1.x, they're simply stunning), and all I get from the Struts server is XML. So I just shrunk the server a bit.
What happens here is that you get separation of concerns at a very basic and natural level, you get quicker coding for at least parts of the system, and you get a authenticated XML feed of the most important data in the system, ready to pour into an enterprise bus or what have you.
Anyway I have a gazillion other things to juggle before falling asleep, Just two quick points;
1) If you're in Sweden, don't forget next Web Monday the 1st of April!
2) I'm going to Google I/O 28/29 May in San Fransisco! Yay!!!! :) Possible with the whole family as well. If you're going to be there, drop me a line and well meet up for a beer.