I recently worked for a company that had technical debt as a strategy to cover the make it to the first release, scheduled at 6 months into development.

What unfolded was what any article/presentation on technical debt warn you about. Lack of predictability. The main issue with technical debt is that it creates invisible problems. They are not factored in the project plan but will slow down work. A task that you estimated to 2 hours as it is what it takes you in normal circumstances end up taking 2 days. Initially, you address it by working a few extra hours every day. However, unless you take the time to do proper refactoring, the overhead progressively grows. Soon, there is not enough hours in a day to make up for the time lost dealing with the debt.

Your best option. Accept that there is a problem and address it. Second best, leave before it has too much unwanted impact on your health or reputation as a professional programmer.

To quote the great book, Clean Code: "[...] it is unprofessional for programmers to bend to the will of managers who don't understand the risk of making messes".

Given the recent annoucements about Flex, I have started a second round of looking around for alternatives. I had a quick look at Haxe a few years ago. At the time, it exported mostly to flash and had less features than Flex. I didn't see how I could use it for interactive applications.

A live demo is available as a ScoreBoard widged.
The goal was to write the code in such a way that data can be passed to it as plugin settings or can be loaded asynchronously from a google spreadsheet. This is managed with a publish-subscribe pattern. This can be done using a combination of bind and trigger, which are included in the jQuery library.

The idea is to avoid tight coupling as much as possible. To accommodate for the fact that different services could be used in the future, best is to keep the code that fetches and parse data from the google spreadsheet completely independent from the interactive that renders the data. We get the interactive to listing to an event "dataChange".

Fetching data from the google spreadsheet is managed by a separate plugin, that we call here dataread.js. A problem is that you have many interactives on the page, each reading data from a different spreadsheet. If you were to dispatch the event at the page level, all interactives would receive a request to update their view using the new data. This is best avoided. The solution we use is to attach the events to a dom element that is specific to an interactive, here, "div#a-0".

I typically avoid to support any political cause through my blog. I live in Wellington and wasn't affected by the quake, luckily. Though not as strong as the September one, last week earthquake, with a 6.3 magnitude, was very shallow and very close from the city center, while following months of repeated aftershocks. The damages have been extensive as can be seen from these photos, moments after the quake and before and after photos

My husband bought a Kinect and released an application that let you run kinect from your USB port, without having to install any driver. Check out cocoakinect project.

Anyway, I noticed that a actionscript wrapper was provided in the openkinect/libfreenect libraries on github. With a helping hand from my husband, got the as3server running. Once it is running, rgb and heatmap pictures can be viewed by running mxmlc test_depth.as or test_rgb.as (provided in the libfreenect library). If you have Flex installed, simply run 'mxmlc test_depth.as' from the command line.

That has taken a fair bit of Googling to figure that one out. Because of security sandbox restrictions, when using the url of the ModuleLoader component, modules can only be loaded from the application directory (or any of its subdirectories).