As reported on the Canadian Net Neutrality action website SaveOurNet.ca, “The CRTC has said that it will consider public opinion in determining the outcome of the traffic shaping hearings set to take place later this year.“ As Canadians, we owe it to ourselves and this great nation to hold governmental institutions charged with guarding the public trust accountable to the purpose for which they were created. We need to send ISPs in Canada the message that this kind of censorship shall not be tolerated, and should not be allowed. Check out the details on SaveOurNet.ca, and send in your action letter to the CRTC.
Looking back on the book projects I participated in over the course of 2008, I notice that the two ActionScript 3.0 books I served as principal tech editor are both out. The ActionScript 3.0 Migration Guide by New Riders/Pearson is a compact guide illuminating some broadstrokes of migration from As2 to AS3. The ActionScript 3.0 Visual QuickStart Guide by Peachpit Press from my Community MX colleague Derrick Ypenburg, is a great primer on the basics of ActionScript 3.0, which is also a useful primer for those converting to ActionScript 3.0 for the first time.
There’s an interesting back story to the AS3 VQSG: I was actually commissioned to write this book, and got as far as writing the outline and scope of the text. At the time I just started writing two books, this one and the Professional Flex 3 book, and it didn’t take me long to realize that writing two heavy books at once would be career suicide, as I would have no time for client work (a man’s got to eat, right?) But I can’t just drop the book: I am honour-bound to find myself a replacement. So I call up my colleague Derrik Ypenburg: we talk about the book, he agrees to take on the project, and we decide that I’ll stay on as the tech editor. Derrick did a great job of writing the text, and at times the project felt more like a collaboration, a co-creation than an editing job — even though Derrick did all the hard work ;) — which is how all team projects should be. Well done Derrick.
I always wondered if this day would come. Now, hopefully, it just might.
Following is a reply to a post on the Open at Adobe blog entitled Is dead code ever a good line?
If someone cares that the program continues, and is will to commit their resources, why shouldn’t the code be released? If the code is good enough, and doesn’t include other properties, why not release it? If a community is available to control and govern it, why not? If the product was good enough to build a market on its own right, why should we believe it can’t continue?
So, to both of my readers
, what do you think? Should dead code be released? Are there examples of it working, or failing? And what do you think are the steps that would help us decide?
I knew exactly what I would write. The same thing that’s been on my mind since I started doing serious actionscript development back in 2002, and the one reason I switched to being a Flex developer:
“I think the answer is hell yes, particularly in Adobe’s case.
I’m going to take a moment and gripe about a typical situation which underscores the importance of this point.
I can think of a few situations in the past where open sourcing the code for the Macromedia Flash v2 (i.e. MX 2004) components would have saved a lot of developers, including myself, from a lot of pain and grief. The fact that Macromedia had abandoned the v2 component code back in 2005 (maybe earlier?), and yet would not open source it, left the Flash development community with little alternative than to use 3rd party component frameworks, because patching up holes in the component framework was simply not a legal option. I remember back when the v2 components were released, a few bright stars in the community found fixes and patches for them, but were unable to distribute this code because of the closed policies surrounding these components. This made a lot of people extremely unhappy.
None of the alternate component sets were satisfactory, because none of them were as complete or feature-rich as the v2 component set. And so we waited for someone, anyone to step up to the plate. We waited for MCOM to complete its vaunted component set, which would supposedly save us all from the bugginess of the v2 architecture. But by the time they were released, Flex 2 and AS3 was just around the corner — why bother?
I say this not to gripe for the sake of it, the past is the past, but to emphasize that Adobe should never, ever, EVER repeat this mistake ever again. This one goof nearly killed component-based development for the Flash Platform back in the day, only to be saved at the 11th hour by Flex 2 and AS3. So obviously
MacromediaAdobe has learned since then.
Many of us cheered a massive hurah when Adobe announced plans to open source the Flex SDK. Alas, we were now saved from a fate worse than death by having to use closed source components. To the Flash developers in the trenches, the ones who sweat blood and tears to make Flash live up to its potential, we are glad not to have to hack our way through closed code with a chainsaw just to build good apps. Thank you for opening up, and later open sourcing the Flex SDK.
But lot of developers working with legacy AS2 code are still not happy. I’ve even seen development teams violating the EULA and decompiling the entire component architecture, just so they can fix a few things and put out a stable version of their application. So it would be a bit of an understatement to say that it would be a saving grace for them, or if nothing else offer some sort of closure on the issue for the rest of us who have moved on, if the
MacromediaAdobe Flash v2 component set were open sourced, at long last. Better late than never.
And while you’re at it, Flex 1 & 1.5 and all the cool MM Dev Kit components that rarely saw the light of day outside of Flex 1-land.
Adobe, if you really want to embrace the open source movement, you need to do this, for your loyal community of Flash developers who have stood by the technology through the years and helped nurture it to what it is today.
A plea from a passionate Flash and Flex Developer.“
Everyone who feels the same way that I do, lend your voice here or on the Open at Adobe blog, and maybe we can finally get that train into the station at long last.
As I commented on the Flash In TO forums, great article. Should go a long way to dispelling a lot of myths and apprehensions that beginners have about delving into AS3. Every college multimedia teacher and Flash instructor should give this to their students.
Although I do have to disagree with Moock on one fundamental point: you do need to teach basic OOP principles to beginners for them to get AS3. In AS2, you could get away with not learning about classes and objects until you used some of the Flash 7 API stuff like MovieClipLoader, and it was essential to do anything with Flash 8 API classes such as BitmapData or Tween.
But teaching OOP to beginners is not the daunting task most instructors or writers think it is. In fact, if you teach the basics of OOP — what is an object, what is a class, class inheritance — without getting into building custom classes, you’re doing beginners a huge favour, and will vastly increase their comprehension of the material. I usually find a Taxonomy/DNA metaphor works best when explaining OOP concepts.
I’ve taught an AS3 course the old way, without OOP until the end, and with a discussion of OOP right at the start, and I’ve found that students absorb the material much easier when exposed to the concept of objects and classes and inheritance right from the start. If you don’t teach them OOP at the very start, you’ll find there’s a barrier of comprehension when they try and increase their knowledege to an intermediate level (i.e. coding with advanced API functionality, but still on the timeline). And you can talk about OOP and still teach timeline-based coding.
The one argument I’ve heard arguing for AS2 being easier than AS3 are events, or more particularly the new event model. As an advanced ActionScripter, it’s heaven. But I have to agree, for the novice ActionScripter, events in AS3 do seem more complicated. Although, like I mentioned, I found that once students had a firm understanding of objects, classes and functions, the leap was not that large. What is crucial in the understanding of the Flash designer is whether they get function scope. Once they understand function scope, the benefits of the AS3 event listeners over AS2 event handlers is evident. The disadvantage of AS event handlers does not become obvious until the student moves into intermediate projects, and they wonder why their project isn’t working, because AS2 doesn’t use closed methods. It’s far harder to explain mx.utils.Delegate than to show them the AS3 event model IMO. So to the novice who is used to learning AS exclusively by doing, yes learning AS 3 may seem harder on the basis of the AS3 event model. But once they actually understand the fundamentals, the benefits of AS3 become obvious and this perceived barrier to learning is not so daunting.
Slightly OT, there are a few things that piss me off about AS3 I wish they’d continued from AS2, such as private constructors (though I understand the reasoning behind this move), and the lack of equivalent for the AS2 onReleaseOutside event. But the advances in so many other areas in AS3 far far outweigh these annoyances.
As Colin mentions, another great resource to convince would-be AS3-ers is Grant’s 50 Reasons ActionScript 3.0 Kicks Ass. :)
On the whole an excellent article.