... .  .    .       .joeberkovitz.com

Going Back to Cali

Although not exactly the Cali represented in LL Cool J’s immortal deadpan number.  (Also check out the wonderful sax solo at the end, playing a minor 3rd up from the key of the tune.)

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!

No Comments

David Coletta at Boston Flex Users Group 11/11

A quick squib here to note that my friend David Coletta will be talking about building unified codebases for AIR and Flex at the November Boston Flex User Group meeting.

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!

No Comments

Heading to Atlanta to Speak at 360Flex

After a far-too-short breather from the last snow-encrusted landing at Logan Airport, I will be flying to Atlanta on Monday to speak at the 360Flex conference Tuesday morning. I really like this conference because it’s small, 100% focused on Flex development and has an extra-congenial, hang-friendly atmosphere.

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!

1 Comment

Flex Builder Source Folders Need to Go Back in the Oven

“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!

7 Comments

Please Rinse Your Used Planet Before Recycling

Lately I had been taking occasional solace from the fact that our planet seemed to be one of those disposable models. We have been making a royal mess of it, but at least (or so I had thought) in 5 billion years Earth would be incinerated in a thermonuclear explosion, courtesy of our Sun’s transition into a red giant. I thought of Earth as sort of a planetary Huggie, something that gets dirty and smells bad but ultimately gets thrown away, burning into nuclear ash and leaving a cleaner galaxy behind it.

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.

1 Comment

Wii be rollin’…

I’ve just emerged from my thrice-weekly morning session with the bike trainer. It’s gotten a lot easier to deal with the boredom of stationary pedaling thanks to the Wii that we bought “for the kids”.

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…

No Comments

An ActionScript interpreter, courtesy of JavaScript and Apollo

I’ve been experimenting quite a bit this week with Apollo, in preparation for a wee talk on the subject at Harvard. I’ve been building out that dependency analysis tool in Apollo and exploring the cool Javascript/Actionscript bridging capabilities in a series of examples.

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.

3 Comments

The Secret Life of SWFs: Flex 2’s undocumented SwfxPrinter tool

It’s apparently a well-kept secret, but the Flex SDK includes a very useful tool for examining the structure and contents of SWF files. The Java class flash.swf.tools.SwfxPrinter, which lives in the Flex 2 SDK’s lib/swfkit.jar library, is an undocumented utility that dumps AS3 SWF files as XML documents. These dumps can provide really useful insight into what is taking up space in a compiled AS3 Flash or Flex application.

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

14 Comments

Abrupt YouTube security policy change

There was a brief glitch in ReviewTube operation this last week, as the fallout from an unexpected YouTube security policy change.

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.

2 Comments

Day 2: Lizard Head Pass to Bolam Pass

This morning it was crystal-clear, with no hint of the previous day’s nasty weather. We could clearly see the dramatic surroundings of our campground: the 14,000+ peaks of El Diente and Mt. Wilson stared across the valley, with the eccentric volcanic plug of Lizard Head itself rising nearby. (Lizard Head, by the way, was considered the hardest climb in Colorado for much of the first part of the 20th century, because it’s made out of crumbly, unreliable garbage rock. Climbing guides of the period advised taking a photo of Lizard Head and turning around to head home. The lizard-head-looking part apparently decayed and fell off some time ago, leaving everyone to wonder what was the idea behind the name.) [Continued...]

No Comments