DPS909 Lab6/7

This week, we are doing some practice on git. For this particular lab, the language I chose is Javascript. Since I've been working with many Javascript projects, I also like to work with Javascript in this lab, not only that I'm familiar with Javascript but also that the flexibility of this language is something I always want to explore. And more importantly, nowadays, javascript are being used everywhere, because it's such a powerful language that can handle both front-end and back-end tasks. In Addition,  a lot of the frameworks and libraries are also built in javascript. Thus, I chose javascript for this lab.

When I was building my javascript library for this lab. I noticed that there are actually a lot of existing codes online that can be re-used in my lab. For example, to get the size of a file I can just import the 'fs' module from the nodeJS.

In the above code snippet, notice that to get the size of a file in node only need 3 line of codes

  1. import the 'fs' module.
  2. get reference to the file.
  3. get the size from the reference
That's why I love javascript so much because there are so many existing modules that had been written by someone else, so you do not need to code them yourself.

The link to the repo of my js library is https://github.com/feihaozi77/BuildingJSLibrary. As a maintainer of the repo, I need to review the changes made by other contributors and provide proper feed back to contributors. Therefore, how you communicate with contributors is directly reflecting the outcome of how successful your repo will be. You need to pay attentions to the comments from contributors. 

Working with contributors is very fun, especially when you are discussing about a Pull Request, ideas are exchanged back and forth, changes are made/requested, merging. All those process are part of fun  of working with open-source project. It feels like running your own business, you are the boss of your repo. 

On the other hand, contributing to other's repo feels like I'm the "employee" of the other maintainer. You need to read documentations of their repo carefully  in order to understand the needs and what you need work on. Communication is important. Sometimes if you feel confident about the task and just work on it on your own without clarifying anything, you may run into issues that your work doesn't meet the repo maintainer's expectation and you need to make so many changes in the Pull request. 

Personally I prefer contributing to other's repo rather than maintaining my own. Because I enjoy reading other's code and learn from it. 

Comments

Popular posts from this blog

Documentation in opensource

Working with gh-pages