ZServer uncaptured python exception

在 http://aspn.activestate.com/ASPN/Mail/Message/zope-list/3492748 提到，使用者臨時取消網頁存取動作，例如按了瀏覽器的停止鍵，會產生這類的訊息，一般是無須追究的情況，真想探究 exception 內容的話，要主動去接取它。如果伴隨系統資源吃緊的狀況，可用 'debug spinning zope' 關鍵字來查詢除錯技巧，或是查詢 spider 或 bot 的造訪狀況，必要時採用 iptables -A INPUT -s -j DROP 的激烈手段。

User SubGroup and Associated Roles

Plone 3.2 版本之前的會員管理介面 prefs_users_overview 執行搜尋時，只能針對 full name 欄位進行比對，不能比對 id 欄位，另外也有 subgroup 與 role 的顯示問題，症狀主要記錄於 #9317 和 #8940。目前已在 changeset 33533 完成修訂，並整理出新的管理介面。

Fake Eggs ?

This is an abstract from Scrambled eggs by Martin Aspeli.

藉由 egg 機制，我們可以更順暢地進行模組軟體的包裝與散佈，但是，遇到 buildout 想要自動昇級某些模組時，為了滿足相依衝突時，egg 也可能帶來許多痛苦，我們會被一堆版本昇級要求資訊淹沒。

由於 Plone 3.0 到 3.1 搭配的 Zope 並沒有包裝成 egg 檔案，導致 setuptools 無從得知 Zope 3 模組的 egg metadata 資訊。舉例來說，如果你安裝一個相依於 zope.component 的模組，但是 setuptools 並不知道你已經有 zope.component 了，因此會試著下載最新版的 zope.component。由於新版 zope.component 的下載動作會引發其他相依關係，很容易造成永無止境的昇級要求。

為了解決上述問題，plone.recipe.zope2install 這個 recipe 預設會安裝一些 fake egg，它的效果，就像是建立一堆指到 parts/zope2/lib/python/* 的 egg。如此一來，setuptools 就能知道系統裡存在 zope.component、zope.interface 等標準模組，不需要再去下載新版檔案。

常見的情況是，我們只知道需要安裝某個檔案，但不清楚所需的明確版本，因此 fake egg 會指定為 0.0 版本，除非你為特定的 recipe 額外指定它的版本號碼。也就是說，如果有個模組的相依關係是 zope.component >= 3.1，setuptools 仍然會以為系統既有的 zope.component 版本過舊，將嘗試下載新的版本。

那麼，模組的相依資訊被記錄於何處? 它的來源大致有兩類，一是在模組檔案的 setup.py 內容裡，二是從 buildout.cfg 檔案的 eggs 設定值尋找。相依資訊的常見形式，又可分成兩類，第一類的例子是「我需要和 zope.component 一起工作」，只指定模組名稱，而不指定模組版本，第二類的例子是「我需要和 zope.component >= 3.4 版本一起工作」，同時指定模組名稱與版本條件。

有時，在 setup.py 裡指定最小版本號碼是必要的，因為某些版本以上的模組，才提供我們需要的功能。當然，在 setup.py 裡明確指定「我需要和 zope.component == 3.4 版本工作」是合法的設定方式，但通常會造成日後的災難，而指定最大版本號碼的方式，例如「我需要和 zope.component >=3.4, <=3.4.999 版本工作」，通常也是很糟的形式。一般而言，除非有必要，永遠不要在 setup.py 裡指定「==」的版本要求，頂多使用「<=」的版本形式。因為，這類不適當的設定值一旦出錯，除錯工作極度困難。

另一方面，目前 setuptools 的運作方式，是找尋最新版本來下載，如果它先下載了某個模組的新版本，就會順著它的相依關係來下載其他模組，即使某個舊版本提供更合適的相依條件，setuptools 並無從得知，這會導致下列問題：

* setuptools 下載過新版本的模組，和稍後模組的最大版本條件相衝突。幸好，這個問題並不難解決。

* 原本 buildout 運作正常，但是有人在 PyPI 上傳新版模組，造成相依關係更新，接著你又執行 buildout 更新動作，下載了新版模組，引發更多新版模組的下載。運氣好的話，系統會通知版本衝突的訊息，運氣不好的話，表面上 build 動作完成，但執行系統時卻失敗。

Quote Portlet

想在 Plone 網站加上 quote portlet 嗎? 利用 collective.portlet.quote 輕鬆就能完成，它還有 Quote Folder 專門來放 Quote Type。不過，並不喜歡預設的方框樣版，想要改個樣子，於是動手修改兩個檔案。 修改 randomquote.pt 內容如下：

    <dd class="portletItem odd">
      <q tal:content="structure view/get_quote">
        Body text
      </q>
    </dd>
    <dd class="QuoteSource">
        <span class="portletBottomLeft"></span>
        <p tal:condition="not:view/has_link">
            –
            <tal:block replace="view/get_source"/>
        </p>
        <tal:block condition="view/has_link">
            <a tal:attributes="href view/get_link">
               –
               <tal:block replace="view/get_source"/>
            </a>
        </tal:block>
        <span class="portletBottomRight"></span>
    </dd>

新增 ploneCustom.css 內容如下：

.QuoteSource
{
    border-color: #8CACBB;
    border-width: 1px;
    border-style: none solid none;
    margin: 0;
    text-align: right;
    padding: 0.25em 1em;
}

有圖有真相。

Bus Rapid Transit

本文取自友人 AB 轉寄來的內容，略作極小的排版修改。我支持大眾交通系統應慎重考量低耗能高效率的方案選項，盲目地 MRT 並非民眾之福。另外，據說嘉義也有 BRT (Bus Rapid Transit)，但跟巴西 Curitiba 的實例相比，仍有不小差距。

之前，我一直覺得捷運是很棒的東西，但是我這幾年再也不這麼認為。

先講公視獨立特派員上週的報導：1800億的夢（高雄捷運）
線上觀看：http://www.peopo.org/innews/post/49974

非常值得花時間看完的報導。

不過我已經看到有人評論：「搞捷運 眼光要看遠」

這些論點看似有理，但是其所謂的捷運，都只侷限在台灣目前獨立於路面外的軌道捷運（高架或隧道）。

請看看上述影片中另一種不一樣的捷運：BRT

其實對於捷運的反省，我也是從這幾年才開始。

首先是四年前我從《你，還在開車嗎？》這本書中，看到夏鑄九教授為這本書所寫的序提到：

今天，一般市民或許不瞭解，台北市的財力已經無法承擔繼續興建目前這個光鮮亮麗卻不符永續城市原則、已經過了時的七Ο年代的昂貴捷運系統了。而高雄，卻因為政治原因，比照台北，亦步亦趨。這就是交通部為何不得不在城市運輸政策上終結高、中運量的捷運系統，改推輕軌的原因。我們若不另外選擇電車（或者說，有軌電車）、公車與腳踏車等運輸工具，台灣的城市交通就還是一條不歸路。

—《你，還在開車嗎？》序，夏鑄九

而《你，還在開車嗎？》這本書也提到一種捷運的替代方案：BRT (Bus Rapid Transit) 系統：

借用巴西的 Curitiba 的經驗，告訴我們一個公共交通系統，若是擁有專用的巴士道、底盤低矮的巴士、路邊收費站，及高於路面的登車月台，功能將不輸於任何有軌的公共運輸設施，而成本卻祇有軌道捷運的一小部份。
—《你，還在開車嗎？》，Alan Thein Durning，p.113

那時候光憑文字很難想像什麼是BRT，直到後來看到公視的報導。

之後，某次和蠻野心足生態協會理事長文魯彬經過台北某個捷運工地，他就指著工地說捷運不好，我就問他為什麼？捷運不是很環保嗎？他說：

捷運也是高耗能的交通系統，只是不像汽車，污染立即可見，捷運的污染產生在林口發電場。

之後，我從潘翰聲的文章也讀到類似的評論：

而捷運耗電量極大，將汽車污染物從都市轉移到鄉村區的燃煤電廠，是環境不正義的課題，二氧化碳的減量效果應有詳實的量化分析。

不過該文章另一個論點更點出另一個問題：

更嚴重的是，捷運的經濟效益被誇大，本案（台北捷運南北線）所評估的效益高達六成是土地增值效益，簡直是花公家的錢幫財團炒地皮。

這是經濟問題，民代和民選地方首長、官員似乎都不願意告訴民眾：

台北捷運系統每公里平均造價60多億元，以目前搭乘率的票務收入，也僅能維持台北捷運公司的操作營運，無法回收建設成本，更遑論未來還需更大一筆維修老舊車體的費用。大概估算，搭台北捷運的乘客約得到政府交叉補貼2/3的票價，即一段20元的票價，政府已補貼使用者40元，原應向乘客收60元。其他縣市想有樣學樣，要求中央政府補助興建捷運，但大眾運輸網絡都不如台北，其便利性及效益就大打折扣，真怕最終淪為載蚊子的捷運。 BRT 每公里造價約莫數千萬元，真的低廉又環保。
http://zh.wildatheart.org.tw/archives/mrtaeaeiebrtcaeece.html

果然不幸言中：「高雄捷運通車不到兩年，已經虧掉60億」

台灣最大的問題是不敢跟私人運具（汽車）搶道，所以目前還沒有任何一條捷運是利用現有路面。而公車專用道的興建，都還要接受民代質疑：是否會因為車道數量縮減而影響到汽車的行車速度？

真是奇怪，要顧全到汽車不會塞車，早就是都市交通中被實證為不可行的交通策略，看看美國城市的道路面積擴張的程度，還是無法解決都市交通問題的事實即可得知。

而且，讓私人運具不方便（塞車、停車問題），才會讓大家轉用大眾運輸系統，這不是很簡單的道理嗎！

看著台北捷運局的捷運願景圖密密麻麻的捷運線路，只希望它不會成真。

Dexterity vs Archetypes

This blog is an abstract from How is Dexterity related to Archetypes by Martin Aspeli.

Dexterity 是 Archetypes 的替代方案，這兩種方案都是 Plone 建構 content type 的框架技術。由於 Archetypes 存在已久，是成熟的方案，而 Dexterity 是後起之秀，結合新版 Zope 技術，有些新技術能夠有效處理以往難以解決的問題。

下列是幾項主要的差異：

* Dexterity 結合新版 CMF、Zope 3 的技術與功能，程式碼更精簡，測試工作更能自動且完整。
* Dexterity 具備更高的模組化程度，更容易整合 SQL 資料庫。
* Archetypes 自有的 Schema 機制，並無法完全相容於 zope.interface 或 zope.schema 的介面。
* Archetypes 使用 accessor 與 mutator 來處理設定值，Dexterity 則使用 attribute notation 方式來處理，因此 Archetypes 的寫法類似 context.getFirstName() 而 Dexterity 是 context.first_name 這樣的寫法。
* Archetypes 自有的 field 和 widget 配合 content object 的脈絡來運作，並不容易被應用在獨立表單，Dexterity 則使用 z3c.form 函式庫，這是表單運作的標準工具。
* Archetypes 並不支援新增表單，Dexterity 則透過 z3c.form 來支援，這代表它不需要用到 portal_factory，執行效率能夠改善。
* Dexterity 支援 behavior，但 Archetypes 沒有直接支援。

Archetypes id-to-title Normalizer

Archetypes 的 content type 在新建時，需要決定 Id 並讓它成為 URL 的一部份，決定 Id 的函式可以先從 Products/Archetypes/BaseObject.py 的 generateNewId() 和 _renameAfterCreation() 查起，它們會配合 plone.i18n.normalizer.interfaces 的 IURLNormalizer 和 IUserPreferredURLNormalizer，並分別來自 INormalizer 和 IUserPreferredNormalizer。

實作例子有 ZopeChinaPak 和 C2FileNameNormalizer，也有個 External Method 的例子。