上周硅谷非常熱鬧，重大消息頻繁出現，其中包括了喬布斯因病休假，蘋果的恐怖財報等等。對于我們所關心的移動業界跟互聯網來說，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，還是比較無奈的....

有時我們需要隨機地獲取數據記錄（實體），比如博客程序中的“隨機文章”的實現。

目前 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）來過濾實體保存的隨機值屬性。

這個方法基本可以達到隨機的效果了，為了讓隨機的效果更動態一點，我們可以考慮經常更新文章實體中的隨機浮點值：

• 訪問文章時（即在更新文章瀏覽次數時一并更新該文章的隨機浮點值）
• 后臺定時任務（獲取一定數量的隨機文章然后更新它們的隨機浮點值）
• 用戶做文章更新時

加上以上處理后，隨機的效果比較好了 :-)

作者 榮浩 發布于 2010年12月28日 上午12時0分

對jBPM來說，今年最大的事件莫過于jBPM的創建者Tom Baeyens離開JBoss了。Tom Baeyens離開的具體原因尚不清楚，但他的離開產生了兩個結果：一是jBPM的下一個版本jBPM5完全放棄了jBPM4的基礎代碼，基于Drools Flow重頭來過；二是Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統Activiti。 由此不難推測Tom Baeyens離開的部分原因：JBoss內部對jBPM未來版本的架構實現產生了嚴重的意見分歧。更加巧合的是12月1日Activiti5剛發布，緊 接著12月2日jBPM5就發布了第一個候選發布版本，jBPM與Activiti之間的微妙關系可見一般。

在這篇文章里，我們將一起回顧jBPM從jBPM3到jBPM5以及Activiti5的發展歷程，我們可以清晰的看見jBPM（包括 Activiti）設計所遵循的一致原則：強調流程服務的可嵌入性和可擴展性。同時，從各個版本之間的變化我們也能看見產品設計思路的變化：更加強調面向 業務人員，增加BPMS（業務流程管理系統）特性。

在回顧之前，我們首先討論一下BPMS應該嵌入還是獨立部署的問題，因為不管是jBPM還是Activiti，都強調了流程服務的可嵌入性。此外，我們還需要討論一下什么是BPMS的特性，它們所解決的問題是什么。

一、嵌入式還是獨立部署？

不管是jBPM還是Activiti，都強調了流程服務的可嵌入性。Tom Baeyens在其個人博客里稱作為獨立部署的BPMS已死，原因有兩個：一是獨立部署的BPMS需要很高的安裝使用成本，需要獨立部署、需要用戶支出大 量的培訓成本和維護成本；二是獨立部署的BPMS與外部系統的交互方式是分布式，這使得很多問題變得復雜，例如分布式事務。Tom Baeyens代表了相當一部分人特別是開發人員的觀點。

Tom Baeyens沒有完全理解BPMS。什么是BPMS？BPMS最重要的目標就是需要打破各個應用系統（CRM、ECM、ERP、SCM）之間的界線，將 分散在這些系統中的流程集中管理，這是BPMS的實質。一如流程再造，打破各個部門之間的壁壘，減少浪費，建立流程驅動性的組織。如下圖1所示：

圖 1：BPMS打破應用系統之間的界線

BPMS所要解決的問題要求其必然是獨立部署的。Tom Baeyens錯誤的根本原因在于其將BPMS與工作流系統的定義混為了一談，他如此定義BPMS：BPMS旨在簡化對組織核心流程進行支撐的軟件創建。 也就是BPMS面向的是軟件開發人員，旨在簡化他們的開發，降低他們使用流程的門檻。而這正是工作流系統需要解決的問題。

BPMS面向企業用戶，工作流面向開發社區和系統集成商。

二、BPMS特性

jBPM4、jBPM5和Activiti5都增加了其BPMS特性，那些特性能夠稱為BPMS特性呢？我們先看一看BPMS需要解決的問題，為解決這些問題所增加的特性就是BPMS特性。

1. 如何設計流程，在組織中高效地對設計出的流程進行溝通，取得共識？

   • 提供跨越組織的流程標準標記符號與術語（BPMN已經成為標準）
   • 流程及相關文檔的可視化（流程/內容存儲倉庫）
   • 提供在組織結構內進行不同層次之間的流程導航（流程存儲倉庫支持組織模型）
   • 流程定義在各個層次/部門間的一致性，避免業務人員的流程建模轉換到IT系統時受到損耗（流程引擎支持基于圖的建模，支持擴展）

2. 如何更好地執行流程？

   • 業務活動的實時監控，預警與控制（BAM）
   • 流程執行的仿真
   • 流程執行的統計分析與反饋（報表）
3. 如何更好地管理流程？
   • 打破各個應用系統之間的界線，統一管理所有流程（EAI，與ESB的集成）
   • 對業務人員友好的建模工具
4. 如何在執行流程過程中遵循業內最佳實踐和規則？
   • 面向流程的知識管理
   • 規則引擎

三、完整的工作流實現jBPM3

jBPM3的最新版本是3.2.7，其包括了以下組件：基于Eclipse的流程設計器、用于監控案例（流程實例）和處理任務的Web控制臺以及jPDL核心庫。如下圖2所示：

圖 2：jBPM3組件

1. 基于Eclipse的流程設計器

   提供給開發人員繪制jPDL流程圖，因為該設計器基于Eclipse，所以生成的流程文件可以與開發代碼一起組織管理，非常容易進行單元測試。實現了工作流管理系統參考模型里的接口1。

2. Web管理控制臺

   主要有兩個功能：一是作為工作流客戶端應用接口，給用戶提供一種手段，以處理案例運行過程中需要人工處理的任務；二是對案例的狀態進行監控與管理。實現了工作流管理系統參考模型里的接口2和5。

3. jPDL核心庫

   jPDL核心庫是一個單獨的JAR包，可以嵌入到目標應用中執行，它包括了：

   • 流程倉庫：解析jPDL流程定義文件并存儲讀取；
   • 流程引擎：對流程定義進行初始化和調度執行，節點的運行期行為與jPDL里定義的節點類型一一綁定；
   • 任務管理：生成任務節點所對應的工作項，管理工作項的生命周期（初始化、分配執行者、執行、掛起、結束、終止）；
   • 事件管理：發布案例和任務的開始、結束事件，通過監聽者模式調用相應的事件處理器；
   • 異步執行機制：通過線程實現了Job Executor，進行異步工作的處理，這些工作包括了時間處理、異步動作。
   • 身份組件模型：實現了一套簡單的身份組件模型，包括了組、用戶和權限。

   通過調用自定義Java代碼實現了對外部應用的調用，從而實現工作流管理系統參考模型里的接口3。

jBPM3是一個輕量級的嵌入式工作流系統。它在Java社區的成功得益于兩個方面：一是嵌入式，這降低了使用工作流的門檻；二是對開發人 員友好，這表現在易讀的jPDL、流程的可測試性(Eclipse插件)以及節點行為的可擴展性，我們可以非常容易的在流程運行中加入自己定制的行為（通 過事件處理器和Action）。jBPM3面向開發人員，它解決的問題是流程的自動化，它的影響力集中在Java開發社區，是一個完整的工作流系統實現。

四、向BPMS努力的jBPM4

與jBPM3相比，jBPM4最大的變化是引入了流程虛擬機（PVM），同時增加了BPMS的特性。jBPM4不再滿足于工作流系統的定位，開始向BPMS努力。

1. 為什么引入流程虛擬機

   盡管jBPM3在Java社區取得了很大的成功，但是有一件事始終被人們詬病，那就是它不支持流程語言規范，從最開始的XPDL、BPEL 到后來的BPMN，它采用了自定義的jPDL。在jBPM3中，節點的運行期行為與jPDL里定義的節點類型是一一綁定的，這造成了流程引擎與特定流程語 言的綁定，要支持其他的流程語言變得困難。于是在jBPM4中，jBPM提出了流程虛擬機的概念，即流程引擎與流程語言解耦，通過一套通用的流程模型并配 以可定制的節點運行期行為實現了對多流程語言的支持。

   流程虛擬機帶來的好處是多方面的：第一也是最重要的是jBPM4支持了BPMN。

   第二是實現了基于流程組件的流程引擎，流程圖(語言)與實現解耦，我們使用通用編程語言實現節點運行期行為，稱之為流程組件，通過將流程圖 與流程組件掛接，避免了圖的損耗。在這一點上，Tom Baeyens對BPMN到BPEL的轉換提出了一針見血的批評：BPMN和jPDL以及XPDL都是基于圖的，而BPEL是基于塊的，這造成了當將業務 人員使用BPMN所建立的流程模型向BPEL執行模型進行轉換時，出現許多的不匹配，最初的流程模型會扭曲變形。而扭曲的后果就是業務人員與開發人員之間 的協作困難，這影響了流程從業務到技術的實現。

   第三個好處是我們可以定義領域特定語言（DSL），在特定的應用里，采用DSL約定并隱藏了大部分的技術細節可能做到業務人員對執行流程的直接修改，例如企業文檔管理里的審批流程。

2. BPMS特性的加入

   這表現在以下三個方面：第一是支持了BPMN，BPMN已經成為業務人員的流程建模標準；第二是引入了Signavio作為面向業務人員的Web建模器；第三是在已有的Web管理控制臺加入了對案例和任務的統計功能。jBPM4的組件如下圖3所示：

   

   圖3：jBPM4組件

   和jBPM3一樣，jBPM4依然是輕量級的、可嵌入的工作流系統。相比jBPM3，它將業務人員作為最終用戶之一，增加了部分BPMS特性，同時PVM的引入使得它的可擴展性得到了極大的增強，我們甚至可以定義自己的DSL。

   在BPMS特性里我們提到了應該避免業務人員的流程建模轉換到IT系統時受到損耗，最理想的情況是業務人員與開發人員共用一個流程模型，業 務人員能夠直接對流程進行調整（在特定應用中，通過DSL是可以做到的）；其次是通過BPMS將業務人員的模型與實際執行的技術模型關聯起來（很多商業產 品已經做到了這一點，在Activiti5中我們也會看到這一點），業務人員、開發人員以及運營團隊之間能夠做到很好的協調；最差是業務人員與開發人員各 自為政，獨立維護各自的流程模型，并且模型之間存在極大的不匹配，此時流程的迅速變化基本上是奢望。

五、鳩占鵲巢的Drools Flow與jBPM5

目前jBPM5剛剛發布了第一個候選發布版本，jBPM5基本上完全拋棄了jBPM4的代碼，所有代碼全部來自原先的Drools Flow。Drools Flow最初被用來解決規則執行順序的問題。其實從Drools Flow開始支持BPMN時起，我們已經預感到它與jBPM的競爭關系。

jBPM5依舊定位為輕量級的可嵌入的工作流系統。在jBPM5的特性里，有這么兩條引人關注：一是引入了Guvnor作為流程倉庫，這解決了流程 的可視化問題，流程定義作為資源被管理，我們可以對流程定義進行可視化管理以及全文檢索（Guvnor使用了Jackrabbit作為了其存儲實現，但我 們的經驗表明Jackrabbit在大數據量情況下性能存在嚴重問題）；第二是規則引擎(Drools Expert)、事件處理引擎(Drools Fusion)與流程引擎的合三為一，這是jBPM5最讓人期待的地方。jBPM5的組件如下圖4所示：

圖 4：jBPM5組件

規則引擎在流程中的應用已經非常廣泛了，我們這里說說事件處理引擎。

事件處理引擎是業務活動監控（BAM）的基礎，BAM的功能及執行過程，如下：

• 捕獲：BAM捕獲各種事件（通過消息監聽器、適配器、代理等）。這些事件來自應用、系統軟件、外部交易伙伴。消息是BAM的核心——它們反應底層業務流程的狀況。
• 過濾：BAM過濾掉沒有直接后果的事件，在很多情況下由支持事件流處理（Event Stream Processing，簡稱ESP）或復雜事件處理（Complex Event Processing，簡稱CEP）引擎來進行過濾。
• 分析：BAM根據分析模型和規則將相關事件聯系起來。
• 警告：BAM向用戶提出警告，以便用戶在必要時進行控制。

如上所示，BAM的執行過程包含四個步驟，而前三個步驟都是對事件進行相關的處理（捕獲事件、過濾事件、分析事件、關聯事件），因此在大多數BAM的技術實現方案中，都基于CEP和ESP的引擎來實現BAM的功能。

與jBPM4相比，jBPM5對PVM的放棄也帶來了幾個不小的問題：第一是對開發人員來說只支持BPMN，不再支持jPDL（當然提供了遷移工 具）；第二是流程執行的可擴展性回到了jBPM3的年代，僅僅支持自定義動作（相當于jBPM3里的Action）。此外，Web建模器由 Signavio替換為了Oryx Designer。

總而言之，jBPM5通過引入流程倉庫和BAM繼續向BPMS邁進（目前的進展是與流程倉庫的集成還未完成，BAM基于日志進行分析），同時，由于不再支持PVM和jPDL，帶來了流程擴展性的降低和社區開發人員的未來流失。

六、Activiti5的反擊

Activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的開源工作流系統，1號剛剛發布第一個版本。Activiti的開發團隊相比與jBPM強 大了許多，有23位核心開發者。當然這也是由于activiti規劃的功能所致：包括核心引擎、Web的流程建模器、協作工具Activiti Cycle、Activiti Probe、Activiti Explorer、與Spring的集成、與Mule的集成等。

圖 5：Activiti5的組件

如上圖所示，Activiti5由三種類型的組件組成，分別是：專用工具（Dedicated Tools）、內容存儲工具（Stored Content）和協作工具（Collaboration Tool）。

專用工具包括以下：

• Alfresco—Alfresco公司的企業級內容管理產品

Alfresco 是一個開源的、企業級的內容管理系統，功能包括：文檔管理、協作、記錄管理、知識庫管理、Web內容管理等功能。Alfresco與Activiti的深 入集成實現了流程及相關文檔的可視化。更重要的是Alfresco支持組織模型，能夠提供在組織結構內進行不同層次之間的流程導航。

• Activiti Modeler—建模器

基于開源Signavio Web流程編輯器的一個定制版本，提供了對BPMN2.0圖形化規范的支持，建模后的流程以文件格式進行存儲。

• Activiti Designer—Eclipse插件形式的建模器
• Activiti probe—管理及監控組件

對流程引擎運行期實例提供管理及監控的Web控制臺。包含部署的管理、流程定義的管理、數據庫表的檢視、日志查看、事務的平均執行時間、失敗多次的工作等功能。

• Activiti Explorer—任務管理組件

提供任務管理功能和對案例、任務基于歷史數據的統計分析（報表）功能。Web應用程序。

內容存儲工具：包括了文檔倉庫、模型倉庫、SVN倉庫、MVN倉庫和Activiti引擎。其中文檔倉庫、SVN倉庫和MVN倉庫三個組件為協作工具（Activiti Cycle）提供底層的支撐。Activiti引擎則是以前的PVM。

協作工具：與jBPM4相比，Activiti5最令人矚目的特性就在于它的協作工具組件。

Activiti Cycle完全是一種新類型的BPM組件。它是一個用來促進業務人員、開發人員和IT運營人員協作的Web應用程序。 在現實的場景中，業務文檔有業務人員所持有，而軟件程序由開發團隊所管理，被部署的軟件應用則被IT管理人員所管理。三者之間不能很好的協作。我們可以想 象這樣一個場景，業務經理用文檔來維護需求和visio格式的流程圖，開發人員管理可執行的流程和大量的Java源文件而IT維護人員則管理部署在 Tomcat中的.war文件和存儲在Activiti數據庫中的流程。

圖 6：Activiti cycle協作組件邏輯示意圖

Activiti Cycle通過BusinessLink將與流程相關的業務人員、開發團隊與IT維護人員關聯起來，實現他們之間的協作。

總而言之，與jBPM4相比，Activiti5目前最重要的增強就是實現了流程的可視化以及創新的Activiti Cycle協作組件，此外，通過與Mule的集成加強了其集成能力。其對PVM的保留使其繼承了jBPM4強大的可擴展能力，對jBPM的老用戶來說，這是向其遷移的重要理由。

七、總結

jBPM3是一個完整的工作流系統實現，面向開發人員，目的在于簡化對組織核心流程進行支撐的軟件創建，不支持標準。

jBPM4引入PVM，使其擁有更強大的擴展性，同時增加BPMS特性，這些特性包括了對BPMN的支持、面向業務人員的Web建模器和簡單統計分析功能的加入。

jBPM5基于原先的Drools Flow，支持BPMN，通過與Drools的合并支持BAM，通過內容倉庫增加對流程可視化的支持。由于放棄了jBPM4的PVM，引擎的可擴展性受到損害，并且不再支持jPDL。

Activiti5基于jBPM4，與Alfresco的集成增加了其流程可視化與管理能力，同時通過創新的Activiti Cycle協作組件支持流程相關人員之間的協調，最后，它加強了集成能力。

對于工作流應用或者jBPM3、jBPM4的老用戶，建議轉向Activiti5。

關于作者

榮浩，ThoughtWorks咨詢師，關注敏捷和企業流程改進過程，目前正與辛鵬合著《Head First Process-深入淺出IT流程》一書。博客地址http://ronghao.javaeye.com。

轉自：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5

有很多理由都能說明為什么我們應該寫出清晰、可讀性好的程序。最重要的一點，程序你只寫一次，但以后會無數次的閱讀。當你第二天回頭來看你的代碼 時，你就要開始閱讀它了。當你把代碼拿給其他人看時，他必須閱讀你的代碼。因此，在編寫時多花一點時間，你會在閱讀它時節省大量的時間。

讓我們看一些基本的編程技巧：

1. 盡量保持方法簡短
2. 永遠永遠不要把同一個變量用于多個不同的目的
3. 使用自描述的變量名和方法名
4. 盡可能的把變量定義在靠近使用它的地方
5. 拒絕神秘數字
6. 友好的對待你的語言
7. 不要逆常規而行
8. 警惕過早優化
9. 積極重構測試過的程序
10. 不要過度沉迷于技巧
11. 通過習例學習新知

現在，讓我們把每個小點展開來詳細講一下。

1. 盡量保持方法簡短

盡管很多人都遵循這個規則，但它仍然非常的重要。你寫的方法要始終能在一個屏幕里放得下。如果你需要去滾動屏幕，這會分散你的注意力，而且你看不到 整個的上下文。最佳長度是5-20行，這根據你的情況而定。當然，getters/setters 通常是一行代碼的方法，但與其說它們是真正的方法，不如說它們只是存取工具。

2. 永遠永遠不要把同一個變量用于多個不同的目的

一個變量應該始終只為一個目的服務。通過使變量常量化(C++里的const， Java里的final)，使得編譯器能夠優化編譯，而且使你的代碼醒目表達這個變量是不能改變的，你的程序的可讀性會變得更好。

3. 使用自描述的變量名和方法名

你的代碼應該，對于任何人來說，只要看一眼就能知道是干嘛的。盡量不要用簡寫方式，除非有特殊的習慣，就像下面的：

 src - source
 pos - position
 prev - previous

如果你認為描述性的名稱并不是那么有價值，請對比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。

4. 盡可能的把變量定義在靠近使用它的地方

蓋房子時，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。

int foo = 3;
int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

baz(foo);

這段代碼可以簡單的重構成

int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

int foo = 3;
baz(foo);

當你把變量的聲明和第一次用到它的地方間隔太遠時(距離超過一個屏幕)，這確實會成為一個問題。記住上下文關系會變得困難，你需要滾動屏幕去找哪來的這個變量。

5. 拒絕神秘數字

當你要把什么東西跟一個常量值做比較時，記得把這個值定義成常量。沒有什么會比去猜測你的同事寫的這樣的代碼更讓人頭疼的事了：

il < 4384

換個形式感覺如何？

inputLength < MAX_INPUT_LENGTH

6. 友好的對待你的語言

學習新語言是一種很有樂趣的事情，你能學到一種新的完成任務的途徑。當一個對一種語言已經很專業的人去學習另一種語言時，會出現一種很大的負面效應。比如說你是一個Java開發者，試圖去學習Ruby。你應該學會用Ruby的方式解決問題，而不是沿用Java的解決問題的思想。

當你需要重復5遍”Hello world！“時，在Java里，你可能會這樣做：

for (int i = 0; i < 5; i++) {
    System.out.println("Hello world!");
}

在Ruby里，你也許會禁不住這樣寫：

for i in (0..5)
  puts "Hello world!"
end

這樣看起來沒問題，但有一個更好的方式：

5.times { puts "Hello world!" }

7. 不要逆常規而行

每種語言都有自己不同的習俗約定。一般來說，人們聽的最多的是Java的編碼規范。讓我們看看其中的一些習俗規范：

• 方法名應該小寫字母開頭，其后用字母大寫的單詞連接(veryLongVariableName)
• 類名應該都使用首字母大寫的單詞連接而成
• 常量名應該全部大寫，用下劃線連接(MY_CONSTANT)
• 左大括號應該跟 if 語句在同一行

只有在有必要的理由時才去打破這些常規，不要輕易的因為你不高興就違反它。如果你只是在團隊里改變一些這樣的習慣，那也沒問題，但當把你代碼拿出來和其他的沒有這些思想準備的程序員共享時，問題就會來了。

8. 警惕過早優化

過早優化是所有問題的根源，至少電視上是這么說的 … 你第一應該關心的事情是寫出易于理解的代碼。起初寫的程序不要求快。除非你的程序很慢，否則談優化都是為時太早。如果你想優化什么東西，你首先需要知道問題出在哪。這就是我們需要profilers這個工具的原因。

在沒有知道問題在哪的情況下試圖對程序進行優化，其結果必然是把程序能壞，至少你的代碼會喪失可讀性。如果你覺得有些地方很慢，不要盲目的重寫代碼，你應先找到慢的證據。

不要傻乎乎的去解決根本不存在的問題。

9. 積極重構測試過的程序

沒有任何東西會是完美的。即使你感覺你真正寫出了一段完美的代碼，幾個月后回頭再看看，你可能會驚訝道”怎么會這樣傻？“

改進程序的一個好方法就是重構，但要等程序測試通過之后。你首先要確保程序是好的可運行的，你可以通過自動化測試或手工測試完成這個工作。

之初，你需要的是程序可用。不要期望在第一次就寫出完美的程序，你只需要把它寫出來，可用。然后重構它，使之完美。對于你們當中知道測試驅動開發 (TDD)的人來說，對這個會很熟悉。這里的關鍵就在于你要習慣于重構這種事情。如果你使用的是像IntelliJ IDEA這樣強大的集成開發工具的話，重構的工作會變得簡單的多。

重構之后，你也許會弄出一些Bug，導致某些功能出問題。這就是為什么說寫自動化測試的原因。不論何時重構后，只要運行一下所有的測試用例，你就能準確的知道什么地方出了問題。

10. 不要過度沉迷于技巧

當我第一次讀到有關設計模式的知識時，我覺得我找到了圣杯。這些精心設計的思想作用顯著，它能使你的設計易于理解，因為你可以簡單的說”我使用的是 ‘觀察器模式’“，而不用從頭到尾的解釋一遍。那么，有問題嗎？一切看起來都這么自然、簡單，你開始不論在哪都使用設計模式。為什么不把這個類做成 singleton呢？干嘛不去再創建一些工廠類呢？

于是一個80行就能寫完的腳本，你最終使用了10個類，15個接口，外加一大堆范式和標記符。97%的代碼不做任何事情。設計模式是一種十分有用的用來簡化你的設計的工具，但這不意味著你該在所有能用到的地方都用它。你應該用它們，但不能濫用。

11. 通過習例學習新知

編程是一種學習新知的過程。當你學到了新的程序庫或新語言，你可能會迫不及待的丟掉舊的代碼，用你新學到的東西重新寫一遍。有很多的理由都能說明你不該這么做。

往現有的應用里增加新的類庫或框架同屬于這種情況。就說你寫了一個Javascript的web應用，期間，你發現了jQuery。現在你突然急切的想丟到你的Javascript程序，重新用jQuery寫，盡管你還從來沒用過它。

最好的方式是你先用jQuery寫一些簡單的例子，通過這種方式把你在應用里將要用到的知識都學會。需要AJAX？在你的項目之外做一些小例子，當完全弄懂了后，丟掉例子，應用到你的產品里。

如果你非常關注編程技術，我強烈的推薦你閱讀Steve McConnell寫的 《代碼大全》 一書。它會永遠的改變你對編程的認識。:)

[英文出處]：11 tips for better code

[譯文來源]：外刊IT評論

“我說我是警察，也是執法 人員，應該文明執法，但還是被打斷腿！”昨天，躺在病床上，昆明市 公安局民警張俊(化名)說起事發當天的情形時，依然有些憤怒！當天他接到母親的電話，說轄區城管要強行拆除小區內的違章建筑，讓他回家收拾東西。不料，張 俊剛到門口表明自己身份時，卻遭到拆遷執法人員的圍毆。據小區目擊者稱，張俊被毆打時，對方揚言“打的就是警察！”。

“我還以為身上有警械，就能夠證明自己身份。”昨天下午，在解放軍昆明總醫院骨科住院部，記者見到了被打傷的張俊，他向記者講述了事發經過。

“我是警察，也是執法人員。”張俊說，為了阻止自己被繼續毆打，他一邊表明自己的身份，一邊準備從身上掏證件。慌忙中，張俊只摸到了自己隨身攜帶的一根伸縮警棍，這一摸不要緊，更是遭了對方一頓暴打。

當 時現場執法人員叫張俊放下警棍，然后將他的警棍拿走。張俊說，第一次被打之后，自己的鼻子和嘴角已經被打出血了。但噩運還沒有結束，之后，他被4名城管反 綁著雙手押到鄰居家的門前。他再次向執法人員提出要回家收拾東西，但沒有人理他。聽到他的反復要求后，一名執法人員轉頭對他說：“你拿警棍打我，怎么可能 讓你上去。”張俊表示，他拿出警棍根本沒有打到人。“我是市公安局的，也是執法者，執法要文明。”張俊說完時就聽到對方一句狂噴：“你敢用手指頭指我，兄 弟們，拿下。”

張俊說，他只感覺周圍的20多名城管全部圍了上來，用警棍和鐵棍將他打倒在地，還有人上前用腳踩他。當時他感覺自己的右腿很疼，他大聲懇求：“求求你們別打了，我的腿斷了。”隨后，他被打暈在地。

現 場很多小區業主都目睹了張俊被毆打的過程，“總共被打了兩次。”張俊的鄰居老邢說。同樣目睹事情經過的程先生也說，張俊大概被毆打了10多分鐘，他遠遠看 著張俊滿臉都是血，倒在地上。他聽到在場的一位執法人員對著幾乎快暈厥過去的張俊喊道：“裝死。”張俊的好友陳小姐說，現場就有執法人員帶去的救護車，但 沒有對他進行救治。

而對此，當時執法拆除違章建筑的昆明市綜合行政執法局盤龍分局負責人稱，是張俊先揮舞警棍導致沖突發生。

據知情人稱，事件發生之后，已經有一名參與沖突的執法隊長被拘留，但此說法未得到有關部門的證實。

轉自：http://news.qq.com/a/20110103/000492.htm?qq=0&ADUIN=845765&ADSESSION=1294033435&ADTAG=CLIENT.QQ.3187_.0

過去與今天
詞 \ 黃家駒. 曲 \ 黃家駒. 主唱 \ 黃家駒.

夜雨街中里寧與靜
霧色燈影照我身
在我的心里常會問
幻變的都市四周
可知我已放棄舊日的理想
知否我也有個夢 要我醉倒
就像 就像 就像
像那方的星光閃動 眼也會發光
仰望浮云常變不定 暗里嘆一聲
沖出他朝崎嶇道上 哪怕會退倒
試問誰人曾會考慮 過去與今天
踏破這黑暗寧與靜
誰會管失意冷風
幻變的都市誰問過
讓暖風緊靠我身

EverBox 是一款由盛大創新院推出的網盤產品，提供數據存儲和同步服務。EverBox 提供了 10GB 超大免費存儲空間，支持文件同步、文件分享、在線瀏覽照片、在線聽音樂等功能，并支持數據同步客戶端。需要邀請的朋友可以改我留言 :-)

主要功能：

支持數據同步客戶端：安裝 EverBox后，您所需的文件都將自動同步到設備上，可以隨時、隨地的使用手邊的任意一款設備訪問文件了。目前提供了 Windows 客戶端程序，支持 Windows XP，Windows Vista 和 Windows 7。在以后的版本中，EverBox 將會陸續推出其他客戶端程序，如： Android，iPhone，iPad，Mac，Linux 等。

容災備份服務：EverBox 會自動的、實時的備份文件數據到 EverBox 安全服務器，因此，當您本地的設備壞損或丟失時，不必擔心由于數據丟失造成的損失，恢復數據易如反掌！

在線音樂播放：EverBox 支持在線音樂播放功能，幾乎支持所有常用的音頻格式，使用簡單、便捷，無需操作即可連續播放 EverBox 當前目錄中的歌曲，很適于一邊使用電腦一邊聽歌時使用。

在線瀏覽圖片：EverBox 支持在線瀏覽圖片功能，幾乎支持所有常用的圖片格式，操作簡單、便捷，并支持自動播放 EverBox 當前目錄中的圖片文件。

EverBox 功能特性

1. 10GB 超大免費空間

   成功注冊 EverBox 即可獲得 2GB 免費空間，完成指定任務可升級空間到 10GB！EverBox 在隨后的版本中將會有更多的獎勵措施，贈送活躍用戶更多空間，敬請期待！

   

2. 支持數據同步客戶端

   您是不是經常遇到以下的情況？“我喜歡在外出時用 iPhone 聽歌，但是我需要從 PC 下載歌曲再用數據線將 MP3 導到 iPhone”；“我經常出差，但是程序和文件都在笨重的 PC 上，而我只帶著筆記本”；“我到 XX 會議做演講，但是保存 PPT 的 U 盤壞掉了”。

   現在有了 EverBox，這些問題將迎刃而解！只需安裝 EverBox，您所需的文件都將自動同步到設備上，您就可以隨時、隨地的使用手邊的任意一款設備訪問文件了。當然，使用瀏覽器一樣可以訪問到您需要的文件。

   

3. 容災備份服務

   硬盤損壞？數據無法訪問？筆記本電腦被盜？完了，重要的數據丟失了！

   不用擔心，有了 EverBox，這一切都不會再是問題。EverBox 會自動的、實時的備份文件數據到 EverBox 安全服務器，因此，當您本地的設備壞損或丟失時，不必擔心由于數據丟失造成的損失，恢復數據易如反掌！

   

4. 在線音樂播放

   EverBox 支持在線音樂播放功能，幾乎支持所有常用的音頻格式，使用簡單、便捷，無需操作即可連續播放 EverBox 當前目錄中的歌曲，很適于一邊使用電腦一邊聽歌時使用。

   

5. 在線瀏覽圖片

   EverBox 支持在線瀏覽圖片功能，幾乎支持所有常用的圖片格式，操作簡單、便捷，并支持自動播放 EverBox 當前目錄中的圖片文件。

   

    

GAE 博客 —— B³LOG Solo 0.2.5 Beta1 發布了。

該版本除了修復 Bugs，還增加了草稿夾、多人寫作、改進了緩存，以及加入了新皮膚 community。

借此機會，祝大家圣誕節愉快，一切平安 :-)

新特性

• 多人寫作
• 鏈接排序
• 新皮膚——community（多人寫作皮膚）

Bug 修復

• 緩存多實例不一致
• 文章訪問次數統計失效
• IE8 下 Feed 不能顯示

改進

• 存儲對象緩存
• 自定義頁面排序方式
• 改進了頁面緩存

具體改動看這里。

升級

如果您是 0.2.1 的用戶，那么請在部署完 0.2.5 Beta1 后登錄后臺，訪問 http://${application-id}.appspot.com/upgrade/v021-v025.do 進行升級。

項目

如果在使用、測試中發現任何問題，如果您有任何意見或建議，請告知我們 :-)

• 項目地址：http://code.google.com/p/b3log-solo/
• 下載：http://b3log-solo.googlecode.com/files/b3log-solo-0.2.5-beta1.zip
• Bug/特性提交：http://code.google.com/p/b3log-solo/issues/list

發布計劃

• 2011 年 1 月 21 日發布 0.2.5 Beta2
• 2011 年 2 月 14 日發布 0.2.5

作者博客

• 簡約設計の藝術
• Vanessa
• 羔羊<>沉默

發布歷史

1. GAE 博客——B3log Solo 0.2.1 發布了！
2. GAE 博客——B3log Solo 0.2.0 發布了！
3. GAE 博客——B3log Solo 0.1.1 發布了！
4. B3log Solo 0.1.0 發布了！
5. B3log Solo 0.1.0-preview2 發布了！
6. Solo 0.1.0-Preview1 發布了

最近一個潛在客戶要求我們比較一下 Amazon EC2 和 Google App Engine，正好我們剛剛在 EC2 和 Google App Engine 上完成了兩個相對來說規模較大的項目，因此有必要做一下總結。

我打算從三個角度來對比這兩大云計算平臺：技術，業務和未來發展趨勢，本文是技術方面的對比，ok，準備好咖啡，我們開始吧！

如果按平臺類型來分，大家可能已經知道Google App Engine屬于PaaS（平臺即服務），而Amazon EC2屬于IaaS（基礎設施即服務），Amazon EC2給你一個安裝了操作系統的“盒子”，你可以自己安裝應用程序，也可以使用AMI（Amazon Machine Image），如果你想構建一個高度復雜的定制應用，Amazon EC2是不二之選，它允許你控制環境參數，底層操作系統，存儲和網絡需求，從技術上講，它屬于很底層的服務，你可以調整你需要的大部分東西。

Google App Engine給你一個完整的平臺，包括完整的SDK（以及Eclipse插件）和服務，你可以構建和部署你自己的應用程序，但你不能很好地控制操作系統， 硬件和存儲，諸如寫文件系統，使用線程等操作都有限制，這樣設計的目的是為了確保平臺不會被某個應用程序綁架。

簡單起來就是：

IaaS：原始硬件（處理器，網絡和存儲）

PaaS：操作系統，系統軟件，開發框架和虛擬機。

下面從技術角度來比較一下這兩個平臺。

1、提供的服務

Google App Engine憑借豐富的服務擊敗Amazon EC2，Google App Engine提供的服務可以讓開發人員快速進入開發狀態。如 Blobstore，Images，Mail，Memcache，Multitenancy，Oauth，Task Queues，URL Fetch，Users，XMPP這些服務在Amazon EC2上是需要自己安裝的，為了便于比較，假設你已經為Memcache，Mail和多租戶搭建好了基礎設施，看看在EC2上你用了多長時間安裝，我敢打 賭你會超過一個小時，使用Google App Engine時，這些服務都是現成的，就象果盤中插好牙簽的水果一樣，你可以隨時享用。

2、管理

Google App Engine再次勝出，因為一旦你的應用程序部署成功后，它幾乎不需要管理，當你的應用程序負載變大時，你不需要向服務注入新的實例，Google App Engine可以自由擴大負載能力，新實例是實時剝離的。使用Amazon EC2時，你必須時刻跟蹤通信流量（現在可以通過腳本自動跟蹤了），新實例是在你的配置基礎上剝離的，因此，如果我的峰值負載是2x+y，那么需要剝離2 個以上的應用程序服務器。

此外，使用Google App Engine升級應用程序服務器實例，安裝新的負載均衡器時，沒有管理開銷，這一切都是自動執行的。

3、抽象水平

和上一條聯系緊密的是抽象水平，Google App Engine抽象得比較好，你只需要關心你的應用程序和業務邏輯，不用擔心底層基礎設施的管理，正如Nick Johnson所說的那樣，抽象水平應作為挑選云計算平臺的一個基本原則，你需要做的是駕駛，不需要研究引擎蓋以下的東西。在我看來，如果你的核心業務是 貨物運輸，那么你應該買一輛卡車，它能高效地把你的貨物從A地運輸到B地，相反，你不應該考慮如何購買零部件自己組裝一輛卡車。

在軟件開發領域，我們看到有Grails，RoR等框架，它們大受歡迎，是因為它們提供了高水平的抽象，如果你是一名泥瓦匠，它們就象是腳手架，你可以踩在它們上面干你的工作。

4、可靠性

從我個人的認識來講，兩者都很可靠，這一點從它們的用戶數量就可以知道一二，用戶可以時刻查看Google App Engine的狀態，它是透明的，但從歷史數據來看，Amazon EC2的正常運行時間比Google App Engine要好。

5、可移植性

從使用的底層操作系統和開發框架來看，Amazon EC2具有更好的可移植性，但也不要擔心你會被Google App Engine給鎖住，Google已經給出了遷移指南，指導你如何從轉移出Google App Engine平臺，當然包含你所有的數據在內。還有AppScale這樣的程序可以幫助你將Google App Engine上的程序轉移到Amazom EC2或其它云平臺上，AppScale已經可以支持EC2，Eucalyptus，Xen和KVM。

6、存儲

Google App Engine目前嚴重依賴于BigTable，開發人員需要從一個完全不同的角度來認識和學習它，特別是對于那些特熟悉關系數據庫，被關系數據庫理論束縛 的人更需要洗洗腦，它提供了一個JPA&JDO訪問接口，但它不支持所有的JPA&JDO功能，特別是關系部分，Google最近也高調 宣布要讓Google App Engine支持傳統的SQL數據庫。Amazon EC2已經支持SQL數據庫，你可以使用Oracle，MySQL等你所熟悉的關系數據庫。

7、應用程序維護和升級

對Google App Engine來說，應用程序維護和升級是件輕而易舉的事，它為各種應用程序提供了一個詳細的管理面板，包括日志查看器和數據查看器，一個程序可以有多個版 本，當新版本經過測試，可以用于生產環境時，你可以將其設為默認的版本，而Amazon EC2就麻煩多了，因為它屬于IaaS類型，所有維護和升級相關的事情你必須親力親為。

8、開發限制

使用Google App Engine時，你必須受到平臺的限制，如果你的查詢處于僵死狀態，很難將其殺掉，此外，Google App Engine沒有線程，提供的SDK也是受限的，有些類和功能被列入黑名單，因此不能被使用，也不能寫文件系統等等。

從表面上看這些限制是不可理喻的，但如果有朝一日你也要提供PaaS類型的平臺時，你就能理解為什么Google要做這些限制了，這樣才能確保運行 在平臺上的應用程序不會違反平臺的規則，否則平臺就可能被應用程序綁架，從而變得不可使用，平臺上的其它應用程序就會收到牽連。

即便有這些限制，90%的商業應用程序仍然可以在Google App Engine上正常運行，但對于那些要使用線程，或寫文件系統的應用，最好還是選擇Amazon EC2，因為它提供了所有底層訪問和控制權。

9、語言支持

截至目前，Google App Engine支持Java和Python，但任何可以轉換成字節碼，可在JVM上執行的任何編程語言都可以在Google App Engine上運行，如果你喜歡其它編程語言，最好選擇Amazon EC2，因為你可以在它的操作系統上面安裝語言運行時環境，你擁有幾乎完整的硬件和操作系統控制權，還有什么不能做的呢？在Amazon EC2上也托管了許多有趣的C#，.NET，ASP.NET MVC/Visual Studio項目，具有諷刺意味著的是，盡管還有Microsoft Azure，但許多以MS技術開發的項目卻托管在Amazon EC2上。

概括地說，Amazon EC2是進入云計算的早期嘗試者，它利用互聯網標準和開放平臺創建了一個非常靈活的云計算平臺，Google則利用了它在大型數據庫方面的研究成果和它內 部實現的一些技術創建了一個強大，但有更多限制的云計算環境。從核心技術來講，Amazon EC2允許你擴展任何計算機實例到多個實例，因此你擁有每個虛擬盒子的完全控制權，Google App Engine從操作系統抽象而來，沒有計算機實例的概念，如果你的Web應用程序不需要操作系統相關的功能，那么Google App Engine無疑是最好的選擇，如果需要更好地控制你的系統環境，特別是操作系統相關的控制，那么最好選擇Amazon EC2。

原文名：Comparing Google App Engine and Amazon EC2 on Technology 作者：Vikas Hazrati

不出意料地，他得到了一大堆回答。

通常情況下，你需要把所有人的發言從頭到尾讀一遍。但是，Stack Overflow有一個很貼心的設計，它允許在問題下方開設一個wiki區，讓所有人共同編輯一個最佳答案。于是，就有了下面這篇文章，一共總結出六個方面共計61條"網站開發須知"。

我發現，這種概述性的問題，最適合這種集合群智、頭腦風暴式的回答方式了。這也是我第一次覺得，Stack Overflow做到了Wikipedia做不到的事。（難怪它最近擠進了全美前400大網站。）

在我的印象中，關于網站開發，這樣全面的概述性文章非常少見，因此也就非常有用。大家不妨看看，61件事情中你做到了多少？

（更新：剛剛發現，一共應該是62條建議，我先前數錯了，這個......太窘了。）

=============================

網站開發人員應該知道的61件事

原文網址：http://stackoverflow.com/questions/72394

譯者：阮一峰

一、界面和用戶體驗（Interface and User Experience）

1.1

知道各大瀏覽器執行Web標準的情況，保證你的站點在主要瀏覽器上都能正常運行。你至少要測試以下引擎：Gecko（用于Firefox）、Webkit（用于Safari、Chrome和一些手機瀏覽器）、IE（你可以利用微軟發布的Application Compatibility VPC Images進行測試）和Opera。同時，不同的操作系統，可能也會影響瀏覽器如何呈現你的網站。

1.2

除了瀏覽器，網站還有其他使用方式：手機、屏幕朗讀器、搜索引擎等等。你應該知道在這些情況下，你的網站的運行狀況。MobiForge提供了手機網站開發的一些相關知識。

1.3

知道如何在基本不影響用戶使用的情況下升級網站。通常來說，你必須有版本控制系統（CVS、Subversion、Git等等）和數據備份機制（backup）。

1.4

不要讓用戶看到那些不友好的出錯提示。

1.5

不要直接顯示用戶的Email地址，至少不要用純文本顯示。

1.6

為你的網站設置一些合理的使用限制，一旦超過門檻值，就自動停止服務。（這也與網站安全相關。）

1.7

知道如何實現網頁的漸進式增強（progressive enhancement）。

1.8

用戶發出POST請求后，總是將其重導向（redirect）至另外一個網頁。

1.9

不要忘記網站的可訪問性（accessibility，即殘疾人如何使用網站）。對于美國網站來說，有時這是法定要求。WAI-ARIA有一些這方面很好的參考資料。

二、安全性（Security）

2.1

閱讀《OWASP開發指南》，它提供了全面的網站安全指導。

2.2

了解SQL注入（SQL injection）及其預防方法。

2.3

永遠不要信任用戶提交的數據（cookie也是用戶端提交的！）。

2.4

不要明文（plain-text）儲存用戶的密碼，要hash處理后再儲存。

2.5

不要對你的用戶認證系統太自信，它可能很容易就被攻破，而你事先根本沒意識到存在相關漏洞。

2.6

了解如何處理信用卡。

2.7

在登錄頁面及其他處理敏感信息的頁面，使用SSL/HTTPS。

2.8

知道如何對付session劫持（session hijacking）。

2.9

避免"跨站點執行"（cross site scripting，XSS）。

2.10

避免"跨域偽造請求"（cross site request forgeries，XSRF）。

2.11

及時打上補丁，讓你的系統始終跟上最新版本。

2.12

確認你的數據庫連接信息的安全性。

2.13

跟蹤攻擊技術的最新發展，以及你使用的平臺的最新安全漏洞。

2.14

閱讀Google的《瀏覽器安全手冊》（Browser Security Handbook）。

2.15

閱讀《網絡軟件的黑客手冊》（The Web Application Hackers Handbook）。

三、性能（Performance）

3.1

只要有可能，就使用緩存（caching）。正確理解和使用HTTP caching與HTML5離線儲存。

3.2

優化圖片。不要把一個20KB的圖片文件，作為重復出現的網頁背景圖案。

3.3

學習如何用gzip/deflate壓縮內容（deflate方式更可取）。

3.4

將多個樣式表文件或腳本文件，合為一個文件，這樣可以減少瀏覽器的http請求數，以及減小gzip壓縮后的文件總體積。

3.5

瀏覽Yahoo的Exceptional Performance網站，里面有大量提升前端性能的優秀建議，還有他們的YSlow工具。Google的page speed則是另一個用來分析網頁性能的工具。兩者都要求安裝Firebug。

3.6

如果你的網頁用到大量的小體積圖片（比如工具欄），就應該使用CSS Image Sprite，目的是減少http請求數。

3.7

大流量的網站應該考慮將網頁對象分散在多個域名（split components across domains）。

3.8

靜態內容（比如圖片、CSS、JavaScript、以及其他cookie無關的網頁內容）都應該放在一個不需要使用cookie的獨立域名之上。因為域名之下如果有cookie，那么客戶端向該域名發出的每次http請求，都會附上cookie內容。這里的一個好方法就是使用"內容分發網絡"（Content Delivery Network，CDN）。

3.9

將瀏覽器完成網頁渲染所需要的http請求數最小化。

3.10

使用Google的Closure Compiler壓縮JavaScript文件，YUI Compressor亦可。

3.11

確保網站根目錄下有favicon.ico文件，因為即使網頁中根本不包括這個文件，瀏覽器也會自動發出對它的請求。所以如果這個文件不存在，就會產生大量的404錯誤，消耗光你的服務器的帶寬。

四、搜索引擎優化（Search Engine Optimization，SEO）

4.1

使用"搜索引擎友好"的URL形式，比如example.com/pages/45-article-title，而不是example.com/index.php?page=45。

4.2

不要使用"點擊這里"之類的超級鏈接，因為這樣等于浪費了一個SEO機會，而且降低了"屏幕朗讀器"（screen reader）的使用效果。

4.3

創建一個XML sitemap文件，它的缺省位置一般是/sitemap.xml（即放在網站根目錄下）。

4.4

當你有多個URL指向同一個內容時，在網頁代碼中使用<link rel="canonical" ... />。

4.5

使用Google的Webmaster Tools和Yahoo的Site Explorer。

4.6

從一開始就使用Google Analytics（或者開源的訪問量分析工具Piwik）。

4.7

知道robots.txt的作用，以及搜索引擎蜘蛛的工作原理。

4.8

將www.example.com的訪問請求導向example.com（使用301 Moved Permanently重定向），或者采用相反的做法，目的是防止Google把它們當做兩個網站，分開計算排名。

4.9

知道存在著惡意或行為不正當的網絡蜘蛛。

4.10

如果你的網站有非文本的內容（比如視頻、音頻等等），你應該參考Google的sitemap擴展協議。

五、技術（Technology）

5.1

理解HTTP協議，以及諸如GET、POST、sessions、cookies之類的概念，包括"無狀態"（stateless）是什么意思。

5.2

確保你的XHTML/HTML和CSS符合W3C標準，使得它們能夠通過檢驗。這可以使你的網頁避免觸發瀏覽器的古怪行為（quirk），而且使它在"屏幕朗讀器"和手機上也能正常工作。

5.3

理解瀏覽器如何處理JavaScript腳本。

5.4

理解網頁上的JavaScript文件、樣式表文件和其他資源是如何裝載及運行的，考慮它們對頁面性能有何影響。在某些情況下，可能應該將腳本文件放置在網頁的尾部。

5.5

理解JavaScript沙箱（Javascript sandbox）的工作原理，尤其是如果你打算使用iframe。

5.6

知道JavaScript可能無法使用或被禁用，以及Ajax并不是一定會運行。記住，"不允許腳本運行"（NoScript）正在某些用戶中變得流行，手機瀏覽器對腳本的支持千差萬別，而Google索引網頁時不運行大部分的腳本文件。

5.7

了解301重定向和302重定向之間的區別（這也是一個SEO相關問題）。

5.8

盡可能多得了解你的部署平臺（deployment platform）。

5.9

考慮使用樣式表重置（Reset Style Sheet）。

5.10

考慮使用JavaScript框架（比如jQuery、MooTools、Prototype），它們可以使你不用考慮瀏覽器之間的差異。

六、解決bug

6.1

理解程序員20%的時間用于編碼，80%的時間用于維護，根據這一點相應安排時間。

6.2

建立一個有效的錯誤報告機制。

6.3

建立某些途徑或系統，讓用戶可以與你接觸，向你提出建議和批評。

6.4

為將來的維護和客服人員撰寫文檔，解釋清楚系統是怎么運行的。

6.5

經常備份！（并且確保這些備份是有效的。）除了備份機制，你還必須有一個恢復機制。

6.6

使用某種版本控制系統儲存你的文件，比如Subversion或Git。

6.7

不要忘記做單元測試（Unit Testing），Selenium之類的框架會對你有用。

（完）

轉自：http://www.ruanyifeng.com/blog/2010/11/61_things_every_web_developer_should_know.html

簡介： 開源 memcached 工具是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁盤或數據庫，加載（并處理）信息了。該工具可部署在專用的情況下，也可作為用完 現有環境內的多余內存的一種方法。盡管 memcached 十分簡便，但有時它仍被不當使用，或被用在錯誤的環境類型中。在本文中，了解使用 memcached 的最佳時機。

簡介

memcached 常被用來加速應用程序的處理，在這里，我們將著重于介紹將它部署于應用程序和環境中的最佳實踐。這包括應該存儲或不應存儲哪些、如何處理數據的靈活分布以 及如何調節用來更新 memcached 和所存儲數據的方法。我們還將介紹對高可用性的解決方案的支持，比如 IBM WebSphere® eXtreme Scale。

所有的應用程序，特別是很多 web 應用程序都需要優化它們訪問客戶機和將信息返回至客戶機的速度。可是，通常，返回的都是相同的信息。從數據源（數據庫或文件系統）加載數據十分低效，若是每次想要訪問該信息時都運行相同的查詢，就尤顯低效。

雖然很多 web 服務器都可被配置成使用緩存發回信息，但那與大多數應用程序的動態特性無法相適。而這正是 memcached 的用武之地。它提供了一個通用的內存存儲器，可保存任何東西，包括本地語言的對象，這就讓您可以存儲各種各樣的信息并可以從諸多的應用程序和環境訪問這些信息。

基礎知識

memcached 是一個開源項目，旨在利用多個服務器內的多余 RAM 來充當一個可存放經常被訪問信息的內存緩存。這里的關鍵是使用了術語緩存：memcached 為加載自他處的信息提供的是內存中的暫時存儲。

比如，考慮這樣一個典型的基于 web 的應用程序。即便是一個動態網站可能也會有一些組件或信息常量是貫穿頁面整個生命周期的。在一個博客站點內，針對單個 blog post 的類別列表不大可能在頁面查看間經常性地變更。每次都通過一個對數據庫的查詢加載此信息相對比較昂貴，特別是在數據沒有更改的情況下，就更是如此。從圖 1 可以看到一個博客站點內可被緩存的頁面分區。

圖 1. 一個典型的博客頁面內的可緩存元素

將這種結構放在 blog 站點的其他元素，poster 信息、注釋 — 設置 blog post 本身 — 進行推斷，可以看出為了顯示主頁的內容很可能需要發生 10-20 次數據庫查詢和格式化。 每天對數百甚至數千的的頁面查看重復此過程，那么您的服務器和應用程序執行的查詢要遠遠多于為了顯示頁面內容所需執行的查詢。

通過使用 memcached，可以將加載自數據庫的格式化信息存儲為一種可直接用在 Web 頁面上的格式。并且由于信息是從 RAM 而不是通過數據庫和其他處理從磁盤加載的，所以對信息的訪問幾乎是瞬時的。

再強調一下，memcached 是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁盤或數據庫，加載并處理信息了。

對 memcached 的接口是通過網絡連接提供的。這意味著您可以在多個客戶機間共享單個的 memcached 服務器（或多個服務器，如本文稍后所示的）。這個網絡接口非常迅速，并且為了改善性能，服務器會故意不支持身份驗證或安全性通信。但這不應限制部署選項。 memcached 服務器應該存在于您網絡的內部。網絡接口的實用性以及可以部署多個 memcached 實例的簡便性讓您可以使用多個機器上的多余 RAM 來提高您緩存的整體大小。

memcached 的存儲方法是一個簡單的鍵/值對，類似于很多語言內的散列或關聯數組。通過提供鍵和值來將信息存儲到 memcached 內，通過按特定的鍵請求信息來恢復信息。

信息會無限期地保留在緩存內，除非發生如下的情況：

1. 為緩存分配的內存耗盡 — 在這種情況下，memcached 使用 LRU（最近最少使用）方法從此緩存刪除條目。最近未曾使用的條目會從此緩存中先刪除，最舊的最先訪問。
2. 條目被明確刪除 — 總是可以從此緩存內刪除條目。
3. 條目過期失效 — 各條目均有一個有效的期限以便針對此鍵存儲的信息在過于陳舊時可從緩存中清除這些條目。

上述這些情況可以與您應用程序的邏輯綜合使用以便確保緩存內的信息是最新的。有了這些基礎知識后，讓我們來看看在應用程序內如何能最好地利用 memcached。

何時使用 memcached

在使用 memcached 改進應用程序性能時，可以對一些關鍵的過程和步驟進行修改。

在加載信息時，典型的場景如圖 2 所示。

圖 2. 加載要顯示的信息的典型順序

一般而言，這些步驟是：

1. 執行一個或多個查詢來從數據庫加載信息
2. 格式化適合于顯示（或進一步處理）的信息
3. 使用或顯示格式化了的數據

在使用 memcached 時，為配合這個緩存，可對應用程序的邏輯進行稍許修改：

• 盡量從緩存加載信息
• 如果存在，使用信息的被緩存版本
• 如果它不存在：
  1. 執行一個或多個查詢來從數據庫加載信息
  2. 格式化適合于顯示或進一步處理的信息
  3. 將信息存儲到緩存內
  4. 使用格式化了的數據

圖 3 是對這些步驟的總結。

圖 3. 在使用 memcached 時加載適合于顯示的信息

數據加載成為了至多三個步驟的一個過程，從緩存加載數據或從數據庫（視情況而定）加載數據并存儲在緩存內。

當這個過程首次發生時，數據將正常地從數據庫或其他數據源加載，然后再存儲到 memcached 內。當下一次訪問此信息時，它就會從 memcached 拉出，而不是從數據庫加載，節省了時間和 CPU 循環。

問題的另一個方面是要確保如果更改了要存儲在 memcached 內的信息，在更新后端信息的同時還要更新 memcached 的版本。這會讓圖 4 內所示的這個典型順序發生稍許變化，如 圖 5 所示。

圖 4. 在一個典型的應用程序內更新或存儲數據

圖 5 顯示了使用 memcached 后發生了變化的流程。

圖 5. 在使用 memcached 時更新或存儲數據

比如，仍以博客站點為例，在博客系統更新數據庫內的類別列表時，更新應該遵循如下順序：

1. 更新數據庫內的類別列表
2. 格式化信息
3. 將信息存儲到 memcached 內
4. 將信息返回至客戶機

memcached 內的存儲操作是原子的，所以信息的更新不會讓客戶機只獲得部分數據；它們獲得的或者是老版本，或者是新版本。

對于大多數應用程序，這兩個操作是您惟一需要注意的。在訪問他人使用的數據時，它會自動被添加到這個緩存內，而且如果對該數據進行了更改，此緩存內也會自動進行更新。

鍵、名稱空間和值

memcached 另一個需要重點考慮的因素是如何組織和命名存儲在緩存內的這些數據。從之前博客站點的例子中，不難看出需要使用一種一致的命名結構以便您能加載博客類別、歷史和其他信息，然后再在加載信息（并更新緩存）時或者在更新數據（同樣也要更新緩存）時使用。

使用的何種具體的命名系統特定于應用程序，但通常可以使用一種與現有應用程序類似的結構，并且這種結構很可能基于某種惟一識別符。當從數據庫拉出信息或在整理信息集時，就會發生這種情況。

以 blog post 為例，可以在一個具有鍵 category-list 的項中存儲類別列表。與此 post ID 對應的單個 post，比如 blogpost-29 相關的值都可以使用，而該項的注釋則可以存儲在 blogcomments-29 內，其中 29 就是這個 blog post 的 ID。這樣一來， 您就可以將各種各樣的信息存儲在緩存內，使用不同的前綴來標識這些信息。

memcached 鍵/值存儲的簡便性（以及安全性的缺乏）意味著如果您想要在使用同一個 memcached 服務器的同時支持多個應用程序，那么就可以考慮使用其他格式的量詞來標識數據屬于某種特定的應用程序。比如，可以添加像 blogapp:blogpost-29 這樣的應用程序前綴。這些鍵是沒有格式的，所以可以使用任何字符串作為鍵的名稱。

在存儲值的方面，應該確保存儲在緩存內的信息適合于您的應用程序。比如，對于這個博客系統，您可能想要存儲被博客應用程序使用的對象以便格式化博客信息，而不是原始的 HTML。如果同一個基礎結構用在應用程序內的多個地方，這一點更具實用性。

大多數語言的接口，包括 Java™、Perl、PHP 等，都能串行化語言對象以便存儲在 memcached 內。這就讓您可以存儲并隨后從內存存儲恢復全部對象，而不是在您的應用程序內手動重構它們。 很多對象，或它們使用的結構，都基于某種散列或數組結構。對于跨語言的環境，比如在 JSP 環境和 JavaScript 環境間共享相同信息，可以使用一種架構中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。

填充并使用 memcached

作為一種開源產品以及一種最初開發用來工作于現有開源環境內的產品，memcached 受大量環境和平臺支持。與 memcached 服務器通信的接口有很多，并常常具有針對所有語言的多個實現。參見 參考資料 以獲得常用的庫和工具箱。

要列出所有受支持的接口和環境不太可能，但它們均支持 memcached 協議提供的基礎 API。這些描述已經被簡化并應用在不同語言的上下文內，在這些語言中，使用不同的值可指示錯誤。主要的函數有：

• get(key) — 從存儲了特定鍵的 memcached 獲得信息。 如果鍵不存在，就返回錯誤。
• set(key, value [, expiry]) — 使用緩存內的標識符鍵存儲這個特定的值。如果鍵已經存在，那么它就會被更新。期滿時間的單位為秒，并且如果值小于 30 天 (30*24*60*60)，那么就用作相對時間，如果值大于 30 天，那么就用作絕對時間 (epoch)。
• add(key, value [, expiry]) — 如果鍵不存在就將這個鍵添加到緩存內，如果鍵已經存在就返回錯誤。如果您想要顯式地添加一個新鍵而又不會因它已經存在而更新它，那么這個函數將十分有用。
• replace(key, value [, expiry]) — 更新此特定鍵的值，如果鍵不存在就返回一個錯誤。
• delete(key [, time]) — 從緩存中刪除此鍵/值對。如果您提供一個時間，那么添加具有此鍵的一個新值就會被阻塞這個特定的時期。超時讓您可以確保此值總是可以重新讀取自您的數據中心。
• incr(key [, value]) — 為特定的鍵增 1 或特定的值。只適用于數值。
• decr(key [, value]) — 為特定的鍵減 1 或特定的值，只適用于數值。
• flush_all — 讓緩存內的所有當前條目無效（或到期失效）。

比如，在 Perl 內，基本 set 操作可以如清單 1 所示的那樣處理。

清單 1. Perl 內的基本 set 操作

				
use Cache::Memcached;

my $cache = new Cache::Memcached {
    'servers' => [
                   'localhost:11211',
                   ],
    };

$cache->set('mykey', 'myvalue');

Ruby 內的相同的基本操作如清單 2 所示。

清單 2. Ruby 內的基本 set 操作

				
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'

memc["mykey"] = "myvalue"

在兩個例子中可以看到相同的基本結構：設置 memcached 服務器，然后分配或設置值。其他的接口也可用，包括適合于 Java 技術的那些接口，讓您可以在 WebSphere 應用程序內使用 memcached。memcached 接口類允許將 Java 對象直接序列化到 memcached 以便于存儲和加載復雜的結構。當在像 WebSphere 這樣的環境內進行部署時，有兩個事情非常重要：服務的彈性（在 memcached 不可用時如何做）以及如何提高緩存存儲量來改進在使用多個應用程序服務器或在使用像 WebSphere eXtreme Scale 這樣的環境時的性能。我們接下來就來看看這兩個問題。

彈性和可用性

有關 memcached 最常見的一個問題是：“若緩存不可用了，會發生什么情況呢？”正如之前章節中明示的，緩存內的信息不應該成為信息的的惟一資源。必須要能夠從其他位置加載存儲在緩存內的數據。

雖然，無法從緩存訪問信息將會減緩應用程序的性能，但它不應該阻止應用程序的運轉。可能會發生這樣幾個場景：

1. 如果 memcached 服務宕掉，應用程序應該回退到從原始數據源加載信息并對信息進行顯示所需的格式化。此應用程序還應繼續嘗試在 memcached 內加載和存儲信息。
2. 一旦 memcached 服務器恢復可用，應用程序就應該自動嘗試存儲數據。沒有必要強制重載已緩存了的數據，可以使用標準的訪問來用信息加載和填充緩存。最終，緩存將會被最常用的數據重新填充。

再次重申，memcached 是信息的緩存但并非惟一的數據源。memcached 服務器不可用不應該是應用程序的終結，雖然這意味著在 memcached 服務器恢復正常之前性能會有所降低。實際上，memcached 服務器相對簡單，并且雖然不是絕對無故障的，但它的簡單性的結果就是它很少會出錯。

分配緩存

memcached 服務器只是網絡上針對一些鍵存儲值的一個緩存。如果有多臺機器，那么很自然地會想要在所有多余機器上設置一個 memcached 的實例來提供一個超大的聯網 RAM 緩存存儲。

有了這個想法后，還有一種想當然是需要使用某種分配或復制機制來在機器之間復制鍵/值對。這種方式的問題是如果這么做反而會減少可用的 RAM 緩存，而不是增加。如圖 6 所示，可以看出這里有三個應用程序服務器，每個服務器都可以訪問一個 memcached 實例。

圖 6. 多重 memcached 實例的不正確使用

盡管每個 memcached 實例都是 1 GB 的大小（產生 3 GB 的 RAM 緩存），但如果每個應用程序服務器只有其自己的緩存（或者在 memcached 之間存在著數據的復制），那么整個安裝也仍只能有 1 GB 的緩存在每個實例間復制。

由于 memcached 通過一個網絡接口提供信息，因此單個的客戶機可以從它所能訪問的任何一個 memcached 實例訪問數據。如果數據沒有跨每個實例被復制，那么最終在每個應用程序服務器上，就可以有 3 GB 的 RAM 緩存可用，如圖 7 所示。

圖 7. 多重 memcached 實例的正確使用

這個方法的問題是選擇哪個服務器來儲存鍵/值對，以及當想要重新獲得一個值時，如何決定要與哪個 memcached 服務器對話。問題的解決方案就是忽略復雜的東西，比如查找表，或是寄望 memcached 服務器來為您處理這個過程。而 memcached 客戶機則必須要力求簡單。

memcached 客戶機不必決定此信息，它只需對在存儲信息時指定的鍵使用一個簡單的散列算法。當想要從一列 memcached 服務器存儲或獲取信息時，memcached 客戶機就會用一個一致的散列算法從這個鍵獲取一個數值。舉個例子，鍵 mykey 被轉換成數值 23875 。是保存還是獲取信息無關緊要，這個鍵將總是被用作惟一標識符來從 memcached 服務器加載，因此在本例中，“mykey” 散列轉化后對應的值總是 23875。

如果有兩個服務器，那么 memcached 客戶機將對這個數值進行一個簡單的運算（例如，系數）來決定它應將此值存儲在第一個還是第二個配置了的 memcached 實例上。

當存儲一個值時，客戶機會從這個鍵確定出散列值以及它原來存儲在哪個服務器上。當獲取一個值時，客戶機會從這個鍵確定出相同的散列值并會選擇相同的服務器來獲取信息。

如果在每個應用程序服務器上使用的是相同的服務器列表（并且順序相同），那么當需要保存或檢索同一個鍵時，每個應用程序服務器都將選擇同一個 服務器。現在，在這個例子中，有 3GB 的 memcached 空間可以共享，而不是同一個 1 GB 的空間的復制，這就帶來了更多的可用緩存，并很有可能會提高有多個用戶情況下的應用程序的性能。

這個過程也有其復雜性（比如當一個服務器不可用時會怎樣），更多信息，請參見相關文檔（參見 參考資料）。

如何能不使用 memcached

盡管 memcached 很簡單，但 memcached 實例有時候還是會被不正確地使用。

memcached 不是一個數據庫

最常見的 memcached 誤用就是把它用作一個數據存儲，而不是一個緩存。memcached 的首要目的就是加快數據的響應時間，否則數據從其他數據源構建或恢復需要很長時間。一個典型的例子就是從一個數據庫中恢復信息，特別是在信息顯示給用戶前 需要對信息進行格式化或處理的時候。Memcached 被設計用來將信息存儲在內存中以避免每次在數據需要恢復時重復執行相同的任務。

切不可將 memcached 用作運行應用程序所需信息的惟一信息源；數據應總是可以從其他信息源獲取。此外，要記住 memcached 只是一個鍵/值的存儲。不能在數據上執行查詢，或者對內容進行迭代來提取信息。應該使用它來存儲數據塊或對象以備批量使用。

不要緩存數據庫行或文件

雖然可以使用 memcached 存儲加載自數據庫的數據行，但這實際上是查詢緩存，并且大多數數據庫都提供各自的查詢緩存的機制。其他的對象，比如文件系統的圖像或文件的情況與此相同。很多應用程序和 web 服務器針對此類工作已經有了一些很好的解決方案。

如果在加載和格式化后，使用它來存儲全部信息塊，就可以從 memcached 獲得更多的實用工具和性能上的改善。仍以我們的博客站點為例，存儲信息的最佳點是在將博客類別格式化為對象，甚至是在格式化成 HTML 后。博客頁面的構造可通過從 memcached 加載各個組件（比如 blog post、category list、post history 等）并將完成的 HTML 寫回至客戶機實現。

memcached 并不安全

為了確保最佳性能，memcached 并未提供任何形式的安全性，沒有身份驗證，也沒有加密。這意味著對 memcached 服務器的訪問應該這么處理：一是通過將它們放到應用程序部署環境相同的私有側，二是如果安全性是必須的，那么就使用 UNIX® socket 并只允許當前主機上的應用程序訪問此 memcached 服務器。

這多少犧牲了一些靈活性和彈性，以及跨網絡上的多臺機器共享 RAM 緩存的能力，但這是在目前的情況下確保 memcached 數據安全性的惟一一種解決方案。

不要限制自己

除了不應該使用 memcached 實例的情況外，memcached 的靈活性不應忽視。由于 memcached 與應用程序處于相同的架構水平，所以很容易集成并連接到它。并且更改應用程序以便利用 memcached 也并不復雜。此外，由于 memcached 只是一個緩存，所以在出現問題時它不會停止應用程序的執行。如果使用正確的話，它所做的是減輕其余服務器基礎設施的負載（減少對數據庫和數據源的讀操 作），這意味著無需更多的硬件就可以支持更多的客戶機。

但請記住，它僅僅是個緩存！

結束語

在本文中，我們了解了 memcached 以及如何最佳地使用它。我們看到了信息如何存儲、如何選擇合理的鍵以及如何選擇要存儲的信息。我們還討論了所有 memcached 用戶都要遇到的一些關鍵的部署問題，包括多服務器的使用、當 memcached 實例消亡時該怎么做，以及（也許最為重要的）在哪些情況下不能使用 memcached。

作為一種開源的應用程序并且是目的簡單而直白的應用程序，memcached 的功能和實用性均來自于這種簡單性。通過為信息提供巨大的 RAM 存儲空間、讓它在網絡上可用，然后再讓它可通過各種不同的接口和語言訪問到，memcached 可被集成到多種多樣的安裝和環境中。

參考資料

學習

• MySQL memcached 文檔 提供了很多有關如何在一個典型的數據庫部署環境內使用 memcached 的信息。
• 通過體驗 IBM solidDB 產品家族，了解 IBM 的商業緩存解決方案 solidDB®。
• 隨時關注 developerWorks 技術活動和網絡廣播。
• 查閱最近將在全球舉辦的面向 IBM 開放源碼開發人員的研討會、交易展覽、網絡廣播和其他 活動。
• 訪問 developerWorks Open source 專區獲得豐富的 how-to 信息、工具和項目更新以及最受歡迎的文章和教程，幫助您用開放源碼技術進行開發，并將它們與 IBM 產品結合使用。
• 查看免費的 developerWorks On demand 演示，觀看并了解 IBM 及開源技術和產品功能。
  
  

獲得產品和技術

• memcached.org 提供了有關 memcached 以及如何下載并安裝它的信息。
• Cache::Memcached interface for Perl 提供了一個廣泛的接口。
• 對于 Java 技術，可使用 com.danga.MemCached 類，它會提供一些額外的故障轉換及多實例擴展。
• 使用 IBM 產品評估試用版軟件 改進您的下一個開發項目，這些軟件可以通過下載獲得。
• 下載 IBM 產品評估試用版軟件 或 IBM SOA Sandbox for People，并開始使用來自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的應用程序開發工具和中間件產品。

討論

• 參與 developerWorks 博客 加入 developerWorks 社區。
• 歡迎加入 My developerWorks 中文社區。
  
  

關于作者

“比心情更好的是你的選擇！”這條掛在“天驕北麓”售樓部房頂上的廣告詞極其充滿誘惑，與之形成鮮明反差的是上百準業主半月來的維權，比其心情更糟的是“天驕北麓”背后“那點房事”。12月18日，位于紅云路上的“天驕北麓”在準業主們的不滿和遭遇雞糞灑門中迎來了開盤。

這 場被媒體和市民高度關注的房事，其實是一場赤裸裸的利益紛爭，以及一個企業在市場經濟下，面對市場風險如何做到誠實守信？對于準業主們來說，需要思考的是 在市場經濟下，如何用法律來保障自己的權益。市場經濟就是法治經濟，道德、誠信這些沒有落在紙上具有法律約束力的字眼，在利益面前顯得蒼白無力。

為防不測，防暴警察也來到現場

昨天上午，“天驕北麓”迎來開盤。由于上百準業主的不滿和抗議，讓這次開盤顯得格外謹慎和受到外界廣泛關注。數十警察趕到現場維持秩序，為了防止不測，防暴警察也來到現場。

中 午12點39分左右，準房主們把早已準備好的兩箱雞糞灑在了售樓部的門口。頓時，現場出現了一點騷亂，在旁邊維持秩序的警察開始前去阻攔。就在這時，一礦 泉水瓶砸向售樓部大門，站在門口的一名保安拿著警棍朝著準業主們指了指，幾個情緒激動的準業主向保安沖去，被維持秩序的警察攔下，在其他保安的勸說下，該 名保安走進了售樓部。

56歲的代阿姨，是這次“天驕北麓”團購房的一名準業主，交了20萬元。維權15天以來，代阿姨有著不少的委屈和不滿。為了換一套大一點的房子，代阿姨把原來的房子賣了，手里攥著60多萬元，本想把這60多萬投向“天驕北麓”，買大一點的房子，等待她的卻是一場紛爭。

“比心情更壞的是花言巧言設下的陷阱，一個沒有出口、巷道林立的購房迷宮。”代阿姨說。

說起購買“天驕北麓”的房子，患有高血壓的代阿姨苦不堪言，當她7月初從中介公司獲知4800元一平方米就可以購買天驕北麓的房子時，義無反顧地交了1.7萬元的轉讓金，并與這家中介公司簽下合約。7月10日選房時，她交了20萬元。

本以為可以圓一個住房夢的她，每天都在盼著房子開盤，日子就這么一天天過去，代阿姨也沒感到有什么煩惱。

當12月1日獲知她交了20萬元參與團購的“天驕北麓”價格比當初和中介公司簽下合約的房價高出一倍時，代阿姨蒙了。自12月4日起，代阿姨和上百團購者開始了維權。由于身體不好，上了年紀，每天的維權之路，代阿姨還是吃不消。

和代阿姨一樣的購房者還有來自四川的周女士。周女士交了6萬元的購房意向金，結果也陷入了這場紛爭。欲哭無淚的周女士昨天上午后悔不已，當初不該草率地賣了房子來購買“天驕北麓”。在這起購房中，還有她的10多個老鄉。

“開發商的一小步，維權者的一大步”

在這些準業主提供的協議中，記者沒有看到一份真正的購房合同，聽到和看到的只是團購、意向金，這些不明不白的詞語，讓人眼花繚亂。

在“天驕北麓”售樓部，一張由云南倫華房地產有限公司貼出的通告里稱，對未選中房子的購房客戶，公司愿意現金一次性補償，以中國人民銀行公布的現行兩年定期存款率3.25%為計算標準。

對于此，準業主霍先生把其稱為“開發商的一小步，維權者的一大步”。霍先生說，在各方壓力和他們準業主的努力下，開發商愿意為返還意向金支付利息，來之不易。

代阿姨說，她交了20萬元的意向金，可以得到6500多元的利息，對于她來說，這點利息已經對其沒有多少用處，因為這幾個月來，看著往上漲的房子，她付出去的更多，已經耽誤了她買房。

中午12點51分，準業主們開始從售樓部撤離，環衛工人開始打掃門口的雞糞。下午1點10分左右，“天驕北麓”恢復了暫時的安寧。掛在售樓部西邊“所有關于生活的夢想從這一刻開啟”的廣告詞，是否會因為一些準業主們的離開而開啟更多準業主們生活的夢想呢？

背景

“天驕北麓”團購風波

2009年11月，由云南倫華房地產有限公司開發的“天驕北麓”項目開始認購，打出的廣告上稱項目房源最低售價3660元/平米，均價4300元/平米，并承諾如正式開盤時提價，團購房源價格不變，上萬的團購者繳納了2至30萬元不等的意向金預訂房源。

2010年12月1日，“天驕北麓”項目公布了每套房源價格，均價上調。開發商稱所有房源按照公布價格出售，不想買房的，無息返還意向金。

當 準業主們獲知這個消息后，猶如五雷轟頂，當初不是說好了3660元到4300元嗎？怎么會有這么大的差距呢？一種不滿的情緒開始在準業主中蔓延。12月1 日，因開盤價格遠遠高于已經交了認購金的購房者的心理底線，這些準業主們一氣之下砸了售樓部的沙盤模型。12月4日、5日，準業主們聚集售樓部，用番茄雞 蛋來招呼開發商，表達對開發商行為的不滿。

記者秦聰俊（都市時報）

轉自：http://news.qq.com/a/20101219/001080.htm?qq=0&ADUIN=84588990&ADSESSION=1292750641&ADTAG=CLIENT.QQ.3073_.0

騰訊微博開放平臺API開放啦，使用騰訊微博開放平臺提供的API創建自己的應用，需要首先填寫個人資料，通過聯系郵箱驗證，獲取開發者資格，就能 創建自己的應用。騰訊微博開放平臺，是基于騰訊微博系統，為廣大開發者和用戶提供的開放數據分享與傳播平臺。廣大開發者和用戶登錄平臺后，就可以使用平臺 提供的開放API接口，創建應用從微博系統獲取信息，或將新的信息傳播到整個微博系統中，豐富多樣的API接口和應用，加上你的智慧，將創造出無窮的應用和樂趣。

騰訊微博開放平臺，是基于騰訊微博系統，為廣大開發者和用戶提供的開放數據分享與傳播平臺。廣大開發者和用戶登錄平臺后，就可以使用平臺提供的開放 API接口，創建應用從微博系統獲取信息，或將新的信息傳播到整個微博系統中，豐富多樣的API接口和應用，加上你的智慧，將創造出無窮的應用和樂趣！

平臺介紹 — 在微博開放平臺能獲取到的資源及優勢

應用開發說明 — 說明如何成為一個開發者并創建應用

應用審核流程 — 審核應用的來源字段能獲得的好處，以及如何審核

開發者協議 — 在此查看騰訊微博開放平臺開發者服務協議

如何開發微博應用？（馬上成為開發者）

你只需要按照如下步驟操作：

第一步：填寫你的開發者信息；

第二步：聯系郵箱通過驗證；（電子郵箱將作為我們聯系你的重要方式，請提供常用郵箱地址）

第三步：填寫要創建的應用信息。

就能馬上獲取到微博App Key和App Secret，調用微博API，進行應用開發。 查看詳細說明

----

代表著中國最先進的互聯網技術的騰訊終于走出了開放的第一步 :-)

轉自：http://www.oschina.net/news/13863/tencent-open-micro-blogging-api

好久沒貼過代碼了，心血來潮。

/*
 * Copyright (c) 2009, 2010, B3log Team
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.b3log.latke.servlet.filter;

import java.io.IOException;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.util.logging.Level;
import java.util.logging.Logger;
import java.util.zip.GZIPOutputStream;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

/**
 * Abstract HTTP response GZIP filter.
 *
 * @author Liang Ding
 * @version 1.0.0.1, Dec 16, 2010
 */
public abstract class AbstractGZIPFilter implements Filter {

    /**
     * Logger.
     */
    private static final Logger LOGGER =
            Logger.getLogger(AbstractGZIPFilter.class.getName());

    @Override
    public void init(final FilterConfig cfg) throws ServletException {
    }

    /**
     * Wraps the http servlet response with GZIP if could.
     *
     * @param request the specified request
     * @param response the specified response
     * @param chain filter chain
     * @throws IOException io exception
     * @throws ServletException servlet exception
     */
    @Override
    public void doFilter(final ServletRequest request,
                         final ServletResponse response,
                         final FilterChain chain) throws IOException,
                                                         ServletException {
        final HttpServletRequest httpServletRequest =
                (HttpServletRequest) request;
        final String requestURI = httpServletRequest.getRequestURI();
        if (shouldSkip(requestURI)) {
            LOGGER.log(Level.FINEST, "Skip GZIP filter request[URI={0}]",
                       requestURI);
            chain.doFilter(request, response);

            return;
        }

        final String acceptEncoding =
                httpServletRequest.getHeader("Accept-Encoding");
        boolean supportGZIP = false;
        if (null != acceptEncoding
            && 0 <= acceptEncoding.indexOf("gzip")) {
            supportGZIP = true;
        }

        if (!supportGZIP) {
            LOGGER.info("Gzip NOT be supported");
            chain.doFilter(request, response);

            return;
        }

        final HttpServletResponse httpServletResponse =
                (HttpServletResponse) response;
        httpServletResponse.addHeader("Content-Encoding", "gzip");
        httpServletResponse.addHeader("Vary", "Accept-Encoding");
        chain.doFilter(request,
                       new GZIPServletResponseWrapper(httpServletResponse));
    }

    /**
     * Determines whether the specified request URI should be skipped filter.
     *
     * 

     *   Note: This method SHOULD be invoked for all filters with pattern
     *   "/*".
     * 
     *
     * @param requestURI the specified request URI
     * @return {@code true} if should be skipped, {@code false} otherwise
     */
    public abstract boolean shouldSkip(final String requestURI);

    @Override
    public void destroy() {
    }

    /**
     * HTTP response wrapper for GZIP.
     *
     * @author Liang Ding
     * @version 1.0.0.0, Dec 16, 2010
     */
    private class GZIPServletResponseWrapper extends HttpServletResponseWrapper {

        /**
         * GZIP output stream.
         */
        private GZIPOutputStream gzipStream;
        /**
         * Servlet output stream.
         */
        private ServletOutputStream servletOutputStream;
        /**
         * Print writer.
         */
        private PrintWriter printWriter;

        /**
         * Constructs an {@link GZIPServletResponseWrapper} object with the
         * specified http servlet response.
         *
         * @param httpServletResponse the specified http servlet response
         * @throws IOException io exception
         */
        GZIPServletResponseWrapper(final HttpServletResponse httpServletResponse)
                throws IOException {
            super(httpServletResponse);
        }

        @Override
        public ServletOutputStream getOutputStream() throws IOException {
            if (null == servletOutputStream) {
                servletOutputStream = createOutputStream();
            }

            return servletOutputStream;
        }

        @Override
        public PrintWriter getWriter() throws IOException {
            if (null == printWriter) {
                printWriter = new PrintWriter(
                        new OutputStreamWriter(getOutputStream(),
                                               getCharacterEncoding()));
            }

            return printWriter;
        }

        /**
         * Creates output stream with GZIP delegation.
         *
         * @return servlet output stream
         * @throws IOException io exception
         */
        private ServletOutputStream createOutputStream() throws IOException {
            final ServletResponse servletResponse = this.getResponse();
            gzipStream = new GZIPOutputStream(servletResponse.getOutputStream());

            return new ServletOutputStream() {

                @Override
                public void write(final int b) throws IOException {
                    gzipStream.write(b);
                }

                @Override
                public void flush() throws IOException {
                    gzipStream.flush();
                }

                @Override
                public void close() throws IOException {
                    gzipStream.close();
                }

                /*
                 * These two are not absolutely needed. They are here simply
                 * because they were overriden by GZIPOutputStream.
                 */
                @Override
                public void write(final byte[] b) throws IOException {
                    gzipStream.write(b);
                }

                @Override
                public void write(final byte[] b, final int off, final int len)
                        throws IOException {
                    gzipStream.write(b, off, len);
                }
            };
        }
    }
}

WebSocket 協議是實現了瀏覽器與服務器全雙工通信的 HTML5 新協議之一。傳統瀏覽器只允許通過 HTTP 與網站互動，然而對于富 Web 應用 如聊天和游戲，HTTP 的效率不太高，因此HTML5 提供了socket API，只需一個握手動作就能在瀏覽器和服務器之間建立快速通道。

然而在 11 月 26 日，安全研究人員發表了一篇研究報告（PDF），他們發現 WebSocket 和透明代理存在嚴重安全問題，他們演示了基于 Upgrade 和 CONNECT 的緩存中毒攻擊，研究人員提議修改握手方式。在 Bugzilla 上，Firefox 開發者討論了該問題，他們最后決定Firefox 4 將默認不啟用 WebSockets，從 Firefox 4 beta 8 開始用戶將需要修改設置才能啟用 WebSockets。未來在解決安全問題后，Firefox 會選擇默認啟用。

轉自：http://www.oschina.net/news/13668/disabling-websockets-for-firefox-4

自從發布第一個版本來，大家給了很多建議，謝謝了 :-)

下個版本 0.2.5 將于明年 2 月 14 日發布，其中加入兩個大的特性：

• 多用戶
  Solo 不再是單用戶博客了。多人可以一起在一個博客里進行文章撰寫，非常適合團隊博客。另外，如果是情侶博客的話，哼哼....
• 草稿夾
  想發布再發布吧！當然，發布了也可以再草稿化....

這個版本的改變比較大（數據存儲、邏輯控制、視圖），除了 Solo 上述兩個大特性的加入，還有 Latke 框架上的增強：

• 存儲緩存
  本地測試可以提升單一實體按 Key 訪問時速度 400 倍左右。當然，部署到 GAE 后可能沒這么好的效果 - -~

（廣告：Latke 是 GAE 上的一個應用框架，主要整合了 Guice、FreeMarker、Jabsorb，數據模型從視圖到存儲都以 JSON 貫穿）

下個版本是 B3log Solo 的第一個正式版吧 :-)

P.S. 情侶博客？兩個人也是多用戶嘛，0.2.5 中將加入一款皮膚，非常適合情侶寫作！謝謝 Lamb 這么給力！

那大爺買西紅柿來著的，挑了三個放到秤盤里，攤主秤了下說：“一斤半，三塊七。”

大爺說：“我就做個湯，用不著那么多。”說完就去掉了個兒最大的那個西紅柿。

攤主迅速又瞧一眼秤子，“一斤二兩，三塊。”

正當我看不過去想提醒大爺注意攤主的秤子時，大爺從容的掏出了七毛錢，拿起剛剛去掉的那個大的西紅柿，扭頭就走了……

攤主當場就風中凌亂了，我憋成內傷，把頭扭向一邊……

轉自：http://www.douban.com/group/topic/16089209/

GAE 博客 —— B³LOG Solo 0.2.1 正式發布了。

該版本除了修復 Bugs，還增加了自定義文章/頁面鏈接，改進了緩存，以及加入了新皮膚 favourite。

在 0.2.1 開發之際，Lamb 童鞋加入了 B³LOG Solo 開發團隊（成員列表），并給我們帶來了新皮膚 favourite。

新特性

• 評論表情
• 自定義文章鏈接
• 自定義頁面鏈接
• 新皮膚——favourite
• 加入了“初始化”功能（/init.do）

Bug 修復

• 修復了偏好設定與統計數據丟失
• 修復了皮膚顯示錯誤
• 修復了按標簽/存檔查看文章時排序的錯誤
• 修復了站外相關閱讀顯示站內文章問題

改進

• 提交評論/回復后只刷新評論列表
• ”最新評論“/統計信息使用模板生成
• 編輯器加入了中文配置
• 調整一些頁面鏈接后綴為 .html
• 改進了頁面緩存

具體改動看這里。

升級

如果您是 0.2.0 的用戶，那么請在部署完 0.2.1 后登錄后臺，訪問 http://${application-id}.appspot.com/upgrade/v020-v021.do 進行升級。

該升級程序主要是對頁面自定義鏈接特性進行數據一致性升級。

項目

如果在使用、測試中發現任何問題，如果您有任何意見或建議，請告知我們 :-)

• 項目地址：http://code.google.com/p/b3log-solo/
• 下載地址：http://code.google.com/p/b3log-solo/downloads/list
• Bug/特性提交：http://code.google.com/p/b3log-solo/issues/list

作者博客

• 簡約設計の藝術
• Vanessa
• 羔羊<>沉默

發布歷史

1. GAE 博客——B3log Solo 0.2.0 發布了！
2. GAE 博客——B3log Solo 0.1.1 發布了！
3. B3log Solo 0.1.0 發布了！
4. B3log Solo 0.1.0-preview2 發布了！
5. Solo 0.1.0-Preview1 發布了

GAE 博客 ——  B³LOG Solo 下周將發布 0.2.1。

該版本除了修復 Bugs，還增加了自定義文章/頁面鏈接，改進了緩存，以及加入了新皮膚 favourite。

在 0.2.1 開發之際，Lamb 童鞋加入了 B³LOG Solo 開發團隊（成員列表），并給我們帶來了新皮膚 favourite。

0.2.1 具體改動可以看這里，發布日期定為 12 月 1 日。

隨著 Web2.0 的風靡，JavaScript 已經成為一門被人們重新認識的編程語言，由于大量 JS 開源框架的出現，利用 JavaScript 開發 的項目越來越多，越來越大。同時，也有越來越多JavaScript 開發問題暴露出來，如性能、網頁加載速度等，其中，JavaScript 文檔維護也成 為了開發者亟待解決的一個難題。

許多現代編程語言都有自己的集成化文檔生成工具，像 Java 有 JavaDoc，.NET有 NDoc，PHP有 PHPDoc，這些自動化文檔工具可以根據代碼中的注釋自動生成代碼文檔。

JsDoc Toolkit 就是這樣一個自動化文檔工具，它是發布在 Google code 上的一個開源項目，和其他語言的文檔工具一樣，它可以自動從 JavaScript 代碼中提取注釋生成格式化文檔。 

下載地址

http://code.google.com/p/jsdoc-toolkit/downloads/list

運行環境

JsDoc Toolkit是用Java開發的，運行時需要 Java 1.5+。

用法

在運行之前，你需要把當前的工作目錄切換到JsDoc Toolkit目錄，并確保將java.exe所在目錄添加到環境變量中。

java -jar jsrun.jar app\run.js -a -t=templates\jsdoc mycode.js

mycode.js是需要生成文檔的js代碼，如果mycode.js和JsDoc不在同一目錄，請加上文件的絕對或者相對路徑。如果項目中有多個js， 可以使用通配符*來指定多個js文件(*.js)。-e參數指定文檔編碼，-t參數指定文檔模板位置（可以新建或修改模板文件讓輸出的代碼文件更具特 色），生成的文檔文件在JsDoc目錄下的out目錄中。為了使用方便，我寫了一個批處理文件，你可以將代碼保存為run.bat，放到JsDoc目錄 下：

常用關鍵字

詳細語法請參閱：JsDoc Toolkit Wiki

整理自：http://blog.tugai.net/2010/01/08/jsdoc-toolkit-usage/