C语言产生满足正态分布的随机数

C语言中可以通过rand函数生成满足均匀分布的随机数,但是生成满足正太分布的随机数就没有那么简单了,下面对常用的几种方法进行总结并用C++编程实现。

方法一:由均匀分布的随机数来产生

一个简单可行的并且容易编程的方法是:求12个在(0,1)上均匀分布的和,然后减6(12的一半)。这种方法可以用在很多应用中,这12个数的和是Irwin-Hall分布;选择一个方差12。但此推导的结果限制在(-6,6)之间,并且密度为12。

方法二:Box-Muller方法

Box-Muller方法是以两组独立的随机数U和V,这两组数在(0,1]上均匀分布,用U和V生成两组独立的标准常态分布随机变量X和Y:

正态分布曲线 2

方法三:由正态分布曲线图形得到的直观结果

图1 正态分布曲线

正态分布曲线

从上图可以看出,在μ附近的概率密度大,远离μ的地方概率密度小,我们要产生的随 机数要服从这种分布,就是要使产生的随机数在μ附近的概率要大,远离μ处小。算法的主要思想是:在上图的大矩形中随机产生点,这些点是平均分布的,如果产生的点落在概率密度曲线的下方,则认为产生的点是符合要求的,将它们保留,如果在概率密度曲线的上方, 则认为这些点不合格,将它们去除。如果随机产生了一大批在整个矩形中均匀分布的点,那 么被保留下来的点的横坐标就服从了正态分布。可以设想,由于在μ处的 f(x)的值比较大,理所当然的在μ附近的点个数要多,远离μ处的少,这从面积上就可以看出来。我们要产生的随机数就是这里的横坐标。

根据以上所述三种方法,编写C++测试代码如下:

#include

#include

using namespace std;

#define pi 3.1415926

#define rd (rand()/(RAND_MAX+1.0))

//区间[min,max]上的均匀分布,min和max要求传入的参数类型一致

template <<span style=”color:blue”>class T>

T rand(T min, T max)

{

return min+(max-min)*rand()/(RAND_MAX+1.0);

}

//求均值为miu,方差为sigma的正太分布函数在x处的函数值

double normal(double x, double miu,double sigma)

{

return 1.0/sqrt(2*pi)/sigma*exp(-1*(x-miu)*(x-miu)/(2*sigma*sigma));

}

//按照矩形区域在函数值曲线上下位置分布情况得到正太函数x值

double randn(double miu,double sigma, double min ,double max)

{

double x,y,dScope;

do{

x=rand(min,max);

y=normal(x,miu,sigma);

dScope=rand(0.0,normal(miu,miu,sigma));

}while(dScope>y);

return x;

}

double randn(int type)

{

//按照12个均匀分布之和减去6得到正态分布函数的x值

if (type==1)

return rd+rd+rd+rd+rd+rd+rd+rd+rd+rd+rd+rd-6.0;

//按照计算公式y=sqrt(-2*ln(U))*cos(2*PI*V)计算得到x

else if(type==2)

return sqrt(-2*log(rand()/(RAND_MAX+1.0)))*cos(2*pi*rand()/(RAND_MAX+1.0));

else

return randn(0.0,1.0,-10.0,10.0);

}

int main(int argc,char* argv[])

{

srand((unsigned)time( NULL ));

ofstream outfile(“321.txt”);

for (int i=0;i<100;i++)

{

//randn(1)、randn(2)和randn(3)效果差不多

outfile << randn(3) << endl;

}

return 0;

}

参考:

[1] http://zh.wikipedia.org/wiki/正态分布

[2] http://en.wikipedia.org/wiki/Normal_distribution

[3] http://wenku.baidu.com/view/e9de620d7cd184254b3535c9?pn=2&ssid=&from=&bd_page_type=1&uid=bd_1332071259_725&pu=sl@1,pw@1000,sz@224_220,pd@1,fz@2,lp@0,tpl@color,&st=1&wk=rd&maxpage=3

转载:http://blog.sina.com.cn/s/blog_70a14458010155b8.html

从Google备份互联网看“数据安全”

【编者按】作者Todd Hoff是High Scalability创始人,为我们解读Google数据保密和数据安全负责人Raymond Blum的演讲。数据安全的一个重要工作就是备份,备份的容量扩展、存储备份的媒介、备份的效率……通过对互联网中庞大数据多样化、复杂的备份,使数据在任何情况下都能简单地还原、恢复。数据安全不仅仅是一个技术问题,它还受到现实的种种限制,做好数据安全,是任何一个企业都要考虑的问题。


CSDN推荐:欢迎免费订阅《Hadoop与大数据周刊》获取更多Hadoop技术文献、大数据技术分析、企业实战经验,生态圈发展趋势。


以下为译文:

Raymond Blum带领Site Reliability Engineers团队负责谷歌的数据保密和数据安全。当然Google从来都不会如实说有多少数据,但从评论上看目前还没到 yottabyte级(1YB=280B),不过也有很多exabyte级(1EB=260B)的数据了。仅Gmail就有接近exabyte的数据。

Blum先生在名为“ 谷歌如何备份互联网”的视频中解释,常见的备份策略对谷歌无效,原因听起来让人吃惊:它们大多是在努力用容量实现扩展。如果备份两倍多的数据,那时间、能源、空间也会消耗两倍,如果不这么做,就不能进行扩展。要让容量比支持容量的能力扩充更快,必须要有效率。从备份1exabyte数据转变到备份2exabyte数据,需要一个不同的计划。演讲的内容的主要关于Google是如何实现容量扩展的。

演讲的一些主要议题:

  • 从无数据丢失。甚至影响颇为不好的GMail停电事件也没有丢失数据,这远比备份许多磁带要复杂的多。数据从整个堆栈检索,每一层都需要管理,包括对人的管理。
  • 备份无用。还原你想要的部分,这是指还原系统而不是备份系统。备份是你要为还原付出的高昂代价。将工作转移到到备份上并使备份适当的复杂,是为了让还原尽可能的简单。
  • 不可以线性扩展。不可能有100倍的数据,你就能得到100倍的人力和机器资源。你只能去寻找使能力倍增的方法。自动化是提高利用率和效率的主要途径。
  • 冗余。谷歌的存储设备一直在老化。这当然不用说都知道,就像我们身体的细胞会死一样,Google并没有幻想着事物不会消亡,它只是为事物的消亡做好准备。
  • 多样性。如果你担心某个站点的位置不安全,那就把数据放在多个站点。如果你是担心用户错误,那就将用户交互与数据隔离。如果你想要避免软件bug的损害,那就把数据放在不同的软件上。从不同的供应商获取存储设备,以减少供应商的bug影响存储的数据。
  • 将人从繁琐的劳动中解放出来。通过GMail保留一封电子邮件有多少备份?这不应该是人关心的事情。通过GMail配置一些参数,系统会具体安排。这是不变的主题,高级别策略设置和系统实现了它。只有规范之外的事情发生才会需要人的参与。
  • 证明。如果你不试用它,那它就不会起作用。备份和还原就是不断的测试,以验证它们的工作的过程。

无论组织大小,都有很多要学习的东西。Blum先生的 演讲很风趣、信息量大、很值得一看。看起来他真的很喜欢工作中的挑战。

以下是我对这个演讲的注释,从中我们可以了解到许多不为人知的秘密:

  • 数据可用性必须是100%,不能有数据丢失
  • 统计学上,2GB文件中如果丢失了200K数据,似乎没什么大不了,但这个文件或许就不能用了,比如说可执行文件或报税表。
  • 数据的可用性比可访问性更重要。如果系统关闭,后果并不特别严重。但如果数据丢失,那就不是小事了。
  • 谷歌保证用以下所有可能组合保证数据安全:
  • 位置隔离
  • 隔离应用层问题
  • 隔离存储层问题
  • 隔离媒介故障
  • 想象一下移动滑块的情形。让软件像纵向滑块那样,让地址像横向滑块那样。如果你想要包含一切,你需要不同地址的软件层备份。你可以在不同的地址使用虚拟机。
  • 冗余不等于可恢复性
  • 制作多个备份不能保证数据不会丢失。
  • 多个备份对某些种类的停机是有效的。例如一颗小行星击中一个数据中心,而在一个很远的地方,你有这个数据中心的备份。
  • 如果你在存储堆栈中有一个bug,那把它复制到N个地方也没有用,因为bug破坏了所有备份。示例:请参阅GMail停机。
  • 相比小行星,代码中的bug、用户错误或已损坏缓冲区的写入,这些故障发生要多得多了。
  • 冗余对访问局部性有帮助。当你想要所有的数据引用与正在使用位置的数据尽可能接近时,备份是个不错的选择。
  • 因为这么多的备份,整个系统非常稳健
  • 谷歌的设备一直在老化。这不用说也知道,我们身体的细胞也同样会死。我们并没有幻想事物不会消亡,我们只是在为消亡做准备。机器也一直在损耗。
  • 冗余就是答案。合计一下,这要比单一的高质量机器更加可靠。单一机器可能会被一颗小行星摧毁。想要摧毁放在50个不同地点的机器就难说了。
  • 大规模并行系统的数据丢失几率更大
  • MapReduce在30000台机器上运行得很好,当然是在没有bug的前提下。一旦有bug出现,造成的影响也是成倍的。
  •  本地备份不能防止站点停机
  • 如果你的服务器机房中发生灾难性的破坏,那RAID也帮不了你。
  • Google文件系统(GFS),大约一年前,整个Google都在使用这个文件系统,它将RAID的概念又升级了一次。使用 编码技术将数据写入不同城市的多个数据中心,只需要N-1个数据片段,即可还原完整的数据。所以即使3个数据中心中一个停机了,也不会影响数据可用性。
  • 可用性和完整性是组织广泛的特点
  • 谷歌的工程师们,BigTable,GFS,Colossus都知道数据持久性和完整性是第一任务。很多系统需要检查并更正在数据可用性和完整性上的错误。
  • 多样性
  • 如果你担心某个站点的位置安全,那就把数据放在多个站点。
  • 如果你担心用户错误,那就把用户交互和数据隔离。
  • 如果你想要避免软件bug的破坏,那就把数据放在不同的软件上。从不同的供应商获取设备,以减少供应商的bug影响存储的数据。
  • 磁带备份真的很不错
  • 磁带好是因为它不像磁盘那样。如果可能他们甚至会使用打孔卡。
  • 想象一下假如你SATA磁盘的设备驱动程序里有一个bug。磁带就避免了这一问题。因为不同的媒介意味着不同的软件,这就增加多样性。
  • 磁带容量遵循摩尔定律,所以他们对磁带作为备份介质都很满意,虽然他们还在寻找替代品,现在很难说这些替代品是什么。
  • 磁带加密意味着有着不良企图的家伙们将很难从磁带中得到有用的东西。
  • 备份是无用的,真正需要关心的是还原
  • 在有人需要数据之前发现数据是否存在问题,你确定需要数据时再还原。
  • 持续还原。不断随机选择5%的备份,还原并对它们进行比较。为什么呢?因为需要在数据丢失之前查明数据是否还能用,找出存在的问题。
  • 自动比较。因为原始文件已更改,所以不能与原始进行比较。所以将校验码和校验码进行比较。把它带到源媒介、磁盘或闪存,或者其它的媒介。请确保数据可以做一次往返,自动比较是一直都在做的事情。
  • 故障率变化的警报
  • 你可能想要知道是不是有什么发生了变化。如果一切运行正常,那就没有必要告诉我了。
  • 预期会有一些失败,但别第一次尝试还原的文件失败就发出警报。
  • 假设首次尝试的失败率是N,第二次尝试的失败率为Y。如果故障率发生变化那一定是哪里出问题了。
  • 损坏
  • 磁盘随时都有可能中断,但因为你监视它,所以你能及时的了解到。
  • 要是磁带的话,只有你使用它的时候,才知道是不是坏了。虽然磁带保存的时间很长,但是你想在用它之前检测它是不现实的。
  • 不要将数据仅写到一盘磁带上。他们是墨盒,随时会有意外发生。
  • 向磁带写入数据时,编写器要保持数据不变,直到数据被完全写入。
  • 建立4盘完整磁带,然后通过XOR(逻辑运算)生成第五盘代码磁带。你可以失去5磁带的任何一个,也能恢复数据。
  • 现在告诉编写器它们可以更改源数据,因为数据已经到了到最终的物理位置,有冗余了。
  • 谷歌备份的每一bit数据都要经历这个过程。
  • 数以百计的磁带每个月都将丢失,并没有造成数据的丢失,就是得益于这个过程。
  • 假设当检测到一盘磁带丢失,通过使用连续还原和同级磁带重新生成另一个磁带,一切都没问题。在那种两个磁带都被损坏的罕见情况下,如果磁带上的受损的两个点相同,那数据就只好丢失了,只能在subtape一级完成重建。
  • 实现这些技术的成本很高,但是为了不丢失数据,很值得。
  • 备份是你为奢侈的还原付出的代价
  • 它是指还原系统而不是备份系统。还原是一个不可屏蔽的中断,他们胜过一切。
  • 让备份变得复杂而且只要需要就这样做。让还原变得快捷而且越自动化越好。
  • 恢复应该是傻瓜式、快速和简单。就算是一只猫也能完成还原操作。
  • 无论你休息得很好还是累的很惨,还原时才不会问你是不是准备好了。所以不要让人为因素决定服务数据还原的成功与否。
  • 大部分的系统都是这样工作的。
  • 数据源或许能够将数据存储一段时间,也许是在它备份之前的几天。但一旦备份完成,它随时都可以还原,而且还原得很快。
  • 为了使还原速度更快,不能将全部资源用于备份。花两个小时来读取磁带是不可行的。只写一半磁带,并行读取它们,这样你仅用一半的时间就可以获取数据。
  • 扩展是个问题
  • 当你有exabyte级的数据时,也会有现实世界的限制。如果你要复制10exabyte数据,然后它会花10周时间备份每一天的数据。
  • 考虑到分布在世界各地的数据中心,可供选择的方案并不多。你能给每个站点无限的备份容量吗?你会按区域划分所有备份吗?转移数据的带宽呢?你难道不需要带宽来为挣钱的流量服务吗?
  • 看看有关的费用。也有一些妥协方案,比如不是每个网站都有备份设施。必须平衡网络中的可用容量。怎样才能最划算?例如,只在有足够带宽的站点中进行备份。
  • 不能线性扩展
  • 你不能只是说想要更多的网络带宽和更多的磁带驱动器。驱动器中断的情况,如果你有10000个驱动器坏了,你需要10000个运算器来替换它们。你有10000个装卸码头来放磁带驱动器,直到一辆卡车把它们运走。这一切都不可以是线性的。
  • 虽然磁带库的数量提高了一个数量级,但参与其中的人并没有随之线性增长。
  • 比如早期曾有人预测,随着电话的增多,30%的美国人会被雇佣为电话接线员。显然他们没预见到未来的自动接线。
  • 自动化
  • 调度被自动化。如果你有一个服务,你说:我有一个数据存储,每N天我需要一个备份,在M时必须还原。内部系统完成这些事情:计划备份、运行还原测试和运行完整性测试等等。并且磁带故障的处理也是全自动的。
  • 人是无法看到这些的。也许有一天,你可能会问平均多少个磁带损坏了。或如果磁带破损率从每天100盒磁带变成每天300盒磁带时,就会发出警报。但在那之前不要问我:如果一天100盒磁带损坏是不是在正常水平内?
  • 人不应参与稳态操作
  • 装载和运输驱动器仍然是人类的活动。自动化的接口准备装运标签,得到RMA号码,检查已经出来的软件包,拿回执,如果出现故障,人才会进行干涉。
  • 库软件维护也类似。例如固件更新时,人不会将这些更新运行在每一个系统中,系统会自动下载这些更新,并进行验证、运行。这些常规的操作不需要人的干预。
  • 自动处理死机事件
  • 机器平均一分钟死两台。如果一台机器在进行MapReduce作业期间使用30,000机器,有一台机器死机了,那就不要告诉我了,处理完它,继续工作。找到另一台机器,转移任务,重新启动。
  • 如果有依赖关系那就先等待。如果你等得太久,就让我知道。你处理你自己的计划。这是算法的工作,不需要人为的操作。
  • 保持效率正向提高
  • 大幅提高利用率和效率。不能有100倍的数据就需要100倍的人或机器资源。
  • 2011年Gmail停机和还原,谷歌如何丢失数据又找回
  • 在周日的上午10:31他看到了一个网页,上面写:“Holly Crap打电话给xxx-xxxx”。关于中断要想了解更多,请看在 这里
  • Gmail的数据量达exabyte级别。这意味着大量的磁带。
  • 100%恢复并不意味着可用性也是100%,数据恢复要过段时间才能正常使用。
  • 一系列的bug和意外事件会产生在备份的过程中。即使是单元测试、系统测试和集成测试,对一些bug也是无能为力。
  • 从磁带中还原意味着大量的工作。还原时间和规模相关。还原gigabyte级数据可以在几毫秒到几秒时间内完成。还原200,000个收件箱中的几个gig,每个都得花去不少时间。
  • 把欧洲的几个同事叫醒,因为他们刚休息完、很清醒。这就是分布式劳动力的优势。
  • 从许多磁带还原和检验数据。不需要花几个星期或几个月时间,只需要花几天的时间。这使他们很开心。在类似情况下的其他公司花了一个月时间才意识到他们找不回数据了。需要采取一些措施以确保这个处理下一次更快。
  • 一个磁带驱动器需要2个小时来读。这些磁带分布在各地。否则在还原过程中,任何单一地点都不会有足够能力读取还原过程中涉及的所有磁带。
  • 压缩和校验码实际上不需要读取200K磁带。
  • 还原过程自那时以来已大为改善。
  • 优先还原
  • 已存档的数据可以在更重要的数据之后还原,比如你当前收件箱和发送的电子邮件。
  • 一个月内没用过的帐户可以等活跃用户优先恢复之后还原。
  • 备份系统被看作是一个巨大的全球有机体
  • 例如,不要只考虑GMail在纽约备份,因为如果该数据中心增长或收缩,备份需要适当调整规模。
  • 把备份看成一个横跨世界的巨型系统。备份时它可能完全是在别的地方完成。
  • 在磁带上的还原必须是在磁带所在的位置。但到它制作磁带时,数据可能在纽约而备份可能在俄勒冈州,因为在那里有容量。位置隔离是自动的,客户不知道自己的数据被备份在哪里。
  • 容量可以被迁移。只要有全球的容量和网络支持,磁带被放在哪无关紧要。
  • 拥有的数据越多,保存好它就越重要
  • 越大越重要的是他们的一条准则。谷歌曾经只是搜索引擎。现在它还是Gmail,还有驱动器、文档一类的东西。它现在变得更大也更重要了。
  • 有良好的基础结构
  • 处理问题时,有通用的解决方案再好不过了。在写MapReduce时可能从来没有想到它会被用于备份。但要是没有MapReduce,利用它进行备份的想法也是不会有的。
  • 扩展的重要性不言而喻,软件、基础设施、硬件、流程都要可以扩展。
  • 你不能说:我要去部署更多的磁带驱动器,就需要两倍的员工。你会雇这么多的人吗?你有两倍多的停车点吗?还有食堂房间?厕所?一切都要扩大规模。你会遇到一个瓶颈,然后寸步难行。
  • 证明
  • 别把什么事情都当作理所当然。希望毕竟不是一种战略。
  • 如果你不检验它,那就起不到作用。还原操作必须要检验备份。直到你结束了你还没证明什么。这种态度已发现有很多的不足。
  • DRT.灾难恢复测试
  • 每N个月都要模拟一场灾难恢复,看系统每一层的反应。
  • 如何做到无论灾难带走什么,公司都能生存下去?答案只有一个:必须学会适应。
  • 在基础设施和物理安全发现无数漏洞。
  • 想象有一个数据中心,一条通向数据中心的路,路上的卡车满载了备用发电机的燃料。那如果这条路不通了怎么办?最好有另一条路,另一供应商可以提供柴油燃料。
  • 必须要有供应链冗余策略。
  • 不同时间点不同地点不同软件堆栈中的冗余
  • 不要仅仅通过堆栈迁移数据。特别是暂停期间堆栈不同层中保留的数据。丢失的数据可以在其它地方找到。所以记住:时间、地点和软件。
  • 想一下Gmail的中断示例。如果备份损坏,数据怎样才能不会丢失?这是演讲时,听众的一个问题,他不想透露太多。数据是持续备份的。假设我们有下午9点的数据,假设下午8点出现损坏,但还没有做出磁带。这时损坏被停止了,软件被回滚到上一个工作版本。在一些还原点,所有堆栈中的数据是还在那里。这些就是磁带上的东西。磁带会备份这些东西。在前端上有,在日志中有。所有数据都可以实现重建。但要在所有数据被转移到另一个堆栈中之后再对其进行操作。
  •  删除问题
  • 不去重写磁带而只是删除数据的成本太高。
  • 一种办法是聪明地使用加密密钥。他没有告诉我们谷歌是怎么做的。
  • 当你信任你的同事,并给他们分配各自的职责时,一个巨型的组织就运作起来了
  • 相信他们能胜任自己的岗位。
  • 确定组织和软件接口定义得很好。执行层与层之间的检验测试。
  • 白名单和黑名单
  • 确保数据在安全的地方,保证数据不会在某些地方,保证数据位置多样性和位置独立性。
  • 最初并不是堆栈的功能。因为要满足政府的要求,必须添加进来。
  • 这些功能尽可能放在堆栈的最底层。填写正确的配置文件,就都完成了。

原文链接: How Google Backs Up the Internet Along With Exabytes of Other Data?(编译/毛梦琪 审校/周小璐)

880万行代码已删,Google在Blink之路上愈斗愈勇

880万行代码已删,Google在Blink之路上愈斗愈勇

几乎在一个半月前,Google 才宣布会用 10 周的时间,以新的渲染引擎 Blink 取代旗下所有平台的现有浏览器引擎。而昨天的 Google I/O 开发者会场上,Blink 团队更新了目前的项目进度:他们已经删除了原有 WebKit 中的 880 万行代码。

Google 最初宣称要以 Blink 取代 WebKit,因为 WebKit 对几个平台的兼容性太差时,表示需要移去 7 个构建系统并删除 7000 个文件包,大约包含 450 万代码。而照如今的进度看,Google 在移除 WebKit 上的工作效率已经远远超出预期。

这一额外的效果使得 Blink 团队成员在开发 Blink 时也变得更有生产力,他们甚至表示已经不需要再招聘什么工程师了,目前这几个独立的开发者的效率就可以按时完成工作。他们目前的工作除了删除代码以外,还包括了一些新的实验,比如Lazy Block布局——检验能否通过先处理屏幕中的显示内容来加快引擎对大型 Web app 的渲染速度。根据现场的 demo 展示,目前实验的结果是,渲染时间从原来的 4 秒降低到了 32 毫秒。

Blink 团队现在已经得到了 Adobe、Intel 和 Microsoft 的支持。Microsoft 已经和 Blink 团队达成合作,会向他们开放 Pointer Events(指针事件)API 以在浏览器中实现鼠标、触摸和手写笔的交互。

关于 WebKit 和 Blink 的恩恩怨怨,可以看这里《历史在重演:从KHTML到WebKit,再到Blink》

来源:http://www.36kr.com/p/203333.html

Google是世界第五大服务器生产商

 来源: Solidot

英特尔数据中心集团负责人Diane Bryant透露,Google是世界第五大服务器生产商,但它生产的服务器只供自己使用。 2008年,英特尔四分之三的服务器芯片业务收入来自惠普、戴尔和IBM,全球大多数企业都是向这三大服务器生产商购买服务器。

但到了2012年,英特尔四分之三服务器业务收入来自八家公司,其中一家公司不销售服务器,它是为自己生产服务器。服务器市场正从传统的服务器供应商模式逐渐转向原设计制造商 (original design manufacturers,ODM)模式,大型Web公司如Facebook、亚马逊和Google都采用ODM减少中间环节降低成本。

除了 Google外,Bryant没有透露八大服务器公司的具体名字,但她列出了正在崛起的ODM供应商如广达、超微(Supermicro)、Wiwynn 以及华为。

Theunderstatement统计显示谷歌高管很少使用Google+

http://www.sina.com.cn 2011年10月05日 15:45 新浪科技微博

新浪科技讯 北京时间10月5日下午消息,美国科技博客Theunderstatement昨天发布报告称,谷歌CEO拉里·佩奇(Larry Page)在Google+中发布的公开信息仅为7条,其他谷歌高管使用Google+的频率也普遍很低。

Google+发布至今已经3个多月,但佩奇在该服务中发布的公开信息总计仅为7条,自8月中旬至今甚至仅发布过1条公开信息。而谷歌执行董事长埃里克·施密特(Eric Schmidt)更是没有发布过一条公开信息,但他在此期间却多次使用过Twitter。

根据Theunderstatement的统计,这种情况在谷歌高管中非常普遍,在谷歌管理团队页面所列出的12名高管中,只有3人曾经在Google+上发布过公开信息,总计为29条,9月仅为6条。

在佩奇今年4月上任后任命的6名高级副总裁中,有4人自8月以来就没有再发布过任何Google+公开信息,他们迄今为止发布的所有公开信息总共也只有9条,其中有8条来自Android主管安迪·鲁宾(Andy Rubin)。

总体来看,在全部18名谷歌级别最高的管理人员中,有11人要么没有使用Google+,要么从未在该服务发布任何公开信息,还有5人使用频率很低。只有Google+主管兼谷歌社交高级副总裁维克·冈多特拉(Vic Gundotra)和Chrome高级副总裁桑德拉·皮采(Sundar Pichai)经常使用该服务发布公开信息。

业内人士认为,高管的参与是一款社交服务获得成功的必备要素之一,例如,Facebook CEO马克·扎克伯格(Mark Zuckerberg)就曾经表示,他会一整天泡在Facebook上;而Twitter CEO迪克·科斯特罗(Dick Costolo)周一也至少发布了30条Twitter消息。(鼎宏)

如何在Google成为一名优秀的产品经理?

2012-02-24 11:17   来源: 伯乐在线

导读:有用户在Quora提问:优秀的Google产品经理需要具备哪些素质?前 Google 工程师 Edward Ho 回复了这个问题。编译Edward 的回答,全文如下:

在Google ,我和我所见到过的最优秀的产品经理一起工作过,我会根据自己的经历出一个列表。由于我不是项目经理,所以这些结论都是我在Google观察最优秀的产品经理后的结果。

1. 对产品以及所有相关的问题负责。这会让你积极主动,你是第一个寻找bug的人,第一个与用户沟通的人,以及第一个担心产品是否合格的人。你总是第一个自愿为产品或团队做各种任务的志愿者,像是做会议记录、给客户发邮件、填补临时的空缺、为bug确定优先级,或是快速做出一个实体模型。始终持有这样一个想法:这不是别人的责任,这就是你的责任。当你这么做的时候,你会发现第2条会更容易。

2. 具备难以置信的说服力。(我不知道这是如何做到的,但每天我都会看到)你希望把事情完成,但你不是负责人,所以只能去说服别人。没有哪个团队向你汇报,也没有任何人会按照你的说法行事。在 Google ,你需要通过使别人信服而不是发号施令来完成事情。如果你正在做第1条,事情会变得简单,因为每个人都知道如果有人攻击这个产品,你和他们会位于同一个战壕。

3. 成为一名工程师。我并不是说你真的需要为产品编写代码。我想说的是,你应当像一名工程师那样对产品的构造过程具有好奇心。你应该了解产品功能在开发过程需要的成本,以及为什么开发成本会变得这么高。那个特性使用的是什么算法?为什么这个页面会呈现得很慢?大的架构变动对产品会产生影响,团队中的每个工程师都会对此非常重视,你也应该如此。如果你遇到项目的负责人,他们想要知道一些具体的事情,你应该能够为他们解释一些主要的工程方面的决定以及之前的利弊权衡。在谷歌,最好的的产品经理都会尽可能地变得更加技术化并乐此不疲。

4. 积极,再积极一点。你的团队很可能全部由工程师组成,并且中的一些可能非常愤世嫉俗。一个非常积极向上的产品经理能够在团队中创造一种包容的氛围。尽管每时每刻都保持积极看上去很可笑,但是积极是有传染性的,你的团队会依赖上它。请记住,你和主要的工程师(技术负责人)可能会列出百万种让你沮丧的事情,但是团队中的其他人不应该知道这一切。因为你是产品经理,所以不应该沉浸在自己的担心中,这样会帮助他们更好地完成工作。你就是团队面向整个公司其他部门的窗口和信使。如果你变得消极,团队就会因此认为公司里其他人也是这么看待他们的工作。

如何在Google成为一名优秀的产品经理?

5. 不要自我推荐。这是显而易见的,如果你这么做了,不但非常无聊而且对自身也有害。赞美团队中的其他人,你和技术负责人(们)已经是项目的主要联系人,因而不要做任何的推荐。如果你拿别人的辛苦劳动用来为自己博得赞赏,你不仅错了而且不会得逞。要心胸宽广。无论是撰写项目博客,还是产品新特性的午餐视频发布会,最优秀的产品经理都应该推荐团队的其他成员。看看谷歌最优秀的产品博客,你就会发现这些博客的作者并不总是由产品经理,反而会是团队中的各个成员。产品经理会积极推荐其他人。(请不要误解我这里所说的“推荐” promotion ,这和升职是完全不同的。顺便说一下,在谷歌升职是和绩效考核紧密相关的。)

6. 无所畏惧。这个名词如果是作家来解释可能会更好,但请你不要被字面意思所迷惑。最好的产品经理向领导汇报的内容和给团队中的工程师或设计师讲述的内容应该是一样的。如果你在被领导质问产品设计所作的决定时默不作声,你肯定不会成功。做出简洁明了的回答,并无所畏惧地为你团队的创意辩护。

希望上述内容能有所帮助。

原文:Edward Ho 编译:伯乐在线 – 唐尤华

Google+:Google给Facebook的终极绝杀

昨晚你可能听说在Google.com的顶端出现了一个神秘的黑条,也许你已经亲眼所见,放心,这不是你的幻觉,这个标志表示Google有“重磅武器”登场了,那就是:Google+GooglePlus

你可能会问,Google+是什么东西?不知道是正常的,因为这可是Google在过去几年一直在悄悄研发的高度机密项目。这个项目是由Vic Gundotra和Bradley Horowitz负责,要知道,他们俩在Google的地位,那就相当于美国的巴顿将军和麦克阿瑟将军。尽管一再有关于这个项目的风声走漏,但Google仍尽可能地刻意对此轻描淡写。在这个项目上,Google的态度一直相当低调。但它是真实存在的,现在它终于登场了。 Google一直将Google+低调处理,不是因为不看好它,也不是因为不把它当回事,而是因为它现在还只是整个发展宏图的草稿而已。Gundotra和Horowitz认为Google+不只是一个产品,也不是一种战略方案,而是一个扩展后的Google。 Gundotra上周在接受采访时说,“我们认为目前在线共享服务还不完善,甚至可以说是相当糟糕的。在我们看来,与其他人联系是人类的一个基本需求,在现实生活中我们一直以各种方式与别人接触,但我们的在线工具却很死板,他们要不就硬把我们塞进桶里,要不就将我们完全曝露在公众面前。真实生活的共享是微妙且丰富的,这很难通过软件来实现。” 在Google+的演示视频中,我们可以看到一个设计周到的产品,甚至看起来不太像是Google的作品。Gundotra说,他们投入了很多心思和精力去做Google+的用户界面和用户体验。

Google+

下面简单介绍几款吸引人的Google+功能。 在Google+中,最让人感兴趣的可能是一个叫做“交际圈(Circles)”的功能,交际圈并不是一款独立的产品,而是Google+的一个重要功能。Gundotra说,“它是我们产品中的一部分核心内容。”用户可以通过交际圈来选择加入和组织群组从而达到最优的共享模式,虽然用户不大喜欢做群组管理,但Google尽可能地将管理过程做得讨人喜欢。你只需从一份推荐联系人的名单(来自于你的Gmail或Google通讯录)中选择合适的人选,然后将他们拖进你指定的交际圈中。整个过程的用户界面都简单直观,甚至可能会让人觉得有趣。它完全可以打败Facebook的建群功能。Gundotra知道很多社交服务商尝试让用户建群但最终都以失败告终,但他坚信交际圈会获得成功,因为他们是运用软件来恰当地模拟真实世界。更重要的是,用户还会因使用交际圈而得到好处。

Google+

Google+最大的特色之一是它作为一个工具栏存在于所有Google网站的顶端,你一旦设置了自己的交际圈,就能通过工具栏极为方便地将任何Google网站分享给任何交际圈中的人。 Horowitz说,考虑到不同网站提供所分享模式五花八门的现状,他们希望通过这个名为Sandbar的黑色工具栏来进行统一,这个工具栏以同样的形式存在于Google的扩展浏览器和手机版本等等。 Gundotra还展示了一个名为“火花(Sparks)”的功能,在Gundotra看来,精彩的内容可以成为好的话题,让聊天更为顺利。使用火花,你可以输入一个所感兴趣的东西,Google会在网上帮你找出他们认为你可能会关心的内容,Google可以搜索出任何相关的博客、视频和书籍。如果其中有你喜欢的,你可以将其收藏。你也可以在其他人的收藏区中看到他们所喜欢和谈论的东西。

Google+

为了便于人们互相联系,Gundotra设计了Google+的即时上传(Instant Upload)功能,其想法是让每个人的口袋里都有一台相机。这个功能适用于喜欢使用Android手机拍照和拍视频的用户。这个新的应用程序可以自动将这些内容上传到Google+并存储在一张私人专辑中,用户可以选择是否分享。

Google+

Google+的另一个功能叫做“聚集(Huddle)”,它实质上是一个群发信息的应用软件,可以在Android、iPhone和SMS上面与交际圈的人进行交流。

还有一个功能叫做“巢穴(Hangouts)”,Gundotra说“现在每人都拥有高速的网络,但有多少人会使用群视频聊天呢?没多少人。”群视频聊天不仅需要强大的技术和资金支持,最大的问题在于这种聊天方式并未受到社会欢迎。为了解决这个问题,Google+的团队想到了真实生活中那些坐在门廊的邻居们。如果你的邻居坐在门廊,你知道他们应该有兴趣聊聊天,而且如果你只是一言不发地走过去,这多少有些不礼貌。基于这种想法,Google+的巢穴功能可以让你的好友知道你想要与人聊天,这在某种程度上解决了视频聊天的问题。如果你准备好与交际圈中的人聊天,那交际圈中的每个人将收到一个来你的巢穴逛逛的邀请。它最多能支持10个人同时进行群视频聊天,而且Google+聪明到能够随时分辨出谁是谈话的主角然后关注此人,这将便于聊天者观看聊天过程,就像是有个编辑坐在屏幕后面,随时对视频进行剪接。

Google+还有很多其他实用吸引人的功能,我们会在接下来的报道中陆续为大家介绍,就像Gundotra所总结的,“Google+不只是一个单纯的产品,它是为了让Google得到更好的发展。如今的网络是以人为本的,想要掌握世界动向,必须了解人们的想法。”

Google+

注:那个该死的黑条并不是Google+,想要体验Google+需要获得邀请才可,不知道这玩意会不会像当年的Wave那样。

来源:月光博客

英文原文:Google’s Facebook Competitor, The Google+ Social Network, Finally Arrives

中文翻译:雷锋网

为什么FACEBOOK不如腾讯QQ

2012-02-13 13:22   来源: 雨枫的博客

为什么FACEBOOK不如腾讯QQ

没错,这是个找骂的题目,我知道。所以我要做个小的修正:“为什么在利用海量用户创造收入的商业模式上,今天的Facebook还不如腾讯QQ那么成熟?”

有两类商业模式。第一类譬如Facebook、譬如QQ、譬如360,他们的共同特点是,被视为最重要/最核心的那部分服务/产品,本身是难以直接创造收入的,360的收入来自于浏览器、导航站和游戏联运,腾讯的收入来自于网游、门户和无线,你要问QQ软件本身直接给腾讯带来了多少收入?那也就是客户端广告那点东西了,很少,可以被忽略不计。通过核心产品/服务带来用户基数和黏着度,通过各种手段,把流量逐步引导进赚钱的业务里,再通过这些业务创造利润。QQ和360都是这么做的,微软的IE浏览器也可以被视作这种模式的代表,包括很多人推崇的linux,某种意义上也是这样的。

第二类譬如google、百度这样的搜索引擎,他们的特点则是,主营业务即收入来源。像google本身,因为关键字广告模式的存在,搜索引擎本身就可以直接创造收入,它不需要把搜索引擎的流量导入到其他某个什么站点/服务上,就可以赚到钱。另一方面,在google这个案例里,实现收入的代价,是用户(本次)离开google,前往广告或链接指定的网址。

同样有将近10亿用户,是facebook的商业价值更大,还是google的商业价值更大?在今天看来,google的收入远比fb高,这又是为什么?要点有二:第一,google的用户使用搜索引擎时,带着明确的诉求而来,这诉求很明确、且很容易被转化成商业行为;而facebook的用户在浏览好友信息的时候,其诉求往往是潜藏的,需要有某种方式加以浮现,才有可能被用作商业化。第二,google不害怕用户离开google,而facebook总体上要一直把用户保持在自己的影响范围内。

所以你知道么,其实facebook的广告,不但现在、而且将来很长一段时间里,都不可能超越google,这不仅仅是广告客户的认知程度问题,这里面有更深刻的含义。

说一个简单的例子吧。12年前,我刚开始关注QQ这个软件,那时候它正在为商业模式所困扰。那时候,出于兴趣,我为这个产品设想过许多不同的商业模式,其中一个,是基于用户聊天内容的关键词广告系统。理论上,如果我们有办法对用户的聊天内容进行分析,通过关键词的筛选进行定向的广告投放,那么这个产品理应赚到很多钱才对。结果呢?12年过去了,腾讯每年赚几百个亿,有多少是基于我说的这个模式的?好像没有。

为什么这样一个看起来很完美的模式实际上无法赚钱呢?三方面因素,首先是技术上的制约,起码在当年,建立这么一个庞大的内容筛选和匹配系统,对腾讯来说并不容易,并且也没有比较明确的算法支持,仅仅因为有人说了一句”我用的笔记本是戴尔的“就给人家显示笔记本的广告,其实一点都不明智。对于用户需求的分析和匹配,不但超出当时,甚至超出了今天我们所能达到的的技术能力。其次是隐私方面的考虑,用户的聊天内容如果被作为广告投放依据,那就是变相跟用户说,我正在监视你的一举一动……很明显这不是个好点子。第三,广告内容是对用户社交行为的打断,试想一对陌生男女正在聊什么起劲的激情话题,他们是不是有闲情逸致去关注旁边显示的小广告呢?实际上人家会直接选择性忽视。

这就导致了一种困境:理论上,社交/通讯型网站对用户的了解应当远比门户和搜索引擎更全面,然而实际情况是,当用户不愿意主动告知或与你分享隐私的时候,你对他们的了解其实远不如匿名的搜索引擎和新闻服务(因为频道和关键词会暴露他们的真实需求),可是一旦你要入侵这些用户的隐私领域,一方面你就面临严重的隐私权的指控,另一方面你会发现,由于用户关注的是具体的人而不是抽象的内容,广告的效果其实是不如内容网站那么明确的。

所以我们可以看到,在营收方面,facebook面临的挑战实际上远比看起来的要大得多,虽然他占了很大一片油田(用户基数和社交关系),但是目前它只能把一小部分原油开采出来,卖给炼油公司,赚很少的收入。想要赚大钱,要么它能够开发出一种技术,让汽车直接烧原油就能跑(更精确的广告投放模式);要么它就得收购或者自建炼油厂,把原油精加工成高级燃料,以换取更多的收入。

这方面,我们简单对比一下就知道,腾讯QQ的商业链远比facebook要完善,无论是门户、游戏还是无线互联网,腾讯很有效的把IM的用户导入到了由自己掌控的、利润丰厚的方向,赚钱的同时还没有失去对用户的控制。

当然,很多人会指责QQ的不开放,而把facebook的开放平台战略挂在嘴边。但开放平台的模式是不是真的能成为facebook营收的驱动力?我举个简单的例子吧,APPLE的开放市场APP STORE 年销售额20亿美金,其中苹果自己收30%也就是6亿美金,不少是么?不少。可是当我们比较一下苹果一个季度(注意不是一年)的净利润是130亿美金,6亿美金几乎可以忽略不计。APP STORE的真正价值是对iphone/ipad的销售促进作用,而不是其自身的营收!我们可以看到开放平台是一个很好的保持和扩大用户基数的战略,但是没有任何证据表明这是个好的商业模式。

同样,facebook向开发者一年支付了14亿美金的收入,这意味着它自己的直接分成收入也不过是6亿美金而已。加上广告收入,这个总额可能更高一些,但是相对于其用户基数,这真的不算是很靓丽的表现。

所以,在此做一个大胆预测:FB上市之后的营收成长,会低于很多人的预期,未来3-5年,FB的营收和利润无法达到google的水平。而能够打破这一预测的唯一可能性,是FB开始进入到利润丰厚的新业务领域,譬如C2C电商、搜索引擎甚至是游戏开发(如果不是考虑到表面的公正性,zynga难道不是一个很好的并购对象么?)当中,这些衍生业务,才会是facebook日后最主要的收入来源。

作者:雨枫

文章来源:雨枫的博客

Android 4.0用户份额已达1%

2012-02-03 08:50  牛华网  rocky

据牛华网北京时间2月3日消息,据国外媒体报道,Google刚刚公布了Android系统的用户使用情况。截至2012年2月1日的两周内,访问Android Market的Android手机用户系统分布如下:

*Android 4.0(Ice Cream Sandwich)用户已占1%。当然,这些用户都使用三星Galaxy Nexus;

*Android 3.0 (Honeycomb)用户占3.4%,较前一个月攀升1个百分点;

*Android 2.3(Gingerbread)用户占58.6%,前一个月为55.5%;

*Android 2.2(Froyo)用户下滑3个百分点至27.8%;

*Andoird 2.0(Eclair用户占7.6%,前一个月为8.5%

据统计,Android设备目前日激活量超过70万台。(rocky)

Facebook、Google、Twitter停工一天会损失多少?

2012-01-20 11:04 来源: 天涯博弈

在各大网站各自发表立场反对SOPA的时候,TheNextWeb发了一篇我很感兴趣的文章《How much would Facebook,Google or Twitter lose if they shut down for one day?》

维基百科决定在1月18日关闭网站一天作为表达抗议SOPA的声音,在互联网引起一片响应,但wikipedia是一个非盈利网站,这种举动并不会对维基百科产生实质的影响,但对于如Facebook、Google之类的网站他们的损失会是多少?

TheNextWeb根据各企业的营收进行了初步的评估,但这仅仅是从营收上来衡量,仅作参考。

Google:根据连线杂志的数据,在7月份Google产生了30亿美元的广告营收,这大多来自于网页上的文字广告。如果Google不仅仅是遮盖它的Logo这么简单,而是向维基百科学习,估算下来一天的的损失将会达到1亿美元。

Facebook:根据Facebook在2011年的盈利预测在42.7亿美元,如果基于这个数字,如果Facebook关店一天,他们将损失高达1170万美元,并且会被用户的口水淹死。

Twitter:基于年报中1.4亿美元的营收,twitter一天的收入将降低40万美元,但twitter用户将没地方来抱怨twitter无法使用了。

eBay:2010年eBay的营收为90亿美元,2011年预计将增长至102亿。如果预测能够达成,ebay每天的损失几乎达到2800万美元,这还未计入每个独立卖家的损失。

Amazon:该电子商务巨头去年在电子商务上的收入提升到300亿美元,但由于亚马逊去年到处撒网,在7月份大涨,并且预计第四季度亏损。根据去年的数字,亚马逊一天的收入损失将在8200万美元左右。

Yahoo:该公司第三季度的收入为10.7亿美元。基于该数字,Yahoo会损失约1180万美元一天,但它应该有更多需要担心的

Groupon:基于早前的预计,今年Groupon将进账26亿美元。如果它和维基百科一样停止销售一天,那么将损失700万美元。

了解更多为什么SOPA是一部恶法

作者:Robert.think

文章来源:天涯博弈

Google 2012十大预测 将不断捍卫其搜索业务

来源: 赛迪网

2011年拉里佩奇担任谷歌CEO之后收购了摩托罗拉,并见证了Google+的面世。在即将到来的一年,人们将目睹Google如何捍卫其搜索业务并利用Chrome浏览器和Android系统加大其优势。 以下是对Google在2012年表现的预测:

1. 成为“监管肥皂剧”的主角

Google将对美国和欧盟的监管机构作出小的让步以消除忧虑。尽管不信任并未消除,2011年Google还是得到了对ITA,AdMeld和摩托罗拉并购案的支持。

2.与必应的竞争中失去5%的市场份额

必应正在逐步扩大市场,在Windows 8成型之际其势头必将继续。微软与雅虎和Facebook的联盟进一步打击了Google。在挥霍了85亿美元之后,微软终于有了像样的产品。

3.与通用汽车合作

有消息称Google与通用汽车达成协议为其10万余员工提供电子邮件和应用软件。此举将使Google拥有前所未有的超级用户并结束其对云计算的担忧。

4.安卓系统在智能手机市场占有率达到60%

安卓在2011年第三季度市场占有率达到52.5%,同比增长一倍。与苹果不同,Google对合作伙伴的依赖将保证其市场份额的继续扩大。

5. Chrome在年底市场占有率达35%

当下Chrome浏览器的全球份额只有25%,2011年初在15%左右。随着更多新功能的开发,Chrome的市场份额将有望继续其增长势头。

6.Google TV较先前表现更强

新的硬件,更实惠的价格将使得Google TV取得有限的成功。其挑战在于如何通过应用软件和Youtube等推出独特的内容。

7.推出语音控制功能

在苹果计划推出地图功能替代Google地图之后,Google也将引入与Siri类似的声音控制功能,代号为“Majel”。

8.为安卓发布Chrome浏览器

当下使用Google Android系统的智能手机默认浏览器建立在Webkit和Chrome V8 Java渲染引擎之上。2012年Chrome For Android将与NativeClient一道进入手机浏览器市场。

9.Google+继续存在

Google+与Facebook将继续竞争,其增长更稳定,目标5千万用户,并逐渐进入商务人士的日常生活。与Google其他服务的结合会使其更为强大。

10.为“One-Snap”购买功能申请专利

亚马逊的“One-Click”已成为专利法荒谬之处的典型代表,而Google将步其后尘,为其图像识别软件一键识别并购买商品的功能申请专利。

垃圾太多 Google搜索封杀1100万“.co.cc”域名

核心提示:Google搜索引擎已经封杀1100万“.co.cc”域名网站,它们的信息再也不会再现在搜索结果中。Google反恶意软件团队费舍尔(Oliver Fisher)在博客中说,大多使用这个域名的网站“太垃圾”。

Google搜索引擎已经封杀1100万“.co.cc”域名网站,它们的信息再也不会再现在搜索结果中。Google反恶意软件团队费舍尔(Oliver Fisher)在博客中说,大多使用这个域名的网站“太垃圾”。在过去几个月,Google系统检查了大量的子域名提供商,它们被恶意软件滥用而成为攻击目标。大量的子域名提供商会注册一个域名,比如XX.com,然后出售子域名,比如xx.xx.com。

Google发现这类子域名常常一下子就注册上千,它们用来分发恶意软件。单从一个提供商那里,Google反恶意扫描就查到了5万个恶意域名。

Google认为“http://co.cc/”提供恶意域名,因此决定全面封杀它。
在博客中,Google说会保护用户免受钓鱼攻击。最据反网钓工作小组 (Anti-Phishing Working Group)的统计,2010年下半年,“.cc”顶级域名发起4963宗钓鱼攻击。

“co.cc”注册时会免费提供一个子域名,客户可以支付1000美元,获得1.5万个子域名,它曾声称拥有11,383,736个注册域名,有5,731,278个用户帐户。

CO.CC免费域名是韩国一家IDC公司HANARO-AS Hanaro Telecom Inc (韩国首尔)注册人(jong sung, kim)提供的免费二级域名。co.cc简短易记,在全球各国都有很大的申请量,已经成为免费顶级域名。