Let me just say that software engineering is a heck of a lot easier than professional bike racing. I have a new, profound respect for people who spend the majority of their time training their bodies for the rigors of professional athletic competition.

As the Car Talk guys would say, I’m just back from the “Red Faced, Peloton Chase, Stress Case, First Place, Climbing Ace, Tour de Toona Bike Race.” And what a race it was. I’ve heard it’s the hardest cycling race in North America for women, and I believe it. For a brief time I rode the wheel of Kristin Armstrong, US and World Time Trial Champion (what was she doing in the back?!). My team of 8 girls was whittled down to 2 by the end, by the likes of Armstrong, plus the US Road Race Champion, the Canadian National Road Race Champion, some of the country’s best crit racers, and 102 other fantastic female cyclists.

During Wednesday’s 95 mile stage, which would be my last as I missed the time cut by 3 minutes, 30 seconds after 5 hours of racing, I realized that I was awfully glad to have a job where the worst endurance event was an all-nighter getting software ready for launch. Professional bike racing is pretty doggone hard.

I even did some usability testing, of the new Specialized computers. I lost the first one after hitting a rather rough section of road. I wasn’t the only one though; a girl from Aaron’s pro team lost hers as well. So, hopefully Specialized will improve the locking mechanism so they stay on better.

As I have experienced before in my real life, working with users, experiencing a different job is very enlightening and educational. And even though I only made it through 3 stages this year at ‘Toona, I can’t wait to try it again.

Here at PointClear, our talents our focused on developing software and solving problems in Healthcare and Life Sciences. We have spent a lot of time with one of our clients developing a Personal Health Record (PHR). This involves not only solving a great deal of very difficult technical problems, but also, learning about the patient and how they can best benefit from this burgeoning revolution in consumer empowerment (how’s that for buzzwords?). We are certainly interested in new initiatives by the big dogs, and it doesn’t get any bigger than Google Health. This article is a wonderful summary of the state of the art in PHRs:

http://e-caremanagement.com/connecting-the-dotsgoogle-health-promises-to-create-and-dominate-next-generation-phrs/

If you’re developing a sizable online app, you may have encountered a bug in which IE (version 6 or 7) will essentially “freeze”, taking up all available CPU cycles until you end the process. Finding the cause of this can be maddening, and I’d like to detail the processes that helped me find the cause(s).

If you scour google, you’ll likely pull up numerous pages dealing with memory leaks. Leaks are definitely something that should be eliminated first. The Microsoft sites lean toward closures being the primary issue…don’t be fooled. Closures hurt, but that’s likely not your primary issue. Have a look at Douglas Crockford’s site to get a better idea…the code snippet he offers works like a charm.

Here are some tools to help you track down memory leaks and browser processing:

• Drip
• Fiddler
• Process Explorer
• STRACE / HTTPReplay

If you find that a memory leak is not your issue, take a deeper look at your app and its use of the innerHTML property. After removing all of our memory leaks, we could still replicate the IE freezing issue by clicking rapidly during certain browser events (showing/hiding divs, transforming some xslt docs, etc). After hours spent combing over the main processes, we finally commented out a “clean-up” method that simply clears the innerHTML of a div…this fixed our IE freezing issue. Why did this work? I’m really not sure, and since IE doesn’t have anything close to Firebug, it’s tough to say (IE does, but read the comments…this thing is buggy).

While I understand that innerHTML isn’t standards compliant, it’s become a defacto standard since IE doesn’t support the “createDocumentFragment” method. There are several libraries that try to get around this shortcoming, but that just seems like bloat when a simple, cross-browser method already exists.

Good luck with your app’s creation. Hopefully these tools and tips will help to get you through any problems quickly and efficiently.