0.2 Release

As mentioned in my previous release, I was pretty satisfied with the fact that I learned a lot about Open Source. Release 0.1 not only allowed me to learn the kinks of how to setup an environment (which ultimately in a way I also helped to troubleshoot), as well as communicating with real developers in order to fix real world problems. I was not successful at getting my code merged, as we ran out of time and Release 0.2 was right around the corner. The professor agreed that it was a better idea to move on.

This is now the second release. I set a goal for myself of getting code/changes merged. Rather than looking for complicated issues to fix, I wanted to start with something small, and attainable. This time around we had the freedom to look for issues ourselves. I went into GitHub's search section and rather than looking for the biggest and most popular projects, I looked for people who needed help by searching for the tag "help wanted". This lead me to my first issue...


Lab 11 - GH-Pages

In this lab we were tasked with writing a test case for triggering an onLoad event every time a picture is loaded. The code was very simple and I simply did a visual representation of that event by switch the background colours, alongside the text. In this lab, I included a picture of my dog, Snow.

After you click the button...

Another aspect of this lab, and the reason why you can even see these images at all was thanks to Github's GH-pages. These allow you to publish your code without having to create your own domain, which is pretty neat and is something I didn't know. The url to the webpage can be found here.

Lab 10 - Getting Started on 0.2

How will you try to grow during this release? What are your goals (e.g., work on larger bugs, try to do more bugs, learn technology X, ...)I want to land a fix, since for my first release, it didn't get accepted. Although it was a very valuable learning experience, which felt pretty close to a victory, it still wasn't the real thing. I want my code to land and make an impact.
Which projects did you consider? What made you end up choosing one over the others? How did you decide?I looked around for a lot of gaming related projects. Eventually I stumbled into Destiny Item Manager, which is an app I have used in the past while playing the game. 
Which bugs are you going to work on (include links)? - this was quick work, simply wanted to help out thanks to me knowing Portuguese. I have already submitted a pull request.  - This is an enhancement which requires me not only to add new…

Lab 9 - Read me

Adding appropriate documentation for your code is standard practice in any company you work for when dealing with a big, or even small project. Sometimes, code is not immediately apparent to others, and functions that one may think are pretty straight-forward, actually aren't. Setting up an environment can also be something that is very time consuming, having that type of information can cut down the time it'll take for someone to contribute to your project. As such, I added a Readme section to my project, where labs 6/7 and 8 were. I also added comments to my functions so it is clearer to others as to what the function is actually doing. I was aware of the existence of Markdown, thanks to the two terms I have spent as a coop for two different companies, it was fun to see how other students set all of their Readme sections differently. As for the reviewing part of the lab, I did so for this project, where I created a pull request to fix some typos and to add a link to their Li…

Lab 8 Travis

In this lab we were to connect with TravisCI. I had some experience with Travis thanks to my 0.1 release bug, but it was interesting to be able to read more and actually connect to it from scratch. All of the requests made to Travis are done through a .travis.yml file, where you tell it how to configure, build and test the project. I wrote some tests in order to check whether or not the code I wrote in Python on the previous lab was working as intended, in a way that would be automated. My testing framework was pytest. Everything went along very smoothly, and it didn't take too long to see a very happy sight: a green checkmark on my Travis build.

Lab 6/7 Github Stuff

The tasks for this lab allowed me to get a little more familiar with Github. We were to design a library, and to do so we first had to create 4 functions. They had to show the filename without the path, show the file size in bytes, and finally the last two had to show the sha1 and MD5 digest for a file's path. In terms of languages used, I chose Python since it is one of the languages I chose to focus more on this term. License wise, I picked BSD3. I created a repo and published all of my code on to the master branch. As for the last part of this lab, I contributed towards someone's lab, by using an example with some code that I saw online. I have yet to receive an answer on whether this piece of code helped or not, but hopefully it leads them in the right direction, if it doesn't solve the issue altogether. Contributing to someone else's code is something that we got some first hand experience with thanks to our release 0.1 assignment, but this was good reinforcement …

Assignment 1 - Fixing a real bug

This is a continuation from my previous post on getting a thimble testing environment to run. To keep you up to speed, my goal was to fix this issue right here:

As you can see, if one doesn't publish a project, the description isn't saved to the server. The text is persisted if you stay within the project editor page, which could fool a user into thinking the text is actually being captured, only to be surprised if they leave it. If everything within this page is saved without publishing, why isn't the description doing it as well? Well, my task was to fix that.

The actual problem narrowed down to how an ajax request is made in order to save the data to the server. Every time a user "published" a project, all of the data would be saved, the description included. "Unpublishing" a project would do the same, all of the data within the page would be saved. When not publishing, the page saved only certain elements, such as the Project name (upper left corner…