本文介绍了vivo工程效能团队基于 Gitlab、Gerrit等开源工具搭建的VCR平台，代码评审idea插件开发及开发过程中遇到的挑战、困难，并分享了相应的应对策略和优化方案。
写这篇文章的初衷：作为一个AI小白，把我自己学习大模型的学习路径还原出来，包括理解的逻辑、看到的比较好的学习材料，通过一篇文章给串起来，对大模型建立起一个相对体系化的认知，才能够在扑面而来的大模型时代，看出点门道。
让我们聊聊微服务的老大难：分布式事务。这是个已经被无数次讨论的问题，网上文章多如牛毛。本文从业务底层视角出发，探讨分布式事务究竟难在何处，以及务实的解决之路走向何方，再加一根牛毛... 不过希望本文是比较不一样的视角，能给到读者不同的启发。
Istio 依赖 Kubernetes 来进行服务发现，这通常意味着必须在 Kubernetes 集群中部署微服务并使用 Kubernetes 服务发现。然而，很多现有的微服务项目还在使用如 Consul、Eureka 这样的第三方服务注册表，本文将探讨如何将这些现有的微服务的注册表与 Istio 集成。
本篇为KMP技术的技术及实践系列文章的第二篇。在这篇技术文章中我们会以百人移动研发团队的工程化视角，探讨Kotlin Multiplatform的核心技术及优化。
前段时间通过优化业务里的相关实现，将高频调用场景性能优化到原来的十倍，使文档核心指标耗时达到 10~15% 的下降。本文将从 V8 整体架构出发，深入浅出 V8 对象模型，从汇编细节点出其 ICs 优化细节以及原理，最后根据这些优化原理来编写超快的 JS 代码
在软件开发和架构设计中，反模式（Anti-pattern）[1]是一种特定的模式，它看似提供了一个有效的解决方案，但却没有考虑到更大的背景或长期后果，因此通常会导致更多的问题和复杂性。 反模式可能是由于开发人员在解决特定类型问题时没有足够的知识和经验，或者在错误的上下文中应用了正确的模式而导致的。 DevOps领域是反模式的高发区。开发团队虽然知道最佳实践的好处，却总是由于各种各样的约束而放弃，去选择那些反模式。还有一些情况是，开发团队以为这些反模式就是最佳实践，从而在错误的道路上越走越远。 这个系列会着重介绍一些DevOps中常见的误以为是最佳实践的反模式及其带来的危害，希望能为广大开发者避坑。
Lighthouse 警告我们避免 DOM 过多，是因为 DOM 会增加内存使用量，并且可能会导致昂贵的样式计算。结合你网站上发生的其他事情，这可能会对用户体验产生影响，尤其是对于使用低端设备的用户。 前几天，当我阅读网站性能报告时，这个警告引起了我的注意。但引起我重新审视的并不是 DOM 元素的总数，而是报告中的另一项指标 —— 最大 DOM 深度。当我在 Lighthouse 报告中看到这个指标时，在脑海中涌现出了一个问题： DOM 深度如何影响渲染性能呢？ 当我们使用像 DOM 这样的树状数据结构时，其深度与诸如查找等操作的执行速度有很大关系。
今天分享的主题是基于 Native 技术加速 Spark 计算引擎，大家将会了解到如何基于 ClickHouse 来改造 Spark 引擎，最终获得较为可观的性能提升。分享主要分为如下四个部分：1）Spark 性能优化背景；2）ClickHouse 性能优势解析；3）Spark Native 加速方案设计和实现；4）加速效果分析。
