django vs. werkzeug или как урезать django?
nike
Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
django - так как django, по его словам, несет в себе достаточно много
функционала, который нам не потребуется, а нагрузка будет достаточно
большой - поэтому нам нужно использовать что-то очень легковесное (без
излишеств).
Я сам не юзал Werkzeug, но есть некоторые аспекты, которые, при
сопоставлении Werkzeug и django, меня реально смущают:
1. Комьюнити:
django в несколько раз больше, чем Werkzeug
2. Докуентация:
в django она КРУТАЯ и чтение ее оттяжно, а чтение доков Werkzeug -
напряжно. Субъективно, но, думаю, со мной многие согласятся.
3. Продакшн.
Последняя версия Werkzeug начинается на "0" (0.6) то есть до
стабильности чувакам далековато. Если не так, то хорошо.
Обращаюсь к группе не для холивара, а для ответа на вопрос: как
урезать django (или просто не подключать какие-то подули) так, чтобы
возросла производительность до уровня Werkzeug.
Что нам точно НЕ нужно: ORM, красивая административная панелька
Что точно нужно: теги, шаблоны, аннотации
Или может все-таки помучиться и разобраться с Werkzeug?
Stanislav Panasik
> Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
> django - так как django, по его словам, несет в себе достаточно много
> функционала, который нам не потребуется, а нагрузка будет достаточно
> большой - поэтому нам нужно использовать что-то очень легковесное (без
> излишеств).
Жизнь говорит о том, что более-менее используемый Hello World со
временем превращается в нечто, требующее либо кучи времени девелоперов,
либо ORM и всех прочих фич, имеющихся в Django.
Если вопрос о производительности - есть такая вещь, как nginx с SSI.
Можно кешировать разные динамические части сайта в memcached и подавать
через SSI директивы. Скорость раздачи будет фактически как у статики.
Так что не в фичах Django проблема, при наличии знаний.
С уважением, Стас
Andrey Popp
Отвечу по пунктам.
> 1. Комьюнити:
> django в несколько раз больше, чем Werkzeug
С этим согласен — Django намного популярнее.
> 2. Докуентация:
> в django она КРУТАЯ и чтение ее оттяжно, а чтение доков Werkzeug -
> напряжно. Субъективно, но, думаю, со мной многие согласятся.
Документация у Werkzeug, на мой взгляд, вполне адекватная, тем более
сама библиотека в разы меньше чем Django, как по количеству кода, так
и по предоставляемому функционалу. Если вам вдруг не будет хватать
документации — добро пожаловать на канал #pocoo на irc.freenode.net
(ник разработчика Werkzeug — mitsuhiko, мой — andreypopp).
> 3. Продакшн.
> Последняя версия Werkzeug начинается на "0" (0.6) то есть до
> стабильности чувакам далековато. Если не так, то хорошо.
Как раз нет — качество кода на уровне, я бы даже сказал, что оно много
выше чем у Django. Библиотека используется в продакшне — примеры можно
посмотреть тут http://werkzeug.pocoo.org/about/users.
> Обращаюсь к группе не для холивара, а для ответа на вопрос: как
> урезать django (или просто не подключать какие-то подули) так, чтобы
> возросла производительность до уровня Werkzeug.
Можно просто не использовать админку или ORM, но боюсь что скорость от
этого не возрастёт. С Werkzeug вы сами выбираете не каком уровне
абстракции будете работать и при необходимости можете опускаться
вплоть до WSGI, используя библиотеку только в тех местах, где это
необходимо.
> Что нам точно НЕ нужно: ORM, красивая административная панелька
> Что точно нужно: теги, шаблоны, аннотации
Если не нужна админка — это первый знак того, что нужно отказываться
от Django. Для шаблонов возьмите Jinja2, она написана авторами
Werkzeug.
> Или может все-таки помучиться и разобраться с Werkzeug?
Конечно!
--
Andrey Popp
phone: +7 911 740 24 91
e-mail: 8ma...@gmail.com
Владимир Корсун
производительность это никак не скажется, а вот выпиливанием
"ненужного" можно заниматься до пенсии.
Руководителю респект лично и совет не вешать уши, а читать документацию.
7 апреля 2010 г. 7:33 пользователь nike <hisma...@gmail.com> написал:
> --
> To unsubscribe, reply using "remove me" as the subject.
>
Stanislav Panasik
> от Django. Для шаблонов возьмите Jinja2, она написана авторами
> Werkzeug.
Если не нужна админка, просто не надо включать админку. Вопрос - какие
дополнительные ресурсы жрёт админка ?
Andrey Popp
Никакие, просто админка — это единственное преимущество у Django перед
остальными Python web-фрэймворками.
Stanislav Panasik
>> дополнительные ресурсы жрёт админка ?
>
> остальными Python web-фрэймворками.
Обоснуйте, пожалуйста.
Владимир Корсун
2010/4/7 Andrey Popp <8ma...@gmail.com>:
> Никакие, просто админка -- это единственное преимущество у Django перед
> остальными Python web-фрэймворками.
Andrey Popp
Я просто выразил своё личное мнение — если мне не нужна адмика, то я
обычно смотрю в сторону других web-фрэймворков.
В данном случае не нужна ни админка, ни ORM. Конечно использовать
Django можно, но зачем? Я бы выбрал Werkzeug или WebOb, тем более
предъявляются требования к производительности.
Stanislav Panasik
> обычно смотрю в сторону других web-фрэймворков.
Личное - имеется в виду субъективное ? Тогда зачем делать заявление, что
админка - это единственное преимущество Django, ведь это не так. Если
делаете такое заявление, то добавьте в конце, что оно опирается не на
факты, а на ощущения, это будет справедливо.
> В данном случае не нужна ни админка, ни ORM. Конечно использовать
> Django можно, но зачем? Я бы выбрал Werkzeug или WebOb, тем более
> предъявляются требования к производительности.
Итак, чем, на Ваш взгляд Werkzeug или WebOb лучше, чем Django в данном
случае, учитывая, что проект безусловно будет развиваться в дальнейшем ?
Т.е. речь не о "Hello World !". В каком месте производительность будет
меньше ? Ответьте, пожалуйста, на эти вопросы.
Andrey Popp
>> Я просто выразил своё личное мнение -- если мне не нужна адмика, то я
>> обычно смотрю в сторону других web-фрэймворков.
>
> Личное - имеется в виду субъективное ? Тогда зачем делать заявление, что
> админка - это единственное преимущество Django, ведь это не так. Если
> делаете такое заявление, то добавьте в конце, что оно опирается не на факты,
> а на ощущения, это будет справедливо.
Конечно субъективное :-).
>> В данном случае не нужна ни админка, ни ORM. Конечно использовать
>> Django можно, но зачем? Я бы выбрал Werkzeug или WebOb, тем более
>> предъявляются требования к производительности.
>
> Итак, чем, на Ваш взгляд Werkzeug или WebOb лучше, чем Django в данном
> случае, учитывая, что проект безусловно будет развиваться в дальнейшем?
Вы очень ошибаетесь, если думаете что приложения на WebOb/Werkzeug не
поддаются "развитию в дальнейшем". Я думаю, это понятие никак не
связано с каким-либо фрэймворком вообще — тут скорее дело в
архитектуре самого приложения. И на Django, я уверен, можно написать
такое, что потом даже не прочитаешь :-).
> Т.е. речь не о "Hello World !". В каком месте производительность будет
> меньше ?
Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
абстракции будете работать, сами описываете WSGI приложение.
Естественно, что таким образом, добиться большей производительности
будет легче чем с Django, которая иногда делает за разработчика
слишком много.
Я не говорю, что нельзя использовать Django, но для данной задачи я бы
выбрал Werkzeug.
Владимир Корсун
кастрация django или использование чего-то другого.
2010/4/7 Andrey Popp <8ma...@gmail.com>:
> 2010/4/7 Stanislav Panasik <span...@gmail.com>:
>>> Я просто выразил своё личное мнение -- если мне не нужна адмика, то я
>>> обычно смотрю в сторону других web-фрэймворков.
>>
>> Личное - имеется в виду субъективное ? Тогда зачем делать заявление, что
>> админка - это единственное преимущество Django, ведь это не так. Если
>> делаете такое заявление, то добавьте в конце, что оно опирается не на факты,
>> а на ощущения, это будет справедливо.
>
> Конечно субъективное :-).
>
>>> В данном случае не нужна ни админка, ни ORM. Конечно использовать
>>> Django можно, но зачем? Я бы выбрал Werkzeug или WebOb, тем более
>>> предъявляются требования к производительности.
>>
>> Итак, чем, на Ваш взгляд Werkzeug или WebOb лучше, чем Django в данном
>> случае, учитывая, что проект безусловно будет развиваться в дальнейшем?
>
> Вы очень ошибаетесь, если думаете что приложения на WebOb/Werkzeug не
> поддаются "развитию в дальнейшем". Я думаю, это понятие никак не
> связано с каким-либо фрэймворком вообще -- тут скорее дело в
> архитектуре самого приложения. И на Django, я уверен, можно написать
> такое, что потом даже не прочитаешь :-).
>
>> Т.е. речь не о "Hello World !". В каком месте производительность будет
>> меньше ?
>
> Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
> абстракции будете работать, сами описываете WSGI приложение.
> Естественно, что таким образом, добиться большей производительности
> будет легче чем с Django, которая иногда делает за разработчика
> слишком много.
>
> Я не говорю, что нельзя использовать Django, но для данной задачи я бы
> выбрал Werkzeug.
>
> --
> Andrey Popp
>
> phone: +7 911 740 24 91
> e-mail: 8ma...@gmail.com
>
>
Stanislav Panasik
> Конечно субъективное :-).
В таком случае это стоит подчёркивать.
> Вы очень ошибаетесь, если думаете что приложения на WebOb/Werkzeug не
> поддаются "развитию в дальнейшем". Я думаю, это понятие никак не
> связано с каким-либо фрэймворком вообще -- тут скорее дело в
> архитектуре самого приложения. И на Django, я уверен, можно написать
> такое, что потом даже не прочитаешь :-).
Ну так в чём же разница ? Раз Вы сами признаёте, что и то и другое можно
развивать, Django должен быть чем-то хуже, раз Вы его не выбрали бы.
Почему не выбрать Django, я пытаюсь понять это.
Пока что Ваш ответ очень похож на "я бы для этой задачи выбрал ASM, т.к.
он тоже расширяем, но работает быстрее, чем C"
При этом Вы не учитываете, что спецов, пишущих на ASM на порядок меньше,
и что развивать код на ASM под различные платформы приходится по-разному.
>> Т.е. речь не о "Hello World !". В каком месте производительность будет
>> меньше ?
>
> Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
> абстракции будете работать, сами описываете WSGI приложение.
> Естественно, что таким образом, добиться большей производительности
> будет легче чем с Django, которая иногда делает за разработчика
> слишком много.
Тем не менее, в каком конкретном месте производительность ниже ? Вы,
видимо, замеряли, хотелось бы посмотреть результаты тестов. Или, может
кто-то другой тестил? На главный вопрос ответа пока нет.
> Я не говорю, что нельзя использовать Django, но для данной задачи я бы
> выбрал Werkzeug.
Почему ?
Давайте так: либо Вы предоставляете факты (а не домыслы и ощущения), что
Django намного медленнее, жрёт намного больше ресурсов и менее удобен,
либо берёте свои слова, что "единственное преимущество Django - это
админка", назад.
Alexander Pugachev
Maxim Penzin
> Здравствуйте!
>
> Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
> django - так как django, по его словам, несет в себе достаточно много
> функционала, который нам не потребуется, а нагрузка будет достаточно
> большой - поэтому нам нужно использовать что-то очень легковесное (без излишеств).
Интересно было бы узнать аргументы руководителя для такой рекомендации.
А особенно характер задачи:
- быстро сделать
- легко поддерживать
- сложная архитектура и нестандартные требования
?
> Я сам не юзал Werkzeug, но есть некоторые аспекты, которые, при
> сопоставлении Werkzeug и django, меня реально смущают:
>
> 1. Комьюнити:
> django в несколько раз больше, чем Werkzeug
Далеко не всегда понятно, насколько оно полезно.
> 2. Докуентация:
> в django она КРУТАЯ и чтение ее оттяжно, а чтение доков Werkzeug -
> напряжно. Субъективно, но, думаю, со мной многие согласятся.
На мой взгляд документация по Django есть, и это хорошо,
но построена она просто ужасно - нечто среднее между
описанием API и девелоперского readme.txt.
Более-менее прилично сделанная документация у Java SDK.
> 3. Продакшн.
> Последняя версия Werkzeug начинается на "0" (0.6) то есть до
> стабильности чувакам далековато. Если не так, то хорошо.
>
> Обращаюсь к группе не для холивара, а для ответа на вопрос: как
> урезать django (или просто не подключать какие-то подули) так, чтобы
> возросла производительность до уровня Werkzeug.
Я бы не стал ожидать тут какой-то большой разницы в производительности.
Результат дает правильная архитектура,
и фреймворк стоит выбирать таким образом, чтобы он не мешал её строить.
> Что нам точно НЕ нужно: ORM, красивая административная панелька
> Что точно нужно: теги, шаблоны, аннотации
>
> Или может все-таки помучиться и разобраться с Werkzeug?
По крайней мере ознакомиться будет очень полезно.
Код у него весьма приятно выглядит.
Дух Django у меня во многом ассоциируется с Microsoft Visual Basic и PHP -
т.е. можно быстро добиться более-менее пристойных результатов,
что зачастую является решающим фактором в производстве ПО.
--
-- mpe...@gmail.com
-- www.penzin.ru
Maxim Penzin
> 2010/4/7 Stanislav Panasik <span...@gmail.com>:
>>>> Если не нужна админка, просто не надо включать админку. Вопрос - какие
>>>> дополнительные ресурсы жрёт админка ?
>>>
>>> Никакие, просто админка -- это единственное преимущество у Django перед
>>> остальными Python web-фрэймворками.
Справедливости ради надо добавить, что там еще есть
весьма занятный (удобный для новичков) ORM и взаимодействующие с ним Forms.
> В данном случае не нужна ни админка, ни ORM. Конечно использовать
> Django можно, но зачем? Я бы выбрал Werkzeug или WebOb, тем более
> предъявляются требования к производительности.
У Вас есть опыт работы Werkgeug и с WebOb?
Хотелось бы услышать впечатления и о том и о другом,
можно на емайл mpe...@gmail.com, так как тут всё же группа про Django ;)
Andrey Popp
> Ну так в чём же разница ? Раз Вы сами признаёте, что и то и другое можно
> развивать, Django должен быть чем-то хуже, раз Вы его не выбрали бы. Почему
> не выбрать Django, я пытаюсь понять это.
В плане возможности "дальнейшего развития" — никакой разницы, это я и
написал, при том, что судя по вашему сообщению, это ставилось в плюс к
Django.
>>> Т.е. речь не о "Hello World !". В каком месте производительность будет
>>> меньше ?
>>
>> Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
>> абстракции будете работать, сами описываете WSGI приложение.
>> Естественно, что таким образом, добиться большей производительности
>> будет легче чем с Django, которая иногда делает за разработчика
>> слишком много.
>
> Тем не менее, в каком конкретном месте производительность ниже ? Вы, видимо,
> замеряли, хотелось бы посмотреть результаты тестов. Или, может кто-то другой
> тестил? На главный вопрос ответа пока нет.
Просто повторю:
"Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
абстракции будете работать, сами описываете WSGI приложение.
Естественно, что таким образом, добиться большей производительности
будет легче чем с Django, которая иногда делает за разработчика
слишком много."
Stanislav Panasik
> абстракции будете работать, сами описываете WSGI приложение.
> Естественно, что таким образом, добиться большей производительности
> будет легче чем с Django, которая иногда делает за разработчика
> слишком много."
Вы думаете, что используя Django, нельзя решать, на каком уровне
абстракции работать ? Если да, то Вы плохо знаете Django.
Добиться большей производительности, не выходя за пределы фреймворка
вообще - невозможно, и не имеет значения, насколько тормознут фреймворк,
задачи повышения производительности решаются совсем другими средствами.
Есть ли ещё аргументы ?
И я не понял - что насчёт "единственного преимущества", таки слова назад
берём или нет ? ;-)
Andrey Popp
>> "Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
>> абстракции будете работать, сами описываете WSGI приложение.
>> Естественно, что таким образом, добиться большей производительности
>> будет легче чем с Django, которая иногда делает за разработчика
>> слишком много."
>
> Вы думаете, что используя Django, нельзя решать, на каком уровне абстракции работать ? Если да, то Вы плохо знаете Django.
> И я не понял - что насчёт "единственного преимущества", таки слова назад берём или нет ? ;-)
Stanislav Panasik
>
> Ну вот не нужно мне, чтобы оборачивала она WSGI environ в свой Request, что мне делать?
Каким образом это имеет отношение к уровням абстракции, не вижу никакой
связи, абсолютно. Однако, если хочется странного, можно написать свой
WSGIHandler, никто не запрещает. Система же модульная.
>> И я не понял - что насчёт "единственного преимущества", таки слова назад берём или нет ? ;-)
>
> Нет, вы же не привели никаких других преимуществ :-). Из разговора с вами я вынес только, что вы фанатично относитесь к Django и не желаете выбирать инструмент под задачу.
Я не привёл, т.к. другие привели, какой смысл повторять.
Фанатизм не при чём, просто голословные утверждения ни к чему, тем более
в профильной рассылке. Вы имеете свой взгляд на вещи, и это правильно,
но не надо его подавать в форме, принижающей и искажающей достоинства
других подходов. Это не инженерный подход, а как раз скорее фанатичный.
Я же попросил результаты тестов. Были бы результаты - было бы что
обсуждать. А так, кроме Ваших ощущений, ничем не обоснованных, говорить,
собственно, и не о чем.
Не хотите признавать неправоту - Ваше дело, я настаивать не буду.
Спасибо за внимание.
Alex Koshelev
On Apr 7, 2010, at 12:38 PM, Stanislav Panasik wrote:Нет, вы же не привели никаких других преимуществ :-). Из разговора с вами я вынес только, что вы фанатично относитесь к Django и не желаете выбирать инструмент под задачу.
> И я не понял - что насчёт "единственного преимущества", таки слова назад берём или нет ? ;-)
---
Alex Koshelev
Andrey Popp
Alexander Pugachev
Andrey Popp
Pashka R.
http://docs.djangoproject.com/en/dev/topics/db/aggregation/#aggregating-annotations
?
//wbr Pashka R. <pashka....@gmail.com>
2010/4/7 Alexander Pugachev <alexander...@gmail.com>:
Alexander Pugachev
barbuza
которая обычно используется в проектах на werkzeug.
Формы в django слабее аналогичных отдельных решений ( wtforms,
insanities ).
Роутинг в django предоставляет меньше возможностей чем роутинг из
werkzeug для аккуратной организации большого кол-ва правил и
заставляет писать регэкспы.
орм и админка топикстартеру не нужны. чем наша любимая жангочка лучше?
On Apr 7, 7:33 am, nike <hismato...@gmail.com> wrote:
> Здравствуйте!
>
> Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
> django - так как django, по его словам, несет в себе достаточно много
> функционала, который нам не потребуется, а нагрузка будет достаточно
> большой - поэтому нам нужно использовать что-то очень легковесное (без
> излишеств).
>
> Я сам не юзал Werkzeug, но есть некоторые аспекты, которые, при
> сопоставлении Werkzeug и django, меня реально смущают:
>
> 1. Комьюнити:
> django в несколько раз больше, чем Werkzeug
>
> 2. Докуентация:
> в django она КРУТАЯ и чтение ее оттяжно, а чтение доков Werkzeug -
> напряжно. Субъективно, но, думаю, со мной многие согласятся.
>
> 3. Продакшн.
> Последняя версия Werkzeug начинается на "0" (0.6) то есть до
> стабильности чувакам далековато. Если не так, то хорошо.
>
> Обращаюсь к группе не для холивара, а для ответа на вопрос: как
> урезать django (или просто не подключать какие-то подули) так, чтобы
> возросла производительность до уровня Werkzeug.
>
Stanislav Panasik
> Шаблоны в django слабее ( по возможностям и скорости ) чем jinja2,
> которая обычно используется в проектах на werkzeug.
Легко подключается к Django:
http://lethain.com/entry/2008/jul/22/replacing-django-s-template-language-with-jinja2/
> Формы в django слабее аналогичных отдельных решений ( wtforms,
> insanities ).
Чем слабее, не подскажете ? По пунктам желательно, с примерами.
> Роутинг в django предоставляет меньше возможностей чем роутинг из
> werkzeug для аккуратной организации большого кол-ва правил и
> заставляет писать регэкспы.
Что значит заставляет ? Это уже не фича, а помеха ? Роутинг в Django для
аккуратной организации позволяет включать файлы с урлами через include,
в werkzeug придумали ещё лучше ? Если да, то что ? Поясните, пожалуйста.
> орм и админка топикстартеру не нужны.
_Сейчас_ не нужны. Не нужны - можно и без них, никто не заставляет,
берёшь raw sql и вперёд.
> чем наша любимая жангочка лучше?
Чем хуже, объясните для начала. Сегодня тему уже вроде разобрали,
признали, что не хуже. Теперь Ваша очередь.
С уважением, Стас
Alexander Pugachev
barbuza
точно
On Apr 7, 3:41 pm, Alexander Pugachev <alexander.pugac...@gmail.com>
wrote:
> insanity это вот этоhttp://hg.barbuza.info/forminsanity/?
> Точно лучше?
>
> 2010/4/7 barbuza <barbuzas...@gmail.com>
Alexander Pugachev
barbuza
формсэты сделать, насколько я знаю, нельзя. из за этого, кстати, сосет
и жанговская админка.
роутинг жанги проигрывает роутингу werkzeug из за наличия в последнем
werkzeug.routing.Subdomain и werkzeug.routing.Submount (хотя самбаунт
и реализуется в жанге раскидыванием правил по разным файлам, из-за
чего теряется наглядность всего списка урлов)
про замену шаблонов мы не говорим, т.к. так можно заменить все
компоненты, а жангочка все-таки монолитный фрэймворк и прелесть его в
возможности сделать домашнюю страничку хомячка васи не подключая
дополнительный компонентов.
On Apr 7, 3:36 pm, Stanislav Panasik <spana...@gmail.com> wrote:
> Привет !
>
> > Шаблоны в django слабее ( по возможностям и скорости ) чем jinja2,
> > которая обычно используется в проектах на werkzeug.
>
> Легко подключается к Django:http://lethain.com/entry/2008/jul/22/replacing-django-s-template-lang...
Yury Yurevich
Здравствуйте!
Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
django - так как django, по его словам, несет в себе достаточно много
функционала, который нам не потребуется, а нагрузка будет достаточно
большой - поэтому нам нужно использовать что-то очень легковесное (без
излишеств).
Я сам не юзал Werkzeug, но есть некоторые аспекты, которые, при
сопоставлении Werkzeug и django, меня реально смущают:
Обращаюсь к группе не для холивара, а для ответа на вопрос: как
урезать django (или просто не подключать какие-то подули) так, чтобы
возросла производительность до уровня Werkzeug.
Или может все-таки помучиться и разобраться с Werkzeug?
--
wbr, Yury Yurevich
xmpp:the....@gmail.com
http://pyobject.ru/
myfreeweb
Если в фреймворке очень много лишнего, это _совсем_ не значит, что оно
загружается. Пока джанге не скажешь загружать, например, админку -- ее
как будто и нет. Можно вообще отключить нафиг все приложения из
contrib (которые на ORM завязаны), не использовать ORM, а
использовать, например, MongoDB.
С производительностью у Django все в порядке. Даже когда работает куча
всяких middleware и т.д., Django летает. Документация крутая,
согласен.
Werkzeug... фигня какая-то. Мне очень нравятся многие проекты Pocoo --
CleverCSS, Pygments, Jinja. Но...
Werkzeug вообще <<wsgi utility collection>>, а не фреймворк. Если на
низком уровне надо -- есть же отличный Tornado. Код на нем выглядит в
разы лучше, чем на этом поделии. А еще Google webapp ок (:
On Apr 7, 7:33 am, nike <hismato...@gmail.com> wrote:
> Здравствуйте!
>
> Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
> django - так как django, по его словам, несет в себе достаточно много
> функционала, который нам не потребуется, а нагрузка будет достаточно
> большой - поэтому нам нужно использовать что-то очень легковесное (без
> излишеств).
>
> Я сам не юзал Werkzeug, но есть некоторые аспекты, которые, при
> сопоставлении Werkzeug и django, меня реально смущают:
>
> 1. Комьюнити:
> django в несколько раз больше, чем Werkzeug
>
> 2. Докуентация:
> в django она КРУТАЯ и чтение ее оттяжно, а чтение доков Werkzeug -
> напряжно. Субъективно, но, думаю, со мной многие согласятся.
>
> 3. Продакшн.
> Последняя версия Werkzeug начинается на "0" (0.6) то есть до
> стабильности чувакам далековато. Если не так, то хорошо.
>
> Обращаюсь к группе не для холивара, а для ответа на вопрос: как
> урезать django (или просто не подключать какие-то подули) так, чтобы
> возросла производительность до уровня Werkzeug.
>
> Что нам точно НЕ нужно: ORM, красивая административная панелька
> Что точно нужно: теги, шаблоны, аннотации
>
barbuza
предназначены.
Vladimir Sidorenko
путаете теплое с мягким. werkzeug и tornado для сильно разных вещей
предназначены.
--
To unsubscribe, reply using "remove me" as the subject.
Alex Koshelev
формы в жанге крайне неудобно работают с формсэтами. и вложенные
формсэты сделать, насколько я знаю, нельзя. из за этого, кстати, сосет
и жанговская админка.
Что значит "нельзя"? Не положили в коробку?:-)
Вложенная форма - 20 строк кода, вложенный формсет 25. Витя, не надо распространять эти грязные сплетни, что мол чего-то нельзя:-) Вон, даже бойцы "Студии" умудрились такое написать.
---
Alex Koshelev
Kirill Zaborsky
С уважением,
Кирилл Заборский
2010/4/8 Alex Koshelev <daev...@gmail.com>:
Alex Koshelev
---
Alex Koshelev
Kirill Zaborsky
своим парсером возятся...
С уважением,
Кирилл Заборский
2010/4/8 Alex Koshelev <daev...@gmail.com>:
Alex Kamedov
2010/4/8 Kirill Zaborsky <qri...@gmail.com>:
barbuza
костылях - не ок.
и, насколько я понимаю, мы обсуждаем доступный функционал из коробки,
потому как дописать самому можно что угодно куда угодно.
On Apr 8, 12:50 pm, Alex Koshelev <daeva...@gmail.com> wrote:
> 2010/4/7 barbuza <barbuzas...@gmail.com>
bur...@gmail.com
обсуждать нужно доступный функционал + имеющиеся готовые библиотеки +
то, что можно написать в 3 строчки.
ну а большинство холиваров, типа вашего, вообще смысла не имеют.
я вот классифицирую фреймворки так:
на которых неудобно будет реализовывать задачу, и на которых удобно.
но для большинства задач, в любом случае, выиграют те, с которыми я
работал много, ведь чем больше работал, тем более удобно делать даже
сложные вещи, и наоборот.
в понятие "удобно" входит и чтение документации перед применением, это
причина, по которой ваши insanityforms формы просто не конкурент ни
WTForms, ни Django forms -- ну не показывает bitbucket вашу
документацию!
топикстартер умолчал о своей задаче, но часть аргументов он вкинул правильную.
а вы обсуждаете уже на 40 сообщений каждый своё представление о
фреймворках, причём, ни с кем ими не поделившись самим представлением,
а только рассказывая некоторые финальные выводы из вашего сравнения,
основанного на вашем представлении.
2010/4/8 barbuza <barbu...@gmail.com>:
> и, насколько я понимаю, мы обсуждаем доступный функционал из коробки,
> потому как дописать самому можно что угодно куда угодно.
>
> On Apr 8, 12:50 pm, Alex Koshelev <daeva...@gmail.com> wrote:
>> 2010/4/7 barbuza <barbuzas...@gmail.com>
>>
>> > формы в жанге крайне неудобно работают с формсэтами. и вложенные
>> > формсэты сделать, насколько я знаю, нельзя. из за этого, кстати, сосет
>> > и жанговская админка.
>>
>> Что значит "нельзя"? Не положили в коробку?:-)
>>
>> Вложенная форма - 20 строк кода, вложенный формсет 25. Витя, не надо
>> распространять эти грязные сплетни, что мол чего-то нельзя:-) Вон, даже
>> бойцы "Студии" умудрились такое написать.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
yokotoka
потребуется ORM - то ничего круче SqlAlchemy я не видел. Жаль, что
джангисты забросили идею прикрутить ее. Приходится костыляться с
джанговским недо-ORM.
Mikhail Kashkin
Здравствуйте!
Мой руководитель предлагает юзать Werkzeug в новом проекте, а не
django - так как django, по его словам, несет в себе достаточно много
функционала, который нам не потребуется, а нагрузка будет достаточно
большой - поэтому нам нужно использовать что-то очень легковесное (без
излишеств).
Я сам не юзал Werkzeug, но есть некоторые аспекты, которые, при
сопоставлении Werkzeug и django, меня реально смущают:
1. Комьюнити:
django в несколько раз больше, чем Werkzeug
2. Докуентация:
в django она КРУТАЯ и чтение ее оттяжно, а чтение доков Werkzeug -
напряжно. Субъективно, но, думаю, со мной многие согласятся.
3. Продакшн.
Последняя версия Werkzeug начинается на "0" (0.6) то есть до
стабильности чувакам далековато. Если не так, то хорошо.
Обращаюсь к группе не для холивара, а для ответа на вопрос: как
урезать django (или просто не подключать какие-то подули) так, чтобы
возросла производительность до уровня Werkzeug.
Что нам точно НЕ нужно: ORM, красивая административная панелька
Что точно нужно: теги, шаблоны, аннотации
Или может все-таки помучиться и разобраться с Werkzeug?
--
To unsubscribe, reply using "remove me" as the subject.
Stanislav Panasik
> и ничего не потеряешь. Даже почитая эту ветку, то видно что с русскоязычным
> сообществом вилы, единственного человека который знает еще несколько
> фреймворков и может поддержать высокий уровень разговора учат жизни. Причем
> те которым не хватило понять что-то еще. Поэтому сообщество не преимущество.
Во-вторых, если вопрос по теме django, и на него могут ответить, то, как
правило, отвечают. Так что сообщество - это всё-таки плюс, имхо.
> Django получил популярность именно из-за того что одноклеточные которым по
> телевизору сказали что "PHP — это для быдла" быстро бросили семки и побежали
> учить то на что им хватит мозга.
> Производительность Django улучшать не надо
Совершенно верно.
Ничто не может быть быстрее, чем генерация контента из памяти nginx-ом,
никакой Werkzeug и даже C с ASM-ом перемешанные. А уж с какой скоростью
работает фреймворк, это малозначимо. Всё равно всё упрётся в БД, и
фреймворк тут не критическое место.
От себя - желалось бы видеть в рассылке разговор умных людей об умных
вещах, а не базар быдла о семках :-)
С уважением, Стас
Maxim Penzin
>
> Совершенно верно.
>
> Ничто не может быть быстрее, чем генерация контента из памяти nginx-ом,
> никакой Werkzeug и даже C с ASM-ом перемешанные. А уж с какой скоростью
> работает фреймворк, это малозначимо. Всё равно всё упрётся в БД, и фреймворк
> тут не критическое место.
После этой классической фразы стоит добавлять
для стандартных сайтиков типа "мой блог" и "мегапорталл",
где основную нагрузку составляют неавторизованные пользователи,
читающие одинаковые страницы.
--
-- mpe...@gmail.com
-- www.penzin.ru
Stanislav Panasik
> После этой классической фразы стоит добавлять
> для стандартных сайтиков типа "мой блог" и "мегапорталл",
> где основную нагрузку составляют неавторизованные пользователи,
> читающие одинаковые страницы.
любом сайте. Основная масса просто читает и не постит ничего.
Авторизованные будут грузить базу данных, это узкое место, а не фреймворк.
Кстати, интересна была бы дискуссия, как ограничить влияние
авторизованных юзеров на нагрузку в плане того, что стоит отображать на
сайте, что не стоит, какие элементы сайта можно не менять в зависимости
от статуса юзера.
С уважением, Стас
Mikhail Kashkin
Ничто не может быть быстрее, чем генерация контента из памяти nginx-ом, никакой Werkzeug и даже C с ASM-ом перемешанные. А уж с какой скоростью работает фреймворк, это малозначимо. Всё равно всё упрётся в БД, и фреймворк тут не критическое место.
Dmitry Shevchenko
On May 14, 2010, at 18:54 , Mikhail Kashkin wrote:
> Можно например не читать каждый раз шаблончики с диска
Best regards, Dmitry Shevchenko.
Maxim Penzin
> Привет !
>
>> После этой классической фразы стоит добавлять
>> для стандартных сайтиков типа "мой блог" и "мегапорталл",
>> где основную нагрузку составляют неавторизованные пользователи,
>> читающие одинаковые страницы.
>
> По статистике, неавторизованных юзеров подавляющее большинство почти на
> любом сайте. Основная масса просто читает и не постит ничего.
Как раз выше и написано, что это верно для некоего среднестатистического сайта
типа "мой бложек" или "вечерний мухосранск".
Важный момент в том, что конкретного девелопера интересует не производительность
некоего обобщенного сайта, а его конкретный проект,
который, например, может быть вообще исключительно для
зарегистрированных пользователей.
И до выяснения этих моментов можно рассуждать только о сферических
конях в вакууме.
> Кстати, интересна была бы дискуссия, как ограничить влияние авторизованных
> юзеров на нагрузку в плане того, что стоит отображать на сайте, что не
> стоит, какие элементы сайта можно не менять в зависимости от статуса юзера.
Лично мое мнение в том, что на сайте надо отображать всё, что надо.
Другой вопрос, как это делать правильно.
Очень полезно бывает ненадолго забыть всякие молитвы типа
"nginx спасет мир", "memcached всё решает" и поразбираться, что
происходит на самом деле.
Например, может оказаться, что небольшой inprocess кэшик прямо в Питоне работает
эффективнее внешнего memcached
(новичкам внимание! надо четко представлять где чья память, как можно
использовать и как нельзя).
Или может так случиться, что один единственный LIMIT в SQL запросе
очень здорово меняет план его выполнения (explain наш друг),
да и сама база держит в ОЗУ немалый кэш, и если в него удается уложить
workset, то
это очень приятно.
Джанго предыдущей версии имела обыкновение парсить свои темплейты по чем зря,
и при вышеописанных условиях это может быть очень даже заметно.
Stanislav Panasik
> закрыть вопрос о производительности Django. Для тех сайтов для которых
> предназначен Django его ускорять не надо. Надо не делать на нем сайты для
> которых он не предназначен. Написал и забыл.
С уважением, Стас
Stanislav Panasik
>> По статистике, неавторизованных юзеров подавляющее большинство почти на
>> любом сайте. Основная масса просто читает и не постит ничего.
>
> Как раз выше и написано, что это верно для некоего среднестатистического сайта
> типа "мой бложек" или "вечерний мухосранск".
процентов 10, остальные тупо кликают по ссылкам. По количеству юзеров
далеко не бложек. Чем не пример ?
> Очень полезно бывает ненадолго забыть всякие молитвы типа
> "nginx спасет мир", "memcached всё решает" и поразбираться, что
> происходит на самом деле.
остального :-)
Просто очевидно, что ничего быстрее, чем чтение из памяти, быть не
может. Ну, чтение из кеша, но пока что не выпустили процессора с хотя бы
гигабайтным кешем :-)))
> Например, может оказаться, что небольшой inprocess кэшик прямо в Питоне работает
> эффективнее внешнего memcached
> (новичкам внимание! надо четко представлять где чья память, как можно
> использовать и как нельзя).
> Или может так случиться, что один единственный LIMIT в SQL запросе
> очень здорово меняет план его выполнения (explain наш друг),
> да и сама база держит в ОЗУ немалый кэш, и если в него удается уложить
> workset, то
> это очень приятно.
по сравнению с чтением из памяти.
С уважением, Стас
Mikhail Kashkin
так она уже :)
Dmitry Shevchenko
On May 14, 2010, at 19:15 , Mikhail Kashkin wrote:
> в випиэс за 5 баксов уже не залезет.
Stanislav Panasik
>>> в випиэс за 5 баксов уже не залезет.
> а вот это уже серьезный недостаток :(
firstvds.ru - самый дешёвый тариф, лезет. И работает нормально, если для
ваших задач хватает процессорных ресурсов пятибаксового.
Mikhail Kashkin
Maxim Penzin
>> Как раз выше и написано, что это верно для некоего среднестатистического
>> сайта
>> типа "мой бложек" или "вечерний мухосранск".
>
> Да ну ! Тот же digg - что там, все зареганы прям ? Да там зарегано может
> процентов 10, остальные тупо кликают по ссылкам. По количеству юзеров далеко
> не бложек. Чем не пример ?
А вот с Многоклассниками, Фейсбуками и Вконтактами все наоборот.
И о чем это говорит? - А ни о чём.
Это я опять к тому, что разработчика интересует не какой-то абстрактный
вебсайт, а вовсе даже конкретный, над которым ведется работа.
И запросто может оказаться, что такой сайт не совсем подходит под
понятие "обычный".
Все "обычные" уже давно сделали на Джумле :))
>> Например, может оказаться, что небольшой inprocess кэшик прямо в Питоне
>> работает
>> эффективнее внешнего memcached
>> (новичкам внимание! надо четко представлять где чья память, как можно
>> использовать и как нельзя).
>
> Хм. Есть сравнительные тесты ? Где почитать-посмотреть ?
Да что тут особо читать-то, всё очевидно
mc: 8.42546892166
pc: 0.162530899048
Но, еще раз повторю, это цифры для сферического коня в вакууме.
Есть варианты, когда без memcached'а никак, но есть случаи когда
без него в десятки раз быстрее.
>> Или может так случиться, что один единственный LIMIT в SQL запросе
>> очень здорово меняет план его выполнения (explain наш друг),
>> да и сама база держит в ОЗУ немалый кэш, и если в него удается уложить
>> workset, то это очень приятно.
>
> Это запросто. Но всё равно пределы оптимизации БД весьма и весьма узки по
> сравнению с чтением из памяти.
Оптимизация бд в большинстве случаев решает и будет решать,
пока основное количество данных у нас лежит на таких кругленьких пластиночках,
которые крутятся в маленьких железных коробочках.
Я просто акцентирую внимание на том, что всегда следует примерять
стандартные паттерны использования к конкретным случаям.
Stanislav Panasik
>>> работает
>>> эффективнее внешнего memcached
>>> (новичкам внимание! надо четко представлять где чья память, как можно
>>> использовать и как нельзя).
>>
>> Хм. Есть сравнительные тесты ? Где почитать-посмотреть ?
>
> Да что тут особо читать-то, всё очевидно
>
> http://gist.github.com/401412
>
> mc: 8.42546892166
> pc: 0.162530899048
>
> Но, еще раз повторю, это цифры для сферического коня в вакууме.
> Есть варианты, когда без memcached'а никак, но есть случаи когда
> без него в десятки раз быстрее.
напрямую из своей памяти процесс прочитает быстрее на порядки.
Я думал, что есть какой-то плагин для джанги, который добавляет новый
механизм кеширования.
Когда я говорю про nginx-memcached, там джанга только обновляет записи
кеша, а nginx не всегда обращается к джанге, а только тогда, когда в
кеше нету соотв. значения.
Изобретать велосипеды в виде самописных кешей дороже выйдет, чем юзать
готовые решения, мне так кажется.
К тому же, memcached может юзать несколько различных процессов, а такой
вот самописный кешик - только один. В общем, это нельзя сравнивать, это
всё равно что сравнивать горный велик и болид формулы-один, конечно
болид по камням не поскачет.
>>> Или может так случиться, что один единственный LIMIT в SQL запросе
>>> очень здорово меняет план его выполнения (explain наш друг),
>>> да и сама база держит в ОЗУ немалый кэш, и если в него удается уложить
>>> workset, то это очень приятно.
>>
>> Это запросто. Но всё равно пределы оптимизации БД весьма и весьма узки по
>> сравнению с чтением из памяти.
>
> Оптимизация бд в большинстве случаев решает и будет решать,
> пока основное количество данных у нас лежит на таких кругленьких пластиночках,
> которые крутятся в маленьких железных коробочках.
>
> Я просто акцентирую внимание на том, что всегда следует примерять
> стандартные паттерны использования к конкретным случаям.
Михаил
предназначенных. Надо будет записать.
14.05.2010 21:54, Mikhail Kashkin пишет:
> этом закрыть вопрос о производительности Django. Для тех сайтов для
> которых предназначен Django его ускорять не надо. Надо не делать на нем
> сайты для которых он не предназначен. Написал и забыл.
>
Alex Kamedov
Для тех, которые один раз написал и забыл?
2010/5/15 Михаил <glad...@gmail.com>:
Stanislav Panasik
> Надо сказать, что изобретать собственные "велосипеды" просто необходимо
> время от времени, чтобы не терять квалификацию и понимать суть вещей.
Интересная точка зрения. Возможно, изобретать и стоит, но вот
использовать - точно нет.
Скажем, Вы - на Новой Земле, медведей фоткаете, а тут бах, и с сайтом
что-то случилось, надо починить. Связи никакой, а бага в велосипеде.
Какова будет скорость исправления - ведь с этим придётся разбираться
человеку, который понятия не имеет, что там наизобретали.
Таким образом, лично для себя, в целях повышения квалификации,
велосипеды может и стоит изобретать, если время есть. Но в продакшен ни
в коем случае, потому что лучше заранее определить уровень разработчика
на поддержке проекта заведомо ниже своего. Это надёжнее, чем
расчитывать, что проектом займётся гений.
С уважением, Стас
Алексей С.
когда есть WSGI интерфейс, смысла в во всех этих фреймворках не вижу.
оффтоп: уважаемый Стас, какой то неадекватный пассажир
2010/5/15 Stanislav Panasik <span...@gmail.com>:
Maxim Penzin
> Привет, Максим !
>
>> Надо сказать, что изобретать собственные "велосипеды" просто необходимо
>> время от времени, чтобы не терять квалификацию и понимать суть вещей.
>
> Интересная точка зрения. Возможно, изобретать и стоит, но вот использовать -
> точно нет.
>
> Скажем, Вы - на Новой Земле, медведей фоткаете, а тут бах, и с сайтом что-то
> случилось, надо починить. Связи никакой, а бага в велосипеде. Какова будет
> скорость исправления - ведь с этим придётся разбираться человеку, который
> понятия не имеет, что там наизобретали.
Очень плохо организована работа, если дела обстоят именно таким образом.
Но Вы так пишете, как будто можно не писать своего кода вообще.
Или что все вот эти многочисленные сторонние плагины уже сразу
по определению не являются "велосипедами" только потому, что их написали
другие люди.
> Таким образом, лично для себя, в целях повышения квалификации, велосипеды
> может и стоит изобретать, если время есть. Но в продакшен ни в коем случае,
> потому что лучше заранее определить уровень разработчика на поддержке
> проекта заведомо ниже своего. Это надёжнее, чем расчитывать, что проектом
> займётся гений.
Ну как сказать, вот можно всё написать на голом ПХП.
По-вашему, от этого любой студент запросто разберется
что к чему и махом поддержит как надо?
Или вот такой пример - в приложении понадобилось сделать не сильно
замороченную очередь.
Сейчас есть две реализации, одна (persistent, reliable, multiple
producer, multiple comsumer)
не базе postgresql - (одна страница кода на Питоне), другая не
persistent сделанная тупо
через benastalkd просто потому, что на самом деле эту очередь там
нафиг не надо было
писать на диск, а по скорости подходят обе.
Как думаете, для человека который не видел ни то ни другое есть
большая разница в чем разбираться?
Для хорошей поддерживаемости кода очень важна его правильная организация,
т.е. структурированность, чётко определенные и прослеживаемые связи
между компонентами,
минимизация всяких неявных побочных явлений (здравствуйте Django signals!),
и конечно же внятное описание ключевых моментов.
Maxim Penzin
> я бы вообще использовал WebOb + библиотеки из Paste,
> когда есть WSGI интерфейс, смысла в во всех этих фреймворках не вижу.
Рекомендую поглядеть на werkzeug - вполне концептуальная вещь,
компактный и приятный код без всякого тяжкого наследия совместимости с
Питоном 2.3.
Stanislav Panasik
> Очень плохо организована работа, если дела обстоят именно таким образом.
разработчик сел смотреть код и натыкается на велосипеды, не то что
незнакомые, а неизведанные.
> Но Вы так пишете, как будто можно не писать своего кода вообще.
> Или что все вот эти многочисленные сторонние плагины уже сразу
> по определению не являются "велосипедами" только потому, что их написали
> другие люди.
сотни пар глаз, там и код и документация соотв. качества.
Да, я считаю, что "своего" кода должно быть минимум.
> Ну как сказать, вот можно всё написать на голом ПХП.
> По-вашему, от этого любой студент запросто разберется
> что к чему и махом поддержит как надо?
значит это осознанный выбор, и надо держаться в формате его
возможностей, либо расширять его функции согласно стандартам фреймворка.
> Или вот такой пример - в приложении понадобилось сделать не сильно
> замороченную очередь.
> Сейчас есть две реализации, одна (persistent, reliable, multiple
> producer, multiple comsumer)
> не базе postgresql - (одна страница кода на Питоне), другая не
> persistent сделанная тупо
> через benastalkd просто потому, что на самом деле эту очередь там
> нафиг не надо было
> писать на диск, а по скорости подходят обе.
>
> Как думаете, для человека который не видел ни то ни другое есть
> большая разница в чем разбираться?
быстрее.
> Для хорошей поддерживаемости кода очень важна его правильная организация,
> т.е. структурированность, чётко определенные и прослеживаемые связи
> между компонентами,
> минимизация всяких неявных побочных явлений (здравствуйте Django signals!),
> и конечно же внятное описание ключевых моментов.
С уважением, Стас
Maxim Penzin
> Привет, Максим !
>
>> Очень плохо организована работа, если дела обстоят именно таким образом.
>
> Причём здесь работа. Написали Вы код, сдали сайт, уехали в отпуск. А там
> разработчик сел смотреть код и натыкается на велосипеды, не то что незнакомые, а неизведанные.
Кажется я понял, в чем тут у нас разногласия.
Я здесь не рассматриваю варианты быстрого "наколенного" написания
сайтиков в одиночку.
Хотя да, для этого Джанга со своим набором тулзов подходит хорошо,
потому и стала так популярна.
> Если говорить о сторонних плагинах, то их, как правило, просматривают сотни
> пар глаз, там и код и документация соотв. качества.
>
> Да, я считаю, что "своего" кода должно быть минимум.
С этим понятно, см выше.
Я просто стараюсь работать не над сайтиками-из-конструктора,
а над проектами, где приходится решать разные нестандартные задачи.
>> Ну как сказать, вот можно всё написать на голом ПХП.
>> По-вашему, от этого любой студент запросто разберется
>> что к чему и махом поддержит как надо?
>
> пхп мы вроде бы не обсуждали.
Пример про ПХП был в качестве иллюстрации
"легко найти кого-то, кто что-то понимает в этом".
> Просто если Вы используете фреймворк, значит
> это осознанный выбор, и надо держаться в формате его возможностей, либо
> расширять его функции согласно стандартам фреймворка.
Очень интересный вопрос - кому надо?
И кто возьмется определять ту грань, когда следовать неким "стандартам
фреймворка"
становится нерентабельно?
>> Или вот такой пример - в приложении понадобилось сделать не сильно
>> замороченную очередь.
>> Сейчас есть две реализации, одна (persistent, reliable, multiple
>> producer, multiple comsumer)
>> не базе postgresql - (одна страница кода на Питоне), другая не
>> persistent сделанная тупо
>> через benastalkd просто потому, что на самом деле эту очередь там
>> нафиг не надо было
>> писать на диск, а по скорости подходят обе.
>>
>> Как думаете, для человека который не видел ни то ни другое есть
>> большая разница в чем разбираться?
>
> Думаю, что есть разница. Про beanstalkd он в инете найдёт информацию быстрее.
Я акцентирую внимание!
Имеется страница работающего кода (одна страница!), который делает
всё, что нужно.
Главный момент здесь вовсе не описание самого демона и протокола работы с ним,
основное это как и для чего всё это используется в приложении.
В данном случае код - лучшая документация.
Stanislav Panasik
> Я здесь не рассматриваю варианты быстрого "наколенного" написания
> сайтиков в одиночку.
> Хотя да, для этого Джанга со своим набором тулзов подходит хорошо,
> потому и стала так популярна.
>> Если говорить о сторонних плагинах, то их, как правило, просматривают сотни
>> пар глаз, там и код и документация соотв. качества.
>>
>> Да, я считаю, что "своего" кода должно быть минимум.
>
> С этим понятно, см выше.
> Я просто стараюсь работать не над сайтиками-из-конструктора,
> а над проектами, где приходится решать разные нестандартные задачи.
Нестандартные задачи, как правило, нестандартны только в какой-то
маленькой частности, всё остальное должно реализовываться стандартными
средствами.
К тому же, как я понял, когда Вам нужна была очередь, Вы сами что-то
написали, хотя были и другие варианты. Кстати, celery не рассматривали ?
Очень толковая вещь, большое комьюнити, работает надёжно.
> Пример про ПХП был в качестве иллюстрации
> "легко найти кого-то, кто что-то понимает в этом".
что даже тот же parser - это тоже php, но вот разберётесь ли Вы в нём за
5 минут - кое-как и кое-в чём, я не то что сомневаюсь, а уверен, что
нет. Хотя казалось бы, php. В общем-то, всё можно свести к двоичному
коду, не так ведь ? :-)
Я считаю, что тут мы не найдём общего языка, просто это разные школы,
что-ли. Есть школа, которая говорит - вперёд, рой землю, и всё
получится. А есть другая школа, которая говорит - подумай, перед тем,
как делать, иногда 1 строчка на баше стоит 10 тысяч строк на С. Я
стараюсь следовать принципам второй. Готов на эту тему дискутировать, но
без голословных утверждений, что чей-то путь заведомо уныл.
>> Просто если Вы используете фреймворк, значит
>> это осознанный выбор, и надо держаться в формате его возможностей, либо
>> расширять его функции согласно стандартам фреймворка.
>
> Очень интересный вопрос - кому надо?
> И кто возьмется определять ту грань, когда следовать неким "стандартам
> фреймворка"
> становится нерентабельно?
Нет человека, который не совершает ошибок, просто мы в силу своей
природы таковы.
Писали-писали, и тут оказалось, что выбрали не тот фреймворк. Бывает.
Очень часто бывает. Есть два варианта дальнейшего развития событий:
1) порвать с фреймворком, писать свой, под задачу (параллельно как-то
поддерживая рабочий код)
2) добавлять свою функциональность в фреймворк патчами. Не принимает в
основную ветку сообщество - сидеть на своём форке до тех пор, пока
заинтересованные люди, у которых аналогичные вашим проблемы, не доведут
градус накала до принятия. Или просто сидеть на своём форке.
Рентабельность тут определяется лёгкостью введения нового разработчика
среднего класса продвинутости в дело. Сколько ему потребуется времени,
чтобы вникнуть в вашу петрушку ? В случае, когда всё в рамках парадигмы
фреймворка, любой разработчик, владеющий фреймворком, войдёт в дело
достаточно быстро. Вот где проявляется эффективность подхода, которому
следую я.
> Я акцентирую внимание!
> Имеется страница работающего кода (одна страница!), который делает
> всё, что нужно.
> Главный момент здесь вовсе не описание самого демона и протокола работы с ним,
> основное это как и для чего всё это используется в приложении.
>
> В данном случае код - лучшая документация.
документация, нет, с этим я согласен, пожалуй, на 1100%.
Несогласие в том, что мы же с вами не в вакууме работаем. У кого-то PIL
под фрёй не собирается, у кого-то ещё что-то. Не бывает чистых вещей,
всегда всплывают какие-то детали. И тут, сюрприз, как раз проявляется
важность сообщества, которое юзает Ваш код и так и эдак, и у любого, кто
взялся его юзать в своём проекте, неожиданно всплывает куча информации
именно под его случай. Вот ведь в чём дело.
Я считаю, что умный человек должен учитывать, что его мысль будут читать
десятки глупых. Что разработчик, владеющий тонкостями платформы (в
данном случае я имею в виду скорее Python), должен учитывать, что его
код будут сопровождать люди, гораздо менее квалифицированные, чем он. Не
больше, не меньше. Это моя мысль.
Если вы (имеется в виду обращение к сообществу, а не к персоне, поэтому
с маленькой буквы) настолько умны, что можете сделать всё - не делайте
этого, сделайте то, что будет понятно большинству, не забывайте, что
максимум кривой IQ располагается в районе 100 единиц, а не там где
значение, которым вы гордитесь. Это полезнее для всего сообщества, а не
только для утверждения ЧСВ.
Надеюсь, я понятно изложил свою позицию. Вообще, что касается наших
родных пенатов, скажу односложно - неконструктивно. Нет юзабилити в
общении. Вот сами посмотрите и убедитесь -
http://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:IQ_curve.svg
Это жизнь, друзья мои, а не теория про когерентность кешей в SMP
системе. Рабочий код только тот, который понятен большинству, а на него
отдельные члены нашего сообщества не ориентируются, увы (как я понял).
===============================================================================
Оффтопик - предлагаю замутить конференцию django-russian-talks для
разговоров на около-джанговые темы, типа флейма и т.п. Потому что
засорять таким контентом основную конфу, имхо, нет смысла. А для
подписчиков, которым интересны и флеймы, это будет весьма интересно.
С уважением, Стас
Vadim Fint
(скажу - сочтёте за рекламу? =)).
Минусов у джанги вагон. Плюсы, впрочем, тоже есть. Поехали.
Минусы:
1. Идиотский темплейтный движок. Как жаль, ох как жаль, что не
догадались сразу прикрутить Jinja2. Используем Jinja2 в других
проектах с джангой - просто писаемся от восторга.
2. 90% фич не нужны. Ибо они просто ЧУДОВИЩНО медленные на больших
production базах. К примеру, тот же select_related. Ну есть у меня
10000 каких-то записей, у каждой из которых ForeignKey поле ссылается
лишь на 1 запись в другой таблице. И что мне теперь эту ещё одну
запись вытягивать 10000 раз?
3. Приложения не являются полноценными модулями для построения
модульной структуры. Можно конечно извращаться и использовать сигналы
как точки выхода, и какое нибудь api.py как точки входа - но.. сигналы
вызываются как попало, попытаться их вызывать "вот это после этого и
никак иначе" можно, но уже геморрой
4. Идиотский ORM. Хотя лучше - нету. Провоцирует использование хаков
на сложных запросов (типа pk__in=FakeSubquery()).
5. Нереально жуткие формы. Основной их минус - если поля зависят от
самих данных, то благополучно встаешь в тупик. Решается, заменив Form
на свой и используя его для наследования.
6. Упор на "ай одну строчку написал и все фурычит" вместо "написал и
работает эффективно" почти во всем.
7. Выполнения запроса в темплейтах. Да и вообще где попало "сам не
знаю где". Довольно быстро запросы без контроля могут превратится в
большую кашу. Конечно в темплейтах типа можно делать {% if %} и
выполнять кверисет, который приготовила вьюшка когда конкретно нужно.
Но именно это и превращает всё в кашу. Тем более - таким if-ам не
должно быть места в темплейтах. Зелёные разработчики прям так и не
могут удержаться от этого никак. В приложениях где каждый запрос надо
продумывать перед тем как писать - польза от такого ORM минимальна,
перед написанием filter(abc=d) все равно делаешь print queryset,
изучаешь чертов запрос, думаешь "да йопрст, ну что за идиотизм ты тут
собираешься делать, почему не просто ...". Как результат - тратишь
УЙМУ времени, да запрос руками быстрее можно было бы написать. Конечно
можно и писать руками, но как ловко сделать модельки из запроса, чтобы
save() работал? А через жопу - выбрать список ID своим "суперским"
запросом, а потом выбрать модельки через id__in=[pks]. Глупо? Очень.
Впрочем, все минусы которые были для нас очень существенны - мы
переписали нахрен в самой джанге (несколько патчей попало и в транк
=)), либо жестко регламентировали между собой (напрмимер, "никаких
запросов в теплейтах!"). В Debug режиме даже проверяется откуда пришёл
"пинок" на выполнение запроса и в тестах это проверяется.
Плюсы.. orm хоть и тупой, но он действительно работает. В тех случаях
когда речь не идёт о сложных и важных запросах - проще ничего нет.
Плюс абсолютное молчание и аккуратная обработка потери соединения,
маппинга к текущему потоку и проч вещах (чего в werkzeug очень
хромает, пока не потратишь уйму времени чтобы реализовать как в
джанге). Больше для меня плюсов в джанге нет. Извращение с
settings.py, думаю, все переписывают. У нас так вообще настройки
берутся из yaml, потом из global_settings, потом из local_settings и
ещё нескольких мест, где все можно оверрайдить. Равно как и пропатчена
джанга, чтобы позволять структуру вида app.web.webapp.models,
app.tools.toolsapp.models и тп
Вообще, я несколько разочарован в ней. Но не в джанге как фреймворку,
а в джанге как в фреймворке для серьёзных бизнес-приложений. Там ей
совсем не место.
Тесты.. эм.. это было первое что мы переписали почти целиком =)
Поэтому даже не в курсе как там в джанге сейчас. У нас есть даже
forked test runner для быстрых тестов в sqlite3 + memory на
многопроцессорных машинах. А вот для тестов mysql/postgresql изрядно
бесит то время которое требуется для создания всего что нужно в бд
перед каждым тестом. У нас это 0.5сек при более 100 таблицах.
Провоцирует на написание больших тестов, которые тестят весь блок
целиком, вместо горки маленьких.
Werkzeug.. были попытки. В чем то намного круче джанги, но надо всё
реализовать самому. SQLAlchemy по стабильности на мой взгляд
проигрывает джанге всё-таки.
Если я займусь новым проектом, то это явно будет свой фреймворк.
Обязательно нужно адекватные программные модули с точками входа/выхода
и прочей инфраструктурой. И независимые от имен модулей питона. Чтобы
можно было взять просто модуль скопировать в папку где модули и чтобы
все заработало сразу (к нему присобачились бы модули которые могут с
ним работать, а он соответственно к тем, с кем умеет). Модульность
должна быть абсолютной -- даже сам факт веб-приложения должен быть
модулем (типа поддержка модулей, которые могут рендерить страницы). В
таком случае может конечно получиться ещё одна жопа (Zope которая),
но, думаю, может и не получится. Основной упор делать на эффективность
получаемых приложений. Как касательно работы с бд так и всего
остального. В джанге кеш темплейтов появился-то совсем недавно только!
Сделать нормальный тестраннер, который блин сможет запускать тесты
которым не нужна бд параллельно и не создавая этой самой бд для них. В
базовой поставке - только ядро. Всё остальное - модули - хочешь качай,
хочешь не качай. Только так ядро может развиваться быстрее (ибо
например, есть v1 и потом делают ядро v2 и пофиг что GIS пока работает
только на v1. Как обновят - так заработает, но это не мешает релизу
самого ядра). Надо ПРОВОЦИРОВАТЬ людей писать эффективные программы.
Предупреждать автоматически если у тебя на странице 100 одинаковых
запросов оказывается, ну или близких по духу, которые можно зашвырнуть
в 1. Надо запрещать творить что попало в темплейтах ну или хотя бы не
советовать этого. Python язык не со строгой типизацией, но блин
использовать это во вред умеет по-моему уже каждый второй. Хотя бы
функции-универсалы do_it(something), когда something - хоть строка,
хоть массив, хоть яблоко, хоть тумбочка. Это круто для pprint. Но это
уродство для filter(field_value=).
Резюмируя скажу - джанга для корпоративных сайтов и мелких порталов.
Не более. Если захочется использовать её в большом проекте - то, так
же как и мы, перепишете половину ядра джанги под свои нужды =). И
постоянно будете зажаты в рамки, которые в общем-то нафиг не нужны.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/15 Stanislav Panasik <span...@gmail.com>:
Eugene Kryukov
----------------------------------------------
С уважением, Евгений Крюков
bur...@gmail.com
Хотелось бы, чтобы все посты в django-russian были такими :)
Да и не только в django-russian, но и чтобы твой пост был повторён на
английском языке в группе django-developers, пусть даже через
онлайн-транслятор.
И хотелось бы ещё больше конкретики. Фактов.
Например, остались ли те же проблемы в Django 1.2.
Попробую сейчас в ответ сформулировать проблемы, которые были у меня.
И если есть решения, то буду их тоже писать.
1) Конфигурация.
1.1) Подключение мелких компонент.
Использую симлинки. Потому что virtualenv ещё хуже, поддержка
используемых несколькими проектами плагинов превращается в пытку.
1.2) Отсутствие модульной настройки приложений.
Всё планирую заточить для себя
http://github.com/jabapyth/django-appsettings , да никак руки не
доходят.
1.3) Отсутствие настройки media для приложений.
1.4) Отсутствие точек подключения в шаблонах. Есть
http://code.google.com/p/django-app-plugins/ , но они какие-то
дурацкие, потому что очевидно, что для extension_point нужно писать
вьюшку, а не шаблон.
2) Денормализованные поля и ORM в целом.
Тут я не знаю хорошего проекта, да и вообще, не в курсе последних
разработок. Мне нужно было год назад, а тогда ничего не было.
Что интересно, у меня действительно почти не возникает проблем с ORM,
даже для больших баз данных.
Мне кажется, тут дело в том, что проблемы с ORM возникают из-за
неудачных архитектурных решений при планировании структуры базы
данных, а я очень тщательно планирую БД и стараюсь сводить количество
будущих проблем к минимуму.
3) Инклуды.
Проблема: дублирование в шаблонах кода структурных блоков html,
скажем, для формочек или кнопочек.
Поборол с помощью http://github.com/buriy/django-containers
Только всё равно дизайнерам, пишущим шаблоны, морально тяжело их
писать и использовать.
4) 3rd-party плагины, которые проще переписать целиком, нежели править
в них баги:
4.1) зачастую нужно было использовать паттерн "Controller" вместо кучи вьюшек
4.2) шаблоны нельзя переиспользовать, нужно выкидывать и писать свои
4.3) reverse у 3rd-party плагинов временами конфликтует
4.4) бывает, вьюшки не расширяемые
4.5) временами авторы неправильно используют middleware и теги.
4.6) отсутствие единообразного способа подключить media
4.7) для большинства приложений или нет админки, или есть, но такая,
что лучше бы её не было!
Короче, в целом, отсутствие культуры и низкий уровень 3rd-party
плагинов. Тут друпал на 10 лет впереди!
5) Админка
5.1) Инкрементальное написание
Решил, написав http://github.com/buriy/django-superadmin
5.2) Уродские виджеты для FK и M2M, отсутствие виджетов для Date,
Duration, Color, картинки для ImageField.
Немножко помогают собранные мной из разбросанных по интернету кусков
http://github.com/buriy/django-extrafields
5.3) Сложность написания своей вьюшки для админки -- нет удобных готовых блоков.
5.4) Наивный подход создателей: "админка нужна только для редактирования":
не хватает встроенного права на чтение таблицы,
нет удобной конфигурации, кто может управлять объектами,
хаки чтобы выводить разные поля для разных пользователей,
хак, чтобы добавлять свои фильтры
(Тут тоже друпал на 10 лет впереди...)
5.5) Приходится тщательно продумывать базу данных, чтобы удобно было
её выводить в пользовательском интерфейсе, особенно это забавно делать
для таблицы из 10 записей.
6) Сложный деплоймент.
Хотелось бы команду, которая сгенерирует настройки для веб-сервера.
Увы, пока нету. И не будет, пока настройки media для плагинов не будут
храниться.
7) проблемы копирования данных
Пришел к выводу: loaddata/dumpdata не готовы к реальному использованию.
Единственное, для чего пригодны -- для формирования fixture.
Использую команду на основе loaddata, которая выдирает из БД только
запрошенные таблицы и объекты.
Отлично помогает, когда основная БД занимает сотни гигабайт.
А для копирования базы целиком использую нативный дамп базы данных.
Работает быстро и качественно.
8) Базы данных
Отсутствие поддержки нескольких баз данных до Django 1.2.
Для компании с десятками различных баз данных и весьма дурацкими
взаимодействиями между ними, было критически важно.
Приходилось писать API, фактически дублирующее ограниченный доступ к
базе данных, или же писать SQL для всех баз данных, кроме основной (а
sqlalchemy тянуть за собой не хотелось, да и если с ним -- всё равно
неудобно!).
Слава богу, хоть теперь с этим проблем нет.
В последнее время напрягает отсутствие поддержки NoSQL баз данных,
хотя бы даже просто поддержка в виде Model и QuerySet, пусть и без
join-ов: очень хочется иметь единый интерфейс.
9) Динамические формы.
Намного больше геморроя, чем со статическими, и нужно тратить намного
больше времени чтобы тестировать правильность работы UI. Это вообще
относится к любой динамике. Ну нету встроенных средств, как в rails.
10) Неудобно писать команды.
Решил очень просто: написал скрипт "django", который может запускать
питонячий файл, подставляя ему DJANGO_SETTINGS_MODULE (
http://github.com/buriy/bash-commands/blob/master/django -- извините,
язык bash знаю плохо, сейчас бы переписал на питоне, но всё не до
этого).
11) Всякие неприятные мелочи.
Опишу только наиболее существенные, для них я написал патчи:
Перезагрузка devserver-а работает не всегда
(http://code.djangoproject.com/ticket/8413),
зажевывание ошибок джангой (
http://github.com/buriy/django/commit/9a7ce8f5405909928b79cc89b1b429c4170c9c68
),
плохая отладочная информация ( http://code.djangoproject.com/ticket/11834 ).
отсутствие цветов для консоли windows
(http://github.com/buriy/django/commit/6a6c331c0f0482897853988a8de7735b82d981ac
)
Но я не ропщу -- я знаю, что в остальных фреймворках всё обстоит гораздо хуже!
Некоторые рамки есть, но я рад, что большинство мелочей Django
действительно берёт на себя!
Сессии, работа с HTTP-запросом, кеши, autoescape, интернационализация, итп.
Большинство принятых архитектурных решений были удачными, а неудачные
решения были приняты исключительно на безрыбьи (это значит, авторы
джанги с радостью в течение года примут в trunk ваш качественный патч,
как бы они вас не убеждали в том, что они берут патчи только по
знакомству) или же достались в наследство (и большинство из них
сосредоточено в django.contrib.* -- он просто не успевает за
изменениями в django !).
А свои наколенные фреймворки от этих самых неудачных решений гораздо
больше страдают -- в них мучительно сложно писать то, что ещё не
написали создатели, и для чего нет готового плагина!
2010/5/26 Vadim Fint <mock...@gmail.com>:
> Кому интересно. Опыт использования Django в довольно крупном проекте
> (скажу - сочтёте за рекламу? =)).
...
> Резюмируя скажу - джанга для корпоративных сайтов и мелких порталов.
> Не более. Если захочется использовать её в большом проекте - то, так
> же как и мы, перепишете половину ядра джанги под свои нужды =). И
> постоянно будете зажаты в рамки, которые в общем-то нафиг не нужны.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Vadim Fint
Дело в том, что да, можно, но в таком случае джанга будет только мешаться.
Там нет способа ноормально создавать процедуры (хотя вру, south это позволяет)
Там нет способа нормально вызывать процедуры.
Там нет способа вообще нормально вызывать свои запросы и оборачивать
результат в кверисет.
Конечно это всё _можно_. Ведь питон да и исходники открыты - делай что
хочу. Но возня со всем этим становится дольше, чем выхлоп пользы от
использования. Админку в больших проектах тоже особых смыслов
использовать нет. В итоге получается что 90% джанги не используется,
потому что создано для мелких/не высоконагруженных проектов (типа
рабочая сила дешевле серваков =) так-то оно так, пока серваков уже не
100 и перспектива ускорить проект в два раза - -50 серверов сразу.
Оооочень много деняг).
Я же сделал акцент на том, что считаю джангу хорошим фреймворком. Но
не для высоконагруженных приложений. Для них нужен не фреймворк, а
продуманная инфраструктура. С уровнем абстракции повыше чем
продуманная инфраструктура под названием "чистый питон" +)). Ну
банально - у нас есть такие запросы, которые мы делаем через джангу,
но на построение которых (т.е. до непосредственного вызова as_sql())
уходит просто уйма процессорного времени. До 0.05сек в фатальных
случаях. Просто тупо чтобы слепить запрос. И это делается каждый
чертов раз, хотя в запросе только условия обычно меняются. Для
простого проекта никто даже задумываться об этом не будет, а вот для
высоконагруженного - цена таких вещей слишком высока.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/26 Eugene Kryukov <doct...@gmail.com>:
Vadim Fint
the right tool for the right job и больше ничего никого не волнует.
> Например, остались ли те же проблемы в Django 1.2.
а мы вообще сидим постоянно на dev сборках последней джанги + море наших патчей.
так что 1.2 у нас уже тыщщу лет =). Зато постоянно проходим через АД
запуска всех тестов самой джанги на mysql-isam базе =). (вот тут и
вылезает отчетливо проблема о которой я писал - подготовка бд к
каждому тесту занимает уйму времени).
> 1.3) Отсутствие настройки media для приложений.
кстати да. Но мы для себя это сделали + чтобы в приложении был набор
css-ок, который при сборке
автоматом собирается в один гигантский css для всех подключенных приложений.
У нас вообще нельзя ничего запустить до ./waf install :). Зато активно
используется препроцессинг и хардлинки (чтобы после билдинга можно
было просто редактировать питоновские файлы в src/). Поэтому я этой
схемой (был эксперимент =)) НАСТОЛЬКО доволен, что теперь вряд ли буду
от неё отходить.
Билдинг проекта позволяет извращаться с media и прочими штуками в куда
более гибкой форме (билдить и js например, устраивать препроцессинг
питона).
> 2) Денормализованные поля и ORM в целом.
> Тут я не знаю хорошего проекта, да и вообще, не в курсе последних
> разработок. Мне нужно было год назад, а тогда ничего не было.
> Что интересно, у меня действительно почти не возникает проблем с ORM,
> даже для больших баз данных.
> Мне кажется, тут дело в том, что проблемы с ORM возникают из-за
> неудачных архитектурных решений при планировании структуры базы
> данных, а я очень тщательно планирую БД и стараюсь сводить количество
> будущих проблем к минимуму.
Большие бд - это у вас там где много данных в 10 таблицах, или где
много данных в 110 таблицах? )
Причём они все друг с другом связаны как-либо и зачастую используют
сложные древовидные структуры,
сложные кеширующие таблицы прав доступа (с 20-30 миллионами записей).
И ты понимаешь, что четкими запросами в бд можно выжать ещё процентов
40 скорости.
Я уж не говорю про иногда требуемые хаки (например, известный where xx
IN (SELECT x.id FROM (SELECT x.id FROM ... ) as mysql_oh_my_god))
> 3) Инклуды.
> Проблема: дублирование в шаблонах кода структурных блоков html,
> скажем, для формочек или кнопочек.
> Поборол с помощью http://github.com/buriy/django-containers
> Только всё равно дизайнерам, пишущим шаблоны, морально тяжело их
> писать и использовать.
А мы наворотили систему своих виджетов =). Не могу сказать что доволен
скоростью их работы (впрочем, ко всей темплейтной системе джанги
притензии), но зато получилось очень удобно.
Типа {% widget my_widget attr=value attr_from_context %} и {% widget
my_widget %}{% expr range(15) as attr %}{% endwidget %} :) Самое
ценное что из приложений виджеты автоматом беруться и есть даже {%
loadwidget %} :). Если бы использовали jinja - это ВООБЩЕ не было бы
нужно.
> 7) проблемы копирования данных
> Пришел к выводу: loaddata/dumpdata не готовы к реальному использованию.
> Единственное, для чего пригодны -- для формирования fixture.
> Использую команду на основе loaddata, которая выдирает из БД только
> запрошенные таблицы и объекты.
> Отлично помогает, когда основная БД занимает сотни гигабайт.
> А для копирования базы целиком использую нативный дамп базы данных.
> Работает быстро и качественно.
Стоило только посмотреть в dumpdata/loaddata чтобы понять что эта дура
будет жрать нереальное (отнюдь не линейное) количество памяти для
вытаскивания данных.
У нас оказалось всё ещё хуже - нам функционал "сохранить бекап из бд"
нужен был позарез ещё и в разрезе "восстановить бд в ДРУГОЙ бд". Т.е.
mysql -> sqlite3 например.
В итоге получились две команды manage.py: backup и restore, которые
могут бекапить из любой бд и восстанавливать бекап в любую (условие -
чистая бд перед restore). Сохраняется всё в своём формате - который
предельно прост:
# table: col1, col2, col3
datacol1; datacol2; data\;col3
И вытагивается так, чтобы все внешние ключи можно было легко собрать
(т.е. в нужном порядке). Скорость - линейная, памяти не ест
практически вообще. Использует SSCursor, т.е. делает use_result.
Особенно круто что получилось 212 строчек =) (для обеих команд
сразу!). А простые вещи рулят ведь....
> 10) Неудобно писать команды.
> Решил очень просто: написал скрипт "django", который может запускать
> питонячий файл, подставляя ему DJANGO_SETTINGS_MODULE (
> http://github.com/buriy/bash-commands/blob/master/django -- извините,
> язык bash знаю плохо, сейчас бы переписал на питоне, но всё не до
> этого).
Я для этого сделал как мне кажется мини-революцию. И не только для
джанги, а для разработки в консоли вообще.
Собираюсь всё это дело оформить в отдельный проект (MIT) и рассказать
уже всё подробно. Моя штука очень глупоко использует возможности zsh
(в прошлом - bash, но может работать с обоими вариантами) =). А пока -
тссссс =)
> Но я не ропщу -- я знаю, что в остальных фреймворках всё обстоит гораздо хуже!
> Некоторые рамки есть, но я рад, что большинство мелочей Django
> действительно берёт на себя!
> Сессии, работа с HTTP-запросом, кеши, autoescape, интернационализация, итп.
Completely agree. У меня к джанге точно такое же отношение
> 2010/5/26 Vadim Fint <mock...@gmail.com>:
>> Кому интересно. Опыт использования Django в довольно крупном проекте
>> (скажу - сочтёте за рекламу? =)).
> ...
>> Резюмируя скажу - джанга для корпоративных сайтов и мелких порталов.
>> Не более. Если захочется использовать её в большом проекте - то, так
>> же как и мы, перепишете половину ядра джанги под свои нужды =). И
>> постоянно будете зажаты в рамки, которые в общем-то нафиг не нужны.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
>
Dmitry Shevchenko
Там нет способа вообще нормально вызывать свои запросы и оборачивать
результат в кверисет.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
Vadim Fint
слепить из них модельки.
Но смысл то в том, чтобы можно было бы делать что-то вроде:
Item.objects.raw('select * from items limit 10').filter(col=XX).
Т.е. чтобы кверисет можно было бы трансформировать дальше. Я понимаю
что это нереализуемо, но это касяк самой системы ORM в джанге -- она
совсем не дружественна к таким желаниям.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Dmitry Shevchenko <dmi...@gmail.com>:
> raw() не подходит разве?
Vadim Fint
class FakeQuery(object):
def as_sql():
return 'SELECT id FROM items WHERE id IN (%s, %s, %s)', [1,2,3]
def prepare(self): return self
Item.objects.filter(pk__in=FakeQuery()).filter(col=1)
Казалось бы для этого можно использовать extra, но тогда надо будет
знать точный альяс таблицы (если она не основная).
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Vadim Fint <mock...@gmail.com>:
bur...@gmail.com
есть тоже какая-то функция.
2010/5/27 Vadim Fint <mock...@gmail.com>:
--
Eugene Kryukov
DB2 -- select * from table fetch first 10 rows only
Informix -- select first 10 * from table
Microsoft SQL Server and Access -- select top 10 * from table
MySQL and PostgreSQL -- select * from table limit 10
Oracle -- select * from (select * from table) where rownum <= 10
Поэтому лимит при фетче - на мой взгляд самый правильный.
А что качается всего остального: если планируется серьезная нагрузка, работа с сотнями тысяч или миллионами строк, то сделать кросс-платформенное, одинаково быстро работающее на разных базах, приложение невозможно - требуется разработка с ориентацией на конкретную базу с учетом средств тюнинга , предоставляемой самой базой. Более того, приложение, к примеру, заточенное под Oracle, даже на похожих железках под сервер БД может вести себя очень по-разному.
А вот реализовать правильную работу django с базой вполне можно, конечно, не так быстро, но для таких проектов сроки обычно другие. Во всяком случае, под django это однозначно быстрее, нежели под каким-нибудь JSF (бррр).
----------------------------------------------
С уважением, Евгений Крюков
Vadim Fint
создания условий и подзапросов таких, на которые ORM не способен, но
чтобы всем остальным занимался всё-таки ORM. Глупо когда в 1 месте
надо написать небольшой "левый" джоин, ну не переписывать же весь
запрос который джанга генерит целиком!
> А что качается всего остального: если планируется серьезная нагрузка,
> работа с сотнями тысяч или миллионами строк, то сделать
> кросс-платформенное, одинаково быстро работающее на разных базах, приложение
> невозможно - требуется разработка с ориентацией на конкретную базу с учетомр).
Для таких проектов сама идея ORM неприменима. Если мы действительно о
_ТАКИХ_ проектах, где несколько серверов бд возятся без устали над
обработкой запросов от нескольких десятков фронтендов.
Хотя бы потому что: мне важно выбрать БД с начала, но после выбора мне
кроссплатформенность (поддержка разных бд) не нужна вообще. Равно как
и после билдинга - ну не нужна и всё тут =). Зато тот факт что
построение самого запроса отнимает уйму времени, каким бы простым ORM
не был - это очень и очень плохо. Должен быть хелпер для построения
запросов на стадии билдинга проекта, но никак не во время уже
обработки веб-страниц.
Но это всё вообще к джанге не относится. Я ругался лишь из-за того что
когда надо чуть чуть усложнить добавив какое-нибудь диковатое своё
условие - очень тяжело, ибо при проектировании ORM они об этом не
задумываются, наоборот стараясь абстрагировать работу с БД до
максимума. Вот.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Eugene Kryukov <doct...@gmail.com>:
Vadim Fint
А альясы вроде T{N} вы видели? Невозможно нормальным образом получить
этот альяс к такой-то сджойненой таблице.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 bur...@gmail.com <bur...@gmail.com>:
Pavel Reznikov
//wbr Pavel Reznikov <pashka....@gmail.com>
2010/5/27 Vadim Fint <mock...@gmail.com>:
Kirill Zaborsky
использовать язык с динамической типизацией, по-моему.
С уважением,
Кирилл Заборский.
2010/5/27 Vadim Fint <mock...@gmail.com>:
Eugene Kryukov
С уважением, Евгений Крюков
При чём здесь LIMIT? Я не про тонкости SQL говорил, а про факт
Vadim Fint
Ну всмысле есть же тот же Boo с частичной типизацией - но никто не
говорит что его билдить надо - может и на лету выполнятся )
Мы нашли частичный билдинг проекта очень удобным - тем более у нас все
равно есть модули на Си которые надо билдить, уж никуда не денешься.
Билдинг пиновоских файлов - это условно ln просто (т.е. хардлинк
делается), тем самым можно все равно на лету редактировать файлы
питона не пересобирая проект вообще.
Так вот во время билдинга можно сделать море оптимизаций в зависимости
от того, как нужно использовать готовый вариант. Банально - ассерты и
прочий дебаговский хлам повырезать для релиза. Ну и билдинг всех
необходимых запросов - тоже было бы очень круто =).
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Kirill Zaborsky <qri...@gmail.com>:
Vadim Fint
Но как бы я ещё раз повторяю - я не считаю джангу кривой или ущербной.
Аналогов всё равно нет. А те что есть - в разы хуже.
Для себя я решил (.. раз уж один фиг почти любой паблик модуль для
фреймворка необходимо допиливать ..) - лучше писать с нуля заточенное
под конкретный функционал решение. Ну или частично с нуля - ибо никто
не мешает выдрать из джанги то, к чему там претензий никаких нет
(Request/Response? :)))
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Pavel Reznikov <pashka....@gmail.com>:
Vadim Fint
Но ORM джанги не позволяет вмешиваться сильно в свою работу - я-то об этом =)
Выкрутится-то всегда можно и это даже не очень сложно, но это.. не
красиво что ли получается.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Eugene Kryukov <doct...@gmail.com>:
Vadim Fint
Соответственно, mysql, postgresql и sqlite в арсенале.
И.. нет возможности использовать сложные серверные вещи наподобие
вьюшек или процедур. Увы.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/27 Vadim Fint <mock...@gmail.com>:
Михаил
> Так вот во время билдинга можно сделать море оптимизаций в зависимости
> от того, как нужно использовать готовый вариант. Банально - ассерты и
> прочий дебаговский хлам повырезать для релиза.
Поделись механизмом плиз
Alex Kamedov
Подозреваю используется Ant.
Мы для билдинга используем его, но билдится у нас только статика.
У студии Лебедева на сайте есть хороший пример
http://www.artlebedev.ru/tools/technogrette/soft/eclipse-ant/
Правила пишутся достаточно просто.
Vadim Fint
медлительностью.
Билдятся:
.py -> (hardlink) -> .py
.ipy -> (preprocess) .py
.ipyx -> (preprocess) -> .pyx
.pyx -> (cython) -> .py
.js -> (combine, gzip, smallify) -> .js
.css -> (combine, gzip, smalify) -> .css
.ihtml -> (preprocess template) -> .html
Модули на си в целом билдятся каждый по-особому
find src -type f -name '*.*py*' -print0 | xargs -0 wc -l | grep total
159798 total
При этом весь билдинг проекта - около 30 секунд. Ребилдинг - 2-3 сек.
Билдинг такой почти в основном изза cython, ибо там gcc надо дёргать
-- у нас 17 Cython модулей.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/28 Alex Kamedov <kam...@gmail.com>:
Михаил
> Нет, у нас используется waf. Раньше был scons пока не взбесил своей
> медлительностью.
>
> Билдятся:
>
> .py -> (hardlink) -> .py
> .ipy -> (preprocess) .py
> .ipyx -> (preprocess) -> .pyx
> .pyx -> (cython) -> .py
А где здесь "ассерты и прочий дебаговский хлам повырезать"?
Vadim Fint
IPI.Manager :)
> А где здесь "ассерты и прочий дебаговский хлам повырезать"?
Ну есть ещё два режима билдинга =)
Второй - и препроцессинг *.py тоже.
nike
wrote:
> Извините, а что такое "аннотации"?
простите, спутал термин с "декораторами"
конечно, это не особенность django - они есть во всем питоне, но мне
нравится, как в django с их помощью решаются задачи по контролю
доступа к тем или иным частям сайта
nike
"кастрировать django" - просто потому что я не знал, что такое
werkzeug и был немного напуган низкоуровневым подходом данного
средства).
теперь я немного пообвыкся с werkzeug и он уже не вызывает у меня
ужаса
если вы хотите понять цель использования werkzeug, она достаточно
проста: мы используем mongodb (на это есть вполне обоснованные
причины, на которых я бы не хотел здесь останавливаться, чтобы не
тратить ничье время), а это значит что orm django не может
удовлетворять наших потребностей. в этом состоит один из основных
отказа от django
On 7 апр, 13:09, Владимир Корсун <korsun.vladi...@gmail.com> wrote:
> Я так и не услышал, какая задача стоит у топик-стартера, кроме как
> кастрация django или использование чего-то другого.
>
> 2010/4/7 Andrey Popp <8may...@gmail.com>:
>
>
>
> > 2010/4/7 Stanislav Panasik <spana...@gmail.com>:
> >>> Я просто выразил своё личное мнение -- если мне не нужна адмика, то я
> >>> обычно смотрю в сторону других web-фрэймворков.
>
> >> Личное - имеется в виду субъективное ? Тогда зачем делать заявление, что
> >> админка - это единственное преимущество Django, ведь это не так. Если
> >> делаете такое заявление, то добавьте в конце, что оно опирается не на факты,
> >> а на ощущения, это будет справедливо.
>
> > Конечно субъективное :-).
>
> >>> В данном случае не нужна ни админка, ни ORM. Конечно использовать
> >>> Django можно, но зачем? Я бы выбрал Werkzeug или WebOb, тем более
> >>> предъявляются требования к производительности.
>
> >> Итак, чем, на Ваш взгляд Werkzeug или WebOb лучше, чем Django в данном
> >> случае, учитывая, что проект безусловно будет развиваться в дальнейшем?
>
> > Вы очень ошибаетесь, если думаете что приложения на WebOb/Werkzeug не
> > поддаются "развитию в дальнейшем". Я думаю, это понятие никак не
> > связано с каким-либо фрэймворком вообще -- тут скорее дело в
> > архитектуре самого приложения. И на Django, я уверен, можно написать
> > такое, что потом даже не прочитаешь :-).
>
> >> Т.е. речь не о "Hello World !". В каком месте производительность будет
> >> меньше ?
>
> > Как я уже говорил, с Werkzeug/WebOb вы сами решаете на каком уровне
> > абстракции будете работать, сами описываете WSGI приложение.
> > Естественно, что таким образом, добиться большей производительности
> > будет легче чем с Django, которая иногда делает за разработчика
> > слишком много.
>
> > Я не говорю, что нельзя использовать Django, но для данной задачи я бы
> > выбрал Werkzeug.
>
> > --
> > Andrey Popp
>
> > phone: +7 911 740 24 91
> > e-mail: 8may...@gmail.com
>
> > --
> > To unsubscribe, reply using "remove me" as the subject.