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.
Sunday, October 18, 2009
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
Subscribe to:
Posts (Atom)