构建工具 - FIS 的使用

13年下半年的时候，第一次接触前端的构建工具，那时候好像刚好在某个会议上百度宣布了 FIS 这个工具，然后就选择了 FIS （其实小部分的原因是因为有中文文档，这个习惯非常不好，我现在已经强制改掉了）。由于那时候前置知识比较欠缺，使用起来还是有点吃力的，但是基本的功能也在项目开发中起到了很大的帮助。嗯，那时候还比较菜，啥都不知道。

后来来到了现在这个团队，根据公司内部已有的项目，改用了 Grunt 来作为项目的构建工具。那时候需求还比较简单，Grunt 并没有太多欠缺的地方。再后来，由我操刀对项目进行全面的重构，我再次选择了 FIS。

由于前置知识的积累以及对 Grunt 的使用，再次使用 FIS 并没有遇到太多的阻碍。我想，如果你已经掌握了 Grunt，可以尝试下使用 FIS 作为某个项目的构建工具，应该会很快的清楚两者之间的差距。

以下开始介绍 FIS 在我所跟的项目里的使用，并没有太基础的入门教程哦，官方的文档虽然写的烂七八糟的，但是还是可以看滴。实在不懂就可以搜索下 issue 或者加入官方基友群，900多号全国顶级互联网公司前端为你解答疑问！

很久以前，就在备忘录上面写好了这篇文章的大纲，希望抽个空把这个阶段前端工程化的一些心得以文字的方式记录下来，但是万事开头难，拖了很久。而且有很多东西我更提倡用面对面的交流去阐释，所以动手写这篇文章还是因为要在公司内部做一个分享会，算是先组织下语言吧。

我以前写了一篇博文叫 《Web-IM 系统的前端设计与实现》 大概的说了下当时的一些前端架构的东西。第一，那篇文章写的比较少，大概说了下；第二，前端技术发展的很快，现在这个项目的前端经过重构，已经完全跟当时不一样了，所以，还是另写一篇博文来细说下自己对前端工程化的一些看法及在项目上的实践。

由于本人能力有限，这篇博文也是以我目前最高水平能写出的东西，难免会有一些差错或不理想的地方，仅供大家参考，如果有任何的建议，欢迎 Email 我，一起交流！

按理来说，应该是一个很简单的过程。从多说导出标准的备份文件，导入 Disqus，就完事了。但是我就整整的折腾了几天，评论是导入进去了，但是在博文页面始终没有把原来的评论显示出来。今天下午，甚至向 Disqus 官方发送了求救邮件。

就在刚才，才发现原来 Disqus 是根据文章的 URL 作为 Primary Key 的，而我新的博客系统的文章 URL 结尾比原来的少了个 /。擦，就是这一个字符，导致没有把原先的评论显示出来

1
2

Old: http://example.com/article
New: http://example.com/article/

导入的具体过程

首先，在多说的后台将评论（包括文章）导出为一个 export.json 文件。这个文件格式是不被 Disqus 认的，所以我们得把它转换成 wordpress 导出的文件格式

很久以前，写了一篇博文 How To Deploy Octopress , 介绍了如何使用 Octopress 搭建一个高B格的博客系统。

可能是因为不熟悉 Ruby 的原因，自己修改好的博客主题（没有备份）在前几天因为 rake 命令无法运行的情况下，不小心清空了。本来想着重新写一遍的，但是越写越不顺手，就开始寻找一款新的博客系统。

后来找到了 Hexo ，作为一个前端，看到是基于 Node.js 写的，当然是无法抗拒的，所以果断的开始折腾 Hexo。

文章最后面，可以下载到这个博客现在所使用的 Hexo 主题，如果你喜好的话。

如何搭建

不想再累赘当中细节，愿意折腾的 Hexo 和 Octopress 的人，应该看文档基本就搞定了。而且因为是基于 Node.js , 不像 Octopress 在 Windows 平台下面会遇到一些不知所以然的问题。Hexo 明显容易很多，编译速度也快非常多。

因为 Hexo 的作者是台湾人，还提供了简体中文的文档，多贴心，看不懂英文不能再成为你不动脑筋的借口了。

自动化能解放人类的双手，而且更重要的是，因为按照规定的流程来走，也减少了很多误操作的产生。不知道大家平时都是怎么样更新自己生产环境的代码的，FTP 覆盖旧文件、服务器定时任务去 build 最新的源码，还是有更高级的做法？

目前我在使用 Git Hook 来部署自己的项目。Git Hook 是 Git 提供的一个钩子，能被特定的事件触发后调用。其实，更通俗的讲，当你设置了 Git Hook 后，只要你的远程仓库收到一次 push 之后，Git Hook 就能帮你执行一次 bash 脚本。

下面是我使用 Git Hook 进行简单的自动化部署，可能还有更高级的做法，大家自己去挖掘。

在服务器初始化一个远程 Git 仓库

git init 和 git --bare init 初始化出来的仓库是完全不一样的，具体我 Google 了下，英文倒是理解了，但是要翻译出中文却不知道用什么形容词去称呼这2种仓库。

这里我们要通过 git --bare init 初始化一个远程仓库

前几天说给博客部署 SSL 证书来提高逼格，后来因为自己一个项目的需要，也跟着申请了多了一张 SSL 证书，按照相同的流程部署上去后，发现前面的域名的证书都 load 到了新增加的那张证书。接着 Google 了下，原来是 Nginx 编译的时候没有开启 TLS SNI ，这样就导致了同一 IP 下只能支持一张证书。

查看已安装的 Nginx 是否开启 TLS SNI

1
2
3
4
5

$ nginx -V
ginx version: nginx/1.6.2
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-55)
TLS SNI support disabled
configure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module

TLS SNI support disabled 即未开启

[update] 本文于 2017-12-29 进行过一次修订

我以前没有接触过 SSL ，导致签发人生中第一张 SSL 证书的时候，Private Key 是通过第三方生成的，理论上来说这张证书基本上是废了，因为你家门的钥匙都是别人帮你配的，谁知道他有没有留一个副本！所以 Private Key 一定得自己生成。

以下的内容，随随便便搜索引擎便能搜索到更加详细的，我在这里也就不累赘了，大概的说一下一些简单的东西。

SSL 证书有什么用

• SSL 是一个加密协议，它能保证你的数据在传输的过程中不被截取
• 它能保证你的网站的内容不被篡改，比如国内的各宽带运营商，强制在你的网站上加 Javascript 代码，投放广告
• iOS APP 和 小程序 强制要求使用 HTTPS 传输内容

写在前面

从14年3月份入职之后，就一直在跟公司的一个即时 IM 的 Web APP 。15年已经来了，博客还没有一篇更新，就来聊聊在做这个 APP 的时候遇到的一些坑和一些总结吧。由于刚开始经验有限，所以在系统设计方面有很多的缺陷和不足，随着知识的积累，通过不断调整项目目录和一些规范，最终变成了下面的前端模型。

设计理念

期间重构时受到 UC前端工程实践.pdf 模块化开发 开发思想的影响，我们也在 APP 中引入了 模块化 的概念。正如里面所说：我们希望能像搭积木一样开发和维护系统，最终通过组装模块得到一个完整的应用。

• 模块是可组合、可分解和更换的单元
• 模块具有一定的独立性
• 将模块所需的js、css、图片、模板维护在一起 ( 我们未采用 )
• 组件生态，同团队不同项目之间能有可复用的模块

以前这个博客是托管在 stdyun 的，后来不知道什么原因（貌似被美团云收购？), octopress 托管服务终止了，原有的网站被转移在外国的服务器上，而且访问速度越来越慢，这不得不让我考虑重新寻找一个免费的 octopress 托管服务。
几经斟酌，觉得选用 GitHub 和 GitCafe ，他们分别是国外的、国内的代码托管服务商，也都提供 Git Pages 服务，我们可以把 octopress 托管在他们那。

GitHub Pages

具体的托管操作在互联网上面大把，这里就不在累赘，大概如下

• GitHub 上面创建一个与你用户名相同前缀的 Repository ，比如我的 BelinChung/belinchung.github.io
• cd path/your/octopress/folder
• 初始化 rake setup_github_pages ，按提示输入你的 Repository URL
• 编译和发布 rake generate rake deploy

RESTful

WEB APP 的概念越来越火，单页应用视乎也成为趋势，看着以前在 HTML 夹杂着用来渲染 View 层的 PHP 代码，总感觉好不舒服。自己也越来越趋向于前端和后端的代码完全分离开来。

现在是移动互联网的时代，我们发现几乎所有的网站、产品都不可避免的遇到一个需求：多平台整合。一个基于 RESTful 的后端架构是放眼未来的做法。

Access Token

捣鼓了那么久的微博开放平台的 API ，看到 Access Token 自然再熟悉不过了。OAuth2.0 授权成功后返回的一个授权码，可后续校验 API 调用的有效性。