Ant Code Katas

Building upon my last blog entry on the application of Katas on improving my programming, I applied this concept to the Apache Ant build system for Java. Although not my first time messing around with a build system, this is by far the most complex I've encountered. Similar to the Make utility found on most Unix-based operating systems, the Apache Ant build system automatically builds executable programs from source code and libraries.

For this particular build system, I worked on the following katas:

1. Ant Hello World
2. Ant Immutable Properties
3. Ant Dependencies
4. Hello Ant Compilation
5. Hello Ant Execution
6. Hello Ant Documentation
7. Cleaning Hello Ant
8. Packaging Hello Ant

Sparing the details for each kata (you can read about them here), each kata gets more difficult along the way. Funny enough, learning how to print words to the screen in Ant took a bit longer than expected. Unlike a programming language, it seems like the first thing the authors of a build system would like you to do is to actually use their program to build a system. I knew I had to enclose the "echo" task around what I wanted to print to the screen but to actually set up the script to do this took longer than expected. A quick Google searched revealed resources on how to do exactly this.

Next, completing the immutability and dependency scripts were pretty painless since the Wikibooks website also provided a good tutorial on those two concepts, however, I would soon hit a brick wall with the next three scripts. Out of the three, compilation wasn't too bad since the Ant manual provides a good basis on how to do this. On the execution script I would later find out the pain in trying to run a Java program using Ant. During this time I've probably went back-and-forth a few times deciding whether to follow the Apache model and JAR my HelloWorld program and execute the the JAR, or to simply find a way to execute the program without having to do this step. Finally, I found the documentation script to be a little simpler since I only had to be concerned with the location of the source files and the directory where I want to store the Javadoc reference files. Luckily, I had no problems with the clean and distribution scripts since I found the sample scripts from another build system distribution straightforward.

With these code katas I was able to dive a little deeper with just how complex build systems can get pass the compilation and execution stages. With the headaches I've encountered when trying to run other peoples Java implementations on my computer, it is clear how useful and in my case necessary to have a robust build system to accompany any software system.

Robocode Code Katas

Having no prior knowledge of what a "Kata" is, I took the time to read through the following articles to get myself acquainted with the idea of a "code kata".

http://en.wikipedia.org/wiki/Kata_(martial_arts)
http://www.codinghorror.com/blog/2008/06/the-ultimate-code-kata.html

The idea is sound. The only way I can get better as a programmer is to constantly challenge myself with harder sets of programming problems. Although I often find myself in an impossible situation when trying something new, I've always come out getting something out of the experience.

Applying this concept to Robocode, an open source programming game, revealed my limitations as a programmer and how the code kata concept can work seamlessly with any programming exercise. In this case, I challenged myself to thirteen exercises devoted to teaching me the basic fundamentals of a robot in the Robocode universe.

Position01: The minimal robot. Does absolutely nothing at all.
Position02: Move forward a total of 100 pixels per turn. When you hit a wall, reverse direction.
Position03: 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.
Position04: Move to the center of the playing field, spin around in a circle, and stop.
Position05: 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.
Position06: Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
Follow01: Pick one enemy and follow them.
Follow02: Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
Follow03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
Boom01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
Boom02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
Boom03: 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).
Boom04: 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).

My approach for this particular exercise was simple, and that was to use as little trigonometry as possible. For the Position robots, everything was fine until I got to the Position04 robot. Knowing that the robot will spawn at a random location on the map immediately caused me to retract my previous "no trigonometry" approach. But thanks to the power of Google, I found an IBM solution in the form of a sample robot called DwRotater found in the article detailing the Robocode basics.

http://www.ibm.com/developerworks/java/library/j-robocode/

DwRotater does exactly as what the Position04 specifications call for, that is, to move to the center of the playing field. I would also use the basic outline of the code and modify to send the robot off into the four corners of the map in Position05. But when it came to the Position06, the "no trigonometry" motto proved to be fruitless as I was not able to find a solution to move the robot in a circle.

The Follow robots proved simple enough by using the built-in functions to give a distance that allows the robot to close in on a particular enemy.

Finally, with the Boom robots things got interesting by experimenting with the firing mechanics of the game, Boom03 in particular because it shows how manipulating the values issued to the fire command will have on enemy tanks. Boom04 proved to also be a hard one since I was only able to track an enemy sitting still by simply rotating the gun in that direction.

With that said, I was able to complete most of the exercises by using no trigonometry whatsoever. Obviously not a smart decision since I'm sure most if not all of the elite robots are using trigonometry to do the more advanced stuff like evasion techniques or firing at the enemy on the move. To build a competitive robot I simply need to learn how to not get hit while still being able to fire effectively at targets. In general, the code kata approach helped by starting on an easy problem and gradually increasing the difficulty to get better at it.

FizzBuzz in Eclipse

FizzBuzz in Eclipse

The following article provides insight into the FizzBuzz problem presented to prospective computer programmers:

You Can't Teach Height - Measuring Programmer Competence via FizzBuzz

“Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers that are multiples of both three and five print “FizzBuzz”.

In retrospect, I did not expect to encounter any problems when implementing the FizzBuzz application in Eclipse. Having some experience with Eclipse over the years and a copy of my in-class solution to this problem, I was confident the application would produce the correct output on the first run.

Expected output for the first 15 numbers:

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz

Actual output from my implementation for the first 15 numbers:

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
Fizz

Obviously this wasn’t correct.

Without really thinking too much about the logic of the program, my checking conditions produced erroneous output as a result of the order I checked the value of number. By checking for numbers divisible by both 3 and 5 after checking for the values of 3 and 5, the application would print “Fuzz” for the values of 15, 30, etc. instead of “FizzBuzz”. By simply checking for the remainder of number and 15 as the first condition fixed this problem.



It took me 05:05.5 to complete the application with correct output, and 12:04.0 to finish writing in my comments.

Open Source Software and the Three Prime Directives

PDF Split and Merge http://www.sourceforge.net/projects/pdfsam/

Overview: PDF Split and Merge is a simple, easy to use, free, open source application to split and merge PDF documents. There are console and GUI versions of the application where the GUI is written in Java Swing. A variety of external libraries is utilized to deal with the manipulation of PDF files, XML format, and encrypted documents.

Prime Directive 1: The system successfully accomplishes a useful task.

A simple Google search on how to merge or split PDF documents will reveal a variety of free and paid solutions for the end-user. A browser-based solution, while free to some extent, is only limited to 15 MB files and offers no split functionality. A DIY method is available but only for Mac OS X users. With that said, PDF Split and Merge allowed me to quickly merge two existing PDF documents in less than a minute. Although the interface could be a little more intuitive, patient users will find the process painless by reading the manual that offers a how-to on merging and splitting PDF documents.

Prime Directive 2: An external user can successfully install and use the system.

The PDF Split and Merge website, http://www.pdfsam.org, has installers available for Windows and Max OS X, a ZIP archive, and the source code. The tutorial from the site describes that a Java Runtime Environment is required to run the application. A detailed explanation of each function in the system is available to help the end-user complete basic tasks such as Merge/Extract and Split.

Prime Directive 3: An external developer can successfully understand and enhance the system.

A Software Requirements Specification document is available at http://www.pdfsam.org/uploads/PDFsam-SRS-v2.1.0-EN.pdf. This developer-level documentation details the basic version of PDF Split and Merge that allows external developers to understand the system and to help improve it. A feature request tracker, https://sourceforge.net/tracker/?atid=814268&group_id=160044&func=browse, has a couple dozen suggestions to improve the system’s feature set. For example, this program is currently limited to merging exactly two documents at a time. Going through the API and source code shows a lack of descriptive comments; however the methods are named in such a way to help an external developer understand the program.

Three Prime Directives of Java-based Open Source Software Engineering:

https://sites.google.com/site/ics314fall2011/modules/introduction/three-prime-directives