I would like to reflect today about what a good time I had at the conference on Wednesday. And not just because of all the free stuff, although the stuff was pretty cool. Hacker playing cards? Check. Ubuntu stickers? Of course. And a myriad of other neat things. But the real value in the conference was all of the speakers that came and spoke passionately about open source software.
The first speaker that I went to see was my professor, Dr. Bowring. He used some of our blog posts to illustrate his approach to teaching a Software Engineering course. In the first semester, this approach begins with having teams within the classroom pick an open source project they find interesting and testing various components of that project. For the second semester, which is called the Practicum, the teams up the ante by becoming part of a project's community and contributing something meaningful like patches to the project's code base, plug-ins , and/or documentation. What this does is make the entire year a capstone project that ties together everything that the student has learned in Computer Science thus far. I'm really lucky to have been a part of the experience, and encourage other professors to consider using this approach. It beats just regurgitating passages from a textbook.
The next session that I went to see was by Don Taylor, the CTO from Benifitfocus, who talked about their software stack and how it works. They have developed a system that allows 3rd party developers to easily customize web pages that they provide as a service. In fact, that is the essential concept, software as a service. It is a really interesting concept and is right out there on the cutting edge of what is being done in web applications today. Also there was a drawing for an ipad...I did not have the winning ticket.
Next up was lunch. They provided some tasty box lunches as well as a salad bar, and the idea was to take in a BOF (birds of a feather) session while eating your lunch. So I grabbed a box and headed over to see Jon "Maddog" hall, who was going to talk about Linux. Jon has been working in the world of professional computing since 1969 and had a thing or two to say about open source operating systems. And he knows Linus Torvald...on a personal level. He began by talking about how awesome Linux is, and how quickly it caught on in the early years. One of the main reasons that it caught on in the first place was the portability to multiple architectures that was built into the kernel early on. Another reason that it was adopted early on, especially by government agencies, was that because of Linux's relatively small footprint it was easy to parallel multiple machines for the purpose of supercomputing. Apparently this filled a vacuum left by Cray supercomputers, who went bankrupt in the mid-90's. Maddog wrapped up by taking questions, one of which was from a 14 year old in the audience. The question was, why open source and not Apple OS or Windows? Maddog's response: control. Open source give you control over the source code that enables a user to customize and fix whatever is needed. Well said, sir.
The last session that I attended was the presentation by Dr. Steven Brodsky from IBM. He gave a really cool speech about Big Data and the methods that IBM uses to sort meaning from the 1.8 zettabytes of information that is out there. One of the techniques that he talked about was called "map reducing" of data. What happens is that vertical and horizontal slices of large data sets are taken, and then frequency counts are done on those slices. It is a very quick and efficient way of dealing with these sets. He also talked about Watson, the supercomputer that beat the two best contestants in Jeopardy history. Watson uses a process called Deep QA for cluster processing all of the data that was needed to compete on the show. I actually worked up the nerve to go up and talk to Dr. Brodsky after his presentation, and ask him a little bit about future applications for Watson. I specifically asked if he thought Watson could ever be used as a diagnostic tool in a medical setting. While he did not speculate on that possibility, he said that research is being done right now to investigate if Watson could be used as a sort of call-in reference for prescription drug interactions. And that was it! My pulse then returned to normal.
Altogether I mark this off as a great experience that was totally worth waking up at 5am for. I look forward to attending next year as a software professional instead of a student, and can't wait to see how things change and improve over the next year.
Friday, March 30, 2012
Monday, March 26, 2012
POSSCON 2012
POSSCON, an open source software conference in Columbia, SC, is coming up on the 28th and 29th this week and it's time to do a little planning. The only day that I have available to attend will be on Wednesday the 28th, so I'll be riding up there in the van bright and early with some of my fellow CS students that day. As far as planning goes, I have whittled the speakers down to six that I'd like to see. Realistically speaking, I may only see four if there are other things to see or do. I'll list them here in order of time-slot...mainly to organize myself for the day:
Jim Bowring 10:00 am - 10:45 am
Dr. Bowring is the professor who is teaching the class that I write this blog for. His presentation is actually on the class, an upper-level software engineering practicum course, and the benefits of using open source projects as a tool for teaching the material. As a student in the course, I can probably help with his presentation by providing experienced-based feedback to the audience.
Steven A. Brodsky 1:00 pm - 1:45 pm
Dr. Brodsky is the keynote speaker for the day, and holds the title of Distinguished Engineer at IBM. Just could not miss this one. He will be speaking about the Hadoop open source framework, big data, and open source in general. It will be a real treat to hear what he has to say, and then corner him and speak to him in person!
Jim Jagielski OR Carol Smith 2:00 pm - 2:45 pm
Having a real hard time deciding which one of these I want to check out. Mr. Jagielski is a SR. Consulting Software Engineer for Red Hat and will be speaking about open source licensing. Carol Smith is a Program Manager for Google and will be presenting on the Google Summer of Code. This is going to be a tough one.
Dave Abrahams 3:00 pm - 3:45 pm
Mr. Abraham is a founding member of Boost.org, a site that provides C++ libraries. His topic will be on...C++! I'm a big fan of C and C++, and look forward to talking to him.
Chris Hinkley 4:00 pm - 4:45 pm
Mr. Hinkley is a Senior Security Engineer at Firehost, a company that provides secure cloud hosting. I picked this presentation because I have an interest in web hosting, and it will be cool to see how security figures into everything.
And that's my plan! I still need to sit down and come up with some talking points for each speaker, but other than that I think I'm ready. Should prove to be a fun day.
Jim Bowring 10:00 am - 10:45 am
Dr. Bowring is the professor who is teaching the class that I write this blog for. His presentation is actually on the class, an upper-level software engineering practicum course, and the benefits of using open source projects as a tool for teaching the material. As a student in the course, I can probably help with his presentation by providing experienced-based feedback to the audience.
Steven A. Brodsky 1:00 pm - 1:45 pm
Dr. Brodsky is the keynote speaker for the day, and holds the title of Distinguished Engineer at IBM. Just could not miss this one. He will be speaking about the Hadoop open source framework, big data, and open source in general. It will be a real treat to hear what he has to say, and then corner him and speak to him in person!
Jim Jagielski OR Carol Smith 2:00 pm - 2:45 pm
Having a real hard time deciding which one of these I want to check out. Mr. Jagielski is a SR. Consulting Software Engineer for Red Hat and will be speaking about open source licensing. Carol Smith is a Program Manager for Google and will be presenting on the Google Summer of Code. This is going to be a tough one.
Dave Abrahams 3:00 pm - 3:45 pm
Mr. Abraham is a founding member of Boost.org, a site that provides C++ libraries. His topic will be on...C++! I'm a big fan of C and C++, and look forward to talking to him.
Chris Hinkley 4:00 pm - 4:45 pm
Mr. Hinkley is a Senior Security Engineer at Firehost, a company that provides secure cloud hosting. I picked this presentation because I have an interest in web hosting, and it will be cool to see how security figures into everything.
And that's my plan! I still need to sit down and come up with some talking points for each speaker, but other than that I think I'm ready. Should prove to be a fun day.
Sunday, March 25, 2012
RMH Homebase Exercises: Editing the "Person" Class
The following exercises are from the SD book They involve editing and refactoring the "Person" class of the RMH Homebase open source project.
Ex. 6.1
This exercise involved adding in some setters and getters for some new instance variables that were added to provide new functionality. The new variables were $status, $employer, $contact_person, and $contact_phone.
All of the setters look like this:
function set_employer ($value) {
$this->employer = $value;
}
And all of the getters have this simple structure:
function get_employer () {
return $this->employer;
Ex. 6.2
Here we are instructed to add our new parameters to the constructor for the "Person" class. I went in and modified the constructor to include the following variables : $status, $employer, $contact, and $contact_phone. I then initialized them like this: $this->status = $status; , etc...
Ex. 6.3
This problem presents us with a question of how to handle invalid input. In the set_status function, there is currently no check in place to determine whether the $value is either 'active' or 'inactive'. A good way to check this would be with an 'if' statement that would make sure that $value was either 'active' or 'inactive' before setting it to anything. And if $value was an invalid string, then the best thing to do would be go ahead and set $status to inactive in the 'else' clause. This way no one is accidentally set as ready to work a shift.
Ex. 6.4
Now that the code has been modified, it is time to refactor and check things out. This exercise asks to go through all of the setters in the "Person" class that we have been working with, and check and see if they are called from anywhere in the code base. It then says to remove any that are not used. Not wanting to physically read through all the php files to do this, I opened up the files on the workbench in Eclipse. I then went through each setter, highlighting them one by one, and checking the call hierarchy (ctrl-alt-h) to see if they were called from anywhere. Surprisingly, I could not find a single one being used! I didn't delete them yet, as I want to make sure I'm doing this right before proceeding.
Ex. 6.1
This exercise involved adding in some setters and getters for some new instance variables that were added to provide new functionality. The new variables were $status, $employer, $contact_person, and $contact_phone.
All of the setters look like this:
function set_employer ($value) {
$this->employer = $value;
}
And all of the getters have this simple structure:
function get_employer () {
return $this->employer;
Ex. 6.2
Here we are instructed to add our new parameters to the constructor for the "Person" class. I went in and modified the constructor to include the following variables : $status, $employer, $contact, and $contact_phone. I then initialized them like this: $this->status = $status; , etc...
Ex. 6.3
This problem presents us with a question of how to handle invalid input. In the set_status function, there is currently no check in place to determine whether the $value is either 'active' or 'inactive'. A good way to check this would be with an 'if' statement that would make sure that $value was either 'active' or 'inactive' before setting it to anything. And if $value was an invalid string, then the best thing to do would be go ahead and set $status to inactive in the 'else' clause. This way no one is accidentally set as ready to work a shift.
Ex. 6.4
Now that the code has been modified, it is time to refactor and check things out. This exercise asks to go through all of the setters in the "Person" class that we have been working with, and check and see if they are called from anywhere in the code base. It then says to remove any that are not used. Not wanting to physically read through all the php files to do this, I opened up the files on the workbench in Eclipse. I then went through each setter, highlighting them one by one, and checking the call hierarchy (ctrl-alt-h) to see if they were called from anywhere. Surprisingly, I could not find a single one being used! I didn't delete them yet, as I want to make sure I'm doing this right before proceeding.
Friday, March 23, 2012
SD Chapter 6: Developing the Domian Classes
The author's use chapter 6 of the SD book not only to define what domain classes are, but to also use the example of domain classes to teach a few key lessons about general code improvement. Those lessons include getting to know a new code base, class design principles, and refactoring.
For getting familiar with a new code base, the chapter begins by going over how to read a design document. This includes identifying classes, basically looking for 'nouns' (if the code is written effectively), finding the instance variables, and figuring out where the methods and functions are. After getting this basic feel for the code, they then go into how to actually read the code. For this, the book lays out three key goals:
1. To understand the overall architecture and functionality of the existing software.
2. To learn the vocabulary established by the domain classes.
3. To identify the extent to which to which the code must be refactored before it can be modified
to support the functions of the new system.
After a lengthy section on modifying the domain classes, there is this tiny section, section 6.3, which neatly sums up how to design an effective class:
1. Is there a need? In other words, is this functionality already elsewhere in the code base.
2. Information hiding...private on those instance variables!
3. Object integrity. Basically initializing all instance variables with a constructor.
4. Cohesion. The class should be responsible for only one job.
5. Coupling. Kept to a minimum.
6. Accessors. Or getters.
7. Mutators. Or setters.
And lastly, the book goes over the importance of refactoring. In this section it talks about removing useless functions in the code base. Are the setters and getters ever even used? Is the function either redundant or useless? If so, get it out if there. All together this chapter provided a good review of material that every developer should be familiar with and have tattooed on their forearm.
For getting familiar with a new code base, the chapter begins by going over how to read a design document. This includes identifying classes, basically looking for 'nouns' (if the code is written effectively), finding the instance variables, and figuring out where the methods and functions are. After getting this basic feel for the code, they then go into how to actually read the code. For this, the book lays out three key goals:
1. To understand the overall architecture and functionality of the existing software.
2. To learn the vocabulary established by the domain classes.
3. To identify the extent to which to which the code must be refactored before it can be modified
to support the functions of the new system.
After a lengthy section on modifying the domain classes, there is this tiny section, section 6.3, which neatly sums up how to design an effective class:
1. Is there a need? In other words, is this functionality already elsewhere in the code base.
2. Information hiding...private on those instance variables!
3. Object integrity. Basically initializing all instance variables with a constructor.
4. Cohesion. The class should be responsible for only one job.
5. Coupling. Kept to a minimum.
6. Accessors. Or getters.
7. Mutators. Or setters.
And lastly, the book goes over the importance of refactoring. In this section it talks about removing useless functions in the code base. Are the setters and getters ever even used? Is the function either redundant or useless? If so, get it out if there. All together this chapter provided a good review of material that every developer should be familiar with and have tattooed on their forearm.
Wednesday, March 21, 2012
Changing Focus
We had a really good team meeting on Sunday regarding our project. Here are the highlights:
1) Matthew and James received a good response on the bug that they were able to replicate. Apparently, the bug was a forgotten and dead issue until they got involved. By posting their success at replicating the bug, they were able to get the developers involved to help solve the issue.
2) I was finally able to get a bug to replicate, on one which involved menu options. The only problem was that as soon as I got involved in the patch process, one of the developers fixed the problem before i was able to submit the diff.
3) David made some headway with his Wiimote bug. He was able to use a Bluetooth usb device to connect the Wiimote and test out the user's problem. Unfortunately, he was unable to replicate this one.
And that ended up being what caused us to initiate a change of focus in relation to our project. The nature of xbmc causes the complexity of the bugs to range from extremely hard to replicate, like something involving a specific file format or driver, to relatively easy, like the one I had with menu options. The ones which fit into our scope, easy enough to be tackled in a few days or weeks, are usually solved by developers before we have a chance to.
So in order for us to contribute meaningfully to the project before the semester is out, we decided to go in and clean up the wiki. The first paragraph of the first page of the wiki is a desperate plea from the developers for assistance. They need help getting the pages up to date with respect to the newest Eden release. In addition, there are many pages out there from earlier releases that still need to be updated. Some of them still point to the old subversion repository, and now the repository is hosted using GIT. We will be meeting up again on Thursday to figure out who is going to do what.
1) Matthew and James received a good response on the bug that they were able to replicate. Apparently, the bug was a forgotten and dead issue until they got involved. By posting their success at replicating the bug, they were able to get the developers involved to help solve the issue.
2) I was finally able to get a bug to replicate, on one which involved menu options. The only problem was that as soon as I got involved in the patch process, one of the developers fixed the problem before i was able to submit the diff.
3) David made some headway with his Wiimote bug. He was able to use a Bluetooth usb device to connect the Wiimote and test out the user's problem. Unfortunately, he was unable to replicate this one.
And that ended up being what caused us to initiate a change of focus in relation to our project. The nature of xbmc causes the complexity of the bugs to range from extremely hard to replicate, like something involving a specific file format or driver, to relatively easy, like the one I had with menu options. The ones which fit into our scope, easy enough to be tackled in a few days or weeks, are usually solved by developers before we have a chance to.
So in order for us to contribute meaningfully to the project before the semester is out, we decided to go in and clean up the wiki. The first paragraph of the first page of the wiki is a desperate plea from the developers for assistance. They need help getting the pages up to date with respect to the newest Eden release. In addition, there are many pages out there from earlier releases that still need to be updated. Some of them still point to the old subversion repository, and now the repository is hosted using GIT. We will be meeting up again on Thursday to figure out who is going to do what.
Thursday, March 15, 2012
Possible Bug Fix Progression
Our team has finally been able to reproduce a bug for our xbmc project. The problem comes in whenever the controller is unplugged from the machine, which causes the program to crash. We were able to reproduce this bug by first unplugging the controller, putting the program into the background through alt-tab and waiting for around four minutes, then bringing xbmc back into the foreground. One of our group members, Matthew, was able to reproduce it on both his laptop and PC. Then comes in the problem.
The developers can't reproduce it! And also the problem is starting to look like a Windows-version problem, and we are all using the Ubuntu version. Also a quick bit of insight into working with users when trying to get these bugs fixed.
It seems like the biggest hurdle to initially cross is to get multiple people (users and developers) to agree when and how the bug occurs, and under what conditions. A certain set of people may be able to replicate the bug following a certain sequence of events, and some can only get it to happen sporadically. Or not at all. Updates to come.
The developers can't reproduce it! And also the problem is starting to look like a Windows-version problem, and we are all using the Ubuntu version. Also a quick bit of insight into working with users when trying to get these bugs fixed.
It seems like the biggest hurdle to initially cross is to get multiple people (users and developers) to agree when and how the bug occurs, and under what conditions. A certain set of people may be able to replicate the bug following a certain sequence of events, and some can only get it to happen sporadically. Or not at all. Updates to come.
Monday, March 12, 2012
Patent Law and Open Source Software
I thought that I would relay some information regarding the everyday legal dangers that open source software faces every day, by presenting a couple of really good articles from opensource.com. The first one, from 2010, shows how rationality sometimes saves the day.
In Total Victory for Open Source Software, Rob Tiller describes a lawsuit brought against Red Hat by two plaintiffs claiming patent infringement. The article relates the details of the case a lot better that I can, but what it boils down to is certain interests trying to break the open source model. The reason they want to do this is money, pure and simple. And what makes this case so interesting is that the plaintifs' argument was so full of holes, that they resorted FUD, or fear, uncertainty, and doubt tactics.
The plaintiffs jumped on the fact that the members of the jury had no knowledge of what open source software was, and immediately tried to paint Red Hat as some king of communist collective. The exact terminology used to describe Red Hat's criticism of US patent law was that Red Hat has "a secret fondness for the writings of Karl Marx"!
Michael Tiemann, Red Hat's vice president of open source affairs, stepped in for the defense and calmly explained to the jury exactly what open source is. He explained that open source is all about "voluntary collaboration, not involuntary expropriation". Red Hat's argument carried the day, but the fight still goes on.
A continuation of this fight is detailed in Julie Samuels' article, Why the Patent System Doesn't Play Well With Software: If Eolas Went the Other Way. In the article she talks about a recent victory over the Eolas patents. These patents were established during the days of the early web and enabled viewing of embryos. Now the people owning these patents claim that they cover "any mechanism used to embed an object in a web document". This would have effectivly given these people ownership of the web, and the jury thankfully invalidated these patents. Then Samuels goes on to make a very effective argument about why patents and software do not go together.
First of all, she shows that when the patent system was originally established, the 20 year protection period was needed for an inventer to develop an idea into something marketable. That does not make sense with software. Technology moves so quickly that this time investment just isn't needed anymore. And how can someone build upon someone else's code if it is locked away for 20 years?
Then she goes on to show how software patents can harm new ideas and innovations. How can a lone programmer developing the next Twitter in his home office operate after he is slapped with a patent suit? All of these reasons come together to show that the US patent system is outdated and is in need of some serious reform. And in the meantime, stay out of our code.
In Total Victory for Open Source Software, Rob Tiller describes a lawsuit brought against Red Hat by two plaintiffs claiming patent infringement. The article relates the details of the case a lot better that I can, but what it boils down to is certain interests trying to break the open source model. The reason they want to do this is money, pure and simple. And what makes this case so interesting is that the plaintifs' argument was so full of holes, that they resorted FUD, or fear, uncertainty, and doubt tactics.
The plaintiffs jumped on the fact that the members of the jury had no knowledge of what open source software was, and immediately tried to paint Red Hat as some king of communist collective. The exact terminology used to describe Red Hat's criticism of US patent law was that Red Hat has "a secret fondness for the writings of Karl Marx"!
Michael Tiemann, Red Hat's vice president of open source affairs, stepped in for the defense and calmly explained to the jury exactly what open source is. He explained that open source is all about "voluntary collaboration, not involuntary expropriation". Red Hat's argument carried the day, but the fight still goes on.
A continuation of this fight is detailed in Julie Samuels' article, Why the Patent System Doesn't Play Well With Software: If Eolas Went the Other Way. In the article she talks about a recent victory over the Eolas patents. These patents were established during the days of the early web and enabled viewing of embryos. Now the people owning these patents claim that they cover "any mechanism used to embed an object in a web document". This would have effectivly given these people ownership of the web, and the jury thankfully invalidated these patents. Then Samuels goes on to make a very effective argument about why patents and software do not go together.
First of all, she shows that when the patent system was originally established, the 20 year protection period was needed for an inventer to develop an idea into something marketable. That does not make sense with software. Technology moves so quickly that this time investment just isn't needed anymore. And how can someone build upon someone else's code if it is locked away for 20 years?
Then she goes on to show how software patents can harm new ideas and innovations. How can a lone programmer developing the next Twitter in his home office operate after he is slapped with a patent suit? All of these reasons come together to show that the US patent system is outdated and is in need of some serious reform. And in the meantime, stay out of our code.
Subscribe to:
Posts (Atom)