Just when we thought it was over, we had to look over more code. There wasn’t much time to rest, after a long and learning experience of creating an open source program. Our professor didn’t want us to take our eye off the ball, so he wanted for us to look over other group’s projects.
Giving
After examining other project code files, I see that everyone has some similar and different ideas in approaching the same problems. Some of the ideas I saw will possibly help in improving my group’s program, and I’m pretty sure other groups that reviewed our project will get some ideas too. It’s like Christmas, a time to give and take, as well as to share. Another thing I got from evaluating other projects was when suggesting on handling a problem, it was like a suggestion to me as well.
Recieving and The Google Experience
Using Google’s reviewing tool was a good learning experience. At first it seemed simple to use, just double clicking on lines I saw interesting enough to comment on. Although when I was finished with all my comments on a single file and clicked on save for each of the comments; a “publish your comments” link should have appeared at the right hand side of the screen, but it was nowhere to be found. So I thought I had lost all my input, then I clicked to go back to the previous page and then clicked to go back into the same file and all of a sudden the “publish your comments” link was there. Once I clicked on the link I was able to see all the comments I made for that file, the sad thing was that I had to repeat this process for every file I reviewed.
When it was time to see what others commented for my group project, it was actually frustrating for me to view the comments. I would go to a file that was commented on, for some reason no comments would appear anywhere. I explore and looked over and over everything that made any sense to enable me to see the comments from others, but couldn’t find anything. So I remembered Philip, a classmate that reviewed the project code, sent an email to me with a link to what he commented on. I followed the link and “BADA BING” the comments appeared, both his and others.
Not Narrow Minded
The comments we received was not much, but very valuable. Some of the comments pointed out issues we over looked, others were praises for good ideas on how to handle problems other people encountered. This experience was not at all degrading; we took every idea for improvement with an open mind. In our next opportunity of looking over other projects, I would be better prepared on using Google Project Hosting in the code commenting area. Also to give more detailed comments and offer more ideas, hoping they will be open minded as well.
Friday, October 24, 2008
Sunday, October 19, 2008
When is the DueDate???
Intro
This is an open source group project which will develop a program named DueDates. Its purpose is to log onto a library website without the use of a web browser. You will then need to provide a login and password for the library website. Once logged into the site, the program will display a list of books that you have checked out and their due dates.
Download DueDates.jar
Process
The process of creating this program was not too tricky. With our professor giving us a description of what I possibly should do, we knew what we wanted it to achieve. We wanted the basics of the program to be able to connect to a library website, log on to your account, and display a list of books you barrowed from the site. With that in mind, we also thought of making the program able to other libraries around the world, so that anyone in the world can use it.
We split the program up into different class files, that way we can be more organized, and just combining them into one package. Another reason for making different classes was if someone else where to make improvements to the program, they would know which file to enhance. The different classes that make up our program are: User, Library, UserLibraryInfo, and DueDates, which is the front end of the program. There are other minor classes which these four classes are derived from and they are: IUser, ILibrary, and IUserLibraryInfo. with everything separated and organized, future enhancements will not be a hard possibility.
Problems that Occurred and Solutions
We ran into some problems during the initial building of the program, the first of our problems was with importing external tools into our project. The problem with importing external tools was solved by communicating with other people in our class. A previous lab partner of mine, John, suggested to me that our project was not bringing in the Httpunit tool and instructed on how to import it into the project. Once that problem was fixed we proceed to develop our copy of DueDates. Just when we thought we were home free, suddenly our testing of the program was not working. After hours of gruesome tracing and looking at lines of code. I abruptly tried to import our files into a previous DueDates project our professor gave us, and it worked. The test completed and we were able to continue with the development.
Just when we thought it was smooth sailing from there on, our EMMA tool was not completing its coverage of our program. We decided that this problem can wait and proceed to fixing other minor problems. Later it was time to try to fix the EMMA problem; after a few hours of thinking of what it could be, Ron notified me that we need to make a test class in order for EMMA to complete its coverage and display its results. Creating that test class and running at least one test fixed the EMMA problem. Our other problems occurred during the running of the quality assurance tools, such as Check Style and PMD, but those errors were quickly resolved. The problems we faced, at the time seemed so big, but the answer to them was so small.
Working on this project we took a bigger step in to the world of Google Project Hosting. Learning how to use the different syntax of the wiki page was very troublesome. The user guide did not help so much and possible correction to the syntax I made, I had to commit the file to the project page to see the results; which cause a large number of commits. Another problem I had with the project page was when I accidentally made a commit and did not put anything on the log. There should be an option to go to the page and edit the log entry, depending if you were the one that made the commit.
The Future
A possible improvement for future development would be to create a user-interface. During our outsource testing; some of the users did not know how to get to a command prompt screen, which prevented them from using actually using the program. Also with a developed user-interface, we plan to also hold more than just the two libraries that are stored in the program, keeping mind that this program would be used for people from around the world. With the way we designed our program, I think future developments won’t be too complicated.
Thoughts
Creating an open source program is a tough and time consuming process, even though our professor provided us with the direction and foundation of the project. Despite the rough road to completion, I learned a lot from this experience. First of all, this being a group project, having a very dedicated and intelligent partner was really helpful. We met almost every day since the project was first assigned all the way to its completion. It was a good experience programming with someone on this open source project. When one of use was stuck in a problem, the other would find a way to solve the problem. Solving big or small problems with someone watching my back, has increased my liking for peer programming.
Also another thing that I valuably learned was how to handle problems, not taking so much time to look for a way to fix it. Take other routes to completion, moving around that problem and get back to it later, presuming that the problem won’t affect the rest of the development. Also not to burn yourself out on looking for a solution, take it as a sign to step away from the computer and relax your mind. Remember a big problem can always be solved by doing something so small.
This is an open source group project which will develop a program named DueDates. Its purpose is to log onto a library website without the use of a web browser. You will then need to provide a login and password for the library website. Once logged into the site, the program will display a list of books that you have checked out and their due dates.
Download DueDates.jar
Process
The process of creating this program was not too tricky. With our professor giving us a description of what I possibly should do, we knew what we wanted it to achieve. We wanted the basics of the program to be able to connect to a library website, log on to your account, and display a list of books you barrowed from the site. With that in mind, we also thought of making the program able to other libraries around the world, so that anyone in the world can use it.
We split the program up into different class files, that way we can be more organized, and just combining them into one package. Another reason for making different classes was if someone else where to make improvements to the program, they would know which file to enhance. The different classes that make up our program are: User, Library, UserLibraryInfo, and DueDates, which is the front end of the program. There are other minor classes which these four classes are derived from and they are: IUser, ILibrary, and IUserLibraryInfo. with everything separated and organized, future enhancements will not be a hard possibility.
Problems that Occurred and Solutions
We ran into some problems during the initial building of the program, the first of our problems was with importing external tools into our project. The problem with importing external tools was solved by communicating with other people in our class. A previous lab partner of mine, John, suggested to me that our project was not bringing in the Httpunit tool and instructed on how to import it into the project. Once that problem was fixed we proceed to develop our copy of DueDates. Just when we thought we were home free, suddenly our testing of the program was not working. After hours of gruesome tracing and looking at lines of code. I abruptly tried to import our files into a previous DueDates project our professor gave us, and it worked. The test completed and we were able to continue with the development.
Just when we thought it was smooth sailing from there on, our EMMA tool was not completing its coverage of our program. We decided that this problem can wait and proceed to fixing other minor problems. Later it was time to try to fix the EMMA problem; after a few hours of thinking of what it could be, Ron notified me that we need to make a test class in order for EMMA to complete its coverage and display its results. Creating that test class and running at least one test fixed the EMMA problem. Our other problems occurred during the running of the quality assurance tools, such as Check Style and PMD, but those errors were quickly resolved. The problems we faced, at the time seemed so big, but the answer to them was so small.
Working on this project we took a bigger step in to the world of Google Project Hosting. Learning how to use the different syntax of the wiki page was very troublesome. The user guide did not help so much and possible correction to the syntax I made, I had to commit the file to the project page to see the results; which cause a large number of commits. Another problem I had with the project page was when I accidentally made a commit and did not put anything on the log. There should be an option to go to the page and edit the log entry, depending if you were the one that made the commit.
The Future
A possible improvement for future development would be to create a user-interface. During our outsource testing; some of the users did not know how to get to a command prompt screen, which prevented them from using actually using the program. Also with a developed user-interface, we plan to also hold more than just the two libraries that are stored in the program, keeping mind that this program would be used for people from around the world. With the way we designed our program, I think future developments won’t be too complicated.
Thoughts
Creating an open source program is a tough and time consuming process, even though our professor provided us with the direction and foundation of the project. Despite the rough road to completion, I learned a lot from this experience. First of all, this being a group project, having a very dedicated and intelligent partner was really helpful. We met almost every day since the project was first assigned all the way to its completion. It was a good experience programming with someone on this open source project. When one of use was stuck in a problem, the other would find a way to solve the problem. Solving big or small problems with someone watching my back, has increased my liking for peer programming.
Also another thing that I valuably learned was how to handle problems, not taking so much time to look for a way to fix it. Take other routes to completion, moving around that problem and get back to it later, presuming that the problem won’t affect the rest of the development. Also not to burn yourself out on looking for a solution, take it as a sign to step away from the computer and relax your mind. Remember a big problem can always be solved by doing something so small.
Wednesday, October 8, 2008
Exploring the TortoiseSVN's shell with a friend
Goal
I will be continuing to explore the use of Google Project Hosting, but this time I will be member of another person’s Google Project page and he will be made a member of mine.
Making a Friend
Initially we, me and my partner Vincent Leung, added each other as members to our respective Google Hosting pages. Once we were members of each other’s page, we will be able to download, make changes, and upload files back onto the page. During our lecture class time, we spent most of it setting up our pages and learning on how to thoroughly use TortoiseSVN. Class was over, so we just exchanged emails in a way to contact each other.
When Vincent was able to upload his project files to his page, I proceeded to download it. I could have easy downloaded each individual code, but I that would take longer. So I made a folder in my local hard drive, to store Vincent’s project files, and then used the ‘checkout’ option on TortoiseSVN. Using that option, I was able to direct download his entire project all at once.
After setting up his project in Eclipse, using the Ant command line shell I tried verifying his project. I got and error and a failure in the JUnit check. When I got all the errors and failures that occurred during the Ant verification corrected, everything went smoothly. Committing, or uploading, the files that were modified back onto his project page, was easily done through TortoiseSVN.
Conclusion of Exploration
This encounter of using an SVN program with a Project Hosting page further shows me the simplicity of group programming. To me the most useful part of these tools was logging or describing the what is different in the version you committed using the log of TortoiseSVN and utilizing the "Changes" tab in the Google Project page, which shows the exact line that was changed and compares the current version to a previous version of the project. The only crack in the shell, problem, I can see is if the programmer that commits the version you are currently working on doesn’t give any good description of why or what changes they made, which can cause you to rollback to later versions or retrace steps.
I will be continuing to explore the use of Google Project Hosting, but this time I will be member of another person’s Google Project page and he will be made a member of mine.
Making a Friend
Initially we, me and my partner Vincent Leung, added each other as members to our respective Google Hosting pages. Once we were members of each other’s page, we will be able to download, make changes, and upload files back onto the page. During our lecture class time, we spent most of it setting up our pages and learning on how to thoroughly use TortoiseSVN. Class was over, so we just exchanged emails in a way to contact each other.
When Vincent was able to upload his project files to his page, I proceeded to download it. I could have easy downloaded each individual code, but I that would take longer. So I made a folder in my local hard drive, to store Vincent’s project files, and then used the ‘checkout’ option on TortoiseSVN. Using that option, I was able to direct download his entire project all at once.
After setting up his project in Eclipse, using the Ant command line shell I tried verifying his project. I got and error and a failure in the JUnit check. When I got all the errors and failures that occurred during the Ant verification corrected, everything went smoothly. Committing, or uploading, the files that were modified back onto his project page, was easily done through TortoiseSVN.
Conclusion of Exploration
This encounter of using an SVN program with a Project Hosting page further shows me the simplicity of group programming. To me the most useful part of these tools was logging or describing the what is different in the version you committed using the log of TortoiseSVN and utilizing the "Changes" tab in the Google Project page, which shows the exact line that was changed and compares the current version to a previous version of the project. The only crack in the shell, problem, I can see is if the programmer that commits the version you are currently working on doesn’t give any good description of why or what changes they made, which can cause you to rollback to later versions or retrace steps.
Tuesday, October 7, 2008
My pet Tortoise named SVN
The Goal
Become familiar with SVN, a subversion control system, and familiar with using Google Project Hosting, with its tasks and procedures.
Download the Program
First I had to download an SVN program software, our professor recommended TortoiseSVN for windows users. TortoiseSVN is an automated revision control, version control, and source control manager.
TortoiseSVN version 1.5.3
The Process
Creating a Google project site was rather moderately simple. I first started by going to the Google code page; then proceeding to the Project Hosting page, from there I started a new project. After reviewed the notes from Prof. Johnson, I started to fill in the text boxes with the required information from his example.
Once the project page was created, I continued to setup TortoiseSVN on my local computer to upload files to the project page. At this point I would have had a rather difficult time getting things to work, but luckily my professor had some very good instructions on the setup. When using the “checkout” option with TortoiseSVN on the folder that contains the files to be uploaded, you must make certain that the link is an https web URL for the project repository. This is because, if you use a normal http web URL you can only view and make local changes, but not commit the changed file to the project repository. From there I was able to commit my copy of the stack program.
Another thing I created was a new Google group; this group will serve as a place for discussion that relates to my project page. Each discussion topic is made each time a version of the project is created from the project page.
Testing how TortoiseSVN with Google Project Hosting worked, I made some javadoc changes to one of the files that were committed to my project page earlier. After the changes were made, I committed the file with a brief description of what I did. It then created a new version of the project in the project page, and also took into account of what specific file was changed and what was different from the previous version of the project.
Thoughts
Using TortoiseSVN combined with Google Project Hosting is a really good experience for me; I see that it’s useful for creating open source projects or just simple group class projects, using these combined project tools will make processing and control easy. It was also awesome seeing the Project Hosting page and the Group Discuss page were both linked to each other, after making the right settings. The most astonishing thing for me was seeing how all this works, the process of multiple programmers and logs taken with each version. The funny thing is that there was nothing lame or boring about this tortoise, but I do wonder how hard it’ shell is.
Become familiar with SVN, a subversion control system, and familiar with using Google Project Hosting, with its tasks and procedures.
Download the Program
First I had to download an SVN program software, our professor recommended TortoiseSVN for windows users. TortoiseSVN is an automated revision control, version control, and source control manager.
TortoiseSVN version 1.5.3
The Process
Creating a Google project site was rather moderately simple. I first started by going to the Google code page; then proceeding to the Project Hosting page, from there I started a new project. After reviewed the notes from Prof. Johnson, I started to fill in the text boxes with the required information from his example.
Once the project page was created, I continued to setup TortoiseSVN on my local computer to upload files to the project page. At this point I would have had a rather difficult time getting things to work, but luckily my professor had some very good instructions on the setup. When using the “checkout” option with TortoiseSVN on the folder that contains the files to be uploaded, you must make certain that the link is an https web URL for the project repository. This is because, if you use a normal http web URL you can only view and make local changes, but not commit the changed file to the project repository. From there I was able to commit my copy of the stack program.
Another thing I created was a new Google group; this group will serve as a place for discussion that relates to my project page. Each discussion topic is made each time a version of the project is created from the project page.
Testing how TortoiseSVN with Google Project Hosting worked, I made some javadoc changes to one of the files that were committed to my project page earlier. After the changes were made, I committed the file with a brief description of what I did. It then created a new version of the project in the project page, and also took into account of what specific file was changed and what was different from the previous version of the project.
Thoughts
Using TortoiseSVN combined with Google Project Hosting is a really good experience for me; I see that it’s useful for creating open source projects or just simple group class projects, using these combined project tools will make processing and control easy. It was also awesome seeing the Project Hosting page and the Group Discuss page were both linked to each other, after making the right settings. The most astonishing thing for me was seeing how all this works, the process of multiple programmers and logs taken with each version. The funny thing is that there was nothing lame or boring about this tortoise, but I do wonder how hard it’ shell is.
Wednesday, October 1, 2008
Two heads are better than One: Peer programming
Working on a project with another programmer sitting right beside me was not a new experience. I originally started programming at a computer lab, where there was a large amount of people using a computer and every computer was placed next to each other in rows. So as I would program, my classmate would program on the computer next to mine. We were assigned to work individually, but when either one of us were stuck on a problem we would turn to each other for advice. This was my first encounter of peer programming.
Programming with another person, to me, is one of the most effective tools in programming. I had the honor to work with a classmate of mine, John Ancheta, in our ICS 413 class. Our task for the first half was to have the Emma quality assurance tool have 100% coverage on a pre-implemented Stack program. We both took turns implementing on my laptop, and it was good having another set of eyes watching what I did. After completing the first half of our in class work, we then planned on how to create bug, but yet maintaining the coverage of a 100%.
John had the idea of rewriting what a method returned when tested. We both carefully thought it through and saw that it worked as we hoped for. We wanted to see if we expected the toString method located in the Stack class would return the list of elements, when rewritten to “this.element.size()” instead of “this.element”. (Note disregard the quotation marks.) As predicted, the coverage of the program was 100%, but failed in our JUnit test of the new “toString” method.
After noticing how Emma can get a result of full coverage and JUnit can have errors. I see that this as a disadvantage, even though one had good results and the other bad results. From this experience though, the advantage was having another head to help think and share their knowledge; also to write proper test cases and what to expect.
Stack implementation
Programming with another person, to me, is one of the most effective tools in programming. I had the honor to work with a classmate of mine, John Ancheta, in our ICS 413 class. Our task for the first half was to have the Emma quality assurance tool have 100% coverage on a pre-implemented Stack program. We both took turns implementing on my laptop, and it was good having another set of eyes watching what I did. After completing the first half of our in class work, we then planned on how to create bug, but yet maintaining the coverage of a 100%.
John had the idea of rewriting what a method returned when tested. We both carefully thought it through and saw that it worked as we hoped for. We wanted to see if we expected the toString method located in the Stack class would return the list of elements, when rewritten to “this.element.size()” instead of “this.element”. (Note disregard the quotation marks.) As predicted, the coverage of the program was 100%, but failed in our JUnit test of the new “toString” method.
After noticing how Emma can get a result of full coverage and JUnit can have errors. I see that this as a disadvantage, even though one had good results and the other bad results. From this experience though, the advantage was having another head to help think and share their knowledge; also to write proper test cases and what to expect.
Stack implementation
Reflections on Coverage and Testing
I will explore more into using testing tools; Emma 2.0.5312 and JUnit 4.5, both are quality assurance tools as well. The main tool I will be using is Emma, to see how well each classes, methods, blocks, and lines of code is covered and tested in a Stack program. Then from the results of Emma, I will then use JUnit to test any of errors I received from the Emma tool.
Initially I ran the same Stack implementation through other quality assurance tools; checkstyle, pmd, junit, and findbugs. From those tools I have repaired any errors I received. Now using the Emma tool, I see from the console screen that not all the methods, lines, and blocks were covered to a 100%. So I further went to the coverage.html file to see precisely what was not covered. A few methods from the original build were not tested, which caused the coverage to be about 78%. After writing some proper Junit test cases on untested methods, I got the coverage to 100%.
Using JUnit and Emma is a new experience for me; I’ve been use to writing generic print out statements as my test cases in the past. Seeing the results from Emma, I observe how easy it is to find out what methods were not tested and covered. I also noticed that, it is helpful running tests with JUnit. It was very helpful for me in examining the use of these two tools; for future use in projects, especially large scale projects.
Here is my copy of the Stack implementation with proper test cases.
Initially I ran the same Stack implementation through other quality assurance tools; checkstyle, pmd, junit, and findbugs. From those tools I have repaired any errors I received. Now using the Emma tool, I see from the console screen that not all the methods, lines, and blocks were covered to a 100%. So I further went to the coverage.html file to see precisely what was not covered. A few methods from the original build were not tested, which caused the coverage to be about 78%. After writing some proper Junit test cases on untested methods, I got the coverage to 100%.
Using JUnit and Emma is a new experience for me; I’ve been use to writing generic print out statements as my test cases in the past. Seeing the results from Emma, I observe how easy it is to find out what methods were not tested and covered. I also noticed that, it is helpful running tests with JUnit. It was very helpful for me in examining the use of these two tools; for future use in projects, especially large scale projects.
Here is my copy of the Stack implementation with proper test cases.
Subscribe to:
Posts (Atom)