使用Git的时候，有时候会碰到需要从Git仓库中永久“抹除”某些敏感信息的情况。例如不小心提交了密码之类的信息到仓库，此时只抹掉这些信息重新提交是没有用的，因为其他人仍然可以通过Git历史看到这些敏感信息。因此需要一种方法将这些信息彻底从仓库中抹去。

如果去网上搜索的话，能很容易找到使用branch-filter来处理的方法，例如

1

git filter-branch --tree-filter "find . -name '*.*' -exec sed -i '' -e 's/OLDSTRING/NEWSTRING/g' {} \;" -f

写法有很多种，但是思路都差不多，就是遍历一遍所有的提交，对这些提交执行指定的命令（例如用sed替换指定的内容，或者移除相关文件），然后重新生成新的提交和分支。

不过这种思路对于我来说却不太受用，原因有几个：

1. 命令行掌握不太好，看到这种命令都不太认识，完全不敢直接放在项目中去跑
2. 直接进行字符串级别的替换，在某些情况下不够用，例如想通过更复杂的编辑手段（新增文本、修改文本、删除文本同时操作）抹除敏感信息
3. 直接对整个仓库/整个文件进行字符串级别的替换还是有些不放心，毕竟要修改的部分是明确的，却无法明确地指定这个命令只修改这一部分信息

那怎么办呢？其实在这种场景下，也可以尝试使用git rebase来解决问题。

rebase是干什么的

rebase顾名思义，就是重新确定一个提交（一个分支）的“基”，这个“基”就是指它的祖先元素。具体的做法是，首先将提交退回到“基”所在的点，然后将之前做过的提交在这个“基”的基础上重复做一遍。相当于修改了当前分支衍生出来的基础，因此中文也被译为“变基”。

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合并回来。