Last time, I posted about continuous integration. This time, I will perform a technical review of another group's project. The project they are working on is a command line interface for a system known as Watt Depot. The Watt Depot system are servers located in the dorms of UH Manoa that monitor everyday use of electricity and is an ongoing project to reduce consumption of electricity. This group goes by the name of BackR, which means back row because they all sit there. The interface communicates with Watt Depot by getting information about power usage and displaying it for the user. More information about BackR's software can be found at this link.
This software was developed using two project management practices, including issue-based project management. The other practice used are continuous integration. To reiterate what issue-based project management is, this practice takes advantage of Google project's issue function to create issues on parts of the software to be worked on. Essentially, it is creating jobs to do. Continuous integration is the practice of reducing duplicate and conflicting work to a minimum. It uses a server software known as Jenkins which downloads the project from Google and uses Ant to verify that all there are no conflicts whenever a new build is uploaded.
I will be using the Three Prime Directives to review this project. These directives are:
Prime Directive #1: The system accomplishes a useful task.
Prime Directive #2: The system can successfully be installed and used by a new user.
Prime Directive #3: The system can successfully be understood and enhanced by a new developer.
Prime Directive # 1
The command line interface can accomplish a few tasks. At the moment, five commands are implemented: rank-towers, daily-energy, energy-since, current-power, and help. The rank-tower command ranks all the sources by how much power they consumed during a certain period of time. The towers are ranked from the least to the most consumed. daily-energy lists the power that source consumed on that day. energy-since tells you how much power was consumed from that day up to today. current-power tells you the current power consumption of that source. Finally the help command tells you all the available commands and how to use them.
I would say that it accomplishes a few useful tasks.
Prime Directive # 2
Downloading the program, it came with the source code and the jar file. The jar file was complete and didn't require any further action on my part to get it to work other than to execute it. It contains a version number.
This shows an example of this program in action.
It wasn't immediately known to me on how I would run such a program. Fortunately, there was a user guide available that I could read to find out. It lists the available commands but there wasn't an example of how they would be used. Installation seemed to be confusing as there was no link available to download Ant, a guide on how to install Ant, or whether it was necessary for a non-developer to use it. Executing the program itself was easy as there was an example of how to start it.
Below shows some invalid and valid inputs to test how the command line interface handles them:
current-power
daily-energy
energy-since
rank-towers
From this tests, it would be safe to say that it is easy for new users to install and use.
Prime Directive # 3
As a developer, I might want to add something to this myself if I find something lacking. It's an open source project after all and I should treat it as such. Looking at the developer guide, it tells me how I would begin development and which classes have been implemented. There is no way for me to find out what kind of standards the developers are using or if I'm going to meet them. The is a small note on what kind of management they use and that I should use it when I attempt something. There is no mention of whether or not it follows Continuous Integration.
Downloading the software from the SVN and generating Java documentation was a painless process. The information written were fairly short descriptions of each class. It supports information hiding by making all the global variables private and having accessor methods. I was able to build the system without any errors. Looking at the test source code, I can see that they have a large number of test cases for each class. Since each class has only one method for performing everything, it would be hard for a new developer to make modifications to these classes without breaking the test cases. The source code looked easy to understand since there were just enough comments that didn't make up more than the source code itself. Comparing the issues with the commits, it was clear who I could go to if I were to have any questions about the code. Although, it looked like one developer did the most work while the others did some. On their CI page, there was at least a daily development. Any issues they had were corrected promptly, usually on the same day.
A new developer would have a fairly difficult time modifying an existing class without breaking anything. Whereas creating a new module would be easy. It is easy to understand how the system works because the classes have been documented fairly well.
Thursday, December 8, 2011
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment