Overview:
To expand our experience, I will be review three other teams code. I hope that by looking at their code, I will see how other people solve the same problem I had. During projects, we often base our solution on our current tools and knowledge. In return for review other team's code, our code are also reviewed by others to give us helpful tips on improvement.
Reaction:
When I review other people's code, I notice that 1 hour is not enough because of what we are asked to do. Following the User and Developer Guide can sometimes be a problem and the only what I was able complete a review is because I have first hand experience when setting up my own project. Another important key I notice was how groups priorities their task and set their goals. Some focus on creating expandability while others focused on the user experience. As a programmer, I was mostly drawn to the structure of the project. Because this is an ongoing project, creating classes to ease future development is important. There were a lot of small things me and my partner Anthony Du over looked. Review other people project reminded me of taking a step back and looking at the big picture.
Friday, October 24, 2008
Monday, October 20, 2008
Putting our Tools to the Test
Overview:
Now that I have all these tools in software development, the next step would be to test it. To test how effective I will be, I will be partnering up with Anthony Du in creating a program. The goal of this program is to help users quickly obtain a listing of all the books they are currently borrowing. Because this is in the beginning stages, the user will be using the command prompt to access the UHM Library and Hawaii State Library system. We hope to expand this to other library systems and to create a more user friendly interface.
Procedure:
This is pretty straight forward. Develop the code Philip Johnson gave us and create User and Developer guides. As a team, we need to create daily objectives to meet our goal in one week. This also helps with splitting the work load and to promote better teamwork.
Reaction:
It's amazing how fast time flies in a week. We tried to meet up early to give ourselves more time to work on it, but that ended up being a weekend programming marathon. Personally, I still have some problems starting the project. A little bit of fear and procrastination is enough to keep me from starting till I absolutely need too. The fear factor has gone down because I'm starting to enjoy solving these bugs. Google has amazingly pulled me through on this project without a problem. The only thing that makes me want to pull my hair out is the collisions me and Anthony face in submitting our code. It has almost come down to a horse race in submitting first so I don't have to fix the merge. I also have to admit that I sometimes forget to verify before Committing. Thankfully, the project was small enough that it did not hurt that much to fix it. In order to work around to constant merging collision, we decided to work on different parts of the project to minimize the time in reviewing and merging the code. Following is an image of the worst thing I saw this weekend:
Now that I have all these tools in software development, the next step would be to test it. To test how effective I will be, I will be partnering up with Anthony Du in creating a program. The goal of this program is to help users quickly obtain a listing of all the books they are currently borrowing. Because this is in the beginning stages, the user will be using the command prompt to access the UHM Library and Hawaii State Library system. We hope to expand this to other library systems and to create a more user friendly interface.
Procedure:
This is pretty straight forward. Develop the code Philip Johnson gave us and create User and Developer guides. As a team, we need to create daily objectives to meet our goal in one week. This also helps with splitting the work load and to promote better teamwork.
Reaction:
It's amazing how fast time flies in a week. We tried to meet up early to give ourselves more time to work on it, but that ended up being a weekend programming marathon. Personally, I still have some problems starting the project. A little bit of fear and procrastination is enough to keep me from starting till I absolutely need too. The fear factor has gone down because I'm starting to enjoy solving these bugs. Google has amazingly pulled me through on this project without a problem. The only thing that makes me want to pull my hair out is the collisions me and Anthony face in submitting our code. It has almost come down to a horse race in submitting first so I don't have to fix the merge. I also have to admit that I sometimes forget to verify before Committing. Thankfully, the project was small enough that it did not hurt that much to fix it. In order to work around to constant merging collision, we decided to work on different parts of the project to minimize the time in reviewing and merging the code. Following is an image of the worst thing I saw this weekend:
Tuesday, October 7, 2008
Part 2 of SVN and Google Project Hosting
Overview:
After becoming familiar with SVN and Google Project Hosting, I will be working with a partner in sharing and editing each others code. This will simulate a small scale of what program development will be like. By practicing how to use SVN effectively, future program developments will run much smoothly.
Procedure:
With the Google Project I created earlier, I will invite my partner, Robin Raqueno, as a member. Being a member means that he can have access to the stack program I uploaded and the ability to make changes to it. In return I will be given access to his code to review and make changes if needed. Once corrections have been made to our partner's code, we can then commit it to Google Project Hosting to update the trunk.
Review:
This excercise was every useful for me because my partner was able to find errors in my code that I over looked. He was able to email me and we both corrected my problems. The only problem I had was when I tried to commit the corrections I made. I got an error message saying that the code was in conflict. Then I remember that I had to update and merge before I can commit again. Turn around time on fixing code was much faster to because I did not have to wait for my partner to send me the code he fixed and we both will always have a working set of code on Google Project Hosting and all the revisions.
After becoming familiar with SVN and Google Project Hosting, I will be working with a partner in sharing and editing each others code. This will simulate a small scale of what program development will be like. By practicing how to use SVN effectively, future program developments will run much smoothly.
Procedure:
With the Google Project I created earlier, I will invite my partner, Robin Raqueno, as a member. Being a member means that he can have access to the stack program I uploaded and the ability to make changes to it. In return I will be given access to his code to review and make changes if needed. Once corrections have been made to our partner's code, we can then commit it to Google Project Hosting to update the trunk.
Review:
This excercise was every useful for me because my partner was able to find errors in my code that I over looked. He was able to email me and we both corrected my problems. The only problem I had was when I tried to commit the corrections I made. I got an error message saying that the code was in conflict. Then I remember that I had to update and merge before I can commit again. Turn around time on fixing code was much faster to because I did not have to wait for my partner to send me the code he fixed and we both will always have a working set of code on Google Project Hosting and all the revisions.
New Experiences with SVN and Google Project Hosting
Overview:
This week, I will be taking a first hand look into SVN by using TortoiseSVN and Google Project Hosting. SVN is a version control software that aids programmers in software development by allowing everyone in the project to concurrently update and make changes to the code. This also keeps a history of all changes so projects can be reverted if there are major bugs found. By getting familiar with the software, I will be able to increase productivity and reduce collisions during development.
Procedure:
The first task that I should complete is to install TortoiseSVN and read the directions and how it works. Once I become familiar with TortoiseSVN I should connect and modify an existing project of Google Project Hosting. My target would be stack-johnson. Once I download all hte files for the project, I should make some "improvements", run verify to make sure it still runs, and then commit the changes. The third task would be to create my own Google Project Hosting to see how it can be customized.
Conclusion:
SVN seems to be one of the most useful tools I have learned so far. Before this, the only concept in programming as a group would be to split the work into coding and documentation or to code one person at a time. This was always time consuming because one person would be waiting for the other person to finish before starting. It is also very helpful with the code being hosted online so that it would be easier with different work schedules.
This week, I will be taking a first hand look into SVN by using TortoiseSVN and Google Project Hosting. SVN is a version control software that aids programmers in software development by allowing everyone in the project to concurrently update and make changes to the code. This also keeps a history of all changes so projects can be reverted if there are major bugs found. By getting familiar with the software, I will be able to increase productivity and reduce collisions during development.
Procedure:
The first task that I should complete is to install TortoiseSVN and read the directions and how it works. Once I become familiar with TortoiseSVN I should connect and modify an existing project of Google Project Hosting. My target would be stack-johnson. Once I download all hte files for the project, I should make some "improvements", run verify to make sure it still runs, and then commit the changes. The third task would be to create my own Google Project Hosting to see how it can be customized.
Conclusion:
SVN seems to be one of the most useful tools I have learned so far. Before this, the only concept in programming as a group would be to split the work into coding and documentation or to code one person at a time. This was always time consuming because one person would be waiting for the other person to finish before starting. It is also very helpful with the code being hosted online so that it would be easier with different work schedules.
Wednesday, October 1, 2008
Limitations of Coverage Testing
Overview:
As a continuation of the coverage testing for the Stack program, I will now look for flaws in this type of testing. Because coverage testing only checks to see if you tested every line, it does not fully test the logic behind each line. To build upon my 100% coverage testing on the Stack program, I will edit the testing or the Stack program to show a major bug while maintaining the 100% coverage. This new bug can be demonstrated with a new test I create.
Procedure:
As I think of ways to create a major bug that coverage testing can not detect, Philip Johnson gave us an example where if we set a limit on the array size, we can create a bug if we push to much. As I looked more into JUnit and Coverage testing, I can see that I just have to change the logic and return variable to show a bug. I decided to hard code the return string for toString in Stack.java to work around the coverage test. A test class "testLimit" has been created to show this bug in testStack.java.
Conclusion:
This exercise showed me that coverage testing is not enough to find all bugs in a program. There needs to be thorough testing instead of just aiming for 100% coverage. All coverage can tell you is if you missed a method, line, or block in testing.
Distribution file
As a continuation of the coverage testing for the Stack program, I will now look for flaws in this type of testing. Because coverage testing only checks to see if you tested every line, it does not fully test the logic behind each line. To build upon my 100% coverage testing on the Stack program, I will edit the testing or the Stack program to show a major bug while maintaining the 100% coverage. This new bug can be demonstrated with a new test I create.
Procedure:
As I think of ways to create a major bug that coverage testing can not detect, Philip Johnson gave us an example where if we set a limit on the array size, we can create a bug if we push to much. As I looked more into JUnit and Coverage testing, I can see that I just have to change the logic and return variable to show a bug. I decided to hard code the return string for toString in Stack.java to work around the coverage test. A test class "testLimit" has been created to show this bug in testStack.java.
Conclusion:
This exercise showed me that coverage testing is not enough to find all bugs in a program. There needs to be thorough testing instead of just aiming for 100% coverage. All coverage can tell you is if you missed a method, line, or block in testing.
Distribution file
Subscribe to:
Posts (Atom)