2015/11/09 第393期

电脑程序员不配被称作工程师

用批判的眼光来看这篇奇文。其他领域工程师需要从业资格认证才能上岗,而程序员通过自学也能动手“改变世界”(嫉妒吧?);其他领域的工程师做高质量的东西(如桥梁,大楼),而程序员做充满bug的软件。

Distribution is 80% of Your Problem

文章提出了 app 分发渠道的一个思考框架:你的app的模范用户是怎样的,尽量具体(计算机系大学生,还是互联网公司ceo)?到哪里找这些模范用户?解决模范用户的痛点,口碑营销,让他们帮你宣传。

“Without real word of mouth, there is no scale”

社交阅读 app Flud 验尸报告

2013年的老文章了。这种阅读类(rss,社交)的 app 层出不穷,前仆后继的。用户对手机阅读的需求很大,但这些华丽的 app 都没解决最本质的问题:高质量的内容。

我的一点幼稚的想法:在阅读app里引入社交的元素,似乎是不错的想法,因为理论上朋友们会互相推荐好文章,你也就能看到好文章了。但问题是,一个人在线上的品位是由真实生活中的个人素质决定的,你follow的那些“朋友”如果现实生活中是阿猫阿狗,他们能在线上推荐出什么好内容?

何时向新技术说 no

工程师们都喜欢把玩新技术,各种酷炫的新的web编程框架,各种新语言,各种 nosql。但在公司里引入新技术要谨慎。这是Stripe的工程师写的,某些情况下可以安全地尝试新技术,比如开发环境里引入新工具;某些情况下要小心谨慎,或者尽量避免引入新的技术,比如数据库方面。

如果想在 production 中换掉某个关键的系统,比如数据库,那可是浩大的工程,不是一拍脑门就能换的:数据迁移不容易,监控,报警,logging,参数调优,备份,出错处理等都得考虑仔细了。团队还得集体学习一下新技术。很多人不理解,认为这是保守的态度,不与时俱进 -- 吃过几次亏后就能理解了。

Netflix 从 AWS 故障中学到的教训

写于2011年,这应该是 Netflix 迁移到 AWS 后经历的第一次 AWS 大规模故障了。本文总结了面对这种故障,Netflix哪些地方做得好,哪些地方需要改进。

这些宝贵经验对于越来越依赖于 cloud 各互联网公司都挺有借鉴意义的。同时Netflix这种开诚布公的,公开透明的沟通,乐于分享实战经验的精神,也是值得学习的。