Break from our own code...

Now that our project has been presented, it is time to look at another team's project. WattWaiter is the project that I will be reviewing this time around. Using the UserGuide provided by the team, I installed and started my review based on these guidelines. You can read my full review here.

After testing out their application, I didn't find a way to break their system. I tested different dates and inputed false information and always received the right output. A few things that I like about their web application is that it is clean cut and colorful. On the other hand, I find myself scrolling up and down a lot to view the data. Maybe make the flags smaller, make the data show horizontally versus vertically and also add the meaning of the colors. Also, I would suggest putting the logo and the date input box on the same row. There is so much space horizontally and it would save the scrolling for the user. Overall, the WattWaiter team did a good job.

Going rogue... i mean Green

During the last week, my group (Edward Meyer, Bao Huy Ung, and Alex Kan) and I, we have been working on this web application based on our previous project WattDepotCli 2.0. By using the instructions on the following page, I believe we met the requirements for the project.

Team Work
We communicated mainly by email, however our communication was not as effective as I would have hoped. Hopefully, we can communicate more effectively and resolve issues before the last minute.

Statistics
I had trouble trying to retrieve data from hackystat.

And here is the statistics from the Emma Coverage for our final build.

[concat] Emma Coverage summary
[concat] class: 89% (8/9)
[concat] method: 84% (41/49)
[concat] block: 79% (1230/1562)
[concat] line: 67% (201/298)

Using the User Guide page on our Google Code project hosting website, you can take a look at our project.

Version two point O

My partner and I had to revise our WattDepotCLI to version 2.0. With this new version we added three new commands and we also took in consideration the adjustments to be made from reviewers previously stated in their blogs from last week.

I believe that we have fully fulfilled all the requirements requested from the command specification from the following page, with the exception of our ChartCommand that doesn't produce correct output but produces the Google page. The reviewers stated that we lacked of test cases and documentations. In this version we focused most of our time on those particular issues.

We communicated via Instant Messaging for the whole project. It was easiest for both of us as our schedule didn't always coincide. We tried our best to partition the project equally.

Below is a screenshot of Software ICU for our project for the previous 7 days.
We had pretty good coverage and we kept the system health stable throughout the duration of the project.



And here is the statistics from the Emma Coverage for our final build.

[concat] Emma Coverage summary
[concat] class: 100% (27/27)
[concat] method: 96% (74/77)
[concat] block: 86% (3538/4098)
[concat] line: 78% (668.4/860)

We completed the following questions in regards to the Oahu power grid during the month of November 2009 from the source SIM_OAHU_GRID

What day and time during the month was Oahu energy usage at its highest? How many MW was this?

November 28th at 02:45:00.00-10:00: 995MW

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

November 26th at 20:00:00.00-10:00: 496MW

What day during the month did Oahu consume the most energy? How many MWh was this?

November 26th: 995 MWh

What day during the month did Oahu consume the least energy? How many MWh was this?

November 26th: 493MWh

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?

November 4: 29,959 lbs

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
November 7: 22,908 lbs

You can download our WattDepot-CLI system here under umikumakahi-2.0.1116.zip.

How I feel about other peoples success and problems.

In the recent review we did on 2 other teams projects which were ewalu and ewia for the wattdepot-cli project we have been working on which can be downloaded here. I found that I learned a lot studying the design of others programming not just from a check out it out and find good code to stand point, but as a way to determine problems that result from implementing different techniques and benefits. As for looking at the reviews of my own teams code which is currently being updates and can be checked out from svn here. I took in some really important insight into some ways we easily overlook problems like with happy path testing. I didn't recieve one review from one of my reviewers David Mau which I believe was due to a name confusion issue between him and another classmate, but I feel I was able to understand our mistakes. Next time I around I believe the key is to perform the same level review on our own code in increments as we program rather then let issues pile up or wait for others to discover them.

Looking at someone else's code

Here's a change. After a few days looking at my own code, I was starting to dream about WattDepotCLI. This week, in my Software Engineering class, the professor has asked us to do a peer review by using his review checklist.

The following links are the reviews for the team Ewalu and Eiwa. And you can also download their WattDepot version here.

Team Ewalu

Team Eiwa

Saving money with... WattDepot

"WattDepot is a 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."

This week, we were to provide a simple command line interface for obtaining information from a WattDepot service. WattDepot gathers data that impacts the enviroment and the way the society uses energy, and also can saves us money on our electric bill.

By using the specifications, my partner and I worked on the Command Line Interface for WattDepot. We were able to accomplish most of the tasklist, except creating test cases. This project was an interesting way for me to learn a new way to do things in Java.

To view our code click here. Our group name is umikumakahi.

SVN Checkout:

svn checkout http://wattdepot-cli.googlecode.com/svn/branches/umikumakahi wattdepot-cli-read-only

Merging your work

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."
-Martin Fowler

When we started using Hudson, a popular open source continuous integration server, my teammate and I had difficulty with the connection. However, when we were able to connect, we weren't able to sync our project with the Hudson server through the use of SVN. The current setup is that whenever a member commits a new code, Hudson will verify the coding, and if it fails the build, it will send emails to the whole discussion group.



I believe that if we didn't have the connection issues, this tool would of help us tremendously by saving us time with integration.