@mengzhuo 加把油，看博客小伙子挺不错

这一段很受启发

> Franco: What recommendations do you have for young people in Italy that are passionate about technology and are looking for opportunities to emerge and build a career as professionals?
> Salvatore: My advice is to use the moment when they are still young enough for parents to be willing to pay for their bills to build things. Your parents are your first VCs, they are investing into you in a moment where you are full of energies. Other advices: don't study forever, put an hard max number of years to your specialization. Finally, don't believe you have something less compared to people in the UK or the US where you see a lot more going on. It's not a matter of better or more competent people, so a good strategy would be to try to create new things without copying what others are doing.

他们的ticket回复很快，有什么问题直接建ticket吧

刚问的

http://ww2.sinaimg.cn/large/67b05ff9jw1enaxwb8zxqj20yu0petag.jpg

@jakehu 找微博作者要吧，我只是转发一下

@dndx 确实是 Google Compute Engine.

@julor

Google App Engine asia-b

http://ww3.sinaimg.cn/large/67b05ff9gw1emx3ki4s9fj21kw0todlr.jpg

> 我删除了你的其他几个comments。这是我第一次在知乎上删除别人贡献的内容。很不好意思。
> Bertrand Russell说现代西方科学是建立在逻辑的基础上的。所以科学技术可以理性分析，可以实事求是。我理解这是很多技术人员热爱技术的根本原因。但是如果讨论的时候，不小心或者习惯性地没能维持好一个客观、温和的氛围，技术讨论也可能陷入情绪化，甚至文人相轻的窘境。
> 针对你提到的Go的几个问题：“反射半吊子”，“annotation半吊子”，“gc不像样子”，“不支持泛型”。我建议总结问题并发布出来，可以和社区分享和讨论。如果很多人都赞同应该修改，也就对修改的价值比较自信了，可以改之，并且请Go Authors review。由此得到的尊重，是可以称之为人生财富的。
> 我早几年的时候，也很容易在技术讨论中情绪化。我觉得这是性格使然，没什么不对。关键是如何完备自己。我比较幸运的是，我身边有一些非常出色的工程师，他们以榜样的力量帮我慢慢拽出来。这让我相信：一个热爱技术的人，是可以用完备技术的热情来完备自己的。

TLTR: “等于”比“不等于”更符合直觉，避免嵌套优先执行异常分支。选第二种。

via. Code Complete 2nd

Summary of Techniques for Reducing Deep Nesting

The following is a list of the techniques you can use to reduce deep nesting, along with references to the sections in this book that discuss the techniques:

- Retest part of the condition (this section)

- Convert to if-then-elses (this section)

- Convert to a case statement (this section)

- Factor deeply nested code into its own routine (this section)

- Use objects and polymorphic dispatch (this section)

- Rewrite the code to use a status variable (in Section 17.3)

- Use guard clauses to exit a routine and make the nominal path through the code clearer (in Section 17.1)

- Use exceptions (Section 8.4)

- Redesign deeply nested code entirely (this section)

区别大了

In [115]: dis.disassemble(compile("total & 0x01", "__file__", "single"))
1 0 LOAD_NAME 0 (total)
3 LOAD_CONST 0 (1)
6 BINARY_AND
7 PRINT_EXPR
8 LOAD_CONST 1 (None)
11 RETURN_VALUE

In [116]: dis.disassemble(compile("total == 1", "__file__", "single"))
1 0 LOAD_NAME 0 (total)
3 LOAD_CONST 0 (1)
6 COMPARE_OP 2 (==)
9 PRINT_EXPR
10 LOAD_CONST 1 (None)
13 RETURN_VALUE

In [117]: dis.disassemble(compile("total and 1", "__file__", "single"))
1 0 LOAD_NAME 0 (total)
3 JUMP_IF_FALSE_OR_POP 9
6 LOAD_CONST 0 (1)
>> 9 PRINT_EXPR
10 LOAD_CONST 1 (None)
13 RETURN_VALUE

- 除了正确执行，代码就是用来维护的。谈维护有个标准，就是谁都能执行，大家品味一致
- 你能兼容他的hard code，他未必能兼容你的OOP
- 除非没人愿意接手维护了，或者有强力Leader牵头，不要干重构这类吃力不讨好的事儿。Martin 的书有点像心灵鸡汤，描绘了该是什么什么样。问题是design一旦脱离实际执行的人就变了味道，执行不好，培训不够，监督不全都会慢慢变坏。
- 没有数据，“可维护性”很有可能不可度量。比起明眼就能看出来的调用效率，自然被攻击。你需要想办法证明“这样写”的代码不可维护。

我就奇怪，烂服务这么多，监控这一块怎么就每个声响

一口吃不了大胖子，摘自己看了有感受的章节。这种大头书，我啃了好多年

@zhengkai

考一个二分不过分吧，至于 $i++ 和 ++$i 实在蛋疼。
了解算法的好处是能够快速分辨一个方案的好坏，你不一定要变成大厨，但是你至少要能分断出黑暗料理。

http://weibo.com/2398286384/BsHSv5rpJ

正常人的论证方式是左面的，有的人论证方式是右面的。[挖鼻屎]
http://ww4.sinaimg.cn/mw1024/8ef2f230tw1eljpyln6pqj20dc0dwdgh.jpg

有的时候我会觉得没办法在V2EX用Q币买饰品凸显我的高贵冷艳，就浑身不自在