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.

Software Engineering So Far: A Midterm study guide

Halfway into the semester and we've covered a sizable amount of content with respect to Software Engineering. It's interesting to see how early on we learned about coding standards and how it has come full circle when it comes to dealing with build systems and configuration management. Without some kind of standard going on, all there ever will be is confusion and frustration. Below are five sample midterm questions I believe are important when it comes to what we've learned so far in the semester. None of the questions are cherry picked as I believe all the material is important in one way or another.

The following are five questions and answers about the topics I've learned up until this point.

1) What is Ant?

Ant is a scripting tool that lets you construct your build scripts in much the same way as the "make" tool in C or C++.


2) Ant properties are immutable. Explain what this means and give an example.

Once Ant properties are set they cannot be changed within the build process. For example,


MyProperty = ${MyProperty}

MyProperty = ${MyProperty}

Will print the following:

[echo] MyProperty = One
[echo] MyProperty = One


3) When deploying new software configuration management tools it's always good practice to use common build tools. Why?

Much time is wasted when a developer cannot reproduce a problem found in testing, or when the released product varies from what is tested. Ensuring that everyone working a project is using the same tools will make tracking down a problem easier.


4) List and explain what a software review exposes that testing does not.

Various answers include:

Reviews are pro-active tests. Find errors not possible through testing such as an unimplemented requirement.

5) ICS-SE-Java-2 says not use the wildcard "*" in import statements. Why?

You must explicitly import each class that you use from other packages. This is an important form of documentation to readers of your class. It doesn't really make sense for a program to throw in the kitchen sink when solving a problem.

Configuration Management and Google Project Hosting

For a couple months now, I've been using my Dropbox account to keep track of my work. When I'm at home I use my Windows machine since I prefer to program on a 24' screen. And when I'm away I have to use my 13' Macbook. I simply do not like emailing myself source code because of the potential overhead it creates on my email account. Early on I also found how it wasn't a very good idea to set my Eclipse IDE workspace as a folder that would sync with Dropbox since it would have been a hassle if I really screwed something up. So this whole idea of Configuration Management coupled with Google Project Hosting is an alternative to my current system of simply copying and pasting code as I transfer work from one machine to another and more.

As a task, I've set up my robocode-gja-shootnscoot system at Google Project Hosting. Although it took quite a bit of time to accomplish all tasks, I feel that it was a good learning experience. In terms of difficulty, I actually found that writing the wiki pages will take the most time and effort since I can definitely see people getting confused on how to run a foreign system when all they know is how to click the "Run" button on their favorite IDE. One thing in particular I've noticed when working with my peers on concurrent revision commits is that there is a potential of a bottleneck happening when too many people are trying to commit their changes to the system. But the occurrence of this type of thing happening constantly seems minimal when the amount of people working on a project is smaller.

Overall, I feel that configuration management is a powerful tool that allows people to collaborate more effectively as opposed to just relying on some kind of mailing list. It allows the group to keep track of progress on a given project and makes available the system for everyone to improve.

The ShootNScoot system hosted on Google Project Hosting: https://code.google.com/p/robocode-gja-shootnscoot/

ShootNScoot: A Competitive Robot

As the name implies, the ShootNScoot robot is roughly modeled on the standard military tactic of Shoot-and-scoot. Although not as elegant as the actual tactic described in the link, ShootNScoot displays the basic strategy of firing at a target and then immediately moving away from the location where the shots were fired.

The basic design of the robot is as follows:

Movement: Using a random number generator, a firing position is generated in the form X, Y where the robot will move to at the beginning of each turn. This deviates a bit from the Shoot-and-scoot tactic by initially moving then firing, however, by the start of the second turn the robot should exhibit normal Shoot-and-scoot behavior by 1) Firing at an enemy and 2) Moving from the previous firing position to a new firing position in an attempt to evade enemy fire.

Targeting: This robot employs a sort of hit-and-run tactic by attacking various targets instead of focusing on just one robot. This is in the spirit of Guerrilla warfare which goes along with the Shoot-and-scoot strategy.

Firing: Sticking with the Shoot-and-scoot philosophy, this robot will not shoot unless it is fully stopped. Also, depending on distance to target, bullet power is varied to increase the chance of a successful hit. Ideally, the robot should be able to fire while moving given an enemy with low energy.

Pitting ShootNScoot against eight sample robots show weaknesses in my Shoot-and-scoot implementation. The following are one vs. one battles over five rounds with the score percentage in parentheses.

ShootNScoot(10%) vs. Walls(90%)
ShootNScoot(42%) vs. RamFire(58%)
ShootNScoot(26%) vs. SpinBot(72%)
ShootNScoot(81%) vs. Crazy(19%)
ShootNScoot(78%) vs. Fire(22%)
ShootNScoot(46%) vs. Corners(54%)
ShootNScoot(31%) vs. Tracker(69%)

There were a couple of close ones, but Walls by far will always dominate ShootNScoot. Given that Walls is always on the move, the only reliable way to win against Walls would be to fire ahead of the robot to score a successful hit. Another robot with a high win percentage is SpinBot which also employs a similar tactic to Walls by constantly moving in circles while firing at the same time. This allows SpinBot to not only evade random fire from ShootNScoot but to successfully return fire. In most situations, the design of ShootNScoot didn't work because too much time is spent moving around and not shooting back. Although the idea of moving to a randomly generated position seems sound, getting hit while moving to that position doesn't help the robot at all. To improve the design of my robot, I would have improve it's firing system by allowing for ShootNScoot to fire while moving to a new position. Also, to somehow predict enemy tactics by storing enemy information and adjusting robot tactics on the fly.

In terms of testing, two acceptance tests were created that verified that ShootNScoot can reliably beat the SittingDuck and Fire robots. The choice of SittingDuck was a no-brainer since this served as a basis for additional testing and to simply show that ShootNScoot does not spontaneously combust upon the start of battle. Out of all the other sample robots, ShootNScoot showed it was able to win against Fire going 10+ rounds. Finally, various behavioral tests were created to verify that the following components of ShootNScoot are working as intended:

1) Generation of random position.
2) Movement to randomly generated coordinate.
3) Variable firing system.
4) Target acquisition.

With regard to software engineering, this project has taken the Three Prime Directives head on and exposed me to what it takes to ensure that these directives are met. I feel that if I had written the test cases before the actual robot implementation, the ShootNScoot would have come out a little better. The reality is that the test cases were developed as a response to the robot implementation and my testing reflects that. Automated quality assurance tools like PMD and FindBugs picked up on little things in my source code that I would have otherwise missed. For next time, I would have definitely focused more on testing before implementing the robot. This way, testing would have exposed poor design choices against other robots and would allow me to adjust my design specifications to create a more powerful robot.

Ant Code Katas

Building upon my last blog entry on the application of Katas on improving my programming, I applied this concept to the Apache Ant build system for Java. Although not my first time messing around with a build system, this is by far the most complex I've encountered. Similar to the Make utility found on most Unix-based operating systems, the Apache Ant build system automatically builds executable programs from source code and libraries.

For this particular build system, I worked on the following katas:

1. Ant Hello World
2. Ant Immutable Properties
3. Ant Dependencies
4. Hello Ant Compilation
5. Hello Ant Execution
6. Hello Ant Documentation
7. Cleaning Hello Ant
8. Packaging Hello Ant

Sparing the details for each kata (you can read about them here), each kata gets more difficult along the way. Funny enough, learning how to print words to the screen in Ant took a bit longer than expected. Unlike a programming language, it seems like the first thing the authors of a build system would like you to do is to actually use their program to build a system. I knew I had to enclose the "echo" task around what I wanted to print to the screen but to actually set up the script to do this took longer than expected. A quick Google searched revealed resources on how to do exactly this.

Next, completing the immutability and dependency scripts were pretty painless since the Wikibooks website also provided a good tutorial on those two concepts, however, I would soon hit a brick wall with the next three scripts. Out of the three, compilation wasn't too bad since the Ant manual provides a good basis on how to do this. On the execution script I would later find out the pain in trying to run a Java program using Ant. During this time I've probably went back-and-forth a few times deciding whether to follow the Apache model and JAR my HelloWorld program and execute the the JAR, or to simply find a way to execute the program without having to do this step. Finally, I found the documentation script to be a little simpler since I only had to be concerned with the location of the source files and the directory where I want to store the Javadoc reference files. Luckily, I had no problems with the clean and distribution scripts since I found the sample scripts from another build system distribution straightforward.

With these code katas I was able to dive a little deeper with just how complex build systems can get pass the compilation and execution stages. With the headaches I've encountered when trying to run other peoples Java implementations on my computer, it is clear how useful and in my case necessary to have a robust build system to accompany any software system.