你截图来看看，referrer 是给服务器看得，正常来说跟浏览器无关

没懂 兼容浏览器跟 referrer 有啥关系

username: <%= ENV["APPNAME_DATABASE_USER"] %> 其他的同

对于鼓吹前后端分离的人，我一般会问他后端渲染有什么好处和前后端分离有什么坏处，当然我自己也会思考前后端分离有什么好处。

目前为止，我主观上倾向后端渲染还是适合大部分场景，但也看到了很多前后端分离的好处，可接触过的追求前后端分离的人绝大部分回答不了我的问题。

偷懒的话直接搞个 Job 模型，记 User total_count processed_count 然后导入数据的时候，导入几条就更新下，然后前端 API 定期轮寻就好了

这种的话，你如果想做的完善很麻烦，一种方法是 ActionCable 或者类似的长连接方案，后台插入数据到一定数量的时候就往前台推一下进度（其实就是已导入数量和总量）

没有 ActionCable 的话，就是做个 API，然后想办法记一下导入的状态，然后前端定期轮训

或者最粗暴的，弄个假进度嘛... 布朗运动往前走

主要是能作为一个职业的，Ruby 目前局限于 Web 开发了，而 Rails 又是最好的 Web 框架。

要说 Ruby 的应用确实很广泛，但是其他的能支撑起一个职业的，就没有什么了

可以试着参与下 discourse 那些开源项目吧，其实可以搞得容易的地方挺多的，而且时髦值也高

Facebook、Microsoft、Amazon、Google 曾经是 FLAG 但是 L 歇菜了，所以。。。

能干什么事情跟语言没关系，是有人写轮子，没有 Rails 那 Ruby 还是能写 Web，只是不会有太多人去用的 Ruby 写 Web 了

可以看看 https://github.com/jasl-lab/form_core 的 dummy 能做到的效果，我发现还有很多点可以去总结的。

另外我昨天还跟同事感慨，现在分享 Rails 使用技巧的帖子越来越少了，我自己也在想，这么多年来我自己独创的技巧估计都有不少了，但是我主观上有惰性去总结成帖子，因为感觉这些别人不知道其实也没啥影响，但是模式是能够带来巨大生产力差距的，值得去推广

小而美最后也是要变成巨无霸的，我个人经验认为 Rails 支撑大型项目没有问题

虽然看业务逻辑上语言的优势可以忽略不计，但是为了支撑表达业务逻辑，不同的语言、技术带来的生产力差异是非常大的。

比如 ORM 领域，ActiveRecord 可以称为地表最强。

.Net 的 Entity Framework 可以说一般场景下不输 AR，因为 EF 有地表最强 IDE VS 提供工具支持去方便的生成模型的代码，并且在 C# 的 partial class 的支持下，可以对开发者隐藏掉这些生成出来的代码，让代码组织更干爽，在 C# Linq 的支持下允许写出类似 AR 的链式查询或者用类 sql 的 DSL 去查询，灵活性甚至胜了 AR 一筹。

但是 Java 的 Hibernate 呢？手动声明字段，Migration 不管，Getter、Setter 自己搞，甚至还得学个 HQL。

为啥 ActiveRecord 只在 Ruby 上有，其他语言抄不走？因为 Ruby 提供了必要的基础设施。而 ActiveRecord 已经可以称为一种 pattern 了，是 pattern 导致的开发效率的差距。

一个例子就是，我最近在公司内部、在论坛、在线下聚会都在推我写的 form_core 还有他所采用的 动态虚拟模型生成 的手法，我们都知道 AR 的模型（或者说数据结构）很容易使用，包括数据验证等等常见的需求都满足了，但是 AR 的模型只解决静态的数据结构，动态的数据结构呢？比如类似京东，不同的商品类型的商品参数是不同的且由用户去定义。这个场景很常见，比如过去我在知人，员工的档案需要 HR 定制、工作流的表单也是用户定制的，我也研究过 Redmine 任务的字段也是可以定制的，但是他们在解决这个场景上做法就很传统，Java、PHP 任何语言也都那么去做，那用 Rails 还有啥开发效率优势？但是用了我的动态虚拟模型手法就不同了，动态定义的数据结构最后转化成一个符合跟 AR 一样的模型，类似数据验证直接交给模型去处理了，不需要额外的开发工作，开发效率自然巨幅提升，而且扩展性、代码可维护性也有保障。

而这个手法也是来自当时解决工作的灵感的总结，所以我就产生了年头，如果关键业务场景的解法能总结成模式，那么生产力重新和其他语言产生代差，会不会在现有条件下（没有新的增长点）让 Rails 再热一次？

举个例子，最近我收到很多帮招人的邀请，是做数字货币的交易所，为啥。。。因为 貔貅 是世界上唯一一个开源的产品级交易所

（先声明：我现在说的都是主观观点）

我觉得 SSR 反而是拉回正轨了，JS 不是不可以一统天下，可以让 JS 接管和用户相关的工作，有微服务的加持下，后端让合适的技术解决合适的业务（Spark 做数据平台，Go 做 实时，Java 写业务系统等等），然后 JS 把这些离散的业务系统串联起来，再展示给用户，相当于现在的后端更后，让 JS 的“服务器端”做“后端的前端”（有点绕），这样产品形态（UI/UX）的变更就完全交给前端开发来完成了，按照产品的需要来组合后端提供的各种服务。

在这个模式之下，后端开发专注于实现业务，精进后端的技术栈。前端开发掌握 SSR 为了更高效的实现 UX，又避免了学习过多的传统后端的技术栈（在目前的形势下，前端即使有了 node.js，由于前端开发没有系统的受过数据库等后端技术栈的学习，实际上是给很多项目造成过负面贡献的，相信不少后端开发有这个体会）

我觉得这才是正确的道路。

Rails 的 SSR 能力非常强大，这就和 JS 的发展路线产生了冲突，目前来看 JS 或者说前端社区赢了，现在的前后端分离，Rails 的 SSR 能力等于废掉。

再看表达业务逻辑，做业务逻辑的精髓在于，精确地表达，即使是 Ruby，惯例上，也提倡不要炫技，用最朴素的代码去编写，根据我的经验，这个时候，代码量上 Ruby 不会比 Java 少多少，这就造成另一个尴尬，Java 的人好找，Go 的性能好，不如直接用他们了。

还有一个是，我相信 Rails 在企业级系统上会有很大作为，这种系统的特点是 业务复杂、对 UI 要求不高、需要配合公司管理模式长期迭代。

Rails 支撑多变的业务需求还有很大的发挥空间（我刚在公司做了这方面的分享），但是在社区层面缺乏总结。

大环境是还缺乏一些新的业务的增长点，最悲观的情况下，我个人判断 Ruby 最差会成为下一个 Lua。

写 Rails 的话其实也不用担心，起码北上深是不会愁工作的，论坛的招聘帖也集中这些城市，而且交流下来看的话是供小于求。

我个人另一个判断是现在 Web 行业处于转型期，WASM 还有 PWA 对于 Ruby 还有其他有兴趣做应用开发的语言都是新的机会，而且前端社区现在火的框架也在发展 SSR，最终可能会造成一种轮回

提个建议，banner 文字配这个背景太不明显啦

我觉得 2.6 发布应该会有类似 iPhone X 的感觉

我让前端做的，而且是显示的时候再转成元，这样就不会遇到计算钱时候遇到的坑

JS 的基本类型没有吧。。。用第三方库也不是不行，不过前端的主要目的是展示，计算结果 round(2) 可以 ok 了，基本不会出错，话说去年大会用的多会，他们就在算金额的时候出过 bug

去年猎头说面试是六轮纯英语视频面试...

另外考虑案例的话，支付宝的支付接口的金额单位是元，微信支付的是分

主要是 JS 没有 Decimal 类型，他的 Number 也是单精度浮点，用元来传递和计算（分自然就是小数了）就很容易出意外的问题，不考虑转汇的问题的话，存分，计算也用分来进行，只有在显示的时候才转换成元，是最安全的实现方式。

当然你时不时的 round 一下，也可以算是一种 workaround，绝大多数情况都可以避免计算导致的精度问题

据朋友给我说，美帝一流 CS 专业的学生都去 FMAG 了，于是苹果只能退而求其次招 EE 的，编程专业训练就不如 CS 的学生，主要是工程能力，造成苹果软件质量不如其他家

你有什么好怕的，谨慎评论自己不熟悉的东西不是最基本的么？或者你要验证自己的观点对不对，作为问题问出来，你每次遇到的尴尬就都不存在。在者，提醒你错了，你可以自己去补全知识，也可以听取正确的观点。

可现在是什么样的呢？反驳你，你就摆出一副被迫害的样子，这不是健康的交流方式

话说出来是给人看的，技术交流对就是对，错就是错，别人有没有深入了解和你说话对错没有关系。

你的规律显然也是错的，挑出你的错是为你好，证明不了我的威严。

那么你觉得你举的例子跟 JIT 有关么

我再问你个问题吧。。。什么时候 JIT 会慢...

你先等等。。。

标准 Lua 是没有 JIT 的

那个文件是给 sprockets 4 预留的时间但是鉴于 4 难产，所以没啥用了