IT牛人博客聚合

十多年前刚走入社会工作的时候，那时的中国软件开发根本没有什么版本管理，也没有什么编程规范，软件开发相比起今天来说非常地混乱，那时仅凭自己的一些学习总结了一些C语言编程中的好的小笔记，后来，这些笔记写成了一篇叫《编程修养》的文章。今天，又有些感触，想把这个话题扩大一下，从“个人修养”扩大到“环境保护”，所谓，穷则独善其身，富则达济天下，今天的技术人员比十多年前在技术和环境上都富有了许多，所以，也应该或多或少地担负起“达济天下”的责任了。

环境保护说白了就是保护一个良好的环境，为好的环境添砖加瓦，与破坏环境的人和事做斗争。其实，从技术人员来说，我们可以做一些力所能及的事。因为我们身边的技术环境还有很大的改善的空间，而一些来之不易的东西

查看全文: http://www.udpwork.com/item/7187.html

【感谢 @风枫峰 投递本文】

故事一：

背景介绍：RT是一个外包公司，ZWZX是项目承接公司，YD是甲方。

RT公司每天下班的时候都会接到ZWZX负责人的电话，询问一天的工作情况，然后布置任务要求晚上加班做完，RT公司的员工很无奈也很气愤因为每天都要加班，员工们就问项目经理：“为什么天天加班赶需求，今天才提一个需求，明天就要上线，还让不让人活了?” 项目经理无奈的说：“我有什么办法啊？这是人家ZWZX负责人说的啊，对方逼得紧。”

多次以后项目经理也忍不住了，就问ZWZX的负责人怎么天天这样啊，ZWZX的负责人就说了:”明天就要向YD的负责人展示这个页面，我也没有办法啊？YD那边老总就是这么要求的，我怎么办，我也不想这样啊？”

查看全文: http://www.udpwork.com/item/7133.html

面试过一些应聘者，当我问到为什么换工作的时候，他们都会告诉我，现在的工作没有挑战，无聊，所以想换一个有挑战的工作。于是我问了一下他的工作情况，发现那些有挑战的东西他还没有搞懂。我总是为有这样的认识的朋友感到惋惜，因为我总是认为有挑战的东西无处不在啊，不能因为工作上没有，自己就放纵了自己。比如，面试过一个做地图的工程师，他的工作是做计算地图上任意两点的最短或最优路径的一部分功能。我觉得这个事很有挑战，也有难度，应聘者说，没什么挑战，因为他做的东西只是调用相关的算法库。他在这个项目干了2年了，当我问他有没有看过算法库，知不知道地图是怎么存储的？他却告诉我，因为没有去做，所以就没有去了解，等做的时候再了解（我希望有这样想法的人都去看看程序

查看全文: http://www.udpwork.com/item/7126.html

这个文章必然是有争议的，我在我的微博上讨论过很多次了，每次都是很有争议的。有不同的观点，有争论总是一件好事，这样可以引发大家的思考。所以，对于我的这篇博文，如果你赞同我的观点，我会感到高兴，如果你会去认真地深入思考，我也会高兴，如果你反对，没关系，可以讨论。

在此之前，我想说明一下我观点里的这个“专职QA”是怎么定义的。

其是很多公司成立的专门做测试的技术人员，仅测试不开发。

这些QA对于软件开发技术并不熟悉，甚至不懂。

我经历过一些公司都有专职的QA团队（专职的测试人员），自从上个公司我的开发团队在一个项目上被QA部门搞得一团糟，我越来越怀疑专职QA存在在意义。我的观点不一定对，但请让我鲜明地表达一下——我觉得是不需要全职

查看全文: http://www.udpwork.com/item/7104.html

相对于英文而言，中文在计算机处理方面有个必须要面对的问题就是中文分词，英文的单词都是空格间隔的，而中文的词语则不同，所以用程序解决中文分词，在很多自然语言处理方面都是首要进行的步骤。

其中最简单的就是最大匹配的中文分词了，比如“今天天气不错”可以分词为“今天/天气/不错”，但是面对一些有歧义的句子时却显得捉襟见肘，于是“南京市长江大桥”就会被分成“南京市长/江/大桥”而不是“南京市/长江/大桥”，于是更好的是基于统计学原理的分词，也就是说看哪种出现的频率更高。
对于一个中文字符串“a1a2a3...an”如何正确的用词语c1,c2..cm表示就是中文分词的任务，也就是说我们要去找寻P(c1c2..cm)最大的分词，按照马尔科夫链

查看全文: http://www.udpwork.com/item/7003.html

Bret Victor（简历） – 苹果公司的UI交互设计师（大神级的人），在 CUSEC（Canadian University Software Engineering Conference） 上做了一个题为 “Inventing on Principle” 的演讲（vimeo视频链接），这个演讲中展示了五个示例：

用程序画树。如何把程序绘图变成实时的，如何把程序和图映射起来。

游戏调试。在实时编程的基础上，可以更容易的让你看到程序参数对游戏的调整，甚至对游戏过程的可视化调试。

算法调试。在写二分查找算法时可以实时看到程序的执行过程。边写边看到。

电路图。可以实时地看到电路图中各个部件的对1/0信号的处理。

查看全文: http://www.udpwork.com/item/6965.html

酷壳好久没有发娱乐性质的技术文章了，搞得气氛有点严肃了，考虑到程序员们都是比较严肃和容易较真的类书呆子的群体，所以，需要更新一个有娱乐性质的文章了。正好最近看到了两个比较有趣的图，在新浪微博上都得到了比较不错的反响，因此，更新到酷壳上来。

如果编程语言是一种刀

下面这个图是把编程语言看做是一种刀，那么会是什么样的。这个图我个人感觉很有意思。

对于这个图，最好不要解释，意会就好。不过，我却有点想不解风情，忍不住想解释一下。

C++，C，Pascal 都是瑞士军刀，说明是用来做细活的工具。C语言的刀上有个USB，说明是可以做硬件操作的。C++的刀是什么都有，说明C++是一种功能繁多的语言。（图中C++的那把瑞士军刀很强大，不要以

查看全文: http://www.udpwork.com/item/6869.html

自从上次写了“程序员技术练级攻略” 以来，就觉得似乎还有很多东西没有谈到，但当时没有继续思考了。而春节前有人问我，是做底层技术，还是做业务。这问题让我思考了很多，不由自主地回顾了一 下我这十多年的软件开发经历，并顺着整理分类了一下自己解决过的若干问题，还发散想了很多，经过了一个春节假期的发酵，产生了下面这篇文章。

前言

这篇文章必然是通过我的个人经历来写的。所以，我先说说个人经历吧。我的经历基本分成三个阶段。

第一阶段：我 刚毕业时在家乡的某银行工作，做些银行的业务系统，还搞些网络，电子邮件系统，OA什么的，因为大四的时候在老师的公司里实习，银行里的人际关系太复杂， 而且技术都包给了产商，所以在银行的每一天都觉得不能适应里面的

查看全文: http://www.udpwork.com/item/6759.html

每天都有天才去世，只是获得的关注不一样。乔布斯的去世举世关注。而天才少女Arfa Karim Randhawa的去世则没多少人知道。Arfa Karim Randhawa是最年轻的微软认证专家，9岁便获得资格认证。可惜的是，16岁去世了。

“If you want to do something big in your life, you must remember that shyness is only the mind,” she said. “If you think shy, you act shy. If you think confident you act confident.

查看全文: http://www.udpwork.com/item/6729.html

今天为了解释某个问题而提到协变和逆变，发现每次解释这两个概念都会忘掉它们的本质，然后要重新看看定义，重新消化一下才能说明白。所以我决定把自己对协变和逆变的理解写下来，以免将来再次忘掉。
我知道 .NET 的用户喜欢用 delegate TResult Func<in T, out TResult>(T arg); 来解释协变逆变，我则喜欢把 Func 的签名简写为 Haskell 签名形式。也就是说，把 Func<T, TResult> 写成 f :: a -> b 的形式；把 Func<T1, T2, Result> 写成 f :: a -> b -> c 的形式。
其实无论是

查看全文: http://www.udpwork.com/item/6694.html

常在河边走哪能不湿脚，写程序没有遇到bug那是不可能的。内核菜鸟写代码，出个kernel oops那更是家常便饭。

从我目前遇到的各种oops来看，debug首先要检验能否稳定重现bug。

若不能稳定重现（触发条件不一，Oops信息不一），那么恭喜了，基本是出现竞态了。这种问题可大可小，当然最后的问题肯定是在自己的代码里面的（前提是其他模块都是稳定的）。这个时候当然是得先把code path都走一遍，检查是不是逻辑有问题；之后就是检查各种锁了。

若能稳定重现，那么相对好办点。慢慢用printk定位到出问题的语句就可以了。objdump反汇编一下，配合oops里面的stack trace信息看看大概是哪个语句出问题了，不过个人觉

查看全文: http://www.udpwork.com/item/6662.html

女程序员是程序员里美丽的风景线，我希望这些女程序员的经历能让我们在这个“重男轻女”的社会中可以给女程员有更多平等的机会和条件，以及相应的尊重。因为，她们其中不乏优秀的程序员，而且在心态、态度和努力上还强过很多男性程序员，很多东西都值得我们大家向她们学习。

这篇文章的来由是因为Eva在“三个事和三个问题”的评论里问我女孩子是否能做技术，她说她的很多师兄都告诉他不要做技术，所以，她有些不坚定了。我的回复是告诉了她我工作经历中的两个技术很牛的女孩，并且我从她们身上学到了多技术。但是，后面有一些人回复说我误导了别人。所以，我在新浪微博和twitter上征集女程序员的故事和想法。我一共收到了19封邮件，其中有17封邮件来自女程序员。其中有一

查看全文: http://www.udpwork.com/item/6642.html

因为有人在酷壳里评论里说我给一个女程序员的建议不靠谱，我不服，因为我的工作经历中的一些女程序员都很不错，比那些男程序员都强，所以，我在新浪微博和twitter上征集女程序员的故事和想法，这两天来，我收到了好几封邮件，让我很感动。其中，有一个故事让我回味很久，在脑海里挥之不去，可能是因为她的经历和我很相似，她的想法和我很有共鸣。

本来，我想通过收到的这些故事然后编辑成一篇关于女程序员的文章，但是我觉得这个故事已经足够好了，任何的编辑都是对这个故事的不尊重，所以，我原封不动，一字不改地把这个故事转到这里。我把一些我认为精彩的地方加了粗。

当然，我还是会再写一篇关于女程序员的文章，酷壳2011年底的最后篇文章和2012年的第一篇文章都

查看全文: http://www.udpwork.com/item/6601.html

从9月份开始，是很多在校毕业生的择业时期，有很多很多朋友写邮件给我让我帮他们参考如何选择工作（对不起我无法在第一时间回信，因为实在是太多了，我那繁忙工作和生活都没办法让我能即时回复），并且还有一个已经工作了多年的技术很强的朋友因为跳槽没有跳好，也和我说了很多他 的感受。从这个过程中让我有了很多感触和想法想和大家分享，本来这篇文章1个月前就想写的，只是要写下来时不知道如何整理这么多的东西和思绪。今天也不知道，但是一定要写了，不然，我的这些感触和想法就会越来越不新鲜了。

注：这篇文章里的所有的故事都是真实的，其不可避免地会加上我强烈的个人情怀和个人色彩，叙述的过程可能比较乱，但我能确保这些都是我的肺腑之言。

第一个事：网友的来信

查看全文: http://www.udpwork.com/item/6557.html

（感谢网友“阿四”投递本文）

有一个令人兴奋的消息，上次提到过Standford的在线公开课公开课AI(人工智能)，machine learning和data base。我注册并参与了其中的两个。觉得很有意思，也学到了不少东西。到现在我觉得和比如像以前的网络公开课相比，比较关键一点它有明确的进度计划。这样，至少你不太会因为某一天Dota太晚而导致整个自学计划崩溃。另外更关键的一点是有不错的课程配套资料。像machine learning(据说database也有，但是我没有上这个课程)，甚至还有对应的编程作业，这对掌握你的所学至关重要。

所以，这个消息就是在2012的1月份左右，将会有其它几门课程推出:

Human-Compu

查看全文: http://www.udpwork.com/item/6518.html

经过几天的编程，netback现在已经转移到thread-per-vif的模型了，非常有限的测试表示在某些情况下新netback的性能还比旧的好的点（至少没有比原来的差）。

为了限制新模型的netback内存占用情况，需要实现一个统一的内存池。本着能简单就简单的原则，用一个free list来管理可用的entry，实现简单的get one和put one操作。以后可能还会用到，先记下。不说实现得有多好，至少是够用了。

所有的页都是通过alloc_page申请的，所以初始状态下它们的reference count应该是1。

锁的使用尽量少，put的时候没有加锁，因为写操作是原子的，真正的页面回收工作推迟到池中没有空闲页面的时候再

查看全文: http://www.udpwork.com/item/6516.html