diff --git a/README.md b/README.md index 866f057..9a6652b 100644 --- a/README.md +++ b/README.md @@ -60,7 +60,7 @@ Chinese translations for classic IT resources. ------------------ 1. [日志：每个软件工程师都应该知道的有关实时数据的统一抽象](log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md) - 这篇文章是`LinkedIn`的`Kreps`发表的一篇博文，被称为**_程序员史诗般必读_**文章。可以作为大数据/分布式系统领域一份导论式的资料。作者对整个领域的理解和实战精深广博，抓出并梳理了这个领域的核心：日志。 + 这篇文章是`LinkedIn`的`Kreps`发表的一篇博文，被称为 **_程序员史诗般必读_** 文章。可以作为大数据/分布式系统领域一份导论式的资料。作者对整个领域的理解和实战精深广博，抓出并梳理了这个领域的核心：日志。 1. [Paxos Made Simple](paxos-made-simple/README.rst) 该论文给出描述一致性问题的概念、术语、算法，从复杂中抓取出了核心，给出了如此简单的描述。 另言简意赅地说明了多实例`Paxos`（`Multi-Paxos`），这是真正实践中使用的`Paxos`。可以说不读这篇论文你就不知道**你还不知道**如何有效地描述和交流一致性算法。 @@ -78,12 +78,12 @@ Chinese translations for classic IT resources. ------------------ 1. [`Erlang`之父学习`Elixir`语言的一周](a-week-with-elixir/README.md) -作为`Erlang`之父_Joe Armstrong_，对`Erlang VM`上的新语言`Elixir`做了很精彩的评论和思考。『特定领域专家的专业直觉』、『编程语言设计的三定律』、『管道运算符避免恶心代码』、『`Elixir`的`sigil`引出的程序语言如何定义/解释字符串』等等问题的讨论，个性鲜明又幽默诙谐的行文风格，都能强烈感受到_Joe Armstrong_深入广博的老黑客风范。 +作为`Erlang`之父 _Joe Armstrong_，对`Erlang VM`上的新语言`Elixir`做了很精彩的评论和思考。『特定领域专家的专业直觉』、『编程语言设计的三定律』、『管道运算符避免恶心代码』、『`Elixir`的`sigil`引出的程序语言如何定义/解释字符串』等等问题的讨论，个性鲜明又幽默诙谐的行文风格，都能强烈感受到 _Joe Armstrong_ 深入广博的老黑客风范。 `Lisp` ------------------ -1. [**_Successful Lisp_**中的`Lisp`书籍推荐](recommend-lisp-books/suggestions4further-reading-in-successful-lisp.md) +1. [**_Successful Lisp_** 中的`Lisp`书籍推荐](recommend-lisp-books/suggestions4further-reading-in-successful-lisp.md) - [`Lisp`书籍推荐和点评](recommend-lisp-books/README.md)，由于`Lisp`与其它语言从**基本概念**就开始的差异，已有的语言经验反而是个学习阻碍，深入浅出的巧妙讲解对入门太重要了。 - 特别提这篇好文[【转】学习`Lisp`的书籍推荐](recommend-lisp-books/recommend-lisp-books.md) diff --git a/a-week-with-elixir/README.md b/a-week-with-elixir/README.md index a34a168..fdc978f 100644 --- a/a-week-with-elixir/README.md +++ b/a-week-with-elixir/README.md @@ -6,7 +6,7 @@ ## 译序 -作为`Erlang`之父_Joe Armstrong_，对`Erlang VM`上的新语言`Elixir`做了很精彩的评论和思考。『特定领域专家的专业直觉』、『编程语言设计的三定律』、『数据的版本化设计』、『管道运算符避免恶心代码』、『静态单赋值』、『`Elixir`的`sigil`引出的程序语言如何定义/解释字符串』、『函数定义和函数字面量在`Shell`的不一致性』等等主题的讨论，个性鲜明又幽默诙谐的行文风格，都能强烈感受到_Joe Armstrong_深入广博的老黑客风范。 +作为`Erlang`之父 _Joe Armstrong_，对`Erlang VM`上的新语言`Elixir`做了很精彩的评论和思考。『特定领域专家的专业直觉』、『编程语言设计的三定律』、『数据的版本化设计』、『管道运算符避免恶心代码』、『静态单赋值』、『`Elixir`的`sigil`引出的程序语言如何定义/解释字符串』、『函数定义和函数字面量在`Shell`的不一致性』等等主题的讨论，个性鲜明又幽默诙谐的行文风格，都能强烈感受到 _Joe Armstrong_ 深入广博的老黑客风范。 [自己](http://weibo.com/oldratlee)理解粗浅，而本文讨论是语言设计，且作为老一代黑客的作者对计算机领域中那些现在我们在日常编程中不再要去使用理解的主题或是思想又真是信手拈来（如`Prolog`/`DCG`、`Lisp`/宏、`sigil`、不可变闭包、语言设计的兼容性），翻译中肯定会有不少不足和不对之处，欢迎建议（[提交Issue](https://github.com/oldratlee/translations/issues)）和指正（[Fork后提交代码](https://github.com/oldratlee/translations/fork)）！ PS：为什么要整理和审校翻译 参见 [译跋](translation-postscript.md)。 @@ -45,7 +45,7 @@ PS：为什么要整理和审校翻译 参见 [译跋](translation-postscript.md 差不多一周前我开始看[`Elixir`](http://elixir-lang.org)，关于`Elixir`之前只有些模糊的了解，没打算花时间去看细节。 -但得知_Dave Thomas_出版了[《_Programming Elixir_》](http://pragprog.com/book/elixir/programming-elixir)这本书的消息后，我的想法彻底变了。_Dave Thomas_帮我修订过那本`Erlang`的书并且作为`Ruby`的倡导者做得非常出色，所以_Dave_要是对一样东西产生了兴趣，那说明这样东西的有趣性是毫无疑问的。 +但得知 _Dave Thomas_ 出版了[《_Programming Elixir_》](http://pragprog.com/book/elixir/programming-elixir)这本书的消息后，我的想法彻底变了。_Dave Thomas_ 帮我修订过那本`Erlang`的书并且作为`Ruby`的倡导者做得非常出色，所以_Dave_要是对一样东西产生了兴趣，那说明这样东西的有趣性是毫无疑问的。 _Dave_对`Elixir`很感兴趣，在他的书里这样写道： @@ -60,9 +60,9 @@ _Dave_对`Elixir`很感兴趣，在他的书里这样写道： > 但在几个月前，和_Corey Haines_聊了一次，在如何不用学院派的书给大家介绍哪些有吸引力的函数式编程概念这个问题上诉了些苦。 > 他告诉我再去看看`Elixir`。我照做了，有了第一次看到`Ruby`时那样的感觉。 -我能理解这种感觉，一种先行于逻辑的内心感性的感觉。就像我知道一件事是对的，却并不知道是如何和为什么我知道这是对的。而对原因的解释常常在几周甚至几年后才冒出来。_Malcolm Gladwell_在他的[《_Blink: The Power of Thinking Without Thinking_》](https://www.amazon.com/Blink-Power-Thinking-Without/dp/0316010669/ref=sr_1_1?s=books&ie=UTF8&qid=1369995752&sr=1-1&keywords=blink)一书中曾探讨过这个问题。一个特定领域的专家常常能瞬间感知出一些事情是否正确，但却不能解释为什么。 +我能理解这种感觉，一种先行于逻辑的内心感性的感觉。就像我知道一件事是对的，却并不知道是如何和为什么我知道这是对的。而对原因的解释常常在几周甚至几年后才冒出来。_Malcolm Gladwell_ 在他的[《_Blink: The Power of Thinking Without Thinking_》](https://www.amazon.com/Blink-Power-Thinking-Without/dp/0316010669/ref=sr_1_1?s=books&ie=UTF8&qid=1369995752&sr=1-1&keywords=blink)一书中曾探讨过这个问题。一个特定领域的专家常常能瞬间感知出一些事情是否正确，但却不能解释为什么。 -但得知_Dave_与`Elixir`『看对眼』时，我很想知道他为什么会这样。 +但得知 _Dave_ 与`Elixir`『看对眼』时，我很想知道他为什么会这样。 无独有偶，_Simon St. Laurent_也出了本`Elixir`的书。_Simon_的[《_Introducing Erlang_》](http://www.amazon.com/Introducing-Erlang-Simon-St-Laurent/dp/1449331769)一书表现不俗，我和他还邮件沟通过几次，所以有些事已经在酝酿了。而_Pragmatic Press_和_O'Reilly_出版社都在争着要出版`Elixir`，我知道在`Erlang VM`上的事已经在发生了，而我自己还没注意到。毫无疑问我Out了！ @@ -80,7 +80,7 @@ _Dave_对`Elixir`很感兴趣，在他的书里这样写道： > 【译注】： > -> **_`sigil`_**是指在变量名中包含符号来表达数据类型或作用域，通常作为前缀，如`$foo`，其中`$`就是个`sigil`。 +> **_`sigil`_** 是指在变量名中包含符号来表达数据类型或作用域，通常作为前缀，如`$foo`，其中`$`就是个`sigil`。 > 像本文中说的例子，`sigil`也可以能对常量加上字母符号，`r"abc"`，其中`r`是`sigil`，把字符串转成正则表达式。 > 详见[`wikipedia`词条`sigil`](https://en.wikipedia.org/wiki/Sigil_(computer_programming)) > @@ -186,7 +186,7 @@ pp(X) -> # 2. `fun`和`def`不同 -在写[《_Programming Erlang_》](https://pragprog.com/book/jaerlang2/programming-erlang)一书时_Dave Thomas_问函数为什么不能在`shell`里输入。 +在写[《_Programming Erlang_》](https://pragprog.com/book/jaerlang2/programming-erlang)一书时 _Dave Thomas_ 问函数为什么不能在`shell`里输入。 如果模块里有这样的代码： @@ -195,9 +195,9 @@ fac(0) -> 1; fac(N) when N > 0 -> N * fac(N-1). ``` -不能直接复制到`shell`里运行，得到相同的结果。_Dave_问这是为什么，并说这样很傻。 +不能直接复制到`shell`里运行，得到相同的结果。_Dave_ 问这是为什么，并说这样很傻。 -`Lisp`等其它语言这么做是没问题的。_Dave_说过『这很会让人很迷惑』类似这样的话 —— 他说的对并且这确实让人迷惑了。在论坛里关于这个问题肯定有成百上千条。 +`Lisp`等其它语言这么做是没问题的。_Dave_ 说过『这很会让人很迷惑』类似这样的话 —— 他说的对并且这确实让人迷惑了。在论坛里关于这个问题肯定有成百上千条。 我已经解释了这个问题无数遍，从黑发解释到白发，我现在头发真白了真就是因为这个。 @@ -232,9 +232,9 @@ ex> def triple(x) do 3*x; end 如果你不解决这个问题就要花后面20年的时间去解决为什么 —— 就像`Erlang`曾经所做的。 -顺便说一下，修复这个问题真的真的很简单。我在`erl2`作为了尝试就解决了。`Erlang`中没法修复这个问题（版本兼容问题），所以我就在[`erl2`](https://github.com/joearms/erl2)解决。只需要**_`erl_eval`_**的小改和解析器的几个微调。 +顺便说一下，修复这个问题真的真的很简单。我在`erl2`作为了尝试就解决了。`Erlang`中没法修复这个问题（版本兼容问题），所以我就在[`erl2`](https://github.com/joearms/erl2)解决。只需要 **_`erl_eval`_** 的小改和解析器的几个微调。 -主要原因是`FORM`不是`EXPRESSION`，所以加了个关键字**`def`**。 +主要原因是`FORM`不是`EXPRESSION`，所以加了个关键字 **`def`**。 ```erl Var = def fac(0) -> 1; fac(N) -> N*fac(N-1) end. @@ -250,7 +250,7 @@ iex> double = fn(x) -> 2 * x end; iex> def double(x) do 2*x end; ``` -上面两者应该是一致的，并且**都是**定义一个名为**`Shell.double`**的函数。 +上面两者应该是一致的，并且**都是**定义一个名为 **`Shell.double`** 的函数。 做了这样的修改，妈妈再也不用担心我会白头了。 @@ -263,7 +263,7 @@ iex> f.(10) 20 ``` -在学校里我学会了写**_`f(10)`_**来调用函数而不是**_`f.(10)`_** —— 这是个『真正』的函数，函数名是**`Shell.f(10)`**（一个在`shell`中定义的函数）。`shell`部分是**_隐式_**的，所以可以只用**_`f(10)`_**来调用。 +在学校里我学会了写 **_`f(10)`_** 来调用函数而不是 **_`f.(10)`_** —— 这是个『真正』的函数，函数名是 **`Shell.f(10)`**（一个在`shell`中定义的函数）。`shell`部分是 **_隐式_** 的，所以可以只用 **_`f(10)`_** 来调用。 如果你对这点置之不理，那就等着用你生命接下来的二十年去解释为什么吧。等着在数百个论坛里的数千封邮件吧。 @@ -275,17 +275,17 @@ Process <- Message 这是啥玩意？你知道从`occam-pi`转成`Elixir`有多难么。 -这点让你现在在失去`occam-pi`社区路上。发送操作符就应该是**_`!`_**，像这样： +这点让你现在在失去`occam-pi`社区路上。发送操作符就应该是 **_`!`_**，像这样： ```erl Process ! Message ``` -接下来的一周，我的脑子会变成浆糊，我的神经网络要被重新编程，这样我才能在『看到』`<-`时才能反应成**_`!`_** —— 这点不是在说如何我思考，而是指要重编程我更深植在脊髓里无意识反应。发送操作符已经不在我大脑里，而是在我的脊髓里。我的大脑想着『发送一个消息给一个进程』并发送信号给我的手指，我的脊髓马上加上**_`!`_**，接着大脑要**回退删除**这个字符改成**_`<-`_**。 +接下来的一周，我的脑子会变成浆糊，我的神经网络要被重新编程，这样我才能在『看到』`<-`时才能反应成 **_`!`_** —— 这点不是在说如何我思考，而是指要重编程我更深植在脊髓里无意识反应。发送操作符已经不在我大脑里，而是在我的脊髓里。我的大脑想着『发送一个消息给一个进程』并发送信号给我的手指，我的脊髓马上加上 **_`!`_**，接着大脑要 **回退删除** 这个字符改成 **_`<-`_**。 这是一个语法问题，而我们都喜欢对语法说长道短的。如果10分制的评级标准，10代表『非常非常烂』，1代表『好吧，我可以适应』的话，这个问题我给3分。 -这点会使`occam-pi`程序员很难转到`Elixir`。什么？只需要简单地用**`!`**而不是`<-`，就可以让一波`occam-pi`的程序员喜大普奔地哭喊着『药 ！药！切克闹！！美好生活现在到！！！』然后立马就转到`Elixir`。以后老司机告诉你真是这样的，这个改变会让人开心得像过节一样。 +这点会使`occam-pi`程序员很难转到`Elixir`。什么？只需要简单地用 **`!`** 而不是`<-`，就可以让一波`occam-pi`的程序员喜大普奔地哭喊着『药 ！药！切克闹！！美好生活现在到！！！』然后立马就转到`Elixir`。以后老司机告诉你真是这样的，这个改变会让人开心得像过节一样。 # 5. 管道运算符 @@ -408,7 +408,7 @@ B = s"Hello #{A}". 大爱`docstring`。 -但有个小建议，请把`docstring`放到函数定义**_里面_**。 +但有个小建议，请把`docstring`放到函数定义 **_里面_**。 `Elixir`是这样： @@ -422,7 +422,7 @@ def foo do end ``` -放到函数**_里面_**会是这样： +放到函数 **_里面_** 会是这样： ```ex def foo do @@ -434,7 +434,7 @@ end 否则成了『没有归属的注释』（`detached comment`）：当你编辑程序时，就可能出这样的问题。注释会与它要去注释的函数脱离开。 -在`Erlang`里，没有办法确定注释的是下一个函数还是上一个函数，或是模块。如果注释的对象是函数那就应该放到函数**_里面_**而不是外面。 +在`Erlang`里，没有办法确定注释的是下一个函数还是上一个函数，或是模块。如果注释的对象是函数那就应该放到函数 **_里面_** 而不是外面。 # 8. `defmacro`的引用和反引用 @@ -545,7 +545,7 @@ end 这是门新兴的语言，但在语言的开发的同时介绍的书也同步在写了。第一本介绍`Erlang` 的书在`Erlang`发明后的7年才出现，而畅销书更是在14年后才出现。用21年的时间去等一本真正的介绍书籍实在是太长了。 -_Dave_很喜欢`Elixir`，我也觉得很酷，我想我们会在使用过程中找到更多乐趣的。 +_Dave_ 很喜欢`Elixir`，我也觉得很酷，我想我们会在使用过程中找到更多乐趣的。 像`WhatsApp`这个应用和全世界一半手机网络的关键部分都是搭建在`Erlang`之上。当技术变得更加亲和，当新一批热衷者进入阵营，让我现在怀着非常欣喜的心情关注着后续要发生的变化。 diff --git a/how-to-ask-questions-the-smart-way/others.md b/how-to-ask-questions-the-smart-way/others.md index fd2f640..a3b68bb 100644 --- a/how-to-ask-questions-the-smart-way/others.md +++ b/how-to-ask-questions-the-smart-way/others.md @@ -170,7 +170,7 @@ 如何更好地回答 ================== -**_态度和善一点。_**问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。 +**_态度和善一点。_** 问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。 **_对初犯者私下回复。_** 对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找`FAQ`都不知道。 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md index 6fb5d36..5ebaf05 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md @@ -17,7 +17,7 @@ 把次序直接看成是时间概念，刚开始你会觉得有点怪异，但是这样的做法有个便利的性质：解耦了 时间 和 任一特定的物理时钟（`physical clock`）。 引入分布式系统后，这会成为一个必不可少的性质。 -> **_【译注】_** 分布式系统的 时间、次序、时钟的概念是个最基础根本的问题，详见被引用最多的_Leslie Lamport_的论文**_Time Clocks and the Ordering of Events in a Distributed System_**（[中文翻译](http://duanple.blog.163.com/blog/static/709717672012920101343237/)）。 +> **_【译注】_** 分布式系统的 时间、次序、时钟的概念是个最基础根本的问题，详见被引用最多的 _Leslie Lamport_ 的论文 **_Time Clocks and the Ordering of Events in a Distributed System_** （[中文翻译](http://duanple.blog.163.com/blog/static/709717672012920101343237/)）。 > > 现在先 **_不要_** 去看，除非读完本文后你还是有很兴趣要探个明白！ @@ -68,7 +68,7 @@ [确定性](http://en.wikipedia.org/wiki/Deterministic_algorithm)（`deterministic `）意味着处理过程是与时间无关的，而且不让任何其他『带外数据（`out of band`）』的输入影响处理结果。 例如，如果一个程序的输出会受到线程执行的具体顺序影响，或者受到`getTimeOfDay`调用、或者其他一些非重复性事件的影响，那么这样的程序一般被认为是非确定性的。 -进程**_状态_** 是进程保存在机器上的任何数据，在进程处理结束的时候，这些数据要么保存在内存里，要么保存在磁盘上。 +进程 **_状态_** 是进程保存在机器上的任何数据，在进程处理结束的时候，这些数据要么保存在内存里，要么保存在磁盘上。 当碰到以相同的顺序输入相同的内容的情况时，应该触发你的条件反射：这个地方要引入日志。 下面是个很直觉的意识：如果给两段确定性代码相同的日志输入，那么它们就会生产相同的输出。 @@ -85,7 +85,7 @@ 理论上来说，我们甚至可以记录各个副本执行的机器指令序列的日志 或是 所调用的方法名和参数序列的日志。 只要两个进程用相同的方式处理这些输入，这些副本进程就会保持一致的状态。 -对日志用法不同群体有不同的说法。数据库工作者通常说成**_物理_**日志（`physical logging`）和**_逻辑_**日志（`logical logging`）。 +对日志用法不同群体有不同的说法。数据库工作者通常说成 **_物理_** 日志（`physical logging`）和 **_逻辑_** 日志（`logical logging`）。 物理日志是指记录每一行被改变的内容。逻辑日志记录的不是改变的行而是那些引起行的内容改变的`SQL`语句（`insert`、`update`和`delete`语句）。 分布式系统文献通常把处理和复制（`processing and replication`）方案宽泛地分成两种。『状态机器模型』常常被称为主-主模型（`active-active model`）， @@ -130,8 +130,8 @@ 这个过程也是可逆的：如果你对一张表进行更新，你可以记录这些变更，并把所有更新的『变更日志』发布到表的状态信息中。 这些变更日志正是你所需要的支持准实时的复制。 -基于此，你就可以清楚的理解表与事件的二象性： 表支持了静态数据，而日志记录了变更。日志的魅力就在于它是变更的_完整_记录，它不仅仅包含了表的最终版本的内容， -而且可以用于重建任何存在过其它版本。事实上，日志可以看作是表**_每个_**历史状态的一系列备份。 +基于此，你就可以清楚的理解表与事件的二象性： 表支持了静态数据，而日志记录了变更。日志的魅力就在于它是变更的 _完整_ 记录，它不仅仅包含了表的最终版本的内容， +而且可以用于重建任何存在过其它版本。事实上，日志可以看作是表 **_每个_** 历史状态的一系列备份。 > **_【译注】_** 关于『二象性（`duality`）』： > diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md index 6039a64..f07e55d 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md @@ -20,7 +20,7 @@ -你一定不会听到数据集成就兴趣盎然地屏住呼吸，并且天花乱坠的想到**_大数据_**的概念， +你一定不会听到数据集成就兴趣盎然地屏住呼吸，并且天花乱坠的想到 **_大数据_** 的概念， 但尽管如此，我相信这个陈词滥调的『让数据可用』的问题是组织可以关注的更有价值的事情之一。 对数据的高效使用遵循一种[马斯洛的需要层次理论](http://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs)。 @@ -94,14 +94,13 @@ 无论是数据来自于一个`RDBMS`、一种新型的键值存储，还是由一个不包含任何类型实时查询的系统所生成的，消费方系统都无需关心。 这似乎是一个小问题，但实际上却是至关重要的。 -> - +> > > [『Each working data pipeline is designed like a log; each broken data pipeline is broken in its own way.』 『工作的数据管道都是设计得像日志；而损坏的数据管道各有各的损坏。』 > —— 列夫 · 尼古拉耶维奇 · 托尔斯泰 （由笔者改写）](http://en.wikipedia.org/wiki/Anna_Karenina_principle) > -> **_【译注】_** [_托尔斯泰_](https://zh.wikipedia.org/zh-cn/%E5%88%97%E5%A4%AB%C2%B7%E6%89%98%E7%88%BE%E6%96%AF%E6%B3%B0) 的『[_安娜·卡列尼娜_](https://zh.wikipedia.org/zh-cn/%E5%AE%89%E5%A8%9C%C2%B7%E5%8D%A1%E5%88%97%E5%B0%BC%E5%A8%9C) 原理』的原文： +> **_【译注】_** [_托尔斯泰_](https://zh.wikipedia.org/zh-cn/%E5%88%97%E5%A4%AB%C2%B7%E6%89%98%E7%88%BE%E6%96%AF%E6%B3%B0) 的『[_安娜·卡列尼娜_](https://zh.wikipedia.org/zh-cn/%E5%AE%89%E5%A8%9C%C2%B7%E5%8D%A1%E5%88%97%E5%B0%BC%E5%A8%9C) 原理』的原文： > Happy families are all alike; every unhappy family is unhappy in its own way. > 幸福的家庭都是相似的，不幸的家庭各有各的不幸。 @@ -234,7 +233,7 @@ 强制使用星型`schema`（`star schema`）、雪花型`schema`（`snowflake schema`），可能会打散数据成高性能的[列](http://parquet.io/) [格式](http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/orcfile.html)（`column format`），等等。同时做好这两件事是有困难的。 这些集成仓库的规整的数据除了要索引到实时存储系统中，也应当可用于实时或是低时延处理中。 -在我看来，正是因为这个原因有了额外好处：使得数据仓库`ETL`大大提升了**_组织级_**的可伸缩性（`scalable`）。 +在我看来，正是因为这个原因有了额外好处：使得数据仓库`ETL`大大提升了 **_组织级_** 的可伸缩性（`scalable`）。 典型的问题是数据仓库团队要负责收集和整理组织中各个团队所生成的全部数据。 两边的收益是不对称的：数据的生产者常常并不知晓在数据仓库中数据的使用情况， 结果产生的数据，为了转成为可用的形式，抽取过程很难或是很繁重，转换过程很难统一规模化。 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md index f2c791f..ec5dd38 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md @@ -17,12 +17,12 @@ - [`PacificA`](http://research.microsoft.com/apps/pubs/default.aspx?id=66814)是实施微软基于日志的分布式存储系统的通用架构。 - [`Spanner`](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/spanner-osdi2012.pdf) —— 并不是每个人都支持把逻辑时间用于他们的日志，`Google`最新的数据库就尝试使用物理时间，并通过把时间戳直接做为区间来直接建时钟迁移的不确定性。 -- [`Datanomic`](http://www.datomic.com/)：[解构数据库](https://www.youtube.com/watch?v=Cym4TZwTCNU)是_Rich Hickey_（`Clojure`的创建者）在它的首个数据库产品中的重要陈述之一。 +- [`Datanomic`](http://www.datomic.com/)：[解构数据库](https://www.youtube.com/watch?v=Cym4TZwTCNU)是 _Rich Hickey_ （`Clojure`的创建者）在它的首个数据库产品中的重要陈述之一。 - [在消息传递系统中回滚恢复协议的调查](http://www.cs.utexas.edu/~lorenzo/papers/SurveyFinal.pdf)。 我发现这是有关容错处理和通过日志在数据库之外完成恢复的实际应用的很不错的介绍。 - [反应式宣言（`Reactive Manifesto`）](http://www.reactivemanifesto.org/) —— 我其实并不清楚反应式编程（`reactive programming`）的确切涵义，但是我想它和『事件驱动』指的是同一件事。 - 这个链接并没有太多的信息，但_Martin Odersky_（`Scala`大拿）讲授的[这个课程](https://www.coursera.org/course/reactive)很精彩。 + 这个链接并没有太多的信息，但 _Martin Odersky_ （`Scala`大拿）讲授的[这个课程](https://www.coursera.org/course/reactive)很精彩。 - `Paxos`! 1. 原论文在[这里](http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf)。 _Leslie Lamport_ 有一个有趣的历史：在80年代算法是如何发现的，但是直到1998年才发表了，因为评审组不喜欢论文中的希腊寓言，而作者又不愿修改。 @@ -33,9 +33,9 @@ 5. 我发现所有关于`Paxos`的论文理解起来很痛苦，但是值得我们费大力气弄懂。你不必忍受这样的痛苦了，因为日志结构的文件系统的大师[_John Ousterhout_](http://www.stanford.edu/~ouster/cgi-bin/papers/lfs.pdf)的[这个视频](https://www.youtube.com/watch?v=JEpsBg0AO6o) 让这一切变得相当的容易。这些一致性算法用展开的通信图表述的更好，而不是在论文中通过静态的描述来说明。颇为讽刺的是，这个视频录制的初衷是告诉人们`Paxos`很难理解。 6. [使用`Paxos`来构造规模一致的数据存储](http://arxiv.org/pdf/1103.2408.pdf)。这是一篇很棒的介绍使用日志来构造数据存储的文章，_Jun_ 是文章的共同作者之一，他也是`Kafka`最早期的工程师之一。 - `Paxos`有很多的竞争者。如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施。 - 1. 由_Barbara Liskov_提出的[视图戳复现](http://pmg.csail.mit.edu/papers/vr-revisited.pdf)是直接进行日志复现建模的较早的算法。 + 1. 由 _Barbara Liskov_ 提出的[视图戳复现](http://pmg.csail.mit.edu/papers/vr-revisited.pdf)是直接进行日志复现建模的较早的算法。 2. [`Zab`](http://www.stanford.edu/class/cs347/reading/zab.pdf)是`Zookeeper`所使用的算法。 - 3. [`RAFT`](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)是易于理解的一致性算法之一。由_John Ousterhout_讲授的这个[视频](https://www.youtube.com/watch?v=YbZ3zDzDnrw)非常的棒。 + 3. [`RAFT`](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)是易于理解的一致性算法之一。由 _John Ousterhout_ 讲授的这个[视频](https://www.youtube.com/watch?v=YbZ3zDzDnrw)非常的棒。 - 你可以的看到在不同的实时分布式数据库中动作日志角色： 1. [`PNUTS`](https://www.youtube.com/watch?v=YbZ3zDzDnrw)是探索在大规模的传统的分布式数据库系统中实施以日志为中心设计理念的系统。 2. [`Hbase`](http://hbase.apache.org/)和`Bigtable`都是在目前的数据库系统中使用日志的样例。 diff --git a/python-philosophy/README.md b/python-philosophy/README.md index 9de9cd5..750c513 100644 --- a/python-philosophy/README.md +++ b/python-philosophy/README.md @@ -76,13 +76,13 @@ PS： 核心复杂度的说明讨论可以参见[《代码大全》](http://book `C`的`Geek`，喜欢写稠密的代码，比如使用`++`，`--`运算符来压缩代码行。 在`Python`看来，这个做法不可取，即会让代码更可能出错（如自增操作的负作用），也降低了代码的可读性。 -**_[5]_** 这里的荷兰人指`Python`之父_Guido_，参见说明：[武汉大学开源技术俱乐部 技术交流 第1期](http://qianjigui.iteye.com/blog/266365)。 +**_[5]_** 这里的荷兰人指`Python`之父[_Guido_](https://zh.wikipedia.org/wiki/%E5%90%89%E5%A4%9A%C2%B7%E8%8C%83%E7%BD%97%E8%8B%8F%E5%A7%86)，参见说明：[武汉大学开源技术俱乐部 技术交流 第1期](http://qianjigui.iteye.com/blog/266365)。 -在这里作者[_TimPeters_](http://www.c2.com/cgi/wiki?TimPeters)即含蓄地表达了对`Python`之父_Guido_的敬意，又体现了自己作为`Python`开发的傲娇，不是吗？ :grin: +在这里作者[_TimPeters_](http://www.c2.com/cgi/wiki?TimPeters)即含蓄地表达了对`Python`之父[_Guido_](https://zh.wikipedia.org/wiki/%E5%90%89%E5%A4%9A%C2%B7%E8%8C%83%E7%BD%97%E8%8B%8F%E5%A7%86)的敬意，又体现了自己作为`Python`开发的傲娇，不是吗？ :grin: **_[6] [7]_** 关于『Now/现在』、『never/决不』、『right now/马上』，个人理解，这个条目要说的是： -决定是否做实现一个功能，要想清楚，要么做要么不做，都能给出**_明确_**的理由；但不要模模糊糊的说『后面马上』做，回避对系统的分析思考。 +决定是否做实现一个功能，要想清楚，要么做要么不做，都能给出 **_明确的_** 理由；但不要模模糊糊的说『后面马上』做，回避对系统的分析思考。 否则结果会是： diff --git a/recommend-lisp-books/README.md b/recommend-lisp-books/README.md index 5b97538..aadc7e5 100644 --- a/recommend-lisp-books/README.md +++ b/recommend-lisp-books/README.md @@ -5,7 +5,7 @@ 由于`Lisp`与其它语言从**基本概念**就开始的差异，已有的语言经验反而是个学习阻碍，深入浅出的巧妙讲解对入门太重要了。 - [图谱实验室](http://blog.sina.com.cn/tupulab)的[学习`Lisp`的书籍推荐](recommend-lisp-books.md) - 让我知道**_Successful Lisp: How to Understand and Use Common Lisp_**这本入门的好书。 + 让我知道 **_Successful Lisp: How to Understand and Use Common Lisp_** 这本入门的好书。 [在线版](http://psg.com/~dlamkins/sl/contents.html) / [`PDF`版](http://ebixio.com/online_docs/SuccessfulLisp.pdf) - [Successful Lisp](http://book.douban.com/subject/1456905/)中的[`Lisp`书籍推荐](suggestions4further-reading-in-successful-lisp.md) - 个人的整理的[`Lisp`书籍豆列](http://www.douban.com/doulist/40854103/)。 diff --git a/recommend-lisp-books/recommend-lisp-books.md b/recommend-lisp-books/recommend-lisp-books.md index b1641b1..e8c26c1 100644 --- a/recommend-lisp-books/recommend-lisp-books.md +++ b/recommend-lisp-books/recommend-lisp-books.md @@ -2,13 +2,11 @@ -学习`Lisp`的书籍推荐 -===================== +# 学习`Lisp`的书籍推荐 为大家推荐几本学习`Lisp`的书籍。 -1. [SICP](http://book.douban.com/subject/1148282/) （计算机程序的构造和解释） ------------------------------ +## 1. [SICP](http://book.douban.com/subject/1148282/) （计算机程序的构造和解释） 作为编程界两大圣经之一，麻省理工的本科教材。非常经典，该书以`Lisp`的方言`Scheme`做为代码示例。 （`Scheme`语法简洁，较`Common Lisp`来说功能少，语法少，什么功能都要自己写，适合教学。） @@ -21,8 +19,7 @@ 如果快了话，前三章每天4个小时一周可以读完（包括做课后题），建议英语好的读英文版，中文版翻译质量不高。 该书的作用是以下几本书中不可替代的，它是从如何学编程的角度讲的，以下的书是从如何学`Lisp`的角度讲的。 -2. [On Lisp](http://book.douban.com/subject/1432683/) ------------------------------ +## 2. [On Lisp](http://book.douban.com/subject/1432683/) 该书适合对`Lisp`有一定基础的同学，是迄今为止讲`Lisp`的书籍中最深的一本，至今无人超越。 该书作者是`Lisp`界的导师：保罗格雷勒姆于29岁时写的（大器早成啊）。 @@ -31,27 +28,24 @@ 该书在很大程度上展示了`Lisp`的威力和很多在使用过程中的注意事项。 网络上有人翻译了该书，大概有两三个版本，其中有一版翻译的非常之好，以至于超越了英文版，因为它纠正了英文版中的一些错误 -（这些错误是由于**_On Lisp_**写于，`ANSI Common Lisp`标准出台之前，不是保罗的错） +（这些错误是由于 **_On Lisp_** 写于，`ANSI Common Lisp`标准出台之前，不是保罗的错） -3. [Successful Lisp](http://book.douban.com/subject/1456905/) ------------------------------ +## 3. [Successful Lisp](http://book.douban.com/subject/1456905/) 这本书可以作为`Common Lisp`的入门教程，语言浅显易懂，示例也很到位，没有什么废话。 把`Lisp`的基本特性表述的很完整。该书于近些年成书，所以带有现代的气息。 非常不错，值得一看。该书只有英文版，可以免费在线阅读。 -4. [Ansi Common Lisp](http://book.douban.com/subject/1456906/) ------------------------------ +## 4. [Ansi Common Lisp](http://book.douban.com/subject/1456906/) 这本同样是老保罗写的，是在`ANSI`标准颁发之后写的`Common Lisp`入门教程。 主要是讲`Common Lisp`的语法的。适合初学者阅读，书后的附录很有参考价值。 -可快速阅读，该书只有英文版，没有**_Successful Lisp_**生动，但是书很薄，作为快速入门的途径不错。 +可快速阅读，该书只有英文版，没有 **_Successful Lisp_** 生动，但是书很薄，作为快速入门的途径不错。 @oldratlee 注： 已有[ANSI Common Lisp 中文版](http://acl.readthedocs.org/en/latest/zhCN/index.html)。 -5. [Practical Common Lisp](http://book.douban.com/subject/10419466/) ------------------------------ +## 5. [Practical Common Lisp](http://book.douban.com/subject/10419466/) 该书的最大特点是废话多，前3章值得阅读。 最后几章的例子可以阅读。中间章节废话过多。