3/25/2012: Team Meeting and Getting Ready for POSSCON

We met at our usual time, but were down two team members due to illness and a prior engagement.  So it was just Jason, Jimmy, and myself today.  Our task is to complete the next milestone (Milestone 4 - Wiki/Documentation Edits).  Unfortunately, we couldn't work on that while on campus because campus internet has slowed to a crawl since Friday and it refuses to load some of the pages on the wiki thanks to time-outs.  So we're each working on wiki pages from home and looking for specific changes to make.  Mine are spelling and grammar, along with correcting function names if necessary.


So...POSSCON...I started out with a list of 5 potential speakers who I really want to see give their presentations. After giving it a great deal of thought, I've narrowed it down to 3.

1. Mark Litz - Senior Manager of Systems, Database and Computer Operations for the South Carolina Department of Corrections.
2. Chris Aniszczyk - Open Source Manager for Twitter.
3. Carol Smith - Program Manager at Google.

I also plan on attending Dr. Bowring's presentation on the 28th, which will include some of my classmates who volunteered to take questions from the audience and talk about their experiences.

SD Chapter 6: Exercises 6.1 and 6.4

These are the two exercises that are to be done for this blog post....
Exercise 6.1--"For the Person class, define a new pair of functions to set and retrieve the value of the variables $employer, $contact_person, and $contact_phone in preparation for implementing new features 1 and 9d in RMH Homebase."


Exercise 6.4--"Refactor the existing Person class by removing all the mutators that are not called from anywhere in the code base.  Be sure to test your changes by rerunning the test suite."


I've got RMH Homebase on Windows and not Linux because I had issues getting it on my Virtual Machine.  I've got a Wamp server up and running and everything.  I opened Eclipse to work on the code and do these exercises, but Eclipse crashed on me while I was trying to figure out how to build a PHP project in it.  THREE TIMES.  I really don't understand this.  It's like my computer's on strike tonight when it comes to my 462 homework.  This makes me want to hit my head against the wall, but since I don't want to hurt the wall I'll just try to figure out what the problem is.  Maybe.  Hopefully.

Learning to Play Nicely With Others: TOS Chapter 3 and SD Chapter 2

The readings for this post are from the two texts we're using, and deal with working in a global community and working with a a project team, respectively.


TOS Chapter 3
This chapter is about learning how to interact with the open source global community.  No matter how big or small the project may be that you pick, you have to first and foremost understand that working on open source projects means working out in the open, and communication with everyone involved is the key element to doing so.  You have to remember that every FOSS community has their own way of doing things, their own culture.  This isn't influenced by the culture of the countries of those involved, but by the "shared experiences, humor, social norms, and conventions that define that community, building up a synthetic third culture".  The qualities of the community are listed as follows:

• Focus: What the community wants to achieve.
• Maturity and History: The age of the project.
• Type of Openness: This can vary from active communities with strict management hierarchy headed up by a development leader (read: dictator) to communities that are completely open to any and all.
• Commercial Ties: Whether or not the project is being sponsored by a company or companies.
• Subgroups: Whether or not the community operates as a whole or is divided into subgroups.
• Skills: Each community focuses on and requires a certain skill set for contributors, so having new contributors come it with skill sets not already a part of the project can be beneficial.
• Mentoring and Training: There's no Mr. Miyagi here, but some communities do have some simple training or mentoring programs to help the community grow and learn.  Wax on, wax off...

There are three main challenges that arise from working in a global community:
1.  Language barrier--this one is obvious.  I mean, sometimes understanding what another person is saying can be difficult from region to region in the same country, not just from country to country.  Establishing a common language (or, depending on the project, a common measuring system) is essential to breaking down the communication barrier.  Coding comes easily. Talking is hard.
2.  Time and distance--also obvious.  Not everyone operates on the same schedule; some prefer coding at night and others during the day.  Meeting face to face can be difficult because the other person could be halfway around the world.  Communicating through other methods, like via email and IRC channels, is a good way to overcome that.  Wikis and blogs are also a good way of communicating with others about your project.
3.  Ego--while there's not a lot of money (or none at all) involved when taking part in a FOSS project, wanting individual recognition can really hurt a community like this.  Acting like this will make others not want to work with you.  It's the same reason no one wants to pick you for their team in kickball--no one likes an egotistical jerk.


Exercise 3.5: Project Wikis
1.  Our project, XBMC, uses the MediaWiki software package for its wiki page.
2.  The project's history is in the wiki under Team XBMC-->XBMC.
3.  The last revision of the wiki was made on March 10th by Ned Scott.  I would consider this to be thriving since it's a very active project.
Exercise 3.7: Linking Your Blog to Planets
For this exercise we are to link our blog to our class planet (the class wiki).  We did this at the very beginning of the semester.
Exercise 3.9: Learning IRC
Already did this one at the beginning of the semester, too. Hooray!!
Exercise 3.11: Joining the Mailing List
XBMC doesn't have a mailing list, only a forum and bug tracker which I have joined.


That's it for TOS Chapter 3.  On to the next part of this post!!


SD Chapter 2
This chapter talks about interacting with a team and how to choose a good FOSS/HFOSS project.  Working in a team setting is like a development community, only it's on a much smaller scale and more structure.  Each team member has a key role, however, the same person may have two or more roles simultaneously.  They are:

• Team Leader: the person who oversees the development process.  Tasks include setting weekly agendas and milestones, assigning tasks to team members, coordinating overall system architecture, teaching other team members about new techniques, leading regular team discussions, and helping resolve design issues.
• Analyst: someone who understands the user's domain, elicits requirements, defines use cases, evaluates risks and alternatives, and sketches the initial design of the software to be developed.  Tasks may also include cost estimation and project scheduling.
• Developer: the person who writes test cases from requirements, and reads, writes, tests, debugs, and refactors program code.  Also refine requirements and use cases, write documentation and online help pages, and solicit feedback from users at each stage in the project.  Basically a programmer who can also read, write, and communicate effectively with users.
• User: the person who is knowledgeable about the application's domain.  Tasks are to review use cases, provide data for test cases, review the output of code written by developers, provide feedback on the quality of that output, and find bugs in the software after each iteration has been deployed.
• IT Technician: filled by persons who configure and maintain the technical environment used by the team.  Tasks are to set up and maintain the code repository, the staging server, the videoconferencing system, the team discussion site, and other software tools needed by the team to develop the software effectively.
• Observer: someone who is interested in watching the project develop and/or whose project management expertise may provide occasional high-level advice on particular design decisions.  This is a fairly passive role.

Team members must be respectful of one another (think the Golden Rule) because a collaborative effort isn't going to work if team members are acting like complete jerks to one another.  This includes respecting the constraints of the schedules of individual team members.


When it comes to choosing your team project, you're looking for a project that (hopefully) has these qualities:

• Popular: look at how many downloads its software has each month and how active its user and developer forums are.  If it's barely surviving or flat-lining, you don't want it.
• Vitality: check out the project's statistics.  The often include the number of new code contributions that have been made, and the number of new releases that are created each year.  All these are measures of a project's vitality and therefore show its receptiveness to the addition of newcomers.
• Growth Potential: don't go with projects that have matured and plateaued.  They may have a large user base and deliver a lot of value, but they don't provide newcomers with an opportunity to make an impact.
• Welcomes Diversity and Promotes Contributions: go for projects that are open communities with lots of opportunities for newcomers, not the close-knit group of buddies with a lot in common.
• Enjoyable: the project, not your class grade, should be the motivating factor for choose a project.  Chances are that choosing it because it's what your instructor would find fascinating isn't a good enough reason to work on a particular project.  Pick something that you're interested in and will be excited about working on it every chance you get.

SD Chapter 6: Developing Domain Classes

As the book says, "domain classes are at the heart of the software architecture".  They are the key element in understanding any system.  The book lists the main steps of developing domain classes as different sections of the chapter.  Here they are in the highlights version (or Reader's Digest version, however you want to describe it):

1.  Reading a Design Document--A design document is described as a document that contains a domain analysis, a requirements analysis, and a set of use cases.  These are used in the following ways:

• domain analysis: describes how the current application works including any existing software that may be used to support that application
• requirements analysis: identifies the activities that the new software must support
• use case: provides a transformative view, showing how the system should support specific kinds of interactions between types of users (called user roles)

2.  Identify Classes and Modules--When reading the requirements for a new system, developers should look for the "big picture" nouns.  Basically the ones that can be abstracted into classes or modules, which are the major elements in the system design.

3.  Identify Instance Variables--Here, we look for detailed entities in the use case that characterize the state of an object in a class

4.  Identify Methods and Functions--You want to look for information that helps designers specify actions that need to be implemented for each class.  In a nut shell, you're looking for methods or functions.

5.  Reading Code--This one is pretty much a no-brainer.  I mean, how can you work on developing a system or work on a current system without reading the code?  Developers will get the code base and read to find the information they need.  There are 3 main goals here:

• To understand the overall architecture and functionality of the existing software
• To learn the vocabulary established by the domain classes
• To identify the extent to which the code must be referenced before it can be modified to support the functions of the new system

When reading the code base for the frist time, developers are advised to start from the top, look for classes with unique keys, and avoid the temptation to refactor.

6.  Examining the Domain Classes--The domain classes characterize the central concepts in a software system.  Basically, the define a name space that permeates the entire application and its documentation.  The names themselves originate from the user's domain, so that they characterize objects and actions with which the users are already familiar.

7.  Adding New Features--The client or group of end users of a software system usually provides the catalyst for adding new features to an existing software system.  As the developer, it's your job to make the necessary changes to the current system to add the features.  The system developers should have good communication channels with users, that way if there is a problem or new needs they can be quickly transmitted and resolved.

8.  Top-Down Analysis/Bottom-Up Development--Going along with "Reading a Design Document", after the key elements are identified (top-down analysis), their implementation evolves through the code base (bottom-up development).  This is done by first revising the domain classes, then the database modules, and finally the user interface modules.

9.  Documentation and Bulletproofing--Whenever a new function is designed, it should be documented using standard practices and appropriate preconditions and postconditions.  This is particularly important for non-trivial (non-getter and non-setter) functions.

3/18/2012: Team Meeting

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.

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.

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.

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.