rscotchmer

Well, this is it -- my final blog post for DPS909. When I started this course, I was quite honestly dreading what was to come. I'd heard a lot from my colleagues -- even those with prior open-source development -- about how this was one of the hardest courses they have ever taken. I heard that I'd be devoting most of my week to completing the coursework, that the bugs I decided to work on would vanish or get taken by others at the last second, and so on and so forth. Most terrifying, though, was the fact that I'd never touched an open-source project before. The thought of getting involved in a project like that was paralyzing, and I was dead certain that I was going to make a fool of myself. And yet, in spite of all of this, I still signed up for DPS909 anyway. The reason? I needed to beef up my resume. My first co-op term was coming up, and I didn't have anything software development-related on my resume. Not great, considering I'd be looking for a j...

I feel like I wrote last week's post on Aseprite just yesterday -- time flies near the end of the semester! Since that post, I've made a lot of progress on my issue. For starters, I actually finished it! ...Well, most of it -- waiting on some reviews at the moment, among some other things, but the features I've added work.   You can check out my PR here . Adding elements to the UI wasn't nearly as difficult as I thought it would be, but it still required a lot of thinking on my end... And a lot of sifting through code, too. Mostly for examples, but also to make sure that I was following the project's general style -- the folks working on Aseprite have a unique way of formatting things, and I wanted to make sure I adhered to that as best as I could. Anyway, after a couple hours' worth of work, I managed to finish everything up on a Saturday afternoon. I committed my changes, pushed them, and... Promptly forgot about them for the weekend. Come Monday, t...

For my latest assignment in DPS909, I've been working on this issue in Aseprite . This wasn't really planned -- to be honest, I actually was going to deal with a bug in filer first -- but one thing led to the next, and I suddenly found myself working on this project instead. I talked about how I've dealt with something similar -- making a fill tool -- in last week's blog post -- and much to my delight, that past experience has served me quite well. In fact, modifying the current code for the fill tool to fill pixels connected on a diagonal was hands-down the easiest part in tackling this issue. It took me maybe 20 minutes to implement -- a few lines copied from existing code, a +1 here, a -1 there... Throw in a couple of if-statements, and voila! It's done. The only tricky part came when using the fill tool on a large area caused the program to crash. To determine where the issue was, I used the most basic of debugging techniques -- commenting bits of code...

My next two tasks for DPS909 are to fix two issues that are a bit bigger than the ones I've dealt with previously. Thanks to my prof, I've already got one issue to work on: a bug in Filer where flags are interpreted as strings, not numbers. I'm not entirely sure how much work it will take to fix this -- I think it largely depends on how wide-spread the issue is across files. If it's contained to only a few, that makes my life easy; if not, I imagine I'll be playing a game of "Where's Waldo", where Waldo is one of many instances of the bug. On the bright side, my prof has offered to mentor me through fixing the bug, so I know I can count on some guidance for this. The other issue I wanted to work on is in a different project. I recently got into doing pixel art, which is easiest to make when you've got a specialized program for it. A few Google searches led me to Aseprite , an open-source image editor geared directly toward those of us doin...

As this first week of March comes to an end, so does my first month of contributions to (public) Github repos. It was an interesting experience, and I learned quite a bit from it. I learned how to use Git more effectively, how to set up various environments for open source projects, and the basic do's and don'ts (like watching out for spurious whitespace changes!). I also gained more confidence in my skills -- enough so to start pushing my own work to Github and join the very active modding community for Stardew Valley. This was something I've wanted to do for literal years , but fear kept me away. Now, though, I've got one published mod and another in the works... And maybe some plans to help out the community by helping to update the old, open-source mods that have broken as the game's been updated. All that, thanks to a little confidence boost from a few Github contributions. Of course, I still have my hang-ups -- I still struggle with imposter syndrome ...

I really like working in Filer. I'm not saying this just to get brownie points with my prof, who helps maintain the project. I'm saying it because I genuinely like working on it. This is probably pretty evident in the fact that I keep going back to work on it. -- as of today, 3/5 of my contributions for DPS909 have been for Filer. I'll admit that familiarity was part of what kept drawing me back to the project. The other part? I really like writing tests. I discovered this after my previous experience in Filer , where I had to make a test for one of the module's functions. The test I "wrote" wasn't that difficult to make -- it was mostly a copy-paste of a pre-existing test with some tweaks (hence the quotation marks around wrote, ha). The tricky part was more understanding what I had to do in order to create the test -- it was like trying to put pieces of a jigsaw puzzle together. I had a pre-existing test to use as a template, some general in...

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...

Foreword Note: This section doesn't talk a lot about the code -- if you're looking specifically for that, skip ahead to the next section. I've always wanted to get into open source development. It seemed like such a cool thing -- programmers from all over the world, working together to create something. Anything . I would browse through GitHub here and there, looking at all the neat things people were doing. Sometimes I'd think about joining in, but I'd always find some reason -- some excuse, really -- to stay away. I was too busy, I didn't know the language, there are already plenty of contributors, I don't know how to use Git, I don't know how to set things up... And so on. Really, I was just finding a way to let myself off the hook and avoid confronting the real issue: I was afraid. I didn't want to make a mistake, I didn't want to make a fool of myself... And I really didn't think I had anything to offer. Logically, I knew th...

Despite having used Node.js a lot in the past few years, I've never actually dug deep into the fs library. I've never really needed to dig deep into the fs library -- my Node.js projects have largely been RESTful servers, which pulled JSON objects from a document database (mongoDB, usually). So when I was told to go research a function from the fs library, I was actually a little excited. ...And slightly apprehensive. I haven't had much experience reading code, so I knew finding the information I needed could be a bit tricky. Fortunately, Node.js has some of the most well-organized documentation I've ever seen, so beyond finding a few obscure files, I didn't have too tough a time. So, without further ado, let's get to looking at the function I chose to learn about: fs.mkdtemp(). What is fs.mkdtemp()? fs.mkdtemp() is a function in NodeJS' fs library. According to the official docs , it "creates a unique, temporary directory." Honestly, at...