Good good study, day day up

我相信万事万物均有其内在之美，绘画有色彩之美，音乐有韵律之美，建筑有结构之美，数学有逻辑之美，程序也是一样，程序之美在代码之中，美的代码犹如绚丽之画卷，随着阅读展露于眼前，慨叹于架构的精巧，设计的美妙，细读下去又象隽永的散文，行文流畅。

我也相信真正的程序员都有对美的追求，其实不亚于艺术家对美的追求。同样做一件瓷器，普通工匠的只是放在大街上叫卖，大师的作品却是陈列在博物馆中价值连城。工匠与大师的区别，就要看他做出来的作品是平庸还是精妙。大师也是从工匠出身的，经过对美的执着追求，不断磨练，终于练就出不凡的手艺。

Make it work, make it better, 我很认同这句话，work是基本的价值所在，better是进一步发掘价值。就像创造一个雕塑，最先是要搭起骨架，然后制作泥胚，总体形态具备后，在逐步加工，细化，最后才是细节的精雕细琢。

可是，我们永远做出来的都是毛坯，加班加点赶制出一个毛坯后又匆匆忙忙赶制下一个，从来都没有制成过成品，甚至没有人在脑子里设想过它的样子。不断的重复着的都是制造半成品的劳动，别说要成为大师了，想要成为好工匠都很难。

也许有人会说，精益求精这只是工匠的个人追求，老板们追求的可是如何赚更多的钱啊，做得越快，卖得越多不就赚得越多吗。

刚才写的东西一个误操作就没有了:(

其实我一般都比较小心的，重要的东西通常都先写好再贴到web page上。刚才丢掉的东西虽然觉得不是很重要，但丢了还是觉得很可惜——浪费了时间和心情啊，肯定不会重新再写一次了。

以后要记住，不能再直接在浏览器上写东西了。

昨天晚上把我的另外一个blog的程序升级到WordPress 1.2, 升级本身是非常简单的, 正如wordpress网站上说的, installing WordPress and upgrading from previous versions and other software is a piece of cake, 它的安装升级脚本做的非常完善且友好, 访问一个URL点击几次next就做好了, 因为是全web化的配置, 保存在数据库中的, 一切都自动完成. 不过update我自己的页面template耗了些时间, 因为新版本提供的函数有些更改了, 必须手工修改, 如果用它的default template就不需要费这些功夫.

我的blog从最早的b2, 到WordPress 0.5x, 到现在的WordPress 1.2, 几次升级, 感觉这个软件越做越好了. XML-RPC的支持, email-blogging, 可自定义字段, link manager, 层次化的category, 多作者, 图片上传和自动生成缩略图, 保存草稿… 还有好多细节方面的功能都不错.

我还考虑过是不是该把blogbus上的这个blog也搬到自己的WordPress上边去, 不过暂时blogbus还是用得不错, 搬起来挺麻烦的, 而且它的HTML编辑挺方便, WYSIWYG, 还是等等再说吧.

mbs: multi byte string, 用char作为存储类型, 一个字符可能对应1个或者多个char, 不能直接确定字符边界. charset不确定. 过去的程序都是采用mbs的.

wcs: wide character string, 用wchar_t作为存储类型, 一个字符对于一个wchar_t. 使用unicode编码, charset与OS相关, 在windows平台中为UTF16(UCS-2), 在大多数unix平台中为UTF32(UCS-4).

国际化的程序都应该在内部使用wcs, 在输入输出时做mbs与wcs的转换.

mbs与wcs的转换函数:

wcstombs/mbstowcs是实现转换的一对函数. wcs的charset是固定不可变的, 但是mbs的charset是可变的, 可能是ASCII, 可能是gb2312, 也可能是big5. wcstombs/mbstowcs是根据locale环境设置来决定mbs采用的charset的, 在程序中可以用setlocale来设定locale, 例如 setlocale(LC_ALL, “chinese”)

没有想到，欧洲航天局网站上的一张卫星照片引起了国内沸沸扬扬的讨论，而且讨论还大有向民族精神升级的趋势，真让人哭笑不得。

由于个人爱好，曾经专门找过一些有关卫星遥感的资料来看，卫星照片也看过一些。且不论卫星照片上可见到长城与太空飞船中肉眼是否可见长城有些什么联系，至少我认为欧洲航天局公布的这照片上的根本不是长城。

先来看看欧洲航天局公布的照片吧：（照片很大，请在新窗口中打开）http://esamultimedia.esa.int/images/Proba/cina.jpg 照片右上角蜿蜒的白线就是被认为是长城，左下角很粗的白线是河流。

在判读卫片、航片时，立体感不是那么直观的，很容易把山脊当成了山谷，山谷当成了山脊，因为都是明暗交界线，不知道阳光方向就很难断定那儿高一些。判断的一个比较有效的方法，就是从河流看起，有河流的地方必然是山谷，两边的是山脊，山谷和山脊是交替的。

原图为了突出右上角，将其余部分增加了亮度，为了分析照片，我用photoshop把图象做了还原处理。http://sunnyday.cn2k.net/photo/cina_edited.jpg

同事刚买了几本书，包括了《你的灯亮着吗》。马上拿过来读，书很薄，字很疏，一个来小时就读完了。

看完后有点失望，也许是看书评后期望太高，也许是我并不适合读这样的书，不懂从中领悟些什么。

翻到最后一页，才发现译者在译后记里面已经把这本书的中心思想全归纳出来了。我觉得比较有共鸣的是几点：

• 意识到问题的存在，与熟视无睹做斗争
• 想想什么才是真正的问题？问题的根源在哪里？
• 想想这是谁的问题？谁是应该解决问题的人？

Subversion这个以替代CVS为目标的版本管理工具，看来已经开始获得广泛支持了。经历了4年开发，大概1个月一次小版本发布，今年年初终于发布了version 1.0 release，开发过程平稳而谨慎。我去年曾经试用过一个interim release版本，作为本地个人使用的版本管理工具，已经感觉相当满意，基本可替代CVS。现在release版本发行后，更是在网上看到一些人说打算从CVS迁移到SVN了。在网上可以找到一些达到实用阶段的兼容subversion的软件工具、plugin，从另一个侧面也反映出subversion正在一步步迈向自己的目标。

以前公司的开发团队使用CVS，配合使用CVStrac，对于这样的搭配我感到比较满意。CVStrac作为轻量级的issue tracking工具，确实做得很到位，issue/bug record、CVS track-in record和wiki的无缝整合，构成了简单而实用的web base软件项目管理系统，对于小型项目非常合适。

现在，与SVN配合的类似工具也有了，Trac，完全就是CVStrac的一个clone，不过是用python开发的，从screenshot上看很漂亮，细节上似乎做得比CVStrac要好。不过现在公司用ClearCase，没有机会试用这些轻量级工具了。我觉得ClearCase的client并不好用，缺乏象cvsweb这样的直观的文件、目录浏览、trac这样的check-in浏览功能。

在SAX和DOM两种paser API中，均提供了EntityResolver接口，应用程序可通过实现这个接口的resolveEntity()方法来实现对外部实体访问的控制，例如将对网络URL的访问重定向为对本地文件或者数据库的访问。Xerces软件包提供了例子redirect来演示这个功能。

在我们的程序中，parse VXML文件时需要使用外部的schema，而这些schema又会间接引用其他的schema或者DTD，这些外部实体都是通过URL形式的system id来指定的（基本上都是在www.w3c.org上）。考虑到程序运行环境不一定与internet连接，还有远程网络的效率也不高，我们在程序中实现了自己的EntityResolver，把所有对这些schemas、DTDs的访问都截取下来，返回程序中内置的拷贝。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

class DTDResolver : public EntityResolver {
public:
    virtual InputSource * resolveEntity(const XMLCh * const publicId,
        const XMLCh * const systemId)
    {
        if (Compare(systemId, L"http://www.w3.org/TR/voicexml20/vxml.xsd")) {
            VXIcharToXMLCh name(L"http://www.w3.org/TR/voicexml20/vxml.xsd (SB)");
            return new MemBufInputSource(VALIDATOR_DATA + VALIDATOR_VXML,
                VALIDATOR_VXML_SIZE,
                name.c_str(), false);
        }

        if (Compare(systemId, L"http://www.w3.org/2001/xml.xsd")) {
            VXIcharToXMLCh name(L"http://www.w3.org/2001/xml.xsd");
            return new MemBufInputSource(VALIDATOR_DATA + VALIDATOR_XML,
                VALIDATOR_XML_SIZE,
                name.c_str(), false);
        }

        if (Compare(systemId, L"XMLSchema.dtd")) {
            VXIcharToXMLCh name(L"XMLSchema.dtd");
            return new MemBufInputSource(VALIDATOR_DATA + VALIDATOR_SCHEMA_DTD,
                VALIDATOR_SCHEMA_DTD_SIZE,
                name.c_str(), false);
        }

        // ......

        return NULL;
    }
};

// ......

parser = XMLReaderFactory::createXMLReader();
DTDResolver * dtd = new DTDResolver();
parser->setEntityResolver(dtd);

在测试中发现，对某些外部实体的访问成功截取了，但是另外一些却不成功，parser依然尝试通过网络访问，然后由于网络不通而访问失败，造成xml文件无法parse。

对程序进行跟踪，发现了问题出现的规律：所有对schema文件的引用处理都正常，无论是include还是import方式，也无论是多少层的间接引用；在被parse的XML文件中DOCTYPE声明的外部实体引用，处理也正常，故此xerces自带的redirect例子是不会出问题的；但是，schema文件的DOCTYPE声明的外部实体引用就不能被正确处理了，根本不会调用指定的resolveEntity()方法。

编写测试程序, 发现超过1000个线程, 程序执行就会出现内存错误. 原来我还以为是windows对线程数量有限制, 查资料才知道支持线程多少并不是操作系统决定的, 而是与程序的堆栈空间大小有关.

在VC中, 修改Project Setting - Link - Stack allocation - Reserve, 缺省为1M(0x100000), 将这个数值降低, 也就是减少每个线程的栈空间大小, 就可以增加线程数量. 这是因为用户地址空间总共是2GB, 线程保留栈空间大小乘以线程数量不能大于2GB.

因为上下文切换的开销, 线程过多效率会降低, 我做这个测试程序就是想知道这个效率曲线到底是怎样的.

以下为网上找到的资料:

I just found this under CreateThread() in MSDN:

不知不觉的，差不多三十岁了。都说三十是人生一个关口，对于一名程序员尤甚。即将告别人生的一个段落，回望过去，看到自己存在不少缺点；展望未来，路要怎么走，不免有些患得患失。

前两天跟flyisland聊天，他说（书上说）：失败的最重要原因，是没有长期目标；第二个原因，是没有短期目标。是啊，总是觉得时间过得很快，到底时间是怎么过去的呢？做些什么不做些什么，年轻的时候可以恣意而行，但现在不行了。

经常会有这样的时候：无所事事不知道该干些什么，过后又后悔浪费了时间。目标不一定要很远大，它指引的是方向，帮助自己排除干扰，做出每个选择，什么是值得做的。不是说做的每件事情都需要有意义，而是做完之后不需要后悔就好了。多些思考，少些漫无目的，

长夜孤灯（很好的名字），这个blog的主人把他在人生目标，个人计划这方面的思考记录下来。看了很有同感，为人理性，爱好思考，但个性稍微消沉，容易患得患失，似乎自己与作者有共通之处（flyisland也是这么说的，难道大家都一样？）。他提到的很多问题也是我的问题，看看他写的东西，反思自己，很有好处。

应该怎样做？继续思考，坚持于行动，一点一点改进。记录下来，自勉。