Lets Talk Energy

    Hawaii is in a very unique situation when it comes to the issue of energy.  Energy prices in Hawaii can be from 3 to 6 times more expensive than those in the mainland US, these high prices have several causes.  One of the main reasons Hawaii has higher energy prices is because of the states dependence on oil, a very high percentage of the energy ( 77 %) created in Hawaii is done so using oil.  Oil has to be imported into Hawaii and is also more expensive initially than other resources, like coal, which is greatly used in mainland US production of energy (45 %).  Another big difference between Hawaii and the mainland US is that Hawaii has several small power grids it runs off of, while the mainland US has one huge supergrid that deals with all the power supply.  Having one large connected grid allows more flexibility than having smaller unconnected grids.
     While having more expensive energy sounds like a bad deal, which it is, there is also a silver lining to this issue.  Hawaii is lucky enough to have access to a plethora of different kinds of renewable energy resources including wind, geothermal, solar, biofuel etc. and because Hawaii is so dependent on oil when oil prices rise, the cost of oil dependent energy rises along with it.  So how could this be a good thing?  Renewable energy is expensive, and while the price of renewable energy remains greater than the price of other non renewable energy sources we will continue using these non renewable resources.  Because the prices of oil produced energy in Hawaii will continue to rise rapidly into the future and because Hawaii has access to a multitude of renewable energy resources Hawaii is bound to find itself in a situation where renewables will become cheaper than imported oil produced energy, and this transition will happen before most every place in the world.  This earlier transition along with support from local government puts Hawaii in a unique situation to get rid of its oil dependencies and also serve as a model for the mainland US, and world wide, on how to transition to renewable energy.  This is also advantageous economically because Hawaii may develop new service exports dealing with these issues.
    This is a software engineering log so lets talk software.  This transition into renewable energy resources here in Hawaii has already begun, and it has funding.  Along with the new technologies that are being developed and the studies being conducted there is a demand for software that can deal with these complex issues.  As the movement towards green energy gains momentum there will be a lot of new opportunities for developing these new systems.  This puts us future and current developers and researchers in a great situation in which we are looking at a potentially explosive field, not just in Hawaii but throughout the US, and one ground zero may in fact be Hawaii.  Hawaii will be one of the first places to adopt renewable energies on a large scale and the associated software that supports these new systems,  these new systems can potentially serve as a model for the rest of the US and other places in the world, which puts us in a very interesting and exciting situation.
    While this is very exciting, it is also very difficult.  There are many new and interesting challenges that have to be addressed and overcome and there are people that support the movement to renewable energy and those who also oppose it.  Along with the development of new software and technologies that will make this transition possible, there are also political challenges such as local opposition to building windmills and geothermal plants on the islands especially when its to support the energy consumption of another island which is the issue of the very centralized use of power on Oahu compared to the other islands and how that can be dealt with.
To learn more please check out this series:    
Click Here

Review

What are the positives and negatives of a walkthrough code review?

Positive: cheap
Negative: unreliable Information/quality

Name 6 instances in which the verify.build.xml command can fail.

PMD, Checkstyle, FindBugs, Junit, JavaDoc, any .xml file error

Explain the What X and Y are, and their relationship to each other:

<target name="X" depends="Y"....
X is the name of the target, Y is a dependency of the target, meaning X will not execute unless Y does.

Give an example of an error that would only be found by Find Bugs.

while (true) {

....
}

What is the shared data problem in respect to a RCS.

The shared data problem occurs when two developers want to edit/work with the same data or file in a project.

Configuration Management and Google Project Hosting

    In order to streaming a software development process among a software team it is extremely valuable to utilize a  configuration management system, a way to control the development process when multiple software developers are writing/editing possibly interdependent code.  Without a configuration management system problems may arise during development such as inconsistant code among developers, no clear indication of when the system started or stopped working properly and what code was responsible, the problem of simultaneous updates which cause "clobbering"  aka only one persons code being uploaded and the shared data problem which arises when two developers need to work on the same file/data.

    Version control is a type of configuration management whose main goal is to maintain multiple versions of the system. Google Project Hosting is a version control system that uses Subversion, which is one of many different version control systems.  Subversion uses a central repository, or a complete and always up to date version of the software project that can be checked out, modified (on an individual basis) and committed(update change/s to repository) by developers.  Each commit made by developers is tracked by Subversion so that there is always a reference to each update in the system, which makes it easy to locate when and where an error occurred.  Subversion also prevents clobbering, by maintaing each developers version of the repository through updates,  and allows each developer to have a complete version of the system, which eliminates the shared data problem.


 

     Getting a project started with Google project hosing is relatively simple, you just have to give it a name, upload files to the repository, and provide supporting documentation for users and developers.  After that you are ready to start adding developers to the project.  Here is an example of  my first project through Google Project Hosting:

robocode-kmi-GreenMachine

      The above is the front page of my hosted project, as you can see we have a description in the text field of the project, there are multiple tabs at the top including downloads, wiki( aka documentation), issues and source.  If you wanted to check out this project you would do so from the source tab, if you wanted a distribution of the system you could find a .jar file under downloads. please feel free to explore this project to get comfortable navigating a Google hosted project.

  This is a project which contains my competitive Robocode robot.  Please see previous posts if you are curious to what that is:

Java fueled robots
and
GreenMachine

  Setting up a project in Google Project Hosting is straight forward, things that I found can tie you up a little would be the documentation, and making sure that the files in your repository are in the correct place.  A few of the small things can be a little confusing but everything you need to know for setting up an new project can be found here if you get stuck:

Getting Started

This is a free and powerful tool for team software development, and as a side note in order to properly use a Subversion system you need to have a Subversion client on your machine, this is the one I am using for Mac.

SmartSVN

How to use a Subversion client is a whole different topic.  You can use the documentation on the above website to get started.

GreenMachine ! Robocode robot

  I have just completed my first battle ready Robocode robot that I named GreenMachine!  If you are unfamiliar with the Robocode project you can read up on my previous post here:
robocode 

If you want to download a distribution of my robot you can find it on my site:
Robot Distribution

The creation of this robot was inspired by a upcoming Robocode competition among some of my fellow classmates, I wish them well.. but I believe that the GreenMachine will do well given the short amount of time given for development of robots for the competition. The GreenMachine is a robocode robot that extends only the robot class, not the junior robot or advanced robot, which means that there are a lot less built in methods to utilise.  Most of my robot is composed of original code except for one method I use to linear target robots that move in 90 degree angles, (such as sample.walls).  the design ideas that I implemented are as follows:

Movment:
   For my movement I could not think of a good way to avoid being hit except to be unpredictable... so what better way to be unpredictable then to use sporadic sudo random movements.   For my movement method I use a built in Java random number generator and generate a random degree between 0-300 and a distance between 75-100 pixels.  I chose to move such a short maximum distance per turn because moving in one way for any extended time will give an opponent a chance to preform linear targeting on my robot. This movement seems to evade a lot of shots, but we will see how it preforms in competition.  A way to improve on this move method (I didn't have the time to) was to eliminate the possibility of moving directly towards or away from the enemy, as this would not change you retaliative bearing in comparison to the enemy.

Targeting/Firing:
   For my targeting I continuously scan the field between moves and acquire a target.  Once my target is acquired I will shoot a bullet at their bearing with power retaliative to their distance from my robot (farther away less power).  If a shot hits its target then the overridden method onBulletHitEvent will immediately fire a mid-power bullet to the same X any Y coordinates that the first bullet struck the enemy, it does this after it moves just in case the enemy fire a retaliation shot in the direction it was struck by my bullet.  In the event that my robot comes close to the enemy, within 100 pixels, the GreenMachine will charge its enemy full speed and on contact with the enemy fire a shot with maximum power, this method of close combat seems to work great.  In the event that a robot is moving in 90 degree angles like sample.walls, GreenMachine will change its behaviour and use linear targeting to make shots that try and intercept the enemies future location.  This behaviour was used from
walls killer 
and was the only code in my robot that I did not write. Finally in the event my robot is hit by the enemies bullet I immediately fire a retaliation shot in the direction it came from then move.

Results of my Labor:
   GreenMachine can beat most of the sample bots reliably including Walls, RamFire, Crazy, Fire,  Corners, Tracker, SittingDuck.  It does have some trouble with SpinBot because it does not have a method for dealing with circular predictive targeting, therefore it wins about half the time against SpinBot. To improve on this I need to create a way of identifying robots that move in circles and devise a way to track them. 


Lets Take a Look: I suggest watching it expanded and in HD on YouTube.

Testing:
   For my testing methods, I used Junit tests to judge my robots progress by having 10 round battle results quickly evaluated for each of the sample robots.  This allowed me to quickly see the effect of any change I mad to my robot.  In addition to these battle simulations I also tested different methods of my robot such as my firing techniques and my robots responses to events such as impact with another robot and impact with walls.  I also utilised JaCoCo to see the coverage of my tests. 


Lessons Learned:
   I learned a lot from this project, I learned about creating a more advanced robot and how complicated robots can get.  I also learned a lot of valuable skill on how to use Junit tests to test a program as well as guide the progress of software development.  Throughout this experience I was utilising the Ant build system and therefore became very familiar with how the Ant and .xml files used in ant work.  Towards the end of the development of GreenMachine I was utilizing Ant + Ivy in an efficient way.  It has also become very clear to me the value of using a build system when developing software among multiple software developers.  From a software perspective I would become very familiar with my build system before writing any code, and from a Robocode developer perspective I would search every nook and cranny of the Robocode API before beginning development to save on time and effort.  I found that writing Junit tests after I began this project was difficult, If I could do it over again I would like to try the approach of writing my Junit tests before the code they are meant to test.

The Power of Ant

   The development of software on a larger scale, meaning there is some sort of development team, becomes difficult for many reasons. When attempting development with a team you will be dealing with multiple developers, possibly using multiple types of systems, with different development environments and the utilisation of third party libraries. So how in the world can you work together in an effective and efficient way? One option is utilising something called a build system, like Apache Ant:

  "Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications."

so what does that mean...

  It means that Ant uses files called "build files" to execute certain commands or tasks called "targets" whose purpose is to make the software development process better by creating/allowing usability and portability between different systems and developers. Ant provides a "unifying technology and set of principals for building any software system" (Johnson)

Download Ant at:
Apache Ant Home Page

In order to learn the power and utility of a build system like Ant I recently, and successfully, took on the "Ant code Katas". Lets take a look at these simple tasks that demonstrate and teach the Ant basics.  Below in a few of the katas I have added an image of my code to give an example of what a build file looks like.
                                                                             

1. Ant Hello World

Create a script called helloworld.build.xml.  Invoking this script via "ant -f helloworld.build.xml" should print out "Hello World".  The script consists of a single (default) target called helloworld with a single line that invokes the <echo> task to print out Hello World. 

2. Ant Immutable Properties

Create a script called immutable.build.xml.   This script contains two <property> elements, one of which assigns the property "my.property" to the value "1" and the second of which assigns the (same) property "my.property" to the value "2".  Now create a target called "printproperty" that uses the <echo> task to print out the value of the property "my.property".  

If done correctly, this script demonstrates that build properties are immutable: once they are set, their value cannot be changed. 

3. Ant Dependencies

Create a script called dependencies.build.xml.   It should contain targets called "foo", "bar", "baz", "qux", and "elmo".  Each target should consist of a single <echo> task that prints out the name of its target. The default target is foo.

The targets should have the following dependencies:

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

Now invoke the build script using "ant -f dependencies.build.xml".   What is the order of targets. In particular, where is elmo called and why

Try invoking "ant -verbose -f dependencies.build.xml".   Note that Ant now tells you how it seriallzed the dependency structure.

Now make elmo depend upon bar and reinvoke the script.  Make sure you understand what happens.                                                                                        

4. Hello Ant Compilation

Create a file called HelloAnt.java, which contains a Java class called "HelloAnt" and a main method that prints out "Hello Ant" to the console.  This file should be in a src/ subdirectory.

Create a second file called compile.helloant.build.xml that contains a single target called "compile".  This target contains a single <javac> task that compiles the HelloAnt program.  You do not need Ivy.   You should be able to compile the program with "ant -f compile.helloant.build.xml".   These class files should be written to a build/classes subdirectory.

You may want to create src.dir and build.dir properties. 

5. Hello Ant Execution

Create a file called run.helloant.build.xml that compiles and runs the HelloAnt program.  It should use the <import> task to import the contents of compile.helloant.build.xml so you have access to those targets. 

Again, make this file as simple as possible. Provide a single target called "run", and make this "run" target depend upon the "compile" imported target so that the code is always compiled before being run. You should be able to compile and run the program with "ant -f run.helloant.build.xml".  

6. Hello Ant Documentation

Create a file called javadoc.helloant.build.xml that generates the JavaDocs for the HelloAnt program.  Once again, make this file as simple as possible; it can contain a single target called "javadoc" that invokes the <javadoc> task.  

The javadoc target should ensure that the HelloAnt program compiles, so you will want to import compile.helloant.build.xml   The javadoc html files should be placed in the build/javadoc subdirectory.  You should be able to generate the JavaDocs with "ant -f javadoc.helloant.build.xml". 

You can create a few properties to support the documentation process if you like.  You must ensure that the javadoc command completes without any warnings or errors.  This means you might have to improve your HelloAnt program!

7.  Cleaning Hello Ant

Add a target called "clean" to your compile.helloant.build.xml file. It should delete the build/ directory.

8. Packaging Hello Ant

Create a file called dist.helloant.build.xml.  It should contain a single target called "dist".   The dist target should have dependencies that compile, execute, and create javadocs for the helloant system (thus checking to make sure the system works correctly).   After all of these dependencies should be the clean dependency. 

The contents of the dist target creates a zip file containing the (cleaned) version of the current directory and all its subdirectories.  This zip file should be put into the (newly created) build/dist directory. Its name should be ant-code-katas.zip,  Unzipping this file should create a new directory called "ant-code-katas" which contains your ant kata files. 

To check your work, invoke "ant -f dist.helloant.build.xml".  Now cd to the build/dist directory, invoke "jar -xf ant-code-katas.zip".  This should create a new directory in build/dist called "ant-code-katas.   Now cd into that directory, and make sure that all of your kata files (and the src/ directory) are there, but that the build/ directory is not there.  Finally, invoke "ant -f dist.helloant.build.xml" in this directory. It should create a new build/dist directory containing yet another copy of ant-code-katas.

 Overall I have found that with a little practice Apache Ant is a very easy and powerful tool.  It is easy to imagine how necessary build systems like Ant are for certain kinds of software development.

Java Fueled Robots

  So you know how to program, your familiar with object oriented programming and you can write some fairly complex code, now where can you put your awesome skills to the test and have fun doing so?  How about designing the behaviour of a robot?
That sounds fun...
Better yet how about designing a complex, cannon wielding, slaying battle robot !
Now thats better.
   Robocode is an open source educational game started by Matt Nelson of IBM, you can get a good idea of what the game is all about here: ROBOCODE
Robocode allows you to design the look and behaviour of a battle robot, you can create anything from a simple robot that shoots its gun in the direction of an enemy, to one that utilises complex statistical analysis, your skill level is the only limit with these battle bots.  Well then, who do you get to battle and prove your superiority over given that you put your time and effort into making an effective killing machine? Robocode has a good sized online community where you can test your robots might against other programmers robots here: sourceforge 
  Okay so you are convinced and want to take on the quest of creating a robot capable of some mayhem, you need a starting point.  I would suggest starting the way I did, by completing the 13 robocode Katas.

Robocode Code Katas

1. The minimal robot. Does absolutely nothing at all. 
2.  Move forward a total of 100 pixels per turn. When you hit a wall, reverse direction.
3. 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.
4. Move to the center of the playing field, spin around in a circle, and stop.
5. 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.
6.  Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
7. Pick one enemy and follow them.
8. Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
9. Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
10. Sit still. Rotate gun. When it is pointing at an enemy, fire.
11. Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
12.  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). 
13. 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).

  These katas are a great starting place to really get familiar with the robocode system (in my opinion katas are a great starting place for any new concept).  Once completed you will have a firm grasp of how to use all of the robots functions and have a good idea about how to start coding a battle ready robot.  I found these katas to be fairly basic only spend significant time on a few of them, why? because I had to remember my trigonometry !  You know... that class you took years ago and never found a use for... well, its back.  I was actually very excited to be able to use things like the distance formula and tangent lines for something practical.  The most difficult aspect of these katas for me was reviewing and figuring out applicable trig. formulas.

So now that you know what Robocode is I am sure you want to see it in action. 
Here are katas 7 and 9 together, no destructiveness but a funny demonstration of their respective behaviours: 

 Go get started with Robocode, I guarantee you will not be disappointed.

FizzBuzz In Java - 4 and 1/2 minutes

FizzBuzz is a simple program that prints out all of the numbers from 1 to 100, one per line, except that when the number is a multiple of 3, you print "Fizz", when a multiple of 5, you print "Buzz", and when a multiple of both 3 and 5, you print "FizzBuzz".

Significance: 

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

http://www.hanselman.com/blog/YouCantTeachHeightMeasuringProgrammerCompetenceViaFizzBuzz.aspx


From the time I opened my IDE (eclipse) to when I successfully ran the FizzBuzz program took me right around 4 and a half minutes.  This is a very simple way to implement the FizzBuzz program, and it is not optimised for testing. I didn't run into any problems and had no coding errors during the process, this is mainly due to the fact that I had recently written this exact program about a week ago.  Most of my time spent writing this program actually originated from messing around with the IDE.  From my experience I would like to stress the importance of using a good IDE, because it will save you a lot of time in the long run, and being familiar with its functionality to avoid getting tied before you being a software project or during development.