以前一直在使用BCB，主要是基于borland的感情，但是目前的情况看，我得项目不能再跟着borland走了。由于GUI涉及的内容还是不少的，因此转换的过程需要谨慎。经过1个月的评比，参考了很多人的使用感受之后，最终选择了QT，而不是wx。

我先下GPL版本的QT开始学习，安装过程还是狠简单的，中间安装了minGW。然后按照教程里面的Hello Word章节写了一个例子。由于QT没有提供IDE环境，对于习惯于windows下面开发的我还是有一点点不适应。不过倒霉事在后头：（

使用命令
qmake -project
qmake
可以生成3个目录，一个debug，一个release和一个tmp目录，还有3个makefile文件和一个工程文件(.pro)。剩下的make就得借助别的编译器来完成了。开始的时候使用BCB的make，但是提示什么FORCE之类的问题。使用-t vcapp参数生成VC的dsp文件，在VC下面编译，也还是不行。既然本身带了minGW，为什么不用自己的mingw32-make试试呢。最终终于完成了make。不过由于minGW和QT不是安装在一个目录的，为了方便起见，写了个批处理文件：

@ECHO OFF
set QTDIR=E:\Leejd\qt4
set PATH=E:\Leejd\qt4\bin;E:\Leejd\MinGW\bin;%SystemRoot%\System32;%path%
set QMAKESPEC=win32-g++

if exist release del release\*.* /q
qmake -project
qmake
mingw32-make

只要把这个批处理文件扔到你的例子目录下，双击执行就OK！

重构这个名词好像也就是前两年出现的吧，感觉跟我自己理解的优化差不多。前段时间由于时间紧急，我抓紧时间写了一个小程序来用。现在发现这个程序用处还是挺大的，不过当时写的时候没有考虑以后扩展，所以修改以来比较困难。考虑到以后可能还会对现在的这个样子进行扩展，准备把这个软件给重新写一遍，保留一些接口以便以后扩展。

由于原先的代码已经写了不少了，不想重新再写一个，所以直接在原有的基础上进行修改，可以说是重构吧。这次重构需要修改以前的数据结构，把基于STL的数据结构类型改为PyObject的，因此底层基本需要重写，而且准备把这部分从界面代码中独立出来。

经验：函数写的相对要独立一些，类内部的函数也是一样的，不要过分依赖成员变量，这样重构轻松一些。一次改动尽量要少，每次存盘之后最好先编译一把，看看有没有语法错误，防止本次的错误带入到下一次操作中。轻易不要修改数据结构的类型，像我这次由STL转到PyObject的代价还是比较大的。平时写代码的时候就可以考虑重构，不要集中在一起做，有时候长时间做这种工作，会狠无聊的。

今天使用Python来读取二进制文件。直接使用read读取，读入的内容没有错误，长度也是对的，使用了type函数查看了一下内存中的数据类型，发现是str的，初步认为是采用C语言里面的char方式存储。

不过我是要把读入的内容转为内存中的数据结构，需要处理整型等数据类型。由于自己认为是char方式存储的，就直观的认为只要将4个字节的char使用int()函数强制转换一下就没有问题的，不过转换失败。后来咨询了木头，说是要使用struct来处理。查手册，发现struct狠简单，常用的函数就是pack和unpcak。使用unpack函数试试，先google一下，网上面有没有相关的例子代码，发现一个：
print struct.unpack('>I',recv_data[recv_len-6:recv_len-2])[0]
然后就照猫画虎写了一个
("%s")%struct.unpack(">I", buff[462:466])
不过测试结果却出乎我的意料，读出来的数据不对。同时对>号感到奇怪，查手册struct的下半部分，发现>是表示网络字节序方式，而不是我们x86系列的本地字节序，删除>试试，读出来的结果正确。

以前只是在写网络程序的时候要注意网络字节序问题，现在突然发现，python里面也要考虑字节序，看来python的处理考虑的还是狠周到的。不过以后也要注意二进制的字节序问题了，毕竟网络过来的二进制数据会越来越多的，很多程序中应该考虑这个问题。

现在写的程序中，一直都在集成Python，所以对Python的数据结构比较熟悉了。今天使用STL来写一个不带Python的程序，发现STL的结构虽然轻巧，但是感觉Python的数据结构操作起来更是方便。可能是跟这几天一直在用Python的数据结构有关吧。

其实最关键的地方是文本文件的处理，使用Python脚本把文本读进来，处理，然后直接存为Python的数据结构方式，比使用C++读入文本再使用STL方式来保存方便很多。不过Python的数据结构至少需要带一个DLL文件，这对于小程序是一个累赘啊。

最近的这个项目，是利用Python操作文本的方便和快捷性，嵌入到项目中处理文本文件。目前做的就是将Python解释器集成到程序里面，然后附带一个Python24.dll，不过这样好像还是差一个文件的，msvcr71.dll，开始测试的时候，由于机器里面装有Python24,没有测试出来，到客户那里演示的时候，才发现没有这个文件，幸亏带了Python的安装包，要不然就出丑了。

由于昨天对脚本进行了一些改动，改动的结果感觉差不多，就没有测试直接给演示了，导致演示中出现了一个小问题，改动部分的脚本执行有问题，程序调用返回始终是NULL。开始以为是脚本调用错了，后来以为是缓存的问题，总之排除了很多外在的因素后，最后认为Python的脚本有问题。最后查得得结果是处理传出来的数据结构中，脚本处理有问题，导致单独执行的时候没错（因为测试用的数据结构没有和传出来的匹配），但是集成处理有问题。

开始的时候，就是准备将Python执行的日志集成进去，不过由于偷懒，只做了程序的，没有做脚本的。认为脚本在本地执行了，程序再去执行是应该没有问题的，现在发现还有有些不同，需要处理的。看来把Python的执行日志集成进去是必要的，否则临时修改脚本，出错了就不好找问题所在了。

这几天开始试用SVN，以前只是玩玩，现在是正式在项目中使用了。不过svn还没有使用trac来配合，主要是trac没有ZQ说的那么简单，没有配置好。

常用的就是import，co，ci，add等几个命令，使用起来也还是比较简单的。不过在使用move命令修改目录名称的时候，执行发现目录没有改变，不解，google了一下，发现move命令需要使用commit命令才能真正执行。看来应该是采用了事务方式来处理的。

去年8月份的blog中，我讲解了当时的SVN的安装，并针对原始的安装文件中的问题进行了修正。不过从反馈回来的情况看，我的安装后来就不行了，有一位读者说，按照我的做法，apache无法启动，原来是少copy了一份intl.dll的文件。

今天我准备重新使用SVN进行版本管理，apache和svn都安装好了，然后按照我的原先的blog描述进行安装，发现有些文件的名称已经有变化了，没有那位读者提到的intl.dll文件，不过倒是有一个类似的文件。打开apache的httpd.conf文件，发现里面自动加载了svn的模块名称了（在LoadModule里面），而不再需要手工去将LoadModule的前面的#号去掉了。不过仓库的目录还是需要自己设定的，毕竟安装者还是不知道你的目录的。

准备以后慢慢的使用svn进行有所的版本管理，不过得先熟悉svn先。

现在终于可以开始全心的投入到Python的嵌入开发中了。不过由于好长时间没有接触到Python这块，使得原先掌握的嵌入式Python的知识忘记了不少，现在很多时候还是需要重新去温习一遍。从网上查到的资料，搞Python的嵌入式开发还是比较少的，基本都是作为一种开发的辅助来进行。我现在的参考资料只有Python自己手册里面带的C API部分。不过自己的英语水平不行，很多地方看得不是狠明白，主要是阅读速度太慢了，不过幸亏有代码可以试，这样开发起来感觉难度是不算大的。不过刚开始的时候，可能内存处理没怎么注意，不过幸亏是客户端，实在不行可以重启一下机器，不怕：）不过随着开发的进入，这些东西必须注意起来，因为这些东西如果处理不好的话，会影响软件的稳定性，不过在软件的第一个版本中，还是功能要优先实现的。

今天写了一个C++的代码，居然用上了Python的语法，非常郁闷：）就是将字符串转为Python对象的时候，我弱智到了直接使用PyObject *进行强制转换了，实际上应该是使用PyString_FromString进行的，导致调试的时候老是非法操作。感觉还是基本功不扎实，需要加强。

转自：http://stompstompstomp.com/weblog/entries/72/

这是我在查找嵌入Python文章的时候发现的，主要是讲述一些Python嵌入的Tips。

这一个月来，由于自己的一些问题，一直没有碰Python代码，今天看到别人写了一个比较有意思的类，我准备用Python代码改一下。由于手头没有合适的编辑器，直接拿记事本来着，但是写到一半的时候，突然发现自己对Python代码已经有点陌生了，对照着别人现成的类改，一口气居然没法改下来。看来，熟能生巧这个成语还是有一定的道理的。不过等这段事情过了之后，得好好的回到Python继续研究了，不过主要还是侧重嵌入式研究，感觉这个玩意还是比较好玩的。

这几天的代码里面，涉及到了一些字符串操作，自己就老是想使用Python来进行，可惜目前的项目不允许这样做，主要是自己的Python嵌入还没有搞的顺畅。不过以后可以考虑加入，毕竟简单的应用只是多了一个DLL的问题，但是带来开发上的方便是无法想象的:)

前几天,应老大的强烈要求,我花了几天晚上的时间,帮老大草草的做了一个CRM软件(嘿嘿,老大要我这么叫的),由于CRM方面的知识我了解的不多,因此,我是参考了一个很简单的CRM做的.不过由于时间简单,很多的地方功能没有实现,测试也只是简单的进行了功能测试,而且只测试了常用的功能,有些功能根本就没有进行测试,然后就冲冲的给老大发过去了.

首先,老大那边说不能运行,发现是数据库的驱动没有带走,我只给他一个可执行文件和一个数据库文件,落下数据库驱动了.后来又发现,缺少一个midas.dll.我这次是首次使用BCB的midas组件进行开发,以前没有发布过,这次首发,没有考虑,郁闷啊.以前老大很信任我的,现在这么搞,在老大心中的信任度严重下降,汗!

老大当初给我了很多的需求,这次来信向我抗议,怎么好几个需求没有完成啊?我以核对,还真是呢.汗!没法,用excel把老大的需求做到一个列表里面,以后每次给他版本的时候,我可以核对一下,哪些需求还没有完成.

地址:http://wxmozilla.sourceforge.net/

wxMozilla is a project to develop a wxWindows component for embedding the Mozilla browser into any wxWindows application. The wxMozilla classes use Mozilla's XPCOM (Cross Platrom COM) interface to embed a HTML browser or editor within the application.

一直以为,如果自己的程序想嵌入网页,而且兼容性要好一点,就只能使用IE,但是今天突然发现这个家伙,呵呵,看来嵌入firefox也是有希望的啊.

这个月确实够忙的,从5.1加班开始就忙,一直到现在还没有结束,估计得再坚持一个半月才行.年后,公司的海外业务高歌猛进,害的我们这些海外组的业务设计人员,一个个都拼了老命在努力.我这个月休息,加上5.1也就可怜的5天,还是争取到的,晚上加班,更加是常事了.

最关键的是老大,一直在催着我帮他定制一个CRM软件,说市面上的CRM软件根本就不适合他们公司使用.首先是市面上的软件,需要单独安装数据库,他们的机器装上sql server就会莫名其妙的慢的要死(估计是中毒),别的数据库根本就不会装.所以要求我在程序中内置数据库,不要另外安装.还有,就是CRM里面的内容是要按照他们的行业进行定制,根据发过来的需求看了一下,还算简单,和我们的业务逻辑比起来,简直就是天上和地下的区别.还有要继承短信到软件里面,方便提醒客户和业务员.

诶,5月怎么这么忙呢:(

PostgresSQL
Postgres可追溯至1986年的加州柏克莱大学。该大学在1994年以BSD授权方式将程式码开放给开源码社群，社群则加入了SQL支援，然後一直研发该软体至今。部分原始程式码与设计依然留存至今，不论在Postgres或Informix资料库都还看得到，後者一开始就采用Postgres的程式码，现在则由IBM所有。Postgres是公认最先进的开放原始码资料库，但文件品质则相当受到诟病。

MySQL
瑞典的MySQL AB公司於1995年开始同时以开放原始码模式与商业授权模式来推出此一产品，该公司表示此一「双轨授权」策略有助於站稳财务基础，有利於未来持续改善资料库产品。MySQL以100名员工可称得上是全球最大的开放原始码资料库组织，号称有400万安装基础，也被赞美为最好用的开放原始码资料库。该公司还提供另一个原本由ERP大厂SAP所拥有的开放原码资料库MaxDB，并加以认证用在R/3套装软体中。

Firebird
Borland於2000年将Interbase关连资料库第六版的测试原始码公诸大众，使得它成为全球最新的开放原始码资料库。Firebird现在进入1.5版，优点是体积小，且SQL引擎非常稳定。

BerkeleyDB
属於内嵌资料库，包括Apache、Sendmail、Mozilla浏览器，甚至是Google都采用BerkeleyDB。EMC在部分储存装置上也有使用，而昇阳的LDAP伺服器则仰赖这套程式码。思科与Sony都仅是用户。号称拥有2亿个部署基础，且跟MySQL一样，都采双轨授权策略。