Merge pull request phodal#22 from phylee/gh-pages

phodal · web-flow · commit 49ad88bd1c1a · 2018-01-11T07:44:02.000+08:00
Fix some typos
diff --git a/chapters/02-github-fundamentals.md b/chapters/02-github-fundamentals.md
@@ -183,7 +183,7 @@ C | 2
 
 ### 我的第一个PR
 
-我的第一个PR是给一个小的Node的CoAP相关的库的Pull Request。原因比较简单，是因为它的README.md写错了，导致我无法办法进行下一步。
+我的第一个PR是给一个小的Node的CoAP相关的库的Pull Request。原因比较简单，是因为它的README.md写错了，导致我无法进行下一步。
 
 		 const dgram       = require('dgram')
 		-    , coapPacket  = require('coap-packet')
diff --git a/chapters/04-commit-message.md b/chapters/04-commit-message.md
@@ -58,7 +58,7 @@ Git 提交信息及几种不同的规范
 
 与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。
 
-因此，这里以做得比较好的开源项目 Angular 中为例展示。Angular 团队建议采用以下的形式：
+因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式：
 
 ```
 <type>(<scope>): <subject>
diff --git a/chapters/06-refactor-project.md b/chapters/06-refactor-project.md
@@ -4,21 +4,19 @@
 
 有一天，我发现当我需要我一次又一次地重复讲述某些内容，于是我就计划着把这些应该掌握的技能放到GitHub上，也就有了[Artisan Stack](https://github.com/phodal-archive/artisanstack.github.io) 计划。
 
-每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是是手工人。
-
-艺，需要有创造性的方法。
+每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是手工艺人，需要有创造性的方法。
 
 ## 为什么重构?
 
 > 为了更好的代码。
 
-在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而，你重写那几十代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
+在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而你重写那几十行代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的Bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
 
 > 写代码容易，读代码难。
 
 假设我们写这些代码只要半天，而别人读起来要一天。为什么不试着用一天的时候去写这些代码，让别人花半天或者更少的时间来理解。
 
-如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试，``没有测试的重构``。
+如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试``没有测试的重构``。
 
 从前端开始的原因在于，写得一坨坨且最不容易测试的代码都在前端。
 
@@ -50,7 +48,7 @@ while ((stra = micromarkdown.regexobject.mail.exec(str)) !== null) {
 }
 ```
 
-选这个做重构的开始，不仅仅是因为之前在写[EchoesWorks](https://github.com/phodal/echoesworks)的时候进行了很多的重构。而且它更适合于，``重构到设计模式``的理论。让我们在重构完之后，给作者进行pull request吧。
+选这个做重构的开始，不仅仅是因为之前在写[EchoesWorks](https://github.com/phodal/echoesworks)的时候进行了很多的重构。而且它更适合于``重构到设计模式``的理论。让我们在重构完之后，给作者进行pull request吧。
 
 Markdown的解析过程，有点类似于``Pipe and Filters``模式(架构模式)。
 
diff --git a/chapters/08-github-marketing.md b/chapters/08-github-marketing.md
@@ -103,7 +103,7 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
 
 ![对比其它项目](./img/comparison.png)
 
-当然了，这种事不能太过，要不是会招来一堆黑。
+当然了，这种事不能太过，要不然会招来一堆黑。
 
 ### 安装及hello, world 示例
 
diff --git a/chapters/13-read-code.md b/chapters/13-read-code.md
@@ -36,19 +36,21 @@
 ![linux-history.png](./img/linux-history.png)
 
 表格源自一本书叫《Linux内核0.11(0.95)完全注释》，简单地再介绍一下：
+
 - 版本0.00是一个hello,world程序
 - 版本0.01包含了可以工作的代码
 - 版本0.11是基本可以正常的版本
 
 这里就要扯到《GNU 风格的版本号管理策略》：
 
-1．项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
-2．当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
+1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
+2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
 3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
-4．当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
-5．另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
+4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
+5. 另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
 
 因此，我们可以得到几个简单的结论：
+
 - 我们需要阅读最早的有核心代码的版本
 - 我们需要阅读1.0版本的Release
 - 往后每一次大的Release我们都需要了解一下
diff --git a/chapters/15-milestone.md b/chapters/15-milestone.md
@@ -23,7 +23,7 @@ GitHub 里程碑
 
 一年前，稍微改变了下策略：暂时以**培养人为主**，同时想着做一个合适的开源框架——只是在今年看来，前端领域已经没有合适的地方可以造轮子了。
 
-在 GitHub 上有一个很常见的问题是，**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
+在 GitHub 上有一个很常见的问题是，**大多数项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
 
 你的开源项目不仅仅需要一个使用文档，还需要一个相关设计思想的文档、路线图、未来计划等等。
 
@@ -53,9 +53,9 @@ GitHub 里程碑
 
 **家居智能中心**。我仍然对于大学学的知识有点念念不忘，虽然已经写了一本书，但是硬件还是相当的刺激。唯一的问题是：连房子都没有，怎么做智能家居。
 
-**图形框架**。这是我之前在做一个图形界面的时候，发生没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
+**图形框架**。这是我之前在做一个图形界面的时候，发现没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
 
-不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
+不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工具来给自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
 
 最后，我做了一个简单的 HTML 5 动画来记录这一时刻，作为这一个里程碑的记念：
 
diff --git a/chapters/16-faq.md b/chapters/16-faq.md
@@ -12,7 +12,7 @@ FAQ
 
 在这种时候，也没有法律来保护这些开源软件作者。你只能从道德上谴责他们，然后指望他们的领导来做出一些什么事。如之前的《[知名公司（努比亚/中兴）拿我的开源软件（ XXL-JOB）申请国家知识专利，我该怎么办？](https://link.zhihu.com/?target=https%3A//www.v2ex.com/t/367424%3Fp%3D1)》事件。
 
-并且对于大部分的开源软件作者来说，都不大可像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
+并且对于大部分的开源软件作者来说，都不大可能像 OpenResty、Vue、emqtt 等软件的作者一样，可以从开源软件获得收益来支撑他们开发。还有一些少数人，还能从开源软件中获得一些利益，提高他们今年的 KPI。然后明年的工资，又会多涨一点点。
 
 可多数人，并没有这样的可能性。我在 GitHub 上有接近 30k 的 star（笑，有接近 20k 是属于电子书的，毕竟思想改变世界），它一点儿也不影响我涨工资。反而多了一个 GitHub “网红” 的称号，要知道在技术领域，“网红” 并不是一个好词。我观察过的大量开源爱好者，怕是比我还惨一些。明明做了很好的工作，因为宣传工作没有做好，连几个 star 都没有，后来就弃坑了。
 
