Abdul's OSD600 Open Source Journey

Setting up Pytest I decided on using pytest as my test runner because it seemed to be the testrunner that was the simplest to use and put the least amount of work on the developer when writing tests. It didnt require the need to create classes to run tests or the need to designate an entry point when running from command line. To install pytest I just had to use the python package installer using the command pip install pytest. After reading some the pytest documentation and reading this article I felt like I was ready to begin writing my first tests.   Writing My First Tests I decided the first thing I wanted to test with the constructer for my TextFile class. To do this I looked at my class and tried to write a test for as many possibilities. This included writing a test to see if the expected result for a nonexistant file, a nonreadable file and a regular valid file all matched. Next I decided to run tests to make sure that the the values stored in the TextFile class were what wa

Setting Up Telescope For this lab, the first step needed was to set up the telescope development environment. And that was were most of the difficulty of the lab came from. I had not used a linux environment in over a year so it was nice to see that the telescope documentation introduced me to the WSL(windows subsystem for linux) tool for windows. Once I had installed and set up all the necessary software needed to run telescope (WSL2, Redis and Elasticsearch specifically), I ran into an issue where the /posts part of the local environment I would need to work with my link checker was resulting in an error and the json array I was expecting was being returned blank. The next problem and bigger problem I had was that instead of consulting my peers in the class about this error I instead just struggled with it alone and this resulted in continued procrastination and falling further behind. The feelings of adequacy preventing me from collaborating with my classmates and peers, is a recurr

 Introduction This week I learned how to incorporate the usage of static analysis tools in my development process. These tools are an easy way to make sure my code is correctly formatted and free of any common or easy to miss errors. The project I have been developing ( my CLI  DeadOrNot  ) was written in python so I decided on using the following two tools:  Black (Code Formatter for Python)  Black is a python code formatter that cleans and up and makes the formatting of your code consistent. When I ran it on my two python source code files, it shortened some of the lines I had that were too long, fixed the spacing issues I had (missing spaces after an operator, leading spaces at the end of a line etc) which overall resulted in my code looking more readable.  To set up Black, I used the python installer pip in my terminal using the command pip install black (note: Black requires python 3.6+ to work). Once Black was installed I ran it on my projects directory using the command black .

 Introduction   This week the focus was on creating a refactoring branch of our link checker CLI's and using that to make improvements to code to increase readability, maintainability and clean the code up. The goal was to use the refactoring branch to make incrementable changes one by one and then rebase those changes into one single commit to be merged with with master branch.    My Focus for Improvements  For the improvements I wanted to make on my CLI, I wanted to focus on making my code more readable and remove as much ambiguity as I could. I felt that the code was already portable enough to be maintained by me but there were multiple instances were I had written code that was vague and hard to interpret, whether it be using numbers without explanation  or having variable names that were not clear. First I went to solve the problem of how I parsed and filtered out the command line arguments. I decided the best solution would be to retrieve the arguments and then send them to a

 Introduction This lab revolved around adding an -ignore feature to another repos link checker CLI. This would allow another file to be used as an argument and that file would contain links that would be ignored during the check. I decided that I would try to work on a project that was made in python as that was the language my CLI was coded in making it easier for me to understand the code needed to create the feature  Ignore Feature for my CLI I was fortunate to have Matt Ross work on an ignore feature for my CLI. He created an issue on my repo and I assigned the issue to him and he began to work on it. He ended up matching my coding style well and created a class that would process and parse the ignore file similar to the class I created to process the url files. This would pass the links to ignore to the link checker and ignore urls that were contained in the ignore file. He added a argparse option that would handle this feature. I used git remote to get the code from his branch in