难道每一个 ruby 项目的结局，都是用 java 重写吗？

准确的说，99.99% 的 ruby 项目最后的结局，都是公司倒闭

哈哈哈，敲着音频想着视频，这个确实没什么好办法，只能靠带时效的私链了

音频也都可以，七牛支持

可别蹭这哥们热度，小心 NC 粉扒你精日

对于不太会用 webpacker 那套但会写 js，可以简单集成，直接引用 vue.js 像 jQuery 一样的用，只不过不是标准的 SPA，相当于每个页面一个 APP，还用 rails assets pipeline 就可以了

APP 图那当然是私有库 + 水印

早期拆分肯定坑，盲目拆分也是坑。 我们的项目从开始拆分微服务到现在正常迭代两年多，业务也足够复杂，拆分出来的服务也就二十个左右吧。几十个？有点夸张，大厂就另当别论了

用 Spring Cloud 这套也挺不错的，以前总觉 Rails 开发效率甩 Java 十条街，但真的用起来也还好，各有各的好，喜欢 Rails 的快速迭代，有问题了还能线上开个 console 去调一把。但 Spring Cloud 基本上可以替代掉 Rails，尤其在大团队协作开发的情况下，如果还是在一个或几个大项目里层层迭代，恐怕代码堆积起来后来人维护都会手抖。

现在如果不追求微服务的话感觉团队还是不够一定规模把，大团队拆分出高内聚低耦合的微服务各自治理，质量上还是很有保证的。至于用 Java 还是 Ruby，敲代码的说了不算

大公司为啥不用 ruby？因为大佬

你需要的是 money

Ps：如果处理国际货币的话，很多货币是没有小数位的，或者小数位只有 1 位，比如円

不管哪种写法 四格缩紧是不能忍的

这不是保留数据的问题，而是你没搞懂测试到底要做什么。

你的两个 test case，分明是一个 test 的流程。

所以，最大的问题是你还没搞懂什么是测试和如何测试

另外，这排版很醉

建议先学习一下测试基础

单列索引最好还是不要在一开始就加上吧，通常都是没用的，软删的索引还是根据业务需要加联合索引效率更高

同楼下，定一个公共 services 就够了，自己调用自己不是很别扭么

controller 里请求应用的另一个接口？ 如果是的话，开发环境启动的服务只能同时处理一个请求，你在请求里发起第二次请求直接挂起，然后只能超时，接下来服务再处理第二个请求

这个 200 应该是 http code 吧，不需要在 response 里单独弄一个，如果要单独定一个 code，可是在 render json 时加个 meta 选项，只不过不是在返回数据的最外层有点别扭。 如果非要这样的话，还是 jbuilder 更方便点，ActiveSupport Serializer 感觉适用于高度 restful 的接口返回，并且针对一种 resource 不存在多种返回形态。

底层改动还是得慎重点，尤其这造轮子，替换生产环境可能会有预料不到的影响

并发要求不高的情况下还是 http API 更方便

system("sh files/test.sh")

简单的方法，跨项目使用 api 或 rpc 交互

客户端的锅不能都砸到后端，这种问题应该先从客户端下手解决问题，web 点击不禁用那就改，不是所有地方都要必须要检验，关键流程比如提交控制好就行，自己的产品这些做不好说不过去吧

然后是后端对提交特征值的校验，比如设备 id，时间戳，ip

为什么 不把 APP 的 bug 修了？

看照片不如看真人，康忙

分别去掉 :as ，再加上 :as 试试 @product.pictures 就知道了

介绍一下大鱼的人栈

http://www.fishtrip.cn/about_us

12x16 为啥不直接叫 16 呢？

王尼玛不来说两句能行么？

为嘛不用URI("http://www.wrox.com:80/misc-pages/support.shtml")

mina 使用的挺方便，遇到唯一一个问题就是shared_paths下的文件需要改动，得上去手动改一下，不知道有没有更 mima 的方法可以根据自定义的某种规则自动修改软链的配置文件，像 crontab update 那样