PHP

Джанго - неудачная попытка сделать хороший веб-фреймворк на пайтоне.
Если тебе сейчас его хватает, значит ты не занимался чем-то бОльшим чем хомяки/гостевухи/блоги.
Для больших проектов на пайтоне используются такие веб-фреймворки как Pylons, TG2. Джанга тоже юзается, но только теми, кто не в состоянии изучить бОльшее.
Pylons сейчас заменяется на Pyramid, бывший repoze.bfg, который сейчас стал частью проекта Pylons и позаимствовал оттуда некоторые идеи.
В общем, если хочешь играть по крупному, то изучай что-то более сложное и более гибкое.

Рельсы... Это дело каждого в отдельности. Почитай о руби. Говорят что рельсы очень не гибкие, но в разы лучше джанги. Из-за плохой гибкости, люди уходят на синатру(по сути, тот же пайлонс, на сколько я знаю).

Если тебе нужно клепать мелкие сайты, то всё-равно.
Если что-то большое, то это дело вкуса, языка, предпочтений.

Я выбрал пайтон потому как мне нравится данный язык, я отлично владею Pylons, изучил Pyramid, знаю все инструменты(библиотеки) для своих задач, имею опыт, могу использовать этот же язык ещё и для разработки сетевых приложений на Twisted, и для прикладного ПО на GTK.

А можешь рассказать что-нибудь о CherryPy и TurboGears? Насколько они хороши в реальной разработке по сравнению с другими фреймворками?

могу посоветовать почитать дифирамбы пирамиде

http://python.su/forum/viewtopic.php?id=9161

Черри, как и многие другие микро-фреймворки, хорош тем, что на нём можно без проблем сделать лёгкое небольшое приложение вроде фронтэнда к прикладному приложению, твоей бд или курсовой.
Если ты делаешь проект, где у тебя задачи, кхм, чуть поболее, то их использовать будет очень трудно только из-за того, что они не рассчитаны на это.
TG(а ныне - TG2, основанный на pylons, repoze.who+what, toscawidgets1) это интересный веб-фреймворк, построенный на pylons с использованием популярных в этой среде инструментов. Одно но - там всё прибито гвоздями так, что если захочешь что-то своё сделать, то придётся изучать кишки трупа не первой свежести.
Кстати, SF.net используют TG2 с mongodb.
Pylons это веб-фреймворк, на котором нужно делать сразу своё приложение или достаточно хорошо продуманный веб-фреймворк. TG2 это попытка сделать свою джангу, но лучше. Оно даже получилось, но всё-равно не так далеко ушло.
Если ты не глуп и с английским не так плохо, советую почитать о Pyramid, ибо скоро все с Pylons будут мигрировать на него(считай что ничего не потеряли, там только дофига плюсов).
http://docs.pylonshq.com/pyramid/dev/

Благодарю. Обязательно почитаю =)

>Джанго - неудачная попытка сделать хороший веб-фреймворк на пайтоне.
Если тебе сейчас его хватает, значит ты не занимался чем-то бОльшим чем хомяки/гостевухи/блоги.

В чем с ней проблемы?

Я бы сказал что во многом.
Многое там прибито гвоздями. Например, нельзя полностью отказаться от SQL и продолжать использовать все благи(в т.ч. кешинг). А ведь сейчас везде стараются отказываться от sql.
Не смотря на то, что там многое готово и уже сделано, ты не сможешь сделать именно то, что ты хочешь, просто из-за слабой гибкости системы.
Вообще, я сам не так много времени просидел за джангой, но и того хватило чтобы понять, что удобнее всё делается на Pylons.
А ведь сейчас ещё появился и Pyramid, со своими идеями, которые очень сильно бустнут качество, удобство и скорость разработки веб-приложений.

. А ведь сейчас везде стараются отказываться от sql.

Ну и дураки, кстати :)

Вопрос по Pylons - я вот попробовал как-то. Не понравилось, что проект формируется генератором. А что если я хочу весь проект в одном файле и ручками? Например как в том же Sinatra. И файлики он какие-то непонятные, магические генерит. Непонятно...

grails

>Я бы сказал что во многом.

Многое там прибито гвоздями. Например, нельзя полностью отказаться от SQL и продолжать использовать все благи(в т.ч. кешинг). А ведь сейчас везде стараются отказываться от sql.

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

Да, там многое прибито гвоздями но все можно обойти. (если понадобитья конечно). Конечно если стандартные Джанговские приложения тебе в проекте не нужны то выбор Джанго сомнителен.
А где это «везде» стараются отказываться от SQL?
И можно поподробнее раскрыть фразу «полностью отказаться от SQL и продолжать использовать все благи(в т.ч. кешинг)».
Не уверен что правильно понял, что ты имеешь ввиду?
В целом сама джанга мне кажется более питонической, чем пайлонс. А вот Pyramid я не видел. Надо будет посмотреть.

>Ну и дураки, кстати :)
Ты приверженец политики «работает и ладно»? Вот из-за такого всегда и бывают проблемы.

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

Бред. Тогда я не знаю что тебе понравится.

А что если я хочу весь проект в одном файле и ручками?

Значит для этой, конкретной, задачи тебе нужен микрофреймворк.

И файлики он какие-то непонятные, магические генерит. Непонятно...

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

>но все можно обойти.
Обойти можно всё, всегда и везде. Вопрос в том, что обходить не хочется, что это всегда против фреймворка, его идей.

Конечно если стандартные Джанговские приложения тебе в проекте не нужны то выбор Джанго сомнителен.

Собственно, об этом и речь. Стандартные джанговские «приложения» пригодны для небольших проектов.

А где это «везде» стараются отказываться от SQL?

Уж точно не в россии. Ты можешь взглянуть на любой популярный проект. Везде сейчас отказываются от SQL, где это возможно. Однако, не везде это легко и дёшево.

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

А что тут такого? Если абстракция позволит использование разных бекендов, которые обязаны предоставлять общий набор функций, то допустимо использование всех благ абстракции под любым бекендом.

В целом сама джанга мне кажется более питонической

Чем?

А вот Pyramid я не видел. Надо будет посмотреть.

Очень советую. Он проще. Вот только траверсал будет сложно сразу понять.

>Обойти можно всё, всегда и везде. Вопрос в том, что обходить не хочется, что это всегда против фреймворка, его идей.

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

Стандартные джанговские «приложения» пригодны для небольших проектов.

Ну это как посмотреть. Админка например чудная вещь и сейчас легко расширяется и кастомайзится. Кэширование тоже очень неплохо из коробки работает. Routes мне в джанге тоже больше нравятся.

Уж точно не в россии. Ты можешь взглянуть на любой популярный проект. >Везде сейчас отказываются от SQL, где это возможно. Однако, не везде это легко и дёшево.

Если ты имеешь ввиду NoSQL, то это актуально для проектов с огромными объемами часто обновляемых данных. Таких проектов ИМХО очень мало (в общем количестве), просто обычно они более популярные. А при небольших объемах данных (< десятков терабайт) зачем использовать nosql?

А что тут такого? Если абстракция позволит использование разных бекендов, которые обязаны предоставлять общий набор функций, то допустимо использование всех благ абстракции под любым бекендом.

А, ты имеешь ввиду, что джанговские модели прибиты гвоздями к джанговской ОРМ. Есть такая проблема. Но во-первых если есть такая необходимость, то можно от джанговской ОРМ отказаться, и использовать то, что нравится (ну или вообще отказаться в данном случае от Джанго, т.к. много джаного плюшек не будет доступно). Во-вторых джанговская ОРМ не так плоха, как ее все ругают (есть определенные недостатки, но часто люди просто в ней не разобрались). Для быстрой разработки лучше я ничего не видел.

В целом сама джанга мне кажется более питонической

Чем?

Ну это скорее субьективно по ощущениям.

CherryPy это http фреймворк, необычайно гибкий, если его дополнить sqlalchemy,formencode(vs wtforms), mako, beaker, можно писать мощные веб приложения. Плюс к этому черрипай - это полноценный сервер, во всяком случае если его использовать в интранет, то больше ничего и не нужно, реальные интернет приложения лучше развертывать через wsgi интерфейс апача например

Почему ничего не сказано про webpy? Негодую!

Потомучто он ужасен)))

Потомучто он ужасен, но это субъективный взгляд на начинку, я о внутреннем содержимом)))

web2py™ выглядит неплохо

>Собственно, об этом и речь. Стандартные джанговские «приложения» пригодны для небольших проектов.

Дело не в размере проектов, а в задачах же.

Уж точно не в россии. Ты можешь взглянуть на любой популярный проект. Везде сейчас отказываются от SQL, где это возможно. Однако, не везде это легко и дёшево.

Эх, а вроде начал ты адекватно.

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

>Админка например чудная вещь и сейчас легко расширяется и кастомайзится.

Ох, главной ошибкой разработчика на джанге бывает завязывание на админку при старте проекта. А потом начинаются мучения...

ИМХО стоит очень хорошо подумать, прежде чем её использовать. И только если уверен, то делать. Потому что она, конечно, расширяется, но не всегда легко, иногда своя была бы в разы проще.

>Дело не в размере проектов, а в задачах же.
Говоря о «больших приложениях», я говорю о определённом виде задач.

Эх, а вроде начал ты адекватно.

А ты хочешь сказать, что если человек говорит что в россии все слоупоки, а переход на новые технологии с отказом от старых - хорошо, то человек неадекватен?

Отказываются от SQL только те, чьи задачи в рамки реляционной модели не укладываются

Использование MongoDB в разы проще и удобнее чем использование SQL-based БД. Однако, это не просто проще, но и удобнее, а главное - быстрее.
Понимаешь, если тебе, в теории, хватает палки для добывания огня, это не повод оставаться на этом уровне технологий и отказываться от спичек, зажигался. Образно говоря, кончено.

Таких, кстати, не так и много - куча проектов даже теоретически требует реляционный подход.

Огромное число проектов укладывается в рамки «реляционной» бд. Они же укладываются и в рамки документ-ориентированной бд. Более того, документ-ориентированная бд ничем не ограничивает такие проекты, не имеет минусов в сравнении.

Админка на джанге хороша только так, если хочется что-то потестировать на этапе разработки. Как они не пытались, так и не удалось сделать её достаточно гибкой.

> Использование MongoDB в разы проще и удобнее чем использование SQL-based БД.

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

А где я соврал?

SQL и документо-ориентированые бд применяются в большинстве случев для разных задач и сравнивать, что круче (проще и удобнее), тупо.

Ну а чего в рельсах такого не гибкого? Ну да, там привязка к MVC + REST, но разве от этого нельзя плясать? Или создать кастомные либы и сувать их в паку lib/ ?

Для руби хорош был Merb, но он теперь входит в состав 3-их рельс, на которые стоит обратить внимание, ибо они очень сильно различаются со 2-ыми.

>Говоря о «больших приложениях», я говорю о определённом виде задач.

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

А ты хочешь сказать, что если человек говорит что в россии все слоупоки, а переход на новые технологии с отказом от старых - хорошо, то человек неадекватен?

Я хочу сказать, что NoSQL не замена SQL, а не более чем инструмент для решения задач, которые через реляционные БД решаются с костылями. Например через перетяжелённый EAV.

Использование MongoDB в разы проще и удобнее чем использование SQL-based БД. Однако, это не просто проще, но и удобнее, а главное - быстрее.

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

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

Пытаться зажигалками и спичками заменить, например, инструмент для резки дерева - это тоже не вариант.

Огромное число проектов укладывается в рамки «реляционной» бд. Они же укладываются и в рамки документ-ориентированной бд. Более того, документ-ориентированная бд ничем не ограничивает такие проекты, не имеет минусов в сравнении.

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

>Использование MongoDB в разы проще и удобнее чем использование SQL-based БД.

охнеты. Порете чушь с видом Моисея, вещающего заповеди. Монга проще только на примитивных запросах, чуть-чуть более сложное - все, монго дохнет потому что она в принципе не может сделать join. Агрегатных функций там кот наплакал. Я знаю что говорю - недавно закончил один проект на монге и сказал, что больше я никогда за это nosql го%но не возьмусь. Монго применима для очень узкого круга задач. Очень узкого.

Ты приверженец политики «работает и ладно»? Вот из-за такого всегда и бывают проблемы.

Чего о_0. ЛОР меня всегда удивлял способностью публики к выводам. Отказ от SQL-БД мне не нравится тем, что те, кто пропагандируют такой подход не могут внятно сказать что они предлагают вместо ACID для тех задач, где конкретно нужно ACID. Нет, ну я понимаю, что есть BASE. Но в большинстве случае люди не на столько глубоко знаю вопрос.

>в большинстве случев для разных задач
Ты считаешь что так хорошо знаешь где и что лучше применять?
Давай пример задачи, где нельзя использовать документ-ориентированную бд, где SQL лучше применим и в сто раз выгоднее.

>Давай пример задачи, где нельзя использовать документ-ориентированную бд, где SQL лучше применим и в сто раз выгоднее.

Документ-ориентированность нужна тогда, когда у тебя есть куча разных свойств, настолько разнообразных, что в реляционной модели придётся делать всякие дополнительные таблицы с извращением.

Если набор свойств постоянный и более-менее одинаковый по всему проекту, то реляционная БД вполне себе подходит.

Почти любая финансовая информация.

>А то ведь есть места, где джанга по-дефолту подходит.
Да. Это такие «места», где достаточно стандартных средств джанги, где не нужно выходить за её рамки и делать что-то своё.

Я хочу сказать, что NoSQL не замена SQL

NoSQL это собирательный образ всех СУБД, которые не используют SQL.
Именно NoSQL ставится как противник SQL, как то, что должно его заменить.

а не более чем инструмент для решения задач

Лисп тоже инструмент. Функционал для чтения текстовых файлов, xml, json - тоже. И?

которые через реляционные БД решаются с костылями

Дело в том, что есть задачи, для которых хватает SQL и для которых не хватает SQL. Документ-ориентированные БД дают возможность выйти за эти рамки сохраняя всё то что может SQL.

Не всегда.

Я не хочу давать 100%-ные гарантии или уверенно говорить что нет исключений. Однако, в данном случае я скажу что да, это всегда.

Если ты будешь эмулировать поведение SQL БД на монго

Не понял, что такое «эмулирование поведения SQL БД на монго»? Что ты эмулировать хочешь?

то оно не будет быстрее.

Если ты будешь из монго делать SQL, то логично что оно не будет быстрее.

Повторюсь, есть задачи, которые укладываются в реляционную модель, и для которых она и была придумана

Да, где mongodb может быть использована и покажет лучшие результаты, чем реляционная. Так почему бы её и не использовать?

Тупые людишки не просто ж так годами это дело разрабатывали.

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

Пытаться зажигалками и спичками заменить, например, инструмент для резки дерева - это тоже не вариант.

Но ты меняешь ведь палку для добывания огня, при чём здесь инструмент для резки дерева?

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

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

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

Ты не понял о чём мы спорим.
Люди утверждают что документ-ориентированная бд не способна заменить реляционную. Что нельзя использовать монго вместо mysql. Что все, кто используют монго вместо sql - дураки(цитируя http://www.linux.org.ru/jump-message.jsp?msgid=5588238&cid=5591603).

Документ-ориентированная БД хорошо подходит для _любых задач_. Огромным плюсом идеологии такой бд является возможность динамически изменять поля и дополнять их. Это плюсы, это не «ограничения».
Я как-раз и говорю о том, что если проект укладывается в систему хранения данных в реляционной бд, то SQL можно использовать, но даже там mongo будет лучше.

>Монга проще только на примитивных запросах
Что-что простите?

чуть-чуть более сложное - все, монго дохнет потому что она в принципе не может сделать join

Вот давай так, я не буду говорить кто ты, а ты возьмёшь и почитаешь о монго, а потом напишешь ещё один пост о том, как там всё хорошо сделано, идёт?

Агрегатных функций там кот наплакал.

Если ты научился использовать функцию join в SQL, это не значит что все СУБД должны подстраиваться под это и давать функционал 1 в 1.
Почитай как это правильно делать в монго и пойми что это не сложнее чем в SQL, но быстрее и удобнее.

Я знаю что говорю - недавно закончил один проект на монге и сказал, что больше я никогда за это nosql го%но не возьмусь.

Уууу... О чём говорили, чего боялись, к чему пришли.
Действительно, в монго нет функционала для того, чтобы одной функцией выбрать кучу записей из 3х коллекций, да только то, что нужно.
Вместо этого нужно делать несколько запросов к БД. Однако, это не значит что МОНГО КЭНТ ИНТУ БИГ КУЕРРИЕС, это значит что нужно учиться использовать инструмент так, как нужно его использовать.

Монго применима для очень узкого круга задач. Очень узкого.

Не используй. Мне-то всё-равно. Проблема в том, что данное твоё утверждение может очень повеселить твоих коллег ИРЛ.

Магазин - не те масштабы. Если будет база с более сложной логикой и бОльшим объемом, твои костыли там не подойдут и падение скорости чтения будет заметнее.

>Магазин - не те масштабы.
Охлол. Ну ок, допустим.

Если будет база с более сложной логикой и бОльшим объемом

Более сложная логика? Возможность изменения структуры, более гибкие запросы дают возможность реализовать сколь угодно сложную логику. Скорость БД позволяет посмеяться над реализацией такой логики через SQL.

твои костыли там не подойдут и падение скорости чтения будет заметнее.

А люди-то не замечали! Оказывается, использование монгодб - уже костыль.

В общем, если ты не троллишь, подумай ещё раз и давай больше конкретики.

Документ-ориентированная БД хорошо подходит для _любых задач_.

Фанатики, такие фанатики.

Например, есть графовые БД. Ну ты понел.

>Pylons сейчас заменяется на Pyramid, бывший repoze.bfg, который сейчас стал частью проекта Pylons и позаимствовал оттуда некоторые идеи. В общем, если хочешь играть по крупному, то изучай что-то более сложное и более гибкое.

Кстати посмотрел на этот твой пирамид - интересная штука, правда выглядит как-то наворочено после джанги.

Оно в реальной жизни подойдёт для написания небольших и средний сайтиков для обычного пользователя? Т.е. сайты фирмы с интерфейсом под CMS, магазинчики итд?

Админка, как я понял, пишется ручками?

>Например, есть графовые БД.
Что ты хочешь этим сказать? Что «документ-оиентированная» бд создана только для хранения _документов_? Тогда тебе стоит почитать о том, что такое документ.

>выглядит как-то наворочено после джанги.
На самом деле просто в пирамиде более интересная система контроллеров и моделей. Наворотов там ни капли, всё минималистично.

Оно в реальной жизни подойдёт для написания небольших и средний сайтиков для обычного пользователя?

Пирамида это ещё и микро-фреймворк. Подойдёт для всего. Просто нужно привыкнуть к траверсал и научиться нормально кодить используя его.

Т.е. сайты фирмы с интерфейсом под CMS, магазинчики итд?

Почему бы и нет? Всё что нужно там есть.

Админка, как я понял, пишется ручками?

Как заметили выше, «админка» из джанги - вовсе не админка, а кусок говна, простите за выражение.
Конечно, админку придётся писать самому. Однако, траверсал сильно упрощает это.

Можно реальный пример проблемы и решения на монго? Я уже давно про нее читаю дифирамбы, но до сих пор не видел ни одного КОНКРЕТНОГО примера. Не могу разложить у себя в голове по полочкам зачем она, как ее использовать и тп. Простой пример и его решение.

>это значит что нужно учиться использовать инструмент так, как нужно его использовать.
угу, мапредьюс в один поток на 4-х ядерном процессоре. Привет.

Вместо этого нужно делать несколько запросов к БД

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

Я могу тебе накидать мои решения проблем, которые ты назовёшь. МонгоДБ просто создана такой, что можно себя не ограничивать.
Например, нужно сделать форум? Ок, вот сущности: форум(раздел), тема, сообщение.
Самый «монгоидный» вариант:
1 коллекция с разделами форума:
{_id:ObjectID, name:unicode, fullname:unicode, uid:int(хотя кому как, можно и name использовать), posts_count:int, threads_count:int}
Если резделов не так много, а тем много, то по одной коллекции на раздел. В эту коллекцию складываются документы тредов, которые имеют такую структуру:
{
_id:ObjectID,
id:int,
author:int,
title:unicode,
messages_count: int
messages:[]
}
В messages хранятся все посты в такой структуре:
{
id:int,
author:int,
message:unicode
}
Теперь, пользователи будут читать треды. Будет запрос на один документ с слайсом на messages для пагинации. Всё просто.
Есть и другой вариант, который, как я заметил, любят коучдб-фаги - использование сообщений как отдельные документы. Конечно, это может быть полезно в некоторых случаях, но проще всё-таки именно вложенные сообщения. Ограничения на документ(в 64-битной системе) - 8 мб. Если сообщения не имеют очень большую структуру, то туда можно уместить всё что нужно.

>угу, мапредьюс в один поток на 4-х ядерном процессоре. Привет.
Не всегда нужно использовать mapReduce.

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

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

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

>Не всегда нужно использовать mapReduce.
других причин использовать noSQL просто нет. Это единственный существенный плюс

ха, не так и сложно, как я думал. Надо будет поплотней про нее почитать. Спасибо.

ах да, ты забыл упомянуть о том, что если в квере есть два $in или используются два поля типа массив, то монго не подхватывает индексы. Красота-то какая.