Monday, April 22, 2013

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

Monday, April 8, 2013

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";
    }

Monday, April 1, 2013

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.

Thursday, March 21, 2013

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.

Monday, March 18, 2013

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.

Monday, March 11, 2013

Line 13: After the break...

Well, Spring break has come and gone, and Team Obsidian is back on track in a big way. Before the break, I was expressing concern over our ability to remain on schedule, due to my own feelings of exhaustion. That prediction turned out to be slightly correct, as the team had a stumble in the last week leading to break. Few of us had what could be considered a "first pass" on our documentation assignments done, and that marked the first time we had ever been late on a deadline. Luckily, the spring break buffer zone allowed us to refocus, and when we met this evening the first pass was indeed complete, and we had made marked progress towards the completion of our final versions of these documents.

We also saw some progress on the enhancements to Obsidian, and we are virtually bug free at the moment (though I have no doubts that the finalizations of the enhancements will add plenty to be squashed). We are all familiar enough with the code to write about it, and seem to have been keeping up the stride we set at the beginning of the semester.

POSSCON is in two weeks from now, so we have also been organizing ourselves for that. We have been granted a booth, in a very good location I might add, and we are getting prepared to go. We used this evening to plan out what we needed to do before POSSCON, and start doing some of those them. These tasks include plans on how we are setting up the booth, who is driving whom, and what we need to bring for the show.

Since it is creeping up on us slowly, we have decided to bump up our meetings from two to three a week. Friday has been added, with the intent of using it to get work done. We will basically sit together in the conference room after class, and go about our personal assignments. Because we are together, we can ask questions of the group and make decisions rapidly, which should speed up the process quite a bit.

As for me, I suffered a little disaster over spring break. My laptop of 5 years bit the dust because of a hardware malfunction. The basic gist of it is that the part that delivers power to the screen has broken down and needs to be replaced. For a while, I thought this would severely impede my progress on Obsidian, however Michael Cole loaned me a spare laptop he had, and I was able to resume my work. My laptop has been packed up and sent off to have its part replaced, and it should be back before POSSCON.

Anyways, things are looking good with the group, and I am glad that we managed to keep on schedule, because it should mean a lot less stress in the long run. We are all looking forward to POSSCON, and want to produce the best project we can before it arrives.

Monday, February 25, 2013

Line 12: Reflections on my Progess

This week Obsidian continued to make progress towards becoming prepared for POSSCON. When we met tonight, we had a conversation about what we would need for the convention. A table and chairs were to be provided to us, but we planned out what our table would look like. We planned on a monitor mirroring one of our computers, so that we could run demos on popular open source projects for people who come by the booth. We also thought that it might be a good idea to have another computer open to people, so that they can sign up for our mailing list if they are interested in the project. We also decided that we would have our poster prepared, so that we have something else to show at the convention. We also discussed the possibility of creating a little script for the convention. Just something that would echo the command line arguments to run Obsidian on projects. This would create an easy and fast way to run it, without having to type out the lines yourself. We didn't reach a conclusion on this front, as some members thought that such a script would not impress visitors to our booth, because it might seem like we didn't know how to run our own project. I personally think that the idea of a script has merit, just for simplicities sake, but it remains to be seen whether we will pursue this idea.

Next we split up the responsibilities for documentation for the next milestone that is due on 2/27. My personal responsibilities are adding JUnit documentation, and writing about modifying test cases. You can check out the rest of the group's assignments on their personal blogs, or on the wiki for our class. The goal is to have a first pass over the documentation completed by Wednesday.

We also finished solving our second bugs since last week. On Sunday, I submitted a diff file to Hunter so that he can add it to the full project. We decided that we are going to use diff files to continue to patch Obsidian, so we were using this week to standardize the procedure. We ended up closing Issues 7 and 4 over the weekend.

I am sort of struck by a sense of being slightly burned out from investing so much time in the project, and it feels like a lot of the team is getting to be right there with me. It was to be expected as the school year went on and the course load started getting heavier, but it is still disheartening that we seem to be slowing down our progress. I spoke with Hunter about the growing sense of ennui, and he agreed that school was catching up with him as well. I have a feeling that this week is going to be hard to get through, and that we might fall behind schedule here. Since our deadline is so much earlier than the rest of the classes' due to POSSCON, it is imperative that this does not happen. I am going to try extra hard this week to try to push through the rest of my work, so that our project continues to stay on the schedule that we set for it.

Wednesday, February 20, 2013

Line 11: Refactoring Mindset

So, I believe I will start this off by actually talking about some of my experiences at the Alumni Symposium. On Monday, I wrote about what I felt the Symposium would be like, and for the most part I was correct. The speakers had good insight on how to get a job, how to sell yourself, and most importantly how to be yourself in the years after college. There was a Q&A period after the presentations, and they used this time to address many of the concerns that students had about finding and keeping jobs in the industry. The most important takeaway from the whole thing seems to be to just keep learning. Technology is a fast field, and you have to be willing to keep up with the times and learn new techniques in order to be a useful member in a company.

One of the really refreshing things about the symposium was how a few of the recent graduates still seemed to not really be fully sure in their jobs. They say that people treat them like experts, but they have to try just as hard as everyone else to keep up and be relevant. It provided a very humanizing viewpoint on the working world.

There was also a slight discussion about events that we could go to in Charleston to further network with people in the industry. Many were mentioned, but far and above the most important was the Job Fair that we will be having in March. I will definitely be attending this, and will hopefully meet some contacts that will be useful to me in the future.

In Obsidian news, we had a meeting tonight to discuss further bug fixes. We worked as a team to help Joanna figure out her exception handling bug, and I solved my Test Class naming issue. For now, we just gave it a more distinct string to append to the end of class names. We may improve upon this further in the future to make sure duplicate names cannot exist. For now though, the team decided this fix was good enough. We also talked more about the Web App and the website itself, and made a plan to meet on Friday to commit the bug fixes to the project.

Hunter also told us today that we had been granted a table at POSSCON for the 2 days it is running. We will be able to show off Obsidian to local developers, and hopefully gain some more members for our project.

One thing that I am currently worried about is the prospect of having a dead project in the future. A lot of the members of our class have been having issues getting into contact with the developers for their projects, and this is discouraging to them. While I don't want Obsidian to become like one of those projects, I do think that there is a very real danger that it might. We are 5 students, 4 of whom will be graduating this semester. That amounts to a lot of change in the future, so hopefully as we tackle that change, we will also be able to continue to grow and nurture this project.

Monday, February 18, 2013

Line 10: That could be me in x years

Tomorrow, in lieu of class, we will all be attending the Alumni Symposium for the computer science department. The point of this event is to allow graduates to come back to school and recollect on their first year of work. They cover topics like how they got their jobs, how they are fitting in, and what the school taught them that they found helpful in the real world. The whole thing is to get those who are close to graduating, like myself, some helpful advice for finding our own job in the future.

When I went to Sparc a few weeks ago, we met one of the speakers, Joshua Walton, who spoke to us for a moment as we took our tour. Since I already made contact with him, and Sparc seems like a cool place to work, his will probably be the talk I am most interested in. The other speakers seem interesting as well though. One of the interesting things about this symposium is that it focuses mostly on new graduates, but we have a few veteran speakers as well. I think that the input that they can give would really help me in my future job search.

In Obsidian news, we recently solved a slew of bugs. Last Wednesday we had a meeting to report on our solved bugs, and we each submitted our fixes to the repository. It was heartening to solve a bug, and even more so that each of us managed to solve ours with little to no problems. So, because of me and my group, the Obsidian project is now a little bit better. That feels pretty good. For a complete list of what we solved and how we solved it, you can always check our Google Code Issue Tracker. You will have to search through all of them for the completed ones though.

For next Wednesday we will each have hopefully solved another bug. The one I am currently casing out is Issue 3. We need a better naming algorithm for Test Classes because of discrepancies when programmers have already created a Test Class. The current algorithm just adds -Test to the end of the class name, since this is a pretty standard naming convention, whenever Obsidian has to name a Test Class, there is a high likelihood of it being named something like ClassTestTest, which would correspond to ClassTest.java. This confuses Obsidian, because it will look at ClassTest.java, and assume that it is the Obsidian Test Class, when it is in fact another programmer's Test Class. This causes many inconsistencies, and is a problem that needs to be addressed.

To solve it, I am probably just going to make more obscure naming convention, and refactor some code to make the search for obsidian test classes a bit more accurate. I think that this should guarantee that Obsidian always finds the test case that it wrote, and will solve the problem. I trust that the rest of the team will have theirs done by Wednesday as well.

Monday, February 11, 2013

Line 9: Squashed?

Since last week we have all made progress on our assigned bugs. We should each have at least one ready to commit to the repository on Wednesday at 6:30. Working in Obsidian has made me much more comfortable with the program, and I am beginning to gain insight into how to work with it. My terminology could still use a little work, and I am hesitant to write any official documentation for the project without first running it by Hunter, but I am getting there. That is the important bit.

My bug was to come up with a more comprehensive method for naming method tests, and classes that Obsidian has to create. Formerly, the code was just appending Test to the end of these things; however, this was dangerous because of the frequency with which programmers write test classes with exactly that naming scheme. This would cause Obsidian to confuse itself when it was searching for something like ClassTest.java for instance. The actual test class for this would be called ClassTestTest.java which would not be what Obsidian was looking for. This is a pretty simple fix, but it is an important one none the less.

We came up with a few different ways of naming method tests, but as of yet we have no clever implementation for the Class tests. At first, we were going to name a method following a method that reflected its arguments. For instance, add(int i, int x, String s) would become addTwoIntOneString() when Obsidian had created the tests for it. This has the benefit of creating distinct method signatures for overloaded classes, but we ultimately shied away from this approach. Some members of our team felt that the method names might become too long this way, and opted for a simpler approach.

 The new method that we finally agreed on was much simpler. It takes any method name, and basically creates a test method that looks like this Test_<methodName>_#. The number will only appear if the method is overloaded, and from there it increments upwards. In order to make a more distinct link between these generic method names and the methods they originated from, Laryea has agreed to write some code to put a comment before each test method that will name its "parent" method.

This weekend also saw a large expansion in our Google Code Wiki's functionality. We planned out the basic structure last week, and over the weekend I created most of the pages and added information where I could. It also has a navigation bar now, which makes navigating the pages much more convenient. It is really coming along, and it will only get better from here forward.

One slight problem that I had during the creation of the wiki was the state of JUnit. The project seems to be migrating, and their home page is looking quite unimpressive at the moment. They also seem to have removed their source code from where it was being hosted. This was bothersome because it would have been nice to link them on the wiki. We decided to wait a week or so and see if they get it back up before we link to it though.

Wednesday, February 6, 2013

Line 8: This bugs me

Today, Team Obsidian met again to further discuss our POSSCON plans. We finished writing up our proposal for the table, and Hunter is going to get criticisms from Dr. Bowring tomorrow morning. This meeting was very short, and the only thing we worked on was the proposal. I hope that this proposal will get us a table so that we can really open up our project to the community at large.

We have also been given some exercises to complete for class tomorrow. Most of these focus on getting further involved with bug fixes for our OSS projects.

6.4
The oldest active bug on the Obsidian project is the request for a better naming algorithm for naming test classes. The current method for creating them can create a bug when test classes have already been created. This bug will be fixed by creating a new method for naming the test classes that will follow the same flow as naming method tests. The way that it is now, there is just a very static procedure for naming test cases. This bug doesn't seem like a very hard fix, so I have chosen to solve it for my first bug fix.

6.5
This exercise was to create an account on the bug tracker for our project, so that we can solve and create bugs in the future. This exercise doesn't really have any impact on our project because we are in charge of making the bug tracker, so we have all already created accounts for our issue tracker.

6.6
The next exercise was to try to reproduce a bug from our project. I accomplished this pretty easily, because the project that we are running Obsidian on, Common Lisp for Java, reproduces the bug I mentioned before very easily. As part of our meetings this week every member of our team met with Hunter to discuss and reproduce our bugs. During my meeting we discussed strategies for solving these bugs, and we also reproduced the ones that I had taken responsibility for.

6.7
Our final exercise had us perform triage on 5 bugs. This is basically laying the groundwork for solving them, and making them easier to solve as a result. Since we are such a tight knit team, most of these are also redundant activities for us. We classified these bugs according to severity and priority when we uploaded them to our issue tracker, and we are all aware of their effects and scope.
I did find it rather helpful information though, because it let me know that the team was on the right track with our meetings and bug discussions. It will also be useful information in the future.

The other thing that I did today was taking a tour of Sparc. Sparc is a local company that predominantly does software design for the government. They have been branching out into more open software recently, and they seem like a pretty fun company to work for.

Our tour basically took us around their office, and we briefly met a few key members of the organization. The whole office is a large open area with lots of pathways between the teams. They follow the agile approach to programming, and seem to focus on their employees a lot. Overall it was a pretty good tour.

Monday, February 4, 2013

Line 7: Bug Juice

When we last left off the team had divvied up duties on enhancing the Obsidian project, and had started to populate our Issue Tracker on Google Code in honest. As we worked and issues popped up, we would log them and move on with our lives. As of writing this, our Issues tracker has 18 total issues, a few of which are our entries for enhancements to the projects, and 4 of which are bugs that we have already fixed.

It was kind of heartening to see progress being visibly made on the project, but the enhancements themselves were very slow going. Most of us are still rather unfamiliar with Obsidian, so coming up with ways to implement the changes without breaking the whole thing was rather difficult. Although last time I said that creating class diagrams of the code had vastly improved my understanding of it, it was apparently not improved enough. Hunter however had no problems with talking out these problems and helping us along with our parts. He also made somewhat stunning progress on his own code, and refactored an integral class to be a bit more generic and better structured.

The delivery date we set for ourselves for this first pass of enhancements was this Wednesday, but when we had our meeting today  it was apparent that we were probably not going to make that. Apparently, despite Hunter's valiant efforts, we were still to unfamiliar with this project to be of this much use to it. So, we reexamined our strategy and changed our plans. We decided that Hunter would be in charge of added the enhancements we had discussed to Obsidian, while the rest of us would take more of a supporting role on the project and fix up the bugs that we had found, and that were sure to pop up in the future. We distributed bugs to the group members and made a plan to meet with Hunter to discuss them in depth in the next two days.

The reason we decided to change the duties around this way was mainly to speed up the project. This is because we hope to speak to some of the organizers of POSSCON about possibly getting a table or booth to show off our project. We feel that we can reach a large audience this way, and that would really help our project take off. With this in mind, we have to have all of our documentation, code, and cursory information online by March 27. We are of course shooting about a week ahead of that so that we have a buffer period to finish any unfinished items.

One other small victory that we won was obtaining the Google Code URL for just obsidian. We had previously been at obsidian-unit-test-generator, which was much more of a mouthful. Hunter contacted the owner of the Obsidian Game engine project and he agreed to give us his URL, as his project had not taken off the way that he wanted it. This makes us much easier to find and will hopefully prove useful in the future.

Wednesday, January 30, 2013

Line 6: Reflections on Open Source in Today's World

Our assignment this week was to become a bit more knowledgeable on the Open Source world. To this end we read a few articles on http://opensource.com/, and also downloaded and built an open source game called Freeciv.

Since Freeciv was pretty straightforward for me, I will talk about that. I didn't really have any problems downloading or building it, because the directions were fairly easy to follow. This is not to say that they were straightforward or direct however. They tended to meander and lead you on a lot of false trails in an effort to make you fail and teach you how to research problems for yourself. While I can appreciate leading people through the steps they need to solve their own problems, I did not particularly enjoy being jerked around by my book. Though I suppose that in the end, it did manage to give me proper step by step instructions for building Freeciv. Either way, this part of the assignment really didn't give me any problems besides a slight amount of annoyance.

For my first reading from the website, I chose to read 10 ways to get started with open source,  by Jason Hibbets. I found this article very informative, and while I had done a few of the steps already, it did provide further insight into how to become further ingrained into the open source community. One of the things that I really found helpful in this article was the link to The Open Source Way. This is an online book that tells you how to get involved with open source communities or how to create your own. I didn't read all of it, but it looks like it will make a valuable resource in the future of our team.

The next article I read was about teaching Python to Children. This article was a basic book review that helps lay out groundwork for teaching python to children. The author seemed very pleased with it, but was more interested in passing along his love for programming to children. He reviews the book and finds it a worthwhile resource for helping to teach adults to teach children python.

My team also had a meeting tonight as well. We split up responsibilities for added functionality to Obsidian, and even solved a bug or two. To assist in understanding Obsidian as a project, we all made UML Class diagrams of the project to help us visualize it. I think this was a very good idea, as it allowed us to each come with questions about the project, and really engage with it in a meaningful way. It also has the added bonus of giving us readable UML Diagrams that we can include in our later documentation of the project.

My part of the project is the first step of Updating, which will allow Obsidian to look at tests that it has already created and determine if it needs to remake them. This kicks in when Obsidian is run twice on the same project of course. We determined the first step in this process is to read in the preexisting tests, so that we have something to compare the new version with. This seems rather simple, but as it is my first step into programming on this project I have a slight amount of trepidation. I have a whole week to get this functionality built, and a whole team to support me though, so I have high hopes.

Monday, January 28, 2013

Line 5: Subversion Under Control

Our assignment for this week was to install subversion and get it up and running on our machines. We were to play around with it a little bit, and then download our projects and build them. To this end, Team Obsidian, decided to hold a meeting tonight to get all of our members up and running.

In the last week or so, Hunter got Obsidian posted to a subversion repository hosted at the school. We were all given access to our own little branch of the repository where we may look at, and play with his code, but not actually effect it in any way. We will quickly move out of this state, but for now we all agreed it would be safer for us to learn in an environment where we can't destroy the whole project. We made plans for committing bug fixes in the future, which will involve us going through our code with another member of the project in the hopes that this will prevent faulty code from being pushed. We are also planning on having weekly code reviews, to discuss what our efforts should be focused on each week. Overall, I think these are good precautions to take, and will help us to really focus our efforts and make good progress in bug fixes and making the code more robust.

We are all using the subversion plugin in the NetBeans IDE to commit and checkout our code. This was fairly easy to set up, because you can just run it from inside the IDE. After all members had the project downloaded, Hunter gave a short demonstration of Obsidian and then walked us through the code. He did an admirable job, but as this project is a large amount of code to process, I think I will need to really study it more on my own before I truly get the hang of what it is doing.

Since last I wrote in here, we decided to break from the milestone schedule that we had set for ourselves. The duties we had broken down were each of varying difficulties and lengths, and while some might take all 4 milestones to complete, others would barely take one. Instead, we opted to work on our code base exclusively for the first 2 milestones. This allows each of the members to get familiar with Obsidian, and gain a good understanding of how it works. This way, when we start working on documentation of the project, we will each have that understanding to draw from. We hope that this will make the documentation that much better in the long run.

That being said, I am still going to focus some of my efforts on getting the IRC Channel fully up and running in the next few weeks, and the other members will most likely be tinkering with their given assignments as well. We are just not focusing exclusively on them right now.

We ended our meeting with each member having a working copy of the source code, and a basic understanding of how to utilize it. We will be meeting tomorrow morning to discuss what needs to be done in the coming week.

Wednesday, January 23, 2013

Line 4: Joining the Project

After forming teams officially last class period, we all jumped into the projects that we chose to pursue. My team, Team Obsidian, had been unofficially meeting for a week or so prior to forming. We used this time to lay the groundwork of our project, and develop a tentative presence online for it. Included in these tasks was setting up an IRC channel, mailing lists, a Google Code page, and the beginnings of our team, and project wikis. We also set a schedule to work by, with milestones being due every 2 or 3 weeks. Hammering out details like this and coming up with a cohesive plan to launch Obsidian into the world of open source software really allowed us to take an active stance on our work.

We accomplished all of the tasks listed above, and are now refining each of them so that by the end of the semester we will have a fully functioning open source community. These accomplishments felt like a major step for our group cohesion, and allowed us to start developing real bonds of trust between each other.

Personally, I was responsible for registering our IRC Channel and Twitter account. Since Twitter was the easier of the two tasks, I attacked it first. We decided in our preliminary meeting that we would be using twitter as a sort of quick news post for our project. @ObsidianTesting will be currently posting updates about what we are working on. Later in the semester it will be more of a tool for communicating with the community we hope to create. The IRC Channel was something that Mike and I worked on together. We looked into a few channels on freenode.net, and registered #obsidiantesting as our own. One channel we looked at before registering ours was #obsidian, however it had a single user idling in it every time we checked. Since the room was created by the freenode staff, we decided that we will ask them for ownership of it in the future, when we have a more comprehensive online presence for the project.

When the group met today, I brought the rest of them up to speed on IRC basics, and got them up and running. They each discussed their parts of the project and we made plans to meet again on Monday.

For now, it looks like my responsibilities will lay mostly with the IRC channel and the twitter account. I plan to talk to Dr. Starr about some twitter accounts he feels would be worthwhile for us to follow. I also am going to begin tweeting updates about our project, so that we can hopefully begin to get some followers. In regards to IRC tasks, my next plan is to add a bot to sit in the channel for us. The bot will be in charge of issuing op commands for the channel when we message him with the commands. This allows us to appear as regular users, which Michael says is important so that we do not scare off new visitors to the channel.

All in all, I think this was a good start for our team.

Tuesday, January 22, 2013

Line 3: FOSS Experiences and Reflections

Over the weekend we had a mini exercise to give us a refresher on downloading and building open source software. We were simply expected to get any open source project, and construct it on our machine. Since I am working with Team Obsidian, and Hunter is still putting some finishing touches on his code before he makes it public to us, I downloaded and built my project from last semester again.

Last semester I worked with a team to develop an automated testing framework for the Google Visualization Suite, specifically focusing on Google Charts. So, I re-downloaded and built the code again on my machine. It went off pretty much without a hitch, since I had done the same thing a semester ago.

With that done, I set about on some activities for my team. I had been put of setting up the IRC channel for our project on freenode.net. We discussed using freenode, because it is very popular among open source projects. So, Michael Cole and I went onto IRC to play around and check out some channels. We investigated #obsidian, #obsidiantest, and #obsidiantesting. The #obsidian room had another person in it, but both other rooms were not owned at all. We decided to register #obsidiantesting for now, and try to obtain the room #obsidian in the future, as it does not seem to be in active use.

After this, I tackled the second part of our homework. This was to read the paper “The Cathedral and the Bazaar” by Eric S. Raymond. This paper was about the author’s experiences as he was developing a mail client using Linus Torvalds’ approach to open source software development. These principles basically come down to releasing early and often, and allowing as many people to help you develop as you possibly can. He compares this approach to a Bazaar, where anyone can set up and contribute to the market in their own way. This is in comparison to traditional software development, in which a few designers are responsible for all major decisions. They decide the direction of the project, and are ultimately responsible for the final incarnation.

He compares and contrasts the two methods, and ultimately walks away very impressed with the bazaar style. He numbers out notions that he considers to be very important to this development style, from the very easy release early and often, to other findings. One that really grabbed my attention was the idea that if you communicate with your beta testers like they are your greatest asset, they will become your greatest asset. I liked this part, because he talked about many methods of communicating with his testers, and how they met his enthusiasm with equal enthusiasm of their own.

One other thing I found interesting was his theory on why Linux has such a high quality of code. He posits that because the people working on the project are so excited about the part they are working on, they make it much better than they would had they been forced to work on something they were not interested in or did not love. I agree with this theory quite a bit, and I think that it bodes well for our project. All of our team members seem to be very enthusiastic and proactive about tackling the parts of the project that they were assigned.

Wednesday, January 16, 2013

Line 2: My FOSS Preferences

The first step to contributing to an open source project is obviously to research which one you want to contribute to. My search for a project was probably a little bit different from many of my classmates’ because I was approached by some classmates who already had a project in mind. However, I still did a little bit of research on my own. I will use this opportunity to talk about 2 open source projects, before I talk about the project that my classmates want me to join them on.

One of the famous open source software projects is Mozilla Firefox. It is an open source web browser is developed for Windows, OSX, and Linux platforms. It is probably one of the more popular open source projects that I am familiar with. In fact, Firefox is my web browser of choice. One of the interesting things about it is the high amount of add-ons for it. These work to help the user customize their browser and add functionality to it.

Another large open source projects is the Linux operating system. This project exists to give users a choice of a free operating system that is able to compete with major commercial releases. Linux is also fully customizable, and many users have created many different forms of it. These Linux distributions allow users to have a choice in how they want the operating system to run. Some distros emphasize speed, while others focus more on ease of use. Anybody can create their own Linux distro and release it to the public. If it becomes popular enough, then the community at large might adopt it. This type of approach to software is highly indicative of the open source mindset. You are able to take the base releases, and add to them until they are suitable for your needs.

However, it is unlikely that I will work on either of these projects, because as I said before, I was approached by a group to help them with their project. Michael Cole, Hunter Hegler, Joanna Illing, and Laryea Quaye asked me if I would help them work on creating the community for an open source project. I can’t say much about the project right now because the paper describing it has not been presented to the community at large, but I can say that it is called Obsidian, and is test case creation software. Like I said earlier, this semester we will be responsible for trying to foster a community for this project. This will require us to make a wiki to tell people how to get our software up and running, an IRC channel where people can ask questions in a live environment, creating a website for the software, and many other tasks to get people to adopt Obsidian.

Overall, I am very excited by this project right now. I like the idea of trying to create a community for this project. We will also be trying to make the software better throughout the semester, but I think that the majority of our time will be focused on getting this software’s name out there. I feel like there is a lot to learn from this, and I look forward to the semester eagerly.

Monday, January 14, 2013

Line 1

The purpose of this blog is to chronicle my time spent working and learning in the Software Engineering Practicum at the College of Charleston. This class is meant to expose students to open source projects, and have them jump in and start contributing to these projects. The end goal is we, the students, develop our programming skills in a real world environment, and also better the programming world through our efforts. Later in the semester we will be attending the Palmetto Open Source Software Convention, or POSSCON for short. We will be meeting with members of the open source community and discussing their projects, and our own experiences in the open source community with them. I am actually looking forward to this event quite a bit, as other tech community events such as Charleston Barcamp and the Pecha Kucha talks have both provided excellent experiences to me.

As this is my first post, I suppose I will provide a slight introduction for myself. I am Micah Jenkins. I am a senior at the College of Charleston, majoring in Computer Science. I first began programming when I was a junior in high school, and grew to love it from there.

This class marks the second half of a yearlong class chain that focuses on software engineering, and the techniques and organization that the discipline requires. Last semester we were split into groups and required to develop an automated testing framework to test an open source project of our choosing in Linux. My group last semester worked on the Google Visualization suite, which is a tool for generating and manipulating data and outputting it into HTML code for embedding in websites.

My team generated 25 unique test cases that test different parts of  the source code, and an automated framework to run and report on these test cases. We also developed a poster that will be shown at the College's Math and Science Poster Session.

That experience was immensely valuable to me, and it really opened the door for this semester. We picked up many skills, such as usage of online repositories like subversion, knowledge of scripting to automate processes, and gaining familiarity with Linux (specifically the Ubuntu distribution). It was a great preparatory experience and got me excited to actually contribute to one of these projects this semester rather than just extensively test on one.

So far, we have created a class wiki where all of our class blogs are linked, and we are all going to be blogging about 1000 words a week on our progress. By the end of this projects, we hope to have contributed in some way to the open source project we choose as groups, whether this be by doing bug fixes, or trying to help out in the community. Some projects will be big, and others will be small. Some might even require their groups to create the community for them by setting up wikis and how-to instructions for building and running the code. The projects I have researched so far all seem to have middling to large communities, but I think that working on a small project could be a very rewarding experience as well. This project, and semester, looks to be quite an interesting one.