#24 楼 @hanluner 我对微信的态度就是，有任务来了能应付就好，千万别投入太多精力，万一哪天又改了就蛋疼了。这种没下限的玩意儿，不值得……

import 在纳尼……

#20 楼 @winnie 用了风扇调节软件提高转速，大部分时间在 65 度~70 度之间，偶尔上 85（编译的时候）但是很快就能降下来，因为 TG 配置到了谋个阀值就全速……

#21 楼 @sjrong1988 原价 16 刀买的。

#22 楼 @hanluner 是呢，那几天写微信支付，花了三天才搞定，可以说微信 API 是我见过最狗屎的 API，文档各种不清楚……

#18 楼 @lips 就是因为系统默认转速太低，然后又不会根据温度及时响应，所以如果要接 4k，只能利用其它 app，我用的 TG Pro，要不然都可以煎鸡蛋了。

#16 楼 @lips 那是肯定的，外接了这个显示器，CPU 随时 80 度，所以一个风扇调节软件是必备的……

#23 楼 @southwolf 什么板子？分享下呗。

#11 楼 @ywjno 艺卓的专业显示器很贵很贵，但是你说这个型号分辨率不是 4k 的…… #12 楼 @dandananddada 楼下电信局摆摊白送的。

优派这款还有个好处就是接口丰富，支持 HDMI 2.0，所以我的 RK 3288 开发板有福了，Android 直接上 4k@60hz：

#14 楼 @046569 120 字符这样的限制，也应该与时俱进上调了吧

#13 楼 @vidon 欢迎捐助，哈哈

#7 楼 @jun1st 24 寸的 4k 效果肯定更棒，ppi 高啊，27 的有点占地方了我觉得。这个 4999，跟 p2715q 一个档次。

#4 楼 @tylerlong 跟自带的显示器类似，设置为实际只显示 1080p 就行了，超大 retina 哈哈。

#1 楼 @huacnlee 原生分辨率肯定没法看，字太小了。开 HiDPI 模式就跟内置的 retina 一样了（4 个像素点组成一个，实际上只能显示 1920*1080），效果非常棒，虽然理论 PPI 低点，但是因为距离远，很舒服。

#21 楼 @jasl 恩，打算看看工控板去，多谢分享：）

#18 楼 @jasl 多谢分享，minnowboard 也太坑爹了吧，本来觉得是 x86 架构，还 64 位，满心期待，这下直接从收藏夹删除得了。其实 cubieboard 3 就不错，做服务器的话，接口齐全，只是全志 A20 性能稍微差了点，目前就玩玩这两块 32 位板子了，继续等 64 位 ARM 发力。 至于 ITX mini 主机还是算了，ARM 的优势除了体积小，另一个就是低功耗，在家 7*24 运行还是能省不少电费的。

#16 楼 @ywjno 我都是自己玩……

我也喜欢材料设计，不过这个框架组件还是少了点，期待后续完善。

#6 楼 @ywjno 今天又测试了下，用 rvm 编译安装 ruby 2.2.2，tk1 耗时 10 分钟，firefly rk3288 耗时 15 分钟。

#12 楼 @jasl 刚搜了下，原来 cubieboard4 就是 cc a80，囧。这货性能还是干不过 tk1 的，虽然是大小核的架构，但是四个 A15 的主频只有 2.0GHz，tk1 可是 2.3GHz，后者还带 USB3.0 跟 SATA，GPU 就更不能比了。

现阶段，32 位的 SOC 开发板里面，也只有 Jetson TK1 最为强悍，还是期待 64 位的开发板尽快普及，那才是 ARM 服务器的春天。

#12 楼 @jasl cubieboard 出了新的 CC A80，基于全志 A80 八核芯片来着，但是这 SOC 不支持 SATA 和 USB 3.0，所以不太适合做 mini server。

minnowboard dual max 貌似只有 2g 内存吧，我正考虑要不要入一块，毕竟是 64 位的，能评测下吗？多谢。

现在手头还有一块 Firefly 的 rk3288 板（Cortex A17 四核 1.8Ghz，4G 内存，32G emmc），做工精致，算是国产精品了，但是同样的，没有 sata 和 usb3，但是板载了千兆网卡和 802.11 ac 双屏无线，ubuntu + android 双系统，挺好玩。

#10 楼 @hanluner Realforce 87U

#78 楼 @qhwa 多谢捧场：） 为什么我会让 Ajax 请求 redirect？请看 60 楼，有针对这个问题的解释，同时也可以参考《The Rails 4 Way》一书有关 Ajax 的章节。

#79 楼 @leopku 后续我也打算就这个话题继续深挖，但是目前真没时间，忙成狗……期待您的分享：）

#70 楼 @yan32768 根本问题不是没把脚本放 head，而是因为 Turbolinks 的机制要求你的 DOM 操作必须“幂等”。自己写脚本好办，别人（三方组件）写的就蛋疼了，所以现在要集成前端 Theme 的话，不出意外我都会被迫关闭 Turbolinks，实在是折腾不起。

#72 楼 @pzgz 握爪，抱头一起哭吧，哈哈。

#63 楼 @aptx4869 rails-assets 这条路不错，希望能逐渐完善起来，这完全是在帮 Assets Pipeline 填坑啊，哈哈。

#4 楼 @miclle 这个看起来好夸张，被动散热？我在想如果不做高负荷运算的话，大概不用散热器，有个老外说他拆了风扇，温度上升大概 2~3 度，如果是这样，可以接受。

#1 楼 @miclle 风扇是出厂就带了的，确实有点吵，我打算拆了它不知道会不会烧了板子……

#2 楼 @ywjno ARM v7 32 位的，没法比吧，这个也就 just for fun :)

#59 楼 @taojay315 那个例子是针对评论里有大大断言 Ajax 请求不可能也不应该发生 redirect to，而给出的一个简化版场景。在面临 Aja*(html,json,js) 问题的时候，根据不同的情况做出合适的选择才是明智的，比方说这个例子，采用 Ajah 可以少操许多心，比方说，修改购物车商品数量其实是连锁反应：你要更新单项小计，总价，甚至还需要应用某些促销算法（比如商品 A 买满 3 件就送 B 之类的），这种情况是不是直接重定向到 index action，充分利用服务端的能力会更好？为什么非要 render json 给客户端然后将构建 UI 的逻辑在 js 里重复一遍？退一万步，就算真这样，数据来源也是 index 提供的，那么还能觉得 redirect 是不合理的？至于返回 js 片段在里面写每个 dom 的更新操作（也就是 js.erb 那种），我只能说呵呵……

Great，不能再同意更多。有时间我也来一篇相关的，但是目前真脱不开身哈哈…… 其实要设计好 services object，很多 rails 既有的东西会成为拦路虎，比方说 filter、callback，以及大家习以为常的 CV 间采用实例变量通信。所以说默认的 Rails 风跟更高层次的架构抽象之间，是有阻抗的。

#55 楼 @rubyu2 握爪，升级的时候真的想骂人，要是没有 Kaleidoscope 这种 diff 神器，想死的心都有…… 别跟我说什么你不升级就好，劳资花钱买了 Theme，作者不断的升级，增加新功能新组件，不用简直就是脑袋进水了。 至于 services 层，肯定要自己来 DIY 了，rails 没有内置指导的，这也是对新手非常不好的地方。

#50 楼 @billy 不要把宝贵的时间都处理在这种价值很低的事情上，非常同意！所以你知道为啥我要吐槽 Assets Pipeline 了吧。不管你是 dirty hack 也好，做 gem 也好（这只是在 dirty hack 之上多费点包装的功夫，搞个 engins 而已），同样的过程都要来一遍，问题的根源不在于做不做 gem……

#47 楼 @billy 像 fontawesome 这种简单的当然很容易，搞不搞 gem 真的无所谓。很多时候，现实是残酷的，不说集成 themeforest 的模板（注意看主贴给的例子，第二张截图，assets 目录有多少三方组件，这还算是少的了），请尝试下给百度编辑器做 gem，这个我在项目里面是搞好了，但最大的问题是维护版本，只要人家一有改动，你的 gem 包也要同步的话，是非常悲剧的，特别是这种玩 hard code 资源路径的玩意儿……

脏一次手无所谓，怕的是要脏一辈子。当然如果对干这事儿情有独钟的话，我也无话可说，真爱。

其实如果 Assets Pipeline 在预编译的时候，考虑周全点的话，完全可以处理下资源的路径，自动将相对路径替换为对应的绝对路径（毕竟是可以根据源文件所在的目录来确定的，至少 css 文件可以，js 就有点蛋疼了，如果是字符串拼接，神仙也帮不了），世界会多么美好……

#43 楼 @flowerwrong 这跟 windows 有毛关系，总不能让甲方也买 mac 吧

#30 楼 @peter Assets Pipeline 集成组件的问题，并不仅限于使用 theme 才会遇到，只要你用到三方带有资源的前端 plugin，然后它又没有现成的 gem 包，都逃不开。

#31 楼 @blacktulip 不必盲人摸象，只要找到症结所在，其实问题是可以解决的，只是比较 dirty 罢了，就像我说的，怕的是以后升级又要再来一次，而版本升级肯定是注定的。

#40 楼 @springwq 可以，改天另写一篇专门介绍这个，大体的流程其实就是这样了，说实话挺累的，工作量跟作者使用的 plugin 数成正比，另外还跟开源组件的代码质量有关系，如果到处都是 hard code 的资源引用，那就太悲剧了（说的就是你，百度编辑器，大厂出品？呵呵……），其实我最不爽的是，升级维护，或许可以考虑写个 gem 来处理这个事情。

#41 楼 @lips 这么说吧，市面上目前你知道和不知道的 rails 书，我都看过了，除了入门级别的……

#31 楼 @blacktulip 其实基本的处理流程我已经写清楚了，只要一步一步的来就好。这活儿确实很蛋疼，关键是，你要全盘掌握模板的构造，最郁闷的，就是碰到模板升级的情况，你说是升级还是不升级？慢慢纠结吧……

#30 楼 @peter 精华恐怕有点难，高级黑嘛