xiaohack's Blog - Ruby on Rails
type: channel
link: https://blog.xiaohack.org/tag/ruby-on-rails/
items: Ruby on Rails 后端工程师招聘（远程）
items: Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
items: 【开发实战】Kamal - 与 Docker Compose 同一生态位的部署工具

Ruby on Rails 后端工程师招聘（远程）
type: item
date: 2026-01-25T06:05:28+08:00
description: Ruby on Rails 后端工程师（远程 ）职位概述我们正在寻找一名 Ruby on Rails 工程师，参与实际业务系统的开发与维护。 你将以 远程办公 的形式加入项目，按实际工时结算薪资，合作方式灵活，适合自由职业者或希望长期远程合作的开发者。工作内容 使用 Ruby on Rails 进行 Web 后端功能开发与维护 参与业务需求的技术实现，与产品/设计协作落地功能 编写结构清晰、可维护的代码，并进行必要的调试与优化 根据项目需要，参与 API 设计、数据库建模等工作 通过文档、Issue 或英文技术资料理解并解决问题 任职要求 熟悉 Ruby on Rails，具备实际项目开发经验 掌握基本的 Web 开发知识（ HTTP 、RESTful 、数据库等） 熟悉常见数据库（如 PostgreSQL / MySQL ） 具备 基础英文读写能力 能阅读英文技术文档、Issue 、报错信息 能进行简单的英文技术沟通（不要求口语流利） 具备良好的自我管理能力，能够适应远程协作 对代码质量负责，有持续学习和改进的意识 加分项（非必须） 有远程工作或自由职业经验 熟悉 RSpec 、Sidekiq 、Redis 、API 设计等 Rails 常见生态 有性能优化、系统重构经验 熟悉 Git / GitHub 协作流程 合作方式 & 薪资 工作方式：远程办公 计薪方式：按工时结算 薪资范围：80 – 140 元人民币 / 小时 具体根据技术水平、合作稳定性综合确定 工时与任务透明，长期合作优先 我们能提供 灵活、尊重专业的合作方式 清晰的需求沟通，不无意义加班 有技术挑战、能真正落地的项目 长期合作机会（不是一次性外包） 如有意向，请投递简历至 [email protected]

Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
type: item
date: 2026-01-21T16:34:55+08:00
description: Ryan Dahl 在 1 月 20 日给软件工程下了结论：“人类写代码的时代已经结束。”留下的工作里，不包括继续手写语法。 如果这话出自某个科技网红，大概刷过去就算了。但 Ryan Dahl 不一样——他不仅写出了 Node.js，后来还“推倒重来”做了 Deno。你可以把他的意思理解为：写代码这部分会越来越自动化，而人的价值会更多落在判断、取舍和责任上。 而在 Ryan Dahl 这次“宣判”之前，1 月 3 日，Ruby on Rails 作者 DHH 也在 X 上连发多条，语气罕见地偏“乐观派”： “别让那些粗制滥造和尴尬翻车，遮住你对 AI 的惊叹。自从我们把计算机连上互联网以来，这是我们让计算机做到过的最令人兴奋的事。如果你在 2025 年一直对 AI 悲观或怀疑，不如在 2026 年的开端，用一点乐观和好奇再试试看？” 于是，社区里迅速冒出一种更夸张、但传播力极强的解读：“DHH 都松口了。”“连最不买账的人都开始给 AI 站台——你还有什么理由不用？”甚至有人干脆把它说成：“DHH 也扛不住了，最终还是向 AI 屈服低头了。” 但你真去听 DHH 的原话，会发现所谓“DHH 屈服论”，并不是那么回事儿。 在最新一期播客中，他说在 37signals，AI 没有在写真实产品，更谈不上“从零写出什么东西”。 他在用 AI，而且每天都用，但更多是做那种“一发入魂”的小实验；一旦进入真工程：要持续演进、要迭代、要打磨，他就会觉得：“这在浪费我的时间，到这一步我自己写更快。” 所以他们的新产品 Fizzy 里 95% 的代码，还是人类亲手敲出来的。 他还补了一句：我们离那种“AI 让一切始终更好、更快、更省心”的明显拐点，还差一点。 “就现在而言，我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。” 更关键的是，他不是在怀旧。他明确说：“手写代码依然有竞争力。”“至少在此时此刻，这是一个仍然有竞争力的选择。” 而且他的判断正好和 Ryan Dahl 相反：“我们并没有到 AGI，没有到那种‘人类写代码的时代死了’的程度。” 挺好玩的是，DHH 还说要远离 Anthropic 的 CEO：他一听到那种“再过五分钟就不需要程序员了”的口吻就火大，直接开喷：“你们到底用的啥模型啊？”反正他自己用的是 Opus 4.5（或当下版本），但在他的体验里，这种“程序员马上下岗”的说法完全不符合现实——尤其是那些要长期维护、持续迭代、不断演进的真实工程，离“五分钟结束”差得十万八千里。 以下是 DHH 播客整理全文翻译： “如果浏览 Web 的不再是人类” 主持人：欢迎大家来到《Next Token》。今天这期节目对我来说有点特别，可能要追溯到 25 年前。很高兴请到 DHH——David Heinemeier Hansson。欢迎你。DHH：很高兴来，谢谢邀请。 主持人：我猜你可能是刚从赛车里下来（笑）。DHH：现在是休赛期，正好歇一歇。 主持人（Torsten）：那我就先来点“热血沸腾”的话题。我从 2010 年左右就开始关注你，你可能是对我影响最大的前五位程序员之一。如果没有你，我可能不会走到今天。我职业生涯中有七八年都在写 Rails，看了你所有的书、博客。我们其实从没见过面，但有一次“交集”让我印象极深——我发过一条关于 Cookie Banners 的吐槽推文，那是我人生中传播最广的一条推文。那天中午我被 Cookie Banners 气疯了，随手发了一条，然后彻底炸了。第二天你转推并评论说：“这就是为什么人们不再浏览 Web，而是开始用 ChatGPT。” 所以我想直接问你：欧盟最近说要“取消 Cookie Banners”，你觉得这真的能改善什么吗？还是说——已经太迟了？ DHH：我认为 Cookie Banners 是 Web 体验变得糟糕的一个主要原因。它们几乎比早期那种弹窗广告还要糟糕——你知道的，“打地鼠”“打猴子”那种 2000 年初的弹窗。当年浏览器还能通过技术手段封杀弹窗，但 Cookie Banners 没有一个统一、有效的技术解决方案。我知道有插件能挡，但大多数人不会装。结果就是：Cookie Banners 成了互联网的一场瘟疫。 我是丹麦人，所以我觉得我有资格狠狠吐槽欧盟。Cookie Banners 最初的出发点是“高尚的”——限制数据收集、提高透明度。但这套东西在第一个 Cookie Banners 出现 5 分钟后，就已经被证明是失败的。可欧盟花了整整 15 年，才开始承认这个问题。现在他们说要“移除”Cookie Banners。但“移除”是什么意思？你以为这就能抹掉你对互联网造成的破坏吗？不可能。接下来30 年，仍然会有大量网站继续保留 Cookie Banners——因为删掉…

【开发实战】Kamal - 与 Docker Compose 同一生态位的部署工具
type: item
date: 2026-01-01T15:50:58+08:00
description: Kamal Deploy web apps anywhereFrom bare metal to cloud VMs using Docker, deploy web apps anywhere with zero downtime. Kamal 提供零停机部署、滚动重启、资源桥接、远程构建、附属服务管理，以及使用 Docker 在生产环境部署和管理 Web 应用所需的一切。最初为 Rails 应用打造，Kamal 适用于任何可容器化的 Web 应用。美国 37signal 公司是一家 “小而美” 的公司，员工只有几十人但是每年有数百万利润。著名的项目管理工具 Basecamp、网络框架 Ruby on Rails 都出自他们。Kamal 也是他们的作品，用 Ruby 编写并集成到 Rails 的默认工具链中。Kamal 的主要优势有二：一是与 Git 版本管理紧密结合，一次 commit 一个镜像，出什么问题可以立即回退；二是使用 kamal-proxy，从而带来健康检查与零停机部署，新版本实例正常上线前不会影响已有的实例。前提条件如上所述，只要能被 Docker 打成镜像的 Web 应用都能用 Kamal 部署。同时因为 Kamal 有 Accessories 的概念，事实上让 Kamal 占据了与 Docker Compose 一样的生态位。然而，你要部署的应用还要满足一些特殊条件：你需要手动写一个 Dockerfile，使你的服务正常启动并向某个端口提供 HTTP 服务。你需要添加 GET /up 端点，该端点用于健康检查，如果应用状态正常则返回 200 OK。（Kamal 最初是为 Rails 设计的，这个端点其实就是 Rails 的惯例。）对于部署目标 VPS 也有一定要求：建议使用刚刚安装、仅配置好 SSH Key 远程连接的全新系统。发行版建议为最新版本的 Ubuntu 或 Debian。SSH 开放在 22 端口且为 root 账户登录。（显然 Kamal 的默认配置并不合安全的最佳实践，但是你会需要额外的配置，下文会说明）下面准备了一个 Node.js 的例子，与一个 PHP+MySQL 的例子来说说它的基本用法。请准备一个域名，并在 DNS 提供商中把域名解析事先设置到你的服务器上。首先安装 Ruby 3.2+，如果你不知道怎么安装，可以用 rbenv。然后运行：$gem install kamal 把 Kamal 安装到本机上。Node.js 应用我已经准备了一个例子： GitHub - uqsme/app-size-comparison: App sizes comparison切换到根目录，如你所见我已经写了 Dockerfile。本应用共有三个端点，根端点是一个 SPA，/api/files 是数据源，/up 是健康检查端点。在根目录下执行：$kamal init 此时会出现 config/deploy.yml，这就是 kamal 的配置文件。但是原配置过于冗长、注释繁琐，这里针对本例的简单应用，请直接清空然后复制粘贴以下内容：service: app-size-comparison # 把kamal改成你Docker Hub的用户名，或你自定义registry的命名空间 kamal/app-size-comparison # 部署的目标服务器，即你ssh的IP或域名 servers: web: - 192.168.0.1 # 自动启用Let's Encrypt proxy: ssl: true # 换成你要部署的域名 host: lastname.uqs.me app_port: 8000 builder: arch: amd64 registry: password: KAMAL_REGISTRY_PASSWORD 再转到.kamal/secret：# Secrets defined here are available for reference under registry/password, env/secret, builder/secrets, # and accessories/*/env/secret in config/deploy.yml. All secrets should be pulled from either # password manager, ENV, or a file. DO NOT ENTER RAW CREDENTIALS HERE! This file needs to be safe for git. # Option 1: Read secrets from the environment # KAMAL_REGISTRY_PASSWORD=$…