我在 2020 年最喜欢的六首新音乐

我们渴望用数据增强和改进商业和生活的方方面面，这需要我们改变大规模管理数据的方式。 虽然过去十年的技术进步解决了数据量和数据处理计算的规模问题，但它们未能解决其他方面的规模问题：数据环境的变化、数据源的激增、数据用例和用户的多样性，以及对变化的响应速度。 数据网格解决了这些维度，它基于四个原则：面向领域的去中心化数据所有权和架构、数据即产品、自助服务数据基础设施即平台以及联合计算治理。 每个原则都推动了技术架构和组织结构的新逻辑视图。

计算笔记本是一个用于编写散文文档的环境，它允许作者嵌入代码，这些代码可以轻松执行，结果也可以合并到文档中。 这是一个特别适合数据科学工作的平台。 此类环境包括 Jupyter Notebook、R Markdown、Mathematica 和 Emacs 的 org-mode。

我们遇到过许多客户，他们有兴趣采用数据科学家开发的计算笔记本，并将它们直接放入生产应用程序的代码库中。 数据科学理念确实需要走出笔记本电脑并投入生产，但试图将笔记本电脑作为代码工件进行部署会破坏许多良好的软件实践。 可以预见，这会导致许多观察到的痛点。 这种行为是一个更深层次问题的征兆：数据科学家和软件开发人员之间缺乏协作。

一个误导性的标题，旨在吸引读者阅读偶尔真实的故事

当出现来源可疑的新闻报道时，社交媒体是否应该使用临时封锁来减缓其传播速度？

Google 表格脚本是一种方便非程序员共享简短脚本的方式。

为什么投票反对特朗普总统及其支持者很重要。

在商务会议中，通常通过比较数字组的平均值来比较它们。 但这样做通常会隐藏这些组中数字分布中的重要信息。 有许多数据可视化可以揭示这些信息。 这些包括条形图、直方图、密度图、箱线图和小提琴图。 这些可以使用免费提供的软件轻松生成，适用于小到十几、大到数千的组。

由于无法前往澳大利亚参加 2020 年 XConf 大会，我改为与 Thoughtworks 澳大利亚技术主管 Scott Shaw 进行了 Zoom 会议。 我们讨论了数据在现代应用程序开发中不断变化的作用：应用程序开发人员和数据库之间的鸿沟、大（且混乱）数据的出现带来的变化、提高数据素养的需求，以及收集投机数据的社会影响。

goto conferences 邀请我采访 Sam Newman 关于他的书：“从单体到微服务”。 这变成了关于微服务以及何时使用它们的对话。 Sam 认为它们独立部署、数据隔离和反映组织结构是三个主要原因。 我对第一个持怀疑态度，但认为数据和人员是软件开发中复杂的组成部分。

对 1953 年伊朗政变纪录片《政变 53》的简短评论。

对 Kinesis Advantage2 人体工学键盘的简要评测，我已经使用它三年半了。

我们的欧洲“数据女巫”Em Grasmeder 和我原本计划在欧洲的 XConf 系列会议上发表主题演讲。 由于是 2020 年，我们改为使用 Zoom 进行了会议，并讨论了数据科学家的角色：该角色的实际意义、他们需要掌握的工具，以及他们与其他形式软件开发的关系。

本文提供了清晰简单的步骤来帮助希望采用威胁建模的团队。 威胁建模是一种基于风险的安全系统设计方法。 它基于识别威胁以制定缓解措施。 随着网络安全风险的增加和企业对其责任的认识越来越高，软件开发团队需要有效的方法将安全性构建到软件中。 不幸的是，他们经常难以采用威胁建模。 许多方法都需要复杂、详尽的前期分析，这与现代软件团队的工作方式不符。 因此，我鼓励团队从小处着手，逐步发展，而不是为了创建完美的威胁模型而停止一切。

现代源代码控制系统提供了强大的工具，可以轻松地在源代码中创建分支。 但最终这些分支必须合并在一起，许多团队花费了过多的时间来处理他们错综复杂的分支。 有几种模式可以让团队有效地使用分支，集中于整合多个开发人员的工作并组织生产发布的路径。 最重要的主题是应该频繁地整合分支，并将精力集中在可以轻松部署到生产环境中的健康主线上。

功能分支是一种源代码分支模式，开发人员在开始处理新功能时会打开一个分支。 她在该分支上完成该功能的所有工作，并在该功能完成后将更改与团队其他成员集成。

暗启动一项功能意味着采用新的或更改后的后端行为，并从现有用户那里调用它，而用户无法分辨它是否被调用。 这样做是为了在公开宣布新功能之前评估系统上的额外负载和性能影响。

某些程序元素天生难以甚至不可能测试。 因此，这些元素中的任何逻辑都容易出现错误并且难以发展。 为了缓解这个问题，请将尽可能多的逻辑从难以测试的元素中移出，并移入代码库中其他更友好的部分。 通过使不可测试的对象变得谦卑，我们减少了它们隐藏邪恶错误的可能性。

软件开发团队发现，如果他们尽可能频繁地集成他们的工作，生活会轻松得多。 他们还发现经常发布到生产环境中很有价值。 但团队不希望向用户公开半成品功能。 处理这种紧张关系的一种有用技术是构建所有后端代码、集成，但不构建用户界面。 该功能可以集成和测试，但 UI 会一直保留到最后，直到像基石一样将其添加到完整功能中，向用户公开。

领域驱动设计是一种软件开发方法，其核心是围绕对领域的过程和规则有深入了解的领域模型进行编程。 该名称来自 Eric Evans 2003 年出版的一本书，该书通过模式目录描述了这种方法。 从那时起，一个从业者社区进一步发展了这些想法，催生了各种其他书籍和培训课程。 该方法特别适用于需要组织大量经常混乱的逻辑的复杂领域。

在本文中，我将介绍来自真实代码库的一组重构。 这并非旨在展示完美，而是代表现实。

结对编程是一种软件开发实践，开发人员两人一组工作。 所有严肃的代码都是由两名程序员编写的，他们通常并排坐着，使用一台显示器，通常使用一个键盘。 在添加代码时，他们会一起讨论每个步骤。

获得良好的音频，使用图库视图，如果不说话请静音，并欢迎猫的加入。

关于 Thoughtworks 如何应对 2019 冠状病毒病 (Covid-19) 爆发的第二篇文章

我们和我们的同事经常被要求为我们的客户执行架构评估。 当我们这样做时，参与这些系统的架构师会谈论这些系统的性能、它们对故障的弹性，以及它们如何设计为轻松支持新功能而发展。 然而，很少出现的大象是不同的系统如何为业务价值做出贡献，以及这种价值如何与其他架构属性相互作用。

到目前为止，我们从应对 2019 冠状病毒病 (Covid-19) 爆发中学到的东西

当客户公司购买软件产品时，他们通常需要熟练的员工来安装它们。这些员工通常由服务提供商公司提供，因为软件产品供应商认为建立自己的服务部门没有商业意义。客户需要了解产品供应商和服务提供商之间的关系，并应要求与其合作的人员对这种关系保持透明。随着云供应商的兴起，这种合作关系日益突出，因此透明度也变得越来越重要。

想象一下，一个团队正在为购物网站编写软件。如果我们查看团队的产出，我们可能会考虑他们在上一季度开发了多少新功能，或者考虑跨职能的指标，例如页面加载时间的减少。然而，结果指标会考虑销售收入的增长或产品支持电话数量的减少。关注结果而不是产出，有利于构建能够更有效地提高软件用户和客户效率的功能。

在理想状态下，产品模式组织由松散耦合、自主的团队组成，这些团队能够对明确和未明确的用户需求做出快速响应。然而，有时会出现需要多个团队协调应对的机会。如果管理不当，结果将导致收入损失、客户不满意和团队能力浪费。我们将应对这些机会的组织计划称为项目。在本文中，我们将通过一个失败项目的例子，分享我们在产品模式组织中管理项目的经验。

如今，许多从事软件开发的人员都听说过结对编程的实践，但它在业界仍然只是零星地被采用。其接受程度不同的一个原因是，它的好处并不是立竿见影的，它更多地体现在中长期效益上。而且它也不仅仅是“两个人在一台电脑上工作”那么简单，所以当它让人感到不舒服时，很多人会很快放弃它。然而，根据我们的经验，结对编程对于团队协作和高质量软件至关重要。