WattWaiter: One review coming up

After completing my web app GreenSmart described in my previous post I looked at other groups' systems and did a review of the WattWaiter system. I used some guidelines for this review and the entire review can be found at the link at the bottom of this post.

Some of the things I noticed about this system was how nice the web page looked and the robustness of the system itself. The page looks professional and I liked the use of colored flags as an indicator of the level of carbon intesity. They created their own logo and incorporated a nice style into their page so it did not look bland. Also, no matter what bad data I input into their system I could not break it and the bad data was handled correctly.

Some things about the system that could be improved would be the layout of the results and the descriptiveness of what the results mean. It would be easier to read if all the data was in one column instead of two for easy viewing and be able to fit in a single frame. There is also the problem of understandability because the only results given is a number of the hour and a colored flag. Another reason to include more information about what the flags mean would be the fact that some people are colorblind and would have absolutely no idea what the flags are there for.

Overall I was very impressed with the WattWaiter system and I look forward to seeing the kinds of improvements they will be able to make in the next version.

Read my entire review: WattWaiter Review

GreenSmart

After creating the WattDepot command-line interface, I have begun a web application modeled after ecotricity. The desired outcome would be a system that shows for every hour of a chosen day, the carbon content and the carbon intensity of the Oahu Grid.

I was on the GreenSmart team which consisted of myself, Scott Wong, John Mack, and Anthony Xu. I had no problems working with my team and we each contributed to the project.

Getting the data and creating the methods to calculate the results was the easy part. We had already worked on similar methods in the WattDepot-CLI. Although it we had already had some practice with the WattDepot-CLI it was not without effort.

The software ICU, which was discussed in previous posts, was also used again and is shown at the top of this post. We had some initial problems setting up the software ICU, we forgot to modify one portion of one of the xml files, so we missed some data for the first couple of days. From this image you can see that some parts of the project did not go as smoothly as planned. We did not write as much tests as we should have, although we may have not set up the sensors correctly because I wrote tests for all of the methods I wrote for the carbon content calculations but it only reported 1 unit test.

The hardest part of the project was integration. We each worked on separate parts of the system; the design of the page, getting the user's input, calculating the output, and displaying the output. In theory all of our parts seemed correct but when we tried to incorporate the parts together we had some difficulties. For me, the hardest part was understanding wicket. I started read "Wicket in Action" and looked at some articles online about wicket but I am definitely still in the learning phase.



GreenSmart: homepage
GreenSmart: download

The second round: WattDepot CLI 2.0

WattDepot CLI 2.0
WattDepot cli v2.0 has an updated WattDepot library and supports the new version 2.0 command line interface, which includes three new commands and makes small changes to the previous commands ("list sources" is now just "sources", etc.).

Eono 2.0
This second version allowed us to improve our old code by changing the organization of the system to include an interface. We also simplified old methods and added tests to the majority of the system. To my knowledge I think we satisfied all the requirements and took care of almost all of the issues raised by the reviewers. A lot of time was put into this project as well as careful attention to detail. There is a suite of high quality tests included in which the coverage can be seen in the Emma coverage report(class 100%, method 99%, block 84%, line 82%).

Eono Group

Scott Wong and I were on the Eono team and we met when we were free. This ended up resulting in meetings a couple of times a week (3-5) for 3-6 hours in duration. We split up the work pretty evenly and for most tasks, such as the 10 original commands that were implemented, we just divided the work in half and were responsible for our share. Although we divided up the work, we regularly helped each other out when someone was having problems and volunteered to do certain tasks willingly. I think we both carried our own weight and put a lot of effort into this project.

Software ICU
The software ICU is used to monitor "vital" signs to ensure a "healthy" project. This includes work being done consistently, equally, commited consistantly, of high quality, etc. I forgot to attach some of the sensors which is why the Test jumps from 1 to 40 (I also forgot to commit some of the tests until the end). From the software ICU it seems as if the project is more healthy than unhealthy but there are some values in the red.

Questions

What day and time during the month was Oahu energy usage at its highest? How many MW was this?
2009-11-02T19:00:00.000-10:00 : 9.835E8
(found by looping through all dates from 11/01-11/15 1 hr at a time at 30 min intervals, used holders to keep the largest value)

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
2009-11-02T04:00:00.000-10:00 : 4.97E8
(found by looping through all dates from 11/01-11/15 1 hr at a time at 30 min intervals, used holders to keep the lowest value)

What day during the month did Oahu consume the most energy? How many MWh was this?
highest: 2009-11-02 (monday) : 14764.0 MWh
(calculated the energyGenerated by the Oahu_Grid each day and found the day with the greatest energy)

What day during the month did Oahu consume the least energy? How many MWh was this?
lowest: 2009-11-07 (saturday) : 14089.0 MWh
(calculated the energyGenerated by the Oahu_Grid each day and found the day with the lowest energy)

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
highest: 2009-11-04 (wednesday) : 2.9959472E7 lbs
(calculated the carbonGenerated by the Oahu_Grid each day and found the day with the highest carbon emitted)

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
lowest: 2009-11-07 (saturday) : 2.2908808E7 lbs
(calculated the carbonGenerated by the Oahu_Grid each day and found the day with the lowest carbon emitted)


Download: WattDepot-Cli-eono-2.0.1116

Review x 2

Reviewing other systems
After reviewing eiwa and elima's systems I got to see a different perspective on the project. I realized how different projects can turn out even when given the same requirements. From eiwa's system I saw how they broke down each piece of information from the user's input instead of having the user type in one long string with all of the information. I was also unsure of exactly how to structure the system and incorporate an interface. I got general ideas of how other teams organized their project through the reviews.

Getting my system reviewed
Not only did I get to see the different perspectives on how other people implemented their systems, but I also got different perspectives on how to improve my system. When you program you have one state of mind which makes it hard to spot problems in your code. There where a lot of small things that I did not think about that I would not have caught if not for the review such as a timestamp referring to a future date. Overall I had a good experience with the reviews.

WattDepot CLI review: 8 eyes are better than 4

After completing the initial stage of the WattDepot Cli, which I talked about in my previous post, my peers in my software engineering class are having a code review. 4 other people in the class are reviewing the eono branch which Scott and I worked on, and I am reviewing two other groups projects, elima and eiwa.

Elima
John Mack and Anthony Xu were in the elima group. One of the major problems I found in the project was that some of the methods were not finished such as "list summary {source}" or the WattDepotCliProcessor didn't have a condition that checked for it and thus didn't recognize it as a command such as "list power [generated|consumed] {source} timestamp {timestamp}". I think if they had a little more time (which we are going to get for version 2.0) the project would be more complete. There was also little testing, but then again I think the focus was more on finishing the commands that they didn't get to work on testing. The commands that did work, worked well and they did a good job of catching exceptions in their methods.

Eiwa
Nathaniel Ashe and David Mau were in the Eiwa group. The main problem I encountered in the project was that the way the user enters information at the command line was different than all of the other projects I've seen, including Scott and my project. Instead of having all the information on one line such as "list power generated SIM_WAIAU_8 timestamp 2009-11-15T12:13:00.000-10:00" the user would enter a "list power generated" and the program would prompt the user for the rest of the necessary information, such as source and timestamp. Although at first it seemed like it would help the user so that they could easily enter the information that was needed, it actually slowed the process down. It is a lot faster to just type in one line versus waiting for a prompt for each individual piece of information. This also slowed down testing. Some of the prompts also were not clear at times as to what it wanted.
Besides this difficulty the project had a lot of testing and checks for errors such as a bad timestamp. There were jUnit tests for a lot of the methods.

These reviews were based on a checklist and I have included the detailed reviews:
Elima
Eiwa

Wattdepot-cli: eono

For the past week I have been working on a WattDepot CLI which "provides a simple command line interface for obtaining information from a WattDepot service". WattDepot collects electricity data from meters and stores it in its database.

I worked on this project with Scott Wong and I think we worked well as a team. There were 10 commands that we had to incorporate into the CLI so we split them up evenly. However, even though we had different tasks we still collaborated on our works and helped each other out.

This project gave me a lot of practice programming and has gotten me back into my programming mode. Many hours were put into this project, sometimes more than 6 hours straight. There were some set backs in the end when I had problems importing the project from subversion into my eclipse workspace. It would not recognize some methods for the WattDepotClient and reported errors. However if I copied just the source files into an older project it would run fine. I had to result in sending my changes to my partner to commit it to subversion and I am still working on how to fix this problem. Because of this experience I have a greater appreciation for continuous integration and version control.

Overall I think we finished the task of creating the commands for the CLI. I don't think we will ever really be "finished" with the project in the sense that there is always something more you can do to improve. I do however wish we could have tested the system more, but we ran out of time.

Download: WattDepotCli-eono

Continuous Integration

Did you ever have that problem where you're working on a project and you find a bug, but after you fix it you see something else you can add to it and then you go back and modify something else. By the time you integrate with your teammate you both have totally different works and integration seems to take longer than the actual production. This is were continuous integration comes in.

Continuous Integration

• Definition: It is a software development practice where members of a team integrate their work frequently.
• Verification: Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
• Results: Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

(source)

I used Hudson to provide the continuous integration system. I have used Hudson before so I did not have much problems setting it up or using it. It is very simple to use and is a useful tool to have. I did had a build fail when I thought everything should have been fine. However with closer inspection I found that I ran ant verify on the wrong project folder. In Hudson you can see the console output and there I was able to see where in the build it failed. However, you should run verify before committing because you have more information about what is wrong (through the findbugs, pmd, checkstyle results). I think having a continuous integration system is very useful and a little time spent using it saves you a lot of time at the end.