Hello Everybody,

我一直在思考两个问题：
对于个人，我们的技术如何更快地成长？同样的技术能力，如何才能工作生活得更有效率？
对于团队，如何才能更有效地沟通、协作？如何形成舒适的工作氛围？如何达到能力互补，具备强大的整体战斗力？

每当观察到一个相关的现象，我都会把它记下来，待到下周一时与大家分享。可是，看到大家那么严肃的样子，我又反思自己是不是说得太过份了……。

我想，不如我换一种做法，把它写下来吧。恰巧现在是我们年中总结的时机，那么，就从这次开始。

下面是随机记录的一些事情，没有多大的逻辑关系，也不一定是正确的，只是我一时的想法，和大家共勉。:-)

————————————————————————————

珍惜时间：
并不是说大家不珍惜时间，相反，都很努力。我只是感叹时间真的太宝贵。在学校的时候，我们常说青春、青春易逝，那个时候只是在无病呻吟；如今，像是真的能看见时光在眼前流逝。一晃之间，一个星期就没了，一个月也没了，不小心就到了年底。好在我们还没有七老八十，还有一丝资本可供挣扎，我愿与大家共勉：不徒费了光阴，努力使它过得有点意义。倒不是说，要大家多加班，努力工作自然是好事，工作之外有意义的事情也是好的。譬如，钻研跟工作关系不大的技术，或是提高提高自己人文方面的修养。重要的是，我们是清醒的，并且是高效的！

对自己的作品负责：
实话说，这是我对大家不太满意的地方，特别是两位新同事。你们已经转正了，我希望你们在学校或者别的地方养成的敷衍的习惯，能够到此终止。
一件事情交给我们，我们就要对它负全责。首先思考，应该采用什么方法，有多少种可能，它们的优缺点是什么，怎么选择。考虑了，拿不定主意，那只是经验的欠缺；但如果什么都不想，就等着别人来给我们画好条条框框，那就太没有追求了。
特别是，做完的东西，自己要把好关。这个作品，它代表了你的态度品味、技术水平，你自己是否满意？举个明显的例子：代码评论那个，难道开发完了，不会自己试一下的！？要知道，我是真心地相信它完成了，实实在在地在使用，并不是来做边界测试挑刺的，结果第一次用就出了问题。类似这样，我拿到手里随便看一下就发现无数问题的例子太多了……。
我们是一个靠谱的团队，这是得到公司其他部门认可的。我希望，靠谱的人不要做出不靠谱的事来；更希望，这个靠谱，不是经过我加工出来的。每个人，他的作品直接拿出去，都应该是自豪的、经得起推敲的。

细节的讲究：
我看到很多重复的、无意义的 commit log，有人可以解释一下你为什么这么懒吗？我看到有文件名是 js.js、css.css，请问，取个有意义的名字真的这么难吗！？不光如此，也包括目录名、类名、方法名，以及很多其它的细节。将各种细节问题揭示给大家，确是我的职责，但我更希望大家自己能有发现这些细节的眼光。

学习借鉴、拓展视角：
有时候，我们做的东西在公司内部或者市场上已经有可借鉴的案例。大家不妨多参考一下。当然，并不是说看得越多越好，重要的是我们看的时候要有思考。先要有自己的构思，在构思的过程中，就可能会对产品的概念、特点、设计、实现技术、实现形式等等产生疑问。带着我们的疑问去看案例，才能“内行看门道”，否则只是流于浮表，看了也白看。对于案例中与我们想法不一致的地方，应该思考它为什么这样设计/实现，哪种方式更优。以及案例整体的逻辑结构、用户体验等等，是否合理，是否有改进的余地。
另外，有的产品会在宣传中声称“遵循国际xxx标准，实现国内yyy规范”。我想，应该有这个敏锐，第一步就是去搜这所谓的标准、规范到底是个什么东西（如果还不知道的话），它针对的是什么行业、试图解决什么问题、大概概念是什么、有什么启发、是否适合我们、是否要具体跟进……。这对拓 宽我们的视角是很有帮助的。

抽象能力、把握全局：
作为一名程序员，如果搞不懂某项具体的技术，自然是很不爽。但我们也很容易陷入技术的细节当中，以致只见树木不见森林。抽象能力，是我们应该自我训练的重要能力。除了基本的对事物的抽象，还有对复杂系统提纲挈领的理解。了解一个软件产品，我们首先需要了解它对用户意味着什么、具备什么功能；然后，从技术架构上，大体上分为几个部分。有了大的概念之后，再进一步深入技术细节。这样，系统总体上是什么样子、我们当前处于哪一步，在脑海中就有一个清晰的印象。

主动反馈：
有的同事，好像从来不曾主动向我反馈过他的工作状态。你现在在做什么？有什么进展？遇到了什么问题？……。我已经在工作流程和其它地方强调过多次了，我的职责要求我知道整个团队现在处于什么状态。告诉我一下工作进展，没那么难吧？你不说，我只好去问了。其实我不想问的，我不想给大家太大压力。下回，当你觉得我老逼问你，很讨厌的时候，请反思一下，你是不是太久没让我知道你的进展了。我觉得 leask 同志有时候做得很好，吃饭的时候简单交流两句，即交流了工作，又有了闲聊的谈资。工作中有数不清的细节，如果靠一个人，一个个去检查，会累死人。希望大家在自己的工作责任范围内，做到主动反馈，给我留点时间做别的事情。

积极讨论，踊跃发言：
头脑风暴的时候，就是要随便说，想到什么说什么，大家不用那么严肃。。。平时多思考、多积累，当你有了自认为很好的想法的时候，就会自信很多。有时候就算是不太合适的方法，说不定也能启发别人的思路呢。我的经验，我经常会在讨论中蹦出不错的想法，这些想法并不是讨论之前准备的，而是在讨论中受了别人的启发。

不是搞定一项技术，而是解决一个问题：
解决方案，用来满足用户需求的一个方案，说白了，就是解决一个问题的方法。技术，都是试图用来解决具体问题的，当我们面对技术迷雾的时候，不妨问自己一句：我要解决什么问题？这并不一定是纯业务的，技术上也一样。
比如我们前段日子搞 NBGit，其实 NBGit 并非我们的目标，我们真正的需求，是建立一套规范合理、简单好用的 Git 工作流程。有了这个概念以后就知道，我们不能简单地宣布 NBGit 不好用，放弃之，我们必须得寻找到一个好用的方案。NBGit 的作者若遇到问题，需要跟它死磕到底，直至觉得无法解决，放弃项目，终止；寻找 Git 工作流程解决之道的人，只要发现有更好的办法，马上可以放弃 NBGit，放弃之后也并非像前者一样，是任务的终止，他需要确定新的方法。
我知道，搞技术的人，对所谓的业务、解决方案都很头疼，觉得拐弯抹角，不直截了当。这是另外一种看问题的角度，习惯之后，我们就能从另外一个角度看到另外一种风景。也会发现，跟非技术人员交流，变得简单了很多～。

不要未加工的资料：
有时候，我需要大家帮忙调查、对比一些技术/工具，可是结果有时有点无语，是原生生地从 Google 抄下来的资料。我自己不会搜么？优秀的做法，是认真去看这些资料，看明白咯，搞懂咯，写出你的理解。它们各自有什么优势、劣势，建议采取哪个方案，为什么，它的优点有多大的意义，缺点应该怎么避免……？

理清逻辑，找到问题的根源：
同事之间多讨论是好事情，更好的，是我们在讨论之前先把问题想明白。有时候，我们把同事叫过来，却又说不清楚自己的问题。最好，在讨论之前，先自己跟自己对话，或者假设桌上的笔筒是你的小听众。把问题的逻辑搞清楚，我要做什么？做了什么？怎么做的？遇到了什么问题？有什么可行的方法？怎么选择？……若是问题太多、脑子太乱，就拿出纸笔把它写下来。
我想，我这些字大家很可能轻轻地一看而过。但是如果你没试过，我强烈地建议你试一试。我的感受，这个方法简单却很管用。很多时候自己跟自己一对话，逻辑清楚了，问题就随之解决了；有时候脑子里想不明白的问题，在纸上简单地写一下，结果就很明了。

总结 而非 汇报：
总结是为自己而做，沉下心来，安静地思考自己的成长。
有些同事，贴一段代码就算完成任务。代码，版本库里不是有么？重要的，是要解释清楚。假设你面前是一个完全没听过这个概念的人，整理好你的思路、说辞，要尽量让不懂的人看后觉得清晰明了。这样，我们写的东西对团队其他成员才有帮助。更重要的，是在这个过程中，理清楚自己的思路、加深对技术的认识。这对我们的逻辑概括能力、总结表达能力也都是很好的自我训练。

把工作安排得井然有序：
有时候，我给大家说的是一些比较大的任务，实际上可以细分成更具体的内容；或者，你自己在开发过程中又想到了很多的问题。光靠大脑是不够的，太多太乱太疲惫、丢这忘那。我建议大家在项目管理系统中记录下来，建一个任务，分派给自己。这样，有多少事情、状态怎么样，一目了然。当然，是记在 issue tracker 里，还是记在本子上，要看个人喜好，但是没有记录肯定是很容易出问题的。我个人，是把所有想到的事情记在 issue tracker 里（大家可以去围观），但把当前最重要的两三件事情记在本子上，摊在面前。

提问题、证实自己的想法：
老总说的听说读写几个方面，我觉得都很实在、很有道理。其它几个属于个人素养，需要自己慢慢悟。我觉得听这方面，提问题的方法，尤其有现实意义。我们已经出现过几次这种情况：我说的时候对方表示很好，做完了却发现不是我想要的。当你不太有把握的时候，不妨多问几个问题。是不是我理解的这样？几个问题下来，我们就能达到理解的一致，或者发现存在的误差。

注重积累，Wiki 是不断改进的：
我们的 Wiki 现在已经有了不少内容，但请不要觉得 Wiki 写完了就完成任务了，若是发现有可改进之处请毫不犹豫地更新！特别是在我们工作的过程中，重复处理 or 重复回答的问题，记在 Wiki 里沉淀下来也许是个不错的方法～。

愉快的心情、健康的身体：
我是个爱运动的人，可是安排得不太好，实际上运动很少，肩膀和腰都经常不舒服。大家好像比我更少运动，时间久了也会不舒服的。我有时候去游泳，完了之后觉得浑身通畅，像是小说里说的打通了任督二脉。建议大家，根据自己的爱好，做个规律的运动计划。共勉！:-)

记录的主要的内容终于写完了……，个别具体的事项再当面讨论。

stay hungry, stay foolish!

————————————————————————————

既然说是年中总结，我也总结一下自己半年来的主要工作。

团队建设：
从人员的招聘到相互的了解，团队的风格，以及思考各个成员及团队整体的能力塑造。我的指导原则，是要以个人鲜明的影响力保证团队在一条正确的道路上快速前进；同时做到中庸与无为，即，在具体的工作中淡化个人的作用，给团队其他成员发挥能力的空间。

工作机制与工作流程：
我们工作的各个环节，基本上都形成了适当的机制。除了开发，其它像招聘时的面试、笔试、评价这样的行政工作，我也都总结出了通行合理的做法。使得第一遍做过的事，以后在此成果与经验基础之上，用少得多的时间即可完成。努力的目标，就是使我们的工作流程，在“最优的机制+最优的工具“的帮助之下，达到“优雅、高效、智能、惬意“。

需求理解与技术设计：
这指我们已有的三个产品。

广泛涉猎：
作为职责，我可以不进行具体的开发，但如果我对产品与相关技术没有整体的把握，则是失职。涉猎的内容，有的是与产品技术直接相关的，有的则是更底层的基础技术，或是大一点的概念如企业IT建设的方方面面，都是我关注的内容。技术之外，像需求、规范、设计等等也是涉猎的内容。视角的广度与深度，决定了决策的优劣。作为个人目标，我希望自己能做到：一手拿RFC、一手拿国家发展计划纲要；脑袋里构思出一套解决方案，一半想的是纲要里的战略需要、一半想的是RFC 里的技术实现。。。

总的来说，这半年来，虽然细节上做得还不尽完美，但实质上没有遇到大的挑战。所需的种种能力，都是自己多年来努力培养的目标。

————————————————————————————

我对自己不满意的地方，是整体的工作效率不够高，自己寻找原因：

客观原因：
如身体、距离、设备等，不细述。

并发而琐碎的工作事项：
相对来说，以前主要还是搞技术，具体的技术，一沉进去就是数个小时。现在，更多的是一些小块的工作事项。频繁地在任务之间切换，一会是技术问题、一会是业务问题，以及一会思考团队、一会执行行政任务，适应起来还是有点问题，有时候把自己搞晕了，不知道在做什么。

偏重逻辑的思维方式：
有时候需要参考一些文章，类似企业IT战略、产品的介绍资料之类的。这样的文章往往写得十分的概念化，几年前初看这种文章时，我会感到非常气愤，觉得全是废话，直接说用到了什么技术、什么标准、什么工具不就得了吗？！现在好多了，能够平心静气地看下去，试图从中挖掘出一些有价值的观点、策略或技术。但有时候还是会头大。

行政工作：
行政工作耗费了我比想象中多很多的时间。除了必要或者不必要的往复交涉，以 Word 为核心的工作流也是一个原因。大部分同事交上来的资料，或者管理部发过来的模板，格式都不够好，而我又不希望从我手里出去的东西有太大的瑕疵。我以前不太用 MS Word 的，因为以上原因，不得不在页眉、行距、表格属性……以及各种疑难杂症上耗费了不少时间。希望我们的工作流产品完成之后，能先在自己公司成功部署。Web 化是我的目标，它不仅仅简化了表面的格式设置，也为数据的收集、搜索、统计等再利用提供了方便。

————————————————————————————

完了。感谢阅读（滚动到最后…）！

add

添加新文件到 Git 代码仓库的索引中

$ git add filename

mv

移动或重命名文件

$ git mv old-filename new-filename

rm

从工作目录和 Git 代码索引中删除文件

$ git rm filename

status

查看目前工作目录的代码状态，自上次提交以来的添加、修改和删除等

$ git status

diff

查看自上次提交以来，本地代码改动的具体情况

$ git diff

commit

提交修改的代码（只是提交到本地的代码库，不会推送到服务器）

$ git commit -am '修改说明'

如果觉得刚提交的“修改说明”写得不够好，可输入以下命令调整

$ git commit --amend

push

将自上次 push 以来的，本地历次 commit，推送到服务器

结合我们的实际，应该这样写：

$ git push origin master:your-id

其中，master 是本地的分支名；your-id 填你在服务器上的 id，服务器的版本库里会有以你的 id 为名称的分支。

pull

将别人推送到服务器的代码，拉到你的机器里

$ git pull

log

查看修改记录，含作者、时间、修改说明等

$ git log

show

显示具体的代码改动情况

显示最后一次 commit 修改的内容：

$ git show

显示指定 commit 修改的内容：

【TIP】git log 命令中，每条 commit 会有一长长的字符串，此即 commid id，取其前面五六位即可。

$ git show commit-id

branch

分支管理

列出所有分支（当前所在分支前会有“*”号）：

$ git branch

新建分支：

$ git branch 新分支名

删除分支：

$ git branch -d 欲删除的分支名

【注意！】不要把 ‘-d’ 写成了 ‘-D’，危险！

• -d：要求：被删除分支的所有修改，已经合并到当前分支；
• -D：直接删除，未合并的代码，将被丢弃！

checkout

恢复某个已修改的文件（撤销未提交的修改）：

$ git checkout file-name

切换到另外的分支，进行开发：

$ git checkout branch-name

【注意！】该命令可能伴随大量的文件增删/修改。Windows 下，改动已被占用的文件可能会被拒绝，导致版本库出现严重问题。如果确实要这样做，安全起见，最好先注销一次。

merge

合并指定分支到当前分支：

$ git merge branch-name

revert

还原已提交的修改（已经提交过的修改，可以反悔～）

还原最近一次提交的修改：

$ git revert HEAD

还原指定版本的修改：

$ git revert commit-id

stash

先将未提交的修改暂存起来，接着清除所有改动，使之与没修改时一样。

若你正在开发功能 A，又需立即去开发功能 B。A 的代码正改到一半，未认真整理，你不想立即提交。此时……请呼叫 stash ～。

它会使你所有未提交的修改瞬间不见了：

$ git stash

它会使刚刚不见了的修改，瞬间又回来了：

$ git stash pop

【TIP】以上命令皆有更多参数，另有一些 Git 命令我们此处没有介绍。但是，这已足令你使用 Git 时游刃有余，你会觉得，Git 简直是一件神器！:-)

【TIP】’$ git help’ 与 ‘$ git help 命令名’ 会在你需要的时候，无私地帮助你。:-)

附：git push 失败的解决办法

假设执行操作：

1. 修改代码
2. git commit
3. git push

此时 push 失败（错误提示：! [rejected] master -> master (non-fast-forward) ）

解决办法：

$ git pull

若成功，则：

$ git push origin master:your-id

完事。

若失败（提示：CONFLICT (content): Merge conflict in 文件名），则：

冲突的文件会有类似下面的代码块：

<<<<HEAD
你修改的代码
============
其他人修改的代码
>>>>>commit id of others'

考虑你和他人对代码的修改，更新成合适的内容，并删除 <<<、===、>>> 3行标记符号，保存文件。

$ git commit -am "resolve conflict"
$ git push origin master:your-id

更详细的说明，可以阅读 $git push –help 该文档的 NOTE ABOUT FAST-FORWARDS 一节。

默认安装：msysGit

二、配置

1、C:\Program Files\Git\etc\gitconfig 添加：
【注意！】请将第二行最后的 “your-id” 修改成你在服务器上的实际 id，默认是姓名拼音。

[alias]
    go = "! bash -c \"git pull && git add .; if [ \\\"$*\\\" == \\\"\\\" ]; then git commit -a; else git commit -am \\\"$*\\\"; fi; git push origin master:your-id;\""
[core]
    autocrlf = false
[gui]
    encoding = utf-8
[i18n]
    commitencoding = GB2312
[user]
    email = xxx@gmail.com
    name = 某某某

2、C:\Program Files\Git\etc\inputrc 修改两行为：

set output-meta on
set convert-meta off

3、C:\Program Files\Git\etc\git-completion.bash 末尾增加：

alias ls='ls --show-control-chars --color=auto'

4、C:\Program Files\Git\etc\profile 末尾增加：

export LESSCHARSET=utf-8

【TIP】以上文件最好使用支持 unix 格式的编辑器修改（如 Notepad++、NetBeans），最次也用“写字板”而非“记事本”。

【TIP】若想了解为什么这样设置，请参见：Windows 下 Git 客户端的选择，及 msysGit 各种中文问题的解决

三、生成密钥

安装完后，需要生成一对 Key（这里指密钥），然后才能通过加密的方式和服务器的代码库取得同步。

到开始菜单，找到“Git Bash”，运行之，并执行以下命令：

$ ssh-keygen -t rsa

程序会提示您输入密钥的文件名，直接按回车即可。
然后会要求你输入一个密码，将来在使用密钥的时候需要提供这个密码。可以输入，也可以不输入直接回车（无论输入还是不输入，都会要求你确认一次）。
确认完毕后，程序将生成一对密钥存放在以下文件夹：

C:\Users\Administrator[这里替换成你的用户名]\.ssh

密钥分成两个文件，一个私钥（id_rsa）、一个公钥（id_rsa.pub）。
私钥保存在您的电脑上，公钥交项目负责人添加到服务器上。用户必须拥有与服务器公钥所配对的私钥，才能访问服务器上的代码库。

【注意！】为了项目代码的安全，请妥善保管你的私钥！因为一旦私钥外泄，将可能导致服务器上的代码被泄漏！

四、使用

1、克隆代码库

使用 Windows 资源管理器，打开你打算存放项目代码的文件夹，点右键选择 Git Bash。

在我们的项目管理系统中，每个项目的首页，都有写明代码克隆的地址，比如我们用于测试目的的沙盒项目：

$ git clone your-name@testing.aysaas.com:/var/projects/sandbox

在 Git Bash 中运行这条命令就能将沙盒项目中的所有代码（其实只是几个随便测试的文件）克隆到本地。

接着您就可以打开习惯的 IDE（如 NetBeans），投入到项目的开发中啦～！

【TIP】上面命令中的 your-name 要改成你在服务器上实际的用户名。

2、查看修改差异

开发过程中，如果你想了解修改了哪些代码，总览所有代码的改动情况，可以在 Git Bash 中输入此命令：

$ git diff

【TIP】Git Bash diff 的时候有两个缺点：一、窗口太窄，可能显示不下整行的代码；二、如果代码中有中文，会乱码。如果你碰到这两个问题，可以在项目文件夹下点右键，选择 Git Gui。

3、提交修改

每当完成一个阶段的代码，就需要提交代码以记录进展，方便日后查找问题以及团队协作。

$ git go aaa 修改说明（改动了什么？为什么这样改？）

【TIP】别忘了 go 后面的 aaa，关于 ‘git go’ 命令的详细说明，请参见 Windows 下 Git 客户端的选择，及 msysGit 各种中文问题的解决

【TIP】请尽量养成勤提交的好习惯。当代码不幸出现问题时，比较容易找出从什么时刻开始出现问题，并回退到该时刻进行调试，最大限度保护已完成的阶段性工作。

【TIP】以上命令，都需要在项目目录下运行。Git Bash 在命令提示符前，会显示当前所在的目录。如果当前不在项目目录之下，需要用 cd 命令切换到项目所在目录。
简单的办法，就是先在资源管理器里打开项目文件夹，再点右键，选择 Git Bash。

五、总结

至此，从获取代码、查看差异、到提交代码，整个流程都熟悉了。Git 还有比较高级的技巧，大家可以参考 Git 进阶功能 或在线找进一步的资料学习。

第二个则是：TortoiseGit，SVN 小乌龟的 Git 版本。
评价：该有的功能基本都有了，还是不错的。

另外，TortoiseGit 只是 GUI 工具，使用它需要先安装 msysGit，这是正宗的 Git 之 Windows 版本。msysGit 有个简单的 GUI 工具，及简单的 Explorer 集成；但它自带的 Bash 非常好用，深得 Linux 的真传。

选择：msysGit。
理由：
NBGit 不用说，功能都不完善，还需要自己定制 bat 脚本（若此，则它同样要依赖 msysGit）；开发不活跃，很可能 NetBeans 下个版本更新就不能用了；况且，我们还有别的项目，不使用 NetBeans。

TortoiseGit 从功能上说是完善的，但它只是功能的堆砌而已，使用时完全体会不到 GUI 带来的便利。相反，它让人感觉很繁琐，一个劲地点鼠标，点来点去全是跟菜单打交道，远离了 Git 命令、远离了 Git 输出提示、远离了真相。

msysGit 的 Bash 非常好用；加上 Git 强大的 alias 功能，我们完全可以自定义一个 $ git go，使得 90% 的情况下只需要这一个命令，即使是不熟悉命令行的 Windows 用户也会觉得很好玩；因为 NBGit、TortoiseGit 都需要 msysGit 做底层，我们直接用底层工具也避免了上层 GUI 带来的额外的 bug。

需要的配置：

1、C:\Program Files\Git\etc\git-completion.bash：

alias ls='ls --show-control-chars --color=auto'

说明：使得在 Git Bash 中输入 ls 命令，可以正常显示中文文件名。

2、C:\Program Files\Git\etc\inputrc：

set output-meta on
set convert-meta off

说明：使得在 Git Bash 中可以正常输入中文，比如中文的 commit log。

3、C:\Program Files\Git\etc\profile：

export LESSCHARSET=utf-8

说明：$ git log 命令不像其它 vcs 一样，n 条 log 从头滚到底，它会恰当地停在第一页，按 space 键再往后翻页。这是通过将 log 送给 less 处理实现的。以上即是设置 less 的字符编码，使得 $ git log 可以正常显示中文。其实，它的值不一定要设置为 utf-8，比如 latin1 也可以……。还有个办法是 $ git –no-pager log，在选项里禁止分页，则无需设置上面的选项。

4、C:\Program Files\Git\etc\gitconfig：
[alias]
go = “! bash -c \”git pull && git add .; if [ \\\"$*\\\" == \\\"\\\" ]; then git commit -a; else git commit -am \\\”$*\\\”; fi; git push origin master:your-id;\”"

说明：强大的 alias，有了这个，我们 90% 的情况下只需要输入 $ git go 这一个命令，免去了先拉后提交再推的繁琐步骤。

两种用法：
$ git go
或
$ git go aaa 修订说明

命令后带修订说明时，会直接提交。需要注意的是，在“修订说明”之前，有还个“aaa”，这是个 bug，参数中的第一个会被忽略，所以随便写一个凑数的……。

若命令行里没有提供修订说明，则会自动弹出一个编辑器，等待输入。默认的编辑器是 Vim。Vim 的使用是很简单的，首先要明白它有两个模式，一个是命令模式、一个是输入模式。Vim 启动的时候默认的是命令模式，需要先按’i'键，进入输入模式；然后就正常编辑；编辑完成之后，将输入法切换回英文状态，按 Esc 重新进入命令模式；此时按 ‘(Shift):wq‘ 并回车，w 表示写入保存、q 表示退出。完毕！

若实在不习惯 Vim，也可以设置为其它编辑器：

$ git config --global core.editor "notepad"

其中 notepad 可以替换为更好用的 wordpad、notepad++ 等（不过它们在命令行里无法直接访问，得先设置 PATH 变量）。

以上 alias 是为 Windows 定制的，Linux 下可以写得更优雅，不过鉴于使用上没分别，就保持一致吧～。

[gui]
encoding = utf-8

说明：我们的代码库是统一用的 utf-8，这样设置可以在 git gui 中正常显示代码中的中文。

[i18n]
commitencoding = GB2312

说明：如果没有这一条，虽然我们在本地用 $ git log 看自己的中文修订没问题，但，一、我们的 log 推到服务器后会变成乱码；二、别人在 Linux 下推的中文 log 我们 pull 过来之后看起来也是乱码。这是因为，我们的 commit log 会被先存放在项目的 .git/COMMIT_EDITMSG 文件中；在中文 Windows 里，新建文件用的是 GB2312 的编码；但是 Git 不知道，当成默认的 utf-8 的送出去了，所以就乱码了。有了这条之后，Git 会先将其转换成 utf-8，再发出去，于是就没问题了。

以上，给 Windows 下的同事在 Git Bash 里推代码就比较完美了。不过仍然有 3 个问题：

1、上面的 alias $ git go 有 bug，代码修订说明之前要输入一串字符凑数；

2、$ git diff，如果代码里有中文，会显示乱码；

3、$ git checkout 有时候需要修改/增删很多文件，如果某些文件被占用，会被 Windows 拒绝，导致失败，甚至可能造成版本库出现无法修复的问题。

这 3 个都是可承受的问题，前两个应该有办法解决；第 3 个归功于文件系统，只能尽量避免 checkout，实在需要的时候先注销一次，就不会有问题了。

【TIP】该文只是解释说明，具体操作请按《Windows 下 git 配置与使用指南》Wiki 执行。

Git 的强大、灵活、好用，毋庸置疑。

但也正是 Git 的灵活性，在公司推行时，如何执行统一的流程成为一个问题。我想了不少时间才制订出一个办法。

目的是规范、统一。还有就是，Windows 下的同事，特别是不熟悉命令行的同事，怎样才能使他们好理解，并且觉得简单（之前大家觉得概念太多，难以理解；步骤多，记不住，不小心就搞错，冲突频发）。

说到 Windows，Git 在 Windows 下不如 Linux 下好使，这也是一个需要考虑的问题。

同样是在公司 Wiki 上写的，再次拿到 Blog 来凑数呵呵～。

版本控制

——————
简单地说，就是将在本地开发的代码，定时推送到服务器。每一次修改，记录下它的作者、时间及修改说明等。

相对的，我们也可以从服务器下拉其他人推送的代码，并了解它的作者、时间、修改说明及其具体的修改内容。

这样，版本控制给团队协作开发提供了极大的方便。即使是一个人开发，因为它记录下了我们整个的开发历史，也是极有帮助和价值的。

比如，如果某次修改甚至整个系统出现问题，它也能帮助找回我们珍贵的代码。

分布式版本控制

——————————–
更进一步，分布式版本控制工具使得我们在本机上即拥有完整的功能，不依赖于服务器，使用更为方便。它们往往也提供其它更好用或更强大的功能，比如灵活的分支管理。

Git

——–
Git 是 Linux 之父 Linus Trovalds，为管理 Linux 内核代码而建立的，被认为是分布式版本控制工具中的顶级水准。智能、友好、强健、高效。

Git 工作流程

—————————-
1、使用中央服务器辅助协作；

2、每人在服务器拥有一个以自己 id 为名称的分支；

3、各人只许推送更新到自己的分支，不允许推送到别人的分支或者 master；

4、master 由专人管理，在合适时 merge 其它分支（开发初期每日自动 merge 各人分支，生产化后则由人工 merge 经过 review 的分支）；

5、代码修改 merge 到 master 后，将同步到所有终端。

【TIP】：熟悉之后，你可以创建类似 myId_branchName 的其它分支。

【TIP】：以上只是概念介绍，至于具体的操作，请参考：《Windows 下 Git 配置与使用指南》、 《Git 进阶功能》。

# apt-get install redmine redmine-mysql libapache2-mod-passenger
_________________________________________________________________________

按：这是在公司 WIKI 上写的文章，难得这么认真，拿出来分享一下 ：）。对比过十多个项目管理系统，然后在比较好的 Redmine, Trac, Mantis 三个当中选择了 Redmine。文中以 Debian Squeeze 为例，但其它 GNU/Linux 特别是 Debian Lenny / Sid、Ubuntu 应该基本一致。

_________________________________________________________________________

一、废话

Debian 的库里有最新的 redmine 发布版（0.9.3），一个命令就可以搞定：

#apt-get install redmine

However……，安装后运行会出现 http 500 service unavailable 等问题。因为 Debian 只有 2.2.3 的 rails，而 redmine 0.9.3 要求 rails 的版本为 2.3.5。

我第一个想法是，既然库里有 redmine，就不折腾了，删掉 rails，再手工装一个新版本。可是 redmine 是依赖于 rails 的，要删得一起删。然后我就想，好，保留它，再装一个新版本覆盖之！就是这个想法……，最后遇到了很多问题，又因为对 ror 不熟，在这上面浪费了不少时间。

没办法，全 purge 掉，实实在在从头来吧。以下以 redmine-trunk 版为例（解决了 0.9.3 中存在的 wiki+php 等一些 bug）。

注：以下 # 开头的命令需以 root 身份执行。

二、依赖关系

#apt-get install ruby rubygems rake mysql-server mysql-client libmysql-ruby libopenssl-ruby
#gem install rails

三、下载 redmine

/var/projects#svn checkout http://redmine.rubyforge.org/svn/trunk redmine

注：稳定发行版本下载 http://rubyforge.org/frs/?group_id=1850

四、创建数据库

# mysql -u root -p
mysql> create database redmine character set utf8;
mysql> grant all privileges on redmine.* to redmine@localhost identified by 'PASSWORD';

五、数据库配置文件

/var/projects/redmine#cat config/database.yml
production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: PASSWORD
  encoding: utf8

六、生成 session key

#rake generate_session_store

会将结果写入 config/initializers/session_store.rb

七、初始化数据库结构

#RAILS_ENV=production rake db:migrate

八、导入默认设置到数据库

#RAILS_ENV=production rake redmine:load_default_data

九、预览！

#ruby script/server webrick -e production

然后可以用浏览器访问 http://server:3000/ ，待测试没问题再继续。

十、用 apache 运行 redmine

WEBrick 虽然能跑，但是超慢！慢到无法忍受的地步（好奇的是，内存和cpu利用率都超低，它在干嘛呢……）。

安装：

#apt-get install apache2 libapache2-mod-passenger

权限：

#chmod -R g+w redmine
#chown -R root:www-data redmine

符号链接：

#ln -s /var/projects/redmine /var/www/redmine

配置文件：

#cat /etc/apache2/conf.d/redmine
RailsEnv production
RailsBaseURI /redmine

Done:

#/etc/init.d/apache reload
$firefox http://server/redmine/

十一、安装/修改 主题/样式（可选）

Redmine 支持基本的主题自定义（可以覆盖默认的 css）。

可以到 http://www.redmine.org/wiki/redmine/Theme_List 下载别人的主题包，解压后将包目录放到 public/themes/ 下面。

#/etc/init.d/apache reload

之后，即可访问 http://server/redmine/settings?tab=display 选择新的主题。

不过我觉得还是默认的耐看。我直接对默认的主题做了一点修改：

--- public/stylesheets/application.css    (revision 3628)
+++ public/stylesheets/application.css    (working copy)

+tr.priority-1, table.list.issues tr.priority-1 a { color: black; }
+
+tr.priority-2, table.list.issues tr.priority-2 a { color: #1c1cf3 /*similar to blue*/; }
+tr.priority-3, table.list.issues tr.priority-3 a { color: #1c1cf3; font-weight: bold; }
+
+tr.priority-4, table.list.issues tr.priority-4 a { color: red; }
+tr.priority-5, table.list.issues tr.priority-5 a { color: red; font-weight: bold; }
+
+tr.status-3, table.list.issues tr.status-3 a,
+tr.status-4, table.list.issues tr.status-4 a { color: green; font-weight: normal; }
+
+tr.status-5, table.list.issues tr.status-5 a,
+tr.status-6, table.list.issues tr.status-6 a { color: gray; font-weight: normal; }

以上加的几行，使得以不同的颜色区分不同优先级（低/高/紧急等）、不同状态（新建/进行中/反馈/已关闭等）的 issue。

十二、安装插件（可选）

很方便，下面是安装 email tls 插件的例子：

#ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git

更新数据库：

#RAILS_ENV=production rake db:migrate:upgrade_plugin_migrations
#RAILS_ENV=production rake db:migrate_plugins

十三、配置 email 发送功能 —— 任务建立/变更时，发送邮件提醒（可选）

以 GMail 为例，先要安装上一步提到的 email 插件，然后:

#cat config/email.yml
production:
  delivery_method: :smtp
  smtp_settings:
    tls: true
    address: "smtp.gmail.com"
    port: 587
    domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps
    authentication: :plain
    user_name: "xxxxx@gmail.com"
    password: "xxxxxxxxxxxxxxxx"

完了 reload apache 即可。这里 http://server/redmine/settings?tab=notifications 有一些设置选项。我去掉了 bcc，选中了纯文本。

修改 1:

--- app/models/mailer.rb    (revision 3628)
+++ app/models/mailer.rb    (working copy)
-    subject "[#{issue.project.name} - #{issue.tracker.name} ##{issue.id}] (#{issue.status.name}) #{issue.subject}"
+    subject "[#{issue.project.name} - #{issue.tracker.name} ##{issue.id}] #{issue.subject}" 

     s = "[#{issue.project.name} - #{issue.tracker.name} ##{issue.id}] "
-    s << "(#{issue.status.name}) " if journal.new_value_for('status_id')
     s << issue.subject

修改的目的，是使得 redmine 发送的邮件提醒在标题中不要包含 issue 的状态（新建/进行中/已关闭等），从而使得关于同一个问题的所有提醒邮件在 GMail 中都能自动组织成一个会话，非常有利于上下文的理解。

redmine 默认在邮件标题中包含 issue 的状态信息，使得每一次状态变更的邮件都分散到不同的会话中，很讨厌。

修改 2:

--- config/locales/zh.yml    (revision 3628)
+++ config/locales/zh.yml    (working copy)
-  text_journal_changed: "{{label}} 从 {{old}} 变更为 {{new}}"
-  text_journal_set_to: "{{label}} 被设置为 {{value}}"
-  text_journal_deleted: "{{label}} 已删除 ({{old}})"
-  text_journal_added: "{{label}} {{value}} 已添加"
+  text_journal_changed: "{{label}}：{{old}} -> {{new}}"
+  text_journal_set_to: "{{label}}： -> {{value}}"
+  text_journal_deleted: "已删除：{{label}} ({{old}})"
+  text_journal_added: "已添加：{{label}} {{value}}"

对中文翻译的一点修改，这是邮件提醒中对 issue 变更的说明，我觉得太啰嗦了，不直观明了，没有重点。

注：如果你发现发出去的邮件，issue 链接都是带 3000 端口号的，而你现在用 apache 跑 redmine 不需要端口号，可以去 http://server/redmine/settings 改“主机名称”。这是因为你第九步的时候无意中保存过这个设置。

十四、打 patch（可选）

以下是作者提供的一个 patch，使得在 redmine 中，可以将任务指派给一个组/group，该组的所有成员都会收到邮件提醒（只是，该任务不会显示在“我的工作台”里）。

redmine#wget http://www.redmine.org/attachments/download/2965/0001-Allow-issues-to-be-assigned-to-a-Group.-2964.patch
redmine#patch -p1 < 0001-Allow-issues-to-be-assigned-to-a-Group.-2964.patch

注一：执行 patch 的时候，它会有一点小抱怨，可不予理会。

注二：http://server/redmine/groups ，此处可以增删/编辑小组及其成员。

十五、与版本控制软件集成（Git / Mercurial）

配置系统（使得只有组内的成员才可以查看/修改项目代码，不同的项目使用不同的组）：

#groupadd saas
#echo 'if [ "saas" == "$(id -gn $(whoami))" ]; then umask 007; fi' >> /etc/profile

Update：
在 /etc/profile 中设置 umask 只会影响 login shell，而我们通过 git push 过来的文件仍然是默认的 755 权限（修改 .bashrc 等亦无效）。

要设置 git push 到服务器的文件的权限为 770（同组成员可写），正确的做法是：

# echo "session optional pam_umask.so umask=007" >> /etc/pam.d/common-session

此外，以下方法应该也可以（没有测试）：

# echo "Subsystem git /bin/bash -c 'umask 007; /usr/bin/git'" >> /etc/ssh/sshd_config

安装 git：

#apt-get install git-core

初始化 git 版本库：

#mkdir /var/projects/saas
#cd /var/projects/saas
#git --bare init
#chown -R root:saas ../saas
#chmod -R 770 ../saas

版本库初始化完成，若要增加新的开发者（各自使用自己的帐号），由管理员执行：

#useradd -m -s /bin/bash -g saas username # 注意，若不指定，默认的 dash 会出错

并将其 pub key 添加到 /home/username/.ssh/authorized_keys 之内。

开发人员在客户端的操作：

$git config --global user.name "xxx yyy"
$git config --global user.email "xxx@gmai.com"
$git clone username@server:/var/projects/saas

测试：

$cd saas
$echo hello > world
$git add .
$git commit -a -m 'hello world'
$git push origin master

以后再 push，就不需要 “origin master” 这两个参数了。

最后，因为初始化版本库的时候我们用了 –bare 参数，在 /var/projects/saas 下是看不到项目代码文件的。

可以生成一份代码拷贝，用来在 apache 下进行测试：

#cd /var/www
#git clone /var/projects/saas
#chown -R root:saas saas
#chmod -R 770 saas
#addgroup www-data saas

开发者 push 完后，apache 下的代码并不会自动更新，若想测试（这个测试相当于预览，因为开发人员 push 之前是需要先在自己的机器上认真测试的）更新后的代码：

/var/www/saas$git pull # 注意，各用自己的帐号执行，不要用 root

至此，版本管理系统已经正常工作，还剩最后一件事：那就是告诉 Redmine，我们版本库的路径。

浏览器里打开 Redmine，新建一个项目，然后在“设置”里会有个标签叫“版本库”，选择 git，并在 path 里填 /var/projects/saas 就搞定了！

另，hg 的设置与 git 非常相似，大部分参数都一样，不另述。

十六、升级 redmine svn trunk（可选）

#svn update
#rake tmp:cache:clear
#rake tmp:sessions:clear

可能还要执行第七步和第十二步提到的更新数据库的操作。升级之前应该先备份，在测试实例上确认没有问题再升级。

十七、备份redmine数据

一是数据库：

#mysqldump -u redmine -p redmine > redmine.$(date +%F).sql

二是上传的文件：

/var/projects/redmine#tar cvzf ../redmine.uploaded.files.$(date +%F).tar.gz files/

（完）

一、顶部文章分类去掉“首页”（否则4个分类加“首页”，太长了，挤到下一行来了）

wp-content/themes/monochrome/js/jscript.js

> $("#menu > li:first-child").addClass("first_menu");
+ $("#menu > li:first-child+li").addClass("first_menu");
> $("#menu > li:first-child.current_page_item, #menu > li:first-child.current-cat").addClass("first_menu_active");
+ $("#menu > li:first-child+li.current_page_item, #menu > li:first-child+li.current-cat").addClass("first_menu_active");

wp-content/themes/monochrome/style.css

+ #menu li:first-child { display: none; }
> #menu .first_menu { border:none; background:none; }

二、点击某个分类后，文章标题字体过小

wp-content/themes/monochrome/style.css

- .archive_contents h2 { font-size:14px; margin:0 0 5px 0; padding:0; }
+ .archive_contents h2 { font-weight: normal; }

三、文章标题颜色不够明晰

wp-content/themes/monochrome/style.css

h2 a { color: green !important; font-weight: bold; }

四、避免分类页和搜索页中，将整篇文章的文字作为链接，改为只给“阅读全文”添加链接

wp-content/themes/monochrome/archive.php
wp-content/themes/monochrome/search.php

-<p><a href="<?php the_permalink() ?>"><?php the_excerpt_rss(); ?><span><?php _e('[ READ MORE ]', 'monochrome'); ?></span></a></p>
+<p><?php the_excerpt_rss(); ?><a href="<?php the_permalink() ?>"><span><?php _e('[ READ MORE ]', 'monochrome'); ?></span></a></p>

五、使搜索/分类页中的“阅读全文”显示更明显一点

wp-content/themes/monochrome/style.css

+ .read-more { color: green; font-size: 130%; font-weight: bold; }

六、隐藏 pre 的滚动条，实在是太丑了

wp-content/themes/monochrome/style.css

- pre { border:1px solid #ccc; background:#fafafa; padding:10px 20px; margin:0 0 1em 0; overflow:auto; }
+ pre { border:1px solid #ccc; background:#fafafa; padding:10px 2px; margin:0 0 1em 0; overflow:hidden; font-size:10px;}

七、删除 Atom Feed 链接，搞这么多干啥，让人迷糊 =_=!

wp-content/themes/monochrome/header.php

2009/8/13 definite <***@gmail.com>:
> 其實已經是了。 :-)
> 在 Fedora Rawhide (技術測試版，搶先版)裡的是 dev, 在現行支援的 Fedora 版本 就是 Stable。
> 所以， ibus-1.1 可視為 stable, 1.2 可視為 dev。
>

我一直用的最新版，还以为只有一个版本呢。这样的话，我有几个问题：
1、请问，在项目组的计划中，1.1 是最新的稳定版，还是只是一个老的开发版？
2、1.1 在发布之前是否经过了严格的测试，解决了已知问题？
3、如果 1.1 中发现了 reproducible 的 bug，是否会得到优先修复？

我想讲一个我自己的笑话 :-) 。

就在发本主题上一封邮件的时候，我也在升级系统，其中包括 ibus（我的系统 Debian sid/experimental, ibus 好像是从 1.2.0.20090723-1 到 1.2.0.20090806-1）。升级完后，我发现我输入不了汉字了。后来在 ibus-setup 中，找到了一个 “Use system keyboard layout setting” 的选项，选上，好了。

如果我把这个问题做一个 bug report，会被鄙视吧。确实，在这个问题上，ibus 没有 bug，可是这不应该是一个稳定版输入法的表现。

普通用户对于输入法的需求，就是随时随地在他／她需要的时候能打出字来。否则就写不了财报、写不了邮件、写不了合同……，就会严重影响他的工作，他就会打电话投诉服务商。如果服务商向他推荐的是 GNU/Linux 系统，他就会认为 GNU/Linux 系统打不了字，进而对此服务商心存疑虑（企业用户选择 GNU/Linux 作为办公环境，主要是信任服务商，而非单纯地认为 GNU/Linux 系统好用）。

我想，计算机系的同学对别的专业的知识不是样样精通吧。那么，我们也不能要求别的专业的用户花费大量时间，来学习计算机的知识。一个系统在他们眼里就是一个整体，他不会去分什么内核／桌面，甚至更多稀奇古怪的术语。如果 Firefox 出了问题，他们就会说 GNU/Linux 系统上不了网；如果 ibus 出了问题，他们就会说 GNU/Linux 系统打不了字。

用户关心的始终是自己的核心业务。我们推荐 GNU/Linux 时，从来都强调它很稳定、很安全，很简单、很好用。除了在服务端，在桌面端，GNU/Linux 系统也是 productive 的。对于普通用户来说，计算机是一个顺手的工具，时刻准备为你服务，而不是要你时不时地去伺候／配置一下。

希望这个笑话，可以让大家看到普通用户和开发社区的朋友看计算机的角度不太一样。在用户眼里，我们离稳定还有一些距离。如果说人手不够暂不考虑，自是合理，但希望稳定版是个方向。

GNU/Linux 不仅仅是一个可爱的玩具，它需要走向产品化，我们用自己的职业生涯努力促进这一进程。很多人反感“菜鸟”们来玷污他高深的玩具，但我想，一个真正认同自由软件理念的人，一定也是乐意分享、乐意看到自由软件发扬光大的。我们是同好，啰嗦之处请多包涵。：）

其实 GAppProxy 很早以前就挺好用了，但是一直有一个问题，就是很多时候会显示一个空白页面。显示空白的大部分都确实是不能访问的，并非 GAppProxy 搞错了。但是我对此很不爽，因为导致空白的原因是很多的。包括各种各样的异常没有catch，包括超出了 Google App Engine 平台的限制等等。它光显示一个空白，你根本不知道发生了什么。

前不久，我对它进行了各种边界测试，把能想到、能碰到的所有错误分类开来。然后在无法代理的时候，向用户浏览器显示一条信息。告诉用户现在是什么状况，具体是什么原因。dugang 也觉得这样很好，在我的基础上进一步细化了。然后，GAppProxy 1.0beta 发布了。

但是接下来的反馈有点出我意料。很多人说 GAppProxy 不能用了啊，怎么办啊？要知道，它以前输出空白的时候甚至没人反应过。

我有点纳闷：我不是解释得很清楚么，就那么一行字，您就不能看看？
后来我意识到，我们两都是典型的 Unix 的想法。就是认为，有问题你给它暴露出来，说明白咯、别藏着掖着。

但是用户有很多是 Windows 的用户。Windows 的一贯传统就是，把问题都藏起来，我们的用户是温室里的花朵，千万别让他们见到任何风雨。在这种风格的影响下，很多 Windows 的用户只要看见跳出一串英文就觉得很怕怕，根本不会去看它到底在说些什么。

其实，之所以有这么一串字符，是因为作者已经考虑到了这种情况。他既然已经考虑到了，自然会做最优的处理。这有什么好怕的。
反倒是那些出了问题也默不做声的，很可能是因为作者的逻辑出了问题，他根本没有考虑到这一点。还有什么比这更可怕的？

有时候我很想说：Don’t panic!

其实，我对很多事情充满着兴趣。比如说某一个知识点，我常常想，哇这玩意儿太牛叉了！一定要把它搞懂了、弄透了。然后开始幻想，如果这一切都了然于胸，自己将会多么牛叉。激情也就跟着来了，为了探个究竟，可以茶饭不思、夜不安寝。

按理说，我应该有很多话题想说的。可是偏偏，我又很“喜新厌旧”。无论之前觉得多么牛叉的东西，等到回过头来，都觉得不过尔尔，真的是沧海一粟、不值一提。大概这就是我的 Blog 好几个月才有一次更新的原因吧……。

虽然我对“物”喜新厌旧，但对“情”却是很怀旧的。这个 NN 年前的 Blog 的模板，我常常想换掉，常常打算换成独立 Blog，但都一直没舍得。自从与 Blogspot 并肩作战已经过去了 5 年，虽然成功地逃过了 GFW，但我与 Google 之间脆弱的协议，早已荡然无存。啊？什么？？？^H^H^H^H^H^H^H^H^H^H…..

P.S. “最近” 参与的一些社区活动：

Firebug 简体中文化。firebug 就不用介绍了吧。值得一提的是，虽然官方只写了我一个人的名字，但其实我开始这个项目的时候，已经有一些基础，并不是从零开始。作者说，是人家给他的，不知道是谁。。

Adblock Plus 之 ChinaList 维护。更不用介绍了。。一开始是一个台湾同胞维护的，不知什么原因他“失踪”了，我就接了下来，后来又成功地引诱了两个人加入~~。ChinaList 易主之后，有了天翻地覆的变化。很遗憾的是，它居然没进 ABP 的默认列表，偏偏我又是个不喜欢争的人。希望有一天作者会发现，我们维护得是多么认真负责，ChinaList 绝对算得上是列表中的典范。

e2fsprogs 简体中文化。e2fsprogs 是 Linux 内核中操作 ext2/3/4 文件系统的一系列工具的组合。比我想象的慢了不少，但是争取每个疑点都实际测试过后再作定夺。质量优先，慢就慢点吧。

加入 GAppProxy 项目。GAppProxy 最近才热起来，但其实这个项目开始已经快一年了。

AutoProxy。是 FoxyProxy 让我产生这些想法的。当时，我一方面欣赏 FoxyProxy 的强大，一方面又对它很不满。我就在想，一个“完美“的代理扩展应该是个什么样子。后来我把想法告诉了 FoxyProxy 的作者，费了老大的劲（几千的词汇量？）。他表示很有兴趣，但是好几个月过去了根本没动手。有个说法，这个东西 scratched my itch。我猜测其实他并不需要代理，自己都不是自己作品的用户，做起来自然没多少动力。原打算给 FoxyProxy 提交几个 patch 的，但是我对它的界面跟实现都很不满意。
AutoProxy 的传播超出了我的预料，本来只是打算非常小范围地测试一下看看反馈，毕竟很多想法还没完工。好在，从各方面反馈来看，没有什么大的问题。主要是菜单设置不合理，缺乏应有功能。这本来就在我的计划之中，正是下个版本首要解决的任务。