标签： Waki-Blog

Blog更换服务器与博客平台

出于网站维护与运行需要，我更换了服务器和域名解析。

当您看到本篇Blog的时候，说明您已经在访问新服务器了。

正好利用这次换服，我决定将Blog平台从我自己的Waki-Blog迁移到Wordpress。

Blog的新地址：http://dgwxx.com

这个老Blog将作为点点回忆一直存在下去，不会删除。但也不会再更新了。今后请访问新地址。

对Blog的前端略作改进

昨天大概花了一上午加一晚上的时间对Blog的操作性和细节进行了小小的调整。Waki-Blog的核心代码已经将近一年没有进行过重大的调整和维护了，对于一个人从零开始建造并维护这样一个工程我自己都有点惊讶。

昨天主要改进了三个地方，两处前端一处后台。

1.在页首添加了工具栏，改善操作不便。

此前Blog的功能链接我都放在sidebar里，但目前这个主题再放在sidebar里的话怎么弄都不好看，于是只好放进了footer里。但功能链接放进footer里所带来的一大问题就是操作非常的不便。这次就在header里增加了一个工具栏来弥补这个缺陷。目前的设计是：
·在登录前，工具栏显示“登录、注册、移动版”的链接（目前我关闭了注册，所以看不到注册链接）。
·登陆后根据用户权限自动显示用户可以进行的操作。
·页面载入完成之后，工具栏从不透明渐变成70%透明（先通过透明度渐变动画提示用户工具栏的存在，然后淡出其在视野内所占比重，让用户的注意力重新回到内容上去）。鼠标移入工具栏区域后恢复不透明，移出后恢复透明。（一切都拜jQuery这样一个便利的东西所赐啊……

2.美化了Ajax登录窗

不多说了，只是微调了一下CSS和HTML。

3.改进了JavaScript载入的方式。用php将后台7个.js文件(225.7kb)整合、打包、压缩、缓存、输出，压缩后33.8kb，只消耗一次HTTP请求。

此外，从去年起我就决定在此后的前端中只在最低的水平照顾对IE的兼容性。只保证IE浏览下的排版和可使用性，不照顾任何IE的美观需求。因此，透明、圆角、覆盖等特效一概不保证在IE能够顺利使用。不是我抛弃了IE，是时代抛弃了IE。

调整了Waki-Blog的编辑器

Tiny MCE

说到编辑器，以前我一直以UBB编辑器为主，HTML编辑器纯属为了应付XMLRPC接口必须支持HTML模式这点而加上去的附产物而已。后来做性能评估的时候才发现基于正则的UBB解析代码对执行效率影响太大，但整个Blog程序从最初开始就是按照UBB为主的思路设计的，再加上已有的几百篇UBB博文，所以就一直没改。

前些天刚好有了时间，就简单改了一下程序，把默认编辑器从UBB换成了Tiny MCE，把程序中的Tiny MCE更新到了最新版本，看了看官方文档，详细配置了一下各个参数（以前一直用默认），把WordPress的Tiny MCE皮肤修改了一下一直过来（说实话WP的Tiny MCE皮肤的CSS有些地方写的真有点那啥……）。这下清爽多了。

Tiny MCE实在是一个功能强大的编辑器，难怪WP也用它。不过令人有些头痛的是，它实在太大了。只算核心代码，不pack、不压缩有300多K，压缩之后也有100多K，用gzip压缩之后也有80K，这还没算上插件和无数的周边代码、图标、CSS。初次打开或者删除缓存之后重新加载要好长时间。怪不得译言的编辑器麻烦不断（笑），的确是一个不好驾驭的家伙。

下面附带我的Tiny MCE配置代码：

tinyMCE.init({
mode : "exact",
elements : "message",
width : "500",
height : "300",
languages : 'en',
theme : "advanced",
skin : "wp_theme",
plugins : 'safari,inlinepopups,emotions,advimage,advlink,media,fullscreen',
theme_advanced_buttons1 : "emotions,formatselect,fontsizeselect,bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,justifyfull",
theme_advanced_buttons2 : "bullist,numlist,hr,charmap,blockquote,image,media,fullscreen,code,|,forecolor,backcolor,link,unlink",
theme_advanced_buttons3 : "",
theme_advanced_toolbar_location : "top",
theme_advanced_toolbar_align : "left",
theme_advanced_statusbar_location : "none",
theme_advanced_resizing:"1",
theme_advanced_resize_horizontal:"",
dialog_type:"modal",
theme_advanced_blockformats : "p,div,h1,h2,h3,h4,blockquote,code"
});

WakiAAS反垃圾回应系统运行5个月技术统计

WakiAAS，全称Waki Advanced Anti-SPAM System，是我写的一个基于PHP的反垃圾回应系统。可以提供基于各种垃圾回应特征的过滤功能。这个系统自开发到测试断断续续持续了半年多，自7月份开始正式上线负责我的Blog的反垃圾回应功能以来已经经过了5个月零4天，这期间共捕捉垃圾回应176条，漏捕5条，错捕0条。今天简要统计了一下WakiAAS这小半年的工作情况。

七月：51条（漏判5条）
八月：6条
九月：20条
十月：1条
十一月：81条
十二月：17条（截至12月4日）

除了八月份因为运动会关闭回应系统和十月份因为系统bug导致回应无法提交之外，垃圾回应的数量是逐月增长的。十二月估计有超过100条的可能性吧。
被拦截的176条回应99%为简单的英文广告，含有一至数条网址。
其余还有部分中文广告，中文广告采用人工发送。

发送目的分析
1.英文广告均含有网址，针对搜索引擎的可能性更高。
2.中文广告不含网址，但含有电话号码，针对访客的可能性更高。

发送方式分析
1.绝大部分发送都是通过机器人完成的。这点通过机器人陷阱和秒表计数器可以看出来。
2.有极少数英文广告通过人工的方式发送，这种SPAM的特点是机器人陷阱没有反应、秒表计数器时间较长。

反过滤特征
从日志观察，绝大部分垃圾回应在发送时有意识地采取了反过滤措施。反过滤手段主要有以下几种：
1.随机的虚假IP地址。
很多垃圾回应拥有完全相同的特征，但IP地址却显然是通过随机生成的。
2.在文本中加入随机字符串。
为了躲避相似性比较过滤器，稀释垃圾回应之间的相似性，几乎全部垃圾回应都在文本中加入了随机字符串。
3.模拟正常回应。
很多垃圾回应在回应中加入“comment”等有实际意义的单词、表情符号来干扰过滤系统，企图让过滤系统误认为这是一条正常的回应。
4.回避真实网址。
鉴于不少常发送SPAM的厂商的域名已经被列入反垃圾黑名单，目前的SPAM广告通常使用Blog、SNS网站、短网址服务、文件共享服务来诱导访客转到自己的真实地址。广告过滤者不可能完全屏蔽常见的BSP、SNS、网址缩短服务、文件共享服务的域名，这样会对正常用户造成不便。因此利用以上黑名单制度本身的缺陷，避免自己的域名因为黑名单被阻挡。

过滤手段与共同特征
由于目前尚未接到含有中文的垃圾回应，这里暂时只分析英文垃圾回应的过滤。
1.不含有汉字的回应嫌疑更大。
2.垃圾回应绝大部分采用机器人或人工大量发送，从页面载入到表单提交之间的时间差很小。发送越快的回应嫌疑越大。
3.垃圾回应中含有大量网址。
4.垃圾回应中含有大量相似的垃圾词，如“cialis”、“buy”、“online”、“viagra”、“levitra”等等。

Waki-Blog 9月24日更新

这次更新主要针对前台的几个细节进行了修改，并针对搜索引擎进行了一些优化。

  • 当用户试图阅读一篇不存在的blog的时候，输出HTTP 404头。这样有助于搜索引擎对于已删除文章的处理。
  • 通过识别搜索引擎蜘蛛的User-Agent信息，限制搜索引擎对一些页面的抓取行为，减少循环抓取。
  • 生成RSS的同时生成标准格式的Sitemap，用户可以将Sitemap提交到各大搜索引擎。目前该功能的效果还在测试中，将来或许会不断调整优化Sitemap的内容。
  • 去掉了留言验证码功能。

因为近期垃圾留言过滤系统的作用得到了验证，阻挡了99.9%的入站垃圾信息，为了加强用户体验，取消了验证码生成功能。我对WakiAAS有足够的自信。
此外，最近正在策划针对后台的一次修改，具体方案还处在构思阶段。

Wakiblog 2.1.1 080721

这几天针对blog系统进行了进一步调整，以下为要点：
1.针对数据库进行了小规模的压力测试。通过数据填充，测试了10000篇blog+单篇blog下1000条回应的效率。针对测试结果对数据库查询、索引设计进行了优化，解决了3个效率比较低的查询，目前还在不断观察、调整中。现在首页的查询和搜索的查询效率方面表现还不是很好。首页的数据库查询中排序工作需要扫描整个索引（虽然不是全表扫描，但也好不到哪去），我会继续想办法= =||
2.对BBCode解析方面进行了调整，修正了回应中BBCode解析的几个bug。
3.对前台的界面进行了调整，现在已经符合XHTML 1.0 Transitional标准了。

目前浏览器兼容性测试结果：
在Windows的IE 7、Windows和Mac OS下的Safari、Firefox 3、Opera 9.5中工作正常。
IE 6中会出现些许排版错乱，但不会影响正常浏览，但考虑到我的主要浏览用户群和Windows升级发放的进度，不会专门再针对IE 6进行修正了。
对开发人员来说真是没有比IE再令人头疼的浏览器了，你永远摸不透他的脾气……

Wakiblog v2.1.1

弄了三天的一个小“新版本”。
进行了如下更改：
1.大规模更改上传图片处理方式。
2.加入lightbox，大家现在点击一下blog中的图片，可以直接看大图（主要更新就在这）。
3.后台进行了一些细微的调整，修复了之前调整ajax结构造成的bug。
4.优化了ajax。

此外，最近持续遭到垃圾留言攻击，不过都很漂亮地被WakiAAS挡了下来，含有链接较少的列入了代审核队列，我一个按钮直接都删了，含有链接较多的直接被拒收（请看日志http://www.dgwxx.com/blog/data/log/spamLog_20080712.html），同时接收的正常留言一个都没误判。WakiAAS开发一年多来被证明有效，大快人心！

WakiBlog的Ajax新界面

今天将前些阵子用在WakiFile上的BlockUI特效移植到了Blog里面，现在登录、登出、修改个人介绍还有后台的管理的Ajax提示全部更改为BockUI的友好界面。
本来打算把留言也Ajax化的，但是考虑了一下，还是有很多困难（曾经实现了，不过有很多局限性，最终又回到了传统的表单提交方式。），于是只好放弃了。后来仔细想了想，表单提交方式…也挺好的shy。（puke这家伙纯属在犯懒吧）
最近不断地完善WakiFile，总结了一些经验教训，回来写成文章与大家共享。
此外，现在正在努力将WF和WB的开发环境转移到MacOS下面（Textmate确实好用），不过却在Bluehost主机的文件权限方面遇到了一些意外的问题……怎么办呢………question

Waki-Blog v2.1更新 即将结束RC

Waki-Blog 2.1已经运行了半年多了。这半年多进行了很多功能上和性能上的优化与调整。从今天起Waki-Blog v2.1开始进入功能特性冻结阶段，开始进行最后的debug和性能优化调整，结束之后放出源代码（叫了好长时间开源了-v-一直没开出来 囧）。
今天的更新主要针对javascript部分，并对程序性能进行了优化。
1.jQuery更新到了1.2.6，按照官方的说法，事件处理性能提升103%、CSS选择器提升13%、.offest()快21%、.css()快25%，并修正多个bug。
2.内置的TinyMCE编辑器更新到了3.1.0.1。
3.开始使用gzip对javascript进行压缩，节省大量HTTP流量。
4.调整沿用了将近两年的目录结构，程序根目录更整洁美观。

今后的打算：
当初开发Waki-Blog的初衷，是写一个能够运行在低版本PHP和MySQL环境下、兼容性优秀、高性能的Blog平台。不知不觉两年多的时间过去了，版本从最初的1.0发展到了现在的2.1，经历了更换模板引擎、独立开发反SPAM垃圾信息功能、重写后台等等重大的转折。
目前Waki-Blog在功能上已经是一个能够满足大多数用户需要、独当一面的Blog平台。单纯作为Blog系统来说，它的开发应该已经可以画上一个圆满的句号了。
至于今后的打算，我依然会不断地维护这个系统，直到我发现更好的系统来替代它。现在Waki-Blog的表现当然不够完美，它在性能上还有很大的提升空间，将来我会不断地发掘它的潜力，让它快些、再快些。
现在主要问题是，它的HTTP请求次数有些多。近期我正在通过将图片文件合成并通过CSS进行分割来减少HTTP请求数，此外，还可以通过调整Javascript的结构来实现减少包含的js数量。
继续努力！