Software Engineering:
This software engineering class has been one the hardest and most time consuming classes I've had. I have also learned a lot and gained many experiences that make me feel more prepared going out in the real world. I had been unsure of my programming ability before taking this class, but I now feel like I have the practice and the tools I need to overcome any obstacle.
Some of the things I think could have been improved in this course is the presentation of Wicket. I felt overwhelmed when given a book towards the end of the semester and having to learn something from scratch in a short period of time. It would have been less stressful if we learned about it earlier and more gradually. I also think the lectures given online could have been spread out more evenly as well. Having to watch three lectures in one day for one class was a little tedious.
Valuable Lessons:
I think the most valuable lesson I learned from this software engineering course was teamwork. Throughout my college classes it has always been about yourself. You and only you are responsible for the outcome of your assignments and your grade. You rely on yourself to complete your work and you do it in your way. However, this is not the case in the real world. There is always interaction with other people and most likely you will work in a team. This was my first real experience working on teams and it has been a great learning experience. Learning how to communicate effectively, the importance of doing your part, and helping each other out has been valuable lessons learned.
Learning More:
I will be taking the continuation of the course next semester and I look forward to the experiences that will come. I am interested in a career in software engineering and this class is a great way to get a head start. I recently did an internship and many of my coworkers said this was one of the classes they learned the most from. I hope to continue working in Java because it is my language of choice but I also would like to use other languages as well.
Thursday, December 17, 2009
GreenSmart 2.0
Version 2.0:
Version 2.0 of GreenSmart including fixes to problems that occurred in version 1.0 and adding new features. The system now includes three main pages: the Homepage, the GridInfo page, and the Stoplight page.
The homepage includes links to the other pages as well as a description and screenshot of the GridInfo page and Stoplight page to guide the user. The GridInfo page contains a chart produced in Google Charts that displays the carbon intensity of the users selected time period. The user can also select different sources and different intervals at which points to retrieve the data. The background colors of the chart indicate the threshold and let the user know if the carbon content was high, medium, or low at that time. The stoplight page shows a picture of a stoplight where the light indicates the current carbon intensity and gives suggestions about energy usage. There is also a contact page with information on how to get in contact with the Greensmart team.
In this latest version we made many improvements. We added links to all pages in every page to help users navigate the website more easily. The background was also changed to white to create a cleaner backdrop. Scott also redesigned the GreenSmart logo to make it more personalized.
Lessons Learned:
Now that the project is over I realized that I learned a lot from this experience. I learned how important communication is and how it leads to better efficiency and less headaches. There were times when people would work on a task and later find out someone else had already finished it. I also learned the consequences of procrastination and not starting on a project right away. It is a lot less stressful when you space out the work and not try to finish everything the night before it is due. Overall, I learned a lot from this project and I enjoyed working with my teammates.
Download: link
Version 2.0 of GreenSmart including fixes to problems that occurred in version 1.0 and adding new features. The system now includes three main pages: the Homepage, the GridInfo page, and the Stoplight page.
The homepage includes links to the other pages as well as a description and screenshot of the GridInfo page and Stoplight page to guide the user. The GridInfo page contains a chart produced in Google Charts that displays the carbon intensity of the users selected time period. The user can also select different sources and different intervals at which points to retrieve the data. The background colors of the chart indicate the threshold and let the user know if the carbon content was high, medium, or low at that time. The stoplight page shows a picture of a stoplight where the light indicates the current carbon intensity and gives suggestions about energy usage. There is also a contact page with information on how to get in contact with the Greensmart team.
In this latest version we made many improvements. We added links to all pages in every page to help users navigate the website more easily. The background was also changed to white to create a cleaner backdrop. Scott also redesigned the GreenSmart logo to make it more personalized.
Lessons Learned:
Now that the project is over I realized that I learned a lot from this experience. I learned how important communication is and how it leads to better efficiency and less headaches. There were times when people would work on a task and later find out someone else had already finished it. I also learned the consequences of procrastination and not starting on a project right away. It is a lot less stressful when you space out the work and not try to finish everything the night before it is due. Overall, I learned a lot from this project and I enjoyed working with my teammates.
Download: link
Monday, November 23, 2009
WattWaiter: One review coming up
After completing my web app GreenSmart described in my previous post I looked at other groups' systems and did a review of the WattWaiter system. I used some guidelines for this review and the entire review can be found at the link at the bottom of this post.
Some of the things I noticed about this system was how nice the web page looked and the robustness of the system itself. The page looks professional and I liked the use of colored flags as an indicator of the level of carbon intesity. They created their own logo and incorporated a nice style into their page so it did not look bland. Also, no matter what bad data I input into their system I could not break it and the bad data was handled correctly.
Some things about the system that could be improved would be the layout of the results and the descriptiveness of what the results mean. It would be easier to read if all the data was in one column instead of two for easy viewing and be able to fit in a single frame. There is also the problem of understandability because the only results given is a number of the hour and a colored flag. Another reason to include more information about what the flags mean would be the fact that some people are colorblind and would have absolutely no idea what the flags are there for.
Overall I was very impressed with the WattWaiter system and I look forward to seeing the kinds of improvements they will be able to make in the next version.
Read my entire review: WattWaiter Review
Sunday, November 22, 2009
GreenSmart
After creating the WattDepot command-line interface, I have begun a web application modeled after ecotricity. The desired outcome would be a system that shows for every hour of a chosen day, the carbon content and the carbon intensity of the Oahu Grid.
I was on the GreenSmart team which consisted of myself, Scott Wong, John Mack, and Anthony Xu. I had no problems working with my team and we each contributed to the project.
Getting the data and creating the methods to calculate the results was the easy part. We had already worked on similar methods in the WattDepot-CLI. Although it we had already had some practice with the WattDepot-CLI it was not without effort.
The software ICU, which was discussed in previous posts, was also used again and is shown at the top of this post. We had some initial problems setting up the software ICU, we forgot to modify one portion of one of the xml files, so we missed some data for the first couple of days. From this image you can see that some parts of the project did not go as smoothly as planned. We did not write as much tests as we should have, although we may have not set up the sensors correctly because I wrote tests for all of the methods I wrote for the carbon content calculations but it only reported 1 unit test.
The hardest part of the project was integration. We each worked on separate parts of the system; the design of the page, getting the user's input, calculating the output, and displaying the output. In theory all of our parts seemed correct but when we tried to incorporate the parts together we had some difficulties. For me, the hardest part was understanding wicket. I started read "Wicket in Action" and looked at some articles online about wicket but I am definitely still in the learning phase.
GreenSmart: homepage
GreenSmart: download
Monday, November 16, 2009
The second round: WattDepot CLI 2.0
WattDepot CLI 2.0
WattDepot cli v2.0 has an updated WattDepot library and supports the new version 2.0 command line interface, which includes three new commands and makes small changes to the previous commands ("list sources" is now just "sources", etc.).
Eono 2.0
This second version allowed us to improve our old code by changing the organization of the system to include an interface. We also simplified old methods and added tests to the majority of the system. To my knowledge I think we satisfied all the requirements and took care of almost all of the issues raised by the reviewers. A lot of time was put into this project as well as careful attention to detail. There is a suite of high quality tests included in which the coverage can be seen in the Emma coverage report(class 100%, method 99%, block 84%, line 82%).
Eono Group
Scott Wong and I were on the Eono team and we met when we were free. This ended up resulting in meetings a couple of times a week (3-5) for 3-6 hours in duration. We split up the work pretty evenly and for most tasks, such as the 10 original commands that were implemented, we just divided the work in half and were responsible for our share. Although we divided up the work, we regularly helped each other out when someone was having problems and volunteered to do certain tasks willingly. I think we both carried our own weight and put a lot of effort into this project.
Software ICU
The software ICU is used to monitor "vital" signs to ensure a "healthy" project. This includes work being done consistently, equally, commited consistantly, of high quality, etc. I forgot to attach some of the sensors which is why the Test jumps from 1 to 40 (I also forgot to commit some of the tests until the end). From the software ICU it seems as if the project is more healthy than unhealthy but there are some values in the red.
Questions
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
2009-11-02T19:00:00.000-10:00 : 9.835E8
(found by looping through all dates from 11/01-11/15 1 hr at a time at 30 min intervals, used holders to keep the largest value)
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
2009-11-02T04:00:00.000-10:00 : 4.97E8
(found by looping through all dates from 11/01-11/15 1 hr at a time at 30 min intervals, used holders to keep the lowest value)
What day during the month did Oahu consume the most energy? How many MWh was this?
highest: 2009-11-02 (monday) : 14764.0 MWh
(calculated the energyGenerated by the Oahu_Grid each day and found the day with the greatest energy)
What day during the month did Oahu consume the least energy? How many MWh was this?
lowest: 2009-11-07 (saturday) : 14089.0 MWh
(calculated the energyGenerated by the Oahu_Grid each day and found the day with the lowest energy)
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
highest: 2009-11-04 (wednesday) : 2.9959472E7 lbs
(calculated the carbonGenerated by the Oahu_Grid each day and found the day with the highest carbon emitted)
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
lowest: 2009-11-07 (saturday) : 2.2908808E7 lbs
(calculated the carbonGenerated by the Oahu_Grid each day and found the day with the lowest carbon emitted)
Download: WattDepot-Cli-eono-2.0.1116
WattDepot cli v2.0 has an updated WattDepot library and supports the new version 2.0 command line interface, which includes three new commands and makes small changes to the previous commands ("list sources" is now just "sources", etc.).
Eono 2.0
This second version allowed us to improve our old code by changing the organization of the system to include an interface. We also simplified old methods and added tests to the majority of the system. To my knowledge I think we satisfied all the requirements and took care of almost all of the issues raised by the reviewers. A lot of time was put into this project as well as careful attention to detail. There is a suite of high quality tests included in which the coverage can be seen in the Emma coverage report(class 100%, method 99%, block 84%, line 82%).
Eono Group
Scott Wong and I were on the Eono team and we met when we were free. This ended up resulting in meetings a couple of times a week (3-5) for 3-6 hours in duration. We split up the work pretty evenly and for most tasks, such as the 10 original commands that were implemented, we just divided the work in half and were responsible for our share. Although we divided up the work, we regularly helped each other out when someone was having problems and volunteered to do certain tasks willingly. I think we both carried our own weight and put a lot of effort into this project.
Software ICU
The software ICU is used to monitor "vital" signs to ensure a "healthy" project. This includes work being done consistently, equally, commited consistantly, of high quality, etc. I forgot to attach some of the sensors which is why the Test jumps from 1 to 40 (I also forgot to commit some of the tests until the end). From the software ICU it seems as if the project is more healthy than unhealthy but there are some values in the red.
Questions
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
2009-11-02T19:00:00.000-10:00 : 9.835E8
(found by looping through all dates from 11/01-11/15 1 hr at a time at 30 min intervals, used holders to keep the largest value)
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
2009-11-02T04:00:00.000-10:00 : 4.97E8
(found by looping through all dates from 11/01-11/15 1 hr at a time at 30 min intervals, used holders to keep the lowest value)
What day during the month did Oahu consume the most energy? How many MWh was this?
highest: 2009-11-02 (monday) : 14764.0 MWh
(calculated the energyGenerated by the Oahu_Grid each day and found the day with the greatest energy)
What day during the month did Oahu consume the least energy? How many MWh was this?
lowest: 2009-11-07 (saturday) : 14089.0 MWh
(calculated the energyGenerated by the Oahu_Grid each day and found the day with the lowest energy)
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
highest: 2009-11-04 (wednesday) : 2.9959472E7 lbs
(calculated the carbonGenerated by the Oahu_Grid each day and found the day with the highest carbon emitted)
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
lowest: 2009-11-07 (saturday) : 2.2908808E7 lbs
(calculated the carbonGenerated by the Oahu_Grid each day and found the day with the lowest carbon emitted)
Download: WattDepot-Cli-eono-2.0.1116
Review x 2
Reviewing other systems
After reviewing eiwa and elima's systems I got to see a different perspective on the project. I realized how different projects can turn out even when given the same requirements. From eiwa's system I saw how they broke down each piece of information from the user's input instead of having the user type in one long string with all of the information. I was also unsure of exactly how to structure the system and incorporate an interface. I got general ideas of how other teams organized their project through the reviews.
Getting my system reviewed
Not only did I get to see the different perspectives on how other people implemented their systems, but I also got different perspectives on how to improve my system. When you program you have one state of mind which makes it hard to spot problems in your code. There where a lot of small things that I did not think about that I would not have caught if not for the review such as a timestamp referring to a future date. Overall I had a good experience with the reviews.
After reviewing eiwa and elima's systems I got to see a different perspective on the project. I realized how different projects can turn out even when given the same requirements. From eiwa's system I saw how they broke down each piece of information from the user's input instead of having the user type in one long string with all of the information. I was also unsure of exactly how to structure the system and incorporate an interface. I got general ideas of how other teams organized their project through the reviews.
Getting my system reviewed
Not only did I get to see the different perspectives on how other people implemented their systems, but I also got different perspectives on how to improve my system. When you program you have one state of mind which makes it hard to spot problems in your code. There where a lot of small things that I did not think about that I would not have caught if not for the review such as a timestamp referring to a future date. Overall I had a good experience with the reviews.
Sunday, November 8, 2009
WattDepot CLI review: 8 eyes are better than 4
After completing the initial stage of the WattDepot Cli, which I talked about in my previous post, my peers in my software engineering class are having a code review. 4 other people in the class are reviewing the eono branch which Scott and I worked on, and I am reviewing two other groups projects, elima and eiwa.
Elima
John Mack and Anthony Xu were in the elima group. One of the major problems I found in the project was that some of the methods were not finished such as "list summary {source}" or the WattDepotCliProcessor didn't have a condition that checked for it and thus didn't recognize it as a command such as "list power [generated|consumed] {source} timestamp {timestamp}". I think if they had a little more time (which we are going to get for version 2.0) the project would be more complete. There was also little testing, but then again I think the focus was more on finishing the commands that they didn't get to work on testing. The commands that did work, worked well and they did a good job of catching exceptions in their methods.
Eiwa
Nathaniel Ashe and David Mau were in the Eiwa group. The main problem I encountered in the project was that the way the user enters information at the command line was different than all of the other projects I've seen, including Scott and my project. Instead of having all the information on one line such as "list power generated SIM_WAIAU_8 timestamp 2009-11-15T12:13:00.000-10:00" the user would enter a "list power generated" and the program would prompt the user for the rest of the necessary information, such as source and timestamp. Although at first it seemed like it would help the user so that they could easily enter the information that was needed, it actually slowed the process down. It is a lot faster to just type in one line versus waiting for a prompt for each individual piece of information. This also slowed down testing. Some of the prompts also were not clear at times as to what it wanted.
Besides this difficulty the project had a lot of testing and checks for errors such as a bad timestamp. There were jUnit tests for a lot of the methods.
These reviews were based on a checklist and I have included the detailed reviews:
Elima
Eiwa
Elima
John Mack and Anthony Xu were in the elima group. One of the major problems I found in the project was that some of the methods were not finished such as "list summary {source}" or the WattDepotCliProcessor didn't have a condition that checked for it and thus didn't recognize it as a command such as "list power [generated|consumed] {source} timestamp {timestamp}". I think if they had a little more time (which we are going to get for version 2.0) the project would be more complete. There was also little testing, but then again I think the focus was more on finishing the commands that they didn't get to work on testing. The commands that did work, worked well and they did a good job of catching exceptions in their methods.
Eiwa
Nathaniel Ashe and David Mau were in the Eiwa group. The main problem I encountered in the project was that the way the user enters information at the command line was different than all of the other projects I've seen, including Scott and my project. Instead of having all the information on one line such as "list power generated SIM_WAIAU_8 timestamp 2009-11-15T12:13:00.000-10:00" the user would enter a "list power generated" and the program would prompt the user for the rest of the necessary information, such as source and timestamp. Although at first it seemed like it would help the user so that they could easily enter the information that was needed, it actually slowed the process down. It is a lot faster to just type in one line versus waiting for a prompt for each individual piece of information. This also slowed down testing. Some of the prompts also were not clear at times as to what it wanted.
Besides this difficulty the project had a lot of testing and checks for errors such as a bad timestamp. There were jUnit tests for a lot of the methods.
These reviews were based on a checklist and I have included the detailed reviews:
Elima
Eiwa
Wednesday, November 4, 2009
Wattdepot-cli: eono
For the past week I have been working on a WattDepot CLI which "provides a simple command line interface for obtaining information from a WattDepot service". WattDepot collects electricity data from meters and stores it in its database.
I worked on this project with Scott Wong and I think we worked well as a team. There were 10 commands that we had to incorporate into the CLI so we split them up evenly. However, even though we had different tasks we still collaborated on our works and helped each other out.
This project gave me a lot of practice programming and has gotten me back into my programming mode. Many hours were put into this project, sometimes more than 6 hours straight. There were some set backs in the end when I had problems importing the project from subversion into my eclipse workspace. It would not recognize some methods for the WattDepotClient and reported errors. However if I copied just the source files into an older project it would run fine. I had to result in sending my changes to my partner to commit it to subversion and I am still working on how to fix this problem. Because of this experience I have a greater appreciation for continuous integration and version control.
Overall I think we finished the task of creating the commands for the CLI. I don't think we will ever really be "finished" with the project in the sense that there is always something more you can do to improve. I do however wish we could have tested the system more, but we ran out of time.
Download: WattDepotCli-eono
I worked on this project with Scott Wong and I think we worked well as a team. There were 10 commands that we had to incorporate into the CLI so we split them up evenly. However, even though we had different tasks we still collaborated on our works and helped each other out.
This project gave me a lot of practice programming and has gotten me back into my programming mode. Many hours were put into this project, sometimes more than 6 hours straight. There were some set backs in the end when I had problems importing the project from subversion into my eclipse workspace. It would not recognize some methods for the WattDepotClient and reported errors. However if I copied just the source files into an older project it would run fine. I had to result in sending my changes to my partner to commit it to subversion and I am still working on how to fix this problem. Because of this experience I have a greater appreciation for continuous integration and version control.
Overall I think we finished the task of creating the commands for the CLI. I don't think we will ever really be "finished" with the project in the sense that there is always something more you can do to improve. I do however wish we could have tested the system more, but we ran out of time.
Download: WattDepotCli-eono
Sunday, November 1, 2009
Continuous Integration
Did you ever have that problem where you're working on a project and you find a bug, but after you fix it you see something else you can add to it and then you go back and modify something else. By the time you integrate with your teammate you both have totally different works and integration seems to take longer than the actual production. This is were continuous integration comes in.
Continuous Integration
I used Hudson to provide the continuous integration system. I have used Hudson before so I did not have much problems setting it up or using it. It is very simple to use and is a useful tool to have. I did had a build fail when I thought everything should have been fine. However with closer inspection I found that I ran ant verify on the wrong project folder. In Hudson you can see the console output and there I was able to see where in the build it failed. However, you should run verify before committing because you have more information about what is wrong (through the findbugs, pmd, checkstyle results). I think having a continuous integration system is very useful and a little time spent using it saves you a lot of time at the end.
Continuous Integration
- Definition: It is a software development practice where members of a team integrate their work frequently.
- Verification: Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
- Results: Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
I used Hudson to provide the continuous integration system. I have used Hudson before so I did not have much problems setting it up or using it. It is very simple to use and is a useful tool to have. I did had a build fail when I thought everything should have been fine. However with closer inspection I found that I ran ant verify on the wrong project folder. In Hudson you can see the console output and there I was able to see where in the build it failed. However, you should run verify before committing because you have more information about what is wrong (through the findbugs, pmd, checkstyle results). I think having a continuous integration system is very useful and a little time spent using it saves you a lot of time at the end.
Tuesday, October 20, 2009
Answers please
1. A foreach or a for/in loop is a new loop that was added in Java 5.0 that executes its body once for each element in an array or collection.
for(declaration : expression)
statement
Source: Java in a Nutshell pg 50
2. More stress
Less efficiency
More frustration
More pressure, etc.
Source: http://www.nytimes.com/2008/10/25/business/yourmoney/25shortcuts.html?pagewanted=2
3. If companies use the open source software as their base, their "value added" programs might be considered "derivative works" and would then need to make the source code available even to competitors.
Source: http://www.abanet.org/intelprop/opensource.html
4. High coverage rates means that a lot of code was exercised. It doesn't mean that the code was exercised well.
Source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
5.
1)Estimating the time to modify existing code.
developers: To check code quality before attempting to modify it
managers: To get a better estimate of time a developer needs to do the work on that code.
2) Evaluating code quality
Shows where code lacks testing
3) Accessing functional testing
Use results to help facilitate risk mitigation
source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
6. GNU = GNU's Not Unix
If the GPL software is modified, it must be distributed under GPL. The GPL spreads to any modified GPL software.
7. Source available software has the source available to be viewed but it cannot be modified or redistributed like open source software.
Source: http://en.wikipedia.org/wiki/Open_source_software
8. Identity-based: Two references are equal only if they refer to the same object.
State-based: Two objects are equal only if they contain the same value.
9. List
10.
Source: "Ant in Action: Java Development with Ant"
for(declaration : expression)
statement
int[] foo = {1, 2, 3, 4, 5};
for (int i : foo) {
System.out.println(i);
{
Source: Java in a Nutshell pg 50
2. More stress
Less efficiency
More frustration
More pressure, etc.
Source: http://www.nytimes.com/2008/10/25/business/yourmoney/25shortcuts.html?pagewanted=2
3. If companies use the open source software as their base, their "value added" programs might be considered "derivative works" and would then need to make the source code available even to competitors.
Source: http://www.abanet.org/intelprop/opensource.html
4. High coverage rates means that a lot of code was exercised. It doesn't mean that the code was exercised well.
Source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
5.
1)Estimating the time to modify existing code.
developers: To check code quality before attempting to modify it
managers: To get a better estimate of time a developer needs to do the work on that code.
2) Evaluating code quality
Shows where code lacks testing
3) Accessing functional testing
Use results to help facilitate risk mitigation
source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
6. GNU = GNU's Not Unix
If the GPL software is modified, it must be distributed under GPL. The GPL spreads to any modified GPL software.
7. Source available software has the source available to be viewed but it cannot be modified or redistributed like open source software.
Source: http://en.wikipedia.org/wiki/Open_source_software
8. Identity-based: Two references are equal only if they refer to the same object.
State-based: Two objects are equal only if they contain the same value.
9. List
10.
<target name="init">
<mkdir dir="build/classes" />
</target>
Source: "Ant in Action: Java Development with Ant"
Sunday, October 18, 2009
Buddy better study
There is a midterm coming up in my software engineering class so I am posting up some review questions. See how many you can answer without using google.
1. Describe what a foreach loop does and give an example of a foreach loop.
2. List 3 consequences of multitasking.
3. Describe the concern companies have with using open source software in regards to derivative works and intellectual property rights.
4. How are coverage reports often misused?
5. What are the 3 best practices for using coverage reports according to "In pursuit of code quality: Don't be fooled by the coverage report"?
6. What does the acronym GNU stand for and what does it mean when it is said that the GNU General Public License is viral?
7. What is the difference between open source and source-available?
8. Describe the two approaches to defining equality and hash value according to "Java Theory and Practice: Hashing it out".
9. Which collection is most appropriate for a list of strings in alphabetical order with duplicates.
10. Write an ant target called "init" that creates an output directory for generated files called "build/classes".
Answers:
1. A foreach or a for/in loop is a new loop that was added in Java 5.0 that executes its body once for each element in an array or collection.
for(declaration : expression)
statement
Source: Java in a Nutshell pg 50
2. More stress
Less efficiency
More frustration
More pressure, etc.
Source: http://www.nytimes.com/2008/10/25/business/yourmoney/25shortcuts.html?pagewanted=2
3. If companies use the open source software as their base, their "value added" programs might be considered "derivative works" and would then need to make the source code available even to competitors.
Source: http://www.abanet.org/intelprop/opensource.html
4. High coverage rates means that a lot of code was exercised. It doesn't mean that the code was exercised well.
Source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
5.
1)Estimating the time to modify existing code.
developers: To check code quality before attempting to modify it
managers: To get a better estimate of time a developer needs to do the work on that code.
2) Evaluating code quality
Shows where code lacks testing
3) Accessing functional testing
Use results to help facilitate risk mitigation
source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
6. GNU = GNU's Not Unix
If the GPL software is modified, it must be distributed under GPL. The GPL spreads to any modified GPL software.
7. Source available software has the source available to be viewed but it cannot be modified or redistributed like open source software.
Source: http://en.wikipedia.org/wiki/Open_source_software
8. Identity-based: Two references are equal only if they refer to the same object.
State-based: Two objects are equal only if they contain the same value.
9. List
10.
Source: "Ant in Action: Java Development with Ant"
1. Describe what a foreach loop does and give an example of a foreach loop.
2. List 3 consequences of multitasking.
3. Describe the concern companies have with using open source software in regards to derivative works and intellectual property rights.
4. How are coverage reports often misused?
5. What are the 3 best practices for using coverage reports according to "In pursuit of code quality: Don't be fooled by the coverage report"?
6. What does the acronym GNU stand for and what does it mean when it is said that the GNU General Public License is viral?
7. What is the difference between open source and source-available?
8. Describe the two approaches to defining equality and hash value according to "Java Theory and Practice: Hashing it out".
9. Which collection is most appropriate for a list of strings in alphabetical order with duplicates.
10. Write an ant target called "init" that creates an output directory for generated files called "build/classes".
Answers:
1. A foreach or a for/in loop is a new loop that was added in Java 5.0 that executes its body once for each element in an array or collection.
for(declaration : expression)
statement
int[] foo = {1, 2, 3, 4, 5};
for (int i : foo) {
System.out.println(i);
{
Source: Java in a Nutshell pg 50
2. More stress
Less efficiency
More frustration
More pressure, etc.
Source: http://www.nytimes.com/2008/10/25/business/yourmoney/25shortcuts.html?pagewanted=2
3. If companies use the open source software as their base, their "value added" programs might be considered "derivative works" and would then need to make the source code available even to competitors.
Source: http://www.abanet.org/intelprop/opensource.html
4. High coverage rates means that a lot of code was exercised. It doesn't mean that the code was exercised well.
Source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
5.
1)Estimating the time to modify existing code.
developers: To check code quality before attempting to modify it
managers: To get a better estimate of time a developer needs to do the work on that code.
2) Evaluating code quality
Shows where code lacks testing
3) Accessing functional testing
Use results to help facilitate risk mitigation
source: http://www.ibm.com/developerworks/java/library/j-cq01316/index.html
6. GNU = GNU's Not Unix
If the GPL software is modified, it must be distributed under GPL. The GPL spreads to any modified GPL software.
7. Source available software has the source available to be viewed but it cannot be modified or redistributed like open source software.
Source: http://en.wikipedia.org/wiki/Open_source_software
8. Identity-based: Two references are equal only if they refer to the same object.
State-based: Two objects are equal only if they contain the same value.
9. List
10.
<target name="init">
<mkdir dir="build/classes" />
</target>
Source: "Ant in Action: Java Development with Ant"
Wednesday, October 14, 2009
A good host offers you food from their own fridge: Robocode Hosting
Robocode Google Project Hosting: robocode-kks-counterall
Discussion Group: robocode-kks-counterall-discuss
As I continue working on my Robocode project from my previous posts I have encountered a problem. Peers are one of your best sources for help and improvement on a project. However, reviewing someone elses code that is constantly being changed can be a hassle. I have had times when I download a project from my peer's blog I am unable to run it and have to wait for them to fix whatever they need to fix and upload the file back to their blog.
The use of google project hosting and svn helped alleviate that problem. If I want to take a look at someone elses project and make some changes that I think will improve the robot I can checkout the project, make the changes, and commit those changes.
I used TortoiseSVN which was a little confusing at first because there is no main application that starts up, and instead runs from Windows explorer. I also had some problems with adding codesite-noreply@google.com as a discussion list member in my robocode-kks-counterall-discuss group. I still am unsure about how it works.
Wednesday, October 7, 2009
Robocode: Test, test, test
Download: CounterAll + jUnit tests
Improving on my previous robot CounterAll from my previous posts I added 6 new jUnit tests. There are 3 different types of tests: acceptance tests, behavioral tests, and unit tests.
The acceptance tests were the easiest to create because all they tested was whether or not my robot beat another robot. On the other hand, I think behavioral tests were the hardest because most of the time they required the use of other methods and classes from within robocode such as the BattlefieldSpecification class. I also had to refactor my code for my unit test which calculates the power the robot shoots at.
Although it was a pain to change my code in order to better test it, I think it improved my code and helped it follow the rule of having small simple methods.
Although I did create these tests it doesn't mean that my robot is completely of good quality. I did try to write tests that ensured the robot accomplished the behaviors it was intended to do. However, that doesn't mean it will beat every robot. Also if I did not provide varying and a thorough amount of parameters to test for, the test itself wouldn't ensure accuracy.
I also ran Emma to view a coverage report of my tests. I was surprised to see how low the coverage was for the class percentage, only 67%. The method, line, and block coverage were more reassuring with above 80%.
Sunday, September 27, 2009
RoboCode: Tools come in all shapes and sizes
Download: CounterAll
I took the robot from my previous posts and modified it to fix some of the problems I encountered during a RoboCode tournament with my classmates. One problem was that if the match dragged on for a while, my CounterAll robot would run out of energy and become disabled. I addressed this problem by lowering the fire power when its enemy was far away in order to conserve its energy.
In addition to modifying my CounterAll robot, I used the build tool Ant (+Ivy) to build and test my system. I had no major problems using it, although because it was my first time using Ant I had a difficult time understanding and modifying the .xml build files. I used an example project called pmj-dacruzer as a template which made it a lot easier.
I also used 3 quality assurance tools (QA) and received the following results:
FindBugs: 0 warnings
PMD: 0 warnings
CheckStyle: 1 error
There was one CheckStyle error which consisted of a missing package-info.java file. It was fixed by adding the missing file.
I found that automated quality assurance tools are easy to use and catch programming or style errors that you probably would not have found yourself. It is also a great learning tool because it helps me understand what I did wrong and correct those mistakes and therefore become a better programmer.
I took the robot from my previous posts and modified it to fix some of the problems I encountered during a RoboCode tournament with my classmates. One problem was that if the match dragged on for a while, my CounterAll robot would run out of energy and become disabled. I addressed this problem by lowering the fire power when its enemy was far away in order to conserve its energy.
In addition to modifying my CounterAll robot, I used the build tool Ant (+Ivy) to build and test my system. I had no major problems using it, although because it was my first time using Ant I had a difficult time understanding and modifying the .xml build files. I used an example project called pmj-dacruzer as a template which made it a lot easier.
I also used 3 quality assurance tools (QA) and received the following results:
FindBugs: 0 warnings
PMD: 0 warnings
CheckStyle: 1 error
There was one CheckStyle error which consisted of a missing package-info.java file. It was fixed by adding the missing file.
I found that automated quality assurance tools are easy to use and catch programming or style errors that you probably would not have found yourself. It is also a great learning tool because it helps me understand what I did wrong and correct those mistakes and therefore become a better programmer.
Sunday, September 20, 2009
CounterAll, the All-in-One Robot
After creating simple robots and analyzing sample robots it was time to use my newly aquired knowledge to create my all-in-one powerful robot that could defeat the sample robots and hopefully any other opponent it came across.
Download: CounterAll
Movement
My robot uses a similar movement to the sample Walls robot where it moves along the walls with its gun facing inwards. There are some differences however including the direction it moves. The Walls sample robot moves clockwise around the battlefield while my CounterAll robot moves counterclockwise. If it is hit by enemy fire coming from in front or behind the CounterAll robot it will change directions. This is to minimize attacks from its "blind spot" where its gun is not pointed and therefore its radar cannot see.
Tracking
My CounterAll robot does not actively track its enemies. However, when an enemy runs into the CounterAll robot, it will turn to where that opponent is to fire at it.
Firing
The CounterAll robot fires at maximum power when it spots an enemy. It also fires at maximum power when another robot runs into it.
Win
My CounterAll robot can reliably beat the SittingDuck, Corners, Crazy, and Fire sample robots. SittingDuck, Corners, and Fire are easily beaten because they are stationary robots and make easy targets. Crazy may avoid bullets and other robots, but since it focuses mainly on moving it is not much of a threat attack-wise.
Lose
SpinBot and Tracker were two robots that my CounterAll robot had a hard time beating. SpinBot was definately the hardest robot to beat. It is constantly moving and therefore difficult to hit with bullets. It also had more ram points than CounterAll because it was usually closer to the center of the battlefield where there were more robots to ram into. The Tracker robot was difficult to beat because it actively tracked and hunted a robot. It was also a mobile robot which made it difficult to attack.
Draw
Walls and RamFire were considered a draw. If the CounterAll robot battled the Walls robot individually it would reliably beat it. However, when there is a battle that includes other robots as well, CounterAll does not reliably beat Walls. The second case is the RamFire robot. Scorewise, the CounterAll robot can beat RamFire. There is an exception when RamFire can catch up to or corner CounterAll resulting generally in a win for the sample robot.
Lessons Learned
There were certain strategies I learned that were better than others. Robots that were constantly moving made it difficult to shoot at. Therefore, avoidance strategies seemed stronger than attack strategies. When it came to tracking, robots that tried to track their enemies did not do a very good job and had difficulties keeping up with mobile robots. However, not using tracking strategies left firing up to chance that the robot would spot an enemy. I would probably do more testing the next time I did a project like this. Winning against one robot doesn't necessarily mean that it will beat the same robot if there are other robots in the same battle.
Download: CounterAll
Movement
My robot uses a similar movement to the sample Walls robot where it moves along the walls with its gun facing inwards. There are some differences however including the direction it moves. The Walls sample robot moves clockwise around the battlefield while my CounterAll robot moves counterclockwise. If it is hit by enemy fire coming from in front or behind the CounterAll robot it will change directions. This is to minimize attacks from its "blind spot" where its gun is not pointed and therefore its radar cannot see.
/**
* Turns and moves left when hit by enemy fire.
*
* @param event Hit by bullet event set by the game
*/
public void onHitByBullet(HitByBulletEvent event) {
out.println("bearing = " + event.getBearing());
bulletBearing = event.getBearing();
// Only changes direction if the enemy is firing from in front or behind ("blind spots") where
// the gun is not pointed
if ((bulletBearing <= 0 && bulletBearing > -4)
|| (bulletBearing >= -90 && bulletBearing < -86)) {
turnLeft(90);
ahead(moveAmount);
}
}
Tracking
My CounterAll robot does not actively track its enemies. However, when an enemy runs into the CounterAll robot, it will turn to where that opponent is to fire at it.
Firing
The CounterAll robot fires at maximum power when it spots an enemy. It also fires at maximum power when another robot runs into it.
Win
My CounterAll robot can reliably beat the SittingDuck, Corners, Crazy, and Fire sample robots. SittingDuck, Corners, and Fire are easily beaten because they are stationary robots and make easy targets. Crazy may avoid bullets and other robots, but since it focuses mainly on moving it is not much of a threat attack-wise.
Lose
SpinBot and Tracker were two robots that my CounterAll robot had a hard time beating. SpinBot was definately the hardest robot to beat. It is constantly moving and therefore difficult to hit with bullets. It also had more ram points than CounterAll because it was usually closer to the center of the battlefield where there were more robots to ram into. The Tracker robot was difficult to beat because it actively tracked and hunted a robot. It was also a mobile robot which made it difficult to attack.
Draw
Walls and RamFire were considered a draw. If the CounterAll robot battled the Walls robot individually it would reliably beat it. However, when there is a battle that includes other robots as well, CounterAll does not reliably beat Walls. The second case is the RamFire robot. Scorewise, the CounterAll robot can beat RamFire. There is an exception when RamFire can catch up to or corner CounterAll resulting generally in a win for the sample robot.
Lessons Learned
There were certain strategies I learned that were better than others. Robots that were constantly moving made it difficult to shoot at. Therefore, avoidance strategies seemed stronger than attack strategies. When it came to tracking, robots that tried to track their enemies did not do a very good job and had difficulties keeping up with mobile robots. However, not using tracking strategies left firing up to chance that the robot would spot an enemy. I would probably do more testing the next time I did a project like this. Winning against one robot doesn't necessarily mean that it will beat the same robot if there are other robots in the same battle.
Tuesday, September 15, 2009
11. If you can't beat them, join them
What better way to beat the enemy than by using some of their own strategies. I looked at some of the sample robots included in Robocode to see what kind of strategies they use in order to make my robots better. There were three things I looked at in each robot: movement, targeting, and firing.
Walls
Movement: The robot moves along the walls in a clockwise direction and is always facing away from the wall it is moving against. It never stops moving which has shown to be a very effective strategy to avoid enemy robots. However, it can be detrimental if an enemy follows the robot behind it in the same clockwise direction since the robot's gun won't point in that direction. If it hits an enemy it will move away from that robot and therefore has an avoidance strategy.
Targeting: The robot does not track enemies. It fires at an enemy once it spots it but does not continue to track the enemy.
Firing: The robot fires once it spots a robot. The firepower is set to always be 2.
RamFire
Movement: The RamFire robot uses a following strategy. Once the robot has spotted an enemy it moves forward toward that robot to try to ram into it.
Targeting: The RamFire robot spins its whole body around to search for a target. This was one of the least effective ways of searching for a target because it is time consuming. Spinning the gun to search for enemies is better because it does not reduce the movement of the robot and allows for movement and scanning independently.
Firing: The robot only fires once it rams into its enemy. This is not very effective because the only way it can attack an enemy is if it is literally right next to it. It spends most of its time moving towards an enemy instead of firing.
SpinBot
Movement: The SpinBot robot constantly moves in a circle in a clockwise direction. It moves very quickly and follows an avoidance strategy.
Targeting: The robot fires once it spots an enemy. However, it does not actively track the enemy in the sense that it does not rotate its gun to follow the enemy.
Firing: The robot fires at the maximum fire power of 3 no matter how far the enemy is located.
Crazy
Movement: The robot uses an avoidance strategy by moving in a crazy pattern which allows it to effectively avoid enemy robots' fire. It also makes it a very difficult robot to follow because the enemy cannot keep up with its crazy movements. If the robot hits a wall it "bounces" right back and continues moving.
Targeting: The robot does not follow a robot or actively target an enemy. It only fires when it has spotted an enemy.
Firing: The robot fires at a set power of 1 which is very low. This shows that it focuses more on moving and avoiding enemies than attacking.
Fire
Movement: The fire robot does not move unless it is hit by an enemy. This shows an avoidance strategy although it is not very effective because it only takes action after it is too late.
Targeting: The robot turns its gun to the right to scan for enemies. It turns its gun very slowly and continues to do so until it spots an enemy, otherwise it will keep spinning.
Firing: The robot fires at a set power of 3 if it has enough energy and the enemy is near. If not, the robot fires at a power of 1.
Sitting Duck
Movement: The robot does not move, it just sits in one place.
Targeting: The robot does not track or scan for other robots.
Firing: The robot does not fire at any enemy robots which would be difficult to begin with since it does not even search or track for enemies.
Corners
Movement: The robot moves to the wall that is to the right of its desired corner, then turns left and moves to that corner. After it reaches its desired corner it remains there until it dies. Also, once the robot spots an enemy, it immediately stops and fires which can leave itself vulnerable to other enemy robots.
Targeting: Once the robot is in its desired corner it scans for enemy robots and fires once one has been spotted.
Firing: The robot fires at an enemy once it has been spotted using a fire power that is inversely proportional to the distance of the enemy. The further away an enemy is, the less fire power is used. This takes into the account that the further away you are from an enemy, the less likely you will get a hit. Therefore you can conserve your power for opportunities that show more promising results.
Tracker
Movement: The robot only moves once it has spotted an enemy. It moves directly toward the enemy and backs up if it gets to close to the other robot.
Targeting: The tracker robot is of course excellent at tracking enemy robots. Once it has spotted another robot it "locks" onto the target and follows it around.
Firing: If the enemy is within 150 pixels of the tracker robot, the tracker robot will fire at it. The robot fires at a set power of 3.
Walls
Movement: The robot moves along the walls in a clockwise direction and is always facing away from the wall it is moving against. It never stops moving which has shown to be a very effective strategy to avoid enemy robots. However, it can be detrimental if an enemy follows the robot behind it in the same clockwise direction since the robot's gun won't point in that direction. If it hits an enemy it will move away from that robot and therefore has an avoidance strategy.
Targeting: The robot does not track enemies. It fires at an enemy once it spots it but does not continue to track the enemy.
Firing: The robot fires once it spots a robot. The firepower is set to always be 2.
RamFire
Movement: The RamFire robot uses a following strategy. Once the robot has spotted an enemy it moves forward toward that robot to try to ram into it.
Targeting: The RamFire robot spins its whole body around to search for a target. This was one of the least effective ways of searching for a target because it is time consuming. Spinning the gun to search for enemies is better because it does not reduce the movement of the robot and allows for movement and scanning independently.
Firing: The robot only fires once it rams into its enemy. This is not very effective because the only way it can attack an enemy is if it is literally right next to it. It spends most of its time moving towards an enemy instead of firing.
SpinBot
Movement: The SpinBot robot constantly moves in a circle in a clockwise direction. It moves very quickly and follows an avoidance strategy.
Targeting: The robot fires once it spots an enemy. However, it does not actively track the enemy in the sense that it does not rotate its gun to follow the enemy.
Firing: The robot fires at the maximum fire power of 3 no matter how far the enemy is located.
Crazy
Movement: The robot uses an avoidance strategy by moving in a crazy pattern which allows it to effectively avoid enemy robots' fire. It also makes it a very difficult robot to follow because the enemy cannot keep up with its crazy movements. If the robot hits a wall it "bounces" right back and continues moving.
Targeting: The robot does not follow a robot or actively target an enemy. It only fires when it has spotted an enemy.
Firing: The robot fires at a set power of 1 which is very low. This shows that it focuses more on moving and avoiding enemies than attacking.
Fire
Movement: The fire robot does not move unless it is hit by an enemy. This shows an avoidance strategy although it is not very effective because it only takes action after it is too late.
Targeting: The robot turns its gun to the right to scan for enemies. It turns its gun very slowly and continues to do so until it spots an enemy, otherwise it will keep spinning.
Firing: The robot fires at a set power of 3 if it has enough energy and the enemy is near. If not, the robot fires at a power of 1.
Sitting Duck
Movement: The robot does not move, it just sits in one place.
Targeting: The robot does not track or scan for other robots.
Firing: The robot does not fire at any enemy robots which would be difficult to begin with since it does not even search or track for enemies.
Corners
Movement: The robot moves to the wall that is to the right of its desired corner, then turns left and moves to that corner. After it reaches its desired corner it remains there until it dies. Also, once the robot spots an enemy, it immediately stops and fires which can leave itself vulnerable to other enemy robots.
Targeting: Once the robot is in its desired corner it scans for enemy robots and fires once one has been spotted.
Firing: The robot fires at an enemy once it has been spotted using a fire power that is inversely proportional to the distance of the enemy. The further away an enemy is, the less fire power is used. This takes into the account that the further away you are from an enemy, the less likely you will get a hit. Therefore you can conserve your power for opportunities that show more promising results.
Tracker
Movement: The robot only moves once it has spotted an enemy. It moves directly toward the enemy and backs up if it gets to close to the other robot.
Targeting: The tracker robot is of course excellent at tracking enemy robots. Once it has spotted another robot it "locks" onto the target and follows it around.
Firing: If the enemy is within 150 pixels of the tracker robot, the tracker robot will fire at it. The robot fires at a set power of 3.
Monday, September 14, 2009
Robocode 2.0
Rarely is one's code perfect on the first try, if there ever is such a thing as perfect code. There is always room for improvement and as such I revised my Robocode robots in two ways. I edited my code to follow coding standards and I looked at my peers' Robocode to improve my robots.
Coding standards are very important in programming because it creates a consistent environment to work in which in turn improves readability, allowing for easier debugging, maintaining, and extending. If it wasn't for coding standards, programmers would be responsible for coming up with their own "style" and have to figure out others' style. One would get caught up in the little details and waste time that would otherwise be spent on programming.
The coding standards I used for my revised version of Robocode robots include:
One problem I had with coding standards while using others code however, was the first rule in The Elements of Java Style of "Adhere to the style of the original." For my Tracking robots I had modified the sample Tracker robot. I did end up changing some of the documentation for the borrowed code because it did not follow the coding standards I was using even though part of the standards was to adhere to the style of the original. I felt that I was taking a small enough amount of code that I could easily change.
Link to my revised Robocode robots: link
Coding standards are very important in programming because it creates a consistent environment to work in which in turn improves readability, allowing for easier debugging, maintaining, and extending. If it wasn't for coding standards, programmers would be responsible for coming up with their own "style" and have to figure out others' style. One would get caught up in the little details and waste time that would otherwise be spent on programming.
The coding standards I used for my revised version of Robocode robots include:
- The Elements of Java Style
- ICS Coding Standards
- ICS Robocode Standards
One problem I had with coding standards while using others code however, was the first rule in The Elements of Java Style of "Adhere to the style of the original." For my Tracking robots I had modified the sample Tracker robot. I did end up changing some of the documentation for the borrowed code because it did not follow the coding standards I was using even though part of the standards was to adhere to the style of the original. I felt that I was taking a small enough amount of code that I could easily change.
Link to my revised Robocode robots: link
Tuesday, September 8, 2009
Can your code beat a robot?
Robocode is a educational game which helps people practice their programming in Java. Competitors write code that builds robots and then "releases" them into the battlefield to compete against other robots.
I wouldn't say that it "teaches" you to programming in the way that the game itself teaches the language. Instead, it provides a challenging atmosphere that requires people to use their knowledge in programming and encourages the people themselves to improve their coding skills in order to build better robots and win more games. It is definitely more fun to write a program where you can actually see the results, instead of printing things to the console. In addition, the competitiveness of trying to build the best robot makes you want to improve your code.
I created 13 different robots that fell into one of three categories: movement, tracking, or firing. The movement robots had abilities ranging from sitting in one place to moving to the center of the battle field and moving in a circle. The tracking robots ranged from just following a target to following a target and reversing if it got to close to an enemy. Finally, the firing robots ranged from firing when its rotating gun came across an enemy to shooting bullets of size inversely proportional to the distance of the enemy.
All of my robots accomplished most of their tasks, although I would have liked to fix some details on some of my robots. For my Movement05 robot, it is supposed to move to each corner which requires it to move diagonally to get to some corners. However, if you move diagonally to a corner the robot cannot get all the way in the corner because of the size of the robot. The corner of the robot will hit the wall before it reaches the absolute corner. Therefore, if you try to move to an adjacent corner the robot will not be flush up against the wall.
One thing that bothered me about this Movement05 robot is that it was cluttered with trigonometry equations to calculate angles. I decided to put that function into its own method getAngle(). I also would store the heading of the robot into the variable heading everytime I wanted to use it. I removed the variable and just used the getHeading() call whenever I needed it.
Another problem I had was that in Tracking03 which is supposed to find the closest enemy and move in the opposite direction by 100 pixels, then stop. My robot does not stop, it continues to scan and move backwards.
Producing small simple robots like these were the right way to go in that you can focus on perfecting small tasks then adding more complex abilities. If I had tried to make a powerful and complex robot at once it would have been overwhelming. Overall I really enjoyed making these robots and I look forward to making an awesome robot and challenging others with it.
Learn More
Here is a link to my robots: link
Robocode Site
Robocode Wiki
I wouldn't say that it "teaches" you to programming in the way that the game itself teaches the language. Instead, it provides a challenging atmosphere that requires people to use their knowledge in programming and encourages the people themselves to improve their coding skills in order to build better robots and win more games. It is definitely more fun to write a program where you can actually see the results, instead of printing things to the console. In addition, the competitiveness of trying to build the best robot makes you want to improve your code.
I created 13 different robots that fell into one of three categories: movement, tracking, or firing. The movement robots had abilities ranging from sitting in one place to moving to the center of the battle field and moving in a circle. The tracking robots ranged from just following a target to following a target and reversing if it got to close to an enemy. Finally, the firing robots ranged from firing when its rotating gun came across an enemy to shooting bullets of size inversely proportional to the distance of the enemy.
All of my robots accomplished most of their tasks, although I would have liked to fix some details on some of my robots. For my Movement05 robot, it is supposed to move to each corner which requires it to move diagonally to get to some corners. However, if you move diagonally to a corner the robot cannot get all the way in the corner because of the size of the robot. The corner of the robot will hit the wall before it reaches the absolute corner. Therefore, if you try to move to an adjacent corner the robot will not be flush up against the wall.
One thing that bothered me about this Movement05 robot is that it was cluttered with trigonometry equations to calculate angles. I decided to put that function into its own method getAngle(). I also would store the heading of the robot into the variable heading everytime I wanted to use it. I removed the variable and just used the getHeading() call whenever I needed it.
/**
* Computes the angle between the width and hypotenuse of the playing field
* cut diagonally
*
* @param height
* height of the battle field
* @param width
* width of the battle field
* @return angle returns the angle between the width and the hypotenuse in
* degrees
*/
public double getAngle(double height, double width) {
double angle = Math.atan(height / width);
angle = Math.toDegrees(angle);
return angle;
}
Another problem I had was that in Tracking03 which is supposed to find the closest enemy and move in the opposite direction by 100 pixels, then stop. My robot does not stop, it continues to scan and move backwards.
Producing small simple robots like these were the right way to go in that you can focus on perfecting small tasks then adding more complex abilities. If I had tried to make a powerful and complex robot at once it would have been overwhelming. Overall I really enjoyed making these robots and I look forward to making an awesome robot and challenging others with it.
Learn More
Here is a link to my robots: link
Robocode Site
Robocode Wiki
Sunday, August 30, 2009
04. FizzBuzz
The FizzBuzz program took me about 10 minutes to implement. I had actually been given a FizzBuzz assignment at my internship so I already had practice. However, it took me a while to finish because I was trying to write it in a different way. In the end though, this original solution seemed the most logical.
One problem I encountered was syntax errors. I originally wrote this program with a pencil and paper, and thus did not catch some errors. I realized what a difference IDE's such as Eclipse makes.
Even though this seemed like a simple program to write, I learned that software engineering starts at the basics. One must start off knowing the fundamentals and build on that in order to become a better programmer.
One problem I encountered was syntax errors. I originally wrote this program with a pencil and paper, and thus did not catch some errors. I realized what a difference IDE's such as Eclipse makes.
Even though this seemed like a simple program to write, I learned that software engineering starts at the basics. One must start off knowing the fundamentals and build on that in order to become a better programmer.
/**
* FizzBuzz
* Iterates through numbers 1 to 100
* Prints "FizzBuzz" when number is multiple of 3 and 5.
* Prints "Fizz" when number is multiple of 3.
* Prints "Buzz" when number is multiple of 5.
* Prints the number otherwise.
*/
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);
}
}
}
}
02. Stellar + Planetarium = Stellarium
Package: Stellarium for Java
Source: http://sourceforge.net/
Download: http://stellarium4java.
Overview
Stellarium for Java is the Java version of Stellarium, an open source software that uses OpenGL to display 3D skies in real time. It shows things like stars, constellations, and planets.
Prime Directive 1
The functionality that Stellarium for Java provides is the same as Stellarium in that it can render the images in real time. The only difference is that Stellarium for Java uses the Java platform. Stellarium is also being used in planetariums.
Prime Directive 2
Downloading and installing Stellarium for Java was easy even for non-developers of the system like myself. After downloading the package it was easily installed with a single click. There are some requirements before installing the program such as certain versions of Java. However, there are links on the same download page on where to download these requirements.
Prime Directive 3
An external developer can also successfully understand and enhance the system. The source code is provided on the download page and the complete javadocs can be found on the development page.
Subscribe to:
Posts (Atom)