-
Notifications
You must be signed in to change notification settings - Fork 0
/
atom.xml
345 lines (305 loc) · 88.2 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[陈钧桐的记忆宫殿]]></title>
<subtitle><![CDATA[背负青天而莫之夭阏]]></subtitle>
<link href="/atom.xml" rel="self"/>
<link href="chenjuntong.me/"/>
<updated>2016-07-25T09:06:55.170Z</updated>
<id>chenjuntong.me/</id>
<author>
<name><![CDATA[陈钧桐]]></name>
</author>
<generator uri="http://hexo.io/">Hexo</generator>
<entry>
<title><![CDATA[为什么在TCP协议中建立连接的握手需要三次？]]></title>
<link href="chenjuntong.me/2016/05/20/threeway%20handshake/"/>
<id>chenjuntong.me/2016/05/20/threeway handshake/</id>
<published>2016-05-20T14:46:24.000Z</published>
<updated>2016-07-25T09:06:55.170Z</updated>
<content type="html"><![CDATA[<blockquote>
<p>TCP is said to be <strong>connection-oriented</strong> because before one application process can<br>begin to send data to another, the two processes must first “handshake” with each<br>other…this connection-establishment procedure is often referred to as a <strong>three-way handshake</strong>. <code>——《Computer networking : a top-down approach》</code></p>
</blockquote>
<p>在任何一本计算机网络的教科书上，我们都会学到：应用程序在使用 TCP 通信之前，先要建立连接，而这个创建连接的过程被称为<strong>三次握手</strong>。（假如你已经忘了的话，我在文末写了段<code>WireShark抓包实战：TCP连接的建立</code>）接着，教材便会开始介绍三次握手的流程以及TCP报文段结构（TCP Segment Structure）。和喜欢追根溯源的历史故事不同，书本很少会涉及到一个问题：<strong>为什么在TCP协议中建立连接的握手需要三次？</strong>二次行不行？四次可以吗？“三”这个数字是怎么来的？与道家所讲的“一生二，二生三，三生万物”有关联吗？</p>
<h3 id="引子：红蓝军问题（Two_Generals’_Problem）">引子：红蓝军问题（Two Generals’ Problem）</h3><p>让我们回溯一下历史，回到冷兵器时代，那时候情报只能靠斥候骑马送达，而斥候在路上很可能被敌军截下。在这种情况下，两支军队之间如何进行通讯就引申出了一个很著名的思想实验——红蓝军问题（Two Generals’ Problem）。</p>
<p><img src="http://ww2.sinaimg.cn/large/6ccda21fgw1f4106u28m1j207g065aan.jpg" alt="Two Generals' Problem"></p>
<blockquote>
<p>Two armies, each led by a general, are preparing to attack a fortified city. A valley separates the two hills, and the only way for the two generals to communicate is by sending messengers through the valley. Unfortunately, the valley is occupied by the city’s defenders and there’s a chance that any given messenger sent through the valley will be captured.——<a href="https://en.wikipedia.org/wiki/Two_Generals%27_Problem" target="_blank" rel="external">Two Generals’ Problem from wikipedia</a></p>
</blockquote>
<p>被蓝军隔断的两支红军要想攻下蓝军，就必须商定好统一的时间吹响集结号合力进攻。于是，左边红军的将军A派斥候告诉右边红军的将军B，“明早九点吹响集结号！”。幸运的是，斥候成功将情报送达，这时将军B虽然知道了时间，但担心将军A还不知道他（将军B）已经收到了情报，从而不敢贸然进攻，于是又派斥候把将军B已经记下时间点的这个情况告诉将军A。幸运第二次降临，斥候也成功地返回左边的红军报到。此时，将军A明早就敢吹响集结号吗？他不敢，因为他担心将军B不知道这次斥候成功送达了情报，在这种情况下，将军B在明早也不敢贸然进攻。于是将军A又派斥候去右边，告诉将军B他（将军A）已经知道了将军B知道明早九点吹响集结号的情报。幸运第三次降临，斥候成功地到右边红军报到。此时，将军B明早就敢发起进攻吗？他依然不敢，因为他担心将军A不知道这次斥候成功送达了情报，在这种情况下，将军A在明早也不敢吹响集结号……</p>
<p>聪明的读者已经猜到，这是一场永远达不成协议的进攻。无论情报送达了多少个来回，总是没有办法保证每个将军想对“最后一次情报送达”的“确认”生效。</p>
<blockquote>
<p>Thus it quickly becomes evident that no matter how many rounds of confirmation are made, there is no way to guarantee the second requirement that each general be sure the other has agreed to the attack plan. Whichever general sends the final messenger will always be left wondering whether the messenger got through.——<a href="https://en.wikipedia.org/wiki/Two_Generals%27_Problem" target="_blank" rel="external">Two Generals’ Problem from wikipedia</a></p>
</blockquote>
<p>这个思维实验说明了一个重要的通信道理：在不可信的信道上，不可能实现完全可信的通信。而实际信道绝对是有扰的，换句话说，<strong>世界上不存在完全可靠的通信协议。</strong></p>
<h3 id="历史的行程：无线电台">历史的行程：无线电台</h3><p>人生天地之间，若白驹之过隙，忽然而已。我们来到已经诞生了无线电台的时代。在这个时空，通讯不再依靠快马扬鞭的斥候，而是靠无线电台。那么斥候会不会被半路劫走就无须担心，取而代之的是，我们要确认<strong>通讯设备是可以正常工作的</strong>，换言之，<strong>发信机和收信机是好的</strong>。那么如果两个人要进行成功的通讯，他们相互之间需要联系几次，才能知道自己设备是好的呢？</p>
<p><strong>第一次</strong>：将军A给将军B发送了尝试建立通讯的电报。此时，将军B收到了，那么将军B能确认自己的收信机，以及将军A的发信机是好的，而将军A什么都确认不了。<br><strong>第二次</strong>：将军B给将军A发送了回应的电报。此时，将军A收到了，那么将军A能确认自己的发信机、收信机都是好的，以及将军B的发信机、收信机也是好的，而将军B依然不能确认自己的发信机，以及将军A的收信机是好的。所以将军A还不能讲正事。<br><strong>第三次</strong>：将军A对将军B的回应进行了回应，再发送了一次电报。此时将军A知道双方的通讯设备是正常工作的，这一次回应只是为了消除将军B对自己的发信机，以及将军A的收信机的担心。现在，将军A不用等将军B的再次回应，就可以开始讲正事了。</p>
<p>以上共有几次握手呢？数一数，一共是<strong>三次握手</strong>。那握手三次后，后面的通讯就一定能一直正常工作吗？当然不能，握手成功后设备可以突然故障，信号可以突然丢失，还有许多可能可以导致通信失败。<strong>三次握手的意义是在于它排除了两个无线电台本身的收发信故障。</strong>如果再多握手几次，变成四次握手，五次握手等，也许会更加靠谱一些，但正如红蓝军问题所揭示的道理一样：世界上不存在完全可靠的通信协议。</p>
<p>有的读者想问了，电台通信一定要三次握手吗？当然不一定。在间谍电影里，我们经常可以看到间谍为了不暴露自己，可以只用收信机而不发信，传送情报时再采取其他手段，例如在冷咖啡的杯垫下留下密文。</p>
<h3 id="众里寻他千百度">众里寻他千百度</h3><p>在这里，我们可以得出结论：<strong>握手次数在建立连接的<code>可靠性</code>和<code>性能</code>上进行取舍后，得出<code>三次</code></strong>。</p>
<blockquote>
<p>握手次数本来就是比较灵活的问题，但是作为协议必须确定。并不会适合所有的情况。现行的tcp协议每次握手的时候具体的通信协议细节，是为三次握手特别设定的。假如当时设定的是四次握手，它的第三次握手的内容就不会和现在三次握手的时候第三次的内容一样了。——Fluxay</p>
</blockquote>
<p>所以在逻辑上是这样的，互联网诞生之初，在连接的<code>可靠性</code>和<code>性能</code>上平衡后，选择的方案是<code>三次握手</code>。在这之后，TCP协议的设计者按照三次握手的方案具体设计了每次握手的通信协议细节。</p>
<p>这个时候，让我们回到教材，看看课本对为什么选择<code>三次握手</code>方案的介绍：</p>
<blockquote>
<p>It may seem that a two-message exchange would suffice to establish a connection.However, the three-way handshake is both necessary and sufficient for correct synchronization between the two ends of the connection given internet delivery semantics.To understand the reason that connection establishment is difficult, remember that TCP uses an unreliable packet delivery service. Therefore, messages can be lost, delayed,duplicated, or delivered out of order. To accommodate loss, TCP must retransmit requests. However, trouble can arise if excessive delay causes retransmission, which means both the original and retransmitted copy arrive while the connection is being established. Retransmitted requests can also be delayed until after a connection has been established, used, and terminated! The three-way handshake and rules that prevent restarting a connection after it has terminated are carefully designed to compensate for all possible situations.<code>——《Internetworking with TCP/IP》</code></p>
</blockquote>
<p>相信聪明的读者读到这里，已是胸有成竹。</p>
<h3 id="WireShark抓包实战：TCP连接的建立">WireShark抓包实战：TCP连接的建立</h3><p>知乎上流行一句话叫“先问是不是，再问为什么”。那么现在就让我用WireShark抓包看看，TCP是不是这样子建立连接的。先看一下课本是怎么介绍的：</p>
<p><img src="http://static.zybuluo.com/JuntongCHEN/1whogirjbb4q3o0bchjtlbov/image_1aj77dkb21rbe11dveeiq87oao9.png" alt="image_1aj77dkb21rbe11dveeiq87oao9.png-65.4kB"></p>
<blockquote>
<p>To establish a connection, TCP uses a <em>three-way handshake.</em> That is, three messages are exchanged that allow each side to agree to form a connection and know that the other side has agreed. The first segment of a handshake can be identified because it has the SYN‡ bit set in the code field. The second message has both the SYN and ACK bits set to indicate that it acknowledges the first SYN segment and continues the handshake. The final handshake message is only an acknowledgement and is merely used to inform the destination that both sides agree that a connection has been established.<code>——《Internetworking with TCP/IP》</code></p>
</blockquote>
<p>再看一眼TCP报文段结构（TCP Segment Structure）：<br><img src="http://static.zybuluo.com/JuntongCHEN/emfrdjrqo1nrwz3oa6wlvys4/image_1aj781udug7ima0cechhm1v7613.png" alt="image_1aj781udug7ima0cechhm1v7613.png-104.1kB"><br><code>——《TCP/IP Illustrated, Volume 1》</code></p>
<p>抓包实战开始：<br>①首先打开<code>WireShark</code>，选定要监听的网卡。<br>②在浏览器输入想访问的网址，比如我输入的是<code>chenjuntong.me</code><br><img src="http://static.zybuluo.com/JuntongCHEN/kzk0u2my29im6yisje2lvip2/image_1aj78pd0u1u87t8sfkbfi4ph3u.png" alt="image_1aj78pd0u1u87t8sfkbfi4ph3u.png-29kB"><br>③在过滤器输入<code>HTTP</code>，找到<code>GET Method</code>，右键菜单中选择<code>追踪流-TCP流</code><br><img src="http://static.zybuluo.com/JuntongCHEN/8ny8vmo54m4hm1peqe1sws9y/image_1aj770lh7100k1o0e10tepj8157a9.png" alt="image_1aj770lh7100k1o0e10tepj8157a9.png-54.8kB"></p>
<p>④此时，通过截获的数据包，我们可以很清楚地看到，客户端和服务器先是在TCP协议下进行了<code>三次握手</code>，然后才进行了HTTP长连接。<br><img src="http://static.zybuluo.com/JuntongCHEN/k6sniqxus2vrfcthzwfymh92/image_1aj7747f01ep815ao1ddrobf1c0um.png" alt="image_1aj7747f01ep815ao1ddrobf1c0um.png-20kB"></p>
<p>⑤庖丁解牛，让我们来看看每一次握手的具体内容。<br>⑥第一次握手：<br><img src="http://static.zybuluo.com/JuntongCHEN/1qqd4k13hl9049uqnef3zi9o/image_1aj78clj7fmq1lidumdkrp5e71t.png" alt="image_1aj78clj7fmq1lidumdkrp5e71t.png-31.8kB"><br>客户端发送建立连接请求，标志位<code>SYN=1</code>，序列号（Sequence number）<code>seq=0</code> 。</p>
<p>⑦第二次握手：<br><img src="http://static.zybuluo.com/JuntongCHEN/x30m4x57up90bbonn2szybvf/image_1aj78jofo16cq11041uvp1hds1qk82a.png" alt="image_1aj78jofo16cq11041uvp1hds1qk82a.png-34.4kB"><br>服务器发回确认包，标志位<code>SYN=1，ACK=1</code>，同时发送服务器的序列号<code>seq=0</code>，将自己的确认序号(Acknowledgement Number)<code>ack</code>设置为客户端的序列号<code>seq</code>加1，即0+1=1，<code>ack=1</code>。</p>
<p>⑧第三次握手：<br><img src="http://static.zybuluo.com/JuntongCHEN/tnomczzn7eukhftuejgshgvi/image_1aj79cka2fpb1v7bhm8ns5v4v4b.png" alt="image_1aj79cka2fpb1v7bhm8ns5v4v4b.png-33.5kB"><br>客户端再次发送确认包，标志位<code>ACK=1</code>，<code>SYN=0</code>，并且将服务器发来的序列号<code>seq</code>+1，放在自己确定字段<code>ack</code>中发送给对方，同时把自己的序列号<code>seq</code>加1再发送出去，即<code>seq=1</code>。</p>
<p>至此TCP连接已经建立，客户端进入<code>ESTABLISHED</code>(已建立连接)状态，当服务端收到确认后，也进入 <code>ESTABLISHED</code>状态，它们之间便可以正式传输数据了。</p>
<p>参考资料：<a href="http://dwz.cn/3p5PaP" target="_blank" rel="external">http://dwz.cn/3p5PaP</a></p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
]]></content>
<summary type="html">
<![CDATA[在任何一本计算机网络的教科书上，我们都会学到：应用程序在使用 TCP 通信之前，先要建立连接，而这个创建连接的过程被称为三次握手。（假如你已经忘了的话，我在文末写了段WireShark抓包实战：TCP连接的建立）接着，教材便会开始介绍三次握手的流程以及TCP报文段结构（TCP Segment Structure）。和喜欢追根溯源的历史故事不同，书本很少会涉及到一个问题：为什么在TCP协议中建立连接的握手需要三次？二次行不行？四次可以吗？“三”这个数字是怎么来的？与道家所讲的“一生二，二生三，三生万物”有关联吗？]]>
</summary>
<category term="ComputerNetworking" scheme="chenjuntong.me/tags/ComputerNetworking/"/>
<category term="计算机网络" scheme="chenjuntong.me/categories/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/"/>
</entry>
<entry>
<title><![CDATA[《Algorithms》摘录评注之叁：基本排序]]></title>
<link href="chenjuntong.me/2015/12/03/alg-03/"/>
<id>chenjuntong.me/2015/12/03/alg-03/</id>
<published>2015-12-02T18:26:20.000Z</published>
<updated>2016-07-25T09:06:10.466Z</updated>
<content type="html"><![CDATA[<blockquote>
<p>本笔记基于<strong>ROBERT SEDGEWICK & KEVIN WAYNE</strong>开设的《Algorithms》课程，同时配有同名教材。<br>slides本身内容丰富详实，所以我会先甄选出重点的篇幅整理出来并做简单批注，后续会添上对应算法题的演示。</p>
</blockquote>
<h2 id="0-排序的基础：">0.排序的基础：</h2><p>通过对两个元素进行大小比较（小于、等于或者大于），返回不同的结果。<br><img src="http://static.zybuluo.com/JuntongCHEN/dg1937djims0j9fo8akds8th/image_1ansqmelvr6j105h5jcjeflca1g.png" alt="image_1ansqmelvr6j105h5jcjeflca1g.png-141.7kB"><br>比较后进行两步处理：①第一个元素是否比第二个元素小（是的话返回-1）②（满足条件下）两者进行交换<br><img src="http://static.zybuluo.com/JuntongCHEN/c81asuptporn992h1gx7doyt/image_1ansqn3idn6g61n12pb15931jai2a.png" alt="image_1ansqn3idn6g61n12pb15931jai2a.png-49.3kB"></p>
<h2 id="1-选择排序">1.选择排序</h2><p>实现过程：①从左（第1个元素开始）到右遍历整个数组，找出当前整个数组最小的元素并放到最左边；②继续遍历整个数组（从第2个元素开始，第1个元素的位置在①中已被最小元素固定，所以不用管）找到（整组中）第2小的元素（即剩下数组元素中最小的），放在左起第2个位置；③重复直至整个数组排序完成</p>
<p>算法复杂度：由于每次都要遍历当前剩下的整个数组，所以需要比较<br>(N – 1) + (N – 2) + … + 1 + 0 ~ N ² / 2 次，交换N次<br><img src="http://static.zybuluo.com/JuntongCHEN/28pc57x8pg05gwpx0mgxng4e/image_1ansqobr3sd15sh1pcgk691qs534.png" alt="image_1ansqobr3sd15sh1pcgk691qs534.png-148.3kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/tqdnainxvpgpmur9fbg7xc1m/image_1ansqofjakjqfntlb71rclcfi3h.png" alt="image_1ansqofjakjqfntlb71rclcfi3h.png-115.5kB"></p>
<h2 id="2-插入排序">2.插入排序</h2><p>每次都要从（当前的）头开始遍历，很麻烦，改进一下。<br>实现过程：从右边开始入手，只要当前的元素比左边的元素小，就跟左边交换，循环往复。</p>
<p>算法复杂度：对于一个随机的数组，平均来看，有一半的元素是已经按从小到大排序好的（不一定连在一起，可以混在没有排序好的元素中间），所以跟之前的选择排序相比，少做一半的比较，（对于选择排序来说，元素怎么排都不影响，它总是机械死板地从头开始遍历整个数组）那么算法复杂度也是选择排序的一半了，即N ² / 4次 。<br><img src="http://static.zybuluo.com/JuntongCHEN/p1bvjzldpmmzebmuvyyrmq0g/image_1ansqppdlkch1gtvr42odm1ngd4b.png" alt="image_1ansqppdlkch1gtvr42odm1ngd4b.png-61.4kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/zk1ymexljxsfx42twr64bye3/image_1ansqpv4p1cmn1cl1fmf1i0ml994o.png" alt="image_1ansqpv4p1cmn1cl1fmf1i0ml994o.png-117.8kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/6q5vq312dc6azh9oqpbp95d8/image_1ansqq35s19ur1kq82q113s94s55.png" alt="image_1ansqq35s19ur1kq82q113s94s55.png-62.5kB"><br>插入排序在已经部分排序好的数组里的表现：<br><img src="http://static.zybuluo.com/JuntongCHEN/0sgxfkk3zwsdx3gio4bcsdxl/image_1ansqqhs01d6d1mdm1i2ujln4u25v.png" alt="image_1ansqqhs01d6d1mdm1i2ujln4u25v.png-59.6kB"></p>
<h2 id="3-Shellsort_（Shell是发明这个算法的人的名字）">3.Shellsort （Shell是发明这个算法的人的名字）</h2><p>插入排序比选择排序有进步，但它也有犯傻的时候，比如在右边的某个元素命名比前面7个元素都要小，但我们却要眼睁睁地看着这个元素连续与左边交换7次。聪明的你们想到了，直接一步到位，交换7个位置嘛！然后再每隔3个元素进行比较交换，再回到最基本的对每个元素进行比较交换，这就是<code>Shellsort</code>。<br><img src="http://static.zybuluo.com/JuntongCHEN/qy2dtsynwg7pxmnv74sif2w3/image_1ansqrt5suq71abp2f81o2fh8p79.png" alt="image_1ansqrt5suq71abp2f81o2fh8p79.png-72.3kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/ymq5ugclci53i6azcjpuwtuu/image_1ansqs7s317bjfmeuuk116cg177m.png" alt="image_1ansqs7s317bjfmeuuk116cg177m.png-148kB"><br>当然，那到底从每隔几个元素进行操作开始呢？这个间隔规律也是个数学问题，<strong>目前并没有一个严密的数学模型可以求得最优解</strong>，在这里介绍一个比较简单易用的：3x+1<br><img src="http://static.zybuluo.com/JuntongCHEN/qq2li9b7hpz7p9xxut0clgpf/image_1ansqsnor1tju1giv28guipc9a8g.png" alt="image_1ansqsnor1tju1giv28guipc9a8g.png-130.8kB"></p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
]]></content>
<summary type="html">
<![CDATA[本节笔记将先介绍排序的API，再讲解数种常用的基本排序及具体实现，分别是：选择排序、插入排序以及Shellsort。目前在Shellsort中并没有一个严密的数学模型可以求得最优解，在这里介绍一个比较简单易用的：3x+1。]]>
</summary>
<category term="algorithms" scheme="chenjuntong.me/tags/algorithms/"/>
<category term="algorithms" scheme="chenjuntong.me/categories/algorithms/"/>
</entry>
<entry>
<title><![CDATA[《Algorithms》摘录评注之贰：栈和队列]]></title>
<link href="chenjuntong.me/2015/11/25/alg-02/"/>
<id>chenjuntong.me/2015/11/25/alg-02/</id>
<published>2015-11-24T18:26:20.000Z</published>
<updated>2016-07-25T09:06:00.851Z</updated>
<content type="html"><![CDATA[<blockquote>
<p>本笔记基于<strong>ROBERT SEDGEWICK & KEVIN WAYNE</strong>开设的《Algorithms》课程，同时配有同名教材。<br>slides本身内容丰富详实，所以我会先甄选出重点的篇幅整理出来并做简单批注，后续会添上对应算法题的演示。</p>
</blockquote>
<p>栈和队列是两种基本的数据结构类型，它们有不同的方式去对存储的数据进行操作。<br>具体操作有：插入（push）、移除（pop）、迭代（iterate）以及检查是否为空等。<br>两者的差别主要是数据的移动顺序：<br>栈：后进先出<br>队列：先进先出<br><img src="http://static.zybuluo.com/JuntongCHEN/uuhtyzk98w5fu2fjr2m8kusr/image_1ansq3r2mvm31t82f19ko6o919.png" alt="image_1ansq3r2mvm31t82f19ko6o919.png-79kB"><br>栈的链表实现：<br><img src="http://static.zybuluo.com/JuntongCHEN/ugn9gcwzwf6ypiltckgjros2/image_1ansq7jqj999ep77nrh01ci51g.png" alt="image_1ansq7jqj999ep77nrh01ci51g.png-133.3kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/hciegdddfpjx3iel475mm97s/image_1ansq7rd7pftu4lc511471ss81t.png" alt="image_1ansq7rd7pftu4lc511471ss81t.png-146.3kB"><br>栈的数组实现：<br><img src="http://static.zybuluo.com/JuntongCHEN/pkiwai3r00xdxw5adakks9gc/image_1ansq88td1328kmia6k16f11bv92n.png" alt="image_1ansq88td1328kmia6k16f11bv92n.png-66.9kB"><br>正如我们在数组实现这里所看到的，我们定义的数组容量是有限的，那么就会存放的元素就会出现“上溢”（数组放不下，要满溢出来了）或“下溢”（数组已经空了，还进行操作）的情况，所以我们需要一种“伸缩自如”的机制来防止这种溢出情况的发生，称为“resizing-array”。<br><img src="http://static.zybuluo.com/JuntongCHEN/kf6rzappviqeiq2k5xc7vn2t/image_1ansq8mish7613g3c5c67q96g3h.png" alt="image_1ansq8mish7613g3c5c67q96g3h.png-90.6kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/1hovl2an0cc4xric2vk5kwvy/image_1ansq900j1nhf17pi15oa1jgnhus3u.png" alt="image_1ansq900j1nhf17pi15oa1jgnhus3u.png-77.6kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/mvwlqolb7e2ir0jimyuipplk/image_1ansq96po8bhpl71jnk1s3h9q4b.png" alt="image_1ansq96po8bhpl71jnk1s3h9q4b.png-149.3kB"><br>其具体实现方法：<br>“伸”：如果原来的数组已满，那么创建一个新数组，容量为原来的两倍，同时把原来数组的元素拷贝进新数组。<br>“缩”：如果数组中的元素减少为容量的四分之一时，把数组容量减少为原来的一半。</p>
<p>可伸缩的数组实现与链表实现对比：<br><img src="http://static.zybuluo.com/JuntongCHEN/a806iqg5fwnm1pyca88fawmg/image_1ansqalkspa51o8gtp91rfn1qn96c.png" alt="image_1ansqalkspa51o8gtp91rfn1qn96c.png-93.9kB"><br>队列的链表实现：<br><img src="http://static.zybuluo.com/JuntongCHEN/q4y4xiczeiuvgry464p2woj8/image_1ansqbcbg9ghdulhfv1n7d5c576.png" alt="image_1ansqbcbg9ghdulhfv1n7d5c576.png-145.4kB"><br>队列的数组实现：<br><img src="http://static.zybuluo.com/JuntongCHEN/rkthnmargwebp0xqd6x4d306/image_1ansqbq231r2g1g0jgcr1hri1s8780.png" alt="image_1ansqbq231r2g1g0jgcr1hri1s8780.png-75.3kB"><br>栈的应用实例，非常常见：比如浏览网页/打开文件夹后使用“后退”（回到最近的位置，后进先出）等等。<br><img src="http://static.zybuluo.com/JuntongCHEN/1obb57z6wtwb50jreru1exti/image_1ansqc82p5s918ap1tp4v2918ar8q.png" alt="image_1ansqc82p5s918ap1tp4v2918ar8q.png-131.6kB"></p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
]]></content>
<summary type="html">
<![CDATA[栈和队列是两种基本的数据结构类型，它们有不同的方式去对存储的数据进行操作。具体操作有：插入（push）、移除（pop）、迭代（iterate）以及检查是否为空等。两者的差别主要是数据的移动顺序。]]>
</summary>
<category term="algorithms" scheme="chenjuntong.me/tags/algorithms/"/>
<category term="algorithms" scheme="chenjuntong.me/categories/algorithms/"/>
</entry>
<entry>
<title><![CDATA[《Algorithms》摘录评注之壹：绪论]]></title>
<link href="chenjuntong.me/2015/11/24/alg-01/"/>
<id>chenjuntong.me/2015/11/24/alg-01/</id>
<published>2015-11-23T18:26:20.000Z</published>
<updated>2016-07-25T09:05:33.746Z</updated>
<content type="html"><![CDATA[<blockquote>
<p>本笔记基于<strong>ROBERT SEDGEWICK & KEVIN WAYNE</strong>开设的《Algorithms》课程，同时配有同名教材。<br>slides本身内容丰富详实，所以我会先甄选出重点的篇幅整理出来并做简单批注，后续会添上对应算法题的演示。</p>
</blockquote>
<p>课程总览：<br><img src="http://static.zybuluo.com/JuntongCHEN/b07nen0n86p5pppb5vowduna/image_1anntk63i12c61im5qn91nf6185b2a.png" alt="image_1anntk63i12c61im5qn91nf6185b2a.png-144.2kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/au9ap7ktzhn1vb51jndseims/image_1anntnleo1b4d1l1u1749edf55h2n.png" alt="image_1anntnleo1b4d1l1u1749edf55h2n.png-116.1kB"></p>
<p>使用<code>Quick-Find</code>方法来解决，直接对数组的每一个元素进行检查和操作：<br><img src="http://static.zybuluo.com/JuntongCHEN/ya2zuxf9fqbka89h0w06g3au/image_1anntorff1qrj1a1i5l1f9n1cgf3h.png" alt="image_1anntorff1qrj1a1i5l1f9n1cgf3h.png-82.6kB"><br>代码实现：<br><img src="http://static.zybuluo.com/JuntongCHEN/gqkp07l59bb8erfpm5m2e7bf/image_1anntpvmr1ek3prncji1tbi1tq94b.png" alt="image_1anntpvmr1ek3prncji1tbi1tq94b.png-60.2kB"></p>
<p>使用这个方法的问题是成本太高了，对<code>N</code>个目标进行<code>N</code>次<code>union</code>连接操作共需要访问数组N²次。<br>试一试别的方法：使用<code>Quick-Union</code>（懒人方法），通过对元素的“根”来进行检查和操作。<br><img src="http://static.zybuluo.com/JuntongCHEN/q096dgb4uzlnf64gwzr27yk1/image_1anpn728n3du3bck1f162g1bms9.png" alt="image_1anpn728n3du3bck1f162g1bms9.png-69.9kB"><br>代码实现：<br><img src="http://static.zybuluo.com/JuntongCHEN/d3a68l8g591cw73btiboiwog/image_1anpn838v3bjlh9fqhsk11ka61g.png" alt="image_1anpn838v3bjlh9fqhsk11ka61g.png-61.3kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/3tezd1txe3mj7bc56c9h7r6x/image_1anpn8jkq2gf1aisnicus61kc49.png" alt="image_1anpn8jkq2gf1aisnicus61kc49.png-54.7kB"><br>但这个懒人办法也太慢了。前一个<code>Q-Find</code>的<code>union</code>操作要访问N次数组，同时它的“树”（把元素连接起来的样子想象成是树的枝桠）是扁平的，但是保持这样的扁平代价太大；后一个<code>Q-U</code>的“树”会变得非常高，使其find操作也可能需要访问N次数组。那怎么办呢？只要在操作树的时候进行“权衡”就能两全其美啦：<br><img src="http://static.zybuluo.com/JuntongCHEN/ccrrs825o1ysrzdj2lkzz7dn/image_1anpn992ese0114k13n21703kp13.png" alt="image_1anpn992ese0114k13n21703kp13.png-68.2kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/r9naarr63qdlhywlv1l3ucd1/image_1anpn9fdmnkgbnd4eql4l6nf1g.png" alt="image_1anpn9fdmnkgbnd4eql4l6nf1g.png-116kB"></p>
<p>“权衡”之后<code>Q-Union</code>的树不再肆意地乱长，而是根据以小服大的方式比较均衡扁平地排列开来了。再想一想，还可以把树变得更加扁平吗？<br><img src="http://static.zybuluo.com/JuntongCHEN/izgeov2sy8b6m5rbzdhs1vzt/image_1anpna0setho17se1ifn1h3k17ul2a.png" alt="image_1anpna0setho17se1ifn1h3k17ul2a.png-58.6kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/u8airerxsjjhgu0pen6ylk3s/image_1anpna5uv9g51s9lst9anq1spu2n.png" alt="image_1anpna5uv9g51s9lst9anq1spu2n.png-54.9kB"><br>对，使用路径压缩！将检查过后的节点直接指向根，这样树就进一步扁平了。<br>对解决动态连接问题的这几种方法总结、对比一下，我们要追求在最坏情况下效率最高（成本最小）的方法：<br><img src="http://static.zybuluo.com/JuntongCHEN/3t4pmoq63r4z0nxacvu85c6e/image_1anpnaltkkdt43n1csu1b6o1j573h.png" alt="image_1anpnaltkkdt43n1csu1b6o1j573h.png-60.4kB"><br>现在来简单看一看如何分析算法（的效率/成本）：<br><img src="http://static.zybuluo.com/JuntongCHEN/oqfpnwdhgkv9pe2h0xvzgyam/image_1anpnb3s41fjbpal1v78vft1n5n4b.png" alt="image_1anpnb3s41fjbpal1v78vft1n5n4b.png-78.4kB"><br><img src="http://static.zybuluo.com/JuntongCHEN/at03dj6ceempqya4wcwkfmzs/image_1anpnb9pm13l223p1o9rcgsrfv4o.png" alt="image_1anpnb9pm13l223p1o9rcgsrfv4o.png-58.5kB"><br>使用“约等于”的波浪号标记来简化数字进行分析：<br><img src="http://static.zybuluo.com/JuntongCHEN/rvnoe455mwq93yib8r4h62cu/image_1anpnbvvrdja1bof19uonno4pb5i.png" alt="image_1anpnbvvrdja1bof19uonno4pb5i.png-93.4kB"><br>来看一下不同算法复杂度的增长速度：<br><img src="http://static.zybuluo.com/JuntongCHEN/xobmc54xbkeegkxxugmjtb5f/image_1anpnceq10hga6lpqphv376c.png" alt="image_1anpnceq10hga6lpqphv376c.png-116.6kB"><br>常用的用来标记算法复杂度的符号说明：<br><img src="http://static.zybuluo.com/JuntongCHEN/r1i9wy2go3yi3j324t3y4w8y/image_1anpng5lrk3jbq5gu81n7g1q1i7j.png" alt="image_1anpng5lrk3jbq5gu81n7g1q1i7j.png-42.8kB"></p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
]]></content>
<summary type="html">
<![CDATA[本笔记基于ROBERT SEDGEWICK & KEVIN WAYNE开设的《Algorithms》课程，同时配有同名教材。slides本身内容丰富详实，所以我会先甄选出重点的篇幅整理出来并做简单批注，后续会添上对应算法题的演示。这是第壹篇笔记，让我们首先对算法有个直观的认识。]]>
</summary>
<category term="algorithms" scheme="chenjuntong.me/tags/algorithms/"/>
<category term="algorithms" scheme="chenjuntong.me/categories/algorithms/"/>
</entry>
<entry>
<title><![CDATA[势单一定力薄？且看13罗汉如何纵横8大平台成功开发Quip]]></title>
<link href="chenjuntong.me/2015/11/01/qiup/"/>
<id>chenjuntong.me/2015/11/01/qiup/</id>
<published>2015-11-01T11:51:02.000Z</published>
<updated>2016-07-25T09:06:47.545Z</updated>
<content type="html"><![CDATA[<p><i class="icon-paste"></i> 原文地址：<a href="http://www.theeffectiveengineer.com/blog/how-to-successfully-build-great-products-with-small-teams" target="_blank" rel="external">How a Small Team of 13 Engineers Successfully Builds a Product on 8 Different Platforms</a><br><i class="icon-pencil"></i> <strong><em>作者：Edmond Lau</em></strong><br><i class="icon-edit-sign"></i> <strong><em>翻译：陈钧桐</em></strong><br><i class="icon-book"></i> <strong><em>整理定稿：覃超</em></strong></p>
<hr>
<p>在一个小巧玲珑如麻雀的团队里开发产品，你要怎么做才能孵化出一只万众瞩目的凤凰？</p>
<p>自从在Quora工作以来（以及最近在Quip的这些年），我一直在努力地思考这个问题。我是在Quora和Quip分别只有12人和13人的时候加入的。这两家初创企业都有雄心勃勃的使命。① Quora致力于分享和增长全世界的知识，同时建造一座互联网上的“亚历山大图书馆”。②在Quip，我们立志于打造出新一代的生产力工具，它能让每一家公司的每一个人在每一天使用起来都非常享受。</p>
<p>当你同时兼备一支小团队和壮志凌云的目标，惟一一个能成就伟业的方法就是专心在那些能带来巨大影响力的事情上——它们能为你的时间投资带来丰厚的回报。</p>
<p>目前为止在Quip里，这样以小搏大的项目最后都如愿以偿。我们已经能够签下越来越多喜欢这款产品的客户，包括Facebook，Pinterest，Stripe，Instacart，Product Hunt，New Relic，以及其他许多家喻户晓的名字。我们的产品线全面覆盖了8个不同的平台（web，Mac，Windows， iPhone，iPad，Android phones，Android tablets，以及Apple Watch）。而这一切，全靠我们13位工程师（包括两位联合创始人）。（大魔王：8个平台，13位工程师，实在是太厉害了。）</p>
<p>我们的征途依然是星辰大海，不过我在这里给出一些准则和方法，它们为我们这个小团队滚出了巨大的雪球。</p>
<h2 id="1-_Build_once,_use_multiple_times">1. Build once, use multiple times</h2><h3 id="只造一次，随处可用">只造一次，随处可用</h3><p>无论你在写软件的任何时候，优秀的抽象编程总是至关重要的，能横跨不同平台的抽象编程对我们这个小团队尤为宝贵。假如我们不得不分别在8个不同平台上从头开始构建产品，我们就不可能走到今天这么远。所以我们在库和体系架构方面投入了大量的精力，来确保我们只用造一次轮子就能在多个平台使用。</p>
<p>举个例子，我们在数据存储、内存数据结构以及跨平台通讯上广泛地使用 Protocol Buffers（译者注：谷歌开发的一种可扩展的结构化数据存储格式）。这让我们能够便捷地完成很多事情，比如直接从MySQL读取Protocol Buffers③；在Python 网页服务器上修改数据；然后把它们发送给我们的 native clients（译者注：谷歌开发的一种可以让浏览器直接运行机器码的沙盒技术），这些native clients上使用的数种语言包括C++，Objective C，Java或者C#；甚至还可以把那些相同的数据结构下载到我们的JavaScript编辑器。此外，所有这些操作都是通过自动生成的数据串行化代码完成的（data serialization code），有着强类型数据结构的它们同时运行在强类型的通讯渠道上。假如我们使用的特定语言专用的数据结构或者甚至是JSON，通过如此繁杂的步骤来处理数据不仅将会变得非常乏味，而且也会容易出错。</p>
<p>“只造一次，随处可用”的精神在其他许多场合也有体现。为了在桌面版、移动端上同步数据以及支持其离线使用，我们使用了相同的C++库。横跨所有设备的文档编辑器都运行在相同的JavaScript库上——然后再针对各自平台进行优化，让用户体验变得更加流畅完美。我们的网页版，Mac和Windows桌面应用都是共用了同一套React的UI代码，使其在各自平台上都更接近于原生应用。④</p>
<p>使用这些技术并不意味着一劳永逸地解决所有麻烦，但是它们确实大大减轻了工作量。</p>
<h2 id="2-_Take_advantage_of_in-network_referrals_for_hiring">2. Take advantage of in-network referrals for hiring</h2><h3 id="在招聘上利用好人际网络的引荐">在招聘上利用好人际网络的引荐</h3><p>在我有幸共事过的团队中，Quip有着最聪明的那撮人。在开发方面，团队里的绝大部分人拥有至少6年的从业经验，甚至超过一半工程师的经验超过10年。</p>
<p>对于初创企业来说，掌握如此丰富的从业经验弥足珍贵：我们能靠一己之力去解决遇到的困难，我们相信每一个人都在做正确的东西。与有着更多初级工程师的团队相比，我们并不需要花太多的时间去培养新员工。显然，我们同时也可以避免早期职业生涯已经犯过的错误，这样可以显著提高数倍A/B测试框架或者监视系统的效率。从业经验让我们在解决产品挑战方面更加游刃有余。</p>
<p>为了组建这样的团队，我们很好地利用了人际网络的引荐。许多Quip工程师在加入前就曾经共事过，这样就减少了招聘过程中的风险和麻烦。即使你的职业生涯刚起步，与你喜欢共事的朋友保持联系也是很重要的。来日方长，也许你能找到不错的机会重新在一起工作。</p>
<h2 id="3-_Invest_heavily_in_tooling">3. Invest heavily in tooling</h2><h3 id="在工具化上投入大量精力">在工具化上投入大量精力</h3><p>小魔王插播：Facebook早年和现在一直就在 internal tools 组里投入了特别厉害的工程师来开发内部的各种工具。比如我们的任务管理工具 task，代码审核和查看工具 phabricator，以及后来的各种基础设施、数据分析和统计工具，比如：Heystack，Scribe，PTail。而即使现在名声大噪的 Kafka，之前也只是LinkedIn的一个内部基础设施项目。但是国内公司我经常发现工程师们对于做工具或者做内部设施没啥兴趣，只喜欢做看得见摸得着的界面或者功能，殊不知这些界面和功能都是PM和设计还有老板们说的算，技术含量也并不高。</p>
<p>工具链能让你的回报加倍。随着时间的积累，它们的益处也会越来越明显。在Quip，我们造了大量工具来帮助我们更快地进行开发：比如能够使用堆栈跟踪来收集统计错误的表盘；比如能用来调试错误和检查状态的工具；比如能分析代码和查出一般错误的git commit hooks；以及其他许多自动化脚本来执行各种枯燥乏味的任务。我们实现了从性能指标到客户留存率的数据可视化，这样我们就能更清楚地了解目前的进展。我们为自己的售后部门和业务部门开发了内部专用的工具，这样他们就能帮助客户快速地处理任何问题。</p>
<p>专注于工具化同时也节约了我们的运营开销。持续不断的内部整合让我们的公司保持在健康状态，部署自动化脚本简化了我们的发布流程。精细化的（程序）警报大大减轻了工作压力，比如这些警报只会在工作时间推送给随叫随到的工程师。最终的结果是，与我所工作过的其他创业公司相比，Quip分配的“寻呼机”几乎形同虚设——过去的一年时间里我只有两三次是在半夜里收到警报推送的。所有在工具化上的投入让我们能把更多的时间分配给开发新功能，而不只是花在维护上。</p>
<h2 id="4-_Put_more_wood_behind_fewer_arrows">4. Put more wood behind fewer arrows</h2><h3 id="有的放矢">有的放矢</h3><p>我们列出了无数乐于去改进或开发的功能，但时间和资源都是有限的。所以我们应该把精力集中在关键的里程碑（事物）上，同时主动地为功能和bug进行优先级排序也很重要，这样我们的战线就不会拉得太长。任务切换的开销非常大，我们选择不做什么跟选择做什么是同等重要的。</p>
<p>在这方面，用户的反馈无论是数量上还是质量上都尤为宝贵。对于A/B测试来说，我们会努力地把所有想法分解成为可以进行测试论证的假设，这样我们就能进行评估以少走弯路。在功能层面，我们可以先开发出一个最小化的可用产品，然后进行用户测试来收集所有原始反馈，以此来了解客户哪里不明白，以及是哪方面起了作用。或者有时候，我们也可以为少数客户推出一项新功能，然后通过与他们紧密地联系与合作，了解他们喜欢什么，讨厌什么。</p>
<p>比方说当发布Mac版和Windows版的应用时，我们是在不同阶段将它们推送给员工、alpha测试者和beta测试者的（基于他们想成为早期试用者的意愿值，以及对bug的容忍度）。他们的反馈（当然是利用Quip）帮助我们把精力集中在桌面应用用户最关心的功能上面。我们可以把其他功能需求稍作推迟。</p>
<h2 id="5-_Reduce_the_friction_of_communication">5. Reduce the friction of communication</h2><h3 id="减少沟通上的摩擦">减少沟通上的摩擦</h3><p>对于开发团队来说，电子邮件和会议可以说是精力的两大黑洞 （大魔王：注意！）。所以在Quip，我们普遍都很排斥它们。除了进行 code review 以及发布几种主要类型的警报，我们在内部并不通过电子邮件进行技术沟通。在平常的每个星期，工程师只用开一个小时的例会：30分钟的全员会议是我们分享各自进展以及展示Demo的场合，在这之后也许会有若干小项目的内部会议，或者一对一的单独沟通。必要时我们会专门开有针对性的会。</p>
<p>我们之间大部分的沟通交流理所当然是通过Quip。这款产品是我们如何在公司里进行协作的法宝，我们每天都通过它完成任何事。我们使用Quip来设计文档，列任务清单，给客户提供支持，还有聊天。我们还为Pager Duty，Zendesk，Twitter，Jenkins，Stripe，Crashlytics，Github以及很多公司内置了 integrations 功能，这样一旦有任何事情发生，他们整个团队讨论起来就方便多了。如果有一位用户在推特上报告了一个bug并@了QuipSupport，那么在Quip内浏览推特聊天频道的任何一个人都可以直接@一位工程师然后问他是否已知晓这个bug。如果客户成功部门（Customer Success）或者某位销售员想要转达来自客户的功能需求，她可以把它加在反馈文件或者待办事项中，相关负责人会立即介入，并为此项工作列出优先级别。我们甚至有一份和本地三明治&沙拉餐厅共享的文档，我们只要输入午餐菜单，棒棒的外卖小哥每天中午就会把它们送到办公室。</p>
<p>纵观一个团队的成长进程，沟通通常是第一个碰上的大麻烦，任何能减少沟通摩擦的工具——无论它是Quip，Slack或者其他东西——都可以显著地提高团队的工作效率。把Quip整合到团队的工作流中让我们得以通力合作，这是传统如电子邮件和会议的沟通方式不可能达到的效果。同时它也帮助公司建立起公开透明的文化，因为邮件里的信息会在一部分收件人手里沉默。相比之下，Quip 的文档正逐渐成为团队里每一位成员愈发丰富的知识宝库。每一份文档的留言和讨论都有据可查，我们所有人都在同一页上。</p>
<p>我们如今已经取得了很多进步，但前方漫漫长路依然充满挑战。假如你对在Quip工作很感兴趣，不妨移步到我们的招聘页面。假如你想要学习更多的具有可操作性以及经证实的方法策略来成为一名高效工程师，不妨看一下我的这本书，《The Effective Engineer》。</p>
<p>这篇文章基于我在Quora上最开始写的一个答案，Slate也有转载。<br>①除了雄心壮志，Quora和Quip在许多方面都有共同点。它们都是由前Facebook CTO创立的，都从Benchmark风投拿到了A轮融资，当然，也都是从Qu起步的。<br>②我们的使命，来自Quora博客。<br>③我们的MySQL数据存储使用了一种类似于FriendFeed的非模式化MySQL设计，不同的是，我们并不使用Python对象序列化方法，而是采用了Protocol Buffers。<br>④Bret Taylor（译者注：Quip的创始人，前Facebook CTO）写过一篇更加鞭辟入里的技术文章，其详细描述了我们（在产品中）共同的C++库和React架构：React with C++: Building the Quip Mac and Windows Apps.</p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
]]></content>
<summary type="html">
<![CDATA[在一个小巧玲珑如麻雀的团队里开发产品，你要怎么做才能孵化出一只万众瞩目的凤凰？自从在Quora工作以来（以及最近在Quip的这些年），我一直在努力地思考这个问题。我是在Quora和Quip分别只有12人和13人的时候加入的。这两家初创企业都有雄心勃勃的使命。Quora致力于分享和增长全世界的知识，同时建造一座互联网上的“亚历山大图书馆”。在Quip，我们立志于打造出新一代的生产力工具，它能让每一家公司的每一个人在每一天使用起来都非常享受。]]>
</summary>
<category term="创业故事" scheme="chenjuntong.me/tags/%E5%88%9B%E4%B8%9A%E6%95%85%E4%BA%8B/"/>
<category term="英文科技文章翻译" scheme="chenjuntong.me/tags/%E8%8B%B1%E6%96%87%E7%A7%91%E6%8A%80%E6%96%87%E7%AB%A0%E7%BF%BB%E8%AF%91/"/>
<category term="英文翻译" scheme="chenjuntong.me/categories/%E8%8B%B1%E6%96%87%E7%BF%BB%E8%AF%91/"/>
</entry>
<entry>
<title><![CDATA[缔造Instagram的这五年]]></title>
<link href="chenjuntong.me/2015/10/29/instagram/"/>
<id>chenjuntong.me/2015/10/29/instagram/</id>
<published>2015-10-29T01:52:28.000Z</published>
<updated>2016-07-25T09:06:37.754Z</updated>
<content type="html"><![CDATA[<p><i class="icon-paste"></i> 原文地址：<a href="https://medium.com/backchannel/war-stories-3696d00207ff" target="_blank" rel="external">War Stories: Five Years of Building Instagram</a><br><i class="icon-pencil"></i> <strong><em>作者：Mike Krieger</em></strong><br><i class="icon-edit-sign"></i> <strong><em>翻译：陈钧桐</em></strong><br><i class="icon-book"></i> <strong><em>整理定稿：覃超</em></strong></p>
<hr>
<p> 2010年，在我们发布Instagram第一个版本的前一晚，我与联合创始人Kevin打赌，第一天大概会有多少人下载这款app。Kevin猜有2500人，我当时特别乐观，赌了把大的，押25000人。第二天，我简直不敢相信我的猜测分毫不差。<br> 今天，在Instagram的五周岁之际，我们拥有来自世界各地的4亿用户，他们每天上传8000万份相片和视频。回望过去，我们在初代产品上就做到了在简洁和精巧中取得恰到好处的平衡，同时就在去年，我们回炉重造了「搜索&发现」（Search & Explore）功能，发布了全新的私密分享功能「Instagram Direct」，如「Layout」这样的创意拼图工具也应运而生。<br> 过去5年，我们的团队一直在（谢天谢地）成长和进步，我们坚持恪守我们的信条：简单的事情先做，它也是下一个五年计划的核心。在这里我将回顾从搭建Instagram起过去的五年时间里，其中一些最重大的里程碑事件——有好的，有坏的，还有出乎意料的。我希望这里的一些经验教训能帮你们打造自己的团队和公司，使其茁壮成长。</p>
<h2 id="里程碑_#1：头三个月解锁1百万用户成就">里程碑 #1：头三个月解锁1百万用户成就</h2><h3 id="归档：最大的挑战">归档：最大的挑战</h3><p> 上线第一个月的惨状不忍直视——经常凌晨3点睡眼惺忪打开屏幕，上面的服务器警信息接踵而至。自第一天爆炸性地吸引了25000名用户后，数量就持续高速增长直至解锁1百万成就。<br> 请脑补一下这个场面：争先恐后的人们迫切想要使用你的产品！世上没有任何号角能比这更能激励士气的了，所以我们开启996模式以确保我们可以承受住与日俱增的访问请求。我们起步的时候只用了一台位于洛杉矶的服务器，其性能还不如一台Macbook Pro。当我打电话给主机服务商，要求根据我们第一天的增长情况再添置一台服务器时，他们回复说需要4天的周转期，快马加鞭的话也得要48个小时。鉴于我们的增长态势看起来深不可测，我们决定转移到亚马逊的AWS云服务器上面去。<br> 由于我们两个都缺乏系统底层架构的经验，我们只能尽所能地狼吞虎咽相关的知识。在<a href="http://www.infoq.com/presentations/" target="_blank" rel="external">QCon</a>和<a href="https://www.youtube.com/user/OreillyMedia" target="_blank" rel="external">Velocity</a>的上面有非常棒的会议视频，还有来自 Facebook, Netflix, Twitter以及其他公司的文章。共享技术知识的开源文化是我们这一行最棒的事情之一了，它也是我们更新维护日志的主要推动力。</p>
<p> 干货总结：我们的信条，“简单的事情先做”脱胎于最初的岁月。因为只有我们两个人并肩作战，所以每当我们面临新的挑战时，我们不得不采用最快的、最简单的解决办法。假如我们以完美的态度要求每一件事情，那我们很有可能在无所作为中灭亡。通过找出最先需要解决的问题，以及选择最简单的解决办法，我们才有能力支撑起我们的指数型增长。</p>
<h2 id="里程碑_#2：发布安卓版Instagram">里程碑 #2：发布安卓版Instagram</h2><h3 id="归档：最众望所归的发布">归档：最众望所归的发布</h3><p> 在Instagram发布的头几年里，Kevin和我每一次在台上都会被问到同一个问题，“安卓版的应用到底什么时候才会出来？！”<br> 我们从iOS版起家——仅仅是因为我们想要在我们的产品上做到快速迭代——毕竟我们只有两个工程师。当跨入2012年后，是时候扩展到其他不同的平台了。我们的安卓版app也是典型的Instagram风格，以Philip领衔的三位工程师在三个月内做出来了，其中两位的安卓开发还是现学现卖的。Philip是在我们开发另一款软件Gowalla的安卓版app时加入的，直到今天他依然领导着Instagram的移动化。<br> 因为我们想要在尽可能多的安卓手机上测试我们的app，甚至包括华为的一款冷门手机“M865 Ascend II 2 Touch”，所以有时候我化身为“eBay皇冠买家”。大多数时候，新手机的屁股还没在办公桌上坐热，我们就立即拆掉快递盒装上我们的半成品app试运行，然后为app的运行效果赞不绝口。安卓设备的产品线之广以至于我们面临了一些挑战——特别是当我们开发Instagram的视频功能时——但最终安卓版app做到了稳定运行在如此之多的手机上而不怎么需要针对某些机型做特殊修改，不得不说太给力了。<br> <br><img src="http://ww4.sinaimg.cn/large/6ccda21fjw1ex67ey3yilj210m0l4dkh.jpg" alt="HTC"></p>
<p> 安卓版上线刚12个小时，用户量就突破了100万——反响之热切真是太不可思议了。也就在那个时候，我写了几篇关于系统底层架构设计的文章。斗转星移，Instagram的安卓版使用起来更像是原生软件了，如今它也成为了流畅度、评分最高的安卓应用之一。<br> <br> 干货总结：从单一平台上起步允许我们沉下心来快速迭代，并且没有兼容性的负担（我们在Instagram内部经常说“做事要少而精”）。当扩展到多个平台的时候，我们成立了一只全新的、以拥有深厚安卓开发功力的天才工程师为首的小队伍。斗转参横，羽翼渐丰的安卓开发团队将让我们的应用更接近原生。</p>
<p><img src="http://ww2.sinaimg.cn/large/6ccda21fjw1ex67g4lh3aj20du0p4mz5.jpg" alt="NBA"></p>
<h2 id="里程碑_#3_2012维吉尼亚风暴">里程碑 #3 2012维吉尼亚风暴</h2><h3 id="归档：最严重的突发状况">归档：最严重的突发状况</h3><p> 2012年中的某个周末，我正在波兰渡假，这时手机嗡嗡响起来：“Instagram.com宕机了。”我火速上网做了测试，发现不只是Instagram——Netflix以及其他网站都纷纷躺枪了。我赶回酒店打开笔记本，AWS云服务器状态页上一条可怕的消息赫然在目：“美国东部的电力供应中断了”。一场巨大的风暴从维吉尼亚州呼啸而过，并且卷走了我们大半服务器的电力。接下来的36个小时俨然成为一场重建几乎整个底层系统的攻坚战。乌云背后唯一的幸福线就是这催生出一张病毒式传播的图片：</p>
<p><img src="http://ww1.sinaimg.cn/large/6ccda21fjw1ex6bhyzzvsj20dc09pq3o.jpg" alt="DOWN"></p>
<p> 在那个时候，我们整个后端技术团队由我自己，我们第一个工程师Shayne以及Rick组成，Rick加入Instagram还不到一个月的时间。所幸没有任何用户数据丢失，但是这次意外暴露出我们在系统底层架构自动化上还有许多坑亟待填补。<br> 这次意外给我们脸上来了一记响亮的耳刮子，我们需要找到一种可以重复使用的服务器配置方法。次年，我们把不稳定的shell脚本迁移到了全Chef系统，这也大幅降低了新团队成员上手底层架构的门槛。<br> 与此同时，我们不再依赖亚马逊的持久性数据块级存储卷方案（Elastic Block Storage），取而代之的是<a href="https://github.com/wal-e/wal-e" target="_blank" rel="external">WAL-E</a>以及Postgres家的WAL shipping replication方案。我们也建造了一个可靠的交叉数据中心，这让Instagram的数据得以分布式地存储到不同的地理位置。</p>
<p> 干货总结：架设自动化脚本的底层架构需要大量的前期工作，不过这可是一本万利，新工程师将能很快融入项目本身，另外这样做也能在突发状况中立功。另外，我很高兴我们雇佣了点对技能点的工程师——当我们面前摆着这样一个惨不忍睹的烂摊子时，Shayne和Rick都撸起他们的袖子立马开始收拾，遇到这种意外，堪比《火星救援》。</p>
<h2 id="里程碑_#4：服务器迁移——Instagration">里程碑 #4：服务器迁移——Instagration</h2><h3 id="归档：最壮志凌云的工程">归档：最壮志凌云的工程</h3><p>2010年10月5日：0用户<br>2010年10月6日：25000用户<br>2010年11月：1百万用户<br>2012：3千万用户<br>2013：2亿用户</p>
<p> 在2013年的时候我们拥有2亿活跃用户，超过200亿张相片存储在服务器上。整个团队虽然在扩张，但规模仍然较小，所有人对于Instagram社区的持续成长感到欣喜万分。<br> 与此同时，我们想要跟Facebook已有的后台系统进行整合——举个例子，他们的Site Integrity系统对帮助我们抵抗垃圾邮件的侵扰至关重要。但在亚马逊AWS云服务器上做这些整合会非常困难，而我们拖得越久，那迁移越来越庞大的底层系统将日益艰巨。<br> 我们迁移去Facebook的后台系统是板上钉钉的事了，但我们想在不中断运营的情况下迁移数以百万计的用户和数以亿计的相片。所以我们开始了Instagration工程，或者我更喜欢将其描述为为给一辆时度100迈的汽车改头换面。一支由8个来自Instagram和Facebook的工程师组成的小队先建起一个共有网络，然后使用自家建造的叫Neti的工具把Instagram从EC2迁移到亚马逊的虚拟私有云 (Virtual Private Cloud)上。接下来迁移我们的系统和工具，其中包括使用一个“ig”的命令行工具，以此在新的FB数据中心搭建类似AWS的开发环境。最终我们花了最小的代价完成了这次大规模迁移。</p>
<p> 干货总结：不要重复造轮子。通过迁移到Facebook的服务器，我们的后台系统运行得更快、更有效率，同时也能利用Facebook其他比如反垃圾邮件这样的工具。利用Facebook的资源和经验，我们的尖刀排不需要扩招变得臃肿，从而使行动更风驰电掣。</p>
<h2 id="里程碑_#5：Instagram的「趋势」">里程碑 #5：Instagram的「趋势」</h2><h3 id="归档：下一个大赌注">归档：下一个大赌注</h3><p> 今年早些时候，我们对「搜索&发现」（Search & Explore）这个功能进行了完善，使得人们在Instagram上能更方便找到世界上每个角落发生的有趣事情。我们引进了「热门标签和地点」，并且搭建了用于甄别以及排序筛选的全新的机制，来给用户推荐Instagram上的精华。<br> 我们第一次对「趋势」的尝试始于2010年发布Instagram，当时采用的是「流行」（Popular）页面。整个算法十分简单：计算每张相片的点赞数，每4小时清零。当我们的社区规模还是比较小的时候，这个算法非常好用。但随着时间推移，我们意识到我们需要一个更细致入微的算法。<br> 鉴于社区规模之庞大，我们在2014年致力于个性化「发现」（Explore ）功能，其所展示的是针对每一个用户兴趣胃口生成的、可无限下拉查看的相片和视频。与非量身定做的「发现」相比，我们的用户在短短数个月内与内容互动的比例提高了5倍。今年，我们带着最初做「流行」（Popular）页面的理念重新登场，并将其升级为「趋势」——其能快速一览整个Instagram上面的内容。随着排序和机器学习专家的陆续加入，我们越来越有能力基于复杂算法生成出更加个性化的「趋势」。</p>
<p> 干货总结：简单的事情先做并不意味着你的解决办法能一劳永逸。我们已经学会对产品的演化进步保持开放的心态，有针对性地建立队伍——比如我们的数据科学队伍，以此应对快速扩张的Instagram社区。</p>
<p> 过去的五年对于我们中间很多人来说是一次激动人心的狂野之旅。在Instagram 5周岁生日之际，停下来回顾反思是极好的。我很确信我们的社区会持续成长，我们的产品也会更上一层楼，在Medium上从来就不缺“回顾我过去十年”这样的文章。让我们为下一个五年干杯！</p>
<p>扩展阅读：<a href="https://www.quora.com/What-is-the-genesis-of-Instagram" target="_blank" rel="external">https://www.quora.com/What-is-the-genesis-of-Instagram</a></p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
]]></content>
<summary type="html">
<![CDATA[过去5年，我们的团队一直在（谢天谢地）成长和进步，我们坚持恪守我们的信条：简单的事情先做，它也是下一个五年计划的核心。在这里我将回顾从搭建Instagram起过去的五年时间里，其中一些最重大的里程碑事件——有好的，有坏的，还有出乎意料的。我希望这里的一些经验教训能帮你们打造自己的团队和公司，使其茁壮成长。]]>
</summary>
<category term="英文科技文章翻译" scheme="chenjuntong.me/tags/%E8%8B%B1%E6%96%87%E7%A7%91%E6%8A%80%E6%96%87%E7%AB%A0%E7%BF%BB%E8%AF%91/"/>
<category term="英文翻译" scheme="chenjuntong.me/categories/%E8%8B%B1%E6%96%87%E7%BF%BB%E8%AF%91/"/>
</entry>
<entry>
<title><![CDATA[「钢铁侠现实版」Elon Musk - 地球上最炫酷的人]]></title>
<link href="chenjuntong.me/2015/08/23/elon%20musk/"/>
<id>chenjuntong.me/2015/08/23/elon musk/</id>
<published>2015-08-23T08:17:38.000Z</published>
<updated>2016-07-25T09:06:26.050Z</updated>
<content type="html"><![CDATA[<p><i class="icon-paste"></i> 原文地址：<a href="http://waitbutwhy.com/2015/05/elon-musk-the-worlds-raddest-man.html" target="_blank" rel="external">Elon Musk: The World’s Raddest Man</a><br><i class="icon-pencil"></i> <strong><em>作者：Tim Urban</em></strong><br><i class="icon-edit-sign"></i> <strong><em>翻译：陈钧桐</em></strong><br><i class="icon-book"></i> <strong><em>整理定稿：覃超</em></strong></p>
<hr>
<p> 上个月，我接到一个让我虎躯一震的电话。<br><img src="http://ww3.sinaimg.cn/large/6ccda21fgw1eu3frc7dnfj20ul0oxdgt.jpg" alt="Call1"></p>
<p><img src="http://ww1.sinaimg.cn/large/6ccda21fgw1eu753sfbftj21jk0vyjwl.jpg" alt="Call2"></p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/Call-2b.png" alt="Call3"></p>
<p><img src="http://ww1.sinaimg.cn/large/6ccda21fgw1eu3icdehoaj21jk0vyn1e.jpg" alt="Call4"></p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/Call-4.png" alt="Call5"></p>
<p><img src="http://ww2.sinaimg.cn/large/6ccda21fgw1eu3iml43wjj21jk0vy41t.jpg" alt="Call6"></p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/Call-6.png" alt="Call7"></p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/Call-7.png" alt="Call8"></p>
<p><img src="http://ww2.sinaimg.cn/large/6ccda21fgw1eu3j1svftej21jk0vygqq.jpg" alt="Call9"></p>
<p> <strong>对于那些不熟悉Elon Musk的人来说，他是这个地球上最炫酷的人。</strong></p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/Untitled-4.jpg" alt="Em"></p>
<hr>
<p> 我将通过这篇文章去探索揭秘身他是如何白手起家成为亿万富翁和现实中的Tony Stark（译者注：钢铁侠在电影中的名字）。不过现在，还是引用传奇亿万富翁Richard Branson的一小段话来为这场好戏拉开序幕吧：<br> <em>不管外界质疑声是多么地此起彼伏，Elon总能如有神助般地把废铜烂铁变为如意金箍，借定海神针平息一切。回想一下在20世纪90年代的时候，我们会把自己的信用卡号码给素不相识的陌生人吗？然而Elon创造了一个叫PayPal的小玩意儿，结局今天你们也都知道了。他的特斯拉汽车和SolarCity公司正在把能源可再生的纤尘不染的未来天堂挪到地上……他的SpaceX正在重新探索太空……矛盾的是，一方面Elon在努力改善我们所居住的地球，另一方面他又为了帮助我们离开地球而在建造太空飞船。</em></p>
<p> 当然，这并不是我所期待的通话内容。<br> 几天之后，我晃过神来发现自己正穿着睡裤在家里疯狂地来回踱步，举到耳边的手机正在跟Elon Musk通着电话。我们展开了一场关于特斯拉、SpaceX、汽车业、航空航天业、太阳能产业的讨论，他还告诉我他的所作所为让很多人摸不着头脑。他提议道，如果这些话题中有我所感兴趣、对我写作有帮助的，我可以去加利福尼亚跟他本人坐下来秉烛夜谈。</p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/2Call1.png" alt="Call10"></p>
<p><img src="http://ww4.sinaimg.cn/large/6ccda21fgw1eu3pvw5jd9j20sg0jamyf.jpg" alt="Call11"></p>
<p> 对我来说，想都不用想就该走起。不仅仅因为他是独一无二的Elon Musk，也因为我有两篇关于未来主题的文章很想写，只是苦于没有素材，主题逐字誊写如下：</p>
<p>-“电力驱动vs混合动力vs汽油驱动汽车，特斯拉的可持续能源战略”</p>
<p>-“SpaceX公司，Musk，火星？？怎么学会造火箭？？”</p>
<p> 我已经蓄势待发去好好写写这些主题了，这样做的原因跟我写<a href="http://waitbutwhy.com/2015/01/artificial-intelligence-revolution-1.html" target="_blank" rel="external">人工智能</a>(<a href="http://zhuanlan.zhihu.com/xiepanda/19950456" target="_blank" rel="external">中文版</a>)那篇文章时如出一辙——虽然我现在还不能完全理解它们，但在未来它们一定起着举足轻重的作用。并且Musk正在大闹汽车和火箭两个天宫。<br> 这感觉就像是你正打算描述雷电形成的过程，然后有天宙斯打电话问你是不是有一大堆问题想问。</p>
<p> 就这样，我要快马加鞭了。整个计划就是我飞去加利福利亚，参观特斯拉和SpaceX的工厂，与每一家公司的工程师见面唠嗑唠嗑，最后再和Musk坐下来谈笑风生。<strong><em>想想就很激动呢！</em></strong><br> 然而计划一开头就够我喝一壶了。如果我对那些领域一无所知的话，我必须避免和那些家伙并肩同坐——那些可是世界一流的工程师和火箭科学家。看来我有一大堆知识要恶补了。</p>
<p>我要问Elon·牛逼·Musk的问题涉足了以下<strong><em>所有</em></strong>的产业：</p>
<ul>
<li>汽车</li>
<li>航空航天</li>
<li>太阳能</li>
<li>人造卫星</li>
<li>能源储备</li>
<li>高速地面交通工具</li>
<li>还有，呃，超行星扩张</li>
</ul>
<p>相比之下宙斯的工作压力都会轻松许多。</p>
<p> 所以我为了准备西海岸之行，花了整整两个星期废寝忘食地阅读，并且我很快清楚地意识到这系列文章的主题肯定会是五花八门的，实在是要涉猎太多的东西了。<br> 在接下来的文章中，我们将会深入Musk的公司和工厂。但现在，让我们首先了解下这个家伙究竟是怎样一个人，以及为什么他能成为齐天大圣。
</p>
<h2 id="Elon_Musk的成才之路">Elon Musk的成才之路</h2><p><em>提示：5月19日将会有一本很棒的Musk传记面世，作者是科技作家Ashlee Vance。我得到了一份样稿，并且发现它是把这一系列文章串起来的关键钥匙。我打算在这里带领你们简短地回顾一下Musk的人生——如果你想了解更多，<a href="http://www.amazon.cn/Elon-Musk-How-the-Billionaire-CEO-of-SpaceX-and-Tesla-is-shaping-our-Future-Vance-Ashlee/dp/B00SIDCSWY/ref=tmm_kin_title_0?_encoding=UTF8&sr=8-1&qid=1437021781" target="_blank" rel="external">去买这本书吧！</a></em></p>
<p> Musk于1971年出生在南非。他的童年并非无忧无虑——家庭环境困苦，永远不适应学校生活。但是，正如你经常在伟人传记中读到的一样，对知识如饮甘霖的他很早就开始自学了。他的弟弟Kimbal回忆说，Elon那时每天经常读10个小时书以上——一般都是科幻小说，后来，浩如烟海的非小说类书籍也进入了他的阅读书单。在四年级的时候，他开始坚持不懈地醉心于研读《大英百科全书》了。<br> 你将从Musk身上学到的一个启发是，他把人类当作计算机，当然不是字面意思，而是在本质上做类比。一个人的硬件是他的身躯和大脑，他的软件是他学习思考的方式、他的三观、他的习惯以及他的个性。对于Musk来说，学习就像是“把数据和算法下载进大脑”的过程。当他还坐在教室里听老师照本宣科时，最不爽的事之一便是“龟速的下载速度”——直到今天，他的大部分知识都来源于自学。<br> 在他9岁那年，他拥有了第一部电脑<a href="https://en.wikipedia.org/wiki/Commodore_VIC-20" target="_blank" rel="external">Commodore VIC-20</a> ，从此玩电子游戏成了他的第二大爱好。这部电脑配有5千字节的内存，还附送了一份“如何编程”的指南，正常来说读者要花6个月才学得完，9岁的Elon在3天内就读完它了。在12岁的时候，他运用他所学的知识开发了一款叫Blastar的小游戏，这款游戏用他的话说“只是一个微不足道的游戏罢了……不过比Flappy Bird好玩多了。”但是在1983年，一家电脑杂志社以500美元的价格购买了它（相当于今天的1200美元）——这对于一个12岁的小男孩来说还不赖。</p>
<p> Musk永远都不觉得自己跟南非有多大羁绊——他没有融入当地的白人文化，并且那里对于一个潜在的创业家来说就是一个噩梦般的国度。他把硅谷看作是迦南（译者注：《旧约》中的圣地），并且在17岁那年永远地离开了南非。由于他母亲是加拿大公民的关系，这里移民更容易，他决定从加拿大起步。数年之后，通过大学转学到宾夕法尼亚大学的方式，Musk进入了美国。<br> 在大学里，他以下面这个问题作为出发点，开始思索这辈子最想要干什么——“在未来什么东西能对人类产生最深远的影响？”脑海里随之蹦出来的，是一份包含五个东西的列表：“互联网；可持续能源；太空探索，特别是超越地球个体的永恒生命延伸；人工智能；以及人类基因密码重组。”<br> <br> 他对后两者的影响有多大积极性表示怀疑，但他对前三者的每一项都感到乐观，而他当时也没想到有朝一日会参与进太空探索。这样他投身奋斗的选项就剩下互联网和可持续能源了。<br> 他决定从可持续能源入手。在完成大学学业之后，他报读了一个斯坦福博士项目以学习高密度能量储存装置，这项技术目标在于开发一种比传统电池更高效率的能量储存方法——他知道这是开启通往未来可持续能源的关键钥匙，并且能加速电动汽车时代的到来。</p>
<p> 但在入学的两天之后，害怕错过有趣事物的心态淹没了他，因为那是1995年，他“没办法眼睁睁看着互联网擦身而过——（他）想要纵身跃进互联网浪潮并增益其所不能。”所以他反而决定退学并去尝试互联网。<br> 他的首要行动就是试着去1995年的互联网巨兽网景公司谋一份差事。他能想出来的策略就是被当作不速之客走进大厅里，然后尴尬地站在那里——他太害羞以至于跟任何人都开不了口，最后悻悻然地走出来。<br> <br> Musk默默无名的生涯逆袭之路始于与他弟弟Kimbal（他也随Elon来到美国）一起创立的新公司Zip2。Zip2就像是Yelp（译者注：美国最大点评网站）和谷歌地图的粗糙结合，但贵为任何类似产品的开山鼻祖。它的目标是让企业们意识到黄页的时代终将逝去，从而自己放上在线目录会是一个更棒的想法。这哥儿俩一贫如洗，睡在办公室、洗在YMCA（译者注：Young Men’s Christian Association，基督教青年会），而作为主力程序员的Elon在电脑上日以继夜地工作，码红了眼。</p>
<p> 在1995那个年代，很难说服企业们相信“互联网至关重要”，很多人告诉这两哥儿们，在互联网上投放广告听起来就像是“愚蠢透底的主意”——但最终，他们还是争取到了顾客，公司也在茁壮成长。90年代互联网蓬勃发展，初创公司往往捞一票就走。到了1999年，Compaq（译者注：康柏计算机公司，后被惠普公司收购）以3.07亿美元收购了Zip2，27岁的Musk一举成为了身价2200万美元的富翁。<br> 对于Musk的人生来说，创办一家企业后再马上潜心投入创办下一家更崭新的、更艰难的、更复杂的企业是一个循环往复的主题。如果他对网络公司百万富翁的准则循规蹈矩的话，他就不会因此成名——在你成功当上90年代大繁荣的弄潮儿之后，你应该做的要么是在惬意的黄昏落日下与天使投资中退休，要么是假如你还有野心，用别人的钱再开一家新公司。但是Musk不走寻常路，他把四分之三的身家都投入实现他的新想法——一个非同凡响而又异常大胆的计划。这个计划旨在建立一个堆满支票、存款以及账户的网上银行——名字叫X.com。这个主意现在看起来没什么特别，但要知道那是1999年，一家互联网初创公司要和庞大的银行帝国竞争是前所未闻的。</p>
<p> X.com所处的同一栋建筑还有另外一家互联网金融公司，名字叫Confinity，由Peter Thiel和Max Levchin所创立。X.com的众多特点之一就是能提供方便的转账服务，不久之后，Confinity也提供了类似的服务。两家公司都开始注意到市场对他们的转账服务有强烈的需求，这使得两家公司电光石火之间就要与对方展开激烈的竞争。最终，他们决定合并为一家公司，即我们今天所熟知PayPal。<br> 这次合并带来了排山倒海般的内部冲突——Musk现在起就得加入Peter Thiel和其他一帮当时超级成功的互联网弄潮儿。尽管公司在飞速成长，办公桌上的事情可没谈妥。冲突终于在2000年底爆发了，当时Musk正在度蜜月（与他的第一任妻子Justine），反Musk势力策划了一场政变并以Thiel取代他的CEO之位。这次突发事件Musk处理得出乎意料的好，并且直到今天，他都表示并不认同那次举动，但他能理解为什么他们要这么做。事后他继续留在公司里担任高管职位，并继续投资公司。2002年，eBay以15亿美买下PayPal时，他扮演了重要角色。作为这家公司的最大股东，Musk带着1.8亿美元（税后）潇洒地迈出大门。<br> 如果在Musk的决策中曾经出现过一次近似乎循规蹈矩的时刻，那么它就是他生命中的此时此刻——成为31岁超级富翁的2002年——他一劳永逸地把成规付之一炬。</p>
<p> 我们在剩下的文章里会彻底探讨他在此之后持续至今的13年里的主题。先来看这一小段故事：<br> 在2002的时候，甚至在出售PayPal之前，Musk就开始狼吞虎咽地阅读有关火箭技术的书籍，并在那一年的晚些时候，他带着1亿美元不加思索地创办了一家历史上最不可思议的企业之一：一家名为SpaceX的火箭公司，这家公司旨在于为太空旅行的花费带来彻底革命，以让人类在下个世纪里通过在火星上至少殖民一百万人口的方式来实现星际移民。<br> <br> 咳咳。<br> 接着，在2004年的时候，在“火箭”正在实行的同时，Musk决定兵分两路——不加思索地创办历史上第二不可思议的企业：一家名叫特斯拉的电动车公司，旨在于显著加速电动汽车的发展，以期彻底改革全世界的汽车业并带领人类向可持续能源的未来迈出一大步。Musk同样是以个人身份资助这家公司，尽管在美国历史上，上一次成功的汽车初创企业（名为Chrysler）要追溯到1925年了，同时能创建一家成功的电动汽车公司的人还没从石头里蹦出来，他依然倾注了7000万美元。 <br> 有钱就是任性，数年之后的2006年，他投入1000万美元与他表兄弟们一起创立了另外一家叫做SolarCity的公司，其旨在于通过开发一种更庞大的分布式设施来彻底改革发电产业。数百万的家庭将会装上这种太阳能电池板系统，以期大幅降低用于发电的化石燃料的消耗，并且最后做到“促进可持续能源的大量采用。”</p>
<p> 如果你纵览Paypal卖出去后接下来的四个年头，你能看出这是一个悲怆的故事。一个痴心妄想的互联网百万富翁，可笑地把他全部心思投入一串不可能完成的任务，无所不用其极地挥霍他的财富。<br> 到了2008年，正如字面意思看起来那样——火开始烧眉毛了。SpaceX已经能够建造火箭，只不过不是真正能工作的火箭——到目前为止前三次尝试发射的火箭都在到达既定轨道之前炸毁了。为了引进任何正式的外部投资或收费发射合约，SpaceX必须证明他们能成功地发射一枚火箭——但Musk说他剩下的资金能且仅能负担起最后一次发射了。如果第四次发射也失败的话，SpaceX将会完蛋。<br> 与此同时，在旧金山湾区，特斯拉也是一团糟。由于并不被外界所看好，他们并没有把第一款车—— Tesla Roadster——推出市场。硅谷八卦博客Valleywag甚至把特斯拉的Roadster列为2007年最失败的科技产品。雪上加霜的是，当时全球也突然陷入经济危机，这无疑重创了汽车工业，并榨干了任何一滴流向汽车行业投资款，作为还没来得及经过市场证明的新兴企业，特斯拉更是身陷囹圄，现金烧得飞快。</p>
<p> 在两方事业的挫败下，他原本岁月静好的八年婚姻，也在混乱的离婚中收场。<br> 长夜漫漫。<br> 但关键的是——Musk并不是傻瓜，而且他从来没创建过烂公司。与其相反，他创立的公司都特别、<strong><em>特别地</em></strong>棒。只是就跟开创一家汽车公司一样，开发一枚可靠火箭的困难程度不亚于上刀山下火海，而且因为在外界看来这企业野心过于庞大并且很可能惨淡收场的，没有人愿意去投资——特别是在经济萧条期间——Musk必须依赖自己的个人资金了。PayPal成就了他的腰缠万贯，但以他一己之力还不够足以支撑这些公司跋涉这么长的路途。如果没有外部投资，SpaceX和特斯拉离墓碑不远了。所以并不是SpaceX和特斯拉太差劲了——只是他们需要更多的时间才能迎来胜利的曙光，然而他们时日不多了。<br> <br> 在最严峻的时刻，突然间迎来转机，一切天翻地覆。<br> 首先，在2008年的9月份，SpaceX发射了第四枚火箭——如果它没能把负载送达预定轨道的话，这将是最后一枚火箭——结果它成功了。完美无疵。<br> 这就足以让NASA（译者注：National Aeronautics and Space Administration，美国国家航空和宇宙航行局）吼出“去他的，让我们给这个叫Musk的家伙一次机会”并赌了一把，为SpaceX提供了一份价值16亿美元的合同，而SpaceX将为NASA实施12次航天运输任务。山重水复疑无路，柳暗花明又一村。SpaceX得救了。<br> <strong><em>第二天</em></strong>，在2008年的圣诞节晚上，当Musk从床下搜刮出他所能支撑特斯拉继续运营的最后一分钱后，特斯拉的投资者们勉为其难地同意投资这家公司。长风破浪会有时，直挂云帆济沧海。5个月之后，事情开始往好的一面发展，另外一项春夜喜雨般的投资也如期而至——来自Daimler（译者注：德国斯图加特，全球最大的商用车制造商）的5000万美元。特斯拉得救了。</p>
<p> 尽管2008年对Musk来说坎坷颠簸，然而接下来的七年中Elon Musk和他的公司创造了巨大辉煌。<br> 自他们头三次发射失败以来，SpaceX已经发射了20次了——全部成功。因为SpaceX的创新技术能将航天运输的成本降到史上最低，所以许多企业现在已成为常客了，NASA只是其中之一。对于一家商业火箭公司来说，那20次发射已经包揽下了几乎所有“第一次”的头衔——直到今天，世界上掌握了航天器发射回收技术的只有四个：美国、俄罗斯、中国、以及——SpaceX。SpaceX目前正在测试他们的新一代航天器，它能载人飞入太空，并且他们在忙于建造更大型的火箭，其能一次性载100个人去火星。最近一次由Google和Fidelity（译者注：美国最大的共同基金公司）发起的投资带给了这家公司120亿美元的估值。</p>
<p> 特斯拉的车型Model S已经取得了了不起的成就，不仅以《消费者报告》有史以来的最高评分——99/100称霸整个汽车工业，而且还获得了来自国家公路交通安全局有史以来的最高安全系数——5.4/5。现在他们离推出真正的终结者越来越近了——更多人买得起的车型Model 3——而且这家公司的市场总值接近300亿美元。他们同时也正在成为世界上最强大的电池公司，目前在内华达州内建造超大型工厂“Gigafactory”，其锂离子电池产能是全球每年<strong><em>产量加起来</em></strong>的两倍。<br> 于2012年面世的SolarCity，现在的市场总值接近60亿美元，并且已经成为美国最大的太阳能电池板服务商。他们现在正在Buffalo (译者注：美国纽约州西部港市)建造全国最大的太阳能电池板制造工厂，并且他们会与特斯拉以合作伙伴的关系把产品和特斯拉的新家庭电池——能源墙（Powerwall）结合在一起。<br> 并且这远远不够，在他的空余时间里，Musk还在抓紧发展一种全新的交通形式——超级高铁（<a href="http://waitbutwhy.com/2015/06/hyperloop.html" target="_blank" rel="external">Hyperloop</a>）。<br> 数年之后，当这几家新工厂都建造完成时，Musk的三家公司会雇佣超过3万人。2008年几近破产的Musk对一位朋友说过，他和他老婆都可能得“搬进他老丈人的地下室”，不过Musk目前的<a href="http://www.forbes.com/profile/elon-musk/" target="_blank" rel="external">实时</a>资产净值为129亿美元。（译者注：截至发稿时为138亿美元）</p>
<p> 所有的这一切让江湖人称Musk为在世大圣。随着汽车企业的初创成功和超级充电站网络遍布全球，人们开始把Musk和诸如Henry Ford（译者注：福特公司创始人）和John D. Rockefeller（译者注：美孚石油公司创办人）这样远见卓识的企业家们相提并论。SpaceX在火箭技术上的领先也让他能比肩Howard Hughes（译者注：美国传奇航空工程师），还有相当一部分人出于Musk能同时纵横各大产业并取得伟大技术进步的理由，把Musk和爱迪生拿来做比较。因为Musk的必杀技就是打破循规蹈矩的产业并给消费者带来连他们自己都不清楚想要什么的产品，所以更多的时候他是被拿去跟乔布斯做比较。有些人相信他将作为有且仅有他自己的人类分支而被铭记。负责给Musk写传的科技作家Ashlee Vance指出Musk现在正做的“连Hughes或者乔布斯创造过的任何东西与之相比都可能如萤火之光与日月争辉。Musk把这些在美国看起来快要弃疗的产业比如航空航天业和汽车工业回炉重造成崭新而妙不可言的样子”。</p>
<p><img src="http://28oa9i1t08037ue3m1l0i861.wpengine.netdna-cdn.com/wp-content/uploads/2015/05/F.jpg" alt="comic"></p>
<p> 负责运营TED演讲的Chris Anderson<a href="https://www.youtube.com/watch?v=tUMZTtQU10o" target="_blank" rel="external">称Musk为</a>“地球上活着的创业家中最非凡卓越的。”其他人都通过“钢铁侠的现实原型”才了解认识他，并且值得一提的是，有件事并非无中生有——在开始执导第一部《钢铁侠》之前，Jon Favreau（译者注：《钢铁侠1》的导演）确实把Robert Downey, Jr.（译者注：钢铁侠扮演者）与Musk关在SpaceX的工厂里一起生活了些日子——这样“钢铁侠”就能够通过对Musk的察言观色来塑造自己的角色。Musk甚至<a href="http://simpsons.wikia.com/wiki/The_Musk_Who_Fell_to_Earth" target="_blank" rel="external">客串过</a>《辛普森一家》。</p>
<p> 这就是Musk——当我在家里穿着睡裤来回踱步时，莫名其妙地就接到了他的电话。<br> 在通话中，他反复强调了他不是找我去宣传他的公司——而是希望我帮忙解释围绕着这几家公司，世界发生了什么改变，以及为什么电动汽车、可持续能源生产以及航空航天业如此重要。<br> 他看起来特别厌倦了别人花费时间去大量报道他——他觉得他所涉足的产业有太多重要的事情更值得被关注且每次有文章要写他，他都希望他们能把焦点放在石化燃料供应、电池优势或者实现人类星际移民的重要性（上文曾提到的关于他的一本传记，其介绍里把这点写得很清楚了——作者指出Musk对于又来一本传记这件事毫无兴趣）。</p>
<p> 所以我确定一定以及肯定的是这篇题为《Elon Musk：地球上最炫酷的人》的文章肯定会惹恼他本人。<br> 但我这么做也有我的理由。对于我来说，这篇文章能开启两个弥足珍贵的宝箱：<br> 1）弄明白Musk出于什么原因投身他的事业。他深深确信他肩负着给人类带来美好未来的重任。我想探究他所作所为的深层原因。<br> 2）弄明白为什么Musk能够成就这一切。在每一个时代中，都有一些伟人深刻地改变了世界，并且那些人都值得我们学习。他们特立独行——我想从他们身上可以学到很多东西。<br> 所以在我去加利福尼亚的路上，我脑海里始终铭记两个目的：一是尽我所能了解清楚Musk和他的队伍如此狂热地在做什么项目，以及为什么他们的所作所为至关重要，二是去洞察是什么使他能如此深刻地改变世界。</p>
<hr>
<p><strong>番外篇 @覃超</strong></p>
<p>为什么 Elon Musk 这么猛？ 他如何跨学科学习的？他的思维模式是怎样的？</p>
<ol>
<li><p>他极度勤奋且酷爱学习<br>在看他的自传里，很多时候描述就是：他每天都在思考和阅读，经常几个小时就可以读完一本书，然后挑里面的关键内容再花一天时间精读；</p>
</li>
<li><p>他创业的方向一直是他从小热爱的东西<br>这很重要但是容易被大家忽视。兴趣是最好的老师，而做感兴趣的事情才是可以坚持一生的事情。不管是火箭，外太空旅行还是可再生能源，这些都是 Elon Musk 在孩提时期就很着迷的事情，另外更加重要的是，它们对整个人类发展有重大的意义。可能我们没有这么好的机遇或者本钱去做改变人类命运的事情，但是我们应该学会去追求自己儿时一直喜欢的兴趣，并想方设法将兴趣和自己的工作相结合，亦或是出来做自己喜欢的创业项目。</p>
</li>
<li><p>他的学习方法和思维模式<br>在TED的采访中，他坦言自己最赞同的思维模式是 “First principle thinking”。 “First principle thinking” 的详细解释和如何运用我会在另外的问题专门回答。简单说来，First principle thinking 就是从事物最基本的公理为出发点来进行推导的思维方式。其对立的方法是 Analogy（类推法），简单说来就是别人或者其他事物如何如何，所以我也要如何如何。</p>
</li>
</ol>
<p>举例说明：“现在我有1万刀的现金想投资股票，我应该买什么股票？”</p>
<p>Analogy ：“别人家之前买了这几支股票，赚了不少，或者我旁边有个股票大神也买了这几个股票，赚了，所以我也准备买这几个股票。”<br>First principle thinking：“首先去弄明白股票的原理，看清股票涨跌的本质，然后分析公司的背后价值，接着根据自己的需求，看自己是想长久投价值，然后在A股市场利用趋势捞一波。当然也有可能，在分析过程中发现股票市场的风险大小超过了自己的承受范围，从而放弃投资股票。转而杀入债市或者定期投资等。”</p>
<p>从上面可以看出几点：First principle thinking 对一个人的学习能力要求很高，同时分析问题的过程冗长；类推法则很方便，直接O(1)出解，只是并不知其所以然，并且缺乏对本质问题的理解。这两种思维模式的选取是一个辩证的问题：在大部分的问题上可以采用 Analogy，节约时间。但是对于重要的可能决定自己命运轨迹的问题，则采用 first principle thinking（比如创业 方向？模式？，长期投资等）。</p>
<p>最后， 如何像 Elon Musk 一样厉害呢？ 做好的上面的三点 + N小时的“精深练习” + 生活规律 + 专注 + 坚持。</p>
<p><strong>这些点说起来简单，但是做起来却都很难。所以，共勉。</strong></p>
<p>— END —</p>
<blockquote>
<p>每篇文章除特殊声明外均以 CC BY-NC-SA 4.0 协议发布，非商业用途可以在保留署名和来源的情况下任意转载。</p>
</blockquote>
<p> </p>
<p>
</p>
]]></content>
<summary type="html">
<![CDATA[我将通过这篇文章去探索揭秘身他是如何白手起家成为亿万富翁和现实中的Tony Stark（译者注：钢铁侠在电影中的名字）。不过现在，还是引用传奇亿万富翁Richard Branson的一小段话来为这场好戏拉开序幕吧：不管外界质疑声是多么地此起彼伏，Elon总能如有神助般地把废铜烂铁变为如意金箍，借定海神针平息一切。回想一下在20世纪90年代的时候，我们会把自己的信用卡号码给素不相识的陌生人吗？然而Elon创造了一个叫PayPal的小玩意儿，结局今天你们也都知道了。他的特斯拉汽车和SolarCity公司正在把能源可再生的纤尘不染的未来天堂挪到地上……他的SpaceX正在重新探索太空……矛盾的是，一方面Elon在努力改善我们所居住的地球，另一方面他又为了帮助我们离开地球而在建造太空飞船。]]>
</summary>
<category term="英文科技文章翻译" scheme="chenjuntong.me/tags/%E8%8B%B1%E6%96%87%E7%A7%91%E6%8A%80%E6%96%87%E7%AB%A0%E7%BF%BB%E8%AF%91/"/>
<category term="英文翻译" scheme="chenjuntong.me/categories/%E8%8B%B1%E6%96%87%E7%BF%BB%E8%AF%91/"/>
</entry>
</feed>