fix images issue

Author: phodal

Makefile

@@ -8,6 +8,7 @@ all: html epub rtf pdf mobi
 
 markdown:
 	awk 'FNR==1{print ""}{print}' $(source) > $(filename).md
+	sed -i 's@](../images@](images@g' $(filename).md
 
 html: markdown
 	pandoc -s $(filename).md -t html5 -o index.html -c style.css \

ebook.md

@@ -76,15 +76,15 @@
 
 谈起路线规则这事，就会联想起算法里的路径问题。想了想，发觉“如何教人入门前端”与“选择合适的路径”颇为相似的，要实现这样的规划蛮难的。先上张图，加深一下印象：
 
-![最短路径](../images/short-path.jpg)
+![最短路径](images/short-path.jpg)
 
 接着，我们来思考这样的一个问题：
 
 > 每个初学者都处于“1”，最后的目标都是到“9”，那么你会怎么帮助他们规划路线？
 
 假设，每一个数字都对应了技术栈，并标注了每个技术栈学习所需要的时间。那么，这时要计算出**最快的学习路线**也就容易了。而这种开挂的感觉，就像是我们拥有了游戏中的技能树的一样。技能树上，包含了所有已知的技能，以及：学习某个技能所需要的时间，学习某个技能后可以触发某个技能等等。
 
-![技能树](../images/sherlock.jpg)
+![技能树](images/sherlock.jpg)
 
 不幸的事，这个路线不可能会怎么简单。倘若你是一个在校的学生，或者是相似的研究人员，那么这种路线也颇为适合。理想的情况下，我们可以自由地分配自己的时间，在对应的技术栈上花费相应的时间。这就好像是游戏世界的技能树一样，我们所拥有的点数是固定的，那么所能学习的技能也是固定的。
 
@@ -96,7 +96,7 @@
 
 一个很有意思的例子就是 Mustache 模板，即可以让我们用后台语言，如 Java，来渲染 Mustache 模板为 HTML，又可以在前端里使用 Mustache.js 来将模板渲染为 HTML。相似的，对于 React 中的 JSX 也是如此，我们即可以用 Node.js 与 React 在后台来渲染出页面，又可以在前端来渲染 JSX 为 HTML。
 
-![简单的前端学习路径](../images/fe-path.png)
+![简单的前端学习路径](images/fe-path.png)
 
 我的前端入门
 ---
@@ -107,7 +107,7 @@
 
 大一时，年轻气盛就去办了个社团，当了个社长。那会儿还能使用各种 Google 的服务，Google 刚刚开始推广它的云服务 Google App Engine。用户只需要点击一个按钮，就可以上传代码，应用就会自动地部署到相应的网站上了。下图就是我的第一个网站：
 
-![Django GAE](../images/django_gae.jpg)
+![Django GAE](images/django_gae.jpg)
 
 当时，写给客户的代码大多乏味，没有挑战性。为了尝试各种新特性，我就将各种奇怪的 CSS3 加到其中。
 
@@ -169,7 +169,7 @@ JavaScript 语言的变化
 
 这些语言在不同的时间段里，所受到的受关注程度都是不一样的。它们都是各自的特色，在不同的时期所到的欢迎程度也是不一样的：
 
-![JavaScript编译语言](../images/js-language-compare.jpg)
+![JavaScript编译语言](images/js-language-compare.jpg)
 
 这种变化相当有趣。尽管 JavaScript 是所有主流浏览器上唯一支持的脚本语言，但是它在过去的主要用途是用来：做一些页面“特效”。它可以通过 DOM API 来操作页面上的元素，而这些元素就是显示在页面上的内容。
 
@@ -263,11 +263,11 @@ TypeScript 与其他编译为 JavaScript 的语言初衷是类似的，为了开
 
 在《Growth：全栈 Web 开发思想》一书中，我曾提到过影响技术选型的几个因素。
 
-![技术选择因素](../images/tech-decide.png)
+![技术选择因素](images/tech-decide.png)
 
 这时，为了更好的考量不同的因素，你就需要列出重要的象限，如**开发效率**、团队喜好等等。并依此来决定，哪个框架更适合当前的团队和项目。
 
-![PRI](../images/pri.jpg)
+![PRI](images/pri.jpg)
 
 即使，不考虑前端框架以外的因素，那么技术选型也是相当痛苦的一件事。
 

index.html

@@ -106,30 +106,30 @@ <h1 id="我的职业是前端工程师入门不是应该很简单吗">我的职
 <h2 id="前端之路">前端之路</h2>
 <p>谈起路线规则这事，就会联想起算法里的路径问题。想了想，发觉“如何教人入门前端”与“选择合适的路径”颇为相似的，要实现这样的规划蛮难的。先上张图，加深一下印象：</p>
 <figure>
-<img src="../images/short-path.jpg" alt="最短路径" /><figcaption>最短路径</figcaption>
+<img src="images/short-path.jpg" alt="最短路径" /><figcaption>最短路径</figcaption>
 </figure>
 <p>接着，我们来思考这样的一个问题：</p>
 <blockquote>
 <p>每个初学者都处于“1”，最后的目标都是到“9”，那么你会怎么帮助他们规划路线？</p>
 </blockquote>
 <p>假设，每一个数字都对应了技术栈，并标注了每个技术栈学习所需要的时间。那么，这时要计算出<strong>最快的学习路线</strong>也就容易了。而这种开挂的感觉，就像是我们拥有了游戏中的技能树的一样。技能树上，包含了所有已知的技能，以及：学习某个技能所需要的时间，学习某个技能后可以触发某个技能等等。</p>
 <figure>
-<img src="../images/sherlock.jpg" alt="技能树" /><figcaption>技能树</figcaption>
+<img src="images/sherlock.jpg" alt="技能树" /><figcaption>技能树</figcaption>
 </figure>
 <p>不幸的事，这个路线不可能会怎么简单。倘若你是一个在校的学生，或者是相似的研究人员，那么这种路线也颇为适合。理想的情况下，我们可以自由地分配自己的时间，在对应的技术栈上花费相应的时间。这就好像是游戏世界的技能树一样，我们所拥有的点数是固定的，那么所能学习的技能也是固定的。</p>
 <p>假使真实世界的前端技能树已经很清晰，那么这里的点数对应的就是时间。在时间固定的情况下，我们所能学习的技能也是固定的。而技能树中的时间花费是一个大的问题：当我们学习完某个技能后，我们可能就拥有其他技能的加成。</p>
 <p>在已经学会了 ES6 的情况下，学习 TypeScript 就变得更轻松，这时学习 TypeScript 的时间就会更短。也因此，相似的技术栈可以归类到一起。遗憾的是，学习相似的技术栈仍然是需要时间的。</p>
 <p>回到前端技术的话题上，在编写复杂前端应用时，我们都会采用前端框架来加快开发。前端框架的技术基础都是一样的，有区别的是，它们衍生出来的技术思想。有的框架创造出了一些有意思的 DSL（领域特定语言），可以借此编写出独立于语言的代码，这些代码也可以用在不同的领域里。</p>
 <p>一个很有意思的例子就是 Mustache 模板，即可以让我们用后台语言，如 Java，来渲染 Mustache 模板为 HTML，又可以在前端里使用 Mustache.js 来将模板渲染为 HTML。相似的，对于 React 中的 JSX 也是如此，我们即可以用 Node.js 与 React 在后台来渲染出页面，又可以在前端来渲染 JSX 为 HTML。</p>
 <figure>
-<img src="../images/fe-path.png" alt="简单的前端学习路径" /><figcaption>简单的前端学习路径</figcaption>
+<img src="images/fe-path.png" alt="简单的前端学习路径" /><figcaption>简单的前端学习路径</figcaption>
 </figure>
 <h2 id="我的前端入门">我的前端入门</h2>
 <p>在我刚学前端工程师的时候，由于只需要编写 CSS、JavaScript 和 HTML，因此要做前端的活相当的简单。有时，甚至会觉得有些乏味。</p>
 <h3 id="我的第一个网站">我的第一个网站</h3>
 <p>大一时，年轻气盛就去办了个社团，当了个社长。那会儿还能使用各种 Google 的服务，Google 刚刚开始推广它的云服务 Google App Engine。用户只需要点击一个按钮，就可以上传代码，应用就会自动地部署到相应的网站上了。下图就是我的第一个网站：</p>
 <figure>
-<img src="../images/django_gae.jpg" alt="Django GAE" /><figcaption>Django GAE</figcaption>
+<img src="images/django_gae.jpg" alt="Django GAE" /><figcaption>Django GAE</figcaption>
 </figure>
 <p>当时，写给客户的代码大多乏味，没有挑战性。为了尝试各种新特性，我就将各种奇怪的 CSS3 加到其中。</p>
 <p>这一点在今天的日常工作里，也没有太多的变化。工作写代码是为了活下去，业余写代码则是为了兴趣。有意识地将两者分开，才能使技术更好的成长。我们不会因为，在项目里引入新技术而沮丧。同时，在业余时自由的使用新的技术，来提升自己的技术与视野。</p>
@@ -166,7 +166,7 @@ <h2 id="javascript-语言的变化">JavaScript 语言的变化</h2>
 <p>几年间，出现了 CoffeeScript、TypeScript、ClojureScript、Dart、ES6 等等的语言，他们都可以编译为 JavaScript，随后就可以在浏览器上运行。诸如 ES6，这一个新的 JavaScript 版本（现有的 JavaScript 版本，称为 ES5，即 EcmaScritp 5），则可以在最新的浏览器上运行部分或者全部的特性。</p>
 <p>这些语言在不同的时间段里，所受到的受关注程度都是不一样的。它们都是各自的特色，在不同的时期所到的欢迎程度也是不一样的：</p>
 <figure>
-<img src="../images/js-language-compare.jpg" alt="JavaScript编译语言" /><figcaption>JavaScript编译语言</figcaption>
+<img src="images/js-language-compare.jpg" alt="JavaScript编译语言" /><figcaption>JavaScript编译语言</figcaption>
 </figure>
 <p>这种变化相当有趣。尽管 JavaScript 是所有主流浏览器上唯一支持的脚本语言，但是它在过去的主要用途是用来：做一些页面“特效”。它可以通过 DOM API 来操作页面上的元素，而这些元素就是显示在页面上的内容。</p>
 <p>随后 Ajax 技术诞生了，开发人员发现可以用 JavaScript 做更多的事。JavaScript 之时，是用于在客户端上执行一些指令。而 Ajax 则可以让浏览器直接与服务端通讯。这就意味着，<strong>你可以在浏览器间接地去操作数据库</strong>，前端应用便因此而变得更加庞大。</p>
@@ -223,11 +223,11 @@ <h3 id="技术选型不仅仅受技术影响">技术选型：不仅仅受技术
 <p>只可惜，我不再是一个后台开发者，我不再像过去，可以直接、没有顾虑的选择。当我选择 JavaScript 时，我就犯上了「选择恐惧症」。技术选型也是没有银弹的——没有一个框架能解决所有的问题。</p>
 <p>在《Growth：全栈 Web 开发思想》一书中，我曾提到过影响技术选型的几个因素。</p>
 <figure>
-<img src="../images/tech-decide.png" alt="技术选择因素" /><figcaption>技术选择因素</figcaption>
+<img src="images/tech-decide.png" alt="技术选择因素" /><figcaption>技术选择因素</figcaption>
 </figure>
 <p>这时，为了更好的考量不同的因素，你就需要列出重要的象限，如<strong>开发效率</strong>、团队喜好等等。并依此来决定，哪个框架更适合当前的团队和项目。</p>
 <figure>
-<img src="../images/pri.jpg" alt="PRI" /><figcaption>PRI</figcaption>
+<img src="images/pri.jpg" alt="PRI" /><figcaption>PRI</figcaption>
 </figure>
 <p>即使，不考虑前端框架以外的因素，那么技术选型也是相当痛苦的一件事。</p>
 <h3 id="上线时间影响框架">上线时间影响框架</h3>