Issue Driven Management, Cooperation and the WattDepot CLI

There's little use to a good API if there isn't an easy way to interact with it. Enter the most l33t way of interacting with computers, the command-line interface. Having stood the test of time (I still find SVN management via the command-line to be the best way to do so) we were tasked to implement a CLI for the WattDepot server. And by "we", I mean the newly formed team of David Wilkie, Yong Hong Hsu and myself, or Team Cybernetic Cucumber (cycuc, for short.) To try to streamline development and ensure that not just one person is tasked with doing everything, we were encouraged (with our grades no less) to incorporate Issue-driven Development, Continuous Integration and Google Project Hosting into our development process. The product of which can be found at http://code.google.com/p/hale-aloha-cli-cycuc/.

Issue Driven Management

The most important new aspect of this development was the concept of Issue-driven Development. Instead of verbal planning, the team outlines Issues for tasks to be done, whether it be debugging, extending/enhancing the system, or just plain doing the documentation. In this digital age, to have anything less descriptive and concrete is a detriment to efficiency. Google Project Hosting incorporates Issues right into their client, making it easy for any person to file an Issue with the system and for the owners to comment and coordinate easily to make sure of its resolution. In terms of the project, we split up tasks with Issues, each of which corresponded to a task for the system. The way we split up the work was for me to focus on the Processor and DailyEnergy command, David to focus on the main CLI, documentation and the CurrentPower command, and for Yong Hong to focus on the RankTowers and EnergySince command. This is easily reflected in the Issues page, (with added Issues corresponding to defects throughout the development process.) All in all, I definitely would recommend Issue-Driven Management to any project with any amount of coordination; text is a great medium especially for coordination (even though the Internet is distracting and impersonal.)

The WattDepot CLI

Our command-line was a simple one implemented in Java. Consisting of a tiered hierarchy, it incorporates a User Interface, several classes that corresponds to queries to the WattDepot server, and a helper class to parse arguments. The hierarchy is listed as such:


| edu.hawaii.halealohacli.Client
|-> edu.hawaii.halealoha.Processor
|-> edu.hawaii.halealoha.Command


The Client was the main loop that interacts with the user. As such, it prompts the user to input a command and passes it to the subclasses depending on the command given. David was genius to implement an Enum to handle both the Operations as we well as the arguments, which made passing data to both of the subclasses extremely easy.

Once done with determining the client, the rest of the string passed to the Processor class to determine if the sources and timestamps are valid. Source validation was implemented by using the getSource(String string) method from the WattDepot API and timestamps were validated simply by checking if the string given was in the form of YYYY-MM-DD and that all values were valid to get information from the WattDepot Server. The Source and XMLGregorianCalendars required by the queries to the WattDepot server were then stored locally and passed to the main Client based on what was needed.

The Command class contains an interface with one method that contains one method, printResults, that all Commands are to implement. The interface ensured a common method that one could use to extend the system.  Each class queries the client and prints out the results of that query.  The following Commands were implemented:


current-energy [source]: The current energy usage of the given source.
energy-since [source] [date]: The energy usage of the source from the date provided to now.
daily-energy [source] [date]: The total amount of energy used by the source on that day.
rank-towers [date] [date]: List out the energy sources in ascending order by the amount of energy used between the two dates.


Each Command comes with a JUnit test that provides 94% coverage, meaning that most of the instructions are tested.

There are several flaws with the implementation as it stands now. Reporting errors to the user is hit and miss since we use ordinary Exception classes to throw with custom messages, which may or may not be descriptive. A more thorough implementation would incorporate custom Exceptions that would be thrown for a respective error (Invalid source, timestamp, timed out, etc). Another bug (though it could be seen as a feature) is that the sources aren't cleared when an error occurs, so if one were to input, say, "current-power Lehua", the Lehua source will stay in the processor until it's changed. This makes it easier for the user to make multiple queries to the same source without specifying it all the time, but also means for weird actions if a source is wrong (if one were to input "current-power foo" after the last command, it would throw an error and print out the energy usage for Lehua again, for instance.) More rigorous testing and reviews would certainly be beneficial for the system.

In all, it was a good challenge to work with a group for project development. Throughout our scholastic career, we were expected to churn out code on our own and by doing so we never really learn how to write for anyone but ourselves. With some help with Automatic Quality Assurance and Issue Driven Development, I've learned a few ways that I could use in the future when I'm not just developing for myself and a grade, but for a system that will be seen and modified by others both in this current development cycle as well as future ones.