上次我们在 Canvas 实现根据背景色更改前景色中使用了一个拖动效果，刚开始非常智障的用 Drag & Drop，后来由于我们更关注一个即时的反馈，所以用 mousedown / mousemove / mouseup。

最初我们绑定 mousemove 在待拖动的 element 中，结果在移动中如果速度过快，会导致 mousemove 离开 element，于是我们把 mousemove 改绑到 document 中。

这样的效果其实仍然有些卡，或者说移动的延迟，尽管最终会到达鼠标所在的位置，高速移动时却不时刻在鼠标下面。之后我们用捕获来代替默认 addEventListener 的冒泡阶段触发：

之后，如果需要在移动时取消所有鼠标的响应时间，可以通过调整 pointer-events 样式来修改，在变更拖动状态时修改 body 的 style 即可。

- 阅读剩余部分 -

自从正式使用了 MongoDB 之后，不止一次吐槽过 MongoDB 的各种垃圾设定，包括但不仅限于：

• 没有事务
• 没有表连接（新版支持了，但估摸着性能堪忧）

也就是说，同样的操作，在 SQL 下通过 JOIN 控制原子性的，通过 MongoDB 可能就不得不去查个两次，而且原子性不可保证——MongoDB 官方也是非常实诚，人家在选型的时候就说了，如果贵系统对并发性（Concurrency）有强要求，那么 MongoDB 可能就不是你的菜了。

- 阅读剩余部分 -

在 Chrome 插件的开发中，我们遇到了需要定时提醒的功能，Chrome 官方推荐的 Alarms + 事件页面的做法，之前我也发过：Chrome 插件开发：Alarms 定时与事件页面，起到了计划任务的效果，但是后来我们发现了一个奇怪的问题：计划任务有时执行，有时不执行，有时会延迟执行，而且延迟可以多达几个小时。

这个 bug 很奇怪，最初收到反馈是最近一个星期，我以为是最新更新了什么代码，结果看了一下 Git Log 并没有改动这一段代码，也没有增加其他 Chrome 提供的 API 的调用，理论上是不受影响的。

- 阅读剩余部分 -

上回我们实现了 background 的效果，但是我们的代码只能达到一个填充缩放的效果，在不同的窗口大小，会导致图片的变形。如果是 background:cover 的效果则相当理想，它相当于需要我们把大的那一边居中对齐。

这里我们用到了使用图像 Using images 中的切片示例，简单的展示了如何处理：

drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight)

sx / sy / sWidth / sHeight 是对原图的操作，对于切下来的图片，dx / dy / dWidth / dHeight 是切好的图像对于画布的相对操作。

- 阅读剩余部分 -

上一回我们说到用 Canvas 去渲染图像，但是在高分屏中，我们会发现，同样的大小，在高分屏上显示的并不清晰，这个 demo 表示的非常清楚：https://jsfiddle.net/csvwolf/3gvs44vw/

为什么会这样

实际上我们在屏幕中看到的都是逻辑像素，但对于设备中元素的实际像素，是逻辑像素 * 设备像素比
，也可以叫做物理像素。

实际上在 Canvas 绘制时，也需要绘制实际像素，再进行画布的缩放。

解决方案

在 demo 中已经有了方案，先绘制逻辑像素 * 设备像素比大小的画布，用 CSS 把样式大小调整，这样实际上是把 canvas 像素点压缩到指定尺寸，但是这样字会变小，我们还需要利用缩放放大设备像素比倍的尺寸，让尺寸恢复正常。

这样一个支持高分屏的渲染就做完了。

接下来我们考虑，如果我们支持完高分屏，图片像素的坐标要怎么选定：答案是要扩大像素比倍进行选择，因为画布的像素点总数没有变化。

很惭愧，一点微小的实践经验，时间有限，就说这么多。

参考

• High DPI Canvas 高分辨率Canvas（译）

最近有一个需求，大致是要根据图片的背景色来切换前景色，也就是根据 background-color 的色值切换 color。

虽然这么一说，那么就能抽象出以下几个问题：

1. 如何取到图片某像素的 color 值，或者是某像素区域的平均 color 值
2. 如何根据 color 划分、如何改变前景的（如 icon、font）color。

- 阅读剩余部分 -

Swagger 是一个完整的从设计到文档到 Mock 的 API 生态体系。

它会帮助你进行一定的设计，对于不符合的设计会报错，你需要掌握它的 yaml 文件书写规范，可以通过 OpenAPI Specification 稍作了解。

最初写文档可能会因为 yaml 语法不熟报一堆 error，习惯之后基本上也没啥问题，这样可以摒弃一些不规范的文档带来的沟通成本。

当然，今天就不介绍这一部分的信息了，在http://editor.swagger.io/#/会存在默认的示例。

- 阅读剩余部分 -

昨天整了一天的 SSR，卒，总结一些经验教训仅供参考。

为什么又双叒叕要用 Server Side Render

这就要说到天下合久必分，分久必合的道理了——最初的时候，静态页面就是静态页面，前后端 MVC，服务端渲染出页面；之后，前后端分离，后端提供 API，由客户端渲染页面；最后，我们又回到了最初的起点，不过是前后端分离后再由后端多渲染一次。

这样做的优点当然有很多啦，比如说我们要照顾爬虫（不），照顾蜘蛛，Vue 官方文档写的几点都已经很清楚了：

- 阅读剩余部分 -

目前前后端对接其实主要是面向 API 文档开发，而 API 的设计中，有一种 RESTful API 的设计，具有规范，从某一种角度，我觉得 RESTful API 可以很好的把后端 API 从繁杂的业务中抽象出来，更好地进行管理和编写，同时也具有良好的可读性。

对于一些现代化的 MVC 框架，在脚手架阶段可能就会自动生成 RESTful 风格的 Controller。

资源的拆分

路由中 URI 中的资源都是名词，即一个个实体，对于代码而言，可以看做一个个类到 URI 的映射，比如：

- 阅读剩余部分 -

Chrome 插件本身也提供了计划任务，使用起来也非常简单，我们主要顺着思路来解释一下事件页面的概念。

在使用之前，我们需要清楚，alarms 的 create 只包含了定时器名和一些定时器需要的相关信息，而具体执行什么，则是由 onAlarm 监听决定的，由 alarm 参数的信息来决定执行内容：

- 阅读剩余部分 -