Versun

新闻：https://www.advancednavigation.com/news/mbda-collaborating-resilient-navigation-technology/

澳大利亚的Advanced Navigation和欧洲导弹制造商 MBDA 正在开发一种新的飞机导航系统，使用专用的相机向下拍摄地球的照片，然后提取地形指纹，并将其与现有的地球表面数据库进行匹配，从而获取绝对位置以进行导航

这个问题其实很好解决

假设未来某天你肯定正在过着你理想中的生活，即使现在你还不知道是什么样的，那么你现在应该做什么呢？

没错，做出改变，什么改变呢？

改掉你现在不喜欢的，一直改，直到你满意为止。

所以，换个问法，当前的生活是你想要的吗？哪些是不想要的，那就一点一点去改变，直到你满意为止

如果你犹豫了，那么问题也就变了: 你有勇气做出改变吗？有勇气接受未来的理想生活吗？

如果你说我还有很多要考虑，比如家庭，金钱等，不能轻易做出改变，那么再换个问题，为了理想的生活你愿意付出什么？

综上所述，理想中的生活并不是一个找不到或者做不到的问题，而是有没有勇气的问题，愿意付出什么的问题。

答案就在那里，你愿意完成这个过程吗

文章：https://navendu.me/posts/jq-interactive-guide/

我今天才知道Linux下竟然有一个专门用来处理JSON的命令行工具jq，而且非常好用且强大

番茄工作法是一种非常有效的管理精力的方法，但要怎么充分正确的使用番茄钟呢？以下是我仅几年实践得出的方法，以供参考。

第一步：测量番茄钟时长最大值
因个体差异，默认的25分钟专注时长并不适合每个人，过短的番茄钟容易打破你的心流状态，导致下一个番茄钟很难找回状态。
因此我们需要测量属于自己的专注力时长，方法很简单：
使用手机设置一个较长的番茄钟，比如50分钟，然后开始工作，当你第二次主动拿起手机观察剩余时间时，那么说明你当前的专注力快到极限了，下次就设置(50-剩余时间)的时长做为番茄钟。
通过以上方法，不断修正，就能得出适合你的专注时长范围

第二步：动态调整番茄钟时长
人不是机器，不可能保证每天的精力都是一致的，所以我们需要动态调整专注时长，方法如下：
通过第一步，我们大致就能了解我们的专注力甜区，正常情况下早上起床的专注力最好，可以设置一个最长的番茄钟，之后每个工作番茄钟减少10分钟，可视情况调整，比如当你不断查看剩余时长时，那么同样说明你的专注力当前较弱，下一个番茄钟就需要减少时长了。

以上就是我目前正在实施的番茄钟使用方法，希望对你有所帮助。

文章：https://wiki.c2.com/?TestDrivenDevelopment

这是一篇关于测试驱动开发的wiki和讨论。

测试优先设计迫使你真正思考你要做什么。它让你摆脱 "当时看起来是个好主意 "的编程方式。

非常赞同这个观点，因为我经常在任务还不是很清楚的时候就开始编写功能代码，然后反复推翻之前花费大量时间，还觉得很牛啤的代码。最后造成进度缓慢，代码耦合度太高照成后期修改代码的认知负担很重。
解决该问题的有效方法就是：先编写测试用例

该方法尤其适合搭配AI代码助理的编程环境，因为在使用AI进行重构时，可以直接使用测试用例来检查AI的代码，减少人工view的情况，而且有些AI还可以自动运行测试用例来检查生成的代码，效率非常高！
在和AI沟通时，最难的部分其实是将功能表达清楚，而编写测试用例就是一种高效的表达方式

总结下测试驱动开发（TDD）的基础流程，通常遵循“红-绿-重构”的循环：

1. 编写失败的测试（红）:

   • 在开始实现新功能之前，首先编写一个测试用例。这个测试用例应该验证你想实现的功能。
   • 因为功能尚未实现，这个测试会失败（红色）

2. 实现代码（绿）:

   • 编写最少量的代码使得测试通过。
   • 这个阶段关注让测试通过，而不是优化或引入复杂性。

3. 运行测试并确认通过（绿）:

   • 运行测试确保所有相关测试用例都能通过。
   • 如果有任何测试未通过，需要回到步骤2进行调整。

4. 重构:

   • 在确保所有测试通过后，重构代码以改善其结构、可读性和维护性。
   • 此时保持功能不变，确保重构后运行的测试依然通过。

5. 重复循环上述步骤

   • 根据需要添加新的功能或改进，返回第一步开始新的循环，编写新的测试用例。

在TDD中，首个测试通常是功能测试，对某个功能进行验证，确保它们按照预期工作，待功能确定后，可以编写更细致的单元测试，对具体的方法或类进行测试，而随着开发进展，有可能需要编写集成测试和系统测试，以验证不同模块之间的互动或整个应用的行为。

注意，并不是写完一个功能测试马上写单元测试，而是写完一个模块的所有功能测试，甚至整个应用的功能测试后，再开始写单元测试。因为再写不同的功能时，可能还需要修改相关功能的模型代码，这时过早的单元测试反而是一种累赘。

实际上，54321周刊是我的一个实验项目，其目的就是为了解决我的信息焦虑问题
如果你和2年前的我一样，每天面对着刷不完的信息流压力山大，那么希望这篇博文能缓解甚至消除你的信息焦虑

其实产生焦虑的心理活动很简单，就是生怕错过任何重要的信息，从而影响未来我们的决策
在此，先说下我的实验结果：

除非你是金融从业者或者其它需要和资讯赛跑的行业，否则完全不用担心会错过任何重要信息

我的实验方法很简单，每周只获取5+4+3+2+1=15条我感兴趣的信息(54321周刊的名字来源)，填满15条后本周就不再阅读任何资讯，无论阅读器里还剩下多少未读条目。

在实验进行了3个月左右时，我发现只要是重要的、感兴趣的信息，即使我没有第一时间获知，但10天内必定会再次映入我的眼帘(从不同的途径/平台/人)
所以我不在担心错过任何重要信息，因为：

成果1：重要的信息绝不会消失，你很快会再次看到它

但这个成果并不能完全解决我的信息焦虑，还有一坐大山在我面前：成千上万的未读条目
在最初的半年里，即使我设置了各种筛选器和关键词过滤，但每周依旧会有不计其数的信息出现在阅读器里，我无法忍受越来越多的未读条目，所以每到月底，我都会单独抽一天时间集中快速刷完这些历史未读。

实验进行了一年左右后，我发现，很多信息在初发布时，都很有趣，看似很重要，但在沉淀了几星期后，都被新的东西所取代，而那些真正重要的信息，却会反复出现，反复被别人引用，所以：

成果2：时间是最好的过滤器

至此，我已能毫无波澜的将成千上万的未读条目一键已读，我已不再信息焦虑，不再机械式的浏览信息流，而是更主动的去处理它们
慢慢的，我有了更多的时间去思考、去看书、去玩、去创造
我没想到，一个观念的微小变化竟然能给生活带来这么巨大的改变

我并不指望这篇博文能解决所有人的信息焦虑，因为每个人的经历各不相同，并没有万能的方法能解决它

但请记住，面对信息流，主动权在你手里，所有的焦虑和变化都因你而起
如果没有头绪，也可以去写写周刊(无论是否公开发布)，只要你主动开始，其它就交给时间吧

接下来

我将在54321周刊中，每周推荐一个我正在关注的源，我并不想一次性把我所有的源放出来，因为那样只会躺在你的收藏夹里，而不是阅读器里。
如果你是刚接触rss或者准备建立自己的信息流，希望这篇博文能对你有所帮助。

网站：https://trunkver.org/

新的一种版本管理方案：

下面是对这句话中几个关键概念的解释：

SemVer-compatible：SemVer是“Semantic Versioning”的缩写，即语义化版本控制方案。这是一种广泛使用的版本号命名规则，通常格式为MAJOR.MINOR.PATCH，其中MAJOR代表主版本号，MINOR代表次版本号，PATCH代表修订号。SemVer-compatible意味着TrunkVer遵循或者兼容这种命名规则。

continuously-delivered：持续交付，这是一种软件开发实践，指的是在软件开发过程中，软件的新版本可以频繁地、自动地被交付到生产环境中。这通常与敏捷开发和DevOps实践相结合。

trunk-based：基于主分支的开发流程，这是一种软件开发方法，其中所有的开发工作都在主分支（trunk）上进行，而不是在多个分支上。这与基于特性分支的开发流程相反，后者会创建多个分支来开发不同的功能。

don’t follow a release scheme：不遵循发布计划，意味着可能没有固定的发布周期或版本号，而是根据需要持续集成和交付。

综合来看，TrunkVer是一种为持续交付和基于主分支开发的应用的版本控制方案，它与语义化版本控制兼容，适用于那些不遵循传统发布计划的软件产品。
这种方案允许开发者在没有固定发布周期的情况下，依然能够清晰地管理和区分软件的不同版本。

使用场景：
这种版本管理非常适合SaaS应用，对于大型的团队会更合适些，因为可以非常方便的追踪构建信息。
对于个人开发者来说，唯一的好处就是不用手动管理版本号，它可以集成到Github action里，但个人更倾向于手动管理并使用语义化的版本管理

预告片：https://www.youtube.com/watch?v=wJO_vIDZn-I

是的，就是关于那个游戏：我的世界(Minecraft) 的电影，看起来非常有趣，期待！！
2025 年 4 月 2 日开始在全球上映

文章：https://foundationcapital.com/has-ai-scaling-hit-a-limit/

作者探讨了当前人工智能发展所面临的问题，主要集中在数据量、电力、架构方面，非常有见解

根据一位OpenAI员工的说法，Orion 进展停滞的部分原因是模型是在 o1 的输出基础上训练的

随着科技公司向清洁能源供应商抛出橄榄枝，微软转向核能，人工智能已经触及到现有能源的极限。下一代模型可能需要整个国家的能源预算

Transformer 架构本身就存在这种限制。下一个标记预测虽然很聪明，但它所创建的系统似乎只能做出反应，而不能真正 "理解"。LeCun 等研究人员认为，再多的扩展也无法弥合这种架构上的差距，就像再多的数据也无法让电子表格理解其数字的含义一样。

最激进的建议或许来自 Domingos，以及 Meta 的 Yann LeCun 和李飞飞等人。他们认为，我们需要完全超越基于文本的模型，倡导"世界模型"：旨在理解因果关系和物理交互的系统，而不仅仅是识别文本中的模式

人工智能的下一个突破可能不是让我们现有的模型变得更大，而是让它们从根本上与众不同。正如 Sutskever 所建议的那样，这个领域最需要的可能是一种新的 "惊奇与发现 "精神。