w00t! 2009 World Champion Flex Bug Quasher!

So I "won" the Flex Bug Quash in Seattle last weekend.

Shouldn't Adobe fix their own bugs? Why work for free?

I don't. Adobe doesn't. I get paid to deliver engaging user experiences for our clients, and most of my development work is Flex based. I have benefitted from the great community of Flex developers and it's time to pay it forward a bit.

I use a fair bit of open source software in my work, and I think contributing to the source code base is a good thing. Plus, I also used the opportunity to fix a couple of bugs that had been causing me pain in past projects. So it was self-serving open source work?

Road Trip!

I help organize the monthly Vancouver Flash Platform Meetup with Ross Ladell. During a recent lunch, nay, drink we realized that the Bug Quash event was being hosted in Seattle, rather than in the Bay area like I had assumed. So we declared it road trip worthy, and I rented a van for the day. Well, EffectiveUI rented the van, aren't corporate cards wonderful?

A bunch of us Vancouver geeks drove down to the Adobe Seattle office to represent Canada. It was a pretty quick drive (border hassles not included) and a fun way (what a geek!) to spend a Saturday. Ross met us down there and the folks from The Active Network were also there. So about 10 of the 30-ish bodies in Seattle were from Vancouver. Nice.

I win!!! Umm ... define "win"

All of this hinges on a very loose & liberal definition of what "win" means. I submitted the most patches that day, 5 in total. So given that metric, I won.

A former boss told me to remember that "fair" and "simple" are at opposite ends of the spectrum. Simple systems usually aren't fair, and fair systems usually are complex.

So counting the number of patches submitted was the easiest thing for the Bug Quash organizers to do, they were already doing it so that we could all watch the big numbers go up as patches were submitted throughout the day.

But submitting a bunch of patches doesn't mean that I'm did a lot of work. I don't think I was the most productive quasher there. I'd much rather see a few really hard problems fixed in the SDK than have some submit a bunch of executable semi-colons.

So what did I fix?

But I really couldn't describe my contributions as huge or high visibility. I just stayed focused in one area of the SDK (DateFormatter and some related classes) and knocked out some low hanging fruit.

1) DateFormatter "HH" shows 24 not 00

SDK-16076 - This didn't even require a code change. It wasn't a bug. The "HH" pattern shows hours in 1-24, the "JJ" pattern shows hours in 0-23.

All the comments said "Not a bug. close it". So I submitted an empty patch with a comment of "then CLOSE it already!". My patch was was rejected as a bit of an abuse of patch submission system, but the bug was closed anyway. I wasn't trying to be a jerk, but there wasn't any other clear way to mark/flag the bug for review. I'm not fond of bug lists that contain a lot of noise.

Total bugs quashed: 1
Total lines of code changed: 0

2) Make DateFormatter.parseDateString() a static public method

SDK-16902 - Yup. All this involved was changing "protected" to "public". +2 for me!

Total bugs quashed: 2
Total lines of code changed: 1

3) Fixed CalendarLayoutChangeEvent ctor

SDK-18567 - I hit this bug a couple of weeks ago, while writing a custom calendar control. The constructor for the CalendarLayoutChangeEvent was ignoring some of its parameters (like the new date, ouch!) so the net effect was that you had to set the date property manually, after the event was constructed. This class was only used once inside the SDK and the flow of control through that method meant that the date property was always being set after the event was created. So the SDK was (inadvertently, I think) working around this bug.

In addition to this two line fix, I also reviewed the SDK code for all the other classes in mx.events.*, just to be sure that this pattern wasn't repeated elsewhere. Nope. That was the only gotcha I could find. Which makes sense, since the other event classes are heavily used within the framework and bugs like that would have been caught early on.

Total bugs quashed: 3
Total lines of code changed: 3

4) Fixed parsing of GMT+x date string

SDK-13650 - This one took a bit more digging, and a whole lot more thinking. The patch I submitted on BugQuash day was rightfully rejected the first time. It actually wasn't until I wrote this post that I noticed that my original patch was rejected.

The original test case was using the AdvancedDataGrid class, which is part of the closed-source data visualization library. That meant I couldn't test the fix with the 3.x branch, since there was no 3.x datavisualization.swc to link in.

So I punted and did a HailMary commit. Which broke. Ugh.

Thankfully, Alex posted a much simpler test case, one that didn't require the closed-source SWC, so I quickly fixed my fix (I had neglected to escape the plus-sign in a regular expression) and submitted a new patch.

Total bugs quashed: 4
Total lines of code changed: 4 (see the method to my madness yet?)

5) Programatic HTML markup of Labels gets lost when truncateToFit() triggers

SDK-14982 - This is a bug I hit and reported about a year ago. When I reported the bug, I also included a fix. If you've set any markup via the htmlText property and the label needs to be truncated, all the formatting gets lost. The fix still isn't 100% but it is better than before and it is not any slower in the success case.

Total bugs quashed: 5
Total lines of code changed: 19

Did I deserve to win? Don't get me wrong. I like trophies!

Oh, I'm keeping the title belt. I'm claiming the (self-assigned) title of "2009 World Champion Flex Bug Quasher", at least until someone else comes along to push me off the top of the hill, attention-whore that I am.

Thanks to all the little people!

Thanks to Adobe for putting on the event.
Thanks to all the fun folks we got to hang out with at the Seattle offices.
Thanks to the Vancouver devs for kicking ass and claiming "first blood" (way to go Myo!).
Thanks to Karl for helping me setup my dev environment so I could finally build the SDK properly.
Thanks to the US Border Patrol officers who joined in our let's-bash-MSoft-fest at the border (nice to get the lads with the sense of humor for a change).