python 是多範式語言，ruby 是 oo 語言，天生沒有函數，對數學的親和力差

操作符在參數列表和在函數體裏意義不同應該是 c 以來的傳統藝能，c 的*在參數就是聲明指針，在函數體就是取值，同理 ruby 的&在參數裏是聲明 block，在函數體是轉換成 block

@316786359 @lijunwei 谢谢，我大概能理解这两种测试的区别，不过一个问题是集成测试应该怎么写，如果单元测试已经覆盖了对内的所有东西，那么集成测试只应该测试不同单元之间的调用，也就是如果 A 单元调用了 B，只要确保 A 发出了调用的信息，并且调用信息和 B 单测里期望的调用结构是一致的，别的什么都不需要关心。这样的话单元测试和集成测试覆盖的东西才没有交集，如果能做到这样应该是很好的。

我的案例应该不适用单元测试和集成测试“覆盖面”的差异，举个例子，一个测试是写关于顾客购买了的商品，那么在准备测试数据的时候，自然的想法是PurchaseService.call(client, product)，然后数据库里就有这个用户买完东西的状态了。但是我同事会说，这里不应该调用 PurchaseService 因为它创建的东西不完全是测试需要的，应该用 factory 自己构造一个购买后的状态。那么在这里用 service 还是用 factory 构造测试数据其实和覆盖面是没关系的，用两种方式该覆盖的都不会少。我认为如果以测试全部跑通为基准，显然用 service 能发现比用 factory 更多的问题，因为如果 factory 都会挂那么 service 也一定会挂，但是反之不然，用 service 挂了可能是 service 的问题，用 factory 是不会挂的。如果以测试跑通的比例为基准，那么用 factory 是更好的，因为有相当一部分测试可能不会挂了，但是这是以维护多一套 factory 为代价的，而且实际上挂的事实没有改变。因此我觉得“隔离测试以保护其不挂/不变”意义不大，可能对于足够大的项目，测试跑通的比例对于他们的规划/定位问题是有意义的，但是对于我们的小项目就没意义了。这里可能有一种容错和速错的理念区别

看起来不错，这个应该可以参考，不过我需要的更多是关于数据库的数据，例如一些测试用例的数据需要一串 service class 调用才能生成（用户做了什么操作），和 service 的耦合是在这里引入的。我需要把这些操作的数据库结果集存起来（相当于 factory），然后在跑测试之前重放，如何进行 diff 可能也是个问题

我的做法是新开了个类似 routes 的文件夹，然后里面定义 endpoints 的 dsl，然后在 routes.rb 里面读取和引入这些 endpoints 定义成实际的 routes。然后这些 routes 都是按约定对应到 controllers 上的。

然后再用 rails 的 FileUpdateWatcher 监视这个目录的变化，然后当有变化的时候触发 routes reload，就可以实时更新，别的类型定义等都存成类文件，要用的时候按名字 constantize，这样可以利用 rails 的 autoload。

这样的话实际上对 rails 的侵入部分就只是 routes，做成插件应该不难，难的是确定各种约定，以满足不同用户的需求

因为这个 dsl 是我自己写的，ts 生成也有了，目前用起来还是很爽的，后端加上检查之后返回类型不吻合的数据会抛错，这样前端可以保证不会遇到类型错误了

这就是团队内斗的一部分，急需高限制性的手段来规范他人的写法，所以我引入了 typescript vue3 还有一系列规范，防止他们继续用 vue2 堆屎

我觉得传统 restful 和 graphql 的区别也没有那么大，因为标准的 restful 任何东西都要抽象成资源，就算是订单取消都要"POST /orders/:id/cancellations"，这里面的cancellation不一定就是真的对应模型，可能只是order的一个字段，后端暴露的资源完全可以是虚构的

看到了那个 apollo codegen，确实可以实现生成 ts，这个应该更适合普遍使用，我的就在自己项目里瞎玩就好了

对，这个过程可以省掉，甚至连协调 url 的过程都可以省掉，但更重要的是要在前端用 ts，不生成的话需要自己用 ts 写一套类型，然后假定拿到的 json 一定是符合前端类型的，数据的字段啊类型都可能出错，降低效率

我不太熟悉 graphql 的生态，可能我这其他人 adopt 它很难（可能也包括我自己），不过思路可能有接近的地方。这个应该更接近 rpc，如果前端后端都是 ts，那https://trpc.io/ 这个会非常爽，但估计对于 rails 能生成一套前端函数已经不错了

“At 00:00 on every 3rd day-of-month if it's on Sunday in September.”不是写的很清楚吗，依赖了周日，不要周日的话把最后一个改星号

另外一楼的工具和 crontab.guru 的结果不一样，我更信 crontab.guru 的

我以前觉得 ECS 是 OO 发展的终极形式，因为 OO 仅考虑了对象有什么属性，ECS 还考虑了视角的问题，即同一份属性在不同人看来是怎么样的

这些称作计算器语言更恰当，定理证明器是什么样的可以参见 https://ruby-china.org/topics/41265 或者 https://leanprover.github.io/ 。

现实中的例子就是把数学证明写成代码，然后用计算机验证。定理证明器只能通过搜索来找证明，搜索空间不会太大，因此自动并不是重点，重点只是验证。

数学非常关心数据类型，类型决定了性质，同样一个数字 1，在 mod 5 和 mod 6 的意义上是不同的，前者是域可以套用线性代数，后者就不行。所以数学里取一个数字都会写 let n ∈ N，let n ∈ Q 等等，这些就是数据类型。数学的未来反而是迁移到由更强大的类型系统支持的定理证明器上，这样才能用机器验证证明，并且构造一个可靠的数学知识库。

支持，代码用粤语读起身好过瘾

js 有 proxy 之后能完全实现 ruby 的元编程功能，decorator 甚至可能比 ruby 更方便，rails 难抄很大部分是 codebase 的复杂度，但是这个复杂度即使是今天的 ruby 程序员也未必当成值得骄傲的事

如果按 review 活跃程度来判断 offlime 其实未必有什么问题

人是计算机，那么做菜的时候装载的程序是菜谱，跳跃的时候装载的程序是物理定律，读书的时候装载的程序是书中的推理

支持，我可以来搬砖

谢谢各位，我研究一下

发个 pg 的

如果说的是正常 html 转这个，很容易弄出转换器，如果说的是普通缩进，那 python 怎么贴就怎么贴

mint 看上去不太好看，简单看了一下，mint 的 connecting store 类似于 react hooks，而 store 内的状态更新则接近 svelte，我猜测它是有响应式设计的。但是 imba 是没有响应式设计的，参照楼顶更新的内容。

一个 fun fact：svelte 是参考 imba 做出来的 https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934

可以用 set_trace_func 获取外部 binding，然后 eval

ruby2.7 开始已经去掉了

机翻？

100.times do
  long_str = "a" * 10_000_000
  sleep 1
end

仅仅执行这个内存使用是很稳定的，我觉得如果有问题的话应该是 rails。还有就是之前用 development 来跑一个小项目，大概几天之后就会非常卡，production 没这个问题，当时没细究但是也有可能是这个环境差异