Angular 还在发展着. https://angular.io/

记得以前饿了么是用 Angular 的. 现在不知道了.

在 Twitter 上看到这样一则笑话: https://twitter.com/markdalgleish/status/1247110984969273344

呀, 大概一看, TypeScript 的代码, 挺好的, 仔细看, 噢, 原来是 Angular.

想起来之前也用过 Vue 的, 当时还不到 1.0, 现在听说就要出 3.0 了. https://github.com/vuejs/rfcs/labels/3.x

想当年 jQuery 风光一时无两.

别人眼中的历史, 我心中的回忆啊.

https://www.kuaikanmanhua.com/web/topic/5904/

不只是 IT 行业, 任何涉及到甲乙方的专业服务行业都会有提需求该需求.

最近看到 PHP 核心开发成员 Laruence 在微博聊语言喷子. 我是非常赞同他的基本观点的, 语言只是解决问题的具体实施细则, 更重要的不是语言本身, 而是解决问题的抽象方法.

下面这则 2019 年的排行还是可以看出 PHP 仍在一阵.

https://redmonk.com/sogrady/2019/07/18/language-rankings-6-19/

参考两个社交媒体:

• GitHub
• Stack Overflow

X 轴的 GitHub 可以代表开源流行度.
Y 轴的 Stack Overflow 可以代表新人活跃度.

x + y 为总流行度, x > y 是更硬核的语言, x < y 是更大众的语言.

可以看出 Rust 开源流行但新人问题少. (相对)
Visual Basic 新人问题多但开源不够流行. (相对)

让大家做个狗语翻译器吧, 做出来之后就趁这个机会讲讲什么是编码.

微信小程序码与二维码的区别

不喜欢小程序码这种非标的东西, 但是其存在是有一定合理性的. 比如二维码缺少可以放 LOGO 的地方.

虽然二维码有一定容错性, 可以在其中插入图片, 但是容错性带来复杂度, 复杂度带来更大的图片与更清晰的图片质量要求.

我想这就是小程序码要解决的问题:

1. 放入图片.
2. 更低图片复杂度.

如何生成带参数的小程序码

官方文档: https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/qr-code.html

通过微信生成小程序码分两种:

1. path 中携带参数. 数量限制 十万. https://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/qr-code/wxacode.get.html
2. 通过特定位置带参数. 暂无数量限制. https://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/qr-code/wxacode.getUnlimited.html

Node.js 生态中的流行包 request 正式被弃用

在 2019 年 3 月份, 作者就创建了相关 issue 讨论逐步让 request 进入历史.

最近, 作者正式宣布弃用该包.

关于弃用的原因, 主要是历史比较久远, 核心代码已经跟不上 Node.js 的发展.

我倾向标准库强大的语言. Go 从设计之初就拥有强大的标准库, Node.js 则是随着
ECMAScript 的进步, 逐渐通过语法来完善与丰富自己.

替代

关于 request 的替代品可以参考这个 issue.

经验

其实我们并没有使用过 request, 在 Node.js 中只是用 node-fetch 和 axios.

在最初进入 Node.js 的时候, 我们关注到了 request, 但语法并没有打动我们,
所以我们转向了 node-fetch.

因为我们同时会写前后端, 在前端标准化的 fetch 让我们能尽快入手.
但正是由于我们前后端同时在写, 我们发现 node-fetch 的语法并不完全等同 fetch.
这让我们更容易因为忽略了差异项而出错.

之后我们再次寻找替代品, 发现了 r2. r2 代码的体积很小, 我们就看看源代码,
发现只是简单调用了 node-fetch.

在最近的项目中, 我们才开始用当时还流行的 axios.

我不太喜欢 axios 的语法, 有些过度了. 但基于流行原则我们还是在继续使用.

现在来看, request 作者的新包 bent 才是我们在 Node.js 中更应该做的选择.

bent

bent 是一个同时支持浏览器与 Node.js 的 HTTP client.

在 Node.js 环境中, 进行了 Promise 化和流的支持.

在浏览器端, 对 fetch 进行了简单封装以符合 bent 的 API.

源代码很小, 依赖也不多. API 简洁实用. 是我们理想的选择.

但在浏览器端, bent 的封装对我们帮助不大, 我们还是会选择 fetch 然后自己封装.

关于使用 PostgreSQL 的 ENUM 类型

数据库版本 v9.6

数据库中枚举值的作用

1. 约束数据.
2. 更加语义化.

在数据库中使用枚举值只是在数据层面确保数据正确的做法, 不能替代程序中的逻辑.

程序中应该做足够的判断, 尽量确保数据库中不会出现因枚举值不匹配导致的问题.

关于枚举值的使用

例如:

CREATE TYPE abc AS ENUM ('a', 'b', 'c');

虽然在向数据库中写数据时, 我们是将 'a' 写入到数据库中, 但实际数据库储存的是
abc[1] 这样的数据.

关于枚举值的查询

如何查询目前数据库中已经有的枚举值是哪些.

可以参考 Stack Overflow 上的回答, 效率还是比较高的, 基本 10ms 以内.

SELECT
  n.nspname AS enum_schema,
  t.typname AS enum_name,
  t.oid AS enum_id,
  e.enumlabel AS enum_value
FROM
  pg_type t
  JOIN pg_enum e ON t.oid = e.enumtypid
  JOIN pg_catalog.pg_namespace n ON n.oid = t.typnamespace
ORDER BY
  enum_name,
  e.enumsortorder;

关于枚举值的修改

1. 支持添加新值.
2. 支持修改原值.
3. 不支持删除原值.

虽然文档说支持向后添加新值, 但实际可以加在任何地方.

虽然文档写不支持修改排序, 但可以通过修改 enumsortorder 来完成重排序. 并且排序
支持浮点数, 比如当执行 ALTER TYPE abc ADD VALUE a- BEFORE b 时,
会将新插入值的排序改为浮点数, 如 1.5.

关于如何修改枚举值, 直接 UPDATE pg_enum 就可以了.

能否直接修改原值的排序呢? 实测是没问题的, 不会影响表中使用到该类型的数据.

虽然 ESLint 可以单独使用, 但如果能结合编辑器, 提前给出一些提示就更好了.

微信开发者工具 是基于 VS Code 的, 所以 VS Code 的扩展应该也可以在微信开发者工具上使用.

以 ESLint 为例, 其他扩展应该也是一样的.

不过这些扩展如何设置我还没找到方法.

1. 下载最新 RC 版本的微信开发者工具.
2. 使用 VS Code 安装 ESLint 插件: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint
3. 将 ESLint 插件复制到微信开发者工具的扩展目录下.
4. 配置微信开发者工具的扩展, 将 dbaeumer.vscode-eslint 加入其中.
5. 清除 微信开发者工具 编辑器缓存.
6. 本地 npm 全局安装 ESLint. (可以提前做)
7. 将 ESLint 配置文件放在项目根目录下. (可以提前做)

Q: VS Code 的插件安装在哪儿?

A: 参考 https://code.visualstudio.com/docs/editor/extension-gallery#_where-are-extensions-installed, 比如 macOS 是在 ~/.vscode/extensions.

Q: 微信开发者工具的扩展目录在哪儿?

A: 微信开发者工具 => 编辑 => 打开编辑器扩展目录.

Q: 如何 配置微信开发者工具的扩展?

A: 微信开发者工具 => 编辑 => 管理编辑器扩展. 文件是一个数组.

Q: 如何清除 微信开发者工具 编辑器缓存?

A: 微信开发者工具 => 编辑 => 清除编辑器缓存.

在css中单位长度用的最多的是px、em、rem，这三个的区别是：

　　px是固定的像素，一旦设置了就无法因为适应页面大小而改变。

　　em和rem相对于px更具有灵活性，他们是相对长度单位，意思是长度不是定死了的，更适用于响应式布局。
对于em和rem的区别一句话概括：em相对于父元素，rem相对于根元素
rem中的r意思是root（根），这也就不难理解了

em

• 子元素字体大小的em是相对于父元素字体大小

• 元素的width/height/padding/margin用em的话是相对于该元素的font-size

<div>
    我是父元素div
    <p>
        我是子元素p
        <span>我是孙元素span</span>
    </p>
</div>

div {
  font-size: 40px;
  width: 10em; /* 400px */
  height: 10em; /* 400px */
  border: solid 1px black;
}
p {
  font-size: 0.5em; /* 20px */ 
  width: 10em; /* 200px */
  height: 10em; /* 200px */
  border: solid 1px red;
}
span {
    font-size: 0.5em; /* chrome有最小字体12px的限制所以这里为 12px */
    width: 10em; /* 120px */
    height: 10em; /* 120px */
} 

rem

rem是全部的长度都相对于根元素，根元素是谁？元素。通常做法是给html元素设置一个字体大小，然后其他元素的长度单位就为rem。

html {
    font-size: 10px;
}
div {
    font-size: 4rem; /* 40px */
    width: 30rem;  /* 300px */
    height: 30rem;  /* 300px */
    border: solid 1px black;
}
p {
    font-size: 2rem; /* 20px */
    width: 15rem; /* 150px */
    height: 15rem; /* 150px */
}
span {
    font-size: 1.5rem; /* 15px */
    width: 10rem; /* 100px */
    height: 10rem; /* 100px */
} 

目前有三部分:

https://v8.dev/blog/understanding-ecmascript-part-1

https://v8.dev/blog/understanding-ecmascript-part-2

https://v8.dev/blog/understanding-ecmascript-part-3

语言规范不是每个人都需要阅读的, 但理解规范可以让我们深入理解这门语言.

司徒正美, 健康

概要

网传, 司徒正美离世, 可能因为颈椎病, 但具体情况不明.

因为想以 React 语法开发微信小程序, 了解过 anu 和 nanachi.

纪念一下他, 也提醒大家关注常见疾病颈椎病, 关注自身健康.

司徒正美其人

网名: 司徒正美 / RubyLouvre

钟钦成

从业多年, 出过书, 以前在去哪儿, 现在应该已经从 qunar.com 离职,
应该是业内一位人物.

主要在国内的社群活动, 比如博客在 cnblogs. 在知乎也有一些回答.
也活跃在 GitHub. 有 Twitter, 但不怎么用.

一位坚持写博客 10 年的人, 值得敬佩.

工作经历可以在 LinkedIn 看到. 2013 年来北京, 在去哪儿工作多年.

最近在刷题, 可能是疫情原因, 也可能是离职后有时间了.

颈椎病

首先, 推荐大家看默沙东关于颈椎病的介绍.

其次, 默沙东有一篇文章谈到了对任何疾病的预防手段.

简单列举一下就是:

• 系好安全带
• 饮食健康 (低热量, 低饱和脂肪, 低反式脂肪酸)
• 身体锻炼 (规律, 足量)
• 涂防晒霜
• 不抽烟
• 免疫接种
• 定期体检

希望大家健康.

需求历史

在 2018 年 8 月份, 我们曾提交工单询问阿里云, 能否提供 POST 方法的日志提交, 因为在大体积日志的情况下, 会出现 414 URL 过长错误.

当时得到的回复如下:

现在已经是 2020 年了, 我们尝试再次寻找解决方法, 发现了现在已经提供 POST 日志功能. 接口名为: PutWebtracking. 请求格式为 JSON string, 需要计算请求 body 的体积, 然后放在请求头中.

PutWebtracking 的相关文档: https://help.aliyun.com/document_detail/120218.html

请求头

请求需要两个头, 分别是:

• x-log-apiversion: 0.6.0
• x-log-bodyrawsize: {byteLength}

还有一个请求头是 x-log-compresstype. 一般, HTTP 请求体是不需要 gzip 压缩的. 如果请求体很大, 也是有意义的. 但一般浏览器难以实现.

在阿里云官网 https://help.aliyun.com/document_detail/29010.html 公共请求头介绍中, x-log-bodyrawsize 的描述中有 "该字段为非必选字段，只在压缩时需要". 但 PutWebtracking 文档中却说必填.

关于在浏览器中获取字符串的字节长度

有一些如 TextEncode 的方法在现代浏览器中可用, 但另外一些环境, 如微信小程序, 不支持. 这是可以参考编码规则来确定长度: https://stackoverflow.com/a/23329386/4124389

里面涉及到一些方法, 在 Node.js 中, 使用: Buffer.byteLength(str).

在其他 JS 环境中, 使用:

function byteLength(str) {
  // returns the byte length of an utf8 string
  var s = str.length;
  for (var i=str.length-1; i>=0; i--) {
    var code = str.charCodeAt(i);
    if (code > 0x7f && code <= 0x7ff) s++;
    else if (code > 0x7ff && code <= 0xffff) s+=2;
    if (code >= 0xDC00 && code <= 0xDFFF) i--; //trail surrogate
  }
  return s;
}

https://codepen.io/iugo/pen/yLyYpwb

https://gist.github.com/iugo/2b25a589a1c4d9fb7440921a925f2456

从物理层面了解数据传输

知识点

OSI七层模型

OSI七层模型（从上至下）分为：应用层，表示层，会话层，传输层，网络层，数据链路层， 物理层
其中上三层（应用层，表示层，会话层）统称为应用层，在这里不做考虑。

网络层

网络层通过ip进行寻址，在这一层的网络设备主要以路由器为主。
路由器的特点是用来连接不同的网络。

数据链路层

数据链路层主要通过mac进行寻址，这一层的网络设备主要以交换机（二层交换机）为主。
交换机的特点是所有连接交换机的主机都必须处在同一个网段中。

交换机与路由器的区别

交换机的接口较多，路由器的接口较少。（一般情况下）路由器的每个接口都代表一个不同的网段，交换机的每接口必须处在同一个网段中。

ARP协议

ARP协议属于网络层协议，将网络地址（ip地址)解析为硬件地址（mac地址）。
当局域网（192.168.1.0网段）内的两台主机A、B进行通信时且A只知道B的网络地址不知道B的硬件地址的情况下A如何将数据发送给B。
A先查找自身的ARP缓存列表，查找B无果。会向192.168.1.255（网络地址）发送一条携带目标ip地址的ARP广播请求并设定一个过期时间，
该网段内的所有主机会收到该条广播，并且跟自身ip地址进行对比，如果该条广播的目标ip地址与自身的ip地址不相符则将这条请求抛弃，
如果相符则响应这条广播。主机A在超时时间之内收到响应，则将主机B的硬件地址和缓存地址保存在自己的ARP缓存列表中以备下次进行数据传输。
如果超过过期时间任然没有接收到响应，则判定主机B不在当前局域网内。

数据封装

这里主要介绍网络层和数据链路层的封装。
网络层对传输层的数据报进行封装，封装成为数据包，包的头部保存ip地址等信息。
数据链路层对网络层的数据包进行封装，封装成为数据帧，帧的头部保存mac地址等信息。
路由器属于三层设备，只检查数据包的头部信息。
（二层）交换机数据二层设备，只检查帧的头部信息。

ip地址为192.168.1.2的主机A要给ip地址为10.0.0.212的主机B发送一条消息数据怎样传输的。

主机A将数据层层封装为数据帧发送出去，由于目标ip不在当前网段，主机A会将数据帧直接发送给网关。路由器在接收到数据以后就将数据帧解封到三层的数据包，
并查询自身的路由表将数据分组转发到对应的接口，目标数据发送到目标局域网，进行查找目标主机（通过arp协议进行辅助查找），目标数据在封装成帧发送给主机B。

先是无意中发现了 https://oi-wiki.org/, 然后又发现了 https://ctf-wiki.github.io/ctf-wiki/.

两个站点主要介绍一些基础, 通用的知识.

其中, OI Wiki 的数学章节和 CTF Wiki 的 Crypto 章节都还挺好看的.

关于加密, 我还想说两个对我有帮助的:

对称加密: https://shadowsocks.org/en/spec/AEAD-Ciphers.html
非对称加密: 整数分解 RSA, 离散对数 EdDSA

Postman
https://postwoman.io/
https://insomnia.rest/

Insomnia 的特色就是读写分离, 前后台分离, 写 API 的应用和用 API 的应用分开.

1. 使用 react-scripts 创建 React 单页应用.
2. 使用 react-router-dom 5 作为路由.
3. 使用 Aliyun OSS.
4. 使用 Aliyun (D)CDN.
5. 配置 OSS 镜像回源, 或在 CDN 中配置 Rewrite 重写.
6. 使用 ossutil 自动发版.

网上查不到太多有效信息, 自己翻找 Aliyun 后台设置. 可能比较简单, 或者没什么人用吧.

Eclipse Theia

项目: https://github.com/eclipse-theia/theia

说到前后分离可以运行在远端的编辑器甚至工作台, 我第一个想到的就是 VS Code.

如果你在用远程工作台, 不要认为这一定是 VS Code, 即便 UI 看上去很像. 因为这也有可能是: Theia.

Theia 是一个开源项目, 而不是开箱即用的编辑器. 想要试试看可以通过 Gitpod.

Eclipse Theia 与 VS Code 的区别

Theia 官网说, 自己与 VS Code 最大的不同有三点:

1. 更加模块化与可定制.
2. 转为桌面和远程设计.
3. 独立基金会.

不过, 从使用者角度看就一点:

1. VS Code 是开箱即用的工具.
2. Theia 是搭建自有编辑器的基础.

做普通用户, 我们在做远程开发的时候, 还是会选择 VS Code. 但很感谢 Theia 对开源社区的贡献, 我觉得正是有了 Theia 这样的项目, 才鞭策 VS Code 做得更好.

Remote Development

下面说一下如何结合远程服务器来使用 VS Code.

一般来说, 一定会有服务器端与客户端. VS Code 就是我们的客户端了. 那服务器端呢? 怎么安装?

我们无需特别地在服务器端安装什么, 这一些都会在 VS Code 这个客户端中帮我们自动设置好. 当然, SSH 还是需要的.

我们只需要在 VS Code 上安装 https://aka.ms/VSCodeRemoteExtensionPack 插件.

VS Code 这个插件通过 SSH 在服务器上自动安装了服务器端依赖.

前置步骤:

1. 本地安装 VS Code.
2. VS Code 安装 Remote Development 扩展.

步骤如下:

1. 打开 VS Code.
2. 左侧功能导航栏选择 Remote Explorer 图标.
   
3. 选择 SSH Targets.
   
4. 点加号创建一个 SSH.
   
5. 使用 SSH 登录到服务器, VS Code 会自动安装服务器需要的东西.
6. 结束, 就像本地一样使用远程机器进行开发吧.

道长在硅谷工作是怎样一种体验

概要

描述了故胤道长在 Uber, Amazon, Quora 的工作体验分享.

主人公是 CMU 毕业, 然后一路都是大厂经验, 主要从事 iOS 开发.

节目

来自播客 ggtalk 的一个系列节目.

讲工作经验的是其中一期. 也顺便讲了讲对行业, 职业规划, 生活的看法.

https://poddtoppen.se/podcast/1440443653/ggtalk/%E9%81%93%E9%95%BF%E4%B8%89%E5%8D%81%E5%9C%A8%E7%A1%85%E8%B0%B7%E5%B7%A5%E4%BD%9C%E6%98%AF%E6%80%8E%E6%A0%B7%E4%B8%80%E7%A7%8D%E4%BD%93%E9%AA%8C

主人公

故胤道长 soapyigu

GitHub soapyigu: https://github.com/soapyigu

微博: https://www.weibo.com/soapyigu

听的感受

• Uber (当时)是一家技术很激进的公司.
• Amazon (当时)的离职率很高, 许多新人.
• Quora (当时)是一家常青藤公司(戏谑).
• NETFLIX 一般不招实习生, 只招资深开发者.
• 选择工作时, 公司是一项重要参考, 同时具体的技术组和直接领导也很重要.
• 在美国不是只有湾区, Amazon, 微软总部都是在西雅图的.
• 在西雅图工作生活都挺舒适的.
• 美国大厂多数是现金 + 股票, NETFLIX 则全部是现金.
• 在美国如果想要更长远的职业发展, 要认真做事, 但同时也要会宣传自己.
• 作为软件工程师, 30 岁成为美国大厂 Senior 已经是很出色的了.
• 语言需要多听多讲, 但想要更进一步的沟通, 还需要了解当地的文化.
• 每一家公司都有自己的特点和生存之道, 无须苛责.

扩展阅读

访问 Quora 杨蕾: https://www.infoq.cn/article/9LhRWeXdYGh6mQQSiVZA

• 从 Google 离职加入 Quora.
• 带领 Quora 工程团队从 60 人增长为 120 人.
• 建立信任有助于团队接受批评和建议, 并进步.

什么是备稿

一般新闻都是时效性的, 但我们这里的 news 并不是严格意义上的新闻, 只是通过某些我们最近了解到的事件, 来学习一些知识或抒发一下想法.

因为团队每天分享一次, 如果一天内多人都有值得分享的内容, 可以提前记录一下, 方便下一次分享. 这就是备稿.

稿件格式

一篇稿件有三个组成部分:

1. 新闻出处.
2. 作者看法.
3. 评论.

其中, 前两者一定要有.

新闻出处可以是一个具体链接, 可以包含部分摘抄, 也可以是一则见闻, 或者最近工作中遇到的具体问题, 甚至是最近灵光乍现的某个想法. 如果为转载, 则必须给出链接, 如果没有没有链接, 则可以值给出出处或截图.

作者一定有看法, 可以融会到稿件内, 也可以在后面单独写. 但一定要有自己的看法.

评论为作者以外的其他人对作者稿件的看法, 可以匿名. 允许没有评论.

代码提交方式

团队内程序对仓库都有 Write 权限, 可以直接提交到仓库. 也可以开新分支进行 PR. 不必 fork.

如何使用关键词关闭 issues

重要的关键词主要有是三个: close, fix, resolve.

比如 Closes #10.

详细文档: https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

建议在 commit 中 close 相关 issue.

关于写目录

每次提交的时候记得修改 index.md 文件, 将链接放在目录中.

暂时还没有标签.

以前的笔记.

更新 API 相关知识

gRPC
GraphQL

与 RESTful 在一起讨论, 但它们却不是一个层面上的东西. 有点像 React 与 Angular 在一起讨论, 它们也不是一个层面的东西, 但都解决一类问题.

目前在我熟悉的领域, 前端与后端之间, 后端与后端之间都是可以使用 RESTful 进行沟通的.

gRPC 更偏向解决后端与后端沟通的问题.

GraphQL 更偏向解决前端与后端沟通的问题.

gRPC 是一种 RPC 框架.

GraphQL 是一种描述需求数据的语言.

https://leetcode.com/problems/minimum-number-of-frogs-croaking/discuss/591884/JavaScript-Solution-faster-than-85.98-memory-less-than-100.00

Hints helped me a lot.

I haven't read any other answers. It just my thoughts.

Runtime: 76 ms, faster than 85.98% of JavaScript online submissions for Minimum Number of Frogs Croaking.
Memory Usage: 37.1 MB, less than 100.00% of JavaScript online submissions for Minimum Number of Frogs Croaking. (2020-04-22 17:22:18 +8)

/**
 * @param {string} croakOfFrogs
 * @return {number}
 */
var minNumberOfFrogs = function (croakOfFrogs) {
  let max = 0;
  const m = { c: 0, r: 0, o: 0, a: 0, k: 0 };
  for (const v of croakOfFrogs) {
    if (!"croak".includes(v)) {
      return -1;
    }
    if (v === "k") {
      m.c -= 1;
      m.r -= 1;
      m.o -= 1;
      m.a -= 1;
      if (m.c >= max) {
        max = m.c + 1;
      }
    } else {
      m[v] += 1;
      if (m.c < m.r || m.r < m.o || m.o < m.a || m.a < m.k) {
        return -1;
      }
    }
  }
  if (m.c !== 0) {
    return -1;
  }
  return max;
};

Deno v1.0

什么是 Deno

安全的 JavaScript 和 TypeScript 运行时.

使用 V8 作为底层的 JavaScript 运行时引擎, 使用 Rust 作为底层系统接口.

如何拼读

一般写作 Deno, 如果在描述具体功能时可以使用首字母小写.

因为 Logo, 我一般会读 dinosaur 的音, dainə. 我也不知道官方希望我怎么读.

为什么要有 deno 这个项目

主要相对 Node.js, 我认为有以下优势:

• [官方介绍] 默认无(文件, 网络, 环境变量)权限.
• [官方介绍] 有开箱即用的 TypeScript.
• [官方介绍] 单一的可执行文件.
• [官方介绍] 简洁可靠的标准库.
• Promise 风格的异步 API.
• 尽量与浏览器兼容.
  比如有 fetch.
• 尽量使用新特性.
  比如跟随 V8 支持 top-level await.

其他我不认为是优点, 但也列出以下:

• [官方介绍] 内建实用工具.

性能如何

Deno 本身有基于最新 master 分支的基准测试 benchmarks, 主要对比 Rust 上限及
Node.js.

从官网给出的测试来看, 目前网络性能与 Node.js 基本相似.

我比较早开始使用 deno, 0.12 之前吧. 当时 deno 的性能不够好, 基本被 Node.js 吊打.
但随着不断优化, 会越来越好的. 尤其是上限给出的 Rust, 在不断贴近.

但毕竟, JavaScript 不是性能见长的语言, 也没必要太刻意追求性能. 不拖后腿就好.

如何使用

因为只有单文件, 使用应该不难.

基本上, 如何使用 Node.js 就如何使用 Deno.

需要注意, 因为模块化问题, 与 Node.js 的依赖是不通用的.

但如果引用的是源代码, 并且内部是纯 JavaScript 而没有引用 Node.js, 那么其实是
可以通用的. 不过仅限我自己写的一些东西, 其他没测过.

权限列表

这点文档做得真不好, 我没有找到. 不过可以通过源代码看到, 有如下权限:

--allow-read
--allow-write
--allow-net
--allow-env
--allow-run
--allow-plugin
--allow-hrtime

当然, 目前还有权限功能不完善的问题, 比如这则 issue 中提到, 现在 workers
还是不能细分权限, 只能继承全部权限.

相关问题

Q: 那么多方法全部放在 Deno 这个对象内, 好傻.
A: 首先, 这样也没有造成什么变量污染, 其次, 这里仅仅存放必要的方法,
大多数需要的其他方法, 在标准库中找就好了, 不会导致体积太大. 浏览器的 window
对象不也这样嘛, 无可厚非.

Q: 有 await Deno.writeFile 了为什么还要 Deno.writeFileSync?
A: 於我心有戚戚焉. 但具体看代码可以知道, 二者并不相等. 理论上来说,
同步的会快一些.

Q: 前端天天搞新东西, 没意义.
A: 不一定会解决所有人的问题, 但一定会解决一些人的问题. 有需要就用, 不需要就不用.

因为我们最近又上了一个 React 项目, 在是否仍要使用 Redux 上做了考量.

React 如何储存和修改全局数据

已经有人这样说了: https://dev.to/anssamghezala/you-don-t-have-to-use-redux-32a6

主要有以下三种方式:

1. 最上层包裹 state, 层层传递.
2. Redux.
3. 上下文.

现在再补充几种:

1. 最上层包裹 state, 层层传递.
2. Redux.
3. 上下文.
4. 模块缓存 + 闭包引用. (不能实时触发渲染)
5. Redux + Web Workers.
6. Hooks + 模块缓存.

URL 与跨域

URL 和 URI 有什么区别

根据 URL 的 wiki, URL 是一种特殊的 URI, 用来表示互联网资源.

URL 的标准是什么

标准由 WHATWG 制定: https://url.spec.whatwg.org/

标准是抽象的, 并且引用套引用, 就像一个包含无数小函数的程序, 需要梳理.

我们来看看 MDN 的文档吧, What is a URL?

在 UTF-8 的现在, 多语言不是问题, 而是大家的守则.
理论上任何语言都可以成为构成 URL 的 valid domain 和 percent-encoded byte.

但是我们倾向于使用这样的规则: 小写字母, 数字, 连字符.

谈谈跨域 HTTP 203

HTTP 203 挺好的, 就是说话太快了, 来不及听.

https://www.youtube.com/watch?v=vfAHa5GBLio 提到:

• 跨域请求问题来源于历史上 Cookies 会被一同发送.
• Access-Control-Allow-Origin 比 Origin 还有历史.
• 之所有会有 Origin 是因为历史上避免包含 - 的头被过滤.
• 但现在 Origin 会有更广泛的作用.

如果网页不使用 Cookies, 似乎就不是什么问题了.

在现在前端当中, Cookies 的功能已经可以完全被替代了.

但可以被取代, 不是会被取代.

sameness, deep equal, immutable

相等

• Strict Equality Comparison === 严格相等
• Abstract Equality Comparison == 大概相等
• SameValueZero
• SameValue 1

=== 与 == 的区别

如果两值类型相等, 则两种对比没有区别. == 的主要功能是隐性地类型转换.

如果一个为 Number 另一个为 String, 则将 String 转为 Number 类型进行对比.

如果任意一个为 Boolean, 则将 Boolean 转为 Number 类型进行对比.

如果任意一个为 Object, 则调用 .toString() 转类型.

转为 Number 类型时, 需要注意: true => 1, false => +0, null => +0.

总结如下:

依据上面的规则, 我们可以得到以下结果.

null == undefined;
"[object Object]" == {};
1 == true;
2 !== true;
0 == false;
-1 !== false;
NaN == "NaN";
!({} == true);
!({} == false);

有些是我们想要的, 但有些不是. 因为这种类型转换的复杂性, 不建议使用 ==.

SameValueZero 与 SameValue 的区别

主要区别在于是否区分 -0 与 +0. SameValue 区分, SameValueZero 则不区分.

这是历史遗留问题, 我们一般不会直接遇到该问题.

=== 与 SameValueZero 的区别

主要区别在于是否区分两个 NaN, === 区分, SameValueZero 则不区分.

赋值

整个 Assignment Operators 比较复杂, 简单说运算符右侧使用的 GetValue.

如果不是引用类型, 则只是返回该值就好.

如果是引用类型, 则将该值复制. 如果右侧为对象, 则创建该值的引用.

深度对比与不可变值

概念:

• deep copy
• deep equal
• memoization
• immutable object

应用:

• JSON.stringify
• lodash/isEqual
• memoize-one
• immutability-helper

tags: ECMAScript

title: 如何用 CSS 自定义使用 Font Awesome 图标
slug: font-awesome-in-css
categories: [css, font-awesome]
author: iugo

最近想在 CSS ::after 中直接使用 Font Awesome 图标.

我们可以直接看代码了解如何去使用, 也可以通过 Font Awesome 官方的文章.

具体实现就是:

.need-after::after {
  font-family: "Font Awesome 5 Free";
  content: "\f007";
}

其中 content 的值可以直接在 gallery 中找到.

附: CSS 的编码

这里顺便说一下 CSS 的编码.

对于一些编程语言来说, 比如 a 会使用 \u0061 这样编码, 其中 u 代表 Unicode.

但 CSS 没有, 虽然编码方式也是 UTF, 但储存方式是固定的 6 个 hex, 比 UTF-32
少了两个储存位置. 比如 a 在 CSS 中可以写为 \000061.

CDC 是 Centers for Disease Control 的缩写, 一般指 Centers for Disease Control and Prevention (美国疾病控制与预防中心).

之前, CDC 一直是不提倡口罩的. 现在则更新了说明:

• 外出到公共场合（例如去杂货店或领取其他必需品）时，人人都应佩戴布制面罩。
• 布制面罩的目的是在您被感染的情况下保护他人。
• 请勿使用医护人员专用口罩。

前一段时间听澳大利亚 SBS 广播, 戴口罩会被 "歧视", 这和** 不戴口罩会被 "歧视" 刚好相反. 可能是文化差异.

但现在, CDC 也建议在一些公共场合佩戴口罩了.

但 CDC 应该是考虑到了现实物资情况, 为了保护一线的医务人员, 告诉大家不要使用 "医护人员专用口罩".

在 Google 最近的几个 Doodle 中, 许多服务人员的形象也是佩戴口罩的.

https://about.google/intl/en_us/stories/coronavirus-front-line-stories/

比如 a = 90 很难理解, 但 小明的语文程序 = 90 就容易理解了, {姓名: 小明, 科目: 语文, 成绩: 90} 可能更好, 从学校的角度来讲, [{姓名: 小明, 成绩: {语文: 90}}] 和 {语文: [{姓名: 小明, 成绩: 90}]} 都可以.

一行暖心的代码，让世界充满爱~

有时用户在访问页面找不到网站的资源时，就会提示404错误。作为网站的开发者，最好应该自己定制404页面，引导用户返回到网站，防止用户流失。

你知道吗？

在自己定制404页面时，只需要在网站中加入一行代码，就能为公益尽一份力。这个页面叫做公益404页面

介绍

公益404页面是由腾讯公司员工志愿者自主发起的互联网公益活动。

网站只需要在自己的404页面中嵌入一段简单的代码，就能通过互联网来迅速传播失踪儿童信息，从而提高找回失踪儿童的概率。失踪儿童信息来自宝贝回家寻子网。

代码

复制以下 js 代码，嵌入到您的 404 页面，可以自适应移动设备

注意事项

如果一个 404 页面的内容小于 512B，IE 会认为该 404 页面不够友好，在 IE 下将不会成功返回该 404 错误页面

<script type="text/javascript" src="//qzonestyle.gtimg.cn/qzone/hybrid/app/404/search_children.js" charset="utf-8"></script>

同时homePageUrl、homePageName两个参数,提高页面定制性

<script type="text/javascript" src="//qzonestyle.gtimg.cn/qzone/hybrid/app/404/search_children.js" charset="utf-8" homePageUrl="返回页面路径" homePageName="返回页面名称"></script>

文章内容参考：：https://www.qq.com/404/

之前大多数项目都是使用 yarn, 但现在 yarn 正在切换到 berry, 有一些问题. 所以最近的新项目使用了 npm. 没想到, 这么多年过去, 依旧是坑.

npm 的确是有效率问题的. 并且有一些低级问题没有进行处理.

效率问题比如依赖之间关系梳理的复杂, 效率低. 具体不展开了, 但实际使用感受已经足够说明问题.
是 Yarn 存在的意义. 同时也是 deno 想要避免的.

这里说一下在国内都可能遇到的问题:

1. 网络原因导致包下载失败.
2. 再次尝试仍然从缓存中拿失败的数据.
3. 如果不清除缓存, 一直无法跳过失败数据.

http fetch GET 304 https://registry.npmjs.org/cssnano-preset-default 982ms (from cache)
silly fetchPackageMetaData error for cssnano-preset-default@^4.0.7 Unexpected end of JSON input while parsing near '...E1piZamJTcxPxUDG/h3FS'

其实这里可以增加一个简单的判断, 如果 JSON 化失败, 则判断为网络问题, 不再从缓存中拿数据.

无法单独清除某缓存, 比如 npm cache clean https://registry.npmjs.org/cssnano-preset-default.

缓存一致性检查 npm cache verify 奇慢.

无奈只好使用 npm cache clean --force 清除所有缓存.

想到清除所有缓存后, 随之而来的所有依赖被重新下载, 想想都头疼.

这真是一个太明显并且太严重的问题了. 网上许多 npm 包的 issues 都是因为 npm 的这一问题.

重新安装依赖中, 太慢了... 不过起码能用, 比代理会快点.

可是 Yarn berry 还是许多问题, 比如 yarnpkg/berry#1149.

使用淘宝镜像吧: https://developer.aliyun.com/mirror/NPM

即便使用镜像, 还是挺慢的.

URL 的 path 部分, 不应该是可以被 encodeURIComponent 编码的.

• 不要使用大写.
• 尽量使用连字符而不是下划线等.

需要修复目前所有文章的文件名.

Jamstack

什么是 Jamstack

只是一个概念, 可以描述一类架构.

JAM = JavaScript + APIs + Markup

在网页应用中, HTML 是通用的 Markup language.

首先前后端分离, 不是 PHP 擅长的那种服务器端渲染.

然后需要将前端代码自动构建为 HTML 及相关部署在 CDN 上.

标准写法

按说, 完整的写法应该是 J.A.M. Stack, 简单的写法是 JAMStack 或 JAMstack.
但是 jamstack.org 和 Netlify 给出的写法是 Jamstack.

我们的经验

我们曾用过 Next.js 的 Static Exporting 功能做过类似的网站. 但还是有一些的限制的,
后来就再没用过.

现在我们更倾向于 code splitting + lazy loading 这种方案. 与 JAM 最大的不同就是
没有 M. 不是在构建的时候生成了多个 HTML, 还是用 JavaScript 生成 DOM, 也就是
Markup.

我们选择不使用静态 HTML 的问题主要是路由, 普通内容站可以说在构建的时候就规划好了
所有页面, 但功能性站点可不是.

比如一个用户的信息页面我们希望是 https://site/people/jim, 但我们在构建的时候
并不真的清楚有多少个用户, 用户都在 API 中获取. 如果要用 HTML 页面和普通 CDN,
我们只能选择 https://site/people?user=jim 这样的方式.

结论

Jamstack 仅适用于内容型站点. 类似的概念不是什么新东西了, 大多数 CMS 都是这样的.

Jamstack 渊源

Jamstack 是由 Netlify 提出的概念.

在 Netlify 的网站上, 有专门介绍 Jamstack 的页面:
https://www.netlify.com/jamstack/.

对于内容展示型网站来说, 如果能遵循原子部署, 那么即便数据量巨大, 理论上也是可以
使用 Jamstack 的.

title: 空值合并运算符 nullish coalescing operator
categories: [ecmascript]

nullish coalescing operator

最近 Logical Assignment Operators 提案到了 Stage 3.

以前没有关注过这一提案, 今天特意看了一下.

提案中说道, 在 ECMAScript 规范中, 有许多数学的赋值运算符,
但却没有逻辑的赋值运算符.

普通的赋值运算符就是 =. 数学的赋值运算符比如 += 是加法的赋值运算符,
-= 是减法的赋值运算符.

所有的特殊赋值运算符目的都是为了简洁, 只是一种语法糖.

不过既然我们都有了数学的赋值运算符, 那就是认可了这种语法糖, 提案者据此提出了
逻辑的赋值运算符.

当然也是借鉴了其他语言, 如 Ruby.

let opts = { foo: 'foo' };

// 等效
if (opts.foo === null || opts.foo === undefined) {
    opts.foo = 'bar';
}
opts.foo = opts.foo ?? 'bar'

// 等效
opts.baz ?? (opts.baz = 'qux');
opts.baz ??= 'qux';

这里说到了以前没见过的运算符, ??, 被称为 nullish coalescing operator.

在 MDN 的中文文档里被称为 空值合并运算符.

听名字就挺好理解的, 主要为了替代 || 的部分功能.

空值合并运算符是 Finished Proposals(Stage 4). 将来大家都可以用到.
在浏览器中的支持情况已经很好了, 主流浏览器的最新版本都支持. 最新的 V8 已经支持,
但目前 Node.js 还不支持.

总之, ?? 对我来说是一个有用的语法糖, 我也会推荐大家使用.