C

随着工程代码量的增加，往往完整的编译一次Proj消耗的时间可能足够你喝两杯咖啡了，我现在build一次我所在proj的代码需要5分多钟，这是很痛苦的，颇让人懊恼的。为了解决这个工作中的别扭事儿，我在网上搜寻了一番，找到了distcc这个分布式编译工具。 ...

昨天是周五，按照工作计划，上午和组内同事做个人阶段性目标沟通。在与一位曾经在国外公司里做过项目的同事沟通时，他给我讲了这么一个故事：某一年的圣诞节前夕(圣诞节在西方人眼里是地位最高的节日了吧)他所在的那家公司的经理预感到圣诞节那天他们公司的网站的访问量激增的可能性会很大，为了保证网站在那圣诞节那天能"挺住"，他要求手下的人对网站进行一次压力测试，并决定让手下用jmeter来做这件事情。手下人没有异议，由于没有用过jmeter，遂大家都忙碌起来，预研的、准备测试环境的等等。一切就绪后，正准备开始测试了，这时那位经理突然召集手下人说jmeter不能满足他们的压力测试要求，大家都惊愕之，并马上提出了反驳，因为jmeter工具是这位领导提出要使用的，现在又不用了，圣诞节已经迫在眉睫，更换压力测试工具肯定不能完成这个任务了。这位经理无奈妥协，结果是：通过jmeter压力测试后优化的网站顺利了通过了”圣诞节的考验“，不过大家都觉得这个过程很别扭。 ...

我所在的项目一直以C语言作为主要开发语言，与做Java以及其他新兴语言的人不同，组内的同事似乎对新鲜的东西不是那么感兴趣，也没有主动去研究新鲜事物的意愿和意识。我深为此闹心，看到外面世界中那么多美妙的工具，再也不能坐以待毙了。我一直都是有很多想法的，但是迫于自身精力有限，自己无法全身投入，以前都是交予别人去做的，但是收到的效果都不是很好。认识到这点后，我决定自己动手，丰衣足食。 ...

每年都有应届毕业生来到公司，每年都要对新同事进行代码方面的培训，比如编码规范就是其中之一。编码规范初听起来比较新鲜，但是培训时间长了，显然有些乏味。今年我打算改变策略，让新同事结合已有规范文档和项目代码，自己先挖掘一遍，然后大家通过坐下来讨论的互动方式来加深对规范的理解，每次讨论时间限制在1 hour以内，不给大家打瞌睡的机会^_^。 ...

assert是大家常用的宏，它的用法相信大家都有所了解。P.J Plauger的"The C Standard Library"一书中提到在源代码中切换assert宏定义的方法： /* turn assertion on */ #undef NDEBUG #include ...

P.J Plauger的"The Standard C Library"一书的Chapter0的章后练习中有这样的一道题：编写一个包含如下一行语句的正确的程序： x: ((struct x*)x)->x=x(5); 并描述这行语句中x的5种截然不同的use，这里其实涉及到这么一个知识或者说概念：C语言的命名空间(namespace)，在"C语言参考手册"中还被称作: overloading class。 ...

很多技术人员都有在"技术细节"上"钻牛角尖"的"癖好"，对此很多人褒贬不一；无论怎样，我也是属于这类人。C语言的变长参数在平时做开发时很少会在自己设计的接口中用到，但我们最常用的接口printf就是使用的变长参数接口，在感受到printf强大的魅力的同时，是否想挖据一下到底printf是如何实现的呢？这里我们一起来挖掘一下C语言变长参数的奥秘。 ...

C语言语法简单，但内涵却博大精深；如果在学习时只是止步于表面，那么往往后期会遇到很多困难。typedef是C语言中一个很好用的工具，大量存在于已有代码中，特别值得一提的是：C++标准库实现中更是对typedef有着大量的使用。但很多初学者对其的理解仅局限于：typedef用来定义一个已有类型的”别名(alias)”。正是因为有了这样的理解，才有了后来初学者在typedef int myint和typedef myint int之间的犹豫不决。很多国内大学的C语言课之授课老师也都是如是说的，或者老师讲的不够透彻，导致学生们都是如是理解的。我这里想结合C语言标准文档以及一些代码实例，也说说typedef。 ...

曾经在多篇blog中报怨过：用C语言写业务逻辑实在是让人身心忐忑不安，再加之C语言自有的"特点"，让其与"单元测试"始终若即若离，曾经尝试过写了一个轻量级C Unit Testing lib，至少目前我依旧在用，但多用在编写独立算法以及底层库的场合。业务层少有使用。业务层多是遗留系统，当初前辈们设计时对可测性考虑不够周全，导致现在无法很好的将各个部分独立抽出进行测试，虽然我们也在做着类似"重构"的工作，但鉴于规模较大，不能一蹴而就，我们需要一步一步找出使用C应对各种单元测试情况的方法。这里说说Mock Test。 ...

本周一已经投奔ThoughtWorks的Dreamhead因公事回到沈阳，来到我们公司看望以前的同事。他谈到业界的一种说法：ThoughtWorks在"怎么做"上达到了很高的高度，但是在"做什么"上与Google这样的公司相比还有差距。既然ThoughtWorks在"怎么做"方面树立了榜样，那么这个公司推出的产品估计在"怎么做"上对其他公司也会有所指导^_^。Mingle就应该是其中之一。 公司走的是CMMI的体系文件，即所谓的"重过程"管理，这样的过程对项目负责人的要求甚是严格，常常发生与QA之间的"你来我往"，甚至为一个无关轻重的文档"严词讨论"一番；再加上部门在过程工具上的选择比较"保守"，自己感觉部门的管理成本还是很高的，有些时候甚至感觉有些浪费。普通编程人员对各种文档也是有着"抵触"情绪的，特别是在"补"一些"写完即过时"的文档时更是无奈。 ...