New semester. New projects. More open source

So I have got thought Open Source Development I course in Seneca College successfully.

Now I am one of not many brave people who are taking Open Source Development II. 

This course is a bit more different in terms of work load. In previous semester I have completed 2 releases (in other words: my professor marked 2 sets of issues I have attempted to fix on GitHub). And this semester I have bi-weekly releases, which means 7 releases. 

I am not excited to be overwhelmed during my last semester in school and I am not a fan of spoiling my transcript, so I need a plan.

First of all, as our professor has advised, the best way is to stick to one project. Originally I wanted to work in Golang on Golang☺. 

But after several attempts to sell it to my classmates, I was sold on contributing to VS Code. This open source editor is quite popular these days. I even wrote an article about using it and some other IDEs a while ago. A lot of people with whom I work/study are using it daily. This is a perfect opportunity to become involved in a large project that affects me and people I know directly.

So I decided to contribute as both developer and translator. I remember the struggle I had with English version of Visual Studio, when I was about 12-13 years old and was confused not only but English, but also by programming in general. So I hope other kids/people in Ukraine and Russia will have more comfort and I want to help! So while I was installing dependencies for vscode project, I found an instruction on how I can contribute to translations.

I even had a chance to translate and rate a few dozens of lines and strings while waiting for all the dependencies to load.
Setting up vs code at my personal computer was a piece of cake, I followed instructions in the vscode Github repository and everything just worked!

My professor suggested not to stress ourselves out and pick some small "good-first-bug" just to get involved. So that was exactly what I did. I picked this "please remove" bug. It was quite an easy fix: Ctrl+F, Delete. I have submitted pull request and to my surprise one of the tests was failing!

  3827 passing (30s)

  1 failing




  1) FileService "before each" hook for "moveFile - MIX CASE":

     Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.



The command "if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then ./scripts/test.sh --coverage --reporter dot; else ./scripts/test.sh --reporter dot; fi" exited with 1.

I was confused... That error was not even related to my fix, so I asked for help.

It was on Saturday, so I didn't expect to get the response until Monday. And the first thing I saw in the morning on Monday was an email from GitHub. My PR got merged and it will be shipped with Visual Studio Code for their January 2018 release! I was happy about how not painful this time my experience was. And that was the test that had some issues.

So my first release is done in this semester!

My Christmas / New Year Journey: Fixing bugs. Part 2

Happy New 2018 Year!

First part of the blog is available here.

So I have been looking for some new bug for the last few days. I have found a few interesting once, contacted different project maintainers, but they didn't respond. Probably because of the holidays.

And finally I found something interesting: rmw project.
As it states on GitHub page: "rmw is an OS portable cli trash can utility written in C. It can send files to your "Desktop" trash, or a completely separate folder. It can also: restore files; permanently delete files that were rmw'ed more than xx number of days ago; skip files or directories that have a "PROTECT" directive in the configuration file; and append a unique string to the filenames so they won't be overwritten (duplication protection)."

I was always curious how the different projects are available in multiple languages, I thought it required a lot of copy-pasted text and if statements... But during my experience I found out that one of the ways is to use gettext tool. So I decided to contribute and translate the output messages to Russian and Ukrainian.

It was definitely an interesting experience and welcoming community!

I can now tell that I finally feel comfortable with contributing, creating pull requests and starting to work on the new projects!

During last 4 months I tried to gain confidence as an open source contributor and programmer.

My goal was to learn more "how big programmers code", best practices and explore some technologies, I have never heard/tried before.

I can say with confidence that I have done at all of that.

And since it's impossible to know and try everything in IT field, I will still continue my journey in Open Source, in exploring new technologies and programming languages by myself.

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!