Manual Automation Katas

Early in the 20th century, America moved from hands-on factory labor to newer and better automated processes - a much-needed match for America's growing population and therefore, growing demands for supplies. This same concept applies to software. As software packages grew in the number of lines of code, the need arose for automated processes. Enter scripting languages such as Make and build systems such as Apache Ant. Apache Ant or Ant (an acronym for "another neat tool") is a software build system tool that allows for the compilation, execution, testing, and documentation of Java and C/C++ applications. Ant works in conjunction with Ivy. Ivy downloads and maintains the libraries required for software projects. Ant is supposedly easy to learn, especially if the "kata" principle - the repeated practice of form - from martial arts is applied.

1st Kata: Ant Hello World
If there's one thing a software developer will never say goodbye to, it's hello. <\echo\> (imagine that the backslashes aren't there; the same goes for the rest of the tags in this post) is to Ant as "System.out.println()" is to Java. Hello World . . . Hello, My First Ant Build Script. A cinch, a cinch, yes it was.

2nd Kata: Ant Immutable Properties
It's integral that Ant, part dependency manager, should have immutable properties (defined by <\property\> tags), as demonstrated by this kata in which I defined two properties of the same name, assigned them different values (first "1" and then "2"), and printed out the value of the property. Any guesses as to which value was "echoed" to screen?

3rd Kata: Ant Dependencies
Ant's dependency management operates in a very straightforward manner: <\target\> is to be executed only if the "depends" attribute is fulfilled. And if "depends" does not exist, then <\target\> is free to run. In other words: IF "depends" is fulfilled, THEN <\target\> executes. <\project\> is to Ant as "class" is to Java. The attribute of <\project\> called "default" specifies the main <\target\> that a build file should run. This dependency management was demonstrated by implementing the following:

*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.

Before running the build script, I had to guess in what order the targets were called, given that "foo" is the default target. I guessed the following: elmo, qux, baz, bar, foo. Right? Yes. Why? foo can't run without bar, and bar can't run without baz and elmo, but baz can't run without qux, which relies on elmo. elmo is the only one without dependencies, so it executes first. qux runs next, allowing baz to run after it. Now that baz and elmo have been executed, bar runs. Lastly, foo runs (it had been waiting on bar this whole time).

The second task was to change the script and make elmo depend upon bar. I had an idea as to what would happen, but I wasn't so sure what would print out. As wonderful as it could ever get, Ant knew exactly what went wrong: circular dependency, since bar ends up depending upon itself.

4th Kata: Hello Ant Compilation
A HelloAnt.java file that prints "Hello Ant" to screen? Easy. Now getting the build file to succeed was all a matter of examining the existing Ant code and modeling my "compile" <\target\> after it. With the use of the <\mkdir\> and <\javac\> tags, I was able to successfully automate the compilation of a Java file.

5th Kata: Hello Ant Execution
This kata was the trickiest so far; I couldn't find an example in the Ant build files I downloaded as part of the Ant package, so I had to search this one up. There were a few unsuccessful executions (using Terminal on a Mac), but I was able to determine that "classname" (name of the Java class, excluding the .class extension) and "classpath" (the location of the Java class file) were the only <\java\> attributes needed. I had success compiling when HelloAnt.java was in the default package, but after moving it to the edu.hawaii.ics314 package, it simply would not compile. Thanks to Jordan Takayama's's blog, I found out that the "classname" attribute should be set to "edu.hawaii.ics314.HelloAnt" and the "classpath" attribute should be set to the "classes" directory. Lastly, this was the first kata that made use of the <\import\> tag (the "compile" build script had to be imported), which is very similar to the #include directive of C/C++.

6th Kata: Hello Ant Documentation
Generating JavaDocs by entering a single command has never been made easier. However, before I could get this to work, I had to create an "overview.html" file (in the "src" folder but outside of the package) and a "package.html" file (in the package). I then made sure that any properties used in the <\javadoc\> tag were specified in my build system before I ran the script file to generate the JavaDocs.

7th Kata: Cleaning Hello Ant
This was pretty straightforward. Again, I modeled my "clean" target after already-existing Ant code. A simple <\delete\> tag did the trick and deletes the "build" directory if "clean" is listed as a dependency.

8th Kata: Packaging Hello Ant
This kata was extremely frustrating at first because I could not for the life of me get my zip file to unzip into a single directory. I tried and tried it my way, trying to ignore existing code in the hopes that it would work for me with a few lines of code. In the end, I had to look at the existing code (from PMJ-DaCruzer's dist.build.xml file) and model my code after that. I learned that it is perhaps impossible to unzip files into a single folder without copying files to a directory within a temporary directory first.

Figure 1: One simple command (ant -f dist.helloant.build.xml) for distribution

In conclusion, Apache Ant is a very powerful tool, designed to make the distribution of a Java project more user-friendly and efficient. Build systems help us automate distribution, proving to be a bit troublesome when one attempts to go against the flow, but once one learns to adapt to it, the raging river becomes easier to navigate.

Mixing Martial Arts with Robots and Coding

So how does one mix martial arts with programming? It's simple: you take the general principles from one and apply them to the other. The general principle in question that is of particular interest to programmers is called the "coding kata." In martial arts, basic form is practiced over and over in simple, repetitive movements called katas. It's no wonder martial arts can appear as graceful as professional ballet and figure skating. This same principle of katas can be applied to coding and is especially useful when one is learning to program in a new language or learning the workings of an open source project.

And the robots come marching in . . . in the form of the renowned Robocode open source project, initiated by former IBM employee Matthew Nelson. With Robocode, one could code their own robots from less than a minute to days on end, depending upon the level of competitiveness the robot is intended to have. The premise for Robocode, inspired by Nelson, is that coding games in Java could be fun and efficient. Indeed, it wasn't - at least, not at first.

Two years ago, I wanted to join a Robocode competition but didn't know how to begin, since I was a Java newbie. If only I had learned about the coding kata back then, then perhaps I would have been able to code at least one simple robot. Indeed, this coding kata is a life-changer.

Luckily, I was given the chance to work on Robocode again this year. The best way to build a competitive robot is definitely to start from the basics, as the Karate Kid films show. I learned, to my surprise, that coding robots was not as difficult as I had made them out to be. It was fun learning bits and pieces of trigonometry all over again. What caught my attention was that robots are like little kids - they won't know when to get out of the way of other robots, just as little kids won't know to look left and right before crossing a street.

Overall, I feel good about the assignment (having implemented all behaviors; I just don't feel too good about the commenting) - it was a treat, in fact, and didn't feel like homework. Coding robots is fun, especially when you're learning from others as well, all practicing the same coding form in order to achieve greater things, such as competitive robots, later down the road.