Hello world

Hi, and welcome to my second attempt at blogging about Adobe Flash Actionscript development. With this blog i’ll be attempting a bit of blue ocean strategy. You want cutting edge wow, don’t come here. This is not about technical marvel. This is a blog about making your life as a developer easier, keeping your head healthy, and in general avoiding headaches and gray hair.

My name is Andreas Rønning. I was born in 1982, and this is my 6th year as a full time Flash developer. I started out with Flash 4, and we’re on the doorstep of Flash 9. It’s amazing to think how fast time goes by.

One thing that i feel separates me from a lot of other Flash developers is that i have always had an immediate and deep respect for how development has been traditionally done in the past. When we were creating applications in Flash 4 we were being denied the fruits of our founding fathers’ labor. We had to invent our own methodology, building games and applications in a framework that was frankly designed to let us make fancy animations with limited interactions. I was always interested in how “real software” was being made, how they tackled problems, and how their solutions could be applied to solve mine.

It’s an understatement to say that until Flash MX2004 and Actionscript 2, Actionscript development was a mutant beast. As the platform grew in popularity, developers from other languages got into the game, working their butts off to find ways to gain the benefits of object oriented programming with a toolkit that wasn’t essentially built for that purpose. This is almost an exact parallel to what’s happening to Javascript right now. The resulting hacks and “hack best practises” live on to this day, and have shaped Actionscript development into an unruly animal with few if any best practises that aren’t viciously argued over on messageboards and other fora.

I chose pretty early on that some things require tight optimizing, other things simply need to work right, and as such the development methodologies will always have to be flexible. Some methods are frowned upon for “being slow”, but you should always ask yourself if your codebase will benefit from this relative slowness in terms of readability and reusability (is that even a word?).

I’ll be writing about methods i come across that make my day better, make my code prettier, and helps me meet the deadlines. Stuff that lets me go home with a clear conscience.

Hope you’ll find it useful!