在安装有些vim插件的时候，需要Vim支持Python，比如YouCompleteMe，但是，最近升级到Jessie后，发现，默认的vim，是不支持Python的，于是在网上搜索了一下，如果需要vim的二进制版本带有Python支持的话，应该安装一个叫 vim-nox 的包，其介绍为：
Vi IMproved - enhanced vi editor - with scripting languages support
就这样。
以前，我使用 Windows 作为自己的工作系统，后来，改用 Mac 作为自己的主要工作系统了。
在 Windows 下，快速搭建*AMP 环境，使用 xampp 或者 WAMP 之类的集成包，会一口气装好所有需要的软件，而在 Mac 下，相应的，做得比较好的是 MAMP，我选用的是与之对应的收费版本 MAMP Pro，总体差别不大。
Git——以及所有一切的版本库——的核心目标，就是保证代码不会丢失。我所熟知的两个版本控制工具——SVN和Git——都是通过提交代码（commit）来实现这个目标的。
虽然我反对使用SVN来类比Git，但是，如果仅是为了强调它们的“不同”，而进行比较，我觉得还是有助于理解的。
SVN使用过程中，版本仓库是在云端的，程序员的个人电脑上，只是一个工作副本，或者叫代码暂存，如果写好的代码，没有被送到云端的版本库，就意味着有潜在丢失的风险。所以，SVN的提交（commit），其本质，就是将代码从本地电脑传送到云端服务器，这个过程，我们称之为“入库”。
说实在的，Git我已经学习了很久很久，从最开始的，零星的学习，然后偶尔使用，到现在成为公司的唯一版本控制方式，断断续续没有两年，也有三年。Git官网上写着，简单易用（easy to learn），我就是被这四个字骗了，开始用上了Git。现如今，它已经成为一种避无可避的工具了，必须学会。
要开始上手使用Git，可能真的是很简单的事情，如果你翻开一些成体系的文档或者书籍，可能上来会教你使用git init命令。这个命令的目的是创建一个新的git版本库。但是，就我个人的经验来看，一个新人，接触版本控制系统，可能第一件事情，往往是融入一个开发团队，接手一块业务，然后开始贡献代码，不太会是上来先建立一个版本库。
Git是目前世界上最为炙手可热的版本控制系统。它是如此的流行和重要，以至于全世界程序员的工作和生活，都可能因之而改变。
Git是一个版本控制系统，帮助程序员管理自己的源代码的版本变化，保证它们不会丢失。它只是开发工作中的一个工具。但是，一个“工具”，为什么可以重要到足以改变这个“工作”本身？我们可以以政治经济学范畴的概念，来理解一下这个问题，Git就相当于是生产工具，生产工具的发展，可以进一步解放生产力，从而推动了社会的进步。Git不是历史上第一个版本控制工具，显然也不会是最后一个，为什么到了Git出现的时候，就产生了近乎变革般的变化？
学习使用PHP怎么也有7年的时间了，竟然也没有注意到有个函数是array_replace_recursive，之前只知道array_merge_recursive，而且，这两个函数的返回结果，都非常地出人意料，不怎么符合直觉，而使用了Yii框架若干年，竟然也不知道有个CMap::mergeArray()方法，这个方法，如果跟前面两个函数混同起来看，竟然也显得有点离奇。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[
'apple',
'orange'
],
'nested' => [
'A' => 'xx',
'B' => 'yy'
],
'single' => 1,
];
$b = [
'fruite' => [
'penapple',
],
'nested' => [
'A' => 'zz',
],
'single' => [
'string'
],
];
echo "array_merge_recursive: ", PHP_EOL;
var_export(array_merge_recursive($a, $b));
echo PHP_EOL, "array_replace_recursive: ", PHP_EOL;
var_export(array_replace_recursive($a, $b));
echo PHP_EOL, "CMap::mergeArray: ", PHP_EOL;
var_export(CMap::mergeArray($a, $b));
然后，我们来看一下这个用例输出的结果，相当神奇哦~1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
array_merge_recursive:
array (
'fruite' =>
array (
0 => 'apple',
1 => 'orange',
2 => 'penapple',
),
'nested' =>
array (
'A' =>
array (
0 => 'xx',
1 => 'zz',
),
'B' => 'yy',
),
'single' => //注意这个东西的处理，简直莫名其妙！
array (
0 => 1,
1 => 'string',
),
)
array_replace_recursive:
array (
'fruite' =>
array (
0 => 'penapple',
1 => 'orange',
),
'nested' =>
array (
'A' => 'zz',
'B' => 'yy',
),
'single' =>
array (
0 => 'string',
),
)
CMap::mergeArray:
array (
'fruite' => //这里选择了array_merge_recursive的行为
array (
0 => 'apple',
1 => 'orange',
2 => 'penapple',
),
'nested' =>
array (
'A' => 'zz',
'B' => 'yy',
),
'single' => //这里却选择了array_replace_recursive的行为
array (
0 => 'string',
),
)
实在是没有心力去把所有的用例想完整，只能随便写几个，从中可以看出来，这些函数的处理规则，不是简单可以说清楚的。
当然，问题绝不止这么几个，只是我懒得想全所有用例而已。
之前已经写了蛮多的跟这个事件驱动特性有关的内容了。比如我今天发现，Yii 框架支持的事件驱动，只能支持对对象实例进行事件绑定。简单来说，当你要绑定某个事件的时候，这个事件的触发者的对象，必须已经建立好了。
Yii框架的特性列表里，有一项叫“Event Driven”，所谓的事件驱动，但是在实际业务开发实践中，我发现即便有应用场景，大家也倾向于不用，究其原因，还是不熟悉。
当然，我认为，作为Yii框架的官方开发团队，没有在这方面给出充足的，合适的例子，来说明这个特性的使用场景，也有着不可推卸的责任。
生搬硬套，为了使用event而去使用event，这种是我们坚决要杜绝的行为，那么到底在哪里使用这个特性才显得恰如其分呢？当然，笔者也没有一个非常好的标准去判断，只是偶有所得，在此跟大家分享一下。
故事是这样的，在我的业务模型里，有些东西是常态并且固定化的，比如User，这是一个网站的用户，有一张用户表与其对应。但是有些东西，却不是那么常态，比如我们的网站要经常搞活动，搞活动的时候，临时开发一个功能，加一个表来存储活动数据，日后，活动下线了，这个表也就没有用了，可能会被删除。活动频次非常高，所以不同的开发都会快速地进行开发，于是出现了命名不一致的情况，比如大家都是要关联User（活动跟用户有关，非常自然），在表A中，代表用户的字段叫user_id，表示User的主键，但是在表B里面，因为习惯使然，代表用户的字段叫uid，然后问题就产生了，当表A和表B需要联表查询时候，怎么设置这个relations呢？
