Emacs 的 UTF-8 字符集替代模式

我的 Emacs 版本是 GNU Emacs 22.3.1 (i386-apple-darwin9.6.0, Carbon Version 1.6.0) of 2009-01-03 on seijiz.local。

今天试图重新配置一下 Emacs 的字体，用 [Inconsolata](http://www.levien.com/type/myfonts/inconsolata.html) 和华文黑体配合显示英文和简繁体中文，使用 UTF-8 作为 language-environment。在 .emacs 里设置后重启，发现有些字符总是使用 japanese-jisx0208 或 japanese-jisx0212 字符集，导致我为中文 UTF-8、BIG-5 和 GB2312 设置的字体和 Emacs 默认的 japanese-jisx* 字体混杂在一起。

搜索了一下，在[这里](http://www.downloadpipe.com/forums/linux/Bug-328196-emacs-snapshot-gtk-mis-detecting-charset-ftopict37467.html)看到类似问题的讨论，试用了一下讨论中建议的 (utf-translate-cjk-load-tables) 函数，没有变化。查看了一下该函数和 utf-translate-cjk-mode 的文档，原来 Emacs 对于 Korean，Chinese-GB/Big5 之外的 language-environment 默认都以 jisx 为默认首选字符集，当字符在多个字符集中有重复时，优先以 jisx 字符集显示。大概是因为使用日文的开发者对于 Emacs/Unicode 的贡献较大的缘故？这个行为大概可以在 lisp/international/utf-8.el 里面改，不过我不打算搞这种难以维护的修改。

Google Wave：不只是 E-Mail 2.0

Image by niallkennedy via Flickr

今天在 [twitter](http://twitter.com/#search?q=%22Google%20Wave%22) 上最热门的话题就是这个 [Google Wave](http://wave.google.com/)，目前这个产品还连一个 beta 版都没有，只有在 Google I/O 大会上的一个演示视频放在页面上，长约80分钟。Wave 的出发点是改进已有40年历史的，极为成功的 E-mail 协议，刚看上去也确实像传统的 E-mail，有些地方甚至像 BBS。但如果坚持把演示视频看完，相信很多人都会认为这是个极具创新性的产品。



Wave 与 E-mail 相比，其最大的优势应该是在于其实时性和可扩展性，同时如果 Google 的计划能够得到贯彻的话，也能保持 E-mail 协议的开放性。有[说法](http://www.readwriteweb.com/archives/five_sites_that_let_your_experience_the_real-time.php)认为实时的网络是互联网的下一个发展方向，并认为 twitter 的实时搜索将对 Google 等搜索引擎[构成挑战](http://www.techweb.com.cn/world/2009-03-05/391846.shtml)，但现在看来 Google Wave 已经把“实时”的含义提高到了类似“实时操作系统”的层次，例如[这个实时搜索 demo](http://www.youtube.com/watch?v=v_UyVmITiYQ#t=41m41s) 所展示的。当然这种实时性目前还限于 Wave 内部，比如虽然用户可以做到从 Wave 内更新 bugzilla 的 bug 状态，在 bugzilla 页面上还是要刷新一下才能看到结果，但如果 Wave 协议果然遍布了整个网络，其效果将是非常惊人的，相当于把电视台一档一档录制好的节目全部变成现场直播的真人秀。

可扩展性也并不是什么新概念，但与实时性结合起来后，也能够实现一些仅存在于科幻小说中的应用。比如演示视频最后的十分钟，感觉是把 Google 某个为人诟病的产品化腐朽为神奇了。Wave 还实现了一些被谈论了很久但是没有产品，或者产品接受度不高的技术，比如分布式评论和实时在线合作，也是通过多样的 extension 实现的。

Wave 对于任何需要远程协作的行业应该都是有用的。想象一下，杂志编辑可以与作者进行即时的沟通；记者可以把照片拖进 Waves，同样的照片立即出现在图片编辑的 Waves 当中，双方可以同时编辑图片的标题；科学家可以实时发布实验结果并立即得到同行的反馈，甚至通过不同数据库读到同一篇论文的读者可以同时让作者看到ta们的评论；看完了一部电影，可以通过追踪它的 wave 看到从豆瓣到 imdb 再到烂番茄上所有人的评论……

当然，顺着这些图景再想下去，会发现 Wave 带来的还不只这些。如果 Waves 的配套技术发展成熟，也许我们会发现 Web 2.0 网站慢慢地趋同（当然现在也可以说开始有这样的趋势了），因为对任何话题的讨论都渐渐被 Waves 整合起来了；而另一方面，对个人来说ta的 Web 体验也可以因为 Waves 而趋向于定制化，当然“查邮件综合症”“挂 IM 综合症”以及“Facebook 刷状态综合症”也可能演化成更为严重的“泡 Wave 症”；甚至有一天也许现在的 Web 都会改头换面，只剩下某种形态的 Wave 和后端的数据库，我觉得 Wave 有这个潜力。

当然现在的 Wave 技术还没有那么夸张。Wave 的协议是在 XMPP 的基础上改进的，目前似乎还只支持基于文本和静态图像的应用，不知道与 Flash 之类媒体交互的能力如何。Google 将 Wave 定位为通讯和合作工具，目前看来其技术是基本能满足这个要求的。但是要更进一步的话，Wave 可能需要处理更多媒体和文件形式的能力（通过下一代 HTML 和 XML？），以及更复杂的会话和权限操作。但现在的 Wave 从演示看来，已经是一个革命性的协议/平台/产品了。

Google 的工程师在演示中说将在今年晚些时候发布 Wave，而且它将是开源的，理论上说任何组织和个人都可以在它们的服务器上架设属于自己的 Wave 系统。不过以这样一个实时系统的流量和系统开销，估计 Google Wave 到时候仍然会是最普及的甚至唯一的大众 Wave 网络。也许 Google 会沿用 GMail 的思路，提供有偿的个人/企业专用 Wave 系统。还有一个问题我没有想明白，这个 Wave 里怎么插广告呢？

自由地图绘制软件 GMT

[caption id="" align="alignright" width="202" caption="Map of Alexander's empire. Created with GMT. Image via Wikipedia"][/caption]

导师把论文里的地图打回来了，还威胁说下次再画那么难看的图就让它直接进字纸篓。GRASS 的地图表现似乎确实不能让人满意，尤其是在缺乏底图数据的情况下，把遥感图像合成到地图上比较困难，处理使用不同投影和坐标系的数据更是困难。QGis 这方面稍有改善，但软件本身还不稳定。好在 GRASS 支持将数据输出成 ASCII GRID 格式，使得利用其它绘图工具生成地图成为可能。

 

Generic Mapping Tools（GMT）就是这样一个工具（包）。GMT 按照 GPL 发布，对 Windows，Mac OS X 及 *nix 等主流平台都提供了二进制包。整套工具由60多个命令行程序组成，可以组合这些程序实现比较复杂的绘图指令。最终的输出格式是 PostScript 或 eps 格式。

GMT 的一大特点是附带了 GSHHS 海岸线和国境线数据库，以此为基础，地图上的特征点可以简单地用经纬度或地图上的(x,y)位置表示，从文本文件中读入。GRASS 等软件导出的 ASCII 文件可以被 GMT 直接读取，或者用 awk 进行简单的处理后读取，这样部分地消除了在各种坐标系间转换地理数据的麻烦。GMT 本身对各种常见投影方法的支持很好，还可以通过命令行选项灵活地设定地图布局，足以应付一般的制图需要。GMT 还可以用来描绘风场图，2D/3D 等高线图，以及其它的数据图（当然这个也许还是用 R 和电子表格一类的软件更方便）。

从我对 GMT 粗浅的接触，我觉得 GMT 对于美国以外的地区提供的数据还不够丰富，没有省/州一级的境界数据，另外似乎对线段和多边形等矢量特征的导入支持不够好。但是对于 GRASS 用户来说，GMT 确实提供了一个在自带脚本 ps.map 之外的更强大和方便的选择。与基于图形界面的 MapInfo Professional 等软件比，命令行界面的 GMT 也有它的优势。

深搜索引擎

ReadWriteWeb 介绍了一个名叫 Infovell 的深度搜索引擎，据称作用是索引那些没有被主流搜索引擎如 Google 抓过的网页，包括各大学术出版商如 Oxford University Press, SAGE, Taylor & Francis, Annual Reviews 等等。Infovell 自己的定义也是 "Research engine"。我这里由于网络质量不佳只能看到 ReadWriteWeb 上的截图，看起来 Infovell 主要的特色是结合了 Web of Knowledge 将搜索结果按学科分类的功能并提供了方便的关键词修改系统，还有些提高可用性的改进例如高亮含有搜索词的句子和显示有同一关键词的不同主题文档之间的关系。

虽然 Google Scholar 现在并不是一个好用的搜索引擎，这个 Infovell 貌似也不是特别让人激动。它在描述自己使用的技术时提到了关键词搜索的一些固有缺点，例如关键词越多，得到的结果越少而且很可能相关程度反而不高。Infovell 宣称它索引了每一段话中各种可能的词语和短语的组合，而且没有网页语言的限制，这似乎说明它使用的不是语义的方法。现在像 Google Scholar 这样的搜索引擎的问题在于它不能搞懂关键词之间的语义关系，而且只会用文章被引用次数等等指标来排序搜索结果，用户可能很难找到含有特定信息的文档。比如我想找一篇关于澳大利亚北部降水对沙漠影响的文章，Google Scholar 给出的第一页结果中可能就有澳大利亚的学者研究纳米比亚沙漠的文章，而 "precipitation" 这个词只是在其参考文献中出现了一次。对于非语义的搜索引擎能把这个问题解决到什么程度，我持相当的怀疑态度。

Infovell 将在9月22日正式上线，按收费方式提供服务，并提供了30天的免费试用。目前的数据库似乎以生物科学期刊和文献为主。这个搜索引擎是否比 Scholar + Web of Knowledge 更有价值要到下周才知道了。

小功告成

在熬了两夜，整整两天连登陆学校邮箱都顾不上的不断 scripting 和 debug 之后，我总算完成了研究地区的一部分净初级生产力分布图。

将 R 中的向量作为空间数据导入 GRASS GIS

GRASS GIS 6.x 中的栅格和矢量数据可以通过 spgrass6 这个 R 的扩展包导入 R 进行统计和其他计算。用 readRAST6() 导入的栅格数据是一个称为 SpatialGridDataFrame 的结构，含有栅格位置、尺寸和投影等信息，栅格的属性数据则按照先从左到右，再从上到下的扫描顺序排成一个列向量，和对应的坐标位置一起储存在结构中。为了方便计算，这个向量可以用类似 as.vector(data.frame(readRAST6())[,1]) 这样的方式提取为普通的数值向量（is.numeric()=TRUE）。但运算完毕后要再将其导出到 GRASS GIS 中，由于缺少空间信息，略微有些麻烦。

这里提供了一些有用的讨论来解决这个问题。虽然向量不能直接导入 GRASS，但是向量可以赋值给一个 SpatialGridDataFrame，例如这样：

ensoeffarea<-array(0,dim<-c(13640,3))
ensoeffarea[,1]<-ndvimaxvalues-ndvielvalues
ensoeffarea[,2]<-data.frame(readRAST6(as.character(filename[1,1])))[,2]
ensoeffarea[,3]<-data.frame(readRAST6(as.character(filename[1,1])))[,3]
temp<-readRAST6(as.character(filename[1,1]))
temp$temp<-ensoeffarea[,1]
writeRAST6(temp,"enso-strike-area","temp")

要注意用于赋值的向量必须是列向量。而且临时使用的这个 SpatialGridDataFrame 的各种空间信息必须与向量所要求的一致，特别是各像素或特征对象数值与像素位置/对象 id 的对应关系不应有变化。否则就只能采用比较费劲的先导出成文本文件再修改导入 GRASS 的方法了。

Linux vs. Windows: A new ideology

刚才跟 roomy 聊了几句 Linux 和 Windows 的不同。他主要使用 Windows，也装了个 Ubuntu 偶尔看一看。他认为 Windows 将细节隐藏在幕后的做法有时候是好的，但如果需要折腾就很不方便。
而不转向 Linux 的原因之一是很难弄清楚软件该到哪里下载，某个组件出了问题要如何处理……等等的问题。我刚要向他介绍诸如 sf.net 和 slashdot.org 这样的网站，忽然意识到要一个只是把计算机当作工具使用的用户投入时间去接受这一整套 Linux 用户习以为常的使用计算机的方式是比较困难的。从 Windows 到 Linux 的转换不仅仅是寻找代用软件那么简单。它要求用户学习和接受从 Unix 一脉相承而来的一套 nerdy 的文化，也难怪那么多 Windows 用户对 Linux 都是望而生畏。另一方面 Linux 用户中也有这种态度：如果有一天 Linux 成了主流桌面，我们就去折腾那些更少人在用的东西。这样说起来，Ubuntu 之类也许是吃力不讨好——易用性做不过 Windows 和 Mac，严肃的 Linux 用户又看它不上。做一个迎合 geek 口味的发行版或许才是正道。

C 语言练习一则

K & R C Exercise 1-9：将输入拷贝到输出，并将多于一个连续空格转换为一个空格。


29 #include<stdio.h>
30
31 /* Read input and replace one or more blanks by a single blank */
32 main()
33 {
34 int c, bl;
35
36 bl = 0; /* bl used as a flag to determine whether a blank is needed before putchar( c )*/
37 while ((c = getchar()) != EOF)
38 if ((c != ' ') && (bl == 0))
39 putchar( c );
40 else if ((c != ' ') && (bl != 0))
41 {
42 putchar(' ');
43 putchar( c );
44 bl = 0; /* bl != 0 means blank(s) in front and needs to be dealt with */
45 }
46 else
47 {
48 ++bl;
49 }
50 }

我知道标准答案肯定不是这样的，因为还没有学 else 和 && 呢……

这里给出了一些解法。

用 Yahoo! Pipes 优化重组 RSS feed

好吧，我知道这可能是 Pipes 最土最容易想到的应用了。不过我前几天在被堆积如山的来自 BBC 和 The Economist 以及 lifehacker 的 feed 困扰时居然也没有想到这点。

我使用的 Pipes 部件都比较简单，无外乎收集 feed，关键词选择以及时间控制，最多加上一个 union。实现的功能主要是从一系列相同主题的站点中搜集 feed 并按关键词挑选出我想看的内容，时间太久没有时效性的就 block 掉。如此以来我需要用来了解天下大事的时间就大大减少了，而且在 Google Reader 里总的 feed 数量减少到6个，也就意味着鼠标的点击和等待时间都减少了，yay！

目前发现的问题是像 blogbus 这样逆历史潮流而动使用 GB2312 编码的 feed 在通过 pipes 后无法被正确识别编码，也许 Pipes 应该加入对编码的识别，或者加个 iconv 部件？从一般 html 页面生成 feed 的能力很赞，不过目前还没有搞清楚怎样导入。

我发布了一个 [Science News pipe](http://pipes.yahoo.com/pipes/pipe.info?_id=pgygETW63BGsYmvXJhOy0Q)，内容是 Nature、Science、NewScientist、Scientific American 和 Slashdot Science section 的有关环境和生态学研究的新闻，欢迎使用、克隆、改进之。

完成了一本开源小册子的翻译

这本小册子32开本，68页，我大概拖沓延宕了一年？翻译页面上的版本信息表明我是在今年1月开始的，想想觉得真奇幻……或者很魔幻？

这本小册子对我来说还是很难翻译的，很多表述英文里完全正常，用中文的话总是有那么一点欠缺。大概我的水平还是太有限，信达雅三者往往只能争取信，多数时候还可以达，雅就谈不上了。而且中间由于回国的时候上网不便和天天耽于享乐（嘿嘿），中断了几个月，前后的一致性恐怕也成问题。我自己收获倒是不小，对于它介绍的 i18n 和 l10n 有了更深一步的理解。

这个项目总共有六本小册子，我一个人搞完了其中两本的翻译，不想再搞其余的了，因为翻译过程基本就是我一人在工作，上一本完成的时候还有一个人帮忙完成了校对，一人完成了 PDF 版本的制作，项目组织者完成了 wikibook 和原网站的上传，目前这本不知道还能不能找得到人校对了。与我翻译的第一本同时开始的还有两本同系列的小册子，目前看上去还没有人理会，还几乎停留在一片空白的状态。

其实我在上半年回国的时候给网站的组织者发信说需要找人接手，而几个月过去后还是我一个人从落下的地方开始翻译的事情，就暴露了问题。这种志愿者通过网络组织起来的活动形式最大的优势应该是在于合作，但是组织者似乎没能建立一种机制方便合作。首先是项目的建立和管理，没有一个优先级的标志，也没有资源分配的机制，大家凭自己的兴趣可以任意地建立和认领项目。这在 wiki 一类的大型网站和一些主题确定的 fan site 也许是行得通的，但一个用户少，活跃用户更少的小网站这样做只是导致资源被稀释。第二，没有激励机制和同伴压力。对于志愿者来说，定一个 deadline 其实并不会把他们吓跑，只要 deadline 和工作量的制定是在协商和试错的基础上进行的。如果有一支10个人的志愿者队伍，每周给每个人一页32开小册子的翻译量，现在这六本册子也早就翻译完了。而当我一个人在翻译，其他人在讨论完全不相干的问题的时候，我简直连同伴动力都没有了。第三是纯技术的问题，网站使用 [drupal](http://drupal.org/) 做内容管理和版本控制，本身也并不鼓励松散的，跨越地理位置的合作（连 revision diff 这样的功能都没有）。如果使用 git 或者 subversion 一类的版本控制系统，搭配 [trac](http://trac.edgewall.org/)，或者起码用 [mediawiki](http://www.mediawiki.org/wiki/MediaWiki) 这样的可以支持 diff 和讨论页的平台，我会更有兴趣写一下 change log 并参与到对别人工作的讨论当中的。

以上的这些牢骚都是在与今年秋季我参加的另一个文档翻译项目——[Gentoo Weekly Newsletter](http://www.gentoo.org/news/zh_cn/gwn/gwn.xml) 的比较中发出的。GWN 的中文翻译提供了工业标准的工具：PO 文件和 git 管理下的 XML，良好而活跃的交流平台：Google Groups 和 irc，还有团队工作模式下 deadline 带来的适当的同伴压力……zhllg 实在是个 man of niubility。

A flavour of AVHRR

In the past few days I have been trying to find suitable software and process for AVHRR data processing. The METOP AVHRR format looks like an enigma. It should be compatible to AVHRR, but despite that I tried hard to find a tool to unpack the file, and even tried to write a Fortran program myself, I couldn't find anything that decodes the file downloaded from [CLASS](http://www.class.noaa.gov/).

What made the search not totally fruitless is a image processing tool, [BEAM](http://www.brockmann-consult.de/beam/), which works nicely with AVHRR and a number of other data files. I can use it to open AVHRR 16-bit and 8-bit Level 1b file (10-bit not tested yet), do some simple preprocessing and statistics, then export the file as GeoTIFF or other formats, which can be read by GRASS GIS + GDAL. It is worth noting that BEAM is free as in free speech software published under GPL **v3** and can run on any platform with Java Runtime Environment.

With the help of BEAM and GRASS I managed to produce my first AVHRR-derived NDVI image this afternoon. Seems I am finally on track. In the coming days there are a number of things that I can look at:

- AVHRR Pathfinder data, their advantages and limits, suggested by one of my supervisor;
- Snow and ice cover mapping with AVHRR;
- Time series data and change detection;
- MODIS data and its interoperability with AVHRR.

自由的遥感图像处理解决方案？

因为工作的需要，最近一段时间的工作重点是搜集和处理遥感图像。具体要怎么处理还没有决定，只知道大概要做的东西包括几何校正，大气校正，geoencoding/registration，后期肯定会做 change detection。这些在 ERDAS Imagine 里面是相对简单的，基本都可以点点鼠标解决。但是目前学校的 IT staff 还没有给我的电脑装这套软件，为了立即开展工作我准备找一找自由/开源的替代方案。

在 [http://opensourcegis.org/](http://opensourcegis.org/) 上给出了一个比较全面的与 GIS/RS 有关的自由/开源项目的列表，虽然其中成气候的项目还很少，而且像 Imagemagick 和 Free Type 这样的通用项目都列上去了，不过这方面的开发工作确实比我想象的更多。在 [GDAL](http://www.gdal.org/) 出来后出现了很多 GIS 项目，但地学图像处理方面的软件相对还是很缺乏。

一番比较后我决定使用 [GRASS GIS](http://grass.itc.it/intro/general.php) 和 [nip2](http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2) 来完成工作。GRASS GIS 是目前自由/开源 GIS 中最成熟的项目（应该不用加“之一”了吧）。以前我用它做过一个简单的模型输出可视化，但没注意到它还有处理遥感图像的功能。看了它的手册和一些搜索之后，结论是它可以用来做几何与大气校正、合成和分类，虽然分类的算法可能没有商业软件包那么多样，不过理论上说可以自己写个实现，已经有人做出了[神经网络分类方法的实现](http://www.ncgia.ucsb.edu/conf/SANTA_FE_CD-ROM/sf_papers/muttiah_ranjan/muttiah.html)。

nip2 是 [VIPS](http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS) 库的一个前端，号称是介于 Photoshop 与 Excel 之间的图像处理软件。其特点是可以用控件和脚本结合对图像方便地进行复杂的处理。虽然它的设计似乎并没有特别考虑地学应用的需要，但它有一个非常吸引人的特性，就是对大图像的处理速度非常快，而且可以处理大于内存容量的图像。我准备用它来处理观测角度与读数关系不大的图像，也可能用它来做分割和组合。

如果两周后我觉得这两个软件用得比较顺手，可能会一直用它们完成论文。商业软件包确实易用，能够节省一些学习和适应的时间，但我觉得用自由/开源的软件能让自己对 under the hood 的东西了解更多一些，而且现在掌握了 GRASS GIS 以后还可以很快上手 ERDAS Imagine，反之则不然。

Trying to choose a plotting package

During the process of writing my review, I meet the problem of plotting. For now I can copy figures from other people's work but I think there will be times when I need to draw my own plot.

There are a number of plotting software packages out there. Some are used by a lot while some have a relatively small user base. For one who want to get some help from the community, it is important to choose one that has a friendly syntax/interface and a larger user base. For now I am looking at [Asymptote](http://asymptote.sourceforge.net/) and [gnuplot](www.gnuplot.info). They are both powerful packages with extensive features, both support LaTeX well. Both have good documentation, which make the choice even harder to make.

In terms of language they use, Asymptote seems to be more formal, using structures more like those of C++ and Java. gnuplot seems to be more similar to (Bourne Again) shell scripts. If I have C++ programming experience it should be easier to pick Asymptote, but in fact I am more familiar with shell scripts and a little bit Fortran.

Taking a closer look, I think gnuplot is better at plotting data and non-parameter functions, as it is easy to do so in a sequential way, and it can read inputs from standard output (Asymptote seems cannot). But for more complicated graphic, the language used by Asymptote really boost it to a higher level.

The best way seems to be to learn both packages, as they have different advantages. But learning both at the same time seems to be very challenging. Without much drawing at hand, perhaps I'll start with gnuplot.

迁移工作基本完成

随着 blog entry 数量的增加，迁移也越发费时费力了……
不过 MT 的表现从目前来看很值得。

目前暂时开放匿名 comment，如果垃圾评论太多的话就要考虑只允许登录的人评论了。

Firefox 的杀手级扩展── Zotero

嗯，我也标题党一回。Zotero 对我来说确实是杀手级的一个应用，不过对于没有这方面需求的人来说它也就是一个普通的扩展。那么具体是什么样的需求呢？大量文献信息的组织，文献的有序保存，以及按需调用。

不错，这正是许多文献管理软件，比如[Endnote](http://www.endnote.com)，[RefWorks](http://www.refworks.com)，以及 [jabref](http://jabref.sourceforge.net) 都具有的功能。但是回忆一下我们在使用这些软件时的行为：看到一篇文献，点击输出参考文献的链接，选择格式，然后等待软件启动，导入文件后我们再把焦点重新放回到浏览器继续浏览。在看文献的过程中我们还要找个东西记笔记，笔记如果不能很好地组织起来，又怕将来忘记，所以每篇笔记还得加上有关文献的链接。这样是无法建立一个有效率的个人[工作流](http://www.answers.com/topic/workflow)的。

Zotero 就不同，它把我们进行文献研究时的主要活动──搜集，整理，阅读和引用都很好地集成到了一个界面之内，就在浏览器的一角，唾手可得，而且没有 Endnote 那种复杂的下拉式菜单，一切都可以用快捷按钮和上下文菜单解决（[这里](http://www.zotero.org/images/quick_start/zoteropane_800x635.png)是界面的截图，版权归原所有人）。在 [Google Scholar](http://scholar.google.com) 和 [Web of Knowledge](http://www.isiknowledge.com) 之类搜索引擎和 Elsevier、Springer 等出版商的网站上还可以利用自动发现功能一键添加文献数据。

大多数情况下，使用 Zotero 的流程可以归纳为：在互联网上发现文献──（利用 [SFX](http://www.exlibrisgroup.com/sfx.htm) 等文献服务发现全文）──利用导入功能得到文件信息和有关附件（pdf 等）──做笔记、tag、与相关文件链接──搜索文献──输出有关文献为其他软件格式──在 TeX 或字处理软件中引用。除最后一步外都不需要打开任何其他软件。

此外，Zotero 的相关文献功能允许我们把关键词和标题上看不出任何联系的文章放在一起，这在我们进行某些跨学科研究时非常方便──比如讨论航海技术和全球化的联系。Zotero 的其他特色功能还包括对 pdf 文件进行索引，通过搜索创建类似于 MacOS X 的智能文件夹，对多种文献来源和格式的支持，在文献快照上进行批注（仅限于文本和 html 文件），以及文献时间线的创建（对于写 review 非常有用）。在 [Zotero 官方网站](http://www.zotero.org)上有对这些功能的[详细介绍和教程](http://www.zotero.org/documentation/)。

据说将来 Zotero 也会引入类似 RefWorks 的线上文献库功能，但是现在使用本地 sqlite 数据库的好处是可以方便地脱机使用，也可以用备份和版本控制工具管理。我倒是希望 Zotero 将来能有这些功能：

- 单独搜索笔记和批注
- 界面上对搜索词高亮
- 记录文献库中项目的访问时间，并可用它作为条件搜索最近看过的文献
- 增加对更多文献数据库的自动发现功能，或者允许用户自己添加自动发现网站和信息提取语法（更新：Zotero 的[开发网站](http://dev.zotero.org/scaffold/)上提供了扩展的下载，用于“高级”用户自行添加 site translator）

总地说来 Zotero 是我目前遇到的用得最顺手舒心的文献管理和笔记软件，向任何看到这篇 blog，平时上网不仅仅是看 YouTube 的人推荐。

\[再更新：如果你是大学内的用户，可以把默认的 OpenURL 解析器（Resolver）改成自己的 sfx 或者其他类似服务的解析器。各学校的解析器 url 可能不太一样，但你自己用 sfx 搜索一次以后就应该知道是怎么构成的了，在设置中填上，用 Locate/定位功能实验一下即可。\]

ifmslide -- 一个似乎没什么人用的 LaTeX 演示宏包

今天在无聊的时候随便用 locate 命令看了一下自己的硬盘，发现 TeXlive 2005 里还有一个用于制作 slide 的宏包，叫做 ifmslide。这个东东似乎利用了 texpower、seminar 等多个宏包的功能，有一些它自己的特点，包括：

- 可以方便地定义背景图像；
- 可以自定义导航按钮的形状和位置；
- 可以方便地开关导航栏和定义导航栏位置；
- 用 pdf 格式时生成幻灯片，用 dvi 格式可以生成 handout ，基本不需要改动代码。

不过还不清楚对中文支持如何，也不清楚是否像 Beamer 那样支持 pgf 提供的绘图命令。另外一个缺点就是没有提供设计好的模板，不清楚做出来的幻灯片美观程度如何。

添加了 instiki (wiki)

给网站加了一个 wiki，用来记录自己平时看书会需要用到，又不容易在网上搜到的资料。地址在 http://snakehsu.info/wiki/。目前是开放编辑权限的，如果被滥用了就会关掉。

设置这个版本（0.11.pl1）时有一点小问题，很多文件都是 DOS 格式，导致在类 Unix 服务器上工作不正常，把大部分文件 dos2unix 之后就好了。

又从 Typo 搬到 Mephisto 了……

Hack 1: 文章 meta 的修改

这里的 meta 是指每个 entry 下面一小块区域，包括文章作者、所属分类等信息，以及指向评论的链接。最初的模板没有订阅评论的链接，也没有文章所属 tag 的信息，所以改动模板的 _shared.liquid 文件如下，加入：

1 2	<span class="tag">Tagged {{ article | linked_tag_list }}</span>

以及：

1 2 3 4 5 6 7 8

{% unless mode == 'single' %} {% if article.accept_comments %} <a href="{{ article.url }}#comments" class="commentslink"> {{ article.comments_count | pluralize: 'comments' }} &#187;</a> &nbsp; <a href="{{ article.comments_feed_url }}" class="commentslink"> Subscribe to comments</a>{% endif %} {% endunless %}

代码基本是自解释的，我就不说啥了。

Hack 2: 每次都要折腾的分类 feed 链接

分类的链接比较简单，Mephisto 的 wiki 上有说明，另有一个 articles_feed 的 filter 可以帮助获取用于自动识别的 feed，加上后会在 html 的 <head&rt; 部分加入 feed 地址，像 Firefox 这样的浏览器就可以自动发现这些 feed。但为了让使用 IE 之类浏览器的人也能看到 feed，就比较麻烦，google 了半天之后发现 mephisto 提供了一个 helper，叫 section_feed_url，终于搞定，代码是这个样子：

1 2 3 4 5 6 7 8 9 10

<ul> {% for category in site.blog_sections %} {% unless category.name == 'Home' %} <li>{{ category | link_to_section }} ({{ category.articles_count }}) {{ category | articles_feed }} <a href="{{ category | section_feed_url }}" class="tiny">(atom)</a> </li> {% endunless %}{% endfor %} </ul>

折腾了一通之后发现有人写了插件提供这个功能……另外 Home 分类是默认的，就是全部文章，这里用 unless 把它去掉。

Hack 3: 最近评论

这是 0.7.3 最新支持的功能，在 CHANGELOG 里他们给出了一种用法，但无论怎么改参数，给出的评论数总是跟默认的页面文章数一致，似乎是参数没有传递过去。后来还是在 Mephisto Wiki 上的提问与回答部分找到了一段代码，依葫芦画瓢：

1 2 3 4 5 6 7 8

{{ site | latest_comments:5 | assign_to:"comments" }} <ul> {% for comment in comments %} <li>{{ comment.author_link }} on {{ comment | link_to_article }} - {{ comment.body | truncatewords: 10 }}</li> {% endfor %} </ul>

至今也不明白为什么像 {{ site | latest_comments :5 }} 这样的代码不行，非得用 assign_to。

Hack 4: 每月文章

这个也是 Mephisto Wiki 上直接给了解决办法的，直接贴出代码：

1 2 3 4 5 6 7 8 9 10

<ul> {% for month in site.home_section.months %} {{ site.home_section | monthly_articles: month | size | assign_to: 'articles_count' }} {% if articles_count > 0 %} <li>{{ site.home_section | link_to_month: month }} ({{ articles_count }})</li> {% endif %} {% endfor %} </ul>

Hack 5: 分类存档

我最得意的 hack :)。Mephisto 的作者非常痛恨 blog 分页，据说是因为这样文章的链接会随其页面位置改变，不方便别人用搜索引擎查找，所以 Mephisto 默认没有分页功能，也没有“上一页”这样的选项。还好每月的文章是可以全部显示的，但查看分类、搜索和首页的文章数等等都要受同一个变量的控制。首页没有早期文章的链接还可以忍，分类也只能看十几篇就比较过分了，好在摸索之后发现每个分类也是可以按照月份显示所有文章的，通过以下代码：

1 2 3 4 5 6 7 8 9 10

<ul> {% for month in section.months %} {{ section | monthly_articles: month | size | assign_to: 'articles_count' }} {% if articles_count > 0 %} <li class="month">{{ section | link_to_month: month }} ({{ articles_count }}) </li> {% endif %} {% endfor %} </ul>

建立一个分类页面专用的模板，在 sidebar 部分加入即可通过每月文章访问到分类中所有的文章。但是这样跟我所要的效果还有一些差距。怎样能看到所有文章的标题呢？参考上面的代码，我依葫芦画瓢写了如下的代码，试验了一下，运气不错：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<ul> {% for month in section.months %} {{ section | monthly_articles: month | size | assign_to: 'articles_count' }} {% if articles_count > 0 %} <li class="month">{{ section | link_to_month: month }} ({{ articles_count }}) {{ section | monthly_articles: month | assign_to: 'articlesmonth' }} {% for article in articlesmonth %} <li>{{ article | link_to_article }}</li> {% endfor %} </li> {% endif %} {% endfor %} </ul>

增加了一重循环，在每月文章内再分别列出文章的题目，第二个 assign_to 的用法比较有趣。

Hack 6: Gravatar 支持

Mephisto 的管理界面直接支持 Gravatar 的头像，但我一开始没有找到对应的 filter，而插件工作也始终不正常。困扰了许久后在 Google Groups 上的 Mephisto Blog 小组找到了答案，原来 filter 就在 mephisto/apps/helper/url_filters.rb 这个文件中：

1 2 3 4 5 6 7 8 9 10 11 12

#################################################### def gravatar_author(author, size=80, default=nil) return '' unless author['email'] url = "http://www.gravatar.com/avatar.php? size=#{size}&gravatar_id=#{Digest::MD5.hexdigest(author['email'])}" url << "&default=#{default}" if default image_tag url, :class => 'gravatar', :size => "#{size}x#{size}", :alt => "author['login']" end ####################################################

修改一下评论模板，在合适的地方加上 {{ comment | gravatar: 32, "http://snakehsu.info/contacts.png"}}，即可看到评论者的 gravatar。两个参数分别是头像的大小和没有头像时的默认图像。

顺便说一句，前几天 gravatar 工作不正常是因为数据库和服务器的配合问题，目前已经基本解决，但是需要用户自己登录 gravatar 再重新提交一次头像。

Hack 7 & 8: 搜索和 Tag Cloud

如上面所说，内置搜索的结果只能给出最初十几个，所以我试图用 Google 定制搜索引擎 来解决这个问题，不过看来 Google 还没有来得及索引这个新地址，所以这几天内估计用 Google 搜不到这里的东西，且看看过一周后怎么样。

Tag Cloud 也是用的现成的插件，唯一的问题是域名不一致，因为它认为我的 blog 的基础地址是 snakehsu.info 而不是 snakehsu.info/main/，我也没空钻研 URL 重写的问题，就直接改了插件的源文件了事，这个是我唯一的一处”硬“修改。

现在这个新 blog 基本实现了过去 Wordpress blog 的所有功能，有些地方还更方便，比如内置的 Gravatar 支持和 Markdown （类似 emacs-wiki 的标记语言）。折腾了好久，现在基本可以熟练地在共享主机上安装 Ruby on Rails 程序了……

从 Wordpress 搬到 Typo 了

而且总算把两个 blog 统一了。导入原来 [blog](http://snakehsu.info/blog) 的文章时发现刚好写了365篇 entry，不知道有没有什么寓意，呵呵。

Blog: 功能增强

因为一大早起来就比较郁闷，所以早上也没干多少活，大部分时间用来折腾 blog 了。通过安装若干插件和对模板代码的少量 hack，目前 blog 有这样一些变化：

• 标题下方加入了令人无语的 tagline；


• sidebar 加入了 Profile 一项；


• 申请了 gravatar 的头像服务并通过插件在 blog 中提供支持。如果发表评论时提供了 e-mail 地址并用这个地址在 gravatar 注册过，则显示评论时也会显示对应的 "Global Recognized Avatar"。e-mail 地址不会显示在页面上，不用担心被盗，请放心使用～


• 你们看不到的：管理界面中批量修改 entry 所在分类属性的插件；


• 最后也是最重要的，改进了分类显示，并提供了分类专门的 rss 的链接。

欢迎多提意见。