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.