Forced to FLEX

I am on a project where we are delivering a web-based mapping application to the client.  The application has gone through every UI scenario you can imagine: Virtual Earth in Sharepoint to ArcGIS Server Web ADF to ArcGIS Server Javascript API to (presently) ArcGIS Server Flex API.  The Flex decision was made against my recommendations.  I don’t have a lot of ammo against Flex, but I was born and raised in JavascriptTown, HTMLandia.  I have read some HTML/JS vs Flex posts and seen all kinds of opinions, and my research has led me to the one true answer to this debate:  It depends.

As with many technical decisions you meet when creating applications for the web, you need to let your context by your driver.  Trust me, I wanted to take HTML Hill and dig in for the victory-or-death battle, but the client liked a couple of Flex sites.   I mean really liked them.  So, rather than just fight the “but that doesn’t look like Flash” battle constantly (even though I think we could win…let it go…let it go…) we are using Flex.

So, I am a lot like my kids eating their spinach.  They get why they have to do it, but they do it begrudgingly and with a nasty look on their faces.   And, much like the vegetable-hating youngsters, I am reaping some benefits:

  • Knowledge is Power. Learning a new language is always a good thing.  One of my favorite books, The Pragmatic Programmer, encourages developers to learn a new language each year.
  • Flex is a good language. Flex has been refreshingly enjoyable to write.  While I still prefer my HTML with a massive heaping of Javascript sauce, Flex (and ActionScript) is a great language (and a ECMAScript standard, like my beloved javascript).
  • Somes things are easier. Some stuff is easier in Flex/Flash.  The best example is probably cross-domain URL access.  If you want to allow a Flash object to access a URL, you put an XML file (crossdomain.xml) in the root of that site.  You can allow access to anyone, or domains, or all kinds of options.  Having struggled mightly with AJAX/REST scenarios involving the same-origin policy, this was really, really great.  Also, the UI is just easier to create.  Sexy, translucent panels and easy drag/drop capabilities come to mind.
  • Flex tries.  Flex does it’s best to use some web paradigms, like CSS stylesheets.  Many of the style properties are specific to Flex, and I don’t profess to understand even half of them, but it made me feel a bit more comfortable.

Now, from the “I told you so” vault, some of the cons:

  • Accessibility (duh).  If we want this web application to be usable on multiple devices (iPhone, screen reader, etc) then we are gonna have to write a totally different interface.  I understand that even in HTML land there is some of that, but it’s easier and allows for more UI code reuse.
  • Unit testing.  While there are a good number of Flex unit testing frameworks (FlexUnit, ASUnit, Fluint, FlexMonkey, and even RIATest (commercial)) they are all difficult to use in my opinion.  Now, part of this reason is because the map is a custom component and is not friendly with the Flex Automation Framework out-of-the-box.  We have struggled finding a unit testing framework that we like, but I think we’re about to settle on Fluint.
  • Continuous Integration.  After unit testing, the next step is continuous integration, and I have no answer for this one yet.  Yes, I know there are things out there like Hudson, Maven, flex-maven, as well as a series of posts on CI with Flex using CruiseControl.  I think my main issue here is my .NET bubble.  We have other services and applications under development for this client, all of which are .NET based.  We have CruiseControl.NET for these .NET based items (thanks CIFactory!) so I have spent much of my time trying to figure out how to integrate our Flex app into that CI setup.  I think this is the wrong approach and we’ll ultimately have to create a separate Flex only CI server.

The best part apart this project has been actually working with a team of developers again.  My projects before this one were cowboy-ish in nature, so I was doing all the nerd stuff.  We have some crazy-smart people where we work, and it’s fun to tackle this new stuff with them.

While I still pine for my HTML/javascript/CSS/C#, writng the Flex stuff has been (and should continue to be)  a learning experience.  Speaking of learning, if anyone reading this has suggestions or approaches to unit testing or CI or anything else to a new bunch of Flex devs, please comment away.

Reblog this post [with Zemanta]
Advertisements

About Ruprict

I am a nerd that is a Nerd Wannabe. I have more kids than should be allowed by law, a lovely wife, and a different sense of humor than most. I work in the field of GIS, where I am still trying to find myself on the map. View all posts by Ruprict

8 responses to “Forced to FLEX

  • Jonathan Hartley

    Hey Glenn.

    There’s clearly something I don’t understand about continuous integration, because I’ve only ever done it in Python land, and while we have flirted with CruiseControl.NET for a while (since we’re IronPython, hence .NET), in the end it had one or two wrinkles that we didn’t like, so we wrote one ourselves, and it turned out to be about ten lines of code:

    while True:
    check_out_source_tree()
    compile()
    run_all_tests()

    And those function calls are actually just synchronously calling external command-line processes, right?

    So what else does everyone else’s continuous integration server do that makes it so hard?

    I guess running the tests also stores the test results in a database, for perusal at our leisure, but I consider that to be part of the test runner infrastructure, not CI.

    Incidentally, the cool part about our CI is that since creating it, we’ve now got it to distribute the running-of-the-tests across all the idle machines in the office (so it’s no longer just ten lines), since our acceptance and stress tests take a long time to run otherwise.

    Hugs, etc!

    JB

  • jeffreyfredrick

    “we’ll ultimately have to create a separate Flex only CI server.”

    I’m curious on the reasons behind this and I’d love to spend some learning about the CI needs of flex developers.

    The office space I’m working in these days is filled w/various web designers but they don’t have a CI background.

    “if anyone reading this has suggestions or approaches to unit testing or CI or anything else to a new bunch of Flex devs”

    I don’t personally have experience doing this with flex but you might try asking on the CITCon mailing list.

  • ruprict

    @JB: Maybe there’s clearly something I don’t understand about CI. You are exactly right. The automated build and tests are simple steps. CIFactory, while it makes deploying CI easier, also takes care of a lot of the details (setting up the service, which is CruiseControl.NET, offering the plug-in framework to extend) which is great. However, the risk of using a framework like this is that you don’t know the details.

    You bring up a great point, tho. I bet we could write a simple CI server ourselves…..maybe I’ll do that.

    @jeffreyfrederick: I will certainly blog about whatever we figure out. Thanks for the suggestion on CITCon…I’ll check it out.

  • jeffreyfredrick

    @reply.both 😉

    I’ve been working on CruiseControl for several years and I’ve heard the question “isn’t it just a fancy cron” for about as long. 🙂

    Writing a simple CI tool is simple, no question.

    The obvious thing you get from using an existing tool are the publishers, the web interface, etc. The non-obvious thing you get is the benefit of 3rd-party stuff and a support network of other users who might have already solved the same problems you’re trying to solve.

    So my own preference is to use CC as a framework and put my own custom efforts into extending it where I need. I get the benefits of having custom control but with the benefit of not starting from scratch.

    I just went through this very recently to start using CC with Xcode. To make it work I only had to write a single class, the XcodeBuilder. And that’s why I was curious about the needs of a Flex developer. I was wondering if it would just take 1-2 classes…

    But in the end the important thing isn’t how you’re doing CI, just that you’re doing CI. 🙂

  • quetwo

    You mentioned accessability as a con of Flex, and I’m wondering why. As long as you do your programming correctly (and want to target devices like screenreaders), accessability is much more accurate and easier to implement than with most AJAX frameworks. Check out this video : http://link.brightcove.com/services/link/bcpid1733261879/bclid1729365228/bctid1738801382?src=mrss

    Now, as far as usability of your application on other devices, you that is a sticky subject. Even in AJAX, device support is all over the place, and not everything supports full JavaScript (or in this case, the Flash Player). Depending on how you write your app, you /can/ target Flash Lite in addition to the Flash Player, but that is not easy, and won’t win you the iPhone. If you are keeping your business logic on the server (which you should), you can make a version optimized for the iPhone, and even one optimized for WAP devices. Remember, the Flex Framework is just the UI, so it shuold be interchangeable with other versions on the fly depending on the end user and device.

  • ruprict

    @jf: You’re probably right. Once the Flex SDK is installed, it should be easy enough to write a NAnt task (there are already Ant tasks for Flex) to do some simple CI (build, run tests, etc) and grow it from there.

    @quetwo: Truth be told, the accessibility dig was thrown in b/c of things I’ve read about Flash over the years. Accessibility has always been something the anti-Flash crowd (which I was briefly a part of) has used to push their case. I’ll watch that video and I bet I learn that I was wrong. Thanks for the link. The iPhone issue is a personal one for me, since I carry one. It’s not Adobe’s issue, tho, it’s Apple’s. Using an MVC type approach (which we do) changing out front-ends should be a non issue.

  • Jonathan Hartley

    >> 3rd-party stuff and a support network of other users who might have already solved the same problems you’re trying to solve.

    That seems very reasonable and relevant, thanks for bringing the idea to my attention.

    Also, the webservice: is that for publishing results to they can be viewed? We have that attached to our test runner, so that all builds (not just CI) can be viewed and analysed after the fact. Or have I got the wrong end of the stick again?

    Thanks for the post, and your others, I really like ’em.

  • tartley

    I don’t know if this is helpful or not, but by co-incidence, a new pico-CI script was announced today:

    http://morethanseven.net/2009/01/14/localbuilder-github/

    It’s nothing more than a ‘watch a directory for changes and then execute a command of your choice’ script (in Python), but I thought I’d mention it just in case.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: