看日志已经过了 fetch 这步,到了 building。
会不会内存不够用了……
看了一下是有些问题呢,也许 discourse 觉得他们的场景 A 超时处理,B 把锁抢过来也没问题,严肃的场景就不能这么搞了。
可以看看 https://github.com/ClosureTree/with_advisory_lock ,用数据库的锁。
如果对标最简单的部署方式,Rails 也就是在命令行跑 bin/rails server -d -e production
而已。
Good job 👍
如果是画作真是厉害,可以发布一些草稿吗?
看了 Numbered Parameters 的例子感觉可读性更差了,我不打算用,不反对别人用,只要不需要我维护。
It depends...
以前就有免费的个人版,之后取消了,现在又回来。
团队版用来协作过一段时间,并不是很好用,功能多,但是单个功能拎出来比不上专注于此的服务。
不过我一直建议弄个免费版当作研究 Rails,Basecamp 有时可以看到某个 Rails 组件为什么要这么设计,效果如何。
常用就加,不常用就等等看。
这里要求文明用语,给个时间你自己编辑。
这是 Rails 自己推的协议,关云服务商什么事?
另外 Ruby 的多线程已经可以在 I/O 阻塞的时候,切到另一线程执行,增加 CPU 利用率和提高并发量。
Threads (in Ruby): Enough Already https://yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/ 这篇文章写在 2010 年,里面提到的一些问题已经解决很久了。
未来的 Guilds 希望可以增加单进程利用多核 CPU 的能力。
node.js 整个运行环境是基于事件驱动的,内部不断的执行事件循环,回调是异步执行的。
Ruby 的基本环境是顺序执行,除非显式的调用线程/进程和未来的 guilds。ActiveSupport 只是提供一种回调语法,本身还是顺序执行。
要像 node.js 那样实现基于事件驱动的异步,可以看 https://github.com/eventmachine/eventmachine ,并且所有用到的库都需要基于事件模型(在 Ruby 世界不流行)。
事件驱动对于重 I/O 的场景很适用,例如 nginx,代理服务器大部分工作是转发请求,适合用事件驱动。如果重 CPU 的场景使用事件驱动,可能上下文切换的支出反而导致效率降低。
本来我是忠实的 Rails default stack 推崇者,最近两个组件 ActiveStorage 和 ActionText 我觉得还是学习它的设计好了,用不用看情况……
Ruby China 不允许这类不友好的发言,自己编辑吧。
关键在最后一行,没截到。
你指 python2 还是 python3?
因为早期 Ruby 资料都是日文,不便于传播。
测了一下 AR 自带的也是把 attributes 改成 string。
最好当作 feature,看看用了 enum 以后业务代码需要处理原始值是否合理。
巴士系数
推荐原因是亚飞为了解决远程面试专门开发了个网站😂 https://ruby-china.org/topics/38926
看了这个列表,前几个是服务(收费),后面就是一些库,Rails 都有(Gem or Engine)。不明白“这样的组件生态才是正确方向”是什么意思,如果说是做个页面把一些关键的库列出来,Ruby & Rails 早就有了 https://www.ruby-toolbox.com/
又或者你觉得 Rails 应该官方实现更多的库,一直以来 Rails 被抱怨的不是做得太多吗?除了一些核心必要的组件,更多组件应该由社区提供,这样更适应需求也更健康。
用 webpacker 要同时了解 webpack 本身的配置和 webpacker 的默认配置,目前资料较少,需要大家一起踩坑总结。
package.json
里面这行:
"main": "dist/js/bootstrap.js"
拆成 sidekiq 任务,task 只负责入队