微軟開源P語言；Facebook開源JS包管理器Yarn；GitHub採用了新的GraphQL API
微軟開源P語言，實現安全的非同步事件驅動程式設計
微軟最近開源了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
文章出處：InfoQ