Open Source

DPS909 (Topics in Open Source Development) – Release 0.1 Discussion

Introduction

For this assignment, we were tasked to do the following tasks:

  • Create an Issue on the Filer.js GitHub repository
  • Implement the changes that I stated in the issue
  • Make a Pull Request on Filer.js’ master branch
  • Ensure that my own branch won’t break the code from the master branch
  • Review someone else’s Pull Request

The Issue that I created on Filer.js’ GitHub repo is the following: https://github.com/filerjs/filer/issues/506 . As stated in the issue, I planned to implement a new test case using the Promises API of Node.js. Since my own testing of unit test that I created was successful, I then filed for a Pull Request ( https://github.com/filerjs/filer/pull/520 ) and my Pull Request was successfully approved – meaning it has passed the TravisCI automated testing suite designed to verify that my changes didn’t break any of the code in the master branch when it was combined with my branch. The Pull Request that I reviewed is JoshRM’s Pull Request which dealt with adding a Promises API-based test case for the appendFile method of Filer.js. 

Now, let me discuss in detail about the tasks that I accomplished in the following sections.

My First Issue on GitHub

As this was my first Issue on an open source project in GitHub, I had only had a general idea on what to do about it – Mr. David Humphrey mentioned that the Issue to be filed on Filer.js can range from anywhere between fixing a documentation issue to adding new unit tests for methods in Filer.js that didn’t have a Promises API-based test.

I decided to go with his latter suggestion as this seemed more interesting to me, although at the same time I was quite nervous on how to approach this problem so I had to figure out a process to ensure that the Issue that I would file is an Issue that I can resolve on my own when I plan to implement the changes that I state. My thinking process was as follows:

      • Check the documentation of Filer.js and read the methods that are documented
      • Skim the method names and find something that can be easily understood
      • Check the ../spec/ folder for the JavaScript file that has the filename of the method that I want
      • Once the JavaScript file has been located, check the code and skim the code to find if a Promises-based unit test has been implemented
      • If no Promises-based unit test has been found, then that method is a valid candidate for the Issue that I will create.

Thus, I set out to find a method that didn’t have a Promises API-based unit test yet and this is what I found: fs.writeFile(filename, data, [options], callback) didn’t a Promises-based unit test so I decided that the Issue I will create will be about on adding a unit test that’s Promises-based.

When approaching this Issue and deciding on how to implement my solution, I came up with a process to ensure that I would be successful:

  • Review the unit testing code that has been already written on the JavaScript file
  • Dissect the code and try to understand it based on how each line of the code operates in a bigger picture of the unit test
  • Check the Node.js File System API documentation if I don’t understand something
  • Check the Promises API for the same/equivalent method that I want to test
  • Search Google on examples of using the Promises-based method

And after quite a bit of experimentation, searching, and ton of help from Mr.Humphrey, the following unit test code was produced:

describe('fsPromises.writeFile', function () {
beforeEach(util.setup);
afterEach(util.cleanup);
it('should write data to a file', () => {
var fs = util.fs().promises;
var buffer = new Filer.Buffer([1, 2, 3, 4, 5, 6, 7, 8]);
return fs.writeFile('/myfile.txt', buffer)
.then(()=> fs.stat('/myfile.txt'))
.then(stats => {
expect(stats.type).to.equal('FILE');
expect(stats.size).to.equal(buffer.length);
});
});

Simply explained, this code will write data to a file called myfile.txt  and check if the data was successfully written. If it’s successfully written, no error will be produced but if it’s empty – meaning that the write was unsuccessful – then an error will be produced.

Now, I’m ready to initiate my first Pull Request!

My First Pull Request

As my implementation for the Issue that I filed was successful, now it’s time to make my Pull Request on the master branch of Filer.js’ repository. The process itself was pretty easy: head to my own fork of the Filer.js repo and click the ‘Pull Request’ icon and make the appropriate decisions so that a Pull Request can be initiated. Surely enough, I did just that, waiting a few minutes for the TravisCI automated testing to process to finish and encountered an error which was related on line ending formatting as I modified the .eslintrc.json file by changing the "linebreak-style": from unix to windows. Thus, to fix the issue, I simply needed to revert my changes – resulting in one failed commit build and one successful commit build respectively as shown in the picture below.

PullRequest

My First Review of a someone else’s Pull Request on GitHub

Now that I’ve successfully completed my own Pull Request, it’s time someone else’s Pull Request. The Pull Request that I reviewed is JoshRM’s Pull Request which dealt with adding a Promises API-based test case for the appendFile method of Filer.js.  While writing my Pull Request, I kept 3 principles in mind – Be Respectful, Be Constructive, and Be Concise. The review of the Pull Request itself wasn’t that bad as his code was easy to read and the ‘split-view’ functionality of the commit changes made it easy to find what code has been added. Thankfully enough, his changes were successful as his Pull Request was verified – meaning that he passed the TravisCI automated testing. However, on a second look at his changes, it seemed that some improvements can be made: since he was testing the UTF-8 encoding for characters that will be written in a file (a topic that I’m familiar with) but he only used characters that would generally be encoded and decoded by universally every character encoding as it’s only English, I suggested that he uses a string that would have Japanese/Korean/Chinese characters in it so that the UTF-8 character encoding testing can be improved to ensure that those set of characters won’t produce an error as the UTF-8 character encoding standard is meant to handle the character encoding for those languages.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s