本周我在看什么（2025/01.05-01.11）

目录

• 趋势
• 我在看什么
  • 1. Whisper的WebUI
  • 2. tldraw：一种拖拽式的LLM交互界面
  • 3. 程序员的角度理解认知负荷
  • 4.纽约时报：关于世界核弹头数量如何变化的动画
  • 5.NASA卫星图像生成器：根据姓名字母探索地球

趋势

我在看什么

1. Whisper的WebUI

• 更换成这个GUI可以解决whisper的某些GUI导致的bug
  • 例如录音中有着长时间的空白会导致所有音频被识别为空白。
• 原因未知，可能是flag写的很好

2. tldraw：一种拖拽式的LLM交互界面

• 一种拖拽式的LLM交互界面
• 更容易使用的n8n，LLM世界的ComfyUI
• 一个提示词就是一个单一功能的节点，很容易就能组装出工作流
• 极度缩短了brainstorm与working pipeline的边界
• 基于Gemini构建

3. 程序员的角度理解认知负荷

• 基于Gemini生成的文章简报：

• 以下是关于软件开发中认知负荷的总结，基于提供的资料：

• 认知负荷是指开发人员为了完成任务需要在头脑中思考的信息量。

  • 人的工作记忆只能同时处理大约四个信息块。
  • 高认知负荷会导致理解代码困难，降低开发效率。

• 认知负荷分为两种：

  • 内在负荷：由任务本身的难度引起，无法减少。
  • 外在负荷：由信息的呈现方式引起，可以大大减少。

• 以下是一些常见的导致外在认知负荷增加的代码模式和解决方法：

  • 复杂的条件语句：使用中间变量分解复杂条件。
  • 嵌套的 if 语句：优先使用早期返回来处理特殊情况。
  • 继承的噩梦：倾向于使用组合而非继承。
  • 过多的浅薄模块：创建接口简单但功能强大的深层模块。
  • 误用单一职责原则：模块的职责应该从用户的角度考虑。
  • 微服务过多且浅薄：早期阶段使用更深层的宏服务。
  • 特性丰富的语言：限制可用的特性数量，选择正交的特性。
  • HTTP 状态码和业务逻辑混淆：使用自描述的字符串代码表示业务逻辑错误。
  • 滥用 DRY 原则：适度重复代码比引入不必要的依赖关系更好。
  • 紧耦合框架：将业务逻辑从框架中分离出来。
  • 分层架构：只有在实际需要扩展点时才添加抽象层。
  • 过度使用领域驱动设计 (DDD)：使用 DDD 来理解领域模型，而不是过度关注解决方案空间。

• 熟悉不等于简单，即使对于熟悉的代码，如果代码中存在过多的“聪明”或不常用的技巧，也会增加认知负担。

• 让新来的开发人员评估代码，找出认知负担过高的部分。

• 测量混乱程度：如果新人在40分钟内持续困惑，则代码需要改进。

• 目标是降低认知负荷，使新开发人员在加入公司后能够在最初几个小时内开始贡献代码。

总而言之，降低认知负荷是软件开发的关键，应该优先考虑人的认知限制，避免引入不必要的复杂性。 通过采用清晰的代码模式、避免过度抽象和减少不必要的依赖，可以提高代码的可读性和可维护性，从而提升开发效率。

4.纽约时报：关于世界核弹头数量如何变化的动画

5.NASA卫星图像生成器：根据姓名字母探索地球

• 输入姓名
• 收到一组卫星图像，卫星图像组成的字母类似于输入的姓名中的字母
• 点击每个位置查看具体所在位置