Sequelize.js是一个用于Node.js的数据库ORM库，支持Postgres、MySQL/MariaDB、SQLite、SQL Server等引擎。

本文记录一些团队在使用Sequelize过程中积累的经验教训。

介绍

ORM即Object Relational Mapping，中文叫“对象关系映射”。简单地说就是可以将数据库的各种对象（表、字段）及关系映射为程序语言的对象和关系，从而使开发者不需要直接操作数据库，转而操作对象即可。

例如，将表user映射为模型User后，从数据库中查询id为1的用户就可以直接调用findOne()方法：

1
2
3
4
5

const user = await User.findOne({
    where: {
        id: 1
    }
});

这样做会带来几个明显的好处：

1. 降低开发难度：ORM都有完善的文档，几乎所有的操作只需要按文档调用指定方法即可，不需要自己拼接SQL
2. 提升安全性：ORM会处理好SQL注入问题，不需要开发者关注
3. 降低封装复杂度：公共逻辑可以基于ORM封装，非常方便

下文不区分“模型”和“Model”，均指Sequelize中与数据表对应的数据模型。

AMP 全称 Accelerated Mobile Pages ，是由 Google 提出的一种移动端页面的规范。相比普通 HTML 而言，最大的特点是对页面中可用元素进行了严格的限制，以确保高性能。此外，Google 还对 AMP 页面提供了高速缓存，如果从 Google 搜索中打开 AMP 页面，速度非常快，几乎是秒开。

前几天将我的博客完全迁移到了 AMP，在此也做一个记录。

作为单独页面存在的 AMP

在很长一段时间内，我都以为 AMP 只适用于移动端某些特殊场景，至少文章页应该是适用的，于是自然而然就想到了博客应该是非常适合 AMP 的场景。因为我的博客使用的是著名的静态博客程序 Hexo，所以也就很自然地想到了，会不会有人已经写好了 Hexo 的 AMP 插件？搜了一下，果然没有失望，找到了一个名为 hexo-generator-amp的插件。

这个插件不会修改已有的文章页面，而是会为文章页面再生成一个合法的 AMP 页面。这两个页面可以互相引用，表示一个是普通页面，一个是 AMP 页面。这种方式也是 Google 搜索等平台认可的 AMP 生成方式。

按照插件的文档，使用起来还是比较简单的，具体的方式就不写了，直接参考文档即可。有几个值得注意的点：

1. 一定要修改文章页的模板，添加link[rel=amphtml]链接，要不然搜索无法找到 AMP 页面
2. AMP 页面会自动在head中添加canonical链接回原有的文章页

这个插件支持自己修改模板。鉴于我对它的样式并不是很满意，没有修改的欲望，于是也就没有去改它。如果你需要修改 AMP 模板的话，可以在网址中添加#development=1，然后在控制台中查看 AMP 验证结果。

本文为《Web前后端漏洞分析与防御》课程的配套文章。早年在慕课社区发布，现补发在博客上。

一说到安全，大家总会特别敏感，尤其是有相当部分的前端开发者并不了解安全相关的知识，颇有谈虎色变的感觉。具体到前端安全这个话题呢，又有些说不清道不明，因为大部分的防御方案，总少不了后端的参与，也有开发者慢慢觉得好像安全都应该由后端来关注了。

其实不然，起码 XSS CSRF 这一类的安全问题前端是一定要了解它们的原理和防御方法的。从防御方法上来说，XSS 和 CSRF 的防御在业界都有比较成熟的方案了。本文将记录一些比较新的防御方案，可能有一些比较老的书籍或者文章中不会提及这些方法。

本文首发于富途web开发团队博客 https://futu.im/posts/2017-05-05-how-nginx-processes-a-request/

Nginx首先需要确定由哪个server来处理请求。我们看一个简单的配置文件，在*:80端口上包含了三个虚拟主机（server）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

server {
    listen      80;
    server_name example.org www.example.org;
    ...
}

server {
    listen      80;
    server_name example.net www.example.net;
    ...
}

server {
    listen      80;
    server_name example.com www.example.com;
    ...
}

在这个配置下，Nginx只通过请求的Host头来决定路由到哪个server。如果Host头的值跟所有的server的server_name都不匹配，或者请求中没有包含这个阔大，Nginx会使用这个端口上的默认server。在这个配置文件中，默认server是指第一个，这正是Nginx标准的默认行为。默认server也可以通过配置显示指定，只需要在listen指令值中加上default_server参数即可。

ES2015（ES6）中新增了几种数据类型，包括Map WeakMap Set WeakSet等。其中Map可以与我们熟悉的对象Object进行对照，他们的功能都是提供一个键值对集合，主要的区别在于Object的key只能是字符串，而Map的key可以是任意类型。关于Map的大致用法可以参考MDN，我在前一篇文章《也谈JavaScript数组去重》中也有提及。

今天要讨论的主角是WeakMap。

按照MDN上的说明

WeakMap 对象是键/值对的集合，且其中的键是弱引用的。其键只能是对象，而值则可以是任意的。

从这段描述来看，我们可以大致推断出，WeakMap与Map的主要区别在于两点：

1. WeakMap对key的引用是弱引用
2. WeakMap的key只能是对象

这两点意味着什么呢？反正我第一眼看到的时候不是拉格良日懵就是三元二次懵的状态。于是围绕WeakMap去查阅了一些资料，渐渐地有了一些更深入的认识，记录成本文。

JavaScript的数组去重是一个老生常谈的话题了。随便搜一搜就能找到非常多不同版本的解法。

昨天在微博上看到一篇文章，也写数组去重，主要推崇的方法是将利用数组元素当作对象key来去重。我在微博转发了“用对象key去重不是个好办法…”然后作者问什么才是推荐的方法。

细想一下，这样一个看似简单的需求，如果要做到完备，涉及的知识和需要注意的地方着实不少，于是诞生此文。

定义重复（相等）

要去重，首先得定义，什么叫作“重复”，即具体到代码而言，两个数据在什么情况下可以算是相等的。这并不是一个很容易的问题。

对于原始值而言，我们很容易想到1和1是相等的，'1'和'1'也是相等的。那么，1和'1'是相等的么？

如果这个问题还好说，只要回答“是”或者“不是”即可。那么下面这些情况就没那么容易了。

本文首发于富途web开发团队博客，原文链接https://futu.im/posts/capture-video-on-web/。

最近在某个需求的评审会上，产品同学脑洞大开，提出了使用web录制视频的想法。并兴致勃勃地说“看，XXX网站可以调用摄像头，还能聊天呢！”本着负（Zhuang）责（Bi）的原则，我们也对该方案做了认真的预研。大致结论：

1. 非实时录制时（文件上传框），兼容性相对较好，且API和性能稳定
2. 实时录制视频在Chrome for Android中可行，其它机型和浏览器均不可使用。考虑到相关标准仍处于不稳定状态，不建议在产品中使用
3. 微信有非公开接口可以调用实时视频录制（微证券使用）

详细方案如下：

相比其他语言（特指PHP）而言，Node.js应用更需要关注出错信息，因为一旦处理不慎，就会导致应用crash。

一种偷懒的方法是使用PM2之类的进程管理软件来启动Node.js进程，从而达到出错crash后自动重新启动应用的目的。

当然更好的办法则是手工捕获错误，然后进行适当的处理，防止应用产生未被接住的错误导致crash。

在捕获到Node.js产生的错误后，下一步自然是记录到错误日志中，以便日后可以进行分析，并针对性地排查修改。本文要说的，即是对错误日志的处理方式之一——告警。

告警是运维工作中非常重要的一个环节，它能让开发者（维护者）及时获知应用出错状态和详情，及早介入处理，将线上故障的影响降低到最低。而要实现告警功能，则需要从两方面入手，一方面是对错误信息进行集中处理（分类、分级、合并、限流等），另一方面需要将这些错误信息及时推送出去。

如果工作流严重依赖分支合并的话，也难免会碰到需要回滚合并的情况。而且回滚还分为两种情况：永久回滚，或者回滚后在稍后重新合并。

假设有如下分支图：

注：Git分支图中的箭头表示依赖关系，并不是分支发展路线。发展路线和箭头是相反的。也就是图中是从C1开始一直发展到C12的。

假设要回滚C10。

第一种解决方案是将master回退到C8，然后将两个特性分支jk/post-checkout和db/push-cleanup合并过来。

1
2
3
4

git checkout master
git reset --hard [sha_of_C8]
git merge jk/post-checkout
git merge db/push-cleanup

完成之后，分支图如下：

接下来就可以继续在新的master上工作，然后在适当的时候将tv/rebase-stat合并回来。

去年10月份，在我们被产品节奏逼到墙角无路可走的时候，我们在几乎没有准备的情况下，在团队中引入了Git。目前时间已经过去半年，回顾这半年的时间，基本还是运作得比较顺利。当然过程中也少不了踩坑，因此记录一些心得。

Why Git?

如果用一句话来说的话，我们是冲“分支”而来的。背景如下：

团队的固定版本节奏为两周一个版本，一周半的时间开发，半周时间测试发布。如果使用软件工程中的概念来说的话，这是一个比较典型的瀑布式流程，即“需求->设计->开发->测试->发布”，然后周而复始，过程中几乎没有重叠。

伴随着瀑布式的流程，代码也只有一份，“开发->改bug->发布”，周而复始。

直到去年10月，公司做了一场声势浩大的营销活动，灾难开始了：一方面需要以并不确定的研发周期支持各种运营活动（运营时间不等人，必须快速写快速发），一方面是运营活动带来大量客户，与客户相关的流程也陷入频繁修改发布的过程。此外支持各种终端需求也集中爆发，需要web侧快速跟进上线。当然，还有一个东西，就是上面瀑布流程中两周发布一次的“主版本”。当这么多版本交叠在一起时，我们发现必须要引入分支来管理研发过程。于是果断切Git。