开发记事本

上一次写博客竟然已经是2006年了，时间真快，或者说，我偷了好长时间的懒。

这两年工作和生活都有所进步，希望以后的路都能够顺顺利利地走下去。

两年来的流水帐：
2006年10月10日：离开从2000年6月5日开始工作了6年多的原公司，在家休息了三个月；
2007年1月11日：进入现在的公司，被外派到微软作为Vendor工作；
2007年5月23日：奔三升级奔四；
2007年9月到12月：去微软总部工作3个月；
2008年5月6日：签订购房合同，成为房奴；

前几天在5460上看到同学们在嚷嚷毕业十周年的聚会，时间真的好快啊，转眼就十年了。

问题的产生：
对于采用Copy-Modified-Merge方式的版本控制系统，冲突的管理和解决是非常重要的。
目前公司的一个项目由于系统的版本升级，系统的源代码在开发过程中有大量的文件重命名操作，原有的CVS不支持文件重命名，每次都需要删除原有文件，再重新导入新的文件，导致文件更改历史丢失；为了解决这个问题，我们把版本控制工具从CVS改成了Subversion，客户端从TortoiseCVS改为了TortoiseSVN；由于TortoiseCVS和TortoiseSVN的使用极为相似，因此转移后大家在使用上并没有遇到什么问题——除了对文件冲突的解决方式；

问题的详细分析：
在文件的合并发生冲突时，冲突文件主要有以下几个版本：
Base：自己的工作复本中该文件的原始版本
Mine：自己的工作文件
Theirs：版本库中的最新文件
Merged：在TortoiseSVN中自动合并后的文件，在该文件中，用如下方式标识了文件中发生冲突的部分（这种方式似乎是Unix世界的通用方式？）：
<<<<<<< filename
    your changes
=======
    code merged from repository
>>>>>>> revision

在 TortoiseCVS 中，对冲突文件的合并是用Mine和Theirs进行比较进行的，合并后的文件即作为工作复本中冲突已解决的新文件；而在TortoiseSVN中，对于冲突的文件（比如ConflictFile.txt），会自动生成以下几个文件：

ConflictFile.txt.mine（自己的工作复本Mine）
ConflictFile.txt.rBaseRevision（原始版本Base）
ConflictFile.txt.rNewRevision（版本库中的新版本Theirs）
ConflictFile.txt（合并后的文件Merged）

TortoiseSVN 的冲突解决需要对以上文件进行比较合并，最终将所有的修改都合并到Merged版本中，然后将冲突设置为已解决；但是由于工作复本、版本库的新版本以及合并的目标分别存储在三个文件中，因此TortoiseSVN的冲突解决就需要使用支持三向比较（3-Ways）的比较/合并工具，比如TortoiseSVN内置的TortoiseMerge（免费），或者Araxis Merge（收费）；原来我们在TortoiseCVS中使用的Beyond Compare就无法使用了，因为BC只支持对两个文件进行比较，在TortoiseSVN中使用Beyond Compare作为合并工具的话，就还需要手工作很多工作——大家就是对这一点非常不适应。

问题解决方案：
1.编写如下的批处理文件（注意将Beyond Comare的路径改为实际的路径）：
"D:\Applications\DevTools\BeyondCompare2\BC2.exe" %1 %2
Del %3
Del %4
Del %2
Copy %1 %3
Del %1

2.在TortoiseSVN的Setting中选择合并工具（Merge Tool）页面，设置使用外部合并工具（External），在命令行中设置外部合并工具的命令行如下：
"D:\Applications\DevTools\TortoiseSVN\TSVNMerge.bat" %mine %theirs %merged %base

3.在使用TortoiseSVN编辑冲突文件时，系统会自动打开冲突文件的Mine版本和Theirs版本进行比较合并，用户将所有的修改合并到Mine版本中，当手工编辑冲突完成后，将自动用合并后的Mine版本替代Merged版本，并删除其他文件；这时使用TortoiseSVN的“标识为已解决”，即可进行提交。

此方法可以使用任何支持双向文件比较/合并的工具。

解决方案存在的问题：
这不是一个完美的解决方案，由于使用的是功能有限的批处理文件，因此存在以下问题：
1.无法判断用户是否进行了合并操作，如果没有进行合并操作，也会进行后面的删除和复制操作；
2.有时候会发生复制时提示Merged文件无法修改的情况，这可能是由于比较工具尚未完全退出造成的；

上面的问题可以通过自己编写程序解决，第一个问题通过用文件监视器监视Mine文件来判断是否进行了修改；第二个文件可以通过监视比较工具的进程进行判断。

很久没有去过CSDN了，今天上去发现首页上有一篇《开源GPL中触目惊心的学术腐败》，题目很是触目惊心，于是去看了看，结果发现是“太极语言”的创始人universee在对GNU/GPL大放厥词，开始还很是诧异，按universee的说法，他好歹也算是自己开发了一个新的语言，怎么会说出“没有GCC编译器，LINUX内核源代码稍微改动一下在MICROSOFT VC/MASM底下编译也是照样可以”这样的话，难道真的是天才现身，把Linux内核改动两行代码就能在VC下编译了？

看了《开源GPL中触目惊心的学术腐败二》以后，才发现原来universee对编译器和IDE都没有搞清楚，而且简单地把开源和GPL画上等号，不过还好知道GPL的核心内容是使用了遵循GPL协议的源代码，则必须遵循GPL协议开源。

而且universee一直在为麒麟开发组做着很没水平的辩护，看这一段：

我们的麒麟OS开发人员肯定很辛苦的，做为中国人应该对我们同胞的工作表示鼓励，而不是思维定势首先怀疑。我认为麒麟OS能用FREEBSD内核替换启动并不能证明麒麟OS就是抄袭的。反而充分证明了麒麟OS不是抄袭的，因为抄袭者必定心虚，必定至少做到内核替换则不能启动（这根本用不了几句话，很简单），否则这漏洞太大了吧，敢唱空城计的可不是一般的啊。那么目前保持内核兼容性的原因是什么呢？可能是为了把FreeBSD上许多软件都迅速移植过来，而不是再重新开发。

这种辩护让我觉得universee不是麒麟开发组的开发人员，就是麒麟聘的枪手；如果是前者，那么这样水平的开发人员很明显不可能做出什么高水平的系统，如果是后者，那么麒麟的运作水平实在太差了，找枪手也要找水平高一点的啊……

借用网友jiangtao9999的评论：“什么都不知道不是你的错，但出来丢人就是你的不对了。”

这种文章居然被放在CSDN首页上，嗯，我得说，我对CSDN是越来越看不懂，越来越失望了。

CSDN上还有另外一个活宝：Sinox的“汉澳操作系统”；大约从2003年起Sinox就以一种妄想狂的姿态在CSDN上宣传他的汉澳操作系统，时至今日仍然不改初衷，不时地出来喊两嗓子；不过从来没有见过CSDN对其有过什么处理措施。

这两位可以称作CSDN双雄，用梁启超的评价方法，一个是“狗放屁”，一个是“放屁狗”，就这点区别而已。

前段时间刚刚向大家推荐了DotNet下的开源图形控件The Netron Project，才不过半个月的时间，Netron项目就没有了，真是世事难料啊。

在CodeProject上（http://www.codeproject.com/script/profile/whos_who.asp?vt=arts&id=524590）Netron的作者Francois *Swa* Vanderseypen有一个简单的自我介绍，这篇自我介绍说明：Francois实实在在是一个天才：

Job: .Net architect in Belgium. Heterogeneous integrations, now more than ten years in the field. Time flies...During working hours I play with IBM Tivoli, SQL Server, mainframes, WebSphere MQ and everything in between. If you have a challenging job for me, drop me a note

Interests: as good as everything, but with a PhD in theoretical physics you can assume I spend a lot of time with mathematical ideas and complexity. Quantum gravity (Loops and knots) in my nostalgic moments. I tend to improvize a lot on my piano and thanks to the blogging phenomenon I write quite a lot of pseudo-philosophical essays.

天才可以写出一流的软件，但未必能够成功地推动一个开源项目，非常优秀的The Netron Project似乎名声不是很大。

Netron的最后版本2005年夏天发布的v2.2.2036；在2006-01-19作者发布新闻：预计将在七月份发布全新的3.0版本，功能也将比2.2强大更多；

然而我们可能永远都无法等到这个版本了。

在我向大家推荐Netron的时候，Netron的主页（http://netron.sourceforge.net）已经无法访问，所有的资料全部丢失，取而代之的是一首诗：

The truly creative mind in any field is no more than this:
A human creature born abnormally, inhumanly sensitive.
To him…
a touch is a blow,
a sound is a noise,
a misfortune is a tragedy,
a joy is an ecstasy,
a friend is a lover,
a lover is a god,
and failure is death.
Add to this cruelly delicate organism the overpowering necessity to create, create, create -
so that without the creating of music or poetry or books or buildings or something of meaning,
his very breath is cut off from him.
He must create, must pour out creation.
By some strange, unknown, inward urgency he is not really alive
unless he is creating.

(Pearl Buck)

这个时候很难知道发生了什么事情，大约2006-06-13左右，访问netron.sourceforge.net看到的是如下的内容：

Give me,
a job with free spacetime for working on diagramming stuff,
a fair allotment and good coffee,
no commercial worries, just faith in innovative ideas.
In return I can give you
the best .Net open source around,
creativity and passion unlimited,
an inspiring and erudite compeer,
impartial friendship, true commitment.

Let me,
be.

Until then; I am sorry.

看来作者对于工作和爱好的矛盾已经无法调和了（是谁说国外搞开源的程序员都是在衣食无忧的情况下搞开源的？），但是因此而删除网站内容的行为似乎不太应该，由于Netron项目一直缺乏很详尽的文档，Netron主页上的资料（主要是其中的一些教程）对于Netron的学习和使用是至关重要的，删除网站内容对于Netron的使用会造成非常大的困难。

随后，Netron在SourceForge（http://www.sourceforge.net/projects/netron）上的项目内容除了CVS仓库以外全部被删除，共同开发人员也已经被Francois删除，再去访问netron.sourceforge.net，则是如下内容：

While I beg you for your financial help,
you continue asking me my latest code
just to make sure
your business can continue.
My God,
the open source world is truly
a cruel place!

看来作者在寻求帮助的时候，得到的却都是索要源代码的请求，因此对开源已经失去了信心（the open source world is truly a cruel place!），做出了一个很极端的举动。

我想没办法责怪作者，毕竟自己为之付出了那么多的心血，却得不到积极响应是件很让人伤心的事情。

不过开源的好处在Netron目前的情况中得到了相当好的体现，Netron关闭后，用户only_me在SourceForge上注册了一个新的项目：Netron Reloaded；这个项目将延续Netron原有的代码和文档，并将作为Netron官方版本之外的一个分支继续开发下去。

这一期（2006年第7期）的《程序员》杂志在描述Ubuntu Linux的时候有一段话，用来说明Netron的当前状态很合适：“只要它仍然有益于社区，就会有人站在它倒下的地方，继续前行。开源的魅力正在于此。”

现在的情况：
Netron的主页（http://netron.sourceforge.net和http://www.netronproject.com）都指向了一个商业图形软件的订购页面；有人说是作者把Netron卖给了商业网站了，也有人说作者是想让大家看看Netron项目有多高的价值。

Netron Reloaded项目已经恢复了Netron项目在SourceForge上发布过的原有的文档和源代码的下载，only_me在2006-06-15说将在当晚恢复代码的CVS仓库，但是时至今日Netron Reloaded的CVS仓库仍然是一片空白。

Netron项目使用的协议是作者自己编写的一个协议，Netron Reloaded项目则采用了LGPL开源协议，尽最大可能地保证了和原协议的兼容，但是有人指出擅自改变原有代码的授权协议并不合适。

希望Netron Reloaded能够一路走好，也祝愿Francois能够找到一个更好的工作，能够有足够的时间和资源 working on diagramming stuff。

1.开源项目：The Netron Project(http://www.sourceforge.net/projects/netron)
说明：Netron是用C#开发的一套功能及其强大的图形库，目前最新版本是2005-07-29发布的v2.2.2036，如果你要用DotNet开发一个Diagram程序（例如开发一个类似Rose的建模工具），那么用这个图形库会是一个不错的选择。
具体功能可以自己运行代码中的Cobalt项目体验一下。

注意：Cobalt项目中有一个窗口是不符合CLS规范的，编译时会发生错误，我的解决办法是把Colbat项目的AssemblyInfo.cs中设置[assembly: CLSCompliant(false)]，这样可以编译运行。

可惜前段时间不知道什么原因其网站(http://netron.sourceforge.net)内容突然消失，取而代之的是一首英文诗，原因不明，这样原来的网站上很多文档都丢失了，现在只能看代码学习。

据作者在2006-01-19发表的声明，最新的3.0将在七月份发布，届时将是一个全新的图形库，不仅仅是功能的增强，连接口和架构都会完全改变——听上去似乎不是很美妙；但是现在网站消失了，不知道原定的计划是否仍然会继续执行。

2.免费工具：Editor4NAnt(http://www.codeproject.com/useritems/editor4nant.asp)
这是一个NAnt构建脚本的工具，可以对NAnt构建脚本进行可视化的编辑、测试和执行，类似贵得要死的Nantpad，不过是免费的，功能上也不比Nantpad差；这个软件的作者是班加罗尔的一个印度程序员，居然还是一个Project Leader。

遗憾的是需要DotNet Framework 2.0才能运行。

另外TortoiseSVN升级到了1.3.4，并终于推出了x64版本，在64位Windows下使用Subversion终于不用再打开32位的资源管理器了；昨天看到了digiking的《TortoiseSVN：Subversion客户端》，觉得“将Blame翻译成谴责真不好，其意思只是追根溯源”说得很对，把Blame翻译成“追溯”更合适。

 

Windows平台下使用Active Directory对Subversion进行权限控制（非完美解决方案）

 

目前网上找到的Subversion的配置说明中，关于用户权限控制都是基于Apache的User文件的或是基于svnserve.conf文件的，这种配置方式最大的问题在于用户信息保存在独立的文本文件中，维护不便（对用户的添加、修改等必须在服务器上执行，用户自己无法修改密码等），并且无法和其他系统集成。

 于是琢磨可不可以用公司现有的Active Directory对Subversion的用户进行权限控制，这样可以解决上面提到的几个问题。

 目前已经基本实现了对Subversion使用Active Directory验证，但是还有一些比较重要的问题没有解决，所以是“非完美解决方案”，放在这里抛砖引玉，希望能够有更好的解决方案。

 Apache不能直接调用Active Directory的，只能通过Active Directory提供的LDAP方式进行访问，因此需要在Apache中打开对LDAP的支持；

 Apache中自带了对LDAP的支持（默认情况下没有打开），但是官方自带的LDAP支持插件在Windows平台下有问题（我这里是经常造成Apache异常退出，服务终止）；因此在Windows平台下需要安装第三方的LDAP支持插件才可以。

 在网上找了一下，发现Apache的LDAP支持模块有以下几个可供选择（来源：http://nona.net/software/ldap/）：

我使用的是http://www.muquit.com的mod_auth_ldap，对其他的没有试过。

 

一、 安装（假定已经安装了Apache+Subversion）

1.        安装文件的获取：

mm_mod_auth_ldap for MS Windows binary：从http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html下载。

由于mm_mod_auth_ldap是基于Sun的iPlanet C SDK 5.08开发的，运行时还需要iPlanet C SDK 5.08的一些DLL，因此还需要自己下载iPlanet C SDK 5.08（http://www.sun.com/download/index.jsp?cat=Application%20Development&tab=3，需要注册才能下载）

2.        安装和设置（来自http://www.chinaunix.net/jh/49/618651.html）:

1)       将上面所说的两个压缩包中的DLL文件复制到Apache的modules目录中；

2)       在httpd.conf中加入 LDAP 相关模块的配置，就是增加如下一行：

    LoadModule auth_ldap_module modules/mod_auth_ldap.dll

 

二、 配置

如下是httpd.conf中Subversion段的配置，注意红字的部分就是LDAP的配置信息，具体意义参见注释；其他关于Subversion和Apache的配置资料请参见网上相关文章（例如http://cube316.net/blog/archives/200512/32）。

 <Location /svn>

    // 常规Subversion配置

    DAV svn

    SVNListParentPath on

    SVNParentPath D:\SVNStore

    AuthType Basic

    AuthName "Subversion repositories"

    # 不能使用svnaccessfile进行配置，原因见后

    # AuthzSVNAccessFile conf\svnaccessfile

    Require valid-user

   

    # 以下为LDAP配置信息

    # LDAP 协议版本，AD提供的LDAP为3

    LDAP_Protocol_Version 3

    # LDAP 服务器

    LDAP_Server 192.168.1.2

    # LDAP 服务器端口

    LDAP_Port 389

    # LDAP 基础DN

    Base_DN "dc=MainDC"

    # AD 的 LDAP 不允许进行匿名查询，因此需要提供一

    # 个 AD 中的用户名及其密码用于 Apache 的LDAP查询

    Bind_DN "cn=Administrator,cn=Users,dc=MainDC"

    Bind_Pass "password"

    # 供 Apache 查询的 AD Object 的属性

    UID_Attr "sAMAccountName"

    # 允许什么条件的 AD 用户访问 Subversion；

    # 这里设置只有scmuser组的用户才可以访问，但是并没

# 有成功，事实上只要是AD中的用户现在都可以访问，

# 不清楚问题出在哪里。

    require group "cn=scmuser,ou=groups,dc=MainDC"

</Location>

这样配置的意图是允许SCMUser中所有用户可以存取Subversion，其他的用户则不可以，但是事实上这样配置以后的实际结果是AD中所有用户都可以访问Subversion了，怀疑是require group中的LDAP Filter写的不正确，但是不知道该怎么写，目前就凑合着用了。

 

三、 问题
使用LDAP可以和其他系统比较好的集成，并且能够方便地对用户进行管理，但是这种方式对于Subversion很有问题，就是使用这种方式后无法使用AuthzSVNAccessFile来对Subversion进行目录级别的权限控制，据网上资料说是因为SVNAccessFile中的用户和组都必须在User文件中定义（参见http://svn.haxx.se/users/archive-2006-02/0586.shtml及其相关讨论），我想如果对Apache的授权模块进行自定义修改的话估计是可以的，不过目前我们对此要求不高，所以还暂时能够使用。

 

四、参考资料

1.        《开发服务器环境配置安装说明》（http://bbs.chinaunix.net/viewthread.php?tid=618651）

2.        《LDAP authentication module for apache》http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html

3.        《Subversion Users List Archives》http://svn.haxx.se/users/

 

DotNet 项目中链接文件的用处

首先，什么是链接文件？

在VS.Net中打开一个WinForm项目或者DLL项目（在Web项目中不能使用链接文件，感谢dudu指出），在随便一个项目中右击鼠标，选择“添加”→“添加现有文件”（抱歉，手头的机器太差，没有装VS.Net，所有的操作说明全凭记忆，如果有出入敬请原谅），随便选中一个文件，不要选“打开”，点击“打开”按钮右侧的下拉菜单，选择“链接文件”；

选中的文件已经添加到了你的项目中，但是这个文件和你平常添加到项目中的文件是不一样，这仅仅是一个指向你所选择文件的链接，相当于一个快捷方式；文件在你指定添加的位置上是不存在的，但是你可以照样地对这个文件进行编辑、编译等操作，和普通文件地使用并没有什么不同；

链接文件有什么用处？我能想到的大概有这么几个：

1.给可执行文件项目进行单元测试；
由于被测试的项目必须是DLL，才能够被NUnit单元测试项目引用而进行测试，因此如果你把逻辑代码放到了可执行文件项目中，NUnit就无用武之地了；

这种情况下要进行单元测试，可以新建一个DLL项目，通过链接文件把可执行文件下的所有文件都进行链接，然后把NUnit单元测试项目的引用指向这个项目，这样就可以用NUnit进行测试了；当你的可执行文件进行了修改的时候，“链接项目”的编译结果也会是最新的。

2.引用其他可执行文件项目
如果你要在自己的项目中引用其他可执行文件项目中的代码，除了将被引用项目的属性临时修改为DLL，编译后再改回来，似乎没有其他办法了。

类似上面对可执行文件项目执行单元测试的情况，我们同样可以使用链接文件解决这个问题：新建一个引用被引用的可执行文件项目的DLL项目，将你自己的项目引用指向这个新建的DLL项目即可；

上面两种情况，究其根本都是系统设计不当造成的，重构或者修改设计可以避免这种问题，但是实际中总是很难做到，用链接文件作为补救措施总还算是一种比较好的亡羊补牢方式。

3.给一个解决方案中的项目统一版本信息和签名信息
一个项目的版本信息和签名信息是在该项目的Assembly.cs文件中指定的，将所有的项目中的Assembly.cs文件都链接至同一个文件，以后只要修改这个Assembly.cs文件中的内容，就可以保证所有项目的版本信息和签名信息都是一致的。 NAnt 项目的 Build 过程就是这样的。

以前听到的都是关于国内的软件公司是如何如何的烂，昨天听到一件事，才发现原来美国的公司烂起来也不是一般的烂啊。

事先声明，这是听同事说的，道听途说的消息，我姑妄言之，大家姑妄看之，不要太当真，借用港台片的一句老词：如有雷同，实属巧合。

有个在世界范围内排前几名的国外公司在国内有一个生产厂 A，A 承担了该公司某种产品的大部分的生产任务，出于提高生产效率，降低生产成本……等等目的，该厂决定采用美国 B 公司的一套管理系统（一个很复杂的名称，我就称之为管理系统吧，大家都明白的）。

该系统是使用的是 .Net 平台，基于 B 公司的一个开发平台开发，这个开发平台是 B 公司针对类似于 A 公司的生产企业开发的一个通用型平台，对于特定的项目只要根据业务流程在这个开发平台上进行二次开发即可。

经过一段时间（我不知道具体是多长时间）的开发之后，该系统开始上线试运行，这时候问题来了：系统的稳定性先不说，产品的一个检测数据录入步骤就长达30秒，大大的制约了生产效率。

找 B 公司询问，B 公司开发人员称是你们的服务器不行，需要使用 Compaq 的 xxx 服务器；于是 A 公司去找中国 Compaq，中国 Compaq 的人说不好意思，这款产品我没听说，大概是不在中国销售的型号吧，我帮你跟美国总部问问；过两天打电话来了：老大，您这消息哪儿来的？那款服务器是美国 Compaq 的产品不错，不过要到明年上半年才开始销售呢……

最后好像服务器是采用了十几台服务器（具体怎么个组织法我就不知道了），然后还是三天两头问题不断：系统崩溃，数据同步失败，少有能正常运行的时候。

就在这样的状态下，B 公司在现场的维护人员少得可怜，据亲眼看到的我的同事说，当时系统已经在生产线上运行了，问题还很多，但是 B 公司在现场只有两个人，一个是经理级别的，不怎么写代码，另一个则是新手，基本上等于什么都不懂。

最终的结果是试运行了大半年了，这套系统仍然没有达到预期的目标，从同事给我说的情况来看，该系统几乎就是一个废物。

最近，B 公司向 A 公司发出通知，该项目的合同和贵公司支付给我们额费用都将到x年x月x日终止，届时我们将终止对该项目的维护……而到此时为止，A 公司在这个项目上的投入（硬件、软件、开发费用等）已经超过了 2000 万 RMB。

不过 B 公司还没有太过于“甩手”，告诉 A 公司，我们可以将该项目转给 C 公司，这是我们的一个合作伙伴，他们可以继续把这个项目维护下去，当然，合同和费用需要另外协商……C 公司已经来人考察，确定是否接手该项目。

这个项目问题出在什么地方？我不知道，但是肯定不在技术或者经验上，B 公司的经验和技术绝非泛泛之辈（否则 A 公司也不会选择他们），我看过他们的开发平台，没有相当丰富的经验，没有很强的技术是做不出来的（仅凭我个人的感觉，我没有那个资格也没有那个实力去评判）；但是为什么搞的这么糟糕？有一件小事可以让我们管中窥豹：半年前有一个报表需要修改，修改内容是将报表上的某个选择项从 DropDownListBox 的单选方式改为 CheckBox 多选方式，修改要求提出后 B 公司多次声称这个选项没办法改，于是这个要求就在 提出→拒绝→再提出→再拒绝 的死循环中始终都没有修改过；上个星期 C 公司的考察人员中有一个小伙子花了一下午的时间，完成了这个报表的修改（&%#$^&#$%34），同事说“A 公司那帮哥们脸都绿了”。

现在的状况：B 公司开发这套系统的核心人员——该系统的核心业务部分就是这位老大一个人（！？）在开发平台上完成的——跳槽了（看来这种事不只中国有啊），但是系统的二次开发没有什么文档留下来，现在的开发人员每天都在猜测这位老大当初为什么要这么设计（这个场景似乎很熟悉？）；该系统列出了一个很长的修改清单，有一个 Team（不知道是 A 公司的还是 B 公司的，没有问同事）每天都扑在上面修改，但是系统仍然不稳定，上个星期在线数据库和查询数据库之间的同步失败，一直到昨天仍然没有恢复，结果后台的一些系统就一直因为没有数据可用而处于瘫痪状态；A 公司内部大家都已经选好了公认的替罪羊，一旦项目宣告失败，哼哼……

公司的一个项目打算采用 Smart Client 来实现，出于提高速度的目的，打算在本地缓存一部分基本信息数据，数据量不大，而且仅仅用于查询，除了数据更新不会有大量的更新操作，所以就不打算采用 MySQL、MSDE 之类的大家伙；第一个想到的是 Access，但是 Access 数据库的安全性实在太差；另一个是使用 XML 文件，但是这样就需要对XML文件内容进行加密，不知道效率和查询方便性如何；另外就是开源的嵌入式数据库，比如 SQLite；

于是把 SQLite 的一堆东西下载下来看了看，建表、添加数据都很简单，也有 .Net 的驱动程序，看上去一切都很完美——不过，怎么对数据库加密码呢？

开动 Google，找了半天，找到这么一个结果：http://article.gmane.org/gmane.comp.db.sqlite.general/11374，第二个回复里写的：
>>if you send Dr. Hipp money you can get a version that is protected by a password. It seems like an equitable trade, with everybody happy in the end.

看来想免费加密是没戏啦。

>>If your data is valuable enough to be worth somebody's time to steal, I think it should be valuable enough for you to protect it properly.

这话是没错，不过，不过，俺还是想找一个能免费使用的，可以比较好地加密地数据库……

帮LP找了一个osCommerce做网上商店，给自己在家里的机器上装了一个Plog写日记；都是基于PHP+MySQL的开源项目，在Windows下运行都很顺利，而且都找到了简体中文语言包，用起来很方便。

工作中还用到了TortoiseCVS、Mantis、CommunityServer等开源软件，有些有现成的简体中文语言包，有些需要自己手工修改，有些则只能使用英文版的软件（只能对源代码进行翻译；虽然有源代码，但是对源代码进行一点点的翻译工作量太大，而且这种翻译方法在源代码升级后就又要重新来过）；

使用开源项目的时候发现一个很有趣的情况，就是很多不基于DotNet的开源项目（比如osCommerce、Plog、Mantis等基于PHP+MySQL的Web程序）都提供了很好的多语言化机制，一般会提供文本格式的语言文件，Translater只要用记事本就可以直接翻译，即使是象TortoiseCVS这样用C++编写的EXE文件，也提供了一个.po文件，可以直接翻译；而相对来说，基于DotNet的开源项目则从来没有见过这样简单的机制，大多数都象CommunityServer一样，除非修改其源代码，否则很难彻底汉化，略好一点的象SharpDeveloper，提供了resx资源文件，也需要专门的工具进行编辑；这一点不知道是DotNet本身的机制限制呢，还是这些开源工具的开发者从来就没有想过要这样实现；

最让我觉得恼火的是NDoc，这个软件是最应该提供多语言接口的（最终生成的文档应该是本地化的而不是全英文的），但是它的翻译方法只能是自己手工去修改源代码中的xslt文件，然后再重新编译，否则；

我更喜欢第一种方式，毕竟Translater和Developer是不一样的，有可能Translater对于程序的使用很精通很感兴趣，但对于程序开发根本就一窍不通，所以把翻译工作做的最为简单最好的。