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.

Creating My First OSS Project: Due Dates

PROJECT: Due Dates

PROJECT PAGE: http://code.google.com/p/duedates-gold/

TEAM: Tyler Wolff and Scheller Sanchez (team gold)

OVERALL CONCEPT: Due Dates is a program that will go and retrieve information about various items that you (the user) have borrowed, including their due dates. The application can be used for library books, videos, or anything else with a due date, and it can be extended to any source that has an online login. As the tag line states - "Never pay a late fee again!"

project homepage view

THE SYSTEM

For the first version of Due Dates, my partner, Scheller and I decided to implement a system for use with only one library - the University of Hawaii at Manoa Library.  This would enable any UH student to use our application to view what books they have borrowed and which ones are due, thus making it a useful system (Prime directive #1). We decided to do this with the addition of some extendible features to expand the functionality in the future. For this stage of our program, it would include these classes.

• LibraryVault - an object to hold information about a given online library system. Object holds the site URL, the login form's name, and the two parameter names within form.
• DueDatesGold - this is the main class that uses LibraryVault objects in conjunction with user defined id/passwords (or any type of login information) to gather information about borrowed books and their due dates.

This initial structure, however simple, would give great functionality into accessing UH Manoa's library system, as well as allow for some future program expansion. The way we see it, since there is a LibraryVault object, many libraries can be set up initially from outside sources, like a file or even a database. Because of this, methods like the login method can then be used for multiple library systems, thus abstracting the code a little more.

However, because our first version of Due Dates only deals with the UH Manoa Library system, the overall code is not simplified that much.  In addition the program works through the use of command-line arguments (the UH student's ID and last name). This means, it runs from a terminal with no interface capabilities. The output is just as informative though, and it can be run very simple through the use of a jar file. Anyone can download and use it (Prime Directive #2):

Sample Program Output

GROUP PROCESS

Sheller and I decided early on that we would communicate everyday about the project, whether it be in person or through the use of an instant messaging program. What ended up happening was that during the last week, we met up almost every other day in person for a couple hours, to talk about the program and work things out. This was definitely to our advantage and it worked well for both of us.

At our initial meetings we planned out the system while issuing specific tasks to each other on the project page. We even met once in Hamilton Library so we could borrow some books (for program testing!). In some of our later meetings we programmed together or edited existing files. What I found interesting was how much can get done while working together. We set up the project page instantly and put up issues just as fast. Its much easier to program as well because you can physically show the other person your code without having to send them the file. A big initial problem we had was getting Eclipse to recognize the HttpUnit classes. We worked together trying to fix it and finally found a temporary solution to the problem. This was later resolved in class.

Something that we did not do a lot at our meetings was commit files to the project repository. I don't know if this was because we never got to a final stage with our code or because we just never thought about it, but it probably would have been more efficient to commit/update code right then and there.  Overall though, it was really nice working with Scheller on this project. We both did what we planned to do and everything ran smoothly. 

SETTING UP THE PROJECT

Hosting the Due Dates project on Google Code was really great. It allowed for really easy collaboration between Scheller and I. Creating a public project page for Due Dates was something I really enjoyed. It is sort of like marketing it as a product and making it accessible to everyone (Prime Directives #2,#3). I gained some experience making a wiki page for Developers to build and modify the project. Since the project does have external dependencies like HttpUnit, I had to create informative instructions for installing and using those tools. I used lots of screen captures and descriptions to explain it all.

The issues log was a great function of google projects that I did not previously know about. After adding issues to the list, Scheller and I were able to go through each of our specific tasks, noting when they were completed. It is like a complex to-do list that really makes it easier to reach project goals as a group.

TESTING THE SYSTEM

Testing for the Due Dates system was a little different than past tests I have done. I personally was responsible for testing the login method and the method that gathered data from the UH Manoa library. I tested for correct login information, as well as incorrect login information. For the due date information, I made test cases with users who had no books borrowed and with users who did have borrowed books. I made sure content was correct and exceptions were caught. 

It was interesting building a test suite from the ground up as I have never done that before. I've only ever added to other test classes. The things we were not able to test for were external dependencies like internet connection, internet errors, etc. This could be done in the future though.

FUTURE IMPLICATIONS

One of the coolest things about the Due Dates program is its extendable capabilities. Scheller and I talked about this a lot since there is so much that could be done to enhance the system. For one the system could employ a better command-line system as well as support multiple libraries. It would be really cool too if a user was able to add their own libraries without extra coding on the programmers side. In addition, some sort of graphical interface would be great. It would make the program look even better.

CONCLUSION

Overall, the building of this project as a group was a eye opening experience. I have never really done this sort of thing programming before and it really showed me the possibilities of open source software development. If many people were all working on this project at the same time, who knows how great the program could become. And it is all done so easily with Google Project Hosting and subversion technology. Hopefully in the future this project can really expand and develop.

Further Exploration in Configuration Management

After working on a professor's project and creating my own stack project (link to past post), I thought it would be interesting to collaborate with another classmate using google project hosting and subversion. Usually when I've worked with others in the past, everything is planned out before each person programs or edits code in order to reduce code clashes and redundancy. Configuration management was never a part of these projects and I have to say it was a challenge sometimes. 

A good example of this was when I was working on the codeRuler project with Daniel Tian. He and I would send each other source files that often would not match up with each other, creating problems with the program on a whole. It was rather tricky to figure it all out. Even deciding who would create the final build was a bit confusing as we both had slightly different versions. It would have been nice to see how the workflow would have been affected with configuration management tools.

COLLABORATIVE SOFTWARE DEVELOPMENT

For this, I decided to collaborate with Jeho Jung, a fellow classmate also working on his own version of the stack project. After I was added to his project on google project hosting, and he was added to mine, we ventured out to verify each others project. I couldn't believe what happened next.

Upon check out of his source code, the ant verify process resulted in a 'BUILD FAILED.' And if you can imagine, the same thing happened with my code when he ran the verify script on it. I was really, really confused about it all since I swore I had verified it all before hand. However, what I failed to remember was when I slightly edited a test case before check-in. That's what screwed it up for my stack project. Jeho's project had a similar problem but his code had errors mainly from missing test cases.

Since we were working on each others code in pair programming style we each went through each project and fixed the problems accordingly. It all went smoothly and either of us were able to update the others project on google code. It's really cool how it all syncs up. I imported his project into eclipse and updated some of the javadoc comments. Then I checked in the changed files to his project repository and it was all set.

He did the same with my project and after verifying the build, everything was fine. I have to say it was an extremely streamlined process. For one, using CM tools makes working together on a project extremely easy and efficient. We could switch computers and still update the same project simultaneously. The subversion tools built into google project hosting make this super simple. Its great! It is also nice to get automated messages whenever a project you're apart of is changed (through the use of google groups).

INSIGHTS

Collaborative programming with another student really opened my eyes to the simple problems that can occur when programming by yourself. A big surprise for me was having a program that I thought could build successfully fail when another user was checking it. Who knows what sorts of things I could have missed on my own. It's really useful to get another programmer to work with so these things are found and fixed.

Collaborative programming also showed me the importance of using configuration management tools like google project hosting and subversion for development. Code review and production was instantly streamlined with the introduction of these tools. If only I had used these tools while creating the codeRuler program with Daniel Tian. Things could have been done much simpler and more efficiently. Configuration management is essential to collaborative programming projects.

If ever I work in a group setting again, I will not hesitate to use subversion and google project hosting. I'm sure my other classmates would agree. Overall, it really seems to me that the use of configuration management tools along with other tools like those for quality assurance, make for more stable builds and more efficient system. I plan to use them all in the future.

Experiences with Configuration Management

During my years as a computer science student I have never used configuration management tools, though I've known about them. I've never used them because they were never required in any of my classes and because frankly, I've never had a real use for them. Most of the programs I have written have been small and have been developed solely by me. But when are these configuration management tools essential for maintaining a project?

SUBVERSION

Before diving into subversion, I decided to think about some of the basic instances where using a configuration management program is useful:

• When groups of people are working on a single project
• When there is a system with multiple versions
• When working on a large system
• When projects branch of to separate versions  

Since I use Mac OS X, I could not use the 'ultimate' subversion client, TortoiseSVN available to windows users. What I did was install another good subversion client called SmartSVN. I found it extremely easy to set up, and after making a new directory on my system, I connected directly to the stack-johnson project on google project hosting. I then checked out the version in the online repository to get the most updated version of the program on my local machine. SmartSVN makes everything very simple and pretty intuitive. 

the smartSVN interface with the stack-johnson project view

To test out the other subversion commands I corrected some of the test code in TestStack.jav by adding @Test to some of the test methods. This is one of the first things I noticed in the stack source code and it definitely improved the system on a whole by enabling those methods to run in JUnit. After verifying that the project worked fine, I committed my change in TestStack.java and bam, my updated code was a part of the main line project.

That is what I think makes using a configuration management tool like subversion so cool. If many people are all working simultaneously to optimize some system, it makes things go really fast. Within a couple hours there were updated test cases and Javadocs in the stack program and it was much better than it was initially. Tools like subversion are essential for group work. It makes things so much easier. I can also see now how it is essential for versioning purposes. Its like an intelligent central backup, stemming from many sources.

GOOGLE PROJECT HOSTING

In order to get even more experience in using project hosting and subversion I set out to create my own stack project on google hosting. Google always impresses me with their different applications and technology. It seems like they have created everything anyone could ever need on the web (including this blog site!). In addition, everything is done so simply, while maintaining powerful functionality. Google project hosting is no exception to this. 

I went in and created my own personal project called stack-tylerwolff. It took about 2 seconds to do the initial set up and I was then ready to check in my program to the web. What was a bit

confusing was adding files to the project. I had to start up SmartSVN, check out the project into a directory (empty project), add files to be version controlled in that directory, and then check-in those files to google project hosting. This took me awhile to figure out but I eventually got it all to work nicely. Once everything is synced up to your local directory, check outs, updates, and commits can be done instantly.

Its really convenient that google project hosting incorporates subversion into their hosting infrastructure. On the project page you are able to view the source file directories as well as a changes list. Google makes it really easy to see everything that goes on with the program from start to finish. What's neat is that after adding Jeho Jung to the project, he was able to update and better the program from his home computer. It is really a great thing!

Overall, the hardest thing about creating a working project on google project hosting was creating a mailing list through google groups. I spent the bulk of my set up time trying to figure this all out. What I eventually realized was that I had set the group to be private, which meant group members (mainly codesite-noreply@google.com) did not have the proper permissions to post emails to other group members. When I fixed this problem, change messages were sent out to everyone added to the project and it was all good.

Subversion is such a great tool for working together on a project. Checking code in and out can be done instantly and getting updated project files is equally as quick. I can't imagine how one would work on a group project without it. In addition, google project hosting is so user friendly and easy to use. Creating projects and maintaining them through google is a smart idea. I can see now that the use of both can really optimize software engineering on a whole.