[T] try compile

phodal · phodal · commit 1963f54c5c21 · 2018-05-15T08:02:42.000+08:00
diff --git a/build/author.html b/build/author.html
@@ -3,6 +3,25 @@ <h1>GitHub 漫游指南</h1>
 <p>项目首页: <a href="https://github.com/phodal/github-roam">GitHub 漫游指南</a></p>
 <p>By <a href="https://www.phodal.com">Phodal Huang</a>(微博、知乎、GitHub、SegmentFault: @<a href="http://weibo.com/phodal">phodal</a>)
 </p>
+
+<p>我的其他电子书：</p>
+<ul>
+<li>《<a href="https://github.com/phodal/ideabook">Phodal's Idea实战指南</a>》</li>
+<li>《<a href="https://github.com/phodal/designiot">一步步搭建物联网系统</a>》</li>
+<li>《<a href="https://serverless.ink/">Serverless 应用开发指南</a>》</li>
+<li>《<a href="https://github.com/phodal/repractise">RePractise</a>》</li>
+<li>《<a href="https://github.com/phodal/growth-ebook">Growth: 全栈增长工程师指南</a>》</li>
+<li>《<a href="https://github.com/phodal/growth-in-action">Growth: 全栈增长工程师实战</a>》</li>
+<li>《<a href="https://github.com/phodal/fe">我的职业是前端工程师</a>》</li>
+<li>《<a href="https://github.com/phodal/make">写给软件工程师看的硬件编程指南</a>》</li>
+</ul>
+
 <p>微信公众号</p>
-<img src="./img/qrcode.jpg" alt=""/>
+<p><img src="https://articles.phodal.com/qrcode.jpg" alt=""/></p>
+<p>
+当前为预览版，在使用的过程中遇到任何遇到请及时与我联系。阅读过程中问题，不烦在GitHub上提出来：
+<a href="https://github.com/phodal/hardware-guide/issues">Issues</a>
+</p>
+<p>	
+阅读过程中遇到语法错误、拼写错误、技术错误等等，不烦来个Pull Request，这样可以帮助到其他阅读这本电子书的童鞋。
 </p>
diff --git a/build/share.html b/build/share.html
@@ -1,5 +1,5 @@
 <div style="width:800px">
 
-<iframe src="http://ghbtns.com/github-btn.html?user=phodal&repo=github-roam&type=watch&count=true"
+<iframe src="https://ghbtns.com/github-btn.html?user=phodal&repo=github-roam&type=watch&count=true"
   allowtransparency="true" frameborder="0" scrolling="0" width="110px" height="20px"></iframe>
 <div>
diff --git a/github-roam.md b/github-roam.md
@@ -400,7 +400,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')
@@ -1035,7 +1035,7 @@ Git 提交信息及几种不同的规范
 
 与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。
 
-因此，这里以做得比较好的开源项目 Angular 中为例展示。Angular 团队建议采用以下的形式：
+因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式：
 
 ```
 <type>(<scope>): <subject>
@@ -1147,21 +1147,19 @@ React.render(
 
 有一天，我发现当我需要我一次又一次地重复讲述某些内容，于是我就计划着把这些应该掌握的技能放到GitHub上，也就有了[Artisan Stack](https://github.com/phodal-archive/artisanstack.github.io) 计划。
 
-每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是是手工人。
-
-艺，需要有创造性的方法。
+每个程序员都不可避免地是一个Coder，一个没有掌握好技能的Coder，算不上是手工艺人，但是手工艺人，需要有创造性的方法。
 
 ## 为什么重构?
 
 > 为了更好的代码。
 
-在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而，你重写那几十代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
+在经历了一年多的工作之后，我平时的主要工作就是修Bug。刚开始的时候觉得无聊，后来才发现修Bug需要更好的技术。有时候你可能要面对着一坨一坨的代码，有时候你可能要花几天的时间去阅读代码。而你重写那几十行代码可能只会花上你不到一天的时间。但是如果你没办法理解当时为什么这么做，你的修改只会带来更多的Bug。修Bug，更多的是维护代码。还是前人总结的那句话对:
 
 > 写代码容易，读代码难。
 
 假设我们写这些代码只要半天，而别人读起来要一天。为什么不试着用一天的时候去写这些代码，让别人花半天或者更少的时间来理解。
 
-如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试，``没有测试的重构``。
+如果你的代码已经上线，虽然是一坨坨的。但是不要轻易尝试``没有测试的重构``。
 
 从前端开始的原因在于，写得一坨坨且最不容易测试的代码都在前端。
 
@@ -1193,7 +1191,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``模式(架构模式)。
 
@@ -1895,7 +1893,7 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for:
 
 ![对比其它项目](./img/comparison.png)
 
-当然了，这种事不能太过，要不是会招来一堆黑。
+当然了，这种事不能太过，要不然会招来一堆黑。
 
 ### 安装及hello, world 示例
 
@@ -2952,19 +2950,21 @@ Lettuce.send = function (url, method, callback, data) {
 ![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我们都需要了解一下
@@ -3521,7 +3521,7 @@ GitHub 里程碑
 
 一年前，稍微改变了下策略：暂时以**培养人为主**，同时想着做一个合适的开源框架——只是在今年看来，前端领域已经没有合适的地方可以造轮子了。
 
-在 GitHub 上有一个很常见的问题是，**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
+在 GitHub 上有一个很常见的问题是，**大多数项目的维护者就是发起人**——如果这个发起人发生意外了，那么这个项目怎么办。如果这是一个很火的项目，它就存在着巨大的风险；同时这可能也说明了，缺乏一套合理的机制。
 
 你的开源项目不仅仅需要一个使用文档，还需要一个相关设计思想的文档、路线图、未来计划等等。
 
@@ -3551,9 +3551,9 @@ GitHub 里程碑
 
 **家居智能中心**。我仍然对于大学学的知识有点念念不忘，虽然已经写了一本书，但是硬件还是相当的刺激。唯一的问题是：连房子都没有，怎么做智能家居。
 
-**图形框架**。这是我之前在做一个图形界面的时候，发生没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
+**图形框架**。这是我之前在做一个图形界面的时候，发现没有一个合适的框架可以满足我的要求。然后我就在想，还是自己做一个吧。
 
-不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
+不过，最好的开源项目就是自己平时用的。于是，我开始将写各种工具来给自己使用——如现在在用的这篇微信编辑工具：[mdpub](https://github.com/phodal/mdpub)。
 
 最后，我做了一个简单的 HTML 5 动画来记录这一时刻，作为这一个里程碑的记念：
 
@@ -3573,7 +3573,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 都没有，后来就弃坑了。
 
