这套方法和动态表单结合在一起就不一样了，表单系统光收集数据没有意义，收集出来的数据需要做搜索、做统计、做分析才有意义（BI），而这些是 NoSQL 的弱项，生态没有关系型数据库丰富。而 PG 可以说兼顾了关系型数据库的结构化

首先他提出了一套存储结构的设计能够让用户定义的动态表单转换成标准的 PG 视图，这时候首先可以像一般的 SQL 表一样去查询、使用 PG 生态下的 BI 工具，甚至可以使用 Active Record 来用 Rails 的方式使用虚拟表（视图），能够被 AR 包装后，便可以利用 Ransack、Blazer 瞬间搭建出高级搜索和 BI 系统，这些都是 Rails 生态下的产物，于是又有了超高的可定制性...

并且 PG 提供的能力可以尽可能的保证如此灵活的设计下有空间进行优化

其实是这样的，去年 k0kubun 有请愿过 Rails team 考虑设置最低版本到 2.5，MJIT 基于 2.5 的字节码设计所以相容，这样未来 MJIT 调教完成，Rails 6 项目可以直接升级 Ruby 而不用担心回归问题。当时 Rails team 比较保守没有同意，最近刚刚做出了最低为 2.5 的改动，那么正和 JIT 开发者的意，其次使用 2.5 消除了很多 workaround 和 ActiveSupport 里实现的增强方法，并且比如 2.5 优化了 block 调用，重构一些瓶颈（比如 write_attribute）可以利用优化带来接近 10% 的性能改善

你要读过 webpacker 源码就知道其实那玩意只是做了个 webpack 跟 rails 的桥接，另外在 webpack 还没领悟约定优于配置的时候引入了一套默认实践，没了

webpack 本身就很麻烦，webpacker 起码不会比标准的 webpack 难用

都有了啊

早发布了，不过没作为默认栈，其实也没必要，因为如果你用 vue react 没必要用，stimulus 更多是用于遗留的场景或者是轻量场景

注册一周以后应该就可以了

完全引入前端那一套了（就是 Webpack），另一方面是配套的 JS 库去 jQuery 化、ES 6 化

不过 Trix 还是 Coffee 做的，我是想忽悠人把 Trix 和 ActionText 解耦。。。

我其实想忽悠个人让 ActionText 和 Trix 解耦，大概就是后端增加个 adapter 层来决定输入 text 的预处理和渲染，如果前端不选择 Trix 就自己实现前端的部分

我自己可能没空做这个事情。。。

接下来就要表演如何结合 FormCore + Schemaless-PG 实现一套表单应用了

我来划重点：

"客户名" => "hooopo",
"印象" => [
            [0] "土豪"
        ]

很正常啊，代码是否公开和你是否能够进行商业使用是两码事，具体能否做要看开源协议怎么规定的

这个优化方向中央是滋瓷的吗？

flowable 算是 jbpm 原教旨版了... jbpm 系列的发展也可以说是波澜壮阔了

所以 PG + Rails 是 Web 2.5 吗 😂

auto fibers 要解决的问题，有好几个方案在竞争，@dsh0416 对这块比较了解

可以试试显式声明字段类型 attribute :update_cycle, :time

https://api.rubyonrails.org/classes/ActiveRecord/Type.html

如果内置的都不能适应场景的话，就得自己扩展了

来源？Eric Wong 今天还在推补丁的 https://bugs.ruby-lang.org/users/724

可以搭配《理解 Unix 进程》做参考

关键字：浮点数、IEEE 754

来介绍下工作内容还有时间要求比较好~

顶吕神，接口没有必要强制 private，Ruby 的封装很容易就可以被破坏，如果你希望子类一定要实现某些方法，可以在父类定义接口的时候 raise NotImplementedError

天津亮了。。。

干...那天长辈过寿...祝圆满成功，等下一期

处理了。。。

@lgn21st 写的呀

说实话不太喜欢加州，姐姐定居在 Fremont，上次去还在飞机上干的我鼻血狂流不止...旱季比北京还暴躁...

前几天推上 DHH 爆料他家被野火波及烧没了... 刚才发推表示没能去成遗憾，这倒是破了 DHH 不去 RubyConf 的流言...

你可以注册个 kissflow 知人之类体验一下，还有 activiti 那些开源项目自己起一个感受下

具体到设计上，知人那套 workflowable 魔改加上 并行流程支持的做法还是很直接的 楼上 @yaocanwei 也是这思路

你发这种也很常见的。

需要哪些流转方式取决于甲方实际的流程，如果你主导的话前期多多和客户接触了解清楚他们的各种流程是最好的。

你作为乙方除非能说服甲方否则就要按照他们的要求来的，我举那个例子也不是很恰当，实际有更多复杂甚至不合理的