目前白嫖 HTTPS 的主流途径依旧是 LetsEncrpyt，certbot 似乎是官方主要推荐的一个申请方式，关于用途和用法，这里不多介绍，总之，是一个品种齐全，种类多样的 cli 工具：https://certbot.eff.org/
这里由于我的 NAS 希望签 HTTPS，但是电信开外网是不允许开 80 和 443 端口的，所以无法用 HTTP 协议去校验，只能选择 DNS，如果没有 DNS 插件，那么只能用 Manual 的方式，非常麻烦。
于是，我开始了面向源代码编程——
最近在写项目的时候有个需求：我的 Promise 即使失败了也没关系——更进一步的，当且仅当失败率大于某一值，这才是一个失败的请求。
于是我查看了包括 ES6 Promise 和 Bluebird 的实现，发现都没有我想要的效果：
在完成项目之后把函数抽出来作为一个单独的 utils 模块发布，今天总算把 lint 和 test 补齐了，于是顺手写一篇宣传文。
他没什么大作用，函数实现还是表现形式都比较 Low：
const foreach = require('sky-promise-foreach')
foreach([...promises], (result) => {
// success handler for each promise
}, (err) => {
// error handler for each promise
})在同事的建议下，之后有空可能会出一个改版，把这个库做的更通用一点。
听说标题要长才有人看。
B 站状态监听也是一个吃饱了没事干试水的项目——除了例行命令行工具之外试了一下命令行可视化交互的库 inquirer、nodemailer 发邮件，crontab 计划任务，在上次做计划任务的时候用的还是 Python 的 plan 库，现在觉得略麻烦，还是直接写进命令行工具里方便，最后在加上 CI（第一次加还是有点小激动）。
具体的都可以在项目里看到：https://github.com/csvwolf/listen-bilibili-live
最近有一个需求，大致是要根据图片的背景色来切换前景色，也就是根据 background-color 的色值切换 color。
虽然这么一说，那么就能抽象出以下几个问题：
昨天整了一天的 SSR，卒，总结一些经验教训仅供参考。
这就要说到天下合久必分，分久必合的道理了——最初的时候，静态页面就是静态页面，前后端 MVC，服务端渲染出页面；之后，前后端分离，后端提供 API，由客户端渲染页面；最后，我们又回到了最初的起点，不过是前后端分离后再由后端多渲染一次。
这样做的优点当然有很多啦，比如说我们要照顾爬虫（不），照顾蜘蛛，Vue 官方文档写的几点都已经很清楚了：
最近在做 Chrome 插件的高级功能，突然想要试试可视化选择 key 的路径，再一想，咦，这不就是个编译原理的典型例题吗？
于是我就开始着手学编译原理了，主要参考 dalao 的以下两篇文章：
编译原理一共分为四个部分：词法分析，语法（文法）分析，语义分析，代码生成。
词法分析，就是逐个解析之后加上词性，语法分析则是将词法分析后的结果解析为抽象语法树，语义分析是在语法分析时针对具体的实例加上额外的动作解释。具体的可以见上面的链接。
在 JSON 的首页有非常完整的词法和语法分析的 token 列表甚至是流程图，所以可以省去了一些劳动。
I reposted an article to avoid high maintenance cost of the repo and as well, everyone can have a try, no more need to repy on cloing the repo.
First of all, the steps of how to install laravel is omitted, use laravel new blog directly.
If you are a Chinese mainland user, you can use the composer image: http://pkg.phpcomposer.com
If there is a Warning after new like( Hmmm, anyway, I met the problem everytime. OTZ )
重新开一篇文章来写，这样可以免于仓库个人维护成本比较高，以及大家可以自己尝试配一下，不必依赖克隆仓库等。
首先这里省略安装Laravel的步骤，直接laravel new blog。
如果你是中国大陆用户，可以尝试这个composer镜像：http://pkg.phpcomposer.com。
如果在new之后发生了Warning（嗯，反正我每次都遇到了OTZ）
这学期做的一个作业，稍微总结一下自己的设计思路，顺便读了一篇美团技术部门写的《消息队列设计精要》，深感做一个消息队列的复杂程度。
简单介绍一下，我的消息路由开源中，但除了学习之中没有什么卵用（这篇文章也不会讲代码的实现，主要是设计思路），之所以这样是考虑到整个系统的开发难度进行了取舍，之后也会说到：https://github.com/csvwolf/Sky_Message_Routing_Middleware
我们要做的东西简单的来说英文是Message Router，也就是消息路由，实际上也就是没什么卵用的转发器，尤其是小规模的情况下——整体而言是一个问答系统，我们有3个前端，一个后端，在这种规模下，似乎确实没有什么意思，只能自己虚拟情况了。
