The Django Book

人物列表

让我们见识一下我们的成员和他们的项目。

Ned Batchelder is the lead engineer at Tabblo.com. Tabblo started life as a storytelling tool built around photo sharing, but it was recently bought by Hewlett-Packard for more wide-reaching purposes:

我们的web开发风格，以及我们连接虚拟世界与物理世界的方式，让HP看到了真正的价值，他们收购了我们，让我们可以将技术带给web上的其他站点。 Tabblo.com依然是一个伟大的故事讲述站点，同时，我们也忙于将我们最有趣的技术模块化并更换主机。

Johannes Beigel 是Brainbot Technologies AG的开发主管，Brainbots 面向公众的主要Django站点是 http://pediapress.com/, 你可以从那里订购维基百科的打印版。Johannes的团队目前正致力于一个称为Brainfiler的企业级知识管理软件。

Johannes 告诉我们，Brainfiler

tp3sYj <a href=”http://ijlsmchjrqqb.com/“>ijlsmchjrqqb</a>, [url=http://wwolzjfopsxb.com/]wwolzjfopsxb[/url], [link=http://ehluzfideanl.com/]ehluzfideanl[/link], http://ujxvaefmdiml.com/

David Cramer 是Curse的开发主管，他开发了Curse.com,一个致力于大型多人在线游戏(例如魔兽世界，网络创世纪等)的站点。

Curse.com是互联网上最大的用Django建成的站点之一:

我们每月大概有六千万到九千万的页面访问量，使用Django，我们页面访问量的峰值达到过一个月一亿三千万。我们是高度动态的以用户为中心的站点，我们为在线游戏玩家提供服务，特别是大型多人在线网络游戏。我们是全球最大的魔兽世界站点之一，我们始建于2005年，在2006年，我们扩展到魔兽世界以外的其他游戏。

Christian Hammond VMware (虚拟化软件的领头羊)的高级工程师，同时他也是Review Board(http://www.review-board.org/)的开发主管，Review Board是一个基于web的代码走查系统，它起源于VMware的一个内部项目，现在成了一个开源项目:

2006年底，David Trowbridge和我讨论了在VMware使用的代码走查流程，在将代码提交到源代码仓库之前，程序员要将改动的部分用邮件发出来让其他人审阅。在这个基于邮件的流程中，想跟踪某个感兴趣的代码走查就比较困难。因此，我们开始讨论这个问题的解决方案。

我并没有把想法写出来，而是直接开始编码。不久，Review Board诞生了，它可以帮助开发人员、代码审阅者及相关责任人方便地跟踪代码走查与更好的沟通。使用者可以直接在代码上做评注，而不是像原来那样在邮件中用文字模糊的指代某部分代码。代码与评注一起展现在系统中，开发者可以根据这些评注方便地对代码做出修改。

在VMware，Review Board的蔓延快得超乎想象，在短短几周内，已经有十来个团队使用它了。现在，这个项目已经不再局限于VMware内部了，我们希望有一天它可以走向开源，让更多的公司与项目使用它。

A0KWvQ <a href=”http://qllnukhkitqa.com/“>qllnukhkitqa</a>, [url=http://gexrhzhjvsab.com/]gexrhzhjvsab[/url], [link=http://kvpuwdrwoxgo.com/]kvpuwdrwoxgo[/link], http://rxkqpzjawlgr.com/

wimLHQ <a href=”http://xgclqztduggh.com/“>xgclqztduggh</a>, [url=http://mpirlevloyjq.com/]mpirlevloyjq[/url], [link=http://irrgjspblhth.com/]irrgjspblhth[/link], http://bkeaotspsavm.com/

为什么选择Django?

我们询问每一个开发人员，为什麽他决定用Django，究竟有什么其他的选择考虑，以及如何最终决定使用django。.

Ned Batchelder說:

在我加入 Tabblo 之前, Antonio Rodriguez (Tabblos 的创建者与 CTO) 对 Rails 和 Django 做了个测评, 发现两者都可以提供非常高效的快速构建环境。在两者的对比中，他发现，Django 更有技术含量，可以更容易的构建强壮的、可扩展的站点。另外，Python完善的生态系统使得Django具有强有力的社区支持。Tobblo的开发充分证明了以上观点。

Johannes Beigel說:

我们使用Python编码已经很多年了，不久我们开始使用Twisted框架，web方面自然就使用了Nevow. 然而很快，我们发现尽管Twisted提供了完美的集成，很多东西还是会略显笨重，它给我们灵活的开发流程造成了阻碍。

进行过一些内部讨论之后，很明显，Django是符合我们需求的最理想的web框架。

我们转向Django的最初动机是它的模板语法，但很快我们就发现Django中的其他特性也非常有用，Django一时炙手可热。

在做了几年并行开发与部署工作后（在一些客户站点的项目中Nevow依然在使用），我们得出了这样的结论：Djiango更轻量、更灵活，写出的代码更容易维护，也更有趣。

David Cramer 說:

我在2006年夏天听说了Django，那时我们正在忙于一个比较大的重构。研究了一下Django之后，它给我们留下了很深的印象，它提供很多功能，可以节省我们的时间，我们商量着，决定就用Django。马上，我们就开始编写第三版的代码了。

Christian Hammond說:

我在几个小的项目中尝试使用了Django，它给我的印象很深，它是基于Python的，我现在已经成了一个Python的爱好者。Django不仅使得编写网站或者Web应用很容易，而且它还可以保持代码的可维护性，通常这在php或者perl中是比较难做到的。根据这些经验，我不假思索的选择Django。

起步

由于Django还是一个比较新的工具，有经验的Django开发者还不是太多，让我们看看这些先行者们是怎么开始使用Django，以及他们有哪些经验可以分享给Django的新手。

Johannes Beigel說道:

我们一直在写c++与perl程序，切换到python之后，我们依然用c++来实现一些计算密集型的部分。

我们是这样学习Django的：照着教程做练习，阅读文档了解它都能做什么（只跟着教程做容易漏掉很多特性），努力去理解这些组件背后的基本概念，如middleware,request objects, database models, template tags, custom filters, forms,authorization, localization。在真正需要的时候，我们会去深入研究这些主题。

David Cramer談到:

官网上的文档很不错，时刻关注它。

Christian Hammond談到:

David和我之前对Django都有使用经验，即使那时还是受限的。我们从评论版的开发中学到了很多东西。我会建议新手去阅读精心编写的Django文档和你正在阅读的这本书，它们对于我们都是无价的。

我们不是非得向基督徒行贿来得到引用的权力。

qVPiIP <a href=”http://yttqrkvgoiin.com/“>yttqrkvgoiin</a>, [url=http://kxzaeecicatj.com/]kxzaeecicatj[/url], [link=http://hmnrgnjhuqmo.com/]hmnrgnjhuqmo[/link], http://ldqzqxdbeoxc.com/

虽然 Review Board 和 Tabblo 是白手起家开发起来的，其他的网站却是从现有代码移植而来。我们感兴趣的是了解这个移植的过程。

Johannes Beigel :

我们开始的时候从 Nevow 移植站点，但很快意识到必须更新太多概念性事物（包括在 UI 部分和应用服务器部分），因此我们转而从零开始，而将之前的代码主要用作参考。

David Cramer :

之前的站点用 PHP 编写而成。从 PHP 到 Python 的移植工作非常程式化。唯一的问题是你必须非常小心内存管理问题【由于 Django 进程运行时间比 PHP 进程（单循环）要长得多。】

现状

下面是一个关键问题：Django 是如何对待你的？我们对听见 Django 出错特别感兴趣——在撞南墙 之前 就知道所用工具的弱点所在是很重要的。

Ned Batchelder :

Django真正使我们能够满足我们需要的网络架构 作为热点用户,企业 ,现在作为hp的合作伙伴, 我们使用非常灵活的方式,使软件适应新的需求. 分离功能,模型,视图和控制器,MVC模块化,让我们可以方便的扩展和维护 而基于python的语言给了用户机会使用大量的已有库来解决 问题不必重复造轮子 感谢 PIL, PDFlib, ZSI, JSmin,

and BeautifulSoup

内存对象和数据库对象之间的关系是， in a few ways，Django 的使用中最难的部分。第一，Django的ORM并不能保证，对同一个数据库记录的两此引用是来自同一个Python对象，所以你可能会遇到这种情况：代码中的两个部分要修改同一数据库记录，而其中一个的数据是旧的。第二，Django 开发模型鼓励你在数据库对象的基础上建立你的数据对象。我们会发现更频繁的超时，更多地使用那些没有对应到数据库的数据对象，我们只好不再假定数据是保存在数据库里的。

对于一个有大量的、生命周期很长的代码库，花时间来anticipating你的数据存储和访问是有非常意义的。nd building some infrastructure to support those ways.

我们也增加了数据库迁移功能，这样开发人员就不必通过SQL脚本来更新数据库结构。开发人员可以通过写一个python函数的来更新数据库。当服务器重启的时候，这个更新会自动生效。

Johannes Beigel談到:

我们把Django看做是一个完美符合Pythonic思想的成功平台。所有事情都会像您期望的那样工作。

在我们的项目中一个需要花点时间来做的事情是调节全局 settings.py文件和目录或配置（为apps程序,templates模板,locale data本地化设置,或者其他的文件。）因为我们在部署一个高度模块化和可配置系统，项目中所有Django视图是类实例化的方法 But with the omnipotence of dynamic Python code, that was still possible.

aUTmui <a href=”http://kygcxffhbqdp.com/“>kygcxffhbqdp</a>, [url=http://qphaudolykxk.com/]qphaudolykxk[/url], [link=http://xwbahlmcsnmk.com/]xwbahlmcsnmk[/link], http://zkapcuytecti.com/

一个周末，我们被要求搞出一个大型数据库应用程序。如果用php的话，做出这样一个原型网站我们大概要花一到两周时间。这时候我们发现了Django

x1JL2r <a href=”http://bjzzhfulbyfy.com/“>bjzzhfulbyfy</a>, [url=http://kljpyuunfsar.com/]kljpyuunfsar[/url], [link=http://vptdhtnlmjvp.com/]vptdhtnlmjvp[/link], http://xxxsdfebyikd.com/

在2007年5月份，暴雪（魔兽世界的创造公司）释出了另外一个比较大的补丁。就像我们刚启动Django项目的11月份时候他们做的一样。第一件闪过我们脑海的事情是，我们在11月份的时候差点没当机。这次和上次差不多，我们的网站应该能顶住压力。大概12个小时以后我们才发现服务器开始受到影响。问题再次被提出：Django是不是我们网站最好的解决方案？

感谢来自社区的很多强大的支持，在几天后的一个深夜，我们为网站部署了一些修复补丁。The changes (which hopefully have been rolled back into Django by the time this book is released) managed to completely reassure everyone that while not everyone needs to be able to do 300 Web requests per second, the people who do, can, with Django.

Christian Hammond提及:

Django允許我們非常快速地建造一個復習版，並驅使我們能透過URL，VIEW，和樣板維持著條理，有架構的，靠著所提供的內建元素，如權限管理小程式，內建的快取，和資料庫的簡化。這些功能，絕大部分都讓我們運行的很有效率。

做為一個動態[網站應用程式]，我們必須寫一堆JavaScript 代碼。這是個Django 沒法實際上幫我們很多忙的部分。Django 的樣板，樣板的標籤，過濾器，表單的支持都是超棒的，但是沒有辦法簡化JavaScript 代碼。當我們想要使用一個特別的樣板或是過濾器的時候，偏偏沒法同時使用JavaScript 代碼。我個人將會樂於看見一些有創意的解法將這部分含入JavaScript 代碼。

团队结构

常常，成功的專案主要是因為他們的團隊，都不是他們所選的技術，我們詢問我們的panel他們的團隊是如何運做，他們是用什麼工具和技術來讓工作上軌道。

Ned Batchelder說:

一個非常標準的網頁開創環境:Trac/SVN,良好的程式員。我們有一個測式主機，一個產品主機，一個ad hoc發布指令稿。就這些。

記憶體快取很重要。

Johannes Beigel說:

We use Trac as our bug tracker and wiki and have recently switched from using Subversion+SVK to Mercurial (a Python-written distributed version- control system that handles branching/merging like a charm).

我想我們有一個非常敏捷的開發過程，但是我們沒有遵守嚴格的方法論像極限編程寫的(即使我們借用了很多點子從那裏)。我們比較像是Pragmatic程式員。

我们有一个自动编译系统（基于定制过的SCons）和对几乎所有东西的单元测试。

David Cramer論及:

我们的团队有4个web开发人员构成，这4个人都在同一个办公室工作，所以我们彼此沟通交流是很方便和容易的。我们彼此共同使用一些工具，如：SVN和Trac.

Christian Hammond述道:

復習板實際上有兩個主要開發者(我和David Trowbridge)和一堆貢獻者。我們將站點放在Google Code 利用他們的Subversion源碼倉庫，事件追蹤器，和維基。我們實際上使用復習版是要復習我們的改變。我們先在自己的本地主機測試，也有手動和單元測試。我們的使用者在VMware上每天用Review Board提供一堆有用的回饋和臭蟲報告，讓我們可以試著這些成果整合進來。

jOEx6u <a href=”http://wdvyaxaohnin.com/“>wdvyaxaohnin</a>, [url=http://scjqbwipafoe.com/]scjqbwipafoe[/url], [link=http://hizygvuirqpt.com/]hizygvuirqpt[/link], http://mgqxipizszyi.com/

Django的开发者很严肃认真的对待如何简化部署及系统的扩展(scaling)，因此我们重视很乐意的听到现实情况里有关系统部署和拓展（scaling）的一些让你麻烦和很难处理的问题。

Ned Batchelder提及:

我們已經使用快取在查詢和回應層，藉此來加快回應時間。我們有一個古典的設定組態方式:一個多重的主機，很多個應用伺服器，一個資料庫主機。目前這種架構運作良好，因為我們可以使用快取在應用伺服器來避免資料庫存取，然後加上應用伺服器，就需求上來應付流量

Johannes Beigel言及:

Linux主機，尤其是偏好Debian,搭載很多的(gigs)記憶，Lighttpd當作網站伺服器，Pound 當作HTTPS 前端和負載平衡器，假如需要的話，而Memcached當做快取。SQLite 用做小型的資料庫，假如資料量成長太快就用 Postgres ，高度的規格化客製資料庫是我們的尋找和知識管理的元件。

David Cramer提及:

我们的结构还有待讨论，但目前就是这个样子的。

當一個使用者要求這個網站，它們會被傳送到Squid (使用lighttpd)的叢集主機。在那裏，主機會檢查是否使用已經登入。假如不是，他們會招待一個快取頁面。一個已登入的使用者會被引導到一個網站主機(跑著lighttpd加上mod_python(每一個都擁有大量的記憶體))構成的叢集，依靠者分散式的Memcached系統和超強的MySQL 資料庫主機。靜態的內容是存放在由lighttpd 組成的叢集。多媒體，如大的影音檔，通常是放在用超小的Django 加上lighttpd 和 fastcgi。現在這些都移往，推向所有多某體到一個服務，類似Amazons S3。

Christian Hammond

这里现在有两个主要的产品级服务器。一个是运行在VMware里，包括了一个运行在VMware ESX里的Ubuntu虚拟机。我们使用MySQL作为数据库，Memcached作为后端缓存，和流行的Apache作为Web服务器。我们有一些在我们需要的时候能够有助于我们扩大规模的强劲服务器。当我们的用户增多的时候，我们可以把MySQ或者Memcached移到其他的虚拟机上。

第二个生产服务器就是用于Review Board的那个。它的设置和虚拟机里面的那个是完全一样的，唯一差别就是虚拟机是运行在VMware服务器上的。