Wednesday, December 4, 2019

Release 0.4 - OpenClimateFix and the Github API

And so it ends...

As my course winds to a close and I finish up my assignments, I have reflected on everything I've accomplished in the last three months. I'm proud of what I've done. I've made 6 pull requests in public repos, 4 of which were merged, 1 of which is dead, and 1 is yet to be merged. I've looked at hundreds of issues in dozens of languages, learned so many things it's taken me 15 or 16 blog posts to contain them all. I am most proud of my work in this pull request, although on the surface it looks rather simple.

The Issue

The issue is built upon my previous pull request for Release 0.3, which is why I thought it would be perfect for 0.4. It is a new page on the website that includes the Contributor Showcase component I built for Release 0.3, as well as a paragraph on how to get involved, a couple of links, and a link to a github search for issues. It also includes a list of the repositories owned by OpenClimateFix. Another part of this issue is to attempt to add the Github API to the Get Involved page, to load the issues instead of clicking on the link. This is what I spent approximately 20-30 hours researching, learning, and testing before I found that I could not do it in this pull request. I figure what better way to use that knowledge than to impart it on the readers of this blog.

Why I couldn't use Github API

In order to use Github API, you can do 3 things:
  1. You can use a personal access token, which provides access to the Github API through your Github account. 
  2. You can set up a Github App, which means setting up a server to host a Github App to fetch data from the API.
  3. You can authenticate using a OAuth app in a similar manner.
What you can't do is use a personal access token on a public website. Everywhere I researched said explicitly that the point of the access token is for testing and maintaining your own repositories, and it is meant to be temporary as it only lasts for a year. It also can be used instead of a github password, which would give others access to my account and private repositories. The other 2 options would have to be done by OpenClimateFix, and would be a project on their own to get set up. The simplest solution is to just make a good Github search query link, and provide links to some of the repositories staticly.

Setting up the environment

Luckily, I have done a few PR's for OCF now, so I have the environment set up. I looked at many new packages and libraries to use the Github API, but in the end I had nothing to add. For your sake (the readers of this blog), I will include what I needed to get the Github API running. If I was making my own app, I would probably fetch the data differently, and not use Gatsby, but this is what I got working with the personal access token:
Then all I had to do was add the Github API query to my code, similarly to how I used a query in Release 0.3. The following code shows the query: 

query MyQuery {
  github {
    repository(name: "repository-name", owner: "owner") {
      id
      description
      issues(labels: "good first issue", states: OPEN, first: 10) {
        edges {
          node {
            id
            title
            url
          }
        }
      }
    }
  }
}

When I realized that personal access token was not going to be an option, I had to go with the backup plan.

The Solution (Pull Request)

The backup plan was to include a link using a Github search url to define open, good first issues available from all openclimatefix repositories. Here are the steps I went through to create the new page.
  1. Create a file named get-involved.jsx under the pages folder. This automatically creates a page in Gatsby, and routes it to the root uri followed by the filename. If the file was in a folder, it would default to `root/folder/jsx-file`. Classes are also added to the routes, so if I wanted to put all of my classes into one file I could, and have several routes. 
  2. Write the code to create and return the Gatsby html template.
  3. Add the existing code from the Get Involved section on the website. This includes the Contributor Showcase component I created for Release 0.3, as well as some links, and I added the new link for good first issues. I also left OCF some room to write their own message on the page.
  4. Format everything to fit prettier and eslint standards. The repository does not run eslint tests on compilation or on commit, but only in the pull request itself. Therefor, any errors are difficult to catch until you have made a pull request. It took several tries to fix the lint errors.
  5. Wait for a Review. I am currently in this stage, and will post an update if I hear anything back from OCF.
The Final Product

Overall it was a fairly simple solution that I spent so many hours researching for. I'm glad that through this blog post, my research and experience might help someone else get the Github API going in Gatsby. I found no guide suggesting where to go and what to do explicitly, so let this be a sort of guide. 

My Final Thoughts

As this course ends, I find myself disappointed and proud of myself. I am disappointed that I did not end up working on an issue for a larger company, like Microsoft, Google, or Amazon. I imagined my code up on some Google application, or as an addition to the newest stable build of Visual Studio Code. I would have liked to see a bug fix of mine in GIMP. But I ended up working on some amazing small projects, and that is what I am most proud of in this course. I found so many awesome projects, some of which I couldn't really help with and others I got heavily involved in. I am glad that I kept this blog (even though it is mandatory) because I know that I'll continue it, and maybe even take it with me to my next professional option course (on android app development). This will be my last blog post till after Christmas, so Happy Holidays to anyone reading!

Release 0.4 - Telescope's Documentation Problem

Why Documentation is Important

I have been working all weekend to digest the entirety of the Telescope repository for my course. I have been mentioning it for weeks now, but I'd like to go into detail now that I know more about it. Telescope essentially grabs blog posts from a feed centralized on a Seneca College website, and displays them on a front end app. This project has been moving very quickly, it only started a month ago and we are days away from a working prototype. But as quickly as it has been moving, the documentation has not been maintained at all, something I foresaw weeks ago when I made the CONTRIBUTING.md file for the project. I intended as developers added their code they would update the documentation, but they have not. 

When setting up the environment this weekend, I had great difficulty in understanding how and why things needed to be done. This is the point of documentation, to assist people in downloading and running the environment required to start development quickly. I am devoting my time on Telescope to solving these documentation issues, not just for the current developers but future developers as well. Now to the issue.

The Issue

Basically what needed to be done was to add documentation on docker, which has become a major component of the project, and how to set the .env variables. I have to talk to several people over the next few days in order to get this information, a process I have already started. Most of the information is readily available through the commit history of the env.example file. 

Background Information and Documentation

The following paragraphs detail what I learned in finding every avenue to install docker, and get the system running in different environments:

Virtualization

I had to learn how to properly set up a virtual machine. Mainly this was to get telescope running on a system that I could use. The main issue was that docker is not readily available on Windows Home Edition. At least so I thought at first. To even run docker, you need to have a virtualization capable system, and in some cases have to enable it in the BIOS. I decided to leave this out of my documentation as it is out of the scope of the project, and there are many guides online that can help you with this process. I even linked to a few guides and youtube videos in the documentation for assistance with certain steps.

Docker

I had to learn how Docker installation works, it's requirements, and what systems it can run on. This included finding alternatives for people who did not have access to the easier methods. For example, getting Docker for macOS is as simple as downloading Docker for Desktop. It will set up docker for you and comes with docker-compose pre-installed. On the other hand, Windows 10 Pro, Education, or Enterprise are required for Docker for Desktop to work. You need to either set up a virtual machine with Ubuntu Linux, get Windows Education Edition (an option freely available from Seneca), or get Docker Toolbox, which is an older version of Docker Desktop with less features.

On top of that, I had to learn how Docker works. It didn't occur to me that Docker essentially builds a miniature virtual machine to run build instructions in a consistent environment across devices, similar to my understanding of Java and it's environment. The difference is that Docker is fully customizable, and can use Docker images to use software that you would normally have to install natively, in our case this is Redis.

Docker-Compose

Docker-compose allows you to run docker applications by starting all services with one command. It is a separate install from docker on Linux distributions, and comes with Docker for Desktop on Windows and macOS. It is vital to the project as docker-compose is required to get the docker image of Redis running as a service on the right port. 

Chocolatey

Chocolatey is a package manager that was recommended to me by my professor as an easy way to download Redis natively. Part of my job was to investigate not using docker, and I found that although you can run the website locally without any major issues, it takes a lot of configuration and extra work rather than using docker. My recommendation was to entirely remove the native set up instructions and stick to docker.

The Review Process (Pull Request)

The review process took a lot longer than I initially anticipated. It took approximately 4 days to go from pull request to merge, and there were a lot of changes along the way. I came into the process with a limited understanding of exactly how everything fit together, and I have walked out knowing exactly how it all works. I was reviewed by Manekenpix and Silvyre, who are both extremely active in the project and have done many pull requests. Some of the concerns raise were as follows:
  • Code Syntax
  • Wording Problems
  • Grammar
  • Usage of sudo (when and why)
In total, between the three of us we made 35 comments, each of which added to the discussion of how much to include, and what should be excluded. This shows it's importance, as even extremely active community members take an interest in proper documentation.

I learned many things during the review process, including:
  • Docker Toolbox (Thanks to grommers00 on Github)
  • Docker for Desktop on Windows Education Edition (Thanks to MeisterRed on Github)
  • The proper usage of sudo
  • How to properly set up docker on Linux (with post install commands)

Overall Feelings on the Project

I feel like I made a good contribution to the project. Although I didn't contribute to the code itself, I can take solace knowing that future developers that work on the project in it's next iteration will be able to adapt and understand the code faster than I could. I have already had some people thank me for my contribution, saying it helped them get their environment set up better than they had it. I have enjoyed my time in this course, and this was a nice cherry on top. But there is still one more blog post to do after this one, and it contains my proudest moment in this course.