Configuration Management and Google Project Hosting

    In order to streaming a software development process among a software team it is extremely valuable to utilize a  configuration management system, a way to control the development process when multiple software developers are writing/editing possibly interdependent code.  Without a configuration management system problems may arise during development such as inconsistant code among developers, no clear indication of when the system started or stopped working properly and what code was responsible, the problem of simultaneous updates which cause "clobbering"  aka only one persons code being uploaded and the shared data problem which arises when two developers need to work on the same file/data.

    Version control is a type of configuration management whose main goal is to maintain multiple versions of the system. Google Project Hosting is a version control system that uses Subversion, which is one of many different version control systems.  Subversion uses a central repository, or a complete and always up to date version of the software project that can be checked out, modified (on an individual basis) and committed(update change/s to repository) by developers.  Each commit made by developers is tracked by Subversion so that there is always a reference to each update in the system, which makes it easy to locate when and where an error occurred.  Subversion also prevents clobbering, by maintaing each developers version of the repository through updates,  and allows each developer to have a complete version of the system, which eliminates the shared data problem.


 

     Getting a project started with Google project hosing is relatively simple, you just have to give it a name, upload files to the repository, and provide supporting documentation for users and developers.  After that you are ready to start adding developers to the project.  Here is an example of  my first project through Google Project Hosting:

robocode-kmi-GreenMachine

      The above is the front page of my hosted project, as you can see we have a description in the text field of the project, there are multiple tabs at the top including downloads, wiki( aka documentation), issues and source.  If you wanted to check out this project you would do so from the source tab, if you wanted a distribution of the system you could find a .jar file under downloads. please feel free to explore this project to get comfortable navigating a Google hosted project.

  This is a project which contains my competitive Robocode robot.  Please see previous posts if you are curious to what that is:

Java fueled robots
and
GreenMachine

  Setting up a project in Google Project Hosting is straight forward, things that I found can tie you up a little would be the documentation, and making sure that the files in your repository are in the correct place.  A few of the small things can be a little confusing but everything you need to know for setting up an new project can be found here if you get stuck:

Getting Started

This is a free and powerful tool for team software development, and as a side note in order to properly use a Subversion system you need to have a Subversion client on your machine, this is the one I am using for Mac.

SmartSVN

How to use a Subversion client is a whole different topic.  You can use the documentation on the above website to get started.

GreenMachine ! Robocode robot

  I have just completed my first battle ready Robocode robot that I named GreenMachine!  If you are unfamiliar with the Robocode project you can read up on my previous post here:
robocode 

If you want to download a distribution of my robot you can find it on my site:
Robot Distribution

The creation of this robot was inspired by a upcoming Robocode competition among some of my fellow classmates, I wish them well.. but I believe that the GreenMachine will do well given the short amount of time given for development of robots for the competition. The GreenMachine is a robocode robot that extends only the robot class, not the junior robot or advanced robot, which means that there are a lot less built in methods to utilise.  Most of my robot is composed of original code except for one method I use to linear target robots that move in 90 degree angles, (such as sample.walls).  the design ideas that I implemented are as follows:

Movment:
   For my movement I could not think of a good way to avoid being hit except to be unpredictable... so what better way to be unpredictable then to use sporadic sudo random movements.   For my movement method I use a built in Java random number generator and generate a random degree between 0-300 and a distance between 75-100 pixels.  I chose to move such a short maximum distance per turn because moving in one way for any extended time will give an opponent a chance to preform linear targeting on my robot. This movement seems to evade a lot of shots, but we will see how it preforms in competition.  A way to improve on this move method (I didn't have the time to) was to eliminate the possibility of moving directly towards or away from the enemy, as this would not change you retaliative bearing in comparison to the enemy.

Targeting/Firing:
   For my targeting I continuously scan the field between moves and acquire a target.  Once my target is acquired I will shoot a bullet at their bearing with power retaliative to their distance from my robot (farther away less power).  If a shot hits its target then the overridden method onBulletHitEvent will immediately fire a mid-power bullet to the same X any Y coordinates that the first bullet struck the enemy, it does this after it moves just in case the enemy fire a retaliation shot in the direction it was struck by my bullet.  In the event that my robot comes close to the enemy, within 100 pixels, the GreenMachine will charge its enemy full speed and on contact with the enemy fire a shot with maximum power, this method of close combat seems to work great.  In the event that a robot is moving in 90 degree angles like sample.walls, GreenMachine will change its behaviour and use linear targeting to make shots that try and intercept the enemies future location.  This behaviour was used from
walls killer 
and was the only code in my robot that I did not write. Finally in the event my robot is hit by the enemies bullet I immediately fire a retaliation shot in the direction it came from then move.

Results of my Labor:
   GreenMachine can beat most of the sample bots reliably including Walls, RamFire, Crazy, Fire,  Corners, Tracker, SittingDuck.  It does have some trouble with SpinBot because it does not have a method for dealing with circular predictive targeting, therefore it wins about half the time against SpinBot. To improve on this I need to create a way of identifying robots that move in circles and devise a way to track them. 


Lets Take a Look: I suggest watching it expanded and in HD on YouTube.

Testing:
   For my testing methods, I used Junit tests to judge my robots progress by having 10 round battle results quickly evaluated for each of the sample robots.  This allowed me to quickly see the effect of any change I mad to my robot.  In addition to these battle simulations I also tested different methods of my robot such as my firing techniques and my robots responses to events such as impact with another robot and impact with walls.  I also utilised JaCoCo to see the coverage of my tests. 


Lessons Learned:
   I learned a lot from this project, I learned about creating a more advanced robot and how complicated robots can get.  I also learned a lot of valuable skill on how to use Junit tests to test a program as well as guide the progress of software development.  Throughout this experience I was utilising the Ant build system and therefore became very familiar with how the Ant and .xml files used in ant work.  Towards the end of the development of GreenMachine I was utilizing Ant + Ivy in an efficient way.  It has also become very clear to me the value of using a build system when developing software among multiple software developers.  From a software perspective I would become very familiar with my build system before writing any code, and from a Robocode developer perspective I would search every nook and cranny of the Robocode API before beginning development to save on time and effort.  I found that writing Junit tests after I began this project was difficult, If I could do it over again I would like to try the approach of writing my Junit tests before the code they are meant to test.

The Power of Ant

   The development of software on a larger scale, meaning there is some sort of development team, becomes difficult for many reasons. When attempting development with a team you will be dealing with multiple developers, possibly using multiple types of systems, with different development environments and the utilisation of third party libraries. So how in the world can you work together in an effective and efficient way? One option is utilising something called a build system, like Apache Ant:

  "Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications."

so what does that mean...

  It means that Ant uses files called "build files" to execute certain commands or tasks called "targets" whose purpose is to make the software development process better by creating/allowing usability and portability between different systems and developers. Ant provides a "unifying technology and set of principals for building any software system" (Johnson)

Download Ant at:
Apache Ant Home Page

In order to learn the power and utility of a build system like Ant I recently, and successfully, took on the "Ant code Katas". Lets take a look at these simple tasks that demonstrate and teach the Ant basics.  Below in a few of the katas I have added an image of my code to give an example of what a build file looks like.
                                                                             

1. Ant Hello World

Create a script called helloworld.build.xml.  Invoking this script via "ant -f helloworld.build.xml" should print out "Hello World".  The script consists of a single (default) target called helloworld with a single line that invokes the <echo> task to print out Hello World. 

2. Ant Immutable Properties

Create a script called immutable.build.xml.   This script contains two <property> elements, one of which assigns the property "my.property" to the value "1" and the second of which assigns the (same) property "my.property" to the value "2".  Now create a target called "printproperty" that uses the <echo> task to print out the value of the property "my.property".  

If done correctly, this script demonstrates that build properties are immutable: once they are set, their value cannot be changed. 

3. Ant Dependencies

Create a script called dependencies.build.xml.   It should contain targets called "foo", "bar", "baz", "qux", and "elmo".  Each target should consist of a single <echo> task that prints out the name of its target. The default target is foo.

The targets should have the following dependencies:

• foo should depend upon bar.
• bar should depend upon baz and elmo in that order.
• baz depends upon qux.
• qux depends upon elmo. 
• elmo has no dependencies.

Now invoke the build script using "ant -f dependencies.build.xml".   What is the order of targets. In particular, where is elmo called and why

Try invoking "ant -verbose -f dependencies.build.xml".   Note that Ant now tells you how it seriallzed the dependency structure.

Now make elmo depend upon bar and reinvoke the script.  Make sure you understand what happens.                                                                                        

4. Hello Ant Compilation

Create a file called HelloAnt.java, which contains a Java class called "HelloAnt" and a main method that prints out "Hello Ant" to the console.  This file should be in a src/ subdirectory.

Create a second file called compile.helloant.build.xml that contains a single target called "compile".  This target contains a single <javac> task that compiles the HelloAnt program.  You do not need Ivy.   You should be able to compile the program with "ant -f compile.helloant.build.xml".   These class files should be written to a build/classes subdirectory.

You may want to create src.dir and build.dir properties. 

5. Hello Ant Execution

Create a file called run.helloant.build.xml that compiles and runs the HelloAnt program.  It should use the <import> task to import the contents of compile.helloant.build.xml so you have access to those targets. 

Again, make this file as simple as possible. Provide a single target called "run", and make this "run" target depend upon the "compile" imported target so that the code is always compiled before being run. You should be able to compile and run the program with "ant -f run.helloant.build.xml".  

6. Hello Ant Documentation

Create a file called javadoc.helloant.build.xml that generates the JavaDocs for the HelloAnt program.  Once again, make this file as simple as possible; it can contain a single target called "javadoc" that invokes the <javadoc> task.  

The javadoc target should ensure that the HelloAnt program compiles, so you will want to import compile.helloant.build.xml   The javadoc html files should be placed in the build/javadoc subdirectory.  You should be able to generate the JavaDocs with "ant -f javadoc.helloant.build.xml". 

You can create a few properties to support the documentation process if you like.  You must ensure that the javadoc command completes without any warnings or errors.  This means you might have to improve your HelloAnt program!

7.  Cleaning Hello Ant

Add a target called "clean" to your compile.helloant.build.xml file. It should delete the build/ directory.

8. Packaging Hello Ant

Create a file called dist.helloant.build.xml.  It should contain a single target called "dist".   The dist target should have dependencies that compile, execute, and create javadocs for the helloant system (thus checking to make sure the system works correctly).   After all of these dependencies should be the clean dependency. 

The contents of the dist target creates a zip file containing the (cleaned) version of the current directory and all its subdirectories.  This zip file should be put into the (newly created) build/dist directory. Its name should be ant-code-katas.zip,  Unzipping this file should create a new directory called "ant-code-katas" which contains your ant kata files. 

To check your work, invoke "ant -f dist.helloant.build.xml".  Now cd to the build/dist directory, invoke "jar -xf ant-code-katas.zip".  This should create a new directory in build/dist called "ant-code-katas.   Now cd into that directory, and make sure that all of your kata files (and the src/ directory) are there, but that the build/ directory is not there.  Finally, invoke "ant -f dist.helloant.build.xml" in this directory. It should create a new build/dist directory containing yet another copy of ant-code-katas.

 Overall I have found that with a little practice Apache Ant is a very easy and powerful tool.  It is easy to imagine how necessary build systems like Ant are for certain kinds of software development.

Java Fueled Robots

  So you know how to program, your familiar with object oriented programming and you can write some fairly complex code, now where can you put your awesome skills to the test and have fun doing so?  How about designing the behaviour of a robot?
That sounds fun...
Better yet how about designing a complex, cannon wielding, slaying battle robot !
Now thats better.
   Robocode is an open source educational game started by Matt Nelson of IBM, you can get a good idea of what the game is all about here: ROBOCODE
Robocode allows you to design the look and behaviour of a battle robot, you can create anything from a simple robot that shoots its gun in the direction of an enemy, to one that utilises complex statistical analysis, your skill level is the only limit with these battle bots.  Well then, who do you get to battle and prove your superiority over given that you put your time and effort into making an effective killing machine? Robocode has a good sized online community where you can test your robots might against other programmers robots here: sourceforge 
  Okay so you are convinced and want to take on the quest of creating a robot capable of some mayhem, you need a starting point.  I would suggest starting the way I did, by completing the 13 robocode Katas.

Robocode Code Katas

1. The minimal robot. Does absolutely nothing at all. 
2.  Move forward a total of 100 pixels per turn. When you hit a wall, reverse direction.
3. Each turn, move forward a total of N pixels per turn, then turn right. N is initialized to 15, and increases by 15 per turn.
4. Move to the center of the playing field, spin around in a circle, and stop.
5. Move to the upper right corner. Then move to the lower left corner. Then move to the upper left corner. Then move to the lower right corner.
6.  Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
7. Pick one enemy and follow them.
8. Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
9. Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
10. Sit still. Rotate gun. When it is pointing at an enemy, fire.
11. Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
12.  Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss). 
13. Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).

  These katas are a great starting place to really get familiar with the robocode system (in my opinion katas are a great starting place for any new concept).  Once completed you will have a firm grasp of how to use all of the robots functions and have a good idea about how to start coding a battle ready robot.  I found these katas to be fairly basic only spend significant time on a few of them, why? because I had to remember my trigonometry !  You know... that class you took years ago and never found a use for... well, its back.  I was actually very excited to be able to use things like the distance formula and tangent lines for something practical.  The most difficult aspect of these katas for me was reviewing and figuring out applicable trig. formulas.

So now that you know what Robocode is I am sure you want to see it in action. 
Here are katas 7 and 9 together, no destructiveness but a funny demonstration of their respective behaviours: 

 Go get started with Robocode, I guarantee you will not be disappointed.

FizzBuzz In Java - 4 and 1/2 minutes

FizzBuzz is a simple program that prints 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".

Significance: 

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

http://www.hanselman.com/blog/YouCantTeachHeightMeasuringProgrammerCompetenceViaFizzBuzz.aspx


From the time I opened my IDE (eclipse) to when I successfully ran the FizzBuzz program took me right around 4 and a half minutes.  This is a very simple way to implement the FizzBuzz program, and it is not optimised for testing. I didn't run into any problems and had no coding errors during the process, this is mainly due to the fact that I had recently written this exact program about a week ago.  Most of my time spent writing this program actually originated from messing around with the IDE.  From my experience I would like to stress the importance of using a good IDE, because it will save you a lot of time in the long run, and being familiar with its functionality to avoid getting tied before you being a software project or during development. 

The Three Prime Directives of open source software

Overview:
  Open source software offers computer users an array of desirable features, including access to free alternatives to expensive software they would normally purchase, the ability to manipulate, customise, contribute and improve on software projects and the ability to develop and release ones own software.  As a open source software developer, especially if developing ones own open source project, there are no explicit guidelines or quality regulations to follow.  So how do we determine when a software system reaches a high enough standard to be considered "high quality"? The answer, The three prime directives of open source software.  The following will elaborate on each of the three prime directives using a randomly chosen open source application.

   The victim: http://sourceforge.net/projects/pdfsam

"Easy to use tool to merge and split pdf documents"



Prime Directive #1: The system successfully acomplishes one successful task.

   After I was able to start PDF split and merge I decided to test the first prime directive by testing the programs ability to accomplish its title.  For this test I simply created a directory containing a single two page PDF file.  I started the program and selected my PDF using the GUI as depicted below.  

After clicking the run button, the blue bar below loaded to 100 %.  when I checked my directory I found:

  Manoa classes.pdf is the original, and the other two are the first and second pages of the PDF accordingly.  Given the success of this test I would conclude that PDF split and merge can preform one successful task and therefore satisfies prime directive one.. and in case you are wondering yes, it also merges just fine.



Prime Directive #2:  A new user can successfully install and use the program


  After downloading PDFsam I unzipped and placed all of the files in a directory on my desktop.  I then tried to launch the program, unsuccessfully at first, using the directions to start the program without having to use the command line.  In my second attempt I followed the instructions to launch the program from the command line, and it worked just fine. 

 Given this we can conclude that depending on the user of the software it could satisfy prime directive two, or it could fail. If the user is someone who has enough expertise to know about the command line, then they should have no trouble starting the program, on the other hand if a novice user tried to launch this software it is unlikely they would be successful.

 In order to test my previous claim I had my not so tec. savvy girlfriend attempt to start PDFsam, to which i got these exact responses:

"I have absolutely no Idea what I am doing"
"Could you explain to me again what I am suppose to be doing"
"Can I just start clicking things?"

Given this trial I would conclude that in fact PDFsam would FAIL prime directive 2.

** note: software deployed on ubuntu **


Prime Directive #3:  A new developer can successfully understand and enhance the system.


  The source code for PDFsam was relatively easy to find and acquire, I was able to find a download for the source code at the owners home site http://www.pdfsam.org/?page_id=32.  After exploring all of the source files for a while I came to the conclusion that this software would be somewhat difficult to manipulate, of the code I looked over the comments and readability of the code was somewhat poor.  I was unable to find a code snippet that was thoroughly explained.  Given this initial impression I believe I would be challenged to participate in the development of this software. It should also be noted that I am inexperienced when it comes to navigating and manipulating open source software at this point in my education, once I become more accustomed to the use of open source software my analysis of PDFsam in respect to prime directive #3 may change.