We continue our work with DueDates and making the system fully operational. For this evolution of development the group needed to implement changes from the peer review, add a sorting mechanism, include the Hawaii State Library, and test all implementations.
Team Purple
As a group the team went through the same process as in version 1.o we felt meeting every weekday for at least a hour was most effective. Meeting on weekends is difficult for the team because of family and work issues. At every meeting the team would talk about what needed to be done with the project. Usually John would think up something new or find a way to modify the code. We did our best to assign the work as evenly as possible. Although some tasks with DueDates 1.1 were more difficult than others. For version 1.1 John wanted me to take the lead role however, due to the complexity of the project and time constraints I had to hand the reins back to John. The approach in which Team Purple is using in my opinion works quite well. My feeling is the more time developers spending working together more the system improves.
1.0 Versus 1.1
Starting a project from scratch is much easier because you do not have that excess baggage of code that needs attending. After the code review and performing some modifications of our own. The project became much more difficult to adjust because we still had to fix or modify the code and still maintain the integrity of the previous version. I found John and myself making constant revisions to the unit tests after discovering modifications to DueDates.java was not working the way it was intended.
The Code
We were able to meet all of the specifications for this weeks assignments however, I think the system is not as functional compared to other teams. DueDates does not have an user interface which is due to time constraints we wanted to make sure version 1.1 met all of the specifications before making additions.
The Issues
One of the biggest hurdles in DueDates was the sort option, when the user invoked -sort[due date or library] the library books should sort in the order of the due date or library. Initially I was going to implement some kind of sorting algorithm. However, Professor Johnson suggested using the Collections.sort method built into the Java library. I went with a Comparable interface that takes in the date, book information, and library code. But the issue with using the Comparable interface is overriding the equals() and hashCode() methods. I have never done an override of the equals or hashCode methods and it took a while to figure out what I needed to do and also John lent his expertise in the matter.
@Override
public boolean equals(Object obj) {
if (obj instanceof BookInfoRecord) {
BookInfoRecord pair = (BookInfoRecord) obj;
return pair.getDueDate().equals(this.dateDue) && pair.getBookTitle().equals(this.bookTitle);
}
return false;
}
/**
* Overriding default hashCode.
*
* @return Returning a unique BookInfoRecord hashCode.
*/
@Override
public int hashCode() {
return this.dateDue.hashCode() + this.bookTitle.hashCode();
}
For this week's version of DueDates we were introduced to Continuous Integration using Hudson. The teams got to park their project on Professor Johnson's server. If you have never used Hudson or Continuous Integration, it is like a pet cat or dog if you do something it does not like it will let you know, which can be a letdown. The development team has to always remember to verify before committing and building. Not verifying before a commit should be considered a mortal sin because you hate to see a red dot and rain clouds, which means your current build failed.Keeping continuous watch on a project's condition is good and bad. The good thing about Continuous Integration is that everyone involved with the system is always aware of its current condition. The team knows the condition of the build, who caused the failure of the build, and why it failed. The bad thing about Continuous Integration, in my opinion is that unnecessary need to keep the sun up. A developer can become obsessed with striving for a blue dot and the sun that they lose focus on the project.
Improvements/Conclusion
To improve my effectiveness, I have to take on more responsibility in the development. With version 1.1 more of my code made it into the distributed version. However, I still would like more lines code making into the next distribution and the only way to that is to continue programming.
I feel with each week I am improving as a programmer I am starting to see it in my code and problem solving. But I still have a long road in front of me I am no where near the likes of John or Ronn.
