在星期四的早上，沒錯，是星期四，這樣就可以不用跟太多人排隊了，一夥人，在經過了，漫長的你等我，我等你後，還好，終於出發了，只慢大約半個小時左右，已經算不錯了
太陽非常毒辣，為了要玩~~~~命，哈哈，這點犧牲不算什麼的啦，六福村算是蠻近的，車上的人來不及昏睡就到了
下車後，就開始一天一起尖叫的旅程，基本上內容就是，一連串的人類自虐行為，不過，過程可以讓人很 High ，這樣說，好像人類是很怪的動物 ;-）
這一次的尖叫成員有 西瓜，西瓜妹(小咪)，Wendy，文文，仔仔，怡君，神奇傑克，小寶(Gary)，也就是老弱婦孺，環肥燕瘦，都有啦
膽子，隨著時間，應該是有變大，挑戰了，海盜船的最後座位，不過，我想海盜這個行業，還是不適和我，沒辦法和強尼代普作同事了，倒是文文，跟仔仔，這兩個不怕死的，作好幾回，相信他們一定有看，海賊王，人小"膽"大
最令人害怕的是大~~~~怒神，坐完，拍照拿相機的時候，手還會抖，要休息一下，才會恢復，有幾張照片，抖的蠻利害的，不要怪我，經歷這種跳樓的感覺，保證會更加珍惜生命 ;-)
入夜後，每個角落，都很美，遠遠看阿拉伯魔宮，更是夢幻，抬頭，天空沒全然變黑前，抬頭看天空，深藍加上，建築的線條，在配上燈光，也是美到不行，要不是，相機已經沒電了，我一定拍幾張，越夜越美的美美照片
感謝這麼優秀的尖叫團隊是一定要的
西瓜，為我們拍了很多的照片，紀錄回憶就靠他了，瓜哥膽子也超大的，作笑傲飛鷹，還可以幾乎全程放手，張開雙手，有點像是老鷹飛翔的樣子，我可以小放一下，不過，可能是笑不出來的笑傲飛鷹
西瓜妹，一開始以為是西瓜早熟剛參加國中基測的姪女，她專門謀殺我們的相機電力(底片殺手)，表情超豐富，由自然面容，到中風歪嘴，或是裝可愛，裝笑唯，都很自在，有詐騙集團核心成員的天份，下次有機會，在凹她配合演出
Wendy，帶著文文，和仔仔，戰力超強的姊姊，很上相，牙齒白，要離開六福村的時候，還說要直接去唱歌，越夜越High，真佩服，我已經腳軟了，還好西瓜台妹說明天要上班(其實，除了兩個海歸派的學者外，大家都要上班)
文文，丹麥歸國的海歸派，精通，中，英，丹麥文，及法文，超強，哈哈，從頭叫到尾，是我們的主力
仔仔，文文的弟弟，精通，中，英，丹麥文，及德文，這對姐弟，雖然偶有暴力相向，不過還算是有所克制 :-)
怡君，她是這一次，六福村的最佳客戶，使用設施最少，幾乎都不敢坐，真不相信他是雙子的，她和西瓜妹著情人裝，一路，謀殺我們的相機，不過，都不肯開懷的笑，希望在尋轉木馬裡，有滿足一下她的想像
傑克，我們的key man，為什麼呢，因為，我們都出發時間，幾乎都是他在掌控，這一次，沒能坐上他性能超優異的"你愛他"(怎麼不是你愛我呢?)，有點可惜
Gary，一路都在躲鏡頭，不過，沒有他不敢坐的，小寶，不要這麼低調麻
相簿的位置
報稅時節
我們向前的動力
以前都迷迷糊糊的報税,今年看了一下,原來,自己不能算是一位撫養的親屬,只有一個標準扣除額,48000 元,比動物園的猩猩伙食費還少,心中真是無限的感慨壓
在台灣真的是要成立公司,才可以避稅,公司繳的稅,都是花剩的,像是,富爸爸,窮爸爸,裡說的一樣,想想,個人受薪階級,都是先扣,誰管你,要不要吃飯,要不要睡覺,最起碼,的居住成本,跟吃飯,一年,48000,不知道政府是如何算出來的
政府,對於一般的科技公司,分發盈餘時,雖然,盈餘,已經是扣過營所稅了,不過,大多又被董監事,及員工分走,被當成薪水發,員工的底薪又是給的很低,所得稅,繳不到,然後,又是拿股東的權益去發,也只需依面額繳稅,唉,一般小股東又要鬱卒,政府的魄力,應該都被企業家買走了 :-)
我只能說,台灣人,真是老實,又有韌性,真的還都是安分的繳稅
就當,這是勉勵自己的罰金好了,要向上提升 :-)
勉勵自己的話
不停的學習,不要自滿,不要讓時間澆熄熱情
勉勵台灣政府的話
當你們發生捷運弊案的時候,新加坡,已經蓋好很久了
當你們還再出賣國家土地的時候,新加坡再立國的時候,他們就已經知道,土地是有限的資產,所以土地國有,只租不賣,人人,有房住,你們也許對國有土地,也可以用租的
當你們對經濟毫無對策,用房地產,來推升經濟,造成,房地高漲,實質經濟成長不高,失業率可以創新高,薪資成長,負數,唉,真是佩服
當你們發生電子收費弊案的時候,新加坡和美國,已經使用很久,用起來也沒有這麼這麼多的限制
希望,你們每次出國考察的時候,可以真正有考察到 :-)
新加坡,也不是,什麼都好,可是,爲什麼,好的,我們總是學不到
參考資料
動物園猩猩預算 http://www.ettoday.com/2005/10/26/10844-1861513.htm
OSDC 感想
這是一個新的活動，根據長輩的說法，這樣的名字比較有吸引力
這一次有很多有趣的議程，不過時間有點重疊，只好，取捨一下，大多還是聽 Python 的議程，看來在台灣，還是算是冷門的工具，嘆，不過還是可以看到很多長輩的風采，真是值得
有幸，我也能貢獻一的議題，TurboGears ，事前，因為有一次，在 TOSSUG 有介紹過，還有程式，反應有點悽慘，都反應太難，所以，預設，聽者應該都可能沒有太多的概念，這真是天大的錯誤，因此，簡報，做的有點像是文件
下一次，如果還有介紹的機會，應該可以快快帶過概念的部份，簡單的 API 介紹以後，就來個，可以用到資料庫，AJAX，及 Python Library 的實例，這樣，才可以大大展現方便之處，嗯，要想想，哪一方面的例子，比較實用
這一次的簡報 Link
SQLAlchemy
最近，實在太久沒有 Blog 了
SQLAlchemy 定義比較繁瑣，不過，彈性似乎更大，作者說，比較像 Java 的 Hibernate， 也非常用力的維護，可以參考一下，以後，也許用的上，在 2006/04/03 後，開始，支援 MSSQL，這樣就蠻完整的了，SQLite, PostgreSQL, MySQL, Oracle, MSSQL 都支援了，大咖的剩下 DB2，不過我也沒用 :-)
MSSQL 的支援
SQLAlchemy
DjanGo and TurboGears
說真的要比較這兩個 Web FrameWork 的話，真是說來話長，不過基本上，都是是不錯的選擇，這兩個專案，都是由很強的開發者，所主導的，所以都很好啦，不需要爭那一個比較好啦，就像是世界上的 Web Framework， 不會永遠只有 Java， dot NET，PHP， Ruby， Zope 或是 Perl， 每一個工具都有適合的地方啦，重點是我們能掌握多少，活用多少
基本上對於這兩個的比較，真的是很難有誰勝誰優的
這可以分成好幾個部份
URL mapping
DjanGo 是用像 Regular Expression 的方式作 mapping，速度很快，也有很大的彈性， 熟 Regular Expression 的人，該知道他的彈性，喜歡 Regular Expression 的人，就可以選它。
TurboGears 是用 CherryPy 的關係，他的 mapping 像是 python 物件一樣，把 class 或是 參數 mapping 到 url上
Database Mapping
DjanGo 自己有一套資料庫對應的 API，用起來已經夠用的，提供的不管是欄位對應，或是資料表的關係對應，都足敷一般的使用。
TurboGears 他則是採用 SQLObject 這一個模組，已經是相當成熟的模組，對應的方式，更像是真實 Python 物件。
Template System
DjanGo 有自己的一套 template 系統，也可以選用 ZPT 的方式
TurboGears 則是選用 Kid，不過已經有 Cheetah，也可以用 Buffet 支援的 template，現在有 CherryTemplate，Kid，Myghty，Python 2.4 String Templates，XSLT 等
Cache System
在 Cache 上，是 DjanGo 的方式比較成熟，功能比較強，TurboGears 則是仰賴， CherryPy，SQLObject，及採用範本系統的 Cache 機制。
Scalability
兩者的可延伸性，都很好，在 Apache 下可以用 mod_python，也可不用 Apache 改用 LightTPD ，來提昇效能。
其實很多的部份都是個人的選擇，和喜好，所以很難說那一個比較好，當然 DjanGo 比較成熟，對於初學者或是有經驗的人都是比較好的選擇，也提供一個很穩定的架構，API 也不會有很大的變動，文件比較齊全，非常有系統的架構，我想應該是很好的選擇，不用擔心以後要不要改的問題。
所以真的是看個性，我自己，因為都不排斥新的架構，也不太擔心那一個會是終極的解決方案，更不相信廠商說得，永遠只有他們提供的架構最好，純粹，以個人的喜好，我比較喜歡，TurboGears，因為 CherryPy 物件方式的 Controller 我比較不會出錯，比較有系統，SQLObject 非常直覺，已經非常像真實的物件了，CherryPy 支援的 template 系統很多，以後要加，應該更有彈性，也有我喜歡的，ClearSilver，可以有 C 的終極效能，還有已經要和 Subway 合併了，在 SVN 中的進步更是飛快，不過多是整合好的模組，或是，加強，TurboGears 自身的工具，在他的 tg-admin shell 裡，也是直接用 ipython，都是原本就很方便的工具，很快的也有權限及群組的功能，在 toolbox 裡，已經可以自動有管理的介面， Model Viewer，i18n tool set (在 DjanGo 中 i18n 也有好的解決方法)，還有還在討論的元件，這些都是很令人感興趣的。
開發的方法方面，每個人的想法會不同，有時候，都整合好的套件好用，我自身則是喜歡 TurboGears 的哲學，把一些已經很成熟功能強大的套件整合，這樣的好處，可以將不同的模組運用在不同的地方，不一定是 Web 的 AP，像是 SQLObject 就可以不管是 web base 或 form base 的應用裡，一旦 API 運用自如，很快就可以上手，如果以後對，TurboGears 不爽，可以直接由 CherryPy 這一層開始，如果，不喜歡SQLObjetc，想要跳槽，也可以，因為他們原本就是分開的，再來就是 OpenSource 的哲學之一，就是 Reuse，我們顧好自己的應用，如果發現採用的套件有 Bug， 將 Bug回報，讓別人幫我們維護我們也需要的部份，所以我覺得 TurboGears 的開發者在方法上，和我比較接近，說起來真賊，不過確是對大家都有易的，雖然，整個完整的方案像是 DjanGo，可以有集中的管理，和發展，但是對我來說，我用 TurboGears 只是再用原本就有在用的工具而已 (SQLObject，iPython…)。其實我相信，以後這兩個 Framework 會互相學習彼此的優點，所以都不錯啦。
聽再多，都比不上，你自己實做一下，自己感受一下吧 :-)
TurboGears
在 Python 的 Web FrameWork 真的是多到，令人嘆為觀止，不過應該還跟 Java 沒得比，這是好處也是壞處，好處是選擇多了，壞處是力量分散了，還有很多人還真不知道如何選，像是學 Java 的，FrameWork 可能會有很多人看到吐血，太多的文件，以及規範了，這就是為何？ Ruby on Rail 會如此成功的原因之一，因為在 Ruby 上，這是一條最大的路，大多數的人也不需要作選擇，沒有的功能，就是加強她，或是整合進去，不像，其他的解決方案，反而有太多的選擇，而分散了力量，徒增加太多的開發時間，TurboGears 的主要開發者 Kevin Dangoor ，希望的是，他可以整合一個的最好的開發方法，不必再讓別人煩惱要選那一個，他說了兩點 : “best-of-breed”，“one way to do it”，但也有提到，雖然希望是這樣，不過保有可以用不同方法的可能，在最新的 mail list 裡甚至有討論到和 Subway 合併在一起的可能性，不是以後有免費的潛艇堡可以吃，這是另一個 Python 的 Web Framework。
實際用的感想，我只能說，把所有相當成熟的模組，合在一起用的感覺真好，在不同的地方也都用的上，看一次 API 後，都可以受用，像是 SQLObject 也有整合在一個 Zope 3 的一個專案中， sqlos 的產品當中，CherryPy 更是成熟的 Web Framework ，也可以用多種的範本系統，彈性也相當大，只是 TurboGears 只加入 Kid ，有用過 Zope zpt 的朋友應該會感覺很熟悉，應該馬上就可以上手，不過要換，也不是難事，畢竟基本的架構是用 cherrypy ，他支援的 template 就很多了，Cheetah，或是 ClearSilver 都有，不過在 TurboGears 要在自己掛進來，也要自己維護，我還是懶一點，用 Kid 就好，還有整合一個輕量的 javascript 的函式庫 MochiKit ，讓你想作 Ajax 的網頁時，可以輕鬆些。
如果你的系統不會用到 ftp，webdav，也不需要複雜的權限管理，老闆，或是經理要求一定要他們聽過的 Database 不能是 ZODB，或是原本後端就是在 SQL 的環境，那就非常建議，你們的 Web Ap 可以考慮一下了，很快的她就會釋出 0.9 ，及 1.0 stable ，所以到時候就可以真正開發一些應用了 ~~~~
cherrypy 讓你的 web framework 可以直接映射到你的 python 物件上
sqlobject 讓你，不用寫一大堆的 SQL query，table，join 來 join 去，定義好資料型態，還有對應關係，就可以了 ，對付一般的 SQL 情形來說，應該游刃有餘，只要處理一些特殊的部份就好
Mochiki 如果想要用 javascript，讓你有一個現成式庫去擴充
Kid 範本系統，這是將邏輯，和視覺呈現分開的必備工具
上面這些都發揮作用以後，想想，真正的程式可能真的很短了，奸笑中 …… 沒有美術天份的我如果不需要自己蠻幹範本的話，就更美好了~~~
還有很多太細了，還有興趣的朋友，就自己再看了 :-)，那個短片教學也很不錯，不過，還是文件內容比較新 :-)
TurboGears 網站 http://turbogears.org/
“Kevin Dangoor” 的 blog http://www.blueskyonmars.com/
Planet Turbogears http://planet.turbogears.org/
Nano Itx
Web Framework
Ruby on Rail
紅很久了，以 Ruby 快速開發的架構
DjanGo
蠻新的，以 Python 開發
TurboGears
非常新，以 Python 開發
以上的架構，多是有自己的 Application Server，結合範本，也可以做到 MVC 的開發，也容易快速的結合 Ajax， 彈性都非常大，都可以快速開發 Web 應用，功力好，喜歡自己堆積木的同好，不要放過，對 Java 來說，真是很好的對應，Vgod ，有一則 blog，Rail v.s. J2EE 的圖，真的非常好笑，當然，Perl 的架構也是很多，看到 CPAN 就夠嚇人了，不過我自己對整合駱駝文並不太行，常常會頭暈，所以那一部分留給長輩說吧。
我自己則是比較喜歡 TurboGears，原因，大概就是，喜歡，CherryPy （櫻桃派），還有 SQLObject ，這兩個可是很有名的，也不是說 DjanGo 的方式不好，雖然他的成熟度稍高，也已有大型的實作，對岸，也有熱心的朋友 woodpecker.org.cn，不過，TurboGears 的開發腳步非常快，相信，很快 0.9 和 1.0 stable 的發佈應該也不會太遠。
Django, Or why I chose it over turbogears and ruby on rails
TurboGears, or why I chose it over Django and Ruby on Rails
Zope 下的內容管理系統
CMS (Content Management System)
Zope 一用好幾年了，現在已經有好幾套內容管理系統可用，有時會讓很多人不知道如何選用
Zope 的 CMS 大多是基於 CMF 的框架上，再繼續發展，所以有一定的相依性，不過這是好也是不好，Zope 和 CMF 是不同的專案，這樣增加了彈性，不過卻也讓新版的 CMF 永遠必須比 Zope 慢，像這一次 Zope3 是比較大的改版，CMF 要好一陣子才能跟上來，對專案的開發不利，比如說你的專案是相依在 CMF 上，那就算是 Zope3 出來了，你可能還要苦等 CMF Zope3 的版本很久，如果您的專案是相依 CMF 及 Plone 的話，那你可能要等更久，這都是讓開發人員不喜歡的，可能以前作過的都要重新作了。就像是 Zope3 出來到現在，不知道要多久，她的 Product 及成熟度才可以和 Zope2 相同。
好吧開始說 CMS 了
Plone 算是在台灣最有名的，不過從 2.1 的版本後，他的內容就都是用 Archetype 了，不再是 CMF 的內容元件了，也就是說以後相依性，要加 Archetype ，而且在升級時，如果自己裝了很多的產品，或是客製太多的內容，都會造成一定的難度，要自己 patch 升級的程式，這對不是開發人員的使用者來說是個難題。
CPS 網頁的內管理系統，架構於 Zope 與 CMF 上，適合於內容網站，或是企業內部或是外部的站台
Silva 也是一個內容管理系統，內容均以 XML 的格式儲存
CPS 和 Silva 應該都是基於 CMF 比較多的，但是目前中文的支援都比較不好
感言
效能還是蠻重要的，好像目前在大型的站台的運用，除了 Cache 還是 Cache，這對一些個人化的服務是一個缺點，一旦沒有太多的經費加伺服器，然後線上人數很多時，在沒有 Cache 的狀態，反應時間有一點點難過。
Zope 的發展，到了 Zope3 真的是變很多，如果各家 CMS 的產品也都可以共用不知道有多好，要是可以集合各家的專長和力量，一定可以做出更可怕的東西。
不過以 Plone 為基礎來開發，已經是很強的系統了，讓使用者有很多不同的體驗，也有許多其他的架構所沒有的優勢及彈性，在介面上 web，webdav，ftp，plonedesktop 還有 external editor 都是很好用的，這樣的內容管理系統也是很夠用了，不過還是希望可以再進步。
我愛白米
這一篇算是弔念台灣的司法，聲援白米小子的
白米真的是用了比較不適當的方式來表達他的想法，不過出發點都是為了別人，看看現今的台灣社會有多少人會為別人設想，抱玻璃娃娃的，被法官判自不量力。
真是覺得司法和法律好像是來亂的，無法保障真正的正義，經濟犯，一污，都是數十億，管他是政府買單，還是百姓，好像也沒什麼重判的案例，每一件案子都是中飽私囊，又有誰是為了別人的權益呢？
他真的犯錯了，他應該學國父孫中山先生憂國憂民，不捨百姓生於苦難當中，買刀買槍起義，才對
註：我真的很愛吃米飯啦，標準的飯桶