谈笑风生又一年 又到一年年底了， 2020 对所有人来说都是不平凡的一年，从年初的美国刺杀苏莱曼尼、科比坠机，到年底的特朗普下台、中欧投资协定谈判的完成，贯穿其中的则是人类的公敌——新冠病毒。至于其他的事件诸如加州山火都是小事。 但既然题目叫『我的 2020 』，这里就不再谈论这些大家已经耳熟能详的各种事件，只是简单记录一下自己这一年的变化。 工作 由于新冠疫情的爆发，公司于三月初开始全员在家搬砖，可以说这个决定来得正是时候。去年年底公司被收购，在大概两个月的过渡期之后，原公司的各种硅谷标配福利被母公司砍得所剩无几，最明显的就是每天的免费午餐不再提供了，公司周边的馆子动辄十几块一顿，作为穷苦人家实在吃不起，正发愁以后如何找借口午饭之后再去上班，恰好公司下令全员居家，自己做比下馆子可便宜多了，虽然麻烦些，但趁着做饭吃饭收拾的时间正好能从繁忙的工作中休息一下。 聊完了午饭的问题，在居家工作
最近 Netflix 又出品了一部新剧，并在豆瓣上获得了 9.0 的高分，叫《后翼弃兵》。讲的是从小在孤儿院长大的主角拥有着不凡的国际象棋天赋，在她的天赋被发现挖掘之后一路走到了国际象棋世界冠军的故事。说到国际象棋，作为一名程序员，自然而然就想到了计算机的经典问题——八皇后问题。 所谓八皇后问题，就是在 8×8 的国际象棋棋盘上放置八个皇后，使得彼此之间不会互相攻击。一个皇后的攻击范围是皇后所在的行、列、和两条对角线上的所有位置，可以看成是加强版的中国象棋中的『車』，这就要求每两个皇后不能在同一行，不能再同一列，并且不能再同一条对角线上。维基百科上给出了一些可行解，例如下图所示，棋盘上有八个皇后，而这八个皇后互相攻击不到对方。 <figure> <figcaption> 八皇后问题的一个可行解 </figcaption> </figure>
调度场算法由 Edsger W. Dijkstra 发明，用于将中缀表达式转换成后缀表达式，即逆波兰表达式。写过程序的同行都了解，对于计算机来说，一个后缀表达式更容易被理解和计算，所以当处理我们看起来更习惯的中缀表达式时，例如 (3 + 4) * 5 - 2 * (3 + 9) ，往往会将其转换成 3 4 + 5 * 2 3 9 + * - 的形式，这样只需要一个栈结构就能得出正确结果 11 ，代码简单到什么程度呢？只要稍微有些数据结构知识的码农，都可以很快写出类似下面的代码。 def calculate_reverse_polish_notation(tokens): stack = [] for token in tokens: if token == '+': stack.append(stack.pop() + stack.p
2021/02/15 更新 由于微博的原因，导致 IFTTT 从微博上抓取内容的 OAuth 接口无法使用，所以上述方法暂时失效了，并通过 IFTTT 客服了解到，因为联系不上微博方面修复这个问题，所以他们也不知道何时才能恢复。 正文 本文需要一定的 Python 编程基础以及 AWS 使用经验。 因为同时拥有微博和推特账号，所以很多时候同一条内容既想发到两个平台上，又不想两个平台之间来回复制粘贴，之前尝试用 IFTTT 来做内容同步，即把一条新微博同步到推特上去，但效果不是很理想，比如说无法区分原创微博、转发微博和带图微博，这样导致三者同步过去的样子是一致的，要么都不带图，这样带图微博的图片就丢了，要么都带着图，纯文字微博的情况就直接放一张默认的『 image not found 』，要多难看有多难看，而转发微博会把整个转发链都搬上去，而里头的内容很可能没什么营养，除了污染推特粉丝的时间
Bitcask 是 Basho 公司设计研发的一款高性能键值数据库，基于日志文件的形式来管理数据，在设计文档中，他们声称实现了数据存储查询的『多快好省』，并且也有许多实践中的案例证明他们确实做到了这一点，例如，豆瓣自主研发的 BeansDB 也在很大程度上借鉴了 Bitcask 的设计思想（他们最近又用 Go 重新实现了一个版本），并用于他们线上服务。文档并不厚，只有简单的六页，所以花一点儿时间通读一遍，学习一下 Bitcask 的设计思路对研究开发自己的存储系统是大有裨益的。 在运行时 Bitcask 把所有数据存在硬盘上，每次写的时候就把数据追加到末尾，所以在性能上能达到媲美内存的速度。 Bitcask 会维护一个 file handler 指向当前正在写的文件，收到写请求就直接把数据追加在当前文件的末尾，而删除动作会写进去一个特殊标记，记录对应的 key 在这次操作中被删除。而读的时
