RIA

I’ve been thinking about writing this post for a while, but every time i started it felt like i was trying to teach a crowd that already knows better than me, and that’s a level of arrogance beyond even me.

But i can’t help but feel there is something to how i do things that must be at the very least affirming to some developers out there. Flash developers often work alone or in small groups, and few really have a big community to hang out with. It creates an atmosphere where you are never really comfortable with your own skill level, and for me at least it fostered a belief that everybody out there were doing rocket science and I was still building Lego cars and didn’t even bother to make the colors uniform.

I’ll write down some specific beliefs that have helped me a lot.

Object-oriented programming is there to make your life easier, not the machine’s.

When AS2 first dropped on us and i was firmly embedded in AS1 and prototype hacking, i could barely grasp the need for inheritance, and interfaces came much later. I was comfortable with functions-as-classes, long rambling frame scripts and include statements, and i felt like i was on top of the platform and what it could do.

Every time i tried to read about OOP i would be drowned in talk about design patterns and other things that are only really material from a philosophical point of view, but are often portrayed as fact, and digging your way through the religious forum conflicts you find out there can serve as a royal boot to the head if you’re trying to find your way in. My first bumbling steps into OOP were moving from include statements and frame scripts into a single frame script that instantiated an Application class. The actual difference was semantic at best, but it felt good  to test the waters.

The actual BOOM moment where i suddenly “got it” was when i started doing application design on paper. Previously I’d drawn visual states -Big boxy wireframes and rough line charts- and eyeballed the code from there, which was good while i was in the moment, but hell to return to a while later. When putting down thoughts i stopped writing MovieClip or Button, String and Array, and instead started naming things just what i physically imagined them to be. It’s an obvious thing in retrospect, but much like understanding Arrays and other such abstractions that no longer name objects, it was a huge mental tectonic shift. An image isn’t a MovieClipLoader in a MovieClip, it is simply an Image.  The change in work process was literally over night. I stopped starting at Application.as and working my way outwards. I started creating dozens of stub classes simply to have the names and concepts in place before i began the actual coding.

It dawned on me that OOP didn’t just let me apply programming principles i felt were beyond my need. It let me alter the fundamental constructs of the programming language. By compartmentalizing problems, i had been given the opportunity to break an application down into dozens of individual small problems that were typically easily surmountable, that in concert could be used to solve even bigger problems. A hypothetical image gallery is an ImageGallery loading xml into an ImageList containing ImageListItems consisting of an Image and an ImageInfoOverlay. I don’t have to worry about how the Image is displayed in the ImageList, the Image handles that. I don’t have to worry about what information to display about an image on mouseover, the ImageInfoOverlay does that.  Mentally, i’m not thinking about abstractions like sprites or arrays anymore; Those are simply words i use to describe a concept. The concept is what actually matters.

In summary: OOP lets you dictate the language in which you write your application. It is this key principle that lets a developer move from one OOP language to another with relative ease. I shudder to think what i would have gone through trying to learn C++ or C# with only AS1 under my belt. If i have any specific wisdom I’d like to impart on a developer new to OOP concepts, it would be this: Make it easy for yourself first, and you’ll be typing what is natural to you.

It is okay to have many classes, it’s okay to be verbose, and it’s okay to be an idiot

Actually, the more classes the better, because with every class you are bending the language semantics to your will. This comes down to the absolute basics. Say you are implementing a geometry algorithm for the first time. The document you are learning from refers to points as vertices. At this point, i would typically create a class named Vertex that simply extends Point and does nothing more than call super(). All i have done here is change the name of the Point class. Why? Because it’s one less step for my brain to walk while i’m learning this new algorithm.

I’m an artist first. I began as a designer, I consider myself a musician first, and i have the attention span of a cat. In spite of this, i find programming hugely empowering and satisfying. It wouldn’t be half as fun if i wasn’t able to recognize that my brain simply works in visual and physical concepts, not deep abstraction. It’s a common saying that programming is like explaining to a really, really dumb person how to do something, but i think it’s important to realize that you are also talking to yourself most of the time.

I’m comfortable with my own inability to work effectively with heavily abstracted patterns like MVC, because they don’t speak well to me as a person. My goal is to complete a task and ship a product i feel good about, not successfully apply a design pattern someone else put together in their own language. Which brings us to the next point.

If it floats your boat…

Design patterns can be absolutely wonderful things, but they should in my opinion be read as philosophies, not sets of rules. It is entirely possible to work within a very abstract design pattern and not be aware that you are doing so. I cherry pick concepts from patterns that i like and apply liberally with little real concern beyond getting the job done with a minimum of pain; Patterns are typically merely solutions to generic problems, and there is no reason to be afraid of them, or treating them like a set of commandments.

You’ll find a lot of technical developers with a very technical point of view that will, for instance, decry the merits of a singleton, while as a developer under stress a singleton can be an enormous timesaver. Don’t let the philosophical debate around patterns stop you from reading into them and taking with you what you need. In the end it should all help YOU be a better and more effective developer and prevent headaches, not the other way around. My first venture into patterns, a rudimentary exploration of MVC, resulted in me actually feeling dumber than before, and was a serious setback for me as someone getting comfortable with new concepts.

Fuzzy coding is fine within a known system

Don’t be afraid to create utilities for speeding up your workflow, even if it does mean doing something “dumb”. Unless it’s realtime or inner-loop code, optimization isn’t something you should even have to consider for solving menial tasks. Here’s one of my favorite utilities of recent:

Say i want to set up a TextFormat with a font name. I know the font is called “whateverfont”, but the actual embedded name of the font if i want to refer to it embedded is case intensive and may have spaces or extra characters that I’m not aware of, such as Whatever Font STD. Before, this would entail using an enumerateFonts call to grab the font objects, and then manually look through them to get the correct font name. With this utility, i simply call FontUtils.getFontBySimilarFontName(“whatever”). It allows me to be fast and loose, at the cost of a couple of extra loops when it gets called, which is ONCE when i declare the TextFormat. This is a trade-off I’m very ready to make, and I don’t see why I shouldn’t be allowed to.

You should allow yourself to be fuzzy and loose when coding, because it, again, takes your mind off the menial boredom and keeps your eyes on the ball.

Have fun

Don’t let nerds and sourpusses bring you down. Programming isn’t “for smart people”. It’s just another language, albeit one where clarity is the point and not the model. Don’t let high-end tech-talk make you feel poorly about your skills. Don’t be afraid to mix and blend. Think naturally. When you are starting up, think about the product you are making and not the individual problems within it; You can solve each problem on its own. Whatever way you solved the problem, the problem remains solved.