View source for DPS909/OSD600 Fall 2017 Lab 6/7

==Introduction: GitHub Repos and Pull Requests==

This lab is all about practicing the [https://wiki.cdot.senecacollege.ca/wiki/DPS909_%26_OSD600_Fall_2017#Week_6 git/GitHub workflow we discussed on Tuesday].  By the end of this lab, you will have successfully done the following:

* Created a new repo for a project
* Written new code, committed it locally, and pushed it to GitHub
* Contributed a Pull Request to another student's repo
* Reviewed and Merged a Pull Request from another student to your repo

This process will give you some exposure to the entire process of creating, maintaining, and contributing to an open source project.

We'll spend a couple weeks doing this lab, so take your time and don't rush this learning.

'''If you have trouble with any of the steps below, or need help, please use our Slack channel to ask your questions.  Don't suffer in silence.'''

==Step 1: Design a Library for Obtaining File Info==

You are asked to create a new open source library.  A library/package/module/etc is a collection of functionality that can be used by an application developer to accomplish a set of tasks.  NOTE: I don't need you to write a full application; just a library of functions.

The purpose of this library is to make it easy to get various pieces of info about a given file on disk.  You will write functions in your library that return the following:

* filename without path.  For example: given a path like <code>"/home/kim/mydata.txt"</code>, return <code>"mydata.txt"</code>
* file size in bytes.  For example, given a path like <code>"/home/kim/mydata.txt"</code>, return <code>129</code> (e.g., the file is 129 bytes on disk)
* [https://en.wikipedia.org/wiki/SHA-1 sha1 digest] for a file at the given path.  For example, given a path like <code>"/home/kim/mydata.txt"</code>, which contains the text <code>The quick brown fox jumps over the lazy dog</code>, return <code>2fd4e1c67a2d28fced849ee1bb76e7391b93eb12</code>
* [https://en.wikipedia.org/wiki/MD5 MD5 digest] for a file at the given path.  For example, given a path like <code>"/home/kim/mydata.txt"</code>, which contains the text <code>The quick brown fox jumps over the lazy dog</code>, return <code>9e107d9d372bb6826bd81d3542a419d6</code>

There are various online tools you can use to generate digests for SHA-1 and MD5 while testing, for example http://www.sha1-online.com/.

==Step 2: Pick a Language==

You can write your library in any language you want.  Consider choosing a language you don't usually use, or have never used before and want to learn.  Challenge yourself to learn something new, and push yourself out of your comfort zone.  You aren't being marked on the quality of your code, this is just a learning exercise.  Here are some suggestions:

* JavaScript (or TypeScript) and node.js
* Python
* Rust
* Go
* Swift

When you choose your language, remember that you are going to need to convince another student to contribute to your repo, and shouldn't pick something that no other developer uses or wants to learn.  This is true of all open source projects.  Choose wisely!

NOTE: GitHub [https://twitter.com/mikeal/status/918177036430118913 published numbers on language popularity yesterday].

==Step 3: Pick a License==

Pick a license for your project.  You can use any open source license you want.  Be careful what you choose, since you don't want to limit your ability to use existing code (e.g., make sure you pick something that can be combined with other open source licenses).

If you're not sure what to pick, consider using BSD, MIT, or Apache.

==Step 4: Look for Existing Modules/Libraries/Packages to Help==

You can use any existing open source code that will help you write your library.  For example, if you can find a module that already implements the MD5 digest algorithm, use it.  Don't write any code you don't have to, don't reinvent the wheel.

Make sure that any open source code you choose is compatible with the license you've chosen.  You may need to adjust your license or language choice depending on what you find.

==Step 5. Create a Repo on GitHub==

Follow the [https://help.github.com/articles/create-a-repo/ instructions on GitHub to create a repo] for your library.  Make sure you choose a name that hasn't already been used by another project, company, or product.  Try doing a Google search before you settle on your name.

==Step 6. Clone your Repo Locally==

[https://help.github.com/articles/fork-a-repo/#step-2-create-a-local-clone-of-your-fork Clone your repo] on your local computer.

==Step 7. Plan your Library by Filing Issues==

Begin by planning your work as a series of Issues in GitHub.  Each issue should be small enough to capture a single feature, improvement, or task.  For example, you might file issues for each of the main functions of your library.  You might also choose to break those down into a smaller issues.  Do what feels right for you.  Fixing many small bugs is often easier than a few large ones.

==Step 8. Start coding==

Now that you have issues filed, pick one and start coding it.  Remember to do each fix on a separate branch.  Once you get a feature finished, and you're happy with it, you can <code>merge</code> it into your <code>master</code> branch.  Here's an example of what this might look like:

<pre>
git checkout -b issue-1
...write the code...
git add <filename>
git commit -m "Fix #1: Added code to do feature X"
git checkout master
git merge issue-1
</pre>

==Step 9. Publish your master branch==

When you've got a few of your bugs fixed and merged into <code>master</code>, it's time to publish your work on GitHub.  To do this, you want to <code>push</code> your <code>master</code> branch:

<pre>
git checkout master
git push origin master
</pre>

Now visit your GitHub repo and make sure you can see your commits, and the code you've written.  If anything looks wrong, do another commit to fix it, and push again.

==Step 10. Invite people in the Class to Contribute==

When you're ready to have people contribute to your project, add your '''name''' and GitHub Repo '''URL''' to the table below.  File any additional '''Issues''' in your project repo on GitHub for things you'd like help doing (see suggestions in step 11 below).  You can also use the Slack channel to tell people about your project, and how they can get involved.

==Step 11. Contribute to Another Project==

In addition to creating and maintaining your own library, you are asked to contribute to at least one other project in the class.  You can work on a different language than you wrote your own project using, and are free to work with anyone in the class (e.g., don't limit yourself to people you know).

Here are some suggestions of things you could do:

* Write the README.md file, with instructions on how to setup and use the library
* Add automated tests (e.g., unit tests) to make sure the library does what it's supposed to do
* Add automated code quality checks (e.g., linting) to help find bugs before they happen
* Add a build system to make it easier to perform common tasks (e.g., build or minify the code, run tests, do various checks)  
* Write a simple command line tool shows an example of how you use the library 
* Improve the code to make it cleaner, faster, or more simple (e.g., remove duplication, add documentation)
* Test the code and fix a bug if there are any.  Does the code do the right thing in all cases?  What happens if you give it data that's different from how the original author wrote it (e.g., run the code on macOS or Linux instead of Windows)?

Before you contribute to another project, make sure there is either an existing bug, or file one yourself.  Make sure the project owner knows you're working on this issue.

Next, <code>fork</code> and <code>clone</code> their repo.  Create a <code>branch</code> for the issue you're fixing, make your changes, <code>add</code>, and <code>commit</code>.  Then <code>push</code> your branch to your <code>fork</code>.

Finally, create a [https://help.github.com/articles/about-pull-requests/ Pull Request] for your change.  In your Pull Request's description, make sure you use the pattern <code>Fix #...: ...</code> to have GitHub automatically close the associated issue when your Pull Request is merged.  For example, if you are working on Issue 14, you might say, <code>Fix #14: add md5 unit test</code>.  Also include a useful discussion of what you've done, how to test it, etc.

==Step 12. Code Review==

Every Pull Request will need to be reviewed by the project maintainer.  When someone submit a Pull Request to your repo, you'll get an email.  You should go and read their code, and make any suggestions for how you want it to be fixed (if necessary).  Remember that as a maintainer, it's your job to help new contributors feel welcome and valued in your project--you want them to stick around and fix more bugs.

When you submit your own Pull Request, if there are changes requested, please make them and then <code>commit</code> and <code>push</code> your branch again.  Any new commits will get added to the pull request.  You should let your reviewer know when you've added more commits so that he/she can go and re-review your work.

When everything is complete, the maintainer will [https://help.github.com/articles/merging-a-pull-request/ merge the pull request].  When this happens, the commits on the branch will get added to <code>master</code>.  The maintainer should then <code>pull</code> these commits to their local cloned repo:

<pre>
git checkout master
git pull origin master
</pre>

==Step 13. Record your Contribution(s)==

Once you've submitted one or more Pull Requests, make sure you add links in the table below beside your name. 

==Step 14. Blog==

Write a blog post about your experiences in this lab.  In particular, discuss each of the following:

* Why did you choose the language you chose?  What did you think of it?  Would you use it again?
* Were you able to find any existing open source code that you could re-use?  How did that go?  Did you have any technical or licensing issues?
* What was it like contributing to another project?
* What was it like having people contribute to your project?
* Did you learn anything during your own experience as a maintainer or contributor that will impact you when you do this again?
* Did you run into any issues with git as you managed your project?  What did you learn in the process, and what do you still need to learn more about?

==Submission==

{| class="wikitable"
! style="font-weight: bold;" | #
! style="font-weight: bold;" | Name
! style="font-weight: bold;" | GitHub Repo (URL)
! style="font-weight: bold;" | Contribution Pull Request(s) (URLs)
! style="font-weight: bold;" | Blog Post (URL)
|-
| 1
| Joshua Longhi
| https://github.com/josh0588/go-file-utils
| https://github.com/ajlomagno/File-Info-Tool/pull/3
| https://wordpress.com/post/jlonghiblog.wordpress.com/419
|-
| 2
|Marco Beltempo
|https://github.com/marcobeltempo/fileside
|https://github.com/SeanPrashad/Lust/pull/10
|https://www.marcobeltempo.com/open-source/git-workflow/
|-
| 3
|Nicholas Krause
|https://github.com/xerofoify/Python-File-Utils/tree/master
|https://github.com/xerofoify/Python-File-Utils/pull/6
|https://nicholas95com.wordpress.com/
|-
| 4
|Phil Henning
|https://github.com/PhillypHenning/lab8 /*--Created new repo by mistake --*\
|https://github.com/PhillypHenning/file-extractor/pulls?q=is%3Apr+is%3Aclosed
|https://bluesockphil.wordpress.com/2017/10/17/839/
|-
| 5
|Michael Pierre
|https://github.com/MPierre9/FileInfo
|https://github.com/marcobeltempo/fileside/pull/6#event-1301937198
|https://michaelpierreblog.wordpress.com/2017/10/20/working-with-git-and-github/
|-
| 6
|Haoyu Yang
|https://github.com/feihaozi77/BuildingJSLibrary
|https://github.com/GauravV-02/JS-Extractor/pull/7
|https://haoyu1337.blogspot.com/2017/11/dps909-lab67.html
|-
| 7
| Dan Epstein
| https://github.com/Securter/FileInfoFinder
| https://github.com/mmBabol/file-info/pull/5
| http://www.danepstein.ca/lab_6_7/
|-
| 8
| Anthony LoMagno
| https://github.com/ajlomagno/File-Info-Tool
| https://github.com/josh0588/go-file-utils/pull/5
| https://anthonylomagno.wordpress.com/2017/11/25/lab-6-7-my-own-open-source-project/
|-
| 9
| Mat Babol
| https://github.com/mmBabol/file-info
| https://github.com/feihaozi77/BuildingJSLibrary/pull/5
| http://mmbabol.blogspot.ca/2017/10/my-first-pull-request.html
|-
| 10
|Sean Prashad
|https://github.com/SeanPrashad/Fiffy
|https://github.com/MPierre9/FileInfo/pull/7, https://github.com/xerofoify/Python-File-Utils/pull/5
|https://medium.com/seanprashad/git-gud-7394d93f1781
|-
| 11
|Earle White
|https://github.com/5earle/File_Info
|https://github.com/5earle/File_Info/issues/3
|https://ewhite7blog.wordpress.com/2017/10/19/creating-a-github-library/
|-
| 12
|Svitlana Galianova
|https://github.com/svitlana-galianova/FileInfo/
|https://github.com/josh0588/go-file-utils/pull/6
|http://svitlanagalianova.blogspot.ca/2017/10/my-experience-in-github.html
|-
| 13
|Gaurav Verma
|https://github.com/GauravV-02/JS-Extractor
|https://github.com/josh0588/go-file-utils/pull/7
|https://gblogs2017.wordpress.com/2017/11/03/learning-github/
|-
| 14
|Harshkumar Patel
|https://github.com/Vasusena/libfilecheck
|WIP
|WIP
|-
| 15
|Mithilan Sivanesan
|https://github.com/Mithilan16/GoLangFileUtils
|https://github.com/MPierre9/FileInfo/pull/8
|https://mithilanblog.wordpress.com/2017/11/04/ready-set-go/
|-
| 16
|Ojavi Hewitt
|https://github.com/ojhew/dsplib
|WIP
|WIP
|-
| 17
|Joao Rodrigues
|https://github.com/jmrodriguesgoncalves/filepy
|https://github.com/GauravV-02/JS-Extractor/pull/8
|https://jmrodriguesgoncalves.blogspot.ca/2017/11/lab-67-github-stuff.html
|-
| 18
| Jay Yin
| https://github.com/jayyyin/python-filelib-thingy
| https://github.com/jayyyin/python-filelib-thingy/pulls?q=is%3Apr+is%3Aclosed
| http://jyopensource.blogspot.ca/2017/11/building-python-library-for-returning.html
|-
| 19
| Leonel Jara
| https://github.com/lejara/easy-python-file-utils
| https://github.com/jayyyin/python-filelib-thingy/pull/9
| https://lejara.wordpress.com/2017/11/29/making-a-simple-libaray-using-python-on-github/
|-
| 20
| Teddy Prempeh
| https://github.com/teddypee/File_Info
| https://github.com/teddypee/File_Info/issues
| https://teddyprempeh.wordpress.com/2017/11/27/creating-a-github-library/
|-
| 21
| Steven De Filippis
| https://github.com/St3v3n-D/file_info_lib
| https://github.com/Vasusena/libfilecheck/pull/2
| https://dps909.defilippis.ca/index.php/2017/11/28/files-git-issues-and-pulls/
|-
| 22
| Marvin Sanchez
| https://github.com/msanchez5/DestinyFileIO
| https://github.com/xerofoify/Python-File-Utils/pull/6
| marvinrsanchez.wordpress.com/maximizing-the-use-of-git-python
|-
| 23
|Fateh Sandhu
|https://github.com/Fatehsandhu/DPS-OpenSource
|https://github.com/msanchez5/DestinyFileIO/pull/6
|https://firefoxmacblog.wordpress.com/2017/11/30/my-contribution/
|-
| 24
|Avedis Zeitounilian
|https://github.com/Avedis777/OpenSourceLabs
|https://github.com/xerofoify/Python-File-Utils/pull/7
|http://avedis777.blogspot.ca/2017/11/creating-my-first-repo.html
|-
| 25
|Jiel Selmani
|https://github.com/jselmani/Extractor
|DNC
|https://www.jielselmani.me/blog/2017/11/22/repo-repo-on-the-wall
|-
| 26
|Eric Schvartzman
|https://github.com/ericschv/node-extract-file-info
|
|
|-
| 27
|Hans van den Pol
|https://github.com/HansvandenPol/FileFunctions
|WIP
|https://opensourcetoronto.wordpress.com/2017/12/07/writing-my-first-library/
|-
| 28
|Azusa Shimazaki
|https://github.com/azusaaz/WhatsTheFile
|https://github.com/msanchez5/DestinyFileIO/pull/10
|http://assmith2017.blogspot.ca/2017/12/dealing-with-git-hub-part1.html
|-  
| 29
|Parthkumar Patel
|https://github.com/ppatel221/xtractor
|https://github.com/teddypee/File_Info/pull/7
|https://ppatel221.wordpress.com/2017/12/12/taming-the-beastgit/
|-
| 30
|Hadi Saeed
|https://github.com/hadialshakhori/python
|
|https://techbreaksblog.wordpress.com/2017/12/13/getting-started-with-python/
|-
| 31
| Arpit Gandhi
| https://github.com/aagandhi1/FileCheck
| https://github.com/Vasusena/libfilecheck/pull/5
|
|-
| 32
| Eric Suarez
| https://github.com/ericsuhn/jsfile-utils
| https://github.com/Mithilan16/GoLangFileUtils/pull/6
| https://esoscode.wordpress.com/2017/12/30/working-with-github/
|-
| 33
|
|
|
|
|-
| 34
|
|
|
|
|-
| 35
|
|
|
|
|-
| 36
|
|
|
|
|-
| 37
|
|
|
|
|-
| 38
|
|
|
|
|-
| 39
|
|
|
|
|-
| 40
|
|
|
|
|}