3.24更新

经过几天的使用，发现:;键按起来不太方便，但是这两个符号使用的还挺多的: :在vim里面用的很多，而;在微软双拼里面代表ing。我对布局进行了一些微调: 在第7层将右空格设置为:;，同时在Karabiner Elements里面针对YDM40做了如下设定：

1. 如果是英文输入法，交换冒号:和分号;，这样我就可以同时按住两个空格键输入vim的命令了。
2. 如果是双拼输入法，交换回车和分号，这样就可以按回车当成ing，同时按住两个空格回车了。

Karabiner里面支持针对设备和输入法设置，还是比较方便的，我的karabiner的设置如下， 点击链 接 即可添加到karabiner elements的complex modifications中：

ydmp40.json

{
  "title": "YDPM40 key settings",
  "rules": [
    {
      "description": "Exchange semicolon and colon",
      "manipulators": [
        {
          "conditions": [
            {
              "input_sources": [
                {
                  "input_source_id": "com\\.apple\\.keylayout\\.ABC"
                }
              ],
              "type": "input_source_if"
            },
            {
              "type": "device_if",
              "identifiers": [
                {
                  "vendor_id": 65261,
                  "product_id": 576,
                  "description": "YDM40"
                }
              ]
            }
          ],
          "from": {
            "key_code": "semicolon",
            "modifiers": {
              "optional": [
                "caps_lock"
              ]
            }
          },
          "to": [
            {
              "key_code": "semicolon",
              "modifiers": [
                "left_shift"
              ]
            }
          ],
          "type": "basic"
        },
        {
          "conditions": [
            {
              "input_sources": [
                {
                  "input_source_id": "com\\.apple\\.keylayout\\.ABC"
                }
              ],
              "type": "input_source_if"
            }, 
            {
              "type": "device_if",
              "identifiers": [
                {
                  "vendor_id": 65261,
                  "product_id": 576,
                  "description": "YDM40"
                }
              ]
            }
          ],
          "from": {
            "key_code": "semicolon",
            "modifiers": {
              "mandatory": [
                "shift"
              ],
              "optional": [
                "caps_lock"
              ]
            }
          },
          "to": [
            {
              "key_code": "semicolon"
            }
          ],
          "type": "basic"
        }
      ]
    },
    {
      "description": "Exchange return and semicolon",
      "manipulators": [
        {
          "conditions": [
            {
              "input_sources": [
                {
                  "input_source_id": "com\\.apple\\.inputmethod\\.SCIM\\.Shuangpin"
                }
              ],
              "type": "input_source_if"
            }, 
            {
              "type": "device_if",
              "identifiers": [
                {
                  "vendor_id": 65261,
                  "product_id": 576,
                  "description": "YDM40"
                }
              ]
            }
          ],
          "from": {
            "key_code": "semicolon",
            "modifiers": {
              "optional": [
                "caps_lock"
              ]
            }
          },
          "to": [
            {
              "key_code": "return_or_enter"
            }
          ],
          "type": "basic"
        },
        {
          "conditions": [
            {
              "input_sources": [
                {
                  "input_source_id": "com\\.apple\\.inputmethod\\.SCIM\\.Shuangpin"
                }
              ],
              "type": "input_source_if"
            },
            {
              "type": "device_if",
              "identifiers": [
                {
                  "vendor_id": 65261,
                  "product_id": 576,
                  "description": "YDM40"
                }
              ]
            }
          ],
          "from": {
            "key_code": "return_or_enter",
            "modifiers": {
              "optional": [
                "caps_lock"
              ]
            }
          },
          "to": [
            {
              "key_code": "semicolon"
            }
          ],
          "type": "basic"
        }
      ]
    }
  ]
}

OpenWrt的安装、配置

首先，下载WNDR4300的固件，OpenWrt的下载页面列出了不同版本的的固件，一般来说下载最新的release即可。 比如当前支持WNDR4300的最新固件是Chaos Calmer 15.05。在下载的时候需要注意，如果是第一次刷机，要下载factory固件；如果以前刷过OpenWrt，下载sysupgrade。

然后，进入路由器的web界面，找到「固件升级」，选择下载的包确定。重启后，路由器的系统就变成OpenWrt了。需要注意的是，重启后默认Wifi没有开启，按一下路由器上的Wifi开关即可。在电脑上，连上OpenWrt这个热点，浏览器打开192.168.1.1登录，用户名为root，没有密码。进入系统后，先进入「System → Administration」修改密码、添加SSH公钥等。

在web页面选择「Network → Interfaces」，对WAN口进行配置。然后进入「Network → Wifi」，设置SSID和Wifi密码。

Shadowsocks

首先，在路由器上安装shadowsocks的客户端：

$ opkg install http://openwrt-dist.sourceforge.net/releases/ar71xx/packages/shadowsocks-libev_2.4.1-1_ar71xx.ipk

安装时到shadowsock的下载页面确定软件的具体版本。如果你空间有限，也可以装polarssl版本。

编辑/etc/shadowsock.json，填上你shadowsock服务器的信息。

然后设置shadowsock自动启动：

$ /etc/init.d/shadowsocks enable
$ /etc/init.d/shadowsocks start

你可以将自己系统的SOCKS Proxy设置为192.168.1.1:1080，测试下shadowsocks是否工作正常。如果工作正常，将/etc/init.d/shadowsocks文件中的ss-local换成ss-redir并重启shadowsocks，表示我们要用shadowsocks进行转发。

$ opkg remove dnsmasq && opkg install dnsmasq-full
$ opkg install ipset

$ ipset create gfw hash:ip
$ iptables -t nat -A PREROUTING -p tcp -m set --match-set gfw dst -j REDIRECT --to-port 1079

$ python gfwlist2dnsmasq.py

conf-dir=/etc/dnsmasq.d

$ /etc/init.d/dnsmasq restart

安装配置

SmartOS可以装在一个U盘里面。这样的好处很多，比如增加了系统的安全性和稳定性，可用磁盘空间也大了，系统升级也很简单——更新一下U盘就行了。我用了一个16G的U盘，按照官方的教程下载镜像、创建可启动U盘，然后从U盘启动就可以了。

SmartOS使用了zones技术，U盘启动后进入一个全局的zone(Global Zone)，负责管理其它的zone。一个zone就是一个虚拟化的实例，SmartOS创建的每个虚拟机都是跑在一个单独的zone里面。

SmartOS使用了ZFS文件系统，所有虚拟机的zone都是存放在一个叫zones的zpool中。第一次启动时，除了让你配置网络，还会要求你创建zones。我有4块3T的硬盘，1块256G的SSD，在启动时选择4块硬盘组成一个raidz来作为zones池。在我的机器上，4块硬盘分别是c1t0d0, c1t1d0, c1t2d0和c1t3d0。

为了取得更好的性能，用format将SSD（c1t4d0）分为32G和224G两个分区，分别作为ZIL(log)和L2ARC(cache):

# zpool add zones log c1t4d0s0
# zpool add zones cache c1t4d0s1

配置完之后磁盘的信息如下：

# zpool status
  pool: zones
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            c1t0d0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0
            c1t2d0  ONLINE       0     0     0
            c1t3d0  ONLINE       0     0     0
        logs
          c1t4d0s0  ONLINE       0     0     0
        cache
          c1t4d0s1  ONLINE       0     0     0

errors: No known data errors

如果上述步骤搞错了，可以参照官方的步骤重装。很不幸的是，我安装官方的步骤选择Grub第2项（noinstall）几乎每次都会死机，如果你遇到和我一样的情况，也可以在启动时出现Grub界面的时候，在第1项按e，然后在最后加上destroy_zpools=true的选项，这样启动后就会删除所有的zpool，然后就可以重新配置了。（注意：磁盘上已经有数据的慎用！）

创建虚拟机

U盘启动的SmartOS是一个只读系统，你所能做的事情非常有限。不过SmartOS就是为虚拟化而生的，它支持zones和kvm两种虚拟化技术，前者类似容器技术，具有很好的性能，但支持的OS较少；后者性能不如前者，但能支持大部分常见的OS。

imgadm和vmadm是管理虚拟机的两个常用命令，前者主要用来管理镜像，而后者用来管理虚拟机。你可以通过imgadm avail来查看已有的虚拟机镜像，用vmadm create来根据镜像创建虚拟机。

此外，我希望数据能够单独存储，即使虚拟机坏掉或者删除数据仍然存在，因此专门建立一个数据存储的dataset：

# zfs create zones/datastore

# imgadm avail | grep debian-8
ca291f66-048c-11e5-98b3-c3f2a972a4cc  debian-8                20150527    linux    2015-05-27T16:24:03Z
2f56d126-20d0-11e5-9e5b-5f3ef6688aba  debian-8                20150702    linux    2015-07-02T15:37:02Z

# imgadm import 2f56d126-20d0-11e5-9e5b-5f3ef6688aba

{
  "brand": "kvm",
  "alias": "debian",
  "hostname": "debian",
  "resolvers": [
    "192.168.1.1",
    "114.114.114.114",
    "8.8.8.8",
    "8.8.4.4"
  ],
  "ram": "2048",
  "vcpus": "1",
  "nics": [
    {
      "nic_tag": "admin",
      "ip": "192.168.1.102",
      "netmask": "255.255.255.0",
      "gateway": "192.168.1.1",
      "model": "virtio",
      "primary": true
    }
  ],
  "disks": [
    {
      "image_uuid": "2f56d126-20d0-11e5-9e5b-5f3ef6688aba",
      "boot": true,
      "model": "virtio"
    }
  ]
}

# vmadm create -f debian8.json 
Successfully created VM b94d3a92-4a3b-4fae-baca-e53c726be924

# vmadm info b94d3a92-4a3b-4fae-baca-e53c726be924 vnc
{
  "vnc": {
    "host": "192.168.1.100",
    "port": 57869,
    "display": 51969
  }
}

# zfs set sharenfs='rw=@192.168.1.0/24,root=192.168.1.102' zones/datastore

# apt-get update && apt-get install nfs-common
# mkdir -p /mnt/datastore && mount -o rw,async,hard,intr 192.168.1.100:/zones/datastore /mnt/datastore

{
  "brand": "joyent",
  "image_uuid": "62f148f8-6e84-11e4-82c5-efca60348b9f",
  "alias": "smartos",
  "hostname": "smartos",
  "max_physical_memory": 2048,
  "quota": 20,
  "resolvers": ["192.168.1.1", "114.114.114.114", "8.8.8.8", "8.8.4.4"],
  "nics": [
    {
      "nic_tag": "admin",
      "ip": "192.168.1.101",
      "netmask": "255.255.255.0",
      "gateway": "192.168.1.1"
    }
  ]
}

# vmadm create -f smartos.json 
Successfully created VM 0b3c7b3b-9f19-4d26-ab22-a8b10a9add25
# zlogin 0b3c7b3b-9f19-4d26-ab22-a8b10a9add25 
[Connected to zone '0b3c7b3b-9f19-4d26-ab22-a8b10a9add25' pts/2]
   __        .                   .
 _|  |_      | .-. .  . .-. :--. |-
|_    _|     ;|   ||  |(.-' |  | |
  |__|   `--'  `-' `;-| `-' '  ' `-'
                   /  ; Instance (base64 14.3.0)
                   `-'  http://wiki.joyent.com/jpc2/Base+Instance

{
  "brand": "lx",
  "alias": "ubuntu1404",
  "kernel_version": "3.13.0",
  "max_physical_memory": 2048,
  "image_uuid": "a21a64a0-0809-11e5-a64f-ff80e8e8086f",
  "resolvers": ["192.168.1.1","114.114.114.114","8.8.8.8","8.8.4.4"],
  "nics": [
    {
      "nic_tag": "admin",
      "ip": "192.168.1.103",
      "netmask": "255.255.255.0",
      "gateway": "192.168.1.1",
      "primary": true
    }
  ],
  "filesystems": [
    {
      "type": "lofs",
      "source": "zones/datastore",
      "target": "/mnt/datastore"
    }
  ]
}

安装

如果你想充分体验Nix的强大功能，可以安装NixOS，它是一个构建于Nix之上的Linux发型版。

如果你不想装一个新的系统，或者像我一样主要用Mac OSX工作，也可以只安装Nix。最简单的方式就是在Terminal里面执行如下命令：

$ bash <(curl https://nixos.org/nix/install)

然后把下面这段脚本加入到你的shell启动文件中(~/.zshrc、~/.bashrc等)：

if [ -e $HOME/.nix-profile/etc/profile.d/nix.sh ]; then
  source $HOME/.nix-profile/etc/profile.d/nix.sh;
fi

然后就可以查看有什么可用的包：

$ nix-env -qa

安装一个包：

$ nix-env -i hello

卸载一个包：

$ nix-env -e hello

升级所有的包：

$ nix-channel --update nixpkgs
$ nix-env -u '*'

回滚上一步操作：

$ nix-env --rollback

垃圾回收不用的包：

$ nix-collect-garbage -d

包管理

安装Nix时主要创建了两个目录：/nix和$HOME/.nix-profile。我们来看看安装的包到底是如何组织的，比如当前有一个包hello：

$ which hello
/Users/hjw/.nix-profile/bin/hello

可以看到，hello来自于$HOME/.nix-profile，而后者是一个符号链接，其指向如下：

进一步查看最后一个目录（省略部分输出）：

$ ls -l /nix/store/hsw97dr9h9z3wmlwhx2lib8r3k2f9wv3-user-environment
bin
etc -> /nix/store/2vk1g8qkly4aqwx6ks49mzkd5kxhrd5f-nix-1.8pre3766_809ca33/etc
include -> /nix/store/2vk1g8qkly4aqwx6ks49mzkd5kxhrd5f-nix-1.8pre3766_809ca33/include
……

$ ls -l /nix/store/hsw97dr9h9z3wmlwhx2lib8r3k2f9wv3-user-environment/bin
ccmake -> /nix/store/r5rr3h6fg9sb0vararwh3plm2v9p8hcm-cmake-2.8.12.2/bin/ccmake
cmake -> /nix/store/r5rr3h6fg9sb0vararwh3plm2v9p8hcm-cmake-2.8.12.2/bin/cmake
……

可以发现，实际的文件都是存在/nix/store中的。这也是Nix管理包的方式：所有的包都存放在/nix/store中，而用户访问的都是指向/nix/store中文件的符号链接。

Profile是Nix管理包的方式，在/nix/var/nix/profiles中保存了当前的profile：

$ ls -l /nix/var/nix/profiles
default -> default-6-link
default-5-link -> /nix/store/g7l19z0c0ka41irwkn4mz67a0z85xydg-user-environment
default-6-link -> /nix/store/hsw97dr9h9z3wmlwhx2lib8r3k2f9wv3-user-environment
per-user

其中default就是当前的profile。如果我们删除一个包呢？

$ nix-env -e hello
uninstalling ‘hello-2.9’
building path(s) ‘/nix/store/816saagv6v8s19b2sksbgzjj0ljf5qfk-user-environment’
created 62 symlinks in user environment

$ ls -l /nix/var/nix/profiles
default -> default-7-link
default-5-link -> /nix/store/g7l19z0c0ka41irwkn4mz67a0z85xydg-user-environment
default-6-link -> /nix/store/hsw97dr9h9z3wmlwhx2lib8r3k2f9wv3-user-environment
default-7-link -> /nix/store/816saagv6v8s19b2sksbgzjj0ljf5qfk-user-environment
per-user

注意到删除一个包会生成一个新的profile —— default-7-link，而default也会指向新生成的profile。这也是Nix的工作方式，你删除包的时候，包其实并没有被删除，而是生成了一个不包含原来包的新profile！而你随时可以回到原来的状态。如果我们后悔删除hello了，那么可以回滚上述操作：

$ which hello
hello not found
$ nix-env --rollback
switching from generation 7 to 6
$ which hello
/Users/hjw/.nix-profile/bin/hello
$ ls -l /nix/var/nix/profiles
default -> default-6-link
default-5-link -> /nix/store/g7l19z0c0ka41irwkn4mz67a0z85xydg-user-environment
default-6-link -> /nix/store/hsw97dr9h9z3wmlwhx2lib8r3k2f9wv3-user-environment
default-7-link -> /nix/store/816saagv6v8s19b2sksbgzjj0ljf5qfk-user-environment
per-user

可以看到，回滚之后default又指向了default-6-link，hello又可以用了。Profile使用起来非常灵活，我们可以很方便地在各个profile之间切换：

$ nix-env --list-generations
   5   2014-09-13 20:58:33
   6   2014-09-19 10:00:58   (current)
   7   2014-09-21 21:16:57
$ nix-env --switch-generation 7
switching from generation 6 to 7
$ nix-env --switch-profile /nix/var/nix/profiles/my-profile
$ ls -l ~/.nix-profile
/Users/hjw/.nix-profile -> /nix/var/nix/profiles/my-profile

如果我们从来不真正删除包，毫无疑问硬盘慢慢就会被占满，Nix支持垃圾回收。我们需要首先删除不用的profile：

$ nix-env --delete-generations 5
removing generation 5
$ nix-env --delete-generations old
removing generation 6
$ nix-env --list-generations
   7   2014-09-21 21:16:57   (current)

然后，可以运行垃圾回收的命令。这里的垃圾回收跟编程语言的垃圾回收机制很像，一个包如果没有profile用到它就会被删除：

$ nix-store --gc

如果你不确定哪些东西会被删除，可以先把要删除的东西打印一下看看：

$ nix-store --gc --print-dead

还有另外一个命令，它会删除/nix/var/nix/profiles下所有profile的老版本，可以用来清理你的系统：

$ nix-collect-garbage -d

Nix的profile其实是可以放在任意位置的，但是垃圾回收的时候之后回收/nix/var/nix/gcroots下所指向的那些profile目录：

$ ls -l /nix/var/nix/gcroots
auto
profiles -> /nix/var/nix/profiles

Channel

Nix的Channel存储了包的集合，可以通过命令添加Channel：

$ nix-channel --add http://nixos.org/channels/nixpkgs-unstable

更新Channel:

$ nix-channel --update

升级已有的包：

$ nix-env -u '*'

此外，Nix还提供了很方便的工具让你把包及其依赖导出、导入以及通过SSH拷贝到另一台机器上：

$ nix-store --export $(nix-store -qR $(type -p firefox)) > firefox.closure
$ nix-store --import < firefox.closure
$ nix-copy-closure --to alice@itchy.example.org $(type -p firefox)

Nix表达式

Nix的包是由Nix表达式描述的，它所使用的Nix expression language是一种支持惰性求值的纯函数式语言。下面是一个简单的hello包的描述：

{ stdenv, fetchurl, perl }:

stdenv.mkDerivation {
  name = "hello-2.1.v1";
  builder = ./builder.sh;
  src = fetchurl {
    url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
    md5 = "70c9ccvf9fac07f762c24f2df2290784d";
  };
  inherit perl;
}

这个描述其实就是一个函数，{stdenv, fetchurl, perl}是函数的参数，表示构建这个包需要什么东西，stdenv提供了一个标准的构建环境，fetchurl通过url抓取一个文件，而perl是Perl的解释器。mkDerivation是stdenv提供的一个函数，它通过一个属性集合来构建一个包。mkDerivation的参数也就是后面花括弧括起来的那部分是一个集合，描述了这个包的属性，如名字、源代码、以及所需的解释器，其中的builder表示构建这个包的脚本：

source $stdenv/setup

PATH=$perl/bin:$PATH

tar xvfz $src
cd hello-*
./configure --prefix=$out
make 5
make install

更具体的Nix expression这里就不赘述，有兴趣的可以查看相关文档。

总结

Nix是一个非常强大的包管理工具，它可以非常方便地解决包的依赖以及多版本共存的问题，对于那些没有包管理系统的语言（如C/C++）是一个比较好的选择；对于包管理很弱的语言（如Python）也能够提供一个更好的解决方法；对于涉及到多中语言的项目，能够以一种统一的方式来管理各种包，对开发者而言是一个非常好的工具。

此外，Nix所提供的包管理机制应该可以和Docker结合起来。比如本地开发的时候使用Nix，发布时将相关的包打包形成一个Docker镜像，实现可重现的构建。

如果说Nix的缺点，那就是相比apt、yum、pacman、homebrew之类比较成熟的包管理器，它包的数量还比较少，特别是在Mac上，有很多包还是处于broken的状态。不过Nix的开发比较活跃，即使你现在还没有用它，也值得去关注一下。

最后说一句，Nix其实也不是真的纯函数式 :-)

模块化编程

长久以来，Web开发者都是把所需Javascript、CSS文件一股脑放进HTML里面，对于庞大的项目来说管理起来非常麻烦。Node.js的出现改变了这种状态，虽然Javascript的模块并非Node.js发明，但确实是它把这个概念发扬光大了。

但Node.js毕竟是用于服务端的，为了将模块化技术用于浏览器，人们又造出了一大堆工具：RequireJS、Browserify、LABjs、Sea.js、Duo等。同时，由于Javascript的标准没有对模块的规范进行定义，人们又定义了一系列不同的模块定义：CommonJS、AMD、CMD、UMD等。这真是一件令人悲伤的事情，希望ES6 Module的出现能中止这种分裂的状态。

Webpack同时支持CommonJS和AMD形式的模块，对于不支持的模块格式，还支持对模块进行shimming。举个简单的例子：

// content.js
module.exports = "It works from content.js.";

// entry.js
document.write(require("./content.js"));

<!-- index.html -->
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <script type="text/javascript" src="bundle.js" charset="utf-8"></script>
  </body>
</html>

这里entry.js是入口文件，它加载了content.js。通过命令行对entry.js进行编译：

$ webpack ./entry.js bundle.js

打开index.html就会看到content.js中的内容已经被加载进来了。

Web开发中用到的不但有Javascript，还有CSS以及各种静态文件。Webpack定义了一种叫加载器loader的东西，它能够把各种资源文件进行转换，用正确的格式加载到浏览器中。比如对于上述程序，如果我们有一个对应的CSS文件：

/* style.css */
body {
  background: yellow;
}

我们修改一下entry.js来加载该CSS：

require("!style!css!./style.css");
document.write(require("./content.js"));

然后再重新编译、打开index.html就可以看到CSS加载进来了。执行上述程序前我们必须安装所需的loader：

npm install --save-dev style-loader css-loader

在编译时，css-loader会读取CSS文件，并处理其中的import，返回CSS代码；而style-loader会将返回的CSS代码作为DOM的style。如果你用的是SASS，只要把require语句改成require("!style!css!sass!./style.scss")就可以了。

Webpack提供了很多常见的loader，开发的时候可以把用到的文件都require进来，生成一个单一的Javascript，便于发布。

上述require CSS的代码虽然功能强大，但写起来比较繁琐，Webpack支持在配置文件中进行配置，把符合条件的文件用同一组loader来进行处理。下面是我用的一组loader：

{
  module: {
    loaders: [
      {test: /\.coffee$/, loader: 'coffee'},
      {test: /\.html$/,   loader: 'html'},
      {test: /\.json$/,   loader: 'json'},
      {test: /\.css$/,    loader: 'style!css!autoprefixer'},
      {test: /\.scss$/,   loader: 'style!css!autoprefixer!sass'},
      {test: /\.woff$/,   loader: "url?limit=10000&minetype=application/font-woff"},
      {test: /\.ttf$/,    loader: "file"},
      {test: /\.eot$/,    loader: "file"},
      {test: /\.svg$/,    loader: "file"}
    ]
  }
}

有了上述配置，直接require('./style.css')就可以了，系统会自动先执行autoprefixer，然后加载CSS，然后再加载为DOM的style。

此外，Webpack还支持插件，实现对Javascript的压缩、替换等各种操作。

依赖模块的管理

Webpack自己并不提供模块的下载，但它可以和已有的包管理器很好的配合。你可以用npm、Bower、component等来管理你的Web开发资源，同时在Webpack中加载它们。

Webpack的文件加载分为三种：

• 绝对路径，比如require('/home/me/file')。此时会首先检查目标是否为目录，如果是目录则检查package.json的main字段（你可以让Webpack同时检查Bower的字段）；如果没有package.json或者没有main字段，则会用index作为文件名。经过上述过程，我们解析到一个绝对路径的文件名，然后会尝试为其加上扩展名（扩展名可在webpack.config.js中设置），第一个存在的文件作为最终的结果。
• 相对路径，比如require('./file')。使用当前路径或配置文件中的context作为相对路径的目录。加载过程和绝对路径相似。
• 模块路径，如require('module/lib/file')。会在配置文件中的所有查找目录中查找。

对于复杂的模块路径，还可以设置别名。一个路径解析配置的例子：

{
  resolve: {
    root: [appRoot, nodeRoot, bowerRoot],
    modulesDirectories: [appModuleRoot],
    alias: {
      'angular': 'angular/angular',
      'lodash': 'lodash/dist/lodash'
    },
    extensions: ['', '.js', '.coffee', '.html', '.css', '.scss']
  }
}

工具的集成

Webpack能够和grunt、gulp、karma等已有工具很好地集成。

此外，除了输出单一文件，Webpack还支持代码分割、多入口以及运行时模块替换，是非常值得Web开发者关注的一个工具。

最后附上我的配置文件：

// webpack.config.js
var path = require('path');
var webpack = require('webpack');

var appRoot = path.join(__dirname, 'app');
var appModuleRoot = path.join(__dirname, 'app/components');
var bowerRoot = path.join(__dirname, 'bower_components');
var nodeRoot = path.join(__dirname, 'node_modules');

module.exports = {
  entry: 'app',
  output: {
    path: path.resolve('./app/assets'),
    filename: 'bundle.js',
    publicPath: '/assets/'
  },
  resolve: {
    root: [appRoot, nodeRoot, bowerRoot],
    modulesDirectories: [appModuleRoot],
    alias: {
      'angular-ui-tree': 'angular-ui-tree/dist/',
      'angular-date-range-picker': 'angular-date-range-picker/build/'
    },
    extensions: ['', '.js', '.coffee', '.html', '.css', '.scss']
  },
  resolveLoader: {
    root: nodeRoot
  },
  plugins: [
    new webpack.ProvidePlugin({
      _: 'lodash'
    }),
    new webpack.ResolverPlugin([
      new webpack.ResolverPlugin.DirectoryDescriptionFilePlugin("bower.json", ["main"])
    ])
  ],
  module: {
    loaders: [
      {test: /\.coffee$/, loader: 'coffee'},
      {test: /\.html$/,   loader: 'html'},
      {test: /\.json$/,   loader: 'json'},
      {test: /\.css$/,    loader: 'style!css!autoprefixer'},
      {test: /\.scss$/,   loader: 'style!css!autoprefixer!sass'},
      {test: /\.woff$/,   loader: "url?limit=10000&minetype=application/font-woff"},
      {test: /\.ttf$/,    loader: "file"},
      {test: /\.eot$/,    loader: "file"},
      {test: /\.svg$/,    loader: "file"}
    ]
  }
};

使用Homebrew管理程序

Mac中的App主要有两类：一类是从App Store中安装的；另一类是下载安装的。对于前者，没有什么太好的办法，到Purchased里面一个个重新装过就好了；对于后者，用Homebrew来管理更加方便，相比直接的下载安装而言，它是更容易自动化、更易重现的方式。

对于dmg和pkg程序，可以用Homebrew Cask来安装。

如果要装的程序没有在Homebrew或者Cask里面，可以在你的GitHub中建立一个Repo来存放相关的Formula/Cask，然后用brew tap将其加到Homebrew中。

Homebrew的好处是，你很容易将当前安装的程序列表备份起来以备下次安装。另外一种备份方法是采用Brewfile，不过Homebrew已经后悔把这东西加进去了，以后也许会有更好的方案出现吧。

管理配置文件

安装程序其实只是最简单的一步，更麻烦的是如何对这些程序进行配置。当前一个很流行的方式是把你的配置文件放在一个Dotfiles的Repo里，然后将其符号链接到相应的位置。然后你就可以用Git轻松管理你的配置文件了。对于包含敏感信息无法放在GitHub中的信息，也可以放在Dropbox中。

把所有程序的配置文件都搜集起来当然是一件非常繁琐的事情，而Mackup可以把你从这件事情里面解放出来，它记录了很多程序的配置文件，从而能够自动在系统中搜索这些配置文件，备份到你的目录中，然后再符号链接到相应的位置。结合GitHub或者Dropbox来进行备份，真是太方便了！

Dotfiles中还可以保存一些常用的脚本，比如mathiasbynens的dotfiles中就包含了很多OSX的设置脚本，一键运行完成你大部分的系统设置。

然而，单靠配置文件有时候也不能完全解决问题，比如安装vim的时候，希望不但能保留.vimrc之类的配置文件，还希望能把所有的插件装上去。这时候就需要介绍下面一个系统了：Boxen。

用Boxen自动化环境设置

Boxen是GitHub的自动化部署工具，它能够快速为新员工构建一个开发环境。Boxen基于Puppet，它针对Mac系统做了一系列的设置，使得环境配置更加方便快捷。关于Boxen的介绍可以看看Gary Larizza的这篇博客.

GitHub提供了一个Boxen工程的模板，叫做our-boxen，只要将其fork并安装说明文档安装即可。安装完的our-boxen包含了一个基本的开发环境（Ruby、node等），你可以在此基础上加入你自己的东西。一般来说，你可以在modules目录里面添加相关的内容：people添加和用户相关的内容，projects中添加工程相关的内容。我的个人设置在这里。

对系统默认参数的一些配置（比如全局的Ruby版本）可以通过Hiera实现，具体参考相关说明。你可以针对用户进行一些设置，这里是我的个人设置。

你甚至可以把代码的Repo和系统相关的配置写在文件里，下次部署时直接搞定。

Boxen支持Homebrew/Cask，所以我们上面安装的App可以直接写文件中，下次部署时只要一个boxen命令即可。Boxen自身也只是App的安装，其GitHub帐户中包含了很多可用的App，和Homebrew/Cask相比，这些App的更新可能相对较慢，但一般会提供更多的配置选项。对于简单的的应用，我一般使用Homebrew/Cask来管理，对于配置比较复杂的（如Ruby）我会采用Boxen提供的版本。

此外，我写了一个puppet的模块puppet-dotfiles，可以使用Mackup兼容的配置文件，直接在Boxen工程中进行配置，使得程序的配置更加自动化。该模块除了用Mackup的配置文件，还会进行了一些其它的设置，比如安装vim的时候会安装上Vundle及其它插件、自动安装prezto及其模块等。

Boxen的另外一个好处是删除简单，只要把/opt/boxen删除即可（当然可能你还要删除/opt下的homebrew-cask之类的）。

缓存安装文件

虽然上述过程能够大大减轻你的负担，但是在恶劣的网络环境中，下载安装文件就会成为一个瓶颈。我的解决方案是：缓存安装文件。

Homebrew/Cask安装程序时会把安装文件缓存下来，下次重装的时候就不会再次下载了。我的Mac是11年的型号，光驱位换了SSD，所以就把这些缓存文件备份到原来的硬盘：

$ mv `brew --cache` "/Volumes/Macintosh HD/"
$ ln -s "/Volumes/Macintosh HD/cache" `brew --cache`

这样万一SSD坏掉，重装起来也会比较快一点。

当然，编译也是一项非常耗时的任务，这个问题主要存在Homebrew中（因为Cask只是些dmg、pkg）。不过Homebrew非常佛心地提供了编译好的二进制版本（叫做Bottle），只要你用默认选项安装，就会使用二进制版本，免去你的编译之苦。然而，不幸的是，某些程序的编译过程需要具体的路径信息（比如Qt），Homebrew默认是安装在/usr/local的，而Boxen把Homebrew安装在了/opt/boxen/homebrew中，所以就不能享受到这项好处了，希望将来能够有所改进吧！

其它方案

对于这样一个常见问题，肯定是有很多方案的，这里有一些供参考的其它方案：

• osxc: 基于Ansible的一套方案。
• battleschool: 也是基于Ansible的方案。
• kitchenplan: 基于Chef的方案。
• thoughtbot/laptop: 用于Mac和Linux安装配置的一套脚本。

其实还有很多……说说你的方案吧。

引号、撇号、上标符

首先是「引号」及其面目相似的兄弟们：

计算机键盘沿用了打字机的做法，将上述符号浓缩为两个：单直引号（’）和双直引号（“）。ASCII 码中也只收录了这两个字符，所以在早期的电子文档中大多是这两者身兼多职。这种引号通常叫做「Typewriter (“programmer’s”) straight quotes」——「打字机（程序员）直引号」：

“Good morning, Frank,” said Hal.

don’t

’06

the cat’s whiskers.

6’ 2” tall.

为了更好的阅读体验，也有用重音符（反引号）（`）来作为左引号的（如TeX）：

``Good morning, Frank,” said Hal.

随着 Unicode 的普及，计算机显示各种字符已经不成问题，让各个标点各司其职才能取得更好的阅读体验。上述标点符号应按照如下规则使用：

• 用弯引号「’’」、「“”」作为单、双引号。

“Good morning, Frank,” said Hal.

‘Good morning, Frank,’ said Hal.

• 撇号「’」用于缩写词、复数、所有格以及拼音分隔等。

don’t

’06

the cat’s whiskers.

Xi’an

• 上标符「′」、「″」用于表示单位、数学公式等。

6′ 2″ tall.

Tx = x′

• 直引号「’」，「“」只用于编程。

char *s = “Hello world”;

char c = ‘A’;

连字号、连接号

另几个长得比较像的是连字号和连接号：

在 ASCII 中，「-」既当减号又当连字号，有时候几个组合起来作为连接号。在 UNICODE 中这几种符号都有了单独的字符。

• 连字号用于标志合成词或用于断字。

ice‐cream‐flavored candy.

We, therefore, the represen‐

tatives of the United States

of America…

• 数字线用于连接数字（如电话号码中间的短线）。

0571‒87932195

• En dash 通常是 Em dash 的一半，它们的大小分别是大写字母 N 和 M 的宽度。En dash主要用于表示数值范围、对比的数值、相关的两件事或者合成词的属性部分。

June–July 1967

Australia beat American Samoa 31–0.

Pre–Civil War era

• Em dash 表示语气转折，类似于中文的破折号。

Dash 的用法比较复杂，各种类似的符号及其用法可以参见 Wikipedia。

中文引号

中文的引号和英文的引号一样，都是用的弯引号，它们的 UNICODE 值也是一样的。这样导致一个问题：在文中出现引号时，是当成中文的全角呢还是英文的半角呢？因此使用直角引号「『』」的逐渐多了起来。

中英文混排

有一种观点是混排时在中英文之间加上空格，在这方面还没有明确的规范。Adobe InDesign、Microsoft Word等软件在进行中英文混排时都会增大汉字与英文的间距，在这种情况下添加空格就没有必要；然而，大多数情况下我们没有这样的专业排版软件支持，这种情况下要想达到较好的排版效果就需要在汉字和西文之间加上半角的空格。刘昕@知乎认为：

中文正文及标题中出现的英文及数字应该使用半角方式输入，并且在左右各留一个半角空格。如果这些这些半角英文及数字的左边或者右边紧接着任何的中文全角括号或者其他标点符号的话，则不需要加入半角空格。

而梁海@知乎认为中英文混排中使用什么样的标点符号取决于「环境」：

事实上我自己考虑排版的时候从来不从“什么夹杂什么”的角度来看问题，我的思路永远是“环境”。就是说，在我写一段文字的时候，我会有自己的意识，意识到这段文字本质上是什么语言环境，然后以此为基础。而且基本环境中也会有子环境，比如一本中文译文的全部脚注或者某一条脚注或者正文中的一大段引文完全可以是一个英文环境（但我在做这样排版的时候会尽量不让它成为一个英文子环境），然后在中文正文中的一大段英文引文中如果再出现括号内的中文解释，我会酌情使用英文括号。你那最后一句话在我看来仍旧是中文环境，中文的逗号和问号都暗示/表明了这一点，这句话还不够独立。

具体采用什么样的方案要看使用场景，如果能从技术上做到中英文的隔离那是最好的了。

输入

规范使用标点符号最大的障碍在于输入。大部分标点符号都是 UNICODE 的，键盘很难直接输入。根据应用场景的不同大致有以下一些方法：

• Microsoft Word、Open Office 等软件本身提供了一些自动输入的方法，可以根据语境选择正确的标点符号。
• 输入法一般会为标点输入提供一些便捷。特别要推荐「中州韻」输入法，它不但跨平台，还提供了强大的配置方案。
• HTML 可以使用「字符值引用」。
• Windows 可以用下「Alt code」。
• Mac 下可以在「Unicode Hex Input」键盘下用「Option + xxxx」输入，其中 xxxx 表示十六进制的 UNICODE 值。
• 其它的输入方法参见 Wikipedia。

经典类的 MRO

Python 有两种类：经典类（classic class）和新式类（new-style class）。两者的不同之处在于新式类继承自 object。在 Python 2.1 以前，经典类是唯一可用的形式；Python 2.2 引入了新式类，使得类和内置类型更加统一；在 Python 3 中，新式类是唯一支持的类。

经典类采用了一种很简单的 MRO 方法：从左至右的深度优先遍历。以上述「菱形继承」为例，其查找顺序为 [D, B, A, C, A]，如果只保留重复类的第一个则结果为 [D, B, A, C]。我们可以用 inspect.getmro 来获取类的 MRO：

>>> import inspect
>>> class A:
...     def show(self):
...         print "A.show()"
...
>>> class B(A): pass
>>> class C(A):
...     def show(self):
...         print "C.show()"
...
>>> class D(B, C): pass
>>> inspect.getmro(D)
(<class __main__.D at 0x105f0a6d0>, <class __main__.B at 0x105f0a600>, <class __main__.A at 0x105f0a668>, <class __main__.C at 0x105f0a738>)
>>> x = D()
>>> x.show()
A.show()

这种深度优先遍历对于简单的情况还能处理的不错，但是对于上述「菱形继承」其结果却不尽如人意：虽然 C.show() 是 A.show() 的更具体化版本（显示了更多的信息），但我们的 x.show() 没有调用它，而是调用了 A.show()。这显然不是我们希望的结果。

对于新式类而言，所有的类都继承自 object，所以「菱形继承」是非常普遍的现象，因此不可能采用这种 MRO 方式。

Python 2.2 的新式类 MRO

为解决经典类 MRO 所存在的问题，Python 2.2 针对新式类提出了一种新的 MRO 计算方式：在定义类时就计算出该类的 MRO 并将其作为类的属性。因此新式类可以直接通过 __mro__ 属性获取类的 MRO。

Python 2.2 的新式类 MRO 计算方式和经典类 MRO 的计算方式非常相似：它仍然采用从左至右的深度优先遍历，但是如果遍历中出现重复的类，只保留最后一个。重新考虑上面「菱形继承」的例子，由于新式类继承自 object 因此类图稍有改变：

classDiagram
    class object
    class A {
        +show()
    }
    class B
    class C {
        +show()
    }
    class D

    object <|-- A 
    A <|-- B
    A <|-- C
    B <|-- D
    C <|-- D

按照深度遍历，其顺序为 [D, B, A, object, C, A, object]，重复类只保留最后一个，因此变为 [D, B, C, A, object]。代码为：

>>> class A(object):
...     def show(self):
...         print "A.show()"
...
>>> class B(A): pass
>>> class C(A):
...     def show(self):
...         print "C.show()"
...
>>> class D(B, C): pass
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <type 'object'>)
>>> x = D()
>>> x.show()
C.show()

这种 MRO 方式已经能够解决「菱形继承」问题，再让我们看个稍微复杂点的例子：

classDiagram
    class object
    class X
    class Y
    class A
    class B
    class C

    object <|-- X
    object <|-- Y
    X <|-- A
    Y <|-- A
    X <|-- B
    Y <|-- B
    A <|-- C
    B <|-- C

>>> class X(object): pass
>>> class Y(object): pass
>>> class A(X, Y): pass
>>> class B(Y, X): pass
>>> class C(A, B): pass

首先进行深度遍历，结果为 [C, A, X, object, Y, object, B, Y, object, X, object]；然后，只保留重复元素的最后一个，结果为 [C, A, B, Y, X, object]。Python 2.2 在实现该方法的时候进行了调整，使其更尊重基类中类出现的顺序，其实际结果为 [C, A, B, X, Y, object]。

这样的结果是否合理呢？首先我们看下各个类中的方法解析顺序：对于 A 来说，其搜索顺序为 [A, X, Y, object]；对于 B，其搜索顺序为 [B, Y, X, object]；对于 C，其搜索顺序为 [C, A, B, X, Y, object]。我们会发现，B 和 C 中 X、Y 的搜索顺序是相反的！也就是说，当 B 被继承时，它本身的行为竟然也发生了改变，这很容易导致不易察觉的错误。此外，即使把 C 搜索顺序中 X 和 Y 互换仍然不能解决问题，这时候它又会和 A 中的搜索顺序相矛盾。

事实上，不但上述特殊情况会出现问题，在其它情况下也可能出问题。其原因在于，上述继承关系违反了线性化的「 单调性原则 」。Michele Simionato对单调性的定义为：

A MRO is monotonic when the following is true: if C1 precedes C2 in the linearization of C, then C1 precedes C2 in the linearization of any subclass of C. Otherwise, the innocuous operation of deriving a new class could change the resolution order of methods, potentially introducing very subtle bugs.

也就是说，子类不能改变基类的方法搜索顺序。在 Python 2.2 的 MRO 算法中并不能保证这种单调性，它不会阻止程序员写出上述具有二义性的继承关系，因此很可能成为错误的根源。

除了单调性之外，Python 2.2 及 经典类的 MRO 也可能违反继承的「 局部优先级 」，具体例子可以参见官方文档。采用一种更好的 MRO 方式势在必行。

C3 MRO

为解决 Python 2.2 中 MRO 所存在的问题，Python 2.3以后采用了C3 方法来确定方法解析顺序。你如果在 Python 2.3 以后版本里输入上述代码，就会产生一个异常，禁止创建具有二义性的继承关系：

>>> class C(A, B): pass
Traceback (most recent call last):
  File "<ipython-input-8-01bae83dc806>", line 1, in <module>
    class C(A, B): pass
TypeError: Error when calling the metaclass bases
    Cannot create a consistent method resolution
order (MRO) for bases X, Y

我们把类 C 的线性化（MRO）记为 L[C] = [C1, C2,…,CN]。其中 C1 称为 L[C] 的头，其余元素 [C2,…,CN] 称为尾。如果一个类 C 继承自基类 B1、B2、……、BN，那么我们可以根据以下两步计算出 L[C]：

1. L[object] = [object]
2. L[C(B1…BN)] = [C] + merge(L[B1]…L[BN], [B1]…[BN])

这里的关键在于 merge，其输入是一组列表，按照如下方式输出一个列表：

1. 检查第一个列表的头元素（如 L[B1] 的头），记作 H。
2. 若 H 未出现在其它列表的尾部，则将其输出，并将其从所有列表中删除，然后回到步骤1；否则，取出下一个列表的头部记作 H，继续该步骤。
3. 重复上述步骤，直至列表为空或者不能再找出可以输出的元素。如果是前一种情况，则算法结束；如果是后一种情况，说明无法构建继承关系，Python 会抛出异常。

该方法有点类似于图的拓扑排序，但它同时还考虑了基类的出现顺序。我们用 C3 分析一下刚才的例子。

object，X，Y 的线性化结果比较简单：

L[object] = [object]
L[X] = [X, object]
L[Y] = [Y, object]

A 的线性化计算如下：

L[A] = [A] + merge(L[X], L[Y], [X], [Y])
     = [A] + merge([X, object], [Y, object], [X], [Y])
     = [A, X] + merge([object], [Y, object], [Y])
     = [A, X, Y] + merge([object], [object])
     = [A, X, Y, object]

注意第3步，merge([object], [Y, object], [Y]) 中首先输出的是 Y 而不是 object。这是因为 object 虽然是第一个列表的头，但是它出现在了第二个列表的尾部。所以我们会跳过第一个列表，去检查第二个列表的头部，也就是 Y。Y 没有出现在其它列表的尾部，所以将其输出。

同理，B 的线性化结果为：

L[B] = [B, Y, X, object]

最后，我们看看 C 的线性化结果：

L[C] = [C] + merge(L[A], L[B], [A], [B])
     = [C] + merge([A, X, Y, object], [B, Y, X, object], [A], [B])
     = [C, A] + merge([X, Y, object], [B, Y, X, object], [B])
     = [C, A, B] + merge([X, Y, object], [Y, X, object])

到了最后一步我们没有办法继续计算下去 了：X 虽然是第一个列表的头，但是它出现在了第二个列表的尾部；Y 虽然是第二个列表的头，但是它出现在了第一个列表的尾部。因此，我们无法构建一个没有二义性的继承关系，只能手工去解决（比如改变 B 基类中 X、Y 的顺序）。

我们再看一个没有冲突的例子：

classDiagram
    class object
    class A
    class B
    class C
    class D
    class E
    class F

    object <|-- D
    object <|-- E
    object <|-- F
    D <|-- B
    D <|-- C
    E <|-- B
    F <|-- C
    B <|-- A
    C <|-- A

计算过程如下：

L[object] = [object]
L[D] = [D, object]
L[E] = [E, object]
L[F] = [F, object]
L[B] = [B, D, E, object]
L[C] = [C, D, F, object]
L[A] = [A] + merge(L[B], L[C], [B], [C])
     = [A] + merge([B, D, E, object], [C, D, F, object], [B], [C])
     = [A, B] + merge([D, E, object], [C, D, F, object], [C])
     = [A, B, C] + merge([D, E, object], [D, F, object])
     = [A, B, C, D] + merge([E, object], [F, object])
     = [A, B, C, D, E] + merge([object], [F, object])
     = [A, B, C, D, E, F] + merge([object], [object])
     = [A, B, C, D, E, F, object]

当然，可以用代码验证类的 MRO，上面的例子可以写作：

>>> class D(object): pass
>>> class E(object): pass
>>> class F(object): pass
>>> class B(D, E): pass
>>> class C(D, F): pass
>>> class A(B, C): pass
>>> A.__mro__
(<class '__main__.A'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.D'>, <class '__main__.E'>, <class '__main__.F'>, <type 'object'>)