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.
Tuesday, November 10, 2009
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.
Subscribe to:
Posts (Atom)