20 Jan 2008
From the Google Blog:
The contest said to “Innovate or Die” – and Team Aquaduct lives! In fact, the San Bruno, California team – consisting of John Lai, Adam Mack, Brian Mason, Eleanor Morgan, Paul Silberschatz – is living in grand (prize) style today after winning the first Innovate or Die Pedal-Powered Machine contest.
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica">
The contest encouraged people to evaluate environmental issues and develop ingenious solutions surrounding climate change. Many original and inspiring ideas emerged; make sure to visit the YouTube <a href="http://www.youtube.com/groups_videos?name=innovateordie">Innovate or Die</a> page to view all of the entries.
</p>
20 Jan 2008
A friend just pointed out a post over on Wired Science that talks a bit more about Google’s (previously) announced plans to begin providing infrastructure to enable scientists to more easily share and collaborate on large volumes of data.
It’ll be interesting to see where this goes. Giving scientists access to large volumes of data is an important first step, providing a means to build pipelines and frameworks on top of it is another.
If there’s anyone that could pull something like this off on a global scale it’s Google.
20 Jan 2008
There was an interesting post (by David Brady) included in the most recent dzone.com email that discussed the notion of Dishonest Programming.
The last sentence does a decent job of summarizing the author’s thoughts:
Any time you feel yourself being clever, ask yourself a key question: are you being deceptively simple, or simply deceptive?
In my mind it boils down to a matter of transparency. As a developer we should be striving towards writing transparent code. It’s easier to test, easier to maintain, and most importantly we’ll be setting a good example for others to follow.
-
Ensure that implementation artifacts (interfaces, classes, methods and variables) are named for what they actually do. Simple enough.
-
Ensure side-effects are known and documented. Pay attention to state and how it’s being maintained and manipulated. Prefer a stateless business tier and avoid undocumented data caches. The latter are trivially introduced and a pain to eliminate.
-
Immutability is good. Final classes, final methods and final variables. Pay attention to the mutability of return types as well.
Keep It Simple … and save the complexity for the kitchen.
As a developer, it’s amazing the difference in motivation you have when you’re working in a coherent and well-structure code base. It’s a difficult stage to get to (and maintain) but it must always remain a goal.
Adhering to a few simple rules will not only make you a better developer but will also improve the overall efficiency of your team.