生机型文化之使命式指挥

摘要:

为了让精益敏捷转型顺利和持久,做出精益敏捷的“神”,必须努力建设生机型文化;而在生机型文化中,一个重要的实践是使命式指挥。如何践行使命式指挥呢?


从生机型文化谈起

越来越多的企业进行精益敏捷转型,但是有一个很普遍的问题:当外部顾问离场后,回退很严重,流于走形式。其中,一个很重要的原因在于精益敏捷文化。文化建设对精益敏捷转型的持久性和高效性非常重要,如同塑造一个人的“性格”,组织的“性格”决定了结果。

什么是文化?文化是为共同目标而工作的员工之间的共同的信仰、价值观以及假设。管理大师沙因用钻石模型描述了文化的三个层次:

  • 外在表现形态:“外部人看到的”组织结构和组织过程等;
  • 规范和价值观:“组织所说的”的理念等,包括战略、目标、质量意识、指导哲学等;
  • 基本隐性假设:“组织所深信和践行的”,包括潜意识的、暗默的一些信仰、知觉、思想、感觉等。

( 文化的三个层次,沙因,1984)

后面两层文化在精益敏捷中体现为生机型文化,是精益企业文化的重要部分,其主要特征是:

  • 成效导向:绩效评价以实际的用户和业务成效依据,而不是过程指标;过程度量则仅用来发现问题和推动改进;
  • 高度合作:个体之间、组织的各部分之间高度合作、相互支持、充分分享;
  • 鼓励连接:鼓励跨越职能、组织和层级的沟通连接,而不是设置阻碍;
  • 风险共担:风险与责任共担,而不是逃避责任或各扫门前雪;
  • 信息辐射:组织内信息顺畅流动,有效辐射,鼓励发现并上报错误与风险的行为,而非掩盖或阻挠;
  • 采纳新鲜事物:鼓励尝试新想法,并采取措施来限制潜在失败带来的损失,提供“安全”的试错环境;为组织带来新思想,新方法和新技术的传播者、先驱者及具有成长型思维模式、学习能力和领导力的人,会得到重视和培养;
  • 失败产生根因调查:当事情出现错误时,尝试去发现根因,采取措施优化系统,而不是寻找替罪羊或追究责任并惩罚。

(生机型文化的核心转变)

生机型文化主要实践,包括了相对“流行”的自组织团队、跨职能团队、持续改善、内在激励、适应性领导力等,还有如文化度量、Y理论、使命式指挥、信任但验证、非指责性事后调查、成长性思维性模式等。本篇文章将重点阐述生机型文化的一个实践:使命式指挥。

(生机型文化的主要实践)

什么是使命式指挥(Mission Command)?

我们先看一个来自麻省理工大学研究的使命式指挥的成功案例:

耐克旗下的两个工厂

A工厂:传统的控制型管理,员工制定产量、生产实践,统一安排工作,相对高度控制。

B工厂:员工自由选择搭档,制定团队生产产量,决定在出现问题时停掉哪条生产线,等等,相对自由。

结果:A工厂的生产效率为B工厂的一半,B工厂的制作成本比A工厂降低40%。因此,即使是在这样一个传统的服装制造业,对团队的组织方式赋予自由的时候,也是有可能让他们的效率比在高强度管理的情况下还要有更好的成就。

在这个案例中B工厂采用使命式指挥充分发挥团队潜力,从而得到更好生产成果。

使命式指挥替代命令和控制指挥,是高度信任的组织文化表现形式。

首先,企业或组织确定好使命并且说明使命的意图和原因,在大范围内形成一致目标;

然后,在一致目标使命下,赋予组织成员更多的自主权——也就是说在职权范围内,每人都有做决定和行动的自由,自行决定达成目标状态的细节;充分发挥个体的创造力,而不是试图控制。

用很形象的战场来比喻,战场上千变万化,很多情况下指挥官都必须靠自己的判断来决定军事行动,而不是完全听命于后方司令部的指挥。使命原则的关键在于建立一致性、实现自主性,必须坚定的把“人”放在核心位置。

为什么采用使命式指挥?

随着组织的快速发展,组织的规模不断变大,就形成了一个“复杂系统”。要想让整个组织快速动起来、提高效率,必须进行系统解耦,让组织中的每个单元独立高效运作,充分发挥组织中个体的能动性。高层管理机构的职责,应该聚焦于局部无法执行的任务,对局部职权进行辅助,实施使命式指挥。例如,年产值25亿美元的化工产品公司戈尔,成立65年来,从未有过亏损的时候,他们就是在没有管理层的情况下运作的。在戈尔公司:

  • 人们选择自己的工作;
  • 领导者就是吸引了跟随者的人;
  • 独立业务部门就是小型、自治且自给自足的;超过150人就拆分。

ThoughtWorks自身也是使命式指挥的践行者。对组织内各项工作,管理层发布使命——愿景、目标和价值观,具体达成目标的细节过程,由员工充分发挥创意完成。我们能展现出各种不同创新模式,得益于这种核心推动力。

如何采用使命式指挥?

在谈如何采用使命式指挥前,得先看看如何建立使命。

一. 如何建立使命?

1.逐层建立组织级战略

从建立使命的人来说,可以分为三层:高层管理、业务线投资组合管理人员、团队。

  • 首先高层管理设立组织级的愿景使命;
  • 业务线投资组合人员分解成业务目标使命;
  • 团队依据整体业务目标设定各自团队的具体目标。

比如,下面的精益价值树就是逐层目标分解。

(精益价值树)

也可以采用接球(Catch Ball)的方式,制定逐层组织级战略。

(采用接球的方式,制定逐层组织级战略)

2.不同类型的使命

通常,使命可以分成:业务使命、过程使命、技术使命、财务和预算使命。

  • 业务使命:上面的精益价值树是一个例子:根据精益企业中提到的业务地平线, 确定三条业务线的比例,然后对于H3类型的创新业务,高层管理需要确定创新的愿景、创新的过程;对于H2类型的拓展业务,需要确定年度的拓展使命和阶段性拓展使命,特别是商业模式;对于H1类型的稳定业务,除了驱动团队围绕以用户为中心的渐进性创新外,高层和业务线投资组合人员还需要确定未来生命周期的使命路线。
  • 技术使命:比如亚马逊的面向服务的架构,还有微服务、自动测试、移动优先、推进云战略等;CEO、CTO、CIO需要很关注这些技术使命。
  • 过程使命:比如:团队用精益敏捷方式开发产品,快速学习,快速反馈,创造对客户有价值的产品;具体可以再按精益敏捷成熟度分解成几个阶段性使命;过程使命需要与业务使命和技术使命紧密结合在一起。
  • 财物和预算使命:如按季度的滚动预算,要与业务和过程使命相互配合。

3.使命一旦确定,必须遵循

需要特别说明的是,使命一旦确定,必须遵循。在现实过程中,经常会出现不遵循使命的问题。碰到这种情况:

  • 首先分析不遵循的原因:可能是使命有问题,或者使命没问题但不想执行;
  • 如果使命有问题,需要立即修正;
  • 如果是执行的问题,需要严肃对待,否则企业和团队处于一切无所谓散沙的状态,一事无成。

典型的亚马逊的案例:

2001年,亚马逊遇到了一个难题:支撑他们网站运行的Obidos系统,是个巨大且铁板一块的“大泥球”,无法进行扩展,其制约因素是数据库。首席执行官Jeff Bezos将这个问题变成了机会。他希望亚马逊变成一个其他企业都可以利用的平台,最终目的是更好地满足客户的需求。因此,他给技术人员发了一封邮件,要求他们创建一种面向服务的架构。Steve Yegge对此总结如下:

  1. 所有团队以后都通过服务接口来暴露他们的数据和功能;
  2. 团队之间必须通过这些接口彼此通信;
  3. 不允许其他任何形式的进程间通信:不能直接链接,不能直接读其他团队的数据库,没有共享内存模式,不能有任何形式的后门;唯一允许的通信是通过网络调用服务接口;
  4. 采用什么技术都行:HTTP、Corba、PubSub、自定义协议,都无所谓;
  5. 所有服务接口,无一例外,都必须要一开始设计就考虑可外部化——也就是说,团队必须要有计划地做出设计,让接口能开放给外部的其他开发人员;不允许例外;
  6. 任何不这样做的人都将被开除。

Bezos雇佣了西点军校毕业的前陆军突击队员Rick Dalzell来强制实施这些规则。和这些规则一道,他还强制推行了另一个重要变革:每一个服务由一个跨职能的团队负责,团队要在服务的整个生命周期里负责其开发和运行。就像亚马逊的首席技术官Werner Vogels所说的,“谁开发,谁运维”。

这条规则和所有服务接口设计必须可外部化这一要求,一起产生了一些重要影响。正如Vogels指出的,这种团队组织方式“让开发人员接触到其开发软件的日常运作,也让他们每天接触到客户。这种客户反馈环对于提高服务质量非常关键”。

二. 如何使用使命式指挥?

1. 首先要建立跨职能的团队

首先,改变组织结构,建立去中心化的、跨职能的、目标高度一致的、松耦合的小团队。确保团队对他们正在工作的系统有清晰一致的理解,以更好地发挥主观能动性。团队一旦超过10人,群体的变动和协调就会变得难以管理,也变得难以达成决策共识,难以确保团队的每个人都对上下文理解一致。

(建立小团队)

比如,可以以API接口边界来划分团队边界。这种方式,我们可以将团队分布在全世界。只要每个服务都由一个同地点工作的、自主的跨职能的团队来开发和运维,团队之间就不再需要大量的沟通。

很有代表性的是,亚马逊的“两个披萨”组织结构。

随着组织的发展,最大的问题之一就是保持人与人之间及团队与团队之间有效的沟通。一旦将人员搬到另一个楼层、另一栋建筑或另一个时区,沟通有效性就会大大受限,要继续保持共识、信任和有效协作就很困难。为了控制这个问题,亚马逊规定所有团队必须能遵循“两个披萨”法则:团队应该小到两个披萨就够所有人吃——通常大概5到10人。

对团队大小的限制会产生四个重要影响:

  1. 确保团队对他们正在工作的系统有清晰一致的理解;
  2. 限制团队正在开发的产品或服务的增长速度——通过限制团队大小,我们限制系统所能演进的速度,这同样有助于保证团队对系统始终保持理解一致;
  3. 可能最重要的是,这让权力去中心化,带来了自主性,遵循了使命原则——每一个“两个披萨”团队(2PT)尽可能自主;团队领导者会和管理层一起决定团队所要负责的关键业务指标,称之为“健康函数”,进而成为团队进行实验的整体评价标准;
  4. 领导“两个披萨”团队可以让员工在一个失败不会产生灾难性后果的环境里获得一些领导力经验——这“有助于企业吸引和留住创业型人才”。

2. 建立团队的自主性策略

建立了跨职能的“两个披萨”小团队后,还需要建立团队的自主性策略:

  • 给予团队工具和授权,可将变更部署至生产环境,开展自运维:这看起来很明显,但很多传统组织会基于安全性为由,导致这一点在实际中很难执行,部署生产环境都要提申请走很多流程,生产环境的部署改革极其缓慢。在亚马逊、Netflix和Etsy这样的公司,变更部署下放到团队,特定的高风险变更,团队商讨措施。高层管理相信团队能够采取恰当的措施,并进行自动化测试。另外,我咨询过的一家公司,开始尝试授权团队做自运维,但也担心安全性问题,他们的措施是自运维的同时做好各种日志和流程的跟踪记录,出了问题可以立刻找到问题点,后续持续改进。这也是一种过度改进措施,先要勇敢地做起来迈出第一步;
  • 确保团队有权利选择自己的工具链:尽量让团队自主选择技术栈;在生产环境中,可以限制团队采用由内部IT部门或外部供应商提供的一致平台或基础设施服务,使团队能够向生产环境进行自主部署;
  • 确保团队不需要拨款审批就能进行试验:只要是在使命范围内的具体实验行动,应该有滚动预算的支持,不会因为资金预算问题阻碍验证新的想法;
  • 确保领导者专注于实现使命式指挥:领导者首先要敏锐地根据市场和用户变化,阶段式定义正确的使命,并有效的传达使命,同时协助建立跨职能小团队,采取各种形式提升人员的胜任力,营造充分发挥个人自主性的氛围,提高最小单元的有效性,并从这些组织单元中培养出新的领导者。

在使命式指挥中,团队有权利和责任对他们所处的特定场景下的成本和风险进行恰当的管理。而财务、项目管理办公室(PMO),治理、风险与合规管理(GRC)团队,以及其他集中式机构的角色,都要发生改变:他们指定目标成效,协助将当前状态透明化,并在需要时提供支持和工具,但不强制规定成本、流程和风险要如何管理。

3. 建立改善形

改善形是一种遵循使命原则,将实现那些成果的主人翁意识推向组织基层的一种方法。改善形为团队建立一致的目标, 并将其分解为一个个小的、渐进的成果(目标状态),能够逐步接近目标。改善形的关键特征是它的迭代性,以及能够驱动一种实验性方法来达到期望的目标状态 。改善形的迭代几乎过程产生效果是一组我们希望下个迭代能叨叨的可衡量的目标状态,它描述了我们要努力的方向,并且遵循使命原则。使命的具体目标跟踪管理也可以采用OKR体系。下面是一个团队利用改善形迭代式遵循使命达成目标的例子:

(利用改善形迭代式遵循使命达成目标)

最后要使使命式指挥真正起效,还需要“信任但验证”的机制保证,确保使命的达成。

著名的瑞典商业银行,给分行授予了高度的自主权,但是有一套非常完善的事后核算反馈成效体系,验证自主行动的效果,持续改进;给团队更多灵活支配使用预算的自主权,同时要定期监控预算使用的成效。

总结

为了让精益敏捷转型顺利和持久,做出精益敏捷的“神”,必须努力建设生机型文化。在生机型文化中,一个重要的实践是使命式指挥,在一致性使命的指导下,充分发挥每个小团队的自主战斗力,从而加快整个组织的响应能力,进而获得市场竞争力。


更多精彩洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

创新,最重要的是信念 | 产品创新读书雷达发布啦!

首先,读书,当然不能保证我们可以做出成功的产品。

不记得在哪里看过说,“读书,其实是为了培养信念”,对于产品创新这件事也是一样。读书,会让我们明白:

  • 有那么多事,值得我们去改变;
  • 原来,我们也能够去改变;
  • 原来有这么些逻辑和方法,可以避免愚蠢的错误;
  • 只要具有钢铁般的意志,终将抵达彼岸。

“我这辈子遇到的来自各行各业的聪明人,没有一个不是每天阅读的——没有,一个都没有。而巴菲特·沃伦读书之多,可能会让你感到吃惊,他是一本长了两条腿的书!”巴菲特合伙人查理·芒格曾这样评价巴菲特。

但我们也不想让大家为读书而焦虑。因此,基于以下的原则,我们筛选出了32本书:

  • 聚焦产品创新主题;
  • Less is More,少就是多;
  • 兼顾格局、视野与实用、落地;
  • 趣味和思想 胜于 全面和细致。

如果你是想尝试产品创新、已经在做产品、或是想在组织里培养更多产品创新者的人,那么下面这份读书雷达或许可以帮到你:

Share

2018年5月期技术雷达正式发布!

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

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,更有细致到类库和工具的推荐和评论,因此更容易落地。经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第十八期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

本期四大主题

浏览器增强,服务端式微

为了实现应用逻辑,浏览器在持续扩展成为部署目标的能力。当平台能照顾好横切关注点和非功能性需求的同时,我们注意到后端逻辑的复杂性有逐步降低的趋势。 WebAssembly 的引入为web应用创建逻辑提供了新的语言选择,同时把处理过程更加推向金属侧(以及GPU)。 Web Bluetooth让浏览器能够处理那些原本是本地应用才能处理的功能,而且我们看到越来越多像 CSS Grid Layout和 CSS Modules这样的开发标准正在替换掉自定义的库。对更好用户体验的追求,正在持续地把功能装进浏览器里,许多后端服务因此变得越来越薄,复杂性也因而降低。

不断蔓延的云环境复杂性

虽然AWS继续凭借令人眼花缭乱的新服务保持领先,但我们逐渐看到 Google Cloud Platform (GCP)和 Microsoft Azure 已经成为可行的替代方案。像 Kubernetes 这样的抽象层以及持续交付和基础设施即代码这样的实践,能支持更容易的演进式变化,从而促进云环境之间的过渡。但随着 PolyCloud (这允许组织根据差异化的功能在多个供应商之间进行挑选)以及越来越多的监管和隐私问题的出现,云策略必然会变得更加复杂。例如,许多欧盟国家现在依法对数据所在地做出要求。这使得数据存储的管辖权和其主机的管理策略成为评估云计算环境的新维度。云计算环境的可选范围也在扩大,比如在“函数即服务”和“管理更长寿命集群”这两者之间,就可以选择提供了“容器即服务”(CaaS) 的 AWS Fargate 这个有趣的选项。虽然各个组织对云技术的应用日臻成熟,但伴随使用这些新技术构建真实解决方案的,是逐渐蔓延又无法避免的复杂性。

信任但要验证

对于几乎所有的软件开发来说,安全问题仍然是至关重要的。当前我们观察到传统的“全局权限管理”的安全策略正在转变为更为细致的本地化方法。现在许多系统会在更小的领域内管理信任,并在不同系统之间使用一些新的机制创建可传递的信任。其理念正在由“永远不信任领域外所有东西”以及“从不验证领域内任何东西”转变为“信任但是需要验证领域内外任何东西”——也就是说可以假设和系统其它部分有本意良好的互动,但一定要在本地验证这份信任。这使得团队可以对自己的基础设施、设备和应用程序栈有高度的权限控制,从而实现高度可视化,并可以在必要时候提供高级访问护栏。类似 Scout2的工具以及 BeyondCorp 这样的技术反映了关于信任更成熟的视角。我们欢迎这种向本地化管理的转变,特别是当工具和自动化策略可以确保同等或更好的合规性时。

物联网的发展

物联网(IoT)生态系统持续稳步发展,关键成功因素包括安全和成熟的工程实践。我们看到了整个物联网生态系统的增长,从设备上的操作系统到连接标准,尤其是基于云服务的设备管理和数据处理。我们看到了一些成熟的工具和框架,支持良好的工程实践,比如持续交付、部署以及为实现最终广泛使用的大量其他必要实践。除了主要的云服务提供商——包括 Google IoT Core ,AWS IoT 和 Microsoft Azure IoT Hub ——像阿里巴巴和阿里云这样的公司也在大力投资物联网 PaaS 解决方案。可以从我们的 EMQ 和Mongoose OS 条目一瞥当今物联网生态系统的主流功能,它们也例证了 物联网 的良好的发展状态。

象限亮点抢先看

要记住,就像适用于其他软件领域一样,封装也同样适应于事件和事件驱动的体系结构。特别是,我们需要考虑一个事件的范围,以及我们是否期望它在同一个应用程序、同一个领域或整个组织中被消费。DOMAIN-SCOPED EVENT将在其发布的同一个领域内被消费,因此我们期望消费者能够访问特定的上下文、资料或引用,进而对事件进行处理。如果这个事件的消费在组织内更广泛地发生,且事件的内容需要有所不同,我们就要注意不要“泄漏”其他依赖领域的实现细节。

身份管理是平台的关键组件之一。外部用户在使用移动应用的时候,需要对其身份进行验证,开发人员需要被授权才能访问基础设施组件,而微服务也需要向彼此证明自己的身份。你应该考虑的是,身份管理是否真的有必要自己来搭建和维护。根据我们的经验,HOSTED IDENTITY MANAGEMENT AS A SERVICE( SaaS)这种解决方案更为可取。我们相信,像Auth0和Okta这样的顶级托管商可以在“正常运行时间”和“安全”两方面提供更好的SLA。也就是说,虽然有时候自行搭建和维护身份管理解决方案是一个现实的选择,特别是对于那些有操作规范和资源的企业来说,这个选择更为安全。但大型企业的身份解决方案通常包含更广泛的功能,例如集中授权、治理报告和职责分离管理等等。不过,这些担忧通常与员工身份更相关,特别是那些受遗留系统限制的企业,尤其如此。

在实践微服务的过程中,为了将后端资源进行聚合,我们实践了一个又一个的模式。之前,我们经常使用类似于Netflix Falcor这样的工具帮助我们实现BFF(Backend for Frontend ),现在很多项目已经开始使用GRAPHQL FOR SERVER-SIDE RESOURCE AGGREGATION。GraphQL可以让客户端直接使用特定的查询语句去访问BFF以获取数据。使用这项技术时,后端服务可以继续暴露 RESTful API,而GraphQL可以轻易的将这些服务所提供的资源聚合在一起,并且对客户端十分友好。我们推荐GraphQL是因为其简化了BFF和其他聚合服务的实现。

在高度分布式的微服务架构中,其可观察性有一个两难问题 —— 要么记录一切,代价是巨量的存储空间;要么随机抽样记录,代价是有可能丢失某些重要事件。最近我们注意到一项技术,它在这两种方案之间提供了一个折衷方案。通过跟踪请求头中传入的某个参数来LOG LEVEL PER REQUEST。使用跟踪框架(可能基于OpenTracing标准),你可以在一次事务中的多个服务之间传递一个相关的ID。还可以在开始事务时注入其它数据(比如期望的日志级别),并且与跟踪信息一起传递它。这样可以确保这些额外数据在系统中总是和相应的单个用户事务一起流动。这在调试时也是个很有用的技巧,因为服务可能会暂停或以逐个事务的方式进行修改。

Headless CMS( Content Management Systems, 内容管理系统) 正在成为数字化平台的常见组件。CONTENTFUL是一个现代化的 headless CMS。我们的团队已经成功把它集成到开发工作流中。我们特别喜欢其“API 优先”的特点,及其CMS as Code的实现。它支持强大的内容建模原语代码和内容模型演化脚本,并允许将其视为其他数据存储的schema,并将演进式数据库设计实践应用到 CMS 开发中。我们所喜欢的其他特性包括:默认包含两个 CDN以提供多媒体资源和 JSON文档,本地化的良好支持和与Auth0集成的能力(尽管需要做出一些努力)。

EMQ是一个可伸缩的开源多平台 MQTT代理。为了追求高性能,它使用Erlang/OTP语言编写,能处理数百万的并行连接。它能支持多种协议,包括MQTT、MQTT传感器网络、CoAP以及WebSockets,使其适用于物联网和移动设备。我们已经开始在项目中使用 EMQ,很享受其安装以及使用的便捷性,以及它能将消息路由到不同目的地(包括Kafka和PostgreSQL)的能力,还有它在监控和配置上所采用API驱动的策略。

TICK STACK是一个由开源组件组成的平台。使用它就可以轻松地收集、存储、绘制基于时间序列的数据(如度量和事件)来触发告警。TICK Stack 的组件包括:收集和报告各种指标的服务器代理telegraf、高性能时间序列数据库InfluxDB、平台的用户界面 Chronnograf,以及可以处理来自 InfluxDB 数据库的流式数据和批量数据的数据处理引擎Kapacitor。不像基于“拉”模型的Prometheus,TICK Stack是基于“推”模型来收集数据的。InfluxDB 组件是该系统的核心,同时也是目前最好的时间序列数据库。虽然这套组件栈基于 InfluxData ,而且需要使用诸如数据库集群这样的 InfluxData 企业版的功能,但在监控方面它仍然是一个不错的选择。我们正在一些生产环境上使用该平台,并且获得了一些很好的体验。

WEB BLUETOOTH能够直接从浏览器控制任意低功耗蓝牙设备。这样以前只能通过原生手机应用来处理的场景,现在也可以适用了。该规范由 Web Bluetooth Community Group 发布,并且定义了一个 API,通过蓝牙 4.0 无线标准发现设备并在设备间通信。 当前,Chrome 是唯一支持这个规范的主流浏览器。借助Physical Web和 Web Bluetooth,现在有了其他途径来让用户与设备进行交互, 且无需让他们在手机上安装另一个应用。这是一个令人兴奋的领域, 值得密切关注。

我们很开心使用 BACKSTOPJS 来做 web 应用的可视化回归测试。作为可视化比较工具,它的可配置视窗和可调节容错能力可以很容易定位到细微差别。它有很优秀的脚本功能,并且可以选择在无界面Chrome、PhantomJS 和SlimerJS 中运行。我们还发现,它在实时组件样式规范的基础上运行时尤其有帮助。

世界上有数不清的问题都可以用数学优化问题来表达,而其中可以用凸问题来描述的那部分常常能够得到有效解决。CVXPY便是一种针对凸优化问题所开发的开源Python嵌入式建模语言。它由斯坦福大学的学者维护,已经为数个开源和商业解决方案提供了功能齐备的安装套件。它的文档中也包含了许多能够引起开发者使用兴趣的例子。尽管有些时候,我们仍然需要类似Gurobi和IBM CPLEX这类商业解决方案,但CVXPY在原型设计阶段可以说所向披靡。在多数情况下,有CVXPY就足够了。同时,基于最近的优化进展,其开发者一直在为我们提供更多的扩展包(例如DCCP)和相关软件(例如CVXOPT)。

HELM是Kubernetes的包管理器。共同定义某个应用的Kubernetes资源集合被打包成图表。这些图表可以描述单个资源,例如Redis pod,或者全栈的Web应用程序:HTTP服务器、数据库和缓存。Helm 默认带有一些精选的 Kubernetes应用,维护在官方的图表仓库里。想要为内部用途搭建私有的图表仓库也很容易。Helm有两个组件:一个是称为Helm的命令行工具,另一个是称为Tiller的集群组件。保护Kubernetes集群是一个宽泛而微妙的话题,但我们强烈建议在基于角色的访问控制(RBAC)环境中搭建Tiller。我们在很多客户的项目中使用了Helm,它的依赖管理、模板和钩子机制极大地简化了Kubernetes中应用程序的生命周期管理。

ARCHUNIT是用来检查架构特征的Java测试库,比如包与类的依赖关系、注解验证、甚至层级一致性。它可以在你现有的测试方案中,以单元测试的方式运行,但目前只能用于Java架构。ArchUnit测试套件可以合并到C(I 持续集成)环境或部署流水线,使我们很容易地以演进式架构的方式实现适应度函数。

Hyperledger项目现在已经发展成包含一系列子项目的大工程。针对不同业务需求,可以支持不同的区块链实现方式。例如,Burrow专门用来实现带权限控制的Ethereum,而Indy更专注于数字身份。在这些子项目中,Fabric是最成熟的一个。当开发者们谈到使用 Hyperledger 技术时,实际上大多数时候是在考虑 Hyperledger Fabric。然而,chaincode的编程抽象相对底层,因为它直接处理账本的状态数据。此外,在编写第一行区块链代码之前,搭建基础设施也经常耗去很多时间。HYPERLEDGER COMPOSER 构建于Fabric基础之上,加速了将想法实现为软件的过程。Composer 提供 DSLs 来建立业务资源模型、定义访问控制和构建业务网络。使用 Composer,可以在不搭建任何基础设施的情况下,仅通过浏览器来验证我们的想法。需要明确的是,Composer 本身并不是区块链,仍然需要把它部署在 Fabric 上。

RASA是聊天机器人领域的新成员。 它并非使用简单的决策树,而是通过神经网络将用户意图和内部状态映射到回应上。Rasa 集成了自然语言处理解决方案(spaCy)。与技术雷达中的其他同类工具不同,Rasa是开源软件,可以自行托管,对于担心数据所有权的使用者来说 Rasa 是一个可行的方案。我们在内部应用中使用了Rasa Stack,效果良好。

RIBs即路由器(Router)、交互器(Interactor)和构建器(Builder)的缩写, 是来自 Uber 的跨平台移动架构框架。RIBs的核心思想是将业务逻辑从视图树中分离出来,从而确保应用程序由业务逻辑驱动。 可以将其看作是Clean Architecture模式在移动应用程序开发领域的一次应用。通过在原生 Android 和 iOS 应用上使用一致的架构模式,RIBs为应用提供了清晰的状态管理模式和良好的可测试性。尽管我们一直建议尽量将业务逻辑放在后端服务,不要将其泄漏到前端视图中,但移动应用程序非常复杂,RIBs可以帮助管理这种复杂性。

REACTOR是一个基于Reactive Streams规范的、用于开发非阻塞式应用程序的 JVM 库,支持 JVM 8 及以上版本。响应式编程强调将命令式逻辑转换成异步、非阻塞和函数式风格的代码,特别是在处理外部资源时。Reactor 实现了 Reactive Streams 规范,并且提供了两个不同的发布者API:Flux (0 到 N 个元素) 和 Mono( 0 或 1 个元素),可以高效地对基于推送的流处理进行建模。Reactor 项目非常适合微服务架构,并且为HTTP、WebSockets、TCP和UDP等提供了支持背压(backpressure)的网络引擎。

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

Share

安吉・弗格森:IT曾是女性主导的行业

本文首发于微信公众号:哈佛商业评论,已获授权,转载请联系哈佛商业评论。

不可否认,女性程序员在全球IT领域仍处于劣势地位。2015年调查数据显示,Facebook的IT人员中仅16%为女性,谷歌为18%。而2014年夏,谷歌、雅虎、领英和Facebook公布本公司女性员工雇用比率时,就承认这一水平过低。事实数据说明,这些大型技术公司在提高女性程序员数量上仍需更多努力。

让我们再聚焦于中国IT从业人员。互联网求职平台100offer在2016年公布的中国互联网女性工程师工作报告表明,过去一年,男性程序员的注册人数是女性程序员的近4倍。此外,同一职位上的男性程序员薪资普遍高于女性程序员。实际上,女性在IT行业,甚至包括整个STEM(科学、技术、工程、数学)领域,都面临严峻挑战和多重偏见,导致这些行业的女性比例和待遇迟迟得不到提高。长达40年的社会科学研究表明,如果不对女性员工的偏见加以制止,这将继续渗透到人们观念中,而且人们会认为自己就在奉行贤能主义,所以更加不会采取行动,破除偏见。

加州大学哈斯汀法学院法学杰出教授琼・威廉姆斯(Joan C. Williams)发表于2014年《哈佛商业评论》的《攻克科技领域多样性问题》一文指出,技术行业女性员工面临的偏见和挑战主要可以分为四类:

  1. 再证明一次!女性要用更多成绩证明自己和男性有同等工作能力;
  2. 如履薄冰。普遍观点认为,高级职位需要在职者拥有传统意义上的男性特质,而女性应做到谦逊矜持。因此,女性职员不能过于女性化,这会显得能力不足,也不能过于男性化,会不讨人喜欢。
  3. 母亲壁垒。女性员工当了母亲后,其敬业度和工作能力会因其母亲身份而频频受到质疑。尽管很多从事技术行业的女性对本行工作时间灵活和远程工作条件称赞有加,但成为母亲后,一旦她们有失职情况,即便是迟到,也会再次印证女性不适合当CEO的传统观念。
  4. 内战。威廉姆斯的研究中,45%的受访女性称曾遭遇这种状况,即如果女性在其事业起步阶段受到歧视,会倾向于避免与其他女性接触,拒绝帮助她们,甚至不惜以损害其他女性利益为代价与男性协作。她们回避对性别歧视的控诉,并以此表明自己的忠心。

那么面对技术领域中普遍存在的四种性别偏见,女性应如何应对,公司又该采取哪些措施提升女性技术人员数量,保障女性员工权益,加强人才多样性呢?带着这些问题,《哈佛商业评论》中文版采访了全球技术咨询公司ThoughtWorks亚太地区集团执行总监安吉・弗格森(Ange Ferguson)。弗格森来自澳大利亚,拥有在澳洲、英国、荷兰、印度、新加坡和中国等国的跨国工作和管理背景,从事技术工作时间近20年。基于在该领域的深厚经验和对女性程序员的深刻洞察,她谈到了女性在技术领域遇到的阻碍以及解决之道

HBR中文版:从全球范围看,女性在技术领域所占比例都比较低。作为女性,你如何接触到计算技术并最终进入该行业?

弗格森:我的父亲是科学老师,所以我小时候可以借父亲工作之便,在放假时使用学校的计算机。1995年我考上大学,第一次接触到互联网,惊讶于这项科技巨大的连接性,决定从哲学系(50/50男女比例)转到计算机技术系(20/80男女比例)。计算机专业是个男性占绝对主导地位的学科,但当时我还没有意识到,这是个需要探讨的问题。

毕业后我去了一家小型专业服务公司。因为公司规模小,所以我得到很多大公司都不能给予新人的机会。虽然工作量很大,但我成长得非常快,还遇到了人生中一位重要导师丹尼斯。2001年互联网泡沫破灭时,我所在公司不幸倒闭了,于是我像很多澳洲人一样,去了欧洲旅行,并先后在伦敦、阿姆斯特丹工作。几年后我回到澳洲墨尔本工作,在丹尼斯引荐下,到了ThoughtWorks工作,到现在已经11年了。

HBR中文版:外界对IT行业的看法是竞争激烈,而且工作强度和难度都很大。作为资深从业者,你认为吸引你留在这一行的因素是什么?

弗格森:IT行业的工作机会很好,我有幸去世界不同国家和地区工作,也尝试了不同的职责,比如我曾在悉尼、布里斯班、香港、新加坡等地担任项目经理。我在ThoughtWorks工作几年后进入管理团队,一年后去印度担任管理工作,还为当地大学毕业生授课。我喜欢这种IT公司的商业模型——我们以项目为单位,结果为导向,工作时间和地点都不确定。你可能每半年或几年就要换新项目,面临全然不同的工作内容、合作伙伴和文化。我喜欢这种多样性带来的冲击。

此外,技术公司往往采取扁平化管理架构。比如在ThoughtWorks,我的另一位导师兼上司就在我隔壁。他像我的朋友,对我极其信任,同时又有很高期望,不断激励和鼓励我。导师对个人,尤其是女性的职业发展来说极其重要;他们的经验和洞见是年轻人最需要积累的财富。(但研究表明,女性虽然擅长建立关系网,可在职场中这种能力并未得到充分发挥。)当然除了导师以外,你可以向公司中每一个人求教,他们都会像朋友一样认真回答你的问题,而且相比进入管理团队,我们更愿意留在一线,学习应用最先进的技术,毕竟编程才是程序员真正热爱的工作。

HBR中文版:时间灵活、重视多样化,这些似乎都是对女性员工友好的工作条件。但为何现在IT行业女性人数依然过少?在打破技术公司性别偏见方面,ThoughtWorks有什么可供借鉴的解决方案吗?

弗格森:某名为《当女性停止编程》的研究指出,个人计算机最初进入市场时,其营销方向是男孩的玩具,所以美国、欧洲、澳洲的大多数家庭都会把电脑放在男孩子的房间。我们准备考大学时,卧室里有电脑的男孩对计算机更熟悉,技能更熟练,所以选择计算机专业的学生往往是男生,而最终从事这一行业的人也多为男性。我认为,市场营销,包括整个社会从一开始就建立了“计算机属于男性领域”的刻板印象,但这一假设并不成立。在计算机早期应用阶段,程序员往往是女性,而计算机主要用于行政工作——传统女性主导的领域。这样看,男女工作的选择更多受社会思维观念影响,而非男性真的做不好行政工作,或女性不能胜任IT岗位。

为创建多元化且有包容性的文化,ThoughtWorks一直以来都注重培养(cultivating)和发展(developing)员工,为他们提供开放、时间灵活、鼓励学习的工作环境。现在我们在中国的女性技术员工占员工总数的34%,所有女性员工占比40%,女性领导者在管理团队占比40%,在全球基本也是以上数据,这在IT公司中算是比较平衡的男女比例。我们是怎样做到这一点的呢?首先,我们会改变思维模式,不去规定你不能做什么,而是专注于你能做什么。我们赋权给员工,尽量给他们更多选择,让他们不论性别、种族、国籍、教育背景如何,都能发挥出其最大潜能。此外,IT行业变迁太快,这要求你在整个事业生涯中都不能停止学习。我们了解,每个人的学习方式都不同,所以我们提供不同的培训项目,并鼓励大家在网络平台上展开积极讨论,为所有员工创造了解彼此、互相学习、共同进步的良好氛围。值得一提的是,我们还在西安邮电大学建立的实验室,为上千名学生,特别是年轻女性提供线上和线下编程课程,希望更多学生,尤其是女性学到实用的IT知识,帮助他们缩小学校所学理论与行业实践的距离。我们认为,如果女性从学习编程初期就接触到聪明、有能力的IT女性,同时获得足够支持与鼓励,她们对编程会更有自信,并相信自己也会成长为杰出的IT女性。 我们还希望给她们跨越整个职业生涯的帮助,因为IT女性出于家庭、生育等因素选择性退出的比例远高于男性,所以每当她们遇到职业瓶颈期时,都可以咨询我们并寻求意见。

HBR中文版:也就是说,只要IT公司对内对外都构建起互帮互助、多元包容的文化,在行业中处于劣势的群体比如女性,会是最终受益者?

弗格森:的确如此。此外,你帮助的女性越多,她们就会形成越来越强大的组织和关系网,产生累积效应,IT女性的力量也就越来越强大。如今我们成为对女性友好的标志性公司,至少在澳洲如此,这其实也告诉外界:如果你的员工发展方式是正确的,女性程序员的潜能就能被激发。我们也倾向招募没有经验的毕业生,帮助他们建立自己的事业,让他们了解我们的价值观,而一旦他们认同并适应多元、包容的环境,他们就会成为这一文化最坚定的倡导者。

HBR中文版:但多数IT公司都未能在提高女性程序员比例上有所作为,女性仍面临同工不同酬、“母亲壁垒”、“再证明一次”等偏见。你如何看到这一现象?

弗格森:这些情况的确存在,我们听到很多这类故事,包括我们的中国员工也提到,在她之前的工作环境中,“作为女性,她必须比男性同级更优秀,才能获得升职加薪机会”。我想女性首先要了解偏见,然后有与上级谈判,要求同等待遇的意识和技巧。比如我曾经为一位女性管理者提供咨询,鼓励她与上级沟通,大胆提出自己的加薪要求,结果她与上级谈完后,提议立刻就被通过了——这说明,她一直都没有得到自己应得的工资,而如果她不提出要求,老板就不会主动给她晋升加薪机会。所以女性要做的不仅是做好自己的工作,更要有谈判、争取自身权益的意识和勇气。一旦你“向前一步”,不公就会“退后一步”。

另外,如果你的组织限定了女性的竞争领域,迫使女性展开内部竞争,争取仅有的几个对女性开放的升职或加薪机会,我觉得你应该离开这家公司。事实上,如果女性愿意联合起来帮助彼此,与已经获得优势地位的男性沟通,效果要好得多。比如在一个10人会议中,只有两位女性参加,那么她们可以彼此呼应,重复彼此的论点,避免自己的声音在男性主导的会议中淹没——事实上,我也用过这个策略。

我依然是对IT界女性力量的壮大,持乐观态度。回想我们的前一代女性,很少人当了母亲后仍在职场工作,但现在随着职场妈妈人数的增多,这一群体也在开始发出自己的声音,要求改变人们对“女性必须承担更多家庭责任”的偏见。更重要的是,如果你知道偏见的存在,就能做出更好的应对。比如女性面临的“如履薄冰”偏见,出现这一问题的原因在于组织多样化程度不高。如果你所在公司以男性为主导,整个思维模式都偏男性化,女性很少能找到同性榜样,这种巨大的权力落差就会造成极端化的刻板印象,让女性不知道如何在男性为主导的文化中表现领袖气质。但若你吸收了大量女性,保证性别的均衡,女性的形象和气质就会更丰富——你不必是“女汉子”或“傻白甜”,你更多是一个糅合多种气质、刚柔并济的员工。每个组织都需要更多领导者“画像”,让员工看到领导力的多种可能性。

HBR中文版:我们所谈的问题,现在依然没有得到公众的普遍认知和认同,有效的解决方案也并未得到广泛实施。对此,我们还需要做哪些努力?

弗格森:我认为,我们需要更多公众讨论,加强人们对偏见的认知和改变的决心。同时,这不仅是女性的战争,我们同样需要男性的支持。比如在澳大利亚,我们有一个名为“Male Champions of Change”的组织,参与者都是澳洲最有影响力的CEO和高层领导者。他们为女性发声,并致力于推动男女同工同酬,促进女性就业和晋升等。这样的项目和组织会在不同国家出现,以不同速度推进,因为这是对的方向,也是我们应该做的工作。


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

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