分类：时间发生机

前几天，添加了添加图书的栏目，原理是通过豆瓣提供的API接口，取回豆瓣用户收藏的图书列表，并对图书的收藏数进行排序，显示程序员们看的图书。

去豆瓣小组发个帖子后，有些热心的朋友帮我测试了这个功能，呵呵，期间发现了一些Bug并修复。这要归功于Django的异常反馈系统，在Django的Debug关闭后，在设置正确的邮件参数和管理员邮箱后，系统会自动将异常的信息发送到管理员邮箱。

虽然，使用了人并不多，但多少也反映了一些数据，比如世界是平的就比较受欢迎。其实，我不是经常使用豆瓣，更不用说在豆瓣上添加好友。在这次的加入共享图书的朋友，我都跑去了加入他们为朋友，也许这样去找的好友还是比较靠谱的。

其实，这个的功能的有些东西，还是不很人性化，比如，在成功加入后，只显示了一句谢谢，是否太不专业了呢，怎么也要显示添加了哪些新书啊或者与哪些豆瓣用户共同的爱好之类。主要这段时间对我来说有点复杂，我会尽力来完善的，谢谢这次参加最开始测试的朋友，祝你们牛年大吉。

昨天，对豆瓣的API进行了应用，实现了一个简单的小功能，收集豆瓣用户的图书信息。虽然能用，但我觉得离有用还有很大的区别，仍然需要改进。

最近，为Devchange添加了对Bazaar的支持，这是一个比较流行的分布式的版本控制系统。下一步计划增加对Git的支持。这样差不多可以覆盖大多数版本控制系统了。

前些天收到benky兄的Google Friend Connect的邀请，玩了一下这个新东西，虽然非常有意思，但加载速度上真是很难恭维，如果要加载多个gadgets那真是要疯了。从界面上来看，应该本地化的工作还没有完成，如果完成了也许加载速度会有所好转。

对博客那边也做了部分更新，增加了程序的自由度。

前几天，我为Lifefix添加了一个Devchange的功能。这个功能对我来说还是挺有用的，因为我至少会每天去关注一下Django中Trac的timeline，我想知道，今天有哪些更新和其它的一些信息。而且，我还关注其它项目的开发进度。因为这些原因，我计划把一些项目管理的版本库记录抓过来，于是Devchange就被这样创建出来了。这样关注其它项目的开发进程所需要花费的成本就少多了。

在做这个东西的时候，我借用了livid开发的project-babel中的随机颜色显示功能，来让这些changeset不那么单调。

如果你觉得这个功能对你有那么一点点的好处的话，那我就非常开心了。

在最新的一个版本中，我不再做一个后台管理界面，于是我有将前后台结合的想法。如果这样的话，换肤就是一个问题，怎么保证管理风格不变，再就是怎样提供更方便的操作方式，而且，页面设计也是问题。

Ext对我来说，好像是这个问题的完美解决方案。优秀的UI设计、完善组件、丰富的数据载入、弹出层实现界面无关性。而且，在最新版本中，可以使用多种JS库，包括jQuery。而且可以自己根据需要构建库文件，让JS文件达到最小。

不过从看Ext的API文档，好像有点复杂。不过有学习的价值。 

这几天我把侧边栏重新写了下，这个实现用于更方便扩展，在下次发布代码的时候会有一个例子来说明怎么写一个侧边栏，而且，在系统内部会内置默认的侧边栏。

在Weblog中，会经常使用Permalink，为了保证这一资源的稳定性。像我在分类中也使用了Permalink，但这样我就不能经常来改变一些分类的Permalink。但有时确需要改某个分类和Weblog的Permalink。所以我觉得应该在改变Permalink后，为了让搜索引擎更新你的链接，应该为原来的链接加上301Moved Permanently。

首先，blogroll＝weblogroll，在前几天我加上了这个东西。网络上对blogroll的定义是：

大多数 blogger（博客）在其个人网志上都提供 blogroll。这就允许读者连接到其他趣味和写作风格相投的人的网志上。Blogroll 方便了网络上的沟通。通过使用Outline Processor Markup Language （OPML），人们可以用 XML 格式文件交换 blogroll。

现在这个功能，并没有达我的预期的目标。被添加的站点，会自动分析head中的内容，将ico和rss提供出来，但现在确没有出现，主要是使用正则分析的问题，本来我对正帽就不是非常了解，所以这是需要解决的问题。而且，分析后的数据是直接取URL还是本地存放一份也是考虑中。

如果根据上面的定义，那么抓取目标站点的OPML也是个不错的选择。