让WEB程序员FT的5大需求
正如我之前提到过的，俺这个“老人家”，做web开发，已经好多年了。
回想起来，这些年的开发之中，可能大家都曾经碰过一些在技术人员看来，极度“BT” 的需求。实话实说，其实，这些需求虽然天马行空，惊世骇俗，可仔细想来，如果能够实现，也挺有意思的。
简单回顾一下这些好玩的需求，大概也是一件有意思的事情吧。
排行第5的是：在线人数。
其实这个并不是没法做到，比如，搞个session listener，这已经是标准的“在线人数统计绕行方案”。但谁也知道，这个特性就是一个摆设。第一，session有个过期时间，通常是半个小时，也就是说，你现在看见的这个数字，恐怕就是30分钟以前的。要真把它当回事，恐怕要坏菜。好在用户一般也比较好糊弄，培训一番Http的知名的“无连接”特性后，模模糊糊的给丫一个数字了事。对这个的进一步需求，一概打住，打住，坚决不允许联想。
排行第4的是：站内消息。
嗯，这个基本上是标配， 随便一个论坛社区什么的，没这个，你都不好意思跟人打招呼。咱们这帮哥们做起来自然也是标准做法。先整个消息表，什么title，body，state，from，to基本上就齐了，然后就是一堆crud。整一些界面，发送啊，回复啊，阅读啊，然后在一个base页面里面插入一堆每次都刷新的代码，基本上就ok了。跑起来也挺顺溜，发一个，刷新刷新，就收到了。反正web也是延时的，有了前面的教育，用户也不会随便乱想。不过开发之余，暗暗觉得不对劲，这不就是一个“Mail”系统么？莫非传说中的邮件系统就是这么实现的？至于性能问题，我们从来也会不担心，因为这就是一个玩具嘛，谁会拿他当真做邮件来使呢？
排行第3的是：访问统计
其实这个功能需求巨常见，相关的解决方案多如牛毛。俺见过最绝的办法是——用perl来解决。丫其实就是一定制的日志分析任务。定时跑一跑，跑完得到一个sql，命令行一执行，就搞定。这个功能可不能用“常规web思路”来搞，一带上数据库，你就死了，死得透透的。想想也是，每个pageview都要跑到表里面去来那么一下子，莫不是嫌机器太闲了？问题是，该数字的增长是“定时的”如果用户要求“实时”你恐怕要就坏菜。如果那样的话，就只能祭出缓存这个杀手锏了。要是一不小心，服务重启，就会发现很多东西的访问数都是整十整百的，嘿嘿，低概率事件，再说也是半夜偷偷重启呢，咱不提也罢。
排行第2的是：在线聊天
客户什么都想往自己的站点上加。什么在线客服啊，什么实时答疑啊，这些是最符合哪些浪漫主义半调子客户的口味了。其实这个做起来挺简单的。现在咱们有了ajax，要是没有，也就是整个隐藏的frame，刷啊刷，刷啊刷。可是，咱也知道，这个功能，也就是一花架子。人上100，立马歇菜。这样的商业机密，总要藏得深深的，唯恐浏览用户一不小心点上去。给客户演示的时候，咱浮光掠影的过一下就行，蜻蜓点水，重点强调什么帮助啦，邮件反馈啦，千万别在上面恋栈。
当当当，我们的冠军是：环顾四周
嘿嘿，玩过走telnet协议的黑漆漆的firebirdbbs系统的老人家，可能对这个词还有点印象。记得第一次听bbs老泡菜的客户人员提出这个需求时，差点没郁闷得死掉。其实，这个需求也挺简单的，说白了就是上述“在线人数”的展开版。可是，这不仅意味着所有的页面代码都要去更新某个表，更改几乎所有的前台显示代码。更要命的是，这个功能偏偏是要在一个大型的，巨多人用的论坛中使用。设计用户100万，换算下来，为了实现这么个微小的功能，一秒钟要处理100个左右的数据库请求，代价不可谓不大，可用户就盯着这个。后来一测试，性能不达标。没办法，只能耍花招，搞了一个内存数据库（关键时刻还是hsqldb大侠好使），单独劈一台server来处理这个功能。靠，累出一头汗，总算歪歪扭扭的过关了。
嘻嘻， 俺这里是抛砖引玉——从来就没有“BT的客户”，只有“更BT的客户”。欢迎各位达人随时补充。
另外，既然敢把这篇口水含量 90% 的文发在 Erlang-China，那也不是白发的，从 Erlang-Way 的角度来考虑，是不是又有别的思路呢。大家 free mind 一下吧。哈哈。
Comments
其实，说到底了，这些都是“基于消息”的web应用，不是么？
。。。。。。
Write a Comment