And Now for Something Completely Different: Hale Aloha CLI, Version 2

Arriving at the point in software engineering where one has to work off a different code base is a daunting task from the get-go. So far in software engineering, my group consisting of Branden Ogata and Jason Yeo, were tasked with creating a simple command-line interface application that interacts with the WattDepot server monitoring energy usage in the Hale Aloha residence halls. Next, we performed a technical review on another group's system that had similar behavior to our system. Now, we continue our work in issue driven project management by experiencing the three prime directives of software engineering with respect to the third directive:

3. An external developer can successfully understand and enhance the system.

Although we tried to make every effort to meet in-person, our busy schedules prevented us from meeting on a regular basis. So what worked for us was to collaborate through both Google Docs and a single email thread where we kept track of issues. For this particular assignment, the SmartSVN client that maintains source code caused some problems for me when other group members would submit changes to a file I was currently working on. For example, updating my local copy of a file from an updated version in the repository would insert my team members changes into my copy and I would have to go in and clean it up. Maybe I haven't fully figured out how to use this application, but the only workaround I had was to simply start fresh by checking out the newest revision and simply inserting my changes manually. Although time consuming, we would often send an email out to each other notifying of an upcoming commit to the repository.

For this final assignment, our group added the following commands to hale-aloha-cli-cycuc:

(1) set-baseline [tower | lounge] [date]

This command defines [date] as the "baseline" day for [tower | lounge]. [date] is an optional argument in YYYY-MM-DD format and defaults to yesterday. When this command is executed, the system should obtain and save the amount of energy used during each of the 24 hours of that day for the given tower or lounge. These 24 values define the baseline power for that tower or lounge for that one hour time interval. For example, if lounge Ilima-A used 100 kWh of energy during the hour 6am-7am, then the baseline power during the interval 6am - 7am for Ilima-A is 100 kW.

(2) monitor-power [tower | lounge] [interval]

This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds. [interval] is an optional integer greater than 0 and defaults to 10 seconds. Entering any character (such as a carriage return) stops this monitoring process and returns the user to the command loop.

(3) monitor-goal [tower | lounge] goal interval

This command prints out a timestamp, the current power being consumed by the [tower | lounge], and whether or not the lounge is meeting its power conservation goal. [goal] is an integer between 1 and 99. It defines the percentage reduction from the baseline for this [tower | lounge] at this point in time. [interval] is an integer greater than 0.

For example, assume the user has previously defined the baseline power for Ilima-A as 100 kW for the time interval between 6am and 7am, and the current time is 6:30am. If the goal is set as 5, then Ilima-A's current power must be 5% less than its baseline in order to make the goal. At the current time, that means that Ilima-A should be using less than 95 kW of power in order to make its goal.

It is an error if the monitor-goal command is invoked without a prior set-baseline command for that [tower | lounge].

Entering any character (such as a carriage return) stops this monitoring process and returns the user to the command loop.

Our group was able to implement all three commands that works to specification. As of this writing, I think the overall quality of the system can still be improved. Although we were not responsible for the operation of the initial four commands the previous team had implemented, everyone on our team contributed to improving the original system if time permitted. For example, a team member reported that "output for the original commands are incorrect and at times not present". To be consistent with the three new commands in terms of look and feel, one team member modified the four original commands so that everything went together. Finally, we were also able to go back and fix some of the issues our group brought up in our technical review of cycuc's system detailed in my last blog entry.

Overall, there were some difficulties when trying to extend hale-aloha-cli-cycuc by implementing three new commands. I think that most people would have problems trying to add on features to someone else's code base and would just resort to rewriting everything from the ground up.
However, I feel that as a group with people working together, it is doable. Of course, it is helpful if you know the original developers and can just ask for their input on how they would do certain things to ease the process. Doing this project proved invaluable in allowing our group to experience firsthand what it takes to become a software engineer.