ashwineedashBlog | Interview of Colin Moock [always informative ]

Friday, February 09, 2007

Interview of Colin Moock [always informative ]

I got this and posting it as it is

/* About Flash */

<Francis> What do you find so attractive in Flash universe ?

<Colin> Communication, expression, exploration, invention. All of which you’ll find in evidence at presstube.com, levitated.net, publicstructure.com, marumushi.com/apps/socialcircles/, and collab.nl. Lots of others here: http://moock.org/moockmarks/, though I haven’t had much time to keep on top of my bookmarks lately.

<Francis> Actually with which work do you earn money?

<Colin> I guess my core income is books. I seem to earn about 30-40k a year off them (assuming I publish something each year). I make a little cash from my site through advertising and donations. Unity sales also make some money. And occasionally I do training or lectures around town to round things out. (These days international lectures actually cost you money most of the time due to travel expenses and low honourariums!). If I get desperate, I do a contract for a client. ;)

<Francis> Have you got enough time to continue to make paintings ?

<Colin> No. But I’m actually just working on one now. In fact, I might have to cut parts of this interview short to get back to it ;) I guess everyone dreams about living a life of pure creativity. I’d definitely like to only do paintings and online art, but that doesn’t buy me any video games or snowboarding lift tickets. I’ve attached a pic of my current work in progress…

/* About Programming */

<Francis> Do you practice other languages except ActionScript ?

<Colin> Yup, I like Java quite a lot. I sometimes read Perl for geek entertainment. Obviously JavaScript, and some PHP. But most of my time is spent in Flash.

<Francis> Which external tools do you use to work, editor, unit tests, CVS, project?

<Colin> I try to stay in the Flash editor so I can give Macromedia feedback on the workflow in the application. I don’t use formal unit testing tools, though I follow their approaches informally, and definitely respect the practice of unit testing. It’s nice to see some real ActionScript options coming out…Robin Debreuil has ASUnit (http://www.debreuil.com/FrameworkDocs/UnitTestingOverview.htm) and iteration::two have AS2Unit (http://www.as2unit.org/). I still like Homesite for HTML editing. I tried to force myself to use Dreamweaver for about a month but I just can’t get into it.

<Francis> I saw you were MVC's addicted, am i right and if yes, what do you love so much in this pattern ?

<Colin> I’m not a purist about it. But I think there are tons of important concepts in MVC that can be applied in various amounts to most Flash programming. ActionScript coding by definition involves the manipulation of audio/visual assets. And when working in the massively open-ended environment that is Flash, it’s really nice to have some set practices. MVC provides general theories that help chart a sensible path through the chaos of UI construction in Flash. I’ve dedicated a good sized portion of my upcoming book (www.moock.org/as2e/) to explaining the lessons of MVC as they apply to Flash.

<Francis> Which patterns do you most often use in your work ?

<Colin> Um…MVC? ;)

I also like Java’s Delegation Event Model. I like the principles of Observer, though I use event broadcasting in practice more often than raw Observer. I find Abstract Factory and Singleton useful sometimes too. Again, my upcoming book has several chapters on design patterns. You’ll get a more detailed response there.

On a more general level, I actually find quite a few patterns to be overkill for Flash. In Flash, you’re just not faced with as many industrial situations as you are in, say, C++ or Java. Patterns really pay off when you’re managing the logic and data of a massive system, like Photoshop or amazon.com’s shipping back-end. In the smaller applications that are common in Flash, the overhead of a pattern can sometimes be more work than it’s worth. That said, I think there are many good principles to be learned from most patterns, and it makes sense for the developer community to adapt those principles to the Flash platform.

<Francis> I am really obsessed these days by "clean encapsulation vs speed coding and speed process". What's the deal for you when you make choice ?

<Colin> Yup, me too…cleanliness first, all the way. If I’m building something with a really clean architecture, and it turns out that what I’m building is running too slowly, I see it as a sign that I’ve identified the wrong requirements for the project. Understanding Flash’s limitations and planning projects to work within them is extremely important. I’m not keen on pushing Flash’s performance limits. As far as I’m concerned, if you need to resort to bytecode optimization (with, say, flasm), you probably shouldn’t be targeting the Flash Player. I’d rather change the requirements of a project up front than optimize late in the game to fix a performance problem. (Unless, of course, I’ve made some error that’s leading to a serious waste of efficiency.)

Despite all that, I must admit I love seeing flasm-heads squeezing every last bit of speed out of Flash to make some crazy app really sing. And, more generally, if an optimization doesn’t compromise code readability and structure too much, I’m all for it.

<Francis> Another classical concept is "inheritance vs composition", could you explain your vision about it?

<Colin> Where movie clips are concerned, I *highly* favour composition over inheritance (I nearly never subclass MovieClip.) I feel movie clip composition is cleaner because it allows for instances to be created via a traditional constructor, and doesn’t force a potentially unnatural class hierarchy (e.g., Box inheriting from MovieClip instead of Shape). I also find composition also more flexible because you can easily change the stored movie clip instance to some other movie clip symbol if required. However, I’d say MovieClip subclassing is still be preferable in the following situations:
when an object needs to belong to the MovieClip datatype (e.g., for the sake of polymorphism)
when a class and a movie clip symbol need to be packaged together as a component for distribution
when an object needs most of the methods of the MovieClip class (in which case the "is a" relationship is legitimate)

Of course, the question of inheritance vs composition goes beyond movie clips. I actually deal with it head-on in my upcoming book. I might as well just cut’n’paste from the draft manuscript rather than paraphrase:

“How do you choose between composition and inheritance? In general, it's fairly easy to spot a situation where inheritance is inappropriate. An AlertDialog in an application "has an" OK button, but an AlertDialog, itself, "isn't an" OK button. However, spotting a situation where composition is inappropriate is trickier because, any time you can use inheritance to establish the relationship between two classes, you could use composition instead. If both techniques work in the same situation, how can you tell which is the best option?

If you're new to OOP, you may be surprised to hear that composition is often favored over inheritance as an application design strategy. In fact, some of the best known OOP design theoreticians explicitly advocate composition over inheritance (p 20, Design Patterns, Gamma et al, Addison-Wesley, 1995). Hence, conventional wisdom tells us to at least consider composition as an option even when inheritance seems obvious. That said, here are some general guidelines to consider when deciding whether to use inheritance or composition:
If a parent class needs to be used where a child class is expected (i.e., if you want to take advantage of polymorphism), consider using inheritance.
If you just need to use an object, consider a composition relationship. If a class you're designing behaves very much like an existing class, consider an inheritance relationship.

For more advice on choosing between composition and inheritance, read Bill Venner's excellent JavaWorld article, archived at his site: http://www.artima.com/designtechniques/compoinh.html. Mr. Venner offers compelling evidence that, generally speaking:
Changing code that uses composition has fewer consequences than changing code that uses inheritance
Code based on inheritance generally executes faster than code based on composition. (This is potentially important in ActionScript, which executes far more slowly than Java.)

In ActionScript, the composition vs inheritance debate most frequently appears when using the MovieClip class. The debate is simply, should one subclass MovieClip or store a MovieClip instance as a property? Both approaches are acceptable, though MovieClip inheritance is more complicated and requires use of a Library symbol in a .fla file. For an example of MovieClip composition, see Chapter 5, Authoring an ActionScript 2.0 Class, where the ImageViewer class uses a MovieClip to display an image on screen. For an example of MovieClip inheritance, see Chapter 13, Custom MovieClip Subclasses. When working with the MovieClip class, the above guidelines can help you determine whether to use inheritance or composition.”

/* About ActionScript essentials */

<Francis> How much time did you spend to write ActionScript essentials?

<Colin> It was about a year of research and writing.

<Francis> What's the main goal of this new book, will you cover high level design concepts or will it be just for oop or as2.0 beginners?

<Colin> Hm. Sounds like another good opportunity to save my hands some typing. Here’s a cut’n’paste from the draft preface:

“This book wants you to use object-oriented programming in your daily Flash work. It wants you to reap the benefits of one of the most important revolutions in programming history. It wants you to understand ActionScript 2.0 completely. And it will stop at nothing to get what it wants.

Here’s its plan…

First, in Part 1, The ActionScript 2.0 Language, this book will teach you the fundamentals of object-oriented concepts, syntax, and usage. Even if you have never tried object-oriented programming (OOP) before, Part 1 will have you understanding and applying it. If you already know lots about OOP because you program in Java or another object-oriented language, this book will use that prior experience to your advantage. It will draw you in to Flash-based OOP with abundant comparisons to what you already know. Along the way, it will introduce OOP into your regular routine through exercises that demonstrate real-world Flash OOP in action.

Next, in Part 2, Application Development, this book will teach you how to structure entire applications with ActionScript 2.0. In Chapter 11, An OOP Application Framework, you’ll learn best practices for setting up and architecting an OOP project. In Chapter 12, Using Components with ActionScript 2.0, and Chapter 13, Custom MovieClip Subclasses, you’ll learn how user-interface components and movie clips fit into a well-structured Flash application. In Chapter 14, Distributing Class Libraries, you’ll see how to parcel up and share code with other developers. All this will help you build more scalable, extensible, stable apps. It’s all part of this book’s plan.

Finally, in Part 3, Design Pattern Examples in ActionScript 2.0, you’ll explore a variety of approaches to various programming situations. You’ll see how to apply internationally accepted object-oriented programming strategies—known as design patterns—to Flash. The design patterns in Part 3 cover two key topics in Flash development: event broadcasting and user interface management. Once you’ve tried working with the patterns presented in Part 3, you’ll have confidence consulting the larger body of patterns available online and in other literature. You’ll have the skills to draw on other widely recognized object-oriented practices. You see, this book knows it won’t be with you forever. It knows it must teach you to find your own solutions.

This book doesn’t care whether you already know the meaning of the words “class,” “inheritance,” “method,” “prototype,” or “property.” If you have no idea what OOP is or why it’s worthwhile, this book is delighted to meet you. If, on the other hand, you’re already a skilled developer, this book wants to make you better. It wants you to have the exhaustive reference material and examples you need.

This book is determined to make you an adept object-oriented programmer. And it’s confident it will succeed.”

<Francis> Will it be 100% new or will there be some ASDG2 chapters included ?

<Colin> It’s 100% new, both in content and approach. It’s basically my most current thinking on how to properly structure a Flash application with OOP.

/* About Flash Mx 2004 and hot stories */

<Francis> Lot of guys complain about Flash MX 2004 release, lack of 2.0 documentation, bugs or that it's not a major upgrade, what's your position ?

<Colin> It was a bit buggy at first, but the updater fixed the major issues. I love ActionScript 2.0. I think 2004 made some really impressive advancements, despite the fact that it still has room for more improvement. If anything, I’d say the 2004 release might have suffered from being too ambitious. Bottom line, I’m never going back go MX. I’d quit Flash first.

<Francis> What do you think about the new v2.0 components architecture and have you been disappointed like Tom Muck was in his oop sacrilege article (http://www.flash-remoting.com/articles/oopsacrilege.cfm) ?

<Colin> I think the structure is pretty good actually, and I *much* prefer the v2 API to the v1 API. The v2 components are not perfect, but in general I like working with them. That said, I think there are some truly unforgivable specific problems with the v2 components. When I get a bit of time, I’ll be writing up my thoughts in a tech note. But just to give a few examples: 1) When using the default halo theme, you can’t change the colour of scrollbars or buttons. That’s just insane. 2) The styles are frustrating and limiting (and underdocumented). 3) The components break when multiple loaded movies are involved. 4) You can’t install a component by dragging a .swc file to the library of a .fla file.

<Francis> What do you think about Branden Hall's position when he wrote : "As for AS 2.0 - I really don't use it much yet. It's nice, but for the most part just syntactic sugar - it all compiles to the same bytecode." What's your point of view about the discussion which happened few months ago on his blog : http://www.waxpraxis.org/archives/000133.html and http://www.waxpraxis.org/archives/000134.html?

<Colin> I’m an ActionScript 2.0 fanatic. I hated the 1.0 prototype syntax. I hated working without compiler errors. I hated not having datatypes. ActionScript 2.0 is the answer to my dreams. I can’t imagine coding without it.

<Francis> Are you interested by the JFSL format and Flash extensions developpement,do you think we can seriously hope in the future to get "xtras-like" with dlls hacking ?

<Colin> I love the direction of JSFL. And yes, I think it’ll continue to grow into something really interesting, potentially fueling its own industry.

<Francis> What do you think about EULA's story thrown by Grant Skinner during GDispatcher developpement (http://www.gskinner.com/blog/archives/000034.html)?

<Colin> Generally speaking, I trust and admire Macromedia’s openness with the developer community. I didn’t follow the discussion closely because I use my own event broadcasting classes. However, I tend to work within known parameters. Flash is not Java or PHP. It’s not open-source. So debates like the one on Grant’s site are bound to happen. I think I just trust that it’s in Macromedia’s (financial) interest to have an active, happy developer base, so things like this will probably resolve themselves naturally. The fact that the actual developer of the components himself (Nigel Pegg) posted a response on Grant’s blog demonstrates a pretty rare level of company involvement in customer issues.

<Francis> Another hot story, how do you feel about Eolas story?

<Colin> Patents suck. Seriously.

/* About Unity */

<Francis> Can you tell us the story of Unity, what was the starting point of this great adventure?

<Colin> There’s nothing better than the mutliuser experience. Games like Combat, Pong, and Archon proved that to me over two decades ago, and I’ve never looked back. My first successful modem connection was pure joy. Then a split window chat in Unix in the 80’s blew my mind. I thought then that, everything should be multiuser aware. Everything.

Later, after Flash 5 was released, Derek Clayton and I wrote several little chat apps as tests in Flash. Out of those tests which grew a paid contract for the CBC (Canada’s national television network), where we built a voting system to coincide with a television quiz show.

But every time we built something new we realized we were using the same basic techniques. So for our own sanity, we started building up a generic library of code to use both on the client and server side. Eventually we decided that there was enough to turn our work into a commercial product, which would help pay for some of the time we put into it.

<Francis> What was the challenge and which were the difficulties that you had to overcome during the development?

<Colin> Making a really generic architecture that could be used for any kind of multiuser application. We thought it would be simple at first, but at every turn, there were synchronization issues, transfer issues, latency issues, etc. Evolving something that would work generally for the majority of use cases took about 4 or 5 months (we thought it would take a couple of weeks!).

<Francis> Do you earn enough money with Unity to pay your and Derek's dev time?

<Colin> Not even close. We work endlessly on Unity. The money we do make just helps take some of the pressure off of doing regular work. But we’re not much into the marketing side of things. We strongly believe Unity could easily make enough to sustain a healthy company. We just prefer to spend time developing, not marketing.

<Francis> What do you think about the other technnologies like Oregano, Electroserver or Fortress, any comments?

<Colin> They’re great. The more people that explore multiuser content, the better. Each team in the industry benefits from the others. (Jobe Makar, in particular, is a really decent guy.)

<Francis> Could you give us a scoop about the next features of Unity 3.0, when do you plan to release it and does true http tunneling stills to be on your list ?

<Colin> We’re working on increasing the server’s ability to handle large volumes of clients (i.e., many more than 1000). We also have a lot of refining of the API to do, including adding closer integration between custom Java rooms and the client-side API. Due to the recent changes in Flash Player 7.0.19.0, HTTP tunnelling is also now on our list. But it’s too early to sneak many other features.

We’re also planning more ready-made app packs, such as the recently released avatar chat (www.moock.org/unity/uchatavatar/). On top of that, I have some personal experimentation I’m going to return to as soon as my next book is done. With any luck, that will be ready to show at Flash in the Can (www.flashinthecan.com).

<Francis> What's your position on open-source, can we expect one day to see Unity in open-source?

<Colin> Open source is freat if you have the time. It’s tougher if you have to pay a mortgage. I figure I give lots away on my site, but I still need to earn money to support myself. Until someone decides to benevolently support Derek and me in a life of digital exploration, Unity will stay commercial.

Right? Back to painting. Thanks for the questions!

ps. Atomic Boarder is incredible! Congratulations on such a nice app.

/* AddOn */

<Colin> Yo i had a few people ask what this 'composition' thing we talked about in the interview was.

i figured it was worth posting a bit more of the excerpt...
http://moock.org/as2e/compositionVSinheritance.html

Name
URL
Email	Email address is not published
Remember Me
Comments
	Write the characters in the image above

Friday, February 09, 2007

Interview of Colin Moock [always informative ]

Comments

Menu

Search

Categories

Archives

Recent Entries

Meta

Errata