Line 20: Chapter 7

Today we will be blogging about more exercises from our book, Chapter 7 this time, which has to do with criteria for a normal database. To this end we will be identifying problems in the RMH Homebase database.

7.1: This problem asks you to identify tables in the RMH Homebase database that violate the the following criteria for a normal database.

Criterion 5: Every entry in the table has exactly one value of the appropriate type.
Criterion 6: No attribute in the table is redundant with the primary key.

dbSchedules violates both of these criteria by itself. It allows more than one person to be entered into the persons column, which is a violation because you can have more than one value in this field.

It also violates Criterion 6, because it's primary key is just a combination of the phone number and the person's first name. This creates a primary key that automatically produces redundancies with the other attributes, as it is just a combination of them.

7.2 This question asks you to develop a few new php functions: get_shift_month, get_shift_day, get_shift_year, get_shift_start, and get_shift_end for the dbShifts.php module.

 This one is pretty easy, as all of these are basically tokenizing a string using the substring "-" as the breaking point. Normally you would have to write something to handle breaking it into substrings, and then adding them to a data structure to be references later, but php has a command that does this easily. Using the explode() function, you can break a string into tokens based on a key character. You just provide an array for the new tokens to go into. Since it is so easy, you can basically just change the index of the array you create for each of these functions. Here is an example of the month version of this get, using explode.

Function get_shift_month($id){
        $tokens = explode("-", $id);
        return $tokens[0];
}

You can basically just reuse this code for each function, just changing the index of the array to match the data you are trying to get.

7.3

Line 19: Chapter 6

Tonight we have been given the assignment to blog some exercises from our book, Software Development.

6.1 - This question basically asks you to create some new functions to retrieve and set values for the variables $employer, $contact_person, and $contact_phone in the Person class in RMH Homebase. So all you had to do was to declare the variables, then write a getter and a setter for each. It basically looks like this. 

private $foo;

//getter for foo

function getFoo(){

      return $this->foo;

}

//setter for foo

function setFoo($f){

      $this->foo = $f;

You can extrapolate the rest from this example.

6.2 - The next question was basically to add these new fields to the constructor, so that they are properly initialized when an object is made. They give you the constructor call to follow, and you fill it in. It looks like this.

function __construct($f, $l, $a, $c, $s, $z, $p1, $p2, $e, $t, $status, $employer, $contact, $contact_phone){
    $this->status = status;
    setEmployer(employer);
    setContactPerson(contact);
    setContactPhone(contact_phone);
}

6.3 - Next question is dealing with the fact that the set_status method will accept any status, when it should only accept the strings "active", "inactive", or any case permutation therein. It asks you to implement a fix for set_status. So, this is basically a string comparing problem. It can be solved like so.

function set_status($value){
if(is_string($value){
    if (strcasecmp("active",$value) == 0 || strcasecmp("active", $value) == 0){
        $this->status = $value;
    }
    else{
         $this->status = NULL;
    }
}
else{
    echo "Status value must be of type string";
}
}

This code should handle any incorrect strings, and cases where value is not passed a string. To test to make sure it works, possibly unit tests cases are setting $value equal to: "active", "inactive", "ACTIVE", "INACTIVE", "iNaCtiVE", "0", "NULL", "you will fail", "", or any other type of value you can throw at it.

6.4 - This next problem has us refactor the Person class by removing all of the mutators that weren't called from anywhere in the codebase.

Turns out none of the setters were called from anywhere in the codebase. All variables were just set manually. So, I removed the setters then tested it. Seemed to work fine.

EDIT: As we discussed this problem in class today, Dr. Bowring pointed out that there is no reason to set the status to NULL in problem 6.3. NULL grants you nothing, and just gives you a new exception you will have to handle later. He suggested instead that we use a default value that is set when incorrect values are given. The else statement now looks like this, using active as the default state.

else{
         $this->status = "active";
    }

Line 18: POSSCON Report

Last week we took Obsidian to POSSCON. We ended up in Columbia on Tuesday to set up the booth, and get everything prepared for the next day. The next morning, we began to sit the booth and explain Obsidian to passersby. It felt slow at first, but we ended up explaining the project to tons of people. Most seemed at least interested in the idea, and they gave us good insight into where to go with it next. We had a form set up online that would allow us to send them one email after the conference, so that they could get more involved with the project if they so wished.

We also met a few good contacts at a company called Engine Yard. We met them on Tuesday night, at a meetup for sponsors and speakers. The people we met were actually two of the speakers at POSSCON, Ines Sombra and Tasha Drew, and they both seemed interested in our project as well.

Of course, we also met many other people, and were given offers of interviews and invitations to do more talks about the project. It was an overwhelmingly positive experience for a student like myself, and really showed me how welcoming the Open Source community can be.

One of the things that many people were interested in, was whether Obsidian would work with .NET. The answer was obviously that it does not currently, but there is no reason why it couldn't.

We also decided to move the project from Google Code to Github, because it seems to be a bit more popular at the moment. Plus, it provides tracking for your commits and pulls, so it is a great resource to show potential employers in the future. This means that I have a lot of work to do on the wiki again, but at least it gives me something to focus on.

For now though, Team Obsidian is taking a cool down period. We sent out a few emails tonight, thanking people for their interest, and also informing them about the project in further detail. We will be focusing on the deliverables for our Software Engineering Practicum for the next week or so, because we would still like to pass the class in the end.

Personally, I thought POSSCON was a great experience for our team. I loved every talk I got to go to, and I feel like the project generated good buzz in the community. It was a pretty fun, if slightly stressful, week.

Line 17: Reflections on my Progress and Plans

So, we have POSSCON tomorrow. Well, we have to set up for POSSCON tomorrow. These past few weeks have been like a blur of work to me, but now I feel like I am in a pretty serene place. The source code is online, and the wiki is in presentable format. The coding that was to be done is done, and there is nothing left to do but wait for the storm to hit.

Tomorrow we are giving a presentation to the College chapter of the ACM, as practice for the questions and information that we will be responsible for at the conference. We also set up scheduling tonight, so that we know who is going to sit at the booth when.

It really feels like Obsidian has come a long way in the last few months. It has much fewer bugs, and some new features have been added as well. The biggest change is in the documentation though. Where we used to just have Hunter to consult with any questions about the project, we now have a whole knowledge base that we can look at for our minor needs. Hunter still has to be consulted on major decisions and things like that, but I feel like this helps to take a lot of the strain off of him.

Since I helped a lot with the wiki, and documentation in general, I really feel like this is a large accomplishment, and I am pretty proud of what has been created. I think that Obsidian could really be a useful tool in a test engineer's arsenal, so I would really like to see it take off at POSSCON.

As for the future, I hope that POSSCON provides us with a better idea of what direction to take the project in. We have a few ideas of our own, but having a few more wouldn't hurt. Currently we are thinking of writing a front-end for the project, so that people would not have to use command line arguments to run the project. We could even make a helper for writing test cases that would inject them into the code in the appropriate places.

Another cool thing would be to see if we could pull generated test cases into Obsidian. You would be able to run a test case generator on your project, and then have Obsidian populate test case arrays with that data. This would save the engineer even more time, and might be able to catch cases that he would otherwise miss.

There are a lot of ways that we could improve this project, and it is exciting thinking about the future of it. This is all assuming that POSSCON goes well of course. If it doesn't, for whatever reason, then I guess we will have a bunch of other stuff to do instead. Either way, it still seems like there is a lot of work to do on this project, and my semester shows no sign of slowing down. Sleep is for the weak anyways.