UFT-8工作日志

2006-07-04T18:57:00.000-07:00

今天的情况，可以用事事不顺来形容。
自从昨天下午开始万维显示出不堪重负后，在禁制了若干搜索访问后，表现显得快了不少。晚上打算修改一个数据库的结构，不成功（后来发现是命令打错了，需要时间太长），重启后显得好象是正常工作了。放开了一些海外的搜索引擎，没有迹象表明是海外的引擎导致服务器的瘫痪。为安全计，没有把其他地址放开，就关机睡觉。

但今天早上还没有来得及放开雅虎，就发现主服务器的数据库垮了，但java应该没有垮。第二，是dep也垮了，bj也垮了。从www昨天给搜垮看，那么dep也给搜垮，倒也可以解释；北京服务器的垮又作何解释呢？前一段时间，这台机在启动程序后不久，总是由于jvm垃圾问题自动关闭；后来重启整个操作系统，问题似乎是解决了，运行了差不多一个星期或以上，中间是否有重启过程序？现在已经记不清了。但记录也显示，这是近来的第一次重启操作系统。最后显示是主数据库垮了，或者，这可以解释为什么几个方向都同时出问题，有点勉强，但还是可以说得通：由于主数据库错误，各服务器积累了多次的错误请求后溢出。

即使承认这条，也等于是负载调优返回到昨天下午的状态了。

而alexa也同样是有问题。上个星期对.net的操作没有得到验证，返回来后，周日显得正常了一点，但周一应该是全面而且正常的，结果却是大错，alexa掉得没有影子。除非，这里显示的是同日而不是周一的数字。那么也是勉强可以说得通，因为，周六前跌是我没有回来，后面跟着是周日。而周六升是因为我回来了。但这里也说不过去，因为我周日的操作应该是算得不少的。非常勉强，但难以立刻作出反应，唯一之法，就是禁止自动页，这也是仅仅减轻这样的可能：由于不恰当地使用了刷新，结果遭到了惩罚。至于换AID和换IP，后者无疑是合法的，而前者，是否正确，还言之尚早。但由于对net的试验没有获得成功，这始终是一条阴影：如何才算是对的？

2006-06-08T20:15:00.000-07:00

间断试尝试组织一个可用的mail，最终发现难度和需要的时间超出预期。当前可能没有办法在短短一两天内实现。原来已经使用过的qmail/cdb方式，由于需要手工添加用户，用到动态网站方面，会大大加重管理员的负担，变得难以接受。

这个邮件的基本要求是：多域，有quota，有smtpauth，能够兼容目前数据库的帐号，有webmail以便用户自已管理密码，支持pop3。要求看似很简单，但是实际上不容易。使用postfix方案，在webmail上遇到了重大的困难，同时，还没有算上它不能采用数据库目前的帐号。它的数据库方案，将多个域存入数据库，不符合我的设想，这将意味着每一下收发邮件（包括垃圾邮件）都会访问数据库，每日将达百万之数。我说的数据库方案只是使用现有数据库表中的帐号，理想的情况下应该只是一条sql的区别。但显然它没有达到这个程度。

qmail的情况类似，而且还有一个更麻烦的事情，在fedora上ucspi编译不通。maildrop也不行，但ucspi通不过就很麻烦了。最后，还是简单地本地开放邮件就算了。整体性方案，光装现有的软件是不行的，需要有针对性地作开发，是一个比较大的工程。

2006-03-15T17:10:00.000-08:00

近来alexa的统计相对下跌,而实际访问量却是节节上升,让人有点摸不着头脑。从显示的情况看，几乎就是凡作弊的都不会跌，而不作弊的都跌，我们就跌得最多。目前唯一能做的就是清空本身的访问，看看alexa会有什么反应。如果方便，顺便了解自身员工的工作权重是多少。

2006-02-03T05:56:00.000-08:00

近来的硬件有点难办。上一次结束了旧公司时，留下二三十台电脑，好的坏的都有，难以分辨，但总的仍是好的占多数。由于估计很长时间用不上的，再说这些电脑卖出去不太值钱，何况所有权当时也没有分得太清，因此，就把不能用不好用的装起来准备处理掉。而把相当较好的把各种配件全部分门别类放起来，其中包括内存。

这样处理的理由，是由于目前一般公司中真正需要的电脑只是简单的文档处理，和简单的服务器使用，撇开员工偷工聊天玩游戏看电影的需求，实在旧电脑是绰绰有余的。如果估计不错的话，新开公司时，可以省下一大笔电脑购置的费用。由于大约有三分一左右的主板是废弃的，因此就变成了内存甚多的情形，我从来不担心缺内存。

但近日的情况令人费解，这批主板、CPU、内存先一段时间是难以稳定工作，前一天工作的主板突然出现轻微短路路宣告罢工，经初步维修后变成严重短路无声无色，看上去凶多吉少。本来是买长城的原装服务器的主板也问题多多，内存认不全可以说是BIOS的设置，但是不知是键盘接口问题还是主板报错，总是显得断断续续的，这个问题不解决，等于没有用处。

另外一些主板倒是可以工作，但就是只认128内存，就算是整条装512M插进去仍是只认128 ,最后，最不好思议的是，手头的SDRAM内存似乎是全部坏了。这些SDRAM目前已经买不了也不打算买，只是内存如此坏，包括前面的故事，都是多年DIY电脑以来从来没有见到过的。

无法解释，不合逻辑。只能说目前的硬件设备报废比例比几年前要高得多。而由于这样的变故，就令手头的故事完全更改：内存变成严重不足了。同时为了避免主级服务器主板不受传染，不得不确定服务器主板和内存与旧板旧内存隔离。这样，处理起来就更显得困难了。

2005-11-18T18:05:00.000-08:00

Alexa目前排名靠前的网站，可以说大部分是通过专门作弊实现的,没有相应的应对措施仅凭内容添加和手工操作，极难有效抵消这种作弊形成的差距。目前主要是看看正常和较正常的措施可以达到的效果程度，最终确认需要的应对程度。陈方面实际上是推卸责任，一方面说功能没有可用，另一方面就说alexa没上去，再就是左右干预，所以把alexa搞上去，也可以争取到更多的操作空间。
可以肯定的是，目前alexa更多是依靠我自已，这班子同事是不是真的有心，是谁也不知道的。

目前最欠缺的是recach项。这一面估计与aid有明显的关系，同时，大概与ID也有一定的关系。可以肯定的是网站员工的数量，与之有直接的关系——但也是在肯定装上alexa时才说得上，实际操作表明，中国员工的素质一般比较低，就算是这一条，也很难保证的，因此，一般仍是与站长以下成员的数量有关系。如果有着统一的TS部门，统一完成装机的话，效果也会不错。另一项明显的就是机器作弊做成的reach量，这条是最难克服的；除非使用同样的应对措施;这需要做实验。

周末的ip数有所增加，却不见得是aid有所增加；估计是由于各个员工回家多少上上网，但浏览量不大，因此51yes统计是增加，而实际量并没有增加。因此周末的排名跌起来也是说不清的。目前要搞清楚的就是更换AID会有什么样的作用机理和程度。

晚热机由于刷新频率低而且低价大，效果值得怀疑。何况，晚刷新使用同一个AID，也很容易诱发清零机制。因此，除非使用特殊程序，否则晚刷新是不可行的。自动刷新目前由于浏览器经常停止，目前也无法准确判断它到底进行了多少次刷新。但估计由于操作空闲时间比较多，如果这里利用起来，是会有较大的效果。只是，到目前为止，已经有几天的操作，并没有看到很明显的效果。在添加后，可以准确知道访问了多少次，因此，周三周四由于中断次数较多，实际刷新不算多，也是有可能的。

2005-11-05T07:06:00.000-08:00

好象今天没有完成什么完整重大的工作，不过，实际上全天都没有闲着，做的是也许是非常重要的一件事情：SEO。这件工作本来不应该由我来做，但经过这段时间，发现还是自已来做好一点。唯一不能确定的就是添加文章有没有现实的好处。这一段时间看来，在各个文章中的链接没有有效地出现在反向连接中，出现的更多是内部连接，这的确是有点令人奇怪的。

blogcity自从给封了后，事实上已经没有开发的价值，特别是在GOOGLE违约后。不过它的 PR升得的确相当快，可以说是最快的，原因何在，还没有什么idear。难道真的是由于我的文章的作用？也许吧。如果说它升得快，那么另外的三个帐号并没有出现提升，似乎又与该说有所不同。所以，这是一个应该值得研究的现象。新近发现，居然连dmoz.org也给中国政府封锁掉了，这帮子真是杂种。由于zwwwxy/zcoral两个帐号的PR升得很快，所以这两个博客就值得再次加以利用了，特别是zcoral，明天可以再去在dmoz和javablog上登记一下。

blogcn 是完全放弃的，这个站点技术和策划都是太差。重新开始培养一个SEO点又显得完全没有必要，所以就用现在这种方案，最合适。做这个工作是为了把SEO的网址记录先做起来，另外，李继的SEO应该继续了。另外，我发现跟在有一定的PR的网页后面评论，会得到更多的反向连接。上周的周六访问值下降得很严重，而今天的下降就很少，alexa还很高。与上周日的情况相似。

2005-11-03T16:54:00.000-08:00

昨天培训胡的是时间还多于我自已做，今天不能再理他了，而且他的论坛还没有做好，效率和能力都不见得如何。其实聊天工具开着，就是有这个问题。陈的倒是什么都有说话，站着说话腰不疼，尽显着自已高明，就这话。本来呢，我这里最需要的是老实巴交的蓝领，也只是陈蔡的干预再招了胡，其实反而还不太好用。

2005-11-02T17:17:00.000-08:00

前两天的计划把归档搞成几个小栏目的静态发布，最后搞了差不多两天，比预计的时间多得多，主要是大大扩展成了批发布的功能了。这是一种相当于翻页的解决方案。算算下来，工作量也真是不少的。后面要做什么，有点忘记了。

论坛的功能需要从头开始修正，但当前需要先搞搞那个发贴不行的问题；修正是一个大工作；
其次是科室的别名显示；
登录流程修正；
然后是把comments的功能拿进万维；
店铺那个如果胡下不去还要想想，不过这里我觉得该说的已经全说了，如果再说下去，就是我自已做了。
招聘；
做一个健康网；
新闻自动抄录器；
分类查询；
同时在线查询，可能涉及到dababase之类的修改，这类应该有足够长时间的验证使用，因此应该在下一版进行。
SEO连接组；
document.sit校正

动态网站针对静态网页的分页发布功能实现；正序的翻页还不能使用目前的静态分页方式完成。目前的静态框架本质上是定期由管理员按指定数字完成发布，这不适合动态更新的翻页显示。
黄页的数量还不算多，不是很急于改静态，另外，改静态的话，需要修改网页结构以便显示细节内容（document.write 的连接和使用弹出的jsp会比较有效）。总而言之，目前的量不足以专门作静态发布，反而是使用模式要作大的修改。这里涉及到这个业务有多大程度上需要销售支持，以及业务模式的认可程度有多大？总之，这是向后推的。

分页依次要达到以下的目的：一是搜索引擎容易索引收录；二是易于操作，三是系统操作少，四是可定制页面。目前很可能不能全部满足上述的要求。由于静态页面不能适应请求参数，因此，分页意味着要对多个分页完成静态发布；同时，保留各个分页下的索引有效——blogger本身也没有能够提供，而 blogbus的分页功能显然是失败的。

假如分页的数量是对大量的内容进行的话，极困难的，似乎需要对模板解释进行大手术，这又涉及到模板功能的升级。使用动态网页解释的话，就极难把它的定制的框架带入。所以实际的解决方式大概有两种比较有效：
１、放弃第四个要求，即可定制页面；
２、另一个方案是使用单页－archives的功能，这就类似于blogger的方案了。
以上两个方案同时提供的可能性也是存在的。更灵活的功能必须等到import的功能完成后才能提供。

目前应该做seo连接和ALIAS,document.site校正是这次升级前要做的事情

2005-10-27T07:48:00.000-07:00

把动态内容发布成静态网页实际上是一个两刃剑。最关键的就在于，实际上目前最鼓励人的访问读数，很大程度上是由于搜索引擎而不是真的由访问者访问而得到的计数。因此，一旦把搜索引擎的计数完全排除，只怕就是自已的死期了——一般说来，业务部门的家伙和投资者的心理承受能力是承受不了这种落差的。象 blogbus，计数上显得非常少，这样，我自已也没有太大的兴趣再写下去，只怕别人也是这样的，与其如此，不如象blogger一样不加以提供。而放开不加以限制，象blog.csdn.ent，就经常给搜索引擎冲垮。今天，我甚至不得不把yahoocn，也就是原来的3721也禁掉，真是不管三七二十一了。

这里需要进行再一步协调：原来把包括翻页也转换成静态网页，是为了最可能扩大搜索引擎的收录面；现在，这部分扩大收录的工作由发布的静态网页负责；而原来的翻页则重新回复到不欢迎跟踪翻页的设置（？？？）。

论坛的翻页实际上没有太大的作用，唯一的功能就是让搜索引擎可以找到从前的贴子。我想，作为 archives会更好。而当前的应该避免。

仍没有非常清晰的如何令博客的文章可以得到强计数的功能，而保留静态网页形态的方案。除非，是在博客网上增加一个分类文章项目。这样可以把它嵌入本网的页面，通过一个连接，把它的页面引过来，从页达到既计数又主要是使用静态网页的目的。

其次，对于大量的同类静态网页象产品编列特别是文章，使用静态发布固然可以节省系统性能；但是一旦更改涉及的工作量也是很大的，因此，象 count的功能，唯一的办法就是尽可能地转移出来。使用专项count完成内部外部的count似是最合理的。

2005-10-07T18:30:00.000-07:00

回到动态网站了，这里需要考虑进行程序上的合并，难度不算大，但需要考虑原有的后台连接都仍是可以工作的。其次是所有的后台程序连接都要带上 dochid，同时，由于所有的程序文件已经转为公共，这个目录也成为一个可以外挂的目录了。总而言之，这里就成了另一个大博客。这个过程需要大约一天左右的时间。大概应该在系统批发布后再进行。事实上，这是检拾动态网站的工作，耗时，其中也包括了帮助部分，还要考虑 lauragao的理解能力有限，需要应付这样那样的疑问。所以目前还是暂不处理为好。

对于搜索引擎仍然没有什么明确的解决方案。刚刚的，开发服务器给一个北京的搜索引擎出垮了，而且是连接冲跨，连apache也当掉。再次提示需要对搜索引擎进行处理。但是，除非把动态响应的部分静态化，实在没有什么更好的办法。如果既要使用动态响应，又要实现对搜索引擎强度的限制，唯一的办法就是就是建立一个缓存核对IP的记录。

使用xmlmemorybase目前虽然可用，但从长久看，却不见得如此，主要原因在于，这个memorybase需要改成每次读写的操作，同时，目前没有进一步的如是否存在等功能。因此，不太适合用于这个搜索引擎的核证。目前的时间也不足以完成这个dabase系统的升级。另外，按最后时间段的算法的确不需要一个单独的计时器，但是，同时也会让许多搜索引擎的访问得到空值，难说物有所值；与此同时，又不允许增多一个计时器。

因此，完整的解决方案是有关联性的，应该是做一个全局性的计时服务， cron,然后，把目前的基表转换成每次读入并可以记录它的某些属性；对于simplebase需要更详细的考虑。这个计时器同时可以用到这个搜索引擎的核证上。它的原理是：建立一个集，记录下每一个时段的访问IP，隔一段时间就清空，一个时段可调，令存储的IP数不多于千，系统强大的话可以达到万以上。如果IP已经存在，就把它的计数加一，一个时段的访问超出一定限额，就拒绝访问。这样，可以很容易地发现搜索引擎。预先建立一个已知搜索引擎的地址列表，如果遇到超数的IP，就检查一下它的pattern(regular expression)是不是已知中的某一款，如果是大款，GOOGLE，BAIDU之类，就放行，否则，就象上面所说的把它禁止。显然，完成一个公用计时器，是上面的关键，把它与database的升级结合完成，效率会更高，不是今天了。

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

另外，发现了另一个象51yes的统计网址，看来这类网址还特别多呢

2005-10-07T06:35:00.000-07:00

看来，除非把网页变成静态，否则减少搜索引擎的冲击无从谈起。对搜索引擎进行判断是困难的，而且，既然打算变成静态页面，又何必另外再作一个判断呢？使用script-iframe方式只对静态嵌套的页面有用，对于目前是动态的网页来说，并没有太大的用处。

一旦转化成静态网页，对访问的记录可以采取实时或非实时的方式进行。假定目前的负载主要是由与数据库的交互形成，目前没有必要弄成非实时的方式，采用实时记录会显得比较地简单。剔除搜索引擎的计数会比较简单，只需要把visitor转到计数页面即可。对于由于不同的iframe导致的重复计数，唯一的办法就是与页面独立出来搞成一套计数器。

2005-09-20T08:11:00.000-07:00

ultraedit/editplus添加了字符自动转换的功能，但反而弄得我们事情不好办，说不清什么时侯就会出现一些乱字符消除不了。昨天弄着弄着，忽然整个界面消失了，无论如何出不来，而查看IE的源码，实际上所有应该写出的代码已经全部送到缓冲区——天知道是什么原因。所以今天花了点时间把东西全部换成英文版，原因好象有点理解了，但根本的解决方法，实际上还没有找到。

电话太费钱，IM工具太分神，出了个skepe，效果不错，把手放开不拿着电话筒的感觉不错，习惯一下后，不会对工作产生什么大的影响。QQ，我看是应该在办公室停止的。原则上，我根本不相信使用QQ的有可能真正把主要的心思放在工作上的，MSN也只是五十步笑一百步。办公室里宁愿花点电话费，也不应该放任QQ泛滥，否则，裁人吧，反正人留着也不会真正搞工作的。

把发布的事情做完了，小的调整还有不少，不过当拖欠的事情放下后，反倒是可以集中一下精力都博客功能的升级和完善上了。

2005-09-17T01:55:00.000-07:00

忙到今天，仿佛有点失去了准绳，不知道该干点什么。就以目前应该升级的事情来说，要干的似乎很多，又似乎什么都没有绝对的必要去干。但无论如何，争取到把整个博客网建立起来，这是一个胜利，假如我自已的博客网是使用体现的实现，却由于政治原因只能用到极少数的用户群，自已还不能用，实在是一个浪费。

由于大方向明白，小的细目太多，因此，最合适的做法就是成批地局部升级，这样的话，可以较为明确在把一批的内容细细搜括一遍。目前把系统下载到本地，就是为了完整地实现一次检测，最后完成升级。

我自已的个人博客群构建是一个庞大的业余工程，能否赚钱不是目前要考虑的，主要是实现一个自已的发表目的，和社论平台。但工程很大，业余的时间其实很少，这样的话，就非常难以兼顾了。

2005-09-02T19:19:00.000-07:00

主工作机看来是中了病毒。这几天不同的程序不断地出现错误，但直到病毒文件不能更新，我开始怀疑是中了病毒的原因。而且，这个window时间已经很长久了，系统盘中有着大量的无用文件也无法清除；中了265陈桥五笔这样的流氓软件也无法完全清理（除非全盘扫描，我也不想），硬盘却反而只乘下两三百兆，我一直打算把它重新来一次算了；趁着这次，就把这个windows扔掉了。实际上由于目前大部分工作是在网上完成的，因此真正需要安装的东西其实并不算太多。而且，先前实际上已经有一个现成的windows可以使用，倒是需要把实际上没有用的安装软件删除，以免占用硬盘空间。这件事令我上午的时间被占用了一点，应该说是效率降低了，实际上我打开另一台电脑后，工作倒是基本上可以继续的。我一向很小心，唯有这次为了装那个googleearth必须升级 directX，微软说的是盗版，只会在网上载别的，没准就是这样中的毒。

早上装修的那些个讨厌鬼提早到七点多就开始丁丁当当，晚上我睡得不算沉。幸好，在和几个朋友一起和静君过了一下瘾后，尽管上下丁丁当当的，倒也算再补充睡了一个小时左右。这一个小时就足以让今天的精神感觉还算是riseup。

累累地算起来，其实博客和动态网站还有不少事情要继续干的：
1、留言要做的；
2、后台管理要用的；
3、可识别的移动是要做的，
4、帮助是要写的；
5、翻页要完成的，如果需要用到科室的升级的话；
6、广告功能也是要完成的；
今天就先做点轻松的，通过博客写帮助。本来有打算使用动态网站更强大，不过这需要花时间设计页面，所以罢了，还是先用博客吧。

2005-08-30T08:04:00.000-07:00

目前的博客能够使用的不算太多，而且也是不算太稳定的，今天这个能用，明天那个能用，按这样的情况，我不太相信中国真正的博客能有多少个。因此，目前的操作手法不是着眼于某个博客的发布，而是内容的可以存放。只要把内容存在两个以上的地方，就算是可靠的。博客本身的发布，需要作为专门的个人工作去完成，否则占用工作时间显得太大了一点。

2005-08-30T07:55:00.000-07:00

昨天开了一天会，晚上主要是分析那个blogbus到底功能达到了一个什么程度——初步结果还是正面的。今天上午去看牙医，中午休息了小半午，但下午仍没有兴趣开始工作；总是觉得休息还不够，但睡觉又睡不着；又看了一下新闻，晚饭后打算放松一下，去洗洗头按按摸。谁知常去的那家发廊原来关了门，转去另一家稍大一点的，钱收得不算少，叫个男孩洗头，也就洗头而已，洗完就把我轰了出来。转了一条街看到有一家按摸店，不妨进去摸摸，小女孩倒是挺热情的，关上门，我闭着眼睛等了半天没有动静，却觉到有温柔暖玉压上身，有人有扯我的裤子。一看，小女孩已经剥得光光的……原来如此，我要的可不是这种服务……就此开溜，回到家里老婆问：“怎么这么快？才二十分钟”……无言以对，罢了，开始工作罢。

轻跑了一下，才想起周日中断的是在什么地方，应该回到动态网站那里，提供默认的或自寻找的模板，以便简化发布工作。不过今天也已经挺晚的，暂且休息一下，上上博客，就拉倒罢。

2005-05-26T02:13:00.000-07:00

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

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

2005-05-25T00:19:00.000-07:00

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

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

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

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

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

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

2005-05-24T01:54:00.000-07:00

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

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

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

2005-05-21T19:56:00.000-07:00

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

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

2005-05-20T18:50:00.000-07:00

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

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

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

2005-05-19T18:30:00.000-07: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-19T08:25:00.000-07:00

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

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

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

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

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

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

2005-05-18T22:23:00.000-07: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-17T05:58:00.000-07:00

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

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

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

2005-05-15T19:21:00.000-07:00

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

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

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

2005-05-15T04:44:00.000-07:00

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

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

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

2005-05-12T19:45:00.000-07:00

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

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

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

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

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

2005-05-12T18:34:00.000-07:00

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

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

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

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

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

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

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

2005-05-09T18:18:00.000-07: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-09T06:49:00.000-07:00

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

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

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

今天三分二左右的时间实际上是对tagfile/jstl学习

2005-05-07T18:57:00.000-07: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-05T18:16:00.000-07:00

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

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

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

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

2005-05-04T17:13:00.000-07:00

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

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

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

今天重点在CP，观念的重大突破

2005-05-03T20:06:00.000-07:00

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

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

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

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

小搞不如大搞，要么就不搞

2005-05-02T16:54:00.000-07: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-01T19:19:00.000-07: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-01T00:35:00.000-07:00

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

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

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

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

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

晚

2005-04-30T09:37:00.000-07:00

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

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

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

仍未开始继续中断的工作

2005-04-29T17:50:00.000-07: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-28T17:52:00.000-07: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-27T17:36:00.000-07: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-26T16:55:00.000-07:00

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

asoka的任务

2005-04-26T06:36:00.000-07:00

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

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

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

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

2005-04-25T23:00:00.000-07:00

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

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