2014/09/28 第54期

Secret 团队推出另一个神秘的 app

原链接

Secret 推出名字叫做 Ping 的神秘 app。 大概的idea是,你选几个感兴趣的主题,然后 ping 会在一天里的不同时段给你推送消息。推送的消息跟你一开始选的主题有关,有点人工智能的东西在里面:
Ping will “evolves and adapts to you” over time, so it’ll be interesting to see how it unfolds in the coming days.
这个 Ping app 以后会慢慢变成像 iPhone 上的 Siri 一样的东西吗? 估计两周后国内的克隆品也会上线。一周做,一周等 app store 的审核,刚好两周 :)

Startup 和大公司的比较

这是 Facebook 的 Product design director 写的。

Make something valuable enough that people will actually use it

这是 startup 最主要的目标(唯一目标?)。除此之外,员工培训以及各种福利都是未来的事情了。毕竟时间和钱都有限,得投资到该投资的地方。有一次电话面试一个在某知名大公司工作多年的人,最后问他有什么问题要问我没有,他就把 Google + Facebook + Twitter + 各种大公司 + 他自己杜撰的员工福利给我过了一遍,反问我,你们有这些吗?你们能报销员工的电话费吗?你们能报销员工家里的上网费和有线电视费吗?你们能每年提供几千刀的休假旅游经费吗?--- 有意思吧。。。

为什么要在经济萧条的时候也能创业

这篇文章是 Paul Graham 写于2008年金融危机的时候。

If we've learned one thing from funding so many startups, it's that they succeed or fail based on the qualities of the founders. Which means that what matters is who you are, not when you do it. If you're the right sort of person, you'll win even in a bad economy. And if you're not, a good economy won't save you.

也就是说,他认为创业跟经济环境没太大关系。猪还是猪,牵到北京还是猪。关键是看人。 但 Investors are more of a problem. Evernote 就是在08年的时候拉不到钱,差点倒闭。

The immediate cause of death in a startup is always running out of money.

这就是最近各个风投大佬所担心的事情:现在的 startup 烧钱太快,泡沫可能马上破灭。

抛弃教条,Facebook 在硬件上的创新

文章讲了 Facebook 的硬件团队自己改进他们数据中心中的电脑硬件。他们会观察数据中心里的人怎么换硬盘,然后思考如何才能让这个过程变得更轻松更快。
When you don’t think about maintenance, it shows and we’ve all dealt with equipment with way too many small screws and poor placement. 
虽然讲的是硬件的事情,但道理也是适用于软件开发的。写代码是很容易的事情,但运维很难。代码写好了放在 server 上跑,要考虑如何监控、如何安全重启、如何安全地处理各种常见的错误(比如某个外部的 API 突然连不上了)。很多互联网公司的软件工程师都要 oncall,这是很好的事情。只有你自己写的程序出了问题,把你半夜吵醒了,你才能切身体会到运维的麻烦,然后才能思考如何写更好的代码。 以前好几次 oncall 的时候,我半夜起来,还得抱个电脑登陆服务器,各种操作,相当繁琐。然后干脆找了一个周末,写了个小的 monitoring daemon,再用 jquery mobile 写了个界面,以后再遇到这种问题,直接躺在床上用手机按个按钮解决问题。

Wealthfront的持续部署系统

这篇文章比较老了,2010年发的,讲了我前面几期很推崇的 continuous deployment 的基本思路。 文中说他们从提交代码,到部署到 production 只需要 4 或 7 分钟。我在想,部署这么快,可能是因为他们在 service oriented architecture 上做得很好。每个 service 都比较小,所以每个 service 都能有独立的 deployment schedule,每个 service 进行的测试相对较少,把代码打包起来(比如打包成 debian package 之类的)的时间比较少。 现在公司里坐我旁边的同事以前在 twitter 工作了几年,他说他们部署一个 infrastructure 的 service,需要 1 个多小时 — 这个数字可能过时了,他的记忆可能还停留在几年前。twitter 也是一开始各种 ruby 的代码缠成一坨,所谓的 monolithic architecture。这样每次进行小小的代码改动,都要重新部署整坨的代码,一打包就要打包所有的代码并安装所有的 dependency — 现在他们作为已经上市的2000人的大公司,应该有足够的人力资源,全力转向 service oriented architecture 了。