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

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

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

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

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

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

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

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

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的无知搞一些政治小动作。其中也夹杂着我对这 家公 司成员对于技术上的无知和对技术人员专业能力缺乏尊重的反感。所以对于她的所谓的需求，除非我自已是百分百同意，否则根本不想搭理的。

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

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

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

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

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

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

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

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

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

因为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

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

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

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

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

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

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

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

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

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

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

深入尝试使用tagfile

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

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

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