好吧... 我承认, 我还在用古老的 xmms, 因为只有这个小咚咚还没给我随便崩溃过, 只有它不会在我加一个超长的列表的时候给我脸色看, 最令人惊异的是 --- 它是处理 MP3 标题时乱码最少的 --- 我不知道为什么, 没有研究的兴致.

http://fanfou.com 是一个 twitter 类的服务, 在国内当然有它的好处: 快速稳定, 更重要的是能手机更新. 而且有一位技术很值得信任的人在那里做开发, 相信它能越做越好. 如果它有比较好的搜索乃至更高级的整理功能的时候, 再借助它的好友圈, 它能成为一个非常好的共享笔记本.

fanfou 当然也开放了 API, 非常地简单易用. 花了点时间学了下 xmms 插件的写法, 找了个简单的例子依样画葫芦就做好了这个插件. 它能把一定时间内 (如 30 分钟) 播放的歌曲列表发上 fanfou. windoz 下也早有这个东西了, 挺有趣的说.

下载在这里, 不说什么了, 某墙立功了, 我没法用 google page 来放这些了. 另外提醒一下, 这咚咚我是临时学写的, 再加上好久没写 C 程序了+测试不足, 这个... 质量没法保证.... 呵呵.

我可能在下一步开发一个 emacs 插件, 让 fanfou 可以当流水帐笔记本来用. 不过发现我那点 scheme 底子对 emacs 扩展开发没啥帮助啊, 好多好复杂的 API....

我在说谷歌, 出了个生活搜索, 结果看来还是骂得多, 赞得少
虽然用的是 google base 的 base, 虽然被人说模仿抄袭, 但至少, 它让我们看到了谷歌的努力, 真的想做一个好东西, 而不是拼流量, 拼公关的努力. (嗯, 其实, 我想无论在中国还是美国, google 的大部分力量还是放在改进网络搜索上的, 可惜我们还不能直观地看到谷歌这方面的成果, 虽然听说 google.cn 的 robot 最近很勤快...)
但是....... 总有很多但是.......

1. life.google.cn... 不行, www.google.cn/life 不行... 最后这个 www.google.cn/shenghuo 这个地址我是 google 出来的. 而且搜的是 google生活, 不是谷歌生活. a) 即使是实验室产品, 是不是也应该多给几个入口呢? 而且本土化的意思可不是样样都要说拼音... 另外谷歌里南方人也不少, 不会不知道南方人分不清卷舌音吧... b) 谷歌这个品牌真可怜....

2. 东西搜出来了, 一点链接, 给我来了个本页面跳转...... 我可是连网页搜索的 preference 都设了跳到新页面的...... 而且这是面向中国的产品, 中国用户习惯开新页面这个应该连火星人都知道了吧.

3. 最后, 搜个东西, 加条件, 下一页, 都给个大空白页显示个正在载入结果, 网络稍微差点那可比直接网页刷新更难受, 因为没有进度条告诉你现在它在干什么. 这种迭荡起伏的体验不是 google 的风格吧, 是不是应该学学 greader 或者 gmail, 保持结果显示的同时提示载入呢?

以上这些问题, 全部不是技术问题. 导航的毫无意义目标用户中也没人会用的上移下移按钮, 热榜中被人抓的弱智网页 bug 以及排名居然漏了 qq 之类的 bug, 还有 google 生活, 似乎都说明: 谷歌你的技术完全没问题, 但你可以做得更好, 稍微花多点时间, 给点耐心和细心, 不用什么高深技术.

A chat with Aoron Swartz
http://blog.outer-court.com/archive/2007-05-07-n78.html

和我同龄 (还是小一岁?), 上个星期一直再用他的 web.py 开发 BGMail 的前端. 这个世界上各种语言的各种框架多得很, 我自己也曾开发过一些. 但像 web.py 那样简单干净, 拥有强大功能的同时又不与你既有的编程习惯冲突的框架实在太少. 所以一直很佩服这个同龄人.

参加过 W3C 的标准工作, (RSS 的起草人之一? 记忆中好像是)
python 界公认的大牛
reddit 创始人之一

他学的第一个语言是 basic, 我也是在小霸王学习机的 basic 上起步
98 年他在 TCL 上开始真正的项目, 98 年我在用 pascal 写游戏, 参加信息学竞赛
到现在......
不禁要问, 这些年我都干嘛去了? >_<

冲动的结果 - BGMail!



长长的五一假期, 我在做什么? 除了洗衣做饭脱地板傻吃闷睡之外, 我的大部分时间都在神情郁闷的写程序, 为了一个冲动的决定......

应该是在五一放假的前一天, 我终于觉得我不能再忍受 Thunderbird 了 (2.0), 用它实在无法有效的管理每天几百封的邮件. 比如, 如果我用 threaded 列表,一封新收到的邮件可能是一个历史久远 (也就一两天, 但是已经能排好几页了)的 thread, 那么 thunderbird 没有一个排序方法能够让这个有新邮件的thread 排到最前; 另外对打了 tag 或 star 的邮件, 我想在只看 tag 和 star的列表里看到这样的邮件后, 再点去查看整个 thread 的上下文 --- 没有任何办法. 另外还有一些 ``小'' 问题, 比如, 要加个 filter, 你不能选定把信过滤发到一个不存在的目录 (expect 它在提示后自动创建), 在那个界面也米有可以创建目录的控制, 所以我每次设 filter 都是开 filter - 建规则 - 发现没目录, 退出 filter 界面跑去建目录, 再来一遍.

我搜过 thunderbird 的 addons, 也用过 evolution 和 kmail (这个我用了几年了), 发现没有一个办法能完全满足我现在的需要. 可能是最近一年被 GMail 惯坏了, 我还是习惯于 GMail 的信息管理方式, 但是用 GMail 去管理内部邮件是不现实的. 我去用 GMail-like 搜索了看是不是有类似 GMail 的 mail client, 结果除了 sf 上一两个处于原始开发阶段的项目外, 一无所获.

所以我的决定是: 利用五一假期, 写一个个人版的 GMail, 这就是 BGMail 的来历, 由于这是我个人制造个人使用, 所以能保证它完全满足我的需要 (不满足的时候再自己改就行了), 还能提供一些根本无法对普通用户提供的功能. BGMail的 意思就是 BeyondGMail, 产品的好坏是由用户决定的, 对于我这个用户来说,我相
信 BGMail 能做到这一点. 当然 BGMail 也可以是 BG Me 啊, Big Gmail = 大猪猫之类啦, 哈哈.

这个冲动的决定令我非常兴奋, 所以我整个五一假期都在拼命的写程序. 其实也许一些console-based 的 mail client, 如 mutt, 再加上一砣砣的扩展, 也许能基本满足我的需要, 但是, 相比于痛苦的配置, 完全按照自己的意愿去写自己的软件,并且在有新需求的时候能自己随意扩展, 不是更有趣的事情吗?

我计划在五一期间完成的并且现在已经实际达到的功能点如下.

1. 类似 GMail 的 tag-based 邮件管理, 同样有 star 功能.

2. 与 GMail 不同的 UI 细节: 对于有未读邮件的 tag, 点的时候不是跳到完整的浏览界面,而是直接在列表界面下拉浏览未读的邮件, 这样能节省阅读大量简短的新邮件的时间. 记忆中 GMail 也有类似的油猴子扩展. 打 tag 的方法不像 GMail 而更像 GReader 的 in place 输入. GMail 的那种标 label 的方法更照顾了对tag-based 管理方式不熟悉的普通用户, 但对我来说是太过烦琐了.

3. 阅读界面能够像 GMail 一样将 quoted text 隐藏 (我就奇怪, 为什么 thunderbird, outlook 等等就没有一个能在 GMail 之前想到这个这么自然的功能呢)

4. 纯文本的 composer, 支持附件. (我本来就很讨厌收到 HTML 邮件, 发邮件当然都是纯文本)

5. auto-filter (在这里可能应该叫 auto-tagger), 可以用一种简单的基于正则匹配的脚本语言对一个邮件的 tag 进行细致的控制 (It's all for geeeeeeks!)

6. 管理方式和 GMail 的不同: star 是对 thread 而不是对单个邮件的; 另外如果邮件被标了 tag, 它就不会在 Inbox 里出现, 这个比较接近于传统 folder-based 的管理. 因为如果像 GMail 的 Inbox 一样, 我的 Inbox 一天就可能上十页, 就根本起不到作用了.

我计划在下一个有较多空闲的时间段完成的功能点有:

1. 高效率的全文检索, 支持将检索结果设为一个目录/tag.

2. 键盘快捷键控制.

截图欠奉, 因为发现模糊实际邮件信息之后整个界面就是一个大色块. 大概就是 GMail 的简装版啦, 没什么特别的.

虽说这是一个冲动的决定, 但我在做计划的时候还是充分考虑了可行性的. 事实上主要功能的完成时间比计划中还提早了一天. 我的信息来自我使用的一大串强大的工具: python, berkeleyDB, web.py, cjson, lighttpd, 还有在我的毕设 solomon 中抽取出来的 RPC 协议. 这些工具使我在短短 5 天, python + javascript 代码量不到 3000 行的规模里, 完成了 BGMail 的基本功能.

基本功能完成后, 在实际使用中也发现了一些问题.

1. In-place 的未读邮件浏览: 这确实能提高查看邮件的效率. 但它的逻辑是这样的: 如果一个 thread 有未读, 则 in-place 浏览, 如果没有未读, 跳到完整浏览界面. 虽然有未读邮件的 thread 会有粗体, 但连我自己有时侯都会迷惑: 在同样的情况下 (仅字体不同) 同样的操作会有完全不同的结果. 现在正在想如何改进这个流程.

2. 基于 thread 而不是基于邮件的 star. 这主要是为了解决 GMail 在邮件列表中打星星会产生的疑惑: 你不知道这时候是哪个邮件, 或是整个 thread 被打邮件了, 要取消星星是系统的行为更是无法预测 (说实话 GMail 也很疑惑, 它不知道你想干什么). 所以在 BGMail 里就干脆直接给 thread 打星. 但这也同样有问
题: 有时侯我们是希望在长长的灌水列表中给某一两个重要信息打星的, 而 BGMail 无法实现这一点, 你点开打星的thread 之后还要自己慢慢看. 我想 GMail 和 BGMail 都同样可以考虑这个逻辑:在列表里打星的时候, 给 thread 里的所有邮件都打星, 但同时也支持对单个邮件打星. 但这样列表上对只有一部分邮件打了星的邮件的呈现还是一个令人疑惑的问题, 如果还是像现在这样显示, 用户取消星星时系统的行为, 就会跟现在一样令人费解了.

3. 分 tag 浏览的问题: 在一个 tag 的列表中, 点一个邮件, 它会给出整个 thread 中邮件的列表, 即使那个邮件没有打上这个 tag. 这在很多时候符合我们的期望 (要知道 thread 的上下文), 但有时侯我们确实只想看这个 thread 中, 标上了这个 tag 的邮件, BGMail 无法实现这个功能. 似可以在界面中加上只显示某个 tag 的下拉选择. 上面所述的 star 功能也同理. (更新: 此功能已基本实现)

前两天 GReader 标 tag 的 suggest 改掉了, 因为界面没怎么变, 我还是顺手按原来的打, 结果发现无论如何都无法把 tag 标上去, 仔细一看:


由于 GReader 是从原来的订阅目录然后转化到 tag 系统的, 不免有点乱. 我的办法是订阅列表的 tag 都是以 ``-'' 开头, 而收藏的文章 tag 则按正常的标. 结果我按 product 的时候, suggest 自作聪明地给我提示 -product-design, 我不知道这里面有没有某种排序逻辑, 但是下面的 product 是精确匹配却不能排在第一, 实在无法理解.

这还没完, 在原来的设计中, 我打完 product, 即使提示不对, 我这时候敲回车, 它就标 tag 为 product, 关闭界面, 操作完成, 现在呢? 按照 suggest 原则, 它自动给你打个 -product-design 上去了. 好吧, 那我打个逗号输下一个总可以了吧? 它还是自动给你打 -product-design!!! 于是我现在要标 tag, 则必须动用鼠标, 或者用上下键选择, 我也必须停下来, 认真阅读这个小得可怜的 suggest 下拉框才能继续下一步操作. GReader 本来有非常好的键盘操作功能, 手几乎不用离开主键盘区就能方便地浏览, 就因为这个小细节, 所有这些方便都被破坏掉了.

总结起来, 这个新的 suggest 设计的问题是:
1. suggest 的存在影响了原有的键盘输入操作, 当不需要 suggest 的时候 (对我来说, 这是通常情况), 这个 suggest 的设计使我不能忽略它的存在, 不能像没有 suggset 的时候一样输入.
2. 自作聪明, 忽视用户的自主选择, 改变用户 expect 系统的行为. 我指的是 enter 和逗号的行为, 这个改变使我使用起来增添了太多太多的麻烦.