Build Systems and Apache Ant

In this Blog entry I write about my experience learning about build systems in general, and Ant in particular.

Ant Code Katas

Again the "Code Kata" approach deserves praise for its role in learning. Until the last Ant Code Kata (#8) the incremental Kata approach proved itself to be appropriate for learning as success came easily with Katas 1-7, motivating me each time to move to the following task. Here are the simple Ant build scripts I implemented:

1. Ant Hello World (Ant echo task)
2. Ant Immutable Properties (Ant property task)
3. Ant Dependencies (Ant target dependency resolution)
4. Hello Ant Compilation (Ant javac task)
5. Hello Ant Execution (Ant java task)
6. Hello Ant Documentation (Ant javadoc task)
7. Cleaning Hello Ant (Ant delete task)
8. Packaging Hello Ant (Ant zip task, ant copy task)

Learning Ant

I was generally impressed with the wide range of useful tasks that can be accomplished by scripting using Ant. By far the most interesting Kata was the zip task, which required understanding the zip target: name the archive, where to place it, and more generally, learning how to include and exclude files. There are also tasks for setting and referencing a multi element classpath. Ant has several ways to do this. Ant properties are immutable, meaning once set, they can not be changed. Integration with Eclipse was expected: Eclipse has a colored syntax editor for working with Ant scripts, Ant "Run Configuration" editor, a "Run as Ant build" button, and it diplays the value of Ant properties when hovering over them in the editor with your mouse.

Automated Build Systems

I learned that automated build systems offer a low cost way to build software releases, including version(ing), automated running of tools such as javadoc, checkstyle, and findbugs, and can even download tools and libraries. They do not interfere with the developers' choice of IDE. An automated build script can be used to automate and verify the build often, with almost no cost once the script is written. Although build systems are not a substitute for JUnit tests or software reviews, practically every substantial software system uses some sort of automated build system to increase productivity, efficiency, reduce errors, and save time.

Robocode Code Katas

Robocode

Robocode is a hugely popular programming game, or more technically, a battle simulation engine, available freely as open source. However, you don't have to be a seasoned game programmer or Java guru to experience or enjoy it. Robocode is easy to install, configure, learn, and understand, even for beginning Java (or .NET) programmers. There are a wealth of websites that contain tutorials, examples, and even complete code for both simple and complex robots.
Using the Robocode API, you can develop robots (or more correctly: tanks) to do battle against other robots of your own, or sample robots provided by the Robocode game itself. The idea behind Robocode is to learn more about Java and programming, and of course, both gaming and Robocode itself, and have fun while doing so. There are even competitions for those that are interested.

Fig 1. Robocode Battle with four robots.

Robocode Code Katas

A "code kata" is an exercise in honing your skills as a programmer based on the concept of katas in karate. Kata are exercises - you repeat each exercise many times, making incremental improvements each time, and the complexity of the exercises increases as you progress through them. The learning discipline of code katas is similar. For more about code katas, the concepts are explained nicely in the blog articles I read by Jeff Atwood here and the more in-depth treatment by Dave Thomas here .

Back to Robocode! I developed a handful of simple Robocode robots in the spirit of code katas, that enabled me to become familiar withe Robocode game engine, the Robocode programmer API, and to incrementally increase my skills as a Robocode/Java programmer. This effort also included learning more about the Eclipse IDE, as well as adhering to a published set of development guidelines. This included following a specification for Java code formatting and coding style, as well as producing professional-level documentation using Javadoc. The book Elements of Java Style  provided most of the style and format conventions I used in order to develop code that is easy understand and maintain.

So as an introduction to learning using the code kata method, I implemented the Robocode robots described below. Each successive 'exercise' was a little more complex and more challenging than the previous one.

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

Four additional robots I have not implemented yet but would like to, are:

• 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).

Discussion

This exercise taught me many things. The Robocde platform, code kata approach, together with the development standards, and Eclipse IDE, was indeed a fun way to practice, learn, and improve Robocode, Java, and Eclipse skills. I was surprised to learn how quick and easy it was to download, install, and configure the game engine, and to code and run my first robot!

The Robocode API was mostly self explanatory, but there were some exceptions. I used Google to search for examples of calling Robocode methods in the context of implementation examples to overcome this. The API seemed abundant enough to build robots quickly and intuitively, but it wasn't long before I was wishing more methods were available, for example, a goTo(Double x, Double y) method. Looking forward, I believe that it would be difficult and time consuming for me to build a very competitive robot (the kind that compete in the Robocode competitions). As I am still building very rudimentary robots, I don't yet have a strategy to build a competitive one.

I believe the code kata approach is a valuable tool for learning. I feel we have all used this approach at some time or another, to some degree, when the opportunity is there (e.g. enough time to use it, no conflicting requirements). I don't know if there is empirical evidence that this approach to learning is the best one, but in an appropriate scenario I consider it a valuable approach. For this endeavor - learning Robocode for fun and exploration - it felt like a productive and appropriate technique.

Once I understood the game engine and it's seamless integration with Eclipse, my difficulties were mainly with the trigonometry required to build robots within the time frame I set aside for this exercise. Having long-forgotten most of the formulas needed, and knowing where and when to use them without hesitation, slowed my ability to code the robot behaviors. I was able to look up trigonometric equations and formulas on the internet, using mainly this site suggested by a friend.

FizzBuzz

FizzBuzz with Eclipse

After reading the blog posts by Jeff Atwood here and by Scott Hanselman here, I implemented the FizzBuzz program using Eclipse in about 7 minutes - including coding a
junit test class. Since I knew a solution ahead of time, the bulk of the time was spent typing, rather than devising an algorithm. Using junit for the first time, I used control+space in Eclipse to see the available methods in the org.junit.Assert class. When I forgot to use String.valueOf() when dealing with integer values (the method return type is String), Eclipse flagged this error in real-time as I was typing. I was able to correct it immediately rather than wait for a compile time error to realize my mistake had I been using an ordinary text editor and javac.

FizzBuzz.java





FizzBuzzTest.java



I implemented an alternate FizzBuzz algorithm by adding another method to my FizzBuzz class and tested it using junit as well. I used "refactor code" in Eclipse and all the method names in the junit test class were changed for me automatically. In addition I used "window->preferences" in Eclipse to change the style of the braces and add blank lines to the code automatically while typing as well as when using "source->format" from the context menu.

Summary

I learned some valuable lessons by reading the blog posts mentioned above and coding the FizzBuzz program with Eclipse. It's a good thing to be able to commit a working knowledge of correct Java syntax to memory, even though it's easy to look at or cut-n-paste existing code, use the API documentation, or search for code examples using Google. With so many Java classes in the API it's not possible, or even time well spent, to memorize every class! However, the basic syntax, such as what's needed to create the FizzBuzz program, is a requirement for any programmer taking his profession seriously. I also gained some insights into the mindset of interviewers, and feel that becoming an expert Eclipse user will be a very valuable skill, increasing my productivity and efficiency when coding.

Reflection on ICS 613

Based upon our assignments and readings to date, I feel ICS 163 will benefit us by introducing and/or reinforcing concepts and skills that are essential to being a successful software engineer.

Open Source Software and the Three Prime Directives

Open Source Software and the Three Prime Directives

Overview: 7-zip

7-Zip is the package I chose to download, which is a file archive pack/unpack utility supporting an everyday task for most software professionals and even end users.  Its stated objectives include a high compression ratio and support for many/most file archive formats encountered on modern computer systems. Additionally it is claimed to run under most flavors of Windows as well as Linux/Unix.

7-zip can be downloaded at:        http://sourceforge.net/projects/sevenzip

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

Given the overview above, it is obvious that the functionality promised by 7-zip would be both useful and beneficial. Therefore it qualifies as a utility that provides an extremely useful everyday task for a broad range of computer users, since a large number of downloaded files are packed, and conversely there is a need to pack files and/or directories before emailing or uploading them to other users.

 

What other useful functionality is provided? Aside from the basic tasks of packing/unpacking archives, 7-zip provides features such as encryption, self-extracting capability, integration with the Windows shell, a file manager, a command line version, and localizations for 79 languages.

So the system satisfies PD1: successfully accomplishing a useful task.


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

Achieving Success with 7-zip was easy. One click to download, run the downloaded .exe file to install it, and simply choose the install directory was all that was required.

I was able to use 7-zip immediately with no instruction, readme file, release notes, or documentation.

I especially liked the seamless integration with Windows context menus. Intuitively, I right-clicked on a .rar file. I was presented with a menu that included several 7-zip options including open archive, extract files, and test archive.

I chose 'open archive' and a well-thought out and simple UI containing the .rar file was presented with just a few buttons, as well more options contained in a menu bar across the top of the application. All I needed to do was click the extract button and provide a location, and the archive file was unpacked in less than a second.

 

7-zip satisfies PD2: I was able to successfully install and use the system.

Prime Directive 3: If you were going to attempt to modify and improve the system, how easy would it be for you to do so?

The package has it’s own home page at http://www.7-zip.org, and another developer-specific page at http://sf.net/projects/sevenzip/develop.

Not only did the developer page include a link: "Send a request to join this project" but the project home page showed statistics for Bugs, Support Requests, Patches, Feature Requests, and Public Forums.

Each statistic had a link to very detailed and easy to understand data arranged in a table format. In fact, the public forums page had both a forum for help, and a forum for discussion including a useful search by keyword feature.

In addition, the 7-zip project home page contained license information, version change history, and a (favorable) compression ratio comparison chart comparing some of the leading popular archivers currently in use.

Without looking at the source code and other developer documentation (available by request only) I cannot be sure PD3 is satisfied. If the source code and developer documentation is comparable to the rest of the package, I suspect that it would be easy to modify and improve the system, thus satisfying PD3.