Today I learned how to use rspec, the Rails plugin. It was my first experience with unit testing, and it seemed eerily familiar.

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.

Tags: codeNo Comments.

There are tons of posts out there from back-end wizards who have seen the light when it comes to object orientation. This post has a few quick pointers for those going in the opposite direction, front-enders like myself who are OOP-fluent but just starting to lift the lid on the back-end and peer into the darkness that is the business and database layers.

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.

[Read more →]

Tags: codeNo Comments.

I was talking with my boss tonite about a big project coming up. He was explaining that a client was thinking of building a new site in AS2. I was dismayed. After developing with AS3 for a while, I was doing some AS2 work and hating it. After AS1, AS2 was a godsend, but after AS3, AS2 is a huge pain in the ass.

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.

[Read more →]

Tags: workflow · code · office15 Comments

In my last post, I reviewed the code architecture of my playground site. In this post, I’ll explain its design.

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:

[Read more →]

Tags: speed · interface · Flash8 Comments

I was 35 when I started to program. And immediately I loved it. It was as if a part of my brain that had been locked away could suddenly cavort in the broad daylight of ongoing life.

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.

[Read more →]

Tags: culture · code · random4 Comments

In the first post of this series, I explained why I wanted features like long-term flexibility, deep linking, history, and background loading for my new, all-Flash playground site, pet-theory.com. I also explained why I used design patterns to meet these requirements.

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.

[Read more →]

Tags: patterns · code5 Comments

When they implement history at all, all-Flash sites tend to offer history-like gestures like a Back/Home/Before arrow in lieu of the actual, click-by-click back- and forward-tracking of a browser.

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.

[Read more →]

Tags: patterns · code1 Comment

The basic operation of the composite pattern is easily grasped. Composite is another wrapper pattern that involves one object rerouting method calls to another object with the same interface.

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.

[Read more →]

Tags: patterns · code1 Comment

In a tree of modules, some modules will need to load assets when selected…and some will themselves need to be loaded.

[Read more →]

Tags: patterns · FlashNo Comments.

I was acquainted with interfaces before I read Head First Design Patterns, but their full glory was hidden from me.

[Read more →]

Tags: patterns · code1 Comment

I remember vividly the first time I opened up the Actionscript panel in the Flash IDE and wrote one line in the heretofore untouched panel:

It was a special moment because this lightning-stab of a line both compressed and expressed a week of work. Ctrl-Enter...and...SWISH!

Between that moment and moment I cracked open Head First Design Patterns, I learned surprisingly little about application files per se.

[Read more →]

Tags: patterns · codeNo Comments.

I wanted things for my playground--not only history, but deep linking and persistence (the site wouldn't automatically reboot when backtracked)--that made a systematic approach to navigation necessary.

At the same time, I hadn't decided on the what of the navigation (the sections), or the how of the navigation (the transitions between the sections), and I didn't want to commit to any particulars, since I hoped the site would last a couple of years, and who knows what WHAT or HOW would be fashionable or imperative two years from now? If I look back two years, the shifts are staggering.

So right away, the fundamental question arose: how to plan for flexibility?

[Read more →]

Tags: patterns · codeNo Comments.

I'm doing a week of posts on how I built my new playground site, pet-theory.com. My three-fold aim is 1) to introduce designs patterns to those unfamiliar to them, 2) to give a soup-to-nuts example of architecting a site, and 3) to suggest solutions to some problems common to all-Flash sites.

I'm no expert on patterns or site architecture. Far from it. Before this project, I was where many Flash coders are: comfortable with the techniques of OOP (objects, inheritance, encapsulation), and reflexive about separating the structure of data from its representation and manipulation (Model-View-Controller, not so much a pattern as a worldview), but unsure where to go next.

[Read more →]

Tags: patterns · code3 Comments

After updating my trial of FlexBuilder to 2.0.1 (OS X), a slew of errors appeared in my AS3 projects.

I had gotten in the habit of using the same name for 1) a package, 2) the most important class in that package, and 3) a reference to that class in another class.

So for instance:

import alertBox.AlertBox;

...

protected var alertBox:AlertBox

I had a queasy feeling about possible collisions, but I found the symmetry clear and effortless, and there were no problems--until the update.

Then, the compiler started disregarding the variable declaration, and treating "alertBox" as the package, instead, so I got a bunch of errors to the effect that "x" (for instance) is not a method defined for alertBox. ("x" is a property of an alertBox instance, but not a class in the alertBox package).

When I renamed the variables ("aBox"), the errors went away.

Just a heads up.

Tags: code1 Comment

AS2 access modifiers were simple to understand. Each class was like a cohesive object with an outside and an inside. If a property could be accessed from the outside, it was public. If it was used for the inner workings of the class, it was private.

AS3 presents a considerably more jagged picture. Senocular has laid out the new landscape with characteristic economy and astringency in these posts, but I had to read them about five times before I understood them.

The most striking innovation is the new default access modifier, internal. The first question about this modifier is: internal to what?

[Read more →]

Tags: code9 Comments