Pet Theory

A man at a Flashbelt session included some racy content in his preso. Different accounts can be found here (more offensive), and here (less offensive). Most of the people in the room were men, and many laughed. Some of the women there–as well as the conference organizer–were first to complain that the content was unprofessional and objectified women.

So the Flash community has a controversy on its hands, just as the Rails community did a month or two ago. Was it wrong? I dunno. Here are some related questions that might help you decide:

If the room held only men, would a presentation like this be wrong? That is, is the harm here how men’s worst impulses are being reinforced?

If the room held mostly women, would it be wrong? Did the upset women’s discomfort stem mainly from the fact that they feel professionally precarious? If they didn’t feel precarious, would they still be upset?
More… »

Flex 4 a.k.a. Gumbo will treat the major pain point in Flex development–the workflow between designers and developers–by allowing Flexers to easily make complete, detailed component skins as well as non-standard interactions and effects.

And what about Flex design? Will it be impacted? It’ll be a year or more before we know, but this post makes two predictions:

1. Flex designer will fulfill the old unfulfilled dream of Flash designers that UI will become more game-like. Flex will also supplant a lot of Flash development while still avoiding Flashiness.

2. More important, Flex designers after Gumbo will focus on incorporating the best of hypertext, the dominant and transformative mode of the web that Flash and Flex designers tend to discount. More… »

Flash releases tend to operate on the each-kid-gets-a-turn principle: one for the developers, one for the designers. After reading this article on Gumbo component article, however, I think Christmas might be come early at Adobe. Because if designers will luv Gumbo’s new skinning model, developers will luv luv luv the new component architecture. More… »

This post will show you how to slim down the service layer in your Rich Internet Application after defining RESTful services.

Posts on REST usually begin by claiming that REST architecture involves much, much more than reducing the syntax of web services to database-derived verbs: create, read, update, delete (CRUD). That’s true, but for this post, exactly that supremely useful reduction will be “REST.”

This post won’t explain how to make a REST call or if it’s possible to wrangle http REST for Flex (no, yes with Rails and Flex, kinda with Java and Flex, StackOverflow). I’ll be focusing on RIA structure rather than http. Examples will be drawn from Flex, but my conclusions should apply to any stateful RIA whether Silverlight or Javascript-based, with any kind of services, whether http or rpc. More… »

A self-evident interface is always Plan A…but a self-explaining interface is a decent Plan B. Here is one in action. (Follow the purple arrow…not optimized for start up yet.)

“As simple as possible, but no simpler.” For my current Flex project I reached this point pretty quickly. Inspired by improv, it is a chat site that creatively orders group chat. There are roles (Host, Quizzer, Conservative, Blind Date, etc.) for a variety of scenarios, mostly drawn from pop culture. Chatterers vote for a scenario leader, who plays one role and picks others for the remaining roles.

For a game, it’s not complicated. For an interface, it is. Some sort of help was required. More… »

Googling is one of those things that has so saturated my life that it now seems trivial. How did programmers operate before Google? Images flit before the mind…IRC, books, co-workers…but seriously, for someone who searches hourly, the mind boggles.

If you live with Google for a while, the controversy about the Web’s inclusivity–how can we sift the smart from the dumb?–is useless. When I was a stupid programmer, I found a lot of slightly-less-stupid blog posts, tutorial and articles that spoke to the stupid in me. When I become less stupid, other voices beckoned. The web grows with me.

Lately I’ve been wondering whether the web should preserve even more stupidity. When I really look at the hours I rack up programming, far too many of them are consumed with stupid mistakes, especially when starting fresh on a new kind of task, language or project. Google is still helpful then, but all too often I find myself grinding through some stupidity alone.

This is partly due to the fact that the set of smart, conceptual mistakes is a minor subset of all possible mistakes. “It’s” v. “Its” is downright hi-concept… “accommodate” v. “acommodate”, “accomodate”, “accommadate” is nearly random in comparison. Not even the web can preserve all the permutations of sheer error.

More… »

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.

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.

More… »

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:

More… »

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.

More… »

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.

More… »

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.

More… »

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.

More… »

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

More… »

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

More… »