dot files

dot files是指以.开头的文件，比如说.bash_profile。在类Unix系统下，dot files是默认隐藏的。在Shell下，很多的工具使用dot file作为默认导入的配置文件。比如说Bash对应的.bash_profile和.bashrc。在Shell下查看这些文件需要用ls -a。在你的home directory下用这个命令，你可能会看到一些已经存在的dot files。

.bash_profile & .bashrc

虽然现在我只使用zsh，但是在切换到zsh之前，积累了一些bash相关的配置，所以也在这里一并列出来。首先是这两个文件的区别：

.bash_profile 是以交互式、login方式进入bash时会调用的

.bashrc 是交互式、non-login暗示进入bash时会调用的

所以我的.bash_profile里面只有一个调用.bashrc文件的代码，所有的其他设置都放到了.bashrc里面：

if [ -f ~/.bashrc ]; then
  source ~/.bashrc
fi

.bashrc里面主要是对一些常用的命令添加了缩写的别名，所以以前我和Eric经常会说一些黑话，比如说gps(git push)，gpl(git pull)之类的，而其他人不知…

上一篇介绍的都是GUI的工具，这一篇我会接着讲有关Shell方面的一些经验和技巧。就我所见，对很多从Windows背景转过来的Web开发人员来说Shell是需要迈过的第一道门槛。图形化的操作在很多情况下是很低效的，Shell能够玩得很熟练，将会对工作效率带来很大的提高。

Homebrew

在debian系的Linux系统（比如Ubuntu）下，可以使用apt-get方便的进行软件的安装，在Mac下也有几种类似的工具，比如说fink，MacPorts。但是我现在一般只用Homebrew。有关这三种工具的比较，可以参考这里，这里，还有这里。

安装Homebrew只需要在Shell下执行：

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

之后需要安装什么东西，可以先用brew info查看一下是否可以通过homebrew安装，比如说：

如果支持，运行brew install xxx即可。下面介绍的大部分Shell下使用的工具都可以通过homebrew安装。

wget and curl

上一篇我们进行了简单的系统设置，那么接下来应该开始安装软件了。

Mac AppStore

现在AppStore已经是Mac OSX的内嵌软件了。很多的工具都可以通过AppStore下载安装使用。当然，使用AppStore需要你有一个账户，下面提到的一些软件需要通过AppStore进行安装，所以如果你还没有账号的话，先去申请一个吧。

Launcher

用Mac的人都应该很熟悉大名鼎鼎的spotlight了。spotlight虽然已经很好用了，但是还是有不少可以改进的地方。现在市面上就有好几个用于替代spotlight的软件，比如说老牌的Quick Silver，和QS的作者被挖到Google去做的的Google QSB等。我使用了几个替代品，最终定下来坚持使用的是Alfred。

Alfred可以直接在AppStore上搜索出来进行安装…

以前陆陆续续的在Blog上有提到一些Mac下Web开发环境的小经验和技巧，正好年后会有三位同事加入Mac User的队伍，为了能让他们少走点弯路，也给自己理一下思路，干脆写了这样一个Mac下Web开发环境设置不完全指南。

• 我们在用Ruby on Rails进行Web开发，但是基本上大部分的东西也应该适合其他类型的开发工具和框架。
• 我所用的OS X的版本是10.7也就是Lion，但是除了系统设置之外的其他部分也应该使用与10.6的版本。

系统设置

Lion的系统默认安装好后，最好进行一些调整，以最大发挥系统的威力。

Trackpad 设置

这应该是我拿到新系统后进行的第一项设置了。首先打开你的系统设置（System Preferences)，找到Trackpad这一项，进行如下设置：

• 确认Tap to click和Secondary click是选中状态。第一个让你轻触触控板即可实现鼠标点击的功能而不需要…

说到source control，因为人上了些年纪的关系，以前用过不少，从最开始的vcs，到cvs，到svn，甚至什么mercurial啊clear case啊之类的都或多或少用过。从最开始的就把它当一个源代码备份工具，到后来了解到一些比较繁杂的源代码管理工作，有一个比较大的感触就是在多人同时开发的环境下，分支与合并始终是一件很麻烦的事情。Git，据说就是Linux之父在和很多人一起开发linux kernel的时候，实在是忍无可忍，无法再忍了用几天的事件开发出来的，而且一开始的目的就是为了让分支和合并的操作尽量的“廉价”。虽然我一直在自己工作之余尝试着使用git，但是直到我们开始做一个内部项目的时候，才开始真正每天都使用到了这个号称非常牛逼哄哄的源代码管理工具。当然，一用之下基本上就再也不想回到公司使用最多的svn上了。网上有关git的好处，与其他源代码管理工具的异同优劣之类的比较文章很多，都不是今天我写这个blog的重点。这个blog的重点是想要推荐一个我觉得比较好的使用git做分支与合并的开发模型。

实际上不管源代码管理工具是什么，你的项目采用的分支与合并的开发模型都很重要。相信需要用到分支与合并的项目基本上都会涉及到不少人，没有规矩，…

@lanvige 今天在微博上show bash completion，我上去回了一个不如试试zsh。@lanvige 希望我说个一二三出来，微博受字数限制，所以放到博客上来了：

• 自动补全

这个应该是一开始使用zsh的初衷吧。zsh的自动补全很强大，我简单的比较了一下bash completion和zsh的补全。区别在于，bash completion只是一个补全的提示，你还得照着提示继续输入。而zsh的提示出来以后，你可以继续用tab在候选的补全里面选择，然后回车选中该补全。

比如说上面的途中，我输入git，然后tab，就会出来一堆git的命令候选项，然后我继续tab，tab到那一个补全候选项上，当前命令行提示符上的输入就会自动跟着变成该候选项。选中我要的git命令，直接回车，就完成了一次补全操作。对于我这样不记详细命令而又懒得在键盘上多输入几次的人来说，zsh的自动不全显然更适合一些。

再来一个更有意思的。经常看到初学shell的同事在杀进程的时候会先用‘ps’命令找到相应进程的pid，然后再用‘kill’命令去杀。在zsh下，可以直接输入进程的名字用tab补全：

上图是tab补全后的截屏，而我实际的输入是‘kill rub’+tab。当然，如果有多个候选项可以继续用tab在候选项中进行选择。如果直接‘kill ’+tab，会出来所有进程的列表。…

Rails应用集群在淘宝自动化测试平台的应用

上周去上海参加了RubyConf。得知有这样一个conference是在微博上，当时看了一下日程安排，因为工作的关系，主要是对Rails应用集群在淘宝自动化测试平台上的应用这样一个主题感兴趣。以下是在听来自黄小勇的讲解时做的笔记，应该有不少遗漏的地方，等官方的slides放出来了之后再核对一下吧。

如何应对日益增长的需求

手段很简单-拆分。

淘宝的自动化测试平台的功能应该是不断的增长的。从黄小勇的slides上看到的，到后来（应该不是早期了）包含了很多方面的需求。比如测试用例的管理，测试报告的生成，项目管理，缺陷管理等等。按照我自己的经验估计，一开始应该是在一个Rails Application下面做了快速实现，然后发现需求越来越多，代码文件也越来越多，并且随着项目规模的增长，对开发人员（尤其是新加入的开发人员）的要求也越来越高（不是指技术方面，而是说开发人员需要理解非常多的domain相关的概念，才可能通盘理解整个系统），于是开始考虑拆分系统。这一点在今年早9月份在infoq上看到的一篇文章 Rails系统重…

想起若干年前在某大公司任职，有个规矩叫专有信息保护。当然，这个中文名是我随口胡诌的，时髦的英文叫法是“POPI”。他不是波比，也不是菠菜，他是Protection of Proprietary Information。

放到实际的操作上来说，就是每个人的小格子（其实跟我现在所在的格子比已经算非常大了，当然，这是题外话）上都有一张大大的印刷得相当精美的硬卡片。这个卡片的用途有点像我儿子现在上的幼儿园 – 贴笑脸和哭脸。每个月总有那么几天，在下班后由安全部门的人巡逻，一旦发现了诸如电脑没锁啊，打印的资料放在桌上了啊之类的，就会给你贴个哭脸。我儿子被贴了笑脸肯定会来给我秀一下顺便勒索个糖果什么的，而在那儿，被贴哭脸的后果就不是没糖吃那么简单了：如果你一年内被贴了两次哭脸，那你当年的加薪升职和奖金基本上就别想了。当然，用比较时髦的说法是fail your performance goal.

有一次下班回家，车都开到了东三环，突然想起，我的神叻，有一份打印的技术文档放在桌上了！虽然只是一篇从codeproject上扒拉下来的文章，不存在安全隐患一说，但贴哭脸的人可不这么想是吧？你也不能要求别人能看懂你这满页满页的英文字母里是不是藏了啥项目的机密是不？想着唾手可及的升职，还有随之而来的加薪，我立马很不淡定的一个漂移又开回了西三环。那时年轻不懂事儿，现在想想，先不谈别的，单算算这一折腾浪费了多少油，并因此多砍了几棵树直接导致了全球变暖加剧之类的后果，就觉得挺不是回事儿的。俗话说的，傻人有傻办法，从那之后我的同事们多少会觉得…

几天前Jean说起Dev Environment setup的问题，正好北美的JT在Yammer上发了一条消息介绍他们Team的“a project that will get your computer ready for development in 4 minutes”，实际上是在Github上share的Dotfile。我说我们几个做Rails开发的都有类似的东西，是的，类似－－因为我要share的不是dotfile（我们每个人都有不同的偏好，所以dotfile各不相同），而是快速安装rails开发环境所需的几个东西：homebrew, git, wget, rvm, zsh, oh-my-zsh, ruby, rails。

使用非常简单：

1

ruby -e "$(curl -fsSL https://raw.github.com/gist/1287091)"

使用前记得先装好XCode，这是唯一的要求。另外在这个脚本运行的过程中会问你一些问题，或者需要输入你sudo的密码。

如果在安装过程中都回答‘y’的话，那么在脚本跑完后，你的shell会默认使用zsh，ruby 1.9.2 p290版本应该安装完毕，同时新建了一个gemset叫做‘rails31’，rails 3.1 会安装在这个gemset里面。对于我们来说，这基本上就是所需的全部。另外如果想要见到安装后效果的shell，需要重新启动你的shell…

看到Pry这个IRB的替代品出来有一段时间了。上个月曾经试着简单的使用了一下，但是由于时间仓促，没有太多的体会到Pry的好处，就直接回到了IRB的环境。今天早上起来看到在ruby-toolbox 上Pry三个大大的字放在了首页的推荐栏上，点进去一看，被它的热度趋势吓了一跳：

可以看到在10月份（现在才过了不到一半），Pry已经开始火起来了。世上没有无缘故的爱，这么火应该是有原因的，那我就花点时间重新来看看Pry到底有些什么好处吧。因为我主要是进行Rails开发，所以下面的实验都是在Rails环境下进行的。

首先是用Pry替代IRB。这个很简单，稍微google一下就有很清楚的描述。关键代码是在config里面加上

1
2
3
4
5
6
7

silence_warnings do
  begin
    require 'pry'
    IRB = Pry
  rescue LoadError
  end
end

但是这样做有…