Sunday, November 8, 2009

code review of wattdepot-cli-umikumaha

This is the wattdepot client interface of team umikumaha (or fourteen) by Dean Kim and Aaron Herres. Below are some issues that I identified.

A. Review the build: there is no problem verify the system with ant -f verify.build.xml

B. Review system usage:
1. The list summary command does not follow the command specification as I've got this error message:

>list summary SIM_KAHE_1
Default list source/sources command
Thus, after reviewed the description from 'Help', and I have to input as below for the summary of SIM_KAHE_1:
>list source SIM_KAHE_1 summary
SubSources: No SubSources found.
Description: Kahe 1 is a HECO plant on Oahu's grid that uses LSFO as its fuel.
Owner: oscar@wattdepot.org
Coordinates: To be looked up later
Properties: (carbonIntensity : 1744), (fuelType : LSFO)
Earliest data: 2009-10-25T00:00:00.000-10:00
Latest data: 2009-11-23T23:45:00.000-10:00
Total data points: 2880
2. The system quit when I inputed the invalid structure for list source.
>list source  SIM_KAHE_1
Exception in thread "main" java.lang.ClassCastException: org.wattdepot.resource.
source.jaxb.SourceIndex cannot be cast to org.wattdepot.resource.source.jaxb.Sou
rce
        at org.wattdepot.client.WattDepotClient.getSource(WattDepotClient.java:1
019)
        at org.wattdepot.cli.ListSourceCommandCli.processSource(ListSourceComman
dCli.java:446)
        at org.wattdepot.cli.ListSourceCommandCli.processCommand(ListSourceComma
ndCli.java:487)
        at org.wattdepot.cli.ListCommandCli.processCommand(ListCommandCli.java:7
6)
        at org.wattdepot.cli.CommandLineInterface.processMainCommand(CommandLine
Interface.java:209)
        at org.wattdepot.cli.CommandLineInterface.processUserInput(CommandLineIn
terface.java:172)
        at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java
:269)
C:\wattdepot-cli-umikumaha-1.1.1104>
3. Mistype for the last token of input command also work. For example,
>list source SIM_KAHE_1 summary2
SubSources: No SubSources found.
Description: Kahe 1 is a HECO plant on Oahu's grid that uses LSFO as its fuel.
Owner: oscar@wattdepot.org
Coordinates: To be looked up later
Properties: (carbonIntensity : 1744), (fuelType : LSFO)
Earliest data: 2009-10-25T00:00:00.000-10:00
Latest data: 2009-11-23T23:45:00.000-10:00
Total data points: 2880
4. The list sensordata {source} day does not work.
>list sensordata SIM_KAHE_1 day 2009-10-30
The input string was invalid.
5. The list sensordata {source} timestamp not work.
>list sensor data SIM_KAHE_1 2009-10-26T12:12:12.000-10:00
Exception in thread "main" java.lang.NullPointerException
        at org.wattdepot.cli.CommandLineInterface.processUserInput(CommandLineIn
terface.java:173)
        at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java
:269)
6. The chart power generated {source} {startday} {endday} sampling-interval {min} file {file} does not work.
>chart power generated SIM_KAHE_1 2009-10-30 2009-11-03 sampling-interval 30 fil
e teste.html
java.io.FileNotFoundException: chart_data_Sun Nov 08 15:33:29 HST 2009.html (The
 filename, directory name, or volume label syntax is incorrect)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(Unknown Source)
        at java.io.FileOutputStream.<init>(Unknown Source)
        at java.io.FileWriter.<init>(Unknown Source)
        at org.wattdepot.cli.ChartPowerCommandCli.generateHtmlOutput(ChartPowerC
ommandCli.java:346)
        at org.wattdepot.cli.ChartPowerCommandCli.processCommand(ChartPowerComma
ndCli.java:394)
        at org.wattdepot.cli.CommandLineInterface.processMainCommand(CommandLine
Interface.java:218)
        at org.wattdepot.cli.CommandLineInterface.processUserInput(CommandLineIn
terface.java:172)
        at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java
:269)
java.io.FileNotFoundException: chart_data_Sun Nov 08 15:35:09 HST 2009.html (The
 filename, directory name, or volume label syntax is incorrect)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(Unknown Source)
        at java.io.FileOutputStream.<init>(Unknown Source)
        at java.io.FileWriter.<init>(Unknown Source)
        at org.wattdepot.cli.ChartPowerCommandCli.generateHtmlOutput(ChartPowerC
ommandCli.java:346)
        at org.wattdepot.cli.ChartPowerCommandCli.processCommand(ChartPowerComma
ndCli.java:394)
        at org.wattdepot.cli.CommandLineInterface.processMainCommand(CommandLine
Interface.java:218)
        at org.wattdepot.cli.CommandLineInterface.processUserInput(CommandLineIn
terface.java:177)
        at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java
:269)
wrote: C:\wattdepot-cli-umikumaha-1.1.1104chart_data_Sun Nov 08 15:35:09 HST 200
9.html
By looking at the location of the output file, I think it's missing the "\" between output file and the source directory.
7. The list power generated {source} timestampe {timestamp} does not follow the command specification. Also, it still does not work when I follow the format from the description in help.
>list powerGenerated SIM_KAHE_1 timestamp 2009-10-26T12:30:00.000-10:00
Exception in thread "main" java.lang.NullPointerException
        at org.wattdepot.cli.CommandLineInterface.processUserInput(CommandLineIn
terface.java:173)
        at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java
:269)
Addition to the commands that I mentioned above, I found that other commands also have similar issue that I don't think it necessary to repeat twice.

C. Review the JavaDocs: There is no problem creating Javadocs with ant-f javadoc.build.xml and also the package and class summary seem to be fine.

D. Review the names: there is no major problem with the naming convention of class or variables in the system.

E. Review the testing:
8. The code coverage result is poor, 49% for method, 25% for block, and 22% for in-line coverage. 9. There also some unused variables that are not clean up.

F. Review the package design:
10. There is only one package in the system that hold the command interface, process the command, and test cases for each command. I think all class commands should be package in another package along with the test class (which eventually will be in a seperate test package when the system growth).

G. Review the class design:
11. To prevent the side-effect when the system growth, I think each command should be in it own class instead of grouping the similar command in one class. For example, list sensordata {source} timestamp and list sensordata {source} day are both in listSensorData class.

H. Review the method design:
12. There is no implementation for list power generated {source} day {day} sampling-interval {min} statistic {max|min|ave} and list power consumed

I. Check for common look and feel: there is no major problem.

After reviewing the wattdepot-cli-umikumaha, I think there are lot of issues with the system that need to fix. I hope my review comment can help both Aaron and Dean to improve their system.

Wednesday, November 4, 2009

Experiencing Team Development with Wattdepot Client

For my first group project, I work in ekolu team (or team 3) with BJ Peter Delacruz (as the team leader) and Wahib Hanani. Our assignment is to build the command line interface for wattdepot client to include all command list in the command specification.

We finally finished the project that also incoporate comment and reviews from Dr. Philip Johnson. The distributed package consists of the 10 command classes in the command specification and test class for each command. Classes are packaged in two packages : org.wattdepot.cli.command, and org.wattdepot.cli.processor.

One of the biggest challenge that we encountered in this project is the code overwritten. Even though subversion is a great tool for committing the source code to the centralized server, it can't prevent the overwritten issue. One might ask how could that happend. The answer is not mysterious if you have two or more people are working on the same file at the same time. When the first person committs the change while the other still work on that file. During the group meeting, we've spent quite a while on reviewing the different and merging both local and updated file.

Overall, this is a good experience especially to participate at the early stage of the revolution for renewal energy. Learning from this first group project, I think the most important pharse (at least for this kind of project) is to detail the break down of the system. As for this project, we put a little too much work on the team leader (BJ) during the reviewing process.

Monday, November 2, 2009

Continuous Integration on Hudson

Continuous Integration (CI) is a software development practice that automate the build command periodically. As many users check in and commit the source code, it will be very difficult to track the error without knowing who cause the failure. The CI provides log of each build that developers can review to find out what had happended to the system at a specific period.

Hudson is a continous integration server for ICS Software Engineering. It provides a plateform for any software development project that using Marven or Ant build tool and Subversion. Creating a new job on Hudson server is very easy; however, scheduling the build trigger is a bit confuse especially between build periodically and poll SCM.

I was assigned to work on the wattdepot-cli project with BJ Peter Delacruz (the leader) and Wahib Hanani as team ekolu (or team #3). We've created a job on Hudson called wattdepot-cli-ekolu, scheduled the build trigger on every five minutes, and set up the failure notification to be sent to the wattdepot-cli Google group. It was a mistake on the scheduling as the trigger generated hundreds of builds; thus, the log seem to be useless. Later on, we changed the schedule to trigger the build command only when there is a change in the source code which also allows us to know when was the last update on the system.

Personally, I believe that a great tool like the CI alone can't make a smooth development process without involving other interaction such as properly configure the build trigger, break up the package into small pieaces, or constanly update the system.

Saturday, October 17, 2009

Midterm Question

Here is my question list to prepare for the midterm.
  1. Describe the three prime directives that could be found in the distribution of the Robocode.

  2. - PD #1: Robocode is Java-written game. User can control which tanks to add to the battlefield and watch the moving and targeting strategy of each tank.
    - PD #2: user can successfully download and install robocode from sourceforge.net.
    - PD #3: Robocode also meet the PD#3 because it provides instructional document that external developer can use to develop their own robots and upload to the server.
  3. According to the article "The poetry of Programming", what are two aspects that Richard Garbriel used to differentiate the software creation from engineering discipline?

  4. #1: there are always a mixed of old and new design in each released version.
    #2: write software requires a lot of practicing work including write your own code while also review and critique other's code to become an expert.
  5. Provide a name that meet the naming convention standard to the following item:
    • a class of publication record:
    • Publication
    • a variable for list of authors:
    • authorList
    • a method to get the author list:
    • getAuthorList
  6. How do you verify the installation of Ant 1.7.1?

  7. At command line, type the following command and see if you can get a readable message.
    ant -version
  8. When does the happy path test consider as the antipattern"?

  9. The happy path test consider as the antipattern when the developer stop testing at the happy path test.
  10. Write a method to display every element in a list that take the list as the input. The method must use the new feature of Java 1.5.
  11. function displayListElement(List<string> authorList){
     for (string author : authorList) {
      system.out.println (author);
     }
    }
    
  12. Briefly describe the three advantages of using Git mentioned in Carsonified's blog?

  13. - Git clone is much faster than SVN Checkout
    - the ability to synchronize with other Git respositories
    - multiple remote respository help collaborating the team work when the centralized server fail to perform.
  14. How does the centralized workflow in Git different from SVN?

  15. Git allows user to have multiple remote respositories for each project with different access type. It also provide the ability to synchronize between multiple respositories to get the last complete version of the project too.
  16. What is the GNU manifesto to the meaning of free software?

  17. The GNU meaning of free software is the freedom to manipulate the source code.
  18. Under the GPL, how can a business make money from "free" software?

  19. You can add some useful functions to the free package and ask user to pay the fee.
The advantage of creating this question list is to basically self-review all materials that have been covered so far in the class. Hopefully, this question list will remind you to review some of the forgotten parts.

Wednesday, October 14, 2009

Subversion and Google Project Hosting for Firingdock

Since I started to work in a team environment, a lot of issue arise. Like many developers, I've been experiencing issues such as my code was over-written accidently or even "the happy testing issue". The issue was not just because of multiple developers involved but also caused by the sync of multiple copies of source code from several local machines. I sometimes spent days just trying to fix the bugs resulted from code over-written.

Using the version control tool like Subversion give me a key for my own problem. I think Subversion is just a great tool for multiple and rapidly release of source code. After installing TortoiseSVN, I've familiarized myself with SVN by checking out the robocode-pmj-dacruzer project from Google Project Hosting. I also made a minor change to the system then verified the package before committed the change. The most important feature of SVN is the promptness of changes made to the system. I think the vulnerable issue with SVN especially for the open source is allowing anyone to committ change to the system. However, holding with the same believe as Jimmy Wales, the co-founder of Wikipedia, will surely overcome this issue.

While SVN meant for tracking release of the source code, Google has provide us a great tool for open source environment. Not only that it cost-free, the Google Project Hosting provides web space to host the source code, wiki page for creating user guides, and interface to track changes of the source code.

After getting around with both SVN and the Google Project Hosting, I think both tools perfectly work together. It is also a good learning experience to explore how thing work in the open source environment.

Checking out the Firingdock's project on Google Project Hosting.

Monday, October 5, 2009

JUnit: 6 Test Cases for FiringDock

A year ago, I totally disagreed when my co-worker mentioned the fact he loves about programming in Java is the ability to build test cases. What is a test case? Every time I code, I compile and verify the result, isn't that called testing? On the first day of ICS613, I got brighten up a little bit when the professor, Dr. Philip Johnson, demonstrated JUnit for FuzzBuzz. Still, more questions came up on how to extend from testing a few lines of code to a large package and also for a web application.

Started from created FiringDock for the first robocode tournament to distributed the high-level package called FiringDock 1.0 with QA tools, I included six test cases in this pacakage. There are two types of test:

Acceptance test: simply verify the victory against the sample robots, in which I chose Crazy and Walls.
  • TestFiringDockVersusCrazy: Make sure that the FiringDock every round.
  • TestFiringDockVersusWalls: FiringDock can at least win 50% over the Walls.

    Behavioural test: verify the robot's strategy, which include the following test:

  • TestFiringDockBulletHitEnemy: verify that in each round the bullet hit enemy at least 7 times.
  • TestFiringDockBulletPower: verify that FiringDock uses the most bullet power for the still target.
  • TestFiringDockMoveEachFire: verify that FiringDock always moves after each firing.
  • TestFiringDockMovement: verify that each round FiringDock randomly moves at least 6 times.
  • Actually, I didn't have any problem building the acceptance test because there's an example provided in the robocode-pmj-decruzer. However, I've spent quite a long time for the behavioural test. I've struggled for a while thinking of what type of strategy I want to test for. Though, I could think of some cases, I was limited to what I can do with the RobotTestBad. This got me confused between the functionality between extends Robot and RobotTestBed. Actually with RobotTestBed ther are not so much properties exists because it just capture the snapshot to the robot after each turn. For instance, to check the bullet's power, I actually used the change of energy as an indicator.

    Along with coding the test case, I also split some code into sub-class as I came across an issue of how could I test everything at once. This was part of my bad coding behaviour as I usually throw everything in one place.

    Next, I ran emma, code coverage tool, and I got a pretty good result. I also verified the pacakage with the QA tools before created a new package.

    Overall, there are lots of improvement in this package both on the coding style and the robot's behavior. I've learnt a lot from the thought process of determine the test case to redesign the package for testability and then build it. Also, this process encourage me to search for IDE tool that fit for building database-driven web site instead of using modern text editor-based tool (eg. Dreamweaver). Fortunately, I found the Eclipse PHP IDE as an open source project which is very ideal for my current project. Hopefully, my coding behaviour will change and I will be able to design a better system for reseachers at the University of Hawaii Sea Grant College Program.

    To download the distributed package with test cases, click here.

    Thursday, October 1, 2009

    Quality Assurance Tool to Improve the FiringDock

    After the first robot tournament in class, I decided to improve the performance of FiringDock as it is not an effecient strategy to only move when get hit by a bullet. The new FiringDock moves randomly after each time the enemy is in the radar to avoid the bullet. Also, when hitting on another robot it turns the gun toward that robot and fires hard. While the FiringDock 1.0 couldn't defeat the SpinBot and the Walls at all, the FiringDock 1.1 has more chance to defeat those two robots. As a result in the 10-round battlefield, the FiringDock 1.1 can survive for 6-8 rounds with the Walls and 4-6 rounds with the SpinBot. The result of the battlefield with Crazy is also significant improve.

    After making all of these changes for the FiringDock, I used the Ant, which is an open-source build tool, to automate the process of style checking, executing test case, and building a distribution package. After installing Ant along with Ivy, I used checkstyle, PMD, and findbugs to check my FirindDock's code. As a result, there are 10 checkstyle errors

    Missing package-info.java file. 0
    Missing a Javadoc comment. 25
    Missing a Javadoc comment. 44
    Line is longer than 100 characters. 48
    '{' is not preceded with whitespace. 53
    '{' is not preceded with whitespace. 54
    'else' is not followed by whitespace. 61
    '{' is not preceded with whitespace. 61
    Expected @param tag for 'e'. 75
    Expected @param tag for 'e'. 83
    and 4 fingbugs warnings all of which are unused variables.
    UrF Unread field: lnp.FiringDock.enemy In class lnp.FiringDock Field lnp.FiringDock.enemy At FiringDock.java:[line 19]
    UrF Unread field: lnp.FiringDock.gunDirection In class lnp.FiringDock Field lnp.FiringDock.gunDirection At FiringDock.java:[line 23]
    UrF Unread field: lnp.FiringDock.turnCount In class lnp.FiringDock Field lnp.FiringDock.turnCount At FiringDock.java:[line 22]
    UuF Unused field: lnp.FiringDock.direction In class lnp.FiringDock Field lnp.FiringDock.direction In FiringDock.java
    After executing ant command for the three QA tools above, I partially agree on how useful the QA tools are. While I don't have any problem follow the screencast of build pmj-decruzer, I am not quite sure about the accuracy and reliability of using automate check style tool for a high complex program. It seems that the automate checking style is very accurate for the FiringDock as it only consist of few classes. Digging through each section of the code just to fix the whitespace issue probably not a real solution for a high-level complexity program.

    Download the FiringDock distriubiton here.