Our project, named Greensmart, is a webapp which displays simulated data of the electrical grid of Oahu, Hawaii. It provides a user useful information in a way that is easy to digest and gain something useful. We have two pages which give different data to the user: a stoplight page and a grid info page. The stoplight page presents the user with a stoplight with either the red, yellow, or green light lit up. This represents the current level of carbon emissions. The user is given an explanation of the data presented and a recommendation if it is a good time to be using energy. The grid info page is a page where the user can enter in data to get the information that they want displayed in a google chart. The user can choose from a source and the start and end date.
There were two big things that I gained from this project. The first one is working in a group. I had only once before worked in a group for programming. The methods that we used in class like Hudson and HackyStat were very helpful in giving me a taste of what I can expect a professional setting to use. The second thing I learned was about the user interface and creating an interface that would be user friendly. There was a big emphasis placed on making the webapp as user friendly as possible and I learned a lot about what things we can do or avoid to achieve that goal.
Friday, December 18, 2009
Thursday, December 17, 2009
Software Engineering
This semester I took ICS 413, Software Engineering. This was the hardest, but most rewarding ICS class I have taken. I learned much more about software engineering than I thought I would. I really feel like I am coming out of this class as a much better software engineer. We implemented many things that are used in the professional setting. Now that I have some experience using some of the tools, I feel more confident.
The best part about this class was working in groups. It was a very valuable experience that I haven’t gotten in my other ICS courses. Learning to work in a group, I think, is something that is very important to learn before to get out into the professional space. There are many things that I learned about working with other people and what you need to do as an individual and as a group to be successful.
This course also was set up in a way that was different than the other ICS courses I have taken in the past. The lectures were placed online and the time in class was used to work on our assignments. I felt that this was very effective and I wish that more courses would implement this same style of teaching. The hardest thing is the self-discipline to watch the videos online. Since the videos were necessary for the next class, if you don’t watch the video, you’re not going to be able to utilize the time in class productively.
The best part about this class was working in groups. It was a very valuable experience that I haven’t gotten in my other ICS courses. Learning to work in a group, I think, is something that is very important to learn before to get out into the professional space. There are many things that I learned about working with other people and what you need to do as an individual and as a group to be successful.
This course also was set up in a way that was different than the other ICS courses I have taken in the past. The lectures were placed online and the time in class was used to work on our assignments. I felt that this was very effective and I wish that more courses would implement this same style of teaching. The hardest thing is the self-discipline to watch the videos online. Since the videos were necessary for the next class, if you don’t watch the video, you’re not going to be able to utilize the time in class productively.
Tuesday, November 24, 2009
Eco-Depot code review
I was tasked with reviewing Eco-Depot, A web application to provide information on the energy use of the Oahu power grid. It was able to fulfill the requirements of the project, and at the same time creating a useful site for someone looking to use energy while it is at its cleanest. The design and implementation of the system were very good. It was easy to follow and understand. Based off the Software ICU, the group seemed to be working very well together, but there was one member whose data was not being updated into the ICU. The code review can be downloaded below.
Download here
Download here
Monday, November 23, 2009
Team Greensmart
My group, team name greensmart, implemented a system to let users see the current carbon emissions on the island of Oahu. Using this information, users will be able to decide when the right time is to use their heavy electicity using electronics. When the webapp says the carbon emission is low, it is the time when the energy is the "cleanest"
I think that this first stage of the project went well. There was a lot of getting used to since this was our group's first introduction to Wicket. But from reading "Wicket in Action" and looking at the example programs provided, I was able to gain a better understanding on how to use Wicket. We were able to share our experiences and tips with each other.
We designed our system the way that the Cheesr system was designed. We utilized sessions and a base page which make make it easier to include more pages down the line. Using this method, our system is easily expandable.
I feel that our group worked very well together. We were able meet on 3 separate occasions which really helped in keeping ourselves on the right track and helping each other if we got stuck. We split up the tasks between us and worked on the system both on our own and as a group. The following is a screenshot of our Software ICU.
I think that this first stage of the project went well. There was a lot of getting used to since this was our group's first introduction to Wicket. But from reading "Wicket in Action" and looking at the example programs provided, I was able to gain a better understanding on how to use Wicket. We were able to share our experiences and tips with each other.
We designed our system the way that the Cheesr system was designed. We utilized sessions and a base page which make make it easier to include more pages down the line. Using this method, our system is easily expandable.
I feel that our group worked very well together. We were able meet on 3 separate occasions which really helped in keeping ourselves on the right track and helping each other if we got stuck. We split up the tasks between us and worked on the system both on our own and as a group. The following is a screenshot of our Software ICU.
Monday, November 16, 2009
Wattdepot-cli-elima Version 2
The goals of this assignment are to improve upon the previous implementation of the Wattdepot command line interface client while also adding some new functionality. We added 3 new functions on top of the commands already available in the previous 1.* verion.
Our 2.* version of the software satisfies most of the requirements of the assignment. We fixed most of the issues that the reviewers brought up during the code review process. Our system utilizes the interface-based design pattern which makes it very easy to add new commands to the current system. We have JUNit tests that test the basics of each of the commands. The coverage from the results of emma are below:
[concat] Emma coverage summary
[concat] class: 92% (24/26)
[concat] method: 90% (52/58)
[concat] block: 60% (1677/2812)
[concat] line: 57% (338.8/591)
Me and my partner, John Mack, communicated regularly to see the status of each others developments. We were able to seperate the work equally so taht we could each work on the system as much as we could. We both contirbuted equally to our implementation of the Wattdepot-cli command line system.
During this version of the system, we implemented a ICU with a Hackystat server. We had trouble with making it work correctly. My data was not displayed in the project, but rather in the default area. A screen shot of our software ICU is below:
With the data that is available, it is easy to see that most of the development time was later in the cycle.
We were also tasked with answering some questions to utilize the commands we had written. They are as follows:
1. What day and time during the month was Oahu energy usage at its highest? How many MW was this?
The following days had the same max amount of energy usage: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13 at 8:00pm. 9.95E8.
2. What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
The following days had the same minimum amount of energy usage: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13 at 4:00am. 4.93E8.
3. What day during the month did Oahu consume the most energy? How many MWh was this?
The following days had the same max amount of energy consumed: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13. 1.475569888888889E10.
4. What day during the month did Oahu consume the least energy? How many MWh was this?
The following days had the same minimum amount of energy consumed: November 1, 7, 8, 14, and 15. 1.408044888888889E10.
5. What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
The following days had the same max amount of energy consumed: November 4, 5, and 13. 2.9942736666666664E7.
6. What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted? The following days had the same max amount of energy consumed: November 7 and 8. 2.2895116928888887E7.
We got these answers from writing a program to run the respective commands for each of the days.
Our 2.* version of the software satisfies most of the requirements of the assignment. We fixed most of the issues that the reviewers brought up during the code review process. Our system utilizes the interface-based design pattern which makes it very easy to add new commands to the current system. We have JUNit tests that test the basics of each of the commands. The coverage from the results of emma are below:
[concat] Emma coverage summary
[concat] class: 92% (24/26)
[concat] method: 90% (52/58)
[concat] block: 60% (1677/2812)
[concat] line: 57% (338.8/591)
Me and my partner, John Mack, communicated regularly to see the status of each others developments. We were able to seperate the work equally so taht we could each work on the system as much as we could. We both contirbuted equally to our implementation of the Wattdepot-cli command line system.
During this version of the system, we implemented a ICU with a Hackystat server. We had trouble with making it work correctly. My data was not displayed in the project, but rather in the default area. A screen shot of our software ICU is below:
With the data that is available, it is easy to see that most of the development time was later in the cycle.
We were also tasked with answering some questions to utilize the commands we had written. They are as follows:
1. What day and time during the month was Oahu energy usage at its highest? How many MW was this?
The following days had the same max amount of energy usage: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13 at 8:00pm. 9.95E8.
2. What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
The following days had the same minimum amount of energy usage: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13 at 4:00am. 4.93E8.
3. What day during the month did Oahu consume the most energy? How many MWh was this?
The following days had the same max amount of energy consumed: November 2, 3, 4, 5, 6, 9, 10, 11, 12, and 13. 1.475569888888889E10.
4. What day during the month did Oahu consume the least energy? How many MWh was this?
The following days had the same minimum amount of energy consumed: November 1, 7, 8, 14, and 15. 1.408044888888889E10.
5. What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
The following days had the same max amount of energy consumed: November 4, 5, and 13. 2.9942736666666664E7.
6. What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted? The following days had the same max amount of energy consumed: November 7 and 8. 2.2895116928888887E7.
We got these answers from writing a program to run the respective commands for each of the days.
Monday, November 9, 2009
WattDepot Code Review
Code review is an important aspect of code design and the review process. It is very effective in finding problems with the code that automated tools wouldn't be able to find. Developers also gain a lot of knowledge in seeing other peoples implementations and having their own work critiqued. We each had 2 branches of the command line interfaces for WattDepot to review. I reviewed the Ehiku and Ewalu branches of the WattDepot.
Ehiku branch:
The branch wasn't separated into a command and processor subpackage. This branch had all of the commands working except for the chart command. It wouldn't save to the specified filename and the result file wasn't a html file. There weren't any test cases. Overall a very good job.
Download Here
Ewalu branch:
Again, this branch wasn't separated into a command and processor subpackage. This branch had all of the commands working. All of the commands were located in a single class, Command.java. The test cases were mostly happy path tests. This team also did a very good job.
Download Here
Ehiku branch:
The branch wasn't separated into a command and processor subpackage. This branch had all of the commands working except for the chart command. It wouldn't save to the specified filename and the result file wasn't a html file. There weren't any test cases. Overall a very good job.
Download Here
Ewalu branch:
Again, this branch wasn't separated into a command and processor subpackage. This branch had all of the commands working. All of the commands were located in a single class, Command.java. The test cases were mostly happy path tests. This team also did a very good job.
Download Here
Wednesday, November 4, 2009
WattDepot Command Line Interface
We wrote a client to provide a command line interface to WattDepot. WattDepot gathers eleectrical data from different meters. Using the API, we were able to access the information and use it to give a user meaningful data on the energy use of different power plants in Hawaii.
I worked with John Mack to implement the command line interface for WattDepot. We were able to integrate the interface-based design pattern, which at first was more difficult to do, the benefits were evident later on. We were not able to implement the list source summary and we dont have data integrity checks or tests.
One of the biggest problems with working with another programmer on a project is the sharing of code. Luckily, SVN provided us with a solution that helped to lessen the hassle of collaboration. Working with a partner sometimes makes it difficult to do as you would like, for fear that you may confuse your partner. Most times when you make a change you need to explain to your partner what you did so that they can understand and utilize the changes that you made. We broke up the work by just working on our own things until we got stuck. Then we would work together to solve the problem before moving on.
I worked with John Mack to implement the command line interface for WattDepot. We were able to integrate the interface-based design pattern, which at first was more difficult to do, the benefits were evident later on. We were not able to implement the list source summary and we dont have data integrity checks or tests.
One of the biggest problems with working with another programmer on a project is the sharing of code. Luckily, SVN provided us with a solution that helped to lessen the hassle of collaboration. Working with a partner sometimes makes it difficult to do as you would like, for fear that you may confuse your partner. Most times when you make a change you need to explain to your partner what you did so that they can understand and utilize the changes that you made. We broke up the work by just working on our own things until we got stuck. Then we would work together to solve the problem before moving on.
Sunday, October 18, 2009
Midterm pre-test
These are questions to practice on for the upcoming midterm. Good luck!
1. What is the philosophical issue that GNU group is based on?
The appropriate way to promote software is to free it from commercial interests.
2. What is the stance of the BSD group?
Users should have easy access to the source of programs.
3. Which approach of development would the Emacs editor fall under according to Eric Raymond's paper, "The Cathedral and the Bazaar"?
Richard Stallman scrutinized every line of code which was added to the kernel. This would fall under the "Cathedral" style.
4. Does subversion follow the "Cathedral" or "Bazaar" philosophy? What about GIT?
subversion -> Cathedral
git -> Bazaar
5. In an SCM system, why shouldn't you share workspaces?
A workspace should be for a single user/project to reduce confusion. Also, the SCM system will be unable to track changes based on user or task.
6. What are the advantages for using a distibuted version control system like Git?
1) You have a perfect clone of the project from the server.
2) Since you have a offline copy, you don't need to go online and are not slowed down by server access.
3) Since its possible for multiple people to have a copy of the project, you can always get the project from a fellow developer.
4) You can add bits and pieces from different projects and incorporate them into your own version of the project.
7. A Standford study tested heavy multitaskers and light multitaskers in a variety of tasks. Did heavy multitaskers or light multitaskers do better when ignoring things? Storing and organizing information? Switching from one thing to another?
The light multitaskers outperformed the heavy multitaskers in each of the tests.
8. Name the benefits to using open source software.
1) Since the source code is available, any developer can make the changes that they want to make.
2) A community to collaborate with.
3) It's free.
4) It's ok to use, modify, and redistribute the project.
9. What are the requirements for on open source project?
1) You are allowed to redistribute the project for free.
2) The source code must be available.
3) The license must allow modifications and derived works.
4) Derived works might be required to be distributed under a different name or version number.
5) No discrimination against people or groups
6) No discrimination against use in a specific field
7) The license is redistributed along with the project.
8) The license must not be specific to a product
9) The license can't put restrictions on other programs included with the project
10. While using a version control system, two developers check out the same file and make changes to that file. What is this called? What problems could arise from this arrangement?
This is called nonlocking. The second user to commit the file will be told that the version they have is out of date. They will need to update before commiting their version of the file and make any changes to the code to resolve any inconsistency issues.
1. What is the philosophical issue that GNU group is based on?
The appropriate way to promote software is to free it from commercial interests.
2. What is the stance of the BSD group?
Users should have easy access to the source of programs.
3. Which approach of development would the Emacs editor fall under according to Eric Raymond's paper, "The Cathedral and the Bazaar"?
Richard Stallman scrutinized every line of code which was added to the kernel. This would fall under the "Cathedral" style.
4. Does subversion follow the "Cathedral" or "Bazaar" philosophy? What about GIT?
subversion -> Cathedral
git -> Bazaar
5. In an SCM system, why shouldn't you share workspaces?
A workspace should be for a single user/project to reduce confusion. Also, the SCM system will be unable to track changes based on user or task.
6. What are the advantages for using a distibuted version control system like Git?
1) You have a perfect clone of the project from the server.
2) Since you have a offline copy, you don't need to go online and are not slowed down by server access.
3) Since its possible for multiple people to have a copy of the project, you can always get the project from a fellow developer.
4) You can add bits and pieces from different projects and incorporate them into your own version of the project.
7. A Standford study tested heavy multitaskers and light multitaskers in a variety of tasks. Did heavy multitaskers or light multitaskers do better when ignoring things? Storing and organizing information? Switching from one thing to another?
The light multitaskers outperformed the heavy multitaskers in each of the tests.
8. Name the benefits to using open source software.
1) Since the source code is available, any developer can make the changes that they want to make.
2) A community to collaborate with.
3) It's free.
4) It's ok to use, modify, and redistribute the project.
9. What are the requirements for on open source project?
1) You are allowed to redistribute the project for free.
2) The source code must be available.
3) The license must allow modifications and derived works.
4) Derived works might be required to be distributed under a different name or version number.
5) No discrimination against people or groups
6) No discrimination against use in a specific field
7) The license is redistributed along with the project.
8) The license must not be specific to a product
9) The license can't put restrictions on other programs included with the project
10. While using a version control system, two developers check out the same file and make changes to that file. What is this called? What problems could arise from this arrangement?
This is called nonlocking. The second user to commit the file will be told that the version they have is out of date. They will need to update before commiting their version of the file and make any changes to the code to resolve any inconsistency issues.
Tuesday, October 13, 2009
Google Project Hosting
I have added my robocode project to Google Project Hosting. The project can be found here. It is exciting to know that my robot can be downloaded and developed by anyone who is interested. I was able to accomplish all of the tasks except those which required codesite-noreply@google.com to be added to the dicussion group. There is a bug which is preventing this from working properly. I have posted into the issue posting found here. At the time of the posting, my project hasn't been added.
The was only some slight difficulty in locating some of the settings that needed to be changed. Ohterwise, it was very strightforward to put my project onto Google Project Hosting. I am excited to have my code out there for the world to see.
The was only some slight difficulty in locating some of the settings that needed to be changed. Ohterwise, it was very strightforward to put my project onto Google Project Hosting. I am excited to have my code out there for the world to see.
Wednesday, October 7, 2009
Testing, testing, 123
Writing JUnit tests for a robocode robot make it very easy to test to see if your robot is doing what you're expecting it to do. Also, it makes it extremely simple to check that nothing is lost while you are making changes in efforts to improve functionality. My Runner robot has an admittedly very simple strategy so there isnt much to test.
The easiest tests to create were the acceptance tests, which only checked to see whether or not my robot won a set amount of rounds against another robot. The harder ones where to check whether or not my function to keep my robot headed in a somewhat diagonal heading worked or not. Testing to see if my firing power based on distance was working correctly wasn't too hard. I wasn't able to test much more of my robot's other strategy so i used more than 2 acceptance tests.
I think it tests most of what my robot does. The only thing that isn't tested is whether or not my robot turns 90 degrees when it hits a wall. I wasn't able to figure out a way to check to see if its behavior was correct.
The results of Emma are as follows:
Emma Coverage summary
class: 90% (9/10)
method: 84% (42/50)
block: 74% (390/530)
line: 74% (100.4/135)
I have changed my robot's code to make it easier to write JUnit tests. I could definitely add more to test though.
Download the latest distribution here
The easiest tests to create were the acceptance tests, which only checked to see whether or not my robot won a set amount of rounds against another robot. The harder ones where to check whether or not my function to keep my robot headed in a somewhat diagonal heading worked or not. Testing to see if my firing power based on distance was working correctly wasn't too hard. I wasn't able to test much more of my robot's other strategy so i used more than 2 acceptance tests.
I think it tests most of what my robot does. The only thing that isn't tested is whether or not my robot turns 90 degrees when it hits a wall. I wasn't able to figure out a way to check to see if its behavior was correct.
The results of Emma are as follows:
Emma Coverage summary
class: 90% (9/10)
method: 84% (42/50)
block: 74% (390/530)
line: 74% (100.4/135)
I have changed my robot's code to make it easier to write JUnit tests. I could definitely add more to test though.
Download the latest distribution here
Wednesday, September 30, 2009
If at first you don't succeed...
... you try, try again. And that is exactly what I needed to do this time around. All the steps leading up to creating the distribution took a lot of trial and error. I was able to follow the steps in the powerpoint to create my own project and successfully run ant. Ant is a build tool that allows you to distribute your program to others regardless of platform and other settings. After that, I needed to run quality assurance tests on my code. The checks I needed to run were Checkstyle, PMD, and FindBugs. Between the 3 of them both errors coding standards and logic in the code are shown. Checkstyle reported 6 errors: 1 for not naming my class with a capital letter, 1 for not including the package.html, 2 for not ending the sentence with a period in the JavaDoc, and 2 for not adding the @param for my event functions. But those were all fixed easily enough. PMD and FindBugs didn't report any errors. Setting up JUnit was easy enough, but a silly oversight had me working on it for a while. It turned out I didn't change a package name which I thought I had. Everything else went smoothly.
It was very clear to me very early on how powerful this automated QA was. It was much quicker to find out exactly what the problem was and go back to make some changes. Then it was very fast to run the check again and see if the problem had been solved. One other thing that I realized was that the error messages are very important. Just like how we learned that descriptive comments are very important to understand the code, the messages that errors give are crucial in raising the chances that the problem can be found and fixed. Even with a good error message, it still took me some time to digest what the error was and how to fix it. If the error message had not been descriptive, I may have never found out what the problem was. This tells me that when I write ant code, I really need to be conscious of what error message I display.
You can download my distribution here
*Updated version: here
It was very clear to me very early on how powerful this automated QA was. It was much quicker to find out exactly what the problem was and go back to make some changes. Then it was very fast to run the check again and see if the problem had been solved. One other thing that I realized was that the error messages are very important. Just like how we learned that descriptive comments are very important to understand the code, the messages that errors give are crucial in raising the chances that the problem can be found and fixed. Even with a good error message, it still took me some time to digest what the error was and how to fix it. If the error message had not been descriptive, I may have never found out what the problem was. This tells me that when I write ant code, I really need to be conscious of what error message I display.
You can download my distribution here
*Updated version: here
Sunday, September 20, 2009
Runner
My robot tries to take advantage of going in the corner so the radar doesn't need to move around as much. When it gets hit, it it runs around trying to dodge bullets and waste opponent's energy. Runner's behavior is descibed below.
Movement: It goes to the bottom left corner and stays there unless it gets hit. If it gets hit, It runs along the bottom trying to waste opponents energy.
Targeting: Since it goes in the corner, it only scans 90 degrees.
Firing: It fires whenever it sees a robot using power proportional to the distance.
I tested my robot against 8 sample robots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck. The results are below.
Win: RamFire, Crazy, SittingDuck
Tie: Fire, Corners, Tracker
Lose: Walls, Spinbot
It was much more challenging coming up with my own strategy for this robot. There was more trial and error to try to make it more effective. You think that one thing is going to work, but then it doesn't so you need to scrap it and start over again. Also, trying to make it match up well against 8 different robots made it more challenging.
Next time, I think I'm going to try with a completely different strategy. Now even though my current robot isn't very competitive, at least I know some things to avoid.
Download Here
Movement: It goes to the bottom left corner and stays there unless it gets hit. If it gets hit, It runs along the bottom trying to waste opponents energy.
Targeting: Since it goes in the corner, it only scans 90 degrees.
Firing: It fires whenever it sees a robot using power proportional to the distance.
I tested my robot against 8 sample robots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck. The results are below.
Win: RamFire, Crazy, SittingDuck
Tie: Fire, Corners, Tracker
Lose: Walls, Spinbot
It was much more challenging coming up with my own strategy for this robot. There was more trial and error to try to make it more effective. You think that one thing is going to work, but then it doesn't so you need to scrap it and start over again. Also, trying to make it match up well against 8 different robots made it more challenging.
Next time, I think I'm going to try with a completely different strategy. Now even though my current robot isn't very competitive, at least I know some things to avoid.
Download Here
Tuesday, September 15, 2009
Robocode's Sample Robots Strategies
When you install Robocode, you see a list of sample robots ready for you to test and become familiar with the Robocode universe. When you see these for the first time, not having written any Robots, they seem to be very sophisticated and you begin to question whether you can write a robot that can compete with the default set of robots. Are these seemingly creative and complex robots really that good? Below is a list of 8 robots which are described based on movement, tracking, and shooting.
Walls
1. Movement: This robot moves along the walls, from corner to corner, nonstop.
2. Targeting: Walls' radar doesn't turn and always faces to the opposite side of the battlefield.
3. Firing: It shoots when it is facing a robot.
RamFire
1. Movement: RamFire chases its enemy to ram them to cause damage.
2. Targeting: When this robot doesn't have a target, it spins around until it finds one. If it goes to an enemy, but the enemy is no longer there, it once again spins around until it's radar finds a robot.
3. Firing: It shoots at max power when it rams into an opponent causing a great amount of damage. Very aggressive!
SpinBot
1. Movement: It goes around in a circle over and over, unless it runs into another robot, in which case it was turn so it can continue doing donuts.
2. Targeting: It's radar always faces forwards. So as the robot spins, the radar is able to scan the entire battlefield.
3. Firing: SpinBot's shoots a bullet at max speed when it's radar picks up an enemy.
Crazy
1. Movement: This robot runs around in a very erratic pattern. It consists of movements like a sin/cos wave and semi circles. It is unpredictable for other robots. It even drives backwards when it hits a wall!
2. Targeting: Crazy's radar, like most of the previously review robots, only faces forward; never turning. It crazy, hence the name, movement also results in an unpredictable radar.
3. Firing: When it finds a enemy on its radar, it fires a low power bullet.
Fire
1. Movement: This robot doesn't move unless it gets hit. Then, it just does a simple move forwards or backwards to avoid multiple hits.
2. Targeting: Fire's radar spins until it finds an enemy. It keeps locked on until the radar looses track. Then the radar spins again to find a robot.
3. Firing: It fires hard if it has a lot of energy left and the enemy is close. If not, it just fires with low power.
Sitting Duck
1. Movement: It doesn't move. At all. Not even when it's hit.
2. Targeting: It doesn't turn and doesn't scan.
3. Firing: Can you guess when Sitting Duck fires? Never. Hard not to feel a little bad for this yellow robot.
Corners
1. Movement: This robot goes straight up to the top of the battlefield, then goes to the top left corner and just sits there. If it does poorly this round (75% of robots still alive when it dies), it chooses a new corner for next round.
2. Targeting: When in the corner, Corners sweeps it radar back and forth. Since it is in a corner, it only needs to sweep 90 degrees.
3. Firing: When it finds an opponent, it fires with a strength proportional to the distance to the enemy.
Tracker
1. Movement: Tracker chases a robot until it is 150 pixels away. If the other robot gets closer than 100 pixels it runs 40 pixels to get more space.
2. Targeting: This robot uses a clever tracking system to turn its radar based on the number of turns it loses track of the enemy. This results in a effective targeting system.
3. Firing: When it is at an optimal distance from the opponent and sees it on the radar, Tracker shoots with maximum power since it is so close.
Walls
1. Movement: This robot moves along the walls, from corner to corner, nonstop.
2. Targeting: Walls' radar doesn't turn and always faces to the opposite side of the battlefield.
3. Firing: It shoots when it is facing a robot.
RamFire
1. Movement: RamFire chases its enemy to ram them to cause damage.
2. Targeting: When this robot doesn't have a target, it spins around until it finds one. If it goes to an enemy, but the enemy is no longer there, it once again spins around until it's radar finds a robot.
3. Firing: It shoots at max power when it rams into an opponent causing a great amount of damage. Very aggressive!
SpinBot
1. Movement: It goes around in a circle over and over, unless it runs into another robot, in which case it was turn so it can continue doing donuts.
2. Targeting: It's radar always faces forwards. So as the robot spins, the radar is able to scan the entire battlefield.
3. Firing: SpinBot's shoots a bullet at max speed when it's radar picks up an enemy.
Crazy
1. Movement: This robot runs around in a very erratic pattern. It consists of movements like a sin/cos wave and semi circles. It is unpredictable for other robots. It even drives backwards when it hits a wall!
2. Targeting: Crazy's radar, like most of the previously review robots, only faces forward; never turning. It crazy, hence the name, movement also results in an unpredictable radar.
3. Firing: When it finds a enemy on its radar, it fires a low power bullet.
Fire
1. Movement: This robot doesn't move unless it gets hit. Then, it just does a simple move forwards or backwards to avoid multiple hits.
2. Targeting: Fire's radar spins until it finds an enemy. It keeps locked on until the radar looses track. Then the radar spins again to find a robot.
3. Firing: It fires hard if it has a lot of energy left and the enemy is close. If not, it just fires with low power.
Sitting Duck
1. Movement: It doesn't move. At all. Not even when it's hit.
2. Targeting: It doesn't turn and doesn't scan.
3. Firing: Can you guess when Sitting Duck fires? Never. Hard not to feel a little bad for this yellow robot.
Corners
1. Movement: This robot goes straight up to the top of the battlefield, then goes to the top left corner and just sits there. If it does poorly this round (75% of robots still alive when it dies), it chooses a new corner for next round.
2. Targeting: When in the corner, Corners sweeps it radar back and forth. Since it is in a corner, it only needs to sweep 90 degrees.
3. Firing: When it finds an opponent, it fires with a strength proportional to the distance to the enemy.
Tracker
1. Movement: Tracker chases a robot until it is 150 pixels away. If the other robot gets closer than 100 pixels it runs 40 pixels to get more space.
2. Targeting: This robot uses a clever tracking system to turn its radar based on the number of turns it loses track of the enemy. This results in a effective targeting system.
3. Firing: When it is at an optimal distance from the opponent and sees it on the radar, Tracker shoots with maximum power since it is so close.
Monday, September 14, 2009
Coding Standards For You and For Me
Coding standards are something that all students learn when they first start taking programming courses. At first, when everyone is worried about just figuring out how to make their program work, comments and the like are the last thing on a student's mind. As I have progressed through the ICS courses I have taken, the benefits of coding standards become more and more clear.
The biggest reason that I see for coding standards is for anyone to be able to understand how the code works. While it is beneficial for other to be able to read your code, the advantages extend to the author of the code themself! I have come back to code that I have written months before and took a long time to figure out what I was trying to do. It is never a bad thing for your code to be clear and easy to understand.
Also, the ability for anyone in the coding community to learn and collaborate is extremely powerful. Programmers on a team can quickly understand each others code and when it is put all together, everything that someone was interested in would all be consolidated and is all of the same form. Without coding standards, open source software couldn't exist.
I applied the coding standards that we learned in class to the robocode robots that I have previously written. Some of them didn't work and I had a bunch of trouble figuring them out. Looking at the examples of Kendyll Doi and Kimberly Heu, I was able to get my robots working and improved on my previous implementations. At first, I didn't have any comments and probably broke a majority of the rules. Now that I have applied the standards, it is evident that my code is much cleaner and is much easier for someone else to read.
The coding standards that were applied to my robocode project are below:
Elements of Java Style
ICS Coding Standards
ICS Robocode Standards
Download my robocode project here
The biggest reason that I see for coding standards is for anyone to be able to understand how the code works. While it is beneficial for other to be able to read your code, the advantages extend to the author of the code themself! I have come back to code that I have written months before and took a long time to figure out what I was trying to do. It is never a bad thing for your code to be clear and easy to understand.
Also, the ability for anyone in the coding community to learn and collaborate is extremely powerful. Programmers on a team can quickly understand each others code and when it is put all together, everything that someone was interested in would all be consolidated and is all of the same form. Without coding standards, open source software couldn't exist.
I applied the coding standards that we learned in class to the robocode robots that I have previously written. Some of them didn't work and I had a bunch of trouble figuring them out. Looking at the examples of Kendyll Doi and Kimberly Heu, I was able to get my robots working and improved on my previous implementations. At first, I didn't have any comments and probably broke a majority of the rules. Now that I have applied the standards, it is evident that my code is much cleaner and is much easier for someone else to read.
The coding standards that were applied to my robocode project are below:
Elements of Java Style
ICS Coding Standards
ICS Robocode Standards
Download my robocode project here
Wednesday, September 9, 2009
Battle to the death!
Robocode is a program that lets you program your own robot to fight other robots on a virtual battlefield. The robots can run around, scan for enemies with a radar, and shoot with a gun. The more strategy you put into your robot, the better it will fair in the arena.
Getting Robocode installed and working with eclipse was easy with the help of the video guide. I had no problems getting it all to work. The tricky part came with programming the robots.
We had 12 robots to program. Each focusing on one of the 3 main actions of the robots: running, targeting, and shooting. Getting the robots to move around wasn't too difficult. I couldn't figure out how to use the trigonometry so I had to resort to vertical and horizontal movements. The tracking gave me a lot more trouble and my robots still aren't working the way they're supposed to. I couldn't get the robots that required tracking of a single enemy robot working correctly. The firing wasn't as difficult. The shooting was pretty straightforward after the tracking robots. I used the following page and it was really helpful. Link
Robocode has been a really interesting way to practice programming. It was really different seeing the code you write reflect robots fighting each other on screen. It was certainly more entertaining than the regular coding. I think this is a great way to get students more interested in programming and more courses should try to incorporate something like this to break the cycle of plain programs week after week.
Robocode project: Download
Getting Robocode installed and working with eclipse was easy with the help of the video guide. I had no problems getting it all to work. The tricky part came with programming the robots.
We had 12 robots to program. Each focusing on one of the 3 main actions of the robots: running, targeting, and shooting. Getting the robots to move around wasn't too difficult. I couldn't figure out how to use the trigonometry so I had to resort to vertical and horizontal movements. The tracking gave me a lot more trouble and my robots still aren't working the way they're supposed to. I couldn't get the robots that required tracking of a single enemy robot working correctly. The firing wasn't as difficult. The shooting was pretty straightforward after the tracking robots. I used the following page and it was really helpful. Link
Robocode has been a really interesting way to practice programming. It was really different seeing the code you write reflect robots fighting each other on screen. It was certainly more entertaining than the regular coding. I think this is a great way to get students more interested in programming and more courses should try to incorporate something like this to break the cycle of plain programs week after week.
Robocode project: Download
Monday, August 31, 2009
FizzBuzz
From opening eclipse to verifying the correct output of my FizzBuzz program, I took 6 minutes 34 seconds.
I didn't run into any of the problems that I had when trying writing this program for the first time. Eclipse ran as expected and I was able to write and run the FizzBuzz program quickly. The first time I tried this program in class, I was very rusty in Java, having not used it in a while. I forgot the syntax and was missing parts of the main() function.
The FizzBuzz program has revealed to me that I needed to review my Java.
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 % 3) == 0) {
System.out.println("Fizz");
}
ELSE IF ((i % 5) == 0) {
System.out.println("Buzz");
}
ELSE { System.out.println(i); }
}
}
}I didn't run into any of the problems that I had when trying writing this program for the first time. Eclipse ran as expected and I was able to write and run the FizzBuzz program quickly. The first time I tried this program in class, I was very rusty in Java, having not used it in a while. I forgot the syntax and was missing parts of the main() function.
The FizzBuzz program has revealed to me that I needed to review my Java.
Sunday, August 30, 2009
OSS Experience
RSS Owl RSS / RDF / Atom Newsreader
http://sourceforge.net/projects/rssowl/
Overview: RSS Owl is an open-source RSS feed aggregator. It is used to organize and view various feeds in different formats including: RSS, RDF, and Atom.
Prime Directive 1: "The system successfully accomplishes a useful task." The main function of RSS Owl is a feed aggregator. It consolidates all of the feeds and allows you to view them in a common view. You can also import feeds from different applications through the OPML format. When you get the newsfeeds that you want, you can view the items in the feeds; both online and offline.
Prime Directive 2: "An external user can successfully install and use the system." As a non-developer, it was easy to install and use the system. Downloading and installing the program was simple and straightforward. When you start it for the first time, it lets you choose to view a tutorial. Importing feeds was quick and I was viewing my newsfeeds shortly after.
Prime Directive 3: "An external developer can successfully understand and enhance the system." It is easy for an external developer to contribute to the program. An API is provided for anyone interested in the project. There is both a wiki and discussion forum for new developers to get more information and learn from other developers.
http://sourceforge.net/projects/rssowl/
Overview: RSS Owl is an open-source RSS feed aggregator. It is used to organize and view various feeds in different formats including: RSS, RDF, and Atom.
Prime Directive 1: "The system successfully accomplishes a useful task." The main function of RSS Owl is a feed aggregator. It consolidates all of the feeds and allows you to view them in a common view. You can also import feeds from different applications through the OPML format. When you get the newsfeeds that you want, you can view the items in the feeds; both online and offline.
Prime Directive 2: "An external user can successfully install and use the system." As a non-developer, it was easy to install and use the system. Downloading and installing the program was simple and straightforward. When you start it for the first time, it lets you choose to view a tutorial. Importing feeds was quick and I was viewing my newsfeeds shortly after.
Prime Directive 3: "An external developer can successfully understand and enhance the system." It is easy for an external developer to contribute to the program. An API is provided for anyone interested in the project. There is both a wiki and discussion forum for new developers to get more information and learn from other developers.
Subscribe to:
Posts (Atom)