Shifting to Flex October 31, 2008
Posted by headwinds in Actionscript, Flex.add a comment

Over the past 6 months, I’ve been spending most of my time in Flex Builder. I remember a presentation by Colin Moock when he announced the same thing about 3-4 years ago. I guess its taken me awhile to finally make the shift.
I’ve practically abandoned my previous favourite combo: Flash Develop and Flash CS3 for now. But why Flex 2 and not Flex 3? We were literally forced into using Flex 2 by our financial client who insisted we mirror their development environment right down to the 0S which in their case is Windows XP. I will briefly discuss how we were able to adapt to some of these restrictions without mentioning the client and project itself due to NDAs.
I’m working on a intel-based Mac; running vmware fusion with two monitors so that I can see my Mac on one screen and PC on the other.
On the Mac side, I have Flex Builder 3 while on the PC side I have Flex Builder 2. If you are a Flex developer, you may be wondering why we didn’t user Flex Builder 3 and compile using the Flex 2 SDK to meet that requirement. Every flex developer that joined the project had this same question
. We were simply told that this was not an option; that our code had to be compiled in the Flex 2 IDE. No problem.
Previous to this project, I only had a couple months experience playing around Flex Builder 3 so during the course of this project, I didn’t really feel that I was missing out on much but talking to some of the Flex Builders, we could have benefited from using things such as the Flex 3 Profiler to better manage memory and performance.
In the beginning, it appears that this project was sold through marketing/business arm with little IT involvement. This isn’t out of the ordinary though dealing with large companies. After several months of design and strategy, their IT tentacles apparently lay dormant until we started to deliver AS3 code during the first month of development, and then the monster started to blink its eye. I write this with tongue-in-cheek because we put a month of development into building a Flash-based application when wanted they really wanted was Flex. The fact that they wanted Flex — and not something like javascript/jsps — is a clear indication that the Enterprise has finally embraced Flash without knowing it.
Of course, Flash had to turn into Flex before this could happen. It would have been nice to use the Flash IDE to create some swc files especially to layout some complex, layered views that could be used in Flex but again their developers didn’t have access to the Flash IDE so that option was out.
I think Adobe’s has done a wonderful job of selling Flex to Java developers and convincing enterprise architects that Flex is secure [all our services were produced using AMF secure and Adobe's Lifecycle]; its built on familiar technology [Eclipse]; and compliments their development process. They almost did too good of a job. There is still a big disconnect between Flex and Flash when they could be perceived as being more harmonious in IT eyes.
It wasn’t that difficult for us to drop Flash for Flex, and our remediation process only added a couple weeks to our development cycle since we were also required to adopt their framework. Blast Radius has developed an AS3 framework based on a modified version of Cairngorm and our first build was based on it.
After meeting with their architects, we realized that we had to tear it out and re-build using their more Java Spring-MessageBus-inspired framework which they had already developed several Flex modules within it. Fortunately, they provided our team with ample documentation and were available if we had any questions about it. We also provided bi-weekly code drops so that they could review our code to ensure that it was consistent with what they had already developed in house.
We had several seasoned Flex developers on our team which I learned a lot from very quickly. This was a great strategy on our part; teaming up more raw AS3 Flash developers with Flex developers. We had a mandate to write code that looked as if it came generally from one hand. It seemed our most heated debates stemmed not from states or mvc patterns but syntax. A developer needs to breath a little bit of their own OCD idiosyncracies — whether it be lining up types or indenting attributes — into the code base, leaving their foot print. For instance, the views were ideal places for this to happen as long as we had consistent services.
Flex developers seem to be a rare breed here in Toronto, and I would like to give credit to the following flex contractors that made major contributions to the project and I would personally recommend them:
- Leigh Williams
- Alex Boudarov
- Ryan Favro
- Shant Adam
These developers not only made our team better; I’m sure their consulting also enriched our client’s team after many discussions and exchanges of expertise/knowledge.
What have we learned from this engagement?
Although we asking the right technology questions in the beginning, it became obvious that we weren’t initially talking to the right technology people; something was being lost in translation within their organization. When we finally did begin to bond with their IT group, great things began to happen in terms of team velocity, delivering code that they would be able maintain and extend. All in all, it worked out in the end which is most important.
This has definitely given us more confidence in our own emerging flex practice and I look forward future projects in Flex 3; Flex 2 not so much. Since I can’t show you any of the work, I’ll leave you with a Flex showcase as I know we are currently on the mark to add to this gallery and hopefully one day next year I’ll be able to talk more freely about it.
