Skip to main content

敏捷咨询日记——匠人精神

“敏捷,是一种匠人阶层的唤醒”

我曾经拜访过印度某个Freemason(共济会)分所,这个世界上最大地下组织来源于传说中制造巴比伦神殿的三个石匠。教谕认为石匠是人类中掌握自然奥秘的一群人,常人只是“神有缺陷的复制品”,而只有靠匠工的不懈努力才能修补人类缺陷使其更接近于神。这也是为什么共济会的标志便是圆规和方矩,方圆规矩的隐喻在六芒星下变得直白。

也许西欧文明开化来自于匠工阶层精英化,不论是对技能技巧的极致追求,或是家族荣耀的逐代传承,这样的阶层似乎在可以营造一种近乎偏执的质量文化。之后,匠人阶层的经验和行规在大生产时代演变成各种制造业雏形,最终演化成一种现代的规模化的制造业体系。从匠人阶级到现代制造业体系,必然是某种技能精益,经验积累,和规则验证极致后模式化规模化的演变。而究其根本,其核心充满着精益中两大核心:“以人为本”-社区荣誉(community honor)和家族传承;“持续改进”-技能演进,经验积累。

相对于西欧文明,我一直苦恼于为何从未断代的华夏文明始终未曾在历史的任何时刻诞生一个类似的匠人阶层。匠人这个在欧洲曾经被认为是改造自然改造人类的职业,在中国被关闭在始皇帝的骊陵中殉葬。不止一次在伦敦的大英博物馆感叹同时期中国的器物精细之程度远胜于欧洲其他文明,但惋惜的是,繁荣延续的匠人阶层未曾出现,更未曾产生过一个趋于成熟的制造业体系。

值得一提的是,欧洲文明善于制作工具,华夏文明善于制作器物本身。工具的目的是为了传承技术,传承技术的目的是为了改进技术,而若只关注于极致精细器物本身,只能理解为中国曾经出现的伟大匠人更关注于“孤品”,或者是更关注于权威绑架。

从精益中衍生的质量文化实际上是对匠人阶层的一种传承,近乎偏执的关注质量,并使用专属的工具和执行相关的流程保证质量,这必是对16世纪共济会繁荣时代(也是工业时代开始的萌芽期)致敬。

很多次,我被告知“以人为本”不可能实现,我忍不发,因我明白匠人们自古以来只是领导者手中更高级的工具,只需做,不必问。而我真正希望做的,是在某种程度上唤醒我们缺失了千年的匠人荣耀,让他们清晰地听见,如果人类走向完美的历程为敏捷项目,他们便是骄傲的交付者。

本文转自:http://i25zt5.lawrence-gd.diancloud.cn/agile-craftman/

Share

20天3D打印总结

Screen Shot 2015-04-22 at 12.24.17 PM

mbot cube 3D打印机拿到手也有20多天了,有空就玩玩,还是做了一些好玩实用的东西出来,总结一些经验来分享。总体来讲3D打印技术还不是太难掌握,对于打印素材来源及模型选择有一些讲究,要特别注意一些模型打印起来非常困难,甚至无法打印。

模型来源

我自己的3D模型主要来源于thingiverse网站,丰富的模型分类及社区的力量提供了非常多的资源。很可惜的是中国访问奇慢,主要原因是网站使用了亚马逊S3和cloudflare云,这两个基本被中国屏蔽,要不就是慢的死人。所以一个给力的代理是唯一的解决方案,否则你会失去很多的乐趣。代理可以参考我之前的shadowsocks在digitalocean上用的例子。

国内有一个叫“天工社”的论坛,上面有很多的模型可供选择,我看大部分还是来自于thingiverse网站的,有些人靠这些来赚积分。

在thingiverse网站上,我做自己做了一些东西,请直接打开网站看

一些成功的例子

失败的例子

模型的选择

尽量不选择太复杂太精细的模型,有些细小的部件,打印机会吐出来一点材料,根本无法顺利的打印出来。有些结构一次性打印的话需要很多的支撑材料,这些支撑会产生很大的麻烦,去除材料的时候会显得很郁闷。当然如果你的打印机是双头的,并且有水溶的材料,那就另当别论了。

所以比较好的模型都是一些稍微简单,甚至是组装的模型。组装的模型比较好打印每个部件,但是有些接插件会遇到无法插入的问题。内孔一般会缩小,外孔一般会变大,这和孔的大小有关。一般得后处理一下。由于我的材料一直是PLA的,所以试过用钻枪扩孔,但是效果不好,钻头会卡在洞里面。另外要注意有些模型如果提供了细杆之内的,强度一般都不会够,对于PLA很容易就折断了。

完全插不进去的外壳,其中一个装齿轮的细杆已经折断

打印模型的时候的方向也比较重要,要看你的模型在什么方向上需要什么的精度。Z方向的精度似乎比较差,XY的还比较靠谱。对于一些比较尖的部件,如果到最后只有这个尖的东东,则打印头会持续的在附近一栋,造成温度很高,下层的尖会软化,导致整个模型报废。所以可以在旁边比较远的地方放一个无关紧要的物件,这样打印头会移动开,等再回来的时候就已经冷却了。

翘边问题

刚拿到打印的时候,基本上都会翘边,还是PLA材料啊。后来打电话给售后问有没有比较好的办法,他们推荐用3M胶带。但是3M胶带实在是太难贴了,而且贴完了打印后会影响底层的平整度。如果贴的位置不是很恰当,还是会造成一些翘边,甚至中间凹陷的情况。

3M胶没有hold住,很难知道哪些地方需要贴
3M胶,造成底部凹凸不平

后来买了蓝色的3M美纹纸胶带,完美解决问题。非常好贴,而且效果很好。
美纹胶,完美解决
儿子很喜欢

打印软件

ReplicateG

这个开源软件很古老了,已经停止更新。试过一两个模型速度都非常的慢,而且界面不好用。还是最好别用这个了。

MPrint

MBot3D自己出的软件,易用性还算过得去,生成速度也挺快的,能够预览生成的路径,看到打印时间和材料克数。win平台和mac都有。作为初学及简单的配置还是很方便的。

不方便的地方在于没有像Slic3r或者Cura提供的打印一个底层边界的功能(不是底垫哈),这样刚开始打印的时候打印后没有材料挤出,要等上几秒钟才连续出料,造成一部分底层打印失败。办法是自己做个物体放在旁边,或者打印底垫。
Screen Shot 2015 04 22 At 12.24.17 PM

Slic3r和Cura

开源利器,两个软件不相上下,我还是比较喜欢Cura,界面比较好用一些。

刚开始用的时候,需要设置好边界,mbot cube我最大设置为200左右,太大的话会造成XY移动到最外面撞到。打印机是没有限位开关的,所以会导致电机堵转或者跳齿,很伤机械。还有一个Machine Settings选项:Machine Center 0,0,如果没有设置,则会按照左上角为0,0,会撞车。

0,0
具体设置可以参考:https://github.com/derekhe-3dprinting/print-settings

材料

当时买机器的时候给了一卷透明的PLA,但似乎材料有些问题,打印效果不好,比较粗糙。后来买了个橘红色的PLA,就好了。

PLA还是比较脆的,有一些玻璃的质感。橘红色的打印出来还是比较好看,但是透明的就完全瞎火。
比较漂亮
修锁扣,强度还是不错
透明的很难看

上色

最安全的方式上色还是用丙烯材料好了,需要涂得比较厚一些后期才不会开裂和掉色。可以借助吹风机速干。
涂的太薄,干了就掉

吐槽打印机

这个打印机价格还是不便宜,要是双头的价格都5200多了。打印的噪音还是比较大,关了门还能听得到明显的噪音。可能是出厂的时候质量有一些问题,Y轴似乎是直线轴承出了问题,方向移动的时候嘎嘎嘎的响。联系的厂商给免费维修,只不过要寄回去比较麻烦。

为了减少噪音,是否需要在外面加一层盖子,这个我还在考虑之中,看轴承修好了以后会不会好一些。

对比Flashforge的creator pro,这个机子的底板能够能够取下板子比较好,毕竟在机器里面拆模型不是非常的方便,贴胶也不好贴。

 

本文转自:http://www.april1985.com/2015/03/25/2015-03-25-3d-printing/

Share

2015.5 技术雷达 | 平台篇

   点击这里可以下载最新中文版本PDF

Apache Spark(spark.apache.org)作为一种快速和通用的大规模数据处理引擎已取得稳步进展。该引擎基于Scala实现,非常适合于那些在多并行操作之间重用数据工作集的应用程序。它即可以作为一个独立集群,也可以作为Hadoop的YARN集群的一部分来工作。它可以从不同的源来访问数据,比如 HDFS,Cassandra,S3 等。不仅如此,Spark还提供了许多更高级的操作符,以便简化数据并行应用程序的开发。作为一种通用的数据处理平台,它使许多更高级别的工具的开发成为可能,如交互式SQL(Spark SQL),实时流媒体(Spark Streaming),机器学习库(MLib),R-on-Spark等。

一段时间以来,Hadoop 社区一直在尝试把低延迟和交互式 SQL 查询能力带到Hadoop平台中(称为SQL-on-Hapdoop)。开源数据库引擎 Cloudera Impala,Apache Drill 和 Facebook的 Presto 都在2014年应运而生。我们认为,SQL-on-Hadoop 这一趋势标志着一个重要的转折,它将 Hadoop 的定位从与数据库互补的批处理,转变为某种可以与之竞争的技术。

Cloudera Impala(cloudera.com/content/cloudera/en/ products-and-services/cdh/impala.html)是早期的SQL-on-Hadoop 平台之一。它是一个基于C++的,支持大规模并行处理的分布式查询引擎。Impala 守护进程是这个平台的核心组件,其负责协调 Impala 集群中跨一个或多个节点间 SQL 查询的执行。 Impala 充分利用了 Hive 的元数据目录来共享两者的数据库和表。Impala 还提供了命令行工具以及 JDBC 和 ODBC 驱动程序供应用程序使用。

密码仍然是一种糟糕的用户认证机制。近来我们看到有公司(如Yahoo!)采用了“无密码”的解决方案——每当你需要从一个新的浏览器登录时,一个一次性验证码会被发送到你的手机来进行认证。如果你仍在使用密码认证,我们推荐您采用能够显著提高安全性的双阶段认证(two-factor authentication)机制。基于时间的一次性密码算法(TOTP)(en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm)是目前这个领域的标准,在 Google(play.google.com/store/apps/details?id=com.google.android.apps.authenticator2)和 Microsoft(windowsphone.com/en-us/store/app/authenticator/e7994dbc-2336- 4950-91ba-ca22d653759b)智能手机中都这样免费的认证应用。

Apache Kylin (kylin.io),是一个来自 eBay 公司的开源数据分析解决方案,它能够在超大数据集上进行基于 SQL 的多维度分析(OLAP)。Kylin 旨在构建一个基于 Hadoop 的混合 OLAP (HOLAP) 解决方案,最终将能够支持 MOLAP 和 ROLAP 风格的多维分析。你可以使用 Kylin 所提供的立方体设计器来定义立方体,并启动一个离线进程来构建它们。离线进程会进行一个预连接的步骤,将事实表和维度表连接到一个扁平化的结构中。下一个是预聚合阶段,各个单独的立方体被 Map Reduce 任务会构建出来。其结果被存储在 HDFS 序列文件中,之后被载入 HBase 。数据请求可以由基于 SQL 的工具提交 SQL 产生。查询引擎(基于 Apache Calcite)会决定目标数据集是否在 HBase 中存在。如果存在,该引擎会直接访问 HBase 中的目标数据,以次秒级延迟返回结果。如果目标数据集不存在,该引擎会将这些查询转向 Hive(或者是集群中任何其它可以用 SQL 查询 Hadoop 的方案)。

CoreCLR (github.com/dotnet/coreclr) 和 CoreFX (github.com/dotnet/corefx) 是 .NET 的核心平台和框架。虽然算不上是什么新闻,他们最近被微软开源了。一个主要的变化是这些依赖是基于二进制文件来部署的,不再需要事先安装在机器上。这使得并行部署变得容易,允许应用程序可以无冲突的使用不同版本的 .NET 框架。你可以安装 .NET 依赖到任何环境中,基于 .NET 编写代码成为了一个实现细节。从外部依赖的角度来看,一个用.NET实现的工具与用 C 语言编写的东西并没有什么不同,这就使它成为编写通用应用程序和工具的一个更有吸引力的选择。CoreFX 也已被分解为独立的 NuGet 依赖,从而使应用能够按需使用,这让 .NET 的应用和库占的空间的更小,并使得替换部分框架更加容易。

Heroku 用它的12要素应用模型改变了我们关于构建、部署、托管 Web 应用的方式。Deis (deis.io) 将 Heroku PaaS 模型封装到一个开源框架中,部署在可被托管在任何地方的 Docker 容器中。Deis 仍在进化当中,但对于那些符合12要素模型的应用来说,它具备大大简化部署,并在你自选的环境中进行托管的潜力。Deis 也已成为 Docker 周边丰富的平台和工具生态系统中的又一鲜活事例。

预测分析在越来越多的产品中被使用,而且通常出现在面向最终用户的功能上。H2O (docs.0xdata.com) 是一套非常有意思的新开源工具包(其背后是一家创业公司),因为其易用的用户界面设计,使得预测分析对项目组更可用。同时它还集成了数据科学家最喜欢的一些工具:R 和 Python 语言,以及 Hadoop 和 Spark。H2O提供了很高的性能,并且依我们的经验,非常易于在运行时集成,特别是在基于 Java 虚拟机的平台上。

当 Oracle 决定停止对 Sun 公司的 OpenSSO(一个开源的访问管理平台)进行开发时,ForgeRock 决定接管它并将它集成进他们的 Open Identity Suite 中。现在它被命名为 OpenAM (forgerock.com/ products/open-identity-stack/openam) ,成为了一个支撑 OpenID 连接和 SAML 2.0的可扩展的开放源码平台。不过,由于 OpenAM 历史悠久,导致它的代码库很庞大,并且文档也很难理解。希望在不久后,一个更轻量级的,对自动化部署和配置提供更好支持的替代方案将会出现。

Spark 是基于云的互联设备全栈解决方案,Spark Photon 是一个带 wifi 模块的微控制器,而 Spark electron 是连接到移动网络的变体。Spark 操作系统为这些设备添加了 REST API 服务。这套解决方案降低了进入物联网,并构建你自己的可连接设备的门槛。

时间序列数据库(TSDB)是一种针对时间序列数据的处理做了优化的系统。它允许用户对各种以时间序列组织起来的数据库对象进行 CRUD 操作。同时它还可以在整个序列上执行统计计算。虽然时间序列数据库不是一个新的技术,但是我们还是在这些数据库应用中看到了一些新的热点,尤其是在物联网应用领域。在许多开源和商业平台(比如OpenTSDB, InfluxDB, Druid, BlueFloodDB 等等)的促进下,时间序列数据库技术发展迅猛。另外还值得一提的是,其中一些数据库产品还使用了类似 Cassandra 和 HBase 的分布式数据库作为他们的底层存储引擎。

容器技术,PhoenixServer 以及持续交付的崛起已经开始让我们摆脱昔日部署 Web 应用的方式。传统方式是我们需要构建出应用工件,然后将工件安装到应用服务器中。这种方式会导致较长的反馈周期,构建时间的变长,以及在生产环境中管理这些应用服务器的开销变大。除此之外,这些应用服务器也很难做自动化。在与我们一同工作的很多团队中,开始倾向于将 HTTP 服务器嵌入到应用中。有很多可以选择的嵌入式服务器:Jetty, SimpleWeb, Webbit 和 Owin 等。更容易做自动化,更容易做部署,对基础设施的投入也会减少,因此我们推荐在未来的项目中使用嵌入式的应用服务器而不是传统的应用服务器。

Google 从2009年开发了一个实验性质的协议 SPDY (chromium.org/spdy/spdy-whitepaper),作为一个替代协议,它用于解决 HTTP/1.1中的一些性能短板。新的 HTTP/2 标准协议包含了很多 SPDY 中性能优化的关键特性,Google 已经宣布从2016年初就会停止在浏览器中支持 SPDY。因此,如果你的应用需要 SPDY 中的特性,我们推荐你去尝试 HTTP/2。

点击这里可以下载最新中文版本PDF

Share

敏捷咨询日记——消除浪费

waste

当我们追根溯源敏捷最先被发明的初期,可以发现,敏捷所消除的便是因为频繁业务需求改变带来的潜在浪费,而一切关于杜绝浪费话题到最后,都变成为对价值的纯粹追求。任何商业模式都基于创造新用户和挽留老用户,最终也被细化为为新用户提供不可替代的新价值和为老用户提供持续改进的旧价值(当然同样可为新价值)那么两件事情被认为是杜绝浪费最重要的两个方面:

  • 只给客户想要的;
  • 让客户简单地用到他们想要的;

简而言之,做了没用的和没用已经做了的是最普遍的两种浪费。二者间的关系是:做了没用的往往的结果是未使用,但未使用往往不止是因为没有用(也许你不够好)。

一个简单的对话可能会揭示这个道理。gigix在贴卡片的时候使用了没有ThoughtWorks logo那一面,我问:用反面的价值是什么?gigix说:我顺手写在了反面。我说:那你就把 logo marketing的价值浪费了。gigix便马上在正面重写。可以看出,在卡片的正面印上公司标志是一件具有市场推广和提高品牌认知价值的事情,我们也同意这种价值是实际需要,但是有50%的情况我们可能会忽略这个价值,于是,这个价值便被浪费了。

据说这个卡片的成本是两毛钱,而印刷logo的成本可能是1毛钱(印logo的唯一价值就是展示出来,于是不展示出来的浪费就是100%),每年全球范围内整个公司的卡片消耗量估计有51万张(一个人一年大概消耗300张,一年就是300X1700=510000张)于是理论上每年因为没有展示公司logo造成的浪费就是25500元。

解决这个办法有两个,长期的,如果每个TWer都有一种价值驱动的自然反应,把浪费扩展到日常生活中去,这个价值被浪费的几率可能减少;短期的,两面都印logo的成本理论上比一面印一面不印还要低,而当两面都有的时候,这种浪费便不可能发生,甚至成本更低。

这就是为什么用户体验被拔高到一个很高的地步,良好的用户体验可以更容易地把有用的价值传递到用户使用过程中,而很可能,往往被忽视,这是一个投入低于可能产生的价值浪费的过程。

敏捷当中关于杜绝浪费的阐述,绝对不应该只是个适用于软件开发(或精益制造)的概念,它应该贯彻到所有日常管理开发的过程中。有时候,我会刨根问底地询问某个内部管理表格上某行小字表述的意思,或者某个状态图中某个多余标签颜色的目的,甚至关于饮水机摆放位置的斟酌。

当各种询问进行之后,你会惊奇地发现,这样的价值最后一定被认为阻塞在一个更高级阶层人物的脑中,而所有人要做的只是忍受一次便接受这种浪费。而这样的现象成为一种奇特的人类自适应习性,特别是在一个具有组织结构的环境里,人们不加思索地游走忍受各种浪费,或者说有意识的拿出可能百分之一的生命作为浪费,而不去质问这个所谓深藏在高阶人士脑中的某个模式。而更神奇的是,这样的组织结构似乎就是为了种容忍浪费的习性提供养料,他们用权威语言(community language)描述这种可能产生浪费的活动,用意识形态的方式提高质问的门槛,他们用一种容忍浪费的高明手段来杜绝“浪费”,这种“浪费”被理解为更多的投入,或者改变,或者干脆就是自己权重更大的时间。

更深层次讨论这个问题这样的浪费被打造成一种十分有效的管理手段,因为我们的文化里,当你不懂我的时候,浅意识里我高过你,当你懂我的时候,你可能高过我,换言之,阻塞价值传递带来的心理慰籍多于价值广达于人。于是,如同状元可当驸马入赘皇族给天下清苦寒士打一针鸡血一样,这种“你不必懂,你只需做”的潜台词,成为底层工作者努力上进的“状元奖品”。同时,不可避免的是,各种浪费在这庞大的机器里不停被产生,讽刺地是,某种意义来说这样的浪费便成了机器运转的润滑剂,我们的发展不也是基于更庞大的物质浪费吗?

或许,我说到了最苦恼的地方,我努力尝试把敏捷方法跳出制造业(基于流程的软件业也是一种制造)而更多地作为一种现代企业管理方法论引入企业日常管理当中去,而似乎,敏捷原则的桎梏在于对人的依赖,以及是不是还有权威与非权威的概念,回到刚才的例子,如何保证所有质问的价值都是低于浪费本身的-万一大部分人的质问都是无理取闹?权威“不必问,只需做”的方式是不是本身也是一种杜绝浪费?

就此来看,敏捷方法还有很多值得思考的东西,但杜绝浪费初衷本身是值得肯定的。

本文转载自:

Share

2015.5 技术雷达 | 技术篇

点击这里可以下载最新中文版本PDF

2015-5 技术

当多个独立开发的服务通过 API 交互的时候,API 提供端的改动会让它所有的消费端调用失败。消费端服务通常也不会直接去连接处于开发中的提供端服务来进行测试,因为这样的测试是缓慢且脆弱的(martinfowler.com/articles/ nonDeterminism.html#RemoteServices),因此最好的方式是采用测试替身(martinfowler.com/bliki/TestDouble. html),但这又引出了测试替身和实际的 API 之间失去同步的风险。消费端的开发团队可以通过使用集成的合约测试(martinfowler.com/bliki/IntegrationContractTest.html)来保护自己——其比较真实服务的响应和测试替身之间的一致性。这样的合约测试是非常有价值的,而更有价值的方式是消费端把它们的测试提供给 API 提供端——采用消费端驱动的合约(martinfowler.com/articles/consumerDrivenContracts.html),提供端可以运行所有消费端所提供的测试来验证自己的修改是不是有可能引起问题。这种消费者驱动的合约测试(consumer-driven context test)是成熟的微服务测试策略(martinfowler.com/articles/microservice-testing/)中非常核心的组成部分。

当我们需要一张描述当前系统的基础设施或物理架构的图形时候,我们通常会选用自己最喜欢的工具来绘制。但是当你使用云或者其他虚拟化技术的时候,这种方式却不再适用。我们可以使用这些平台本身提供 API 去查询实际的基础架构环境,并使用一些简单的工具比如 GraphViz(graphviz.org),一些可以输出 SVG 格式的工具,生成实时的,自动化的基础架构图(automated infrastructure diagram)。

离线优先 Web 应用程序(Offline first web applications)提供了基于缓存和更新机制来设计 Web 应用离线访问的能力。它的实现需要在 DOM 中设定一个标志来检查接入设备是否在线,离线则访问本地存储,在线则同步数据。现在所有的主流浏览器都支持离线模式,通过显示的指定 HTML 属性来使本地信息可访问,同时启动如 HTML, CSS,Javascript 或其他资源的下载和缓存。当前已经有一些工具使离线优先应用的实现变的简单,如 Hoodie(hood.ie),CouchDB(couchdb.apache.org),不仅如此它们还提供与本地部署的本地存储应用的集成能力。

大多数软件开发的心智模型都是做项目,在不同的档期内进行计划、执行和交付。敏捷开发极大的挑战了这种模型,通过与开发过程同时进行的持续需求发现,代替了预先的需求确定。精益创业的技术,如观察需求的 A/B 测试(martinfowler.com/bliki/ObservedRequirement.html),进一步削弱了这种心态。我们认为,大多数的软件开发工作应该遵循精益企业的引领(info.thoughtworks.com/lean-enterprise-book.html),将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付,更多的是一个探索如何更好的支持和优化业务流程的过程,只要业务依然有价值就会不断持续下去。基于这些理由,我们提倡企业组织依照产品而不是项目(products rather than projects)的思路进行思考。

当前大多数开发团队都意识到编写安全软件并以负责任的方式处理用户数据的重要性。他们确实面临着陡峭的学习曲线和大量的潜在威胁,其范围从有组织的犯罪和政府的间谍活动到仅仅是为“玩笑或激怒什么人”而攻击系统的年轻人。威胁建模(Thread modeling)(owasp.org/index.php/ Category:Threat_Modeling)是一组技术,主要从防御的角度出发,帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时,这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

Flux(facebook.github.io/flux)是 Facebook 为其互联网应用开发所采用的一种应用架构。它通常与 react.js 一同被提及,Flux 基于一个单向数据流,用户或外部事件对数据存储的修改会触发数据在渲染管道中向上流动。已经有好一阵子我们都没有看到任何古老的model-view-*架构的替代者了,Flux 拥抱这种 Javascript 前端应用与多个后端服务通信的现代互联网时代。

当前,大部分开发人员习惯使用 git 来管理源代码以及协作。但是,git 还可以为其他一些情况提供基础的实现机制,比如当人们需要使用基于文本化的文档进行协作的时候(这些文档可以被很容易的合并)。通过使用基于文本的可编辑格式,我们已经看到越来越多的项目把 git(git-scm.com)作为一个轻量化的 CMS 来使用。Git 有很多强大的功能,通过使用分布式的存储模型,Git 可以支持对变化的跟踪以及寻找替代品。然而,难于大范围采用 Git 的最大原因是 git 对于非编程开发人员来说并不容易学习,而我们期望看到更多的构建在 git 核心之上的工具的出现。这类工具可以为一些特殊听众简化他们的工作流程,如作为内容的作者。我们也欢迎更多的工具支持对比和合并非文本文档。

凤凰服务器(martinfowler.com/bliki/ PhoenixServer.html)的想法现在已经被很好的建立并且在被应用到一些正确的问题上时带来了很多好处。而我们要部署的服务器所依赖的环境,如在某些情况下需要等待网络配置、负载均衡、防火墙端口等等情况,却已逐渐成为修改配置时的主要瓶颈和限制。凤凰环境的概念可以帮助这种情况。它允许我们可以用自动化的方式创建整个环境并保证定期销毁和重建整个环境的流程正确,例如在AWS上使用CloudFormation。凤凰环境可以支持为测试,开发,UAT等等配置一个全新的环境。它也可以简化对灾难恢复环境的配置。由于凤凰服务器的模式并不总是可行的,我们需要小心地对待诸如状态和依赖,在蓝绿部署中用它对环境配置进行重置可以成为一种方式。

函数式反应型编程在过去的几年渐渐开始流行起来,同时这个概念越来越多被延伸到在分布式系统架构中。根据反应型编程宣言(reactivemanifesto.org),反应型架构(reactive architectures)主要基于通过一个网络下独立进程间的单向,异步的不可变事件流(可能具体实现为微服务)。在正确设置下,基于这种架构的系统容易扩展,具有弹性,也会减小了各个独立处理单元间的耦合。但是完全基于异步消息传递的架构同时会引入相应的复杂度,并且常常会依赖于一些专有的框架。所以我们推荐在选择这种架构风格前首先了解自己系统对于性能以及可扩展性的需求。

对于安全,传统的方式依赖于前期的需求规格以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队,因为大部分设计都贯穿于整个过程,而且也没有持续交付所提供的自动化便利。公司或者组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括:正确评估当前威胁模型的级别以做前期设计;考虑何时将安全问题划分为独立的故事、验收标准、或全局的非功能性需求;在构建流水线中引入静态或动态的自动化安全测试;考虑如何将更深层次的测试,如渗透测试,引入到持续交付的发布过程中。正如 DevOps 的出现使得过去相互博弈的团队能够重新合作一样,同样的事情也正发生在安全人员和开发人员身上。(尽管我们并不喜欢安全三明治模型,但这也比根本不考虑安全要好得多,糟糕的是,这依然是一种非常普遍的状况。)

 

点击这里可以下载最新中文版本PDF

Share