Hearts of Darkness: A Programmer's Apocalypse

Group work. For the most part working with other people can be an unpleasant experience. Often times one finds themselves carrying the group for whatever reason, but in this instance I can gladly say this wasn't the case. After getting our feet wet with the WattDepot API, my peers and I were split into groups to apply everything we've learned so far in software engineering (Ant, Google Project Hosting, Jenkins, etc..) to develop and maintain a small application that will display various energy usage in the Hale Aloha residence halls.

Taken from the help command in our program, the following were to be implemented:

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)

With three people in the group, we decided to split up the tasks as follows:

Input Parsing - To validate user input and make sure that it makes sense.
Program Processes - Takes user input and retrieves information from the WattDepot servers.
User Interface - Provides a simple command-line interface that allows for user interaction.

The assignment of tasks was deliberate as to cater to our strengths and weaknesses. In this case, only one of us completed all WattDepot katas in the previous class assignment.

Initially, there were some things to get used like creating an issue in Google Project Hosting that describes the task at hand. For example, the tasks above were broken down into smaller subtasks that are intended to be completed in 1 - 2 days. As detailed in the Issue Driven Project Management lecture, we tried to adhere to some rules that would lead to a successfully managed managed project:

Divide the work into tasks.
No task takes longer than 2 days.
Each task is specified by an issue.
Each issue has a single owner.
At all times, every person has an open task that they are responsible for completing.
Every commit specifies an issues in its log comment.

However, there were some issues with respect to these goals. Because of the way we subdivided the tasks, there were times in the project where I was blocked from completing my task. Working with the user interface, I described to a member handling the parsing portion of the program how I intend to send information inputted from the user to their package of commands. From there, he would parse user input and check the validity before passing it on to our team member handling the processing of data. Finally, the output returned by the WattDepot API would trickle back to me where it is finally outputted to the screen. Although we could have broken up the Processes package into smaller tasks, one group member felt confident that he would be able to handle the four commands without issue. This same group member happened to be the most talented of our group with respect to Java. Although we expressed an interest to create our own JUnit tests for each package, he was able to churn out the JUnit tests for each command in the processor package like he had been doing it all his life. This was not in vain, however, because when it came time to put everything together, I often had to go back into each test and verify that everything was working properly since we had some cross-platform issues regarding Ant and the verify task.

Instead of meeting regularly, we decided on meeting regularly online once a week over Google Docs and using the document feature to take notes that everyone could see. This worked out pretty well since this sort of acted as a virtual white board for us to hash out ideas. We also met twice a week before class to clarify anything that needed to be addressed, and we also used standard email as a message thread between the three of us to collaborate asynchronously. This allowed our group to be up-to-date on the issues going on with the project and thus actually worked out pretty well. When someone would finish a task, the issue of "What now?" would often come up and we were able to quickly find things to work on despite being trivial in nature. For example, while two people were finishing up with the Java portion of the project, another would be administering the Google Project Hosting site with regard to wiki pages and evaluating the issues and updates page to see if it met the class standards. This kind of work ethnic employed by our group ensured that we were always on top of things despite the rocky start with getting used to the whole process of project management.

In terms of what we accomplished, we were able to implement all commands described above with little issue.

From our Google Project Hosting site:

https://code.google.com/p/hale-aloha-cli-teams/

This is a command line interface that allows users to view various information about power and energy consumption in the Hale Aloha residences on the campus of the University of Hawaii at Manoa. The current commands implemented are:

current-power: Finds the current power consumption for sources in the Hale Aloha residences.

daily-energy: Finds the energy consumption for a given source on a given day.

energy-since: Finds the energy consumption for a given source since a given date.

rank-towers: Sorts the Hale Aloha towers based on energy consumption.

Overall, I am satisfied with what we have produced. It would have been interesting to see how far we could have taken this project by extending it using Java Reflection, but we wanted to make sure we had a solid product before trying something new.

WattDepot Katas

Continuing off my last blog entry about energy in Hawaii, there is an energy conservation competition going on over at the first-year dorms called the Kukui Cup. The system that facilitates this competition is the WattDepot web service which collects electricity data from meters found in these dorms. To get my feet wet with the use of the WattDepot API, I implemented some of the following katas.

All katas will accept a URL to a WattDepot server that will provide energy consumption data in the Hale Aloha residence halls at the University of Hawaii. All katas will lists all sourced defined at this URL and will also display specific information per kata.

Kata 1: SourceListing
Lists all sources defined at a given URL.
Kata 2: SourceLatency
Lists the number of seconds since data was received sorted in ascending order.
Kata 3: SourceHierarchy
Show the hierarchy of all subsources of a given source.
Kata 4: EnergyYesterday
Lists amount of energy in watt-hours consumed during the previous day for each source.
Kata 5: HighestRecordedPowerYesterday
Lists highest recorded power associated with a source during the previous day.
Kata 6: MondayAverageEnergy
Lists average energy consumed by a source during the previous two Mondays. Sorted in ascending order by watt-hours.

One obvious thing I've noticed about WattDepot is that it's very complex! Some of these katas seem trivial on paper, but trying to implement them was a different story. With the first kata, a simply copy and paste of an example program did half the work. But the other half involved learning the intricacies of the System.out.format method. Like the System.out.println method which simply prints data to standard output (the computer screen), System.out.format allows data to be printed in a nicely formatted list. With the SourceLatency kata, I found that the latency given by the WattDepot server may have already been sorted since printing each source with its computed latency shows that it is indeed in ascending order. To make sure, I've tried setting variables involved with computing latency to zero before computing the latency of the next source. Finally, SourceHierarchy proved interesting since the subsources given by each source was provided in a not so nice format. For example, given a source Ilima, the sub sources of Ilima would look something like this:

[http://someurl.com/subsource, http://someurl.com/subsource]

It wasn't perfect, but using a combination of Java's Split operator to break up the URI's and WattDepot's UriUtils class, I was able to extract the subsource from each subsource URI.

However, I wasn't able to complete the last three katas in time since each kata builds upon the last one. The EnergyYesterday kata requires the computation of the previous day which carries on to the fifth and sixth katas. Even though I was able to get the previous days time stamp in a nice format, I wasn't able to properly compute the energy consumed for each source. Looking at the last two katas, they both do something similar with respect to computing some previous day along with some data recorded at that day.

Finally, in terms of time spent on each kata, I found that more time was required to complete a kata than the previous kata. Not surprising since each new kata gets progressively more difficult. Overall, I found these katas enlightening in that it showed me how to approach a programming problem. Working with one of my peers last week getting started with these katas, I was overwhelmed with the amount of complexity he put into the second kata with respect to sorting by latency. There is always a brute force approach to solving some of these katas, but I like to stop and ask myself "Is there a better way?". Surely there exists some method in Java that can help solve these programming katas without having to produce spaghetti code.

Care for the Land: Energy in Hawaii

Having lived here all my life, I've been aware that the cost of living in Hawaii is one of the highest in the nation. There are many reasons on why energy is so expensive in Hawaii, but the main reason being our reliance on imported oil. As a result, the citizens of this state must make decisions today that will affect their livelihood for themselves and for future generations.

There are many challenges the Hawaii state government faces when having to deal with energy consumption. For example, each island in the state has its own power grid that does not allow for the transferring of energy produced from one island to another. Oahu consumes the most energy out of all the Hawaiian islands, and energy produced on other islands can be utilized on Oahu. On the mainland, one state can easily sell electricity to a neighboring state that needs it. This is facilitated by the fact that power generated on the mainland comes from a variety of natural resources such as coal and natural gas, thus decreasing the need for imported foreign oil.

To address these challenges, Hawaii's geographical location offers a huge renewable energy potential. The abundance of natural resources such as geothermal, water, and wind, allows us to exploit these resources quickly and effectively. Our small size is an advantage in that our energy consumption is relatively modest, so this would work well with renewable energy.

The Hawaii state government has made some progress to address these challenges with the Hawaii Clean Energy Initiative, where the state will try to achieve 70% clean energy by 2030. But to meet these requirements, we need to find ways to reduce our energy consumption today, and with tomorrow's technology we can expect to consume less energy than we do today. With that said, HNEI offers various devices to be installed into peoples homes that will measure energy consumption that allows for two-way communication to a database off-site. This data is then made available to a website that allows residential customers to see their energy consumption which can educate them on how to adjust their needs with respect to power usage. For example, a device called a smart thermostat, interacts with an A/C unit that shuts it off periodically to conserve energy when the temperature sample is at a comfortable level. In effect, if enough of these devices are being used then the energy savings would be huge to the customers and the amount of energy demand on the electric companies would go down. Another huge potential with this type of technology is the ability to use this data to model energy usage and if there is time during the day where there is excess energy produced as a result of lower energy demand, this type of information can be communicated to customers that would allow them to utilize this free excess energy to fulfill their needs.

Here on the University of Hawaii at Manoa campus, Kuykendall Hall is going through a building renovation to facilitate the measurement of energy usage and environmental factors such as temperature, humidity, air flow, and radiant heat. This information is used to to help engineers design buildings that are environmentally neutral where power consumption is lower as a result of smart building design that allows for better lighting and cooling. With the installation of these metering devices, there is an opportunity for software developers with an interest in clean energy to design software that can process the data collected to help people make better decisions with respect to building design.

Going forward, we can lower our consumption of energy with the help of HNEI. If demand response devices are installed into everyones homes, then that will certainly help us achieve that goal of 70% clean energy. All of this is facilitated by the development of good software to help manage data these devices measure that will allow people to make better decisions when dealing with energy consumption.