by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
GCN : September 2013
WHILE DEVELOPING a Java configuration Web service for our technical cloud broker software, Axon Cloud Chan- nel, I needed some code to execute an external process from within my Java code, and remembered that I had already developed similar code for an article I wrote way back in December of 2000 (yes, 13 years ago) entitled, "When Runtime. exec() won t." The article proved to be popular, as the Java pitfall it uncovered had tripped up many programmers using the built-in Java class for the first time. Additionally, in that article I introduced and provided the source code for a class called "StreamGob- bler" that "gobbled," or continuously read, an input, output or error stream from the external process. Besides the catchy name, that simple Java class cleanly solved one problem when us- ing the Java Runtime.exec() method. Furthermore, the class was meant only to dem- onstrate the solution and left several advanced features for others to implement. When Googling for that code from the article, I was shocked to see 15,800 hits for it and delighted to discover that the code had proliferated, been extended, reused and refined in hundreds of projects. My humble baby "StreamGob- bler" had grown up and taken on a life of its own! Well-known open source repositories like Apache, GitHub and Google Code had StreamGobbler variants as part of their reusable librar- ies. Well-known question- and-answer sites like Stack Overflow, Yahoo Groups and the Java Ranch answered multiple questions on it. And finally, well-known institu- tions and companies such as Stanford University, Software AG and Hewlett Packard had included the code, or a derivative, in their projects. All of this begs the question -- why would this code prolifer- ate? And furthermore, what are the ramifications of that? This small case study on the proliferation of 13-year old source code is one proof point for "Why Software is Eating the World," as posited by Marc Andreessen, co- founder of Netscape. While his article was for laypersons in the business community, I would like to focus on the question from the developer s perspective and o er three reasons why software will continue to "eat the world:" • Good source code has longevity. Good source code on a robust, well-supported platform (or platforms) has a long shelf life --- decades or more. For example, the Java Platform was released by Sun Microsystems in 1995 and is still growing strong and evolving today. • The power of open-source software. Open source software, where the source code is available to the public for reuse, including modi- fication, has been a global boon for innovation and improving the overall state of technological progress. Or- ganizations like the Apache Software Foundation are heroes in my book. I have been an avid fan, supporter and contributor to open source for my entire career, and all source code from my technical books is available on my website. • Source code maturity should be the gold stan- dard. The key mark of good software is that it fulfills its function, over time, robustly and reliably. To achieve that end, good source code is mature source code. My measures for source code ma- turity are the following: It is being used in a produc- tion environment. It has aged in that environ- ment and therefore has been executed by end-users. It has been tested in terms of coverage and corner cases. It has been tested via auto- mated regression tests. The most mature code will have fulfilled all of the above and run flawlessly under those constraints for the longest time. How mature is your code? Fortunately, the next wave of cloud-based applications will leverage and increase these positive trends of source code longevity, open- ness and maturity. And speaking of cloud computing, I am nearing the completion of my next book, which is on cloud comput- ing. If you are an IT manager or developer interested in formally reviewing the book, please contact me via email or from this website. • --- Michael C. Daconta (mdaconta@incadencecorp. com) is the Vice President of Advanced Technology at InCadence Strategic Solu- tions and the former Metada- ta Program Manager for the Homeland Security Depart- ment. He is currently work- ing on the second edition of his book, "Information as Product: How to Deliver the Right Information to the Right Person at the Right Time." GOOD CODE NEVER DIES, IT JUST STARTS EATING THE WORLD REALITY CHECK BY MICHAEL DACONTA Good source code on a robust, well-supported platform has a long shelf life --- decades or more. GCN SEPTEMBER 2013 • GCN.COM 15