Udacity的Machine Learning納米學(xué)位課程中，關(guān)于Github的筆記。

聽(tīng)課范圍：
Github Profile
Git 和 Github
Readme

Profile
Readme
Commit
Contribute to open source community

課程聽(tīng)了一半，筆記繼續(xù)更新，有待排版。

show your work and how you work

照片
twiter，個(gè)人博客

recruiter最先看的是這里，看你有多活躍，幾乎每天都會(huì)coding。

點(diǎn)進(jìn)一個(gè)最popular的contribution的repository，可以看到scott做了最多的貢獻(xiàn)，寫(xiě)了大部分代碼。

頁(yè)首加了get hub page for this library。

readme是repository里最重要的部分之一。
便于其他人閱讀和使用代碼。

comments里面可以加入版本的說(shuō)明，feature增加的說(shuō)明等。

hiring manager的職責(zé) figure out what attributes do value in engineers。

第一要看的，就是活躍熱圖，看綠色的分布，看這個(gè)人是否熱愛(ài)編程。是否經(jīng)常做貢獻(xiàn)，不需要總是在編程，但至少會(huì)有比較穩(wěn)定的趨勢(shì)。

接下來(lái)看這個(gè)人建立的repository，和他貢獻(xiàn)過(guò)的repository。
挑一個(gè)最豐富的repo，花一個(gè)小時(shí)去讀他們的code，從而看出他們是什么樣的工程師。
也會(huì)看他是否在其它repo中有貢獻(xiàn)，看他怎樣和別人互動(dòng)，協(xié)作，討論。

寫(xiě)readme

便于自己記憶code，回頭再看看你寫(xiě)過(guò)的代碼，你是否還記得你當(dāng)時(shí)是怎么想的嗎，是否還記得你當(dāng)時(shí)為什么做了這些決定嗎，便于別人使用，便于別人協(xié)作。

看如何使用這個(gè)code，有沒(méi)有example，如果沒(méi)有好的document，別人就會(huì)轉(zhuǎn)向其它更方便的library，如果非要讀這樣的code，就會(huì)花費(fèi)很多時(shí)間，

Paste_Image.png

https://github.com/thoughtbot/factory_girl
https://github.com/zkat/can.viewify
https://github.com/udacity/create-your-own-adventure

項(xiàng)目簡(jiǎn)介，Description
其它文檔，Documentation
安裝，Install
額外信息：Contribution，當(dāng)你想讓別人更方便地加入進(jìn)來(lái)，或者Issue
License

看下面這個(gè)例子
https://github.com/github/ledbetter

readme需要提供給user足夠的信息以便于up and running your code

題目
描述：一兩句，清楚并且精準(zhǔn)地描述項(xiàng)目的精髓

Installation, common Usage, known Bugs
readme的長(zhǎng)短取決于你的項(xiàng)目，沒(méi)有必須的要求，只需要提供給使用者必要的信息。

copyright和licensing information，或者link。
下面這個(gè)網(wǎng)站，可以學(xué)習(xí)如何選license。
http://choosealicense.com/
這里有關(guān)于license的指南，
https://github.com/blog/1530-choosing-an-open-source-license
這里可以告訴你為什么要選license，以及不選license的情況：
https://help.github.com/articles/open-source-licensing/

建立license很簡(jiǎn)單：

提供一下已經(jīng)知道的bug，這樣用戶就不用發(fā)愁為什么他的code無(wú)法成功運(yùn)行。

用markdown寫(xiě)readme，易讀，而且排版容易。
Github，Stack Overflow，Slack，Reddit

Here's a link to the basic Markdown documentation. You can also check out the differences in GitHub flavored Markdown here.

github中常用markdown命令
加粗
Isn't today a wonderful day?
斜體
And in that moment I thought to myself: Did I turn off the stove?
代碼
You should use the strong tag.
標(biāo)題

This is an h2.

Working with .md
Files
Much like how your HTML files should be saved with a .html
extension, your Markdown files should be saved with a .md
extension.
Markdown itself can't be opened in the browser like an HTML document. If you want to preview your Markdown files, Dillinger is a great online resource for you to do so.
If you are using Sublime Text, there is a plugin you can download to let you preview Markdown files right on your computer. If you are using Atom text editor, Markdown preview is baked right into the program (in the 'Packages' menu).

Here's a link to the basic Markdown documentation. You can also check out the differences in GitHub flavored Markdown here.
To preview Markdown in the browser, try Dillinger.

什么那個(gè)不好用，下面這個(gè)好用
http://dillinger.io/

well formatted commit messages

讓別人知道，為什么這里有這樣的code，何時(shí)做了怎樣的修改。
方便別人解讀，使用，維護(hù)你的代碼。
hiring manager會(huì)看這個(gè)人有多么地擅長(zhǎng)溝通，傳遞。

Udacity上的例子
http://udacity.github.io/git-styleguide/

The first line is the subject.This should be a short description of what changed.should be 50 characters or less, with the first letter capitalized, and end without a period. At Udacity, we also include a short annotation about the type of the commit, if it is a bug fix, a feature, change to the documentation, etc.

The body is next, this is where you give a more detailed description of why you made the change. The body should typically have around 72 characters per line. This is to ensure that the message fits into a terminal window when using git on the command line. You’ll also need to make sure there is a blank line between the subject line and the body.

Some commits don’t require a body in the message. If you fix a typo for example, it’s okay to only have a subject line.
You can also include a footer, typically this will be used to indicate which issues or bugs the commit addresses.

This does come with an exception of course. If you are working on an open source project, be sure to follow the message format for that project. This will make the maintainers happy and increase the chance your pull request is accepted.

從你的代碼里可以看出，你是否善于協(xié)作，喜歡幫助別人，并且熱愛(ài)編碼。
面試官是怎么樣從你的github上看出你是個(gè)好的協(xié)作者的，在一個(gè)團(tuán)隊(duì)里是如何表現(xiàn)的。
看他們參與的repo里的issue，
是否在on po requests里評(píng)論，
看他們?nèi)绾闻c其它工程師互動(dòng)。
看他們是否有耐心對(duì)待剛進(jìn)入這個(gè)社區(qū)的成員，
找找是否有internet relay chat關(guān)聯(lián)于這個(gè)repo，
看log，看他們是否helpful，kind，patient。

作為hiring manager，你想向new programmer提些什么建議，關(guān)于他們?cè)趨⒓觕ontribute to很大很復(fù)雜的開(kāi)源項(xiàng)目中。
break the ice in a new project,
找文檔看，readme，clone the project，try to build it, try to get it running, follow the steps in readme.
try to clarify some problems I have, submit a poll request with a few changes in the readme.
just move on to fix the bugs, and maybe actually contributing the features.

如何為開(kāi)源項(xiàng)目做貢獻(xiàn)

Github
https://guides.github.com/activities/contributing-to-open-source/
找一些最喜歡的開(kāi)源的library，pandas：
https://docs.google.com/document/d/1ULcO23Edlydaf82zycRdSWHKUme5pmNnC4OoMefIZ-c/pub

python: pandas, numpy, scipy, seaborn, scikit-learn, orange, nltk
r: dplyr, ggplot come to mind
also 'stan' for r
pymc for python as well.
http://www.datakind.org/
http://databits.io/ for data and data vis related competitions
https://www.kaggle.com/ - Kaggle is a platform for data prediction competitions. Companies, organizations and researchers post their data and have it scrutinized by the world's best statisticians.

讀documentation，不會(huì)的問(wèn)題就create issue，尋求幫助。
創(chuàng)建issue，這個(gè)項(xiàng)目的，也可以是你自己的，
要nice，都是public的，
最好的contribution方式，就是improve the documentation。

check list
https://docs.google.com/document/d/1a9AKnNyqfGgdQV5ohPCN5H9ntnEUhMptWMwVBWURCN0/pub?embedded=true

GitHub Profile Checklist

General
I’ve uploaded at least four projects to GitHub.
I’ve verified that my account shows knowledge about how to make incremental commits.

For the last two weeks, I’ve made and pushed some sort of commit, no matter how small, to repo(s) each day.

Personal Profile
I have a professional GitHub name. If at all possible this GitHub name is my own name.
I have a professional profile photo (recommended to be a photo of yourself, but could also be stylized).
My profile is up to date.
Profile includes at least one up-to-date links for: 'URL' and/or 'Company' fields and/or ‘Contact Email’ and current location.

Projects
I have starred at least one repository I’d like to keep track of.

My projects have meaningful names.

My projects have a completed README that says what the purpose of the project is, any instructions about how to use or view it, and what kind of collaboration is sought.

Not all forked repos/changes require modifications to the README, especially when contributing upstream to another's project (would need to be a substantial change). All changes should be documented with commit messages to explain the changes.

The last commit I made to a project matched the commit style guide I chose. If I did not follow the Udacity git commit style guide, then I have included a link to the guide I did use to show consistency.

career resource

http://career.udacity.com/resource-center/contributing_open_source.html

end