看了limodou 在上期程式員雜志推薦的Python Django架構，于是選擇Django用來書寫熱點自動發現的Web界面。Python本身的優勢、友好的URL、友善的template、MVC，都是讓書寫Django順暢|好心情的原因。
但是再往下，還是有點擔心。一是Ajax，尋找了一圈，也就是“Ajax With Django”這篇文章給出的資源還靠譜；二是将來更新的問題。
對于Ajax和Django的內建問題，到底選擇內建Dojo，還是選擇內建JQuery，還是像TurboGears一樣直接用MochiKit？11月3日，哈哈，James Bennett回答很酷：
“
On 11/3/06, Enquest <[EMAIL PROTECTED]> wrote:
> What would it take to integrate jquery to Django?
> Just like now is happening with Dojo... I think however jquery is a
> better lib ...
Dojo integration was a fleeting, now-discarded idea. Django will not
be "integrating" any JS toolkit. One good reason for this is evident
in your post: no matter which one was chosen, someone would always be thinking that some other toolkit would have been better.”
是啊，總有人會不滿意的。但。。。他們就一直遵循這個原則“make the simple things easy and the complex things possible.”？
大陸這邊可能由于blogspot被封的原因，很少有人能看到11月9日台北thegive寫的《從 Django 看 Ruby on Rails 成功的原因》。是啊，是及時切換到RoR，還是等待Django，還是TurboGears？這是一個問題。
Ian Maurer倒是給出了TurboGears和Django的比較，請看後面的資源二。
雖然limodou推出了《Django Step by Step》，但似乎Python的Web架構介紹遠遠不如RoR的多和精彩。
資源一：
從 Django 看 Ruby on Rails 成功的原因
這裡有一份對岸 cookoo 寫的對Django的遺憾，真是一篇好文章，裡面描寫到 Django 如何錯失大鳴大放的機會。我看完之後，突然發現 cookoo 這篇文章藉由 Django 的缺點，他也順便偷偷分析了Ruby on Rails 成功的原因。大家可以來看看
- django的原始碼改動頻繁
- ORM API 繁瑣（後來按ActiveRecord風格重寫）
- 沒有整合的測試架構
- 沒出書，檔案相比Rails缺之甚多
- python内部有人對django完全獨立的一套full-stack系統有不同看法，又搞了很多别的架構（比如turbogears）
- django對AJAX熱潮無動于衷
相比起來
- Rails Team 相當穩定，很少大改
- ORM 太優美了
- 出的書籍一級棒，檔案也相當多
- Ruby 因為社群小，超級團結
- Full Stack 架構，Unit Test 内建
- RJS 趕上 AJAX 熱潮，炒熱不少話題
雖然 Open Source 技術為本，但是撇開 Ruby on Rails 優秀的技術不談。
- 假如大家都不寫檔案，Ruby on Rails 的檔案不夠多的話，有人敢用一個不熟悉的語言嗎？
- 沒有将 Ruby 社群主力放在 Rails 身上，寫得出那麼多 API 嗎？
- 沒有團結的團隊，人員來來去去，吵來吵去的團隊作得出好作品嗎？
- 沒有 DHH 肯花寫程式以外的時間推銷 Rails ，并且花衆多時間寫出一本Agile Web Development with Rails，會更多人願意花時間去學習一個聽都沒聽過，也沒有公司support 的 Ruby on Rails 嗎？
一 向是一盤散沙的 Open Source 社群可以仔細思考一下 Ruby on Rails 帶給大家的啟示。Ruby 社群向心力強，不分散力量，又懂得出書以及掌握時勢用RJS炒熱話題。這說明，團隊管理好，向心力強，營銷強，正是 Ruby on Rails 擴散那麼快速的主因。其實，這不正是一個好商業團隊應該具備的特質嗎？
資源二：
：TurboGears 和 Django 的比較
Django 和 TurboGears 都是 MVC 風格的架構，開發人員可以利用這些技術使用 Python 語言快速開發 Web 站點。為了選擇最适合您的需求的技術，請考慮以下差別：
- 背景：
這兩個項目與 Ruby on Rails 一樣，都是從現有的應用程式中提取出來釋出到開源社群中的。Django 的曆史比較長，來源于一個每天服務于數百萬次頁面檢視請求的線上報紙服務。TurboGears 是從一個胖客戶機 —— RSS News Reader 應用程式，目前仍在開發中—— 中提取出來的。TurboGears 的社群驅動力比 Django 更好，因為它是在現有開源元件上建立起來的。
這兩個項目之間背景的差異導緻了不同的項目優先級。Django 項目來源于迅速變化的線上出版業，它重點關注的是一個可以快速建構并修改基于内容的應用程式的架構。TurboGears 項目的基礎是消費産品，重點關注的是胖客戶機應用程式和可插入體系架構。
- URLs：
TurboGears 的請求分發機制通過控制器類和方法名進行路由。在添加新控制器類或方法之後，它們就自動變為可用的了。如果我們需要修改執行給定控制器的路徑，就需要對代碼結構重新進行配置。反之，Django 使用了一個單獨的基于正規表達式的配置檔案将 URL 映射為底層代碼，這樣就降低了 URL 路徑結構與實際實作之間的耦合程度。
TurboGears 系統的設定比 Django 更加快捷，因為它隻需要一個
expose
操作讓新頁面變成可用即可。然而，Django 配置系統可以進行最大限度的控制和靈活性。在發生重大變化之後，Django URL 可以簡單地重新映射到應用程式上。這個幫助防止由于舊書簽或緩存搜尋引擎結果引起的 “連結失效” 的情況。“連結失效” 會對 Django 設計用來建立的基于内容的Web 站點的通信級和可用性造成很大的影響。
- 代碼重用：
TurboGears 團隊将他們的項目稱為大架構，這樣清晰地表達了 TG 是一個由現有的很多元件構成的項目這一思想。TurboGears 團隊選擇并內建了最好的開源代碼，而不是從頭重新開始編寫。TurboGears 架構的另一個優勢是這是一個由很多社群構成的大項目。TG 現在功能已經非常強大，正在強力促進大家對構成 TurboGears 核心元件的興趣和參與。這樣可以起到水漲船高的效果。
另外一方面，Django 是在 2003 年建立的，當時 Python 元件的狀态還不像現在一樣穩定。Django Web 棧是從頭開始建立的，最終的結果是獲得了一個穩定的架構，這個架構已經被用來建立了多個每天處理數百萬點選率的 Web 站點。然而，有些人評論說 Django 項目可能會由于缺乏代碼的重用而遭遇 NIH（Not Invented Here）問題。Django 團隊的立場是在 Python 中從頭建立一個架構所需要的工作不會比将現有的元件拼裝在一起更困難，這樣最終可以生成一個更統一的架構。
- JavaScript：
TurboGears 在自己的架構中首先提供了 MochiKit，這是一個 JavaScript 庫。這個團隊還建立了一個部件庫，它可以充分利用 JavaScript 建立豐富的表單元素。這顯示了胖客戶機（Ajax）開發在 TurboGears 世界中是多麼重要。Django 團隊沒有選擇使用一個JavaScript 庫來預設地包含自己的架構，但是他們已經對這種可能性展開了讨論。這兩個項目都不會限制我們使用任何 JavaScript 庫。
- 管理工具：
這兩個項目都有管理接口。Django 管理工具的目标使用者是那些需要良好資料入口工具的終端使用者，這樣每次向應用程式中添加新功能時就不需要對工具進行定制了。另一方面，TurboGears 管理工具重點關注的是開發人員的需要：它為開發人員提供了一組設計工具，以及一個基本的資料庫檢視器和編輯器。
- 許可證：
由于 Django 是從頭開始建立的，是以整個項目都使用的是開源許可證（BSD 許可證）。TurboGears 是由多個項目構成的，使用了多個許可證。SQLObject（ORM 工具）是使用 LGPL（Lesser General Public License）保護的，這說明對 SQLObject 進行的任何直接修改都需要貢獻回這個項目。這個許可證并不 要求使用它的應用程式也開放源代碼。不過有些公司會禁止使用受 LGPL 許可證保護的軟體。在這種情況下，我們可以考慮使用SQLAlchemy，它是 TG 社群大力支援的另外一個 ORM 工具。
- 實際例子：
請參見 參考資料 部分給出的已知的 Django 和 TurboGears 驅動的站點的清單。這些實際的應用程式展示了我們可以使用每個工具實作什麼功能。
資源三：
Tr Ruby 顯示 AJAX 可怕之處的 Demo site，你可以在 Web 上面打入任何 ruby command，他也會立刻顯示 irb 的結果。
資源四:
大公司對于 Ruby and Ruby on Rails 的動作清單
國際大廠對于新技術的動作一向保守，不過這一年來，他們對于 Ruby and Ruby on Rails 的動作從觀望，似乎變成了開始小幅買進了。
- SUN：Sun 雇用了 JRuby 核心開發者
- Amazon：Amazon疑似加碼 37 Signal ？
- Yahoo： Yahoo Developer Network 也開始加入 Ruby 選項
- Microsoft：MS 聘了 RubyCLR 創造者
- Google： Google 買下用 Ruby on Rails 寫的Measure Map 。這家公司也擁有 Rails Core Team其中一員Nicholas Seckar。
- IBM：IBM采用 Ruby on Rails 來開發 Koala Project。
藉由一連串的 Ruby 大爆發以及 Ruby 書籍銷售長紅，大家或多或少都看到 Ruby and Ruby on Rails 的能力跟潛力。外資會不會持續有加碼動作呢？我們可以等 thegiive 老師持續為您報明牌 XD