Flex has a short learning curve for Java developers, who will find that there are a lot of familiar language constructs and patterns. It also provides excellent remoting capabilities for Java programmers, allowing transparent data transfer between ActionScript and Java 1.4 data types. With Java version 5 and above in production for a while now you have a lot of Java data structures that use enum and need marshaling to/from the Flex applications. This article provides a working example of the ActionScript language extension for an enum data type.

Some things that I learned early in my career that originally helped me succeed, I believe are now hurting me in job interviews. One of the pros to typing via dynamic languages and forgiving compilers such as ActionScript 1.0, Ruby, JavaScript, and others is that you can quickly code things that work. In a lot of the early agency, multimedia, and small software company work that I did, these technologies were great. They didn't get in your way, and they empowered you to quickly create programmatic solutions that were enhanced or even driven by good designers. You could hit insane deadlines, recompile changes quickly for a client, and react flexibly to ever-changing, almost fluid requirements...if any.

Did you know ActionScript 3.0 supports multiple inheritance? Here's how... Multiple inheritance is actually possible with AS3, despite popular belief that it's not supported. It's not really multiple inheritance in the true sense of the word going by the strict definition... but there's a way to get the job done in AS3 that behaves almost like the real thing.

The subject of this piece is how to pass parameters from HTML to a Flex 2 application using flashVars parameters.

In Java, if you've created an object from a particular class, you can use only properties and methods that were defined in this class. This is not the case in ActionScript 3. This is one of the examples of unusual (from the OOP perspective) programming techniques.

While a large Flex application is loaded, the user may experience unpleasant delays, which can be used productively to logon to this application. Besides, it'll give the user perception that your application loads faster.

Depending on the scope of your project, you may have the opportunity for code reuse. The reasons you might want to do so are two-fold. First, you reduce duplication of efforts. If you have already created a hyperlink enabled CellRenderer for your DataGrid once, why do it again? Second, you create, or build upon, an ever growing utility code base. While it may not be in the 'utils' package per se, you'll soon end up with re-usable events, common GUI controls and widgets, and yes even utility classes. Whether by merely being in a different folder means the client doesn't own it is up to you or your sales team.