Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 293
Высокая скорость работы. Ну не такая чтобы уж очень.
Не «Поддержка MTV (Model-Template-View)», а не совсем логичная реазилация «MVC». «MTV» стали называть чтобы не подчёркивать данный факт. В Pylons вот как-раз есть нормальная реализация MVC.
Вы вообще рассматривали Pylons? Можете сказать причину почему выбрали именно Django а не Pylons?
Не холивора пишу ради, просто хочется знать мнение и причины.
Не «Поддержка MTV (Model-Template-View)», а не совсем логичная реазилация «MVC». «MTV» стали называть чтобы не подчёркивать данный факт. В Pylons вот как-раз есть нормальная реализация MVC.
Вы вообще рассматривали Pylons? Можете сказать причину почему выбрали именно Django а не Pylons?
Не холивора пишу ради, просто хочется знать мнение и причины.
Да, я в свое рассматривал Pylons. В целом, это система, которая связывает другие библиотеки — SQLAlchemy, Genshi и т.п., и в чем-то она напоминает Java Spring. Бесспорно, у Pylons есть свои плюсы, но они перекрываются другими недостатками (по крайней мере в моих глазах): недостаточная зрелость проекта, небогатая документация (это касается не только самого Pylons, но и библиотек, которые он предлагает использовать), отсутствие автоматической админки. Все это повышает порог вхождения, и понижает скорость разработки. А это — потерянные бабки, это трата времени на его изучение молодыми специалистами, это трудноопределимые баги, когда непонятно кто виноват — тот же Genshi, SQLAlchemy или сам Pylons.
Спасибо за такой развёрнутый ответ. Советую посмотреть на него сейчас, лично я заметил заметное продвижение вперёд, по сравнению с состоянием где-то на апрель сего года. Да и документация очень радует. У них есть хоть растянутый и нужный, но свой большой и полный «бук».
Порог вхождения да, немного выше, но он того стоит.
Порог вхождения да, немного выше, но он того стоит.
это SQLAlchemy недостаточно зрелый проект? Или может CherryPy? а, наверное Paster.
чем хороши Пилоны — так это полной взаимозаменяемостью компонентов и отсутствием собственных велосипедов (попробуйте в джанге поменять ОРМ или шабллонизатор).
как Pylons так и все входящие в состав библиотеки отлично документированы. разрабатываются не один год и давно вошли в статус зрелости.
единственный плюс Джанго (кроме собственных предпочтений) это пресловутая админка, облегчающая работу ньюбам. и то — для более-менее сложных проектов она не подходит.
чем хороши Пилоны — так это полной взаимозаменяемостью компонентов и отсутствием собственных велосипедов (попробуйте в джанге поменять ОРМ или шабллонизатор).
как Pylons так и все входящие в состав библиотеки отлично документированы. разрабатываются не один год и давно вошли в статус зрелости.
единственный плюс Джанго (кроме собственных предпочтений) это пресловутая админка, облегчающая работу ньюбам. и то — для более-менее сложных проектов она не подходит.
спорить в этой теме опасно для кармы и рейтинга, но я обосную свою точку зрения.
я тоже не хочу естественно сказать что Джанго — плохое решение.
потому несколько моих тезисов.
0. Я не претендую на абсолютную истину и просто излагаю свое мнение.
1. Джанго замечательна как минимум своей популярностью — благодаря ей (или ему) отношение к веб разработке на Пайтоне стало куда более лояльным и востребованным.
2. Джанго я последний раз смотрел давно, где-то с год назад, что-то могло и поменяться.
3. Все вами перечисленные плюсы кроме распиаренности имеют место быть у всех «зрелых» фреймворков. Кстати, на счет отсутствия статей по другим фреймворкам — думаю можно поправить ситуацию :-)
4. Я все же считаю что все «компоненты» Джанго уступают аналогоичным библиотекам. Шаблонизатор — хуже Jinja2 (хотя бы по скорости, да и синтаксис не ахти). ОРМ — явно не Alchemy. И т.п. конечно с рядом проблем можно по заменять это все на ту же жинжу и алхимию, но тогда встает вопрос — зачем было брать джангу.
Тем более что замена не так уж прозрачна.
Не буду заниматься приведением конкретных «недочетов» джанги, так как это глупость. Просто мое мнение: джанго хороший выбор для новичка, но при необходимости «более глубокого» тюнинга она будет связывать по рукам и ногам.
я тоже не хочу естественно сказать что Джанго — плохое решение.
потому несколько моих тезисов.
0. Я не претендую на абсолютную истину и просто излагаю свое мнение.
1. Джанго замечательна как минимум своей популярностью — благодаря ей (или ему) отношение к веб разработке на Пайтоне стало куда более лояльным и востребованным.
2. Джанго я последний раз смотрел давно, где-то с год назад, что-то могло и поменяться.
3. Все вами перечисленные плюсы кроме распиаренности имеют место быть у всех «зрелых» фреймворков. Кстати, на счет отсутствия статей по другим фреймворкам — думаю можно поправить ситуацию :-)
4. Я все же считаю что все «компоненты» Джанго уступают аналогоичным библиотекам. Шаблонизатор — хуже Jinja2 (хотя бы по скорости, да и синтаксис не ахти). ОРМ — явно не Alchemy. И т.п. конечно с рядом проблем можно по заменять это все на ту же жинжу и алхимию, но тогда встает вопрос — зачем было брать джангу.
Тем более что замена не так уж прозрачна.
Не буду заниматься приведением конкретных «недочетов» джанги, так как это глупость. Просто мое мнение: джанго хороший выбор для новичка, но при необходимости «более глубокого» тюнинга она будет связывать по рукам и ногам.
Когда нас перестал устраивать внутренний шаблонизатор джанги, мы спокойно перешли на jinja2. Никаких «связываний по рукам и ногам» не заметили.
угу. потом когда перестанет устраивать ОРМ джанги можно так же спокойно сменить его на алхимию…
потом сменить роутинг на что-то другое…
потом мидлвары свои добавить.
кстати, на каком из шагов отвалится та же админка?
потом сменить роутинг на что-то другое…
потом мидлвары свои добавить.
кстати, на каком из шагов отвалится та же админка?
Админка отвалиться на смене ОРМ-а, кмк. Вынос ОРМ-а из джанги — нетривиальная операция.
ОРМ джанги нас не устраивает только в нескольких очень специфичных запросах. Мы их спокойно делаем руками. С роутингом все в порядке, что там может не устраивать? Мидлвары свои добавляются достаточно легко.
Так что может у меня просто привычка возникла, но особых трудностей разработки больших проектов по джангу я не вижу.
Так что может у меня просто привычка возникла, но особых трудностей разработки больших проектов по джангу я не вижу.
вы меня упорно не понимаете :)
мы тоже писали на джанге. сначала пришлось заменить шаблонизатор (он очень посредственный в джанге).
потом ОРМ. так как сложность запросов превысила возможности джангового.
потом пришлось писать и втыкать свои мидлвары.
последнее что сделали — заменили роутинг на более простой, так как фокусы с регэкспами были не сильно нужны, а вот скорость — очень.
после этого стало понятно что от Джанго у нас ничего и не осталось. пришлось задуматься — зачем она была изначально нужна.
в общем — теперь у нас или Пилоны или собственная связка на основе CherryPy.
мы тоже писали на джанге. сначала пришлось заменить шаблонизатор (он очень посредственный в джанге).
потом ОРМ. так как сложность запросов превысила возможности джангового.
потом пришлось писать и втыкать свои мидлвары.
последнее что сделали — заменили роутинг на более простой, так как фокусы с регэкспами были не сильно нужны, а вот скорость — очень.
после этого стало понятно что от Джанго у нас ничего и не осталось. пришлось задуматься — зачем она была изначально нужна.
в общем — теперь у нас или Пилоны или собственная связка на основе CherryPy.
Ууу, как все плохо. Покажите плз проект, ради которого пришлось так помучиться.
что ж тут плохо-то? просто с ростом нагрузки пришлось все последовательно менять.
показать, извините, не могу ибо проект не публичный.
могу в привате немного рассказать некоторые детали, если интересно.
показать, извините, не могу ибо проект не публичный.
могу в привате немного рассказать некоторые детали, если интересно.
Ага, люди уперлись по скорости даже в роутинг! Очень интерсено!
я просто нахожусь под действием NDA :(
подумаю что можно рассказать не нарушая его и сделать пару обзорных статей, но ничего обещать не могу.
ЗЫ 3 млн. хитов в день — это та нагрузка при которой критичным становится все :)
подумаю что можно рассказать не нарушая его и сделать пару обзорных статей, но ничего обещать не могу.
ЗЫ 3 млн. хитов в день — это та нагрузка при которой критичным становится все :)
З млн? А какое железо? Не так и много хитов, чтобы так извращаться, но конечно если железо достойное.
забыл сказать: кроме 3 млн. хитов есть еще ряд «усложнений».
по железу — Large Instance на Amazon EC
в том то и дело что сначала хочется оптимизировать все по софту, чтоб потом уже расти по железу.
по железу — Large Instance на Amazon EC
в том то и дело что сначала хочется оптимизировать все по софту, чтоб потом уже расти по железу.
есть мнение, что заниматься «оптимизацией софта» можно практически бесконечно
есть мнение, что взрослые здравые люди способны усмотреть предел нормальной целесообразности :)
в общем-то пока для наc Черипаха + Алхимия + Джинджа2 позволяют спокойно работать в пределах большой ноды. не будет хватать — перейдем на свербольшую. но пока нужды нет.
пользуясь случаем хочу передать благодарность разработчикам великолепной программы без которой нам было бы намного тяжелее: спасибо Postgres :-)
в общем-то пока для наc Черипаха + Алхимия + Джинджа2 позволяют спокойно работать в пределах большой ноды. не будет хватать — перейдем на свербольшую. но пока нужды нет.
пользуясь случаем хочу передать благодарность разработчикам великолепной программы без которой нам было бы намного тяжелее: спасибо Postgres :-)
Спасибо. Тогда всё ясно — у вас другой подход. Только в таком случае нельзя говорить «выбор джанга для новичка». Путь левой пятки через правое плечо слишком тернист и там сломается любая абстракция.
я ж потому пару раз и написал что это мое личное мнение :)
сейчас попробую свое мнение немного расширить (не претендую на абсолют)
под «профессионалом» я тут имел в виду человека, использующего максимально гибкие инструменты. а в мире пайтона как раз таковыми и будут являться SQLAlchemy, Jinja2 (или Cheetah), Paster и т.п.
просто в силу того что остальные конкуренты в целом не дотягивают.
сейчас попробую свое мнение немного расширить (не претендую на абсолют)
под «профессионалом» я тут имел в виду человека, использующего максимально гибкие инструменты. а в мире пайтона как раз таковыми и будут являться SQLAlchemy, Jinja2 (или Cheetah), Paster и т.п.
просто в силу того что остальные конкуренты в целом не дотягивают.
Я не нашел среди ваших аргументов на мой взгляд самую вкусную вещь — высокую скорость разработки. Почему? :(
Это под-пункт в «Использование Python в качестве языка программирования», тогда уж.
Основное «ускорение» придаёт сам пайтон. Хотя у джанго упрощено действительно много операций, но использования пайтона, как правило, само собой подразумевает высокую скорость разработки.
Основное «ускорение» придаёт сам пайтон. Хотя у джанго упрощено действительно много операций, но использования пайтона, как правило, само собой подразумевает высокую скорость разработки.
Во-первых, для многих это не очевидно ) Ну а во-вторых, Питон, несомненно, «придает ускорение», но Django и сама по себе предоставляет огромное количество дополнительных библиотек, методов, шаблонов, которые значительно уменьшают время разработки, а сам «код» получается зачастую очень лаконичным.
Вы сами перечислили причины, почему Python ускоряет разработку — на нем проще проектировать грамотную архитектуру, проще ловить баги, проще тестировать. Ну и с разработчиками тоже особо проблем нет из-за низкого порога вхождения, т.е. любой грамотный разработчик сможет писать на Python-е через неделю после его изучения с нуля.
Единственное, хочу отметить про баги. Python — динамически-типизируемый язык, и соотвественно, можно ловить много багов из-за несоответствия типов. Мы для себя эту проблему решили жестким требованием соблюдать 100%-ое покрытие кода.
Единственное, хочу отметить про баги. Python — динамически-типизируемый язык, и соотвественно, можно ловить много багов из-за несоответствия типов. Мы для себя эту проблему решили жестким требованием соблюдать 100%-ое покрытие кода.
Я это косвенно упоминал. Фактически, все упомянутые пункты влияют на скорость разработки. С другой стороны, это очень шаткий аргумент, т.к. в некоторых случаях разработка на Django не столь быстра, как на специализированных фреймворках. Например, в том же RoR некоторые вещи можно писать намного быстрее, если сайт полностью совпадает с паттернами проектирования, заложенными в рельсы изначально.
ну вот опять, я не могу решить python + django или ruby + RoR…
Да по большому счету смотрите сами ) Оба фреймворка достаточно хороши.
Но python сам по себе самодостаточен, в противовес ruby. Я сейчас пишу на Django, о чем ни капли не жалею.
Плюсом еще является то что сейчас многие крупные порталы используют первую связку. К примеру Я.Афиша, Я.Расписания итд.
Но python сам по себе самодостаточен, в противовес ruby. Я сейчас пишу на Django, о чем ни капли не жалею.
Плюсом еще является то что сейчас многие крупные порталы используют первую связку. К примеру Я.Афиша, Я.Расписания итд.
> Плюсом еще является то что сейчас многие крупные порталы используют первую связку. К примеру Я.Афиша, Я.Расписания итд.
и в чем тут плюс для конечного разработчика?
и в чем тут плюс для конечного разработчика?
Во первых применение в крупных проектах — это показатель стабильности и эффективности работы фреймворка.
А во вторых банально можно устроиться на работу.
А во вторых банально можно устроиться на работу.
так РНР еще в большем количестве крупных проектов применяется… :)
Ну а никто и не говорит что РНР это плохо. Я ему отдал 5 лет.
Сейчас сижу на джанге, т.к. она позволяет больше думать над проектом, вместо того чтобы думать над кодом.
Сейчас сижу на джанге, т.к. она позволяет больше думать над проектом, вместо того чтобы думать над кодом.
да я к тому что «кто использует» не показатель в принципе.
вот например кто использует Pylons: wiki.pylonshq.com/display/pylonscommunity/Sites+Using+Pylons
достаточно внушительный список.
я вот пишу на CherryPy + SQLAlchemy + Jinja2, и вообще обхожусь без фреймворков.
и тоже в общем-то не сказал бы что сильно «думаю над кодом»
вот например кто использует Pylons: wiki.pylonshq.com/display/pylonscommunity/Sites+Using+Pylons
достаточно внушительный список.
я вот пишу на CherryPy + SQLAlchemy + Jinja2, и вообще обхожусь без фреймворков.
и тоже в общем-то не сказал бы что сильно «думаю над кодом»
Не хочу поднимать холивар, а просто выскажу, почему я не использую RoR в своих проектах:
— слабая документация, приходится ковырять кучу ресурсов и смотреть тяжелые скринкасты;
— неинтуитивно понятный ЯП, без привычки иногда читать тяжеловато, особенно если злоупотребляют mixin-ами и другими техниками;
— явные тормоза, даже со свежей версией (по-крайней мере, под линуксом);
— кривой rcov, что в итоге не позволяет мне считать code coverage (сейчас может исправили, но последний раз, когда я смотрел летом, он не работал со свежей версией Ruby);
— нет единообразности в процедурах локализации. То, что предлагается по умолчанию, не столь удобно в использовании.
— слабая документация, приходится ковырять кучу ресурсов и смотреть тяжелые скринкасты;
— неинтуитивно понятный ЯП, без привычки иногда читать тяжеловато, особенно если злоупотребляют mixin-ами и другими техниками;
— явные тормоза, даже со свежей версией (по-крайней мере, под линуксом);
— кривой rcov, что в итоге не позволяет мне считать code coverage (сейчас может исправили, но последний раз, когда я смотрел летом, он не работал со свежей версией Ruby);
— нет единообразности в процедурах локализации. То, что предлагается по умолчанию, не столь удобно в использовании.
с документацией я запутался, прочитал книжку по RoR, поржал. Но вот синтаксис Ruby мне больше понравился. Думаю можно обе платформы изучить, а позже уже выбрать… Я просто вообще от вэбразработки далек, html с css начал месяц назад изучать :)
А Ruby начал изучать из-за того, что встретил RadiantCMS. сразуже свой проект на нем начал делать, и влюбился в руби :) питон начал идучать из-за GAE, но встретил Ruby, и решил изучать руби :)
А Ruby начал изучать из-за того, что встретил RadiantCMS. сразуже свой проект на нем начал делать, и влюбился в руби :) питон начал идучать из-за GAE, но встретил Ruby, и решил изучать руби :)
Вы далеко не одиноки (хотя некоторые и утверждают что Ruby это «неинтуитивно понятный ЯП»). Но начинать изучение советовал бы лучше с Sinatra или Ramaze. По той причине что RoR многое делает автоматически, это помогает быстрой разработке, но без понимания механизмов за этим стоящих (а их изучение c RoR велик соблазн «изучить потом») низко падает качество конечного продукта.
В своё время, начитавшись синтаксического сахара ruby, очень долго колебался с выбором, RoR или Django? В конце-концов скатился ко второму варианту, хотя RoR продолжаю изучать на новой работе, в силу выбора технологии там. Но в то же время — привил туда же и Django. Хотя множество технологий внутри одной небольшой студии и создают сложности поддержки из-за небольшого числа сотрудников. Решение начальства в пользу Django появилось после обнаружения множества узких мест в производительности на нагруженных инфосистемах. А c RoR я продолжаю дружить из-за вложенного туда духа agile и красоты ruby ;) Ну и знания не бывают лишними, да.
Работал C++ программистом, увлекался питоном. Год назад стоял перед таким же выбором. Изучал оба фрейворка, выбрал Rails, причина — линия заказов на Rails :)
С Django знаком поверхностно, в Rails нравится:
* Ruby — спустя пол года оценил красоту и мощь языка
* Migrations (решения для Django не так красивы)
* Множество гем и плагинов веб тематики, они создаются, развиваются — одних только attachment плагинов шесть штук
* Тестирование, тестирование и тестирование
* RESTful идеалогия
После Python первое время Ruby казался неказистым, почитал мануалы, посмотрел как пишут другие люди и понял. Он другой, не так далек как Haskell или Lisp, но и питоном его мерять нельзя.
С Django знаком поверхностно, в Rails нравится:
* Ruby — спустя пол года оценил красоту и мощь языка
* Migrations (решения для Django не так красивы)
* Множество гем и плагинов веб тематики, они создаются, развиваются — одних только attachment плагинов шесть штук
* Тестирование, тестирование и тестирование
* RESTful идеалогия
После Python первое время Ruby казался неказистым, почитал мануалы, посмотрел как пишут другие люди и понял. Он другой, не так далек как Haskell или Lisp, но и питоном его мерять нельзя.
несколько раз пытался подступиться к руби и рельсам. но никак не хватало терпения и мотивации.
в общем — главное в том что руби — другой. он просто отличается от питона. потому не надо мерить его питоновыми мерками, и тогда будет понятно что это — тоже просто хороший язык. со своими плюсами и минусам, но хороший.
верно и обратное для рубистов, глядящих на пайтон :)
в общем — главное в том что руби — другой. он просто отличается от питона. потому не надо мерить его питоновыми мерками, и тогда будет понятно что это — тоже просто хороший язык. со своими плюсами и минусам, но хороший.
верно и обратное для рубистов, глядящих на пайтон :)
>одних только attachment плагинов шесть штук
Меня такие знаки обычно настораживают: лучше бы был один, но добротный.
Меня такие знаки обычно настораживают: лучше бы был один, но добротный.
Питон быстрее, руби — красивее.
Автоматическая админка — это не только автогенерация форм и списков. Это еще и права доступа, аудит, отслеживание целостности, всяческого рода фильтры и поиски. Я не сомневаюсь, что есть готовые решения для любой платформы, но в Django это идет из коробки, и не приходится что-то искать и пробовать.
Джанговская админка далеко не универсальная штука.
После определенного момента писать хаки к админке становится «дороже», чем все выкинуть и написать ту админку, которая нужна :)
После определенного момента писать хаки к админке становится «дороже», чем все выкинуть и написать ту админку, которая нужна :)
Не соглашусь. Буквально недавно закончил работу над большим django-проектом (8 месяцев работы 3-х программистов), где пришлось достаточно сильно вмешиваться в работу админки Django. Вид админки изменился почти до неузнаваемости, даже схема URL'ов и навигации вообще. Тем не менее, никаких хаков и monkey-патчей не понадобилось, а изменения были сработаны весьма быстро.
Админка Django не совершенна, но архитектурно многие вещи сделаны правильно, и это позволяет менять всё что угодно, так как:
* класс django.contrib.admin.options.ModelAdmin полностью отвечает за все аспекты работы с моделями — вы можете добавлять view и менять роутинг URL'ов, создавая новые страницы (хоть wizard'ы), вмешиваться в генерацию форм, стандартные обработчики CRUDL-операций, контроль прав доступа… словом во всё! Есть лишь проблема с самописными фильтрами, но она редка, решаема стандартными способами, а к марту 2010-го эту часть админки обещают сделать расширяемой.
* Вы можете использовать всю мощь newforms (часть Django), и применять в админке свои виджеты, использующие свои дополнительные css-стили и js-модули.
* для каждой модели можно индивидуально переопределить шаблон страницы, и вообще переопределиь любой шаблон админки. Наследование шаблонов поможет не дублировать код, исправить только нужные участки.
Я хочу сказать, что админку Django можно применять и в случаях, когда от неё будет требоваться сильно нестандартное поведение. При этом, вы сможете сконцентрироваться только на этих нестандартностях, не занимаясь изобретением велосипедов в остальных аспектах, а воспользоваться всеми уже готовыми «плюшками». Без хаков, переносимо.
Админка Django не совершенна, но архитектурно многие вещи сделаны правильно, и это позволяет менять всё что угодно, так как:
* класс django.contrib.admin.options.ModelAdmin полностью отвечает за все аспекты работы с моделями — вы можете добавлять view и менять роутинг URL'ов, создавая новые страницы (хоть wizard'ы), вмешиваться в генерацию форм, стандартные обработчики CRUDL-операций, контроль прав доступа… словом во всё! Есть лишь проблема с самописными фильтрами, но она редка, решаема стандартными способами, а к марту 2010-го эту часть админки обещают сделать расширяемой.
* Вы можете использовать всю мощь newforms (часть Django), и применять в админке свои виджеты, использующие свои дополнительные css-стили и js-модули.
* для каждой модели можно индивидуально переопределить шаблон страницы, и вообще переопределиь любой шаблон админки. Наследование шаблонов поможет не дублировать код, исправить только нужные участки.
Я хочу сказать, что админку Django можно применять и в случаях, когда от неё будет требоваться сильно нестандартное поведение. При этом, вы сможете сконцентрироваться только на этих нестандартностях, не занимаясь изобретением велосипедов в остальных аспектах, а воспользоваться всеми уже готовыми «плюшками». Без хаков, переносимо.
Вот один минус джанги, как раз, так это слабая документация по глубокому пилению админки. Отсльное документировано отлично.
Тут можно возразить, что «пиление» админки — это не ожидаемый разработчиками сценарий применения. Они рассчитывают на стандартные инструменты, специально предназначенные для кастомизации, и за которые разработчики Django могут нести ответственность. Таким образом, если в будущем понадобится серьёзный рефакторинг, они смогут без проблем его провести, не боясь что у кого-то что-то поломается.
Если вы хотите переделать автомобиль на управление джойстиком и со способностью летать в стратосферу, тут уж извините — придётся лезть во внутренности. А такие случаи задокументировать просто невозможно. Можно лишь дать общие указания «куда копать», и такие указания есть — вот, например.
Если вы хотите переделать автомобиль на управление джойстиком и со способностью летать в стратосферу, тут уж извините — придётся лезть во внутренности. А такие случаи задокументировать просто невозможно. Можно лишь дать общие указания «куда копать», и такие указания есть — вот, например.
В Symfony это тоже идет из коробки, но в итоге и на django проектах, и на symfony исходной админкой в готовом продукте без кастомизации не обходится, а подчас действительно создается отдельное приложение под frontend. А вот мне документация у ZendFramework нравится. А Django нравится из-за быстроты разработки. А вот RoR не пробовал, но всё в переди!
Документация у ZF не ахти, на самом деле. То есть её огромность создаёт ложное впечатление документированности, но она очень поверхностна и там не касаются сути вещей. Иными словами, если надо что-то сурьёзное переделать, то надо ковырять исходники. Учитывая «лаконичность» пхп, это сильно замедляет процесс.
есть Catwalk разработанный для TurboGears, но отлично прикручиваемый к любому фреймворку.
Если вам очень критична скорость джанги, я бы рекомендовал заменить встроенный шаблонизатор на jinja2. По синтаксису он очень похож на джанговский, но мощнее и быстрее. Но его придется немного адаптировать под стандартные теги джанги (стандартные шаблоны джанги из коробки в нем не работают).
Спасибо, я в курсе. Оптимизация Django-приложений — это отдельная тема, для которой необходимо упоминать такие страшные слова, как memcached, nginx, load balancer, database cluster, replication и т.п. В принципе, все это сказано в презентации Django Con High Performance Django.
а что скажете насчет webpy? сам не изучал, но яндекс использует
К сожалению, я тоже не изучал. Естественно, у него есть своя ниша, и думаю, что он больше применим для CGI-скриптов, что подтверждается «Who uses web.py?» секцией на заглавной странице проекта.
Вообще, я не воспринимаю выбор фреймворка как некий религиозный вопрос. Разнообразие проектов существует не просто так, и у каждого есть своя уникальность. Но при этом возникают другие вопросы — времени, денег и усилий. Для кого-то они не важны, например, для студентов или людей, у кого излишек времени и/или денег. Я себе такие растраты позволить не могу и не хочу, поэтому зачастую выбираю именно Django как оптимальный вариант с точки зрения траты ресурсов.
Вообще, я не воспринимаю выбор фреймворка как некий религиозный вопрос. Разнообразие проектов существует не просто так, и у каждого есть своя уникальность. Но при этом возникают другие вопросы — времени, денег и усилий. Для кого-то они не важны, например, для студентов или людей, у кого излишек времени и/или денег. Я себе такие растраты позволить не могу и не хочу, поэтому зачастую выбираю именно Django как оптимальный вариант с точки зрения траты ресурсов.
Я бы не стал советовать если у вас не такой большой опыт в веб-кодинге и пайтоне. Дело в том что это очень, очень лёгкий веб-фреймворк, который даже фреймворком называется с большой натяжкой.
Скажем так: он избавляет программиста от написания фундаментального функционала для работы веб-приложения. Гибкость — да. Свобода — да. Простота разработки — нет. Быстрая разработка — нет.
Вообще, webpy очень хорош, не подумайте. Но если вы пишете большой проект, а времени, финансов и сил не много — ваш выбор django или pylons.
Скажем так: он избавляет программиста от написания фундаментального функционала для работы веб-приложения. Гибкость — да. Свобода — да. Простота разработки — нет. Быстрая разработка — нет.
Вообще, webpy очень хорош, не подумайте. Но если вы пишете большой проект, а времени, финансов и сил не много — ваш выбор django или pylons.
по-моему яндекс его не использует в своих проектах, видать эта байка родилась после того, как bobuk добавил в список сайтов, использующих вебпи, добавил сайт яндекса). Если и используют то для внутренних сайтов и для мелочей. У меня блог на нём вертится, довольно шустро работает.
Но cherry получше будет, в вебпи довольно убогий шаблонизатор. Но всему своё место, я использую вебпи в простых утилитах где надо выводить инфу (статистика, мониторилки, чекеры с вебинтерфейсом и тп).
Всему своё место;) Для более серьёзных вещей я б брал werkzeug +sqlalchemy + jinja2 + wtfform
Pylons отпугивает paste и глобальными переменными.
А крикунам, которые дальше джанги ничего не видят, советую глянуть хотя бы werkzeug.pocoo.org/wiki30/ для расширения кругозора ;)
Но cherry получше будет, в вебпи довольно убогий шаблонизатор. Но всему своё место, я использую вебпи в простых утилитах где надо выводить инфу (статистика, мониторилки, чекеры с вебинтерфейсом и тп).
Всему своё место;) Для более серьёзных вещей я б брал werkzeug +sqlalchemy + jinja2 + wtfform
Pylons отпугивает paste и глобальными переменными.
А крикунам, которые дальше джанги ничего не видят, советую глянуть хотя бы werkzeug.pocoo.org/wiki30/ для расширения кругозора ;)
webpy используется — не наружу, но используется.
Что-то кругозор испугался и забилсяв угол, но не расширился;-)
Что-то кругозор испугался и забилсяв угол, но не расширился;-)
мне web.py нравится своей дубовостью.
чем-то похож на автомат калашникова — такой же простой и нетребовательный.
да, в нем многого нет, да он слишком прост.
зато его можно за 4 часа изучить полностью (даже без документации, по одним только исходникам) и использовать для маленьких проектов.
чем-то похож на автомат калашникова — такой же простой и нетребовательный.
да, в нем многого нет, да он слишком прост.
зато его можно за 4 часа изучить полностью (даже без документации, по одним только исходникам) и использовать для маленьких проектов.
я бы сказал, что Tornado интереснее и хорошо набирает обороты.
Тормозят рельсы или конкретная реализация конкретной задачи чисто конкретными программистами?
Или рельсыф провоцируют программистов на написание говнокода?
Или рельсыф провоцируют программистов на написание говнокода?
у меня такое мнение сложилось из за Twitter-а.
он как раз на RoR и построен.
и в начале года все время ложился из за нагрузки. его вроде бы собирались переписать на Grails, но или RoR ушел далеко вперед, или инженеры твиттера что-то предприняли, последнее время он работает стабильно.
он как раз на RoR и построен.
и в начале года все время ложился из за нагрузки. его вроде бы собирались переписать на Grails, но или RoR ушел далеко вперед, или инженеры твиттера что-то предприняли, последнее время он работает стабильно.
На RoR только фронтенд. Бэкенд на Scala/JVM. Информация из первоисточника: Scaling Twitter: Making Twitter 10000 Percent Faster.
Позволю себе процитировать:
Позволю себе процитировать:
Twitter moved to the Java JVM for their server infrastructure (long lived processes) and moved to Scala to program against it (high level language, static typing, functional). Ruby is used on the front-end but wasn't performant or reliable enough for the back-end.
* Формы, вернее form_for, жестко привязана к ActiveRecord. Пока не нашел красивой работы с иными моделями (кастомными и ActiveResource).
* Очень много вариантов выбора (даже Pylons меньше запутывает) — несколько ORM, множество средств тестирования, шаблонизаторов, систем авторизации, acts_as_ плагинов итд тип. Смущает новичка, стараюсь пользоваться проверенными средствами.
Получилось? :)
* Очень много вариантов выбора (даже Pylons меньше запутывает) — несколько ORM, множество средств тестирования, шаблонизаторов, систем авторизации, acts_as_ плагинов итд тип. Смущает новичка, стараюсь пользоваться проверенными средствами.
Получилось? :)
Комментарии интресные, подчеркнул для себя пару моментов! Спасибо!
Хоть и люблю я джанго, но статья ни о чем.
Не очень аргументировано. Я вот использую Yii, и все, что вы написал о Django, можно полностью сказать и о Yii.
Django vs RoR trends
Питон я сразу отмел, так как выделение блоков пробело-табами меня сразу расстроило :)
А вы попробуйте. У меня тоже вначале были мысли в духе «Чо за бред?», а потом наоборот, понравилось. Сейчас скобки в «традиционных» ЯП начинают немного раздражать: место занимают, а вот читабельность кода не сильно повышают, так как код «размывается».
Сейчас уже многие выделяют это как влюс пайтона.
Почему? Да вы только посмотрите код всякий фреймворков на php!
Даже в простейшем коде сам чёрт ногу сломит!
А пайтон на уровне семантики заставляет человека писать хоть сколько-нибудь читабельный код.
Почему? Да вы только посмотрите код всякий фреймворков на php!
Даже в простейшем коде сам чёрт ногу сломит!
А пайтон на уровне семантики заставляет человека писать хоть сколько-нибудь читабельный код.
Это только поначалу непривычно. А потом ловишь себя на мысли, что ты все равно это делал всю жизнь :) Только раньше это было ради простоты чтения и вроде не особо нужно, а теперь осмысленно.
В итоге на питоне очень трудно написать нечитаемый код. Я не имею ввиду случаи, когда поставлена такая цель, а когда пишется нормальный проект.
В итоге на питоне очень трудно написать нечитаемый код. Я не имею ввиду случаи, когда поставлена такая цель, а когда пишется нормальный проект.
когда выбирал скриптовой язык для изучения и применения, это меня тоже смущало очень. но в итоге — привык.
Такого распространения, количества библиотек, логичности нету ни у одного скриптового языка!
Ближайший конкурент тут только ява, но она совсем в другой нише.
Такого распространения, количества библиотек, логичности нету ни у одного скриптового языка!
Ближайший конкурент тут только ява, но она совсем в другой нише.
Восходит солнце, и заходит солнце, и на место свое поспешает,
Чтобы там опять взойти;
Бежит на юг и кружит на север, кружит, кружит на бегу своем ветер,
И на круги свои возвращается ветер;
Бегут все реки в море, — а море не переполнится,
К месту, куда реки бегут, — Туда они продолжают бежать;
Всё — одна маята
====================
Кстати, мне тоже напомнило какую-то древность типа Васика.
Чтобы там опять взойти;
Бежит на юг и кружит на север, кружит, кружит на бегу своем ветер,
И на круги свои возвращается ветер;
Бегут все реки в море, — а море не переполнится,
К месту, куда реки бегут, — Туда они продолжают бежать;
Всё — одна маята
====================
Кстати, мне тоже напомнило какую-то древность типа Васика.
Для меня недавно стал вопрос: что использовать Ruby или Python. (PHP — надоел почему-то)))). Сначала попробовал Питон и Джанго. Написал простенькое приложение. Вобщем-то все понравилось. Затем попробовал Ruby и RoR — понравилось еще больше)))) Решил так: для веба-буду использовать рельсы и решил углубляться в них. Питон хорошо для сетевого программирования. Очень порадовал фреймворк Tornado (он подойдет для не очень сложных задач веба при сложном сетевом взаимодейтсвии). Вот, как пример комбинирования этих технологий, недавний проект: habrahabr.ru/blogs/i_am_advertising/73829/
Писал один проект на питоне и диджанго вылезли такие минусы:
1) IDE нормальных нету. PyDev местами глючил. Debug с точками останова в NetBeans завести так и не удалось
2) В шаблонах не python, а свой велосипед (не лучший) изобрели
3) С MySQL были большие memory-leaks. Хорошо, что проект небольшой и легко было перейти на postgre
4) ORM не поддерживает BLOB
5) Кастомизация аутенфикации и авторизации походу не очень приятная вещь, так и не успели сделать
1) IDE нормальных нету. PyDev местами глючил. Debug с точками останова в NetBeans завести так и не удалось
2) В шаблонах не python, а свой велосипед (не лучший) изобрели
3) С MySQL были большие memory-leaks. Хорошо, что проект небольшой и легко было перейти на postgre
4) ORM не поддерживает BLOB
5) Кастомизация аутенфикации и авторизации походу не очень приятная вещь, так и не успели сделать
1) Я и мои знакомые сидим на Geany. Просто нет причины исопльзовать тяжеловесный PyDev. Единственный минус — нет дебага. Остальное устраивает.
2) В смысле? Вы вместе системы шаблонов джанго использовали что-то иное? Шаблонная система джанго это не пайтон. Или я не правильно понял ваше «В шаблонах не python»?
3) С MySQL или с Django? Если именно с MySQL то вы не в тот тред это написали.
4) Это да, проблема. Не помню как там оно сейчас, но раньше просто создавали новый тип полей в бекэнде. buffis.com/2007/07/25/modifying-django-to-have-a-blobfield-for-storing-binary-data-in-mysql/
5) Куда уж приятнее? djbook.ru/ch12s03.html
2) В смысле? Вы вместе системы шаблонов джанго использовали что-то иное? Шаблонная система джанго это не пайтон. Или я не правильно понял ваше «В шаблонах не python»?
3) С MySQL или с Django? Если именно с MySQL то вы не в тот тред это написали.
4) Это да, проблема. Не помню как там оно сейчас, но раньше просто создавали новый тип полей в бекэнде. buffis.com/2007/07/25/modifying-django-to-have-a-blobfield-for-storing-binary-data-in-mysql/
5) Куда уж приятнее? djbook.ru/ch12s03.html
1) Ну вот отсутствие дебага довольно неприятная вещь. Все писать в лог, а потом разбирать тонны его как-то неприятно. Вы ж не станете утверждать что у вас код всегда без багов выходит?
2) Django template language если быть точным. Если бы там был сам питон, то мне не нужно было бы писать свои фильтры. Это множество if, ifnotequal, ifequal… Нельзя сделать break в цикле. Ну не знаю, лучше уж вставки именно python кода, а сам разаработчик сам уже решит на свое усмотрение то ли выносить код из presentation layer или нет.
3) Все дело в mysqldb как оказалось. Так что тред имхо верный
5) Ну я насколько понял, чтобы сделать аутенфикацию по email, а не login, то необходимо лезть в Middleware
ИМХО
2) Django template language если быть точным. Если бы там был сам питон, то мне не нужно было бы писать свои фильтры. Это множество if, ifnotequal, ifequal… Нельзя сделать break в цикле. Ну не знаю, лучше уж вставки именно python кода, а сам разаработчик сам уже решит на свое усмотрение то ли выносить код из presentation layer или нет.
3) Все дело в mysqldb как оказалось. Так что тред имхо верный
5) Ну я насколько понял, чтобы сделать аутенфикацию по email, а не login, то необходимо лезть в Middleware
ИМХО
5. Нет, пишется auth backend и подключается (http://byteflow.su/browser/apps/accounts/backends.py#L36)
1) А по-моему так с дебаггингом все отлично. Откройте для себя pdb или ipdb, это проще, чем кажется. Пишете «import ipdb;ipdb.set_trace()» и в консоли, в которой runserver запущен, в точке останова появится дебаггер.
2) Ну с if'ами в 1.2, думаю, разберутся. В 1.х ничто не мешает пользоваться сторинними template-tag'ами: www.djangosnippets.org/snippets/1350/. Если хотите, чтоб он был по умолчанию, напишите
from django.template.loader import add_to_builtins
add_to_builtins('smart_tags.templatetags.smart_if')
5) нет
2) Ну с if'ами в 1.2, думаю, разберутся. В 1.х ничто не мешает пользоваться сторинними template-tag'ами: www.djangosnippets.org/snippets/1350/. Если хотите, чтоб он был по умолчанию, напишите
from django.template.loader import add_to_builtins
add_to_builtins('smart_tags.templatetags.smart_if')
5) нет
прошу прощения, вторая ссылка недописана :)
http://night-fairy-tales.blogspot.com/2009/10/djangoeclipse-autoreload-django-debug.html
http://night-fairy-tales.blogspot.com/2009/10/djangoeclipse-autoreload-django-debug.html
> Ну вот отсутствие дебага довольно неприятная вещь.
А у нас в php все проще: пишешь в нудное место код например var_dump($var) — и все можно посомтреть, без уродских сложных IDE на Яве.
А у нас в php все проще: пишешь в нудное место код например var_dump($var) — и все можно посомтреть, без уродских сложных IDE на Яве.
Это не дебаг, а дуйня, которая работает только при незначительных ошибках. Лучше пару раз пробежаться «сложным» дебагом, чем весь день вставлять в разных местах var_dump и искать закономерности.
Если это быстрее даст результат, то нифига не хуже. Чем возиться с этими дебанггерами, настраивать, запускать какую-нибудь убогую тяжеленную IDE на яве, нафиг нужно (а консольный дебаггер — вообще ад).
Ну а если вам, чтобы все заработало, надо «весь день» отлаживать программу, может стоит код правильно переписать? На модули там разбить какие-нибудь.
Ну а если вам, чтобы все заработало, надо «весь день» отлаживать программу, может стоит код правильно переписать? На модули там разбить какие-нибудь.
А вы пишете в Блокноте, да?
В блокноте с подсветкой, автодополнением и сокращениями под названием Scite. Не тормозит и не ест память, запускается сразу, весит мало, очень удобно.
Да и на том же Маке, в культовом TextMate никакого дебага нет.
Да и на том же Маке, в культовом TextMate никакого дебага нет.
Ладно, не буду спорить, а то потом экрана не хватит.
Если я не ошибаюсь, для PHP пока нет полноценного (= безглючного и удобного в использовании) дебаггера с поддержкой трассировки. Примерно раз в полгода я проверяю dbg и xdebug (в связке с Eclipse) и в очередной раз убеждаюсь, что с ними все по-прежнему достаточно плохо.
Думаю, именно поэтому люди в основной массе и предпочитают вместо отладчика применять print_r. Барьер входа в последний намного ниже и, действительно, чаще всего удается отловить ошибки минимальной кровью. (А если использовать концепции Test Driven Development или хотя бы просто писать тесты через несколько минут, а не дней, после написания кода, необходимость в отладке резко уменьшается.)
Если кто-то таки поставил на поток использование полноценного отладчика в PHP (пусть даже платного), напишите, пожалуйста. Будет очень интересно.
И я надеюсь, что в Python дела обстоят менее плачевно в этом отношении (но почему-то подозреваю, что там примерно то же самое происходит, или нет?).
Думаю, именно поэтому люди в основной массе и предпочитают вместо отладчика применять print_r. Барьер входа в последний намного ниже и, действительно, чаще всего удается отловить ошибки минимальной кровью. (А если использовать концепции Test Driven Development или хотя бы просто писать тесты через несколько минут, а не дней, после написания кода, необходимость в отладке резко уменьшается.)
Если кто-то таки поставил на поток использование полноценного отладчика в PHP (пусть даже платного), напишите, пожалуйста. Будет очень интересно.
И я надеюсь, что в Python дела обстоят менее плачевно в этом отношении (но почему-то подозреваю, что там примерно то же самое происходит, или нет?).
зачем в шаблонах python? Это не PHP. И в чём минусы велосипеда?
Eclipse+PyDev — практически идеально решение. Возможно, в винде у этой связки и есть какие-то проблемы, у себя и у моих сотрудников в линуксе их вообще ни разу не наблюдал. Отладка тоже работает на ура, хотя некоторые придирки к отладчику все-таки есть, но это мелочевка.
MySQL мы вообще перестали использовать в своих проектах. При интенсивной работы с фикчами он очень существенно тормозит, а они у нас очень много используются в юнит-тестах. Сейчас используем исключительно PostgreSQL.
MySQL мы вообще перестали использовать в своих проектах. При интенсивной работы с фикчами он очень существенно тормозит, а они у нас очень много используются в юнит-тестах. Сейчас используем исключительно PostgreSQL.
как бы там не было я за классический asp.net )))
>Автоматически генерируемая админка… она еще и дает возможность клиентам сразу начать работать
Автоматически сгенерировать User Interface не большая проблема. Сделать его удобным (юзабельным) — вот в чем вопрос.
Автоматически сгенерировать User Interface не большая проблема. Сделать его удобным (юзабельным) — вот в чем вопрос.
Все-таки приходится иногда сильно повозиться над некоторыми формами, чтобы люди видели модель так, как им удобно или кажется что удобно.
Это вообще со всеми фреймворками так — сначала все просто и красиво, а как шаг в сторону, начинается копание в мануалах и гугление :)
Это вообще со всеми фреймворками так — сначала все просто и красиво, а как шаг в сторону, начинается копание в мануалах и гугление :)
Давно смотрю в сторону Джанго. Но в юзабельность не верю. Юзабельная админка вообще редкость. От 99% того что руками сделано в стандартных CMS от Joomla до Bitrix просто тошнит. А уж сгенерированная на автомате — это фантастика.
Это не фантастика, это — Python :) в PHP невозможна некая «магия», которую использует Django.
PHP здесь абсолютно непричем. UI — отдельная вещь, повязанная не на язык программирования, а на юзера. Который, сволочь такая, не поддается алгоритмическому описанию. Как бы того не хотелось разработчикам.
Обязательно выучу питон (ЕБЖ). Но в возможность автоматического UI-удовлетворителя — не верю :)
Обязательно выучу питон (ЕБЖ). Но в возможность автоматического UI-удовлетворителя — не верю :)
Админка — это всего-лишь CRUD с базовым ф-ционалом. Плюшечки уже придётся руками дописывать.
Пользуюсь Grails, потому что Java.
Что касается ZF/Rails/Django — то сейчас они уже сравнялись функционально(всё выше описанное есть во всех 3х) и выбор обычно определяется личными мотивами.
Что касается ZF/Rails/Django — то сейчас они уже сравнялись функционально(всё выше описанное есть во всех 3х) и выбор обычно определяется личными мотивами.
Не скажу, чтобы сравнялись. Ну или покажите, как админку в ZF для модкли сделать ;) Как пример.
Под PHP я только с Symfony работал — там админка генерировалась без проблем. В Zend думаю тоже что-то есть.
В любом случаем с тем проектом на Symfony — я переписал админку сам, вышло 6 разделов(для каждой сущности по справочнику) — 2 раздела(логических, чуть с более сложной структурой, но гораздо более производительных для пользователя).
В любом случаем с тем проектом на Symfony — я переписал админку сам, вышло 6 разделов(для каждой сущности по справочнику) — 2 раздела(логических, чуть с более сложной структурой, но гораздо более производительных для пользователя).
Там (в симфони) админка генерируется статически или динамически?
Статически естественно. Иначе это бы нехило тормозило, как мне кажется.
Ну вот в джанге не тормозит :)
В любом случае это работает дольше — а следовательно тормозит в перспективе, никаких плюсов в генерировании динамически тут не вижу.
Что работает дольше? Оно генериться при старте и работает до его смерти-перезапуска. Нечему там особо тормозить. К тому же, админка не должна выдерживать миллионов хитов в секунду, поэтому до тормозов её довести очень сложно.
Плюс в генерировании динамически в том, что вы внеся изменения в модели должны только перезапустить сервер, а не запускать перегенерацию админки. Тем более, что части её могут быть взаимосвязаны и перегенерировать может понадобиться много чего.
Не вижу особой разницы в генерировании при старте сервера или при внесении изменений в модель.
Динамическая генерация это немного другое.
Динамическая генерация это немного другое.
Нет, динамическая генерация это именно то. Система сама собирает админку в соотв. с моделями и уточняющими декларациями.
В моём понятии — динамика = рантайм, статика = этап запуска/компиляции.
В symfony при генерации админки создаюся разные файлы, пишутся настройки всякие, а потом это предлагают править. Так?
В django при генерации создаются классы, необходимые для админки. Не статичные файлы с кодом да диске. В php это принципиально не возможно, т.к. в php нет метаклассов.
Т.е. в django мы имеем не автоматизированный и параметризованный копи-пейст, как обычно это бывает. От созданных джангой классов можно наследоваться, ну и как угодно расширять их функционал.
В django при генерации создаются классы, необходимые для админки. Не статичные файлы с кодом да диске. В php это принципиально не возможно, т.к. в php нет метаклассов.
Т.е. в django мы имеем не автоматизированный и параметризованный копи-пейст, как обычно это бывает. От созданных джангой классов можно наследоваться, ну и как угодно расширять их функционал.
Запуск, точнее инциаилизация непосредственно после запуска, это разве не часть рантайма?
Плюс в гибкости. Не нужно ничего генерировать и потом перегенерировать в случае изменений.
А тормозить не будет к примеру потому, что:
1) Дополнительная нагрузка минимальна.
2) Это не ботлнек, туда имеют доступ только админы.
А тормозить не будет к примеру потому, что:
1) Дополнительная нагрузка минимальна.
2) Это не ботлнек, туда имеют доступ только админы.
2) Зависит от приложения. Иногда админы и есть основные пользователи.
Если админы это основные пользователи, то приложение выворачиваеца наизнанку и фронтендом становиться система управления (админка), которую в таком случае действительно надо писать рукаим.
Т.е. на вашем сайте единовременно будут тысячи админов вбивать данные? И при таком расходе на их зарплату вы пожалеете немного денег на несколько процентов более мощное железо ;)
> Иначе это бы нехило тормозило, как мне кажется.
Кажется. Это не узкое место же.
Кажется. Это не узкое место же.
вы для себе на grails пишите?
сравню для себя с Ruby on Rails:
1. Использование Python в качестве языка программирования: руби не самый идеальный и быстрый язык, синтаксис удобнее даже питона. Хорошая документация и «мощь метапрограммирования» присутствует.
2. Великолепная документация: guides.rubyonrails.com/ отличная документация.
3. Встроенный ORM (Object-relational mapper) в Ruby on Rails чудесная поддержка ORM.
4. Автоматически генерируемая админка: Ruby on Rails позволяет создать скаффолды, хотя пожалуй автоматическая админка единственный, пока, плюс джанго.
5. Поддержка MTV: Ruby on Rails — поддержка MVC
6. Высркая скрорость работы в Ruby on Rails отличные инструменты для кэширования, отладки, тестирования и пожалуй они лучше даже джанго.
Лично я не нашел для себя плюсов в django, статья не убедительна :)
1. Использование Python в качестве языка программирования: руби не самый идеальный и быстрый язык, синтаксис удобнее даже питона. Хорошая документация и «мощь метапрограммирования» присутствует.
2. Великолепная документация: guides.rubyonrails.com/ отличная документация.
3. Встроенный ORM (Object-relational mapper) в Ruby on Rails чудесная поддержка ORM.
4. Автоматически генерируемая админка: Ruby on Rails позволяет создать скаффолды, хотя пожалуй автоматическая админка единственный, пока, плюс джанго.
5. Поддержка MTV: Ruby on Rails — поддержка MVC
6. Высркая скрорость работы в Ruby on Rails отличные инструменты для кэширования, отладки, тестирования и пожалуй они лучше даже джанго.
Лично я не нашел для себя плюсов в django, статья не убедительна :)
насчет m-to-m и 1-to-m:
guides.rubyonrails.org/association_basics.html ассоциации в рельсах.
belongs_to связь 1-to-m, или has_many m-to-m, а так-же вариации
Пр.: у нас есть модель Articles и модель Comments в модели Articles достаточно вписать has_many :comments а в модели Comments belongs_to :article и получаем связи. Интуитивно и понятно а главное в 2 строках.
Выборка осуществляется примерно так @products = Product.all, вовыд всех продуктов, так-же можно выводить по условиям Product.find(условия). Или сложные связаные записи @comments = Comments.Article(ид_статьи) найдет все комментарии к статьи с id = ид_статьи. подробнее можно почитать тут guides.rubyonrails.org/active_record_querying.html
Про скаффолды можно почитать тут guides.rubyonrails.org/getting_started.html#getting-up-and-running-quickly-with-scaffolding
Лично я не люблю скаффолды, но раз они есть, значит людям нравится :) Прошу прощения лень искать скриншоты :) выглядят они как обычные хтмл формы без верстки, но включают в себя функционал CRUD с валидацией.
guides.rubyonrails.org/association_basics.html ассоциации в рельсах.
belongs_to связь 1-to-m, или has_many m-to-m, а так-же вариации
Пр.: у нас есть модель Articles и модель Comments в модели Articles достаточно вписать has_many :comments а в модели Comments belongs_to :article и получаем связи. Интуитивно и понятно а главное в 2 строках.
Выборка осуществляется примерно так @products = Product.all, вовыд всех продуктов, так-же можно выводить по условиям Product.find(условия). Или сложные связаные записи @comments = Comments.Article(ид_статьи) найдет все комментарии к статьи с id = ид_статьи. подробнее можно почитать тут guides.rubyonrails.org/active_record_querying.html
Про скаффолды можно почитать тут guides.rubyonrails.org/getting_started.html#getting-up-and-running-quickly-with-scaffolding
Лично я не люблю скаффолды, но раз они есть, значит людям нравится :) Прошу прощения лень искать скриншоты :) выглядят они как обычные хтмл формы без верстки, но включают в себя функционал CRUD с валидацией.
Прошу прощения за опечатки, трудный день глаза слипаются :)
> Несмотря на то, что Python не блещет скоростью
o_O
А кто из скриптовых языков быстрее его, за исключением деревянного lua?
o_O
А кто из скриптовых языков быстрее его, за исключением деревянного lua?
Ну можно сравнивать не со скриптовыми языками. Например, сам Grails практически весь написан на Java/Spring/Hibernate, на Groovy пишется лишь бизнес-логика самого приложения. Очень «производительный» подход.
а чем вам lua не угодил? Почему «деревянный»?
вообще то php быстрее. К сожалению…
Можно ссылочку на сравнение ;)
На питон + JIT для ООП-кода я добился 7% C++ной скорости.
И даже без JIT для ООП-кода разница на 60% в пользу питона(скрипт проверки на 10м итераций с вызовом метода и математического действия)
А с psyco выигрыш был в 10(!!!) раз. Полторы секунды против 16.
На питон + JIT для ООП-кода я добился 7% C++ной скорости.
И даже без JIT для ООП-кода разница на 60% в пользу питона(скрипт проверки на 10м итераций с вызовом метода и математического действия)
А с psyco выигрыш был в 10(!!!) раз. Полторы секунды против 16.
Сравнение тут — shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=python&box=1
Там, насколько я знаю, только ванильные возможности, без psyco. Видно, что в среднем, питон быстрее-компактнее и менее прожорлив на память. Но это синтетика, конечно.
Там, насколько я знаю, только ванильные возможности, без psyco. Видно, что в среднем, питон быстрее-компактнее и менее прожорлив на память. Но это синтетика, конечно.
На хабре сравнивали php, ruby1.8, ruby 1.9 и python там в результатах был такой порядок скорости
ruby1.9->php->python->ruby1.8
так что чем минусовать спрашивайте.
И говорю я естественно про безJitовый код
ruby1.9->php->python->ruby1.8
так что чем минусовать спрашивайте.
И говорю я естественно про безJitовый код
и где ж Вы откопали безJitовый ruby1.9?)
насколько я помню, последние два больших теста на хабре свелись к тому, что почти все одинаковые по скорости.
если это тот тест что я думаю (в котором РНР оказался быстрее Пайтона), то был абсолютно идиотский тест, мерящий непонятно что.
автор того «теста» измерял скорость работы print в цикле.
что конечно офигеть как показывает производительность различных языков…
автор того «теста» измерял скорость работы print в цикле.
что конечно офигеть как показывает производительность различных языков…
Есть например сравнение по числодробительным возможностям на основе расчета фрактала:
www.timestretch.com/FractalBenchmark.html
Правда тесты довольно-таки староваты, по-хорошему надо бы их прогнать на современных версиях ЯП. Ну и ради справедливости надо добавить что есть JPython (для JVM) и IronPython (для .NET), которые в некоторых случаях могут работать весьма шустро. Я не говорю уже про всякие расширения типа psyco.
По себе скажу, что я вообще уже давно забил на сравнение производительности, т.к. в основном узкие места — это взаимодействия со внешней средой (БД, файловой системой, сетью и т.п.) Есть, конечно, области, где скорость важна — мультимедиа приложения, или реально высоконагруженные сайты. И здесь уже не до религиозных споров — выбираются технологии по возможностям. Но замечу, что YouTube все-таки написан на Python.
www.timestretch.com/FractalBenchmark.html
Правда тесты довольно-таки староваты, по-хорошему надо бы их прогнать на современных версиях ЯП. Ну и ради справедливости надо добавить что есть JPython (для JVM) и IronPython (для .NET), которые в некоторых случаях могут работать весьма шустро. Я не говорю уже про всякие расширения типа psyco.
По себе скажу, что я вообще уже давно забил на сравнение производительности, т.к. в основном узкие места — это взаимодействия со внешней средой (БД, файловой системой, сетью и т.п.) Есть, конечно, области, где скорость важна — мультимедиа приложения, или реально высоконагруженные сайты. И здесь уже не до религиозных споров — выбираются технологии по возможностям. Но замечу, что YouTube все-таки написан на Python.
Последний раз когда смотрел django столкнулся с тем что туда тяжело прикрутить репликацию или шардинг. Да и вообще сделать чтобы несколько серверов баз данных использовалтсь — проблема.
За последний год в этом направлении что-то изменилось?
За последний год в этом направлении что-то изменилось?
сравню для себя с ASP.NET:
1. Использование Python в качестве языка программирования:
C# 3.0 с Generic-ами, элементами функционального подхода, библиотеками, заточенными под этом. С огромной MSDN. С кучей реализаций AOP. Да в общем просто не сравним с скриптовым языком. Не говоря уже про скорость работы кода.
2. Великолепная документация:
msdn.microsoft.com и ТЬМА других ресурсом
3. Встроенный ORM (Object-relational mapper)
Entity Framework, LINQ2SQL (эти две встроены в Студию), NHibernate, и ТЬМА других ORM
4. Автоматически генерируемая админка:
ASP.NET DynamicData Website — встроенный тип проекта в Студии.
5. Поддержка MTV:
MVC — в ASP.NET MVC, MVP — в ASP.NET WebForms — на любой вкус
6. Отличные инструменты для кэширования, отладки, тестирования
Visual Studio. Без комментариев вообще.
«Лично я не нашел для себя плюсов в django, статья не убедительна :)»(с)
Ну то есть объективно, конкуренция между разными технологиями работает. Всё подтягиваются потихоньку. Но я всё равно люблю ASP.NET :)
1. Использование Python в качестве языка программирования:
C# 3.0 с Generic-ами, элементами функционального подхода, библиотеками, заточенными под этом. С огромной MSDN. С кучей реализаций AOP. Да в общем просто не сравним с скриптовым языком. Не говоря уже про скорость работы кода.
2. Великолепная документация:
msdn.microsoft.com и ТЬМА других ресурсом
3. Встроенный ORM (Object-relational mapper)
Entity Framework, LINQ2SQL (эти две встроены в Студию), NHibernate, и ТЬМА других ORM
4. Автоматически генерируемая админка:
ASP.NET DynamicData Website — встроенный тип проекта в Студии.
5. Поддержка MTV:
MVC — в ASP.NET MVC, MVP — в ASP.NET WebForms — на любой вкус
6. Отличные инструменты для кэширования, отладки, тестирования
Visual Studio. Без комментариев вообще.
«Лично я не нашел для себя плюсов в django, статья не убедительна :)»(с)
Ну то есть объективно, конкуренция между разными технологиями работает. Всё подтягиваются потихоньку. Но я всё равно люблю ASP.NET :)
один огромный минус — работает только под win, на серверах вообще не нужно
Вы шутите? Сервер == Unix-based? на дворе 2009-ый, проснитесь. Что ни крупный заказ — Windows Server и ASP.NET, а вы говорите, на серверах не нужно. Если вариться в междусобойчике php-python-ruby, то конечно можно считать, что окружающего мира не существует. Но он есть :)
windows server и asp.net, потому что заказчик — лох и ведется на цветную рекламу microsoft. рассказывайте о преимуществах ws и .net на каком-нибудь форуме для менеджеров, тут тех. специалисты собрались, нечего нам лапшу на уши вешать.
вы нечётки в каждом посте.
1) server != unix, это раз
2) цветную рекламу я тут не показывал, так что «лапшу» оставьте себе.
Я же сказал про технические аспекты, а вам неприязнь к слову Microsoft не даёт увидеть их технические плюсы.
Вы видели как устроена IT-инфраструктура, например, в Raiffeisen? Вы всерьёз думаете, что они из-за красивой рекламы WinServer покупают?) Вроде ж серьезные люди, в финансовом мире не ведутся на лохотрон, а тут вот раз — и наивные ягнята, берут первое что в красивой упаковке. Вы реально так считаете?
1) server != unix, это раз
2) цветную рекламу я тут не показывал, так что «лапшу» оставьте себе.
Я же сказал про технические аспекты, а вам неприязнь к слову Microsoft не даёт увидеть их технические плюсы.
Вы видели как устроена IT-инфраструктура, например, в Raiffeisen? Вы всерьёз думаете, что они из-за красивой рекламы WinServer покупают?) Вроде ж серьезные люди, в финансовом мире не ведутся на лохотрон, а тут вот раз — и наивные ягнята, берут первое что в красивой упаковке. Вы реально так считаете?
в Raiffeisen может все серьезно и устроено, но купили они winserver либо из-за красивой рекламы, либо из-за «политического» решения, но точно не из-за технических преимуществ — их просто нет. Квалифицированные программисты и под Dos все правильно и серьезно напишут, лишь бы платили.
то есть либо всё таки Raiffeisen ягнята, и ведутся на обёртку, либо «политическое»… а что это за политика такая? всемирный заговор купленных микрософтом генеральных директоров?))
Скажите просто, что вы предложите корпорации вместо SharePoint?
Скажите просто, что вы предложите корпорации вместо SharePoint?
«политическое» — это когда тем людям, кто решение принимает в компании о выборе платформы производитель платформы платит деньги, или дарит подарки. откат по-русски
по описанию, sharepoint — какой-то костыль для костыля ms office
скажите, что требуется от этого продукта (лень вникать), я назову кроссплатформенную альтернативу
по описанию, sharepoint — какой-то костыль для костыля ms office
скажите, что требуется от этого продукта (лень вникать), я назову кроссплатформенную альтернативу
Ок, Microsoft купила весь мир и заставила пользоваться своим софтом. А кого-то не купила, и они обиделись и сделали oss. :-D Я не считаю такую модель мира обоснованной. Но это бесполезная дискуссия.
Что касается SharePoint, то если раз вы не знаете, что это такое, то вообще не имеете представления о корпоративной инфраструктуре. На этом можно было бы ставить точку, в принципе.
1) НЕ имеет отношения к Офису, хотя и называется с этим словом.
2) Это платформа для обеспечения работы всего предприятия, — одним словом не описать, — но, среди прочего
— корпоративная CMS, чтобы быстро завести внутренний или внешний портал для начатого нового проекта, с поддержкой
— рабочих процессов,
— библиотек документов,
— с версионностью и блокировками, если надо,
— интеграцией (разумеется) с Active Directory,
— платформа для разработки на базе её кастомных решений, с неплохой объектной моделью всего этого для программного доступа.
С каким серьёзным предприятием не сталкивался, везде стоит Active Directory и SharePoint, прямо таки отраслевой стандарт. А вы словно не замечаете этого. Странно, и забавно)
Что касается SharePoint, то если раз вы не знаете, что это такое, то вообще не имеете представления о корпоративной инфраструктуре. На этом можно было бы ставить точку, в принципе.
1) НЕ имеет отношения к Офису, хотя и называется с этим словом.
2) Это платформа для обеспечения работы всего предприятия, — одним словом не описать, — но, среди прочего
— корпоративная CMS, чтобы быстро завести внутренний или внешний портал для начатого нового проекта, с поддержкой
— рабочих процессов,
— библиотек документов,
— с версионностью и блокировками, если надо,
— интеграцией (разумеется) с Active Directory,
— платформа для разработки на базе её кастомных решений, с неплохой объектной моделью всего этого для программного доступа.
С каким серьёзным предприятием не сталкивался, везде стоит Active Directory и SharePoint, прямо таки отраслевой стандарт. А вы словно не замечаете этого. Странно, и забавно)
1) Не понял фразу «А в гугле — питон, да»
2) Я писал про какой-то многомилионный проект?
Если вы про Гендикс, то мы почти не занимаемся «просто сайтами».
Деньги мы делаем на консультациях/аутсорсинге в интеграционных проектах (например, XML-веб-сервис авиарасписания с интеграцией в разные клиентские приложения), причём чаще всего не можем поместить это в портфолио, т.к. «официально» работу делает другая студия.
А кроме этого мы развиваем свой стартап asklive.ru, и там, кстати, _есть что_, что сложно реализовать на чём-то ещё. Но это надо глубже копнуть в суть.
2) Я писал про какой-то многомилионный проект?
Если вы про Гендикс, то мы почти не занимаемся «просто сайтами».
Деньги мы делаем на консультациях/аутсорсинге в интеграционных проектах (например, XML-веб-сервис авиарасписания с интеграцией в разные клиентские приложения), причём чаще всего не можем поместить это в портфолио, т.к. «официально» работу делает другая студия.
А кроме этого мы развиваем свой стартап asklive.ru, и там, кстати, _есть что_, что сложно реализовать на чём-то ещё. Но это надо глубже копнуть в суть.
1 — ну Raiffeisen не Гугль, всё же. И таких компаний _из встреченных мною на жизненном пути_ — большинство. Может у меня путь такой, но тем не менее. То есть я просто говорю, что MS как серверная платформа вовсе не «не существует», а очень даже нормально существует, и даже имеет свои плюсы, как и минусы.
И хорошо, что у других не хуже, я, в отличие от никсоидов, не кричу, что «всё, что не .net — отстой».
2 — вы неверно поняли, это как раз в nix-сообществе есть такое мнение, что MS так себя позиционирует.
Например, коммент ниже: «ну то есть вы предлагаете для (относительно) простых веб сайтов использовать дотнет? мм… не смешно.
а в весовой категории «корпоративные сайты/веб-приложения» сравнивать надо с...».
Этот коммент выражает общее мнение вашего мира, что .net — это что-то большое и громоздкое для чего-то большого.
А я как раз считаю, что C# это для начала удобный скриптовый язык. Который, кстати, можно даже 5 строчками кода _встроить в свою программу_.
И поэтому делать на ASP.NET даже что-то простое — вполне оправдано, если вы на этой технологии умеете работать.
3 — насчёт особенностей платформы в нашем стартапе, там есть такой момент:
нужно делать выборку из БД, критерием которой является результат работы сложного алгоритма, реализовать который на SQL технически сложно и неэффективно. MS SQL Server умеет хостить в себе среду .NET, что позволило описать хранимку прямо на C#, т.о. на стороне SQL выполнить наш сложный алгоритм, реализованный на более удачном для этого C#.
И хорошо, что у других не хуже, я, в отличие от никсоидов, не кричу, что «всё, что не .net — отстой».
2 — вы неверно поняли, это как раз в nix-сообществе есть такое мнение, что MS так себя позиционирует.
Например, коммент ниже: «ну то есть вы предлагаете для (относительно) простых веб сайтов использовать дотнет? мм… не смешно.
а в весовой категории «корпоративные сайты/веб-приложения» сравнивать надо с...».
Этот коммент выражает общее мнение вашего мира, что .net — это что-то большое и громоздкое для чего-то большого.
А я как раз считаю, что C# это для начала удобный скриптовый язык. Который, кстати, можно даже 5 строчками кода _встроить в свою программу_.
И поэтому делать на ASP.NET даже что-то простое — вполне оправдано, если вы на этой технологии умеете работать.
3 — насчёт особенностей платформы в нашем стартапе, там есть такой момент:
нужно делать выборку из БД, критерием которой является результат работы сложного алгоритма, реализовать который на SQL технически сложно и неэффективно. MS SQL Server умеет хостить в себе среду .NET, что позволило описать хранимку прямо на C#, т.о. на стороне SQL выполнить наш сложный алгоритм, реализованный на более удачном для этого C#.
С точки зрения скриптовости С# не так уж хорош, прежде всего, потому что он компилируется. И хотя практически все скриптовые языки компилируются в промежуточный байт-код, процесс компиляции C#-проектов намного дольше. Я помню на своей практике, когда не такой уж тяжеловесный ASP.NET-сайт запускался по несколько минут из-за компиляции ASPX-страниц.
И не надо умалчивать другие не особо приятные вещи про ASP.NET — громоздкие ViewState-ы на страницах, которые любят забивать трафик, кошмарные автогенерируемые имена для контролов, и вообще любовь этой платформы к памяти и процессору. Естественно, все это решается, однако для простенького сайта слишком уж много чести, чтобы еще разбираться с такого рода проблемами. У ASP.NET есть своя ниша, но простые сайты на этой технологии точно писать не стоит. Я помню в свое время как мы ковыряли движок DNN, и сколько там понаходили кода только для оптимизации проекта, чтобы он крутился более или менее адекватно, хотя проект по сути достаточно простой.
И про СУБД. Oracle и PostgreSQL позволяют писать хранимые процедуры на Java, причем очень давно, и все уже к этому привыкли. Это так, для общего развития, хотя возможно, вы это и знаете.
И не надо умалчивать другие не особо приятные вещи про ASP.NET — громоздкие ViewState-ы на страницах, которые любят забивать трафик, кошмарные автогенерируемые имена для контролов, и вообще любовь этой платформы к памяти и процессору. Естественно, все это решается, однако для простенького сайта слишком уж много чести, чтобы еще разбираться с такого рода проблемами. У ASP.NET есть своя ниша, но простые сайты на этой технологии точно писать не стоит. Я помню в свое время как мы ковыряли движок DNN, и сколько там понаходили кода только для оптимизации проекта, чтобы он крутился более или менее адекватно, хотя проект по сути достаточно простой.
И про СУБД. Oracle и PostgreSQL позволяют писать хранимые процедуры на Java, причем очень давно, и все уже к этому привыкли. Это так, для общего развития, хотя возможно, вы это и знаете.
Грош цена тем «техническим специалистам», кому собственные эмоции не дают объективно оценить технологии, любой компании. Это непрофессионально.
дело не в эмоциях.
c# и .net сам по себе неплох, посмотрите на oss реализацию — mono
windows — это большой костыль, любые хорошие технологии прикрученные сверху будут работать как на костыле
c# и .net сам по себе неплох, посмотрите на oss реализацию — mono
windows — это большой костыль, любые хорошие технологии прикрученные сверху будут работать как на костыле
я согласен, но ведь правда — win как сервер хуже чем linux.
Есть такое расхожее мнение в кругах юниксоидов. Которое ровно обратным образом звучит в сообществе Microsoft-ориентированных разработчиков. Адекватных доводов в пользу этого я _на сегодняшний день_ не вижу. А .NET и вправду классная, и позволяет простить MS многое.
— win как сервер хуже чем linux.
— чем?
— чем linux!
а если серьезно — любая зрелая система отлично подходит для решения своих задач. тут нет абсолютного «лучше» или «хуже».
для чего-то лучше подходит гоночный болид, а для чего-то карьерный самосвал.
— чем?
— чем linux!
а если серьезно — любая зрелая система отлично подходит для решения своих задач. тут нет абсолютного «лучше» или «хуже».
для чего-то лучше подходит гоночный болид, а для чего-то карьерный самосвал.
Знаете, а ведь как это ни странно, я по некоторым пунктам поддержу Андрея. Несмотря на то, что я заядлый PHP-шник и перлист, и программирую в основном для Unix.
Действительно ведь, «php-python-ruby-linux» — отдельный междусобойчик, а продукты MS — отдельный. И они почти не пересекаются, так что тем, кто слева, трудно понять тех, кто справа (и наоборот). Какой из этих междусобойчиков лучше, сказать сложно, т.к. специалистов и в том, и в другом почти нет (я не видел). Мне лично хочется верить, что лучше первый, однако я в последние годы (как представитель первого междусобойчика) все больше ощущаю незримое присутствие второго… причем ощущение такое, что это «второе» ничуть не меньше и даже иногда не хуже «первого».
Возможно, это все из-за того, что я принципиально работаю с Windows на ноутбуке и иногда пишу для Windows довольно низкоуровневые вещи, а не ставлю Linux и не перехожу на Мак. ИМХО это единственный способ быть в курсе того, что происходит в мире MS (глупо было бы на него сейчас глаза закрывать).
P.S.
Кстати, есть еще Java-мир, это вообще третий «междусобойчик». Но только ИМХО (судя по документации к разным Java-продуктам) для Java несколько более приоритетна Windows, чем Linux, так что лично для себя я воспринимаю Java как «недоДотНет» (возможно, ошибочно).
Действительно ведь, «php-python-ruby-linux» — отдельный междусобойчик, а продукты MS — отдельный. И они почти не пересекаются, так что тем, кто слева, трудно понять тех, кто справа (и наоборот). Какой из этих междусобойчиков лучше, сказать сложно, т.к. специалистов и в том, и в другом почти нет (я не видел). Мне лично хочется верить, что лучше первый, однако я в последние годы (как представитель первого междусобойчика) все больше ощущаю незримое присутствие второго… причем ощущение такое, что это «второе» ничуть не меньше и даже иногда не хуже «первого».
Возможно, это все из-за того, что я принципиально работаю с Windows на ноутбуке и иногда пишу для Windows довольно низкоуровневые вещи, а не ставлю Linux и не перехожу на Мак. ИМХО это единственный способ быть в курсе того, что происходит в мире MS (глупо было бы на него сейчас глаза закрывать).
P.S.
Кстати, есть еще Java-мир, это вообще третий «междусобойчик». Но только ИМХО (судя по документации к разным Java-продуктам) для Java несколько более приоритетна Windows, чем Linux, так что лично для себя я воспринимаю Java как «недоДотНет» (возможно, ошибочно).
P.P.S.
На самом деле деление на междусобойчики можно продолжать даже в «php-python-ruby-linux». Например, PHP почти не пересекается с Ruby по приверженцам. Специалисты чаще всего бывают узкие, охватывающие в основном только один язык (или семейство). Для меня, например, такое семейство — старая школа, PHP+Perl. Я совершенно не представляю, чем живут Python-программисты, к примеру.
На самом деле деление на междусобойчики можно продолжать даже в «php-python-ruby-linux». Например, PHP почти не пересекается с Ruby по приверженцам. Специалисты чаще всего бывают узкие, охватывающие в основном только один язык (или семейство). Для меня, например, такое семейство — старая школа, PHP+Perl. Я совершенно не представляю, чем живут Python-программисты, к примеру.
Настораживает, что в Джанге вот уже больше года нет поддержки репликации и шардинга, а в документации и туториалах эти вещи старательно обходятся стороной. Впрочем, в PHP-мире ситуация не лучше: все сидят на своих собственных велосипедах с квадратными колесами и не спешат делиться наработками (хотя в некоторых ORM для PHP и есть поддержка репликации, но она там «номинальная»; видно, что авторы никогда не задумывались, например, о запаздывании реплик и других эффектах).
> т.к. специалистов и в том, и в другом почти нет
имелось в виду «т.к. специалистов ОДНОВРЕМЕННО и в том, и в другом почти нет»
имелось в виду «т.к. специалистов ОДНОВРЕМЕННО и в том, и в другом почти нет»
ТОТ самый Дмитрий Котеров?)
Поддерживаю ваше мнение, но все равно небуду ставить венду даже на нетбук, ибо принцип! К asp не прикоснусь даже если будут платить больше в полтора раза. Вот такой мой ответ проприетарщине!
Поддерживаю ваше мнение, но все равно небуду ставить венду даже на нетбук, ибо принцип! К asp не прикоснусь даже если будут платить больше в полтора раза. Вот такой мой ответ проприетарщине!
А если послушать заказчиков, то это не минус вовсе. С чего вы взяли что это минус? Все пользуются и довольны. Кто не доволен — использует другие ОС. Каждому своё.
А у вас лицензионные windows и visual studio?
Рекомендуете ли вы другим разработчикам купить эти продукты?
Рекомендуете ли вы другим разработчикам купить эти продукты?
я бы если мне и денег дали, этими недоделками пользоваться не стал. есть проверенные годами emacs и vim, есть новомодный, но хороший eclipse.
есть множество приличных os для сервера и декстопа
есть множество приличных os для сервера и декстопа
А каким боком это относится к вопросу?
И зачем покупать БЕСПЛАТНУЮ visual studio?
И зачем покупать БЕСПЛАТНУЮ visual studio?
>А каким боком это относится к вопросу?уточните о каком вопросе идет речь
Судя по тому что вот здесь www.microsoft.com/visualstudio/ru-ru/howtobuy/default.mspx
я вижу слово «Приобрести» и возле Visual Studio® 2008 Professional Edition я вижу циферку 799, я делаю вывод что она платная.
VS Epress Edition, WebSpark, BizSpark, Dream Spark, MSDN AA… и т.д.
> Professional Edition
Express версия стоит ровно $0. То есть бесплатно.
> уточните о каком вопросе идет речь
О подмене понятий «качество» и «стоимость». Считаю, что цена никак не влияет на качество продукта.
И, кстати, серверная винда в Web-редакции стоит дешево. Гораздо дешевле месячного заработка программиста.
Express версия стоит ровно $0. То есть бесплатно.
> уточните о каком вопросе идет речь
О подмене понятий «качество» и «стоимость». Считаю, что цена никак не влияет на качество продукта.
И, кстати, серверная винда в Web-редакции стоит дешево. Гораздо дешевле месячного заработка программиста.
Я пишу из лицензионной Win 7. У меня лицензионная Студия и SQL Server. Мне 25 лет, я директор маленькой веб-команды. Я не платил денег за эти продукты, у MS достаточно программ, чтобы тот, кто озаботился вопросом лицезионности, смог получить всё, что нужно.
Кому интересно, это WebSpark (для веб-студий) и BizSpark (для стартапов), дальше в гугл.
Не говоря уже про бесплатные версии Express.
Так что я с чистой совестью порекомендую другим пользоваться этими продуктами. Причём для некрупных игроков для этого есть бесплатные возможности. А крупным и купить не сложно.
Кому интересно, это WebSpark (для веб-студий) и BizSpark (для стартапов), дальше в гугл.
Не говоря уже про бесплатные версии Express.
Так что я с чистой совестью порекомендую другим пользоваться этими продуктами. Причём для некрупных игроков для этого есть бесплатные возможности. А крупным и купить не сложно.
Вот у меня ровно такие же впечатления от людей из мира unix-решений.
«Хоть бы один раз выяснилось, что фанатичный приверженец Unix-платформы для Web-разработки и правда имеет для этого какие-то веские основания, а не просто иррациональную боязнь MS.»
Забавно, да?)
К тому же, .NET != MS, есть Mono.
А насчёт нового, я постоянно что-то осваиваю, сейчас лямбда-исчисление и ФП. И я в курсе языков типа Python и Ruby. Просто в нашем мире столько всего возникает интересного и прогрессивного, что просто нет возможности охватывать всё, да и нет в том никакой нужды.
Если я буду расширять кругозор, то начну с Java, кстати, а не скриптовых языков.
«Хоть бы один раз выяснилось, что фанатичный приверженец Unix-платформы для Web-разработки и правда имеет для этого какие-то веские основания, а не просто иррациональную боязнь MS.»
Забавно, да?)
К тому же, .NET != MS, есть Mono.
А насчёт нового, я постоянно что-то осваиваю, сейчас лямбда-исчисление и ФП. И я в курсе языков типа Python и Ruby. Просто в нашем мире столько всего возникает интересного и прогрессивного, что просто нет возможности охватывать всё, да и нет в том никакой нужды.
Если я буду расширять кругозор, то начну с Java, кстати, а не скриптовых языков.
Стоп, а зачем вам бесплатная копия? Вы ПО за деньги пишете, так? Вот и операционку можно за деньги купить. Или нельзя?
Если смотреть на фриланс с постингами «сделайте мне сайт за $100», то конечно это невыгодно. Но если ваш контракт весит $100k, то поверьте, заказчику не напряжно заплатить за лицензию windows server, sql server или другой серверной технологии, не говоря уже о железе.
Опять же, есть разница — фриланс с бросовыми ценами и профессиональные компании-разработчики ПО, с нормальными европейскими рейтами и соотвественно с цивильными зарплатами для разработчиков.
Каждому свое, определенно. Я просто хотел сказать что есть сегмент который пишет на Asp.Net, и не особо жалуется на жизнь :)
Опять же, есть разница — фриланс с бросовыми ценами и профессиональные компании-разработчики ПО, с нормальными европейскими рейтами и соотвественно с цивильными зарплатами для разработчиков.
Каждому свое, определенно. Я просто хотел сказать что есть сегмент который пишет на Asp.Net, и не особо жалуется на жизнь :)
выше уже писали, но я погуглил за вас:
например вот.
www.microsoft.com/web/websitespark/
есть ряд других программ.
например вот.
www.microsoft.com/web/websitespark/
есть ряд других программ.
Иррациональная боязнь как раз в другом лагере. Достаточно почитать лор.
ну то есть вы предлагаете для (относительно) простых веб сайтов использовать дотнет? мм… не смешно.
а в весовой категории «корпоративные сайты/веб-приложения» сравнивать надо с java-spring-hibernate-сотоварищи. да и тут выбор в основом зависит от факторов, отличных от приведенного списка.
а в весовой категории «корпоративные сайты/веб-приложения» сравнивать надо с java-spring-hibernate-сотоварищи. да и тут выбор в основом зависит от факторов, отличных от приведенного списка.
зачем в весовой категории «корпоративные сайты» вообще рассматривать дотнет, привязанный к падучей виндовс? когда есть та же ява
бывает нужна интеграция с microsoft-решениями. собственно других причин не вижу :)
хотя с падучестью щас получше, чем во времена 5-го ииса :)
хотя с падучестью щас получше, чем во времена 5-го ииса :)
хотя бы потому, что падучая виндовс осталась в 90-х, где вы видимо до сих пор пребываете.
и потому что .NET на шаг впереди Java.
и потому что .NET на шаг впереди Java.
Да для любых сайтов удобно использовать то, на чём ты пишешь _всё_ остальное. На C# отлично пишется и сервер, запущенный как сервис, и консольная тулза, и WinMobile приложение, равно как и Web. C# — удобная и развитая версия Java, и всё её плюсы, кроме работы на сотовых телефонах, есть в нём.
на python/wxpython отлично пишется все вами перечисленное
Ну и круто, я не ругаю питон. Но мне лично ближе языки со строгой типизацией, так как это снижает количество необходимых тестов, и улучшает подсказку кода при наборе (мелочь, но важная для скорости работы).
И — скорость сервера на питоне ммм… вызывает некие сомнения, так скажем. А у нас компилируемые приложения, всё же.
И — скорость сервера на питоне ммм… вызывает некие сомнения, так скажем. А у нас компилируемые приложения, всё же.
ну вот при всей моей любви к пайтону (мой основной язык) — это уже явно перебор…
пайтон хорош, но не во всех применениях и не везде.
пайтон хорош, но не во всех применениях и не везде.
Покажите пожалуйста на C# бесплатные опенсорсные аналоги Hadoop, Android, Google Web Toolkit, Maven, Eclipse… Я могу и дальше перечислять, но думаю этого для начала хватит.
А мы не болеем бесплатностью и опенсорсностью. У нас деньги есть.
Amazon, Google, eBay, Yahoo, Baidu, Google, Oracle, SAP, Zend и другие бедствующие компании строящие свой бизнес на Hadoop и Eclipse шлют вам привет.
«VS лучшая IDE, Java позади, впарить заказчику продукты от MS» — знаете, я был большего мнения о MVP, оказывается их за троллизм выдают.
«VS лучшая IDE, Java позади, впарить заказчику продукты от MS» — знаете, я был большего мнения о MVP, оказывается их за троллизм выдают.
В том-то и дело, что msdn — тьма.
Касательно функциональных преимуществ, упомянутых в заметке, скажу лишь, что Grails с этой точки зрения ничуть не уступает Django:
* Встроенный ORM — также присутствует (именуется здесь «GORM», в качестве бэкэнда — Hibernate)
* Автоматически генерируемая админка, *одна из уникальных фич, у которой практически нет аналогов* присутствует и в Grails (здесь это называется «scaffolding»)
* Поддержка темплейтов — также присутствует в Grails (в качестве бэкэнда — SiteMesh)
* Встроенный ORM — также присутствует (именуется здесь «GORM», в качестве бэкэнда — Hibernate)
* Автоматически генерируемая админка, *одна из уникальных фич, у которой практически нет аналогов* присутствует и в Grails (здесь это называется «scaffolding»)
* Поддержка темплейтов — также присутствует в Grails (в качестве бэкэнда — SiteMesh)
Прошу заметить, что scaffolding это совсем не то, что джанговская админка. Фундаментально не то.
И да, еще одно:
* в Grails используется Groovy — отличнейший язык программирования, очень удобный, повышающий продуктивность, со множеством всяческих «вкусностей» и т.д.
* в Grails используется Groovy — отличнейший язык программирования, очень удобный, повышающий продуктивность, со множеством всяческих «вкусностей» и т.д.
да, он хороший. и groovy как язык крайне приятственен. но когда я в последний раз смотрел grails, оно тормозило. нет, не так — ТОРМОЗИЛО. может подскажете, есть современные бенчи, такие, чтобы не сферических коней в вакууме мерили? (обленился я, ага)
На Grails работает портал sky.com(самая крупная платная ТВ-сеть Англии, top25 сайт по alexa в UK). Любые бенчмарки — сферические кони в вакууме.
Что касается скорости, она увеличивается с каждой версией Spring, Hibernate, Groovy & JVM(в грядущей версии которой сделают поддержку динамических языков).
Что касается скорости, она увеличивается с каждой версией Spring, Hibernate, Groovy & JVM(в грядущей версии которой сделают поддержку динамических языков).
Я относительно недавно знаком с Grails, но у меня тормозов вообще никаких нет… Впрочем, и опыта коммерческой разработки пока — тоже никакой… Так что объективным я тут вряд ли могу быть.
С другой стороны… Grails (не так давно приобретенный не менее известной SpringSource, что тоже кое о чем говорит) используют такие «гиганты», как Sky.com (для их основного и дополнительных сайтов) и LinkedIn (внутренние intranet-решения).
А ваш опыт («жуткие тормоза») основан на чем? Коммерческая разработка или так, на локальной машине «поигрались»?
С другой стороны… Grails (не так давно приобретенный не менее известной SpringSource, что тоже кое о чем говорит) используют такие «гиганты», как Sky.com (для их основного и дополнительных сайтов) и LinkedIn (внутренние intranet-решения).
А ваш опыт («жуткие тормоза») основан на чем? Коммерческая разработка или так, на локальной машине «поигрались»?
>Почему не ASP.NET, Ruby on Rails, Grails и т.п.?
Ну и список. ASP.NET — технология, Grails и RoR — фреймворки.
Ох уж эти питонисты — стоит им освоить __init__(self), как они начинают менторским тоном рассуждать о всём на свете.
>Ниже я кратко опишу свое мнение, и причины, его сформировавшие.
Ни мнения, ни причин в посте нет. Только список из 6-ти фич, каждая из которых есть в том же Ruby on Rails.
Ну и список. ASP.NET — технология, Grails и RoR — фреймворки.
Ох уж эти питонисты — стоит им освоить __init__(self), как они начинают менторским тоном рассуждать о всём на свете.
>Ниже я кратко опишу свое мнение, и причины, его сформировавшие.
Ни мнения, ни причин в посте нет. Только список из 6-ти фич, каждая из которых есть в том же Ruby on Rails.
Кстати, Django выкатили в 2005 году, а RoR — в июле 2004-го. Как говорится, понятно, кто по чьим следам двигался.
Вобщем, единственную причину выбора Django — «так получилось» — оп так и не озвучил.
Вобщем, единственную причину выбора Django — «так получилось» — оп так и не озвучил.
Ну первый публичный релиз в 2005м — это 8825й внутренний коммит. А делать django начали в 2003. В январе 2004го уже 1000+ коммитов было, по крайней мере. В августе 2004 — 4000+ коммитов. После этого влияние RoR, конечно, было. RoR вообще положительно повлиял на всю веб-разработку. Но насчет следов обольщаться не стоит)
В качестве затравки на очередной холивар: сейчас вот наоборот говорят, что RoR в сторону Django движется)
В качестве затравки на очередной холивар: сейчас вот наоборот говорят, что RoR в сторону Django движется)
Обычно RoR сравнивают с Pylons.
Можете ещё дату релиза питона и руби сравнивать В)
Можете ещё дату релиза питона и руби сравнивать В)
дажнга очень не похожа на RoR.
Каждая из этих 6 фич есть практически в любом фреймворке) Пост ни о чем, это правда.
гм… а чем же «технология» от «фреймворка» отличается?
я бы не сказал что разница сильно критична.
как ASP.NET — набор библиотек и утилит работающий поверх языка
так и пайтоновые фреймворки.
я бы не сказал что разница сильно критична.
как ASP.NET — набор библиотек и утилит работающий поверх языка
так и пайтоновые фреймворки.
Комментарии вышли гораздо более интересными и содержательными, чем заметка :) Побольше бы таких обсуждений
в споре рождается истина ;)
К сожалению, очень часто спор на подобные темы переходит в холивар, но здесь этого пока не произошло :) Отличный вышел тред, надо будет периодически перечитывать на досуге.
А вообще, читаешь комментарии и понимаешь как же много на хабре людей, которые действительно _разбираются_ в этой (и не только) теме. Почему же так мало статей об этом? ) Огромная просьба — делитесь своим опытом :)
А вообще, читаешь комментарии и понимаешь как же много на хабре людей, которые действительно _разбираются_ в этой (и не только) теме. Почему же так мало статей об этом? ) Огромная просьба — делитесь своим опытом :)
Угу, а также понимаешь, сколько же людей разбираться не разбираются, но слово своё сказать скажут.
Ведь и в самом деле мало кто попробовал и то и другое и третье и имел возможность сравнить всё это под боевой нагрузкой. Это к вопросу о том почему мало статей. Просто описать свой опыт работы с чем-либо не интересно. Интереснее именно, что сравнить.
Ведь и в самом деле мало кто попробовал и то и другое и третье и имел возможность сравнить всё это под боевой нагрузкой. Это к вопросу о том почему мало статей. Просто описать свой опыт работы с чем-либо не интересно. Интереснее именно, что сравнить.
Мне в джанго не понравилось создание компонент для шаблонов, слишком надумано. А без простого компонентного подхода я не представляю как делать легко понимаемые шаблоны страниц.
А в целом, есть еще куча работы по улучшению скорости и качества разработки веб-проектов. Отчасти Merb+RoR или Grails начинают делать шаги в этом направлении.
В джанго я таких шагов не видел — здесь всё еще живут в 2006 — бума RoR и блогов за 15 минут.
А в целом, есть еще куча работы по улучшению скорости и качества разработки веб-проектов. Отчасти Merb+RoR или Grails начинают делать шаги в этом направлении.
В джанго я таких шагов не видел — здесь всё еще живут в 2006 — бума RoR и блогов за 15 минут.
А расскажите поподробней — какие шаги вы имеете ввиду?
Из основных:
— автоматическое подключение плагинов
— автоматизированное средство для контроля зависимостей (подключаемых библиотек)
— каталог плагинов различных уровней (вплоть до всяких cms) и сообщество вокруг него (на сайте разработчика)
— автоматическое подключение плагинов
— автоматизированное средство для контроля зависимостей (подключаемых библиотек)
— каталог плагинов различных уровней (вплоть до всяких cms) и сообщество вокруг него (на сайте разработчика)
Не совсем понятно что имееться в виду под плагинами. в джанге есть www.djangosnippets.org/ это мини-плагины (наверное), есть 3rd-party компоненты и другое code.djangoproject.com/wiki/DjangoResources (прямо «на сайте разработчика»), на битбакете, гитхабе и гуглокоде можно найти тысячи приложений (плагинов) для джанги.
Автоматическое подключение плагинов это что? Возможность воткнуть плагин в рантайме? Неясно что вы имеете в виду, в общем.
Сообщество вокруг джанги довольно обширное.
Автоматическое подключение плагинов это что? Возможность воткнуть плагин в рантайме? Неясно что вы имеете в виду, в общем.
Сообщество вокруг джанги довольно обширное.
Автоматическое подключение плагинов это:
grails install-plugin app-engine
grails app-engine run
или так «grails install-plugin ibatis», когда нужно заменить ORM
Плюс я еще не затронул тему, что к каждому плагину можно написать доп. команды, типа «grails create-gateway com.example.Account», который сгенерирует нужные шаблоны для плагина ibatis.
Т.е. что я хочу сказать, в Grails и Merb существует новый уровень для подключения 3rd-party библиотек. В Django такого не видел.
А на сайте разработчика это имелось ввиду так: www.grails.org/plugin/home, а не какой-то странный каталог ссылок, в котором даже поиска нет.
grails install-plugin app-engine
grails app-engine run
или так «grails install-plugin ibatis», когда нужно заменить ORM
Плюс я еще не затронул тему, что к каждому плагину можно написать доп. команды, типа «grails create-gateway com.example.Account», который сгенерирует нужные шаблоны для плагина ibatis.
Т.е. что я хочу сказать, в Grails и Merb существует новый уровень для подключения 3rd-party библиотек. В Django такого не видел.
А на сайте разработчика это имелось ввиду так: www.grails.org/plugin/home, а не какой-то странный каталог ссылок, в котором даже поиска нет.
Ах, да, я еще забыл упомянуть тему quickstart'ов в — это когда можно сделать так mvn generate:archetype и выбрать стартовый шаблон для начала нового проекта. В том числе можно создать собственные.
Если я правильно понял, то в Django без проблем можно написать свою команду для start-project.py, которая будет создава стартовый шаблон.
Джанго-проект по умолчанию минималистичен и ничего не умеет.
Если нужны какие-то крупные заготовки, именно то, что Вы пишете, есть в Pinax — выбираешь стартовый шаблон для нового проекта и поехали.
А свои стартовые шаблоны может задавать какая-то management-команда из django-extensions.
Да и написать все это — занятие элементарное.
Несмотря на наличие готовых решений, не думаю, что оно того вообще стоит. Вот как часто приходится новый проект начинать?) Взял да скопировал, если нужно.
Если нужны какие-то крупные заготовки, именно то, что Вы пишете, есть в Pinax — выбираешь стартовый шаблон для нового проекта и поехали.
А свои стартовые шаблоны может задавать какая-то management-команда из django-extensions.
Да и написать все это — занятие элементарное.
Несмотря на наличие готовых решений, не думаю, что оно того вообще стоит. Вот как часто приходится новый проект начинать?) Взял да скопировал, если нужно.
То есть вы не можете сформулировать что такое плагин? :) Будем считать тогда, что плагины это аналог приложений в джанге. Их там тоже прос то ставить, да и доп. команды писать можно вполне.
Насчет списка плагинов — это не минус джанги, что их на сайте разработчиков нет. Дело в том, что если бы они там появились, разработчики джанги по умлочанию взяли бы на себя отвестственность за их работоспособность, баги, настройку и прочее. Так принято в джанге. Поэтому они их там и не держат. Это просто другой подход и всё.
Насчет списка плагинов — это не минус джанги, что их на сайте разработчиков нет. Дело в том, что если бы они там появились, разработчики джанги по умлочанию взяли бы на себя отвестственность за их работоспособность, баги, настройку и прочее. Так принято в джанге. Поэтому они их там и не держат. Это просто другой подход и всё.
> Да и централизованного сайта с django-приложениями нету
Я написал, почему этого нет для джанги. Чтобы это было, надо собрать всех разработчиков сторонних компонентов в одном месте. Я больше чем уверен, что многие плагины в том репозитории для грельсов либо совсем мёртвые, либо не поддерживаються почти. Так не принято в нашем идеальном джанго-мирке :-D
Я написал, почему этого нет для джанги. Чтобы это было, надо собрать всех разработчиков сторонних компонентов в одном месте. Я больше чем уверен, что многие плагины в том репозитории для грельсов либо совсем мёртвые, либо не поддерживаються почти. Так не принято в нашем идеальном джанго-мирке :-D
> Неоднократно видел заброшенные django-application на google-code. Да у меня самого лежит несколько opensource приложений на битбакете на которые я немного забил, хаха :) Так что джанго-мирок, я думаю, такой же как и везде:
Вот именно поэтому я и написал, что так не принято в джанго-мире. И имел в виду именно разработчиков — поэтому они и не держат на сайте списков плагинов и прочего, потому что не хотят брать на себя эту ответственность.
> Неа, не нужно. Нужен человек, который бы мониторил битбакет, pypi, git, находил бы новые приложения, удалял бы старые, в общем нужна человеческая поддержка сайта. А сам сайт бы представлял из себя описания пакетов, ссылки на их домашние странички.
Это полностью подтверждает мои слова =) Нужен лишь человек, который бла-бла-бла. Уверен я, что нужен не один а пяток человек. А это уже большая проблема. Во всяком случае, битбакет почти справляется с этой функцией социальными путями. И это хорошо.
Вот именно поэтому я и написал, что так не принято в джанго-мире. И имел в виду именно разработчиков — поэтому они и не держат на сайте списков плагинов и прочего, потому что не хотят брать на себя эту ответственность.
> Неа, не нужно. Нужен человек, который бы мониторил битбакет, pypi, git, находил бы новые приложения, удалял бы старые, в общем нужна человеческая поддержка сайта. А сам сайт бы представлял из себя описания пакетов, ссылки на их домашние странички.
Это полностью подтверждает мои слова =) Нужен лишь человек, который бла-бла-бла. Уверен я, что нужен не один а пяток человек. А это уже большая проблема. Во всяком случае, битбакет почти справляется с этой функцией социальными путями. И это хорошо.
Какие-то совершенно надуманные проблемы. Установка django-приложений совсем не сложная, места их поиска разведаны, вплоть до cms все есть, зависимости простейшие, пишешь все в requirements-файл для pip'a и готово.
Да, может быть, вам удобно все делать вручную. А мне нужно, чтобы когда я обновился из репозитория и запустил сервер типа mvn jetty:run у меня всё сразу заработало (обновилось, докачалось, доставилось). В Django, когда я забирал из репозитория и делал ./manage.py runserver у меня иногда вылетала всякая херь и не запскалось. Приходилось лезть в менеджер пакетов, искать и ставить всё вручную.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Причины выбора Django для разработки сайта