Thursday, June 30, 2011
Wednesday, June 29, 2011
Tuesday, June 21, 2011
Saturday, June 11, 2011
Friday, June 10, 2011
from ACM Queue by Michi Henning (2007-06-07).
After more than 25 years as a software engineer, I still find myself underestimating the time it will take to complete a particular programming task. Sometimes, the resulting schedule slip is caused by my own shortcomings: as I dig into a problem, I simply discover that it is a lot harder than I initially thought, so the problem takes longer to solve—such is life as a programmer. Just as often I know exactly what I want to achieve and how to achieve it, but it still takes far longer than anticipated. When that happens, it is usually because I am struggling with an API that seems to do its level best to throw rocks in my path and make my life difficult. What I find telling is that, after 25 years of progress in software engineering, this still happens. Worse, recent APIs implemented in modern programming languages make the same mistakes as their two-decade-old counterparts written in C. There seems to be something elusive about API design that, despite many years of progress, we have yet to master.
(PhysOrg.com) -- The VLT Survey Telescope (VST), the latest addition to ESO’s Paranal Observatory, has made its first release of impressive images of the southern sky. The VST is a state-of-the-art 2.6-meter telescope, with the huge 268-megapixel camera OmegaCAM at its heart, which is designed to map the sky both quickly and with very fine image quality. It is a visible-light telescope that perfectly complements ESO’s VISTA infrared survey telescope. New images of the Omega Nebula and the globular cluster Omega Centauri demonstrate the VST’s power.
Image credit: ESO/INAF-VST/OmegaCAM. Acknowledgement: OmegaCen/Astro-WISE/Kapteyn Institute
Thursday, June 02, 2011
What I Learned From 250 Whys by Dan Milstein at HubSpot. This is quite good and worth reading!
I've learned about how HubSpot's systems work, why they sometimes break, and what we can do to make them more resilient. Beyond that, I've learned a lot about complex systems and failure in general. Which, in case you're wondering, is a fascinating topic. I highly, highly recommend Richard Cook's essay “How Complex Systems Fail” in O'Reilly's Web Operations. Or Atul Gawande's Complications and Better. Or basically anything John Allspaw writes.
If you'd like to build resilient systems, here's some of what I've learned from the fifty-plus 5 Whys I’ve been a part of. (And by &rlquo;systems,” I mean systems of people + machines, and by “resilient,” I mean I'm stealing from Allspaw.)