今天，我要介紹Python網頁開發的標準: WSGI，我個人在看見這類英文縮寫時，都一定會試著去記住它的全寫，因為縮寫本身一點意義都沒有，難以記憶，WSGI的全寫是』Web Server Gateway Interface『，它的發音有點像是whiskey，光知道這個名字還是很難理解這到底是用來做什麼用的，簡單的來說，它是Python定義網頁程式和伺服器溝通的介面，如果你有寫過CGI (Common Gateway Interface)，它的作用基本上就是和CGI類似的功用，定義一個標準的溝通方式，讓你寫的程式可以和伺服器溝通，但是WSGI不是設計用來給任何語言使用的，它是設計給Python用的，而它其實是基於CGI的延伸，在Python的部份進一步做更多的定義，而因為他是基於CGI，所以它也可以和CGI的介面相容，只要透過一個轉接器，就能把WSGI的程式接到CGI，說了這麼多，相信大部份人對於WSGI是什麼還是一頭霧水，會有一堆疑問，為什麼有了CGI還要有WSGI? Middleware又是什麼? 這很正常，我一開始也對WSGI一點概念都沒有，接下來我們就來介紹WSGI的特色。
Posts Tagged ‘TurboGears’
化整為零的次世代網頁開發標準: WSGI
一月 27th, 2010以前的PHP有很多缺陷
一月 6th, 2010有人在plurk上PO了一篇文章的連結，PHP 開發迷思 (三) – PHP 很糟糕？，因為我不認同那樣的看法，所以我回覆說php很爛，當你說一個語言很爛時，就要有心理準備有人準備要跟你戰了，果然有人不認同我的說法，當然任何人都可以不認同我所說的，而且好和爛是很主觀的，同時也是是相對的，但是我所說的是有根據的，說php爛不是我一個人的說法，而是已經被說到爛掉的說法，很多比我有經驗多的網頁程式設計師都異口同聲的說PHP很爛，為了解釋為什麼我認為PHP很爛(我在本文指的爛是指語言設計上的眾多嚴重缺陷)，我寫了這篇文章
更新:
我承認這篇寫得有點偏激，也是以前的觀點，也是在發洩以前對PHP的不滿，我沒有寫較新的PHP，所以我收回PHP很爛，改成以前的PHP有很多缺陷，我想表達的是一款語言的很多缺陷，而且是在以前的缺陷，現在PHP確實有改進很多，所以我寫了一篇 如何評估比較程式語言
另外我想表達的一件事是，當有人說你用的程式語言有問題時，為什麼一定要這麼抓狂呢? 如果一個程式語言它的缺陷沒有人罵，大家都愛語言如命，那麼語言的開發者或團隊要如何知道這語言要改進什麼呢? PHP有很多缺陷是事實，然而說出來很多人可能就不高興，然而我選擇用較激烈的字眼是因為他改進實在太慢了，我們可以看到以前的Magic quote、unicode問題等等，至今都仍未解決，要php6才會解決，這些問題不是只有我覺得很糟，而是我發現很多人都跟我一樣覺得這太差了，我每次罵PHP都真的很希望他在下一個版本就把這些鳥問題解決掉，但以我之前的經驗它都讓我失望，所以我怨念很深，這篇文章寫起來也特別偏激，但我想表達的是，我說PHP爛某種程度是希望他變好，那你可能會問，我為什麼不說Python爛，然後哪裡爛，很簡單的原因是我太喜歡Python，當你很喜歡一個東西時你是看不見這東西的缺點，如果有人說Python爛，我覺得很好，我想知道他有哪些缺陷，是我沒看到的
除此之外，對於初學者來說，PHP的低門檻讓他成為吸引新手的蜜罐，而很多人都只知道PHP可以寫網頁，但是不知道其實所有程式語言都能寫網頁，我希望透過罵PHP也能讓更多人知道其實還有更多選擇，但其實這會讓人覺得反感，我在這背後目的是希望其它語言能夠有更多人使用，有競爭才有進步，而對於國內大部份人都只用PHP在刻網頁我也覺得很失望，我同時也希望讓大家知道其實網頁的技術現在已經很先進了，很少有人使用框架等次世代的網頁技術，所以有興趣也可以看一些較新的技術，而不是土法煉鋼
別讓危險成為預設的行為，讓危險的行為比安全的行為更麻煩
十二月 13th, 2008危險的行為
對於寫程式而言，很多預設的行為都是相當危險的，舉一些最常見的例子SQL Injection、XSS、Buffer overflow，我們可以從這些幾個最常出現被攻擊的類形，都有一個共同的特點，就是它們通常都是因為預設的行為很危險，我們一個一個來看
TurboGears的cache decorator
十月 27th, 2008問題
今天在寫TurboGears網頁時，因為遇到用matplotlib產生的圖片
@expose_matplot_figure
def figure(self, id):
return dict(figure=pieFigure(id), dpi=75)如果每次都重新產生一張新圖片，流量大時對主機是件很浪費資源的事情，理所當然第一個想到的就是cache，而cache要能知道有什麼東西改變了是否需要重新產生，而最好能夠不用為了每個exposed的頁面寫一個cache，因此最好的辦法就是用decorator來使用，可以丟函數進去來判斷是否是一樣的東西，是否需要重新產生等等，正當我要開始寫時…
替代Plone的Python CMS列表
十月 2nd, 2008Plone真的是怪物
當收到來自WebFaction的回信後，更令人驚訝的事實
At this point, PHP applications are not counted towards your memory
usage. If you look at the memory output in the notice, you will see that
it’s just Zope (Plone).
原先我一直以為超過記憶體限制是因為PHP的關係，但是他們說PHP的記憶體使用並不列入計算，我回頭去看他們寄來的記錄上的確只有Plone的記憶體使用，所以驚人的事實就是
Zope + Plone吃掉了超過 171 MB的記憶體!
我並不清楚是何種情況讓Plone吃掉這麼多記憶體，在這之前都沒有超過記憶體的情況發生，但是這樣飢餓的怪物真叫人害怕
其它選擇
為了向這頭怪獸說不，在他減肥成功之前，我決定尋找其它解決方案，相較於PHP，Python的CMS就顯得較少且沒有相當成功，最廣為人知的似乎也只有Plone，其它是新興的、或是更少為人知的CMS，以下是我找到的其它選擇
