GNU~~我的老山羊

http://www.codecomments.com/archive292-2005-3-433707.html

First, try if you like to disable precompiled headers (it's in the compiler options in the project settings). See if that helps at first. If it does, then try setting your settings for stdafx.cpp to "Create precompiled Header" (/Yc) with stdafx.h, and then set the rest of the files to "Use Precompiled Header" (/Yu) with stdafx.h. See if that helps.

我一直在工程选项里面调这个设置，没想到单独的 cpp 文件也有自己的设置。早该想到，应该有第一个 cpp 文件用来生成这个 pch 文件，可是既然每个 cpp 文件都必须用到 pch 文件，这简直就是个先有鸡还是先有蛋的问题。现在还是查 Google 解决了。

整个项目接近尾声了，编译速度才终于可以忍受：这就是一个 Build Manager 的失败之处了。至于 AWS 组前几天才号召在 Post Build 中复制文件到目标位置：胡乱作出的决定，甚至连 attrib -r 都不用，当初设计源代码仓库目录的时候就有些问题，把二进制文件与需要原样发布的文件混合在同一个目录下，现在多次尝试分离都做不到方便开发和构建。他真是失败。

光武说，Bad smell
杭哥说，Refactor

再次与合作者发生冲突。原因是改名。我们的程序包含了很多以数字编号的组件，君英大大开始写的 c++ 程序并没有在文件名和类名上包含编号，我写的 xslt 在文件名和模板名上大量应用编号。现在 c++ 程序交给我做了三天，我把程序重构了一遍，基类当然是按照那个尽量压缩的原则，还有 private virtual 原则，自己感觉很有条理。无数的 helper 函数。protected 其实是 private virtual 的 helper 函数，把函数都放到这个区域，然后整体提取成 helper class 就会让基类更小。比较不爽的是 protected 在提取为 helper class 之前，不能像独立的 helper 函数一样放在 anonymous namespace 里面，很难限制它的用法。言归正传啊，另外一个重构就是改名，把文件名和类名改成和 xslt 一样的风格，因为那个编号本来就属于那个类。另外，类名的单词部分也作了修改，以保持与 xslt 一致。xslt 与 c++ 必须同步，不然维护会很麻烦。这样修改之后，文件名可以方便的在文件管理器或 IDE 中找到，而类名也像 xslt 模板名一样提供了足够的名字空间，只要工程中组件数控制在 100 以内，命名和搜索就不会是很困难的事情。小小的改动是把输出文件的名字改掉了，因为我们在整个工程里只是很小一部分，不能用一个丝毫无法联想到我们的输出文件。一旦出问题，没人知道该来找我们。

冲突就是这么发生了。上次和保川师傅冲突，也是这样的原因，首先是 private virtual，其次是目录结构。问题在于，我是不是一定要这样才能顺利工作。如果看到一个不顺心的名字或者路径，我想谁都会觉得不舒服，例如 typo，这在我眼里是不可容忍的错误。另外，时刻考虑到自己的名字空间会对整个项目中其他人有利。作为一个新手，我觉得我应该坚持这样做，才能有长进，不能因为想到合作者会暂时觉得不习惯，而把改变什么东西的想法抛到脑后。合作者往往比我有经验的多，因此一方面可以容忍我，一方面可以给出更好的意见。(可是检出文件禁止我继续做下去，是比较无情的做法 :()

目前的情况是，我已经修改了文件名和类名，使用 sed 非常快，我不想再改回去了，因为不想在将来，为新的类取名字而绞尽脑汁。想必君英大大也不会费力地把它改回去。anonymouse namespace 的事情，君英大大看来十分反对 helper 函数采用这种方式，而想放回去继续作为 protected。我想既然这样是书上推荐的做法，那么一定不会错。具体的理由我得到书里去抄，反正时刻记住老师的独立演化，再加上逻辑清楚就可以了。有一点可以确定的，anonymous namespace 作用域就是当前源文件，因此不能用在 .h 头文件里面，因此 inline 没有意义。。。。绝对不是变成了 global symbol.

有点问题就是 helper 函数会让维护者学习一阵子。例如几个 private virtual 其实是两个层次，其中一个层次只有一个函数，调用了第二层次的所有函数。在过去的 Direct 1.0 中这种结构导致了非常大的混淆，因为没人会关心基类中，第二层次的默认实现究竟有什么效果。因此，Direct 1.0 中大部分的派生类都是直接对第一层次重载。这样其实是允许的，但是他们同时对第二层次也进行了重载，或者说很不幸的为自己的实现取了与第二层次完全相同的名字，混淆就在这里了。不应提供两个层次的重载? 但是如果不那样做，默认动作的实现就会比较麻烦。采用两层的继承可以很好的解决这个问题，其中一个无法再继承第一层次，然后推荐大家使用这个版本。但是，又有多少人会为了这种维护的好处而冒着“类层次过多”的指责呢? 回到这个工程，我想这个问题不会很严重，即使规模上升到 100 的时候，因为每个派生类的处理内容都非常少，而基类的作用不是一个容器，基类的处理非常重要。后续的维护者一定会去研究基类的每一步的效果。

我是不是太喜欢从技术上的争论/问答中学东西了呢

zonzi 说的对，我是死读书的，并且很顽固。我觉得他很讨厌，因为他吵架时候总是转移话题。他会讨厌我的逻辑，这也是我在 linuxsir 说他不喜欢和我吵架的原因。我为我死读书而自豪啊!

update:
比较严重的问题，是我为什么总是在中途加入项目，而不是从开始就独立做些什么呢，像杭哥儿一样?
君英大大提了个很严重的问题，什么时候重构才会停止? 不过既然他看过了 refactor，那么自然该知道，bad smell 在维护过程中总是会慢慢的，散发出来。

早晨把一个梦做了无数遍，重构一个人的关系，涉及两大门派和小门派的争斗以及委培之类
还有就是梦见自己的嗓音无比动听

觉得早晨二十五分钟炒个菜应该没啥问题，煤气总是会有，水也有。然后水管一阵轰鸣，停水了。好险我洗过脸才做饭的。转过头，茶几上放一张燃气管道隐患通知，也许煤气也没有了，谁知道呢

早晨走在路上想，昨天为什么想不起 restart, setter, 诸位亲爱的师兄们的名字

还有感冒了，所以非常活跃

因为默默说我的声音变了，并且不是很好，所以一直有点郁闷究竟怎么回事。昨天晚上和消失已久的周叶铨(这个名字还能想起来~~)通话，好久没听他讲有意思的东西了，他好像还在 Qt，并且是 PyQt 但是进度比在学校时也好不到哪儿去，于是我觉得工作一年，对于这些杂学的长进很没好处。学到了扫雷游戏的写法。看 Qt 的函数和 MFC 那么像，真是亲切。

昨天想到，程序员需要掌握的东西：语言，业务，框架，部署。也就是说，例如扫雷，我必须懂得扫雷的算法，也就是业务；语言呢，是 Python；框架就是 Qt 的一套，虽然这里只是一个库，但是牵涉的东西已经比较多了；部署则是在玩游戏前必须安装 PyQt 并且对 PyQt 适用的平台了如指掌。初学者会把语言放在首位，而我一直是把部署放在首位，于是我的程序写得不好，处理问题倒是很拿手。业务是头儿们关心的，而框架是我们拿工资的根本，于是在一个公司里，开发者会有分化。我既然现在把业务放在首要考虑，大概是因为很想当头儿。但是另一条规则就是只有好程序员才可能当好领导者，因为必须了解实现的办法以及可能性，才能集中精力考虑业务。我看到自己将来怎么失败了。

四个水煎包，两个早饭，两个午饭。打字，看帖子，不知不觉，午饭吃掉了~~
真是个郁闷的早晨

Bresenham 算法画椭圆，还是用那个莫名其妙的公式画椭圆，还是把那些莫名其妙的参数换算成 svg 椭圆参数？问题是，哪一个都这么困难。。。。


看到一个牛人的 blog http://spaces.msn.com/members/freemanhu
觉得他见识比我强得多

另一个。 http://spaces.msn.com/members/liujiakai
觉得还是 jwise 他们积极参加算法大赛的人最有前途

上面两个链接来自 Bowei Yang http://spaces.msn.com/members/ybwzw

终于放弃了搞明白 viewbox 的用法。。。。只有左中右三种定位，要么缩放要么不缩放，总是从 0,0 开始，用在 svg 中，可以指定 pt 单位：不知道用在什么地方才好。然后，从 svg spec 的警告里找到了 <clipPath> 和 <g clip-path="...ID"> 的用法，谁会想到想要的 view 实际上是 clip 呢。还有，<g transform="..."> 的用法，因为是矩阵乘法，因此从右到左计算，而嵌套的就是先计算内层的。这下子定位问题就圆满了吧。

从上周五到今天，忙了三天。大概做出来的东西。。。。反正从对 MFC 一窍不通，到用了不少里面的东西，光武帮我好多。
从网上看到个做法：
这样，静态类成员变量就可以使用 COM 对象了。COM 在初始化之后必须运行 CoUninitialize()，并且在每个线程中都必须对称地初始化和撤销，除非用 CoInitializeEx() 初始化。这样，由于全局变量比静态类成员的析构更晚，可以保证 CoUninitialize() 总是最后一个调用的函数。

还有呢，发现 MFC 的界面线程和 swt 有点类似，PostMessage 和 SendMessage 就相当于 swt 中的 asyncExec 和 syncExec，真是有趣。以前不知道应该这样看待这些鬼东西的。不应当在多个线程中直接操作部件，必须交付主线程去做。关于绑定消息，MFC 还是比 swt 丑陋一些。

为什么要总结半天呢，因为研究业务逻辑，考虑一个最好的实现，定义配置格式和解析，费了好大的心力。就算是将来要重用代码，也不是什么难事吧。。。。可是，翔哥还是放弃了自己的框架，也就是说小华选择了另一个组。给我的十天时间，现在已经用不到了。明天，我就必须去学习另一个组的东西，然后重新来过。

真的是控制权决定一切。现在讨厌别人看我的代码。小程序员，和大家合作。
我很想合作呢，设计的 xml，使用的名称，提交的文档，我很想合作呢。反正看见小心翼翼的语气，强硬的语气，商量却不容置疑的语气，不同意却不说出来的语气，心里很奇怪。觉得 ggbk 那句话真好，尽力推进团队讨论的透明。。。。可是，别天真的以为别人会看自己的代码、文档，精心设计的名字。我又一次想去大腕的组了。也许，那一组会累一些，受气一些？陈宇和大腕需要加班好晚，难道那一组就这么恐怖？

我要什么？直白的要求，直白的要求，明确的否决，理解，文档，天哪我连 check in 时候留下注释的习惯都没有了。我们组里面直白的要求太少，只有等待其他人的决定，等待另一个人的神机妙算。等待是我们组最大的弱点。

翔哥需要强硬一些了，至少应该把我的埋怨一巴掌打回去。我不想让他生气。另外，哪怕返工很多，也应该多动手做才对，就像那一组一样。

今天看了 China PUG (Python User Group) 的一些讲稿，觉得啄木鸟社区又专业又热闹，真是个好地方。

组里面十个程序员，有大半反对我写代码时候使用 namespace。这些不可救药的 c++ 程序员！
于是把我的那些文件统统修改一遍，一共是几十个。项目里本来就没有多少文件，于是全部检出，时间间隔 2hrs。
还有挑出来的毛病是使用 std::string。应该统一到 CString。平心而论，CString 直接导出 buffer 的做法很让人喜欢，因为 MFC 整个就是为了方便而设计的，没有数据隐藏，所谓 C 开头的其实都是 struct。这样的 MFC 让 BS 去用，肯定是无法接受的，要是让 OOSC 的作者去用，恐怕他连砸烂机器的心思都有。但是我的代码里 CString 和 string 都太多了。说起维护，我想我从上手编程序到现在也不过这样几天，照样很习惯，他们凭什么不能花几天来适应 namespace 的用法？。。。。
其实有问题的代码都出现在比较新的结构里，但是不能排斥成这个样子啊
要是不允许用 std::vector 的话，我还是去死好了
还有 #define Unicode 还是 #define MBCS，现在要求必须把所有的 L"" 统统变成 _T("")，那样还是不如杀了我吧，痛快一点。要多打多少字符呢。。。。
还有 include 的修改，本来有个 includes 目录(拼写错误！)，大家把头文件扔进去，一样互不干涉，并且自己的代码可以干净一点。可是新的规矩出来，不允许设置项目属性。。。。这样的话怎么办才好，把头文件和源代码混起来实在是麻烦死了。项目属性是做什么用的！
最后是 XML 的接口。大家都用着 xiang 的那一份，但是我觉得并不好用，也许是我用错了？xml 里面有那么多内容，而大腕他们的封装也不错，为什么不考虑直接用他们的呢，何必将来重写呢。并且 xiang 的接口必须同时用到 doc 和 node，就算是 CppSQLite3.cpp 也提供了 stmt->execDML 和 stmt->execQuery，真是别扭死了。
数据部分就是被动地接受请求，返回数据。
这程序写得也太被动了。
我提了一万次的意见，自动生成文档和分析的时候可以方便些。但是最后的响应，是“我们的程序直到生命期结束都不会有文档，也不会有人去看文档。直接看目录划分就可以了”。我提目录和文件内部的 namespace 逻辑关系应该一致，像 java 一样，没人用 class view。大家都只操作文件。
还有第三方库的头文件以及库文件位置。一个 linux 那么大的系统都可以有 FHS，为什么我必须把 sqlite3.lib 和 CppSQLite3.cpp 放在自己的工程下面？
好多问题，我想如果我忍耐下去，我会什么都学不到。这里连 cppunit 也少有人知，eclipse 也不了解，我还能从这里学到什么？学习 COM 和 MSMQ 吗？MFC？
这里也没有 Apache 只有 IIS，ActiveX，没有 OOo 只有 word, ppt, xsd, 这里的 ms exchange 经常出故障。
我想去 AWS 组，应该比这里忙一些吧
保川师傅接着我的两小时窗口之后，全部检出。他的习惯比我还差，他喜欢全部检出，然后在 commander 里面移动文件，我总是担心他做这种对文件的操作时候，脑子里有没有在想逻辑关系，也许翔哥说得对，只是因为我们的习惯不一样，我和大家的编码习惯有点不一样，处理习惯有点不一样。。。。在他检出之后，他的机器再次死机了。我想这段时间我既然完全没有办法做事情，不如在这里关税，顺便抱怨一下。
FHS, HIG, 好怀念 linux 中的种种标准。一切皆为标准，世界就会清静许多。std::string 和 std::stringstream 真差。
我快要爱死 cppunit 用 doxygen 生成的文档了。就连 eclipse-cdt 的函数模版也要照顾 doxygen 的面子。我们并不是总是通过看代码来学习的。我有什么办法？
没有 namespace 的时候，私有类和全局类，每个模块的类按照字母顺序排列，一锅粥。一个小程序，用到三种第三方库，包含五六个模块的时候，类的数量已经增长到了两百。对话框可以用 CDlg 这种前缀，看起来好像很整齐，可是我们各种各样的对象。。。。


update20060320
现在在 vss 里面工作有了习惯，本地修改不检出，检出时不覆盖，提交前先做 diff

和以前的想法一样，尽可能减小排他修改的窗口

好吧，也可以说，是忍气吞声地看着别人检出、排他修改，然后自己去做合并。自己吃亏一点，对于整个团队有好处。但是，如果这样做并没有得到他人理解，反而被嘲笑是不懂规矩的傻瓜，那就是进入了纳什均衡的...窝囊的状态。郁闷！

Item 18
招聘

( Read more... )

http://fedoraproject.org/wiki/FAQ/Glossary
http://fedora.redhat.com/docs/jargon-buster/fedora-glossary.html
http://www.redhat.com/docs/glossary/

    假如翻译字典的话，肯定很好玩。但是，如何保持与这三个网页的同步，以及翻译的中间过程采用什么形式，以及翻译之后的公布如何做到同步，都有点困难。成熟的中间过程是 po 但是几个源文件都是 HTML，如何转换... 关键是对 http://i18n.linux.net.cn 的 html2po 不熟悉，试试看

    本来想翻译 yum 的文档，但是发现 fedora docs 网站上好像禁止外人访问 cvs 了？好奇怪的说，难道翻译者也被作为文档撰写者同等对待了？....意味着注册阿，认证阿，烦死了。:(
    好像搞错了。http://cvs.fedora.redhat.com 还是有 docs.shtml 页面的，:)

    为什么我把过程看得比劳动本身还要重要呢，以至于工作是不是做完了也不关心了呢？很多事情，包括做版主，搞翻译，都是这样子。也许是我没有真正理解一个项目究竟是如何成功的：踏踏实实的做事情，把事情做完做好，而不仅仅是关注过程和软件工程的废话。也许我学习一直不好，学各种东西总是浅尝辄止也是这个原因。
    1. 如果找到一个最好的办法，却没有实现它，说明这个办法并不能激励我，说明它不是一个最好的办法。
    2. 如果在找最好的办法时浪费了太多时间，没有精力和劲头再去实现它，那么是得不偿失的。

    我想那些成功的项目管理者素质就在于可以忍受现状，可以在改进流程的同时推进实质性工作，充分利用人力资源而不是技术资源。


    update: 我想不用我去做翻译了。redhat glossary 本来就有中译本。而 fedora glossary 和 jargen buster 有 fedora-gro cvs 翻译。另外，发现 IBM 也有一份 glossary 在 http://www-128.ibm.com/developerworks/cn/linux/glossary/