无障碍性测试工具 Pa11y

2017.3 技术雷达 Trial

A11y(Accessibility)指的是用来帮助身心障碍者(残疾人)更加便利的使用先进技术的能力。目前世界上主要由各种人权组织和政府通过一些民间规则和政府规则来保障这方面权益。以Web Content为例,比较常见的规则有W3C组织在2008年出台的WCAG2.0,和美国国家标准的Section508等等。

这些规则数量比较多,涉及的检查范围从规定网页元素的颜色对比度,到元素的属性是否缺失等,内容十分丰富。对一个网站的内容进行完整的A11y检查,通常需要针对网站的每一个页面的每一个元素走查,这样的检查几乎是手工无法办到的。

Pa11y是基于HTML codeSinffer以及PhantomJS制作而成的网站内容A11y自动化检查工具。它利用PhantomJS的headless模式运行需要被测试的网站,然后把网页源文件和指定的规则(比如WCAG2AAA)做对比,自动检查出网页内容是否符合规范,同时会把检查结果输出成指定格式的报告。

ThoughtWorks技术雷达VOL.16将其放在试验阶段,鼓励大家对它进行尝试和使用。

Pa11y本身运行在node环境下,通过npm install安装。安装成功后,可以使用命令行来执行对目标网页的检查。同时它也支持从JavaScript直接调用。Pa11y工具支持选择WCAG2.0 A/AA/AAA标准和Section508标准,也支持忽略这些标准中某些特定的项。通过设置参数,还可以改变输出报告的格式,比如输出CSV或者HTML格式的报告。

对比之前需要在手动进入到网站的每个页面、点开每个隐藏元素,再把当前网页源代码拷进自动化工具的检查方式。Pa11y提供了Actions方式来自动化操作页面元素,使得网站操作和规则对比可以完全自动化进行。

另外和其他A11y测试工具相比,除了免费和开源之外,Pa11y还衍生出了许多不同目的的、基于核心工具Pa11y的Pa11y-X工具。比如支持并发多线测试和测试/生产环境隔离,而且可以存储每次执行结果的Pa11y-Webservice;又比如支持非技术用户使用、操作配置简单易懂、集成了Pa11y-Webserivce的前后端一体工具Pa11y-Dashboard(如下图)。

Pa11y-Dashboard还提供可视化图表,协助分析质量趋势。

另外,基于Pa11y这个核心工具还衍生出了专为CI准备和优化过的命令行工具Pa11y-CI等工具。 随着需求的增加,这个平台里面的工具也在Pa11y team的维护下逐渐增多,逐渐形成了一个A11y测试工具全家桶。

然而在目前的版本中,仍然有一些可以继续关注的地方,比如:

  1. 目前所支持的标准仅有WCAG2.0和Section508,将来是否会扩展新的规则支持方案。
  2. 2017年的WCAG2.1标准已经发布β版本,Pa11y应该如何做相应更新值得期待。
  3. 如何提升对不同浏览器的检查支持。
  4. 当前版本依赖的PhantomJS本身还有一些问题,例如对ES6的支持性不完等,如何使Pa11y在ES6开发的网站上完美运行善。

另外值得注意的是,由于Chrome59宣布开始支持Headless,PhantomJS2.x的主要开发者之一Vitaly Slobodin已经宣布不再继续开发新的功能。那么依赖PhantomJS的Pa11y是否也会迎来一次大的改版换“芯”成Chrome呢?


更多技术雷达信息,请点击这里

Share

技术雷达的安全实践

安全事故

2014年乌云网发布了某旅行网站(以下简称X网站)的安全支付漏洞,X网站因长时间打开支付服务调试接口,导致用户信用卡信息面临泄露风险;在针对其进行进一步的扫描后,乌云发现X网站的分站源代码可打包下载,其数据库配置和支付接口因此被直接泄露。

(图片来自:http://t.cn/Rt7siGq)

在X网站所泄漏的数据中,最引人关注的当属信用卡的CVV码。由于大量国外网站可以直接通过CVV码进行支付验证,用户直接面临盗刷的风险;X网站的行为也公然违反了《银联卡收单机构账户信息安全管理标准》:

各收单机构系统只能存储用于交易清分、差错处理所必需的最基本的账户信息,不得存储银行卡磁道信息、卡片验证码、个人标识代码(PIN)及卡片有效期。

混用测试环境与产品环境、明文记录用户敏感数据、违反相关技术标准、公网暴露数据库密码。X网站的安全事故对很多企业的IT部门都是警示,它提醒我们,随着互联网的发展,软件安全和信息安全不再是安装防火墙所能保障的,它需要企业从软件开发的第一分钟就开始关注安全并积极采取行动,把软件安全内建到研发过程中。

技术雷达的安全概念

技术雷达是ThoughtWorks的定期发表物,它包含了ThoughtWorks对于前沿技术和实践的观察与理解,是软件工程实践的风向标之一,在2016年4月期技术雷达中,与安全相关的技术与实践有13项,占到总数的13%(采用2项,实验5项,评估6项),从软件开发生命周期的角度去观察这十三项安全实践:

  • 分析阶段:1项
  • 开发阶段:8项
  • 测试阶段:2项
  • 运维阶段:2项

通过这个趋势我们可以观察到,软件的安全问题已经不仅仅存在于开发结束后,对于安全的管理已经开始贯穿软件开发的全生命周期,内建安全正在成为一种趋势。

如何理解安全实践

仅仅在项目启动的时候提出安全的要求,在项目结束前做渗透测试和审查,在现有的技术环境中已经不够了,X网站就是很好的反例。那么是不是越安全越好?

(图片来自:http://t.cn/R6Kkcag)

安全措施应该被看作是“必要的浪费”,关键是与商业目标做好平衡,我们认为其中的关键是安全问题从出现在代码/配置里到被发现之间的时间,即MTTD时间(Mean-Time-to-Detect),IT所追求的目标是将MTTD降到一个比较合理的水平, 且达到这一目标的成本是能够被开发团队所接受的。

基于这一理念,我们可以在软件开发流程的各个阶段内,在MTTD目标的牵引下,充分引入各种实践、工具、流程制度等等,不管表现形式是什么, 核心的目标都是在成本的限制下降低MTTD时间,我们看看从需求分析、开发、测试、运维几个阶段的角度入手,有哪些关于安全的工具、实践可以采用。

需求分析阶段

威胁建模,其主要目标是分析系统可能遭受的潜在攻击、识别出风险并制定应对措施。威胁建模提供了一系列技术,可以帮助团队在开发阶段就能够对潜在威胁进行识别和分类,其主要分为三步:

  • 解构应用:庖丁解牛般的解构软件,比如网络、用户数据存储、其它数据、应用层等,分析攻击者可能对哪些信息感兴趣以及他们最可能的侵入方式。
  • 分析风险:对于上述风险,在参考了攻击的可能性、损失和成本因素后,进行优先级排序。
  • 决定对策:对于高优先级的风险在软件开发的不同阶段采取不同的措施进行防范。

当然威胁建模只是安全战略的一部分,当它和其他技术(如建立跨团队的安全专家,采取自动化安全扫描器)结合使用时,威胁建模才可以真正减轻企业面临的安全风险。

开发阶段

Let’s Encrypt,早些年SSL Labs公布的2010年互联网SSL调查报告(PDF)指出超过半数的Web服务器没能正确使用证书,主要的问题有证书不被浏览器信任、证书和域名不匹配、证书过期、证书信任链没有正确配置、使用已知有缺陷的协议和算法等。而且证书过期后的续签和泄漏后的吊销仍需进行繁琐的人工操作。Let’s Encrypt就是为了解决这个痛点而诞生。它基于自动证书管理环境(Automated Certificate Management Environment),至少做到了两件事:免费发放证书自动化更新证书

(图片来自:http://t.cn/R6CoUXB)

Let’s Encrypt由ISRG(Internet Security Research Group,互联网安全研究小组)提供服务并得到了Mozilla、Cisco、Akamai、Electronic Frontier Foundation和Chrome等众多公司和机构的支持。从2015年12月开始,Let’s Encrypt项目从封闭测试阶段转向公开测试阶段,也就是说用户不再需要收到邀请才能使用它了,这促使安全和隐私向前进了一大步。

OWASP Dependency Check,堡垒最容易从内部攻破,现代软件开发少不了用到第三方的库和插件,这些库是否安全呢?OWASP Dependency-check就是一款自动识别Java和.Net项目中所使用的第三方库中是否有已知安全问题的软件,通过第三方插件,它也支持Ruby, Node.js, Python和C/C++。

HSTS,新的HTTP头,可以用于强制要求浏览器与系统之间采取HTTPS通信,目前新版浏览器都支持这一头文件,Internet Explorer从Windows10技术预览版开始支持。

iFrames for sandboxing,HTML5标准的一部分,在<iframe>标签中插入了sandbox属性,开发团队可以建立一种新的开发实践。通过将第三方的组件放到iframe里,并且使用iframe的sandbox属性,只给iframe开放最小的权限,避免第三方的组件访问主页面的信息(比如DOM)。

Content Security Policies,新的HTTP头,CSP的目的是减少跨站脚本攻击。比如通过指定Content-Security-Policy的default-src属性为‘self’,强制要求只能使用本站资源,避免恶意脚本在payload中加入恶意代码,下载和上传信息。CSP需要浏览器的支持。

(图片来自:http://t.cn/R69APfE)

Gitrob,用于检测是否有员工不小心把某些敏感信息放到了Github公开库里。目前Gitrob只支持Github的组织级帐号,并只能扫描最近一次提交。

HashiCorp Vault,微服务架构需要管理大量服务器和各种密钥(秘钥、API key、证书),“如何安全管理这些信息”逐渐成为项目的一大挑战。之前通过文件或者环境变量存储机密信息的方式已经变得难以控制。HashiCorp Vault就是用于解决这一问题的,它可以作为开发的一个最佳实践采用。

Repsheet,一个类似于防火墙的工具,下一代安全防护产品(作为第三方库,在应用的源代码里使用)。可以分析和可视化来自黑客的攻击流量,使之只对正常流量放行。

测试阶段

OWASP Application Security Verification Standard ProjectASVS是一个针对应用程序安全性的检查清单,目前包括了22篇实践,比如《不要在敏捷开发中忘记黑客用户》,官方认为它可以作为:

  • 清单:用于开发人员自查。
  • 原则:作为安全人员和开发人员的桥梁。
  • 采购标准:用于企业采购软件时进行技术打分的标准。

Sleepy Puppy,Netflix出品的一个用于追踪、分析、 管理跨站脚本攻击的工具, 测试人员也可以利用这个工具进行跨站脚本攻击的测试。

运维阶段

Linux security modules,一个框架,可以支持多种不同的安全框架

Deflect,对抗分布式、拒绝服务攻击的服务

2017技术雷达

互联网企业所采用业务模式往往是“以隐私换服务”,这间接促成了庞大的隐私黑产、伤害了个人的权益。2017年的技术雷达也体现了业界在隐私问题上的思考。本期雷达上,身份数据欧洲托管从“评估”进阶为了“尝试”,差分隐私开始进入雷达。

差分隐私,从源头抓起

在2016年的WWDC大会上,苹果宣布自己加入了AI大战,同时宣布了不会走Facebook和谷歌的道路,在对于用户数据的收集上采取了差分隐私技术,简单来说,差分隐私是通过算法对个体用户数据添加噪音,让任何人都不能凭此追踪到具体的某一名用户,但又可以允许机构成批分析数据以获得大规模的整体趋势。其目标是在保护用户身份和数据详情的同时,仍能提炼出一些基本信息用于机器学习。

差分隐私的实施也将影响软件架构,比如(部分)计算将重新回到本地(而非云端),(夜间)批量处理可能成为移动端的最佳实践。

身份数据托管,减少干预

由于互联网企业拥有的数据越来越多,政府也在通过各种渠道渗透互联网公司,试图获取数据的控制权,棱镜门所暴露的政府文件让全球都意识到了这个问题。而欧洲是对于PII数据管控最为严格、立法最为完善的区域。比如:

在这样的监管下,Amazon这样的巨头也不得不推出相关服务,以响应这样的监管措施。

在可行的情况下,尽量考虑通过欧洲的数据中心进行托管是进一步减少干扰、增强隐私的方法。


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

Share

从2016年11月期《技术雷达》看前端的未来

本文仅代表作者个人观点,来听听一个前端程序员的YY。

新一期的技术雷达有点出乎意料,使用new标签的框架、工具、技术、语言等等超过了一半——Vue.js、ES2017上榜,Three.js凭着VR的火又上榜了,还有熟悉的Electron,以及微前端的概念。

让我们先看看一些技术亮点。

前端在可见的未来

在那篇《最流行的编程语言JavaScript能做什么?》的文章里,我们看到了JavaScript在各个领域的应用。在这一期里,仍然有很多亮点(new):

Vue.js

Vue.js,如果你在使用Vue.js,那么你应该更加自信了,现在它已经被列入评估期。Vue.js是一个简单易上手的框架,并且相当的轻量,在最近的这段时间里,它发挥的相当的出色。

可惜,笔者现在在用Angular.js 和 Angular 2,毕竟我现在的所做的事情是开发混合应用。不过相信在半年后,Angular 2 和 Ionic 2是会上榜的。

Ember.js,我现在对这个框架还缺乏深入的了解,而且还没有证据表明它会在国内火起来。

ECMAScript 2017,尽管我现在已经倾向于使用TypeScript,不过ES2017还是会用到的,只是我觉得Babel对我来说就是个坑。

PWA

Electron,我在很多场合中都使用过这个框架,从NodeWebkit开始写编辑器,再到用Electron完成Growth 1.0的桌面版。

Physical Web,现在我们可以通过蓝牙低功耗技术在浏览器上控制真实世界。

不过与此相比,我更看好 Progressive Web App,毕竟他可以让Web应用接触到更多的底层API,而不是局限于蓝牙,还可以是Push Notification等等。

VR

Three.js,它上榜的原因是WebVR的流行。这一点可以从我去年写的那篇《Oculus + Node.js + Three.js 打造VR世界》中可以看到一些趋势。这些就和现在的单页面应用一样,虽然运行起来不是那么流畅,但还是行得通。因而在可见的未来使用Web技术来开发VR也有一点苗头,未来浏览器上应该是可以运行编译过后的代码,而不是在运行时。

WebRTC,它可以让我们在浏览器端实现实时视频聊天。第一次接触到这个视频流技术是在两年多以前,上一次接触则是在半年多以前使用WebRTC + Oculus,你可以在我博客的那篇《JavaScript在VR世界的应用》中了解到更多的详细信息。当然如雷达所说,WebRTC将会形成未来在Web上进行AR/VR协作的基础。

接着再让我们看看一些架构上的变化吧。

前端引起的架构变化

在过去的两三年里,前端火得一塌糊涂——对于后端程序员来说,这有点winter is coming 的感觉。我在那篇《前端演进史》对前端的演进做了相当多的介绍,并在《后台即服务演进史》里对”后台即服务”开了个头,在这篇文章里让我们根据《技术雷达》来继续补几刀。

前后端分离

我们可以看到,很多中大型团队已经分解为前端和后台两个小组,沟通可以通过接口、契约等方式来进行。但是这一点儿也不精益,沟通在这时仍然是一个问题,让我有点怀念起之前前、后端都做的项目了——自己可以创建自己想要的接口。

不过,这意味着前端和后台在技术选型上更加独立了。

臃肿的前端——微前端

前端单体应用

在上一个项目里,我们一步步地将一个有近10年历史的系统替换掉。起初这是一个传统的Spring + JSP网站,然后我们用JSP创建了JSON API,后来创建了一个新的API来服务移动应用和单页面应用,再后来这个API被拆分成了几个API。我们的后台已经从一个单体应用变成了一个微服务架构的应用,但是这一点并没有在前端上应用——前端应用正在变得难以维护。

因此在这一期的雷达里,你可以看到微前端的概念(micro frontends)。这也是在上一个项目里,我们尝试做的一部分,遗憾的是并没有完全成功实施。这是一个搜索类型的网站,网站的首页承担着大部分的访问量,而详情页的主要流量来源则是搜索引擎。我们在首页上使用jQuery + Require.js技术栈,而在其他页面(搜索结果页 + 详情页)使用 React.js,我们在最初的时候考虑过将详情页静态化——因为需要SEO的缘故,这样可以让我们降低SEO带来的复杂度。

MicroServices

后来,我也在我的博客上解耦了两部分,为了更快的访问首页——将首页独立出来,不使用JS,直接使用Pure.css来担重任;在其他页面里使用Material Design Lite作为UI部分。

有一点值得考虑的是:对于微服务架构来说,在一个系统的不同部分使用不同的技术栈是一种不错的体验;而对于一个前端团队来说,在同一个系统中使用不同的技术栈就不是一种不错的体验。

API设计——应该变得简单

Backend

如我们所见的Spring Boot已经变成推荐采用的程度了,按雷达上的习惯用语:“我们已经在多个项目上使用这个框架”——反正我最近的项目都是用这个框架。如果你考虑使用 Java,那么一定不要错过这个框架,以及使用这个框架来实施前后端分享。

对于大部分不需要考虑SEO的应用来说,将后台变成一系列RESTful的API并不是一件复杂的事,但是在后台API上的设计就变成一件麻烦的事。因此尽管在实践的过程中有契约作为保证,但是不一定是可靠的。作为一个前端程序来说,我们在调用后台API的过程中,总会遇到这样、那样的问题。除此,还有接口不好用的问题——“要是你可以在这里使用超媒体API,那么我的代码就会更加简单了”。

因此在 API 设计上,雷达上给出了两个不错的案例:

强化后台查询

GraphQL

代表例子就是Facebook的GraphQL,它是在Facebook内部应用多年的一套数据查询语言和 runtime。原本为了请求一个用户及其好友信息,需要发起多个API请求。现在,我们只需要在客户端拼装好对应的Query语句,在这个语句里将大部分需要查询的东西写好,即 JSON格式的数据,然后发给服务端来处理。而在我们客户端上,我们所获取到的结果都是我们所需要的,不需要再做特殊处理了。

这一切,看上去很美好——除了,在客户端上拼查询语句。

过去,我们使用搜索引擎来搜索数据,就需要在前端拼好对应的Query,再传给后台API,由后台API返回我们需要的结果。在这个过程里,我们在Query做一些对应的数据处理。

反正,他们都是使用查询语言来搜索结果。如果你考虑使用QL的话,不妨做一层Wrapper,以后好做迁移。

前后端同时优化

Falcor

Netflix在这样复杂的API请求下,创建了自己的库Falcor——它可以从多个数据源获取数据,并在服务端上汇总成一个JSON model;在客户端上,请求时我们只需要加上对应的参数即可——可以将多个请求合并到一起,也可以只针对某一个部分发出请求。这样可以降低发出多个请求所带来的复杂度。

我想,一种最实用的做法:就是将一些更新频率较低的API合并成一个大的API(大部分人都会这样做吧)。

简化的后台——无服务器架构

ServerLess

除了上面的这些内容,后台还有一些东西蛮好玩的,其中一个就是Serverless架构,即无服务器架构。不过,这种架构目前在国内运行起来还是有点难度的,缺少一系列的配套措施。如在这期的雷达上,Auth0可以为我们提供一个授权服务,以及AWS Lambda可以直接使用 AWS系列云服务来对数据进行处理。

关于这期技术雷达我就不多说了,读者可以自己去看。点击原文就可以获取最新一期ThoughtWorks技术雷达。

那么未来,你想玩哪种技术。

Share

技术行业的宏观趋势

我们每半年发布一次技术雷达:它是所有我们认为横跨业界当下和将来的相关重要技术的快照。我们从世界各地召集了约20位最有资历的技术人来编写技术雷达,这也是一个用全球视角对比趋势和方向的绝佳机会。我们在技术雷达上总结出了主要的潮流,但这其中的奥妙足以再专门写一篇长文章。在此,我们将关注于技术雷达中未能覆盖到的一些宏观趋势。

1-macro-trends

强大的团队和商业

开拓新业务所需要的不仅仅是好软件。

开源软件现在出现了大爆炸式的集中发布,其中有一些公司公开了那些你可能认为是专属或有竞争优势的软件。比如,谷歌的TensorFlow深度学习工具包Netflix的整体产品栈

乍一想这似乎是个糟糕的主意:竞争对手可能用这些代码一步登先,然后进行竞争。但Google真正的’秘密武器’不是软件,而是软件中的数据。对于Netflix,其云规模不(再)是竞争性优势,真正的优势在于他们的原始内容、有许可的交易和品牌力量。

这些都是著名的利用软件与技术促使企业变强变大的例子,但这不是企业成功的真正原因。我们看到很多赢家通过关注“产品思维”来创建优秀的体验,同时吸引和保留优秀的员工来打造他们的产品。在这种情况下,开源软件更多的被用于招聘和增加名誉,公司即便将软件免费赠送,也可以保持自己的市场领导地位。

2-team

自治团队赢得全栈控制权。

在过去的几年里,我们看到了“谁创建,谁运行”的敏捷团队的崛起:由同一批人来创建、发布软件,并为之做产品支持。我们是这种方式的拥护者,最起码做产品支持能够让人成为一个更优秀的开发者

这种趋势在逐渐扩大,我们能够看到团队的控制权越来越深入,选择PaaS,然后在此基础上部署、运行他们的(通常是基于云的)负载以及运行测试工具、监控工具和安全工具。这是一个好的趋势,但最终,企业环境中需要一些标准化。我们喜欢Spotify的方式允许团队创新,然后寻求最佳解决方案——这是一个处在创新和高效之间不错的平衡。

开源是高尚的副产品。

开源软件中的创新比以往发生得都更加迅速。之前我们提到了Google和Netflix发布开源代码库,但是如果你在搜索引擎中敲入“开源”+公司名称,你很有可能找到满满一页都在讲述该公司对于开源软件贡献页面。公司投资于开源软件有两大原因。

第一个是获取有天赋的人:随着技术越来越强力地驱动着商业和社会,能否寻找最具天赋的人才是成功的关键要素。但是作为一个技术人员,搞清楚自己是否真的想要为某个公司工作是困难的——面试过程和实际工作之间有巨大的差异。开源软件能够帮助候选人通过查看该公司产生的代码质量,来对一个组织获得更深的理解,也能帮助公司为潜在新成员展示其技术文化。第二个是将之作为文化声明。很多技术人员相信分享和重用的力量,为开源软件做贡献是一个公司展示与此哲学一致性的方式。

平台和生态系统提升生产力

开发者们主要通过代码来沟通。

讨论技术问题最好的方式通常是代码交流。敏捷宣言的原则之一是“可工作的软件”优于“理论或观点”,而开源软件就反映了这一点。

不同于试图用长篇大论解释所有技术问题的细节,开发者们通常会写一部分或全部代码,使用Github的代码社交功能来轻松讨论、接受或拒绝建议。直接通过代码来讨论,通常会带来更加高效的讨论,我们也逐渐看到这种技术在企业上下文中被采用。企业正在采用一种“内部开源”的模型,在这样模型下,源代码可以随时被分享出来并用于协作。但企业应该在面临风险时,忽略这种趋势。

3-paas

每个人都应该使用PaaS,但这个选择并不是永恒不变的。

能够参与到从“数据中心里放的一堆堆服务器”到“按需索求的虚拟基础设施”的业界革命的过程一向都是激动人心的,ThoughtWorks也一直处在譬如DevOps和持续交付等运动的领导前沿。客户常常要求我们使用云策略帮助他们,而我们今天的建议通常是“你需要采用PaaS”。

很多组织已经欣然接受了IaaS并且创造了复杂的基于“chuppet’的、领域特定的、通常由一些胶水代码和shell脚本搭起来的PaaS。尽管这些土生土长的平台已经够用了,但我们认为现有的PaaS产品更加成熟、值得一用。

PaaS可供选择的范围很大,从高度结构化的选项比如Cloud foundry和OpenShift,到无结构的以容器为中心的选项例如Mesos和Kubernets。我们不认为这些平台是万灵药。很有可能你会需要深入到IaaS底层来满足你的结果(比如配置复杂的网络)或者它们会降低你的灵活性(比如使之很难使用某个服务定位库)。但是一个PaaS,如果实现得当,能够为大多数企业级开发选购带来巨大的生产力。我们曾见证过,仅仅是利用将平台标准化、取得高效的部署、运行app,就产生了两倍生产力的爆发。和要求20个团队自己搞明白部署策略相比,PaaS是绝对的规则变革者。

Docker,Docker,Docker。

如果缺少了Docker,那整个技术行业的概述都不是完整的。这个容器化现象已经吸引了所有人的关注力,不管是开发者、测试者还是产品运营专家。Docker首先使包装一个应用或组件到容器里变得十分容易,在这基础之上,它还可以管理容器的各个生命周期。

Docker对于开发场景十分适用,比如从在同一个笔记本上运行多个微服务,到利用Docker镜像作为规模和管理单元来跨数据中心管理大型产品负载。我们认为最有趣的是围绕着Docker的高能源生态系统。现在的确有和Docker相竞争的工具,但是Docker在人们脑海中的占有率和其投资有着重要的意义,而且很有可能,在可预见的未来它会变成架构设计、开发策略和产品PaaS平台的底层基础。

Swift生态系统发展逐渐加速。

我们编写此次雷达时,讨论了很多Swift工具、库和框架,尽管它们不是每一个都光彩夺目。在诸如Microsoft的.Net, Ruby on Rails, Scala和Clojure等已沿用多年的平台基础上,开发者们在用Swift重新创造他们最中意的软件。这是Swift平台逐渐接近成熟的好兆头,而且它也是iOS开发的不错的选择。特别地,我们会质疑任何使用Objective-C为起点来开发新的项目。

4-swift

基于“计算组织体”的创新持续加速

底层技术——IoT, VR, 和Blockchain——给提供我们重要的组件块

当我们评估新的技术趋势时,观察其下支撑的工程学和物理学是非常有指导性的。比如说,物联网,就是由于底层的工程,诸如电池、高性能低功耗芯片、无处不在的网络连接的进步而变为可能的。这些智能的、相互连接的设备会带来诸多优势,首当其冲就是在那些能显著改善效用和节能的工业和商业环境下。消费者物联网依然停留在浅显的、小把戏的程度,在接下来几年里需要解决重要的安全和隐私问题。虚拟现实在譬如Oculus Rift和HTC Vive平台上的应用越来越广泛,超越游戏范畴的VR会随着我们逐步采用这个新组件块而变成一个增长领域。至于blockchain,我们预期在未来6~18个月中有比较缓慢的增长,但在超分布式信任和不可改总账之下,存在着我们可以用于建立商业、经济甚至社会的新能力。

当今时代显然是科技工作的黄金时代。在接下来的六个月里,我们期待能够看到这些趋势持续带给我们生产力上的增长,使团队和商业变得更加有力,并带给我们前所未有的全新想法和模式。我们也想要听听你的想法,在评论区告诉我们你心中最重要的行业趋势,以及未来我们可能见证要发生的事情吧!


你想看到的洞见,都在这里

wechat

Share

解读ThoughtWorks技术雷达的正确姿势

接地气的技术雷达

ThoughtWorks在每年都会出品两期技术雷达,这是一份关于技术趋势的报告,它比起一些我们能在市面上见到的其他各种技术行情和预测报告,更加具体,更具可操作性,因为它不仅涉及到新技术大趋势,比如云平台和大数据,更有细致到类库和工具的推介和评论,从而更容易落地。

这是2016年4月份的技术雷达全貌:

2016 April tech radar post

其中,自上次雷达发表以来新出现或发生显著变化的技术以三角形表示,而没有变化的技术则以圆形表示。每个象限的详细图表显示各技术发生的移动。

技术雷达对于不同层级和水平的技术从业者,有可以从不同角度和分类进行解读的可能。不管你是个人开发者,对于新工具和技术有执着的追求,寄希望于从新工具和技术那里获取改进每日工作的灵感,或者你是技术领导者需要针对自己的系统做技术选型,以及对未来技术趋势的把握,技术雷达都会是一份很好的参考。

而如何解读技术雷达就是变成一件很有意思的事情,解读方式可以帮助我们更有效地利用它。下面会介绍几种观察技术雷达的不同角度。

这里可以下载到最新版本的中文技术雷达。

手持一份技术雷达,更新技能和工具

技术雷达在四个象限(技术,工具,平台,语言和框架)中,布满了大量由ThoughtWorks技术专家们发现的,可以极大改善开发效率和品质的条目。它们大多数会分布在每个象限的试验和评估区域。

这些条目多具备创新和极客精神,可以很大程度上改善个人开发者的开发兴趣,保持对于新技术和技能的敏感度。

下面是两个例子:

Gauge是一个轻量级的跨平台测试自动化工具。技术规格由自由的Markdown语法写成,因此,测试用例可以用业务语言而不是使用通常的 ‘given-when-then’ 这种具有局限性的格式来描述。不同语言和IDE的支持以插件的形式添加到核心实现中这使得测试人员能够与团队一起使用同样的支持自动完成、重构等功能的IDE。同时,这个ThoughtWorks出品的开源工具天生就能够并行执行所有支持平台的测试。

Aurelia采用最新的Javascript:ECMAScript 2016标准开发而成,被认为是下一代JavaScript客户端开发框架。Aurelia的作者Rob Eisenberg是Durandal之父,离开Angular2.0核心团队之后全力打造了Aurelia。Aureliarelia最了不起的是它的高度模块化,包含了许多小型库,可以非常方便的进行定制化开发。Aurelia遵循约定优于配置的理念,而且其约定恰到好处,很容易进行模块的产生和使用。Aurelia有一个庞大的开发社群,它的官网还提供了非常好的入门文档。

开发者把玩并品味,将新工具和技术应用到手头的软件开发工作中,可以给日复一日、陈旧乏味的遗留系统带来新的气象,而成就感也就伴随而来。

如果对于已经处在采用(非常推荐)区域的技术条目,如果开发者仍然觉得陌生,那这也许就是自己对技术的敏感度在下降的征兆了。比如DockerReact.js

停止对不推荐技术的过度投资

开发者会觉得有一些技术和工具方兴未艾,依然趁手,但技术雷达已经将它们放入了暂缓区域(停止推荐),开始唱衰,这样的态度可以给开发者一些前瞻性的警示。

过度地投资在不被看好前景的技术上,势必会拖累开发的节奏和进度,跟不上市场的步伐,开发者需要的是拥抱更具市场前沿性的工具和技术。

比如这一期的技术雷达对于单一CI(持续集成)实例的担忧:

因为只有一个统一的配置和监控点,但是在一个组织中多个团队共享一个臃肿的CI会导致很多的问题。构建超时、配置冲突和巨型构建队列等类似问题出现得越来越频繁。这种缺陷导致的单点失败会造成多个团队工作的中断。要认真考虑在这些陷阱和保持单点配置之间找到一个平衡点。而雷达的建议是,由各个团队分布式地管理自己独立的CI。

还有一个很显著的例子是关于雷达对于Gitflow暂缓的态度,而这里有一篇很好的文章:Gitflow有害论,来自我的同事刘尚奇。

看技术演进动态

除了可以静态地看一份最新的技术雷达,我们如果对照比较浏览最近几期技术雷达中一些技术点的动态演进趋势,这会是一个更加有趣的体验。一方面也可以培养开发者自身对位技术未来趋势的把控力,另外一方面也可以印证技术雷达的前瞻性和可靠性,

这样动态形式看技术雷达,大致可以分下面两类方式:

单看某个技术点的演进

一个典型例子可以是技术雷达关于AngularJS的态度:

虽然我们使用AngularJS成功交付了很多项目,并且也能看到大型企业中越来越多的项目采用该框架,但是我们决定在这个版本的技术雷达将Angular移回“评估”。这个改动是为了让大家注意:React.jsEmber也有很不错的可选性,Angular从1.0到2.0的迁移过程充满不确定,同时我们发现一些组织在使用这个框架时并没有认真思考单页应用是否适合他们的需要。为此我们进行了激烈的内部辩论,但是可以肯定的是,同时使用双向绑定与不一致状态管理模式会让代码变得过于复杂。另外我们相信,相比于尝试移除一个固有框架,更好的方式是通过仔细的设计,在外层使用Redux或者Flux,来解决这些问题。

目前在前端框架方面,技术雷达的新宠是React.js

另外更加明显的在技术雷达上不断演进的例子是GradleSpringBoot。比如下面是技术雷达的历次版本对于SpringBoot的推介态度:

springboot-radar

从技术雷达的主题展开看

技术雷达开头的”最新动态“旨在展现当期雷达中最为引人注目并值得关注的几个技术或者主题。比如下面是最新这一期技术雷达的主题截图:

theme-radar

由主题内容开始,去寻找当期技术雷达中对于该主题的展开论述,在各个象限内找到对其有支持和补充的具体技术点,可以在开发者脑中绘制出一份更加完整的关于这个主题的现状和趋势来。

比如对于微服务这个技术,我们可以看到在技术雷达中,有这样一些技术、工具或者平台对于微服务架构的支撑:

microservices-map

而跳出单份技术雷达,开发者可以留意到,连续两三期的技术雷达都可能在针对同一技术,做主题性质的连续阐述,来阐释这一技术点在雷达中的重要性和演进的程度。

再比如微服务,它在技术雷达中的演进过程是,2012年3月雷达建议开始评估微服务,2012年10月则建议可以在系统中试验微服务架构,直到2015年1月出现Microservice Envy(微服务羡慕嫉妒恨),雷达建议暂缓实施微服务。

可以看见,对于微服务,雷达的态度是推荐而且敏感的。跟随雷达,开发者可以提前时间预见到自己可能遭遇的坑,以及会有相应的解决方案。

同样,不止于微服务,我们仍然可以找到类似这样的主题技术在雷达中的位置和全貌。

比如技术雷达对于安全领域的关注,在最新一期中,除了积极推荐采用的威胁建模方法外,雷达还提到了一下这些技术点,从证书管理、安全规范、漏洞检查、机密信息访问等方面,提供了一些推荐试验或评估的条目:

如数家珍,开始做技术选型

现在开发一个典型的Web应用,前端+后端可以有很多技术的选择,前端AngularJS方兴未艾,ReactJS已经异军突起,而对后端进行架构和选型,可以挑选的空间则更大,我们不得不在业务和技术采纳,甚至加上遗留系统之间,做更多的权衡和把握。

比如如果我们需要尝试微服务架构,并且碰巧身处Spring生态,那么SpringBoot会是更优的选择:

很多的工作已经通过使用SpringBoot来降低复杂度和依赖, 这在很大程度上缓解了我们以前的保留意见。如果你在Spring的生态系统中并正在走向微服务架构,SpringBoot就是当下最好的选择。而那些不在Sping生态环境中项目,Dropwizard也值得认真考虑 。

我的同事佟达对关于如何采用Python作为大数据全栈式开发语言的论述,同样精彩。他就云基础设施、DevOps、网络爬虫、数据处理四个方面,细数Python技术栈的选择,对于打造一个大数据处理平台的可能,信手拈来。

就像只要会JavaScript就可以写出完整的Web应用,只要会Python,就可以实现一个完整的大数据处理平台。

期待更多

ThoughtWorks技术雷达是一份不限行业,技术中立的前瞻性技术报告。它预测技术趋势,小到一个工具和类库,大到平台和架构,而我们已经在不断见证事实的发生。本文提供了一些可能有帮助的观察技术雷达的视角,你还有更有帮助的视角吗?

Share