DPS909 - Joao Rodrigues

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 .

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)? https://github.com/LaCasemate/fab-manager/issues/91  - this was quick work, simply wanted to help out thanks to me knowing Portuguese. I have already submitted a pull request. https://github.com/DestinyItemManager/DIM/issues/2444   - This is an enhancement which requi

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

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.

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 o

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