每日新聞摘要

Sehaj Kahlon's guide explores the IntrinsicSize API in Jetpack Compose and explains how and why a parent layout sometimes needs to "peek" at its children during measurement. The piece clarifies IntrinsicSize’s purpose, outlines the measurement flow when child intrinsic dimensions influence parent sizing, and highlights practical patterns, pitfalls, and performance trade-offs. Through real-world examples the author shows when IntrinsicSize is appropriate, when alternate approaches are preferable, and how extra measurement passes affect rendering cost. The article emphasizes balancing layout correctness with efficiency, and offers concrete tips to avoid common bugs and unwanted layouts. It’s aimed at Compose developers facing complex sizing scenarios where knowing child dimensions ahead of time leads to more predictable and correct UI layouts.

Sehaj Kahlon 的文章针对 Jetpack Compose 的 IntrinsicSize 机制提供实务导览，说明在父容器需先“偷看”子组件以决定尺寸时的测量流程与挑战。文章阐述 IntrinsicSize 的用途与使用情境、展示实际范例与常见陷阱，并比较可能的替代做法与性能影响。作者强调在正确性与额外测量成本之间取舍，提供实务建议与防错技巧，帮助开发者在遇到子组件尺寸会影响父布局的复杂场景时作出更佳设计决策。

This article introduces Kotlin's binarySearch and binarySearchBy as efficient, built-in alternatives to writing custom search algorithms for collections. It explains when to apply these functions—primarily on sorted collections—and highlights binarySearchBy as the variant to use when searching by a specific key or selector. The piece covers practical usage patterns, how to interpret return values and handle cases when an exact match isn't found, and discusses considerations such as ensuring correct sort order or comparators. By demonstrating how to replace linear scans with standard library binary search utilities, the article aims to help developers simplify code and improve search performance in common collection-handling scenarios.

本文介绍了 Kotlin 的 binarySearch 与 binarySearchBy，作为在集合中高效查找数据的内建替代方案，避免编写自定义搜索算法。文章说明这些函数适用于已排序的集合，并强调 binarySearchBy 适合按特定键或选择器检索复杂对象；同时讨论了返回值的含义、未找到精确匹配时的处理，以及排序与比较器等注意事项。通过展示何时用标准库的二分查找替代线性扫描，文章旨在帮助开发者简化代码并提升集合搜索的性能。

Building on a prior overview of Kotlin's Intermediate Representation (IR), this article shifts from theory to practice by demonstrating how to use Kotlin IR to perform compile-time transformations of Domain-Specific Languages (DSLs). The author explains why transforming DSL constructs during compilation can be valuable—reducing runtime overhead, enabling additional static checks, and integrating DSLs more tightly with Kotlin's toolchain—and presents practical examples and patterns for implementing IR transforms. The post addresses implementation considerations, common pitfalls, testing strategies, and how to incorporate transformations into a build process. Its goal is to give Kotlin library and DSL authors practical techniques to manipulate IR so DSLs behave more efficiently and safely without changing their external APIs. For full code examples and details, the article continues on Medium.

延续此前对 Kotlin 中间表示（IR）的介绍，本文从理论转向实践，说明如何在编译期利用 Kotlin IR 对 DSL 进行转换。作者阐述在编译期改写 DSL 的动机，例如减少运行时开销、增强静态检查以及更紧密地与工具链集成，并给出实作示例与常见模式。文章还讨论实现过程中的注意事项、测试方法以及如何将转换纳入构建流程，旨在帮助 Kotlin 库或 DSL 的开发者通过 IR 操作在不改变外部 API 的前提下提升性能与安全性。完整代码与详细示例请见 Medium 原文。

This article presents multiple ways to solve the classic FizzBuzz puzzle in Java. It starts with the problem statement and an example sequence (e.g., n = 15 yields 1, 2, Fizz, 4, Buzz, …, FizzBuzz). The naive solution uses modulus (%) checks with careful ordering to ensure numbers divisible by both 3 and 5 produce "FizzBuzz." A concatenation approach reuses a single StringBuilder and appends "Fizz" or "Buzz" as appropriate, naturally producing "FizzBuzz" when both apply and improving maintainability when adding conditions. The counter-based approach replaces modulo operations with simple counters for 3 and 5, resetting when thresholds are reached, which eliminates repeated modulus computations. The article also shows unit tests (ground-truth sequences for n = 5 and n = 100) and concludes that concatenation is more readable while the counter-based solution scales best for larger n; source code is available on GitHub.

文章介绍了多个在 Java 中实现 FizzBuzz 的方法。起初给出问题说明与示例输出（例如 n = 15 时的序列），然后展示基于取模的基础解法，强调必须先判断同时被 3 和 5 整除的情形。接着介绍使用 StringBuilder 的拼接方法：在每次迭代中根据条件 append 相应字符串，重用同一 StringBuilder 并清空以避免频繁创建对象，可方便地扩展条件。最后提出用两个计数器跟踪距离上一个 3 或 5 的差值，计数到达目标时追加对应字符串并重置，从而避免频繁的模运算。文章还给出针对 n=5 与 n=100 的单元测试，结论是拼接法更易读，而计数器法在较大 n 时表现更优，源码托管于 GitHub。

This tutorial explains compile-time templates—templates that are converted into Java classes during build rather than parsed at runtime—so template errors surface at compile time and generated code can avoid reflection for native images. It compares four libraries: JStachio (Mustache, compile-time, reflection-free, Spring Boot starter), Rocker (custom language, compile-time, uses reflection, requires a custom Spring View), JTE (custom language, compile-time, reflection-free, Spring starter and configuration), and ManTL (Manifold-based, compile-time, requires custom view). For each library the article shows Maven plugin or annotation-processor dependencies, how to write templates and model classes, code examples for rendering (e.g., JStachioModelRenderer.of().execute(...), Rocker.template(...).render(), TemplateEngine.render(...), templates.mantl.ManTLDemo.render(...)), and how to wire templates into Spring controllers. The walkthrough helps developers weigh compile-time safety, reflection requirements, and Spring integration when choosing a template library.

本文介绍了编译时模板的概念与多种实现：在构建时将模板转换为 Java 类，使模板错误在编译期暴露，并且某些实现可避免反射以支持 GraalVM 原生镜像。文章对比了四个库：JStachio（Mustache、编译时、无反射、提供 Spring starter）、Rocker（自定义语法、编译时但使用反射、需自定义 Spring View）、JTE（自定义语法、编译时无反射、提供 Spring starter 并需配置预编译）和 ManTL（基于 Manifold、编译时、需自定义 View）。每个部分展示了相应的 Maven 或注解处理器配置、模板与模型示例、渲染调用以及如何在 Spring 控制器中集成，帮助开发者在编译期安全、反射依赖与框架集成之间做出选择。

In "That One Interview Question I Thought I Knew: Singleton," Saif describes a moment when his theoretical understanding of the Singleton pattern did not translate into success during an interview. The short reflection highlights the gap between knowing concepts on paper and being able to apply or explain them under interview conditions. Saif stresses the value of deeper, practical preparation: practicing implementations, thinking through possible follow-up questions, and being ready to discuss trade-offs and real-world implications. The takeaway is that mastering an interview topic often requires more than textbook familiarity—it requires rehearsed explanations, hands-on experience, and an ability to address edge cases and rationale on demand.

在《那道我以为会的面试题：Singleton》中，Saif 叙述了他在面试中意识到仅凭对单例模式的理论了解并不能确保通过面试的经历。文章强调，纸上熟悉与面试中的实际表现存在差距，建议加强实作练习、预想考官可能的追问并能说明设计的权衡与实际影响，从而更有把握地应对面试。核心结论是：要在面试中表现好，需要超越教科书式的理解，具备能够解释、实现并处理细节的能力。