EDITOR'S EYE

The World of Software Development.

January 2007

What brings mobile phones to mind is the movie I went to see last night. Granted, "The Last King of Scotland" had nothing to do with cell phones, and in fact, during the period of history the movie addresses -- Uganda in the 1970s -- cell phones weren't even a twinkle in Steve Jobs eyePhone. No, what brought mobile phones to mind at the movie were the phones moviegoers forgot to put in vibrate mode or just turn off.

But back to today's mobile phone news....

Sony Ericsson has announced its plans to manufacture mobile phones in India, through manufacturing agreements with outsourcers Flextronics and Foxconn. (The announcement was made in Chennai which, you recall, is where I was a week or so ago.) What's mind-boggling about this is that annual production capacity in India expected to reach 10 million by 2009. That's a lot of cell phones.

Initially the focus will be to manufacture basic color phones and mid-level music-enabled phones, for local distribution. In addition to competitive pricing, these phones will offer customized features for the Indian market, such as local content and customized keypads. Today, Sony Ericsson is among the top 3 GSM handset players in the country.With a GSM subscriber base of 105.4 million, India is one of the fastest growing mobile markets in the world, and forms a priority growth market for Sony Ericsson worldwide.

Seagate and cell phones? Sure, why not. What with all the video, audio, and even an occasional phone call, applications and data can eat up a lot of memory on mobile phones. That's why Seagate is starting to talk about "Crickett," its "Digital Audio Video Experience" that provides 10-40GB of wireless storage for cell phones. Crickett is a portable wireless storage solution. Crickett works seamlessly with Bluetooth-, WiFi- and USB-equipped handsets to provide substantial capacity without impacting a phone’s design or cost. According to In-Stat Research, there will be more than 540 million Bluetooth-enabled handsets and 11 million WiFi phones in 2007. Crickett-based storage devices will be about the size of a credit card and operate at up to 30 feet from phones. Software has already been produced for J2ME, BREW, Windows Mobile, and Symbian, among others.

Okay, the iPod isn't a cell phone, but Apple has announced a breakthrough that deserves mentioning. In a nutshell, Apple delivering the iPod Shuffle in four new colors--blue, pink, green, and orange. "With the Shuffle, color is arguably more important because you're going to wear it, and when you're going to wear it, it becomes more of a fashion item," said Greg Joswiak, Apple's vice president of worldwide iPod product marketing. At least now we know why the Apple Lisa never made it in the marketplace -- it lacked fashion sense.

Posted by Jon Erickson at 10:09 AM  Permalink |

There's little pride in admitting what you don't know. But that's the way of the world, I suppose. So here are a few things I don't currently understand, and probably never will.

Quantum Biology. Okay, I do have a handle on biology, after a fashion, and have been reading up on quantum, as in quantum computing or quantum mechanics. But quantum biology flummoxed me. From what I've read, quantum biology is the study of biological processes in terms of quantum mechanics. Which seems to me that you're using a term in the definition of that same term--which you're not supposed to do. The part I find interesting about quantum biology is that it hinges on the power of high-performance computers to precisely model complex biological processes.

To investigate QB, researchers are using the supercomputing facilities at Rensselaer Polytechnic Institute's Scientific Computation Research Center(SCOREC) and the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. This kind of computing power will let researchers model complex biological systems with even greater accuracy: "The more atoms you include, the more accurate your system," says research team member Philip Shemella, a doctoral student in physics at Rensselaer. At least that makes sense to me.

DNA Nanotags. Just as I was getting a handle on RFID tags, the folks at Carnegie Mellon University have come up with "DNA nanotags." Tags I get. Nanotechnology I get. But everything I know about DNA I learned by watching the O.J. Simpson trial. According to a news release, "scientists have married bright fluorescent dye molecules with DNA nanostructure templates to make nanosized fluorescent labels that hold considerable promise for studying fundamental chemical and biochemical reactions in single molecules or cells. [This] improves the sensitivity for fluorescence-based imaging and medical diagnostics." Okay.

Much of the work on DNA nanotags is being done by scientists at CMU's Molecular Biosensor and Imaging Center, a really interesting research site whose mission is to develop fluorescence detection technologies for biomedical research and NASA space exploration. Clearly, I have a better grasp of the center's work on fluorescence imaging for life detection in extreme environments that the Center is doing in collaboration with CMU Field Robotics Center and NASA Ames Research Center, than the biomedical stuff. But then that leads us to the field of "astrobiology" -- the study of life in the universe -- where robotic astrobiologists will search for life on other planets, and I'm lost again. Did I mention that everything I know about astrobiology I learned on Star Trek?

Airport Security Screening. I admit I know something about airport security screening, having spent half my adult life in airports, it seems. But what I don't understand is how some of the screening devices that identify hazardous and toxic materials work. Luckily, researchers at Sandia National Labs do understand this stuff.

Moreover, they're working on next-generation screening devices that work in the underutilized terahertz (THz) portion of the electromagnetic spectrum that lies between microwaves and infrared. The current project underway at Sandia is the Terahertz Microelectronics Transceiver Grand Challenge. "The technology being developed in the Grand Challenge can be used to scan for items such as concealed weapons or materials, explosives, and weapons of mass destruction," says Mike Wanke, principal investigator. "In addition, we believe it will find applications in advanced communication systems and high-resolution radars. However, the infrastructure needed to move the terahertz technology from the laboratory to the field is unavailable right now. We want to develop that infrastructure and invent the necessary technologies." Wanke added that over the past three years, "the terahertz situation has begun to change dramatically, primarily due to the revolutionary development of terahertz quantum cascade lasers." (There's that "quantum" stuff again.)

Wanke's team is currently developing the receiver, doing systems tests, and exploring packaging requirements. In addition to monitoring for concealed hazardous materials, Mike believes a terahertz system can be used to monitor the air for toxic materials. Here's a tip: If you want to contain hazardous vapors at airport security screening, don't ask me to take off my shoes.

Hopefully the boss won't be reading this. She thinks I really do understand all this stuff -- because I told her I did. I don't know what I was thinking.

Posted by Jon Erickson at 10:29 AM  Permalink |

As anyone who has sat in line at bridge or turnpike tollbooths knows, one of the truely great conveniences that tech in general, and wireless tech in particular, has brought us is fast-tags, k-tags, fast-lanes, or whatever they're called, wherever you are.

You know. Those RFID-based electronic toll collection devices that operate via an RFID transponder (tag) attached to the inside of your windshield. As you pass through a designated lane, a green "Thank You" light flashes, verifying that your transaction is approved and charged to your credit card.

So there I was, on the way home from YAT (that's "Yet Another Trip") late at night, when I came to the tollbooth that let me on the turnpike. But as I approached the gate, the light was stuck on red and the gate didn't rise. Looking at place where I expected the transponder to be, all I saw was glue where it had been attached. It had came unglued during my week away -- and I was coming unglued by the line of honking cars behind me. Then for whatever reasons, the light went green, the gate went up, and I scurried through like a Sea Biscuit running a race.

Of course, I did pull over to find the missing transponder and reattach it to the windshield, preparing my story for a state trooper, had I been pulled over, and if not, to the person in the tollbooth when I got off the turnpike. But when that time came, I drove right on through the exit, green light and gate cooperating to the max.

Curious as to what was going on -- not to mention wondering what my bill might look like -- I called the turnpike authority the next day to inquire and explain. As it turns out, the toll gates will always go up as you enter the turnpike, no matter if you have a transponder or not. This is simply a means of saving gates for those people inclined to drive through them. As for exiting, the system recorded my account number as I went through, not knowing where I got on the turnpike. In all likelihood, my monthly bill will have the maximum amount for the entire turnpike system charged, even though I got off at the first exit.

All in all, a reasonable system design it seems. The only problem area has nothing to do with the wireless technology, but everything to do with the adhesive material on the Velcro strips that holds the tag to the windshield.

Since we're talking RFID, it seems appropriate to mention RuBee, also known as IEEE 1902.1 -- an emerging standard that may be an alternative to RFID for some applications. RuBee networks operate at long-wavelengths and accommodate low-cost radio tags at ranges between 10 to 50 feet. The standard targets harsh environments, such as, I assume, the inside of my car. The RuBee radio tags, which will be either active or passive, would have battery lives of 10 years or more using lithium batteries. One of the advantages seen for the long-wavelength technology is that the radio tags can be low in cost, near credit-card thin (1.5 mm), and fully programmable using 4-bit processors.

In general, RuBee is seen as filling the gap between the non-networked, non-programmable RFID tags and high-bandwidth, radiating systems governed by local (802.11) and personal area networks (802.15). They are seen as having applications healthcare, agriculture, government and retail.

Okay, it starting to look like we have that wireless stuff down, time to go back and work on the glue.

Posted by Jon Erickson at 04:07 PM  Permalink |

Upon walking back into the office on my first day after returning from India, the response of the Dr. Dobb's staff was "You've been gone? Ah, sorry, didn't notice." And that from the boss.

But a great trip it was, if you don't count the spiced buttermilk served on Kingfisher Airlines on the flight from Hyderabad to Chennai. I was able to meet face-to-face some readers I'd traded email with for years, not to mention making lots of new friends. All in all, the trip was wonderful, something that my traveling companions Scott Meyers, Hugh Thompson, Ken Pugh, and Andrew Stellman, will agree with.

But the trip wasn't just entertaining, but it was educational too -- and not just for the conference attendees, but me too. Recall that I did share a few things I learned in and about India. Here are a few more odds and ends:

• On the plane coming home, somewhere around Chicago, the guy in the seat next to mine says:

  Him: Where you flying from?

  Me: India.

  Him: Me too.

  Me: Hmmph.

  Him: IT or pharmaceuticals?

  Me: IT.

  Him Pharmaceuticals.

• WiFi in the hotels was really good -- better than most hotels in the U.S. that I've stayed at. And cheaper -- I think. Let's see, 30 rupees is how much in dollars?
• The software developers we met in all three cities -- and we met hundreds of them -- were really, really sharp. Both Scott Meyers and Hugh Thompson said that the post-presentation questions they were peppered with were sophisticed and challenging.
• As high-tech and modern as some areas are -- the Microsoft and IBM (and others) buildings in Bangalore were gleaming glass towers -- the contrast was at times amazing. For instance, a few blocks from our hotel in Bangalore, I ran across cubby-hole businesses with treadle sewing machines that were smokin' they were sewing so fast.
• Yahoo India is hiring. How do I know? Because the company bought the back of the Jet Airways boarding passes on our flight from Chennai to Bangalore.
• Here's a tip: If you want to assert an aura of authority at an authentic ethnic Indian resturant like Tandoor, don't order a Cinderella. Fruit juice and soda sounded fine when I saw it on the menu. But it was the little paper umbrella stuck in the glass that had everyone pointing their fingers at me. And I wonder why I'll never be a boss.
• And I never did rent a scooter. Come on, do you really think someone who orders a Cinderella would make it on the streets of Bangalore?

Okay, it's time to put a wrap on it and get ready for Dr. Dobb's Best Practices Russia. (Hmm, I wonder how you say "Cinderella" in Russian?)

Posted by Jon Erickson at 12:07 AM  Permalink |

While there are any number of reasons why Hyderabad is on the verge of becoming a major software development center in India, the biggest reason might be traced back to the Hyderabad Software Exporters Association (HYSEA).

With more than 300 members who represent the software industry in Andhra Pradesh, HYSEA's vision and goal is to position Andhra Pradesh as the leading intellectual capital of the world, by nurturing entrepreneurship, research, and innovation, to achieve global excellence in IT products and services. Granted, those are big shoes to fill, but there's nothing wrong with aiming for the stars.

For the most part, HYSEA's efforts focus on educational and informational objectives. For instance, this week HYSEA will host a seminar on "TDS Compliance: Policy Framework and Process - Good Practices, at the Softpro Heights, Software Units layout, Madhapur, Hyderabad. Conducting the seminar will be M A Uday Kumar, Addl Commissioner, Income Tax along with a team of senior officers. To be truthful, I have no idea of what TDS Compliance is all about, but I simply want to give you an idea of the types of educational program HYSEA has sponsored. In the same vein, another program this week focused on "U.S.-India Collaboration for Quality Improvement in Technical Education" and let by Brig. Hari Kumar of the School of Management at JNT University, Kukatpally. In the spirit of disclosure, I need to mention that HYSEA was a Supporting Partner in Dr. Dobb's SD Best Practices India 2007 conferences.

If I were to compare HYSEA to an organization in my experience, I'd compare it to the Software Development Forum in Silicon Valley. Of course, SD Forum has been around a lot longer -- more than 20 years.

I had a chance to shake hands and listen to a talk by HYSEA's current president, Anil Jampala. Dr. Jampala currently heads the Technology division of Emergency Management and Research Institute (EMRI), which provides emergency response (police, fire, and medical) through a single number in 50 cities and 3500 villages covering 25 million people. (But more on EMRI later on. It is really interesting.) Dr. Jampala holds a Ph.D in Electrical Engineering from the University of Washington, Seattle.

Other programs that HYSEA has sponsored include design competitions for Software Code Reviews which targeted college students and was conducted in partnership with Institute of Electronic Governance and Infosys. 26 colleges from all over Andhra Pradesh participated in the competition. (As an aside, the winners were Siddharth and Chandrasekhar from Gurunanak Engineering College, and runner ups where Swarna Hema and Sameer Kumar from Gokaraju Rangaraju Institute of Engineering and Technology, and Sravan Kumar Akella from Akula Gopayya College of Engineering and Technology.

Posted by Jon Erickson at 08:42 PM  Permalink |

The way Jason Beres sees it, the Three-Mile Island nuclear reactor disaster of nearly 30 years ago was, in part, a UI problem.

And UIs are something Beres, who is chief technical evangelist at Infragistics, understands. After all he's written the book (okay, a book or two and a bunch of articles) on the topic -- and that was the focus of his presentation at Dr. Dobb's SD Best Practices India 2007. Entitled "An Agile Approach to Building Great User Experiences," Beres' presentation examined the "user model" which focuses on building UIs based on what users wants. The "user model," in other words.

There are a couple of things particularly interesting about the user-model approach. One is that it requires you clearly identify who you user/client is before design and coding starts. Most importantly, it helps you identify potential conflicts early one. For instance, will the appliation be used by both a novice and a power user? If so, how do you cater to the needs of one and the demands of the other without alienating both?

The second intersting thing about the user model is that it is ideally suited to sync up with agile methodologies, particularly in terms of iteration and the like.

What I liked about Jason's presentation was that it became clear that Infragistics, the company he works for, eats its own agile dogfood. That is, not only does Infragistics enocurage its customers to adopt agile methodologies when using Infragistic tools, Infragistic uses agile methodologies to build those tools. All the way from techniques like user models to daily, 15-minute standup meetings, 30-day sprints, and other Scrum-like techniques.

Oh, and the Three-Mile Island stuff? Beres showed photos of control panels at the nuclear site that had important switches identified by beer-bottle caps adhered to the switch. Let's see, Budweiser is "turn on the airconditioner," Coors is "fire the reactor" or whatever. Not what you'd call intuitive, nor a great user experience.

Posted by Jon Erickson at 08:05 PM  Permalink |

What have I so far learned in India? Well, for starters, I wouldn't last 5 minutes on a motor scooter in Hyderabad or Chennai. I admit it -- I'm an amateur, no matter what I thought before arriving in India. Which is why I don't understand why the boss was actively encouraging to "Rent a scooter, have some fun. Helmets? Who needs helmets?" Do you think she was trying to tell me something?

Other things I've learned:

• Political leaders in India are serious about making the country a world leader in high technology in general, and software development in particular. In Chennai, for instance, community leaders just announced that they will be establishing 24 high-tech industrial parks over the next 10 years. Five will be built immediately. The area, which has a population of about 6 million people, currently only has a couple of industrial parks.
• The ratio of men-to-women at the sessions in Hyderabad and Chennai remains in favor of men (that is, lots more men than women). But in an admittedly scientific analysis, there seems to be more Indian women attending the technical conference than you'd see at a similar conference in the U.S. This was confirmed to some degree when I learned that currently, far more women than men are enrolled in computer science programs at universities in India. (Likewise, the medical professions have more women than men enrolled.)
• The coffee in Chennai is killer caffine. Love it. Even better, there are no Starbucks, although U.S. coffee giant plans on establishing its first forays in Mumbai or Delhi by the end of this year.
• This has nothing to do with India, other than I learned it here. In his early morning session (which was again packed wall-to-wall), Scott Meyers mentioned that, according to research, if you are looking for errors in source code, you will find more errors if you print it out and examine on paper than you will if you examine it on-screen.

Okay, another Scott Meyers story. In the same early-morning session, Scott referenced Hugh Thompson's bringing down info/entertainment systems on airplanes.

Scott granted that he wasn't on the airplane -- and that he was glad he wasn't. So see, it just wasn't me.

Posted by Jon Erickson at 02:20 AM  Permalink |

We're off and running -- from one airport to the next. Which is my way of telling you that Dr. Dobb's SD Best Practices India 2007 is underway.

Scott Meyers capped off a full day of lectures in Hyderabad by speaking to a standing-room-only crowd of architects and developers on the topic of "Better Software: No Matter What." The "no matter what" referred to "no matter what language or platform" you're developing in or for. Scott, you recall, is primarily known for his books and article on C++. By using the "no matter what" tag, he wanted to make sure attendees understood he was talking about better software, not necessarily better C++ software.

That said, part of the focus of Scott's presentation involved static analysis, and the message he wanted to get across was "embrace static analysis". Scott pointed out that the types of problems static analysis can detect include:

• Design violations, such as dependency errors and cyclic dependencies.
• Imissions, e.g., subclass method redefinitions that fail to call superclass definitions.
• Logic errors, e.g. off-by-one or other boundary errors.
• Inefficiencies, e.g., adjacent loops that could be fused.
• Security issues, e.g., failure to validate user input.
• Typos, e.g., if (x + y = z) ...
• Violations of local coding standards, e.g. functions that exceed a complexity metric

Scott then pointed out the advantages of static analysis, including:

• Static analysis is more reliable than debugging and testing.
• Static analysis incurs no runtime cost.

He went on to examine the role of code reviews and testing in the software development lifecycle, noting that reviews can’t replace testing -- they’re complementary.

Other speakers in Day 1 of the conference included Hugh Thompson who spoke on building security into your software, Ken Pugh who discussed managing global and distributed teams, Andrew Stellman who explained what makes open source projects work, Anil Jampala who described the role of the Hyderabad Sofware Exporting Association, Jason Beres who examined agile approaches to building GUIs, Jagdish Babu who described how to maximize application performance in multi-core processors, S.S. Ramakant who showed how to building distributed systems using Visual Studio Team Systems, and Abhishek Mathur who look at VSTS from the perspective of project management.

The Conference continues on January 17 in Chennai, and wraps up in Bangalore on January 19.

Posted by Jon Erickson at 12:35 PM  Permalink |

Some people collect stamps. Other hobbyists go fishing. Some even write computer programs for fun. Whatever your pastime of choice is, I wish Hugh Thompson's hobby was something different, at least when he and I are flying on the same airplane.

You see Hugh, who is best known for as a security expert who has written articles for Dr. Dobb's including Rethinking Software SecurityRethinking Software Security and Red-Team Application Security Testing, gets his kicks from crashing computing systems -- all in the name of research, of course. In itself, that's okay and, in fact, a good thing. Except Hugh's particular delight is in crashing the info/entertainment systems on airplaines. Now that in itself is okay too, except when I happen to be on the same plane.

I first heard about Hugh's experiences in crashing a Linux-based info/entertainment system when sitting in on a lecture he was presenting at Dr. Dobb's Architecture and Design World 2006 Conference. Hearing about it in the abstract (if chewing on a turkey sandwich at the luncheon keynote can be consisted abstract) was interesting and amusing.

But more recently, I met up with Hugh at the Frankfurt Germany airport where we were on the same plane to Dr. Dobb's SD Best Practices India conference. Not only were we on the same plane, but Hugh was sitting in the seat directly in front of me. There I was, expecting a pleasant flight -- love that airplane food, those free movies, and the chance for a nice nap. Foolish me. The plane hadn't even taken off yet when Hugh starts cackling "Come look at this." As you can probably guess, he had already crashed the info/entertainment system, this time a Windows-based one.

I suppose I ought to be thankful that the plane was still on the ground, but somehow I still didn't nap too well, thinking of how easy it was to crash the system and there Hugh was with plenty of time on his hands in an 8-hour flight to Hyderabad.

And then there's the flight home to look forward to. Hugh, how about I buy you a crossword puzzle book?

Posted by Jon Erickson at 04:02 AM  Permalink |

Over the years, I've herded cows, fed cows, milked cows, and, to put it delicately, cleaned up after cows. Consequently, it shouldn't come as a surprise that there's not a lot of love lost between Elsie and me. Still, I found it exciting to learn that Somark Innovations has developed a chipless RFID ink and tested it on cattle to identify and track cows.

The process developed by Somark involves a geometric array of micro-needles and reusable applicator with a one-time-use ink capsule. According to Somark co-founder Mark Pydynowski, it takes 5 to 10 seconds to "stamp or tattoo" an animal, and there is no need to remove the fur. The ink remains in the dermal layer, and a reader can detect it from 4 feet away. As anyone who has had tattooed or attached tags to a cow's ear will tell you, this is good news.

But this wasn't the RFID news that put a smile on my face. No, that news was Honda Italia Industriale's announcement that it is using RFID to transform the production processes at its Atessa, Italy plant to achieve higher levels of efficiency and accuracy in managing motor scooter production. (Did I mention that I'm a motor scooter nut? That, much to my wife's disgust, I currently have three of them in the backyard. I don't know what she is complaining about because it wasn't that long ago there were five of them there, most in various stages of rebuilding and repair.)

In any event, Honda Italia will be implementing IBM's RFID tools for real-time, automatic identification of each scooter along the entire production chain. The RFID tags will also be used on micro-lots of critical components, such as engines. Apparently IBM has been collaborating for a long time with Honda Italia engineers in the design of the new processes and in the identification of the best solution. The RFID technology will be then integrated with Honda's existing IT systems through a Linux and Java (J2EE) application built on the IBM WebSphere Application Server to track inventory and to monitor ways to improve efficiency. (For more on some of what IBM is up to with RFID, listen to this interview with Chris Clauss on Web services and RFID.)

Admittedly, there are those who say that RFID is a bunch of bull, but I'm not one of them -- at least not after this week's news.

Posted by Jon Erickson at 10:00 AM  Permalink |

D is finally out da door and Walter Bright, D's developer, deserves a pat on da back. Several years in the offing (Walter first wrote about the language in "The D Programming Language" in the February 2002 issue of Dr. Dobb's Journal), the official Version 1.0 was released just last week by Digital Mars, Walter's company.

So what is D? It is a freely available programming language that looks a lot like C/C++, but which eliminates features that make programs difficult to write, debug, test, and maintain. Those bad features are replaced by good features that make it easier to do such tasks. In short, D's emphasis is on simple, understandable, and powerful syntax. In this vein, D focuses on combining the power and high performance of C and C++ with, according to Walter, the programmer productivity of modern languages like Ruby and Python. All the while, paying special attention to quality assurance, portability and reliability.

There's a lot more to D than dat, however. D is statically typed, and compiles direct to native code. It's multiparadigm, supporting imperative, object-oriented, and template metaprogramming styles. To see how it compares to languges such as C, C++, C#, and Java, see this chart.

There are currently two implementations, the Digital Mars DMD package for Win32 and x86 Linux, and the GCC D Compiler package for several platforms, including Windows and Mac OS X. Moreover, there's a large collection of D source code and projects are at dsource D's community site. In addition, DDJ and the late CUJ has published numerous articles on D, primarily via Matthew Wilson's long running column.

So congratulations Walter. A job well done.

Posted by Jon Erickson at 04:34 PM  Permalink |

It used to be that astronomy in general and telescopes in particular were smoke and mirrors to me. Eventually, I figured out that they were just mirrors. And then somewhere along the way (circa, the Keck Telescope), telescopes became computers and mirrors.

The same thought must have occurred to Google, although folks there are a lot smarter than me so it all made sense to them a lot sooner. The end result is that Google recently joined with 19 other organizations to build the 8.4-meter Large Synoptic Survey Telescope (LSST), scheduled to see first light atop Cerro Pachón in Chile in 2013.

Google's role will be to organize the massive quantities of data and make that data useful. The decade-long LSST sky survey will generate more than 30,000 gigabytes (30 terabytes) of image data every night. Google manage large parallel data streams, and process and analyze data non-stop so that discoveries become available in real time.

"The LSST will be the world's most powerful survey telescope, with vast data management challenges," Donald Sweeney, LSST project manager, said. "LSST engineers and scientists have been collaborating with Google on number of these exciting opportunities. Even though the universe is very old, exciting things happen every second. The LSST will be able to find these events hundreds of times better than today's other big telescopes. Google will help us organize and present the seemingly overwhelming volumes of data collected by the LSST."

No matter how big or how small, telescopes and astronomy is always fascinating. That's one reason we've covered them off and on over the years. For instance, there's:

• David Cox's article XML for Instrument Control and Monitoring which examines the Instrument Markup Language, an XML dialect designed to aid in the exchange of data and commands with remote instruments.
• Then there's Don Parrish's article on Image Processing and Visual Basic which focused (no pun intended) on improving I/O and enhancing image quality.
• Thomas Schneider's Astronomical Adaptive Optics which explains how astronomical adaptive optics is a technique for the real-time removal of atmospheric distortion.
• And Lars Frid-Nielsen and Alex Lane's article Celestial Programming with Turbo Pascal in which he uses Turbo Pascal and a CCD camera to brings astrophotography to the PC.

Even in a backhanded sort of way, the relationship between computers and telescopes is taken for granted, as evident by the quote attributed to Edsger Dykstra in which he supposedly said "Computer science is no more related to the computer than astronomy is related to the telescope--the point being that the computer is just a tool to get to this larger science." I'll buy that.

Posted by Jon Erickson at 12:58 PM  Permalink |

Over in the Architecture and Design department, I prattled on a bit about how security experts are warning that the coming security dangers are from inside organizations, not intruders. To make their case, researchers at the Software Engineering Institute modeled these threats using the System Dynamics methodology.

Okay, I admit I skimmed over "System Dynamics methodology" without giving it a lot of thought. Luckily, Len Malczynski stepped up to the plate, letting me know that the methodology is 50-years old this year and doing fine, thank you. At Len's suggestion, I went over to the System Dynamics web site and learned a few things, starting with what exactly Systems Dynamics is:

System dynamics is a methodology for studying and managing complex feedback systems, such as one finds in business and other social systems. In fact it has been used to address practically every sort of feedback system.

The site goes on to explain that the methodology:

• Identifies a problem,
• Develops a dynamic hypothesis explaining the cause of the problem,
• Builds a computer simulation model of the system at the root of the problem,
• Tests the model to be certain that it reproduces the behavior seen in the real world,
• Devises and tests in the model alternative policies that alleviate the problem, and
• Implements this solution.

I also learned that the System Dynamics Society is quite active, with distance learning programs, newsletters, and an upcoming conference later this year. The conference, which will be held at MIT, should be fun. Why do I think so? Because they'll be celebrating the 50th anniversary of System Dynamics -- and any society that uses a Beer Game to introduce concepts of system dynamics knows how to have a good time.

Thanks for the pointer Len. I enjoyed learning something new.

Posted by Jon Erickson at 12:52 PM  Permalink |

When it comes to software, updating is a matter of "when," not "if." Just this weekend, for instance, I was going over a soon-to-be-published Dr. Dobb's article by Jack Purdum which described how he took his Microstat, a 1980-era CGA-based program for MS-DOS, and updated it to .NET.

Of course, Dr. Dobb's has published all kinds of articles about updating software. Among those that come to mind are:

• Lessons Learned.
• Updating Smart Clients with ClickOnce.
• Eclipse: Adapting and Updating an IDE.
• Radical Refactoring.

But I'm the first to admit that updating desktop software is child's play compared to what's involved in updating software that's anywhere from 35 million to 250 million miles away. That's something that Glenn Reeves found out when finding and fixing the Priority Inversion problem the Mars Pathfinder spacecraft experienced a few years ago.

Still, that's what NASA recently did when updating the software for Spirit and Opportunity, the twin Mars rovers. Spirit will begin its fourth year on Mars on January 3, and Opportunity on January. 24. In addition to their continuing scientific observations, the updated software lets them test new skills, including letting spacecraft examine images and recognize certain types of features. This is based on software developed for NASA's Space Technology 6 "thinking spacecraft."

For instance, Spirit has photographed dozens of dusty whirlwinds in action, and both rovers have photographed clouds. Until now, however, scientists on Earth have had to sift through many transmitted images from Mars to find those few. With the updated software, the rovers can recognize dust devils or clouds and select only the relevant parts of those images to send back to Earth. This increased efficiency will free up more communication time for additional scientific investigations.

To recognize dust devils, the new software looks for changes from one image to the next, taken a few seconds apart, of the same field of view. To find clouds, it looks for non-uniform features in the portion of an image it recognizes as the sky.

Another updated feature, called "visual target tracking," lets a rover keep recognizing a designated landscape feature as the rover moves. Visual target tracking can be combined with a third new feature -- autonomy in calculating where it is safe to reach out with the contact tools on the rover's robotic arm. The combination gives Spirit and Opportunity a capability called "go and touch," which is yet to be tested on Mars. So far in the mission, whenever a rover has driven to a new location, the crew on Earth has had to evaluate images of the new location to decide where the rover could place its contact instruments on a subsequent day. After the new software has been tested and validated, the crew will have the option of letting a rover choose an arm target for itself the same day it drives to a new location.

The new software also improves the autonomy of each rover for navigating away from hazards by building better maps of their surroundings than they have done previously. This new capability was developed by Carnegie Mellon University and JPL.

"Before this, the rovers could only think one step ahead about getting around an obstacle," said JPL's John Callas, project manager for the Mars Exploration Rovers. "If they encountered an obstacle or hazard, they'd back off one step and try a different direction, and if that direction didn't work they'd try another, then another. And sometimes the rover could not find a solution. With this new capability, the rover will be smarter about navigating in complex terrain, thinking several steps ahead. It could back out of a dead-end cul-de-sac. It could even find its way through a maze."

This is the most comprehensive of four revisions to the rovers' flight software since launch. One new version was uplinked during the cruise to Mars, and the rovers have switched to upgraded versions twice since their January 2004 landings.

Posted by Jon Erickson at 10:28 AM  Permalink |