跳到主要内容

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

趋势

我在看什么

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卫星图像生成器：根据姓名字母探索地球​

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