周五晚上，女儿睡着以后，在google reader上闲逛，随口和老婆说了句，“你看，有人去排队了”，老婆鼓励我说，“你也去吧”，我马上心动，开始在网上四处抓人。半个小时后，我坐上了朋友的车。晚上九点半，我们一行三个人来到了三里屯即将开业的苹果店门口。被咬了一口的苹果，象月亮一样挂在天空。

进入橙色大厅前，工作人员再三确认我们是否真的要排队，告知进门以后只有一个小时的放风时间，和我们在网上看到的差不多，也没啥好犹豫的，就把狗牌栓上了。我是106号。

进去就听到有人喊“石锅拌饭”，过去一看是吕胖胖和夏瘦瘦，分别是三十多号和九十多号，在他们介绍下认识了拜读已久的apple4.us的两位编辑，都是十号以内的强人。转身出去在肯德基买了汉堡和可乐，今晚就在这里扎营了。

有不少专业排队的，睡袋、防水垫、帐篷，装备相当齐全。相比之下，我们只有Ginn带的一把折椅，还好最后在音箱旁找了一个有插座的地方，大厅有无线宽带，电也不用愁了。

整个大厅有接近一百号人，聊天的、玩游戏的、看电影的、杀人的，还有几个活力四射的摆了一晚上pose照了一晚上的像。对于中国的mac fans，这就算是woodstock了。整晚我都很兴奋，四点钟睡了一个小时，五点，迎来了苹果店的第一个早晨。

八点多钟，开始按号码集结，随后穿过极长的走廊，来到店门口。

最后两个小时的等待是最消耗耐心的，十点钟，苹果店终于准时开门，在店员的呼喊声中，我们终于进来了。

十点半，我们三个人出了店门，各回各家。最终收获，一件T-shirt，一张包装纸，一个塑料狗牌。

凌晨的时候，一个负责装音箱的工作人员很好奇的问我，“明天开门有什么特别的活动么？”，我说可能没有，“有什么礼物么？”，我说不太清楚，“你们是被请来的么？”，我说不是，“你们在这待了一夜了？”，我说是。我想找点理由解释我们为什么在这里待了一夜，也找不出来。我们好像一群无聊的人，在做一件毫无意义的事情。但凡心智成熟的人，都应该不会有这样的举动。

我也只好说，偶尔做一做这样没有意义的事情，比如排一夜队等待苹果店开幕，比如看两遍变形金刚，比如花一下午练习杀死一只黑狼鸟，会让自己感觉年轻一些。

现在注册一个网站，那叫一个难，先要准备好一寸免冠照片一张，还要填写各种个人信息，籍贯、户口所在地、教育经历、工作背景、联系地址、QQ、MSN、GTalk、个人网站地址，不填全了都不好意思和人SNS。上照片的时候遇到了麻烦，试遍了Safari和FF都不行，最后被告知Windows Only，赶快打开VMWare，上IE。这是我为了上招商银行特别安装的，注册5GSNS也必备。越是曾经鄙视的，越是要效仿。

终于完成注册，跳转到个人主页，赫然已经被8人访问共计44次。虽然我知道5Gsns流量很大，用户很活跃，但是还是被吓了一跳。此后两个小时，再没有人访问过我。我恶毒的认为这是一个人为手段造成的结果，可以说网站在诱导用户互相产生联系，也可以说在诱骗。

上去主要是为了看“王小可事件”，看完感觉酷似前段时间发生在贵州某地的事情，有很冤的被和谐的人，有很牛的道歉，有解释不清楚的规则，有打酱油的，有俯卧撑的。SNS就是这么酷似我们的现实生活，给你一次站着说话不腰疼的机会。

我以后会经常上去看看的。因为我发现，傻呵呵的拜读网络精英们的blog，是不会读到他们真正的价值观的，唯一的办法就是去看他们做的是什么事。

今天和一个朋友聊起股市，他说他自己现在满仓，亏得不敢看。我自己在6000点的时候是2/3债券基金，1/3股票型基金，跌到3500点的时候，转换了一部分债券型到股票型，两个月前开始定投股票型基金，目前接近60%的股票型，40%的债券型。累计收益-18%，超过81%的财迷。

很多人都骂中国的股市不理性，可很少有人细究为什么会这样，更多的人乐于把责任推卸给政府、证监会、机构或者当年忽悠他们进场的人。要我说，的确有这样那样的原因，但是股市是股民组成，股市的不理性正是股民的不理性的反映，是我们的股民造就了我们的股市，不是别人。06/07年的股市暴涨让多少本来理性的人失去了理性，又让更多本来没什么理性可言的人冲进了市场，泡沫就是这样起来的。

也总有人在这个时候质疑为什么政府不救市。股市上涨的时候是没有人喜欢政府来干预市场经济的，去年调高印花税，不知道多少人骂呢。我并不是来开脱谁的责任，但如果已经有人通过一些手段来告诉你风险很高了，你没有听，还要他怎么救你呢？还有我也想不出该怎么救市，如果政府真有什么有效的干预手段让救股市到规规矩矩回到6000点，手段一出，招来的就是索罗斯们。如果这次学费白交了，下次只能还做受害者。

我选择这个时候开始定投，并不是说我认为现在是底了，我不是来抄底的，只是觉得现在比较低了，去年11月份之前，相信每个人都会想，如果2700点有一次进的机会该有多好，现在还有多少人把这看成机会呢？我选择定投而不是一下全赌进去，如果股市再跌，那么下个月我可以买到更便宜的基金，熊市时间越长，我能够收集的筹码越多，总有涨上去的那天。这就是定投的好处。

这些都是我和朋友谈的对现在市场的看法，我肯定不是什么专家，不过是经过这一年的一些所得。

这个东西还有个叫法,叫cheat sheet, 就是考试作弊放在下面抄的那个东西. 网上有各种各样的cheat sheet, errblog甚至有一个叫cheat的小程序,一个命令行,比如 cheat strftime ,就能列出strftime里面那些奇怪的字符都对应什么内容,非常好用. 还没那么简单,你可以自己添加和修改cheat sheet,而这些cheat sheet都通过web service保存在一个集中的wiki里,大家一起cheat.

这个小工具我相当喜欢,但是用了一段时间还是有些不满意的地方.首先是每次想添加和修改cheat sheets的时候都很犹豫,怕自己加了别人不需要的东西,给人添麻烦.另一方面,我自己有一些和项目相关cheat sheets,很想用同样的方式来组织,但是又不可能提交进去.

其实,做这件事做好的后端是git, 可以把git看做是一个分布式wiki的内核.用git做这件事有很多好处:

1. 天然具备版本管理的功能
2. 非常灵活的分享策略.你可以自己选择从那里得到cheat sheet,又分享到哪里去.
3. 访问速度更快,因为git的repository就在本地.
4. 更灵活的目录结构.cheat本身受实现的影响不支持目录结构.

于是,就有了 ‘chit’ , 一个基于git的cheat sheet工具. 我把它放在了github上.

安装

sudo gem install robin-chit -s http://gems.github.com

安装完运行一下

chit --init

会自动完称配置.

运行

如果要得到一个cheat sheet,比如mysql的cheat sheet,直接在命令行输入:

chit mysql

如果要修改:

chit mysql --edit

如果要添加:

chit ahaha --add

同时,你还拥有一个private的cheat sheets库.访问和添加的方法是在cheat sheet名字前面加一个’@’.私有的cheat sheets保存在一个单独的git repository里,不会和public的部分有关联.
比如要添加一个私有的cheat sheet

chit @robin --add

访问它:

chit @robin

还有一个有用的命令,就是列出所有的cheat sheets的名称:

chit all

列出所有私有的cheat sheets当然就是

chit @all

分享

拜git所赐, 分享cheat sheets会非常容易.

chit其实创建了两个git repositories, 分别在~/.chit/main 和 ~/.chit/private下,对应缺省的cheat sheets和私有的cheat sheets, 你可以随时将这个两个cheat sheet库push到任何一个地方,和你的朋友或者同事分享.别人可以选择添加一个remote branch,随时merge,也可以干脆修改~/.chitrc,在chit第一次init时从指定的地址得到cheat sheet库,以后随时通过pull来同步. 完全由你自己掌握.

目前版本0.0.3, 欢迎大家使用,欢迎各种意见建议.

项目主页
项目wiki
缺省cheat sheets库

Capify

首先,在项目目录中运行:

capify .

生成相关的deploy文件.我们需要关心的是由这个命令生成的config/deploy.rb文件.这个文件由Capfile加载.

配置deploy.rb

和应用相关的配置:

1
2
3
4
5

set :application, "myapp"
role :web, "www.mydomain.com"
role :app, "www.mydomain.com"
role :db,  "www.mydomain.com"
set :deploy_to, "/var/app/#{application}"

这部分和capistrano 1.x基本相同.在部署的时候,会先尝试public key方式连接合服务器,失败后会尝试password方式.建议大家都使用public key的方式.

使用者相关的配置:

1
2

set :user, "robin"
set :runner, "www"

大部分部署指令会以:user设定的身份去运行,但和启动应用服务器相关的指令会以:runner设置的身份去运行,缺省的runner是’app’,如果你是’www’或者其他什么用户,最好设置一下.

capistrano2.3支持git,git相关的配置:

1
2

set :repository,  "ssh://mydomain.com/git/myapp.git"
set :scm, "git"

第一行设置repository的url.第二行指定scm是git.
另外还可以设置访问git所需的密码

1


set :scm_passphrase, "p00p"

如果项目比较大,可以做shallow clone,节省部署时间:

1


set :git_shallow_clone, 1

也可以使用Remote Cache,避免每次都clone

1


set :deploy_via, :remote_cache

对于mongrel,确认你安装了最新版本的mongrel_cluster,我这里的版本是1.0.5.新版本中有针对capistrano 2.x的修正.
和mongrel相关的配置:

1
2
3


require 'mongrel_cluster/recipes'
set :mongrel_conf, "#{deploy_to}/current/config/mongrel_cluster.yml"
set :mongrel_user, "apprunner"

第一行加载了mongrel_cluster的recipes,重载了start/stop等命令,保证每次重启的是mongrel.第二行指定了mongrel_cluster配置文件的位置.第三行指定了以什么身份来运行mongrel.

最后需要写一个spin脚本,放在./script目录下,capistrano会用它来启动mongrel

1


/usr/local/bin/mongrel_rails cluster::start -C /path/current/config/mongrel_cluster.yml

记住要把path换成你deploy_to的目录,还要给这个文件执行权限.

1

chmod 755 ./script/spin

配置到这里基本就完成了.

部署

第一次部署需要运行下面的命令:

1


cap deploy:setup

这个命令会在服务器上配置好相关的目录结构.然后再运行:

1


cap deploy:check

检查目录结构是否配置正确.
第一次部署用的命令是:

1


cap deploy:cold

以后部署都可以直接用:

1


cap deploy

如果发生问题要rollback可以用:

1


cap deploy:rollback

参考资料

Capistrano: Rails
Deploying with Capistrano - Git Guides
Deploying Rails (2.0) to Mongrel with Capistrano 2.1

很多用户是闭着眼睛看网站的说了一件很现实的事情,用户是不看提示的,他们只凭自己的感觉操作.

对于产品交互的设计,我也一直这么认为,如果需要在界面上通过写提示信息来指导用户操作,那么设计上很可能是有可以改进的余地.就象好的程序是自然可读的,如果不得不加注释,多半是有问题了一样.

好的交互设计,就是要随着用户去造,总能完成任务.要做到这点,需要好好体会下面的交互设计三定理:

第一:产品不能做危及用户的事情,如果用户操作错误,也有义务修正.
第二:服从用户的所有操作,但不得违反第一条.
第三:不能危害产品自身,但不得违反第一、第二定理

看着眼熟么?其实剽窃了阿西莫夫的机器人三定理,他老人家半个世纪前就总结好了:

第一:机器人不得伤害人,也不得见人受到伤害而袖手旁观。
第二:机器人应服从人的一切命令,但不得违反第一定理。
第三:机器人应保护自身的安全,但不得违反第一、第二定理

每一个产品都是一个机器人.

说起来挺容易,做起来真的很难.

$ curl fuck.you
<html>
<head>
<link rel="stylesheet" type="text/css" href="http://202.106.195.23:6688/aicss_test242.css" />
</head>

<script>
s=String(window.location.href);
mylocal=s.substring(7,s.indexOf('/',7));
t = "http://dm.bbn.com.cn/response.asp?MT=" + mylocal;
document.location.href = t;
</script>

<body></body>
</html>

No host is impossible!

开始

安装最新版本的git，从git 1.5.3以后支持git-svn，git和svn的配合就要借助这个功能。

安装完毕后要做一些简单的配置。最直接的做法就是创建修改~/.gitconfig。下面是我的.gitconfig

[user]
        name = Robin Lu
        email = ---@gmail.com
[color]
        diff = auto
        status = auto
        branch = auto
[alias]
  st = status
  rb = svn rebase
  ci = commit -a
  co = checkout

[user]部分标示出使用者的身份，你提交的代码会自动引用这一身份信息。[color]设置命令输出的颜色。[alias]部分可以简化一些常用命令，比如在这里将git status简化为git st。

初始化代码库

首先用git-svn来初始化本地的代码库(repository)

git svn clone -s svn-repository-url

svn-repository-url部分使用svn代码库的url。如果要从trunk目录或者某个branch目录里check out，要把-s换成-T、-b等选项。具体参看man git-svn。这个命令时间比较长，因为需要同步所有的提交历史，还好只此一次，以后不会这么慢了。做完这一步，在本地就有了一个完整的代码库，包括所有commit的历史和log，已经可以开始用它来进行开发工作了。

不过，在开始开发之前，最好先做一次垃圾搜集：

git gc

它对代码库的信息进行垃圾搜集和压缩，最明显的作用就是减小磁盘占用空间。第一次做效果尤其明显。

你可以检查一下代码库的状态：

git status

现在应该在一个叫”master”的分支(branch)上。

用这个命令来显示出所有的分支(branch):

git branch -a

master前有一个*号，代表你现在所处的分支，另外还有一个分支叫trunk，它是一个远程分支(remote branch)，对应的是远程svn代码库。master实际上是trunk的一个本地分支。

接下来，需要配置忽略文件，让git忽略一些目录中不希望加入代码库的文件，类似svn propset svn:ignore。全局有效的忽略文件列表可以添加在./.git/info/exclude文件中。比如我需要忽略所有vi产生的swp文件：

.*.swp

对于和目录有关的忽略文件设置可以在该目录下创建.gitignore，然后加入需要忽略的内容，比如我希望忽略根目录下的log,tmp等目录，可以直接在根目录下的.gitignore中加入:

log
tmp

开发流程

可以开始工作了。用git后开始养成一个新习惯，就是工作前先创建新分支:

git checkout -b new_branch

-b后是分支名，创建的同时，你要转到了新分支上。尽量保持master上没有未提交到svn的commit，这样随时都可以很容易的产生一个干净的分支。

接下来你可以写代码，修改文件或者添加文件。如果想看看修改了什么，可以用：

git diff

如果对某个修改不满意，希望恢复原状，可以使用:

git checkout path/filename

相当于svn revert

git引入一个索引(index)的概念，提交前，需要把要提交的文件加入到git索引(index)中：

git add path/filename1
git add path/filename2
...

然后提交

git commit -m "提交感言"

每次commit都是提交索引(index)中的内容。

如果要一次提交所有修改过的文件，可以一次性添加，然后提交

git add .
git commit -m "提交感言"

如果只是修改，并没有添加新文件，可以直接用下面的命令:

git commit -a -m "提交感言"

将被修改文件加入索引并提交，一次完成全过程。

在修改加入所索引后，如果想看看索引内容中都所了什么修改，可以用：

git diff --cached

适合在提交前做最后的code review。

查看最近一次提交的内容，可以使用

git show

修改中随时查看当前代码库的状态：

git status

相当于svn status

删除和移动某个文件：

git rm file
git mv file newfile

提交到svn

在完成了几轮工作后，要将本地内容提交到远程svn中，可以先让当前分支和远程svn同步：

git svn rebase

然后将所有已经合并到master分支的本地修改提交到svn

git svn dcommit

如果在git svn rebase时发生代码冲突，需要先手动解决冲突，然后用git add将修改加入索引，然后继续rebase

git svn rebase --continue

缺点

最后说说这种工作方式的缺点。这个话题稍微复杂一点。

svn和git的工作原理毕竟不同，git对代码提交的非线性特性在svn中难以再现，如果使用了git-merge或者git-pull，再提交到svn，相关分支上的提交历史有可能无法体现在svn上。从svn的使用者的角度，无法辨别这是一个提交还是一次合并，所以在和svn协作过程中，尽量不要使用merge，或者说，尽量让代码库保持线性。

我的经验是，如果不在乎svn中是否反映出提交历史，使用merge也无妨。比如完成工作后，可以将工作分支合并到主分支中去：

git checkout master
git merge new_branch

先用checkout命令切换回master分支，然后将新分支中内容合并进来。然后在master分支上做git svn rebase和dcommit。从svn来看，这就是一个commit，new_branch上的提交历史在svn上体现不出来。(有例外情况，以后再讨论)。

还有一个解决办法是尽量保持git代码库的线性特征。比如在new_branch分支中，先和master做rebase，再合并到master分支中：

git rebase master
git checkout master
git merge new_branch

然后在master上做dcommit，就可以在svn代码库中看到完整的提交历史。

如果看到这已经有点头晕了，可以干脆不管它，就按照前面的做法，直接在你的工作分支里dcommit，等对非线性开发有一定了解再来看各种情况。

好了，基本上知道这些就可以干活了。