diff --git a/10-things-you-didnt-know-about-java/README.md b/10-things-you-didnt-know-about-java/README.md index 6da98b5..8fb23e3 100644 --- a/10-things-you-didnt-know-about-java/README.md +++ b/10-things-you-didnt-know-about-java/README.md @@ -58,7 +58,7 @@ class Test { } ``` -是的！`Java`语言不允许一个类里有2个方法是『***重载一致***』的，而不会关心这2个方法的`throws`子句或返回类型实际上是不同的。 +是的！`Java`语言不允许一个类里有2个方法是『**_重载一致_**』的，而不会关心这2个方法的`throws`子句或返回类型实际上是不同的。 但是等一下！来看看[`Class.getMethod(String, Class...)`](http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getMethod-java.lang.String-java.lang.Class...-)方法的`Javadoc`： @@ -137,7 +137,7 @@ class Test { ```java @Target(ElementType.TYPE_USE) @interface Crazy {} - + class Test { @Crazy int[][] a1 = {{}}; int @Crazy [][] a2 = {{}}; @@ -159,7 +159,7 @@ class Test { > 在我4周休假前的最后一个提交里，我写了这样的代码，然后。。。 ![for-you-my-dear-coworkers](for-you-my-dear-coworkers.jpg) -【***译注***：然后，亲爱的同事你，就有得火救啦，哼，哼哼，哦哈哈哈哈～】 +【**_译注_**：然后，亲爱的同事你，就有得火救啦，哼，哼哼，哦哈哈哈哈～】 请找出上面用法的合适的使用场景，这个还是留给你作为一个练习吧。 @@ -312,7 +312,7 @@ for (int i = 0; i < 10; i++) { > 在我4周休假前的最后一个提交里，我写了这样的代码，然后。。。 ![for-you-my-dear-coworkers](for-you-my-dear-coworkers.jpg) -【***译注***：然后，亲爱的同事你，就有得火救啦，哼，哼哼，哦哈哈哈哈～】 +【**_译注_**：然后，亲爱的同事你，就有得火救啦，哼，哼哼，哦哈哈哈哈～】 7. `GOTO` --------------------------------------- @@ -459,7 +459,7 @@ class Test { 一个很难的问题，[`Ross Tate `](http://www.cs.cornell.edu/~ross/)回答过。答案实际上是不确定的： -***`C`是`Type`的子类吗？*** +**_`C`是`Type`的子类吗？_** ```java 步骤 0) C @@ -470,7 +470,7 @@ class Test { 然后： -***`D`是`Type>`的子类吗？*** +**_`D`是`Type>`的子类吗？_** ```java 步骤 0) D > diff --git a/README.md b/README.md index c9cf39d..12d2373 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ Chinese translations for good english 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`。可以说不读这篇论文你就不知道**你还不知道**如何有效地描述和交流一致性算法。 @@ -50,7 +50,7 @@ Chinese translations for good english resources. `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`入门的难度，整理了[`Lisp`书籍推荐和点评](recommend-lisp-books/README.md) - 特别提这篇好文[【转】学习`Lisp`的书籍推荐](recommend-lisp-books/recommend-lisp-books.md) diff --git a/git-workflows-and-tutorials/README.md b/git-workflows-and-tutorials/README.md index 6eeacf4..235879d 100644 --- a/git-workflows-and-tutorials/README.md +++ b/git-workflows-and-tutorials/README.md @@ -17,11 +17,11 @@ `Forking`工作流是分布式协作的（`GitHub`风格）可以先看看`GitHub`的Help：[Fork A Repo](https://help.github.com/articles/fork-a-repo/)和[Using pull requests](https://help.github.com/articles/using-pull-requests/) 。照着操作，给一个`GitHub`项目贡献你的提交，有操作经验再看指南容易意会。指南中给了[自己实现`Fork`的方法](https://github.com/oldratlee/translations/blob/master/git-workflows-and-tutorials/workflow-forking.md#%E5%BC%80%E5%8F%91%E8%80%85fork%E6%AD%A3%E5%BC%8F%E4%BB%93%E5%BA%93)：`Fork`就是服务端的克隆。在指南的操练中使用代码托管服务（如`GitHub`、`Bitbucket`），可以点一下按钮就让开发者完成仓库的`fork`操作。 -***PS***： +**_PS_**： 文中`Pull Request`的介绍用的是`Bitbucket`代码托管服务，由于和`GitHub`基本一样，如果你用的是`GitHub`（我自己也主要使用`GitHub`托管代码），不影响理解和操作。 -***PPS***： +**_PPS_**： 更多`Git`学习资料参见 diff --git a/gui-and-cli-principles/README.md b/gui-and-cli-principles/README.md index de17dcb..dc9c01a 100644 --- a/gui-and-cli-principles/README.md +++ b/gui-and-cli-principles/README.md @@ -35,9 +35,9 @@ PS： 在展示和说明一件事时，`GUI`更优。 -一个好例子是，标准的`GUI` `Diff`工具。尽管可以算出差异后用统一格式输出 ***[1]***，但分屏对比显示（比如像`VimDiff`、`Tortoise`自带的`Diff`）会方便很多，新老文件左右两边对比显示，使用不同的颜色来标识出修改部分。 +一个好例子是，标准的`GUI` `Diff`工具。尽管可以算出差异后用统一格式输出 **_[1]_**，但分屏对比显示（比如像`VimDiff`、`Tortoise`自带的`Diff`）会方便很多，新老文件左右两边对比显示，使用不同的颜色来标识出修改部分。 -***[1]*** 译注：`diff`命令的输出格式参见：[读懂diff](http://www.ruanyifeng.com/blog/2012/08/how_to_read_diff.html "读懂diff") +**_[1]_** 译注：`diff`命令的输出格式参见：[读懂diff](http://www.ruanyifeng.com/blog/2012/08/how_to_read_diff.html "读懂diff") ### `GUI`原则#2 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md index 5f7cb4e..3a9d701 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md @@ -8,7 +8,7 @@ [学习笔记：The Log（我所读过的最好的一篇分布式技术文章）](http://www.cnblogs.com/foreach-break/p/notes_about_distributed_system_and_The_log.html)对本文做了很不错摘要和解读。 -但作为一篇***经典***文章，是值得去完整地研读和理解： +但作为一篇**_经典_**文章，是值得去完整地研读和理解： 1. 原文可以作为大数据/分布式系统领域一份导论式的资料。 作者对整个领域的理解和实战精深广博，抓出并梳理了这个领域的核心：日志。 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 1eb28ac..ff75679 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/)），现在先 **_不要_** 去看，除非读完本文后你还是有很兴趣要探个明白！ 日志记录的内容和格式是什么对于本文讨论并不重要。另外，不可能一直给日志添加记录，因为总会耗尽存储空间。稍后我们会再回来讨论这个问题。 @@ -65,7 +65,7 @@ [确定性](http://en.wikipedia.org/wiki/Deterministic_algorithm)（`deterministic `）意味着处理过程是与时间无关的，而且不让任何其他『带外数据（`out of band`）』的输入影响处理结果。 例如，如果一个程序的输出会受到线程执行的具体顺序影响，或者受到`getTimeOfDay`调用、或者其他一些非重复性事件的影响，那么这样的程序一般被认为是非确定性的。 -进程***状态*** 是进程保存在机器上的任何数据，在进程处理结束的时候，这些数据要么保存在内存里，要么保存在磁盘上。 +进程**_状态_** 是进程保存在机器上的任何数据，在进程处理结束的时候，这些数据要么保存在内存里，要么保存在磁盘上。 当碰到以相同的顺序输入相同的内容的情况时，应该触发你的条件反射：这个地方要引入日志。 下面是个很直觉的意识：如果给两段确定性代码相同的日志输入，那么它们就会生产相同的输出。 @@ -82,7 +82,7 @@ 理论上来说，我们甚至可以记录各个副本执行的机器指令序列的日志 或是 所调用的方法名和参数序列的日志。 只要两个进程用相同的方式处理这些输入，这些副本进程就会保持一致的状态。 -对日志用法不同群体有不同的说法。数据库工作者通常说成***物理***日志（`physical logging`）和***逻辑***日志（`logical logging`）。物理日志是指记录每一行被改变的内容。逻辑日志记录的不是改变的行而是那些引起行的内容改变的`SQL`语句（`insert`、`update`和`delete`语句）。 +对日志用法不同群体有不同的说法。数据库工作者通常说成**_物理_**日志（`physical logging`）和**_逻辑_**日志（`logical logging`）。物理日志是指记录每一行被改变的内容。逻辑日志记录的不是改变的行而是那些引起行的内容改变的`SQL`语句（`insert`、`update`和`delete`语句）。 分布式系统文献通常把处理和复制（`processing and replication`）方案宽泛地分成两种。『状态机器模型』常常被称为主动-主动模型（`active-active model`）， 记录输入请求的日志，各个复本处理每个请求。 @@ -127,7 +127,7 @@ 这个过程也是可逆的：如果你对一张表进行更新，你可以记录这些变更，并把所有更新的『变更日志（`changelog`）』发布到表的状态信息中。 这些变更日志正是你所需要的支持准实时的复制。 基于此，你就可以清楚的理解表与事件的二相性： 表支持了静态数据，而日志记录了变更。日志的魅力就在于它是变更的_完整_记录，它不仅仅包含了表的最终版本的内容， -而且可以用于重建任何存在过其它版本。事实上，日志可以看作是表***每个***历史状态的一系列备份。 +而且可以用于重建任何存在过其它版本。事实上，日志可以看作是表**_每个_**历史状态的一系列备份。 这可能会让你想到源代码的版本控制（`source code version control`）。源码控制和数据库之间有着密切的关系。 版本管理解决了一个和分布式数据系统要解决的很类似的问题 —— 管理分布式的并发的状态变更。 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 0faf088..06e3ad0 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)。 @@ -97,7 +97,7 @@ > > [『每个工作的数据管道要设计得像是一个日志；每个损坏的数据管道都以其自己的方式损坏。』 -> —— ***Count Leo Tolstoy*** （由作者翻译）](http://en.wikipedia.org/wiki/Anna_Karenina_principle) +> —— **_Count Leo Tolstoy_** （由作者翻译）](http://en.wikipedia.org/wiki/Anna_Karenina_principle) 这里我使用术语『日志』取代了『消息系统』或者『发布-订阅』，因为在语义上明确得多，并且准确得多地描述了在实际实现中支持数据复制时你所要做的事。 我发现『发布订阅』只是表达出了消息的间接寻址（`indirect addressing of messages`） —— @@ -240,7 +240,7 @@ 这意味着作为系统设计和实现一部分的生产者，在交付到中心通道时， 必须考虑其输出和输入的数据要有良好结构形式的问题。 新的存储系统的加入对于数据仓库团队是无关紧要的，因为他们现在有的是一个中心结点去集成。 -（***译注***：原来要集成的是其它各个相关的系统，工作是被简化了的） +（**_译注_**：原来要集成的是其它各个相关的系统，工作是被简化了的） 数据仓库团队需只处理更简单的问题，从中心日志中加载结构化的输入数据、完成特定于他们系统的数据转换。 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 cdceb4d..2f9c51e 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 @@ -13,16 +13,16 @@ - 关于[状态机](http://www.cs.cornell.edu/fbs/publications/smsurvey.pdf%E2%80%8E)和[主备份](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.5896)复制的概述。 - [`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年才发表了，因为评审组不喜欢论文中的希腊寓言，而作者又不愿修改。 - 2. 甚至于论文发布以后，它还是不被人们理解。***Lamport*** 再次尝试，这次它包含了一些并不有趣的小细节，这些细节是关于如何使用这些新式的自动化的计算机的。 + **_Leslie Lamport_** 有一个有趣的历史：在80年代算法是如何发现的，但是直到1998年才发表了，因为评审组不喜欢论文中的希腊寓言，而作者又不愿修改。 + 2. 甚至于论文发布以后，它还是不被人们理解。**_Lamport_** 再次尝试，这次它包含了一些并不有趣的小细节，这些细节是关于如何使用这些新式的自动化的计算机的。 它仍然没有得到广泛的认可。 3. [Fred Schneider](http://www.cs.cornell.edu/fbs/publications/SMSurvey.pdf)和[Butler Lampson](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)分别给出了更多细节关于在实时系统中如何应用Paxos. 4. 一些Google的工程师总结了他们在Chubby中实施Paxos的[经验](http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf)。 diff --git a/python-philosophy/README.md b/python-philosophy/README.md index 40550bd..7d9d0bf 100644 --- a/python-philosophy/README.md +++ b/python-philosophy/README.md @@ -13,13 +13,13 @@ 美优于丑。 2. Explicit is better than implicit. 直白优于隐晦。 -3. Simple is better than complex ***[1]***. +3. Simple is better than complex **_[1]_**. 简单优于复杂。 -4. Complex is better than complicated ***[2]*** . +4. Complex is better than complicated **_[2]_** . 复杂优于纠结。 5. Flat is better than nested. 扁平优于嵌套。 -6. Sparse is better than dense ***[3]*** . +6. Sparse is better than dense **_[3]_** . 稀疏优于稠密。 7. Readability counts. 可读性是有重要价值的。 @@ -35,7 +35,7 @@ 面对二义性情况时，要拒绝任何猜的诱惑。 11. There should be one -- and preferably only one -- obvious way to do it. 应该有一个，并且宁愿只有一个做法，一个显而易见的做法。 - * Although that way may not be obvious at first unless you're Dutch ***[4]***. + * Although that way may not be obvious at first unless you're Dutch **_[4]_**. 尽管在刚开始的时候这个做法可能不是那么显而易见，毕竟你不是荷兰人。 12. Now is better than never. “现在” 优于 “决不”。 @@ -50,7 +50,7 @@ ### 译注 -***[1] [2]*** 单词complex的意思是 复杂，而complicated 是 结构复杂。 +**_[1] [2]_** 单词complex的意思是 复杂，而complicated 是 结构复杂。 在计算机领域中，complex 可以对应 单个模块复杂，而complicated 则可以对应 多个模块互相关联的复杂。 用计算机的术语来说，complicated 是不同模块之间紧“耦合”，体现了理解不深，设计不好。 @@ -62,11 +62,11 @@ PS： 核心复杂度的说明讨论可以参见[《代码大全》](http://book 翻译上，complex 翻成 复杂，complicated 翻成 纠结。 -***[3]*** 稀疏、稠密指的是代码行中操作的疏密。 +**_[3]_** 稀疏、稠密指的是代码行中操作的疏密。 `C`的Geek，喜欢写稠密的代码，比如使用`++`，`--`运算符来压缩代码行。 在`Python`看来，这个做法不可取，即会让代码更可能出错（如自增操作的负作用），也降低了代码的可读性。 -***[4]*** 这里的荷兰人指`Python`之父Guido，参见说明：[武汉大学开源技术俱乐部 技术交流 第1期](http://qianjigui.javaeye.com/blog/266365)。 +**_[4]_** 这里的荷兰人指`Python`之父Guido，参见说明：[武汉大学开源技术俱乐部 技术交流 第1期](http://qianjigui.javaeye.com/blog/266365)。 在这里作者[TimPeters](http://www.c2.com/cgi/wiki?TimPeters)即含蓄地表达了对`Python`之父Guido的敬意，又体现了自己作为`Python`开发的傲娇，不是吗？ :grin: diff --git a/recommend-lisp-books/README.md b/recommend-lisp-books/README.md index 7ddcb4d..25eca70 100644 --- a/recommend-lisp-books/README.md +++ b/recommend-lisp-books/README.md @@ -6,7 +6,7 @@ - [Successful Lisp](http://book.douban.com/subject/1456905/)中的[`Lisp`书籍推荐](suggestions4further-reading-in-successful-lisp.md) - [图谱实验室](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) ![lisp](lisp.png) diff --git a/recommend-lisp-books/recommend-lisp-books.md b/recommend-lisp-books/recommend-lisp-books.md index a426754..c43878f 100644 --- a/recommend-lisp-books/recommend-lisp-books.md +++ b/recommend-lisp-books/recommend-lisp-books.md @@ -31,7 +31,7 @@ 该书在很大程度上展示了`Lisp`的威力和很多在使用过程中的注意事项。 网络上有人翻译了该书，大概有两三个版本，其中有一版翻译的非常之好，以至于超越了英文版，因为它纠正了英文版中的一些错误 -（这些错误是由于***On Lisp***写于，`ANSI Common Lisp`标准出台之前，不是保罗的错） +（这些错误是由于**_On Lisp_**写于，`ANSI Common Lisp`标准出台之前，不是保罗的错） 3. [Successful Lisp](http://book.douban.com/subject/1456905/) ----------------------------- @@ -45,7 +45,7 @@ 这本同样是老保罗写的，是在`ANSI`标准颁发之后写的`Common Lisp`入门教程。 主要是讲`Common Lisp`的语法的。适合初学者阅读，书后的附录很有参考价值。 -可快速阅读，该书只有英文版，没有***Successful Lisp***生动，但是书很薄，作为快速入门的途径不错。 +可快速阅读，该书只有英文版，没有**_Successful Lisp_**生动，但是书很薄，作为快速入门的途径不错。 @oldratlee 注： 已有[ANSI Common Lisp 中文版](http://acl.readthedocs.org/en/latest/zhCN/index.html)。