rscotchmer

Edit 2/27/29: I created a pull request , and have written more about my experiences in the section "Making The Test". Another week, another bug to find and another pull request to make. ...Well, in theory, anyway. Truth be told, I haven't made as much progress on this week's bug as I would have liked. One of my other courses had a major project due this same week, and that may have taken precedence over this project. Due to that, I don't have a pull request up yet, though I'll be sure to change that early on in the coming week. It is imperative that I stay on top of my work, after all; falling behind on one project leads to falling behind on the rest of them, like some awful game of academic dominoes. Anyway, I'm getting off-topic here. Before I go off on another tangent, let's get into what we're actually here for--fixing bugs. The Bug For this week, I decided to return to a project I'd worked on before , called filer . I'

When finding an issue to work on in an open source projects, it's very important to keep your own strengths and weaknesses in mind. Just because an issue says "good for first contributors" or "good first bug", doesn't mean it's necessarily for you. ...Well, not if you're working on a deadline, anyway. Which I am -- I was supposed to have fixed a bug by today in a project of my choice. Instead of a pull request, though, I've got 3 different projects in ember.js sitting on my hard-drive and a search history filled with queries along the lines of "ember.js basic routing examples". From hours of research, I've got a few measly lines to show for my effort -- and they're certainly not worthy of being pushed to a project. All this because I didn't take a moment to think about my strengths. The Bug I spent the better part of a week looking for a bug to work on for my course, DPS909. It had to be something small -- I had

For a lot of people -- myself included -- getting involved in open source development is a very, very daunting task. We all have our different reasons for being hesitant to jump in -- I, personally, struggle a lot with impostor syndrome, which I talked about in one of my previous posts . Another big hurdle for me, though, is finding a project to work on. Self-esteem issues are debilitating, sure, but it's hard to even get my foot in the door when I don't know what I want to do in the first place. Do I want to program in Java? C? C++? How about JavaScript or TypeScript? Maybe something I haven't used before, like Rust or Elang. The possibilities are endless! And, quite frankly, pretty overwhelming... Especially if you're as indecisive as I am. Fortunately for me, though, I do have some requirements -- those outlined by my assignment, specifically. The gist of it is that I need to make 4 pull requests by March 8, with deadlines along the way for each indiv

I have a pretty limited experience with git. I know the basics of push, pull, commit, checkout, branch... The bare-bones of what you need to make use of this tool. Not efficient use, though; I have made plenty of mistakes and backed myself into bizarre corners because I don't fully understand what a certain command does. In an attempt to familiarize myself more with the powerful commands at my disposal, and hopefully reduce the number of times I turn my repositories into some eldritch abomination, I decided to take a closer look at two of my favourite git commands: reset and rm. This article assumes you have a basic understanding of Git, and know what HEAD and index refer to. If you don't, you'll definitely want to check out the docs before reading on. Git Reset What It Does According to the official docs , git reset reverts the current HEAD to the specified state. It does this by following these three steps: Change the branch that HEAD points to Refactor th