2 weeks ago I was assigned to a new group for the DueDates project. This time instead of working with a partner I had to learn to work with 3 other people. Things got a bit complicated in term of group management but it was nothing we couldn't manage. Professor Johnson once stateed that group leaders didn't need to be assigned because they naturally rise from the group to take that role. Well, he was right. It was clear from the beginning that Ronnie had the sense of responsibly and ability to coordinate easily among different group members that was needed in a leadership position. He had us coordinate our schedule using Doodle so that met several times over the past two weeks. These meeting were located at Sinclair Library and usually occured almost every evening.
We decided to use the DueDates-silver project as a foundation for our new code since it already had xml parsing already built in which was one of the features we had to implement in this project. The only problem with silver was that coded in such a way that made it really difficult for new developers to get a grasp of. That taught me that I had a much easier time with code that I built from the ground up than code that would be handed to me. It took a while but Ronn manage to cut the code that was superfluous to the new project and that helped alot.
Several days later I noticed that mine and other member's statistics weren't being recorded and I realized we didn't add ourselves to our own Hackystat project. I also informed Ronnie that he had to add codesite-noreply@google.com and csdl.hudson@gmail.com because we weren't being emailed any info on the project.
Each of us was given a task to work on. While the others worked on the xml parsing and the web site I had a hand in redoing the the sort implementation and working on the extra credit assignment that involved being able to dynamically load libraries. I know we weren't suppose to work on additional features before we did the main components of the the project but my previous project was developed in similar and I was admittedly weak with Wicket. I felt that I didn't go too much out of my way to work on it. I also did coverage, wiki pages, and fixed a jar issue that was preventing it from running the program. I tested out my extensible library feature and it worked perfectly. I even tested it with a jar.
Eventually when it came down to the wire everything was up and running except for one problem. We couldn't hook up requestInfo to the wicket meaning we couldn't output any info to the website. This was devastating as it was less about needing more time but more about getting help. Many hours were spent trying to find a solution but none were found. None of us could figure it out so we had to set up example output to test the other features of the project.
The jar file of the project can be found here and the distribution can be found here.
Monday, December 8, 2008
Monday, November 24, 2008
Wicked?
This week I started using Wicket to implement a stack web implementation. Suffice it to say I had a rather difficult time with it. I didn't get around to finishing it Mostly it was my fault because I didn't devote enough time to learning Wicket and when it came around to coding I didn't have enough time due to other obligations.
First thing I did was figure whether I wanted to base the main class of my project on the Jetty.class in Example 2 of the wicket examples, which can be found here, or on the Start.class in Example. After some failed attempts getting something similar to the Start.java to run I switched over to Jetty.class which worked out fine. Then started a series of stumbles where I tried to implement something, then finding that it depended on a class that I didn't implement, implementing that class, then finding out that the class also required another class that I didn't implement. At the end I was a bit confused at how PropertyModel worked and I was getting bugs where the it suggested the stack class needed a get method. So now I think that I need a variable in the stack class to hold the data from the textField on the web page and that when a button is pressed on the page the corresponding stack method will use that variable.
My biggest problem that I have to change is time management. I already spent quite some time with the project but didn't realize that I it would take much more than what I had available.
A distribution of the project can be found here.
First thing I did was figure whether I wanted to base the main class of my project on the Jetty.class in Example 2 of the wicket examples, which can be found here, or on the Start.class in Example. After some failed attempts getting something similar to the Start.java to run I switched over to Jetty.class which worked out fine. Then started a series of stumbles where I tried to implement something, then finding that it depended on a class that I didn't implement, implementing that class, then finding out that the class also required another class that I didn't implement. At the end I was a bit confused at how PropertyModel worked and I was getting bugs where the it suggested the stack class needed a get method. So now I think that I need a variable in the stack class to hold the data from the textField on the web page and that when a button is pressed on the page the corresponding stack method will use that variable.
My biggest problem that I have to change is time management. I already spent quite some time with the project but didn't realize that I it would take much more than what I had available.
A distribution of the project can be found here.
Monday, November 17, 2008
Spamalot
This week began the development of the email alert and the scheduled task component of the project. For the email alert we wanted the system to email the user a list of books that are due. For the scheduled tasks we wanted the program to perform a scheduled task. That way we could, for example, have the program check everyday if there are books that are about to be due.
Since we were told that it wasn't too difficult to code, we decided to split the work with me working on the scheduled task and my partner working on the email alert. For my part, first I had some difficulty juggling the data types. I had to parse a double argument and use it as a long for one method and a int for another method along with figuring out time in milliseconds. After creating the Wakeup class for executing the schedule task I realized that I had to somehow run the program without calling main again. Eventually I came to the conclusion that I had to move most of the the code from the main method to the DueDates constructor so that I could execute the program outside the main.
Because of the "simplicity" of this part of the project we met twice this week for 30 mins. Next week we will more than likely meet up for longer since I expect to be given something more difficult. When we met I had issues with my JAVAMAIL_HOME argument where the program will only run if I removed it. Turns out it was somehow conflicting with the mail.jar in the lib/ext of the Java installation. I moved it out of there and redirected the enviromental variable to its new location. Later on I realized that in order for the DueDates.jar file to run correctly I needed mail.jar back in that directory so I just copy and pasted it back in.
Working on version 1.2 was actually in some ways more difficult than 1.1. I definitely got stuck more often in 1.2 than 1.1. In 1.2 had to move around large sections of code in the main. In 1.1 I had to remove more code and add more code than in 1.2.
This week we manage to get code that will fail verify on our local system but pass in Hudson. Because we didn't have system variables for emails in Hudson we had to hard code them in the Junit test case TestMailer.java. Since the host was mail.hawaii.edu it would only work when the system was hooked up to hawaii.edu network. To test email on my system I used smtp-server.hawaii.rr.com.
Next time I want to get more practice with test cases and I want to reconsider how the code is structure. At the moment it works but it isn't a very elegant solution.
A distribution of the new version of the project can be found here.
Since we were told that it wasn't too difficult to code, we decided to split the work with me working on the scheduled task and my partner working on the email alert. For my part, first I had some difficulty juggling the data types. I had to parse a double argument and use it as a long for one method and a int for another method along with figuring out time in milliseconds. After creating the Wakeup class for executing the schedule task I realized that I had to somehow run the program without calling main again. Eventually I came to the conclusion that I had to move most of the the code from the main method to the DueDates constructor so that I could execute the program outside the main.
Because of the "simplicity" of this part of the project we met twice this week for 30 mins. Next week we will more than likely meet up for longer since I expect to be given something more difficult. When we met I had issues with my JAVAMAIL_HOME argument where the program will only run if I removed it. Turns out it was somehow conflicting with the mail.jar in the lib/ext of the Java installation. I moved it out of there and redirected the enviromental variable to its new location. Later on I realized that in order for the DueDates.jar file to run correctly I needed mail.jar back in that directory so I just copy and pasted it back in.
Working on version 1.2 was actually in some ways more difficult than 1.1. I definitely got stuck more often in 1.2 than 1.1. In 1.2 had to move around large sections of code in the main. In 1.1 I had to remove more code and add more code than in 1.2.
This week we manage to get code that will fail verify on our local system but pass in Hudson. Because we didn't have system variables for emails in Hudson we had to hard code them in the Junit test case TestMailer.java. Since the host was mail.hawaii.edu it would only work when the system was hooked up to hawaii.edu network. To test email on my system I used smtp-server.hawaii.rr.com.
Next time I want to get more practice with test cases and I want to reconsider how the code is structure. At the moment it works but it isn't a very elegant solution.
A distribution of the new version of the project can be found here.
Friday, November 7, 2008
Emergency Room
Recently we started working with the idea of "Software ICU" where the progress and "health" of a project can be tracked. The idea is to takes information from the project such as coverage and commits and track these statistics over time. It's helpful to be able to see the history of project because that will in turn influence the future development of it. In our project we used Hackystat to assist us with this idea. I installed all the necessary tools which included Perl, JavaNCSS, DependencyFinder, and SCLC and followed the instructions. Then I verified that I was sending vital signs from the example project, stack-johnson, and duedates-yellow. Note that in order to send vitals signs, we had to update our build files and create a Hackstat project. We also created a daily build for our project. Some obstacles I encountered was the usual getting the enviromental variables correctly set and running the build files in eclipse because it's my prefered method rather than using the command prompt. So far I noted that in the Software Project Portfolio Analysis the weakest part of our project is coverage. Otherwise the others stats are generally good.
Monday, November 3, 2008
Climbing the Ladder
This week we started the next phase of the DueDates project. We gained some experience with Continuous Integration using Hudson. Hudson gives us another level of oversight on our program, allowing us to double check our code. I found that it was a good way to catch errors that might not crop up during testing on a local system such as forgetting to upload a newly created java file. At one point Hudson was giving me errors about using @Override in certain portions of my code even though it passed verify on my system. Turns out that it noticed that those methods didn't actually override the superclass methods so @Override was unecessary.
Additionally we were tasked with adding new capabilities to our program, including supporting multiple libraries, sorting, and output control. To deal with the new arguments I added a bunch of conditional statements. To deal with the new requirements I first thought up of a complex program structure that involved storing book objects into a ArrayList for each library and storing each of those list into another ArrayList. Eventually my partner John Ly came up with a much simpler implementation that only needed a single ArrayList.
For the sorting method, at first my partner created a sorting method that used bubble sort. I decided that it was simpler to use the Collection class to sort the ArrayList and override the necessary methods. I spent some time fighting with FindBugs over EQ_COMPARETO_USE_OBJECT_EQUALS but eventually I resolved it. Additionally we first assumed that sorting by library didn't need any work since books were placed in the ArrayList by libraries according to the order of the arguments but eventually we realized that we didn't consider multiple account request to the same library. After some research I used the Comparator class in the Java API to add the library sort capability.
As for the within method we used a Calendar class help us contain the date information and used it also drop books from our ArrayList that weren't due within the user specified number of days.
For the project we met up twice for about 2 hours. During that time we shifted from my idea for the program structure to John Ly's idea for it. Having face to face helps quite a bit when you have to discuss complex program structures and features. It's a good way to ensure that the other person understands them. With other forms of communication it becomes a bit more diffucult. Eventually we finished meeting the requirements for the project. A distribution of the current state of the project can be found here.
Additionally we were tasked with adding new capabilities to our program, including supporting multiple libraries, sorting, and output control. To deal with the new arguments I added a bunch of conditional statements. To deal with the new requirements I first thought up of a complex program structure that involved storing book objects into a ArrayList for each library and storing each of those list into another ArrayList. Eventually my partner John Ly came up with a much simpler implementation that only needed a single ArrayList.
For the sorting method, at first my partner created a sorting method that used bubble sort. I decided that it was simpler to use the Collection class to sort the ArrayList and override the necessary methods. I spent some time fighting with FindBugs over EQ_COMPARETO_USE_OBJECT_EQUALS but eventually I resolved it. Additionally we first assumed that sorting by library didn't need any work since books were placed in the ArrayList by libraries according to the order of the arguments but eventually we realized that we didn't consider multiple account request to the same library. After some research I used the Comparator class in the Java API to add the library sort capability.
As for the within method we used a Calendar class help us contain the date information and used it also drop books from our ArrayList that weren't due within the user specified number of days.
For the project we met up twice for about 2 hours. During that time we shifted from my idea for the program structure to John Ly's idea for it. Having face to face helps quite a bit when you have to discuss complex program structures and features. It's a good way to ensure that the other person understands them. With other forms of communication it becomes a bit more diffucult. Eventually we finished meeting the requirements for the project. A distribution of the current state of the project can be found here.
Friday, October 24, 2008
Everyone's A Critic
This week began the review phase of our project. Everyone was tasked with looking over each others' code and making comments to it. For our project Aric took a look at our xml files and noted that we had the wrong project name in a few of them. He also suggested changing the login and getInfo method in Lender.java to abstract which I took into consideration. He stated that there were several JavaDoc comments that had flimsy description so we expanded them. Two reviewers commented that we hard coded the login and password for TestLender.java. I guess I forgot to change that after I changed how arguments are passed in TestUhManoa.java. Philip noted we had @Ignore in our test cases, which we only added to pass verify.build.xml. Two reviewers noted our argument for specifying the library was different from the standard so I changed that. Ancheta suggested we turn the Lender class into a interface because we only had print statements in there but we prefer to keep it as a superclass so that we could use it later in the future for nonspecified library methods. The only two individuals who didn't make a comment was Flestado and Sanchez.
For my reviews I was tasked with the red, silver, and gold teams. For gold I was tasked with looking at the JavaDoc comments. I made a comment for the LibraryVault.java because their parameter descriptions was gibberish. For red I was tasked with looking at the main method
where I didn't see any problems. For silver I was tasked with looking at Library.java, User.java, Book.java, and the testing suite. I made a suggesting to have toString in Book.java to return both the book title and due date. I also suggested dropping the toString in User.java because it does the same thing as getUserID.
The act of posting comments to the code in Google Project Hosting was awkward for me because in order to have the "Publish Comments" appear I had to add a comment and save, refresh the page, and add the comment again. Looking at other groups code gave me alot of ideas that I would like to incorporate into my group's code. Probably the work that needs to get done the most is in the test cases. Next time I would probably clarify that it's alright to look at code outside the reviewer's main task. I would probably do the same to the tasks assigned to me.
For my reviews I was tasked with the red, silver, and gold teams. For gold I was tasked with looking at the JavaDoc comments. I made a comment for the LibraryVault.java because their parameter descriptions was gibberish. For red I was tasked with looking at the main method
where I didn't see any problems. For silver I was tasked with looking at Library.java, User.java, Book.java, and the testing suite. I made a suggesting to have toString in Book.java to return both the book title and due date. I also suggested dropping the toString in User.java because it does the same thing as getUserID.
The act of posting comments to the code in Google Project Hosting was awkward for me because in order to have the "Publish Comments" appear I had to add a comment and save, refresh the page, and add the comment again. Looking at other groups code gave me alot of ideas that I would like to incorporate into my group's code. Probably the work that needs to get done the most is in the test cases. Next time I would probably clarify that it's alright to look at code outside the reviewer's main task. I would probably do the same to the tasks assigned to me.
Sunday, October 19, 2008
DueDates
Recently I started a Java project named DueDates. What this program does is retrieve information from libraries and allows a user to find out what books they have borrowed along with their due dates. In this project I worked with Jon Ly we put together a program that allowed a user to access the UH Library system and find out the books he has borrowed. The project can be found here and project files can be downloaded here.
Design
One of our first problems was to figure out how to divide up the classes. We wanted to make sure the program was extensible so that in the future we could easily add more libraries and features. We created a Lender superclass which in the future we hope will have generic methods that can access libraries that can't be found in the program. There is also a toFormattedString method in it that we use standardize the output of all libraries. In the future we could also add other standardized features to the Lender class like a GUI.
From that superclass we created library subclasses that had login and getInfo methods specific to each library. Later we can add other methods that might be unique for each library.
Problems and Resolution
Using HTTPUnit we had the program look for the first table with the string "Renew?" on the UH page which should be the table containing the information on books borrowed. It's doubtful that any other table will start with that string and testing for that possibility would be slightly difficult since the only other possible table before that one is the Patron Block table which I believe is related to late fees.
Since we moved all our methods to other classes there was only a static main method in the main class so a Singleton error cropped up while running PMD. This was an error I've never seen before and through some research I found it can be fixed by adding a private constructor.
One of our biggest problems was making the test cases. It took me a while to figure out how to pass arguments to test cases. I couldn't tell if it worked because we couldn't figure out how to get the login method test to work. The method was suppose to return a object, in this case a WebConversation object, but we couldn't figure how to check if the correct object was returned. So we had to add a @Ignore to get the program to pass verify.build.xml.
Another problem I noticed was that when running Emma it would produce a Rhino classes error. I wasn't exactly sure whether the cause was our test cases or Rhino which we were told we could ignore.
Future Features
In the future we hope to add other libraries including the Hawaii State Library. The Hawaii State Library system wasn't the focus of this phase of the project but we had a cursory class for it. There are a few problems with it, including a slow info retrieval and getting accurate information, that we hope to fix with the next phase of the program. We also plan to add the ability to retrieve more information besides just borrowed books including fees, requests and holds. We also want to allow the user to renew books through the program. It'll be nice if the program had an alert system that a user can schedule to warn him when something is almost due. Also the ability to send a feed to different programs would be cool. Lastly, even though it's unlikely, I'll like the program to attempt to access other libraries that haven't been covered by the program.
Group Project
Our group met at the Hamilton library about 3 times, spending an average of an hour each time working on the project. We had discussions on the design of the program and what part of the project we will be working on. We made sure to commit frequently throughout the week. I think that the way we organized ourselves was effective and allowed us to get the program done in a timely manner.
As for Google Project Hosting I found the Issues tab to be an effective way for members of a project to point out problems that arise during the course of the project. Probably the only annoyance I had with Google Project is the amount of emails I got. In the past week I received 40 emails from the project. I understand getting an email for rather important items like commit changes but wiki changes and some issue reports are things that I really don't need to know about. There should be some sort of priority on whether something is email worthy.
Design
One of our first problems was to figure out how to divide up the classes. We wanted to make sure the program was extensible so that in the future we could easily add more libraries and features. We created a Lender superclass which in the future we hope will have generic methods that can access libraries that can't be found in the program. There is also a toFormattedString method in it that we use standardize the output of all libraries. In the future we could also add other standardized features to the Lender class like a GUI.
From that superclass we created library subclasses that had login and getInfo methods specific to each library. Later we can add other methods that might be unique for each library.
Problems and Resolution
Using HTTPUnit we had the program look for the first table with the string "Renew?" on the UH page which should be the table containing the information on books borrowed. It's doubtful that any other table will start with that string and testing for that possibility would be slightly difficult since the only other possible table before that one is the Patron Block table which I believe is related to late fees.
Since we moved all our methods to other classes there was only a static main method in the main class so a Singleton error cropped up while running PMD. This was an error I've never seen before and through some research I found it can be fixed by adding a private constructor.
One of our biggest problems was making the test cases. It took me a while to figure out how to pass arguments to test cases. I couldn't tell if it worked because we couldn't figure out how to get the login method test to work. The method was suppose to return a object, in this case a WebConversation object, but we couldn't figure how to check if the correct object was returned. So we had to add a @Ignore to get the program to pass verify.build.xml.
Another problem I noticed was that when running Emma it would produce a Rhino classes error. I wasn't exactly sure whether the cause was our test cases or Rhino which we were told we could ignore.
Future Features
In the future we hope to add other libraries including the Hawaii State Library. The Hawaii State Library system wasn't the focus of this phase of the project but we had a cursory class for it. There are a few problems with it, including a slow info retrieval and getting accurate information, that we hope to fix with the next phase of the program. We also plan to add the ability to retrieve more information besides just borrowed books including fees, requests and holds. We also want to allow the user to renew books through the program. It'll be nice if the program had an alert system that a user can schedule to warn him when something is almost due. Also the ability to send a feed to different programs would be cool. Lastly, even though it's unlikely, I'll like the program to attempt to access other libraries that haven't been covered by the program.
Group Project
Our group met at the Hamilton library about 3 times, spending an average of an hour each time working on the project. We had discussions on the design of the program and what part of the project we will be working on. We made sure to commit frequently throughout the week. I think that the way we organized ourselves was effective and allowed us to get the program done in a timely manner.
As for Google Project Hosting I found the Issues tab to be an effective way for members of a project to point out problems that arise during the course of the project. Probably the only annoyance I had with Google Project is the amount of emails I got. In the past week I received 40 emails from the project. I understand getting an email for rather important items like commit changes but wiki changes and some issue reports are things that I really don't need to know about. There should be some sort of priority on whether something is email worthy.
Wednesday, October 8, 2008
SVN With A Partner
Recently I worked on my partner's project using SVN. The first thing I did was Source->Format his code in Eclipse and made changes to his comment grammar. Then I changed the default output path to build/classes to bin. That should fix the same build issue that I also had in my project which I talked about in this blog post. Then I added more descriptions for his Javadoc comments on his methods.
Working Nicely With Others
Overall I learned how to work with other programmers using SVN. This was a good experience for me since only recently have I started to collaborate with another individual on a program. Before I was basically programming on my own. Without SVN I can see many unnecessary meetings where we would have to delegate responsibility over portions of code and spend wasted time resolving conflicts. Also without Ant I predict that the quality of the code would drop and people would get annoyed at their partners for making them do extra work because a change might have broken something in the program. With Ant it has made it easy to ensure that when I commit code to SVN, that code will run properly. In the future I would definitely use SVN and Ant with collaborative projects.
Having another individual look at my code helps to reveal mistakes I might have made or problems that I couldn't find a solution to no matter how much pound my head on the keyboard. There are times where I had a partner who was at the same place as I was in the assignment. Those times can be a good way to learn from someone else's mistakes especially during pair programming sessions in class.
Working Nicely With Others
Overall I learned how to work with other programmers using SVN. This was a good experience for me since only recently have I started to collaborate with another individual on a program. Before I was basically programming on my own. Without SVN I can see many unnecessary meetings where we would have to delegate responsibility over portions of code and spend wasted time resolving conflicts. Also without Ant I predict that the quality of the code would drop and people would get annoyed at their partners for making them do extra work because a change might have broken something in the program. With Ant it has made it easy to ensure that when I commit code to SVN, that code will run properly. In the future I would definitely use SVN and Ant with collaborative projects.
Having another individual look at my code helps to reveal mistakes I might have made or problems that I couldn't find a solution to no matter how much pound my head on the keyboard. There are times where I had a partner who was at the same place as I was in the assignment. Those times can be a good way to learn from someone else's mistakes especially during pair programming sessions in class.
SVN and Google Project Hosting
Subversion (SVN) is way for multiple developers to work on a project while minimizing conflicts. While not perfect, I think it's one of the best ways to manage a project, at least compared to the alternatives like RCS and CVS. For my project I used TortoiseSVN as my SVN client.
Using SVN
For the "Stack-Johnson" project located at http://code.google.com/p/stack-johnson/ I replaced the println in the catch blocks of the testIllegalPop and the testIllegalTop methods with assert. I didn't think it was right to have println that didn't do anything in those spots. I found it difficult looking for changes I could add to the code because it already passed verification previously.
Google Project Hosting
I also created my own Google Hosting Project at http://code.google.com/p/stack-johnzhou/. I had help from Aric West during the in-class lab setting it up. I had issues running verify.build.xml on my project, which I later corrected. It seems that the last time I worked on my project I was focused with getting 100% coverage with Emma so I wasn't too concerned with getting it to pass verification.
Discussion Group
I also created a discussion group for the project located here: http://groups.google.com/group/stack-johnzhou-discuss. I had issues with updates getting sent from the project to the discussion group until I found that I using stack-johnzhou-discuss@googlegroups.com for activity notification when I should have been using stack-johnzhou-discuss@google.com.
Using SVN
For the "Stack-Johnson" project located at http://code.google.com/p/stack-johnson/ I replaced the println in the catch blocks of the testIllegalPop and the testIllegalTop methods with assert. I didn't think it was right to have println that didn't do anything in those spots. I found it difficult looking for changes I could add to the code because it already passed verification previously.
Google Project Hosting
I also created my own Google Hosting Project at http://code.google.com/p/stack-johnzhou/. I had help from Aric West during the in-class lab setting it up. I had issues running verify.build.xml on my project, which I later corrected. It seems that the last time I worked on my project I was focused with getting 100% coverage with Emma so I wasn't too concerned with getting it to pass verification.
Discussion Group
I also created a discussion group for the project located here: http://groups.google.com/group/stack-johnzhou-discuss. I had issues with updates getting sent from the project to the discussion group until I found that I using stack-johnzhou-discuss@googlegroups.com for activity notification when I should have been using stack-johnzhou-discuss@google.com.
Wednesday, October 1, 2008
The Limits of Test Coverage
Having a partner for this program made it easier to sort through the issues that I was having, especially since my partner was farther along than I was. In this case my partner was Creighton Okada and from him I picked up on some of the assert methods that I should be using.
Adding Failure
In order to create a unit test that failed I added a method to the test code that will check the size of the array. I intentionally made it so the expected value was less than the actual size to make the test fail. When Emma was ran, it reported 100% coverage but when Junit ran the test code it failed.
Conclusion
This shows that there are limits to Emma. It appears that Emma only really checks whether the lines in the code is executed and not whether the test cases are actually valid. Pair programming helped me but I think it would've been better if we were both in at the same point in our progress.
The project can be found here.
Adding Failure
In order to create a unit test that failed I added a method to the test code that will check the size of the array. I intentionally made it so the expected value was less than the actual size to make the test fail. When Emma was ran, it reported 100% coverage but when Junit ran the test code it failed.
Conclusion
This shows that there are limits to Emma. It appears that Emma only really checks whether the lines in the code is executed and not whether the test cases are actually valid. Pair programming helped me but I think it would've been better if we were both in at the same point in our progress.
The project can be found here.
Using Emma to Improve Testing Coverage
When I was given this project the current coverage was at ~80%. As some point while working on it, eclipse was giving me errors on certain lines of code. Even after undoing the code back to the original it was still giving me the errors. It turns out that the project required that I went to Project->Clean in order to discard build problems.
Code Changes
In TestClearStack.java I added a line to test getTop(). I had issues with the isEmpty method until I found out that I had to test both true and false cases. For TestStack.java I added a test for toString. I had some difficulty parsing what was supposed to be outputted so I used a println to check. Then I added a test for the top method in case it threw a EmptyStackException.
Conclusion
I think that these changes improved the testing of the code. It's good to know that every line of code works as it's suppose to. It doesn't make a code foolproof though cause there can be elements in a program that one might not think of testing. 100% percent coverage may mean that you touch upon every line of code but it might not consider necessary features that might be missing or incidents that might cause errors.
You can find my build here.
Code Changes
In TestClearStack.java I added a line to test getTop(). I had issues with the isEmpty method until I found out that I had to test both true and false cases. For TestStack.java I added a test for toString. I had some difficulty parsing what was supposed to be outputted so I used a println to check. Then I added a test for the top method in case it threw a EmptyStackException.
Conclusion
I think that these changes improved the testing of the code. It's good to know that every line of code works as it's suppose to. It doesn't make a code foolproof though cause there can be elements in a program that one might not think of testing. 100% percent coverage may mean that you touch upon every line of code but it might not consider necessary features that might be missing or incidents that might cause errors.
You can find my build here.
Tuesday, September 30, 2008
Stack Overflow Review
I recently took a look at http://stackoverflow.com/ which is a site that computer programmers can go to ask for help. I have some thoughts on the site. I thought the reputation and badge system was a very clever way of getting more people to respond to questions and to get good answers out of people. It's a good thing that there's a way to vote on whether the answers are good or bad. The content is provided by the users and there's a system in place to control the chaos of the masses. As for how well the site provides answers, I just stumbled onto this relevant question from the site. In it is a discussion on the quality of the answers. It appears that providing a detailed question will increase the likelihood of having a good answer. The user was annoyed by Google responses he recieved for some of his questions. Seems like the best way to avoid that is to also add to your question what you have tried that didn't work.
In terms of structure this site reminds me of Digg.com and other similar sites. Through OpenID, I used my Blogger website as a login to the site. I'm curious about how it can ensure that I'm the person who I say I am. It would be nice if the questions were placed in categories like C, C++, and Java to give it more of a structure than just relying on tags. It's nice though that the questions can be categorized by newest, hottest, votes , active, unanswered.
In terms of structure this site reminds me of Digg.com and other similar sites. Through OpenID, I used my Blogger website as a login to the site. I'm curious about how it can ensure that I'm the person who I say I am. It would be nice if the questions were placed in categories like C, C++, and Java to give it more of a structure than just relying on tags. It's nice though that the questions can be categorized by newest, hottest, votes , active, unanswered.
Wednesday, September 24, 2008
Using Ant
Introduction
The focus of this assignment was to use QA tools to debug some sample code. For the assignment I used Ant along with Checkstyle, PMD, FindBugs, and JUnit.
Installation
First of all, I downloaded Ant, Findbugs, Checkstyle, JUnit, and PMD along with stack-6.0.911.zip. I unzipped all the files to a single directory. One of the biggest obstacles that I encountered was just installing the tools that I needed. I often found myself googling for instructions. Once I got the first few tools installed the rest of them were easy cause they followed similar steps. Much of it had to do with setting up environmental variables.
QA Testing
Afterwards I ran through the gamut of tools to test that if they all worked. The commands that I used were:
Conclusion
At first I was fustrated at getting all these tools up and running but now after using them I realized that these things will make my life much easier. I wouldn't be surprised if one day I would abhor the thought of not being able to use them in my programming.
Here is a distribution of the project: stack-johnzhou-6.0.924.zip
The focus of this assignment was to use QA tools to debug some sample code. For the assignment I used Ant along with Checkstyle, PMD, FindBugs, and JUnit.
Installation
First of all, I downloaded Ant, Findbugs, Checkstyle, JUnit, and PMD along with stack-6.0.911.zip. I unzipped all the files to a single directory. One of the biggest obstacles that I encountered was just installing the tools that I needed. I often found myself googling for instructions. Once I got the first few tools installed the rest of them were easy cause they followed similar steps. Much of it had to do with setting up environmental variables.
QA Testing
Afterwards I ran through the gamut of tools to test that if they all worked. The commands that I used were:
- ant clean compile
- ant -f checkstyle.build.xml
- ant -f dist.build.xml
- ant -f findbugs.build.xml
- ant -f javadoc.build.xml
- ant -f junit.build.xml
- ant -f pmd.build.xml
Conclusion
At first I was fustrated at getting all these tools up and running but now after using them I realized that these things will make my life much easier. I wouldn't be surprised if one day I would abhor the thought of not being able to use them in my programming.
Here is a distribution of the project: stack-johnzhou-6.0.924.zip
Wednesday, September 10, 2008
Thursday, August 28, 2008
FizzBuzz
The program for FizzBuzz required that all of the numbers from 1 to 100 be printed out, except when the number was divisible by 3 it should print Fizz, when the number was divisible by 5 it should print Buzz, and when the number was divisible by 3 and 5 it should print FizzBuzz. It took me about 5 mins to get the correct output since the assignment felt "timed" and another 20 mins just messing around in Eclipse, resulting in the following code:
Source Code
Didn't have much difficulty with Eclipse since I've been using it for a while. It was probably made easier to accomplish since I witnessed it done in class. I first started working on the main and the "for" control statement, then moved on to make the method "getValue". The first time I did this in class I didn't read the instructions entirely so I was making the "FizzBuzz" conditional statement last and had to redo my if-else statement chain. This time I made sure I started that first. Another issue came up where Eclipse wanted me to make the "getValue" method static, probably because I was calling it within the same class. The last problem was in the formatting where the output wasn't line by line so I just added newline statements to the print.
Conclusion
It was nice to know that I could pass this screening test for decent programmers. I found that I should read the entire problem before jumping headlong into programming. From reading the other blogs, I found that I should have probably used a print line in the for loop and passed Strings to it from the getValue method.
Source Code
Issues
public class FizzBuzz {
public static void main (String [] Args){
for(int i = 1; i<=100; i++){
getValue(i);
}
}
public static void getValue(int i){
if((i%3 == 0)&&(i%5 == 0)){
System.out.println("FizzBuzz");
}
else if(i%3 == 0){
System.out.println("Fizz");
}
else if(i%5 == 0){
System.out.println("Buzz");
}
else{
System.out.println(i);
}
}
}
Didn't have much difficulty with Eclipse since I've been using it for a while. It was probably made easier to accomplish since I witnessed it done in class. I first started working on the main and the "for" control statement, then moved on to make the method "getValue". The first time I did this in class I didn't read the instructions entirely so I was making the "FizzBuzz" conditional statement last and had to redo my if-else statement chain. This time I made sure I started that first. Another issue came up where Eclipse wanted me to make the "getValue" method static, probably because I was calling it within the same class. The last problem was in the formatting where the output wasn't line by line so I just added newline statements to the print.
Conclusion
It was nice to know that I could pass this screening test for decent programmers. I found that I should read the entire problem before jumping headlong into programming. From reading the other blogs, I found that I should have probably used a print line in the for loop and passed Strings to it from the getValue method.
Subscribe to:
Posts (Atom)