Reflections On My Progress...

The FOSSils have been attempting to submit our first documentation fix.  Unfortunately, it is not going too well.

First of all- wrapping our head around Git has been embarrassingly difficult.  But at least we are learning now and not later,  right?!

While the Django community is great and there is always someone to help, we can't seem to write documentation that they approve of.  So as a team, we have been discussing moving on to an actual bug.  I'm not sure if this is a good idea or not, but at this point we are sick of Django documentation and maybe finding a solution for an "easier" bug will be more straight forward than their documentation.  It is a bit disheartening- Django seems to have an overwhelming amount of contributors and I kind of feel like we're in the way- but we're just going to have to try harder to help.

Also another ticket that I recently signed up to "own" was fixed 12 hours ago...so that was a fun surprise.

Future plans:
We are looking for another ticket- an actual bug that we could fix *fingers crossed*.  Earlier Tim (a Django core developer) offered to have a video conference with us- I think we might try and meet with him Friday before our SPRING BREAKKKKKK!  And we might have a team meeting over break- I like hanging out with my FOSSils- so it won't upset me too much.

Here are tickets we are considering:  22079, 22078, 22056.

Refactoring Mindset

Today we have exercises out of our textbook  Software Development:  An Open Source Approach.

Unfortunately I have no idea how to approach these exercises.  The instructions are unclear and I'm not sure where to find...anything useful that's related to the exercise.  I MUST be missing something.

I learned all about "smelly" code in Chapter 5.  A portion of code emits a bad smell when it is not easy to read and could be improved.  There's a whole list of common types of bad smells.  I will list some of them for your perusal:

• poorly named variable, method, or class
• A guy who sat next to be in my first CSCI class ever, decided to be "cute" on a test and named his variables: cat, meow, dog, bark, etc- he was deducted many points- the professor was not amused.
• duplicate code
• long method
• large class
• too many/too few comments
• apparently too many comments can hide bad code AKA the comments are "used as deodorant".  Is it wrong that I find this section hilarious?
• data clumps

There are many more bad smells, but I'll stop at these.

So once the offensively smelly code is found, it is refactored.  This means modifying the code to improve its readability, efficiency, or modifiability.  Refactoring usually changes the size of the code base and makes the code more simple.

It is recommended by this text to develop a test suite while gathering requirements for a project and before any coding is started.  This type of software development is called test-driven development (TDD).  TDD is great because it keeps the client in the loop (the client explains the desired end result and what the system needs to do before they approve it).  TDD also motivates effective and focused code development.  Professor Omsted actually talked about this recently in CSCI 360- basically if you write the test suite first- it's like you have the answers to a test- you know what you're going to be tested on!

And then finally there is debugging.  A bug is a defect or flaw in the code base that causes or helps cause a failure (unacceptable behavior).  It is best practice to add a new test to the test suite that addresses the particular bug that has been corrected.

*UPDATE:
The class was given some time to work on the book exercises in class and I did get a little further with help from my classmates.  We were able to find the module in RMH Homebase that displays a shift's notes- calendar.php.  We were able to locate the "ugly" code and defined a new function called "predates(a,b)".

We inserted this as a new feature of the Shift class.
...Annnnnd that's as far as we got.

That could be me in x years!

Tuesday, the Computer Science Department had their 8th (I think?) annual Computer Science Symposium.  It was packed with a lot of familiar alumni faces- Melissa, Lee, and Tatiana.  

I was really proud of my sister and the encouraging speech she gave about start-ups.  Unfortunately I missed half of it due to an embarrassing choking-on-water incident.  The more I tried to stop coughing, the worse it got and I think it threw my sister off- Sorry Melissa!  But everyone told me that she did great and some of the FOSSils get to meet her in person this weekend!

It was really interesting to hear everyone's advice, especially since a lot of these alumni were in our shoes not too long ago.  

The tid-bits I took away from it was to find something you're passionate about and try to excel at it.  My sister LOVES her job- not a lot of people can say that.  I want to be a person who loves their job.  To be excited to go into work.  To like and care about the people you work with.  That is where I want to be- in an environment where I can thrive and learn with people who are encouraging and supportive.  

Money isn't everything.  I've learned this lesson before in my other career and will not repeat it.  I am striving to be happy and if I'm not- I'm moving on to something else.  I'm sure this sounds a bit naive and silly, but life is too freaking short.  I aim to be happy.  I was not happy in my other career, I was miserable.  I kept giving it more time and more time.  "One more year and you will love it!"  I would keep telling myself, but that was not the case- so I did something about it.  Quitting my job and my nursing career path was by far the scariest decision I've ever made, but it was a good one...I think/hope.

Currently, I am interning under my sister's supervision at BrainPower Software and I'm...happy.  Life is pretty sweet and I really can't complain.  Even though I do not graduate until May 2015, I am starting to think ahead more and trying to figure out what I want out of, not only my career, but out of life.  I can't wait to see what happens and where I'll be in x years!

What's Happening?

Patch it up!

This week we learned all about patches.  What is a patch?  A patch shows changes that have been made (line-by-line).  This is shown with either a '+' to represent additions and '-' to represent removals in the code.  When submitting changes to a FOSS project, patches are the preferred method.

Our first exercise was to diff two files we had been working with in the text without using the -u flag.  With the -u flag, a patch was printed out in my terminal in great detail:  showing which files were involved, printing out the entire code and showing +'s and -'s where code was changed.  When the -u flag was removed, the terminal printed a "<" along with whatever line was modified and then it printed out a ">" with whatever that line was modified to.  For some reason, my output was not the same as the text's, but if I flipped the file order in which I diffed them, then the output was the same:

The books instructions:

My results:

My results when switching file order:

Weird.  I'll have to remember when I'm diff-ing files to put the original one in first.

Our next exercise involved creating a patch for a new file.  To be honest, I'm still not sure I did this right.  Here is the exercise:

Create a patch file that represents a new file, foo being created with the contents bar. Hint: on Linux systems, the file /dev/null represents an empty file -- use that as one of the files you are comparing.

My outlined thought process:  

1. I have to create a patch file...I'll name it "exercise-7-8.patch"
2. I have to create a new file "foo" with the contents "bar"
3. ?!?!?!?!?!?!?!?!?!?!?! ...maybe I could.... ?!?!?!?!?!?!?!?!?!

So I ended up consulting good 'ol stackoverflow and came up with this:

I created a file in my text editor, "foo", and saved it with the contents "bar".  I then ran this command.  After running the command I have a "exercise-7-8.ptach" file with these contents:

So that's right...right?!  That's what this exercise wanted?  Yes?  Cool.

The last exercise is titled "Patch echo". 

Patch the echo command from the coreutils project so that it echoes out arguments in reverse order.

Huh?  Well luckily there were step-by-step instructions to follow, so I did, hoping to understand the objective of the exercise as I delved deeper.

It was all going smoothly until the last two instructions:

$ ./configure$ make

and

$ src/echo is this reversedreversed this is

I was silly and entered the first command in the command line not once, but three times before I realized it was not one, but two commands. *shakes head in shame*

$ ./configure

and

$ make

The last one also needed to be split in two.

This is the command:

$ src/echo is this reversed

This is the output:

reversed this is

That's just sassy.

The article I read was "The Second-Order Effects of Steve Jobs" and this was taken from the January 2012 Computer magazine.  

"For 20 years, Steve Jobs provided us with a gift- technology from the future."

This article gives examples of how Jobs pushed the industry forward.  One example the author gives is when the Mac II came out in 1993 with 256 color levels and IBM was telling its customers "You don't need color:  we've already provided it.  You have four of them- black, [yellow], cyan, and magenta."  That sentence made me chuckle.  

Steve Jobs was an innovator and when he left Apple because the board and management "valued top-down, business-style control over a relentless, quirky, unpredictable and seemingly risky quest to push the envelope of feasibility", the company suffered.  So when Jobs returned, he made it clear that Apple's purpose was to innovate.

It's amazing how far technology has come.  I remember dreaming about products that I actually do own today...because they aren't fantasy...they are reality.  How crazy is that?

````````````````````````````````````````````````````````````````````````````````````````````````````````````````
The next required reading was an article written by Peter Wayner titled "12 predictions for the future of programming".

1.  GPU's will be the next CPU's. 
•  I've already encountered this GPU-muscle-flexing in our very own computer lab, so I can definitely agree with this prediction.
2.  Databases will perform increasingly sophisticated analysis
• There is more data now than ever and this data is helping companies make big decisions.  Agree.
3. JavaScript for everything
• They have valid points.  Seeing as I've never coded a line in javaScript, I immediately went to codeacademy and I'm happy to report they have a javaScript course- which I'm starting the moment this blog is finished.
4. Android on every device
• Literally everything is going to have Android.
5. The Internet of things -- more platforms than ever
• Literally everything is going to have internet.
6. Open source will find new ways to squeeze us
• This is sad.  I don't like it, but it's the way the world works.
7. WordPress Web apps will abound
• I need to tinker with WordPress- I've meant to for a while now.
8. Plug-ins will replace full-fledged programs
• Don't build from scratch
9. Long live the command line
• I've grown to really like the command line.  Plus I feel like a bad-ass when it's up on my screen. 
10. Dumbing it down will fail
• Agree
11. Outsourcing and insourcing will remain deadlocked
12. Management will continue to misunderstand coder and coding
• Communication is key!  

I enjoyed reading this article.  This field is so exciting!   Maybe the rest of today should be spent learning javaScript or working with WordPress rather than getting under the covers and taking a nap.  

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*