Форум программистов [Powered by Invision Power Board]

Максим Ищенко о TG

http://www.developers.org.ua/archives/max/2005/12/16/turbogears-razrabatyivaem-veb-prilozheniya-na-python/

Цитата

TurboGears: разрабатываем веб-приложения на Python
Грудень 16th, 2005 by Max
Опубліковано в: Технологии, Инструменты, Web

Иван Сагалаев с увлечением взялся рассказывать о Django - среде для разработки веб-приложений на Питоне. Подстегнутые популярностью Ruby on Rails, Python разработчики, похоже, кинулись готовить достойный ответ. Точнее, ответы. smile

Я тоже определился с выбором, только в пользу TurboGears. Почему не django или что-то другое?

Во-первых, разработчик(и) TurboGears не стали изобретать велосипед, а взяли готовые, зарекомендовавшие себя компоненты: MochiKit, Kid, CherryPy, SQLObject. Это дает не только внушительный объем функциональности, но и доступ к сложившимся вокруг этих проектов коммьюнити. Во-вторых, мне понравился исходный код, организация проект и “первая производная” (а.к.а вектор развития). Ну и наконец - не хочу повторяться. Пусть Иван Салагаев описывает Django, а я буду писать о TurboGears (если это кому-то интересно).

ЗЫ: К “промышленному” использованию TurboGears пока не готов, ИМО, так что если вы ищите готовую среду для разработки веб-проекта с конкретными сроками лучше посмотрите что-то другое. Ruby on Rails, к примеру. smile

Иван Сагалаев о Django

http://softwaremaniacs.org/blog/2005/12/08/django/

Цитата

Давно хочу написать про Django. В итоге, вот, сподвигся, прочитав песню о Ruby и Rails на Julik Live.

Многим людям, особенно занимающимся программированием, дизайном и прочей деятельностью, связанной с hi-tech творчеством, думаю, знакомо ощущение, что ты в этом мире катастрофически не успеваешь за временем. Что, в общем-то, и понятно: благодаря интернету творческим людям делиться интересными мыслями становится крайне просто. Усваивать такое количество информации одному человеку почти нереально, поэтому все мы, наверное, осознанно или нет, выработали какие-то механизмы фильтрации, по поводу чего можно просто подумать “да, прикольно…”, а чем заинтересоваться поподробнее.

У меня в качестве такого сильного фильтрующего признака, как я недавно осознал, выступает рекомендация чего-либо со стороны блогеров, которых я считаю большими профессионалами в своей области. Поэтому когда уважаемый мной Саймон Виллисон написал о новом веб-фреймворке Django, я таки пошел читать, что это такое.

“Таки” в словах “таки пошел” означает, что я, в общем-то, не особенно западаю на объявления о новых веб-фреймворках. Действительно их существует просто дикое количество. Такое ощущение, что каждый веб-разработчик считает своим святым предназначением выдрать куски кода из какого-то своего очередного сайта и объявить их тулкитом, фреймворком, CMS или чем там еще… Документация не прилагается, рефакторинг — “планируется”. Нет, безусловно есть и хорошие, и даже, наверное, очень много. Но обилие плохих поделок сильно снижает вероятность благополучного исхода знакомства.

Но с Django у меня вышло иначе. Я не только про него прочитал, но и решил после этого даже с ним поработать! Что еще более невероятно, я, который может с легкостью рассказать, чем я по уши загружен на ближайшее десятилетие, все же начал с ним работать. И уж совсем из области фантастики то, что все не остановилось на уровне прототипа в моем ноутбуке, а движется к завершению в виде коммерческого проекта фотосервиса (не спрашивайте подробней, что за проект: не могу говорить).
Ruby on Rails

Если вы занимаетесь web-разработкой, умеете пользоваться интернетом и не считаете, что ASP.NET или PHP — самое последнее слово в веб-технологиях, то вы слышали о “Ruby on Rails“. Трудно было не слышать, потому что восторгов и отзывов по поводу того, как просто, быстро и без потери масштабируемости можно писать на RoR веб-приложения, в сети — море.

Меня огорчало только одно: какое-то время назад, решив поменять ориентацию, я заинтересовался не Ruby, а Python’ом. И возможно, я уже слишком “старый” по программерским меркам, поэтому начинать учить другой язык, не разобравшись с первым, мне стало лениво. Да, в общем-то, и смысла особенного не видел, потому что Питон, как язык, очень мне нравится.

Но так или иначе, не успев даже как следует обидеться на судьбу за то, что соседняя очередь опять идет быстрее, я читаю про Django, о котором, как только он появился, говорят не иначе как “очень похоже по идеологии на RoR” и “как RoR, только для Питона”. Это, после совета авторитетов, стало вторым побуждающим фактором к скачиванию.

Вообще, напрямую сравнивать оба фреймворка я не возьмусь, потому что Rails я не использовал, а только видел знаменитый скринкаст на сайте и читал отзывы и сравнения. Однако вот краткая выжимка того, что я знаю об отличиях Rails и Django:

    *

      Rails изначально вырос из веб-приложения, системы управления “Basecamp“, а Django — из CMS для издательской компании “World Online“. Отсюда некоторые отличия в вещах, которые у той и другой системы получается лучше всего. Как сказал создатель Rails: “Rails больше подходит для создания приложений с добавлением статических страниц, а Django — для контент сайтов с динамическими функциями”.

      Взять, например, такую деталь: время жизни пользовательской сессии в Django стоит по умолчанию на 2 недели и считается от первого входа пользователя. Это не очень удобно для приложений, где сеансы короткие (порядка минут-часов), и время “протухания” считают обычно от последнего обращения.

      Однако надо учесть, что обе системы активно развиваются, и потихоньку приобретают все нужные черты, которых не имели раньше. Та же поддержка коротких живых сессий в Django уже есть (не без моего участия :-) )
    *

      В Django модель данных вашего приложения описывается в Питоне классами, и по ней генерится схема БД. А раз схема определяется в языке и от БД не зависит, это значит, что можно легко перейти на другую БД (например если вы писали что-то с Postgres’ом, а у юзера вдруг оказался только MySQL). Еще лично мне это очень нравится из-за того, что я не в состоянии запомнить, как пишутся все эти ALTER TABLE, которые еще и разные для разных БД. Хотя это и решается визуальными конструкторами.

      RoR делает по-другому: там сначала пишется схема БД, а по ней генерируется скелет приложения.

      Другими словами, и тот, и другой фреймворк используют свои ORM-решения для доступа к БД, которые, тем не менее, не избавляют от ручной работы по синхронизации объектной модели и модели БД.

Философия Django

Вот где Django сходится с Rails, так это в идеологии (от чего, собственно, их все и сравнивают). Вот основные принципы Django.

    *

      Принцип DRY — Don’t Repeat Yourself. Означает, что по возможности надо стараться исключать дублирование уже введенного в систему знания. Самый простой пример, если вы описали тип поля в таблице, вам уже не нужно писать исключительную по своему творческому заряду вещь:

      if тип поля EMail:
        проверить, что передан EMail
      elif тип поля Integer:
        проверить, что передан Integer
      ...

      Фреймворк делает максимум усилий для того, чтобы из описанной один раз информации достать максимум возможного сервиса. Хотя вы можете им и не пользоваться (что тоже иногда важно).
    *

      Реализация идеологии MVC. Очень удачная и практичная идеология. В Django правда, она реализована не совсем в классическом варианте. Например то, что обычно называется Controller, там вырождено в файл соответствия URL’ов обрабатывающим функциям, которые лежат в уровне View. Поэтому часто говорят, что Django просто переназвали Controller во View, а View — в шаблоны.
    *

      Разделение фреймворка на максимально независимые компоненты: так называемая “слабая связанность”. Тоже очень правильная идеология. Шаблоны, обработчики и модель почти не завязаны друг на друга. Модель ничего не знает о такой вещи, как HTTP-запрос, а из шаблона нельзя даже случайно изменить данные.
    *

      Отказ от завязывания шаблонов на язык программирования. Когда шаблон представляет собой смесь HTML’а и кода серверного языка, то очень быстро это приводит к тому, что в шаблон проникает довольно много логики, которой неплохо бы быть на уровне приложения. Что в свою очередь ведет к тому, что все это сложно поддерживать (примерно как суп вилкой есть). В Django язык шаблона вообще не связан с Питоном, а шаблонная логика намеренно очень ограничена. Например в операторе {% if %} можно проверить только логическую истинность объекта, а произвольное условие типа “равна ли длина списка пяти” — не допускается. Еще одно свойство шаблонной системы — безопасность. Можно обращаться не к любым методам, а только к тем, которые не меняют сами объекты. Поэтому шаблон спокойно можно отдать на редактирование кому-то другому, зная, что он ничего не сломает.
    *

      Красивые URL’ы. Это одна из тех вещей, про которую все знают, что это хорошо, но тем не менее обычно откладывают, потому что на функциональность сайта это не влияет, а начальство требует все новых возможностей от продукта, красота никого не трогает. В Django вы просто не сможете породить конструкции типа “index.php?func=user&subfunc=add&PHPSESSIONID=…..”. У вас есть файл, в котором просто пишется список всех видов URL’ов, которые привзяываются к своим обрабатывающим функциям. Причем изменяемые части URL’ов (id’шки там всякие) передаются в обработчики в виде обычных параметров функций, их не надо доставать из какой-нибудь коллекции.

И еще там есть много вкусных вещей, которые заставляют вас, читая, кивать головой, думая “ага, правильно!” :-).
Less code

Центральная же идея фреймворка — быстрая разработка с маленьким количеством кода. Все нацелено на то, чтобы большую часть времени программист занимался не настройкой фреймворка, а написанием кода своего приложения.

Для достижения этого многие вещи делаются без лишних указаний в настройках, а по соглашению. Скажем, если надо при генерации схемы БД заполнять ее какими-то тестовыми данными, нужно просто оставить в проекте файл оговоренного названия с SQL-скриптом, не надо нигде прописывать выполнение этого кода.

Кроме того, Django поставляется с немалым количеством уже написанных базовых вещей, которые в том или ином виде присутствуют почти в любом современном веб-приложении:

    * Сессии. Вы просто подключаете в приложение нужный модуль и у вас в каждом запросе появляется request.session, в которую можно класть любые данные. Они, естественно, разные для каждого юзера.
    * Авторизация . Вообще чумовая штука: регистрация, авторизация, система прав на объекты вашей модели данных, генерация паролей, рассылка сообщений юзерам по EMail.
    * Кеширование. Для того, чтобы не обращаться в базу каждый раз, когда требуются редко меняющиеся данные, можно вывод закешировать. Можно целиком весь сайт, можно отдельные страницы, можно вообще произвольные данные. Причем у системы кеша еще и несколько возможных вариантов, где этот кеш хранить: в памяти, в memcached (не знаю, что это, но говорят, известная штука), в директории на диске, в таблице БД…
    * И куча еще: синдикация, GZip, conditional get, редиректы, статические информационные страницы, валидация форм и т.д.

Причем эти базовые вещи еще и легко расширяются. Например, если нужны нестандартные поля для таблички юзеров, то с помощью некоторого подобия наследования можно переделать стандартную табличку, и система авторизации будет использовать ее. Также сильно помогает, что исходники всего фреймворка открыты, и можно в точности увидеть, как все работает, и как это можно поменять или расширить.

Но пожалуй, самая “презентационная” особенность Django, ускоряющая разработку сайта — админка. Все, кто пишет веб-приложения, знают сколько времени может отнять написание рабочего места для человека, который будет рулить наполнением табличек. А если это еще и на права завязано…

В Django для этого писать код вообще не надо. Надо только указать, какие ваши объекты вы хотите видеть в административном интерфейсе и все, Django автоматически формирует интерфейс, который мало того, что работает, так еще и выглядит классно.

Причем дальше, когда уже все работает, можно при желании заняться вылизыванием: сливать экраны редактирования объектов и подобъектов, добавлять поиски, разбивку на страницы по датам и т.д.
Python

Не последнюю роль в реализации принципа “меньше кода — больше денег” играет язык программирования.

Питон — один из модных объектно-ориентированных динамических языков, который отличается от классических (Паскаль, Си, Си++) в первую очередь тем, что он современный. А значит, в нем исправлены многие вещи, которые были сделаны в тех языках плохо. Кроме того, многие приемы программирования (паттерны), которые сложились за долгое время, добавлены прямо в синтаксис языка.

Причем все это сделано не сумбурно, а с наличием четко выверенной позиции, что делает программирование несказанно более простым и предсказуемым. Одни из главных принципов Питона: “явное лучше неявного” и “должен быть только один очевидный способ делать одну вещь”. Поэтому он и не превращается в Perl, который известен как “write-only language”.

Django использует возможности Питона на всю катушку. Например взможность по объекту узнать всю внутреннюю структуру класса, какие у него методы и свойства, очень полезна для реализации принципа DRY. Именно из-за этого возможно строить модель данных по описанным классам и обвешивать объекты этих классов всякими полезными методами. Например, если вы определили класс Person с атрибутом picture, в котором лежит фотография человека, то Django сделает ему удобные методы get_picture_url(), get_picture_filename().

Буквально недавно я написал один кусочек, которым хочу поделиться в качестве примера совместной работы Django и Питона.

Есть у меня список объектов — уменьшенные копии фотографий — которые я передаю в шаблон. Мне понадобилась оптимизация, чтобы некоторые thumbnail’ы нужно было не передавать полностью, а использовать только их id.

Вот тут начинает работать Питоновская динамика. В список thumbnails я могу класть не только экземпляры класса thumbnail, а вообще говоря, все что угодно. И вместо целиковых thumbnail’ов я могу положить там где надо заглушки с id:

thumbnails=[]                  #создается пустой список
for t in get_thumbnail_list(): #получаются thumbnail'ы из БД
  if <какое-то условие>:
    thumbnails.append(t)
  else:
    thumbnails.append({'id':t.id})  #заглушка в виде стандартного dict

dict - это тип данных в Питоне, который в PHP известен как “массив”, в Perl - как “хеш”, а в C++ ближайшим аналогом является STL’ный “map”.

В самом шаблоне ко всем элементам списка я обращаюсь одинаково: {{thumbnail.id}}, даже несмотря на то, что это по природе совсем разные объекты.

Работает это так. Когда Django’вский шаблон встречает конструкцию {{thumbnail.id}} он делает несколько проверок: 1. Если объект thumbnail - коллекция, и у нее есть ключик ‘id’, достается значение по ключу. 1. Если у объекта thumbnail есть свойство id - берется его значение. 1. Если у объекта thumbnail есть метод id(), то он вызывается и берется его результат. 1. Если бы вместо “id” была цифра, то Django проверил бы еще и элемент списка с этим индексом.

Вкусно, да? :-). В итоге шаблон получается гораздо более читаемым, чем во многих других шаблонных системах.

Дальше — больше. Мне понадобилось, чтобы в списке каждый thumbnail сопровождался еще одним параметром — признаком unchanged. И если добавить в заглушку еще один ключик проблем не представляет (будет {'id':t.id,'unchanged':False}), то у объекта thumbnail никакого такого свойства “unchanged” нет.

В каком-нибудь языке со статической типизацией надо было бы заменить все объекты в списке на некую обертку с дополнительным полем:

ThumbnailWrapper={
  unchanged:bool;
  object:Thumbnail;
}

… и заменить все обращения к элементам списка с просто thumbnail.id на thumbnail.object.id.

В Питоне же можно прямо к существующему объекту просто навесить новое свойство простым присваиванием:

thumbnail.unchanged=True   # у объекта создается новое свойство

Красота!
О стабильности кода

Пока еще Django находится в стадии активной доводки, и еще не дожил до версии 1.0. А это в свою очредь означает, что надо быть готовым к тому, что довольно часто разработчики ломают старые API и подходы в пользу более лучших. При этом ведут документик по несовместимым изменениям.

Это, на самом деле, резко увеличивает фан, и почти не добавляет головной боли, потому что изменения маленькие и логичные. Но если для вас важна стабильность кода, то пока переводить клиентские сервисы на Django я бы все же не советовал.
В заключении

Должен сказать, что пока я это все писал, меня довольно часто уносило вглубь по многим вопросам, и я потом стирал все целыми абзацами. Моей главной целью было дать представление о фреймворке и заинтересовать вас самих на него смотреть. Для этого, кстати, совершенно не обязательно иметь какой-нибудь мегахостинг, всю катавасию можно завести у себя на машине, причем и на Windows, и на Маке, и на других юниксах, конечно.

Планирую писать про Django и дальше. Спрашивайте, что вам было бы интересно.

Добавлено @ 17:52
Matthew Russell о TG (англ.)
http://www.macdevcenter.com/pub/a/mac/2005/11/08/turbogears.html

Цитата

urboGears
    TurboGears is a Python-based framework that enables you to quickly build database-driven, ready-to-extend web applications. TurboGears can be developed on Windows, Linux, and Mac OS X. It allows you to seamlessly provide HTML or an API for JavaScript to work with, gives your designers room to work with any XHTML tool for building layouts, and enables you to use your database without writing SQL. TurboGears is free and released under liberal open source licenses for both non-commercial and commercial projects.

In this article

   1. It's Kind of Like Rails -- But with Python
   2. Similarities with Rails
   3. A Quick Closer Look at the Stack
   4. An Interview with the Creator of TurboGears
   5. The TurboGears Are Spinning Fast

Rails sure has stirred up a lot of buzz lately (and rightly so), but now there's another great way to develop your next web app. It's lean, it's mean, it's easy to configure and use, and it shouldn't be a surprise that it's based on Python, a language that truly makes the common cases fast and easy. Meet TurboGears -- the powerful new mega-framework that's designed specifically to help you create your next great web app as quickly as possible. And the best part is that you're going to have a lot of fun doing it.
<A TARGET="_blank" HREF="http://ad.doubleclick.net/click%3Bh=v7/344c/3/0/%2a/a%3B32503746%3B0-0%3B0%3B12453998%3B4252-336/280%3B16834366/16852261/1%3B%3B%7Efdr%3D38627655%3B0-0%3B0%3B13513799%3B4252-336/280%3B17184607/17202502/1%3B%3B%7Efdr%3D25171877%3B0-0%3B0%3B10905964%3B4252-336/280%3B13990008/14007904/1%3B%3B%7Esscs%3D%3fhttp://seeker.dice.com/jobsearch/gentwo/index.jsp "><IMG SRC="http://m1.2mdn.net/982522/Dice_Testimonial_336x280_a-85.gif" BORDER=0></A>
It's Kind of Like Rails -- But with Python
TurboGears stack The TurboGears stack. Image courtesy of Blazing Things.

TurboGears puts together some of the best Pythonic frameworks available to bring you a mega-framework similar to Rails that makes it easy to get a lot of work done in very little time. It's a "full-stack" approach that covers the entire gamut of details involved with traditional web applications. Everything from slapping data down on the disk with SQLObject all the way up to providing a slick AJAX-based user experience with the help of MochiKit, the best JavaScript library you're going to find out there, is included in the package.

Sandwiched in between is CherryPy, the web application framework that makes cranking out dynamic content as easy as writing Python, and Kid, a powerful XML-based templating system. Each piece of the stack does what it does extremely well, and the overall effect of combining the pieces together certainly seems to produce an effect that's greater than the sum of the individual parts. Oh, and by the way, all of those projects are released under liberal open source licenses, as is TurboGears itself. Sound too good to be true? Let's take a closer look.
Similarities with Rails

Perhaps the most important similarity to Rails is the ultra-productivity that you can experience with TurboGears. Do you know of many other frameworks you can use to create a Wiki in only 20 minutes? (Didn't think so.) As we'll see, this productivity isn't the result of rocket science or some kind of profound inner truth. Rather, it's just the natural effect of combining nicely designed software components in a solid model-view-controller architecture.

Notably, each piece of the stack is based on Python, a powerful yet easy-to-use language that heralds itself as making development as simple and quick as possible. Python and Ruby are obviously different languages, but they share a lot of similarities with regard to the perks that they bring to the development cycle. Google's director of search quality, Peter Norvig, recently said, "Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." Those are inspiring words to hear from a company that obviously has been doing something right.

Another similarity between TurboGears and Rails is that it takes the same basic model-view-controller approach to web development that separates your underlying data and logic from the actual presentation of your content. Not only is code that's written in this way naturally modular, it's also fairly easy to troubleshoot and maintain -- significant factors to consider regarding the life cycle of any project. The model-view-controller approach is the same great methodology that just about any mildly complex application for your Mac is designed with. Examples might not prove anything, but it's hard not to notice how successful Apple has been in leveraging this approach to dish out some pretty amazing applications these last few years.

A Quick Closer Look at the Stack

At the bottom layer of the stack is SQLObject. Essentially, this little marvel removes much of the burden of writing your own SQL queries, and instead, allows you to focus much more of your attention on the modeling process. The basic idea is that classes are flattened into tables and the attributes of the classes become table columns. An especially interesting property of SQLObject is that it tries to be as agnostic as possible with respect to the specific SQL database that you use underneath, so you could transition amongst SQLite and PostgreSQL without hassle.

Click here to find out more!

Here's what's becoming the classic example for illustrating how easy it is to use SQLObject:

from sqlobject import *
from datetime import datetime

class Person(SQLObject):

    firstName = StringCol(length=100)
    middleInitial = StringCol(length=1, default=None)
    lastName = StringCol(length=100)
    lastContact = DateTimeCol(default=datetime.now)

That code looks remarkably similar to the following SQL query:

CREATE TABLE person (
         id INT PRIMARY KEY AUTO_INCREMENT,
         first_name VARCHAR(100) NOT NULL,
         middle_initial CHAR(1),
         last_name VARCHAR(100) NOT NULL,
         last_contact TIMESTAMP NOT NULL
     );

Sitting just above the SQLObject layer of the stack is CherryPy. If you've ever done any kind of server-side scripting before with a technology like servlets, you'll find CherryPy to be a very easy way to pump out dynamic content. Here's the classic "Hello World" where you can optionally set the query string parameter who in the URL to display something in the place of "World."

import cherrypy

class MyRoot:

    @cherrypy.expose()
    def index(self, who="World"):
        return "Hello, %s!" % (who)

It really doesn't get much simpler than that, and if you're already the least bit Python-savvy, you'll be able to surprise yourself with what you can get done with CherryPy. The performance isn't bad either; the server itself is capable of serving several hundred requests a second, which means that your performance is going to depend mostly on your application's specific code.

Kid is the next layer of the stack and provides a robust XML templating system that makes it easy to separate the content from the presentation of your pages, in addition to simplifying mundane tasks like building tables. For example, take a look at the following code to build a table using Kid:

<table>
    <tr py:for="gear in turbogears">
        <td><span py:content="gear.name">TurboGears</span></td>
    </tr>
</table>

That's easy enough. As you can see, templating engines fill the niche of transforming data that's churned out by an application into a nice presentable format via insertion into a spot template itself. Just think about how much easier that approach makes it to maintain complex hierarchies of documents on sites like eBay and Amazon.

Of course, CSS still styles the actual content that's pushed into the template, but the template itself provides the overall structure for the document. Templating systems provide one of those highly sought-after, win-win situations that allow designers to do what they do best (presentation) and developers to do what they do best (deliver content).

Finally, MochiKit tops off the TurboGears stack by providing a rich JavaScript library that you can use to work AJAX capabilities or those final user-interface tweaks into your application. If you've ever done much work with JavaScript, you already know that development often can be painful because of the lack of standard library functions. Fortunately for us, MochiKit significantly lessens the burden of that very problem, allowing us to focus our attention on more interesting things. Consider the following snippet of code for building a table using MochiKit:

    var rows = [
        ["dataA1", "dataA2", "dataA3"],
        ["dataB1", "dataB2", "dataB3"]
    ];
    row_display = function (row) {
        return TR(null, map(partial(TD, null), row));
    }
    var newTable = TABLE({'class': 'prettytable'},
        THEAD(null,
            row_display(["head1", "head2", "head3"])),
        TFOOT(null,
            row_display(["foot1", "foot2", "foot3"])),
        TBODY(null,
            map(row_display, rows)));
    // put that in your document.createElement and smoke it!
    swapDOM(oldTable, newTable);

A job well done. You'll find all sorts of goodies that'll save you time in MochiKit: logging utilities, AJAX utilities, the ability to fade text, and sorting lists, just to name a few.

And there you have it, the four simple yet elegant components that pack quite a punch when used together -- the power of SQL without writing SQL queries for data storage, a robust and flexible Pythonic web server for generating dynamic content, XML-based templates to provide an overall structure and organization for your documents, and finally, some JavaScript to spruce things up a bit and add some spunk to the user experience.

No doubt, you're wondering how to get started at this point. Well, it's easy. Too easy. Just go out to the TurboGears Mac installation page and follow the steps. All that's required is making sure the correction version of Python is installed and downloading the goods. Then you'll be on the way to creating that Wiki you've always wanted. There's also a massive collection of resources provided to get you up and running. And now, here's a real treat.

An Interview with the Creator of TurboGears

TurboGears is such a cool project that I thought we should try to get some one-on-one time with Kevin Dangoor -- the creator of TurboGears and the upcoming Zesty News product. Fortunately for us, he was more than willing to take a few minutes out of his busy schedule to talk a little more about his work.

<A TARGET="_blank" HREF="http://ad.doubleclick.net/click%3Bh=v7/344c/3/0/%2a/a%3B32503746%3B0-0%3B0%3B12453998%3B4252-336/280%3B16834366/16852261/1%3B%3B%7Efdr%3D38627655%3B0-0%3B0%3B13513799%3B4252-336/280%3B17184607/17202502/1%3B%3B%7Efdr%3D25171877%3B0-0%3B0%3B10905964%3B4252-336/280%3B13990008/14007904/1%3B%3B%7Esscs%3D%3fhttp://seeker.dice.com/jobsearch/gentwo/index.jsp "><IMG SRC="http://m1.2mdn.net/982522/Dice_Testimonial_336x280_a-85.gif" BORDER=0></A>

MR: I always find it fascinating see the progression of events that leads people to do such interesting things as creating a new framework, so before we get to TurboGears itself, could you say a little about your background? Are you a software engineer?

KD: Yeah, actually my degree is in computer science from the University of Michigan. I graduated in 1994, so it's been a while. I've been programming professionally since 1988, but along the way I've also worked jobs in management, sales, and engineering. I've also had a couple of my own companies, which is something else I bring into this whole endeavor. Interestingly enough, it's not just about the programming -- there's also a lot of product management aspects that come up when you're developing professionally.

MR: So what specifically gave you the inspiration for TurboGears? You obviously had the technical background, but where did the creative inspiration come from?

KD: Well, the inspiration for TurboGears is actually my Zesty News product. While working on that, I needed to have the tools to make the web application itself. At the beginning of the year, I started looking at the various frameworks there were available in an effort to put something together that would do what I needed. Along the way I decided to really emphasize plug-ins for Zesty News, and that was the point at which I decided that I needed to document all of the work I had been doing and put it out there so other people could take advantage of it. Rather than being a sudden flash of inspiration, TurboGears came from an evolutionary process in building Zesty News.

MR: So this effort is a full-time job then? It's not just a part-time effort that you work during the evenings?

KD: Yes and no. You could say that my day job is working on Zesty News -- that's what my company Blazing Things is developing at the moment. But I decided that I would develop TurboGears and get it out to the masses before getting back to Zesty News, because I think that TurboGears is really showing that there is a demand and a real need in the Python world for a "full stack" web framework.

MR: So why is the TurboGears stack so reliant on Python?

KD: I think Python is a really easy to learn and fun language for development, and it's not a very difficult endeavor for anyone who's ever had any programming experience. In fact, I've noticed that a lot of people on the mailing list for TurboGears said that they're new to Python so it looks like there are quite a few people that are coming to Python through TurboGears. I don't think they're finding Python itself to be a very difficult part of the learning process. I personally have been developing in Python for about 10 years, and I consider it my language of choice.

MR: How much "glue code" did you have to write to get TurboGears working?

KD: Well, for the first release, the amount of code involved in putting TurboGears together was quite small. I would say the initial TurboGears release was only around a thousand lines or so. I didn't make any notes at the time, but I really don't think it was more than that. It was really small, and the amount of code necessary to get these pieces working together was negligible because they are so nicely written and had a natural interoperability with other projects. The bulk of the code is naturally going to remain in the individual projects that make TurboGears possible, and hopefully some of the components developed for TurboGears will migrate back out into the pieces of the stack themselves. But overall, the amount of code specific to TurboGears has been growing with each release.

MR: Would you say that Rails has had any impact at all on your design of TurboGears?

KD: Well, actually, when I was starting Zesty News I considered Rails but decided to use Python because of particular Python libraries that are not readily available for Ruby. So, yes, I did look at Rails, but the specifics of Rails weren't really an influence on TurboGears because I started with different tools, namely CherryPy and SQLObject. But conceptually it has the same sort of architecture as Rails. The fact that Rails gives you everything you need for a web application from front end to back end is what was missing in open source previously, and that has been a big influence on projects like TurboGears that have come since.

MR: So what took us so long to get to this "full stack" paradigm of web development like Rails and TurboGears? Is Apache losing any footing here?

Click here to find out more!

KD: Well, I think there will always be room for the servers like Apache in the world because it's hard to beat them for serving up static files and things of that nature. As far as application servers like Rails and TurboGears, however, I think lightweight development processes have actually existed for some time with the net-savvy companies like Amazon, eBay, and Google. These companies have all been using languages like Python and Perl internally so I think the idea has been there longer than you might think. But I think there's a real shift happening in corporate America right now with regard to enterprise-level development. They're finally realizing that they don't have to do things that take thousands of lines of XML configuration and tens of thousands of lines of code when they can rely on smaller and more agile frameworks that are just as capable for the common case -- frameworks like Rails and TurboGears.

MR: What advice would you give to developers who are trying to decide whether or not to choose TurboGears or Rails for their project?

KD: There are definitely some trade-offs and I think they go back to the third-party libraries that are available for Python and Ruby. Python has a lot of useful libraries that aren't available for Ruby yet, but Rails has been around longer so, from a documentation perspective, it is better established -- although we're working hard to fix that. I think the other big thing is that TurboGears and Rails have two different styles of doing things and so it also comes back to preference at some point. It's kind of like that the whole Emacs versus Vim argument. The two tools can do the job arguably equally well, but stylistically they are very different. Hence, people might choose one or the other based on their own personal preference and style. TurboGears definitely has a different style than Rails, and for some people, I think that style will definitely appeal.

MR: AJAX has its place in the TurboGears stack, so does that mean that you think it's here to stay? There has been a bit of discussion about that lately.

KD: I think AJAX is here to stay for a while. Browsers are supporting it more and more, and it is something that you can do to provide a much richer user experience than otherwise. It's possible that new standards will come up and newer standards will change the way we do AJAX (remember, it's more of a concept than it is an entity), but for what it does there is really no better alternative right now.

MR: How well does TurboGears perform and scale when compared with the enterprise-level servers like J2EE?

KD: Really, scalability is more about application design than it is about choosing a particular application framework, and that's just one more reason that TurboGears is a very viable choice. As long as you are designing an application in the way that you need it to scale, you should have no problem using TurboGears that relies on a very high level language like Python. Personally, I've done a lot of Java and J2EE development, and I'm much happier working in Python now. I'm able to get stuff done so much more quickly, I fight with the tools a lot less, and it just seems to be a lot more fun overall.

MR: Since you're mostly flying solo on this project, do you use any particular kind of development cycle, or do you pretty much wing it?

KD: TurboGears development is not a solo endeavor, because there are other people leading and contributing to all of the projects involved with TurboGears. For Zesty News, I very much believe in agile development methods. I've done a lot of extreme programming (XP), and so I also believe very strongly in unit testing. In fact, before releasing TurboGears, I actually put together a testing package called TestGears to make unit testing easier. For that matter, I believe very strongly in test-driven development in general. I usually write the tests before the code. I don't need to do, or believe in doing, a giant functional specification beforehand, because I think it is often a waste of time. But I do believe in going through a process similar to XP. So, yes, even working as a single developer I still feel the need for a development process so that I can make sure I'm heading in the right direction and measuring progress.

MR: You're approaching a v1.0 release soon. How long has it taken to get this far, and when can we expect v1.0?

KD: It was really a process that started at the beginning of the year if you count the selection of tools, defining of requirements, etc. I've gone through a variety of different tools throughout the evolution of Zesty News, and in its current form, I'd say that TurboGears has basically existed since July. That was when Bob Ippolito released MochiKit, which was pretty much the last piece of the puzzle. MochiKit is a JavaScript library that helps handle a lot of front-end tasks. It's been nearly 2 months now that I've been spending almost all of my time working on TurboGears, because I want people to be able to easily develop plug-ins for Zesty News.

Naturally, I don't think I can solve all of the world's problems by v1.0. But plenty of useful functionality already exists, and we are already doing a good job of making sure that anything we change between now and then will stay backwards compatible. Changes are being documented, and we are being very disciplined to make sure that people know about changes that have major impacts when transitioning through major versions. We're currently on the fast track to v1.0, but there is already so much useful functionality in there that there is no reason for people to stand by waiting. Forecasting ahead, v0.9 will be out really soon, and v1.0 should be out by the end of the year.

MR: Great. Well, thanks so much for taking the time to chat. You're doing great work with TurboGears and Zesty News. Keep it coming.

KD: Definitely. This has been fun.
The TurboGears Are Spinning Fast

Kevin and the rest of the crew at Blazing Things are making significant progress on a very regular basis, so check the TurboGears website often for new announcements, screencasts, and tutorials. It's really going to be interesting to see how this project continues to develop and the impact that it has on developers and end users alike.

Matthew Russell tries hard to live life as a quintessential renaissance man, but hasn't been making very much progress since becoming enthralled by the cult of Mac.