Programming Languages

Vol. 9 No. 10 – October 2011

Programming Languages

Articles

How Will Astronomy Archives Survive the Data Tsunami?

Astronomers are collecting more data than ever. What practices can keep them ahead of the flood?

How Will Astronomy Archives Survive the Data Tsunami?

Astronomers are collecting more data than ever. What practices can keep them ahead of the flood?


G. Bruce Berriman, NASA Exoplanet Science Institute, Infrared Processing and Analysis Center, California Institute of Technology
Steven L. Groom, Infrared Processing and Analysis Center, California Institute of Technology


Astronomy is already awash with data: currently 1 PB (petabyte) of public data is electronically accessible, and this volume is growing at 0.5 PB per year. The availability of this data has already transformed research in astronomy, and the STScI (Space Telescope Science Institute) now reports that more papers are published with archived data sets than with newly acquired data.17

This growth in data size and anticipated usage will accelerate in the coming few years as new projects such as the LSST (Large Synoptic Survey Telescope), ALMA (Atacama Large Millimeter Array), and SKA (Square Kilometer Array) move into operation. These new projects will use much larger arrays of telescopes and detectors or much higher data acquisition rates than are now used. Projections indicate that by 2020, more than 60 PB of archived data will be accessible to astronomers.9

by G. Bruce Berriman, Steven L. Groom

Postmortem Debugging in Dynamic Environments

Modern dynamic languages lack tools for understanding software failures.

Postmortem Debugging in Dynamic Environments

Modern dynamic languages lack tools for understanding software failures.


David Pacheco


Despite the best efforts of software engineers to produce high-quality software, inevitably some bugs escape even the most rigorous testing process and are first encountered by end users. When this happens, such failures must be understood quickly, the underlying bugs fixed, and deployments patched to avoid another user (or the same one) running into the same problem again. As far back as 1951, the dawn of modern computing, Stanley Gill6 wrote that "some attention has, therefore, been given to the problem of dealing with mistakes after the programme has been tried and found to fail." Gill went on to describe the first use of "the post-mortem technique" in software, whereby the running program was modified to record important system state as it ran so that the programmer could later understand what happened and why the software failed.

Since then, postmortem debugging technology has been developed and used in many different systems, including all major consumer and enterprise operating systems, as well as the native execution environments on those systems. These environments make up much of today's core infrastructure, from the operating systems that underlie every application to core services such as DNS (Domain Name System), and thus form the building blocks of nearly all larger systems. To achieve the high levels of reliability expected from such software, these systems are designed to restore service quickly after each failure while preserving enough information that the failure itself can later be completely understood.

by David Pacheco

Wanton Acts of Debuggery

Keep your debug messages clear, useful, and not annoying.

Wanton Acts of Debuggery

Keep your debug messages clear, useful, and not annoying.


Dear KV,

Why is it that people who add logging to their programs lack the creativity to differentiate their log messages? If they all say the same thing—for example, DEBUG—it's hard to tell what is going on, or even why the previous programmer added these statements in the first place.

by George Neville-Neil