Hacktoberfest PR #5

The Project

The project was the same as the last pull request, I did the same kind of fix as the last one but this time I was adding a dairy tag to all foods that had dairy in them. Most of these foods already had milk in them so I felt it was a bit redundant to add the dairy tag but since the issue was still open I thought I was still a problem. This pull request was a still larger than the last one since there were a lot of lines that needed to be changed. That being said these two last pull request were pretty simple and didn't require to understand a lot of the nitty gritty in the project, which I'm thankful for.

Hacktoberfest PR #4

The Project

This project is Cataclysm - Dark Days Ahead is a turn-based survival game set in a post-apocalyptic world. I was led on to this project by a fellow student who told me there was some easy fixes that I could do. My fix was just editing a recipe in a JSON according to contributors suggestions. This project was a pretty big one at 1.3 gigabytes so I didn't bother building it I just made the pull request and let their automatic build systems check it.

Hacktoberfest PR #3

Third Pull Request

I was browsing thourgh projects and while I was reading the Readme I thought I saw typo so I made a reckless pull request without creating an issue or checking with the maintainers. This led to the pull request being closed because the issue I thought I found was actually not an issue. I learned that even the process of looking through issues/making issues and communication is a vital part of open source and I can't just drop what I think are fixes willy nilly.

Hacktoberfest PR #2

The Project

For my second pull request I just wanted to do a quick and easy fix. I had enough of cloning projects, builds failing, dependencies missing and just decided how about we update a README that sounds like it can be done without install 100000000 files. So I searched around and found the repository for HandBrake, HandBrake is an opensource video transcoder. Their main page had a docs repository which seemed just like the place to look.

Issue

It was actually quite easy finding an issue. It seems like this repo didn't have too much activity and the newest issue a month old. Conveniently the newest issue also didn't have anyone actively working on it so I decided to take a stab at it. It was just two misspelling fixes, created a pull request and that was it.

Conclusion

Even thought this pull request is pretty small I still feel a sense of accomplishment. Handbrake is a widely used tool and its nice to contribute to a larger project.

Hacktoberfest PR #1

First Impressions

Honestly I was excited about hacktoberfest when I first heard about it, I thought it would be full of huge opensource projects and bugs on stuff I use every day, except I found most of the hacktoberfest labeled issues are more of collections of code like a list of nice words or a set of algorithms in different languages. This made searching for actual projects tedious since there was a lot of these kinds of projects making issues but eventually I found a project that struck my interest.

Project

This project was a game engine written in c++ then a python wrapper is put on it so it can be used in python. I found this project captivating since it used combined two languages that I'm interested in. The game engine seemed to be in a primitive but working state. But more I read into the code the more it became confusing, it used a lot of strange calculations and an enormous amount of OpenGL functions which I couldn't understand. I kind of gave up on it since it seemed like a never ending rabbit hole of code. Except I couldn't stop thinking about it, I guess even if I didn't understand the code I still found it interesting.

Issue

At the time I was choosing an issue there was only two open and one of them was already being work on so I was left to do this one. Although I had no understanding of OpenGL or how texture rendering even worked I chipped away at it for a few days, looking at each function call, traversing files just to find some clue on how I could implement the fix. I found the line that used an image from file and the line that loaded it. All I had to do was change that and be done. So I messed around with it and got it working! Even I was surprised when it started showing different a image. This victory was bittersweet because after I changed the loaded image I couldn't find a way to specify that image in the python constructor. Thankfully it was pointed out that the python constructor wasn't in the scope of my pull request so I was in the clear. I put up my pr and that was it.

Pull Request

The project owner brought up some valid criticism in my pull request. I was loading the texture from file every frame which would cause additional lag and I could just have the image stored in a object group since it is being used by every object in that group. I made these changes and then tragedy struck... The pretty colors from the pictures weren't being shown anymore. It seemed like if the image wasn't being loaded right before it was being used, it would get corrupted somewhere along the line. I set sail back into the sea of code and tried to find out why this was but I just couldn't. I replied to the project owners comment telling him my problem seeing if he could find out why this was happening but as of righting this he has not yet replied.

Conclusion

I learned a bit about OpenGL and some game engine logic. I am still interested in this project but as of now it is unclear whether or not I will be worth the time investment and stress trying to contribute to this project. Overall even though it sounds like I had a terrible experience I actually enjoyed sifting through code and finally finding a nugget of gold only to find out it was fools gold.

First Open Source Experience

The First Step

Diving into a open source project was intimidating and frustrating, I spent a few hours just trying to get comfortable with the project space. Then I figured I would delve deep into the source code and try to understand how it all came together. This was... a mistake, not because the code is horribly written or anything it's just that I didn't have the time to learn this whole API. It was like trying to put a big puzzle together, It could be done but I had nowhere near the time or patience to do it. So I settled on porting a stat test to use the new Promise API in fs. This is what I think I should have done in the first place, don't dive straight in maybe just wet my feet and see how it feels. I opened up an issue and away I went.

The Nitty Gritty

The test I chose to port was this one. I had some knowledge of stat from the previous post so I could understand almost all of what was going on in here. First of all I made a branch that was call issue-423 (423 being the number on my issue). It was pretty easy to convert to using promises, just import the library, switch the callback to .then/.catch and that was it, I pushed it to my branch and made my pull request and thought I was finished. Except I had a few bugs that I wasn't aware of. Thankfully open-source community was there to help and they pointed out all the things I could improve. For instance changing my test be more promise-friendly and some style fixes, things that I wouldn't have thought of like returning the whole promise since the it() function can handle them. GitHub also made this process really fluid since all changes that I made in my local branch were reflected in the pull request. Even though I made the initial code I felt everyone who posted reviews helped write it.

The Give Back

After getting good feedback and improving my pull request I thought it was about time I re-payed the favor. I basically took what others suggested about my code and applied it to other pull requests. Like here and here. Overall I feel like not only my code got better but I helped other people learn as well. Working in open-source made me fix things that normally I would be too lazy to, it also helped motivate me learn git which I struggled with for quite some time.

NodeJS Stat

The Basics

If you're not familiar with stat I will give you a quick rundown. Stat is used in UNIX to view information about a file. In the fs module of NodeJs most stat related functions return a Stats object. This is what is looks like in the documentation.

Stats {
  dev: 2114,
  ino: 48064969,
  mode: 33188,
  nlink: 1,
  uid: 85,
  gid: 100,
  rdev: 0,
  size: 527,
  blksize: 4096,
  blocks: 8,
  atimeMs: 1318289051000.1,
  mtimeMs: 1318289051000.1,
  ctimeMs: 1318289051000.1,
  birthtimeMs: 1318289051000.1,
  atime: Mon, 10 Oct 2011 23:24:11 GMT,
  mtime: Mon, 10 Oct 2011 23:24:11 GMT,
  ctime: Mon, 10 Oct 2011 23:24:11 GMT,
  birthtime: Mon, 10 Oct 2011 23:24:11 GMT } 

This object holds a lot of information that seems to be irrelevant to us, but in reality it is all useful! I made a handy reference sheet so that the file statistics represent

 
  dev: Device ID
  ino: Inode number
  mode: File type and mode
  nlink: Number of links
  uid: User ID of owner
  gid: Group ID of owner
  rdev: Device ID (if special file)
  size: Total size in bytes
  blksize: Block size of file system I/O
  blocks: Number of 512 byte blocks allocated
  atimeMs: Time of last access in milliseconds
  mtimeMs: Time of last modification in milliseconds
  ctimeMs: Time of last status change in milliseconds
  birthtimeMs: Time of creation in milliseconds
  atime: Time of last access 
  mtime: Time of last modification
  ctime: Time of last status
  birthtime: Time of creation 

Lets put our new knowledge to use.

const fs = require("fs");
let filepath = "test1.txt";
fs.stat(filepath, (err, stats) => {
    if (err) {
        console.log(err);
    } else {
        console.log("Date Created: ");
        console.log(stats.birthtime);
        console.log("Date Accessed: ");
        console.log(stats.atime);
        console.log("Date Modified: ");
        console.log(stats.mtime);
        console.log("Date Changed: ");
        console.log(stats.ctime);
    }
});

Output:

Date Created: 
2018-09-13T22:04:58.180Z
Date Accessed: 
2018-09-13T22:04:58.180Z
Date Modified: 
2018-09-13T22:04:58.180Z
Date Changed: 
2018-09-13T22:04:58.180Z

We can also do the same thing using fsPromises

const fsPromises = require("fs").promises;
let filepath = "test1.txt";
let statPromise = fsPromises.stat(filepath);
statPromise.then((stats) => {
        console.log("Date Created: ");
        console.log(stats.birthtime);
        console.log("Date Accessed: ");
        console.log(stats.atime);
        console.log("Date Modified: ");
        console.log(stats.mtime);
        console.log("Date Changed: ");
        console.log(stats.ctime);
    }).catch((err) => {
        console.log(err); 
});

lstat works similarly to stat except if the filepath is a symbolic link the link in statted instead of the file. fstat takes a file descriptor instead of a filepath. To use fstat open a file using fs then using the file descrpitor from the opfunction and pass it into fstat
It would look something like this:

const fs = require("fs");
let filepath = "test1.txt";
fs.open(filepath, 'r', (err, fd) =>{
      if (err) console.log(err);
      console.log(fd);
      fs.fstat(fd, (err, stats) => {
          if (err) {
              console.log(err);
          } else {
              console.log(stats);
          }
      });
      // always close the file descriptor!
      fs.close(fd, (err) => {
          if (err) throw err;
      });
 });