Squashed?

This weekend was suppose to be spent at the CWIC conference over in Mount Pleasant.  Unfortunately I've been sick.  More sick than I can remember being in a long while.  I had a stubborn temp of 101 all weekend (a temperature I haven't seen on the thermometer since I was in middle school).  So long story short- this weekend was awful and I'm beginning to wonder if I have bedsores from the lack of movement (KIDDING- nursing humor).

Team FOSSils has been working diligently on our ticket.  We did not take into account that in order to "fix" our ticket, we had to build the djangoproject.com code (the website code).  This has been extremely difficult.  The readme provided is...lacking...to say the least.  The good to come of all this is that we'll be able to provide a new and improved readme.  Bobby has taken the lead on this and has helped each of us with the building process (Thanks Bobby!).  Meanwhile, Lynn has found another mentor through the core mentorship mailing list.  His name is Tim- apparently he recently finished his employment with Google and has more time to work on side projects.  He has even offered to video chat with us.

For now we are putting this ticket on hold and focusing on another ticket we have taken ownership of.  Here is the Description:

Currently, the "Forms API" section of the Django docs (and in particular the ​Using forms to validate data section of that page), does not document Form.clean(), though the Form.add_error() documentation in that page references it.

There is some documentation about Form.clean() in the ​Form and field validation page, so perhaps the Forms API docs can link there for its information (and/or vice versa).

Django has a great section labeled "Writing documentation" that instructs the newbie how to get the raw documentation, get started with Sphinx, etc.

Django's documentation uses the Sphinx documentation system.  Sphinx is a python documentation generator.  Since these tickets are all about the documentation, we needed Sphinx.

1. To build the documentation locally, install Sphinx:  $sudo pip install Sphinx
2. Navigate to the Django-trunk and then to the docs folder
3. To build HTML:  $make html

Squashed?

No. Nothing has been squashed, but I feel as though we are laying the ground work for future squashing.  So- no, nothing has been squashed, but not for long.

This bugs me...

Task:  Find the oldest bug that's still open in your chosen project. Write a blog entry describing the problem, with a theory about why the bug hasn't been resolved yet.

Django's oldest ticket is EIGHT YEARS old.  Wowzers. It is not, however, a bug problem- it is a new feature- involving the admin interfaces.  This new feature would make it possible to have multiple fields worth of data entered in a single field.  This is the example they provide:

"For example, a field for a sports stat could be entered into a single field as "XX-YY-ZZ", whereas the three values are actually three separate fields in the DB."

The current triage stage is "Someday/Maybe" so I do not think that this new feature is of top priority- obviously- since it's been 8 years.  But I do see some involvement in the comments from core developers...but that was...ummm...TWO years ago.

Task: Figure out how to create a new account on the bug tracker of your chosen project. You'll need that account very soon.

It was super simple to join Django's bug tracker, but they call it a "ticket system".  I am now registered.

Task: Go through your project's bug tracker and find a bug that you think you might be able to reproduce -- and then try to reproduce it in the latest build. Take careful notes. Report your experiences as a comment to the bug. If you can reproduce the bug, great! Give as much information as you can. If you can't reproduce the bug, great! Give as much information as you can, and ask the original reporter if there are other steps you might be able to take to reproduce the bug.

This ticket reported a bug that produced an error when a field from a subclass was moved to its base class.  One of the core developers responded to this ticket giving instructions on how to reproduce the error step-by-step.  I followed it exactly, but could not reproduce the error.

What I did:

1. I had the subclass and base class in their original positions --> $ python manage.py makemigrations
2. Switched their positions, saved the file --> $ python manage.py makemigrations
3. After running that command on both those versions, $ python manage.py migrate, was suppose to cause the error, but it did not.

Task: Find five bug reports in the new state, and attempt to triage them according to the rules above. Your goal is to do as much as you possibly can, in a short period of time, to make those bug reports as useful as possible to the developer to whom they are assigned. (Note: be sure to follow any triage rules that your project may have defined. If there are no set triage rules, be sure to announce your intentions on the project's mailing list, so that developers can provide you some guidelines if they choose.)

There was one new ticket that was only 3 hours old so I was able to add this "helpful" comment:
"Hi, thanks for reporting.  Do you mind giving more information on how to reproduce this exception so a newbie could partake?  Thanks!"

This ticket did not contain any software versions nor was it very descriptive.  But that was about the only ticket I saw that I could help triage.  Django's triaging system seems to be really organized and people are quick to comment and move the ticket along the triaging line.

Reflections on Open Source in Today's World

Our class was assigned to read two articles from opensource.com.  

The first article I read was entitled "Make money and have fun in open source".  Christy Eller, the author of this article, points out the minuscule number of women in computing compared to the number of men.  She explains how she would love for her 11 year-old daughter to become more interested in computers, but the question is:  how are computers suppose to compete with Katy Perry "wear(ing) a candy striped leotard and strut(ing) around through a maze of life-sized lollipops"?! 

She then goes on to talk about how valuable open source tools have been to her career.  She now owns a freelance WordPress web design business, she says "I am making a good living using open source. And it's fun, it really is. I get to make things all day long, beautiful things."  

Christy feels like young girls need role models like herself so that they know what a successful career as a woman in technology looks like.  "Be the change you want to see."  

This was a really interesting read for me- I love the fact that Christy has taken free tools and made a career out of it- what other field could you do something like that?  Make something from nothing while making your imagination come to life.  So. freaking. cool.

 For some reason reading this article reminded me of this.  Maybe we need a lego girl software engineer who goes on adventures.

The next article, "Big data and Hospital OS improve Thai diet" caught my eye initially because of the word "Thai".  

I love Thailand...to the point where I'm borderline obsessed.  I made my first solo backpack trip to Thailand back in 2009, fell IN LOVE with the country, and went back again in 2011.  This summer I am planning on backpacking SE Asia for 6+weeks, so Thailand and I will be reunited once again!  

Another reason this caught my eye was "big data".  My sister graduated with a Discover Informatics...now, Data Science degree- and I have heard her give speeches on big data.  Basically, when big data is analyzed by people like my sister- it can help businesses make better informed decisions regarding...just about anything that has data.

Back to the article...

Dr. Kongkiat Kespechara is a practicing physician in Phuket.  When the Thai government demanded that Information Technology be adopted in all Thai hospitals, but didn't provide a budget for it- Dr. Kongkiat Kespechara decided to use Hospital OS (open source software) in hospitals all around Thailand to accomplish this.  And since he knew that most hospitals would not backup their data- he did it for them with his system.  This led to him having heaps of data from all over Thailand- eventually after several years, he was able to predict what outbreaks were coming.  The main disease that this article talks about is diabetes and how Dr. Kongkiat Kespechara was able to use big data to see the connection between diabetes and white rice, find an older form of rice that would not spike blood sugar levels-and find a way to retail this rice to the Thai people.  

By the end of this process, Dr. Kespechara had added a few thing to his resume...

"Dr. Kespechara is a still-practicing MD, a software entrepreneur, an open source pioneer, a force in economic development, a big data processor, a nutritionist, an agriculturist and a retailer."

It's incredible how open source software can help a whole COUNTRY in it's health.  Wow. Just wow.   

 

Bug Juice / Snowpacolypse 2014

The middle of last week was spent snuggling in bed with my puppy dog, eating obscene amounts of junk food, and progressively getting lazier and...smellier (who wants to shower in the middle of snowpacolypse?!).  

I also watched this clip far too many times.  

I actually did do some productive work- I started following a Django tutorial for creating a basic blog engine.  Right now I'm stuck- having trouble syncing my databases (pretty positive it's a user-error).  

But I digressssss...onward to the meat of this post--> 

Django has a section called the "Ticket system" where you can report bugs or find tickets that you would like to take ownership of and "fix".  Django has a great section titled "Contributing to Django" where there is heaps of information on how to get involved.  After browsing through the "easy-pickings" tickets, our team realized that this was going to be anything BUT easy.

The most frustrating part was reading tickets that made NO SENSE.  We took turns reading the different tickets over and over again, out-loud,  putting stress on different parts of the sentence because the grammar was so horrible.  This further showed me the importance of effective written communication.  I mean, COME ON- at least give an example of what you're trying to convey and YES- grammar is essential- use it.

We quickly realized that we needed guidance.  Lynn reached out in the django-core-mentorship mailing list and we got a very informative response from Russ, a core-developer.  After emailing back and forth, our team decided to go with ticket #17638.

BAM.  OWNED.

This ticket involves documentation.  Here is the ticket description:

"There is one thing bothering me with Django documentation: it's split between topic guides and API reference. Often while googling I get to wrong one and it's not always easy to find another. There should be an easy way to do that: a link at the top/bottom/sidebar. And this way should probably be somehow automatic, so new pages are connected automatically."

So basically this ticket involves auditing the current links between topics and reference guides and adding any links that are missing- this is in the djangoproject.com code, NOT the django software code. 

This particular ticket was opened 2 years ago and has been "owned" by one community member in the past, but it looks like they gave it up for one reason or another.

In response to connecting the new pages automatically, a core-developer commented that this should be done manually and that making it automatic is "not likely to be worth the effort".  

It'll be interesting to see if our team can piece this together.  Even though this ticket is suppose to be "easy"- right now it feels like a daunting task, but nothing that us FOSSils can't handle *she says optimistically*

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