p2227.github.io
p2227.github.io copied to clipboard
p2227
personal pages
## 目的： 不用每一次push的时候都输入用户名密码 ## 原理 - 参考 https://zh.wikipedia.org/zh/Secure_Shell - 一言蔽之，就是ssh协议支持使用公钥-私钥的方式访问 ## 效果： 可以做到多个git协议的网站同时使用的效果 可以做到一个git协议网站的多个帐号同时使用的效果 ## 步骤 1. Mac/Linux 打开命令行终端, Windows 打开 Git Bash 。这个git Bash在安装了git命令行之后会有 输入`ssh-keygen -t rsa -C "[email protected]"`，提示信息基本上按默认即可（也可以输入密码）实测发现即使是私有项目，也不需要输入密码...
此文章是 #5 的后续 在安装node-canvas的时候，也总是提示这个，不同的是，这次提示错误 的地方找不到源代码的所在地 ``` gyp ERR! stack Error: unable to verify the first certificate gyp ERR! stack at Error (native) gyp ERR! stack at TLSSocket. (_tls_wrap.js:1016:38) gyp ERR!...
> 富文本编辑器的基础 (document.getSelection && range） # 0x01 Selection 和 range之间的关系 document.getSelection 方法会返回一个`selection`对象，对象中会有0个或者1个`range`，当网页中有了光标，或者选中了某个区域，selection中就会有1个range，否则0个range # 0x02 selection selection的属性和方法有很多，需要注意的有以下几个 * anchorNode 表示选区开始的节点，可以是一个文本节点。 * anchorOffset 表示选区在anchorNode内的偏移 * focusNode 表示选区结束的节点。 * focusOffset 表示选区在focusNode内的偏移 * isCollapsed...
--- ## 本文写于2016.6.1儿童节 :-) 一般使用者如果第一次进入公众号并且进行一笔支付，公众号系统总共需要三次签名。其中有两次的签名需要前台Web知道结果。 - 第一次（告知前台）是wx.config签名。 这个签名需要当前url，并且是sha1算法 这个接口需要很多先决条件，慢慢看文档不会有问题 参考网址 https://mp.weixin.qq.com/wiki?action=doc&id=mp1421141115&t=0.026192156120719012&token=&lang=zh_CN#fl1 - 第二次（不需要告知前台）是服务端调用统一下单接口时的签名。 把所有非空参数排序后加上商户key，再MD5， 这个接口比较常见，其中的数据交换是服务端与平台的 参考 https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_1 - 第三次（告知前台）是客户端再调用 js-sdk 提示用户输入支付凭证的. 这里面有两套前台js的API，一个是 wx.chooseWXPay， 一个是 WeixinJSBridge.invoke('getBrandWCPayRequest') 这里面前后台要统一一个方法调用，因为前者参数是timestamp，后者是timeStamp。所以签名肯定不一样 后台根据参数生成签名后，前台也要一致地调用它，才OK，不然会提示“支付验证签名失败”。本人用的是第二套方案 参考 https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=7_7&index=6 关于签名：这个是一个web安全的问题。由于签名中需要用到商户key（实质上是一个密钥）进行摘要算法，这就保证了请求的发起方一定是该商户，而不是其他人伪造的。
# npm 提示 unable to verify the first certificate 的解决小结 --- 在npm 安装包的时候，经常会提示`unable to verify the first certificate`，在此对该情况的解决方案进行了一些小结，总体说来，这个问题的出现都是因为用了代理。 https是一种安全的协议，确保服务端与客户端之间传送正确性的。现在中间多了一个代理转发，有一些连接会觉得这样不靠谱，不让你们连接去连接。在npm中有一个配置可以把这个去掉，就是`npm config set strict-ssl=false` 我说一下我自己的网络情景吧，代理才能访问外网，但是公司在全球都有代理，一但用了国外的代理，什么google,youtube,facebook等都能非常快地访问到。所以我一直就是用npm官方的源（非https)，并且配置了`strict-ssl=false`。 今天看到有一个非常方便的node调试工具`devtool`想来安装，当中用到了electron，然后就是死活安装不了，之前在安装`node-sqlite3`也经常提示这个问题，当时是**切换代理（比如从美国的代理切换到瑞典的代理)**就可以了。但今天这个方法不凑效。 肯定是因为里面下载 electron 的时候用了一段https的下载连接，但该连接建立不起来。由于fiddler抓取不到相应的url，我就在出错提示的目录找到了下载的源代码。于是找了相应的npm包的源代码，关键代码如下 ``` var url...
# HTTPS知识小结 ## 背景1：TCP握手 internet上的两台机器A,B要建立起HTTP连接了，在这之前要先建立TCP连接，情景大概是这样子的： * A：你好，我跟你建立一个TCP好吗？ * B：好啊。 * A：那我们建立一个TCP连接吧。 网络上有个关于TCP的笑话，大概就是上面的意思。当然事实上的情景要比这个复杂： * A：你好，我跟你建立一个TCP好吗？我从0x0A00这个序号开始给你发送数据（SYN）。 * B：好啊。我从0x0B00开始给发送数据（SYN），我收到你0x0A00开始的那个握手数据啦，（ACK=0x0A01） * A：那我们建立一个TCP连接吧。我收到你0x0B00开始的那个握手数据啦（ACK=0x0B01） TCP握手本质上是在约定一次二进制通讯的参数，使得网络上的两台机型能够基于这个约定交换二进制数据。因为大家也知道，二进制数据就是一堆0和1，如果没有事先约定好字节长度的分割和每个位代表的意义，是无法解读的。 ## 背景2：TLS握手 还是上面的情景，A和B建立好TCP连接后，又要建立一个TLS连接了 * A：你好，我跟你建立一个TLS连接吧，我支持的加密方法有A1,A2,A3.....我的加密参数有A10，A11，A12... * B：好的，我们选定A1作为加密方法吧，我选择的参数是A10，这个是我的证书，里面有公钥，你拿着我的公钥用上面的加密方法加密个密码来看看。 * A：(转过头去问CA，证书是否合法)，好的，我想好一个密码啦，这是我的密码用你的公钥加密之后的结果，blablabla... * B：(用自己的私钥去解密)我知道你的密码是多少啦，下面是你的密码对称加密之后的密文，lablablab......
setState这个api里面做了些啥 ，网上有很多资料，典型的是关于源代码里面的一幅ASCII图画 ``` /* * * wrappers (injected at creation time) * + + * | | * +-----------------|--------|--------------+ * | v | | * | +---------------+ | | *...
# react 学习 --- 自己写一个react 4.domdiff react的出现，解决了前端一直以来的几个痛点，一个是组件化，一个是dom的更新效率问题。domdiff算法是后者的关键。 这一步的更新持续时间比较久，代码行数也从1xx变成了4xx，参考了react和一些迷你react的框架，下面把一些要点记录一下。 ## 大思路 这里面有两条思路分支，到底我们是先把新旧的虚拟dom都生成好，比较完再去应用dom上 (dom Patches) ，还是直接在真实dom上面遍历，一边比较一边应用差异呢。 官方是用前者，一些迷你react框架是用后者。在我看来，前者其实是一种分层处理的思想。`state处理层->虚拟dom比较层->dom Patch层`， 每一层之间的对接保持一致，那么每层内部就能在一个小的关注点里面进行优化，就好像TCP/IP分层那样。 当然这样的设计肯定会有一定的性能损耗和代码冗余。我觉得关键在于你对于框架代码的定位如何，如果是定位比较大，建议分层。如果是针对当前具体业务问题快速解决，那把所有的更新写在一起会更加快捷小巧。 我的目的是学习官方的思路，所以我选择了前者。 ## dom Patches 在实测过程中经常有 state1->state2好好的，state2->state3不符合预期的问题，细节断点调试之后，发现原因一般是dom的Patches没做好。针对真实dom，经常会断链，针对虚拟dom，一般是局部属性的增删改没同步好。 针对react组件，可以看成以container为根的一棵大dom树，对树或者链表进行操作的时候经常会遇到断链的问题，比如在textNode在更新时，要针对于包裹它的element进行，否则会断链，后续节点的更新就跟踪不了。而且也会发现更新真实dom后忘记更新虚假dom的情况，在state2->state3时，实际上是state1->state3，会发生各种超出预期的情况。 ## 简化问题，循序渐进 事实上，dom节点的变化可以非常大，之前还是一个textNode，后面可能会变成一个列表，列表有可能有些有key，有些无key。我会先覆盖以下测试用例 1. 同一类型节点，内容（textNode）有变化...
这一步跨度比较大，主要有两个方面，`react组件的状态更新`与`基础设施升级` ## react组件的状态更新 这个话题十分庞大，涉及到`setState内部机制`与`domdiff算法问题`，react的几个精髓之二就在这里了，不过我并没有一步吃下这两个大内容。我们回顾一下我们是怎么更新react组件的？一般说来途径是这样子的 ``` 用户触发行为->调用到组件的setState->组件进行更新 ``` ### 用户触发行为 本质上就是事件绑定，因为没有事件，不能响应用户的行为，而事件绑定又涉及到react里面的一个大点`合成事件`了，fb还用这个去申请了专利，不过也有人觉得这里面的代码很冗余。我这里简单起见，直接针对onClick属性的dom进行事件绑定 ```javascript if(props.onClick){ //react中是使用合成事件的，鉴于时间问题先省略 domElement.addEventListener('click',props.onClick); } ``` ### 调用到组件的setState 这里面就是按照`事件绑定->调用api->合并state->生成新虚拟dom->下一步`的步骤进行 ### 组件更新 简单起见，我是直接比较组件有没有差异，一但有，就整个dom更新掉。 把以上思路串起来，就做完了这个阶段的代码，实测也是可以运行的。 https://github.com/p2227/diyReact/blob/dbaebfc6fd58432cae3ea427ffd9851783a5eaa4/src/stage2-update.js ## 基础设施升级 在实现本次升级的过程中，我经常修改实例代码，要设计一个不太复杂但是又能体现以上功能点的交互实例，还是有很多细节需要打磨的。由于受不了一次次复制粘贴babel，也不想配置构建环境。于是把关注点放在了online版本的babel上 http://babeljs.io/setup#installation ，但是文档里面的用法我不太喜欢，他是每个实例都要写一个页面的。我观察了一下 standalone...
## 0x00 背景 由于最近的业务都是面向海外用户的，所以我果断申请在主站中加入PWA功能，由此得到了一次PWA的实践机会。 网上关于PWA的文章很多，但大多数是停留在理论层级。印象最深刻的是饿了么的知乎专栏，因为是真正实践的总结。 PWA中最重要的一个点是service worker，以下简称sw。 ## 0x02 参考文章 * https://github.com/p2227/p2227.github.io/issues/11 * 前端大多数的基础归根到底要看标准，https://w3c.github.io/ServiceWorker/ * 当然，PWA首先是google提出来的，所以有不少文章可以在google 找到 [1](https://developers.google.com/web/fundamentals/codelabs/your-first-pwapp/) [2](https://developers.google.com/web/fundamentals/app-install-banners/) ## 0x03 开发域名 * 开发的过程中，要么用http localhost ，要么用https 带域名，其他方式不允许 ## 0x04 生命周期...