Craig Castelaz's Java blog looks at the relative importance we attach to polymorphism, inheritance and encapsulation. The comments on the post are mostly in agreement - with each other and with Craig - that encapsulation is the most important thing to think about when you're programming. Polymorphism is mostly an artifact of using interfaces in Java (for Craig and his readers) and inheritance is relegated to third place (composition is much more common than inheritance - see my earlier post about inheritance).
To paraphrase real estate then: encapsulation, encapsulation, encapsulation!

Brandon Purcell has posted a superbly useful utility that not only lets you browse all the components installed on a server but actually lets you invoke methods to test them. It builds on the cfcexplorer component that comes with CFMX and adds the ability to invoke individual methods and specifying arguments - all determined by introspection. It doesn't require a CF Admin password so be careful not to leave it lying around on a production server - but it should be extremely useful for development.

The official website has an FAQ that is focused more on "Why Mach II?" than on "How Do I...?" so Robby posted this functional FAQ on the Mach II forum. In the absence of an actual web page containing this information, this thread is a good reference.

It was interesting to see the (very!) mixed reactions to my post about leaving cf-talk because of the HTML issue but in view of some of the comments being made (and I deleted one particularly nasty one out of hand!), I've decided to follow Charlie Griefer's suggestion to remove the original post and post this update (on which you cannot comment, thank you very much!).
It seems people took my comments as some sort of personal attack on Michael Dinowitz which was not my intent (Judith and I discussed the issue at some length when I unsubscribed so Judith and Michael know it was nothing personal!). I know Michael will iron out the kinks in the handling of HTML and plain text on the list - I'd already told Judith that I'd see how things were working out in a month or so and might re-subscribe.
cf-talk's pretty high traffic so being unsubscribed gives me a bit more time to work on other things - I probably spent an hour or two every day reading and replying to cf-talk. Seeing that extra time, I decided to unsubscribe from flashcoders too, freeing up more time. I'm using that free time to work on Mach II documentation (and spend a bit more time with my wife!).

Robby @ OhSoGooey has a Mach II page that offers a number of filters for download. I haven't checked any of these out yet (although one is based on my RequestToEvent filter in the MachWiki application) but figured it was worth giving other Mach II developers a heads up about this resource!

Rob Brooks-Bilson has a great article on O'Reilly's ColdFusion Development center called Top Ten Tips for Developing ColdFusion Components. He recommends always providing an init() (good, although where he shows calling it in the pseudo-constructor won't work since his example requires an argument to be passed that is not available in the pseudo-constructor) and goes on to cover a number of other best practices. Essential reading!

Finally, everyone else can get their hands on what a few of us have been very excited about for a while: Macromedia Central is now in public beta! Mike Chambers has more to say about this in his blog but I'd urge you to install it and take it for a spin. Bear in mind that it's beta software so go and read the FAQ and other product information first!

A while back, Tim Bray wrote about XML being too hard for programmers. Not everyone agreed with him but there were some interesting comments in his original post.
Now Martin Fowler has effectively written that XSLT is too hard. Hopefully, this is a much less contentious position than Bray's because, if you ask me, XSLT isn't just hard, it's downright impenetrable! One of my team is our resident XML / XSLT expert and he can make XSLT do amazing things but it really does have a horrible syntax and, as Fowler says, some things are nigh-impossible to program purely in XSLT.
Fowler thinks scripting languages may help us here. He's using Ruby (which I'm not familiar with) to good effect. Whenever I need to work with XML, I jump into ColdFusion because it has good XML support and it's easy to work with.
What do people think - is XSLT viable or do you also jump into a scripting language of some sort when you need to manipulate XML?

Ray Camden's blog alerted me to this important new Macromedia Tech Note about names you cannot use for functions names. When you think how CFMX compiles code to Java, it makes sense that you can't define methods or functions that collide with the public members of the Java base class Object but I'm sure it's pretty frustrating if you get the error message and don't understand why.

The latest core files (1.0.6) are now available for download from the Mach II website. These fix all of the bugs that had been posted on my bug fixes and enhancements page. I've also posted an updated version of the MachWiki application. All the official sample applications have been updated so I'll be downloading ContactManager again and ensuring my anatomy page is accurate.

---

I've updated the anatomy page to reflect the latest version of the ContactManager application. I'd already account for the change of view in the XML to view-page in the event-handler and to page-view in the page-views definition section but I hadn't accounted for the addition of access="..." to the event-handlers.

Mike Chambers has just published an article on the Macromedia Developer Center which provides an update on Macromedia Central and talks about what folks can expect in the product after the various sneak peaks at different trade shows over the last year or so.
I think Central's a really promising application of Flash technology, providing a great end-user experience drawn from the vast pool of high-quality Flash application developers out there. I already use Central on a daily basis, even with just the few sample applications available (most of which have been demo'd at one or more trade shows). I'm excited about the possibilities once the development program is opened up publicly!

I've never been much of a fan of visiting doctors but my back problems have been getting worse so my wife finally dragged me along to a chiropractor, Dr Julie Orman in Oakland. She confirmed that I feel ancient sometimes for good reason: several vertebrae are out of alignment, my pelvis is crooked and I have four ribs that need adjustment. No wonder I literally can't get out of bed some days (fortunately that's only about once a year). The good news is: she thinks she can do quite a bit to help me so I start treatment next week. As an engineer, I'm fascinated by the human machine, especially the skeleton and the nervous system so I'm really looking forward to the treatment (and, of course, looking forward to any relief she can give me from the problems that have been ongoing - and getting steadily worse - for about 15 years!).

I have finally published the long-promised Release 3.0 of the ColdFusion MX Coding Guidelines. A couple of sections are untouched from last year's version but most of the document has had a substantial overhaul to bring it up to our current best practice. There's also a fledgling Mach II Development Guide - currently a 1.0draft - which I be updating substantially over the coming weeks. Feel free to leave comments here with feedback.

Sarah Allen comments on SBC Yahoo!'s use of Flash for creating a slick, single-page personalization center for managing your Yahoo! SBC portal page. This particular example is powered by the Laszlo Presentation Server which just serves to further validate both the ubiquity of the Flash Player and its suitability for delivering applications over the web.

After running various custom CF installs for a long time, I decided it was about time to create a couple of 'official' installs. So I now have vanilla installs of both CFMX 6.0 for J2EE (build 58096) and CFMX 6.1 for J2EE (build 63958) running side-by-side on Tomcat, on top of Apple's 1.4.1_01 JVM. There wasn't a huge difference in the installs, for the WAR deployment, but the speed difference is quite noticeable.
Mostly I've done this so that I can try code on clean installs of both versions when folks ask questions on various CF lists! I've got other installs I can use for my own development work (three installs of CFMX 6.1 that I'm using for Mach II work, for example!).

Various presentation and code examples are now available from the Fusebox 2003 conference website. Worth checking out, especially if you missed the conference!

Apple have just re-launched the 15" PowerBook. An upgraded case, faster processor, AirPort Extreme, backlit keyboard... Very nice!

The Macromedia Flash Remoting MX Components have been updated for Flash MX 2004.

I have just updated the Mach II bug fixes / enhancements page to reflect the 1.0.4 core files (which fix three reported bugs). I've also updated the MachWiki source code to match the 1.0.4 core files - although you still need to apply the Listener Access to Properties fix in order to use MachWiki!

Monday morning at the conference was dedicated to Mach II. Hal Helms and Ben Edwards presented a three hour session on the new framework with theory as well as practical applications.
Hal started with a background on why object-orientation is important and why, even if you're not planning to jump into OO today, you should be thinking about learning OO techniques. He focused on encapsulation as the most important of OO's PIE techniques (Polymorphism, Inheritance and Encapsulation). He also explained the concepts of tight cohesion and loose coupling (cohesion means a class does one job well which is a good thing; coupling means the dependence between classes which is a bad thing). It was a very compelling introduction to OO and I was pleased to hear him focus so heavily on good practice in design rather than any specific nuts and bolts issues. He quoted Buckminster Fuller at one point on the importance of elegance in design - if it isn't beautiful, it's wrong. He also focused on why inheritance should be used with caution: novices see inheritance "everywhere" and overuse it; composition is more common and more flexible (and more likely to be the correct design choice).
One of the hardest parts of moving to OO is learning to develop a good object model. Hal said you need to think in terms telling a story with a coherent narrative - write down the way your system works (at a business level). This will help you identify good candidates for classes (the 'nouns' in the story - and the methods on those classes are the 'verbs' in the story). In more formal OO design work, this story telling would be called Use Case Analysis.
Finally, on to the framework itself where they kept the nuts and bolts to a minimum except where they needed to explain code structure to support their examples. If you want more information, you can always read the Mach II website and my Mach II resources page. The framework is based on Implicit Invocation which can be a bit of a hard concept to swallow so I liked Hal's simple analogy: a website announces an event and people sign up for it (register interest in it) - when the event occurs, they all get notified and can process the information however they want.
It was very gratifying for me to see the 'buzz' that Mach II created amongst the Fuseboxers at the conference, with many keen to learn more about OO and expand their skills 'toolbox'. We should see a near-final code drop of the core files pretty soon.

CFers are still divided on Dreamweaver but an increasingly common complaint appears to be that they don't like having to buy Dreamweaver just to get HomeSite+ (the direct upgrade for ColdFusion Studio 5). Now that Dreamweaver MX 2004 ships with HomeSite+ 5.5, this issue is coming up again and, as Rafael Bleiweiss recently said on cf-talk "My true feeling it have HS be a full stand-alone thing again, at it's own fee, not bundled on any CD with anything else... I'd pay for regular upgrades."
So I figured I'd ask here on the blog - do you really want HS+ unbundled from Dreamweaver MX? CFS5 used to be $499. DWMX is only $399. Would you really want HS+ unbundled and sold at the original $499 price? What would you reasonably pay for upgrades to HS+ as a separate product? (The upgrade to DWMX 2004 from CFS5 is $199). Comments?

I got somewhat overtaken by work and then I was off sick for a couple of days so I didn't get around to blogging the rest of the sessions. Sorry. I'd got as far as Jeff Peters' "Fusedocs" session so next up was Charlie Arehart of New Atlanta touting the upcoming BlueDragon 3.1 release as an alternative platform for Fusebox 4. BlueDragon 3.1 will add the XML functions (already present in CFMX) that are necessary to support FB4.
After dinner, Michael Smith ran an interactive workshop on FLiP - the Fusebox Lifecycle Process. It was interesting to hear people talking about what didn't work for them in the real world and hearing suggestions for how to overcome these problems. That's always more productive than simply hearing why something is so great! I sat at the back and watched, mostly because I'm not very familiar with FLiP beyond what I've read in Nat & Jeff's book (about Fusebox 3, which includes a chapter on FLiP).
After that, it was the Fusepanel, which I was honored to be asked to join. The audience asked a lot of questions ranging from very Fusebox-related issues (which I deferred to Sandy Clark, Michael Smith and Steve Nelson) to more general design-related issues (where I found myself more in agreement with Steve than I would have expected!). There were also some specific Macromedia-related questions for me... I talked a little about how the product team had made a specific effort to optimize CFMX 6.1 for Fusebox applications (both existing Fusebox 3 applications and the then-nascent Fusebox 4 and Fusebox MX sample applications). I also encouraged the audience to submit articles about Fusebox to the Developer Center since Fusebox was currently unrepresented on macromedia.com.
I also acknowledged that we're using Mach II on some projects at Macromedia but couldn't say much about those yet... watch this space!

If you're running Windows, you should by now have become a regular visitor to the Windows Update website. Another three vulnerabilities were announced recently so our IT Support Center staff sent another email asking everyone to make sure their machines are up to date.
So why is this post in the OS X category? Because I think the recent torrent of Windows updates is just about the best advert for Mac OS X there could be...

The Developer Center has an excellent Logged In column that points you at important articles about the new MX 2004 products. These articles should get you up and running with all the great new features like "Relevant CSS" (Dreamweaver MX 2004), "Flash Screens" (Macromedia Flash MX 2004 Professional), "Gradients" (Fireworks MX 2004) etc.

Here it is... Studio MX 2004, Dreamweaver MX 2004, Fireworks MX 2004, Macromedia Flash MX 2004 and Macromedia Flash MX 2004 Professional. All available today!

This blog entry is getting a lot of traffic recently, especially from search engines. It is a FOUR YEAR OLD BLOG ENTRY! The Flash Player has been updated quite a bit since then and is currently (July 2007) at release 9.

If, like Connie below in the comments, you have old software that refuses to install when it detects the newer player, that is a bug is your old software since Flash Player 9 will happily play all of the content that was written for Flash Player 7. In fact, Flash Player 9 will play content written for any previous version of the player dating back many, many years.

If software - or a website - is refusing to work with a newer player then the software (or website) is at fault: it is incorrectly checking compatibility.

I've often berated people for using inheritance to 'reuse' code. I'm sure you've seen it too - someone finds a neat utility class that does something they need so they make their class extend it to gain access to that functionality. Sound familiar? But inheritance means "is-a". Extending some generic persistence class, DataStore, to make your Car class persistent is wrong: a Car is not a DataStore! Instead, create a CarStore (which "is-a" DataStore) and have CarStore be able to persist Car objects.
I've been threatening to write a treatise on this subject for a while but Allen Holub has written a wonderful piece that covers much of what I was going to say. He says "extends is evil" and, while that's going to push a lot of people's buttons, he's mostly arguing that you should be implementing interfaces instead of extending classes.
Allen followed up that article with "getters and setters are evil" which has already pushed buttons on TheServerSide. Again, he makes some very good points about designing for reuse and maintaining loose coupling between classes. The bottom line: slavishly providing getX() / setX() methods for all your instance data will buy you little but complexity!

Somehow, this blog-cum-wiki hybrid had escaped me until just the other day. For those who don't know, Martin Fowler is the godfather of refactoring - something we should all find time to do to our code to improve it. A couple of recent entries on his bliki struck a chord with me:

• TechnicalDebt talks about the price you pay later for bad design now (one of my mantras).
• BuildArchitect emphasizes the importance of involving engineers in the architecture phase of a project (to sanity check assumptions and decisions) as well as pointing out the potential problems with letting a UI designer plan out a website in isolation (another hobby horse of mine!).

There's a lot of good material in Martin's bliki - plenty of food for thought!

Taken from Robert C Martin's blog:

"Somebody went meta. Somebody, probably in the early 80's, decided that OO was really about creating models of real world structures. Perhaps they were embarrassed by the geeky origins of OO. Perhaps they needed to explain OO to the masses, or bosses. Whatever it was, the geeky origins were replaced with the meta-origins of modeling the real world.
And the industry bought it. The argument is just so reasonable. Bollucks, but reasonable. Nobody wants to think that the basis for modern software development has its roots in some geeky experiment about whether data structures are allocated on the stack or the heap. We are much more comfortable with the reasonable, yet completely untested, notion that OO is about modeling the real world. Earthly objects move towards Earth, Watery objects move towards Water..."

The whole article - on the danger of creating a buzzword bandwagon - is very interesting (and cautionary!) reading but this particular quote stood out. I'm not sure that I entirely I agree with him on every point - there's an element of the Emperor's New Clothes about some of the topics he is defending - but his basic point is worth remembering: buzzwords like "agile" and "XP" - and even "OO" - get overused and tend to escape the control of their originators. Most of all, I liked the quote above because he used (but misspelled) the gloriously English word "bollocks".

Fusedocs are an XML-based documentation standard for fuses that several automated tools have grown up around. Jeff Peters talked about how and why you should use them when writing Fusebox applications. The basic idea is that, before you start coding but after you have identified all your fuses, you write a structured comment at the top of each fuse file that explains to the programmer exactly what they need to know to write the code of the fuse - the "responsibilities" of the fuse (written in the first person singular - "I retrieve all the users in the system"), the properties of the fuse and the input / output parameters of the fuse (i.e., which variables it expects to be set on entry and what it sets on exit). As Jeff points out, this level of documentation "takes practice and discipline" but, as Steve Nelson has shown with his SecretAgents.com company, if you follow the process well enough then you can hand the Fusedocs out to 100 random programmers and have all your fuses written in parallel.
Steve reckons that his 'agents' write a fuse in around ten minutes for the most part but I can't help feeling it would take at least that long to write a decent Fusedoc so it's a tradeoff between the benefits of distributed "Software Done In A Day" (the SecretAgents.com tag line) and getting much of the code written in the time it would take to write the Fusedocs in the first place!
Personally, I feel that by the time you've broken your application down into such small bite-size pieces as fuses, you might as well just write the code and put a simple comment at the head of each file... but... well... there is also the tempting benefits of many of the Fusedocs related tools, such as the one that generates CF test harnesses for your fuses based solely on the Fusedocs. So I'm in two minds about that, when it comes to Fusebox.
Of course, I mostly program in an OO style, using MVC as the basis for my applications - hence my interest in and enthusiasm for Mach II - so Fusedocs in their current form simply don't apply to what I do. If a similar system grows up around Mach II, I'll have to re-evaluate whether I'd find it valuable. I lean much more toward 'self-documenting' code with well-chosen names for components and methods and variables - if it reads like English it can be its own documentation and it never gets out of sync with the code (because it is the code).

A very interesting announcement from Montara Software - .NET integration without COM. The soon-to-be-released software is called Black Knight which works with CF 4.x upwards.
According to Matt Liotta, CEO of Montara Software, this allows developers to create CFX tags using any .NET language without any performance degradation. I look forward to hearing reports from Windows developers who use this stuff...

Release 3.0 of the coding guidelines are currently going through their final internal review and I'll be publishing a non-Macromedia-specific variant of them fairly soon. The changes include breaking the very long document into half a dozen files, updating examples and recommendations to match CFMX 6.1, clarifying many of the recommendations (based on the number of questions received by email!), increasing the emphasis on CFCs and application structure, and rewriting the sections that cover locking, shared scopes and session management.

For me, this was probably the best session: not only did it cover the whole layout mechanism in detail but it also talked about standards compliance and accessibility. Very important topics!
Sandy Clark started out with an overview of layouts in general and drew a distinction between the application level (global navigation, site consistency) and the circuit level (side navigation etc). She showed how these can be implemented in Fusebox 4: application level layout can use global fuseactions (preprocess / postprocess) that invoke fuseactions in a layout circuit; circuit level layout can either use a plugin (which must check which circuit is active) or a circuit's prefuseaction (which requires clearly separating fuseactions into public and private circuits). Her presentation was very clear, with good code examples as well as good screen examples to illustrate each type of layout.
In the second half of her session, she focused on accessibility and standards compliance and used a free 'screen reader' application to dramatic effect to show how a site that uses HTML for layout (tables) instead of just for structural markup can be almost impossible to navigate for disabled users. She said we should use XHTML and CSS to separate structural markup from positioning and visual styling - to assist the "15-30% of the general population that have functional limtations that can affect their ability to use technology products" (from the Internet Society briefing on design). Having gotten our attention with this, she showed how Fusebox 4's 'content variables' help us keep content separate from presentation, allowing us to produce accessible websites much more easily.
As a final example, Sandy worked through the entire process of implementing a breadcrumb trail navigation element in Fusebox 4.
All in all, a high-content, high-value presentation and the highlight of the conference for me!

One of the problems that has plagued Fusebox in the past is that people tended to modify the core files of the framework to add various extensions like security etc. This undermines the whole purpose of a framework of course - a framework is supposed to provide a standard way of doing things! Fusebox 4 comes to the rescue by providing a plugin framework so that you can add your own code to the framework without touching the core files!
John Quarto-Tividar talked about how FB4 plugins work and gave some really good guidelines as to what should be a plugin:

• Is your extension applicable to all Fusebox applications? If so, consider submitting it for inclusion in the framework. Very few extensions are likely to fall into this category!
• Is your extension applicable just to a single action or maybe a few actions? If so, you can just implement it as a fuseaction and invoke it from the XML control file
  <do action="...">
  .
• Is your extension somewhere in between - applicable to a class of applications? If so, it's a good candidate for a plugin. Security is a good example of a class of plugins.

John also emphasized that each plugin should be atomic and cohesive, i.e., it should do a single job and do it well, independent of other code. He demonstrated a security plugin based on a list of access keys in the context of an office building and securing access to different rooms. It was an engaging demo and clearly showed the benefits of being able to easily extend the framework.
It should be noted that in Fusebox 4, each plugin is somewhat like a fuse - a simple file - that is called at a certain point in the processing of a fuseaction request. By contrast, in Mach II a plugin is a CFC which extends the framework's base and overrides the necessary methods - all of which are called by the framework for every plugin object registered. I prefer Mach II's approach but for folks comfortable with earlier Fusebox versions, the simple procedural approach of Fusebox 4 will be very natural.

Macromedia's MX 2004 products are all about letting you do great things, whatever you're into. See and hear what some of our customers are into and contribute your own story! It's a fun site, showing off the performance and video capabilities of Flash Player 7 (it'll help you install FP7 Beta if you don't have it yet).

Ironically, I didn't get to any of the three sessions yesterday (I was too tied up with 'interesting' problems to be able to make either 11am or 4pm PDT sessions and I had a dinner 'date' that meant I couldn't stay around for the 7pm either!). Reading Adam Howitt's blog it sounds like exactly what I expected it to be - a slick preview of the Macromedia Studio MX 2004 products which naturally focused on designers more than developers. Given how ambivalent many CFers are toward Dreamweaver, I'd be pretty surprised to see any enthusiasm for yesterday's previews among CFers. The fact that some comments on Adam's blog were enthusiastic about the new products is therefore very encouraging.
Yes, the 'big news' for Dreamweaver MX 2004 is CSS - Dreamweaver has always had good CSS support but MX 2004 brings this to a whole new level. Don't for one minute compare this to the CSS support in HomeSite / CF Studio and think you're comparing apples to apples! Also, contrary perhaps to the perception created by yesterday's previews, DWMX 2004 does bring new developer features that make CF developers' lives easier. True, they're incremental changes rather than a radical makeover but they're in there.
Macromedia Flash MX 2004, especially in the Professional edition, is a very impressive upgrade. The ease with which you can create animated effects and manage additional media types, the new ActionScript 2.0 programming language, enhanced editing, CSS for text fields (all in both editions). The Professional edition adds form-based application development with data connectivity and many advanced components and behaviors as well as support for team development.
Fireworks continues to grow and improve, adding numerous effects, improving performance, supporting team development. Fireworks is the unsung workhorse of the Macromedia Studio products, in my view. I use it for all sorts of image manipulation and creation but because it just works (and works well), it tends not to get as much glamor and praise as the other products. I'd hate to be without it.
ColdFusion developers need to remember that they just recently got a fairly major upgrade - ColdFusion MX 6.1 - and it was free! That brought enhanced performance, easier installation, several new features (e.g., super, additions to cfhttp and cfmail) and, yes, lots of bug fixes.

Today, Macromedia is demonstrating the new MX 2004 products to user groups around the world. The demonstrations will be broadcast using Breeze Live - but you need to attend your local, participating user group in person to see it. Support your local user group!

Hal gave a good overview of Fusebox 4, starting out by saying that although acceptance of Fusebox has increased over the last two years there had been no updates to the framework. He outlined the big changes (XML configuration files, plugins, content variables - instead of layouts, code parsing) but also said that many things don't change: fuseactions, circuits, fuses.
Hal explained how the XML to CFML compilation mechanism (which will also be able to target PHP etc) is the key to the performance improvements in FB4. Instead of the core files dynamically pulling together all the files needed to satisfy a request as happens in FB3, the XML in FB4 is translated to a single include file for each fuseaction that contains all the code needed to execute that fuseaction. The result is much less processing and much more speed.
Then he walked through the process of building a typical FB4 app: write the Fusedocs (same as for FB3), write the fuses (same as for FB3), write test harnesses (same), write for each circuit (new in FB4, replaces the files), write for the application (new in FB4, replaces the and files).
Migration from FB3 shouldn't be too hard and it brings many benefits, including better performance, better extensibility (plugins), more flexible layout (content variables), multiple fuseactions per request (like FuseQ which FB4 totally obsoletes)...

I figured I'd do an overview first and then blog detailed entries about the sessions.
Saturday night was the foosball ('Fuseball') tournament and networking evening. I didn't play (too wary of RSI) but it was good to hang out and chat with folks I'd only 'met' through email before. A fun 'Fusetag' game was organized for the weekend too - everyone got a sheet with everyone's name and a CF / Fusebox tag next to each; you also got name tags with your own <tag> on; the goal was to get as many folks to initial your sheet as possible. A good way to encourage networking!
Sunday was Fusebox 4 day. Hal gave a great overview across two sessions, followed by John Q talking about plugins (another two sessions). After lunch, Sandy Clark gave two sessions on layouts and writing standards compliant, accessible code (excellent stuff!). Then a session from Jeff Peters on Fusedocs followed by a session from Charlie Arehart about Blue Dragon (and he mostly managed to stay out of 'sales' mode!). After dinner, Michael Smith ran an interactive workshop on FLiP then we had an open Q&A session - the Fusepanel.
Monday morning was Mach II with a three-hour introduction to the architecture and framework, along with some live coding demos.
The highlights of the conference for me were Sandy's sessions on layouts (and, particularly, standards and accessibility) and the Fusepanel (because it was so interesting to hear from, and interact with, the Fusebox community for really the first time for me). It was also great to chat with Ben Edwards about Mach II and discuss possible enhancements and bug fixes.
I'll write up all the sessions, in order, over the next couple of days.

A full report will be posted in the next few days as I catch up on my notes. Sorry I didn't blog live from the conference but the room only had WebTV instead of a proper Internet connection so I wasn't going to pay $10 a day for that!
In summary, it was a great conference - really good to hear about Fusebox 4 and Mach II - really good to meet all the 'names' and talk turkey about frameworks etc.
I've posted some more Mach II bug fixes and an updated MachWiki sample application. Ben Edwards is busy integrating these code changes along with several other fixes and enhancements. Right now, I think MachWiki relies on some core file changes that haven't been made public yet - a new code drop is coming soon - and I'm in the process of making a slew of other changes. I'll blog more on this once everything has stabilized.