We were short one team member today as Jason was out of town and unable to get back in time. We each looked for a few more bugs, just in case we couldn't replicate or figure out the bugs we picked last week.
Our team has managed to replicate a bug today (Bug #12653). We found a bug that deals with Blu-Ray issues (Bug #12594), and since I have Blu-Ray built into my laptop we will be able to look at this one as well.
Wednesday, February 29, 2012
Exploring opensource.com
Today's assignment was to go read and discuss two articles from opensource.com. I chose "How to teach undergrads how to become open source contributors without writing any code" which is about a class full of college students learning to become functional open source contributors without having to write code (redundancy here due to the title I know. Sorry about that), and "Culture eats strategy" which is about why understanding a company's culture is so important. Let's get to it, shall we?
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
Sunday, February 19, 2012
2/19/2012
We had our weekly group meeting today at 2 (our group decided to make them a weekly thing today). We have been working on a timeline for the class project and creating milestones. We've decided to work on at least three bugs, one every two weeks, instead of working on one major bug for the rest of the semester. The interval was chosen so we would be able to fix our first bug before spring break. We discussed various bugs that we found on the bug tracker, and selected five bugs to try and fix this semester.
Tuesday, February 14, 2012
2/15/2012
The assignment for this post was to read chapter 4 in Software Development: An Open Source Approach. This chapter covers Software Architecture. The book describes software architecture as being "an organizational model for a moderate or large software system...provides strong guidance on how modules interact with each other, how a test suite can be designed, how refactoring strategies can be exercised, and how program bugs can be detected and removed."
It lists 4 architecture patterns:
It also lists the 3 important software architecture development principles:
It lists 4 architecture patterns:
- Mutlti-Tier: distiguishes the user interface layer from the core class layer from the database later. GUI components are isolated within the user interface layer and database interactions are isloated within the database layer.
- Client-Server: separates the functionality of a typical user of the system from that of the server that hosts the database that all users access. The "client-side" code is that which resides on the user's computer, including GUI components. "Server-side" code resides on the server's computer, including the database components.
- Transaction Processing: useful for systems that accept a stream of transactions and process each transaction fully before moving on to the next.
- Model-View Controller (MVC): useful for systems that have substantially complex user interfaces. The idea here is to separate the functionality that underlies the user interface from the code that controls how the user sees and interacts with the system.
It also lists the 3 important software architecture development principles:
- Layering Principle: Every module belongs in a single layer. No module should skip over its neighbors in the layer immediately above or below it, in order to provide or obtain services from another layer.
- Maximum Cohesion Principle: All the functions that relate to a single concept are gathered into a single module or class. A software architecture is maximally cohesive if all its modules and classes are cohesive in this way.
- Minimum Coupling Principle: Two modules are coupled if either one shares information or receives services directly from the other. A software system is minimally coupled when the number of interactions between all pairs of modules is kept to a minimum.
Sunday, February 12, 2012
Group Meeting--Fixing a Bug
Our group met today at 2 to work on the group assignment due this week--fixing a bug in the project. We had already established what we wanted to work on. David found a bug a couple of weeks ago (bug #12565) that dealt with the incorrect display of images in slideshow mode. He created a test image for the developers, but no one was able to replicate the bug. We decided to fix the README.ubuntu file, which has some incorrect links and is missing some of the dependencies needed to get the source code for XBMC.
Friday, February 10, 2012
2/10/2012 (TOS Chapter 7)
This chapter covers patches, and how to create and submit them. We were asked to do exercises 7.2.2, 7.8, and 7.9.
To do exercise 7.2.2, the authors want you to create the file used in the example to compare the outputs of a diff command using the -u flag and without it. The file is a simple "Hello, World" program, very simple to write (just copy and paste into the text editor). I booted up Ubuntu--I prefer it for my homework in this class because that's the OS we have to use for our projects--and opened up my text editor (gedit) so I could get the program pasted in and saved the file. I then opened up the terminal window and followed the instructions in the example, which I needed to do before completing the actual exercise. With that taken care of, I started playing with the diff command as stated in the exercise. I noticed that without the -u flag, the only output to my terminal window is the original line of the program and the new one that contains the change. When the command has the -u flag, the output shows where AND when the change was made. It even prints out the program text with the original and new lines of code--a "-" for the line that will be replaced and a "+" for the new line of text that will be going into the program. After seeing the outputs for both versions of the diff command, I prefer the one with the -u flag because it contains more information, but I suppose that doing the command without the flag would be more efficient if you have a lot more going on in your terminal window. I prefer it because I like to know exactly where it is being changed. On to the next!
7.8:
This exercise says to create a patch file that represents a new file, foo being with the contents bar. I'm little confused by this one actually. I wasn't sure if we were supposed to create a patch for the hello.c files or if it was for a different program. Maybe I'm just being an idiot, I don't know. Let's hope the last one goes better...
7.9:
This is a step-by-step exercise that wants you to create a patch echo for a project. I actually really like this one because I'm a Windows user, so I don't know a whole lot about the bash commands except for what I used last semester in CSCI 362. Unfortunately, my terminal keeps telling me that the commands I'm trying to use aren't correct, and typing exactly what TOS is telling me to type in the exercise. I don't understand why this is happening. I did read through the exercise and I'm pretty confident that I understand what's going on. It's basically a reinforcement of the two previous exercises along with teaching the new concept of creating a working echo binary.
To do exercise 7.2.2, the authors want you to create the file used in the example to compare the outputs of a diff command using the -u flag and without it. The file is a simple "Hello, World" program, very simple to write (just copy and paste into the text editor). I booted up Ubuntu--I prefer it for my homework in this class because that's the OS we have to use for our projects--and opened up my text editor (gedit) so I could get the program pasted in and saved the file. I then opened up the terminal window and followed the instructions in the example, which I needed to do before completing the actual exercise. With that taken care of, I started playing with the diff command as stated in the exercise. I noticed that without the -u flag, the only output to my terminal window is the original line of the program and the new one that contains the change. When the command has the -u flag, the output shows where AND when the change was made. It even prints out the program text with the original and new lines of code--a "-" for the line that will be replaced and a "+" for the new line of text that will be going into the program. After seeing the outputs for both versions of the diff command, I prefer the one with the -u flag because it contains more information, but I suppose that doing the command without the flag would be more efficient if you have a lot more going on in your terminal window. I prefer it because I like to know exactly where it is being changed. On to the next!
7.8:
This exercise says to create a patch file that represents a new file, foo being with the contents bar. I'm little confused by this one actually. I wasn't sure if we were supposed to create a patch for the hello.c files or if it was for a different program. Maybe I'm just being an idiot, I don't know. Let's hope the last one goes better...
7.9:
This is a step-by-step exercise that wants you to create a patch echo for a project. I actually really like this one because I'm a Windows user, so I don't know a whole lot about the bash commands except for what I used last semester in CSCI 362. Unfortunately, my terminal keeps telling me that the commands I'm trying to use aren't correct, and typing exactly what TOS is telling me to type in the exercise. I don't understand why this is happening. I did read through the exercise and I'm pretty confident that I understand what's going on. It's basically a reinforcement of the two previous exercises along with teaching the new concept of creating a working echo binary.
Tuesday, February 7, 2012
2/8/2012 (TOS Chapter 6)
For this post we are to do exercises 6.4, 6.5, 6.6, and 6.7 from chapter 6 of "Teaching Open Source".
6.4:
The oldest bug I could find was #5231 (DVD Player: Certain AVI-files play too slow/fast after seeking forward/backward). This ticket was first created 3 years ago and is still an unresolved problem (it was last modified 3 weeks ago). The bug here doesn't seem to be occurring on a consistent basis, which is a problem when debugging software and is probably the reason why this one hasn't been fixed yet. I can't think of a solution to this bug. No bonus points for this chica. (Insert Debbie Downer sound clip here).
6.5:
This is something that I had already done before the assignment because you have to have an account to get into the forums. Can I get bonus points for that one? (Don't look at me like that. A girl can dream, you know.)
All kidding aside, you have to have an account to contribute in any way to the XBMC project, and each member of our group registered in the forum community before we began looking at the bug tracker.
6.6 and 6.7:
I could not do these two exercises because my VirtualBox screwed up somehow. Lovely. Just lovely. Thank the Lord I remember how to install it.
**NOTE: Something's wrong with the Blogger tonight, so I had to highlight the bulk of this post in black so I could read it. If it changes back to normal later, I will fix this post.
6.4:
The oldest bug I could find was #5231 (DVD Player: Certain AVI-files play too slow/fast after seeking forward/backward). This ticket was first created 3 years ago and is still an unresolved problem (it was last modified 3 weeks ago). The bug here doesn't seem to be occurring on a consistent basis, which is a problem when debugging software and is probably the reason why this one hasn't been fixed yet. I can't think of a solution to this bug. No bonus points for this chica. (Insert Debbie Downer sound clip here).
6.5:
This is something that I had already done before the assignment because you have to have an account to get into the forums. Can I get bonus points for that one? (Don't look at me like that. A girl can dream, you know.)
All kidding aside, you have to have an account to contribute in any way to the XBMC project, and each member of our group registered in the forum community before we began looking at the bug tracker.
6.6 and 6.7:
I could not do these two exercises because my VirtualBox screwed up somehow. Lovely. Just lovely. Thank the Lord I remember how to install it.
**NOTE: Something's wrong with the Blogger tonight, so I had to highlight the bulk of this post in black so I could read it. If it changes back to normal later, I will fix this post.
Subscribe to:
Posts (Atom)