{"id":13495677,"url":"https://github.com/oldratlee/translations","last_synced_at":"2025-05-12T15:33:00.218Z","repository":{"id":20013911,"uuid":"23281534","full_name":"oldratlee/translations","owner":"oldratlee","description":"🐼  Chinese translations for classic software development resources","archived":false,"fork":false,"pushed_at":"2025-03-09T17:28:25.000Z","size":14455,"stargazers_count":6884,"open_issues_count":27,"forks_count":1551,"subscribers_count":420,"default_branch":"master","last_synced_at":"2025-05-07T00:52:03.676Z","etag":null,"topics":["api","api-design","chinese-translation","concurrency","consensus","design","design-principle","distributed-systems","elixir","erlang","experiment","functional-programming","git","lisp","paxos","python","reactive","simplified-chinese","translation","translations"],"latest_commit_sha":null,"homepage":"https://github.com/oldratlee/translations","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/oldratlee.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2014-08-24T13:21:11.000Z","updated_at":"2025-05-05T02:08:52.000Z","dependencies_parsed_at":"2025-03-27T20:10:22.186Z","dependency_job_id":null,"html_url":"https://github.com/oldratlee/translations","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oldratlee%2Ftranslations","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oldratlee%2Ftranslations/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oldratlee%2Ftranslations/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oldratlee%2Ftranslations/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/oldratlee","download_url":"https://codeload.github.com/oldratlee/translations/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253765906,"owners_count":21960816,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["api","api-design","chinese-translation","concurrency","consensus","design","design-principle","distributed-systems","elixir","erlang","experiment","functional-programming","git","lisp","paxos","python","reactive","simplified-chinese","translation","translations"],"created_at":"2024-07-31T19:01:37.040Z","updated_at":"2025-05-12T15:33:00.195Z","avatar_url":"https://github.com/oldratlee.png","language":null,"funding_links":[],"categories":["Others","Technical"],"sub_categories":[],"readme":"# 🐼 translations\n\n\u003ca href=\"##\"\u003e\u003cimg src=\"images/icon.png\" width=\"20%\" align=\"right\" /\u003e\u003c/a\u003e\n\n[![知识共享协议（CC协议）](https://img.shields.io/badge/License-Creative%20Commons-FE6B3A.svg?logo=apache) ![Licence: CC BY-NC-SA 4.0](images/LICENSE.png)](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)  \n[![GitHub stars](https://img.shields.io/github/stars/oldratlee/translations.svg?style=social\u0026label=Star)](https://github.com/oldratlee/translations/stargazers)\n[![GitHub forks](https://img.shields.io/github/forks/oldratlee/translations.svg?style=social\u0026label=Fork)](https://github.com/oldratlee/translations/fork)\n[![GitHub Contributors](https://img.shields.io/github/contributors/oldratlee/translations?style=social\u0026logo=github)](https://github.com/oldratlee/translations/graphs/contributors)\n\n一些不错英文资料的中文翻译。  \nChinese translations for classic IT resources.\n\n----------------------------------------\n\n[自己](http://weibo.com/oldratlee)想到去做些翻译，原因是：\n\n1. 促进 自己的**深入学习**。\n    - 一份经典资料深入研读十遍，相信收益大于，泛读十份资料。\n    - 而深入学习理解是翻译所要求反复推敲的副产品，主动表达会是个更好的学习方式。\n1. 训练 自己的**写作基础技能**。\n    - 写作即是思考，文字是我们表达思想最常用的方式，也可能是最有用的方式。\n    - 写作、遣词造句是最重要的基础技能之一，而翻译是在刻意练习这个技能。\n    - 虽说纸短情长、言外有意，语言文字并不能表达想要表达的一切，但只要输出成语言文字就有了在时间与空间上更好的扩展性：\n        - 语言文字可以长时间的流传，而不限于作者的几十年光景。\n        - 语言文字可以给大量人的阅读，而不限于作者所在的场合范围。\n        - 可以被使用传承，甚至进一步改进和衍生。\n    - 思想的文字化/文档化 意味着 **文明**（仅个人的拔高说辞 😂 ）。\n1. 能为大家 带来**便利**。\n1. **兴趣**。\n\n翻译遵循的原则：『信』为本，力求『达』，不妄追『雅』。\n\n\u003e 信：译文忠实表达作者思想；达：让读者轻松地阅读；雅：让读者愉悦地阅读。  \n\u003e 详见[信达雅 - 百度百科](http://baike.baidu.com/view/645992.htm)。\n\n----------------------------------------\n\n- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中的不足和不对之处，欢迎 👏\n    - 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new)\n    - 指正，[`Fork`后提通过`Pull Request`贡献修改](https://github.com/oldratlee/translations/fork)\n- 如果文章理解上有疑问 或是 应用过程中碰到疑惑，请[提交 🙌 `Issue`](https://github.com/oldratlee/translations/issues/new) ，一起学习交流讨论！\n\n\u003e 翻译是译者用自己的思想，换一种语言，对原作者想法的重新阐释。鉴于我的学识所限，误解和错译在所难免。如果你能买到本书的原版，且有能力阅读英文，请直接去读原文。因为与之相较，我的译文可能根本不值得一读。  \n\u003e 　— 云风，《[程序员修炼之道 第2版](https://book.douban.com/subject/35006892/)》译者\n\u003e\n\u003e 阅读的价值，取决于你真正想得到的是什么体验。  \n\u003e 　— 此句由`@mj5219054`的`PR`提供\n\n愿你阅读愉快，祝你日有所进～ 💕\n\n# ⏳ 按内容时间排序\n\n\u003e 下一节是 [⬇️ **按内容主题分类** ⬇️](#-%E6%8C%89%E5%86%85%E5%AE%B9%E4%B8%BB%E9%A2%98%E5%88%86%E7%B1%BB)\n\n- **2020-02** [理解`Kotlin`协程：自底向上的视角](kotlin-coroutines-bottom-up/README.md)  \n    `Kotlin`的协程应该是`Java`生态中最好的协程实现，在生产环境（`Android` / 后端场景）也有比较多实际应用。\n    无论是`Kotlin`语言还是`Kotlin`协程，都非常注重务实与开发者友好，`Kotlin`协程以大家习惯的命令式/过程式的编程方式写出非阻塞的高效并发程序。\n    但并发编程是计算机最复杂的主题之一，即使是用协程的编写方式；再者`Kotlin`协程的友好使用方式，对于使用者理解协程背后的运行机制其实反而是个障碍。而真正的理解协程才能让使用协程做到心中有数避免踩坑。这篇文章自底向上视角的讲解方式，正是有意于正面解决这个问题：如何有效理解`Kotlin`协程的运行机制。\n- **2019-09** [手把手介绍函数式编程：从命令式重构到函数式](a-practical-introduction-to-functional-programming/README.md)  \n    本文是一篇手把手的函数式编程入门介绍，借助代码示例讲解细腻。但又不乏洞见，第一节中列举和点评了函数式种种让眼花缭乱特质，给出了『理解函数式特质的指南针：函数式代码的核心特质就一条，**无副作用**』，相信对于有积极学过挖过的函数式同学看来更是有相知恨晚的感觉。希望看了这篇文章之后能在学习和使用函数式编程的旅途中不再迷路哦，兄die～\n- **2018-10** [务实的函数式编程（by Bob大叔）](pragmatic-functional-programming/README.md)  \n    `Bob`大叔的短文，`FP`在软件开发优点上务实的思考，引导大家理解、学习和使用`FP`，文章后半篇还用`FP`语言`Clojure`简约演示了一番。在文末不忘呼吁学习`FP`，并推荐`Clojure`语言。\n- **2018-10** [Codehaus宣言：技术管理与开源项目运营之道](codehaus-manifesto/README.md)  \n    `Codehaus`：协作构建开源项目的社区，强烈强调现代语言，并开发聚焦于满足实际需求的高质量组件。`Groovy`、`Jetty`、`Gradle`、`XStream`、`Jackson`、`Drools`、`jMock`、`EasyMock`、`Grails`、`XDoclet`、`QDox`、`Esper`、`Mule`、`Janino`、`JBehave`、`Stomp` 以及其他数以百计开源项目，都得感谢`Codehaus`社区。很多项目听起来都是如雷贯耳吧，而这份精小的`Codehaus`宣言是`Codehaus`多年在技术管理与开源项目运营上的思考、总结与领悟，相信非常值得一读！**向`Codehaus`致敬！！**\n- **2017-11** [`Java` `Fork/Join`框架](a-java-fork-join-framework/README.md)  \n    _Doug Lea_ 大神关于`Java 7`引入的他写的`Fork/Join`框架的论文。[反应式编程](https://www.reactivemanifesto.org/zh-CN)（`Reactive Programming`/`RP`）作为一种范式在整个业界正在逐步受到认可和落地，是对过往系统的业务需求理解梳理之后对系统技术设计/架构模式的提升总结。`Java`作为一个成熟平台，对于趋势一向有着稳健的接纳和跟进能力，有着令人惊叹的生命活力：`Java 7`提供了`ForkJoinPool`，支持了`Java 8`提供的`Stream`，另外`Java 8`还提供了`Lambda`（有效地表达和使用`RP`需要`FP`的语言构件和理念）；有了前面的这些稳健但不失时机的准备，在`Java 9`中提供了面向`RP`的官方[`Flow API`](https://community.oracle.com/docs/DOC-1006738)，实际上是直接把[`Reactive Streams`](http://www.reactive-streams.org/)的接口加在`Java`标准库中，即[`Reactive Streams`规范](https://github.com/reactive-streams/reactive-streams-jvm#specification)转正了。`Reactive Streams`是`RP`的基础核心组件，`Java`提供了`Flow API` 标志着 `RP`完成了由 **集市**式的自由探索阶段 向 **教堂**式的规范统一阶段 的转变。通过上面这些说明，可以看到`ForkJoinPool`的基础重要性。\n- **2017-07** [`API`设计原则 - `Qt`官网的设计实践总结](api-design-principles-from-qt/README.md)  \n    `Qt`的设计水准在业界很有口碑，一致、易于掌握和强大的`API`是`Qt`最著名的优点之一。此文既是`Qt`官网上的`API`设计指导准则，也是`Qt`在`API`设计上的实践总结。虽然`Qt`用的是`C++`，但其中设计原则和思考是具有普适性的；如果你对`C++`还不精通，完全可以忽略与`C++`强相关或是过于细节的部分，仍然能学习或梳理关于`API`设计最有价值的内容。整个篇幅中有很多示例，是关于`API`设计一篇难得的好文章。\n- **2017-05** [重叠实验设施：更多、更好、更快地实验](overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md)  \n    `Google`这篇10年前2010年的关于『实验基础设施』设计的论文，现在看来仍然是关于这个领域最有深度和体系的资料。不单说明了，实验设施的系统设计，还包含实验的进阶主题如：实验可信度、敏感度、围绕实验数据驱动的整体流程。对于了解`Growth Hacking`/`ABTest`的同学，可以有效的学习实验设施的系统设计，尤其是重叠实验设施要考虑多方面的需求、维度，如何建模是很复杂的；对于不了解`Growth Hacking`/`ABTest`这个领域知识的同学，可以通过这篇文章，学习一个复杂系统整体的思考和设计的模式，包含需求、场景、模型设计、产品流程、落地关键。\n- **2016-10** [`Erlang`之父学习`Elixir`语言的一周](a-week-with-elixir/README.md)  \n    作为`Erlang`之父 _Joe Armstrong_，对`Erlang VM`上的新语言`Elixir`做了很精彩的评论和思考。『特定领域专家的专业直觉』、『编程语言设计的三定律』、『管道操作符避免恶心代码』、『`Elixir`的`sigil`引出的程序语言如何定义/解释字符串』等等问题的讨论，个性鲜明又幽默诙谐的行文风格，都能强烈感受到 _Joe Armstrong_ 深入广博的老黑客风范。\n- **2015-10** [提问的智慧](how-to-ask-questions-the-smart-way/README.md)  \n    说明了作者所认为一位发问者事前应该要做好什么，而什么又是不该做的。作者认为这样能让问题容易令人理解，而且发问者自己也能学到较多东西。此文在网络上受到欢迎，被广泛转载而广为人知甚至奉为经典。著名的两个缩写`STFW`（`Search the fxxking web`）以及`RTFM`（`Read the fxxking manual`）就是出自本文。\n- **2015-08** [日志：每个软件工程师都应该知道的有关实时数据的统一抽象](log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md)  \n    这篇文章是`LinkedIn`的`Kreps`发表的一篇博文，被称为 **_程序员史诗般必读_** 文章。可以作为大数据/分布式系统领域一份导论式的资料。作者对整个领域的理解和实战精深广博，抓出并梳理了这个领域的核心：日志。\n- **2014-09** [**_Successful Lisp_** 中的`Lisp`书籍推荐](recommend-lisp-books/suggestions4further-reading-in-successful-lisp.md)\n    - [`Lisp`书籍推荐和点评](recommend-lisp-books/README.md)，由于`Lisp`与其它语言从**基本概念**就开始的差异，已有的语言经验反而是个学习阻碍，深入浅出的巧妙讲解对入门太重要了。\n    - 特别提这篇好文[【转】学习`Lisp`的书籍推荐](recommend-lisp-books/recommend-lisp-books.md)\n- **2014-09** [`Git`工作流指南](git-workflows-and-tutorials/README.md)  \n    关于`Git`工作流主题，也许这是目前最全面最深入的说明。这篇指南以大家在`SVN`中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的`Pull Request`功能，体系地讲解了各种工作流的应用。行文中实践原则和操作示例并重，对于`Git`的资深玩家可以梳理思考提升，而新接触的同学，也可以跟着step-by-step操练学习并在实际工作中上手使用。\n- **2014-09** [`Git` `2.1`有哪些新特性？](whats-new-git-2-1/README.md)\n- **2014-12** [关于`Java`你可能不知道的10件事](10-things-you-didnt-know-about-java/README.md)  \n    作者是个`Java`老鸟，行文风趣幽默，娓娓道出`Java`的诡异和难点时不忘着给出用心良苦的提点。\n- **2014-03** [如何用`Linux`命令行管理网络：11个你必须知道的命令](how-to-work-with-network-from-linux-terminal/README.md)\n- **2014-03** [为什么`Android`手机会越用越慢，如何提速？](why-android-phones-slow-down-over-time-and-how-to-speed-them-up/README.md)\n- **2013-01** [`PaxosLease`：实现租约的无盘`Paxos`算法](paxoslease/README.rst)  \n    可以说是最简单且可以实际使用的`Paxos`算法变种。\n- **2012-12** [Paxos Made Simple](paxos-made-simple/README.rst)  \n    该论文给出描述一致性问题的概念、术语、算法，从复杂中抓取出了核心，给出了如此简单的描述。另言简意赅地说明了多实例`Paxos`（`Multi-Paxos`），这是真正实践中使用的`Paxos`。可以说不读这篇论文你就不知道**你还不知道**如何有效地描述和交流一致性算法。\n- **2012-11** [`GUI` \u0026 `CLI`原则](gui-and-cli-principles/README.md)  \n    文中列出的`GUI`和`CLI`的原则：说明了两种`Interface`适合的场景和优劣；进而引导你去思考，面向用户或作为程序员的你，交互/操作 如何才能是高效的。\n- **2012-05** [`Java`的通用`I/O` `API`设计](generic-io-api-in-java-and-api-design/README.md)  \n    给出了一个通用`Java` `IO` `API`设计，更重要的是给出了这个`API`设计本身的步骤和过程，这让`API`设计有些条理。文中示范了从 普通简单实现 整理成 正交分解、可复用、可扩展、高性能、无错误的`API`设计 的过程，这个过程是很值得理解和学习！设计偏向是艺术，一个赏心悦目的设计，尤其是`API`设计，旁人看来多是妙手偶得的感觉，如果能有些章可循真是一件美事。在艺术工作中，真的艺术性工作量也只是一部分，而给出 _**方法**_ 以 _**减少艺术工作之中艺术性工作量**_ 的人是 **大师**。\n- **2010-09** [`Python` Philosophy（`Python`哲学）翻译及简析](python-philosophy/README.md)  \n    既有指明大是大非的理念，又有指导细节操作的准则；既有谆谆教导的推荐，也有声色俱厉的禁止。\n- **2010-03** [`Stubs`和`Mocks`的区别](stubs-vs-mocks/README.md)  \n    翻译自《Programming Groovy》，讲得言简意赅。\n\n# 🎵 按内容主题分类\n\n\u003ca href=\"##\"\u003e\u003cimg src=\"images/icon.png\" width=\"30%\" align=\"right\" /\u003e\u003c/a\u003e\n\n\u003e 上一节是 [⬆️ **按内容时间排序** ⬆️](#-%E6%8C%89%E5%86%85%E5%AE%B9%E6%97%B6%E9%97%B4%E6%8E%92%E5%BA%8F)\n\n\u003c!-- START doctoc generated TOC please keep comment here to allow auto update --\u003e\n\u003c!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --\u003e\n\n- [思考/思维](#%E6%80%9D%E8%80%83%E6%80%9D%E7%BB%B4)\n- [设计原则](#%E8%AE%BE%E8%AE%A1%E5%8E%9F%E5%88%99)\n- [系统设计实例](#%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%AE%9E%E4%BE%8B)\n- [分布式系统/大数据](#%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E5%A4%A7%E6%95%B0%E6%8D%AE)\n- [并发](#%E5%B9%B6%E5%8F%91)\n- [`FP`/`Clojure`/`Lisp`](#fpclojurelisp)\n- [`Git`](#git)\n- [`Erlang`/`Elixir`](#erlangelixir)\n- [`Java`](#java)\n- [软件测试](#%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95)\n- [其它](#%E5%85%B6%E5%AE%83)\n\n\u003c!-- END doctoc generated TOC please keep comment here to allow auto update --\u003e\n\n## 思考/思维\n\n1. [提问的智慧](how-to-ask-questions-the-smart-way/README.md)  \n    说明了作者所认为一位发问者事前应该要做好什么，而什么又是不该做的。作者认为这样能让问题容易令人理解，而且发问者自己也能学到较多东西。此文在网络上受到欢迎，被广泛转载而广为人知甚至奉为经典。著名的两个缩写`STFW`（`Search the fxxking web`）以及`RTFM`（`Read the fxxking manual`）就是出自本文。\n\n## 设计原则\n\n1. [`Python` Philosophy（`Python`哲学）翻译及简析](python-philosophy/README.md)  \n    既有指明大是大非的理念，又有指导细节操作的准则；既有谆谆教导的推荐，也有声色俱厉的禁止。\n1. [Codehaus宣言：技术管理与开源项目运营之道](codehaus-manifesto/README.md)  \n    `Codehaus`：协作构建开源项目的社区，强烈强调现代语言，并开发聚焦于满足实际需求的高质量组件。`Groovy`、`Jetty`、`Gradle`、`XStream`、`Jackson`、`Drools`、`jMock`、`EasyMock`、`Grails`、`XDoclet`、`QDox`、`Esper`、`Mule`、`Janino`、`JBehave`、`Stomp` 以及其他数以百计开源项目，都得感谢`Codehaus`社区。很多项目听起来都是如雷贯耳吧，而这份精小的`Codehaus`宣言是`Codehaus`多年在技术管理与开源项目运营上的思考、总结与领悟，相信非常值得一读！**向`Codehaus`致敬！！**\n1. [`Java`的通用`I/O` `API`设计](generic-io-api-in-java-and-api-design/README.md)  \n    给出了一个通用`Java` `IO` `API`设计，更重要的是给出了这个`API`设计本身的步骤和过程，这让`API`设计有些条理。文中示范了从 普通简单实现 整理成 正交分解、可复用、可扩展、高性能、无错误的`API`设计 的过程，这个过程是很值得理解和学习！设计偏向是艺术，一个赏心悦目的设计，尤其是`API`设计，旁人看来多是妙手偶得的感觉，如果能有些章可循真是一件美事。在艺术工作中，真的艺术性工作量也只是一部分，而给出 _**方法**_ 以 _**减少艺术工作之中艺术性工作量**_ 的人是 **大师**。\n1. [`API`设计原则 - `Qt`官网的设计实践总结](api-design-principles-from-qt/README.md)  \n    `Qt`的设计水准在业界很有口碑，一致、易于掌握和强大的`API`是`Qt`最著名的优点之一。此文既是`Qt`官网上的`API`设计指导准则，也是`Qt`在`API`设计上的实践总结。虽然`Qt`用的是`C++`，但其中设计原则和思考是具有普适性的；如果你对`C++`还不精通，完全可以忽略与`C++`强相关或是过于细节的部分，仍然能学习或梳理关于`API`设计最有价值的内容。整个篇幅中有很多示例，是关于`API`设计一篇难得的好文章。\n1. [`GUI` \u0026 `CLI`原则](gui-and-cli-principles/README.md)  \n    文中列出的`GUI`和`CLI`的原则：说明了两种`Interface`适合的场景和优劣；进而引导你去思考，面向用户或作为程序员的你，交互/操作 如何才能是高效的。\n\n## 系统设计实例\n\n1. [重叠实验设施：更多、更好、更快地实验](overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md)  \n    `Google`这篇10年前2010年的关于『实验基础设施』设计的论文，现在看来仍然是关于这个领域最有深度和体系的资料。不单说明了，实验设施的系统设计，还包含实验的进阶主题如：实验可信度、敏感度、围绕实验数据驱动的整体流程。对于了解`Growth Hacking`/`ABTest`的同学，可以有效的学习实验设施的系统设计，尤其是重叠实验设施要考虑多方面的需求、维度，如何建模是很复杂的；对于不了解`Growth Hacking`/`ABTest`这个领域知识的同学，可以通过这篇文章，学习一个复杂系统整体的思考和设计的模式，包含需求、场景、模型设计、产品流程、落地关键。\n\n## 分布式系统/大数据\n\n1. [日志：每个软件工程师都应该知道的有关实时数据的统一抽象](log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md)  \n    这篇文章是`LinkedIn`的`Kreps`发表的一篇博文，被称为 **_程序员史诗般必读_** 文章。可以作为大数据/分布式系统领域一份导论式的资料。作者对整个领域的理解和实战精深广博，抓出并梳理了这个领域的核心：日志。\n1. [Paxos Made Simple](paxos-made-simple/README.rst)  \n    该论文给出描述一致性问题的概念、术语、算法，从复杂中抓取出了核心，给出了如此简单的描述。另言简意赅地说明了多实例`Paxos`（`Multi-Paxos`），这是真正实践中使用的`Paxos`。可以说不读这篇论文你就不知道**你还不知道**如何有效地描述和交流一致性算法。\n1. [`PaxosLease`：实现租约的无盘`Paxos`算法](paxoslease/README.rst)  \n    可以说是最简单且可以实际使用的`Paxos`算法变种。\n\n## 并发\n\n1. [理解`Kotlin`协程：自底向上的视角](kotlin-coroutines-bottom-up/README.md)  \n    `Kotlin`的协程应该是`Java`生态中最好的协程实现，在生产环境（`Android` / 后端场景）也有比较多实际应用。\n    无论是`Kotlin`语言还是`Kotlin`协程，都非常注重务实与开发者友好，`Kotlin`协程以大家习惯的命令式/过程式的编程方式写出非阻塞的高效并发程序。\n    但并发编程是计算机最复杂的主题之一，即使是用协程的编写方式；再者`Kotlin`协程的友好使用方式，对于使用者理解协程背后的运行机制其实反而是个障碍。而真正的理解协程才能让使用协程做到心中有数避免踩坑。这篇文章自底向上视角的讲解方式，正是有意于正面解决这个问题：如何有效理解`Kotlin`协程的运行机制。\n1. [`Java` `Fork/Join`框架](a-java-fork-join-framework/README.md)  \n    _Doug Lea_ 大神关于`Java 7`引入的他写的`Fork/Join`框架的论文。[反应式编程](https://www.reactivemanifesto.org/zh-CN)（`Reactive Programming`/`RP`）作为一种范式在整个业界正在逐步受到认可和落地，是对过往系统的业务需求理解梳理之后对系统技术设计/架构模式的提升总结。`Java`作为一个成熟平台，对于趋势一向有着稳健的接纳和跟进能力，有着令人惊叹的生命活力：`Java 7`提供了`ForkJoinPool`，支持了`Java 8`提供的`Stream`，另外`Java 8`还提供了`Lambda`（有效地表达和使用`RP`需要`FP`的语言构件和理念）；有了前面的这些稳健但不失时机的准备，在`Java 9`中提供了面向`RP`的官方[`Flow API`](https://community.oracle.com/docs/DOC-1006738)，实际上是直接把[`Reactive Streams`](http://www.reactive-streams.org/)的接口加在`Java`标准库中，即[`Reactive Streams`规范](https://github.com/reactive-streams/reactive-streams-jvm#specification)转正了。`Reactive Streams`是`RP`的基础核心组件，`Java`提供了`Flow API` 标志着 `RP`完成了由 **集市**式的自由探索阶段 向 **教堂**式的规范统一阶段 的转变。通过上面这些说明，可以看到`ForkJoinPool`的基础重要性。\n\n## `FP`/`Clojure`/`Lisp`\n\n1. [务实的函数式编程（by Bob大叔）](pragmatic-functional-programming/README.md)  \n    `Bob`大叔的短文，`FP`在软件开发优点上务实的思考，引导大家理解、学习和使用`FP`，文章后半篇还用`FP`语言`Clojure`简约演示了一番。在文末不忘呼吁学习`FP`，并推荐`Clojure`语言。\n1. [手把手介绍函数式编程：从命令式重构到函数式](a-practical-introduction-to-functional-programming/README.md)  \n    本文是一篇手把手的函数式编程入门介绍，借助代码示例讲解细腻。但又不乏洞见，第一节中列举和点评了函数式种种让眼花缭乱特质，给出了『理解函数式特质的指南针：函数式代码的核心特质就一条，**无副作用**』，相信对于有积极学过挖过的函数式同学看来更是有相知恨晚的感觉。希望看了这篇文章之后能在学习和使用函数式编程的旅途中不再迷路哦，兄die～\n1. [**_Successful Lisp_** 中的`Lisp`书籍推荐](recommend-lisp-books/suggestions4further-reading-in-successful-lisp.md)\n    - [`Lisp`书籍推荐和点评](recommend-lisp-books/README.md)，由于`Lisp`与其它语言从**基本概念**就开始的差异，已有的语言经验反而是个学习阻碍，深入浅出的巧妙讲解对入门太重要了。\n    - 特别提这篇好文[【转】学习`Lisp`的书籍推荐](recommend-lisp-books/recommend-lisp-books.md)\n\n## `Git`\n\n1. [`Git`工作流指南](git-workflows-and-tutorials/README.md)  \n    关于`Git`工作流主题，也许这是目前最全面最深入的说明。这篇指南以大家在`SVN`中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的`Pull Request`功能，体系地讲解了各种工作流的应用。行文中实践原则和操作示例并重，对于`Git`的资深玩家可以梳理思考提升，而新接触的同学，也可以跟着step-by-step操练学习并在实际工作中上手使用。\n1. [`Git` `2.1`有哪些新特性？](whats-new-git-2-1/README.md)\n\n## `Erlang`/`Elixir`\n\n1. [`Erlang`之父学习`Elixir`语言的一周](a-week-with-elixir/README.md)  \n    作为`Erlang`之父 _Joe Armstrong_，对`Erlang VM`上的新语言`Elixir`做了很精彩的评论和思考。『特定领域专家的专业直觉』、『编程语言设计的三定律』、『管道操作符避免恶心代码』、『`Elixir`的`sigil`引出的程序语言如何定义/解释字符串』等等问题的讨论，个性鲜明又幽默诙谐的行文风格，都能强烈感受到 _Joe Armstrong_ 深入广博的老黑客风范。\n\n## `Java`\n\n1. [关于`Java`你可能不知道的10件事](10-things-you-didnt-know-about-java/README.md)  \n    作者是个`Java`老鸟，行文风趣幽默，娓娓道出`Java`的诡异和难点时不忘着给出用心良苦的提点。\n\n## 软件测试\n\n1. [`Stubs`和`Mocks`的区别](stubs-vs-mocks/README.md)  \n    翻译自《Programming Groovy》，讲得言简意赅。\n\n## 其它\n\n1. [如何用`Linux`命令行管理网络：11个你必须知道的命令](how-to-work-with-network-from-linux-terminal/README.md)\n1. [为什么`Android`手机会越用越慢，如何提速？](why-android-phones-slow-down-over-time-and-how-to-speed-them-up/README.md)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foldratlee%2Ftranslations","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Foldratlee%2Ftranslations","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foldratlee%2Ftranslations/lists"}