My Christmas Journey: Fixing bugs. Part 1

Merry Christmas and Happy New Year!

A bit later after my holidays, I remembered that I need to finish my assignment for Open Source Development. I have planned how I was going to work on it in this blog post. I planed to work on it for 1 month instead of 9 days, but due to personal reasons, I couldn't do that. So here I am: 7 days before the deadline(It's not 7 hours, so I think it's quite doable).

As I expected the bug I planned to work on about a month ago has been already silently fixed, so I didn't even get any email notifications about activity on the issue I have been following on the GitHub. That happened a few days ago and of course I got stressed out. So I have asked my friend, Ray Gervais (link to his blog), to recommend me some interesting developing project and he did.

He was contributing to a CSS Framework based on Flexbox called Bulma. Even though originally I was planning to concentrate more on Node.js, JavaScript and React, I thought it might been a good idea to see how CSS Frameworks work from the inside.

So I picked up a new bug. This experience started with "Oh my God, this is amazing!" comment. When you start contributing to a new project you need to set up an environment, download all the technologies you may not have on your computer... Well, apart from forking the repository and cloning it locally, I spent 5 minutes on setup: npm install and npm start (to run the project). It would be a bit longer if you don't have node.js on your machine, but it is still faster than a lot of other large projects.

I have started looking into the code. And at some point I asked myself "what am I trying to do here?". Originally I thought the requester meant to add an ability to write buttons with different sizes, that was already implemented(I wish I read the docs, I just found a piece of code), so I contacted my friend again just to confirm that I am not going crazy and it already exists.

Spoiler: later that day the requester made his idea clearer, but I think that should be reviewed by somebody who maintenance the project first.

Still it was a nice experience getting familiar with a new code, but I didn't find my bug yet...
Next part of the blog is available here.

Goals for the next month

It's about month before the due date for the next project for my Open Source course.
So it's time to set some goals and determine how I am going to grow as an open source contributor.

My goals are:

• Fix more bugs
• Try to settle on one project
• Explore Node.js, JavaScript and/or React 

It's quite tricky to work on the assignment at the end of the semester with no plan. And Christmas is coming! I definitely need a plan how to spend more time with my family and friends, but also do my best for this project.

My plan:

• Spend 3 hours on fixing bugs every week from Dec 12 till Jan 5
• Learn Node.js, JavaScript and React if needed (depends on my knowledge and bugs I find)
• Fix at least 2 bugs

So far I have found only one bug, but I hope to get involved in this project and continue working on it.

Proper documentation is a key to success

This week in my Open Source Development class we were discussing a topic of Documentation.

When (almost) every programmer hears a word "documentation", first thought is pain.

When you start documenting a production-ready project, you know that the next days/weeks are going to be a hell.

It would be nice to start documenting stuff from the beginning, but you didn't... You were too excited with coding and solving more significant(as you think) issues.

I have been there. If you are working on your own the only documentation you might have are comments to explain some hard-to-follow places in your code and maybe that's fine for now. But what if you come back to this project in a few weeks or even months. You will not remember which component does what.

I have a small rule I follow while working on every new project. I try to put meaningful comments, so later on you can reuse a code without spending a long time figuring out what that function does.

I also like to start working on README file as soon as I set up development environment. It's much easier to document things you are currently experiencing, maybe paste some links/commands to download all the dependencies or put a note how to solve an issue and how you overcome it.

Proper documentation would be definitely appreciated by your team, your boss, contributors and even yourself.

So if there is a question: do I need a documentation? The answer is always: "YES!!!", even if that's a small project living on your local machine.

Tips and useful links:

• Use this website to get started with Markdown (it stores cookies, if you want to start everything from the scratch again either clean those or access the website in incognito mode)
• Gitlab Markdown cheat sheet