Collaborative Learning

Collaborative Mind Map

I rarely study for a test.  My excuse is that it's not really studying, but cramming.  After all, shouldn't one learn the material while it is being taught (at their own pace), rather than the night before a score is given?  The truth, however, is that not everyone has the time and interest to always be attentive during the learning process, and thus periodic reviews/tests are needed to prompt us to "study"!  So here we go...

The Experiment: Collaborative Review

Being that it's one of those few times that I actually study for an exam, I thought it would be interesting to try out new approaches.  What if, instead of meeting in a group and discuss possible exam problems, we do so online?  Each person would do a self-review of the materials, and post 5 possible questions and answers to their blog and share them:

JKA Engineering Log

JMB Software Engineering Blog

ACL Engineering Blog

Thoughts on Design

Design Opinions

TNC's Online Engineering Web Log

Software Engineering Blog

Engineering Blog

College Computing

Engineering Blog

Trials and Tribulations of Computers and Sciences

Chistopher Foo's Engineering Log

JTG Engineering Log

Yong's Engineering Blog

M. Kupfer Software Engineering Log

Techie Babble

Matthew Mizumoto's Software Engineering Blog

Software Engineering Log

Hawaii Current Voltage

Zach Hacks

RBV Engineering

skeeto byte

Software Engineering

What are the benefits of that?  Well, for one, we gain more perspectives on the materials.  Instead of reviewing from our point of view alone, we get to see others' subjective point of views as well (i.e. what they think were important materials and should be on the exam.)  See the mind map above for what we have merged together so far!

Here are my review questions and answers:
1. Why should you indent your code with two spaces instead of using the tab character?
A: We indent code with two spaces to ensure readability without taking up too much space.

2. Give an example of a CheckStyle error
A: Although it is difficult to differentiate between PMD and CheckStyle errors, one can generalize CheckStyle errors to those relating to the style/format of the source code.  For example, CheckStyle would recognize the following as errors:
a) Use of tab characters instead of spaces for indentation
b) Not ending the first sentence in a documentation block with a period
c) Line is longer than 100 characters

3. Give an example of a PMD error
A: Although it is difficult to differentiate between PMD and CheckStyle errors, PMD errors are usually more focused on source code semantics.  For example, PMD would recognize the following as errors:
a) An if() statement is always true or always false
b) A method is empty
c) An implementation type is used instead of the interface type (i.e. ArrayList instead of List)

4. Give an example of a FindBugs error
A: FindBugs checks the compiled bytecode for possible performance and correctness issues.  Possible problems/errors that it reports on are:
a) Declared class data fields that are never used in the class
b) Using Math.round() to round an integer-casted floating point value
c) Using incompatible bit masks in a comparison that always yields the same result

5. Give an example when an IDE could be "bad" for you
A: An IDE can rarely be "bad" for you, but the lack of an IDE, or too much dependence on the IDE, could potentially cause you to mess up a job interview.  For example, the FizzBuzz program is usually used to evaluate a potential interviewee's programming capability.  The question is, can you write a fully compilable version of the code without the help of an IDE?  Or will you need to go through multiple revisions to iron out syntax bugs which the IDE usually flags and correct for you?

ToyBot is hosted on Google Project

After the competition, we started posting our individual robots onto Google Project for continued development and improvement.  If you would like to contribute, feel free to visit ToyBot's Google Project page.  I also posted my pre-packaged robot there, so feel free to download it and run it against yours.

If you are a developer and would like to contribute, go straight to the "Source" tab and grab a copy of the distribution using subversion.

I am sure there are many areas in which ToyBot can be improved on.  Hop on in and join the fun challenge!

Robot Rumble!!!

It is time!  The robocode competition is here, and we are all ready to have fun!  After spending hours going through the API source code, as well as trying some "Java cracking" attempts only to find the API being pretty secure, I settled on using the AdvancedRobot API.  I followed the robocode lessons and created an enemy robot tracker, which allows me to track other robots' movements and make prediction based on existing movement patterns.  The radar tracking code keeps all the robots being tracked in an array, and locks on to the first robot it sees.  The locking is done using the minimum radar turn assuming robot and gun is turned in the opposite direction.  Finally, the motion is a simple circular movement, with the added random reversal of direction whenever a continuous decrease of distance to target is observed.  Also, a "gutter" region around the battlefield is defined to try to keep the robot away from the wall, thus minimizing self-inflicted damage.

The competition is happening now!  In the meantime, here's some performance statistics against sample bots:

In one-on-one battle, the approach used was able to beat all the sample robots consistently.  One of the initial problem I had was with the "gutter" logic.  I initially set it to reverse every time it finds itself in the gutter. This is problematic most of the time because it ends up changing direction constantly and being stuck in the gutter.  This is fixed by putting a timestamp on each reverse, and set a period of timeout for consecutive reversal, thus allowing it enough time to exit the "gutter" condition.

Finally, like most of the students, I struggled the most with understanding the underlying robocode execution/event model.  The game physics page tries to explain the execution model, but is still unclear for in-depth exploitation.  In my attempt to go through the API sources and trace the event model, here is what I have as my notes:


Function calls per turn:
performLoadCommands()
  - fireBullets() => add bullets to battle field
updateBullets() => update and remove
updateRobots()
  - performMove()
    - updateGunHeat()
    - updateGunHeading()
    - updateRadarHeading()
    - updateMovement()
    - checkWallCollision()
    - checkRobotCollision()
    - update scan flag if moved or turned
  - performScan()
handleDeadRobots()
  - compute scores
  - update survival on the remaining bots
computeActiveRobots() => count how many is alive
publishStatuses()
  - energy, x, y, bodyheading, gunheading, radarheading, velocity, remaining moves/turns, gunheat, roundNum, time, etc.
wakeUpRobots()
  - waitWakeUp()
  - waitSleeping()


One needs to look at the event model in a cyclic manner.  During the last step, wakeUpRobots(), that's when your custom code is executed/evaluated.  I think that during your code execution, whenever you call a function that correlates to execution of an action (i.e. execute(), ahead(), turnRight(), turnRadarRight(), etc.) the action is registered and the robot code is put to sleep.  Then the event model starts evaluation from the top, by first updating bullet firing.  Note that in this case, for each turn, the standard Robot API only allows the registering of one of the various actions in the event model.  The AdvancedRobot API, on the other hand, have set*() functions to register multiple actions per turn before being interrupted and put to sleep by the call to execute().  I hope this notes could help the next generation of robocode hackers!  Enjoy and have fun!

Ant Build System: An XML version of make

Once upon a time, I tried to practice Java by typing up my codes in vim on the terminal and running it there.  The problem?  I couldn't.  Java has gotten a bit more complicated than what I remembered.  Instead of a welcoming "Hello World", I get thrown an exception: java.lang.ClassNotFoundException.  That's just not friendly, especially for someone who's just trying to say hello!

Thus, I have been sticking with the eclipse IDE ever since.  It feels a bit handicapped, since I can't automate things on the terminal and use command-line programs such as make.  However, it was necessary to build my basic Java knowledge in a simple IDE before trying to tackle more advanced topics.  Luckily, we didn't have to wait long to learn about the Java-version of make and other automation tools: the Ant build system.

Ant is invoked on the terminal using the command 'ant', and by default, looks for an "XML makefile" named 'build.xml'.  To tell it to use other script file, you need to invoke it in this form: 'ant -f <script-file>'.  Today, we'll look at some sample XML script files to familiarize ourselves with ant:

1. A simple Hello World


The code above illustrates the minimally required XML elements for an ant script.  First, the 'project' tag define the project name and indicate the default target to execute.  In this case, we only have one 'target' in this script, and it's named "helloworld" and is the default target.  Within the "helloworld" target, a single 'echo' command is embedded to print out "Hello World" when the script is invoked by ant.

2. Immutable Properties


The code above illustrates a new tag called 'property', which is used to define something similar to a named constant.  However, the catch is that properties are immutable, and thus the second definition of property named "my.property" is ignored.  The 'echo' line illustrates how one may access the value stored in a property, by enclosing it in the form: '${<property-name>}'.

3. Dependencies


The good old makefile had the ability to define dependencies and automate a whole hierarchy of dependent tasks.  The ant-version of that is similar, and uses the 'depends' keyword in the 'target' element definition.  The code above illustrates its use:
(a) by default, "foo" is the target, but because it depends on "bar", "bar" is executed first
(b) however, "bar" depends on two other targets, "baz" and "elmo", in that order
(c) "baz" yet again depends on another target named "qux"
(d) and "qux" depends on "elmo"
(f) finally, "elmo" doesn't depend on anything else, so it executes its content.  The dependencies is fulfilled, and the code unraveled back up the chain.
The final outputs are: "elmo", "qux", "baz", "bar", "foo", in that order.

4. Java Compilation using javac


Finally, we get to do the cool stuff: automating the build of your Java project.  The interesting thing to note here is this: if you named your package correctly, and placed the files in the correct package hierarchy within your "src" directory, all the codes are compiled automatically with a single ant command: 'javac'.  In the code above, we want to organize the compiled *.class files within the "build/classes" subdirectory, so we create that directory with the 'mkdir' command, and then tell 'javac' to use it as the "destdir".  A single line to compile your whole source tree, now that's an improvement over make!

Another target that's normally found in the makefile is "clean".  Luckily, because we generate our build within the "build" subdirectory, the cleaning task is simple.  Whenever the "clean" target is invoked (i.e. with 'ant -f compile.helloant.build.xml clean') the 'delete' command is executed on the "build" directory.

5. Java Execution using java


So, we are back to the original question: how do you run a Java program once you get it to compile, without throwing java.lang.ClassNotFoundException, on the terminal?  It turns out that due to the hierarchy of the packaging of Java classes, you can't expect 'java' to take a direct path to the *.class file and execute it.  Instead, you need to invoke it with the full package name and provide it the class path to where the package was compiled to.  For example, assuming the build script places its compiled classes in the "build/classes" subdirectory, then you would execute them manually by typing:
    java -classpath build/classes <full-packaged-class-name>
In the code example above, we have a class named "HelloAnt" within the package "edu.hawaii.ics613.helloant", thus the full packaged class name is "edu.hawaii.ics613.helloant.HelloAnt".  The 'java' element line illustrates how the respective pieces normally required on the command line is provided to the 'java' command in the XML script.  You might have noticed that the property "build.dir" was not declared anywhere in this script.  This is because it is imported from the previous script using the 'import' syntax.

6. Java Documentation using javadoc


The normal 'javadoc' documentation is generated in a similar fashion.  For more details on the syntax used, see the full documentation of 'javadoc': http://ant.apache.org/manual/Tasks/javadoc.html

7. Zip it up


The last step in an automated build system is the ability to package up the codes, after testing that it works, into a distributable archive.  In the code above, we used the 'zip' command.  The syntax is a bit more complicated due to our need to make the archive contain the project folder hierarchy.  To do so, you need to specify the "prefix" attribute of the 'zipfileset' element.  Packaged in this way, the archive will recreate a single folder specified by the "prefix" containing the whole project tree.

In conclusion, 'ant' is the Java-version of make.  It is a bit verbose due to its XML syntax.  However, it is still a good price to pay in gaining back the automation capability of a build system.

Gaming Challenge: Robocode!

Last Sunday, I spent 16 hours porting the memory scanner from Cheat Engine to a scripting language I use in windows for gaming automation purposes.  Yup, 16 hours!  I guess something clicked in my dream, and I woke up at 1AM and kept cracking at it for 16 hours straight!  Tired?  Not really.  It was fun!

FUN is the keyword.  If it's fun, I don't mind doing it more often.  Heck, if it's fun, I WANT to do it ALL the time!  The difference between being mentally tired from an 8-hour day-job, and being mentally enlightened from a 16-hour "hack and crack" is your attitude... and "Fun" is definitely the right attitude to have!

So, how about having FUN in an ICS programming assignment?  Sure!  The screenshot above is what we are doing in our ICS 613 class.  Nope, we are not designing a game from scratch.  Instead, we are competing in a robotic challenge called the Robocode.

Robocode is a Java-based competition arena for anyone interested in putting their minds and wits to the test.  The challenge?  Program your own robots and put your robots' intelligence to the test by competing against other robots.  The catch?  You need some Java know-how, be creative, and most definitely, time, to have fun!

The most challenging part of Robocode for me was trigonometry.  Yes, you need MATH to play smart!  In fact, all the good game engines out there uses Physics and lots of Math.  It was an interesting and refreshing experience to see programmers pulling out their pencils and scrible away on a sheet of paper instead of typing up codes.  I guess sometimes we forget: good software are designed and engineered.  Sometimes the  engineering notes all reside on the programmer's head (the easy ones).  But most of the time, programmers need scratch paper too.

Additional Links:

The Robocode wiki: http://robowiki.net/wiki/Main_Page

Interesting Lessons on Robocode: http://mark.random-article.com/weber/java/robocode/

Saying Hello in Java: "FizzBuzz"

My first programming assignment, after 5 years away from Java, is the FizzBuzz program.  The program is suppose to print out 1 to 100, and replace the numbers that are divisible by 3, 5, and 15 with the strings "Fizz", "Buzz", and "FizzBuzz" respectively.  This task took me about 8 minutes and 30 seconds to accomplish:

package edu.hawaii.ics613;

public class FizzBuzz {
  public static String generateOutput(int i) {
    if(i%15 == 0)
      return "FizzBuzz";
    else if(i%3 == 0)
      return "Fizz";
    else if(i%5 == 0)
      return "Buzz";
    else
      return String.valueOf(i);
  }
  public static void main(String[] args) {
    for(int i=1; i<=100; i++) {
      System.out.println(generateOutput(i));
    }
  }
}

Something new which I didn't learn about 5 years back is the JUnit test facility.  Here is a simple test case for the FizzBuzz program above:

package edu.hawaii.ics613;

import static org.junit.Assert.*;
import org.junit.Test;
public class FizzBuzzTest {
  @Test
  public void testGenerateOutput() {
    assertEquals("Testing 1", "1", FizzBuzz.generateOutput(1));
    assertEquals("Testing 3", "Fizz", FizzBuzz.generateOutput(3));
    assertEquals("Testing 5", "Buzz", FizzBuzz.generateOutput(5));
    assertEquals("Testing 15", "FizzBuzz", FizzBuzz.generateOutput(15));
  }
}




Conclusion: I am still very rusty... need more Java polishing!

Proteus Cross Compiler and the LLVM Compiler Infrastructure

There is a new (6 days old) project on SourceForge that really piqued my interest: the Proteus Cross Compiler.  The project boasts the ability to generate Java code from GCC compatible languages such as C, C++, and Fortran.  Having had experience compiling C to MIPS assembly by hand, I began poring through the project home page and documentation.

At first, I was doubtful.  Many would-be language converters that I have looked at in the past failed at the insurmountable task.  What could make this project an exception?  I was pleasantly surprised to find that the task was reduced in complexity by taking advantage of another interesting, well-established project: the Low Level Virtual Machine (LLVM) compiler infrastructure.  The LLVM project takes care of the various GCC language front-ends, and spits out an optimized intermediate form which is then used by Proteus to generate Java code.  Thus, in a way, Proteus is just an LLVM to Java converter.

After being convinced of the reduced complexity of the task, I was quick to start setting up my environment to test out the system!  Looking through the worked-out examples, I figured it was best to try it on my Ubuntu virtual machine instead of directly on my OS X Lion, which would require me to manually compile many dependent packages.  On Ubuntu, installing the supporting LLVM and GCC front-end was really easy:


sudo apt-get install llvm-2.7 llvm-gcc-4.5


Finally, it is time to play!  I clicked on the "files" section to download the project, and the only thing there is a "readme.txt" file.  The 6-day old project does not have the files uploaded yet...  I guess we will just have to check it out next time!

One closing trivia: is anyone aware that Apple is using LLVM?  Check it out: http://developer.apple.com/technologies/tools/