开源改变世界，微软、Facebook真乃开源良心。本实习主播稍微剧透一下，1024程序员节，给你看不一样的东西~
微软最近开源了P语言（https://github.com/p-org/P），致力于在Linux、macOS和Windows上编写安全的异步事件驱动程序。
微软将P描述为一种领域特定语言，对异步系统的组件间通信进行建模，例如嵌入式、网络或分布式系统。P程序是通过有限状态机（finite state machine）来定义的，这些状态机会并发运行。每个状态机都有一个输入队列、状态、转换、机器本地存储，并且可以发送异步信息给其他状态机。
在P中的基本操作要么是更新本地存储，发送消息，要么就是创建新的状态机。如下的代码片段展示了如何使用P来描述一个状态及其转换。除此之外，它还展现了如何发送消息或创建新的状态机：
...
start state Init {
entry {
server = new Server();
raise SUCCESS;
} on SUCCESS goto SendPing;
state SendPing {
entry {
send server, PING, this;
raise SUCCESS;
}
on SUCCESS goto WaitPong;
}
...
按照微软的说法，P程序能够使用模型检查功能来进行核实。这样的话，就允许开发人员确保所有的事件均能得到及时地处理。对于P程序来说，要想保证响应性，它的状态机就要处理每个状态上所有可以出队（dequeue）的事件。这种做法并不一定总是可行，因此对一些事件可能会进行延迟处理。
在这种情况下，语言能够确保某个事件不会无限期延迟。P编译器能够核实程序的状态，还可以生成C代码，并交给C编译器执行，另外，它还可以输出Zing模型，用于系统测试。Zing是一个针对并发程序的开源模型检查器，它能够系统性地暴露一个模型所有可能出现的状态。
微软使用P语言实现和检验了Windows 8 USB设备驱动栈的核心功能。按照微软的说法，工程师使用P来序列化大量来自硬件、操作系统、功能驱动以及其他驱动组件的不同事件，提升了性能和可靠性。他们尤其指出，在新的USB hub驱动中，非法内存访问和竞态条件的数量不那么明显了，同时，枚举时间快了30%，也没有观察到worker条目饿死的现象。
本文翻译已获授权，原文链接：
http://www.infoq.com/news/2016/10/microsoft-p-language-opensourced
本文译者：张卫滨
Facebook开源JavaScript包管理器Yarn
Facebook开源了Yarn（https://yarnpkg.com/），这是针对存储在npm或Bower注册表中的JavaScript模块的一个代理包管理器。
按照其三位工程师所撰写的博客文章：
http://blog.npmjs.org/post/151660845210/hello-yarn
多年以来，Facebook一直非常成功地使用npm客户端。在他们的团队中，这起初运行得很不错，直到代码库增长到一个点，此时“一致性、安全性以及性能”方面的问题开始浮现：
在Facebook，我们的很多项目，比如React，都会依赖npm注册表中的代码。但是，随着内部的扩展，当在不同的机器和用户上安装依赖时，我们遇到了一致性的问题，还要考虑到加载依赖所消耗的时间，另外，npm客户端在加载某些依赖的时候，会自动执行代码，这也会带来安全方面的问题。
Facebook提到了通过CI工具运行npm install时的问题，因为处于安全的考虑，他们的环境与互联网是互相切断的。最直接的解决方案就是单独下载所需的模块，并将它们包含到项目的源码中。但是，更新其中的某些模块会带来很大的影响：
例如，更新babel的一个小版本都会导致800,000行的提交，这样的话，对于非法utf8字节序列、Windows换行符以及non png-crushed图片触发lint规则校验就会非常困难。对node_modules合并变更经常会耗费工程师一整天的时间。
他们所做的最后一次尝试就是从源码中移除这些模块，并将其放到内部的CDN上。但是，这意味着要为开发和CI构建机器提供互联网的连接，而这是无法接受的。最终，他们构建了自己的包管理器，名为Yarn，Facebook认为它是快速、可靠和安全的。
Yarn具有多项特性：
离线模式（Offline Mode）：如果你之前安装过某个包，那么你可以在没有互联网连接的情况下，对这个包进行重新安装。
确定性（Deterministic）：不管安装顺序如何，相同的依赖在每台机器上会以完全相同的方式进行安装。
网络性能：Yarn会对请求进行高效地排队，避免出现请求瀑布（waterfall），便于将网络的使用效率达到最大化。
网络弹性（Network Resilience）：单个请求的失败不会导致整个安装的失败，请求会基于故障进行重试。
扁平模式（Flat Mode）：将不匹配的依赖版本都会解析为同一个版本，避免重复创建。
另外值得一提的特性就是Yarn能够与npm和Bower注册表协作使用。
经营npm注册表的npm公司对 Yarn表示欢迎，因为这是对已有Node.js管理器的一个补充，值得注意的是，尽管Yarn会从registry.yarnpkg.com抓取包，但这个仓库仅仅是官方npm注册表的一个代理。
还有Facebook没有明确提及的一点，Yarn的另外一个目的在于：在npm注册表宕机时，所有的Node模块能有一个安全的备份，因为在今年春天npm曾经停机2.5小时，导致世界范围内成千上万的开发人员构建失败。
除非具有像Facebook那样的扩展性和开发需求，Yarn不一定是必须的，但是通过代理来获取包能够在原始注册表发生宕机时，提供一个弹性层。
Facebook还介绍说Yarn是与Exponent、Google和Tilde协作的成果。它的代码已经基于BSD许可证协议在GitHub上开源。
开源地址：https://github.com/yarnpkg/yarn
本文翻译已获授权，原文链接：
http://www.infoq.com/news/2016/10/yarn
本文译者：张卫滨
GitHub采用了新的GraphQL API
近期在GitHub全球大会上，GitHub推出了新API的alpha预览版，该版API使用Facebook的GraphQL（http://graphql.org/，一种允许自服务API契约的查询语言）编写。
GitHub在其工程博客写道，GitHub对API范式的转换主要是因为现有的RESTful契约缺乏可扩展性。为迎合大量各异客户的需求，REST不能在提供GitHub所需灵活性的同时维持较低的维护代价。
GitHub将现有API迁移到GraphQL的公告，与数日后Facebook将最终移除其服务的“技术预览”绰号的决定是遥相呼应的。虽然早自2002年起，GraphQL就已用于Facebook的生产环境中，但由于直至最近GraphQL的九月中期版本才得以开源，所以其在技术上依然是一个“预览版”。
总体而言，社区对GraphQL表现出复杂的反应，一些人宣称GraphQL给服务器端代码带来了不公平的额外复杂度和管理，也有一些人对GraphQL分隔各种个体消费者的数据消费需求和核心数据本身的能力青睐有加，认为这将使API更具可扩展性和多样性。
GitHub在其工程博客上这样地描述当前的API：“不管我们提供了多少信息，来自集成商那里的反馈依然认为我们的REST API还不够灵活。有时为构成对一个资源的完整视图，需要做两次或三次单独调用。看上去尽管我们的响应同时发送了太多的数据，但是其中并未包括用户所需的数据。”
这里Github暗示GraphQL非常适合于具有大量各异客户的应用场景，其中客户对底层数据具有复杂规模的需求。而对于为一个并没有多少开发人员消费的简单网站提供API，GraphQL并不能体现出其相对于REST的优越性。
在其工程博客中，GitHub指出其API的历史开始于2008年。其中提及Github的第一个RESTful API成为了很多企业的样板，彼时这些企业正为精雕细琢其自身的REST API而寻找实例模板。GitHub希望GraphQL能像其首次涉足REST时那样，为那些寻求很好的方式去从多消费者复杂数据需求中受益的开发人员和企业树立样板。
正如在GraphQL技术预览版发布后的InfoQ文章中，GraphSQL的早期贡献者之一Lee Byron所说的：“社区不仅在使用GraphQL，同时也在创建它。”作为GraphQL的首批主流用户之一，GitHub自采用GraphQL以来就一直在转变它。在GitHub上，GraphQL已从其早期的JavaScript构建，转变为使用从Java到C#和Ruby（Ruby是GitHub自身也在使用的）等多种语言构建，现在平台上已有种类繁多的开源工具。
虽然看上去GitHub转到GraphQL的主要原因是为了实现适合各种客户所需的可扩展性，但是GitHub也提及很多额外的优点。在其技术博客中这样写道：“GraphQL代表了API开发中的一个巨大飞跃。类型安全、内省、文档生成和可预测响应，这使我们平台的维护者和客户均可从中受益。”考虑到GitHub当前所呈现出的数据规模，文档生成和内省有益于数据的消费。
此外，Swagger等工具非常有助于RESTful API的文档化，GitHub确需贯穿整个代码库的手工注解创建，这些注解易于变成和代码注释一样的陈旧。GitHub可以使用GraphQL所包括的所有工具，与相应的API改变和必要的API文档一起发布其中的软件，这对于GitHub及其用户而言均为一个重大利好。
本文翻译已获授权，原文链接：
https://www.infoq.com/news/2016/10/graphQL-GitHub
本文译者：Rays
▽
延展阅读（点击标题）：
喜欢我们的会点赞，爱我们的会分享！
![]()
