最近 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 在这次操作中被删除。而读的时
最近和家里领导一起刷完了日剧《无法成为野兽的我们》，作为社畜大军一员，这部剧的每一集都让我产生了无比大的触动。看这部电视剧，关注的重点不应该是剧里演出来的那一部分，而是没有说的部分。最后的结局看似喜剧，但每个人都无法逃离。 剧中唯一能被称之为『野兽』的大概只有橘海寺和他的妻子橘吴羽，活得那样坦然纯粹，丝毫不在意其他人的眼光，顺其自然，无拘无束，也不必向世俗低头，但这一切的支撑是他们手里的公司和产业，他们有足够的经济实力去无视这些自己不喜欢的东西，因此他们获得了足够的自由，活成了剧中的朋友们、也包括剧外的观众们羡慕的样子。绯闻又怎么样？记者发布会又怎么样？他们可以毫不客气地回敬过去。 回到男女主角身上，晶过的可以说是我们认知中非常典型的社畜生活，早上六点半起床上班，要忙到天黑才回家，因为同事们的不给力，水平高责任心强的她只好能者多劳，同时还要承受着更加工作狂的老板的训斥与压榨。在整个故事中，
