Wow, this semester has really gone by fast! As this is my last blog post as an undergraduate student, I wanted to use this post to sum up my entire college experience and reflect on everything that's happened over the last few years. Then reality kicked in and I realized that wasn't going to happen...I would need a whole other blog and the fortitude of a level 20 elf mage to even consider such a feat. Instead, I'm going to sum up the last two Software Engineering classes. Here it goes...
Actually, I can sum up the course sequence in two words: teamwork and open source. Both were vital components for the classes and together formed the kernel of what was needed to complete the course work. Make no mistake about it, learning to work with a team is no easy task. In our case, you are dealing with the personalities and habits of four other people who you barely know, having to communicate and coordinate with these people, and your grade depends on it! It can be a scary prospect when first starting out in 362 (the first Software Engineering class). On the flip side of that, it is also a rewarding experience like no other. You make friends that you will continue to know and talk to outside of class. It is really neat figuring out what everyone's strengths and weaknesses are, and then working with those attributes to balance the workload fairly.
The open source component has been gone over extensively in my previous posts...and now I'm going to add a little more! My position on open source software as a teaching tool is simply this: it gives a full-package, complete experience that I don't see happening any other way. You learn how to use tools like virtualbox and subversion, work with raw source code, communicate with developers, and many other things too numerous to list here. It's been a great year...now onto the real world!
Sunday, April 22, 2012
Database Concepts Should be Required
The title says it all! I've had more than a few phone interviews with local companies over the last few weeks, and have noticed a common thread. They have all, in some way or another, asked some kind of question related to databases. These have ranged from simple (what's a relational database) to challenging (tell me the difference between an outer join and an inner join). If I had not taken Database concepts last semester I would have completely choked on at least one of these interviews, where I had a good 5 detailed questions on the subject. So why is this not a requirement? I mean, everything on the internet uses some kind of database for storage (persistence layer to us professionals). Someone graduating with a Computer Science degree without taking this class is left with a huge glaring hole in their knowledge base. I know, I know...we can't make everything a requirement, Jason. Where would we wedge in yet another required course?
Get rid of 350. Plain and simple. This class is interesting and helpful, but definitely should not be a requirement. For those of you unfamiliar with the class, it is the second class (250 being the first) that we are required to take on computer chips and hardware. We are taken on an adventure through the wonderful world of decoders, multiplexers, logic gates, and the like twice. 250 is a good class and should stay in the curriculum by all means. In that class we are introduced into binary, computer logic, and basic circuit design. This is needed and is a good idea. Part 2 is not. The students would be much better served by being given the chance to take Database. In fact, a part 2 offering of DB concepts isn't a bad idea either!
By the way, I did great on all the database questions in my interviews.
Get rid of 350. Plain and simple. This class is interesting and helpful, but definitely should not be a requirement. For those of you unfamiliar with the class, it is the second class (250 being the first) that we are required to take on computer chips and hardware. We are taken on an adventure through the wonderful world of decoders, multiplexers, logic gates, and the like twice. 250 is a good class and should stay in the curriculum by all means. In that class we are introduced into binary, computer logic, and basic circuit design. This is needed and is a good idea. Part 2 is not. The students would be much better served by being given the chance to take Database. In fact, a part 2 offering of DB concepts isn't a bad idea either!
By the way, I did great on all the database questions in my interviews.
Homebase Project Presentation
For my presentation on the RMH Homebase project, I decided to keep things simple...and include some creepy pictures of Ronald McDonald (RMH = Ronald McDonald House) . I broke up the presentation into two parts: the aspect of the project as a learning experience, and how the project as a whole enhanced my knowledge of Computer Science.
Learning Experience
Things that I learned doing this project that I either didn't know before, or had limited experience with, include setting up the LAMP stack, using the Simpletest plugin for Eclipse, using Eclipse for php, and utilizing my fellow students as a resource. I'll not go into the first three here, as I have already extensively blogged on those subjects, but using other students' blogs as a learning tool deserves a little attention.
For the first two or three programming classes that we take here at the college, students are given any number of dire warnings about collaboration on programs or using google to find code examples. And for those courses that approach makes sense. I mean, we are trying to learn Computer Science here. So being given the opportunity in this class to openly use classmates as a resource was a little weird at first. Every time I went through someone else's posts for inspiration I felt like I was cheating! I quickly got over this feeling when I realized that this is probably the way people program in the real world. Open collaboration means that if you are hitting a wall on a problem, chances are someone else on the project has either seen this problem before and solved it or has some helpful input. It is all about getting the project done efficiently and on time. So, thanks for the help everybody! Hopefully a few of my posts helped someone out as well.
Bringing it all together
This project really helped with my understanding of a few key concepts. Those concepts are debugging, refactoring, and unit testing. All three of these ideas are vital in constructing robust and useful software, and represent a good portion of the actual work that I put into Homebase.
That was basically my presentation and accurately represents my experience working with this project. It also gave me the opportunity to incorporate a picture of Grimace eating a small child...behold!!
Learning Experience
Things that I learned doing this project that I either didn't know before, or had limited experience with, include setting up the LAMP stack, using the Simpletest plugin for Eclipse, using Eclipse for php, and utilizing my fellow students as a resource. I'll not go into the first three here, as I have already extensively blogged on those subjects, but using other students' blogs as a learning tool deserves a little attention.
For the first two or three programming classes that we take here at the college, students are given any number of dire warnings about collaboration on programs or using google to find code examples. And for those courses that approach makes sense. I mean, we are trying to learn Computer Science here. So being given the opportunity in this class to openly use classmates as a resource was a little weird at first. Every time I went through someone else's posts for inspiration I felt like I was cheating! I quickly got over this feeling when I realized that this is probably the way people program in the real world. Open collaboration means that if you are hitting a wall on a problem, chances are someone else on the project has either seen this problem before and solved it or has some helpful input. It is all about getting the project done efficiently and on time. So, thanks for the help everybody! Hopefully a few of my posts helped someone out as well.
Bringing it all together
This project really helped with my understanding of a few key concepts. Those concepts are debugging, refactoring, and unit testing. All three of these ideas are vital in constructing robust and useful software, and represent a good portion of the actual work that I put into Homebase.
That was basically my presentation and accurately represents my experience working with this project. It also gave me the opportunity to incorporate a picture of Grimace eating a small child...behold!!
Tuesday, April 17, 2012
In The Home Stretch!! Chapter 8 Exercises
Only one full week of classes left in my undergraduate career! Focus is a difficult commodity to come by these days, but I managed to put off falling into a coma long enough to get this last exercise completed. Now, with no further jabbering:
8.1
This exercise is in three parts and deals with making the default password more secure, as well as making password retrieval a more automatic process.
a) Suggest a more secure definition for default password assignment in RMH Homebase.
I think the best way to tackle this, other that actually have the user create a password upon sign up, is to have the system generate a pseudo-random password consisting of both lower and uppercase characters, and also some numbers and special characters.
b) When a person forgets his password, suggest a way by which the person can recover it without bothering the House Manager
The best way to deal with this would be to have a secret question and answer setup. The user picks through a list of stock questions, picks one, and then provides a pass phrase that is associated with the question.
c) Implement these ideas and then test them.
For the random password generator I made the following function:
<?php
function generatePassword($length=9) {
$special = '@#$%&';
$letters = 'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ';
$password = '';
$alt = time() % 2;
for ($i = 0; $i < $length; $i++) {
if ($alt == 1) {
$password .= $letters[(rand() % strlen($letters))];
$alt = 0;
} else {
$password .= $special[(rand() % strlen($special))];
$alt = 1;
}
}
return $password;
}
?>
The code generates a pseudo-random password of length 9 by alternating through the alphabet and special characters.
For implementing the question/answer password recovery functionality, I created a new module called recovery.php. All this class does is have an array of stored strings (questions) that can be chosen from. Once chosen, the user can then input a pass phrase. Both the question and the pass phrase are stored in a new table in the database. The assignment did not say anything about connecting any of this to the GUI, so I left that part out and just made some new unit tests to make sure everything worked. Done!
8.1
This exercise is in three parts and deals with making the default password more secure, as well as making password retrieval a more automatic process.
a) Suggest a more secure definition for default password assignment in RMH Homebase.
I think the best way to tackle this, other that actually have the user create a password upon sign up, is to have the system generate a pseudo-random password consisting of both lower and uppercase characters, and also some numbers and special characters.
b) When a person forgets his password, suggest a way by which the person can recover it without bothering the House Manager
The best way to deal with this would be to have a secret question and answer setup. The user picks through a list of stock questions, picks one, and then provides a pass phrase that is associated with the question.
c) Implement these ideas and then test them.
For the random password generator I made the following function:
<?php
function generatePassword($length=9) {
$special = '@#$%&';
$letters = 'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ';
$password = '';
$alt = time() % 2;
for ($i = 0; $i < $length; $i++) {
if ($alt == 1) {
$password .= $letters[(rand() % strlen($letters))];
$alt = 0;
} else {
$password .= $special[(rand() % strlen($special))];
$alt = 1;
}
}
return $password;
}
?>
The code generates a pseudo-random password of length 9 by alternating through the alphabet and special characters.
For implementing the question/answer password recovery functionality, I created a new module called recovery.php. All this class does is have an array of stored strings (questions) that can be chosen from. Once chosen, the user can then input a pass phrase. Both the question and the pass phrase are stored in a new table in the database. The assignment did not say anything about connecting any of this to the GUI, so I left that part out and just made some new unit tests to make sure everything worked. Done!
Wednesday, April 11, 2012
Chapter 8 and Password Security Rant
Two big sections of this chapter of the Software Development textbook are about user interface design and software security, respectively. As I have a sizable amount to say about to say about software security and how it relates to password strength, I'll begin with what constitutes a good user interface. Why? Well, because it is good information, everyone has experienced a truly horrible website UI, and someone needs to put the word out there so the healing can begin. The book lists 9 "principles" of good UI design buy I'll only list a small subset of those:
'Chicken1' is not a good password. Changing it to 'Chicken2' does not make it any better. A good article by Chad Perrin talks about how the idea that a good password should be convenient and memorable needs to be done away with as soon as possible. He then goes on to say that one way to be secure and still say sane (try to remember '2%4!G.>_!*5_02' every time you want to transfer money to checking) is to use a good password manager that keeps track of all the various passwords you use. This is good advice. By using a password manager you only have to remember one, and the rest are securely stored and encrypted for you.
- Simplicity. This is probably the most important. The page should walk a knife's edge balancing just the right amount of information on each page, just enough functionality for simple and intuitive navigation to the other pages, and painless viewing of embedded media.
- Feedback and Recovery. What the hell did I just do and how do I get back to where I was? This should never be a problem. Each page should clearly indicate what has been done, provide a way to undo what has just happened, and show the way to what can be done next.
- Security. Users should only have access to the functionality that they are authorized. This one is actually pretty obvious, but it needed to be said. And speaking of security...
'Chicken1' is not a good password. Changing it to 'Chicken2' does not make it any better. A good article by Chad Perrin talks about how the idea that a good password should be convenient and memorable needs to be done away with as soon as possible. He then goes on to say that one way to be secure and still say sane (try to remember '2%4!G.>_!*5_02' every time you want to transfer money to checking) is to use a good password manager that keeps track of all the various passwords you use. This is good advice. By using a password manager you only have to remember one, and the rest are securely stored and encrypted for you.
Sunday, April 8, 2012
Exercises 7.1-7.3 and Team Meeting
Before I go into the exercises, there was apparently a bug (intentional?) in the 2.0 source code for Homebase. After getting the unit tests up and running, I kept getting this error from the testMonth class whenever it tried to test the RMHdate class. I little digging revealed that where testMonth imported RMHdate as a requirement, the 'd' in date was capitalized. I fixed the bug and then all the tests passed. Anyway, now on to the exercises!
7.1
This exercise is about going through the database tables and making sure they all satisfy normalization criteria. More specifically criterion 5 and 6 from the book. Here is an explanation of each criterion and an example that violates it from the project code:
This exercise is about developing further the dbShifts module by adding the following functions: get_shift_month, get_shift_day, get_shift_year, get_shift_start, and get_shift_end. This exercise proved to be a really neat little mini-project to implement. Basically what you are doing here is taking in the $id as a parameter, then slicing and dicing the $id to get the month, day, etc. Php's built in 'explode' function (thanks for the hint Mario!) was a HUGE help in making this happen. When you invoke the function, all you have to do is pass in a delimiter (a dash in this case) and it breaks up the string into the components that you need. I also added some tests to the testdbShifts class to check everything still worked. The other tests that were already present in the module served as a good starting point, and all that was required was to pass in a created id and assert that it was true that a particular string was (month, day, etc.) was extracted.
7.3
Here the book is asking for the creation of a completely new module for the project. The module that is to be made is called dbMonths (kinda like the dbWeeks class) and will be used to pull an entire month's worth of information from the database and then sent to the GUI for display. A good starter for this is found in chapter 6, where the authors have already included the needed fields and constructor. But, as stated earlier, the requirements for dbMonths are very similar to what is already available in the dbWeeks class, so I pretty much copy and pasted the dbWeeks module and then made the required changes. I also created a new unit test for the module to test the constructor and functions. After creating the new test and running it i kept getting some serious errors that baffled me for a while. I finally figured it out. What I forgot to do (even though the book explicitly says to do so) was add dbMonths to the dbInstall script, so that the new module can be created and added to the database.
Team Meeting
Today's meeting was really productive and we were able to pretty much complete our poster for the upcoming poster session. Being Easter only me, James, and Matthew were able to attend the actual meeting, but a lot was accomplished despite of this. The poster consists of sections containing an overview of the project, the lessons that we learned during the course of the semester, and how we specifically contributed to the project. These sections are supplemented by screen shots of patches and wiki pages that we submitted, as well as a timeline of the xbmc release cycle that we found ourselves in the middle of when starting the project.
7.1
This exercise is about going through the database tables and making sure they all satisfy normalization criteria. More specifically criterion 5 and 6 from the book. Here is an explanation of each criterion and an example that violates it from the project code:
- Criterion 5 - Every entry in the table has exactly one value of the appropriate type. dbSchedules easily violates this one by allowing multiple values into the table under the persons (notice the plural?) column. When populated in sandbox mode, several entries have two people available for one slot.
- Criterion 6 - No attribute in the table is redundant with the primary key. The dbPersons class violates this by using a person's first name and phone number as the primary key. This is a redundancy as both these attributes exist elsewhere in the table. A better primary key be the person's ssn# or a specifically assigned unique volunteer id.
This exercise is about developing further the dbShifts module by adding the following functions: get_shift_month, get_shift_day, get_shift_year, get_shift_start, and get_shift_end. This exercise proved to be a really neat little mini-project to implement. Basically what you are doing here is taking in the $id as a parameter, then slicing and dicing the $id to get the month, day, etc. Php's built in 'explode' function (thanks for the hint Mario!) was a HUGE help in making this happen. When you invoke the function, all you have to do is pass in a delimiter (a dash in this case) and it breaks up the string into the components that you need. I also added some tests to the testdbShifts class to check everything still worked. The other tests that were already present in the module served as a good starting point, and all that was required was to pass in a created id and assert that it was true that a particular string was (month, day, etc.) was extracted.
7.3
Here the book is asking for the creation of a completely new module for the project. The module that is to be made is called dbMonths (kinda like the dbWeeks class) and will be used to pull an entire month's worth of information from the database and then sent to the GUI for display. A good starter for this is found in chapter 6, where the authors have already included the needed fields and constructor. But, as stated earlier, the requirements for dbMonths are very similar to what is already available in the dbWeeks class, so I pretty much copy and pasted the dbWeeks module and then made the required changes. I also created a new unit test for the module to test the constructor and functions. After creating the new test and running it i kept getting some serious errors that baffled me for a while. I finally figured it out. What I forgot to do (even though the book explicitly says to do so) was add dbMonths to the dbInstall script, so that the new module can be created and added to the database.
Team Meeting
Today's meeting was really productive and we were able to pretty much complete our poster for the upcoming poster session. Being Easter only me, James, and Matthew were able to attend the actual meeting, but a lot was accomplished despite of this. The poster consists of sections containing an overview of the project, the lessons that we learned during the course of the semester, and how we specifically contributed to the project. These sections are supplemented by screen shots of patches and wiki pages that we submitted, as well as a timeline of the xbmc release cycle that we found ourselves in the middle of when starting the project.
Thursday, April 5, 2012
Chapter 7 Exercises: A Slow Start
First let me say that I was unable to actually get to the exercises, mainly because of the difficulties that I encountered installing the SimpleTest plugin for Eclipse. On that count I was ultimately successful. Here follows the painful account of the experience.
The version of RMH Homebase that was used on previous exercises was the 1.5 version, and the version needed for the new database exercises is the 2.0 version. What this meant was that I needed to start from scratch as far as getting a new development sandbox ready. Going back to Scott's awesome instructions for doing this made the process a lot less of a headache. The switch over from 1.5 to 2.0 involved the following steps:
The version of RMH Homebase that was used on previous exercises was the 1.5 version, and the version needed for the new database exercises is the 2.0 version. What this meant was that I needed to start from scratch as far as getting a new development sandbox ready. Going back to Scott's awesome instructions for doing this made the process a lot less of a headache. The switch over from 1.5 to 2.0 involved the following steps:
- Downloading the new 2.0 code and placing the rmh20 folder into my /var/www folder
- Creating a new MySQL database in phpMyAdmin named rmh20DB
- Setting up myself with security privileges in the new database
- Entering these privileges into the dbinfo.php file in my webroot folder
- Adding the project to Eclipse
- Running (as a web page) dbinstall.php then dbinstallsandbox.php in Eclipse to set up the sandbox
- Download the tarball here for the Eclipse plugin
- Extract in whatever folder you downloaded into
- Open up Eclipse and go into Help > Install new software. Enter the following url into the "work with" box > http://simpletest.org/eclipse/ and then click add.
- After installing the plugin, its time to configure. Restart Eclipse
- Go into Window > Preferences > Simpletest
- Enter the executable location for php (mine is /usr/bin/php5), the php.ini location (mine is /etc/php5/cli/php.ini/), and the path to where the extracted Simpletest folder is. Then put down the file extension as .php
- Now go into Run > Run Configuration. Highlight Simpletest and then click on 'New' (tiny box at top left).
- Enter into the form that pops up a name for your new configuration, the project (rmh20), and then the test file (alltests.php). Save it and you are ready to test.
Wednesday, April 4, 2012
Chapter 7: Modifing RMH Homebase Database
The reading for this chapter is a great precursor to the homework that is due on Friday. Both the chapter and the exercises deal with cleaning up and modifying the database for RMH Homebase. And, for me anyway, a lot of the stuff in this chapter is review. Last semester I took an extremely useful course called Database Concepts (which I recommend every CS student take) that covered all of the things mentioned here. For the sake of review, which is always a good thing, I'll go over a few key concepts.
The particular DBMS talked about in the chapter is MySQL, which is a relational database. The authors start out with a little terminology, then dig right into how the database fits into the software stack for the project as the persistence layer. The software stack that I'm using for the homework is a LAMP stack because I'm running a Linux box. Then they go through connecting a project to a database, keys, info about tables, and some naming conventions for tables. Then comes the cool stuff.
Two of the things that makes database design interesting are the aspects of security and integrity. Straight from the book, here are what a secure database accomplishes:
Finally, the last part of the chapter offers some insight on how to ensure that any changes made to the database do not have a detrimental effect, and all functionality remains the same. As in previous chapters, this involves modification of the unit tests to include those changes and then refactoring. If a part of the database has been changed or streamlined, then perhaps something in the class that uses that part of the database can also be streamlined or removed. Coming up...chapter 7 exercises.
The particular DBMS talked about in the chapter is MySQL, which is a relational database. The authors start out with a little terminology, then dig right into how the database fits into the software stack for the project as the persistence layer. The software stack that I'm using for the homework is a LAMP stack because I'm running a Linux box. Then they go through connecting a project to a database, keys, info about tables, and some naming conventions for tables. Then comes the cool stuff.
Two of the things that makes database design interesting are the aspects of security and integrity. Straight from the book, here are what a secure database accomplishes:
- It prevents unauthorized or accidental disclosure, alteration, or destruction of data.
- It prevents unauthorized or accidental access to data considered confidential to the organization or individual who owns the data.
- It ensures data integrity, so that the data stored in the database are always valid and accurate.
Finally, the last part of the chapter offers some insight on how to ensure that any changes made to the database do not have a detrimental effect, and all functionality remains the same. As in previous chapters, this involves modification of the unit tests to include those changes and then refactoring. If a part of the database has been changed or streamlined, then perhaps something in the class that uses that part of the database can also be streamlined or removed. Coming up...chapter 7 exercises.
Sunday Team Meeting: Prepping for Poster Session
Our team decided that the best use of our time for this week's meeting would be beginning to get ready for the poster session that is coming up this month. We are all individually on track for our respective parts of the documentation for the project, so this was not an issue that was discussed.
For the poster session, we have to submit an abstract of 150 words or less by April 13th. This abstract gives a general overview of our project and how we, as a team, contributed and worked on it. We finished the abstract without too many problems...but then difficulty in respect to the physical poster manifested itself.
Our first idea was to create a google doc that we all had access to, so we could edit simultaneously as ideas popped into our brains. This turned out to be an unfortunate idea. What ended up happening was that we created an incoherent mess that didn't flow or make any sense, and looked like what five different people thought it should look like. What we were experiencing was actually pretty interesting when you think about it. It is called combinatorial explosion.
Combinatorial explosion refers to the increasing lines of communication as you add individual nodes to a network. If you have four people, then you will have six channels:
Adding another person, which is the size of our group, increases the communication channels to 10. So the channels, represented by c, look something like this: c = (n(n-1))/2 for n people. This is what was happening when we just jumped into all creating the poster at the same time with no central person in charge.
Me and James both had previous experience from creating our poster from last semester. James did more of the work on last semester's poster, so he was made the de-facto designer of the poster portion of this project. So now all ideas will go through him while he is creating the template for the poster, and this will reduce the lines of communication from 10 to 4. Now that this is worked out, hopefully this will be a smoother process!
For the poster session, we have to submit an abstract of 150 words or less by April 13th. This abstract gives a general overview of our project and how we, as a team, contributed and worked on it. We finished the abstract without too many problems...but then difficulty in respect to the physical poster manifested itself.
Our first idea was to create a google doc that we all had access to, so we could edit simultaneously as ideas popped into our brains. This turned out to be an unfortunate idea. What ended up happening was that we created an incoherent mess that didn't flow or make any sense, and looked like what five different people thought it should look like. What we were experiencing was actually pretty interesting when you think about it. It is called combinatorial explosion.
Combinatorial explosion refers to the increasing lines of communication as you add individual nodes to a network. If you have four people, then you will have six channels:
Adding another person, which is the size of our group, increases the communication channels to 10. So the channels, represented by c, look something like this: c = (n(n-1))/2 for n people. This is what was happening when we just jumped into all creating the poster at the same time with no central person in charge.
Me and James both had previous experience from creating our poster from last semester. James did more of the work on last semester's poster, so he was made the de-facto designer of the poster portion of this project. So now all ideas will go through him while he is creating the template for the poster, and this will reduce the lines of communication from 10 to 4. Now that this is worked out, hopefully this will be a smoother process!
Friday, March 30, 2012
POSSCON Was Incredible
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.
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.
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.
Monday, February 20, 2012
RMH Homebase Exercises
As a way of getting used to refactoring code and rooting out "bad smells" in code, we were assigned to download and explore RMH Homebase. Homebase is an open source volunteer scheduling system. The code is written in php, so I decided to approach the assignment by looking at a single php file for bad smells.
I picked one of the larger files called editMasterSchedule.php and immediately found some problems with the code. To begin with, only one of the twelve functions within the file had any sort of commenting. Because of this, it was really hard to figure out what was going on and took some time to be able to make my own comments. As an example using one of the shorter methods, the function do_slot_num($shift) takes in a shift as a parameter and then returns how many slots are available for that particular shift. And that literally is what I put down for the comment.
While I was commenting the code, I also noticed that one of the functions, do_fill_vacancy_form($shift, $fam), was left as a stub and did not do anything at all. So I removed that from the file.
Ironically, the only function that was actually commented was a long method, or a method that performs more that one task. And it was the comments that gave it away. The comments disclose that the function checks to see if a person is working a given shift, and also checks to see if a person is available to work any shift. This should be two separate functions and I rewrote the code to reflect this.
The last function in the file is a really long if statement:
function get_day_names($shift,$day) {
if($day=="Mon") {
$shift[]= "Monday";
$shift[]="Mon";
}
if($day=="Tue") {
$shift[]= "Tuesday";
$shift[]="Tue";
}
if($day=="Wed") {
$shift[]= 'Wednesday';
$shift[]="Wed";
}
if($day=="Thu") {
$shift[]= "Thursday";
$shift[]="Thu";
}
if($day=="Fri") {
$shift[]= "Friday";
$shift[]="Fri";
}
if(substr($day,0,3)=="Sat") {
$shift[]= "Saturday";
$shift[]="Sat";
}
else {
$shift[]="Sunday";
$shift[]="Sun";
}
return $shift;
}
I decided to change this out to a switch statement:
function get_day_names($shift,$day) {
switch ($day) {
case "Mon":
$shift[]= "Monday";
$shift[]="Mon"; break;
case "Tue":
$shift[]= "Tuesday";
$shift[]="Tue"; break;
case "Wed":
$shift[]= 'Wednesday';
$shift[]="Wed"; break;
case "Thu":
$shift[]= "Thursday";
$shift[]="Thu"; break;
case "Fri":
$shift[]= "Friday";
$shift[]="Fri"; break;
case "Sat":
$shift[]= "Saturday";
$shift[]="Sat"; break;
default:
$shift[]="Sunday";
$shift[]="Sun";
}
return $shift;
}
For me, this just looks more straightforward and readable. Although my professor, Dr. Bowring, pointed out that this is a problem that should ultimately be solved with polymorphism.
I picked one of the larger files called editMasterSchedule.php and immediately found some problems with the code. To begin with, only one of the twelve functions within the file had any sort of commenting. Because of this, it was really hard to figure out what was going on and took some time to be able to make my own comments. As an example using one of the shorter methods, the function do_slot_num($shift) takes in a shift as a parameter and then returns how many slots are available for that particular shift. And that literally is what I put down for the comment.
While I was commenting the code, I also noticed that one of the functions, do_fill_vacancy_form($shift, $fam), was left as a stub and did not do anything at all. So I removed that from the file.
Ironically, the only function that was actually commented was a long method, or a method that performs more that one task. And it was the comments that gave it away. The comments disclose that the function checks to see if a person is working a given shift, and also checks to see if a person is available to work any shift. This should be two separate functions and I rewrote the code to reflect this.
The last function in the file is a really long if statement:
function get_day_names($shift,$day) {
if($day=="Mon") {
$shift[]= "Monday";
$shift[]="Mon";
}
if($day=="Tue") {
$shift[]= "Tuesday";
$shift[]="Tue";
}
if($day=="Wed") {
$shift[]= 'Wednesday';
$shift[]="Wed";
}
if($day=="Thu") {
$shift[]= "Thursday";
$shift[]="Thu";
}
if($day=="Fri") {
$shift[]= "Friday";
$shift[]="Fri";
}
if(substr($day,0,3)=="Sat") {
$shift[]= "Saturday";
$shift[]="Sat";
}
else {
$shift[]="Sunday";
$shift[]="Sun";
}
return $shift;
}
I decided to change this out to a switch statement:
function get_day_names($shift,$day) {
switch ($day) {
case "Mon":
$shift[]= "Monday";
$shift[]="Mon"; break;
case "Tue":
$shift[]= "Tuesday";
$shift[]="Tue"; break;
case "Wed":
$shift[]= 'Wednesday';
$shift[]="Wed"; break;
case "Thu":
$shift[]= "Thursday";
$shift[]="Thu"; break;
case "Fri":
$shift[]= "Friday";
$shift[]="Fri"; break;
case "Sat":
$shift[]= "Saturday";
$shift[]="Sat"; break;
default:
$shift[]="Sunday";
$shift[]="Sun";
}
return $shift;
}
For me, this just looks more straightforward and readable. Although my professor, Dr. Bowring, pointed out that this is a problem that should ultimately be solved with polymorphism.
Monday, February 13, 2012
Playing With Patches
For this assignment, we were to read chapter 7 and do some of the problems contained within it. The title of the chapter is "Fixing_The_Code" and talks about how to document and submit bug fixes. The first thing that struck me after reading this chapter was how well implemented a process this is. And also that it was completely different from how I imagined it.
When I thought about fixing bugs and then submitting them for approval from the project developers, I figured that you just uploaded the patch into the repository. Then the code update would happen after the patch was reviewed by the People In Charge. Well, it seems that there is a bit more to the process than that. There is a really neat way that the fix is documented that makes whatever changes made easy to read, and keeps things standardized across the board. This is called creating a diff, or patch.
The patch is a text file that is created by comparing two (or more) other files using the unix diff command, then piping the results of that comparison into the text file. The example in the book starts with a simple C
program:
#include <stdio.h>
int main() {
printf("hello, world.\n");
return 0;
{
Now, say you want to change the code to express your insane enthusiasm for C and programming in general. In order to do so, you must create a patch file. The first thing to do is make a copy of the "hello.c" file in the same directory. Then make the changes to the original file, namely some exclamation points:
#include <stdio.h>
int main() {
printf("hello, world!!!\n");
return 0;
{
Now to create the patch. A simple command takes care of the rest:
$ diff hello.c.new hello.c > crazyHello.patch
This compared the two files, documented the changes, and reported them into the file "crazyHello.patch". This file has a lot of information in it, but the most important is what was actually changed. It looks like this:
- printf("hello, world.\n");
+ printf("hello, world!!!\n");
By doing things this way, open source developers know exactly what to look for when a patch is uploaded to them. This makes things go a lot faster for approving changes, fixing bugs for users, and improving the project. Pretty smart.
When I thought about fixing bugs and then submitting them for approval from the project developers, I figured that you just uploaded the patch into the repository. Then the code update would happen after the patch was reviewed by the People In Charge. Well, it seems that there is a bit more to the process than that. There is a really neat way that the fix is documented that makes whatever changes made easy to read, and keeps things standardized across the board. This is called creating a diff, or patch.
The patch is a text file that is created by comparing two (or more) other files using the unix diff command, then piping the results of that comparison into the text file. The example in the book starts with a simple C
program:
#include <stdio.h>
int main() {
printf("hello, world.\n");
return 0;
{
Now, say you want to change the code to express your insane enthusiasm for C and programming in general. In order to do so, you must create a patch file. The first thing to do is make a copy of the "hello.c" file in the same directory. Then make the changes to the original file, namely some exclamation points:
#include <stdio.h>
int main() {
printf("hello, world!!!\n");
return 0;
{
Now to create the patch. A simple command takes care of the rest:
$ diff hello.c.new hello.c > crazyHello.patch
This compared the two files, documented the changes, and reported them into the file "crazyHello.patch". This file has a lot of information in it, but the most important is what was actually changed. It looks like this:
- printf("hello, world.\n");
+ printf("hello, world!!!\n");
By doing things this way, open source developers know exactly what to look for when a patch is uploaded to them. This makes things go a lot faster for approving changes, fixing bugs for users, and improving the project. Pretty smart.
Wednesday, February 8, 2012
Response on "The Cathedral and the Bazaar"
I have finally finished reading The Cathedral and the Bazaar by Eric Raymond, and I am now prepared to complete my assignment from last week and blog a response to it. My first impression upon reading it was that this should be, and is in my case, required reading for any CS student interested in learning more about open source software development.
He lays out a number of little nuggets of wisdom throughout the essay and the first one was right on the money. It says, "Every good work of software starts by scratching a developer's personal itch." This is an absolutely true statement. At the place where I work one of the jobs that I do is help to recover an encrypted hard drive after a system crash. The method for doing this required multiple steps, such as copying and pasting things into the command line, and was a real pain. After I complained about this to one of my co-workers, his basic response was, "hey, you're a programmer. Fix it." Challenge accepted!
So to make a boring story short, I scratched my personal itch by writing up a batch file to automate the process of getting the recovery key. It was a very satisfying experience to create something that actually filled a need and would be used by other people. And this is what I expect drives many developers to go out there and create cool things, it satisfies a personal need to do so.
Another idea that Raymond features in his paper is the notion of treating users as co-developers, which allows a better flow of code development and a more efficient way of debugging. This method is apparent in the project we are working on right now, because just by messing around with xbmc's bug tracker for a few minutes the time and effort put into it's design become apparent. It is an obvious effort to make the bug reporting system as easy as possible for users to navigate. And I totally agree with this approach. Giving users a sense of ownership over a project ensures a more open and dependable development cycle.
He then goes on to describe his personal experience taking ownership of his own project, fetchmail, and how he applied good open source design principles in improving and implementing changes to the project. Altogether this was a very informative and descriptive paper, and still has as much merit today as when it was written back in 2000.
He lays out a number of little nuggets of wisdom throughout the essay and the first one was right on the money. It says, "Every good work of software starts by scratching a developer's personal itch." This is an absolutely true statement. At the place where I work one of the jobs that I do is help to recover an encrypted hard drive after a system crash. The method for doing this required multiple steps, such as copying and pasting things into the command line, and was a real pain. After I complained about this to one of my co-workers, his basic response was, "hey, you're a programmer. Fix it." Challenge accepted!
So to make a boring story short, I scratched my personal itch by writing up a batch file to automate the process of getting the recovery key. It was a very satisfying experience to create something that actually filled a need and would be used by other people. And this is what I expect drives many developers to go out there and create cool things, it satisfies a personal need to do so.
Another idea that Raymond features in his paper is the notion of treating users as co-developers, which allows a better flow of code development and a more efficient way of debugging. This method is apparent in the project we are working on right now, because just by messing around with xbmc's bug tracker for a few minutes the time and effort put into it's design become apparent. It is an obvious effort to make the bug reporting system as easy as possible for users to navigate. And I totally agree with this approach. Giving users a sense of ownership over a project ensures a more open and dependable development cycle.
He then goes on to describe his personal experience taking ownership of his own project, fetchmail, and how he applied good open source design principles in improving and implementing changes to the project. Altogether this was a very informative and descriptive paper, and still has as much merit today as when it was written back in 2000.
Tuesday, February 7, 2012
Becoming Familiar With xbmc Bugs
This assignment proved to be a really interesting one. We were once again tasked with doing some exercises from our online open source textbook, this time ones dealing with the xbmc bug tracker. The assignment was broken up into four parts, so that is how I'll divide up this post:
1) Finding the oldest bug.
In the process of doing this exercise, I actually found some new functionality in the bug tracker which allows further refinement of which bugs to display. I figured that because we are working exclusively in Linux for this project, I would start in the newly discovered section just for Linux bugs. After doing this I was returned with 369 open tickets! After sorting by date created, I found that the oldest bug was from November of 2003 and was dealing with a module called Requant. It appears there is a problem with the C++ source code dealing with the re-sizing of video files, but the priority level on this is set to unimportant and the ticket has not been touched in over a year. I think that this bug has not been resolved because the module was not needed in the first place, and that whatever functionality it was supposed to provide (the ability to re-size without decoding and then encoding again) was picked up by something else.
2) Create a bug tracker account.
Ha! I was one step ahead of you, authors of Teaching Open Source, on this exercise. Although, to be honest, this was not by design. By creating an account to have the ability to post on the forum, a contributor also has access to the bug tracker.
3) Attempt to reproduce a bug.
4) Bug Triage.
Unfortunately, I began to experience problems connecting to their server at this point and was unable to stay logged into the bug tracker. I plan on completing parts three and four tomorrow, and then posting my experience later that day.
1) Finding the oldest bug.
In the process of doing this exercise, I actually found some new functionality in the bug tracker which allows further refinement of which bugs to display. I figured that because we are working exclusively in Linux for this project, I would start in the newly discovered section just for Linux bugs. After doing this I was returned with 369 open tickets! After sorting by date created, I found that the oldest bug was from November of 2003 and was dealing with a module called Requant. It appears there is a problem with the C++ source code dealing with the re-sizing of video files, but the priority level on this is set to unimportant and the ticket has not been touched in over a year. I think that this bug has not been resolved because the module was not needed in the first place, and that whatever functionality it was supposed to provide (the ability to re-size without decoding and then encoding again) was picked up by something else.
2) Create a bug tracker account.
Ha! I was one step ahead of you, authors of Teaching Open Source, on this exercise. Although, to be honest, this was not by design. By creating an account to have the ability to post on the forum, a contributor also has access to the bug tracker.
3) Attempt to reproduce a bug.
4) Bug Triage.
Unfortunately, I began to experience problems connecting to their server at this point and was unable to stay logged into the bug tracker. I plan on completing parts three and four tomorrow, and then posting my experience later that day.
Monday, February 6, 2012
Exploring xbmc For Bugs
Our team ended up having a meeting on Sunday to discuss which bug we would like to work on. We explored many options and already had some ideas coming into the meeting. One of the ideas that I brought to the table was that there were some documentation errors in the readme file. The repository that the file was pointing to was the old sourceforge one, and the current working repository is located here. Also there was a couple of errors in the instructions for compiling the code.
After much discussion, we decided to run with this and use it as an experience to get our collective feet wet. Just to double-check, I went into the most current readme for the Eden version of the software before we committed to doing this. They had already fixed it! So we dug back into the bug tracker and looked to see what kind of reported bugs were out there.
To help with this, xbmc has a convenient ticket system called their Trac system. Using this system, a potential developer for the project such as me can scroll through all open tickets listed. These tickets can also be filtered by a number of ways including date created, component affected, and date modified. The first thing that we discovered was that there are a LOT of bugs to pick from. The second was that we were going to have to be careful in choosing which bug to work on, because of the difficulty involved with some of them.
One example of one of the more cryptic ones listed says " "startup window" option does not honor skin "videos button always goes to video files" option ". I can imagine that, having not written the code myself, this would be a hard one to track down. So these were the things that we were dealing with when trying to sift thought the various tickets. So in the end, we actually did not come up with a bug to start working on during the meeting. This was due to the readme bug already being fixed and the overwhelming amount of bugs listed on the bug tracker. Hopefully we will be able to narrow it down during the week and come up with something by Friday.
After much discussion, we decided to run with this and use it as an experience to get our collective feet wet. Just to double-check, I went into the most current readme for the Eden version of the software before we committed to doing this. They had already fixed it! So we dug back into the bug tracker and looked to see what kind of reported bugs were out there.
To help with this, xbmc has a convenient ticket system called their Trac system. Using this system, a potential developer for the project such as me can scroll through all open tickets listed. These tickets can also be filtered by a number of ways including date created, component affected, and date modified. The first thing that we discovered was that there are a LOT of bugs to pick from. The second was that we were going to have to be careful in choosing which bug to work on, because of the difficulty involved with some of them.
One example of one of the more cryptic ones listed says " "startup window" option does not honor skin "videos button always goes to video files" option ". I can imagine that, having not written the code myself, this would be a hard one to track down. So these were the things that we were dealing with when trying to sift thought the various tickets. So in the end, we actually did not come up with a bug to start working on during the meeting. This was due to the readme bug already being fixed and the overwhelming amount of bugs listed on the bug tracker. Hopefully we will be able to narrow it down during the week and come up with something by Friday.
Thursday, February 2, 2012
Article Interpretation and xbmc Part 2
The article that I chose to write about comes from the January 2010 issue of Computer magazine.
In their article titled "Online Security Threats and Computer User Intentions", Thomas F. Stafford and Robin Poston theorize on the phenomenon of user apathy regarding online security. In this article they do not address why people should use antispyware software, but why they choose not to use such software.
One of the first statistics cited in the article is that, out of a survey of 252 consumers, only 22 percent of them consistently used security software of some kind. Another study done by AOL saw that 55 percent of the people polled either did not use or did not know whether or not they used antispyware software. As a CS student I find these results troubling and somewhat confusing.
I find them troubling because when users do not use security precautions on their personal machines, for whatever reason, they can unknowingly contribute to the proliferation of malware and spyware. I find it confusing because the first thing I think about, at least on a Windows machine, is whether my virus definitions are up to date. But it seems there is a possible reason for the shocking numbers that were cited.
Stafford and Posten have put forth a theory they call Protection Motivation Theory. Simply put, the theory says that when presented with a perceived threat, such as the possibility of a keystroke logger on your computer, an individual must be sufficiently motivated to deal with that threat. According to Stafford and Posten, the biggest obstacle that prevents users from using available software solutions is what they call Protection self-efficacy, or a user's lack of confidence for using and installing said software.
This is really interesting stuff, and while they do not go too far into possible solutions to this problem, it seems that the onus is on developers and the tech community. Through rigorous education of the lay-user and continual re-development of easier to use security software, we might be able to see these statistics begin to change direction.
And on a quick side-note, I finally was able to get xbmc up and running. Through the helpful posts of my team members James and David, I realized that I needed to add the xbmc PPA to my system in order to get all the necessary dependencies. After installing the PPA, I ran the following command: sudo apt-get build-dep xbmc. This built all the dependencies that I was missing and I was then able to finish configuring and making the project.
In their article titled "Online Security Threats and Computer User Intentions", Thomas F. Stafford and Robin Poston theorize on the phenomenon of user apathy regarding online security. In this article they do not address why people should use antispyware software, but why they choose not to use such software.
One of the first statistics cited in the article is that, out of a survey of 252 consumers, only 22 percent of them consistently used security software of some kind. Another study done by AOL saw that 55 percent of the people polled either did not use or did not know whether or not they used antispyware software. As a CS student I find these results troubling and somewhat confusing.
I find them troubling because when users do not use security precautions on their personal machines, for whatever reason, they can unknowingly contribute to the proliferation of malware and spyware. I find it confusing because the first thing I think about, at least on a Windows machine, is whether my virus definitions are up to date. But it seems there is a possible reason for the shocking numbers that were cited.
Stafford and Posten have put forth a theory they call Protection Motivation Theory. Simply put, the theory says that when presented with a perceived threat, such as the possibility of a keystroke logger on your computer, an individual must be sufficiently motivated to deal with that threat. According to Stafford and Posten, the biggest obstacle that prevents users from using available software solutions is what they call Protection self-efficacy, or a user's lack of confidence for using and installing said software.
This is really interesting stuff, and while they do not go too far into possible solutions to this problem, it seems that the onus is on developers and the tech community. Through rigorous education of the lay-user and continual re-development of easier to use security software, we might be able to see these statistics begin to change direction.
And on a quick side-note, I finally was able to get xbmc up and running. Through the helpful posts of my team members James and David, I realized that I needed to add the xbmc PPA to my system in order to get all the necessary dependencies. After installing the PPA, I ran the following command: sudo apt-get build-dep xbmc. This built all the dependencies that I was missing and I was then able to finish configuring and making the project.
Monday, January 30, 2012
Round 1: compiling xbmc
Although downloading and compiling Freeciv was an invaluable learning experience, there were many problems that were encountered doing the same with xbmc.
The first thing that I that I did wrong was download the source code from the wrong site, which was the old sourceforge repository. I had downloaded all the files and was getting ready to compile and make the project, when I went to the xbmc wiki and saw that all the most recent releases were now being stored at github.
So I deleted that folder (rm -rf "folderName" deletes the folder and its contents) and started from the beginning using the new repository with the subversion command "svn co https://github.com/xbmc/
And here is where my next problem made itself apparent. I had walked away from my laptop while downloading, and when I came back the terminal curser was blinking. Thinking everything had downloaded fine I went ahead and tried to compile, but after many minutes of compiling received error messages saying I was missing about half of the code. Looking back through my terminal logs I saw that I had indeed lost the secure connection halfway through the download.
Not to be a person easily daunted, I pressed on and tried again. This time, after almost all of the code had been downloaded, I ran out of disk space on my virtual machine. A rookie mistake! When creating it many months ago, I had only allotted it 10 gigs of space on my hard drive. So now I am in the process of imaging a new virtual machine and starting over. Round 1 goes to xbmc.
The first thing that I that I did wrong was download the source code from the wrong site, which was the old sourceforge repository. I had downloaded all the files and was getting ready to compile and make the project, when I went to the xbmc wiki and saw that all the most recent releases were now being stored at github.
So I deleted that folder (rm -rf "folderName" deletes the folder and its contents) and started from the beginning using the new repository with the subversion command "svn co https://github.com/xbmc/
And here is where my next problem made itself apparent. I had walked away from my laptop while downloading, and when I came back the terminal curser was blinking. Thinking everything had downloaded fine I went ahead and tried to compile, but after many minutes of compiling received error messages saying I was missing about half of the code. Looking back through my terminal logs I saw that I had indeed lost the secure connection halfway through the download.
Not to be a person easily daunted, I pressed on and tried again. This time, after almost all of the code had been downloaded, I ran out of disk space on my virtual machine. A rookie mistake! When creating it many months ago, I had only allotted it 10 gigs of space on my hard drive. So now I am in the process of imaging a new virtual machine and starting over. Round 1 goes to xbmc.
Saturday, January 28, 2012
Warming up with Freeciv
In order to get our feet wet, we were instructed, as a class, to build up the Freeciv project from its source code. Freeciv is an open source strategy game. It turns out that this was a really good learning experience because problems immediately ensued...
I downloaded the source code from the project repository with no problem, but the build process presented some interesting obstacles. As part of the build, I had to take care of a lot of dependencies by installing some required packages. This took a some time and while the "Teaching Open Source" textbook was extremely helpful, its instructions are for the Fedora distribution of Linux so a little translation via Google was needed here. The book also used RPM program to check and see if packages were already installed, but I found the "whereis" command to be a lot quicker to use. The INSTALL file within the Freeciv documentation was also helpful, if somewhat frustrating at times. Some of the packages that it said I needed were misspelled and required a little additional research to find and install. Installing the GLib utility library was particularly frustrating because the command ended up being "sudo apt-get install libgtk2.0-dev" instead of glib or Glib. This ended up be useful because this command installed gtk+ at the same time, with GLib being a dependency.
After MANY tries at configuring (the script kept finding undocumented dependencies) I finally was able to make the project. Time for a game of Freeciv!
I downloaded the source code from the project repository with no problem, but the build process presented some interesting obstacles. As part of the build, I had to take care of a lot of dependencies by installing some required packages. This took a some time and while the "Teaching Open Source" textbook was extremely helpful, its instructions are for the Fedora distribution of Linux so a little translation via Google was needed here. The book also used RPM program to check and see if packages were already installed, but I found the "whereis" command to be a lot quicker to use. The INSTALL file within the Freeciv documentation was also helpful, if somewhat frustrating at times. Some of the packages that it said I needed were misspelled and required a little additional research to find and install. Installing the GLib utility library was particularly frustrating because the command ended up being "sudo apt-get install libgtk2.0-dev" instead of glib or Glib. This ended up be useful because this command installed gtk+ at the same time, with GLib being a dependency.
After MANY tries at configuring (the script kept finding undocumented dependencies) I finally was able to make the project. Time for a game of Freeciv!
Tuesday, January 24, 2012
Installing Ubuntu and Subversion
Ahh, Ubuntu. The operating system of champions! Or the red-headed stepchild of operating systems, depending on who you talk to. There is a network guy where I intern who foams at the mouth whenever I praise the virtues of switching over to Ubuntu. In any case, I love it and have been using it for years...probably since Cloverfield came out if I had to put a date on it. So when the assignment came down from headquarters to install both Ubuntu and Subversion on my machine, I already had Ubuntu set up and ready to go. And as for installing Subversion, it was already installed for a project from last semester.
Because these tasks were already accomplished, I decided to blog about the dilemma that I faced when I purchased a new laptop last Spring. My new laptop came with Windows 7 installed on it, which presented me with a decision to make:
1) Change my allegiance
2) Dual-boot
3) Blow away the machine and run Ubuntu
4) Or run either one on a virtual machine
The first option was not even worth considering, so that left only three real choices. The only problem that I have with partitioning my hard drive and dual-booting is that it would limit me to only running one at a time. So nix on that one. And because I'm forced to use Windows at work, it did not make sense to only run Ubuntu. I sometimes do homework there (only during lunch!) at my workstation, and from a file-transfer point of view keeping Windows in some capacity seemed to make sense. Plus I sometimes write batch files at home to automate some of the things I need to do at work. So my eventual decision was to install VirtualBox and run Ubuntu as a virtual machine.
This process was as easy as these things get. I burned a copy of the latest version of Ubuntu to a dvd (11.04 at the time) and then installed using VirtualBox. It was a very intuative, step-by-step experience.
So that left Subversion to deal with. I already had this installed on Ubuntu from last semester, and all that was needed was to create a new repository for our project (imaginatively named classProject2). I then pointed my svn client to the new URL supplied by the department's system admin. Done!
Because these tasks were already accomplished, I decided to blog about the dilemma that I faced when I purchased a new laptop last Spring. My new laptop came with Windows 7 installed on it, which presented me with a decision to make:
1) Change my allegiance
2) Dual-boot
3) Blow away the machine and run Ubuntu
4) Or run either one on a virtual machine
The first option was not even worth considering, so that left only three real choices. The only problem that I have with partitioning my hard drive and dual-booting is that it would limit me to only running one at a time. So nix on that one. And because I'm forced to use Windows at work, it did not make sense to only run Ubuntu. I sometimes do homework there (only during lunch!) at my workstation, and from a file-transfer point of view keeping Windows in some capacity seemed to make sense. Plus I sometimes write batch files at home to automate some of the things I need to do at work. So my eventual decision was to install VirtualBox and run Ubuntu as a virtual machine.
This process was as easy as these things get. I burned a copy of the latest version of Ubuntu to a dvd (11.04 at the time) and then installed using VirtualBox. It was a very intuative, step-by-step experience.
So that left Subversion to deal with. I already had this installed on Ubuntu from last semester, and all that was needed was to create a new repository for our project (imaginatively named classProject2). I then pointed my svn client to the new URL supplied by the department's system admin. Done!
Thursday, January 19, 2012
Getting to know you...
The eventual winner of our contest to pick a team project was xbmc, an open source media platform. After exploring the website and wiki, it looks to be a really neat project and there are lots of opportunities to contribute to it.
So, the assignment this time was to join their IRC channel and the dig around a bit. After reading up a bit on the ins and outs of how to behave in an IRC and some of the commands needed to navigate, I was off to explore. After listing all the available channels, it seems to be a lot of activity that doesn't have much to do with the actual project. This is just at first glance, though, I have not had a chance to really get into it yet. There were some gamers chatting about various obscure games, lots of hyperlinks to non-relevant websites, some spam, and a few channels that looked legit.
One really cool thing that I liked was that this appears to be a global community of people in here. I saw a little German, some French, Spanish, and Russian channels that were available to join. I might join one of the French ones just to brush up.
As per part two of the assignment, I also registered for the xbmc forum. This looks like the real meat and potatoes of the developer side of things. I picked a thread on Python scripts and plugin development, and there were posts with example code as well as developer discussion about current fixes they were working on. It seems as though the IRC was mainly filled with end-users just hanging out, and the forum is where the developers discuss the project and code. In fact, most threads leading to specific forums said either "coders only" or "not for end-user whining".
What I will probably do while working on whatever fix or contribution our group decides on taking on, will start our own channel in the IRC to communicate with each other. And then use the forum to talk with developers and post whatever problems we encounter in the process. This is really starting to look like fun!
So, the assignment this time was to join their IRC channel and the dig around a bit. After reading up a bit on the ins and outs of how to behave in an IRC and some of the commands needed to navigate, I was off to explore. After listing all the available channels, it seems to be a lot of activity that doesn't have much to do with the actual project. This is just at first glance, though, I have not had a chance to really get into it yet. There were some gamers chatting about various obscure games, lots of hyperlinks to non-relevant websites, some spam, and a few channels that looked legit.
One really cool thing that I liked was that this appears to be a global community of people in here. I saw a little German, some French, Spanish, and Russian channels that were available to join. I might join one of the French ones just to brush up.
As per part two of the assignment, I also registered for the xbmc forum. This looks like the real meat and potatoes of the developer side of things. I picked a thread on Python scripts and plugin development, and there were posts with example code as well as developer discussion about current fixes they were working on. It seems as though the IRC was mainly filled with end-users just hanging out, and the forum is where the developers discuss the project and code. In fact, most threads leading to specific forums said either "coders only" or "not for end-user whining".
What I will probably do while working on whatever fix or contribution our group decides on taking on, will start our own channel in the IRC to communicate with each other. And then use the forum to talk with developers and post whatever problems we encounter in the process. This is really starting to look like fun!
Tuesday, January 17, 2012
Team Assignment: Choosing a Project
Me and the team met up on Saturday to discuss the various projects that we wanted to consider for this semester. The assignment was to narrow it down to three by Wednesday, which proved to be easier than I thought it was going to be. This was partially due to our Team dynamic and partially due to the experience that we gained from last semester.
A quick side note on our team dynamic. Everyone did a great job in helping the team to decide on our top three. We came to the meeting with each of us having a project that we wanted to explore, then we took turns trying to sell it to the team. This resulted in an informal vote that gave us our top three choices, ranked from most desired to least. It was a very smooth process.
I'll leave the other members to blog about their own favorites, and just give a brief description of mine. And my choice did make it into the top three. Its an HFOSS project, so it's humanitarian in nature, and is called sahana. The purpose of the software is to provide a way to organize disaster relief efforts around the globe. What caught my eye about this project was its mission, the huge amount of documentation that was available (wiki, etc.), and the large support community. In fact, I'll probably end up being a volunteer developer even if we don't pick this one.
A quick side note on our team dynamic. Everyone did a great job in helping the team to decide on our top three. We came to the meeting with each of us having a project that we wanted to explore, then we took turns trying to sell it to the team. This resulted in an informal vote that gave us our top three choices, ranked from most desired to least. It was a very smooth process.
I'll leave the other members to blog about their own favorites, and just give a brief description of mine. And my choice did make it into the top three. Its an HFOSS project, so it's humanitarian in nature, and is called sahana. The purpose of the software is to provide a way to organize disaster relief efforts around the globe. What caught my eye about this project was its mission, the huge amount of documentation that was available (wiki, etc.), and the large support community. In fact, I'll probably end up being a volunteer developer even if we don't pick this one.
Thursday, January 12, 2012
Learning about FOSS!
I think I'll divide this post up into two sections. The first to address my thoughts about the first chapter in the book, and the second on my experience installing some open source software.
Book
First of all, this book is a pretty good read. After getting though a little history behind FOSS and some basics regarding software development practices, the book starts getting into some things that I either had no prior knowledge of or was misinformed about.
I'm a little ashamed to admit this, but I did actually think that the "free" in FOSS meant that it didn't cost anything. So the thing that I learned today is that it refers to the concept of free speech. This means that when it is licensed, which I'll get back to in a minute, free software is actually legally protected. This was a new idea to me; the fact that free software even required any protecting.
I'll admit this straight off, when I got to the section about licensing I was tempted to either skip ahead or skim. But I soldiered through it and was amazed by some of the information in this section. To quickly sum it up, FOSS needs licenses (GPL is one) to keep the big dogs from stealing the software and placing it under their own proprietary licenses. One thing I wish the authors would have explored further (maybe in a later chapter) is how are these licenses protected. And this leads right what kind of impact FOSS has had on the world so far.
All you need to know about the worldwide impact of FOSS is this figure: $60 billion. That is the amount of lost revenue to software companies because of FOSS per year. It makes me a little nervous to attend the POSSCON conference in March, because I'll be half-expecting a hit squad from some development company to show up.
And that's it, I hope the rest of the book is as informative as this chapter was.
Installing FOSS
This will be short and sweet, as I encountered no problems intalling GIMP, a really cool photo editer, on either of the platforms that I run. On Windows, I simply downloaded the setup executable and ran it. Then walked through the steps using the Windows Installer. Intalling on Ubuntu was even simpler. I just ran three sudo apt-get commands in the terminal, and it was all gravy.
Book
First of all, this book is a pretty good read. After getting though a little history behind FOSS and some basics regarding software development practices, the book starts getting into some things that I either had no prior knowledge of or was misinformed about.
I'm a little ashamed to admit this, but I did actually think that the "free" in FOSS meant that it didn't cost anything. So the thing that I learned today is that it refers to the concept of free speech. This means that when it is licensed, which I'll get back to in a minute, free software is actually legally protected. This was a new idea to me; the fact that free software even required any protecting.
I'll admit this straight off, when I got to the section about licensing I was tempted to either skip ahead or skim. But I soldiered through it and was amazed by some of the information in this section. To quickly sum it up, FOSS needs licenses (GPL is one) to keep the big dogs from stealing the software and placing it under their own proprietary licenses. One thing I wish the authors would have explored further (maybe in a later chapter) is how are these licenses protected. And this leads right what kind of impact FOSS has had on the world so far.
All you need to know about the worldwide impact of FOSS is this figure: $60 billion. That is the amount of lost revenue to software companies because of FOSS per year. It makes me a little nervous to attend the POSSCON conference in March, because I'll be half-expecting a hit squad from some development company to show up.
And that's it, I hope the rest of the book is as informative as this chapter was.
Installing FOSS
This will be short and sweet, as I encountered no problems intalling GIMP, a really cool photo editer, on either of the platforms that I run. On Windows, I simply downloaded the setup executable and ran it. Then walked through the steps using the Windows Installer. Intalling on Ubuntu was even simpler. I just ran three sudo apt-get commands in the terminal, and it was all gravy.
Tuesday, January 10, 2012
First day!
I think the best way to start off my first-ever pro blog is to talk about some of the things I hope to learn and experience this semester. Although I do look forward to digging down into another open-source project and exploring the code within, I would like to make my focus this time around on the "Team Experience". Some of the most rewarding times that I spent last semester was figuring things out with my team and throwing ideas around.
I also like the idea of keeping up a blog for the duration of this class. It will force me to think back on topics discussed in class and structure my thoughts in a coherent way. Last semester before graduating, and I plan on making the most of it!
I also like the idea of keeping up a blog for the duration of this class. It will force me to think back on topics discussed in class and structure my thoughts in a coherent way. Last semester before graduating, and I plan on making the most of it!
Subscribe to:
Posts (Atom)