The Release of Due Dates Version 1.1 [team gold]

For the last week and a half, my partner Scheller Sanchez and I have been working on Due Dates Version 1.1. This new version has many new features compared to the last one, including support for the Hawaii State Library, a sort option, as well as a within option. All in all what ended up happening to our original code was a lot of redesign, a lot of review, and then even more redesign. Visit the project homepage to check out how it turned out.

VERSION 1.1 DESIGN

A lot has changed in the design department of our Due Dates implementation. Some of the things we initially made for future extension, like the LibraryVault class, we found were obsolete for this version because they were not abstract enough. For this very reason, I redesigned the overall structure a lot, first by putting all the methods for every library in the LibraryVault class, and then by making the LibraryVault class an interface for each separate library to implement from. This, I think turned out to be quite efficient as one can now add libraries easily based on the interface.

Another big change in version 1.1 was the creation of the ItemDue object that holds information about a borrowed item. Using this object, we were able to create an overall List of all the items that were due, allowing the program to sort through them, as well as perform other functions on them.

Also, Due Dates version 1.1 uses the open source ArgParser libraries to parse the command line arguments. These libraries are super useful in specifying command line options and ranges of certain arguments. Using the argparser definitely added to the robustness of the overall system, and it will allow for future additions to the program as well.

TIME CONSTRAINTS WITH VERSION 1.1

Since the release of Due Dates 1.0, I have been loaded with huge amounts of school work. In the last week and a half I not only had two midterms, but two large midterm projects due, not including Due Dates. For me, this was the main thing that slowed progress down on developing the system. I really spent all my extra school time working on Due Dates and it still was not enough.

What I had to do to really get things done was reserve certain days for working on Due Dates, and just work extra hard on it during these times. Although it was not the best system for doing things, it worked out. It was also nice that the system was reviewed twice in this time, helping me to narrow down what the most important things were to do.

COMMUNICATION PROBLEMS AND GROUP PROCESS

Another thing that changed since the last release of Due Dates was communication between our group. It turned out to be much, much harder to meet up in person this week since Scheller and I both had huge amounts of other work to do. By last week wednesday, the original date for the release of the system, he was still unable to help out on Due Dates because he was stuck working on another project. It was hard to collaborate on things because of this.

When we met in person a few times we went over some issues to do as well as some design problems we had to solve. This was good, but it was far from planning everything out. At some point last week I realized I had to just start trying out my new design ideas for Due Dates version 1.1. This was not efficient since I was the only one doing things, and because of this I had to redesign the program a few times over. Things didn't run as smoothly as they did with the release of version 1.0.

Sometimes it took awhile to contact Scheller, but eventually I would get some sort of answer. Luckily we could communicate via instant messages, and luckily we were using configuration management software. It could have been worse. The truth is this version of Due Dates probably could have been better if we had worked more together on it. We did our best for the time period, and I tried my best to release the program up to specifications. I hope for the next release of the program I will be able to meet up with my group a lot more in person. That seems to be the best route for creating collaborative software.

WORKING WITH THE HUDSON SERVER (Continuous Integration)

For the development of version 1.1 we had access to the 'Hudson' server, which is used for the continuous integration of our system. This was, to say the least, really, really, really useful. I could not believe how many times a build would fail on there when I was positive I just checked it on my home machine. On one occasion, I would fix some problems that were found and that would cause even more problems (this had to do with declaring 'private final static' variables and the order of those words). I would commit thinking that everything was a-okay, but the build would fail and hudson let me know each time. Having a back up check using continuous integration is essential.

On the other hand, it was a bit much to always have the system build on Hudson. On many occasions I wanted to commit my code to the server for my partner to look over but the code did not pass verify due to QA errors that popped up. I would always end up spending a long time fixing these errors, when all I wanted to do was commit the code I had so far to show my partner, regardless of the errors. For a while I ended up committing code that would fail the build because of this. That's why we probably still have 'cloudy skies' on hudson.

FINAL THOUGHTS

Overall, working on Due Dates version 1.1 was a lot more of a challenge compared to version 1.0. There were a lot of factors that caused this (time constraints, group process, etc), but I still believe the final outcome turned out great. The program runs nicely now and has all the functionality needed. It is now very extendable too! Developing the next version of the system will be interesting.

Some of the other teams also did great implementations of Due Dates for version 1.1. One worth checking out is Due Dates (Team Silver). I did a review on their system and it is just really awesome. Watch out for the next version of Due Dates coming soon...

Software Review Part Deux

After much time was spent re-working and changing the Due Dates [Team Gold] system to include new standards, Scheller and I were assigned to do a software review on Team Silver's Due Dates program, as well as have our system reviewed by Team Orange. This turned out to be a real eye opening experience for me, as I saw what other groups were capable of and what could be improved on our teams implementation. Since last weeks software review, I didn't really know what to expect since I was reviewing a new groups system.

REVIEW TEAM SILVER

Ronn Reeves and Robin Raqueno were the developers of this Due Dates system and it really was a pleasure reviewing their system. My first impression after viewing just their homepage was WOW. 

I mean look at that page! Compared to what I saw last week in other projects and what my own project homepage looks like, I was blown away. This project was definitely portrayed in an informative and professional way. I loved this. But how did the actual code fair?

After downloading their source code and checking it all out, I was not surprised to see top notch code. Their package structure was organized nicely, as was their class structure. Everything functioned correctly and was done really well. I found their system could really be extended by anyone, even the user. This was because libraries were added through an xml file where the data for each library was held, and this could be updated. I was very impressed by this function. It really was a task to find anything serious to comment on in their code, but I found a few things here and there worth noting.

What was interesting was to see how this team implemented ArgParser, and open source command line parser, since we had also implemented that in our system. Not only did they implement the parser to work for correct arguments like -uhm 12345567 wolff, they made it work for arguments without the library declaration, something more like 12345567 wolff. This was a pretty cool thing I thought, since it would minimize user errors when adding command line arguments.

Overall, doing this review was really nice. It was intriguing to see how a top notch team implemented their system. I think I was able to help as well, if not with their actual code, but with their user/developer guides which were missing a few important things (Their results). In addition to all of this, I got some new ideas for our system.

TEAM ORANGE'S REVIEW ON OUR PROJECT

A review on our Due Dates system was really needed and luckily we had an excellent review team do it - Team Orange, Daniel Tian and Aric West. Our initial review page outlined everything we wanted to have reviewed and they responded to basically everything we asked for and more. I was expecting comments on our class structure, testing and a few other areas, but they found some things I would have never found on my own that were of equal importance. After refactoring our system to have the DueDates name instead of the DueDatesGold name, I forgot that this screwed up jar creation and basic building capabilities. They caught this. There were also some really great comments on the code itself. They gave some great suggestions on some general design issues that needed to be addressed.

I think it is so important to have others try to build and run your system, especially when your dealing with an Open Source Software development project. Many things like jar creation work perfectly on our computers where we've developed everything, but once someone else tries to do these things on another machine, there are errors. Having a review done like this is great for pointing out these errors.

GOOGLE PROJECT HOSTING REVIEW

Doing this review was fairly similar to doing it the last time. Adding comments to peoples code was easily done and check-out was easy. However, I found it much easier to read the comments on our system, as they are all logged on one overall page. Something funny that did happen though was when Daniel Tian did his review and half of his comments appeared on r39, while the others appeared on r40. We couldn't figure it out.

A function I would love google to implement is something that sends you the info about your review that you've done. I have no way of accessing the review I did on Team Silver's system. The only way would be to get a link from them. It could be made easier if that were automated, or if there was a dedicated page for it all.

Overall, this software review was a great experience for me. I sort of got inspired from looking at Team Silvers code, and Team Orange really gave our group some good ideas for improving our system.

Time For Review! Software Review that is...

After working with Scheller Sanchez on the first release of Due Dates, I was ready to take the next step in expanding and enhancing the overall system. Since it is still in the first version, Due Dates is far from being a perfect system. There are many things to improve on and a lot of things to extend the program to. Many times, an efficient way of evaluating everything is by performing a series of reviews on the program, pointing out what does not meet requirements and what design features could be improved.

Doing Reviews

I participated in three reviews - one for duedates-blue, one for duedates-orange, and one for duedates-green. I found this to be a really insightful experience. As Scheller and I designed the structure for duedates-gold, we often wondered how other teams were laying out their system. I personally really wanted to see how far other teams were taking it. By doing these reviews, I got to see just that.

It was really interesting to see how teams structured their systems. To see certain functions - like the program menu function in duedates-blue - actually implemented was extremely useful. I personally had been thinking about implementing that sort of function on our version of Due Dates. Now, I can better judge the use of a program menu in our version. Another thing that intrigued me was seeing how different groups did different things. For instance, one of the groups I reviewed had large amounts of code for parsing the command-line input. Another group had a relatively small amount of code for this, yet surprisingly they did basically the same thing.

For some of the teams I reviewed, it was easier to pick things out to comment on, and for some teams it was a bit harder. Nevertheless, I found some overall problems I'm sure others had found as well. One of these things was Exception handling. Every project I reviewed just showed a stack dump upon exception. This is not good.

Receiving Reviews

The Due Dates - Gold system was reviewed by:

• erinjuneilkim
• creightonokada
• aricwest
• jnancheta
• anthony.m.du
• john.km.zhou

What was cool about all this was that even though Scheller and I specified specific things for each member to look at on our Review.wiki page (documentation, testing, class structure, etc), most of them went out of their way to inspect some of the other code as well. We got a lot of great feedback, good and bad, about our program design and how are program fairs in general. I was surprised to see comments about things I would have totally missed on my own. A good example of this is the command line program requirements. Scheller and I both forgot to integrate the -uhm command in our program but luckily Aric West commented about it.

I am usually really strict about how I program things. However, I do let things slide from time to time and I forget about them. It really is great to get an outsiders perspective on the internals of the program. Having these reviews done on our program can only improve what the future system will become.

Problems with Google Project Hosting's Review Tool

I couldn't believe how many problems I ran into using Google's built in review tool. As a reviewer, my main problem was publishing my so-called 'draft comments.' Half the time there was not a 'publish your comments' link on the page and I was left stuck, wondering what to do. On the first review I did, this occurred and I navigated back a few pages to see what would happen. Somehow by doing this I lost all my draft comments and I had to re-do them. After that instance, when there was no publish link, I realized the only way to fix it was to navigate to different pages until one did pop up. This actually worked well since my comments didn't disappear anymore, but it was a real hassle at first.

I also had big problems trying to see the comments that were left on our source code. This is actually something I'm still trying to figure out! It seems like only some of the comments made actually show up when you browse to the file, and others are left hidden. All six reviewers did post reviews, but they didn't all show up together. When I first looked at the source code, there were only reviews from anthony.m.du, john.km.zhou, and aricwest. In addition, these reviews were sometimes there and sometimes not there. It was really confusing! The way I found the other reviewer's comments was through a link in one of the gmail notifications, of which I only received for two reviews. This link brought me to some other page that listed all the comments on their own. What's better is that aricwest's comments were on both the source code side and the comment page. I have no idea why it does this but I'm just glad I figured out a way to see them all. 

What I learned from it all

After doing reviews, receiving reviews, and dealing with Google's review tools, I can now see the importance of a software review. For the past week I have been trying to think of ways to improve the structure of Due Dates gold. Now I think I have a better idea of what needs to be done. The reviewers of our code really help in creating a better system overall.