You know when you write a class and then instantiate it and throw a couple of curveballs at it just to make sure it works? And then you write a related class, and throw both of them in the air for a few compiles?

That’s it. That’s what unit tests do. I had read a few tutorials on it, but their simple data class examples weren’t vivid enough to help me make this connection to my own practice.

It’s turning my stomach a little to realize how much time I’ve wasted. Informal unit testing is hugely inefficient. With informal unit testing, your little experiments are pretty much tossed into a big dark ditch. With formal unit testing, you can always run them again, which is priceless when you make a modification and need to make sure nothing has been broken. I get that now. Amen.

1. 70% of your instincts still apply. Designing a package of classes and a set of tables is a similar process. First you achieve a sense of how your specific domain (virtual worlds for 11-year-olds, shoe stores, mortgages, etc) works. Then you carve that domain into the most logically coherent parts. In both cases, the optimal division is the one easiest to maintain. For the OOPer, that means application-wide changes can be made in one place. For the database designer, that means data is not duplicated anywhere (data is “normalized”). It also means that the basic units of the system, whether classes or tables, can be combined and recombined for combinatorial limberness.

(more…)

He patiently explained to me that my personal likings were not the only factors to consider. There was a lot of AS2 code that could be re-used. AS3 developers were rare and expensive, and training takes time. Etc.

In truth, weighing all these factors is above my pay grade. He is probably right in this case. But, of course, that’s not what I said. Instead, I threw out that AS3 development is just faster.

(more…)

I fear that the site will have all the charm of exposed pipe for the average Flash designer. My fear is based partly on my primitive graphic-design skills, but mostly on the unusual nature of the interface.

Here is the interface:

(more…)

Having developed other skills and burnt though other passions, I was self-conscious about the joys of programming; I wanted to know what this new thing was, and why it thrilled me.

Some joys were not specific to programming per se but would attend the learning of any skill. Obviously, it’s cool to know how to do stuff. I remember vividly the stultification of my three brothers (an accountant, a lawyer, an engineer) when they started their careers, and even more vividly how they slowly got pulled into the details and the drama of their craft. As Moby Dick proved with whole chapters on subjects like stripping of whale carcasses, almost anything can be made intriguing. In the future, maybe bird-watching, souffle and design patterns will each have a cable channel devoted to them.

(more…)

In subsequent posts, I explained how it was done, focusing on one design pattern per post: Strategy for navigation, Mediator for application files, Interface for loading, State for loading swfs, Composite for a background loading queue, and Command for history.

In this post, I’ll summarize the entire process. I’ll start by identifying the fundamental problem bedeviling all-Flash sites, and end by suggesting that my solution to this problem can be the basis of a flexible, lightweight, comprehensive framework.

(more…)

This degradation of a useful and universally expected feature usually makes navigating these sites awkward, often painful.

So I decided (after preliminary reflections recorded in this post) that my playground site should be equipped with a full-fledged history.

This decision committed me to a systematic approach to navigation, because I suspected that the more systematic the navigation, the more manageable the history…and this suspicion proved justified. Once I had set up a navigation system in which every navigation was handled by the same piece of code and used the same syntax, adding history was trivial.

(more…)

Graphed, it looks nearly identical to the state pattern. Remember that with state, a wrapping object relays method calls to any one of a number of objects with the same interfaces, depending on its “state.”

With composite, rather than relaying the calls to one internal object, the wrapping object relays the calls to ALL of them.

(more…)

(more…)

(more…)