记录我过去一周看到的值得分享的东西，每周四发布。
随笔
坚持一件事有多难
我当初立志每周写一篇分享，这才过了不到三个月，就已经 delay 两回了……
坚持做一件事说难也难，总有各种各样的事情突然出现延误了计划；说简单也简单，比如我坚持每天吃饭睡觉已经二十多年了……
希望我之后能尽可能的坚持下来吧。
那个受用户喜爱的百度已经回来了！
百度：真香！
疯狂扩张的瑞幸咖啡
在刚刚过去的 2018 年，瑞幸咖啡疯狂烧钱扩张，平时上网总能看到关于瑞幸咖啡的新闻。但令我感到奇怪的是：绝大部分新闻都不看好瑞幸咖啡。最令我感到奇怪的是：不看好瑞幸咖啡的新闻们，彼此之间相似度极高，总是用同样的几个论据来写文章。
我和瑞幸咖啡没有任何利益关系，只是一个感觉他们咖啡还挺好喝的吃瓜群众。瑞幸咖啡在 2019 年是成功也好，倒闭也好，说实话和我关系不大。但当时 ofo 受到了那么多的关注和支持，最后还是倒了。
所以得出结论：写文章的那批人其实都是复读机，第一个人怎么写他们就怎么写。
新闻
GitHub 宣布为免费用户提供个人仓库功能
GitHub 宣布免费用户可以创建无上限个私有仓库，与付费的私有仓库相比，免费的私有仓库最多只能添加三个协作者。
论坛里，机智的网友们已经开发出了 GitHub 的网盘功能。coding 和 gitee 瑟瑟发抖。
GitHub 添加当前状态标签
GitHub 添加了状态标签，用户可以标记自己的状态，比如：工作中、度假中、生病了等等。如果设置了自己的状态为 Busy 的话，那么其他人在提及自己或者分配任务的时候就可以看到自己的状态。
技术杂谈
反向代理下的静态资源缓存
我在以前的博客中提到过静态资源 304 的好处，减少流量消耗、加快页面访问等等。如果你使用了 Nginx 作为静态资源服务器的话，那么默认情况下 Nginx 就会帮你处理 304 的情况。
但如果你的 Nginx 是作为反向代理，而你的后端有多台服务器的时候，问题就会变得复杂起来了。稍大的网站都会有不只一台服务器，那么，当浏览器端有某个静态资源的缓存时，用户又发起了一次对这个文件的请求，如果这个请求被反向代理到了另一台服务器，而两台服务器上的文件修改时间不一致时，缓存就会失效。
我大概想了两种解决的方案：一是修改为基于文件哈希的 ETag 来进行缓存判断，二是同步多台服务器上的文件修改时间。
Git 如何删除历史提交记录
很多同学在使用 GitHub 时，会不小心把自己的密码传上去；或者不小心传了一个巨大的文件。此时就可以通过删除 git 的历史提交记录来解决这个问题。
洛谷自动 AC 机
这位同学写了一个可以自动 AC 洛谷题目的代码，其原理大概是用 C++ 的宏定义绕过了洛谷的安全检查。
说实话，任何基于字符串匹配的安全检查都是自欺欺人，限制 C++ 的库引入也是做无用功。一个较为安全的评测姬应该至少做以下几种限制：
- 编译、运行 CPU 时间限制
- 编译、运行墙上时钟时间限制（防止 sleep 卡评测）
- 内存限制
- 运行用户权限限制（防止破坏操作和读取敏感数据）
- 文件访问权限控制（防止读文件 AC）
- 系统调用限制（防止 fork 炸弹、网络调用等）
其他的限制，可以考虑上容器。即使用户代码真的破坏了评测环境，也可以快速恢复，不至于被卡很久。
【洛谷日报#32】洛谷第四代评测系统技术分析
在被攻击后，洛谷不甘示弱，上了新一代评测系统。
但这个文章并没有涉及多少有关技术的东西，看起来更像是回应挑衅 + 示威。
Python 字典长度与哈希冲突的问题
前阵子我遇到了一个问题，需要用 Python 在内存中维护一个索引，用于加快查询。
键共有三种，当时有两种思路：一种是将对三种键的查询散列生成一个二进制串，然后用这个二进制串做键去存储和查询；另一种思路是直接建立三层的字典。
本来我以为，第一种应该快于第二种的，因为第二种要查询三次才能出一个结果，而第一个只需要一次。而且因为散列过程都是位运算，应该会很快才对。但结果让我很惊讶：十万数据量的情况下，第二种方法比第一种快接近二百倍！
后来看了很多博客才明白为什么，这里就直接放结论：因为 Python 的字典的查找方式可能会出现冲突，多个键从右往左相同的越多，冲突就会越厉害。
使用标签时，你可能会忽略的一个安全问题
这个是我之前从来都没有想过，但是细思极恐的一个问题。
表情包
送你们的新年特辑
