| |
| The ExoBlog is maintained by John T. Stough... read the profile here: |
 |
| Mr. Stough is a member of (ISC)2 as a Certified Information Systems Security Professional: |
2_Member_Content/Member_Resources/CISSP_logo.jpg) |
|
[Hint: click the arrow beside a blog to see sub-categories]
|
Adobe's Fault: ColumnCharts in Flex for Live Data
Location: Blogs ExoBlog (by John)FLEXocubic (Flex & AS3) |
 |
| Posted by: exocubic |
6/19/2008 10:18 AM |
I'm always careful (OK, not always...) I'm generally careful not to blame the vendor right out of the gates when I have a problem. I guess this is mainly because I have been on both the vendor side and the consultant side of the fence enough to know that most tech support calls due to the "broken feature" are actually IO errors (IO = Idiot Operator). It is really tough to build a tool so intuitive that it just knows what to do, so configuration confusion can create the appearance of defects that are not really there.
This problem, however, I REALLY want to blame on Adobe - It is most likely not their fault, mind you, because we are using the Flex column chart in a way that it probably was not intended, but it just feels better to blame someone! Unfortunately, I've met some of the folks at Adobe, so now I see their faces and have to own up to it - I just feel bad accusing someone I can see crying in his beer later (yeah, right). More realistically, I just don't want to feel like the Idiot Operator when they say it is just a configuration problem! How do we balance getting support and trying to stay self-sufficient? (feel free to comment)
So how do you get resolution on deep issues that require help from the
vendor? In this problem, particularly, there is no silver bullet in
our initial research, we cannot find anyone else with the issue (at
least, not yet) and I can't say for sure that it is a problem with the
tool. I'll get into the techincal details in a minute. The point is, really, about how to isolate the problem.
Let me shift from that point a bit to describe the problem and why it matters. This blog post is not really about the specific issue, we have it trapped in a corner at the moment and are moving on, but it is important to realize that had we not followed a logical process to isolate it, we would still be stuck and facing a major feature killing bug prior to a pilot test - so getting to the other side of things like this can wreck your project! I'd like to post how we solved the problem in hopes that it will help others solve similar complex issues.
The situation: I am working for a client on a custom development project where we are using Flex to build a near-real-time data display with graphs and other features. The application has line charts, area charts, bar charts, and pie charts (among other things) wired into an asyncronous data stream that updates with live data. You can also specifiy a historical range and get to averaged data and other goodies. The problem started to occur with our zooming features on the charts (which all have to stay in sync when you zoom) that the bar chart would occasionally go off into la-la land and become a big rectangle. Since all the other charts work fine and the code is so similar between them, the solution is easy - IT'S ADOBE'S FAULT!!! Not at first, and we don't give in so easy, so after many hours of debugging we realized that the pecuiliar nature of our data sync was partly to blame (it has to do with time series data gaps, I won't bore you). The point is that we could, through a series of changes, start to perdict the rectangle, even though we still did not understand it's cause. We could also eliminate it in many cases, isolating it to a very small test case on the fringe of realistic use. The technical details are a little farther down on the post, for anyone that cares. The important point here for the casual reader, however, is that we isolated the problem through a very systematic approach to problem solving rather than assuming at first it was broken because of the tool.
Here are a few notes I have found helpful in the process of debugging a complex issue:
- If you cannot reliably and consitently recreate the problem, then most likely neither can the engineer assigned to fix it - so if you want it solved, first figure out exactly how to recreate it. Many times this step alone results in an obvious fix.
- If you can isolate the problem to a repeatable fashion, try to move it to a "sandbox" where you can focus on just that problem. There have been several times in the past were we see a problem in the integrated solution, but cannot recreate it in the sandbox (this was one of those problems) but if you can isolate it to the sandbox, you will make the diagnosis free from your application - thus free from blaming the complexity of other things getting in the way. It also is easier then to email it to the company and say "SEE!" without giving up all of your code!
- Try to talk through the scenario - the "order of events" with someone else to get a clear picture of what is happening in the code... most of the time it is only doing what it is told, but that also means it may be making certain assumptions as it goes along. A good example of that is initializing a date can make it equal to the current time, so if you have logic checking for older dates, it fails but is not always clear why. Talking things out in detail (typically a peer review of the code, or whatever) can often help.
- Start cutting out the fat. You want to get the problem down to the smallest possible cause. When we are debugging issues in HTML stylesheets, we start eliminating code until the problem goes away, then back up one step - your problem is there on that shifting point. The same is true with software, perhaps not as easy to find, but you want to find the switch that makes it go pop by cutting as much else out as possible.
This is becoming a long post, so I'll stop here and get into the technical details later. Suffice it to say that we have discovered that with large sets of data in variable time intervals, that we can recreate a failure of the bar chart in an odd way - it shows one big block with a few tooltips, but not the entire series. However, by isolating the problem as we described, above, even though we are not there yet, we have chased it down to a scenario that is only repeatable now when we have less than one second deltas in the intervals with real-time data. We can now move forward to other things and just blame Adobe (in jest, of course). |
|
| Permalink |
Trackback |
Comments (1)
|
Re: Adobe's Fault: ColumnCharts in Flex for Live Data |
By exocubic on
7/3/2008 1:00 AM |
| P.S. we finally did resolve the problem, we think, after some additional trial & error; it seems that if you are plotting real-time data in very small intervals that you can get some flutter - but if you create an intentional overlap in the data (like 1:30, 1:35, 1:30, 1:35, 1:40) where point date-order is messed up, you can recreate our "block". So we added some special checking for this (processing each data point) and have removed most cases of the block. |
|
 |
|
From time to time, we all have random thoughts... sometimes they are profound, sometimes they are not, but if they are worth keeping then they are worth recording. This blog is used to record the thoughts on what it means the think creatively, solve problems, and improve processes. You have to be a registered user of the site in order to comment; help us maintain the integrity of the site and comments posted on it. We would love to hear your feedback, so please take a moment to register.
|
|
|