#27 楼 @assassinpig 我没说清楚，应该是压力过大。

压力和记忆力的关系知道的不多。但一定的压力是非常有必要的，但非常大了，就有害了。

#21 楼 @moliliang 想要记得太多，记不住，是正常的。。。这个不能算是记忆力减退，如果这样的话，就没什么好担心了。

最近，觉得 14 寸的 mac 屏幕太大了，想外接个简述的飘过。。。 你们都无视我吧。。。

非常严重了，而且还需要很好的记忆，去去看看医生吧。

如果不严重，等等再说。

没有证据说，人的记忆力会随着年龄递减。

记忆力不好，不想记的可能性最大。如果觉得一件事情无聊，你肯定记不住。

记不住的东西是什么？人擅长记忆某些东西，不擅长记忆另一些。

再就是身体最近怎么样？

压力是否很大？

有些不知道的东西反而很重要，说的高深点，就是在不透明的情况下决策。

从软件开发的角度讲。有个策略是敏捷开发。没需求想想办法确定需求，xp 有个思想就是，不写不需要的代码。代码需要维护，越多，越不好维护。要灵活，快速应对变化。我不知道明天怎么样，但我可以保持灵活（所谓的反脆弱）。

当然也有很多办法可以避免损失（折中方案总是有的）。

比如一个公司如果想创业。可以先做自己公司的库，这个可以很好的提高效率，增加大家的积极性。然后还可以做自己需要的工具，如果好了的话，可以开源，再牛逼点，就做成产品。似乎 37signal 就这么搞的（没根据的，乱猜的）。

比如框架这个东西，非常重要，写好了花的时间太多，写不好了，又不好用。干脆开源，大家一起写。你获益，我也获益。可见的好处是知名度，不可见的好处是积极性，能力，代码质量。

运气这东西很不好说。觉得 DHH 不拼爹，也不靠运气，一样很牛。 觉得做好一件事靠的更多的是努力和一点点天赋（其实环境什么的也非常重要了。。。），但你要做到最好，比如你写个语言非要赶超 ruby，那就需要运气了。

#2 楼 @lgn21st 感觉三楼外楼了，我也跟着歪下。 Engineering Long-Lasting Software http://book.douban.com/subject/10511550/ 这本什么都有，哈哈。

@mahone3297 确实有点多，我改一下吧。。。非技术，非小说，比如最近在看的是《反脆弱》和《remote》（图多，字少，估计能达到 4、50 页吧，哈哈）。 都是做第一遍速读或者是重读，所以速度都比较快。

住的离公司也稍微远些。在地铁上看书，没法看技术类的，效率也一般点，但也还好。每天能看 3、40 多页（这些应该是有的，因为都是速读和重读。之前估计的有点太乐观了。）。其实也蛮可观的。

再就是地铁上看书也不太好，一是对眼睛，二是人有的时候需要 idle 和 wonder 的。不过总体上利大于弊。

吃饭觉得没那么贵，早上随便吃点，5 块钱，晚上 12、3 吧。

另外我始终没把广州和上海北京放在一起，不是说他经济发达与否，而是树多，空气好，人还不太多。广州比我家里（3 线城市）的空气要好不少。

#36 楼 @u1378130755 那就好！嘿嘿。JavaScript 坑太多了。但我说的都不严谨。。。就是那个意思吧。

按照 hisea 的说法应该是这样，在浏览器中是返回“My Object”的。 var name = "The Window"; var object = { name : "My Object", getNameFunc : function(){ var that = this; return function(){ return that.name; }; } }; alert(object.getNameFunc()());

@u1378130755 我有点过于随便了，而且是拿 scheme 往上套的（毕竟 js 的作者很大程度用了 scheme 的东西）。。。但应该大体是那个意思（也许差的很远。。。）。

这个是 this 的原因。在 JavaScript 中，那个东西叫了 方程，谁就是 this，如果没人叫的话，就是 window（其实叫 global 也差不多。。。）。

第一次，是 object call 了 getNameFunc，然后返回的是一个方程，随后，这个方程又被 call 了（第二括号），而这个时候已经没有 人叫这个方程了，所以 this 是 window，顾返回“The Window”.

clojure 的 scope 是 function 的。就是有个 function，就有一个 scope。

scope 有点像一棵树（其实就是个属性结构，全局是跟）。假设一个变量出现在子树里面，比如 a，然后编译器看到 a 了，就开始找 a 是什么东西，在本 scope 里面找，如果有定义，那么直接得到值。如果没找到，就去他爹那找，一直找下去，如果到全局了，还没找到，就报错了。

var a = 10; #编译器记录了一个 a到10 的映射。
a+1;

编译器读到 a 的时候，就找 a 是什么，发现 a 是 10，赋值，进行运算。

都学学，都用用呗，有没差太多。 需要用哪个就用哪个。

mechanize 可以设置 user_agent_alias 这个（系统和浏览器），是换一下试试。可能是这个问题。

觉得 ruby 写算法没什么太大的有事。

我实在想说，算法只是编程一部分。而且觉得算法跟艺术关系也不大。。。测试似乎也不全。

@whitecrow thx

人可以选择不去考虑些什么，但这样做很难。。。

一个新特性开个新分支，做完了，再 merge 到主分支。如果关于 git 你只想学一点，那么你就学这一点吧（这个不是我说的。。。）！

问题 1。 1，比如你写个项目，其中有个功能是关于滑动效果的。你写出来了，但过了一个月，需要你改一改这块的代码。没 git，你怎么知道哪些功能是和滑动相关的（当然你可以推断，全局搜索什么的）？你看 git comment！你找到你写在哪了，写了什么，就可以开搞了。这么是最清楚，最快的。 如果是多个功能，你需要话更多的经理去考虑，哪些是相关的。

2，出现问题了，有的时候不好 debug，干脆，就 checkout 了。如果两个功能写在一些，你 checkout 的时候会把别的功能也干掉，很不爽。。。

3，做个总结。你这干一样，那干一样，很难完成任务的。

写些项目吧！反正你写着写着就会发现，git 怎么这么好用！

再者，git 用于多人合作。我想看你代码，总不能说，hi，给我给备份。。。

顺便推荐 gitx。

需要学 clojure，刚才找书，随便找了下就 5、6 本了，认真看不可能，但至少要过一下，有需要再细看。 看着的书，有 10 多本。。。 闲书（比如 remote，mindset 等），开始看的就有 3 到 5 本（有的是重读）。 始终觉得书看不完，看完了，有些还需要回头反复看。。。

建议去豆瓣搜，书太多了。或者看看别人读什么，觉得好就跟着读就是了，反正是读不完的。。

Inappropriate Intimacy 一个 class 利用了另一个 class 过多的实现细节 (One class exploits too much knowledge about the implementation of another)（你知道的太多了。。。）。 重构：Move Method,Move Field 如果真的需要把它们放到某处，Extract Class，如果真的有重叠的话。或者引入一个 Delegate 来隐藏 (hide) 实现如何实现。 翻译的，嘿嘿。

顺便补充下想关的命令和 gem，rake stats,SimpleCov,flog, saikuro. 后面两个没用过。觉得工具也非常重要，有个量化标准，而不是依据个人的喜好。

觉得 comments 有的时候该加还是要加比如 这种 ' function getPayloadBytes() { // 1 MB return Math.pow(10, 6); }'

参考资料<>

其实挺反感读书无用的论调的。。。 但有些本科用的教材确实比较坑，读了还不如不读。

http://book.douban.com/subject/10511550/

这本书楼主要的都有了，edx 有相应的教程，搜索 cs169。

不足的地方是 javaScript 讲的很少（js 才是大技能。。。）。 再就是这本书更注重的是传授一种方法，以及尽可能让你理解最重要的东西（比如测试只讲了 mock，stub 之类的，rspec 中的 it 都直接被作者跳过了，作者觉得这个可以自己学吧？）

优点是全、精、简。 全，敏捷开发，BDD,TDD，Git, js，团队合作，重构，设计模式，优化都有讲。 感觉敏捷开发需要有个全貌，要不然很多东西连不起来，比如为什么要选择敏捷？为什么随后要跟着 BDD 和 TDD。 精简，这本书解释 js 是面向对象语言，就用了两句话，js 有对象这种机制。但没有继承，继承跟面向对象没关系，是大家使用 java 产生的误解。有一篇 blog 为了解释这个问题说了上千字。 讲 ruby 的时候，直接从三个大特点切入，一切都是对象，一切都是方法，一切都是元编程。比如数据库的查询，只告诉了你一个 where，剩下的自己查文档。 讲 ruby，常用的 methods 都列出来了，够用了，在不想把 ruby 写得很魔幻的前提下。

非常赞同楼主的观点！用 rails 和 ruby 就是为了快速开发和迭代。遇到性能问题，首选就是买服务器。

想请问，楼主关于单元测试，是怎么看？单元测试和开发（这里包括维护和 debug，团队交流）速度是一个什么样的关系？ 谢谢！

人脑的能力其实还是挺可悲的，"the number of chunks of information you can remember accurately with no memory degradation is only one"，所以学习新动，分解问题就很重要，如果都连在一起。。。就很困难。

有一种处理 legacy code 的方法，是一边写 character test，一边重构。代码乱了，感觉除了功力深的，没发写，所以要重构。然后写完了，可以把测试当文档用。 当然写测试，也需要很好的能力。。。

有人说以前机器很贵的时候，机器的时间比较贵重，要用汇编，要用命令行，当机器变得便宜的时候，人的时间变得更加重要，于是出现了图形界面。

使用 ruby 其实也假设了，更多的考虑程序员的感受，而不非机器。

呃，有个故事是说美国看了中国的教育之后，预言没几年，中国就会超越美国呢。。。这么多年过去了。。

中国的问题不是钱的问题。国民时期有多少大师级的人物出现？呵呵。也别拿人口说事，日本人口密度更大。