Overview:
Another week and another rush to finish. Who would have thought little features like sort and within would be so much problem. Along with adding those two new features, we had to add the Hawaii State Library System as another library we can access. Lucky a time extension was given to let us sleep a extra night.
Process:
Communication was good in the beginning. We met up at Hamilton Library for a few hours and we got a lot of work done, but things turned fuzzy after that. Because of our busy schedules, we were limited to only Instant Messaging and Aim. We tried to schedule another meeting, but things came up so we had to cancel it. For me, it was hard for me to program since I did not know how the design was going to be. For example, I would be sitting in front of the computer reading Anthony's message and designing how the Library file will parse the sort and within parameters and then I see that Anthony created a robust parsing file. I end up retracing the program and frustrated that I was unable to help.
Results:
We completed the project with all the requirements needed. Our project automatically sorts the results by Library and the user can sort the books by due date. Both library systems are working and the within feature works fine. Continuous Integration is a very fun tool. It's like another person watching our submits and waiting to give us a red mark when we forget to verify.
Reflection:
I think the one thing that can improve my effectiveness would be to find more time to meet up face to face to program. Aim and email does not seem to work to well with me and I was able to see a major difference between me working alone and me working with my partner side by side. That is the optimal view, but I also need to improve my communication skills over the internet so that I can be more productive when I'm at home.
Monday, November 3, 2008
Saturday, November 1, 2008
Self Reflection on Review
Overview:
As a team, me and Anthony are given the task to review another team's code. We need to help them test if we are able to download their code and configure our system to be able to start developing. Because we are developing an open source application, it is very important for our code to be robust and easy to set up for future development by other programmers.
Review:
It has always been hard for me to give a review because I would have to criticize their code and point out their flaws in design. I also run into uncertainty because I am reviewing code that are in the middle of development. Since I am not in their group, I would not no their goals and I would be wrong with my review. When I was reviewing purple's code, I felt really back because I was unable to get the code working. In my mind, I believe that it should be working and the fault was with me. I ended up not being able to run their code in Eclipse, so I just traced the code to help review other parts of the code.
After doing the review, I talked to Anthony and I was surprised that we both gave the same review. I guess because we worked together on our code, their design thoughts were the same. It was also nice to know that I was not the only one having problems getting their code to work. Looking at Purple's code also gave us ideas on how to solve our problems.
As a team, me and Anthony are given the task to review another team's code. We need to help them test if we are able to download their code and configure our system to be able to start developing. Because we are developing an open source application, it is very important for our code to be robust and easy to set up for future development by other programmers.
Review:
It has always been hard for me to give a review because I would have to criticize their code and point out their flaws in design. I also run into uncertainty because I am reviewing code that are in the middle of development. Since I am not in their group, I would not no their goals and I would be wrong with my review. When I was reviewing purple's code, I felt really back because I was unable to get the code working. In my mind, I believe that it should be working and the fault was with me. I ended up not being able to run their code in Eclipse, so I just traced the code to help review other parts of the code.
After doing the review, I talked to Anthony and I was surprised that we both gave the same review. I guess because we worked together on our code, their design thoughts were the same. It was also nice to know that I was not the only one having problems getting their code to work. Looking at Purple's code also gave us ideas on how to solve our problems.
Friday, October 24, 2008
By Our Powers Combined
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.
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.
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)