Versun

文章：How to Get a Job Like Mine

这是一篇来自“互联网之子”亚伦·斯沃茨(Aaron Swartz)的一篇文章，讲述了他进入互联网世界的历程，以及他的成长秘诀：

1. 要有好奇心。广泛阅读。尝试新事物。我认为，人们所说的智慧，很多都可以归结为好奇心。
2. 对一切说 "是"。我很难说 "不"，甚至到了病态的程度–无论是对项目、面试还是对朋友。因此，我尝试了很多，即使大部分都失败了，我还是做了一些事情。
3. 假设别人也不知道自己在做什么。很多人拒绝尝试某件事情，是因为他们觉得自己对这件事了解不够，或者他们认为其他人肯定已经尝试了他们能想到的一切。其实，很少有人真正知道如何把事情做对，更少有人愿意尝试新事物，所以通常情况下，只要你尽全力去做，你就会做得很好。

文章：The 70% problem: Hard truths about AI-assisted coding

很不错的一篇文章，描述了目前的人工智能辅助编码的现状：
AI可以快速的完成 70% 的编程目标，但最后的 30% 却是一个痛苦的打地鼠游戏过程。
以下是我摘抄的观点，很有参考/思考价值

如果你刚刚开始人工智能辅助开发，我有以下建议：

• 从小事做起
  将人工智能用于孤立、明确的任务
  审查生成的每一行代码
  逐步建立更大的功能
• 保持模块化
  将所有内容分解成重点突出的小文件
  组件之间保持清晰的接口
  记录模块边界
• 相信自己的经验
  利用人工智能加速而非取代您的判断力
  生成的代码感觉不对的问题
  保持工程标准

目前我的经验是，先写测试，然后再写功能代码，这样可以在审核每行代码之前，快速检查AI生成的代码是否正确，可以节省很多时间。（面向测试/用例编程）

2025 年，最有效率的团队可能是会：

• 为人工智能代理设定明确的界限和准则
• 建立强大的架构模式，让代理可以在其中工作
• 在人类和人工智能能力之间建立有效的反馈回路
• 在利用人工智能自主性的同时保持人工监督

人工智能并没有让我们的软件变得更好，因为软件质量（或许）从来都不是主要受限于编码速度。软件开发的难点–理解需求、设计可维护的系统、处理边缘情况、确保安全和性能–仍然需要人类的判断。
人工智能能让我们更快地进行迭代和实验，通过更快速的探索，有可能找到更好的解决方案。但前提是我们必须保持工程纪律，并将人工智能作为一种工具，而不是良好软件实践的替代品。请记住我们的目标不是更快地编写更多代码。而是要构建更好的软件。

新闻：China Completes Massive Green Belt Around Taklamakan Desert

塔克拉玛干沙漠是中国最大的沙漠，也是世界第二大流动沙漠，中国花费了46年的时间(1978年开始)，在沙漠边缘种植各种抗旱树种，将沙漠围起来，防止扩张，非常伟大。

网站：https://networkoftime.com/

很有意思的一个网站，任选2个名人，然后显示这2个人跨历史维度的联系。
比如我选择了“李小龙”和“马斯克”
它显示出联系如下：

• 李小龙曾经和美国演员Chuck Norris一起演过电影《猛龙过江》
• 特朗普曾经和Chuck Norris握手过
• 马斯克也认识特朗普

所以理论上，李小龙可以通过Chuck Norris认识马斯克

文章：https://matt.blwt.io/post/7-languages-in-7-weeks-for-2025/

2025年的学习计划可以开始咯，文章介绍了7种值得花一周去学习使用的语言和理由：
Python、TypeScript、Go、Gleam、Zig、Racket 和 Odin

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

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