苦水潭

我写 fuse 客户端可能有点上瘾，是因为我觉得对于在线存储类的服务，能够映射到本地存储，对用户来说是路径最短，学习成本最低、体验最友好的方式。而要实现类似的效果，据我所知要么用 fuse 把远端的存储挂载到本地（如 sshfs、amazon s3fs），要么写个后台服务实现本地和远端的双向同步（同步远端可以轮询或用某种 push 技术，同步本地可以用 inotify，典型案例是 dropbox）。而我之所以倾向前者，是因为 fuse 的实现成本要小很多，对于个人开发者来说性价比完胜。 有了上述前提，什么专门的 GUI 管理工具啦，专门的 shell 啦，在我看来都比较无聊——当远端的文件系统已经变成本地的一部分时，用户可以使用任意自己熟悉的文件管理工具（无论 GUI 还是 CLI），可以使用任意自己熟悉的 shell 环境（包括相应的各种工具），来完成对远端的文件管理任务。比如将 dropbox 同步到 upyun，在我看来只需要这样就可以了： upyunfs -b lyman_foo ~/cloud/upyun # 挂载 upyunfs rsync -avh ~/cloud/dropbox/ ~/cloud/upyun/ # 用 rsync 同步两个文件夹 所以看到 upyun 搞了 开发者比赛 的时候，我实在是忍不住，便写了这个 upyunfs 。 对实现细节不感兴趣的同学可以忽略下面的文字了，不过还是希望各位能给 upyunfs 投个票：到 项目页面 里找到 upyunfs-for-UPYUN，点击「投票」按钮即可。 接下来大概分析一下 upyunfs（以及类似存储系统）的实现要点。 一、技术选择 fuse 有 各种语言的 binding ，从执行效率角度考虑首选当然是 c/c++。但是如 upyun 这样提供 RESTful 接口的服务，用到字符串操作的地方不少，所以用脚本写起来更方便。python 的 binding 我试过一次，问题不少文档不多，所以我一直用 perl。 二、roadmap 基本功能 这个阶段基本上只要做好 fuse 回调和 RESTful api 的映射就好了。具体一点，在线存储系统基本上必不可少的 upload/download/list 操作，大抵就可以对应到 fuse 的 read/wri...

该不该限制程序员的语言？当然，这里的程序员肯定不是 java 之于 hadoop，objective-c 之于 mac 的那种，而是像我一样，对于每天处理的任务，从 c/c++ 到 bash 几乎什么语言都能做到的那种。 前几天终于亲耳确认了是老大拍板要把团队内的脚本语言都统一成 python。作为团队一直在使用 perl 做主力脚本语言的我瞬间感觉胸闷。所以下面牢骚居多。 其实老大也明白，像 perl vs python 这样的传统圣战题材，是争论不出个所以然来的。之所以拍出这个决定，是为了减少团队的代码维护成本。这中间我隐隐约约嗅到了点 perl 代码难以维护的意思。 水母 perl 版主 flw 认为，代码维护难度的决定因素是写代码的人，而与语言关系不大。我补充认为，能写出无法维护的 perl 的人，写出来的 python 也靠谱不到哪儿去。 换一个角度，合格的程序员更应该对未知事物充满好奇。在 2009 年刚刚进入团队的时候，我对 perl 一无所知，当时反而是还写过一点 python。这些年下来，perl 沉淀为首选，其实经过了相当漫长的自然而合理的选择过程。与此同时，我也在维护着一部分 python 代码。两者各有其擅长的场景，通过数据而不是语言来耦合，我觉得这样最有效率。如果哪天出现一种在我的任务领域更有表达力的语言，我也一定乐于学习（请复习 程序员的三大美德 ）。 所以当听到对于语言的强制规定时，我的第一反应是团队的人员要出问题。 以我不长不短的从业经历，还真碰到过一次强制规定语言的案例。那是刚工作不久。某元老级网游公司把原来外包给我们用 ruby 实现的支付系统用 c++ 重写了，也是号称为了降低维护成本。结果是以成本导向招进来的驾驭不了 ruby 的人也很难驾驭那个用 c++ 重写的系统。几年后这公司垮了。 这里可能还有屁股决定脑袋的问题。当领导的大概都喜欢整整齐齐的经济林，因为树苗可以批量供应，既便宜管理起来又方便。而在下面当树的，不想长成参天大树的恐怕不会是什么好种子，而经济林里大概很难长出参天大树来。 至于是经济林好，还是原始森林好，这又是个圣战潜力题材。怕是战不出结果的。 食君之禄，忠君之事。我目前正在用 python 重写以前的工具。不过我有两个愿望：第一个是但愿我的第一反应是错的；第二个是...