用过WordPress的朋友都知道Akismet这个强大的垃圾评论过滤器吧，如果要放弃使用WordPress，Akismet是最舍不得的东西。 现在好了，Akismet也能在其他框架上工作，现在我已经成功地让Akismet运行在Pulog上了。 —– 参考文章是：http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/ 基本原理是，利用django新的comments框架，注册一个“已评论”的信号，即在一个评论保存后，马上调用Akismet进行验证工作，如果是垃圾，则将is_public设置为False。 这套机制很灵活，首先不必对首先的Models和Views做任何修改，只要简单的加一个函数，并用comment_was_posted这个信号连接一下即可。 因为pulog的comments部分即是改自Django自带的comments，所以也就直接用上了。 下面是我稍微修改过的代码，实际上就在原来代码上面去掉了TypePad部分。 def on_comment_was_posted(sender, comment, request, *args, **kwargs): try: from akismet import Akismet except: return if hasattr(settings, 'AKISMET_API_KEY'): ak = Akismet( key = settings.AKISMET_API_KEY, blog_url='http://%s/' % Site.objects.get(pk=settings.SITE_ID).domain ) else: return if ak.verify_key(): data = { 'user_ip': request.META.get('REMOTE_ADDR', '127.0.0.1'), 'user_agent': request.META.get('HTTP_USER_AGENT', ''), 'referrer': request.META.get('HTTP_REFERER', ''), 'comment_type': 'comment', 'comment_author': comment.user_name.encode('utf-8'), } if ak.comment_check(comment.content.encode('utf-8'), data=data, build_data=True): comment.flags.create( user=comment.content_object.author, flag='spam' ) comment.is_public = False comment.save() comment_was_posted.connect(on_comment_was_posted) 需要注意的是，需要在settings.py设置AKISMET_API_KEY，这个需要在WordPress.com上注册帐户才能获得。 测试站点是：http://ldcn.org/，欢迎大家用各种垃圾评论去袭击它！ 下一个目标是实现WordPress即将拥有的新特性：threaded comment！然后就可以考虑换掉WordPress了～

Wow！GTK＋真是灵活过头了，C、C++、C＃、Java、Python、Perl……上述的语言都可以用来写GTK＋应用程序，现在，JavaScript（WebKit JavaScriptCore）也可以了！ 这个项目叫做：Seed。 —— 简单的说，Seed是基于GObject Introspection（GObject自省）的一个工程，通过它，可以用JavaScript来写GTK＋应用程序。一般用于在WebKit（GTK）中用JS进行操作界面吧。 下面是例子代码示例： 一、构造器 Clutter这个较新的工程也有绑定，不错！ timeline = new Clutter.Timeline({fps:60, num_frames:30}); 二、方法和属性 将控件的事件设置成Gdk所有事件 widget.events = Gdk.EventMask.all_events_mask; description = widget.create_pango_context(); 三、信号连接 这个信号的作用是利用JS的get_uri方法设置地址 browser_view.signal.load_commited.connect( function(browser_view, browser_frame) { this.text = browser_frame.get_uri(); }, entry); 四、定义新对象 喔！干净利落，比用C语言定义一个对象要方便多了！ HelloLabelType = { parent: Gtk.Label, name: "HelloLabel", instance_init: function(klass) { this.text = "Hello" // Hello labels always say hello. }, class_init: function(klass, prototype) { // Add a say goodbye function to all instances. prototype.say_goodbye = function(){this.text = "Goodbye"}; }); HelloLabel ...

今天009linjx朋友在留言中提到了“Myword”，我突然起来了这个项目！ 当初因为想背单词，又觉得ReciteWord一些地方不好，所以打算基于Reciteword的词库写一个背单词的工具。 最终还是写完了，却不想背了。虽然基本实现了我要的功能，但是代码和UI比较Ugly。 写这篇文章不是决定要开始续写Myword，而是趁此回顾一下自己学习编程以来，到底写过多少东西。 —– 第一个算的上“项目”的，当然就是经典的完成于大一第一学期（2007年1月）的“学籍管理系统”。此前从来没有写过超过一百行的程序，这个东西虽然简单，但是却让我才开始了解什么叫“编写软件”。 后来，大一的第二学期，没写过什么东西，倒是学习了点Linux的服务器方面的东西，还搭了个网站，它就是：linuxdesktop.cn 大二的暑假，我又开始编程了，这次定了个长久的编程计划，这个计划就是：Ubuntu Tweak。对于还仅写过一个简单程序的我来说，不知道写Ubuntu Tweak意味着什么。直到现在我才知道，坚持是最重要的。 后来又写过一些小东西，又接触了Web开发，但是主线一直是编写Ubuntu Tweak，因为能做好一个软件，这就够了。 回忆了一下这两年不到的时间里（从2007年1月到2008年11月），我撰写了一个页面，把我写过的、不论大小的项目都列出来。 2007年到现在差不多两年，怎么感觉这么长？因为我差点忘记自己写过的那些东西了，回忆了很久！ 访问：项目 | I’m TualatriX

Ubuntu 8.10发布好几天了，没有发生以前的那种“盛况”。怎么回事？原来风头都给Windows 7抢走啦！ 身为Windows的铁杆粉丝，想当年Windows Vista刚出预览版时就曾下载试用。这次怎么能错过呢？ 于是花了半天时间下载了近2.7GB的ISO镜像（build 6801），然后开始了Windows 7体验之旅。 话说Windows的硬盘安装一直做的不错，从最早Windows 98开始就支持直接把文件放在硬盘上双击就可以安装了。这次也是这样安装。 因为没有多余的分区，于是直接把许久未用的Windows XP升级到了Windows 7。 废话不多，直接用图表达。 Windows 7的窗口管理器（用Linux的常用术语）有了很大增强，实际上我想如果MS愿意的话，也可以弄个像Compiz Config Settings Manager的工具出来，并开放接口来实现更多的窗口特效。 我在想Windows 7窗口操作的增强仅仅是在Vista窗口的基础上增加了插件吧。 在Windows 7中，我们可以像Linux一样，把最大化的窗口直接拖下来，变成普通窗口。也可以把普通窗口拖到边上，然后决定是否最大化（其中有上、左、右三边可用）。 这个虽然Linux早已实现，不过Windows 7似乎做的更精致一点。具体精致在哪里去检验一下就明白啦！ Windows 7默认安装Internet Explorer 8，好像与IE 7没啥区别。不过我马上看出区别来了，哈哈，与我的部落格兼容性不好！ 我想这一定是IE 8的问题，因为小站在其他所有浏览器上都可以正常显示！ IE 8有哪里神奇的地方呢？当然有！因为它支持标签恢复！ 刚才我浏览几个网站，突然提示崩溃了，我郁闷了，以为整个IE要关掉了，没想到只是重新启动了一下其中一个标签。其他标签都好好的！ 哇，我的Firefox啥时有这个功能就好了。要等到Firefox 4吗？ 总之，如果IE 8对网页的兼容性再好一点（可能是Beta的原因），那似乎是一款不错的浏览器。 下面的截图展示了Windows 7一些基本系统组件，是计算器、扫雷、CMD、Windows Media Player 12和画图。 可以看到很多工具应用了Robbin式菜单，这个很不错。标题栏也可以嵌入有用的按钮了（据说GNOME也会有）。 其他没啥好说了，主题就是Vista样式的，比较精致耐看。但还是希望到了Windows 7正式版会有让人一亮的样子！ 资源管理器，据说Library很强大，类似于“虚拟文件夹”一样把类似的文件都组织在一块。不过Library的名字总是让我想到XX库、YY库。 Windows体验索引分，我的电脑有31分，除了图形以外其他都有4分以上。实际表现也比较流畅。不打游戏还是很OK的。 本来还想试试Superbar，不巧补丁总是打不成功。所以就没继续弄下去了。 Superbar弄成功了，试了一下，基本搞清楚是怎么回事了。老实说，Superbar是一个比较优秀的设计，与Dock相比可以说不想上下。Superbar不仅可以取代Dock，而且可以预览窗口，更可以通过特定的应用程序进行特别的操作。 如IE 8.0是支持多标签浏览的，在Superbar上，将会显示所有IE标签的预览，点击预览，即进入相关标签。而WMP的在Superbar上，即可以进行浏览歌曲、静音或其他操作。 真是不错的一个设计！ 个人认为，目前为止Windows 7的最大亮点就是Superbar。但是我想未来肯定会有其他较大的更新，毕竟现在还是预览版。 明年Windows 7正式版真的会发布吗？Linux要加油！

那天Jason Lee兄介绍我介绍了django-dynamic-media-serve以后，还没来得及用。 今天状态好多了，可以研究技术了，所以下载并试用了它。一用就喜欢上了，真是个不可缺少的好东西。 项目地址是：http://code.google.com/p/django-dynamic-media-serve/，可下载的最新版本是0.36，trunk是0.4的，不过还没正式发布。 下载后直接放在PYTHONPATH能搜索到的目录，就可以用了，下载是使用方法。 我把它所在的目录命名为：dynamic_media_serve，然后把之前的serve相关的都换成它，如： (r'^static/(?P<path>.*)$', 'dynamic_media_serve.serve', {'document_root': MEDIA_ROOT}), 然后就可以开始用了，我在MEDIA_ROOT/upload下放一张名为gnome.png，以普通的方式去访问，输入：http://127.0.0.1:8000/static/upload/gnome.png 图片出来了，是默认的全尺寸 这时，如果我要获得一张高度是320的缩略图，只要在URL后面加上?height=320就OK啰！ 同理，如果是要宽度是640的，只要?width=640就可以了。 当然！两者结合起来也可以！ 这只是最基本的缩略图功能，其他还可以压缩（用gzip传输）、改善品质和flickr形式。其他可以参考该专案的Wiki。 现在开始不用手动切图就可以拥有各种尺寸的图片了，不仅可以减少空间占用（磁盘＋数据库），而且它利用Django的缓存（从源码中看到默认启用了Cache），理应可以提升速度。虽然我没有测试过。 因为在第一次访问该缩略图时，Django首先载入默认图片，然后再生成缩略图，这时都保存在内存当中。当另一个用户访问时，就直接从内存获取就可以了：无论该用户访问的缩略图还是大图。 而如果手动切图，访问缩略图和大图就是一样的过程，默认情况下是不缓存的，除非你用Django的缓存系统。 现在就去改造blog系统！

终于用完全Django式的方法完成了Admin界面的图片上传与缩略图处理啰！ 什么是“django式的方法”，意思就是都是利用Django的类和方法来实现的（除了缩略图处理以外）。因为没做任何其他扩展，所以一些步骤还是需要手动的，比如把图片粘贴进文本区域（-_-#）。 进一步完善后，可以做一个比较自动化的界面来写文章了（像WP一样）！ 嗯！最近在完善相当早之前写的TXblog，打算用其来代替现在用的WordPress。 前天写到设计一个模型来存图片，要用ImageField和FilePathField。那天写完后经过反复思考，发现这样是不合适的。应该都用ImageField！ 首先来说如何处理缩略图，很简单，用PIL库就可以完成。下面的函数即把给定位置的一张图片处理为480宽度的缩略图（如果小于480才进行处理）。 代码高亮插件有点小问题，把“>”转义掉了。 from __future__ import division import os import Image def make_thumb(path, size = 480): pixbuf = Image.open(path) width, height = pixbuf.size if width &gt; size: delta = width / size height = int(height / delta) pixbuf.thumbnail((size, height), Image.ANTIALIAS) return pixbuf 下面是我设计的Media模型，image为图片本身，thumb将在重写的save函数中生成。与Post（即文章）的关系是ForeignKey，即一张图片必对应一篇文章，而文章不一定包含图片。这样设计还能使用Admin的Inline功能与编辑文章的界面显示在一块。请看后面。 还要提提如何手动构建一个ImageField。与CharFiled、IntegerField这类简单的字段不同，CharFiled对应Python的unicode，IntegeField对应int，直接写就可以。而ImageField对应的是ImageFieldFile这个Django自定义的类，所以一定要用Django式的方式构建。 ImageFieldFile继承于FieldFile，建立时需要对象本身，对应的字段和图片的相对路径。所以我就用下面的方法手动建立，并调用save来保存。 import os from django.db import models from settings import MEDIA_ROOT from django.utils.translation import ugettext as _ from django.db.models.fields.files import ImageFieldFile from utils import make_thumb from pulog.models ...

终于用完全Django式的方法完成了Admin界面的图片上传与缩略图处理啰！ 什么是“django式的方法”，意思就是都是利用Django的类和方法来实现的（除了缩略图处理以外）。因为没做任何其他扩展，所以一些步骤还是需要手动的，比如把图片粘贴进文本区域（-_-#）。 进一步完善后，可以做一个比较自动化的界面来写文章了（像WP一样）！ 嗯！最近在完善相当早之前写的TXblog，打算用其来代替现在用的WordPress。 前天写到设计一个模型来存图片，要用ImageField和FilePathField。那天写完后经过反复思考，发现这样是不合适的。应该都用ImageField！ 首先来说如何处理缩略图，很简单，用PIL库就可以完成。下面的函数即把给定位置的一张图片处理为480宽度的缩略图（如果小于480才进行处理）。 代码高亮插件有点小问题，把“>”转义掉了。 from __future__ import division import os import Image def make_thumb(path, size = 480): pixbuf = Image.open(path) width, height = pixbuf.size if width &gt; size: delta = width / size height = int(height / delta) pixbuf.thumbnail((size, height), Image.ANTIALIAS) return pixbuf 下面是我设计的Media模型，image为图片本身，thumb将在重写的save函数中生成。与Post（即文章）的关系是ForeignKey，即一张图片必对应一篇文章，而文章不一定包含图片。这样设计还能使用Admin的Inline功能与编辑文章的界面显示在一块。请看后面。 还要提提如何手动构建一个ImageField。与CharFiled、IntegerField这类简单的字段不同，CharFiled对应Python的unicode，IntegeField对应int，直接写就可以。而ImageField对应的是ImageFieldFile这个Django自定义的类，所以一定要用Django式的方式构建。 ImageFieldFile继承于FieldFile，建立时需要对象本身，对应的字段和图片的相对路径。所以我就用下面的方法手动建立，并调用save来保存。 import os from django.db import models from settings import MEDIA_ROOT from django.utils.translation import ugettext as _ from django.db.models.fields.files import ImageFieldFile from utils import make_thumb from pulog.models ...

终于用完全Django式的方法完成了Admin界面的图片上传与缩略图处理啰！ 什么是“django式的方法”，意思就是都是利用Django的类和方法来实现的（除了缩略图处理以外）。因为没做任何其他扩展，所以一些步骤还是需要手动的，比如把图片粘贴进文本区域（-_-#）。 进一步完善后，可以做一个比较自动化的界面来写文章了（像WP一样）！ 嗯！最近在完善相当早之前写的TXblog，打算用其来代替现在用的WordPress。 前天写到设计一个模型来存图片，要用ImageField和FilePathField。那天写完后经过反复思考，发现这样是不合适的。应该都用ImageField！ 首先来说如何处理缩略图，很简单，用PIL库就可以完成。下面的函数即把给定位置的一张图片处理为480宽度的缩略图（如果小于480才进行处理）。 代码高亮插件有点小问题，把“>”转义掉了。 from __future__ import division import os import Image def make_thumb(path, size = 480): pixbuf = Image.open(path) width, height = pixbuf.size if width &gt; size: delta = width / size height = int(height / delta) pixbuf.thumbnail((size, height), Image.ANTIALIAS) return pixbuf 下面是我设计的Media模型，image为图片本身，thumb将在重写的save函数中生成。与Post（即文章）的关系是ForeignKey，即一张图片必对应一篇文章，而文章不一定包含图片。这样设计还能使用Admin的Inline功能与编辑文章的界面显示在一块。请看后面。 还要提提如何手动构建一个ImageField。与CharFiled、IntegerField这类简单的字段不同，CharFiled对应Python的unicode，IntegeField对应int，直接写就可以。而ImageField对应的是ImageFieldFile这个Django自定义的类，所以一定要用Django式的方式构建。 ImageFieldFile继承于FieldFile，建立时需要对象本身，对应的字段和图片的相对路径。所以我就用下面的方法手动建立，并调用save来保存。 import os from django.db import models from settings import MEDIA_ROOT from django.utils.translation import ugettext as _ from django.db.models.fields.files import ImageFieldFile from utils import make_thumb from pulog.models ...

Android正式开源啰！足足等了一年！ 记得Adnroid刚刚出来时，我就在Ubuntu 7.10下体验了一番，然后录制了个视频还写了篇文章，在这里：在未来的Android平台上畅游！ 后来因为仅仅开放了SDK感觉不爽，而且只能用Java写App，就放下了。 现在Android开源了，好好把源码弄下来研究一番吧！ 按照http://source.android.com/download所写的把源代码取下来，首先要取得其特有的repo源码管理程序（实际上就是git的包装，利用python增强了一些功能吧）。 具体过程不写了，教程都详细地写着，然后repo sync开始同步源码。不幸的是不断发生fatal和error，不停地重试才行。 估计是取源码的人太多了，服务器受不了了。 在N次重试以后，到了这个组件时就不停地失败，platform/external/icu4c。我也手动试地累死了，于是写了个shell脚本，让系统在失败时睡眠三秒然后重试： #!/bin/bash echo "======start repo sync======" repo sync while [ $? = 1 ]; do echo “======sync failed, re-sync again======” sleep 3 repo sync done 这段脚本很简单，首先先执行repo sync，如果失败了，就会发出错误退出信号1，由while捕获，判断如果是错误退出就继续，否则完成。主要就是“$?”这个变量，是由上一个执行完的命令返回的退出状态。 开始执行这段脚本，然后睡了个美美的午觉。 睡醒后一看，终于过去了，不过还没好。Android的组件真是多啊！一些组件如libxml2、libpng、dbus、sqlite真是熟悉啊，Android就是一个集众所之长的平台。 今天就先取源码，改天再进一步研究。 —– 顺便提了一下，有几个星期了，那个http://github.com都进不去了，而用代理是可以进的。解决办法是使用OpenDNS，在/etc/resolv.conf写入下面的就行了： 208.67.222.222 208.67.220.220 强烈抗议那些将github.com等技术站点封掉的不法分子！简直不可理喻！ 想像一下，以后这样的情况越来越多，我的系统将离不开那些代理软件（Freegate、Tor）、OpenDNS，上网途中动不动就是“连接被重置”或“超时响应”，真是可悲！