From eb225ead402007dec09fcf1891330b2ba102a673 Mon Sep 17 00:00:00 2001 From: penghuster Date: Fri, 11 Aug 2017 17:34:05 +0800 Subject: [PATCH 01/34] penghuster apply for it --- ...20 An introduction to the Linux boot and startup processes.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sources/tech/20170220 An introduction to the Linux boot and startup processes.md b/sources/tech/20170220 An introduction to the Linux boot and startup processes.md index e6d064f3cd..9b8228f814 100644 --- a/sources/tech/20170220 An introduction to the Linux boot and startup processes.md +++ b/sources/tech/20170220 An introduction to the Linux boot and startup processes.md @@ -1,3 +1,4 @@ +penghuster is translating An introduction to the Linux boot and startup processes ============================================================ From d6501cf086816a02fe9a73d854f0061925145a0a Mon Sep 17 00:00:00 2001 From: wxy Date: Sat, 12 Aug 2017 18:33:48 +0800 Subject: [PATCH 02/34] PRF:20161202 Reactive programming vs. Reactive systems.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit @XLCYun 这篇太专业了，辛苦你了！ --- ...active programming vs. Reactive systems.md | 88 +++++++++---------- 1 file changed, 43 insertions(+), 45 deletions(-) diff --git a/translated/talk/20161202 Reactive programming vs. Reactive systems.md b/translated/talk/20161202 Reactive programming vs. Reactive systems.md index 210c7e3e46..10e59680a9 100644 --- a/translated/talk/20161202 Reactive programming vs. Reactive systems.md +++ b/translated/talk/20161202 Reactive programming vs. Reactive systems.md @@ -1,20 +1,20 @@ -响应式编程vs.响应式系统 +响应式编程与响应式系统 ============================================================ ->在恒久的迷惑与过多期待的海洋中，登上一组简单响应式设计原则的小岛。 +> 在恒久的迷惑与过多期待的海洋中，登上一组简单响应式设计原则的小岛。 -> ![Micro Fireworks](https://d3tdunqjn7n0wj.cloudfront.net/360x240/micro_fireworks-db2d0a45f22f348719b393dd98ebefa2.jpg) -下载 Konrad Malawski 的免费电子书[《为什么选择响应式？企业应用中的基本原则》][5]，深入了解更多响应式技术的知识与好处。 +> 下载 Konrad Malawski 的免费电子书[《为什么选择响应式？企业应用中的基本原则》][5]，深入了解更多响应式技术的知识与好处。 -自从2013年一起合作写了[《响应式宣言》][23]之后，我们看着响应式从一种几乎无人知晓的软件构建技术——当时只有少数几个公司的边缘项目使用了这一技术——最后成为中间件领域(middleware field)大佬们全平台战略中的一部分。本文旨在定义和澄清响应式各个方面的概念，方法是比较在_响应式编程_风格下，以及把_响应式系统_视作一个紧密整体的设计方法下写代码的不同。 +自从 2013 年一起合作写了[《响应式宣言》][23]之后，我们看着响应式从一种几乎无人知晓的软件构建技术——当时只有少数几个公司的边缘项目使用了这一技术——最后成为中间件领域middleware field大佬们全平台战略中的一部分。本文旨在定义和澄清响应式各个方面的概念，方法是比较在_响应式编程_风格下和把_响应式系统_视作一个紧密整体的设计方法下编写代码的不同之处。 ### 响应式是一组设计原则 -响应式技术目前成功的标志之一是“响应式”成为了一个热词，并且跟一些不同的事物与人联系在了一起——常常伴随着像“流(streaming)”,“轻量级(lightweight)”和“实时(real-time)”这样的词。 -举个例子：当我们看到一支运动队时（像棒球队或者篮球队），我们一般会把他们看成一个个单独个体的组合，但是当他们之间碰撞不出火花，无法像一个团队一样高效地协作时，他们就会输给一个“更差劲”的队伍。从这篇文章的角度来看，响应式是一组设计原则，一种关于系统架构与设计的思考方式，一种关于在一个分布式环境下，当实现技术(implementation techniques)，工具和设计模式都只是一个更大系统的一部分时如何设计的思考方式。 +响应式技术目前成功的标志之一是“响应式reactive”成为了一个热词，并且跟一些不同的事物与人联系在了一起——常常伴随着像“流streaming”、“轻量级lightweight”和“实时real-time”这样的词。 + +举个例子：当我们看到一支运动队时（像棒球队或者篮球队），我们一般会把他们看成一个个单独个体的组合，但是当他们之间碰撞不出火花，无法像一个团队一样高效地协作时，他们就会输给一个“更差劲”的队伍。从这篇文章的角度来看，响应式是一组设计原则，一种关于系统架构与设计的思考方式，一种关于在一个分布式环境下，当实现技术(implementation techniques)、工具和设计模式都只是一个更大系统的一部分时如何设计的思考方式。 这个例子展示了不经考虑地将一堆软件拼揍在一起——尽管单独来看，这些软件都很优秀——和响应式系统之间的不同。在一个响应式系统中，正是_不同组件(parts)间的相互作用_让响应式系统如此不同，它使得不同组件能够独立地运作，同时又一致协作从而达到最终想要的结果。 @@ -28,62 +28,64 @@ _一个响应式系统_ 是一种架构风格(architectural style)，它允许 * 响应式编程（基于声明的事件的） * 函数响应式编程（FRP） -我们将检查这些做法与技术的意思，特别是前两个。更明确地说，我们会在使用它们的时候讨论它们，例如它们是怎么联系在一起的，从它们身上又能到什么样的好处——特别是在为多核、云或移动架构搭建系统的情境下。 +我们将调查这些做法与技术的意思，特别是前两个。更明确地说，我们会在使用它们的时候讨论它们，例如它们是怎么联系在一起的，从它们身上又能到什么样的好处——特别是在为多核、云或移动架构搭建系统的情境下。 让我们先来说一说函数响应式编程吧，以及我们在本文后面不再讨论它的原因。 ### 函数响应式编程（FRP） -_函数响应式编程_，通常被称作_FRP_，是最常被误解的。FRP在二十年前就被Conal Elliott[精确地定义][24]了。但是最近这个术语却被错误地用来描述一些像Elm，Bacon.js的技术以及其它技术中的响应式插件（RxJava, Rx.NET, RxJS）。许多的库(libraries)声称他们支持FRP，事实上他们说的并非_响应式编程_，因此我们不会再进一步讨论它们。 +函数响应式编程Functional reactive programming，通常被称作_FRP_，是最常被误解的。FRP在二十年前就被 Conal Elliott [精确地定义过了][24]了。但是最近这个术语却被错误地^脚注1 用来描述一些像 Elm、Bacon.js 的技术以及其它技术中的响应式插件（RxJava、Rx.NET、 RxJS）。许多的库(libraries)声称他们支持 FRP，事实上他们说的并非_响应式编程_，因此我们不会再进一步讨论它们。 ### 响应式编程 -_响应式编程_，不要把它跟_函数响应式编程_混淆了，它是异步编程下的一个子集，也是一种范式，在这种范式下，由新信息的有效性(availability)推动逻辑的前进，而不是让一条执行线程(a thread-of-execution)去推动控制流(control flow)。 +响应式编程Reactive programming，不要把它跟_函数响应式编程_混淆了，它是异步编程下的一个子集，也是一种范式，在这种范式下，由新信息的有效性(availability)推动逻辑的前进，而不是让一条执行线程(a thread-of-execution)去推动控制流(control flow)。 它能够把问题分解为多个独立的步骤，这些独立的步骤可以以异步且非阻塞(non-blocking)的方式被执行，最后再组合在一起产生一条工作流(workflow)——它的输入和输出可能是非绑定的(unbounded)。 -[“异步地(Asynchronous)”][25]被牛津词典定义为“不在同一时刻存在或发生”，在我们的语境下，它意味着一条消息或者一个事件可发生在任何时刻，有可能是在未来。这在响应式编程中是非常重要的一项技术，因为响应式编程允许[非阻塞式(non-blocking)]的执行方式——执行线程在竞争一块共享资源时不会因为阻塞(blocking)而陷入等待（防止执行线程在当前的工作完成之前执行任何其它操作），而是在共享资源被占用的期间转而去做其它工作。阿姆达尔定律(Amdahl's Law)[2][9]告诉我们，竞争是可伸缩性(scalability)最大的敌人，所以一个响应式系统应当在极少数的情况下才不得不做阻塞工作。 +[“异步地(Asynchronous)”][25]被牛津词典定义为“不在同一时刻存在或发生”，在我们的语境下，它意味着一条消息或者一个事件可发生在任何时刻，也有可能是在未来。这在响应式编程中是非常重要的一项技术，因为响应式编程允许[非阻塞式(non-blocking)]的执行方式——执行线程在竞争一块共享资源时不会因为阻塞(blocking)而陷入等待（为了防止执行线程在当前的工作完成之前执行任何其它操作），而是在共享资源被占用的期间转而去做其它工作。阿姆达尔定律(Amdahl's Law) ^脚注2 告诉我们，竞争是可伸缩性(scalability)最大的敌人，所以一个响应式系统应当在极少数的情况下才不得不做阻塞工作。 响应式编程一般是_事件驱动(event-driven)_ ，相比之下，响应式系统则是_消息驱动(message-driven)_ 的——事件驱动与消息驱动之间的差别会在文章后面阐明。 响应式编程库的应用程序接口（API）一般是以下二者之一： * 基于回调的（Callback-based)——匿名的间接作用(side-effecting)回调函数被绑定在事件源(event sources)上，当事件被放入数据流(dataflow chain)中时，回调函数被调用。 -* 声明式的（Declarative)——通过函数的组合，通常是使用一些固定的函数，像 _map_, _filter_, _fold_ 等等。 +* 声明式的（Declarative)——通过函数的组合，通常是使用一些固定的函数，像 _map_、 _filter_、 _fold_ 等等。 -大部分的库会混合这两种风格，一般还带有基于流(stream-based)的操作符(operators)，像windowing, counts, triggers。 +大部分的库会混合这两种风格，一般还带有基于流(stream-based)的操作符(operators)，像 windowing、 counts、 triggers。 说响应式编程跟[数据流编程(dataflow programming)][27]有关是很合理的，因为它强调的是_数据流_而不是_控制流_。 举几个为这种编程技术提供支持的的编程抽象概念： * [Futures/Promises][10]——一个值的容器，具有读共享/写独占（many-read/single-write)的语义，即使变量尚不可用也能够添加异步的值转换操作。 -* 流(streams)-[响应式流][11]——无限制的数据处理流，支持异步，非阻塞式，支持多个源与目的的反压转换管道(back-pressured transformation pipelines)。 -* [数据流变量][12]——依赖于输入，过程(procedures)或者其它单元的单赋值变量(存储单元)(single assignment variables)，它能够自动更新值的改变。其中一个应用例子是表格软件——一个单元的值的改变会像涟漪一样荡开，影响到所有依赖于它的函数，顺流而下地使它们产生新的值。 +* 流(streams) - [响应式流][11]——无限制的数据处理流，支持异步，非阻塞式，支持多个源与目的的反压转换管道(back-pressured transformation pipelines)。 +* [数据流变量][12]——依赖于输入、过程(procedures)或者其它单元的单赋值变量(single assignment variables)（存储单元），它能够自动更新值的改变。其中一个应用例子是表格软件——一个单元的值的改变会像涟漪一样荡开，影响到所有依赖于它的函数，顺流而下地使它们产生新的值。 -在JVM中，支持响应式编程的流行库有Akka Streams、Ratpack、Reactor、RxJava和Vert.x等等。这些库实现了响应式编程的规范，成为JVM上响应式编程库之间的互通标准(standard for interoperability)，并且根据它自身的叙述是“……一个为如何处理非阻塞式反压异步流提供标准的倡议” +在 JVM 中，支持响应式编程的流行库有 Akka Streams、Ratpack、Reactor、RxJava 和 Vert.x 等等。这些库实现了响应式编程的规范，成为 JVM 上响应式编程库之间的互通标准(standard for interoperability)，并且根据它自身的叙述是“……一个为如何处理非阻塞式反压异步流提供标准的倡议”。 -响应式编程的基本好处是：提高多核和多CPU硬件的计算资源利用率；根据阿姆达尔定律以及引申的Günther的通用可伸缩性定律[3][13](Günther’s Universal Scalability Law)，通过减少序列化点(serialization points)来提高性能。 +响应式编程的基本好处是：提高多核和多 CPU 硬件的计算资源利用率；根据阿姆达尔定律以及引申的 Günther 的通用可伸缩性定律(Günther’s Universal Scalability Law) ^脚注3 ，通过减少序列化点(serialization points)来提高性能。 -另一个好处是开发者生产效率，传统的编程范式都尽力想提供一个简单直接的可持续的方法来处理异步非阻塞式计算和I/O。在响应式编程中，因活动(active)组件之间通常不需要明确的协作，从而也就解决了其中大部分的挑战。 +另一个好处是开发者生产效率，传统的编程范式都尽力想提供一个简单直接的可持续的方法来处理异步非阻塞式计算和 I/O。在响应式编程中，因活动(active)组件之间通常不需要明确的协作，从而也就解决了其中大部分的挑战。 -响应式编程真正的发光点在于组件的创建跟工作流的组合。为了在异步执行上取得最大的优势，把[反压(back-pressure)][28]加进来是很重要，这样能避免过度使用，或者确切地说，无限度的消耗资源。 +响应式编程真正的发光点在于组件的创建跟工作流的组合。为了在异步执行上取得最大的优势，把[反压(back-pressure)][28]加进来是很重要，这样能避免过度使用，或者确切地说，避免无限度的消耗资源。 -尽管如此，响应式编程在搭建现代软件上仍然非常有用，为了在更高层次上理解(reason about)一个系统，那么必须要使用到另一个工具：_响应式架构_——设计响应式系统的方法。此外，要记住编程范式有很多，而响应式编程仅仅只是其中一个，所以如同其它工具一样，响应式编程并不是万金油，它不意图适用于任何情况。 +尽管如此，响应式编程在搭建现代软件上仍然非常有用，为了在更高层次上理解(reason about)一个系统，那么必须要使用到另一个工具：响应式架构reactive architecture——设计响应式系统的方法。此外，要记住编程范式有很多，而响应式编程仅仅只是其中一个，所以如同其它工具一样，响应式编程并不是万金油，它不意图适用于任何情况。 ### 事件驱动 vs. 消息驱动 -如上面提到的，响应式编程——专注于短时间的数据流链条上的计算——因此倾向于_事件驱动_，而响应式系统——关注于通过分布式系统的通信和协作所得到的弹性和韧性——则是[_消息驱动的_][29][4][14]（或者称之为 _消息式(messaging)_ 的）。 + +如上面提到的，响应式编程——专注于短时间的数据流链条上的计算——因此倾向于_事件驱动_，而响应式系统——关注于通过分布式系统的通信和协作所得到的弹性和韧性——则是[_消息驱动的_][29] ^脚注4（或者称之为 _消息式(messaging)_ 的）。 一个拥有长期存活的可寻址(long-lived addressable)组件的消息驱动系统跟一个事件驱动的数据流驱动模型的不同在于，消息具有固定的导向，而事件则没有。消息会有明确的（一个）去向，而事件则只是一段等着被观察(observe)的信息。另外，消息式(messaging)更适用于异步，因为消息的发送与接收和发送者和接收者是分离的。 响应式宣言中的术语表定义了两者之间[概念上的不同][30]： + > 一条消息就是一则被送往一个明确目的地的数据。一个事件则是达到某个给定状态的组件发出的一个信号。在一个消息驱动系统中，可寻址到的接收者等待消息的到来然后响应它，否则保持休眠状态。在一个事件驱动系统中，通知的监听者被绑定到消息源上，这样当消息被发出时它就会被调用。这意味着一个事件驱动系统专注于可寻址的事件源而消息驱动系统专注于可寻址的接收者。 -分布式系统需要通过消息在网络上传输进行交流，以实现其沟通基础，与之相反，事件的发出则是本地的。在底层通过发送包裹着事件的消息来搭建跨网络的事件驱动系统的做法很常见。这样能够维持在分布式环境下事件驱动编程模型的相对简易性并且在某些特殊的和合理范围内的使用案例上工作得很好。 +分布式系统需要通过消息在网络上传输进行交流，以实现其沟通基础，与之相反，事件的发出则是本地的。在底层通过发送包裹着事件的消息来搭建跨网络的事件驱动系统的做法很常见。这样能够维持在分布式环境下事件驱动编程模型的相对简易性，并且在某些特殊的和合理的范围内的使用案例上工作得很好。 -然而，这是有利有弊的：在编程模型的抽象性和简易性上得一分，在控制上就减一分。消息强迫我们去拥抱分布式系统的真实性和一致性——像局部错误(partial failures)，错误侦测(failure detection)，丢弃/复制/重排序 消息（dropped/duplicated/reordered messages)，最后还有一致性，管理多个并发真实性等等——然后直面它们，去处理它们，而不是像过去无数次一样，藏在一个蹩脚的抽象面罩后——假装网络并不存在(例如EJB, [RPC][31], [CORBA][32], 和 [XA][33])。 +然而，这是有利有弊的：在编程模型的抽象性和简易性上得一分，在控制上就减一分。消息强迫我们去拥抱分布式系统的真实性和一致性——像局部错误(partial failures)，错误侦测(failure detection)，丢弃/复制/重排序 （dropped/duplicated/reordered )消息，最后还有一致性，管理多个并发真实性等等——然后直面它们，去处理它们，而不是像过去无数次一样，藏在一个蹩脚的抽象面罩后——假装网络并不存在(例如EJB、 [RPC][31]、 [CORBA][32] 和 [XA][33])。 -这些在语义学和适用性上的不同在应用设计中有着深刻的含义，包括分布式系统的复杂性(complexity)中的 _弹性(resilience)_， _韧性(elasticity)_，_移动性(mobility)_，_位置透明性(location transparency)_ 和 _管理(management)_，这些在文章后面再进行介绍。 +这些在语义学和适用性上的不同在应用设计中有着深刻的含义，包括分布式系统的复杂性(complexity)中的 _弹性(resilience)_、 _韧性(elasticity)_、_移动性(mobility)_、_位置透明性(location transparency)_ 和 _管理(management)_，这些在文章后面再进行介绍。 在一个响应式系统中，特别是使用了响应式编程技术的，这样的系统中就即有事件也有消息——一个是用于沟通的强大工具（消息），而另一个则呈现现实（事件）。 @@ -91,17 +93,17 @@ _响应式编程_，不要把它跟_函数响应式编程_混淆了，它是异 _响应式系统_ —— 如同在《响应式宣言》中定义的那样——是一组用于搭建现代系统——已充分准备好满足如今应用程序所面对的不断增长的需求的现代系统——的架构设计原则。 -响应式系统的原则决对不是什么新东西，它可以被追溯到70和80年代Jim Gray和Pat Helland在[串级系统(Tandem System)][34]上和Joe aomstrong和Robert Virding在[Erland][35]上做出的重大工作。然而，这些人在当时都超越了时代，只有到了最近5-10年，技术行业才被不得不反思当前企业系统最好的开发实践活动并且学习如何将来之不易的响应式原则应用到今天这个多核、云计算和物联网的世界中。 +响应式系统的原则决对不是什么新东西，它可以被追溯到 70 和 80 年代 Jim Gray 和 Pat Helland 在[串级系统(Tandem System)][34] 上和 Joe aomstrong 和 Robert Virding 在 [Erland][35] 上做出的重大工作。然而，这些人在当时都超越了时代，只有到了最近 5 - 10 年，技术行业才被不得不反思当前企业系统最好的开发实践活动并且学习如何将来之不易的响应式原则应用到今天这个多核、云计算和物联网的世界中。 -响应式系统的基石是_消息传递(message-passing)_ ，消息传递为两个组件之间创建一条暂时的边界，使得他们能够在 _时间_ 上分离——实现并发性——和 _空间(space)_ ——实现分布式(distribution)与移动性(mobility)。这种分离是两个组件完全[隔离(isolation)][36]以及实现 _弹性(resilience)_ 和 _韧性(elasticity)_ 基础的必需条件。 +响应式系统的基石是_消息传递(message-passing)_ ，消息传递为两个组件之间创建一条暂时的边界，使得它们能够在 _时间_ 上分离——实现并发性——和 _空间(space)_ ——实现分布式(distribution)与移动性(mobility)。这种分离是两个组件完全[隔离(isolation)][36]以及实现 _弹性(resilience)_ 和 _韧性(elasticity)_ 基础的必需条件。 ### 从程序到系统 -这个世界的连通性正在变得越来越高。我们构建 _程序_ ——为单个操作子计算某些东西的端到端逻辑——已经不如我们构建 _系统_ 来得多了。 +这个世界的连通性正在变得越来越高。我们不再构建 _程序_ ——为单个操作子来计算某些东西的端到端逻辑——而更多地在构建 _系统_ 了。 系统从定义上来说是复杂的——每一部分都包含多个组件，每个组件的自身或其子组件也可以是一个系统——这意味着软件要正常工作已经越来越依赖于其它软件。 -我们今天构建的系统会在多个计算机上被操作，小型的或大型的，数量少的或数量多的，相近的或远隔半个地球的。同时，由于人们的生活正变得越来越依赖于系统顺畅运行的有效性，用户的期望也变得越得越来越难以满足。 +我们今天构建的系统会在多个计算机上操作，小型的或大型的，或少或多，相近的或远隔半个地球的。同时，由于人们的生活正变得越来越依赖于系统顺畅运行的有效性，用户的期望也变得越得越来越难以满足。 为了实现用户——和企业——能够依赖的系统，这些系统必须是 _灵敏的(responsive)_ ，这样无论是某个东西提供了一个正确的响应，还是当需要一个响应时响应无法使用，都不会有影响。为了达到这一点，我们必须保证在错误( _弹性_ )和欠载( _韧性_ )下，系统仍然能够保持灵敏性。为了实现这一点，我们把系统设计为 _消息驱动的_ ，我们称其为 _响应式系统_ 。 @@ -109,36 +111,32 @@ _响应式系统_ —— 如同在《响应式宣言》中定义的那样—— 弹性是与 _错误下_ 的灵敏性(responsiveness)有关的，它是系统内在的功能特性，是需要被设计的东西，而不是能够被动的加入系统中的东西。弹性是大于容错性的——弹性无关于故障退化(graceful degradation)——虽然故障退化对于系统来说是很有用的一种特性——与弹性相关的是与从错误中完全恢复达到 _自愈_ 的能力。这就需要组件的隔离以及组件对错误的包容，以免错误散播到其相邻组件中去——否则，通常会导致灾难性的连锁故障。 -因此构建一个弹性的，自愈(self-healing)系统的关键是允许错误被：容纳，具体化为消息，发送给其他的（担当监管者的(supervisors)）组件，从而在错误组件之外修复出一个安全环境。在这，消息驱动是其促成因素：远离高度耦合的、脆弱的深层嵌套的同步调用链，大家长期要么学会忍受其煎熬或直接忽略。解决的想法是将调用链中的错误管理分离，将客户端从处理服务端错误的责任中解放出来。 +因此构建一个弹性的、自愈(self-healing)系统的关键是允许错误被：容纳、具体化为消息，发送给其他的（担当监管者的(supervisors)）组件，从而在错误组件之外修复出一个安全环境。在这，消息驱动是其促成因素：远离高度耦合的、脆弱的深层嵌套的同步调用链，大家长期要么学会忍受其煎熬或直接忽略。解决的想法是将调用链中的错误管理分离，将客户端从处理服务端错误的责任中解放出来。 ### 响应式系统的韧性 [韧性(Elasticity)][37]是关于 _欠载下的灵敏性(responsiveness)_ 的——意味着一个系统的吞吐量在资源增加或减少时能够自动地相应增加或减少(scales up or down)（同样能够向内或外扩展(scales in or out)）以满足不同的需求。这是利用云计算承诺的特性所必需的因素：使系统利用资源更加有效，成本效益更佳，对环境友好以及实现按次付费。 -系统必须能够在不重写甚至不重新设置的情况下，适应性地——即无需介入自动伸缩——响应状态及行为，沟通负载均衡，故障转移(failover)，以及升级。实现这些的就是 _位置透明性(location transparency)_ ：使用同一个方法，同样的编程抽象，同样的语义，在所有向度中伸缩(scaling)系统的能力——从CPU核心到数据中心。 +系统必须能够在不重写甚至不重新设置的情况下，适应性地——即无需介入自动伸缩——响应状态及行为，沟通负载均衡，故障转移(failover)，以及升级。实现这些的就是 _位置透明性(location transparency)_ ：使用同一个方法，同样的编程抽象，同样的语义，在所有向度中伸缩(scaling)系统的能力——从 CPU 核心到数据中心。 如同《响应式宣言》所述： -> 一个极大地简化问题的关键洞见在于意识到我们都在使用分布式计算。无论我们的操作系统是运行在一个单一结点上（拥有多个独立的CPU，并通过QPI链接进行交流）,还是在一个节点集群(cluster of nodes，独立的机器，通过网络进行交流)上。拥抱这个事实意味着在垂直方向上多核的伸缩与在水平方面上集群的伸缩并无概念上的差异。在空间上的解耦 [...]，是通过异步消息传送以及运行时实例与其引用解耦从而实现的，这就是我们所说的位置透明性。 +> 一个极大地简化问题的关键洞见在于意识到我们都在使用分布式计算。无论我们的操作系统是运行在一个单一结点上（拥有多个独立的 CPU，并通过 QPI 链接进行交流）,还是在一个节点集群(cluster of nodes)（独立的机器，通过网络进行交流)上。拥抱这个事实意味着在垂直方向上多核的伸缩与在水平方面上集群的伸缩并无概念上的差异。在空间上的解耦 [...]，是通过异步消息传送以及运行时实例与其引用解耦从而实现的，这就是我们所说的位置透明性。 因此，不论接收者在哪里，我们都以同样的方式与它交流。唯一能够在语义上等同实现的方式是消息传送。 ### 响应式系统的生产效率 -既然大多数的系统生来即是复杂的，那么其中一个最重要的点即是保证一个系统架构在开发和维护组件时，最小程度地减低生产效率，同时将操作的 _偶发复杂性(accidental complexity_ 降到最低。 +既然大多数的系统生来即是复杂的，那么其中一个最重要的点即是保证一个系统架构在开发和维护组件时，最小程度地减低生产效率，同时将操作的 _偶发复杂性(accidental complexity)_ 降到最低。 这一点很重要，因为在一个系统的生命周期中——如果系统的设计不正确——系统的维护会变得越来越困难，理解、定位和解决问题所需要花费时间和精力会不断地上涨。 响应式系统是我们所知的最具 _生产效率_ 的系统架构（在多核、云及移动架构的背景下）： -* 错误的隔离为组件与组件之间裹上[舱壁][15]（译者注：当船遭到损坏进水时，舱壁能够防止水从损坏的船舱流入其他船舱），防止引发连锁错误，从而限制住错误的波及范围以及严重性。 - +* 错误的隔离为组件与组件之间裹上[舱壁][15]（LCTT 译注：当船遭到损坏进水时，舱壁能够防止水从损坏的船舱流入其他船舱），防止引发连锁错误，从而限制住错误的波及范围以及严重性。 * 监管者的层级制度提供了多个等级的防护，搭配以自我修复能力，避免了许多曾经在侦查(inverstigate)时引发的操作代价(cost)——大量的瞬时故障(transient failures)。 - * 消息传送和位置透明性允许组件被卸载下线、代替或重新布线(rerouted)同时不影响终端用户的使用体验，并降低中断的代价、它们的相对紧迫性以及诊断和修正所需的资源。 - * 复制减少了数据丢失的风险，减轻了数据检索(retrieval)和存储的有效性错误的影响。 - * 韧性允许在使用率波动时保存资源，允许在负载很低时，最小化操作开销，并且允许在负载增加时，最小化运行中断(outgae)或紧急投入(urgent investment)伸缩性的风险。 因此，响应式系统使生成系统(creation systems)很好的应对错误、随时间变化的负载——同时还能保持低运营成本。 @@ -173,19 +171,19 @@ _响应式系统_ —— 如同在《响应式宣言》中定义的那样—— 响应式编程在内部逻辑及数据流转换的组件层次上为开发者提高了生产率——通过性能与资源的有效利用实现。而响应式系统在构建 _原生云(cloud native)_ 和其它大型分布式系统的系统层次上为架构师及DevOps从业者提高了生产率——通过弹性与韧性。我们建议在响应式系统设计原则中结合响应式编程技术。 -``` -1 参考Conal Elliott，FRP的发明者，见[这个演示][16][↩][17] -2 [Amdahl 定律][18]揭示了系统理论上的加速会被一系列的子部件限制，这意味着系统在新的资源加入后会出现收益递减(diminishing returns)。 [↩][19] -3 Neil Günter的[通用可伸缩性定律(Universal Scalability Law)][20]是理解并发与分布式系统的竞争与协作的重要工具，它揭示了当新资源加入到系统中时，保持一致性的开销会导致不好的结果。 -4 消息可以是同步的（要求发送者和接受者同时存在），也可以是异步的（允许他们在时间上解耦）。其语义上的区别超出本文的讨论范围。[↩][22] -``` + +> 1. 参考Conal Elliott，FRP的发明者，见[这个演示][16] +> 2. [Amdahl 定律][18]揭示了系统理论上的加速会被一系列的子部件限制，这意味着系统在新的资源加入后会出现收益递减(diminishing returns)。  +> 3. Neil Günter的[通用可伸缩性定律(Universal Scalability Law)][20]是理解并发与分布式系统的竞争与协作的重要工具，它揭示了当新资源加入到系统中时，保持一致性的开销会导致不好的结果。 +> 4. 消息可以是同步的（要求发送者和接受者同时存在），也可以是异步的（允许他们在时间上解耦）。其语义上的区别超出本文的讨论范围。 + -------------------------------------------------------------------------------- via: https://www.oreilly.com/ideas/reactive-programming-vs-reactive-systems -作者：[Jonas Bonér][a] , [Viktor Klang][b] +作者：[Jonas Bonér][a]， [Viktor Klang][b] 译者：[XLCYun](https://github.com/XLCYun) -校对：[校对者ID](https://github.com/校对者ID) +校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 组织编译，[Linux中国](https://linux.cn/) 荣誉推出 From d1cc8ec63b2ed9baac05145debc91d1f6d529fb1 Mon Sep 17 00:00:00 2001 From: wxy Date: Sat, 12 Aug 2017 18:34:14 +0800 Subject: [PATCH 03/34] PUB:20161202 Reactive programming vs. Reactive systems.md @XLCYun https://linux.cn/article-8773-1.html --- .../20161202 Reactive programming vs. Reactive systems.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {translated/talk => published}/20161202 Reactive programming vs. Reactive systems.md (100%) diff --git a/translated/talk/20161202 Reactive programming vs. Reactive systems.md b/published/20161202 Reactive programming vs. Reactive systems.md similarity index 100% rename from translated/talk/20161202 Reactive programming vs. Reactive systems.md rename to published/20161202 Reactive programming vs. Reactive systems.md From 7a5d21266696b604527fe7442e254cd5d414417e Mon Sep 17 00:00:00 2001 From: Snapcrafter Date: Sun, 13 Aug 2017 12:21:09 +0800 Subject: [PATCH 04/34] [Translated by Snapcraft] 20170628 Build, test, and publish snap packages using snapcraft.md --- ...d publish snap packages using snapcraft.md | 173 ----------------- ...d publish snap packages using snapcraft.md | 174 ++++++++++++++++++ 2 files changed, 174 insertions(+), 173 deletions(-) delete mode 100644 sources/tech/20170628 Build test and publish snap packages using snapcraft.md create mode 100644 translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md diff --git a/sources/tech/20170628 Build test and publish snap packages using snapcraft.md b/sources/tech/20170628 Build test and publish snap packages using snapcraft.md deleted file mode 100644 index 0df0b5db6c..0000000000 --- a/sources/tech/20170628 Build test and publish snap packages using snapcraft.md +++ /dev/null @@ -1,173 +0,0 @@ -【Snaplee准备翻译】Build, test, and publish snap packages using snapcraft -============================================================ - - -### Share or save - - _This is a guest post by Ricardo Feliciano, Developer Evangelist at CircleCI. If you would like to contribute a guest post, please contact ubuntu-iot@canonical.com._ - -Snapcraft, the package management system fighting for its spot at the Linux table, re-imagines how you can deliver your software. A new set of cross-distro tools are available to help you build and publish “Snaps”. We’ll cover how to use CircleCI 2.0 to power this process and some potential gotchas along the way. - -### What are snap packages? And Snapcraft? - -**Snaps** are software packages for Linux distributions. They’re designed with lessons learned from delivering software on mobile platforms such as Android as well Internet of Things devices. **Snapcraft** is the name that encompasses Snaps and the command-line tool that builds them, [the website][9], and pretty much the entire ecosystem around the technologies that enables this. - -Snap packages are designed to isolate and encapsulate an entire application. This concept enables Snapcraft’s goal of increasing security, stability, and portability of software allowing a single “snap” to be installed on not just multiple versions of Ubuntu, but Debian, Fedora, Arch, and more. Snapcraft’s description per their website: - -“Package any app for every Linux desktop, server, cloud or device, and deliver updates directly.” - -### Building a snap package on CircleCI 2.0 - -Building a snap on CircleCI is mostly the same as your local machine, wrapped with [CircleCI 2.0 syntax][10]. We’ll go through a sample config file in this post. If you’re not familiar with CircleCI or would like to know more about getting started with 2.0 specifically, you can start [here][11]. - -### Base Config - -``` -version: 2 -jobs: - build: - machine: true - working_directory: ~/project - steps: - - checkout - - run: - command: | - sudo apt update && sudo apt install -y snapd - sudo snap install snapcraft --edge --classic - /snap/bin/snapcraft - -``` - -This example uses the `machine` executor to install `snapd`, the executable that allows you to manage snaps and enables the platform, as well as `snapcraft`, the tool for creating snaps. - -The `machine` executor is used rather than the `docker` executor as we need a newer kernel for the build process. Linux 4.4 is available here, which is new enough for our purposes. - -### Userspace dependencies - -The example above uses the `machine` executor, which currently is [a VM with Ubuntu 14.04 (Trusty)][12] and the Linux v4.4 kernel. This is fine if your project/snap requires build dependencies available in the Trusty repositories. What if you need dependencies available in a different version, perhaps Ubuntu 16.04 (Xenial)? We can still use Docker within the `machine` executor to build our snap. - -``` -version: 2 -jobs: - build: - machine: true - working_directory: ~/project - steps: - - checkout - - run: - command: | - sudo apt update && sudo apt install -y snapd - docker run -v $(pwd):$(pwd) -t ubuntu:xenial sh -c "apt update -qq && apt install snapcraft -y && cd $(pwd) && snapcraft" - -``` - -In this example, we again install `snapd` in the `machine` executor’s VM, but we decide to install Snapcraft and build our snap within a Docker container built with the Ubuntu Xenial image. All `apt` packages available in Ubuntu 16.04 will be available to `snapcraft` during the build. - -### Testing - -Unit testing your software’s code has been covered extensively in [our blog][13], [our docs][14], and around the Internet. Searching for your language/framework and unit testing or CI will turn up tons of information. Building a snap on CircleCI means we end with a `.snap` file which we can test in addition to the code that created it. - -### Workflows - -Let’s say the snap we built was a webapp. We can build a testing suite to make sure this snap installs and runs correctly. We could try installing the snap. We could run [Selenium][15] to make sure the proper pages load, logins, work, etc. Here’s the catch, snaps are designed to run on multiple Linux distros. That means we need to be able to run this test suite in Ubuntu 16.04, Fedora 25, Debian 9, etc. CircleCI 2.0’s Workflows can efficiently solve this. - -[A recent addition][16] to the CircleCI 2.0 beta is Workflows. This allows us to run discrete jobs in CircleCI with a certain flow logic. In this case, **after** our snap is built, which would be a single job, we could then kick off snap distro testing jobs, running in parallel. One for each distro we want to test. Each of these jobs would be a different [Docker image][17] for that distro (or in the future, additional `executors` will be available). - -Here’s simple example of what this might look like: - -``` -workflows: - version: 2 - build-test-and-deploy: - jobs: - - build - - acceptance_test_xenial: - requires: - - build - - acceptance_test_fedora_25: - requires: - - build - - acceptance_test_arch: - requires: - - build - - publish: - requires: - - acceptance_test_xenial - - acceptance_test_fedora_25 - - acceptance_test_arch - -``` - -This setup builds the snap, and then runs acceptance tests on it with four different distros. If and when all distro builds pass, then we can run the publish `job` in order to finish up any remaining snap task before pushing it to the Snap Store. - -### Persisting the .snap package - -To test our `.snap` package in the workflows example, a way of persisting that file between builds is needed. I’ll mention two ways here. - -1. **artifacts** – We could store the snap package as a CircleCI artifact during the `build`job. Then retrieve it within the following jobs. CircleCI Workflows has its own way of of handling sharing artifacts which can be found [here][1]. - -2. **snap store channels** – When publishing a snap to the Snap Store, there’s more than one `channel` to choose from. It’s becoming a common practice to publish the master branch of your snap to the `edge` channel for internal and/or user testing. This can be done in the `build` job, with the following jobs installing the snap from the edge channel. - -The first method is faster to complete and has the advantage of being able to run acceptance tests on your snap before it hits the Snap Store and touches any user, even testing users. The second method has the advantage of install from the Snap Store being one of the test that is run during CI. - -### Authenticating with the snap store - -The script [snapcraft-config-generator.py][18] can generate the store credentials and save them to `.snapcraft/snapcraft.cfg` (note: always inspect public scripts before running them). You don’t want to store this file in plaintext in your repo (for security reasons). You can either base64 encode the file and store it as a [private environment variable][19] or you can [encrypt the file][20] and just store the key in a private environment variable. - -Here’s an example of having the store credentials in an encrypted file, and using the creds in a `deploy` step to publish to the Snap Store: - -``` -- deploy: - name: Push to Snap Store - command: | - openssl aes-256-cbc -d -in .snapcraft/snapcraft.encrypted -out .snapcraft/snapcraft.cfg -k $KEY - /snap/bin/snapcraft push *.snap - -``` - -Instead of a deploy step, keeping with the Workflow examples from earlier, this could be a deploy job that only runs when and if the acceptance test jobs passed. - -### More information - -* Alan Pope’s [Forum Post][2]: “popey” is a Canonical employee and wrote the post in [Snapcraft’s Forum][3] that inspired this blog post - -* [Snapcraft Website][4]: the official Snapcraft website - -* [Snapcraft’s CircleCI Bug Report][5]: There is an open bug report on Launchpad to add support for CircleCI to Snapcraft. This will make this process a little easier and more “official”. Please add your support. - -* How the [Nextcloud][6] snap is being built with CircleCI: a great blog post called [“Continuous acceptance tests for complex applications”][7]. Also influenced this blog post. - -Original post [here][21] - --------------------------------------------------------------------------------- - -via: https://insights.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages-using-snapcraft/ - -作者：[ Guest ][a] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://insights.ubuntu.com/author/guest/ -[1]:https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-artifacts-among-jobs -[2]:https://forum.snapcraft.io/t/building-and-pushing-snaps-using-circleci/789 -[3]:https://forum.snapcraft.io/ -[4]:https://snapcraft.io/ -[5]:https://bugs.launchpad.net/snapcraft/+bug/1693451 -[6]:https://nextcloud.com/ -[7]:https://kyrofa.com/posts/continuous-acceptance-tests-for-complex-applications -[8]:https://insights.ubuntu.com/author/guest/ -[9]:https://snapcraft.io/ -[10]:https://circleci.com/docs/2.0/ -[11]:https://circleci.com/docs/2.0/first-steps/ -[12]:https://circleci.com/docs/1.0/differences-between-trusty-and-precise/ -[13]:https://circleci.com/blog/ -[14]:https://circleci.com/docs/ -[15]:http://www.seleniumhq.org/ -[16]:https://circleci.com/blog/introducing-workflows-on-circleci-2-0/ -[17]:https://circleci.com/docs/2.0/building-docker-images/ -[18]:https://gist.github.com/3v1n0/479ad142eccdd17ad7d0445762dea755 -[19]:https://circleci.com/docs/1.0/environment-variables/#setting-environment-variables-for-all-commands-without-adding-them-to-git -[20]:https://github.com/circleci/encrypted-files -[21]:https://circleci.com/blog/build-test-publish-snap-packages?utm_source=insightsubuntu&utm_medium=syndicatedblogpost diff --git a/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md b/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md new file mode 100644 index 0000000000..5d66be2665 --- /dev/null +++ b/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md @@ -0,0 +1,174 @@ +# 使用 Snapcraft 构建、测试并发布 Snaps + +标签（空格分隔）： snapcraft Snaps CircleCI + +--- + +这篇客座文章的作者是 Ricardo Feliciano —— CircleCi 的开发者传道士。如果您也有兴趣投稿，请联系 ubuntu-iot@canonical.com。 + +`Snapcraft` 是一个正在为其在 Linux 中的位置而奋斗的包管理系统，它为你重新想象了分发软件的方式。你可以使用一系列新的跨版本工具来构建和发布 `Snaps`。接下来我们将会讲述怎么使用 `CircleCI 2.0` 来加速这个过程 +以及一些在这个过程中的可能遇到的问题。 + +### Snaps 是什么？Snapcraft 又是什么？ + +`Snaps` 是用于 Linux 发行版的软件包，它们在设计的时候吸取了在移动平台，比如 Android 以及物联网设备，分发软件的经验教训。`Snapcraft` 这个名字涵盖了 Snaps 和用来构建它们的命令行工具，[snapcraft.io][1]，以及在这些技术的支撑下构建的几乎整个生态系统。 + +Snaps 被设计成用来隔离并封装整个应用程序。这些概念使得 Snapcraft 提高软件安全性、稳定性和可移植性的目标得以实现，其中可移植性允许单个 `snap` 包不仅可以在 Ubuntu 的多个版本中安装，而且也可以在 Debian、Fedora 和 Arch 等发行版中安装。Snapcraft 网站对其的描述如下： +> 为每个 Linux 桌面、服务器、云或设备打包任何应用程序，并且直接交付更新。 + +### 在 CircleCI 2.0 上构建 Snaps + +在 CircleCI 上使用 [CircleCI 2.0 语法][2] 来构建 Snaps 和在本地机器上基本相同。在本文中，我们将会讲解一个示例配置文件。如果您对 CircleCI 还不熟悉，或者想了解更多有关 2.0 的入门知识，您可以从 [这里][3] 开始。 + +### 基础配置 +``` +version: 2 +jobs: + build: + machine: true + working_directory: ~/project + steps: + - checkout + - run: + command: | + sudo apt update && sudo apt install -y snapd + sudo snap install snapcraft --edge --classic + /snap/bin/snapcraft +``` + +这个例子使用了 `machine` 执行器来安装用于管理运行 Snaps 的 `snapd` 和制作 Snaps 的 `Snapcraft`。 + +由于构建过程需要使用比较新的内核，所以我们使用了 `machine` 执行器而没有用 `docker` 执行器。在这里，Linux v4.4 已经足够满足我们的需求了。 + +### 用户空间的依赖关系 + +上面的例子使用了 `machine` 执行器，它实际上是一个内核为 Linux v4.4 的 [Ubuntu 14.04 (Trusty) 虚拟机][4]。你的 project/snap 可以很方便的使用 Trusty 仓库来构建依赖关系。如果需要构建其他版本的依赖关系，比如 Ubuntu 16.04 (Xenial)，我们仍然可以在 `machine` 执行器中使用 `Docker` 来构建我们的 Snaps 。 + +``` +version: 2 +jobs: + build: + machine: true + working_directory: ~/project + steps: + - checkout + - run: + command: | + sudo apt update && sudo apt install -y snapd + docker run -v $(pwd):$(pwd) -t ubuntu:xenial sh -c "apt update -qq && apt install snapcraft -y && cd $(pwd) && snapcraft" + +``` +这个例子中，我们同样在 `machine` 执行器的虚拟机中安装了 `snapd`，但是我们决定将 Snapcraft 安装在 Ubuntu Xenial 镜像构建的 Docker 容器中，并使用它来构建我们的 Snaps。这样，在 `Snapcraft` 运行的过程中就可以使用所有在 Ubuntu 16.04 中可用的 `apt` 包。 + +### 测试 + +在我们的博客、文档以及互联网上已经有很多讲述如何对软件代码进行单元测试的内容。如果你用语言或者框架外加单元测试或者 CI 为关键词进行搜索的话将会出现大量相关的信息。在 CircleCI 上构建 Snaps 我们最终会得到一个 `.snap` 的文件，这意味着除了创造它的代码外我们还可以对它进行测试。 + +### 工作流 + +假设我们构建的 Snaps 是一个 `webapp`，我们可以通过测试套件来确保构建的 Snaps 可以正确的安装和运行，我们也可以试着安装它或者使用 [Selenium][5] 来测试页面加载、登录等功能。但是这里有一个问题，由于 Snaps 是被设计成可以在多个 Linux 发行版上运行，这就需要我们的测试套件可以在 Ubuntu 16.04、Fedora 25 和 Debian 9 等发行版中可以正常运行。这个问题我们可以通过 CircleCI 2.0 的工作流来有效地解决。 + +工作流是在最近的 CircleCI 2.0 测试版中加入的，它允许我们通过特定的逻辑流程来运行离散的任务。这样，使用单个任务构建完 Snaps 后，我们就可以开始并行的运行所有的 snap 发行版测试任务，每个任务对应一个不同的发行版的 [Docker 镜像][6] (或者在将来，还会有其他可用的执行器)。 + +这里有一个简单的例子： + +``` +workflows: + version: 2 + build-test-and-deploy: + jobs: + - build + - acceptance_test_xenial: + requires: + - build + - acceptance_test_fedora_25: + requires: + - build + - acceptance_test_arch: + requires: + - build + - publish: + requires: + - acceptance_test_xenial + - acceptance_test_fedora_25 + - acceptance_test_arch + +``` +在这个例子中首先构建了 Snaps，然后在四个不同的发行版上运行验收测试。如果所有的发行版都通过测试了，那么我们就可以运行发布 `job`，以便在将其推送到 snap 商店之前完成剩余的 snap 任务。 + +### 保存 .snap 包 + +为了测试我们在工作流示例中使用的 Snaps，我们需要一种在构建的时候保存 Snaps 的方法。在这里我将提供两种方法： + +1. **artifacts** —— 在运行 `build` 任务的时候我们可以将 Snaps 保存为一个 CircleCI artifact（artifact 也是 snapcraft.yaml 中的一个 `Plugin-specific keywords` 暂时可以不翻译 ），然后在接下来的任务中检索它。CircleCI 工作流有自己处理共享 artifacts 的方式，相关信息可以在 [这里][7] 找到。 + +2. **snap 商店通道** —— 当发布 Snaps 到 snap 商店时，有多种通道可供我们选择。将 Snaps 的主分支发布到边缘通道以供内部或者用户测试已经成为一种常见做法。我们可以在构建任务的时候完成这些工作，然后接下来的的任务就可以从边缘通道来安装构建好的 Snaps。 + +第一种方法速度更快，并且它还可以在 Snaps 上传到 snap 商店供用户甚至是测试用户使用之前对 Snaps 进行验收测试。第二种方法的好处是我们可以从 snap 商店安装 Snaps，这也是 CI 运行期间的一个测试项。 + +### Snap 商店的身份验证 + +[snapcraft-config-generator.py][8] 脚本可以生成商店证书并将其保存到 `.snapcraft/snapcraft.cfg` 中（注意：在运行公共脚本之前一定要对其进行检查）。如果觉得使用明文来保存这个文件不安全，你可以用 `base64` 编码文件，并将其存储为 [私有环境变量][9]，或者你也可以对文件 [进行加密][10]，并将密钥存储在一个私有环境变量中。 + +下面是一个示例，将商店证书放在一个加密的文件中，并在 `deploy` 中使用它将 Snaps 发布到 snap 商店中。 + +``` +- deploy: + name: Push to Snap Store + command: | + openssl aes-256-cbc -d -in .snapcraft/snapcraft.encrypted -out .snapcraft/snapcraft.cfg -k $KEY + /snap/bin/snapcraft push *.snap + +``` + +和前面的工作流示例一样，替代部署步骤的 `deplog` 任务也只有当验收测试任务通过时才会运行。 + +### 更多的信息 + +* Alan Pope 在 [论坛中发的帖子][11]：“popey” 是 Canonical 的员工，他在 Snapcraft 的论坛上写了这篇文章，并启发作者写了这篇博文。 + +* [Snapcraft 网站][12]： Snapcraft 官方网站。 + +* [Snapcraft 的 CircleCI Bug 报告][13]：在 Launchpad 上有一个开放的 bug 报告页面，用来改善 CircleCI 对 Snapcraft 的支持。同时这将使这个过程变得更简单并且更“正式”。期待您的支持。 + +* 怎么使用 CircleCI 构建 [Nextcloud][14] 的 Snaps：这里有一篇题为 [“复杂应用的持续验收测试”][15] 的博文，它同时也影响了这篇博文。 + + + +原始文章可以从 [这里][18] 找到。 + +--- + +via: https://insights.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages-using-snapcraft/ + +译者简介： +> 常年混迹于 snapcraft.io，对 Ubuntu Core、Snaps 和 Snapcraft 有浓厚的兴趣，并致力于将这些还在快速发展的新技术通过翻译或原创的方式介绍到中文世界。有兴趣的小伙伴也可以关注译者个人的公众号： `Snapcraft` + +作者：[Guest ][a] +译者：[Snapcrafter](https://github.com/Snapcrafter) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://insights.ubuntu.com/author/guest/ + + + [1]: https://snapcraft.io/ + [2]:https://circleci.com/docs/2.0/ + [3]: https://circleci.com/docs/2.0/first-steps/ + [4]: https://circleci.com/docs/1.0/differences-between-trusty-and-precise/ + [5]:http://www.seleniumhq.org/ + [6]:https://circleci.com/docs/2.0/building-docker-images/ + [7]: https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-artifacts-among-jobs + [8]:https://gist.github.com/3v1n0/479ad142eccdd17ad7d0445762dea755 + [9]: https://circleci.com/docs/1.0/environment-variables/#setting-environment-variables-for-all-commands-without-adding-them-to-git + [10]: https://github.com/circleci/encrypted-files + [11]:https://forum.snapcraft.io/t/building-and-pushing-snaps-using-circleci/789 + [12]:https://snapcraft.io/ + [13]:https://bugs.launchpad.net/snapcraft/+bug/1693451 + [14]:https://nextcloud.com/ + [15]: https://kyrofa.com/posts/continuous-acceptance-tests-for-complex-applications + [16]:https://nextcloud.com/ + [17]:https://kyrofa.com/posts/continuous-acceptance-tests-for-complex-applications + [18]: https://circleci.com/blog/build-test-publish-snap-packages?utm_source=insightsubuntu&utm_medium=syndicatedblogpost + [19]:https://circleci.com/blog/build-test-publish-snap-packages?utm_source=insightsubuntu&utm_medium=syndicatedblogpost \ No newline at end of file From b522148427d1ca430226c2059d256137f7034b19 Mon Sep 17 00:00:00 2001 From: Snapcrafter Date: Sun, 13 Aug 2017 12:37:04 +0800 Subject: [PATCH 05/34] Fix some errors --- ...uild, test, and publish snap packages using snapcraft.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md b/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md index 5d66be2665..8d60ff7b1d 100644 --- a/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md +++ b/translated/tech/20170628 Build, test, and publish snap packages using snapcraft.md @@ -1,7 +1,5 @@ # 使用 Snapcraft 构建、测试并发布 Snaps -标签（空格分隔）： snapcraft Snaps CircleCI - --- 这篇客座文章的作者是 Ricardo Feliciano —— CircleCi 的开发者传道士。如果您也有兴趣投稿，请联系 ubuntu-iot@canonical.com。 @@ -121,7 +119,7 @@ workflows: ``` -和前面的工作流示例一样，替代部署步骤的 `deplog` 任务也只有当验收测试任务通过时才会运行。 +和前面的工作流示例一样，替代部署步骤的 `deploy` 任务也只有当验收测试任务通过时才会运行。 ### 更多的信息 @@ -171,4 +169,4 @@ via: https://insights.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages [16]:https://nextcloud.com/ [17]:https://kyrofa.com/posts/continuous-acceptance-tests-for-complex-applications [18]: https://circleci.com/blog/build-test-publish-snap-packages?utm_source=insightsubuntu&utm_medium=syndicatedblogpost - [19]:https://circleci.com/blog/build-test-publish-snap-packages?utm_source=insightsubuntu&utm_medium=syndicatedblogpost \ No newline at end of file + [19]:https://circleci.com/blog/build-test-publish-snap-packages?utm_source=insightsubuntu&utm_medium=syndicatedblogpost From e487b6d19e1b137f6cda5082dd9a9db7994eb930 Mon Sep 17 00:00:00 2001 From: wxy Date: Sun, 13 Aug 2017 13:27:08 +0800 Subject: [PATCH 06/34] PRF:20161220 TypeScript the missing introduction.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit @MonkeyDEcho 恭喜你完成了第一篇翻译。你的 LCTT 专页是： https://linux.cn/lctt/MonkeyDEcho 翻译中，一个是要注意格式，具体可以参考我们的项目中的“格式指北”。另外一个是，用语可以灵活，但是要将原文的意思表达透彻。 --- ...220 TypeScript the missing introduction.md | 256 ++++++++---------- 1 file changed, 114 insertions(+), 142 deletions(-) diff --git a/translated/tech/20161220 TypeScript the missing introduction.md b/translated/tech/20161220 TypeScript the missing introduction.md index 53c7e84782..2177c0243e 100644 --- a/translated/tech/20161220 TypeScript the missing introduction.md +++ b/translated/tech/20161220 TypeScript the missing introduction.md @@ -1,55 +1,39 @@ -简洁的介绍TypeScript +一篇缺失的 TypeScript 介绍 ============================================================= +**下文是 James Henry（[@MrJamesHenry][8]）所提交的内容。我是 ESLint 核心团队的一员，也是 TypeScript 布道师。我正在和 Todd 在 [UltimateAngular][9] 平台上合作发布 Angular 和 TypeScript 的精品课程。** -**下文是James Henry([@MrJamesHenry][8])所编辑的内容。我是ESLint核心团队的一员，也是TypeScript的热衷者和发扬者。我和Todd合作在[UltimateAngular][9]平台上发布Angular和TypeScript的精品课程。** - -> 本文的主旨是为了介绍我们对TypeScript的思考和在JavaScript开发当中的更好的使用。 +> 本文的主旨是为了介绍我们是如何看待 TypeScript 的以及它在加强 JavaScript 开发中所起的作用。 > -> 我们将给出编译和关键字准确的定义 +> 我们也将尽可能地给出那些类型和编译方面的那些时髦词汇的准确定义。 -TypeScript强大之处远远不止这些，本篇文章无法涵盖，想要了解更多请阅读官方文档[official document][15]，或者查阅[TypeScript courses over on UltimateAngular][16]UltimateAngular平台的TypeScript精品课程－从初学者到TypeScript高手 +TypeScript 强大之处远远不止这些，本篇文章无法涵盖，想要了解更多请阅读[官方文档][15]，或者学习 [UltimateAngular 上的 TypeScript 课程][16] ，从初学者成为一位 TypeScript 高手。 -### [目录][17] +### 背景 -* [背景][10] -* [关键知识的掌握][11] - * [JavaScript解释型语言还是编译型语言][1] - * [运行时间 VS 编译时间][2] - * [TypeScript编译器][3] - * [动态类型 VS 静态类型][4] -* [TypeScript在我们JavaScript工作流程中的作用][12] - * [我们的源文件是我们的文档，TypeScript是我们的拼写检查][5] -* [TypeScript是一种可以启动其它工具的工具][13] - * [什么是抽象语法树（AST）？][6] - * [示例：在VS中重命名符号][7] -* [总结][14] +TypeScript 是个出乎意料强大的工具，而且它真的很容易掌握。 -### [背景][18] +然而，TypeScript 可能比 JavaScript 要更为复杂一些，因为 TypeScript 可能向我们同时引入了一系列以前没有考虑过的 JavaScript 程序相关的技术概念。 -TypeScript是很容易掌握的强大开发工具 +每当我们谈论到类型、编译器等这些概念的时候，你会发现很快会变的不知所云起来。 -然而，TypeScript可能比JavaScript要更为复杂，因为TypeScript可能同时向我们介绍以前没有考虑到的JavaScript程序相关的一些列技术概念。 +这篇文章就是一篇为了解答你需要知道的许许多多不知所云的概念，来帮助你 TypeScript 快速入门的教程，可以让你轻松自如的应对这些概念。 -每当我们谈论到类型、编译器等这些概念的时候。事情就会变的非常麻烦和不知所云起来。 +### 关键知识的掌握 -这篇文章就是为了你在学习过程中你需要知道的许许多多不知所云的概念解答的，来帮助你TypeScript入门的，让你轻松自如的应对这些概念。 +在 Web 浏览器中运行我们的代码这件事或许使我们对它是如何工作的产生一些误解，“它不用经过编译，是吗？”，“我敢肯定这里面是没有类型的...” -### [关键知识的掌握][19] +更有意思的是，上述的说法既是正确的也是不正确的，这取决于上下文环境和我们是如何定义这些概念的。 -有时候运行我们的代码是在Web浏览器中运行，和我们平常运行代码有不同的感觉，它是怎样运行自己书写的代码的？“没有经过编译的，是正确的吗？”。“我敢肯定没有类型的...” +首先，我们要作的是明确这些。 -情况变的更有趣了，当我们知道通过前后程序的定义来判断语法的正确与否 - -首先我们要作的是 - -#### [JavaScript 解释型语言还是编译型语言][20] +#### JavaScript 是解释型语言还是编译型语言？ 传统意义上，程序员经常将自己的程序编译之后运行出结果就认为这种语言是编译型语言。 -> 从初学者的角度来说，编译的过程就是将我们自己编辑好的高级语言程序转换成机器实际运行过程中能够看懂的格式（一般是二进制文件格式）。 +> 从初学者的角度来说，编译的过程就是将我们自己编辑好的高级语言程序转换成机器实际运行的格式。 -就像GO语言，可以使用go build的命令行工具编译.go的文件格式，将其编译成较低级的语言，可以直接运行的格式。（译者没有使用过GO语言，不清楚GO编译过程的机制，试着用C语言的方式说明） +就像 Go 语言，可以使用 `go build` 的命令行工具编译 .go 的文件，将其编译成代码的低级形式，它可以直接执行、运行。 ``` # We manually compile our .go file into something we can run @@ -59,21 +43,21 @@ go build ultimate-angular.go ./ultimate-angular ``` -我们在日常使用JavaScript开发的时候并没有编译的这一步，这是JavaScript忽略了我们程序员对新一代构建工具和模块加载程序的热爱。 +作为一个 JavaScript 程序员（这一刻，请先忽略我们对新一代构建工具和模块加载程序的热爱），我们在日常的 JavaScript 开发中并没有编译的这一基本步骤， -我们编写JavaScript代码在浏览器的