Python: Веб-разработка без фреймворков (ответ на критику)

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

Комментарий Ивана Салагаева: Тут я хочу сказать, что от таких эффектов все равно нельзя защититься. Большинство людей любят не думать, что от чего зависит, а сразу ищут однозначных ответов. И уж тем более, если их пишет человек с авторитетом (который у меня, уж как получилось, есть). Моя статья, хоть и эмоционально написана, отвечает, как ты сам заметил, не конкретно на твой обзор WebOb, а использует его как повод для развития моей собственной точки зрения, которую я постарался обрисовать в начале. (WebOb важная часть, но статьи не только про него — примечание СЩ).

Недоразумения можно было бы избежать, если бы Иван прежде чем писать отзыв уточнил правильно ли он понял к чему я веду. Чтобы не повторить эту ошибку со своей стороны, я, как вы уже заметили, попросил его прокомментировать эту статью до её публикации.

Начать стоит, пожалуй, с того, что я не агитирую никого бросать их любимый фреймворк, не призываю писать свой собственный, я вообще ничего не предлагаю и не требую. Статьи описывают библиотеки, которыми пользуюсь я сам и приводят примеры как выглядит в результате код, не более того. Статьи не предназначены для новичков, для того чтобы эффективно писать код в том стиле, как делаю это я, необходимо хорошо понимать как работают все задействованные уровни включая HTTP протокол, сам стандарт WSGI, диспатчинг, шаблоны, используемый ORM и сама база данных, объяснить всё это я могу лишь отчасти. Пожалуй нелишним будет опыт разработки на нескольких существующих web-фреймворках. Я начал программировать для веб на Python шесть лет назад, и хотя были перерывы, имею солидный опыт использования самых разных фреймворков, поэтому не надо думать, что я пишу код таким способом из-за того что страшусь использовать существующие.

Велосипеды

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

Для того чтобы внести ясность попробую объяснить различие между фреймворком и библиотеками. Framework в переводе с английского это буквально каркас, т.е. ваш код является вторичным по отношению к библиотечному коду. Не вы выбираете где и что использовать, а расширяете и переопределяете уже имеющуюся функциональность. Более четким критерием отличия фреймворка будет повсеместное использования инверсии контроля, будь это декларативный код или callbacks[1].

Я исхожу из того, что этого нужно избегать насколько только возможно. Это вопрос личного предпочтения — если вам нравится писать код в колбеках, если это вам не мешает, то, вероятно, у нас совершенно разные стили программирования и мой опыт вам ни к чему. Если же вы улавливаете преимущества более свободного структурирования кода, то, возможно, программировать при помощи библиотек окажется удобней и продуктивней[2].

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

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

Также Иван предположил, что такой подход продиктован «чистотой» WSGI, но ничто не может быть дальше от правды. Как раз поиском решений для всего и сразу страдают фреймворки. Они часто исходят из какой-то идеологии (например MVC). Очень часто пытаются спрятать сложность веб-приложения за избранными абстракциями итд итп. Благодаря же WebOb получается укротить эту сложность, оставив притом всю доступную мощь на кончиках пальцев. Что приводит нас к следующему пункту.

«... в качестве клея компонентов... WSGI! Нет, серьезно — WSGI!!!»

Объясню, почему в статьях всё крутится вокруг WSGI. Поскольку я стараюсь максимально использовать существующие библиотеки, поскольку я стараюсь не терять возможностей на разных уровнях приложения, то я привязываюсь к WSGI. Если мы хотим использовать разные библиотеки совместно мы вынуждены использовать WSGI. Посмотрите на URLMap, посмотрите на различные middleware, без предоставления и использования WSGI они были бы невозможны. Из-за того что фреймворки идут другим путем и выбирают другую, предположительно лучшую, модель представления запросов и ответов именно для них так часто приходится изобретать велосипед, ведь нужно вписаться в идеологию фреймворка. В таких случаях обычно говорят о важности интеграции родных компонент и прочую лабуду, однако правда гораздо проще — просто приходится делать заново или что-то перекручивать[3].

Я знаю мнение PJE о том, что middleware злоупотребляют и я с ним полностью согласен. Ядро его недовольства он сформулировал так: «If your application requires that API to be present, then it’s not middleware any more!». Совершенно верно, однако есть ряд случаев когда middleware единственно верное решение, например paste.gzipper. Это те случаи когда оборачиваемые приложения не знают и не должны знать что они обернуты, к такому использованию прослоек претензий быть не может.

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

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

Диспатчинг

Мне, без дураков, больше нравится писать серию if или, скажем return self.appmap.get(req.path_info_pop()). Если ваш пуризм (или менеджер проекта) требует чтобы это было сделано иначе — делайте, для этого, среди прочего, есть например Routes. Не нужно ни писать заново, ни платить цену использования фреймворка.

Вообще, многих программистов похоже пугает писать код, как только они пишут код приложения, они думают «О Боже! Почему этого не делает за меня фреймворк!?». Конечно, размышляя таким образом, получится, что диспатчинг вручную — зло, и срочно надо писать свою библиотеку или хвататься за готовую. Если же не спешить, и не побояться сделать самому решение именно имеющегося вопроса (подчеркиваю — не универсальное решение), то может оказаться, что паника была преждевременной, и кода вышло меньше, код вышел понятней, в будущем менять его проще. Так выходит у меня. Извините.

Остальное

«Что произойдет, если клиент пришлет невалидную utf-8 строку?» (см. третью статью в серии). Произойдет то что и должно произойти — клиент получит ошибку (нет, ничего не упадет, снова извините)[4]. Какие такие «ваши данные» выжмет Django из невалидной строки я не знаю, но мне такие и не надо. Может вам нравится иначе, но это, по крайней мере, соответствует PyZen и здравому смыслу.

Кстати, если посмотреть на The Zen of Python в целом (или его русский перевод), то почти по каждому пункту веб-фреймворки идут против него, такое моё мнение. Это не аргумент против, просто наблюдение[5].

<hr/>

  1. ^ ИС: Кстати... Джанго, как немногие знают, очень близко подходит к этой границе: в нем очень много просто библиотечного кода, который не является каркасом. Да, Джанго, несомненно фреймворк, потому что предоставляет архитектуру обработки запроса с разбором url’ов и вызовом пользовательской view. Но это, пожалуй, и все. Шаблоны, обработка форм, ORM — это фактически внешние библиотеки, которые пользователь зовет сам, и тогда, когда ему надо. Единственное, чем тут помогает Джанго — примерами в документации.
    Тот же Pylons в этом смысле существенно глубже находится в зоне «фреймворк».
  2. ^ Мне действительно нравятся те места, где Джанго строит «собственный путь» по той простой причине, что он совпадает с тем, что сделал бы я сам. А это значит, что он экономит мне время.
    Но в целом, я полностью согласен с тем, что это вопрос личного стиля.
  3. ^ А я тогда объясню, почему я так резко реагирую :-). Дело в том, что я удивительно часто встречаюсь с точкой зрения, что WSGI — это такая великая магия, и если на сайте фреймворка на первой странице написано это слово, то фреймворк автоматически считается дико гибким и мощным. Моя цель — объяснить, что WSGI — это простой протокол, который очень удобно использовать в качестве базы, но который сам по себе никакой архитектуры не строит. В WSGI нет, например, понятия каскада приложений. Его так использует тот же Paste, но это не само по себе происходит.
    И снова, это я отвечаю не на то, что ты пишешь, а разъясняю, что имел в виду я сам. (С последним полностью согласен — СЩ)
  4. ^ Тут под «упадет» я имел в виду не то, что приложение остановится на сервере. Я имел в виду как раз 500 ошибку. Это, я так понимаю, просто разница в жаргоне. (Насколько я понял, просто был выбран неудачный пример для критики — СЩ)
  5. ^ О, вот это точно флеймообразующий абзац :-). 9-й пункт в Дзен («Although practicality beats purity») дает возможность трактовать все что угодно как угодно :-). Поэтому я обычно на Дзен ссылаюсь только в шуточной манере. (А как же остальные пункты! — СЩ)
  • Популярное

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хотел почитать эти статьи, но оказалось что ссылки нерабочие(((

Если пользуетесь декоратором подобным моему, то можно использовать следующее исключение: raise HTTPException («Тут текст для отладки, если понадобится», wsgi_application) Это позволяет переопределять результат исполнения из глубины стека.Вопросы о том где вызывается start_response наводят на мысль что в middleware превращены на самом деле зависимые компоненты которые лучше реализовать обычными библитечными вызовами. Если говорить о XSLT-преобразователе применямом к любому WSGI-приложению, то я думаю такое наверняка уже кто-то реализовал (wsgi+xslt).

Стараюсь построить библиотеку по работе с XSLT шаблонизатором для составления HTML документов. Специфика: фронтенд — nginx, бакэнд — flup через fastcgi. Джангу и другие фреймворки смотрел, но ни один из них не заточен под XSLT, юзать nginx-модуль XSLT — не хочу по субъективным сображениям. Кроме того, у меня написан свой модуль для работы с БД, так что более 50% любого фремворка надо будет удалять хирургическим путем. А это будет уже не джанго.Ранее работал со SkunkWeb-ом. В нем меня устраивало маппирование URI в имя файла в файловой системе. Кроме того для удобства разработки было предусмотренно исключение, генерация которого говорила серверу «ответ готов, отсылай клиенту» (патч для ReturnValue). Другие исключения выдавали ошибку 5xx. Вообщем была сильна «вуду». Часть этого вуду хочу сохранить, ибо удобно, по крайней мере мне.Собственно сам вопрос — никак не могу понять, куда и каким местом приделать start_response во всем стеке исполнения мидлварин? Просто вариаций масса, хочется же остановится на чем-то предпочтительном.

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

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

А расскажите про издержки использования Джанго? И как это зависит от количества проектов? Серьезно, очень интересно. Особенно в сравнении, если в этих проектах был бы полностью собственной code base.

Единственное, что меня заботит — это экономическая эффективность.Стоимость развертывания масштабируемых проектов, издержки на содержание обслуживающего эти проекты железа. Время — деньги?

А от скорости разработки это не зависит? Т.е. если собственный code base пишетсы в два раза дольше это эфективнее?

Перманентно ковырять транки/SVN и адаптировать свой код, каждый раз заново? Может техноманьякам это и нравится, но такой подход очень вреден для бизнеса. Мне было бы любопытно посмотреть на «экономящих время» программистов, когда «неожиданно» придется вносить изменения в сотню проектов из-за новых мулечек свежей версии фреймворка.

А что мещает не изменять? И как отлично это от того, что свой доморощенный фремворк тоже будет расти со временем?

Использование же чистого кода, оставляет наши руки свободными и позволяет дописывать нужные нам и нашим клиентам «фичи».

А у вас клиенты часто выдвигают изменяющиеся требовния к web request stack как к таковому? И главное, чем отличает применение джанго от применения разных библиотек? Спасибо.

Апплодирую автору стоя.Читал весь цикл статей давно, но лишь недавно наткнулся на критическую заметку Ивана. Откомментировался там, и решил, что будет правильным поблагодарить и здесь.Я, как и автор статей, принадлежу к вымирающему классу «программистов старой школы». Тех самых, у которых лозунгами были «Знай свой код! » и «Экономь каждый байт», а не «Джанго рулит, код from scratch мастдай». Мне нравится знать свой код, называть переменные и классы так, как удобно мне. Придерживаться навязанной идеологии какого либо культа, какого-либо фреймворка мне не очень нравится. Не нравится мне молиться, выкрикивая в экстазе наборы букв «WSGI, ORM, MVC, Django-Django, Ruby-RoR! ». Нанимая Py-программиста, я заинтересован в его познаниях языка Python, а не языка Python «Django Edition».Как я уже сказал у Ивана, я не против Django. Мне нравится этот проект, но он применим ровно в своих задачах. Сделать один сайт, два или три. Но когда идет поточная работа над сотней проектов, и у каждого своя специфика, использовать «сферическую лошадь» становится невозможным. Издержки от использования фреймворка растут прямо пропорционально количеству разрабатываемых и обслуживаемых проектов. Проектов, подчеркиваю, а не «частных порталов Васи Пупкина». Да, я старый зануда, брюзга и сноб.:) Code is poetry — есть такой слоган. А писать стихи, будучи зажатым требованиями цензуры фреймворка, несколько проблематично, хотя и коньюнктурно. Использование отдельных библиотек, предоставляет существенно больше свободы маневра и снижает издержки ресурсов. Многие программисты обленились, увы. Как было выше замечено, многие уже хотят, чтобы фреймворк выполнял за них всю работу. Дескать, это экономит время. Честно говоря, меня мало беспокоят затраты времени программистами. Поменьше в игрульки играть будут:) Единственное, что меня заботит — это экономическая эффективность. Стоимость развертывания масштабируемых проектов, издержки на содержание обслуживающего эти проекты железа. Время — деньги? Согласен на все сто процентов. Но время сэкономленное при разработке проектов с использованием умных фреймворков, рано или поздно выходит «чревато боком». Особенно это чревато выходило до релиза джанги номер 1. Перманентно ковырять транки/SVN и адаптировать свой код, каждый раз заново? Может техноманьякам это и нравится, но такой подход очень вреден для бизнеса. Мне было бы любопытно посмотреть на «экономящих время» программистов, когда «неожиданно» придется вносить изменения в сотню проектов из-за новых мулечек свежей версии фреймворка. Использование же чистого кода, оставляет наши руки свободными и позволяет дописывать нужные нам и нашим клиентам «фичи». И особенно в этом нам помогает тот же WSGI. Хоть я и большой нелюбитель «прокладок», но в данном случае использование этой технологии весьма целесообразно, поскольку помогает с легкостью подключать и модифицировать библиотеки, без затрагивания самого кода бизнес-логики. И позволяет делать это быстро и чрезвычайно эффективно.Спасибо за Ваш цикл статей, Уважаемый Сергей.

Сергей, ну наконец-то, впервые вижу первого человека в мире, который осмелился плюнуть в знаменитый paster! Я тоже был сразу поражен, когда только почитал про него, да и про Pylons. Что это за генерялка кода, блин?! И гуглил, гуглил, а везде одну похвалу поют. Так я и не почувствовал в чем тут вкус...Остальному народу: в самом начале Сергей сказал, что никого ни в чем не убеждает и показывает лишь еще один как минимум не хуже работающий подход. О чем тут может быть спор? Ученые часто придумывают что-то новое и доказывают, что на нем можно выразить все старое. Так сказать выражение одной теории через другую. Например, слошь и рядом в теоретической физике:) Что касается моего ИМХО: из всех фреймворков, что я использовал или видел, ограниченная Django имеет максимальную скорость вхождения. Я ее вообще не изучал. Просто сел и начал делать, периодически поглядывая в книжку. Как только я ее поставил, так все сразу заработало и стало расти вширь и в глубь. После Zope это меня поразило, конечно. В этом смысле Django вне конкуренции. А про ее ограничения, возможности, ORM и пр. — это уже другой вопрос, я акцентирую внимание лишь на одном — скорости «вхождения» в нее.И напоследок, Сергей, именно смелость выразить свое несогласие и поиск нового там, где уже все найдено и никому ничего нового не надо и толкает к открытиям. Так держать: -) Другой вопрос, что многие исподтишка уже юзают что-то такое и не признаются в этом — это факт:)

Сергей, прочитал отзыв у Салагаева, и сразу подумал: «хорошие видать статьи, раз здесь так ругают», надо пойти почитать. А на «пишет человек с авторитетом (который у меня, уж как получилось, есть) » посмеялся. Спасибо за серию.

Игорь, Спасибо, всегда приятно слышать что кому-то пригодилось или понравилось. Хочу заметить что про типичное начало разработки с фреймворком я пока ничего не упомянул, т.к. собирался писать об этом в статье с обзором по уже существующим. Я так подумал что ту статью лучше не писать, потому что в результате выйдет дикий флейм — каждый бросится защищать свой инструмент. Но вообще обычно начинается с запуска

paster create -t %имя фреймворка% %имя приложения%

Paster впору было бы назвать copy-paster’ом, потому что именно это он и делает — создает тонны бойлерплейта под проект (например посмотрите обзор содержимого пустого проекта на Pylons). Я не знаю чем для себя оправдывают такой подход его адепты, но по-моему это полный... в общем это ужасно. Я ко всему стараюсь относиться скептически, так что не знаю насколько много людей действительно поймут многое из написанного, хоть и надеюсь что из статей есть что вынести. Если пригодится хоть одному человеку, то уже хорошо — осчастливить весь мир я и не пытаюсь. Человек без опыта попытавшись писать код таким образом наверняка наделает немало косяков, но мне кажется всё таки результат всё равно будет лучше чем с фреймворком. Я осторожничаю такое утверждать, ведь это только домыслы, но мне было бы интересно услышать про опыт тех, кто всё же попробует на свой страх и риск.Насчет отзыва... ну кто-то Ивана вяло одергивал, а кто-то писал «в пух и прах», «спасибо наставили на путь истинный» или «там учат плохому! ». Особо порадовали говноблогеры видящие во всем поиск популярности)) Вот уж точно каждый со своим аршином. Я как прочитал комментарии сразу задумался, а зачем объяснять в чем там ошибка? Если люди сами не видят, что критика вообще непонятно на что направлена (Иван потом сам признался что критика не просто не про мои статьи, она вообще про точку зрения которую он затруднился назвать где вообще встречал). Так вот если я им обьясню, условно, что наоборот WSGI — рулит, а Джанго — говно, то что с того? Какая разница что будут думать люди которые сами не думают? Ну и не стал потому поначалу отвечать.Джанго это «коммюнити», а приблизительно 100%-м людей нужно принадлежать какой-то клике, клану, сообществу, нации, так что она отвечает тем запросам, которым просто выполнение своей работы отвечать не может. Понятно, что недостаток реверансов в сторону великой и могучей Джанги сразу обозначило меня как «чужого», поэтому не нужно далеко ходить за настоящей причиной неприятия. Толпа она и в Интернете толпа, всегда есть исключения, так что кто-то конечно использует фреймворк потому что действительно, обьективно для него это лучше, но чем больше об этом разговоров, тем больше у меня на этот счет сомнений.К слову, как раз по этому же поводу обсуждал Джанговские темплейты и родился новый смайлик (в качестве шутки конечно): {% — Я ДЖАНГИСТО! Пятая статья уже написана и сверстана, должна появиться на днях.

Сергей, несмотря на то, что я программирую не на Python, хочу вас поддержать. Моя профессиональная область — ASP.NET, а Python мне просто очень интересен. Я с большим вниманием прочел и весь цикл ваших статей, и комментарии Ивана Сагалаева. Статьи мне прекрасно объяснили, с чего начинается жизненный цикл типичного web-приложения на питоне и с чего начинается большинство питоновских фреймворков. Спасибо! Комментарий Ивана меня удивил резкостью (там в блоге его коллеги сразу начали одергивать). Вы своими статьями увеличили количество программистов, понимающих азы, основы. Программистов, способных обойтись без фреймворка или создать свой собственный. Программистов, которые не пытаются впихнуть весь большой мир в рамки Джанго, а смогут выйти за пределы этих рамок. И даже если первые версии их собственных фрейворков не будут иметь 18 уровней абстракции и не будет отвечать высоким требованиям Ивана, они будут программистами, а не Джанго-кодерами. В общем, даже если Иван где-то прав технологически, идеологически он все же не прав.У вас все хорошо получилось. Продолжайте писать о своем опыте.

Если задача выполнена и другие части будут делать другие люди, то лучше чтобы никаких фреймворков не было — мороки меньше. Но иногда конечно хорошо иметь пул програмистов готовых, если что, доработать проект за еду, поэтому иногда можно и на PHP сайт заказать.

Плохая организация — если такая ситуация смертельна для проекта.Коллективное владение кодом спасает.

А разве когда разработчик был, а потом его не стало резко, это плохая организация работы виновата? Это жизнь, всякое случается:)

От плохой организации работы «известный фреймворк» не спасает. Совсем.

Я имел ввиду интересы заказчика, когда обучать некому, проект большой, а например вся команда во главе с главным разработчиком уехала в штаты жить и работать. Или программеры, написавшие большой портал на смеси С++ и Perl с нуля вдруг решают поднять себе зарплату сильно. Для заказчика всякие самоделки опасны т.к. он себя сильнее завязывает на разработчика. Именно поэтому, в интересах развития проекта, я даже несложные проекты пишу на известном фреймворке, а свои наработки пользую только когда для себя пишу.

Для Питона более-менее большое комьюнити в вебе есть только для Джанги.Но у меня есть опыт обучения ньюбов (умеющих «просто писать хорошие программы на Питоне») новому подходу. И, поверьте, это происходило очень легко и быстро. Не в фреймворках счастье -, но хорошо бы их знать архитектору проекта. Чтобы не наступать на привычные грабли.

Отличный пост. Спасибо! Хочу добавить, что фреймворк — это еще и среда, комьюнити шарящих в нем разработчиков, где во первых порой можно найти массу готового здорового свободного кода для старта/развития проекта, а во вторых — найти людей в этом коде хорошо ориентирующихся и способных недорого и быстро подменить разработчиков. Иногда это важнее неприязни к колбекам.А так, конечно HTTP взял / HTTP отдал приятнее писать, чем корячиться:)

О чем разговор уже и не пойму.

@Frenzy, Очень интересно... может тогда уже так: «всё абсолютно то же, только проект GUI, написан на Erlang десять лет назад и должен работать на мобильных телефонах». Я вам что скажу, если не писать ху ерунду по типу «потом поймете почему это неправильно», то придется писать как есть на самом деле — «у меня / нас не получается», «я / мы не смогли так сделать», «я сделал себе больно потому что не стал рефакторить имеющийся код», «я как-то взялся за гуж и оказался не дюж», «какие-то уроды написали уродский код, а мне разгребать» итп. Правда тогда видно будет что это к критике не относится никаким боком. Плюс, прежде чем утверждать что-то про собеседника или найдите где он сам такое про себя говорил или сначала спросите так ли это, а главное, когда чего не понимаете то или молчите или спрашивайте, не надо изливать свою мудрость на окружающих. Я знаю зачем и почему пишут так как пишут и рекомендуют как рекомендуют. И зачем сервлеты знаю, прикол именно в том, что те кто ими пользуется — не знают. Вот бы кто написал таки зачем, было бы интересно заодно узнать, лечатся ли сервлетами кривые руки разработчиков?

Dmitry, фреймворк не получится, так только кажется.

Любой кто не знает альтернатив, считает что в его подходе очень много смысла. Среди критиканов пока не попалось ни одного человека фактически испытавшего на опыте описываемый подход. Когда появится тогда поговорим.

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

Спасибо автору. Интересные статьи. Они натолкнули меня на поиск того, как сама идея WSGI может быть полезна в Perl. Ответ я уже нашел — никак, все необходимые абстракции от сервера уже существуют. Но, читая статьи, я хотя бы узнал, что в Питоне это существует и даже выделено в отдельный протокол. На самом деле, я считаю, что веб разработка без фреймворков сейчас невозможна. Другое дело, что фреймворки могут быть разного уровня сложности. Необязательно то, что фреймворк должен абстрагироваться от всего, от чего только можно. Я думаю, что если собрать и доработать в кучу весь тот код, приведенный в серии статей «Веб-разработка без фреймворков», то может получиться простой, но довольно таки не плохой... фреймворк:)

Вспомнилось почему-то интервью с создателями live journal. — Мы ненавидим изобретать колесо. Но если колесо не существует или оно квадратное — мы не боимся изобрести круглое колесо.Frenzy, какое количество разработчиков, уровень текучести и срок разработки нужен, чтобы почувствовать непреодолимую потребность именно в фреймворках? Я всегда основывал свой выбор на несколько иных критериях, поэтому мне очень интересно.

До чего людей Ява доводит — человеческий код уже романтика)

Ув. Сергей, Когда Вы себе бох и царь, можете делать всё, что угодно — это просто неважно, важно чтобы работало.Но как только доведется участвовать в команде, состоящей больше чем из N разработчиков разной квалификации (+должным уровнем текучести), на проекте, который придется поддерживать и дорабатывать не год и не два, сразу станет ясно зачем фреймворки, IoC, код аля сервлеты-шмервлеты и соответствие какому-то "правильно«Романтика это конечно хорошо.Только потом знаете что получается от обилия романтики? А то, что фразы проскакивают «А я ведь сразу сказал, на яве писать надо было! » Потому что у нас же все кулхацкеры, которым быстрей все самим написать, чем в этом... разбираться. Классика своего рода. Всегда так будет. Только в итоге всегда питон в тени, а вот о руби/груви/... все кричат направо и налево

Со всем полностью согласен, и добавить нечего =), спасибо.

Фреймворки не экономят время (на любом большом проекте это заметно). Главная их миссия — нести идею в массы. Позволять ньюбам быстро писать что-то работающее.Ньюбы не очень-то знают, что такое HTTP — зато они выучили HTML и знают магию, заставляющую запустить AJAX. Этого достаточно для владения фреймворком. На уровне «сделать простой сайт».Ты думаешь на уровне HTTP — и «небо не обрушивается» — спасибо, отличные слова. Все получается быстро и просто — Дзен по Питоновски. Но это — результат опыта и знаний (очевидное решение может не казаться таковым, если ты не GvR). Я сейчас делаю что-то вроде sqlalchemy для моей работы — просто потому, что должен работать с герерогенными базами, и они не далеко всегда предоставляют SQL фасад (django ORM не рассматриваем — ugly. SQLObject тоже сильно кривой). Результат — написал основу сам. Заимствовав у алхимии основы архитектуры. Оказалось — не слишком-то много работы. И тоже — небо не обрушилось. Другой вопрос — смог ли бы я сделать нечто подобное два года назад? Знаний и умений хватило бы? Давай таки остановимся на том, что «каждому — свое». А по мере профессионального роста стоит иногда попытаться увидеть привычную проблему с новой точки зрения.

Андрей, в целом со всем согласен, но всё же добавлю пару слов от себя, чтобы было ясно что я утверждаю, а что нет. Главное заявляемое преимущество фреймворков в том что они делают общие места «правильно» и что они экономят время. За это разработчик платит потерей гибкости в разработке, временем потраченым на изучение (всегда очень и очень немалым), зависимостью от разработчиков фреймворка и их идей. Действительно ли они экономят время? Действительно ли они делают всё лучше? Люди не пробовавшие альтернатив уверены что именно так.Я не выступаю за чистый WSGI, да и какой уж он «чистый»? Просто это стандарт и если не хотим писать адаптеры для каждой библиотеки в представление по «нашей идеологии», то нужно стараться слишком далеко от него не отходить. Попробую на пальцах объяснить как фреймворки могут быть ненужными и в больших приложениях, с интерфейсом итп. Вот самая основа: что такое веб приложение? Веб приложение это HTTP запрос -> HTTP ответ. То есть тупо функция принимающая HTTP запрос и возвращающая HTTP ответ. Аргумент / возвращаемое значение. Ну и еще ошибка — exception. Всё. Не мегадиспатчинг с убергибким темплейтингом, не, упаси боже, MVC и не что-то еще. Мне нравятся представления для запроса / ответа из WebOb, очень близко к реальному HTTP стандарту и напрямую работают с WSGI — отлично. А если превращать веб-приложения в сервлеты-шмервлеты, то получается соответствие какому-то «правильно», но чего ради я вот сейчас сказать не могу, подскажите кто-нибудь, хотя вроде кода написал в таком виде немало.Так вот, если нужно например использовать шаблон, то в конце такой функции берем и делаем вызов подстановки данных в шаблон — корона не падает, я проверял. И тому подобное по аналогии. Большое приложение получается не требовательней маленького. Веб-разработка превращается просто в разработку требующую знаний общих для области — HTTP стандарт, HTML, CSS, БД, возможно JS итп. Если не знать как это работает, то фреймворки позволяют накопипейстить что-то запускаемое, но тогда что получается, что это инструменты для клепания плохих сайтов? Я не берусь критиковать Pylons или Django, просто потому что я ими не пользовался в настоящих проектах. Я верю что они очень классные, что они рулят и бибикают и что пользуясь ими помощь к нескончаемым проблемам;) получить запросто. Это всё просто отлично. Утверждаю я другое: если быть проще и просто писать код просто делающий то, что требуется, небо не обрушивается. И для моего стиля, оказывается, выходит очень и очень много преимуществ.А вообще ничего точней чем «каждому — своё» в данном случае и впрвду не скажешь.

Сергей, всю серию читал с интересом.Вывод «для себя»: предлагаемый подход — «для профессионалов».Django хорош, если не хочется долго разбираться, а нужно «просто сделать сайт, и быстро». В нем уже очень много есть — плюс отличная документация (для кого-то это очень важно, я привык читать исходники). И большое community, contibs и прочее. Сильная завязка на базу данных — плюс и минус одновременно. Легко написать что-то работающее — и сложнее перестроить систему «под себя».Pylons требует больших знаний для изучения -, но гораздо гибче. Правда, многое нужно «делать с нуля» — и делать это можно самыми различными способами. В том числе и уродливыми. «Почувствовать» правильный путь может быть не легко. Документация — откровенно слабая (я уже говорил — для меня не критично). Друзья испытывали довольно сильное «трение вхождения».Чистый WSGI самый гибкий и одновременно самый требовательный. Слишком легко начать писать «не так». Но, одновременно, при правильно выбраном пути (чутье и опыт) — позволяет писать очень эффективно.Это — общий обзор. Не сомневаюсь, что Иван Сагалаев способен выкрутить из Джанги все, что ему нужно — он более чем отлично ее знает.Каждому — свое. И чем меньше нужно в конкретном приложении работать с пользовательским интерфейсом — тем более резонным становится выбор WSGI. Если нужно сделать web service с основным упором на API — зачем мне Джанга/Пилоны? (А есть еще нежно любимый мною twisted, который главным образом не для HTTP).Резонным выглядит разбиение проекта на отдельные сервисы и независимый для каждого сервиса способ реализации.На последнем exception разговаривал с парнем, который сказал: они используют twisted для долгоиграющих и системных нужд. Интерфейс пользователя — на Джанге (так проще и быстрее всего). Связь — через БД (узкое место, не для всяких задач подойдет. Но можно делать и иначе). Результатом более чем довольны.Резюме: для каждой задачи — свой инструмент, наиболее подходящий. И чем задача комплексней — тем больше различных инструментов требуется. Инструменты подбираются «под себя».Серебрянной пули не бывает.

Кстати подумайте, почему, если фреймворки это так хорошо, то почему они рождаются и дохнут пачками, почему постоянно переписываются, время от времени без обратной совместимости, почему существуют вопросы рода «как сделать кеширование в таком-то фреймворке» (и почему, чего ради, решение должно быть специальным?), почему случается что нормально работает только trunk итд итп? Это потому что, вот это «одинаковое приложение» никак написать не могут, а этому, в свою очередь, причиной то, что приложения оказывается не одинаковые.

Так я же и не говорю «всем надо делать напильники», я вообще «всех» не упоминал. Еще раз повторю, решения для «всех» это беда фреймворков.В моем опыте с определенного момента фреймворки стали только палками в колесах, я показываю к каким решениям в итоге я пришел. Как оказалось плюсов у такого подхода гораздо больше чем я сам предполагал, поэтому заодно пытаюсь показать это тем кто пишет иначе. Главная неожиданность что стало возможно писать как минимум столь же хороший, а чаще всего лучший код чем раньше, не заглядывая при этом в документацию, не выискивая способов вписаться в эти самые 99% итд. Выходит код лучше, времени в среднем тратится в три раза меньше, поддержка проще и никаких вопросов совметимости итп, так что можно сколько угодно не соглашаться с подходом, я то сужу по результату. У кого-то так не получится, ну так люди разные — ничего удивительного.

Сергей, если бы не было Pylons я бы с вами согласился, но все таки 99% веб приложений одинаковы, и изобретать всем напильники для WSGI как-то нерационально, имея под рукой такой неплохой набор который есть в Pylons и дополнив его своими личными (у нас это AJAX валидация, authkit, статистика). Да можно было бы это собрать самостоятельно, но сколько это времени бы заняло я не знаю. Кроме того, используя чужой код ты учишься писать свой, и главное ты можешь делать это постепенно.

Подписаться на комментарии