Final Thought on ICS 613 Software Engineering

Finally, the semester is over. After taking the ICS 613, here's my final thought of the course.

Positive Aspect:

This is the real-world trainng of software engineering experience. I really enjoy the tought assignments in this class because I believe that is the best way of training myself to become a better software developer. I've learnt a lot of new practices as well as experienced in team environment. The professor, Dr. Johnson, is also very passionate about the subject. I believe that he might had spent a lot of additional time preparing the screencast lectures for the class.

Negative Aspect:

This class is very time-consuming both on the programming assignment and writting the blog. It's both programming and writting intensive. I've spent about 75% of my time working for this class alone. Fortunately, my other classes didn't have much work.

In conclusion, I would recommend this class to every ICS students but also make sure that you don't take two programming intensive classes at the same semester.

Ekolugical Carbonometer 2.1

Ekolugical Carbonometer is a web application that developed in Wicket by team Ekolu. This application is the gateway to data of power grid on the Oahu island. In addition to the improvement of the existing pages (stoplight and grid info) from previous version (1.0), the new version (2.1) also includes three new pages which are Grid visualization, Source summary, and Carbon Intensity page. The section below is the summary of the system improvement.

Main Page: Provides brief description of each pages. Also the layout of the main page has been updated to be consistent with the rest of the system. Instead of wicket URL, the new system also provides the bookmarkable URL for each page.

Current Carbon Intensity Page: this is formerly the Stoplight page. This page use the stoplight to indicate the status of the carbon intensity level of Oahu grid at the current hour. In addition, it also provides useful tips accordingly to the status. The tip is also updated in every ten seconds.

Grid Information: display the power data in chart view. Three major improvements of the page includes the calculation of data period of each granularity option, the use of ajax-style for processing the chart, and the update of chart Y-axis based on the dataset.

Grid Visualization: presents power data in a visualization mode. The system provide user an option to include multiple power data in the chart.

Daily Carbon Intensity: display the daily carbon intensity information of the Oahu grid. The stoplight-mode also available on this page.

Source Summary: displays the summary of each power source. The detail information of the project is available on Google project hosting site under ekolugical-carbonometer.

Project Experience

It's finally a big relief after this project is done. I've been working very closely with my teammate both BJ Peter Delacruz and Wahib Hanani on this project. Each of us very devotes to this project. Personally, this is a great experience for software development. There are a few factors that matter to the completion of this project. We've used the software ICU to monitor the project progress such as the coverage of the system. However, the software ICU doesn't really reflect the amount of actual work for each member due to some administering tasks doesn't monitor by the system. Also, working collaboratively is very important for this groupwork. Though, we have assigned specific tasks to each member, we always jump in to help or shuffle the task so that each member can involve in all part of the system. Last word to say, I will miss the fun working in ekolu team.

Have a wonderful winter break!!!

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!!!

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.

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.

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.

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.

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.

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.

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.

- 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.
2. According to the article "The poetry of Programming", what are two aspects that Richard Garbriel used to differentiate the software creation from engineering discipline?

#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.
3. 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
4. How do you verify the installation of Ant 1.7.1?

At command line, type the following command and see if you can get a readable message.

ant -version

5. When does the happy path test consider as the antipattern"?

The happy path test consider as the antipattern when the developer stop testing at the happy path test.
6. 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.

function displayListElement(List<string> authorList){
 for (string author : authorList) {
  system.out.println (author);
 }
}

7. Briefly describe the three advantages of using Git mentioned in Carsonified's blog?

- 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.
8. How does the centralized workflow in Git different from SVN?

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.
9. What is the GNU manifesto to the meaning of free software?

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

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.

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.

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.

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.

FiringDock: My First Competitive Robot

Task: Design and implement a single robot that can reliably beat as many of the following eight sample robots as possible: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, SittingDuck.

After studying the strategies of some simple robots include in the Robocode and brainstorming some strategy to counter those sample robots, for this week I started to build my first competitive robot which called FiringDock. Click here to download.

Movement: This robot sits still and only moves 100 pixels perpendicularly to the bullet when it hit by a bullet.

Targeting: The targeting for FiringDock is similar to the TrackFire. The radar and the gun always points at the enemy.

Firing: The firing strategy for FiringDock is very simple. The FiringDock always fires when the enemy is scanned. It fires with the bullet power proportionally to the distant between the enemy and the enemy's velocity. While minimizing bullet waste and maximizing the chance to shoot the target, it fires the maximum bullet power when the target sits still or is within 300 pixels; otherwise, it fires the lower bullet power.

Sound simple, isn't it? Now let's look at which sample robots it can defeat in a 1v1 battlefield.

Corner: the FiringDock has more chance to win the Corner because the Corner does not attack until it get to the one corner of the battlefield and it only sits still there. The chance that the FiringDock gets hit by the bullet is less because it moves to a new position when getting hit by the first bullet. The FiringDock also has a more efficient firing technique for a still target.

Fire: similary to the FiringDock, the Fire only moves when it hit by a bullet. With the firing technique that always fire hard at the still object, the FiringDock always win the Fire. The FiringDock also has a better targeting technique when it moves or the target moves. It scans for the target faster when it moves or the target moves.

RamFire: the FiringDock can easily win the RamFire because the RamFire take time to turn and move closer (as it tries to ram), it only fires when it hits the enemy and it does not move away from the bullet.

SittingDuck: the firing technique of FiringDock can easily kill the SittingDuck in every battelfield.

Tracker: the FiringDock can easily kill the Tracker because the Tracker only fires when it get within 150 pixels. The FiringDock can at least reduce 1/2 or 1/3 of the Tracker's life before it opens fire.

However, the FiringDock cannot defeat the Walls, the Crazy, and the SpinBot with the same strategies because it does not include a predictive shooting algorithm for a moving target. The FiringDock lost energy in two ways: it gets hit by the enemy and it wastes the bullet. Keep pointing the gun at the target does not work for a moving target.

Lesson learned: I admit that without looking into the code of each sample robot, the FiringDock probably defeat less than the five simple robots above. Designing a real competitive robot is very challenging. Though, we have an idea of how to defeat the wall by following behind it, coding a single robot that could defeat all will not be easy without some movement pattern recognition involve. While trying different ideas to design a single robot that defeat all, another option is escaping the bullet. The constraint to this option is the lack of functionality for scanning when the enemy fires a bullet. By googling the web, I realized that we can track this by tracking the energy drop (between .1 and 3). I beleive, with some additional conditions, this could be a potential solution for surviving the Walls, SpinBot, and Crazy.

Review of Strategies in Sample Robots

The sample robots included in the Robocode package has a lot of potential for competitive robot. While trying to tacgle for the first robocode assignment, the only feature that missing from the sample robots is the trigonometric moving between two points. Because I like simplicity (even for a complicate problem), I really like the targeting of TrackFire. Anyway, below is the review of moving, targeting, and firing strategy of eigth sample robots.

Walls: It first turns to one of the special angles then moves to the furthest wall. The targeting of the walls is simple but efficient enough to stop before hitting on an enermy. With the "peek" variable, the robot will stop if there an enermy in front of it and it will keep firing till the enermy out of the way. If it hits the enemy in the front, moves back; otherwise moves ahead.

RamFire: The movements is straightforward. The targeting is not very efficient because the radar only turns when the robot turn. Thus, it need to rescan for a new enermy while trying to get close to the previous enemy that already moved out of the radar. It only fires on hitting at the enermy and uses the bullet power proportionally to its energy. Though, it seem to be effecient, in a real battlefield, the chance is that it could be killed before hitting on any enemy.

SpinBot: This is the extends of AdvancedRobot. Its unique feature is the circle movement by turning in a large degree with a low velocity then moving ahead. The targeting is straightforward. The firing is not energy efficient. Not only that it fires hard once scanned on a robot, it also does not track the exact location of the moving target. Thus, there's more chance that the bullet would miss the moving target.

Crazy: This is another advanced robot. The movement of this robot is seem randomized. After looking at the robot movement and the code, first I wonder what make this robot not moving a straight ahead while in the code said so. After deeply investigate some of the advanced robot function, I've realized that each of the set movement will not execute until the completion of waitFor(new TurnCompleteCondition(this)). That seem to be a pretty cool method of making a random movement. The targeting and firing is straightforward and also it does not track the exact location of the enermy. It takes longer to kill an enemy because the bullet power is low.

Fire: This robot turn "perpendicular" to the bullet before moving backward or forward 50pixels each time hitting by a bullet. Without interupting, it sits still, spins gun around and fires on the target. The gun spins around but does not follow on any enemy which is not so efficient on a tough battlefield. It uses the bullet power proportionally to its energy and the distance of enemy. It also do the best to kill enemy as fast as possible if it hit on it.

Sitting Duck: This robot sits still and keeps track of its persistency. There is no movement, firing, or targeting in this one. At least the feature of this robot is tracking robot's life into the external file.

Corners: This robot first moves to one of the corner and switch the corner if it did not do well in the previous round. Similarly to the walls robot, the corner uses "stopWhenSeeRobot" variable to be alert of any enemy in its way. Instead of rotate the gun around, this robot only rotate the gun back and forth which is sufficient enough. The ability to keep track of enemy in the field and statistisc of each round make this robot unique. Maybe we can include that feature in the design of the competitive robot. The firing is similar to Fire.

Tracker: This robot tries to move closer to its chosen target before firing. Before moving anywhere, it has to scan for an enemy and tries to move closer. The technique doesn't work for a moving robot. It rescan for the chosen target everytime after each turn. The method of finding the first target is unnecessary. We can get at least one target with just a single round (360) turn regardless of robot's position. Trying to rotate the gun to another direction should be replaced by pointing at the enemy all time. The firing is straightforward as it fires hard once getting close.

Coding Standard in Robocode

The most important reason for using the coding standard is the effeciency in debuging code especially with the following elements of coding style:

1. Comment: a meaningful comment is very useful for understanding the method or each line of code. Accordign to The Element of Java Style, comment is summary of interface, class, or method. By having a clear comment for each method, others rather than the author of the code can easily debug the code without asking the code author. Other programmer can also identify the pitfall in the code by just comparing the code's objective and its actual functionality.

2. Naming Convention: by having a standard naming convention, programmers can identify each names quickly without going back-forth or scrolling up and down between classes. Imagine the scenario of having 10 programmers working on each class of a project using different naming convention. Some use the old naming convention (no vowel with underscore, eg. gt_rpt) for both class, interface, method, an variable. Some use mixed convention, and some use a non-meaningful name. In this case, if someone rather than the author has to debug the code, he or she will spend quite a lot of time to adapt to the new convention and try to debug the code. A mix convention also presents an integration issue which could cause a nightmare.

3. Variable scope: by specifying the class, method, or variable with the keyword 'this, public, or private' has two advantages. First, it ensures the scope of each method or class. Second, it also prevent the common method or variable name issue in different classes especially for a global variable.

Revising Robocode: I spent about two hours for reviewing the coding style in my robocode that consist of thirteen movements. After reading The Elements of Java Style and the ICS coding standard, I realized that I had violated a lot of elements in coding standard. Just to name a few, those violations include a mixing naming convention, variable scope, and comment documentation. Actually, the comment section was a bit scary for me but I was very fortunate to come across Georg's blog that I could use as a sample. Renaming some of the variable name is not so difficult since in fact this project is small and also within Eclipse you can just simply find and replace. The last thing that I did was to ensure the single task in my method and also include a descriptive comment of the method.

Finally, my personal thoughts for the coding style is the rule #1: Adhere to the style of the original seem to be valid for different language not just in Java. Despite the fact that each language has different styles and rules, each project should document the related style use within the project.

To download my improved Robocode, click here.

My First Robot Assignment

Click to download LNP package

Robocode is a Java-based game, created by Mathew Nelson. Digest through all the robocode resource, I found that it's very interesting that the initial purpose of the this project was to prove that we can program game in Java.

Include in my package are the following movements:

Movement01: The robot does absolutely nothing.

Movement02: The robot move forward a total of 50 pixels per turn and it reverse direction if it hits a wall.

Movement03: The robot move forward a total of N pixels per turn, then turn left. N is initialized to 10 and increases by 10 per turn.

Movement04: The robot move to the center of the battlefield and stop.

Movement05: The robot move to the upper left corner, then to the lower right corner, then to the upper right corner, and to the lower left corner.

Movement06: The robot move to the center, then move in a circle, and ending up where it started.

Tracking01: The robot pick one enemy to follow them.

Tracking02: The robot pick one enemy and follow them, but stop when it gets within 20 pixels of them.

Tracking03: The robot find the closest enemy each turn and move in the opposite direction by 100 pixels, then stop.

Firing01: The robot sit still, rotate gun, and fire when it is pointing at an enemy.

Firing02: The robot sit still, pick one enemy, and only fire when it is pointing at the chosen enemy.

Firing03: The robot sit still, rotate gun, and fire the bullet power proportionally to the distance of the enemy.

Firing04: The robot sit still, pick one enemy, and attempt to point the gun at the enemy all the time but does not fire.

It's very obvious that one of my problem was to install the Robocode. Due to the default program for any *.jar file on my computer was Eclips, the installation of robocode did not start automatically. It tooks me a while to figure out and change the default setting of *.jar file.

After I successfully installed the Robocode, first I took a few hours to get my feet wet with all the classes, functions, movements, and events. I've read each link in 06.Robocode of this class as well as did my searching, and digging through the sample robot's code.

I did not have any problem with movement 01 to 03 since they are just to understand the basic steps of a robot. However, I've spent a lot of time on movement 04. I tried to create a shared function for movement 04, 05, and 06 and I first started with two steps to get to a new position. It seemed to work well for movement 04; however, it got confused when the robot has to go to multiple postions in movement 05. Instead, I rewrote the function by applying some trignometry function to measure the angle between two. Below, I attached my code to calculate the angle between two points:

    public double getDegree(double x1, double y1, double x2, double y2){
        double dx = Math.abs(x1-x2);
        double dy = Math.abs(y1-y2);
        double t = dy/dx;    //tan = opp/adj
        double r = Math.atan(t);     //angle = inverse tan (in radian)
        return Math.abs(r * (180/Math.PI));     // deg = rad * 180/pi
    }

Thus, to simply move to a new position, my robot has to:

turn to face the 0 or 180 (this help me adjust the robot's heading in the next step)

calculate the distant and angle between both positions

move to the new position the approximate distant

For tracking and firing robots, the most challenging issue is to keep the gun tracking the enemy (and not turning away). For my tracking01-bot, it will follow a new enemy when it collide with a new enemy. After digesting throught some sample robots, I used the approach from TrackFire-bot to track the enemy. This approach work perfectly with all of my tracking and firing robots.

However, I could not follow the specification for Tracking03 and Firing02. For Tracking03, I could not define "the closest enemy". I assume that the closest enemy for each turn should be the closest one in the radar angle. For Firing02, the robot sit still but the gun will follow the chosen target and keep firing until the target die. I first tried with the gun also sit still but it will take too long waiting for the target to come back again (which probably not in most cases).

Beside the technical issue, I also had problem with the unclear specification of each movement. For example, the turn left angle for Movement03, the started point in Movement06, and rotating gun in Firing02.

After spent most of the long weekends with this robocode assignment, I've learnt that to build a competitive robot, the following factors are very important:

smart fire: use the bullet power proportionally to the distant of the enermy

try to kill the enermy fast in each turn

destroy the most threaten enermy first

I've also got some ideas from the sample robots TrackFire and RamFire which can put together to build a competitive robot.

FizzBuzz Experience

FizzBuzz is a good startup assignment. In short, the goal is to print a number from 1 to 100 on each line and if the number is a multiple of 3 print Fizz, if the number is a multiple of 5 print Buzz, and if a number is a multiple of 3 & 5 print FizzBuzz.

It took me about 15 minutes to implement the FizzBuzz in which most of the time spent on setting up a new java project in Eclipse. Rewritten the code did not take long.

When I started using Eclipse for the first time, I encountered a lot of minor challenges. One of the challenges was setting up the java project and adding new java class into the package.

After finishing the main class, I also had problem when adding the JUnit test case to the package. It took a while to get the right syntax for assertEquals and get the TestFuzzBuzz pass.

Since it’s been a long time from my undergrad that I’ve coded Java, I’ve also encountered a lot of syntax error and mistype the keywords. By using Eclipse, it's a lot easier to code, compile, and package Java project compare to using command prompt when I first learned Java programming 7 years ago.

Here’s my code for the FizzBuzz:

public class FizzBuzz {

    public static void main(String[] args) {
        for (int i=1; i<=100; i++) {
            System.out.println(getFizzBuzz(i));
        }
    }

    static String getFizzBuzz(int i) {
        if ((i%3==0) && (i%5==0))
            return "FuzzBuzz";
        else if (i%3==0) return "Fizz";
        else if (i%5==0) return "Buzz";
        return Integer.toString(i);     
    }
}

Here's my code for the JUnit test case:

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class TestFuzzBuzz  {
    @Test
    public void Testfuzz () {
        assertEquals("1",FizzBuzz.getFizzBuzz(1));
        assertEquals("Fizz",FizzBuzz.getFizzBuzz(3));
        assertEquals("FuzzBuzz",FizzBuzz.getFizzBuzz(15));
        assertEquals("Buzz",FizzBuzz.getFizzBuzz(5));        
    }
}

Three Prime Directive: MyJQuery v.1.0

Overview:

Package downloaded: MyJQuery version 1.0

Author: Adrabi Abderrahim

URL: http://myjquery.sourceforge.net/

MyJQuery version 1.0 is a java-based database utility under open source license for executing MySQL statement released in June 2008 by Adrabi Abderrahim. MyJQuery is powered by Java Database Connection (JDBC) and run on any operating system. It is a tool that provides capability for manipulating MySQL database from simple query to complex SQL object creation. It can also export data to CSV, HTML, XML and generate code snippet of an entire schema's data in different programming languages. The key features of MyJQuery include the following:

• Query editor: allows for the execution of single or multiple SQL statements and the result of the executed statement is displayed in the log panel which also indicate specific error message and code.
• Database browser: allows user to view a database’s schema and tables.
• Query snippet: allows user to insert a SQL query for quick help.
• Export CSV, HTML, and XML data: allows for exporting data in CSV, HTML or XML format from one or more tables.
• Generate Perl, Perl/CGI, PHP, Java & JSP code snippet: allows for generating a snippet of MySQL code from one or more tables.
• Server database statistics: shows all statistics of the selected database.

Prime Directive 1: MyJQuery does not satisfy the PD#1. Though the design of MyJQuery is very simple and straightforward, MyJQuery does not fully satisfy the user interaction at all. The SQL editor does not mirror the modern text editor as it does not support some keyboards and the short cut keys. For instance, the SQL editor does not support the navigator key such as page up, page down, and arrow key. Also the user can only copy and paste by right-clicking the mouse which very inconvenience. Additionally, the SQL editor does not automatically insert a line break when inserting a new query from the query snippet.

Prime Directive 2: MyJQuery satisfy the PD#2. Any external user can download and unzip of MyJQuery from sourceforge.net site without any a problem. No installation is required for MyJQuery. The user can execute the program directly from the execution file in the package. There is no additional user-level documentation in the package to the README and LICESCE document. No java or JDBC knowledge is required; however, the user is required to have much or less SQL background to use the program. It will be very challenging for the user who has no SQL background. MyJQuery required connection to the database when it started. Users should get SQL tutorial directly from MySQL site or any developer forum if there is any syntax error from the query. There is no need for the program to provide additional tutorial on SQL.

Prime Directive 3: MyJQuery does not fully satisfy the PD#3. External developer can find the source code of MyJQuery in the develop section on sourceforge.net site. Though, the source code is well written and placed under GNU license, it still very challenge and time-consuming if the external developers decide to extend or modify the system as there is no developer-level documentation provided in the package that.

Conclusion: Overall, MyJQuery does not satisfy all of the three PDs. During the testing of using MyJQuery, it can only connect to the database on the local machine or within a specific location. For the key features of the system, it does not meet the user interaction. There are some frustration trying to use the query editor and try to the developer-level documentation beside the source code. Personally, I am looking for MySQL database management tool instead of just a query editor that allow connecting to the database server not only on the localhost as PHPMyAdmin is already provided a great tool to manage localhost database.