It's crazy how fast this semester has gone by. Spring Break has (unfortunately) come and gone, and in a little over a month the dreaded exam week will begin. It's definitely NOT my favorite time of year. Exams and group presentations and papers....oh, my!
The focus of today's team meeting was once again the bug fixes we are working on. The School of Science and Mathematics Research Poster Session is coming up in a few weeks, and we will have to make a poster to display there, so we're going to begin getting ready for this.
POSSCON is next week, and I'm preparing for that. We have to find speakers we wish to interview for our blog, so I'm looking at the list and trying to figure out questions I might want to ask.
Sunday, March 18, 2012
Thursday, March 15, 2012
3/15/2012: Team Meeting
We decided to meet up today to get some more work done on our project before Monday. I brought in a Blu-ray disc with me so I could take another look at the bug that I was assigned to tackle (Bug #12594). I found that it takes XBMC 46 seconds to fully boot up when I start it immediately after inserting the disc, but when I wait for the drive to read it or have no disc in the drive, it takes XBMC only 5 seconds to fully boot up. This leads me to believe that there is no problem with XBMC. I think the problem was with that guy's disc drive. So even though the bug couldn't be replicated, it's great that we were able to rule out any sort of issue with XBMC in that particular case.
Tuesday, March 13, 2012
3/13/2012
Just thought I'd place a quick update here for y'all....
All of the groups presented yesterday to let everyone in the class know where they stand in their projects. Our group is going to meet again tomorrow afternoon so that we can continue to work on our project.
Campus Internet died today around noon for some reason, and was pretty weak for the rest of the day. I was going to take the opportunity to catch up on some blog posts, but I'm currently unable to access Dr. Bowring's website in order to look at the syllabus. I can't even access the department's website for that matter. Hmm...well, that's not good. I hope it's not related to what happened to the Internet today. The class wiki is still accessible because it isn't a site through The College. However, it's link to the syllabus doesn't work. Hopefully tomorrow it will be better.
All of the groups presented yesterday to let everyone in the class know where they stand in their projects. Our group is going to meet again tomorrow afternoon so that we can continue to work on our project.
Campus Internet died today around noon for some reason, and was pretty weak for the rest of the day. I was going to take the opportunity to catch up on some blog posts, but I'm currently unable to access Dr. Bowring's website in order to look at the syllabus. I can't even access the department's website for that matter. Hmm...well, that's not good. I hope it's not related to what happened to the Internet today. The class wiki is still accessible because it isn't a site through The College. However, it's link to the syllabus doesn't work. Hopefully tomorrow it will be better.
Sunday, March 11, 2012
3/11/2012: Weekly Group meeting
Today after a lovely Spring Break, Team Triple J met up to discuss our group's progress during the break. There was good news and bad news. The good news is that we were able to replicate a couple of the bugs from our list. The bad news is some others were fixed by other developers and a few of the bugs couldn't be replicated, including the one that I was working on (I'm still trying though). Because of this, we've had to start looking at the bug tracker and pick out a few ore bugs to look at in place of the ones that have been fixed. We updated our project timeline to reflect these changes. Oh, and over the break the developers released a new release of XBMC: "Eden" Candidate 2 so we spent time today downloading this version on Ubuntu.
Wednesday, February 29, 2012
2/26/2012: Weekly Group Meeting
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.
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.
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.
Subscribe to:
Posts (Atom)