上周硅谷非常熱鬧，重大消息頻繁出現，其中包括了喬布斯因病休假，蘋果的恐怖財報等等。對于我們所關心的移動業界跟互聯網來說，Google 換帥是另外一個重量級消息。

Quora 上有一個討論串，題目是“Larry Page 上任之后，Google 的重點應該是什么？”，討論相當活躍。我也在這里湊個熱鬧，談一談在我看來，Larry Page 應該如何去改變 Google。

1：關注核心業務，也就是搜索

Google 前段時間在搜索結果上算是飽受攻擊，由于與日俱增的垃圾內容，搜索結果的污染狀況越發嚴重。Stack Overflow 的創始人之一 Jeff Atwood 在一篇文章里這樣評價 Google 現在的搜索結果：

Google ，這個曾經的必備工具，某種程度上已經失去了它的優勢地位。垃圾內容制造者、以點擊率為終極目標的內容聚合站點正在走向勝利。

在 這一點上來說，ifanr 感同身受。作為內容提供者，我們是創造價值的人，是在給互聯網不斷添磚加瓦的一方。而之前在 Google 里搜索我們的原創文章，出現在結果最頂端的卻往往是是通過拷貝+粘貼、有時候還不注明出處進行轉載的內容聚合站點。它們用毫無成本的方式奪取著應該屬于原 作者的訪問量。

好在 Google 似乎已經認識到了這一點。之前搜索質量組的 Matt Cutts 表示他 們已經意識到了垃圾內容的增多，以及劣質內容聚合站點引發的不滿，并且會很快進行處理。從我今早的實驗來看，似乎 Google 已經采取了措施，最近 ifanr 的原創文章都出現在首頁頭條。從根子上（點擊量帶來的經濟利益）驅逐劣質內容聚合站點，對現代互聯網來說，確實是件好事

搜索，是 Google 的立身之本，從上周發布的財報來看，Google 收入的主要增長點仍然是在網站本身的業務。不斷改進搜索，添加新的搜索方式，才能保持和增強 Google 在這個領域的領導地位。后院不起火，才有在其他領域發展的資本。

這一條，是 Larry Page 上任以后最需要關注的。未來十年的搜索是什么樣子？如何提高內容關聯性，改進使用體驗？怎么樣通過創新，把 Bing 等競爭對手遠遠甩開，對 Google 來說，至關重要。

2：在社交網絡方面另辟蹊徑

Google 在社交網絡方面的試探，到目前為止都是悲劇，坦率地說，我個人認為Google 已經錯過了第一班社交網絡的列車。

作為新生事物的社交網絡，從一開始負載的是用戶虛擬交流的需求。

目 前的勝利者里面，Facebook 滿足了人們交流的愿望，利用網絡，表現了某種程度上真實的人與人關系，而大量互動元素的引入，則是模擬了現實生活的部分人際往來，從根底上來說，沒有理念 上的創新，然而它仍然足夠偉大，Facebook 把現實生活成功投影到了虛擬世界，是真正意義上的創造者。

另一個贏家是 Twitter，它滿足的，是人們表達自己的愿望。通過簡短的 140 個字，人與人之間形成了一種奇妙的交流關系，普通人也可以第一時間見證重大事件。可以說，Twitter 與智能手機的結合，創造了一種新媒體。表達自己，記錄周邊，關注別人，是 Twitter 類社交網絡的根本。無論是變種的 foursquare，還是 Quora，從理念上看，都是這樣的東西。

Google 之前的嘗試呢？ Wave 那個體驗一塌糊涂的東西不去說它，出生太早了；Buzz 則是無限制版本的 Twitter：Google 試圖利用現成的龐大用戶群，但沒有實質性創新，再加上拙劣的整合方式，這個產品的前景樂觀不到哪兒去。

社交網絡走到現在，實際上已經到了一個重要的關口，即：虛擬的內容如何與現實社會結合起來，怎樣把線上關系與實體經濟整合，創造出一個嶄新的商業模式。在我看來，這才是第二代社交網絡，也即成熟版本的社交網絡。這個方向是未來兩年的熱點，也是 Google 下一步可以突圍的角度。

Google 的最大優勢是什么？大家應該都非常清楚，其一是龐大的用戶群，其二就是信息了。Google 相對于 Twittter、fousquare 等來說，先天就有信息方面的優勢。而 Google 在建設社交網絡的時候，卻完全忽略了這個優勢，捆著手腳去從頭開始跟已經成熟的對手競爭，怎么可能勝利？

舉個最簡單的例子，Google Maps 信息豐富，我經常用它來尋找晚餐地點，最大的好處之一就是可以看到多個網站的用戶評價，看看截圖：

看 到了吧，有 Buzz 選項，然而搞笑的事來了。我可以看到其他網站的評價，可以在 Buzz 上分享這個地點，然后呢？沒了。我完全看不到 Buzz 關于這個餐館的討論，看不到我分享以后朋友的看法——一點也沒有。實體經濟方面的內容本身就是 Google 的長項，然而在它的任何產品里面，都沒有把這個長處跟自己的社交網絡更緊密得結合起來。

放著龐大的現實數據不用，幾個產品之間幾乎沒有交流，捧著金飯碗要飯，這就是 Google 的社交網絡。跟現實社會結合的社交網絡，將是 Google 在這一領域的最后一個機會。

3：細節，細節，還是細節

有一句老話，細節決定成敗，然而 Google 現在的很多做法，卻表現了一種對細節的漠視，極大影響了產品的使用體驗。還是要以 Android 為例（這玩意簡直就是反面教材）：

就從簡單的設置界面說起。Android 平鋪直敘的設置界面，完全沒有突出重點（我甚至懷疑這幫人安排順序的時候是不是拍腦門做出的決定。），跟右邊的 iOS 比，孰優孰劣，一目了然。

還有應用市場，每次談到 Android 的應用市場，我都有爆粗口的沖動。緩慢的速度、時常丟失的已下載應用列表、遲遲沒有解決的應用無法下載問題……這是整個產業的核心之一，Google 就準備這么糊弄下去？

Android 不講究的地方何止這些，工程師文化并不代表著可以不拘小節，Google 的目光，應該多放些在細節上。移動設備，用戶體驗至關重要。

4: 繼續擁抱云，下注新能源產業

在這個賣雜貨的、搞 B2C 的、做軟件的都在搞云應用平臺的當口，互聯網界巨頭，擁抱云的先驅之一，可能擁有著世界上最好硬件以及網絡設施的 Google，當然也擁有自家的 App Engine。

云 計算平臺對于中小企業、個人的意義，無論如何贊揚也不會過分，它直接引領了當前的互聯網創業潮。低廉的平臺成本，按需付費的方式，Amazon EC2 吸引了大量的個人開發者，Google 的 App Engine 當然不錯，但我要說，還是不夠靈活，如果能提供更多語言支持，就再好不過了。

新能源很好理解，隨著碳交易市場的興起，碳排放量眼看就要變成金融市場上的一個新產品。在這個趨勢影響下，每個企業都應該考慮下自己的能源來源，為將來更加嚴格的排放調控措施做好準備，規避可能的經濟風險。

降低所消耗能源的碳排放，對于 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

沒有人能說清哪種緩存算法優于其他的緩存算法。（以下的幾種緩存算法，有的我也理解不好，如果感興趣，你可以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（運行在 GAE/J 上的博客程序） 代碼后發現 Google Code 版本控制系統會將提交日志同步發布到 Google Buzz 中：

但在 Buzz connected sites 里并沒有看到與 Google Code 關聯：

現在一提交代碼就 Buzz，還是比較無奈的....