kowalskidark (Kowalski Dark)

Ruby China 社区里全栈工程师的具体定义是什么

kowalskidark — Sun, 10 Oct 2021 23:33:23 +0800

一直都看到社区里很多招聘帖都在发“全栈工程师”的招聘，也有不少培训班说自己是培养“全栈工程师”的。

个人粗略总结是，要求会写网页前端，也会做网站后端，即“web 前后端都干”。

请问在 Ruby China 社区这个语言环境下，“全栈“是否有一个可以达成共识的简单定义？

例如作为基准线的知识（学过什么理论）、技术（已经掌握了什么样的工具）和经验（解决过什么问题）要求。

Ruby Hack Challenge[0x01]: MRI 的源码结构

kowalskidark — Fri, 28 May 2021 13:22:13 +0800

Ruby Hack Challenge[0x00]: Ruby 的开发文化

(2) MRI 源码结构

关于这份文档

本文介绍了 MRI 的源码结构，同时介绍了 hack MRI 的必要知识。

包括了以下几个话题：

练习：clone MRI 的源码
练习：构建 MRI 并安装构建好的二进制
练习：用构建好的 Ruby 二进制来运行 Ruby 程序
MRI 源码结构
练习：初试 hack，修改版本描述信息

前提

要执行以下的命令，我们默认你使用的是 Unix-like 的环境，例如 Linux 和 macOS 等。如果你使用的是 Windows，你需要参考其他的材料。

备注：我们也提供了一个实验性的 docker 镜像：docker pull koichisasada/rhc。通过 su rubydev 命令来切换到 rubydev 账号开始 hack。

我们默认使用以下的目录结构：

workdir/
- ruby/ <- git clone 下来的 ruby 源码目录
- build/ <- 构建目录（*.o 文件和其他编译过程产生的文件存储在这里）
- install/ <- 安装目录（workdir/install/bin/ruby 是安装好的 Ruby 二进制)

我们需要 git、ruby、autoconf、bison、gcc（或 clang 等）和 make 命令。如果依赖的库存在，Ruby 标准扩展（例如 zlib、openssl 等）也会被构建。

如果你用 apt-get（或 apt）来做包管理，可以使用下面的命令来安装所有依赖：

$ sudo apt-get install git ruby autoconf bison gcc make zlib1g-dev libffi-dev libreadline-dev libgdbm-dev libssl-dev

练习：Clone MRI 源码

使用以下命令：

$ mkdir workdir
$ cd workdir
$ git clone https://github.com/ruby/ruby.git # clone 下来的源码将会在 workdir/ruby

练习：构建 MRI 并安装构建好的二进制

确认上文提到过的所需要的命令可用
$ cd workdir/ # 进入 workdir
$ cd ruby # 进入 workdir/ruby
$ autoconf
$ cd ..
$ mkdir build
$ cd build
$ ../ruby/configure --prefix=$PWD/../install --enable-shared
- prefix 选项用来指定安装目录，你需要传入一个完整的绝对路径（这里是 workdir/install）。
- Homebrew 用户需要添加以下选项 --with-openssl-dir="$(brew --prefix openssl)" --with-readline-dir="$(brew --prefix readline)" --disable-libedit
$ make -j # 执行构建。 -j 指定了并行构建.
$ make install # 建议：为了加快安装，使用 make install-nodoc 安装不带 rdoc 的 ruby.
$ ../install/bin/ruby -v 会显示你安装的 ruby 命令的版本信息

备注：在执行 make 时添加 V=1 选项（例如，make V=1 -j 等）会输出构建过程中执行的全部命令。默认使用的是 V=0 即不输出详情。

练习：用你构建好的 Ruby 来运行 Ruby 程序

你可以通过很多方式，使用构建好的 Ruby 来运行脚本。

最简单的是直接启动安装好的 Ruby，例如调用 workdir/install/bin/ruby。这就和调用一个预先构建的 Ruby 二进制一样。但是这意味着每当你修改了 Ruby 的源码，都需要执行一次 make install，非常费时。

这里介绍一些便捷的方法，在不安装的前提下启动我们修改过的 Ruby。

使用 miniruby

在构建 Ruby 过后，workdir/build 下会有一个可用的 miniruby 命令。miniruby 是一个精简版的 Ruby，用于构建 Ruby 本身。然而 miniruby 被精简的部分其实很少：它不能加载扩展库以及缺少完整的字符编码支持。你可以在 miniruby 中使用大部分的 Ruby 语法。

miniruby 是在 Ruby 构建过程中的第一阶段被构建的，因此使用 miniruby 对 MRI 的改动进行早期验证很有帮助。

下述开发流程是十分高效的：

修改 MRI。
运行 make miniruby 来构建 miniruby (这比 make 或 make all 快很多)。
用 miniruby 执行一段 Ruby 脚本，测试你改动的正确性。

为了支持这样的开发流程，我们在 Makefile 中提供了一个 make run 规则，用来：

构建 miniruby
用构建好的 miniruby 运行 workdir/ruby/test.rb (test.rb 是在 Ruby 源码目录里的)。

借助 make run 你可以通过以下几步来测试你的改动：

在 ruby/test.rb 为你的改动编写测试。记住在 test.rb 里你不能 require gems 或者扩展库。
修改 MRI
在构建目录里调用 $ make run

使用完整功能的 Ruby（而不是 miniruby）

如果你想运行“正常的”Ruby，即可以加载扩展库的版本，你可以运行 make runruby。这样不用执行 make install 就能运行 Ruby，节省时间。

在 ruby/test.rb 编写你的测试代码。
修改 MRI。
在构建目录里调用 $ make runruby。

用 gdb 调试

备注：在 macOS 上运行 gdb 非常麻烦。我们默认你在 Linux 环境执行下文的指令。

当你修改 MRI 源码，很容易会引入一些严重问题，导致产生 SEGV。为了调试这种问题，我们提供了一条 Makefile 规则来支持使用 gdb 进行调试，当然你也可以使用断点进行调试。

在 ruby/test.rb 编写测试。记住在 test.rb 里你不能 require gems 或者扩展库。
调用 $ make gdb，通过 gdb 启动 miniruby。如果没有问题，gdb 会结束执行而不报错。

make gdb 用的是 ./miniruby。如果你想调试 ./ruby, 使用 make gdb-ruby。

如果你想使用断点，修改 make gdb 命令产生的 run.gdb 文件。例如 b func_name 这条 gdb 命令会在 func_name 函数开始的地方插入一个断点。

$ make lldb 是为 lldb 准备的类似规则，你可以用 lldb 来替代 gdb（但是 Koichi 不清楚细节，因为他并不用 lldb）。如果你用 macOS 这也许有用。

运行 Ruby 的测试

$ make btest # 运行 ruby/bootstraptest/ 中的 bootstrap 测试
$ make test-all # 运行 ruby/test/ 中的 test-unit 测试
$ make test-spec # 运行 ruby/spec 中的测试

这三种测试有不同的目的和特点。

MRI 源码结构

解释器

你大致可以看到下述的目录结构：

ruby/*.c MRI 核心文件
- Ruby 虚拟机核心
  - Ruby 虚拟机
    - vm*.[ch]: Ruby 虚拟机实现
    - vm_core.h: Ruby 虚拟机数据结构定义
    - insns.def: Ruby 虚拟机指令定义
  - compile.c, iseq.[ch]: 指令序列 (字节码)
  - gc.c: GC 和内存管理
  - thread*.[ch]: 线程管理
  - variable.c: 变量管理
  - dln*.c: 扩展库使用的 dll 管理
  - main.c, ruby.c: MRI 入口
  - st.c: Hash 算法实现 (参看 https://blog.heroku.com/ruby-2-4-features-hashes-integers-rounding)
- 内置类
  - string.c: String 类
  - array.c: Array 类
  - ... (文件名指明了类名，例如 time.c 对应 Time 类)
ruby/*.h: 内部定义，C 扩展库不能使用它们。
ruby/include/ruby/*: 外部定义，C 扩展库可以使用他们。
ruby/enc/: 字符编码信息。
ruby/defs/: 各种定义。
ruby/tool/: 构建 MRI 使用的工具。
ruby/missing/: 实现了在某些操作系统上缺失的特性。
ruby/cygwin/, ruby/nacl/, ruby/win32, ...: 特定操作系统和运行环境相关的代码。

库

有两种库：

ruby/lib/: Ruby 编写的标准库。
ruby/ext/: C 编写的扩展库，也会被一起打包。

测试

ruby/basictest/: 旧的测试
ruby/bootstraptest/: bootstrap 测试
ruby/test/: 用 test-unit 表示的测试
ruby/spec/: 用 RSpec 表示的测试

杂项

ruby/doc/, ruby/man/: 文档

Ruby 的构建流程

Ruby 的构建流程分为几个阶段，包括了代码生成等。其中有几个工具是用 Ruby 编写的，因此 Ruby 的构建需要依赖 Ruby 解释器。发布的 tarball 包括了生成好的代码，因此用发布的 tarball 安装 Ruby 不需要 Ruby 解释器（以及其他开发工具，比如 bison）。

如果你想用通过 Subversion 或 Git 仓库获取的源码来构建 MRI，你需要有一个 Ruby 解释器。

下面描述了构建和安装的流程：

构建 miniruby
1. parse.y -> parse.c: 用 bison 将语法规则编译成 C 代码。
2. insns.def -> vm.inc: 用 ruby（BASERUBY）将 Ruby 虚拟机指令编译成 C 代码。
3. *.c -> *.o (在 Windows 上是 *.obj): 将 C 代码编译成 object 文件。
4. 链接 object 文件生成 miniruby
构建字符编码支持
1. 通过 miniruby 将 enc/... 翻译成恰当的 C 代码。
2. 编译 C 代码
构建 C 扩展库
1. 用 miniruby，mkmf.rb 和 extconf.rb 来生成 Makefile
2. 用生成的 Makefile 来执行 make
构建 ruby 命令
生成文档（rdoc, ri）
安装 MRI (安装到 configure --prefix 选项指定的路径)

实际的构建过程中步骤会更多，然而要完整地列出所有步骤是非常难的（甚至我也没有记住全部），因此以上的只是精简过的流程。如果你好奇，可以查看包含了所有的规则的 common.mk 和相关文件。

练习：初试 hack，修改版本描述信息

让我们开始修改 MRI, 默认我们将所有源码放在 workdir/ruby。

我们要修改版本描述信息，即 ruby -v（或 ./miniruby -v）会显示的内容，让它显示你定义的 Ruby 版本信息（例如包含了你名字的版本）。

在编辑器中打开 version.c。
大致阅读整个 version.c。
我们要找的看起来是 ruby_show_version() 函数
C 函数 fflush() 用来输出缓冲区内容，因此我们推测在 fflush() 前添加用于打印的代码应该有用。
添加一行 printf("...\n");（将 ... 替换成你想要的字符串）
运行 $ make miniruby 开始构建（别忘了要先切换到构建目录）
运行 $ ./miniruby -v 并检查结果
运行 $ make install 来安装 Ruby
运行 $ ../install/bin/ruby -v，检查对于安装好的 Ruby 是否生效

最后，除了插入 printf(...) 语句，可以试试替换掉整个 ruby... 描述（比如换成 perl...之类的），这会很有趣 ;p

Ruby Hack Challenge[0x00]: Ruby 的开发文化

kowalskidark — Thu, 27 May 2021 15:44:58 +0800

原文：GitHub: ko1/rubyhackchallenge

本文是 MRI 开发者 ko1 为了帮助新手了解 MRI 开发所写的文档

在上手 Ruby 开发时 ko1 向译者推荐了该文档和另外一本 Ruby under a microscope（见文末）

文档中涉及了很多 Ruby C API 的细节，对 Rubyist 开发 C Extension 非常实用

因此我将其英文版本翻译成简体中文，发布在 Ruby China 社区，希望对大家有帮助

(1) MRI 的开发文化介绍

关于这份文档

本文介绍了 MRI 的开发文化。MRI: Matz's Ruby Interpreter（即你使用的 ruby 命令）是开源软件。MRI 的开发始于 1993 年，第一版发布于 1995 年。由于 MRI 是开源的，任何人都可以参与到开发过程中来。但如果你对 MRI 的开发一无所知，参与到其中并不简单。因此，本文为你介绍了我们是如何开发 MRI 的。

本文涵盖了：

如何开发 MRI（开发流程和工具）
如何管理 bug ticket
如何了解 MRI 的内部实现以及如何获取社群信息
MRI 中还有哪些待解决的问题

MRI 开发流程

Ruby 是开源软件，因此任何人都能参与开发。

“开发 Ruby”有两种含义：

Ruby 语言的标准（specification）制定。
Ruby 的一种实现 —— MRI 的开发。

MRI 是 Ruby 语言的参考实现，因此被 Ruby 标准采纳的功能都将在 MRI 上被实现。如果我们在 MRI 上修复了一个 bug，意味着我们也会修改 Ruby 标准的对应内容。因此，在决定是否修复 bug 时，必须考虑对兼容性的影响。但准确地说，也存在着许多 MRI 独有的特性，比如 MRI 的虚拟机指令，所以并不是所有对 MRI 的改动都会导致 Ruby 标准产生变化。

代码仓库和 Ruby committer

Ruby 主要的代码仓库使用 Git 进行源码管理 https://www.ruby-lang.org/en/community/ruby-core/ 。许多人都有权修改这个仓库的内容，我们称之为“Ruby committer”。目前全球大约有 100 位 Ruby committer (实际上活跃的人数要少得多。如果你成为了“Ruby committer”，你不能放弃这个称号。）

每位 committer 都可以修改 MRI 源码的任意部分，但是不同 committer 都有各自负责的部分。如果一位 committer 想要修改其他部分，他/她需要事先征求负责这部分的 committer 的建议。例如 ko1 是 Ruby 虚拟机的开发者，因此任何一位想要直接修改 Ruby 虚拟机的人在提交改动前都应该征求他的建议。

并不存在正式的 code review 机制。我们会检查被提交的 patch 并指出我们发现的问题。我们使用 git bisect（或类似的技术）来查找问题。如果打算进行大规模的改动，也会请其他的 committer 来 review。

同时，GitHub 上还有一个镜像仓库 https://github.com/ruby/ruby/。

Ticket 管理

我们使用 Redmine 这个 bug 追踪工具来讨论对 Ruby 标准的修改、bug report 和其他相关内容。每个被提交的 ticket 对应一个相关的 issue。新的 ticket 和对 ticket 的内容修改会以通知的形式被发送到 Ruby 的邮件列表。这里有英文（ruby-core）和日文（ruby-dev）的邮件列表 https://www.ruby-lang.org/en/community/mailing-lists/。

大部分重要的 issue 和 proposal 都用英文提交。如果是精简的 issue 也可以用日文提交 ticket。

Ticket 可以被分为两类：“Feature request”和“Bug report”

Feature request
- 请求为 Ruby 语言本身添加新特性或修改已有特性
- 顺带一提，Redmine 的 URL https://bugs.ruby-lang.org/projects/ruby-trunk/ 里有“bugs”这个词 :)
Bug reports
- 奇怪的行为，性能问题等，除了修改 Ruby 标准之外的一切问题。

在你提交 ticket 时会被要求选择用何种语言（英文或日文）进行表述，根据你选择的语言我们会选择将其转发到对应的邮件列表中（ruby-core 或 ruby-dev）。

好的 bug report 应该包含以下几点：

概述（Summary）
可复现的代码和运行环境信息，以便复现 bug（ruby -v 命令的结果，操作系统和编译器的版本信息等）
期望的运行结果
实际的运行结果
如果可能的话，带上一个可以解决此问题的 patch

想要详细了解这部分，请阅读 https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReport （英文）或 https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReportJ（日文）。

好的 feature request 应该包含以下几点：

摘要（Abstract）
背景 (Background): 你想要解决什么问题，原因以及你的用例
提案（Proposal）
如果可能，带上你的实现（Implementation）
评估 (Evaluation)
讨论（Discussion）
总结（Summary）

举个例子，如果你想要提交一个“Feature request”，你很可能会被问到“你的实际用例是什么？” 用一个极端的例子来解释：如果你提议“应该修改这个特性，因为它导致了行为的不一致，但是我不再用这个特性了”，那么你的提案将会被拒绝（相较于修复不一致行为，保持兼容性更重要）。

了解更多信息请阅读 https://bugs.ruby-lang.org/projects/ruby/wiki/HowToRequestFeatures.

GitHub 上的 issue 或 pull request 偶尔也会被查看，换句话说，有时它们也会被忽略。我建议你去 Redmine 上开一个新的 ticket 链接到你在 GitHub 上创建的 issue 或 pull request。或者你也可以尝试直接联系一位 Ruby committer。

MRI 的 CI

MRI 是个庞大且复杂的软件，因此使用自动化测试来保证软件质量（QA）非常必要。我们为超过 5000 个文件编写了大约 450,000 行测试。

我们同时准备了大量不同的环境来运行测试。例如，许多广为人知的操作系统如 Linux，macOS，Windows 以及不那么有名的 *BSD，Solaris 等。通常我们使用 Intel 的 x86/64 或 ARM 处理器，但也会用其他平台的处理器进行测试。这是一份 Ruby 支持的平台列表：https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms。

因为 MRI 会运行在许多环境中，我们偏向于尽可能地在大量不同环境中进行测试。使用持续集成（CI）来进行自动化测试是常见的实践方式，Ruby 也不例外。

在使用流行的 Travis-CI 服务之外，我们还维护了 http://rubyci.org 网站来收集更多种环境的测试结果。一般来说 CI 系统会消耗它自身的计算资源。然而我们的资源有限，因此我们并不自己筹备并维护这些环境所需要的计算机，而是交给社区志愿者使用他们自己的计算资源来进行测试，再收集测试结果。chkbuild 工具会构建 Ruby，运行测试，生成测试结果，并对输出进行 diff 以方便我们辨别哪个版本的 Ruby 有何种 bug。

chkbuild 是优秀的测试和 CI 框架，但是由于多种原因（例如，chkbuild 每次都会下载源码）它的运行速度很慢（一般来说要几十分钟）。为了突破这些限制，我们使用另外一个 CI 系统 http://ci.rvm.jp/，它能复用之前的构建并且可以并行地运行构建和测试，将测试需要的时间缩短到了两三分钟。这让我们每天可以进行数百次测试，对发现那些难以复现的 bug（例如时间相关的 bug）非常有帮助。

Ruby committer 应该在他们自己的机器上运行测试。如果一个 Ruby committer 不小心提交了一份不能通过测试的代码，http://ci.rvm.jp/ 将会检测到错误，不出意外所有 committer 都将会收到警报。

MRI 中待解决的问题

Ruby / MRI 有许多待解决的问题，下面是一些例子：

标准
- Ruby 2.6, ...
- Ruby 3
- JIT 编译（仅为了性能提升？放弃向前兼容？）
- 静态检查
- 并发执行
性能
- 基准测试框架和基准测试
- 性能提升
文档
Bug 修复

以下是我（ko1）想要修复的内部问题：

提升 bytecode serializer 的性能和质量
优化 method dispatch 机制
内联代码
增加 generational GC 支持的对象（特别对于 T_DATA)
提供用于测试主线 gem 的 CI 服务

有关 Ruby 开发的信息

如何探索 MRI 的内部实现

参考文献

英文

Redmine wiki
- https://bugs.ruby-lang.org/projects/ruby/wiki
- https://bugs.ruby-lang.org/projects/ruby/wiki/DeveloperHowto
Ruby Hacking Guide by @minero-aoki
- Ruby 1.8 时代 MRI 内部实现的完整教程。
- Part 1, 2 (GC, Parser) 仍很有价值。
Ruby Under a Microscope by Pat Shaughnessy
- Ruby 2.0 MRI 内部实现的简单教程。
- 不完整，但对于新手了解 MRI 内部实现很有帮助。
The Ruby Bibliography

如果你想更深层地探索 MRI，你需要掌握 C 语言。

通讯频道

Ruby's Redmine: https://bugs.ruby-lang.org/projects/ruby/
- Ticket
- Wiki
邮件列表
- https://www.ruby-lang.org/en/community/mailing-lists/ (英文) https://www.ruby-lang.org/ja/community/mailing-lists/ (日文)
- ruby-core (英文)
- ruby-dev (日文)
会议
- RubyConf 和其他会议
- 日本国内
  - RubyKaigi
  - RegionalRubyKaigi
  - Asakusa.rb, *.rb
Ruby 开发者会议 (每月在东京举行)
联系开发者个人
- Twitter
  - @yukihiro_matz
  - ...
Gitter https://gitter.im/ruby/ruby

重要提示

本文描述了很多学究式的“规则”，但是我们解释器开发者最重视的是“Hacking”精神。如果你提交了一个非常棒的 patch，即使你没有严格地遵守上述的规则，我们也会支持你的贡献。

Write code, and have fun!

大家有没有留意过 Kernel::require 这个 API 的性能问题

kowalskidark — Thu, 20 May 2021 14:41:45 +0800

完整的 benchmark 代码在 ruby-require-perf

                        user     system      total        real
require(relative)   0.001705   0.003376   0.005081 (  0.005089)
require(absolute)   0.001190   0.000009   0.001199 (  0.001195)
require_relative    0.002576   0.000000   0.002576 (  0.002567)

Kernel::require 在传入一个相对路径的时候比绝对路径要慢了差不多 4 ~5 倍，比 Kernel::require_relative 慢了 2 倍

想知道平时大家在写代码的时候有留意过这个问题吗？

另外这个 Kernel::require API 性能优化的提案在今年的 GSoC Ruby 立项了，也许我们最后能在 ko1 的帮助下调查出来结果