DPS909 0.2 Release – Pull Request 3

My third pull request was on another topic that I have not done in a long time. This time I was working with C++. C++ is a general-purpose programming language. It has imperative, object-oriented and generic programming features, while also providing facilities for low-level memory manipulation. I chose to work with C++ because I have a somewhat decent background in the language even though I have not worked with C++ in almost two years. But before that, I was working extensively in C++. I decided to work with C++ for my third pull request because it had been a while since I have used it so I decided to use this pull request as a somewhat refresher in the topic. I’m sure for my next pull request I can work with a language that I haven’t used for my previous two pull requests. The following is the issue that was posted that I decided to work on.

Add two matrices #74

What was being asked from the issue was to add a new file where two two dimensional matrices would add with each other. First I had to review two dimensional arrays. I also had to make sure that if two separate two dimensional arrays that had different dimensions were able to add with each other. After doing research I learned that both two dimensional arrays had to have the same dimensions in order to be added with each other. So first I had to make sure that both two dimensional arrays that are being added are the same dimension. That means if one array was 2×4 the other array had to be 2×4 and not 4×2. I decided that the user should input the numbers of rows and columns to create the dimension of the arrays, which is done in the following image.


After the user enters the dimension of the array, the user must enter values to populate both arrays. I could have set values when the program loads but I figured it would be better if the user would enter their own values. When the user enters their own values, I made sure to display which matrix has values being entered and the position of the value being entered next to the text field. So the values are entered in the following image.


After all of the values are entered, the next field displays the sum of each position after both matrices are added like in the following image.


After making more tests to make sure everything was done correctly, I made the pull request and made sure to reference the issue in the pull request which is done in the following link. I am glad I completed this issue because it has been some time since I’ve worked with C++ and this was a simple refresher in the language. I believe this has been my fourth pull request and working with Git Bash has become natural to me. This assignment has helped when it comes to working with different problems in different languages and making pull requests to GitHub helps when it comes to understanding how the repositories work. The first time I was working with GitHub I was always so confused as to how it all worked but know it is all very simple and easy to understand.

Added addTwoMatrices.cpp -74 #82





DPS909 0.2 Release – Pull Request 2

My second pull request was on a topic that I have not done in a long time. This time, I was working with HTML and CSS. Hypertext Markup Language (HTML) is the standard markup language for creating web pages and web applications. Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a document written in a markup language like HTML. I chose to work with HTML and CSS because I have a good background in the topics and because I was working on other assignments at the time so I did not have the time to experiment with a new programming language. Hopefully for my next pull request I can try something new depending on what my schedule looks like. The following is the issue that was posted that I decided to work on.

Add a good about page layout #7

What was being asked from the issue was to add a page for about.html. What I was updating was someones website which included a home, contact, and about page. The about page already had some work done to it, so I added whatever I could think of to improve the overall look of the website.

The first change that I made was to add a new CSS for the about page. I also made sure to link the about.html page to the about.css sheet. Then for the about.css page, I tried different colors and patterns to improve the overall look. The website already had an image taking the top half of the page so it was difficult to add colors that would go with the placed image. So I made some minor improvements like making changes to the font and the font style. I changed the font to Lucida Console, made it bold, and added a shadow to the header at the beginning of the about section. After my changes were completed, I made the pull request but I happened to run into some problems. The following is the link to my pull request.

About page #26

The repository that I was working with had a specific branch that had all of the necessary files including the about.html page that I needed to work with. So initially I was pushing to the master branch but in order for my pull request to be merged, I had to push into the hacktoberfest branch that was already created. After I realized this mistake, I made sure to complete my pull request to the hacktoberfest branch.

After completing this pull request, I am feeling more confident when it comes to GitHub and Open Source. But now that many people are participating in hacktoberfest, it is a bit difficult to find a recent issue that no one has taken yet because it seems that an issue could be posted for five minutes and then it gets taken. So I will make sure I have sufficient time before the next due date to get an issue so I won’t run into any problems in the future.




DPS909 0.2 Release – Pull Request 1

My first pull request was on a new language I have not worked with before called Ruby. Ruby is a dynamic, interpreted, reflective, object-oriented, general-purpose programming language. Ruby supports multiple programming paradigms, including functional, object-oriented, and imperative. It also has a dynamic type system and automatic memory management. I chose to work with Ruby because it was a chance to work with something that I have not worked with before. The following is the issue that was posted that I decided to work on. 

Fix error character “!” event not found #4

The program that had to be fixed was not exactly a difficult concept. Using Ruby, the user can enter text into the command line after compiling the program, and that text would be converted into giant text using certain symbols found on the keyboard, like the following. If no text was entered then the string RUBY LETTERS would be displayed.


So the text within the quotes would be read from the command line, then the program would go through each character within the quotes. Each character would be matched with what is stored in the array of characters in the program. An array will be formed containing references to the collection of characters array and each element will displayed beneath the commands. 

The issue that I chose to work had to do with an exclamation mark. As you can see, when an exclamation mark is included in the string, you get the following error.
-bash: !": event not found


So the first task in fixing this issue was to clone the repository, create a branch, and reference the issue in that branch. After completing all of the necessary tasks for the initial GitHub phase, I studied the program file letters.rb. I learned how the user designed the program and decided which areas of the program that I could change to help fix this error. I thought by manipulating the string from the command line would help but it didn’t. I tried manipulating the user input string, or the string when an exclamation mark is called from the collection of keyboard symbols would work but it did not. So I resorted to the last tool which is used whenever I run into a dead end, which is Google. I looked through different forums to figure out why the exclamation mark was not found. It turns out that the exclamation mark is not allowed in bash. That is not entirely true. The exclamation mark is part of history expansion in bash. What does that mean? History expansion is performed immediately after a complete line is read, before the shell breaks it into words. History expansion is the first stage of processing, even before shell parsing, which is why double quotes don’t protect ! the latter is processed before double quotes. It is handled by the history library, which implements its own parsing, with a few ways of protecting the history operator. By the time the shell’s parser starts handling a string, it’s already been parsed by the history library and history expansion has already taken place. Enclosing characters in double quotes " " preserves the literal value of all characters within the quotes, with the exception of $, `, \, and, when history expansion is enabled, !.

It turns out that the issue that I took upon myself did not required any code to fix the program because the program did not need any fixing from the beginning. It turns out that all the user has to do is enclose the string in single quotes to avoid the error: -bash: !": event not found

By using single quotes ' ' the user can escape the history expansion character, but the history expansion character is also treated as quoted if it immediately precedes the closing double quote " " in a double-quoted string. In the following examples, the strings are enclosed in single quotes ' ' and contain exclamation marks. 


Since there were no changes that had to be made to the code, I decided to add a character since that was the first issue that was made regarding this repository. The character that I added to the collection of characters was the equals sign =

Add special characters #1

The equals sign was simply two lines of underscores and after testing my addition to the program I made sure to add the changed file, commit, push, and finally make the pull request. 


Pull Request – Fix #4 Use ‘ ‘, Add equal #18

In my pull request I left a description of why the exclamation mark would return an error and I mentioned to use the single quotes ' ' from now on to avoid any further errors. I also made sure to reference the very first issue issue that was filed which was to add special characters since I added the equals sign to the program. 

After completing this pull request, I feel that I am starting to become more comfortable with GitHub and Open Source in general. It was a bit intimidating at first since GitHub is relatively new to me, and there are so many languages out there that I have not worked with so working on an issue that was created by someone that I don’t know, in a language in which I am inexperienced was a bit terrifying. But after studying the code and doing the research I don’t exactly feel intimidated to take on new tasks in the future and I am confident that I can complete this release on time.


Bash Reference Manual: History Interaction


DPS909 Fall 2018 Release 0.1

This first release was designed to expose myself to the common workflows and tools involved in contributing to open source projects on GitHub and personally, I think this first release was successful in doing that. By completing this first release, I had a hands-on-experience in completing tests for the Filer web filesystem project. Filer implements the node.js fs module and apart from creating a blog on two node.js fs modules in my previous blog, this was the first time I was using the node.js fs module to implement some type of test for a specific issue.

Before enrolling in Open Source this semester, I had limited experience when it came to Git Bash and GitHub. I already had a GitHub account, but it was mainly used to join different groups and it wasn’t exactly used to contribute to some sort of open source project. When it came to Git Bash, this was my first time using it and I obviously ran into a lot of problems from the start. But after continuously working through the issue I created I was finally able to successfully build my test and pass all checks and not have any conflicts with my branch and the base branch.

The following are the tasks that needed to be done in order to complete the first release.

  • An Issue should be filed before your create your Pull Request. The Issue must have a complete subject and description of the problem or change you believe needs to be made. The Issue must also be assigned by the Open Source professor in order to move forward with the release. – In order to create an Issue, I had to first go through the filer repository and find a file to work on and complete my testing. I found the time-flags.spec.js file and decided to add a test with promises.
  • The Pull Request should reference the Issue Number in its description (e.g., “Fixes #123: Add test for …”) – The Issue Number that was assigned when I first created the Issue was #469 and I did reference the Issue Number in my Pull Request.
  • Changes must be made on a new branch (e.g., if you are fixing Issue 123, use issue-123 as your branch name) – All of my changes were done in the branch: issue-469.
  • Adds a Test, and/or Code Fix, and/or Documentation update – I completed all of my changes on Notepad++ and after making changes I would build the file on Git Bash to check if everything compiled. If the build was unsuccessful then I would continue with debugging.
  • Code or Tests must pass eslint – After running npm run lint and npm run lint:fix the tests would pass eslint.
  • All Unit Tests must pass after your changes are made (i.e., new tests must pass, and you must not break existing tests). – After numerous builds, eventually I was able to receive a success when it came to my added test.
  • Co-ordination with other student/community Pull Requests. Make sure you don’t duplicate another fix or change that someone else has already done. – Before creating an issue, I made sure to check that no one else had already completed a test similar to what I was planning on doing.

When I first decided to create a test for time-flags.spec.js, more specifically not updating ctime when calling fs.rename(), I was lost. Node.js was a new subject and even with the all of the research I felt like I wasn’t ready to complete a test for the Issue I created. It didn’t matter because I needed to get started so I started creating code that I believed would be an acceptable test to my Issue. What I was doing at first was wrong and with the help from others on Slack, I was able to understand the first release, more specifically, my code needed to be completed. I tested fs.rename() using promises so ctime does not get updated when calling fs.rename() with NOCTIME. NOCTIME was a flag and whenever the flag was called, stat() should not be updated. My process for this release was to do as much research as possible to understand how to apply promises for testing functions. Over time it was easier to understand since I was making it more difficult than it needed to be. After completing my test I learned how to apply promises to fs.rename(), and more importantly, how to use Git Bash. I had never made commits and pull requests on my own before so this was a great learning experience for me. I would definitely see myself contributing to Open Source projects in the future with the new skills that I have gained. In terms of what I would do differently would be to complete more research on certain topics so I would not complete my tests incorrectly at first and then have to make major changes toward the end.

The following is the link to the Issue that I filed.

Link To My Issue

The problem with the time-flags.spec.js file was that one of the functions should not update ctime when calling fs.rename() with NOCTIME. My end goal with this issue was to use a promise to test fs.rename() and not have it update when the flag, NOCTIME, is called.

The following is the link to the Pull Request that I created.

Link To My Pull Request

Working on the Issue that I filed, I realized at one point I wasn’t exactly getting anywhere. After completing what I thought was correct but not having it compile on Git Bash, and having to start over helped me understand Node.js even more. Looking back, the fix was a lot simpler than I thought it would be. By creating a promise variable and applying it to createTree() and stat() and return with rename() I was able to successfully complete my test.

The following is the link to the Pull Request that I reviewed.

Pull Request Reviewed

I noticed that no one had reviewed this person’s contribution so I decided to review it myself. This person had a total of seven commits, but the last four were successful commits. I did not notice any major errors, but I did notice a few style errors, such as a few spelling mistakes and some white line inconsistencies. I made sure to point them out overall and on the lines where I noticed them.


So far, the only review comment that I have received wasn’t exactly constructive, but more supportive to my first contribution to an open source project. Nonetheless, it is very much appreciative but I will definitely by checking back to see what reviews are left on my Pull Request so I can improve when it comes to contributing to an Open Source project.

The following are links to my involvement on Slack.

Slack Question

Slack Response 1

Slack Response 2

Since this was my first contribution to an Open Source project, I did not feel confident when it came to mentoring others in this subject. But that did not stop me from asking questions. At first, I used the Slack resource to look at other comments people had posted because their problems were a lot similar to what I had been encountering. After using the responses to other posts to my advantage, I was able to move forward with the test. I did encounter what looking back was such a basic mistake. I was not in my working repos directory, but actually in the directory called repos, that is why I was not able to build my code correctly. After having someone point out the error that I had made, I was able to again move on with my test. I am very thankful that we have Slack at our disposable, and it is such an educational and friendly resource and I will definitely be checking back because I am sure that I might run into some sort of error in the future.

So after completing my first contribution to an Open Source project, I think it was overall a great learning experience. It was definitely time consuming but having my test compile without any errors was a satisfying. Not only have I gained some experience in Node.js, I feel more comfortable using Git Bash and GitHub and I’m looking forward to the next release for this course.

DPS909 LAB 1

In this post I will be going into detail about two Node.js fs modules: fs.access and fs.accessSync.

The purpose of the fs.access(path[, mode], callback) method is to check if a user have permissions for the given file or path. like the following example.

fs.access('/etc/passwd', fs.constants.R_OK | fs.constants.W_OK, (err) => {
if (err)
return console.error('no access')
console.log('access for read/write')

  • path takes a string, Buffer, or URL to specify file or directory.
  • mode takes an optional integer to specify accessibility checks that need to be performed.
  • The default mode argument is fs.constants.F_OK (to check of the path is visible to the calling process
  • The callback function is invoked with a possible error argument.

Other constants exposed for permission checking include:

  • fs.constants.R_OK– to check if the path can be read by the process
  • fs.constants.W_OK– to check if the path can be written by the process.
  • fs.constants.X_OK– to check if the path can be executed by the process.

Important: Using fs.access to check for the accessibility of a file before calling fs.open, fs.readFile or fs.writeFile is not recommended because a rare condition will be introduced. Between checking and the actual file operation, another process may have already changed that file. Instead, the file should be opened directly and the error cases should be handled there.

fs.accessSync(path[, mode]) is a module that synchronously (occurring at regular intervals) tests a user’s permissions for the file or directory that is specified by the path. The mode argument is considered optional (integer) and specifies the accessibility checks that need to be performed.

require('fs').accessSync("filename.ext", fs.R_OK | fs.W_OK)
//code to action if file exists
console.log('can read/write');
//if accessibility checks fail, an Error will be thrown