IT瘾facebook推荐

来自Facebook的一些MySQL运维经验

Sun, 21 May 2017 00:12:18 CST

1. 概要

每台机器都使用多实例的模型。每个机器放多个实例，每个实例放多个DB。

一些信息可以参考： https://www.youtube.com/watch?v=UBHcmP2TSvk

多实例之间没有进行资源隔离，这么做是让每个实例都能发挥最大性能。

目前大部分核心业务已切换成MyRocks引擎，在机器硬件配置不变的情况，约可节省一半机器。

放在MyRocks上的核心业务主要有：Feed、Post、社交图谱等读写混合业务。

MyRocks项目地址：https://github.com/facebook/mysql-5.6

另外，MariaDB 10.2版本也即将整合MyRocks引擎。

2. 高可用机制

采用基于GTID的一主多从结构，外加一个基于lossless semi-sync机制的mysqlbinlog实现的binlog server（可以理解为MySQL 5.7的loss zero replication）。

基于多数派实现自动选主。

基于配置中心实现切换，未使用VIP。

在认为semi-sync复制可保证主从数据一致性的假设前提下，发生故障切换时，利用上述的binlog server中的日志进行补全后再选新主、切换。

若个别情况下由于特殊原因，出现从库全部挂掉的情况，会将全部请求切到主库，由它扛起所有的业务服务压力。

某个从库挂掉时，可以动态摘除。

3. 备份机制

所有的备份都是基于mysqldump实现，之所以采用mysqldump逻辑备份好处有：

无需备份索引，只备份数据；
备份文件压缩比高，更节省磁盘空间；
改进了mysqldump，备份过程中还进行额外压缩；

上面提到，因为采用多实例、多DB结构，备份时可以多DB并行备份。当然了，也会控制并行备份的数量，避免影响在线业务性能。

备份放在集中存储（HDFS）上，据说已达EB级别容量。

关于备份的作用定位：

供数据分析环境拉数据
供灾难恢复

4. 如何快速部署从库

可使用xtrabackup在现有存活的SLAVE实例上备份，也可在主库上发起备份，再利用WDT（或者是BT）协议传输到异地，用于拉起从库。

关于WDT项目：https://github.com/facebook/wdt

5. 高度自动化

面对大规模的数据库实例，手工处理完全不现实。目前在facebook主要是利用Python开发内部DB运维平台，所以Python技能方面要求比较高。

采用他们自已的osc工具执行Online DDL（也是本次DTCC大会上lulu的分享主题），它最早用PHP开发，虽早已开源，但实在不好用，所以几乎只在内部使用。这个工具不同于pt-osc，相对来说更有优势，比如可以避免使用pt-osc最常遇到的主从数据延迟问题。

项目地址： https://github.com/facebookincubator/OnlineSchemaChange

6. 团队结构及技能树

DBA团队更多的是负责私有DB云平台的建设。

Schema设计及DB拆分等由性能优化团队负责。

在线表结构变更：数据库资源申请由质量服务团队负责，做到资源的合理分布、分配，如果某个业务只需要个位数级别的DB实例，可以自行在私有DB云平台中申请部署，当数量比较大时，需要先经过质量服务团队评估通过。

数据库资源申请由质量服务团队负责，做到资源的合理分布、分配。如果某个业务需要小量DB实例，可以自行在私有DB云平台中申请部署；当数量比较大时，需要先经过质量服务团队评估通过才可以。

文章来自微信公众号：云DB

浅谈移动应用的跨平台开发工具（Xamarin和React Native）

Mon, 06 Jun 2016 12:35:26 CST

谈移动应用的跨平台开发不能不提HTML5，PhoneGap和Sencha等平台一直致力于使用HTML5技术来开发跨平台的移动应用，现在看来这个方向基本算是失败的，基于HTML5的移动应用在用户体验上与原生应用仍然存在着明显的差距。

与上述HTML5平台不同，Xamarin和React Native通过各自的方式来实现跨平台。Xamarin基于Mono框架将C#代码编译为原生平台代码，React Native则是在UI主线程之外运行一个JavaScript线程，两者呈现给用户的都是原生体验。

笔者恰巧两个平台都各使用过一段时间，在这里就抛砖引玉，分享一下个人观点。对于资源有限的创业团队，如果熟悉JavaScript，使用React Native再加上React，Redux等技术可以实现移动端、Web端、和Service端整套系统的开发，还可以重用一部分代码（比如Reducer和Action中的业务逻辑，以及通用的JavaScript组件代码），React Native也非常适合快速原型的开发。对于实力相对雄厚的大中型公司，如果已经在使用Microsoft的.Net技术，并且拥有成体系的系统架构，那么Xamarin或许是一个更好的选择，架构设计得好的话在代码重用方面并不逊于React Native。

下面从几个方面说一说两者各自的优缺点：

从编程语言的角度来说，C#和JavaScript都是成熟的主流编程语言，都有丰富的第三方库和强大的社区支持。两种语言都能够实现从前端一直到后端的整套方案。

从开发工具的角度来说，Xamarin Studio的表现只能说刚刚及格，有种和Xamarin整个产品线不在一个水平的感觉，特别是重构和界面可视化编辑等方面还有很大的改善空间，并且在版本升级中经常会引入新的BUG，让笔者多少有点患上了升级恐惧症。React Native本身没有IDE，开发人员可以选择自己熟悉的JavaScript IDE，比如：IntelliJ等。

从第三方库的角度来说，Xamarin的第三方库给人一种不多不少、刚好够用的感觉。在IDE中集成了Xamarin Component Store以后，第三方库的数量质量都有了提升，开发人员使用起来也非常方便。如果遇到特殊情况需要自己开发或者绑定（binding）原生代码库时可能会比较麻烦一些。React Native则完全依赖于JavaScript社区，NPM和GitHub，在需要自行开发和桥接（bridging）原生代码库时个人觉得比Xamarin容易一些。

价格方面，Xamarin有免费版本，但在应用包尺寸上有限制。对于企业级开发最好还是选择它的Enterprise License，虽然价格不菲，但是可以获得技术支持和使用平台的其他产品（如：Xamarin.Forms和Xamarin Test Cloud）。React Native则是完全免费的。

至于学习难度，很多人对JavaScript缺乏信心，觉得这门语言很难掌握和用好，而C#和Java则相对容易安全得多。这里笔者推荐图灵的《你不知道的JavaScript》系列，看过之后也许能够改变这一看法。除了JavaScript语言，React Native还需要掌握Facebook的React框架，它是React Native的核心。Xamarin要求掌握C#以及iOS和Android开发的相关知识，虽然使用React Native并不一定要求会iOS和Android开发，但是对于移动应用开发者来说，无论使用什么工具、怎样跨平台，了解各个平台的架构设计还是非常必要的。

下面是对两者各方面的一个总结：

不足和纰漏之处还望各位不吝赐教，欢迎交流讨论。

欢迎关注CoolShell微信公众账号

（转载本站文章请注明作者和出处酷壳 – CoolShell.cn ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

应用分发当年的大戏要重演了，只是这一次主角变成了新媒体内容

Sat, 29 Aug 2015 09:00:39 CST

如果给两三年前中国互联网上竞争最激烈的领域排个名，应用分发一定会占一个；而如果数一下中国互联网当下以及接下来会变的竞争异常激烈的领域，内容分发也一定会算一个。

说到应用分发大家应该都挺熟悉，各类应用下载商店应该是见得很多了；但说到内容分发可能就要解释一下了，毕竟这个词以前的意思和我要表述的其实并不太一样。在当下，由于科技公司越来越多的介入，内容从媒体到读者之间的传播路径正在发生非常大的变化，那些有着过亿用户的科技产品已经成了重要的内容展示渠道，更重要的是，它们开始用技术手段来影响媒体的哪些内容能被读者看到，以及读者看到的是什么。

媒体内容当下的变化趋势

在国外，Facebook、苹果都已经开始介入到媒体内容分发领域；在国内，今日头条、UC 浏览器、英威诺、一点资讯以及豌豆荚一览同样在做着影响内容传播路径的事。按照一位业内人士的说法，从下半年开始，内容渠道领域的竞争会变的非常激烈。

其实，无论国外还是国内，这些积极介入到媒体内容领域的科技公司的一个共同点就是：它们自己都不是内容的生产者，它们做的事更多是用技术或者产品的手段介入到媒体内容和读者之间，改变已有的媒体内容传播路径、分析并影响读者的阅读习惯。

拼图依次是：今日头条、豌豆荚一览、UC 浏览器

当然了，在这个大的共同点下，各家的做法也各有各的不同：

Facebook：Facebook 在 5 月份推出的 Instant Articles 让媒体可以直接发布自制新闻内容，它的载入速度更快，并且还可以通过算法为用户推荐感兴趣的文章；

苹果：苹果在 iOS 9 中内置一个 News 新闻阅读 app，利用算法和人工编辑一起为用户提供可能感兴趣的内容。

今日头条：这个阅读应用主要在做三件事：媒体内容抓取、算法个性推荐、收编内容作者也就是自媒体。

UC 浏览器：浏览器也开始做个性化内容阅读了。在新版的 UC 中，只要在主屏幕向上一划，它立马就变身成了一个今日头条。按照 UC 浏览器总经理朱挺的说法，App 的竞争真的结束了，内容的纯粹性、内容的依附性越来越变成一个竞争的优势。

英威诺：它做的事情和今日头条很类似，最大的区别就英威诺直接和手机厂商合作，酷派瀑布流、华为悦读、联想小知、天语语知，这些内容产品背后都有英威诺的身影。简单说就是直接预装在手机里。

豌豆荚一览：一览和上面这些应用不同的是它是通过应用内搜索技术抓取各个应用内的内容，这包括新闻资讯，但又不仅限于这一类，像豆瓣、Instagram、什么值得买之类的也都是一览抓取的对象。

看完上面的案例之后不难发现，无论大公司还是创业公司都已经挤到内容分发这个领域中来。大公司往往是希望借内容增加已有产品的粘性，创业公司则是寻求新风口下的成功机遇。

为什么会出现这种变化？

说起来，媒体内容其实是个挺古老的东西，它为什么突然就成为科技公司的焦点了呢？在我个人看来，这和当下互联网线上服务创新乏力不无关系。

看看这半年多以来美国的科技公司在研究什么？汽车、虚拟现实、机器学习、无人机、帮更多的人接入互联网；中国的科技公司呢？大多都在想着怎么把线下服务互联网化；而至于聚焦在线上产品方面的创新，其实非常少，就像我的一位同事在硅谷呆半年回来后也说那边能感受到比较有意思的服务其实挺有限。

虽然线上服务本身的创新正在面临瓶颈，但用户倾注在手机上的注意力却并没有减少。这个时候针对已有服务的优化自然也就变的更加关键。想一想，你的手机里，既能吸引大量用户的注意力，又能让科技公司的技术有足够的释放空间的，媒体内容自然可以算得上比较靠前的那一类。

这对媒体来说是一件好事吗？

媒体的内容纷纷被科技公司看中，这对经常被看衰的媒体产业来说是一件好事吗？其实并不一定。

首先，那些内容主要靠转载、更新量少的媒体在这一波内容变革中会首先被冲击。有了个性化的内容聚合和分发平台后，这样的媒体品牌对用户的价值会越来越小，相应的，也难以再获取新的用户。

其次，对于原创的媒体来说，这类产品也可能会削弱媒体本身的品牌。因为，当用户在 UC 浏览器上看到一篇 PingWest 品玩的文章时，他和别人提起时自然会说是在 UC 浏览器上看到的，而不会说是在 PingWest 品玩上。

最后，当然就是人才争夺了。像今日头条正在努力签约自媒体，一些员工被要求每周找 5 名自媒体作者开头条号。未来，今日头条会直接向这些作者提供利益分成。这样以来，媒体的人才难免会被分流一部分。

当然了，对于媒体公司来说，让技术参与到内容分发中也不是没有好处。利用这些公司的技术手段和用户量优势，某些内容可以获得更多的阅读量，作者也可以通过跟踪数据变化来生产更符合用户口味的文章。这些方式相当于让内容产业也有了获得快速增长的机会。

总结来说，由于技术和产品的因素越来越多的介入到内容传播之中，这件事往上看会影响到上游的内容生产者，往下看也会影响到下游的读者。这些科技公司之间的竞争将在接下来极大的影响到整个产业链条上的每一个参与方。应用分发当年的大戏正在重演，只是这一次主角变成了新媒体内容。

题图来源：站酷海洛创意

Presto 来自Facebook的开源分布式查询引擎

Tue, 14 Jul 2015 20:52:24 CST

PrestoDB 来自Facebook的开源分布式查询引擎

Presto是一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。下图中展现了简化的Presto系统架构。客户端（client）将SQL查询发送到Presto的协调员（coordinator）。协调员会进行语法检查、分析和规划查询计划。计划员（scheduler）将执行的管道组合在一起，将任务分配给那些里数据最近的节点，然后监控执行过程。客户端从输出段中将数据取出，这些数据是从更底层的处理段中依次取出的。

Presto的运行模型和Hive或MapReduce有着本质的区别。Hive将查询翻译成多阶段的MapReduce任务，一个接着一个地运行。每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。然而Presto引擎没有使用MapReduce。它使用了一个定制的查询和执行引擎和响应的操作符来支持SQL的语法。除了改进的调度算法之外，所有的数据处理都是在内存中进行的。不同的处理端通过网络组成处理的流水线。这样会避免不必要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。这样的方式会大大的减少各种查询的端到端响应时间。

Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。

Presto特点：

完全基于内存的并行计算
流水线
本地化计算
动态编译执行计划
小心使用内存和数据结构
类BlinkDB的近似查询
GC控制

扩展性是在设计Presto时的另一个要点。在项目的早期阶段， Facebook就意识到出了HDFS之外，大量数据会被存储在很多其他类型的系统中。其中一些是像HBase一类的为人熟知的系统，另一类则是象Facebook New Feed一样的定制的后台。Presto设计了一个简单的数据存储的抽象层，来满足在不同数据存储系统之上都可以使用SQL进行查询。存储插件（连接器,connector）只需要提供实现以下操作的接口，包括对元数据（metadata）的提取，获得数据存储的位置，获取数据本身的操作等。除了我们主要使用的Hive/HDFS后台系统之外， Facebook也开发了一些连接其他系统的Presto 连接器，包括HBase，Scribe和定制开发的系统。作为Hive和Pig（Hive和Pig都是通过MapReduce的管道流来完成HDFS数据的查询）的替代者，Presto不仅可以访问HDFS，也可以操作不同的数据源，包括：RDBMS和其他的数据源（例如：Cassandra）。目前已经被支持的RDBMS有：MySQL、SQLServer、PostgreSQL等

WebUI

1、AirPal（推荐）

AirPal是AirBnb开源的查询Presto的WebUI。项目特性：

可选的用户访问控制
SQL语法高亮
查询结果导出到CSV文件，或者存到Hive表中
可查看SQL查询的历史记录
可保存查询
根据表名搜索对应的表
可查看表结构，并预览前1000行数据

项目地址 https://github.com/airbnb/airpal

2、Shib

Shib是Treasure Data员工TAGOMORI开源的查询Hive、Presto、BigQuery的WebUI。

项目地址 https://github.com/tagomoris/shib

3、Hue

Hue本身是不支持查询Presto的，但是可以通过以下的方法使其支持查询Presto： https://medium.com/@ilkkaturunen/integrating-presto-with-hue-61702b244839

4、yanagishima

这是一个奇怪的英文名字，因为是一个日本人起的，来自东京的软件工程师wyukawa。项目特性：

安装简单（无需安装RDBMS）
易用，与MySQL Workbench类似
使用本地存储记录独立的查询历史
可以为查询添加标签
可以查看历史查询列表
可以Kill正在运行的查询
可以格式化查询语句
可查看表信息（列、分区）
查询结果保存为TSV文件

项目地址 https://github.com/wyukawa/yanagishima

其他参考链接：

Presto 官网： http://prestodb.io/
Presto Github 主页： https://github.com/facebook/presto
京东修改版（推荐）： https://github.com/CHINA-JD/presto
Presto 文档： http://prestodb-china.com/docs/current/

转载请注明：标点符 » Presto 来自Facebook的开源分布式查询引擎

Instagram: 2年10亿美元背后的技术架构

Fri, 03 Jul 2015 16:28:35 CST

转自： Archfan

参考： Instagram的技术探索

Instagram是一款免费照片分享移动应用，目前支持IOS和Android。在1年多的时间里，Instagram发展到140万个用户，1.5亿张图片(几个TB)，仅有3个工程师，以10亿美元的天价被Facebook收购。不得不说，Instagram是业界的一个神话。今天我们就来看看到底是什么样的技术架构支撑着这个10亿美元的公司。

Instagram团队之前发表过一篇文章： What Powers Instagram:Hundreds of Instances,Dozens of Technologies。这篇文章中提到的技术架构堪称经典，很适合初创项目的快速启动。

这个小团队使用了很多不同的技术和策略，保证他们能轻松的应付快速增长带来的压力。他们混合使用SQL、NoSQL，一堆开源项目，和云服务；云服务他们选择了Amazon，他们认为Amazon要比他们自己部署IDC更有优势；用异步队列来串联组件；系统架构在众多的对外API和内部Services之上；数据存储在内存和云端；大部分代码是动态语言；等等等等。非常时髦的一个架构，基于这个架构之上他们得以快速前进，并且保持精简。

那篇文章非常值得一读，有兴趣的同学可以直接看原文。这里我列出一些要点：

架构原则:1.保持简单;2.不重复造轮子;3.尽量使用成熟稳定的技术
3个工程师
大量使用Amazon服务，工程师不用耗费时间自己维护服务器
100+个EC2实例用于各种用途
Ubuntu Linux 11.04(“Natty Narwhal”)，他们认为这个版本更加稳定
Amazon的ELB(Elastic Load Balancer)路由请求，ELB后面起了3个Nginx实例
ELB上关闭了SSL，因为它降低了CPU的使用率
DNS使用Amazon的Route53
25+个Django应用服务运行在High-CPU Extra-Large类型的机器上
CPU使用比内存使用更加容易达到边界值，所以使用High-CPU Extra-Large的实例来平衡内存和CPU
Gunicorn是他们的WSGI服务器。Apache更难配置，更耗CPU
Fabric被用来在所有机器上并行执行命令。部署花费更少的时间。
PostgreSQL(存储用户，照片元数据，标签等)运行在12个Quadruple Extra-Large Memory实例上
12个PostgreSQL副本运行在不同的节点上
PostgreSQL的Master-Replica使用流复制模式，利用EBS的快照来频繁备份
EBS部署在软件RAID上，使用 mdadm以获取适当的IO
将所有工作中的数据集存储在内存中，因为EBS每秒磁盘寻道次数有限
Vmtouch(轻量级的文件系统缓存诊断工具)被用来管理内存数据，尤其是当故障转移时目标机器没有足够空余的内存
用XFS做文件系统，保证数据快照时RAID阵列上数据的一致性
Pgbouncer用作 PostgreSQL的连接池
有几个TB的照片存在Amazon S3上
用Amazon CloudFront做CDN
Redis用来支撑feed，活动消息，session系统和其它服务
Redis运行在几台Quadruple Extra-Large Memory实例上，偶尔也会做下切分
Redis也是Master-Replica，副本持久化到磁盘上，并由EBS通过快照备份（这么搞是因为他们发现直接在Master上做dump相当吃力）
Geo-Search使用Solr，Solr提供的JSON接口也很简单易用
6个memcached实例做缓存，因为Amazon Elastic Cache服务并不便宜，mmc客户端使用pylibmc和libmemcached
Gearman用做:向Twitter,Facebook等平台异步分享照片；新照片发布的通知；feed的反送
200个Python进程处理Gearman的任务队列
Pyapns处理超过10亿条Apple的push通知，异常稳定
Munin用做监控和系统度量工具，用 Python-Munin写了很多图表插件，如每分钟注册人数，每秒钟图片发表数等等
Pingdom做内部服务的监控
PagerDuty用来处理通知和事件
Sentry用来做Python的错误报告

以上就是Instagram的博文里面提到的技术要点，怎么样，准备好构建下一个10亿美元的应用了么？

您可能也喜欢：
Sun 10大技术创新	Java 技术的发展	SOA & Web Services: 概念, 技术,工具	BEA的Java虚拟化技术白皮书
无觅

Facebook创始人扎克伯格亲自审查核心代码

Mon, 12 Jan 2015 16:32:41 CST

导语：美国科技博客网站 BusinessInsider 今日撰文揭开了 Facebook 程序设计人员的神秘面纱。Facebook 代码从开始编写到最终发布，都有着极为严格的程序，CEO 马克·扎克伯格(Mark Zuckerberg)甚至对 News Feed 每个代码更新亲自把关，确保不出现任何差错。

工作中的扎克伯格

Facebook工程师是这家社交网站巨头最有价值的财产，他们拥有非常大的自主权，但同时也面临着尽快发布高质量代码的压力。

谷歌 (微博)员工李易(Yee Lee)通过与大批Facebook工程师的交谈，在一篇博文中披露了Facebook代码发布流程。这个流程的确与外界之前想象的相差无几，虽然Facebook对代码发布的监督比人们预想的更为严格。尽管这篇博文发表于一年前，但整个流程自Facebook上市以来似乎并未发生太大变化。

Facebook员工主要由工程师构成，人数最多的两个团队分别是Engineering和Ops，总计占了Facebook员工总数的一半左右。此外，Facebook还有大量产品经理。他们要确保代码按时发布。每一个产品经理负责7到10名工程师。

Facebook所有工程师都要接受4到6周的培训，学习Facebook修复漏洞的方法，聆听资深雇员举办的讲座。在进入“训练营”(Boot Camp)的工程师当中，会有大约10%无法顺利通过测试，最终被劝退。

接受完培训以后，工程师开始接触Facebook数据库。他们可以随意核对代码，对数据库做出修改。员工们还会拿到一张“禁做之事”名单，如禁止分享用户数据。尽管如此，Facebook还出台了一系列措施，防止此类事情的发生。

同谷歌一样，Facebook的企业文化同样以工程师为主。一名工程师说：“产品经理基本上在这里毫无作为。”工程师可以修改尚未正式上市的产品规格，在任何时间提出新的功能创意。

工程师会在每月一次的不同团队例会上提交他们的成果。产品推广经理和产品经理会出席这些会议，但不被鼓励畅所欲言。“如果产品经理在例会上畅所欲言，工程师们就会向领导层反应说，‘上次会议上他们有关产品的意见太多了’。”

在Facebook，工程师想做什么，基本上都由他们自己决定。他们会找到主管，说：“这是我想做的五件事情。”产品经理会说服工程师当场试一试，让他们亲身体验这些项目的效果，但他们多数情况下不会对每位工程师的偏好横加干涉。

工程师们不会争论某项功能是否值得尝试，而是开发出原型机。接下来，工程师会用一周的时间开发某项功能并进行测试，以确定它是否值得推出成品。通常情况下，新功能都是由Facebook员工亲自测试。整个过程由一款名为“Gatekeeper”应用控制。这是Facebook“黑客”文化的主要组成部分——快速开发和推出产品，淘汰没有市场前景的产品。

在Facebook，每个人都想参与后端产品的开发。可伸缩性和基础架构是工程师最感兴趣的两个问题。所以，工程师很难对实时消息等前端产品感到兴奋，相反，每个人都希望从事像News Feed算法这样的后端产品。这种做法与其他消费类科技企业的惯例背道而驰，在这些企业，员工都希望参与前端产品的研发工作。

Facebook 创始人兼CEO马克扎克伯格(Mark Zuckerberg)会亲自对News Feed每个代码更新把关。在Facebook，所有重大升级的代码都进行强制评估，任何一个改动都至少由一人把关。但是，无论工程师对News Feed做出任何改动，都将由扎克伯格亲自把关。

Facebook工程师负责测试产品功能，修复产品漏洞，对发布以后的产品进行维护，但他们并不是官方的质保团队。不过，Facebook仍然有负责质量评估的工程师，并积极鼓励每位工程师报告产品漏洞。

正常情况下，代码升级会在每周二发布。Facebook有专门的评估工具，告诉工程师代码更新的风险有多大。

运营团队会逐步推出代码更新。Facebook共有大约6万台服务器，运营团队会逐步将更新后的代码发布到少数几台服务器上，确保它能起作用。最开始是6台服务器，接着慢慢增加。如果需要做出修改，那么这项工作会由提交代码更新的工程师在线下完成。修复工作完成后，代码会再次在那6台服务器上先试用，接着增加到更多的服务器上。

在代码更新发布期间，运营团队会通过IRC和其他实时聊天工具一对一通知工程师，他提交的代码是否需要修改。如果修复以后的结果仍然难以令运营团队满意，当事工程师会被“当众羞辱”，虽然李没有提供有关这方面的具体细节，但他说如果这种情况经常发生，工程师会被炒鱿鱼。

新媒体最重要的三件事：分享，分享，还是分享

Sat, 14 Feb 2015 14:52:00 CST

我每次与媒体朋友聊天，话题总离不开媒体的现状与未来，看衰者、对未来出路不确定者居多。由于这个原因不少人离开了媒体行业。最近与一位不在媒体工作的朋友交谈，我总算意识到为什么当前的大多数媒体都走偏了。其实新媒体的出路就在那里，但大家都视而不见。

如果做新媒体只需要关心一件事，那就是：分享；如果做新媒体需要关心三件事，那就是：分享，分享，分享。请原谅我重复，因为它太重要了，在这个喧嚣的媒体环境里，我得多强调几遍大家才能意识到。

互联网和移动互联网正冲击着一切，而媒体行业是被冲击得最早，也是最厉害的行业之一。

媒体受到的第一波冲击来自搜索引擎。Google出现前，每个人都生活在不同的信息高墙之下，你的信息环境决定了你能接触到什么样的信息；Google出现之后，你几乎可以在几秒钟内找到任何想要的信息。这时候，阅读的主动权更多地倾斜到读者手中：他不再受信息渠道的限制，从而有权选择全世界的内容为自己的喜好服务。

这种变化对平面媒体是一次大的冲击。平面媒体的内容制作是线性、规整的，头版、二版、八版……放什么内容，都有明确的设定。搜索引擎和门户网站的出现，则打破了这种制作逻辑：一篇文章在搜索引擎中的排名、在门户页面中的位置，决定了它的影响力，如果头版文章不被选用，媒体预期它能产生的影响力也随之消解。这种标准的改变从影响媒体内容制作，逐渐波及到媒体的生存——2013年、2014年很多优秀的平面媒体开始感受到广告收入的大幅下滑。这时，新浪微博等社交媒体开始流行。

媒体经历的第二波冲击，就是社交网站。在美国是Facebook，在中国2010年—2013年是新浪微博，2014年以后是微信朋友圈。为简化描述，这里只谈Facebook与微信朋友圈，它们是社交媒体时代典型的内容分发引擎。

三个月前我曾写过，媒体内容必须免费，因为它与社交网络是一种共生关系。在Facebook和微信朋友圈看朋友吃了什么、玩了什么，用户的视野是极为有限的，媒体内容的加入，则能让人在了解小世界的同时，知晓大世界。从企业价值角度看，优质内容可以为社交网络提高用户粘性，增加DAU（日活跃用户数）与平均停留时间。对了，社交网站还可以在内容中推销广告——这已经是Facebook最重要的收入来源。

社交网站的流行，对微信公号以外的媒体意味着：内容制作、内容分发及商业模式这三个核心环节的第二次推倒重建。衡量一篇文章影响力的标准变成了：能不能被用户分享。而分享的关键在于下面这三件事：

1、你是否有监测热门内容以及预判趋势的能力，这不是刷刷自己的朋友圈就能解决的；

2、如何不断优化内容。每个标题都可以有两种甚至五种写法，怎么判断哪个关键词更容易引发流行？

3、内容分发与商业模式，该如何调整？

BuzzFeed是一个不能忽视的案例，它的模式解答了90%的疑问。

当前国内的新媒体们基本上还是在依赖内容编辑，这种模式能保证内容质量和基本的话题性，但远没到能被分享的程度。对热门内容的判断，机器的效果更好。BuzzFeed最早上线的一个产品是BuzzBot，就是专门用来监测和判断网络上热门内容的。

优化内容一直是非常难统一标准的事情，过去基本上依靠编辑的主观判断，但每个编辑对好内容的标准都不一样，甚至在极端情况下会让媒体难以形成合力，内容产品化也就无法执行了。国内很多新媒体都意识到内容需要产品化，但至今没有看到谁对“产品化”做出技术上的定义和实际操作的标准。一个人物访谈栏目算是产品吗？一个与互联网行业相关的科技博客是产品吗？一个新闻客户端是内容产品吗？仔细分析下来真挺痛苦的。同样是大佬的节目，我喜欢看库克的访谈，但可能对马云的兴趣就谈了很多。一个人物访谈栏目，很难说得上是一个产品，甚至说不上是一个功能(feature)，因为不是用户每次访问都会用到。

有一个简单且被业界普遍接受和采用的方法可以快速验证产品可行性。那就是当你不知道一个产品是否能被用户接受时，开发一个MVP（Minimum Viable Product，即最简可行产品）就好了。那么在媒体，什么是内容产品的MVP？在我看来，其实就是单篇文章。每一篇文章，它是否被打开、阅读、分享，都在为以后制作同类文章的标题、导语、内容、展示方式、篇幅等建立最基本的模型，收集反馈，提出改进方向。BuzzFeed在一定程度上做着这样的产品设计和迭代工作。每一篇文章，他们都可以发布两个标题去做A/B测试，测试完后，依靠数据就可以知道标题用哪个关键词更容易击中用户痛点。优化内容不再凭编辑的主观标准，一切靠数据说话，这些数据在后台能逐步升级迭代，且经验可累计。在系统面前，老编辑和新编辑拥有同样的话语权。

当你以能被分享的标准去制作内容时，分发途径就显而易见了——依靠社交网络。在国外是Facebook，在国内就是微信朋友圈。BuzzFeed有超过50%的流量来自Facebook。张小龙曾披露过用户在微信上的阅读偏好：80%通过朋友圈阅读内容，20%去订阅号挑内容阅读。所以，如果现在做微信运营的第一指标还只是看粉丝的增长，而不是看分享人数，那就完全错了。因为分享决定了你80%的影响力。

写到这里，依靠制作分享内容的媒体商业模式也就清晰了：原生广告。我们先看看Facebook的商业模式。

Facebook 90%以上的收入来自广告。目前它的广告形式有三种：PC页面右侧的广告栏，PC信息流广告以及移动端信息流广告。移动端的信息流广告收入已在Facebook的总广告收入中超过了66%。Facebook的移动端信息流广告还有一个特点：点击率要比PC端高出187%，点击成本却低了22%，广告单价也要更高。桑德伯格对移动端信息流广告单价更高的解释是：用户的互动性更高。这挺好理解，能被分享的文章，本身是具备互动性的——分享本身就是一个互动的行为。以上说明在以分享为标准的媒体平台，具备已被验证可行的商业价值。

短短十几年面对两波大的冲击，身处媒体行业的人不难受是不可能的。但与很多人的悲观和看衰不同，我认为媒体有大爆发的可能。新浪通过门户的方式，奠定了中国互联网媒体的产品原型，但在今天它的生产力已经落后了。新生产力的出现，往往能比旧的生产力产生10倍的效果，而这在BuzzFeed身上已经发生了。（在这里我们先不考虑在BuzzFeed制作严肃新闻的内容团队，因为严肃内容是做品牌和口碑的，不是做用户量的。）BuzzFeed制作清单体的内容团队为50人，目前它的估值为8.5亿美金；新浪门户的内容团队超过1000人，市值24亿美金。也就是说，BuzzFeed用1/20的员工，创造了相当于新浪市值的1/3，生产力已接近10倍的提升。

BuzzFeed的中国门徒微在毫不讳言自己就是要学BuzzFeed，以个人阅读趣味来看，我很难接受微在的内容，哪怕是朋友圈里被人分享出来，也几乎不会去点。不过我的个人趣味一点都不重要，重要的是，如果你去微在看一下热门文章的浏览量，还是有点让人出乎意料的：平均每天都有一篇阅读量在10万以上的文章，每周能有一篇20万或30万以上的文章，日常文章的阅读量还有不少在3万—8万之间。可以说，微在找到了让内容被分享的感觉。

很多人瞧不起BuzzFeed，觉得它无非是一个猫猫狗狗的网站，但问题是为什么不是其它猫猫狗狗网站做成了近十亿美元的媒体？

雷军说，他做小米唯一搞错的地方，是一开始以为小米是一个百亿美金的生意，后来才意识到原来是千亿美金的生意，创业时少估计了一个零。这其实代表了，顺势而为本身就是多一个零的生意。放在媒体，这个“势”就是分享。分享等于10倍生产力。

（文章首发于《商业周刊/中文版》。文章一开始提到的朋友是张宁Neo Zhang，文章很大程度上是因为受他的启发，致谢。他也有一个非常好的公号Platform Thinking，欢迎订阅。）

【相关链接】

媒体将成为互联网基础服务：
http://dajia.qq.com/blog/446675061360505

张小龙：微信80%的用户在朋友圈阅读内容
http://mi.techweb.com.cn/news/2014-12-11/2105721.shtml

Facebook移动广告解读
http://tech.qq.com/a/20150116/015200.htm

桑德伯格解读Facebook移动信息流广告
http://tech.qq.com/a/20140424/025039.htm

BuzzFeed最初上线的产品BuzzBot，专门用来监测和判断网络上的热门内容

http://www.businessinsider.com/buzzfeed-jonah-peretti-interview-2012-12

2014 Q4 Facebook分享占美国网民分享总量的81%

http://www.199it.com/archives/325851.html

师北宸的微信公号：digital_meme，欢迎关注。

为什么移动搜索产品都那么糟糕？

Tue, 17 Jun 2014 08:00:42 CST

即使放到现在来看，我们依然可以说，移动搜索还不算是太成功的那一类产品。

一方面，用户的搜索习惯正在从PC向移动设备延伸，高达90.4%的用户会在手机上使用搜索功能；另一方面，用户并不喜欢移动搜索产品，高达61.4%的用户觉得在手机上搜索比在PC上困难得多。（数据出自： Serch Engine Land）

于是，你可以看到这样一个怪象—— 搭了“传统互联网没落”便车的移动搜索产品在获得大量用户的同时，却仍然没有找到一个真正被移动互联网用户所接纳的产品形态。用户并不怎么喜欢移动搜索产品，他们之所以还在用是因为不得不用。而以Siri为代表的语音搜索也没能真正改善移动搜索体验，只有区区18.5%的用户认为语音搜索提高了移动搜索体验。

除了通过引入新的交互模式来改善移动搜索的产品形态，搜索服务商们将搜索结果内容结构化，而非提供一堆链接。另一方面，随着互联网内容逐渐向移动应用内转移，应用内内容的搜索也开始变得越来越重要。

Google在2013年12月开始支持应用内的内容索引（App Indexing），他们希望借此将应用内容与各个网站进行连接，使得Google搜索结果能够提供应用的Deep Link（深层链接）。在搜索结果内展示应用内的内容，需要开发者做两件事：更新应用，增加对Deep Link的支持；将应用的Deep Link提供给Google。

在中国，豌豆荚则是另一家较早涉足应用内搜索的公司，他们从2013年8月开始做应用内搜索的第一个产品——视频搜索。今年3月，豌豆荚上线了“ 应用内搜索技术协议”，在推出自己标准的同时兼容Google的App Indexing标准和Quixey的AppURL标准。他们希望合作伙伴将自己的应用内容接入到豌豆荚里，让用户能够搜索到应用内容。

Deep Link是支持应用内搜索的一个必要环节。“我们应用内搜索这个事需要有几个环节，第一件事是我们需要知道内容在哪里，因为内容都是在一个一个应用信息孤岛里面，我们需要想办法把内容从信息孤岛里面拉出来。第二步我们需要知道怎么消费这个内容，怎么消费内容就跟Deep Link有关。”豌豆荚搜索技术负责人李大海对PingWest说，“比较通俗地说， Deep Link就是描述我们怎么展现，怎么打开，怎么处理应用里面的内容。”

但Deep Link仍然不够普及。根据李大海向PingWest透露的数据， 在最热门的1000款应用里，真正友好支持“调起”的应用不会超过20家。这意味着，绝大多数开发者需要对自己的应用进行修改来支持对Deep Link的支持。

“早期的时候，所有开发者更关注自己的业务，‘调起’只要能工作就好了，不太关注这个事情是不是满足规范，因为这完全是内部行为。现在的现实是，很多开发者虽然自己的产品体验比较好，但是‘调起’这块情况非常糟糕，甚至完全不支持对外部的”调起”，有一些还会刻意的说我就不允许外部‘调起’。这会给外部‘调起’带来很大的困难，甚至产生很多无形当中的障碍。”李大海对PingWest说。

这些对“调起”并不那么在意的开发者，在制造了一大批不合乎标准的应用的同时，也给应用内搜索的实现制造了障碍。

于是，你会发现 在App Store里的应用越来越多的同时，移动搜索不管是在体验还是对应用内搜索的支持度上都没有相应地跟上。最明显的例子是，Google的App Indexing上线半年以来接入的第三方应用不足百家，豌豆荚上线应用内搜索SDK三个月以来接入的应用为30家——要知道他们收录的应用数量已经超过了150万个。

（Facebook的App Link介绍）

不仅如此， 各家的应用内搜索技术标准还处于各自为战的混乱状态。除了Google的App Indexing、Quixey的AppURL外，Facebook最近也上线了自己的标准App Links。虽然方案很多，但是应用内搜索还没有形成统一的标准，也缺少一个像W3C这样的中间机构来出面统一标准。

“传统互联网发明了hyperlink（超链接）以后才开始变得宽广起来， 但是移动互联网最早基于的是应用，信息的流动不是一开始考虑的重点。随着内容也转移到手机上，内容的流动和容易被发现变得越来越重要，信息孤岛限制了信息的自然流动。“李大海对PingWest说，“每个厂商都希望从自己的角度出发解决问题。例如，Google把网页和应用结合在一起，是因为他们更熟悉网页内容。“

为什么移动搜索产品都那么糟糕？你可以拿“标准的不统一”“开发者的不在意”和“交互模式的落后”来解释。从互联网的发明到基于超链接的万维网的出现经历了约二十年时间，但愿在移动互联网时代，我们不必经历那么长久的等待。

题图出处： shutterstock

新闻阅读器Paper对Facebook有多重要？

Tue, 28 Jan 2014 12:37:18 CST

根据Re/code的报道，Facebook将在几周内发布类似Flipboard的阅读应用Paper，不仅如此，他们称 Facebook正在招募编辑来为内容做人工筛选。

Paper是Facebook的秘密项目，用户可以利用Paper阅读到来自传统出版物的内容、好友状态更新和Instagram照片等内容。看上去，它就是一个具有社交功能的聚合阅读器，与Flipboard很接近。该项目已经在Facebook产品副总裁Chris Cox的管辖下进展数年，期间产品形态发生了多次改变。

Paper的内容采编完全来自于编辑团队，这意味着Facebook完全以算法驱动个性化展示动态新闻的时代终结了——在过去，Facebook依靠你和你社交网络的加权信号来决定展示哪些内容，但在Paper应用上，内容展示的决定权从算法转移到了编辑的手中。

这种从算法推荐到人工推荐的模式看上去似乎是一种倒退，但其实并不尽然，目前我们所能阅读到的优质报刊杂志仍然在采用人工编审这种看似古老的模式。通过算法进行个性化推荐和编辑推荐不过是两种不同的内容推荐模式，不存在绝对的替代关系，毕竟你现在还很难让机器具备人类那样的品味、感性、审美等能力。

Paper对于Facebook而言是一个非常重要的产品。他们在这个产品上已经有多年的投入，他们还不惜放弃使用内容推荐算法也要组建编辑团队来进行优质内容的采编，这已经清楚地表明了他们并不想像“办一场黑客马拉松一夜间复制出一个Snapchat”那样再来复制出一个Flipboard。

Paper的出现，意味着Facebook所扮演的角色正在从社交网络巨头进一步向内容分发商渗透。尽管Facebook原本也具备内容分发的特性，但一个专门针对新闻阅读的应用的推出，将会极大地改善富媒体的阅读体验。编辑筛选能保证内容质量，更好的富媒体阅读体验则意味着更“豪华”的广告效果。

对于出版商来说，Paper凭借着Facebook的13亿月活跃用户比Flipboard更有吸引力，很有可能成为一个更好的内容分发渠道；对于Facebook自己来说，优质的内容能够让用户在他们的服务上停留更久。

接下来，Facebook要做的事就是如何跟出版商打交道。他们目前还没有向出版商详尽解释与Paper有关的内容合作，但既然Facebook要在Paper上展示来自传统出版物的内容，这道坎无论如何也得迈过去。

WhatsApp日消息420亿条，值190亿

Thu, 20 Feb 2014 13:27:48 CST

2月20日，大洋彼岸的一则并购案例在神州大地被主流媒体报道和传播，引发了广泛的关注和热议。“Facebook190亿美元收购WhatsApp”这条新闻是美国两家公司之间的并购，虽然这笔并购对互联网行业来说是大新闻，打破了该行业最高的并购记录(美国在线和时代华纳的实际并购不属于互联网行业并购)。

但“ facebook收购WhatsApp”毕竟这是国外的并购案例，为何会引发包括中国在内的全球主流媒体的聚焦关注?其主要原因就在于WhatsApp是一款通讯类软件，这款软件经过短短4年的发展，已经成为全球最主要的沟通工具之一，全球用户使用该软件发送的消息单日超过420亿条!

知名调研公司Analysys Mason近日发布报告称， 2013年全球短信发送量仅为6.5万亿条，相对于每日不到180亿条的规模，这个规模显然和WhatsApp一对比，已经大大的落了下风。一款全球消息发送量超过全球短信的软件，其命运和去向自然引发了所有人的关注。

我们先来看一组数据：

根据速途研究院最新的数据显示，在2011年10月份的时候，WhatsApp单日消息发送量仅为10亿条，到了2012年8月份就达到了惊人的100亿条。然而100亿不是瓶颈，随着智能手机和移动互联网在全球的高速发展和普及，到了2014年2月，WhatsApp单日消息发送量达到了创纪录的420亿条，也就是说仅仅WhatsApp一个软件的消息发送量就已经两倍于全球短信的消息发送量。

众所周知，社交软件类的用户忠诚度和留存比例要远高于电子商务、游戏等产品的用户，让我们来看看WhatsApp月活跃用户的增长走势图。从上图来看，WhatsApp在2011年10月份只有5000万的注册，当时的5000万用户体量的产品在中国互联网都比比皆是。随后，在2012年8月，WhatsApp月活跃用户达1.4亿，又过来一年到了2013年8月，活跃用户突破了3亿大关(注：按照腾讯的历次财报，微信在2014年月活跃用户才会超过3亿)。3亿对于WhatsApp来说还不算最高值，在2013年下半年WhatsApp迎来了真正爆发的时间，仅仅过来半年，也就是在2014年2月，WhatsApp月活跃用户达到了4.5亿

在Facebook宣布用现金和股票总计190亿美元收购WhatsApp之后，业内专家普遍认为190亿美元的价值对于一个初创公司来说过高，WhatsApp难以匹配这样的高估值。不过，笔者认为，从未来移动互联网的发展趋势来看，190亿美元对WhatsApp的估值反而过低，原因主要有以下几点：

第一：就仅仅通过信息发送量这一项来看，WhatsApp估值就远远不止190亿美元。短信在2013年创造的价值是1300亿美元(注：此项数据是英国市场调查公司Portio Research发布)，而WhatsApp已经两倍于短信的消息发送量，相信到了2014年甚至2015年以后，本来就走下坡路的短信从量级来说更不是WhatsApp的对手，参照之下WhatsApp的估值会更高。

第二：WhatsApp不仅仅是一个通信类产品。对于WhatsApp来说，发送消息只是一个最基本的功能，就如同中国的微信一样，除了消息发送还可以借此布局游戏、支付、打车、电子商务、O2O等其他领域。

第三：WhatsApp和Facebook可以相辅相成。WhatsApp如果独立发展，非常有可能成为Facebook的颠覆者，显然Facebook也已经看到这一点，要及早的把WhatsApp扼杀在摇篮里，但与其说是把WhatsApp扼杀，反倒可以说WhatsApp可以和Facebook相互配合，相辅相成。Facebook强于社交，WhatsApp强于移动信息沟通，这两个搭配就好比中国的人人网和微信的搭配一样，双方如果能找到好的平衡点，未必不能实现更高的突破。

总结：也不排除WhatsApp被收购后，因为内部的一些原因造成左右互搏式的内耗，手机QQ和微信的案例历历在目啊!

(本文作者系速途研究院院长丁道师微博：@丁道师微信：dingdaoshi )

190亿收购WhatsApp，Facebook的焦虑症

Thu, 20 Feb 2014 13:44:43 CST

一大早在上班路上朋友圈就被一个消息刷了屏，Facebook一狠心花了190亿美金收购WhatsApp让整个互联网业界沸腾人民奔走相告就差喜极而泣了。虽然想不到这事儿跟他们有什么关系。

很多人都觉得Facebook是疯了，这么大一笔巨款收购一个似乎没多少营收的通讯应用。不过这大多是因为“190亿”整个数字实在是太吸引眼球而已。盘算一下WhatsApp到底值不值这个钱，很容易就可以说清楚。

WhatsApp在2009年推出，至今5年时间，目前月活跃用户数为4.5 亿，其中70%的日活跃，屌炸天好吗？相比之下，被成为可以“再造一个腾讯+移动互联网船票+移动互联网入口+超级APP”的微信在2013年11月公布月活跃用户数才超过了2.7亿。其次，作为社交通信工具的超高用户粘性和使用率。许多人用之前收购Instagram来比较，社交通信需求相比分享的需求，这两个真不是一个量级的事儿。说多一句，Snapchat 这么让人追捧，也是因为其被作为通信工具使用。然后，WhatsApp极其成功的全球化，其在拉美和欧洲的覆盖达到恐怖的地步，Facebook自己做基本没希望。另外WhatsApp仍在快速增长，而且用户年轻化明显。

为什么我觉得这个价格还便宜了呢。如果单纯用数字说话，你这么牛X的WhatsApp才这么点估值，你让微信情何以堪。当然两者相差甚大，不可以这么简单地进行比较。

所以，收购这事儿其实就是，你有的他没有，只能花钱买了。无论是马克·扎克伯格从接触WhatsApp到决定收购只用了11天，还是狠心用了190亿美金，这些数字都只是反映了目前Facebook的焦虑症而已。从很久以前开始，除了Facebook自身推出的应用或服务就缺乏创新缺乏吸引力，尤其在移动端的产品更是让人无语，还曾推出过山寨Snapchat的Poke这种失败产品，稍有亮点的Instagram也是收购而来。

在知乎上的一个答案，就很能说明目前Facebook遇到的问题。答案链接请戳这里。

Facebook其他功能日子都不好过，帖子变成灌水的，满页无意义的转贴加上LoL。要么就是在Group里背地长舌。照片看得人也不多，毕竟一堆炫耀自己旅游经历的相册远远不如Twitter或者Vine转发的有意义的照片吸引人。

Instagram已经过时了，美国互联网界流行的速度比Taylor Swift换男友的速度还快，最近不是又在流行Snapchat吗？Facebook想买Snapchat人家还不卖呢!

Facebook还有一些其他的问题：

1、很多学校，公司封锁Facebook，因为老板老师觉得Facebook影响工作学习效率。

2、一些中老年人（No offense 大于30岁的人差不多都算了）的入侵，让Facebook上最主要的活跃人群，年轻人（30岁以下）觉得Facebook很Lame，毕竟难道你喜欢你老爸老妈注册Facebook然后假扮你的朋友监视你的活动状态？

3、很多人离开学校后就没有时间用Facebook了。

4、社交游戏做得也不成功，但是还能靠API从热门移动游戏厂商吸引一些人。

5、Facebook的广告，数据挖掘和营销引起了许多用户的反感。

6、Facebook的主要活跃用户因为年龄原因消费能力并不算太强。

看完了这些问题，你有没有觉得Facebook其实跟国内一个社交网站很像？尤其是第三点。嗯，说得这么明显，相信大家都知道了，就是人人网。分享的内容无意义，离开学校后不再使用，社交游戏不成功，逐渐失去年轻用户。而且自身创新乏力，没有办法推出酷炫的新产品吸引用户，移动化转型不顺利。对人人网和Facebook来说，这些都是很严峻的问题。

不过两个网站最大的不同点是，人人网病入膏肓了仍毫无办法，甚至连挣扎一下都做不到，就只能慢慢等死。而Facebook目前仍算正当盛年，并能很快地意识到自己的短板在哪里，并舍得花大价钱快速补充自己的短处。从这个方面来讲，Facebook的焦虑症还真不算是坏事。

事实上，Facebook这次的收购很快地让我想起了昨晚刚刚看过的电视剧里的一个情节：

（若无特别注明，雷锋网文章皆为原创，转载请注明出处)
原文链接: http://www.leiphone.com/190-b-whatsapp-facebook.html

2013 年 Facebook 在开源方面的工作回顾

Tue, 24 Dec 2013 11:16:17 CST

自从 Facebook 的第一行PHP代码，第一句 MySQL 的 INSERT 语句，开源就已经是我们工程哲学中的一个重要的部分。

现在，我们使用、维护并为大量的主要项目做出了贡献——涉及多种领域如手机工具、大数据系统、客户端的web库、后端的运行库和基础架构，也涉及到开放计算项目，服务器和存储硬件。

2013 是我们开源项目具有重要意义的一年，我们拥有大量令人自豪的新项目，为正常运行和维护它们的更新承诺，和使用它们的充满活力的社区一起工作的愿望。仅在我们的 Github账户上，我们现在已经有超过90个仓库，有超过40,000次的提交，一共被复制了15,000次。

年末是一个很好的机会来回顾我们投入精力的一些主要的领域，简要重述（不是详细的！）下我们工作的一些项目列表。

手机

我们最自豪的开源贡献常常是我们为了解决在 Facebook 遇到的规模和性能的挑战而开发的一些技术。

手机也不例外：Facebook 的手机应用已经是我们产品团队今年的一个重点，我们现在也还需要开发新的兼容性——在这种情况下，那些要迅速开发、编译、测试并发布我们手机应用的需求变得更加的高效。开源我们的工作，正如我们已经做的那样，是很自然的事情，这些工具已经成为我们手机开源作品集的核心。

比如，在四月份，我们发布了 Buck，我们的Android编译工具。开发者的效率对我们来说很重要，自然速度是Buck的首要工作：在Facebook，我们发现它在编译我们的应用时，比 Ant 快了超过两倍。从一开始，这个项目就越来越强大，并被Android社区也包括一些有名的Java项目广泛应用。

对于iOS，我们也有类似的瓶颈，发现我们需要加速和自动化Xcode的手动编译过程。结果就是非常流行的 xctool ——也在四月份发布——可以使工程师（更不说那些持续集成的机器）更加简单的编译和测试iOS和Mac项目。

我们在十月份举行的 Mobile @ Scale上推出了 Rebound，一个Android的物理和动画库。Will Bailey在这篇最近的博文中详细介绍了这个项目，我们相信对真实世界的物理建模是一个有力的方式，方便在应用中创建自然、可触的动画和交互效果。

最后，通过发布另一个手机工具来结束这一年，还有比这更好的方式吗？今天我们很激动的发布 Origami，一个 Quartz Composer的工具集，允许设计者更快的编译和构建手机交互的原型。

Web

Web技术也和Facebook相关，包括手机和桌面的客户端。在前段，我们开源的重点更多的在于支持在五月份的 JSConf上发布的快速灵活的JavaScript库 React。

从那以后，React库——和社区的热心者——有了一定的发展。现在在编译工具上有了大量的集成，服务器端的环境（像 node， Rails，和 Python）和其他客户端的库——也包括一些备受瞩目的外部的部署工具如 Khan Academy。团队维护了一个出色的社区概要博客，包括大量其他React项目的例子、演示和教程。

总之，我们也想帮助提高JavaScript语言和web应用的质量。例如， Regenerator，是用来转换ECMAScript 6的yield语法到现今的浏览器的一个转换器， Huxley，在夏天由Instagram团队构建的，已经快速成为web应用中一个非常流行的可视化正则测试工具。

数据

Facebook与开源数据基础设施(open source data infrastructure)颇有渊源，回顾我们对MySQL， Cassandra，Hadoop，Hive和Hbase所做的贡献可以看出这一点。2013年也不例外，仅仅在过去的几个月里，我们就上线了两个新的旗舰级数据项目。

首先是 Presto，一个新的分布式SQL查询引擎，被设计用于高性能分析我们用于运行交互式查询的300PB数据仓库。

我们在夏天的 Analytics @ Scale event上公布了Presto并且在上个月于我们的blog上对它做了更多介绍。从那以后，我们激动的看到它被许多像Airbnb和Dropbox这样的公司采用，并且从许多热情的社区得到了贡献，包括 new clients， Ansible playbook和 debian packaging。

第二个项目是 RocksDB，一个非常与众不同的数据基础设施(data infrastructure):一个基于LevelDB的嵌入式key-value存储类库，并且为拥有多核CPU和快速闪存的环境做了优化。此外，在它上线的以后几个月里，它引起了广泛的兴趣，一些伟大的社区已经把它绑定到其他的语言上。

我们对数据基础设施(data infrastructure)的贡献和支持拓展得很好也已经超过了我们本身。我们对 Giraph提供了强大的支持，比如，它已经被提高到可以支持1万亿边缘的图形结构。

基础设施项目

最后，但绝对不是最不重要的，基础设施项目在我们对开源项目的贡献中仍然是最为重要的一部分。

HHVM，the HipHop Virtual Machine，是目前为止我们的项目资产中最为显著并且是追随人数最多的项目，并且得到了大量的来自PHP生态系统的支持。2013年有近4000次提交，并且在性能和第三方php框架的兼容性上有了长足进步，这对于社区的广泛采用来说是非常重要的。

这个团队刚刚从封闭中走出来并且在昨天分享了他们最新进度的消息。并且我们很激动的看到在持续不断的集成测试之后，VM 被集成到Travis CI，并且为集成到其他流行的web server加入了 FastCGI支持。

我们今年也为许多其他的显著的基础设施项目工作过。对于我们自己的项目，包括 pfff，我们的代码分析工具箱， libPhenom，一个高性能的事件框架，和 folly，我们流行的C++类库。并且我们今年为 Mercurial， LLVM和 GNU grep提供了许多显著的贡献。

Open Compute项目在2013年继续壮大，使用 new work on networking hardware，新的社区和基础管理，以及全年众多的hackathons和讨论会。Facebook致力于支持项目建设并且它的目标是开发设计用于所有数据中心技术的开源服务器和数据中心 – 并且让我们期待下个月的 Open Compute Summit。

2013年我们的开源项目…

当你在使用或者为一个开源项目做出贡献时，我们知道没有比看到它停滞不前更糟糕的了：bug 没有被修复，问题没有解决，pull requests 被忽略。关于 Facebook，我们的目标是，通过我们的投资组合，保持强有力的社区参与责任感。

我们已经采取了具体的措施来达到这个目标。例如：我们现在鼓励我们的工程师团队在使用或者开发一个开源项目的时候，首选 Github，Bitbucket 或者 Apache 软件基金会的项目作为源码的来源。

我们有一个新的工具链，使 repos 和我们内部系统同步，同步代码评审过程，任务跟踪等等。同时把我们最近检测的所有 repos 仪表化，保证他们保持健康的发展：我们有内部的仪表盘来显示commits 的数量，pull requests 的数量和每个团队 issues 的数量。这给我们提供了一个早期预警系统，提醒社区中有哪些被我们无意中忽略了。

同时我们很自豪的宣布，我们正在做的 Bountysource 项目帮我们社区解决了很多问题，其中包括鼓励大家参与各种开源项目，奖励那些参与开源项目的开发者。我们已经有了一系列的奖励计划，包括 HHVM 和 D。

就在上个月，我们宣布 Facebook Open Academy 已经把开源带到世界各地大学的计算机科学课程中。

在 2013 年，我们也同步开始了 “ @ Scale” 工程活动的项目，这个项目旨在汇集开发人员讨论和分析各种技术大规模实施面临的挑战，分享他们的解决方案和相关的开源项目。今年的活动包括 Analytics @, Mobile @ 和 Data @ Scale，相关的视频已经放在了我们的 Facebook Developers channel。敬请期待明年更多的 @ Scale 活动。

最后，欢迎访问我们新工程的网站 code.facebook.com！我们尽可能让您更方便的关注我们所有的活动详细信息，在 blog posts, events, videos, academic publications 和 open source projects 上都可以找到我们所有的工程项目和活动。订阅我们的 Facebook Page 和 open source news 可以获得更多的更新新闻。

…以及未来

Facebook 的著名格言：我们的开源项目仍然是只完成了1%。

通过上面提及的所有主题，我们知道还有很多方面需要我们继续努力。我们很庆幸在我们众多的项目中有强大而热情的社区支持，给予我们强烈的责任感和动力。

不管你们是在移动端，web，数据亦或是基础设施社区，我们都很期待能继续与你们合作，2014年再见！

2013 年 Facebook 在开源方面的工作回顾，首发于博客 - 伯乐在线。

报告揭示美国几大知名社交网站的用户特点

Sat, 12 Oct 2013 17:27:42 CST

不同社交网站的用户特点存在差异，而了解主流社交网站的用户情况将有助于商家针对性地投递广告、开展营销活动。

BI Intelligence 研究发现，

Facebook：用户群仍偏向年轻，但 45 到 54 岁的用户较 2012 年年底增加了 45%。在年收入 7.5 万美元以上的美国互联网用户中，73% 都会使用 Facebook，而 Twitter 这一数字仅为 17%。
Instagram: 68% 的用户为女性。
Twitter：美国 18 到 29 岁人群中 27% 使用 Twitter。
LinkedIn：男性用户居多。
Google+：70% 的用户为男性，是所研究的网站中男性比例最高的一家。
Pinterest：由平板用户主导，84% 的美国用户为女性。
Tumblr：对青少年和年轻的成人有很强的吸引力，但年收入 7.5 万美元以上的美国互联网用户中，只有 8% 使用 Tumblr。

查看 BI Intelligence 的完整报告及分析结果需要付费订阅，完整报告进一步介绍了上述社交网站的用户行为特点及所带来的营销启发。

题图来自 wallpoper

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 · Beats of Bits | 原文链接 · 查看评论 · 新浪微博 · 微信订阅 · 加入爱范社区！

Nielsen 报告指出，用户开始拥抱智能手机 App 而摒弃传统 Web 网页服务

Tue, 17 Dec 2013 14:01:00 CST

分类: 互联网络

每到年末的时候，市场分析公司都会发布年终盘点，Nielsen 公司也不例外。该公司刚刚发布了十大网络web 品牌，十大网络视频品牌和十大智能手机 App，其揭示了一种不断增长的趋势，那就是越来越多的人使用智能手机 App ，而不是基于传统的 Web 服务。在这份榜单中， Nielsen 公司还指出，和去年同期相比，各个品牌的用户整体使用率已经发生了一些改变，网络品牌全线下跌，在线视频品牌表现的比较平坦，智能手机 App 的使用率则在暴涨。

Google 在 2013 年的时候是顶级的 Web 品牌，但它的独立访客数量和去年同期相比减少了 6%，而 YouTube 则下降了14%。尽管如此，这两个品牌在智能手机十大 App 中冲进了前五名的位置，从 14% 增长到了 29%。也许并不奇怪， Facebook 经历了类似的趋势，它的网络流量减少了 16%，而其智能手机 App 数量增长了 27%，成为今年最常用的服务。此外，像 Instagram 和 Twitter 这两个社交网络则获得了跨越式发展，在十大榜单中占据着第七名和第十名的位置；其中 Instagram 是在十大榜单上增长最快的 App。「这里插播一下，我们的母公司 AOL 在十大 Web 品牌中占据第七名的位置」。

最后，Nielsen 报告还说，有将近三分之二的美国手机用户，具体就是 65% 现在使用智能手机，而不是功能手机，而在 2012 年底这个数据才维持在 56%。这些用户中，有 52% 现在使用 Android 设备，而 41% 的人使用 iOS 平台，7% 的人使用其他平台「 BlackBerry 是 3%，而 Windows Phone 是在 2%」。有兴趣的可以点击跳转查看详细榜单信息。

继续阅读全文 Nielsen 报告指出，用户开始拥抱智能手机 App 而摒弃传统 Web 网页服务

此文章网址 | 转寄此文章 | 回应

Facebook开源闪存数据库RocksDB

Fri, 22 Nov 2013 13:04:27 CST

本周四Facebook宣布开源其嵌入式数据库 RocksDB（一种嵌入式Key-value存储系统），该数据库能够充分利用闪存的性能，大大提升应用服务器的速度。
Facebook用RocksDB来驱动一些面向用户的应用，这些应用由于需要通过网络访问外部存储而性能低下，此外Facebook还用RocksDB来解决固态硬盘IO利用率不高相关的一些问题。Facebook的数据库工程师Dhruba Borthakur在其个人博客介绍了RocksDB的设计原由和原理，但实际上催生RocksDB的最大动力来自服务器闪存存储卡的价格大幅下滑，Facebook的定制服务器已经开始全面采用闪存。

随着闪存存储时代的到来，一些新的应用可以在闪存中管理并快速访问自己的数据集，无需通过网络访问外部数据。这些新应用使用的就是我们所说的嵌入式数据库。

数据库查询如果在本地闪存中进行，速度理论上会比通过数据中心内部网络查询快一倍，因为数据库中心内部网络有50微妙的延迟。

RocksDB的能够充分利用闪存的高IOPS性能，同时也能利用多核服务器的计算性能，Facebook目前已经在 RocksDB的GitHub页面上发布了RocksDB在Fusion-io服务器上的跑分基准测试结果，Facebook声称其速度比Google的LevelDB嵌入式key-value存储系统快很多。

WhatsApp估值的四个支撑点

Sun, 23 Feb 2014 00:51:48 CST

Facebook以190亿美元的价格收购WhatsApp近日在全球新闻界引发了“值不值”的大讨论，WhatsApp 190亿美元的估值成为近年来最大宗的科技收购，在笔者的印象里，最近一次超过200亿美元的科技界收购是多年前惠普以240亿美元的价格收购康柏。

从Mashable给出的这张图表可以看出，在近年互联网公司的收购史中，WhatsApp的估值创下了新高。

在上面这张表中，Facebook以10亿美元收购Instagram的估值排名垫底，甚至google收购摩托罗拉移动的估值也远不及WhatsApp。

190亿美元意味着什么呢？Facebook可以用这个价格买下Sony或Gap，或者四家航空公司，但Facebook却买了WhatsApp，一家累计融资仅有6000万美元的创业公司。

190亿美元的“天价”使得WhatsApp的估值问题成为业界最热门的话题，近日哈佛商业评论撰文指出，对Facebook来说，WhatsApp的估值或者说价值主要有以下四个支撑点：

一、吸引年轻用户。WhatsApp过去五年积累的4.5亿活跃用户，70%都是日活跃用户，是Facebook同期的三倍，是Twitter和Skype同期的10倍。4.5亿活跃用户，其中很多是年轻用户，这些都对Facebook的用户基础构成严重威胁。

二、新的盈利模式。与Facebook等互联网巨头普遍采用的广告模式不同，WhatsApp采用的是订阅付费模式，免费使用一年后会向用户收取0.99美元的年费。由于采取年费模式，因此WhatsApp能够向用户承诺完全“干净”的社交网络环境，没有广告、没有用户数据挖掘，没有讨厌的推荐和营销活动骚扰等。

三、对现有业务模式的改进。WhatsApp的每日消息数量与全球通信业产生的SMS短信数相当，过去Facebook主要是个人生活事件的发布场所，而通过WhatsApp的个人消息服务的元数据，Facebook可以挖掘更深层次更精准的用户关系网络，从而实施更加精准的营销。

四、国际化。Facebook Messenger在美国非常流行，但也仅此而已。在印度和南非等重要市场，WhatsApp比Facebook Messenger要流行得多。这也许是WhatsApp估值中最终要的部分，Facebook也想加入移动全球化的大潮中。

Facebook 数据揭露年龄与兴趣之间的关系

Sun, 29 Sep 2013 17:11:31 CST

被评论为“最 Geek 网站”的 Wolfram Alpha 今日发布了一份有趣的数据。他们从参与“Facebook 数据贡献计划”志愿者的 Facebook 上收集个人留言墙数据，分析男/女用户兴趣焦点随着年龄变化会出现何种改变。

这份数据揭露了一些有趣的现象。比如随着年龄增长，Facebook 用户的人际关系趋于稳定，关于感情的话题随着年龄增长而减少，这个分水岭大约是 25 岁。比如女性比男性更喜欢谈论个人情绪、宠物、家人，男性比女性更喜欢谈论运动、科技、音乐电影等等。

以下是关于 24 个领域的兴趣-年龄趋势图（纵轴为讨论频数，横轴为年龄；红线为女性，蓝线为男性）：

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 · Beats of Bits | 原文链接 · 查看评论 · 新浪微博 · 微信订阅 · 加入爱范社区！

谈谈Facebook的聊天系统架构

Tue, 13 Aug 2013 01:13:47 CST

今天看到一份 Facebook 公司 2009 年的 PDF, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.

Web Tier: 用 PHP 开发, 聊天相关的业务逻辑代码. 如 AJAX 请求, HTML 页面拼接等. 这个模块整个其它的 3 个模块, 向浏览器提供了大部分的聊天接口.

Chatlogger, 用 C++ 开发, 消息的存储服务. 至少向 Web Tier 层提供了消息保存, 聊天历史消息, 最近联系人等基础服务接口.

Presence, 用 C++ 开发, 提供用户在线状态维护服务. 这些服务器会将在线的用户(UID)保存在内存中, 然后接受 Web Tier 的请求, 例如判断某个用户是否在线.

Channel(Comet) Cluster, 用 Erlang 开发, 提供基于浏览器的”Server Push(服务器推)”功能. 是对开源的 Mochiweb 的二次开发. 浏览器会跟 Channel Clusters 进行连接, 当 Web Tier 收到某个用户的消息时, 会通过 Channel Cluster 推送到接收者, 实现网页实时聊天功能.

关于 Web Tier, 其实没有太多的技术可讨论, 因为这主要是业务逻辑, 即使不用 PHP 语言, 用 Python 或者 Java 等都没有问题.

Chatlogger 虽然名字是”日志记录”, 但它不可能是简单的日志记录, 它必须要提供基本的消息服务接口. 而且, 为了存储数亿 Facebook 用户的聊天历史, 必然要涉及到海量数据存储. 这部分 Facebook 曾经用 Cassandra, 后来改为 HBase. Chatlogger 使用 C++ 进行开发是基于性能的考虑, 而且消息存储服务的接口比较固定, 不太可能经常变化.

Presence 维护用户的在线状态, 类似这种服务在网游中比较常见. Presence 服务器使用 C++ 来开发, 也是基于性能的考虑. 如果使用 HTTP + PHP + Memcache/Redis 这样的架构, 一是 PHP 代码执行性能损失很大, 二是 Memcache/Redis 是通用的存储方案, 不适合 Presence 的高性能需求. Presence 在数据全部保存在内存中, 速度快, 设计灵活. 注意, Presence 是一个被动服务器, 它并不主动向外推送消息, 这使得这样的服务器接口非常固定, 独立性很强. Presence 的数据主要来自于 Comet 群集的推送.

Channel(Comet) Cluster 和浏览器保持网络连接. Comet 有通道的概念, 每个用户对应一个通道, 用户会分布在不同的服务器上, 用户每打开一个新的浏览器标签, 就会同服务器建立一个新的网络连接, 但都是连到同一个通道. Comet 服务器是基于开源的 Erlang 服务器 Mochiweb 进行二次开发. 在身份验证和安全方面, 通道的建立是由 Web Tier 进行控制的, 这样如果用户没有在业务逻辑层经过相应的验证, 就直接连接 Comet 服务器, 它是会被拒绝的. 另外, Comet 服务器会在自己的内存中先维护一份在线用户列表, 然后定期更新到 Presence 服务器, 这也是二次开发的原因. 如果 Comet 服务器不自己先缓存一份在线用户列表, 那么用户频繁上线下线都立即通知 Presence 的话, 压力会非常大.

架构已经很清晰, 但要应用起来, 代码的开发是必不可少的. 当然, 不同的技术团队会根据技术情况进行取舍. 例如消息存储使用 MySQL, Presence 使用基于 Web 容器架构的技术来开发, 而 Comet 模块可以使用 nginx-push-stream. 不过, 仅仅依靠整合开源系统而不做二次开发, 不可能解决大问题.

PDF 文件可以在这里下载: http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf

你现在看的文章是: 谈谈Facebook的聊天系统架构

Linode VPS - 美国虚拟主机 | IT牛人博客聚合网站

为什么2012年HTML5发展远未达预期

Sun, 25 Nov 2012 17:24:28 CST

编者按：本文作者Ben Savage, Spaceport.io创始人， Spaceport.io旨在向移动游戏开发者提供原生Javascript和HTML5开发平台。Ben在年初的时候曾对 2012年HTML5的发展趋势作了十四项大胆预测，不过在接近年终的时候他认为这一年来 HTML5的发展远远未达预期，主要原因有以下五个方面：

在这之前曾有人预测在2013年基于HTML5的手机销量将达到10亿， Facebook也似乎为其铺好了道路，笔者在年初的时候也曾预言2012年将会是HTML5起飞的一年，不过现在回头发现HTML5的发展并不尽如人意，Mark Zuckerberg的一句话很好的映证了这一点：“作为Facebook公司来说，我们最大的错误就是在HTML5上押宝太多！”

以下五点是对于这一年来HTML5为什么没有达到高预期的一个解释：

1.跨平台HTML5开发并未起飞

桌面端和移动端HTML5之间的分裂还是巨大的，这两者之间没有形成一个统一的开发标准，主要原因就在于以下的这三点差异：

电脑键盘与手机、平板键盘之间的差异；
两个平台设备的屏幕大小；
鼠标与触摸屏操作的差异。

最理想的情况就是针对特定平台进行产品开发，这样开发者就能对应用的外观、感觉和功能等进行相应的个性化设置，从用户体验角度来说这也是极其重要的。然而很多人对HTML5的预期就是HTML5应用可以实现跨平台访问，比如说从桌面端访问移动HTML5应用。不过从现实情况来看，用户也只能选择一个应用能更好的运行的平台，因为当前的跨平台HTML5并不完善。

通常开发者的观念就是说到移动端的时候，HTML5应用就必须是为移动用户开发的。没有什么比开发者们不愿意将时间多花在跨平台HTML5应用的开发上更让人沮丧了，而到最后你才发现其实你的用户是个多平台设备用户，在某一个平台上不能完美体验你的HTML5应用的时候，用户就有可能离你远去。

不管怎么说跨平台HTML5开发需要时间、精力和给用户更多的体贴。

2.人们更习惯于通过应用商店下载应用

为移动设备创建一个带桌面图标的HTML5浏览器链接非常容易，但是想改变人们对应用的传统观念还是比较困难。人们往往习惯于被告知去下载某一个应用，用户本能的反应就是通过应用商店去搜索应用，而占主导地位的苹果和谷歌的应用商店迄今为止还没上线过一款HTML5站点应用。

Facebook创建的通用商店“universal store”提供了原生应用和HTML5网页应用供用户选择，在很多人看来这将会成为Facebook的商店战胜苹果和谷歌的应用商店的一大有力举措。为了说服更多的开发者投身HTML5应用，Facebook甚至在 W3C联盟下建立了一个开发者网络，但是到目前为止，它的这一举措还没有显现出足够的吸引力。

3.混合应用不能依赖移动浏览器

在我的想法中至少要有一款主流主机游戏是使用 WebGL技术开发或者再版，游戏巨头EA就曾发布了HTML5版命令与征服泰伯利亚联盟（Command & Conquer Tiberium Alliances），然而最大的问题所在就是作为移动浏览器中的佼佼者Chrome和Safari都并没有完全支持HTML5技术的意向，举个例子来说，主流移动浏览器Chrome和Safari等就不支持WebGL技术，而这是HTML5 3D游戏开发的核心技术所在。

跨平台HTML5应用的兼容性是一大问题，但是移动浏览器的速度也是制约HTML5移动应用发展的因素之一。有报告曾显示HTML5在移动浏览器中的访问速度比起桌面端HTML5应用的速度要慢上十到七百倍左右，事实研究证明移动浏览器的HTML5应用的平均速度要比桌面端低889倍。而当前的主流HTML5应用大都是图形化应用，受移动网络网速的影响，移动端HTML5的用户体验是比较糟糕的。

4.不同移动设备间的适配问题

在HTML5发展的过程中，那些已经建立了一个网站的开发者们就曾经历过很让人头疼的浏览器兼容性和跨平台适配问题。举个例子来说，Gamzee的一位工程师Sean Soria就曾描述过他们在为Facebook的HTML5博客开发Skyscraper City应用的时候所面临的问题：在编写代码的时候他在文档对象模型（DOM）中使用了一个伪3D转换CSS代码，它能触发大多数移动设备的硬件加速能力，而且这种方法比使用Canvas元素表现要好很多，非常不错的一种方法，但是问题就是Android手机并不支持。这样的问题还有很多，往往不同设备之间HTML5应用所面临的问题和解决方法都不一定是相同的。

基于网页的WebApp短期内将遇到发展瓶颈。因为标准化问题和终端设备功能的支持程度，很难在短时间内找到确切的解决方案。

5.HTML5还不够强大

从我所已经看到的来说,炒作已经导致许多人高估了有多少开发人员喜欢使用JavaScript这一现状，JavaScript用于跨平台开发的强大是毋庸置疑的，但是这样就能证明JavaScript是HTML5跨平台开发的替代品么？显然不是这样。对于一些较为复杂的应用特别是游戏来说，面向对象法和更强大的手写代码往往更受开发者们的欢迎。

所以从上述几点来看，HTML5在这即将过去的一年的发展远远没达到人们的预期。HTML5可以说是成为了以Facebook为代表的新兴移动互联网一代被高估的替罪羊，如果HTML5能代表未来的话，那么它所代表的未来比起我们能想象到的还要远很多，不过现在谈这些还是有点为时尚早，当然这也不是说HTML5就没有春天，只是在短期之内还是很难实现的。

Via VB

最新发表

您可能也喜欢：
开发者看HTML 5：就差一个大公司的推动	HTML5未来发展的六大趋势	游戏巨头Gree发布HTML5服务誓要打破App Store模式	2012年HTML 5的14大预测	Kendo UI：开发者态度乐观 HTML5春天将提前到来
无觅

（流云供 雷锋网专稿，转载请注明来自雷锋网及作者，并链回本页)

社交网络崛起

Sat, 08 Sep 2012 06:03:43 CST

2009的8月28日，当由新浪CEO曹国伟亲自主导的神秘项目微博开始内测的时候，更多还是被看作与饭否、嘀咕、滔滔相似的国内众多类Twitter产品之一，不过事情的发展出乎了不少人的意料：新浪成就了一个不同于美国Twitter的、中国本地化的微博产品，并引发了之后3年中国社交网络的一场风暴。

于新浪而言，微博业务的崛起让这家上市10年的老互联网公司重新焕发生机，于中国的社交网络而言，微博是一个无法被忽视的里程碑意义的产品，而微博成功背后更值得玩味的则是：一个最不像Facebook思路做出的产品反而引爆了过去3年的社交网络浪潮。

关于那段历史，《商业价值》杂志在2010年12月刊《微博照耀新浪》一文中曾做过还原。

“当时我们就认为微博和新浪的基因其实正好搭上了”。王高飞及许多新浪高层至今都认为，“连接网页的Google和连接人的Facebook是互联网的两大基础设施，是‘道’的层面，而Twitter是‘术’的层面”。但新浪必须找到一个适合自己的切入点——这就要搭上自己的媒体基因。

新浪微博的迅速崛起除了要归功于一个恰当的发布时机（饭否、叽歪、嘀咕等微博监管上遇到问题；搜狐白社会的成功让它坚定走在SNS的路上，并未看好微博客路线），新浪强悍的媒体运营实力还与微博产品深层的设计息息相关，从这个角度，新浪微博是一个最懂中国人微妙心理的产品。

在《商业价值》杂志2011年4月刊《社交新世界》一文中曾分析过新浪微博迅速引爆的深层原因：提起Facebook人们自然想到六度空间理论，六度关系所构建的社交网成为Facebook这个庞大社交网络的血管和骨骼，这也是无数SNS产品的基础模型。“但是在新浪微博上，因为鼓励关注，少量用户被大量用户关注，所以新闻很可能在第2步被一个超级链接器类型的用户转发，新闻就能覆盖全网，从新浪微博得到的数字是2-3度，而不是许多社会网络里平均的5-6度。这也成就了微博为信息传播速度和形态带来的深层改变。”

不过，在掀起了一波社交网络浪潮，扮演了中国人社交网络启蒙者的角色之后，新浪微博却发现在社交领域，它正在被借助智能手机迅速崛起的微信逐渐赶上，至少在产品层面，微信被认为更加社交，而微博强烈的媒体属性让它越来越像一个营销平台。

新闻的严肃与社交的戏谑形成了两个产品截然不同的风格，如今，越来越多人选择在新浪微博上看新闻，对于大多数非加V用户来说，这是一个45度角仰视大牛的平台，但总是缺少点社交的氛围；在看新闻和八卦之余他们更乐于在微信上调侃好友卖萌撒娇。

433天达成1亿用户，微信的速度看起来像是个奇迹，但是也是一场“在IM关系链上做SNS的风险极大之尝试”（本刊2012年5月《微信4.0的赢与代价》）。

微信继承自QQ，在基因上是与微博的弱关系交友不同主打的是手机通讯录为代表的熟人关系，后来随着微博和QQ关系链的导入让微信用户的人际关系链变成了“熟人+微博互粉+QQ好友”，再往后为了扩展用户量，LBS、摇一摇、漂流瓶等陌生人交友模式被引入，微信在功能无比强大又好玩的同时开始面临关系链混乱的潜在风险。

如同《微信4.0的赢与代价》一文中所说：微信扩展产品，做大做强，与此同时却让关系链混乱，而关系链的混乱又将使得它难以变成一个真正意义上的社交平台，限制了其未来发展的广阔空间。

过去3年是中国社交网络启蒙的3年，也是中国人网络社交从亢奋到回归常态的3年，不客气的说，新浪微博和微信的迅速崛起的一个天时地利之一是中国人社交需求带来的庞大人口红利，未来更好的社交网络形态则需要更加扎实的对人的研究和深厚的产品功力。

相关文章：

电商起落

提高软件质量实践―― Facebook 篇

Mon, 05 Nov 2012 09:16:54 CST

来源： Bill Liu 的博客

Facebook从04年的哈佛校园的学生项目在短短的7－8年的时间中快速增长为拥有10亿用户的世界上最大的社交网络，又一次见证了互联网创业成功的奇迹。同时它的产品研发流程也成为了众多互联网产品公司的追逐对象。今天我们来看一下facebook在产品质量控制方面的实践。有人说，现在的google象早期的微软，现在的facebook象早期的Google. 我觉得无不道理。虽然facebook已经早已不是创业公司，但是不难看出它在产品研发和质量控制仍然保持着创业公司的风格。在产品研发上，他们以小的研发团队为核心，遵循几个非常重要的原则：

Be there from start to ship: 每个工程师自始至终负责产品。从最开始的一个想法，到开发原型，到内部审核，反馈，到产品开发，上线和维护，全部有工程师自己搞定。

Show work early and often: facebook非常看重反馈，尤其早期内部反馈。他们鼓励工程师有了想法后，尽快开发出原型，尽快得到反馈。

Gets your hands dirty: 动手去做，去实现。

Don’t fall in love: 互联网产品是不断变化的，不需要等到把一个产品设计的很完美了才发布。

为了遵循以上原则，facebook工程师采用以下质量控制手段来保证产品质量：

开发对质量负责：开发从设计，实现，测试，到部署都要自己做。其它做工具，流程的工程师通过开发工具和流程来帮助开发人员更为简单方便地做测试，做部署和做监控。每个开发人员有自己单独的测试环境，测试环境就是运行在开发本地机器上，部署非常简单快速。测试环境用的是真实的用户数据。

持续集成和测试自动化：每周发布一次。星期天晚上，要发布的构建从主线上分支出来到发布分支，到星期二的中午如果没有大的问题，就可以上线了。所有的测试运行控制在10分钟以内，所以不需要考虑不运行哪些测试用例。运行所有测试用例。（只是听说，没有经过考证。）

内测（dog food）：发布之前，公司员工使用要发布的功能。2－3天之内可以有几百个或上千个人在使用新功能。负责要发布功能的开发人员在星期天晚上到星期二中午之间会做大量的测试（一边上班，一边刷微博，岂不是很爽）。

发布风险控制：新功能本身质量可能有问题，新功能也可能影响其它现有功能。为了减少或控制这些风险。Facebook开发了一整套完善的发布，控制，监控流程和工具。做到：1.测试通过后，产品质量基本有保证。2.即使有漏测的bug，只会影响很少量的用户。3.及时监控到问题。4.及时修复。

产品监控：监控产品的系统的运行状态。

Facebook之所以采取这种质量控制策略和它的产品特点密切相关：

1. 用户对社交产品质量的容忍度相对较高。比如发微博，现在连不上，等一会在连接也可以，现在发布不出去可以等一会再发，粉丝数量统计有误，没有人太关心。其实facebook并不认为自己的质量差。他们认为产品的质量高低不是有多少个failed测试用例,有多少个bug来确定的，而是有用户对质量的期望值来决定的。如果用户对产品质量的期望值很高很高，一个bug漏掉了都会照成质量差的印象，用户很有可能放弃使用。相反，如果用户的期望值一般，100个bug漏掉了都不会影响用户继续使用。所以facebook产品发布的条件是满足用户对质量的期望值即可。

2. 相对宽松的产品发布周期。不想微软或google很多产品已经在市场上，用户对下一版本的发布时间和新增加功能的期望很高，这往往给产品开发组的压力很大。Facebook基本没有这个问题，它有适合自己的发布期限，不用受到外界干扰。

3. 产品发布和监控流程比较完善，即使有漏测的bug，对用户的影响可以控制在最小而且可以及时发现及时修复。

Facebook质量控制中引以为豪而且倍受瞩目的就是“没有专职测试工程师”。我这里需要专门讨论一下：

1. 什么是“专职测试工程师”？头衔里面有“测试”的工程师？专门找bug的工程师？专门做质量控制的工程师？等等。

2. Facebook的确没有带“测试”头衔的工程师，也没有专门运行产品找bug的工程师。每个人都是开发工程师。但是他们的实际工作有区别，有的专门做面对用户的产品，有的专门做测试，开发工具，有的专门做产品的构建和持续集成工具和流程，有的专门做发布和监控的工具和流程。如果按照传统意义上的开发和测试的划分的话，除了第一类外，其他都可以看做专职测试工程师。

3. Facebook不是惟一一个没有带“测试”头衔工程师的公司，很多软件公司都没有，比如twitter.

4. 很多人把专职测试工程师指专门运行产品找bug的工程师。微软在2005年去掉STE (software test engineer )岗位，就已经没有这一类型的专职测试工程师了。

所以个人认为，专职测试工程师是个非常模糊的结论。尤其现在我们对产品质量控制方法的不断演变和提高，“测试”的概念不仅仅是指找bug了，所有围绕提高产品质量的工作都是测试。头衔上有没有“测试”不重要，有没有“测试”岗位不重要，重要的是如何有效保证和提高产品质量。

Facebook推社交搜索工具挑战谷歌威胁Yelp

Wed, 16 Jan 2013 08:18:59 CST

Facebook今日面向其逾10亿用户，推出了社交搜索工具Graph Search（发布会实录），向用户提供了另一个选择，来替代谷歌、LinkedIn及Yelp等企业所提供的服务。

Facebook在位于加州门洛帕克市的总部举办了产品发布会，该公司CEO马克·扎克伯格(Mark Zuckerberg)在会上表示，用户可以通过Graph Search寻找用户、照片、地点及用户兴趣等。Facebook还在发布会上展示了Graph Search的招聘功能，帮助雇主找到潜在的新雇员。

等到Graph Search完全推出之时，这个搜索工具将对众多网页用户造成刺激，减少他们在谷歌、Yelp及LinkedIn等网站停留的时间。扎克伯格表示，这项新功能将在未来成为一项“业务”，但他并未说明该服务如何尽快实现盈利，令Facebook股价承压。

市场研究机构Gartner的分析师迈克尔·盖丁伯格(Michael Gartenberg)表示，“哪一个更有价值？在纽约找一家寿司店，还是找一家好友喜欢的寿司店？Facebook和谷歌的竞争将继续。”

美国当地时间1月15日美股收盘时，Facebook股价报收30.10美元，跌幅为2.74%。由于Facebook新搜索工具的职业搜索功能或对在线求职服务提供商LinkedIn及Monster造成威胁，二者股价盘中因此下滑，但收盘时股价均微涨，点评网站Yelp的股价报收20.61美元，跌幅为6.19%。

扎克伯格在发布会中表示，“Graph Search旨在进行精准查询，并向用户返回答案，而不是连往其他地方的链接。”

餐厅搜索。通过使用Graph Search，用户可以通过设置餐厅类型、位置进行搜索，同时还可以搜索自己“喜欢”，或朋友们“喜欢”的饭店。

与朋友合照的照片。按与朋友们在一起的照片，可以帮助用户进一步缩小搜索范围。

照片搜索。用户可以展开自己的想象力，进行照片搜索——“1990年以前，我朋友拍的照片”，当然也可以更具体一些，如由制定的人上传的，1990年以前朋友们的照片等等。

网络搜索。Facebook的Graph Search整合了必应（Bing），如果这家社交网络巨头找不到答案，就会提示转到网络搜索——这一功能的图标是灰色的。

10日天气预报。网络搜索的结果，也可以直接展示在Facebook的搜索页面中。如在查询天气的时候，天气信息会直接展示在Facebook的搜索菜单中。

Facebook四处拓展营收

IPO(首次公开募股)开局不利，及对这家社交网络巨头长期盈利前景的担忧，市场一度对Facebook感到失望，而现在华尔街正在重拾对这家全球最大社交网络的信心。

由于用户逐渐向移动端转移，Facebook正在集中力量，研发新方法以从用户处获得营收。扎克伯格表示，公司正在移动方面采取积极行动。

从智能手机到网页搜索产品，过去几周，市场对Facebook新产品的猜想可谓是到达了狂热阶段。另外，市场预计Facebook第四季度将实现强进的财务业绩，从而推动Facebook股价上涨。

虽然扎克伯格认为这项搜索服务将成为一项业务，但分析师们则建议谨慎行事。此前，由于隐私政策不明朗，Facebook已多次遭到抨击。

研究咨询公司Ovum Research分析师艾登·左勒(Eden Zoller)认为，Facebook的当务之急是强化广告营收。他表示，“Facebook的Graph Search搜索工具无疑将通过收集用户数据，向广告主提供更多定向个性化的广告机会。不过，Facebook需要谨慎慢行，要留心用户隐私问题。”

搜索市场

市场研究公司IDC的分析师卡尔斯滕·韦德(Karsten Weide)曾在本月初表示，如果Facebook推出更多基于搜索结果的广告，其有可能占据美国搜索广告市场5%的份额，2012年该市场的市场规模已达到约150亿美元。

另外，扎克伯格表示，Facebook新的搜索功能旨在帮助用户在网络中找到新朋友。Facebook将面向小部分用户推出Graph Search试用版。Facebook表示，其意在保护用户隐私。

与依靠关键字的网页搜索不同，Graph Search允许用户进行短语搜索，来找出在Facebook上已被分享过的信息。该服务将以4个领域为主要关注点：用户、图像、地点及兴趣。

Facebook表示，其已与微软必应搜索结成合作伙伴关系，若Graph Search无法找出用户所需答案，将由必应为用户提供额外的网页搜索结果。扎克伯格表示，“这是个奇妙的东西，是我们开发最酷的产品之一。Graph Search将让用户拥有提一个全新的方式，在Facebook上查找信息。”

会威胁到谷歌吗？

Graph Search的理论是：因为与好友、他们的个人喜好、他们的好友、所做的事、事情发生的地点，及他们所想所赞的事务相关，因此，这个搜索结果与搜索内容相关。不过，所有这一切引出了一个问题及“这对谷歌有多大威胁？”简言之，目前为止，对谷歌没有很大威胁，除非这些搜索结果能够在必应或者雅虎上出现。Facebook上会显示必应的二次搜索结果，必应此前曾使用该搜索工具的“精简版”，但没有做到Facebook如今提出的水平。

要想大规模改变用户的搜索习惯，Facebook需要为此耗费大量的时间和财力。如何鼓励用户从谷歌、必应或雅虎等搜索引擎转向Facebook？因此，Facebook就要像必应和雅虎，以对这些搜索结果进行整合。这之后，其才能真正对谷歌构成威胁。谷歌Google+社交网络虽然很有趣，但是规模很小，因此，谷歌的社交图谱搜索所能发挥的作用也很小。

业内人士预计，随着越来越多的用户将使用Facebook进行数据查询和搜索，该工具将得到大规模普及。而搜索流量增加将会让有更多默认必应搜索结果出现。因此，必应或将因此受益，赢得市场份额。

Yelp股价大跌

Facebook工程师拉斯·拉斯穆森（Lars Rasmussen）在今天的发布大会上声称，通过Graph Search，用户还可以搜索包括餐馆和牙科诊所等在内的本地化业务相关的信息。

Facebook的上述举措令美国最大的点评网站Yelp投资者感到非常担忧，这一担忧也导致了Yelp周二股价大幅受挫，盘中一度下跌8.5%之多。

Yelp似乎正面临着Facebook引发的新战争。Yelp目前大约拥有8000万活跃用户，与Facebook庞大的用户规模相比，只是一小部分而已。事实上，Yelp最近也开始拓展国际市场，而Facebook早已在国际市场展露了强劲的实力。

但是，Yelp与Facebook相比，仍拥有一些优势，例如拥有更加详细、更加有序的商业信息评论等相关的内容，这些内容可以让用户搜索到“墨西哥玉米饼”和附近的墨西哥快餐馆等信息，之所以如此，主要是因为Yelp的一位用户在他的地理位置评论信息中提到了“墨西哥玉米饼”。当然，Facebook比Yelp拥有更多的优势，例如拥有更加发达的社交连接功能，Facebook可以利用这些连接来为用户提供相关的服务信息，但目前为止，有关这些服务的信息却非常少，这些较少的信息包括餐馆的菜单可以提供哪些食品、或者是医生能够提供哪些服务等。

Yelp的商业模式似乎只以地理位置评论为主（事实上Yelp也包括了一些小的团购业务），毫无疑问，Facebook的新搜索服务将会对Yelp的服务产生一些冲击。

你可能也喜欢：
谷歌推出本地图片模糊搜索功能 (@70man)	Clicker利用Facebook社交数据为你推荐视频 (@resyschina)	谷歌工具条推新功能：可对所有网站发表评论	视频：体验谷歌中文语音搜索好强大	谷歌图片搜索广告悄然上线相关性遭质疑
无觅

Feed enhanced by Better Feed from Ozh

告诉你美国最火的15个网站

Fri, 01 Feb 2013 17:09:06 CST

如果让你列出在美国最受欢迎的15个网站，你能想到多少？你可能会想到Google很火，Facebook也很火。可能你还记得雅虎。当然了，啥都卖的亚马逊一定也很火。哦对了，还有eBay！但我们打赌你不能把其他10个也全部说出来，而且还是按顺序。。。。。。感谢ComScore公司！他们提供了2012年12月美国最流行的15个网站的数据。一起来看看它们都是谁吧：

15.CNN：5300万访客

网站类型：多媒体新闻网站

上榜原因：CNN以首发突发性大事件而著称。他们的内容很棒，无论是视频、音频还是文字。

14.Live.com：5600万访客

网站类型：微软旗下电子邮件网站

上榜原因：微软使他们的两大电邮品牌Outlook和Hotmail都能在Live.com上使用。

13.eHow：5700万访客

网站类型：教你“这个该怎么做”的网站

上榜原因：eHow的内容非常丰富。大部分内容都是具体问题的答案，而这种问题往往是人们在Google常问的。所以他们大部分的流量来自 Google。

12.About.com：6200万访客

网站类型：教你“这个该怎么做”的网站

上榜原因：《纽约时报》在2005年收购了它，后来又把它卖给了IAC（美国最大网上旅游服务公司）。 About和eHow很像，也是以回答问题为主的网站，Google为他们带来了很多流量。

11.Ask.com 6300万访客

网站类型：网络搜索引擎

上榜原因：Ask是一个很有特色的搜索引擎。在他们的母公司IAC收购了About后， Ask上面也相应多了很多内容。

10.eBay.com：6400万访客

网站类型：网上拍卖及购物网站，相关产品包括：电器、衣服、体育用品等

上榜原因： eBay改变了人们处理旧东西的方式。自从1995年成立以来，eBay收购了多个品牌，如PayPal、Skype、Shopping.com等。

9.Blogger：：6700万访客

网站类型：博客平台

上榜原因：Blogger在成立之初只是旧金山的一个小公司。他们也曾挣扎在破产的边缘，但后来在2002年Google的收购拯救了这家公司。

8.Bing.com：7500万访客

网站类型：网络搜索引擎

上榜原因：微软大力推广自己旗下的Bing，而且也付出了许多努力来使得 Bing更好用，例如改进搜索算法等。而且微软还掏钱让其他网站来连Bing。

7.维基百科：8600万访客

网站类型：免费的网上百科全书平台

上榜原因：维基百科允许任何人在它们的网站上编辑并发布内容，这使得维基百科成为了一个巨大的教育资源库。它绝大部分的流量是Google带来的，因为它能回答人们在Google上问的问题。

6.MSN：1亿访客

网站类型：微软旗下综合网站

上榜原因：MSN从一个互联网服务提供商成长为类似Hotmail、MSN这类网上服务的集结地，是一个综合门户网站。

5.Amazon：1亿500万访客

网站类型：综合线上购物网站，销售电器、衣服、体育用品甚至食物等

上榜原因：一开始的时候，亚马逊只不过是个小小的卖书网站。但现在它是一个从小提琴到牛肉干到iPad无所不卖的网站。

4.Youtube：1亿2800万访客

网站类型：观看、上传、分享视频的网络平台

上榜原因：Google在2006年对Youtube的收购确实给这家网站带来了新活力。从那以后，越来越多的人开始使用Youtube。

3.Facebook：1亿5000万访客

网站类型：社交网站

上榜原因：Facebook总裁马克·扎克伯格在他还是一名哈佛大学大二学生时建立了Facebook。这个网站一开始只是对哈佛学生开放，后来慢慢的其他学校的人也加入进来。现在，只要你年满13岁，Facebook就不会拒绝你。

2.Yahoo.com：1亿7100万访客

网站类型：搜索引擎并连接雅虎旗下其他服务，如Flickr、Yhaoo Finance等

上榜原因：雅虎是上个世纪90年代产生的网络门户之一。人们去雅虎看各类新闻以及收发邮件。

1.Google：1亿9100万访客

网站类型：网络搜索引擎

上榜原因：Google在上实际90年代后期才进入搜索市场，其实那时的市场已经相当拥挤了，但他们赢得了竞争，因为他们更快也更准确。现在它旗下有多款产品，如Gmail、Google Maps、Google+等等。它已经成了人们上网的一种方式。

via： bi

最新发表

您可能也喜欢：
内容型问答网站怎么盈利？	Myspace发布全新设计的社交网站	欲与Facebook抗衡，Google+须走非常道路	Facebook在美国推出免费的VoIP电话服务	Google赢得美国内务部3500万美元订单
无觅

2012年度全球移动应用市场分析报告

Tue, 19 Feb 2013 23:28:47 CST

本文作者易传媒移动平台总经理蒯佳祺。

著名移动应用市场和生态系统分析公司Distimo刚刚发布了2012年度的全球移动应用市场分析报告。较为突出的几点是Google Play增长迅猛，应用获得100万用户的时间大幅缩短，应用商店营收快速放大至70亿美金，应用强势整合，爆款应用掠走大部分收益，续收益已达总收益69%，超越下载收费本身。

最重要的一些数据和分析结果如下：

1.Google Play的增长极为迅猛。从2012年8月11月的四个月间，Google Play在全球主要的20个市场上日均营收提升为43%，同期苹果应用商店（包括iPhone和iPad）的日均营收提升了21%。

2.作为2012年最著名的AppZHIYI1,Draw Someting在上线后短短9天内达到100万用户，Facebook也花了9个月时间达到100玩用户。Draw Something的记录很快也被打破，在2012年11月，亚洲的应用开发商Naver发布了5款应用，其中Line Pop在短短72小时内就获得了超过175万次下载。

3.基于巨大的App下载量，应用商店的营收规模迅速放大。以2012年11月一个普通例子为例，苹果应用商店的单日营收就超过1500万美金，而Google Play的单日营收达到350万美金。

4.应用市场的强势整合正快速发生。在2012年11月，苹果iPhone应用商店里，仅仅7款应用就占到了整个应用商店10%的营收，而同期苹果的iPad应用商店里，仅仅6款应用就占了10%的营收。

5.对iPad应用最热衷的国家是俄罗斯，在俄罗斯所有的iOS应用下载中，46%为iPad应用。排名二三的是荷兰和芬兰，比例分别38%和35%。而对iPad应用最不热衷的是日本，在日本所有iOS应用下载中，仅7%是iPad应用。在某些市场，iPad应用获得的营收已经开始超过iPhone，比如俄罗斯。

6.2012年，在iOS app store和Android各大应用商店加起来实现了70亿美金左右的销售额，这包括下载App本身的收入，以及App后续升级和虚拟道具购买等后续收入。其中，后续收入所占比例提升得很快，从年初的53%快速增长到69%。在收入排名前10的应用开发中，65%的营收来自后续收费。

（若无特别注明，雷锋网文章皆为原创，转载请注明出处)
原文链接: http://www.leiphone.com/s-app-marketing.html

槐序 @雷锋网

我们持续跟进创业者团队采访，产品求报道，业界话题。如果您希望您的产品与团队有更多曝光的机会，欢迎联系：msso4u@gmail.com weibo:@Abeunt

最新发表

您可能也喜欢：
2012年中国移动终端市场发展趋势分析	王钟雄: 城镇移动互联网市场的12个现状	关于移动互联市场你所应该知道的	亿动广告传媒高照：移动游戏的广告盈利	中国成全球最大移动设备市场
无觅

BBC：Facebook，正在让人厌倦

Mon, 18 Feb 2013 12:50:04 CST

钛媒体注：本文摘选自 BBC 的一篇报道，在欧洲，人们对社交网络的疲倦感在加剧，包括一些曾一度以社交网络为经营重点的演艺明星。因为社交网络占用了人们太多的时间。在美国进行的，由皮尤互联网与美国生活项目所做调查结果也显示，61％的Facebook用户已经自愿暂停脱离社交网络一段时间。 27％的受访者计划今年会花更少的时间在社交网络上。这个变化趋势将在多大程度上影响社交网络的发展？社交网络正在失去它的魅力吗？

瑞安·维克特是一名演员。他居住于伦敦和柏林两地，一年前他曾是Facebook中的一名活跃用户。但是最近他的Facebook好友发现，自从圣诞节之后他的状态就一直没有更新。

“我正暂停使用Facebook，因为我不希望围绕着别人的一言一行而生活。我发现对我个人而言（Facebook上的好友状态)影响了我，我因此感到忧虑和羡慕。我慢慢变得不像是自己。”维克特这样告诉《BBC全球》。

“我不再专注于自己的事业和对我重要的东西，而是担心着别人所做的事。”这位演员说道。

其实发生在这位年轻演员身上的事情并不是偶然。事实上，这是一种规则。

因此，至少它符合了一个由皮尤互联网与美国生活项目所做调查的结果，该调查结果表明61％的Facebook用户已经自愿暂停使用Facebook一段时间。 27％的受访者计划今年会花更少的时间在社交网络上。

这个调查是在美国实行的，而在那里社交网络依然在人们生活中占主导地位：三分之二的成年网络用户使用Facebook，包括暂停使用的用户。

但是，虽然社交网络依然流行，人们的对待趋势却渐渐发生变化。

太多作秀

五分之一暂停使用的用户表示他们这样做只是因为“太忙”或者是“没有太多时间”花费在这个网站上。
但是最有说服力的数据是，将近三分之一暂停使用社交网络的用户这样做的原因出于：产生了类似于“不感兴趣”或是“厌恶”的排斥感（10%）、觉得浪费时间或有太多不相关的内容（10%）、只是觉得有太多作秀、闹剧、消极内容或冲突（9%）。

“我厌倦了那些愚蠢的评论”、“越来越无聊”、“对我一点帮助也没有”、“太多的作秀”或“他们甚至连晚饭都要发布出来”，这些都是研究顾问收到的受访者的意见。

更为极端的是，永久停用
有些用户的表现则更为极端。20%目前不使用Facebook的人之前确实曾是社交网络的一份子，但是他们已决定永久的放弃使用社交网络。

在一海之隔数千公里外的瑞安，费尔南达·贝克尔也决定停止使用Facebook，但这个停止是永久性的。
这位兼是新闻记者和律师的智利女士曾忘记了她的Facebook账号密码，在历经千辛万苦找回密码后，她觉得社交网络并不适合自己。

这是发生在4年前的事。但是直到现在，一些不知情的好友仍然会在她生日时（在Facebook上）给她送去祝福、（在状态中）提到她、在照片中圈出她。

甚至他们还“送”给了我新的个人主页和密码，一切都准备就绪只等我重新开始使用Facebook，但我却感到很厌烦，因为我没有那么多时间，因为当人们使用Facebook的同时也会失去另外一个社交圈。那些知道我不再使用Facebook的好友通过打电话或是发邮件联系我，而不是通过大量的信息留言。

同时也有一些人想离开社交网络，但却不能这样做。

但是，放弃社交网络也会付出一些代价。“不幸的是我不记得好友的生日，如果他们发布一些不雅的照片，我唯一的办法只能是通过一些非网络方式来维护自己的荣誉。”这位兼是记者和律师的女士开玩笑道。

没有什么是永久的

的确，现在的人们已无法永远弃用社交网络。至少在混杂的社会人脉中是如此。

虽然根据上述调查结果来看，用户已经调整了他们在社交网站上所花的时间，但是绝大多数的社交网络用户（92%）仍然拥有Facebook个人主页。

根据研究顾问给出的数据，在过去三年里社交网络用户数量（占互联网总用户数量的百分比）从47%飙升至69%。在平均一天中有一半以上的美国人使用社交网络。

（原文来自 BBC ，由译言深黑色翻译）

为了让你更久地沉浸于内容，Facebook已经花了1年多研发Reader项目

Mon, 24 Jun 2013 12:11:26 CST

Facebook 正在变成一份“个性化报纸”。马克·扎克伯格说“我们希望Facebook带给每个人世界上最棒的个性化报纸”，他也是这么做的。根据华尔街日报的消息，Facebook 正在做一个内部被称为 Reader 的服务，用户可以在移动设备上通过这项服务阅读来自出版商和其他 Facebook 用户的内容。

Facebook 开发这个项目已经超过了一年。知情人称，最新版本的 Facebook Reader 与 Flipboard 很像，后者目前有超过 5000 万名用户。知情人称扎克伯格把 Reader 项目盯得很紧。

尽管扎克伯格把“快速行动和打破常规”作为 Facebook 的公司理念，但是 Reader 这个产品的开发进度却显得相对的缓慢和从容。 知情人称 Facebook 尝试了各种方法来突出新闻内容，来帮助用户更加沉浸于内容里，更久地使用 Facebook。

毫无疑问，Facebook Reader 是他们朝着成为“世界上最棒的个性化报纸”的关键性产品之一，这或许是他们在这个产品的开发上花了如此多的时间、并如此慎重的原因。与之对比，Google 将于 7 月 1 日关闭旗下的阅读器产品 Google Reader，并在旗下的社交产品 Google+ 上投入颇多。这两家互联网巨头似乎是朝着完全相反的方向前进，未来会如何让人非常好奇。

目前还不清楚 Facebook 会在什么时候发布这个产品。

在国外，社交网络对电商的价值还微乎其微

Mon, 08 Jul 2013 10:31:15 CST

这年头做品牌推广和市场营销，不谈社交网络都落后了。社交的个人属性与传播性，可以做到更精准的推送与更佳的传播效果。不过遗憾的是，尽管具有诸多优点，但是在实际应用中，社交网络并未起到中流砥柱的作用，仍然处于起步阶段。

前不久 Emarketer 的统计数据就发现，Google 在广告市场占据着统治地位。尤其是移动广告市场，份额高达 56%，远高于排名第二的 Facebook，Twitter 的份额仅为 1.95%。

在在线零售这块，社交媒体的表现同样令人失望。市场分析机构 Custora 花了两年的时间，追踪了 86 家主流在线零售地址，捕捉分析了 7200 万用户的行为数据，包括跳转来源、购买金额、产品类别等等，发现传统方式带来的收益仍然遥遥领先。

两年时间，在线零售用户量增长了四倍。在 Google 统治下的搜索占据了 15.8% 的份额，CPC（cost per click）占据了 10%，即便是古老的（垃圾）邮件营销都占到了 7%。Facebook、Twitter 大概在不到 1% 左右徘徊。

在购买金额上，从搜索过来的消费者开销更大，高于平均值 50%，邮件点击用户高于平均值 11%。社交网络这块，Facebook 与平均值持平，Twitter 则比平均值低 23%。

Custora 的数据科学家 Aaron Goodman 认为，Twitter 的营销推广有很大的随机性，即便是用户看到了广告，几秒钟之内广告也会消失。

社交媒体在电商市场低迷的表现与其高活跃度十分不符。社会化营销优势有二：一是个人属性极强；二是传播性。对于品牌商来说，Facebook、Twitter 是建立品牌形象的利器，但是涉及到购买却“力不从心”。很大程度上，这与用户打开网站的目的有关。搜索的目的性很强，就是直接购买东西，而社交网络则是被动的吸引，属于购买计划之外。

相比之下，国内的社交网络与电商却结合的更加紧密。在微博上或者微信上，品牌商的活动经常能得到大量互动，通过微博推广营销早已成为狠多品牌商的首选。原因有很多，比如成本低廉、定位精准、互动强等，中国网名极高的活跃度对品牌商的推广也起到推波助澜的作用。

微博营销的火爆和微博的政策息息相关，微博早期放养了许多大号，利用这些大号，品牌商的广告可以轻轻松松覆盖上亿用户。且双方的互动十分频繁，根据 Alexa 的数据显示，3% 的淘宝用户在访问完淘宝后会紧接着访问新浪微博，3.2% 的新浪微博用户在访问后新浪微博后会紧接着访问淘宝网。

如此紧密的纽带关系，直接促成了阿里巴巴注资新浪微博，并为日后社交服务电商做出示范，这些或许都可以为国外社交网络提供一些借鉴。

题图来自 Wired

王超文

关注科技，热血而沉着，极致而纯粹。努力做一个理想主义者。

邮箱

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 · Beats of Bits | 原文链接 · 查看评论 · 新浪微博 · 微信订阅 · 加入爱范社区！

Graph Search：貌不惊人的颠覆者

Wed, 13 Feb 2013 06:00:54 CST

尽管年轻的Graph Search暂时还无法对传统搜索形成全面冲击，但它未来颠覆的将可能是整个互联网以流量为核心的商业模式。

1月16日，Facebook发布了社交图谱搜索——Graph Search，这是Facebook自去年5月上市饱受质疑近8个月后做出的最大的动作，扎克伯格亲自主持产品的发布，足见其不容忽视的里程碑意义。

比起1月16日之前媒体猜测的“Facebook会推出自己的手机”这种劲爆消息来说，Graph Search看起来似乎不那么让人兴奋，然而，不要忘记，扎克伯格是一个掌握着10亿用户、以“接管世界为己任”的CEO，因此我们有必要在纷繁的新闻背后去冷静思考，Graph Search究竟意味着什么。

Graph Search是什么？根据扎克伯格在发布会上的视频演示，它的功能是让用户能搜索到社交链上的信息，例如“我朋友都喜欢那些纽约的餐馆？”，“我去年和某某人的合照”、“我朋友去过的国家公园”等。

用创新工场CEO李开复的话来说，技术层面Graph Search的价值在于：1.自然语言理解（把用户输入转换成一个数据库要求），2.获取和挖掘用户的信息（包括主动和非主动输入的，例如社交链、点击习惯，like等），3.把海量的用户信息转换成为巨大的数据库。

IDC市场研究公司分析师Karsten Wide曾经说过，“倘若Facebook决心认真发展搜索，势必与谷歌展开激烈竞争。”

长久以来，谷歌一直是搜索领域的王者，基于搜索带来的广告收入也支撑着其绝大部分利润，然而，自从Facebook引领的社交网络时代到来，人们就一直期待着它能在谷歌之外为搜索带来些新的东西。

正如凯文·凯利在2009年时期待的：“我一直在思考谷歌以及搜索引擎的未来。很显然，互联网上的点击量多于链接量。也就是说，相比于做链接，人们更常做的是直接点击。然而就我所知，PR值以及其他的搜索索引排名算法主要还是依据权重链接的数量。将大众在网站中点击的智慧包含进来不是更好吗？”

事实上，Facebook这一次确实是不负众望。相对于传统的搜索引擎，Graph Search 能为用户呈现与自己信息相匹配的个性化结果。如果你觉得抽象，那我们举个例子，比如在 Graph Search 上你可以搜索“我朋友中谁喜欢星球大战和哈利·波特？”而谷歌则在为能够精确搜索“世界上最深的10个湖是什么”而努力。

简单地说，谷歌希望自己的搜索未来成为知识引擎，更加智能化地进行信息整合，而Facebook则更关心帮助你快速找到你的好友更喜欢什么。

大数据的价值释放

为什么关注“你的好友更喜欢什么”如此重要？我们不妨从Facebook在发布Graph Search 前的一系列重要产品铺垫说开去。

Facebook早期增加的一个重要功能是News Feed，它通过新闻的推送让人们可以知道身边的世界正在发生什么事，随后的一个里程碑性产品则是Timeline，帮助人们知道其朋友过去的历史，事实上这是一种让用户信息从现实向虚拟的迁移。还有一个不能不提的功能就是Like了：在经典的搜索中搜索对象是网页，决定搜索结果中网页显示顺序的联系主要是链接。简单来说，链接就像投票，它们帮助搜索引擎决定特定主题应显示哪些最热门的页面。而在Facebook图谱搜索中，搜索对象不是网页，而是现实对象的虚拟表示：人、地点和事物。对象间的联系主要由Facebook “Like”决定。正是这些“Like”将Facebook上的信息联系起来了。

Graph Search的出现，让之前存在多时的Like按钮开始释放出巨大价值，让信息变成数据，让虚拟照进现实。

众所周知，Facebook是全球最大的社交网络，然而它的真正价值却并不是社交，社交只是工具和手段，Facebook的核心价值正是在于它掌握的海量数据金矿——10亿名用户、2400亿张照片和1万亿次页面访问量。

Graph Search的出现让这些数据的价值开始得到释放，在Facebook这个自成体系的庞大而封闭的帝国中，未来的人们可以通过朋友的推荐去找饭馆，找工作，甚至是购物决策。

这也难怪国外网站已经开始高呼Facebook将借Graph Search进一步冲击Google、Yelp、Foursquare、Pinterest、雅虎、Twitter、维基百科、微软等几乎所有主流互联网公司。这当然是媒体过于乐观的意愿，且不说Facebook在战略上是否会如媒体臆想的一般四处出击，单是改变用户习惯就是一个需要付出巨大成本的漫长过程。

威胁传统流量模式

其实，无论Facebook是否能够借Graph Search迅速形成商业循环，一旦其背后的用户价值得到释放，都将会深刻影响人们获取信息和做决策的方式，而这才是令现今所有成熟互联网模式都会感到毛骨悚然的。

众所周知，互联网发展20多年的商业模式的根基一直是广告，而广告则是一个基于流量的生意，搜索引擎之所以赚钱正在于其强大的流量搬运能力，归根结底，任何搜索引擎做的都是流量分发的事情。

然而，Graph Search的出现则有可能率先对展示广告造成冲击：过去的广告基础是人们主动的搜索，通过用户搜索时的关键词较为精准地找到目标客户；Graph Search则更像是一种相对被动的推送，通过朋友关系做导引来引导人们做决策，一旦技术的影响扩散到了人们的决策过程，许多既有的商业模式都将在未来数年之内面临重新的考量。

比如，当你第一次来到加州，想要找一家特色餐馆，过去的做法是会主动在搜索引擎上按一定条件搜寻目标；今后可能会有越来越多人习惯去先找找朋友们推荐过（点了Like）的地方，一方面人们更容易信任身边朋友的推荐，另一方面做出基于朋友推荐的决策也更容易增加在朋友圈中的谈资。

这样一来，广告商们会不会需要重新去考虑广告的投放效率：究竟是去精准地影响用户身边的朋友推荐更有效还是按照流量大小投放展示广告更加合算。

设想一下在未来，推荐会不会在越来越多的场合代替信息的检索？基于内容的搜索是否也将逐渐向基于关系模式匹配的搜索演化，甚至将会威胁到整个传统互联网的流量模式？这些都是Graph Search带给我们最迫切需要思考的问题。

北美互联网公司求职记

Sun, 30 Dec 2012 10:37:54 CST

本文作者 @zellux，雷锋网已取得作者授权，原文链接。

最近签掉了 offer，找工作的事情算是告一段落。在这里写一点面试体验和心得，希望对有兴趣去北美工作的朋友有所帮助。

先简单介绍下自己，国内硕士在读，明年毕业，没有牛 paper，也没参加过 ACM-ICPC 竞赛。在实验室做过内核、虚拟机和 Android 底层相关的研究工作，接过一些网页和移动开发的外包，2011 年开始在字节社兼职负责后台开发。另外也经常上 Stackoverflow 和 GitHub。

这次决定直接申请美国的职位后，由于心里没底，不知道国外公司招聘的难度，所以一开始投了很多公司。几个大公司都找人内推或者直接投了，小公司也投了不少，比如 Foursquare、 Path、 Pinterest 和 Square 等都试了。当时甚至在手机上找了一圈应用，把可能涉及后端开发的应用都投了一遍。不过大多数公司都没给我安排面试，只有 Microsoft、 Google、 Facebook、 Twitter 和 Hulu 这五家公司愿意给我面试机会。

一般来说，国内毕业后直接投国外公司，会比出国留学毕业后找工作的难度大一些。除了语言因素之外，我了解到的主要原因在于工作签证，出国留学毕业后可以通过 OPT 签证入职，之后再过渡到 H-1B 签证。而国内毕业的学生只能通过 H-1B，这意味着要等到第二年的十月份才能入职。好在 Google、Facebook 等公司不太介意这个问题，还是会欢迎国内的应届生申请。

校招的 HR 一般会有各自的职责。比如 technical sourcer 负责发现有希望进入自己公司的应届生；recruiter coordinator 会帮助 recruiter 安排面试者的面试时间、面试官，以及 onsite 面试时帮助面试者订机票和酒店；staffing consultant 则负责发 offer 以及介绍公司的具体福利制度，并解释面试者相关的问题。不同公司的 HR 职责的分法自然也不一样，我在 Facebook 的面试过程中只和两位 HR 联系过，而在微软的面试过程中则联系过五六位 HR。

在面试流程方面，相比我了解到的国内公司的面试，国外公司的面试安排上会更人性化一些。例如安排面试时间时，HR 一般会先让你给出几个空闲的时间点，然后他们再从这些时间中给你安排面试。此外在为你安排 onsite 的住宿时，也会询问你有没有相关的要求。

关于面试题目，大多数公司都比较侧重面试者对基本的数据结构和算法的掌握程度，以及把这些内容实现为实际代码的能力（一般会要求你选一个语言实现，而不允许用伪代码）。越是规模大的公司越注重这些基本功，而小公司除此之外还会考察你的开发经验，例如对某个框架的了解和性能优化方面的技巧。关于这一点区别我的理解是大公司里面会有自己的框架和开发工具，面试者的基本功好就能比较快的上手；而小公司一般用社区现有的工具，所以已有的开发经验可以直接用在将来的工作中。

下面是这几个公司的面试细节，有些公司因为在 onsite 面试的时候签了 NDA，所以没法透露具体的面试题，还请见谅。

Microsoft

微软是我最早投的公司之一，托了在微软总部工作的一位学长帮忙内推。面试包括一轮 HR 面和四轮 onsite 面。

申请了一个多月后一直都没有反应，直到微软国内招聘的前一天，北京的 HR 打电话问我是不是投过微软的职位，要我参加第二天上海站的笔试。

笔试过后，又过了一个多月，收到了微软一位招聘人员的邮件，问我是不是对微软北美的职位有兴趣，要我填一份基本情况的问卷，里面有问到其他公司的面试进度。我当时已经收到了 Google 和 Facebook 的面试邀请，就如实填写了。回复第二天后就收到了邮件通知，告诉我会有 HR 进一步跟进。第三天有一位 HR 联系我和我约电面的时间。微软约电面的方式和其他公司不大一样，HR 会给出很多个选项，让你在里面选择几个空闲的时间。另外值得一提的是这些时间都转成北京时间了，这也是微软在安排面试时比较人性化的一个地方。

第一轮面试是 HR 面。HR 先问了一些技术无关的问题，比如喜欢做什么，工作地点的偏好，什么时候开始学的编程，为什么投了微软等等。接着是一些智力题，比如 9 个小球，8 个质量相等，另一个比其他的重，如何用天平称两次把它找出来；公司开发了一种新键盘，有哪些测试它的方法；在会议室内怎么估计室外的温度。都是些更像是考验英语水平而不是技术能力的问题。

面完第二天收到了 onsite 的通知。虽然是北美的职位，onsite 面试地点却是在上海。我参加的是周日的面试，和我一起参加面试的还有一位学生，他之前在微软实习，了解到这次有去北美工作的机会后也想尝试下。面试官是从总部飞过来的工程师，一共有四位，其中三位都已经是 principal 级的了。HR 提到一般技术面试要五轮，因为我们之前参加过一轮笔试，所以只需要面四轮。

onsite 面每一轮的过程都差不多，都是面试官自我介绍，接着我介绍自己和做过的一些项目，然后开始技术问题，最后是我提问的环节。微软的面试问题会考察面试者编码、设计和测试三方面的能力。

coding 环节要求直接在白板上写代码，我被问到两个 coding 问题。一是如何检查一棵二叉搜索树是否正确，二是写一个解数独的程序。第一个问题写起来很快，第二个问题因为时间有限，我先写了一个没啥剪枝的暴力搜索的版本，写完后和面试官分析了可以在此之上做的优化。

设计方面的问题有两个。第一个问题是设计一个分布式的数据管理系统。使用场景可以是一个连锁店信息的记录系统，每个分店都有可能更新自己的信息，并把这些改动传播到整个系统中。在设计这一系统的同时要考虑性能、容错、一致性等要求。我一开始想了一个基于 push 的机制，在面试官指点下逐步优化，最后还是有不少问题。于是干脆重新设计了一个基于 poll 的系统，优化改进之后面试官满意了。

另一个设计问题和类的设计有关，要求设计一个包含图形界面的棋盘游戏。因为之前做过不少相关的开发，所以这一部分我还挺擅长的。按照 Single Responsibility 的原则设计了几个分工明确的类，另外把网络对战和 AI 接口都考虑进去了。设计完成后面试官要求我从用户鼠标单击这一事件开始介绍整个控制流程，在某些类中还会问及这么设计的原因，以及和其他设计方案相比的优缺点。

测试部分的问题也有两个。第一个问题是如何测试一个随机函数。第二个问题和分布式系统有关，面试官先向我介绍了一个分布式系统，包括它的使用场景和基本的架构，然后问我其中某一个部件应该如何测试。提到正确性、可伸缩性、一致性和容错性后再给出相应的测试方法应该差不多了。

onsite 面试后的第二天后就收到了 HR 的邮件，祝贺我拿到了 offer，并和我约时间谈具体的 offer 细节。虽然微软一开始拖了两个多月才开始安排面试，但是一旦开始面试后他家的效率非常高，是这次面试的几家公司里效率最高的了。

Google

Google 面试也是托学长推荐了。HR 说我的简历看起来很不错，先给我安排了两轮电面。

电面都和 coding 有关，面试官会给你一个 Google Docs 链接，在电话里描述题目后要求你在 Google Docs 上写程序。题目的难度不高，两轮一共四题，都是对基本数据结构的操作，例如给在一个未排序的数组中去掉重复的数字，还有把一个有序数组转成一个平衡二叉搜索树，在一个已排序但有重复数字的数组中查找元素等。

第一轮电面聊天的时候还发现第一轮的面试官是在 ITA Software 做的。正好前几天用他们的产品 Matrix Airfare Search 订到了低价的去土耳其的机票，过了一星期神奇的在面试的时候碰到了这个团队的工程师。当时一下子就兴奋起来，聊了不少和 Matrix 的有关的话题。这位面试官听说中国的机票也能用他们的平台查询，还挺吃惊的。他还提到他们原本想把计算任务放到 Google 内部的计算框架上，但是由于和合作方的合同的限制，没法把一些商业数据放到 Google 的平台里，只能继续用原有的计算引擎。

第二轮电面的面试官是位印度人，虽然我很难听懂他的口音，但是他很耐心，会和我重复描述问题，所以题目做下来也没啥困难。在和他的聊天中得知他除了正业（Youtube）外还在闲余时间研究机器人。

电面结束后第二天收到了 HR 的邮件，邀请我去总部面试。由于当时已经是九月底了，而我十月初打算去土耳其玩两星期，于是只能从土耳其回来后开始准备签证了。Google 的 HR 非常热情，每次回邮件都很及时，经常能在加州时间晚上十一点左右收到她的邮件。她帮我弄来了 Google 的面试邀请信，顺利的过了签证面试。之后另一位 HR 还帮我订好了从上海往返 San Jose 机场的机票，以及三晚的住宿（因为考虑到我需要倒时差，多了一晚住宿，这一点也很体贴）。

Google 给我安排的住宿是 Wild Palms Hotel，在 Sunnyvale。不愧是硅谷的旅馆，每天早上起来吃旅馆的早饭，都能听到有人讨论 Java。在 Sunnyvale 的第二天我坐公共汽车到处逛了逛，考虑到接下来要在加州玩一圈，就办了张 T-mobile 的一个月电话卡（60 美元，包括不限量的短信、通话和 3G 流量，但是这家的信号非常差）。这家旅馆和苹果总部也很近，出门有公交车直达，作为半个果粉自然不会浪费这个机会。

第三天在 Google 工作的学长开车带我去了公司。Google 的园区里有不少免费自行车，没有锁，直接就可以骑。我在 Google 商店买了点礼品，在园区骑车转了一会儿后就开始面试了。

面试一共有四轮，每轮 45-55 分钟，中间有 5 分钟的休息时间。中午会有 Google 工程师带你吃饭。带我吃饭的 Google 工程师也是中国人，了解到这点后我们就知道用中文聊天了。吃饭时间里了解了不少在 Google 工作的优缺点，也一定程度影响了我之后做的决定。

由于签了 NDA，没法在这里透露具体的面试题目。面试主要都是算法题，比电面难一点。除了算法题外我还被问到一个分布式系统的设计题，以及一个多线程相关的 coding 题，后者用信号量很容易解决。其实如果能和面试官好好交流，这些题目做出来应该是没啥问题的。

面完第二周 HR 通知我拿到 offer 了，打电话告之了 offer 的具体细节。Google offer 的邮件附件还包括一份各项福利的介绍，着实吸引人。我还记得 HR 打电话来的时候我正好在三藩 Exploratorium 边上的小湖旁，在湖边美景中听到这样的好消息自然分外兴奋。HR 还告诉我没有限制我的签约时间，可以在任意长的时间后再做出决定，也算是 Google 非常体贴的地方。另外具体的职位会在入职前一段时间决定，HR 的说法是可以根据自己的喜好在一些项目之中选择。

Facebook

我在今年三月份投过一次 Facebook 的暑期实习，被告之已经招满了，接下来校招时会再联系我。七月份的时候我又在网站上投了一次开发职位，还麻烦一位在里面实习的学长帮我内推了。八月一位 HR 联系我安排第一轮面试，电面安排在了九月。

Facebook 的 HR 也很负责，她在电面前几天打电话和我聊天，介绍 Facebook 的基本情况，以及面试流程。第一轮电面结束后的情况分三种，如果面试表现很不错，那就直接获得了 onsite 的机会；如果面试表现一般，面试官不确定要不要，就会再加面一轮；如果面试表现不好，就可能直接被刷了。除此之外 Facebook 的 HR 比较体贴的一点在于给中国人安排的第一轮面试官很有可能也是个中国人，降低了语言上出现问题的可能。

HR 的电话里还提到 Facebook 入职后有六星期的 bootcamp，可以熟悉各个项目和团队，具体的项目是 bootcamp 结束后自己选的。问了一下在那工作的朋友，做出的选择一般都会被满足，因为 bootcamper 的选择分布还算比较平均的。

Facebook 电面和 Google 差不多，是在 collabedit 上进行的。也是面试官在电话中口述题目，我在网站上写代码。老实说这个网站的体验不怎么样，面试过程中出现过几次我这边写的代码没在面试官那里出现的情况。好在面试官比较有经验，一发现有问题就会提醒我刷新页面。

第一轮电面我做了三个 coding 题，题目都不难，但是要求 bug free。电面的面试官抓 bug 的能力着实厉害，找出了两个我一开始没发现的 bug。好在他提示说有 bug 但没指出的情况下，我把它们都修正了。面试题目难度和 Google 的电面难度差不多，都是对数组、二叉树和字符串的基本操作。第一题是把一个字符串中的 %20 都转成空格，第二题是按层打印一棵二叉树，第三题是找出两个有序数组里不同的数字（类似求集合的异或）。程序正确后面试官还会问一些优化方面的问题，例如在不同的情形下应该使用哪一种算法。

面完后第二天收到 recruiter 的消息说我拿到 onsite 的资格了，具体的时间会在十一月通知我。

Facebook 给我安排的酒店是 Palo Alto 的 Sheraton。酒店门口停着不少出租车，面试那天的出租车司机还是用 Square 收的钱。我的面试正好赶上了他们的 University Day。这一天的安排是上午三轮面试，中午吃饭，下午逛一圈公司以及三场讲座。我的第三轮面试还出了点茬子，面试官一直没出现，HR 只能先带我去吃中饭。中饭结束后 HR 带着别人边逛公司边介绍，我只能继续我的第三轮面试了。

Facebook 校招时本科生和硕士生是统一级别的，面试只包括算法题，不会有设计题；而博士生则高一级，面试的时候还会有设计题。三轮 onsite 面试包括一轮 jedi 和两轮 ninja。jedi 面主要是让面试者介绍自己的项目经历，了解面试者的技术专长和偏好，不过面试官也让我做了一个简单的 coding 题。ninja 面各有两个 coding 题，题目难度都不大，和电面差不多。但是与电面不同的是，面试官会深入问一些细节的问题，例如代码里生成了多少个新的对象，有没有办法优化等，有一个问题还要求我用一种算法实现后，再用另一种完全不同的思路实现一次。（onsite 面试是签了 NDA 的，这里就不方便透露具体的题目了）

面试完之后有三个讲座，第一个讲座介绍了 Facebook 总体的工作环境。第二个分产品和后台两个讲座，同时进行所以只能选一个。我一开始选择了后台开发，不过当时突然对产品有了兴趣，就去听了产品的讲座。一位负责 Events 开发的工程师结合这个产品介绍了下 Facebook 内部产品开发的流程，例如新特性是怎么出来的，如何测试等。最后一个环节是几位刚从 bootcamp 毕业的员工和我们分享他们在 Facebook 中工作的感受。

University Day 结束后，参加活动的每位学生还收到一个包装精致的礼物。拆开来后是一块两面分别刻着「Move fast and break things」和「Proceed and be bold」的玻璃砖。我还是很喜欢这个礼物的，这也一定程度上影响了我最后的选择。

面试完第二天 HR 从我这里要了三位 reference，包括他们的职称和联系方式，接下来 HR 会联系他们询问我的情况。Facebook 的动作也很快，第二周就给我发了 offer。有意思的是，offer 邮件的 welcome package 最后一页建议面试者在入职前熟悉一下 Unix，还推荐了几篇文章和两本书。

Google 和 Facebook 的 onsite 是在同一星期面的，前后只隔了一天，收到 offer 的时间也只差了一天。package 方面， Facebook 比 Google 的要好不少，但是 Google 的 HR 说可以 match Facebook 的 offer。去之前我想过如果两个 offer 都拿到，那就去 Google。但是到了这两个公司，和几位面试官以及在里面工作的朋友深入聊天后，最终还是选择了 Facebook，因为它规模更小，应该能有更多的锻炼机会。

另外我了解到的 Google 和 Facebook 的面试流程都是先由各位面试官给你打分，例如分 strong hire / hire / weak no hire / strong no hire 四档（不一定完全一致，比如可能会多一档 neutral）。同时要写下关于你的面试情况的报告。再接着由 hiring committee 讨论要不要给你 offer，以及 package 如何。有亮点（某位面试官的 strong hire）很重要，一个 strong hire 和几个 weak no hire 会比平庸的清一色的 weak hire 好。

Hulu

Hulu 是这几个公司里唯一一个我没有找人内推而拿到面试机会的，也是面试体验最好的一个公司。Hulu 和 Twitter、Zynga、Foursquare 等公司一样，用了 jobvite 接受和追踪职位申请。因为是申请的第一家公司，我在申请 Hulu 时的 cover letter 写得很详细，针对职位需求上的每一条都写了我的相关工作经验，这也许是最后能拿到面试机会的原因吧。其他公司的 cover letter 都写得很简单，短短两段就结束了。

Hulu 的第一轮电面和其他公司的有些不同。45 分钟里要做四个题。面试官提前十分钟发了一封邮件给我，上面有两段代码。第一段代码是一个检查两个字符串是否是 anagram 的程序，写得很绕而且性能很差。面试官先问我这段代码的用途，然后问有什么方法优化，并要求我把代码写在 titanpad 上。接着他问了我第二段代码是做什么的。第二段代码也写得有点复杂，不过可以看出是一个检查有向图里面是否存在环的程序。

然后是设计题，要求设计一个 LRU Cache，只要说出接口、用到的数据结构和大致的算法就可以了，我想了个用一个 LinkedList 和一个 HashMap 的方案。

第四题还是代码题，写一个合并两个有序链表的程序。

面完后还有点时间，我们就聊了聊。面试官是在 Hulu 做支付的，主要用的语言是 Scala（Hulu 里面各个团队用的技术都很自由，可以选择自己喜欢的语言开发，Python Ruby C# Java 都有）。我当时正好在字节社做 iOS 上的应用内购验证，就问了他有没有处理黑卡坏账方面的经验。可惜 Hulu 在 iOS 上只有订阅方式的支付途径，没有 non-consumable product 的相关经验。

面完后 HR 给我安排了第二轮电面。面试官来自法国人，是 FFmpeg 的维护者之一。面试官看我简历上有星际比赛的奖项，还当过校队的队长，就和我聊起了星际2的平衡性。接着说到最近的虫群之心 beta，他觉得改动没有当年母巢之战的有意思，因为前期的改动不大。

聊了二十分钟的星际2后才切入正题，coding 题很简单，就是在一个数组里找出两个数，使得他们和为给定的数。写完这个最基本的版本后还有些别的变化，比如如果所有的数都是一定范围内的正整数，这时可以用一个数组统计每个数字的出现频率。

二面结束后等了三星期还没有消息，不知道是默拒了还是 HR 忘了。三星期后我又写了封信询问我的二面结果，HR 回信说欢迎我去他们公司 onsite 面，之前校招忙把我忘了。

Hulu 的总部在洛杉矶，Santa Monica 附近，离海滩只有几公里的路程。一进面试的会议室就看到白板上写着「Welcome Yuanxuan to Hulu」，一下子对这个公司充满了好感。

Hulu 的 onsite 面试题是面过的几家公司里最难的，一共有四轮。前三轮由来自内容团队、API 团队和架构团队的工程师面试，最后一轮的面试是 CTO 亲自面的。题目也是涵盖了算法、设计和实际的编码，有一轮的问题从设计一个分布式系统开始，讨论了这个系统的身份验证、数据分片、原子性、容错等问题的设计，考察了很多细节的地方，最后还让我写了 SQL，以及如何优化这些查询指令。不过我对 SQL 很不熟悉，每次用都要查手册，当时用了 ActiveRecord 的查询接口代替。

CTO 面完后 HR 进来问了我有没有其他公司的 offer，接着带我逛了一圈 Hulu 的工作场所。Hulu 总部只有 40 位左右的工程师，大家相互之间都很熟，气氛非常好，也比较自由。逛完后 CTO 带我出去买了杯咖啡，在回来的路上给我发了 offer。Hulu 的 package 和 Facebook 的在数额上差不多，但是因为公司性质的问题没法发股票给我，只能用相近的奖金代替。

回到公司后，CTO 问我对哪个团队比较有兴趣，我说如果我最后签了 Hulu 的话应该会想去做后端。HR 就安排了这个团队的工程师和我一起出去吃晚饭，还给了我两张 voucher 用于支付回去的出租车。当时因为觉得去 Hulu 可能性不大，觉得对方这么热情实在不好意思，可是还是推脱不掉，只得跟着他们去了附近一家餐厅。因为 Hulu 主要内容是美剧和电影的，饭桌上讨论的主题也是各种电视剧，还提到接下来 Hulu 可能会搬到附近另一个办公楼。

最后还是没有接受 Hulu 的 offer，虽然对他家印象非常好。一方面我更希望在湾区工作，另一方面小公司吸引人的一个点在于初期的股票，由于 Hulu 没法发股票所以这个优势也就没了。

Twitter

Twitter 用的也是 jobvite 的招聘系统，我麻烦了一位在里面工作的学姐帮忙内推。据说 Twitter 相比其他互联网公司 work-life balance 是比较好的，工作会相对轻松。而在给我安排面试时 HR 给出的可以约的最晚的时间点，也是几个公司里最早的，于是我只能很早起床等待面试官的电话。

第一面是一位负责移动端网页前端开发的工程师面的。他说我的简历上工作经历很丰富，就不让我做 coding 题了，让我谈谈做过的这些项目。谈完项目后又进入了聊天时间，我提到喜欢 Twitter 的一个原因在于他有很多好用的开源项目。比如我平时写一些小型的 web 应用都会用 bootstrap，省时省力；而我之前实习的时候做的一个分布式的内容下载系统，也参考了 murder 的实现。另外因为当时我在实现字节社 iPhone 和 iPad 的 web 界面时碰到了之前修复的 bug 后来再次出现，忘了测试的情况，就问了他 Twitter 是怎么做移动端 web 界面的测试的。结果面试官说他们也基本上是买一堆设备然后人工测的，倒是桌面端可以用 Selenium。

愉快的结束第一面后，就开始了略有点无语的二面。我的二面前三次都没面成，第一次被放鸽子了；第二次面试官是 iOS 团队的，听我介绍完自己想做后端时，说他面我不合适，会让 HR 再帮我重新安排一轮；第三次再次被放鸽子，面试官那天很忙，抽不出身。每次面试失败后都要再等一星期才能收到 HR 的消息，所以光二面就拖了一个月。

第四次二面终于面成了。我听面试官介绍应该是来自平台相关的团队，不过面试官接着问我是喜欢写代码还是喜欢倒腾环境的时候，我说喜欢写代码，结果面试官说他的团队主要是做运维的，开发的工作量很小。估计是考虑到之前已经放过一次鸽子了，这次面试官还是继续面下去了。

虽然运维团队本身不是我喜欢的，但是面试官的问题相当对我胃口。一上来就是一连串的几个关于僵尸进程的问题：什么是僵尸进程？如何列出所有的僵尸进程？如何获得这些僵尸进程的 PID？如何把它们终止？我用 ps grep awk xargs 配合管道把这几个问题用一行命令行解决了，他很满意。

第二问是统计一个 httpd 的访问日志中，访问量最大的前五个 IP。我用 Ruby 写了一个，六行代码就能搞定。

接着面试官了解 DNS 吗，如果浏览器没法上网一般怎么诊断？我的回答是先 dig 看 DNS 解析是否正确，然后用 ping 判断 IP 是否可以访问，再用 curl 看是不是浏览器设置的问题。最后还可以用类似 www.websitedown.info 的服务检查。

第四个问题是怎么把一个文件复制到多个机器上？我说可以先用 ssh-copy-id 把公钥拷过去，然后再用 scp 拷文件。面试官说这样机器多就麻烦了。我解释到可以用 expect 写脚本自动输入密码，还加了句当然也可以用 Twitter 的开源工具 murder 分布式部署。

第五问是文件系统中 soft link 和 hard link 的区别。我的解释是 soft link 是一种特殊的文件，它的内容是被指向的文件的路径，而 hard link 是直接指向 inode 的。所以 soft link 可以用于目录，但是 hard link 不可以。

文件系统中 inode 和 path 的区别。我回答是 inode 是文件系统的一个数据结构，指向某个磁盘上的文件；而 path 是由多个 struct dentry 组成的，每个 dentry 描述了 inode 的父子关系。

最后一问是如何修改 DNS 服务器？我说可以修改 /etc/resolve.conf。

感觉 Twitter 的电面题会包含不少概念题，当然也有可能是运维团队的特点。几天后我收到 HR 的邮件，告诉我两位二面面试官都表示我对他们的团队不怎么感兴趣，而除了这两个团队外目前还没有其他团队可以给我安排面试。估计从此就进入等待列表了，没能去总部 onsite 面试，我在签掉 Facebook 后就联系 HR 把招聘进程终止了。

后记

最后签了 Facebook，等着下一步关于工作签证手续的通知。mm也表示愿意和我一起去美国，她应该会先在那里读个硕士再找工作。

希望接下来的签证手续等事情都一切顺利了。

DEC 24TH, 2012 • Permalink

（若无特别注明，雷锋网文章皆为原创，转载请注明出处)
原文链接: http://www.leiphone.com/s-microsoft-twitter.html

槐序 @雷锋网

我们持续跟进创业者团队采访，产品求报道，业界话题。如果您希望您的产品与团队有更多曝光的机会，欢迎联系：msso4u@gmail.com weibo:@Abeunt

最新发表

您可能也喜欢：
借助Facebook和Twitter获取新闻用户只有9%	Twitter该向Facebook学些什么？	继Facebook后，最值得期待的11家准上市科技公司	Hulu通过Facebook Connect增加社交功能	Facebook雇员在Twitter上（已删除）泄密Facebook Music杀手级功能
无觅

Facebook即将发布新版New Feed，可否改变Facebook现状帮其提升营收潜力？

Mon, 04 Mar 2013 11:52:10 CST

【i黑马导读】Facebook在上周五表示，将于3月7日在美国加州总部举行发布会，发布这一新的动态汇总(News Feed)设计。这是今年到目前为止Facebook第2次重要的产品发布活动。今年1月，Facebook发布了社交图谱搜索功能。

Facebook的News Feed中展示了用户好友网络中的照片、视频和评论更新。扎克伯格曾表示， News Feed是Facebook服务的“3大支柱”之一，另两大支柱分别为搜索和用户个人页面。 News Feed的上一次升级还是在2011年9月。

TechCrunch一月曾报道，Facebook正在测试全新的News Feed页面，新版将放弃传统的蓝白颜色风格，将会兼容移动设备，支持全屏幕显示，将有更多的图片。

此前，包括马克·库班在内的名人用户已经对Facebook现有的News Feed功能发表不满意见，比如来自Pages的信息并未获得妥善显示。

不过，媒体们关心的似乎并不全是 News Feed 的界面设计，因为这款产品不仅为 Facebook 带来了巨大的流量，与此同时，News Feed 还帮助这家公司提升了营收潜力。

巨大压力让 Facebook 不得不以丰厚的广告利益牺牲用户体验，因此即便 News Feed 已大不如前，但这款产品仍是 Facebook 社交体验的核心。

另一方面，由算法驱动的 Facebook 实时社交数据收录工具也让用户欲罢不能，因为 Facebook 能够将你的数据串联起来并进行分析。很多时候，当你将自己的资料与信息交给 Facebook 时，他就能在某个意料之外的时间告知你一些根本看似不可能的事情。虽然 News Feed 的这些特征让用户爱不释手，混乱的界面却也让他们悲愤难平。

新版的 News Feed 可能会移除部分微观管理入口，然后加入维护相关信息流的功能。另外，Facebook 可能还会重新考虑那些决定 News Feed 中显示内容的程式，以便更好、更集中化地控制排序和隐藏某些内容。

您可能也喜欢：
讲中国？Facebook的群狼对手	Facebook收购Atlas欲与Google抗衡	泰格医药：黑马营走出的第一家上市公司	Facebook也要出手机了？	河南商人曝光14个乡镇和县政法委吃回扣收礼金
无觅

IT瘾facebook推荐

来自Facebook的一些MySQL运维经验

浅谈移动应用的跨平台开发工具（Xamarin和React Native）

相关文章

应用分发当年的大戏要重演了，只是这一次主角变成了新媒体内容

Presto 来自Facebook的开源分布式查询引擎

Instagram: 2年10亿美元背后的技术架构

Facebook创始人扎克伯格亲自审查核心代码

新媒体最重要的三件事：分享，分享，还是分享

为什么移动搜索产品都那么糟糕？

新闻阅读器Paper对Facebook有多重要？

WhatsApp日消息420亿条，值190亿

190亿收购WhatsApp，Facebook的焦虑症

2013 年 Facebook 在开源方面的工作回顾

手机

Web

数据

基础设施项目

2013年我们的开源项目…

…以及未来

相关文章

报告揭示美国几大知名社交网站的用户特点

Nielsen 报告指出，用户开始拥抱智能手机 App 而摒弃传统 Web 网页服务

Facebook开源闪存数据库RocksDB

WhatsApp估值的四个支撑点

Facebook 数据揭露年龄与兴趣之间的关系

谈谈Facebook的聊天系统架构

Related posts:

为什么2012年HTML5发展远未达预期

1.跨平台HTML5开发并未起飞

2.人们更习惯于通过应用商店下载应用

3.混合应用不能依赖移动浏览器

4.不同移动设备间的适配问题

5.HTML5还不够强大

社交网络崛起

相关文章：

提高软件质量实践―― Facebook 篇

相关文章

Facebook推社交搜索工具 挑战谷歌威胁Yelp

告诉你美国最火的15个网站

2012年度全球移动应用市场分析报告

BBC：Facebook，正在让人厌倦

为了让你更久地沉浸于内容，Facebook已经花了1年多研发Reader项目

在国外，社交网络对电商的价值还微乎其微

Graph Search：貌不惊人的颠覆者

大数据的价值释放

威胁传统流量模式

相关文章：

北美互联网公司求职记

Facebook即将发布新版New Feed，可否改变Facebook现状帮其提升营收潜力？

Facebook推社交搜索工具挑战谷歌威胁Yelp