Elgato_dark/github
1
0
Fork 0
mirror of https://github.com/phodal/github synced 2026-05-22 08:38:23 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #82 from Bashamega/gh-pages

Browse source 
New Website
This commit is contained in:
Fengda Huang 2024-05-23 20:41:26 +08:00 committed by GitHub
commit 09caa78b22
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
16 changed files with 3714 additions and 3631 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
chapters/01-start-project.md
View file

@ -31,7 +31,7 @@
如下是不同开源许可证的市场占有率及使用情况。
![License 使用情况](./img/permissive-vs-copylift-license-2.jpg)
![License 使用情况](../img/permissive-vs-copylift-license-2.jpg)
又比如，在我们看到的一些外版书籍上，如果拥有代码。那么作者一般就会在前言或者类似的位置里，指明书中代码的版权所属。如：
@ -39,7 +39,7 @@
于是，选择一个合理的 LICENSE，就变成了一个有趣的话题。为此，笔者做了一个如何进行开源协议选型的流程图：
[![如何选择 License](./img/licenses.png)](https://github.com/phodal/licenses)
[![如何选择 License](../img/licenses.png)](https://github.com/phodal/licenses)
简单地来说，这些 License 之间是一些权利的区别，如当你把代码放置到公有领域，就意味着任何人可以修改，并且不需要标明出注；可如果你想要别人标明出处及作者，你就需要 MIT 协议；而你希望别人闭源的话，那么你就需要 MPL 协议等等。

12
chapters/02-github-fundamentals.md
View file

@ -56,11 +56,11 @@ $git status
来看现在的状态，如下图是添加之前的：
![Before add](./img/before-add.png)
![Before add](../img/before-add.png)
下面是添加之后 的
![After add](./img/after-add.png)
![After add](../img/after-add.png)
可以看到状态的变化是从黄色到绿色，即 unstage 到 add。
@ -111,11 +111,11 @@ jQuery[^jQuery] 在发布版本``2.1.3``，一共有 152 个 commit。我们可
接着,我们试试在上面创建一个项目：
![GitHub Roam](./img/github-roam-create.jpg)
![GitHub Roam](../img/github-roam-create.jpg)
就会有下面的提醒：
![GitHub Roam](./img/project-init.jpg)
![GitHub Roam](../img/project-init.jpg)
它提供多种方式的创建方法：
@ -208,10 +208,10 @@ CLA 即 Contributor License Agreement，在为一些大的组织、机构提交
以下是我为 Google 提交的一个 PR
![Google CLA](./img/google-cla.png)
![Google CLA](../img/google-cla.png)
以及 Eclipse 的一个 PR
![Eclipse CLA](./img/eclipse-cla.png)
![Eclipse CLA](../img/eclipse-cla.png)
他们都要求我签署 CLA。

6
chapters/05-create-project-documents.md
View file

@ -9,19 +9,19 @@
通常这个会在项目的最上方会有一个项目的简介，如下图所示：
![GitHub Project Introduction](./img/github-intro.png)
![GitHub Project Introduction](../img/github-intro.png)
## README
README 通常会显示在 GitHub 项目的下面，如下图所示：
![GitHub README](./img/readme-example.png)
![GitHub README](../img/readme-example.png)
通常一个好的 README 会让你立马对项目产生兴趣。
如下面的内容是 React 项目的简介：
![React README](./img/react-intro.png)
![React README](../img/react-intro.png)
下面的内容写清楚了他们的用途：

2
chapters/06-refactor-project.md
View file

@ -335,7 +335,7 @@ public class replaceTemp {
选中 ``basePrice`` 很愉快地拿鼠标点上面的重构
![Replace Temp With Query](./img/replace.jpg)
![Replace Temp With Query](../img/replace.jpg)
便会返回

22
chapters/08-github-marketing.md
View file

@ -33,7 +33,7 @@ Vue 不是因为好用，而一下子火了。这一点我印象特别深，当
除此，还有一种可能是，你的 ID 不够 fancy，即你在社区的影响上比较少。此时，就需要**一点点慢慢积累人气**了。当你积累了一些人气，你就能和松本行弘一样，在创建 mRuby 的时候就有 1000+ 的 Star。并且，在社区上还有一些相关的文章介绍，各个头条也由他的粉丝发了上去。如，一年多以前，我创建了 [mole](https://github.com/phodal/mole) 项目。
![Mole](./img/mole.png)
![Mole](../img/mole.png)
当时，是为了给自己做一个基于 GitHub 云笔记的工具，在完成度到一定程度的时候。我在我的微信公从号上发了相关的介绍，第二天就有 100+ 的 Star 了，还接收到一些鼓舞的话语。对应于国内则有：
@ -60,7 +60,7 @@ Vue 不是因为好用，而一下子火了。这一点我印象特别深，当
GitHub 的 Description 是我们在 Hacking News、GitHub Trneding 等等，第一时间看到的介绍。也是我们能快速介绍给别人的东西，如下图所示：
![GitHub Trending](./img/github-trending-example.png)
![GitHub Trending](../img/github-trending-example.png)
这一句话，必须简单明了也介绍，它是干什么的。
@ -78,7 +78,7 @@ Vue 则是：A progressive, incrementally-adoptable JavaScript framework for bui
> Most machines on internet communicate with each other via TCP/IP. However TCP/IP only guarantees reliable data transmissions, we need to abstract more to build services:
![RPC 开源项目](./img/rpc-example.png)
![RPC 开源项目](../img/rpc-example.png)
以上便是这个项目能解决的问题，不过这个项目能解决的问题倒是比较长，哈哈哈。
@ -86,7 +86,7 @@ Vue 则是：A progressive, incrementally-adoptable JavaScript framework for bui
当我们有 A、B、C 几个不同的框架的时候，作为一个开发人员，就需要对比他们的特性。如下是 Go 语言实现的 MQTT 示例：
![GO MQTT 示例](./img/go-mqtt.png)
![GO MQTT 示例](../img/go-mqtt.png)
这个项目只支持的 Qos 级别为 0。如果我们需要的级别是 1，那么就不能用这个项目了。
@ -101,7 +101,7 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
你会怎么写？脸皮够厚的话，可以直接写一下，与其它项目的对比，blabla：
![对比其它项目](./img/comparison.png)
![对比其它项目](../img/comparison.png)
当然了，这种事不能太过，要不然会招来一堆黑。
@ -131,7 +131,7 @@ app.listen(3000);
好在这里的安装工作只有两步，而不是：
![Lan 安装过程](./img/lan-example.png)
![Lan 安装过程](../img/lan-example.png)
对于那些需要复杂的安装过程的软件，应该简化安装过程，如提供 Docker 镜像，或者直接提供一个可运行的 Demo 环境。以免用户在看完 README 之后，直接放弃了使用该库。
@ -142,7 +142,7 @@ app.listen(3000);
由于，之前在某一个项目，经历过一个第三方 API 文档的大坑——文档中只罗列了 API 的用法。如下 Intellij Idea 生成的结构图：
![API 示例](./img/api-examples.png)
![API 示例](../img/api-examples.png)
文档中上，罗列了每个函数，以及每个函数需要的参数。我使用 Intellij Idea 直接反编译 jar 包，看到的信息都比文档多多了。文档上，没有任务示例，甚至连怎么初始化这个库的代码都没有。
@ -152,7 +152,7 @@ WTF！
对于一个复杂的开源项目来说，文档上要写明安装、编译、配置等等的过程。如下图所示：
![Python Social Auth 文档](./img/python-social-auth-example.png)
![Python Social Auth 文档](../img/python-social-auth-example.png)
并且在我们发布包的时候，就要不断地去重复这个过程——如果你使用了自动化测试，那么这个过程便自动完成了。
@ -160,7 +160,7 @@ WTF！
并且，我们可以将文档直接入到代码里。它可以有效地减少文档不同步，带来的一些问题。
![Lodash 示例](./img/lodash-code-example.png)
![Lodash 示例](../img/lodash-code-example.png)
上图是使用了 JSDoc 的 Lodash 示例。
@ -172,7 +172,7 @@ WTF！
反正，除了一个 hello, world，你还要有各种场景下的示例：
![Redux](./img/redux-examples.png)
![Redux](../img/redux-examples.png)
没有这么多示例，敢说自己是好用的开源项目？
@ -193,7 +193,7 @@ WTF！
这一点可以在 README，以及介绍上体现：
![Feel free to contribute!](./img/feel-free-to.png)
![Feel free to contribute!](../img/feel-free-to.png)
哪怕只是一个错误字的 PR，那么你也可以 merge，啊哈哈~。然后，就有人帮你宣传了，『我给 xxx 项目一个 PR 了』。刚毕业的时候，我也是从这种类型的 PR 做起的~~。

8
chapters/10-git-tools.md
View file

@ -8,7 +8,7 @@ Git 命令行增强
### [diff-so-fancy](https://github.com/so-fancy/diff-so-fancy)
![diff so fancy 截图](./img/git-diff-screenshot.png)
![diff so fancy 截图](../img/git-diff-screenshot.png)
### [git-extras](https://github.com/tj/git-extras)
@ -66,11 +66,11 @@ SourceTree 方便用来查看一些非我写的项目，寻找其中的一些问
gitflow 分支合并、查看
![SourceTree 截图](./img/sourcetree.jpg)
![SourceTree 截图](../img/sourcetree.jpg)
### GitHub Desktop
![GitHub Desktop](./img/github-desktop.jpg)
![GitHub Desktop](../img/github-desktop.jpg)
Git 娱乐
---
@ -132,4 +132,4 @@ Set up your git name and email, this is important so that your commits can be id
### Gource
![Gource 历史](./img/gource.jpg)
![Gource 历史](../img/gource.jpg)

10
chapters/11-analytics.md
View file

@ -10,7 +10,7 @@
最后效果图
![2014 01 01](./img/2014-01-01.png)
![2014 01 01](../img/2014-01-01.png)
要解析的 JSON 文件位于``data/2014-01-01-0.json``，大小 6.6M，显然我们可能需要用每次只读一行的策略，这足以解释为什么诸如 sublime 打开的时候很慢，而现在我们只需要里面的 JSON 数据中的创建时间。。
@ -138,7 +138,7 @@ draw_date("data/2014-01-01-0.json")
继上篇之后，我们就可以分析用户的每周提交情况，以得出用户的真正的工具效率，每个程序员的工作时间可能是不一样的，如
![Phodal Huang's Report](./img/phodal-results.png)
![Phodal Huang's Report](../img/phodal-results.png)
这是我的每周情况，显然如果把星期六移到前面的话，随着工作时间的增长，在 GitHub 上的使用在下降，作为一个
@ -150,7 +150,7 @@ draw_date("data/2014-01-01-0.json")
看一张分析后的结果
![Feb Results](./img/feb-results.png)
![Feb Results](../img/feb-results.png)
结果正好与我的情况相反？似乎图上是这么说的，但是数据上是这样的情况。
@ -446,7 +446,7 @@ pipe.execute()
结果大致如下图所示：
![SMTWTFS](./img/smtwtfs.png)
![SMTWTFS](../img/smtwtfs.png)
看看主要的事件是？
@ -456,7 +456,7 @@ pipe.execute()
[[('PushEvent', 154.0), ('CreateEvent', 41.0), ('WatchEvent', 18.0), ('GollumEvent', 8.0), ('MemberEvent', 3.0), ('ForkEvent', 2.0), ('ReleaseEvent', 1.0)]]
>>>
![Main Event](./img/main-events.png)
![Main Event](../img/main-events.png)
蓝色的就是 push 事件，黄色的是 create 等等。

16
chapters/13-read-code.md
View file

@ -18,11 +18,11 @@
在我阅读的前端库、Python 后台库的过程中，我们都是以造轮子为目的展开的。所以在最开始的时候，我需要一个可以工作，并且拥有我想要的功能的版本。
![it-works-cms.png](./img/it-works-cms.png)
![it-works-cms.png](../img/it-works-cms.png)
紧接着，我就可以开始去实践这个版本中的一些功能，并理解他们是怎么工作的。再用 `git` 大法展开之前修改的内容，可以使用 IDE 自带的 Diff 工具：
![pycharm-diff.jpg](./img/pycharm-diff.jpg)
![pycharm-diff.jpg](../img/pycharm-diff.jpg)
或者类似于 `SourceTree` 这样的工具，来查看修改的内容。
@ -33,7 +33,7 @@
我最早阅读的开源软件是 Linux，而下面则是 Linux 的 Release 过程：
![linux-history.png](./img/linux-history.png)
![linux-history.png](../img/linux-history.png)
表格源自一本书叫《Linux内核0.11(0.95)完全注释》，简单地再介绍一下：
@ -61,25 +61,25 @@
一、先 Clone 它。
![clone-flask.png](./img/clone-flask.png)
![clone-flask.png](../img/clone-flask.png)
二、从 Release 页面找到它的早期版本：
![flask.png](./img/flask.png)
![flask.png](../img/flask.png)
三、 从上面拿到它的提交号 `8605cc3`，然后 checkout 到这次提交，查看功能。在这个版本里，一共有六百多行代码
![flask-0.1.png](./img/flask-0.1.png)
![flask-0.1.png](../img/flask-0.1.png)
还是有点长
四、我们可以找到它的最早版本：
![flask-init.png](./img/flask-init.png)
![flask-init.png](../img/flask-init.png)
然后查看它的 `flask.py` 文件，只有简单的三百多行，并且还包含一系列注释：
![flask-init.png](./img/flask-init.png)
![flask-init.png](../img/flask-init.png)
五、接着，再回过头去阅读

46
chapters/14-streak-your-github.md
View file

@ -5,7 +5,7 @@ GitHub 连击
我也是蛮拼的，虽然我想的只是在 GitHub 上连击 100~200 天，然而到了今天也算不错。
![Longest Streak](./img/longest-streak.png)
![Longest Streak](../img/longest-streak.png)
``在不停地造轮子的过程中，也不停地造车子。``
@ -17,7 +17,7 @@ GitHub 连击
对比了一下 365 天连击的 commit，我发现我在 total 上整整多了近 0.5 倍。
![365 Streak](./img/365-streak.jpg)
![365 Streak](../img/365-streak.jpg)
同时这似乎也意味着，我每天的 commit 数与之相比多了很多。
@ -43,7 +43,7 @@ GitHub 连击
这也就是为什么那个 repo 有这样的一行：
![Repo Status](./img/repo-status.png)
![Repo Status](../img/repo-status.png)
做到 98% 的覆盖率也算蛮拼的，当然还有 Code Climate 也达到了 4.0，也有了 112 个 commits。因此也带来了一些提高：
@ -57,7 +57,7 @@ GitHub 连击
有意思的是越到中间的一些时间，commits 的次数上去了，除了一些简单的 pull request，还有一些新的轮子出现了。
![Problem](./img/problem.jpg)
![Problem](../img/problem.jpg)
这是上一星期的 commits，这也就意味着，在一星期里面，我需要在 8 个 repo 里切换。而现在我又有了一个新的 idea，这时就发现了一堆的问题：
@ -84,7 +84,7 @@ GitHub 连击
今天是我连续泡在 GitHub 上的第200天，也是蛮高兴的，终于到达了：
![GitHub 200 days](./img/github-200-days.png)
![GitHub 200 days](../img/github-200-days.png)
故事的背影是：去年国庆完后要去印度接受毕业生培训——就是那个神奇的国度。但是在去之前已经在项目待了九个多月，项目上的挑战越来越少，在印度的时间又算是比较多。便给自己设定了一个长期的 goal，即 100~200 天的 longest streak。
@ -128,7 +128,7 @@ GitHub 连击
[Google Maps solr polygon 搜索](http://www.phodal.com/blog/google-map-width-solr-use-polygon-search/)
![Google Maps solr](./img/solr.png)
![Google Maps solr](../img/solr.png)
代码：[https://github.com/phodal/gmap-solr](https://github.com/phodal/gmap-solr)
@ -145,7 +145,7 @@ GitHub 连击
- jQuery
- Gulp
![Skill Tree](./img/skilltree.jpg)
![Skill Tree](../img/skilltree.jpg)
代码：[https://github.com/phodal/skillock](https://github.com/phodal/skillock)
@ -159,13 +159,13 @@ GitHub 连击
- Knockout.js
- Require.js
![Sherlock skill tree](./img/sherlock.png)
![Sherlock skill tree](../img/sherlock.png)
代码：[https://github.com/phodal/sherlock](https://github.com/phodal/sherlock)
#### Django Ionic ElasticSearch 地图搜索
![Django Elastic Search](./img/elasticsearch_ionit_map.jpg)
![Django Elastic Search](../img/elasticsearch_ionit_map.jpg)
- ElasticSearch
- Django
@ -176,7 +176,7 @@ GitHub 连击
#### 简历生成器
![Resume](./img/resume.png)
![Resume](../img/resume.png)
- React
- jsPDF
@ -189,7 +189,7 @@ GitHub 连击
#### Nginx 大数据学习
![Nginx Pig](./img/nginx_pig.jpg)
![Nginx Pig](../img/nginx_pig.jpg)
- ElasticSearch
- Hadoop
@ -224,7 +224,7 @@ GitHub 连击
> 给你一年的时间，你会怎样去提高你的水平？？？
![GitHub 365](./img/github-365.jpg)
![GitHub 365](../img/github-365.jpg)
正值这难得的 sick leave（万恶的空气），码文一篇来记念一个过去的 366 天里。尽管想的是在今年里写一个可持续的开源框架，但是到底这依赖于一个好的 idea。在我的 [GitHub 孵化器](http://github.com/phodal/ideas) 页面上似乎也没有一个特别让我满意的想法，虽然上面有各种不样有意思的 ideas。多数都是在过去的一年是完成的，然而有一些也是还没有做到的。
@ -256,9 +256,9 @@ GitHub 连击
在我写 [EchoesWorks](https://github.com/echoesworks/echoesworks) 和 [Lan](https://github.com/phodal/lan) 的过程中，我尽量去保证足够高的测试覆盖率。
![lan](./img/lan.png)
![lan](../img/lan.png)
![EchoesWorks](./img/echoesworks.png)
![EchoesWorks](../img/echoesworks.png)
从测试开始的 TDD，会保证方法是可测的。从功能到测试则可以提供工作次效率，但是只会让测试成为测试，而不是代码的一部分。
@ -295,7 +295,7 @@ GitHub 连击
我在写 [lan](https://github.com/phodal/lan) 的时候，也是类似的，但是不同的是我已经设计了一个清晰的架构图。
![Lan IoT](./img/lan-iot.jpg)
![Lan IoT](../img/lan-iot.jpg)
而在我们实现的编码过程也是如此，使用不同的框架，并且让他们能工作。如早期玩的 [moqi.mobi](https://github.com/echoesworks/moqi.mobi)，基于 Backbone、RequireJS、Underscore、Mustache、Pure CSS。在随后的时间里，用 React 替换了 View 层，就有了 [backbone-react](https://github.com/phodal/backbone-react) 的练习。
@ -341,7 +341,7 @@ GitHub 连击
当然如果你连做梦也在写代码的话，那么我想 500 天就够了，哈哈~~。
![Gtihub 500](./img/github-500.jpg)
![Gtihub 500](../img/github-500.jpg)
虽然不是连击次数最多的，但是根据 [Most active GitHub users ](http://git.io/top) 的结果来说，好似是大陆提交数最多的人，没有之一。再考虑到提交都是有意义的——不是机器刷出来的，不是有意识的去刷，我觉得还是有很大成就感的。
@ -357,7 +357,7 @@ GitHub 连击
如下图所示的就是情绪周期：
![情绪周期](./img/qingxu.jpg)
![情绪周期](../img/qingxu.jpg)
简单地来说，就是**有一个时间段写代码的感觉超级爽，有一个时间段不想写代码**，但是如果换一个说法就是：**有一个时间段看书、写文档的感觉很爽，有一时间段不想看书、写文档的感觉**。这也就是为什么在我的GitHub首页上的绿色各种花。不过因为《物联网周报》的原因，我会定期地更新一个相关的开源项目。
@ -376,7 +376,7 @@ GitHub 连击
在一些日子的练习后，我发现这还是太无聊了。天生就喜欢一些有意思的东西，有趣才更有激情吧~~。不过，像下图的打字练习还是挺有意思的：
![打字练习](./img/huovd.png)
![打字练习](../img/huovd.png)
还是能打出了一堆错误的字符。但是对比了一下大多数人的人，还算不错，至少是盲打。但是，还是存在着很大的提升空间。
@ -412,7 +412,7 @@ THE ONLY FAIR IS NOT FAIR . ENJOY CREATE & SHARE.
而这些并不是一种容易的事，很多时候有一些模式，我们都很难有一个好的实践。只是这些东西都不是一些可以生搬硬套的，我们更需要的是知道有这些东西的存在，以便于在某一天，我们可以从我们的仓库里将这些知识取出来。
![10000 hours](./img/10000.png)
![10000 hours](../img/10000.png)
我们的刻意练习加上我们的持之以恒总是会取得长足的进步。不过在我们练习之前，你需要有一个目标。这个目标可以是一个 Idea、一个设计模式、一个模仿等等，这些内容都可以以 Issue 的好好管理着。
@ -425,7 +425,7 @@ THE ONLY FAIR IS NOT FAIR . ENJOY CREATE & SHARE.
通常在这种情况下，我们知道自己不知道什么东西，当我们处于不知道自己不知道、不知道自己知道时，那我们就需要网上的各种技能图谱——如StuQ的技能图谱。
![skilmap](./img/skillmap.png)
![skilmap](../img/skillmap.png)
然后了解图谱上的一个个的内容，尽可能依照此构建自己的体系——以让自己走向知道自己不知道的地步，然后我们才依此来展开练习。
@ -437,7 +437,7 @@ THE ONLY FAIR IS NOT FAIR . ENJOY CREATE & SHARE.
时间：2014.10.08-2014.12.30
![2014.png](./img/2014.png)
![2014.png](../img/2014.png)
在这一段时间里，我创建的项目大部分都是一些物联网项目：
@ -458,7 +458,7 @@ OnMap 项目是为了让我用 Nokia Lumia 920 拍照的照片，可以在地图
#### 2015年
![2015.png](./img/2015.png)
![2015.png](../img/2015.png)
整个区间就是刷各种前端的技术栈，创建了各种有意思的项目：
@ -478,7 +478,7 @@ OnMap 项目是为了让我用 Nokia Lumia 920 拍照的照片，可以在地图
#### 2016 年
![2016.png](./img/2016.png)
![2016.png](../img/2016.png)
我们有了 Growth 系列的电子书、App，还有 Mole，几个极具代表性的项目就够了。

10
chapters/18-get-star.md
View file

@ -34,7 +34,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有
因此开始之前，我们先看张图就能知道怎么获取流量。如下是《GitHub 漫游指南》最近两周内的流量来源统计（GitHub 通过 Google Analysis 来统计）：
![GitHub 漫游指南](./img/github_traffic.png)
![GitHub 漫游指南](../img/github_traffic.png)
从上图中可以看出，流量主要来源于几部分：
@ -46,7 +46,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有
总的来说，在这一周里，累计有 1,266 次访问，其中有 735 个独立访客。看这数据不错，而实际上 Star 率 就有点低。根据 Star History 网站（https://star-history.t9t.io ） 的统计，在过去的近两个月里，才涨了 38 个 Star。
![GitHub 漫游指南 Star 历史](./img/github-star-history.png)
![GitHub 漫游指南 Star 历史](../img/github-star-history.png)
从我的分析来看，大抵原因有两个：
@ -55,7 +55,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有
而我最近在玩的 New Project Checklist（[https://github.com/phodal/new-project-checklist](https://github.com/phodal/new-project-checklist) 的转化率看上去，还算可以：
![GitHub New Project Checklist](./img/github-new-project-checklist.png)
![GitHub New Project Checklist](../img/github-new-project-checklist.png)
在 999 个独立访客里，获得了 202 个 Star，转化率差不多是 20%——大家真的对这个项目感兴趣。
@ -73,7 +73,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有
实际上，在上一小节里，我们已经介绍了相关的内容。若是想获得来自于 Google 等搜索引擎的访问，那么要掌握的技巧有：
![Google New Project Checklist](./img/google-new-project-checklist.png)
![Google New Project Checklist](../img/google-new-project-checklist.png)
- 简单实用的项目名。项目名在 Google 搜索结果里是放在最前面的部分，它与 URL 同在。
- 写好项目的 ``Description``。不管怎样，你一定要为你的项目写好 Description，让看到的人知道它在做什么。
@ -107,7 +107,7 @@ GitHub 是一个人的简历，**而开源项目的 README，就好像是一个
**更新状态**。当我在写一个大家感兴趣的开源项目时， 我会在我的社交账号上，如微博、知乎想法，定期的更新相关的状态。诸如：
![微博 MoPass](./img/mopass-weibo.png)
![微博 MoPass](../img/mopass-weibo.png)
万一有人感兴趣，就会随之而来——主要是我也不知道微博要怎么玩。

21
chapters/_sidebar.MD Normal file
View file

@ -0,0 +1,21 @@
- [Home Page](/)
- [01 introduction](/01-introduction.md)
- [01 start project](/01-start-project.md)
- [02 github fundamentals](/02-github-fundamentals.md)
- [03 build github project](/03-build-github-project.md)
- [04 commit message](/04-commit-message.md)
- [05 create project documents](/05-create-project-documents.md)
- [06 refactor project](/06-refactor-project.md)
- [07 tdd with autotest](/07-tdd-with-autotest.md)
- [08 github marketing](/08-github-marketing.md)
- [09 maintain project](/09-maintain-project.md)
- [10 git tools](/10-git-tools.md)
- [11 analytics](/11-analytics.md)
- [12 find github project](/12-find-github-project.md)
- [13 read code](/13-read-code.md)
- [14 streak your github](/14-streak-your-github.md)
- [15 milestone](/15-milestone.md)
- [16 find in github](/16-find-in-github.md)
- [18 get star](/18-get-star.md)
- [19 joke](/19-joke.md)
- [999 faq](/999-faq.md)

18
chapters/generate.py Normal file
View file

@ -0,0 +1,18 @@
#This file is for generating the _sidebar.MD
import os
# Get the current directory
current_dir = os.getcwd()
# List all files in the current directory
files = os.listdir(current_dir)
# Filter out only the markdown files
md_files = [file for file in files if file.endswith('.md')]
# Write the names of the markdown files
with open('_sidebar.md', 'w') as sidebar_file:
sidebar_file.write("- [Home Page](/)\n")
for md_file in md_files:
if md_file != "readme.md" and md_file != '_sidebar.md':
sidebar_file.write("- [" + md_file.replace('-', ' ').replace('.md', '') + "](/" + md_file +")\n")

4
chapters/00-prelude.md → chapters/readme.md
View file

@ -38,7 +38,7 @@
我的微信公众号：
![作者微信公众号：phodal-weixin](./img/wechat.jpg)
![作者微信公众号：phodal-weixin](../img/wechat.jpg)
我的 GitHub 主页上写着加入的时间——``Joined on Nov 8, 2010``，那时才大一，在那之后的那么长的日子里我都没有登录过。也许是因为我学的不是计算机，到了今天——``2015.3.9``，我才发现这其实是程序员的社交网站。
@ -68,7 +68,7 @@
当然，后来是审阅完了，书上有我的英文简介。
![Phodal Huang Introduction](./img/phodal-intro.jpg)
![Phodal Huang Introduction](../img/phodal-intro.jpg)
一个月前，收到 MANNING 出版社的邮件（PS：也是在 GitHub 上），关于 Review 一本[物联网](iot)书籍的目录，并提出建议。

3600
index.html
View file

File diff suppressed because it is too large Load diff

3566
website_old/index.html Normal file
View file

File diff suppressed because it is too large Load diff

0
style.css → website_old/style.css
View file