你无法拥有所有，你只能学会放弃

最近和儿子学棋的时候，突然感觉到了围棋的放弃。你在落子的时候不可能落下一百个子，最后落下的一个子放弃了其他地方，最后选择了一个位置。因为你不能错过这一次宝贵的机会，所以你会深思熟虑的考虑自己的每一步棋。但在现实生活中，你非常自然的想得到一切东西。工资嫌少、家人嫌烦、开车嫌慢、坐车嫌乱。我也见过一些人无欲，看似则刚，实则如泥。又走入了另一个方向，他们看似视输赢为粪土，其实害怕投入。

人生的棋盘下，对手是你自己的命运。下的每一手棋都是自己意志的使然，是退、是扳、是攻、是守。赢棋有些时候是可欲不可求的，但在纹枰之上的精彩进退是我们可以尝试的。

我只想说的是，在落下一子之前在占领领地的同时，你能接受放弃的内容吗？这是你的风格吗？

当你欠缺对未来的想象的时候

我一般很少摘抄网络的文字，但以下的内容我想永远的保存在我的博客里面。

中国从上世纪八十年代之后，很多人觉得乌托邦思想相当危险或者不太靠谱。但是另一方面如果太过抛弃掉某种乌托邦的想象，而把自己局限在现实之内，我们就会欠缺一种想象未来的能力。当你欠缺对未来的想象的时候，其实就表示你对目前实际生活的投降、缴械。（via:梁文道）

最好的项目

今天吃饭的时候，一个同事跟我说上一个与我合作的项目是他加入的最好的项目。作为那个项目的Team Lead，我当然喜欢听到这样的话，之前也从侧面得到了同样的评价。但使我不安的是我深知那个项目的种种不好，我开始怀疑这“最好的项目”的评价了。或许那真是他们加入过的最好的项目？

估计他也不知道一个肯定的评价会对我造成一连串的思考，但起码或真或假的反应了他的感受。我们太缺少对他人的肯定了，那对自己的肯定呢。虽然有点压力，但我有信心日后我接手的项目，从客户、公司、个人角度看，都是最好的项目。

立字为证

Scrum认证是否可以作为学习敏捷开发的开始?

前几天跟别人聊天，谈到敏捷总是谈到Scrum，并且问我是否获得认证。我表示了对敏捷认证的抵触，他认为Scrum认证是学习敏捷的一个开始。当时这个话题没有继续，但我相信有这种想法的人不在少数。但这是否正确呢？虽然我不是Scrum的专家，但我想尝试探讨一下这个问题，让我们从头开始吧。

首先，什么是敏捷呢？

敏捷 Agile最初来源于拉丁词根ag, agi, agit, act也就是to lead, to drive, to do的意思。这让我想起了对立面的一些词汇：跟随，静止。翻阅词典之后发现，agile本身有三种解释：1，快速且协调运动。2，积极的，有活力的。3，思维快速。但是这种行动来自何方？是什么使你有做的动力呢？ 是勇气。想象一下失去勇气的你在什么情况下才能做出行动。在勇气之前呢？那就是一颗勇于面对变化，且积极的心。

那什么是Scrum呢？

来自Wikipedia的解释是

“Scrum is a process skeleton which contains sets of practices and predefined roles.”

Scrum就是一个包含一些内容的过程。这个过程框架给出一些实践与预定义角色可供使用者进行剪裁并形成适合使用者的过程。它定义了过程中的角色、会议与工件(Product backlog, Sprint backlog, Burn down)。

我们再回过头来说说敏捷开发，最能够诠释敏捷开发的是敏捷宣言了。接下来我们将回顾一下经典并且尝试比较一下Scrum，这里需要注意的是 over 后面的内容敏捷不是认为它没有价值，而是前面的价值更多。

• 个体与交互 over 过程与工具
  • Scrum是一个过程的框架，虽然在过程的角度上尽可能的保证交互，但过程缺乏对个体的关注。这让我想起了CMMI，同样的关心过程、同样的宣称可以剪裁、同样的实施认证。如此一来过程的还是过程，套路不同而已，且多了噱头；关心交付的还是关心交付，对大家的考核框架根本没有涉及。总结起来就是，Scrum对过程和工具有所涉及，对个体与交互只是在过程中进行体现。
• 可以工作的软件 over 面面俱到的文档
  • Scrum定义了一些工件( Artifacts)，在中文版本的wiki中更是直接翻译成了“文档”，如果一个过程能够保证可工作的软件的话，那CMM早就可以了。“可工作的软件”这句话在我看来是敏捷开发宣言中最重要的一句话，也就是说敏捷更关心交付，但Scrum只是在精神层面上给我们暗示了方向。拿到认证的人们是否感受到这种暗示呢？对于代码来说隐性的东西是会受到批判的，因为如果你认为什么东西是好的，就应该显性的表示出来，不能让后来看代码的人有错误的想法。使用过程来实现敏捷价值观简直就是隔靴搔痒。
• 客户协作 over 合同谈判
  • 对于这项Scrum规定了客户建议扮演的角色和在过程中应该承担的责任。最有意思的是那个火腿鸡蛋的比喻，Stakeholders (customers, vendors)作为鸡的角色进入项目，试想一下如果用户不能积极参与项目的话，何谈交付。
• 响应变化 over 遵循计划
  • 说到遵循计划与响应变化，我就想起了一个朋友跟我说起的一个段子。他说：你听说过Scrum吗？你肯定没有见过这么烂的软件开发方法论。举个例子来说，比如一个足球游戏，突然在足球场上发现了两个足球，整个项目组还需要等一个月才能着手修正这个问题。当时我很无语，我也不知道这是Scrum的问题还是使用者本身的问题（当然肯定不是方法论的问题;-）。但若干年前我们使用CMM不就是这个样子吗？

说到最后，我还是对敏捷认证保留意见。首先你拿Scrum认证的目的是什么？如果为了更好的软件过程，这个证书又能代表什么？代表你了解了一些过程？还是你嘴中多了一个和别人忽悠的噱头？代表你愿意学习敏捷的意愿？还是职业生涯的又一个资本？

我们为了制造出更好的软件已经学习了太多太多的东西了，而在学习的过程我们在不停充实自己的过程中是否还记得我们最初的初衷？我们是不是应该尝试丢弃一些过程？丢弃一些实践？丢弃一些角色？丢弃一些会议？看看我们是不是还能做出好的软件。认证就类似一门考试，我们在追求考试的过程是不是这本身就不够敏捷？我们是不是想要的太多了？一方面要做好软件，一方面自己要紧跟时代的步伐，一方面要为自己的职业生涯添砖加瓦……

任何一种事物都在于我们对它的理解，从而产生巨大的不同。就如同小时候看到糖果的我，我会对它产生心理上的冲动，不光因为它的味道，父母的严令禁止也是原因之一，直接导致的结果就是牙齿的问题。对于Scrum来说，技术层面上讲我没有任何意见。但它的推广过程中所采取的方式，有可能会对结果造成影响。尽管它可能很火，尽管市场份额可能很大，尽管它可能成为潮流。

引用我一个朋友列出的敏捷学习过程，需要重点指出的是，他把Scrum的学习放在了第一步：

• 过程的敏捷（学习并尝试敏捷的套路）
• 痛苦的敏捷（学习并尝试与代码相关的敏捷实践）
• 真正的敏捷（学习并尝试实现敏捷深层次的价值）

最后，我相信 法无四乘。人心自有等差。不在乎套路也不在乎门派，关键在于内心。

ubuntu mysql 编码/乱码 问题

看了很多文章都不能解决问题，最后还是找到解决方案。回想一下，只需要几步：

第一步，进入mysql，键入命令”\s”查看下面两项是不是显示utf8

Client characterset: utf8
Server characterset: utf8

第二步，编辑 /etc/mysql/my.cnf 的[client]下面增加loose-default-character-set=utf8 ，如下

[client]
loose-default-character-set=utf8

重启mysql之后再检查char set是否已经设置成功，关键是前面增加一个loose-的前缀折腾了很长时间。

可以参考：
http://dev.mysql.com/doc/refman/5.0/en/option-files.html

我和我追逐的梦

Coding已久
在每个项目只能稍作停留
喜乐和哀愁今生不能由我
任Build带我停停走走
孤独依旧
多希望你能理解Technical debt的痛苦
却不愿痴心得到你的温柔
IPM之中装作冷漠
泪不敢流
让Story牵引着我南北西东
看功能模块悲欢离合难分难舍
而谁在为code重构
我和我追逐的梦擦肩而过
永远也不能重逢
我和我追逐的梦一再错过
只留下我独自寂寞
却不敢回头

我们的程序员素质难道真的不如以前？

当和一些朋友聊天的时候，经常会谈起现在的程序员的素质。朋友感叹道现在的程序员做完程序测试都不测试，发现一堆错误；做一个功能不动脑子想想到底有没有更佳的解决方案；对新技术跟进的主动性太差，诸如此类。又说道想当年的程序员是多么的细致、善于思考而且专业。感叹啊……感叹啊……。当然我的这些朋友大都已经不在开发工作岗位上，而是在管理工作岗位上。每次说到这些内容的时候我一般比较沉默。我在想难道程序员的素质真不如以前的前辈吗？

我不否认程序员个人能力的不同会影响最终的工作效果。但对于这个问题我们需要再认真的分析一下：

我们先回到对程序员评价的标准上，对程序员的要求到底是什么？我认为上面提到的种种程序员的问题是传递商业价值的过程中暴露出来的。也就是说用户在使用或配合建造软件的过程中发现问题才会间接反应程序员的问题。这里把测试部门的测试也当成用户的使用，因为在测试过程中发现的问题一样要拿到程序员的手中返工或改正，这也是浪费金钱的一种方式。总之我们考核程序员是传递商业价值效果的考核。我们列表对比现在和过去的细节情况：

这里需要说明一下的是，在过去IT部门的人员很少所以人员的考核是在整个IT部门的范围内考核程序员的绩效情况。现在的情况是由于职责划分，原来的开发部门分解为若干业务单元。比如专门负责需求的需求业务单元、负责测试的测试业务单元、负责后期维护的运行维护业务单元等等。试想一下，如果传递商业价值已经不作为考核的一部分，取而代之的是你写了多少行代码或者是否听话的干活。反正换了我，我也会对本业务单元负责的，毕竟工资是这么来的。

我们再比较一下过去和现在在团队上的区别：

对于团队上的区别和企业的IT信息化需求是紧密相联系的。在过去企业还处在努力实现人手一台计算机的阶段，精力大部分放在硬件或系统部分。但是现在随着软件系统需求的爆炸式增长，人员不可避免的增多。但在软件项目疯狂吸取人员资源的过程中，领导往往忙于应对人员的调配和各自业务单元利益当中。大家可能都没有发现：高质量的骨干人员出现断档，而且缺口越来越大……

技术也是非常关键的因素之一，我们来看看过去和现在的对比：

显而易见，我们现在面对的技术和过去面对的技术从信息来源、厂商数量、平台数量、需求层次都已经不能同日而语了。如果说原来客户吃稀饭加咸菜就算一顿好的早点的话，现在的客户你不给他做出，西式、广式、粤式、川式的早点就算你失职。

总结上面的内容，我认为考核方式是致命的。如果选择一种适当的考核方式会促进IT人员的努力。反之会抹杀IT人员的创造力。有一句话是：如果你期望得到一堆搬砖头的程序员，那么你就会得到一堆会搬砖头的程序员。

350公里的速度

春节前看望老同事，老同事看着我的一身打扮奇怪的说：你是去爬山吗？为何身穿冲锋衣？这确实是一个好问题，我确实最近全部是穿着冲锋衣脚踏旅游鞋。回到家中仔细回味这个问题，我发现我找到了答案……

我每一次离开家，离开亲爱的老婆和儿子，我感觉我一次又一次的出发，向着我的目标更进一步。从心情上这无异于一次野外的跋涉，我时刻提醒自己，路上
的风雨、同行的旅伴、精彩的景色都会过去。就像我媳妇的经典签名一样：我必归来，与你同在。当然在我这里的话就得更改为：我必归来，与你们同在。身穿冲锋
衣，让我感觉更能与我每一次出行的心情相吻合。如果你还不能理解的话，想像一下下面的场景：

一个冬天的凌晨5点25分，匆忙脚步之后，猛地推开楼门，天上繁星闪烁吸引了我的注意……太美了，欣赏若干秒后踏上了160多公里的上班之路……

一个平常的下班时间，穿插在那北京地铁汹涌的人流中，抢上那南三环拥挤的出租车，支付那15块永远不变的车费，欣赏那每一次看到都激动不已的北京南站，激动那我是以350公里的速度奔向家人的身边……

儿子每天早上都沉浸在冲向家长被窝时的感觉，我也沉浸在那350公里的速度中……

一个不合格的父亲

从大连医院的病床旁回到家中感觉自己在为了很多人活着，晚上儿子问我要是赶不上去北京的火车会怎样？我说就赶下班。他继续问：要是下班也没有赶上
呢？我说我就开车去。他：车坏了呢？我：…………我说爸爸想陪着你们娘俩，天天在一起，早上送你上学，晚上接你回家……但是爸爸也有理想，就如同你也有去
达喀尔开拉力赛的理想一样，但是追求一些事情的时候就要放弃一些其他的事情……爸爸会尽可能的多陪你们，再过6-7天爸爸就和你们待7天，这7天你不用去
幼儿园，咱们天天在一起……现在睡觉吧……

感觉实在是不能解释太多，因为本身就对不起家人。唉……

一个不合格的父亲，实在是很痛苦啊

早上，当你把你的孩子交给幼儿园老师的时候……你看到了微笑

儿子放假了，我估计他自己都不知道放假这个概念。一直去的幼儿园以前也有假期合班，但这次因为幼儿园装修，所以必须找另一个幼儿园解决儿子白天的活
动场所和一日三餐问题。无奈的99爸爸和99妈妈找到另一个幼儿园，硬件设施实在赶不上原先的幼儿园，儿子有时候回家也会抱怨一下：现在的幼儿园太小了。
我听后心里很不好受，一直有种愧疚的感觉。

这几天听说99回到家说：准备去幼儿园是不愿意去，但是一去就高兴了。但让父母最放心的不是儿子到幼儿园之后的感受，而是每次看到老师脸上的微笑——-一种发自内心的微笑。99妈妈说以前幼儿园的老师根本没有这种微笑……

我突然感觉轻松了很多，硬件条件再好又有多少用处呢？指纹识别、教室电话、网上监视系统、占地较大的 活动操场……这一切一切比不上老师对孩子们发自内心的微笑。因为你能从微笑看到她们的心，她们的爱。

我们又是如何面对我们的工作的呢？我们为了坚持不知对错的选择而尝试说服同伴、我们每天10点的开会都还有迟到的队员、我们以技术人员自居而拒绝对
某些问题思考……我们还不如幼儿园中的老师，她们起码能让孩子的父母放心。我们能让我们的客户放心把项目交给咱们吗？咱们对得起客户的孩子吗？

你能想得到当自己把孩子交到老师手上的心情吗？