AST 基础学习以及躲坑技巧

AST 的全称是抽象语法树,名字也很抽象,给个容易理解的例子。

上面这个例子,是一个简单的常量定义。

当浏览器不支持 const 这种语法的时候,我们需要把他换成支持的 var,这个时候,AST 就上场了。

这里面,每一个包含 type 的层次结构,都叫一个节点(Node)。

这里我们关注的 const 就在一个 VariableDeclaration 的节点上面,开始位置为 0。

一个个 Node 节点,组成了一份描述我们代码的树状结构,也就是 AST。 继续阅读“AST 基础学习以及躲坑技巧”

捉到 Edge 的渲染 BUG 一只

最近测试同学发现,用 Edge 浏览器,访问问卷的新版设置界面,部分联动锁总是显示异常,该锁的没锁,不该锁的又锁上了。

期初以为是 React 在 Edge 里面有什么 bug,一圈排查下来,发现状态、样式都是正确的,偏偏就是显示出来的很诡异,鼠标在上面晃动一下又正常了(浏览器绘制BUG,以前 IE7 也遇到过)。

这个 BUG 的特征,当使用 :disabled ~ label 这种伪类 + 相邻元素进行样式定义的时候,如果动态修改 input.disabled 的值,其对应的 label 的表现就不会更新。

Demo

继续阅读“捉到 Edge 的渲染 BUG 一只”

React Key 在非数组、队列场景下的应用

猜猜这段代码会发生什么事?

以为仅仅是切换下按钮?

其实是会执行下面的流程

  1. isEditingfalse 的时候,点击 button
  2. isEditing 变成了 true
  3. 重新 render,在 virtualDOM 进行 diff 的时候,给 button 添加了 type=submit 以及 form='form-1'
  4. #form-1 表单被意外的 submit 了

来个 DEMO 验证下 继续阅读“React Key 在非数组、队列场景下的应用”

基于 styled-components 实现一套皮肤系统

结构定义

styled-components 使用模版字符串特性,让我们可以保持原有 CSS 的书写习惯来编写 CSS,同时,利用 ${ props => props.theme.xxx } 的方式,实现皮肤系统中挖空填值的能力。

继续阅读“基于 styled-components 实现一套皮肤系统”

利用 Promise 实现任务流的自动重试

背景

微信小程序不支持 HTTP 的 cookie ,其会话机制是通过开发自己维护一个 session_id 在小程序的本地存储中,每次调用 wx.request 的时候都带上这个 session_id 来实现的会话机制。

那么,有会话机制,就会存在会话失效、更新等等问题。

传统的 HTTP cookie-session 机制,当会话失效的时候,可以在 HTTP 的返回头里面通过 setcookie 来静默返回一个新的 session_id ,小程序就比较麻烦。

传统的实现方案

1.理想的实现情况

2.为了容错,我们会添加返回判断,但错误的时候,再调用一次

上面这种方式,在接口的返回值中做一次判断,然后再执行一次,好像就解决问题了。

但如果我们业务的接口非常多,返回判断是不是要添加很多次呢?

继续阅读“利用 Promise 实现任务流的自动重试”

await 性能猜想

前言

以往我们推崇异步 I/O 来实现高并发下的高性能,如今 NodeJS 步入 8.x 时代,async await 可以用同步的写法来实现异步处理,不知道对性能是否会有影响,来做个简单的测试。

测试基准

Linode 1G 配置两台,一台用 ab 发请求,另一台跑4个测试用例。

先用 Nginx 跑一个默认服务,返回一个 html 文件,测试基准性能。

Nginx 访问默认的 html 文件,QPS 为 5162

同步访问文件

fs.readFileSync 是 fs.readFile 的同步版本

测试结果

QPS 为 3195

异步访问文件

测试结果

QPS 为 2945

使用 async 来封装异步操作

测试结果

QPS 为 2855

对比

  • 5162 Nginx
    • -1967
  • 3195 fs.readFileSync
    • -250
  • 2945 fs.readFile
    • -90
  • 2855 await promise fs.readFile

本来猜测的结果,应该是 Nginx >  fs.readFile > fs.readFIleSync > await + promise + fs.readFile

实际结果却是 Nginx > fs.readFileSync > fs.readFile > await + promise + fs.readFile,这下傻眼

 

Linux Kernel 4.9 & BBR

Google 真是共享了个好东西,先来看看效果。

Kernel 4.9

Linode 自带的 Kernel 4.9 没有编译 BBR 模块进来,直接切换是不行的,得手动替换 Kernel。

虽然 Ubuntu 官网的 Kernel 还没升级到4.9,但是他们官方的 ppa 已经支持4.9了,可以手动下载一个回来安装。

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/

根据自己的32位或者64位环境,wget 个新的 linux-imag-4.9下来

安装好之后,去 linode 后台,把 [Boot Settings] 中的的 [Kernel] 改成 [GRUB 2] ,这样 Linode 的 vps 重启后,就会使用我们刚刚安装的内核了。

BBR

网上开启 BBR 的方式,都是 echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf  这种暴力又不美观的方式,我是不喜欢。

仔细看了下,发现一个 /etc/sysctl.d/ 的目录,里面还有一个 README

这是一个带权重的配置目录,新的 php-fpm 目录下面也是通过这种方式来维护模块配置的。

这里面补一个 60-bbr.conf ,把开启 BBR 的规则放在这个 60-bbr.conf 里面就 ok 了。

根据 README ,执行 service procps start 就能看到效果。

More

在 /etc/sysctl.d/目录下还无意发现一个 10-network-security.conf,里面默认开启了 tcp_syncookies 来防范常见的 SYN-flood 类型的 DDoS。

JavaScript Cookbook 2nd 之 Function

昨晚翻了一下,虽然都是一些旧知识,不过深入下去对照着其他资料一起看,还是能发现一些有意思的地方。

函数式编程

反正之前我是没搞懂函数式和命令式的区别,也很疑惑函数式编程中,如果出现分支怎么办,昨晚总算弄明白了。

传统的命令式编程,我们会这样写业务逻辑

而函数式编程,我们则可以这样写业务逻辑。

这里可能会有一个疑惑,互斥的 processA 和 processB 怎么进入了同一个处理流程,这样和需求就不符合了?

在这种情况下,我们还需要在 processA 和 processB 的内部,把退出条件补上。

调用栈

JS 在执行的时候,有一个函数调用栈,栈里面放着一个个的函数调用帧,这些帧保存着所属函数所需的所有变量信息。

函数调用会在内存形成一个“调用记录”,又称“调用帧”(call frame),保存调用位置和内部变量等信息。如果在函数A的内部调用函数B,那么在A的调用帧上方,还会形成一个B的调用帧。等到B运行结束,将结果返回到A,B的调用帧才会消失。如果函数B内部还调用函数C,那就还有一个C的调用帧,以此类推。所有的调用帧,就形成一个“调用栈”(call stack)。

浏览器拦截 window.open

我们发现有时候执行 window.open(),能正常打开新窗口或者新的标签页,而有时却又不行,会被浏览器拦截。

其原因是浏览器会根据当前调用栈,找到最初的caller,如果不是用户触发的,则拦截。

尾调用优化

由于函数调用的时候会生成新的调用帧,当递归调用的时候,调用栈中的调用帧增长会非常厉害,最终导致内存耗尽而触发 RangeError。

如果把函数调用放在函数块的最后一条语句,且不在使用外层函数的变量了,则外层函数所占用的调用帧已无存在意义。在进入内层函数的时候,可以直接用内层函数的调用帧替换掉外层函数的调用帧,从而大大减少内存占用。

其他

Partial Application 的模式,用来做 Library 和 SDK 都挺好的。一个可定制性高的底层接口,再通过类似 _.partial() 的方式,提供一个开箱即用的上层接口。就像 $.ajax()$.get() 一样。

_.defer()_.memoize() 可以用在有大运算量的业务场景。

git cherry-pick

QQ20160707-1

有一个 hotfix分支,merge 到 master 后,忘了 merge 回 develop就被删掉了,咋办

这个时候可以祭出 git 的 cherry-pick 功能,将某个分支上面指定的几条 commit,提交到另外一条分支上

QQ20160707-2

恩,本来有用 git-flow 脚本的,但是遇到过几次命令执行失败后,还是老老实实自己去切分支 merge 了

ckeditor 从入门到放弃

真心复杂

有一个 CKEDITOR 的全局空间,

有一个 CKEDITOR.instances的全局实例引用

有 Classic 编辑和 Inline 编辑两种模式

有 Plugin 也有 Widget

有自成一体的编译打包工具,与 AMD\CMD\UMD社区不兼容

官方兼容性

  • Desktop environments:Internet Explorer:
    • 8.0 and 9.0 – close to full support,
    • 10 and 11 – full support,
    • 9.0 Quirks Mode and 9.0 Compatibility Mode – limited support.
    • Firefox, Chrome, Safari, Microsoft Edge, Opera (Latest stable release) – full support.
  • Mobile environments:
    • Safari (iOS 6+) – close to full support,
    • Chrome (Android) – close to full support,
    • Internet Explorer Mobile (Windows Phone 8.1+) – support under evaluation.

继续阅读“ckeditor 从入门到放弃”