这两个设计思维不一样，看你喜欢哪种：

passenger - 系统守护进程，背后默默搞定很多事，只要把应用路径配置好就行。
puma - 需要自己了解进程管理、信号机制等等。

我现在用的是 puma，因为是 Rails 默认。

我是 Ruby 前端工程师～

建议用 cap 不要用 mina，mina 处理方式太粗暴（合成一个脚本无法回滚），不支持多机部署，有明显缺陷。

14.04 太老了，还有不到一年就停止维护。换 18.04 看看？

好像没收到，再发这个邮箱试试（编辑掉）

这说不准，公司项目和团队很多，需要的能力不一样，不试一下是不知道的。

来吧简历🤙

同一个公司的招聘贴本来也要合并。😂

我所在的公共技术部通讯组也招 Ruby，想投公共技术方向的可以投给 michael.ji#dji.com

工作内容：开发维护 DJI Go App 的后台服务。

待遇：与顶楼内容一致。

就用 GitHub 协作挺好的。

开多个 redis 实例储存不同持久化需求的数据。

find_each

奥，我还没试过删数据有没有问题。

这篇文字语言粗俗，满篇牢骚，毫无营养，几年后再看自己写的东西会很羞愧吧。

Ruby 语法一样有很多被人不屑的地方，例如有人单纯因为不喜欢 end，不喜欢 @ 就把 Ruby 整个否定的。这样就错过了 Ruby 的 DSL，元编程，Rails。只关注缺点不关注优点会错过很多东西，何况缺点通常是微不足道的。每个存在的语言都有可取之处，工作不得不用却不去发现它的优点那损失的是你自己。

还缺了狗。

矫枉过正了，一个白人都没有。

首先感谢楼主的分享，这对需要这样做的人很有参考价值。

但是我要反对这种做法，可以看到，转 React SSR 的需求不是用户体验要求，也不是产品功能要求，而仅仅是需求方的任性，而需要的 SEO 的网站就不适合前端渲染。万一哪天他们要求用深度学习和区块链来做网站呢？

改回去是不可能改回去的，这辈子都不可能改回去的。设计又不会做，就是用 Bootstrap 才能维持得了样式这样子。

如果没有自己云储存的适配器就自己写一个。

Oracle 😏

能做个分享就好了。很多人喜欢分享新技术，但很少人分享新技术有什么问题，而我觉得这一样有价值。

HTML 原生特性

我是 Ruby 和 Rails 各半。

https://bearmetal.eu/theden/how-do-i-know-whether-my-rails-app-is-thread-safe-or-not/

根据现在流行的 devops 理念，不应该区分生产数据库和测试数据库，在生产环境跑测试也应该针对的是生产数据库，不知道大家有什么看法？

谁说的……

http://chloerei.com/2013/11/22/you-do-not-need-these-gems/

json 序列化并不是个大问题，除非有查询需要，不喜欢并不是换数据库的充分理由。

应该是文档错了，相对地址会加上 /assets 前缀。

文档地址是？

有安全隐患，楼主想用就用吧。

暴涨：财务自由

暴跌：最高点抛出，财务自由

立于不败之地。