Ecologineers 2.1

Over the past few weeks since version 1.0 of my groups' project, there were many new additions and modifications to the program. Instead of one page that just does the chart, we have added a homepage which describes the entire project, and as stoplight page that gets the current carbon output. There is also a menu bar that allows the user easy navigation throughout the website. We have also upgraded the grid info to implement a chart. The chart now allows for users to look at data over multiple days because there is now a start dates and an end date that users enter. The users now have a choice of what source they want to choose from to view.

There is a new stoplight that tells the user the current state of the system. The stoplight shows green, red, or yellow which indicates if there is currently high, medium, or low carbon intensity. Low is green, medium intensity is yellow, and high intensity is red. The colors mean the same thing on the gridinfo page. The gridinfo page contains a chart with 3 input fields. A start date, end date, and source. To make the program user friendly, we have set the program up so that the same start and end date is one day. Ex. 10/01/2009 to 10/01/2009 will get the chart to print out the 24 hours worth of information.

Some other additions that we have made to the program was implementing ajaxpagerefresh for the stoplight page that will refresh the page every minute without the user having to manually refresh the page. We also added nice URLs, which made the URLs easier to read.

Final 413 Blog

This will be my last blogpost for my 413 software engineering blog. But fear not all you people out there, I will be back blogging about new experiences in my 414 class next semester! My first software engineering experience has been a good one. This experience has reinforced my belief that I chose the correct field and enjoy working with software and coding.

The most important thing that I have learned this semester is to always plan out the entire project before even starting on it. Every project that was assigned this semester was very interesting and fun to work on, but I had the problem of always flying by the seat of my pants while working on them. Instead of planning out and really thinking about how I wanted to implement the assignment, I would just start coding and get small parts done without looking at the bigger picture. This caused many problems later in the project since it took a lot of work to put everything together. The best example is the first wattdepot CLI assignment. My group had a poor implementation idea where we didn't take into account what we were trying to implement. We just finished all the methods and threw all these methods into one file. We didn't think about how hard the code was to read and expand on. We later had to refactor all of our code, we also made the code more readable and easy to expand upon by adding a command map that would handle all the user inputs.

I also learned about different quality assurance tools such as checkstyle, pmd, and findbugs. These tools were a burden at many times during the class since they would nit-pick at such small things, like a missing space after a comment, which would cause our build to fail. Although they would annoy me, I have learned a lot using these tools, since they made me a better programmer. They made me realize that some of my code could be optimized and to make sure that I always comment. This was also the first semester that I needed to use JUnit. Making test cases were very useful since it allowed me to make tests for small parts of a program. The JUnit tests saved time testing the program since I would not have to run the entire program to test a small change. I could just test the small change using JUnit.

Another important thing that I have learned in this class was working in groups. This class gave me my first experience working in groups and the various programs that helped with the group projects such as Git or subversion. We used subversion in class and I have seen how it has helped with the process of finishing an assignment.

Overall, I have enjoyed my 413 class very much. I have never worked so hard in a class before. This class was very intense and I have felt like everything that I have worked on in this class is very useful and relevant to real world experience.

Review of GreenSmart 1.0

We are reviewing other groups projects again for our ICS 413 class. I was assigned to review GreenSmart's project. When I first visited their project site, I was very impressed with their home page. It looked very professional with the screen shot of their system, and also a good description of what the project accomplishes. They had good wiki's that explained what needed to be done to run the system as a client or as a developer.

I was not able to break their system as error messages were produced whenever there was bad input or there was no output. The only problem I had with the error message that I didn't like was that it said "Error:" for each error message. I would rather like to have seen something like "Invalid input, please only input integers." or something in the nature that tells the user what is wrong. This is the only negative I found with their program.

Looking at their actual java code, I could not tell that the program was written by more than one person. The code was easy to follow and I found nothing wrong with their documentation. I think that they could have setup two different packages, where one package was the wicket and another package has the wattdepot commands.

My full review can be found here.

Ecologineers 1.0

Imagineer that! We are embarking on a quest to improve the life of the entire world. When I speak of we, I am talking about me and my 3 other ecologineer group mates. We are writing a program that uses the WattDepot system, which I talked about in my previous blogs, to give indications of when there is a high amount of carbon being emmited. This new system uses the Wicket system which allows for html to run complicated java programs almost effortlessly. Using the Wicket platform, we are making a webpage that indicates the amount of carbon being emmited at a certain time of the day.

Learning the Wicket language was very difficult at first. Extending the Webpage and Webapplication classes were very confusing at first, but I slowly got the hang of it. One thing that I still do not understand after working with wicket is exactly what the 'serializable' class does. I hope after I read more up on it later that I will understand the serializable better.

I was very pleased with the way our group worked together. We all got along great and also are able to get things done when needed. The only bad part was that we started working on the project a little late which caused us to spend long nights getting the program up and running by the due date. I am okay with the design of our project. I think that we could have made the program a little more efficient at getting the thresholds, but other than that small kink, I am pleased with our implementation. Some kinks in our program is that we didn't get all of the validations to work and some input causes the program to crash. For example, putting extra 5 digits in the year field will cause the program to crash. We didn't figure out a way to fix that bug yet and will have that bug fixed by version 1.1. We also were not able to get the rows of our table that we generated to output the corresponding colors. Instead we just put a column called 'Intensity' that has a text output of what the row color should be. We should also have that fixed by version 1.1 of our system.

The picture above is our hackystat ICU chart. This chart indicates that we do not have adequate test cases, and also that we have uploaded a lot in a small amount of time. Our coverage report is small, since we didn't test any of our wicket code.

A distribution of our project can be found here.

Revamping to WattDepot 2.0

In this blog, I will talk about upgrading our team's WattDepot User CLI to version 2.0. This was a very tedious task since it required a lot of refactoring of our code. The majority of our groups effort was put into refactoring our code since we implemented an interface and used a Hashmap to call our commands. We made the mistake of finishing all of the commands from 1.0 instead of getting the hashmap to work. This made us take a few more hours than it should of since we just added more code to refactor. There were also a few new commands that was added into the new version of WattDepot. The new commands can be found here. The three new commands were a lot easier to implement now that we were more familiar with the API. Also, the commands were changed from version 1.0, which were easy to fix after we implemented our Hashmap and interface. I am glad that we have finished the assignment and got everything working.

I thought that my group partner and I worked well together. I felt that we each held our own and did the tasks that we assigned for each other. We met regularly about 2-3 times a week in sessions of about 3-6 hours at a time. This gave us plenty of time to work on the assignment.

I believe that our system wasn't the most efficient way to implement the user CLI, but we were able to get the job done. Having the refactor the code created some problems, but we were able to workout the details and get all of the commands up and running. We tried to take care of as many of the issues raised by our reviews of our system. The reviews were very helpful since it gave an outside perspective on our system that we were not able to see ourselves. Our design of the system still has some kinks, especially after we broke up the commands into their own classes. To get all the commands working, we had to extend the UserCommandInterface class since it held some key methods that could only be accessed if we extended the class. This was a design error by us since we were not able to access the client information from the main class since we didn't ever pass it as a parameter. To summarize this, we have each of the classes in the command package having to extend the UserCommandInterface and the UserCommands class. The names are a little confusing since the UserCommands class is the interface and the UserCommandInterface holds the CLI menu methods.

We did not write tests for every class which tells me that we do not have good test cases. This was a pitfall because we did not write test cases at the same time that we were writing code. We tried to write out the test cases at the end of the code for the old commands from version 1.0, but again we ran out of time. We were only able to cover 76% of our class, 63% of our method, 44% of our block and 46% of our line code.

Looking back on the assignment, I feel that the goals of this assignment was to give everyone in the class group experience, which is something that was lacking in previous ICS classes. We were also introduced to some pretty cool tools that helped the group project go along smoothly. Using subversion was a big help since we were just one click away from updating and commiting our changes to the project. The new tools that I was introduced to were Hudson and Hackystat, which were both interesting tools. Hudson was a good tool that helped our group keep our project healthy and not let it stay broken for long. Hudson was a build tool that is very useful since it verifies the system all the time with helps when either me or my partner forgets to verify. Hackystat was another interesting tool which told us all about our code. Here is a printout of our code. This printout told us that we needed to write more test cases to help cover more of our code. Also, since our design of the system was pretty bad, our code is very complex.


What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW

What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW

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

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

What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
4th, 5th, 16th, 17th, and 30th of November. 29,959 pounds of CO2 were emitted.

What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
7th and 8th of November. 22,908 pounds of CO2 were emitted.

Our distribution file can be found here.

Giving and Taking Criticism

Doing peer reviews of other people's implementations of the User Command Interface for the Wattdepot project was very interesting. Both projects that I reviewed had implemented their systems very differently. Both groups split their programs up, but one group implemented their program using an interface, while the other group implemented their program by extending their classes from the main class. Anther interesting aspect of the two implementations was the fact that one group hadn't used any methods in their different classes, but just used System.out.println() within a constructor. I guess I am saying that it took some time getting used to each group's coding style before I was able to review each group. One of the most important things that I have learned from looking at other people's code is the importance of Javadoc comments. I was able to easily read through the code that had good documentation of what was going on.

It was interesting reading other peoples review of our system. The 5 reviewers of our system had similar critiques of our system. Basically each of the reviewers talked about our lack of test cases and having too many methods within one class. These are very true comments and I agree with their review. While working on the project I made the stupid mistake of trying to write in all the test cases for my code after finishing my code. I also need to organize my code better and not put everything into one class. Something I learned that helped a lot when looking at reviews of our system, was when reviewers would write in exactly what command they inputted that failed to work while they were testing our code.

The most helpful reviews were the reviews which contained constructive criticism. Most of the reviewers review of our system were constructive with the exception of one. While reading the reviews, one comment about my group's projects was that we have written our code in "spaghetti code." This is a very harsh comment that did nothing to help our group improve our system since the comment ended there. This reviewer did not specify what parts of our code was "spaghetti code." Writing comments without giving evidence just confused me because I didn't what what exactly made our groups code hard to read. Besides having one long file, I thought that our groups code was easy to follow.

Reviewing other people's WattDepot-Cli

This week for ics 413, we get to review other people's implementations of their User Command Interfaces. Each member of the class was assigned to review two other group's projects, not including their own of course. We were also assigned to base our reviews on the criteria given by our professor. A copy of that review sheet can be found here. I was assigned to review two groups: Umikumakahi and Umikumalua.


Umikumakahi
Umikumakahi's system was very tricky to review, since I was not able run their system in my command prompt or in the Eclipse IDE. I was not able to test whether commands worked or not therefore my review was based more on their javadocs and their design of the system. My full review can be found here.

Umikumalua
Umikumalua's system worked well, but had many issues where bad input would crash the program. Also, commands were case sensitive which cause me problems when trying to test out the commands on the system. For example, 'list sources' would work where 'LIST SOURCES' would not be recognized. There were also a few commands that were not implemented which need to be before their next version comes out. My full review can be found here.

Creating a WattDepot CLI

For my ICS 413 class, we are writing code for the WattDepot-Cli program. WattDepot is a new program that helps people regulate accurate power usage of power plants and homes throughout the island. More information can be found about the WattDepot program here.

In class, we were paired up with another person in our class to create a CLI(Command Line Interface) for the WattDepot program. I was paired up with Shaun Ramento. This assignment was very hard to start off. It took a long time just learning the API of the WattDepot. Just getting simple functions like client.getSource() was troublesome, since the Source class also had many other methods nested in it. After learning the basics of the API, we had to figure out how we were going to implement the CLI(Command Line Interface). We decided to create a new class, that would hold all of our methods in it, and also figure out what commands the user is inputting. The 10 commands that we needed to implement can be found here.

After getting the two simple commands, 'help' and 'quit' done, we started working on the next set of commands. We decided to split up the work on commands 2.3 and 2.4 so we would be able to help each other get used to the API. We then split up the work by the type of commands we will need to access. I took commands that dealt with sensordata and shaun took the commands that dealt with power. Finally, we split up the last two sections of the assignment where I took section 2.9 and Shaun took section 2.10.

After getting about half way through the assignment, our professor told the class that he did not like the way that a certain group was deigning their code. This group had all their methods setup in one java class file. Our professor told the class that these people need to rewrite their code by splitting up their methods and to use an interface. This was a problem, because my partner and I had decided early on to do the commands the same way that he lectured about, which meant that we also needed to change the design of our implementation of the project. Also, the group wrote their code using a lot of System.out.println() which we also did. Rewriting the code to not have these System.out.println() statements caused much time to be wasted since we had to rewrite a good portion of our code to fulfill the standards of the program.

We made a mistake by not writing junit tests while we writing our java code which caused a lot of time to be wasted since we would write code, run the program, then enter code to see if it works properly. This was a huge mistake. Too much time was wasted in this process. We ended up writing our junit tests late, which caused us to waste more time since we had to look over our code to remember what we had to test.

After finding out that we needed to change the design of our project, we decided to finish all of our methods then work on moving the methods around. Unfortunately, we were not able to setup our project in the way that our professor wanted us to, since we had problems finishing the rest of the methods by the Wednesday deadline. So we did not move the methods into their own separate classes and implement an interface. I wish I had more time to understand this interface and creating separate classes. I will most likely look at how other people have implemented this portion of the assignment, since it seems like it is very useful and essential to learn writing code in table-based dispatching form.

Here is the distribution to team eha file.

Continuous integration and Hudson

For my ics 413 class we were just introduced to continuous integration. We were introduced to this topic because we are going to be working in groups on this upcoming assignment. In groups projects, big changes to software can lead to problems since those changes may not be compatible with other group members code. Continuous integration is an idea where programmers of software projects make small changes to projects then committing those small changes. The continuous integration environment that my 413 class is using will be Hudson.

Hudson is a system that helps software development by continually building and testing projects. Hudson will monitor my groups SVN repository by building and testing new project updates. Anytime a group member commits something new to the SVN repository, Hudson builds and verifies the project. If any build or test fails, an email would be sent out to everyone working on the project saying that the project failed to build. Anytime there is a failed build, it should be immediately fixed. The Hudson system is very useful since it verifies a project just in case one of the group members forgot to.

Hudson was very simple to setup and use since most of the instructions were given to us in a webcast. If I were to do it on my own, I think that it wouldn't be too hard since there are instructions all over the internet. The only problem that I had while setting up Hudson for my group was that I didn't set the automatic build field, so Hudson looked for a file in a folder that didn't exist, so the build kept failing. Other than that user error, everything else in the setup was straightforward.

My Madeup Midterm Questions!

1. What is an anti-pattern? Give one example of an anti-pattern.

"An antipattern is a recurring negative solution to a problem" (http://www.ibm.com/developerworks/opensource/library/os-junit/#N100C5) In otherwords, an anti-pattern is a test where it seems like it is testing a lot of the code, but rather it has missed much of the code. It is giving a false sense of security that the code is working properly.
Examples of anti-patterns:
Happy path tests - Tests if everything is working properly and gives the correct results. This is only an anti-pattern if this is the only type of test used.
Validation and boundary tests - Like the happy path test, but tests the boundaries of something(maybe a method, list, input, etc.) and also tests if the correct output is thrown if there is invalid input. This could be an anti-pattern if the data that you put in returns valid when it should not be valid. For example, if an input should be out-of-bounds, but it still returns valid input.
Easy tests - Tests that are very simple (like testing toString()) because the code is hard to test. These tests work but do not accomplish much.
Overly complex tests - A test that is so complex you cannot tell if it is correct or not. The anti-pattern is not knowing if a test is correct or not. It is better to have a simple test that you know is correct.

2. When overriding equals(), you must also override hashCode(). Why could overriding hashCode() in the following manner not be good?

public int hashCode() { return 0; }

This is because the hash would become one long list of values in one bin.


3. What makes a build tool, like ANT, so useful?

-Build tools are cross-platform
-It allows for the compilation and testing of code to be automated
-It can download and install everything that is needed for running the code
-It can be incorporated with IDE's like Eclipse.

4. What is the main problem with only allowing one person to checkout and modify a project at a time?

Everyone would have to wait on that one person.

5. What is the difference between White Box testing and Black Box testing?

In Black Box testing, there is no knowledge of the internal structure of the program. Some examples of Black box testing is equivalence and boundary value analysis. In White Box testing, a person could test the paths within a program. Some examples of White Box testing is control flow testing, data flow testing, and branch testing.

6. In the article about coverage tools, In pursuit of code quality: Don't be fooled by the coverage report, what did the author mean by "fools gold?"

It is when there is a high coverage report, but it doesn't mean that the code was exercised well.

7. What does the following code written in an ant build file
<Property Name="checkstyle.config.file" value="checkstyle.xml" />do?


It defines a property, checkstyle.config.file, and sets its value to checkstyle.xml.


8. According to the Stanford article, why are heavy multitaskers unable to perform better in the tests than the light multitaskers?

The heavy multitaskers were unable to filter out the excess information and thus were not able to concentrate.

9. Emma's coverage report indicates that you have covered 100% of you code. Does this mean that your code is now bug free? If not, explain.

Even though all of your code has been executed by Emma, it doesn't necessarily mean that your code is bug free. A test could cover all of the lines of code but not have been fully exercised. For example, a person could write a single test that covers every line of the code.


10. What irritates hackers the most when they are trying to help people on forums?

When people ask questions that they could have easily looked up the answer to themselves.

Google Projects and SVN

I was just introduced to SVN or subversion and found the program to be very useful. SVN is a useful tool for working on big group projects. SVN allows for people working on a project to make small changes to the projects and commit the changes to a server for everyone to update. The SVN program that we were introduced to was TortoiseSVN. The good thing about TortoiseSVN is that when a person has to commit an updated version of a program, that person needs to have the most recent version. For example, if a person tries to commit an updated verison of a program to the server, but there was a newer version of the program commited, that person has to update to the newest version of the program then make the changes and commit to the server again. This may also be a negative for SVN since if there are many people making changes at the same time, there may be changes every few minutes or hours. Therefore a person could only be making small changes instead of making one big changes to the program.

I used google projects to host the project. It was very useful since it allowed me to put all of my files onto the server. Anyone who wants to download my files would be able to from the google server. I liked how google projects allows other people to have easy access to my files. When TortoiseSVN is used with Google Projects, any updates could be easily updated by checking out the most recent copy of the project.

JUnit and Emma testing

For another class assignment, we were introduced into creating our own tests and running them on JUnit. We were also introduced into using a coverage tool called Emma. JUnit allows java developers to easily test their code over and over. This saves the programmer a lot of time testing their code every time small changes are made. JUnit is especially useful for running tests on code after small changes are made and can tell the programmer if a change to the code has messed up other parts of the code. Emma is a coverage tool that tells the tester how much of the code was actually covered by the JUnit tests. To get used to JUnit and Emma, I wrote tests for my robocode robot.

I have never utilized JUnit before so this my first experience writing my own tests for code. It felt like I was learning an entirely new language, but after a few hours of looking at the API and the RobotTestBed I got the hang of it. I found that writing tests that are not acceptance tests are very challenging. At first, I had a hard time figuring out what types of behavioral tests to test on my robot. I decided to test if my robot moved to the correct side of the map initially, if my robot moved up and down the left or right wall, if my robot had its gun facing the correct direction, and if my robot turned 90 degrees when it was either hit by a bullet or ran into another robot.

The most challenging of the four behavioral tests were testing to see if my robot moved paralled up and down either the right or left wall. Eventually, I figured out that I had to test if the robot was first close to a wall then check if the robot was also facing parallel with the wall. After figuring that out, the rest of my tests went by pretty smoothly. Just thinking about what tests to run took a majority of my time. Thinking of the most efficient tests to test the most amount of code was challenging.

Using Emma was also an interesting experince for me. I had a lot of problems working with emma at first because I didn't understand exactly what all the red, green, and yellow highlights on my code were. As it turns out, the green highlights are highlights of code that was run during the tests. The red highlights were code that was not seen by Emma during the tests. The yellow was codes that were seen, but not executed or used by Emma. While trying to run Emma I ran into problems with Emma not being able to see my CounterBot.java file. This scared me for about an hour until a friend told me that I had to change the emma.build.xml file. The build file was not looking for the correct java code in the correct place, so after changing the code, I Emma was able to read my java file. I found that Emma was able to read 100% of my java file and also read almost all of my JUnit tests. The only test that Emma didn't read 100% was my TestToSide test. I think it was because some of my code doesn't get called if the robot only starts on one side of the map for the entire test.

In order to make my robot easier to test, I think I would have to create more methods within my code. I was not able to run any unit tests on my code since I didn't have methods that were not events within my code. I had a lot of code within the events like onHitRobot, onScannedRobot, and all those other tests. Therefore, I would probably make a moveDirection() method and a fire() method. This would allow me to test is my robot is moving laterally or test how strong of a bullet my robot would fire at a given distance.

My distribution file can be found here.

Ant Build Tool and QA Tools

I recently was given the task of learning and using the Ant Build tool and Quality Assurance (QA) tools. The Ant Build Tool is most useful when it is used with Ivy. Ivy imports a lib directory and is used in xml files to help The Ant Build tool is a great tool for working with big java group projects since it can automate the compilation and testing of java applications. This greatly saves time for the programmers since the compilation and testing could all be done from one command. Another great thing about the Ant Build tool is that if the build.xml file is setup properly, it could download and install all of the necessary applications for a project onto each member's computer. A good example is the build.xml file from the package that I used in my ICS 413 class. The build.xml file from that package downloaded all QA tools that I didn't have on my computer and downloaded it for me.

The QA tools that can be run using Ant+Ivy like checkstyle, findbugs, and pmd. Each of these programs check the java code for small errors like unused variables, inefficient code, and for correct documentation. Each of these small QA tools can be called in an Ant build file. This enables projects with large groups to all follow the same coding standards. This also allows everyone working with the project to be able to reach each others code easier since everyone needs to follow the same style of coding.

When I ran checkstyle, findbugs and pmd, I originally had no errors in pmd and findbugs. But I had a lot of checkstyle errors. I fixed all of the errors and ran findbugs and lost the checkstyle folder. So I am unable to paste any of those errors onto this blog.

The greatest part about Ant is that can be used on any type of platform. So the same build file could be run on a Mac as on a Windows machine.

CounterBot had some weaknesses in its design as it would always go the right wall first and go up and down that wall. Since my robot depends on taking a wall early, I changed my robot to go to the nearest wall, either the left or right wall and start moving up and down that wall. I also made my robot shoot the most powerful bullet when at a farther range. This allowed my robot to become a little stronger at close combat.

My updated CounterBot can be found here.
My distribution file can be found here.

Counter Robot

Trying to create a robot that is able to counter and beat a variety of other robots is a challenging task. I will try to create a robot that can beat Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, SittingDuck. My strategy for defeating each of these different robots is as follows:

Movement:
Robot will move up and down a wall, but if robot runs into an enemy robot, the robot turns and begins to move left and right across the map. This will help the robot evade attacks. The robot will also move the same way if it gets shot by another robot. The basic strategy for movement is to keep moving and not stay in one place.

Tracking:
Doesn't really utalize tracking capabilities. This robot will only pick up on enemy robots if the enemy is in front of the robot.

Firing:
Fires upon sight of the enemy.

Since Walls is one of the toughest robots to defeat, I decided to chose this design because it will defeat the Walls robot on average 80% of the time. After implementing this robot, I was able to defeat each of the robots on a consistant basis except the Tracking robot. I defeated all the other robots about 60% of the time, but I am 50-50 against the Tracking robot. I had a tough time against the Tracking robot because of it's aggressive nature and exploits the weak spots in my robot.

I have learned a lot about Robocode through this experience. It is very hard to get robots to do things by just using the basic Robot package. This restricts the robot's movements a lot. The robot only has a choice to do one command at any point. This meant that the robot was either evading or attacking and could not do both at the same time. If I were able to do this, I would have been able to build a much more balanced offensive and defensive robot.

My code can be downloaded here.

Goods and bad of sample robots

In this blog I review the different sample robots that are given in robocode. I will be judging each robot by the following criteria:

1. Movement: How does the robot move? Does it have an avoidance or following strategy?
2. Targeting: How does it find a target to fire?
3. Firing: What is its criteria for firing?

For the Firing assessment, assume that all firing is called in the onScannedRobot() method call.

Walls

Movement: The walls robot moves exactly as the name implies: around the walls of the map. At the start of a game, the robot turns to a side of the and heads straight for it. Then turns parallel to the wall and moves in a clockwise fashion around the map. Before turning around the corner of the map, Walls checks if there is an enemy robot along that wall, and if there is, Walls fires at that robot until the robot is either not on the wall or dead. If Walls runs into another robot, Walls either backs up or moves ahead 100 pixels, depending on where the enemy robot it bumped into is. Walls then turns 90 degrees right moves across the screen. Thus, this robot impeliments an avoiding strategy since it is always trying to move away from an enemy.

Targeting: Walls finds a target around the map when an enemy passes in front of Walls and is picked up by the scanner. This robot does not lock on to any robot.

Firing:Fires on sight. As soon as Wall's radar identifies an enemy robot, it fires its weapon. It always fires a bullet with firepower 2.

RamFire
Movement: RamFire spins around in a circle until it finds and enemy. This robot utilizes a following strategy. When RamFire finds an enemy, it stops spinning, calculates the distance between it and the enemy and charges at the enemy full speed. If it gets to its destination without ramming into an enemy, RamFire starts spinning again until it finds another enemy and the process starts over again. If RamFire runs into another robot, it backs up and fires its weapon.

Targeting: This robot spins around 360 degrees until it picks up an enemy robot.

Firing: The amount of firepower that RamFire uses is proportional to the amount of energy the enemy robot has left. RamFire doesn't want to kill the enemy robot since it primarily wants to ram the other robot for extra bonus points. So the more energy the other robot has left the stronger the firepower up to firepower 3. The weakest bullet that RamFire uses is 0.1. Unlike other robots, this calls the fire() method in the onHitRobot() method instead of in onScannedRobot().

SpinBot
Movement: SpinBot moves around in a circular pattern throughout the entire game. SpinBot will turn if it runs into a wall. If SpinBot runs into another robot, SpinBot will fire upon that other robot if the enemy is in front of it, otherwise it will just turn right 10 degrees. This means that SpinBot uses an avoidance strategy, since it is always moving around.

Targeting: SpinBot's gun and radar never move around to track anything. SpinBot just scans the map as it moves around in its circular pattern.

Firing: Always fires a bullet with firepower 3 whenever it scans an enemy robot.

Crazy
Movement: Crazy moves around by turning and moving at the same time. This is accomplished by using the AdvancedRobot package and using the waitfor() method. The waitfor() method waits until the robot completes a turn while still allowing the robot to move forward. Thus, the method seems to allow the robot to move and turn at the same time. The robot keeps moving forward until it hits a wall or enemy robot and then moves in the opposite direction.

Targeting: The gun and radar do not move. So like previous robots explained, Crazy has no tracking system and just waits for a robot to be in front of it.

Firing: Fires when the robot scans an enemy robot in front of it with firepower 1.

Fire
Movement: Fire only moves after it got hit. When Fire gets hit, it turns at an angle relative to the angle that it was shot from and then moves 50 pixels forward. Fire only shows signs of evasive maneuvers after it gets shot.

Targeting: Fire targets other robots by spinning its gun around 360 degrees. After finding the first target it sees, Fire locks onto that target. This is the first robot that has tracking capabilities. Once it finds its target, Fire locks onto the target and keeps firing bullets until Fire recieves damage and then tries to use some evasive maneuvers.

Firing: After finding a target, Fire fires its strongest bullet if the enemy robot is within 50 pixels and if Fire has more than 50 energy left. Otherwise, Fire only fires a power level 1 bullet.
Sitting Duck
Movement: This robot has no movement, it just sits there and outputs some information on the console.

Targeting: None

Firing: None

Corners
Movement: When a match begins, Corners does exactly what the name implies and goes to a
corner that is specified in the code. Corners gets to a corner by first turning to one wall, moving
toward that one, then turning perpendicular to that wall until it gets into the corner of the map.

Targeting: After getting into a corner, the robot's gun turns its gun 360 degrees until it finds an enemy then tracks and fires at it.

Firing: Depending on its distance from an enemy, the firepower of the bullet changes. The closer the enemy the stronger the bullet.

Tracker
Movement: Tracker moves toward an enemy until the enemy is within 150 pixels of it. If the enemy is closer than 100 pixels away, then tracker moves back.

Targeting: Tracker initially spins its gun around and tracks the first enemy it finds. Tracker targets a single enemy until the enemy either dies or Tracker cannot find the enemy for 10 turns. If Tracker runs into another robot while moving, Tracker will change the robot it is tracking to the robot that it just bumped into and fire.

Firing: Tracker fires at the tracked enemy if the enemy is within 150 pixels with firepower 3.

Java Coding Standards

In all the java coding that I have read so far in my short career, I have seen some very complex java code that was very hard to understand. This was due to the fact that the code wasn't well documented, which made it very hard to follow. This made me waste a lot of time just trying to figure out exactly what certain methods and classes did within the program. This has taught me that proper documentation saves the person reading code a lot of time.

Not only will following proper coding standards reduce the reading and understanding time of another person's code, but it will also increase it's reuse ability because of it. Many times, java programmers finish a project and move onto other things, then other programmers may want to improve on the code. In these cases, having the proper java coding standards are most important. Since it saves the programmers that take over and improve the code a lot of time understanding exactly how the code works.

To help myself have better coding standards, I have read a book called The Elements of Java Style. I also follow the java coding standards of my software engineering class found here. After reading those coding standards, I started fixing my code from my previous robocode assignment. I, like many programmers, did not follow all of the coding standards. I had to fix a lot of my documentation because I didn't explain why a method was there but rather what the method does. This my biggest problem because I realized that I have always been breaking coding standard.

While fixing my code to conform to the java coding standards, I also had a chance to fix up some of my codes that were not able to work properly by looking at how some other people in my class did it. I ended up adopting code from Kimberly Heu for my Tracking03 robot. Her code was very easy to understand since she docuemented it well, and her robot worked perfect also.

My new updated code can be found here.

Robocode fun!

For my ics 413 class, I am lucky enough to have Robocode programming as an assignment. Robocode is an open source program, written in Java, that allows a programmer to program a virtual robot to fight against other robots. At the very end of this assignment, the class will have a competition to see who will have the best combat robot. This is something that I think that I will enjoy working on, since I am a very competitive person.

The installation of Robocode went pretty smoothly. All I had to do was download the program from http://robocode.sourceforge.net/ and run the .jar file. It was very simple and only took a few minutes. However, getting the Robocode to work with eclipse was a little difficult to do. Luckily, there is an online step-by-step walkthrough of how to run Robocode from Eclipse and import your robot into Robocode to get the robot to run. I followed the instructions from this wiki.


To help us get acclimated with robocode, the class was assigned to create 12 different robots. The 12 different robots are :

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

After reading the methods from the robocode api, I thought I had a good idea of how to make my robot move around, but I realized that the movements were a lot trickier. Being able to move from one point to another precisely was very tricky since it required some geometry. A friend later pointed me in the to a website that contained a method that pointed the robot in the correct direction. I used the absoluteBearing method from the website. This helped my movements out greatly.

After figuring out the point to point movement of the robot, Movement04-Movement05 were relatively easy. But I ran into a few problems while on Movement06. I wasn't able to get a movement where a robot would move in a circle and stop when it returns to its starting point. I got the robot to move around in the circle, but the robot wouldn't stop when it return to the starting point.

The tracking robots were a bit tough to get working at first, but after reading the sample code and using a small portion of code to get the robot to lock onto a target, the tracking wasn't too bad. The firing robots were not very hard to get working. The only problem that I ran into was also getting the robot to track, but after I figured out the tracking, I was able to get the robot to track a single bot.

Samples of my code can be found here.

I learned that robots are really hard to program and need to be told to do almost every single action down to the smallest action. There is also a huge amount of math and physics that go into getting the robot to perform certain actions such as targeting and moving to the correct direction.

SyncDocs

I have tried this program called SyncDocs(http://syncdocs.sourceforge.net/). I downloaded the program off of SourceForge.net.The SyncDocs program is used to transfer one file or a group of files easily from one computer to another or used to transfer files onto an iPhone or iTouch. All you have to do is drag and drop all files that you want to transfer into a window, and when the other computer on the client side types in what file type they want to download, the files are transferred to the other computer.

I have used the three prime directives given by Philip Johnson to evaluate the program.

The most useful application is being able to transfer files to an iTouch or iPhone or another device with a different since the OS on these devices are different. So as long as they have java support, a person would be able to transfer the files from one device to the other.

This program was relatively easy to install. All you have to do is unzip and double click. If you ran into any problems, solutions were given on their webiste. They also have demos of how the application works for people who are visual learners. This makes the process of learning the program easy.

I have no idea how to develop this program yet. I don't know how to find the information to develop this program.

FizzBuzz Challenge!

This is my FizzBuzz program that I wrote. It took me about 10 minutes from opening java to write verify and implement the code. It was a little funny working on this program because I forgot about the system.out part before putting println. This annoyed me, since i wasted a couple of minutes wondering why it didn't work, but realized that mistake. But other than that small hickup, everything else went smoothly.

//This program Is the fizzbuzz program that prints the numbers
//from 1-100 And prints "fizz" In place of the number If the number Is a factor of 3 And
//prints "buzz" In place of the number If the number Is a factor of 5 And prints
//"fizzbuzz" In place of the number If the number Is a factor of both 3 And 5.
Public class FizzBuzz {
  Public Static void main(String[] args){
      //main Loop To go through all the numbers from 1-100
      For(int i=1;i<=100;i++){
          If(i%15 == 0){
              //If a factor of both 3 And 5 Print fizzbuzz
              System.out.println("FizzBuzz");
          }Else If(i%3 == 0){
              //If a factor of 3 Print fizz
              System.out.println("Fizz");
          }Else If(i%5 == 0){
              //If a factor of 5 Print buzz
              System.out.println("Buzz");
          }Else{
              //If Not a factor of 3 Or 5, Print number
              System.out.println(i);
          }
      }
  }
}