浏览器通讯新标准——WebRTC

What is WebRTC?

WebRTC是Web Real-Time Communication的简称,它是谷歌的一个开源项目,其目的是通过一系列的协议和规范来让浏览器提供支持实时通讯功能的API接口,这样在浏览器中通过简单的接口调用即可实现本地音频、视频等资源的实时共享。

早在 2009 年,Google的一名员工就提出了该想法,随后便有几位对此想法有兴趣的人开始投入精力开发,不久后关于获取本地资源的差异性问题都已经解决,唯一的难点就是解决实时通讯。与此同时,随着Chrome浏览器的推广, Google开始对此想法投入大量的精力,在2011年收购了当时拥有实时通讯所需低级组件的Gips公司后,实时通讯的难题也逐渐得到解决,随后WebRTC便应运而生。

(图片来自:http://t.cn/RQ3FnsC

Why WebRTC ?

在没有WebRTC之前,如果要在浏览器中实现实时通讯只有两种方式:

  • Flash: Flash顾名思义是通过Flash技术来实现本地音、视频资源共享。而使用Flash最大的问题在于Flash只能提供质量较差的视频及音频资源,而且运行时还需要服务器许可证。
  • Plug-in: Plug-in是通过给浏览器安装支持访问本地资源的插件来实现对本地音、视频资源的共享。而使用Plug-in最大的问题在于维护成本太高,因为不同的浏览器,不同的系统需要提供不同版本的插件,这样则导致一个功能需要针对不同的平台去做开发。

通过比较,很明显可以发现,WebRTC仅仅通过浏览器提供的同样的API接口,就可以实现实时通讯,而在开发过程中不用去关心平台和兼容性甚至安全性问题,那么实时通讯的实现成本就会降低很多。因此,很多网站已经开始使用WebRTC技术来实现实时通讯功能。

Why ASSESS ?

WebRTC在解决Web实时通讯问题中可以说是首选方案,但为什么在我司的技术雷达中仍然处于“评估”呢?我觉的目前最主要的一个问题是浏览器支持程度。这里是WebRTC对浏览器最新的支持情况,明显可以看出,WebRTC目前是不支持任何IOS设备的,这将使 WebRTC的适用性大大降低。其次,出于安全性考虑,所有使用WebRTC的站点必须使用 HTTPS协议,这又大大的限制了WebRTC的适用范围。

虽然如此,WebRTC依然是目前在浏览器实现AR/VR技术最简单易用的流媒体平台,加之Apple已经明确表示在未来的Safari中将支持WebRTC,不知道在IOS设备支持WebRTC及浏览器中AR/VR技术普遍采用WebRTC后,WebRTC是否会迎来突飞猛进的发展呢?


点击这里查看最新版技术雷达

Share

phantomJs之殇,chrome-headless之生

技术雷达快讯:自2017年中以来,Chrome用户可以选择以headless模式运行浏览器。此功能非常适合运行前端浏览器测试,而无需在屏幕上显示操作过程。在此之前,这主要是PhantomJS的领地,但Headless Chrome正在迅速取代这个由JavaScript驱动的WebKit方法。Headless Chrome浏览器的测试运行速度要快得多,而且行为上更像一个真正的浏览器,虽然我们的团队发现它比PhantomJS使用更多的内存。有了这些优势,用于前端测试的Headless Chrome很可能成为事实上的标准。

随着Google在Chrome 59版本放出了headless模式,Ariya Hidayat决定放弃对Phantom.js的维护,这也标示着Phantom.js 统治fully functional headless browser的时代将被chrome-headless代替。

Headless Browser

也许很多人对无头浏览器还是很陌生,我们先来看看维基百科的解释:

A headless browser is a web browser without a graphical user interface.

Headless browsers provide automated control of a web page in an environment similar to popular web browsers, but are executed via a command-line interface or using network communication.

对,就是没有页面的浏览器。多用于测试web、截图、图像对比、测试前端代码、爬虫(虽然很慢)、监控网站性能等。

为什么要使用headless测试?

headless broswer可以给测试带来显著好处:

  1. 对于UI自动化测试,少了真实浏览器加载css,js以及渲染页面的工作。无头测试要比真实浏览器快的多。
  2. 可以在无界面的服务器或CI上运行测试,减少了外界的干扰,使自动化测试更稳定。
  3. 在一台机器上可以模拟运行多个无头浏览器,方便进行并发测试。

headless browser有什么缺陷?

以phantomjs为例

  1. 虽然Phantom.js 是fully functional headless browser,但是它和真正的浏览器还是有很大的差别,并不能完全模拟真实的用户操作。很多时候,我们在Phantom.js发现一些问题,但是调试了半天发现是Phantom.js自己的问题。
  2. 将近2k的issue,仍然需要人去修复。
  3. Javascript天生单线程的弱点,需要用异步方式来模拟多线程,随之而来的callback地狱,对于新手而言非常痛苦,不过随着es6的广泛应用,我们可以用promise来解决多重嵌套回调函数的问题。
  4. 虽然webdriver支持htmlunit与phantomjs,但由于没有任何界面,当我们需要进行调试或复现问题时,就非常麻烦。

那么Headless Chrome与上面提到fully functional headless browser又有什么不同呢?

什么是Headless Chrome?

Headless Chrome 是 Chrome 浏览器的无界面形态,可以在不打开浏览器的前提下,使用所有Chrome支持的特性,在命令行中运行你的脚本。相比于其他浏览器,Headless Chrome 能够更加便捷的运行web自动化测试、编写爬虫、截取图等功能。

有的人肯定会问:看起来它的作用和phantomjs没什么具体的差别?

对,是的,Headless Chrome 发布就是来代替phantomjs。

我们凭什么换用Headless Chrome?

  1. 我爸是Google,那么就意味不会出现phantomjs近2k问题没人维护的尴尬局面。 比phantomjs有更快更好的性能。
  2. 有人已经做过实验,同一任务,Headless Chrome要比现phantomjs更加快速的完成任务,且占用内存更少。https://hackernoon.com/benchmark-headless-chrome-vs-phantomjs-e7f44c6956c
  3. chrome对ECMAScript 2017 (ES8)支持,同样headless随着chrome更新,意味着我们也可以使用最新的js语法来编写的脚本,例如async,await等。
  4. 完全真实的浏览器操作,chrome headless支持所有chrome特性。
  5. 更加便利的调试,我们只需要在命令行中加入–remote-debugging-port=9222,再打开浏览器输入localhost:9222(ip为实际运行命令的ip地址)就能进入调试界面。

能带给QA以及项目什么好处?

前端测试改进

以目前的项目来说,之前的前端单元测试以及组件测试是用karma在phantomjs运行的,非常不稳定,在远端CI上运行时经常会莫名其妙的挂掉,也找不出来具体的原因,自从Headless Chrome推出后,我们将phantomjs切换成Headless Chrome,再也没有出现过异常情况,切换也非常简单,只需要把karma.conf.js文件中的配置改下就OK了。如下

customLaunchers: { myChrome: { base: 'ChromeHeadless', flags: ['--no-sandbox', '--disable-gpu', '--remote-debugging-port=9222'] } },

browsers: ['myChrome'],

UI功能测试改进

原因一,Chrome-headless能够完全像真实浏览器一样完成用户所有操作,再也不用担心跑测试时,浏览器受到干扰,造成测试失败

原因二,之前如果我们像要在CI上运行UI自动化测试,非常麻烦。必须使用Xvfb帮助才能在无界面的Linux上 运行UI自动化测试。(Xvfb是一个实现了X11显示服务协议的显示服务器。 不同于其他显示服务器,Xvfb在内存中执行所有的图形操作,不需要借助任何显示设备。)现在也只需要在webdriver启动时,设置一下chrome option即可,以capybara为例:

Capybara.register_driver :selenium_chrome do |app|
Capybara::Selenium::Driver.new(app, browser: :chrome,
                               desired_capabilities: {
                                   "chromeOptions" => {
                                       "args" => [ "--incognito",
                                                   "--allow-running-insecure-content",
                                                   "--headless",
                                                   "--disable-gpu"
                                   ]}
                               })
end

无缝切换,只需更改下配置,就可以提高运行速度与稳定性,何乐而不为。

Google终极大招

Google 最近放出了终极大招——Puppeteer(Puppeteer is a Node library which provides a high-level API to control headless Chrome over the DevTools Protocol. It can also be configured to use full (non-headless) Chrome.)

类似于webdriver的高级别的api,去帮助我们通过DevTools协议控制无界面Chrome。

在puppteteer之前,我们要控制chrome headless需要使用chrome-remote-interface来实现,但是它比 Puppeteer API 更接近低层次实现,无论是阅读还是编写都要比puppteteer更复杂。也没有具体的dom操作,尤其是我们要模拟一下click事件,input事件等,就显得力不从心了。

我们用同样2段代码来对比一下2个库的区别。

首先来看看 chrome-remote-interface

const chromeLauncher = require('chrome-launcher');
const CDP = require('chrome-remote-interface');
const fs = require('fs');
function launchChrome(headless=true) {
return chromeLauncher.launch({
// port: 9222, // Uncomment to force a specific port of your choice.
 chromeFlags: [
'--window-size=412,732',
'--disable-gpu',
   headless ? '--headless' : ''
]
});
}
(async function() {
  const chrome = await launchChrome();
  const protocol = await CDP({port: chrome.port});
  const {Page, Runtime} = protocol;
  await Promise.all([Page.enable(), Runtime.enable()]);
  Page.navigate({url: 'https://www.github.com/'});
  await Page.loadEventFired(
      console.log("start")
  );
  const {data} = await Page.captureScreenshot();
  fs.writeFileSync('example.png', Buffer.from(data, 'base64'));
  // Wait for window.onload before doing stuff.  
   protocol.close();
   chrome.kill(); // Kill Chrome.

再来看看 puppeteer

const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://www.github.com');
await page.screenshot({path: 'example.png'});
await browser.close();
})();

对,就是这么简短明了,更接近自然语言。没有callback,几行代码就能搞定我们所需的一切。

总结

目前Headless Chrome仍然存在一些问题,还需要不断完善,我们应该拥抱变化,适应它,让它给我们的工作带来更多帮助。


更多精彩洞见,请关注微信公众号:思特沃克

Share

技术雷达——科技宏观趋势

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业技术趋势的报告。是ThoughtWorks对工具、技术、编程语言和平台的详细解读,我们通常会引入一百余个技术条目。编写技术雷达需要与来自ThoughtWorks全球各个办公室的资深技术专家进行深入沟通,在讨论个别现象的过程中,我们也会谈及宏观趋势。本文汇集了我们眼中当前科技行业的大趋势,以飨读者。

区块链不仅仅是炒作

在本文编写之时,一枚比特币的市值已经突破一万美元大关,从年初至今已经翻了十倍。而埃隆·马斯克明确否认自己是中本聪本尊,中本聪是比特币的神秘发行人。比特币炒作带火了加密货币这个混乱的市场,同时名人效应带来的ICO投机也是风生水起,这引发了加密货币存在“巨大泡沫”的担忧。不过在这种过山车式的疯狂炒作下,也孕育了一些很有价值的技术。

我们的许多客户都在试图建立一个运用区块链的分布式账本和智能合约,一些雷达条目显示,区块链相关技术已经趋于成熟,使用多种技术和编程语言实施智能合约的有效方法越来越多。区块链会解决两大问题。首先,这种技术可以让我们摆脱对“大家共同信赖”中间人(如银行或者股票交易所)的依赖,建立分布式信任机制;其次,区块链可以让我们创建一个共享式、不可更改的的可信的账本——是对事实的记录。如今,我们已经见证了基于这两个核心理念的组织的诞生。其中,我们认为以太坊智能合约和Corda分布式账本技术值得持续关注。

企业内部署(on-premise)软件风光不再?

谈及基础设施和部署,暂且把我们的沟通对象变成我们的每一个客户。在组织开始考虑配置服务器、安装软件,并且对软件进行后续打补丁和维护等动作时,第一个问题是“有我可以购买的定制服务吗?”,然后是“我可以从云服务供应商买什么来构建我的云服务?”这个决策流程可以总结为“最后考虑企业内部署(on-premise)软件”。曾几何时,人们在使用云服务时会研究多时;而今使用on-premise式服务时人们才会非常谨慎。过去一年来,云端托管已经成为大家非常感兴趣的话题。

雷达报告中再次印证了这个趋势——本文中谈及的许多工具、技术和平台要么是云服务辅助,要么支持云端服务。我们切实见证了许多组织“默认上云”的趋势,我们这里提到“企业内部署”,但是重点不是服务器在哪里,而是高效获得一项服务或功能,并长期保证其运行和维护所需要的工作量。

虚拟化的“长尾效应”

早在1999年我们开始使用Vmware的虚拟机时,并没有预料到虚拟化将会给软件带来全方位的变革。虚拟机如今已成为软件行业各个环节的必选,无论是开发者工作站还是谷歌这个体量的数据中心,而且虚拟机也是许多系统的“扩展单元”(除非你是谷歌,在谷歌数据中心本身就是扩展单元!)。Docker、Kubernetes以及当前所有重量级云技术都是基于虚拟化来实现的。

虚拟化促成了云服务的繁荣,我们认为,在NIST定义中的云极具价值。NIST的五个“基本特征”中,我们认为两个特征——按需自助服务和弹性——是云服务能够获得宠爱的绝对关键要素。选择云服务时,还有三个特征,而这些优势正是许多“私有云”产品所无法比拟的。

同等特性(feature parity)的误导

我们发现目前科技行业呈现出一种不良趋势,即在实施云迁移、遗留系统升级或产品再开发时以“同等特性(feature parity)”为目标。将一套运行时间达十年或十五年的老系统单纯用新技术重新部署,且不论程序缺陷等等,这绝非好主意。常用的借口是“我们不想给企业带来困扰”,或是担心改变流程或计算,但结果常常是交付遥遥无期、进展缓慢、一次性交付,还潜藏各种风险。在发现项目延期、预算大幅超支且不能给企业带来任何新的利益时,利益相关者往往大失所望。

这些教训值得我们反思。我们认为IT领导者(和企业)应当大胆质疑十年前编写的逻辑能否代表当今企业的运行方式,要相信用户有能力采纳(整体更强大的)新系统。企业应当深入研究自己真正需要的功能,而不是在新平台上重建一套功能完备的特性集。关于如何为云服务重写敏捷项目管理工具Mingle本期技术雷达进行了更多深入的探讨。

中国正在开源世界中崛起

我们发现中国的开源项目在数量和质量上均呈跳跃式增长。百度和阿里巴巴等大企业已经发布自己的开源代码,令全球为之瞩目。在过去的几年里,中国公司对开源代码的认知悄然转变。以前出于保护知识产权的忧虑,不愿意开源。而现在他们看到了Docker、Kubernetes和OpenStack等大型项目的影响力,认识到建立一套生态系统是比闭关更好的选择。只要保持对开源社区的影响力,他们就可以掌握其IP的控制权,同时享受开源的福利。

另外一个因素是中国与发达国家的市场有很大不同,具有独特的文化和视角,由此产生的期望与要求也有所不同,所以中国企业并不一定需要亦步亦趋地追随西方企业的脚步。中国市场的体量巨大,中国企业正在创建、分享开源代码,开发自己特有的软件和生态系统,从而解决中国特有的问题。

本期技术雷达中,我们重点介绍了阿里巴巴的两大项目AtlasBeehive,可以更好地实现应用程序模块化,有助于分布式或者远程团队协作。借此你可以动态地将物理隔离模块统一装配到单个应用程序中,其具体设计显然考虑到了中国软件市场的情况。

值得注意的是,中国的开源代码首先是为中国编写的,因此不用走出国门就能取得巨大成功。文档将使用中文撰写,如果一个项目进行得足够顺利,后续可能创建翻译版本。中国涌现了一些质量很高的软件,而且非常实用,但需要注意的是其主要受众是中国市场。

Kubernetes统领容器管理生态

一年前,身在ThoughtWorks的我们曾被问道“你们偏爱哪一种容器管理平台,Kubernetes还是Mesos?”如今,这个问题的答案已经不言而喻。Kubernetes俨然已是事实上的默认标准。这是为什么呢?我们认为是各种因素作用下的综合结果。

容器化趋势已经建立了一套生态系统,我们所有的工具都可以在该生态系统内与容器协作(而且经常需要容器),Docker在这一点上尤为突出。在某种程度上,容器就是新POSIX、新通用接口。IT行业在创建软件组件上付出了多年的努力,看来容器可能是目前最好的标准化方式。(然而,因为一个容器里可以插入任何内容,所以目前尚无法保证组件可以很好地共同运行。)微服务、演化架构、默认云等其他重要科技趋势与容器的协作极好,因此也存在自然的共生关系。

几年前,科技行业主要参与者还在探讨GIFFEE——谷歌提供的针对其他所有人的基础架构。“GIFEE”的话题才刚开始,Kubernetes基本已经成了所有人都能用的谷歌式基础架构。谷歌努力推进项目,投入了大量资源,希望把人们吸引到谷歌云产品上。随着时间的推移,Kubernetes已经成了我们与供应商和云提供商打交道的默认容器平台。

除此之外,Kubernetes还进化得更易于大规模运行。经过对Kubernetes核心软件的改进,借助更好的工具和高度活跃的生态系统,运行弹性生产集群的学习曲线已经不再那么陡峭。现在所有主要云提供商都提供基于Kubernetes的托管,所以进入门槛很低。

数据流即是标准

本期技术雷达中,我们探讨了一系列与Kafka相关的问题:Kafka、Kafka Streams、Kafka作为正确数据之源、Kafka作为轻量级ESB。然而我们为什么要强调数据流?

全世界都渴望实时分析。事实上,设计系统时我们必须做出调整适应。我们喜欢基于事件的流式架构所带来的福利——松散耦合、自主组件、高性能和高扩展性——但分析要求推动了对数据流的要求。离开数据流便无法实现实时分析。

与数据流兴起相关的是事件驱动架构的成熟度。人们对这些系统已然司空见惯,也很好理解了。有些新技术还在涌现,例如用数据流作为企业事实/状态的持久化存储。我们并非百分百确定所有这些技术都是好主意(CQRS已经坑了许多不设戒备心的人),但数据流已深入人心,这一点毋庸置疑。

Share

2017年11月期技术雷达正式发布!

技术雷达是由 ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出的最新技术趋势报告,它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议,为从程序员到CIO/CTO的利益相关者提供参考。

技术雷达的内容来自于 ThoughtWorks 的观察、对话以及在应对最令客户棘手的业务挑战时所沉淀下的一线经验,其中既包含现有技术,也包含新兴技术。技术雷达报告使用可视化的方式将技术趋势分为四组,分别涵盖技术、平台、工具和语言与框架,每个领域又进一步细分为暂缓、评估、试验或采用。


本期四大主题

崛起的中国开源软件市场

星星之火,已成燎原之势!在态度和政策发生转变之后,包括阿里巴巴和百度在内的众多大型中国企业正在积极发布开源框架、工具和平台。中国软件生态正伴随着经济扩张而加速成长。从这个巨大而繁荣的软件市场向 GitHub 等开源网站发布的开源项目的数量必将持续增多,质量也将持续提高。中国企业为何热衷于将他们的众多资产开源出来?与硅谷等其他活跃的软件市场一样,各个企业对开发人员的争夺十分激烈。紧紧提升薪酬水平是不够的,让聪明的开发者一起在最前沿的开源软件上共事才能够持续激励他们,这是一个放之四海而皆准的通则。我们预期主要的开源创意会继续保持 README 文件中先有中文版后有英文版的趋势。

容器编排首选Kubernetes

Kubernetes 及其在许多项目中逐渐增强的主导性推动了大量雷达条目的更新,以及更多的讨论。似乎软件开发生态系统正在 Kubernetes 及其相关工具的周边稳定发展,以解决有关部署、规模化和容器操作这些常见问题。诸如 GKE,Kops 和 Sonobuoy 这些雷达条目提供了托管平台服务和工具,以改善采用和运行 Kubernetes 的整体体验。事实上,它具备用一个调度单元来运行多个容器的能力,可以让服务网格(service mesh)和能够实现端点安全的 sidecar 得以实现。 Kubernetes已经成为容器的默认操作系统——许多云提供商已经利用其开放的模块化架构来采用和运行Kubernetes,而它的工具则可以利用其自身开放的API来访问诸如负载、集群、配置和存储等功能。我们看到更多的产品正在把Kubernetes作为一个生态系统来使用,使其成为继微服务和容器之后的下一个抽象层次。更多迹象表明,尽管面临分布式系统固有的复杂性,开发人员仍然可以成功地驾驭现代的架构风格。

成为新常态的云技术

本期技术雷达讨论中的另一个普遍性话题,无疑是近期的“多云”天气。 随着云提供商的技术能力越来越强大,且可以提供同样好用的功能,公有云正在成为许多组织中新的默认选择。当启动新项目时,许多公司已经不再问“为什么放在云端?”,而是问“为什么不放在云端?”。 诚然,某些类型的软件仍然要在公司内部私有地部署,但随着价格的下降和功能的扩展,云原生(cloud-native)开发的可行性越来越高。尽管主要的云解决方案提供商提供的基本功能都很相似,但它们也都提供了一些独特的产品特性,以针对特定类型的解决方案来实现差异化。因此,我们看到一些公司通过“多云”(Polycloud)策略来同时使用几个不同的云提供商,从中分别挑选最能满足其客户需求的平台专业能力。

各方对区块链的信任稳步增强

尽管加密货币市场仍然处于混沌状态,我们的许多客户已经开始尝试利用基于区块链的解决方案来处理分布式账本和智能合约的需求。雷达中的一些条目展示了区块链相关技术运用的成熟度,它们使用各种新技术和编程语言并以一些有趣的方式来实现智能合约。区块链解决了“分布式信任”与“共享且不可篡改的账本”这些老大难问题。如今,许多公司正致力于增强其用户对将区块链作为系统的底层实现机制的信心。许多行业存在着明显的“分布式信任”问题,我们期待区块链技术能持续找出解决这些问题的方法。


部分亮点预览

技术篇:

DesignOps:受DevOps运动的启发,包含一系列实践和文化转变的DesignOps横空出世。它可以帮助组织不断重新设计产品,而不在质量、服务一致性和团队的自主性上妥协。 DesignOps提倡创建并不断演进设计的基础,最大限度降低创造新的UI概念及其变体的工作量,并与最终用户建立快速可靠的反馈机制。使用DesignOps,设计正在从一种具体的实践演变成每个人工作内容的一部分。

Chaos Engineering:在早期的技术雷达中,我们讨论了Netflix的Chaos Monkey。Chaos Monkey可以随机终止生产系统中的运行实例,并对结果进行度量,从而帮助验证系统在运行时对生产中断的应对能力。今天,人们有了一个新兴术语来描述这一技术的广泛应用:混沌工程。在生产环境的分布式系统中运行这些实验,可以帮助我们建立系统在动荡环境下依旧能够按预期工作的信心。如果想要更好地理解这个技术方向,请参阅混沌工程原理。

Service Mesh:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐。服务啮合在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程,这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例),我们可以获得服务的互操作性和可观测性。一段时间以来,我们一直主张去中心化的微服务管理方法,也很高兴看到服务啮合这种一致性模式的出现。随着 linkerd 和 Istio 等开源项目的成熟,服务啮合的实现将更加容易。

平台篇:

TensorFlow Serving:机器学习模型已经开始渗入到日常的商业应用中。 当有足够的训练数据可用时,这些算法可以解决那些以前可能需要复杂的统计模型或试探法的问题。 随着机器学习从试验性使用转向生产环境,需要一种可靠的方式来托管和部署这些可远程访问的模型,并能随着消费者数量的增加而进行扩展。TensorFlow Serving 通过将远程gRPC接口暴露给一个被导出来的模型,解决了上述部分问题。这允许以多种方式部署训练完成的模型。TensorFlow Serving 也接受一系列的模型来整合持续的训练更新。其作者维护了一个Dockerfile来简化部署过程。 据推测,gRPC 的选择应与 TensorFlow 执行模型保持一致。 但是,我们通常都会对需要代码生成和本地绑定的协议保持警惕。

LoRaWAN:LoRaWAN是一种低功耗广域网,专为低功耗、远距离和低比特率的通信场景而设计。它提供了边缘设备与网关设备之间的通信能力,能够通过后者将数据转发至应用程序或者后台服务。LoRaWAN通常用于分布式传感器组或物联网这些必须具备长电池寿命和远距离通信能力特点的设备上。它解决了在使用一般的WiFi进行低功耗广域网通信时的两个关键问题:通信距离和功耗。LoRaWAN已有若干实现,其中值得注意的是一个免费的开源实现——The Things Network。

Language Server Protocol:那些大型 IDE 的威力很大程度上源于利用源代码分析出的抽象语法树(AST)来进一步分析和操作源代码的能力,比如代码补全,调用分析和重构。语言服务器将这种能力提取到单独的进程中,从而让任意文本编辑器都可以通过 API 来使用 AST。微软从他们的 OmniSharp 和 TypeScript 服务器项目中,提炼并引领了”语言服务器协议”(Language Server Protocol, LSP)的拟定。编辑器只要使用 LSP 协议就可用于任何具备 LSP 兼容服务器的编程语言。这意味着我们可以继续使用自己喜爱的编辑器,同时也不必放弃各种编程语言的高级编辑功能——这对于很多 Emacs 瘾君子来说尤其利好。

工具篇:

Gopass:gopass是一个基于GPG和Git的团队密码管理解决方案。它的前身是pass,并在此基础上增加了诸如多用户密码管理、层级式密码存储、交互式查找、基于时间的一次性密码(TOTP),以及二进制存储格式等功能。由于它的存储格式与pass基本兼容,因此可以直接从pass迁移过来。这意味着只需调用一次存储密钥就能将其集成到迁移的整备工作流中。

Jupyter:过去几年间,我们注意到分析笔记本应用(analytics notebooks)的流行度在持续上升。这些应用都是从 Mathematica 应用中获得灵感,能够将文本、数据可视化和代码活灵活现地融入到一个具备计算能力的文档中。在上个版本的技术雷达中我们所提到的基于Clojure 的GorillaREPL,就属于此类工具。但随着人们对机器学习的兴趣不断增加,以及该领域中的从业者们逐渐将Python作为首选编程语言,大家开始集中关注Python分析笔记本了。其中 Jupyter 看起来在ThougthWorks团队中格外引入注目。

Rendertron:JavaScript Web 富应用的一个老问题是如何使这些页面的动态渲染部分可供搜索引擎检索。为此开发人员采用了各种各样的技巧,包括使用 React.js 的服务端渲染,外部服务或预渲染内容。现在谷歌 Chrome 新的 headless 模式又贡献了一个新的技巧—— Rendertron,即 Chrome的headless 渲染解决方案。它在一个 Docker 容器中封装了一个 headless 的 Chrome 实例,可以作为独立的HTTP服务器来部署。无法渲染JavaScript的爬虫机器人可以被路由到此服务器来进行渲染。 虽然开发人员也可以部署自己的 headless Chrome代理并配置相关的路由机制,但 Rendertron 简化了配置和部署过程,并提供了令爬虫机器人进行检测和路由的中间件示例代码。

语言&框架:

Gobot:Go语言能够被编译为裸片上运行的目标程序,这使得嵌入式系统开发领域对它的兴趣与日俱增 。GoBot是一个用于机器人、物理计算和物联网(IoT)的框架,它基于Go语言编写,并且支持多个平台。我们在一个对实时性响应没有要求的实验性机器人项目中使用了GoBot,并且用GoBot创建了开源的软件驱动。GoBot的HTTP API使其与移动设备的集成十分容易,从而能创建更丰富的应用。

Solidity:智能合约编程需要一种比交易处理脚本更具表现力的语言。在众多为智能合约设计的新编程语言中,Solidity是最受欢迎的。这是一种面向合约的静态类型语言,其语法类似于JavaScript。 它抽象了智能合约中自我实现的业务逻辑。围绕Solidity的工具链也在快速成长。如今,Solidity是Ethereum平台的首选编程语言。

CSS-in-JS:CSS-in-JS是一种用JavaScript编写CSS样式的技术,通过鼓励采用一种通用模式,编写样式以及应用样式的JavaScript组件,使样式和逻辑的关注点得到统一。该领域中的新秀——诸如JSS,emotion和styled-components,依靠工具来将CSS-in-JS代码转化成独立的CSS样式表,从而适合在浏览器里运行。这是在JavaScript中编写CSS的第二代方法,与以前的方法不同,它不依赖于内联样式,这意味着它能支持所有CSS特性,使用npm生态共享CSS以及跨平台使用组件。我们的团队发现styled-components很适合像React.js这样基于组件的框架,并且可以使用jest-styled-components做CSS的单元测试。这是个新兴的领域且变化迅速。用该方法时,在浏览器里人工调试生成的class名称会需要费些功夫,并且可能不适用于那些前端架构不支持重用组件并需要全局样式的项目。

以上是我们在最新一卷技术雷达中随机摘取的几个Blips,欲获取整版技术雷达,请点击这里

Share

技术雷达是如何创建的?

ThoughtWorks一年发布两次技术雷达,在每次雷达的准备期,TAB(ThoughtWorks技术顾问委员会)成员都会全力以赴的投入其中,以至连睡觉都会变成一件奢侈的事情。

言归正传,到目前为止我已经参与了几次技术雷达的构建。在这之前我曾疑惑于一个问题——“技术雷达是如何建立的?”这也是如今我常常被他人询问的问题,在本篇文章中,我将从内部人员的视角就技术雷达的产生机制、准备方式和决策方式给予一些介绍。文章从一次为期四天的会议开始。

第一天

为了制定下一期技术雷达,来自全球的ThoughtWorks TAB成员一大早就汇集在了一起。每次我们都会从四个办事处中选择一处碰面——这次我们定在了去年刚成立的巴塞罗那办事处。如果你觉得初来乍到和时差问题会拖慢进程,那就错了。团队一旦聚在一起,稍作提神后,立马就投入战斗了。

首先给大家介绍一下我们的技术顾问委员会,它是由来自全球的ThoughtWorks资深技术人员组成的,其中包括首席科学家Martin Fowler。此次线下会议由我们的全球CTO Rebecca Parsons主持。

开始的第一天,技术顾问委员会的每一位成员都准备了不少他们认为可以纳入下一期雷达的想法——也就是我们在技术雷达中看到的具体条目。

这次在巴塞罗那,团队要对180个备选条目进行投票表决。这就意味着要达成共识,大家需要进行审慎的考虑和热烈的讨论。

候选条目按雷达象限(技术、工具、平台、语言与框架)归类,再分为几个环(暂缓、评估、试验和采用)。这便于提醒我们每个环所表示的意思,有助于决定条目的归属范畴。

  • 暂缓。这一环包含我们认为客户应当放弃或者需要等待时机成熟的条目。
  • 评估。我们认为有希望且值得研究一番的事物。
  • 试验。强烈推荐的技术,仅当我们预见能成功部署于生产时,才会将条目归于这一环——非常罕见的情况除外。
  • 采用。对于特定应用情形,我们认为这是唯一最好的方案。

为了确定最终能够登上本期雷达的100个条目,我们每次分析一个象限,每个象限从采用到暂缓由内而外地进行。条目的推荐人负责向团队进行介绍,然后展开讨论和表决。每个人有三张不同颜色的牌子:绿色表示“是,我希望将其纳入雷达”;红色表示“不,不可能将其纳入雷达”;黄色则表示他们有疑问或意见。这四天会议上将大量用到这些牌子。

红牌用完后,用橙牌表示新的红牌。

这次我们从技术象限开始——不仅因为这是我最喜欢的方式,也因为这样讨论将更加细致。如此一来,下一期技术雷达就有了起点。

第二天

直到第二天凌晨,雷达墙才略微显露出一些秩序——但区别也不是很大。一名团队成员负责逐一检查雷达墙,而我则负责确保跟踪所有决定——到后来几乎不可能记住所有的东西。检查雷达墙时,他们明确我们下一步即将探讨的提议,并将便利贴移到团队表决的位置。有些情况下,要将便利贴置于指定的环内——但后来可能移到其他环或象限,或者完全遭到拒绝。

偶尔我们会遇到一些条目,迸发激烈的争论,甚至会由于一些细微差别而陷入僵局。这些问题我们视为“太过复杂而无法成为条目”——这并不表示它们会被抛诸脑后;这些问题仍然很重要而且值得注意。只是不适合在技术雷达上探讨。

有这么多条目需要讨论和表决,让讨论继续进行才是关键。Rebecca负责监督程序的进展。介绍条目时,她会留意黄牌的出现,并告诉团队下一个发表意见或提问的人是谁。期间没有人会插嘴。每个人必须在轮到自己的时候才能发言。

第一轮表决进度很快。先介绍条目,再快速讨论,最后表决。这里有一个棘手的问题。已经有一些人发表了一些意见,但团队里仍有不少人举黄牌。为了保持程序正常进行,Rebecca拟制了发表意见的名单并提示我们:“乔尼发言后开始表决。”

表决票数经常比较接近,所以要一直举着牌直至统计完所有绿/红牌。当有黄牌出现时,讨论继续。达成决定后,进入下一步。这里不掺杂任何个人因素,我们进行地很快。

第三天

到了第三天,我们基本已经完成了新条目最主要的部分。但离完成还相差甚远。从许多方面而言,艰难的工作才刚开始。

之前,每一次表决都将决定是否将某个新条目纳入雷达。现在,我们得回顾上一期雷达的条目,加起来通常会有100个左右。他们是否仍然关系重大?哪些应当去掉?哪些条目需要重写?如果我们对一个条目的看法连续两期雷达都没有发生改变,就让其“淡出”。因为还有很多有趣的事情值得探讨!有些时候,为了腾出雷达空间,我们必须强制淡出一些条目——即提前删除这些条目。

即便如此,我们还有大量的条目。现在的讨论就变得激烈了。技术雷达诞生于全球充满热情的技术人员所组成的ThoughtsWorks社区。它基于我们的客户工作经验。我们认为这是我们的优势之一。但只要大家对技术怀抱热情,难免会存在异议。我们的雷达讨论也不例外。

接下来,我们检查所有人一致同意理应纳入雷达但不如其他条目价值高的条目。这种剔除过程非常艰难,好几次我们不得不停下来问自己:团队有没有什么建议?如果团队对某个条目没有明确的建议或一致的意见,那这个条目便不会被纳入雷达。

第四天

连续三天的讨论——除了雷达,偶尔下班消遣时也会与同事互动,挑起技术谈话——大伤元气。现在会议室里几乎每个人都很疲惫了,但仍需进行最后调整,落实到位。

为了确保在计划时间内结束,我们采用了许多方式。例如,Rebecca确保不让讨论无休止地继续。我们也明白有时候个别人会不同意团队的决定。这时候,有一个可以改变团队的决定机会——我们称之为救生艇。一旦雷达基本落实到位,各技术顾问委员会成员可选择一个条目恢复——但他们必须说服团队该条目值得纳入雷达。或者说服大部分人即可,无需所有人一致同意。

最后,只有所有人尊重其他人的意见时,会议才能顺利开展。Rebecca协调会议时确保所有人都具有发言权,能表达自己的想法、经验和关注点。看到一群热情的人以相互尊重的方式表达有力的观点,展开高质量的讨论,这是令人高兴的事。所以即使团队出现分裂,表决票数相当,我们也能进入下一轮讨论。

到第四天结束时,我们对雷达的内容做出了最终决定。每次参加技术雷达会议,现场的讨论都令我折服——有幸参加会议让我深感荣耀,我一直惊叹于大家的技术意见、意见产生的过程、意见的评估方式以及团队谈论的各种背景。

这仅仅是雷达建立过程的起点。随后我们必须详细编写每一个条目、讨论产生的主题及主要报告。敬请期待——新一期雷达将于11.30日与你见面!点击这里提前订阅。

Share