我册～真的是用生命在连载！神人！佩服！

其实我觉得在国内的福报资本面前这个才是最重要的原因。

能靠堆人和加班就能解决问题的时候，需要谈技术的生产力吗？

我相信有很多低调的牛人能一个人就把中小型项目从 ui/ux 设计一直到线上部署运维都搞定，问题是不是流水线作业，可插拔性不强啊。

老板一想，唉？不行啊！我不能被写代码的牵着鼻子走啊！必须给我来一套可插拔性强的架构！Java 可插拔性强不强？前后端分离呢？强的不要不要的好吧。人又多，又不用担心替补队员不够用。

功夫到家的情况下，用 Rails 可以一个人跟隔壁一个组叫板！问题是能力太强老板会担心的呀～

PS: 路过的老板别打我，我只是说某些老板。。。

据说 90% 的都在吃土，哈哈～

在我查考的资料中基本都有提到，对于 upwork 上的新人把评测成绩做好是非常重要的，就是平台方会根据你提交的技能特长出一些测试题给你打分。

老哥你够狠，电视机都拆！要在我家里，早被打断腿！

大部分的 SPA 应用可以翻译成 stupid application，除了增加整体工作量和复杂度，根本没起到什么积极的作用，本质上还是全栈不好找，那就大家加班搞分离好了，还是 turbolinks 来的直接高效。

商务人员拿下一个大单子，老板一看不错不错，又给公司挣钱了。程序员费劲巴力做优化也许节省了十分之一的成本，但不是直接收益，老板看不到呀！咱们还是调整好自己的心态吧。

就像最近去面试，技术面都过了，薪资谈不拢，因为人家觉得程序员不值那些钱，只增加了成本，你说能有啥办法嘞～

@Rei 我的回帖又被人拿来灌水了。。。

怎么感觉应该是设计产品那个人的锅，让 Ruby 背有点不太合适吧。

@huobazi 是不是可以用 reset_session

https://guides.rubyonrails.org/action_controller_overview.html#accessing-the-session，文档里最后一句有写

To reset the entire session, use reset_session.

谢谢大佬们，已经从项目中移除掉了，使用 http.rb 还有自己封装的一些类简单实现了一下 non activerecord model

@Rei 发现疑似博彩网站灌水者@lesliehuang

我觉得写 Ruby 至少要能开启两种模式，自嗨模式和让她 (他) 嗨模式。哈哈哈哈～

哈哈哈～ 看源码 +1

针对这位兄弟的观点聊一下自己粗鄙的看法：

rails 学习曲线明显抖很多 不好上手 把官方的教程走一遍还是迷迷糊糊的 要反复的看文档才能搞清楚之间的关系 反观 Python 的 Web 框架 跟着走一遍基本上就能依葫芦画瓢了「直接拦住了很大部分想要学的人 本来想学的人就少 直接变更少」

我的感觉是 Rails 其实并不适合对 web 开发一点基础没有的人来学，从前端到后端，乃至数据库及运维的知识都要有一个宏观性的了解，在这基础上再学 Rails 感觉会好不少，我是先接触的 flask，简单清晰，然后又接触的 django，回想当初学 django 的时候感觉也迷糊，本质原因还是当时对该了解的理论知识没有了解透彻。所以武断地讲，无论哪种语言的全栈框架都不是为一点基础没有的初学者准备的。

用的人数少导致有些问题去谷歌搜 搜不到，讨论的也不多，而 python 的 web 框架基本上遇到问题都能找到答案

个人的体会是，在使用 Rails 过程中碰到的比较棘手的问题都是靠看源码解决，对自己来说这到是个好事情。

啊！你好啊老乡！我的邮箱是 [email protected]

大东北吉林长春～

辛苦了

我在一个 3.5 线城市强行安利团队小伙伴上了 Rails，现在正在干的项目是用 Java 做 API 服务，剩下的全放在 Rails 里。我敢说我在的这个城市用 Rails 的公司应该不超过 3 家，希望为 Rails 的使用率做点小贡献。。。

嗯，已经决定在新项目中用 webpacker 了，只是觉得 sprockets 挺可惜的，很优秀的工具而且 4 做了改进，但还是败给了前端生态圈。。。

其实从 DHH 的观点来看，我觉得他更多是一种迫于无奈的妥协，要不然也不会坚持用 sprockets 处理 js 以外静态资源的观点。其实从 js 打包工具来看，我倒觉得 rollup 是更好的选择，但为了兼顾前后分离的方案，又没有比 webpack 更成熟的选择，估计这老哥心里也挺憋屈。。。

关于 webpacker 和 sprokets 的取舍需要请教一下前辈。

面对前端开发组件化开发的逐渐普及和 sprockets 可能被抛弃的问题，那是不是应在不依赖陈旧的前端 gem 包的项目中尽量拥抱 webpacker 呢？

在 webpacker 的 readme 中，开头有这么两段话，让小弟有点犹豫。

1. Webpacker makes it easy to use the JavaScript pre-processor and bundler webpack 4.x.x+ to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets).

2. However, it is possible to use Webpacker for CSS, images and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.

对这两段话我理解是在非组件化场景下对于 css 还有图片、字体之类的资源还是建议用 sprockets 来管理，对于组件化场景下才建议使用 webpacker 来管理。

在 github 上 DHH 和一些开发者之间关于 webpacker 和 sprockets 取舍的讨论 https://github.com/rails/rails/pull/33079

看完之后又觉得疑惑不少，正反双方说的都很有道理。个人感觉现在项目目录下又是 assets 又是 javascript，还可以在 javascript 里放 css 和图片之类的，虽然可以把 javascript 目录名改成 frontend，但总感觉和 assets 并存又有点不伦不类的，资源管理不太统一，所以，还请有时间的前辈们指点一二，对于 webpacker 和 sprockets 的选择上，现阶段是否有必要像 webpacker 中 readme 以及 DHH 建议的那样，或者直接全面拥抱 webpaker 呢？

Ruby China 相关帖子 https://ruby-china.org/topics/38832 (@lyfi2003 作者大大要不要也聊聊观点)

其他相关链接：

Choosing Sprockets or Webpacker

https://github.com/reactjs/react-rails/issues/813

Rails 5.2+: why still use assets pipeline with webpacker?

(ps one: 我已经有点彻底懵逼了，如果问题太过幼稚，请忽略。谢谢！)

(ps two: hackernews 上有人也提了一个类似的问题，不过遗憾的是没有人回答。。。https://news.ycombinator.com/item?id=18226741)

Umm。。。每次在 eclipse 里找各种按钮各种点一遍，controller 里写一堆 url，想直接返回个 executable javascript 我还得各种尝试，想死的心都有（别误会，没有贬低 java 程序员的意思，我只是说一下自己作为一个 java 小白的直观感受）。

如果是自己的项目，果断 Rails，能让我快速实现自己的想法而不至于陷入一些无关紧要的技术细节，即使周围的人都在学 java 用 spring，我还是坚持 Ruby，Rails。

我的那个博客部署上以后好长时间都忘了还有它的存在。。。

不客气~

我用的是最便宜的，一个月是 5 美元，如果用里面的数据库托管或者备份托管什么的还得额外付费。 这个是价格表 https://www.digitalocean.com/pricing

在社区前辈的指导下租了 DigitalOcean 的服务器。

谢谢大兄弟~

弱弱地说一下，其实我深挖的方向是 web 前端。。。挖了这些年有点挖厌倦了，毕竟前端能够创造出的价值非常有限。