Continuing with WattDepot: hale-aloha-cli-tiger

As part of our continuing development with WattDepot, my group and I were given the task of adding some new functionality to another project called hale-aloha-cli-tiger. We implemented three new commands to their CLI system: set-baseline, monitor-power, and monitor-goal. Here are the commands and a short description of each:

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.

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.

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 implemented the commands according to the specifications, and they all work as expected. There were some problems due to the previous state of the hale-aloha-cli-tiger project, but our group was able to work through it. Some of the problems were low test coverage, and bad error handling left over from the previous project. Some of these problems are still occurring, but we were not expected to fix the problems because we inherited them from the previous project.

I would say this system satisfies the three prime directives, that is, the system successfully accomplishes a useful task, an external user can successfully install and use the system, and an external developer can successfully understand and enhance the system. Despite some of the errors, the newly implemented commands are useful for retrieving energy data from the Hale Aloha Towers, and we were obviously able to enhance the system as external developers. There are also several guides on the project site that should help any external user successfully install and use the system. Based on that alone, the project satisfies the three prime directives.

Watt Depot Technical Review

As you may recall from my previous blog posts, I've been working on a command-line interface program which uses the WattDepot library to collect information about energy consumption for several residence halls at the University of Hawaii. I've learned a lot about software development throughout this project, and now I've been given the opportunity to review a similar system developed by another group which accomplishes the same task, to determine whether the system satisfies the Three Prime Directives. Here is a link to the project site I am reviewing.

Review question 1: Does the system accomplish a useful task?

Here are the available commands supported by the system:

> help
Here are the available commands for this system.
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
Note: towers are: Mokihana, Ilima, Lehua, Lokelani Lounges are the tower names followed by a "-" followed by one of A, B, C, D, E. For example, Mokihana-A.

There are a few problems with the system in question. Some major functionality, including the "daily-energy" and "rank-towers" commands, is missing or broken, when it should be present and functional according to the system requirements. Furthermore, there is a bug in the "daily-energy" command that results in the error message "Date must be before today" when the given date argument is actually a valid one. In short, I could not get the "daily-energy" command to execute properly no matter what input I provided. Additionally, the system does not handle some exceptions when dealing with user-input and instead may crash if the user provides "bad" input.

The other two required commands, "current-power" and "energy-since", are implemented and function properly, except, as previously mentioned, the system may crash if the user provides bad input or incorrect arguments. Because some major functionality is broken or missing, and because the system does not handle bad user input in a graceful manner, I would conclude that the system is somewhat useful, but could definitely be improved.


Review question 2: Can an external user can successfully install and use the system?

The project site home page provides a short, clear description of the system and its purpose. Although there is no sample input and output provided on the page, it is still pretty clear what the system does based on their description. There is also a User Guide wiki page that provides details on how to download, install and execute the system. However, I found that the instructions were not completely correct, as it said the .jar file used to run the system would be in the /build/jar directory, when it was actually in the top level directory (there was no /build directory in the distribution I downloaded). There was no compilation necessary since they provided an executable .jar file, so it was pretty easy to run the system as a user. Furthermore, the download link was labeled with the version number, so users can easily keep track of what system they are using.

Review question 3: Can an external developer successfully understand and enhance the system?

The Developer's Guide wiki page provided clear instructions on how to build the system from sources, as well as the project guidelines for development, including the implementation of JUnit tests for all new features. It also provides guidelines for formatting code (including a downloadable file for auto-formatting within Eclipse), adding new issues, and verifying the build before committing changes with "ant -f verify.build.xml". I was able to determine that the developers use automation tools such as Checkstyle, Findbugs, PMD, and JUnit.

Lastly, there is a link to the Continuous Integration project build on Jenkins. From the wiki page I was able to conclude that the developers use Issue Driven Project Management as their development process, although this is not explained in detail on the page itself. There were no specific instructions on how to generate JavaDoc documentation, but I was able to accomplish this without any problems and I feel most Java developers would be able to as well. The documentation was well-written, and I felt the developers used descriptive names throughout their system, such that the purpose of a method, class or variable could be determined implicitly from its name in most cases.

I was able to generate coverage information about the system using Jacoco, and found that their tests only covered about 21% of the code. I saw that the command manager class, as well as each respective command, had its own JUnit test class associated with it, but some of the tests were not named correctly, and thus may not have been counted in the coverage. This likely contributed to the low coverage percentage.

I found that the source code followed coding standards and made effective use of comments for the most part. The code was easy to understand and I feel like an external developer could understand the system fairly easily by looking at the code and documentation.

I read the "Issues" page on the project hosting site to determine which parts of the project were worked on by each developer. I could tell that all three developers worked on the project equally by the amount of issues attributed to each member. Furthermore, I believe it would be fairly easy for an external developer to determine who to ask if they had a question regarding a particular part of the system.

I had a look at the Continuous Integration server associated with the project and saw that anytime there was a build failure it was corrected soon, or at the very least, someone worked on getting it corrected as soon as possible. It was clear that the system was worked on in a consistent fashion, and every commit was associated with an appropriate issue, which means the developers did a good job of breaking the system up into issues of manageable size.

From these results I would conclude that a new external developer could successfully understand the current system and enhance it with relative ease. I think the documentation, comments, and the readability of the source code would be pretty helpful to a new developer, and they would be able to successfully contribute with the current team to improve the system.

Watt Depot Group Project

For the past couple of weeks I've been working on a group project expanding on the WattDepot service that, if you recall from my previous blog posts, collects electricity data from meters and stores it in a database. This allows other tools to retrieve the data for visualization and analysis.

Our group created a command line interface program to help understand various aspects of energy use in the Hale Aloha residence halls at the University of Hawaii at Manoa. The user can call different commands and retrieve energy data with output that is easy to read and nicely formatted.

Furthermore, our program is modular and uses a reflection-based command manager that allows for new commands to be added easily to the system. Because the command manager scans for commands upon execution and does not hold a static list of the commands, no further changes to the code need to be done for new commands other than the command implementation itself.

This was my first experience with issue-based project management and working with a group using tools like subversion and google project hosting. Overall it was a really positive experience, and I know I will use the skills I learned in the future when building software in a group environment. My group members communicated effectively and I believe the quality of our software is pretty good. We implemented all of the required functionality as well as the reflection-based command manager which was not required, but offered for extra credit (Thanks Toy!).

Overall this project was a positive experience and one of the better group projects I've been a part of, simply for the fact that communication was not a problem. I've had my fair share of bad group projects where communication is a problem, and they can be pretty painful experiences. Thankfully were we able to work together effectively and communicated to each other at each step of the way.

Project site: hale-aloha-cli-tnt

You can download a release of the program from our hosting site here.

Hawaii's Energy Future

Hawaii is a unique place unlike anywhere else in the world. But the challenges it faces and will continue to face in the near future regarding energy needs are just as unique, and that can be viewed as a blessing as well as a curse. On one hand, there are so many opportunities for people from a wide range of professions to become involved in improving and innovating Hawaii's energy future. Yet, on the other hand, there is a sense of urgency regarding energy in Hawaii because of our dependence on imported oil for our energy needs.

This means that if we fail to develop sustainable energy in a meaningful way, and before it's too late, the consequences for Hawaii will be far more severe than it would be in other places, like the mainland U.S., for example. Hawaii already has some of the highest gas prices in the nation, and we see those costs not only at the pump, but at the grocery store and just about everywhere else as well.

One thing I've been exposed to regarding Hawaii's energy future, and that I think is really exciting, is the fact that Hawaii can potentially develop just about every renewable energy source there is, from solar and wind, to geothermal and more. This means that we can become experts on all of these if we devote the necessary resources and effort they require. Furthermore, we will be able to export that expertise abroad as the need for renewable energy continues to grow elsewhere.

What are some of the problems facing renewable energy in Hawaii? So far it seems there are definitely some environmental and cultural issues surrounding the topic. Some are strongly against building wind turbines on certain islands or in culturally significant locations. Some don't think it's fair for one island to have wind turbines in order to power other islands. I think these sort of issues will begin to take a back seat once that "sense of urgency" thing I previously mentioned begins sinking in (when gas prices hit $10 a gallon, etc.). When that happens, people will check their priorities and begin to see that renewable energy is of paramount importance.

I think it will take a lot of cooperation from everyone if we are to solve the energy problem in Hawaii. Furthermore, I think that educating people about energy, and whether or not we will be able to do that effectively, will prove to be one of most important factors in whether or not we improve Hawaii's energy future. We can all make a difference just by conserving energy ourselves and being more aware.

WattDepot Katas

To begin our exploration of energy-related programming, my fellow ICS classmates and I have been tasked with hacking out 6 programming exercises, or katas, that deal with WattDepot.

What is WattDepot you ask? Well, here is part of the description from the host site:

"WattDepot is an open source, RESTful web service that collects electricity data (such as current power utilization or cumulative power utilization) from meters and stores it in a database. The data can then be retrieved by other tools for visualization and analysis. It is designed to provide infrastructure for experimentation and development of "Smart Grid" applications."

So as you can see, WattDepot is a useful tool for viewing energy consumption data. Here are the 6 katas we were required to do in order to become more familiar with the WattDepot library:

Kata 1: SourceListing

Implement a class called SourceListing, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and their descriptions, sorted in alphabetical order by source name.

I finished this kata during class. It took me about twenty minutes and was pretty straightforward.

Kata 2: SourceLatency

Implement a class called SourceLatency, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the number of seconds since data was received for that source, sorted in ascending order by this latency value. If no data has every been received for that source, indicate that.

This kata was also straightforward. It took me a half an hour or so.

Kata 3: SourceHierarchy

Implement a class called SourceHierarchy, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a hierarchical list of all sources defined on that server. The hierarchy represents the source and subsource relationship between sources.

This was the only kata I didn't complete. I couldn't figure out how to get the subsource data that I needed in order to print the hierarchy the way I wanted.

Kata 4: EnergyYesterday

Implement a class called EnergyYesterday, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the amount of energy in watt-hours consumed by that source during the previous day, sorted in ascending order by watt-hours of consumption. If no energy has every been consumed by that source, indicate zero.

Katas 4, 5 and 6 together took me about three hours altogether. They were pretty challenging because this was the first time I dealt with timestamps or dates in Java, and I found them to be very non-trivial.

Kata 5: HighestRecordedPowerYesterday

Implement a class called HighestRecordedPowerYesterday, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the highest recorded power associated with that source during the previous day, sorted in ascending order by watts. Also indicate the time when that power value was observed. If no power data is associated with that source, indicate that.

Kata 6: MondayAverageEnergy

Implement a class called MondayAverageEnergy, whose main() method accepts one argument (the URL of the WattDepot server) and which writes out the URL argument and a list of all sources defined on that server and the average energy consumed by that source during the previous two Mondays, sorted in ascending order by watt-hours.

This kata was hard because you had to figure out how to determine the day of the week in order to find the average energy for a Monday--another non-trivial task. This kata took me about an hour.

From these katas I learned that energy data manipulation can be really useful. I think its important that the software analyze the data and create output that is easy to read and understand. That way it can be utilized fully by other professionals and not just other programmers.

5 Things ICS Students Should Know in Order to Pass the Midterm and Maybe Graduate One Day

Midterms are upon us, which means it's that time of the semester again. Sleep-loss is at a peak and attention spans are running dangerously low around campus. In order to protect ourselves against impending doom, my fellow ICS students and I have been working in collaboration to produce a study guide, to which I am contributing the following five questions.

1. When starting Ant, you can select which target(s) you want to have executed. What happens if no target is given?

A: When no target is given, the project's default is used.

2. What is one example of manual quality assurance techniques?

A: Writing units tests with JUnit. Conducting code reviews.

3. Why is manual quality assurance bad for finding low level code defects?

A: It is difficult/expensive for finding low level code defects. It must be redone for all projects.

4. In Java, when should you use Enumerated types (rather than, say, an ArrayList)?

A: Whenever you have a well-defined, fixed set of values which are known at compile-time.

5. What is the convention for naming packages?

A: Use reversed internet domain names as package prefix, ex. "edu.hawaii." Use a single lowercased word as the root name for each package.

Host with the Most

My beloved robot, BattleBot, who has been the topic of most of my recent blogging, has a new home on the interwebz. That's because I've recently created a Google Project Hosting site in his honor so that other, inferior robots may look upon him and become inspired by his awesomeness...

In all seriousness, the reason I did this was to gain experience with configuration management systems and subversion, neither of which I had ever used prior to this. After downloading the SmartSVN client and interacting with my subversion repository, I quickly realized how much of a "game changer" configuration management really is. Having worked on a few projects with small amounts of code in a group before, I know how hard it is to manage the sharing of files and how difficult it can be to track changes and stay in sync. Thankfully, subversion makes collaboration much easier. It was simple to set up and get running, and although there are some practices that I will need to get used to (running 'verify' before every commit, etc.), overall it really does make life easier.

One of the things that I really liked about the Google Project Hosting is the ability to track changes to the source code and even view the changes in the source code directly in a side-by-side view. The idea that if my partner makes a change, I can view that change without opening Eclipse or downloading any files is really nice. However, I was a little surprised that it also showed every change I made to the wiki pages as a revision as well.

Overall, I think configuration management and subversion are really going to be helpful once I start collaborating more with other students and working on group assignments. I think it will allow me to focus more on writing code instead of spending too much time emailing files and trying to stay in sync. It definitely relives some of the headaches that can occur when collaborating.

BattleBot Google Project Hosting Site: http://code.google.com/p/robocode-ajo-battlebot/