Lately I've been working on ever more complex systems, particularly layered systems, and it has led me to start looking at system approaches that I haven't had room or reason to look at in the past. In particular, messaging has caught my eye. My company is still extremely small, and most of our applications do fine within the two-phase commit model used by Zope's transaction manager, or the transaction manager of our own D4 (Dynamic, Declarative, Data-driven) based framework, but there are some applications that are already chafing under these loads. Primarily, it's applications that depend on far away services outside of our control that have had the most issues, and required a lot of patchy resources to get around the problems.
A book that I've glanced at on occasion is Gregor Hohpe's Enterprise Application Integration Patterns. When I first saw it and glanced through the diagrams, I was overwhelmed by the messaging architectures put forth. None of my systems had any sort of requirement like that yet. Most of the enterprise application integration I've done to this point has been along the lines of integrating new web based applications for large organizations with their larger corporate databases. But for some reason, and perhaps it's just that "it's a new year, it's time to learn a new technology!" bug that bites some of us, now I'm starting to understand the (potential) importance of messaging.
What really interested me was Gregor's post, Starbucks Does Not Use Two-Phase Commit. In that post he uses the typical Starbucks interaction to describe an asynchronous messaging scenario, and also goes in to exception handling in such scenarios (not only in Starbucks, but in other entities as well). I found the post informative, and it's helping my mind break out of the mold that it's been in for the last eight to ten years. And to be honest, that mold has worked quite fine most of the time. I just have a feeling that it's one that my company is going to have to break out of over the upcoming year. Based on recent conversations in house, it's obvious that our brains aren't quite wired to handle asynchronous messaging yet. I think a lot of that has to do with exception handling, however, and Gregor's post casts light on scenarios that come and go in conversations that we've never battened down.
Paul Everitt cleans his office and finds this gem: Principia 1.5 on a Floppy. Principia was Zope before it was Zope.
I don't even have a floppy drive, so I can't tell exactly what's on it. It's crazy to think, though, that someone could make an application server that would fit in 1.44 Mb. With an object database.Indeed. In fact, I seem to remember jokes around the office that the installation was too small to actually be taken seriously. Yet we did some very serious applications on that sucker.
Holidays are obviously a time of reflection and excessive sentimentality. It's fun to think back on where our office was then, the people that were there, and the absolute, utter lack of realization for what was to happen in the next few years.It was a very fun time and I find myself missing it off and on. The people, the old Princess Anne street building, the sounds of "Hey buddy?!" "Yeah buddy?!" going back and forth between the offices of Jim Fulton and Paul, or suddenly hearing Jim sing out "Superuser!"
This also means that I've been working on Zope/Principia for over seven years now. And working with Bobo / BoboPOS (now Zope's ZPublisher and ZODB, respectively) for nearly eight. Wow. I imagine only Rob, Paul, Jim, Brian, and a very small handful of people (many of whom ended up working with/for DC/ZC) have been using them consistently for longer than I have. I remember the day I first really used Bobo to port a Python application I had written to the web. I was able to do it in a day, and half of that was spent making really pretty templates. I was amazed and felt almost guilty.
VoodooPad 2.0 post-mortem: "Gus Mueller wrote a VoodooPad 2.0 post-mortem. I love stuff like this and wish more programmers would write about writing their software."
(Via inessential.com.)
Part of me wants to comment on the VoodooPad 2.0 post-mortem itself - namely the authors dropping of outliner support. There are no good collaborative outliners that I know of on Mac OS X, and when thinking through a project, it's just how I like to think. Also, while NotePad is a good outline database, it differs from the more free form associative structure that VoodooPad and DevonThink have. And while DevonThink claims outliner capabilities, it's difficult to reorder entries in the same level, and has neither the speed nor intuitiveness of OmniOutliner or NoteBook when used in outline mode.
There are a lot of great applications out there for Mac OS X right now, but no single application does quite enough for what I want. And I don't mind that, per se. I like the concept of small applications that do one or two things well than applications that do a lot of things poorly. But I still lament the death of OpenDoc. It would be cool to use the search and categorization features of DevonThink while being able to use OmniOutliner or OmniGraffle documents inside the system.
But what I really wanted to mention, briefly, is project post-mortems. It's been a long time since I've done one, or taken part in one, but they are great things to do after a project. When done personally, it's just interesting to introspect what was done and what wasn't done and why. And in a group environment, it's just as interesting if not more so. Of course it's all moot if notes aren't taken and points aren't remembered. It's also interesting to sit in on post-mortems of other company projects in order to see what worked and what didn't. It's also interesting to look at non-technical issues, such as ones related to how the project was run: How much time was spent communicating with the customer, how was it done, who did it? Was it budgeted properly? For projects of similar scope, would it benefit the project to have more non-technical help? Did management interfere too much with developers, or not help enough? What issues arose out of the contract? And so on and so on. Too often (my own little company included), we seem to always be running. Even before one project ends, another baton is handed to us and there's seldom time to evaluate what worked, what didn't, etc.
Posted on AlterNet: The P.U.-litzer Prizes For 2004: There are media awards of all kinds, but none so foul and smelly as these.
Merrily merrily I stay away from big media these days. I have no expectations of it any more, and these awards (the 13th annual) remind me why.
Recently, I wrote about integrating two different Zope 2 projects (both developed in-house) together. I finished that integration today - at least the primary functionality. Now I can start adding new features that actually take advantage of both systems, should the need arise.
As I was wrapping up today's work, appreciative of the component architecture stylings of each system, I started yearning again for Zope 3. Zope X3 3.0.0 is now released, but I fear it will be some time before I can start using it in earnest, given our current customer base and application state. Still, I thought, adapters and views would be nice technologies to have in each system, and especially in the bridge product.
And then tonight, I remembered Five, the Zope 3 in Zope 2 project. It's another interesting bridge project which allows use of some fundamental pieces of Zope 3's component architecture in Zope 2. Five is still a young project, but I hope to look into it soon. There are quite a few elements I've been implementing in half-form (or less) in recent projects that Zope 3 has and Five aims to bring to the Zope 2 world. This not only brings some nice tools to the Zope 2 developer, it should also start closing the gap between Zope 2 and Zope X3 by letting developers who choose to use it start migrating their applications and systems.