2012年10月ThoughtWorks技術雷達

自上期《技術雷達》釋出起，我們認為以下幾個技術趨勢越來越明顯：
• 移動：從“移動優先”的設計，一直到新的測試工具；
• 便利的分析：大資料並不意味著大預算；
• 簡單架構：橫跨構建和組合應用程式、部署、失效備份和恢復的技術；
• 可複製的環境：支援開發、測試和生產環境的標準化、自動安裝和協同管理；
• 使用得當的資料持久化：瞭解對NoSQL的使用（和濫用）的各種模式。

簡介

ThoughtWorks對技術一直褒有激情。我們對技術進行建立、研究、測試、開源、發表文章，並以改進技術為目標——為所有人。我們的使命是為軟體卓越和IT革命而奮鬥。為此，我們建立並分享ThoughtWorks技術雷達。ThoughtWorks技術戰略委員會由ThoughtWorks內部的資深技術專家組成，他們建立了這個技術雷達。他們經常聚在一起討論全球技術戰略和對行業有巨大影響的技術趨勢。

《技術雷達》總結了這些討論的結果，為包括從CIO到企業開發人員在內的相關人員提供有價值的資訊。本文中僅提供內容摘要，讀者可以繼續探索自己感興趣的細節。我們儘量保持雷達的簡潔明瞭，使讀者能夠快速瞭解。技術雷達用圖解的形式，將所有專案分為技術、工具、語言和平臺幾大類。有些專案會同時屬於多個類別，我們會將它歸入最合適的某個類別。另外，根據這些專案目前所處的環，用不同的階段將其進一步分組。

這些階段分為以下四個方面。
• 保留階段：應當謹慎使用的技術。
• 評估階段：值得探索的技術，以瞭解其對公司的影響。
• 試用階段：值得應用的技術。公司有必要了解如何使用該技術，並且在風險可控的專案中試用。
• 應用階段：強烈建議公司使用的技術。公司應在適當的時候應用於專案上。

新的專案或有新動向的用三角形代表，上期已經提到的專案用圓形代表。每個象限的圖展示了各個專案的動向。我們感興趣的專案遠遠多過可以展示在文件中的，所以我們只好隱去上期雷達展示過的舊專案，藉以給新的專案留出展示位置。但隱去並不代表我們不再關心它。

如希望瞭解更多的有關技術雷達的知識，請參閱Radar FAQ

編者：
ThoughtWorks技術諮詢委員會
Rebecca Parsons (技術長)
Martin Fowler (首席科學家)
Badri Janakiraman
Darren Smith
Erik Doernenburg
Evan Bottcher
Graham Brooks
Hao Xu
Ian Cartwright
James Fischer
James Lewis
Jeff Norris
Mike Mason
Neal Ford
Pramod Sadalage
Ronaldo Ferraz
Sam Newman
Scott Shaw
Srihari Srinivasan
Thiyagu Palanisamy
Wendy Istvanick

技術

我們看到，無論是在ThoughtWorks還是在更廣泛的社群，採用微服務（micro-services）的越來越多。諸如Dropwizard的框架和宣告性配置（declarative provisioning）都表明了技術和工具的成熟。避免通常的大規模整體替換，而是逐個替換系統的各個部分，對系統的總成本有積極的影響。我們看到，這對中長期尤其是二至五年的重寫週期影響最大 。

打破單一整塊的應用模式、而是以微服務來構建系統，需要一個可靠的策略把各個分開的系統整合起來從而給終端使用者提供連貫的體驗。在表現層使用Edge Side Includes (ESI) 來整合，是一個實用而優雅的解決方案。該方案以諸如Varnish的反向代理的形式存在於你的環境中，或在內容交付網路（Content Delivery Network - CDN）中貼近使用者。

應用程式部署經常由於過量的特定於環境的配置而痛苦，這些配置包括依賴的服務的主機名。在DNS配置中使用諸如“mail”“db”的標準主機名是降低配置複雜度的有價值的技術。該技術有多種實現方式，包括水平分割（split-horizon）的DNS或者配置搜尋子域。要做到這一點，開發團隊和IT運營之間的合作是不可缺少的，但遺憾的是這種合作在一些組織中依然很難實現。

在設計領域模型時，聚合模式有助於結構和模組化。對映到關係型資料庫，這種聚合在資料庫表中時不可見的。文件型資料庫，例如MongoDB，則可以將你的聚合建模成文件。這種1：1的對映意味著，聚合的根應該是從集合中載入的物件。

採納持續交付意味著很多團隊正在建立一個自動部署管道（automated deployment pipeline），用以把他們的程式碼一直送到產品環境。管道給其他複雜的構建、部署活動鏈條提供視覺化。此外，針對通往產品環境的每一階段的構建產物，管道為其提供了可靠的跟蹤能力。現在，許多廠商都在建立持續整合（CI）伺服器，並以管道做為其首要的功能，而不是僅僅提供視覺化模組。我們建議，團隊要仔細研究這些產品，以避免把自己的管道硬塞到一個不適當的產品中去。

在敏捷開發已經成為主流的情況下，我們提及這一點可能聽起來有些奇怪。但是我們發現團隊證重新發現並擁抱採納對半成品的限制。各種方法，例如看板（Kanban），限制了正在進行中的半成品，迫使團隊採取更優的工作流程，將瓶頸視覺化。

諸如Pallet等工具給宣告性配置下的環境建立和管理提供了令人信服的方法。通常，它以以下形式完成：用一種領域特定語言（Domain Specific Language, DSL）宣告環境拓撲——例項數、作業系統、網路配置和應用——之後用命令列工具自動化建立整個環境。這種方法的不同之處在於將例項的建立和應用的配置解耦；另一個不同之處在於，對搭建在多個機器上的特定領域應用層服務，這種方法具有宣告各個服務之間依賴性的能力。

我們在迅速走向一個移動裝置上的使用者互動佔主導的世界。“移動優先”擁抱這種變化趨勢，以移動裝置為第一目標來進行使用者介面和伺服器互動的設計。對比帶著高能力客戶端和快速可靠網路的假設的其他方法，移動優先策略降低使用者體驗以適應移動裝置的限制。

實現這一目標的一種技術是響應式網頁設計（responsive web design）。該技術使頁面開始於基本內容展示－通常是保持基本的資訊不變－按照檢測到的瀏覽器的功能進行相應的使用者體驗增強。這通常根據螢幕的大小來改變表單的佈局和格式。

在過去的15年裡，機器學習，語義分析，文字挖掘，定量分析，和其他先進的分析技術不斷成熟。這些方法在預言、預測識別重複的模式、洞察非結構化的資料提供了令人難以置信的潛力。從歷史上看，我們儲存和快速分析大的音訊、視訊和影像資料的能力受到嚴重限制。這種限制約束了樣本大小，也同樣束縛了驗證分析模型並將之放入產品的時間。現在，通過使用一些列諸如NoSQL，data harvesters，MapReduce框架和無共享（shared-nothing）的商品伺服器叢集等新技術，我們有了真正有效利用這些技術的必要能力。結合源自感測器、移動裝置和社交媒介的全球資料的大量增加，我們看到的是一個蘊藏著巨大商機的領域。

Web伺服器、資料庫、網路基礎設施和後臺系統生成的日誌檔案是業務的運作和行為重要資料來源。在過去，這些檔案大多數被視為失敗情況下的診斷資訊。但是，以如此低廉的存貯，加上諸如 Splunk等可用工具的對數以百萬計的事件的索引和檢索，日誌檔案也可以是瞭解客戶的資料來源。日誌即資料、並儲存完整的日誌而不是預定義的指標，提供一種方法來解答“一個企業不能達到先前預期”的新奇問題。

把使用者帶到一個可控環境下進行正式的測試是一個緩慢而昂貴的提議。更有用的是，定性的反饋可以快速而廉價的從遊擊式使用者測試得到——通過到外面的世界對一般公眾的小樣本進行測試。另一個替代方案是遠端可用性測試，你可以將從設計線框圖到最終產品等各種東西發出去給全球各地的人進行測試。Usabila, Loop11 和 Treejack等都可以提供工具，讓你可以要求使用者完成特定的任務，並捕捉所有資訊，從任務完成時間到使用者完成任務過程中的想法和感受。

開發團隊通常會產生測試來指定和驗證應用程式的行為，但是這些測試在產品釋出後就不再執行了。這是一個被錯過的機會。語義監控利用你的測試來持續評估你的應用程式，測試、執行相結合並進行實時監控。採用微服務和相同粒度的架構方法，執行時的互動測試越來越重要。將對使用者驅動的合約的驗證合併到一個監控設施中來是實現方法的一種。雖然仍在發展中，我們看到這兩種獨立但重要的驗證方案有很大的合併的希望。

驗收測試一般從“外部”執行被測系統，為執行整個應用的安全性遍歷整個網路堆疊。過程中的驗收測試對測試程式碼和被測應用必須執行在不同的程式中才能獲得這些好處的概念作出挑戰。當使用嵌入式的容器，不必花費由部署和與另一個容器通訊帶來的成本，就可以容易的搭建系統、通過HTTP執行測試並驗證最終狀態。

之前我們已經談過在應用程式所有適當的層執行自動化測試。在本期技術雷達中，我們要十分具體——我們不推薦基於瀏覽器的詳盡測試。諸如Selenium等瀏覽器自動化工具鼓勵通過瀏覽器進行廣泛的測試。而這些測試在測試集中持續佔有自己的位置，大多數團隊發現，通過瀏覽器執行這些大量的測試緩慢而脆弱。

工具

在各種專案中，我們使用過多種語言與構件工具，其中一個經常被我們使用的就是Rake。Rake 是一種優雅、簡單和強大的構建語言，它作為內部DSL並基於Ruby實現。Ruby可以執行於多種虛擬機器平臺，這意味著Rake也同樣可以，併為使用者留下了利用更多特定語言工具實現特定任務的空間。無論你使用哪種平臺，你都很難找到像Rake這樣的優雅與靈活性的結合體，所以我們推薦嘗試 Rake for Java and .Net 專案。

以XML為基礎的構件工具，例如Ant和Maven，由於太多令人生厭的尖括號和粗糙的外掛框架而逐漸失寵。雖然尖括號問題可以通過自動生成來解決，但當專案變得越來越複雜的時候，粗糙的外掛框架卻嚴重地限制了構建工具的能力。我們已經逐漸感覺到外掛框架其實是一種不合理的抽象層次，更推薦使用以語言為基礎的工具，例如 Gradle 和 Rake，因為它們從長遠來看抽象更加合理而且也更加靈活。

在Java和Ruby混搭的應用開發中，對包的格式和依賴管理的方式將截然不同。通過提供與Ivy相容的代理將RubyGems和JAR打包，並且使用Ivy來解決Gem依賴，GemJars將合併和簡化Java和Ruby混搭系統的構建工作。

在企業資料中心中，以前由雲服務提供商所設定的準則也在發生著變化。在雲環境中，很多系統將會自動擴容以提供額外的可用性或應對訪問量的增長。對於尋求 IaaS 和 PaaS 解決方案的企業來講，管理日益增長的叢集環境，使用不可變更伺服器（或者稱為“鳳凰伺服器”）是一個不錯的選擇。與此相對應的是，配置可更改的雪片伺服器增加了運營團隊的負擔並且鼓勵了一種“在我的機器上可以啊？！”的工作心態。利用例如 Chef 或 Puppet 工具可以通過指令碼快速構建伺服器或虛擬機器，從而大大減輕了管理伺服器叢集的複雜度。配合應對系統異常的軟體共同使用將大大增加系統的擴充套件性和穩定性。

我們一直以來都認為 Javascript 是一流的計算機語言，並且它努力跟隨著它所在領域的測試工具的發展。優秀的成果之一就是基於瀏覽器的測試框架 Jasmine。Jasmine 搭配 Node.js 使用是構建強壯的客戶或伺服器端的 JavaScript 應用的最佳選擇。

當構建分散式應用來應對網路擴充套件或大資料需求的時候，配置合適的監測工具將是一件不可捨棄的工作。Zipkin 可以採集不同服務組建的資料，並可通過類似於 firebug 的顯示方式顯示經由不同服務組建的具體訪問資訊。原始資料可儲存在 Hadoop 中用於進一步的資料探勘。

Zucchini 是提供給 iOS 應用的 Cucumber 風格的BDD測試框架。它使用 CoffeeScript 進行特徵定義，並且我們非常高興的是它可以在執行中儲存快照資訊。

iOS 本地應用是Apple移動平臺成功的基石。在 JetBrains 將其在其它平臺上的IDE的優勢注入併發布了 AppCode 以後，開發 iOS 和 OS X 應用已經變得越來越方便和高效。

像很多優秀的軟體開發者一樣，我們精心選擇我們使用的工具。我們的口味一般與眾不同，這是為什麼我們選擇支援 Light Table Kickstarter 專案的原因。儘管專案還處於早期開發階段，基於新的詮釋，他們承諾的互動性將匹擬 Smalltalk 世界中的佼佼者，我們期待著這一巨集大專案所產生的影響。

Hadoop 繼續作為開發分散式系統的主流框架。儘管使用 Java 開發 Hadoop 應用並不困難，但設計高效的 MapReduce 的資料處理通道確實需要相當的專案開發經驗。Apache Pig 通過提供高層語言 Pig Latin 和語言執行環境，簡化了 Hadoop 的開發。Pig Latin 是過程式語言，提供類似於 SQL 的方式與大型資料集進行互動。底層執行平臺將 Pig Latin 編譯成為執行在叢集上的一系列優化後的 MapReduce 程式。Pig Latin 可以基於不同語言，例如 Ruby，JavaScript，Python 和 Java 通過使用者自定義函式的方式進行擴充。

有很多實用性測試工具非常適合我們的游擊戰方式。視線跟蹤一直以來是設計迷人的使用者介面的有效工具，然而與之相關的軟體和硬體裝置都非常昂貴並需要專業公司的指導。Crazy Egg 是廉價的軟體解決方案，它基於滑鼠移動產生熱成像圖，滑鼠移動與視線焦點又具備非常相關的聯絡並且可作為近似估算。Silverback 不僅在測試過程中可以截圖，也可以錄製使用者的面部影像和聲音。這些特點能為大型開發團隊提供非常寶貴的測試體驗分享。

儘管存在許多用以支援系統監測的圖表生成工具，Graphite 無疑正在成為它們之中的首選。除了可以實時顯示圖表資料，它所採用的環狀資料庫既可以儲存大量的歷史資料，也可以提供可靠的近期資料。在介面上還提供了不少配置選項，最終的資料圖表也可被嵌入網頁從而提升展示效果。

Riemann 是一個開源伺服器，它可以實時地將各種事件進行整合和傳遞。它基於 Netty 用 Clojure 編寫，能夠應對單個節點上的成千上萬次的併發請求。Riemann 使用簡單的 Protobuf 作為事件處理協議，支援將各種型別，例如 CPU、記憶體使用、訂單錯誤率的事件資訊整合起來，並可將資料提供給例如 Graphite 型別的圖表系統或者觸發郵件通知，同時提供資料的監測頁面。Riemann 把資料處理理解為實時的通用事件流，相對於使用特定系統處理特定型別的資料的而言，Riemann 無疑是向前邁出了一大步。

JavaScript 引擎的效能提升結合著廣泛被採納的基於 HTML 的嵌入式 SVG 文件，這使得基於純 Javascript 的客戶端圖表和視覺化解決方案被更多人所接受。Highcharts 是我們嘗試過的優秀者之一，它具備對高可配置性互動圖表的靈活支援，並可輕而易舉地對大資料集進行渲染。

D3 是將資料集繫結至 DOM 的 JavaScript 函式庫，通過宣告式的方法將文件轉換為不同的視覺化效果（從圖表到熱成像圖）。對 HTML、CSS 和 SVG 的支援，和採用可擴充套件的外掛模型，我們喜歡它所提供的通過多種直觀方法表現資料的方式。

我們對程式碼視覺化技術非常著迷。特別是已經被證明非常有用的 Dependency Structure Matrices (DSM) ，它支援進化式結構與浮現式設計並且存在大量的支援 DSM 的工具。

我們已經談論過很多關於 embedded servlet containers 的事情，並且它們也已經被我們的專案所廣泛採用。像 SimpleWeb 和 Webbit 這樣的工具通過簡單和嵌入式的途徑更進一步提供了無需實現 Java Servlet 標準的精簡 HTTP 伺服器功能。我們也高興地看到利用此優勢的相關測試程式碼的複雜度也在降低。

我們是內建式自動化效能測試的信仰者，但目前在這領域的開源測試工具數量有限。Locust 是非常推薦的 Python 測試工具，它支援執行多個注入器，生成基本的統計資料，還提供了實用的網頁皮膚。它在效能測試方面更專注於對使用者行為的模擬而不僅是生成訪問流量，所以相對於傳統的 JMeter 和 Grinder 我們更推薦使用 Locust。

當前 SaaS 效能測試工具，例如 Blitz.io 和 Tealeaf 的興起使我們避免了效能測試中搭建叢集環境以及軟體許可給我們帶來的種種麻煩。這些服務通過不同地域的客戶端的支援使效能測試變得異常簡單，並且免去了在基礎平臺上的大量投入。

平臺

混合雲（Hybrid clouds）結合了公有云和私有資料中心的最佳特性。混合雲允許應用程式在正常時間執行於私有資料中心，而高峰時段的過載請求則執行於公有云中的租賃空間。有很多基礎設施解決方案允許在混合雲上自動一致的部署，例如Palette和RightScale。由於Amazon，Rackspace和其他服務商提供的強大的產品，我們將混合雲放到本版雷達的試用圈中。

從令人眼花繚亂的雲服務商中做正確的選擇依然很困難。一個策略就是採用開源IaaS（open source IaaS)平臺，例如OpenStack或者CloudStack。開源IaaS平臺可以執行和公有云一致的私有云，在有需要時從一個雲服務商遷移到另一個上去。Apache的Deltacloud進一步從服務商特定的APIs中抽取以提供跨雲平臺的一致體驗。

Google的BigQuery(BigQuery)將資料分析帶到雲上。不再是將資料載入到一個昂貴的，提前定義索引的資料倉儲，BigQuery通過隨機的類似SQL的查詢允許上傳和分析一個資料集。數千臺伺服器在幾秒內處理數千兆資料, 這為概念證明甚至一個完整的應用都提供了一個廉價的方式。

微軟的Azure雲平臺(Azure) 繼續和AWS這些更成熟的平臺扮演追趕者的角色，但微軟如何響應市場需求仍然讓我們印象深刻。像大多數微軟的解決方案一樣，Azure仍然是一個競爭者並且值得評估。

雲端的持續整合（Continuous integration in the cloud)是支援敏捷開發且事後顯而易見的基礎設施解決方案之一。沒有本地軟體，只有最少配置就可以工作。隨著產品的成熟，開發人員沒有理由不採用這個重要的實踐。

儘管在全球北美遭到明顯的抵制，像肯亞的M-Pesa這樣的移動支付系統（mobile payment systems）正提供安全的非現金貨幣交易。隨著這項服務在非洲的展開，這個系統為百萬有著手機卻無法訪問傳統的銀行網點的人們開啟了一個巨大的市場。如Square這樣的供應商正緩慢改變現狀，但是北美繼續落後。

對於適用於文件資料庫模型的問題，MongoDB（MongoDB)提供了簡單的可程式設計性，一個查詢藉口，自動故障轉移的高可用性和自動的分片能力。它允許從一個關係型資料庫管理系統模型平滑地轉移到NoSQL資料儲存，並且用一些大家熟悉的概念，如能夠定義索引。

圖形資料庫將資訊儲存為由命名關係形成的任意互連節點，而不是表和連線。沒有Schema，高度的可擴充套件性，圖形資料庫是複雜領域建模半結構化資料的一個非常好的選擇。Neo4j（Neo4j）是該領域的領跑者，它的REST API和Cypher查詢語言支援簡單快速的儲存和圖表的遍歷。

Riak(Riak)是分散式鍵值儲存，沒有Schema，與資料型別無關。對於寫任務很重的專案，例如儲存像會話，購物車和流日誌這樣的資訊，Riak非常適用，同時它也能在全文字搜尋中執行復雜查詢。分散式叢集可以在沒有單主站時自我恢復，有可調的一致性和可用性設定，能夠檢測衝突，如果需要可以解決衝突-這些對於高可用性環境特別有幫助。

基於對資料庫工作原理的重新思考，Datomic(Datomic)是一個不可變的資料庫伺服器，具備事務處理和部署的特性。在敏捷專案裡一個共同的頭痛之處在於管理資料庫遷移，特別是備份之前的狀態。Datomic讓遷移的需求不再存在-每一個版本的資料（以及schema)都被資料庫儲存。雖然仍在演進，但我們欣賞Datomic的氣魄。

Couchbase(Couchbase)是一個持續快取，具備自動分片，無主機叢集和為了避免快取丟失的資料複製等功能。因為支援Memcached協議，它允許基於Memcached系統的簡易替換。

作為從傳統，獨立應用程式容器中進化而來的代表，Vert.x(Vert.x)是一個連線同步和非同步程式設計風格的應用框架。程式設計師為了簡單起見，可以選擇權衡可擴充套件性和效能。和Node.js不同，Vert.x是一個可以從很多支援JVM的語言中被呼叫的庫，包括Java，Ruby和JavaScript。

我們之前對跨平臺重用程式碼持懷疑態度。我們將市場上很多工具的經驗融合，並且建議對這種型別解決方案感興趣的客戶慎重。如果在這個較為危險的領域做選擇的話，我們感覺Calatrava（Calatrava)是移動應用開發中值得評估的。它的架構很好地遵守了業務和表現層邏輯的分離，最大化重用相同的部分，並且提供平臺本地介面的訪問來滿足速度以及裝置特定功能的需求。

Meteor.js(Meteor.js)是一個客戶端和服務端的JavaScript應用框架，在web瀏覽器或Node.js容器裡執行，用MongoDB支援保持永續性。它使用“智慧包”-很少的一部分程式碼，可以作為瀏覽器執行或者作為雲服務的一部分。它允許熱部署和在瀏覽器中更新。我們覺得儘管這個框架還沒有完全成熟，但是這個想法還是很棒。

儘管Windows Phone有一個良好的開端，一個深思熟慮的使用者介面，以及可能所有移動平臺中最好的開發體驗，我們還是看到微軟和它的合作伙伴在平臺策略執行過程中的一些牽絆。和上一版雷達比，這讓我們對這個平臺的將來不太樂觀。

有時，架構上的決定導致你將基礎設施包含在內，而通常我們只能承受一個基礎設施，例如大型機或者搜尋裝置。這是個很糟糕的想法。它嚴重限制了測試和部署的靈活性。我們強烈支援可以容易設定和拆除的基礎設施。Singleton infrastructure(Singleton infrastructure)屬於過去被誤導的供應商驅動的架構。

語言和框架

JavaScript已經超出了瀏覽器，作為跨平臺開發的一個重要技術新興而起。它在如Node.js，Meteor.js，以及如Calatrava的移動框架的程式碼重用的方式中，是一個前端和中介軟體。隨著近來其他編譯成JavaScript的語言的擴散，我們考慮是否應該將JavaScript作為一個平臺(JavaScript as a platform)而不是一種語言。

隨著JavaScript越來越多地被採用，許多JavaScript程式碼庫的大小也在增加。為了改進程式碼模組化以及幫助管理，我們看到團隊歡迎一些如Require.js（Require.js)的庫。使用非同步模組定義（AMD）格式後，程式碼被分成模組，使得開發和維護都變輕鬆，也是一個合併和減小產品環境部署指令碼的優化工具。

隨著JavaScript的發展，越來越多的需要可重用，可擴充套件的UI工具。Twitter Bootstrap（Twitter Bootstrap)是該領域最好的產品，提供了一系列強大的模式和元件，幫助開發者建立有藝術感的響應式和自適應的應用。

我們認為鼓舞下一代技術者們非常重要。Scratch，Alice和Kodu（Scratch，Alice,and Kodu)是一些依賴視覺環境和教育裝置模組的程式語言。他們為培養在學術環境外的普及程式設計知識的教育專案和組織提供更多可能性。

作為程式語言領域一個不可能的競爭者，Lua(Lua)在不同的行業中都得到了廣泛的採用。在遊戲開發和音樂創作中作為指令碼平臺；在銷售點裝置和網路裝置中嵌入；在有安全執行語義的擴充套件NoSQL資料庫中使用。我們期待將來會有更多的應用。

作為在客戶端和伺服器端處理應用中增加的複雜度的一種方式，微框架正新興起來。Sinatra（Sinatra）是伺服器端這一領域的先驅，通過輕量級的DSL來快速構建服務。Flask, Scalatra和Compojure是和Python,Scala和Clojure對應的一些類似產品。

Dropwizard(Dropwizard)是一些輕量級Java工具和框架的組合，這些工具和框架大多值得推薦。這個組合體現了許多我們喜愛的技術，包括嵌入的HTTP伺服器，支援RESTful端點，內建的運營指標和健康檢查，以及直接部署。Dropwizard使做正確的事更容易，允許你關注問題關鍵的複雜部分而不是其他的支援部分。

Gremlin（Gremlin）是急需的一種由多種圖形資料庫支援的圖形遍歷語言。其簡潔的結構可以在資料庫的原生語言中被應用，可以更快的開發，有些情況下，更快的執行。我們推薦它作為簡單場景的一個選擇。

Jekyll(Jekyll)代表了網站釋出領域的框架的“微觀化”。當關注點只有一個，部落格網站儘可能透明，並且指向一個更輕量級的未來。一個我們喜歡的例子就是現在釋出軟體專案有用的文件更加輕鬆了。

作為Ruby編譯器以及iOS應用開發的工具，RubyMotion（RubyMotion）在ThoughtWorks開發社群中不出意外地引起了不小的轟動。開發應用時理解底層的iOS APIs和一些Objective-C的需求依然存在，但RubyMotion對於更習慣於Ruby語言和工具的人來說還是很有幫助。

有一種趨勢認為離線功能的需求和開發一個應用的需求等同。儘管標準化流程緩慢，大部分HMTL5的功能已經在主流瀏覽器上被應用。本地儲存能力，跨手機和平板瀏覽器支援能力，這些使得使用HMTL5開發離線應用（HTML5 for offline applications)一個非常合適的選擇。

我們看到建立單頁面網站應用的一個通用模式。不再需要整個頁面重新整理，只需要伺服器端很小的一部分資料集，通過修改DOM來改變頁面內容的展示。為了使這些更易管理，JavaScript MV*框架用來支援資料繫結，客戶端模板以及驗證。輕量級應用可能不需要一個框架，對於更復雜的場景，AngularJS和Knockout（AngularJS and Knockout)可以看做該領域的領跑者。

Backbone.js(Backbone.js)是一個抽象較弱的例子。我們喜歡開始很容易的搭建，但實際上它和所有從WebForms到客戶端/服務端工具的資料繫結框架有同樣的問題。我們發現它讓框架和模型太過模糊，從而容易造成要麼產生出不佳的架構設計,要麼只能通過精妙的框架修改來保持概念的完整性。

隨著整個行業從桌面GUI開發轉向web, 將大多數成功的模式和設計移植到新的範例中看起來很自然。在15年的嘗試後，我們感覺仍然沒有基於元件的框架（component-based frameworks)成功地實現。我們推薦不要試圖在本質不同的東西上做網站開發。現在是接受網站的網頁和基於請求的本質的時候了，關注支援的架構而不是和這些概念鬥爭。