#76 楼 @zzwzj 这是在北京的第二届，前四届都在上海

撸主是个萝莉控啊

rmbp 基本个人维修不能了，换一次屏 5.8k 没 apple care 基本可以考虑贴钱弄台新的了

app 在一个独立低权限用户跑 app 的代码放到该用户 home 里 log 放到挂载的/data 数据盘里

Concern 最好命名以 able 结尾~

#21 楼 @saiga play 还是可以用 java 写的吧，scala 我也不会 话说我接触 play 还是他 0.x 的时候

#24 楼 @ichord 对呀 java 的

我建议可以先试试接近 rails 风格的 play framework 然后再接触 rails，好处是先用熟悉的技术建立起 Rails 风格 MVC 的有关概念，然后再做技术的迁移

#72 楼 @xiongxin8802 可以参加每月组织一次的 SZRuby 聚会 @lyfi2003

#32 楼 @quakewang 了解了 那长微博我没读

#22 楼 @quakewang 老罗不懂的，发布会当晚 tombkeeper 在微博上说是老罗找他咨询给科技界基金捐款，然后推荐的 openssl，至于网站没上 https 应该是手下人的做法吧，客观的说这个应该跟吹牛关系不大

今天流量爆发刚搞完...早看到白天就不用花时间研究了 - -

感觉不同人学习能力有差异

同意解决问题比代码本身重要

提供一种可能的思路，把编程问题和熟悉的事务建立关联

支持，道理上是如此，但我认为这些内容都是对有经验的人来说的，但有经验的人往往有自己的方法了，总结的意义不大了...

对于新手或者刚入行的人来说，个人对各种经验总结都持悲观态度，试着逐一举反例

1. 抓住主干，而非细节。 那么，什么是主干？什么是细节？你可以知道，但新手怎么能够知道，我们也可以告诉新手什么是主干什么是细节，但要做不同的事情主干和细节是不同的，前辈们真的有那么多精力么？比方说学写 Rails 可能很长一段时间都不需要自己亲自动手完成一个类，或者也几乎不需要操作各种 IO，但我想写一个统计代码行数的小脚本则反之了。

2. 尽量不折腾 和 1 类似，什么叫折腾？对于新手，本身就是白纸一张，做任何事情都是“折腾”。而且相对来讲，做网站 NodeJs+MongoDB 组合对一个完全新手来说可能是最不折腾的了，因为只需要学习 JS 一门语言足矣。而且在基本 CRUD 上，是不可能遇到坑的，碰到“坑”完全是因为用错了。

3. 尽量学习经典原理而不是浪费时间在细节上 原理、思想很重要，但是，一个实践不足的人能够理解他们么？此外，编程是极重实践的工作，任何思想最终都要化为一行行实实在在的编程语言的代码，思想和模式是提供思路的，语言的语法、特性、类库是解答问题的，两者分工不同

4. 尽量学习形而下的系统而不过多上升到形而上的思想上 学习 C 语言就要随着 OS 学习，学习 OS 本身就是一个巨大的范畴了，数据结构、算法、汇编等等，而 C 只是因为历史原因采用其实现而已。 学习 Lisp 就随着编译器或分析器一起学习，抱歉不好举例，但个人认为编译器和分析器与 LISP 或者 HASKELL 之类函数式语言也无直接关系 学习 Ruby 或 Python 就跟着 web 开发来学习，至少 Python 在科学计算领域也有着很大的市场，Ruby 也在测试领域还有 PAAS 领域有着很重要的地位 上边每一个选择都是巨大的坑，彼此之间完全不相干 此外，通过某一类系统架构理解语言的优劣，优劣是通过对比得来的，也就是说，你要用 LISP 和 C 写操作系统，用 LISP、C 或者 Py、Rb 对比写编译器，用多种语言写 Web 对比后，才能说出优劣，这完全是实践出来的总结

我认为成长只有实践，走弯路很正常、感觉困惑也很正常，遇到了，停下来，反思、交流，我觉得这是个穷则思变的事情，各种经典书籍里记载的也不是真理，思考的原料、实践的方向而已，在瓶颈之前，不要想太多

#66 楼 @tangzhan_ 感谢！ 过段时间会发布消息的

#64 楼 @fredwu 下届地点暂时保密恩... 这次还是要熟悉下组织活动的流程

#60 楼 @stargwq 控制在 200 左右，争取以内

已经入手，等纸质版，再买一本留念

这种情况 mongodb 更容易解决，我们的流程是这样的

1. 保留旧的字段，加上新的字段，如果涉及到数据迁移，则编写兼容代码，添加修改的时候再写入旧字段的同时也写入新字段 2.上线模型，并且在后台对老数据做数据迁移 3.上线新功能 4.删除兼容代码，清理废弃代码

下一届办在哪里 保密 恩。。。

蹭饭！

恩 会去

#65 楼 @simlegate 至于怎么找到方法，原因则很复杂，运气、个人经历、知识积累、经验等等都有可能

另外就是，人是会随项目成长的。面对问题来解决问题，然后总结，什么样的问题是常见问题，什么是跟场景有关，Rails 其实就是前者常见问题解决方案的集合。

#65 楼 @simlegate 努力没什么事儿做不成，我不赞同，更重要的是方法要找对，然后才是努力

测试为什么不能解决问题我已经叙述过了，回头看我帖子，另外别忘了，RSpec 升级之后过去的用例集也要重构的，这工程可真不比升级系统小

#60 楼 @simlegate 少年，脑洞不要开太大，升级之前我早在半年前就用几个项目预演过了，唯一遇到棘手问题还是 Mongoid 当时处于 alpha 版有 bug，正好赚个 PR

难度多大、花费时间多少、无不无聊 看人，你能力够强、经验够丰富 没什么做不到的 世界上毕竟还是有 Linus 这种代码一次成型的大神的

#57 楼 @psvr rake routes 就可以完成 提高效率的有效方式就是少走弯路，业务代码首先无聊其次没营养，这样学习不浪费精力，何况代码数万行后了解整个系统运作几乎不可能。这里也是 Rails 的优势，通过 Convention 降低学习成本，构建好代码地图遇到问题就能够做到快速定位问题即可。

至于#58 没有证据表明测试和减少潜在问题有正相关性，例如 Rails 的 CounterCache 的测试用例就是错误的，实现也就只能是表面上正确。所以能够降低这个观点不成立。 至于你说不会 100%，我得承认具体问题具体分析，因为我不是反对测试，而是认为很多项目因为业务和工程上的特性可以变通的方式避免编写测试并且减少重构时发生问题。如果一个项目完全可以这么做，我认为写测试的必要是 0，肉测即可

#36 楼 @xdite 啊...好吧...