phodal · phodal · May 23, 2024 · May 23, 2024 · May 23, 2024 · May 23, 2024
diff --git a/chapters/01-start-project.md b/chapters/01-start-project.md
@@ -31,15 +31,15 @@
 
 如下是不同开源许可证的市场占有率及使用情况。
 
-![License 使用情况](./img/permissive-vs-copylift-license-2.jpg)
+![License 使用情况](../img/permissive-vs-copylift-license-2.jpg)
 
 又比如，在我们看到的一些外版书籍上，如果拥有代码。那么作者一般就会在前言或者类似的位置里，指明书中代码的版权所属。如：
 
 > 也许你需要在自己的程序或文档中用到本书的代码，但除非大篇幅地使用，否则不必与我们联系取得授权。例如，用本书中的几段代码编写程序无需请求许可，blabla。
 
 于是，选择一个合理的 LICENSE，就变成了一个有趣的话题。为此，笔者做了一个如何进行开源协议选型的流程图：
 
-[![如何选择 License](./img/licenses.png)](https://github.com/phodal/licenses)
+[![如何选择 License](../img/licenses.png)](https://github.com/phodal/licenses)
 
 简单地来说，这些 License 之间是一些权利的区别，如当你把代码放置到公有领域，就意味着任何人可以修改，并且不需要标明出注；可如果你想要别人标明出处及作者，你就需要 MIT 协议；而你希望别人闭源的话，那么你就需要 MPL 协议等等。
 

diff --git a/chapters/02-github-fundamentals.md b/chapters/02-github-fundamentals.md
@@ -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。
diff --git a/chapters/05-create-project-documents.md b/chapters/05-create-project-documents.md
@@ -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)
 
 下面的内容写清楚了他们的用途：
 

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

diff --git a/chapters/08-github-marketing.md b/chapters/08-github-marketing.md
@@ -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,15 +78,15 @@ 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)
 
 以上便是这个项目能解决的问题，不过这个项目能解决的问题倒是比较长，哈哈哈。
 
 ### 它有什么特性
 
 当我们有 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,15 +152,15 @@ WTF！
 
 对于一个复杂的开源项目来说，文档上要写明安装、编译、配置等等的过程。如下图所示：
 
-![Python Social Auth 文档](./img/python-social-auth-example.png)
+![Python Social Auth 文档](../img/python-social-auth-example.png)
 
 并且在我们发布包的时候，就要不断地去重复这个过程——如果你使用了自动化测试，那么这个过程便自动完成了。
 
 如果我们的项目使用起来相当的简单，那么我们就可以只写一些示例代码即可。
 
 并且，我们可以将文档直接入到代码里。它可以有效地减少文档不同步，带来的一些问题。
 
-![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 做起的~~。
 

diff --git a/chapters/10-git-tools.md b/chapters/10-git-tools.md
@@ -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)
diff --git a/chapters/11-analytics.md b/chapters/11-analytics.md
@@ -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 等等。
 

diff --git a/chapters/13-read-code.md b/chapters/13-read-code.md
@@ -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)
 
 五、接着，再回过头去阅读