在上篇文章《钉钉 ANR 治理最佳实践 | 定位 ANR 不再雾里看花》中介绍了因为 ANR Trace 刻舟求剑的问题，导致 ANR 监控平台中排名第一的往往都是 nativePollOnce。也说明基于 ANR Trace 里的堆栈进行聚合并不能定位到 App 的头部 ANR 问题。 本文将重点介绍 ANRCanary 的 ANR 归因算法和 ANR 归因聚合上报的能力，帮助研发人员更快的分析和定位头部 ANR 问题。
今年是淘宝人生上线 3 周年，我们去年从灵犀互娱手中接过这根接力棒，经过了漫长的开着飞机换引擎的过程。在这之前，我们团队并没有中大型的 3D互动游戏项目经验，但在这个项目中，我们把该经历的都经历了。说实话，3D互动游戏项目确实不好做，从灵犀互娱的那种游戏工作室模式，转到淘宝这种职能组织架构，遇到了工种协同、技能匹配、磨合程度等多种问题。 接下来，我把我们的思考和经验分享出来，希望能成为一个敲门砖，给想要同样追逐这波浪潮的你们。
软件交付的终态是提供一个稳定可预期的系统，可预期的系统要确保环境和软件制品的一致性。而在软件研发协作的过程中，无论是制品、环境，还是发布过程，往往都是定义在代码里的。 软件交付体现为发布，而提升交付能力的目标，是要发的容易，发的频繁，增量要多，每次发的时间要少。
之前看过杨振宁的一个采访，说他最大的成就，不是获得了诺贝尔奖的研究，而是之前的一个普通理论的研究：他坚信事物是遵循一定规律的，不是大家认为的不可捉摸，花了7年时间，陆陆续续，终于找到了一个很好的解释，并且幸运的是，这个研究结果可以覆盖非常多的场景。 当我看到这个采访的时候，内心触动到的一个点是：尝试寻求表象背后的规律或者通用解释，是能够帮助更多的人、产生更大的影响的，这也应该是我们应该努力并坚持的方向。
“标签画像”或者说“用户画像”体系建设是各大互联网公司在发展过程中绕不开的话题，在阿里内部以及各大网络论坛上也有诸多分享和讨论。但大多立足数据算法或产品形态，解决方案方面并不多（尤其是工程研发实际构建角度）。本文初衷是想站在工程研发的角度，以阿里本地生活标签画像系统的开发经验为基础，分享一下构建标签画像体系的实践经验。 本文将按总分的结构进行展开：首先对标签画像的基本概念做简单的说明；其次会从业务需求的角度出发，阐述如何构建一个可用的最小标签画像系统单元；而后会以这个最小单元为基础，对部分重点模块进行扩展介绍；最后会进行总结，并对文中未涉及的发展方向简要说明。希望对大家有所帮助。
GaiaX 跨端模板引擎，是在阿里文娱内广泛使用的 Native 动态化方案，其核心优势是性能、稳定和易用。本系列文章《GaiaX 开源解读》，带大家看看过去三年 GaiaX 的发展过程。
最近在学习K8S，基础的知识参考于《Kubernetes in Action》。看完整本书基本上用了2~3个月的时间，进度比较慢；主要都是每天早晨到公司后，在正常工作时间之前的1个小时里完成的。由于时间拉的很长，各章的知识在我脑袋里是散状的，所以在我整理这篇笔记的时候，就想通过一个主题，把相关的内容串起来。第一篇笔记定的主题是“调度-当我们部署应用的时候都发生了什么？”，先从大的框架上记录一下K8S的架构与原理；对于卷、网络、configmap等组件会放在第二篇。初学者级别的学习笔记，有问题的地方大佬们及时勘误。 我在这里先给大家简单描述一下，当我们在aone里手动点击了升级之后，k8s里都发生了什么？ 当我们在aone里手动点击了重新部署，aone会通过k8s的api接口通知master节点创建一个Deployment，Deployment会按照配置里的声明要求创建一个新的RepliactionSet，RepliactionSet会按照配置的创建一个或者若干个Pod，pod会调度到相应的工作节点上，通过docker拉取镜像，启动应用。
