My Experience of Software Engineering Class

Finally, the software engineering class is over. It has been a pretty busy semester for me. In the beginning of this semester, I did not follow the class very well. I was kind of not getting used to so many work during one week or even two days. There are lots of blog posting and I never post a blog before. But now, I am used to it.

Being busy is not a bad thing. I learned a lot of new things in this semester. Before, I never used Java. Now I am pretty confidence with Java programming. I never used eclipse either. Now I am pretty familiar with eclipse. Before, I never created a unit test in my project, but now I understand the importance of testing and what is a good test coverage and quality. Further more, I never heard about Apache Ant and all those quality assurance tools, such as PMD, CheckStyle, and Findbugs. Now I learned how to distribute the system and make use of those auto-quality assurance tools. In the end, we worked on a web application that using Apache Wicket. Before I only used ASP .net frame work and now I have some experiences about Apache Wicket. The most important experience I gained this semester is that project management. Before I mostly code individually, now I learned how to split the work and use issue management tools to manage the schedule and effort.

After all, I think this class is an interesting and important class for me. It makes me more professional and helps me establish good coding habits. I am pretty satisfied with the content that covered this semester. However, if we talk about different software planing technique such as Agile, it will be more interesting.

Anyway, it is a nice semester to remember. Thank you very much for Dr. Johnson and all of you who helped me in this class.

E-hoomaluo V2.0 is released!!

After two weeks development, finally, E-hoomaluo V2.0 is released. It is more a new project rather than version 2. Almost nothing was kept from the last version. In this version, we need to create three pages:

-Home page: describe the purpose of this web application and instruct users how to use this web application.
-Stop light page: get current carbon emitted information from WattDepot server and display different stop light based on the value got.
-Grid info page: generate a chart that describes the energy generation for a specific source given a time interval.

Since we have four people in the group, we decide to split the work into four parts. First, Dean is going to work on the stop light page. Then, Aaron is going to work on the home page and write CSS for the web site. George is going to develop the user input and output panel for the grid info page. My task is to create the method that collects data from wattDepot Server and generate the chart URL.

It is always nice to work in a team. we had a lot good time in this project. For example, we meet in a coffee shop and discuss our status. We use Google wave to host an on-line meeting. We send emails to help each other. Besides, I learned some knowledge about how to use Apache Wicket to host a web application, such as how to add different inputs to the form. Also, I learned how to use google chart to generate different charts.

As a result, I think our E-hoomaluo is pretty good, although the design of the page is not very fancy. However, we got almost everything done.

After we released the V2.0, Aaron and I decided to keep working on this project so that we can get some bonus points for the class. Since there are only two people left, we didn't try to be ambitious. We basically improve the E-hoomaluo in three aspects:
1. Improve the user interface so that E-hoomaluo is more user friendly.
2. Create cache to reduce processing time of generating chart and loading stop light.
3. Develop more functionality in the gird info page, so that user can generate different kinds of chart.

We break the work in half: Aaron works on creating cache, while I work on enhance the chart generation, and both of us work on Improving the user interface.

Compare with V2.0, I added four more user inputs in the grid info page:
1. Time scale
It can be either "Hour", "Day", or "Week". It tells the time scale that used to grab data from WattDepot Server.
2. Resource type
It can be either "Carbon" or "Energy". It tells what type of resource that is going to be displayed in the chart.
3. Transitive check box
If transitive check box is checked, system will display the data for both the selected source and its subsources.
4. Cumulative check box
If cumulative check box is checked, system will generate the chart based on the cumulative data of the selected source.

Finally, we got the E-hoomaluo V2.1 done as well. The cache is working and the chart is more powerful. I am pretty satisfied with what we got.

I learned several lesson in this implementation. The one that impress me the most is that it is pretty hard to maintain other people's code. As I mentioned before, only two of us worked on V2.1, which means we have to maintain George's and Dean's code. Understand their code definitely takes some time for me. Second thing is that testing is really very important. For example, I didn't test a lot about generating chart with a time scale of "week". However, right before the project presentation, I find out that the error message is wrong and some data is not valid to generate the chart. The last thing I learned is communication is very important. For example when Aaron commit the cache creating part, I didn't notice that the data he hashed actually is wrong. I was keep looking at my code and finally find out that it is a caching defect. That also caused a lot of trouble during the development.

Anyway, next semester I will keep working on this project with Dr. Johnson. So hopefully, I can bring some more news on this topic. So, to be continued...

Oscar Web Application V1.1

Last week, we got some more new requirements on our web application project. As I mentioned in previous post, the version 1.0 "e-hoomaluo" only has one page which displays the carbon emitted information for one day and mark the data with different color based on a threshold. For version 1.1, we just need to modify the version 1.0 a little bit based on the comments that we got.

Basically, we have two important issues to work on:
1. Change the user interface so that the content will fit in one screen.
2. Change the threshold calculation so that in each day there will be some red, some yellow, and some green.

In this case, I volunteer to work on the threshold calculation. In version 1.0, we just pick some arbitrary value as our threshold. It is hard to have a spread red, yellow, and green in this way because the threshold we use represents the statistic in a long period. Therefore, I decide to use a moving average method to generate a dynamic threshold. After I implemented this method, it looks pretty good as a result.

Since last week in class we discussed about Oscar Web Application V1.0, I learned some interesting things about web application design. First of all, use the space effectively. Try to fit the content in one screen so that user does not have to scroll around. Second, keep the interface simple and clean. Third, make sure the default input value is a valid input, so that default input can show user an example how to use the system.

Reveiw for Project Ekolugical Carbonometer

Here is my reveiw for Project Ekolugical Carbonometer following our professor's checklist.

A. Build successfully
B1. The main functionality is implemented.
B2.
1.When I put 2009-12-04 and submit, it returns a list. However, if I put 2009-12-05, 2009-12-06, 2009-12-07...
and submit, it does not change. It looks like there is no data but the no data error does not show up.
2.When I put 2009-11-2g 2009 and submit, it returns error fail to convert to timestamp. However, the error message
should be "Please enter a date with the following format: YYYY-MM-DD."
B3.
1.The interface is not self-explanatory.
2.The system require unnecessary scrolling to see the data.
3.The style is not standardized. "Enter a date" compare with the "Maximum and minimum"
C1.Description included. No explanation how packages relate to each other.
C2.Description included. No explanation how classes relate to each other.
C3.Description included. No sample code for clients of the class.
C4.Description included.

D1. Most names are properly named. RESULT, RESULT_DAY_ONE, RESULT_DAY_TWO should not be capitalized since they are
not constant.
D2. Internal name looks Ok.

E1. Emma test coverage is good 86% lines of code.
E2. There are two tests have the same comment. Not test for the WattDepot query.

F1. I think the Thresholds class should be inside the WattDepotCommand class because the calculation of threshold heavily
depends on the WattDepotCommand class.

G1. I think WattDepotCommand class's instance "RESUTL", "RESULT_DAY_ONE", "RESULT_DAY_TWO" is not appropriate. They are
too detail.
H1. Methods look OK.
I1. The code is implemented consistently.
J1. Well documented for both UserGuide and DeveloperGuide.
K1. I cannot view the hackystats for this project.
L1. I think the planning is too general. There is no issue for implementation of the application.
L2. The task is evenly distributed.
M1. The system is regularly built due to commits,
M2. The builds failed states on Nov 21 lasted 2 hours.
M3. There is a daily build job.

Overall Comment:
I am not sure if Ekolugical Carbonometer project's threshold calculation make sense or not. However, I think the interface of the web-application definitly need improve. The idea of having a rolling threshold is very good.

WattDepot WebApp Project

In the past week, I worked on a new project about WattDepot service with George, Aaron and Dean. For this project, we named it "e-hoomaluo" which means "conserve" in Hawaiian (I heard from George). It is to retrieve the hourly carbon content data from the WattDepot server for a given date. Also it analyzes the data and displays the hourly data in different colors so that people know when is the best to use energy.

-Red means the carbon content is pretty high and you should try to use energy as little as possible at this time.
-Yellow means the carbon content is at a medium level. You may use some energy but it might not be the best timing.
-Green means the carbon content is low and if you want to use some energy to do something, now is the best time.

Unlike the WattDepot Cli project, "e-hoomaluo" is a web application. Again, unlike the most web applications I worked on before(I mostly use javascript to do the programing), this time we used Apache Wicket, which is definitely a challenge for most of us. Luckily, our professor posted 5 example web applications that using Wicket, so that I can play arround and help me to get use to Wicket.

Frankly speaking, I am still not good at Wicket. As far as I know, you have to have an html file paired with a java file. For example, you have a page called testPage.html. If you want to use Wicket, you need to have a file called testPage.java. Also you need to assign a special attribute called "wicket:id" in the html file. It is the name that will be recognized in the java file.

In this project, I didn't do anything with the web programing. I was assigned to implement the class that creates the connection to WattDepot server and retrieving the carbon content data. Aaron and George worked on the implementation of the web page. Dean worked on the setup and the documentation. Since Dean was outside the island for this week, George, Aaron and I met almost everyday. I think our work went pretty smoothly. In the first meeting, we decided the design of the web page and split the work. Later I just worked on my own part. Finally, George merged everything together and created the distribution. The only challenge during the development is to use Wicket to change the CSS of the hourly data. I and George spent couple hours to solve that. I think the group project gives me a lot of motivation.

Here is the software ICU screenshot for "e-hoomaluo":


Unfortunately, we do not have a good coverage of our project. I think it is because that none of us is familiar with how to write test for Wicket. Probably in the next version, we can find a way to write junit test for Wicket program. Another issue is that the score for Churn is kind of low, again I am not sure how this score is measured. However, I think we did have a continuous development for this project.
Anyway, here is the link to get to the google project hosting for "e-hoomaluo". In this page, you can find the source of "e-hoomaluo" project and also the user guide and the developer guide.

WattDepot Cli Version 2.0

Since we have developed the WattDepot Cli project in last two weeks, this week we are assigned to add some more features to WattDepot Cli and make it Version 2.0.

Last week, two other groups reviewed our project, they provided lots of feedback to us which I mentioned in my previous blog post. Therefore, we decided to modify our existing WattDepot Cli project before implementing new commands. First, we simplified the class names for all the commands. Then we added more error messages to represent different exceptions. Also we fixed some bugs that found in existing project. Then we start implementing the new commands.

George and I didn't meet this time. Since last project, we have known each other pretty well. So we decided to communicate by email. We email each other almost everyday to check out status. I implemented two commands and George setup the hackystat for our project and implemented one command. Therefore, I think the work is partitioned equally.

Here is a Software ICU screenshot for our project.


I think our project's health is kind of OK. We have a pretty good coverage for the junit test. Also we contribute to the project almost everyday. However, I am not so sure why the complexity is high because WattDepot Cli is a pretty simply project. I don't think we have a lot of loop or condition statement. The Churn value is kind of high because I kept having some strange problems in some junit tests and I didn't commit until Thursday. So once I commit, I introduced a lot of new lines. With these experience, I hope we can do better for the next project, which is coming soon.

Finaly, we need to find the answers to some questions that asked by our professor. George implemented two additional commands to answer these questions. So I used his new commands: "energystat" and "carbonstat". Here is the answer I got.

>energystats generated SIM_OAHU_GRID from 2009-11-01 to 2009-11-30 daily
Max: 14764.0 MWh at 2009-11-03T00:00:00.000-10:00
Min: 14089.0 MWh at 2009-11-02T00:00:00.000-10:00
Average: 14571.1 MWh

>carbonstats SIM_OAHU_GRID from 2009-11-01 to 2009-11-30
Max: 29959472.0 lbs at 2009-11-04T00:00:00.000-10:00
Min: 22908808.0 lbs at 2009-11-07T00:00:00.000-10:00
Average: 27141379.3 lbs

Code Review for WattDepot Cli - Part 2

After reviewing two WattDepot Cli projects that implemented by different teams and their comments of our WattDepot Cli project, I learned some lessons.
First thing I learned is that error message is very important. When I wrote my code, I saw there are some many exceptions to catch if I need to retrieve data for a source. I thought it is kind of tedious to compose the error message one by one. So why don't I just send one same error message "connection error". However, when I read the comments, both team criticize on this irresponsible error message by saying the error message should be more specific. In both their projects, they handle all kinds of exceptions separately. I think they are right. Error message is very important for users. If it is not very informative, user would never know why the program is not working.
Second thing I learned is that declaring instance inside a loop is not efficient. Before, I like to create a temporary instance in the loop to hold some value. This is very inefficient because I keep creating new object in the system which is not neccessary. Instead, I can declare it outside the loop, and in the beginning of the loop initialize the value of that instance. In this way, the performance of the program can be improved.
Third thing I learned is that reviewing the project that created by other people is not a easy task. Even though for a small project like WattDepot Cli, it still takes me some time to understand other teams' structure, global instance, and test cases. Therefore, programmers should try their best to code in a readable way so that future reviewers can catch up quickly.
Overall, I think review other people's code is a not a bad thing to do. Although it might be boring, you can always learn something that you never know.

Code Review for WattDepot Cli - Part 1

This week, I was assigned to review two other team(Ekolu, Umikumaha)s' source code for WattDepot Cli project. To conduct this review, each of us followed a review checklist that was provided by my teacher. After reading through other's code, I finaly understand how important the Javadoc is. Javadoc will show the structure for the project and it provides a easy way to access the code. Although it is not a fun thing to review code, I had some good time when I tried to break other teams' program.
Anyhow, following is my review for team Ekolu:
A. Verify passed. Build successfully.
B. All commands are working correctly, but there are a number of problems.
1."list sensordata SIM_KAHE_1 day 2009-11-10T23:30:00.0000" works the same as "list sensordata SIM_KAHE_1 day 2009-11-10".
2."list power generated SIM_KAHE day 2009-11-01 sampling-interval 0 statistic max will break the system and no command can be processed after that.
3."list power generateds SIM_KAHE day 2009-11-01 sampling-interval 60 statistic max" works fine. There is no check for string like genterateds.
C. The Javadoc for this project is pretty good. It does not explain how packages and classes relate to each other, but it is still very helpful.
D. Some class names are not very clear. For example, PowerTimestamp is not as good as CommandListPowerTimestamp. Some internal names are not informative too. For example, "fos" is not a good name to represent FileOutputStream.
E. The testing coverage is ok. However, there are some cases do not have test.
1. No test for correct intput for every command.
2. No test for help.
3. No test for sampling-interval value.
4. No test for "list power consumed", "list total energy" and "chart power consumed" command
5. No test for "statistic min" and "statistic average"
F. Overall the package level design is good.
G. The class level design has some problem.
1. SourceListing class is not used.
2. The block of condition: "" equals to sourceName in "list summary" command is a dead block.
H Most methods in the system accomplish only a single task. Some methods need refactor. For example in SourcesInformation class, the if statement in listsources method should be refactored. Overall, most methods do not have side-effects.
i.The consistency is not very good. For example, the error message for "list power consumed SIM_KAH timestamp 2009-11-01T00:00:00.0000" should be the same as "list summary SIM_KAH". Also sometimes stringbuffer is used to concatenate strings and sometimes just use + to concatenate strings.

The review for Umikumaha is still on-going.

I hope my comments can help them to improve the quality of the project.

WattDepot Client and Continuous Integration

These days, I learned about continuous integration, which automatically download the code from the repository and try to built it and run all the tests. In the beginning, I thought it is kind of redundant because if I commit some code, I will make sure there is no error, so why do we need another tool to do it again?
However after a while, I figured that actually I am wrong.
The reason why continuous integration is significant because different user may have a different environment setup. For example, person A commits something which depends on a class file he just created. When he is doing SVN commit, he didn't commit the new class file, because Tortoise SVN does not check non-versioned file automatically. In that case, although the code works well with person A's environment, it will introduce errors in any other user's environment. Now we need some kind of tool to prevent this sadly scenario.
For our WattDepot Client project, we used Hudson for continuous integration. Hudson is an open source software that supports continuous integration. It has a simple and clear user interface. You may set up a build schedule for your project. Then it will download your project and try to build it according to the schedule you set, like a batch program. All you need to do is to include a hudson.build.xml in the Ant build system. You may also want to leave the project discussion email address, so that Hudson will send a report email once it fails building the project. I believe all of these will facilitate group project dramatically.

WattDepot Client and Working in a Group

Last week, we started on a new project: "WattDepot Client". This is a client program that retrieves data from the WattDepot server. The task for us is to implement a command-line style user interface and the system, which reads and processes the command. Following are the commands that the client should be able to recognize.
2.1 help
2.2 quit
2.3 list sources
2.4 list summary {source}
2.5 list sensordata {source} timestamp {timestamp}
2.6 list sensordata {source} day {day}
2.7 list power [generated|consumed] {source} timestamp {timestamp}
2.8 list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}
2.9 list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}
2.10 chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}
As you can see, there are a lot of things to implement. The good news is that we are not building from scratch. We have the code for the command-line interface and also some libraries that will make life easier.
I was assigned to the Umikumakolu team. My partner George is a very talented program er. I learned a lot of thing from viewing his code and he always can help me out when I had a problem.
Finally, we successfully finish the WattDepot Client development. We break up the work according to our skill of programming. We analyze the problem, and figure that the command with a lower number tends to be more trivial. So we decide that I will work from the front while George will work from the back, and we should be responsible for testing the commands that we wrote.
I think the whole development went through pretty smoothly. We had a daily meeting during the weekdays. In the weekend, we emailed our status to each other. I really enjoyed pair programming. I think pair programming gives me more motivation and I write my code more carefullly because I know my partner is counting on me.
I hope we can have more group project in this class.

Make My Robocode Open Sourced

Most of the time when people try to accomplish a complicate task, they need collaborate with other people. For example, you may know exactly how to build an Egyptian Pyramid, but you can never finish it alone. Therefore, it is very important to learn the art of collaboration. In software development, the tool that help people to collaborate is called version control program. This time, I will share my experience of using subversion(SVN) and Google Project Hosting.

Google Project Hosting is a free place that you can use as a repository. To start creating a new project, you need to have a gmail account. Once you log in, you can create a project with a project name you specify. Then you can put some summary and description for your project. The description is formatted in Wiki markup format. It has some tutorial on line and it is pretty straight forward. Then you can start inviting your partners to this project.

You might realize that there is no source code for your project yet. Yes, you need to use an SVN client to export your code into the on line repository. What I did is I downloaded and installed the TortoiseSVN on my machine (I use Windows), then I restarted my computer. Because TortoiseSVN is integrated within the shell, you can just right click on the project folder and go to TortoiseSVN and choose "Export". Then you need to type in the URL of repository in the text box and click "OK". After authentication, SVN client is going to upload everything in that folder to the on line repository and you will find your code if you click "Browse" in the "Source" tab in the your google project. If you partners need to work on your project, they can do a SVN Checkout and they will have a copy of the project locally.

Now, the most important thing is done. Later, you may want to create a google group for discussion of your project and put some wiki pages in your project as documentation.

SVN is a really important tool that facilitates a large project development. People can check out the source and work on their own. After they finished their part, they can submit the change and SVN will help to merge them together. If there is a conflict occurred, SVN will point out the difference and ask developers to figure it out. I cannot imagine how much time and effort in project development are saved from version control.

Yichi's Quicky Quiz

Here are some quicky quiz questions that I think may be asked in the mid-term.

1. When you start software development, which editor you want to use, wordpad or Eclipse? Why you choose it?
- Use Eclipse because wordpad is not an IDE. IDE is very important in software development. It helps developers understand the system hierarchy better. It also shows syntax errors which saves lots of time locating the problem. It also supports for testing, debugging and refactoring.

2. Name two new features of Java 5 comparing with C?
- In Java, parameters are always passed by value.
- Java supports basic collections

3. Implement the FizzBuzz program in Java. FizzBuzz program should print out all of the numbers from 1 to 100, one per line, except that when the number is a multiple of 3, you print "Fizz", when a multiple of 5, you print "Buzz", and when a multiple of both 3 and 5, you print "FizzBuzz".

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

static String GetFizzBuzz(int n){
 if(n%3==0&&n%5==0){
  return "FizzBuzz";
 }
 else if(n%3==0){
  return "Fizz";
 }
 else if(n%5==0){
  return "Buzz";
 }
 else{
  return Integer.toString(n);
 }
}
}

4. Design three unit test for the FizzBuzz program.
-Test 1: Make sure GetFizzBuzz(3) return "Fizz"
-Test 2: Make sure GetFizzBuzz(4) return "4"
-Test 3: Make sure GetFizzBuzz(5) return "Buzz"

5. Why coding standard is important for a program?
- Code standard is important because it improves the readability, understandability, and maintainability of the code.

6. When you create a class in Java why you want to override equals method and hashCode method most the time?
- Because the default implementation for equals method and hashCode method might not be correct for your class.

7. What is the advantage for using Ant? Briefly describe how would you write an Ant build system for a program.
Ant has a file-level dependency management and it has built-in support for Java and simplifies cross-platform Java development. To build a system, you need to define a default target which ant will run first. Then you may want to use IVY to get all the third party libraries that used in your system. Lastly, you need to include all the code that need to be compiled.

8. What are the advantages and disadvantages for manual quality assurance and static quality assurance?
-Manual QA can detect some logical problems, but it takes time to write lots of customized tests. Static QA is to use some existing tools such as FindBugs, they mostly check for some simple problems such as an unused variable.

9. Why configuration management is important for a project?
Configuration management helps developers back track the changes that made to the system.

10. In case you run into a problem in question 3 (For example, you don't know how to print "FizzBuzz"), and you want to ask other people for help. how would generate ask your question:)
Hi there, I am working on a FizzBuzz program(discribe FizzBuzz). I can print "Fizz" and "Buzz" but I cannot print "FizzBuzz" when the number has a factor of 15. Here is my code:

static String GetFizzBuzz(int n){
 if(n%3==0andn%5==0){
  return "FizzBuzz";
 }
 else if(n%3==0){
  return "Fizz";
 }
 else if(n%5==0){
  return "Buzz";
 }
 else{
  return Integer.toString(n);
 }
}

Any Comment?

Play around with Junit~~

After applied some automated QA tools (CheckStyle, PMD, FindBugs) to my robocode project, it is also important to write some tests manually to assure my robot works correctly. This time, I created total six tests for my project, including two acceptance tests, two behavioral tests, and two unit tests. Here is a list of my tests.

Acceptance tests:
1. check if my robot can beat SittingDuck 10 times out of 10 battles.
2. check if my robot can beat Walls more than 5 times out of 10 battles.

Behavioral tests:
1. check if my robot ever visited the four corners in the battlefield during 5 battles.
2. check if my robot ever fire at SittingDuck and hit SittingDuck during 5 battles.

Unit tests:
1. check if the calculation for robot heading given the start position and target position is correct.
2. check if the calculation for normalizing angles is correct.

In my case, acceptance test is the easiest test to create. It only checks the "strength" of the robot to make sure it fits in some requirements. Unit test is a little bit harder to create, because it depends on the complexity of the unit that need to be tested. If the unit is relatively big, it is nice to break it down to pieces and write unit test for each pieces. I think the behavioral test is the most challenging test to create. For example, I tried to write a detail test for my robot's firing strategy. The firing strategy is determined by the robot's sensor. However, in a battle, we cannot tell when, where, and how robots see another robot unless we set the initial positions for all the robots. Therefore, it is very hard to test a specific behavior at a certain point of time. The most we can do is track if the robot ever made certain movement during a period of time.
After creating the test, I used Emma to check the coverage of my tests. 59% of lines of code are tested which is a acceptable number since there is only 6 tests. However, I think, to be a solid test, more than 90% of lines of code should be tested. I think test case is an important way to ensure the quality of the project, especially for a large system. Test is like a documentation for the system. It helps developers to mentain the system in a more efficient way. Also, developers can even develop the system by writing tests.

Here is my latest code with all the tests:http://www2.hawaii.edu/~yichi/robocode-xyc-yichispecialbot-1.1.1007.zip

It's time to package!

To deploy a software, it is always nice to have all the files packaged together. We don't want to look around for some third party libraries in order to run the code successfully. Organizing the dependency in a software project is quite troublesome unless using Apache Ant build system. Developer can define different tasks in an Ant build system. All those tasks are coding in xml files, which is kind of neat and structured. In addition, it can integrate the Apache Ivy so that it will check and download the missing third party libraries automatically during a build.

Another issue I was working on recently is quality assurance. Quality assurance is a critical part in a software development. However, mostly people can get really bored by working on some tasks like that. Is there any tool that can somewhat automate this procedure? The answer is yes! There are plenty third party tools designed for automated quality assurance. Here are three popular tools: CheckStyle, PMD, FindBugs.

CheckStyle -- will check the coding standard for you. It can be really helpful if you want to make the code clean and readable.
PMD --------- will check the syntax problem of the code. For example an empty block for a catch statement.
FindBugs ---- will check how the code works. It will try to find the part that make no sense and consider it as a potential bug.

All these tools are very user friendly. Every time after checking, they will generate reports in html so that developer can check the result quickly. The first time I run those tools on my robocode project, I got 132 errors for CheckStyle which means my coding standard is poor; and I got 3 warnings for PMD which is about reassigning a value to itself (I think this one is acceptable); and I got no bug for FindBugs. It take me about 10 to 20 minutes to fix those problems. I think it is much faster than checking the code manually.

I adapted Ant to my robocode project. The new robocode build system is available at:
http://www2.hawaii.edu/~yichi/robocode-xyc-yichispecialbot-1.1.930.zip

Let's fight smartly

After working on RoboCode for a week, it is the time to start implementing my own strategy. This time, I will try to create a robot (YichiSpecialBot) that can beat the sample robots (Crazy, Corner, Fire, Sitting Duck, Spin Bot, Ram Fire, Tracker, and Wall) that come with the robocode package. Following is my strategy.
1.Movement
To win a battle, you have to survive first. Movement is a very important part in the battle strategy. After playing around with the sample robots, I figure that "Wall" is the one that can survive most of the time. Why it can survive? I think it is because Wall is moving constantly so that it can dodge the bullet effectively. Therefore, I am going to use the same strategy as Wall. However, if I do the exactly same as Wall, I probably cannot beat it. Instead of moving on the edge of the battlefield, I decide to make my robot follow the diagonal of the battlefield if it is moving horizontally and follow the edge if it is moving vertically. In this case, when my robot played against the Wall, it can reach the corner earlier than Wall so that it can set an ambush.
2.Targeting
Since my robot keeps moving during the battle, it will not try to track any enemy. It will fire at any one it scans. However, At the beginning of each turn, it will turn the gun a little bit so that it can scan a different area. Also if it hit by another robot or bullets, it will turn its gun to the direction that the event happened.
3.Firing
It is not smart to fire all the time. I set my robot only fire if the enemy is within 500 pixels and fire hard if the enemy is within 100 pixels. I also tried to implement a perdicting function in my robot so that it can perdict the enemy movement according to the distance of the enemy, heading of the enemy, and the velocity of the enemy, but it does not work properly so far:(

Testing Result for YichiSpecialBot (10 battles):
vs Sitting Duck: 10 wins
vs Crazy: 10 wins
vs Fire: 10 wins
vs Corner: 8 wins
vs Ram Fire: 4 wins
vs Tracker: 7 wins
vs Wall: 7 wins
vs Spin Bots: 7 wins

The result is reasonable. It can reliablly beat Sitting Duck, Crazy and Fire. It has some advantages when fighting with Corner, Wall, Tracker and Spin Bots. It does not work well when fighting against Ram Fire. I think the problem is my robot does not run a way when hit by a robot. Therefore, Ram Fire can take advantage because it is design for short distance battle. I should probably find a solution to that later on.

Here is my code for YichiSpecialBots:
http://www2.hawaii.edu/~yichi/xyc.YichiSpecialBot.1.0.jar

Dig into the sample Robo

In the robocode package, there are plenty sample robots. Before implementing the battle strategy for a robocode robot, it is a good thing to take a look at those sample robot. Here is some analysis done by me. I will focus on three aspects: movement, targeting, and firing.
1. Corners
-movement: Corner bot will move to a corner at the beginning of the battle and stay there until battle is over. If there are more than 75 percent robot still alive when it dies, it will switch to another corner.
-targeting: It will not target any robot while moving. When it sits down, it will turn the gun to the left first. If the gun has been turned for 90 degrees, it will change the direction of turning the gun. No target locking involved.
-firing: It will fire different bullet according to the distance and its energy. If it is weak fire or the enemy is too far away, fire a small bullet. If the enemy is within 200 pixels, it will fire a middle bullet. If the enemy is within 50 pixels, fire a big bullet.
2. Crazy
-movement: Crazy bot will move and turn at the same time. The first time, it will turn 90 degrees then reverse the heading. However, the rest time, it will turn 180 degrees then reverse.
-targeting: It does not move radar or gun. It is always watching the front side of itself. No target locking involved.
-firing: It always fire the same size of bullet.
3.Fire
-movement: Fire bot will only move when it is hit by a bullet. It will move back and forth within a certain distance.
-targeting: It will turn the gun around slowly. If it sees another robot, it will fire. No target locking involved.
-firing: It adjusts the power of bullet according to the distance and its energy. If the enemy is within 50 pixels and the fire bot's energy is more than 50, it will fire hard. Also if it is hit by another robot, it will fire at that robot at once.
4.Walls
-movement: Wall bot will move to the wall at the beginning of the bettle. Then it will keep moving from corner to corner.
-targeting: It does not move radar and it keeps the fun pointing to the front. It will fire whenever it finds another robot. No target locking involved.
-firing: It fires the same bullet all the time.
5.Tracker
-movement: Tracker bot will not move until it finds it target. Then it will move towards its target. If it is too closed to the target, it will move back a little bit.
-targeting: The direction that Tracker bot will turn its gun to depends on how many turns it has tracked for its target. If it does not see its target for 10 turns, it will start looking for a new target.
-firing: It will only fire when an enemy is really close or it is hit by another robot. It never fire at some robot that is more than 150 pixels away.
6.SpinBot
-movement: Spin bot will move and turn at the same time. It basically keep moving on a circle route. Only turn a little bit if it hits another robot.
-targeting: It does not move radar or gun. It is always watching the front side of itself. No target locking involved.
-firing: It fires the same bullet all the time.
7.RamFire
-movement: RamFire bot will keep turning until it detects an enemy. Then it will move towards to that robot and try to run into that robot.
-targeting: It does not move radar or gun. It is always watching the front side of itself. No target locking involved.
-firing: It only fires when it hit a robot. The bullet power that it fires depends on the target's energy. It will try to fire a bullet that contains a weaker energy than the target. Then move ahead and try to crash the target by using its body.
8.Sitting Duck
-movement: Sit...
-targeting: Never mind...
-firing: I am just a peaceful little duck sitting in the battlefield...

As a summary, I think all of the bots I listed above are sample bots. They basically adapt a simple strategy. However, I think there is one principle for this game that will help all kinds of strategy: "Fire hard and fire carefully".

Is Coding Standard Necessary?

Last week, I worked on refactoring my code. One major task was adapting the coding standard. After gone through the coding standard, I realized that most code I wrote before did not follow the standard. It is because most of the time I just code by myself, and I don't think other people will ever try to take a look of my code. In that case, no matter how I write the code, it should be easy for my to catch on later. However, it does not work that way. Sometimes when I work on a complicate program, it took me quite a long time to understand the code, even though it is written by me. I think keep the code in standard is seriously important. It will make the code more readable and more organized. The most important thing is that it will bring you a good mood while coding. I used to work on debugging some old code. When I saw some messy code, I just felt so exhausted and desperated. Usually, that is a pretty bad thing:(

I agree with most the standard, but there are several rules that I am not so sure. The top thing bothers me is puting the open brace at the end of the line. I really see no differece between putting the open brace in a new line. To me, putting the open brace in a new line seems more organized and easy to read.

Anyway, I think it is a good time to start following the coding standard. Although you might need some extra efforts to made the documentation, it will definitely pay you back in the future.

Here are the links that put my new RoboCode source code: http://www2.hawaii.edu/~yichi/RoboCode-YichiXu.jar
http://www2.hawaii.edu/~yichi/RoboCodeXYC.zip

Go Robo~

In the past week, I was working on some basic functionality in RoboCode. The RoboCode system is very cool. I can debug without re-run my code. All you need is simply pause the current battle. Then when you press the "restart" button, all the change in the code will be applied. That's very amazing to me.

I worked on moving, tracing and aiming for a robot in Robocode. The Robocode Documentation really helps when you trying to do some warm-up program. The Robocode API is quite powerful. However, I think it should contain some methods that will get the direction to a point in the battlefield. Right now, I have to use Java.Math.atan method to find the angle that robot should turn. Also it is very accurate since too many number processing going on. Therefore, I still working on how to make a robot move circularly properly. Right now, I make the bot move in a square route:( I think it is so hard to move in a round circle because if you want your bot move at 1 pixel per turn (as small as possible) and you turn 1 degree per turn (as small as possible again), it is just too slow.

Another issue in Robocode is scanRobotEvent. This class contains the method that will return the distance between two robots. However, in my understanding, it looks like this scanRobotEvent does not happen continuously to one robot. For example, bot A saw bot C. As long as bot C is within bot A's sight, scanRobotEvent does not occur. If that so, how does it update the new distance etc.?

Over all, Robocode is a very nice project to work on. It can be simple or complicate. I enjoy the most from Robocode is the satisfaction after I see my robots working correctly:)

My RoboCode source code is available at http://www2.hawaii.edu/~yichi/RoboCodeXYC.zip

FizzBuzz

Writing a program for FizzBuzz is a quite relaxing program practice. It takes me about 1o minutes to finish this task. Out of this 10 minutes, I spent at least 6 minutes in creating a new project in Eclipse:(

When I first time started Eclipse, I was shocked by the "user-friendly" interface of the Eclipse welcome page. It has some icons, but I cannot find any icon for creating a new project. Therefore, I had to look carefully so that I can successfully click on the "file" button on the small menu bar to start a new Java project. Maybe the next version for Eclipse IDE will have a simple start page instead of an abstract welcome page.

The start up for me is not very smooth, but the environment is very friendly. It provides helpful hints if there is something unusual in the code. With such facility, I can write my code more efficiently.

Basically, this is my experience about writing a FizzBuzz program in Eclipse.

Here is my code:

public class FizzBuzzClass {

public static void main(String[] args){

for(int i = 1; i <= 100; i++)

{System.out.println(GetFizzBuzz(i)); }

}
static String GetFizzBuzz(int n)

{

if(n%3==0&&n%5==0)

{ return "FizzBuzz"; }

else if(n%3==0)

{ return "Fizz"; }

else if(n%5==0)

{ return "Buzz"; }

else { return Integer.toString(n);

}

}

}