Monday, November 23, 2009

Review of e-hoomaluo Web Application

E-hoomaluo is a web application providing daily information on the level of carbon intensity of Oahu grid. After reviewing the system, here's the few things that catch my attention. The cool features of the system is the calendar picker which simplify user a lot. It's also prevent user from typing the invalid date. However, the date format should be rearranged to mm-dd-yyyy instead of yyyy-mm-dd. In term of interface design, the date textbox should set to readonly. This will eliminate the issue that user will input invalid date or any random text. Also, the date textbox size should shrink to only the length of the date. I also suggest to have a calendar grid icon for the calendar picker icon, it's more familiar to most user. After waiting for a result to show up, I've got an error message at the top of the page. I was freak out a bit as the message for any date that has no data that goes as "Got a bad result...". The users might interpret the message differently and they only like to see a good result. To gain user's attention, the error message should has some style like red bold text and somewhere in the middle of the page. I do like the carbon-level label which is a good idea to help user to understand the result better. However, the mathematical symbol should be replaced with text as not everyone knows these symbols. In the system documentaion, I think the description of wattdepot package is incorrect. The last suggestion is for the threshold calculation. The system need to filter the hard-coded threshold value with at least another constraint such as time or total carbon emission. My last word for the implementation design, I like the idea to pack the page components in a component package.

Beside my comments above, I also checked the system coverage, reviewed the software ICU, and reviewed the naming style. I don't find any major issue that worth mention here. I hope this review will somehow help improving the e-hoomaluo system. Keep doing great work!!!

Sunday, November 22, 2009

Web Application Experience: Ekolugical Carbonometer 1.0

Moving on to the first Webapp project in ICS613, I was assigned to the same group. My teammates are BJ Peter Delacruz and Wahib Hanani. We name the system "Ekolugical Carbonometer". Our goal is to build a web application that displays carbon emission information for the Oahu power grid. The information displays with a color: red, yellow, and green to indicate the carbon intensity level high, medium or low. Additional detailed about the system can be found here. Check the download section, for the appropriate package.

Activity Overview

On the first day, we met in BJ's office to start on the project. I created the Google Project Hosting for the project and updated the build.xml files to reflect the new project. BJ and Wahib both were working on configuring Hudson and Hackystat. During the week, we met three times: twice during the class hour and another standup meeting. We also had one long meeting over the weekend to review and refactor the system. Beside meeting in-person, we also communicate via Skype. Before I started involve in implementing the system, I spent about two days studying Wicket. We don't use the issue tracker very often. One of the reason due to the project period which isn't that long. Instead of waiting for another member to fix issues that we've found, we just fix it right away.

System Overview

Our implementation goal is to give a reasonable result to the users. We don't want users to defer electricy for three days straight or can always use the electricy anytime. For version 1.0, the system computates dynamic threshold for carbon intensity. The threshold for each day derives from the threshold of the previous two days. The system also check to make sure that the red flag will not stay over 12 hours period. The system still need a lot of improvements as some major issues are listed below:
  • the output still sometime remain green for the whole day which mean the threshold does not quitely accurate
  • the system needs to refactor
  • the system needs more tests

  • Hopefully, the next release will at least address thes issues.

    Group Overview

    Overall, everyone works really hard on this project. Each member shares idea and participate actively in the project. We have worked really hard to verify the system and ensure that the distribution package will work for the other users. However, due to the complexity of Wicket and time constraint for the project, the delivered product at this stage is not fully satisfied the goal.

    Software ICU

    Below is the screenshot of software ICU for our system. From the screenshot above, there are two red flags on churn and test. It's because the system doesn't fully test. The coverage, complexity, and coupling look pretty good.

    To join the project, feel free to contact one of the project administrator from the project owner list.

    Monday, November 16, 2009

    Wattdepot Client Version 2.0 (Ekolu)

    Finally, we're done!!! During this week, team ekolu has been working really hard to meet the released deadline of version 2.0.

    Activity Overview

    First of, while BJ and Wahib were updating the current implementation based on the code review's comment, I'd updated the current command specification to meet the specification of the new version. It toke me quite a few hours just to remove one word from the command string and update the index of the string. As I had to update the main class and all the test class, after I had finished two commands, I realized that the current implementation was poorly designed. At least if we had used patten recognition, it probablly not a pain.

    Next, there's two tasks that BJ (as a team leader) did. He created a new job of wattdepot-ekolu-daily-build in Hudson and define the wattdepot-cli-ekolu project in Hackystat. Actually, we worked on the last one together in class. As we followed the instruction from Dr. Johnson's screencast of Software ICU, we didn't have any major problem setting up our project.

    Later, we moved on to implementing the three new commands below and its test cases.

    2.11 fueltypes {source} by Wahib Hanani
    2.12 totalpower {source} {timestamp} fuelType {fuelType} by Lyneth Peou
    2.13 carboncontent {source} {timestamp} sampling-interval {interval} by BJ Peter Delacruz 

    After that we reviewed the whole system to improve the coverage overall as we had a very poor coverage for class (92%), method (73%), block (58%) and line (65%) in the first version. In the reviewing process, we had also done a lot of significant improvement to the system.

    Also, we'd worked together to solve the questions in part B, posted here.

    Lastly, we had another round of testing and verifying the distribute package before posting the package.

    System Satisfaction

    The version 2.0 of wattdepot client by team ekolu includes the following updates:
  • created a new class for quit command and its test case
  • splited the method of ChartPower command (2.10) into its own functionality
  • reviewed the exception block
  • added more test cases for each command to satisfy the coverage overall; in which most part that wasn't cover is the exception block
  • also cleaned up the unused code
  • At this point, I really satisfy with the released of the version 2.0. We had taken care most of the issues raised by reviewers especially George Lee gave us a bunch of constructive comments. The code coverage of this version is pretty good.

    class: 97%
    block: 97%
    method: 75%
    line: 79%
    

    However, I think the quality design of the system is still average in term of the current implementation of processing the string input and the exception. Also, we have not implement a good mechanism to process the exception at this version.

    Group Interaction

    During this week, we met 3 times and communicated through skype for most the time. I think the communication via skype was very productive. The partition of the work in this round was not overload to the team leader as the first version. Each of us work on one new command and two questions. Of course, I had been working on this project everyday and for this version I've spent about triple time I worked on the first version.

    Experiencing Software ICU

    Below is the screenshot for the first and last day of software ICU for wattdepot-cli-ekolu. During this week, we've been using software ICU as a tool to monitor the project health. I think from the two screenshot above, we've been doing a lot better than we first started; the coverage is high, the complexity is low, also the devtime is high. Everyone participating very actively in this round.

    Answer to Question in Part B

    During November, for SIM_OAHU_GRID
  • The highest energy usage is 995MW; usually at 8PM every weekday: 2-6, 9-13, 16-20, 23-27, and 30.
  • The lowest energy usage is 493MW; usually at 4AM every weekday: 2-6, 9-13, 16-20, 23-27, and 30.
  • The most energy consume: no data
  • The least energy consume: no data
  • The most carbon emitted is 29959.193 lbs on the following day: 5, 13, 16, 17, 20, 26, and 30.
  • the least carbon emitted is 22908.58 lbs on the following day: 7 and 8.

    To derive the answer of these questions, I implemented a temporary class that has two methods; one for the energy statistic and another one for carbon statistic question. These methods use the two existing method to create a data set of each hours (for energy) or day (for carbon) and sort out the one that has the lowest or highest values.

    Personal Experience

    This is a really good setting for experiencing group coding and software development. I think some of the tools that we've been using is very useful such as Subversion that give us a quick warning whenever the system fail.
  • Tuesday, November 10, 2009

    How Does Code Review Improve Wattdepot Client?

    Code review is an informal process of getting some feedback at the early stage of developing software. Code review requires the release of the source code to the selected reviewers. Also, the reviewers are required to thoroughly test the functionality of the system, verify the system documentation, read the source code, and evaluate the performance of the system. Of course, the goal of code reviewing is to catch all possible errors and bugs at the early stage.

    For reviewers, the most interesting part of code review is getting to learn the others "coding style" while reading their source code as there's always new thing to learn.

    After working on the Wattdepot Client 1.0 as team ekolu, my assignment was to review the Wattdepot Client of the other two team; umikumaha and umikumakolu. Actually, the review checklist, provided by Dr. Johnson, is useful such that I know where to begin at. At least there are two common issues I've found to improve my own Wattdept Client 2.0 after the code review.

    First issue was the coverage tool does not cover most of the exception code. My first thought was maybe it's normal because it's just exception. After I'd thought about this, the way to tweak the coverage tool might be creating test cases for each exception.

    Second issue was the try/catch of a single exception in multiple command classes. As in each command the exception code is about 10 to 20 lines of codes, creating a new exception class by itself will probably eliminate the redundancy code.

    Personally, I think code review is a very helpful process to improve the performance of the system as well as to write source code. Sometimes we're only keeping on the main parts and ignoring the tiny parts that in fact could blow off the system unexpectedly.

    Sunday, November 8, 2009

    Code review of wattdepot-cli-umikumakulo

    This is the wattdepot client interface of team umikumakulo (or thirteen) by George Lee and Yichi Xu. Below are some issues that I identified.

    A. Review the build: the system successfully build.
    1. Missing some external libraries in Eclipse due to the incorrect build directory.

    B. Review system usage: there is no problem with the happy testing for all the commands.
    2. The error message is invalid. The below is error message should be "Invalid source" instead of "Connection error".

    >list summary SIM_KAEH
    Connection error
    

    3. Also, the system does not validate the input string properly as input string such as the following are also work.
    list sourcres!@#@
    list summary23
    list power232s ... day
    4. The empty command issue: the system should let go of the empty command instead of display "Unknown command" message.

    C. Review the JavaDocs: there is no problem generating the Javadocs for the system.
    5. The description of the main command class is meaningless. For example, chartPowerCommand: Implements the chart command. Instead, the description of this class should be "Creates HTML file representing chart for power generated or consumed from startday to endday.

    D. Review the names: there is no significant issuer with the naming convention in the system.

    E. Review the testing: the result of code coverage is over 90% for method, block, and line.
    6. Mostly the exception block is not covered.

    F. Review the package design:
    7. The help and quit command should be part of the command package instead of processor package.

    G. Review the class design:
    8. The commandProcessor is not self-contained because it also trigger the help command and quit command differently from the other commands.

    H. Review the method design: after reviewed the source code of the commandProcessor class, I found myself the answer to the issues the I mentioned in part B.
    9. Instead, the commandProcessor should check for each term of the input token (maybe just ignore the case).

    I. Check for common look and feel:
    10. From the Javadocs, George and Yichi refers to the system sometime as "command line interface" or "command handler". Though, it's not so important for the functionality of the system, it still represents some confusion to the user.

    11. Also, after reviewing the source code, there exist some uncommonality in the format. Some blocks of the source code space out widely, which make it more clear and easy to read, while some blocks does not have any whitespace at all.

    I hope my comment will help George and Yichi to improve the wattdepot-cli-umikumakulo.

    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.