那么，新手转什么开发找工作容易？

负责说“这个实现不了”

估计是运行环境的问题，例如磁盘性能差。

不维护了，建议用 docker，我晚上再清理代码。

ActionCable

24 小时手机通，外出带笔记本。

缺了必须的页面反馈，用户不知道怎么用，这就是个 bug。

到这里提 issues https://github.com/ruby-china/ruby-china-android

描述问题和截图。

#4 楼 @zouyu 是

在 console 执行一下看日志。

#19 楼 @danielglh 我还想追踪一下这个说法是怎么来的，我这用 Google 搜，英文前几篇都是否定或质疑的，但是中文搜就很多肯定的。初学者如果只看二三手中文资料，会被误导。

#11 楼 @danielglh 是我误会了，不过我希望不要把这个原则当作社区共识，社区不是一个个体，我就一直不太认同这个原则。

后面 business logic 模块化我赞同。

#23 楼 @wildchilderic 不一定。

首先，客户端性能不是可忽视的，特别是移动端。https://medium.com/dev-channel/javascript-start-up-performance-69200f43b201#.5o2nxx2gw

其次 从 HTML 页面转 JSON API 不一定能降低服务器负担。像 Ruby China 的 API 优化得没有 Web 好，你可以调试顶楼的 demo，首页 Web 一个 30 毫秒请求，换成 API 需要两个 80 毫秒请求，服务器负担变大了。即使优化很好我觉得差别也不会大，因为数据库耗时是一定的，渲染部分都缓存住。

React 推广之初，性能是一大卖点，最有名的是 dbmon 的测试（https://www.youtube.com/watch?v=z5e7kWSHWTg），凭此测试让 React 引起了广泛关注。不过接着就被发现之前 Angular 的测试版本写错了（http://blog.500tech.com/is-reactjs-fast/），实际上 Angular 和 React 不相上下。用来做性能评比的是一个很极端的例子——一个高频刷新的表格，并且每个单元格都有自己的逻辑（弹出框）。如果要做一个股票交易工具也许很适合，不过一般的 Web 应用不需要这么高频刷新。

但是信息传播很容易走样，“高频刷新下 React 性能很好”经过传播后就只剩下了“React 性能很好”。接着，遇到服务端渲染慢的时候就会想，用 React 重写前端是不是更好。有的团队真的这样做了，花了几个月前后端分离，用 React 重写前端，结果还更慢了。接着为了渲染速度和 SEO 又去做 React 的服务端渲染……

我早前也有疑问，用 JavaScript 渲染页面真的比浏览器直接替换 body 快吗？如果说 Virtual DOM 可以减少绘制提高性能，那么 JavaScript 本身的计算消耗如何呢？但是很少有团队会把一个产品用服务端渲染实现一次，再用客户端渲染实现一次，一直到了最近有人利用 Ruby China API 重写前端，我才有机会做一个公平测试。

数据表明，对于整页替换的网站，前端渲染没有性能优势。所以如果你做的项目比较像一个网站，那么大可不必用前端渲染，从性能和 SEO 角度来看服务端渲染更好。对于大多数网站来说，以 Rails MVC 为主，少量 JavaScript 做调料，复杂组件用前端渲染，是最简单高效的。

我的意思不是说前端渲染无用，让大家不要学，前端渲染有它适用的地方，应该更多从功能上判断。如果你的网站有很多客户端状态，有很多拖拽、弹层、动画效果，需要提供离线功能，或者其他不适合用服务端处理的地方，那么就应该考虑前端渲染。

“Fat Model, Thin Controller”我一直没找到 Rails 官方资料或者核心开发的分享有推荐这个准则，为什么说是 Rails 的指导呢？

相反我找到一篇 DHH 的文章指出不要为了代码重用而把代码都塞进 Model http://david.heinemeierhansson.com/2012/emails-are-views.html

我觉得逐条转换没问题，不过 update! 用错了，每次调用都会保存一次数据库。

CoffeeScript 默认用闭包包裹，assets pipeline require 可以处理依赖。

https://cloud.google.com/datalab/

如果只是顶楼的三个需求，在管理后台自己加个图就好了 http://www.chartjs.org/

甚至不需要可视化，输出表格。

Kibana 可以随着运营人员的需求变更灵活调整。

Elastic 全家桶 https://www.elastic.co/products/kibana

#8 楼 @luft 之前没看过这个工具，看了几节文档。

我赞同副标题的内容“book is a program”，书有源码、编译、发布，跟程序差不多。不过这个工具跟 latex 的问题一样：难用。我是不知道怎么向一般作者介绍这个工具，写作之前要学习这套 Lisp 系 DSL，门槛太高。

在我构想中，制作一本书的可以分开三个环节。

1. 作者写作，这个过程作者只需要考虑内容，不需要考虑样式和构建。工具可以是标记语言，或者其他标准化文档的编辑器。
2. 制作样式，这个过程由技术或设计师进行，工具是 HTML/CSS/JavaScript。
3. 构建发布，这个过程是自动化进行，把内容和样式编译成各种格式。可以是命令行工具，也可以是 SaaS。

所以在我看来现在最接近理想的工具是 GitBook。

#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 耦合。