On Friday, I fly to San Francisco, rent a car, drive to San Rafael, meet spouse who is already there, and then we’ll spend 6 glorious days moseying around the wilds of the Mendocino County and northern Marin coastlines.  Goodbye, work, for a while.  I predict there will be some kind of trip report!

Go see David.  Go see David.  Go see David.

Is there anything about “Go see David” that you don’t understand?  He’s a dynamic, intelligent and very, very informative speaker.  Hope to see you there!

Many of my speaking topics have to do with architecture, patterns, or some kind of preaching about best engineering practices. I love all that, but, to be completely frank, it feels a bit abstract and windy sometimes. I like to build concrete stuff that does something useful, and that’s where my real interests lie. (”Dammit, captain, I’m an engineer, not a methodologist…”) So this year I’ve made a pact with myself to only do talks about real live projects.

At 360 Flex I’ll be sharing a detailed case study of the architecture and implementation inside the most challenging and interesting product we’ve built at Allurent to date: the Allurent Display Platform. This system includes an engine that visually renders XML markup as Flex components — but unlike MXML or HTML, the markup resolves bindings to nonvisual data objects (usually products or product categories) that can live anywhere in a “virtual namespace” of content. Allurent Display also includes a fully-featured visual authoring tool for this markup similar to Flex Builder Design View.

This talk is a case study, not a product demo: I will be sharing the big decisions we made, the Flex or Flash technologies we used, the implementation tricks we had to resort to, the alternate approaches we considered (maybe the audience will propose something better). I think it’ll be a fun time. Anyway, hope to see you there, if this kind of thing interests you!

“The pain, the pain…”
– Jonathan Harris as Dr. Zachary Smith in the original Lost in Space

Dr. Smith was famous for whining, and so am I. Here’s my latest: Flex Builder does not work very well with multiple source folders in a project’s path. Probably the worst breakage is that integrated SVN source control (via the Subclipse plugin) doesn’t work inside them (FB-9989). Second worst would be that library projects can’t compile classes from multiple source folders (FB-9988). Yet another baddie: FB-5564: if you use Ctrl-click to navigate to a definition in a class which is in a linked source folder, a new window is opened unnecessarily, as if FB didn’t know that two files were actually the same. All this is too bad, because source folders are a really good solution to another serious problem with Flex Builder, and one that is probably harder for Adobe to fix: poor performance with multiple library projects.

If you’re using Flex Builder on some large applications with a number of library projects, you may have noticed it gets real slow. Yeah, I’ve noticed that too. It’s too bad, because using lots of small-to-medium libraries forces developers to be much more careful about dependencies between packages.

At Allurent, our approach to this problem has been to structure our Flex Builder projects for speed rather than strict dependency checking. We use Ant for all production builds (it builds multiple .swcs for dependency checking), while developers can use Flex Builder for incremental builds while they work on a project, if they want. To get around the big slowdown problem, we create mega-projects that include all the libraries’ source code directly via multiple source paths. While such projects are slow to open and start up, once you build them and warm up Eclipse’s caches they perform quite well.

The big fly in the jam jar — I know it’s usually ointment that metaphorical flies get stuck in, but that phrase gets kind of old, doesn’t it? — is that source folders are kind of semi-functional in Flex Builder. The fact that Subclipse doesn’t treat the contents of source folders as versioned (even if they are) is really frustrating. Maybe some folks out there are frustrated too. If you are please consider voting on the above bugs!

But today, courtesy of the New York Times, I read:

About five billion years from now, astronomers say, the Sun will run out of hydrogen fuel and swell temporarily more than 100 times in diameter into a so-called red giant, swallowing Mercury and Venus and dooming life on Earth, but perhaps not Earth itself. Astronomers are announcing that they have discovered a planet that seems to have survived the puffing up of its home star, suggesting there is some hope that Earth could survive the aging and swelling of the Sun.

So it appears that Earth may instead be destined for some kind of galactic curbside recycling bin.

If so, I think it would make sense for us to leave the planet in some kind of reasonable shape after all. You wouldn’t recycle filthy, unwashed food containers out on the street, where they would attract flies. Would you? No, I thought not. Likewise, you shouldn’t leave a nasty, polluted planet lying around the solar system where it might attract… well, I’m not sure what. Anyway, my plea stands: let’s clean this place up so it’s ready for recycling. We can do this any time in the next 5 billion years or so.

No, dear reader, I am not in fact coordinated enough to play Zelda or Wii Sports while pedaling furiously. (OK… make that semi-furiously.) What I am able to do is surf the web using the Wii’s built-in web browser, pointing and clicking the Wii Remote in one hand while maintaining pace and position on the bike. And this, from my point of view, is one very good reason to get hold of one of these gadgets. Now I can read a wide variety of stuff while doing my workout, and exercise free choice over it. That’s progress!

There are plenty of other reasons to check out the Wii. The remote (which has 6 degrees of free motion as well as buttons and internal accelerometers) is a really interesting input device, and it can interface via Bluetooth with a PC or Mac, and folks are coming out with some great homebrew hardware and software to provide connectivity for developers. Combine the remote with Flex, WiiFlash and Papervision3D, and suddenly you’re looking at an impressive 3D visualization platform. Hmmm…

Something amusing came up in the course of exploring script bridging: because JavaScript has the eval() function, and because AS3 objects are visible in an Apollo HTML DOM as fully fledged Javascript objects, one can easily use eval() in a Javascript context to evaluate live AS3 function calls, property assignments, and so on. Very, very nice!

For example,

<head>
<script>var obj;</script>
</head>

<body>
<input id="expr" type="text" size="80"/>
<a href="#" onClick="eval(document.getElementById('expr').value)">
  Evaluate
</a>
</body>

If you stuff this HTML into an HtmlControl, set that control’s window.obj to some AS3 object (say a Label for argument’s sake), then you can eval expressions like obj.setStyle(”fontFamily”, “Tahoma”) inside the HtmlControl and watch them take effect before your eyes. Should be a great debugging hack in Apollo.

If you’re in the FLEX_HOME/lib directory you can run it as follows:


java -classpath asc.jar;swfkit.jar flash.swf.tools.SwfxPrinter [options] swfFilename


Here’s a somewhat random excerpt from some output; this includes some Flash sprite definitions:

  <DefineSprite id='28'>
    <!-- sprite framecount=1 -->
    <PlaceObject2 idref='27' depth='2' matrix='t0,0'/>
    <ShowFrame/>
  </DefineSprite>
  <ScalingGrid idref='28' grid='(80,80),(1200,360)'/>

The valuable -showoffset option causes the output to include the offset and size of each element in the file. For instance, the following DefineFont3 element shows the size of an embedded font from a Flex CSS stylesheet:

  <!-- offset=86441 size=35356 -->
  <DefineFont3 id='112' font='Myriad' numGlyphs='232' italic='false' bold='false' ansi='false' wideOffsets='false' wideCodes='true' shiftJIS='false' langCode='0' hasLayout='true' ascent='17019' descent='5120' leading='614' kerningCount='0' codepointCount='232' advanceCount='232' boundsCount='232'>

Sadly, in a regular application SWF, there is no information about how the code is broken up; all you get is a single element representing the entire code of the application in a single lump:

  <!-- offset=291066 size=1338571 -->
  <DoABC2 name='frame2'>
  </DoABC2>

Not to worry. Far more useful are the results of using SwfxPrinter on the SWF that’s inside a SWC (just use any ZIP decompression tool to unpack library.swf from a SWC file). Now you’ll see information like this:

  <!-- offset=2130104 size=4192 -->
  <DoABC2 name='mx/effects/CompositeEffect'>
  </DoABC2>
  <!-- offset=2134296 size=670 -->
  <DoABC2 name='mx/effects/Parallel'>
  </DoABC2>
  <!-- offset=2134966 size=4111 -->
  <DoABC2 name='com/allurent/containers/AnimatedViewStack'>
  </DoABC2>

Now that’s more like it!

So… I’m in the process of writing an Apollo-based tool that analyzes SwfxPrinter dumps, along with the linkage dependency information found in a SWCs, and allows developers to analyze both code size, linkage dependencies and associated source code/documentation in a single environment. Granted, it would probably make more ultimate sense to do this as an Eclipse plugin alongside Flex Builder, but which would you rather do to read in swfx dumps: deal with the Java XML APIs or hack some E4X? Also a lot of the analyzed information is easy to display in HTML, and Apollo has that nice built-in web browser.

Here’s a screen shot of some work in progress:

One can use a tool like this to find out exactly how much space each individual class or package in the application takes up, and use that to tune its space requirements, Module loading strategy, and so on — this takes a lot of work, of course, but it’s a lot easier with the right information at one’s fingertips.

I’m thinking about the dependency-analysis angle. My current thought is to support two complementary approaches: 1) discover what other classes a given class/package depends on (and thus drags into the SWF), and 2) discover which dependencies caused the inclusion of a given class/package in the SWF. The first approach is useful when one has a good heuristic notion about what should be separated out (like a complex but rarely displayed view). The second is useful when you can see a large bunch of code and you’d like to understand what other stuff is using it, so you can separate out that stuff and avoid dragging the expensive code into the SWF up front. Either way, you identify candidate classes for modification, removal, or placement in a loadable module, in the name of a smaller download size.

Note: A somewhat more convenient way to run SwfxPrinter is to just copy this swfxprinter.jar file into FLEX_HOME/lib; then you can run it in any directory as follows:


java -jar %FLEX_HOME%/lib/swfxprinter.jar [options] swfFilename


(I’m not redistributing any Adobe code here of course; the JAR file just contains a manifest with references to class and library names.)

Some links:

• CSRF exploits and crossdomain.xml
• Death of open crossdomain.xml’s?
• YouTube, crossdomain

Possibly due to an exploit, they abruptly changed their crossdomain.xml file to only allow access from the youtube.com domain. As a result, YouTube developer API calls from Flash no longer work if the SWF was downloaded from a non-youtube.com domain. This broke a few aspects of ReviewTube that used that API.

I quickly got around the problem by proxying the YouTube requests through my own web server. Recall that ReviewTube was created to demonstrate an architecture for remote Flex applications. Well, in a validation of that architecture, it took changes to about 3 lines in 3 source files to make this change. Two changes were to code in the Service layer, and one change was to the component configuration file. (Full disclosure: also about 10 new lines of Rails code on the server side to do the proxying.)

So… we’re back live.

YouTube, if you want to be safe and not screw up Flash/Flex developers, please move your API to a different domain and put a liberal crossdomain.xml on that host. Thanks.

After a very hearty breakfast, and futile attempts to dry our wet gear from last night, we packed up our tents and gear and prepared to leave. The hail from last night was still lying on the ground, a reminder of what we might expect at any time from the fickle mountain skies.

We set off down the East Fork Trail which began in a soggy meadow right outside the campground, and smiles began to break out. After a messy, muddy climb up a rise, the trail topped out on a grassy hill and began to descend in a series of sunny open alpine meadows alternating with rocky, rooty alcoves of cool spruce and fir. The East Fork of the Dolores River roared unseen, far below us on our right; further right across the valley was a steep rock wall with forest above and below. The trail swooped up, down, and around, with tricky biker-unfriendly water bars to spice up our ride. I did a graceful, super-low-speed endo after jumping a water bar only to trap my wheel behind a small rock 2 feet beyond it; fortunately I caught the bike before it could start tumbling down towards the river! It was a little object lesson in the ways of my rental bike, which was 1.5″ shorter than my usual machine: the front wheel was closer to my body, and I was going to have to take account of an increased propensity for nose wheelies and endos by sitting further back.

I felt energetic at first but after a lot of East Fork swooping, I did begin to tire and start to walk some of the steeper climbs; the altitude was getting to me again. We arrived at the midpoint of our ride soon after that, a trail intersection in an open glade with a small creek running through it. We were all grinning, because this was the kind of riding and scenery we had come for, and the weather was cooperating.

The remainder of that ride was a steep fire-road climb of some 5 miles. Even though it was a lot steeper than the initial day on the Galloping Goose, the knowledge that it was shorter, my increasing adaptation to the altitude and the fine weather all contributed to making it a pleasant leg of the trip. As we ascended towards Bolam Pass at 11,000 feet, the scenery slowly morphed around us. Open spaces with brilliant wildflowers became more frequent. The air, cool to start with, became cooler. After about 90 minutes or so, we reached the pass and coasted down another 1/2 mile or so to our beautiful campsite beneath the pines. The truck was there, and the rain canopy had been erected just in time as the skies suddenly cut loose with more hail and rain and the temperatures plummeted from the 70s to the 40s. I picked a campsite, and started to set up my tent.

And that was when I discovered that I had left my dry bag full of all my gear back at Lizard Head Pass.

Mortified, I told Rachel and Scott. They weren’t angry, but obviously they weren’t terribly happy either — Lizard Head was a long, long way away by road. Biking back there to get it was out of the question; the dry bag was enormous. I checked every dry bag, but there was no question. I clearly remembered leaving my dry bag at my tent site at last night’s camping spot. Fortunately I had a day pack with a complete change of clothing, down jacket, and fleece hat, so I didn’t have to freeze in my biking clothes, and there was a spare sleeping pad and bag on hand. Worst come to worst, I’d do the rest of the trip with only two sets of clothes.

Scott already had an unpleasant driving errand on his hands: after several reversals of fortune, “Frank 2″ had finally arrived in the Durango area with his baggage (it had been mistakenly put in some sort of broom closet in the Durango airport and then reported as missing) and was being shuttled to the nearby town of Rico, so Scott needed to pick him up first, bring him back to Bolam Pass. He offered that if the weather was still OK at that point, he would go to pick up my bag at Lizard Head. I don’t think I need to say that I was unbelievably grateful to him for rescuing me after my total bozo forgetfulness.

“Frank 2″ arrived, and turned out to be a young emergency room doctor from Vancouver. (For the rest of the ride, people enjoyed pestering him with questions beginning with, “You know on ER when…”) We didn’t ride for the rest of the day due to bad weather; in some of the non-rainy periods we went down to the nearby lake and washed the mud of the previous day and a half out of our sorry-ass drive trains, which perked up and decided they might shift properly again someday.

While Scott was off retrieving my gear, a man and two boys came through our campsite with a train of 3 llamas and an Airedale. He allowed as how he’d rented the llamas. Each llama was carrying the volume of, say, 3 enormous backpacks. They were traveling to Durango via the Colorado Trail. The kids, carrying little or nothing, looked cranky and exhausted. The llamas looked like they were having a Sunday walk in the park. They all walked down to the lake to camp there.

That night there was a piercingly loud animal fight somewhere nearby. I was convinced that it was a death battle between a pack of coyotes and the Airedale. I could clearly hear a “woof” sound in counterpoint to the weird squealing and yelping of coyotes. This went on for almost 30 minutes. It took me a long time to get to sleep afterwards.

Read the next entry