最近折腾 Kafka 的迁移和高可用时，两次碰到了这个坑，所以专门记下来并分享下，就是 __consumer_offsets topic 的 replication factor 一定要大于 1，具体可以看上边链接的文章，讲得非常清楚了。另外再说一个我自己碰到的误区吧，Kafka 停止的脚本是 kafka-server-stop.sh，但是脚本执行完后 server 是要经过一个清理的过程才会停的，所以如果看进程还在的话要等一会儿，不要着急着直接杀进程，否则可能会丢失数据，而且下次再启动时恢复又要好长时间了。
非常天才的一个音乐制作人，最近听了他的几首歌都非常喜欢，特点是曲调优美，忧伤中带点激昂，可能是比较契合我现在的心绪吧；另外就是动听婉转的女声，听着也很享受。几首代表作 Faded、Sing Me to Sleep、Alone、Darkside 我都挺喜欢的，可能在审美方面，大家的欣赏品味都趋同吧。
Python 核心开发者为 Python 性能问题辩护的文章，里边讲了些常识性的道理，比如要权衡开发的效率和快速原型迭代等；以及当要优化时可以采取的步骤和方法等，值得看一下。当然反对者也是有理由的，比如 PyPy 很多人总认为无法用到生产环境，也不大会去尝试；另外一些现代的静态编程语言比如 Go、Rust，它们本身的语言表达能力和简洁性也做得很好了，所以可选择的范围也多了。
新语丝上关于着凉与感冒的科普，能纠正很多人的看法：
现在，科学界对着凉与感冒的关系已经基本清楚：普通感冒是由感冒病毒导致的急性上呼吸道感染，寒冷的环境能促进感冒的发生（通过增强病毒在体外的生存时长、增加病毒感染的机会、降低呼吸道细胞对病毒的免疫力等），但着凉本身和感冒基本无关。
文章主要是从研究的历史的角度来讲的，看着还蛮有意思的，能知道科学研究的严谨和论证的充分性。如果仅仅是想看科学道理的话，还可以看方舟子之前写的这篇短文“感冒”并非“伤风”
一对工程师和设计师夫妇创业做的产品反馈 SaaS 产品，还记得3年前分享过他们的文章，这次再看到总结还是很欣喜，喜欢这种简单纯粹的成功。确实还有许多公司像他们一样沿着类似的路途行进，但却未必成功了，所以那些看似简单的道理实践起来却未必容易，学学别人的经验，看看有哪些值得借鉴的地方挺好的。
作者分析了经济学人杂志转型过程中所采取的一些方式，横向对比了一些类似的传统新闻媒体。总之结果还不错，但我觉得因为幸存者偏差的存在，适合别人的未必就适合你，不过可以借鉴它们的经验和获得启示，对从事媒体行业以及对媒体感兴趣的人们。
Sip 是他们做的一个科技新闻摘要的产品，过程和经历挺有意思的，对于信息流类似的产品都可以参考。他们最后总结了几点：
去中心化、可扩展一开始就要置入产品里
关注指标数据，和宏观态势
实际执行总是比预期的时间要长
作者站在工程师和公司的角度分别阐述了编码面试的利弊，公司方面主要是基于成本考虑，提高门槛，避免误判；而工程师呢，则面对买方的市场，必须按游戏规则来，闯过一道道关卡，证明自己，虽然成本也很高。
作者设想让第三方来客观提供对工程师的统一测评，减少双方的成本，同时加上公司方面的特殊用人需求能力考察，来解决这个问题，然而这只是理想的情况。所以怎么办呢，现状就是工程师还是好好准备吧，通过了是能力的体现，没做好也不必气馁，毕竟它只是一次测验，不代表工程和项目能力。
当然，找工作对个人来说是件大事，找到适合自己的长期工作，避免切换的巨大成本。