Monthly Archives: September 2008

Presentation Slides from 360Flex San Jose 2008

At 360Flex San Jose 2008, I gave a session titled Polishing Components for the Unwashed Masses. In my talk, I covered all the important details around releasing a custom component to the community. Having built a few open source components on my own, and being a former member of the development team behind Yahoo! Astra, I’ve spent a lot of time focusing on how to create quality supplementary material to include along with the source code and the SWC. The four main topics were writing documentation, creating examples, making your components extensible, and encouraging a community.

Screenshot of the presentation slides

To some, my session seemed a little obvious. To others, it was a good checklist of what-to-dos before some code gets released. Personally, I’ve seen way too many half-finished, barely documented, almost unusable components that could use a little extra love (even before going up in a one-time blog post). It takes time to do a decent release, and yes, sometimes creating all this “extra” stuff is a little boring. However, basic polish can make the difference between a forgettable component that no one uses and something everyone in the community enjoys. To convince a random developer to use your custom component, you need to guide them and show them how easy they can get started, and that’s the message I tried to emphasize in my session.

Thanks to everyone who gave me feedback! I may do a version of this session again sometime, and I got some helpful tips for areas that could use a bit more detail or some supporting visuals.

Download Slides (PDF file)

Open Source Flex Component: HeatMap

Note: I no longer work for Esria. Some links here may be broken because I no longer maintain the community site there. Being an open source project, though, I still have the original source code, and I’ve made a copy available for download from my own blog for those interested.

Over the last week, I’ve been working on a new Flex component, a heatmap! For those unfamiliar, a heatmap is a form of data visualization that uses color on a two-dimensional plane to compare values. Most recently, in the Flex community, heatmaps have been made famous by Universal Mind’s Spatial Key application. After seeing that go live, I knew people would be interested in an open source heatmap component for Flex, so I put one together and dropped it on Esria’s open source and community site (broken link removed).

Screenshot of HeatMap component

Overall, I found the process of building this component very straightforward. There are many similarities to my treemap component, but the heatmap is a bit simpler in many regards. One thing I particularly enjoyed about building the heatmap was that it required some pretty heavy optimization. Since it could potentially display massive data sets, manipulating the data provider and extracting the required numbers needs to be fast. I spent a lot of time diving into Flex Builder’s profiler. By the way, Jun Heider’s profiler session at 360Flex has some great info that helped me understand the profiler’s numbers better. I highly recommend checking it out.

In particular, I made a few good optimizations in some functions that could potentially run hundreds of thousands to even millions of times when preparing the data (basically, sorting a huge list of items). First, I made sure to access member variables directly. Usually, I’ll just use the public getter if it’s available, but it actually became a bottleneck when Array.sort() needed make such a huge number of function calls. Next, since a sort function potentially has to access the same value over and over again, I set up Dictionary-based caches to retrieve an item’s position and weight without having to recalculate these values every time. Personally, I’ve always been a little wary of the Dictionary type, but lookups proved to be very fast. Finally, though it didn’t necessarily have the same impact as the other optimizations, I drew the heatmap using a Bitmap rather than a Graphics object.

In addition to raw code execution speed, I included a couple other features to aid in performance. First, a sampleSize property lets you use every nth item in the data provider instead of every item. This won’t provide a complete picture of the data, obviously, but it will certain speed up the analysis by using a subset. Additionally, you can specify a weightField or a weightFunction. Normally, every item has a weight value of 1 used to determine the color of a region. Differing weight values can allow for more complex data, certainly, but it can also be used to combine multiple points together to form a smaller data set. For example, if you are using a region size of 30 pixels, you can combine all the items in the same region together since the heatmap won’t need more per-pixel position data. If your raw data has an item for every pixel in that 30×30 region, you’ll reduce the number of items in that region from 900 to just 1, but still have the same overall weight for that region. That can be a huge performance increase when you consider that this sort of reduction might be happening in every region on the heatmap. Moreover, by doing this on the backend, you’ll send fewer bytes to the client. Reduced bandwidth usage is always helpful.

The source code for the Flex HeatMap component is available under an MIT license. Be sure to check out the HeatMap API documentation (broken link removed) and look at the examples to get started.

Introducing RokTok, a Flex mashup featuring particle systems, last.fm and Twitter!

Now that I’m settling in as the new R&D guy at Esria, it’s time to start showing people some of the cool stuff I’m doing. Part of my job is to work with and evaluate new technology, libraries, and tools. The best way to do that, in my opinion, is to use them by building “real-world” applications. So, in order to begin playing around with the Mate framework and the Flint particle system library, I decided to build an app that I call RokTok. This fun Flex app combines the top musical artists on Last.fm with the community conversations on Twitter.

Screenshot of roktok app

I started peeking into the Mate framework just before 360Flex, and it looked pretty cool. I got the chance to see Laura Arguello’s Mate session at the conference, and afterwards I had no doubt that this framework was worth a deeper look.

Mate works a bit differently than the traditional Flex frameworks like Cairngorm, and that’s exactly what I like about it. Most of your work with Mate will be in an EventMap, an MXML tag-based event wiring system. Personally, I think this is a great way to utilize Flex’s native markup language and binding system, and to keep much of the framework code in one place. To me, it felt like I spent less time making the framework do its thing because I wasn’t creating half a dozen different classes to get one minor action to happen, yet it still felt organized. On the other hand, I could tell that larger applications with many events being handled in one place could lead to a large and unwieldly event map. Thankfully, there’s nothing stopping developers from breaking up event maps into multiple parts with only related events appearing in the same maps. Still, though, some developers may find that Mate works best for smaller applications that could still use a framework.

I love particle systems, and I’ve done several little experiments with them in the past. RokTok will be the first time I’ve been able to use them as part of an app, and making them visualize data seemed like a great way to do it. Many folks first head to Flare for data visualization in Flash Player, but I recently discovered the Flint particle system library for AS3. It’s obviously geared specifically toward particle systems, but in that area, this library definitely shines. I found the API extremely intuitive and extensible (good architecture, yay!), and it was super easy to integrate it into a Flex application.

Having designed my own particle systems in the past, and having trouble making them easily customizable, I was excited to see the approach Flint took for extensibility. Using Initializers and Actions to define behavior, Flint makes altering the way particles interact possible through small pieces that are easy to write and reuse. Having a decent collection of Actions that already come with the library and cover many of the most obvious behaviors certainly helps too. If you check out the source code for RokTok, you’ll see a few extensions I made in the com.flextoolbox.flint.* package.

I had way too much fun building RokTok as one of my first Esria R&D projects. If you’re interested in how it was built, check out the source code. It is released under an MIT-style open source license. Stay tuned because I’ve got a lot more cool stuff planned for my R&D and community efforts at Esria.