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

Study Time!

Some questions to help study for this week's midterm:

1. Name one reason why using Unix based OS is better than using Windows in software development.

There's many reasons why a unix based OS is better than Windows in software development. One of them is that you don't get the usual problems that Windows users get such as getting infected by a malware and/or spyware. Stability could also be a reason.

2. Provide an example on how to properly ask a question in an online community forum.

Subject: NullPointerException when running a robot in Robocode

Body: Hello, I'm using Eclipse 3.5 on my Intel Macbook Pro running Snow Leopard. The error shows up when I try to run the robot Movement04. It throws the NullPointerException error before the robocode application gets a chance to open up.

*code here*

3. Why is it better to focus on doing one thing instead of multitasking?

The quality of work decreases if not focused on one thing.

4. Name one advantage of using automated quality assurance.

It saves precious time and money.

5. Provide an example of a JUnit Antipattern and explain it briefly.

Happy Path test validates the expected behavior of the system.

6. What automated quality assurance tool checks for proper coding standard?

Checkstyle

7. Provide an example of an acceptance test design.

Test to see if my own robot can beat a sample robot.

8. Why would a developer implement version control on their programs?

By implementing version control, we can see what types of changes were made in the system. For example lets say we have a system that's currently in version 1.1. If we compare it to say version 1.1.1, we can tell that its just a minor bug fix if the developers were following the version standards. If it was 1.2, then we know that something new or a major revision was done.

9. Name one advantage of distributed version control over centralized version control.

Everybody has their own copy of the project. If the project gets lost or corrupted in a centralized server, unless someone kept a backup, the whole thing is gone.

10. What does ANT stand for?

Another Neat Tool

Project Management with Google

In this homework assignment, I learned how to use a centralized configuration manager by using SmartSVN and project hosting with Google Code. The tasks for this assignment were pretty easy if done correctly. The first thing I did was install SmartSVN on my machine. This is the program that does all the subversion work for us. It didn't take long before I got the hang of using SmartSVN on my machine. I used the "robocode-pmj-dacruzer" project to test SmartSVN.

After getting SmartSVN up and running on my machine, I then went ahead and created a new project in Google Project Hosting called "robocode-djl-dabeast." With the help of SmartSVN, I got my robocode system hosted in no time. I went ahead and tried to download the project anonymously in SmartSVN and ran ant -f verify.build.xml. The build was successful which means that everything is set up correctly.

I was able to accomplish all task except for one. An issue with Google that wouldn't allow us to add codesite-noreply@google.com as a member in our discussion list. The main purpose of this was to send out notifications whenever someone commits to the project. I filed the issue here and tried their fix but I'm still not able to generate an email after committing. I think this is the most difficult part of the assignment for me.

There is one important lesson I learned from this and that is to not "Update" my local directory when the repository is empty. I made this mistake in SmartSVN. I didn't commit the local project to the repository before I did the update and it resulted in an empty local directory.

Here are the links to my project and discussion pages:

robocode-djl-dabeast

robocode-djl-dabeast-discuss

Leave a message with your email if you want to contribute to this project :)

-David Joel Lazaro

Robocode: JUnit Testing

This homework assignment was about gaining experience writing our own JUnit test codes. I think the hardest and most frustrating part of this homework for me was getting our distribution directory to import and play nice with Eclipse. I spent the whole class time trying to setup my environment inside Eclipse. Once I got everything up and running the way I wanted, it was time to brainstorm on what I should test in my robocode.

My JUnit test cases consisted of two acceptance test and four behavioral test. For my acceptance tests, I tested whether DaBeast can win half the time against the sample robots Corners and Crazy. One of my behavioral test check whether DaBeast actually goes into one of the corners of the battlefield mainly the bottom left corner. The other test checked whether DaBeast travelled near the left wall by checking if it went to the bottom left corner and top left corner. Another behavioral test was to see if DaBeast rams its opponents. Lastly, I made a test to make sure that DaBeast's firing power is within range of what I set it to be.

The easiest test to create were obviously the acceptance test. All we needed to do was assert if we won the battles half the time. The behavioral tests were the difficult ones to create for me. I think it's because I wasn't familiar with the syntax of the snapshot interfaces that were built in robocode.

I'm not really 100% sure about the quality of my test cases. Two of the tests had bugs that I can't quite figure out how to fix. My bullet power test for example takes all the bullets in the battlefield at the end of each turn. This means that it also uses the bullets of the enemy robot for testing purposes. My robot only fires either to the power of two or three. For some reason, even if I was going against SittingDuck, I would see a bullet fired with the power of 1 which doesn't make sense to me. Another test that's flawed is when I check to see if DaBeast travels next to the left wall. It only checks whether DaBeast goes to the bottom and top left corners. DaBeast moves from the bottom left corner and goes straight up to the top left corner near the left wall. If anybody can help me fix that test then I'd really appreciate it.

When I ran Emma, it revealed that all of the methods of my test cases were executed. From my experience, it seems like having your code broken down into smaller pieces and testing each of those is the easiest way to test my robot. Click here to download the distribution of my system and see if you guys can implement my test cases in a much better way :).

-David Joel Lazaro

Ant: Project Building Made Easy

Ant is one of the best java programming tool I've used to date. Before Ant, it was just about writing the code, manually checking it for errors, then be done with it. Ant gives us the ability to create better software and automated quality assurance tools. This homework assignment allowed us to experience working with Ant by using robocode-pmj-dacruzer system as a template for our robots.

Getting Ant to run on my machine didn't go so well. After downloading the latest version of Ant and setting up the paths for it, I still couldn't get it to run. After some time, I came across a page that says Ant is installed with XCode tools for mac. I had XCode installed on my machine so I went ahead and check if there is a version of Ant installed by removing the new one that I just downloaded. After invoking the command ant -version, I was presented with a 1.7.0 version of Ant. I then removed that version and tried to install the newest build and the error disappeared. I then ran the ant invocations for the robocode-pmj-dacruzer system and passed all of it.

The second task of the homework was to use robocode-pmj-dacruzer as a template to implement on our own robocode project. I found that the best way to understand how Ant works is by tracing the xml files. It gave me an idea of how the build system worked. After modifying the build files, I was able to invoke ant and have a successful build.

The third task involves automated quality assurance on our project. The tools that we used for this project are Checkstyle, PMD, and FindBugs. As you all know, Checkstyle helps us developers to write codes that adhere to coding standards. In the past, I would do this manually by going through each line of the code. This quality assurance is automated by Checkstyle. After invoking ant -f checkstyle.build.xml for the first time, it flagged my code with two errors. The first error involves my use of "@date" which is not a valid Javadoc tag name. I simply removed that tag and replaced it with an @version tag instead. The other error was due to the lack of package-info.java file. I made a simple html file with the appropriate information. I rant the checkstyle build again and it flagged five more errors in my code. The first error was because I missed a period in my sentence. The other error was a missing Javadoc comment. The rest of the errors was due to missing @param tags for my methods. Checkstyle passed with no errors after my last fix. PMD reported no errors in my code which is good news. FindBugs however found one error. The error was URF_UNREAD_FIELD: Unread field. I had a variable that wasn't being used. This is a performance type of warning. All is good after removing that variable.

I may become very dependent with these quality assurance tools. They would make my future software development much more easier to debug. Also, utilizing these tools greatly cuts down the debugging time so we can focus more on making our software better.

Click here for my robocode-djl-DaBeast system.

-David Joel Lazaro