GreenDepot Review

In summary, GreenDepot is on the right direction and just needs to fix some major bugs to get their application running smoothly. Right now the application is dependent of Ant. I would check the jar.build.xml to see if it's compiling the needed components for the system to run. I also suggest that a separate session class be created for getting and setting user input. Software ICU and Continuous Integration data shows that the group was working on it consistently. To view my full review, click on the link below.

GreenDepotReview

-David Joel Lazaro

Ecologineers Wicket Application

After working on WattDepot, it's time to put it in practical use by building a web application that can take advantage of it. We had to build a wicket application that shows the carbon intensity of a certain day. Our group name is Ecologineers. My partners for this project were Paul Galiza, Shaun Ramento, and Jarret Mizo.

Overall I believe that the project went well. Everybody did what they can to contribute to the project. We helped each other out when one needed help. The only thing I observed that got in our way of working on this project was our other class works. Me and Paul have midterms and C++ homework to work on. Meanwhile, Jarret and I also had some lab report to do for our networking course. I think we got most of the job done because we were always able to meet and work on the project as a group.



As for the current state of our application, our group was able to implement most of the requirements. We just couldn't tackle a couple of bugs due to time limit. One of the things that doesn't work is the color coding of the table in the webpage. It shows the text Red, Green, and Yellow instead of the actual color. We only need some more input validation in our date entry forms. Our system could also use some more test cases as you can tell from our hackystat image above. There were times where the system wasn't touched at all because we had other stuff to do. But when we do work on it, we all do it together as a group.

Click here to download and try our wicket application.

-David Joel Lazaro

WattDepot Ekahi Version 2.0

This assignment enabled us to correct the mistakes we made in the first version of our WattDepot system. Armed with better knowledge after being reviewed by our peers, our group made sure that the second version of our system is way better than the first. The main fix that we had to do was refactoring our code and break it up in different classes for each commands. Doing this enabled us to clean up the system. It also made test cases easier to do because we now have each commands return something rather than being void.

After doing the refactoring, we were able to implement the commands in a much more efficient way. We took many unnecessary codes out also. I believe that we were able to fix most of the issues that the reviewers have raised. The design of the system went from having one giant class to each commands being in their own class. At the end of it, we were able to get a 62% coverage in our system. I think if we worked on it some more then we could easily bring that coverage up.

My partner (Paul Galiza) and I worked pretty well as a team. We both had other things to do outside of this class but we were still able to pull through and work as a team with no problem. We met outside of class to work on the system as much as we can. In our group, we pretty much just worked on whatever was needed to be done. I think we both did a good job of carrying our weight when it comes to working on the system.

A new concept that was introduced to us while building this version of the system is Software ICU. Software ICU is a way of tracking the "health" of our project by monitoring the vital signs of the system. To do this, we used the system called hackystat. In a nutshell, hackystat monitored almost everything that we did involving the project. The screen shot above shows the current health of our system. Although it could be improved, our group really worked hard on getting the system up and running with minimal flaws.

The following questions are something that we are able to answer after getting our system up and running:

• What day and time during the month was Oahu energy usage at its highest? How many MW was this?
  The timestamp 2009-11-02T20:00:00.000-10:00 netted a high 995MW.
  
• What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
  The timestamp 2009-11-02 netted a low 493MW.
  
• What day during the month did Oahu consume the most energy? How many MWh was this?
  No available data found for this month to answer this question.
  
• What day during the month did Oahu consume the least energy? How many MWh was this?
  No available data found for this month to answer this question.
  
• What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
  The timestamp 2009-11-05 is one of the dirtiest day which emitted 29,959 lbs or carbon.
  
• What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
  The timestamp 2009-11-07 is one of the cleanest day which emitted only 22,908 lbs of carbon.

Click here to download the Ekahi branch of the WattDepot system.

-David Joel Lazaro

Code Review Experience

Reviewing each other's WattDepot systems clearly has a positive outcome. Clearly the other groups had different ways of building the system. Its good to know that I'm able to help them out by pointing out the errors so that they can improve their system. Reviewing the other systems also helps me because I can see how to improve our system also. I saw some better ways of implementing some methods that would make the system much more efficient.

The best way of responding to a code review is by taking it in positively. The reviewers of our system pointed out many things that we can improve on. They've spotted errors that we didn't catch ourselves. They have suggested many things to improve our system. The next part now is to try and implement those suggestions and fix the errors that they found.

-David Joel Lazaro

Code Review: WattDepot Eono Branch

This is my software review of the WattDepot System Elima branch by Scott Wong and Kelli Sawai. The template I used was provided by Philip Johnson.

A. Review the build

A1. Download the system, build it, and run any automated quality assurance checks (use "ant -f verify.build.xml"). If any errors occur, note these in your review.

-Build Successful

B. Review system usage

B1. Run the system. Exercise as much of its functionality as possible. Does it implement all of the required features?

help

-Works

quit

-Works

list sources

-Works

list summary {source}

-Invoking the command does nothing but returns to the command line interface.

list sensordata {source} timestamp {timestamp}

-Works

list sensordata {source} day {day}

-Doesn’t check the data for the duration of the day.

list power [generated|consumed] {source} timestamp {timestamp}

-Works

list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}

-Works

list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}

-Invoking “>list total energy generated SIM_WAIAU_8 day 2009-11-15 sampling-interval 30” results in the following error:

Exception in thread "main" org.wattdepot.client.BadXmlException: 400: Range extends beyond sensor data, startTime 2009-11-15T00:00:00.000-10:00, endTime 2009-11-15T00:00:00.000-10:00: Request: GET http://server.wattdepot.org:8182/wattdepot/sources/SIM_WAIAU_8/energy/?startTime=2009-11-15T00:00:00.000-10:00&endTime=2009-11-15T00:00:00.000-10:00&samplingInterval=30

at org.wattdepot.client.WattDepotClient.getEnergy(WattDepotClient.java:566)

at org.wattdepot.client.WattDepotClient.getEnergyValue(WattDepotClient.java:614)

at org.wattdepot.client.WattDepotClient.getEnergyGenerated(WattDepotClient.java:637)

at org.wattdepot.cli.ListCommand.listTotalGenerated(ListCommand.java:362)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:109)

chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}

-Can’t get this command to work properly. Nothing happens when I invoke the command.

B2. Try to break the system by providing it with unexpected input. Can you make the system crash or generate a stack dump? If so, note the input that caused the failure.

>list total energy generated SIM_WAIAU_8 day 2009-11-15 sampling-interval 30

Exception in thread "main" org.wattdepot.client.BadXmlException: 400: Range extends beyond sensor data, startTime 2009-11-15T00:00:00.000-10:00, endTime 2009-11-15T00:00:00.000-10:00: Request: GET http://server.wattdepot.org:8182/wattdepot/sources/SIM_WAIAU_8/energy/?startTime=2009-11-15T00:00:00.000-10:00&endTime=2009-11-15T00:00:00.000-10:00&samplingInterval=30

at org.wattdepot.client.WattDepotClient.getEnergy(WattDepotClient.java:566)

at org.wattdepot.client.WattDepotClient.getEnergyValue(WattDepotClient.java:614)

at org.wattdepot.client.WattDepotClient.getEnergyGenerated(WattDepotClient.java:637)

at org.wattdepot.cli.ListCommand.listTotalGenerated(ListCommand.java:362)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:109)

>list sensordata SIM_OAHU_GRID timestamp break

should never happen.

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.ListCommand.listSensorDataTimestamp(ListCommand.java:320)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:65)

>list sensordata test day test

should never happen.

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.ListCommand.listSensorDataDay(ListCommand.java:92)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:77)

C. Review the JavaDocs.

C1. Does the System Summary (provided in an overview.html file) provide an high-level description of the purpose of the system? Does it explain how each of the packages in the system relate to each other? Is the first sentence self-contained?

-The system summary provides a high-level description of the purpose of the system. Doesn’t really explain how the packages in the system relate to each other because only one package exist.

C2. Do the Package Summaries (provided in package.html files) provide a high-level description of the purpose of the package? Do they explain how the classes in the package related to each other? Is the first sentence self-contained?

-Main package summary refers to an example of WattDepot interaction.

C3. Do the Class Summaries (provided at the top of each .java file) provide a high-level description of the purpose of the class? Does it provide sample code for clients of the class, if useful? Is the first sentence self-contained?

-Accurate high-level description of the purpose of the class. Doesn’t provide sample code for clients of the class.

C4. Do the Method Summaries (provided before each method) explain, from a client-perspective, what the method does? Do they avoid giving away internal implementation details that could change? Do they document any side-effects of the method invocation? (Note that you can click on the method name to see the source code for the method, which is helpful to assessing the correctness and quality of the javadoc.)

-The method summaries does a pretty good job on explaining what the method does. They were able to do it without giving away internal implementation details.

D. Review the names

D1. Do another pass through the JavaDocs, this time concentrating on the names of packages, classes, and methods. Are these names well chosen? Do they conform to the best practices in Elements of Java Style, Chapter 3? Can you propose better names?

-Naming scheme looks fine.

D2. Once you have reviewed the names displayed in the JavaDocs, review the source code for internal names in the same way.

-Source code internal names looks fine also.

E. Review the testing.

The system should provide a useful set of test cases.

-Only test present is the example test provided by the instructor.

F. Review the package design

F1. Consider the set of packages in the system. Does this reflect a logical structure for the program? Are the contents of each package related to each other, or do some package contain classes with widely divergent function? Can you think of a better package-level structure for the system?

-System only contains one package. Maybe create a separate package for commands class, test cases, etc.

G. Review the class design

G1. Examine its internal structure in terms of its instance variables and methods. Does the class accomplish a single, well-defined task? If not, suggest how it could be divided into two or more classes.

-After going through the instance variables and methods of the system, I conclude that the classes in the system could be divided into separate classes instead of one big class that does many things. This will make the code easier to read and makes creating test cases easier.

G2. Are the set of instance variables appropriate for this class? If not, suggest a better way to organize its internal state.

-Looks fine.

G3. Does the class present a useful, but minimal interface to clients? In other words, are methods made private whenever possible? If not, which methods should be made private in order to improve the quality of the class interface to its clients?

-No private methods observed in the system.

H. Review the method design

H1. Does the method accomplish a single thing? If not, suggest how to divide it into two or more methods.

-Each methods seems fine in accomplishing a single thing.

H2. Is the method simple and easy to understand? Is it overly long? Does it have an overly complicated internal structure (branching and looping)? If so, suggest how to refactor it into a more simple design.

-The methods looks fine. They are easy to follow and understand.

H3. Does the method have a large number of side-effects? (Side effects are when the result of the method's operation is not reflected purely in its return value. Methods have side-effects when they alter the external environment through changing instance variables or other system state. All "void" methods express the results of their computation purely through side-effect.) In general, systems in which most methods have few or zero side-effects are easier to test, understand, and enhance. If a method has a large number of side-effects, try to think about ways to reduce them. (Note that this may involve a major redesign of the system in some cases.)

-No side-effects observed.

I. Check for common look and feel

I1. Is the code implemented consistently throughout the system, or do different sections look like they were implemented by different people? If so, provide examples of places with inconsistencies.

-The code seems to be consistent throughout the system. It doesn’t look like two people implemented the code.

Code Review: WattDepot Elima Branch

This is my software review of the WattDepot System Elima branch by Anthony Xu and John Mack. The template I used was provided by Philip Johnson.

A. Review the build

The first part of any review is to verify that the system builds and passes automated quality assurance.

A1. Download the system, build it, and run any automated quality assurance checks (use "ant -f verify.build.xml"). If any errors occur, note these in your review.

-Build Successful

B. Review system usage

If the system builds, the next step is to play with it.

B1. Run the system. Exercise as much of its functionality as possible. Does it implement all of the required features?

help

-Works

quit

-Works

list sources

-Parent and Description is missing from the output.

list summary {source}

-Command only returns the string “list source summary”

list sensordata {source} timestamp {timestamp}

-Works

list sensordata {source} day {day}

-Output of the command is not formatted correctly. Also doesn’t check the data for the duration of the day.

list power [generated|consumed] {source} timestamp {timestamp}

-“No such command” output when I tried to invoke the command listed in the help menu.

list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}

-“No such command” output when I tried to invoke the command listed in the help menu.

list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}

-“No such command” output when I tried to invoke the command listed in the help menu.

chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}

-Can’t get this command to work properly. I get the following error:

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 9, Size: 9

at java.util.ArrayList.RangeCheck(ArrayList.java:547)

at java.util.ArrayList.get(ArrayList.java:322)

at org.wattdepot.cli.command.ChartPowerCommand.doCommand(ChartPowerCommand.java:35)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

B2. Try to break the system by providing it with unexpected input. Can you make the system crash or generate a stack dump? If so, note the input that caused the failure.

> list sensordata SIM_OAHU_GRID timestamp 2009-

Unable to create timestamp

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.command.ListSensordataTimestamp.doCommand(ListSensordataTimestamp.java:41)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

> list sensordata SIM_KAHE_1 day day

Unable to create timestamp

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.command.ListSensordataDayCommand.doCommand(ListSensordataDayCommand.java:41)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

> chart power consumed

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 3, Size: 3

at java.util.ArrayList.RangeCheck(ArrayList.java:547)

at java.util.ArrayList.get(ArrayList.java:322)

at org.wattdepot.cli.command.ChartPowerCommand.doCommand(ChartPowerCommand.java:31)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

C. Review the JavaDocs.

Download the system and generate the javadocs (use "ant -f javadoc.build.xml"). Navigate to the build/javadoc folder and click on index.html to display the JavaDocs in a browser. Read through the JavaDocs and assess the following:

C1. Does the System Summary (provided in an overview.html file) provide an high-level description of the purpose of the system? Does it explain how each of the packages in the system relate to each other? Is the first sentence self-contained?

-The system summary provides a high-level description of the purpose of the system. Doesn’t really explain how the packages in the system relate to each other.

C2. Do the Package Summaries (provided in package.html files) provide a high-level description of the purpose of the package? Do they explain how the classes in the package related to each other? Is the first sentence self-contained?

-Pretty clear high-level description of the purpose of the package.

C3. Do the Class Summaries (provided at the top of each .java file) provide a high-level description of the purpose of the class? Does it provide sample code for clients of the class, if useful? Is the first sentence self-contained?

-Accurate high-level description of the purpose of the class. Doesn’t provide sample code for clients of the class.

C4. Do the Method Summaries (provided before each method) explain, from a client-perspective, what the method does? Do they avoid giving away internal implementation details that could change? Do they document any side-effects of the method invocation? (Note that you can click on the method name to see the source code for the method, which is helpful to assessing the correctness and quality of the javadoc.)

-The method summaries does a pretty good job on explaining what the method does. They were able to do it without giving away internal implementation details.

D. Review the names

One of the most important (if not the most important) form of documentation in any software system is the choice of names for program elements, such as packages, classes, methods, instance variables, and parameters. Due to evolution in requirements and design changes, the name originally chosen for a program element may no longer be appropriate or optimal. An important goal of review is to ensure that the names of program elements are well suited to their function. Due to the refactoring capabilities in modern IDEs such as Eclipse, renaming need not be a burden.

D1. Do another pass through the JavaDocs, this time concentrating on the names of packages, classes, and methods. Are these names well chosen? Do they conform to the best practices in Elements of Java Style, Chapter 3? Can you propose better names?

-Naming scheme looks fine.

D2. Once you have reviewed the names displayed in the JavaDocs, review the source code for internal names in the same way.

-Source code internal names looks fine also.

E. Review the testing.

The system should provide a useful set of test cases.

-Only test present is the example test provided by the instructor.

F. Review the package design

The JavaDoc review is focussed on whether the system design is correctly explained. In this section, you start to look at whether the system design is itself correct.

F1. Consider the set of packages in the system. Does this reflect a logical structure for the program? Are the contents of each package related to each other, or do some package contain classes with widely divergent function? Can you think of a better package-level structure for the system?

-Package structure looks good and organized. This is how the structure of the system is supposed to be like.

G. Review the class design

Examine each class implementation with respect to at least the following issues.

G1. Examine its internal structure in terms of its instance variables and methods. Does the class accomplish a single, well-defined task? If not, suggest how it could be divided into two or more classes.

-After going through the instance variables and methods of the system, I conclude that not all the class in the system accomplished a single, well defined task. This is because one of the class that does the list source summary command is not complete.

G2. Are the set of instance variables appropriate for this class? If not, suggest a better way to organize its internal state.

-Looks fine.

G3. Does the class present a useful, but minimal interface to clients? In other words, are methods made private whenever possible? If not, which methods should be made private in order to improve the quality of the class interface to its clients?

-No private methods observed in the system.

H. Review the method design

Examine each method implementation with respect to at least the following issues.

H1. Does the method accomplish a single thing? If not, suggest how to divide it into two or more methods.

-Each methods seems fine in accomplishing a single thing.

H2. Is the method simple and easy to understand? Is it overly long? Does it have an overly complicated internal structure (branching and looping)? If so, suggest how to refactor it into a more simple design.

-The methods looks fine. They are easy to follow and understand.

H3. Does the method have a large number of side-effects? (Side effects are when the result of the method's operation is not reflected purely in its return value. Methods have side-effects when they alter the external environment through changing instance variables or other system state. All "void" methods express the results of their computation purely through side-effect.) In general, systems in which most methods have few or zero side-effects are easier to test, understand, and enhance. If a method has a large number of side-effects, try to think about ways to reduce them. (Note that this may involve a major redesign of the system in some cases.)

-No side-effects observed.

I. Check for common look and feel

I1. Is the code implemented consistently throughout the system, or do different sections look like they were implemented by different people? If so, provide examples of places with inconsistencies.

-The code seems to be consistent throughout the system. It doesn’t look like two people implemented the code.

Wattdepot: A Smart Consumer's Tool

Last week, our class was introduced to the Wattdepot project. Wattdepot is a system that lets us store and analyze our power consumption by reading the meters. It's a great tool that gives smart consumers the ability to monitor their power consumption.

My partner for this project is Paul Galiza. Paul worked on the early parts of the system. I think Paul and I did pretty well as a team. He was always available for help whenever I'm stuck on some parts of the system.

I believe that we achieved most of the goals of this system. We were able to create all of the ten commands listed in the CommandSpecification page. A lot of time and effort were put in to getting our system done. Some of us stayed at Sinclair library overnight trying to finish our project. Paul and I pretty much just picked the next parts that was needed to be finished while helping each other out.

The biggest issue we had was creating our test cases. Our system didn't implement interfaces so we had one giant class that includes all of our commands. It was difficult to create test cases for one giant class. We will most likely modify our system later on to fix this problem. We would have done the changes but we didn't have enough time before the deadline. Click here to download our ekahi wattdepot system.

-David Joel Lazaro

Implementing Continuous Integration

Continuous integration is a practice that helps developers working in groups. Basically what it does is set up a general environment that gets the source code from a repository and verifies to see if its in a working condition. It monitor's the repository continuously to check for any errors when someone commits.

We are using Hudson for implementing continuous integration. The project set up was a breeze and only took about 3-5 minutes. We set up our project in the Hudson server so that every 5 minutes, it will download the source from the repository. It will then run the hudson.build.xml file which is pretty much running the verify Ant command. When something is wrong, it emails the group to inform that an error occurred while building the project. It's very helpful because it also shows what failed and who committed the file.

Using continuous integration can be very helpful when working on a project with many committers. It tells you when the project has errors not long after you perform a commit. The only negative I see in implementing continuous integration is the time lost setting up the Hudson server. Other than that, I think that continuous integration is all positive for a developer.

-David Joel Lazaro