Of course, you get what you pay for, and Perch is definitely worth paying for… for some projects. Perch is very unique in its approach. Consider it an emergent CMS. Perch doesn’t have a predefined site structure that it builds on. Rather, you insert tags into your pages that CMS picks out and pairs with templates used for data-entry. It took me a while to wrap my head around it, but once I did I found it to be very powerful.

Because it’s not free (~$55 per domain), I’ve not used it at every opportunity. So far, I’ve reserved it for sites where someone else is picking up the tab, which is where it shines because that usually means I’m building a site for a non-technical user, thus Perch’s emergent CMS provides the minimal UI for that user’s site. For example, I used Perch to build a real-estate site for a friend of mine, Williams & Associates.

Originally, I was going to build this site on top of WordPress: pages for fixed content, categorized posts for news and property listings. I found a plugin that would provide a custom set of form fields for editing a post that would’ve worked well for the property listings… if I could have gotten it working. In the end, I was fighting WP more than it was helping me, and even if everything worked as planned there would still be a hugely complicated admin UI presented to the client whenever they wanted to make changes. (Yes, there are plugins to address that as well…)

I then ran across Perch. I loved its minimalism. It allowed me to build the site exactly as I wanted — which if you look at the HTML, you’ll see is pretty minimal, way more than a normal WP site would be — and then generate the admin-side of things automatically from its structure. Perch 1.0 definitely lacked some major features, such as image uploads and list re-ordering, but these have largely been addressed in recent updates (though they were slower coming than I would have hoped).

In fact, I was quite happy to see that when I recently went in to make some updates to the site, I ended up spending far more time in the admin UI editing text than I did touching any HTML structure, much of this thanks to Perch’s native support of Textile and Markdown.

Just last week, Perch 1.5.5 was announced, and I’m looking forward to playing with its new features. They include the notion of “apps” that I’m very interested in checking out. I do wish Perch was free, or significantly cheaper (say, $5 for non-commercial sites), or offered a subscription license (unlimited domains for a year) as it’s a perfect fit for lots of throw-away sites where a full-blown CMS would simply be overkill.

1. The WHATWG and W3C revise the Canvas API to align with Flash’s Display List API.
2. Adobe donates the Flash Player to the WebKit project to serve as an initial implementation of the revised Canvas API.
3. Apple, Google and Microsoft adopt and implement the revised Canvas API in all of their desktop and mobile browsers.

I think this is an ideal compromise: everyone gives a little, everyone gains a lot. There are no losers.

I’ll address each point in more detail this week.

Like many people my age, I first experimented with Flash during college. It was the 90′s, the web was new and exciting, and honestly we’d try anything.

I got into it deep. I created the site OpenSWF.org. I maintained an updated SWF file format spec and built a Java-based player. In fact, this was pre-ActionScript, so I even designed an extension mechanism that leveraged Java’s dynamic class loading to allow on-the-fly, distributed updates to the player itself.

Then, I graduated from college, I got married, I got a grown-up job; I left my childish Flash ways behind me and got serious: C++, vector units, video game consoles, multi-million dollar projects.

Five years later I read an incredibly influential whitepaper from Scott Bilas, former Bungie engineer, based on his GDC 2005 presentation: What About Flash? Can We Really Make Games With It? I fell back in love.

Within a year I set out to launch my first (and only) startup, Mockingbird Games, with the goal of making game making as fun as game playing. Much like YouTube, we leveraged the Flash Platform to deliver our core experience to as many people as possible.

For the last 3 years I’ve been developing on the Flash Platform all day, every day. I’ve designed and built a flexible game architecture, a large and complex web application, and many games and apps for clients such as MTV, Paramount, Disney, Mattel and Hasbro. Me, myself and I programmed every single line of code. Millions of people have played these games and used these apps, and tens of thousands of games/levels have been made with just our apps.

During those 3 short years, the Flash Platform has gone from v8 to v10, from ActionScript2 to ActionScript3, from purely interpreted to a modern, JIT’d virtual machine, from a vector-only renderer to a high-performance raster/bitblit renderer. We’ve gotten a declarative markup language for building apps, a high-quality UI framework, multiple free & commercial IDEs and an open-source compiler.

I can write an app for the Flash Platform, compiled with free, open-source tools using a free, open-source SDK, and it will run on Windows, OS X, Linux, Android and iPhone with zero changes. I don’t need anyone’s permission to do this, or anyone’s blessing. My app sinks or swims based on its quality, including not only the work I’ve done but the work I’m building on top of, the Flash Platform itself.

Amazingly, I could have done this 4 years ago with Flash. In fact, in 2006 I could have used a freely available compiler (mtasc) and free toolchain (swfmill) to produce a SWF that would still work today, unchanged on these platforms. But I digress…

I’m not alone in my experience: there are thousands of Flash developers out there building fantastic interactive content. Fantastic webapps like Picnik, Audiotool, Playcrafter and Balsamiq. Even more fantastic games like Canabalt, Machinarium and Club Treasure World. And about a hundred thousand more examples.

There’s something all of these examples have in common: their monetization and distribution are entirely within the control of their developers, and they are freely accessible by virtually any modern desktop computer. For me, this is the definition of an open platform.

Furthermore, many of these apps were built with freely available, open-source tools. They’re all published to a bytecode format that’s documented, well-defined and backwards compatible. They run on a player that’s freely available and is actively being maintained, improved and migrated to new platforms. For me, this is the definition of an open platform.

Flash has provided some unbelievable shoulders for me to stand on. I have used Flash to make my livelihood, to create my dreams and to share them with millions. I’ve used dozens of others languages and platforms over my last 20 years of programming, and none have done as much for me.

I support Flash. I’ll defend its role in the modern web. Flash is my platform.

So, I’ve kind of obsessed about it this evening and put together a pretty solid solution. I think you AIR folks out there will be interested in it. Very handy. Set autoWidth and/or autoHeight to true to lock that dimension to the ideal (based on the measured children).

Imagine $50,000 in “tax cuts.” Should we give that benefit to the top income earners, middle income earners, or bottom income earners?

Consider an extremely top earner earning $500,000 a year. Does the $50k change their life? No. Are they likely to spend it? Not immediately, and most likely not in a stimulative fashion. Does the tax cut reduce their burden on the government? No, because they’re already not a burden, i.e. they aren’t leveraging Medicare/Medicaid, welfare, food stamps, etc.

Now consider two top earners making $250k a year each. They get tax cuts of $25k each. Does it change their lives? Probably not. Are they likely to spend it? More likely, sure, often times on debt or major purchases (home, car). Stimulative effect? Minor, but some. Reduced burden on the government? Not really, again because they’re not likely utilizing expensive welfare services.

Now consider four middle earners making $125k a year each. They get tax cuts of $12.5k each. Does it change their lives? Probably doesn’t change their lives, but it can make some big differences. Credit cards get paid off. Down payments on a home get made. Car gets paid off. Or, if stuck in savings, now someone who more than likely didn’t have a significant savings “buffer” now has a few months of money to help them whether the storm. This buffer saves them even if they lose their jobs, or have emergency medical expenses, or wreck their car. Again, this earner is less dependent on welfare, etc., but they’re now less likely to ever need it because they’re in a “safer” spot financially.

Finally, consider 16 low income earners making $32k a year each. They each get tax cuts of $3.2k. Does it change their lives? Significantly. Simply spread out over the course of the year it’s enough to make the difference between being in the red at the end of each month and being in the black. A family of four could move from a 2 bedroom apartment to a 3 bedroom apartment. Healthcare insurance becomes a possibility. Medicaid is less necessary. Food stamps are less likely. Overall quality of life shifts subtly but significantly from sinking to staying afloat. And all the money spent is most likely spent at local businesses, subject to sales taxes, benefitting the local community, and directly employing other low wage workers.

Simplistic, sure. But certainly a more compelling and detailed argument than simple “trickle-down economics.” In the case of the top earner, the tax cut is more like a bonus, a cherry on top of an already comfortable, ultra high quality standard of living, with the most likely beneficiaries being other high income earners in the form of commissions on investments, etc. In the case of the bottom earner, the tax cut represents a make or break amount of money, the difference between a livable and poverty lifestyle, a reduction of secondary costs to the government, a healthier, lower-stress population spending money at the local level.

In all cases, the surface cost to the government is the same $50k in loss tax revenues. I think it’s pretty clear which category benefits the most people to the greatest extent.

I’m not a stupid person but prop injection is retarded. I need both vars set before calling apply -> http://twitpic.com/1dz5d9 #Advice

This comes up quite a bit in Mockingbird since hot-swapping dependencies while a game is running is our major differentiator. In practice, it’s often not necessary, but it definitely always make your code more complicated, more fragile and (inevitably) buggier.

If your class has (or ever could have) more than two hot-swappable dependencies, you need a proper invalidation model in order to scale to the dependencies. You can also potentially have a faster object by deferring, and thus aggregating, validations.

Here’s a quick example class I just wrote-up because code speaks louder than words. To keep things conversational, I typed it up in a text editor and haven’t actually tried to compile and run it, which probably means there are typos and stupid mistakes. But the point (and pattern) should hold.

If USE_DEFERRED_VALIDATION is true, validation will not occur immediately when a property changes. Instead, a flag will be set and on the next frame validation will happen. This allows you to set multiple dependencies during one frame and they’ll all be applied at once the next frame.

The classic game engine loop basically embodies this invalidation model with update() (which invalidates) and draw() (which validates).

I updated the sidebar to include links to myself elsewhere, places updated slightly more often than the blog.

I wanted to specifically point out Dribbble. Excellent site built by Simplebits that’s just recently come out of a private beta. I’ve made one post so far, but I’m trying to put in a schedule of posting something daily. There’s some incredible talent on there producing great stuff.

As many have pointed out, the release model for this site was fantastic. Perfect for a site full of user-generated content produced by avid content creators. It was invite only, and the number of posts is limited (30 a month, I think). I’ve got a site bubbling right now that I’m thinking about applying a similar mechanism to.

Now that Dribbble is public, folks will get to see me working on the next big thing! ;-)

UPDATE: Thanks to the suggestions of Casey, I’ve updated the base class to use events from the loaderInfo instead of checking each frame, as well as using the frame label as the class name (which I believe is the idiom that Flex’s [Frame] metadata follows).

I reread the preloader post I made earlier today and it occurred to me I should make this an actual re-usable class. So, I did. Here’s the Preloader base class:

Usage is very straightforward. I made everything protected for easy sub-classing, but you shouldn’t have to override the event handlers, onProgress(), onComplete and onRemovePreloader().

As I discussed in my earlier article on the subject, you have to include a compiler argument to force your main application class to be loaded on a secondary frame. You do this using the -frame compiler argument like so: -frame frameLabel fullyQualifiedClassName.

To customize the preloader animation, override addPreloader(), updatePreloader() and removePreloader().

To create your main application class you can either pass the application class’s name into the constructor, e.g. super("com.mycompany.myapp.Application");, or you can use the class’s name as the frame label in the compiler argument, e.g. -frame com.mycompany.myapp.Application com.mycompany.myapp.Application. If you need to do something more specialized than just constructing your class and adding it to the stage, you can override createApplication().

Here’s an example of a preloader that displays progress as a percent in the top-left corner of the screen:

I’m not sure why Adobe dictated this in mxmlc, there’s no reason that [Frame] would require this to be implemented correctly. Unfortunately, they did, so we have to resort to using a compiler argument to get the result we want.

[Frame] metadata basically equates to the -frame compiler argument, but a little reversed. With [Frame] you specify which class should be placed in the frame previous to the class it decorates; with -frame, you specify which frame a class should appear on.

My standard preloader is named for the application’s SWF (so I don’t have to add any extra compiler arguments in Flex Builder), and once it finishes preloading it instantiates the actual application’s root class, which I normally name Application.

Because the application usually does some additional remote service calls and asset loading after the SWF completes, I don’t remove the preloader until it’s notified by the application that’s it’s ready. I use an event to do this so that there’s no hard-references either way.

This is an important point: whatever you reference in your preloader will be placed in the first frame of your SWF, so you have to be sure and not reference your application class (or really, any classes outside of the flash.* packages) statically. What you do is load them by name using getClassDefinition() once you’ve determined that the entire SWF has loaded.

I suggest visiting CTW to get the full run-down of what’s offered, but a quick description: CTW is place for kids (and adults!) to build their own games and “chat worlds” to share with their friends. Everything is built from treasures that folks can purchase through micro-transactions or earn using the Nintendo DS game Treasure World which Aspyr shipped last year.

CTW was the first project I used Robotlegs on. Even though we didn’t use it extensively—the other developer on the project was not familiar with dependency injection—it provided a nice solid architecture to jump off of. And due to its minimal nature, even when we weren’t leveraging it, it was never in the way.

While we were working on this project I also started several other smaller projects leveraging Robotlegs (none yet released) and have gradually refined my own workflow with it. I’m still a fan, though I’m quite curious about Swiz because it appears to be even more minimal, if that can be believed. I am completely sold on the idea of dependency injection and have started applying it to my API designs.

My latest Robotlegs project is also my first project to leverage Rob Penner’s excellent AS3 Signals. These two together have significantly cleaned up my code and are definitely quashing many of the architectural issues I ran into when developing the original Mockingbird app. In fact, I’m itching to go back and rebuild the whole app and site—not to add features but to clean up the codebase in such a way that it’d be ready for some rapid feature addition in the future. Robotlegs definitely provides a very agile framework.

For CTW we also used SmartFoxServer for the first time. In the end, I was less enthused about this choice. While it got us up and running really fast with it’s simple API and built-in chat functionality, it was a pain to develop with and debug, and I wouldn’t choose to use it again. The API originates from AS1/AS2, so there’s very little type safety and none of the current AS3 conventions. The documentation leaves out a huge amount of caveats present in the API that don’t necessarily make sense, even though it’s clear from the support forums that developer after developer encounter the same issue. The next time around I plan on using a more robust option, like ElectroServer, or possibly the still-in-alpha Union Platform.