OSD600 0.4 Reflection

For this post, I am going to reflect on the pull requests that I made for Release 0.4. Now, while I do not need to make this reflection, I am going to do it just because I want to talk about what I did for trying to create tests for app that run through React, and the huge amounts of trouble that I went through just to create such simple pull requests. You can view each of my blog posts on create the tests here:

Post 1

Post 2

Post 3

Now, when trying to create these test, I had no idea what I was getting into. For the most part, I am not great at creating checks for errors within code. I usually just read through the code and try to determine what the problem being cause is based on the error messages and solve the problem myself. However, for this, I have had very little experience with React apps and creating tests for those apps, which is why I wanted to take on these pull requests, since I would have a reason to learn about testing for error, and it would help me get over my Achilles’ heel of testing. I never expected how difficult it would be to make even the simplest of tests.

I spent the most time on the Curated-tv-and-film pull request, as it was the one I started with, and was the one that I wanted to figure out how to work on the most. I skimmed through the code, and after noticing how the toggleFilter event just changes a single state from false to true and shows the filter bar, I figured that would be the easiest place to start. It seemed simple in concept, just retrieve the state of the showFilters value, run a event once, and check the showFilters value again to see if it had changed. The real problem was trying to find information on how to check for changes to state. I went straight to the official document for testing React apps, but there was nothing that I could use there. I then went on to the document on Test Utilities for React, but I still couldn’t find anything on testing for state there. After jumping from post to random post, I finally stumbled onto a post that explicitly has the title that it was testing for state, but that was after several hours of testing what seems like it would work, and trying everything that I could possibly find. The post it located here, and it was just a random post that was not connected to the official documents at all.

Searching for the a way to run an event was even more difficult. I could not figure out for the life of me how to to emulate running an event. The biggest issue was that the events were not declared as a method within the app, but instead were a lambda that was given an event. So, instead of toggleFilter(), it was instead toggleFilter = () = > {}. Since ever test that I could find online was for a method instead of a lambda, I could not find a single thing to help me figure out what to do to run the lambda. I eventually had to ask the owner how I should go around doing it, and the owner quickly informed me of what I to run, which was wrapper().instance().method(). The worst part was when I pulled the current version of the repository, my simple test that barely had anything within it stopped working, and I was suddenly back at square one after all that work.

After this. I kept searching to see whether I could figure out what the new issue that arouse was, to no avail. After so much time spent trying to figure out errors and getting the tests working, I just gave up, and made a request to check to see whether the HTML div was being rendered correctly. While simple, it still is an important part of the app to check, because if it fails that app will not show anything at all, but it was not even close to as much as I would have liked to do. I really wish there was more documentation on creating tests for React, especially for problems that will occur when attempting to create a test, since there was not much information to go on that I could use to determine how to solve my problem.

The lack of information became the biggest problem when working on the Creative-Collab repository. I couldn’t even get shallow rendering working with the app, and had absolutely no idea why. When it turned out that the problem was because of the React-Quill component that I could not do anything about, that was one of the worst times of my life, since I spent so much time trying to find the solution to the problem and it turns out that I could not do anything about it. Not mentioning that I planned to create tests for the repository was my fault, as another student went on and created tests for the components, but they were not part of the tests that I was planning to create, so it was more or less fine. The biggest problem was that I had spent so much time trying to figure out how to shallow render, that I have very little time left to work on create normal tests for the repository. Since I had no way of solving the shallow rendering problem, I could not even attempt to create tests the same way that did for the previous repository, and since I could not use mount I was couldn’t even mount the repository correctly. This forced me to simply use the same tests that I used for the Curated-tv-and-film, which bothered me quite a bit since it was not nearly as complex as I would have liked.

The only part of this release that was not that bad was updating tests for the python exercises. The problem with running the exercises was troublesome, but quickly resolved after asking the owner of the repository about it. Once that problem was solved, updating the test was simple. All I needed to do was look at the previous code and see what had changed, and make the changes necessary to accommodate those changes.

This release was very dissatisfying for me. After all that work, several hours of searching online for the solution to the errors that I was running into, all I could do was create simple tests and push those to the repository, since those were all I could get working. I hope that either documentation on testing React apps will grow in the future, or I get better at searching for issue solutions on Google.

OSD600 0.4 Pull Requests Post 3

For this release, I plan on creating tests for the Curated-tv-and-film repository. I plan on dealing with issue #20, which simply asks for implementing new tests for each component. This is the next step of from my previous blog post on testing, and there is more information on what I am planning on doing there.

To start off, I looked into the tests that exist already within the repository and tried to determine what possible tests that I could add. Looking at each component’s tests, they are currently made up of a test that checks whether the app can still render, and a test that checks whether the code has the same design as a snapshot. Looking at some websites that have tutorials on making tests for React Apps, I am trying to test the methods that exist already within the app, but need to figure out how to test to see the value of what each method changes.

To start off with, I began with a simple test to see whether the toggleFilter method was doing its job and changing the showFilters state from false to true when it is triggered. It seemed like the ideal place to start, since it would be the start of many other method test, and would be a basic outline of any test to come after it. What I was not expecting was how difficult it would be to try to figure out how to create a test. I began by searching online for a good reference to use when attempting to implement a test for the method. I found information on the matter, but very little of it resembled the code within the app that I was planning on working on. There was a blog that I managed to dig up on the matter here, and it gave enough information for me to begin work on testing the state, but the time needed just to find that one page was impossibly long. I nearly spent 2 days just because I could not find any information on how to test the state anywhere within the official jest testing documents. I was hoping to find it within the official page for testing react apps with jest, but could not find a single thing on how to test for a change in state. The only thing I could find was a test for text, and I had absolutely no use for something like that for the tests that I was planning. All I could do was keep searching until I found something that actually did testing for an app similar to what the current app looked like.

So, after all that searching, I finally have a reference point to use in terms of testing for state. The current code looked like this:

it('testing for changed toggle state', () => {
  
  const wrapper = mount();
  
  expect(wrapper.state().showFilters).toEqual(false);
});

It was simple, easy to understand, and the most important part, ACTUALLY WORKED. It was very difficult just trying to figure out what to use to receive the app’s state, as just trying to get the state was an ordeal in of itself. I tried to use wrapper.state.showFilters, expecting it to return the state, but kept giving the value undefined whenever attempting to run it. I then went on to testing for props to see whether I happened to be testing for the wrong thing, but that didn’t get me anywhere either. I found an example of a tic-tac-toe app that created tests for buttons, but since the component was not a button and instead the value was the state within, that information did little to help me as well. I then began to look into the shallow wrapper API to determine whether there is a specific method to retrieve the state, but all I could figure out was how to find a component, and while there was a method on how to find the state, I could not figure out in any way how to get it working, as it states that as an argument you need to pass the key into the method, but whenever I attempted to do that I would always get undefined as the value.

Now that I managed to get the state, I went on to figuring out run the event that changes the state from false to true. Trying to figure this out was even worse then trying to figure out how to retrieve the state of the app itself. I searched the web some more, and found several pages on testing, such as one that talks about the react testing library, information on the react test utilities, and a very detailed document on how to test for components within the app, but still nothing on how to tests events, The most I could find was the simulate() method, that could be used with buttons to simulate them being clicked on, but I could not figure out for the life of me how to use them with the events called within the app, as the events were not called simply just by a button click, since they were using dropdown lists, and I couldn’t find any information on how to use simulate with a dropdown. I finally gave up and asked the owner of the repository whether they know how to run the events.

The owner informed that I would need to run the instance() method along with the method that I wanted to run, and it would look like the following: wrapper.instance().method();. After all this time, I finally got something to work with. I modified my code to run the toggleFilter event and my code look like this:

it('testing for changed toggle state', () => {
  
  const wrapper = mount();
  
  expect(wrapper.state().showFilters).toEqual(false);
  
  wrapper.instance().toggleFilter();

  expect(wrapper.state().showFilters).toEqual(true);
}); 

I ran the code, and I finally got it working! After all this time, I was finally getting somewhere! After the test checked to see whether the toggle worked correctly, I decided to update my repository to the current version from the original, as just trying to do this has taken so much time that my version has fallen quite far behind. So, I ran the command git fetch upstream and git pull upstream master, and tried to re-run the tests to see whether they will work with the new changes.

And…nope. The simple test that I had implemented into the repository just to check to see whether the state was being changed when an event was called was no longer working. Suddenly, I was receiving the error: TypeError: Cannot read property 'showFilters' of null and my test was failing to run. This is especially infuriating since the test was so simple that I was not expecting a single thing to go wrong. I informed the owner of the repository of the error and began looking into what could be causing the error.

For now, I used one of the pages of information that I found on React testing and used it to start with a test that checks for whether the app is rendering a div properly. It looked like the following:

it('always renders a div', () => {
  const wrapper = mount();
  const divs = wrapper.find('div');
  expect(divs.length).toBeGreaterThan(0);
});

I was not able to figure out how to deal with the problem with checking for state. It is most likely a change into how the app checks for its state, and the changes that the owner of the repository made probably made it so that the state cannot be retrieved in a normal way, but I have no real way of knowing what would have that effect, other then carefully analyzing every change that the owner has made since my previous version, which would take too much time for me to do. I will have to go with just the test for a div and leave it at that, in pull request #208.

Now, I will be looking into creating tests for the Creative-Collab repository. I will also be creating tests for this repository, helping with issue #22. I was still not able to figure out how to solve the problem with running the tests without shallow rendering, but another student wanted to assist in creating tests for the repository, and so I asked him to help look into the problem with rendering. He said that it is most likely a problem with using the React-Quill component, and the only way to deal with the problem is to remove that component. Unfortunately, because that component is crucial for use within the app, removing it is not an option, and so I could now do anything about using shallow rendering. I attempted to use mount instead of shallow, but when attempting to test using that, I received the error ReferenceError: MutationObserver is not defined and the tests failed. I used the code that I had for testing the other repository and used it for testing within this repository.

it('always renders a div', () => {
  const wrapper = mount();
  const divs = wrapper.find('div');
  expect(divs.length).toBeGreaterThan(0);
});

While I was working on determining possible tests for the Creative-Collab repository, another student came and created tests for both the StoryBoard and Board component, before I could manage to. I forgot to make a mention on the issue that I planned on working on creating tests! I have already spent so much time just trying to determine how to create tests for the Curated-tv-and-film repository, that I did not have anymore time to start working on any more complicated tests for the Creative-Collab repository. So, I just decided to commit the test for divs into the repository and finish it up, with pull request #37.

I’m a bit bummed on these pull requests. I kept trying to create tests for these repository, but problems keep popping up, whether I can’t run a function that I should be able to do, or the tests don’t come out the way that I would like it to. I will be going into it in my reflection post, as I have a lot I would like to talk about in terms of creating tests. For now, I’ll just say that you should really try to understand how the app works before going into how to test how it works.

OSD600 Release 0.4 Post 2

For this pull request, I will attempt to add tests into the repository exercism, and update tests for several of the exercises that exist already. Now, since there are already several tests that exist already, and the changes that I plan on making are just updating tests that exist, I plan on doing multiple issues at once to make up for that simplicity of each individual issue.

Now, the issues that I currently plan on dealing with are #1623 and #1621

So first, I forked the repository and cloned the fork onto my PC. I seemed that I would need to use python for this repository, so I checked my python installation that I have previously installed using python -V, and I had installed python version 3.7.1, so I went on to testing to see whether I can run the tests. I then received the error FileNotFoundError: [WinError 2] The system cannot find the file specified and my progress was again at a standstill. I informed the owner on issue #1624 to ask about the issue, and he informed me that the python testing file was written with Unix systems in mind, and that on Windows there needed to be some changes to some of the code that runs the scripts in order to get it running. He then created an issue for the changes to make the repository cross-platform and made the changes necessary to have it work on a Windows system. I then pulled the repository into my forked one, and again tested it to see it the changes would work. The tests worked fine, and so I began work on the tests.

So, looking through the tests, it is not entirely clear what is necessary to update the tests up to the current version. For each issue the contributor states that a certain test suite is out of date, and needs to update to the latest canonical data. For some tests, it clear that it is missing a test or two that the data shows, but for others the differences are not so obvious. I decided to start with the more obvious tests, and to ask the owner of the issues about the less obvious changes. After looking through each test, I decided to start by updating the tests for binary-search. I looked at the changes between the data and tests, as well as used the previous commit to the test file as a reference to determine what the last version had in comparison, the only difference was that it was missing a test at the end. Using the previous tests as a outline, I created the test:

def test_bounds_cross(self):
        with self.assertRaisesWithMessage(ValueError):
            binary_search([1, 2], 0)

I committed and pushed the previous test to the original repository for review, created pull request #1631, and went on to work on the next test. Next, I decided to work on the tests for the hamming file. The data for this file had several redundant data removed from the file, and so I simply removed the tests that checked for the previous data and pushed those changes to the original repository, and created the pull request for the changes, pull request #1632.

Since I was spending so much time with creating tests for my other repositories, I decided that I would not spent too much time on this external pull request. Even then, I still had a bit of trouble just trying to run this repository, since it was not Window capable. I am glad that I help the owner of the repository know that his tests were not Windows compatible, and helped him figure out how to make his repository Windows compatible.

OSD600 0.4 Release Preparation

For this release, I will be creating pull request for 2 external repositories and 1 Seneca repository. For those who are unsure at what this blog post is about, you can refer to my previous blog post release, 0.3. In short, I will be creating some pull requests on Github to fix issues, implement features, create documents, or any other changes that need to be made to a repository. I am currently planning to expand on tests created for the Creative-Collab repository, and also implementing tests for the the repository Curated-tv-and-film, both repositories that I previously worked on. Since I will be creating tests for both of them, It should be easier for me to manage to figure out how tests work for each one, and using a similar syntax, it should be rather simple to figure out what to do. Now, while I made a test for Creative-Collab before, it was a very simple one that simply tests if the app will run, and i did not manage to work without shallow rendering, and I would like to figure out how to fix the problem of working without shallow rendering.

Now, I will first be trying to determine how to implement tests without shallow rendering for the Creative-Collab repository. I have been running into a strange problem recently when attempting to run tests. Whenever I try to run a test, it does not seem to find the test until I add an extra new line to the end of the tests. I am not entirely sure why this occurs, and the same problem occurs when I attempt to run other tests, but it seems to be solved just by adding in a new line to the tests doc, so I’ll look into it later. My current issue is trying to determine why my test files will not accept the Creative-Collab App as a DOM element. The test that I am currently running is this:

it('renders without crashing', () => {
  ReactDOM.render(, document.getElementById('root'));
});

The error that I am receiving is: Invariant Violation: Target container is not a DOM element.. This is a problem, as it forces me to use shallow render until I determine what the issue is, and I won’t be able to start implementing new tests until I figure out why it is not being accepted. It is especially strange, as in the index.js file that runs the app uses the exact same code, and runs without issue. So I looked into the boardgame.io testing, with our code is based on. Looking into boardgame.io’s testing, they use the instead of Creative-Collab, and after looking into the app.js file this makes sense as it is the one that calls the client. So I attempted to modify the code using App instead, but it still game me the same error. so I attempted to run the boardgame.io app tester to see if it works, since it has the syntax I want to use for testing. The boardgame.io app tests worked fine, so it is most likely a problem with the Creative-Collab test dependencies. After looking into where the render pulls from, it seems that the boardgame.io app pulls from a Typescript download of react-dom on my computer, while Creative-Collab pulls from a file within its own repository. I uninstalled and reinstalled the react-dom on the Creative collab with npm install --dev react-dom and it is now showing that it is reading the correct render function, but I still receive the same error.

Unfortunately, after some continuous checking and over 8 hours of trying everything I can, I still have not been able to figure out how to solve this issue. I looked up the issue online, and every instance of this issue occurring has different solutions, and even after trying ever solution that I could find, I still couldn’t figure out how to solve the issue. I have a feeling that it is a problem with how the Creative-Collab reads the app, since the boardgame.io app runs fine, and it is very similar to the Creative-Collab app, making it incredibly difficult to determine the problem, since I can’t seem to find any difference with how the tests are called. I will have to move on to creating tests with shallow rendering for now, since I have spent way too much time trying to solve this problem.

OSD600 0.3 Release

For this post, I will be discussing two pull requests that I worked on. First, I am going to discuss the pull request that I made for the Seneca repository that I am working on.

I am going to work on implementing tests for the repository, as I have very little experience with creating tests for code. I am working on the Creative-Collab game app, which allows multiple people to play a game where each side will take turns to create a story. So I cloned the repository into my directory and went into the test directory to start working on the app. There were currently not any tests to work on, so I informed the current owner of the repository on the issue that I will be working on creating tests, which was issue #22.

I first looked into creating react-app tests using the documentation online, and took a line from the index.js file to use as the test, which looks like this:

it('renders without crashing', () => {
    ReactDOM.render(, document.getElementById('root'));
  });

However, when attempting to test this, I recieved the error that the target container is not a DOM element, and the test failed. I made a comment in the issue thread, and they told me to try to do it using a shallow rendering. So I changed the code to do the following:

configure({ adapter: new Adapter() });

it('renders without crashing', () => {
  shallow();
});

So I created a commit and pushed the new changes back to the original directory, pull request #32. The checks failed, so I added the package.json file and package-lock.json file to the commit and push that as well, as I needed to run the npm install --save enzyme enzyme-adapter-react-16 react-test-renderer to add the packages, and the new pull request was accepted into the repository.

For my second pull request, I found a repository that has a list of iconic movies and films, and I decided that I wanted to alphabetize that list so that it would be easier to navigate. The repository, curated-tv-and-film, was a rather simple one, so I informed the owner in a issue asking for better styling, issue #57, and then forked and cloned the repository. After looking through the code, I saw that the data was hard coded into the files, and that I would be able to sort the files using the keys that holds the title. So I found a site with information on sorting using keys, and used it to create the following code:

//Sorts by titles
content.sort(function(a, b){
	var titleA=a.title.toLowerCase(), titleB=b.title.toLowerCase()
    if (titleA  titleB)
        return 1
    return 0 //default return value (no sorting)
})

So, I tested and committed it, and created pull request #168. The creator informed me that all I was doing was exposing environment variables to the build, and so I decided to add a feature that allows it to sort through alphabetically if chosen. I then went and modified the code to add the new features to the filter bar, implemented as a dropdown that allows the users to choose whether or not to sort alphabetically. After implementing it using the code above in both the App.js and filterBar.js files, I pushed it to the original directory.

The creator of the directory informed me that I needed to update the snapshots of the code so that it would pass the tests to see if it was working. I tried to run npm test, but for some reason it did not run a single test found within the repository. So, I looked into trying to determine why the tests were not being read by the command. Strangely enough, all I needed to do was add an empty line to the end of each test file and it began working correctly. I saw that it was returning an error, and looked up how to update the snapshots. I ranyarn test --watch that I found here and updated the snapshots to fit my new changes to code.

This release was not as simple as I planned. I ran into quite a few problems trying to do both issues, since the testing in my Creative-Collab did not function as expected, even though there was so little to do, it still gave me an error. The pull request for the tv and film repository also was more complicated then expected, as it took quite some time to find where to enter the new code, and I have never worked with snapshots of code before. It’s good to remember that with any issue you’ll always run into problems.

OSD600 Creative Writing Game Pull Request

For this blog post, I will be working on making changes to the repository that the students of our class has made, for a story writing game app that allows multiple people to collaborate on a story, with each player taking turns. The current repository, Creative-Collab, is rather sparse, with a barely functional app that has almost no features. I plan to work on creating the CONTRIBUTING.md page, issue #15, because no one else will be able to work on the app unless they know how to contribute, so someone has to take the mantle of figuring out how it works.

So, I forked the repository and cloned it onto my computer. Then I tested the app on my computer. I ran the code npm install from within the directory and then npm start to run the app. The app worked fine, so I used the boardgame.io document as a outline and created a Contributing doc with what I used to run the app. The creator of the repository informed me on what version of node that they are using to run the app, so I included that as the minimum requirement for the Node install. I also made some changes to the Readme on the commands needed to run the app.

So I created a pull request to the original repository for the new Contributing doc and Readme, pull request #16. One of the contributors asked for some minor changes to the documents, like changing some of the wording, and after making the changes, the pull request was accepted into the repository.

While the issue I dealt with seems small in scale, I believe that it was an incredibly important one to deal with early on. Without someone completing it, no one would be able to work on the code, as they would most likely not know what to do to even start up the app, whether there are specific commands to run, or the environment they need to be in. I hope that my changes lead to everyone else being able to work on the code without getting confused on how to get started on the work.

OSD600 Plan for 0.3 Release

For this blog, I will be explaining my current plan for the 0.3 release of my osd600 course. For this release, I will need to create 3 pull requests, either 2 requests for Seneca projects and 1 pull request for a repository outside of Seneca, or vice versa, 1 Seneca request and 2 external request.

For my current plan, I am going to attempt to work on a creative collaboration writing game web app that allows multiple people to play a game where they take turns writing a story, with each player entering a certain amount of words until it reaches the end. The current repository is located here, with the owner as one of the students in the class. Our current plan is to examine a framework, boardgame.io, that is used for board games and determine a way to extract what we need to implement our creative writing game. I may also take on some issues within the framework as a way to both complete a pull request and learn more about the framework at the same time.

I may also attempt to complete an issue that I took during Hacktoberfest, trying to implement clickable url within a Webchat repository that allows deploying a bot straight to a website, Recast.AI Webchat. I did not have enough time to work on it during Hacktoberfest and would like to see if it is possible to finish it now. I have finally managed to get the Webchat up and running on my computer, and just need to determine what changes are necessary to add in clickable url, since there is no clear sign of where to implement it. It would definitely take some time trying to figure out where I would need to put in the new implementation, so I’ll have to take a look when I get the chance.

This is my current plan for what I am going to do for this release. I am not certain whether I will create 2 external or 2 Seneca pull request, I will have to see over time.

Hacktoberfest Final Sumamry

Going through Hacktoberfest and making pull requests was quite the experience. Trying to work on projects that I know nothing about, with limited knowledge on what needs to be done and trying to figure out solutions to unknown strangers’ problems was nerve-wracking, and attempting to set up my environment for work was much more difficult then I would have expected.

My first pull request was definitely the easiest. I simply needed to create a function for issue #411 getWordCount and place it within the hacktoberfest-2k18-katas repository. It was rather simple, just creating some code the gets the number of words within a string was no big deal, and downloading the necessary packages to use yarn was easy enough. Solving this issue was a good way to learn how Hacktoberfest worked, and gave me the opportunity to test my development environment. I made the pull request, #477, and had it quickly accepted into the repository.

My second pull request was a bit more difficult. I went to work on issue #8 of the image2pattern repository, to see fix a problem with the code using string concatenation instead of node paths. The difficult part was how when I attempted to create the solution for the issue, when testing it on my computer, it did not work as planned. When I asked the creator of the repository about it, he informed me that it was most likely a problem with my environment. So I created a solution that I expected to work even though I could not test it, and the creator merged the solution into his repository, in pull request #15. Next time, when I am not on such a time crunch, I would like to figure out what the issue is so that I do not run into it in the future.

My third pull request was, strangely enough, the most difficult and the easiest at the same time. I went to solve issue #335 of the Goodwork repository, which was just a bug that a dropdown menu was not showing. When attempting to build the repository on my computer, however, I ran into issue after issue, just trying to get it working! Every time I solved a problem, I ran into a new problem, and could not get it working no matter what I did. I then decided to attempt to solve the problem without getting the app working on my computer, to see if it was possible. I managed to figure out the problem and fix it in no time flat, just by taking out a line of code. I created pull request #352 and it was accepted into the code. I hope that more repositories will make their code more Windows friendly.

Working on my fourth pull request, I ran into similar issue that I did with my third pull request. I was going to work on issue #31 of the BookPro repository, and improve on a book search function. However, when I tried to build the repository with Docker, I still could not get it working! This time, I created issue #36 asking for someone to improve on the README so that it would work in a Windows environment. After some back and forth with the creator, he made the necessary changes so that it would function in a Windows environment, and I was able to fix the issue. What I did was add another section to the HTML file that included the more relevant books, and modified the python code to so that each section would be separate, and made pull request #49.

My fifth pull request was luckily a lot more math and a lot less problems setting up. I decided to work on issue #1 of the Color-the-Internet repository, and beautify some of the code within it. Easily enough, all I needed to do was set up an environment for testing the python function, and determine a simpler way to replace how the code determined the velocity of the images. So, I figured out how to switch the multiple if statements with a calculation function, and made pull request #2. This was probably the easiest issue to solve, since I did not need to go through multiple painstaking steps just to get my environment working. What was the most surprising was the fact that I learned there were multiple people working on the pull request without me even knowing, since they did not say anything about working on it in the issue, and in the end the creator accepted my pull request because he said it looked the best.

Overall, working on issues during Hacktoberfest was interesting. I had some good times and some bad times, but I managed to get through all of them in the end. Most of the good times was working with code, and most of the bad times was trying to get my environment ready for work with that code. It was still a good learning experience, and I may consider doing it again next year.

Links to my blog posts for each request:
Hacktoberfest Kata Pull Request
Hacktoberfest Image2Pattern Pull Request
Hacktoberfest Goodword Pull Request
Hacktoberfest Bookpro Pull Request
Hacktoberfest Color-the-Internet Pull Request

Hacktoberfest Color-the-Internet Pull Request

For this request, I will be beautifying and simplifying the code of a python function for a program that creates a data visualization of datapoints received from incoming internet packets, Color-the-Internet. I found the issue where it was located, and informed the creator that I planned on working on the issue, issue #1. The issue is to clean up the code of a function that checks the size of the last packet and converts it to a velocity rate. The previous code looks like this:

def variancechecker(i):
		if i < 1000000 and >= 950000:
			 return 0.0095
		elif i < 950000 and >= 900000:
			 return 0.0090
		elif i < 900000 and >= 850000:
			 return 0.0085
		elif i < 850000 and >= 800000:
			 return 0.0080
		elif i < 800000 and >= 750000:
			 return 0.0075
		..................................
		elif i < 55 and >= 50:
			return 5.0
		elif i < 50 and >= 45:
			return 4.5
		elif i < 45 and >= 35:
			return 4.0
		elif i < 35 and >= 30:
			return 3.5
		elif i < 30 and >= 25:
			return 3.0
		elif i < 25 and >= 20:
			return 2.5
		elif i < 20 and >= 15:
			return 2.0
		elif i < 15 and >= 10:
			return 1.5
		elif i < 10 and >= 5:
			return 1.0
		elif i < 5 and >= 0:
			return 15
		else:
			return i

This is not very clean and incredibly inefficient in terms if code, with multiple if statement checking multiple short increase in values. Looking over it, there are likely some problems with what the code is returning, as it probably should not return 4.0 when it equals 30, since it skips over a number. I asked the creator whether that was a mistake with the code, or if that was intentional, and continued with under the belief that those were a mistake, so that it would be possible for me to use mathematical equations to deal with the issue. Later on the creator informed me that it was indeed a mistake, and changed the code to fix it.

So, now I began working on a way to reduce the sheer number of if statements so it will function better and will be much more readable. I realized that it would be possible to reduce the if statements if you instead replace the range of the checks with a much larger number, and replace what is being returned with a calculation that determines what to return based on the variable being used. I expanded the range to encompass all numbers between. This is the code that I came up with:

def calculatevariance(num, modulus, divide):
    return (num - (num % modulus)) / divide

def variancechecker(i):
    if i < 1000000 and i >= 100000:
        return calculatevariance(i, 50000.0, 100000000.0)
    elif i < 9500 and i >= 1000:
        return calculatevariance(i, 500.0, 100000.0)
    elif i < 1000 and i >= 100:
        return calculatevariance(i, 50.0, 1000.0)
    elif i < 100 and i >= 5:
        return calculatevariance(i, 5.0, 10.0)
    elif i < 5 and i >= 0:
        return 15
    else:
        return i

I created a pull request back to the original repository, informing the creator about how the new function worked, pull request #2. I made it so that it would use a function that calculates the rounded decimal number for each range, so it would be much easier to work on the function itself or change anything about the function. The creator informed me that there was some numbers that were not giving the correct response. After looking into it, I noticed that there was a range that was not accounted of within my calculations, as anything between 9500 and 100000 returns 0.095, so I modified the code to fix that issue.

def calculatevariance(num, modulus, divide):
    return (num - (num % modulus)) / divide

def variancechecker(i):
    if i == 1000000:
        return 0.0095
    elif i < 1000000 and i >= 100000:
        return calculatevariance(i, 50000.0, 100000000.0)
    elif i < 100000 and i >= 9500:
        return 0.095
    elif i < 9500 and i >= 1000:
        return calculatevariance(i, 500.0, 100000.0)
    elif i < 1000 and i >= 100:
        return calculatevariance(i, 50.0, 1000.0)
    elif i < 100 and i >= 5:
        return calculatevariance(i, 5.0, 10.0)
    elif i < 5 and i >= 0:
        return 15
    else:
        return i

So, I informed the creator about the new changes, and he informed me that it was working great and closed the pull request. Completing this issue was much less code and much more math, but was rather fun, since I enjoy math from time to time. With this, my final pull request is complete, and I can be glad about all the work that I have put into this. This was a great experience, working on projects and learning new things as I solve issue. Maybe I’ll join Hacktoberfest next year, but for now I’m looking forward to some nice rest.

Hacktoberfest Bookpro Pull Request

For my fourth pull request, I will be improving on the search function of an open source price comparison tool for books, BookPro, by . As usual, I first commented on the issue that I planned to work on and informed them that I planned to work on it, issue #31. Then I forked the directory and cloned it onto my computer. Following the instructions in the README, I downloaded Dockers for Windows by creating an account and setting it up, and began to set up my environment. I ran the docker build command and tried to run the program using so that I could test it. I quickly ran into some issues, as while the scripts were running I received an error stating “/usr/bin/env: python\r: No such file or directory” and the command would fail.

I created an issues informing the creator of the repository of the problem and asking to update the README so that it will work within a Windows environment, issue #36. After some back and forth with a contributor, we managed to make the necessary changes to the files and README so that it functions in a Windows environment, and closed the issue.

So, I ran the new command after pulling the code from the original repository after syncing my fork with it, and I began looking into the issue. I first took a look into where the search function is located, views.py. I found the search function, and saw that the relevant books variable was already declared and included in the render, so there was no need for me to implement that. So I moved on to the code that makes the page, results.html. I copied the code that was being used to create the list of all of the books, and replaced the new list using the relevant variable, then placed it before the list of all the books.

{% for book in relevant %}

I then went back to views.py to remove the relevant books from the list of all the books. I used the following code:

all_items = [x for x in all_items if x not in relevant]

I tested the code by running the docker-compose up --build command, and it worked as expected, with the relevant section located at the top, and the related section located under it. I then added the new files, made a commit, and pushed the files to the original repository, creating a pull request stating the changes, pull request #49. The contributor informed me that my pull request worked as he wanted, and he merged the request with the original repository.

Completing this issue took longer then expected. It seems that not a lot of repositories are made for use with Windows, as I ran into a similar problem with my previous pull request. Luckily, this time I was able to discuss the changes so that it will be compatible with a Windows environment, so everything managed to work out.