- 安静 不打扰用户，用户用完即走。这和之前张小龙演讲提到的观点是一致的。
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,”
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.
- Is profitable 如何确定是否有潜在的利润？作者这块分析的结论没看出来。
- Can be found via App Store search 找到用户搜索的热词，了解用户需求。
- Has crappy competitors 竞争对手比较烂。
- 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.”
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 (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.
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
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.
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
- 索引 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: 根据用户操作，做些推荐相关的算法。
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
- Small Releases The more often we release, the smaller the releases can be. Smaller releases carry less risk, letting us release even more often.