POSSCON Plans, Part: the Second

I've still not thought of good questions to ask the people who interest me.  I'm going to attend their talks and seek inspiration there.  I'll be posting the talks I plan to attend now.  The speakers I want to "interview" are in bold typeface.

Chris Hinkley will be presenting Web Hosting – Knocking Out Application Layer & Open Source Threat from 10:00 to 10:45.

John Diamond will be presenting about Open Source Gaming from 11:00 to 11:45.  

Walter Bender will be presenting Learning to Learn: Using & Modifying the Sugar Platform from 1:15 to 2:00.

Bryan Johns will be presenting The Case for Open Communications from 2:15 to 3:00.

David Duggins will be presenting Starting and Running a Business on-the-cheap with Open Source from 3:15 to 4:00.

Nathan Marz will be presenting Become Efficient or Die: the Story of BackType's Success from 4:10 to 4:50.




And, of course, I'll be attending the Tablet giveaway, just in case.

POSSCON Plans

In order to get to Columbia by 9:00, we've got to leave here (Charleston) uncomfortably early.  Whining about getting up early isn't the overall point of this post, however.

John Diamond will be speaking about open source gaming.  He is the CEO and lead developer of COR Entertainment LLC, a company that was initially formed in 2006 that developed the popular open source game Alien Arena.

Bryan Johns will be speaking about open source solutions in telecommunications.  Bryan spent nearly 20 years in and around the businesses of technology and telecommunications.  He has started, grown and sold a handful of web application development and VoIP technology businesses and in 2004, found a home in the disruptive world of open standards and open source telecommunications platforms.

Nathan Marz will be speaking about big data.  Nathan Marz is the lead engineer at BackType where he builds analytics tools for social media.  BackType collects many terabytes of data from Twitter, Facebook, social news sites, millions of blogs, and provides analytics on this data in real-time.

All three of these topics interest me to some degree, big data and gaming more so than telecommunications.  Over the next few days I will ponder some questions to ask them.

OpenKinect: Documentation and POSSCON

The source code for our chosen project is documented fairly well already.  I think we should add some comments to the code in the few places that lack an explanation of the function/segment of code.  Further, I think we should document our additions to the code with more in-depth comments for those with little experience with C.  A working source with good documentation can effective for learning a new language.

POSSCON is coming up soon.  I'm looking forward to that seeing how professionals use and contribute to the open source community.  In a later post I'll cover the people I intend to talk to at the convention and the questions I want to ask them.

Catchup

It seems I was remiss in my blogging.  I completely forgot to blog about TOS chapter 8.  Chapter 8 is titled Explaining the Code, but it's really about documentation; I suppose the two aren't mutually exclusive.  The text describes two types of documentation: ad hoc and planned. 

Basically ad hoc documentation occurs during the working process.  Any code that gets developed must have documentation that explains the reasoning and any unclear code.  We've learned good practices to use to develop sufficient ad hoc documentation in every programming class we've taken.

Planned documentation is the development of a formal document that fully explains a piece of software.  This type of document is of much higher quality than the ad hoc documentation.  We learned how to generate these kinds of documents in Software Architecture and Design.

An important concept the chapter addresses is the waterfall method approach to technical writing.  It outlines

 

1. Planning -- who is the audience? What are the book's goals?

2. Content -- what are the chapters about? Where will you get the information?

3. Writing -- first draft, review, second draft ...

4. Internationalization/Localization -- will the book be translated? Into what languages?

5. Review -- what worked? What didn't? How will the book be maintained? 

 

and says that starting with the first and proceeding down is the best approach.

OpenKinect Schedule

After reading through James' most recent blog post, I've created and posted a rough schedule for the rest of the semester on the project wiki.  It isn't very detailed yet, but it does provide a good outline for what we've done and what we will be doing.  As we make progress, we can fill in the details, which registers we'll focus on at any given time, for example.

After some initial discomfort with C programming and low-level hardware driver manipulation, James' amazing progress and coding skill have swayed me to the feasibility of actually succeeding with this project.  We've already made some non-trivial contributions, and the more we accomplish, the better off the project will be as a whole.  I'm looking forward to seeing what we can do by the end of the semester.

The cost of boredom

Tuesday I decided to do the exercises for TOS Chapter 7 because I was at a loss for something else to do.  Now today I'm finding myself without anything about which to blog.  I updated our team's wiki page to reflect our decisions regarding our "bug" and semester contribution to the OpenKinect project.  Briefly, we need to figure out the USB Control Command structure, write a USB control command for the OpenKinect libfreenect library, and then use it to manipulate the RGB camera in the Kinect controller.  Hopefully, it'll be as easily done as said, but I'm doubtful it'll be simple.

TOS Chapter 7

Chapter 7 of the Teaching Open Source book is about patches.  In short, patches involve running the diff command on a file that has been changed.

Exercise 7.2.2
The -u option to the diff command makes for a much more readable output, and it even includes some context (which isn't strictly necessary since "hunks" of code are labeled with line numbers.)  The diff command without the -u option is still useful, it's just not as easy to read.

In the initial, simplistic example, only one file was modified and patched.  A more comprehensive example followed which made a change to two files in a directory and a diff was applied recursively to the directories.  This captured the changes to all files within the directory, which will be much more useful when working with huge source code directories.

Both the individual file and the directory diff patch methods are not using an SCM.  Using an SCM to create a patch is almost identical, except, instead of using two different files/directories, the SCM compares changes in the current working copy against the most recent revision.  The latest HEAD code should always be used when making a patch, so that the development team can more easily integrate the patched changes.

Applying a patch is a simple matter.  It's similar to the shell redirect described in the initial diff section, only instead of redirecting the output of a command to a file, a file is redirected to the input of a command.  That command is, shockingly, patch.  Running patch from the directory in which to make changes seems easiest.  The option exists to run the command from root, but I don't fully understand the -p flags.  From the text it sounded like I could strip off x number of directories from the paths listed in the patch, but if I'm running the patch from the root directory, wouldn't those files then exist in the root directory?  I'll have to remember to ask about this in class.

I think I missed the point of Exercise 7.8.  Creating an empty file called foo, and then running diff on that new file against /dev/null resulted in no output from the diff.  I imagine that's because both files are empty and there's no difference between them.
So I asked about the exercise in class; turns out, the fonts on my screen look too similar to tell apart.  I was supposed to create an empty file called foo and put "bar" as the contents of the file.  This would have yielded some output from diff -u when run against /dev/null.

Exercise 7.9 was almost identical to the example for running diff on a single file from the very beginning of the chapter.  The only difference was the file was located at the end of a path, instead of in the working directory.  The patch file was formatted exactly the same.

Exercise 7.10 tells us to make a patch for our selected project.  We're steadily working on that, and I'm convinced we'll have this feature request completed "soon."