两年前写过一篇文章利用现代浏览器所提供的强大 API 录制，回放并保存任意 web 界面中的用户操作实现了浏览器操作的录制、保存、回放、管理等功能。不过之前的实现是基于rrweb这个项目，限于浏览器本身对于API以及rrweb的限制并不能完美录制 （比如webgl） 所有操作。
作为周末项目没想到也收获了上百的star，期间还有很多人私信使用中的问题。正好今年过年因为疫情留守没回去家，所以把整个项目进行了重构，使用了更强大的API以及更完善的文档。核心API是MediaDevices.getDisplayMedia()，虽然状态是Working Draft，但是各大主流浏览器早就对其进行了实现（Chrome 72 2019-1 , Firefox 66 2019-3 , Safari 13 2019-9）。
开始之前还是求一波
star：项目地址
SpaceX上的Javascript 这下面试造火箭没准真就去造火箭了
在上个月SpaceX 成功发射了载人火箭Dragon 2，其中的飞行界面就是由Chromium 和JavaScript进行构建的，当然只有图形界面是，系统的其他部分还是由c++来完成的。
Also, only the actual graphical display application uses Chromium/JS. The rest of the system is all C++. The display code has 100% test coverage, down to validation of graphical output (for example if you have a progress bar and you set it to X% the tests verify that it is actually drawn correctly).
不知道会不会出现氧气剩余 NaN%，着陆地点undefined
火箭的操作界面估计是不会开源了，但是SpaceX-API 倒是在GitHub上开源了。
继阿波罗登月的代码之后又参与了SpaceX-API 的review，以后面试问我参与过什么项目就可以说参与过阿波罗登月计划和SpaceX 载人航天计划的code review。感觉准备个PPT可以去融资了。
按照时间自增，可排序。
并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)。
经测试 MacBook Pro (15-inch, 2018) 每秒可产生136万左右的ID。
twitter开源的地址：twitter-archive/snowflake
SnowFlake的结构如下(共64bits，每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
| ———————-|———————- –|– –|– —–|——
1bit不用 41bit 时间戳 数据标识id 机器id 序列号id
- 1位标识，二进制中最高位为1的都是负数，但是我们生成的id一般都使用整数，所以这个最高位固定是0
- 41位时间戳，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下下面程序IdWorker类的startTime属性）。41位的时间截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69
- 10位的数据机器位，可以部署在1024个节点，包括5位dataCenterId和5位workerId
- 12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号
- 加起来刚好64位，为一个Long型。