Sunday, October 18, 2009

Turning Knowledge Into Questions (Update)

When reading to understand, it takes a while before the full concept is realized. You must first do the initial reading, taking a moment or two at difficult points, digest the material, then review. The real test to see if one fully understands the material is if he/she can create questions based on the reading that isn't easily found just by skimming.

This is just the case for this week's assignment for my Software Engineering class. This blog post contains 10 quiz style questions that will help me and fellow classmates study for the upcoming midterm. Each student will come up with their own questions and by the end of the assignment, we will have a diverse array of questions to study from.

Topics range from the initial FizzBuzz program, multi-tasking, Java concepts, Build technology, testing, Ant, and Configuration Management.

I will amend this post with the answers later on this week.
Answers are here!

Here goes:

FizzBuzz + Anti-Patterns
1) How would you test the correctness of the FizzBuzz program?
A: You essentially want to create a unit test that tests the boundaries and the conditions that print "Fizz", "Buzz", and "FizzBuzz", namely 1, 3, 5, 15, and 100.

2) What would be a Happy-path test for the FizzBuzz program?
A: Happy-path test would be creating a single unit test that would always test a single value, let's say 1, and always return 1, causing the test to always pass.

Three Prime Directives
3) How do the Ant .xml files in the robocode-pmj-dacruzer system satisfy the Three Prime Directives?
A: The build files included allow for automated quality assurance/distribution which is a very useful tool to alleviate the tediousness of importing foreign projects. The fact that it's coded in Ant and automatically downloads necessary libraries it needs to successfully "build" a system ensures that an external user can install and use. The .xml files are direct source code which users edit, and there's also the online API for Ant.

Coding Standards
4) You created the ultimate Robocode robot that can beat any opponent, why would ensuring your code be up to standards be necessary?
A: The ability to beat another robot does not ensure readability or the ability for another user to adapt code. When you need to isolate a specific portion of code to test, have you're code could be a mess and probably would have to re-structure you're code in order to do so.

Quality Assurance
5) Your code has passed automated tests Checkstyle, PMD, FindBugs, why are automated tests not enough to ensure quality code?
A: These sorts of tests are only ensure that you're program follows standards and runs. It in no way can test the validity/correctness of your program. You will need to create an array of tests to accomplish this.

Asking Questions, Getting Answers
6) You're having trouble getting your JUnit tests for Robocode to work in Eclipse. You keep getting the error "robocode.jar not found." Given this problem, write a question in good form, you may make-up any other specific details that will aid in the diagnosis of the problem.
A: Hello, I've been trying to get my unit tests for a Robocode project to work in Eclipse, but I keep getting the error "robocode.jar not found." I've tried searching the forums to see if anyone else has this problem, but so far no one has. I'm sure I've setup my VM-arguments correctly (-Drobocode.home=) when I "Run As". I'll greatly appreciate any help/insight. Thank you for your time.

Understanding Ant Code
7) Given the following Ant code from checkstyle.build.xml:



What does it do?
A: Creates a target for checking if "checkstyle" has already been installed, if "checkstyle.config.available" does not exist, then Ant will download the necessary files from "src" url into the "dest" fo
lder giving it a timestamp.

8) Write a simple Ant statement that checks if the file robocode.jar is available in the path ${robocode.pat
h} and give it the property robocode.available.
A:


Version Control
9) Given an example where pessimistic locking is preferred, then give another example where optimistic locking is best. What does this tell you about which Version Control System to use?
A: Pessimistic locking only allows a single person to checkout a file, and places a lock while until it's been checked back in. Optimistic locking allows for multiple check outs and only places a lock when a person check's it back in with updates. On web based project or a large development team, you would want simultaneous check outs to facilitate work, so Subversion might be the right tool to use. However, if strict updates need to be kept, and you're in a small team of maybe 2/3, pessimistic might be feasible, so Revision Control System (RCS).

Open Source
10) What's the different between Free Software and Open Source Software?
A: Free software doesn't need to make its source code available and modifying and distributing the program is not necessarily allowed. Open Source software makes it source code available and modifying and distrubting the software is allowed.

How did y'all do? ^o^

Tuesday, October 13, 2009

Creating a Google Home: StrafeNShoot Repository

When working in a software development team where a group of people are working on the same project, version control becomes a key element in maintaining the most current, up-to-date distrubution of a software. Constant updates have to be taken in account so that a developer does not end up making a change that has already occured.

For this week in my Software Engineering class, we learned about Configuration Management(CM) and Version Control Systems(VCS). We were to use a specific type of VCS, namely Subversion(SVN). Since the version of SVN is dependant on your Operation System, I used TortoiseSVN on my Windows XP. In combination with the previous assigments that dealt with Ant and Build, which made distributions easy to package, distribute, and unpackage, SVN allows access to an online repository for my Robocode project StrafeNShoot, and any modifications made to the StrafeNShoot project SVN updates and commits the actions to the online repository.
The online repository we have used is Google Code, Google's developer network of open source projects.

My personal Google Code repository can be found here.

It currently stores the most up-to-date version of StrafeNShoot, summarizes the robots strategy, and contains two Wiki pages that show the User Guide and Developer Guide. You can either download the .zip format of the distribution, or can Checkout the project using SVN.

Note: Anyone can Checkout the project Anonymously, but if you would like to be a Project Member and/or commit or receive update notifications, I will have to add your Gmail account to my project. If you would like to be added, feel free to e-mail the discussion group at robocode-etm-strafenshoot-discuss@googlegroups.com

Along with Google Code, I have created a Google Discussion Group for my Google Code Project. All updates to StrafeNShoot are automatically posted in the discussion for everyone to see (including non-developers). This allows developers and others to see updates that have been going on and where the project is headed.

This weeks assignment details can be found here.

I've completed all the tasks except the known issue of the codesite-noreply@googlecode.com to the discussion group. However, I did get a workout this and instead added my Google Code project URL, robocode-etm-strafenshoot@googlecode.com to my discussion group. Then add the group's discussion e-mail (robocode-etm-strafenshoot-discuss@googlegroups.com) to the Activity Notifications in the Admin Source page of the Google Project, this allows for the updates to be e-mailed to all the discussion group members.

The most difficult task I found was using SVN. After installing SVN, you don’t actually open SVN the program, but use the Right-Click menu in the repository folder. The order of steps to use SVN was unintuitive at first. After modifying any of the files in my project, I had to first "update" the repository, then “commit” the actions. Remembering/re-pasting my Google Code project is a slight pain, but manageable.

I did accidently activate the "Adult Content Warning" when creating my Google Group. I inadvertently checked it off thinking it said that "My group does NOT contain any Adult Content". I looked through Google Group's help site, but found that only Google Administrators are able to change my Content Policy. I've posted my request on the site hoping they'll soon change it. I learned my lesson in that I should read carefully before checking off options that involve “Adult” and “content”.

Google Groups help was also useful in looking for known issues such as codesite-noreply, and already existing cases of accidental “Adult Content” activation.

Wednesday, October 7, 2009

Verifying StrafeNShoot's Strategy: Failure

The topic for this week in my Software Engineering class was about building test cases using JUnit and verifying certain aspects of my robot, StrafeNShoot. The aspects in question for movement, firing, and targeting strategies.

Here's a quick recap of StrafeNShoot's strategy:

Movement: Moves in a four corners style, starting from the upper left, lower right, upper right, then lower left. I chose this movement pattern because although it doesn't seem random, it provides a good path for my robot to always be in motion.

Targeting: The gun is initially positioned at the rear flank of the robot as it moves. When StrafeNShoot sees another robot, it attempts to keep an active lock on the target, while still maintaining it's movement patter.

Firing: As long as there's an enemy in it's sights, fire at will.

The assignment details can be found here. We were to create 6 test cases, at most 2 of them could be acceptance tests, which merely checked to see if StrafeNShoot could consistently beat another robot; behavioral tests, which tests the movement, targeting, and firing strategies; and lastly unit tests, to verify that the output of these methods were correct.

Sadly, I was only able to create 2 out of the 6 requried for the assignment, 2 of which acceptance tests.

The easiest of the tests were obviously the acceptance tests, mainly because Prof. Johnson had already included such a test in his pmj-dacruzer file which was easily adaptable, but also there was no real calculation involved, nor did I have to modify the source code of StrafeNShoot.

When it came time to implement a test for behavors, I began thinking of how I could test if StrafeNShoot does in fact move to the four corners. I then realized there was no concrete test I could do that would test for this, as StrafeNShoot "attempts" to move in the four corners style. It's possible that throughout the entire battle that StrafeNShoot will never reach a corner, since the way I coded the movement, if StrafeNShoot runs into another robot, it immediately attempts to go to the next corner without reaching the one it was trying to get at.

As for unit tests, it was hard to think of a solid unit test that I could use. The main problem with the unit tests was that I could not find a way to directly access StrafeNShoots internal variables. The trigonometry I used to calculate to turn to a corner, which would have been an ideal choice to verify, was hard coded into StrafeNShoot's source code. And the only way for me to verify the angle was correct, was by using the exact same steps I used to calculate the angle in the first place. There were other issues such as verifing that StrafeNShoot would correctly calculate the angle to turn towards the enemy.

With my test cases seriously lacking, I can firmly say that my test cases do not adequately ensure the quality of my robot. Sure it has the capacity to beat other robots, but being able to verify it's strategy without actually watching the battlefield is a whole nother problem.

For my EMMA coverage, there isn't much to tell, overall my block coverage was 43% and line coverage was 55%. But I've uploaded the whole results, which can be viewed here.

When I first started working with Robocode, I had no idea that the analysis would get this deep, I thought that the only thing that matters was coming up with a unique strategy, and beating other robots. But now, even if you have a unique strategy, it can be a pain trying to verify the things it does. When I decided to implement my strategy for StrafeNShoot, I did not code in modules, or even think about refactoring certain pieces of code. It ran sufficient enough to not look twice. But after this week, it shows how much modules, organization, and coding with verification in mind can lead to a well documented, quality source code.

My distributed StrafeNShoot package with it's lone, 2 test cases, can be downloaded here.