Subversion Under Control

Subversion vs. Git

Last semester when I told my real-world-software-engineering-working-friends that I was using subversion (SVN) for my CSCI-362 project, they were pretty much appalled- going on long rants about why I should be using GIT.  I do not remember the points they made back then, so this was a chance to look into it myself.  Based on their reactions, I will have strong feelings about which version control I use when I'm in the working world.

I have VMware Fusion installed on my computer from last semester and decided to add a new virtual machine for this semester (and a couple of back-ups, just in case).  Both GIT and SVN were very easy to install with commands that I googled.

What is version control?

Version control is a system that allows you to keep a history of the changes you/a team make to a file.  So, for example, if you make a commit and at this point in time, your code is working great.  Maybe an hour later something breaks and you cannot find the fix- luckily you can easily revert back to the file you committed when everything was working!  Both SVN and GIT are types of version control that both get the job done, but in slightly different ways.

GIT is the new and cool way of doing version control- which was obvious by my hip real-world-software-engineering-working-friends' earlier reactions.  GIT was developed by Linus Torvald for Linux kernel development.  A lot of googling leads me to believe that GIT is also the most popular version control available at the moment.

GIT is distributed.  And that means...  

Instead of "checking out" a repository, you "clone" the repository which means you get the latest version and all the history associated with that project.  This means you have a complete repository!  Which in turn means that instead of having a central repository (like SVN), GIT has multiple repositories.  The benefits of having multiple repositories is that if something is wrong with the main repository- developers can still work and commit their code locally and then push it up when the main repository is fixed.  A "push" in GIT is like a "commit" in SVN.  Commits in SVN can take time, while commits in GIT are very fast.  Working with GIT is faster because there is no need to communicate to the central server!  And (this point I do remember from my real-world-software-engineering-working-friends) is that you can work OFFLINE.  Very cool.

Team FOSSils has decided to use GIT this semester to broaden our knowledge and to show how "hip" us FOSSils really are.

Joining the Project

1) Select an IRC client and join the channel for your Team project; peruse the history and listen to current traffic; blog about your experiences.

I have had no experience with an IRC client, so I googled "best IRC client for Mac" and got a couple of choices.

I decided to go with Colloquy.  

The UI is great and it feels like a Mac app.  

After registering my "nick", all systems were go.  I joined the #djano room and the #django-dev room.  The #django room for users was very active, but I was disappointed to see that there was not a lot of activity in the #django-dev room.  I did not interact, with the community I just "listened".  There was one user in particular that wanted to use Django on their site and was getting a lot of help.  I feel confident that if my team has any questions- answers will readily come from this community. 

2) Join the electronic mail list and/or newsgroup for your team project; select an interesting thread and explore it; blog about your experiences.

Our team collectively decided to join the following mailing lists:  django-users, django-core-mentorship, and django-developers.

Under the django-developers there was a ticket request review which caught my eye- after clicking and glancing at it- I am beginning to see how we will interact with the community regarding our bug fixes.   I don't think it's required to put your ticket revisions on the mailing list, but the contributor got a lot of feedback regarding his fix which I'm sure our team would appreciate.

The Reading

Our class is using the text Software Development:  An Open Source Approach.  Much of Chapter 2 in this text was review- as a class we've already talked about this material or seen it somewhere else.  I did think that the IRC etiquette lessons included in Chapter 3 of the online text and in Chapter 2 were good to look over.  Most of it was common sense, but still good to review.  Chapter 3 was more "getting started" material and (mostly) all review.  I will make it a point to go back and read The Bug Tracker section more thoroughly within the week.

Thoughts

Two of my friends who are applying their BS's in Computer Science to software engineering in the real world, have very different work environments.  Friend A works at a place where there is a strict no-finger-pointing-policy, while friend B works in an environment where finger pointing is part of that company's culture.  I'm assuming that both of these company's get their work done, but it is done in such different ways.  Pleasant work environments vs not-so-pleasant work environments.  This kind of goes back to the reading from last time-how the author thought that a charming leader was key to a successful project:  he fluffed his beta-testers/co-developers when needed (praising them in emails, etc) and charmed them into doing hard work.  Here he's clearly trying to create a pleasant "work environment" or I guess- pleasant community-experience in this case.  Let's just stop pointing fingers and get the work accomplished.  Shall we?!

FOSS Experiences and Reflections

For this blog post we were required to go find a new piece of open source software that interests us. Install it, and report back with any problems.

Our team collectively decided to install Django.  Lynn and I decided to follow a tutorial appropriately titled How To Tango With Django.  This tutorial is very thorough and I assumed it would be relatively easy/quick to work through chapters 1 and 2 of the tutorial, but we all know what happens when we assume...

Everything was going very smoothly until I was to install the Python Imaging Library.  Unfortunately I had dependency issues to work out.  I worked around this by installing Homebrew.  Homebrew is a package management system that makes installing software on my Mac a lot easier.  (It's also FOSS!)  Then typing in these commands:

$brew install gcc48
$pip install Pillow

These commands helped me finish installing the Django software successfully.  

I also downloaded and played with GIMP.  GIMP is an acronym for GNU Image Manipulation Program, it is a image editor.  This installation was very quick.  I had three images that I needed to edit and this software really impressed me.  Also, any questions I had were easy to find answers to as there were a ton of tutorials on anything and everything.  GIMP seems to have quite the following.

Required reading:  The Cathedral and The Bazaar

The author of this 30+page essay is Eric Steven Raymond.  You can view his resume here.

This whole piece is about how the author inherited popclient and the lessons he learned as it evolved into a completely different program, Fetchmail.  During this process he tried to emulate Linus Torvald's style of development- "release early and often, delegate everything you can, and be open to the point of promiscuity". In all, Raymond provides the reader with 19 lessons that he learned throughout this process.  

Raymond quotes Brooks- an author we read last semester- the author of The Mythical Man-Month-throughout this piece,  and usually agrees with him up until the chapter titled "The Social Context of Open-Source Software".  Raymond states that if Brooke's Law ("adding manpower to a late software project makes it later") were "the whole picture, Linux would be impossible".  Raymond goes on to explain the concept of "egoless programming" which the author of The Psychology of Computer Programming, Gerald Weinberg, observed.  Egoless Programming:  "in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere".  Raymond goes on to say that the bazaar method harnesses the full power of "egoless programming", negating the effect of Brooks's Law.  Brooks Law is not the be-all and end-all.

What I took away from this piece:
More heads are better than one.
Always listen to your customers.
Treat your beta-testers and co-developers well.
Use your charm...WINK.

Favorite lesson/ quote:
"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." - Antoine de Saint-Exupery

My FOSS Preferences

The class teams are to choose three open-source projects that we would like to participate in.  The tricky part is that we need to choose projects that have active communities.  So TeamFOSSil's prerequisites for the team project are as follows:  the open source project has to be written in python (member preference) and has to have an active community.  This shouldn't be too hard to find, right?!

Number One Choice:  Django 

The "D" is silent- pronounced "Jang-oh"

It was suggested by Lynn that we look into Django.  I had no idea what Django was in regards to open software.  The first thing that popped into my head was Jamie Foxx in that Quentin Tarantino movie- EXCELLENT movie by the way.  "Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design."  In a nutshell, it allows you to quickly build high-performing Web applications.  It was originally developed to manage several news-oriented sites for The World Company  of Lawrence, Kansas.  The framework was named after guitarist Django Reinhardt who is often regarded as one of the greatest guitar players of all time. Django has some bragging rights.  Here are a few sites that use Django- Instagram, OpenStack, Mozilla,  and (my personal favorite) Pinterest. Django is written in Python and has a VERY active community making it my favorite choice for this semester's project.  It also seems very newbie friendly- another bonus.

Choice Number Two:  SaltStack

Bobby vaguely remembers hearing about this choice at some CSCI talk.  SaltStack is a new approach to infrastructure management- it runs within seconds, scalable enough to manage tens of thousands of servers, and can communicate with these servers within milliseconds.  For newbies, the Saltstack site says- "There is no need to introduce yourself, or ask permission to join in.  Just help and be helped."  I like it.  There is a lot of documentation, an active community, and even a YouTube channel!  Plus it meets all of our prerequisites because it is indeed written in Python.  Oh snap.

Choice Number Three:  Gramps

This choice started off as a joke since it would fit perfectly with our FOSSils team name- Gramps just goes so well with our old team member theme, but it could in actuality be a decent choice.  This is free and open source genealogy software.  This is software for genealogists or genealogist hobbyists- a way to keep them organized.  Now the community for this choice is a little lacking- definitely nothing like the community for Django.  The site says that the filing and tracking of bugs has low traffic, but that discussions on using Gramps and issues relating to software development have medium traffic.  It is written in Python as well- but we have two much much better choices above.

The preface of the book reiterates why participating in FOSS is advantageous.  Alright. You've convinced me.  The preface also goes over class organization, a sample syllabi, and other support and guidance.  

Chapter 1 gets more interesting.  From last semester's readings, I was aware that software failures do happen, but for some reason I was still a little shocked to read that according to the 2009 CHAOS Report, only THIRTY-TWO percent of all software projects were completed on time, on budget, and with full functionality.  The text lists many reasons for these software failures, but it singles out "improper choice and deployment of an effective development methodology" as the main culprit.  

I will sign off with the

Four Freedoms of FOSS: 

1. Freedom to use
2. Freedom to modify
3. Freedom to distribute
4. Freedom to improve

Productively Lost?

A new semester, new required texts, new team members, and the same (one and only) Dr. Jim Bowring.  This semester CSCI-462 is relying partially on an online text.  Teaching_Open_Source 0.1 - Practical Open Source Software Exploration:  How to be Productively Lost, the Open Source Way.  This text aims to teach students and self-learners the basic skills of open source development  through real involvement in meaningful projects.  Chapter 1 explains why a student/ self-learner would need this text.  David A. Patterson, a computer science pioneer, advocated for the inclusion of courses in open source software development in computer science curriculum.  Unfortunately the world of academia did not heed his advice, as the text puts it, "because it's hard".  The text stresses that "the skills required to succeed in an open source software project are the exact same skills required to succeed in any large software project."  In short, this is real world preparation folks.   The text also stresses that one of the most important skills a developer must possess is the ability to be "productively lost".  Last semester I was mostly lost, so hopefully that will be of the productive variety this time around.

And as this may show up on the ONLY test this semester as a bonus question, this handsome gentleman is David A. Patterson.

He is most known for contribution to RISC processor design and his research on RAID disks.  He was president of the Association FOR Computing Machinery from 2004-06.  He has also co-authored six books and has been recognized by about 35 awards for research, teaching, and service.

At this point I'm happy with my post and want to stop writing, but I'm 200 hundred words short so....

In Chapter 2, we get a preview of what we will learn in future chapters.  Here are some of the covered topics:  version control, build management, documentation, bug hunting, and the mechanics of fixing code.

So what is the value of sharing?  Why is FOSS valuable?

• Shared development costs- time is money and this time can be spread out over several individuals. 
• Users can fix their own bugs...OR find other people to fix their bugs for them.  This section provides a great analogy between a car fix and a bug fix.  
• Arguably better software- since there can potentially be many more people working on a FOSS project than the number of developers any company could pay.  But didn't we learn last year that more man power doesn't necessarily mean better software? I guess that's why "arguably" is the lead on this header.
• Software that outlives its creator- code that isn't shared can turn into abandonware and die with its creator, but FOSS projects have a chance to be reborn.
• The freedom to fork- ummmm, what?  Apparently this means taking a project in a new direction without asking for anyone's permission.

This semester I am on a four person team.  My other team members are Lynn Kitchner, Chris Moore, and Bobby Jenkins.  I'm pretty excited to be on a team with such cool cats.  Since we are all a little older than our other classmates- Chris suggested we call ourselves the FOSSils.  I obviously love this idea and hope that this will become our official team name, but we have yet to vote.