This behavior is described in Apple's pitch about Exposé but I didn't catch it until after I'd seen it in action. I think it deserves a little more attention.
At some point, when you have a bunch of windows open in a bunch of applications, hit F9 to activate exposé. Then use Alt-tab. Exposé remains active but the windows displayed narrow to only those for the application you've just tabbed to. Now tab to a different application and watch that app's windows take center stage. Nice touch, Apple!
Looks like I may no longer need the screen grooming habits that I've developed over the years. :)
State machines part six
David Geary presented an overview of JavaServer Faces at DJUG on Wednesday. I have to agree with his assessment that JavaServer Faces will be The Next Big Thing in java web app development. Interestingly, it looks like JSF will be notably similar to bOP.
JSF will be Java's answer to .NET and especially VisualStudio. Some of the big players in the Java world are going to put a lot of marketing muscle behind it. David mentioned that his book is going to be competing with a stunning number of JSF offerings. Many vendors want to sell you their IDEs. It seems the diversity in java's web framework ecosystem deters them from making web app magic happen in their tools. "Which framework should we support?" they ask. By blessing one framework the IDE vendors can focus their development resources on "The Standard". Just as the 1.4 logging APIs threaten to replace log4j, so will JSF threaten Struts, and all the rest of the java frameworks for that matter. Brace yourself for a tsunami of JSF hype.
In spite of the coming marketing storm, David showed off some good stuff. I welcome one change in particular. They borrow heavily from Struts, but have separated the concerns of site navigation from actions which change the state of the Model. Whereas, both of these things are handled with Action configurations in Struts, in JSF they are separated. In fact, the navigation configuration is yet another state transition table which will declare the flow through the application. The Actions get to focus just on changes in the state of the Model. This is one thing that I have missed from Turbine -- the navigation is separate from the actions which effect the model. That exact separation of concerns is also present in bOP.
David mentioned that there are places to declare the connection between a form and an object in the model. If he actually showed us that detail, I missed it. But he did mention repeatedly that JSF uses much more declarative programming. bivio brags about being declarative too.
What about the View?
JSF adds several stages in the life-cycle of a request. Some of those stages are specifically added to allow page widgets to trigger events. It allows you to "attach" server-side event listeners to those page widgets. They've done some pretty clever things to simulate a Swing-like event model while staying within the limits of HTTP. I'm sad to report that JSP still plays a central role. Taglibs provide some of the important hooks that help maintain the Swing-like look in the code. It looks like it will be hard to use other templating options with JSF -- the functionality provided by tag libraries for JSP would have to be replicated in Velocity or similar tools.
I'm not sure what to make of the move to Swingishness. See, I've drunk deeply from the templating kool-aid. I prefer Velocity to JSP for various reasons I won't go into here. When I wrote a little controller in perl for New Millennium, one of the key ingredients was HTML::Template -- it's not as cool as Velocity, but it let me separate the HTML from the controller.
Rob observes that templates make the same mistakes that old green screens did: mixing display codes with business logic and data. At first blush that sounds like JSP scriptlets. But I think Rob's assertion was more sweeping. Whether you're writing servlets with println()s or JSPs with scriptlets or concealing the scriptlets with tag libraries, there's a mixing "screen control characters" with logic and data. Velocity macros don't change that mix.
In bOP they use a Tk like language for defining the web pages. To the extent that Tk and Swing are similar, so is bOP's view language similar to JSF's stuff. Looking at David's examples for JSF helped me get my head around bOPs stuff a little more. bOP views assemble UI widgets into a hierarchy. I presume that bOP's facades are basically implementations of the language which render those widgets into HTML. I'm making educated guesses about what's going on behind the scenes. But I'm fascinated by the parallel development going on in JSF.
My feelings are still mixed. Rob's point about green screens is persuasive. But I'm just not quite ready to give up templating. Interestingly, bOP and JSF both seem to bring the web user interface back under the auspices of software development, perhaps taking it back from web designers. Maybe that's appropriate for web applications. It also seems like a natural progression for web apps. The GUI developers have worked through a lot of UI and usability issues in the past twenty years. Their toolkits look like Swing and Tk.
State machines part five
At the September meeting of frameworks-boulder Tom Vilot, an artist and a geek, presented bOP. Rob Nagler, President of bivio also showed up. Tom's personal website has interesting artwork. (I feel obliged to mention that there's some nudity -- exercise caution if you or anyone with a view of your screen is likely to be offended.) Tom's also got an interesting business that you might check out. I enjoyed his presentation of bOP.
The conversation with Rob afterwards was interesting enough that I ended up missing BJUG. Tom had explained that "bOP is written in very lispish perl". Rob added that it makes heavy use of closures which is part of what makes it lispish. I also saw some use of anonymous subroutines (lambdas in lisp) in the task configuration[1]. While talking about lisp and perl Rob asked if I'd read On Lisp? I've been reading it slowly for the past few months. Interesting timing. Most relevant for this conversation, a bOP application centers around a task configuration which happens to be a state transition table.
My intuition is ringing pretty loudly about this framework. I haven't worked with it at all, but while I've been looking more closely, everything I've seen aligns with all of this state machinery. Here's part of the example bOP Pet Store task configuration.
sub get_delegate_info {
my($proto) = @_;
return $proto->merge_task_info($proto->SUPER::get_delegate_info, [
...
[qw(
PRODUCTS
500
GENERAL
ANYBODY
Model.ProductList->execute_load_all_with_query
View.products
)],
[qw(
ITEM_SEARCH
501
GENERAL
ANYBODY
Model.ItemSearchList->execute_load_page
Model.ItemSearchListForm
View.search
next=CART
)],
[qw(
ITEMS
502
GENERAL
ANYBODY
Model.ItemList->execute_load_all_with_query
Model.ItemListForm
View.items
next=CART
)],
[qw(
ITEM_DETAIL
503
GENERAL
ANYBODY
Model.Item->execute_load_parent
Model.Inventory->execute_load_parent
Model.ItemForm
View.item
next=CART
)],
[qw(
CART
504
GENERAL
ANYBODY
Model.CartItemList->execute_load_all
Model.CartItemListForm
View.cart
next=CART
want_query=0
)],
[qw(
CHECKOUT
505
GENERAL
ANYBODY
Model.CartItemList->execute_load_all
View.checkout
)],
I don't know the mechanics behind it, but I'm really interested in the lines that declare a relationship between Model and View and a given state. It looks related to parts of the Ace Application Usage Specification. Both appear to be declaring relationships between the state machine and the Model, though Ace is quite a bit more verbose. Also, Ace is speculative research whereas bOP has been in production since 1999.
When I read Bob Martin's chapter on the state pattern, I immediately started imagining how that could be connected to a web app framework so I could get back to thinking about web apps like I used to with Tango. By all initial inspection, it's already implemented in bOP, and bivio's taken further steps to make the model and security connections also declarative. In fact, while explaining why you should consider bOP bivio uses language similar to what I was saying about Tango:
bOP's primary advantage is as an alternative model for web development. Application servers promote a page-centric model. bOP's task-centric model allows you to think in terms of operations, not output (results).
[1] anonymous subs are how you do closures in perl so these are probably the same thing.
slight diversion from State machines
For my undergraduate research project I tried to create some tools to generate three dimensional computer models of buildings (or whatever) from photographs. I used AutoLISP and let AutoCAD's graphics engine manage the user input and the display. My mentor was Mark Gross who among other things was an accomplished lisp hacker. I was hoping to teach myself Common Lisp after graduation, but was discouraged when Mark observed that languages, even programming languages, are grounded in a community. He said it would be hard to learn lisp in the absence of a lisp community. He was right. Before I finally admitted defeat I had bought CLTL2, Mark's suggestion, and On Lisp which I found for myself in the Fall of 1994.
Both books have collected dust on my bookshelf in the many years since. Every time I've moved since then I've considered getting rid of them, but each time I've felt my stomach uncomfortably tighten up. I couldn't do it. For just less than a decade I have been moving them and their dust from one place to the next.
My recent exploration of PyBlosxom has rekindled my interest in lisp because of the lambdas in its callback chain. I have been wanting to reconnect with what I used to know about functional programming, but had still not made the time. Then I blog-hopped my way to Paul Graham's article Hackers and Painters.
There on his site I found his page about On Lisp . The reviews quoted there are glowing. I went to Amazon to get other opinions which were even more glowing. I'm glad my intuition wouldn't let me get rid of it. In the past month I've finally cracked it open and have been slowly ploughing my way through it.
It's a fairly short book, but quite dense. I'm sure Paul would consider that flattery because he suggests that code should have just those qualities, short but dense. The reading is slow going. Most of the prose is brief explanations of what a code example is doing, or why you might want a utility to do that. But understanding the code and connecting it with the prose takes time and attention. And it's been a long time since I parsed parentheses.
Macros, creating languages, and other meta-programming. The discussion of closures and functions that return functions are quite illuminating. I've understood the what of closures for a long time. The Camel book explains them pretty clearly. But only now do I think I understand the why bother of closures. They're akin to lightweight objects with only one method. The variables closed within are encapsulated properties of the object. Lightweight and encapsulation are Good Things. Paul emphasizes how lisp invites the programmer to extend the language into their problem domain. Functions and macros that generate functions and macros are powerful tools. Another recent bloghopping session led me to Guy Steele's OOPSLA '98 inspired presentation on Growing a Language. Mark said something similar at the Sundance Lab in the early 90's: "sooner or later all programs want to become their own language."
All those lisp hackers have been pointing me in this direction, but only with some experience under my belt can I understand the wisdom. AutoLISP was trying to guide me in that direction too. Toward the end of my time working with Kim Veltman, the animation tools I had developed were becoming a language. I wasn't doing that in any intentional way. I was just gradually removing some of the repetition in creating the animations. As I sharpened my tools, there began to emerge an animation scripting language.
While developing Envoy, we were conscious of the force pulling towards a language. In fact we resisted that force, trying to expressly not write a language. But the requirements were really begging for it. Envoy administrators would create macros (think Excel macros, not lisp macros) to munge CAD data. There were pre-processing macros, format conversion macros, post-processing macros, and delivery macros. (I thought we needed a composite pattern -- macros of macros -- but was accused of more pattern zealotry). In spite of our efforts to avoid it we joked sarcastically that we had created a not-exactly-visual, distributed batch file system, about as impoverished a language as DOS. In spite of our sarcasm, it was actually pretty fun to build. Good lessons in concurrency and messaging among other things.
Is all programming meta-programming, just that some things are more obviously meta- than others? When test-firsting I write programs to test programs. It's not quite like functions that return functions, but there's something meta- about it. Test-driving often leads quickly to interfaces each of which is an API -- a micro language for communicating with an object. That's what Guy Steele's presentation was getting at, that good programming languages encourage growth in the language. The Ace project web site remarks that we don't write ones and zeros anymore, and very few write assembly. It boasts of being the next logical step in that progression of abstracting away another layer of implementation details. When Grady Booch spoke at DJUG he called it increasing layers of abstraction.
On Lisp's theme of bottom-up programming is a metaphor for the profession as a whole. Programmers grow their tools from the root elements of lisp toward a domain specific language at the same time that the system is being decomposed from high level requirements into appropriately digestible chunks. Similarly, the programming's progression has been inside-out recursion. Instead of working in from the outer lists down to the atoms, those who went before wrote in atoms and in each decade those elements have been wrapped it in a higher level list.
Heh heh heh. I'm not even half-way through this book and I've already connected it to the programming profession as a whole. Consider that another strong recommendation. :)
The plate 'o shrimp phenomenon from Repo Man
Miller : A lot o' people don't realize what's really going on. They view life as a bunch o' unconnected incidents 'n things. They don't realize that there's this, like, lattice o' coincidence that lays on top o' everything. Give you an example; show you what I mean: suppose you're thinkin' about a plate o' shrimp. Suddenly someone'll say, like, plate, or shrimp, or plate o' shrimp out of the blue, no explanation. No point in lookin' for one, either. It's all part of a cosmic unconsciousness.
Otto : You eat a lot of acid, Miller, back in the hippie days?
I like to pay attention to coincidence. If I notice a connection between otherwise random events, then there's something in that connection to examine more closely. Not necessarily because of a cosmic unconsciousness, it's probably all just randomness. But if my brain draws a connection, then there's something inside me that establishes a relationship between those events. It's like a window into my subconscious. For me, coincidence, déja vu, and intuitive zaps are all things that make me examine my experience more closely to see what pattern my brain is trying to draw to my attention. I have never been disappointed by the results of such reflection. And if there does happen to be a lattice 'o coincidence that lays on top o' everything, at least I'll be paying attention to what's really going on. ;)
I first saw Repo Man as a class requirement for "Psychology of Architecture" (pronounced "psycho architecture") which had earned a reputation for aggressive mind games (hence the pronunciation). I thrived in that class and came back as a teaching assistant for a couple semesters. Among the other required movies were The Last Wave , Batman , True Stories , Blade Runner , and the 1984 colorized restoration of Metropolis . That collection of movies was part of the appeal of the class for me.
State Machines part four
A couple weeks ago John mentioned that Craig Larman is one of his favorite authors. A link on Larman's site caught my eye: James Gosling has been working on the Ace project. No particular reason for that to get my attention, but it did. Trusting intuition I followed the link. After lots of effusive hype about how Ace is going to make programming easier (and maybe wash your dishes too :), the page briefly explains the how of it:
The key to the Ace technology is its mechanism for application specification. This Ace specification has been formulated to capture the precise and complete intent of the desired application while simultaneously excluding or hiding all of the possible implementation details.
I quote that paragraph mostly because it highlights that this is "the key to the Ace technology" and because hiding implementation details sounds remarkably similar to my description of Bob Martin's state machine compiler. The quote goes on:
The first half of an Ace specification is a description of the data which the application will manipulate, that is, its set of business objects. These business objects and their relationships are represented visually in a diagram. ...
The second half of an Ace specification is a description of how the application will manipulate that data, that is, its business process tasks. These business process tasks and their sequencing are represented visually in another diagram.
The business process diagram for the PurchaseOrder application is an unmistakable state transition diagram.
Given all the state machines on my brain I had to take a closer look. Sun Labs Ace Project has a more technical spin. Have a look at this Ace example code for an Application Usage Specification and compare that with Bob Martin's state machine compiler configuration.
State Machines part three
I've recently finished reading Agile Software Development cover to cover. I learned a ton. I can't recommend this book strongly enough. This goes on my list of must-haves along side Design Patterns , and Refactoring , and Effective Java .
Bob Martin Introduces the state pattern on page 419:
Finite state automata are among the most useful abstractions in the software arsenal. They provide a simple and elegant way to explore and define the behavior of a complex system. They also provide a powerful implementation strategy that is easy to understand and easy to modify. I use them at all levels of a system, from controlling the high-level GUI to the lowest-level communication protocols. They are almost universally applicable.
That dispelled any doubts I had about all those workflows . And it gave me insight about what made that Tango outline effective. Despite some tendency toward self-doubt, I trust my intuition when it gets insistent. But confirmation by external authorities gives me a warm, fuzzy feeling inside. :-)
Just as I was settling a little too deeply into my self-satisfaction, Bob mentioned his state machine compiler, available for free at Object Mentor . It humbled me. Create a state transition table and let the compiler pop out a bunch of state machine gears and cogs. What an excellent example of meta-programming (about which I'll have more to say). Moreover, a state transition table is an excellent way to think about the state pattern. The compiler allows me to work with the state machine at a conceptual level without having to get lost in the state pattern minutia. This is the kind of trick I just know is going to change the way I approach problems. This is leverage.
By the way, Larry, who recommended Agile Software Development to me, has just commented about using state charts to design user interfaces .
Update: Thought I should include an example of the SMC config file. This is the state transition table for a turnstyle from the SMC distribution. I think you can see at a glance how it spares you the state machine minutia.
Context Turnstylecontext // The Name Of The Context Class
Fsmname Turnstyle // The Name Of The Fsm To Create
Initial Locked // The Name Of The Initial State
// For C++ Output
Pragma Header Tscontext.H // The Header File Name For The Context Class
{
Locked
{
Coin Unlocked Unlock
Pass Locked Alarm
}
Unlocked
{
Coin Unlocked Thankyou
Pass Locked Lock
}
}
Jeremy Allaire has stirred up some buzz. There's one point about this RSS-Data I don't think has been made.
There's all sorts of hype and excitement about other applications for RSS, but what we have right now is mostly vaporware. The blogsphere certainly proves the utility of RSS, but other applications are at most speculative. Introducing a low-threshold format for publish-subscribe exchanges of objects could be just the ticket to get some real application development rolling. As real applications appear and crystalize, then schemas can be formalized for those applications.
If you haven't already been following the discussion here's what I've read:
Les' examples are good for discussion. On the surface it looks like solid argument against Jeremy's suggestion. But despite the verbosity, I think the ability to get on with the applications is the important part. I think Jeremy's idea will grease those wheels.
I pushed really hard to get VisionLink to move off of FileMaker Pro and onto PostgreSQL, though any SQL database would have made me happier. After a lot of back an forth it became clear that they were not going to budge. It also became clear that I couldn't stand to work with FileMaker Pro any longer. That's ultimately why I left in the Spring of 2000. I was convinced that they were using the wrong technology and I was tired of having to work around it. More importantly I felt stifled and claustrophobic in my professional development. It was a pretty hard choice to make because I really liked my coworkers and really believed in the company and in the products. I still do, actually.
The job with Spacial (later PlanetCAD) was all that I could have asked for professionally. Right off the bat I was thrown into a project using PHP and MySQL on a linux box. I did my development in emacs. I introduced the use of version control for web apps. I also spent some time helping to automate the importation of an XML news feed. A little bit of cron, perl, XSLT, and a python module for zope. And then they decided to move everything we were working on to Java and Oracle. That led to Turbine and other Jakarta goodies. I couldn't ask for more...
... except for the fact that the company was in an irrecoverable tailspin. In addition to all the cool technical things I learned along the way I learned many negative examples about business. PlanetCAD had the right technology. But it completely failed as a business. Every decision was a foolish gamble striving to recover ten-to-one returns for the investors to make up for what they had been loosing. Over the same period .coms were crashing all over the place. The wreckage was profound.
VisionLink powered right along. Part of that has to do with their customers. The non-profit business ecosystem runs under different cycles than the commercial world. I'll take a fair bit of credit for some of the technical suggestions they did adopt. They agreed to move to an ASP business model. When I started, a significant chunk of my work was managing the servers which were installed remotely at the client's ISPs. Before we began gradually pulling them back into our own house there were probably twenty-five servers I was managing through Timbuktu. At the same time we were replacing the remote servers with our local server farm, we modified the code to work under virtual hosting -- supporting more than one community on a single piece of hardware. With all the servers relocated it was easy to throw hardware at the problem when a community outgrew their little slice of a server. The communities that outgrew their systems would get moved onto dedicated and spiffy new hardware.
But given the lessons at PlanetCAD and the accompanying hail of dot bombs, the lion's share of VisionLink's success has to go to their business savvy. They paid careful attention to maintaining excellent customer support and building relationships with their customers. That was a real business priority and not just rhetoric or marketing. They kept expanding the revenue stream in sensible ways and made sure those revenues covered salaries, rent, long distance phone bills, the expense of the new hardware, and so on. And they made exactly the right decision to not change technology when I pushed so hard for it. The revenue stream wouldn't have supported the complete overhaul I was suggesting. And the customers were served just fine with FileMaker Pro on the back-end and regularly expanded hardware.
It's too bad that my professional development needs didn't match with VisionLink's business needs. But I'm glad we finally figured that out and went our separate ways. I'm pretty sure we are both better off for the change. And I'm happy for their continued success. If you happen to be involved in workforce development efforts or education reform you should look at the tools and services they offer. You can most definitely trust that you will be well served, and you can trust them to manage their business and not drive it into the ground. They will definitely be there as you grow.
State Machines part two
My life as a network administrator ended and life as a professional software developer started in 1997 when I moved back to Colorado and got a job with VisionLink . At the time, VisionLink used Tango and FileMaker Pro on PowerMac G3's for their web application (there was only one at the time). Tango has changed hands a number of times and now goes by the name WiTango .
Since leaving VisionLink I've worked with many other web application tools. PHP, Zope, the ArsDigita Community Server, perl and python cgis, Turbine, Velocity, Struts, JSP. Tango had one thing that all of those other technologies lack. The development tools encouraged you to think in terms of what the whole application was going to be doing rather than thinking one page at a time. I miss that way of thinking about web applications. It was like having an outline of the application up front. You still had to put the individual pages together but every page was inherently created in the context of the rest of the application. It was easy to see the relationship of the forrest and the trees.
Few people have even heard of Tango, much less developed an application of any complexity with it. It's hard to explain why it's a better way to think about the apps. Perhaps it's similar to making the leap from simple functional programming to recursive programming, or from procedural to object programming. Or the leap to using patterns. (I'm sure that aspect oriented programming will open up still more options if I can ever make the time for it.) It's all programming, but different modes of thinking about problems open up different solutions. For a given problem some modes of thinking are more effective than others. I think Tango had a better fit for thinking about web applications.
I have just recently learned to think of that "outline" as an application-level state machine.
Update: Looks like the WiTango Development Studio hasn't changed radically since my Tango days. There's a picture of the outline I've been talking about on that page. It's a tree widget with if...else branches and such. Those branches are at the application level, not the page level. If the user isn't logged in ... if action=save ... and so on. As opposed to if user has x permission then show y widget or other page logic.