Idea: Revamping the MOSTValidator

Some of you are aware that I was one of the two developers commissioned to work on the MOSTValidator software used by the MOST Space Telescope team, and more recently, available to the public as a resource for the MOST: My Own Space Telescope contest. I built the software in 2005 using Java, the only programming proprietary language I was comfortable with at the time.

The software allows users to pick astronomical targets and tests against the MOST telescope’s “Continuous Viewing Zone (CVZ),” which is basically a set of astronomical coordinates that the telescope can point towards and “look at.” Satellites often have viewing restrictions due to their orbits (and the fact that there is often a giant blue planet in the way), and MOST’s orbit is…interesting, to say the least.

I developed it as an internal resource with the help of one of the graduate students who designed the CVZ graphing utility and all the conversion methods between various units. My task was to build the rest of the software, i.e., the searching interface and the networking components to retrieve coordinates of input targets from the SIMBAD database. I’d pass along the coordinates to the graphing utility and the user would be presented with a visual representation of whether the input target would be viewable by MOST at all.

Eventually, the MOST: My Own Space Telescope campaign began to involve Canadians with the MOST research, and I was asked to make the software available on a website dedicated to the contest. To this day I host and maintain both the software and the website (as is evident from the contest website’s URL, no doubt). So now, our little internal software tool was receiving quite a widespread exposure, and last year, SIMBAD completely renovated their site to allow XML SOAP requests to the database, so that involved a substantial overhaul of my networking code. Keeping in mind that I threw together a subpar user interface for the MOST team alone (the graphing module is beautifully done however), the software is now widespread enough that I think it needs to be revamped with the users in mind this time. Also, Java has got to go.

Here is what I would like to achieve (with affected operating systems in parenthesized italics):

1) Rewrite the existing software in C++ or Python using GTK+ to maintain cross-platform functionality while still embracing free software ideals (and encouraging users to use free operating systems in using this research tool) (all OS versions).

2) Use a proper design pattern-oriented approach to modularize the software. Networking, graphing, CVZ calculations and project management (loading, saving) should all be separate (all OS versions).

3) Provide installers for multiple operating systems, and debianize the GNU/Linux version for ease of use with package managers (GNU/Linux).

4) On that note, perhaps set up a PPA for the purposes of deploying updates quickly and effectively (GNU/Linux).

5) Provide a software update feature for non-package installations (all non-Debian based OS versions).

6) Use revision control to make it easy for future developers to collaborate or take over (all OS versions).

7) User registration/login/contest proposal submission from the software itself (all OS versions).

Point 2 is definitely going to require the maximum amount of work, as I have to re-think and re-engineer the modularized software. Most importantly, I want to decouple MOST’s CVZ from the software so that any other space telescope’s CVZ can be used in the future without requiring an entirely new software package. This will require serializing the CVZ data in a way that allows easy import/export/graph rendering. I’ve already learnt the lesson of modularizing the networking component in case SIMBAD performs another terrific system overhaul.

Point 7 is something that was part of the original codebase except it was going to take far too long to implement (the MOST contest was announced just as I began writing this piece of the software, so I chose to abandon it and instead use the Drupal web based method of interacting with users). I think it makes more sense to maintain everything in the one software package, however. Right now, users use MOSTValidator to validate their target choices, but they must then go onto the contest website to submit their proposal by copy pasting information obtained from the software, and if they want, attaching a PDF document. Consolidating this into the new software will standardize things a lot more. The software can be responsible for submitting a pdf or a format of the team’s choosing. We can get rid of our reliance on Drupal for submissions in this manner.

I like to think I’ve matured as a software developer since 2005. Looking back at MOSTValidator’s code base makes me cringe (mostly because of the Java), and I’m glad that the MOST team echoed my sentiments and gave their go-ahead on the project. Plus, by decoupling and rewriting a cleaner, ethically sound version of the software, we can hopefully encourage other outreach programs affiliated with other space telescopes to use our basic software with their own customizations (CVZ, graphing colours, submission standards etc.).

VR

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Canada License.