从pyhton的生成器到js的生成器

说起这个generator啊 本不是js的东西 而是从其他语言中借鉴来的 当初初es6标准的时候想必大家都看过了 也都知道所谓生成器 但是估计大家和我一样 可能从来也没用过吧 最大的用处估计就是在async/await实现之前来替代的处理异步吧 比如koajs1.x 但是这并不是generator本身应该的正确用法 如果你是generator 你心里会怎么想 本来我估计也用不到这东西 但是最近我不是后来去写了python嘛 也终于在一次认识到了这个东西 然后再次从js的角度看待generator

首先来个例子 redis中每个用户有一个物品列表list user:$userId:items 每个物品有物品详情hashset item:$itemId 现在需要遍历所有物品 为了减轻内存负担 所以要一条一条取

js 回调参数 内部回调函数版

1
2
3
4
5
6
7
8
9
10
11
12

function getAllItem(userId, callback){
    redis.lrange(`user:${userId}:items`, 0, -1, function(err, itemIds){
        if (err) return callback(err);
        for (let itemId in itemIds){
            redis.hgetAll(`item:${itemId}`, callback);
        }
    });
}

getAllItem(1234, function(itemDetail){
    console.log(itemDetail);
});

这个版本因为整个函数都是异步的 获取所有物品后再执行后面的过程 这个操作是没法处理了 需要对回调参数函数进行再次封装 即使内部换成Promise也是一样的

本文的目的是为了和大家分享如何从官方文档中获得答案  
至于标题中和本文其他的语法也是非常不规范  
在平时开发中需要极力避免使用`==`与不必要的类型转化

我先抛出一个例子 大部分人估计会很疑惑 在语言大战中 很多其他语言的人也经常抓住类似的例子来攻击js

但是js作为一个有规范的语言 所有的结果都要遵循规则吧 然后咱就来带大家看看 关于==语法在es 2017中的定义

为啥是2017呢 因为本文写的时候最新的标准就是这个版本 ECMAScript® 2017 Language Specification (ECMA-262, 8th edition, June 2017) 但是没有关系啊 我会截图给大家的

首先先看==的标准 Abstract Equality Comparison

这段时间各种面试 杭州在网易之上的 当然只有阿里一家了 就找了学长帮投了阿里云的简历 没想到投的是资深全栈工程师 有点点虚 ——你一个刚毕业一年不到的也敢投资深全栈？？ 不过最后还好 挂在了hr上 吐槽一句：阿里的hr果然名不虚传，算是见识到了。 技术的几面还是挺顺利的 技术官也都非常厉害 可惜忘了要联系方式了 我感觉所有的hr都有毒，我挂在hr上已经不止一两次了 十几次都有了吧？？

跑题了 笔试出了三题 都不难 和面试官共享页面 也可以对话什么的 这种笔试方式 与其说是笔试 更像是面试的时候拿张草稿写解决方法的感觉 我觉得非常棒 （最后我会对比另外一家的笔试题目 真的太垃圾了）

其中第一题 让我就非常欣赏 题出的太棒了

 实现一个函数，传入一个数组，元素均为字符串，把数组中的所有星号(*)移到末尾，其他值的次序不变，如下图


这个题目非常简单啊 但是我觉得这个是个非常好的题 具体好在哪呢

这个主题想写已经很久了

自从换了新部门之后 也没有写过前端 因为部门总共6个人 有两个前端 然后后端和算法人员不足 因为我技术比较强 就被安排到了新的任务 老大和我说 做数据和算法比前端有前途 话是这么说的 但是我从大一起开始写前端写了这么多年 突然让我去写其他的 那我前端领域的优势就没了啊 而且就算我继续算法这些写个三年四年 到时候仍然随便一个刚刚毕业的专门研究算法的就能把我干趴下了好吗 毕竟我也没怎么专门研究过这些东西 不过既然部门有任务安排 那只能写了 这段时间经历了 python从入门到精通 hbase从入门到精通 hadoop从入门到精通 什么kafka 什么zookeeper 让我作为一个前端大开眼界 有点偏主题了。。。。

我的主要工作有三点本文只是涉及其中一点 就是基于协同过滤的推荐算法 我们部门是推荐技术部 各种推荐算法当然是我们部门的核心技术 协同过滤这一块没那么核心 但是也非常重要

这个相关的文章 网上也是一抓一大把 主要的原理是通过用户对物品的行为来计算物品与物品之间以及用户与用户之间的相似度 算法的核心数学公式有好几种 我就不重复写了 我负责的这一块是从其他项目中借鉴过来的 发现对应的数学公式和现有的一些公式并不一样 我也不便透露了 不过各种公式的功能是一样的 都是为了计算相似度 不同公式对不同对场景会有优劣而已

先说结果 为ejs-mate实现了一个组件加载函数 实现了服务端组件化的渲染 按组件加载js与css资源

目前很多前端标准各大浏览器都有部分支持 心想试一下 然后试试看把vue的组件改成原生的前端组件吧 然后看了一下WebComponents 发现Shadow DOM离我上次看的标准又有变化了 没办法 目前这些基本还处于草案的阶段 只有template标签因为属于HMTL5的标准 目前是比较稳定放心可用的状态 具体就不多说了 写了两个组件 弄了个demo xjpin.github.io/blog-demo/webcomponents 代码在这github.com/xjpin/blog-demo/tree/master/webcomponents chrome56+

然后我发现并不能把vue的组件完全移植到原生的组件上 后来发现事情并没有这么简单 重新审视一番发觉 vue 的这些所谓的组件实质上是 模板 之所以不能移植到原生组件 很大一部分原因是诸如v-if、v-for等语法 而这些在模版引擎里非常常见 包括router-view这种 原生组件是根本没法搞的

vue ng之类的 本质上是前端的组件化渲染 组件本质就是模板 相比后端组件化渲染还只是停留在非常低级的includehtml模板文件的阶段 对组件的js与css的处理几乎没有

所以我在想 按照各自框架渲染组件的方式 如果移植到服务端渲染 那岂不是很爽吗 然而vue是有服务端渲染的 不过这个服务端组件渲染和前端组件渲染不太一样 服务端渲染只是把html相关的渲染完成 而事件属性之类的传递和前端组件渲染并没有区别 也还是包含了一个完整的Vue对象 所以其实这种渲染并不是完全的服务端渲染 而是分步渲染 反而觉得这种方式非常多余 为了seo的一种妥协

于是开始搞一个吧 完全后端渲染的 组件化的解决方案 各自模板引擎其实都有提供include方法 不过这只是html的模块化 事件以及数据传递相当成问题 弄了一个简单的 包含了这种思想的 demo

最近整理一篇关于 一些 浏览器html5 相关api 的权限的东西 虽然大部分都可以用了 但是基本上还是草案居多

本文所有的demo都在 这里 blog-demo/permission 代码在这github.com/xjpin/blog-demo

有几个权限的demo还没有写好 之后会单独写出来

w3c.github.io/permissions: Editor’s Draft, 17 October 2016

事实上不止链接中的这几个权限, 比如usb, 本文就只对下面列出的这几个权限进行介绍

1
2
3
4
5
6
7
8
9
10
11
12
13

enum PermissionName {
      "geolocation",
      "notifications",
      "push",
      "midi",
      "camera",
      "microphone",
      "speaker",
      "device-info",
      "background-sync",
      "bluetooth",
      "persistent-storage"
}

push background-sync需要配合service worker工作

notifications 在service worker与浏览器环境中有不同

检查权限

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

navigator.permissions.query({ 
    name: "notifications", // ["notifications", "push", "midi", "background-sync"]
    //not support now: ["camera", "microphone", "speaker", "device-info", "bluetooth", "persistent-storage"]
    userVisibleOnly: false, // for "push"
    sysex: false, // for "midi"
    deviceId: null, // for ["camera", "microphone", "speaker"], 可以从`navigator.mediaDevice`接口获取
}).then((permissionStatus) => {
    let { 
        state // ["granted", "denied", "prompt"]
    } = permissionStatus;
    permissionStatus.onchange = function () {}
});

// 请求权限 目前没有浏览器实现这个接口 所以在各个接口有自己的实现
navigator.permissions.request({})

之前写过一点点 后来又看了 一篇ppt You Might Not Need CSS Preprocessor 讲了一些关于当前预处理解决的痛点以及它们缺点 并给出了使用原生css解决这些痛点的方法 然而大部分方法都还只是标准 甚至有的还是提案 浏览器实现就更少了 不过可以作为展望来期待一下美好的未来吧 算是The Future of CSS

预处理器解决的痛点:

1. 变量 (CSS Variables)
2. 混合 (Mixins)
3. 嵌套 (Nesting)
4. 模块 (Modules)
5. 其他: 选择器辅助方法, 颜色函数等 (Selector helpers, color functions)

预处理器的缺点:

1. 额外配置 (Additional setup)
2. 需要编译 (Compilation)
3. 不够标准化的语法 (Not standardized syntax)
4. 调试困难 (Hard debug)

然后文章告诉你 这些痛点都有原生的解决办法 具体的兼容性可以查看 caniuse或者MDN或者官方标准 这些东西更新太快了 不能保证写本文的时候的标准以后不会变

之前的那个12脚扫描式4位数码管 要想显示1234这样的数字 一个扫描周期里需要四个动作 每个动作只显示一位 另外三位是不亮的 而且每次占用了大量的针脚 于是 淘宝上买了个带芯片的 4针脚的 4位数码管

本次的芯片是用的TM1637 查了一下 到处都是只有arduino的代码 而且貌似这个数码管也是标配给它的 不管 反正接口是一样的嘛

原本给arduino的代码是用c写的 还找到了另外一个python写给树莓派的 两者的代码的思路是一样的 但是还是没有看懂 说好的基本输入输出呢 两个的代码全都是直接修改pinMode来处理高低电平的 我擦泪 完全看不懂啊 为啥不用digitalWrite

反正就是这个数码管有4个脚 一个电源 一个接地 一个时钟信号 一个串行输入信号 然后看文档 文档 尼玛这什么狗屁文档 完全看不懂啊 一个是数码管的说明 一个是芯片的说明 一个是两者连接说明

这个答案要从一个题开始。

基本上所有的语言都提供了一个random方法来获取一个随机数，以js为例， Math.random() 将返回0到1之间的任意值。这个方法所有的值都是等概率的，从概率论角度来说，即该方法的概率密度函数为常量，为：p(x) = 1, x∈(0,1)
如果将随机变量做一次处理，例如平方，那么它的概率分布将会怎么样。得到下题：

如果x为(0,1)上的随机变量，且概率密度函数为p(x) = 1, x∈(0,1)，求y=x^2的概率密度函数。

这个题啊，其实很简单，如果是当初大一的时候还在上概率论的课，两分钟就解出来了。不过虽然很久没接触概率论，花点时间还是能解出来的。

心血来潮，来写一个模板引擎吧！

功能就不多说了

实现思路

从最简单的开始吧

假设一个模板长这样

<h1><% var world = 'world!'; %> hello <%= world %></h1>