Midterm

The following questions, I think would be good for a midterm:

1) What are the pros/cons of Code Review and Automated Code Assurance? Why do we need both?

2) What event would you need to override in order for your Robocode Robot to react appropriately to hitting a wall?

3) What is the main principle of The Principle of Least Astonishment (found in The Elements of Java Style)?

4) What feature was added to Java to make dealing with primitive data types easier?

5) What JUnit method would you use to test if an object is equal to its expected outcome?

Sounds pretty good if I could say myself.

Version Management

The only thing that's constant is change. That holds for life and for programming, as well. As programs get more and more complex, the more they need to be maintained. Even if you debug your code and release a perfect product, it's likely that you will want to make a change sometime in the future, a new feature or an overlooked security issue, for instance. Version Control is akin to an assistant that keeps track of every change you make to your code to assure that each change you make to your code is logged and kept track of. Acting like save points in a videogame, version control makes it obvious what changed and allows you to revert your code to a previous version if needed.

As a requirement for one of my classes, we had to use Subversion along with Google Code to host our robocode project (the result can be found here.) Having experimented with Git while working with Heroku, Subversion came intuitively to me. Both have command-line and gui interfaces, though with linux the command-line is really the best way to go about your files. With Subversion, you can make changes to your local directory that subversion will note to change on your remote server. It's easy as 'svn commit' when it comes to updating your source. To upload your code to a remote server is easy, too, as 'svn import URL' allows you to import your base directory to the path, assuming that the path is configured for subversion management.

The only thing I miss from git is an easy-to-find ignore list like .gitignore, but for the purposes of uploading a robocode robot to google project, interfacing directly with the folder proved just fine (though it resulted in way more versions than I had planned.) Other than that, managing versions of your software is easy as import, edit, commit.

Robocode: Lessthan20charsyeah

Due to time constraints I shall skip right to the nitty-gritty:

Design

I wanted my robot to keep its distance while trying to track its opponent. Upon being hit with a bullet, it tries to avoid it by alternating movements. What resulted was something like a cross between Walls, Corners and MyFirstJuniorRobot. It scales the walls until its at a certain distance from the enemy, then it scans and tries to shoot at the enemy. If it gets hit by a robot, it turns inwards and travels far, and if it gets hit with a bullet, it tries to avoid it by zig-zagging or going further up the wall, depending on which stage its at.

Robots that Lessthan20charsyeah can regularly beat (in a test of 5 rounds)

- Corners (5/5)
- Crazy (5/5)
- Fire (5/5)
- MyFirstJuniorRobot(3/5)
- MyFirstRobot(4/5)
- RamFire(4/5)
- SpinBot(4/5)

Testing:

- Acceptance Testing:
My goal for the robot was to keep away from close robots and to dodge bullets. As such, I picked two robots to do acceptance testing on, Corners, since it picks a corner tracks a robot, and RamFire, since it tries to track and get as close as possible to the robot as possible. Lessthan20charsyeah has an acceptance rate of greater than 80% (more often than not it is 90%) which, in the my view, is sufficient enough for a competitive robot.

Behavior Testing

Due to time constraints I was able only to test the robot's ability to keep ones distance. I calculated the distance between the robot and RamFire for a typical battle. I tested to see if my robot was able to keep a distance of more than 200 for more than 70% of the time and it came out to be successful. Such, it does an acceptable job of keeping its distance.

What I learned:

I learned the importance of testing and documenting. More specifically, that no matter how imperfect a product is, it pays off to test often and test early. Testing takes up a lot of time and such one shouldn't try to fine tune a product and leave no time for testing. The documentation would be incomplete, giving the client less than perfect confidence in the correctness of the product.