jbablog.com

the personal blog of John BouAntoun


When Flash just aint flash - Part 1

So I’ve been working with the Flash guys in the design team at work now for a few months, trying to help them become more effective collaborative Flash developers. It’s not necessarily been the easiest process in the world as there have been a number of concepts that would be straight forward to most regular devs, but not necessarily Flash devs.

Some of the things we’ve gone through are concepts like:

  • Using SCM systems to store the code in a central location
  • Design Patterns (in particular the MVC and Command Factory seem to get allot of use)
  • Multiple simultaneous checkouts of text source files (or “how to develop without individual checkouts”)
  • Visually diffing two versions of a source file

And so on. Along the way I’ve actually had to learn a hell of a lot more Action Script than I would have thought I needed to and seen my fair share of Flash ugliness. I’ll probably do a whole series of these little rants, but this week in particular we kept coming across and trying to work around the same infuriating issue.

This has to do with Flash 8 (Action Script 2) and using the FileReference object to perform a multipart form POST to a server, that is, when you try to do a form submission that has a file upload in it and you care about the status of the submit. On most web systems this is probably a common occurrence; “Send us your picture and 25 words why you think you should win the …”. Sounds like a relatively straight forward thing to do in Flash, and in fact it’s not that difficult to code up.

The problem comes when your server tries to process the form upload/submission and send back some information to the Flash client about whether or not the submission succceeded (think form field validation). In theory a file upload is just another http request and the Flash client should have the ability to read the text in the response body. No such luck. It seems that in Flash 8, the FileReference object doesn’t expose the http response body upon completion, I don’t think the Flash architects thought it was useful. What the?

Why go to all the trouble to build a multipart form submission capability inside Flash and then decide not to pass on the response to the Flash client? What possible reason could they have for such a glaring omission of useful information in a standard web-type request/response scenario.

And just for clarity, we have a constant pressure to try and use the minimum version of Flash required to perform our particular task, so while this problem has been fixed in Flash 9, it’s rather annoying to have to change our system to use a whole later version of Flash for functionality that should have been there in the beginning.

SvnBridge: a local Subversion proxy to a Team Foundation Server

So I ran into this application over on codeplex the other day: SvnBridge. I’m impressed.

I’ve been using Subversion since the mono project adopted it many years ago, and was an instant convert. At the time the only real SCM systems I’d used before that were Visual Source Safe (VSS) or cvs. Subversion was such a breath of fresh air. (I’ll save my rant for any dev team with more than two devs in it that’s still using Source Safe when subversion is available for another time.)

Anyhow since then I’ve pretty much adopted or championed subversion use at any place I worked at because for some strange reason they all seemed to still be using Source Safe even with it’s issues with network access, VPN access, scalability, database corruption and uselessly slow history retrieval (I know I lied when I said I’d save the rant for later).

I continued to be impressed with the availability of tools to use with subversion from client side (tortoisesvn, ankhsvn) to server side (viewvc, mantisbt, redmine, reviewboard) which combined together help make an end-to-end high performance software development environment and process (I’ll definitely save those discussions for more posts to come).

Anyhow, now that Microsoft has released Team Foundation Server (TFS) it’s worth considering that most teams will be moving from VSS to TFS. And all indications are that a correctly configured TFS system is everything that VSS wasn’t.

So to get to the originally intended point of this post, svnbridge enables you to run a local svn server (in your taskbar) that actually proxies all it’s calls to a TFS system. This enables your developers to continue working locally with an svn working folder and therefore be able to use all the other svn integrated tools you may have included in your development process, while having your source code repository actually sit in TFS.

Now it’s relatively fresh software, in that it’s only just been released but I’ve actually used svnbridge and was impressed with how it does a direct mapping for most svn SCM operations to TFS operations including the obvious commit messages, branches and revision sets.