创造世界是一种什么样的体验

via 歌词经理 (author: Lyric)

增程器就是充电宝？别被忽悠了

如果你畅游社交网络的汽车区，经常有人分享“增程车的增程器就是个充电宝”这样的观点，更有甚者，觉得“1.0L, 1.5L 1.5T 都可以做这个充电宝”。这些排量+是否有涡轮增压的发动机都可以做增程器是不假，但很影响用车体验。

我从一个点切入，你就知道 1.5T 增程器用在“百万豪车”为何不妥了。

当电池电量 30% 时，三元锂电池整包的放电功率大概只有满电时的60%~70%，如果此时用户正在从【泸定县城】爬往【折多山垭口】，这个例子太具体了，我们换成高速上紧急加速场景。某增程车?6（?代表一个字符）三元锂电池包 36.8度，我查到他峰值是8C的放电倍率（几乎只能维持10+s），但是高负载（能扛住长时间大功率需求）时放电倍率只有3C，满电时放电能力有294.4kW，那么30% SOC 时候放电倍率只有 110.4kW，无法满足此时的功率需求。

还有一个重要的点，也许很多人知道但是忽略了，电池包同一时间只能进行充电/放电，不可能既在放电又能充电的。

所以上面的场景下，很大可能是发动机+电池共同出力满足电机需求的。发动机 -> 发电机 -> 驱动电机，如果此部分功率不够，整车系统还会继续从电池中取功率喂给驱动电机。

这部分的能量传输路径是：发动机 - 发电机 - 交流电转直流电（AC to DC）- DCDC控制器 - 直流电转交流电（DC to AC）- 驱动电机 - 减速器/差速器 - 车轮。

所以增程车的增程器只是个充电宝吗？不是，某种意义上他也会参与“直驱”，但是他“直驱”的形式是通过曲轴带动发电机发的电驱动车轮前进。

我们在讨论直驱时，到底是在讨论什么？插混直驱就是发动机曲轴的力通过一些机构直接作用在车轮上，而不经过上面那一大串路径了。城区低速场景，功率需求比较低，大部分时间功率需求都在100kW以内，纯靠电池就能提供，这时候插混和增程是一样的，都是在合适的时间启动发动机专门发电，然后部分功率用于驱动，剩余功率充进电池。

via Allen Hua 的网络博客

自去年年初以来，Google Play 的应用程序数量下降了 47%

根据应用程序情报提供商Appfigures的最新分析，从2024年开始到现在，安卓应用程序市场在全球范围内承载的应用程序从约340万个减少到仅有约180万个。这一数字下降了约47%，意味着全球安卓用户可使用的应用程序被大幅清除。

via TecHug (author: techug)

Netty初探

via Sekyoro的博客小屋

文件分片上传分析

via Sekyoro的博客小屋

Optimal Brain Surgeon

Derivation and Extension of The Classical Optimal Brain Surgeon Algorithm

via Lei Mao's Log Book

你真的了解 SQL 吗？数据库工程师究竟建议你做什么？

我们每天使用的一些大型应用程序中，80% 都是关系数据库中的 SQL。这通常是 Oracle、MySQL、Postgres 或 Microsoft SQL。你这样做也没有错。一旦你真正学会了 SQL，你就会发现它的真正魅力所在。

via TecHug (author: techug)

一个简单的 A star 寻路算法实现

我需要一个接口简单的寻路模块，所以今天写了一个 。其实之前也写过很多版本，在我上传代码时就发现我自己的 github 账号下早有同名仓库。不过，之前的版本的接口设计不太满意，直接删掉了，用这次的新版本复用老的仓库名字。

我希望达到的目标是，C 接口简单易用，且和地图本身的数据结构无关，只提供寻路功能。这样容易拓展到不同应用场景。

数据结构简单，内存开销固定，在算法执行过程中不额外分配内存。这可以方便的在多线程环境运行。

我不需要处理特别复杂和规模巨大的地图，那种场景应该额外做一些预处理。但在起点和终点的路线结果不长时（即使在大规模地图上），应该有较好的性能。

原始的 A star 算法实现最为简单，在大多数情况下有不错的表现，所以我选择了它。我知道算法可以有很多改进方法，但我觉得代码简单最为重要。

通常 A star 算法依赖一个优先队列，但我没有选择使用诸如平衡二叉树等复杂结构来实现它，而使用了最简单的单向链表。因为这样可以轻松的把全部数据全部塞在一块平坦内存中。

基础数据结构是一个用数组实现的闭散列 hash 表，使用者来决定使用多大的数组，通常使用预期路径长度的平方大小会比较合适。为了减少每次寻路的初始化成本，使用了一个 version 值表示每个 slot 的初始状态，每次调用寻路，都会把 version 递增（ O(1) 操作），这样就可以让整个 hash 表的所有 slot 复位。

寻路过程中每个尝试的节点都会加入 hash 表中，在 hash 表使用率超过一半就会中止算法，防止性能恶化。但接口在这种情况下依然会返回已经找到的离目标最近的中途点。

在不复杂的大规模地图上，通常可以通过多次调用找到完整路径。但依然建议针对大地图做更高层次的预处理。在 Youtube 上有一个 Rimworld 作者讲解 Rimworld 中区域分割系统的视频值得一看，搜索 "RimWorld Technology - Region System" 可以找到。

A star 工作中的待展开节点集是用单向链表的形式串起了 hash 表中的 slot ，而没有使用额外的优先队列结构。虽然单向链表的插入操作是 O(n) 的，但我猜想在大部分场景中，这个 n 并不算大。尤其是估价函数理想工作状态下（朝着目标直线移动），新插入的节点都是在链表一端附近的。这个猜想需要足够多的测试数据验证。

为了调试算法工作中的内部状态，模块提供了一个函数可以输出整个 hash 表的当前状态图（仅限于每个 slot 的 gscore ，即离起点的路程）。合理使用这张图，可以把算法的内部状态可视化表现。test 中使用 ascii 字符展示，但用灰度图输出图像效果会更好。

----------------------

代码刚写好，尚未充分测试。但我觉得接口设计还算通用，应该会有人愿意使用。期待有更多人使用而让代码的质量提升。

via 云风的 BLOG

一个简单的 A star 寻路算法实现

我需要一个接口简单的寻路模块，所以今天写了一个 。其实之前也写过很多版本，在我上传代码时就发现我自己的 github 账号下早有同名仓库。不过，之前的版本的接口设计不太满意，直接删掉了，用这次的新版本复用老的仓库名字。

我希望达到的目标是，C 接口简单易用，且和地图本身的数据结构无关，只提供寻路功能。这样容易拓展到不同应用场景。

数据结构简单，内存开销固定，在算法执行过程中不额外分配内存。这可以方便的在多线程环境运行。

我不需要处理特别复杂和规模巨大的地图，那种场景应该额外做一些预处理。但在起点和终点的路线结果不长时（即使在大规模地图上），应该有较好的性能。

原始的 A star 算法实现最为简单，在大多数情况下有不错的表现，所以我选择了它。我知道算法可以有很多改进方法，但我觉得代码简单最为重要。

通常 A star 算法依赖一个优先队列，但我没有选择使用诸如平衡二叉树等复杂结构来实现它，而使用了最简单的单向链表。因为这样可以轻松的把全部数据全部塞在一块平坦内存中。

基础数据结构是一个用数组实现的闭散列 hash 表，使用者来决定使用多大的数组，通常使用预期路径长度的平方大小会比较合适。为了减少每次寻路的初始化成本，使用了一个 version 值表示每个 slot 的初始状态，每次调用寻路，都会把 version 递增（ O(1) 操作），这样就可以让整个 hash 表的所有 slot 复位。

寻路过程中每个尝试的节点都会加入 hash 表中，在 hash 表使用率超过一半就会中止算法，防止性能恶化。但接口在这种情况下依然会返回已经找到的离目标最近的中途点。

在不复杂的大规模地图上，通常可以通过多次调用找到完整路径。但依然建议针对大地图做更高层次的预处理。在 Youtube 上有一个 Rimworld 作者讲解 Rimworld 中区域分割系统的视频值得一看，搜索 "RimWorld Technology - Region System" 可以找到。

A star 工作中的待展开节点集是用单向链表的形式串起了 hash 表中的 slot ，而没有使用额外的优先队列结构。虽然单向链表的插入操作是 O(n) 的，但我猜想在大部分场景中，这个 n 并不算大。尤其是估价函数理想工作状态下（朝着目标直线移动），新插入的节点都是在链表一端附近的。这个猜想需要足够多的测试数据验证。

为了调试算法工作中的内部状态，模块提供了一个函数可以输出整个 hash 表的当前状态图（仅限于每个 slot 的 gscore ，即离起点的路程）。合理使用这张图，可以把算法的内部状态可视化表现。test 中使用 ascii 字符展示，但用灰度图输出图像效果会更好。

----------------------

代码刚写好，尚未充分测试。但我觉得接口设计还算通用，应该会有人愿意使用。期待有更多人使用而让代码的质量提升。

via 云风的 BLOG

[2025-05-14 Wed 16:10] 名为 notepad.exe 的笔记本

[[]]

via @marckohlbruggfe

via Home - Space Looming

Invalid media: image

A single Python function for both async/sync

Scenario: I often need to write Python functions like:

1. take some parameters and format them
2. call an API with the formatted parameters
3. parse the result and return chosen values

There's a huge problem in step #2.

In today's Python world, troubles arise because async/await are "infectious", In practice this function is splitted - like in Python stdlib, where a vanilla method and its async counterpart amethod often come in pairs. Package authors scramble to provide sync transport and another async transport. I discovered this ugly fact while reading the source code ofredis-py, httpx and elasticsearch-py. Duplicate and lookalike code was always written twice. All it takes is some random async IOs in one place and your code would be forced to change forever.

Is there a way to write the function in one place, but callable both with async and without?

I pondered this question for ages, and today I stumbled upon something interesting:

  def s1():
    return asyncio.sleep(1)

  async def s2():
    return await async.sleep(1)

There's virtually no difference when calling await s1() and await s2()

I vaguely remembered how Python’s coroutines were designed, and after some tinkering, I came up with this snippet:

import asyncio, types

def aa(f):
    """
    make a function both awaitable and sync
    idk how to property name this. maybe anti-asyncio (aa)?
    """
    def wrapper(func, *args, **kwargs):
        if asyncio.iscoroutinefunction(func):
            return types.coroutine(f)(func, *args, **kwargs)
        else:
            g = f(func, *args, **kwargs)
            try:
                while True:
                    next(g)
            except StopIteration as ex:
                return ex.value
    return wrapper

@aa
def my_func(func, *args, **kwargs):
    # prepare args, kwargs here
    if asyncio.iscoroutinefunction(func):
        # just replace `await` with `yield from` for async calls
        result = yield from func(*args, **kwargs)
    else:
        result = func(*args, **kwargs)
    # handle the result here
    return result

import httpx

# async
async def main():
    print(await my_func(httpx.AsyncClient(timeout=3).get, 'https://est.im/'))
asyncio.run(main())

# sync
print(my_func(httpx.get, 'https://est.im'))

The above shows a single piece of code, injectable with a sync/async call, allows for customizable pre- and post-processing logic, and returns the result with clean syntax.

The only mental tax: inside my_func, you have to replace all await keyword with yield from.

It works for my scenario and I’ve yet to find a simpler solution.

via est の 输入 输出和出入

A single Python function for both async/sync

Scenario: I often need to write Python functions like:

1. take some parameters and format them
2. call an API with the formatted parameters
3. parse the result and return chosen values

There's a huge problem in step #2.

In today's Python world, troubles arise because async/await are "infectious", In practice this function is splitted - like in Python stdlib, where a vanilla method and its async counterpart amethod often come in pairs. Package authors scramble to provide sync transport and another async transport. I discovered this ugly fact while reading the source code ofredis-py, httpx and elasticsearch-py. Duplicate and lookalike code was always written twice. All it takes is some random async IOs in one place and your code would be forced to change forever.

Is there a way to write the function in one place, but callable both with async and without?

I pondered this question for ages, and today I stumbled upon something interesting:

  def s1():
    return asyncio.sleep(1)

  async def s2():
    return await async.sleep(1)

There's virtually no difference when calling await s1() and await s2()

I vaguely remembered how Python’s coroutines were designed, and after some tinkering, I came up with this snippet:

import asyncio, types

def aa(f):
    """
    make a function both awaitable and sync
    idk how to property name this. maybe anti-asyncio (aa)?
    """
    def wrapper(func, *args, **kwargs):
        if asyncio.iscoroutinefunction(func):
            return types.coroutine(f)(func, *args, **kwargs)
        else:
            g = f(func, *args, **kwargs)
            try:
                while True:
                    next(g)
            except StopIteration as ex:
                return ex.value
    return wrapper

@aa
def my_func(func, *args, **kwargs):
    # prepare args, kwargs here
    if asyncio.iscoroutinefunction(func):
        # just replace `await` with `yield from` for async calls
        result = yield from func(*args, **kwargs)
    else:
        result = func(*args, **kwargs)
    # handle the result here
    return result

import httpx

# async
async def main():
    print(await my_func(httpx.AsyncClient(timeout=3).get, 'https://est.im/'))
asyncio.run(main())

# sync
print(my_func(httpx.get, 'https://est.im'))

The above shows a single piece of code, injectable with a sync/async call, allows for customizable pre- and post-processing logic, and returns the result with clean syntax.

The only mental tax: inside my_func, you have to replace all await keyword with yield from.

It works for my scenario and I’ve yet to find a simpler solution.

via est の 输入 输出和出入

河南行拾遗

via Frost's Blog

AI 陪聊通用 PUA 攻击（提示词攻击）

**由于一些人的不厚道做法，往后 AI 陪聊相关的所有`逆向 / 漏洞`方面的文章不再透露任何细节。**

通过 `PUA 攻击（提示词攻击）`，目前已经过验证可以达到以下效果，更多玩法还在研究中：

1. 逆向角色卡
通过提示词 PUA + 剧情反推 + 二次总结，可以将角色卡逆向出来，但是逆向出来的角色卡通常没有原卡好使，可以靠人工微调优化，通过逆向角色卡将友商的数据“借鉴”出来自己搭酒馆使用。世界卡理论上也能推出来，但得花费很多的

via LiesAuer's Blog

数据库内核开发 5 年，我从无数坑中学到的 14 个宝贵教训

前言

过去五年半里，我在 Apache IoTDB 社区担任核心开发者，亲历了老分布式版本的迭代、新分布式架构的设计、盲测性能优化和系统可观测性搭建。这些年来，我在调试各种疑难杂症、修复线上事故以及优化系统架构的过程中，踩过无数坑，也积累了宝贵经验。

这篇文章记录了我在实战中总结出的 14 个重要教训，不是纸上谈兵，而是用血泪换来的经验。希望能帮助正在或即将从事数据库内核开发的朋友们少走弯路。

14 条教训

预见性设计集群扩展，消除性能瓶颈

集群扩展性是确保系统长期可持续发展的关键。在设计初期，应尽量避免集群中的单点瓶颈，合理地将用户负载分配到集群中的所有节点上，并且要控制分片数量。

这样，不仅可以保证集群在负载增加时能够平稳扩展，还能避免在实际运行过程中出现性能瓶颈，从而提高系统的整体可用性。

抽象共识算法接口，实现无缝迭代

共识算法是分布式存储系统核心中的核心，其设计决策直接影响系统性能上限和可靠性保障。如果确信系统只需使用一种共识算法，可以集中精力将其优化到极致；但如果预见到未来可能需要支持多种算法，就应当提前设计一个抽象的通用接口。

通用共识框架的设计不仅能支持当前的共识算法，还为未来算法的演进和优化创造了可能性。良好的抽象接口使新算法的引入变得简单，避免了整体架构的大规模重构，极大地减少了技术债务。

构建完善可观测性，实现透明可控

可观测性是系统设计中的核心部分之一。随着系统的迭代，良好的可观测性设计不仅能帮助你快速定位问题根源，避免因找不到问题所在而浪费大量时间，还能够在不同业务负载和硬件环境下，提供详细数据来量化评估各项优化工作的投入产出比。

投入构建完善的可观测性体系是极其有价值的工作，它不仅能够构建可扩展的工程服务体系，还能够支撑可持续的架构演进。

稳定性优先于性能，打造可靠基础

当系统出现不稳定性问题时，稳定性应始终作为首要解决目标。系统的不稳定性问题通常比性能问题更为紧急，只有系统足够稳定，才能进行进一步的性能优化。

因此，如果系统本身仍存在严重稳定性问题，可以考虑暂停性能优化工作，集中精力解决系统的稳定性问题。

精细化模块设计，控制复杂度增长

代码量每增加一个数量级，维护的复杂度都会呈指数级增长。大型系统的可维护性直接影响到产品的长期生命力和演进能力。在系统不断扩展的过程中，良好的模块化设计是控制复杂度的关键武器。

通过清晰的责任边界、松耦合的接口设计和合理的抽象层次，可以将复杂系统分解为多个可独立理解和维护的模块。这种”分而治之”的策略不仅能够降低团队协作的成本，还能够使系统在面对不断变化的需求时保持足够的灵活性和可扩展性。

隐藏系统复杂性，打造友好接口

在功能迭代过程中，很容易为追求极致性能而向用户暴露底层实现细节或复杂概念。然而，这种”优化”往往会带来用户理解成本的急剧上升、使用门槛的提高以及后期维护的困难。

系统设计的艺术在于在保证性能的同时，尽可能对用户隐藏内部复杂性。一个优秀的系统应当既能提供强大的功能和性能，又能通过简洁直观的抽象概念让用户轻松上手。用户关心的是解决问题的简易程度，而非系统的内部构造。过早的性能优化和不必要的复杂性往往会得不偿失。

自动化代码规范检查，统一团队风格

从项目一开始，就应该引入代码自动化规范检查工具，避免在后续迭代中频繁出现代码风格的变化，或者通过大型 PR 改变代码风格而破坏原有的 git blame 历史。通过自动化检查，不仅能够确保团队成员的代码风格一致，还能减少不必要的沟通和协调，提高团队的协作效率。

构建分层 CI/CD，平衡效率与质量

CI/CD 流程是高效开发的基石。它不仅能够帮助团队保持高效的开发节奏，还能确保系统的稳定性和可靠性。在设置 CI 时，建议将其拆分为 commit、daily 和 weekly 级别，分别执行不同优先级的测试用例，从而在开发效率和代码质量之间找到最佳平衡点。

坚持持续检测，防止质量问题积累

性能和功能的持续检测是保持系统质量的关键。尤其在长期的迭代过程中，确保开发主分支持续接受充分检测，可以有效避免”问题积累”。随着时间推移，未及时发现的问题修复成本会大幅增加，因此及时发现并修复问题，才能确保系统质量持续得到保障。

借助 AI 编程工具，提升开发效率

随着 AI 技术的发展，像 Cursor 这样的 AI 工具可以大幅提高开发效率。尤其是在你已经具备扎实的开发能力时，借助 AI 工具生成代码并进行细致的 review 和微调，能够显著提升代码产出速度。

利用 AI 辅助编程，可以将每日有效代码产出从 100 行提升到 500 行，这不仅节省了时间，也能够提高团队的整体生产力。

选择成熟 IDL 工具，奠定扩展基础

在系统设计初期，选择成熟的 IDL 工具（例如 Protobuf 或 Thrift IDL）来管理网络接口的字段和持久化对象的非压缩磁盘存储（例如 WAL）是明智的选择。不要为了短期性能而放弃可演进性，否则日后很可能会产生难以消除的技术债。

在滚动升级集群时，或者在添加、删除持久化对象字段时，如果最初没考虑可演进性，往往会涉及非常复杂的处理过程和额外的维护成本。提前做出决策，选择合适的工具，可以为未来的扩展和维护打下坚实的基础。

掌握高效调试工具，缩短排障时间

开发初期，学习并掌握先进的线上调试工具是非常必要的。掌握高效的调试工具，能够极大提高问题解决效率。例如，Java 系统开发者至少应当熟悉 JDK 自带命令、JProfile 和 Arthas 等工具，它们可以帮助你快速诊断系统问题，特别是在复杂的线上环境中，能节省大量排查时间。

熟练掌握这些工具可以将复杂问题的解决时间从数天缩短到数小时甚至数分钟。

选择高效流程工具，降低沟通成本

软件开发不仅仅是写代码，管理好软件的迭代流程同样至关重要。结合需求分析、功能设计、技术研究、开发、测试等环节，选择合适的工具来管理文档和迭代任务，能够显著降低团队沟通成本。

高效的流程管理工具能够提高团队的协作效率，确保信息透明和流畅，在团队规模扩大后尤其重要。在这方面，我强烈推荐飞书文档和飞书多维表格等协作工具。

定期小版本发布，降低发版风险

定期发版的计划需要提前制定，避免将所有功能集中在大版本发布中，这样做会带来潜在的延期风险。通过定期发布小版本，不仅能够帮助团队及时应对问题，还能减轻技术负担，避免大版本发布时出现复杂情况。

建立每季度甚至每月定时发布功能版本的节奏，既能让用户及时获得新特性，也能有效降低每次发版的风险。

写在最后

五年多的数据库内核开发之路，既有成功的喜悦，也有踩坑的痛苦。这些教训都是在实际项目中一点一滴积累的，希望能对你的工作有所启发。

在数据库这个相对成熟的领域，虽然具体实现会随着业务需求不断演进，但这些经过实践检验的工程智慧和方法论却是经得起时间考验的。即使技术栈更迭，底层架构变化，这些原则依然适用。从项目伊始就重视这些关键点，不仅能够减少技术债务，还将为你的系统打下坚实的基础，让团队能够持续、稳健地迭代和创新。

本文借助 Cursor IDE 和 Claude 3.7 辅助创作完成，AI 工具极大提高了内容的整理和润色效率，感谢 Anthropic 提供如此强大的技术支持。

via 谭新宇的博客

揭秘 .ignoredByLayout()：让视觉变换“隐形”于布局之外

在 SwiftUI 的众多 API 中，.ignoredByLayout() 算是一位“低调的成员”。相关资料稀少，应用场景也不常见，其名称本身就容易引发困惑。它似乎暗示着某种对布局的“忽略”，但这与我们熟知的 offset 或 scaleEffect 等修饰符默认不影响父布局的行为有何不同？ ignoredByLayout 究竟在什么时机工作？它到底“忽略”或“隐瞒”了什么？本文将为你揭开这个 SwiftUI 布局机制中微妙 API 的面纱。

Subscribe English RSS

阅读全文

via 肘子的 Swift 记事本 ｜ Fatbobman's Blog

PIVOT Vol.17 云儿在天上飘

via Another Dayu

从Go路由选择看“标准库优先”：何时坚守？何时拓展？

via Tony Bai (author: bigwhite)

java 字符串变得更快了

在 JDK 25 中，我们改进了String 类的性能，使String::hashCode 函数大部分时间都是 constant foldable 的。例如，如果您在静态不可修改的 Map 中使用字符串作为键，您可能会看到性能的显著提高。

via TecHug (author: techug)

不听话的员工就应该开掉吗？！

via 王福强的个人博客：一个架构士的思考与沉淀