大家周末好，天氣這是越來越冷了，冬季到來了。西安冬日的傳統霧霾又上演了，不過最近又限行了，希望能有點用處吧。好了今天不說什么新的東西，把之前的坑給填一填吧。
上篇文章的最后給大家留了一個問題，如果順序的執行多個promise，已經有同學答對了，就是用鏈式調用。的確答案就是如此，那么具體一點怎么做鏈式調用呢？那么我們來看一個例子吧。
var guid = 0;
function run() {
guid++;
var id = guid;
return new Promise(resolve => {
setTimeout(function () {
console.log(id);
resolve(id);
}, (Math.random() * 1.5 | 0) * 1000);
});
}
var promises = Array.from({ length: 10 }, run);
Promise.all(promises)
上篇文章（上邊的例子）中我們看到了 使用promise.all可以把幾個promise組合起來使用，那么如果我們想讓這些promise順序執行改怎么辦呢？來看答案。
var guid = 0;
function run() {
guid++;
var id = guid;
return new Promise(resolve => {
// resolve in a random amount of time
setTimeout(function () {
console.log(id);
resolve(id);
}, (Math.random() * 1.5 | 0) * 1000);
});
}
var promises = Array.from({ length: 10 }).reduce(function (acc) {
return acc.then(function (res) {
console.log(res)
return run().then(function (result) {
res.push(result);
return res;
});
});
}, Promise.resolve([]));
這里有點很有意思，我們先創建了一個創建一個長度為10的Array出來，然后呢，調用了其上的reduce方法，關鍵是這個reduce方法有意思了，傳入的初始值是個resolved的promise，然后傳入了一個function，其作用就是將這些promise都chain了起來。這樣達到了順序調用的目的，當然可以用其他寫法達到目的，但是使用reduce還是有點意思的。大家有興趣了可以自己來試試。
OK，之前在介紹DockerFile的時候圖表君還是留了問題。下邊的DockerFile其實定義的是有問題的。
FROM node:4.6
MAINTAINER Aaron Chen<mail@aaronchen.cn>
RUN mkdir /app
WORKDIR /app
COPY . /app
RUN npm install
EXPOSE 8080
那么問題在哪呢？問題就是這樣的DockerFile我們就不能利用webpack-dev-server的hot reload的特性了。這對于開發階段是相當大的效率影響的，那么如何解決呢，也是比較容易的，我們將代碼做成一個volume掛到容器里就解決問題了。
下邊說幾句非技術的話題，技術的道路做久了，都會考慮到技術路線的問題，作為一個年輕人圖表君并沒有太多的經驗，但是上周看到了池建強老師的一篇文章，說的挺好，在這里分享給大家。
技術發展（這里只談我了解的軟件）不外乎三條路：算法、底層和業務。能在一條路上精通，就很不錯了。而厲害的人可以同時兼顧兩條路。三條都牛的人，蠻罕見的。
技術1：算法路線
走算法路線，對智商的要求是高于其它路線的。但也不能說高到哪里去了。畢竟在企業里做算法工作，更多的是應用成熟算法，而不是自己設計算法。
算法路線比較適合耐得住寂寞的人，因為做算法常常是站在產品的幕后，好的結果又往往需要慢慢「熬」出來。算法往高走，對基礎的要求就比較高了。不是博士出身，沒在頂尖研究機構混過，在企業里也很難做出特別牛的成果。所以一般本科生不太建議走這個方向（當然，本科生也不用太難過，畢竟沒退學生也做出過一些驚人的成就，池建強注）。
技術2：底層路線
底層路線，是圍繞著操作系統、編譯原理、分布式系統、數據庫、軟件工程這些理論，用各種工具搭建出酷酷的應用開發、運行環境。把各種復雜的工具跑起來，不僅和諧共處，還能發揮各自的長處，彌補各自的短處，并不是個簡單工作。如果能再自己開發一些好用工具，就更不簡單了。
極客、黑客范兒的人，是最適合走這條路線的。愛折騰，愛嘗鮮，崇尚開源文化，細致縝密，是做好這一行的標簽。
運維、DevOp、云計算、大數據、架構師，這些崗位或領域的人，多是能呼云喚雨的底層高手。
技術3：業務路線
大多數技術都是在業務線生存和創造價值的。如果論技術光環，這條線是比不過前兩條的，容易產生「對技術能力要求不高」的感覺。從某些角度看，確實如此，但這條線也有自己獨步天下的技術，那就是復雜業務建模能力。
修煉這項能力，除了技術的通用要求外，還需要比其它路線更強的溝通能力和抽象能力。或者說，對情商的要求最高。
適合自己的才是最好的，到底走那條路線是一個選擇問題，做出自己的選擇，并堅持的走下去。這可能是漫長和痛苦的過程。好了，嘮嘮叨叨了這么多，今天就寫到這吧，我們下周見。
原創文章，歡迎轉發，但請標明出處。歡迎關注圖表君的公眾號，一起成長。在微信中搜索 “多彩數據” 或者 “Data_Visualization”
