Hasty Briefsbeta

全部标签

#software-development

共 175 篇

双语

Five Years of Tinygrad
5 months ago
- tinygrad的首次提交是在2020年10月17日
- 团队已发展至6人，代码库达18,935行（不含测试）
- 目标是通过先构建自主软件栈再流片，与英伟达展开竞争
- tinygrad正在移除LLVM依赖，以纯Python支持AMD GPU
- 该项目在多类工作负载上超越PyTorch，预计完成时保持约2万行代码规模
- tinygrad遵循'埃隆法则'：'删繁就简，至臻至简'
- tiny corp采用开源运营模式，通过Discord和GitHub协作，计算机销售部门提供资金支持（年收入200万美元）
- 通过推特公开谈判获得AMD合约，将MI350X用于Llama 405B训练的MLPerf测试
- 招聘以代码贡献为准绳，极少开会，专注优化tinygrad
- 使命宣言：'让千万亿次计算触手可及'
The AI Noise
5 months ago
- AI在工作场所对于高效利用时间至关重要。
- 浪漫派工程师抵制AI，偏爱传统编码方法。
- AI改变了软件开发，减少了对底层设计的关注。
- AI工具激增，造成了选择过多的困扰。
- 过度使用AI工具可能导致认知卸载的风险。
- TIE框架有助于有效管理AI工具的整合。
- 接下来的系列将探讨AI在工作中的角色及人类的相关性。
Build Software. Build Users
5 months ago
- 氛围编码加速了软件开发，但也引发了关于软件质量的疑问。
- 高质量的软件不能仅靠大量测试保证，理解用户需求才是关键。
- '酒吧爆炸'梗图说明：仅关注代码测试可能会忽略用户真实需求。
- 大语言模型能通过海量网络知识帮助深度理解用户。
- 用户氛围编码需要创建详细用户画像并模拟其交互行为。
- 建议的文件夹结构包含用户分组、画像和用户流程的'理想路径'。
- 这是个迭代过程：先编码用户氛围，再开发软件，持续完善认知。
- 软件的简洁性需要深度用户理解，并自然融入其工作流程。
- 模拟用户（作为智能体）可提供反馈来简化流程、提升质量。
- 该方法不同于用户画像和用户故事，它优先进行用户模拟。
- 与传统测试的区别在于：在开发前就优先建立用户认知。
- 结论：先构建用户智能体，再通过真实/模拟用户迭代开发高质量软件。
Building an internal agent: Code-driven vs. LLM-driven workflows
4 months ago
- 文章讨论了构建内部代理时，代码驱动与LLM驱动工作流的对比。
- 作者最初认为LLM结合工具使用可以解决复杂工作流，但后来发现某些问题用软件解决更简单。
- 文中给出了一个现实案例：用LLM驱动的工作流在Slack中标记已合并的拉取请求，但有时会出错导致效率低下。
- 解决方案是同时支持LLM和代码驱动工作流，允许通过自定义Python脚本处理LLM不可靠的情况。
- 这种混合方案先用LLM处理初始工作流，必要时渐进式切换到代码驱动工作流作为增强。
- 作者总结道：即使模型持续改进，长期策略仍是将其窄范围应用于需要智能而非迭代工作流的场景。
The Cost of Software Libraries
4 months ago
- 文章探讨了使用软件库的隐性成本，指出它们并非免费且伴随着各种权衡取舍。
- 使用库可能导致可执行文件体积增大、运行速度变慢以及可维护性降低。
- 作者通过对比Rust语言中自定义命令行解析代码与'clap'库的示例，展示了性能和体积上的显著差异。
- 当依赖外部库时会出现可维护性问题，因为修复错误或适应变更可能非常耗时。
- 作者建议仅在库的收益明显超过成本，或时间紧迫时才考虑使用库。
- 文章最后强调，库会给用户和开发者带来真实成本，往往导致应用程序臃肿且运行缓慢。
Cold-Blooded Software (2023)
4 months ago
- 作者回忆起一堂大学讲座，教授用一只能在冰冻后存活的锦龟来演示冷血动物如何通过调节新陈代谢适应环境温度变化。
- 与恒温动物保持稳定体温不同，像锦龟这样的变温动物会随环境温度变化而活跃或迟缓——温暖时生机勃勃，寒冷时行动缓慢。
- 作者将变温动物的特性类比软件开发，区分了需要持续维护才能存活的'恒温型'项目与可以随时暂停/重启的'变温型'项目。
- '变温型'软件项目采用稳定无趣的技术栈，规避外部依赖，即使长期无人维护也能保持功能，例如作者用Python 2编写且持续运行12年的博客系统。
- 这个博客系统通过内嵌依赖和本地化操作，十二年间仅需极少更新，作者预计其未来数十年仍可继续稳定运行。
LocalFirst: You Keep Using That Word
4 months ago
- 本地优先软件难以精确定义，其特性更像一个光谱而非二元标签
- 本地优先天然包含多设备协同，但常与离线优先概念混淆——允许服务器存在但应作为可选项
- 真正的本地优先软件必须实现数据主权，这本质上要求应用程序开源
- 网页应用因先天依赖'回传服务器'的特性，难以成为理想的本地优先载体
- 并非所有本地优先应用都需要多人协作功能，某些场景下刻意规避反而更有利
- 本地优先的解决方案包括开发原生应用、坚持开源路线、避免加载动画等干扰性设计
- 未来挑战在于如何将电子邮件、即时通讯和社交媒体改造成本地优先模式
I like when apps are "finished"
4 months ago
- 作者主张应该让软件'完成'而非持续更新的理念成为常态。
- 许多应用现有功能已足够完善，并不需要频繁更新，但用户常将缺乏更新误认为是开发者弃坑。
- 开源项目尤其容易被贴上'无人维护'的标签——哪怕它们运行完美，仅因近期没有代码提交。
- 作者将软件与艺术对比，指出大多数软件是实用工具，无需无止境的优化。
- 文章建议科技行业应接纳更多'已完成'的应用，并逐步摆脱订阅制商业模式。
Developers Are Solving the Wrong Problem
4 months ago
- 氛围编码是一个有争议的话题，有人视其为革命性创新，也有人认为它会损害代码质量。
- 传统编码价值观强调简洁、模块化和清晰的代码，旨在便于调试、扩展和维护。
- 向氛围编码的转变反映了人们更关注快速解决问题，而非追求完美的代码结构。
- 氛围编码的流行源于它能让用户在缺乏深厚编程知识的情况下快速迭代并解决问题。
- 生成式AI在氛围编码中的应用需要优质底层模型、充分上下文和健全的测试工具来保障质量。
- 未来可能出现'无开发者'公司，因为更多人会使用生成式AI直接创建解决方案。
- 适应氛围编码需要将其视为工具、优化提示词，并接受快速迭代和持续学习的方式。
Maybe the database got it right
4 months ago
- 文章讨论了软件开发中数据库被历史性地疏远，转而青睐内存模型和面向对象编程的现象。
- 它强调尽管人们努力减少数据库的影响，数据库仍间接地塑造了系统设计。
- ORM框架的兴起和NoSQL运动进一步疏远了关系型数据库，但应用程序依然重度依赖CRUD操作并保持关系型特征。
- 现代前端开发和对表达性数据查询的需求催生了GraphQL等解决方案，这些方案重新引入了类似数据库的特性。
- 关系型数据库不断发展，吸收了那些本欲取代它们的系统的特性，暗示它们可能自始至终都是正确的选择。
- 文章质疑这种反射性地隐藏数据库的做法是否仍适应当前需求，并建议重新评估数据库在系统设计中的角色。
The spectrum of isolation: From bare metal to WebAssembly
4 months ago
- 执行环境对于可靠的软件开发、测试和部署至关重要。
- 隔离性存在不同层级：硬件、内核、进程、文件系统和语言运行时。
- 物理机（裸金属）提供最高性能，但成本高昂且缺乏灵活性。
- 虚拟机（VM）具有强隔离性，但由于运行完整操作系统实例而产生显著开销。
- 容器轻量级、共享主机内核，是微服务的理想选择。
- 进程沙箱通过限制进程与系统交互来保障安全性。
- 虚拟环境管理语言特定依赖项，但不提供操作系统级隔离。
- 现代工具链结合运行时管理器、路径隔离和包管理以提高效率。
- 分层方案（虚拟机+容器+虚拟环境）能构建稳健的工作流。
- 未来趋势包括：容器作为默认接口、无服务器计算，以及用于可移植执行的WebAssembly（Wasm）。
IKEA for Software
4 months ago
- 文章探讨了构建用于管理太阳能微电网的生产级软件平台所面临的挑战，重点指出建立行级安全规则、社交登录和时间序列数据库等核心组件的过程极其耗时。
- 文章分析了现有加速软件开发的各种方案，包括闭源系统、低代码平台、数据库封装器和人工智能，但指出这些方案都无法提供完全可定制且经过实战检验的解决方案。
- 作者将当前软件开发状态比作手工匠艺，缺乏标准化蓝图，并质疑为何不更普遍采用自上而下（从预配置模板开始）的开发方法。
- 阻碍自上而下方法推广的潜在因素包括系统多样性、开发者偏好从零构建的习惯，以及需要编写大量文档的负担。
- 文章提出'软件界的宜家'概念，开发者可以共享标准化的预配置云应用，既减少重复性设置工作，又能为创建者创造被动收入。
- 结论指出，虽然当前工具聚焦自下而上的效率提升，但未来软件发展可能在于'扁平封装'系统，允许开发者从顶层开始并根据需求逐步定制。
The recurring dream of replacing developers
4 months ago
- 简化软件开发的承诺循环已持续五十年——从COBOL到AI时代，始终未能消除对专业开发者的需求
- 历史上COBOL、CASE工具和Visual Basic等尝试旨在普及软件开发，但最终都因内在复杂性仍需专业知识
- AI编程助手是当前最新进展，它能提升开发效率，但无法替代人类处理复杂问题时的判断力
- 软件开发本质是管理复杂性，仅靠工具无法走捷径，必须依靠缜密思考和专业知识
- 企业管理者应善用工具提升效率，同时认清解决复杂问题仍需人类专家智慧
- 取代开发者的永恒梦想推动着技术创新，催生出提升效率的实用工具，即便终极目标从未实现
The Cathedral, the Megachurch, and the Bazaar
4 months ago
- 《大教堂与集市》一文将旧式开源（大教堂）与新式开源（集市）进行对比，但现代开源已演变为Linux、Python和Node.js等'巨型教堂'
- 巨型教堂式开源项目是结构完善的组织，具有严格的贡献规则，通常由大公司和基金会支持
- 集市模式依然存在，代表大多数开源项目——规模小、混乱无序，通常由个人维护且缺乏严格治理
- 现代基础设施严重依赖集市模式，但这些小型项目的资金和可持续性仍是难题
- 类似主权技术机构的倡议正在探索无附加条件的开源资助方式，政策建议则着眼于长期解决方案
- 鼓励读者探索并支持小型开源项目，理解它们在更广泛生态系统中的作用
Pushing the smallest possible change to production
4 months ago
- 向生产环境推送一个微小、无关紧要的变更，能帮助作者熟悉新的工作环境。
- 例如修正拼写错误或部署一个'Hello world!'应用来理解工作流程。
- 这个练习能解答关于源代码访问、版本控制、持续集成/持续部署流程的关键问题。
- 通过提前了解限制条件，可以避免后续开发功能时的挫败感。
- 在此过程中与同事互动有助于建立关系和团队默契。
- 在首周结束时完成一个实际变更，能为工作关系奠定积极的基调。
Gas Town's Agent Patterns, Design Bottlenecks, and Vibecoding at Scale
4 months ago
- Steve Yegge的Gas Town是一个实验性智能体编排系统，可同时运行数十个编程智能体，在软件工程界引发了激烈讨论。
- Gas Town虽然效率低下，每月消耗数千美元API成本，但作为具有挑衅意味的推测性设计虚构作品，探索了未来智能体编程系统的可能性。
- 当智能体承担所有编码工作时，设计与规划成为瓶颈，因为人类的上下文理解、审美判断和愿景构思仍不可替代。
- Gas Town混乱的设计反映了Yegge的临时方法论，虽难以为他人所用，却揭示了未来智能体编排的潜在模式。
- Gas Town的核心模式包括：专业化智能体分工、层级化监督机制、持久化智能体身份标识和临时会话系统。
- 该系统采用'Beads'机制追踪原子任务和智能体身份，通过Git存储实现跨会话的持久化工作记录。
- Gas Town运用持续工作流、智能体管理的合并队列和强效提示机制来维持智能体任务专注度。
- 尽管月耗资数千美元，但该系统加速开发的潜在价值可能对某些企业物有所值。
- Yegge提倡'氛围编程'理念——永不查看代码，引发了关于在未来智能体主导开发中程序员是否仍需审查代码的辩论。
- 与代码保持何种距离取决于领域特性、风险承受度、项目类型、团队规模和开发者经验等多重因素。
- 未来工具需要在速度与质量间取得平衡，随着开发效率提升，深思熟虑的设计规划和团队协作将愈发重要。
Joel Spolsky: Painless Software Schedules (2000)
4 months ago
- 美国铁路公司Acela特快列车的营销活动在服务开通前就已展开，突显了产品上市时机把握的重要性。
- Lotus公司为适配旧硬件将123软件3.0版本推迟16个月发布，结果硬件已过时，微软Excel趁机取得领先优势。
- 网景公司决定彻底重写浏览器的决策导致市场份额大幅流失，这证明了没有明确时间表就进行重大改造的风险。
- 制定时间表对软件项目至关重要，但许多程序员因嫌麻烦和质疑其价值而逃避这项工作。
- 推荐使用Microsoft Excel而非Microsoft Project等复杂工具做进度规划，既能简化流程又可避免过度复杂化。
- 进度表应包含以小时（而非天数）为单位的细分任务，以确保规划精确性。
- 必须由实际编写代码的程序员来预估时间，只有他们才清楚具体步骤和所需时间。
- 合理的进度表必须预留调试、系统集成、休假和缓冲时间。
- 管理者不应强迫程序员压缩预估时间，这会导致进度表失真并打击团队士气。
- 进度表能帮助团队聚焦核心功能，舍弃冗余需求，最终打造出按时交付的优质产品。
37signals Isn't Smarter Than You, but They Are Different
4 months ago
- 37signals的工程战略包括保持小规模、无情削减范围、并雇佣顶尖工程师。
- 他们的代码库在代码行数(LOC)上明显少于典型公司，每位开发者维护的代码行数更少。
- 大多数公司遵循'功能越多等于收入越多'的思维模式，导致代码臃肿和招聘标准妥协。
- 37signals的战略创造了飞轮效应：更干净的代码、减少人员编制、并吸引顶尖人才。
- 许多企业无法采用37signals的战略，因为缺乏产品市场契合度或不愿削减范围。
- 37signals的成功并非源于天才，而是坚持质量优先于数量的纪律性战略。
Package Management Is a Wicked Problem
4 months ago
- 霍斯特·里特尔和梅尔文·韦伯于1973年在城市规划领域提出'棘手问题'概念，将其描述为试图解决时会发生变化的难题。
- 软件包管理因其复杂性成为典型棘手问题——涉及数百万个软件包、版本和下载依赖，微小改进都会影响所有关联项目。
- 里特尔与韦伯提出的十个棘手问题特征，每个都适用于软件包管理领域：
- 1. 无明确界定：问题与解决方案相互纠缠，不同群体对'软件包管理'等术语存在理解差异
- 2. 无终止规则：软件包管理器持续演进，不存在终极解决方案
- 3. 好坏判断而非真伪判断：解决方案具有主观性，取决于利益相关方立场
- 4. 缺乏即时/终极检验标准：决策后果随时间显现，难以评估替代方案
- 5. 不可逆的影响：如PyPI的抢注漏洞或npm的版本范围设定都会产生持久效应
- 6. 无明确解决方案集：利益相关方的目标冲突导致无法穷尽所有可能方案
- 7. 本质独特性：不同系统（如npm/Cargo/Python）需要特定情境的解决方案
- 8. 其他问题的表征：软件供应链安全等议题与更广泛的系统性问题交织
- 9. 多重归因解释：不同利益方对问题成因及解决方案存在竞争性理论
- 10. 不容试错：软件包管理器设计者责任重大，失误成本极高
- 该理论框架解释了为何软件包管理进展缓慢且解决方案常引发新问题。
- 里特尔和韦伯主张参与式规划，强调利益相关方协作与持续迭代改进。
- 文章建议将焦点从追求完美工具转向改善沟通与接口设计，例如建立软件包管理的通用协议标准。
Lobsters Vibecoding Challenge (Winter 2025-2026)
4 months ago
- 作者通过提出一系列测试任务，对生成式聊天机器人能开发任何软件的说法提出质疑。
- 概述了三个主要任务：提升Brainfuck解释器性能、将Raku编译器移植到静态编译语言、优化Python任务的执行速度。
- 每个任务设有具体要求、基于性能和代码质量的评分等级，以及预计完成时间框架。
- 解决方案必须基于提示生成（'氛围编码'）、功能完整、可通过Nix编译，并包含验证所需的上下文和工作日志。
- 作者特别强调开发过程中的可读性、安全性和伦理考量。

About|Login

#software-development

Five Years of Tinygrad

The AI Noise

Build Software. Build Users

Building an internal agent: Code-driven vs. LLM-driven workflows

The Cost of Software Libraries

Cold-Blooded Software (2023)

LocalFirst: You Keep Using That Word

I like when apps are "finished"

Developers Are Solving the Wrong Problem

Maybe the database got it right

The spectrum of isolation: From bare metal to WebAssembly

IKEA for Software

The recurring dream of replacing developers

The Cathedral, the Megachurch, and the Bazaar

Pushing the smallest possible change to production

Gas Town's Agent Patterns, Design Bottlenecks, and Vibecoding at Scale

Joel Spolsky: Painless Software Schedules (2000)

37signals Isn't Smarter Than You, but They Are Different

Package Management Is a Wicked Problem

Lobsters Vibecoding Challenge (Winter 2025-2026)