5 Things ICS Students Should Know in Order to Pass the Midterm and Maybe Graduate One Day

Midterms are upon us, which means it's that time of the semester again. Sleep-loss is at a peak and attention spans are running dangerously low around campus. In order to protect ourselves against impending doom, my fellow ICS students and I have been working in collaboration to produce a study guide, to which I am contributing the following five questions.

1. When starting Ant, you can select which target(s) you want to have executed. What happens if no target is given?

A: When no target is given, the project's default is used.

2. What is one example of manual quality assurance techniques?

A: Writing units tests with JUnit. Conducting code reviews.

3. Why is manual quality assurance bad for finding low level code defects?

A: It is difficult/expensive for finding low level code defects. It must be redone for all projects.

4. In Java, when should you use Enumerated types (rather than, say, an ArrayList)?

A: Whenever you have a well-defined, fixed set of values which are known at compile-time.

5. What is the convention for naming packages?

A: Use reversed internet domain names as package prefix, ex. "edu.hawaii." Use a single lowercased word as the root name for each package.

Host with the Most

My beloved robot, BattleBot, who has been the topic of most of my recent blogging, has a new home on the interwebz. That's because I've recently created a Google Project Hosting site in his honor so that other, inferior robots may look upon him and become inspired by his awesomeness...

In all seriousness, the reason I did this was to gain experience with configuration management systems and subversion, neither of which I had ever used prior to this. After downloading the SmartSVN client and interacting with my subversion repository, I quickly realized how much of a "game changer" configuration management really is. Having worked on a few projects with small amounts of code in a group before, I know how hard it is to manage the sharing of files and how difficult it can be to track changes and stay in sync. Thankfully, subversion makes collaboration much easier. It was simple to set up and get running, and although there are some practices that I will need to get used to (running 'verify' before every commit, etc.), overall it really does make life easier.

One of the things that I really liked about the Google Project Hosting is the ability to track changes to the source code and even view the changes in the source code directly in a side-by-side view. The idea that if my partner makes a change, I can view that change without opening Eclipse or downloading any files is really nice. However, I was a little surprised that it also showed every change I made to the wiki pages as a revision as well.

Overall, I think configuration management and subversion are really going to be helpful once I start collaborating more with other students and working on group assignments. I think it will allow me to focus more on writing code instead of spending too much time emailing files and trying to stay in sync. It definitely relives some of the headaches that can occur when collaborating.

BattleBot Google Project Hosting Site: http://code.google.com/p/robocode-ajo-battlebot/

Robocode Competitive Robot

Over the past week or so, I've been creating my own competitive Robocode robot for an upcoming competition against other software development students. My previous blog posts have touched upon the basics of Robocode and build systems using Apache Ant, and the competitive robot is supposed to be a culmination of everything I've been learning about so far.

The bad news? I'm competing against grad students (shudders) as well as other undergrads, so my poor robot stands little chance of coming out of the competition in one piece. Especially if anyone adopts a strategy similar to the sample robot simply known as "Walls" (I never knew I could dislike a virtual robot as much as this one), who I am yet to beat with my robot that I've named "BattleBot."

With my robot, the first thing I tried to do was think about movement. I figured that sideways movement, or strafing, would be best for dodging enemy bullets. Thus, I programmed my robot to square off perpendicular to the other robot the entire time. Rather than moving each turn on its own, my robot only moves when it detects an "energy drop" (the enemy's energy level decreased from the previous turn), which allows it to dodge enemy bullets. The idea is that firing a bullet depletes a robot's energy, so we can use that information to guess that the enemy has fired a bullet.

In order to target the enemy robot, I simply built upon the movement strategy which I had already implemented. Because my robot is always squared off sideways to the enemy, I just turn the gun 90 degrees at the start, so that it's pointed at the enemy, and then lock the gun so it turns with the robot as it adjusts its position. That way the gun is always pointing at the enemy. This strategy works well against robots that don't use a lot of random movements. I tried to improve my strategy by using linear targeting to shoot moving targets, but my implementation was not accurate enough so I ultimately did not use the code.

Because my robot's gun is always pointed at the enemy, I decided to fire every turn if possible. My robot uses bullet power proportional to it's distance from the enemy in order to conserve energy (the farther the enemy, the less chance my robot has of hitting it). Also, my robot does not fire if its energy is below a certain level so that it doesn't run out of energy.

Of the sample robots included with Robocode, my robot can reliably beat all of them except for Walls. Against Crazy and SpinBot, my robot wins about eighty percent of the time (which I consider to be pretty reliable), and always beats RamFire, Fire, Corners, Tracker and SittingDuck. I think the reason my robot struggled against Walls was because it is always moving and my robot struggles with moving targets. The linear targeting strategy which I implemented improved my results against Walls but actually was worse against the more simple robots, so I eventually ditched it altogether.

In order to test my robot, I implemented six tests: two acceptance tests, one unit test, and three behavioral tests. The acceptance tests were used to verify that my robot could reliably beat some sample robots. This made the development process faster and easier since I could quickly test changes to my robot's behavior to see if they improved its performance against other robots. The unit test verified the output of one of the methods that my robot calls when it fires a bullet to ensure that it uses proportional power based on enemy distance.

The behavioral tests made sure that my robot behaved like I intended. For example, one behavioral test tested that the robot had moved when it detected an energy drop. Another tested the bullet power to verify that proportional power was being used in firing, and the last one made sure that my robot did not continually run into walls.

Overall, developing this competitive robot has really taught me a lot. I improved my skills in Java and Ant, became comfortable with build systems, wrote some tests for the first time, and become more familiar with the Eclipse IDE, among other things. This was a valuable learning experience, and I can't wait to see to what implementations my classmates have come up with for the Robocode competition.