Nginx是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器，相较于Apache，具有占有内存少、稳定性高等优势。Nginx安装非常简单、配置文件简洁，但是配置的类目却不少，本文主要记录Nginx的安装以及相关的配置（以下操作在CentOS6.7 64bit环境下）。

Nginx安装

作为一个喜欢折腾的人，Nginx首选当然是采用源码包安装，不过也可以选择yum、rpm来安装。Mac下，用brew install nginx来快速安装。

为了能从源码包编译Nginx，除了编译器之外，还需要提供OpenSSL（启用SSL)以及Perl（使用rewrite）、zlib压缩库等等。由于Nginx的模块化特性，还可以安装第三方模块为Nginx提供额外的功能，如ngx_lua、pageSpeed。

第三方模块可以在github或者https://www.nginx.com/resources/wiki/modules/查找。

最近一段时间，函数式编程又开始活跃起来了。函数式编程是一种编程范式，它将电脑运算视为数学上的函数计算，并且避免使用程序状态以及可变数据。函数式编程强调程序执行的结果而非执行的过程，倡导利用若干简单的执行单元让计算结果不断渐进，逐层推导复杂的运算，而不是设计一个复杂的执行过程。

今天我试图用js去梳理函数式编程相关的一些知识。文中代码风格采用Standard，使用ES6语法。

函数式编程初试

首先我们来看一个例子，计算数组元素的和。

我们可以快速用命令式来实现，代码如下：

const arr = [1, 2, 3, 4]
let sum = 0

for (let i = 0, len = arr.length; i < len; i++) {
  sum += arr[i]
}

利用ES5种提供的reduce方法，代码如下：

const arr = [1, 2, 3, 4]
let sum = arr.reduce((x, a) => x + a)

可以看到，reduce的函数式代码与前面命令式代码解决问题的方式和角度是完全不同的。命令式需要关心所有的过程，如何遍历以及如何组织结果数据。而reduce由于将遍历、操作以及结果数据的组织的过程封装至Array中，我们真正关心的逻辑就是reduce的参数里的匿名函数中的过程。

我们清楚，代码质量应该由代码测试来保证。在ES6规范发布后，越来越多的项目开始尝试使用ES6甚至是ES7，那么，本文就以ES6的代码来谈谈如何构建高效的测试工作流。

本文主要会使用到如下工具：

• karma 自动化测试工具，命令行执行浏览器测试
• babel 编译ES6/7代码
• mocha 测试框架
• chai 断言库

接下来，我们通过一个简单的实例来展示如何构建ES6的测试工作流。

安装

我们通过npm的方式来安装依赖包，以下为依赖包列表：

"devDependencies": {
  "babel-plugin-transform-es2015-modules-umd": "^6.6.5",
  "babel-preset-es2015": "^6.6.0",
  "chai": "^3.5.0",
  "karma": "^0.13.22",
  "karma-babel-preprocessor": "^6.0.1",
  "karma-chai": "^0.1.0",
  "karma-chrome-launcher": "^0.2.2",
  "karma-coverage": "^1.0.0",
  "karma-mocha": "^0.2.2",
  "karma-mocha-reporter": "^2.0.0",
  "mocha": "^2.4.5"
}

执行 npm install 将安装所依赖的包。

这里简单说明一下这份依赖表中的一些包，karma-mocha-reporter用于使karma日志输出保持mocha原来的风格；karma-coverage是用来检验测试的代码覆盖率。

babel 6默认情况下并没有转换ES6代码的功能，需要安装相应的转换器插件，所以安装了babel-preset-es2015和babel-plugin-transform-es2015-modules-umd，通过.babelrc文件来设置，具体的配置在下一节给出。

众所周知，我们都知道300-399这一系列的状态码代表的是重定向状态码。重定向状态码要么告知客户端使用替代位置来访问她们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的Location首部来告知客户端已被移走，以及现在可以在哪里找到它。这样子，浏览器就可以在不打扰用户的情况下，透明地转到新的位置。

那么，接下来，我们从状态码出发，梳理一下3xx状态码（300-307），以及缓存一系列相关的东西。（注：HTTP/1.1版本的内容）

300 Multiple Choices

客户端请求一个实际指向多个资源的URL时会返回这个状态码。

比如说，一个站点提供了中文和英文两个版本，理想情况下，服务器应当向中文用户发送中文版，向英文用户发送英文版。HTTP提供了内容协商方法，允许客户端和服务器作这样的决定。内容协商包含客户端驱动的协商、服务器驱动的协商以及透明协商。

客户端驱动由客户端发起请求，服务器发送可选项的列表，客户端进行选择；服务器驱动是由服务器来检查客户端的请求首部集并决定提供提供哪个版本的页面（q值机制，Vary首部）；透明协商是由某个中间设备（通常是缓存代理）代表客户端进行请求协商。

而300 Multiple Choices属于客户端驱动的协商。服务器发送回HTTP/1.1响应时，使用300 Multiple Choices响应代码。客户端浏览器收到这种响应时，可能会弹出对话窗口，让用户选择。其流程如下：

趁着元旦放假重写了博客，后端采用Node.js+MongoDb，前端采用gulp＋webpack打包，这几天才将blog.crazycoder.cc博客的内容全部迁移过来。折腾自己的博客一年多了，本文主要写一下我自己博客的变迁记录。

目前版本的博客做了比较多的优化，可以看一下 Google PageSpeed Insights 的评分。

这个版本主要做了首次加载的优化，减少http请求，后面会涉及到。