In creating new content for the web – educational, corporate, entertainment – we have a bit of a pressure-cooker atmosphere. Teams are quickly assembled. Ideas are tried and tested and implemented in hours and days, and deadlines are often set with everything but technical feasibility in mind.
Of course, in web, the stakes are rarely as high as those of, say NASA. We can update, beta test, and the consequences are not typically life altering. There is always “CTRL-Z”
Nonetheless, we need good teams – exceptional teams, really – to get the job done.
Looking back over 50 years, one of the most amazing teams, goals, and deadlines was the Apollo program to land a man on the moon by 1969. 0.4% of the Gross Domestic Product of the United States at that time was diverted to NASA, and when the project had started it was science fiction – it would be like us today building nuclear starship in 15 years, just enough feasibility to not be pure science fiction.
But things did go wrong, because of the rush to meet the deadline, and because of the unique nature of risk: nothing goes wrong until things go wrong – the only symptom of high risk is catastrophe. Read the rest of this entry »
I wrote a jsfiddle sample as a demo for my brother’s control systems class at NAIT to show the differences between closed-loop feedback controllers – the tiny algorithms behind cruise-control autopilots, and autofocus in your camera.
I have to generalize it to a PID object and so on, but it is fun to play with the coefficients – and I learned a thing or two I’d forgotten about digital controller behaviour, like sampling error and sampling bandwidth. And as all Control Systems engineers are warned: Turn up your Gains slowly!
Ideas for feedback loop tuning games? The unicyclist? better cruise control, Autopilot lander? Fill the acid vat?
By sandboxing App Stores and development processes, the major players have taken on the problem of developing their app stores. Although HTML5 promised to be a universal platform, iOS, Windows 8, Android etc. make those apps second-class citizens to the native App Store versions, forcing developers to choose which platform to develop for as an initial target.
This becomes a problem for upcoming platforms that quickly need to build App libraries to legitimize their proprietary platforms, mainly because they want it both ways: they want to lock developers time into their platform, and they want those developers to do it when there is no critical mass in that platform. From a developer perspective, why would I write for, say Windows 8 first when I can spend the same effort on a known distribution base: iOS? Ideally I would like to write for all platforms with one codebase. Of course if the platform creator is trying to ramp up by funding key developers and projects that can work for a while, but it presumes the target audience’s planned use for the new platform.
A simple solution would have been to allow web-based technologies to acts as a virtual machine that could be further compiled to native code for performance boost, much like Adobe is attempting to do with AIR. This would allow a write-once platform with closer to native performance, unlike, say PhoneGap which is forced to work in a browser window and so is not really a native App. Performance on, say, smartphones and tablets, is quickly becoming good enough that a small performance hit would be acceptable.
Being proprietary does not in itself attract developers – being a good return on investment does. It may be that the performance gap between native code and HTML5-based apps is not closing as fast as it could because platform creators do not think this way.
Kids are fearless and brilliant and will learn to drive an interface faster than any adult. This great article outlines 4 ‘pleas’ from a father to touch app developers that are not so much for his kid (2 years old) but for his own understanding, and I have not seen it spelled out so clearly and concisely before. Well worth the read.
….From Lee Brimelow (of course!) Check it out here