剛剛試著查找一些 GAE 的相關應用資訊的時候,在 App Gallery 上看到幾個還算不錯的好玩網站,其中不少 Twitter 類似或使用 Twitter 資料的網站 (因為 twitter 越來越難用了?)

如果你還不知道 GAE 是甚麼,不妨花幾分鐘聽一下 Google 在 Campfire One 的簡短說明,其中 Guido van Rossum (Python 的作者, Google App Engine 成員之一) 也給了一段演講

Campfire One: Introducing Google App Engine (pt. 1)

Campfire One: Introducing Google App Engine (pt. 2)

Campfire One: Introducing Google App Engine (pt. 4)

Campfire One: Introducing Google App Engine (pt. 5)

Campfire One: Introducing Google App Engine (pt. 6)

長久以來,一直為了一個小小的資料庫系統尋找適合的解決方案。這個系統的基本概念是要建立一個可以大量收集與處理 Metadata 的資料模型。由於這只是一個 Pet Project,在無法額外投資建立叢集系統的狀況下,只能試著用一些簡單的方式來實做。

這個資料庫的用途是可利用透過各式 Metadata 所組成的 Facts 進行推論。稍早的實驗,已經可以有效率的進行基本的前推式(Forward-chaining)與回溯式(Backward-chaining)的混合式推導來取出有意義的「knowledge」。

我的資料形式都是 subject-predicate-object 表示的 RDF Triples (RDF: Concepts and Abstract Syntax),原本是專注在可以處理 RDFTriplestore,但大部份的開放原碼後端資料庫都還是使用 RDBMS,加上冗贅的 RDF/XML 資料交換格式,速度上實在難以令人忍受。而 ORDBMS 又需要使用不少的計算資源 (記憶體 :-/ ) 才能順利執行。

於是,策略性的將系統設計為 Controlled vocabulary,後端採用飛速的 SQlite。以速度來說,在有 VFS 快取下,從兩千餘萬筆資料中取出十筆的時間大約是 150ms。這種速度在使用上是毫無問題的,但如此一來毫無 Scalability 可言。問題之一是寫入的速度並不快,而且寫入過程資料庫便被鎖住,別說同時寫入,就是取用也是一個大問題。

於是,試著找一些可行的方案,如以 BigTable 為基礎的 Apache HBase, Hypertable,或是 Document-oriented database 類型的各式解決方案,如以 Erlang 開發的 Apache CouchDB, 基於 Facebook Thrift 架構的 ThruDB, Ruby 開發的 StrokeDB, 或 Java 為基礎的 FeatherDB。這些資料庫具備分散式且容錯的設計,而且都適合塞 schema-free 的資料。唯一的問題是你還是得自己架設一堆伺服器,才是「正」分散式、容錯設計。

直到最近 Google App Engine (視訊說明) 推出正式的服務租用價格,由於費用極為便宜,我便開始認真考慮是否可以把資料庫移到網路公司所提供的 Platform-as-a-Service

Google App Engine 提供的是以 Python 語言為基礎網站應用軟體開發環境,其中提供 Datastore API,是基於 BigTable 上所開發,以提供了所謂 Scalable data-backed。另外一個價格與功能相仿便是 Amazon SimpleDB (但是 GAE 的硬碟儲存費用便宜多了)。這兩組服務所提供的都不是標準的 SQL 語法,而是特定的 API 搭配特製的查詢語法,Datastore 是 GQL, SimpleDB 則設計了自己的 query language.自然,網路上已經出現了根據此 document-oriented database 與 RDBMS 的交相論戰,如 Ryan Park 所寫的 Top 10 Reasons to Avoid the SimpleDB HypeYurii Rashkovskii (StrokeDB 的作者) 的回覆 Top 10 Reasons to Avoid Document Databases FUD

對我而言,我並不需要 RDBMS 的特色,key-value 的資料庫形式已經可以滿足我的要求。問題在於系統是否可以處理我的需求,根據 High Scalability Todd Hoff 的文章指出,GAE 的 Datastore API 似乎有些速度上的問題、以及 Application Quotas 的限制,如此還必須實際再深入研究軟體的設計方式。而 Amazon SimpleDB 尚處於 Limited Beta 的狀態,因此還不能進行實際的評估。此外,目前這些方法還無法做 Path queries,是下一個研究方向。

The software is updated at 2010/10/05.

It’s nice to see that people still like to use the small piece of software which been wrote for 20 months without updated. Thanks for feedback from

  • Uwe, g021030 (at) gmx.net
  • Keith Refson, K.Refson (at) rl.ac.uk

And the others how left the messages on the blog, especially patch from Hank Hampel and encouragement from Dick Dunbar. 😉

The new release is now handling in-line attachment as well, and it’s autotoolized and debianized.

You can download the tarball and deb file for Debian sid from

evolution-remove-attachments_0.0.2.tar.gz
evolution-remove-attachments_0.0.2_i386.deb
evolution-remove-attachments_0.0.2.dsc
evolution-remove-attachments_0.0.2_i386.changes

They are tested on Debian Sid with Evolution 2.22.

標題原為「何能使自由軟體計畫存活於麻煩人物之中?」,經 jserv 建議,改為「來亂者,去死!!」

這其實是去年就聽過的主題,不過近來又再次接觸到所謂「麻煩人物」的攻訐,因此特意整理此段演講分享社群中人參考。也作為內省之用。

基本上,這麼一些人長年以來到處與人唱反調,

  • 若你辦了協會,他會質疑你立意不佳。
  • 若你舉辦了票選活動,他會質疑你好大喜功。
  • 若你參加了票選活動,他會說你灌票,貪圖虛名。
  • 若你不幸被安了社群職位,他會說你沽名釣譽。
  • 若你有幸取了企業或政府資源贊助,他會說你分贓利益。
  • 若你剛刻了一個新軟體,他會說架構全錯,應該依照他的先知卓見重寫。
  • 若你刻了個好用的軟體,他說嫌棄功能不全。該用其他設計健全的軟體。
  • 若你失敗的經營了軟體社群,他會理所當然要你好好反省並影射你無能。
  • 若你成功的經營了新軟體社群,他會批評你政治不正確,號招成員出走。
  • 若你….他會….

可能是透過網路溝通的誤解或短時間內的情緒問題或過度自負或天生心理殘障或後天傷害悲觀或者根本是憤世嫉俗而造成上述的行為。

大體來說,這些行為是有益於社群發展。但問題是這群人基本上拒絕合作。他們願意抱怨,不願貢獻,很多時候根本是個戳樂 (Troller),他們以戳你為樂。你要跟他們客觀的分析問題,他們會很主觀的訴求於情緒。你誠心的想聽他們的意見,他們卻說不出個所以然。你邀他們出席聚會,他們會出污泥不染的拒絕參與。你邀他們主辦,他們會說這不是他們的使命。

到頭來,你只是自找罪受的徒勞無功。你甚至無法從討論中找出一點點建設性的意義。於是、於是你得好好的研究一個方法來辨識、管理他們。

這段標題為 “How Open Source Projects Survive Poisonous People” 的演講是由 Ben Collins-SussmanBrian W. FitzpatrickGoogle Tech Talk 中所分享。Ben Collins Sussman 與 Brian Fitzpatick 目前都是 Google 的工程師,兩位長久以來都致力於開發 subversion 計畫。

這個主題的基礎參考書是《生產開放原碼軟體,如何經營一個成功的自由軟體計畫》 (Producing Open Source Software, How to Run a Successful Free Software Project)

若你並非自由軟體開發者也無所謂,讀完整篇文章,你會發現這裡的情境適用於普遍的狀態,包含企業、NGO、社區、社群等。因為,到處都有這樣的人存在。甚至,你也可以找到類似的商業書籍中有相似的處理建議,像是 《成功開發員工潛能的24堂課》(Dealing with People You Can’t Stand)、《搞定頭痛人物》(How to Deal With Difficult People)等書。

生產開放原碼軟體,如何經營一個成功的自由軟體計畫


身為一個想認真瞭解開放原碼自由軟體的讀者,你肯定已經讀了 Eric S. Raymond教堂與市集,因而學習了所謂市集模式為你的軟體計畫帶了甚麼樣的好處,你大約也從書中習得幾個重要的準則,像是擁有使用者、儘早發表、頻繁發表等等。

不過,教堂與市集中並沒有告訴你該如何經營一個自由軟體計畫。很快你會發現,經營一個自由軟體計畫並沒有你想像中的簡單,除了各式各樣的術語文化,你還得學會經營社群與「管理」你的使用者們。

這本由 Karl Fogel 所著作的 《生產開放原碼軟體,如何經營一個成功的自由軟體計畫》 傳授了所有相關的眉角 (訣竅),主題廣泛的含括了

  • 啟動一個自由軟體專案,包含選擇專案名稱、定義計畫聲明書、計畫之資訊提供與敘述。
  • 技術基礎建設 (溝通管道之郵遞論壇、IRC、Wiki、版本控制系統、臭蟲追蹤系統)
  • 軟體專案計畫之社交行為與政治方法。
  • 資金籌措方式。
  • 溝通技巧,學習對話調性、辨識無禮/理的人、應對難搞的人、運營成長的社群。
  • 軟體套件封裝、發表、分支管理等。
  • 義工管理。
  • 授權、版權與專利等問題。

這本書非常適合剛想踏入自由軟體開發世界的開發者,也適宜任何一位想瞭解如何經營一個自由軟體計畫的讀者。

溝通

Ben Collins Sussman 與 Brian Fitzpatick 的演講主要是著重在《生產開放原碼軟體,如何經營一個成功的自由軟體計畫》一書第六章的【溝通】。重點在於自由軟體計畫中,該如何辨識所謂「缺德人士」,以及如何驅離他們。

之所以需要遠離缺德鬼的原因在於,自由軟體計畫發展最重要、最有價值的唯一資源是專注參與的義工們。任何一位無恥之徒的行為都可能污染快樂開發社群中的空氣,造成計畫中的義工們分心,甚至放棄參與計畫。

然而任何一個自由軟體計畫都會碰到這樣的人。原因在於領導開發者或協調者,總是必須在權宜的狀態下作抉擇。你得抉擇分支的目標、里程碑目標、修改建議的取捨。麻煩的是,凡是決定總無法令每個人滿意。因此你得準備好接受社群的其他人所給你的挑戰或批評。

然而,大部分的情況下,社群其他成員總是可以透過合理的溝通妥協於主協調者的決策。然而,有另外一群人的反應則不是如此。這群人就是演講中討論的頭痛人物。

頭痛人物

這裡所說的頭痛人物泛指任何使軟體開發受挫的人。若要評估一個自由軟體計畫的活躍度,我們通常會計算所謂的公車指數 (Bus factor),Bus factor 意指重要開發成員的多寡,指數意義在於萬一火車頭成員被公車撞死,計畫持續的機會有多大。

影響公車係數的變因很多,可能是因為工作內容改變、生活形式的改變、談了戀愛、失戀、生了小孩等等。或者是浪費時間在回應頭痛人物,或者被缺德鬼激怒,因此分心而降低生產力。

最常出現的頭痛人物就是日常即興加入的新手,他們帶著全部大寫或是 ‘root’ 的暱稱闖進 IRC 頻道或論壇,毫無禮貌的要求支援或宣告訴求。

或者是過度熱心的參與者,在演講中,提到一個案例。在 Subversion 的發展期間,大約是 2003 年的最後幾個月,有一位人士回覆每一篇文章,以至於他在當下的排名在頭六名中,然而其他五名都是主要的開發者,而他純粹發信,如此行為嚴重影響其他開發者的產能。這當然也算是一種麻煩人物。

但頭痛人物並不見得是新手,也可能是資深的社群人士,甚至是德高望重的前輩。既然軟體由人寫成,不可避免的總會碰到缺德難搞的人事問題,也並不是成功軟體計畫的主開發者/協調者就是一個容易相處的人,例如 Linus 長久以來就讓 Gnome 計畫很難過

但我們必須說,這樣的行為是非常不道德的。

你要知道,開放原碼社群是基於大家對名譽的重視所驅動,隱性的名譽機製為社群中的人提供了一種微妙的壓力系統,驅使人們往正向的方面發展。特別是開源軟體社群名譽壓力系統也拉引了好管閒事之徒的興趣,顯然破壞他人的名譽也是一種賺取名譽的方式。

身為一位自由軟體開發計畫的成員,你應該小心的保護專案的產能,以免計畫被老鼠屎拖累。

辨識

麻煩人物的通常有幾個主要的特徵,你可以依據這些特徵來辨識

  • 惡毒的人
    • 潑冷水、污辱現狀
    • 憤怒的索求
    • 散佈黑函
    • 刻意激怒他人
    • 偏執狂似陰謀論者、拚命指責別人
  • 自負
    • 拒絕承認他人的意見。
    • 以偏概全的主張。
    • 重啟已達成共識的話題。
  • 拒絕合作
    • 很愛抱怨,但不願意修正任何問題。
    • 不願意討論解決問題的構思。

有些人會帶著惡毒的心態踏進你的計畫裡面。他們可能會潑你冷水,將你的成就嫌棄的一文不值。另外一些人,認為你理所當然要提供服務,無論是技術支援或者是活動舉辦,你應該要立即妥善的滿足他的需求。有些人會散佈黑函甚至偏執的在認為計畫後面有某種陰謀,或者刻意的激怒他人。

另外有些人則是過度自負,認為他自己的主張才是正確的,相信任何事情都有正義是非,而他們自然永遠都是正義那一方。最麻煩的是他們以偏概全的訴求,往往會綁架專案的發展方向。或者他們會過份在意每一項討論,老是重提那些已經達成共識的老話題。

另外一些人則純粹拒絕合作,他們只是不希望看到你成功。因此會帶著負面的態度慢慢的污染你周圍的空氣,直到它發出惡臭,鬧走你的成員為止。

處置

你可以發現,其實有許多麻煩似乎都是溝通的問題。事實也是,由於開放原碼社群的對話討論一向都是在網路上進行,偶爾才有面對面的接觸。誤解似乎是多少難以避免的問題。例如,有些文化避免難堪公開的指責,有些文化則痛恨私下批評,你似乎很難判斷陌生人喜歡那一種溝通方式,很容易就會觸怒對方

然而有幾個準則是通用於任何處置方式的

  • 重點 (Comprehead)
    • 保持注意力與專注力 (preserve attention and focus)
  • 防禦 (Fortify)
    • 建立一個建康的社群 (Build a healthy community)
  • 辨識 (Identify )
    • 偵測搬弄是非的跡象 (Look for tell-tale signs)
  • 消毒 (Disinfect)
    • 保持鎮靜與自我立場 (Maintain calm and stand your ground)

在實務上,有幾個事項是在演講中所分享的。其中之一是不要把自己的名字擺進程式碼裡面,因為這會造成自尊膨脹的問題,這似乎是宣示此為你的地盤,外人誤觸的禁忌,這種習慣會妨礙整體計畫的發展與自由,應該有所避免。

此外,應該避免私下溝通。私下溝通是一件很容易使用的政治工具,透過私下溝通你總是可以比較輕易的做下決策。然而,這樣的行為卻排擠其他人的意見與想法。計畫成長後,你總會不停的為新來的人解釋當初的決策。總之是一種得不償失的手段。

另外則是郵遞論壇的禮儀、重啟舊議題等。特別容易發生於敵對的議題上,偶爾,你會發現有一人不停的重開那些反對他意見的對話。他的目的大約在於持續的張貼再張貼,直到對方疲累放棄,而獲得最終毫無意義的勝利感!

通常你可以很快速的辨識出這種戳樂毒瘤,原則上只要你保持情緒,客觀的進行討論通常可以達到有建設性的具體結論。然而,更多時候,戳樂會惱羞成怒的激動不已,甚至出口傷人。這種情況下,如果沒有提早為社群建立一個健康的政策防護機制,你也只能被動的請社群公斷啦。

雖然這篇文章是為了避免麻煩人物所寫,但是有時候這些人性問題也會出現在社群經營者身上。根據 Rober Kaye 的意見,無論你是參與者或經營者,都必須具備同理心,以及以下的態度,才能在社群中廣受歡迎

  • 禮貌 (Politeness)
  • 尊重 (Respect)
  • 互信 (Trust)
  • 謙卑 (Humility)

缺乏以上態度,你也可能會犯了過度自負的毛病,而做了不受社群歡迎的錯事呢。這篇短文大約四千字主要參考由 Ben Collins-SussmanBrian W. Fitzpatric 的演講 – “How Open Source Projects Survive Poisonous People” 以及 由 Karl Fogel 所著作的 《生產開放原碼軟體,如何經營一個成功的自由軟體計畫》 一文。敬請收聽以下演講

這個月底,將是 Wine 計畫成立十五週年!Wine 也將終於在十五年後釋出 1.0 版 !!

這兩三年,由於 Google 的積極參與 (Google 的其中一個產品 Picasa for Linux 是基於 Wine 所開發),許多程式如 Adobe PhotoshopAdobe Flash 都已經可以在 Wine 上面成功執行,相容性已經有大幅度的改善

因此我也試著再度玩起 Wine,試著裝了 wine, wine-doorsIEs4Linux,幾個主要的軟體、元件如 DCOM 98, MSXML 3/4, GDIPlus, Visual C++ runtime library 6, Internet Explorer, Micrsoft Media Player 9 等倒是沒有問題。

前些時候裝了 Sling Player, 以及 Macromedia 的 Dreamweaver 8, Fireworks 8 (可透過 winedoors 直接安裝) 大致上也可以運作。

接下來又測試一些台灣使用者常用的 Windows 程式,如 Foxy, GOGOBOX 與 KKBOX 等,則碰了些無法使用的障礙。雖說安裝都沒有問題。

首先是 Foxy (請別作道德勸說,這純粹是測試相容性),安裝時提示畫面,中文會顯示亂碼,但是可以成功的安裝,且系統也會自動設定啟動選單。但是啟動後,系統會出現以下錯誤訊息:

Unhandled exception: page fault on read access to 0x00000020 in 32-bit code (0x00422cb4).

過了啟動畫面後,無論如何都無法進到主程式,只好先回報到類似的問題上,稍後再求解。

另外一個測試的軟體是 GOGOBOX,安裝也沒有任何問題,也可以啟動主程式後登入系統。也可以進行「累積里程」的行為。但是 GOGOBOX 的使用是先從網頁上下載安裝檔,然後在點選網頁上得連結時,透過 ActiveX 元件將下載網址傳給主程式。

在進行點選連結時,Internet Explorer 可以叫起 GOGOBOX 主程式,但是軟體會不停的提示「GOGOBOX 檔案傳送管理員沒有設置好,或是新版本已問世。要現在設置/更新嗎?」,卻始終無法正確的把下載檔案傳進 GOGOBOX 主程式。殘念。

另外一個測試的軟體則是 KKBOX,安裝的過程中也沒有異狀,執行後可以進到主程式,雖說選單是亂碼。但是由於無法退出軟體啟動時的 Panel,也就是中間的「註冊」、「登入」提示畫面。那個畫面是嵌入一個瀏覽器元件,理論上按下「註冊」,系統應該開啟一個註冊網頁,若按下登入,系統應該提示一個登入對話視窗。

然而,此時按下註冊或其他網址,軟體毫無反應。應該是 shdocvw 未實做完全的緣故。若按下「登入」畫面,軟體則出現 “Unhandled exception: page fault on read access to 0x0100bbf8″,然後退出視窗。

要讓這些在中文微軟視窗使用者流行的軟體在 Linux 上順暢執行,還有許多功夫要下阿。