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.

FizzBuzz Java Implementation Analysis in Eclipse

It took me approximately 25 minutes to implement (with good citizenship) and verify (line-by-line) the FizzBuzz program.  Summary: Rough implementation - 10 minutes; Code-polishing - 15 minutes

Before our first lecture class for Software Engineering, I have not programmed in Java for months. Given this task to implement FizzBuzz in Java, I took about 10 minutes to code FizzBuzz off the top of my head (and partially from what I could remember from last week) and run it with an at-a-glance "passed" for verification of correct output. However, at this 10-minute mark, I knew I had yet to appropriately verify my code, figure out how to place it in the proper Java package (edu.hawaii.ics314, in this case), and comment my code for good programmer citizenship's sake. With fellow classmate Jason Yeo's help, I discovered that I had always been missing one simple step to placing a Java source file in a custom package, and that step is to specify a name for the "Package" text field upon creation of a new Java class. As can be seen in the following figure, I had multiple packages before I made the right one (and later got rid of the others):

Figure 1: Multiple packages before creating the right one

Commenting each subsection of the code took only a few minutes.  It was the line-by-line verification of the correct output that comprised the bulk of the 15 extra minutes I spent to polish my code.  Each of the "FizzBuzz" and "Buzz" outputs were a given, since multiples of 15 and 5 are hard to miss.  In order to verify the "Fizz" multiples of 3, I mentally added each multiple's digits and divided the resulting sum by 3.  In the near future, I shall learn to use JUnit to test my code instead of this human error-prone line-by-line verification method.

In conclusion, I learned that writing the code itself is a downhill slide.  It's the uphill climb - the polishing of code and learning of new concepts to polish it even better - that takes more time, but in the end, it matters most.

Figure 2: The proper package, carefully-constructed comments, and line-by-line verification


Figure 3: My Java Implementation of the FizzBuzz Program

Logisim: An Essential for Every ICS 331 Student

An Assessment of Open Source Software against the Three Prime Directives for Open Source Software Engineering

Last semester, I took ICS 331 with Dr. Curtis Ikehara, which is a course entitled "Logic Design & Microprocessors," and about each week, he would assign us a lab assignment using our breadboards.  In other words, understanding and building circuits was a huge portion of the class, and if only I had begun to think sooner about delving into the world of open source software, then I would have saved myself from unnecessary eraser markings and trouble.

Overview

Logisim is exactly as its name implies: a simulation of logic - of digital logic circuits, to be more specific.  Its main function is to serve as a user-friendly interface for designing, building, and simulating digital logic circuits.  More information can be found at its SourceForge.net website and Project Home website.  In reference to Dr. Philip Johnson's Three Prime Directives, my assessment of Logisim is as follows.

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

In less than five minutes, I was able to discover Logisim's most basic function without reading any tutorials by replicating a XOR circuit consisting entirely of NAND gates, as shown in the image below.  After accessing the "Help" menu, I discovered the feature of building circuits automatically using input from a truth table, which is a useful function for building especially complex circuits.  This program also features hierarchical circuit design, or the ability to use saved/already-existing circuits as portions of other circuits.  In short, this system, without a doubt, successfully accomplishes a useful task (and more).

Figure 1: XOR circuit consisting entirely of NAND gates

Figure 2: The "Help" Documentation

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

It took about a minute or so to download, install, and run the program (the latter accomplished by a simple double-click on the OR gate icon labeled "Logisim").  For download and installation support, straightforward and concise "Getting Logisim" directions are found on the Project Home website, upon clicking the "Download" link on the left panel.

As mentioned above in the first prime directive, the interface is simple enough in design that the average user can construct a circuit in under five minutes.  Click once (but do not hold down) on a logic component icon, such as a gate, move the mouse pointer over to the dotted area, position the icon, and place it down by clicking once more.  Hovering the mouse pointer over the blue markings behind a gate, for example, creates a momentary green circle around the specific marking.  This circle indicates a point from which the user can click, hold, and drag a solid line from one icon to another.  The entire contents of the "Help" documentaion for Logisim can be found offline on the "Help" toolbar within the program or online at the developer's website.  In short, this system is extremely easy to successfully install and use.

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

Bugs, Feature Requests, and Support Requests could be reported/requested using the "Tracker" menu on Logisim's SourceForge.net toolbar.  The News information under the "Develop" menu includes version release notes; the 2.7.1 entry here introduces a mailing list for development updates, which anyone can subscribe to at this link.  There is also a separate Logisim Developers' mailing list and Google Group found on the "Support" menu.

Features, bug fixes, and design changes are highlighted on Logisim's Project Home website under "Release History," and Carl Burch, the original developer, also provides his e-mail address in the "Comments" section in case the SourceForge.net resources do not serve a user's needs.

At Logisim's "Develop" page on SourceForge.net, clicking the "browse code" link under "Repositories" displays a page that shows the file/folder name, the number of revisions made to that file/folder, the "Age" (stating the elapsed time since the last revision), the "Author" (who made the last revision), and the last log comment/entry.  One way to access the source files is by clicking on the "Download GNU tarball" link.  Another way to access them is by decompressing the jar file included with the initial download of the Logisim software.

In regards to the Java source code, I feel that there is a significant lack of comments in each of the ten sample files I have opened.  Most of the comments are something along the lines of "access methods" or short three- to five-word one-liners.  Only one of the files I opened actually had a few comments within a method itself.  This style of commenting is in no way beneficial on my part or, as I can imagine, on anyone else's.  Hence, despite the fact that some pretty solid support and documentation exists for the Logisim open source software, it does not meet the last prime directive because its source files are not well-outlined and well-commented.  Nevertheless, I still recommend that every ICS 331 student take advantage of this software as soon as humanly possible.

Blog Title: "Geek Inertia, You're Despicable"

I spent the greater part of two hours trying to devise a creative title.  Satisfied with the results?  Yes, close enough.  This title personifies my lifelong stance on learning about IT.  Thanks, Daffy.
~ Proud [Warning: "Computer" is Inferred] Geek