Zeka 的记事本

书写 cron 定时同步脚本时，时间参数设置出现了错误：

* * 17 * * *
# except：
# 0 0 17 * * *
# or:
# 0 17 * * *

由于第一位（秒钟）与第二位（分钟）设置为了 *。导致 crontab 在 17 点时每过一秒执行一次任务。刚好同步脚本用到向 telegram 发送信息，于是出现了对 telegram 的小 d。在我还没意识到发生什么的 51 分钟里，telegram channel 已经出现了 1k+ 条消息（由于本地程序执行也需要时间，所以实际上不可能一秒执行一次）。

换作其他平台（比如莫名其妙把我的开发者号封了的 twitter），这个 bot 肯定是废了。但是 telegram 仍然正常运行。

也许这次没有触碰到 telegram 的上限？毕竟换算下来频率大概 3s 请求一次。

不过不管怎样，也提醒了我 cron 时间设置一定要检查好。毕竟 cron 执行本身是无声的，很有可能出现错误配置却没有发现的情况。

找了找，果然发现了 cron 可视化网站（crontab.guru）。它支持将书写好的时间转化为人类可读的格式，从而帮助你发现错误。

举例来说，将我的错误时间放上去，会提示：

# * 17 * * *
At every minute past hour 17.

这样一下就知道出错了。

单线程 JavaScript 能获得成功的一大原因在于其强大的异步能力。而作为 Node 的 “纠错者”，Deno 提供了更完善的异步支持。async await 满天飞

一个特征是 Deno 支持 top level await。

top level await 特性似乎仍然处于提案阶段，各大浏览器似乎除了最新版 Chrome 没有支持的。

相信学习 JS 的人一开始对于 JS 没有 sleep 函数感到困惑。你无法直接让程序休眠一段时间，JS 只提供了 setTimeout 与 setInterval 方法。这是为了防止主线程阻塞。对于单线程程序，运行在浏览器里的 JS 主线程发生阻塞将会发生无法预知的效果。为此，浏览器只支持回调形式的延时，Top level 的执行在没错误的情况下是不会阻塞的。

但是有了而 top level await 之后，sleep 就变得顺理成章了：

// define sleep function
const sleep = (sec: number) => {
    return new Promise((reslove) => {
        setTimeout(reslove, sec);
    });
};

// use in top level
console.log('execute at time 0');
await sleep(3);
console.log('execute at time 3');

有人说 Top-level await is a footgun，理由也很简单，阻塞了主线程执行，可能一个再正常不过的请求就会导致执行阻塞。

当然，只要加个 wrapper,就能实现伪 top level await 了 机智的地球人：

(async()=>{
    // everthing here！！！
    // I am top level :)
    await sleep(3);
})();

使用自然见仁见智了，但是如果运行环境不是浏览器，那么 Deno 的这个特性将会带来不少便利。比如上面提到的 sleep 函数，以及异步迭代器（for await），请求发送等等。