项目现在遇到了一个问题--BUG好像永远也改不完！每当改完一个BUG之后，就会发现有其他的BUG冒出来。好像无论如何努力，BUG数也无法降低下来--无法看到BUG被完全消灭的一天吗？这个令人恐惧的预兆将极大打击项目成员对项目的信心。
最根本的原因是系统的设计有问题--系统的框架并没有实现好的模块间耦合隔离，那么，模块间互有依赖，改动一个模块就会影响另外一个模块--这样改BUG经常这头刚按下去一个，那边又冒出来两个。
还有一个原因是项目组织管理的问题--由于采用契约制社员来开发，不能保证自始至终由相同的人负责固定的模块，改BUG的时候，程序员总是面对一堆别人的代码（要命的是，项目的大多数代码没有做CODE REVIEW，注释很少，设计书也言之不详，困难可想而知），多数情况下，眼光只局限于BUG出现的那几行代码，所谓头痛医头，脚痛医脚，对整个功能设置整个模块会造成什么影响，就无法顾及了。
那么，如果你是项目经理，你会做什么呢？比如，以上的两点根本原因你都无法改变的话，是否就要缴械投降呢？幸好，你还有最后一颗子弹，从技术上着手，你可以很大程度上改善这种困境。
这颗子弹就是持续集成（以及与之联合的BUG管理系统）[to be continued]
2007年6月13日星期三
Safari 冲入Windows阵地
拥有Max OS X上一样的迷人外表，页面装入和显示的速度是IE7的两倍，比FireFox2快1.6倍。近日Apple的Safari 3.0同时发布了在Windows上的版本。听起来激动人心哦！
（关于速度的描述摘自Apple.com上的原文，不知道是否有笔误，这样不是意味着IE7比FireFox快--这恐怕不对。另外这样明目张胆拿对手的产品来比较，难道不会有麻烦吗？）
下载Beta2来看看，安装文件很小，只有7M左右，开始还以为是在线安装程序呢。想想IE7一百多兆的体积，不知道M$在里面都放了一些什么呢？在日文版Windows XP Pro上无事安装成功。界面和Mac下几乎没有差别，不过用一下马上就发现没有在Mac下的感觉。估计是显示引擎的原因，本来在Mac上很优雅的菜单和对话框动画的动作显得很不自然。另外整个应用程序的稳定性有待提高，程序异常退出的情况比比皆是，这么频繁的错误对于一个Beta2版，有点说不过去。
苹果近一段对于操作系统市场采取了一些积极的对策，改用Intel处理器并支持Windows XP/Vista，希望扩大操作系统的市场份额。针对数量巨大的Widnows用户，发布支持windows的软件，不失为一个很好的策反策略。毕竟绝大部分Windows用户（特别在中国）没有用过Mac OS，让他们了解Mac和Apple是第一步棋。（iTunes的Windows版本做得就不错）
不过，理想与现实之间，有很长的路要走。第一，Windows和Mac OS毕竟是不同的平台，他们没有共同库文件作支持，同时发布两个平台上的软件差不多意味着要写两个软件。而且，Windows上的表现和Mac上的表现会有差别。如果处理不善，就无法把Mac OS软件稳定，简洁，优雅的特征传达给Windows用户，相反会造成Mac OS上软件不如Windows软件稳定的印象。第二，渠道所限，Apple对这些软件推广的效果有待考察。现在能看到的是在下载站点的连接和介绍（苹果在中国基本没有大排场的市场活动好像），我想，这是远远不够的。
2007年6月8日星期五
完美世界
游戏《完美世界》的主题曲之一，第一次只听歌唱，没有看到歌词，有种“沧桑历遍，激情和向往如初”的感觉，很好听。今天特意找了歌词，水木年华的歌。略感失望的是歌词没有雕琢，内容单薄，不过念在是网络游戏的主题曲，旋律好听已经很不错。
游戏是国内不可多见精细之作。
游戏是国内不可多见精细之作。
不知日落夜深多少个夏秋
不知我已这样奔跑了多久
我从出生就注定一生的寻求
远方那完美世界的爱和自由
Fly with me
In the perfect world
Go with me just like a bird
没什么能阻挡自由的天地
这样沉默爱你不知有多久
我愿付出我的生命和所有
我要你不顾一切跟我走
去向那完美世界的爱和自由
Fly with me
In the perfect world
Go with me just like a bird
没什么能阻挡我们在一起
Fly with me
In the perfect world
Go with me just like a bird
没什么能阻挡自由的天地
Fly with me
In the perfect world
Go with me just like a bird
没什么能阻挡我们在一起
2007年6月5日星期二
再见了，Gaim！
开源IM的盟主Gaim，5月4日开始改名为Pidgin，并正式发布2.0版，主页移动到www.pidgin.im，新主页上Lasted News（也是唯一的一条News）上简单带过--
Following a legal settlement with AOL, Gaim has been renamed Pidgin and its 2.0.0 release is now available...（根据和AOL诉讼的裁定结果，Gaim改名为Pidgin，现在2.0版本可以使用），不由令人浮想联翩。
从项目名称来说，Pidgin这个词可比Gaim差多了，发音拗口不响亮，外形也不好，说到词义，Pidgin这个词让我产生嘀嘀咕咕喋喋不休的联想（我不是不喜欢鸽子哦）。Gaim招牌易手，和我一样，我想不少的Gaim使用者要扼腕叹息吧。 那么，Gaim为什么要拱手将这个开源和跨平台IM老大的金字招牌拱手让给AOL呢？实际上，Gaim和AOL针对Gaim所有权的争端从Gaim项目开始不久就浮出水面了。
当时AOL Instant Messenger如日中天，Gaim项目为了推广取名GTK AOL Instance Messenger之意，这成为AOL以后诉求的重点。（此事和ICQ控告当初取名叫OICQ的QQ如出一辙，结果是OICQ被迫改名QQ，不过现在QQ赚得盆满钵满，而当年的老大ICQ却已经是垂垂老声势日微矣，扯远啦）数年后，AOL取得AIM商标的所有权，再次表示GAIM侵犯了其商标权，不过未见有任何公开的行动。
直到Gaim 2.0Beta发布之后（记得是2006年吧），AOL开始放出狠话，威胁要将GAIM的开发者告上法庭。不过此次双方并未大动干戈，庭外和解了事，至于和解的条件，就不得而知了。只是Gaim的Fans要知道以后没有Gaim，要用嘀嘀咕咕的Pidgin了。
2007年4月16日星期一
WEB系统设计-SQL上要写一些什么？
1.SQL要写到什么程度？
这个系统的SQL语句不少写得比较复杂。比如：
甚至还有在SELECT句上含有IF/ELSE分支选择语句的（这是我第一次知道ORACLE支持这种语法）。在一个多层WEB MIS系统上，SQL写得过于复杂，是不好的设计。
带来的坏处是：
导致系统业务逻辑分散分布在SQL语句和BO(Bussiness Objects)上。违反了分层设计的初衷，阅读和理解代码变难，系统维护和升级的工作也复杂了。
举例来说，以上的功能模块，进行维护或升级工作的技术人员必须兼顾JAVA和数据库，在这两个方面都要不错才可胜任工作，要不然就需要两个技术人员。
就上面的SQL语句来说，
1.要避免使用DECODE解码语句。将常量和字典的映射写在SQL上是很笨的，首先SQL的设计者必须记一堆编码映射表不要搞错，很多系统有很大的映射参照表，SQL设计者们要经常查阅这个表。另外试想有一天常量的名称需要改变时，需要修改所有有关的SQL语句。（当然我们还有文件批量查找和替换工具可以用，不过那实在是不太优雅的招数）
2.要避免在SQL上使用外联接来查询字典表。联接查询字典表不能算是大的问题，事实上很多系统都一直这么做的，毕竟比起上述的把字典解码直接写到SQL上要进步很多了，它实现了字典数据的集中管理。但我认为，对于系统运行过程中不会改变的全局字典表(SYSTEM MASTER表，比如《邮政编码映射》，《业务分类》，《顾客分类》等字典表)来说，最好的办法是在系统初始化的时候就将其加载到全局内存中，并在JAVA层提供查询的接口。这样可以减少不少SQL句的复杂度，而且对使用频繁的字典表的访问减少到最低，数据库的负荷也减轻了。
按照分层设计的原则，理想的状态，SQL语句因该是纯粹的最简单的SELECT/UPDATE/DELETE语句，不要包含任何逻辑。存储过程和触发器应该避免使用。
但是，世上的事情总是没有那么简单。不可避免地，我们要遇到一些有关性能的问题，比如，需要对大量的记录的每一条进行一些复杂运算，然后更新这些记录。这时候，在JAVA层面上对每一条记录进行循环，做运算，然后写回数据库，效率可能无法满足要求。此时可以考虑存储过程或复杂的批量UPDATE语句。必须记住的是，在整个系统设计中，这是极端状态下的特例，不能以性能为理由来破坏分层设计的原则。(Hibernate有持久对象缓存机制，另外好像在关注批量更新的性能问题，不知现在应付这类任务性能如何。
这个系统的SQL语句不少写得比较复杂。比如：
SELECT
decode( ?, 0, '（オーダー入力）', '（オーダーキャンセル）' ) TITLE,
decode(a.FAX_HATCHU_FLG, '1', '', a.JUCHU_NO ) JUCHU_NO,
....
FROM
SUE_INC a,
SS_MASTER b,
...
WHERE
a.SS_CODE(+) = b.SS_CODE
...
甚至还有在SELECT句上含有IF/ELSE分支选择语句的（这是我第一次知道ORACLE支持这种语法）。在一个多层WEB MIS系统上，SQL写得过于复杂，是不好的设计。
带来的坏处是：
导致系统业务逻辑分散分布在SQL语句和BO(Bussiness Objects)上。违反了分层设计的初衷，阅读和理解代码变难，系统维护和升级的工作也复杂了。
举例来说，以上的功能模块，进行维护或升级工作的技术人员必须兼顾JAVA和数据库，在这两个方面都要不错才可胜任工作，要不然就需要两个技术人员。
就上面的SQL语句来说，
1.要避免使用DECODE解码语句。将常量和字典的映射写在SQL上是很笨的，首先SQL的设计者必须记一堆编码映射表不要搞错，很多系统有很大的映射参照表，SQL设计者们要经常查阅这个表。另外试想有一天常量的名称需要改变时，需要修改所有有关的SQL语句。（当然我们还有文件批量查找和替换工具可以用，不过那实在是不太优雅的招数）
2.要避免在SQL上使用外联接来查询字典表。联接查询字典表不能算是大的问题，事实上很多系统都一直这么做的，毕竟比起上述的把字典解码直接写到SQL上要进步很多了，它实现了字典数据的集中管理。但我认为，对于系统运行过程中不会改变的全局字典表(SYSTEM MASTER表，比如《邮政编码映射》，《业务分类》，《顾客分类》等字典表)来说，最好的办法是在系统初始化的时候就将其加载到全局内存中，并在JAVA层提供查询的接口。这样可以减少不少SQL句的复杂度，而且对使用频繁的字典表的访问减少到最低，数据库的负荷也减轻了。
按照分层设计的原则，理想的状态，SQL语句因该是纯粹的最简单的SELECT/UPDATE/DELETE语句，不要包含任何逻辑。存储过程和触发器应该避免使用。
但是，世上的事情总是没有那么简单。不可避免地，我们要遇到一些有关性能的问题，比如，需要对大量的记录的每一条进行一些复杂运算，然后更新这些记录。这时候，在JAVA层面上对每一条记录进行循环，做运算，然后写回数据库，效率可能无法满足要求。此时可以考虑存储过程或复杂的批量UPDATE语句。必须记住的是，在整个系统设计中，这是极端状态下的特例，不能以性能为理由来破坏分层设计的原则。(Hibernate有持久对象缓存机制，另外好像在关注批量更新的性能问题，不知现在应付这类任务性能如何。
WEB系统设计-前言
这一段在做一个系统的代码验收，一家石油零售商的WEB MIS系统，开发周期长达数年。进入这个小组1个月有余，除了编程的问题外，发现设计上存在不少的瑕疵，问题是存在的，不过现在已经进入验收阶段，只要影响不大，也就没有改的必要了。日本的Team会做代码重构吗，会，在他们被系统的问题逼到墙角的时候就会。
一直很关注Web系统设计，在技术问题上一直是吹毛求疵的我(哈)，看到这些问题，不免心下痒痒，随便拿几点指摘一下系统的设计吧。
一直很关注Web系统设计，在技术问题上一直是吹毛求疵的我(哈)，看到这些问题，不免心下痒痒，随便拿几点指摘一下系统的设计吧。
Facts About Me
Software I use:
Mac OS X, Ubuntu, Opera, Google Family, Eclipse, Java, Sure, the M$ family -- Windows and Office
Hardware I use:
IBM T41, Toshiba A20, Mac Book G4, iPod, Palm Zire, Treo，Sony Clie
If I won 1 million dollars, I would:
E..E...E.....Exicted to die, so better in times. :)
If I were a super hero I would:
Super hero, really? ...Could I have a dozen of GFs ? It may be a hard job to handle with so much, but trust me, I will try a super hero's best. :D
I wish I could:
Have a two-months vacation, one for piggy sleep, one for staying with family !
Mac OS X, Ubuntu, Opera, Google Family, Eclipse, Java, Sure, the M$ family -- Windows and Office
Hardware I use:
IBM T41, Toshiba A20, Mac Book G4, iPod, Palm Zire, Treo，Sony Clie
If I won 1 million dollars, I would:
E..E...E.....Exicted to die, so better in times. :)
If I were a super hero I would:
Super hero, really? ...Could I have a dozen of GFs ? It may be a hard job to handle with so much, but trust me, I will try a super hero's best. :D
I wish I could:
Have a two-months vacation, one for piggy sleep, one for staying with family !
2007年1月12日星期五
iPhone手机
传闻终于有了结果，苹果昨日发布了自己的手机产品iPhone，乔布斯不忘在最后一刻吊足了记者们的胃口：
外观看，iPhone特意将320x480的屏幕和黑色外壳设计在同意平面上，这样屏幕上所显示高亮度的按钮更接近真实感受。 看清楚了，它没有设计键盘，用的是触摸屏幕，天哪，它也同样没有搭配触笔吗？！要让用户拿指甲望屏幕上乱划么？
总来说，看到iPhone的外观之后，回头看以前流传的iPhone的设想外观图，只能说，设想者要么根本不了解苹果的设计宗旨，要么就是严重缺乏想象力。演示的功能也非常激动人心，苹果一贯的作风－－为提高用户体验无所不用其极－－得到了充分的体现。
不看用手指在唱片架子上滑过挑选唱片的拉风，想想一台装了Mac OS X的手机就已经足够令苹果迷们血压升高了，拿着它，你可以和喜欢的Mac无时无刻呆在一起，超过和你女朋友在一起的时间哦。看完演示，差不多我就要抛弃手上的treo投靠iPhone阵营了。
发布会尾声的消息稍稍浇灭了我的热情：在美国的两年签约价是399（估计在亚洲要卖599美元吧，不过东西好，再贵也有人买，想想那些虔诚而狂热的苹果信教者吧），另外，在亚洲估计要到2008年才上市(发布会开得早了点吧，明摆要亚洲用户流着口水等上一年～)。
今天，我将宣布三种新的产品：（现场：议论的骚动）
一款超大屏幕触摸屏iPod播放器 （现场：鼓掌欢呼声）
一款手机 （现场：激动的欢呼声）
一款Internet网络终端（现场：例行公事的寥寥鼓掌），
这三个产品将被命名为iPhone。(现场：哗然，有人起立欢呼)
外观看，iPhone特意将320x480的屏幕和黑色外壳设计在同意平面上，这样屏幕上所显示高亮度的按钮更接近真实感受。 看清楚了，它没有设计键盘，用的是触摸屏幕，天哪，它也同样没有搭配触笔吗？！要让用户拿指甲望屏幕上乱划么？
总来说，看到iPhone的外观之后，回头看以前流传的iPhone的设想外观图，只能说，设想者要么根本不了解苹果的设计宗旨，要么就是严重缺乏想象力。演示的功能也非常激动人心，苹果一贯的作风－－为提高用户体验无所不用其极－－得到了充分的体现。
不看用手指在唱片架子上滑过挑选唱片的拉风，想想一台装了Mac OS X的手机就已经足够令苹果迷们血压升高了，拿着它，你可以和喜欢的Mac无时无刻呆在一起，超过和你女朋友在一起的时间哦。看完演示，差不多我就要抛弃手上的treo投靠iPhone阵营了。
发布会尾声的消息稍稍浇灭了我的热情：在美国的两年签约价是399（估计在亚洲要卖599美元吧，不过东西好，再贵也有人买，想想那些虔诚而狂热的苹果信教者吧），另外，在亚洲估计要到2008年才上市(发布会开得早了点吧，明摆要亚洲用户流着口水等上一年～)。
2007年1月10日星期三
铁老大发慈悲
今日新浪新闻头条：今年起春运火车票价不再上浮！春运近在眉睫，铁道部此番旺季门口让利大酬宾，而事前并未有任何渲染铺垫，事出突然，着实令人惊讶。
中国众多垄断老大中，铁老大之牛气当属第一，服务水平之低程度已足让其他老大自叹弗如，(春运帝国之大作堪称尖锐)，旺季涨价抢钱之壮举更是开服务业先河。
近年屡屡被推上被告席，但官司却是不必担心会输的--咱们铁道部自家开着法院公安检察院一应俱全，按规定要告您得来我这里告。
对如此之牛的铁老大而言，原不大可不必有什么担心，你们啰唆你们的，我自顾收我的钱涨我的价买我的快餐，反正火车只有我一家能开，能耐你就坐飞机轮船神六或者干脆别回家过年。
料此次行动，明显将影响铁路各职工年终奖金的厚度，而规定出台如此干净利索，也没有所谓专家出来发表涨价有利国计民生之类的高论，且不单针对近年，以后皆不涨价，此中原委，足以令我等百姓埋头想上三天三夜了。
2007年1月9日星期二
发明轮子之后遇见汽车
前不久在东京时已经基本搭建了一个数据库功能单元测试框架。利用JUnit来测试DAO对象。采用了Derby数据库，测试数据采用Excel来组织，用POI来读写Excel。
采用Excel来主要是基于Excel文件很容易查看和修改，在Excel文件里面加上一些必要的注释，测试数据文件本身就可以作为一个单体测试报告文档提交。这样程序员可以省去不少工作。
整个项目不复杂，在利用POI来读取数据集的比较啰唆。此段因为有教学的事情在忙，也一直荒废没有进一步完善。偶然在书店看到《JUnit in Action》，知道DBUnit有读取XML数据文件并和测试结果比较的能力，到DBUnit.org浏览了一下，发现它竟然可以支持Excel数据源。
哇咧，难道我闭关多时好不容易发明轮子，一出关却看到满大街的汽车到处跑？！国外的网站现在很慢，从sf.net上下载Java doc没有成功，罢，等抽空仔细研究一下，能简单地到达我的目标也不赖。
采用Excel来主要是基于Excel文件很容易查看和修改，在Excel文件里面加上一些必要的注释，测试数据文件本身就可以作为一个单体测试报告文档提交。这样程序员可以省去不少工作。
整个项目不复杂，在利用POI来读取数据集的比较啰唆。此段因为有教学的事情在忙，也一直荒废没有进一步完善。偶然在书店看到《JUnit in Action》，知道DBUnit有读取XML数据文件并和测试结果比较的能力，到DBUnit.org浏览了一下，发现它竟然可以支持Excel数据源。
哇咧，难道我闭关多时好不容易发明轮子，一出关却看到满大街的汽车到处跑？！国外的网站现在很慢，从sf.net上下载Java doc没有成功，罢，等抽空仔细研究一下，能简单地到达我的目标也不赖。
2007年1月7日星期日
GNome Pilot on Ubuntu
Dapper默认安装的Gnome Pilot很容易同步手上的Treo 600，可是中文全部成了乱码。
于是安装Jpilot
sudo apt-get install jpilot
乱码问题解决，可是Jpilot不是和Evolution同步，联系人，日程安排等都是单独管理，不方便。
Gnome Pilot的乱码是因为编码默认是英文，尝试寻找配置文件以修改编码设置，没有结果。
Google之后发现Pilot Link把编码固定写在源码里面了。动手修改源代码重新编译：
下载源代码:
apt-get source pilot-link
修改编码
vi pilot-link-0.11.8/libpisock/util.c
寻找
define PILOT_CHARSET "CP1252"
将CP1252改为GBK
因为不需要重新发布deb包，所以只是重新编译库文件：
./configure --prefix=~/fakeroot/usr/
make
make install
最后将生成的libpisock.8.so拷贝到/usr/lib下覆盖
sudo cp libpisock.8.so /usr/lib
重新启动
sudo reboot
于是安装Jpilot
sudo apt-get install jpilot
乱码问题解决，可是Jpilot不是和Evolution同步，联系人，日程安排等都是单独管理，不方便。
Gnome Pilot的乱码是因为编码默认是英文，尝试寻找配置文件以修改编码设置，没有结果。
Google之后发现Pilot Link把编码固定写在源码里面了。动手修改源代码重新编译：
下载源代码:
apt-get source pilot-link
修改编码
vi pilot-link-0.11.8/libpisock/util.c
寻找
define PILOT_CHARSET "CP1252"
将CP1252改为GBK
因为不需要重新发布deb包，所以只是重新编译库文件：
./configure --prefix=~/fakeroot/usr/
make
make install
最后将生成的libpisock.8.so拷贝到/usr/lib下覆盖
sudo cp libpisock.8.so /usr/lib
重新启动
sudo reboot
订阅：
博文 (Atom)
