Wednesday, November 4, 2009

Programming Duo: Wattdepot CLI

For the past couple weeks in my Software Engineering class I have been working on developing a branch of Command Line Interface for the Open Source Project Wattdepot. In essence Wattdepot is a RESTful web service that collects electricity data (such as current power utilization or cumulative power utilization) from meters and stores it in a database.

I have been working with a partner, Bao Ung and together we have developed our own branch of the Wattdepot CLI.

Our project branch is designated "umi" (as our group number was ten) and our distributed system can be downloaded at the Wattdepot-cli Google Project site by clicking here.

By using all of the SE tools we have been introduced thus far (ant, SVN, Google Code, and Hudson) we were able to effectively develop the project concurrently. The use of ant's automated builds and quality assurance tools ensured our project would run, SVN allowed both of us to commit changes to a single repository so each of us would have the most up-to-date classes, and Hudon recorded our build progress as well as our projects overall "build" health.

For the most part our system does run functionally and is able to process each command and return output. However even with the extension given to us by Prof. Johnson, neither of us found time to create test cases in order to thoroughly test our system. We also didn't break up the methods into their own classes, although it shouldn't be very difficult to do so as all the methods are independent and don't output directly to the console, all return strings. We just need to create 2 new packages "command" and "processor."All the coding is well commented and all java files pass verify.build.xml.

There were some minor work-arounds that we discovered worked better in the end. One of them is, if there were big changes done to the system, (i.e. refactoring of methods to suit a more dispatch style of command mapping) it was best to just have the person with the old version delete their existing source code and "update" so they will have the most recent version. Also, we had a little trouble organizing how the command arguments should be processed. After Prof. Johnson's lecture of HashMaps we got some insight on how to proceed.

A good portion of time was spent reading the Wattdepot API This was the hinder in work progress. All the commands were laid out for us, which can be found here we just needed to know how to access the data.

In the beginning it was hard to split the work. Previous ICS classes dealt with solo projects and sharing of code was not allowed, Bao and I were a little stumped as to who should do what. What we both realized is that it was easier to code in modules and have separate classes for each command, that way we don't run into any merge conflicts if we are modifying the same file. However in our situation we saw each other daily so merge conflicts weren't that much of a problem since we worked in close proximity.

No comments:

Post a Comment