rvm use 2.5.3 这样我没遇到过问题,只要 ruby 装对了
我知道的坑一个是安装前导入 rvm 的证书,另一个就是你主帖里描述的 你安装完之后关掉终端重新开 rvm 应该就正常了,然后再安装 ruby
另外看你截图 ubuntu 版本不是比较新的,如果学习没特殊需要的话上 18.04 吧,16.04 也还可以用,再老会发生什么就不好说了
terminal 设置里把那个用登录 shell 的选项打开
不给咱们那个表单项目加上吗
对呀~~ 所以后来的几个轮子的标题就是“SaaS 快速开发套件”
还差界面和部署
我有一个试验用的项目是需要租户的部分显式调 with_tenant(tenant)
scope,控制器层的做法一样,写起来麻烦一些。
default_scope
就怕有的 gem 比如软删除,会覆盖 default_scope
的行为,出现泄露很难调试
动态表单的数据库定义这块应该做法没太大差异,这块创新的空间感觉不大。
FormCore 主要集中在改善动态表单的开发体验上,没看视频,讲稿中对数据验证、嵌套表单(我觉得这个是一个比较麻烦的部分)似乎没涉及到
另外金数据使用 MongoDB,在存储上优势很大,不过持久化和索引也是个大话题
BTW:话说我看到有人 fork 了 FormCore 把 backend 改成 MongoDB,金数据要不要试试
只扫了眼图,感觉是通过数据库中间件或者是做在数据库层面上了,现在多租户有多数据库、数据库的内建做租户功能、应用层隔离。应用层隔离的轮子间也有实现差异。金数据这套应该是应用层面的多租户,可控性最好,缺点就是涉及数据库相关的操作代码要写对,不然会发生泄漏。其他层面的方案都有坑,太底层了解决起来麻烦
我在想如果搞一个关于 Ruby 或者 Rails 的 AMA(Ask Me Anything)会不会有帮助?主要旨在了解使用者的问题
试试 class ::Spec
注意用 ::
指定下顶层
恰恰相反 Ruby 只有引用类型
感觉这位楼主 2016 年和 2018 年不是一个人
另外我在设计这个模式的时候,研究过 Rails 4 - 5 的 ActiveModel 的演进,预判 ActiveRecord 会把更多的功能移动到 AM 中去,果不其然,最关键的显式声明字段 DSL attribute
和储存字段的 AttributeSet
都挪到了 AM 中,也就是说,Rails 6 发布后,DuckRecord 就完成历史使命了,当然我准备到时候做一套 AM 的扩展来加入嵌套模型的支持
ActiveType 可以,理论上可以移植到 DuckRecord,我没做这个主要俩原因,首先是懒,其次是其实我没想通这样做的场景,比如 ActiveType 文档里演示的注册表单的情况(SignUp 虚拟模型继承 User 模型),我来做的话,直接面对业务的部分我更倾向显式声明字段,这样维护性才高。
至于命名啥的,我觉得靠命名规范可以解决,Rails 本身就是这样做的嘛。
虚拟模型这个手法是基于 Rails 有 ActiveModel 这个公共接口,所以如果你有这方面需要可以直接用 ActiveType,不影响这套设计模式的应用
其实 duck_record 支持和真实模型的关联,比如有一个真实模型 Post
,建立关联可以这样
class VirtualPost < DuckRecord::Base
attribute :post_id, :integer
belongs_to :post
end
应该就可以了,不过我后来反思过,虚拟模型和真实模型的关联可能会有很多边界情况,所以我在 FormCore 的例子里把所有这种写法都改写掉了,在 Presenter
层根据虚拟模型里的字段值去做查询获取真实模型的数据
比如附件字段的 [AttachmentFieldPresenter](https://github.com/rails-engine/form_core/blob/master/test/dummy/app/presenters/fields/attachment_field_presenter.rb 这里我嫁接的 ActiveStorage
因为我跟中国 Py 社区的组织者(们)认识啊
你说 foo *[1, 2, 3]
?
这些年的语言,都在避免 ++
--
,比如 Swift、Rust,Go 虽然有,但是也有人提议在 Go 2 删掉,用 var += 1
写法代替,当然不同意的人也有很多
如果禁用 AP 并且不用 Webpacker 或者其他关联前端工具链的方案的话,你就只能把编译好前端资源放到 public 目录下了,这个就是 Rails 3.1 前的做法,目前 Redmine 这些上古项目也还是这么用(貌似)
趋势吧,不过 docker 镜像的作者要正确制作好
Heroku 貌似被墙,RubyChina 的服务器 UCloud 赞助的,在其上用 Docker 部署
那您考虑与时俱进下吧...
如果 State 不依赖 React 简直完美,那作者对富文本编辑的现状思考很多啊
跟 @hooopo 研究表单数据存储的时候,第一条优化这个
都 8012 年了... 咱就忘了 win7 吧...
内存需求肯定少多了,计算性能没做过对比但应该半斤八两,WSL 的 IO 性能会差些,没关注后来改进没有
哦,微软在 Win 上实现了一个东西来支持 Linux 的 syscalls,也就是说让 win 能理解 x86 的 elf 格式,差别在于,静室实现的方式(规避 GPL 的法律问题)不可能 100% 复制 Linux 内核行为,但这都 8102 年了... 绝大多数流行程序都被社区检验过兼容性,包括 docker 好像都支持了。但是 cuda 这种涉及内核扩展的不行。
你说什么原生支持
他这个 precompile 还会先启动 sprockets 这个耗时还是挺久的