#3 楼 @markluo 复杂情况用 clock process，更好的调度和扩展，不用 crontab。

1. crontab 手写不难，whenever 可以减少重复代码，但不是必须，web 更没必要。
2. 如果只是需要载入 rails 环境并执行脚本，rails runner 比 task 合适。
3. 如果需要经常修改运行时间，提供 web 界面，推荐 clock process 模式，例如 sidekiq-cron。

#7 楼 @kai209209 coffee 支持 import export，但是不解析模块，需要再加一个 babel 之类的编译器。

ES6 在浏览器环境算不上原生。

#16 楼 @u1452261116 我觉得是的，不确定有没有其他方法。

密钥暴露到客户端是有问题的，被别人盗用作恶被禁用的时候连带自己的应用也被禁用。

mock 是单元测试用的吧，应该放在客户端的测试代码里，怎么会让后端解析 mock 规则呢？

如果是为了开发联调，应该部署一个全功能的 test 环境。

如果一定要用 mock 模拟服务端，让他们自己搭。

热闹驱动开发 http://www.luanxiang.org/blog/archives/2291.html

#5 楼 @lulalala

Asciidoctor PDF

使用 Prawn 绘制 PDF，Prawn 不支持 CJK 文字环绕和 OTF 字体，需要打断字补丁，字体选择很少，样式设置很不方便。

以前处理的问题汇总在这里 https://github.com/asciidoctor/asciidoctor-pdf/issues/82

不过修了一个 bug 又引出新的 bug（https://github.com/chloerei/asciidoctor-pdf-cjk/pull/3），我不想再在这个方向投入。

我打算用 http://wkhtmltopdf.org/ 生成 PDF，借助 webkit，使用者可以基于 HTML/CSS 设置样式，字体也可以使用任意系统字体。

Asciidoctor EPUB3

这个包基本可用，就是有些小问题，但问题虽小却不好修。另外也是难于定制样式。

Asciidoctor 本身

代码很复杂，我想加个 rouge 代码高亮都无从下手，理解 Asciidoctor 的内部数据结构不如 HTML 方便。

综合这些问题，我觉得用 HTMLBook 作为中间格式会更好处理，不跟 Asciidoctor 耦合。

多谢楼主的工作，我终于可以拿两个几乎一样的页面比较 Turbolinks 和前端渲染的速度。

首屏速度（主题列表）

Turbolinks

React

分析

减去空白时间，Turbolinks 耗时 281ms，React 耗时 474ms，Turbolinks 是 React 的 59%，前者大幅领先。

换页速度（从主题列表进入主题页）

Turbolinks

React

分析

减去空白时间，Turbolinks 耗时 219ms，React 耗时 251ms，Turbolinks 是 React 的 87%，前者小幅领先。

总结

渲染同样的页面，Turbolinks 总是比 React 实现的快。数据不说谎，认为客户端渲染比较快的，要不是错觉，要不是只关注服务端耗时忽略总体耗时。要注意的是，这次评比 React 实现是访问 Ruby China 的 API，服务端响应更快数据量更小，但内容展现到用户面前的时间，还是服务端渲染耗时更少。

事实上，这也不是完全对等的对比，我相信还有很多功能 React 版本是没实现的，我特意用未登录状态测试，避免受影响。同为 js 打包成一个包，Turbolinks 执行 js 的时间更少，秘诀是把 AJAX 响应逻辑隐藏在服务端，只有调用的时候才需要浏览器解析；客户端渲染则在初始化时就解析了这些逻辑，因而花在 js 的时间更多。功能越多，客户端方案会越重。

除了速度外客户端渲染还有一个问题，就是内容闪烁。从主题列表进入主题页的时候，虽然页面框架保留，但是需要等待 api 数据，造成一小段时间内内容部分空白，给用户的感受就是内容闪烁。当然，可以用一些动画效果优化更新方式，不过在网络本身足够快的时候显得有些多余。而 Turbolinks 则是整页替换，网络理想的情况下给用户的感觉是切换瞬间完成，体验更好。

我理解为什么现在客户端渲染方案大行其道，根源还是前后端开发者间的语言差异。在传统 Web 开发中，前端是整体项目的附属品，前端的每次修改都需要服务端配合，服务端可能是 Java，.net，PHP 模版，框架也缺乏对前端代码管理的支持，前端改起来很吃力，于是 JavaScript 前端琢磨出了不需要服务端配合的纯 JavaScript 前端方案。在大公司环境下，分工不同、各司其职的思想下，前后端分离很合适部门划分。很多时候架构设计不是出于技术考虑，而是在适应人员结构。

但是 Rails 提倡的是另一种思路，Rails 项目是高内聚的，各个开发者之间没有明确的界限，前端应该了解后端，后端也应该了解前端，重视整合系统，这样可以从项目整体作出最优判断。Rails 项目和别的项目集成又可以实现低耦合，通过 api 和消息队列和别的项目进行通信，别的项目用 Rails、PHP、Node.js 都不成问题。

最后，我希望 Rails 开发者不要放弃钻研前端，把 Web 项目甜美的部分拱手让出，Rails 本身已经不仅是 Ruby 框架，也依赖 Node.js。对于 Web 项目来说，能到达用户为人所用，解决用户的问题，提供好的体验才是一个好的项目。另外也希望参与 Rails 项目的 JavaScript 前端多了解 Rails，Rails 对前端提供了良好支持——虽然跟 JavaScript 的主流不太一样。但顶尖的 JavaScript 程序员也在向 Ruby 社区取经，举个最近的例子，Facebook 的 Yarn 就是借鉴 Ruby 的 Bundler。了解 Rails 会让你成为更好的前端。

PS：上面的文字并不是针对楼主，楼主做的工作是有意义的，继续加油！

PS：有点难

我猜需要先安装字体到这些目录 https://github.com/metaskills/pdf-writer/blob/7f5bc6c9ce69c26574bbfde36ebdb9ecf06709d0/lib/pdf/writer.rb#L111

指定日文字体，我在这个库的源码里看到有 demo。

#21 楼 @sefier 楼主问 csrf，那么 web app 和 mobile app 都有可能啊，所以我问楼主有没有用 cookie 验证，因为 web app 可用也不用 cookie。是你先入为主。

补充：Ruby China 的安卓 APP 基于 turbolinks 实现，其实是 webview，需要防 csrf。

#19 楼 @sefier https://en.m.wikipedia.org/wiki/App

App, apps or APP may refer to:

• Mobile app, software designed to run on smartphones and other mobile devices
• Application software that causes a computer to perform tasks for computer users
• Web application or web app, software designed to run inside a web browser

#16 楼 @sefier 技术讨论干嘛搞得像批斗会一样，最后一段话对解决问题没有帮助，提问者不就是因为不懂所以提问。如果你知道问题所在，可以提供参考资料。

现在前后端分离这么流行，也许楼主说的 APP 就是网页前端，放在同一域名，通过 cookie 验证，这样就需要防 csrf。

#2 楼 @timlen 你不能只是把 Turbolinks 加上，还要看它的文档，不然就会遇到各种问题。

我觉得电商网站挺有必要实现这套，随时会新增运营人员但限定不同权限。

核心需求我通常会自己实现。

Ajax 操作之后用 history.replaceState 更新历史记录。 RubyChina 用 Turbolinks 已经自动处理了。

https://ruby-china.org/topics/31858

哦，发现楼主已经回帖了。

我还不是很清楚你的场景，多个应用是多个网站还是多个移动应用，以后会不会扩展？需要多站点免登陆还是相同账号密码登陆还是授权验证？

多系统共用的账号系统要优先选用通用的协议，不要从零开始。

#8 楼 @pengedy 什么叫政治正确？看了你几个帖子都在胡说八道。

SSO：用户一次登陆后在多个系统免登录。
OAuth：用户授权第三方应用访问自己的资源无需提供账号密码。

场景不同选择不同。

#7 楼 @xiaobai2 access_token 放参数或者头部

#3 楼 @ghn645568344 给个攻击例子？不明白被抓取是什么意思。

rvm use --default 2.2.0

CSRF 利用的 cookies 验证进行未授权访问，不用 cookies 作为验证就没问题（大概）

我还是相信 crontab

创业公司也有很多类型，不同规模。