《大道至简》的一个读者huofei给我mail，提及到这样的问题： 在你与Soul的讨论之中，你写道很多程序员对于OS的内核没有了解，所以水平不能够有提高。我的问题是很多程序员是写非底层程序的，比如java程序员。我以为这些人是不需要多少OS知识的。 你的话会不会误倒别人呢！如果真的需要研究，又要研究些什么呢？这对写上层应用程序的开发人员有什么帮助呢？ 这个问题其实一直在被很广泛、很有争议地讨论着。很多人认为只有搞学术的、专业的、科班的程序员会把“懂多少OS知识”作为一项对技术评核的要求。但首先说，我不是搞学术的，也非专业、科班的程序员。然而即便如此，我仍旧希望开发者能了解一些OS方面的底层技术。 ...
一、 发生了就发生了吧 关于Borland出售IDE的消息，我比CSDN上公开这条消息早了半天知道。接下来这些天，总有人在MSN或者mail里问我关于这个消息的态度，我一方面显得很乐观，另一方面也很淡然。从整件事情开始直到现在，我似乎少了李维那种惊叹的表情，我总是淡淡地说：发生了就发生了吧。 我的释然却是与李维有关的。我第一次见李维的时候是去BorCon 2003大会做演讲。跟李维谈得很投机。最后我终于问到了我一直深存于心的问题：Borland到底为什么不停地买进又扔掉技术。那一时，李维的脸色显得尴尬、茫然而又愤懑于心。李维说为了推进技术投入和高层对技术、研发部门的关注，他甚至跟总部大吵过。然而Borland毕竟不是一个开发人员说了算的公司。因此一些的努力只能( ...
Qomo项目中有很多人给我mail，说自己是新手，没有多少经验，不知道能不能加入Qomo。 关于这个问题，首先给个答案，只要愿意参与开源项目，即使是不会写Code，也能够在项目中找到自己的位置。Qomo亦然。我不会拒绝任何人加入Qomo的申请，没有回mail并不表明你被否决了，只因为(目前)项目还没有正式展开，因此也没有项目角色的分派。 之所以提到这个问题，是因为今天在CCF里看到另一个开源项目(shellweb)的负责人alexe写了一篇给新手的贴子，觉得他对这个问题的解释能够让新手们在开源项目中找到一条自己的道路： 以下(转贴自CCF) 看到有很多人问关于初学者的问题，在这里就忍不住要解释一下。 其实每个开源项目对于你所拥有的能力都没有任何要求， ...
两天假，没有出行的计划，在家呆着也没有过圣诞的情绪。于是就想了想明年的计划。 给朋友提到过我两年做事的习惯：一年只做一件事。这样省得去回顾的时候，都找不着头绪。从03年开始就是这样：写了两本书，做了一年部门经理。三年，也就这么三件事情而已。 那么2006年呢？手边要做的事情真的多了，有很多是由于自己懒而堆积起来的。总是应该一件一件的了结了。排在计划里的事情： 把《石像的忆述》这篇小说写完，或者续写一部分。 去西藏两次了，每次都没有游记出来。如果再不写，西藏的印象只怕是要沉淀到记忆里， ...
远在98年，富翁doubt就提议“希望大富豪能有更多主题，如Linux”。这个问题争论一时，在当时delphibbs的规模下，还是颇可观的。当时我回过一贴： 我们说的《大富翁之xxx世界》，不是《Delphi之xxx世界》，我并不希望在这个Delphi论坛中看到什么BC、java或VB之类的话题，相信我，我是最忠实的borland Delphi鼓吹者(不是什么inprise!!)之一。 但是，大富翁这样好的一个论坛思想，如果只限在Delphi一个论题上，不免有些浪费可惜了。我想如果yysun精力足够，可以象ee一样开一个全面的论坛站。不过， ...
曾经在delphibbs上贴过一套试题，是2002年时所在的公司的一套招聘题。在应聘者中有一个程序员在答卷上到处写的是“可参考XX书”或“可参考MSDN对有关XX问题的说明”，他几乎没有写什么代码，但最后被我们聘用了。 对于这件事，我在论坛上做过一个解释： 善于使用资源的程序员才是好程序员。绝大多数的问题在网上都有答案，为什么要花三天来自己解决而不是花一个小时去查资料呢？ 我记得有在M$技术服务中心的朋友说，他们绝大多数的时间都花在帮来要求技术服务的用户查MSDN了。从这一点，就应该明白DelphiBBS一类网站的好处了。 我记得对那个程序员的评价是“涉及面广，头脑灵活，善于学习”。你想想，应该就会明白我们为什么聘用他了。:) 事实上，即使是到现在， ...
为了考虑一段代码中的字符串处理效率问题，我写了一个测试程序来检测字符串引用，然后把它贴在delphibbs里。随后这引起了对软件工程和开发技巧的争论。下面的文字很大程度上代表了我当时(2002年中)对开发技术、技巧的观点，我想这与现在的很多开发人员的观点是一致的： 说实在的，现在越来越多的人员都在说要重工程，而不要重算法，不要重技巧；陷于程序的枝节，不如跳出来考虑总体结构。 看起来说得很对，但问题是，为什么到现在M$的编译器的速度都比Borland的慢？M$在这上面追了这么多年，什么样的软件工程没搞过，却怎么还是比人家的慢？ 现在个人机越来越高档，对于个人而言，好象是永远也不用到CPU极限一样。 ...
在大富翁论坛中讨论Delphi 6 SP1对BUG的修补问题时，我提及“强烈建议Borland针对自己的产品出hotfix，而不是让大家非得等到Server Pack”，随后与y9y兄讨论到Borland和MS的不同态度。或者我们可以从另一个角度去看待MS与Borland今日的不同局面： y9y同意bugware关于补丁的一些观点，很大程度上出于Borland以及我们一些程序员所形成的思维方式。——什么东西都要做到最好才拿出来。这的确是没错的。但是，borland和MS多年来的交手，似乎总是忘记了一件事，那就是商业操作。 hotfix除了能给用户带来最快的修正外，更大程度上反映的是一个公司对用户需求的反应速度。做程序并不怕出错，但一定不要让用户觉得他们面对着错误，却没有人对此事件做任何反应。MS现在越来越注重这些对用户信息的反馈/反应速度了。而Borland还是一如既往地抱着古旧的思想…… 我刚才还在给同事说关于Borland发布sp1的事。 ...
２００１年在delphibbs做“首届Delphi编程竞赛”活动的时候，曾就代码的规范性与品质问题与大家进行过讨论，摘录一些言论如下： 3. 我们公司有个程序员，现在是项目经理。他原本是做图形程序开发的，我看过它的一个工具的代码，OHHHH，我当时差点没有昏倒。——它的代码做得就象方块，每一行几乎都一个样子，似乎都在不断重复。但是，这些代码的运行效率居然比我见到的所有图形开发包都快！ 所以，我绝对同意“一个真正优秀的方案可能代码很多，很精巧，也很复杂，但绝对在效率、速度上非普通方案可比”、“大道深处又至简，一个非常出色的方案往往可以化复杂为简单， ...
在delphibbs里发布《测试、调试软件软件使用评测计划·评测报告》时，讨论到各个(被评测的)工具的优劣，andrewbar希望我能够给他一些测试上的建议。因而我有回复下面的一段文字： 但你要注意的是，用DUnit可能需要花费较长的时间来建立测试应用和测试数据。项目测试不是一两天的活儿。如果你们的头儿没有这样的观念，那就只能将一个半成品投给客户。——这样的项目是很常见的。 AQTest是一个模拟客户行为来综合地进行黑盒测试的好工具。学习使用它，没有半个月是很难的。很多时候，测试的强度取决于客户的需求和项目的进度，而不是象工程中说的那件。 如果项目一开始就没有建立测试机制和计划。以及没有在设计和开发过程中准备测试数据，那么，到测试的时候， ...
大富翁(www.delphibbs.com)第一个被结贴的是ID号为20的技术贴。提问时间是(1998-09-08 22:51)，提问者是yysun，答复人则是我(aiming/aimingoo)。而大富翁第一个水贴却是谁呢？偶没考证过。不过看起来，大富翁里有悠久的灌水历史，以至于到才两个半月(1998-11-25 12:51)之后，贴子ID已经涨到93056。这个水贴里面的灌水角色，不妨列出来大家看看： 好吧， ...
2001年的时候，我开始使用Delphi 6。只用了三天，便测出了7个bug。后来我将bug列表整理出来，发在delphibbs上。 随后写了如下一段感概： 很多的时候，我信任Borland，但更多的时候，我宁可去读完它的源码，然后再来发表对Borland的看法。我一面承认着那些程序员的优秀和代码的品质，一面抱怨着这样那样的BUG。无论如何，BUG还是BUG，一如既往的多。作为在对这些在M$ Windows平台上唯一抗衡的编译器开发人员，和在大富翁里里外外的这些Delphi Fans最高的尊敬，我除了只能提出这些Bug，还能说什么呢？ 接下来的事，可能还是只有低头， ...
在与网友讨论的时候，写到一段话，觉得有点用，记下来备忘。 (2005-11-29 23:09:52) 一只小小鸟 为了提高程序效率，几乎所有的数据访问都是基于存储过程，有时修改一个问题要修改三部分，唉，为了考虑数据库的安全，下一步我想把它做成CWebService,但我一个朋友骂了我，他的观点是，一个小企业，没必要做的那么麻烦，过程也可以不用，直接把SQL语句嵌入到代码中进行数据访问就行了，也许他是从软件公司做项目的角度来看问题的，因为开发效率也很重要。 (2005-11-29 23:10: ...
尐乖不乖在回贴里提到我的职称。也就是我在个人简介里的职业“程序员、项目经理、架构设计师"。这倒是很有趣的。因为我看到过有人列出一长串的职业和职称，还言之无物，意无所指。我这里写下了三个职称，也如同这些人一般，那岂不是水分太大~~ 哈哈。那索性就来解释一番。 一、程序员 这个职业我做了近十年，现在都还在做。我还在写code，这并不是一件让人脸红的事(事实上我引以为自豪)，但也不见得让人愉快。代码是我的本业，从代码中去发掘思想，是我这些年来在做的， ...
今天做一些JS的代码，终于发现忍无可忍。不知道为什么，翻来覆去就那些代码行，做了一周也没有什么长进。实在烦得可以。 掩面长思～在差点睡着之前，终于想明白一件事：EN,代码的生长过程，也是曲线的。 首先，在项目的最初起，由于方案并不很确定，技术疑难也多，因此框架代码多、技术实现的示例代码也多。因此这个阶段的代码是散、乱，并且有效的代码也很少。基本上，在后期能留下来的并不多。但是这个阶段的代码量可能暴涨暴跌，因为技术选型导致的很多代码可能一夜之前就出现大幅的增删。 在项目的中段， ...
