标题来自：为美好的世界献上祝福

近期在使用一个无需构建即可运行的前端框架，runtime 一时爽，但是怎么样快速查看自己的变更是否有效却是一个很大的问题——

想象一下这样的场景：

- 阅读剩余部分 -

其实无论前端还是后端，在非常多场景下你都会遇到类似于这样的一个实现：

假定最大值为 100% 高度，我们怎么样把值映射成一个图表的形式，从数学的角度来说，我们很容易想到，这就是把 [a, b] 映射到 [0, 1] 的过程。当然，a 不一定是 0，有可能是 [0.2, 1]，这是由具体需求来决定的，方法都一样。

先从简单的数学题开始吧，我们经常会使用 Math.random() 得到一个 [0, 1) 的值，然后扩大 x 倍，取整，得到了 [0, x) 的值，最后加上 offset，就得到了 [a, x + a) 的值。

- 阅读剩余部分 -

说起 Lint tools，其实不如说是 Vue 的 Lint tools 推荐，在过去我对 Vue.js 的 Lint 感受的不够深刻，由于 Vue.js 是由 .vue 的后缀名组成的 template file，那样 Lint 其实是不好做的，但是万万没想到，这年头 Lint 工具超发达的，什么都有——

eslint

lint 界元老，也是最基本的一个 lint 工具，即使别的你什么都不配，相信你也至少会使用 eslint 来管理你的项目。

- 阅读剩余部分 -

我们在项目里用到了 MQ，但是之前我们发现了很多 MQ 的问题：比如消费者挂了，消费内容堆积，消费者重复循环死亡等情况，之前我对于 MQ 一无所知，这些问题都无法回答——我们的代码看上去很标准，也很简单，似乎没有什么问题。但是实际上从开发时就是由一群对 MQ 没有概念的人进行的，因此才出现了这么多问题。

公司的 MQ 是单独定制的，基于 AMQP 0-9-1 去开发的，而实际在使用过程中，其实就是一个 RabbitMQ 的封装版，因此还是以 Rabbit MQ 为主来讲下学习的内容。

- 阅读剩余部分 -

Boom！

昨天下午 15:00，我们发现了 CI 的大规模异常，基本上就是 connection failed 和 Could not resolve host 的连环轰炸。

在查找问题之前，先来看看从我们伪 DevOps 能治理的角度出发可能是什么问题，一个运行中的 CI 任务到底是跑在哪里的：

在我们这里，CI 机器是有一个独立网段的，部署一个 CI 需要若干台机器，由 Master 负责调度给 Slave，Slave 在机器上创建新的 Docker 容器运行任务。

- 阅读剩余部分 -

本文目标人群：自己，请勿期待

之前在 NAS 里搭建了一整套 dev 环境（大概），但是由于希捷两块硬盘双双 GG，我实在没有办法——所以就寄回去换了硬盘，顺便跟老板说换成西数的吧，没想到真的帮我换了，加上在京东买的西数金盘和东芝的企业盘，换了老价钱换上了 RAID 10. 再把内存加到了 8G，完全体建立完毕。

- 阅读剩余部分 -

一般来说，我这里的基础设施得益于 CDN、OSS 和网关层，到了这里都不用扛太多的流量，只要写的不怎么车祸，后端都不存在什么性能瓶颈。

但是这次要上一个灰度功能，需要和业务相结合，在此之前我们的灰度都是以 DNS 为标准进行地区式的灰度，但是现在流量必须要直接打到后端才能判断，如果前面缓存了就没办法灰度了——因此没办法，我们只能船到桥头自然直——扛吧。

先来简单描述一下我们的代码逻辑：查询 1 -> 处理逻辑 -> 查询 2 -> 查询 3 -> 处理逻辑 -> 灰度判断 -> 返回。

最初保持了最原始的代码，没有设置任何缓存，这在过去是满足需求的，因为缓存是由网关层的反向代理帮我们在 Header 里加上的，包括了 s-max-age 和 max-age。

- 阅读剩余部分 -

今天在公司看到了一个同事的演讲总结，觉得其实自己也应该总结一下。

目前自己参加过四次演讲，一共是：

1. Node Party 2017 - 女程序员的自我修养
2. Coding 技术小馆 - 女程序员与开源程序
3. FreeCodeCamp Shanghai 2018 - 闲话 CDN
4. 2018 计算机大会前端分会场 - 字符级静态资源增量更新实践

- 阅读剩余部分 -

之前经常有用户反馈我们做的系统中，在上传过程中会遇到 Request body larger than maxBodyLength limit，其实这个问题之前已经存在了很久，但是一直没去动。

最初以为是服务端发出的 error，因为默认使用的 koa-body 在旧版本也有上传内容的大小限制，但是后来调试过程中发现请求根本没发出去——

- 阅读剩余部分 -

今天同事向我反馈，当我们的静态资源有中文名混杂 + 和空格 时，得到的链接并不能打开，返回的是 404.

举个例子，假定我们的资源为：

http://example-resource.oss-cn-shanghai.aliyuncs.com/23232323/中文 + 文件-file.ec296f20-d67b-11e8-a623-7b28809dc3c9.js

那么在浏览器中访问的文件名应该被转义为：

%E4%B8%AD%E6%96%87%20+%20%E6%96%87%E4%BB%B6-file.ec296f20-d67b-11e8-a623-7b28809dc3c9.js

注意，在这里，空格被转义为 %20，而 + 没有进行任何处理。

- 阅读剩余部分 -