With the new release of FireFox 3.5, the plugin authors have been working to get their code to be compatible with the new release, and this morning I noticed that Firebug had an update. I use this at work to look into the failing JavaScript code I (sometimes) write and be able to see what's really happening. Excellent tool.
For the last day of the Staycation, we had planned to go to the Indiana Dunes, but when we got up today the weather looked like it wasn't going to cooperate. If it's 82, then the water will be colder, and no one is going to have fun in freezing cold Lake Michigan water. So we decided to go to a local place and ride a few GoCarts and play a little Putt-Putt.
As it turned out, it got up to 92! So much for good weather predictions.
But we had a lot of fun on the GoCarts, and a good bit of fun on Putt-Putt. Nina doesn't like not doing something really well, and so when she wasn't hitting it in the cup in one or two strokes, she got a little nasty. Face it, she's 10, and used to being able to do what she wants to do. But life isn't always like that. Lesson learned.
We then went home, plated a few games, and called it a Staycation.
Liza and I learned a lot about our family and vacations, and that's good.
So long as we carry these lessons forward, it'll be OK.
Today we went to downtown Naperville for a nice brunch at Flat Top Grill and then walked around the downtown area for a while. We enjoy the downtown, and we stopped in to talk to our friends at the running store, and looked in on the newly moved 'Two Bostons' pet "stuff" store. Very fun.
We had tickets for RibFest, and were hoping to see Hewey Lewis and The News in concert, but the place was totally packed. We walked around for about 45 minutes trying to find a place to sit on the grass, and there simply was none. Liza and I were stunned because when we came to see KC and the Sunshine Band several years ago, there was an entirely different layout of seating in front of the main stage. They have literally cut it by 75%.
We were bummed, but we decided to try and make the best of it while we were there. It was a nice night, but not what we had hoped for.
Today we went downtown Chicago to do a little fun shopping at the Magnificent Mile and then take in a show - hoe metropolitan! I got to go into the Apple Store - very impressive. We went to the Hershey's Store and listened to a few street musicians. It was a lot of fun.
Had it not been for the rain.
Yeah, it was chilly and rainy, but that didn't damper our spirits too much. It was great seeing the sights for a little bit. Then it was time to go see the Blue Man Group. What a show! I really enjoyed it, and realized that we don't take the kids to enough theatre and we need to. I was lucky to see about a show a year when I was their age, and we need to see more than one every couple of years.
If you get a chance to see it, do see it. You'll be glad you did.
Today starts the wonderful three-day July 4th weekend that we're turning into a nice 4-day weekend that is going to be our "Staycation" for the Summer of 2009. The kids are busy, Liza is busy, and there isn't a lot of time to take a big week-long vacation, so we're doing things around the area and having a lot of fun.
Today was the Water Park and a great Kane Count Cougars ball game. It was a decent time at the water park - a little chilly for my tastes, but the kids liked it plenty. Liza didn't get a toe in the water all day.
The Cougars played the Peoria Chiefs - the AAA Farm Team for the Cubs. Turned out that A. Ramirez was playing that night and the KCC had a 9-year high attendance of over 14,000! It was a good game, the Chiefs won, but it was the three errors on the Cougars that really was the reason.
After the game, they had a great fireworks display there. It was directly overhead. We lay back in the grass and looked up at the fireworks. It was amazing. We felt like we could reach out and touch them. Fantastic night.
I've been working within the limitations of the AnnotatedTimeLine graph from the Google Visualization API set and have just been telling my users that the unfortunate "flash" to white of the graph while it's updating data is an unfortunate reality of the AnnotatedTimeLine, and that Google knows this is in issue and they are working on it.
Then I read an interesting post to the mailing list about how Google Finance didn't have this issue, and it got me thinking... How could they get around the flash? And in the show this morning, it hit me: Double-Buffering.
Simply have two graphs - one aligned in the z-axis behind the other. In fact, make them have the same coordinates, but just vary the zIndex value to "flip" them one in front of the other. Then, always draw to the rear (invisible) graph and when it's done, flip it to the front by setting sIndex to 49 on it, and setting zIndex to 0 on the one that was in front.
A simple use of an array of two graphs accomplishes this quite easily. I add in two variables - the index values for "foreground" and "background", and then you always draw to chart[bg] and so on. It's very clean and slick. The change of the z-axis values is done in the blink of an eye, it's very hard to see. Compared to the 3 to 6 seconds that the redraw used to take, it's nothing short of amazing.
In a very simplistic form:
var chart = []; var fg = 0; var bg = 1;
and then in my initialization code, called from the Goolge setOnLoadCallback() method, I have:
chart[0] = new google.visualization.AnnotatedTimeLine(chartDiv[0]); chart[1] = new google.visualization.AnnotatedTimeLine(chartDiv[1]); // tie us into the events for these guys google.visualization.events.addListener(chart[0], 'ready', graphReady); google.visualization.events.addListener(chart[1], 'ready', graphReady);
and then when I need to draw to the correct graph, I simply call:
chart[bg].draw(graphData, chartParams);
When the graph is done drawing, I'll get a call to:
function graphReady() { //swap the graphs quickly chartDiv[fg].style.zIndex = '0'; chartDiv[bg].style.zIndex = '49'; // now swap what we mean by back and front if (fg == 0) { fg = 1; bg = 0; } else { fg = 0; bg = 1; } }
There's a lot of the details I've left out because they don't really matter. The point is that you have to place them on top of each other, and then do this double-buffering. It's pretty nice.
Today I got a call from the original developer of this project I've somewhat taken over. He still has components of this project that are relatively new, and I haven't even been introduced to. Needless to say, there's no documentation whatsoever - other than what I've put into the codebase as I've been working on it.
So today when he called and said that one of his reports was missing a lot of data, I knew it was not going to be fun. He was really busy with this other project that his desk was depending on, and it was going to be up to me to figure out what had happened and how to get it back to "right".
As I've said, this guy didn't document a thing. There's a few high-level 10,000 ft. documents about how things are supposed to work. Problem is, this project was built with Spring and while it's certainly got benefits, I have to say making a reasonable, understandable, documented system isn't one of them. Confused? Sure. Exotic XML config files? Roger.
I don't mean to harp on this, but I'm going to because it's just that important. If you can describe the system at a high level as simple and flexible, then the implementation ought to be simple and flexible. It seems that Java has created this entire cadre of developers that over-design even the simplest of things just because they can. It's one of the most frustrating things I've run into in years.
Every language has it's detractors, and my favorites are no exception. I'm not one to throw stones, living in a glass house, but this really does seem to be something of a pandemic. Systems built with tools that almost restrict the developer from making useful, well-documented, code and easily understood code.
This is the project that has the most incomplete, yet copious, set of unit tests that I've ever seen. The unit tests passed completely, but at the same time, they didn't point out why I might have absolutely no data in the report. Does that sound like a good set of unit tests? Yet, I spent the better part of two days updating these same unit tests when I added a feature that took me about an hour. What's right with that?
If you're going to have unit tests, and more than that, have integration "unit" tests, then don't you think it should cover the case where a great deal of the result is empty? If it's a coding mistake, it should be caught in the tests. If it's a data issue that would blow out that much data (like a null pointer), then again, it should be flagged as at least a warning.
No tests failed or even logged problems.
I looked at the SVN change logs for all the files. Nothing there would make all the data disappear. I looked at the data in the database - maybe a lead there, but no, it was a false alarm. I looked at the data moving around the system at a level that wasn't easy to locate as there wasn't any documentation (as I've said), but in the end I was able to see the data coming out of the test system and the production system. Interestingly, the data at this level wasn't blank. It appeared that the Flex client was interpreting the data as something it didn't want to display.
Now we were getting somewhere.
When I looked at the data more closely I noticed that the numbers were remarkably similar. Interesting. Then I noticed that one part of the data was the wrong symbol. Very interesting, now. So I asked the original developer on this point, and he said that the symbol I had was wrong. OK, let's go there.
I had put the configuration of the system into a database so that it's far easier to maintain and basically is driven off the data that's maintained by the individual desks. When I put in these normalizing contracts I put in what I believed to be the right contracts. Turns out, for this report, for this group of instruments, it was wrong.
A one field change in the database and a restart of the Tomcat instance and Bingo! data was there in the report.
At the end of the experience I was sad to realize that I hadn't really learned a lot from this other than what I already knew: poor documentation, poor tests, poor checking on the client, the list goes on and on. While I know it's like whipping a dead horse, as long as I'm forced to work with this system it'll continue to be a source of anguish to me. It's got a lot of nice things in it, but the design and documentation aren't among them.
The code is consistent for the most part, and the goals and attempts are admirable, but in the end it's another victim of that pandemic of over-design and under-documentation. Make it simple... make it clean... work on the documentation... make it something that when another developer looks at it, it makes them code better. Set the Gold Standard for code. Be better than you have to be.
I learned those lessons years ago, and I only home some of them rub off.
Wonderful is the Twitter update!
Today I got a tweet from the OmniGuys saying that OmniGraphSketcher has gone Final 1.0. Great news, with a raft of changes in this cut the application really is ready to go. I'm glad I got in on this as I do love visualizations and graphs, in particular.
Had to get it.
This morning I saw that the Mozilla crew finally released Firefox 3.5! This is great news as I have been waiting on this for a long time for work. I'm hoping to see the performance of Firefox 3.5 on Windows to be up to snuff and capable of handling my web pages without crashing. The initial results seem to indicate that it's possible that this version of Firefox is far better at memory usage than the previous versions - and even better than Google Chrome! That would be great.
Even if that's not the case, it's nice to see Firefox making a big move in the JavaScript area. Very much appreciated.
Apple has released a big update to iPhoto '09 (8.0.4) that is supposed to fix a serious crashing bug that effected some users. I didn't experience it, but then again, I just got my iPhone to start uploading those pictures! Had to get it as I'm planning on doing a lot more picture taking.