RMH Homebase Exercises

As a way of getting used to refactoring code and rooting out "bad smells" in code, we were assigned to download and explore RMH Homebase.  Homebase is an open source volunteer scheduling system.  The code is written in php, so I decided to approach the assignment by looking at a single php file for bad smells.

I picked one of the larger files called editMasterSchedule.php and immediately found some problems with the code.  To begin with, only one of the twelve functions within the file had any sort of commenting.  Because of this, it was really hard to figure out what was going on and took some time to be able to make my own comments.  As an example using one of the shorter methods, the function do_slot_num($shift) takes in a shift as a parameter and then returns how many slots are available for that particular shift.  And that literally is what I put down for the comment.

While I was commenting the code, I also noticed that one of the functions, do_fill_vacancy_form($shift, $fam), was left as a stub and did not do anything at all.  So I removed that from the file.

Ironically, the only function that was actually commented was a long method, or a method that performs more that one task.  And it was the comments that gave it away.  The comments disclose that the function checks to see if a person is working a given shift, and also checks to see if a person is available to work any shift.  This should be two separate functions and I rewrote the code to reflect this.

The last function in the file is a really long if statement:

function get_day_names($shift,$day) {
      if($day=="Mon") {
       $shift[]= "Monday";
       $shift[]="Mon";
      }
      if($day=="Tue") {
       $shift[]= "Tuesday";
       $shift[]="Tue";
      }
      if($day=="Wed") {
       $shift[]= 'Wednesday';
       $shift[]="Wed";
      }
      if($day=="Thu") {
       $shift[]= "Thursday";
       $shift[]="Thu";
      }
      if($day=="Fri") {
       $shift[]= "Friday";
       $shift[]="Fri";
      }
      if(substr($day,0,3)=="Sat") {
       $shift[]= "Saturday";
       $shift[]="Sat";
      }
      else {
       $shift[]="Sunday";
       $shift[]="Sun";
      }
      return $shift;
     }

I decided to change this out to a switch statement:

function get_day_names($shift,$day) {
      switch ($day) {
             case "Mon":
                  $shift[]= "Monday";
                  $shift[]="Mon"; break;

             case "Tue":
                  $shift[]= "Tuesday";
                  $shift[]="Tue"; break;

             case "Wed":
                  $shift[]= 'Wednesday';
                  $shift[]="Wed"; break;

             case "Thu":
                  $shift[]= "Thursday";
                  $shift[]="Thu"; break;
    
             case "Fri":
                  $shift[]= "Friday";
                  $shift[]="Fri"; break;
   
             case "Sat":
                  $shift[]= "Saturday";
                  $shift[]="Sat"; break;
   
             default:
                  $shift[]="Sunday";
                  $shift[]="Sun";
            }
      return $shift;
     }

For me, this just looks more straightforward and readable.  Although my professor, Dr. Bowring, pointed out that this is a problem that should ultimately be solved with polymorphism.

Playing With Patches

For this assignment, we were to read chapter 7 and do some of the problems contained within it.  The title of the chapter is "Fixing_The_Code" and talks about how to document and submit bug fixes.  The first thing that struck me after reading this chapter was how well implemented a process this is.  And also that it was completely different from how I imagined it.

When I thought about fixing bugs and then submitting them for approval from the project developers, I figured that you just uploaded the patch into the repository.  Then the code update would happen after the patch was reviewed by the People In Charge.  Well, it seems that there is a bit more to the process than that.  There is a really neat way that the fix is documented that makes whatever changes made easy to read, and keeps things standardized across the board.  This is called creating a diff, or patch.

The patch is a text file that is created by comparing two (or more) other files using the unix diff command, then piping the results of that comparison into the text file.  The example in the book starts with a simple C
program:

#include <stdio.h>

int main() {
     printf("hello, world.\n");
     return 0;
{
    
Now, say you want to change the code to express your insane enthusiasm for C and programming in general.  In order to do so, you must create a patch file.  The first thing to do is make a copy of the "hello.c" file in the same directory.  Then make the changes to the original file, namely some exclamation points:

#include <stdio.h>


int main() {
     printf("hello, world!!!\n");
     return 0;
{

Now to create the patch.  A simple command takes care of the rest:

$ diff hello.c.new hello.c > crazyHello.patch

This compared the two files, documented the changes, and reported them into the file "crazyHello.patch".  This file has a lot of information in it, but the most important is what was actually changed.  It looks like this:

-    printf("hello, world.\n");
+   printf("hello, world!!!\n");

By doing things this way, open source developers know exactly what to look for when a patch is uploaded to them. This makes things go a lot faster for approving changes, fixing bugs for users, and improving the project.  Pretty smart.

Response on "The Cathedral and the Bazaar"

I have finally finished reading The Cathedral and the Bazaar by Eric Raymond, and I am now prepared to complete my assignment from last week and blog a response to it.  My first impression upon reading it was that this should be, and is in my case, required reading for any CS student interested in learning more about open source software development.

He lays out a number of little nuggets of wisdom throughout the essay and the first one was right on the money.  It says, "Every good work of software starts by scratching a developer's personal itch."  This is an absolutely true statement.  At the place where I work one of the jobs that I do is help to recover an encrypted hard drive after a system crash.  The method for doing this required multiple steps, such as copying and pasting things into the command line, and was a real pain.  After I complained about this to one of my co-workers, his basic response was, "hey, you're a programmer.  Fix it."  Challenge accepted!

So to make a boring story short, I scratched my personal itch by writing up a batch file to automate the process of getting the recovery key.  It was a very satisfying experience to create something that actually filled a need and would be used by other people.  And this is what I expect drives many developers to go out there and create cool things, it satisfies a personal need to do so.

Another idea that Raymond features in his paper is the notion of treating users as co-developers, which allows a better flow of code development and a more efficient way of debugging.  This method is apparent in the project we are working on right now, because just by messing around with xbmc's bug tracker for a few minutes the time and effort put into it's design become apparent.  It is an obvious effort to make the bug reporting system as easy as possible for users to navigate.  And I totally agree with this approach.  Giving users a sense of ownership over a project ensures a more open and dependable development cycle.

He then goes on to describe his personal experience taking ownership of his own project, fetchmail, and how he applied good open source design principles in improving and implementing changes to the project.  Altogether this was a very informative and descriptive paper, and still has as much merit today as when it was written back in 2000.

Becoming Familiar With xbmc Bugs

This assignment proved to be a really interesting one.  We were once again tasked with doing some exercises from our online open source textbook, this time ones dealing with the xbmc bug tracker.  The assignment was broken up into four parts, so that is how I'll divide up this post:

1) Finding the oldest bug.
In the process of doing this exercise, I actually found some new functionality in the bug tracker which allows further refinement of which bugs to display.  I figured that because we are working exclusively in Linux for this project, I would start in the newly discovered section just for Linux bugs.  After doing this I was returned with 369 open tickets!  After sorting by date created, I found that the oldest bug was from November of 2003 and was dealing with a module called Requant.  It appears there is a problem with the C++ source code dealing with the re-sizing of video files, but the priority level on this is set to unimportant and the ticket has not been touched in over a year.  I think that this bug has not been resolved because the module was not needed in the first place, and that whatever functionality it was supposed to provide (the ability to re-size without decoding and then encoding again) was picked up by something else.

2) Create a bug tracker account.
Ha!  I was one step ahead of you, authors of Teaching Open Source, on this exercise.  Although, to be honest, this was not by design.  By creating an account to have the ability to post on the forum, a contributor also has access to the bug tracker.

3) Attempt to reproduce a bug.
4) Bug Triage.
Unfortunately, I began to experience problems connecting to their server at this point and was unable to stay logged into the bug tracker.  I plan on completing parts three and four tomorrow, and then posting my experience later that day.

Exploring xbmc For Bugs

Our team ended up having a meeting on Sunday to discuss which bug we would like to work on.  We explored many options and already had some ideas coming into the meeting.  One of the ideas that I brought to the table was that there were some documentation errors in the readme file.  The repository that the file was pointing to was the old sourceforge one, and the current working repository is located here.  Also there was a couple of errors in the instructions for compiling the code.

After much discussion, we decided to run with this and use it as an experience to get our collective feet wet.  Just to double-check, I went into the most current readme for the Eden version of the software before we committed to doing this.  They had already fixed it!  So we dug back into the bug tracker and looked to see what kind of reported bugs were out there.

To help with this, xbmc has a convenient ticket system called their Trac system.  Using this system, a potential developer for the project such as me can scroll through all open tickets listed.  These tickets can also be filtered by a number of ways including date created, component affected, and date modified.  The first thing that we discovered was that there are a LOT of bugs to pick from.  The second was that we were going to have to be careful in choosing which bug to work on, because of the difficulty involved with some of them.

One example of one of the more cryptic ones listed says " "startup window" option does not honor skin "videos button always goes to video files" option ".  I can imagine that, having not written the code myself, this would be a hard one to track down.  So these were the things that we were dealing with when trying to sift thought the various tickets.  So in the end, we actually did not come up with a bug to start working on during the meeting.  This was due to the readme bug already being fixed and the overwhelming amount of bugs listed on the bug tracker.  Hopefully we will be able to narrow it down during the week and come up with something by Friday.

Article Interpretation and xbmc Part 2

The article that I chose to write about comes from the January 2010 issue of Computer magazine.


In their article titled "Online Security Threats and Computer User Intentions", Thomas F. Stafford and Robin Poston theorize on the phenomenon of user apathy regarding online security.  In this article they do not address why people should use antispyware software, but why they choose not to use such software.
One of the first statistics cited in the article is that, out of a survey of 252 consumers, only 22 percent of them consistently used security software of some kind.  Another study done by AOL saw that 55 percent of the people polled either did not use or did not know whether or not they used antispyware software.  As a CS student I find these results troubling and somewhat confusing.

I find them troubling because when users do not use security precautions on their personal machines, for whatever reason, they can unknowingly contribute to the proliferation of malware and spyware.  I find it confusing because the first thing I think about, at least on a Windows machine, is whether my virus definitions are up to date.  But it seems there is a possible reason for the shocking numbers that were cited.

Stafford and Posten have put forth a theory they call Protection Motivation Theory.  Simply put, the theory says that when presented with a perceived threat, such as the possibility of a keystroke logger on your computer, an individual must be sufficiently motivated to deal with that threat.  According to Stafford and Posten, the biggest obstacle that prevents users from using available software solutions is what they call Protection self-efficacy, or a user's lack of confidence for using and installing said software.

This is really interesting stuff, and while they do not go too far into possible solutions to this problem, it seems that the onus is on developers and the tech community.  Through rigorous education of the lay-user and continual re-development of easier to use security software, we might be able to see these statistics begin to change direction.

And on a quick side-note, I finally was able to get xbmc up and running.  Through the helpful posts of my team members James and David, I realized that I needed to add the xbmc PPA  to my system in order to get all the necessary dependencies.  After installing the PPA, I ran the following command: sudo apt-get build-dep xbmc.  This built all the dependencies that I was missing and I was then able to finish configuring and making the project.