关于 Fetch Api,接受度越来越高了。网上很多文章在介绍 Fetch 的用法,在鼓吹 Fetch 的优势,也有人在撰文批评 Fetch 的难以使用。
但是,当我们在讨论 Fetch Api 的优点和缺点的时候,我们在讨论什么?如果不清楚一个接口的设计目的,又如何去评判这个设计?
电阻色环标注
电子-色环标注
如何识别电阻的顺序
先找标志误差的色环,从而排定色环顺序。
最常用的表示电阻误差的颜色是:金、银、棕,尤其是金环和银环,一般绝少用做电阻色环的第一环,所以在电阻上只要有金环和银环,就可以基本认定这是色环电阻的最末一环。棕色环是否是误差标志的判别。
棕色环既常用做误差环,又常作为有效数字环,且常在第一环和最末一环中同时出现,使人很难识别谁是第一环。在实践中,可以按照色环之间的间隔加以判别:比如对于一个五道色环的电阻而言,第五环和第四环之间的间隔比第一环和第二环之间的间隔要宽一些,据此可判定色环的排列顺序。在仅靠色环间距还无法判定色环顺序的情况下,还可以利用电阻的生产序列值来加以判别。
比如有一个电阻的色环读序是:棕、黑、黑、黄、棕,其值为:100 × 10000 = 1MΩ,误差为1%,属于正常的电阻系列值,若是反顺序读:棕、黄、黑、黑、棕,其值为140×1Ω=140Ω,误差为1%。显然按照后一种排序所读出的电阻值,在电阻的生产系列中是没有的,故后一种色环顺序是不对的。
解读色值
助记
棕一红二橙是三,
四黄五绿六为蓝;
七紫八灰九对白,
黑是零;
金五银十表误差。
new URL()
URL 接口是 web 接口,包含若干静态方法的对象,用来创建 URLs。
当使用一个没有实现该构造器的用户代理时,可以通过 window.URL 属性来访问该对象(比如小程序里面就只有 window.URL),对于没有 URL 的用户代理,可以使用第三方实现,比如:https://github.com/zloirock/core-js/blob/master/packages/core-js/web/url.js
基础使用参见:
https://developer.mozilla.org/zh-CN/docs/Web/API/URL/URL
https://developer.mozilla.org/zh-CN/docs/Web/API/URL
https://developer.mozilla.org/zh-CN/docs/Web/API/URLSearchParams
容易让人疑惑的点:
示例一,Chrome 浏览器:
1 | const obj = new URL('http://hostname/pathname?name=value#hash') |
示例二,Chrome 浏览器,把 http 协议换成 scheme:
1 | const obj = new URL('scheme://hostname/pathname?name=value#hash') |
示例三,Node.js:
1 | const url = require('url'); |
可以看出,这个 URL 的规范与其他实现里面的实现还是有区别的,whatwg 的 URL Standard 定义了几个 special-scheme:
https://url.spec.whatwg.org/#special-scheme
当你发现 URL 解析的结果不符合你的预期时,你需要的可能是 URI ,而不是 URL。=。=
Javascript Array Like
“array like”(类数组) 这类数据对象见得挺多的,典型的如“NodeList”、argument对象以及字符串.
keil基础
源文件管理
keil 新创建的源文件或者头文件默认都在工程目录下。
创建文件夹
工程目录下创建对应的文件夹,比如:
proj
-- app
-- public
并将对应的头文件和源文件放到对应的文件夹中。
创建并添加到 Group
创建需要的 group,最好是保持 group 名称与上一步创建的文件夹名称一致。
同时将源文件添加到对应 group 中。
添加Path
由于分了多个文件夹,因此在引用其他文件夹内的头文件时,就找不到了,所以需要把这些头文件加到查找路径中:
其他正常操作就行了。
Lib 的使用
创建 Lib
将文件打包成 Lib 文件:
生成的 Lib 文件在工程目录的 Objects 文件夹下(不同版本可能位置不一样)。
引用 Lib
不过只引用 Lib 文件是不够的(尤其当 Lib 是个独立的工程),还是需要把 Lib 使用的头文件放到当前工程的头文件查找路径里。此时可以选择把 Lib 工程的头文件放到独立的目录里,然后其他工程引用这个目录的头文件就行了。具体参见上文“源文件管理”部分。
常见错误
引用 Lib 报错
SN: Eval Version
这类错误,通常是因为版本不对,自己上网去找个正式的破解版得了。
那些传男不传女的技艺,最终都消失了
其实我并不是想说重男轻女的问题,而是想用“传男不传女”这种说法来指代哪些神神秘秘的传统技艺,毕竟这种博人眼球的标题总是能吸引关注。
问题源于我看过一个揭秘川剧变脸的小视频,结果底下清一色的评论“这种视频应该封杀,中国传统技艺不要让外国人偷师了”,无一不是在逼迫原作者删除这个视频。初看之下我还不以为意,结果发现抱有这种观点的人真是不在少数,也不知道是应该感叹拳拳华夏爱国之心,还是感叹素质教育任重道远。
应该怎样评价这种观点呢?首先得看“传男不传女”这种规矩是怎么来的?“传男不传女”的一般都是一些赖以谋生的独特手艺,比如“变脸”,比如“唐朝鼓乐”,再比如沸沸扬扬的“漆线雕”,当初先人立下此规矩原因无非有二:
- 认为女儿终究是外人
- 古代的“专利保护”,其实第一条也是依赖于这一条的,因为“外人”终究会成为潜在的竞争者。