Tuesday, September 27, 2011

I'm terrified of bugs but Ant just might change my mind

I am. I truly am terrified of bugs. As a person, I am terrified of just about anything with more than four legs and as a software developer, I am terrified of my programs not doing what I want them to do. O bugs how I loathe thee! I recently discovered however, albeit ten years too late, that there actually is a bug I am actually quite fond of: Ant. Granted, if one were to truly overanalyze this one exception to my entomophobia, an ant is still an insect and the Ant I am so fond of is a Java application builder.

As any software developer should know, there exists a massive divide in the developer world regarding operating systems. Furthermore, not every developer is going to agree on which development environment they prefer to write code in and everyone has their own thought process about how their software projects should be organized. Naturally, these exponential differences between developer systems are going to cause trouble when two or more developers deem it necessary and wise to collaborate on a project. Thus the birth of software building utilities arrived and developers could carry on knowing they were right all along about which development system and environment is the best.

Ant is a tool which is ideally used for building Java projects. Invoking Ant on different operating systems should, theoretically, always yield the same project build and ultimately make it possible for developers to continue to work on the project in their preferred manner but have a quick solution for sending the project off to be worked on by another person as well. Additionally, Ant can be instructed to run various quality assurance tools each time it tries to build a project thus ensuring that the projects being shared adheres to the same standards as others using the same Ant build. It's easy to see now why a software developer can, upon learning about the existence of it, be so quick to embrace the technology.

Learning to write an Ant script does require a basic understanding of XML. However, suffice it to say that each Ant task is a different XML tag that is understood by Ant to perform some action whether it be print something to the command line or to simply set a value to a property. In order to get a crash course on Ant, I walked myself through several "Ant Katas" to get familiarized with some basic Ant scripting concepts. Said Ant Katas follow:

Preface
I do not intend to explain how I accomplished these katas in detail, but rather share with you my learning experience through them. On a side note, there have been several external links thus far in this article for your edification and education. You are welcome.

Ant Kata #1 - Ant Hello World
The idea behind this Kata is to learn how to write a simple Ant script. With a bit of quick internet researching, I was able to learn that an echo tag with a "helloworld" message value was all I needed. However, this being my first foray into Ant scripting, I hit a road block almost immediately. An echo tag by itself was no good because Ant requires actions to be wrapped in target tags to be performed. Targets, as it turns out, are the little blocks of instructions that tell Ant what to do. But since you can have several targets inside an Ant script, how would it know which target needs to be carried out, if at all? Hence my final lesson from a deceivingly simple kata was that one can specify a default target for Ant to use when the script is executed if no target is specified by the user of said script.

Ant Kata #2 - Ant Immutable Properties
This Kata involved associating a value to a property element in Ant and then associating a different value with it shortly after. As one might expect with a Kata referring to immutability, a property's value can not be altered once it has been set. What struck me as interesting here is that essentially properties can be viewed as constants in Java since they can only be set and referred to but never changed.

Ant Kata #3 - Ant Dependencies
If you have ever used Make before, you might be familiar with the concept of dependencies. Briefly speaking, associating a dependency to one target tells Ant that the execution of this target depends on the successful execution of its dependencies. For any person reasonably logical, the concept of dependencies shouldn't be very difficult to grasp. If a target Keyholder depends on Car (to get to work) and a Store depends on Keyholder (so it can open), it follows that Car is needed for Keyholder which is needed for Store. Likewise, if Car depends on Store (apparently the car needs to be purchased from the store first in this case) then we have a circle of dependencies with no logical entry or exit point. In the latter case, Ant would complain and fail to execute the build.

Ant Kata #4 - Hello Ant Compilation
The point of Ant is to build projects - ideally Java - and any decent Kata routine certainly ought to have something practical as part of its choreography. Ant Katas are no different and to practice Ant in see it perform its core functions in all its glory, I wrote a simple Java program to simply print "Hello Ant" to the console. By applying everything I learned in the previous Katas, I was able to execute this Kata without much trouble. Compiling the Java file was a simple matter of calling on Ant's javac task and telling it where to find the Java file and where to put the compiled file.

Ant Kata #5 - Hello Ant Execution
Of all the Katas, the one which gave me the most problems was figuring out how to execute the compiled class file from the previous Kata. Rather than an issue with understanding how to use the java task in Ant properly, it was a dependence on my development tools to keep track of my class path which led to my headaches. However, once I was able to surmise that it was my use of a lengthy package name which was causing my Ant build failures, I was able to quickly diagnose the problem and fix my script accordingly. Lo and behold, my compile was successful and my execution printed out "Hello Ant" to my delight.

Ant Kata #6 - 8
For you, the reader, I will summarize that the goals for Katas 6 through 8 were to have JavaDocs be generated by an Ant script, a standalone "clean" target to exist and be readily invokable should the user choose to do so, and to put everything we've learned from the previous Katas together and package the project in one neat zip file for distribution. However, as I forewarned previously, this is a discussion of my learning experience through these Katas and, quite frankly, there is little left to discuss here.

Ironically, it turns out, the simpler Katas taught me the fundamentals of Ant scripting which allowed following Katas to be much easier to execute, and the skills for deciphering how Ant tasks work were all it took to execute the latter Katas. In retrospect - which is always an easy perspective to speak from - it was with a very low level knowledge of Ant and XML that I was able to manage completing my 8 Ant Katas and take my first step towards writing more robust and functional Ant scripts. That fact, coupled with the power of Ant and its supreme usefulness in software development, made me a believer that perhaps not all bugs demand from me the response of utter terror.

Tuesday, September 20, 2011

Three Laws of Robotics

Whenever a person thinks of robots, they tend to think somewhere along the lines of C-3PO or R2-D2 - digitally charged beings programmed so superbly that they are nothing short of autonomous.  Now imagine, if you will, that R2-D2 had spent the majority of the Star Wars franchise sitting in place and twirling its dome-like noggin around in circles.  Han, Luke and Leia would have met an early death at the hands of Jabba the Hutt but R2-D2 would have performed exactly what I programmed my robots to do in Robocode.  Continuing down the line of not-so-obscure science fiction references, it is nearly blasphemous to talk about robots without talking about the Three Laws of Robotics as established by the late Isaac Asimov.  The laws state:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Given my limited exposure to the joys of Robocode I was saddened to find that, while my robots all certainly cannot injure a human being and obey my poorly devised orders to the letter, they were all ill equipped to protect their own existence.  In my defense I, too, was given instructions on the functions that I was to write into my robots and, to their credit, all the robots I wrote performed valiantly on the field of battle with what they were given.

To get my feet wet, so to speak, I started off with a building a robot that did absolutely nothing.  This poor robot, when pitted against just about any other robot, was essentially defenseless.  I do make it a point to say just about any other robot because it drew every match it had against the sample SittingDuck robot which came packaged with Robocode to a dramatic stalemate.  However, as one might expect, making a robot that does absolutely nothing is not very interesting and soon, with the aide of a few built in movement methods, I was creating robots that could leisurely move across the playing field provided its opponents, too, were all pacifists who fired no bullets.  But even robots moving across the field back and forth quickly grew tiresome and it became all too obvious that more advanced techniques would be required to get them to perform more interesting movements.

Problems for me quickly arose when I attempted to create a robot that moved itself to the center of the playing field.  Firstly I realized that, due to the nature of how headings are organized from a range of 0 to 360, I had to warp my way of thinking and the trick to turning the robot efficiently would be to be very methodical and view destination headings as being relative to the robot's current headings.  To turn efficiently also meant that the choice to turn left or right was important and had to be based upon the robot's initial heading.  After tinkering around with the numbers a bit, I was finally able to get a robot to properly turn and move towards the center vertically and then horizontally.

Alas, I was not satisfied.  When walking to the middle of an open field, I would never first walk vertically along the field, turn 90 degrees, and proceed horizontally towards the middle.  Barring any obstacles, I would almost certainly walk diagonally across and I could think of no reason why my robot should not be allowed the same choice.  Thus, through trigonometry, I was able to devise an algorithm for which my robots were able to locate the center of the field, decide to turn left or right to be efficient and move straight to the center in a straight line.

Having mastered exhibited this skill a single time now, I forged ahead in my quest to learn Robocode and attempted to get my robots to not only acknowledge the existence of other enemies but to react to their existence as well.  Surprisingly, following another robot proved not to be as absurdly difficult as one might have imagined since Robocode actually offers several helpful methods for tracking enemies.  Since it is possible to keep a robot's radar facing in the same heading as the robot itself, following other robots was just a matter of turning my robot according to where the enemy is.  However, when it came time to finally work with the guns, a lot of unforeseen trouble headed my way.

Initially, working with guns seemed fairly straightforward: turn the gun in a direction which automatically activates the robot's radar and every time an enemy is scanned, fire away.  But when trying to track an enemy, I found that my previous algorithm for following an enemy did not translate very well.  This was due to the fact that, upon scanning an enemy, the bearings returned to my robot was relative to my robot's current heading, and not my robot's gun's current heading.  Thus working with bearings, which ranges from -180 to 180 and having to translate its relation from the robot's heading to its gun's heading turned out to be a spatial nightmare for me.  Ultimately, the solution I found was to translate the bearings into the same 0 to 360 range that headings worked in and after struggling with the problem for hours, I was able to get my robot to track another robot fairly well.  Albeit, at times, the tracking would still lose its target and the robot would be forced to spin its gun to relocate the enemy.

Although I was able to complete 13 simple robot implementations and develop a minor grudge against Robocode and mathematics in general, I realized that some of the instructions specified picking an enemy and although they did not necessarily always say to stick with the chosen enemy, the implication was there and had somehow gone over my head.  Thus, it is difficult to say that all 13 of my robots are living up to their specifications, but at least they are not injuring human beings.