Kuuliza Si Ujinga - (Direct translation) Asking is NOT foolish

Kuuliza Si Ujinga

As a native Swahili speaker, there are some things, especially Swahili proverbs, that I find impossible to express in English. So excuse the title - but sure hope the translation helps! ;) To elaborate on it a little, the proverb was used by encourage people to ask many questions, because asking does not mean your foolish. In fact, it means the exact opposite! 

I remember my teachers using this proverb a lot in class. After teaching a new concept, my physics teacher would always ask for questions - no hand was raised. This is because most of us were thinking that our silly question was going to waste time for the other brilliant students, and teacher. Plus, who wants to be the only one who did not understand?

So how does all this relate to opw?

One of my favourite activities during my internship is the opw meeting. The meeting is pretty informal - done over irc where the mentors and interns share their thoughts on whatever topic that's being discussed. You can get the logs here.

Doing the last meeting someone made a comment, and I thought I must blog about it.  Here is the comment:

I particularly ask, because I have sort of inhibition that people might be very busy to entertain my naive queries which I am sure to have

From my experience contributing to Deltacloud, these are my thoughts on this. 

It's totally OK not to know

Seriously, it's ok! When joining a new project, everyone else in the project knows more about it than you do. This is a fact. Everyone knows it. And there is nothing to be ashamed about. On day one on my internship, Marios gave me the most comprehensive intro to the code I was going to work with (and two fat pdfs! :) ). He gave me the intro, even before I asked thing. I choose to highlight this because it means one thing - he knew I didn't know as much as about the Deltacloud API as he did, which is ok! He probably expects "naive" questions from me (And he got many of them!). 

The comment up there got me thinking that a lot of people are not contributing to open source projects cause of that fear - which actually only exists in your head! FOSS devs are usually very willing to help out - it's actually part of the culture! There is no shame is not knowing - but there is shame in not wanting to learn! 

To emphasize my point, if a Ruby Conf was being held in Tanzania (a country that mainly speaks in Swahili) and Marios and I are attendants, I actually expect "naive" questions from  him! E.g, "How do I say hi?". These questions do not mean he is dumb - they mean he wants to learn! He could have chosen to just smile and wave to whoever he is saying hi to, but instead, chose to learn how to say it in Swahili. 

I hope this encourages someone to ask more of those those naive questions - they have a home in open source. ;)

Two months later - Progress?

Yay - yet another blog post! This is great. My internship has got me blogging, almost regularly, something I have been trying to do for years, and failed miserably. I have like 9 blogs out there, with an average of two posts. So, this is great! :)

In case you are new to my blog, I joined the GNOME Outreach Program for Women (#fossopw on Twitter) in January 2013. I have been an intern with Deltacloud project for two months now, which is 2/3 of the internship. This post is a summary of my experience and contribution. I like grouping things up, so I will divide this into three parts: mentorship, code and new ideas.

1) Mentor-ship

My internship is a unique one. Instead of being joining the project and feeling all lost, the program attached me to a mentor, David, an awesome mentor! The internship is remote, and this comes with it's own challenges. I live in Nairobi, Kenya and my mentor is in the US. There is a 13 hr time difference! But, surprisingly, this has been no hindrance. The amazing thing about my mentorship is that I have learnt more than just the project I am working on.

A couple of weeks ago, I bombarded David with "why did you get a PhD" questions on an irc meeting - the conversation was very interesting, and got me learning Common Lisp and reading  this amazing book. I chose to highlight this because I am not onnly being mentored on the project, but also on my skills as a programmer. Which makes so much sense! Now that I am really getting into FLOSS, I need to really master my craft. ;)

2) Code

As mentioned in previous posts, I was to achieve to objectives during my internship - 1) Get the CIMI web app working again, 2) ensure we are not explicitly writing URLs, but the app is getting then from the server. I am still on task 1, and in a bit of a panic mode. Unanticipated difficulties such power outages (Kenya Power, it is the 21st century!) and unreliable internet (Orange Kenya, I will shamelessly point you out - as a warning to others!) are dragging me behind. But I have plan on catching up - I work surprisingly well even in panic mode. ;)

On finishing task 1), I am going to patiently work though my buggy code in 9 branches, so that I have code pushed up - oh the joy of having your code pushed to master! :D . Chasing after your own bugs can get frustrating, and it is even more frustrating when you get other people on board to chase after your bugs (Michal and Marios, I awe you tea ;) ). 

In the interest of helping others understand what I am doing, and not intimidate them with random code, I will not include any code in this post. But is you are a Ruby programmer, get down to the Deltacloud website and have a little fun! :)

3) New Ideas

Ideas ideas ideas! :) A friend of mine hates them because he claims ideas == more work, which is true! ;) My new idea => I need to actively speak at Dev confs. Please note, not attend, but speak! Preparing a talk is a whole different story, because you cannot speak to amazing geniuses when you do not thoroughly have your facts right. (Yes, I said it! Programmers are amazing geniuses, sue me if you wanna :P #GeeksRock).

Focussing... Now back to my new idea - Martha the speaker at developer conferences! This guy has been psyching me up for this (including reviewing topics I am thinking of presenting on, and giving me advise about them, for free! +1 for that you!). The other day(like 2-3 weeks ago), Marina, the one organizing the entire project, joined in psyching me up! (Sent out an email with a list of conferences happening this year that I could start preparing presentations for! Talk of amazing!). I have started submitting proposals and I am loving all the research I am doing in my free time. P.S: it is a great way of relaxing, it is ok not to code 24/7 ;) .

Now here is the little hitch - did I mention that I live in Nairobi, Kenya? The tech scene is pretty you here - you need to see the number of people in my Ruby and MongoDB user groups! If you did not get the hint, developers in Kenya are few, so we do not attract all the dev conferences in the world. Well, any for that matter - though I am actively working on a Ruby conf Nairobi this year! #WooHoo!! :D Focusing.. So the conferences happen to be far, really far! And I am 19, so I do not have accumulated funds to be globe trotting. But this is no big deal - I have found ways of getting around this. For those interested, if you are thinking of speaking at conferences, your level of experience, of availability of travel funds should not kill your psych for speaking! Google around for work-arounds - like serious! ;)

As much as this post has not about code, or the project I am working one, I think it will greatly benefit anyone stating out in open source. As I have come to learn the FOSS community goes beyond code. It is a culture. I hope this post captures some of that culture, that I have grown to adopt.

CIMI client

As I have mentioned in previous posts, I have been working with Deltacloud project. This post is about the code I have been working on. As the title tells, I have been working on CIMI client - getting it working. It's a Sinatra app. There were a few bugs here and there that I have been fixing and adding new stuff.

I started by going though the entire app and noting the issues that I came across, eg broken links and the like. From my notes of issues, I wrote some JIRA tickets which I started working on. The first issue that I dealt with if fixing all broken links. This basically meant creating all the missing pages. This was a great task to start with, as I got me even more familiar with the code. After sending out a few of these patches to the dev mailing list, my code was pushed to master -> Woohoo! :)

The pages that I created were index and show pages for CIMI resources. This was not all that tricky as there were some great helpers already written for the front-end.  My next task was writing code for creating new entities. This was a little challenging, because I came across enough bugs/issues while writing this code. From Ruby bugs to bugs in the methods I was using. As I much as it was great that I found the issues and filed JIRA tickets for them, I felt 'slowed-down' enough. It's easy to feel unproductive after a whole day of chasing after a bug.

With most of the bugs fixed, I sent out the patches for creating some entities, which is great! I am looking into writing sending out the rest of the patches on creating entities, and move to my next task => Change the code so that CIMI client does not explicitly construct URL's but rather  uses the URL's the server sent it. That should be fun! :)

Git, a FOSS programmer's best friend

Since I started working on the Deltacloud project, Git has become my best friend friend. I was using git before on my own work, but I have coming to believe one can only enjoy the full power of Git when working on an open source project.

I had to learn a number of new git commands to work effectively and thought it'll be a great idea to share. The commands I will mention include cloning a repo, getting the latest changes, creating a branch, commiting your changes, creating a patch, sending a patch and applying the patches of other developers. I will share this by going through the process I use. 

$ git clone git://git.apache.org/deltacloud.git

This is the first step one usually takes, I ran this last while working on my small contribution for applying for the internship. I'm pretty sure most people have used this before. Know an open source project you like, then you need to run this command and happy coding!

$ git pull

I run this code to get the latest changes on master before making any changes of my own. I do this often to keep my code up-to-date.

$ git checkout -b working_branch

This command basically create a new branch from master. This is where I will work on the code from. After writing code to a certain point, e.g, fixed a bug, you can commit your changes with the following commands. Please note that code relating to a certain issue should be commited as one commit. This is because they the different commits will create the different patches, and you definitely want relating code in one patch.

$ git add .

This will stage your changes for commit.

$ git commit -m "a commit message that makes sense"

This command, as you might have guessed, commits your changes. Most important thing here is the git message. It should summarize the your changes in a few words, and be very clear. It's important for these reasons: The message will be used as the subject of the patch (If you do not change this) and the other developers need to know that what your commit is all about. As I have come to learn, communication is key in open source projects.

$ git rebase master

Running this command is very critical - I am talking out of experience! This is apply your commits against master ensure ensure there are no conflicts. Next, you create your patches.

$ git format-patch master

This checks your commits against master and creates a patch for each commit. This will create .patch files for you. You probably want to add this to your .gitignore. Now to sending the patches.

$ git send-email -your-patches-

Before running this command, you will need to edit your .git/config file and fill out your details. After sending out the patches, you still have the .patch files hanging around, if you did not store them in a separate directory. What I do after this is run

$ rm -rf -your-patches-

This will simply get rid of the files for you. To apply patches by other developers, you simply run

$ git am name-of-patch.eml

This for a patch in email format. For patches in text format, use git apply.

There is the summary of some of the commands you'll find yourself using. Of course, there is a lot more and this no complete git documentation. I hope it helps someone starting out in open source. I am also pretty new to git, so feel free to leave comments with additions and corrections. :)

Steep Learning Curve

I have spent the last couple of week (Jan 2 - Jan 15) working on the Deltacloud project. I do not remember the last time I learnt so much within two weeks. This is the first open source project I have contributed to full time, and so far, this is what my very steep learning curve looks like.

1. Communication

In the project, we are not seated in one small office, where we can talk to each other across the table; we are oceans apart. However, effective communication still takes place. In fact, I dare say, our communication is more effective than talking across the table!

• Jiras --> We use these to file bug reports. I have not used this system before, so this was step one in learning. Articulating a problem is very important, mainly because another developer will probably fix the bug, or work on the fix with you. 
• Email -->  Keeping everyone in the loop in all communication is very important to avoid repeating the same message several times, as I found myself doing.
• IRC --> The developer's favourite tool. The deltacloud public channel on Freenode has become my favourite hangout. This is because I can get immediate response to any question I have.
• Google+ hangout --> We use for demonstrations and stuff. Mega effective. Just a week ago, one of the devs helped me find a bug through a short hangout. I thought that was really cool.
• Git commit messages --> Yes, those few words in the commit messages have become very important. This is because they need to refer to the Jira ticket they are addressing so as to keep the tickets and mailing list in sync. I am still training in this.

2. Code

Of course, there is a lot of learning when it comes to the code, simply because you did not write the code. After some time studying the code, I discovered  something - code readability is of utmost importance. Writing complex code that needs takes someone time to understand, does not make sense in such a project. The project is open source, so you are not the only one who will play with the code. 

I am still learning, not the technology, but the practice. I do not want to be send patches that will lead to maintenance difficulties. 

Communication and simple code are two things I have been taking for granted, well, at before Jan 2. These two lessons have presented me with a steep learning curve as enter the FOSS community, and I look forward to more adventures in the community.