都说秀恩爱死得快，真怕这个答案会在未来某天不得不转行时掌脸，但还是忍不住想来答一下。
借用那个问题 业余和专业最大的区别是什么？ 中的某个答案，一样东西你当作兴趣爱好，做到 50 分时就会获得「好棒」的夸奖，做到 60 分就会被称赞「真是个天才」。而作为职业人士，做到 80 分是「理所应当」，做到 70 分则会是「怎么差成这样」。
所以把兴趣当作职业需要面临的问题是：在某个喜欢并擅长的事情上成就感急速降低。
想想，一个人前一秒还被朋友夸赞写的东西真有意思应该去出书，后一面就被编辑退稿：傻逼，不登。这是种怎样的折磨啊。更不要说世界上有那么多嚷嚷着「我们只要高端大气上档次」的难缠甲方了。
然而世界上总有些富有冒险精神和精益求精精神的人愿意将兴趣作为职业，除去他们对这项兴趣极度的热爱以外，更是因为「在自己所热爱的事情上不断进步进步直到攀上高峰」所带来的巨大成就感，这种快感无可比拟，犹如宿命，犹如光荣的荆棘路。
谷歌发布新操作系统 “L Developer Preview” 后，也同步推出了可视化语言 Material Design，它的设计美学将会融入到谷歌所有的平台之中，包括 Chrome OS 和网页，它也将形成一个统一的外观，将所有的产品捆绑在一起。扁平化的设计，加上明亮的色彩，Material Design 的外观还是很吸引人的。此外，谷歌对动画效果也做了相应的调整，让体验变得更加好玩儿。
除了在 Google+ 社交媒体上发布了相关内容之外，谷歌还给与会者发送了一些艺术印刷套件，其中就包括一些极具特色的明信片，这些明信片很漂亮，也向人们展示了新设计语言的设计原则。谷歌是这样介绍的：「设计是创造的艺术，我们的目标就是要满足不同的人类需要。人们的需要会随着时间发展，我们的设计，实践，以及理念也要随之提升。我们在自我挑战，为用户创造了一个可视化语言，它整合了优秀设计的经典原则和科学与技术的创新。这就是 Material Design。”
材料隐喻是合理空间和动作系统的统一理论。谷歌所谓的「材料 “ 是基于触觉现实，灵感来自于对于纸张和墨水的研究，也加入了想象和魔法的因素。
十七岁的梦想，十七岁的故事，十七岁的微笑和眼泪，就让它们永远留在我们回不去的十七岁吧。多年后的简宁，沉静如初，淡定如初，鲜活如初，在我心里。致我们回不去的十七岁！
因为《北京爱情故事》中的吴狄，想起了多年前《十七岁不哭》中的简宁。忍不住在百度上搜到全集，再一次重温儿时的经典。
简宁——那样简单，宁静的男孩子是被许多女孩暗恋着的吧。他对待学问谦虚且认真，对待同学朋友真诚，对待自己要求严格。当然有很多人会喜欢雷蒙，可是我喜欢简宁，我最欣赏他的一个方面，不是他在入学摸底考试时在别人怨声载道时冷静淡定考出的门门 95 分以上；不是他认认真真地练守门只为捍卫自己的小小骄傲；不是他吹得一口好萨克斯；不是他在广播台能够面对他人离去而任劳任怨独当一面；而是军训时的一个立扑，在立扑这个项目的训练中只有雷蒙一个人做的最好，但是只有简宁一个人在做的不好之后重新做了一次，那一个瞬间我开始欣赏简宁。我欣赏他对完美永无止境的追求，欣赏他不随随便便说结束。
他的优异成绩他的组织才干他的体育能力，这些学校和家庭的教育统统都能培养的出来。然而究竟是什么的熏陶，能让一个人有那样从心底散发的从容大气淡定沉着的气质。
还记得军训时大家都在喊累时他在读书，教练问他累吗，他说还行，教练问还行是什么意思，简宁说，「累，但还能坚持。」
By Sahand Saba 翻译 Liam
自从我开始学习 python,我决定记录下一系列经常用的技巧。当我看到一些代码（例如，在 Overflow，或者一些开源的应用等等）我觉得很酷，我觉得我们应该不知道这一些用法。当我理解这些代码的时候，我会测试这些代码，然后加入这个列表中。下面发表的是一部分整理后的列表。假如你是一个很专业的 Python 工程师，即使你已经知道大部分用法，你还是可以找到一些你不知道的。假如你是 C, C++, Java 工程师，并且最近想学 Python，或者最近想拓展新的编程方式，那么你将会发现有一部分真的很有用，就想我一样。每一个技巧和语言的特性都将会通过例子演示，而没有解释。同时，我将会尽量使例子简洁明了，可能有一些仍然讲的不清楚，因为专业水平不够。如果有一些例子看完之后还是不能明白的话，你可以利用例子的标题去 Google 找到更多有用的信息。例子大致的按难度排序，一些比较简单和常见的功能和技巧会放在前面。内容的目录我将会放在最后
Roy Keyes 提了一个非常好的建议，把这个文章放在 github 上，让人们通过提 PR 方式来增加内容。这个仓库是 https://github.com/sahands/python-by-exampl。欢迎大家 fork，提 pull requests。我会更新这篇文章的，当有仓库跟新的时候。
这篇文章在 Reddit, Hacker News 有很多的讨论， 在那些评论中，很多读者提了很多建议和修改。我已经更新了我的列表，根据改进的建议，并且增加了一些新的条目。我现在确实有这样的一瞬间。”Cool! I didn’t know you could do that!” 另外，我不太清楚 itertools.chain.from_iterable 和 dictionary comprehensions. 同时，有一些十分有趣的讨论关于是否有一些技术导致难以调试代码的可能性 就我而言，下面的条目本质上是没有很难调试的。但是我可以断定，如果代码写的太长，将会增加调试的难度，以及更加难理解和维护。根据你的判断，如果你的代码足够的简洁，那是有那好维护和阅读。举例来说，我觉得列表推导式可以很好阅读，而且易于调试和维护。但是如果列表推导式在另一个列表推导式中来传递给映射，然后到 itertools.chain？可能不是好主意！
2014 年 2 月 14 日是豆瓣 CODE 项目成立两周年，同日豆瓣 CODE 团队宣布 将整个框架开源。本次开源包含 CODE 框架 以及 Mikoto、Linguist、P、CodeLive 等周边项目，感兴趣的工程师可以在这个基础上继续开发。
下面，豆瓣 CODE 的工程师们将在 InfoQ 上分享一些 CODE 背后的故事。
2012 年初，已经对 SVN 和 Mercurial 无力吐槽的豆瓣工程师们正面临一个艰难的决定：是往 Github 企业版迁移，还是自己研发一套代码管理系统。
2012 年 2 月 14 日，清风老师为豆瓣 CODE 写入了第一行代码；一周之后，一个用 Trac 改造的原型诞生了。CODE 不是一个公司项目，自始至终没有任何一个豆瓣的产品团队或工程团队为这套系统负责，但一个又一个的豆瓣工程师开始被吸引到这个项目周围，形成了一个强大的虚拟团队。
随着 Github 在国内的普及程度越来越高，越来越多的企业也开始探索自建 git 仓库之路。开源的 Gitlab 项目 开始受到部分团队的关注，但这个项目仍有较多局限性。这时，豆瓣 CODE 引起了包括淘宝在内不少同行的兴趣，并开始沟通将 CODE 开源的可能性。
作为一个面向内部设计的系统，CODE 的源代码中混杂了大量豆瓣专有系统的依赖，如果要开源出来需耗费不少的工作量，之前 清风在 C2D2 的分享 和 段念在QCon上海2013大会的分享 中都提到这一点：
虽然有种种麻烦，但豆瓣的工程师们仍然将大量工作之外的时间热情的投入到将 CODE 开源的工作当中。一开始，CODE 团队零星的 将一些底层的基础库开源，包括 Python 版本的 git HTTP 实现 GPack，git SSH 实现 Maria，Pygit2 的 wrapper Ellen 等；2014 年 2 月 14 日，豆瓣 CODE 宣布 将框架代码和周边项目代码全部公开！此时的 CODE 已经聚集了 85 位 committer 为其贡献代码，并且已经托管了 1916 个项目，其中大部分都是类似 CODE 这样的、由工程师自主发起的非官方项目。
CODE 发展两年来一直在扩展自己的定位，从单纯的代码管理系统发展为可以将设计、产品都拉进来一同协作的平台，周边衍生出大量的附加项目，从 image diff 到类 Dropbox 的文件同步工具，可谓五花八门。所有这些功能都围绕一个核心：对 git 仓库的读写。
豆瓣曾经历过大桌子开会、强制大家做 review 的岁月，而 CODE 颠覆了这一情况。CODE 团队将 code review 视为 CODE 的第二个核心功能，认为促进工程师之间的沟通是 CODE 最大的成就之一。
CODE 为每个项目设置了三个角色，分为 owner（有全部权限）、committer（有 push 和 merge 权限）、member。review 机制根据项目的不同设置了不同的规则，如产品线级别的、需要对外发布的项目，基础库等项目都需要经过严格的 review，如 东西团队 对 review 设置了如下规则：
对于松散或娱乐性项目、小工具项目，并不会那么严格的 review，这也取决于 owner 自己，他可以借这个项目寻找到一位导师，来帮助他进行 review：
对于 CODE 项目本身，所有工程师都可以向 CODE 上的任意项目提 PR，也都可以是 CODE 的 reviewer，同时所有工程师的代码都需要经过 review 才会被 merge 到 master 分支。
发展到现在，豆瓣的 review 基本上都是自发，很少遇到需要 review 的代码堆积的情况。代码讨论区里据说时不时会出现美女图，这可能是刺激工程师们去 review 的因素之一；另外，CODE 系统本身也有奖励机制，鼓励大家去评论别人的代码。
CODE 系统的奖励机制主要有积分和勋章这两个部分。积分的规则主要就两个：
目的就是鼓励多发 PR。一般来说，小 PR 要好过大 PR，不过有时候开发任务比较紧的时候，发出比较大的 PR 也是在所难免。
勋章系统在 CODE 早期阶段就做了进去，早期的奖励规则主要跟代码提交相关，例如给开源项目发过 Patch 并被 merge 会有相应的徽章。现在 CODE 团队对勋章系统有一些新的规划：
CODE 上没有设置惩罚机制。
相比 Github，CODE 有一些非常实用的地方，比如在提交代码入库之前可以先在 CI 里面完成自动测试，reviewer 可以直接看到代码测试是通过（绿色）还是失败（红色）；代码完成 merge 之后还可以通过 DAE 直接往线上部署。持续集成、自动测试、监控、部署这些都是独立系统，与 CODE 都是靠 API 来进行交互。
对于测试的实现，豆瓣对开发者有明确的要求：
CODE 团队在下面的问答中分享了他们使用 git 的心得和经验，无论对正在使用 git 的团队还是还没有使用 git 的团队都是很好的参考。
InfoQ：你们当时从 SVN、Mercurial 转换到 CODE，这个过程好像还挺顺利的？有没有遇到过一些阻力？如何化解的？
InfoQ：对于 git，CODE 团队有没有特别的经验要分享？
InfoQ：如果现在让你们重新设计 CODE，会在哪些方面做调整和重新的规划？是否会考虑基于类似 GitLab 进行二次开发？
InfoQ：你是否会建议所有还在使用 svn 和 hg 的团队早日脱离苦海、投奔 git？
相关演讲和分享
CODE 相关开源项目列表
CODE 依赖的 Douban 开源库列表
The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.
由WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证。
本文首发于Why·Liam·Blog (https://blog.naaln.com)，版权所有，侵权必究。
本文永久链接：https://blog.naaln.com/2014/03/review-of-watercress-code-two-years/
禅寂，那是一种淡泊明志、宁静致远的境界，一种被古代儒士所推崇的佛教哲学，教人修身、养性、无我的哲理，这理念运用到设计中，就是简洁并让人安静的设计美学。
禅的境界
大道至简，教给人们解惑的道理，都是一些很简单的哲理故事；大象无形，真正有内涵的事物，它的气质是从内散发出来的，而不是刻意靠外表去装饰的。同理，真正好的设计是让你感觉不到设计。无印良品 (Muji) 就是一个很极致简洁的品牌，无印在日文中是没有花纹的意思，日本店名」无印」意为无品牌。然而靠着清一色无华简朴，及还原商品本质的讲究手法，低调的无印良品反而成为闻名世界的」No Brand」(无品牌)。其实有牌无牌已经不重要，虽然极力淡化品牌意识，但它遵循统一设计理念所生产出来的产品无不诠释着「无印良品」的品牌形象，它所倡导的自然、简约、质朴的生活方式也大受品位人士推崇。