大事记 把女儿心心哄睡着之后，我躺在她旁边，听着她平稳的呼吸声，心里充满了幸福和感激。女儿降生的那种感动，是无以伦比的，之前的很多事情变得无所谓起来，这当然是我今年最大的收获。
当然，初为人父，有好多好多东西需要学习，她还在月子里的时候，我整理过一次思维导图：
今年也有一些其他的里程碑：
骑行了第一个100公里 学会了驾驶（已经行驶了近6000公里） 学会了抱娃，换尿布，给娃洗澡，试水温等等 《轻量级Web应用开发》被翻译成繁体中文版在台湾发售 Hiking到了秦岭最高点（大爷海，海拔3500m） 学习 今年的大部分时间都不在办公室，在客户现场出差有8-9个月。最大的感受是归属感的缺乏，另外就是大部分时候再输出，会导致积累的存货快要被掏空的感觉。很多知识需要花时间来补充上，咨询工作本身有很大一部分是需要咨询师在非咨询项目上做积累，然后再去输出的。
这一点希望在2017年可以做的更好一些：减少一些出差，多在办公室的项目上工作，然后能有更多的时间来积累自己的知识库。
上半年花了一些时间和设计师唐婉莹合写的《在迭代1之前》，后来出差网络比较封闭的时候，就只有唐婉莹在做更新（频率和质量都很高），我自己的开发部分很久没有改动了，算是一个比较遗憾的地方。2017年希望可以完成其中的烂尾部分。
总体来说，2016年很多时间是做咨询工作，内容比较杂乱。我梳理了一下，大致如下：
一些微小的练习 我的第一个React Natvie应用，感谢傅若愚：
闪电计划的页面局部，感谢张小虫：
Graphviz一个例子：
闪电计划 7月，和另外两个同事组织了一个系列的活动，这个活动旨在通过一系列的刻意练习，包括但不限于：
TDD，Tasking，构建，环境自动化 自动化测试（集成测试，UI测试） 项目中的常见场景（多表关联，异常处理，RESTful API设计） 常见静态页面 一些具体而微的端到端Web项目 闪电计划的另一个副作用是找出了一些前端的Kata，可以供后续的前端们做练习用。我已经找张小虫，李彤欣做过了第一次的实验，证明是一个比较合理的方向。在2017年，可以作为新的Workshop进行。
项目经历 元月份经历了一个史上最奇特的咨询项目：Staffing好的3个人中，有两个离职了……。不过还好，通过两个月的微小工作，客户最终还是比较满意的，也很顺利的有了项目的第二期（虽然由于其他原因，第二期只做了一半）。
其他的经历比较平淡：
在回南天的3月去了一趟广州出差，做了一些前端性能相关的测试。 在最热的7月份去了一趟上海出差，莫名其妙的做了一些前端性能相关的测试，以及React Native的一些预研。 最后在寒冷的12月去了一趟深圳出差，做了一些安全测试（基于OWASP）、依赖关系图（基于Doxygen）等的Spike。 不过总体来看，2016年经历的项目是最多的，而且多样性也很高：
3个咨询项目 3个交付项目 3个售前 其他 应王欢要求，除了一起吃过几次饭之外，今年跟王欢基本上没有交集。倒是多亏了他的脸，在楼下的来福士和他喝了不少次咖啡。
这是九月份去付莹家的黄河时和同事们的合影，第一次开车走高速去那么远的地方，后座还有一个澳洲的客户。
骑行了一半儿，有一群开着车的同事追了上来，跟我们一起吃了个饭，我们骑车回去，他们则开车/坐车回去了。
下项目之后 通常来说，下项目总是一件比较高兴的事（大部分团队还会一起吃个饭庆祝一下）。这里面既有终于摆脱了厌烦了的技术栈的解脱感，也有对新项目/新技术的向往，可能还有些在旧项目中做的不太满意的事情，可以在新项目重头再来的期望。
可能有点老生常谈了，不过这里我想说说下项目后如何做总结的事儿。对上一个项目的总结，其重要程度可能要远远超过你的想象。我是在2014年初，在一个客户现场的一个会议室和一位同事谈我的Annual Review的时候，才意识到这个问题的。
Annual Review会回顾我们过去一年的项目经历，有哪些方面的进步，同时也会展望未来的计划。但是这其中有几个问题：第一个问题是以年为单位的Review粒度太粗，有些经历已经淡忘，也有人可能一年会换好几个项目；第二个问题是对于大多数人来说，展望未来是一件比较容易的事儿，每个人或多或少都会有一些计划（比如学会前端的某些技术，尝试一些DevOps方面的工作，或者了解一下大数据等等）；但是对于回顾过去，我们其实并不擅长；最后一个问题是即使做了回顾，回顾的层次非常浅，作用并不大。
说到回顾过去，更多时候我们关注的是从项目中学到了什么样的新技术，这种浅层次的回忆和记流水帐是容易的，但是对于我们的成长并不会有太大的收益。真正会为帮助我们在将来的项目中做决策，甚至会影响我们学习效率，解决问题能力的是：深度回顾。
深度回顾练习 深度回顾可以帮助我们梳理知识，将实际的案例归纳总结为实际可用的知识。要获得这种能力，需要做一些针对性的练习。根据我自己的经验，这些练习大约可以归为3类，难度依次增加。
项目上的直接经验 这个练习比较简单，就是问问自己：“我在项目里学到了什么？”
要回答这个问题是很容易的，项目中用到的技术如模板引擎，前端框架，自动化测试套件，build工具等等，总结这些内容的过程，对于我们的PS来说都是“自动”发生的，几乎不需要付出额外的efforts。这些回顾、总结可以帮助我们成为一个“熟手”，即当下一次遇到相同或者类似的场景时，我们可以很容易直接应用这些经验。
更进一步，再问问自己在项目中的其他收获。比如客户关系处理的经历，团队建设的经验，甚至是写英文邮件的技巧等等方面，看看做的有没有问题，有没有提升的可能？
人类最牛逼的技能是：可以审视自己的行为。也就是站在旁观者的角度来看待自己的行为，随波逐流式的在各种琐事中沉浮事实上无法得到提升的。可以经常性的将自己置身事外，以一个旁观者的角度来审视自己做过的事情。并从中找出做得好的地方和不足的地方，然后自己给过去的自己一些建议，并记录下来。这些刻意的练习会帮助你养成回顾，从经验中学习的习惯，而这个习惯正是一个人区别于另一个人的绝对“捷径”。
练习讲故事 这个练习是，假想你遇到了一个同一个办公室的同事，他对你刚做完的这个项目很感兴趣，你来给他描述一下这个项目。描述的内容包括但不限于这些方面：
项目的背景介绍 该项目以何种方式，为那些用户，带来了什么样的价值？（business model是什么） 该项目的实际用户数量是什么级别？ 项目的部署，运维是如何操作的？ 项目的监控是怎样做的？ 当遇到系统故障，项目组是如何反应的？ 能把一件事情描述清楚是一件非常了不起的能力。我见过很多的程序员，写起代码来好不含糊，但是却很难将一件简单的事情讲清楚。我们当然要提防那些夸夸其谈，华而不实的“嘴子”，但是也至少得要求自己做到清晰，准确的将自己经历过的事情描述清楚。
描述项目背景需要至少需要交代这样一些内容：客户是谁，最终的消费者是谁，项目以何种方式运作（离岸交付，本地，onsite，咨询，培训等），我们帮助客户为消费者带来了什么样的价值。客户的商业模式是什么，在我们周围有哪些类似的项目。
即使在技术方面，也有很多被Dev忽略掉的信息，比如项目在产品环境中如何部署，数据中心建在何处，客户如何运维、监控等。实际的发布周期如何，发布流程如何，客户的内部论坛上都会有很多的这样的信息，但是很少有人关注。从一个项目roll off的时候，这些信息即使做不到了若指掌，至少也能描述清楚，否则难免有些“入宝山而空回”的遗憾。
回顾项目中的挑战 从简单的CRUD系统，到复杂的分布式计算，从企业内部的管理系统，到支持高并发、要求实时处理的交易平台，每个项目都会遇到一些挑战。除了技术上的挑战之外，还有陈旧而无文档的代码库，复杂的业务场景，不配和的客户接口人等等。挑战无处不在，那么作为项目中的一员，你是如何应对这些挑战的呢？最后又是如何解决的？
现实世界是一个充满了trade off的世界，我们需要做种种权衡，代码测试覆盖率和交付压力，性能和客户能负担的机器实例数量，框架A和框架B的优劣等等。我们在采取这个方案的时候，只能舍弃其他方案，由于谁也无法在事先准确预料采取某个方案一定是对的，那么在一个失败的方案背后，其实也是一个很好的教训，至少可以为未来的决策提供帮助。
遇到的最大的挑战是什么？ 这个挑战是如何被解决的？ 如果有机会重做，你会如何考虑？ 其他练习 这里列出了一些我常用的，辅助性的练习。它们可以帮助你更好的梳理项目上学到的技能、知识，并且转换成你自己的知识。这些练习未必一定要等到项目结束之后才做，事实上它们都可以应用在日常的工作中。
记笔记 写博客 在办公室内演讲 去社区贡献话题 很多人都会记笔记，但只有一小部分的人在记录之后会持续翻阅。很多人会使用Evernote/印象笔记之类的工具将一些临时的想法，问题的思路，知识点的细节等记录下来，但是仅仅记录是不够的，笔记需要不断的检索、整理、提炼、修正、总结和归纳。在不断的加工之后，这些笔记可能会得到沉淀，并升华形成一些更有意义的内容（比如个人博客，或者可以发表到InfoQ/IBM DeveloperWorks平台上的文章等）。
除了记录笔记之外，写博客也是一种很好的总结形式。通过将素材不断充实、整理、完善，最终形成一个可供别人直接消费的文章，不但可以锻炼到总结能力，还可以很好的提升表达能力，而且可以帮助你将已有的知识体系化。如果你的博客写成了系列，也很容易通过Gitbook等将其发布为一本电子书，从而影响更多人（说不定还可以赚点咖啡钱）。
写博客/电子书，终究是书面形式的。事实上一个人可以很容易的通过文字将自己的实际情况隐藏起来。举个极端的例子：如果有足够的动机（比如公司的KPI要求），即使不熟悉某种语言/工具，仅仅通过Google，一个人也可以通过这种“作弊”的方式写出一篇“专家级”的文章。但是对于演讲这种面对面的形式，则基本上无法作弊，从而也更具有挑战性。另一方面，对于一个新的知识、技能，自己掌握是一回事儿，要讲出来让别人也能听懂，并从中收益，则完全是另外一回事儿。作为咨询师，语言表达（包括书面和演讲）能力的重要性勿庸赘言。整理知识，并归纳为演讲，会帮助你将体系化后的知识更好的表达出来。
在办公室里讲session有一定的挑战，但受众毕竟是“自己人”，压力相对会小一些（比如在ThoughtWorks，我们非常鼓励员工为其他人讲session，具体可以参看我的这篇文章）。要在社区中演讲则要面临更大的挑战，通过将话题不断锤炼，不断归纳，最终形成可以在社区分享的话题，则不但可以提高内容的质量，也可以更好的锻炼表达能力和临场应变能力。
不过归根结底，这些活动的重要输入还是对之前项目中的知识、经历的深度回顾。
总结 从项目上下来之后，需要深入思考并总结之前的经验，这种深入思考会帮助你建立比较完整的知识体系，也可以让你在下一项目中更加得心应手，举一反三。如果只是蜻蜓点水般的“经历”了若干个项目，而不进行深入的总结和思考，相当于把相同的项目用不同的技术栈做了很多遍一样，那和我们平时所痛恨的重复代码又有什么不同呢？
2015年总结 2015年在不经意间就过去了。又是一年。按照惯例，我会在年末回顾一下这一年自己的进步，收获以及一些感慨（牢骚）。然后对来年做一点展望，看看什么地方可以做的更好。
项目经历 今年基本上经历了三个项目，性质也都不一样：
海外交付 国内交付 国内售前 3月前的项目以及没有什么印象了，依稀觉得项目上的所有实践都是“错”的，可能由于太过与荒诞，所以大脑自行将这段抹去了。
4月到6月在深圳的一个国内交付项目上，交付压力还挺大。不过也是在这个项目上，非常直接的体会到了其他角色的不容易。无论是客户的接口人，客户的项目经理，客户的领导，我们的开发，我们的UX，项目经理，还有交付的lead，所有人都不容易。
《项目经理是大傻逼吗》这篇文章就是为了纪念这个项目，或者说是被这个项目驱动出来的。
6月之后回到办公室，在一个海外交付项目上。说是一个项目，中间其实换了6，7个不同的工作内容（出钱的是同一个客户而已）。总之一片混乱，所幸我们在10月前就结束了和这个客户的合作。这个项目事实上除了锻炼项目上人的耐心外，基本毫无益处。甚至对于很多毕业生来说，是深刻的伤害。
10月之后，我难得的在beach上待了下来，而且一待就是3个月。中间在一个联合国的项目上工作了2周，然后就是为另外一个咨询项目准备了几周方案。当然，闲是不可能闲着的。在beach上，如果不出意外，肯定会比项目上更忙！比如打黑工啊，内部什么系统的改进啊，总是有好多事情。
由于有一些本地的项目机会，而我又不在具体项目上，就来做这个售前的角色。帮助客户梳理需求，分析问题，设计方案，计算工作量等等。但是这个过程往往循环往复，一轮接着一轮，在合同确认之前，需要很多次讨论和交流。这应该不会是我自己的一个方向，在项目上写代码，培养新人，分享自己的学习所得，和他人一起进步，是我自己比较有热情的方向。
技术方面 在海外交付项目上，乏善足陈，项目中用到的也是非常厚重，已经至少10年的技术。通常来看，这样的大组织，没有人对要做的事情真正关心。好不容易遇到一个特别靠谱的人，结果我们的项目又结束了。国内项目上倒是有很多有意思的东西：
如何在前端代码中很好的使用MVC 流畅的前端开发模式 如何做前端的测试 上面这三点，我希望可以找时间整理出一本电子书，可以让没有工程级做过项目的前端工程师能有一个参考。
另一方面，由于项目的压力，和项目人员的特殊性（开发就俩人，一个做前端，一个做后端，要集成就pair一下），所以很多实践都没有应用，比如结对，自动化测试等，做的都不够好。虽然我们很推崇，强调CI/CD的实践，但是当和客户的后端系统集成时，就各种悲剧。
联合国的项目上，技术栈比较新颖，上一家的技术人员使用了他们当时能找到的所有酷炫的新技术，并用在了项目中，然后他们公司被收购。留给我们的在今年来看，依然是比较新的：
React Reflux ES6 mocha/chai 而在国内售前，基本上没有写过一行代码，更多是更高层次（高不一定是好哦）的工作。确认需求，估算工作量，确定方案（前后端测试，开发方式，部署策略，自动化测试等等）。
2016年，我希望可以多学习一些具体的编程知识，比如：
mongodb 数据分析，数据挖掘 容器技术如docker 书籍 今年读了一些技术方面的书，更多的则是一些非技术类的。《自私的基因》是在2012年11月去墨尔本时，在广州白云机场买的，路上10个小时，读了几页。直到2015年才又拿起来，读了两章左右，基本上颠覆了我之前建立的对“进化论”的认识。
另外读了一些科普类的，比如《哲学家在干了些什么》，《上帝掷骰子吗》等，又扫了一次盲。再就是一些佛教相关的书籍，《西藏生死书》，《能断：金刚经》，《正见》等，人生观和价值观得到了刷新。
技术类的，主要是一些与具体技术关系不太大的，比如《恰如其分的软件架构》，《企业级应用架构模式》，《发布！》，《实例化需求》，《持续发布》之类。
虽然竣工于2014年，但是我的一本著作和一本译作都是2015年才发布出来，那就算作2015年的吧：
《轻量级Web应用开发》 《7周7Web框架》 社区 今年在深圳的时候，有幸和ThoughtWorks的首席科学家马丁.福勒在同一次活动中作为讲师。
回到西安之后，在本地社区中还讲过一个前端工程师需要掌握的技能列表的session
2016年希望可以做一些更加深入的topic，以及一些更有意思，可以帮助到更多已经在路上的工程师们。
People Development 这个不知道如何翻译了，但是确实做了一些具体的事情：
给我的sponsee们安排了读书会 组织了一次《编写可维护的JavaScript》的workshop 组织sponsee来做一个side project 组织《Web开发实战》的workshop 我自己总结出来了一套组织workshop的方式，其实很简单：
做好计划，做好课表，做好课件 找学员，同时从学员里找出有基础，而且有意愿接着run workshop的人 讲课，收集feedback，并改进课表，课件 将run workshop的任务传递给那些有基础，而且有意愿接着run workshop的人 2016年希望可以找到更多的候选人，并帮助他们成为更好的讲师，教练。...
ThoughtWorks内部培训 对新人的培训是每个企业都绕不开的一个话题，企业当然想要每个新人都能直接独当一面，最好可以直接上项目贡献自己的价值。但是从经验来看，所有新人到一个新环境都需要学习很多不同的新东西（新技术，框架，语言，工作方式等等），而每个企业对于培训新人都有各种各样的策略，比如老人带新人，比如扔到项目上让新人自己学。
在ThoughtWorks，我们有着丰富的培训方式，有面向社招的，有面向毕业生的，有民间自发的，有官方组织的，有内部的，也有面向社区的。
TWU TWU全称ThoughtWorks University，面向毕业生，入职之后的第一堂课。TWU的地点设在印度，之前在班加罗尔，后来改到了普内。每一期5周，学生们需要和和全球其他国家地区的同学一起，一般会尽量将各个地区的学生打乱安排，尽量让学生体会多元化的文化，培训内容设计公司文化，软件开发方法论，敏捷开发（Project SImulation）实践等，同时还需要保证学生有足够的代码练习机会。
我在2013年作为讲师参加了一起TWU，对我自己的帮助也非常大，在和来自不同地区的讲师一起备课，学习中学习到了很多的东西，之前似是而非的一些概念也得到了纠正。
TWI TWI全称ThoughtWorks Immersion，面向有经验的社招同事，主要涉及的内容为公司文化（合作，沟通），专业服务（如何专业的解决客户的问题），软件开发流程，敏捷开发方法论等。
我在2012年时参加过TWI，并整理了几篇相关文章，可以参考这里，这里还有这里。
Session Office局限在ThoughtWorks办公室之内，内容随意，参加不参加随意，可以随时加入或随时离开。虽然内容没有限制，但是大多数时候分享的都是技术主题。比如自动化部署，自动测试，Spring 4，Ruby中的构建工具等等。
Sessoin的形式是主讲者找一个自己感兴趣的主题，一个人讲，其他参与者听，鼓励互动。时间一般控制在一个小时以内，所以一般选择在中午饭的时候，有的session会给大家订饭，一边吃一边听。
虽然大部分Sessoin的主题是技术相关的，但是并不局限于此。比如旅游见闻，历史，财务，摄影等等，都可以分享，有时候这些趣味性的Session的参与者更多。
WorkShop Office之内，内容随意，以动手为主，讲解为辅。
HTML/CSS Testable JavaScript 设计工作坊 OO BootCamp Ruby BootCamp 一般来说，Workshop都会组成一个系列，通常会占用几天到几周不等。参与者需要带上电脑，在课堂上进行练习之外，课后还会有一些练习。
3周3页面和可测试的JavaScript是我去年做的两个Workshop。由于Workshop会在下班后或者中午的休息时间，公司会为每个参与者订饭，以节省时间。
郑大晔校 面向刚刚得到offer的毕业生，在上项目之前，我们希望学生的基本技术达到特定的水平，因此设置了一系列的练习。包括
编程基础 开发流程 工作方式 公司文化 等等。郑大晔校的周期为每周一次，一次一天。涉及的内容会与大多数项目上的要求一致，比如西安office的Java/Ruby项目居多，我们的课程安排就会涉及到Java/Ruby方面。当然，各种软技能如工作方式也会在课程中涉及，尽量的寓教于乐。
每期郑大晔校大概会有10周，学生入职之后有的会直接去TWU，有的则会在项目上工作一段时间再去TWU。
组内培训 各个组内自行组织，并不要求其他同事参加。比如某个项目需要一些docker的知识，或者需要AngularJS相关的培训，一方面是找自己组内的专家组织一次内部培训，，另一种是找办公室内相关的专家来进行培训，形式比较灵活。
项目中已经在使用的技术 项目中将要使用的技术 请别的组的专家来咨询 社区 OpenParty Rails Girl 问题 谁当讲师 活动经费 内容如何持久化（人，内部知识分享系统） 如何保证效果（宽松） 由于对任何的话题都没有限制，也没有对参与者的限制，因此任何人只要感兴趣都可以作为讲师。而又由于没有任何的强制措施，参与者和主讲者都凭着自己的热情来组织，这也算是比较独树一帜的事情。
而关于内容的持久化，更多的是为参与者打开一扇新的窗户，或者说洒下一些火星，而至于火星如何形成燎原之势，则完全在参与者自己的自觉。好多次和客户分享了我们的培训机制之后，被问到最多的问题是如何强迫参与者产生热情？
这个问题在ThoughtWorks不是问题，我们在一个人进入公司的最开始，也就是面试的时候，就考察了他的热情，如果在热情上有缺陷，则很可能会直接拒掉，免得破坏我们好不容易构建起来的学习氛围。
依照惯例，我每年在元旦时候都会写一篇回顾，总结过去，展望未来。不过很少跟上一年指定的计划真正去比较，一般都是列举一下这一年做的事情。
大致分下来，可以分为上半年和下半年两部分，这当然不是废话。因为上半年和下半年分别在两个完全不同的项目上工作。
技术咨询项目 上半年在一个国内咨询项目上，主要做的事情有（其实我是作为前端专家加入的，不过后来工作重心发生了改变）：
GIS平台 大数据平台 关于GIS最后的产出是一系列博客，而且还在InfoQ上发表了一篇。
而后来我又根据我iPhone上照片的经纬度信息，汇总出了一个热力图（使用QGis）：
大数据相关的所有东西都在我的gist上，还没有时间整理。
硬件 回到办公室之后，发现了硬件小组提供的一大堆有意思的工具和器件，包括3D打印机，Arduino的一些芯片等，为了纪念我的GIS项目，我还打印了一个瓦片：
不断将我拖延了4年的机器小车组装了起来，而且还使用舵机，蓝牙，超声波等模块制作了一个实际的雷达：
Sessions & Workshop 5月底回到办公室后，我发现Office的气氛其实比我来的时候低落了很多，ThoughtWorks的感觉非常淡了。
一方面是新人太多，而来新的项目所在的11楼由于客户的关系（我自以为），同事们的积极性极低。一个最容易看到的信号就是Session变得很少，我尝试做一些改变。
分别做了一些关于自动化测试，JavaScript方面的Session和Workshop，下面是《可测试的JavaScript》的Workshop。这是我第一次组织比较大的，而且时间比较长的Workshop。
有了上一次的Feedback，在年底的时候，我又组织了一次为期3周的Workshop，受众更是扩大到了各种角色，包括BA，UX，UIDev，QA等等。
写作 今年的博客数量减少了，一个原因是我在编写我的第二本书《轻量级Web应用开发》，经过几个月的坚持和努力，这本书已经编写完成，应该会在明年(2015年)年初与读者见面。
另外，在休年假的时候（3周3页面之后），我将Workshop的内容做了整理，并加入了一些设计相关的内容，形成了一本电子书，名为《3 web designs in 3 weeks》。
其他 我正在努力的向UX角色的转变，所谓千里之行，始于足下。我在休年假期间，买了一大堆UX相关的书籍。目前正在努力学习画画：
在今天的CST的创新课上，我们一起设想了几个场景，下面是我自己画的图：
最后是一张我自己设计的自己的名片：
希望来年可以在自己努力的路上看到一些成果吧。