Thursday, June 30, 2005

Having an Impact

If you cannot ascertain from the name of this blog, I will tell you that in addition to computer science and psychology I am interested in space exploration, astronomy and climatology.   On July 4th NASA is attempting to crash part of a space probe into the comet Tempel 1, with the main craft recording the event.  If all goes well the craft will be placed on an extended mission with its next probable target the comet Boethin. It will take 3.5 years to get there.  So even if you read this after July 4th  2005, there is still more to explore with this probe.

A frequent contributor to this blog and former student, Greg Horvath works at JPL on this project and sent me this heads up a few days ago.  I wanted to share Greg's logbook entry with you.  The text was provided by Greg with some minor edits from me.  Actually there was more interesting stuff on testing in his entire email, but I will save that for another post.  Later!

So, on to the fun stuff:

- We release the impactor Saturday evening, 7/2, at 11pm PDT (2am 7/3, Sunday morning EDT).
- Assuming all goes well, the impactor will arrive at the comet at 10:52pm PDT on Sunday night (1:52am EDT Monday 7/4).

In addition to the instruments on-board the spacecraft, we will have a number of other on-orbit telescopes taking both visible and spectral images (Hubble, Chandra, Spitzer f/k/a SIRTF) as well as many ground observatories including Keck, Palomar, and the SMA.  There will be plenty of gooey data to check out if this goes off as planned.

Our mission website has a schedule of programming
As of right now, the schedule is:
Deep Impact Press Encounter Events - Jul. 1 - 4
(All times PDT.)

    * Pre-impact briefing: July 1, 10 a.m.
    * Pre-impact update: July 3, 11 a.m.
    * NASA TV coverage: July 3, 8:30 p.m.
    * Expected time of impact: July 3, 10:52 p.m.
    * Post-impact briefing: July 4, 1 a.m.
    * Post-impact press conference: July 4, 11 a.m.

Also, there is some animation and a few videos over at  Click on 'Night of the Comet', and it will launch a little flash player.  (In fact if you click the picture of the woman under the 'Videos' tab of the flash player, you can see me near the beginning of the clip being a big dork.)

As I've mentioned, we will be on NASA TV, which you can stream online at  (see times above).  I'll be on-console for impact so if you tune in you may see me pointing to a blue screen and doing other amusing geeky stuff.

Other good sources of info are:
(This site usually has good real-time info updated during critical mission events).  Also, our mission webpage will be updated in near real time during encounter, including images as they come down.

Lastly if you're in the SoCal area, the Planetary Society will be holding an event with real-time data streaming in and running commentary.  More info here:
It's in Glendora, and entry is $20.  There will be some guest speakers as well.

Thursday, June 16, 2005

Once upon a time ...

It is easy to be cynical in this age of outsourcing, impossible schedules and managers who think the only valid motivational technique is fear.  It is hard to remember the sense of wonder of software and computers that initially lured us into this field.  In working on Research for another task I came across an article by Allen Newell, "Fairy Tales," AI Magazine, WInter 1992. Note that you have to find the article in the table of contents, the first click on the title provides the abstract and clicking on the title within the abstract provides the article. It is a short, 3 page article and I highly recommend it to give yourself a boost and get back to viewing the big picture of why you do what you do.

The article discusses computer science and the promise it provides.  Rather than summarize it, I urge you to read it.

A bit on Allen Newell.  Allen, along with Herb Simon, Marvin Minsky and John McCarthy are known as the Fathers of AI in the United States. He was a great guy and had a great sense of humor.   He also was very direct and got right to the point.   For my Human Computer Interaction courses I have a clip of him struggling with a photocopier.  His personalty shows through perfectly. He died over a decade ago but the ripples he started will continue for a long time.

To close this off I would like to quote the last sentence of his article:

Finally, I wish to express my feeling of childlike wonder that my time to be awake on this earth has placed me in the middle of this particular fairy story.


Friday, June 10, 2005


The title of this post is a takeoff on the word tomfoolery which means foolish or senseless behavior.  One of the discussion topics for my Software Engineering course concerned building and using your own tools.  One of the students in the discussion, Chris Slater, offered this insight:

I am fairly new to the industry, so I have not developed a set of tools that I carry around.  However, at my new job, I have begun to develop these tools.  The funny thing about this is I created these tools in hopes of standardizing the tool set for our new project; however, once the other developers got a hold of these tools they either: (a) threw them away, or (b) rewrote them to fit their personal preference.

I then asked the class:

Did you ever ask  why they tossed or modified the tools?  This is a common experience and it would be nice to understand the, "not invented by me syndrome."  Is it lack of documentation?  Lack of Support?

I do notice that the use of tools, and reuse in general, follows an inverse square law of distance between parties.  It is much more likely that I will use tools or code from someone in an office nearby.  The probability drops off quickly the greater the distance. 

The only time I saw this not happening was during the mid years of UNIX (1970s-80s) and that was a factor (I think) of excellent documentation, UNIX manual pages, and a strong culture.

I did not expect anyone to respond, but Chris did (this is a paraphrase, it was longer):

Now, I also did some asking around and from what I can tell the two most prevalent reasons why tools such as mine get rewritten are ego or poor documentation.  I have to tell you the latter is one of the bigger problems I see.

What do you think is the reason for not using others tools?  Is it my distance inverse square law of reuse?  Is it poor documentation?  Is it ego?  Is it another reason?  I would appreciate your insight into this tomtoolery.

Thanks and later!



Tuesday, June 7, 2005


Julia Ryan has suggested another blog entry on source code management.  What tools do you use to manage source code and are these tools capable of providing statistics on the evolution of the source code?  If so, what sort of metrics do you typically collect and at what level (class, module, file or project)?  For example can your tool report the changed lines of source code and, if it can do you use that metric?  What other metrics do you use?

Generally we use CVS, but I am converting to Subversion, which seems a bit more straightforward.  To quote from the Subversion web site:

Subversion is meant to be a better CVS, so it has most of CVS's features.  Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.

I will report later this summer on my opinions of Subversion.  Of course if any of you have used these tools (or others), I would appreciate your comments.  Later.

Thursday, June 2, 2005

Program for Programming?

This summer part of my resolution is to clear my back log of blog posting from students (and add some of my own).  This blog is from Curtis Eckhardt from my Fall Software Engineering course at Stevens.  He poses the question: how does someone get started/accomplished in programming?  Is it solely through classes?   

What is or was your program for programming?   My program began as an undergraduate.  I had taken several classes that introduced programming concepts as part of their class (statistics and laboratory instrumentation) but I had not taken a programming course.  During the month break between the Fall and Spring semesters (1972-1973) I spent the holidays at home and then returned to school for 2+ weeks.  A professor (Don Walter) had given me a key to a room that contained a PDP-8 minicomputer that was used by the psychology lab for presenting and controlling experiments.   After those 2+ weeks I had a thorough grounding in assembler language and continued learning throughout the Spring semester.  That was my introduction to programming, which continued when I entered the graduate program at the University of Pittsburgh in Fall of 1973 and was introduced to the  PDP 15 installation at the Learning Research and Development Center

I am sure there are more current ways to learn programming.  What is your experience?  Do you  try to learn at least one new programming language a year?  I do and I encourage my students to do the same.  On to Curtis's post - later!

Here’s a question that jumped into my mind the last class:

How do you jump into programming?

Honestly? I suppose you could start by buying a few programming books… but that seems a bit overwhelming. I mean there are many areas in programming. Hell, even picking an appropriate programming language can be a pain. Of course, other questions have to be raised before this conversation can go any further. So I’ll use what I know best and setup a scenario based on me:

You’re in college and would like to learn how to program because it appeals to your sensibilities. You’ve taken two programming classes and found that it’s fairly easy to pick up on. You also have in your head all the possibilities that knowing how to program can provide, but don’t know where to start. Being that you’re a mechanical engineer already approaching your junior year, you deem it unwise to switch over to programming engineering. So what do you do?

What I did personally was join a small organization called Windows Interest Group (WIG). The reasoning was simply, “surround myself with people that know how to program and want to program and it’ll rub off on me.” WIG was for a small group of people to get together and learn how to program. The only problem was the fact that the organization was brand new! I mean I was basically one of five people that was interested enough to return consistently. I didn’t learn how to program better, but gained a few more friends.

<Afterthought 12-14-04>
WIG was actually a Microsoft sponsored program. So a lot of the meetings were PowerPoint presentations of .NET and how it’s the “wave of the future” for programming. Promoting .NET was just a ruse to get money out of Microsoft. Even though the focus had to be on .NET technology, learning how to program was still the overall goal. That was fine and dandy, but what I was looking for was to get a group of people to work on a cool programming project. Our group tried twice… since we were all too busy with school and work, nothing was accomplished. Plus, there were only 2 people in the group that could have been lead since everyone else were essentially noobs at programming. Anyway, WIG is still active. In fact, visit the (now outdated) website:
</Afterthought 12-14-04>

Without a little direction it’s easy to get overwhelmed and lost in the sea of books and knowledge that’s out there. Where do you start and why? Are taking programming classes the only way to gain guidance? Since time is limited, how does one avoid wasting time?