期间: 2019
Heavy Cardboard
Heavy Cardboard 是一个专注于桌游的媒体频道,由 Edward Uhler 运营。我第一次接触它的时候,它还只是一个播客,我喜欢它是因为它评论了我感兴趣的游戏类型,并且评论的深度足以让我很好地了解我是否会对这款游戏感兴趣。后来它增加了一个视频频道,在 Youtube 上直播游戏。我很少观看直播,但经常发现观看录制视频有助于我决定是否喜欢一款游戏。我还发现,Edward 在每次直播前都会讲解规则,这是学习如何玩游戏的有效方式。我非常喜欢这个节目,成为了它的赞助人,并且很喜欢只对赞助人开放的 Slack 频道。这是一个很有用的讨论论坛,也是我参与过的最令人愉快的在线团体之一。
探索性测试
探索性测试是一种强调快速学习、测试设计和测试执行循环的测试风格。探索性测试不是试图验证软件是否符合预先编写的测试脚本,而是探索软件的特性,发现问题,然后将其归类为合理行为或故障。
瀑布模型
在软件领域,“瀑布”通常用于描述一种软件过程风格,它与迭代或敏捷风格的理念形成对比。与软件领域中的许多知名术语一样,它的含义定义不清,起源也不明——但我发现它的核心主题是根据活动将一项大型工作分解成多个阶段。
机器学习的持续交付
机器学习应用正在我们的行业中变得越来越流行,然而,与更传统的软件(如 Web 服务或移动应用)相比,开发、部署和持续改进机器学习应用的过程更加复杂。它们在三个方面都会发生变化:代码本身、模型和数据。它们的行为通常很复杂,难以预测,而且更难测试、更难解释、更难改进。机器学习持续交付 (CD4ML) 是一门将持续交付原则和实践应用于机器学习应用的学科。
不要为了避免供应商锁定而陷入困境
架构设计的大部分精力都花在了减少或避免供应商锁定上。这是一个相当崇高的目标:架构的目的是为我们提供选择,而供应商锁定则恰恰相反。然而,供应商锁定并不是一个简单的真假问题:避免被锁定在一个方面往往会让你锁定在另一个方面。此外,一些流行的观点,比如开源软件可以自动消除供应商锁定,也被证明并非完全正确。是时候仔细研究一下供应商锁定问题了,这样你就不会为了避免它而陷入困境!
Heavy Cardboard 对《璀璨宝石:伯明翰》的评测
《璀璨宝石:伯明翰》 是一款现代桌游,玩家在工业革命中建立起一个由煤矿、啤酒厂和铁路组成的工业帝国。Edward 和我将对这款游戏进行详细的评测:评估其难度、评测其组件,并概述我们喜欢这款游戏的哪些方面。播客以我们最近的游戏体验开始,我谈了一些我的游戏背景——实际的评测从 1:16 开始。
2018 年网站报告
在 2019 年伊始,回顾一下 martinfowler.com 的现状似乎是个好主意。我做了一个简短的网站回顾 早在 2014 年,所以现在是时候再来看看它带来的流量了。
微前端
做好前端开发很难。扩展前端开发,以便多个团队可以同时在一个大型复杂产品上工作,就更难了。在本文中,我们将描述最近将前端巨石应用拆分成许多更小、更易于管理的部分的趋势,以及这种架构如何提高前端代码团队的工作效率和效益。除了讨论各种好处和成本之外,我们还将介绍一些可用的实现方案,并深入探讨一个完整的示例应用程序,以演示该技术。
DevOps 状态报告
DevOps 状态报告是一份年度报告,它使用调查数据的统计分析来确定软件交付组织的有效实践。其主要作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。
高质量软件值得投入成本吗?
软件开发项目中一个常见的争论是,是花时间提高软件质量,还是专注于发布更有价值的功能。通常,交付功能的压力主导着讨论,导致许多开发人员抱怨他们没有时间来处理架构和代码质量。这场争论是基于一个假设,即提高质量也会增加成本,这是我们的共同经验。但与直觉相反的现实是,内部软件质量消除了拖慢新功能开发速度的障碍,从而降低了增强软件的成本。
技术债务
软件系统容易积累 障碍——内部质量的缺陷,这使得修改和扩展系统变得比理想情况下更加困难。技术债务是一个比喻,由 Ward Cunningham 创造,它构建了如何处理这些障碍的思路,将其视为金融债务。添加新功能所需的额外努力就是为债务支付的利息。
如何从单体数据湖迁移到分布式数据网格
许多企业正在投资于他们的下一代数据湖,希望大规模地实现数据民主化,以提供业务洞察力,并最终做出自动化的智能决策。基于数据湖架构的数据平台具有常见的故障模式,导致无法兑现大规模承诺。为了解决这些故障模式,我们需要从以湖为中心的范式或其前身数据仓库转变。我们需要转向一种借鉴现代分布式架构的范式:将领域视为头等大事,应用平台思维来创建自助服务数据基础设施,并将数据视为产品。
面向领域的 Observability
在我们的软件系统中,Observability 一直很有价值,在这个云计算和微服务时代更是如此。然而,我们添加到系统中的 Observability 往往是相当低级的技术性质,而且它似乎经常需要在我们代码库中添加各种冗长、笨拙的日志记录、检测和分析框架调用。本文描述了一种模式,可以清理这种混乱,并允许我们以一种干净、可测试的方式添加与业务相关的 Observability。
供应商锁定成本
在我最近的客户互动中,我预见到无服务器架构是一个完美的解决方案。然而,由于担心供应商锁定,采用无服务器架构的想法并没有得到我们客户的认可。对于零售商来说,这是一个有趣的时期,因为留在 AWS 可能意味着亚马逊作为另一家零售企业将获得竞争优势。考虑到不支持竞争对手的想法,我的客户有兴趣确保我们选择的解决方案可以完全移植到其他云供应商。