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.

Answers please

1. A foreach or a for/in loop is a new loop that was added in Java 5.0 that executes its body once for each element in an array or collection.
for(declaration : expression)
statement

int[] foo = {1, 2, 3, 4, 5};
for (int i : foo) {
 System.out.println(i);
{

Source: Java in a Nutshell pg 50

2. More stress
Less efficiency
More frustration
More pressure, etc.

Source: http://www.nytimes.com/2008/10/25/business/yourmoney/25shortcuts.html?pagewanted=2

3. If companies use the open source software as their base, their "value added" programs might be considered "derivative works" and would then need to make the source code available even to competitors.

Source: http://www.abanet.org/intelprop/opensource.html

4. High coverage rates means that a lot of code was exercised. It doesn't mean that the code was exercised well.

Source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html

5.
1)Estimating the time to modify existing code.
developers: To check code quality before attempting to modify it
managers: To get a better estimate of time a developer needs to do the work on that code.
2) Evaluating code quality
Shows where code lacks testing
3) Accessing functional testing
Use results to help facilitate risk mitigation

source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html

6. GNU = GNU's Not Unix
If the GPL software is modified, it must be distributed under GPL. The GPL spreads to any modified GPL software.

7. Source available software has the source available to be viewed but it cannot be modified or redistributed like open source software.

Source: http://en.wikipedia.org/wiki/Open_source_software

8. Identity-based: Two references are equal only if they refer to the same object.
State-based: Two objects are equal only if they contain the same value.

9. List

10.

<target name="init">
 <mkdir dir="build/classes" />
</target>

Source: "Ant in Action: Java Development with Ant"

Buddy better study

There is a midterm coming up in my software engineering class so I am posting up some review questions. See how many you can answer without using google.

1. Describe what a foreach loop does and give an example of a foreach loop.

2. List 3 consequences of multitasking.

3. Describe the concern companies have with using open source software in regards to derivative works and intellectual property rights.

4. How are coverage reports often misused?

5. What are the 3 best practices for using coverage reports according to "In pursuit of code quality: Don't be fooled by the coverage report"?

6. What does the acronym GNU stand for and what does it mean when it is said that the GNU General Public License is viral?

7. What is the difference between open source and source-available?

8. Describe the two approaches to defining equality and hash value according to "Java Theory and Practice: Hashing it out".

9. Which collection is most appropriate for a list of strings in alphabetical order with duplicates.

10. Write an ant target called "init" that creates an output directory for generated files called "build/classes".

Answers:
1. A foreach or a for/in loop is a new loop that was added in Java 5.0 that executes its body once for each element in an array or collection.
for(declaration : expression)
statement

int[] foo = {1, 2, 3, 4, 5};
for (int i : foo) {
 System.out.println(i);
{

Source: Java in a Nutshell pg 50

2. More stress
Less efficiency
More frustration
More pressure, etc.

Source: http://www.nytimes.com/2008/10/25/business/yourmoney/25shortcuts.html?pagewanted=2

3. If companies use the open source software as their base, their "value added" programs might be considered "derivative works" and would then need to make the source code available even to competitors.

Source: http://www.abanet.org/intelprop/opensource.html

4. High coverage rates means that a lot of code was exercised. It doesn't mean that the code was exercised well.

Source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html

5.
1)Estimating the time to modify existing code.
developers: To check code quality before attempting to modify it
managers: To get a better estimate of time a developer needs to do the work on that code.
2) Evaluating code quality
Shows where code lacks testing
3) Accessing functional testing
Use results to help facilitate risk mitigation

source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html

6. GNU = GNU's Not Unix
If the GPL software is modified, it must be distributed under GPL. The GPL spreads to any modified GPL software.

7. Source available software has the source available to be viewed but it cannot be modified or redistributed like open source software.

Source: http://en.wikipedia.org/wiki/Open_source_software

8. Identity-based: Two references are equal only if they refer to the same object.
State-based: Two objects are equal only if they contain the same value.

9. List

10.

<target name="init">
 <mkdir dir="build/classes" />
</target>

Source: "Ant in Action: Java Development with Ant"

A good host offers you food from their own fridge: Robocode Hosting

Robocode Google Project Hosting: robocode-kks-counterall
Discussion Group: robocode-kks-counterall-discuss

As I continue working on my Robocode project from my previous posts I have encountered a problem. Peers are one of your best sources for help and improvement on a project. However, reviewing someone elses code that is constantly being changed can be a hassle. I have had times when I download a project from my peer's blog I am unable to run it and have to wait for them to fix whatever they need to fix and upload the file back to their blog.

The use of google project hosting and svn helped alleviate that problem. If I want to take a look at someone elses project and make some changes that I think will improve the robot I can checkout the project, make the changes, and commit those changes.

I used TortoiseSVN which was a little confusing at first because there is no main application that starts up, and instead runs from Windows explorer. I also had some problems with adding codesite-noreply@google.com as a discussion list member in my robocode-kks-counterall-discuss group. I still am unsure about how it works.

Robocode: Test, test, test

Download: CounterAll + jUnit tests
Improving on my previous robot CounterAll from my previous posts I added 6 new jUnit tests. There are 3 different types of tests: acceptance tests, behavioral tests, and unit tests.

The acceptance tests were the easiest to create because all they tested was whether or not my robot beat another robot. On the other hand, I think behavioral tests were the hardest because most of the time they required the use of other methods and classes from within robocode such as the BattlefieldSpecification class. I also had to refactor my code for my unit test which calculates the power the robot shoots at.
Although it was a pain to change my code in order to better test it, I think it improved my code and helped it follow the rule of having small simple methods.

Although I did create these tests it doesn't mean that my robot is completely of good quality. I did try to write tests that ensured the robot accomplished the behaviors it was intended to do. However, that doesn't mean it will beat every robot. Also if I did not provide varying and a thorough amount of parameters to test for, the test itself wouldn't ensure accuracy.
I also ran Emma to view a coverage report of my tests. I was surprised to see how low the coverage was for the class percentage, only 67%. The method, line, and block coverage were more reassuring with above 80%.