#15 楼 @hemengzhi88 第一天的没有录

300 个活跃的肯定不止。我认识不少 70 后的 Rubyist，根本不上论坛，也不参加线下活动，但还是写 Ruby 的。

Oh My zsh 和 homebrew 都需要升级后，才能完美兼容 El Capitan

中

Linux 本身的包管理器维护得更完善吧

无论在哪里，创业总是应该选择自己最熟悉的技术，因为创业是为了尽早把东西做出来，做出来后你有的是机会改进和变换技术。

自动赞的功能很赞

:plus1:

楼主是否了解现在做一个静态网站的价格？

#5 楼 @tumayun 既然已被曝光，我就招了吧 我们暂时不招人，不过 remote 的朋友，如果喜欢到处走走，欢迎来找我玩。

默认好用，定制困难，但这也不是 devise 的错，因为它本身就是为默认为主 + 少量定制的场景设计的。

弹性工作和远程还是有点区别的。 remote 是小而美的公司的未来，但是，对于规模化的公司或人力密集型的业务，remote 就不适合了。

#37 楼 @hxh1246996371 有部分杀毒软件厂商做过这种事。 另外，最大的反流氓软件厂商，就是先做成了最大的流氓软件厂商（3721），再突然改做反流氓软件的。堪称现实演绎。

对于做过此类事情的厂商，我们必须要怀疑它后续行为的动机。 对于没有做过此类事情的厂商，我们也不能恶意中伤，毕竟还是有一些厂商在做靠谱的事。

V 站不懂装懂，乱喷技术的文化，不要带来 RubyChina，这里是理性的技术论坛

是 ICMP Flood，还是根据 ruby-china 的特点定制的海量 HTTP 请求？

Jared Friedman 的文章今天好红。

成熟的东西（像现在的 Rails），虽然汇聚了很多最佳实践，稳定可靠又能平滑演进，却再也找不到眼前一亮的特性了（实验特性引入成熟框架会破坏稳定性），所以，追求 Different 的人们开始唱衰它是一定的。

上一个类似的案例是 SQL => NoSQL，然而多年以后

中国各地的网络情况差异很大，就像大部分地方都可以流畅地翻，但是少数人的本地运营商网络很差，觉得要流畅简直不可能的。中国还有大量小运营商（长城宽带，电信通，宽带通……）它们会把流量劫持到自己的局域网，减少带宽费用，导致 AppStore 或其他流量出现问题。另外，部分廉价宽带有一个机制，持续大流量传输，会导致掐断互联网连接几秒，这样下载必然断线。

AppStore 的 CDN 在大部分地区表现其实不错的，100 次中 99 次可以成功下载和更新，速度也能保持 50Mbps-100Mbps 之间。但是网络不好的地方，就完全不一样的表现了，可能 100 次要失败 50 次。当然，就算偶尔断了，技术人员也不应该去不可信任的第三方下载。这么多大公司中招，只能说大公司普遍存在招聘不严格，不小心招到了不是技术人员的人来做技术。

那个只是成熟期，比较平稳。

真正衰退的技术，曲线是这样的：

#3 楼 @blacktulip 一次性付费产品，几年一次的巨大改变，很可能无功而返，或技术原因，或市场原因。而且，非大厂，并不积极 fix 现有系统的 bug，因为软件已经全部在发布的前几个月卖出了。 一次性付费的产品，比如 VMware / PD 每年也为新系统改进兼容性，并且提高性能，但是每年都被用户骂黑心收钱。 一次性付费的产品，比如 TextMate，曾经是 Mac 上 GUI 编辑器的王者，但因为没有改进动力，结果几年后衰落了。

但是订阅模式不一样，厂商积极 bugfix，根据市场连续的小功能迭代，用户也不在犹豫或吐槽又要花钱买新版本。这是良性循环。

订阅模式，开发商更愿意长期改进，对双方都有好处。

#12 楼 @lukefan 一些流量很大的网站，比如新闻站，会静态化为 html，他们大部分时候不需要登录功能。 其实，完全静态化，登录功能还是可以做的，通过 AJAX 方式请求那个区块，比如一些电商站就是这么做的。

我明白了，楼主的意思难道是希望做完全静态化。 这样的话，你要把页面 cache 下来，存为 HTML 文件，放在 nginx 可以访问到的路径下。 不过，除非非常大规模的应用，否则没必要完全不读数据库的全静态化。大规模应用的话，这一步也不应该自己来做，而是交给 CDN 做，只要设定哪些页面由 CDN 静态化缓存即可。

大学新生，建议 先谈恋爱。

如果你是为了兴趣，那么有 4 年的时间，你想学什么学什么，学好了都能找到好工作。 如果你是为了就业，那么技术发展太快了，你大一根据就业环境学的，大四时早就变了。所以等大三末期再找容易就业的技术学。

Google "Apache Reverse Proxy". You will get it.

好像没什么人说 devise 慢，大部分不用 devise 的都是因为它“太难定制”。

用 NFS 很常见，放心。 不过你的架构要考虑到网络延迟和丢包时，NFS 可能不可用的场景，有处理方案即可。

需要信用卡就办一张，并不麻烦的。 如果没有信用卡，未来你还会遇到其他困难，寻找各种替代品。

development 模式下，你可以一直开着，不用每次都重新启动的，大部分内容都会 reload on change 的。

结构更好了，终于 Sass 了，JS 的那些组件也实用多了。 不过，不支持 IE8 对国内网站来说，还是难以接受的。

楼主提出的“提前修改表结构”是不能很好应对部署出错的，回滚版本的时候，migration 一起回滚，是很好的实践，保证了数据库和代码的匹配。 如果有更复杂的情况，比如遗留数据处理，手工写任务处理。