Official Python Planet@Taiwan

耶，新版的 jQuery 出來了，算是一個修正的版本，效能有不少的提昇，找時間，來升級測試一下

連結: http://jquery.com/blog/2007/08/24/jquery-114-faster-more-tests-ready-for-12/

鄉民們，衝壓

現在做一個網站好像是小學生做的事情一樣，好像一點難度也沒有，聽一聽鄰居大嬸說，我們家小朋友，國小四年級就會做了，真的這麼簡單嗎，為什麼一大堆的網頁不符合標準，一大堆網站用 Firefox 看起來就是怪怪的

技術高深不可測，學歷比天還高的專家，或是某公司會說，耗資多少，做出 WEB X.0 的網站，但是，我要說的是，做網站，很簡單，要做好，又優美的很難，至少以我自己龜毛的個性來看

我想大聲說

可不可以 URL 的連結盡量有意義的，不要超過像是 512 的字，裡面不要有中文字，如果真的要有，能不能先轉好碼，以下有一個血淋淋的範例，各位就知道我在說什麼了，對不起，我知道這樣很傷眼睛，如下

http://xxx.xxx.xxx.tw/object/detail.php?city=台北市&objectid=10111831780&storeid=A0111&pagekind=1&city_2=&code_2=&way=&oneself=&park=&life=&keyword=&line=&station=&station_2=&tablename=&school=&road=&city=台北市&code=&kind=&type=&type_2=&layout=-1&layout_2=no&price=0&price_2=upward&ping=0&ping_2=no&way=&notindex=1&pagekind=1&direction_check=&direction=&control_check=&control=&stall_check=&stall=&mrt_check=&school_check=&park_check=&life_check=&today=&orderby=order%20by%20movie%20desc,%A5Z%B5n%B0%E2%BB%F9%20asc

還有重複的變數，真是夠了，不然就是，URL 裡面還有空白，或是斷行的，看了，差點眼淚掉下來

還有一件事很想說，很多的網站花了很多的技術，效能和時間，在收集，或是保護資料，讓您要一直停在網站上，找不到資料，然後看了一大堆廣告，或是動不動就要您註冊成會員，註冊成會員以後，所有的產出，責任都是會員的，所有的產出收益都是網站的，感覺有點邪惡 ……

在有 Database 的應用裡，寫多了 SQL（Structure Query Language） 會覺得他是一種累贅，讓你的邏輯不斷的，在程式語言，及 SQL 之間轉換，所以後來，就有了，很流行的 Database ORM (Object Relational Mapper) 來幫助我們開發，一來，可以用相同的邏輯思考方式，用物件的方式，去對應資料庫的元件，一來，可以有資料庫的抽象層，對一個系統的開發有很大的助益，但是，如果，要寫的 code ，比一般的 SQL 還要複雜，還要隴長，你該怎麼作呢？

寫回去 SQL 嗎？還是就去適應這樣的物件對應方式？

這也許沒有一定的答案，不過，我來分享一下，我用 Django ORM 到目前所遇到的問題，和解決的方法，所以，裡面有一些是個人好惡的選擇

• 現在Unicode 的branch 還沒有 merge 到 truck 裡，如果用 wxPython unicode 的版本，自己要處理，string to unicode 及 unicode to string 的問題
• ManytoManyField 的欄位，Q object OR 沒有辦法套用，在 djangosnippets 有解決辦法，連結是 http://www.djangosnippets.org/tags/m2m/ 不過還是希望有官方的
• 目前如果是用 truk 的 Django， 用 groupu_by() 只能在對應該物件的 database table 裡分 group，無法使用別的欄位作 group_by 的條件，在別的 branch 有解決了，可是基於，愛乾淨不要混用，太多 branch 的原則，我是用 extra 的解法，算是走 SQL 的回頭路，不過， "GROUP BY" 在 SQL 也是標準的語法，不至於破壞了資料庫的抽象層，不過，如果有用 GROUP BY 的話，不可以混用 filter 的功能，不然，產生的 SQL 語法不對，我們要決定所有的 where 條件，第一個例子，是有 where 的 group by，第二個，是沒有 whehe 可是要強加 grouop by 在不同欄位，這樣就還可以在 DB 上只用一個 query，在 Django 上還是傳回 QuerySet 的作法，不過，這一個 QuerySet 不可以再用 filter 的方式，因為這樣會讓 group by 及 where 的位置錯了

範例1:

qset = Stock.objects.extra(select={'totalsum':'sum(volume)'},where=["customer_id='%s' group by product_id" %(customerid)])

範例2:

qset = Stock.objects.extra(select={'totalsum':'sum(volume)'},where=["1 group by product_id"])

以上，是目前，我遇到的一些限制，及解決辦法，也許對您有參考的價值，在 Desktop 的應用程式上， 如果，還有更複雜的的需求， SQLAlchemy 應該是不錯的選擇

想起以前用 Zope 及 Plone 的美好時光，文件是使用 ExternalEditor 編輯的， 對編輯器有固執堅持的人，很難接受在網頁上的一個 TEXTAREA，秉持著，細心，耐心，安於現狀的原則，乖乖的敲打文件內容，可是Web AP 沒有像 Zope 或是 Plone 一樣整合 ExternalEditor 怎麼辦？

哈哈，答案來了，請愛用 FireFox，裝個套件吧！

Mozex http://mozex.mozdev.org/

看是要 VIM 還是 EMACS 還是有人覺得電腦效能太強，一定想開個 WORD，當然，我們這窮苦人家的小孩，是買不起 Word 這一種軟體的，總之要用什麼就用什麼

你長期都是盯著美元匯率看嗎？

要吃大虧了，我想全台灣都應該改使用歐元了，在過去的三個月裡,台幣相對歐元已經貶值 15%了，不算利息上的差異，這代表,過去三個月,歐洲人除了，本來就賺的比我們多外，他們再加薪 16% 左右，你能三個月加薪 16%嗎？ 新台幣可以收起來了，再一次見視到錯誤的政策比貪污嚴重的可怕，照這種速度，新台幣相對歐元很快就變成壁紙了，而且相對其他的外幣也沒好到哪去，澳幣，紐幣都一樣

為什麼新台幣這麼弱勢呢？

• 政府刻意的政策，寬鬆資金，要刺激民間投資，可以藉此降低企業負擔
• 要刺激經濟成長，達成拼經濟的口號
• 要刺激房地產，炒地皮，商人才有錢賺
• 政府的財政惡化，所以大家都不要新台幣
• 有錢人拼了老命，把錢送到國外投資

什麼是有改善空間的

• 民間的投資意願低落，主要不是因為利率原因，而是朝野惡鬥，經濟政策舉棋不定
• 有通膨隱憂，可是政府視而不見
• 以為利用龐大的公共建設可以解決一切問題，財政日漸惡化
• 平均所得無法往上成長，內需無力

以上是對經濟很無知的我，發的牢騷，感謝收看

查詢外匯走勢 http://rate.bot.com.tw/Pages/UIP004/UIP004INQ1.aspx?lang=zh-TW

每個人做出選擇都有許多的原因，我來說說我的。

話說去年秋末的時候，手上用 TurboGears 寫的東西，就快完成了，在一個天氣不錯的週末，趕著回家，notebook 掉了，泣，裡面，裝著我三四個月的努力，最後，當然是沒有像電視報導那樣，被善心人士撿到送到警察局，所以證件重辦，電腦重買，系統重寫，要重寫的時候，TurboGears 轉變的非常快，SQLObject 到 SQLAlchemy，範本系統則是 Kid 到 Genshi，而且開發進行的飛快，API 也不確定，所以那時候就選了 Django 來重寫，沒錯，我選的原因是，notebook 掉了，當時沒有時間等 API 穩定了

這一個真實的例子，告訴我們 Version Control 的重要，就算是只有一個人在寫也不例外

最令人高興的事，這兩個專案，都一直有進步

參考資料

http://www.turbogears.org/ TurboGears

http://www.djangoproject.com/ Django

最近作一個公司內部簡單的應用，希望不要讓使用者再去記憶更多密碼，所以 POP3Backend 於是誕生，可以直接用公司的 POP3 Server 來作認證，會先試試 POP SSL 來連，不行才用一般的 POP 連結，真的是很短啦，有一點陽春，用了一個需外裝的 python dns 模組，來查網域的 MX 資料，還有很大的改善空間，不過還是可用啦，一樣，版權沒有，自己取用，責任自負

雖然也很想用 LDAP，不過，內部系統雜亂的歷史包袱，還一時改變不了，還是先撐一下吧，說到認證，不免要抱怨一下，什麼時候，台灣才有正式的非商業，OpenID service provider 壓

連結在這 http://www.djangosnippets.org/snippets/203/

參考資料

http://www.carthage.edu/webdev/?p=12 ，LDAP Authentication in Django with Backends http://www.djangoproject.com/documentation/authentication/ ，User authentication in Django

對政府的拼經濟的方向，真的非常憂心，拼出了，十年勞工，基本工資不變，大學畢業生，起薪比十年前差，先不管是不是部份媒體刻意在唱哀，台北的房價確創下歷史新高，經濟沒拼成，倒把房價拼上去了，說政府，還有民代是最大的炒手，一點也不為過吧，像是，最近的樂生事件，帶著民眾去抗議的民代，個個的都說是為了捷運線居民的福祉，但是又有哪一個沒有建商色彩呢，沿著捷運線的新建案，又有誰沒有關係呢？大家都是幕後的金主吧，如果，這麼多的國有地都要釋出給建商蓋豪宅的話，那直接政府發包，自建自售好了

http://www.businessweekly.com.tw/webarticle.php?id=22163

這是一篇商業週刊的文章，值得一讀，台灣的教育，及未來，教育經費，幾乎全用在人事支出，尤其是最後所說得，

苦不能苦孩子 ，窮不能窮教育

若無法讓教育的歸教育，福利的歸福利，台灣教育經費背後失衡的情況繼續下去，未來我們孩子究竟會成為跨國菁英，還是國際台勞？令人不敢想像。

果然，自己又當了一次小白，我錯怪了 Django

原來是自己修改了 mysql backend 的 base.py 才會造成怪怪的編碼問題，精神不好的時候，還是，看看資料，想想計畫，不要寫太多東西

最近在做的東西，是用 MySQL （懶，已經有 MySQL了，不想再裝 PostgreSQL 了），在資料庫上預設用 UTF8 編碼，在 Django 上，如果 DATABASE_ENGINE = ‘mysql’，第一個 connection 都會下， SET NAMES utf8; 然後，之後的 Query 都會自己加 SET NAMES latin1; 大多時候，是正常，不過，有時是亂碼，奇怪就在，我把這一個有問題的結果，print 出來除錯時，螢幕是亂碼，可是在網頁上又可以變正常，真想掉眼淚

這種情形，一開始用 Sqlite 開發的時候，也沒有，所以開發環境，還是跟實際一模一樣比較好

真是很怪的情形，令我頭痛好幾個晚上，有點像是靈異現象了

不過還好試一下舊的mysql engine ，還可以用，而且不會有這種怪情形，他只有會在connection 時下， SET NAMES utf8; 之後的 Query 不會加 SET NAMES latin1

暫時用這一個好了，設定 settings.py 裡改成 DATABASE_ENGINE = ‘mysql_old’

作業環境，Debian_etch，python2.4.4，python-mysqldb-1.2.1-p2-4，mysql-server-5.0.32，Django svn 4866