个人的程序的报警很多人都用的 server 酱 之前我也是用这个的 个人使用的时候确实非常方便 但是因为 server 酱是基于微信公众号的 所以如果要发送个多人 或者分组发送消息 还是不是很方便 于是自己开始准备用 wepy 来做这个工具

结果发现貌似itchat接口被封掉了 issues 不得不寻求其他的方法

最终找到了telegram 不得不说 虽然是聊天工具 但是对开发者还是相当友好的 各种接口都有提供 而且提供了一个非常强大的机器人系统 可以进行各种操作 而且流程非常简单

创建自己的机器人

搜索BotFather 这个帐号 然后发送/start开始对话 BotFather是telegram的一个机器人帐号 用来管理所有用户创建的机器人 开始对话之后 会提示你进行各种操作 来创建和管理自己的机器人 设置机器人的用户名 创建完成之后会得到一个机器人token 之后所有的操作都是使用这个token来做

创建频道

telegram和微信不同 除了组之外还有频道的概念 频道里只有管理员可以发送消息 其他人可以订阅这个频道 接受消息 非常符合报警这个使用场景 创建完了之后设置频道的名称 并且将你的机器人设置为频道的管理员

发送消息

然后就可以测试了 用的是python-telegram-bot这个库

1
2
3
4

from telegram import Bot

bot = Bot(token = "tokenofyourtelegrambot")
bot.send_message("@channelname", "测试内容测试内容")

是不是简单到爆炸。。。。 然后在使用flask之类的封装一下成http接口简直好用到不行

上篇讲了个如何使用gpu.js这个库来进行简单的gpu计算 虽然简单易用 但是本身的局限也很多 目前这个库也不是非常完善 有待改进 那咱就从原理开始 来自己搞一个吧 当然 并不是指实现一个这个的通用的库 而是使用相关原理 完成一个是用GPU计算的demo 当然还是矩阵的乘法

前端使用GPU的能力是通过webgl实现的 更加广泛的理解的可以认为是通过canvas来说实现的 canvas估计对大多数前端来说并不陌生 canvas有许多个像素组成 每个像素的颜色可以有RGBA四个维度表示 每个维度范围为0-255 既8位 把RGBA表示成数值的话 那每个像素可以存32位 这就是前端使用gpu计算最为核心的一点 每个像素可以存储一个32位的值, 刚刚好就是一个int或者uint

0.基本WebGL绘制

首先从最简单的绘制一个图像开始 webgl绘图的流程 最简单的就这样

其中两个vertex shader和fragment shader为两个GLSL代码片段 分别处理坐标数据和颜色数据 vertex shader和fragment shader的执行是以像素为单位

canvas开始绘制的时候 vertex shader中得到 每个需要绘制的像素的坐标 视需要可以对坐标进行各种转换 最终得到一个最终位置 这个过程中可以将数据作为输出传入fragment shader 参与下一步的计算

fragment shader接受各种输入 最终输出一个RGBA颜色数据作为该像素点的颜色值

当所有像素都绘制完成之后 画布绘制完成

前端是可以接触到GPU的 于是也是可以使用GPU的计算能力的 对于我这种没有很深入的GPU运算了解的程序员来说 完全从底层开始怕是也不太可能 好在已经有大神把相关的内容以及封装成库了 gpu.js 于是本文的初识的意思就是就从这个库开始 首先说明 这个库其实也还在开发当中的 也没有一个很稳定的正式版 所以很多功能都是有欠缺的 但是了解个GPU计算是啥来说 绰绰有余了

因为js是单线程的 所以并不适合处理CPU密集型的程序 但是GPU是有非常高的并行线程数 所以GPU计算的基本思想就是把计算任务分拆成N多个线程任务 每个线程返回一个结果 然后吧每个线程的结果再汇总 这个基本的思路不管是哪平台上的应该都是一样的

啥是线程的概念 咱先直接看一段代码来先感受一下

1
2
3
4
5
6

const gpu = new GPU();
const myFunc = gpu.createKernel(function() {
    return this.thread.x;
}, { output: { x: 100 } });
myFunc();  // [0,1,2,3,...98,99]

每个线程都会执行这个传入的函数 具体起多少个线程有参数output决定 可以有x,y,z三个维度 上面这个例子只取了x方向上数量100个

在函数里this.thread.x可以获取到当前执行这个函数的线程x维度上的地址 如果有多个方向的话 还有类似this.thread.y和this.thread.z的

函数接受的参数为外部调用的时候传入的参数 函数返回的值为当前线程返回的值 所有线程按照各个维度上的位置 向最外面返回一个最终的数组 就是上面那个执行的效果 每个线程直接返回了线程在x维度上的位置 最终吧所有线程按照维度的顺序合并起来 如果有两个维度 最终的值就是个二维数组 同理三个维度也是

要注意的是 这个执行的函数 最终会被库转化进入到GPU中执行 所以 所有外部js的参数和函数 还有该函数里的语句语法是有限制的 具体的解决方法可以参考文档 有向内部传入数据的方法

从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

这个主题想写已经很久了

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

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

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

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

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

最近干嘛都不知道 瞎搞了很多乱七八糟的东西 整理一下 虽然事情都是小事 但是因为都很简洁而且强大 特别喜欢 所以记录一下

1. 使用pssh一个指令 批量服务器执行制定脚本
2. python使用mysqldb导出数据量超大的表
3. 使用rsync同步多台服务器上的数据
4. 微信文章爬虫
5. 破解百度云限速的小工具

批量远程操作服务器

因为一个需求涉及到批量操作远程服务器 找了很多文章和工具推荐 一个个都没有我想要的 有推荐pssh的 就是 parallel-ssh 也没有很方便的使用方法 后来我自己研究help 找到了一个非常非常好用的方法 这样 相当好用 完全满足自己的需求了 后来想想 还是有点不足 就是如果每个服务器登陆用户名不一样怎么办 不过这个已经提供了一种思路了 直接用ssh命令也可以操作了吧

1

parallel-ssh -I -P --user username -h server/list.txt bash < script/to/run.sh

之前写过一点点 后来又看了 一篇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或者官方标准 这些东西更新太快了 不能保证写本文的时候的标准以后不会变