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.
Subscribe to:
Posts (Atom)