在大概3月初的时候，我在实验室局域网服务器上架设了Wiki系统用于知识库的建立。期望能够借助Wiki的机能，充分集中大家的智慧和经验，群策群力的建立一个拥有长久价值的知识仓库。我坚定的相信这样一个知识仓库的建立会带给每一个人不同程度的好处。

一个月快要过去了，回头看这一个月中Wiki在整个团队的使用状况，感觉有一些东西是我在建立Wiki之前所没有考虑到的。

首先，Wiki虽然大多提供了比较强大的编辑功能，但是对于大部分没有接触过Wiki的人来说，用好这些编辑功能的门槛还是相对比较高的。就算对于我们这些计算机专业的学生来说都有一些困难，一些标记符号并不是那么容易记住和灵活使用。所以，从易用性来看，Wiki并不象我认为的那么简单而有效。甚至有些朋友反映，实在是难以理解。尽管我花费了一定时间，准备了比较充实的帮助材料。

其次，Wiki这个概念对于很多很多人还是一个崭新的概念。Web2.0其实是一个很小的圈子，尽管我们在圈内的人炒的热火。但是说句实话，在这个圈内的人实在是很少很少的一部分。尤其是在国内，尽管很多人知道Web2.0，但是他们并不清楚。可以想象，我从上大学以来一直生活在计算机的专业圈子里，就我身边的人看，对于Wiki这种东西的认知程度，仅仅取决于在线的时间以及对于互联网的使用方式。尤其对于Wiki这种东西是需要相当人给出贡献的，如果大家对于Wiki都不是很了解，如何能够形成一个好的知识库呢?

再次，Wiki的内容形成完全取决于每一个用户的集合，但是并不意味着就不需要管理人员。恰恰相反，Wiki的管理工作甚至更加繁重。很难想象每一个用户都有一个概念，把自己添加的内容放在恰当的位置。尽管Wiki通常带有搜索功能，但是从通常意义上讲，把内容放在不恰当的位置是一件非常头疼的事情。尤其在每一个人头脑中的知识层次结构都不尽相同，除非强加一个标准，否则很难依靠自组织形成良好的库结构和优秀的内容。既然是强加标准，那就需要有执行力，这又不免要带来需要管理人员的需求。我们都以为Wiki是完全自由的，但是每一个成功的Wiki都需要有一个或者一组核心成员付出相当程度的努力。从某种意义上讲，我所处的团队中的任何一个人包括我本人都不可能拿出这样的精力投入到这样一件事情之中。

最后，Wiki是一种交换，贡献自己的知识提供给他人，同时有机会获取到自己需要的知识。注意我用到的词汇，有机会。因为人是有区别的，不能指望所有的人会贡献得一样多。这样就产生了有些人贡献比较多，有些人贡献比较少。当一个人发现自己无法从这一个知识库中获取足够的资源的时候，他就要求助于其他的系统，比如我现在最常使用的是Wiki是英文Wiki百科而不是中文Wiki，而长此以往会产生一种习惯，我们会逐渐淡忘那些无法获取所需内容的地方，转而把注意力投入到拥有足够规模的社群，同时把自己的贡献倾斜到能够获取更多的社群中。其实这种现象对于大规模的Wiki组织来说不是问题。但是对于一些小的或者不知名的或者局部的Wiki就会有很大影响，想象一下，你是希望把自己辛苦编辑的内容放在一个拥有大量内容的Wiki上，还是放在一个什么都找不到的Wiki上。而对于我们团队的Wiki，情况更加惨烈，大家都说这个东西很好，但是真的除了我以外，我只发现很少的其他人提供的内容。因为大家查找资料的第一选择不是我们的内部Wiki，从另一个角度讲，除非可以在我们内部的Wiki上获取大部分我们日常需要的内容，才有可能吸引大家更加关注这个系统的前景，从而发自内心的贡献内容用于交换。

我们的内部Wiki已经注定失败了。有没有其他的替换办法呢？我始终感觉一个内部知识库的存在的必要性，正是因为积累才有可能跃上更高的层次。不知道哪里有比较成功的团队Wiki应用案例。

另外，老师最近想要架设实验室内部的SNS，其中包括Blog。我想也许对于自私性这一本质来说，Blog来分享经验是一种更加个人化的方法，也许会起到更好的作用。但是很担心实验室SNS的建设成功与否，首先，这是老师的一个任务，其初始目的是用来最终大家的思想动态和用于实验室的工作组织，所以学生们最先担心的问题是，他们不能在这些Blog上面随便写东西；然后就是执行者的问题，因为大家都是硕士生博士生，没有人愿意花费时间用于这种没有什么“技术含量”的事情上面，相信最后搭建的系统会是一个没有什么实际意义的系统，这一点我很失望，因为执行者不是我，我也没有权利去干预。算了，还是不说的好，毕竟这个blog已经被发现了。

其实有一句话还是有道理的，Blog被自己熟悉的人知道是一件不是那么好的事情。如果被自己老板知道了更加是一件痛苦的事情。索性的是我还不是什么口不对心的人，我暂时还没有什么内心的需要隔离的事情，之所以还能继续写Blog也在于此。如果我有什么东西不能让别人知道，Blog就不会是我表达自我的天地，我的Blog也不会存在了。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=807541

这很让人苦恼，每个礼拜总有那么几天，会处于一种反思状态。而软件开发的绝大部分工作量存在于修改代码，而不是创造代码。客户付钱给我们，希望拿到令他们满意的软件；我们挣扎着，尽量去取悦客户。如果我们的努力是值得的，至少我们会快乐许多。不过痛苦的时刻总是有的，我们付出了最大的努力，但是客户的脸色似乎并不那么好看。更悲惨的是，客户想了一想说，也许改回原来的样子会更好吧……

我们热爱着我们的专业，我们投身其中。如果仅仅为了赚钱和谋生，又太多的选择和机会了。做一个程序员在这个社会网络中实在太微弱了，除了神经质一般的生活规律，我们能给这个社会创造的仅仅是似乎可以提高工作效率的工具。我们没有办法通过关系或者权利来帮助“朋友”获取利益，更多的我们能做到的是，在朋友打来电话的时候提供处理计算机鼓掌的解决方案，事实上，在这一点上，我们也很业余。我们只是持续着受虐狂的本性，不断的折磨自己，然后看着成千上万行的叫做代码的东西扬扬自得，仿佛整个世界已经踩在自己的脚下。世界本来就在脚下，这不用我们以为，可惜的是，我们经常感觉不到这个世界。

尽管我们会抱怨，但是我们还是会尽量使客户满意，一方面是生理需求，我们得吃饭；另一方面也是心理需求，只有这样才能体现我们得价值。不是么？

所以，大大方方的走进这个真实的世界吧。兵来将挡，水来土囤。总有一种办法能让客户满意吧，这不是幻想，否则为啥有这么多骗钱成功的案例，为啥那么多年轻人削尖了脑袋要成为挨踢人。（这世界本来就充满了大大小小的“围城”，外面的想进来，里面的想出去，好奇而已？）

有句话我向来欣赏：“既来之，则安之。”通过探索和学习来提高自己的水平，近期将结合自己一些不成熟的想法，写出来一些文字，做一个总结，做为自己将来的备忘录吧。如果您有兴趣和我一起讨论，或者想收我这个不算不太开窍的小子为徒弟，欢迎关注：“Satisfy the Customers”系列反思，近期奉上。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=764645

这是基于DoxyGen的一款专门用来生成C＋＋ Documentation的工具。和JavaDoc一样，DoxyS根据特定格式的注释和对源码的分析自动生成Html格式的文档。这下子我可以告别手工写文档的日子了。试用了一下，所要做的只是把" // "改为“ /// ”或者" //! "，把“ /* …*/ ”改为“ /** …..*/ ”或者“ /*! ….*/ ”而已。当然也拥有一系列的特殊格式，比如：\author，\note，\todo等等（详细的可以参见help文档）。生成的Html文档比JavaDoc还要漂亮。

public member of a class

include graph

当然DoxyS还只是0.84beta而已，还有很多功能会出现，也会有bug存在，不过这款工具确实解决了我很大的苦恼。原来还想有空自己写一个生成工具来着。人家早就替你想到了。

每一个开源软件社区就像是一座宝库，指不定哪个软件哪段代码会给我们带来惊喜。我已经淘到过不下十种新鲜工具了，实用，便捷，最主要的是免费，而且源码开放。

至少，下面我得文档工作轻松了很多。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=440893

传统的做法是，用TListBox来显示ListBox……这恐怕用脚后跟都能想到。

例如使用ADOQuery，我们要把Query的DataSet取出需要显示的字段的数据加入ListBox中显示出来。然后根据选择把相应的信息显示或者处理。

这涉及到很多过程：

//从Query读数据出来，加入到ListBox：

//在ListBox的OnClick事件中处理选择：

那么我还要根据选择在数据库中读取其他字段怎么办呢？重新根据选择的内容查询？或者当初读出来的数据缓存到一个空间里面和ListBox1的ItemIndex关联？无论怎么做代码都不少写。

在查询很复杂，用户操作步骤很多，或者无法预知用户步骤的时候，我们需要多次对数据集进行操作。在这个时候我们真的必须把数据都读到ListBox中然后再操作吗？当然不用。我们有TDBLookupListBox。

但是我觉得它不够好用，一个投机取巧的办法是直接用DBGrid作为List。谁说List就一定要用ListBox了。把DBGrid属性中的Option展开，设置：dgTitles、dgIndicator 、 dgColLines、dgRowLines为false，设置dgRowSelect为true。然后设置ReadOnly为true，怎么样，能看出来DBGrid和ListBox有什么区别了么？

我们可以再ADOQuery中select需要的字段，加入datasource，在DBGrid中显示出来。而不需要显示出来，却需要用的字段我们可以通过下面的手段隐藏掉。
例：

这样Brithday和Address字段我们就看不到了。但是他们就在数据集里面，我们甚至不需要编写多少处理Click事件的代码就可以轻松在Edit中显示想要的数据，或者进一步处理了。

要做的仅仅是在DBGrid的OnCellClick事件中通过简单的ADOQuery1->FieldByName("…")把想要的字段数据取出来并且加入处理过程这么简单了。

有时候，这种办法可以瞬间使得头疼的过程变得轻松异常。一个DBGrid可以起到几个DBLookupListBox的作用，在一些特别的地方可以试试这种特别的ListBox。至少想到这种方法以后，今天就把几个原来查询过程不太人性化的窗体重写了，效果还不错。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=422951