设计都是权衡取舍。好处是你不会像 JS 或者 Python 那样因漏写一个括号而传了一个 function 给需要 function() 的地方。

下面的 Y combinator，留给楼主回去思考：

def Y &f
  g = -> h, x, *xs { f[h[h], x, *xs] }.curry
  g[g]
end

factorial = Y {|f, n| n == 0 ? 1 : n * f[n - 1] }
factorial[8]

建议楼主花几分钟看一下基本的语法。这些地方和 Python 不一样的。

Ruby 调用方法可以省略括号，这就意味着：

• foo.bar 必然是 foo.bar()
• foo 可以是取局部变量也可以是 foo(), 就看这个局部变量有没有定义了
• 你可以创建 lambda 或者 method 对象，像这样： -> x { x << 'str' }, method(:foo), obj.method(:foo)
• lambda 或者 method 也是对象，调用它不是加括号而是用 call 或者 [] 或者 .()： foo.call 1, 2

Ruby 对象不能直接接括号，能接括号都是方法调用。

回到你开始的代码，可以这么写 (用 Lambda 或者 Method)：

def twice fn, v
  fn.(fn.(v))
end

append_x = -> str { str << 'X' }
twice append_x, 'ooo'

def append_x2 str
  str << 'X'
end
twice method(:append_x2), 'ooo'

也可以这么写 (用 symbol 或者字符串)：

def twice fn, v
  send fn, (send fn, v) # 这时 fn 是 Symbol 或者字符串, 不是 Lambda 或者 Method 对象 
end

def  append_x str
  str << 'X'
end
twice :append_x, 'ooo'

这是对方在试探你是不是个好忽悠的傻子。

Shadow binding 还是纯的，名字看起来相同但其实是不同的变量。

任何设计都是取舍，Elixir 就没有 dup() 和 clone() 的必要，把 struct 作为参数传给别的方法也不用担心 struct 的状态被改变了，这可以避免一些让人很头疼的 bug。但 struct 就缺乏对象维持状态的功能了（其实 process 才是和 Ruby 对应的对象……）

数据量很大的时候，需要这样的星型表，关联查询很可能搞不动的

我们每天接触的信息越来越多，有用的信息却越来越少。man 虽长，但比微博微信更值得看

图 1 中 first_id=6 的记录只有一条 ma=0，图 2 中 quality_avg 为 100，而红字描述说不要这条记录，自相矛盾。

告诉你一个技巧：SQL 是逻辑式范式的语言。

其实你把想要的数据描述清楚了，逻辑清晰，没有自相矛盾之处，你想要的 SQL 就自然出来了。

从图上看来，你的 css 文件响应很慢，可能：

• 没走 nginx，得把你的 nginx 配置发出来看看
• 或者这个文件非常大，吃满了带宽
• Rails 进程开太多了，挤满内存导致整个系统都响应缓慢

这个机器配置，puma 单进程，几个线程就足够了。

我开好头了，你们继续讲一本书……

虽然可以讲一本书... 不过有几个情况你先介绍下更好：

Rails 是用 production 模式开的吗？ 你知道慢在哪里了吗？有没有测过？

内存太小，缓存基本作用不大...

不是，它很弱的只会在输入框里插

利用 ripper-tags 跳转和自动完成

两个点竖着和横着有啥区别？

应该说更胜任，真心没多少差别，从语言基础设施上，Ruby 还有有理数/复数字面量，明显更方便啊

命令行输入

ri Net::SMTP

看文档就知道了

如果指定 465 端口的话，就会用 SSL 发送。如果是别的端口，参考 enable_ssl 方法

建议以组件级别组织样式表。

很多前端框架 (Vue, React 等) 都有支持 scoped style:

style scoped
  ...

编译后，这些样式会只对组件起效果，这样命名就很自由了根本不用什么层级。

我是反对 BEM 这种又长又臭的命名方式的... 如果是写全局级别的样式框架 (例如 reset, 布局，或者给原生 html 组件), 可以用交集的方式组织多种 feature (可参考 semantic UI 的命名方式).

例如：

.blue.button
  color: white
  background: blue
  :disabled
    background: gray

这不是件容易的事情，要花很多精力的甚至要脱产... 加油咯，希望能努力把参会体验办好

Mac 的拼音输入法有个选项可以自动在中英文之间加入空格

非要做的话，load balancer 里决定好访问哪台服务器

应该说是延迟反序列化准确些

通过只 select 你用到的字段也能达到相同的优化效果，就是手动 select 代码多写，容易写错，不易修改

opencc 可以翻译常见词的

一堆语言都有，Python 和 Ruby 最相似而已。

增加一个作用和 import 差不多的语法，但写起来丑很多，功能和已有语法重叠... 这样的多余设计实在太丑陋了。如果真通过了我真不如该写 Python 算了

Ruby 的 module 已经和 Python / NodeJS 的 module 功能是否相似了，只是 foo.bar.baz 变成了 Foo::Bar::Baz, import 变成了 include 和 using 而已。这提案只能说明还没会用 Ruby

一是太麻烦了要是所有包都学这个，写点什么脚本全都得 import 一大堆 二是如果都搞 import 了为什么还不用 Python...

个人觉得插件配置有点不容易... 其实可以应用程序端 opencc 做转换成简体后存储和查询...

不用再包一遍了吧，SDK 会帮你搞定

before(), after(), prependTo(), html(), text(), attr(), ...  是没有的，Nokogiri API 是不如 jQuery 那么好记

正式版推到 2019 年开，所以这次加了 Autumn 后缀

Scrapy 用得都是泪，几个痛点：

• 浏览器 (Splash) 和代理一起用就麻烦得一 b, 想要某些用代理某些不用代理，就得用隐藏的 dont_proxy 选项控制
• Web 服务 (Scrapyd) 就只是一个单机服务而已，根本没考虑部署多台机器 (当然一般一台机器就够了不过扩展起来要自己搞很多东西)
• Scrapy 设计的 parse callback 其实很不 flexible, 很难接收 request 的一些参数，如果想用 lambda 会发现有一堆限制 (例如里面不准用 statement), 于是就得切出去多搞一个类...
• Python 处理字符串限制太多，正则的使用极其不方便，urllib 的一些辅助函数在各版本变化很大

基于这些，我觉得 kimurai 相当不错了 (即使用的人不多)