折腾了两天，终于搞定dbexpress+sqlite，一直想架设一个轻量级三层结构，今天终于看到曙光。整个故事要从头说起，且让我一一道来。
起因是因为要开发一套桑拿系统，现在市场上几乎99%的同类软件都是使用C/S结构，后台使用大型数据库(mssql,oracle)，ADO大行其道。2层结构简单、快速、以数据库为中心，几乎都是单一进程，前后台全部合并在一起，各个客户端之间通讯全部通过数据库，安装较为复杂，数据库设置和维护会花费较大的人力物力。虽然也不是什么致命的问题，但我还是希望找到一种更好的方式，我的期望是：
1、数据库采用轻量级引擎，数据库为单一文件，最好是免安装的，这样可以避免长期运行后的维护和备份的困难
2、避免以数据库为中心的架构，尽量把数据库在系统中占据的分量减轻，不使用任何存储过程和触发器，把逻辑放在代码里，避免后期维护的困难
3、系统采用多进程方式，前后台要分开，模块化搭建系统，避免配置参数的无限膨胀
4、多个客户端之间传递消息不要走数据库，而是使用其他方式，以减轻数据库的负担，且可以尽量减少网络中的数据流动，提高效率
5、安装简单，维护简单，升级和配置简单
因为之前一直在做底层，习惯了自己造轮子，所以一开始的打算是自己构建整套系统，使用C/C++编写。基本框架如下：
db engine <--------> midware <------------(network,pipe,share memory)------------> multi-point(client, server manager,multi-process)
数据库引擎很简单，一定会选用sqlite，因为sqlite速度快，尺寸小，移植方便。这里的移植功能是个人的恶趣味，因为我一直想把系统搬到linux下。
中间件是无界面的console进程，默默工作，不做任何多余动作，负责的事情有两条：
1、在db和point之间传递数据和命令
2、在数据库有变动的时候通知各个point，同时负责各个point之间的消息传递
最终的用户端由多个子进程组成，可以任意组合和拆卸，和midware之间使用pipe/memory/udp进行通讯，界面和实现分开，系统底层有一个client-tranfer进程，负责全部的数据传递，GUI通过pipe/share memory和其进行通讯，后台管理和前台分开，互不干涉，但也可以组合在一起
...
阅读全文...
起因是因为要开发一套桑拿系统，现在市场上几乎99%的同类软件都是使用C/S结构，后台使用大型数据库(mssql,oracle)，ADO大行其道。2层结构简单、快速、以数据库为中心，几乎都是单一进程，前后台全部合并在一起，各个客户端之间通讯全部通过数据库，安装较为复杂，数据库设置和维护会花费较大的人力物力。虽然也不是什么致命的问题，但我还是希望找到一种更好的方式，我的期望是：
1、数据库采用轻量级引擎，数据库为单一文件，最好是免安装的，这样可以避免长期运行后的维护和备份的困难
2、避免以数据库为中心的架构，尽量把数据库在系统中占据的分量减轻，不使用任何存储过程和触发器，把逻辑放在代码里，避免后期维护的困难
3、系统采用多进程方式，前后台要分开，模块化搭建系统，避免配置参数的无限膨胀
4、多个客户端之间传递消息不要走数据库，而是使用其他方式，以减轻数据库的负担，且可以尽量减少网络中的数据流动，提高效率
5、安装简单，维护简单，升级和配置简单
因为之前一直在做底层，习惯了自己造轮子，所以一开始的打算是自己构建整套系统，使用C/C++编写。基本框架如下：
db engine <--------> midware <------------(network,pipe,share memory)------------> multi-point(client, server manager,multi-process)
数据库引擎很简单，一定会选用sqlite，因为sqlite速度快，尺寸小，移植方便。这里的移植功能是个人的恶趣味，因为我一直想把系统搬到linux下。
中间件是无界面的console进程，默默工作，不做任何多余动作，负责的事情有两条：
1、在db和point之间传递数据和命令
2、在数据库有变动的时候通知各个point，同时负责各个point之间的消息传递
最终的用户端由多个子进程组成，可以任意组合和拆卸，和midware之间使用pipe/memory/udp进行通讯，界面和实现分开，系统底层有一个client-tranfer进程，负责全部的数据传递，GUI通过pipe/share memory和其进行通讯，后台管理和前台分开，互不干涉，但也可以组合在一起
...
阅读全文...
麻辣婆媳与N-Tie
[ 2007-03-04 23:21:45 | 作者: 痉挛的老鸨 ]
麻辣婆媳，家庭剧，CCTV-1难得会放这种味道的连续剧，所以当初PP推荐的时候我不以为然，但是下雨天打孩子，闲着也是闲着，所以就下载了，但是摆在服务器上一直也没看，不过我老妈倒是看得津津有味。最近服务器空间不够，于是刻了DVD，打算存档备份，顺便就看了，发现其实挺好看的。
一方面惊悚于婚姻的艰难，一方面也感觉和最近折腾的三层系统有诸多相似之处。受夹板气的大良好比是服务器中间层，属于核心部件，但又并不被大家重视，时常眼光会越过他的脑袋视其为无物但又不可逾越。间或搞搞震的吴芮媳妇就是客户端，看似什么都能，而且貌似独立，但实际上还是依赖其丈夫、公公、婆婆。人生的悲哀不外如是，当你觉得已经握住命运的小气管的时候却总有当头棒喝从天而降，令人清醒，令人头疼腰疼屁股疼，所以，谦虚的态度并非代表高尚的情操，相反，绝大多数是因为生活所迫。
压阵的大头：数据库，是公公婆婆，能量超群，善于提供各种帮助和麻烦，很无聊的角色，同时也是很重要的角色。
忽然间觉得无聊，没意思，昏昏欲睡，overover......
一方面惊悚于婚姻的艰难，一方面也感觉和最近折腾的三层系统有诸多相似之处。受夹板气的大良好比是服务器中间层，属于核心部件，但又并不被大家重视，时常眼光会越过他的脑袋视其为无物但又不可逾越。间或搞搞震的吴芮媳妇就是客户端，看似什么都能，而且貌似独立，但实际上还是依赖其丈夫、公公、婆婆。人生的悲哀不外如是，当你觉得已经握住命运的小气管的时候却总有当头棒喝从天而降，令人清醒，令人头疼腰疼屁股疼，所以，谦虚的态度并非代表高尚的情操，相反，绝大多数是因为生活所迫。
压阵的大头：数据库，是公公婆婆，能量超群，善于提供各种帮助和麻烦，很无聊的角色，同时也是很重要的角色。
忽然间觉得无聊，没意思，昏昏欲睡，overover......
讨论fltk的qq群
[ 2007-01-28 18:42:30 | 作者: 痉挛的老鸨 ]
群号：32425450
欢迎对fltk有兴趣的开发人员加入
欢迎对fltk有兴趣的开发人员加入
简单的C，简单的生活，简单的美.....
[ 2007-01-20 01:15:43 | 作者: 痉挛的老鸨 ]
昨天夜里通宵写代码，大脑特别集中，心无杂念，看到一行行的代码出现在屏幕上，忽然发现，这么多年来，已经很少有这样的快乐感觉了。上一次从编程中感觉到快乐，似乎还是读书的时候.....
刚上大学的时候，自学了C语言，然后从书本上一行行的抄录代码，调试，编译，看到结果出来的时候那种震撼和快乐的确让人陶醉。后来开始工作了，这种感觉却似乎逐渐消失了，整天和架构做斗争，和class做斗争，和操作系统做斗争，编程变成了驾驭野马的力气活，曾经的美好愿望落了空，只剩下成堆的bug满腹的牢骚和一地的鸡毛。每每看到电视剧里那些轻飘飘的IT人士，只能报以一声喟叹，编剧啊，你就是个猪脑子！
几年后，终于明白一点class 的含义，却总也找不到合适的开发方法。设计模式、重构、面向方法之类的书也看了不少，但惊叹号的数量永远稀少，问号却总是越来越多。super class、重型设计、框架、类间传递的痛苦和困扰像一座座山峰压的我不敢呼吸，每每在屏幕前失神，每写一行代码都会诚惶诚恐，生怕将来变成一堆垃圾。脑袋里有那么多的大师级的方式方法，但是落实到键盘的时候却总是要出现偏差，给别人讲解的时候头头是道，回头看看自己的代码，依然是一道东北菜：乱炖。类啊类，你真的让我很累！
4年前开始接触linux，阅读kernel源代码的时候，一开始的确很有抵触情绪，这也叫伟大的软件？到处是未经雕琢随手编写的代码，为了效率大量使用goto，巨大的函数体，混乱的命名方式，古老的结构化编程，但是在这样糟糕的表象下为什么整体结构却可以工作的很好？这是一个问题，并且让我浑身不自在，仿佛自己精心炮制的菜肴难以下咽，别人随手弄了点家常菜，食客们却吃的眉开眼笑，不甘心啊！但是，答案在哪里？
欲练神功，必先自宫，既然不能打败你，那就让我们合作吧。于是乎，花费大量的时间阅读相关的书籍和kernel的源代码，同时尝试用linux的风格编写代码，试图用这种方式需求一个可能的答案。
2、 3年后我发现，原来精美的未必一定复杂，强壮的未必一定庞大，恰恰相反，越是复杂庞大的系统越容易出现各种隐患和问题，越是简单小巧、零散、组合式的系统越是坚固可靠，而且扩充性极好，好的让人汗颜。想想当初自己编写的巨大系统，越到后期，越是出现各种奇怪的问题，扩充性几乎降到冰点，需求稍有修改，立马对系统的内部结构造成不可修复的伤害，原先看起来那么精致的class...
阅读全文...
刚上大学的时候，自学了C语言，然后从书本上一行行的抄录代码，调试，编译，看到结果出来的时候那种震撼和快乐的确让人陶醉。后来开始工作了，这种感觉却似乎逐渐消失了，整天和架构做斗争，和class做斗争，和操作系统做斗争，编程变成了驾驭野马的力气活，曾经的美好愿望落了空，只剩下成堆的bug满腹的牢骚和一地的鸡毛。每每看到电视剧里那些轻飘飘的IT人士，只能报以一声喟叹，编剧啊，你就是个猪脑子！
几年后，终于明白一点class 的含义，却总也找不到合适的开发方法。设计模式、重构、面向方法之类的书也看了不少，但惊叹号的数量永远稀少，问号却总是越来越多。super class、重型设计、框架、类间传递的痛苦和困扰像一座座山峰压的我不敢呼吸，每每在屏幕前失神，每写一行代码都会诚惶诚恐，生怕将来变成一堆垃圾。脑袋里有那么多的大师级的方式方法，但是落实到键盘的时候却总是要出现偏差，给别人讲解的时候头头是道，回头看看自己的代码，依然是一道东北菜：乱炖。类啊类，你真的让我很累！
4年前开始接触linux，阅读kernel源代码的时候，一开始的确很有抵触情绪，这也叫伟大的软件？到处是未经雕琢随手编写的代码，为了效率大量使用goto，巨大的函数体，混乱的命名方式，古老的结构化编程，但是在这样糟糕的表象下为什么整体结构却可以工作的很好？这是一个问题，并且让我浑身不自在，仿佛自己精心炮制的菜肴难以下咽，别人随手弄了点家常菜，食客们却吃的眉开眼笑，不甘心啊！但是，答案在哪里？
欲练神功，必先自宫，既然不能打败你，那就让我们合作吧。于是乎，花费大量的时间阅读相关的书籍和kernel的源代码，同时尝试用linux的风格编写代码，试图用这种方式需求一个可能的答案。
2、 3年后我发现，原来精美的未必一定复杂，强壮的未必一定庞大，恰恰相反，越是复杂庞大的系统越容易出现各种隐患和问题，越是简单小巧、零散、组合式的系统越是坚固可靠，而且扩充性极好，好的让人汗颜。想想当初自己编写的巨大系统，越到后期，越是出现各种奇怪的问题，扩充性几乎降到冰点，需求稍有修改，立马对系统的内部结构造成不可修复的伤害，原先看起来那么精致的class...
阅读全文...
不久前fltk终于释出可以实用的2.0版本，目前的具体版本是2.0.x-r5556，让我们看看具体的更新和变动
首先是字体的巨大改进，开始支持utf8，所以在linux下汉字无法显示和输入法无法输入的问题已经彻底解决，但同时也带来一些问题，就是在代码内必须使用utf8的汉字才能正确显示在界面上，但是unicode的编辑器又不是那么好找，再说在windows下开发的话一般都会使用vc，而在vc下输入unicode是一件有困难的事情，至少我没有找到好的插件，所以需要一个解决办法，那就是<fltk/utf.h>里的函数，帮助文档里没有说的很清楚，但是大体上还是可以猜到意思的
修改了class Browser，变成了一个tree，在1.0中想显示一个grid或者listview一直只能自己处理，现在不用了，这个Browser还算可以，提供了基本的功能，稍微还有一些扩充，如果想再丰富一些就只有自己继承了，反正fltk的宗旨就是自己动手丰衣足食。
Opengl的功能貌似有一些修正，但是我没有用到，而且demo中关于OpenGL的例子还没有提供，所以目前情况未知
帮助文档未完善，而且代码中附带的帮助无法使用，所以很多时候还是查1.0的帮助以及看源代码更加有效一些
所有的头文件和类名全部去除了FL_，引入了namespace，好处是类看起来更清楚了，坏处是从1.0的代码升级变得很麻烦。头文件从<FL/FL_XXXX.H>变成<fltk/xxxx.h>，全部变成了小写，而且去掉了FL_，同时目录也变成fltk/了，这些细节稍微用一段时间就会习惯，但是一开始会造成一些问题，虽然在fltk目录下也保留了一些兼容的头文件，但是建议还是不要用，因为不全，而且迟早要换的，何必不一步到位？
对编译器支持的更全，目前支持vc6,vc.net,devcpp,gcc,Code::Blocks,bc5，基本囊括了流行的C/C++编译器
支持整体theme，可以一次性设置当前界面的theme
打算引入一个叫cairo的库，具体作用好像是用于矢量运算的，属于第三方的代码，在fltk的站点上关于这个有一个投票，大多数人还是拒绝在fltk中加入外来插件，都觉得应该保持fltk的轻量快速的特征
待续.....
首先是字体的巨大改进，开始支持utf8，所以在linux下汉字无法显示和输入法无法输入的问题已经彻底解决，但同时也带来一些问题，就是在代码内必须使用utf8的汉字才能正确显示在界面上，但是unicode的编辑器又不是那么好找，再说在windows下开发的话一般都会使用vc，而在vc下输入unicode是一件有困难的事情，至少我没有找到好的插件，所以需要一个解决办法，那就是<fltk/utf.h>里的函数，帮助文档里没有说的很清楚，但是大体上还是可以猜到意思的
修改了class Browser，变成了一个tree，在1.0中想显示一个grid或者listview一直只能自己处理，现在不用了，这个Browser还算可以，提供了基本的功能，稍微还有一些扩充，如果想再丰富一些就只有自己继承了，反正fltk的宗旨就是自己动手丰衣足食。
Opengl的功能貌似有一些修正，但是我没有用到，而且demo中关于OpenGL的例子还没有提供，所以目前情况未知
帮助文档未完善，而且代码中附带的帮助无法使用，所以很多时候还是查1.0的帮助以及看源代码更加有效一些
所有的头文件和类名全部去除了FL_，引入了namespace，好处是类看起来更清楚了，坏处是从1.0的代码升级变得很麻烦。头文件从<FL/FL_XXXX.H>变成<fltk/xxxx.h>，全部变成了小写，而且去掉了FL_，同时目录也变成fltk/了，这些细节稍微用一段时间就会习惯，但是一开始会造成一些问题，虽然在fltk目录下也保留了一些兼容的头文件，但是建议还是不要用，因为不全，而且迟早要换的，何必不一步到位？
对编译器支持的更全，目前支持vc6,vc.net,devcpp,gcc,Code::Blocks,bc5，基本囊括了流行的C/C++编译器
支持整体theme，可以一次性设置当前界面的theme
打算引入一个叫cairo的库，具体作用好像是用于矢量运算的，属于第三方的代码，在fltk的站点上关于这个有一个投票，大多数人还是拒绝在fltk中加入外来插件，都觉得应该保持fltk的轻量快速的特征
待续.....
屁股冒烟之平沙落雁式
[ 2006-11-27 12:57:59 | 作者: 痉挛的老鸨 ]
老李同志，别催了，我这不是撅个腚正在努力么。我知道你急，但其实我更急，眼瞅着快年底了，一堆杂事纷沓而来，我也怕啊。
没办法，框架我已经写的差不多了，但由于现在的方式，一开始是看不到界面的，所以自我感觉已经写了很多了，却偏偏没有东西给你看。这感觉，好似吃了一顿大餐正醺醺然自得的时候，围观的过来问你吃的啥，一通描述却总说不明白，恨不能立刻去厕所挤点出来以表清白.....
昨晚把lua的书打印出来了，今天也查了一下lua for sqlite，lua for fltk也被我挖到后续项目之所在，一开始真以为项目已经隔屁了-_-! 说到这，估计明白的人已经很明白了，不明白的已经找砖头去了.....
其实我也是被逼的，山顶洞人的滋味很好受么，造轮子其实没啥快感，但是客户就是上帝，该死的是，这群上帝们各有各的地盘和bible，每个人还都念的不一样，为了避免二进制和source code衍化出无数枝头，只好全部script化了。不过这个方式倒是很有创造性，阿弥陀佛，rayman不要咬我.....
后面的项目一律照此方式处理，钦此！
ps:刚才在云风的blog上看人吵架，爽啊，掐的很激烈，很别开生面，很血肉模糊一塌糊涂。有兴趣的自己找去，关于dll的一篇文档，我记忆力比较差，就别摧残脑细胞了，看过就得。
没办法，框架我已经写的差不多了，但由于现在的方式，一开始是看不到界面的，所以自我感觉已经写了很多了，却偏偏没有东西给你看。这感觉，好似吃了一顿大餐正醺醺然自得的时候，围观的过来问你吃的啥，一通描述却总说不明白，恨不能立刻去厕所挤点出来以表清白.....
昨晚把lua的书打印出来了，今天也查了一下lua for sqlite，lua for fltk也被我挖到后续项目之所在，一开始真以为项目已经隔屁了-_-! 说到这，估计明白的人已经很明白了，不明白的已经找砖头去了.....
其实我也是被逼的，山顶洞人的滋味很好受么，造轮子其实没啥快感，但是客户就是上帝，该死的是，这群上帝们各有各的地盘和bible，每个人还都念的不一样，为了避免二进制和source code衍化出无数枝头，只好全部script化了。不过这个方式倒是很有创造性，阿弥陀佛，rayman不要咬我.....
后面的项目一律照此方式处理，钦此！
ps:刚才在云风的blog上看人吵架，爽啊，掐的很激烈，很别开生面，很血肉模糊一塌糊涂。有兴趣的自己找去，关于dll的一篇文档，我记忆力比较差，就别摧残脑细胞了，看过就得。
先看这个文章，“最小接口”：
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx
Martin Fowler的确是oo的大师，对类的理解和解析的确很深入，但是我还是想表述一些不同的意见。对于class而言，越强大就会越臃肿，越简单就会越零碎，这是不可避免的问题。对于一个足够复杂的系统，class简单了不行，太散，最后的组装成本会相对过高，复杂了也不行，复用和维护的成本也很高。而且这两种都会造成中间层的脂肪过剩，虽然所有讲oo的书都会说过度复杂的中间层不好，但是没有哪本书提出了很好的解决办法，似乎归结到最后就只有依靠开发者本身了。这种情况其实很是可怕，面对目前的开发现状，很多系统对复用的渴求会越来越明显，但是老系统中到底有多少模块可以无缝移植，只怕没有人能说清楚。而且随着需求的变化，老系统的维护和升级也越来越成为一个巨大的负担，重写是最常见的最终武器，但这武器所带来的损耗和浪费也是相当惊人的。
其实问题的核心是：如何在复杂度和可读性之间寻求最佳的平衡。人的脑容量是有限的和有差异的，不同的开发者对复杂度的衡量标准是不一样的。一个确定的模块，对某些人而言是容易理解和消化的，但对另外的人而言却复杂的无法吞咽，这是现实问题，并不是通过培训和努力就能消除的。不同的行业和不同的开发方向，一定会造成不同的理解范围和理解方式，也就造成不同的开发者之间会存在必然的差异。只要这种差异存在，之前所述的问题就一定存在。
问题不可怕，可怕的是不敢去面对。真的勇士，敢于直面惨淡的人生;-) 个人看法，胶合层是一定要减肥的，但是如何减是一个问题。对于一个oo构架的系统，胶合层是一定存在的，如何做薄做小是个关键，同时薄和小的标准也是因人而异的。起码有一点我很肯定，胶合层的复用性是很差的，甚至可以说根本没有复用的可能，那么很简单，一个系统中只创建一个胶合层，尽量将特定的需求和无法复用的部分整合进来，同时随时做好丢弃的准备，一旦需要开发新系统或者需要升级系统，胶合层就成为第一个被牺牲的对象，如果设计的好，就有可能是唯一需要丢弃的部分，这样起码可以保证智力投资最大限度的保值。
模块(class，接口，函数，随便你怎么定义它)的复用性如何，决定了它的生存时间，也直接反应了开发者的能力，如何确保复用性是个老生常谈...
阅读全文...
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx
Martin Fowler的确是oo的大师，对类的理解和解析的确很深入，但是我还是想表述一些不同的意见。对于class而言，越强大就会越臃肿，越简单就会越零碎，这是不可避免的问题。对于一个足够复杂的系统，class简单了不行，太散，最后的组装成本会相对过高，复杂了也不行，复用和维护的成本也很高。而且这两种都会造成中间层的脂肪过剩，虽然所有讲oo的书都会说过度复杂的中间层不好，但是没有哪本书提出了很好的解决办法，似乎归结到最后就只有依靠开发者本身了。这种情况其实很是可怕，面对目前的开发现状，很多系统对复用的渴求会越来越明显，但是老系统中到底有多少模块可以无缝移植，只怕没有人能说清楚。而且随着需求的变化，老系统的维护和升级也越来越成为一个巨大的负担，重写是最常见的最终武器，但这武器所带来的损耗和浪费也是相当惊人的。
其实问题的核心是：如何在复杂度和可读性之间寻求最佳的平衡。人的脑容量是有限的和有差异的，不同的开发者对复杂度的衡量标准是不一样的。一个确定的模块，对某些人而言是容易理解和消化的，但对另外的人而言却复杂的无法吞咽，这是现实问题，并不是通过培训和努力就能消除的。不同的行业和不同的开发方向，一定会造成不同的理解范围和理解方式，也就造成不同的开发者之间会存在必然的差异。只要这种差异存在，之前所述的问题就一定存在。
问题不可怕，可怕的是不敢去面对。真的勇士，敢于直面惨淡的人生;-) 个人看法，胶合层是一定要减肥的，但是如何减是一个问题。对于一个oo构架的系统，胶合层是一定存在的，如何做薄做小是个关键，同时薄和小的标准也是因人而异的。起码有一点我很肯定，胶合层的复用性是很差的，甚至可以说根本没有复用的可能，那么很简单，一个系统中只创建一个胶合层，尽量将特定的需求和无法复用的部分整合进来，同时随时做好丢弃的准备，一旦需要开发新系统或者需要升级系统，胶合层就成为第一个被牺牲的对象，如果设计的好，就有可能是唯一需要丢弃的部分，这样起码可以保证智力投资最大限度的保值。
模块(class，接口，函数，随便你怎么定义它)的复用性如何，决定了它的生存时间，也直接反应了开发者的能力，如何确保复用性是个老生常谈...
阅读全文...
界面为什么不能是立体的？切换视角，抽拉卡片，菜单一片片的分类排列，功能在天花板上整装待发......
1
