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.

Line 16: Preparing for POSSCON

So POSSCON is just around the corner, and while I am a member of Team Obsidian, I also have my own interests in the talks that will be happening. I have been browsing the POSSCON website, looking at speakers and the talks they are going to give, trying to decide who I should go hear. The goal of course is to pick topics that interest you personally, and to be able to interact with the speaker in a meaningful way after the talk.

With this in mind, my first pick for a talk was incredibly easy. Roel Van de Paar will be giving a talk entitled From Crash to Test Case: A Debugging Primer. He is a QA lead at Percona, which is a MySQL services company. His talk will focus mainly on what to do with the information you receive from a server crash, and how constructing test cases will allow you to quickly isolate and repair the problem.

Since I have been working on a Unit Test Implementation Generator for nearly the whole semester, I am eager to see what an industry professional like himself  has to say about constructing useful test cases. I am even more interested in what he will think of Obsidian however. It is my hope that his talk will prove both informative, and give me some new insights into Obsidian. My best case scenario is that he is able to impart advice about how to further improve the project, which will give us some direction to take it in the future.

The next talk I want to attend is Javascript: The Language Every Developer Should Know, which is being given by Tom Wilson. He is the president of Jack Russell Software, which is a local company that develops mobile and web applications for HealthcareIT. I am interested in this talk mostly because of the company's relative proximity to me, but also because I know very little about Javascript. I hope to go to his talk and become more educated on this language, especially if it is truly one that every developer should know.

The last talk I am going to is called How Open Source Helped Win the 2012 Election, and it is given by Harper Reed. He was the CTO on Obama's 2012 campaign, and is also the CTO for Threadless, a democratic shirt printing site. I am interested in his talk because of its proclamation of helping win the 2012 presidential election. It is really cool to think that community driven software has such a large impact on the world. I hope to talk to him more about his experiences during the campaign, and working for a website that I have used on more than one occasion.

Most of the conference though, I will probably be attending the Obsidian table, collecting members for our Google groups, and passing out stickers to attendees. I look forward to meeting all of the speakers, but I am personally more excited about meeting anyone who comes by our table and introducing them to the project I have been working on.

Line 15: Release early and often

Last time I spoke about the large work session that we held last Friday, So I guess I will give an update on that.

We gathered at 3pm that afternoon in the conference room, and we worked there for about 6 or 7 hours. We made decent progress on many aspects of the project, and the fact that we were surrounded by our group members was actually very good for productivity. We were able to ask questions of the group and get immediate responses, which was a tremendous time saver.

We got the wiki into good condition, and then were able to have a mini meeting about what changes needed to be incorporated on each page of it. With the feedback, we each had something to concentrate on for the next week.

We also planned out our trip to POSSCON more, and came up with a good layout for the poster. It features an easy to understand graph that shows what each case Obsidian recognizes to generate test implementations for. We will be focused on having that finished in the coming days.

When we met on Monday night, we basically hammered out a bit of the poster, rearranged some wiki pages, and added a Contact page so that we could just link to it, rather than repeating contact information across multiple pages. We also scheduled out our next week, and decided on meeting times and goals for the project. We have our work cut out for us in the next week, but I still feel like we are in a good position to finish all of this.

We all worked on modifying the wiki pages that we had received critique of on Friday, and they are coming along nicely. The wiki is complete currently, but the information still needs tweaking here and there.

I think that a good test of it would be to give Obsidian to a group or classmate currently in 462, and leave them to try to figure out how to use Obsidian on their own projects without any input from the group. If they can do it easily, that will indicate to me that the wiki provides a good base foundation for new users, and will really put me at ease about its functionality. However, if they are unable to do it, it will highlight areas that need work so that we can increase the usefulness of it before POSSCON. I had this idea while modifying my pages after the meeting, so I am going to talk to Hunter about it tonight, and the group about it either before or after class tomorrow.

The good thing is that the team seems very motivated, and is tackling problems and quickly coming up with solutions to them. POSSCON will be one week away on Wednesday, so we are very obviously in crunch time. The source code and .jar files will go up on the Google Code page next Tuesday, so we only have a little bit of time to finish tweaking before our version 1.0 release. We have the pieces in place to succeed, all that is left is to actually do it.

Line 14: The Doc is in!

Tonight our reading was about documentation in Software project. It talked about useful tools that you could use, and methods for documentation. This included commenting, and even "bug fixes" that were just documentation clarification for the project. We had some exercises to complete as homework, that would allow us to get further into the documentation mindset.

The first part was to go through the code and make sure that you had readable comments that enhanced the ability to easily understand your code. My project is of course Obsidian, and I must say that most of the commenting on this project seems to be in a good area. Most of the classes are easy to understand and have easily understandable comments describing their functions. The project goes even further, because it also generates comments for the test cases that it generates.

We have been working on documenting this project on our wiki for the past few weeks as well. In fact, I feel like we have been in the documentation mindset for the past few weeks.

We have been focusing on documenting Obsidian since we left for spring break, and by now most of our documentation has been completed. We have created documentation on how to modify tests, planned out frequently asked questions, and even wrote guides to getting the project off the ground quickly.

Overall, most of our efforts for the past two weeks have been put into finishing documentation for our project, so this reading was really easy to understand for me.

In POSSCON news, we are currently preparing for our trip, making lists of what we need to bring, and also ordering items to promote our project. We decided to make a form for people to sign up for our mailing list, that they can easily use when they visit the booth. We also planned out who is going to go up the day before to set up the booth, as it has to be done by 7pm on March 26th. This was sort of an issue, because the stickers that we are ordering will probably arrive on that Tuesday. Since Michael Cole has a test that day, it was decided he would stay behind to make sure that we get all of the things that we ordered. This is convenient, because we will be staying at Hunter's mother's house that night, and we wouldn't have enough beds for us to sleep in.

That was all that we really discussed over the past few days, but our first giant work session will be tomorrow on Friday, and I hope that we can accomplish a lot of our goals at it. We still need to decide on final wiki structure, and we are also going to begin working on our poster, so that we can display it at POSSCON.

We are in a good place for our final push towards POSSCON, and I really feel that we will be able to muster a strong showing for the conference. I am looking forward to it.