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.

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. 

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?

Overview 

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.

Design

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. 

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

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.

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. 

FizzBuzz

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;  
2:    
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 {  
12:    
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:       }  
19:         
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.    

JNetTool: A Handy Networking Tool

Overview
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 (BrowserLauncher.java)

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"