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 也是这思路

你发这种也很常见的。

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

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

你要做的 his 属于bpms，这领域名气比较大是java的 jbpm 和衍生的几个 比如 activiti flowable

状态机的问题是他只能表达一个状态，比如我在帖子里提到的图例，比如：提请假，报直属领导同意，同时 报HR专员同意，然后抄送部门负责人，最后申请人确认后生效。并行的两个步骤。状态机就无法实现了。PetriNet没有这问题

正因为看过一圈没有所以我才做的吧

我调研过，我做的应该是全网独家。。。

合并进核心没必要，企业级 Rails 项目框架还有 http://trailblazer.to/，也提供了一些针对特定场景的重要轮子。

其实 ActionCable、ActiveStorage 之类默认包括在 rails 里，其实他们根本就不算 rails core 的，从这几个组件的设计上讲，都是 rails 的 engine。

Rails 的核心是 Railtie —— 工具链、ActionPack —— 控制器和视图（的接口）、ActiveModel 和 ActiveRecord —— 模型和CRUD

其他都是外围，放在一起可以说是 rails team 的工程和宣传上的策略。

另外那些组件从 Basecamp 抽出来的，又 Rails team 和 Basecamp dev team 有很多交集，所以约等于 Rails 官方维护这些组件。

工作流是个很宽泛的概念，审批系统算，如果你看 Wiki，容器编排、CI 的 pipeline 也都可以算，不同的工作流系统设计上有他的侧重点，所以可复杂可简单，但本质上，（不是很精确的解释哈）都在解决流程的定义和流程的执行这两件事。

流程定义就是说设计一种数据结构，来表达业务流程，通常来说最后会落地成一张有向图，文中提到的 PetriNet 相当于是一种为（侧重于审批系统）工作流优化的图结构。实际系统中，由于流程可能会非常复杂，或者说需要可视化的与业务方人员沟通，这时就涉及到了流程的建模。

这里插一句：你提到的 BPMN 就是一种标准化的流程建模语言，他定义了业内专家总结出的业务系统中的流转方式，并且有比较完善的生态：可以被一些流程引擎读取以及流程设计器。但是缺点也明显，“企业级”有时候和“复杂”是挂钩的，而且因为标准定义只包含了业内共识的部分，各家会给自家的 BPMN 方言加大量的私货。

流程执行就是核心功能了，简单的说就是读进流程定义，创建流程的实例（用来持久化流程相关的用户数据和状态），根据流程和实例的状态来执行流程。

认同这两点，结合业务，从头设计一套针对需求的工作流系统并不难，比如 hooopo 提过他那边业务类似电商，流程简单用状态机糊一个就行了，知人曾经魔改的 Netflix/Workflowable 。

至于 SaaS，之前看过 Kissflow，还不错，纯收费的，国内用可能不太接地气。

至于开源项目，工作流是 Java 和 C# 的传统阵地，比如 jBPM 和衍生出来的 Activiti、Flowable。jBPM 和他衍生品的特点是他自身就是一套完整的服务，并且暴露 Restful API，所以你可以把他们作为核心，然后外围构建自己的系统。

缺点很明显了，因为是独立的服务，跟业务系统的数据上的交互和同步会非常难做，数据出了问题对于审批系统，后果挺严重的。

我对审批系统的理解是由三部分组成：表单、权限、流程。你直接看 jBPM 的组件图，大致也是 流程、表单、用户和权限 基本跟我的理解是一致的。

所以这就是我做了一系列轮子的动机，有了这些轮子，就可以直接做在一个系统里了，同时通过组件化的方式明确边界。

最后说工作流在 Ruby 和 Rails 上的生态，我也在一直调研，可能我做的这套轮子是整个 Rails 社区独家，而且除了 WorkflowCore 其他组件都被一些团队（商业产品）验证过了，WorkflowCore 算是我个人对这个领域的总结，如正文所说，还是比较早期，我因为不在做这个领域了所以要暂时放下，但是思路上是没问题的。

你可以参考我上边提到的一些项目，也可以了解 WorkflowCore 原理后复制他示例的代码来构建你的系统，我个人经验看，Rails 做这个比 Java 那些开发效率要高很多，写起来也容易。

PS: 我记得13年读大四的时候，帮同学看过他的毕设，他正好是实习做 HIS 系统，基于 Rails 2.1

其实技术会议主要还是社交的，技术分享只是个幌子（不然怎么把这帮死宅骗到一起来

开在美国的会就没便宜的...默默看推...

更新了一下性能测试，随便抄了个 fib 的代码，跑了求第100项，3ms 可以的，比我原文中描述的快了非常多，可能是 mruby 1.4.1 带来的，我原始的实验好像还是在1.3上