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.

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.

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.

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.