IT牛人博客聚合

从哪儿说起呢？我想了想，从 gets 说起可能最好。

初学C语言的时候，如果要输入一行字符串，该怎么办？看书，或者找老师，或者找学长，通常得到的答案是gets。用法很简单，似乎也很好用，但是很不幸，这个函数很危险。因为 gets 对输入不进行任何的限制。如果对应的字符数组只有100个字符，而面对的输入是1万个字符，那么几乎毫无疑问，这个程序是要崩溃的，除非运气特别好，或者……

或者给出的输入是经过精心设计的，例如一段shell code，及其对应的跳转地址。对于常见的计算机体系来说，函数调用时，返回地址是在栈上的，通过精心设计输入，使得溢出数据中的跳转地址好正好覆盖了该返回地址，于是函数在返回时不是如预期般回到调用者处，而是跳转

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

之前，@风枫峰 在“这是谁的错？”中说过开发团队对需求来者不拒，而@weidagang 也在“需求变更和IoC”中说过用IoC来最大程度地解决需求变更。今天我也想从Unix设计思想的角度来说说什么是好的软件设计，什么样的设计可以把需求变更对开发的影响降低。（注意：这并不能解决用户或是PM的无理需求，面对无理需求，需要仔细分析需求，而用技术的手段无法搞定这个事，但是可以减轻需求变更带来的痛苦） 我曾经在《Unix传奇》的下篇中写过一些Unix的设计哲学和思想（这里重点推荐大家看一下《The Art of Unix Programming》，我推荐过多次了），以前也发过一篇《一些软件设计的原则》，不过，这些东西都太多了，记不住。其实，这

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

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

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

翻译自：How To Read C Declarations 英文原文
p.s. 以前还真没注意到这篇文章最后提到的vtable是啥意思……

就算是非常有经验的C程序员，也对那些比简单数组/指针更复杂一些的声明感到头疼。比如说，下面这个是一个指针的数组，还是一个数组的指针？int *a[10];

下面这货到底是什么？int (*(*vtable)[])();

当然了，这货是一个指针，指向一个数组，这个数组的每个元素是一个指针，指向一个函数，函数的返回值类型是int  :)

这篇短文希望能够教会你一个非常简单地读懂复杂声明的方法。我99%肯定我在80年代读过这篇，但是不记得具体是在什么

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

【感谢 Todd投递本文 – 微博帐号：@weidagang 】

需求又变了，怎么办？

先上一个轻松的段子：

程序员XX遭遇车祸成植物人，医生说活下来的希望只有万分之一，唤醒更为渺茫。可他的Lead和亲人没有放弃，他们根据XX工作如命的作风，每天都在他身边念：“XX，需求又改了，该干活了，你快来呀！”，奇迹终于发生了，XX醒来了，第一句话：“需求又改了？”。

这个段子用幽默的方式反映了需求变化是每一个程序员、架构师或项目经理都会经常遇到的问题。面对这个问题，不同的人有不同的应对之道，最近微博上有一段关于需求变化的讨论：

@假装刺猬的猪：我们在软件开发过程中，会持续碰到客户需求变更的情况。如果没有领域建模，我们单纯将问题使用

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

【感谢 Todd投递本文 – 微博帐号：weidagang 】

问题

最近项目中遇到了一个分布式系统的并发控制问题。该问题可以抽象为：某分布式系统由一个数据中心D和若干业务处理中心L1，L2 … Ln组成；D本质上是一个key-value存储，它对外提供基于HTTP协议的CRUD操作接口。L的业务逻辑可以抽象为下面3个步骤：

read: 根据keySet {k1, … kn}从D获取keyValueSet {k1:v1, … kn:vn}

do: 根据keyValueSet进行业务处理，得到需要更新的数据集keyValueSet’ {k1′:v1′, &

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

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

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

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

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

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

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

12306.cn网站挂了，被全国人民骂了。我这两天也在思考这个事，我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促，而且完全基于本人有限的经验和了解，所以，如果有什么问题还请大家一起讨论和指正。（这又是一篇长文，只讨论性能问题，不讨论那些UI，用户体验，或是是否把支付和购票下单环节分开的功能性的东西）

业务

任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。

其一，有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载

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

　　对于没有GC的语言来说，这实在是最让人头疼的事情了，毕竟内存泄漏是最难处理的问题（之一?），对于一个后台server，即使只是一个小小的泄漏，日积月累，也会导致灾难性的后果。有个传闻说的是，某公司的某下载软件的某后台server，由于有个无法定位的内存泄漏问题，导致服务的内存占用不断增加，以至于只能每隔一段时间重启之。

　　有人说，C/C++程序员有一半的工作量是花在处理内存泄漏上面，但是很遗憾，内存泄漏仍然屡见不鲜。一旦出现泄漏，能做的事情不多，上述处理方式是消极做法之一，有效，但治标不治本。积极一点的，也不外乎这两个：一是看代码，反复看代码，请别人看代码，请别人反复看代码；或是借助valgrind之类的工具来跟踪内存的分配

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

这程序写了好几次了，干脆贴出来吧～附上exe。#include <stdio.h>
#include <stdlib.h>

char str[65536];

int main() {
    int i;
    for (i = 0; i < 65536; i++) str[i] = '1';
    str[65535] = '\0';
    i = 0;
    while (1)


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

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

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

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

Human-Compu

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

因为《腾讯帐号申诉的用户体验》一文中好多人觉得腾讯申诉是世界级先进的，并让我拿出一个找回用户的帐号的功能来。本来不想写的，因为大家看看其它系统的就行的，但是，很明显有些人就是很懒，也不会思考，而且不会观察，所以，我就只好写下这篇科普性常识性的文章。

在行文之前，我得先感谢腾讯公司的至少30名员工在《腾讯帐号申诉的用户体验》一文后的回帖（我STFG（Search The Fucking Google）看到了你们使用的那个固定IP在各个大学论坛上的腾讯的招聘广告），我感谢你们主要有两点：

你们有半数以上的人留下的是gmail而不是QQMail/Foxmail的电子邮件，这点让我感到很欣慰。

你们在加班到晚上11点的时候都能在本站回

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

该元素在数组中不一定存在，只是要找一个i，使得 arr[i]

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

感谢@weidagang （Todd）向酷壳投递本文。

程序设计语言的抽象机制包含了两个最基本的方面：一是语言关注的基本元素/语义；另一个是从基本元素/语义到复合元素/语义的构造规则。在C、C++、Java、C#、Python等通用语言中，语言的基本元素/语义往往离问题域较远，通过API库的形式进行层层抽象是降低问题难度最常用的方法。比如，在C语言中最常见的方式是提供函数库来封装复杂逻辑，方便外部调用。

不过普通的API设计方法存在一种天然的陷阱，那就是不管怎样封装，大过程虽然比小过程抽象层次更高，但本质上还是过程，受到过程语义的制约。也就是说，通过基本元素/语义构造更高级抽象元素/语义的时候，语言的构造规则很大程度上限制了抽象

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

ppt中保存的默认是原始照片；可以把照片另存，但是保存的图片实际上是压缩过后的图片，而且EXIF信息也丢失了；另存为pptx再改成zip，发现效果相同。为了找回最原始的照片，可以将其另存为xml格式，然后再写程序将其中的图片信息提取出来。

xml格式中图片的信息大致是这样存储的:引用
<pkg:part pkg:name="/ppt/media/image5.jpeg" pkg:contentType="image/jpeg" pkg:compression="store"><pkg:binaryData> [[base64 encoded dat

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

我在我的微博上说过这样一段话，我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子：聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的bug… 所以， 越差的团队一般会越忙，而且还忙不完。

在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD，快速迭代，不

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