Joeflash’s Enigmacopaedia


Flash and Math AS3 Tutorials

Posted in Flash, Tutorials, ActionScript 3.0, Visualizations, Flash CS3, Math by Joeflash on the January 16th, 2008

Whilst doing some research on the mysterious MainTimeline class, I bumped into this really neat site which has all kinds of cool tutorials on using advanced math to craft Flash animations and effects. It’s also got some pretty decent beginner’s tutorials on the AS3 and Flash CS3 in general.

On their site, they indicate,

The website evolved from our ongoing project sponsored by the National Science Foundation and the Mathematical Association of America whose purpose is to empower educators in math and sciences to create web-based teaching materials using Adobe Flash. As a part of this project, we have been developing a collection of ActionScript 3 tutorials.

Wish I had this resource in High School…

In the process, we have dicovered that these tutorials are of interest to the general Flash developers’ community.

You betcha!

FlashAndMath.com

Check it out, it’s a gold mine.

Flash R Flex 4 Teh Win?

Posted in Flash, ActionScript 3.0, Books, Flex, Workflow by Joeflash on the January 15th, 2008

Sean McSharry, co-author of Foundation Actionscript 3.0 with Flash CS3 and Flex, has issued a challenge to the community in giving out free copies of his book.

The challenge is: “Which is better and why: Flex or Flash?

Since my answer was unexpectedly long-winded, I am reposting it here.

Let us assume by Flash we mean both the Flash CS3 IDE and its compiler, and by Flex we mean Flex Builder and its MXMLc compiler.

a) Different tools for different jobs. Neither is better.

From a design standpoint, Flash CS3 as an authoring environment is better suited toward designers creating interactive or “branding-oriented” gaming experiences which do not rely heavily on data enablement, due to the ability to create timeline animations using the design tools.

The Flash workflow can also be used to create component-enabled solutions using the CS3 components (fl.*), which results in a much lighter weight application, though this advantage will be less important when Flex 3 comes out with Persistent Framework Caching RSLs.

The Flex workflow, on the other hand, is a coding-centric environment for creating component-centric data-enabled applications using the Flex component framework (mx.*). Flash CS3-based projects can be data-enabled, but the Flex framework has more tools for large-scale data integration, and the CS3 component set lacks data-enabled components such as Tree or DataGrid.

So, tools for the job: do you want expressiveness and possibly light-weight components for your project, or do you want a component-centric large-scale data-enabled application?

b) Since both the Flash CS3 compiler and Flex Builder/MXMLC compiler both produce SWFs aimed at the Flash Runtime which are based upon the core ActionScript 3.0 language/Flash API, both are better.

Both workflows can be leveraged intelligently to create both visually engaging experiences and data-enabled large scale applications. Flex component-centric data-enabled applications can leverage Flash assets developed using a Flash workflow. In other words, Flash assists a Flex project.

Another workflow use-case scenario, is that the Flex workflow can be used to create “Flash”, i.e. pure ActionScript 3.0-based applications (flash.*) which are not component nor necessarily MVC-based, and does not require the use of the CS3 or the Flex component frameworks. An example of such an application would be a very complex interactive game or 3D simulation using PaperVision 3D, Sandy or a physics engine. Since as of Flex 3 the Flash-Flex workflow is be more closely integrated, both can be used in the workflow. In other words, Flex assisting the development of what might have previously been considered a “Flash” project.

In other words, an ActionScript 3.0-based project which is not dependant on either the CS3 component architecture, or the Flex component architecture, can use either Flash, or Flex, or both authoring environments in its creation.

In summary, the answer is: neither, and both, are better.

Flexers and Flashers and Writers, Oh My!

Posted in Enigmacopaedia, Flex, Community MX, Employment by Joeflash on the January 14th, 2008

I thank Adobe for aggregating this blog on the MXNA. Without aggregation, posting on a blog feels like whispering in a desert: someone may hear you, but you’ve got to shout, so to speak. :)

For those of you new to this blog, here are the most recent posts:

Staffing Flex Developers (And the Upgrade or Die Syndrome)

Posted in Flash, Business, Flex, Thermo, Employment by Joeflash on the January 14th, 2008

Today I came across a very interesting post by Yakov Fain, who comments on staffing a team for your Flex project. In it he divides the different kinds of roles and skillsets necessary for a well-balanced team into three categories:

  1. Flex GUI developers
  2. Flex component developers
  3. Flex architects

This is remarkably similar to the three categories of “Flash worker” I proposed in
my post here and my HR whitepaper here:

  1. Flash Developer
  2. Visual Flex Developer
  3. Enterprise Flex Developer

The interesting thing is that Yacov comes from a background as seasoned Java programmer and project manager with substantial experience in forming teams of Flex developers, so you gotta know he’s eaten the dog food an drunk the cool-aid on this topic, to mix metaphors. Whereas my perspective is as a Visual Flex Developer/Flash Platform Developer, having been on a few such Flex development teams in my consulting work over the last few years, and seen them succeed or fail in part based on the presence of balanced skillsets as described by both Yacov and myself.

Yakov’s assessment nails the staffing situation on the head, and feels validating when I say to a prospective client (in different words), “Hey that’s great that you have a team of Java developers who have just picked up Flex, but don’t you think you might need a few Flex developers (like me) who have actually grown up with the technology and know how build a decent interface?” ;)

Of course the converse can be true, like when I’ve been asked to build a full-blown data enabled enterprise application, and I have to tell the client, “well, you might need a Java or ColdFusion developer on your team who knows a bit more about these things than I do”. I am not ashamed to admit it: (for the moment) I am not a server-side enterprise developer. Tools for the job.

I also occasionally meet Flash Developers or Visual Flex Developers who think that they need to learn Java and enterprise frameworks just to compete in today’s Flex development marketplace. I myself struggled with that question until quite recently, convinced I had to go out and get a Comp. Sci. degree just to get ahead. But in the past six months of consulting, the market has proved otherwise, as clients find my depth of experience with ActionScript 3.0 and the Flash Runtime (amongst others) to be an invaluable asset. I’ve even ventured into the realm of architectural planning on my last few projects. So there is hope yet for us “Flash boys” (and grrls ;)).

So now I tell some of my colleagues still struggling with the issue of “upgrade or die,” that in this rapidly expanding market for Flash and Flex Developers, there is a place for “Flash workers” of a wide range of skillsets. Thermo will open up that vista even more when it comes out.

It’s all good. :)

Flex 101: Part 14 - Using the Event Subclasses

Posted in Tutorials, ActionScript 3.0, Flex, Community MX, Flex 2 by Joeflash on the January 13th, 2008

The latest addition to the Flex 101 series is now available on Community MX. In this tutorial we go into the Event subclasses — what they are, when and when not to use them, complete with examples. We describe when certain event classes are dispatched from component interactions, what classes to type to depending on use, and the event class package and inheritance structure in Flex 2.

Flex 101: Part 14 - Using the Event Subclasses

So You Want To Hire a SWF Developer?

Posted in Flash, Business, Flex, Adobe, Workflow, Employment by Joeflash on the January 10th, 2008

Almost every time I speak with a new recruiter, I find myself explaining what a
“Flash Platform Developer” is, and what the skills listed on my resume mean in the overall context of RIA development. Or having conversations with project managers and HR personnel about why it may be necessary to hire two different kinds of Flex developers, unaware of the distinction.

Lurking in the background of such discussions was a subtext, an underlying question: “what do we call the person who builds SWF files for a living, and what exactly do they do?”

Following my previous post and ensuing discussions with fellow developers, I thought it might be useful to publish an article on the topic of (re-)defining these developers, given recent and upcoming changes in the technology, and in the employment marketplace.

This free Community MX article, entitled ‘So You Want To Hire a SWF Developer?‘ serves as a whitepaper for recruiters, HR personnel, managers and developers looking to get to grips with defining and hiring various people who “build SWF files for a living.” *

* Okay okay, so you got me, smarty pants: any one of these developers can publish for Flash, AIR or Flash Lite runtimes and not author a SWF file, I had to call them something…

More Reasons to Use Flex

Posted in Business, Flex, RIA by Joeflash on the January 7th, 2008

Following my post the other day on reasons to use Flex for RIA development, I stumbled upon an excellent post by InfoQ regarding Top 10 Adobe Flex Misconceptions, as well as an excellent blog comment regarding why to use Flex (as opposed to certain supposed \*ahem\* competitors).

I Do Like Writing Books, Sam I Am

Posted in Geekness, Tutorials, Business, Books, Training, Community MX, Inspirations, Personal, Presentations, Publishing by Joeflash on the January 5th, 2008

I do like writing books, Sam I Am… I would write them on a train, or in a plane, in a tree, they are so good, so good, you see!

:P

I am writing this partly in response to Jesse Warden’s post “I Will Not Write a Book“, partly in response to all those enquiries about helping out with the upcoming Professional Flex 3 book, partly to share my experience for all those writers-to-be.

There are several reasons not to write a book, as Jesse mentions:

  • the money generally sucks
  • it’s a huge effort
  • the return is not tangible, or obvious
  • I could be playing XBox

For me, though, there are several more reasons to actually write a book or pen a tech article. The most obvious one is that I’ve always loved writing, and have kept a journal with miscellaneous thoughts and ideas since I was 14.

I also love to teach, even though I don’t do that much of it these days. I caught the teaching bug by giving private Flash lessons back in 2002, and achieved one of my dreams when I worked at Humber College in 2005-2006 as a Flash instructor, and later as an Adobe Trainer with New Toronto Group. I love watching students’ eyes light up as they figured out a key concept in class, almost as if I could see the light bulb going off in their heads. Sharing in that Eureka! moment is what makes teaching very special for me. Giving a lecture or seminar, or penning an article or writing for a book holds a similar fascination.

I also remember being inspired by the Visual Quickstart Guides and Friends of Ed books back in the Flash 4 and 5 days, by so many authors. I still get inspired by a good “Flash” book. My latest favourites are Head First Design Patterns and ActionScript 3 Design Patterns.

Now that I’ve learned a thing or two worthy of sharing with others on their learning path, to have the opportunity and the potential to inspire others, knowing that somewhere I will have contributed to more Eureka! moments as I have been inspired and coached, is a real honour. That is mostly why I write.

In describing motivations, I won’t use the word “selfless”, because I dislike thinking in those terms, for me it reinforces the notion of martyrdom — if writing for you seems selfless, as in thankless, as in feeling like a martyr to the Great Hordes of N00bs, you’re missing the point IMO.

I would also not describe the motivation as one of ego. Sure, it’s nice, seeing one’s name in print or a book on the shelf (which I have yet to experience, but I’m sure it feels good ;)), one’s name on a course completion certificate as the instructor, or an article in a reputable journal. It’s a validation, a reward for all the hard work of sharing the work and building community and paying it forward that to me says, “see, I’ve done something important, I’ve built something.” But if you let this feeling of validation, of recognition become one of the dominating raisons-d’être of your teaching or writing, the result becomes some twisted, misshapen thing funnelled through the lens of your own selfish need for gratification. I’ve seen a few developers who take the stage go all starry eyed after a few lectures, and have even fallen prey to that beast myself on occasion. Writing is also similar in this respect.

Make no mistake, more often than not the money totally sucks. As Jesse pointed out, I also could make ten times more money in consulting. It’s a given that people don’t write books for the money, it’s more of a fringe benefit than anything. That’s not to say that tech writing is completely without tangible payback. Sometimes, the money is actually pretty good, even if it isn’t a primary motivator. I don’t think I could stay committed to the hours it takes to consistently produce well-written tutorials for Community MX (with a little help from the editors ;) ) without some reasonable renumeration. At first it was hard work, but after two years of writing two or three articles a month, you develop shortcuts and tricks for quality writing that make the mechanics of it less of a chore, such that now writing for that publication is actually a pretty decent part time job for me.

And the other month my agent brought me a book for which the advance was equivalent to a few months’ salary, which granted is not the norm, but it made the proposition an interesting one to be sure — I could do it part time for four months and maybe have to either lessen my consulting workload or work 80 hours a week, or I could just take a few months off and do nothing but write the book. As it turns out the commitment was too great, so I turned it down in favour of the Flex 3 book I am currently writing. So it can pay, not nearly as well as consulting, but it can have a financial benefit to offset some of the long hours.

I won’t blow sunshine up you arse and tell you that I’m not doing it for a little self-promotion as a freelancer. I think every author is in it for that angle to some degree, whether it’s for one’s own consulting business or the company you work for, even though it’s not something we like to advertise, lest people get the wrong impression. There is no question as to the networking angle: I have gotten consulting gigs based my writing exposure, as well as the many other ways of meeting people such as workshops, lectures, conferences, training sessions and discussion forums. So there is definitely a benefit to improving one’s visibility in the community.

There is also the spirit of sharing, which I equate less to “a selfless desire to build community,” which is more a result than a motivation, as it is a desire to share some awesome thing and totally geek out on the coolness of some shiny new toy. Which to my mind is very similar to the drive programmers have to develop open source code and blog about their discoveries. It’s announcing to the world, “hey check this out! Isn’t this like, SO COOL DUUUUDE! Geekout, man!!” (okay, I would never actually say that, it sounds dumb, but you get the idea.)

And then there is the self-exploration angle. Someone once said, “I write to know what I think.” * For me, there is a very direct and personal gain I get from writing. Because this particular book I’m writing now is on the cutting edge of the technology, it feels a little like writing a PHD thesis (not that I’ve ever written one, mind you), where you log the results of experiments investigating new territory, with empirically verified results for other scientists to replicate. And in every tutorial I write, no matter how basic, I always discover something new, reinforce something I thought I knew, and boy, do I ever know it well now. So writing actually makes me a much better programmer. In fact, I don’t know how I could remember half the stuff I know without having written about it.

* I’m killing myself trying to find the author to that original quote. If anyone knows who said it please let me know. Some days the internet feels like a billion terrabytes of utter shiite when you’re looking for something that should so obviously be there.

I am excited to be writing my first book on Flex 3 with a group of superbly talented individuals, none of whom need another book under their belt, believe me. The fringe benefit of writing this book with such brilliant people* is that I would have never met them otherwise. And writing these past two years alongside the likes of Tom Green, Stephanie Sullivan, David Stiller and many many more has been a huge huge honour, and to be considered a close acquaintance and even friend by some to be an even bigger honour still. So another benefit to writing is meeting such cool people.

* Sorry I cannot announce who else is on the team at this point because the co-author lineup has yet to be finalized)

So to summarize, to me the benefits of tech writing in general are:

  • I get to inspire others and share in their victories
  • I get a warm and fuzzy feeling of accomplishment
  • I get to geek out on sharing cool shit I’ve discovered, or cool shit others have discovered
  • sometimes it actually pays
  • I am a much better programmer as a result
  • I may even get a contract or two from the exposure
  • I get to meet cool people in the industry I’ve admired for years

And if everything I’ve been coached on by my estimable colleagues and my agent is of any indication, writing books is indeed hard work, make no mistake about it, so I can see how one could get burned out on them if you don’t balance your life. Granted, most of my experience is in article writing and teaching for the moment, so my enthusiasm for book writing may be premature, but somehow, with the proper perspective and balance, I think these words will still ring true for me in a few years to come.

When evaluating enquiries in response to my call for writers, if the first question in the email was “what’s the compensation,” forget it, out to lunch, not even worth a reply. Or if the email did not contain a link to any work or writing of any kind, ditto. You’ve got to give something to get something. So I apologize to those whom did not get a reply to their queries; many of you did.

You’ve got to be passionate about sharing knowledge to do technical writing, and it can’t come from a place of ego or martyrdom, and you’ll need to balance your life carefully to go the long haul. Humility and generosity are huge must-haves if you’re going to go into this. One starts in the writing biz much like in programming: at first you get volunteer, pro-bono work, like tech editing or making a contribution, eventually making a name for yourself in training, teaching or publication writing, and eventually graduate to being asked to co-author or write a book on your own. And it need not be a thankless job without tangible recompense: if the money is not good enough, hold out for another book, another writing avenue, or go into corporate training.

It’s a long, arduous road, but if you’re passionate about it, it’s worth it in the long run, so I’ve been told, and based on what I’ve experienced thus far on the path, I am certain that is completely true.

Why Flex for RIAs?

Posted in Business, Flex, RIA by Joeflash on the January 4th, 2008

A colleague of mine recently emailed me asking if I knew of what amounts to an authorative Flex adoption whitepaper for RIA development for a client of his. My reply to him was:

They can check out the Adobe Flex Product Page, but I guess one authoritative text could be this O’Reilly booklet by Effective UI, even though it is a little dated: Flex Early Evaluation: Assessing Flex and Your Project Needs, which the benefits of RIA development in Flex in a formal, documented fashion.

You can also refer them to this tongue-in-cheek expose of Top 10 Myths about Adobe Flex 2.0 by Adobe’s Ted Patrick, and this video overview of the technology by James Ward entitled Flex, Flash and Apollo for Rich Internet Applications. If you want a great examination of real-world capabilities, check out James Ward’s Ajax and Flex Data Loading Benchmark application, which tests data transfer benchmarks for a variety of technologies.

Proof of Flex’s rising ubiquity can be had by going no further than Google Trends, or a recent news announcement that NATO now used Flex in its information delivery systems, or that Adobe has just been inducted into the Intelligent Enterprise 2008 Editors’ Choice Awards, as one of “the 12 companies that will matter the most to the intelligent enterprise in 2008.”

What more evidence do you need?

:)

What kind of SWF Developer Are You? (and how to hire them)

Posted in Flash, Business, Flex, Adobe, Workflow, Employment by Joeflash on the January 3rd, 2008

A few days ago I participated in an interesting discussion on Paul Ortchanian’s blog about approaches to SWF development as a way of categorizing the-dude-who-builds-SWFs, and it made me think of all those conversations I’ve had with designers, developers, project managers, recruiters and HR people looking to get a handle on this.

In response to Paul’s post, since there are more than five ways to build SWFs, what with open source compilers out there, I am not sure if it’s fair or even accurate to refer to the kind of developer by what tool they use to compile a SWF file or application. In my view the terms Flash Developer and Flex Developer are pretty accurate descriptions of job categories, though there could be further clarification to be sure.

I would categorize “SWF developers” or “Adobe-based programmers” into five types:

1) The Flash Designer

This is more of a graphic designer who specializes in animating with Flash, and knows enough coding to muddle through creating some visually stunning experiences, but is unable to code any kind of data-enabled or component-based application. They generally excel in illustration, 3d modelling and animation design, with a little bit of AS and HTML/CSS coding experience.

2) The Flash Developer (otherwise known as the “Flash Designer-turned-Developer” or “ActionScript Programmer”)

This is the AS2/AS3 developer who more often than not uses the Flash IDE for development, but may also use a third-party dev tool such as SEPY, FlashDevelop or even Flex Builder. They are not particularly interested in using MXMLC or the Flex Framework, and stay closer to visually expressive than business-focused application development. Their advanced knowledge of ActionScript enables them to create visually stunning dynamic animations using things like PaperVision3D and physics engines. Most often this type of developer started off learning Flash from a designer’s point of view, and graduated into ActionScript development later on.

[ update 2008-01-04: ] Another term for a Flash Developer might also be “ActionScript programmer,” who may or may not have started with the design tools in the Flash IDE. A PHP/ASP/CF/etc. programmer who now codes primarily in ActionScript without using Flex or much of Flash’s design tools can also be considered a Flash Developer.

3) The Visual Flex Developer (otherwise known as the “Flash-turned-Flex Developer”)

This is a Flex developer who grew up with Flash, became a Flash developer, and decided to migrate to Flex rather than focus exclusively on AS3 development. These developers may not be as knowledgeable as their Java/.Net/C counterparts in building architectures, but their intimate knowledge of the Flash runtime’s capabilities, as well as the ability to code expertly in low level AS3, make them equally as valuable.

[ update 2008-01-04: ] The Visual Flex Developer might also be adept at enterprise development, but their strongest skill is client-side programming rather than server-side programming.

4) The Enterprise Flex Developer (otherwise known as the “[insert language here]-turned-Flex Developer”)

This is the Flex developer who started out in other languages such as Java, .Net or C, and has recently graduated to Flex. They don’t know a whole lot about the history of ActionScript (if at all), and they don’t care about timelines or animation — they want to focus on patterns, server-side integration, data-enabled applications, enterprise development, frameworks. They may be a novice in the particulars of the Flash Runtime and low level AS development, but they generally know a lot more about advanced programming concepts than most Flash developers. You hear most of the bitching about “why AS is not more like [Java/C/Python etc.]” from these types of developers.

[ update 2008-01-04: ] As was pointed out to me by a colleague on FITO, it is conceivable that an ActionScript programmer with experience of server-side coding and enterprise deployment might take up Flex, in which case they would also be an Enterprise Flex Developer, hence the assertion “[insert language here]-turned-Flex Developer” remains true, even though the term implies that the stronger skillset is in server-side languages and enterprise development workflows, with client side development in ActionScript & MXML being second.

5) The Flash Platform Developer (otherwise known as the “expert jack-of-all trades swf developer”)

This is someone with a lot of experience in coding for visual Flash applications built in AS2 and AS3, knows how to develop in Flex, including enterprise application programming such as design patterns and architectural frameworks such as Cairngorm. They can also develop for most of the Adobe SWF-related technologies such as FMS, LCDS and AIR and Flash Lite, including knowledge of server-side languages such as Java, CF and PHP.

Although generally used as an umbrella term which can apply to any one of the preceding developer categories (#2-4), I consider the title a mark of mastery (or mastery-in-the-making). I’m not too sure if one can consider oneself a master of such a constantly evolving range of technologies, so I use the term loosely.

[ Note 2008-01-04: for a primer of Flex-related technologies, read “Flex 101″ parts 1 and 2 of the series, free on Community MX ]

Like Paul Ortchanian, I have an issue with the how low the salaries still are for the very competent and advanced AS3 developer. Though there is a tendancy by the industry to categorize the above types of “SWF developers” according to pay scale in the order above, with #1 being lowest to #4 as the highest paid, with the exception of #5, all four types of seasoned professionals should be worthy of an equally high salary in my opinion, with #5 worth a slight increase beyond that.

I think the reason that Flex developers generally get paid more, is that Enterprise Flex Developers ideally have a knowledge of enterprise development that most Flash Developers do not posses, and Visual Flex Developers have the ability to code a Flex application, with all its architectural complexity, get down and dirty with the ActionScript code, and add some expressiveness to the application to boot. And, as it so often happens, salaries are driven by market forces: experienced Flex developers (whether Visual or Enterprise) are in high demand, whereas there is a perception in the interactive media and advertising industries that experienced Flash Developers are abundant, including a tendency in the industry to commoditize creative talent, so their salaries are generally lower.

I personally became a Visual Flex Developer (aspiring towards Flash Platform Developer-dom ;)), for one, because once I tried Flex Builder (and more particularly Eclipse), I could never go back and code in that stone age editor in the Flash IDE. (Flashdevelop has since provided a route for me on my AS3-only projects.)

Secondly, by acquiring skills in Flex application development, I was able to take on a wider variety of freelancing jobs: I can take on an AS3 project if I’m in between Flex projects, so the work is more consistent.

Third, building enterprise Flex apps using patterns are more challenging for me than building pure AS3 projects, most of which are pretty simple in their use of OOP and design patterns.

The industry that tends to develop Flex apps is also different, the client expectations are different, and so are the projects. Flex projects I participate in generally are less about procedural code born out of impossible deadlines from a “let’s just get it out there in time for the next marketing launch,” and more about building robust applications. So the timelines are longer, the project planning and workflow is better thought out, so there is less stress, for more money. I realize I’d been looking for that kind of workflow and clientèle all along in my Flash projects, so to find it being a Flex developer really made the transition a non-decision for me.

I have also talked to more than a few project managers and HR people who seem to be following the growing trend to hire Flex developers with little or no actual Flex development experience, which flies in the face of all common sense. Although I partly understand the reasoning: unable to find Flash Developers with sufficient experience in Flex and backend languages, design patterns and large-scale development, companies are looking for Java and .Net people who can pick up Flex.

But I’ve yet to see a workflow where a Flash Designer and what I call a “Novice Enterprise Flex Developer” can talk on the same wavelength most of the time. What a lot of teams need is a Visual Flex Developer, or even better, a Flash Platform Developer, to bridge the gap between the designer and the enterprise Flex developers. A well-rounded Flash platform RIA development team should have Flash Designers, Visual Flex Developers and Enterprise Flex Developers in its workflow, as well as server-side developers and junior support staff.

With a well-balanced team possessing the range and depth of expertise required, an enterprise project has a much greater likelihood for success.

Next Page »