软件项目工作日志

这个星期

2006-12-16T13:40:00.000+08:00

这个星期，周一的计划到周六才做。周四到深圳一次很可能是白跑一圈，周一本来是前剧，但是搞错一个小地方，出现了一大堆的垃圾，一直到今天还没有清理完，昨天大半天，让一个程序小错误弄了大半天，最后才发现是变量搞错了，令数组溢出了序号域。由于这个错用catch也收不住，一度令我糊涂万分。
但看来google也好不了多少，这个简单的升级，好象整整花了它十几个小时。

2006-06-14T12:09:00.000+08:00

昨天真的碰上了麻烦事，新系统性能限制居然比旧系统还要严重，而且会自动退出。
新系统目前只有两种系统可以装上去，一个是fedora，一个是suse10还只是32位版本，这是64位机，但不知为何，无论是fedora64还是suse64装起来都是半途死机，连安装都没有完成，一点办法也没有。
fedora把没有用的桌面什么的删除后，倒也能用，今天网上的静态发布的东东就是由第一次的fedora做的。也正因如此，昨天碰上的事情才真叫奇怪：它不能正常发布了。总是出too many files opened，但无论是fs-max,这应该是文件系统允许的文件数；还是ulimit下的文件数，都已经绝对改大了，仍是出同样的错。更麻烦的是，它的错误象是还可以记忆，以致于第二三次就会自动退出系统。如果真的用作主力工作机，那还不如不用。除非我在第一次成功发布时是记错了，否则这个事情真的是无法解释。但，网上就放着它发布的东西！！

我怀疑是rh在fedora版上搞鬼，但换到suse10上，仍是同样的结果。而两者唯一相同的，就只是使用uname2.6内核。难道真是2.6内核的问题？如果进一步升级到java1.5那工程就越变越大，而且还只是一个探索工程，谁也没有把握，这个工程就一定是成功的。

我尝试在网上找找答案，但是搜索出来的结果少之又少。显见，碰到同样问题的人不多；而事实上，这种发布方案，一般是使用后置工作机专机处理，象我这里预发布的少之又少，真碰上能否认识到有这个错误，实际上也是很难说的。另外，我感觉到似乎这个新系统对内存的使用效率还比不上老系统的内核。或者，真的是内核上的限制？

目前可选的方案不是太多的，简单化重装一个fedora再试试，但真的是挺悬的,结果无效。另一个就是下载一个2.4内核看看更换内核会不会有点好处，那怕修改了fs.h的头，找不到inode.c，再研究下去就复杂化了；重新用上这个内核后，还是不行。除此之外，也实在想不出好办法来了。

顺便试试java1.5和tomcat5.5版，发现对大内存的使用上比前一版本好了，能识别的内存更多，与apache的配合没有问题，一切照旧，但原有的程序一律编译不出来。看来，把系统移到tomcat5.5上仍是相当复杂的一个工程，而且是否有效也是不能马上确定的。

2006-02-04T08:54:00.000+08:00

眼前事情比较多，而且其中缺乏连贯性，最不令人喜欢的那种操作。
一、月初升级dis大纲的工作做了一半，碰上硬件故障，到今天仍然没有重新开始，以致于到底干到什么地方都差不多忘记了，更不用说当时的感觉，显然是全没有了。而这段时间收拾硬件的坏感觉也影响了整个工作情绪。

二、SATA的linux驱动如果不搞下来，新的一台服务器也难说得上有什么作用。而新恢复的服务器增加linuxmail也是一件不小的事情，这个操作虽然以前搞通了，却也是很没有意思的一个，重新看以前的文档，很闷的事情。

升级到java1.5 不容易

2005-11-30T08:36:00.000+08:00

除了如何升级外，还有着为什么要升级的问题。初步看它的文档，我觉得JAVA1.5是从语言层过多地向抽象层、应用层扩张了，包括它的netbean，还有resultset可选这些类功能，恰恰是我最反对的。事实上，这是为了适应低级的用户而在基本性能上作出了妥协。

在测试过程中，尝试直接使用1.5JVM升级1.4,结果应用系统迅速崩溃??无报错崩溃。这说明1.5违反了一些语言包升级的最基本要求，即应该兼容从前的应用；尽管我可以用1.5再编译一次，但终归是不太合理的。

用1.5重新编译时，发现许多可以在1.4上编译通过的代码，在1.5就通不过，这意味着需要重新建立一个系统，使用1.5一个个地bug，同时也要预计到如果1.5通不过，同样的代码需要在1.4上也bug一次才可以使用??以它目前的表现，谁能担保到时1.5的系统上运行不会DOWN?或者会好一点？

起码，到目前为止，我还是没有看到必须使用1.5的理由。尽管1.4的类明显有BUG，象，filewriter的数组写出时计数错误，每隔一千字符丢一个之类的，但代价了比目前可见的升级到1.5的混乱要少。

如果是从零开始一个系统，或者，1.5是一个可能的选择。

2005-11-08T11:50:00.000+08:00

让会话的问题无来头阻了一个多小时，发现这是一个早已解决但却差不多忘记的问题。

收拾几个发布的便于SEO的网页，由于昨天睡眠太差，居然花了我几个小时，不过忙中偷闲也睡了一两个小时，精神似乎恢复过来了。从访问量看，减去了archives的部分后，回复到九月较好的水平。其实是不错的，因为基本的面并没有改变，不过陈似乎是难以接受似的。

2005-11-05T10:00:00.000+08:00

回头看看，教胡完成工作的速度，大概只有我自已下手的二分一，换言之，我自已来花自已的时间还少一点。所以下一步就是少教，他做到什么地方算什么地方，然后我就收功课就是了。

３７２１仍是有着中国搜索引擎的恶习，尽管它已经被yahoo收购，也愿意署名了，但是现在发现几次造成down机，都是3721干的好事。而原因，是由于logger，看来，logger的锁定是造成溢出错误的一个重要的因素，它能够承担的写入量基本上接近顶点了。这个下面要仔细考虑一下，什么地方需要写入，而什么地方不需要写入记录。

SEO连接组那里要花点时间整理一下。我目前的博客包括四个部分，一直保持的部分，这一部分最好不要与网站发生关系；二是可用作连接的部分；三是私有的部分；四是专作SEO的部分。除第三私有部分外，一律可以通过本站提升，但第一部分不应直接形成对本站的连接，而应该形成对第二部分或第四部分的连接。

打算花点时间整理一下各个博客，首先就是那个blogcn，结果进一步确认blogcn真是最烂的垃圾，该有的功能没有或者不好有用，花梢的东西全有，简直就是惨不忍睹，它的那个排名怎么可能是真的呢？

2005-10-30T10:57:00.000+08:00

XMLOjbect中的类型，一直在两可之间。一方面，它其实可以看作是一段格式化的文化，具有文章类的一切特征；另一方面，它又表现为一个网页。 TEXT类型的歧义来源于它刚好处于动态发布和静态发布发展过程中间。它的出现，是由于象黄页那样的，希望表现出一个独立的地址表现一个黄页内容，同时，又不希望在同一个黄页内容中出现多次数据库的访问；由此而诞生出寻求在一个对象中获取子对象的解决方案。事实上，这也是导致发展出XMLObject模式的动力之一。

当XMLObject的博客和动态网站内容最终发展成静态网页发布时，TEXT原有的避免产生多次访问的原意就失去了现实的意义。这也导致了对 XMLOjbect子集合形式的积级意义的再思索。产生重新审核的导引是由于对访问审计的需要，尽管不是必要。在不同的实例中更新对一个数据库记录的访问计数，要比更新一个XML记录要来得更省事一点，对数据库的访问两者则是一样的。

目前添加TEXT计数的方法大致有两种：
１、添加一个通用的对XMLＯbject子对象的计数方法－标签；
２、是改成一个对类article的围绕着数据库管理的方法。

前者是XMLObject体系的再发展，而后者，则是兼容关系模式的发展。显然，目前没有必要把texts/articles归为一体。就当前而言，使用一型会显得更为直接而富有进取性。实际上，目前article的计数中搜索引擎起到了积极的作用，如果没有这个作用，text中的记数会明显地不及，因此，或者应该再建起一个便于对article进行记数增加的网页。

2005-10-09T08:56:00.000+08:00

在静态的页中带上连接包括：到主域的连接，不宜用script打出来，连iframe都不算合适，更适于使用静态连接,以便对主域的pr有所帮助；其次，是一个指向强大下载甚至是刷新地址的页面，这样才可以加大流量，最后，是需要一个指向当前域的地址，以便可以调节会话；或者，还需要一个统计网址，以便知道这个网页的访问量有多大。

统计的功能令人不能放弃，但是统计就必然意味着高耗能的数据库存写。另一方面，单纯的刷新访问可能看罕见的，真正的访问计数估计者是来自于搜索引擎。如果提供了静态网页，却是再消耗大量资源做少量的实时的统计，实在有点不伦不类。这里解决方案有两个：一是由另一台电脑完成，实际上是把负担放到数据库；数据库也可以由单犯的系统提供。这种方案，本质上是扩充软硬件来满足边缘需求；代价除了软硬件的成本外，系统管理也是很大的成本。另一个方案就是一直说来的消息系统。把要统计的数字作为消息串放在系统中，在检查到访问量不算大时，就自动把它存入数据库。显然，也是需要一个系统的计时器。因此，这部分目前只能是推后，直到系统定时器出来。

2005-09-21T11:57:00.000+08:00

今天再次考虑一下是否升级dababase，这是最早时使用XML来代替简单基表的解决方案，当XContainer已经出现后，就显得有点简陋了；最终实现升级是必然的事，如果这个项目最终能够完成的话。当有着先例的情况下，使用XContainer升级这个老的XML文件，不会是太麻烦的事情，问题在于，调用的地方会如何？目前调用的情形，已经脱离了lister，因此，只要控制会几个访问database的标签，也不会产生太大的震荡。难点主要在于那个二级，会涉及到另外几个base，因此，有可能会造成一个升级延伸。其中最大的动作，毫无疑问还是在于那么database.service的升级，这个地方，涉及到线程的使用，可能会有一些震荡性的动作。

下一步升级涉及到的，大概是这两个问题。刚刚让防火墙老客户估计是arp欺骗的求告弄了一下，想起，大概也可以安排李继搞一搞这件事了，不知有什么用，但是大概可以帮上某一件事情。

XContainer 里头装载的，是XOBJ，这和Database里的memoryBase还是有很大的区别的，看来，把XContainer的排序方法写进Base里，显得更为现实，由于现在的大base已经是在数据库里，这样升级的好处，是允许系统管理员可以通过界面编写，而这一条，目前还不算太迫切。

近日屋前盖大楼，头顶三家公务员又在装修，半年一修，共党的公务员就是钱多。白天把我的房子弄得象厂一样声威大响，加上女儿也在凑热闹，真是吵得不能静下心细想问题。晚上乘着人静一点，周围走走，想想这个base的事情；觉得环境还是不错的，白天拿个手机，也可以在小区里跑跑步，晒晒太阳。

细想下来，memorybase,simplebase,甚至multibase都有存在的必要而不会有多少更替的空间；而treebase就没有太大的存在的必要。另一方面，simplebase结合数据库的支持也是必要的，当初也没有做错什么。treebase目前仍没有真正开始使用，显然，这种反向遍历效率太低，如果不是使用子集的形式，根本就不值得采用。由于XML可以解释子集合对象，这样，的确存在着把子对象变成链集，实现无反向遍历的树表，的可能性。并且，这种结构还可以继续使用simplebase的数据库支持，通过XML字段存储子集信息。

把memorybase存储到小文件中，可以实现另一个目的，就是把这些存储清除出内存。对小文件的当前查询和解释并不可怕；而原来的大文件方式就显得太可怕了。

simplebase存入数据库中读的时侯载入，一定时间后清除，一时也想不出更好的办法。如果实现的是静态发布，实时访问量会大幅度减少，对于数据库支持性能的担忧也会随之减轻。这里，没有必须如何升级的清晰的主意。非常肯定地，目前涉及到DATABASE的升级的工作不是一天可以完成的，估计需要三天时间。想清楚，还可以一点点地升级，这几个步骤看来是不必然相连为一个的。

2005-09-17T20:07:00.000+08:00

今天忽然说起为什么还有钱给扣了，才记起保险公司那里还没有收到它的发票。这里构成了一个闭路的混帐循环：工行特别麻烦，而电信那里总是抢扣钱，扣了钱还不知道它是从那里扣的，它还从几个地方扣钱，最后，是保险公司那里老是扣不成功钱??估计是扣不成功。不但如此，先前那个王卫红的医疗保险还拿了我几百元，到现在还没有把发票拿回来，如果是真的，那就是第一次出现吞钱的事情了。虽然只是几百元。明天和这个星期的第一件事就是去银行把帐单打出来，看看钱到底扣出来没有。

……打完卡，发现钱已经扣了出来，这下就到了另一个问题，为什么没有把发票给我，以及另外的住院保险下落如何了。

2005-09-02T23:04:00.000+08:00

昨晚睡眠不佳，一早本来想睡睡懒觉，谁知道楼上楼下的装修声音震天价地响起来。妈的，咱们这些鸟同胞一天哭穷，一边拿着共产党分的房子??他们买的房子最便宜的只有一万多元一百多平米，平民百姓根本想不别想；可是呢，这些“穷酸”却有本领每年拿出十万八万不断地把房子装修来装修去。不但如此，公共照明、电梯、管理费，等等，要他个人出分摊时，却又拖来赖去地不愿交，希望单位给他埋单。当然，这是因为他们的单位都是皇家饭的单位。其实中国坏就坏在这些高高在上的“公务员”身上，把整个社会吃得精穷。给吵得睡不好，人也特别烦燥，偏偏老板来个电话说中秋请吃饭；这样一整天就泡汤了。但以这样的状态不能休息调整，其实也干不了什么事情。

刚刚完成的博客，给这帮家伙试用时，抱怨的东西一大堆，到头来没有几件是真实的。也许是过分烦燥吧，以至于不想再干了，本打算把帮助写下去，但是越写又越不想动笔??好好的博客放着却要手工编HTML，总是觉得不大对劲。最后还是想通了，应该用博客写这引动帮助文件，反正已经是静态文件，一来可以试试，二来也可以方便排版。但是我自已的五花八门的博客就不要在这里弄了，以免个人情况暴露得太多??靠，就是因为对现在的博客都不满意才兴致勃勃地自已开发博客自已用，到头来还是不应该用。或者应该想其他的办法，比如注册一个域名什么的用动态网站把它建起来？

本来打算把那信用卡款给还了算了，谁知道居然还鬼那么难；一会是不能转帐，一会是不接收。总觉得这个信用卡有点怪，要说还款吧，妈的明显说终止了它自作主张给了人家钱，倒过来向我催款；却没根没据的。要说这个帐号已经废弃了的话，他一死催款。直接向它里头注钱吧，它又是一个废了的帐号，给多不退；问银行吧，银行的人居然让我别管。我又不想理它了，印象中上一次催款和这一次是一样的数额，有本事告我去。

国内的博客没有几个好用的，blogbus看来是比较好的一个

2005-08-29T20:52:00.000+08:00

近一两周业余时总想把一些文章发上博客，但两个多月没有跟进博客（却是自已应项目要求开发了一个博客引擎），再看国内提供的几个博客，实在是用不了： blogchina有一半的时侯工作不正常，另一半时间不是提交出乱码就是告诉你有更严格的政治控制；blogcn的前台分几段由xhttp读取更详细的动态内容，弄得打开前台要一两分钟（真不知他们的技术人员是怎么想的）；blogdriver和blogchina是同一个模子，blogchina的问题它全有，blogvchina没有的问题它也有。

相比之外，国际上知名的几个博客比这几个国内博客好得多，象blogger，从来没能什么大问题，最大的问题就是使用xml存储带来的多语言化问题；英国最大的blogcity工作也是非常的稳定，花梢的东西不及国内这些网站的十分一。这几个国外的博客最不足的就是没有讨三个代表的欢心，都给中国网警封得死死的。国内的网络信息控制官还是相当尽职尽守的，只要看到海外博客的中文信息稍稍多一点，就会随叫随到地把它封死的，反而是所谓的黄色站点，几乎都是开通的。

不过，也正是由于几个大的博客不能用，所以才想到要试几个小的博客。第一个是yculblog，歪酷；这是一个php做的博客，优点是比较稳定。目前较大型的博客一般是使用jsp/cofusion作为解决方案；使用asp的博客大多数在用户达到一定数量后就要在系统设备上付出很大的成本；性能上也得不到保证??说真的，还真没有见过成功的大型博客是使用asp的。国内的博客最成功的之道，大约无非是上市或招引风险基金，说句不中听的，风险基金一咨询技术顾问公司，就会对asp网站的真实流量表示怀疑的。

不过，如果jsp/asp用得不好，象 blogchina/blogdriver一样，就会画虎不成反类犬,倒不如使用php，php看来很适合中等的博客站型建设；如果用例模式的功能需求不是太复杂，php缺乏对象化的弱点就会不太明显，而它的性能硬度远胜于asp，也胜于设计不佳的jsp网站。

第二个就是blogbus，这也是一个php的博客。最早时浅试过这个小博客，觉得不怎样，现在再试一下，发现这个博客就实现的功能来说，是目前国内博客的狡狡者（不过部分设计功能看来还是比不上牛虻刚完成的那个，但网页版面的美观就远超过我的了）。这是一个完全支持完全模板的博客，它的概念基本上就是跟随着blogger实现的，活象是一个blogger的php简化版；看来也同样实现了静态网页的发布。（现在看来，所有网页以静态形式发布是既能让搜索引擎亲近，又能避免让搜索引擎冲毙的唯一办法）。它还实现了一些blogger没有实现，或只能通过第三方实现的功能，象文件的管理，看得出来，它是用程序管理服务器上特定的文件夹。先试着用用吧，看看它后面还有什么问题。

牛虻一直觉得blogger作为一个博客是很优秀的， myspace的用户排名在blogger的前面;但那看上去更象是一个象msn的 userapace的博客，我想这种博客大概不应叫博客了，作为个人网站（网页集合）的一个升级可能会更合适一点。因此，牛虻设计的博客也是完全跟随着 blogger的基本功能进行提供，这条思路与blogbus应该是一样的；也正因为如此，牛虻一眼就认出它的基本逻辑与blogger的相近之处。

要跟随blogger，就要实现两个基本的效果，第一是完全定制的模板，这意味着要写标志解释工具；使用程序控制的局部对话界面订制的路就走不通了；但倒也省掉了写一大堆无聊对话模块的工作量（牛虻最讨厌搞这东西了，如果牛虻没有看错，开发模板以及模板定制界面，占了许多博客开发和维护工作成本的50％以上）；牛虻使用了这种代码解释方式后，这方面的成本下降到接近可以忽略的程度。第二，要发布成静态网页，这既是对搜索引擎的适应，也是对性能的要求，否则每次访问都需要重新分析解拆一个长字符串，那是了不得的性能消耗。这是实现blogger形式的博客所最起码的，牛虻做到了，看来blogbus也做到了，到目前，似乎是没有看到其他达到同样要求的。

目前博客已经成了一个相当复杂的同时缺乏标准的产业，象tag，显然是索引分类的关键字，类似于sql中的like子句（但如果真的在前台提供like查询，这个网站几乎肯定承担不了很大的访问量），但却并没有被主要的几个国际上博客接受；还有象国内很多专业网站也声称提供博客，等你一进去，大致有三种，要么就是假的（象某健康网把论坛称为博客），要么是外购服务，象yahoo提供的博客面向ISP的有偿ASP服务；其三是使用一些免费却消化不佳的免费博客软件??如同免费论坛程序满天飞，博客也是有的；不过牛虻对这些免费的应用程序都不太感冒，主要是觉得它们的开发水平太次了，把它组合进自已系统的工作量远远超过自已开发的工作量，还象吃了死苍蝇一样恶心。最终结果就是牛虻目前感觉到的：博客满天飞，但真正能用好用的没几个，还主要在国外，让网警给封死了，国内全看不见！

最后又用了一下blogchina/blog.csdn.net，试图回答网友的问题，但更性能实在令人无法忍受。这个blogchina拿了两千万美元，反而变成一个不可用的东西了。既然blogbus可用，就移到blogbus上吧。

2005-08-26T17:40:00.000+08:00

blogdriver有很严重的技术问题，该栏难当重任，先前在这一栏上进行存储的目的部分是由于blogchina政治性控制太严；同时需要存下一些有价值的文档。blogdriver的问题主要有两个，第一个是首页的效率低，它居然是把全部内容读出来然后选择显示头和全部！这样无论是多少内容，它的系统负担都会非常高的；其次，就是乱码以及丢内容；这可真是致命的弱点。还是重复一句，真不知方兴东为什么会选上它，那个什么基金为什么会选上方兴东，简直就是大傻冒啊！

blogchina的问题也不少的，性能太差，它可是设备大升过级的！

2005-07-24T10:45:00.000+08:00

要提供自定制网站，要做的事情看来比预计的多得多。要实现各个样式模板定制，如果象blog-city那样，交互界面的工作量就大得不可想象，而且大部分是我不擅长的界面工作，能够给用户定制的量定际上也很有限，这个方案是不可行的。blogger的发布方式可以实现完全定制，的确比较吸引人，但是等同于完成一个自已解释的发布工具，这个问题还没有完全想清楚。

一般说来，jsp页面上的发布，就是在html上用自已定制的标签等把动态内容抽取出来。显然，逻辑是隐含在下面的scriptlet/标签之中，只要可以把文本写进指定目录的指定文件中，当然可以发布成任意形式的html/xml;缺点是，每次更新都要进行相应的发布，更新页面。这是blogger的办法。

另一种方式就是发布成jsp，这样可以通过标签动态读取更新内容，减少了发布的工作量，不过，允许用户发布jsp代码是非常危险的工作；除了他可以等同于访问系统外（这可以通过限制代码类型相对减少危险），还由于每次更新系统会令系统重新发生编译工作。在此以前，这是不可承受的，但近来随着maxsper 似乎暂时得到解决。当然，从长远计，仍是不合适的；短期内，有可能令发布的工作显得加快。

第三种方法就是把现成的jsp通过import输出成静态网页形式，这种办法顾名思义，就是把现成的网页输出，显然，对于不是现成的网页，不是一个好的解决方案。

当前而言，时间太紧了，需要一个中间性的过渡方案，第二种方案应该是比较合适的，可以直接先按jsp编写，然后再允许发布几个标签，最后，完全改换成html.

繁简转换，和搜索引擎带来的类DoS攻击

2005-06-10T09:54:00.000+08:00

这两天研讨这几个博客和广告有着现实性的意义，其中原因就在于对于博客和主页这两者的关系和应该做到的程度没有什么谱。现在看来，一个完善的主面显然是应该超越博客的，模板是最好的办法，可以把界面和css的工作扔出去给用户自已来。作解释性的输出对我来说不是一件太难的事情。这也可以应对目前界面人员职业水平低的缺点，事实上，弄不好除了我不会用PS外，我的水平也是最高的；而PS，看来是要学的。对于网络的广告需要作一个详尽的规划，这不是今天的事情。另一个重要的部分就是图片的上载和管理，当然包括了空间的管理和限制，这两个模板都只能推后实现。而陈今天早上说的挂号也是一个。

当妈子把保险的存折拿回来后，发现存折没有扣钱，反而是电话把钱扣了??我从来没有印象是使用这个存折去交电话费的。这个存折一直是专折专用！而实际上从上面看来，已经给扣了好几个月了。这次没有扣款可能有两个原因，一个是收到通知的时间很迟，其二是如果按通知说的时间，我应该是已经迟了交进去，其次是黄黄做的好事：她把我这个拿去交了电话费，弄得帐面的钱不够了。而工商银行网点少排队时间长也是一个问题。如果从通知看周一周二不办事，那么我还要现在提早过去呢。妈的！

现在保姆和猪猪和妈子一起去打预防针，已经是10：30分了，出去的话她们回来可能会没有门进的。而且赶到后也已经是中午，看来还是下午去吧，或者应该把那个社会保险也一起办下来了。难道20日还要再走一次吗？就这样决定吧。

目前在开发的时侯，由于数据库是共用的，而processor已经改由数据库的metadata识别，这样如果更改了数据库而没有及时更新类文件，就会在前台出错！因此，类似的修改还是在本地先进行吧。

动态个人网页需要增加一个单例短文属性表。象目前前台的一些属性也应该可以使用这个,这些属性修改的机率比较低，而读取的机率比较高，也不存在回复啊，查询啊的故事。其实是可以使用文件，然后直接往目前中生成这些静态的文件。目前仍没有担心系统性能不足，如果到了那一天，也的确可以把大量的文章作为静态的文件发布出去，这样也可以大大提高系统的性能容限。这个表的读取每次只是显示有限的几个，所以可以使用数据库；但如果数量稍大，那么就变成一页要读几次数据库，那是万万划不过来的。

博客那里需要更多的一个帐号，从过程看，似乎目前最有把握拿到的是垃圾那个，就先用那个帐号申请，看看能否成功。手头上好象还有几个网站可用的，总之，帐号可以多一两个，但当前大概只需要有两个就可以了，如果有三个当然是最好的。无论如何，如果发表的内容不是那么阳春白雪容易挨骂的话，特别是在这个国家，还是小心一点为好。申请过程中网景死了，它的postcard实在是一个垃圾，用例假设完全是失败的。

今天第一次接触到繁简转换，意外的是windows的那个内码转换工具完全不能工作??估计它不是这样用的，大概是用来转换象properties文件之类的多语言版本之用。而在互联网上，我找回来的那个繁简转换似乎更简单易用，可以把它做到一个网上服务的类型。由于blogspot诸网页都是大陆无法看到的，因此，专门作为一个面向海外读者的网站可能更为划算。blog-city也是一个以unicode为主的网站，不过，由于它使用的是html所以也没有多大的所谓。我想呢，凡是这种面向国外的网站，大概都主要使用繁体会得到更佳的效果。简体就在国内使用吧。

由于整理那个意见，又在博客上花了一点时间，做完了，就听见猪猪在那里哭哭啼啼个不停，因为没有人陪她玩。不过我下午急着去搞保险项目，这事情整整花了我一个下午。

晚上开始不久，就碰到怪事，网站一下子极慢，并最后死翘翘了，原因不查自明：会话达到了1700多个，而且是短期内的阵发会话，几乎就是等同于DOS攻击了，这个强度已经远远超过了我进行压力测试的最大值。检查日志，发现同时有几个搜索引擎在扫描我的网站。这些搜索引擎实在有点讨厌，不过看在它可以招引浏览者的份上，我一直容忍着，但这次是太离谱了，日志表明，其中深址的219.133.49.235居然每秒钟发出十到二十下扫描请求，连续几分钟不停，换成别的任何网站都会受不了的。我把它禁了以后这种不署名而且无良的搜索我会把它禁掉的。

但除了防火墙禁外，还有没有方法呢？IDS我不敢启用，在公共网路上启用IDS响应很可能导致自我封闭式的DOS，但是这种同一个IP，然后密度很大的行为，如何在程序上加以识别并加以拒绝呢？

records

2005-06-10T08:58:00.000+08:00

06-10; 28000said;doctor3; 9.24 read 34000 ; register 35; alexa 7212
06-10 20:00,遭遇搜索引擎?描?密，???1700多，重?，?封?219.133.49.235
06-11 8:45 alexa??10959；????10734,登?51；

处理集合类型缺陷，研究博客的模板功能以及专家主页的层次

2005-06-09T08:03:00.000+08:00

昨晚其实是提早上床睡觉的，但是仍是老毛病，难以深眠，早早就醒，这是精神疲劳的表现。

alexa计数的确是不定时的，早则２３点多一点更新，迟则零晨吧，升了一千多位。这应该是周二的值，这段时间我是一直使用刷新的，但这次好象效果不是太明显，有可能是由于某些电脑停了，象asoka那台电脑如果没有使用的话，也的确是会带来一定量的影响。周一周二他们出去派卡，所以工作人员上网的比例低了，也属正常，没有出现大幅度倒退就是很成功的。

昨天发现的问题，显然是由于集合属性赋值上的不同步，把老的集合值重新拿了出来，所以不能更新。要解决这个问题，唯一的办法就是令它同步，最不济的就是手工覆盖编码的方法。现在的问题显然是由于更新字段的方向既可能是更新集合，如热点值的用例操作，也可能是更新这个字段值，象这样的roles的操作。 instanceCollections的效果是直接从字段到集合，反之,serialsCollections是从集合到字段。但如果中间一些字段从集合始，而另一些字段从字符串开始，那么目前的方法就不够了，这就是问题。

完全手工编码显然是低效的，看来还是有相应的解决方案。使用容器当然是最终的方案，不过目前没有时间。而使用公共方法的调用，然后在每个设入或读出时都进行一次调用，会是合适的解决方案，缺点是，需要修改那个Coder，其次，如果所有类都更新，短时间内会有系统级的抖动。不过，似乎也想不出更好的办法了。因此，集合实体的程序其实还没有完全完成，只有当Coder已经完全更新可以自动输出相应的程序后，这个程序才算得上是真正是完成了。

当doSychonize 方法完成后，那么原来的instanceCollection方法就显得过时而可以加以废除了。……好象并非如此的，删除后，由于从数据库读出前没有 entity，所以就无法完成初始化，这是原来没有考虑到的。而当实现从结果集转换成持久对象的过程中，由于并不是根据dao而是根据 class.fields进行抽取的，这样就不能在一开始set入的时侯先设入entity，（当然，强行修改也是可以的），目前使用这个 instanceCollection，可以减少系统变动，也是一件好事。但最终仍然是把它去掉了，原因在于始终不便于从几个地方维护。这个问题完全解决，已经是中午了……事实上是到了十二点半。

中午太累了，还是先休息一下。下午从修改文章类别使用这个集合类型开始。但是猪猪在门外吵吵叫叫，加上保姆和黄黄的姑妈也在阳台上吵吵嚷嚷，又不好把她们赶跑，别人还好说，但猪猪叫我总不能叫她收声的。所以中午这一觉是似睡非睡，和阿琼聊了一会，最后又让高的电话弄醒了，只好起来再继续做事。或者，在书房睡效率更高一点。

无意间发现博客中国的页面是根本上全部下载了然后不作显示??这样说来他们的流量中的大部分是虚假的流量。难怪我的那个博客会如斯缓慢。稍作修改后又发现它的逻辑是：如果有摘要就显示摘要，否则就显示整个文章体。另外它的图片的下载也是显得非常的慢。调整博客中国仍然是花了一定的的时间，总是开始时觉得一点点操作就好了，结果最后却发现花了一两个小时。同样是无意中发现，csdn的公告栏中昨天放进去的广告显示出来了，这样，由于这个公告栏会出现在所有的版面，而相反，博客中国的文章中无法显示广告，因此，这里发布的技术型文章，无论是从评级还是实际效果上看，都会比在博客中国中要好。难怪昨天的统计渠道数量远远的少于所有汇总的数量，要知道，我的渠道是绝无可能重复的。但是CSDN其实也只是垃圾中的精品：号称是中国技术代表性站点，选用了asp，还做得很精细，结果是三天两头……有一会儿是可以访问的，其他时侯都是不同形式的死翘翘的。打算在它的公告栏中加上一个GOOGLE的搜索，但结果却发现让它的一个form给挡住了，打算用脚本绕过它提交，也成功了（原来GOOGLE不可以使用post的），却是乱的中文提交，结果只能找英文，中文是不成的。不过，事实上就算是在secure网站上的google提交也是不能的，结果是一遍的空白，什么也没有。这件事情同样是原以为几分钟的事情，结果花了我差不多一个小时。最后发现，在文章可以编辑源代码的版面中一般情况下都可以插入广告，对于象csdn没有太大的价值，但是对于不能在文章项目中插入广告的blogchina，就有着积极的意义，所以花经了一个多小时，尝试性把第一版和科学版的文章加入了广告而实际上这次打开博客是想看看内容部分是否可以加入那个小天使的背景图片……实际操作时发现已经是第二次作这个尝试，总之是不行，原因不清楚，也没有心思现在去找答案了。Google搜索那里转转眼，

文章方面目前基本上就是在主网上显示；大致可以分成总网和子网两个类型，而这两个类型也可以通过一个虚拟的科室进行区别；可以假定总网的文章也可以用到健康网的上面。当加上了另一个类型，如博客和主页时，就需要添加上一个BASE类了，同时，这个操作类型，似乎还没有相应的操作组件可以使用呢。原打算文章类型使用集合进行调整，但把以前的设置一抄，结果就变成了单列的选择，这也是一个解决的办法，我还是有点想得不算太清楚，就是跨类型的显示有没有必要；是不是受欢迎。现在很清楚，无论是陈还是那些医生对于如何建设这个网站是没有什么准主意的，那些医生的潜意识中只是将这个看作是一个自已文章的集散地，如果连他们的研究生的文章他们都不愿意发，那就有点过分阳春白雪了，又怎么可能以共享的方式吸引到其他的专家同行来呢？回想当初的专家黄页所谓的只收副高，思维何等的狭隘！所以完全可以假定，他们不会愿意接受其他人的文章，尽管自已组织文章的数量总是很有限的。

昨天让老妈子帮手买平安的健康保险，今天又接到电话，要在620以前买下一期的社会保险；这件事情可以记住了，只有几天的时间……好象620是许多事情的一个日子，或者只是巧合？

近傍晚，高气冲冲地投诉诊室那里修改文章类型权限拒绝，但是我那怕把程序下载到本地调式，仍然是一切正常，直到把dep上的系统重启了一次，也正常了，真不知是什么原因了。从记录上看，似乎是artype2的原因，但如果是这样的话，www也会有问题的，而且使用管理员帐号也是有问题的，但是事实上那是正常的。反正，俺不是很清楚，这又是一个matrix现象。

文章的分类同时规分出hzw/ysw并不能代替目前的artype的分类方式，但是可以令文章介时以分网形式的显示提供更高的设置效率??调整也只是使用 sql命令的短时间操作，所以其实也是无多大所谓的。投稿其实是不存在的，只存在博客文章的采纳，但又出现与投稿同样的问题：那些笨蛋会不会接受人家的投稿？估计他们完全不能理解使用博客这种形式。现在的很大问题是那些“专家”对互联网是一窍不通，但同时却让他们（应该说是让陈）缚住了手脚，所以无法采用很多常用的网络经营手段。真要做出点名堂来，唯一的办法就是跳出这些个科室的实际限制。所以能够跳出科室限制的手段都是可以使用的。事实上，由于主页使用的文章类型都可以用另一个域值的非零标定，这样，就可以做到同时适应于多种使用，或者，这是更合适的办法。

事实上，这个主页就是一个博客，既然是一个准备要收钱的博客，那就必须去了解一下他人的博客是有什么功能了。根据我对博客的观念：博客的生存之道就是帮助博客用户通过博客赚钱赚名，然后向他收取费用。显然，目前的大多数博客的操作完全违反了这条规则，可以肯定，都是不会有好结果的。出于这个目的，我逐一地观察几个博客是否满足这条原则，和满足到了何种程度。结果最精明也是最愚蠢的是显然是歪酷，它的技术选项就是百分百防止博客卖自已的广告的，换言之，它投资搞那个博客应该是烧钱支持公益不营利事业，大家都知道，这种行径者高尚到愚蠢，然后死去。

另一个blogcn呢？看上去提供了最强大的模板，接近于blogger的方式，但它的刷新太慢了，我等了差不多半小时还没有看到结果，说不定也是银样蜡枪头过分精明（本人赞他人聪明精明的话真实含义是那家伙蠢得可怜）。反正俺是困了，明天再说……但是就在我打算睡觉的最后一刻，刷新一下后，发现它全部出来了，换言之，尽管blogcn的技术（体现在性能上）实际让人不太感冒，但它却是最符合博客的生存原则的，这足以令我对它刮目相看，大概，我应该把主力的站点移到这个博客上。

试用了所有的五笔输入法，从８６版的选择应该是极点和念青

2005-06-08T10:45:00.000+08:00

一直到此前，用得最多的是８６五笔，在linux平堂上装了一个念青五笔和另一个默认的五笔输入，除了互相冲突，此活彼死外，linux上的五笔还存在着严重的缺词缺字；所以用起来感觉远不如在WINDOWS上顺手，当然，windows的客户易用性是无可争议的。８６五笔经历过一次升级，９８五笔，但却是有史以来最失败的软件升级案例，王志民显然不是一个软件客户化的专家，他不升级还好，一升级几乎等于判了他自已的五笔死刑。从五笔前途看，王最合适的选择应该是完全公开五笔作为一个开源项目，然后通过这个开源项目卖自已怕广告，或者，收入会远比现在这样收使用费现实。

五笔越来越有限制，作为挂在windows2000上的输入法已经开始走向沿落，而以前试过装过几个另类五笔，大同小异。86版的主要问题是词量太少，在同一台机上长期使用后补充词量可以初步解决这个问题，但是仍是一个不少的工作量，而且换一台机就没有了，总是滑稽！而98根本就是垃圾，与86版几乎没有继承性，象我这样基本上只使用五笔的用户试过几次转换到９８版，都是屁滚尿流地转回到８６版，可见基本人会是如何光景？软件的升级，特别是输入法这种升级，客户的使用习惯继承是最重要的参考因素，而编码的优化是最次要的因素；升级，应该是根据的使用习惯进行优化，而不是另开一套编码。这是最经典的升级导致被淘态的软件案例。
尽管重新使用五笔８６，但是中文输入越来越依靠一个缺乏维护也不公开的编码方式，总不是一个办法，实际上已经明显感觉到了它的限制，以致于我作文时不得不在用词时也要考虑五笔实际上能够支持什么词和字。所以一直考虑尝试新的输入法替代方案，可是仍是不得要领，其他的输入法大部分是拼音优化，没有什么特别的突破，作为非职业的人员来说大概可以满足少量输入的需要，但是不是一种经典的可长期持有的方法。尽管我不是中文输入法的专家，那不是我的专业强项，我只是解决了有服务器存储的中文编码问题；但仍然觉得桌面中文输入其实是没有找到根本性的路子，目前的吹牛什么中文是世界上输入法速度最快的语言，完全是无知者的自恋式吹嘘。

五笔的一个问题是字根字太难找，实际上尽管反复地使用，碰到字根字仍然是头大！打字速度经常在这里给中断了下来。这个问题我现在找了一个在线查询的编码网站，大概可以缓解这个问题。而另一个问题就是字编码太少，象“?"就没有！这是使用者最经常碰到的问题，所以五笔输入软件理论上应该自带一个编码查找的工具，并允许用户自定义编码应对规则，但显然目前的五笔没有这个功能。

五笔输入输入的另一个问题是输入字和词的选择。我的速度是极快的，目前计数是每分钟大约７０多个字：这不算快，职业录入要求至少８０个字一分钟；而事实上，真正有一两年职业录入的录入员的速度也比不上我快，尽管她们的速度记录是每分钟１２０字。问题在于我打的是字，而不是词，如果我大量录入某一领域的词，那么速度计数就可以轻松地提高一倍左右。而实际上五笔汉字不但重字，而且有大量的重词，重复的频率远远超过了字的重码率，以致于打词是一个不可靠的方式，甚至很难做到完全不看提示框就进入通过词的输入。而对于录入员来说，词可以很长，特别是专业性的文章，甚至可以把一个句子作为词通过四码输入，但对于使用电脑写作的人来说，出词的机率非常高特别是双码重词，一个作家不可能在思考一个句子能够预先提早十个字预计会有什么词，特别是习惯性用词。

我的使用习惯表明，打词基本上不能提创造性写作的速度但可以大幅度提高录入速度。我是极少直接打词汇的，打词存在不少一唯一性，实际上降低了输入的速度，词，一般在不会打那个字时打入，而且一旦习惯打词，当词条不是每台电脑一样的话，就会大大降低录入的速度。另一方面，对于不用动脑的录入员来说，打词是可以预计的，而对于象我这样高速打字写作的人来说，思考中涉及到的词在微秒级只是达到未来的一到两个字词，所以不可能在思考文章的同时预计会出什么词，一旦预计打出的词没有如预期的出现，整个录入的速度就会大幅度下降。事实上，这反应出一种语言的要求：尽管汉语是以字为义的根元，但是实际上人的使用最通常的方式仍然是以词甚至于习惯用句来思考的；由于五笔词的重码率高，就变得不太可靠，而字如果打得熟了除非少量的字根字难以迅速打出来，这是五笔的一个缺点，那么直接打字的效率要比打词更可靠，也更快。这是下一代的输入法应该考虑这个问题，就是针对打词并且不应该与打字混淆。日语输入中的输出缓存可以考虑的，这样可以在最后通过一个识别码决定本次输出是字还是词。从本质上说，这也说明汉语的发现方向是演变成词义字元式的表达方式，才能适应文化电算化的要求。争论汉语是不是最合适电脑处理的语言是无意义的，会混淆本质，令这种语言得不到进步。

升级的另一个要求是能够用一种输入法兼顾两种汉字编码，甚至三种，gb2312,gbk,gb18030,big5,作为一个大陆人不可能去学台港拼音，更不可能学仓颉码；同样，要求一个台湾人使用五笔也是甚为难为。而在电脑中这是可以做到的，输入法编码其实是一个动态组合查字名的过程，而字体是一个显示光点组合的16位数值，这由字库决定，与输入法无关。因此，应该是很容易办到的。

问题是用什么升级了，当前仍然是查找新的五笔输入法，它的要求是：第一不用钱，因为８６就是不用钱基本上可以使用，如果要钱的话，意味着在一定时期后这个输入法是得不到维护的；第二应该比８６强，第三应该能输入繁体；第四是占用系统资源少，不是一个用我的资源拍我马屁提供一些无关紧要的功能的垃圾。

前两天花了半天时间几乎把几个现有的五笔方法装了一遍，结果，几乎全部淘汰了，只剩下一个不用钱的极点五毛和念青五笔是好用的??软件的事情就是怪，除了微软ORACLE这样有长久承继性的软件外，几乎总是不用钱的软件比收费软件更好用的！感觉上和86差不多，它与念青五笔都有一个优点，就是与 windows的录入框架非常友好，不会自已另一起一套，凡是另起一套框架却对windows一窍不通的东西，几乎肯定就不是什么好东西，万能五笔就是一例。

那个万能五笔是最垃圾的，不但功能最弱，而且最霸道，还设了一个木马把265设为首页。一些中国软件人为什么就是这么贱？桌面软件不赚钱目前是事实，但搞这套就可以加以补偿了吗？区区一个输入法，不但占用了大量的资源还互相打架（因为超出了微软的输入法框架，那是一种游戏规则），而且还搞那么多小动作，我干嘛要用它呢？把它用反间谍软件清除后，我不但永远不会用，还会永远禁止在公司使用任何万能五笔；而且永远不会访问２６５，而且永远建议投资者不要投资２６５网，因为它的流量是虚假的。陈桥五笔也是垃圾，不但要另外占有大量的资源，而且还想时时要钱，真是一个垃圾的东西，然后看来，凡是打算要钱的基本上都非常接近垃圾的水平。

念青五笔与微软匹配最佳，而且念青五笔可以实现windows/linux等平台的习惯通用，可以认为是８６版王码的最天然的升级品种。在windows 平台上，极点五笔具有与念青五笔同样的占有资源少的优点而功能显得更为全面一点，所以windows平台选用极点，可能会比念青更佳；何况念青也是要钱的，只不过不会太下流的方式要钱而已，而极点五笔，就开宗明义不用钱的??比王志民要聪明得多。极点五笔和念青五笔都对繁体有完整支持，所以繁简这个问题初步看来是解决了的。

仍然花了一点时间在博客和广告上，杂事多，应争事也多；专家主页其实没有进展

2005-06-08T08:29:00.000+08:00

今天抓紧时继续，博客和广告的事情要先扔到一旁，那那个东西是不能够天天看着的，而图片的能力也不是立刻就可以得到提高的，所以目前是差不得就放到一旁去了。昨晚上本来是打算和老婆亲热一下的，但时间一下来，已经太累了，结果是睡觉了。由于猪猪跟新的保姆睡了，所以倒了睡得很有一点质量；只是猪猪已经一连两晚哭闹着不肯睡，抬着头就去找妈找爸，不过也是不能不这样，道理上孩子应该自已睡的。

要开发一个主题的博客不是光是做一个博客就够的，如果不打算别人知道的倒也无所谓，但是如果是打算有点价值的，通常就不是一个博客而是一批的博客，这也是从安全考虑。期间也必然关系到包括主题、分类、版面设计和文章归理，广告设计，广告策略等。不是一个小量的工作，如果使用的是多个博客，就包括对多个博客的评估，以及各个博客功能的运用等。

把时间向前推上三天，从上个星期六开始，实际上有多半时间并没有集中精力到软件项目上，先是六四，然后是和Joan几个序旧，然后是五笔和博客，最后是广告，而象昨天，基本上全天没有真正干过项目中的事情。除了这些相对来说也是正经事以外，实际上还花了大约有半天的时间查找关于战列舰舰炮发展关系的线索，这是由于技术争论而起的业余课题。而今天是应该把精力回转到正经事上面了。说是没有集中，是相对于我原来的工作效率来说的，实际上在这么多人当中，我干的事情还是最多的。

karran 发了几份简历给我，只是从这些简历上看不到什么有价值的东西，而见面本身则显得非常的浪费时间，因此我不太愿意就此花我的时间。等k上班后，就告诉她先去了解一下他人的工资要求水平，以后也是这样处理就可以了。但马上回应是下载要给钱，这也是前面考虑的事情：目前网络招聘其实省的不是公司的成本，省不了多少，而可能是扩大了可招收的面，并省了一点人事人员的时间而已。可想理想的网络招聘应该是一种可以让老板直接招聘的网站，可以针对性地搞成针对小企业的招工网站。

这几天把时间转向其他地方除了有作一次清洁积事的需要外，还因为要做的事情堆得太多，直觉是不可能在这段时间里完成的，那就需要静一静，或者断一断，以便清出最需要的事情，而把成批的事情向后面推。如果不是经过这种思考而直接把所有的事情都postpone的话，那就意味着怠工了，这是一个非常核心的区别。许多人不明白我为什么在需要把一件事情放下前，仍要花时间把它思考清楚，其实就是这个原因。

中午高又说科室修改用户组不行，记得这个已经解决了的，为什么又一次重新出现呢？其中一个原因可能是没有真正实现更新，但目前没有时间细看了，手工先把东西扔上去吧。

关于论坛：
论坛显然是一个延续性非常明显的工作，无法清晰地摆出它的边界，事实上在操作的过程中存在着明显的功能上的扩展。象目前的qzys就是如此，它目前碰到的不能短时解决的问题是回复和跟贴是无法简单区分的，而特约专家和非特约专家的回复也应该加以区分，这就不仅仅是简单的界面问题，而包括大量的版面修正和用例探讨。对于统计来说，可以做到目前开始就分割回复和发?跟贴，但是从前的记录计数就变得无法再核准了，这样的意义也不是太大。总之，我觉得论坛的事情是如果要处理的话，虽要在时间不是太紧的情况下细心整理，而不能预先定出处理什么什么项目??除非已经有完整的用例分析，否则这是不太可能做到的。而完整的用例分析，目前没有其他人可以做到。结论是，向后推。

关于注册：
目前的另一个存留问题是注册方面需要让专家乐于注册，其中涉及到一个在线审查用户，而最接近的就是在论坛中回答问题时要求他填入更多的东西，不过，这两项都是不小的事情，更是需要详细的渐进式的考虑，所以，今天仍是需要把它向后面推的。

关于这个博客：
看来，这个博客使用XML而不是数据库的一个好处是可以随读随入，而不必考虑这样会加重数据库的负担，这样对于使用者来说可以象在桌面一样习惯性地存盘，但它的缺点是不能很容易地回到原来的地方，相比之下，blog-city就做到了。其实也是非常简单的，只需要在后台添加一个继续编辑就可以做到了。……其实，我可以把这个连接连到博客项目上，然后直接进入编辑或者看到前台的效果的。

关于专家主页
这三者与博客及专家黄页的关联和区别，实际上还没有考虑得非常清楚，但要在今天短短几个小时内推出一个版，看来也不能考虑得太仔细的，唯一的办法就是直接让它可以打出文章。这就涉及到一个问题，文章本身，是否应该与原有文章放在一起？这个问题是考虑的。重新查找了一下以前发布的文章，当时的结论是应该合并为一个表；看来这是有道理的，如果要合并为一个表就必须把这个表增加一个键值，使用多对多的键值显然不是一个好的办法。

下午四点：www服务器好象再次出现了溢出，看来内存的设定仍没有到位，这是一个严重的问题因为，这个溢出是在已经有一段时间没有修改程序的时侯发生；其次是溢出后没有恢复；第三是在溢出时实际上指示还有大量的内存空间可用，而为什么会溢出呢？那只有一个解释，没有充分使用到提供的内存空间。那换言之，就算加大内存也无法增加负载容量，老实说没有什么比这个更麻烦的。发现有内存溢出报警是在前一两天就有的，与负载的关系并不是非常大，目前仍闹不准它什么时侯会是内存会面临溢出。尽管这个是最重要的事情之一，但既然是没有什么idear也就暂时不去理它，仅仅是把使用的内存空间再次加大，看看结果如何。…… 记得曾经记下这篇文章的，结果在博客中国中就是找不到，相反，使用google一查，却查到了自已的那篇文章，很简单的，最后把xms加上去了，out of Memory的问题也就解决。这次可以看到内存统计上直接上到了1000M以上。

下午傍晚时分，在博客中国上又花了两个多小时的时间，主要是放入广告和背景，并与blogger作一个对比，看看其在订制性上有什么差别。看来，博客中国和相应的那个bloggerdriver以及csdn都有着同样的缺点，或者是同样愚蠢的地方，就是限制使用者组织自已的版面和广告，能够这样做的只能是那些自以为高明的年轻小程序员，用我的话来说是够精明，太聪明；算来算去最后却是算了自已：用户博客如果自已不能赚钱，又如何能为收费博客付款呢？

实际上，今天应答服务请求也占了我两三个小时的工作时间，以及为招聘而花的时间，其他电话也是接连不断，这就令我到了晚上仍不能真正开始那个专家主页的工作；雪上加霜的是家中几盏灯也不能亮了，通常这意味着原来的灯的方案有问题，如果一盏盏地跟踪它，成本就太高了，有点受不了。

无论如何，还是回到那个结构的更改上吧，由于文章决定是一个表承接多种类型，所以需要添加一种文章类型，同时，如果弄成一个多对多的表格的话，就意味着要全部文章记录都要更改，显然这不是一个好主意，还是使用集合类型吧。集合方面今天出了问题，我打算顺便看看它。发现了原因，但是其中一段看不出必要性。

晚上的时间主要google中的广告引到了一个似乎是异样的招聘猎头网站上，还作了登记；我希望这会对我考虑招聘网站有点作用。另外的时间就是解决那个 tomcat内存再次耗尽的问题　，这个问题不解决，坐立不安。alexa的排名升了５０００位，好象还没有更新？因为我记昨天还是这个数的，今天的数字应该是周二的值。那么就应该是升上来的第二次才对？？似乎还是这个值！

拿到了google广告条，也发现这个博客可以改不少地方

2005-06-07T07:31:00.000+08:00

今天早上仍然是早醒，仍然是再花了小半个小时查一查历史上208巡洋舰炮有什么特点，仍是不得要领，看来，应该是一种?助装填的整弹炮，不然无法理解为什么三十年代列强会专门打算造一级舰装这种炮。

终于批到了google的广告条，但是原来拿来申请的网站太旧了，页面设计也不科学，一直没能太多的时间去整理，所以仅仅是把一个广告贴到首页，当场就让整个网页变了型，不过也没有太多的时间去修整，等手头上工作告一段落后，就把那个网站重新做一次。而现在，首先看看把这个广告能够不能在这个博客上贴起来。结果发现这个博客可以在模板填进各种各样的代码，这样就达到目的了，基本吧，如果知道它的对象是如何提取的话，可以做更多的东西，但至少目前是可以使用了。而一来从laura那里拿不到广告帐号，二来这帐号也没有能够成功登录进去，三来更有趣的是google干脆就不能访问了，估计又是盖世太保干的好事。

这个极点五笔还没有找到不让它跟随光标的地方，总是会挡住输出界面，我是看作输出打字作文的，这样对我的影响还是比较大的。我打的是单字，使用词组如果是录入没有什么问题，但如果是作文，单字比词组要好一点。但是我在本博客上调整了如斯时间后，却没有从渠道中发现有记录。换言之，我还没有把握，那个广告是不是允许在多个网站投放的；或者只是在一个网站下的网页才允许进行投放，这是目前没有把握的事情。高岚的广告发给我后，却发现没有办法登录上去，不知是不是给封掉了。而高岚本身是问过，同一个广告帐号还是可以在不同的网站发布的，库可靠见，我想还是要再搞一个帐号，以备急用。

念青五笔的感觉与王码八六差不多，但支持GBK码，所以这样就可以把86扔掉了，如果念青不会另外收我的钱的话。上午尽管搞GOOGLE广告花了一点时间，包括这个博客的调整，但另一个地方，那个早已解决的URL重写用到全科里也花了我不少时间，最简单的东西却搞了两个小时，最后好了也不知原来错在那里（不可能错的东西），好象是有一点缓存的迹象在阿帕奇里，而不是完全按照规则填写进行重定向的。

不过，最后试来仍然不行，如果我把博客体在首页隐掉，那么连细页也不会显示出来，如果显示细页的话，就必然显得长得不得了。……整一天大部分时间，包括晚上，都是在学习如何使用这个blogspot的博客，它的调整模板项倒是不太难，只是模板逻辑显得单一基本上掌握了。

于公而言，这是在了解一个博客应该有什么功能，以前他人的功能做到了什么程度；于私而言，是希望让这批博客发挥出它的应有价值；而当前是由于得到一个 GOOGLE帐号后，想看看实际运行效果是什么。没有图片的话一个网站显得太单调，因此下载图片的时间花了不少，尽管已经严格限制了。secure的网站格构太差，这是之前的美工水平太差所致；我处理图片的能力太弱了，看了，这些相当于自已的网站，如果不能自已处理图片的话，是玩不下去的；至少是玩不好的。

把五笔都装了一遍，只有极点五笔还可以用，最垃圾是万能五笔

2005-06-06T09:25:00.000+08:00

早上很早起来的，开始做到要修改dao.xml中member，便联想到要把dao.xml的读入方式升级，以及相应的解决方案，但打日志时更觉得五笔不好用了（打了十年了，越来越觉得它不好用了），心血来潮要装98试试，这是第N次了，前面装上去总是不好用最终删除。这是最后一次吧，感觉98推出后五毛就完蛋了，王志民是一个笨蛋，完全不理解输入法的使用习惯比稍作笔划优化是更重要的选用因素。更糟糕的是，98不能用，（编码完全不对，难道重学一遍吗？），而86也失踪了，连重装也装不上。最后重启再装，上去了（估计刚才是内存耗尽所以装不起），发现原来写好的日志也没有了。幸好不算多。

所以五笔的升级是需要的，问题是用什么升级了。更新了一个极点五笔，感觉上和86差不多，而且暂时还不知道如何录入词汇呢！而实际上我是极少直接打词汇的，打词存在不少一唯一性，实际上降低了输入的速度，词，一般在不会打那个字时打。……

又一次?掉了?入的文?；那??能五?看?是罪?之首，?能是?不能！垃圾的?西，把它?除清光後保留了其他??五?等?入。把它?除了，??在桌面上留下了一?copyso的什??西。瞧在它好象?挺安份，我也一??有??理睬它，就?它呆著吧！另一?五?快打要????倒是不?，但瞧?付德性也?有什? 出?的地方，大把替代品，我?嘛花??不可靠的?西呢？??版找???都?得找，就把它?除了。反正我的原?是要?的就不用。?次的五?安?花了我?? 小?，才回到正?上。

从检验效果上看，上述文字不但在客户端成为问号，读回来也成为问号，原因可能与blogger.com使用的是 xml的存储有莫大的关系，由于XML文件有编码设定，因此，这就与先前的乱是同一个原因。而对于新的读回，也是使用如java这样的方案读成字节流，当然也成为乱码了。但是我对于汉字编码的内在原理还是不太清楚，这个问题不搞清楚，要做一套文字两套语言就不是那么容易的一件事情。

今天的alexa排名掉下来了，理论上这是周日的排名，还有更麻烦的事情，那个万能五笔设的265仍然霸占了首页，仍是不能把它搞掉，这显然是一个间谍软件。咱们一些中国人就是这么一副缺德性。

星期天，半天有多花和朋友的叙旧上

2005-06-05T08:03:00.000+08:00

晚上受猪猪的干扰太大了，一直睡不太好，因此早也容易醒。昨天晚上刷新了一晚home，不知有没有效果，这要过两天才看得出来。那部生活记录弄着弄着，变得仿佛成了成人小说似的，原来是如此花时间的。把qzys最后的部分整理完毕，没有发现有什么问题，但当把head.jsp修改后由于每个jsp都是包含它的，结果却是全网一下子变得特慢，大概是因为所有的模板都要重新编译一次的原因。

晚上到十二点近了，仍没有做到hzbbs中的最关键修改部分，如同昨天还是前天一样，这一部分不是小东西的，反正居居一两个小时肯定做不完，还是等到明天再做吧。

那个alexa排名掉了下来，是一万多一点。不过相比上一个星期，算是掉得少得多了。看来刷新还是有用的。

周六，继续做qzys，并对六四进行了记念

2005-06-04T08:51:00.000+08:00

晚上睡不好，早上早醒，这是一个不好的兆头，意味着开始进入精力衰期。原计划是想继续做昨天未做完的事情，但结果精力转换成博客整理，目的原来打算是要申请那个ads帐号的。其中的大部分时间是把旧的utf-8的文章到gb2312的博客里。不过，thechina的帐号域名很好，不太舍得扔掉。另外，又写一份六四记念文章，这种文章以前从来没有写过。前后花了三四个小时。

中午午饭后睡了大约两个小时，精神基本上恢复了，把博客的广告也再次地申请了一遍。下午和晚上的主要工作仍是围绕着qzys的贴子的整理，直到添加上签名并发布到服务器上。对于贴子内容中要显示作者的情况，既不能做到全部非规范化，也不可以一行行地读取数据库??数据库只怕是非down不可的。唯一的办法就是把签名搞成一个iframe，这样就可以大致异步，同时把列表项缩小一点，初步可以解决问题。论坛上的最新回复贴在最后，对于翻页很多的贴子来说，其实也不是一件好事。不过这种大量使用iframe的方式，一定是可以让网站的pageview上去的，我相信这也是许多网站看上去很高的原因。

晚上仍然未完全做好，明天还有用户签名，上载个人图片这些项目；特别还有发表贴子的统计，以及把科室转调回到对的科室和病上；这几个功能还是相当花时间的。

周五，强制性把论坛发布了，实际上并没有做完

2005-06-03T10:35:00.000+08:00

上午不管三七二十一上载了。对于我来说，远远没有完全做好，不过，其实推广方面的工作完全没有必要等我这里完美了才开始工作，我这里说完全OK实际上各人的标准是不一样的。不过，陈是不明白这个东西的，罢了，反正载上去，有问题他也是过很久才有发现的。况且，也未必称得上是问题。实际上我目前做的事情远远不仅仅是补充出那个会员功能，实际上还包括整个详细功能的全面细化和合理化，包括原来给扯掉的科室到专栏的功能，以及全面的转向静态化。

目前的求助专家是一点点地收正，所有的子页已经全部独立出来，除了编辑外。编辑的本子需要使用contains判断标签。独立出来的原因是由于论坛这东西花梢东西很多，不独立的话，主要功能没有问题，但花梢东西的添加就成了大工程了。

虽然全天基本上是围绕着qzys操作，力图首先让它基本完善起来，但实际上却是大量地进入到hzw和后台，包括把全部的专栏改成静态网页的形式。这步操作尽管很小心，但晚上仍然再次令系统进入内存溢出，不算非常严重，但仍是不得不重启。到20：00，仍有贴子组织、quanke未做，估量着份量并不轻的。需要先行做出contains判断标签，另外，后台也应该修整进入的路径，加块它的效率。

今天的alexa与昨天持平，一般说来应该是周四，我已经打开了home刷新，但象是效果不怎么样呢！今天是周末，继续保持刷新，看看效果如何。

到办公室花了一个下午的时间；申请GOOGLE给回绝了

2005-06-02T08:08:00.000+08:00

昨晚的休息很差，近来由于猪猪的影响，不但平时工作效率可用时间大大降低，而且晚上休息质量也大为下降。保姆的确是该炒的，素质低的人也没有办法跟她说道理。

今天在最简单的javascript上碰到难题了：无论如何都不能用javascript在菜单里重定位或者自动提交表单??尽管，目前还不算是一个大问题，但是一来原因不明，二来表明javascript对form的控制不可靠性。我估计可能是与div/layer中的javascript受限制有关系。要限制这种控制，可行性总是处于不可预计的状态。

一个最简单的tagfile再次失败，看来tagfile的价值小得很呢！早上做那个自动显示的页面还是值得的，如果不这样做，那么一个个砌也同样要花很多时间，重用性还很低。不过不太顺利，原因多多。收获是进一步了解了struts标签的使用方式，从迭代标签上看，确实比c要强大，理论上也可以代替我的 getter的大部分工作的。由于可以从javadoc中得到使用属性，所以缺乏文档的困难也大大减少了。当初做了一个display标签，由于涉及到的 html代码太多中途告废除，现在实际上已经重新做出来了，使用的方式要简单得多，这就是技术上的进步。

高岗抱怨会话丢失。但非常奇怪，我这里无论如何都无法重现。会话是会丢失的，不过如果访问过基础站点域名就可以得到保存。怎么会出现丢失不能恢复的情况呢？而且一直在基础域名上，如果仍是会话丢失，我也不知有什么办法了。在黄黄机上重复出了同样的错误，似乎是如果先访问过基域或www，再访问dep就会出这样的情况，而在firefox就一切如常。

退一步说，同样的情况，为什么从前没有明显地出现过呢？这仍然是欠解释的。其中的一个解释可以与基域名转换为www，以确保主服务器会话工作正常的原因？实验表明，的确是这个问题。看来，框架中带有一个刷新窗口，也别说没有用，尽管目前dep上没有什么影响。对于IE来说，一旦先进入低一级域名，那么所有高端域名就共用一个会话，而其他服务器那里，也就没有这个会话可以保持了，这就是原因。

昨天收到了ads的回复，给回绝是预料之中的，但总算有了回复。所以我打算本周对刚刚处理完的日志版本再次申请。拿一个帐号，对于了解有多少人浏览我的网站也是有好处的。昨天晚上对home进行了一晚的刷新。这不是应对排名下降，也是为了确认次级域名是否会纳入排名统计之中。今天晚上更新的alexa重新回到6500，从时间上看，应该是指周三的流量。我还没有打开自动刷新。

下午回公司花了我实际上是接近于一个下午，也是聪明下午才回去，这样说来，我可以在周一如无约定则迟至中午才露面，反正也一样可以做事。李继看来是个废物，什么都是是是是，但实际上要做的事情连最简单的SEO都一件没有做下来。废物！今天再见了一个，水平与杨应该是差不多的，只在于多干了几年。不过从写程序来说，有一定年纪的大专生比刚毕业的本科生为佳。

本来打算连夜搞定论坛，不过项目太多，实际上明天也不知能不能搞定呢！所以今天熬是没有意思的，何况昨晚的休息就已经是不好的。除了修整整个贴子外，更麻烦的还需要检查用户的当前登录状态。所以如果能够明天完全完成，就真是很不错的。

中断专家主页的工作转向论坛

2005-06-01T09:35:00.000+08:00

今天休息不算太好，老婆打算既然保姆已经不做了，那么就不让飞飞再在家里住下去，本来也是题中之意，对此飞飞也不见得很争气，对此我也是爱莫能助，所谓天阴就会屋漏雨，实在是自然之事。

本来今天的计划是继续把专家自主页的模块完成它，但是一大早chase就打了个电话过来催着要改那个首页，如果光是首页也还罢了，麻烦的是要随之修改论坛的发贴方式，这等同于是要把论坛修改的计划提前并用包括了注册项目，这样就不少了。不过chase的习惯是每次总是这样紧那样的紧地把东西塞进来，然后过几天就是，原来那样东西过了多久没有完成啊，我在等着啦之类的话。这还不包括昨天垃圾机的部分。

注册那里要分开非专业用户和专业用户两种，这是一个多次出现有选择显示的form，可以使用opflow完成。不过，仍然是继续原来订下的原则：仍不清楚opflow必然可用的地方是什么，所以可以使用其他办法的，就使用其他办法。

ps: tagfile中如果修改了属性方法，就算删除了也没有用，必须删除并重启从有用。这显然是tagfile服务器处理的一个 bug。tagfile有着严重的缺陷，不能代替simpletagsupport, 除非含有大量的html要输出，否则使用simpletagsupport更为优越。

ps:今天流量再退一千多位，看来，这会与内部使用alexa的人减少有莫大的关系。

ps: 黄黄看来一肚子火，要求阿姨回来把东西拿走，大概也是想打个招呼，谁知阿姨干脆不接电话；结果一肚子火撒到了飞飞身上，不管飞飞是一个穷蛋，要求她立刻把欠下的电话费全部补清??看来黄黄是压根不指望能拿回借出去的1500元了??这又一次证明，钱借给穷人是没有回头的：其实是救济，那倒不如直接明确就是救济算了。飞飞也是一肚子火离开了，尽管她有点无辜，不过既然她摊上这样一个母亲，加上自已也不太懂事，也不能完全算是无辜的。对我来说，粘上一脱扔不开的可能性是没有了，但再抚摸欣赏飞儿的胴体的可能性也算是没有了。??横竖飞儿也是打算搬出来住的，所以也不算是什么损失了。

会员由于表太大了，而且是带有通行证的概念，分成几个显示的话会太复杂，看来需要一个会员显示页面，无论是前台后台都是如此。而修改的部分，只是极少部分。目前dao.xml扩展得太大了，要有效使用，看来要学struts，可以分成几个xml，换言之，把它扔进一个目录中。

实际上，今天的工作除了修整会员管理，还包括修整系统后台，这里由于长时间只有一两个用，一直没有真正完整处理过。但现在会员那里显得相当必要了。

规则专家主页howtodo

2005-05-31T11:22:00.000+08:00

早上，把猪猪送到邻居家照顾起来，这下子可以全神贯注地开始工作了。工作的一部分内容就是整理自已的几个博客，按照既定原则，分门别类地申请不同的博客栏目，一方面是方便介时正式开始网络广告，二来，就算是个人整理起一个网站，也可以把这些博客作为该网站的周边支持。这项事情相对纷繁，占了一定的时间，特别是那个blogchina，目前仍是主要使用的博客，但是它的后台设置怪诞难寻，无聊之极。就使用的方便明晰来说，blogger的确是值得仿效的。

眼前要做的专家主页，其实与博客颇有相同之处，本质上就是一个博客，与目前已经做好的黄页也颇有相同之处。将它分成几个东西是不明智的，事实上，在大部分方面，它们都是功能相同的，仅在于功能的多寡上。因此，它们之间必然存在着相互的联系，也必然存在着（业务上的）冲突，如果不加以理顺的话。

专家黄页是一个仿效locateAdoc.com和medscape的，它本身就是一门完整的网上生意。我不明白的是一些拍挡思路会如斯狭隘，仅仅把黄页看作是一个电话薄，如果是这样，那么一开始说的locateAdoc的方向就是错了，从另一个方面看，开发人员的劳动也没有得到尊重，退一万步来说，目前的投资者一知道网站经营者是如此理解水平的话，只怕是立刻就会信心全失的。因此，尽管拍档们没有理解，但是基于一个完整的黄页的经营，仍会在网上渐次推开。专家黄页目前是不收钱的，也没有更详细的东西。

博客是免费的，它与专家黄页的最大区别就在于可以发表文章，并且可以发私有广告。这个目的是我的一个假设：对于博客而言，收钱没有玩！而分散的博客希望由博客供应商组织广告，是非常困难的，倒不如让博客自已管理广告，博客供应商帮助他们玩自已的广告。如果博客们自已能够从博客中赚到钱，还怕不能让他们为博客的存在支付一点钱吗？

由于目前服务器资源有限，所以我也不打算无偿无限制地提供专家博客，对于专家博客，从拥有到维持，我打算提供一定的条件，条件也不算苛刻，象要有定期的更新，以及需要在论坛回答一些回题等等，就当前而言，博客的对象是各个科室的研究生和实习生群；反而是专家本身，估计没有多少兴趣在博客上舞的。我倾向于使用象blogger.com的博客类型：不分类，但是可以拥有多个博客主题。同进允许通过友情连接把多个博客组织起来。

博客当然要比专家黄页要丰富点，但是又必须比专家主页要弱。专家主页是目前预计要收费的项目，那么它有什么栏目呢？可以认为，凡是博客有的，它都是应该有的。从继承性来说，它可以认为是博客的集合。而除此以外，要比博客更强，目前可能提供的还有论坛。

下午北京抱怨垃圾网站出了问题，我一查，的确如此，但是就冲什么投诉的威胁，我决定放慢三拍去理它??本来呢，就没有收他们的钱，还拿老板来威胁我？谁怕谁啊？我检查了一下，看清楚总是好的：这个网站是琼依照我的老网站的做法做的，不过得其形不得其神，错漏百出。而就眼前这个错误就奇怪，那是因为少了个方法，但是编译又过关，显然是使用了不知什么目录的另一个类所致的错误。最好不是责任感而是好奇心让我去解决这个问题：实际上错误不复杂，就是没有办法找到它引用的那个类??我怀疑是服务器对servlet/bean有缓冲一类，但是我已经把work目录中的部分删除了；自然，不能全删除，否则dep会非常慢的。最后，我失去了耐心，把目录换了后顺便改成了html，解决了这个问题。看在它原来的页面已经有一定的pr,我没有把所有东西都换过来。

由于目前是打算做各个相当于个人网站的网页，那么是否可以提供它本身的登录呢？它与主网的帐号又是什么关系呢？……看来，对于单位网站这个帐号还是有点价值，而对于个人网页的价值就完全没有。因此，个人网页不应该考虑登录，甚至于论坛也不见得必须，反而是图片和自录网页显得更为有价值。目前的的状态是黄页已成，开发动态个人网站；同时要考虑为博客预留空间。

下面的问题是，目前的网站文章和未来的博客文章，是否应该放在同一个表中，还是应该分割进不同的表中？分割的好处是可以减少表的大小，加快查询的速度；而使用同一个表的好处是可以统一进行查询。说到这里又顺便说一说本网的全文检索，它与表无关，但同样涉及到有多少个索引文件的问题。对于互联网来说可以通过反向链接进行计算，而对于单一网站来说，反向连接没有现实的意义，唯独点击数有实际的意义。目前我觉得数据库的查询似乎不是一个瓶颈。何况我有提高效能的保留手段，所以还是集中在一起吧。各种类型的文章合并在一起后，看来有必要用一个特别的键值进行识别。

这几天的alexa变行基本上是周六8000多，周日10000强，周一28000，周二17000，周三8000多；从这个排名看来，是推迟两天但不是 48小时。另外，没有看到明显的刷新的效果，而周一的下跌显然与上周五的中断有关系。目前平均排名8000有可能与自动刷新减少了一个窗口有很大的关系。

原说今天基本完成专家主页，看来是不可能了，睡觉。飞儿晚上回来了，对于她妈被炒，看来气鼓鼓的，看来是不会再和我调情了。

5.30，一天到晚几乎什么也干不了

2005-05-30T20:36:00.000+08:00

不出所料，今天仍要花了一整天开会??其实是浪费时间，到晚上仍没有能够恢复精力，本身晚上又太疲劳了一点，真是一点也不想干了，只想睡觉，可是女儿却精神百倍地呼呼叫叫，就是没有机会静静地躺一躺。
同日申请的那个google ads还是没有回音，要观察一下，到底是什么因素作怪。从一些迹象看，申请一个帐号好象还不是那么容易的，还需要某种的档次。不过不要紧，其实我目前的博客内容的整理并没有完成甚至没有真正的开始；但如果现在给我一个google ads帐号，或者我会更有目的性的。
五月份的工作的确是严重受到了保姆贻工的影响，这是一点点感觉到的。昨晚，一方面我的确是欠眠，（这也是间接和保姆有关，晚上照顾孩子是她的责任，现在要我们两夫妻照顾，自然影响了休息），二来的确是小猪呱呱叫个不停，(这孩子目前处于这样的时期：抱着她吧，左扭右扭，放下她吧，来个马拉松式的大哭闹；还一会儿吐一会儿啃地板的，不能不管)，三来老婆的大脑也不算太发达，一边说累啊忙啊，一边浪费时间在不必要的地方??大大的全自动洗术机摆着，她却把自已的衣服和猪猪的衣服一件件手洗，布的而已，也不是什么高档晚礼服……反正，整个晚上我没有机会工作，唯一可得的，就是早了两个小时上床，但其中一个半小时仍是拍着翻来滚去哭哭笑笑的小猪，根本没有机会睡着觉。
所以老婆决定把保姆立刻开掉我是不觉意外的，平心而论，如此继续下去也的确不是一件事。唯一有所挂念就是保姆也住在我这里的女儿，飞儿。飞儿不是一个懂事的女孩，俗语说穷人孩子早当家，她却是穷人的孩子迟懂事，已经成人了，仍是不知世间艰辛，显然，这与她文盲的母亲的素质有直接的关系。我有点关切她，是因为她是又一个对我原则上无隐私的女孩。这体现了一种信赖。我对她的身体并无邪念，事实上如果我愿意，完全可以把她扯上床占有她估计仍是处女的自体，但是我不会这样做的。我enjoyed的，仅仅是享受着通常属于女性绝对隐私的可以任意向我开放的那种密切的感觉；但我并不是愿意越轨的人。
今天晚上休息好了，那么白天估计可以干许多事，因为猪猪暂时被寄托在一位邻居家照顾。

今天基本上没有进行工作

2005-05-29T22:10:00.000+08:00

今天的结过很简单：上午抱女儿到她伯伯那里，然后让她伯伯一家玩，熟悉一下，然后我自已和老婆去看《星球大战》，并在外面用了午餐，然后把女儿接回家里，已经相当疲劳了；事实上近段时间一直都觉得疲苏，令工作效率上不去。没有时间恢复是主要的原因，咳嗽影响睡眠；然后是保姆总想办少女，一天到晚抛下我的女儿去玩跳舞（她老已经近六十岁了），弄得我和老婆常常被女儿的哭闹中止工作，效率低下；冲这条，也的确有必要考虑换人了。另外，近段开始与女儿一起睡了，女儿常常半夜哭闹，弄得俺夫妻俩晚上都睡不好。
下午不敢什么理由，我都把女儿推给老婆带一带，一觉睡到七点钟，也就两个小时吧。但即使是这样，仍然是给女儿莫名其妙的哭声弄醒了。晚饭后，仍是让女儿拖了一个小时左右。然后才开始工作。而工作的开始就是处理那个博客的问题。与网站相关的问题，始自22:38。

我想，老婆的不能让女儿哭闹的标准定得太高了，以后我不能理她，女儿只要没病没痛，要找人玩的小哭小闹，有心则管无心就让她哭一会，哭累了就不哭了，或者就睡了。

今天中止的地方，仍是要写东西，关于招聘和短信的部分，仍然没有想清楚的。而可预见地，明天又是开会，没有时间展开工作的。

目前blogspot中文仍然存在问题

2005-05-29T21:24:00.000+08:00

blogspot除英语外，默认使用的是utf-8编码；对于英语，这没有问题，IE会适应的，但对于中文就不然了，事实上，如果不是浏览者手工设定编码的话，utf-8编码的网页显示的就是一遍空白！问题就在于，全中国人有多少分之一的浏览者知道网页编码是什么回事吗？
这个问题我以前没有注意，因为我使用的是firefox，（严格地说也谈不上“以前”，我是昨天才知道在中国大陆也是可以看到blogspot上的站点的）,默认状态下的utf-8，如果设回到gb2312，原来发布的文章，就全部变成了乱码。
问题出在blogspot的发布机制。我一直留意到blogger.com的“发布”这个用例操作，不太明白它是什么意思。直到我看了它的网页源代码，事情就开始清楚了，它使用的估计是一个与google相关的索引文件另加一个与cocoon相似的xml发布机制，发布的意思就是把文章转成xml存档，这样做的好处是可以根据不同的xslt转换成html/pdf/xml/rss文件。由于转换是一致的，对于所有网页都适用，也就不需要每一个转换写程序 ??有它的合理性??但也有它的不合理性，事实上现在它对于中国读者，包括绝大部分非英语读者，我看，都是不可见的，那怕中国网安没有封闭它！

它的日志文章显然是独立放置，并且在读取时才由某一个读写器从xml存档中再读回来，这里显然存在一个逻辑错误，就是读回来的xml的encoding有冲突，??这个案例说明，xml除了让软件业有了升级的炒作题材，其实也不见得适用于所有的情况，还是一句老话：软件无所谓先进，只有合用不合用。就 blogger.com来说，尽管它是全球博客第一，到目前为止我还是没有看出它的完全基于xml的解决方案有什么必要性，带来了什么特殊的效果，因为，我实在看不到它有rss功能提供！

这也可以解释b logger.com的缺陷??文章缺乏分类功能，以及文章显示缺乏设置功能??它甚至不能选择设置只显示文章条目于第一页！当然，如果它一定要提供这个功能是还是可以做到的，但是在如此数量的情况下，修改一个基本结构的工作量和成本投入不是普通项目可以比的，而完全基于 xml的解决方案，在扩展性上是不是那么乐观仍是一个未知数，至少，作为一种范式，没有多少可以参照的项目经验可用。

这就形成了这样的一个问题。如果用户写博客本身只是涂鸦，其实有点东西下笔就可以了，但如果象blogger.com那样希望与google的ads结合产生效益，为博客指出一条赢利之路的话，那么，就不太美妙了。因为，这样条件的博客，其实是基本上没有希望发挥博客内容的吸引力潜力的。就本人而言，如果打算组织自已的可以发布动态广告的博客群，blogger.com就不可能是一个首选，除了它是中国网安的重点封锁对象外，它的内在的技术逻辑错误，恐怕是更致命的因素。

5.27/5.28, 原来这个博客是给网警屏蔽了

2005-05-28T11:29:00.000+08:00

说来也算是有趣，今天本人才第一次看到这个博客的效果，而此前，都是把它当成一个封闭的博客使用。在使用如斯久之后，发现国内不能访问这个博客，但自从发现这是世界上最大的一个博客以后，就一直怀疑，它是给国内的网警封掉了；但使用部分代理服务器后仍然访问不了，也不能确定是国内不能访问，还是它本来就没能对中国大陆的受众开放。

现在看来，当初不能访问除了网警封闭以外，还有一个原因就是代理服务器有时用的也是国内的；而另一些时侯，是根本国内外的网站都全部不能访问；象昨天527全天，本地与海外的网上访问全部中止。鉴于这个博客是全球最大的博客，所以从这时侯起，也就开始考虑那个ads了。

我有许多个博客，部分已经达到了PR4，不过在此以前，一直没有意识到可以发布广告；因此，各个博客的内容没有进行有规划的整理，在主题欠缺的情况下，其实也是不太可能作有效的广告宣传的。因此，在完全整理好我的博客前，其实也不太急于登记广告发布。事实上，连上今天的三次，我已经是第四次准备登录然后撤销，因为我实在想不出该弄到什么样的博客。

最后，我把这个博客作为第一个发布广告申请的对象，不是因为它特别能吸引人，而是因为它是目前最清晰的一个，而且估计可以发布广告。而csdn和blogchina呢，前者不知道可以在什么地方发布这个广告，而后者，内容太庞杂，其实也的确不便于发布广告。

我的中文能力还是有自信的，只要有一条路是通的，我相信一定会走得比别人好。我目前不但拥有组织博客的能力，事实上还拥有建立复杂站点自已用的能力。所以不必急于弄一些不定能拥有广告点击的项目也是好的，的确不用急。如果这个ads计划是可行的，不必急在一时，否则急也没有现实的收入。何况我现在忙得很。

目前的blogger也有很大的缺陷，这个博客不能划分文章类型，这样对于建立一个完整的技术站点是颇嫌不足的。它似乎适于建立象与敏感性相关比较高的站点内容，而真正敏感的内容呢？最好是用另一个ID发布。对于技术性内容，不同类型的技术文章混杂在一起，其实价值也是有限的。这个博客, blogger.com的设想，其实就是使用不同的博客作为文章分类，然后再分别发布。所以，技术方面仍需要再作分类。

但进一步的处理，需要等待拿到ads帐号后才能继续。现在仍不太清楚那些个帐号到底是如何用的，尽管在公司的帐号上接触过。

点击排名和会话问题

2005-05-28T11:27:00.000+08:00

alexa的统计是迟两天的，这样今天后到的排名，就应该是周四的排名；但为什么会突然掉了下来？有一个解释，也许我清除了为第一次保持会话的自动刷新后，就令排名下来了。实际上，到目前尽管我没能专门地作个假，但也没有搞得非常清楚，排名中由于自已人的关系，以及系统保持的关系（部分网页通过刷新保持会话存在）的影响有多大？毫无疑问，也无法判断象39网为什么能排到那么高，我是严重怀疑其中有假的；另一个因素是，目前内部统计中有多少是机器人的所为？由于jsp得不到ua，所以这也是不清楚的，除非，使用apache检测，然后通过qsa添加条件地把它识别出来，另一个笨办法就是使用手工把搜索引警的IP加入到“黑名单”中，这样就可以了解到有多少点击实际上是搜索引擎所为??不过，这都是后话了。

在使用了重写后，使用二级域名的会话丢失大幅减少了，但今天仍是再次出现，不过没有能够重现，仍不清楚它出现的充分条件是什么。这在情况下使用url重写也不是个办法，因为在初始情况下根本就不会带有会话重写的信息。看来这的确是一个难题。

底层出现错误，是集合型式出现了冲突

2005-05-26T12:11:00.000+08:00

今天升级工作完成后，整整花了一天整理新发现的bug，严格地说这些bug与升级的关系不算太大，更多的是顺路的整理，象全科和耳鼻科。但其中一项花了我差不多一个下午的工夫，四个小时，就是roles域更新不了。最后检查下来，这是由于这是一个集合值，所以在添加时总是把空值写进去而不是记录直接的值。这是设想中的集合域的特点。目前添加的问题已经解决，而修改的问题仍没有完全解决。主要仍是在于修改时存在着原值和新值两个概念。所以这个修改除非特别扩展这类方法，否则需要是针对集合属性操作，而不是对串行后的属性操作。这是最需要注意的地方。详细的我还没有想得很清楚，总是觉得相应地form.style等处也要有所修改。

王傻呆了几天弄出一个新首页草案??只能是草案。我不知道高的审美观是如何的，反正我觉得那东西特难看，如果是这样，我觉得倒不如现在的首页来得好看一点了。我觉得高是在拍chase的马屁，她一直都是这样的。而chase对这个问题，其实是没有什么idear的。
王呢，实在是一个活宝，我已经可以肯定，他是帮不了公司的，我可以看出它存在的意义是由于chase不懂广告所以想找一条拐棍，但偏偏在一个相对新的行业是找不得拐棍，我也试过，最终确认这种方法是白费劲。我具备学习的能力而chase没有。所以chase想找王做广告，几乎可以肯定是不可能成功的。

优先先处理底层，日期记录应与样式分离，会话丢失仍成问题

2005-05-25T12:10:00.000+08:00

今天上午围绕着论坛和lister不应带有base输出进行修改。这是应该优先的，原因在于base输出如同前一期的日期表现形式一样，应该在表达层选择，此前没有发现需要表达的东西，形成今天这个格局也是由于先前没有足够的工具；现在，把它改过来从结构上是合理的，从稳定性上看，可以令lister显得更稳定。

但是pageindex就不太可能直接转化为html，关键在于它需要request.geturi,这样的话形式上的不同不会反映到它拿的界面的不同。强行修改不但牵涉面甚广，而且效率不见得高。看来，如果的确需要转变成html翻页，还是从已经输出的html入手，把jsp的形式转换成相应的html 形式，这样涉及到的地方会相应地少得多。不过翻页共用的部分也就此作废了。

对此，也许搞成archive形式按日期安排，更有现实性的意义，涉及到的更改面也最少。

论坛需要修改的部分甚多，包括分别提问方式，医生签名，静态化等等，这一部分需要特别抽取时间进行优化。同时还包括对现有会员的再分类，弹出窗口要求填写资料等；是多个小用例的修改集合，应该视为一个独立的升级项目。

晚上打算开始广告部分，但最终时间花在处理二级域名上，本来以为只是一个小小的操作，结果却演变成两三个小时的奋战。原打算使用重写URL的办法，结果发现没有结果，只好使用网页转向的办法，实际上这样也没有什么不好的，反而可以保留有进一步作记录的空间。明天升级时还真要注意别忘了把.htaccess 也一并修改。

另外今天dep上在内存用光后发现linux可以自动关闭这个应用，而清理内存的比例也让人惊奇，如果是这样，那么在超出内存容量后……仍是不妥，它把tomcat关掉了。

522,523,524

2005-05-24T12:10:00.000+08:00

5.22周日不知干了什么，记不得了，好象是效率不算太高，精神不算太好，不过也没有闲着，好象是修改了会员登录类型，以及相应的form功能。

5.23 周一，本应睡得还可以，但这几天都是这样，睡眠已经很注意了，但精神就是好不起来，白天开会，象是扫盲，这种会对我来说更象是浪费时间。时间花了一整天，晚上也没有多少心机搞事情了，精神特别不佳，留下的要评论的文章挺多的，看来也不知什么时侯可以把它们统统评完呢;

5.24今天，精神仍是不好，另外求职与招聘以及广告等还没有完全理清，精神不好再没有理清，就特想睡觉。结果前半段一直是休息，只有脑袋中空明中运转，直至下午，精神好了，好象也想清楚了。下午和初晚的主要时间，用于收拾如论坛的谬误。不过，她们说的转到其他栏目，我没有发现。包括晚上，主要也是在规划广告服务器，包括规则它的业务使用方式。

精神不佳，主要工作在会员修改

2005-05-21T12:09:00.000+08:00

今天本应精神不错，其实是精神不佳。会员类型添加实际工作量不大，但完成一个牵涉的面还是挺广的，花去一天的时间实属正常；而所作的修改仍然导致万维变慢，估计与其中的某几个公共页面需要重新编译有关系。看来，对于使用work更替的网站，还是尽可能使用work更替为妙。member目前也就是这样了，进一步实际上是一个会员资格审计和使用的步步升级，这涉及到所有与会员权限相关的项目。所以还是到具体环节再说吧。

下面是进一步去搞那个招聘等；先把栏目都建起来，然后搞那个消息短信系统，让东西跑起来。

520，开始修改会员登录结构

2005-05-20T12:09:00.000+08:00

从观察中的浏览数量看到，昨天24小时的浏览人数不算多，大约只有15000左右，这个量是比较少的，换言之，没有非常大的进步。???医生实际上广州地区的热情已经在下降了，象那个drxyz，长期以来我已经没有看到她在操作了。需要找个机会以某种方式让chase产生紧迫感。

现在我可以大致总结出类似laura这种情况的心理，（事实上在其他人身上我也见过许多这样的情况），不愿付出艰苦的劳动去掌握足够的职业技能，又怕失去工作中的地位（那怕其实并不高），缺乏相像力，不愿承担决策的风险，却希望把握某个关节点来获得血酬的资格。虽然是中国最通常的职业处事方式之一，却也的确让人讨厌。

今天的任务是令member可以分类使用，但通行证是肯定的，这样就存在着

公司缺乏技术传统给我带来巨大的困扰，我是在作出自我牺牲

2005-05-19T12:08:00.000+08:00

chase对招新的技术员操太多的心，似乎是隐含着更深的意思。事实上，这家公司缺乏技术传统既给我提供了机会，也令我时时受到困扰。我相信目前公司内几乎所有人，都缺乏对我真正实力水平的真实体验，所谓不看到别人比不上我，不知道我有多强。反过来，把一个拿高工资的人拿来干不了活然后让他滚蛋，反而对于提供我的收入水平有积极意义。事实上我的用人经验告诉我，当然这是从做老板的角度，大专的写程序比本科的强。从节约成本的角度上看这是对的，但当前的角度上看，反而对我是一个制约；既然如此，我就招个所谓的高素质高成本的，不妨让他跟着laura干，直到他干不下去为止；诱导他和larua争，省点laura拿着现在的角色给我添麻烦。

目前的计数可能受到以下因素的影响：自已的访问；搜索引擎的访问；系统自动重复的访问等。
目前象黄页在后台还需要一些管理工作，不过这些工作不是太急的，在前台逻辑未完全确定以前做的可能都是多余的。弹出窗口归并需要一些时间，好象也不是太急的样子。还是先搞科室的归并吧。

采用大jsp看来也受到了制约，jsp的大小是受到限制的。此路不通;这样，包括上午做的对路径的重写的研究就完全失效。对路径的重写也是奇怪，明明是开始做对了，没有显示出结果。改了无关重要的地方，反而有反应了。可能是apache的一些缓存bug一类。这样那个发布困难的问题仍将存在的。（使用 asp的站点有很大的限度，blog.edu.cn很大程度上体现了学院派的程序水平，这个网站使用asp，而性能可见性地直线下降，可见asp是一个何等的臭货）,事实上，jsp也是臭货，网站大到一定程度后，jsp所体现的发布困难和大小限制，就充分说明它的局限性了。

由于大小受限制，目前唯一的办法似乎就是先生成work目录同时上载了。而对于hzbbs/ysbbs/qzys来说，这三者的条件都是非常相似的；当初把它当成是一个服务，并没有错，只是它们其实并不是服务，只是论坛一部，所以目前存在着一种可能性：把它们抽下来；归并为一个论坛。从初步的尝试看是可行的，不过最好是在广告等完成后，把主要的include归并到tagfile以后。

对于tagfile的使用，看来是要慎重，在能够使用 include的地方，原则上不用tagfile.另一个问题似乎是应该注意的，那就是用户图片的使用问题；目前没有用户图片的限制性措施，如果用户更换图片，将会形成图片的积累，事实上，这样迟早会形成一个大问题，而且无法加以识别，什么图片是已经被调用的，什么是没有的，目前也没有办法知道。

随着用户有可以上载图片，看来需要开发一个图片的管理功能了。图片管理清理需要一个清理功能，难以预先了解它的调用点，因此，唯一办法就是开发机器人进行整理；另外，可以提供用户图片的统计功能，以及针对用户目录的图片清除功能等。这是一个大工程。

今天大部分时间是在迟疑思索中，以确定下一步应该从那里下手，顺便把自已的一些博客加以维护，花的时间不算多。而办公事务性的事情也占了不少的时间，在白天总有三分一左右。

迟疑，总是迟疑，也不奇怪，这既关系到后面的基本模式，又涉及到已有工作的重新进行，同时可选的方式不止一个，这个关节上小心一点，也不为过份。对于tags/include的取舍，看来已经使用tags的，就不必改过来了；继续向前吧。

我现在对于laura是越来越反感，原因在于她不学技术，却偏要对技术内容指手划脚，反感二是她利用chase的无知搞一些政治小动作。其中也夹杂着我对这家公司成员对于技术上的无知和对技术人员专业能力缺乏尊重的反感。所以对于她的所谓的需求，除非我自已是百分百同意，否则根本不想搭理的。

事实上，目前公司运转最大的动力在我这里，当然蔡生的投资也应该计算在内，但我令这个公司可以用一般是百分一的投资完成最复杂的网站功能，这是其他公司和网站不可能做到的。

遭遇发布难的问题，紧急处理

2005-05-19T12:06:00.000+08:00

发布慢的问题再次出现，并且观察到下面似乎是对tagfile的循环死锁。这下子陷入了进退两难的困境，完全抛弃tagfile有点舍不得，何况也未必就是tagfile的问题。因为在此前虽然发布困难没有这么严重也不是没有出现过。关键问题还是jsp非顶级模板的这个模式的问题，显然，到目前为止，结论已经是比较清晰的：在格局安排上，少模板复杂的程序比多页面简单程序要划算。我最早的选择是对的jsp网站理想情况下就应该是一个网页。

昨晚不但因为这个发布困难的问题也牵挂，而且，女儿调皮总把我弄醒也是一个原因，反正整晚几乎没有真正休息过。上午搞了个花招才算把程序发布上去，运行起来，但已经让我有点担惊受怕。那个运行程序的方法下次可以再次采用；虽然花了一两刻钟，让桌面死机两次。但较之发布起起不来的浪费劲，还是花算的。而程序本身，就要向少而大的模板方向转化了。首先就是把各个科室部分清理出来。这里的量显得最大。

蔡生与风险基金的接触给了他信心，这是好事。但我们目前的实际点击量可能并没有真的那么高，实际上是使用alexa用得好。另外，网站的逻辑象 redirect这类，相信也会令点击的统计数量增加。当然，象三九的点击率，我看就根本不可能真正的是几百之数，一定有内在的其他原因；同样包括 fx120。这个网站目前真正的价值在我的技术含量，象这样的网站包括开发的维护，一年一百万是最起码的，而现在只有十万以下，这个成本，实际上网站本身光是卖google广告都可以维持一定的收入了。我自已其实是不用太担心的，只要有几个月的缓冲，光这个网站就可以提供很强有力的缓冲支持了。我的特点是路子不多，但拿到路子的利用效率都是极高的。

网站的另一个支撑是chase与医生的合约。不过这里存在着很大的变数：医生，实际的投入热情是多少？包括在熟悉网络后对网站的热情是多少？chase可能对此没有准确的估计，而laura则没有这个智力和心思进行估计（或者是事实上不太关心）；我的估计是如果目前不开始加以强化，相信很快他们的热情就会消退。为上我要以我自已为主的一个重要原因，能够看到未来，这是我最大的优点。自然，蔡生本身的兴趣和信心是最重要的支持因素。

其他人在他们她们的本职工作以外的作用是无关重要的。象laura，真正的价值是chase的拐棍，对我是没有必要性的，我没有必要为她的业务能力不足而委屈自已，从而承担额外的负担和成本。

下午出了几份实际上是总结，提醒，包括博客上的那一份总结性文章；少改几个BUG。晚上太累了，先睡了两个小时，再出总结，一天就完全过去了。这两天基本上可以认为是在唯护工作上花费时间。

jsp的确是一个技术性的失误

2005-05-18T12:06:00.000+08:00

因为SUN在java.web上的取向采用了向非专业人员倾斜的策略，而丢弃了java语言本身面向抽象对象的特点，反而在 presentationLayer上模仿由整个操作系统控件支持的简单的asp脚本效果；十足的弱智行为。因此写了一份批评文章选择jsp而不是servlet作为BS前台主流方案是JAVA的战略性方向错误。看来，没有骂错！当进一步尝试采用jsp2.0的其他“新”特性时，进一步发现jsp的发展策略已经达到了极限；在较大的工程中采用jsp技术，一定要有相应的策略技巧，否则应用程序甚至面临无法发布的困境??在开发和测试环境似乎是OK的，但一发布就无法达到平稳运行（所有jsp已经自动编译成 servlet)的程度。无法有点夸张，但让服务器down几十次过几天才算完成是有可能出现的，取决于你的系统有多大，concurrent有多少。
在几年前开始接触jsp时，一位开发人员非常兴奋地说：“jsp真方便，不用写class了，把代码写到jsp里，一刷新就出结果了”。时人也认为这是 java技术的伟大进步。本人却是不以为然，相反，我认为这是sun公司的那位白痴头头主导的一场重大退步??把java降格为脚本语言了??事实上后来连名称也是如此:javalet。实际上对于程序员来说，javac并不是一个困难，就本人来说，甚至50%以上的程序是自已写的调用 System.compile方法自动按预设定完成编写编译和发布的程序，SUN要做的事情很多，没有必要花精力在这些地方拍马屁。
这种奉迎初级程序员的方法似乎在开发简单程序时的确是方便了，但付出了在发布、和维护上的重大代价；以后，SUN的java社团在这条方向目的混乱的路上似乎是渐行渐远，仿佛是一条不归路了。为了克服jsp中被降格为脚本的java所带来的界面混乱，sun先是开发了一套bean的使用方式；这套今天看来简单至极的初级反射工具并不能把主要的逻辑方法有效地组织起来；随后，sun再次开发了标签技术。应该说，这是SUN在jsp发展路上意义最重大之一的突破，看来有可能把javalet在被强行请进html中以后再强行把它驱逐出去了。
但是，现在我发现它的问题仍是大大的。尽管就java技术圈内，笔者是最不感冒jsp的一类，但实际上，对于jsp技术的采用深度和广度，相信却比绝大部分jsp的绝对fans要深得多广得多。基本上是所有现存的技术已经试用过，并在实际中应用过了。如果不是把亲身感受过它的开发中的优点，笔者是不会对一样技术加以评论的，象asp，笔者几年前开发过几万行的程序，几年没有碰了，尽管印象比jsp差得多，但近来没有碰，就不便加以评价了。也正是由于用得深，用得新，所以发现的问题才觉得特别多。按一般经验，此山望着彼山高，真要用到其他解决方案时，只怕也同样会有火冒三丈的时侯。
写<选择jsp而不是servlet作为BS前台主流方案是JAVA的战略性方向错误> 最恼火的是因为jsp的确难以形成一个可复用的顶级模板，这样就不得不使用不同的jsp带公共的逻辑。（用惯servlet后总是对servlet可以作为一个公共模板，大大节约了代码量怀念非常??struts中的ActionSevlet就可以看作是这样的模板，从中可以看出这种模板的作用）。最终的办法是使用一个自动发布jsp(生成jsp)的程序把基本模板中的十来个jsp文件更替变量和模块，发布到逻辑相似的各个子应用，如科室、子公司栏目中；这样开发和维护工作就集中到这十几个文件和调用的所有class/bean/entity中；工作量毕竟是可以控制了。自动发布的工具好处是痛快，哗拉哗拉就完成了几十上百个目录中的jsp的编写，十几秒吧；坏处是不知不觉中形成了近千个的复杂的jsp文件；几一个连锁单位一个目录，目录下有子目录，有前台有后台；这样百乘千，就为后来的大问题打下了伏笔。
另一个伏笔是jsp中对标签更改的处理。jsp2.0中对标签的处理方式不知是由于一个什么样的bug

事情是从上个月开始，总是在开发环境

发布慢，等同于中断一到两个小时，多次溢出

2005-05-17T12:05:00.000+08:00

昨天试过一次，今天又试过一次了，发布后启动是极慢的。后来把部分c:改成logic逻辑，好象就全部通过了编译了。感觉似乎是c中的uri的原因，但细想之下，似乎也不完全。因为有另外两个原因可能与此相关：其一，在此前我把某些个科室隐藏起来，只编译xnk??也许，这样就屏蔽了其他呼叫，从而令其中一个完成了编译，包括大部分主要内容，这样后面的就只编译相应的部分。至于另一个可能的原因：tagfile初看也是很有可能的，但后来的表现是否定了它的可能性。

其次，仍然保留着的大量c段也似乎并不完全支持uri连接论。具体如何，看来还需要再作实验，但我目前显然是可以把uri换成死的tld连接的。这条是需要搞清楚的，不然不明不白放上去就动弹不了，就实在是一件大问题了。重新再来，你说它不行吗？它现在跑得挺快的。那么问题何在呢？为何会out of Memory呢？这下子我倒是麻烦了！如果说明那不是原因，那就是说原因没有找到，情况会随时重复出现。以目前这个速度是绝对谈不上慢的。

现在只能是死马当成活马医，先把命名空间定为死的tld……今天晚上全搞完了。但更新上去后台仍然出了不少问题，主要就是那个归并到index时的ent缺失问题。

tagfile只适合于简单的代码型集合

2005-05-15T12:04:00.000+08:00

后记：tagfile不能代替gimpletagsupport的工作，而且一旦修改，重写编译对系统的性能压力很大，不宜大规模使用。

tagfile那里的确可以完成Simpletagsupport的几乎全部工作，并加以了一定的识别扩展。但问题仍然是存在的，象variable就很不可靠，该输出的输不出来。我想，这仍然是pageContext/jspContext在处理上的混乱造成的。

看来升级后慢，也不见得就是由于程序有问题，而是升级后重新编译的确是一个非常冗长的工夫。看来，应该是在前一晚提交，这样，有可能让搜索引擎帮忙。不过上一次溢出可能也是这样的原因：由于搜索引擎太频繁地诱发重新的编译，导致虚拟机的内存溢出。应该是这个原因了。使用tagfile常常需要冒着莫名其妙的无法编译的风险，这下次编译成功不等于下一次jasper编译成功。看来白天的编译也是不妥的，还是需要晚上来一次update，然后使用程序或手工进行一系列的初步更新才可以达到目的。

在dep上看到的即时升级的问题实在是不少的，象刚刚抄录过后，tomcat干脆就没有了输出。这都是从未见过的现象。

深入尝试使用tagfile

2005-05-15T12:03:00.000+08:00

tagfile中不能setAttribute?可能这与variable的设置有关，也可以看作是一种限制。把后台所有的文件合并在一起？可行，不过还没有想到一个更好的办法介时作为帮助索引。帮助的索引看来必须结合地址和qstring才行。

原则上重新整理完那个时间问题，包括翻页等的问题还发现很多，都需要在后面的日子里一点点地规范化；但不是今天的主题。由于目前病是使用名称进行索引，所以所有关于病使用名称进行索引的部分暂时都不宜花功夫做SEO，而这一条是准备改换成 ID的。同理，还有那个科室的名称转换为id的索引。当做到这一条时，顺路就要把翻页那个要做成可以形成 html 的格式定制，这样全局就可以变成html了。

各个title处理要比原来要精细，这条同样不是今天去处理了。
tagfile虽然可以使用其他标签，但是一些概念却不一样， tagfile中使用的标签的上下文，似乎是tagfile中的page，另外，不能传入其他类型的对象。因此，当使用象list中的变量设定时，就出现困难了：它得不到原定的对象。这是在使用过程中要注意的。但tagfile文件看来可以用于解决多个列表文件中的复用问题。

转换了Processor枚举列的方式后，出现和系统抖动

2005-05-12T12:03:00.000+08:00

当Processor转由meta检测列后，就连连报出类中缺setter/getter的错误；目前还是一件好事。

processor对数值是对-1不操作，但实际上象空值非常广泛，特别是在param中传递，空值是经常的，防不胜防；所以0是一个关键值而不是-1。看来应该控制为>0，而放弃<=0的操作；但这将会与database的0/1冲突，似乎也是不妥的。

现在回过头看那个患者网的默认首页，仍觉顶心顶肺，当初所以形成这个局面，高岚界面能力不足是一个主要的成因。让她把握界面是一个大错。她不干拉倒，我看这几个编辑抽出其中一个来也可以照样做事。上下午大部分时间是搞文件上传：以前已经基本弄妥，现在是处理细致使用。

想用outlookep看看那封信，结果死了机，把妹头拖入房想一边看着她在地上打滚一边工作，免得她在外头哭吵，却把服务器电源挂断了。晚上大部分时间是搞版面组织??版面组织的事情还是我来做吧；高岚是做不了的，现在开始就不再让她插手了。

jstl的逻辑中可以使用||，这是比原来的struts.logic好的地方。

５１１／５１２，开会真是浪费时间

2005-05-12T12:02:00.000+08:00

前两天为了应付蔡生的关心，开了两个大半天会，实际上晚上的工作也受到很大的影响，两天充其量只相当于平时大半天的工作成果。

大前天晚的休息特别差，其中对于gaolan和chase的态度令我难于立刻释怀。昨天chase再次与我说不要打击laura的积极性。从他总经理的角度看平衡各方面的情绪我是可以理解的，但现在的问题不在我这里，而在laura不能摆对她的角度成员的伴置。在必要性上来说，我的必要性要大得多，就不怕打击了我的积级性？其实，我的积极性已经受到打击了，只不过本人一向自我把握比较强，不受影响而已。

还是那句老话，如果承认我是专业程度最高的人，我就继续干，如果认为我的专业程度不足于应付，就找另一个专业程度更高的??我相信不可能找到。相对于我的专业程度，其他人都是业余的，包括gaolan，这是问题的关键。我并不认为laura是必不可少的，需要特别照顾；她的确帮了不少忙，但不是必不可少的，帮忙的前提是不能添乱，至少添的乱不能超过帮的忙。目前以我为纲，就应该是帮我的忙，不是帮chase的忙。

既然我是最专业的人，并且开发的所有责任由我承担，就绝不可以说是搞我的个人网站??反过来，让我去搞gaolan的个人网站岂不是更滑稽？所以，我认为我对laura的态度是正确的，也是刻制的；关键在于gaolan仍没有摆正她的伴置??她的任务是网站内容的维护，不是规划；更不是业务规划，事实证明她完全没有这方面的基础知识和基础训练。

我已经明白他和chase相的黄页是什么了，由于缺乏常识，他们只是单方面打算把医院中的专家门诊那个报告栏摆上电脑，却花大价钱去找人登记。这是非常初级的错误：用互联网的大成本实现有限生活中的局限性且是间接性的业务。他们不能理解这里面意味着的成本。这是不了解互联网方式的自认为业务专家的人最经常犯的错误：不惜成本把业务中的某个小细节搬上网，对于由此衍生出来的业务内容（可以摊薄成本）却不能理解而加以拒绝。

这其实是我和chase的分歧的问题，与laura无关，她完全不到这个层次和级数介入这个争论??当然，她可以发表自已的意见；但不是我要说服她，而是她要说服我。现在她把这当成是她和我的争执，还要我说服她才能做事？于理不合嘛！

蔡生找了个帮手做鞋垫，给的工资委实低了点。chase对他不甚欢迎，也的确有他的道理。反过来，我也记得chase当初是如何对我的；这人目前就是差不多的处境了。就初步看他的素质还是不错的，硬件，和浏览器中的事情，大概还是可以让他去做的。但是，该用什么电脑呢？或者我这里应该拿一台电脑给他，或者让他暂时先用公共那台电脑。

花了半天时间对付tomcat的默认页，出只猫成何体统

2005-05-09T12:01:00.001+08:00

今天睡到近九点才起床，却也颇为罕见。
昨天无意中发现/是tomcat默认页，打算改过来，不过却有点看不出苗头，最后把/也设为app就勉强可以了。当然，与_app路径仍是两个context。此路得通，倒也不必取消_app改写，但是可以在随后把所有的连接都改过来，不是有一个dir的参数可用吗？……但是很快发现两个共用是不可能的，使用任何一个都不困难，假如换为空/，那么外围进入的将在提交等等时失去它的会话。

对于改写的html，看来并不影响它的post执行,get的情况如何还有待观察. form-Validation仍有改进的余地，它的验证域与主域名关联太重了。修改过后，连同formTag就应该算是搞妥了下头的一些BUG了。

laura在搞什么鬼？明明知道chase说黄页是多一句西一句前后没有逻辑联系的，却非要抓住只字片句吹毛求疵？是没有脑吗？还是其他原因？说她认真嘛，她没有担起自已的责任，说她不认真嘛，对着屁的东西却真是什么必较。

清加了一个reloadrep的cgi；但是似乎有一个缺点，就是随后tomcat关不全了,原因不明。要知道在开始的时侯并没有什么特别的变化，应该说是完全没有变化。另外，如果dao.xml改错了，整个系统就只有重启了，所以好象也不算怎样，适于在调式时用。

帮助把科室管理页面的验证部分更新了。下面是搞定那个发信问题。信这里会是一个大问题，特别是在如何不使用自已的帐号为他人发信这一方面。换言之，能否提供一个默认的SMTP服务器。以及如何设定等，目前暂时先使用repository。

晚上开始整理processor，原意是为了能够删除那个空值，但整完后没有能够删除空值；见到有大量的输出，然后进入了BeanUtilites领域。转了一圈，变成从ResultMetaData下手，有什么区别吗？好象没有什么区别呢！原来只需要不输入异常就可以了。到晚上十点才叫做把原来的东西检齐了，不需要再使用public也可以找到那些个域了。

看来在域选项中增加一项对象还是很有用的，的确方便许多的。顺便地，让name可以修改了。另一个Lister中日期的操作消除也是势在必行的。

今天开会准备好战斗，结果没有战事

2005-05-09T12:01:00.000+08:00

今天开会，先做好了战斗准备。而态度的坚决倒了减少了许多麻烦的事情;大的原则框框没有变动。

会话丢失那里仍是没有完全搞清楚。bbs的三级域名仍然不能正常登录??但怪就怪在在dep上的三级域名登录正常。所以这样就完全找不到可以参照的规律了。完全只能是每一次的尝试确定的确是可以运作的，才算正常，所以象bbs的域名就使用redirect算了。现在没有把握的是到时使用转换的二级域名对博客和个人网页是否有意义。

而另外一些功能，象发邮件确认，在原地测试时就一切正常，搞不懂到了那里就不行。最后，在开会前的升级令开会时的演示显得非常的缓慢。邮件那里？？有点明白了，这是由于邮件服务器的所在伴置不能联络到造成的。

服务器报擎，但没有时间理

2005-05-07T12:00:00.000+08:00

报擎的是2.106,就是现在的103.107，而且重启也没有成功，??这台机昨天并没有重启，再次重启，成功了，但是电源仍然在叫，看来还是要跑一趟，如果要跑一趟，就顺便把内存装上去吧。这件事也提醒了两件事：第一是应该有另一个系统保险，尽可能空出一个首位硬盘空间安装另一个linux，以备出错时借此拯救。另一方面是现在集中到一个服务器是合适的；这样的全局两线备份比分开要好得多。

跑一趟把内存装上需要半天时间，还未必可以解决电源问题；而安装一个备份系统就需要另外的半天时间。在安装工作系统备份时，还要再考虑让DEP承担一段时间；估计来去要一两天的功夫。所以还是先推后吧。
为了能方便地显示日期，抽了一个多小时学tagfile，还是不难的，看通了它的逻辑，其实就是一个平面上写简单的simpletag的做法。 fragment我还没有什么idear，但似乎比xml定义的片片要好。用来显示日期，比在lister中搞的sdf要好得多。毕竟，把时间全部改成 long型就是为了数据和显示分离，放在repository中是没有办法的事情，能够一个标签显示是最佳的??这个标签早就该写了。一些简单的涉到及经常性修改的标签也可以使用tagfile处理；特别是与html代码相关联的。但暂时地，还可以保留原有的机制一段时间？？……没有办法保留，要改就一起改。不能并行。

tagfile实际上是文本化的SimpleTagSupport.extends.Coder，大概可以这样称呼吧；也必然带上它的限制：不能做JSP内嵌的循环，不宜处理数据库操作是显见的两条。
但tagfile中能用什么？仍没有什么谱。顺便再收集资料研究了JSTL,其中许多内容可以用其他办法来实现；主要还是原来那样，既然大家都用，还是在它可能完成的情况下向它靠拢，以便保持一定的兼容性。

由于tagfile中虽然可以包容，但是不能容许后级文件中带有page，因此，不能代替choice类型。但我对import还是挺感兴趣的，可以包含外界的网页。（我刚想到），不过，它没有把图片等等保留为原地址。不过,import不能代替include，事实上这是我概念有点模糊的地方，jsp: include应该是servelt Dispatcher.include，拿一个jsp的输出嵌在这一个地方。所以我目前的包含是不同的。这不奇怪，因为我从来不会使用 jspinclude内容这种手法的。另外，我一直被include的路径弄得有点头晕，看来使用完整路径更为合适。

使用jstl所达到的一般功能，实际上我使用logic和自定义标签基本上都做到了。但仍可以互取长短，象otherwise就比我的埋default的办法要简洁。pagedefault比jstl要好，用jstl用使用一个c:choose/c:when/c:otherwise。

当取消了opflow后，就开始发现它也是有用处的，特别是那种踌过两步但仍想保持住act的情况，显得非常的方便。opflow还是有保留的价值的，在使用时第一步调用不要使用flowlink，这样就可以简化flow的设置，同时前面直观，一举两得。这就是opflow的要点。

打算修改rmsecthots，碰到最奇怪的一件事：有一段时间里埋设的断点竟然无论如何打印不出来;真是怀疑是在matrix里了；实在找不到可以解释的理由。
另一个故事同样是奇特的：明明已经执行到了热点集合清除处；并且单个也可以清除，但循环清除就没有丝毫的结果。输入断点显示删除是删除完了，转头就又装了进去，但是删除一个就正常地更新了。

三分二的时间用于tagfile和jstl的学习，主要是收集资料，阅读；并做一些小实验。在操作上打算结合tagfile也需要一定的效率牺牲。

花时间整理博客，准备发布广告，看看效果如何

2005-05-05T12:00:00.000+08:00

早上机房报告www服务器报警。那是一个双路冗余电源，当初花多了几千元，从来没有见它发挥过作用，现在好象多少有点用处了。为这件事跑一次，大概也只能是重启什么的，反正主机还在跑，我注意一下备份就是了。把它备到dep，如果不行，就用dep暂时代替一下。到假期结束要到中信去的时侯顺便跑一次，把dep内存升到2个G；这样就可以把dep提供数据服务，进一步提供系统容量。另看来，唯一可以解释为什么csdn较blogchina获得更高的排名，原因就在于使用IE进行浏览。博客不应把不同的专题放在一起，这样不便于形成高的排名和投放广告。要把目前的资料一一分开。

今天大部分时间主要干两件事，一件是慢慢收拾几个博客，为广告做准备；这花了大约三分一的注意力，其中包括那个德国网，文章不错。第二件事是准备那个 form系统，这是整个系统中的一个大项，好象也是最后一个未收拾过的大项；把它收拾完整是值得的。出乎意外的是地区的选择基本上也都选了，这样计划就要改变一下了，把地区放在第一页登记页上；不作进一步的检验：检查必须等待地区这个树系OK后才能进行。

在流程上，主要是完成登记和修改，以及激活的流程。

国内很难进行有效的媒体建设在博客中国的表现就看出来，莫名其妙地封锁文章，这样谁也没有把握有文章可以有效的发表。应对一个盖世太保是有必要的，但如果太认真执行，就是思想有问题了；反过来，也是和自已过不去。而那个歪酷网呢，版面设计不错，编辑器却是功能弱小;另一个网二级域名可能是无效的，幸好还是html的。

有点拿不准GOOGLE的排名是如何做的

2005-05-04T11:59:00.000+08:00

admin也达到了PR3，这是没有理由的，因为连连接都不会直接出现的，这部分几乎没有任何推介。那么只有一个可能，就是工具条的作用。不但如此，象患者网医生网的PR现在比首页还要高一点。这里转头需要再一步的协调：当周边的PR达到一定数量时，就可以看看到底要多少让第一页升级了。把session 时间缩短后，在线一般地下降到了50多个，这正是相当于三分一的水平。连接在线刷新了占了一定的的击率，包括在客端的刷新，所以昨天真实的点击数仍是拿不太准的，一万几千。后面重整LOG系统时要把自动刷新的部分清除掉。

打算修改那个sendmail程序令它适应性更广，但却发现当初只是完成了可用性的研究，要进一步令他变得更可用，必须进一步细致规划整个sendmail流程，并且必然形成一个mail的标签库。最终，的确可以在网站上达到一个邮件客户端的主要功能。

使用windows.explorer管理samba中的jsp文件，差点造成大错，以后凡是使用explorer进行删除都是禁止的操作。晚上主要是发布，发布后发现www的速度很慢，然后是验证并花时间找原因。可能找到了，速度上去了。

开始处理CP，这是一个大项

2005-05-03T11:58:00.000+08:00

使用EL如果属性名是xml就会出不知名的错误……不是，是页面对象的类型错误。

看来，看来标签的确比action有着更大的优越性： password原来需要一个servlet，现在只需要使用现有标签就可以完成。 action/opflow全面向jsp/tag/action转进，可以进一步实施，直至结果很可能是把struts完全废除。opflow基本上可以定为不再合乎事宜了。

今天的精神相对于昨晚的睡眠时间来说是不错的；但总是不算好，晚上头痛不止。本来计划在临晚不再处理细节问题，留下时间做总结，不过仍是不知不觉中超时了。今天的时间仍是花在CP上，并且大量时间整理用户登录/改资料/取密码等等整个过程。添加了对名称规范性的验证，这条其实还是挺好用的，只是不太熟，时间也紧。取回密码部分是一个较大的工程，到晚停就停在这里了。CP的一个重大课题是如何促使人家登录使用CP。

用户个人访问日志可以做出来；由于有会话加以辅助，所以是比较地简单的。不过这点有点偏移主题了，大概应该在黄页做出来后再做。结合活性编辑器和实体方法，实际已经可以把整个网站实现脱代码的编写和日常管理了。的确是一个重大的技术应用的升级，到此为止，网站基本上已经可以比较准确地实现多用户的操作使用，包括动态网站的发布了。

担心mysql成为系统瓶颈，进行了优化

2005-05-02T11:58:00.000+08:00

我担心mysql的连接情况，不过它的设置我仍然有点措不着头脑：寻常的修改会令它不能启动,而找不到任何启动不行的错误提示，300改500试过一段时间，1000改500也试过。（这条要上论坛问一问）,修改是否已经OK？目前只能是以通过show variables看到，是不是就是那个意思？最要命的是启动失败的时侯没有提示。

alexa的计数直线下落，看来它真的经过了一些平滑的处理。同样有点弄不明白。不过反正可以把它打得挺高的，这就是我的目的。时间上也是有点莫名其妙的，一会儿一天变几次，一会儿不变，上下变动值也是莫名其妙。section计数也终止了，除非修改基于database的计数，否则不会再得到这个计数。目前还是先推行为佳。

需要为复基添加维度，以便一个复基服务于多个参照。看来这是有必要的。但进一步就面临着任务扩展的难题了。Database自从几个月前完成以来一直是底层的基础；但也慢慢显得需要合理化操作了。
一来，dababase.xml编辑达到一定数量时，就会显得困难，特别是xml缺乏键管理措施，更加是显得困难；
其次，一次性载入所有记录耗用内存比较大。事实上小基类使用的情况不算很多，完全可以象simplebase一样有读才载入；定时清空；
第三，不能刷新，要等；
第四大类如role很少在运行时访问，没有必要长驻内存，这样就存在着一个希望load和unload设定的要求；
第五把一些基类如role移入其他表还是比较麻烦的，而把artype移入数据库，同样是较大量的工作量；
第六，复基没有经过更严格的运行。

总之，这不是短时间内可以完成的。牵一发动全身；小搞不如大搞，要么就不搞。看来这是开发程序中的一个特点，最小化意味着大量合意功能的缺失，小搞意味着大量的重复工作及维护（结构多次移动），成效最低；大搞可以提供全部功能，如果功能都用得上就是最经济的；如果功能用不上就是不经济的。所以，小搞就变成是最经济的。初步判断这将演变成一个大工程，可能需要一个星期的时间，而且会伴随着抖动。无论是那一条，都是不应该现在进行的理由。

象chase那种问题有时很奇怪的，他不懂技术也无法向他解释：要增加功能就必须有所修改，修改总是有涉及的。如同药总有副作用的，但仍要吃药，就因为病人需要吃药。
会话这个问题到了二级域名真是头痛，完全缺乏重复性。为安全计，还是把与域名相关的部分都在下面引一个iframe为妙。

翻页导引部分一直是虽简单但头痛繁琐的地方，把它合并到一个包含的文件中，更利于提供精细的翻页导引。

下面正式开始了，在有日志记录的时侯可以清晰地了解到什么事情把工作空间占用了。下午开始的是整理form。hanva.form是另一个大系列的标签，但应用得比list少，而且也更显得不成熟。用得少的一个重要的原因，以致于一些操作不得不直接写成html，这不符合原来的期望。在form成熟后，大量非常相似的popupform可以归纳为一个文件了。

下面到了注册过程中的修正，但是我完全看不到如何拿到密码的办法。

注意保险要交钱了／会话丢失开始困扰人了

2005-05-01T11:56:00.001+08:00

专业向无知让步，总是带有额外的代价，区别只在于代价由谁来承担。使用病专栏替代首页，是chase没有网络常识，laura没有基本能力的妥协性产物。实质上我做多了几件事：要使后台可以调置一个默认病专栏；要在前台特别协调；代价是一旦出现类似的变动就再次带有更大的成本。而如果使用一个首页就根本没有这个问题。责任上说是laura的能力不足所致。

杨欠缺逻辑能力甚至可以从这样的语句看出来：(语句丢失，这个博客不能处理代码型的)
试问有必要吗？这是见其然不知其实的作品，换言之设定声明变量的用意他也没有理解。所以杨其实不是帮我而是帮laura，因为她连这个能力也没有。让他做的直接编辑病专栏一节也没有了，不过这个估计是由于覆盖造成的，开工后要重新让他做一次。

昨天那个自动刷新功能是可以的，一晚都没有丢线；但是不知为什么，现在却是连连掉线。实验出现了不一致，也就不知该如何继续了。现在暂时改成刷新本页，应该把握会变得大一点……仍是不行，自动刷新似乎无助于会话的保持.也许是由于meta 带来的自动刷新等同于告诉浏览器，不要保留会话。……仍是没有保留住会话。可能，这与最低时限有关系，低于某一界值的话，就无法通过刷新保持会话。而如果可以保持会话的话，可能使用meta.refresh效果更佳。

section现在是一个base，但是使用方式却特别，用的是name 而不是id，这样潜藏着一个以前未涉及到的使用方式??基类是名字而不是ID。更替到id是一个大工程，无疑id由于没有歧义，但也欠直观，紧简单的方式就是扩展baselect这类组件，令它可以支持名字的使用。

保险通知单现在还没有收到，不知是不是有点什么问题，象让那个王什么红的改掉了。要注意一下，这个月还是要把钱存进去的。

看来webadmin与普通科室的使用还是有很大区别的，难以合并。

www晚上似乎中断了一会，重启后发现会话极多；就象死循环。但没有发现有死循环，发现的几个错误地方也相应的修改了。本来打算连夜上去试验在线维持，但是操作失误，尽管恢复了过来，从保险起见，就暂进不更新www只对dep做功。

但是说到这里，又似乎有不妥的东西了??原来使用一个iframe是因为会话丢失。现在使用一个refreshmeta，把那个删除了，照理是不行的。但现在却是成功地登录了。这是什么意思呢？意味着和昨天的结论是相反的。到底是保持还是应该抛弃呢？

提高mysql连接数超过300的方法没有找到，记得是不允许的。使用samba转接出来也没有做，来不及了。

带女儿到她伯父家串门，也算是一种休息了

2005-05-01T11:56:00.000+08:00

今天带女儿到她十个月大的姐姐那里，算是一次休息。中断时间大致在五个小时左右。会话保持看来是成功的，而alexa计算也渐渐回复到正常，估计近一两天就有一次剧降。介时再用向本地的连接发出连接看看能不能让它的计数上升到新的高度。

论坛按最小操作原则重新整改了。这里的页面是最缺乏规范化的，所以维护（适应新的机制的必要的修改成本）也是最高的；要减少以后的成本，唯一的办法就是全面规范化，象bbsedit需要在中间加一重，然后把两头的编辑都合并起来；反正需要统一的整改。如果不是目前这样的操作方式，仅此就至少有超过二十个类似的列表程序需要维护，成本是非常大的。修改论坛程序需要随后有一个跟进检测可用性的过程，在没有其他人帮忙的情况下，现在进行这一步工作就是低效率的。还是推后到有人上班吧。下面的事情是asoka弄的诊室前台。asoka根基不扎实，又不算太好学，因此让它做新的东西有很大的困难。照抄某个东西倒还是有几成可以的，而laura是连抄的能力也没有。

这个前台通用的关键是需要有一个检查诊室存在的方式。selectcount是一个广泛需要的工具，对数据库的压力也是很小的。而使用枚举方式尽管也可以，但是对数据库的负担非常巨大，所以搞一个实际上是看看数据库是否有记录返回的标签还是很有必要的。杨完全不懂使用entity，取entity的地方都是使用list，然后设定名称。这条已经提醒过他的，看来他真的没有把注意力放在做事上，聊天的家伙没有出息，再一次得到证明。他不能理解组件的真实含义，不能自已完成那怕是一个presentation模块的能力，只具备抄改的能力。

Modify中如果域字符串是空就不会更新；这是一个两难的选择：如果允许更新，那么不但可能与notnull冲突，而且很多时侯诸多域中只想更新其中一个，也没有理由全部一起抄进去；但否则的话就会令偶然的设定更新为空无法执行，唯一的办法就是允许执行进接的sql语句。

做一个连接，再看看另一个链接，再看第三个，和第四个，第五个，以后就做好一句话，照抄，the Create,jchinamed，另一个blogchina,edu,否酷，歪酷，另一个也不错再加一个。几个简单的全都行了，但是直接拷贝下来的就不行。还是先做好一页，以后全是抄吧。Alexa的计数看来挺操蛋的

在中国卖的东西很多是垃圾，象那个短信的EMAIL

2005-04-30T11:54:00.000+08:00

目前不知葛那里的资料是什么回事，如果没有猜错，其实也没有什么用处的。论坛就是一个jsp较散乱的例子，照顾它改过来花了不少时间。不难，但是花时间。而且我也在这时侯更感到找不到水平的人帮手是越帮越忙的道理：除非范式互相认同并同达到共同的规范；否则就会蔓延出一大堆乱七八糟的jsp；把它一个个跟回来固然花时间，而如果不管，那一旦底层组件有修改就不得不照顾版本问题而不得不向下兼容，这又导致要照顾几套版本，滚雪球一样滚大。相反，自已照顾的话至少可以更熟悉也可以使用工具帮忙。所花的时间常常更少一点。

iframe自动刷新的部分成功地令二级域名等保持了会话；但是保持会话的目的似乎没有达到。还要再进一步观察。今天的论坛仍没有完全跟下来，而且诊室前台部分也没有完全跟妥。

alexa那里退到了7000，这才开始接近正常。而www则由于线程用尽，停了小半小时。还要继续监视。做一个连接，再看看另一个链接，再看第三个，和第四个，第五个，以后就做好一句话，照抄，the Create,jchinamed，另一个blogchina,edu,否酷，歪酷，另一个也不错再加一个。几个简单的全都行了，但是直接拷贝下来的就不行。还是先做好一页，以后全是抄吧。Alexa的计数看来挺操蛋的

仍未开始继续中断的工作

2005-04-29T11:53:00.000+08:00

大约五天前，因为必须先把科室基础转移到数据库，涉及到SectionBase的大迁移；这个大迁移随之又涉及到一个严肃的课题：有关存储对象化和实例化的问题。SectionBase大迁移牵涉到了所有jsp和标签直至类的包括命名规范化的再整理；以及包括系统后台的大清理，把struts.Acion 向HanvaActionTag的转移；这是一个大扫除，既扫除已知的不规范，又以发现新知的问题，如二级域名会话丢失的问题。以至于五天后，事情才算告一段落。

早上花了一个多小时，把roleadmin.jsp搞定了。本来原则是如果原来的组管理还可以跑就不作修改，那怕修改是举手之劳，但是它就是给权限卡住了。既然是举手之劳，就改掉它吧！的确，对于有权限要求的操作，使用tag较直接显示为url的servlet优越性明显。趁着他们还在上班，先上载到 dep上让他们可以跟进检测一下基本功能。

的确检查了不少事情，大扫除仍没有完全完成，在form中仍有不少flow的不合调用。bbs 就是一个。但在打算到www看看原来的链接是如何产生的，却发现down了，日志显示是线程用尽，有小半个小时，看来tomcat的问题还是挺多的，（用尽线程就释放重启就是了，为什么会down呢,这条要上论坛问问）

中午，重新又碰到那种每刷新一次就出现一个会话的情况，而URL重写已经是使用了RL，看来仍不是点。更重要的是，重复性也太差了。转眼又似乎OK了，似乎是一旦通过认证产生就可以了。不过，问题正在这个地方，是否认证只不过是一直绑定在session中的visitor的属性，又怎么会影响到会话的认定呢？进一步的实验表明，是由于经过了真实的域名后就可以绑定会话，否则就不可以。（还是要上论坛问问）。这样也可以解释为什么www上的会话产生会如此之多了：这是由于每刷新一次产生一个新的会话！最终通过提早嵌入一个无显示的iframe解决了问题，iframe指向一个固定域名的地方。

尽管使用了tag代替servlet优点明显，但在一页中串列一系列处理tag然后再显示的话，然是不行的，主要是不能提供重新刷新的效果。因此，凡是这种处理，还是在弹出页处理最为合理。

		做一个连接，再看看另一个链接，再看第三个，和第四个，第五个，以后就做好一句话，照抄，the Create,jchinamed，另一个blogchina,edu,否酷，歪酷，另一个也不错再加一个。几个简单的全都行了，但是直接拷贝下来的就不行。还是先做好一页，以后全是抄吧。Alexa的计数看来挺操蛋的

今天还是扫除和更替为主

2005-04-28T11:53:00.000+08:00

做一个连接，再看看另一个链接，再看第三个，和第四个，第五个，以后就做好一句话，照抄，the Create,jchinamed，另一个blogchina,edu,否酷，歪酷，另一个也不错再加一个。几个简单的全都行了，但是直接拷贝下来的就不行。还是先做好一页，以后全是抄吧。Alexa的计数看来挺操蛋的，周日到周一明显我是试验性作弊，弄到了2000左右，但是稍后就停了下来，而计数却仍是在2000多，甚至还有上下浮动。可见它的即时性颇为不准。估计有一些平滑性措施之类。还有，我是对着dep作弊的，而这也没有在记录上显示出来。

在添加上instance和serialz自管理方法后出错，检查下来，发现是由于同一个实体的不同时侯是可以使用不同的Class的；同时，它不一定总是带有全部的字段(field)方法;因此尽管instance/serializ方法总是存在（继承），但字段不在，仍是留下log记录；因此需要添加判断：只能是指定的类而不是超类作为读取对象时才进行这种对象的串行处理。
在实际围绕着formtag的测试中产生了缺乏回归性的结果：一开始是没有得到dform,然后围绕着formtag为何没有成功转向做工作，忽然间，一切都消失了，变成了另一个错误：在初始化实例时没有找到entity. 另外看来把所有相同的文件不因用途不同而分开是对的。

中午睡了一觉后精神觉得好得多了。不过在重新检查role/member管理时却失了方向，不知道原来是如何实现的，而且老一套似乎根本就不能运转，那怕是在www服务器上。唯一的办法似乎只能是在下班后他们都不干时把dep的换成旧的对照着操作。在此前，先进行其他，但马上就又发现问题。

实际上在把转向的域名前缀去掉后，就不时发现有会话丢失的情况。开始以为是密码打错之类，但现在很清楚：在使用非主域名及struts的 action后，按ActionMapping的重定向都造成了会话的丢失。原因是什么，这里仍然没有很明确的认识；估计和中间有一个"/"的过程，在失去了app路径后会丢失会话，这是经过验证的。但解释并不充分。由于ActionMapping的处理并不是完全透明的，这样，也就失去了进一步解决的可能。使用非主导的工具体系的缺点也就在这里。可以改写一个同样的tag，看看用Hanva.ActionTag是否会出现同样的情况，或者会有更准确的认识。这样一来，改写的部分就进一步延展了。在写这个程序前先把entitytaglib和cmdlib分开，由于处理程序越来越集中到taglib中，这样原来的分类就显得太庞杂了。

然后就改写了那个logonAction为LogonTag，但是在这个程序能够开始工作前，最终却发现会话仍是丢失了。直到，在改写中使用R,L 而不是L时，才得到修正。看来，这是与是不是struts的无关；而是与非正常域名的改写规则有关系。由于目前没有在首页提供登录，所以没有迹象表明同样作用到首页，但可能性是非常大的。要维持二级域名全程，看来只能使用R改写。但是进一步显示的结果非常可怕，就是在二级域名改写的情况下，几乎没一次刷新，都是一个新的会话记录。……但随后这种情况又消失了，显得非常的不确定。这下子也没有办法再进一步了，因此会话显得太不可靠,没有重复性，也就没有什么可研究的地方了。目前可以做的也就只是知道session可能会丢失，以后在碰到类似问题时可以先查一下。

晚上九点多了；终于回来重新看那个旧的会员管理为什么可以工作。原因在于Opflow把type传了过去(在这里显得挺巧妙的)，这样，尽管form中没有 type，但仍可以令cgi接受type。而现在没有 opflow，就只能让form预备下type了。葛兵，96688-013901310204；

roleadmin.jsp 是最早的一个列表jsp，同时也是最复杂的一个；也是唯一的一个两重列表。简化了要求后，实际上也同时是验证几个处理标签的正确性。看来，还是应该把几个共同页面归一。明天，仍然需要一定时间继续搞清洁。随着五一假期的到来，不可能期望其他人帮忙了，还是我自已去验证最主要的功能吧。

今天是搞代码大扫除，全部规范化

2005-04-27T11:51:00.000+08:00

昨晚上已经是注意提早上术睡觉，但是仍然是早醒的毛病，今天的精神状态和昨天差不了多少，仍需要注意休息。博客司机中国博客 csdn hanva.test ＸＰ编程测试专栏 BlogSpot 博客城参考站点一参考站点二参考站点三参考站点四参考站点五 jakarta 中国医疗中国医疗中国医疗协会草珊瑚博客总线 CORAR 酷网中原人
从日志上可以看到，由于会话保留时间很长，搜索擎带来的会话造成了很大的负担。看来，有必要有一两周内使用iframe保持会话；而把会话保留时间压缩到很短。这样还有另一个对计数上的好处。

今天的工作内容主要集中在令DAO类型可以对自已的集合字节实行实例化和串行化的管理；这涉及到Section的彻底取消，除了实际上使用 database的section之外；在重新编译所有类的过程中，大量涉及到一些action中的错误；既然要修改action，不如顺路直接改到 tags;改到tags，又涉及到opflow和jsp中的清理，包括struts-config中的清理。这样，就演变成一个根本性的大清洁了；尽管是早就有计划进行的。从另一个角度考虑，大清洁通常对于后面的维护，包括再开发的起步有实在的好处。象opflow，如果不加以清理的话，实际上已经变得无法再用了。

写好了VEntity/DAO的实例化/串行化代码，完成编译；把SectionBase的代码彻底清除出去以绝后患；把 Action的代码和 opflow中已经过时的设置全部清除；把jsp中涉及到的连接全部清除；其实真是一个大工作。到晚上才叫完成。但调试却还没有开始；还是先睡一觉再说吧。

今天精神不好

2005-04-26T11:49:00.000+08:00

自dep升级以后，应该抓紧在五一黄金周以前把它升级到www上，以便有两天可以用来检查实际运行情况。升级到www上还有一个操作就是要确保科室的正常运转。由于原来的目录是原装备份的，不行就换回来，倒也没有什么不妥的地方。病专栏部分也没有太多的可处理的地方。升级后仍需要把科室设置的xml拷过来，然后备份一次；因为原来的科室的备注是不全的。不过升级是很容易漏掉东西的，asoka改错改漏未改好的固然如此，而dao.xml中关键的针对服务器的调整项目也忘记了。不过，现在比当初还是好得多了，只有几个地方要跟进，不然碰到升级就是一堆抓瞎。
这两天精神仍然很不好，今天也是如此。早上起床还觉得不错，但很快地精神就直线下降；而且休息也不管用，浅睡易醒，对噪声敏感；这是积劳疲惫的表现，要注意休息，特别是提早睡觉，平时累了时能睡就睡，把精神恢复过来，效率就好事半功倍。
目前是把section等作为对象型放在数据行中，它和关系数据的结构差别在于之与多表关系隐藏中子对象集合之中。对象有集合，而关系数据库就没有这个集合。通常在关系数据库中类似section-artype这样是以多对多关系表示，通过sql连接。但在显示时仍是麻烦的，那个集合最终仍是不得不面对。在把section转移到数据库后，一直没有直接修改到这一步，直到发布后就发现了这个问题，这是一个需要静下来理一理的事情。
早上laura在和chase提了提缺科室的事，不出所料，chase根本没有考虑内在的含义，马上一把否定。这就是我说的业务人员不懂业务建模但又不愿承认不懂，不愿意承认建模的必要性的表现，回答是预料之中的，（看昨天的记录），如果没有自已的主见，人家说什么就否定什么，那么就什么都不用做了??因为人家没有义务把事情做出来；也没有提供如何做的解决方案；只是说这个不好那个不好。人家现在不懂也是东西不好的理由之一。几乎是立刻的，原来强烈反对的科室首页推出，得到了承认??实际上这本来就是网站建设的基本常识之一。
今天实在是疲劳，大约效率只有正常情况下的二分之一以下。尽管出了几份博客，其实不过是工作过程中的思路总结，非此不足以明了下一步如何做才是合理的。也不勉强了，该睡就睡吧。

asoka的任务

2005-04-26T11:34:00.000+08:00

昨天布置了asoka几个任务原则和三个具体任务：把诊室搞妥，直接编辑专栏介绍，修改更新标签，减少一次数据库访问。今天再看看代码，前一个没有开始，中间一个没有搞定，后一个我还没有看。明天要再打个电话问一问，并且还可以再布置另外的几个任务：其一是qzys栏目允许原作者继承发问；其二是前台允许判断时间显示new；或者包括论坛。他目前的处理方式是挺可笑的：最前四个定为new；回想起早先他的日期处理方式，估计要求它做到按日期处理还不是太容易呢！基础不足，皮毛不懂，从asp角度理解jsp；不懂英语；提供的余地就很有限。不懂英语，我想是致命伤。明天估计他会开始搞诊室，所以不妨再缓一天。

我把_jsp目录移到管理目录下面，并把后缀名改成jsp_由于有apache保护，不再担心会给下载到客户本地。这主要涉及到各个科室的目录中文件也要改到当前。不过由于asoka的专栏部分还没有改好，这样如果改过来是不是我替他搞掉呢？显示不妥，所以不如继承让他使用旧的_jsp目录，然后在他这个问题完毕后再一起过来。使用find . -mmin -xxx的办法可以找出修改过的文件，或者这样更有利于保证版本的一致。反而是数据库有修改，要注意保持一致性。

今天全天精神甚差，勉强撑持，眼皮直跳，甚至傍晚睡了一两个小时也没有好转；其实也没有怎么睡，总觉得周围太吵了，睡不觉，似睡非睡的。

4.25网站的在线统计

2005-04-25T21:21:00.000+08:00

网站的统计功能需要一个专门的服务。实际上它的统计包括两个层次的含义：需要日期参数序列的日志，和单一总计的统计。后者分别由各个实体记录中的字段累计，但无法分清各个时间段的累计。而各个日期段的时间，就不能在实体中记录，否则太复杂了。解决办法就是通过这个专门的服务直接作为汇总报表登记入一个专门的表之中。这个类更象是另一个log，只不过，只记录点击/时间段等方面的内容，而不涉及其他。所以分析下来，这是一个不小的模块，而且相当复杂的。

网站的在线统计目前受制于会话时间段；时间段太短不成，但太长也令会话失真。一个办法就是在每一页中添加一个iframe，iframe中使用一个自动刷新窗口，然后就可以把会话时间收缩到很短，大概只有几分钟。这样的好处除了在线统计真实了许多外，还有另一个好处就是可以借此调整网站的流量。frame 当然可能更好，但我目前真的没有找到无frameset的frame操作的例子，可以再去问问别人，但需要时间。一些网站的排名如果没有这种手段，我才不相信他们有能力跑到一千几百。

有了这个在线统计，就可以很好地实现在线客户显示等等功能，同时，刷新部分也可以提供另一个功能，就是实时信息提示。总之，还是有必要的。

4.25对这个网站建设项目的初步思考总结

2005-04-25T21:18:00.000+08:00

对网站的建设实际上我有着最完整的思路，但Chase总是否定得太干脆而没有经过深刻的考虑（这也是他一向的大缺点），别说laura极少支持或有水平支持，就算有，其实也没有太大的用处;Chase是除非他自已认识到，否则跟他说什么也没有用的。最后，我现在实在忙得紧，如果没有时间精力马上付诸实行的话也没有必要现在提太多的东西。如果需要干的话，其实也不见得非要说服chase才去做。这指的是二级层面的工作。

在一级层面上，仍需要一步步说服chase。相对而言，说服蔡生更容易也更危险：如果他觉得前途困难，他可能干脆就中止了。一级层面的事情，其实就是说整个网站的思路是否符合小而广的建网原则。违反小而广原则的网站，基本上是不可能获得独立的成功的。这个原则归纳起来，对网站来说就是OPEN的，允许其他人进来，而不是自已特约的专家才可以进来。实际上，吸引专家的数量是网站成功的关键而不在于那份合同，这是chase没有搞明白的事情。不过，这并没有否定合同带来的科室建设的稳定性，红花需绿叶，现在需要的是绿叶。chase的思维似乎缺乏处理多层次因素和相互关系，综合考虑的能力，

我们的架构支持许多的科室建设。唯一例外的就是dabase在基记录太多的时侯，可能需要考虑它的载入方式，分二级载入，或者，象科室菜单等就建立一个机制，定时载入到一个文本文件中，以减少内存中的记忆量。不过，这条目前还不用太担心，虽然列表打印出来量很多，但并没有迹象表明系统内存在危险边缘。

因此我们应该放开接受科室。另一方面，目前建立的科室有大科有小科，小科居多，这也意味着需要多个科室。多个科室必然意味着科室的导航入口；而这又是目前所缺乏的前台的考虑机制。Chase没有能力去考虑这个问题，而laura则没有意识去挖掘考虑这个问题。

除了科室，接受外来新的专家显得更重要，这是目前他们的考虑都非常欠缺的地方。象论坛，应该将招引并留住其他专家作为一个重点中的重点，包括专科学生；另外，象诊室之类应该可以以博客为基础扩展开来。这样，有了基础的资源，其他的业务项目才有生存的余地。这种修改也不需要大的投入，只不过是小的，却是至关重要的基本逻辑的修改。在这个修改完成前，这个网站实际上并没有贯彻小而广的原则，而是不自觉地多少跑了大而窄的路子。

目前无论是博客还是黄页登记，或是招聘，都接近于是一个通行证对多个服务；每个服务都带有一个后台管理；一个前台用户管理和一个前台受众浏览的部分。逻辑相似，就可以建立相似的组件。一个不大不小的问题就是缺乏映子科室的建立。尽管表面上黄页和博客都是附在科室上，但科室开得实在太窄了，我们不可能针对一个领域百分二十的普通受众建立这个服务。但建立影子科室则面临另一个不定量，就是如何处理影子科室，这涉及到一定的业务策略，这不是我能够处理。目前能够做的就是削弱科室的影响，建立一个专门的黄页登记前台，把分科不分科的都登记起来;事实上也需要这样一个前页，不过，也必然会受到chase的反对_实际上是不理解！

象blogger这样的一个通行证可以管理多个专题栏目值得考虑，这样利于专题的建立。不过，不算太利于单个栏目的综合建设，而且，一般人还是习惯针对一个栏目建设，而宁愿使用多个ID。允许黄页和博客、招聘发到多个科室可能是有益的，但也会令所有人发到所有的科室，这也不是一个好的办法，倒不如可以让他改挂进不同的科室。无论如何，黄页等与个人相关的项目还是不要和科室结合得太紧密，而以挂靠的方式为妥。这样，就不涉及到科室的管理，而是在系统管理中进行；同时，要把这些部分从科室管理菜单中去掉，至少是不能删除；或者说删除挂靠，这是一个很重要的原则。

项目中最困难最矛盾的地方

2005-04-25T11:33:00.000+08:00

前一阶段我花了大量的时间到了菜单组排上，这是我极不情愿的。我一直认为自已是一个至少是组件级别的开发者，而不是菜单编排上的开发者。但最终却不得不如此，而必要性，其后就忘得差不多了，只能要横蛮的态度：就应该这样来应对各人的疑问。现在，我再次面临这样的问题，而原因却深刻地体会出来了，把它记下来，可能对以后如何处理这种困难矛盾的境地有所帮助。
对于这个问题，首先必须明确，作为网站本身的策划其实是不足的，业余的，尽管商业策划中的一些想法存在闪光点。如果我在公司的收入是满意并有保障的，或者就不会持完全的支持态度。问题在于，chase本身对于网站建设和推广缺乏基本常识；而又不容易接受他人的专业意见??当然，这是双向的问题，如果他容易接受他人的专业意见，他很可能就不会同时具备同样高的自信和热情。换言之，名义上chase是销售，实际上只是销售联络员，真正让网站能够销售，却是要靠我的策划和工作。
大部分时间内，另两个本应发挥更重大和更自觉作用的角色是laura无论是专业水平还是个人投入都很欠不足，这也令这个网站的建设从一开始就存在先天不足，如果我不加以全力支持，这个网站几乎从一开始就是不可能存在的。而另一个参与者石生，更大程度上只是起到令项目上马的作用而没有对项目本身提供任何实际的帮助，或者许可证的申请除外，那也是要花专门的精力的。这样一来，实际上决定这个网站项目生死的是我，而不是别人。
从我的角度上来说，尽管辛苦，但把这个网站扶生扶大却是最合乎我的利益的；尽管让它开始从投资角度上看不算太合乎公司的风险控制。一方面，我实际上已经具备，我个人相信，全中国乃至全世界最强大的网站开发能力，至少就单人来说是这样；而且我相信，即使是许多大公司的开发团队都不会比我一个人更强。我是专家中的专家，高手中的高手，我自已深信这一点。但初始地位和的机会的不足，特别是在中国这样一个压抑个人的封建国家，我必须抓住身边的每一个机会；而建设一个大型的专业化的成功的商业网站，既是能力的证明，也是职业能力的提高，成则于公于私都有利，败，至少也可以让我的技术能力再上一层楼。
另一方面，我的年龄先天不足，实际上我开始学程序的年龄是其他人开始退休的年龄，仅仅是靠着一种疯狂，我的一年实践相当于他人的两到三年，而且一直是在技术的最前沿，不存在老化的问题，这样才使我后来居上，当仁不让，那怕是所谓的高手的所言所谈所做所创，在我分析后，却感到其实比不上我。而我一向自名为德国人风格，对于发现自已的不足是无情的，对于自已能力的肯定也是不回避的，我相信我的评估是客观真实的。
但年龄的不足就使得我的能力在其他公司获得认可的机会大大降低，实际上根据就没能给我施展的机会。所以这个项目提供了这样的可能：无论它多么不可能，开始条件多么不理想，至少是我可以作重大发挥的项目；可以进一步证明自已的地方。

这就是我其实是最希望这个项目成功的一个人的原因，尽管表面上是帮助chase成功，而实际上帮助他成功，我自已也是不会失败的，反之，如果他失败了，我也难以成功。难题就在于这里，我不但要维持投资者的信心，还要维持销售者的信心，以及其他同事的信心，而这些伙计的水平又太低，甚至可以说是不学无术，碰到完全矛盾的致命的概念缺失或错误，我既不能回避，也不能照搬，要让他们能够理解，但又不能让他们太丢脸子，（会丢掉信心的）。
菜单就在程序来说是一件小事，完全可以由低几级的人员去从事，但他反应了一个网站的基本框架是否合理。chase的理解力就停留在菜单上有那几个字，而不能理解几个字后面是什么概念；laura本来认为菜单是她的天然权力，但她却没有从网站使用者的角度以及这个网站商业可行性去考虑菜单的层次，仅仅是百分百奴性地牵就需求用户的无知和要求。这就是我不得不直接处理菜单的原因。
就以目前碰到的问题来说：黄页是针对医生的登记，同理招聘和商业发布都是一样的；而chase能够找来的科室只是占了可用科室的20%，难道辛苦做出来的黄页和商业发布就对20%的科室和医生起作用？简直就是白痴的选择！其实解决办法也很简单，只需要换换思路就可以做到：科室尽管是网站的基础，但只是吸引人气的信息集合；是发布其他商业的渠道而不是唯一的载体。专家的黄页没有必要一定归属于科室，同理药品和其他也不必归属于科室，它们是独立的。但可以挂到不同的科室下发布，这时侯，科室是网站发布的服务租凭方。
这是人见人懂的基本原则，但我敢肯定，那哥们就是不懂！而且一旦我提出来，是什么反应我都可以预先知道的：第一就是不理想，多几个字后面的全都是白说，这样理由再充足也说不来去了；其次，就算是理解了，他也会先否定你的，反正理由嘛正理歪理总是可以找到的；而最大理由就是：我们是和科室签了合同的，离开科室就失去了特色。多搞几个专项门户在同样的资料基础上发布专项内容，不会影响科室本身的特色，这条，几个月了，他还是不懂。这就是困难的地方，就算明知前面是对的，还不能先走十足，以先走70%，让他否定，然后再转成90%100%。
菜单是这个逻辑的晴雨板，象如果黄页实际上是不能挂到科室下面的，那么科室下面就一定是少的，不能再分；那么他们落后的理解能力就难以理解为什么想象中的省市分类不存在??别人都可以做到为什么你不能做到？却不去看别人的科只是一些分类，而我们的科室却是营业的实体；别人的分类可以单纯地做得完全，我们的科室却只是一部分。
如果象黄页不属于科室，（可以挂靠），那就必然需要一份黄页入口的首页，黄页，最典型的就一定是从首页开始导入的。但这样他们，特别是chase不会说，这相当于多一个站，好了现在他已经糊涂了，到时更糊涂，所以不赞成。
这就是我最困难的地方，实际上对于眼前要做的东西，这帮家伙没有一个准主意，但却都执着某一方面反对的死理。我却必须把几个抽象的想象的东西，一般是做一个可以B2B买卖药的网站，变成一个实际可以运行的实体，业务也是可以运作的；已经够困难的了，还要面对这些个死理，有些还很无聊的，象laura：看见下拉菜单就别扭??您是专业人员，怎么把自已的喜欢代替从客户角度的考虑？我不是喜欢下拉菜单或讨厌，但我要求所有专业人员都必须从专业角度出发，从客户眼光出发考虑技术问题，而不是任由自已的喜好，这是非常缺乏职业质素的表现。
今天我仍是如此做，把基本的东西做出来，先不在前台显示出来，然后让他自已说出我要做的，这样就少点反复了。