Capstone: Upcoming Presentation

This post will be brief as it will be outlining my upcoming poster presentation for the Data Science and Computing in the Arts symposium at the College of Charleston, as well as my Capstone technical report.

A look at my poster:

I chose to go with a brief overview on the poster and I can elaborate more if people ask. So the poster does not go too much into the technical detail.

Below is a flier advertising the presentation:

RMH Homebase - Chapter 7 of Software Development: An Open Source Approach

This post will be composed of mostly responding to exercises found in Chapter 7 of Software Development: An Open Source Approach.

Chapter 7 is about the development of database modules and the chapter uses RMH Homebase (as I have referenced in numerous posts prior to this) as the example with which to conduct exercises.

The first exercise relates to database normalization criteria.

First, I would like to start by outlining the six database normalization criteria (directly taken from the text):

1. The rows can be rearranged without changing the meaning of the table (i.e., there's no implicit ordering or functional interdependency among the rows).
2. The columns can be rearranged without changing the meaning of the table (i.e., there's no implicit ordering or functional interdependency among the columns).
3. No two rows of a table are identical.  This is often accomplished by defining one column whose values are mutually unique.  This column is known as the table's primary key.
4. No row has any hidden components, such as an object id or a timestamp.
5. Every entry in the table has exactly one value of the appropriate type.
6. No attribute in the table is redundant with (i.e., appears as an explicit substring of) the primary key.

It is given that certain tables in RMH Homebase violate criteria 5 and 6. It is given that dbDates does not satisfy either of these criteria. 

Another table that violates criteria 5 is the dbSchedules table. To recapitulate, criteria 5 states that every entry has exactly 1 value; dbSchedules sometimes misuses the Persons field. Sometimes there only exists 1 person in the field (or null), but there do exist times where multiple people are in the field for one record. Because it is happening for one record, that is a violation of criteria 5.

Another table that violates criteria 6 is in the same exact table. Typically, databases will have a primary key in the form of some unique id. Other times, however, compound keys are used (or created). A compound key is the usage of multiple fields in a database table to uniquely identify a record. For example, if we had a Person table, then we could potentially have 2 people with the same name so maybe we would identify them by their name and address together. The dbSchedules table, though, uses name and phone number as a compound key, which is not a problem, but the primary key is now a new field. So the primary key (or compound key) is now a redundancy of both the name and phone number in the same table, which is in clear violation of criteria 6. 

The next exercise is asking for me to develop and unit test specific functions for the dbShifts.php module.

So the getters can be written very easily since id is a compounding of all the other needed attributes (delimited by -'s).

function get_shift_ABC($key) {
    $attribute = explode('-', $key);     $ABC = $attribute[fieldNum];
    return $ABC;        

}

So here I am showing a very generic version of the getters I would use, given the exercise specifications. I change the variable coming to "$key" from "$id" merely because I like key as a better name, but that is just my personal preference. The next line is equivalent to conducting a ".split()" on a string in Python. So now "$attribute" is a list of all the attributes, in generic list order. Now you may have noticed that I named the function ..._ABC(...) and named a variable $ABC. This is because each getter would have a better name for the variable there (for readability). For example, you would replace "ABC" with "month" if you were writing the get_shift_month(...) function. The only thing that changes when getting different fields with these getters is the indexing into the $attribute variable. Below I have listed what field each value in the list corresponds to:

fieldNum	Field
0	Month
1	Day
2	Year
3	Start
4	End

So now all 5 getters are, effectively, written.

The last exercise wants me to design and implement the changes to the database modules required by the new feature - Item 4: Calendar Month View - in the "wish list" as prescribed in Appendix B. The quickest way to do this is to copy an entire database through php and then use refactoring (this may not be the cleanest, but it is quick, effective, and gets the job done). The php class I refactored was dbWeeks - I chose dbWeeks because the two classes are organized similarly (this is even hinted at doing in the book - page 194). Refactoring allows me to change the fields to the necessary values. So now each row in this calendar month view represents a month, active or archived. The unit tests were also able to refactored easily and all the tests passed with no apparent issues.

Penultimately, I would like to give an update about Team Rocket and our work with Galaxy this semester. We have finished our poster and got it printed off. Below is a (low quality) picture of our poster that we will be presenting at the College of Charleston School of Science and Math Poster Session on Thursday, April 17, 2014. 

Lastly, I would like to give an update about my plans to "Meet Charleston" - for me that was attending an "Agile User Group" meeting. The next meeting will be taking place April 24, 2014, from 11:00am-1:00pm and will be hosted by Life Cycle Engineering. I am really excited to make it to this meeting.

Software Development: An Open Source Approach <-> RMH Homebase (Developing the Domain Classes)

For this post I will be going through Chapter 6 of Software Development: An Open Source Approach and reflecting upon my experience with some of the exercises at the end of the chapter. All of the exercises focus on dealing with the open source software RMH Homebase (which I have mentioned in posts in the past).

The previous blog post in which I talked about the installation and usage of RMH Homebase can be found here.

The RMH Homebase release 1.5 code base can be downloaded from myopensoftware.org/textbook

Unfortunately, all the work I did on my previous post is for naught for the purposes of doing these exercises since I am on a different computer. So let's run through some commands and dependencies with which I had to deal:

% sudo apt-get install mysql-client mysql-server
This command didn't work as I had hoped because it kept complaining about out-of-date dependencies and missing dependencies. And these errors kept continuing.

% sudo apt-get install mysql-server-5.5 mysql-client-5.5
led to
% sudo apt-get install libdbd-mysql-perl
led to
% libmysqlclient18
which ultimately led to an error with glusterfs-server, which is something, I believe, extremely specific to my lab computer.

Experience-wise, it is good that I can note what is going on. Practicality-wise, this is frustrating because I do not want to tinker with the cluster as there are a lot of projects that are relying on the cluster not being tinkered with (including my own). So while this was valuable, I will continue this on a different computer at a later point. Also, the gluster error perpetuated for every package I wanted to install (apache, php, etc.)

More commands:
% sudo apt-get install apache2
% sudo apt-get install php5
% sudo apt-get install phpmyadmin

For reference, an easier way to get all of the MySQL stuff installed can be done through:
% sudo apt-get install mysql-client-core-5.5 mysql-server-core-5.5

Everything that these commands install and do can be found in my older blog post I mentioned earlier.

The exercises are very basic, in nature. Defining new functions to set and retrieve the value of the variables $employer, $contact_person, and $contact_phone.

So, pretty much. Encapsulate the Person class with getters and setters so someone can say "get_employer()" or "set_employer($newEmployer)". So there's not really any work here rather than making getters and setters for all 3 of the features.

Example:
function set_employer($newEmployer){
     $this->employer = $newEmployer;
}
function get_employer(){
    return $this->employer;
}

The next step is to create a more well-defined constructor. This goes as follows:

function __construct($f, $1, $a, $c, $s, $z, $p1, $p2, $e, $t, $status, $employer, $contact, $contact_phone){
     $this->first_name = $f;
     $this->last_name = $l;
     .
     .
     .
}

It's obvious that you would just typical assignment in this constructor like I started to outline. When doing the password field you would probably want to throw in your favorite flavor of encryption so you are not handling raw passwords because that's a security no-no.

The next question pretty much asks you to rewrite the set_status function because currently the $value that is passed in is never checked to be valid (which it can be "active" or "inactive"). Currently, if something else is passed in (let's say "cheese") then someone's status could be set to "cheese" rather than actually checking if there is a problem. So let's rewrite the function below:

function set_status($value){
     if ($value == "active" or $value == "inactive"){
          $this->status = $value
     }
     else{
          echo "Your input for set_status was invalid. active and inactive are the only valid options."
     }
}

So now the user knows if they picked a wrong value for set_status and status does not get changed if an invalid input is put in.

The last exercise is to refactor the Person class (where we've been working this entire time) to have removed all the mutators that aren't called from anywhere in the code base. This can be done by deleting or commenting out (commenting out would be preferable in my eyes) unused mutators.

Music listened to while blogging: Childish Gambino