At the corner of Magazine St. and Perry St., Cambridge, Mass.

Michael Wargo, a chief lunar scientist at NASA headquarters in Washington said, “Water and other compounds represent potential resources that could sustain future lunar exploration.” And an article by the New York Times stated, “Lunar ice, if bountiful, not only gives future settlers something to drink, but could also be broken apart into oxygen and hydrogen. Both are valuable as rocket fuel, and the oxygen would also give astronauts air to breathe.”

Give “future settlers” a drink? People… you are missing the point. That’s our water, and it belongs in terrestrial supermarkets.  We should be shipping that Moon water straight back to Earth, putting it in expensive-looking theme-y bottles, and selling it at inflated prices at Whole Foods.  The profits from this commerce can be plowed back into more space exploration, ultimately leading to the discovery of other water-bearing celestial bodies.

In fact, I already have a brand name picked out for this bottled water: Lunessence.  And I don’t need a marketing expert to tell me how to sell it, I already have Fiji Water to serve as a tutorial.  Here’s our ad copy:

The reality is a bit more complicated.  Some bottled waters come right out of municipal reservoirs before they are “purified.”  And, even “spring” water is affected by the earth’s many pollutants as it bubbles to the surface.  It’s better not to get your water from anywhere even near the freakin’ earth.

Then there’s Lunessence… uncontaminated and uncompromised.  Preserved and protected by its source and location, Lunessence’s aquifer is in a virgin ecosystem — well, not exactly an ecosystem, more like a sterile deep-space environment — at the edge of a lunar crater, hundreds of thousands of miles away from the nearest industrialized civilization.  Winds that carry acid rain and pollutants all over Earth just aren’t a factor here.

So if you ever wondered what really pure water tastes like, just open a bottle of Lunessence.  And remember this — we saved you a trip to the moon.

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.)