@Rei

+1

所以都切换为电脑版搞

SQL 特殊地方，他是一个 三元逻辑系统 true、false、null 逻辑处理的时候，必须要考虑 null，除非这个字段加了 非 null 约束。

他的布尔值运算，也要遵循三元真值表。

（前几天看了，逃。。。

感觉远程这件事，算时间成本、租办公区成本，应该是比较共赢的。只是这个想法里面，对打工人利好，管理者应该不想。

速度上来了。以前 gitlab.com 访问起来非常非常慢

可以这样理解。毕竟 KPI 驱动、急功近利的晋升导向的不良氛围，而且维护性根本不可靠。而且做来做去就那点东西抄抄弄弄的。

实话是活，和国外还是有点差距。

他们家网站的插画，真是喜欢

答案如果找到了，AI 不就造出来了。如果 AI 造不出来（不能被复现) 说明答案还没找到。

有时候我觉得，这跟 Ruby、Rails 都没什么关系。

市场上有的是未成熟的技术就有人上赶着去用。Go、Rust 周边设施都没完善起来。Nodejs 也是乱七八糟的情况。

新技术替代旧技术，有一大部分原因是一种技术营销的结果。

另外还有一个国情特殊，国内的人喜欢迷信有国外大厂背景的技术比如 Google，仅此而已。国外大厂推出了什么，国内就会换一波。这几年一直都是这样。

国内缺乏上游技术制造的氛围和生态，所以总是换来换去。

🆙

截止今天 Rubinius 2 年没又提交了。

看来东西也要看是否能坚持到底

如果自己，可能是正则、字符串替换。

这个是 Ruby 的 Syntax 范畴，肯定是 他的 解释器里面 Parser 部分实现的。转成 AST，以语法的形式处理。

观望观望

作为前端，深知前端的轮子都靠不住。三天打鱼，两天造轮子。

之前看到一个 https://lit.dev/

背景：在公司的 slack channel 里一直安利 Ruby，突然有一天，有个同事问我——想白嫖一个环境搭建的教程。

我是菜鸡，难的我不会。可是这个简单啊，我快速撸一篇，这个适合新手。

关键字 Safe Navigation Operator

官方最新的文档

https://ruby-doc.org/core-3.0.2/doc/syntax/calling_methods_rdoc.html#label-Safe+Navigation+Operator

更新历史

https://www.ruby-lang.org/en/news/2015/11/11/ruby-2-3-0-preview1-released/

Feature BUG 跟踪 https://bugs.ruby-lang.org/issues/11537

404 了

然后当时的原文

https://github.com/baya/baya.github.io/blob/master/_posts/2013-12-06-%E4%B8%80%E6%AD%A5%E4%B8%80%E6%AD%A5dsl.md

新的地址 http://baya.github.io/2013/12/06/%E4%B8%80%E6%AD%A5%E4%B8%80%E6%AD%A5dsl.html

update

我其实觉得有高质量的标准库挺好的。

JavaScript 就不存在高质量、标准库。所以各种代码的操作都极大地围绕周边第三方仓库。一些简单的事情也很复杂。百里不同样。 第三方也可能不维护了。这样说可能有些人都没有概念。比如处理时间，JS 是没有自己完善的标准库的。需要仰赖第三方，那你选择就多了 moment、date-fns ……简单的事情，可能每个仓库不同人经手口味不同。

简单的事情也变复杂了。

这个角度，我其实很欣赏官方愿意花精力维护一些标准库。

而且 Ruby 的标准库范围很广，让我觉得很有趣。 etc 的存在，意味着，你去写一些命令行的程序也很方便。操作系统方面兼容性的细碎不是一般小白，或者我就想快速做一个脚本。这样的人可以搞定的。

web 即 app

周杰伦可以给我签个名么

个人不成熟的观点：

需求有限，低代码是 OK 的，就像简单的程序你怎么写他都可以 工作。

现实往往是充满变化和对撞——这种变化的本质来自于市场、竞争对手、人们的喜新厌旧和贪得无厌。有价值的需求永远是 超前的，低代码依托在一个极其有限的模型下根本 cover 不住。

当你用低代码抽象的时候，发现还不如写代码快。

挺酷。

不过不太喜欢 缩进语法。一个缩进导致解析错误有点崩溃。

amd 主机有推荐的么

感觉回到了 2010 年的 mbp

—— 发送来自我的 2010 年 mac book pro

这个作者是一如既往的优秀。可惜现在退休了

Chrome F12

Ctrl+Command+P 命令面板

输入 Screen 这里有截图功能

我个人的观点，东西体量小，觉得没区别。

Nginx 内部的是 EventLoop 类似的单线程异步，分发请求的效率非常高。背后有多个 server 多个服务的时候，未必全是 rails 的时候，很有必要。

Puma 是多线程的，他自己会慢一些。

从原理感受下就知道了。其实是有区别的。Puma 有速度和用途的局限性。而且听说 Puma 是不是会存在回收时候的等待。这样 Nginx 会弥补一些 Puma 的问题。

浏览器只支持这个，没办法避开

前端的多个框架从战国最后到几家独大，门槛降低。前后端分离就比较合理了。

其实这件事很清晰，Web 在前端部分的工作有独立的逻辑、本身就有独立的语言，所以他们是可以看成是独立部分。早些年是因为很简单，字符串拼接，借助了后端语言来实现。

跳出来，你不会觉得 iOS、Android 甚至写一个 PC、Mac 的 Application 前端也非要用 后端框架生成。其实是一样的。

之前小小的使用 Rails 遇到 多数据库问题的时候，就发现一个问题—— 并不是支持多数据库很难，而是 Rails 支持多数据库很难，难点在于 Rails 要把那么多东西塞入到他的 MVC 的模型里保持一致。

同理，个人观点是，并不是处理前端这件事很难很复杂实际上已经有独立的 vite，webpack 已经熟悉前端的同学会觉得反而没那么麻烦，相反是非要融合进 Rails 很难很复杂，要重新建立概念。

api model 挺好，甚至中小问题，微框架加上一点个人的胶水代码，解决问题更快。