水滴石穿－第三期

不积跬步，无以至千里；不积小流，无以成江海

作者谈他为何觉得Instagram是最好的社交应用，主要是以下三点：

简单
- 信息简单：Instagram以纯图片的方式传递，没有超链接，没有一大段文字
- 操作简单：点赞或者只是浏览。
安静不打扰用户，用户用完即走。这和之前张小龙演讲提到的观点是一致的。
无限制社交

Instagram的定位并不是密友社交。并顺带举了path失败的例子，密友社交不是需求，真正的密友社交是一对一的，而不是一个密友圈。

People like social networks because they’re an efficient way of communicating with many others, but, as he said, “efficiency is the enemy of intimacy.”

“Real intimacy can never, ever be broadcast. It must be either one-to-one or one-off,”

所以你在Instagram上看到不同圈子的照片，你可以有自己的解读：

You can skip inside jokes. You can miss subtext that pricks someone else’s hearts. You can savor the density of meaning in pictures from close friends and the surface beauty of posts from distant ones.

How To Choose a Profitable Niche

作者提出具备好商机的app有下面三个条件：

Is profitable 如何确定是否有潜在的利润？作者这块分析的结论没看出来。
Can be found via App Store search 找到用户搜索的热词，了解用户需求。
Has crappy competitors 竞争对手比较烂。

9 daily habits of successful mobile app entrepreneurs

如何做好一个app？可以参考下该文章提出的几个习惯：

Study the App Store：了解用户的评价，排名趋势和排序算法。
Learn From The Horrible Apps：分析优秀的app和糟糕的app之间的差别。
Answer Support Calls & Emails (Even as a CEO)：回复咨询电话和邮件：每天花部分时间亲自回复用户的咨询，即使你是ceo。
Consume Something Inspirational：读些motivational的书，听听ted talk，保持积极向上的心态。
Write EVERYTHING Down：好记性不如烂笔头。
Benchmark Your Data：紧盯数据趋势（评分，用户评价等），确保走在正确的方向上。
Inbox Zero：及时回复邮件。
Keep a Journal：“I use journaling as a form of therapy and as a way for me to start each day with a clean slate.”

Slack is the Operating System Slack is the Operating System

对于大多数新的app来说，slack是一个操作系统。在slack上运作一个app，它是跨平台的，实时同步的，并且界面一致，对用户友好。

Designing for messaging will become a discipline as important as responsive design, and will incorporate skills as diverse as copy writing, business analytics and API programming.

We’re going to call it Messaging Experience Design, or MXD.

Messaging is the New Web

Web的优点在于易部署易扩展易分发。而在智能手机兴起的大背景下，Messaging应运而生。

Messaging (in a very broad sense including SMS, texting apps, and things like Slack) present a similar challenge and opportunity today in the context of smartphones.

回复信息/文本会话相比起app来说要轻量得多，比起打开浏览器，输入url再等待页面展示也更近方便。同时登陆认证对于用户来说是透明的，用户不需要额外申请账户，也不需要额外学习新的操作界面。

If integration with Slack is cheap and easy and provides additional distribution for business services, more services will be incentivized to offer it, which in turn makes Slack more valuable for its customers. And when Slack’s customers have a host of services integrated with their Slack instance, the more valuable Slack becomes to them

The Future of Asynchronous IO in Python

这篇没怎么看懂，欢迎交流。

Making sense of MVP (Minimum Viable Product) — and why I prefer Earliest Testable/Usable/Lovable

深度好文！文章最后的总结如下：

Avoid Big Bang delivery for complex, innovative product development. Do it iteratively and incrementally. You knew that already. But are you actually doing it?
Start by identifying your skateboard — the earliest testable product. Aim for the clouds, but swallow your pride and start by delivering the skateboard.
Avoid the term MVP. Be more explicit about what you’re actually talking about. Earliest testable/usable/lovable is just one example, use whatever terms are least confusing to your stakeholders..

以下是精华摘抄：

We start with the same context — the customer ordered a car. But this time we don’t just build a car. Instead we focus on the underlying need the customer wants fulfilled. Turns out that his underlying need is “I need to get from A to B faster”, and Car is just one possible solution to that.

We might learn some really surprising things. Suppose the customer says he hates the skateboard, we ask why, and he says “I hate the color”. We’re like “uh…. the color? That’s all?”. And the customer says “Yeah, make it blue! Other than that, it’s fine!”. You just saved alot of money not building the car! Not likely, but who knows?

The key question is “What is the cheapest and fastest way we can start learning?” Can we deliver something even earlier than a skateboard? How about a bus ticket?

In most real-life product development scenarios I’ve seen, no matter how much up-front analysis you do, you’re still surprised when you put the first real release into the hands of a real user, and many of your assumptions turn out to be way off.

Early feedback from real users! Don’t just design the product and build the whole thing.

Pleco: Building a Business, not an App

What stands out to me about Love’s approach was that from day one his differentiation was not based on design, ease-of-use, or some other attribute we usually glorify in developers. Rather, he focused on decidedly less sexy things like licensing. Sure, licensing is particularly pertinent to a dictionary app, but the broader point is that Love’s sustainable differentiation was not about his own code. Sustainable differentiation never is.

This is the critical point: developers all want to write an app for themselves, which means everyone has. That’s why there is no money to be made in something like an RSS reader. But there are whole swathes of people out there who have really interesting and specific needs — like Chinese language learning — just waiting for someone who can not only develop, but can also do market research, build a business model, and do all the messystuff upon which true differentiation — and sustainable businesses — are built.

如何设计社交产品的后台架构？

存储
- Master Data or Static Form of Data Like User Profile 选择document based storage，推荐mongodb。优点：分布式／高可用／可分库分表。
- Connected or Relational Data 选择图数据库，推荐Neo4j，但是其不支持分库分表。其他选择：FlockDB, AllegroGraph 和InfiniteGraph。
- Binary data (UGC) 推荐Amazon S3
- Session Data
- 用户相关，推荐redis。
索引 Apache Storm用于实时生成索引。Lucene（性能不够）或SolrCloud做索引系统。
Queuing & Push Notifications 使用ActiveMQ做队列，push通知可以采用pyapns, CommandIQ 或App Booster。
缓存策略
- Application Level Caching (Content Cache) redis。
- Proxy Cache Nginx 或ATS。
- Second Level Cache (Code Level Caching) EhCache。
- Client Cache 客户端做缓存。
传输协议 http客户端采用OkHttp，消息传输采用MQTT。
安全 All our user data must be encrypted

MongoDB and Neo4j already supports Storage Encryption. On case basis we can decide to encrypt key user information. Transport Encryption must be enabled for all DB related calls.
- Secure Socket Layer SSL
- All our api endpoints should be run on non default ports and should implement Oauth without fail
- All reads from DB should happen through rest endpoints always
- The configuration which holds password must be dealt specially
模块整个后台架构包括以下模块：
- Load Balancer：负载均衡
- Proxy Server：处理http请求，包括cache策略
- Ingestion Engine：处理输入数据，包括缓存，转码，压缩
- REST Server: 访问db
- Event Processor: 从ActiveMQ读取消息并通过notification engine生成push通知。
- Recommendation Engine: 根据用户操作，做些推荐相关的算法。

How We Release So Frequently How We Release So Frequently

如何快速发布？作者提了下面几个快速发布的准则：

Forward-only Migrations 不允许回滚数据库的Migrations。

Take dropping a column as an example; how do you release that change? Easy: Release a version of the code that doesn’t use that column; ensure it is stable / won’t be rolled back. Do a second release that has a migration to remove the column.
New Code != New Features 用户应该对你代码的发布无感知。

It’s a really bad experience for customers to see a new feature appear, start using it, and then have it disappear a few minutes later as a release is rolled back — possibly for unrelated reasons

Every new feature is first released in a hidden state, ready to be turned on with a ‘feature toggle’.

There are some really strong plus points to this approach:

We don’t have to roll back a whole release (which may contain several changes) just because a single new feature isn’t working
We can fully test new features in an environment that has the exact hardware, software and data we need
We can release new features to customers gradually

文中介绍了利用session和cookie来实现灰度升级，有兴趣可以仔细阅读下。

Small Releases The more often we release, the smaller the releases can be. Smaller releases carry less risk, letting us release even more often.