A Bad Review is not Failure, but Feedback

"There is no failure. Only feedback."

Some rich entrepreneur said that in one of those "get rich" schemes. I don't know think I'll be getting rich. But I think it makes a lot of sense in this situation. Bad reviews/feedbacks can feel like you're getting kicked in the gonads sometimes. Once you get over the feeling, you realize the comments really make the job easier. As the recipient, I'll know exactly what to address. The project will likely make strides for the better (if I do it correctly and select the correct areas to change).

How The Reviews Are Given

Google project hosting is a pretty sweet free service. Google allows reviewers to easily insert comments within the body of the code by double clicking the line we're referring to. All within a browser. That's like commenting on an essay but without having to double-space the lines to write between. I mean what better way to point out a problem than identifying it directly in your source code?

There was one glitch when I tried to submit or publish my comments. The link wasn't always available and only after a refresh of the page, the "Public My Comments" would appear. But after the refresh, I would have to rewrite all my comments.

The Set Up

In order for anyone to comment on the code, some settings in our project needed to change first. The first thing our group needed to do was either (1) add the reviewers to the project, or (2) allow anyone to add comments. Then, we made a copy of the trunk of a repository and put it in the tags directory. Basically this made saved the current stage of the current project, so the users can comment on it. That way we could continue to work on the project, while not having to wait for the reviews to be complete.

Giving and Taking... and Taking Some More

I was responsible for reviewing three groups (Purple, Violet, and Blue). I picked up and saw some good test cases as well as some good design. I saw ideas that I would want to add to our project. Although I tried to point out as much things as I could for improvement, I feel like I walked away with more than I put in.

If that wasn't enough, our group got some more feedback. They helped point out small issues to clean up, which is good because we want to be neat and professional. We also got comments on design, which is highly apppreciated and what I was looking forward to the most. Our design is currently using a superclass Library and all libraries extend it. We were contemplating on using an interface instead since there isn't much to inherit. With an extra voice, we have more reason to switch.

Final Thoughts

I understand the short amount of time everyone had to complete the task and I really appreciate the reviewers' efforts. As of Wednesday night, our group only received four out of the six (missing: Flestado and Sanchez) reviews we expected. I previously overlooked one because it was the posted to an earlier release (r29 vs r28). I am pretty sure I didn't see the other ones though. I looked in all releases since Sunday.

I hope we end up with the remaining reviews regardless if they're just restating what others said. To me, if there are that many people that feel a certain way on a topic, it should be taken highly into consideration.


Things to Improve Next Time Around:

I need to take note of the "publish my comments" link before I start commenting too much. Rewriting all of those sucked. I noticed I forgot to add the google discuss group email in the event of code reviews. Man that made it hard to locate comments. For future reviews, it should be better.

DueDates

"Two Heads Are Better Than One"

That basically sums up the experience for DueDates. Any problem I had, I felt less worried than usual because I had someone else to consult. Someone had my back and I had theirs. My partner this week was John Zhou.

The Task This Past Week

We were all partnered up this week with another classmate to work on DueDates, an Open Source Java command-line program that retrieves checked out library items information.

Basically any UH student with an internet connection and a machine with Java 6 installed can use this program. They simply need to perform the following steps and as Emeril Lagasse would say, "BAM!" Users see their results in the command-prompt. Unfortunately, the results are not as instantaneous as the expression. It's more like "BAAAAAAM!" stretched out over 3-6 seconds.

Sample output can be seen in the screenshot below.

What We Accomplished:

My partner and I were able to meet most of the requirements for version 1. From the user's perspective, the program meets all the requirements of version 1. But from a developer's perspective, we lack testing. We did not get 100% coverage on our test cases. In fact, we sort of ran out of time to do much or any testing. We did attempt it and ran into some problems.

Problems We Encountered and Solutions We've Arrived At:

1. Emma and JUnit

• Because of the lack of javascript support in HttpUnit, JUnit Testing fails and presents an error when run with Ant. This errors seems to be apparent cause to the low coverage reported in Emma. I guess the coverage test stops as soon as the error is reported.

2. Design

• We felt that all libraries will needs it own unique way of logging in and retrieving information. So all libraries should be a subclass to a larger superclass. To keep output consistent, we decided that the superclass should have toFormattedString method. And all subclasses would use that method to keep output uniform.
  
• SOLUTION: Created superclass Lender, with subclasses UhManoa and HawaiiStateLibrary. All within placed inside a subpackage, "library".
  

How We Worked:

I thought we did a pretty good job accomplishing most of the tasks considering how busy the other's schedule. Both of us had midterms at different times throughout the week. Nights when I was free, my partner needed to study. And the opposite applied when my partner was free. But even through all of the schedule conflicts, my partner and I were still able to meet about 3 times for about an hour each meeting at Hamilton library.

There's nothing much more we can do. It's midterm time and it's good that we can even find time to work with one another. I think the number of face-to-face meetings was about right. We didn't exactly meet on weekends but we communicated through IM. I do wish there was somewhere more casual and laid back to meet. However, it's hard to find somewhere with WiFi and food to eat.

What I Learned:

It's different thinking about future releases of this project. It's difficult to know what to expect for future libraries. It's also difficult to run tests since all accounts could generate different results. Except in my friends' cases, they all have no books checked out.

Google Project Hosting keeps everything very public. Every single update is documented. Not only do you want to think for the future, but you want to put out your best impression to the world. You never know who wants to contribute and who is critiquing your work. Since our real names are published, there is pressure to write clear, well-documented code.

CM Lab

In the previous entry, I was bickering about how there are too many steps to this configuration management process. While I have not fully mastered everything, I still must say it is not that easy compared to the previous assignments. However, there are good news. That is I'm getting the hang of checking out, updating, and comitting with TortoiseSVN.

The Grunt Work is Becoming Bearable...

Luckily for us, the project all contained a similar URL and I only needed to change the project to stack- of whoever it belongs to. Nice and simple. I guess I somewhat already noticed that the googlecode.com password is the same for all projects. If I wasn't already sure, this third time using it confirmed it. I haven't looked into it, but hopefully there's a way to create our own password. I would hate to need to copy and paste that weird set of characters each time I set up a new project.

Check Out, Update, Verify and Commit

I verified both before and after I finished working on Phillip's stack. All was successful so hopefully I don't get a message back about how I messed things up. That would be awful. I really did everything in my power before commiting. I treated it as a commitment to helping while not destroying.

I've only edited minors things. The stack project name in eclipse was simply "stack". I changed it to "stack-klau4" for a couple of reasons. The first was mainly because I already had 3 other stack assignments imported into Eclipse. I need a way to distinguish between the others. The second is because I think the assignment requests for us to include our name in the project.

Everything else seemed okay in the code so I just touched up some JavaDoc for consistency. I noticed in one method, there was an @exception while others (that also included thrown errors) didn't. I even looked up Elements of Java Style to see. It's weird how I never noticed that the book suggests we include @exception tag whereas CheckStyle will complain about not including @throws. To keep with Philip's documentation, I added @exception to the others, but also left the @throws for CheckStyle's sake.

Looks like I See the Light at the End of the Tunnel

Early on, it felt like I was driving through a tunnel with no headlights on. Lost and confused, often times at a stop, trying to figure out how I'm going to finish this. But as I use all of the sites and TortoiseSVN all together, I am beginning to get used to how things work. I can see the light at the end of the tunnel.

Sometimes I worked for long periods of time. In a larger group, there is likely a chance that someone else updated the project in between my commit. I need to get used to updating the project more often. I simply commit once the project passes verify. Another concern, or more of a question really, is the empty packages I am seeing. I noticed when I import the projects I've obtained through TortoiseSVN into Eclipse, there are a couple of empty packages that appear. It is weird how when I commit mines, those empty package don't exist. I am not sure how important this is (probably not seeing how they're empty). But it did make me wonder what was causing it. Perhaps I'll figure it out another time. Is it something everyone's computer is doing except mines, or is it just one person in the entire group responsible for it?

Config Management and TortoiseSVN

TortoiseSVN

This assignment seemed to be much more overwhelming than any of the past assignments. By configuring TortoiseSVN (which oddly enough isn't slow at all) to Dr. Johnson's stack project, each one of us ICS 413 students modified the project in some way to (hopefully) better the overall status of the project.

Rolling Up the Sleeves....

I don't know if its my fever and headache affecting my thoughts, but it seemed as though this assignment required much more setup than the previous tools. The installation to TortoiseSVN was the easiest part of the assignment. But afterward installation was complete, there are so many URLs to keep track of.

https://stack-johnson.googlecode.com/.....
http://code.google.com/hosting
http://groups.google.com/group/stack-johnczly-discuss

And not to mention there's the codesite-noreply@google.com to add to the discussion group, and the googlegroups email address to add to the project page for update and commit email notifications. I'm getting another headache just remembering the process. I found myself constantly referring back and forth from the assignment page and the google pages. This can create quite the confusion. Hopefully after the lab and the next project, the process will be burned into my brain. I'll know how to do all these trivial tasks of setting up projects like I know the back of my hand.

Doing My Part

Well, we don't have an assigned role or assigned area of focus to work on. So my part is not clearly defined. Basically my goal was to change something I felt was beneficial to the project and avoid corrupting its current state. It's amazing no conflicts seemed to have occured so far with so many students working on the stack. I was worried, since I started the assignment late. Had there been an error, I don't know if I can contact the previous commiter to fix it in time.

Anyways once I updated and verified the stack, I noticed the coverage was not at 100%. My first intentions were to increase the percentage slightly (leaving some work for others). I thought the stack was identical to the assignment we've been working on all semester. But turns out, it was different. EmptyStackException has three constructors, and only one was being covered in our JUnit testing. I couldn't quite figure out how to get the other two constructors to be covered, but I thought something such as the following

throw new EmptyStackException("Empty Stack");

Unfortunately, PMD complained and I couldn't come up with a solution to solve both problems. To save time, I noticed that there was some inconsistency between JUnit test cases involving expected exceptions. I fixed that problem and moved on. Hopefully someone will improve the coverage. I can keep track of it now with TortoiseSVN's log.

Reflection of This Long Assignment

Everything is so public in these assignments. It really adds pressure to check your work. Everyone can see who was the last to edit the project and who is to blame if something stops working.

I know google project hosting is free. But seeing as how group members of a project would love to receive notice updates, Google should have combined the best of two worlds and created a mailing utility within the Google Project page. That way there is no need to create an additional group and mailing list. They basically ask for similar information. Referring back and forth between Google Groups and Google Project is kind of a pain. That is just my opinion. Then again, it could be the Tylenol talking.

In addition to these lessons, there is one more I learned. Take your flu shots. Programming while sick sucks.

This was an eye-opening experience. It shows that a team is useful in more than just offering you help. They are also there to place blame! There's no lying with TortoiseSVN. Hopefully, my commit didn't cause any problems. I checked with verify before commiting. Build was successful.

StackOverflow: Temple of Knowledge (and Badges)

First Impressions:

The very first page I visited on StackOverflow was the “About” page to learn more about the site. I really liked their description of themselves and the tone they used in it. They didn’t brag about who they were. Instead there were quite frank saying things such as,

“What makes us special? Nothing, really.”

To me, it set a message that says there are no egos here (at least from the moderators’ side). There is no need to worry about shame when asking questions. We don’t think of ourselves as tremendously superior guys so you shouldn’t feel inferior to speak up.

Types of Questions:

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." -- Rick Osborne

That’s some incentive to comment and be organized there. Haha. That was a reply to a question asking for everyone’s favorite programming quotes. I liked the fact that not all questions and answers are boring and textbook-like. They also aren’t limited to only debugging. I don't know if that violates their original idea of "programming" type questions. But I enjoyed seeing the different varieties. Some questions I saw involved programming interview questions (useful to prepare yourself). Others involved how to work with "incompetent" group members. All good stuff.

Fast Responses:

StackOverflow looks like a very active environment with a lot of credible members providing answers. Some questions under the hot section received 5 answers and about 50 views in only 30 mins. That’s a pretty fast respond rate. So it would make sense to expect a good number of responses in a one day’s worth. I know I will be back to ask more questions. I already see some questions on TortoiseSVN. I’ll be sure to search and even ask questions on StackOverflow if I come across a problem.

Plus, I need to get me some of those badges! I think the badges were a good idea. It provides some extra motivation to answer questions well. Hopefully, no one is cheating the system and voting up for their buddies though.