Wednesday, December 14, 2011

Hale Aloha CLI Technical Review Part Deux

What started as another group's system ended up as our project in a surprise turn of events. Our initial group comprised of Branden Ogata, Jayson Gamiao and myself were tasked with enhancing the cycuc's CLI system. By enhance what I mean is add more functionality to the cycuc system. The functionality added are 3 additional commands that add new features, listed below;

  • set-baseline [tower | lounge] [date]
This command defines [date] as the "baseline" day for [tower | lounge].  [date] is an optional argument in YYYY-MM-DD format and defaults to yesterday.  When this command is executed, the system should obtain and save the amount of energy used during each of the 24 hours of that day for the given tower or lounge.  

  • monitor-power [tower | lounge] [interval]
This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds.  [interval] is an optional integer greater than 0 and defaults to 10 seconds. Entering any character (such as a carriage return) stops this monitoring process and returns the user to the command loop.  

  • monitor-goal [tower | lounge] goal interval
This command prints out a timestamp, the current power being consumed by the [tower | lounge], and whether or not the lounge is meeting its power conservation goal.   [goal] is an integer between 1 and 99.  It defines the percentage reduction from the baseline for this [tower | lounge] at this point in time.  [interval] is an integer greater than 0.  

These three commands were successfully implemented, however many difficulties were had during this process. The main difficulty our group had was using cycuc's system, since we were not familiar with their code, we first had to understand what exactly does what. Perhaps there is a little bias on our part since our group structured the CLI project a certain way, but cycuc's structure of their CLI was confusing. What ended up happening was that, we made changes to portions of their code so that we could successfully implement the three new commands. We implemented all the functionalities asked and also fixed some of the bugs left over by cycuc in this current system. As with the last project, we used the Issue Driven Project Management (IDPM) principals during this project. This time we were experienced with IDPM and things went along very smoothly. Our email exchange for this implementation reached close to 100. This was close to the number of emails we sent out for our CLI system. Similar to the last project I felt that most of the principals we had done successfully. We had a very good means of communications, all of us used the build tools available to aid our development and our system adheres to all relavent coding standards.

Keeping the three prime directives in mind;

1. Does the system accomplish a useful task?
Yes, the implemented commands give meaningful data in relation to WattDepot

2. Can an external user successfully install and use the system?
Yes, the most current version is located in the downloads page of cycuc's google code page. The userguide pages located in the wiki also has detailed instructions on how to use the system. 

3. Can an external developer successfully understand and enhance the system?
cycuc has left a developers guide in the wiki page for information on enhancing the system. What we had done to modify cycuc's code was to document the system further by expanding the comments within the code. 

What I feel we learned from taking over another group's system is that to fully enhance the system on hand you must know exactly what each line of code does. The difficulties we faced was understanding the structure of the code. We all have our own ways of thinking. In essence through this project I developed my software engineering skills and skillset. 

Friday, December 2, 2011

Hale Aloha CLI Technical Review

This is a continuation of the last blog entry I've posted. Essentially the purpose of this blog entry is to detail the findings of a complete review of a software system. The system on hand is the Hale Aloha CLI system developed by Team cycuc

The following is the technical review our team put together, with respect to the three prime directives.

Review Question 1: Does the system accomplish a useful task?
Below is a sample run of team cycuc’s system:

When we initially ran Team cycuc's .jar file there was a slight problem as it could not successfully run. Eventually one of cycuc's team members had updated the system for it to successfully run in console. For the most part, this system provides functionality as described in the assignment specifications. For example, the formatting of both the date and power / energy is not in the same as the sample output given.

> current-power Ilima-A
Ilima-A's power as of 2011-11-07 13:48:56 was 2.3 kW.
> daily-energy Mokihana 2011-11-05
Mokihana's energy consumption for 2011-11-05 was: 89 kWh.
> energy-since Lehua-E 2011-11-01
Total energy consumption by Lehua-E from 2011-11-01 00:00:00 to 2011-11-09 12:34:45 is: 345.2 kWh
> rank-towers 2011-11-01 2011-11-09
For the interval 2011-11-01 to 2011-11-09, energy consumption by tower was:
Mokihana  345 kWh
Ilima     389 kWh
Lehua     401 kWh
Lokelani  423 kWh

This may be an issue for some people depending on how they plan to process the data given. Reporting the data given in units such as kilowatt may be more desired. In the case of the rank-towers command, no units appear next to the output given which may confuse those not familiar with the system. Also, it appears that for the commands daily-energy and energy-since reports the wrong units with respect to the data given. From personal experience with the getData() method, the data returned by this method must be converted correctly to M Wh. In this case, 549 kWh should be 0.549 M Wh.

For example, the formatting under the current system is as follows;

> current-power Ilima-A
Ilima-A's power as of 2011-12-01T22:56:50.337-10:00 was 6756.08 W.

Some of the commands do not successfully return data at all, below is a sample of the code when the rank-towers command was executed.

> rank-towers 2011-11-01 2011-11-09
Connected to server successfully.
Rank Towers by Energy consumed, from 2011-11-01T00:00:00.000-10:00 to 2011-11-09T00:00:00.000-10:00
Caught an exception! Here's the message: 
400: Range extends beyond sensor data, startTime 2011-11-01T00:00:00.000-10:00, endTime 2011-11-09T00:00:00.000-10:00:   Request: GET

Sorry, due to technical difficulties, the data from WattDepot has been lost, the current range of datais from 2011-11-24 to the current date. 

> rank-towers 2011-11-25
Connected to server successfully.
Rank Towers by Energy consumed, from 2011-11-25T00:00:00.000-10:00 to null
Caught an exception! Here's the message: 

Essentially the system attempts to implement the four commands listed in its help menu. The exact usefulness of this system is debatable as we deem this version of cycuc’s system not ready for distribution.

Review Question 2: Can an external user successfully install and use the system?
In addition to containing the files for hale-aloha-cli-cycuc, the project site provides a very general idea of what the project is and does.  The home page has a brief description of the system and a picture that presumably provides an explanation for the group name.  This does give viewers an idea of what the system does, but not a very clear concept.  There is no User Guide page; instead is a page titled “PageName” that contains most of the information that the User Guide should.  The exception though is how to execute the system, which is not covered.  The distribution file in the Downloads section does include a working version of the system along with an executable .jar file.  The version number is included in the distribution folder name, allowing users and developers to distinguish between different versions.  These version numbers include the timestamp corresponding to the time at which the distribution was created, thus letting users and developers compare versions chronologically.  The numbers that actually indicate major and minor versions appear to have remained at 1.0 since the first downloads became available.

The tests of the system are shown below:

Valid Input:
> current-power Ilima-A
Ilima-A's power as of 2011-12-01T23:11:50.751-10:00 was 6333.76 W.

> daily-energy Mokihana 2011-11-25
Connected successfully to: org.wattdepot.client.WattDepotClient@2be2befa
509734.840423 MW consumed on 11/25/11 

> energy-since Lehua-E 2011-11-25
Connected successfully to: Lehua-E
Source: Lehua-E      
639210.4079087041 MW consumed since 11/25/11 

> rank-towers 2011-11-25 2011-11-26
Connected to server successfully.
Rank Towers by Energy consumed, from 2011-11-25T00:00:00.000-10:00 to    
Mokihana-06-telco      15385.932595232502
Lokelani-08-telco      16653.69566474599
Lokelani-12-telco      19451.44859161321
            Lehua-10-telco      19645.025624631904

       Invalid Input:
       > current-power Ilima-z
       Caught an exception! Here's the message: 
       Invalid source: Ilima-z
       java.lang.NumberFormatException: For input string: "Ilim"

> daily-energy Mokihana 2011-11-33
Caught an exception! Here's the message: 
Invalid timestamp: Invalid day 33 days are 1 - 31

> daily-energy Mokihana 2011-11-25
Connected successfully to: org.wattdepot.client.WattDepotClient@7114460
509734.840423 MW consumed on 11/25/11 

> energy-since Lehua-L 2011-11-27
Caught an exception! Here's the message: 
Invalid source: Lehua-L
java.lang.NumberFormatException: For input string: "Lehu"

> rank-towers 2011-1124 alsdjaflakdsf asdlkfjasd;flkajs fklajsdlfk sdf;lkafj k;djf ;akdjf;lkasfajs 
jdkl;asfj s;dlfkjas ;dlkfj asdl;kfj asfl;kasdj fasdl;kf jasl;kdfj as;lkfja sd;lfkajs ;lfkjas f;lkajsdf 
asd;lkfjas l;kdfjas ;dlfkjasd f;lkasjdf;lkas jf;laksjf as;ldkfjasl ;fkjasd;lfkjas
Connected to server successfully.
Rank Towers by Energy consumed, from 2011-11-25T00:00:00.000-10:00 to null
Caught an exception! Here's the message: 
//this tests overflows the buffer

Review Question 3: Can an external developer successfully understand and enhance the system?
Next, check out the sources from SVN (read only), and see if you can generate the JavaDoc documentation.  If it can be generated, review all of the JavaDoc pages to see if they are well-written and informative.  Do the JavaDocs provide a good understanding of the system's architecture and how individual components are structured?  Do the names of components (packages, classes, methods, fields) clearly indicate their underlying purpose?   Is the system designed to support information hiding

Next, see if you can build the system from sources without errors.  See if you can generate coverage information regarding the system.   Next, review the test case source code to see how the current developers are assuring the correctness of the functionality of the system.   By combining information from the coverage tool with review of the testing source code, you should come to a conclusion about how well the current set of test cases can prevent a new developer from making enhancements that break pre-existing code. 

Now read through the source code, and check to see if coding standards are followed and if the code is commented appropriately.  Is the code easy to understand, and is there neither too much nor too little commenting? 

Next, check the Issues page associated with this project.  Is it clear what parts of the system were worked on by each developer?  If an external developer had a question regarding a certain part of the system or a certain aspect of its behavior, could the Issues page be used to determine which developer would be the best person to ask? Does the current system appear to result from approximately equal input from all of the developers, or did some developers appear to do much more than other developers? 

Now check the CI server associated with this project.  Apart from Nov 22-24 when there were known outages, did any build failures get corrected promptly?  Was the system worked on in a consistent fashion?  Were at least 9 out of 10 commits associated with an appropriate Issue?  

Carefully document the results of your investigations into each of these issues, and use the results to come to a conclusion regarding the ease with which a new external developer could successfully understand the current system and successfully contribute with the current team to enhancing it in future.

The Developers’ Guide wiki page on the cycuc project site provides clear instructions on how to build the system in Ant.  The guide also includes information on the automated quality assurance tools used on the project.  Specific information about those tools is not given, but developers are informed that the verify task will run all of the automated quality assurance tools.  A link to the formatting guidelines serves to document the stylistic rules that the code is to follow.  The Developers’ Guide does not mention Issue Driven Project Management or Continuous Integration.  Similarly, instructions on how to generate JavaDoc documentation are not available, though the documentation does appear to come with the project in /doc.

JavaDoc documentation, as mentioned above, comes with the project in /doc.  However, developers may still generate JavaDoc files through Ant or Eclipse.  The JavaDoc documentation itself tends to be well-written, though there are some questionable points and the description is somewhat sparse.  Several methods lack descriptions in their JavaDoc documentation.  There are a few contradictions within the documentation, as in where the description for the printResults method (line 28) indicates that the text printed is based on days[0] while the parameter tag for days (line 31) states that days is ignored.  However, the JavaDoc documentation did show the organization of the system, and the names of the various components were well matched with their actual purposes.  The system does appear to have been designed to implement information hiding, with the Command interface serving as an example.  

The cycuc system builds without errors in most cases.  A timeout while attempting to access the server will cause the entire build process to stop, which accounts for the instances in which the build fails.  Aside from timeouts, the system builds properly.  

The data that Jacoco provides concerning test coverage does induce some slight concerns about the validity of the testing.  The halealohacli package has no testing at all.  Testing on the halealohacli.processor package covers 67% of the code and 58% of the possible branches.  For halealohacli.command, 94% of the code was executed in testing, while 59% of the branches were taken.  (These values seem to vary upon repeated testing; this may be due to the aforementioned timeouts.)  These low values for branch coverage in particular may stem from a lack of testing for invalid input.  As a result, none of the exceptions are checked.  The tests indicate that parts of the system work for a particular input; however, as there is only one test per test class (with the exception of TestProcessor) it is difficult to be certain that the system does behave correctly.  Thus, the existing testing will not necessarily stop new developers from breaking the system; the testing ensures that developers cannot treat valid input incorrectly, but does nothing to stop invalid input from causing problems.  

With regard to coding standards, there exist several minor deviations from the standards that do not affect the readability of the code.  The amount of comments varies: at times, there is a comment explaining every line of code, while at other points there are entire blocks of code without any documentation.  The deviations from the coding standards are provided below:

EJS-07: Include white space.
There is a lack of whitespace in the test methods of TestRankTowers, TestDailyEnergy, and TestCurrentPower.

EJS-13: Capitalize only the first letter in acronyms.
HaleAlohaClientUI class capitalizes “UI” instead of only capitalizing the first letter.  Admittedly, “HaleAlohaClientUi” might have been confusing to read.

EJS-29: Qualify field variables with “this” to distinguish them from local variables
In HaleAlohaClientUI:
        prompt (line 66)
        finished (line 27)
        scanner (line 130)
In Operation:
        string (line 35)
In CurrentPower:
        powerConsumed (line 24)
In DailyEnergy:
        energy (line 44)
In TestProcessor:
        processor (lines 37, 47, 59, 60, 75, 80, 81)

EJS-30: When a constructor or “set” method assigns a parameter to a field, give that parameter the same name as the field.
In Processor:
    setSource (line 135)
    setTimestamp (line 81)
    Note though that in both of these cases the methods are not actually setting the field to the parameter value.

EJS-31: Use uppercase letters for each word and separate each pair of words with an underscore when naming constants.
In HaleAlohaClientUI: 
    prompt (line 34)
In Operation:
    quit (line 10)
    help (line 12)
    currentPower (line 14)
    dailyEnergy (line 16)
    energySince (line 18)
    rankTowers (line 20)

EJS-33: Keep comments and code in sync.
In HaleAlohaClientUI:
    “When we have the processor class implemented...” (lines 38-39)
        The Processor class is already implemented as of this writing.

EJS-35: Use documentation comments to describe the programming interface.
In HaleAlohaClientUI:
    JavaDoc comments were used repeatedly where single-line comments would have been preferable.

EJS-53: Provide a summary description for each class, interface, field, and method.
In HaleAlohaClientUI: 
    isFinished (line 26)
In DailyEnergy:
    getEnergy (line 48)
In EnergySince:
    getEnergy (line 49)
In RankTowers:
    rankTow (line 56)
In Processor:
    getTimestamp (line 179)
    getBeginningTimestamp (line 187)
    getEndTimestamp (line 195)

ICS-SE-Java-6: Format JavaDoc summary lines correctly.
In TestDailyEnergy:
    test (line 22)
        The first “sentence” in the JavaDoc documentation is “1.”  This does not adequately describe the method.

Overall though, the code is readable; admittedly, the person testing the code had already implemented the project for a separate group and thus might be familiar with the objectives of the code, which would affect the results and opinions of the tester.  

Looking through the Issues page associated with this project, it is clear what parts of the system were worked on by each developer. This team utilized a variety of status options available to better inform an external developer what worked and what didn’t work with respect to project progression. In some cases, clarification in the form of comments show the decision making process this team used when dealing with issues. Since each issue described clearly explains what the task was, it should be easy for an external developer to determine which developer would be the best person to collaborate with. In terms of work input from all of the developers, it appears that some team members did more than others.

Turning to the CI server associated with this project, it appears all build failures were corrected promptly with a maximum latency of roughly 30 minutes. Also, looking through each successful build, this team showed that they were working on this project in a consistent fashion where at least 9 out of 10 commits associated with an appropriate Issue.

Tuesday, November 29, 2011

Issue Driven Project Management

Recently I've partaken in a group project with two fellow software engineers (Branden Ogata and Jayson Gamiao) in which we developed a Command Line Interface (CLI) for energy and power consumption in the UH Manoa Dorms. More specifically we enhanced the wattdepot katas to have a more user friendly front end. This project also used many of the Issue Driven Project Management (IDPM) concepts such as breaking a project into meaningful tasks. Using IDPM really made our lives easier, since everyone had a specific job to do. At first I thought that this project would've been done faster if one person just coded everything since, he/she would know how the code worked. However I was proved wrong because each project member contributed and showed their areas of strength in programming terms.

To briefly explain what IDPM is; In software project management things can get very complex and the larger the project is the more complex it will be. Essentially IDPM has project members working on tasks, which are small jobs to complete the overall project. The project members should have a task to work on at all times and tasks should be meaningful. My overall attitude to what worked with IDPM was that it provided a framework in which group members know what to do and what other group members are doing at all times. This is evident with email notifications with each update and build tools verification.

The project implemented the following commands

  • current-power [source] Prints the current power consumption of the source
  • daily-energy [source] [date] Prints the amount of energy that the source consumed on the given date
  • energy-since [source] [date] Prints the amount of energy that the source consumed from the given date to now
  • rank-towers [date] [date] Prints the Hale Aloha towers in order of energy consumption between the dates given
  • help Prints a list of commands that the user may type in 

The functionality built in was a soft of idiot proof user interface where if users intentionally try to break the system, an error message would be printed. The functionality that was not implemented was the addition of more commands. The wattdepot API allows more commands than the 4 listed above, but for brevity sake our group chose to implement those 4 as a starting point. This project leaves room for upgrading the code, at this page.

The Google code page for this project is located here

Tuesday, November 8, 2011

WattDepot Fun

Recently I've partaken in a kata exercise using the WattDepotClient. What is the WattDepotClient you ask? Well it is basically a Java Class that holds a lot of energy data from the dorms located at UHM. The purpose of the katas was to manipulate this energy data and print the selected data. All in all I completed 5 out of the 6 katas here, due to the difficulty in some of the katas I did not have enough time to finish all of them. What was most fun about these katas was the fact that we were given a system/API and was told to understand the methods and utilize them for our kata solutions. Most likely that without access to the API, the katas would've taken much longer to finish. It took roughly a day per kata but kata 3 was most difficult in my opinion. However I had gained insight to a possible solution with the help of my fellow software engineer, Russell Vea. 

I felt that WattDepot was a excellent exercise in a sense that it provided real world data. All the data collected were actual energy/power usage from dorm rooms, and it was fun knowing that I had access to this data.   

Tuesday, November 1, 2011

Energy in Hawaii

Living in Hawaii, we unknowingly pay more for our energy use than the mainland. Coupled with the fact that our primary resource to create power is gas, we put ourselves in a situation where Hawaii is at the mercy of Gas. I know this firsthand because recently I just started to drive to school, rather than catch the bus. However as Hawaii tries to shift towards a clean energy solution, I think of all the pros and cons of this effort.

What was interesting to me was the fact that Hawaii pays around 30 cents per kWh while the mainland only pays 10 cents. This is a prime example of the 'paradise tax' we pay for living in Hawaii. Since we do not have a 'super grid' like the mainland, we rely heavily on electric plants that consume gas as a means to make energy. Keeping in mind that Hawaii is in a prime spot for other renewable energy alternatives, such as wind, solar, and geothermal. 

Energy in Hawaii is difficult to describe, but I would summarize it in one word, complacency. Most of the residents here are either unaware or don't care for the clean energy movement, and most likely they'll grumble and whine when it is too late. Hawaii clean energy initiative is a great idea but it requires a collective effort from the community. For example a small group of energy enthusiasts won't make a dent when hundreds of thousands of energy users don't preemptively change their energy usage.

I like to use the analogy of a person that thinks their actions doesn't make an impact on this situation as an example of the problem we face. If people in Hawaii don't begin to try become more energy efficient, I would ultimately be paying the price by a higher electricity bill, and paying an arm and a leg for gas. This bystander effect will be the biggest challenge that the HCEI would face in my opinion. However a lot of people are making efforts to promote clean energy in Hawaii.

For instance Jay from HNEI has received a grant from the US Department of Energy to do work using neat energy meters. These energy meters are a great tool to provide real empirical data on energy costs. For example if I installed an energy meter and suddenly realized that my energy usage has jumped twofolds just by watching tv, I would reconsider my habits to try reduce my energy usage. Hopefully this issue does find a solution to itself in the future, as Hawaii is in dire need for a clean energy solution.

Tuesday, October 25, 2011

Five Important Lessons Learned In Software Engineering

1. Why should software developers always keep the three prime directives in mind?
    The three prime directives ensures that a software system is a well developed and easily maintainable code. The three prime directives are found here.

2. The FizzBuzz program makes use of the assertEquals jUnit test cases, what would be an example test case for this program?
    Since the FizzBuzz program tests for number cases with, FizzBuzz being printed if n is divisible by 3 or 5. Fizz printed if n is divisible by 3 and Buzz if n is divisible by 5. We could use the test case assertEquals("Test for FizzBuzz", "FizzBuzz", 15) for example.

3. Before committing changes to a project hosted on google code which ant target should be run?
    The verify target should pass to ensure the next person working on the project that it is a working version of the code.

4. What kind of bugs would Checkstyle find that PMD wouldn't?
    Checkstyle would find coding standard errors while PMD would find errors that deals with the code. Such as Bugs, dead code, suboptimal code, overcomplicated expressions, and duplicate code.

5. Of the three review methods, which has the fastest turnaround?
    Walkthroughs have the fastest turnaround, minimal overhead. With little/no preparation and no formal process. The other review methods include technical reviews and inspections. Technical reviews' goals include defect discovery and ambiguity resolution. Inspections attempt to detect and remove all defects.

Thursday, October 20, 2011

Google Code Project Hosting

I've been working with hosting my Robocode robot on Google Code's project hosting site. So far my experience with it has been most satisfactory, as I was able to successfully host my distribution on Google Code and sync it with my SVN client.  I've tested the SVN capabilities by uploading all the files for my project onto the truck portion of my project webpage. The most difficult thing I had to troubleshoot was the formatting of the wiki pages to adhere to my liking. I was most surprised with the quality of hosting projects on Google Code. It was very easy to create a page and start uploading and creating wiki pages. Plus the fact that other developers are able to join the project by just adding their email makes Google Code very simple.

A link to my robocode robot I've been developing is here. Overall I look forward to using the Google Code project hosting site to work on future projects, since it is a great free option for developers. 

Tuesday, October 11, 2011

One robot to rule them all

Alas, my robot project has come to an end. However there is still one more act in this play, the epilogue of my journey of which is called robocode. The name of my competitive robot is called RobotDevil because just like the real devil, you never know what (s)he is going to do, or not do... The inspiration of my robot was the idea of a snowflake. They say that no two snowflakes are alike, and I would like to believe that when a user runs RobotDevil, no two instances will behave the same. Without further ado, whose cuisine robot will reign supreme?

If I asked you to pick a number between 1-10 and use that number as some sort of 'random' generated output, how 'random' would that be? The same theory applies to what I had attempted in my robocode project. I had set out to try create a robot that ideally will not win 100% of the time yet not lose 100% of the time either. A rudimentary coin flip of a robot would be my esoteric description. In essence I opted to build a robot that would display 'random' movement behavior, an optimal firing scheme and sophisticated tracking logic.

Movement: Movement is the heart and soul of RobotDevil, since our movement paradigm is limited to the battlefield and 360 degrees of turning options, the 3 factors in movement for RobotDevil was the degree of the turn, length of the turn, and condition of a hit wall. The general strategy for moving the robot was to create unpredictable behavior, since most advance robots will attempt to predict RobotDevil's next movement. The only downside to this approach is that RobotDevil may not make the most logical decisions, such as moving towards an enemy bullet or walls.

Targeting: Targeting is relatively simple in the design of RobotDevil, once an enemy robot has been scanned by our robot, the robot will adjust the firepower to either the MAX_BULLET_POWER or 1. RobotDevil continuously sweeps the area by rotating the radar and gun 360 degrees.

Firing: Firing is simple since once RobotDevil sees another robot it either fires a weak bullet or the strongest bullet. The measure taken to anticipate the movement of an enemy robot was not taken since our movement is not predictable.

Results (Out of 100 rounds)
RobotDevil 2606 (14%) V.S. Walls 16575 (86%)
RobotDevil 17549 (52%) V.S. RamFire 16466 (48%)
RobotDevil 1867 (10%) V.S. SpinBot 17423 (90%)
RobotDevil 10136 (59%) V.S. Crazy 6993 (41%)
RobotDevil 20612 (68%) V.S. Fire 9593 (32%)
RobotDevil 15093 (51%) V.S. Corners 14241 (49%)
RobotDevil 2664 (12%) V.S. Tracker 19446 (88%)
RobotDevil 18020 (100%) V.S. SittingDuck 0 (0%)

As the results show, RobotDevil performed horribly against Tracker, SpinBot and Walls. Partly due to the fact that these robots stay at a distance and attack rather than approach other robots. I suppose one design improvement RobotDevil could use is a better tracking system. 

Majority of the testing was done to ensure that the movement of RobotDevil was truly random. So jUnit tests to check between two length in distances traveled are not the same. It is suffice to say that the tests were a good indicator of random movement but this brings me back to my original question of how random is random.

Lessons Learned
I felt that this robocode development experience provided myself with invaluable experience in jUnit and simple software development principals. It was a great introduction in testing practices such as behavior in code. Perhaps after seeing some of the robots developed by my fellow software developers, it will provide me with inspiration on possible future implementations in RobotDevil.

Thursday, September 29, 2011

Using ant as an alternative to make?

I'm a bit biased when dealing with build systems, because I've worked with the very simple make build tool.  Yes it doesn't have all the bells and whistles as ant does but it gets the job done and it was popular before build systems took off. (make was the original build system hipster)

I approached ant just like how I would approach women. I would try to RTFM look at example files and try to understand how it works by just reading the code.  The code I tried to analyze first was the XML files packaged in the PMJ.dacruzer folder. I took a look at the build.xml file, only to be stumped as to what the heck was going on after 30 minutes. However the structure of the build.xml file was similar to a make file, which led me to believe I was on the right path.  I attempted to try complete a couple of ant katas, as a way of getting my feet wet. The katas dealt with cleaning, compiling, javadocs and packaging a system.

Eventually I turned to the ant manual for more information. The manual has a lot of information but it was a bit difficult to understand what exactly was going on. I had also asked a couple of software developer friends of mine on some insight about some of these katas.

In the end I was able to finish all of the katas, except the packaging kata.  The difficulty I had with this kata was the creation of the zip file.  However from completing all the other katas I have learned a lot about ant. For example I learned about basic dependencies, immutable properties, and working with java files within ant. I still appreciate make but ant seems to provide software developers with a much more convenient tool than make. The fact that ivy and ant works together to provide a build system + dependency management tool for a software developer, is awesome.

Tuesday, September 20, 2011

Robocode Katas

When thinking of katas the first thing that comes to my mind is the next karate kid.  More specifically the scene where Julie-San asks Mr. Miyagi when she was going to start breaking boards.  Mr. Miyagi responds by telling her to continue washing his car, remember 'wax on, wax off.'  This is where the beauty of Katas come in, it might seem repetitive to wash a car, or print a hello world program, however the underlying idea is that you are sharpening specific skills.  Katas are not necessarily easy, some katas may challenge you and bring you to the brink of frustration and insanity.  I welcomed this idea of a programming challenge and applied the code kata idea on building robots.

danger danger will robinson... these aren't the robots you're looking for. In fact these robots are part of an open source game called Robocode.  These robots fight for the user and set out to destroy other robots, until there is only one.  Robocode is a game in Java, where programmers can build their robots to do all sorts of fantastic things. These robots are very intricate, because of all the things the user must account for when building his/her ultimate robot.  Such as the direction the robot is facing, the direction the gun is facing, the enemy robot, and the strength of attack. 

  • 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.
  • 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.
  • 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). 
I've successfully finished the code katas listed above, however I've yet to implement a working version of the following robots
  • Position06: Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
  • 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). 
The main problem I've had with these 2 code katas is that it involves the use of trigonometry and that is a field where I lack in. Although I have gained a lot of knowledge in developing a basic robot that involves moving, firing, and scanning. While doing these katas I found myself looking at the Robocode API since it was a very useful page displaying the functionality of everything in Robocode. Also I've gotten more comfortable reading other people's code. One of the code katas asked for the robot to reach the middle, and a researcher at IBM had posted his code that solves this in an intricate way. Overall my ineptness to use trigonometry haltered the completion of the last two katas.  

My future plans on Robocode would involve building a competitive robot that will incorporate trigonometry. I will focus on the firing aspect on my competitive robot, as this will indefinitely help fire me into robot glory. 

Wednesday, August 31, 2011


Recently I implemented the FizzBuzz programmed discussed on our first day within the Eclipse IDE. The task was to implement the FizzBuzz program within the Eclipse IDE. The time it took total was 9 minutes to code the program, in addition it took another 11 minutes to comment and verify the output of the program. JUnit wasn't used for verification and so each output was examined for its validity. The main problem I had faced was cleaning up the code, so it isn't 'messy'.  

Cleaning up the code involved creating a FizzBuzz object that handles the logic portion of the problem. The getOutput method within FizzBuzz will return a string representation of the number taken. There is still more room for improvement in the code, primarily incorporating software engineering principles in the code. Below is the source code for my FizzBuzz implementation.

1:  package edu.hawaii.ics314;  
3:  /**  
4:   * @author Jason Yeo  
5:   *   
6:   * FizzBuzz program should print out all of the numbers from 1 to 100  
7:   * one per line, except that when the number is a multiple of 3  
8:   * it will print "Fizz", when a multiple of 5, it will print "Buzz"  
9:   * and when a multiple of both 3 and 5, it will print "FizzBuzz"  
10:   */  
11:  public class FizzBuzz {  
13:       public static void main(String[] args){  
14:            FizzBuzz fb = new FizzBuzz();  
15:            for(int i = 1; i < 101; i++){  
16:                 System.out.println(fb.getOutput(i));  
17:            }  
18:       }  
20:       /**  
21:        * @param number  
22:        * @return String  
23:        *   
24:        * getOutput will accept an integer ranging from 1 to 100, and   
25:        * will return the respective String output. The String output is  
26:        * based on the requirements set by Professor Johnson in his requirements   
27:        * for the FizzBuzz program.  
28:        */  
29:       public String getOutput(int number){  
30:            if(number % 15 == 0){  
31:                 return "FizzBuzz";  
32:            }  
33:            else if(number % 3 == 0){  
34:                 return "Fizz";  
35:            }  
36:            else if(number % 5 == 0){  
37:                 return "Buzz";  
38:            }  
39:            else{  
40:                 return String.valueOf(number);  
41:            }  
42:       }  
43:  }  

Note that I had modeled my code after the solution created by the class.    

Monday, August 29, 2011

JNetTool: A Handy Networking Tool

Sourceforge holds a wide array of open source projects and to my surprise I found a Java related project that dealt with networking.  The reason I chose the JNetTool was because I am currently learning the workings of TCP/IP and all of its intricacies.  The description for JNetTool is as follows, "A network tool with gui for whois, ping, traceroute, ns lookup (dig,dns), portscan, network calculator, visual net plan - written in java."  Indeed all of the components in JNetTool makes for a handy networker's 'pocket knife'.

I will demonstrate the features within JNetTool and show that this package satisfies the three prime directives.

1. The system successfully accomplishes a useful task.
The one component within JNetTool that I was very excited to see was the Net-Calc option.  Subnetting is somewhat a tedious task for me and having a subnet calculator makes life much easier.  The Net-Calc option has all your standard subnetting options such as network class/CIDR, subnet mask, number of hosts, network and broadcast address and IP range.  

Example of the Net-Calc tool in JNetTool

What JNetTool does to go above and beyond is the option to 'show next subnet with this number of hosts', which will iterate subnets with the designated number of wanted hosts.  The PortScan option offers a basic portscanning tool.  While it is not as robust as Nmap it does its job.  

Example of a port scan done on uhunix (selected ports for brevity)

2. An external user can successfully install and use the system.
JNetTool's documentation page, holds an up to date change log and links to relevant pages. Unfortunately the developer seems to be have an extensive documentation in German, which I am unable to understand.  However within the JAR file was several .txt files describing his project.  There were no problems downloading and installing JNetTool.  Since the project was packaged as a JAR, it ran as a applet when opening it.  The fact that I was able to run JNetTool on my first try is a good indicator of this system meeting the 2nd prime directive. 

3. An external developer can successfully understand and enhance the system. 
The source code for JNetTool is available on sourceforge and is well written as it is extensively commented.  Since there are several tools within JNetTool (whois, dns, ping, traceroute, etc...) the source code is somewhat large and would take time for me to fully read and understand how it works.  However this is a minor problem since the code is structured and commented well.  

Example of the source code for JNetTool (

Overall I feel that running and examining JNetTool was a great way to get my feet wet in the realm in software engineering.  I would love to venture out and possibly create/enhance JNetTool in the future. I believe I'll find motivation in the great words of Captain Jean Luc-Picard... "make it so"

Wednesday, August 24, 2011

Hello Blog;

//First post for ICS 314.  I hope to cover many of my interests and related topics in this blog.