随着 Web 的发展，HTTP/1.x 已经很难满足现在的需求，Google 因此开发了 SPDY 作为尝试，HTTP/2 在此基础上应运而生。HTTP/2 在2015年5月被批准，目前已经在很多 Web 浏览器和服务器中得到实现。

HTTP/2 和 TLS 组合可以提升你的站点性能，并且让用户觉得你的网站很安全。

服务器软件版本支持

请确保你服务器的软件版本号支持开启 HTTP/2，否则坑很大，坑死人。

• Nginx ≥ v1.9.5
• openSSL ≥ v1.0.2

一直对 Hybrid App 有比较浓厚的兴趣。包括几年前玩的 Phonegap/Cordova 和最近玩的 react-native，Webview 模式下的 Hybrid 在 Android 设备上显然有一些性能上的缺陷。 RN 看似不错，很多大厂也陆续把 APP 的部分模块或整个 APP 通过 RN 重写，但前途如何，不得而知，毕竟 “前会玩”。

V2 上很多关于 [ Hybrid App 能否取代原生APP ] 的主题下讨论的热火朝天，不亚于 [ PHP 是否是世界上最好的语言 ] 的讨论。为什么是取代而不是共存呢？

首先我们来看一下官方的 Changelog 这个版本有哪些 breaking changes。其中大部分变更暂时我还没有使用到，所以就忽略。但是 Android 有个变更貌似改变挺大了，也直接导致了大部分的第三方插件直接无法使用

1
2
3

Change the application template (49f20f4) - @foghina
* Plugins which pass activity reference in the constructor need to be updated to extend ReactContextBaseJavaModule use getCurrentActivity to get the activity reference. This change is backward compatible.
* Apps need to be migrated to use the latest template

大概的意思是：这个版本我们变更了 APP 的模板，如果你的插件选择在构造函数中传递当前的 activity，那么在这个版本中需要升级到通过继承 ReactContextBaseJavaModule 来获取当前的 activity，这个改变是可以向下兼容的。
Continue reading

最近把公司一个 Web APP 项目用 Electron 封装了一个 Mac 客户端，主要是弥补了 Web 浏览器的一些先天不足：

• 支持原生的通知
• 支持原生的 icon 未读提醒
• 支持原生的系统托盘
• 增强网络状态变更的感知

其中以前下载方式是通过打开系统浏览器进行文件下载的。因为文件需要鉴权，还得携带一些敏感的 cookie、token 过去，感觉不安全，所以希望文件下载能在 APP 内完成
Continue reading

写在前面

使用 MacBook Pro 也2年多了，慢慢地积累了一些工作中好用的 APP，帮助自己更高效的工作。正版化也一直在进行着，除了 IDE 用的是教育版订阅之外，其他已经都是正版了（但我不排除 License 授权不支持工作用），力所能及的支持正版吧，毕竟自己也是软件开发从业者。

APP 合集

每个 APP 对应一段简单的描述，数量还不多，就暂时不分类了，大概的排一下。
Continue reading

构建工具 - 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 初始化一个远程仓库