写的有点乱，原作者的核心观点其实就是 branch 被滥用了，然后说明了滥用的地方，只要有效反驳这一点就可以言之成理，其它都是枝节

恭喜 @rei

吐个槽，大疆的售后感觉不怎么样啊，我买了两架精灵（2 和 3），对故障的处理很让人担心，现在都不敢买 4 了

新架构是完全做代理么？我也怀疑 api 的压力是主站不能承担的

另外，@qhwa 是如彼还是墨泪？没想到也离职了

昨天半夜就起来看各种宣传片了。 有个疑问，障碍感知能处理的障碍有什么限制，比如居民楼附近有电线，能”看到“吗？

两条路：

先选你感兴趣的领域，然后看看这个领域常用什么语言框架。 先选你感兴趣的公司，然后看看这个公司热衷于什么语言框架。

第二条路的缺点是：好的公司特别是大公司通常不是单一语言技术栈

没啥讨论价值，王垠的关注角度和一般人不一样的，而且也不是“工业级”，他是“研究级”，如果他的文章是讨论具体问题，不妨看看（前提是能看懂），泛泛之论就算了，普通人不必关心科研人员吐槽

vagrant 大法好，用 rubymine 是正确选择

还没有得到过以 ruby 为工作内容的职位薪水

07 年和同事合伙做网站，结果发现 ubuntu 下面搭建项目只要两行：

apt-get install rails
rails new myproject

所以实属意外

果然做广告一定要花钱才有诚意，已注册

吕、莫好像都是科班出身吧，对 ruby 的好感还是很足的

很难想象 ruby 社区会有一本书和 effective java 相当，不过还是关注一下吧

Progress over stability 意思是“行进中开火”么？

有股票就留下，否则闪人，一般来说这么做没大错

一定要搞清楚员工和老板的关系——基于契约的协作。

兔死狗烹的典故来自等级森严的贵族社会，双方是依附和被依附的关系，现代社会（没错，即使是大家都不喜欢的 hard 模式的中国）原则上没有兔死狗烹。

为什么说是“原则上”？因为这涉及你的理念，所以核心问题还是搞清楚你和老板的关系，包括不要对老板抱过多期望，也包括理解老板真正比员工多付出的地方在哪里

完全物理隔离是不可能的，比如你不是还可以 scp 嘛，楼主应该说清楚是怎样的隔离方式，比如服务器是否可以自己访问外网，或者受限访问外网（受到类似国家防火墙的阻挡）等等

#6 楼 @msg7086 rebase +1

#17 楼 @knwang 非常感谢，我写完以后就觉得可以合并 team/team controller，以及 matrix/matrix delegator，有空再重构一下，这种练习很有意思。

over design 的问题有原因，我本来是想做玩家对决，后来发现还是想多了 :-P

另外有个困难，就是 ship 里面那段代码，主要是为了避免碰撞，感觉很啰嗦，而且降低了可测性

想了一下，不应该怕丢人，代码在 https://github.com/fsword/ship-game

总结一下试验的收获：

• 对 player、ship、screen、matrix 的建模比较重要
• 虽然以前没写过类似的程序，但是在其它方面得到的一些经验有助于简化工作，比如 repaint
• 分离关注点的价值，以及对 listener 的理解
• 最后处理 Array.new 导致的那个 bug 花了很久时间，说明 API 掌握不熟练会导致很高的成本

用 debian 以后才觉得 linux 很美好

5x5 矩阵有讲究啊，如果是 4x4 会有点麻烦

-------------12.31. 更新分割线----------- 试了一下，累计时间已经超过两个小时了，目前还有 bug，好泄气

#4 楼 @luikore 楼主理解没错啊

irb(main):009:0> class X; attr_accessor :group_type; end
=> nil
irb(main):010:0> instance = X.new
=> #<X:0x007fc43129ae30>
irb(main):011:0> not instance.group_type.nil? and instance.group_type.downcase == "case" 
=> false
irb(main):012:0> instance.group_type = 'case'
=> "case"
irb(main):013:0> not instance.group_type.nil? and instance.group_type.downcase == "case" 
=> true
irb(main):014:0> 

#15 楼 @xssbt 虚拟机自己调度线程的代价就是要负责影响释放时机啊，完全交给操作系统就没法运用 GIL 了

#25 楼 @gzrain 做法是有些传统了，不知道你们的 private cloud 是否有其它因素考虑，如果没有特殊原因，还是多接触新趋势好一些

#26 楼 @akirapanda 这篇文章是针对 ruby 工程师而写的，针对所有程序员的简书文集在这里

你的感受很充分，不过其实 docker 的未来（未必是 docker 公司的野心）还要更宽广些，实际上我是打算写一本书专门谈这个，不过考虑到自身水平和拖延症，还是先拿些文章凑数比较好。

spring boot 作为微服务基础挺契合你说的演化路径，如果有空来杭州的话，不妨在 ruby tuesday 上聊聊

#23 楼 @gzrain 你是哪个公司？1 月份北京有一个 container 大会，是 dockerone 社区搞的，我了解了一下，案例比较多，打算去看看

#21 楼 @xanderzhang 不是 docker 成本高，是分布式本来就成本很高，所以如果系统演化到非分不可（一般来讲这是必然趋势），就需要 docker 出手了，这就是我们必须掌握 docker 的原因

#18 楼 @hmilym docker 这个技术绝不是仅仅和运维有关，就象集装箱绝不仅仅和船有关（这也是我没把这篇文章放在运维节点的部分原因），理解然后发挥 docker 的价值，最终是要涉及整个研发链路的

以前杭州的 ruby tuesday 有好几次就是在 ThePlant 做的，社区里好些同学也是出自这里，顶！

slim