88250

Java

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  82 随笔 :: 0 文章 :: 5 评论 :: 0 Trackbacks

2011年1月10日 #



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/netbeans-chinese-newsletter-134.html
posted @ 2011-01-26 00:32 88250 阅读(233) | 评论 (0)编辑 收藏

上周硅谷非常热闹,重大消息频繁出现,其中包括了乔布斯因病休假,苹果的恐怖财报等等。对于我们所关心的移动业界跟互联网来说,Google 换帅是另外一个重量级消息。

Quora 上有一个讨论串,题目是“Larry Page 上任之后,Google 的重点应该是什么?”,讨论相当活跃。我也在这里凑个热闹,谈一谈在我看来,Larry Page 应该如何去改变 Google。

download (4).png

1:关注核心业务,也就是搜索

Google 前段时间在搜索结果上算是饱受攻击,由于与日俱增的垃圾内容,搜索结果的污染状况越发严重。Stack Overflow 的创始人之一 Jeff Atwood 在一篇文章里这样评价 Google 现在的搜索结果:

Google ,这个曾经的必备工具,某种程度上已经失去了它的优势地位。垃圾内容制造者、以点击率为终极目标的内容聚合站点正在走向胜利。

在 这一点上来说,ifanr 感同身受。作为内容提供者,我们是创造价值的人,是在给互联网不断添砖加瓦的一方。而之前在 Google 里搜索我们的原创文章,出现在结果最顶端的却往往是是通过拷贝+粘贴、有时候还不注明出处进行转载的内容聚合站点。它们用毫无成本的方式夺取着应该属于原 作者的访问量。

好在 Google 似乎已经认识到了这一点。之前搜索质量组的 Matt Cutts 表示他 们已经意识到了垃圾内容的增多,以及劣质内容聚合站点引发的不满,并且会很快进行处理。从我今早的实验来看,似乎 Google 已经采取了措施,最近 ifanr 的原创文章都出现在首页头条。从根子上(点击量带来的经济利益)驱逐劣质内容聚合站点,对现代互联网来说,确实是件好事

搜索,是 Google 的立身之本,从上周发布的财报来看,Google 收入的主要增长点仍然是在网站本身的业务。不断改进搜索,添加新的搜索方式,才能保持和增强 Google 在这个领域的领导地位。后院不起火,才有在其他领域发展的资本。

2323.jpg

这一条,是 Larry Page 上任以后最需要关注的。未来十年的搜索是什么样子?如何提高内容关联性,改进使用体验?怎么样通过创新,把 Bing 等竞争对手远远甩开,对 Google 来说,至关重要。

2:在社交网络方面另辟蹊径

Google 在社交网络方面的试探,到目前为止都是悲剧,坦率地说,我个人认为Google 已经错过了第一班社交网络的列车。

RIP-Google-Wave-Dead.jpg

作为新生事物的社交网络,从一开始负载的是用户虚拟交流的需求。

目 前的胜利者里面,Facebook 满足了人们交流的愿望,利用网络,表现了某种程度上真实的人与人关系,而大量互动元素的引入,则是模拟了现实生活的部分人际往来,从根底上来说,没有理念 上的创新,然而它仍然足够伟大,Facebook 把现实生活成功投影到了虚拟世界,是真正意义上的创造者。

另一个赢家是 Twitter,它满足的,是人们表达自己的愿望。通过简短的 140 个字,人与人之间形成了一种奇妙的交流关系,普通人也可以第一时间见证重大事件。可以说,Twitter 与智能手机的结合,创造了一种新媒体。表达自己,记录周边,关注别人,是 Twitter 类社交网络的根本。无论是变种的 foursquare,还是 Quora,从理念上看,都是这样的东西。

Google 之前的尝试呢? Wave 那个体验一塌糊涂的东西不去说它,出生太早了;Buzz 则是无限制版本的 Twitter:Google 试图利用现成的庞大用户群,但没有实质性创新,再加上拙劣的整合方式,这个产品的前景乐观不到哪儿去。

社交网络走到现在,实际上已经到了一个重要的关口,即:虚拟的内容如何与现实社会结合起来,怎样把线上关系与实体经济整合,创造出一个崭新的商业模式。在我看来,这才是第二代社交网络,也即成熟版本的社交网络。这个方向是未来两年的热点,也是 Google 下一步可以突围的角度。

Google 的最大优势是什么?大家应该都非常清楚,其一是庞大的用户群,其二就是信息了。Google 相对于 Twittter、fousquare 等来说,先天就有信息方面的优势。而 Google 在建设社交网络的时候,却完全忽略了这个优势,捆着手脚去从头开始跟已经成熟的对手竞争,怎么可能胜利?

举个最简单的例子,Google Maps 信息丰富,我经常用它来寻找晚餐地点,最大的好处之一就是可以看到多个网站的用户评价,看看截图:

Untitled-1.jpg

看 到了吧,有 Buzz 选项,然而搞笑的事来了。我可以看到其他网站的评价,可以在 Buzz 上分享这个地点,然后呢?没了。我完全看不到 Buzz 关于这个餐馆的讨论,看不到我分享以后朋友的看法——一点也没有。实体经济方面的内容本身就是 Google 的长项,然而在它的任何产品里面,都没有把这个长处跟自己的社交网络更紧密得结合起来。

放着庞大的现实数据不用,几个产品之间几乎没有交流,捧着金饭碗要饭,这就是 Google 的社交网络。跟现实社会结合的社交网络,将是 Google 在这一领域的最后一个机会。

3:细节,细节,还是细节

有一句老话,细节决定成败,然而 Google 现在的很多做法,却表现了一种对细节的漠视,极大影响了产品的使用体验。还是要以 Android 为例(这玩意简直就是反面教材):

就从简单的设置界面说起。Android 平铺直叙的设置界面,完全没有突出重点(我甚至怀疑这帮人安排顺序的时候是不是拍脑门做出的决定。),跟右边的 iOS 比,孰优孰劣,一目了然。

Untitled-2.jpg

还有应用市场,每次谈到 Android 的应用市场,我都有爆粗口的冲动。缓慢的速度、时常丢失的已下载应用列表、迟迟没有解决的应用无法下载问题……这是整个产业的核心之一,Google 就准备这么糊弄下去?

Android 不讲究的地方何止这些,工程师文化并不代表着可以不拘小节,Google 的目光,应该多放些在细节上。移动设备,用户体验至关重要。

4: 继续拥抱云,下注新能源产业

在这个卖杂货的、搞 B2C 的、做软件的都在搞云应用平台的当口,互联网界巨头,拥抱云的先驱之一,可能拥有着世界上最好硬件以及网络设施的 Google,当然也拥有自家的 App Engine。

download (3).png

云 计算平台对于中小企业、个人的意义,无论如何赞扬也不会过分,它直接引领了当前的互联网创业潮。低廉的平台成本,按需付费的方式,Amazon EC2 吸引了大量的个人开发者,Google 的 App Engine 当然不错,但我要说,还是不够灵活,如果能提供更多语言支持,就再好不过了。

新能源很好理解,随着碳交易市场的兴起,碳排放量眼看就要变成金融市场上的一个新产品。在这个趋势影响下,每个企业都应该考虑下自己的能源来源,为将来更加严格的排放调控措施做好准备,规避可能的经济风险。

data-center.jpg

降低所消耗能源的碳排放,对于 Google 这种能源消耗大户来说,是经济跟政治上都很正确的方向,而且同样有大量的利益存在。新能源产业,应该成为 Google 下一步的重点投入方向。

5:提高决策速度与质量,减少内部沟通环节

大 家都知道 Google 著名的 20% 规则:员工可以把 20% 的上班时间放在其他项目上。Google 的员工无疑是优秀的,这些业余时间做出的项目也应该有很多不错的点子,然而,从中孵化的成果却并不多。其中的部分原因,恐怕与 Google 的内部引导以及沟通机制存在很大的关系。由于缺乏引导,员工的项目往往与 Google 本身没什么联系,而因为沟通问题,好的项目不一定能够获得公司的帮助。

Google 的前员工遍布整个互联网业界,大量创新却往往出现在他们离开 Google 以后。应该如何去引发员工的创造力、提高内部效率跟执行力度,Larry Page 需要仔细考虑,以便调整内部架构来适应这个变化迅速的世界。三星这个反应快到根本不像大公司的大公司在全世界攻城掠地,诺基亚反应稍微迟缓一点就束手束 脚,Google,你要快一点,再快一点,才能跟 Facebook 以及数以千计的创业企业进行竞争。

转自:http://www.oschina.net/news/14996/larry-page-google-five-things-todo



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/larry-page-google-five-things-todo.html
posted @ 2011-01-25 09:21 88250 阅读(249) | 评论 (0)编辑 收藏

没有人能说清哪种缓存算法优于其他的缓存算法。(以下的几种缓存算法,有的我也理解不好,如果感兴趣,你可以Google一下)

Least Frequently Used(LFU):

大家好,我是 LFU,我会计算为每个缓存对象计算他们被使用的频率。我会把最不常用的缓存对象踢走。

Least Recently User(LRU):

我是LRU缓存算法,我把最近最少使用的缓存对象给踢走。

我总是需要去了解在什么时候,用了哪个缓存对象。如果有人想要了解我为什么总能把最近最少使用的对象踢掉,是非常困难的。

浏览器就是使用了我(LRU)作为缓存算法。新的对象会被放在缓存的顶部,当缓存达到了容量极限,我会把底部的对象踢走,而技巧就是:我会把最新被访问的缓存对象,放到缓存池的顶部。

所以,经常被读取的缓存对象就会一直呆在缓存池中。有两种方法可以实现我,array 或者是 linked list。

我的速度很快,我也可以被数据访问模式适配。我有一个大家庭,他们都可以完善我,甚至做的比我更好(我确实有时会嫉妒,但是没关系)。我家庭的一些成员包括LRU2 和 2Q,他们就是为了完善 LRU 而存在的。

Least Recently Used 2(LRU2):

我是 Least Recently Used 2,有人叫我最近最少使用twice,我更喜欢这个叫法。我会把被两次访问过的对象放入缓存池,当缓存池满了之后,我会把有两次最少使用的缓存对象踢走。 因为需要跟踪对象2次,访问负载就会随着缓存池的增加而增加。如果把我用在大容量的缓存池中,就会有问题。另外,我还需要跟踪那么不在缓存的对象,因为他 们还没有被第二次读取。我比LRU好,而且是 adoptive to access 模式 。

Two Queues(2Q):

我是 Two Queues;我把被访问的数据放到LRU的缓存中,如果这个对象再一次被访问,我就把他转移到第二个、更大的LRU缓存。

我踢走缓存对象是为了保持第一个缓存池是第二个缓存池的1/3。当缓存的访问负载是固定的时候,把 LRU 换成 LRU2,就比增加缓存的容量更好。这种机制使得我比 LRU2 更好,我也是 LRU 家族中的一员,而且是 adoptive to access 模式 。

Adaptive Replacement Cache(ARC):

我是 ARC,有人说我是介于 LRU 和 LFU 之间,为了提高效果,我是由2个 LRU 组成,第一个,也就是 L1,包含的条目是最近只被使用过一次的,而第二个 LRU,也就是 L2,包含的是最近被使用过两次的条目。因此, L1 放的是新的对象,而 L2 放的是常用的对象。所以,别人才会认为我是介于 LRU 和 LFU 之间的,不过没关系,我不介意。

我被认为是性能最好的缓存算法之一,能够自调,并且是低负载的。我也保存着历史对象,这样,我就可以记住那些被移除的对象,同时,也让我可以看到被移除的对象是否可以留下,取而代之的是踢走别的对象。我的记忆力很差,但是我很快,适用性也强。

Most Recently Used(MRU):

我是 MRU,和 LRU 是对应的。我会移除最近最多被使用的对象,你一定会问我为什么。好吧,让我告诉你,当一次访问过来的时候,有些事情是无法预测的,并且在缓存系统中找出最少最近使用的对象是一项时间复杂度非常高的运算,这就是为什么我是最好的选择。

我是数据库内存缓存中是多么的常见!每当一次缓存记录的使用,我会把它放到栈的顶端。当栈满了的时候,你猜怎么着?我会把栈顶的对象给换成新进来的对象!

First in First out(FIFO):

我是先进先出,我是一个低负载的算法,并且对缓存对象的管理要求不高。我通过一个队列去跟踪所有的缓存对象,最近最常用的缓存对象放在后面,而更早的缓存对象放在前面,当缓存容量满时,排在前面的缓存对象会被踢走,然后把新的缓存对象加进去。我很快,但是我并不适用。

Second Chance:

大家好,我是 second chance,我是通过FIFO修改而来的,被大家叫做 second chance 缓存算法,我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一样也是在观察队列的前端,但是很FIFO的立刻踢出不同,我会检查即将要被踢出的对象有没有之前被使用过的标志(1一个bit表示),没有没有被使用 过,我就把他踢出;否则,我会把这个标志位清除,然后把这个缓存对象当做新增缓存对象加入队列。你可以想象就这就像一个环队列。当我再一次在队头碰到这个 对象时,由于他已经没有这个标志位了,所以我立刻就把他踢开了。我在速度上比FIFO快。

CLock

我是Clock,一个更好的FIFO,也比 second chance更好。因为我不会像second chance那样把有标志的缓存对象放到队列的尾部,但是也可以达到second chance的效果。

我持有一个装有缓存对象的环形列表,头指针指向列表中最老的缓存对象。当缓存miss发生并且没有新的缓存空间时,我会问问指针指向的缓存对象的标 志位去决定我应该怎么做。如果标志是0,我会直接用新的缓存对象替代这个缓存对象;如果标志位是1,我会把头指针递增,然后重复这个过程,知道新的缓存对 象能够被放入。我比second chance更快。

Simple time-based:

我是 simple time-based 缓存算法,我通过绝对的时间周期去失效那些缓存对象。对于新增的对象,我会保存特定的时间。我很快,但是我并不适用。

Extended time-based expiration:

我是 extended time-based expiration 缓存算法,我是通过相对时间去失效缓存对象的;对于新增的缓存对象,我会保存特定的时间,比如是每5分钟,每天的12点。

Sliding time-based expiration:

我是 sliding time-based expiration,与前面不同的是,被我管理的缓存对象的生命起点是在这个缓存的最后被访问时间算起的。我很快,但是我也不太适用。

好了!听了那么多缓存算法的自我介绍,其他的缓存算法还考虑到了下面几点:

  • 成本。如果缓存对象有不同的成本,应该把那些难以获得的对象保存下来。
  • 容量。如果缓存对象有不同的大小,应该把那些大的缓存对象清除,这样就可以让更多的小缓存对象进来了。
  • 时间。一些缓存还保存着缓存的过期时间。电脑会失效他们,因为他们已经过期了。

根据缓存对象的大小而不管其他的缓存算法可能是有必要的。

原文:http://www.zavakid.com/27



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/general-cache-algorithms.html
posted @ 2011-01-21 14:13 88250 阅读(2738) | 评论 (0)编辑 收藏



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/netbeans-chinese-newsletter-133.html
posted @ 2011-01-20 00:19 88250 阅读(200) | 评论 (0)编辑 收藏

提交 B3log Solo(运行在 GAE/J 上的博客程序) 代码后发现 Google Code 版本控制系统会将提交日志同步发布到 Google Buzz 中:

code-buzz.png

但在 Buzz connected sites 里并没有看到与 Google Code 关联:

buzz-connected.png

 

现在一提交代码就 Buzz,还是比较无奈的....



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/code-buzz.html
posted @ 2011-01-14 10:04 88250 阅读(188) | 评论 (0)编辑 收藏



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/netbeans-chinese-newsletter-132.html
posted @ 2011-01-11 22:09 88250 阅读(217) | 评论 (0)编辑 收藏

有时我们需要随机地获取数据记录(实体),比如博客程序中的“随机文章”的实现。

目前 GAE 并没有 API 可以直接获取随机实体,要实现这样的需求我们只能自己想办法了 :-)

在 stackoverflow 上也有人提过该问题,总结如下:

  • Generate and store a random number on your entities as you create them, then pick a random number and look (via a query) for the closet record(s) to it.
  • Implement some mechanism to ensure your entity ids are "densely" populated, then fetch within the known range using keys.
  • Periodically generate random lists of the entities and return entities from those lists. This may take the form of a stack that entities are popped off of, or as actual lists that are returned.

目前 B3log Solo 在处理“随机阅读”上采用的是方法一,即在每个文章实体上添加一个属性保存 0-1 的随机浮点数。

在获取随机文章时生成一个 0-1 的随机数(mid)作为查询条件,以此查询条件作为边界(0 <= mid <=1)来过滤实体保存的随机值属性。

这个方法基本可以达到随机的效果了,为了让随机的效果更动态一点,我们可以考虑经常更新文章实体中的随机浮点值:

  • 访问文章时(即在更新文章浏览次数时一并更新该文章的随机浮点值)
  • 后台定时任务(获取一定数量的随机文章然后更新它们的随机浮点值)
  • 用户做文章更新时

加上以上处理后,随机的效果比较好了 :-)



本文是使用 B3log Solo简约设计の艺术 进行同步发布的
原文地址:http://88250.b3log.org/get-gae-random-entities.html
posted @ 2011-01-10 21:16 88250 阅读(207) | 评论 (0)编辑 收藏