Command Line in the Back Row

     Most young programmers like myself start off programming solo, but we eventually have to learn how to program and work with others since this is a more realistic approach to a programming type of job. Over the months, I've introduced many things such as the Ant Build System and Configuration Management that enables working in a group with ease. With these tools, anyone in a group can make a change in the project and update it to the other members, but would you say it's organized? Over the past weeks, I participated in a group to develop a program using a style called Issue Driven Project Management (IDPM). Simply, as a group, we break down the project into tasks and we update the project according to these small tasks that we are assigned to do rather than just writing code till it works and putting it together. IDPM organizes what each member of a team should do and is efficient since it acts as the guideline to finishing up the project.
     So let's get back to the project my group and I created. The project is called hale-aloha-cli, but for our group, it's entitled "hale-aloha-cli-backr". (Note: backr is or group name. Derived from "Back Row" since our group was formed in the back row of a classroom.) This project extends what I've been working on the more recent blog entry of WattDepot. This project is a command line interface program to understand various aspects of energy use in the Hale Aloha residence halls at the University of Hawaii at Manoa. Other information on our project can be found here: http://code.google.com/p/hale-aloha-cli-backr/
     As a group, we developed this program using Google Project Hosting to host a repository of our system online and we also used Jenkins to automatically build the project and check for errors. We divided the project into tasks which we individually had to update the status on (or Issue as it's called). At first, our group didn't start with much issues. We just builded the base system and didn't create any issues on them. After a formal meeting on IDPM, out group started fresh and created issues for all tasks from revision 1 of the project. After more issues, we finally accepted what these issues did; it directed each group member what they needed to do rather than asking someone what needs to be done. If an issue is found, anyone can create an issue for it where anyone could take to address it.
     We completed the project fulfilling the guidelines and implementing all what needs to be in our system. Our project takes in 6 basic commands:

• help

             Shows the user a list of commands, the parameters for them and a description.

• current-power [tower | lounge]

             Returns the current power in kW for the associated tower or lounge.

• daily-energy [tower | lounge] [date]

             Returns the energy in kWh used by the tower or lounge for the specified date (yyyy-mm-dd).

• energy-since [tower | lounge] [date]

             Returns the energy used since the date (yyyy-mm-dd) to now.

• rank-towers [start] [end]

             Returns a list in sorted order from least to most energy consumed between the [start] and [end] date (yyyy-mm-dd)

• quit

             Terminates execution

     Our project contains a main program which we named HaleAloha. This class is the main interface which does most of the printing on to the console, takes user input and connects to the WattDepot server. The HaleAloha class calls the CommandProcessor class which decodes the user's input in which this processor class makes a call to the CommandManger. The CommandManager invokes one of the command class that matches with the command input from the user using the Java Reflection API to create instances of these command classes. This seems to be more robust that hard coding these classes onto the file. This would make adding future command classes simpler.
     While developing the program, we also needed to test the program at the same time. In sync, we developed some test files for the classes we created. Using jacoco to see how much our test covered our code, we tried to make test cases that would cover most of our code, if not 100%. A simple program that is well tested will probably perform with no issues than a complex program with little or no testing. As we completed our test files, the entree project was hit with a curve ball. The WattDepot server crashed and we were unable to connect to the server, rendering our program useless for a couple of days. When WattDepot revived, our program ran as before, but our test files failed. This was because all old sensor data from WattDepot was no longer available. We could only access data since the revival. Our team acknowledged the problem and fixed it to get it up and running again; clearing up the many failed builds in Jenkins.
     Overall, I think our group produced a great quality program, though there will always be room for improvements.

Link:
Project Home: http://code.google.com/p/hale-aloha-cli-backr/
Download: http://code.google.com/p/hale-aloha-cli-backr/downloads/detail?name=hale-aloha-cli-backr-v1.zip&can=2&q=