DueDates Project Review

Premise: In this posting, I’ll continue from last week’s first iteration of our class project called DueDates. This week I was tasked to evaluate three DueDates project groups and also receive seven reviews of my implementation of the same project. Again I’ll be using Google’s Project Hosting site as my primary source code versioning and issue tracking system tool.
Setup for Review: So how do I put out a package to the world for developers to critique and annotate my work without interfering with my main code-line? Well, SVN provides a concept of creating snapshots of your production line code, called “tags”. Tags are meant for production version-labeled releases of a project. It provides a workable copy of the file-system at a certain point in time of your project. This can be easily done by the commands below. *Note that this would be exactly what a reviewer needs to do prior to evaluating your work. *Also to get the BASE_URL, you may try using the command: svn info - displays the details of the current svn repo. Or svn info | grep URL for just the base url.

svn copy BASE_URL/trunk BASE_URL/tags/review_release
-m “Tagging a review release of main line”

My Review Process: Google’s Project Hosting review tools provide developers the essentials to annotate and evaluate project source code in an effective and efficient manner. It gives reviewer’s, who must first be members of the project, the ability to leave comments within the actual project source file. When the source file is finalized and the reviewer is satisfied by their comments, then they can easily publish those results to the project. After the comments are published, the owners of the project are notified by email(s) of those comments. This definitely made my job as a reviewer better, since I’ll be able to optimize my time to focus on reviewing the project code, and it gives the owners of the project immediate feedback.
Reflecting on Results: During this review process I’ve gained insight into how to improve my code as well as learn the mistakes that I’ve made throughout the course of my implementation. In many ways, I could say “I approached it all wrong,” but by the indication of some feedback, I was also doing something right. Documentation was the main thing I knew that would have to be sacrificed due to our time constraints. Therefore, people were totally oblivious as to what my project expected as an input and output. The project was a total black box, in the front, middle and back. Since I did not pay close attention to my audience, it was difficult for people (both users and developers) to use or expand my system. However, I’m glad to say that there were some people who reached out to support. It was evidently helpful and gratifying to us both. During this process, I also found a way to “switch” between production lines. The reason for this was that I needed to repair the broken tag distribution for review. Before doing this, I sent out a mass email detailing the reasons. Here are the commands to switch between the trunk and tags (it also goes the same for any directory layout that you build through SVN):

svn switch BASE_URL/tags/review_release

Pretty nifty, huh? Indeed, I thought so too. After I got done making changes to the review_release version, I quickly switched back to the trunk's main code line to continue coding on the trunk. I was surprised to notice one reviewer who really felt inspired by my implementation of an error logger (ErrorLogger.java). My first intent for this class was to just parse out the command line arguments, but it became something more along the lines of a stack dump error logging tool. It currently parses out the arguments, separates them by [args] => [options - prefixed with a hyphen] [parameters - non-hyphen parameters (actual values)]. Options are pre-populated with somewhat of a unix/linux inspired command, "-v" or "-verbose". The final feature was the ol' error handling messages (friendly or verbose) depending on the passed options. Overall there were lots of small details that needed to be worked out of the beta stages of this increment. My goal from this point on is to sculpt out the essentials of the application, make it more abstract or general, and extended upon new ideas.

A lesson learned: I wanted to express this on my last posting but it was difficult to express matters under certain time constraints. I’ll start off by mentioning about what went wrong in my group’s implementation and then how we are currently going about to improving ourselves for future increments. I would like to tag this project during this point in time, called “death by email”. My group partner and I only had one official meet outside of class during the first week of working on this project. In my opinion it was horrifying to communicate with someone for the first time and barely knowing them. We both made the mistake by not getting to know each other better outside of class. Due to this slight alienation, we caused each other to have flawed predictions of one another. These preconceptions proved to be inaccurate and misleading. It was very difficult to see whether or not a team member was having a hard time with the project or if they were suffering from other external issues. During the course of this project, I learned that you are only as strong as your weakest link. Apparently we both had strengths and weaknesses. If we had communicated better straight from the get-go, and came together to pick at our flaws, then the project would have turned out better as a whole. My project group member and I have been taking the time out of our busy schedules to do regular fact-to-face meetings that last at least 30 minutes long. We’ve started to put this into practice rather than having to deal with just emailing each other progress reports. Hopefully we’ll be better off in our next increment, this coming week.

DueDates Project (Part 1)

Premise:
I have been tasked this past week to assist in the creation of a project called DueDates. DueDates is currently a program that enables a user the ability to check the status of items they may have borrowed from one or more library systems. It is meant to generalize the interface between the user and their list of items, whether they be books, bills, tasks and etc. For this project, I will be accompanied by the following tools and source code: Google's Project Hosting, SVN, Eclipse, HTTPUnit, and sample code, DueDatesBootstrap.zip

Process:
The hardest part in any project is the process. I found it difficult at first to plan out a reasonable and consistent plan. Many times a plan might backfire or doesn't go as you'd expect, but after a few moments of reading up on the project's needs and wants, I finally came to conclude some possible project enhancements:
User Interface:
End-users are left with a couple of command line options that makes too many assumptions as to what is required by them. Another problem was that the resulting error dumps (Java Exceptions) were being outputted in a very cryptic manner. To solve this, we could suppress the messages and also provide an extra parameter to display other misc stack dumps for developers.
Functionality:
The sample code, DueDatesBootstrap only provides sufficient code to initialize, connect and grab responses over the network to a fixed number of supported library systems. We could provide general library system templates, and pass required parameters to them. This might not solve all internal problems, such as HTTP parsing, but it will provide a step in the right direction.

Execution:
Setup:
Even some practices needed to be re-iterated. I found myself needing to take the time just to refresh on the syntax of SVN. I keep getting this notion that I need to do a "svn import", but that's only when I'm locally hosting my SVN repositories. Google's Project Hosting site skips one step in the common "svn import" and "svn checkout" process that I'm used to. Another minor problem was knowing which folder(s) needed to be included on revision. In most common development environments, only the source, custom libraries and configuration files are worthy of inclusion to the repository.
Plan:
The first thing I noticed about the initial DueDateBoostrap program was its lack of "friendly" error handling. It occurred to me that possibly building an ErrorLogger for this system would be most beneficial not only for this project but also for others. My goal from here on was simple, build an error logger that simply takes in at least one (supported) option and deal with auditing the errors. Although my approach is simple, it does the job with a few left out features. This error logging system lacks the ability to audit with level of warning types. In future enhancements I would like to incorporate a more sophisticated level system that weighs the severity of an error/exception.

Conclusion:
I enjoyed taking the time to get my hands on a new project again. Here I can step back and think about new ideas that I have yet to explore and hopefully, along the way make changes to better the application as a whole. Its always important to know that there are some ideas that work for certain situations and some ideas that work for others. I have learned from the past that large projects like these amounts to the overall effort and not only the ability of one individual. I believe that in this high collaborative society, esp. for software engineers, that we are only as strong as our weakest link. Learning to accept the fact that you are not the lone programmer these days will better you for the actual development setting. The setting is ever changing, people come and go, while many of us still have to learn to adapt rapidly. This project proved to be quite a learning experience for both me and my team member.

Stack on Google's Project Hosting + SVN (Part 2)

Premise:
In this posting I will attempt to build upon where I left off from my previous entry regarding SVN and Google's Project Hosting (GPH). My experience portrayed here will both reflect the ease and comfortableness of using SVN in a group oriented setting.

Experience:
My project is currently being hosted by Google's Project Hosting and all members of the project have SVN command privileges to add, delete, or commit changes. Likewise, I could also do a checkout of someone else's project using the same command ("svn checkout...") under "Source" tab in GPH. If I've been given membership to this person's main code line, then I'll also have full write access to their master repository. This means that the changes I make locally will reflect on the live repository once I perform a "svn commit -m...". I will attempt this very concept on a group member's project. After checking out the source from the member's repository, I am given a local copy of the project. Before attempting to run the program or make any changes of my own, I ran "Ant" to assure the code that I've just checked in, integrates well without error. If errors do occur, then I'll either have to notify the discussion group or make the changes myself.
Currently the project appears to be at a solid state without any conflicts or obvious errors. The actual error didn't occur until I used Eclipse and Ant simultaneously to execute tests and run verifications. It turns out that the given build.xml file provided by this project conflicts with Eclipse's class build directory path. Eclipse assumes ownership over a folder while Ant secretly writes to that directly after each build. Eclipse complains by throwing a "ClassNotFoundException". The easiest way to fix this is to create a folder in the project directory called "bin" and modify the default classpath in Eclipse to point to this directory. You can make this slight modification in Eclipse by going to "Project>Properties", under "Source" tab and change "Default output folder". At this stage, the current changes I make here are done locally and will not yet affect the main code line until I've committed. Now I will verify if my changes work for this issue by simply replicating the steps which brought on the error. Once everything seems to work with both Ant and Eclipse, then it should be safe to commit my changes. But before committing my changes, I'll first do an "svn update" to see if the project has changed since the time I was working on my fixes. This should be done before and after every commit to ensure that your code integrates well with other project member's code and to relieve later efforts of having to resolve more difficult conflicts.
Systematic procedures to keep integrity of code in-sync with master repository:

• svn update - brings your current local copy up-to-date with the current revision
If conflicts need to be merged, then resolve these problems before continuing on.
• Make your changes on your local machine
• Run Ant's build tools to verify your code changes.
• svn update
• svn status - to see if the files you've modified are correctly marked with 'M'
• svn commit -m "some informative message about the changes" - post changes to master codeline
• Continue the process again.

Other tidbits:
You can run the command, "svn log" to view the history of revisions made on the current project. Notice the last revision is listed first and its corresponding comments regarding the changes are made right below it. Also note that the optional commands like "svn log", "svn diff -r M:N filename", or etc. can be done easily on GPH's site. Its much more convenient and easy to read compared to using terminal. In my opinion, the most useful operation is svn's diff command. GPH provides a complete visual, including a side-by-side view of both files under different revisions. I only wish that GPH had a feature to produce patches along with having the ability to do diff's. Patches would be pretty useful for situations when you do not have full control over the master repository. So rolling out your own set of "diff" changes to fix a general project issue would be useful when you need to send it to a user group or mailing list to explain about your changes. From there your patches can be determined by the owners or other members, as to whether or not your patch should be applied to the main system. GPH solves the problem of communicating with members of the group project (via Google Groups), but does not make it easy for current members of the project to apply these patches/changes.

Conclusion:
Subversion is a code-management repository that enables you to keep your source code stored on a remote server (in this case Google's Project Hosting Server) that can be accessed by multiple members/users. Subversion makes collaborating with multiple users a breeze because users can checkout copies of the source code to their local machines, make edits, and then send the changes back to the SVN server. At that point, team members can update their local copies with all the team's changes. SVN manages the changes made to each file so that you aren't automatically overwriting your co-worker's work! Even if you are the sole developer, storing your project source under Subversion is a great way to keep a remote "backup" of your code in case your development machine is compromised or if you fall victim to a situation resulting in data loss.

Stack on Google's Project Hosting + SVN

Premise:
The purpose of this post is to experience the process of building your own source code management system by using both a live server (Google's Project Hosting) and Subversion (SVN). Source code management enables project teams to effectively share and collaborate with each other while keeping track of their development process. A part of the construction process consists of using good foundation practice tools, such as SVN to help ease the pain of manual code tracking and tasking.

Setup:
1. Install Subversion
You'll need to have a copy of Subversion installed on your local machine. If you're running Mac OSX or Linux/Unix, then that'll be all you'll need. You can simply download the binaries/source straight from Subversion's site, here. Otherwise, If you're a Windows user, then I would recommend installing the latest version of CollabNet's TortoiseSVN. TortoiseSVN is an easy to use GUI version of SVN for Windows that can be interfaced (in version control) to support any filesystem item (files, folders, etc). Although the subsequent steps follow the basis of a Linux based platform, the process of login in and setting up the first checkout, add, commit, and update are conceptually the same.
2. Create a Google Project
Google's Project Hosting (GPH) is a service which enables team-project members to collaborate in an effective development environment. GPH provides project workspaces with easy to use UI member controls, issue tracking, mailing group lists (via Google groups), and most importantly Subversion. Although you are not restricted to use Google's Project Hosting, I would recommend it if you want to quickly get something up and running for your co-workers or the world to see. If your intentions are to use some other advanced remote server, then you'll have to look elsewhere for that. I'm simply portraying the use of one possible solution. If you'd rather take another approach, then here are some of my recommendations on how to approach the same level of likeness to Google's: 1) Get and install Subversion, 2) Install Apache on your server, 3) Configure Subversion to work with SSL and Apache, and 4) Install Trac - issue/task management software. The more detailed instructions can be found here.
3. Initialize: Revision 1
To get started with GPH, you're required to obtain/already own a Google account (as with anything from Google). Next, redirect yourself to GPH's site here and click on "create a new project." This will instantly create a project and provide you the necessary parameters needed to describe your project. Once all the forms are out of the way, navigate over to the "Source" tab. Here, you'll be presented by Google's nicely suggested commands to run SVN. You could now just copy and paste the following into a terminal window.
"svn checkout https://stack-anthonydu.googlecode.com/svn/trunk/ stack-anthonydu --username anthony.m.du"
Quick explanation of these commands:

• "svn checkout" - pulls the SVN tree structure (svn>(tags)/(branches)/(trunk)) from the specified server. This will only need to be done once.
• "https://.../svn/trunk/" - url of source code. It can be a remote or local server
• "stack-anthonydu" - project folder name
• "--username anthony.m.du" - google account username for server access.

Once you hit return, the GPH server will verify your credentials with a pre-generated key. You may generate a new one or use the one pre-generated key under the "googlecode.com password" link. After you successfully checkout, SVN will display a message noting your very first revision. This marks the end of possibly the hardest part of setting up your repository.
4. Adding & Committing files
Now switch to your project directory. Notice that their is a hidden ".svn" folder in your directory which stores information about the current state of your repository. The next logical step is to add files to your main code line. Use "svn status" to see which files have not yet been added or added but not yet committed. The files that have been added will be prefixed with the letter 'A', and one's that have not been added will be prefixed with '?'. Unfortunately there is no easy way to recursively add all files and subdirectories using a terminal/command line. You might think that a simple svn add * would do the trick, but this command is NOT recursive. So I looked around for a quick and dirty script that will simply add all newly, non-committed files to svn. Here's the script in its most rawest form: "svn status | grep "^\?" | awk '{print $2}' | xargs svn add"
I have made this into a command of my own to simply be called anywhere called "svnadd." This can be done by saving the one-liner script into a file and storing it into the "/usr/bin/" directory (only under Unix/Linux platforms).
For a list of commands provided by svn, you may simply type "svn help". Now that you've made changes to your repository by adding files, the next step is to commit your changes to the main repository. This can be simply done with the command "svn commit", followed by a meaningful message describing the changes you've made. In this initial process, you can name it along the lines of "project initialization."
Transmitting file data .............................................
Committed revision 2.
This marks the end of Revision 2.

I have applied these instructions to my first GPH, called "stack-anthonydu" (same project from previous blog posts). This project can be accessed, viewed/downloaded, but not modified by public users. The master repository goes unchanged unless you own or are a member of the project. Here is a link to my stack-anthonydu in all its glory.

Conclusion:
I learned that version control should be part of your daily-standard arsenal. After this brief introduction to configuring and getting a feel for Subversion commands, I was quick to appreciate its vast potential for sharing and publishing source code. In my next blog post I'll further explain my experiences using my newly committed stack project.

Stack Overflow - Programmer's Q & A Haven

What is Stack Overflow?
Stack Overflow is a web application written by collaborative programmers for programmers with programming questions. The site initially requires nothing when you first visit, but to be able to gain further editing privileges, then you must sign-in using a new or existing OpenID account. OpenID is a one-stop sign-in or sign-up account used to help ease the pain of remembering login names for different sites. Upon successfully registering for the site, you’ll be immediately given the ability to edit your personal account info, easily search for a question or answer (either by tags or textual search), and post questions or answers. Soon, after you make your first post, moderators, or users who have gained high reputation will rate the prevalence of your post given the appropriateness and popularity. You’ll be given points depending on these factors, which then will correspond to your abilities on the site. If you gain higher status in your reputation, then the site awards you the ability to edit yours and other’s posts almost like a wiki. At times you might feel that Stack Overflow is giving you a hard time, but it does it for good reasons. The most popular attraction of this site is its strict rules on postings. Since posters must stay on topic, the site’s reputation and purpose gets further established in the community. The simplicity and specificity gives Stack Overflow a name in the community of programmers as a “programming FAQ” site, rather than a sub-category amongst other contending search topics. Also, it helps eliminate the trouble of irrelevant or duplicate questions. In my opinion, this proves to be a good strategy than most other social networking sites that deal with a conglomerate set of topics, like Digg or SlashDot. Its unique moderation and rating system makes it an ideal example for newer social networking sites to follow.

What were my Stack Overflow experiences?
Stack Overflow is a "programmer's haven" for Q & A's. I have posted one question regarding the goods and bads of using more than one level nesting in Ruby on Rails. Hopefully, the question will get picked up by the community and I'll get an answer that will suit my needs.
Here's a direct link to the question: http://stackoverflow.com/questions/164520/to-nest-or-not-to-nest

Overall, I think the service will be a good addition for programmer related sites. I've definitely given this a good rating on my StumbleUpon and bookmarked it for future visits.