diff --git a/10-things-you-didnt-know-about-java/README.md b/10-things-you-didnt-know-about-java/README.md index 48cc5e9..824763c 100644 --- a/10-things-you-didnt-know-about-java/README.md +++ b/10-things-you-didnt-know-about-java/README.md @@ -87,7 +87,7 @@ class Test { abstract class Parent { abstract T x(); } - + class Child extends Parent { @Override String x() { return "abc"; } @@ -465,7 +465,7 @@ class Test { } ``` -一个很难的问题，[`Ross Tate `](http://www.cs.cornell.edu/~ross/)回答过。答案实际上是不确定的： +一个很难的问题，[`Ross Tate`](http://www.cs.cornell.edu/~ross/)回答过。答案实际上是不确定的： **_`C`是`Type`的子类吗？_** diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6e39b77..fcdfd34 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,7 @@ 欢迎贡献 ==================== -- :see_no_evil: [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 :clap: +- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 👏 - 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new) - 指正，[`Fork`后提通过`Pull Requst`贡献修改](https://github.com/oldratlee/translations/fork) - 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随意:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起学习交流讨论！ @@ -52,7 +52,7 @@ int main(int argc, char *argv[]) HEAD 1 ===================== - + HEAD 2 --------------------- @@ -64,7 +64,7 @@ int main(int argc, char *argv[]) And then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match.” - + — Bill Bryson 因为在`Markdown`换行是不分段的（通过空行分段），所以不影响显示效果。上面内容显示效果如下： diff --git a/README.md b/README.md index 88a14fd..269c26b 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ Chinese translations for classic IT resources. 遵循原则：『信』为本、力求『达』、不妄追『雅』。 \# 信：译文忠实表达作者思想；达：让读者轻松地阅读；雅：让读者愉悦地阅读。详见[信达雅 - 百度百科](http://baike.baidu.com/view/645992.htm)。 -- :see_no_evil: [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 :clap: +- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 👏 - 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new) - 指正，[`Fork`后提通过`Pull Requst`贡献修改](https://github.com/oldratlee/translations/fork) - 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随意:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起学习交流讨论！ diff --git a/a-java-fork-join-framework/README.md b/a-java-fork-join-framework/README.md index 75ad48c..2f69351 100644 --- a/a-java-fork-join-framework/README.md +++ b/a-java-fork-join-framework/README.md @@ -4,7 +4,7 @@ # `Java` `Fork/Join`框架 -## :apple: 译序 +## 🍎 译序 _Doug Lea_ 大神关于`Java 7`引入的他写的`Fork/Join`框架的论文。 @@ -19,7 +19,7 @@ _Doug Lea_ 大神关于`Java 7`引入的他写的`Fork/Join`框架的论文。 对了，另外提一下`Java 9`的`Flow API`的`@author`也是 _Doug Lee_ 哦～ PS: -[自己](http://weibo.com/oldratlee)理解粗浅，翻译中肯定会有不少不足和不对之处，欢迎建议（[提交Issue](https://github.com/oldratlee/translations/issues)）和指正（[Fork后提交代码](https://github.com/oldratlee/translations/fork)）！ :two_hearts: +[自己](http://weibo.com/oldratlee)理解粗浅，翻译中肯定会有不少不足和不对之处，欢迎建议（[提交Issue](https://github.com/oldratlee/translations/issues)）和指正（[Fork后提交代码](https://github.com/oldratlee/translations/fork)）！ 💕 ------------------------------------------------------------------------------- @@ -89,7 +89,7 @@ Result solve(Problem problem) { 尽管这种思想已经存在了很长时间了，但是第一个发布的能系统解决这些问题的框架是`Cilk`[5]。`Cilk`和其他轻量级的框架是基于操作系统的基本的线程和进程机制来支持特殊用途的`Fork/Join`程序。这种策略同样适用于`Java`，尽管`Java`线程是基于低级别的操作系统的能力来实现的。创造这样一个轻量级的执行框架的主要优势是能够让`Fork/Join`程序以一种更直观的方式编写，进而能够在各种支持`JVM`的系统上运行。 -![](figure2-0.png) +![figure2-0](figure2-0.png) `FJTask`框架是基于`Cilk`设计的一种演变。其他的类似框架有`Hood`[4]、`Filaments`[8]、`Stackthreads`[10]以及一些依赖于轻量级执行任务的相关系统。所有这些框架都采用和操作系统把线程映射到`CPU`上相同的方式来把任务映射到线程上。只是他们会使用`Fork/Join`程序的简单性、常规性以及一致性来执行这种映射。尽管这些框架都能适应不能形式的并行程序，他们优化了`Fork/Join`的设计： @@ -240,7 +240,7 @@ if (++base < top) ... 下文提到的主要的测试，其测试程序都是运行在`Sun Enterprise 10000`服务器上，该服务器拥有30个`CPU`，操作系统为`Solaris 7`系统，运行`Solaris`商业版`1.2` `JVM`（`2.2.2_05`发布版本的一个早期版本）。同时，`Java`虚拟机的关于线程映射的环境参数选择为『`bound threads`』（译者注：`XX:+UseBoundThreads`，绑定用户级别的线程到内核线程，只与`Solaris`有关），而关于虚拟机的内存参数设置在4.2章节讨论。另外，需要注意的是下文提到的部分测试则是运行在拥有4 `CPU`的`Sun Enterprise 450`服务器上。 -![](figure4-1.png) +![figure4-1](figure4-1.png) 为了降低定时器粒度以及`Java`虚拟机启动因素对测试结果的影响，测试程序都使用了数量巨大的输入参数。而其它一些启动因素我们通过在启动定时器之前先运行初始化任务来进行屏蔽。所得到的测试结果数据，大部分都是在三次测试结果的中间值，然而一些测试数据仅仅来自一次运行结果（包括4.2 \~ 4.4章节很多测试），因此这些测试结果会有噪音表现。 @@ -248,13 +248,13 @@ if (++base < top) ... 通过使用不同数目（1 \~ 30）的工作线程对同一问题集进行测试，用来得到框架的扩展性测试结果。虽然我们无法保证`Java`虚拟机是否总是能够将每一个线程映射到不同的空闲`CPU`上，同时，我们也没有证据来证明这点。有可能映射一个新的线程到`CPU`的延迟会随着线程数目的增加而变大，也可能会随不同的系统以及不同的测试程序而变化。但是，所得到的测试结果的确显示出增加线程的数目确实能够增加使用的`CPU`的数目。 -![](figure4-2.png) +![figure4-2](figure4-2.png) 加速比通常表示为 **_Timen / Time1_**。如上图所示，其中求积分的程序表现出最好的加速比（30个线程的加速比为28.2），表现最差的是矩阵分解程序（30线程是加速比只有15.35） 另一种衡量扩展性的依据是：任务执行率，及执行一个单独任务（这里的任务有可能是递归分解节点任务也可能是根节点任务）所开销的平均时间。下面的数据显示出一次性执行各个程序所得到的任务执行率数据。很明显，单位时间内执行的任务数目应该是固定常量。然而事实上，随着线程数目增加，所得到的数据会表现出轻微的降低，这也表现出其一定的扩展性限制。这里需要说明的是，之所以任务执行率在各个程序上表现的巨大差异，是因其任务粒度的不同造成的。任务执行率最小的程序是`Fib`（菲波那契数列），其阀值设置为13，在30个线程的情况下总共完成了280万个单元任务。 -![](figure4-3.png) +![figure4-3](figure4-3.png) 导致这些程序的任务完成率没有表现为水平直线的因素有四个。其中三个对所有的并发框架来说都是普遍原因，所以，我们就从对`FJTask`框架（相对于`Cilk`等框架）所特有的因素说起，即垃圾回收。 @@ -264,7 +264,7 @@ if (++base < top) ... 这种垃圾回收机制优势的一个典型体现：使用这种垃圾回收机制，四个线程运行的`Fib`程序耗时仅为5.1秒钟，而如果在`Java`虚拟机设置关闭代拷贝回收（这种情况下使用的就是标记清除（`mark−sweep`）垃圾回收机制了），耗时需要9.1秒钟。 -![](figure4-4.png) +![figure4-4](figure4-4.png) 然而，只有内存使用率只有达到一个很高的值的情况下，垃圾回收机制才会成为影响扩展性的一个因素，因为这种情况下，虚拟机必须经常停止其他线程来进行垃圾回收。以下的数据显示出在三种不同的内存设置下（`Java`虚拟机支持通过额外的参数来设置内存参数），加速比所表现出的差异：默认的4M的半空间，64M的半空间，另外根据线程数目按照公式（`2 + 2p`）M设置半空间。使用较小的半空间，在额外线程导致垃圾回收率攀高的情况下，停止其他线程并进行垃圾回收的开销开始影响加封。 @@ -276,7 +276,7 @@ if (++base < top) ... 测试结果显示，内存操作压力的增加会导致加速比的降低，虽然我们无法提供明确的证据来证明这是引起这种表现的唯一原因。但数据的字宽的确是影响程序的性能的。比如，使用一个线程，排序字节`byte`数据需要耗时122.5秒，然而排序`long`数据则需要耗时242.5秒。 -![](figure4-5.png) +![figure4-5](figure4-5.png) ## 4.4 任务同步 @@ -291,7 +291,7 @@ if (++base < top) ... 1. 从其他队列窃取任务的开销要比在自己队列执行`pop`操作的开销大。 1. 在大多数程序中，任务操作操作的是一个共享的数据单元，如果只运行自己部分的任务可以获得更好的局部数据访问。 -![](figure4-6.png) +![figure4-6](figure4-6.png) 如上图所示，在大多数程序中，窃取任务的相对数据都最多维持在很低的百分比。然后其中`LU`和`MM`程序随着线程数目的增加，会在工作负载上产生更大的不平衡性（相对的产生了更多的任务窃取）。通过调整算法我们可以降低这种影响以获得更好的加速比。 @@ -301,7 +301,7 @@ if (++base < top) ... 在加速比的测试中，不同框架在不同程序上所得到的测试结果非常接近，线程数目1 \~ 4，加速比表现在（3.0 \~ 4.0之间）。因此下图也就只聚焦在不同框架表现的不同的绝对性能上，然而因为在多线程方面，所有的框架都是非常快的，大多数的差异更多的是有代码本身的质量，编译器的不同，优化配置项或者设置参数造成的。实际应用中，根据实际需要选择不同的框架以弥补不同框架之间表现的巨大差异。 -![](figure4-7.png) +![figure4-7](figure4-7.png) `FJTask`在处理浮点数组和矩阵的计算上性能表现的比较差。即使`Java`虚拟机性能不断的提升，但是相比于那些`C`和`C++`语言所使用的强大的后端优化器，其竞争力还是不够的。虽然在上面的图表中没有显示，但`FJTask`版本的所有程序都要比那些没有进行编译优化的框架还是运行的快的。以及一些非正式的测试也表明，测试所得的大多数差异都是由于数组边界检查，运行时义务造成的。这也是`Java`虚拟机以及编译器开发者一直以来关注并持续解决的问题。 diff --git a/a-week-with-elixir/README.md b/a-week-with-elixir/README.md index bcd9ccc..df0e9d8 100644 --- a/a-week-with-elixir/README.md +++ b/a-week-with-elixir/README.md @@ -448,7 +448,7 @@ end > 作者上面说到的： > 1.『难怪有上千篇文章来解释它有多简单』； > 2. 用`Lisp`来快速解释引用和反引用，而不能直接去解释。 -> +> > 这是在用调侃的方式表达『真真儿难于解释』。 # 9. 额外的符号 @@ -491,7 +491,7 @@ iex> lc x inlist [1, 2, 3], do : 2*x ```js js> a = 5; 5 -js> f = function(x) { return x+a }; +js> f = function(x) { return x+a }; function (x){return x+a} js> f(10) 15 diff --git a/api-design-principles-from-qt/README.md b/api-design-principles-from-qt/README.md index c42fe40..ded62dd 100644 --- a/api-design-principles-from-qt/README.md +++ b/api-design-principles-from-qt/README.md @@ -4,7 +4,7 @@ # `API`设计原则 - `Qt`官网的设计实践总结 -## :apple: 译序 +## 🍎 译序 `Qt`的设计水准在业界很有口碑，一致、易于掌握和强大的`API`是`Qt`最著名的优点之一。此文既是`Qt`官网上的`API`设计指导准则，也是`Qt`在`API`设计上的实践总结。虽然`Qt`用的是`C++`，但其中设计原则和思考是具有普适性的（如果你对`C++`还不精通，可以忽略与`C++`强相关或是过于细节的部分，仍然可以学习或梳理关于`API`设计最有价值的内容）。整个篇幅中有很多示例，是关于`API`设计一篇难得的好文章。 diff --git a/generic-io-api-in-java-and-api-design/README.md b/generic-io-api-in-java-and-api-design/README.md index 606d390..8b5cb38 100644 --- a/generic-io-api-in-java-and-api-design/README.md +++ b/generic-io-api-in-java-and-api-design/README.md @@ -1,7 +1,7 @@ 原文链接：[A generic input/output API in Java](https://dzone.com/articles/generic-inputoutput-api-java) - _Rickard Öberg_ （PS：[文章原始链路](http://www.jroller.com/rickard/entry/a_generic_input_output_api)已失效） 译文发在：[【译】Java的通用I/O API](http://oldratlee.com/474/tech/java/generic-io-api-in-java-and-api-design.html)，2012-05-11 -### :apple: 译序 +## 🍎 译序 本文给出了一个通用`Java` `IO` `API`设计，并且有`API`的`Demo`代码。 diff --git a/git-workflows-and-tutorials/README.md b/git-workflows-and-tutorials/README.md index 939a999..154e0e6 100644 --- a/git-workflows-and-tutorials/README.md +++ b/git-workflows-and-tutorials/README.md @@ -2,8 +2,7 @@ 译文发在[博乐在线](http://www.jobbole.com/)： [http://blog.jobbole.com/76550/](http://blog.jobbole.com/76843/)，2014-09-14 PS：原文的老链接和标题是[Git Workflows and Tutorials](https://www.atlassian.com/git/workflows)，`atlassian`改地址后换了文章标题，译文保留使用原标题。 -:apple: 译序 ------------------ +## 🍎 译序 关于`Git`工作流主题，也许这是目前最全面最深入的说明。这篇指南以大家在`SVN`中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的`Pull Request`功能，体系地讲解了各种工作流的应用。 如果你`Git`用的还不多，可以从前面的讲的工作流开始操练。操作过程去感受指南的讲解：解决什么问题、如何解决问题，这样理解就深了，也方便活用。 @@ -29,7 +28,7 @@ PS：原文的老链接和标题是[Git Workflows and Tutorials](https://www.atl ---------------- -- :see_no_evil: [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 :clap: +- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 👏 - 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new) - 指正，[`Fork`后提通过`Pull Request`贡献修改](https://github.com/oldratlee/translations/fork) - 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随意:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起交流学习讨论！ @@ -39,13 +38,13 @@ PS：原文的老链接和标题是[Git Workflows and Tutorials](https://www.atl `Git`工作流指南 ====================== -:point_right: 工作流有各式各样的用法，但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队中最常用的几种`Git`工作流让大家可以上手使用。 +👉 工作流有各式各样的用法，但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队中最常用的几种`Git`工作流让大家可以上手使用。 在阅读的过程中请记住，本文中的几种工作流是作为方案指导而不是条例规定。在展示了各种工作流可能的用法后，你可以从不同的工作流中挑选或揉合出一个满足你自己需求的工作流。 ![Git Workflows](images/git_workflow.png) -:beer: 概述 +🍺 概述 --------------------- ### 集中式工作流 diff --git a/git-workflows-and-tutorials/pull-request.md b/git-workflows-and-tutorials/pull-request.md index 90ce88e..c530bfb 100644 --- a/git-workflows-and-tutorials/pull-request.md +++ b/git-workflows-and-tutorials/pull-request.md @@ -19,7 +19,7 @@ `Pull Requests`是`Bitbucket`上方便开发者之间协作的功能。 提供了一个用户友好的`Web`界面，在集成提交的变更到正式项目前可以对变更进行讨论。 -![](images/pull-request-bitbucket.png) +![pull-request-bitbucket](images/pull-request-bitbucket.png) 开发者向团队成员通知功能开发已经完成，`Pull Requests`是最简单的用法。 开发者完成功能开发后，通过`Bitbucket`账号发起一个`Pull Request`。 @@ -29,7 +29,7 @@ 如果变更有任何问题，团队成员反馈在`Pull Request`中，甚至`push`新的提交微调功能。 所有的这些活动都直接跟踪在`Pull Request`中。 -![](images/pull-request-overview.png) +![pull-request-overview](images/pull-request-overview.png) 相比其它的协作模型，这种分享提交的形式有助于打造一个更流畅的工作流。 `SVN`和`Git`都能通过一个简单的脚本收到通知邮件；但是，讨论变更时，开发者通常只能去回复邮件。 @@ -42,12 +42,12 @@ 来`pull`你仓库中一个分支到他的仓库中。这意味着你要提供4个信息以发起`Pull Request`： 源仓库、源分支、目的仓库、目的分支。 -![](images/pull-request-anatomy.png) +![pull-request-anatomy](images/pull-request-anatomy.png) 这几值多数`Bitbucket`都会设置上合适的缺省值。但取决你用的协作工作流，你的团队可能会要指定不同的值。 上图显示了一个`Pull Request`请求合并一个功能分支到正式的`master`分支上，但可以有多种不同的`Pull Request`用法。 -:beer: 工作方式 +🍺 工作方式 --------------------- `Pull Request`可以和[功能分支工作流](workflow-feature-branch.md)、[`Gitflow`工作流](workflow-gitflow.md)或[`Forking`工作流](workflow-forking.md)一起使用。 @@ -67,7 +67,7 @@ 功能分支工作流用一个共享的`Bitbucket`仓库来管理协作，开发者在专门的分支上开发功能。 但不是立即合并到`master`分支上，而是在合并到主代码库之前开发者应该开一个`Pull Request`发起功能的讨论。 -![](images/pull-request-feature-branch.png) +![pull-request-feature-branch](images/pull-request-feature-branch.png) 功能分支工作流只有一个公开的仓库，所以`Pull Request`的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支，`master`分支作为目的分支。 @@ -85,7 +85,7 @@ 在`Gitflow`工作流中使用`Pull Request`让开发者在发布分支或是维护分支上工作时， 可以有个方便的地方对关于发布分支或是维护分支的问题进行交流。 -![](images/gitflow-workflow-pull-request.png) +![gitflow-workflow-pull-request](images/gitflow-workflow-pull-request.png) `Gitflow`工作流中`Pull Request`的使用过程和上一节中完全一致： 当一个功能、发布或是热修复分支需要`Review`时，开发者简单发起一个`Pull Request`， @@ -102,7 +102,7 @@ 在这个工作流，`Pull Request`的通知功能非常有用， 因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。 -![](images/pull-request-forking-workflow-1.png) +![pull-request-forking-workflow-1](images/pull-request-forking-workflow-1.png) 由于各个开发有自己的公开仓库，`Pull Request`的源仓库和目标仓库不是同一个。 源仓库是开发者的公开仓库，源分支是包含了修改的分支。 @@ -113,13 +113,13 @@ 用团队成员的`Bitbucket`仓库作为目标，而不是正式项目的仓库。 然后使用相同的功能分支作为源和目标分支。 -![](images/pull-request-forking-workflow-2.png) +![pull-request-forking-workflow-2](images/pull-request-forking-workflow-2.png) 2个开发者之间可以在`Pull Request`中讨论和开发功能。 完成开发后，他们可以发起另一个`Pull Request`，请求合并功能到正式的`master`分支。 在`Forking`工作流中，这样的灵活性让`Pull Request`成为一个强有力的协作工具。 -:beer: 示例 +🍺 示例 --------------------- 下面的示例演示了`Pull Request`如何在在`Forking`工作流中使用。 @@ -129,18 +129,18 @@ ### 小红`fork`正式项目 -![](images/pull-request-1.png) +![pull-request-1](images/pull-request-1.png) 小红先要`fork`小明的`Bitbucket`仓库，开始项目的开发。她登陆`Bitbucket`，浏览到小明的仓库页面， 点`Fork`按钮。 -![](images/pull-request-2.png) +![pull-request-2](images/pull-request-2.png) 然后为`fork`出来的仓库填写名字和描述，这样小红就有了服务端的项目拷贝了。 ### 小红克隆她的`Bitbucket`仓库 -![](images/pull-request-3.png) +![pull-request-3](images/pull-request-3.png) 下一步，小红克隆自己刚才`fork`出来的`Bitbucket`仓库，以在本机上准备出工作拷贝。命令如下： @@ -152,7 +152,7 @@ git clone https://user@bitbucket.org/user/repo.git ### 小红开发新功能 -![](images/pull-request-4.png) +![pull-request-4](images/pull-request-4.png) 在开始改代码前，小红要为新功能先新建一个新分支。她会用这个分支作为`Pull Request`的源分支。 @@ -167,7 +167,7 @@ git commit -a -m "Add first draft of some feature" ### 小红`push`功能到她的`Bitbucket`仓库中 -![](images/pull-request-5.png) +![pull-request-5](images/pull-request-5.png) 小红完成了功能后，`push`功能到她自己的`Bitbucket`仓库中（不是正式仓库），用下面简单的命令： @@ -179,7 +179,7 @@ git push origin some-branch ### 小红发起`Pull Request` -![](images/example-6.png) +![example-6](images/example-6.png) `Bitbucket`上有了她的功能分支后，小红可以用她的`Bitbucket`账号浏览到她的`fork`出来的仓库页面， 点右上角的【`Pull Request`】按钮，发起一个`Pull Request`。 @@ -189,13 +189,13 @@ git push origin some-branch 而目标分支是`master`分支。另外，小红需要提供`Pull Request`的标题和描述信息。 如果需要小明以外的人审核批准代码，她可以把这些人填在【Reviewers】文本框中。 -![](images/pull-request-7.png) +![pull-request-7](images/pull-request-7.png) 创建好了`Pull Request`，通知会通过`Bitbucket`系统消息或邮件（可选）发给小明。 ### 小明review `Pull Request` -![](images/pull-request-8.png) +![pull-request-8](images/pull-request-8.png) 在小明的`Bitbucket`仓库页面的【`Pull Request`】Tab可以看到所有人发起的`Pull Request`。 点击小红的`Pull Request`会显示出`Pull Request`的描述、功能的提交历史和每个变更的差异（`diff`）。 @@ -205,7 +205,7 @@ git push origin some-branch 但如果像这个示例中一样小明发现了在小红的代码中的一个小`Bug`，要小红在合并前修复。 小明可以在整个`Pull Request`上加上评注，或是选择历史中的某个提交加上评注。 -![](images/pull-request-9.png) +![pull-request-9](images/pull-request-9.png) ### 小红补加提交 @@ -219,7 +219,7 @@ git push origin some-branch 最终，小明接受变更，合并功能分支到`master`分支，并关闭`Pull Request`。 至此，功能集成到项目中，其它的项目开发者可以用标准的`git pull`命令`pull`这些变更到自己的本地仓库中。 -:beer: 下一站 +🍺 下一站 ----------------- 到了这里，你应该有了所有需要的工具来集成`Pull Request`到你自己的工作流。 diff --git a/git-workflows-and-tutorials/workflow-centralized.md b/git-workflows-and-tutorials/workflow-centralized.md index d03b48c..b7005df 100644 --- a/git-workflows-and-tutorials/workflow-centralized.md +++ b/git-workflows-and-tutorials/workflow-centralized.md @@ -25,7 +25,7 @@ 其次，`Git`提供了强壮的分支和合并模型。不像`SVN`，`Git`的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。 -:beer: 工作方式 +🍺 工作方式 --------------------- 像`Subversion`一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比`SVN`缺省的开发分支`trunk`，`Git`叫做`master`，所有修改提交到这个分支上。本工作流只用到`master`这一个分支。 @@ -48,7 +48,7 @@ 如果本地修改和上游提交有冲突，`Git`会暂停`rebase`过程，给你手动解决冲突的机会。`Git`解决合并冲突，用和生成提交一样的[`git status`](https://www.atlassian.com/git/tutorials/inspecting-a-repository#git-status)和[`git add`](https://www.atlassian.com/git/tutorials/saving-changes#git-add)命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，`Git`可以很简单中止整个`rebase`操作，重来一次（或者让别人来帮助解决）。 -:beer: 示例 +🍺 示例 --------------------- 让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红，看他们是如何开发自己的功能并提交到中央仓库上的。 @@ -230,7 +230,7 @@ git push # 原因同上 ``` -:beer: 下一站 +🍺 下一站 ----------------- 如你所见，仅使用几个`Git`命令我们就可以模拟出传统`Subversion`开发环境。对于要从`SVN`迁移过来的团队来说这太好了，但没有发挥出`Git`分布式本质的优势。 diff --git a/git-workflows-and-tutorials/workflow-feature-branch.md b/git-workflows-and-tutorials/workflow-feature-branch.md index 777777c..2d8e595 100644 --- a/git-workflows-and-tutorials/workflow-feature-branch.md +++ b/git-workflows-and-tutorials/workflow-feature-branch.md @@ -26,7 +26,7 @@ 另外，如果你在功能开发中有问题卡住了，可以开一个`pull requests`来向同学们征求建议。 这些做法的重点就是，`pull requests`让团队成员之间互相评论工作变成非常方便！ -:beer: 工作方式 +🍺 工作方式 --------------------- 功能分支工作流仍然用中央仓库，并且`master`分支还是代表了正式项目的历史。 @@ -53,7 +53,7 @@ 仓库管理的产品解决方案像[`Bitbucket`](http://bitbucket.org/)或[`Stash`](http://www.atlassian.com/stash)，可以良好地支持`Pull Requests`。可以看看`Stash`的[`Pull Requests`文档](https://confluence.atlassian.com/display/STASH/Using+pull+requests+in+Stash)。 -:beer: 示例 +🍺 示例 --------------------- 下面的示例演示了如何把`Pull Requests`作为`Code Review`的方式，但注意`Pull Requests`可以用于很多其它的目的。 @@ -146,7 +146,7 @@ git push 这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交，因为它像一个新功能和原来代码基线的连通符。 但如果你偏爱线性的提交历史，可以在执行合并时`rebase`新功能到`master`分支的顶部，这样生成一个快进（`fast-forward`）的合并。 -【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:） +【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:） ```bash git checkout marys-feature @@ -167,7 +167,7 @@ git push 通过隔离功能到独立的分支上，每个人都可以自主的工作，当然必要的时候在开发者之间分享变更还是比较繁琐的。 -:beer: 下一站 +🍺 下一站 ----------------- 到了这里，但愿你发现了功能分支可以很直接地在[集中式工作流](workflow-centralized.md)的仅有的`master`分支上完成多功能的开发。 diff --git a/git-workflows-and-tutorials/workflow-forking.md b/git-workflows-and-tutorials/workflow-forking.md index f7f0471..986ef42 100644 --- a/git-workflows-and-tutorials/workflow-forking.md +++ b/git-workflows-and-tutorials/workflow-forking.md @@ -27,7 +27,7 @@ 效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。 也让这个工作流成为开源项目的理想工作流。 -:beer: 工作方式 +🍺 工作方式 --------------------- 和其它的`Git`工作流一样，`Forking`工作流要先有一个公开的正式仓库存储在服务器上。 @@ -58,7 +58,7 @@ 各个开发者应该用分支隔离各个功能，就像在[功能分支工作流](workflow-feature-branch.md)和[`Gitflow`工作流](workflow-gitflow.md)一样。 唯一的区别是这些分支被共享了。在`Forking`工作流中这些分支会被`pull`到另一个开发者的本地仓库中，而在功能分支工作流和`Gitflow`工作流中是直接被`push`到正式仓库中。 -:beer: 示例 +🍺 示例 --------------------- ### 项目维护者初始化正式仓库 @@ -197,7 +197,7 @@ git push origin master git pull upstream master ``` -:beer: 下一站 +🍺 下一站 ----------------- 如果你之前是使用`SVN`，`Forking`工作流可能看起来像是一个激进的范式转换（**_paradigm shift_**）。 diff --git a/git-workflows-and-tutorials/workflow-gitflow.md b/git-workflows-and-tutorials/workflow-gitflow.md index befad94..14151c4 100644 --- a/git-workflows-and-tutorials/workflow-gitflow.md +++ b/git-workflows-and-tutorials/workflow-gitflow.md @@ -25,7 +25,7 @@ 除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。 当然你可以用上功能分支工作流所有的好处：`Pull Requests`、隔离实验性开发和更高效的协作。 -:beer: 工作方式 +🍺 工作方式 --------------------- `Gitflow`工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并`push`分支到要中央仓库中。 @@ -80,7 +80,7 @@ 为`Bug`修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在`master`分支上处理的临时发布。 -:beer: 示例 +🍺 示例 --------------------- 下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。 @@ -217,7 +217,7 @@ git push git branch -d issue-#001 ``` -:beer: 下一站 +🍺 下一站 ----------------- 到了这里，但愿你对[集中式工作流](workflow-centralized.md)、[功能分支工作流](workflow-feature-branch.md)和`Gitflow`工作流已经感觉很舒适了。 diff --git a/gui-and-cli-principles/README.md b/gui-and-cli-principles/README.md index 74188ac..236e780 100644 --- a/gui-and-cli-principles/README.md +++ b/gui-and-cli-principles/README.md @@ -1,7 +1,7 @@ 原文链接：[Subversion UI Shootout](http://onlamp.com/pub/a/onlamp/2005/03/10/svn_uis.html "Subversion UI Shootout")，2005-03-10 译文发在：[【译】GUI & CLI Principles](http://oldratlee.com/post/2012-11-04/gui-cli-principles)，2012-11-04 -### :apple: 译序 +### 🍎 译序 文章[Subversion UI Shootout](http://onlamp.com/pub/a/onlamp/2005/03/10/svn_uis.html "Subversion UI Shootout")比较了多个`GUI` `SVN`工具以及命令行的优劣。 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 9c684a5..429e0dd 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 @@ -77,7 +77,7 @@ 对于这一领域，我将持续关注，如果您知道一些我遗漏的内容，请您告知。 -最后我留给你的信息是这个： :smile_cat: +最后我留给你的信息是这个： 😸 [![The Log Song - Ren & Stimpy (Deadwood HoN)](images/log_song.png)](https://www.youtube.com/watch?v=2C7mNr5WMjA) ----------------- diff --git a/python-philosophy/README.md b/python-philosophy/README.md index 253bf73..cf09fe2 100644 --- a/python-philosophy/README.md +++ b/python-philosophy/README.md @@ -71,7 +71,7 @@ PS： 核心复杂度的说明讨论可以参见[《代码大全》](http://book **_[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_](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: +在这里作者[_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`开发的傲娇，不是吗？ 😁 **_[6] [7]_** 关于『Now/现在』、『never/决不』、『right now/马上』，个人理解，这个条目要说的是： @@ -79,7 +79,7 @@ PS： 核心复杂度的说明讨论可以参见[《代码大全》](http://book 否则结果会是： -- 『马上』做 是 『世界上最不能相信』的话 :smile: ，想想饭店服务员的话『您要的菜马上就好』，其实你自己知道后面往往就不会去做这个功能了。 +- 『马上』做 是 『世界上最不能相信』的话 😄 ，想想饭店服务员的话『您要的菜马上就好』，其实你自己知道后面往往就不会去做这个功能了。 更多『世界上最不能相信』的话参见[世界上最不能相信的几句话](http://blog.renren.com/share/339618932/7590788371)。 - 『马上』做 === 不经过思考的不做，结果系统没有做一个本该这个系统做的功能！然后这个功能在不合适的地方被实现，即系统设计有问题。 diff --git a/recommend-lisp-books/recommend-lisp-books.md b/recommend-lisp-books/recommend-lisp-books.md index db837f4..591f258 100644 --- a/recommend-lisp-books/recommend-lisp-books.md +++ b/recommend-lisp-books/recommend-lisp-books.md @@ -1,4 +1,4 @@ -原文链接：[推荐学习LISP的书籍](http://blog.sina.com.cn/s/blog_72d43af30100pg5t.html) - [图谱实验室](http://blog.sina.com.cn/tupulab)，2011-02-01 21:10:14 +原文链接：[推荐学习LISP的书籍](http://blog.sina.com.cn/s/blog_72d43af30100pg5t.html) - [图谱实验室](http://blog.sina.com.cn/tupulab)，2011-02-01 21:10:14 diff --git a/whats-new-git-2-1/README.md b/whats-new-git-2-1/README.md index 9a1b58b..f7f47e3 100644 --- a/whats-new-git-2-1/README.md +++ b/whats-new-git-2-1/README.md @@ -84,7 +84,7 @@ issues = "!f() { : git log ; echo 'Printing issue keys'; git log --oneline $@ | > > 当从子目录运行时，命令输出的路径通常相对于当前目录。这个选项强制输出的路径是相对项目的顶级目录。 -非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行`git grep`找出一个文件的路径，拷贝粘贴到一个`XML`文件中（这样的做法可能出卖了我是个`Java`开发 :grin:）。如果你也觉得有用，只要简单运行： +非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行`git grep`找出一个文件的路径，拷贝粘贴到一个`XML`文件中（这样的做法可能出卖了我是个`Java`开发 :grin:）。如果你也觉得有用，只要简单运行： ```bash $ git config --global grep.fullname true @@ -115,7 +115,7 @@ $ git replace --edit master $ git replace --edit master:jira-components/pom.xml ``` -应该这么做？基本上不会 :smile: 大部分情况应该用`git rebase`重写对象，这样会正确的重写提交的`SHA`，保证历史是健全的（`sane history`）。 +应该这么做？基本上不会 😄 大部分情况应该用`git rebase`重写对象，这样会正确的重写提交的`SHA`，保证历史是健全的（`sane history`）。 > `git replace`会读取`--graft`选项，可以编辑父提交。