— 路线图 —

个性化阅读的算法案例（一）：如何确定一篇内容的中心点？

    摘要：很欣赏国外的好文，结构层次和逻辑都表达得非常好。本文侧重于实践中分析推理，系统性方面就尽力而为吧。这种情况在很多网站上都会出现，有一定的普遍性，在此只是想反映出，个性化导读的算法不容易实现。在此基础上，还提出了自己的改进意见。   《5疑犯持枪劫车后遁形 数十警员搜捕两小时未果》是网易的新闻网页，在它页面的中间，有几条TAG和相关新闻： 关于 荒地 窝头 治保 的新闻 五治保员执勤被砍 一人肝部遭重创 五治保员执勤被砍 此处阅读全文

发表于 @ 2006年10月27日 12:50 AM | 评论 (4)

域名不要随便换，很大的教训（改：域名不好还是要换，但要注意过渡）

    摘要：曾经建过一个网站，在5月份的时候，觉得域名不好，于是就换了个新的域名。旧网站保留，但不再更新；新站建设的时候，总结了旧站的不足，程序做得更好，可惜在7月份时，被百度封了。   不曾想过，旧站在网友中的印象会那么的深。近两个月，不断地发现出指向旧站的反向链接，很多人收藏了旧站；还不仅仅是这样子，今晚，竟然发现了网友在百度里搜索旧站的名称，不只一个，好几个不同省份的 IP！   看到这样，郁闷大于高兴，要是一直建设旧站，那效果会比现在好得多！这是个教训，今后，一定要多点知道网站用户的想法和使用习惯。这样子，才可以在网站的 建设中有的放矢。不多写了，记在心上。    （全文共942字）——点击此处阅读全文

发表于 @ 2006年09月23日 2:22 AM | 评论 (1)

很高兴，程序测试的成绩不错，记录一下

    摘要：今天测试了一个程序，服务器接受60个并发的访问，包括有数据库查询与下载文件 (1586k)，服务器CPU的占用率不超过40%（平均来说）。这个数据意味着，设计出来的程序，服务器每天可以容纳接近10万个用户的访问。   其关键是，尽量减少服务器的数据查询次数，以及连接次数，这样可以尽可能地减少服务器的通讯压力。   过几天，等数据更新功能做好了，再做一次更大规模的测试，数据查询 + 更新 + 下载，这样能更多地考验服务器。    （全文共371字）——点击此处阅读全文

发表于 @ 2006年09月13日 2:53 AM | 评论 (0)

网络上的“口碑相传”

    摘要：

美丽旧世界《附着力因素的产品解读》谈到《引爆点》中“附着力因素”，摘录如下：

 

此处阅读全文

发表于 @ 2006年09月08日 7:53 PM | 评论 (0)

发现DONEWS BLOG的一个BUG

发现DONEWS BLOG的一个BUG：当提交了一篇文章，进入文章列表页之后，这时候如果刷新该页面的话，会同时生成多一篇相同的文章出来。虽然这种操作很少会出现，但程序应该也需要避免才对。

====================

update: 再次尝试一下TRACKBACK 一个梦与“怒胜思”

发表于 @ 2006年05月15日 10:58 AM | 评论 (0)

小试TRACKBACK

这个测试没生效，是DONEWS又封了TRACKBACK功能，还是在修改程序的缘故呢？难道是做得不对？但我是按“大鱼”BLOG里的讲解做的，真不解

选择 —— 我这样看“技术与市场”

看KESO的网志，评论里有不少TRACKBACK，但都是非DONEWS的。

发表于 @ 2006年05月09日 9:04 PM | 评论 (0)

P2P用户统一管理设想

    摘要：

    用户管理是每一个系统的基本功能，其架构的设计可以较为简单，只需要userid与password两个项目，有注册、登录、注销登录的功能即可。不过在很多时候，由于实际的需要，用户资料会要求更多的项目、资料注册时加入随机验证码、userid与password的名称限制与合法性检测、password MD5加/解密、用户群组/等级、注册时需要邮件验证、权限控制、在线检测、用户活动历史记录、用户定制等，甚至是通行证的使用形式。
    当前，我们计划将原有的三个系统在P2P的共同基础上整合成为一个WEB体验中心系统，再以Torrent技术优化系统。在这个系统中，用户可以分享到P2P技术带来的便利，从资料查找、软件下载到媒体欣赏等方面都有一体式的体验感受，而且，还可以获得Torrent的最新资讯，参与论坛活动等等。这样的计划，就需要我们设计一个比较好的用户管理系统，它能够让用户们可以自由地在几个分系统（既有客户端软件也有WEB端操作）之间进行活动，而且，还能够适应日后可能会出现的PRO高级用户的情况。
&nb    （全文共3539字）——点击此处阅读全文

发表于 @ 2005年11月01日 10:42 AM | 评论 (1)

从 10 秒到 1 秒

    摘要：

      前几天，我接手了一个使用 DELPHI 开发的项目，其中，较迫切的任务是需要解决原有几处代码的性能问题。其中，有一处代码较为典型，因此，特地将其详细问题、解决思路与相关想法整理出来，供大家参考讨论。

      在设计进行数据处理工作的代码时，我们常常会发现有这样的需要：将一些数据按树状的样式显示到屏幕上，方便用户查看或其他操作。举例说：我们有可能想在TREEVIEW控件中显示地区，然后将隶属该区的供应商加入到对应的地区中；或者又是显示客户，然后将隶属于该客户的订单号加入到对应的客户中（这是简要的流程，在应用的时候，会有各种变化，受到其他的业务规则影响——而往往又是这些东西迷惑了人们）。
      在上述的项目中也碰到这样的情况，原先的代码按下面的思路进行设计：首先，将“地区”数据查询到一个数据对象中，并通过迭代运算将该部分数据加到树图上；然后，分别    （全文共7870字）——点击此处阅读全文

发表于 @ 2005年11月01日 10:40 AM | 评论 (5)