Michael Overall DPS909

While I only made a series of small changes, for Hacktoberfest, I feel that I learned a lot in the process. I learned about the capabilities of VirtualBox, in terms of running nested VMs (no 64 bit VMs can be run inside VirtualBox VMs), and the was introduced to the use of Vagrant for virtualizing a development environment across multiple platforms, and how to get creative by stealing JSON data from live versions of code when my local version was missing data (see the blog post here) . I was also exposed to some simple things that you don't necessarily think about unless you visit an array of repositories as an outsider (previously, my use of GitHub consisted mostly of working on school projects in private repositories). I discovered that if you own a repository, there are some files that may change or be moved that you don't think about--either because you are not the primary user of the file (like CONTRIBUTING.md), or because you overlooked how a change affected the acces

This  was another simple change for Hacktoberfest, as I had been investing a fair bit of time in learning  about Rust and concepts of integration testing for a different issue . The task was to go in and change the name of a function from "execute" to "run" in order to make it mimic the naming conventions for the axe-core function that it wrapped/called. I had looked through the files in the repo to check for calls to execute(), and changed them to be "run()". I also made sure I changed references to this function name that were included in the README.md file as well as a file that ran unit tests, so the test suite wouldn't freak out when the name of the function call changed (in fact, I made a point of running the unit tests with a bad function name to make sure that it failed). What surprised me, is that there was a comment made on the pull request that suggested the possibility of missing changing the names of calls to the newly renamed &qu

This was another simple issue that I created a pull request for. It was just to add a code of conduct file to the repository, and link to it from the CONTRIBUTING.md file. In looking into doing this pull request, I had noticed that the link from the README.md file to CONTRIBUTING.md was broken (mentioned in an earlier blog post). So after fixing this, I pulled the code of conduct file into the repo, and gave a relative link to it from the CONTRIBUTING.md file. It was only later that I realized I had given this relative link by habit. All of the other links to markdown files in the repo were absolute. The thing with using absolute links is that if you fork a repository, or are in another branch of the main repository, and then click on an absolute link, it will take you from the current repository/branch to the branch on the repository that the absolute link points to. With a relative link, you link to a file in the same directory, on the same branch of your repository. Both of th

One of the major goals as a software developer is to ensure that what you produce can be used by a variety of people. This concept may manifest itself in ensuring that your end users will find a piece of software as easy to use as the devs already think it is to use (it's obvious, isn't it?), or packaging your apps/coding environments into some kind of distributable container so that they will run consistently across differently configured machines. What we do and produce is the product of our own perspective; we see the world through our own eyes, and without constant, unadulterated, inhuman, hypervigilance we may find ourselves overlooking certain details from time to time (oh, to be an inhumanly hypervigilant dev). For example, as a repo creator, you might create a CONTRIBUTING.md file while using <a href="https://blog.github.com/2016-02-17-issue-and-pull-request-templates/">this great feature github has for creating templates for pull requests and issu

When I was a teenager I once went down to my local DIY bicycle repair shop to try my hand at wrenching on some bikes. Having worked to maintain a department store mountain bike of my own through minor maintenance, and having survived the experience, teenage me felt motivated to go lend my expertise through some volunteer work. They started me off with something decently simple: stripping a scrap bicycle for parts so that they could be placed into bins to be later found and used by patrons in search of inexpensive replacement components.  And what a simple task it was: I had pulled off the wheels, removed the derailleurs, brakes, brake levers, and shifters in no time until I was down to frame, handlebars and the fork (the bit of the bike that holds the front wheel, and connects to the stem; the bit that holds the bicycle's handlebars). Here was something unfamiliar. The handlebars were clamped into a stem, which then attached to the fork, but the setup looked different than what I

I found myself trying to look for a relatively simple pull request to get warmed up to Hacktoberfest . After a fair bit of poking around, and prodding at an issue in another repo for a library that I had actually used as an end user over the summer, I found an issue that looked relatively straightforward to help me get my foot in the door in a new and unfamiliar repo. The issue was to change some styling on a search page to help differentiate clickable menu items from non-interactive headings. The creators of the repo did a good job in providing a screenshot, and working link to running code that illustrated the issue here . They also provided a quick start guide for setting up the coding environment, and some additional tips on working with the virtual machine that comes with the repo. The project I aimed to contribute to is LibreCores , a website that hosts open source electronic hardware designs. The project is written in PHP using the Symfony framework . For its deve