请不要删除原始问题……

else
  str1==str2

我感觉我 ruby 白学了……

当年就是 1.8 到 1.9 升级 break 了太多东西以至于后来 Ruby 都不敢随便乱来了，这才有了 1.9 到 2.3 的平滑升级路径。

最大的 break 在于整个字符串系统重新搞了，从 byte[] 转成了 char[]，于是所有的对字符串内元素的读写操作全都要重写……

1.8.7 到 1.9，满满的 break changes。

rvm，个人觉得 ruby 还是用系统包比较方便点……

nginx 1.4.4 这是什么千年老妖……

rails，为什么不用 bundle 安装要单独提前安装？

conemu，我觉得挺好用的。

我的确没写过 Unit::Test，因为我学 Rails 的时候老大直接带着我们写 RSpec 了。

我个人倾向于把业务逻辑拆分到app/service和app/lib下，然后分开做模块的单元测试。主程序基本只考虑做request or feature测试，这样相对来说比较容易维护测试代码，因为细节的实现可能会经常改动，但是只要对外的行为不变就没问题。

如果有（可能）比 Default Stack 更好的选择，为什么不用更好的呢？

而且 Default Stack 本身也一直在改变，比如 WebServer 之前用 Webrick 现在改用 Puma 了。

这个「没有头绪」是大问题。

月薪 1 万，现在的新人好可怕啊。

怕啥呀，直接开大号正面上啊

Ruby 没多少框架

Ruby 下 BDD 了不会有多少 Bug

就只能吹水了……

我说 Wine+Heidi 会被人打吗

新泽西节点？你不在纽约用的话何必买新泽西节点。

主力就是 Ruby，公司里偶尔用用 Coffee，没了……

之前用 Skype+GChat，现在我在试图转到 Mattermost。

devdocs.io

如果数据不要了的话就 drop 掉重建。

如果数据还要的话就手工修数据库。

C#的Partial是语法糖，Ruby的打开类是运行时的东西，完全不一样啊。

Racket 就不太清楚了。

#35 的论点也值得商榷。有很多的特性是互相冲突的，比如打开类这个特性，关掉的话可以改善维护性，允许的话可以提高开发效率增加灵活性，你可以选其中一个，但是没法两个都选啊。

你说到C#里var关键词，那你可曾知道C#的类型是没法编辑的。 一个类一旦写完编译完成以后，类成员就固定下来了。 既然类固定了，当然可以从返回值去推断变量的类型。

如果你需要一个静态类型的语言，那从一开始就不应该选择Ruby，而应该选择Java/C#系。 就像如果你要买一双适合运动的鞋子，那就去买一双运动鞋，而不是买一双有运动感的皮鞋。 你说是吗？

Ruby 这个语言的风格本来就是通过牺牲你说的这些来换取灵活性。

程序在运行期以外是无法正确检查类型的。

随时打开类，随时修改类行为，各种魔术方法（method_missing），你这个想法要是实现的话，这些东西都是问题，这有点颠覆 Ruby 核心风格的感觉了。

1. 提升最快的途径应该还是有人带着做项目。
2. 需求是一直在变的，在需求分析与灵活性之间权衡，适应可能的需求变更，加快迭代速度比花很多时间去确定需求要更有用一些。
3. 项目很难到终结，大部分项目都是长期持续地继续开发下去，很少会说做完这个功能以后项目就终结了（除非是没钱了做不下去了，或者进坟地了）。

Excited!

就算是在同一个公司里的同事，工作三年以后也会出现能力上的差异。三年经验本身说明不了太多。

.order('SUM(quantity) DESC') 应该也可以？

先看能不能优化查询咯。不能的话，你说的分级缓存是个挺常见的做法。

从零开始用 PG。已经熟悉 MySQL 了的话除非遇到技术瓶颈否则没必要切。

我给大家讲一个。 某个刚导完数据准备上线的生产环境下，发现有一个 Migration 写错了，于是打算 Rollback 某个特定的版本，结果手贱写了db:rollback STEP=2016xxxxxxxx……

多动脑筋。 只把安排的任务做完的话，真的就只能做底层员工了。 有自己的思考，提出自己的见解，带着自己的产品往前走才能往上爬。