今天是端午节，首先祝大家端午节快乐，然后今天要和大家说一下最近对 think-mongo 模块做了一些升级。ThinkJS 3 虽然已经支持使用 think-mongoose 来接入 mongoose 模块，不过因为文档这块默认还是 think-mongo 所以用这个模块的同学还是比较多。而这个模块因为是两三年前开发的了，依赖的 mongodb 模块一直是 2.x 的版本，适配 MongoDB 数据库 2.0 版本。而 MongoDB 在 2015 年的时候就升级到了 3.0 版本，2018 年的时候升级到了 4.0 的版本。其中 4.0 的版本增加了事务的功能，这个让许多同学非常心动。所以很多同学提 issue 问能否将 think-mongo 升级一下支持最新版的 MongoDB。
在 ThinkJS 的用户群里，经常有开发者提出需要对源码进行加密保护的需求。我们知道 JavaScript 是一门动态语言，不像其他静态语言可以编译成二进制包防止源码泄露。所以就出现了 pkg、nexe 之类的工具，支持将 JS 代码连同 Node 一块打包成一个可执行文件，一来解决了环境依赖的问题，二来解决了大家关心的源码保护的问题。
在 pkg 模块的 README 中，罗列了它的几大用处，如果你有下面的几个需求的话建议不妨试试。
Chimee 是由奇舞团开源的一套可扩展的H5组件化播放器框架。由于前段时间业务有视频播放的需求所以使用了它，并基于它提供的插件系统之上开发了一系列的插件，其中最复杂的是控制条插件。由于默认的样式无（实）法（在）满（是）足（太）设（难）计（看）需（了）求（！），所以我们重新开发了一套 lizheing/chimee-plugin-controlbar 并总结一些心得，希望对大家有帮助。
ZEIT 是免费的云平台，支持部署静态网站以及 Serverless 函数。Serverless 是近几年比较火的概念，简单去理解就是你只需要去实现具体的业务逻辑，而与最终服务相关的服务器、HTTP 服务等则由第三方管理。Serverless 又被称为 FaaS（函数即服务），由于业务粒度非常细，所以非常方便做动态扩容等自动化运维任务。
//一个最简单的基于 Node.js 的 Serverless 函数
module.exports = function(req, res) {
const { name = 'World' } = req.query
res.send(`Hello ${name}!`)
}
通过 ZEIT 提供的 CLI 工具 now，我们可以一条命令将 Node.js, Golang, Python, Ruby, PHP, Rust 等语言的应用部署到 ZEIT 上。如果你想了解更多关于 ZEIT 这个公司的知识也可以看这篇知乎回答了解更多。
由于我所在的业务是资讯内容类业务，因而在业务中会经常碰到如下场景：有一个内容列表，列表中需要按照一定的规则插入广告。除了获取广告数据，广告展现和点击后需要有打点上报逻辑。正常来说我们会这么写：
这篇文章是多年前在 SegmentFault 上的一个回答，原问题是问如何使用 Canvas 实现一个下图类似的圆环选择器，点击后会出现对应的日期。虽然已经有 Canvas 的答案了，不过当时正好在学习 SVG 就顺手自己实现了一下。我感觉对大家去理解 SVG 的贝塞尔曲线会有一定的帮助，所以重新整理了下发出来。另外感兴趣的同学还可以去原问题上看一下，除了标准答案 Canvas 的实现以及我写的 SVG 实现之外，还有使用 DIV+CSS 的实现方案。
说到视频字幕格式，一般大家都会想到 .srt, .ass 之类大家比较常用的格式。而现在说到 Web 字幕格式，大家第一反应肯定都是 WebVTT。我们知道在<video>或者<audio> 标签中要加载字幕的话，需要使用 <track> 标签将字幕文件嵌入进来。而在 track 的文档中我们会发现其实还有一种 Web 字幕格式，那就是本文的主角 TTML。
The tracks are formatted in WebVTT format (.vtt files) — Web Video Text Tracks or Timed Text Markup Language (TTML).
via: <track>: The Embed Text Track element
第一次接触到目录遍历漏洞还是在 ThinkJS 2 的时候。代码如下图，目的是当用户访问的 URL 是静态资源的时候返回静态资源的地址。其中 pathname 就是用户访问的 URL 中的路径，我们发现代码中只是简单的解码之后就在22行将其与资源目录做了拼接，这就是非常明显的目录遍历漏洞了。
开篇之前先介绍一下场景。信息流是一个基于用户兴趣使用算法将用户感兴趣的新闻内容推荐给用户的一种业务。这种业务带有非常特色的场景就是用户有一个“永远”都刷不完的推荐流列表，点击列表中的新闻之后可以跳转到其详情页中查看新闻的正文内容。列表一般都是由客户端原生去实现的，而详情页这块由于新闻内容结构的复杂性，一般还是会使用 h5 来实现。这样就对我们 h5 的性能提出了要求，我们必须在用户切换的时候将切换的白屏时间尽量减少，这样才能提高用户的阅读体验。
本文就将为大家讲述一下我们是如何实现性能优化达到“闪开”的效果的。我们可以先看看效果，下图左边是正常版本，而右边的是优化后的版本。对比之下可以发现即使我已经悄咪咪的先点击左边的手机，同一篇新闻右边的打开速度明显比左边的要快很多。接下来就让我们看看这个是如何做到的吧！