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

Review: Is TravisCI my happy place?

This week I am working on Continuous Integration. The goal is to configure a few tests for my GitHub repository.

Finally, I am confident about my "no-stress-success" in this topic. At least I have seen .yml/.yaml files and I think that I am pretty good in writing pipelines using Concourse CI!

Anyway, my journey into a simpler life with Automatic tests started with creating an account with TravisCI. It was fast and simple process of clicking on "Login with GitHub" button.

I would say that interface is user-friendly and all the features you need can be found within a few seconds.

It's really rare that you got something right from the first time you tried it. So didn't happen to me this time. But even though a few of my builds failed, I enjoyed the experience. It was not stressful at all!

I would definitely recommend to use Travis CI for your projects. Spending about an hour to set up everything(including account creation and writing .travis.yml file) to test your code every time you or other contributors commit totally worth it! One hour worth work will save you much more time and brain storming in future!

So let's take a closer look at my .travis.yml file and see what's going on there.

1. language: go

2.

3. go:

4. - master

In the first 4 lines I have configured Golang environment and the version I specified is master. Master is the latest version available.

6. notifications:

7. email: false

On the next few lines I have disabled email notifications. I don't know if they are enabled by default, but I can easily get annoyed by enormous amount of new "junk" emails. So to make sure I am still on the happy side of this experience I included some extra lines there. 

Edit: "The default settings will only email you if the build does not pass. And then you would get one email after it passes, letting you know the build was fixed." (c) Andy Alt 

More good news: there is an option to configure slack notifications! You can find out how to do that in Travis CI docs. I enjoyed their docs! Everything is quite clear and detailed.

8. before_script:

9. - go get -t ./...

10. - go get honnef.co/go/tools/cmd/megacheck

Next step is to install all the packages to build your project and additional testing tools. 

And here goes an actual script and testing process:

11. script:

12. - go test -v ./...

13. - go vet ./...

14. - megacheck ./...

15. - go test -v ./fileInfo

Bonus: a few useful links on for configuring Travis CI for Golang:

• Travis Docs for Golang
• go vet
• megacheck
• Golang testing

To conclude: I will definitely use Travis CI for my school and personal projects. I recommend you to at least try it out. And Travis CI is a happy place, at least for me.

My experience in GitHub

I have already been a contributor to a project (you can read a blog about my journey here) and now it's time to be an owner of open source project!

This week I have started an obtaining file info library written in Golang.

How to create an open source project?

Step #1: decide on your idea

I got my idea from professor, because I did it for my open source class.

Step #2: pick up the programming language
I wanted to do something nice and not stressful and pleasant. I  am quite a fan of Golang, so my choice was obvious. Golang is fast, easy and has a nice set of packages.

Step #3: pick up the license
I decided to go an easy way and use good old MIT license.

Step #4: start coding
Coding was easy and smooth, I got a lot of help from various Golang packages, so it was nice.

Step #5: file some issues
If you want people to contribute, you should file some issues, include some nice explanation, screenshots and some starting-point information(if applicable). You should also create a detailed instructions in README. Nice documentation would for sure attract developers.

My experience with contributors

I have done all the steps from a previous section and just waited. 4 hours later I got pull requests for all my issues from one person. He/She was supposed to be my classmate(that's one of the tasks to contribute to one another's projects), but I did not recognize the name... After going through the list of my group, I did not find his name. According to GitHub profile, the guy is from Germany! It is crazy! I did not expect somebody not from my group to contribute!

Anyway, Danke Marcel Beck!

Small step for developer giant leap for community

Every person who has tried to fix some code he/she didn't write, knows that the real fun begins after the build...

Most of the projects have straight forward documentation that covers the build part. But when it comes to code editing: you are on your own. Now your success depends on how fast you are going to understand the logic of the mysterious lines written by some strangers.

I have noticed that it's much easier to improve/debug/add features to the code written by a single person, because he/she sees the big picture and idea, so it's easier to follow those.

Unfortunately when it comes to work on a project with hundreds or thousands of contributors, understanding the full logic is almost impossible and would take ages to fully know what is going on.

Luckily for me and other open source contributors, every project like that has communication channels. For example, Mozilla Dev Tools team is using Slack. That's the place where one can ask questions and get help. When you talk to people there you need to keep in mind that you are not the only one who is looking for help.
So if you want to get a straight forward answer, you need to ask a clear question.


Developing code is not an easy thing, but working with something written by a large amount of people is even harder. At the same time project may be more successful if more people contribute to it.

And as my open source journey continues, I hope, I will be one of the many who are working on something important, who are defining the future of the technology.

And the next stop is fixing code. My bug wasn't really a hard one, but it took some time to understand the logic of the flow. Fortunately, Jason Laster was there to answer my questions or to refer to the right person.

And now I am trying to pass tests and push the code to my GitHub forked repository. The first time I run tests I got the following output:

                                                                                                                                               

Snapshot Summary

 › 11 snapshot tests failed in 1 test suite. Inspect your code changes or run with `yarn test -- -u` to update them.

Test Suites: 2 failed, 59 passed, 61 total
Tests:       12 failed, 332 passed, 344 total
Snapshots:   11 failed, 101 passed, 112 total
Time:        96.983s, estimated 100s
Ran all test suites.

error Command failed with exit code 1.

info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
                                                                                                                                               

It amazes me how something small like changing a color of an icon can cause problems!
After asking how to get started with fixing failed test, I was told that there was an issue with line endings, so after git pull: -1 failed test suit and -1 failed test!

Jason advised me to ignore the failed tests, so git push!!! I have never though that such a simple git command can bring so much satisfaction!

I am almost there, my next step is to create pull request.

My code did not fail any of the PR checks! That feeling is amazing!
Do you know what feels even better? When real developers approve your code and give you some pleasant comments!

The least stressful built ever

Deciding where to start my open-source developer path was maybe the hardest part of my contribution so far (I hope) 

The next step is to set up environment and run the project locally. 

Without any positive attitude or expectations I went to the link which gave me some instructions how to set all the required dependencies and start debugger.

I got Yarn, Node.js and the project itself:

git clone git@github.com:devtools-html/debugger.html.git  

So far so good!

Next step was to install all the dependencies with even more magical command: yarn install. Nothing stressful and with no pain I have successfully started the project on port 8000 with yarn start.

And that was it! 

Tip for the future: Have more courage and Murphy's law doesn't always work.