Over the course of this semester, I learned about a lot of new concepts such as continuous integration, issue tracking, and configuration management. The application of these techniques can assist in making development more efficient and productive. These are valuable techniques that can be applied to future projects. I feel that learning these new skills have helped me become a more productive developer and I will try to continue practicing these techniques in the future.
There were also a number of new tools such as CheckStyle, JUnit, PMD, FindBugs, and Ant that were introduced that assist development by automating tasks that would otherwise have to be done by the developer. While these tools cannot guarantee code quality, they allow developers to concentrate on other more important tasks. This allows developers to use their time more productively.
I found the most valuable part of this course to be the experiences that I gained while developing the different projects. Each project taught new skills such as learning about an existing project by reading code. The projects also provided me experience in the development of a system that could be used by consumers. Up to this point, I only had experience developing school-type applications that couldn't be used in the real world. Also, we learned about team management which is useful since, when we get hired, we will most likely be working as part of a team of developers. We had to learn about time management, division of responsibility, and effective communication methods in order to have a successful project. These aspects can be applied to any team project and are critical to the success of the project.
I would like to have learned more about development of web applications. The final project required us to create a web application. The development of the final application was done in just a couple of weeks which didn't give us much time to learn everything. I wish that we had more time to become more proficient with the Wicket Framework, HTML, and CSS because skills with these tools can be applied to many different areas.
Overall, I found this class to be very useful. It taught me many different skills that I am able to take with me and apply in other projects. I think that I have become a more effective developer because of the new techniques and tools that I have learned about.
Wednesday, December 9, 2009
WattWaiter Version 2.1 Release
WattWaiter 2.1 is the second release of the WattWaiter system. Version 2.1 introduced two new pages. A stop light page which provides users a visual representation of the current hour's carbon intensity has been added as well as a grid info page which provides a graphical representation of the carbon intensities of a specified source. By providing this information, WattWaiter hopes to help increase consumers' awareness about when they should plan energy use. Consumers can make informed decisions about scheduling their electricity usage to coincide with low carbon intensity periods.
The stop light page categorizes the current hour's carbon intensity into three categories represented by a green, yellow, or red light for low, moderate, and high carbon intensity respectively. The hours are categorized into colors based on their predicted carbon intensities for that day. The twelve lowest hours are given a green rating, the six next highest hours are given a yellow rating, and the six highest hours are given a red rating. The Wattdepot system is queried at the top of the hour for the current carbon intensity level.
The grid info page provides users with a graphical representation of the carbon intensity over a period of time. A user is able to specify a source, start date, and end date. There are also other options that the user can select such as if they would like to see a cumulative or transitive display, whether they would like to see the carbon or energy generated, and the time frame for the graph. After selecting these options, a user is provided with a line graph that represents the changing carbon intentiy over the specified period of time.
There were many new thing that were learned throughout the course of this project. The Wicket Framework, HTML, and CSS were some of the topics that were new to me. I found that learning to use these new syntaxes was a challenging task. Prior to this project, I had a very limited knowledge of HTML and CSS. It took a while until I got the hang of using their syntax. I also struggled with the Wicket Framework at the start, but it became easier to understand through working with it. There were also team and project management issues that were learned such as getting the whole team involved in development and keeping track of project issues. The Google project issue tracker helped with both of these issues by allowing assignment of tasks to members so everyone knew what they were resonsible for. As in version 1.0, I thought that our team worked well together. We didn't have to make many adjustments to the way our group was functioning. We helped one another when we got stuck, so we could keep progress moving forward. Overall, I found this experience to be a positive one.
The WattWaiter project page, where users are able to download the WattWaiter 2.1 system, can be found here. There is also additional information such as a user guide, developer guide, and release notes that can be viewed. A screenshot of WattWaiter 2.1 is shown below.
The stop light page categorizes the current hour's carbon intensity into three categories represented by a green, yellow, or red light for low, moderate, and high carbon intensity respectively. The hours are categorized into colors based on their predicted carbon intensities for that day. The twelve lowest hours are given a green rating, the six next highest hours are given a yellow rating, and the six highest hours are given a red rating. The Wattdepot system is queried at the top of the hour for the current carbon intensity level.
The grid info page provides users with a graphical representation of the carbon intensity over a period of time. A user is able to specify a source, start date, and end date. There are also other options that the user can select such as if they would like to see a cumulative or transitive display, whether they would like to see the carbon or energy generated, and the time frame for the graph. After selecting these options, a user is provided with a line graph that represents the changing carbon intentiy over the specified period of time.
There were many new thing that were learned throughout the course of this project. The Wicket Framework, HTML, and CSS were some of the topics that were new to me. I found that learning to use these new syntaxes was a challenging task. Prior to this project, I had a very limited knowledge of HTML and CSS. It took a while until I got the hang of using their syntax. I also struggled with the Wicket Framework at the start, but it became easier to understand through working with it. There were also team and project management issues that were learned such as getting the whole team involved in development and keeping track of project issues. The Google project issue tracker helped with both of these issues by allowing assignment of tasks to members so everyone knew what they were resonsible for. As in version 1.0, I thought that our team worked well together. We didn't have to make many adjustments to the way our group was functioning. We helped one another when we got stuck, so we could keep progress moving forward. Overall, I found this experience to be a positive one.
The WattWaiter project page, where users are able to download the WattWaiter 2.1 system, can be found here. There is also additional information such as a user guide, developer guide, and release notes that can be viewed. A screenshot of WattWaiter 2.1 is shown below.
Tuesday, November 24, 2009
Ecologineers Review
The Ecologineers system provides a web application for users to query the Wattdepot database for carbon intensity readings. Readings for each hour are returned with a rating of red, yellow, or green assigned. Based on these readings, users are able to make decisions regarding their electrical usage. My job was to perform a review of the Ecologineers system. My full review of the system can be found here.
I found that the overall functionality of the system was good. The system met the functional specifications. It returns the reading and rating of a specified day's carbon intensity in hourly increments. A UserGuide, DeveloperGuide, and ReleaseNotes were provided on the project website. The design and implementation is good, however, the visual aspect of the web application could be improved. A more visually appealing user interface could be implemented which would greatly improve the web interface. There were a few bugs in the system such as entering a year that is far in the past or a year in the future. The testing implemented seems to only check "happy paths". Adding tests that check bad input and the functionality of the web application would further ensure the quality of the system. The Ecologineers team did a good job of not letting the system stay in a failed state for a long period of time. The "health" of the system was moderate. The group seems to be functioning ok, however, it may benefit from starting earlier on the development of the project. This could help improve the project's "health" by raising the churn and commit statistics.
I found that the overall functionality of the system was good. The system met the functional specifications. It returns the reading and rating of a specified day's carbon intensity in hourly increments. A UserGuide, DeveloperGuide, and ReleaseNotes were provided on the project website. The design and implementation is good, however, the visual aspect of the web application could be improved. A more visually appealing user interface could be implemented which would greatly improve the web interface. There were a few bugs in the system such as entering a year that is far in the past or a year in the future. The testing implemented seems to only check "happy paths". Adding tests that check bad input and the functionality of the web application would further ensure the quality of the system. The Ecologineers team did a good job of not letting the system stay in a failed state for a long period of time. The "health" of the system was moderate. The group seems to be functioning ok, however, it may benefit from starting earlier on the development of the project. This could help improve the project's "health" by raising the churn and commit statistics.
Sunday, November 22, 2009
Wattwaiter 1.0
Wattwaiter is a web application that allows users to query the Wattdepot database to determine carbon intensities for a given day. By obtaining this information, consumers are able to make educated decisions about electrical usage. Wattwaiter provides a visual breakdown of the carbon intensities by hour. Colored flags are assigned to each hour to indicate the intensity. The flags are colored green, yellow, and red which correspond to low, moderate, and high carbon intensities respectively. We hope by providing this information to consumers, they are able to adjust their electrical usage and become "smart" consumers.
Using Wicket was difficult for me because I don't have much experience in creating web applications. Luckily, other members in my group were more experienced and able to help me understand how it works when I got stuck. Wicket in Action was a good resource that explained how to accomplish basic tasks using Wicket. Also, I found the Wicket examples to be very useful. They allowed me to view working code that demonstrated how to create different components. I also had to familiarize myself with HTML. Now, I have a basic understanding of HTML and Wicket that I hope will grow as the project progresses. Overall, I felt that the project went well.
I feel that the design of our system was good. We were able to accomplish the goals of the application without making use complicated. It is simple for users to query different dates and interpret the data that is returned. This is an important aspect of the project, so users will not feel it is a hassle to use.
I feel that our group worked well together. We all contributed to the design and implementation of the project. Having several different perspectives helped to improve the design of the system by considering different approaches. Also, our communication was good which helped everyone stay on-track.
Shown below is a screenshot of our software ICU from Hackystat. By observing the metrics, it can be seen that there is room for improvement. The areas that need improvement are churn and testing. We will put more focus on these aspects during the cycle of the project.
Below is a link to our project website where guides on Wattwaiter and a distribution of the system can be found.
Wattwaiter 1.0
Using Wicket was difficult for me because I don't have much experience in creating web applications. Luckily, other members in my group were more experienced and able to help me understand how it works when I got stuck. Wicket in Action was a good resource that explained how to accomplish basic tasks using Wicket. Also, I found the Wicket examples to be very useful. They allowed me to view working code that demonstrated how to create different components. I also had to familiarize myself with HTML. Now, I have a basic understanding of HTML and Wicket that I hope will grow as the project progresses. Overall, I felt that the project went well.
I feel that the design of our system was good. We were able to accomplish the goals of the application without making use complicated. It is simple for users to query different dates and interpret the data that is returned. This is an important aspect of the project, so users will not feel it is a hassle to use.
I feel that our group worked well together. We all contributed to the design and implementation of the project. Having several different perspectives helped to improve the design of the system by considering different approaches. Also, our communication was good which helped everyone stay on-track.
Shown below is a screenshot of our software ICU from Hackystat. By observing the metrics, it can be seen that there is room for improvement. The areas that need improvement are churn and testing. We will put more focus on these aspects during the cycle of the project.
Below is a link to our project website where guides on Wattwaiter and a distribution of the system can be found.
Wattwaiter 1.0
Sunday, November 15, 2009
Wattdepot Version 2.0
The goal of the Wattdepot-CLI project was to create a command line interface that could access Wattdepot and return useful information to users. This information could then be used to improve electricity usage of consumers.
Wattdepot 2.0 is the second release of our command line interface. Wattdepot Version 2.0 features 3 new commands in addition to the previous commands that were originally released. Our initial version used the correct structure for the program which made creation of Version 2.0 much easier. The most commonly observed weakness of our original program was insufficient Javadocs. In Version 2.0, we improved the Javadocs in order to make the API easier for other developers to understand. The testing that was implemented for each command verified not only happy paths, but also covered input validation and exception checking. Our coverage was decent at 82%, however, there is still much room for improvement.
In order for this project to be successful, it took teamwork and dedication. We met in person as often as possible and regularly on IRC to discuss progress of the project as well as issues that arose. We divided the work evenly between the group members which ensured that each member was participating. I felt that all members of the group carried their weight. Each member's work was critical in the success of this project.
Hackystat is a software ICU which tracks the statistics of your project in order to ensure that you stay on track. It provides information dealing with the automated quality assurance tools we have been using as well as ANT and Eclipse. Hackystat also provides a visual summary of the projects "health". At a glance, developers are able to see the "health" of their project in order to keep a project's progress in the right direction. By looking at our Hackystat metrics, our project's "health" was decent, but our testing statistic could use some improvement. Our project's Hackystat chart is shown below. Click on the image for an enlarged view.
Below are the results to some queries that were executed using our Wattdepot-CLI.
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW
What day during the month did Oahu consume the most energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu consume the least energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
On November 4, 5, 16, 17, and 30, 29,959 lbs of carbon were emitted.
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
On November 7 and 8, 22,908 lbs of carbon were emitted.
Wattdepot 2.0 is the second release of our command line interface. Wattdepot Version 2.0 features 3 new commands in addition to the previous commands that were originally released. Our initial version used the correct structure for the program which made creation of Version 2.0 much easier. The most commonly observed weakness of our original program was insufficient Javadocs. In Version 2.0, we improved the Javadocs in order to make the API easier for other developers to understand. The testing that was implemented for each command verified not only happy paths, but also covered input validation and exception checking. Our coverage was decent at 82%, however, there is still much room for improvement.
In order for this project to be successful, it took teamwork and dedication. We met in person as often as possible and regularly on IRC to discuss progress of the project as well as issues that arose. We divided the work evenly between the group members which ensured that each member was participating. I felt that all members of the group carried their weight. Each member's work was critical in the success of this project.
Hackystat is a software ICU which tracks the statistics of your project in order to ensure that you stay on track. It provides information dealing with the automated quality assurance tools we have been using as well as ANT and Eclipse. Hackystat also provides a visual summary of the projects "health". At a glance, developers are able to see the "health" of their project in order to keep a project's progress in the right direction. By looking at our Hackystat metrics, our project's "health" was decent, but our testing statistic could use some improvement. Our project's Hackystat chart is shown below. Click on the image for an enlarged view.
Below are the results to some queries that were executed using our Wattdepot-CLI.
What day and time during the month was Oahu energy usage at its highest? How many MW was this?
November 2-6, 9-13, 16-20, and 23-27 all had a usage of 995MW
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
November 2-6, 9-13, 16-20, 23-27 all had a usage of 493MW
What day during the month did Oahu consume the most energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu consume the least energy? How many MWh was this?
There was no data found for this.
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
On November 4, 5, 16, 17, and 30, 29,959 lbs of carbon were emitted.
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
On November 7 and 8, 22,908 lbs of carbon were emitted.
Tuesday, November 10, 2009
Software Review Experiences
Peer reviewing is a process where other developers review your code and provide comments about good and bad things that they find. Performing these reviews is not only beneficial to the project that you are reviewing, but also to yourself. Peer reviews are a great way to help other developers improve their code while improving your own skills at the same time.
While performing reviews, we are able to practice our code reading and understanding skills. These are important skills to have as many large projects require working with other developers. Being able to read and understand other's code makes you a valuable team member because you are able to help others when they run into problems. I was also able to view weak points in other programs. By taking note of areas that other projects need to improve, I was able to see areas in my own project that could use improvement.
There are many ways to write code to accomplish a certain task. Everyone's mind works differently, so people usually go about doing things in different ways. It is useful to observe how other people solve a problem as it is difficult for one person to think of all solutions. By reviewing other developer's code, we are able to learn new techniques that we can add to our own arsenal. This helps us to continually grow as programmers. While performing the reviews, I saw different ways of solving problems which made me re-think my solution. I think that a best solution is often produced by combining the good parts of many different solutions.
I was able to learn a lot by reading comments about our project. The information provided was very useful. Reviewers were able to find flaws in the program that we were unable to find during our own code review. We were also able to get feedback about which parts of our program were difficult to understand. The ability of other developers to understand your code is as important as the functionality of the code itself. By fixing these issues, we will improve the quality of our program and take one step closer to accomplishing Prime Directive Number 3 (an external developer can successfully understand and enhance the system).
I found peer reviews to be a very useful tool. It provided insight into other's code as well as my own. Performing reviews is great for learning new ways of accomplishing tasks while helping out fellow developers. Reading other's reviews of your code can give you insight into what other people see when they look at your code. If we let it, the information provided can show us different views which can help us improve our skills. In order to continue to grow as programmers, we must have an open mind.
While performing reviews, we are able to practice our code reading and understanding skills. These are important skills to have as many large projects require working with other developers. Being able to read and understand other's code makes you a valuable team member because you are able to help others when they run into problems. I was also able to view weak points in other programs. By taking note of areas that other projects need to improve, I was able to see areas in my own project that could use improvement.
There are many ways to write code to accomplish a certain task. Everyone's mind works differently, so people usually go about doing things in different ways. It is useful to observe how other people solve a problem as it is difficult for one person to think of all solutions. By reviewing other developer's code, we are able to learn new techniques that we can add to our own arsenal. This helps us to continually grow as programmers. While performing the reviews, I saw different ways of solving problems which made me re-think my solution. I think that a best solution is often produced by combining the good parts of many different solutions.
I was able to learn a lot by reading comments about our project. The information provided was very useful. Reviewers were able to find flaws in the program that we were unable to find during our own code review. We were also able to get feedback about which parts of our program were difficult to understand. The ability of other developers to understand your code is as important as the functionality of the code itself. By fixing these issues, we will improve the quality of our program and take one step closer to accomplishing Prime Directive Number 3 (an external developer can successfully understand and enhance the system).
I found peer reviews to be a very useful tool. It provided insight into other's code as well as my own. Performing reviews is great for learning new ways of accomplishing tasks while helping out fellow developers. Reading other's reviews of your code can give you insight into what other people see when they look at your code. If we let it, the information provided can show us different views which can help us improve our skills. In order to continue to grow as programmers, we must have an open mind.
Sunday, November 8, 2009
Wattdepot-CLI Review
After creating our Wattdepot-CLI, we were tasked to perform reviews of two other groups projects. The criteria for the reviews were provided and can be found here. The two projects that I reviewed were for Eiwa and Umi.
Eiwa - The project was able to be built successfully and all the commands were functional. Some changes may need to be made to either the help menu or the command names as they do not match. Different classes were created for each of the different commands. The JUnit tests implemented were good, however, additional testing needs to be implemented for the remaining untested methods. Some reorganization may need to be done. The full report for this project can be found here.
Umi - The project was able to be built successfully and all the commands were functional. Reorganization of the commands should probably be done, so multiple commands are not implemeted in a single class. Also, this project may want to seperate the command line interface and the commands into seperate packages. More test cases need to be generated to provide sufficient checks of functionality. The full report for this project can be found here.
Eiwa - The project was able to be built successfully and all the commands were functional. Some changes may need to be made to either the help menu or the command names as they do not match. Different classes were created for each of the different commands. The JUnit tests implemented were good, however, additional testing needs to be implemented for the remaining untested methods. Some reorganization may need to be done. The full report for this project can be found here.
Umi - The project was able to be built successfully and all the commands were functional. Reorganization of the commands should probably be done, so multiple commands are not implemeted in a single class. Also, this project may want to seperate the command line interface and the commands into seperate packages. More test cases need to be generated to provide sufficient checks of functionality. The full report for this project can be found here.
Tuesday, November 3, 2009
Watt Depot CLI
Watt depot is a service that collects and stores electricity data. Tools can then retrieve the data and analyze it for consumers. Consumers are able to use this data to become smart consumers. By observing data trends, consumers can adjust their usage. By knowing when off-peak demand times are, consumers are able to use electricity during lower demand periods to lower their electricity bill. This also benefits the electric company by reducing demand.
Developing a Watt-Depot-CLI was a challenging task. There were several different commands that needed to be implemented. The commands can be seen here. Learning the Watt Depot API to complete the CLI was a task in itself. There were many different methods that we needed to understand in order to implement the commands correctly. At first, progress was slow while as we were still getting accustomed on how to accomplish certain tasks using Watt Depot. As we got more experience working with Watt Depot classes and methods, it became easier and we increased our productivity. We were able to successfully implement all the commands.
Testing was a large part of this project. In order to ensure that our commands were implemented correctly, we created JUnit tests to validate inputs and outputs. These tests are particularly useful during development to ensure that previously written code continues to work correctly.
This was our first project that required working with a partner. This was much different than working alone. In order to have a successful project, you must designate work and ensure that you understand each other's code. Luckily, communication was not a problem for our team. We were able to coordinate meeting times to discuss the project as well as communicate through IM. I felt that this was a crucial factor in the success of our project. It allowed us to discuss issues that came up and brainstorm feasible solutions. Without good communication, our progress would have been much slower and our product would not have been as good.
We split the project up fairly evenly. Each of us developed code to implement the commands as well as tests to verify their functionality. Although the work was divided, we ensured everyone knew the status of the project by committing frequently. This not only allowed us to follow each other's progress, but also help each other when issues arose. This strategy worked out well for us. We continually had forward progress and when a roadblock was hit, we had someone to turn to for help.
Through this project, I was able to learn not only about coding, but also teamwork and time management. Teamwork was a critical part of this project as we were dependent on each other in order to complete the project successfully. Time management was crucial to allow us to work at a lower stress level. I found that by working hard at the start of the project, we were able to make changes to our design without much stress. Although I still have a lot to learn, knowing some of the skills that are needed in future development projects will be very beneficial.
Developing a Watt-Depot-CLI was a challenging task. There were several different commands that needed to be implemented. The commands can be seen here. Learning the Watt Depot API to complete the CLI was a task in itself. There were many different methods that we needed to understand in order to implement the commands correctly. At first, progress was slow while as we were still getting accustomed on how to accomplish certain tasks using Watt Depot. As we got more experience working with Watt Depot classes and methods, it became easier and we increased our productivity. We were able to successfully implement all the commands.
Testing was a large part of this project. In order to ensure that our commands were implemented correctly, we created JUnit tests to validate inputs and outputs. These tests are particularly useful during development to ensure that previously written code continues to work correctly.
This was our first project that required working with a partner. This was much different than working alone. In order to have a successful project, you must designate work and ensure that you understand each other's code. Luckily, communication was not a problem for our team. We were able to coordinate meeting times to discuss the project as well as communicate through IM. I felt that this was a crucial factor in the success of our project. It allowed us to discuss issues that came up and brainstorm feasible solutions. Without good communication, our progress would have been much slower and our product would not have been as good.
We split the project up fairly evenly. Each of us developed code to implement the commands as well as tests to verify their functionality. Although the work was divided, we ensured everyone knew the status of the project by committing frequently. This not only allowed us to follow each other's progress, but also help each other when issues arose. This strategy worked out well for us. We continually had forward progress and when a roadblock was hit, we had someone to turn to for help.
Through this project, I was able to learn not only about coding, but also teamwork and time management. Teamwork was a critical part of this project as we were dependent on each other in order to complete the project successfully. Time management was crucial to allow us to work at a lower stress level. I found that by working hard at the start of the project, we were able to make changes to our design without much stress. Although I still have a lot to learn, knowing some of the skills that are needed in future development projects will be very beneficial.
Sunday, November 1, 2009
Hudson the Watchdog
Continuous integration is a software development practice where members of a development team integrate their work frequently. Work is integrated at least once daily. Then, an automated build tool is used to verify the integration. This detects any errors/problems with the build quickly. By integrating frequently, it allows software to be developed faster with less integration problems.
Hudson was used as the automated build tool for our watt-depot-cli project. Hudson was configured to use SVN to poll for changes made to the project repository. If changes are detected, it does an automated build of the project to ensure that it is working correctly. It also sends out email notifications if a build fails. This allows developers to be aware that something is not working correctly and that it needs to be fixed. This is good so that files with errors in them are not downloaded by other team members. Sometimes, a developer may forget to verify a build before committing to the project. Hudson prevents a broken build from going unnoticed for long periods of time.
I was able to see the benefit of continuous integration with my project by observing what happens when conflicts occur. When there are conflicts, the amount of code affected is usually minimal because the differences between files are minimal. This makes conflicts much faster and easier to resolve. The longer you wait to integrate, the more differences there may be which can make resolving conflicts a long and painful task.
One bad thing about continuous integration is that sometimes it gives a false sense of how a project is progressing. Sometimes our team was working on developing a new feature for the project and wanted to help each other fix problems with the code. We uploaded the code through SVN, knowing that there were problems with the code that we were working to resolve. A failed automated build was performed and logged on the Hudson server. This added to our cumulative build count which made it appear as though our project was having issues by the storm clouds that appeared next to our project. An outsider looking at the statistics may conclude that we are having problems with our project even though this was not the case.
Overall, I found continuous integration to be a useful practice when working with a development team. It makes integrating changes much quicker and easier. I also found that the automated notifications that Hudson sent to be useful. This is a very useful technique that I can see benefitting many future projects.
Hudson was used as the automated build tool for our watt-depot-cli project. Hudson was configured to use SVN to poll for changes made to the project repository. If changes are detected, it does an automated build of the project to ensure that it is working correctly. It also sends out email notifications if a build fails. This allows developers to be aware that something is not working correctly and that it needs to be fixed. This is good so that files with errors in them are not downloaded by other team members. Sometimes, a developer may forget to verify a build before committing to the project. Hudson prevents a broken build from going unnoticed for long periods of time.
I was able to see the benefit of continuous integration with my project by observing what happens when conflicts occur. When there are conflicts, the amount of code affected is usually minimal because the differences between files are minimal. This makes conflicts much faster and easier to resolve. The longer you wait to integrate, the more differences there may be which can make resolving conflicts a long and painful task.
One bad thing about continuous integration is that sometimes it gives a false sense of how a project is progressing. Sometimes our team was working on developing a new feature for the project and wanted to help each other fix problems with the code. We uploaded the code through SVN, knowing that there were problems with the code that we were working to resolve. A failed automated build was performed and logged on the Hudson server. This added to our cumulative build count which made it appear as though our project was having issues by the storm clouds that appeared next to our project. An outsider looking at the statistics may conclude that we are having problems with our project even though this was not the case.
Overall, I found continuous integration to be a useful practice when working with a development team. It makes integrating changes much quicker and easier. I also found that the automated notifications that Hudson sent to be useful. This is a very useful technique that I can see benefitting many future projects.
Sunday, October 18, 2009
Midterm Questions
1. What is the difference between locking and non-locking when talking about version control?
Locking only allows one person to check out a file and work on it. Non-locking allows multiple developers to check out the same file and make changes.
2. Name one advantage of non-locking over locking.
The problem of a user taking out a lock and forgetting to return the file by unlocking it is eliminated.
3. What is the difference between white box and black box testing?
In white box testing, a tester uses an internal perspective of a system to develop test cases based on the internal structure. In black box testing, a tester only has an external perspective of a system and chooses valid/invalid inputs and ensures the correct output is returned.
4. What is the difference between the Codeline policy of an Active Development Line and a Release Line?
For an Active Development Line, progress is slightly favored over stability. For a Release Line, stability is favored over progress.
5. List two distribution terms that Open Source software must comply with. Provide a brief explanation of each.
Free Redistribution - The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
Derived Works - The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
6. Explain one reason that Open Source software has been successful and popular with developers.
Community - Having a common source code pool and the tools provided by the Internet creates an opportunity for extensive and speedy collaboration on development projects.
7. What is wrong with the following statement?
import java.util.*;
Using the “*” in an import statement is a violation of coding standards. You should explicitly import each class that you use from other packages because it is an important form of documentation for those reading your code.
8. List at least two things you should do before asking a technical question by email, newsgroup, or website chat board.
1) Try to find an answer by searching the Web.
2) Try to find an answer by reading the manual.
9. Does a high percentage in a coverage report ensure the quality of your code? Explain your answer.
No, a high percentage in a coverage report can expose code that has not been adequately tested, but it cannot guarantee the quality of your code. You need to ensure that your tests are thorough and adequate enough to ensure the quality of your code.
10. Why is it important to get developer buy-in when implementing coding standards?
It is important to get developers to buy-in when implementing coding standards so they understand the importance of the standards and are more likely to follow them. Providing the reasoning behind each rule can encourage adoption of the rules.
Locking only allows one person to check out a file and work on it. Non-locking allows multiple developers to check out the same file and make changes.
2. Name one advantage of non-locking over locking.
The problem of a user taking out a lock and forgetting to return the file by unlocking it is eliminated.
3. What is the difference between white box and black box testing?
In white box testing, a tester uses an internal perspective of a system to develop test cases based on the internal structure. In black box testing, a tester only has an external perspective of a system and chooses valid/invalid inputs and ensures the correct output is returned.
4. What is the difference between the Codeline policy of an Active Development Line and a Release Line?
For an Active Development Line, progress is slightly favored over stability. For a Release Line, stability is favored over progress.
5. List two distribution terms that Open Source software must comply with. Provide a brief explanation of each.
Free Redistribution - The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
Derived Works - The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
6. Explain one reason that Open Source software has been successful and popular with developers.
Community - Having a common source code pool and the tools provided by the Internet creates an opportunity for extensive and speedy collaboration on development projects.
7. What is wrong with the following statement?
import java.util.*;
Using the “*” in an import statement is a violation of coding standards. You should explicitly import each class that you use from other packages because it is an important form of documentation for those reading your code.
8. List at least two things you should do before asking a technical question by email, newsgroup, or website chat board.
1) Try to find an answer by searching the Web.
2) Try to find an answer by reading the manual.
9. Does a high percentage in a coverage report ensure the quality of your code? Explain your answer.
No, a high percentage in a coverage report can expose code that has not been adequately tested, but it cannot guarantee the quality of your code. You need to ensure that your tests are thorough and adequate enough to ensure the quality of your code.
10. Why is it important to get developer buy-in when implementing coding standards?
It is important to get developers to buy-in when implementing coding standards so they understand the importance of the standards and are more likely to follow them. Providing the reasoning behind each rule can encourage adoption of the rules.
Thursday, October 15, 2009
Collaboration through SVN
Subversion or SVN is a version control system that is used when there are multiple developers that may be working on a project at the same time. This software ensures that everyone is working on the latest version of the project. Also, SVN is very useful when multiple developers are working on the same project because it can ensure that different developer's changes don't overwrite each other. SVN is non-locking which means that two developers can work on the same files at the same time. The files are checked for conflicts when they are committed. If any conflicts occur, the developer who is trying to commit is notified that they must update their files and resolve any conflicts before committing.
I was able to host my Robocode project on Google Project Hosting and create a discussion group for it. I found that setting up the automatic commit and issue messages to be difficult. At first, I could not get automatic commit and issue messages to be sent when changes were made to the project files. I added the group email address for the discussion site, robocode-kkc-diamondbot-discuss@googlegroups.com, to receive activity notifications. I finally got it to work after setting robocode-kkc-diamondbot@googlecode.com to be the sender.
I learned that using Google Project Hosting and SVN is a good way that multiple developers can collaborate on a project. It is vital to have version control when working with multiple developers to ensure that progress keeps moving forward. Attempting to accomplish this manually would be an extremely tedious and time comsuming task. Thankfully, there is version control software like SVN that can automate the process.
I was able to host my Robocode project on Google Project Hosting and create a discussion group for it. I found that setting up the automatic commit and issue messages to be difficult. At first, I could not get automatic commit and issue messages to be sent when changes were made to the project files. I added the group email address for the discussion site, robocode-kkc-diamondbot-discuss@googlegroups.com, to receive activity notifications. I finally got it to work after setting robocode-kkc-diamondbot@googlecode.com to be the sender.
I learned that using Google Project Hosting and SVN is a good way that multiple developers can collaborate on a project. It is vital to have version control when working with multiple developers to ensure that progress keeps moving forward. Attempting to accomplish this manually would be an extremely tedious and time comsuming task. Thankfully, there is version control software like SVN that can automate the process.
Monday, October 5, 2009
Passing the Test
Automated testing is an efficient way to ensure that as you develop a program it still works correctly and as expected. This approach is much more time efficient than entering test cases manually. As you add new functions to your program, it is important to ensure previous capabilities are not affected. JUnit is an automated Java testing program that allows a developer to create custom tests to verify functionality and performance.
As I developed my Robocode robot, it was important to ensure that changes I made while adding new features did not result in a loss of previous performance. I could have manually run Robocode each time I made a change, however, this approach is time consuming and takes away effort that should be put towards improving my robot's performance. JUnit allowed me to create tests that could be run in a fraction of the time it would take me to accomplish manually.
The three types of JUnit tests that were created that were acceptance, behavioral, and unit tests. Acceptance tests verify that a robot can consistently defeat another robot. Behavioral tests check that a robot correctly implements a movement, firing, or targeting strategy. Unit tests verify that individual methods correctly calculate an output for specified inputs. These tests can provide a developer a reasonable performance measurement. While this does not test for all situations, it can cover a substantial portion of your code to ensure that it is working as expected.
The simplest tests to create were the acceptance tests where a robot is matched against another robot to verify that it can consistently defeat it. I chose to battle my robot against RamFire and Crazy and check that it was able to win more than fifty percent of the time. The behavioral test was more difficult to create. There was much more information that was required to be gathered to validate that a strategy was being implemented. I decided to test my movement strategy. I ran into problems getting my behavioral tests to work correctly. Eventually, I was able to get this test to work. The unit tests that were created verified the output of three methods. One calculated a distance that was required, another calculated an angle, and the last calulated how many degrees the robot needed to be turned to face the next position.
Now that I have some experience in writing JUnit tests, I would develop my robot to have smaller methods. I found that I was doing too much in one method, which made it difficult to write tests for. I had to break down my methods without altering the behavior of my robot to be more specific to accommodate testing. After modifying my robot, determining how to perform unit tests became much simpler.
I felt that these tests adequately tested my robot since the program was rather short. If this had been a larger project, I would have had to write more tests in order to increase the coverage provided by the tests. Listed below are the results from running Emma.
Overall coverage Summary:
Class Percentage = 89%
Method Percentage = 80%
Block Percentage = 55%
Line Percentage = 56%
Even though I ran into some issues while developing my tests, I was able to see the value in creating automated tests. After the tests were created, I was able to run them over and over without much time and effort. The ability to create automated tests is an essential skill to have and is particularly valuable when developing a large project.
A distribution of my robot including JUnit tests can be found here.
As I developed my Robocode robot, it was important to ensure that changes I made while adding new features did not result in a loss of previous performance. I could have manually run Robocode each time I made a change, however, this approach is time consuming and takes away effort that should be put towards improving my robot's performance. JUnit allowed me to create tests that could be run in a fraction of the time it would take me to accomplish manually.
The three types of JUnit tests that were created that were acceptance, behavioral, and unit tests. Acceptance tests verify that a robot can consistently defeat another robot. Behavioral tests check that a robot correctly implements a movement, firing, or targeting strategy. Unit tests verify that individual methods correctly calculate an output for specified inputs. These tests can provide a developer a reasonable performance measurement. While this does not test for all situations, it can cover a substantial portion of your code to ensure that it is working as expected.
The simplest tests to create were the acceptance tests where a robot is matched against another robot to verify that it can consistently defeat it. I chose to battle my robot against RamFire and Crazy and check that it was able to win more than fifty percent of the time. The behavioral test was more difficult to create. There was much more information that was required to be gathered to validate that a strategy was being implemented. I decided to test my movement strategy. I ran into problems getting my behavioral tests to work correctly. Eventually, I was able to get this test to work. The unit tests that were created verified the output of three methods. One calculated a distance that was required, another calculated an angle, and the last calulated how many degrees the robot needed to be turned to face the next position.
Now that I have some experience in writing JUnit tests, I would develop my robot to have smaller methods. I found that I was doing too much in one method, which made it difficult to write tests for. I had to break down my methods without altering the behavior of my robot to be more specific to accommodate testing. After modifying my robot, determining how to perform unit tests became much simpler.
I felt that these tests adequately tested my robot since the program was rather short. If this had been a larger project, I would have had to write more tests in order to increase the coverage provided by the tests. Listed below are the results from running Emma.
Overall coverage Summary:
Class Percentage = 89%
Method Percentage = 80%
Block Percentage = 55%
Line Percentage = 56%
Even though I ran into some issues while developing my tests, I was able to see the value in creating automated tests. After the tests were created, I was able to run them over and over without much time and effort. The ability to create automated tests is an essential skill to have and is particularly valuable when developing a large project.
A distribution of my robot including JUnit tests can be found here.
Tuesday, September 29, 2009
Build Systems
Build systems are tools that can be used to automatically build your programs and perform automated quality assurance. They can be customized to perform many automated checks such as ensuring correct versions of software and necessary packages are installed. They are very flexible and users can customize them to meet the requirements of their project.
Ant and Ivy are good because they ensure that all users' and developers' systems are setup correctly before a program is executed. They can automatically download and install necessary software if they are missing. Also, build systems can inform users of problems such as incorrect software versions which may pose potential problems. They allow for cross-platform usage. Tedious tasks such as ensuring correct syntax is used when specifying paths are automatically handled by the build system.
Tools used for automated quality assurance such as Checkstyle, PMD, FindBugs, and JUnit can be applied to projects. Manually checking coding standards and best practices can be a very tedious and time-consuming task. Thankfully, these tools can automate the process and allow developers to concentrate on more important tasks. Although they cannot replace code reviews, they can ensure that formatting issues and coding standards are followed.
Checkstyle can help ensure that coding standards and best practices are followed. It checks the Java source code for things such as comments, naming conventions, and indentions.
PMD also provides assurance that best practices are followed. It can also find sub-optimal code and potential bugs. Like Checkstyle, it analyzes the Java source code.
FindBugs is a tool that differs from Checkstyle and PMD in that it analyzes Java bytecode. It searches for potential bugs that can break your program. This program searches for strings of bytecode that are known to potentially cause serious problems.
These tools can be incorporated into an IDE such as Eclipse to allow for feedback as the program is being developed. They will also create a HTML report containing descriptions of each problem found and their location.
JUnit allows developers to create simple tests to ensure that software is working correctly. Automated testing such as that provided by JUnit can save time and effort. It provides the developer some assurance that the program is functional without manually entering different test cases.
I found these tools to be very useful. They were able to find problems with my code much quicker than I would have been able to. They found two problems with my code. Checkstyle reported a problem with a condition in an IF statement I had declared. It reported that the expression (move == true) could be simplified. PMD reported a best practices violation in which I had variables that could be declared as local variables. After fixing these problems, I was able to successfully build my project.
I made some improvements to my Robocode robot based on observations made during the first robot battle. I restricted the range that my robot fires in order to save energy. I also attempted to adjust my firing to account for the many Walls style robots that were in the first tournament.
A developer distribution of my system can be found here.
Ant and Ivy are good because they ensure that all users' and developers' systems are setup correctly before a program is executed. They can automatically download and install necessary software if they are missing. Also, build systems can inform users of problems such as incorrect software versions which may pose potential problems. They allow for cross-platform usage. Tedious tasks such as ensuring correct syntax is used when specifying paths are automatically handled by the build system.
Tools used for automated quality assurance such as Checkstyle, PMD, FindBugs, and JUnit can be applied to projects. Manually checking coding standards and best practices can be a very tedious and time-consuming task. Thankfully, these tools can automate the process and allow developers to concentrate on more important tasks. Although they cannot replace code reviews, they can ensure that formatting issues and coding standards are followed.
Checkstyle can help ensure that coding standards and best practices are followed. It checks the Java source code for things such as comments, naming conventions, and indentions.
PMD also provides assurance that best practices are followed. It can also find sub-optimal code and potential bugs. Like Checkstyle, it analyzes the Java source code.
FindBugs is a tool that differs from Checkstyle and PMD in that it analyzes Java bytecode. It searches for potential bugs that can break your program. This program searches for strings of bytecode that are known to potentially cause serious problems.
These tools can be incorporated into an IDE such as Eclipse to allow for feedback as the program is being developed. They will also create a HTML report containing descriptions of each problem found and their location.
JUnit allows developers to create simple tests to ensure that software is working correctly. Automated testing such as that provided by JUnit can save time and effort. It provides the developer some assurance that the program is functional without manually entering different test cases.
I found these tools to be very useful. They were able to find problems with my code much quicker than I would have been able to. They found two problems with my code. Checkstyle reported a problem with a condition in an IF statement I had declared. It reported that the expression (move == true) could be simplified. PMD reported a best practices violation in which I had variables that could be declared as local variables. After fixing these problems, I was able to successfully build my project.
I made some improvements to my Robocode robot based on observations made during the first robot battle. I restricted the range that my robot fires in order to save energy. I also attempted to adjust my firing to account for the many Walls style robots that were in the first tournament.
A developer distribution of my system can be found here.
Sunday, September 20, 2009
DiamondBot
Robocode is a fun, educational game where people can develop a virtual robot and battle it against other robots to see how effective it is. My first attempt at designing a competitive robocode robot was called DiamondBot. It was designed based on observations that I made during my review of sample robots that are provided with the robocode installation as well as the brainstorming of counter-robots for some of the sample robots. I tried to incorporate strengths and defenses for weaknesses that I observed into the design. The goal was to reliably defeat as many of the following sample robots as possible. The sample robots to defeat were Walls, RamFire, Spinbot, Crazy, Fire, Corners, Tracker, and Sitting Duck. Descriptions of my robot's movement, firing, and targeting are shown below.
Movement:
DiamondBot moves around the robot battlefield in a diamond pattern. The robot's movements change based on whether it is hitting its target or not. If it's hitting its target, then it will stay still if it gets close to the enemy. If the robot is missing its target, then it will try to stay away. If a collision with another robot occurs, the robot attempts to back away and continue with its normal movement pattern.
Firing:
DiamondBot varies the power of its bullets based on distance and accuracy. As an enemy gets closer, the power of the bullets fired increases. If DiamondBot is missing a lot, the maximum power of a bullet is reduced to prevent it from becoming disabled as quickly.
Targeting:
DiamondBot targets enemies by scanning with its radar and firing at the scanned position. If DiamondBot is missing a lot, it attempts to shoot an enemy by leading it to cause the enemy to run into the bullet.
DiamondBot was able to consistently defeat Walls, Ramfire, Crazy, Fire, Corners, Tracker, and Sitting Duck. However, it did not do well against Spinbot. I tried to come up with a strategy that could be used against Spinbot but, when making changes to compensate for Spinbot, I found that my performance against other robots decreased. I finally decided to sacrifice performance against Spinbot in order to keep performance against the other robots.
Creating my first competitive robot gave me insight into how difficult it is to create a well-rounded robot that is effective against many different strategies. When I made changes to increase my robot's performance against a specific robot, it often degraded its performance against other robots. It is very difficult to balance a robot, so it is always effective. I should have come up with a more solid, well-thought out strategy by doing further research on different strategies before starting to build my robot. I found that you must be flexible in your design because things don't always work out how you planned.
A packaged version of DiamondBot can be found here.
Movement:
DiamondBot moves around the robot battlefield in a diamond pattern. The robot's movements change based on whether it is hitting its target or not. If it's hitting its target, then it will stay still if it gets close to the enemy. If the robot is missing its target, then it will try to stay away. If a collision with another robot occurs, the robot attempts to back away and continue with its normal movement pattern.
Firing:
DiamondBot varies the power of its bullets based on distance and accuracy. As an enemy gets closer, the power of the bullets fired increases. If DiamondBot is missing a lot, the maximum power of a bullet is reduced to prevent it from becoming disabled as quickly.
Targeting:
DiamondBot targets enemies by scanning with its radar and firing at the scanned position. If DiamondBot is missing a lot, it attempts to shoot an enemy by leading it to cause the enemy to run into the bullet.
DiamondBot was able to consistently defeat Walls, Ramfire, Crazy, Fire, Corners, Tracker, and Sitting Duck. However, it did not do well against Spinbot. I tried to come up with a strategy that could be used against Spinbot but, when making changes to compensate for Spinbot, I found that my performance against other robots decreased. I finally decided to sacrifice performance against Spinbot in order to keep performance against the other robots.
Creating my first competitive robot gave me insight into how difficult it is to create a well-rounded robot that is effective against many different strategies. When I made changes to increase my robot's performance against a specific robot, it often degraded its performance against other robots. It is very difficult to balance a robot, so it is always effective. I should have come up with a more solid, well-thought out strategy by doing further research on different strategies before starting to build my robot. I found that you must be flexible in your design because things don't always work out how you planned.
A packaged version of DiamondBot can be found here.
Tuesday, September 15, 2009
RoboReviews
There are several sample robocode robots that are part of the robocode installation. These robots show different strategies and options that robots can use. The sample robots provide a good way for beginning robocode programmers to learn how to control robots they build. Each of the sample robots use different techniques for movement, targeting, and firing. I will discuss the strategies used for several of the sample robots.
Walls:
The walls robot continually moves along the outer edge of the battlefield. This robot keeps its gun facing in and fires at enemy robots with medium power when detected. If there is an enemy on the next wall to travel, Walls waits at the corner and fires down the line until the enemy moves or it is destroyed. Walls uses an avoidance strategy if a collision occurs. The walls robot moves to the opposite wall that it was moving down when the collision occurred. This robot uses a simple, but very effective strategy. It has a good balance of offense and defense.
RamFire:
When an enemy robot is scanned, Ramfire moves towards the enemy and attempts to ram it. This robot only fires after it rams the targeted enemy. It determines the power of its shot based on the amount of energy an enemy has remaining. The more energy an enemy has, the stronger the shot. RamFire continues to shoot an enemy with bullets until it is weak enough that it can destroy it by ramming. This robot attempts to gain bonus points by killing an enemy by ramming it rather than shooting it. This robot's strategy is offensive. While it can get bonus points if it is able to kill an enemy by ramming, a robot that can avoid being rammed can kill RamFire rather easily.
Spinbot:
Spinbot continuously moves in a clockwise circle and fires when an enemy is found. When this robot collides with another robot, it attempts to determine who's ramming into whom. If it determines that the collision was its own fault, it moves away from the enemy and continue its circular movement. If not, the robot fires at the enemy that collided with it. This robot always fires strongly regardless of an enemy's distance. This robot has a decent defensive strategy for avoiding bullets, but its targeting isn't that good.
Crazy:
Crazy uses an interesting strategy. It moves in an alternating arcing pattern. If a wall is hit or if it hits another robot, the robot reverses direction and continues with its arcing pattern. The Crazy robot fires weak bullets at scanned enemies. This robot mainly relies on its semi-unpredictable movement to avoid being shot. Attempting to make movements random seems to be a good defensive strategy.
Fire:
The Fire robot determines how much power to use when firing based on enemy distance and its own remaining life. If the enemy is within 50 pixels and it has more than 50% life, it fires a strong bullet, otherwise, it fires a weak bullet. The Fire robot sits still until it is hit by an enemy bullet. At that point, it changes its heading between -180 and 180 degrees based on its current heading and a scanned enemy's heading. Then, the Fire robot moves forward or backward a specified distance, alternating direction after each time it is hit. If the Fire robot is rammed by another robot, it faces its gun to the enemy and fires strong shots at it. This robot has a decent defense strategy to avoid enemy fire, however, its targeting of enemy robots is not that good.
Sitting Duck:
On the surface, the Sitting Duck robot seems to do nothing. However, it actually keeps track of how many rounds and battles it has been involved in. It displays this information in the console. This just shows you that you can't make assumptions about code based on behavior. You need to actually read the code to know what is happening.
Corners:
The Corners robot moves to a chosen corner, being careful not to crash into another robot while it is on its way. If Corners sees an enemy while it's on its way to a corner, it stops and fires at it. Once it gets to a corner, it turns its gun back and forth until an enemy robot to fire at is scanned. Corners determines the amount of power used based on its distance from the enemy and its own life. If the Corners robot is far away or its life is low, it fires a weak bullet. If Corners has a decent amount of life remaining, it increases its bullet power as an enemy gets closer. This robot uses a good strategy to determine the bullet strength used.
Tracker:
Tracker finds a target robot and attempts to follow it. If Tracker loses an enemy and cannot locate it within two turns, it searches by turning its gun to the left 10 degrees per turn. If it cannot find the enemy within five turns after losing it, it turns its gun right in increments of 10 degrees. If it still cannot find its enemy after ten turns, it looks for another enemy to target. Tracker attempts to get within 100 to 150 pixels of the target enemy. If it is too close, less than 100 pixels away, it backs up so it is within the 100 to 150 pixel range. Once a target is in range, it fires a strong bullet at it. If tracker collides with a different robot from the one already being tracked, the enemy robot that collided with it becomes its new target. Then, Tracker fires at it, and backs up a little. When Tracker wins a round, it does a victory dance. This robot employs a good tracking strategy. However, its defense is not that great because it can be getting shot by other robots that it is not tracking and it won't retaliate.
By reviewing the sample robots, many things about different strategies' strengths and weaknesses can be learned. Using the knowledge gained, I hope to incorporate the strategies that I found effective to build a competitive robot.
Walls:
The walls robot continually moves along the outer edge of the battlefield. This robot keeps its gun facing in and fires at enemy robots with medium power when detected. If there is an enemy on the next wall to travel, Walls waits at the corner and fires down the line until the enemy moves or it is destroyed. Walls uses an avoidance strategy if a collision occurs. The walls robot moves to the opposite wall that it was moving down when the collision occurred. This robot uses a simple, but very effective strategy. It has a good balance of offense and defense.
RamFire:
When an enemy robot is scanned, Ramfire moves towards the enemy and attempts to ram it. This robot only fires after it rams the targeted enemy. It determines the power of its shot based on the amount of energy an enemy has remaining. The more energy an enemy has, the stronger the shot. RamFire continues to shoot an enemy with bullets until it is weak enough that it can destroy it by ramming. This robot attempts to gain bonus points by killing an enemy by ramming it rather than shooting it. This robot's strategy is offensive. While it can get bonus points if it is able to kill an enemy by ramming, a robot that can avoid being rammed can kill RamFire rather easily.
Spinbot:
Spinbot continuously moves in a clockwise circle and fires when an enemy is found. When this robot collides with another robot, it attempts to determine who's ramming into whom. If it determines that the collision was its own fault, it moves away from the enemy and continue its circular movement. If not, the robot fires at the enemy that collided with it. This robot always fires strongly regardless of an enemy's distance. This robot has a decent defensive strategy for avoiding bullets, but its targeting isn't that good.
Crazy:
Crazy uses an interesting strategy. It moves in an alternating arcing pattern. If a wall is hit or if it hits another robot, the robot reverses direction and continues with its arcing pattern. The Crazy robot fires weak bullets at scanned enemies. This robot mainly relies on its semi-unpredictable movement to avoid being shot. Attempting to make movements random seems to be a good defensive strategy.
Fire:
The Fire robot determines how much power to use when firing based on enemy distance and its own remaining life. If the enemy is within 50 pixels and it has more than 50% life, it fires a strong bullet, otherwise, it fires a weak bullet. The Fire robot sits still until it is hit by an enemy bullet. At that point, it changes its heading between -180 and 180 degrees based on its current heading and a scanned enemy's heading. Then, the Fire robot moves forward or backward a specified distance, alternating direction after each time it is hit. If the Fire robot is rammed by another robot, it faces its gun to the enemy and fires strong shots at it. This robot has a decent defense strategy to avoid enemy fire, however, its targeting of enemy robots is not that good.
Sitting Duck:
On the surface, the Sitting Duck robot seems to do nothing. However, it actually keeps track of how many rounds and battles it has been involved in. It displays this information in the console. This just shows you that you can't make assumptions about code based on behavior. You need to actually read the code to know what is happening.
Corners:
The Corners robot moves to a chosen corner, being careful not to crash into another robot while it is on its way. If Corners sees an enemy while it's on its way to a corner, it stops and fires at it. Once it gets to a corner, it turns its gun back and forth until an enemy robot to fire at is scanned. Corners determines the amount of power used based on its distance from the enemy and its own life. If the Corners robot is far away or its life is low, it fires a weak bullet. If Corners has a decent amount of life remaining, it increases its bullet power as an enemy gets closer. This robot uses a good strategy to determine the bullet strength used.
Tracker:
Tracker finds a target robot and attempts to follow it. If Tracker loses an enemy and cannot locate it within two turns, it searches by turning its gun to the left 10 degrees per turn. If it cannot find the enemy within five turns after losing it, it turns its gun right in increments of 10 degrees. If it still cannot find its enemy after ten turns, it looks for another enemy to target. Tracker attempts to get within 100 to 150 pixels of the target enemy. If it is too close, less than 100 pixels away, it backs up so it is within the 100 to 150 pixel range. Once a target is in range, it fires a strong bullet at it. If tracker collides with a different robot from the one already being tracked, the enemy robot that collided with it becomes its new target. Then, Tracker fires at it, and backs up a little. When Tracker wins a round, it does a victory dance. This robot employs a good tracking strategy. However, its defense is not that great because it can be getting shot by other robots that it is not tracking and it won't retaliate.
By reviewing the sample robots, many things about different strategies' strengths and weaknesses can be learned. Using the knowledge gained, I hope to incorporate the strategies that I found effective to build a competitive robot.
Sunday, September 13, 2009
Coding Standards
Coding standards are a set of guidelines that programmers follow in order to make their code easier to read and understand. These standards involve things such as formatting, naming conventions, and documentation. Code is easier to read and understand when it is in a format that is familiar. Coding standards are also useful because the majority of code that is created will be read and modified by many different people.
Reading and understanding code that is written by someone else can be a difficult task. Writing code conforming to standards helps make it easier. The use of meaningful comments that explain difficult or essential parts of a program can speed up understanding a lot. On the other hand, having poor comments and bad formatting can make understanding nearly impossible for large, complex programs. Making code as easy to read and understand as possible should be done as a courtesy for the next person who has to work on it.
There were three coding standards that were implemented for the Robocode project. Each of the standards provide useful guidelines that make code easier to read and understand. These standards are listed below.
1) Elements of Java Style
2) ICS Coding Standards
3) ICS Robocode Standards
Upon review, I found that my code was not conforming to some of the standards for this class regarding formatting and documentation. One violation I found was that I was using tabs for indentation rather than two spaces. At first, I thought that it would be very tedious to change the formatting of my code to conform to the standard. I was glad to discover that the formatting of my code was easily fixed with the use of the provided XML file. I also added documentation comments to my code so others who read my code will know the purpose of the code at a glance.
The .jar file containing my code can be found here.
Reading and understanding code that is written by someone else can be a difficult task. Writing code conforming to standards helps make it easier. The use of meaningful comments that explain difficult or essential parts of a program can speed up understanding a lot. On the other hand, having poor comments and bad formatting can make understanding nearly impossible for large, complex programs. Making code as easy to read and understand as possible should be done as a courtesy for the next person who has to work on it.
There were three coding standards that were implemented for the Robocode project. Each of the standards provide useful guidelines that make code easier to read and understand. These standards are listed below.
1) Elements of Java Style
2) ICS Coding Standards
3) ICS Robocode Standards
Upon review, I found that my code was not conforming to some of the standards for this class regarding formatting and documentation. One violation I found was that I was using tabs for indentation rather than two spaces. At first, I thought that it would be very tedious to change the formatting of my code to conform to the standard. I was glad to discover that the formatting of my code was easily fixed with the use of the provided XML file. I also added documentation comments to my code so others who read my code will know the purpose of the code at a glance.
The .jar file containing my code can be found here.
Tuesday, September 8, 2009
Chronicles of Robocode
Robocode is game that battles virtual robots people have created in an arena. The code for each robot is written in Java. Programming a robot is a fun way to improve your programming skills. It’s easy to get started and you can program a simple robot within minutes, however, creating more advanced robots can take a lot more time and research. There is also a certain degree of math involved in getting your robot to behave the way you want it to, so it's a good idea to brush up on your trigonometry.
There are several aspects to a robot including movement, tracking enemy robots, and targeting/firing at enemy robots. We started slowly with simple robots in each category to familiarize ourselves with basic commands and successively built upon the previous robot to build more complicated robots. A list of the robots I successfully created are listed below.
Movement01: The minimal robot. Does absolutely nothing at all.
Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
Movement04: Move to the center of the playing field and stop.
Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
Movement06: Move to the center, then move in a circle, ending up where you started.
Tracking01: Pick one enemy and follow them.
Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
Firing03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
Firing04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).
I ran into some problems while creating the Movement04 robot. At first, I couldn't get my robot to face the correct direction to move to the center. I eventually found that the angles I was working with were in different coordinate systems, one in degrees and one in radians. After correcting this error, I was able to get the robot working. This problem helped my debugging skills because at first glance the code looked correct. Upon further investigation, I was able to figure out the problem.
I learned a lot about how Robocode robots behave through creating the different robots. There are some details that I'm not quite clear on yet, but I feel that I have a good grasp on most of the basic robot behaviors. Using the Robocode API was very helpful in figuring out how things work. I'm looking forward to creating more advanced robots. I think that a strategy that I may use is the random movement strategy because it would make targeting the robot difficult. I'm not sure what strategy I'll use yet, but I'm looking forward to seeing how my robot stacks up against others.
The project containing the source code for the robots I created can be found here.
There are several aspects to a robot including movement, tracking enemy robots, and targeting/firing at enemy robots. We started slowly with simple robots in each category to familiarize ourselves with basic commands and successively built upon the previous robot to build more complicated robots. A list of the robots I successfully created are listed below.
Movement01: The minimal robot. Does absolutely nothing at all.
Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
Movement04: Move to the center of the playing field and stop.
Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
Movement06: Move to the center, then move in a circle, ending up where you started.
Tracking01: Pick one enemy and follow them.
Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
Firing03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
Firing04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).
I ran into some problems while creating the Movement04 robot. At first, I couldn't get my robot to face the correct direction to move to the center. I eventually found that the angles I was working with were in different coordinate systems, one in degrees and one in radians. After correcting this error, I was able to get the robot working. This problem helped my debugging skills because at first glance the code looked correct. Upon further investigation, I was able to figure out the problem.
I learned a lot about how Robocode robots behave through creating the different robots. There are some details that I'm not quite clear on yet, but I feel that I have a good grasp on most of the basic robot behaviors. Using the Robocode API was very helpful in figuring out how things work. I'm looking forward to creating more advanced robots. I think that a strategy that I may use is the random movement strategy because it would make targeting the robot difficult. I'm not sure what strategy I'll use yet, but I'm looking forward to seeing how my robot stacks up against others.
The project containing the source code for the robots I created can be found here.
Sunday, August 30, 2009
FizzBuzzed
The FizzBuzz program is a simple program some interviewers use to test basic programming skills of applicants. The FizzBuzz program counts from 1 to 100 and prints out “Fizz” if the number is divisible by 3, “Buzz” if the number is divisible by 5, “FizzBuzz” if the number is divisible by both 3 and 5, and the number itself otherwise. The code for the FizzBuzz program is shown below.
It took me about 5 minutes to implement this program and verify the output was accurate. I didn’t run into any real problems, except that I couldn’t remember some of the syntax. Luckily, the Eclipse IDE auto-complete assisted with this problem. This experience helped me realize that programming, like other skills, need to be practiced to keep them sharp. Thankfully, IDEs, like Eclipse, exist to make life easier. Through the programming assignments in this class, I hope to sharpen my programming skills and become a more efficient programmer.
public class fizzbuzz {
public static void main(String[] args) {
// Loop 1 through 100
for(int i = 1; i <= 100; i++){
// Display FizzBuzz if i is divisible by 3 and 5
if(i % 15 == 0){
System.out.println("FizzBuzz");
}
// Display Fizz if i is divisible by 3
else if(i % 3 == 0){
System.out.println("Fizz");
}
// Display Buzz if i is divisible by 5
else if(i % 5 == 0){
System.out.println("Buzz");
}
// Display number if i is not divisible by 3 or 5
else{
System.out.println(i);
}
}
}
} It took me about 5 minutes to implement this program and verify the output was accurate. I didn’t run into any real problems, except that I couldn’t remember some of the syntax. Luckily, the Eclipse IDE auto-complete assisted with this problem. This experience helped me realize that programming, like other skills, need to be practiced to keep them sharp. Thankfully, IDEs, like Eclipse, exist to make life easier. Through the programming assignments in this class, I hope to sharpen my programming skills and become a more efficient programmer.
Sweet Home 3D
Overview:
Sweet Home 3D by eTeks is an open source Java application that assists users with interior designing of their home. It is available for download at http://sourceforge.net/projects/sweethome3d/.
There are three prime directives of open source software engineering that can be used as a measure of how well software is developed.
Prime Directive #1: The system successfully accomplishes a useful task.
This application allows users to create an accurate 2D layout of their residence. After creating a home, users are able to use the 2D model to place various pieces of furniture where they choose. This allows the user to experiment with various arrangements of their furniture without having to physically move them. The application also creates a 3D preview of the home to give users a more accurate idea of how their furnished home will look.
Prime Directive #2: An external user can successfully install and use the system.
Installation of this application was quick and easy with the Sweet Home 3D setup wizard which guides you through the installation process. Once Sweet Home 3D is installed, new users can access the Sweet Home 3D help which contains descriptions that explain how to use key features of the program. Additional help resources are available for users at http://www.sweethome3d.eu/documentation.jsp, including a video tutorial. After reviewing the help topics, users can quickly become efficient enough to begin modeling and decorating their home. I was able to create a simple 2D home and begin furnishing it within about 15 minutes. I found that this program was fun and easy to use.
Prime Directive #3: An external developer can successfully understand and enhance the system.
A plug-in developer’s guide, which walks through programming a new plug-in for Sweet Home 3D, is available at http://www.sweethome3d.eu/pluginDeveloperGuide.jsp. Also, the Sweet Home 3D source code and developer’s javadoc API is available at http://www.sweethome3d.eu/download.jsp. The source code contains comments to assist developers to understand and modify the code to meet their needs. The Sweet Home 3D API contains a thorough library of classes and methods used to create the Sweet Home 3D application. I think developers would be able to expand the capabilities of this application without much trouble after reviewing the source code and API.
Sweet Home 3D by eTeks is an open source Java application that assists users with interior designing of their home. It is available for download at http://sourceforge.net/projects/sweethome3d/.
There are three prime directives of open source software engineering that can be used as a measure of how well software is developed.
Prime Directive #1: The system successfully accomplishes a useful task.
This application allows users to create an accurate 2D layout of their residence. After creating a home, users are able to use the 2D model to place various pieces of furniture where they choose. This allows the user to experiment with various arrangements of their furniture without having to physically move them. The application also creates a 3D preview of the home to give users a more accurate idea of how their furnished home will look.
Prime Directive #2: An external user can successfully install and use the system.
Installation of this application was quick and easy with the Sweet Home 3D setup wizard which guides you through the installation process. Once Sweet Home 3D is installed, new users can access the Sweet Home 3D help which contains descriptions that explain how to use key features of the program. Additional help resources are available for users at http://www.sweethome3d.eu/documentation.jsp, including a video tutorial. After reviewing the help topics, users can quickly become efficient enough to begin modeling and decorating their home. I was able to create a simple 2D home and begin furnishing it within about 15 minutes. I found that this program was fun and easy to use.
Prime Directive #3: An external developer can successfully understand and enhance the system.
A plug-in developer’s guide, which walks through programming a new plug-in for Sweet Home 3D, is available at http://www.sweethome3d.eu/pluginDeveloperGuide.jsp. Also, the Sweet Home 3D source code and developer’s javadoc API is available at http://www.sweethome3d.eu/download.jsp. The source code contains comments to assist developers to understand and modify the code to meet their needs. The Sweet Home 3D API contains a thorough library of classes and methods used to create the Sweet Home 3D application. I think developers would be able to expand the capabilities of this application without much trouble after reviewing the source code and API.
Subscribe to:
Posts (Atom)