Taking ICS413

ICS 413 Software Engineering class was a quite of an experience. I got to brush up on my java skills, learned how to use numerous useful tools, and got to be involved in several group projects all in one semester. It may sound overwhelming at first, it might be at first, this class seemed to have gotten better and better as the semester went by.

The Robocode part of the class was rather challenging and quite interesting at the same time. Robocode was interesting because it gave us a good reason to perform well, that is to win the tournament. Even though I was disqualified for implementing a class I was not supposed to, it was still a good experience.

The group project aspect of this class is when the class starts to get really interesting. Dealing with teamates can be really fun or difficult, but you will certainly learn how to deal with tough situations that could arise in place like this. I would have to say, though, learning how to use the Wicket framework was not the most interesting part of the class. I remember that I can spend so many hours trying to figure out how to fix a bug, yet still I cannot find that one line that would magically solve the entire problem. Dealing with wicket was rather painful, but I would like to believe that it had given me a good life experience.

Finally, finishing up the version 2.1 of our wicket application was a satisfying experience. I certainly would not have been able to experience building such a complex application in any of the other classes offered in this department. Overall, I feel that I learned alot through this course. I would definitely like to take the next sequence of this course if I get the chance.

Eco-Depot 2.1

Here is my final release of EcoDepot project. This project I must say, was not easy. It required me to study the new framework wicket in about two months and be able to produce a quality application. It seemed like an impossible task at first, at least for me, though in the end it was a good experience.

The improvements I've made since our release of version 1.0 includes, the addition of google charts and traffic light functions. These two were the main functions of our wicket application and was quite possibly the most difficult to implement. I have learned throughout implementing the google chart and also for the most part of the project that it is extremely difficult to learn a completely new framework in a short period of time. Most of the tasts that were assigned to us takes a good amount of reaserch work before you even begin coding. Even though I thought some of the tasks were brutal, I believe in the end it taught me some good lessons.

I have also modified the google chart so that it can deal with hourly/daily/weekly datas. This did not take much of an effort, since most of the fucntions required to accomplish this task was already created previously. I also modified the chart so that it can also print Carbon Emitted values. This also was quite a easy task, for the same reason that I have mentioned above.

I have also made some modifications to the traffic light page. The first modifcation was to store cached information of the traffic light value inside the server so that when a next user access the same page, depending on the time access, he can reuse the value without having to recompute it. I also modified the code so that the traffic light is updated every 60 seconds automatically. This was done via the use of Ajax and this was a fairly straightforward task once you have understand how Ajax works.

Overall, I think that this version of EcoDepot came out to be pretty decent. EcoDepot 2.1 can be downloaded here.

Greenometer Review

After finishing up our very first Group project in Wicket, it is now time to review other people's work. I was assigned to review the Greenometer project. I would have to say that I was most impressed with their graphical interface. It is needless to say one of the most impressive looking project in class and their use of Google chart tool made the system a lot more user-friendly.

I would say that the system fulfils most of the project requirements. It does what it is supposed to do in a very neat fashion. I liked the addition of the traffic light object which indicates the current carboncontent level. Their source code was nicely organized into 3 packages with each of them having a specific function. I noticed that there were some files in the system that contained functions that were never being called. I am not sure why the functions are there, but I would assume that taking those functions out of the source code would increase the code coverage data in Hackystat significantly. I also suggest making test cases which tests for failure cases. This should cause the system to call some of the catch{} statements and should increase the coverage data even further.

Their Hackystat and continuous integration data indicates that they correctly configured the system to perform daily builds and regular builds after each commit. Their data also shows that they have committed their changes regularly and also shows that each person in the project have contributed to the work fairly well. The only problem with the data was the low Test values due to missing test cases, which can be easily fixed in their next version. I would say that Greenometer group did a pretty good job with the project, and I sure hope they keep up the good work!

My project review can be downloaded here.

Eco-Depot 1.0 Release

Our new Eco-Depot project is sort of an addition to our previously build WattDopot program. The new project implements the Wicket language which is used to connect Java with an html page. Wicket proved to be an extremely useful tool, while it was very difficult to learn initiallly. I am not sure about other people, but it took me hours of reading the "Wicket in Action" to finally understand how to use this new tool. It seems as though that I didn't have enough time to actually use this new tool to its full potential, as the code I punched out seemed that it simply does what its supposed to do.

This was also our first project to work in a group of 4. I was initially excited with the idea, though as time went on, and after realizing I had many other classwork to complete over the same week, it turned out to be quite of a stressful experience. I realized that we were very late in staring our project, and that we could have started much earlier if we had communicated better. I am not sure if it is because the team size got larger, but we weren't able to communicate with each other well, which delayed our project significantly.

One big mistake that we made in my humble opinion is that we never discussed about the design of our project thorougly. As I began working on my part of the project, I realized that I had no idea how other teamates wanted the project to look like. It was already late in the week so I decided that I would write down my initial design and commit the change, and see if everybody likes it. I am still not sure if that was a good move, but it was a move atleast, that was all that mattered to me at that point.

The rest of the project I think went rather smoothly, compared to how it was earlier.
The only problem was that I had work on a different project while my team-mates were working intensely on the project. I got lost momentarily then, but other than that the project came out quite well I believe.



I liked how our project came out, and I hope that for our next project we can improve on our teamwork a bit more. Our project "Eco-Depot" can be downloaded here.

Wattdepot Version 2.0

It is now time to release the version 2.0 of our Wattdepot program. In this version, we implemented some brand new commands that a user can work with. We also improved our code in many different ways. We have implemented a few more interfaces to make the code clearer and easier to read, and we have also implemented hash code so that we can map a class instance into a string literal. This way, our code looks a bit nicer and now it is somewhat easier to make modifications if need be.

My WattDepot Version 2.0 can be downloaded Here.

We had numerous problems trying to transfer all our methods into separate classes however. It seems that rewriting our code in this style was not an easy task. I ran into numerous problems with variables and class instances. When we managed to put together, we realized how easy and simple the program looks.

We were also asked to asnwer some questions which can be derived by using or tweaking some of our commands. Following are the questions:

• What day and time during the month was Oahu energy usage at its highest? How many MW was this?

** During most of November the usage seemed to be at the highest. My value came out to be 1630 lbs Co2/MWh

• What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

** Minimum value occurs throughout early morning of November. The value was around 1597 lbs Co2/MWh.

• What day during the month did Oahu consume the most energy? How many MWh was this?

** So far the most energy consumed is 1630 lbs Co2/MWh.

• What day during the month did Oahu consume the least energy? How many MWh was this?

** So far the least consumed energy is at 1597 lbs Co2/MWh.

• What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?

** Dirtiest carbon were emitted at November 4th and 5th, with value 29959 lbs.

• What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?

** Least carbon were emitted at November 7th or 8th at value 22908 lbs.

Review Experience

This week's coding review have helped me a lot. Looking at other people's code and to see how they approached the project was very interesting and a good learning experience. While viewing others' codes, I sometime wondered to myself "why are they writing it this way" or "how can this be efficient?", but as I took my time and began to figure what that piece of code actually doing, I oftentimes thought to myself that what they are doing is actually a more efficient and organized way of coding.

While I was reviewing other people's codes, I cannot help but to notice that most of the codes were very well documented and commented. This struck me because I could not remember if I documented my own code that well. All I could remember about my code is that I rushed through it in an attempt to finish up all of the commands. Now I know that if there are improvements that can be made into my code, one of them would be to add more documentation and comments. I thought most of the code I reviewed was very well done. Even though their code may not have the full functionality of the commands, its interfaces and such were build quite well.

I would have to say that viewing somebody else's review about our project was also very helpful. It seems that everybody who was assigned to do our project review have completed it, and they did a very good job. I have learned through looking at some of our review that we still need to work on our interfaces and class structuring. This seems to be a somewhat of a difficult task, but since now I have a better idea of how to structure our code, I think we can do it. This code reviewing overall was indeed a very helpful experience.

My WattDepot Project Reviews

Punching out lines of code while your brain is in your programming mode feels great, and one cannot help but to assume that the codes you just typed out was perfectly written. Unfortunately this is not always the case, and it certainly helps to have other people have a look at your code to make sure that you have punched out a quality code.

Our assignment for this week was to review other group's projects. For this task we followed this guideline to make sure that we have checked every part of the project. Interestingly, our professor instructed us to be as evil as possible when reviewing certain parts of the project, especially when it comes to checking for bugs. I started by compiling the code, and running it with variety of different inputs to see if the code checks for input errors. Following are the two projects that I reviewed.

elima
eono

WattDepot

WattDepot is an interesting project that we have been working on over the past week or so. Its function is to retrieve various useful information such as energy consumption, carbon emission, or power consumption from the WattDepot server. My experience with building the WattDepot program was a valuable one. It seems that the world is headed towards the notion of energy conservation and knowing how to deal with this type of application certainly would benefit us in the future.

This WattDepot project turns out to be our first real group project this semester. As our class exercise, me and my group mate discussed about the overall design of the project and also about how we wanted to work on the project and when. I feel now that it is really important that we discuss the details of the project before we start touching the code. That way, we can both be sure that we know exactly what to do. It sounds very simple, but it is an important concept.

Building our project was not an easy task. The assignment basically was split into 10 parts, or commands. My group mate and I decided that we will split the work in half and this idea turned out to be quite efficient. The only problem we had with building our commands was that it was fairly difficult to check if the output we got was indeed the correct one. Only after checking with other groups we were finally able to see whether the output was correct or not. Although this was quite a bit of inconvenience for us, it actually motivated us to go out and ask around other people about their outputs.

Building our interfaces was a farily complicated task. We were able to set up our project so that it implements multiple interfaces for different set of codes. For example, we set up an interface for class file that contains all the functions that deal with the commands, and we set up another interface for class file that deals with parsing of strings. We were; however, not able to write all of our commands into separate classes, and have the them hash to String variables. We were able to build about 9 test cases that test various functions in our project. I would say that most part of our project turned out fairly well. We may need to work a little bit harder on building the functions into separate classes.

Here is my distribution file.

Continuous Integration

Last week in class, we were introduced to a yet another convenient tool called Continuous Integration. Continuous Integration is a tool that helps us stay in track with our project and reassure that the project in the repository compiles and passes all the test cases. It can also provide you with a graph indicating all of your test case results.

We are going to be using this Continuous Integration for our upcoming project. Our project is fairly big in size, so implementing this tool should help us manage our projcet and keep in track of changes and failures quite easily. We are also using the Continuous Integration tool with hudson. Hudson enables us to schedule periodic builds and tests so that we can be certain that every little changes that we made into the project does not result in unsuccessful builds or failure to pass the test cases. The idea here is that sometimes, running the test cases only once after making some serious changes to the project may not be sufficient. Instead, hudson allows us to continously build and test to make sure that the project is in a good shape.

I am quite pleased with my experience with Continuous Integration and hudson. The set up process was fairly straightforward and I was able to observe the automated build and test almost immediately. I hope to employ this tool for my future project as it is a great tool that reassures that my project is ineed in a good running shape.

Midterm Questions and Answers

Here are the answers to my 10 questions:

1. Define the term 'security through obscurity' and describe why it is not a good practice.

Security through obscurity refers to the use of secrecy as a mean to develop a secure application or system. It is usually not a good practice because it can still contain vulnerabilities that could have otherwise been detected if it were publicly disclosed.

2. Explain why writing "Please send your reply to...." after posting your question on a forum is bad.

Because most posters would like to earn recognition through answering your questions, and by asking them to reply privately would not help them achieve that goal.

3. What does the command 'ant -f emma.build.xml' do?

Emma is a coverage tool that generates an html report indicating how much lines of your code is actually being executed. The command emma.build.xml executes Emma.

Consider the following program written in Java for questions #4 - 10.

/**
* Simple program that fills an array with integers.
* @author Daniel Colton
*/
PUBLIC class MyList {
PUBLIC Integer TOP = 0; // Tracks the TOP INDEX
PUBLIC Integer[] intArray = new Integer[10]; // Array OF integers
/**
* Create an instance of MyList and insert 10 integers
* into it.
*/
PUBLIC static void main(String[] args) {
MyList list = NULL;
MyList newList = new MyList();
FOR (INT i = 0; i < 10; i++){
list.ADD(i);
}
}
/**
* Adds an integer into the array.
*/
PUBLIC void ADD(Integer i) {
intArray[top] = i;
TOP++;
}
/**
* Prints the ith elemnt of the array.
*/
PUBLIC void PRINT(Integer i) {
String MESSAGE = new String("List";
System.out.println(MESSAGE+"["i+"] = "intArray[i]);
}
}

4. List at least two lines that can be considered a CheckStyle error.

- Missing '@param' statement above lines 'public void add(Integer i)' and 'public void print(Integer i)'.
- Missing javadoc coments above data variable declarations at lines 'public Integer top = 0;' and 'public Integer[] intArray = new Integer[10];'.
- Use of ambiguous naming convention for variables such as 'i' at lines 'public void add(Integer i)' and 'public void print(Integer i)'

5. List at least two lines that can be considered a PMD error.

- Unused variable 'newList' at line 'MyList newList = new MyList();'.
- String variable 'MESSAGE' at line 'String MESSAGE = new String("List");' should be declared as a string literal (String MESSAGE = "List").

6. List at least one line that can be considered a FindBug error.

- A null pointer dereferace for the 'List' variable at line 'MyList list = null;'.

7. Rewrite the program so that it passes all three of the above mentioned tests.

I also added the two functions, getValue and onProgramEnded, which are useful when writing JUnit tests for Questions #8, 9, and 10.

/**
* Simple program that fills an array with integers.
* @author Daniel Colton
*/
PUBLIC class MyList {
/** Tracks the top index. */
PUBLIC Integer TOP = 0;
/** Array of integers */
PUBLIC Integer[] intArray = new Integer[10];
/**
* Create an instance of MyList and insert 10 integers
* into it.
*/
PUBLIC static void main(String[] args) {
MyList list = new MyList();
FOR (INT i = 0; i < 10; i++){
list.ADD(i);
}
list.onProgramEnded();
}
/**
* Adds an integer into the array.
* @param index refers to the index position in the intArray.
*/
PUBLIC void ADD(Integer INDEX) {
intArray[top] = INDEX;
TOP++;
}
/**
* Prints the ith elemnt of the array.
* @param index refers to the index position in the intArray.
*/
PUBLIC void PRINT(Integer INDEX) {
String MESSAGE = "List"
System.out.println(MESSAGE+"["INDEX+"] = "intArray[index]);
}

/**
* Returns the ith element of the intArray.
* @param index refers to the index position in the intArray.
*/
PUBLIC INT getValue(Integer INDEX){
RETURN intArray[index];
}
/**
* This method is called after the program executes.
*/
PUBLIC void onProgramEnded(){
}
}

8. Write an assertion test for the program that you have re-written in question #7.

Following assertion test checks to see if all values are properly inserted into the integer array:

import static org.junit.Assert.assertEquals;
import org.junit.Test;

/**
* This is an acceptance test that tests if an integer value
* is inserted into the array.
*/
PUBLIC class TestMyList {
@Test
PUBLIC void testIfInserted() {
MyList list = new MyList();
FOR (INT i = 0; i < 10; i++){
list.ADD(i);
}
boolean isInserted;
FOR (INT i = 0; i < 10; i++){
IF (intArray.getValue(i) != NULL) {
isInserted = true;
}
ELSE {
isInserted = false;
}
assertTrue("Check if inserted" isInserted);
}
}
}

9. Write a behavioural test for the program that you have re-written in question #7.

The following program checks if the values are inserted in the correct order (from 0 to 9):

import static org.junit.Assert.assertEquals;
import org.junit.Test;

/**
* This is a behavioural test that tests if the integer values
* are inserted in the correct order.
*/
PUBLIC class TestMyList2 {
@Test
PUBLIC void testValuesInserted() {
MyList list = new MyList();
FOR (INT i = 0; i < 10; i++){
list.ADD(i);
}
FOR (INT i = 0; i < 10; i++){
assertEquals("Check insert order" list.get(i), i);
}
}
}

10. Write a unit test for the program that you have re-written in question #7.

The following program tests if the getValue method returns the correct value from the integer array:

import static org.junit.Assert.assertEquals;
import org.junit.Test;

/**
* This is a Unit test that tests if the getValue method returns
* the correct value from the list.
*/
PUBLIC class TestMyList3 {
@Test
PUBLIC void testGetValue() {
MyList list = new MyList();
FOR (INT i = 0; i < 10; i++){
list.ADD(i);
}
assertEquals("Test getValue" list.get(0), 0);
assertEquals("Test getValue" list.get(9), 9);
assertEquals("Test getValue" list.get(4), 4);
assertEquals("Test getValue" list.get(7), 7);
}
}

Hosting MistaRoboto with SVN

We are nearing the half way mark of the semester and now we are beginning to prepare for our upcoming group projects. Our next task is to study how to use Subversion with Google Hosting.

Subversion is a tool that enables you and your group members to upload local copy of your project onto the online repository.

Using Subversion with Google Hosting can never be easier. I was able to upload my project almost issue free. The only problem I had with uploading my project was that I accidentally deleted parts of my project and for a little while I was not able to run verify on it. I was able to determine the source of the problem fairly quickly however. I simply copied down to my local repository the files that were missing in the online repository, and committed the changes. The missing files were back on the repository and the project was back and ready to go.

Throughout this exercise and learning this new Google Hosting functionality, I am now more confident that I will be able to organise a group project. I think that one important feature of Subversion is that we have the option to roll back to previous versions of the project if something goes very wrong in our latest project version. I would like to be able to effectively use all the functionalities provided by Subversion

Testing Stage

Now that we finished developing our robocode project, it is now time for some testing. Testing a project may sound easy at first, but in fact, it is one of the most difficult tasks when it comes to project development. As a part of our class exercise, we were asked to design some test cases that would be useful when we actually go and create the test cases later on. I must say that it was not easy to come up with an ideal test case for my lab partner's robocode project. It took me a good half an hour of thinking and brainstorming to finally come up with an idea that may work well for his project.

Designing test cases for my own robot also was a difficult task. It seemed to me that in order for my robot to pass an acceptance test, it must at least beat the strongest of the sample robots, that is, Walls. I simply created an acceptance test case where my robot and Walls battle with each other for 5 rounds. If my robot successfully beats Walls 5 matches in a row, then it passes the first phase of my acceptance test. Another acceptance case would be a very similar one, but my robot now has to beat Tracker. I chose to implement Tracker because this robot does not have a set routine movement like Walls and some of the other sample robots. Passing my two acceptance case would mean that the robot is capable of beating a robot that is strong and has a set routine movement, and is also capable of beating a robot that does not have a set routing movement.

My first behavior test was rather simple. Since my robot does somewhat involve random movements, and it is programmed to move forward until it hits a wall, it should at least touch 3 of the 4 walls in the battlefield before the match ends. My first behavior test checks just that. My other behavior test checks to see if the robot is actually moving perpendicular to the enemy. This part of the test was difficult to implement because by the time onTurnEnd() method is called, the target robot may have moved to a another position. I resolved this issue by giving the robot a much larger range for its 'perpendicular movement'. For instance, moving 45 degree angle towards the enemy would still be considered as a 'perpendicular movement'.

For my Unit tests, I basically tested to see if the part of my code that controls the turning of the robot is working correctly. I also had some difficulties implementing this test case because the robot only turns about 10 degrees per turn. This makes it difficult to keep track of the robot's turn rate and how much it had already turned. My other Unit test case checks for the function that takes the robot out of the corners. This is done simply by checking whether the robot does a 90 degree turn sometime during a battle.

After finishing up all of my test cases, I continued to improve my project by using a tool called Emma. Emma is a tool that provides a greater insight to your code, by allowing you to view which part of your code is actually being ran and which part isn't. This tool is helpful especially when it comes to testing and I hope to use this tool for my future projects as needed.

My Robocode project with the above test cases can be downloaded Here.

MistaRoboto Domo Arigato

It has been about 3 weeks since we first implemented Robocode. It is now time to build our Robocode project in a more professional manner. During our class exercise, we have done some practice building/compiling projects on an open source build tool called Ant. Ant is a convenient java build tool that provides you with many differnet features. We also use Ant with other useful tools such as Ivy, Checkstyle, FindBug and PMD. Most of these tools provide means of error and style checking, which is extremely useful when it comes to building and writing a readable code.

Building together my version 1.1 Robocode project was not an easy task. I faced numerous problems trying to get the Junit and PMD to work and succesfully run on my project. The problem associated with Junit turned out to be that the compile command in build.xml file did not place my robot.class file properly into the lib/robocode directory. I was unable to figure out the source of this problem; however, re-downloading and re-installing the package seem to have fixed the issue.

The PMD issue was a tricky one. It turns out that the problem had nothing to do with editing of .xml files or misplacing of files. The issue was within the .java source code. I began to test my source code by commenting out one block at a time to see which line was causing the issue. I pinpointed the problem down to the block of codes involving the override of onHitRobot method. It seems that this block of code was preventing the PMD check to fail for an unknown reason. I have solved the issue by removing the lines of code.

I have learned a lot through this exercise. The use of CheckStyle was what stunned me the most. CheckStyle able to spit out about 50+ style errors in my source code initially. Through looking at the output html file, I was able to improve my code and make it much more readable. I find these build tools to be extremely helpful, and I hope to improvise these tools in the future when I develop more and more complex systems.

My Robocode MistaRoboto is available here

My Competitive Robot

It is now the time to build our own Competitive Robot, that is, a Robot that can beat all of the sample Robots! Our assignment for this week was to build a Robot that can specifically beat the following sample robots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck.

It certainly was not easy to build a Robot that can beat all of the eight sample robots, as they all have very different strategies. My robot, called MistaRoboto, has the following functionalities.

Movement:
The Robot first searches for nearby targets, and rotates its body so that one of its side faces directly towards the target, and moves back and forth. In other words, my Robot moves perpendicularly to its target while firing.

Targeting:
The Robot initially sweeps the battle field left and right, and once it acquires a target, it tries to keep its gun towards the target for as long as it can.

Firing:
The Robot does not fire until the target is reasonably near, that is, within 400 pixels radius. The Robot will fire with medium fire power for targets within 400 pixels and farther and 200 pixels. The Robot will fire with maximum fire power for targets within 200 pixels.

My Robot can beat RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck pretty consistently. It has trouble with Walls however. Since my Robot is effective only against Robots within close range, it seems to have a difficult time dealing with Walls' strategy.

One mistake I made during this assignment is that I started punching out codes before really thinking deeply about my Robot's combat strategy. It seems that with projects like this, or any other projects for that matter, it is important that I map out the plan beforehand so that I understand exactly where I am headed. I also think that planning ahead actually does reduce the total time spent for coding. Therefore, I believe it is important that I build a solid plan before coding and I hope to practice this with future assignments.

You can download my Robot here

Sample Robot Strategy Analysis

The Robocode program is packaged with various sample robots. Below are a few list of sample robots with its battle strategy.


Walls

Movement: This robot simply moves along the wall clockwise. It does not have any avoidance or following strategy to speak of, but it seems quite effective when faced with more than 2 robots. The only time the robot moves away from the wall is when it hits another robot along the wall, in which case, it attempts to move to the wall directly across the battlefield and continue its maneuver.

Targeting: Its targeting system is also very simple as it never moves its radar while targeting. It finds a target by pointing its gun towards the battlefield while moving along the wall.

Firing: It only fires when the radar detects the enemy. It never rotates the gun or the radar to scan/lock on to a target.

RamFire

Movement: Rotates until it detects a target, and moves directly towards it. It does not have any avoidance strategy, but its following strategy is to move directly onto the position of a target.

Targeting: It finds its target initially by rotating clockwise. Once it loses the target, it randomly rotates clockwise or counter-clockwise to continuously search for targets.

Firing: It fires only when the robot hits a target. It attempts to maximize the damage by continuously moving (ramming) into the target and by firing with the maximum fire power.

SpinBot

Movement: This robot's avoidance strategy is to move in a very tight circle. It does not have a following strategy.

Target: It finds a target simply by scanning while moving around in a circle.

Firing: Fires only when it detects an enemy with the maximum firepower.

Crazy

Movement: Its avoidance movement is to move in series of half circles and reversing direction when hitting a wall. It does not have any following strategy.

Target: It finds its target by scanning while moving in a series of half circles.

Firing: It attempts to hit the enemy as accurately as possible by using the lowest file power.


Fire

Movement: No movement.

Target: Scans for enemy by rotating its gun clockwise. Keeps the gun towards the target so long as the target does not move out of sight. It continues to scan once it loses its target.

Firing: Fires continuously until the target is destroyed with the minimum fire power.

Sitting Duck

Movement: No movement.

Target: No targeting.

Firing: No Firing. I am guessing its strategy is to sit and wait until everybody else is destroyed or disabled.

Corners

Movement: Moves to upper-left corner as soon as the battle begins, and sits there for the duration of the battle. It has no following strategy.

Targeting: It scans targets through a series of clockwise and counter-clockwise scannings.

Firing: Fires continuously until the target is destroyed.

Tracker

Movement: Moves towards the enemy and holds about 100 pixels away from the target. It has no avoidance strategy.

Targeting: Very similar to ramfire, except this robot rotates its radar to scan for targets. Once the robot loses its target it attempts to re-acquire the target by briefly scanning left and right.

Fire: Attempts to maximize the damage by firing with maximum power. Fires until the target is destroyed.

Robocode coding Standards

The simple Robocode design is now complete, and we are now ready for the next step. It is always a good practice to write your code clean and follow some form of standard, so that other people can clearly read your code and understand. It helps if you follow some form of standard, and this precisely is our next task.

I must say that I ran across a numerous trouble trying to get my Robocode to meet the class's coding standards. I decided that I should start with something rather simple, and that is, to change my robocode project name "robocode" to a more appropriate "robocode-danielhcolton". This; however, did not go as smoothly as I initially thought it would.

I was faced with an infamous nullPointerException after refractoring the "robocode" project name to the new "robocode-danielhcolton". Mysteriously, resetting all of VM arguments, classpath, and the development options under the robocode GUI did nothing to solve the issue. I was very close to giving up but turning the assignment in with an inappropriate project name was not an option for me. I finally solved the issue by creating a brand new project under the new name "robocode-danielhcolton" and copying all the necessary .java files to it. Although I was happy I finally got it to work, I sure wish this simple renaming process were a lot more simple.

The rest of the process was rather easy in comparison. The xml document that our professor provided sure did a lot of help in terms of making our code much more readable.

Following a coding standard while programming is very much like writing essays with correct grammar. A reader will have a much difficult time deciphering your writings if your essay is full of spelling and grammar errors. Coding standards must always be followed, especially if you work with a team of programmers.

Here is my revised version of Robocode Project

Battle with Robocode

Robocode is an interesting piece of code that you can work on to brush up your Java programming skills. I find Robocode challenging, as it requires numerous programming, math, and of course, debugging skills.

We were intructed to download and install the source code to work with Eclipse IDE. Although I barely had an experience working with Eclipse in the past, the installation process went quite smoothly. I find it rewarding to finally see my Robot tank on my screen with my name on it after following series of complex instructions.

I have created various robot tanks that can do certain movements, such as moving in a circle, move to all corners, etc. The following is a list of movements I have produced

Movement01: The minimal robot. Does absolutely nothing at all.
Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
Movement04: Move to the center of the playing field and stop.
Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
Movement06: Move to the center, then move in a circle, ending up where you started.
Tracking01: Pick one enemy and follow them.
Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
Firing03: 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).
Firing04: 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).

All of the movements through 01 to 04 I was able to implement successfully. Movement05 involved many trigonometric computations and I was not able to get the Math functions in Java to work properly, so I ended up dropping the diagonal movements all together. The robot in Movement05 now interestingly reaches all four of the corners without any diagonal movements.

I also had a couple of problems with tracking02. It seems that when I try to code the robot to stop 20 pixels before reaching the target, it does not take the size of the robot itself into account. With the setting Distance - 20(pixels), my robot ended up hitting the target everytime. I solved this problem by adding about 40 pixels to on top of the 20 pixels to compensate for the size of the tank. After applying the change, my robot now seems to follow its target about 20 pixels behind.

Another problem that I had occured while developing tracking03. I programmed the tank so that it would store the name and the distance to the robot who is the closest. I could not fully test if everything was working correctly as Robocode battlefield tend to get pretty chaotic when it has more then 3 robots running around. The robot also does not fully stop after traveling 100 pixels. It only briefly stops after each move and attempts to search again for the nearest robot.

If you would like to download my Robocode, feel free to do so.

I will also also provide a link to the source forge site here:
http://robocode.sourceforge.net/

OSS experience

The Java Project I chose: Dependometer

After browsing through some of the Java open source projects, I chose to take a look at Dependometer for it seemed like an interesting tool that could very well help me write a more efficient and clear code in the future.

Prime Directive 1:
Dependometer basically is a tool that provides you with the software metrics of your projects/programs. As you might be able to tell from its name, Dependometer measures software metrics of a program in terms of the dependencies of classes. It then generates an html document that summarizes the metric readings. Knowing the software metrics of your program is important for programmers because it helps them analyze its complexities. Dependometer, therefore, can ultimately be a tool to help reduce the complexity of your program. It also satisfies the first directive.

Prime Directive 2:
I must say that it seemed quite simple to install this program at first, until I figured out that it requires Ant in order for this program to run. Since I am still not an expert at installing programs on commandline, it took me a quite a bit of time and googling before I finally got the Ant installed on my system. The rest seemed a little easier. I placed an xml file inside the project directory and tweaked the file according to my needs. Finally I ran the the Ant command with the xml and Depondometer then spat out an html document with the results. I would say that the tool satisfies the directive only if the user is an expert at installing programs under commandline.

Prime Directive 3:
Dependometer does include extensive documentations so I would say that modifying this program can certainly be done a lot easier than those with no documentations at all. In this respect, I would say that Dependometer satisfies the third Directive. It would not be easy, however. The code does look complex and it would most likely take me long before I can actually start modifying any part of the project.

My FizzBuzz Program

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

It took me about 10 - 15 minutes to write this program on eclipse. When I originally solved this problem on a sheet of paper, I wrote the first if statement as if((i%5==0)&&(i%3==0)), however I realized later that writing it as above is much clearer.

I would have to say that since I am not used to programming on eclipse, it took me much longer to program this FizzBuzz program than usual. But I feel that once I get the hang of all the GUI functionality and additional features that eclipse provides, I will then be able to code much faster.