Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 163
Довольно интересно.
Надоело писать свой django-велосипед под простейший сайт. А использовать решения на PHP типа Drupal — уже не хочется.
Качаю, буду пробовать.
Надоело писать свой django-велосипед под простейший сайт. А использовать решения на PHP типа Drupal — уже не хочется.
Качаю, буду пробовать.
Надо будет попробывать.
Спасибо. Недавно увлёкся Jango, будет интересно посмотреть на этого зверя)
А есть какие-то инструменты чтобы это на венде потестить?
Ну… Думаю, и Апач, и Питон, Джанго можно запросто поставить на Винду.
Другое дело, что лично я никогда этого не делал :)
Другое дело, что лично я никогда этого не делал :)
Достаточно поставить сам Питон (скачать/устанвить), БД (см. список поддерживаемых) и питоновский коннектор к данной БД (для MySQL нужны небольшие танцы, например).
а что у вас за танцы были-то? никогда проблем не было
Позавчера ставил Python 2.6 + python-mysql для него. Никаких проблем.
bitnami.org/stack/djangostack
На здоровье!
На здоровье!
Если хочется локального web сервера не заморачиваясь, то я пользуюсь иногда DENWER — Джентльменский Набор Web-Разработчика
Базовый пакет:
— Apache2 + SSL
— PHP5
— MySQL5
— phpMyAdmin
Может работать с флешки.
Базовый пакет:
— Apache2 + SSL
— PHP5
— MySQL5
— phpMyAdmin
Может работать с флешки.
Пакеты расширений:
* PHP 5: дополнительные модули
* PostgreSQL 8.2 + модули PHP
* Денвер + Parser в одном пакете
* PHP 4: полный дистрибутив
* ActivePerl 5.8
* ActivePython 2.5
* Parser 3 с поддержкой XML, SQL и эмулятором SMTP-сервера
* Apache 2.2: дополнительные модули
* PHP 3: полный дистрибутив
* FireBird 2 + модули PHP
* MySQL 5: дополнительные модули и утилиты
* MySQL 4: предыдущая версия
* PHP 5: дополнительные модули
* PostgreSQL 8.2 + модули PHP
* Денвер + Parser в одном пакете
* PHP 4: полный дистрибутив
* ActivePerl 5.8
* ActivePython 2.5
* Parser 3 с поддержкой XML, SQL и эмулятором SMTP-сервера
* Apache 2.2: дополнительные модули
* PHP 3: полный дистрибутив
* FireBird 2 + модули PHP
* MySQL 5: дополнительные модули и утилиты
* MySQL 4: предыдущая версия
Хотябы пару скриншотиков самых интересных мест цмски бы дали.
Они там есть, я уверен :)
Если серьезно то DjangoCMS вещь стоящая, сами юзали. Были некоторые проблемки но совсем незначительные, по моему с обновлением моделей при обнослении версии, а так летает замечательно.
Они там есть, я уверен :)
Если серьезно то DjangoCMS вещь стоящая, сами юзали. Были некоторые проблемки но совсем незначительные, по моему с обновлением моделей при обнослении версии, а так летает замечательно.
А вас не смущает такое изобилие запросов к БД?
А так я рад что DjangoCMS засветился на хабре, давно за ним слежу…
А так я рад что DjangoCMS засветился на хабре, давно за ним слежу…
всмысле в самой CMS? Да не очень в принципе.
До этого стояло что то PHPшное, кажется симфони — там было побольше, на порядок.
До этого стояло что то PHPшное, кажется симфони — там было побольше, на порядок.
сам django-cms не использовал, но один раз помогал отладить сайт на ней. Выдавала она огромную кучу запросов на страницу. Для каждой i18n-строчки текста делалось около 50 запросов — по числу локалей в джанге. Быстрое ковыряние исходников показало, что причина — настройки LANGUAGE_CODE и LANGUAGES в settings.py, а точнее — их отсутствие. После добавления этих настроек все стало более-менее ок. Баг репорт не оформлял, может это фича такая, а может в версии 2.0 ее уже и нет, но если что, имейте в виду.
все для народа ;) Любуемся!
О-хо-хо… А что вас интересует? :-D
Что значит «забежал»? :) Я в этом блоге живу практически! :)
Отступы… Отступы… А надо нормальный редактор использовать, и не будет проблем с отступами :-P
Отступы… Отступы… А надо нормальный редактор использовать, и не будет проблем с отступами :-P
Автор — я, если вы не обратили внимание, можно лично вопрос задавать.
Вот лично мое чувство прекрасного от вида языка пэхэпэ. Вот с++ терплю, си люблю, Джава и Перл уважаю.
С — почти ассемблер
C++ — это типа Си плюс сверху объектность и чудная STL.
Java — аккуратный C++ со сборщиком мусора, беспроблемной кроссплатформенностью и без сишных архаизмов
Perl — жуткий синтаксис, но зато regex и oneliners
Но ПэХэПэ… Ух. Вроде как шаблонизатор встроенный, да. Но вроде как сейчас это уже не актуально, в эпоху-то mvc и отделения логики от представления. А что остается? уродский синтаксис да слеши в импорте модулей?
Вот лично мое чувство прекрасного от вида языка пэхэпэ. Вот с++ терплю, си люблю, Джава и Перл уважаю.
С — почти ассемблер
C++ — это типа Си плюс сверху объектность и чудная STL.
Java — аккуратный C++ со сборщиком мусора, беспроблемной кроссплатформенностью и без сишных архаизмов
Perl — жуткий синтаксис, но зато regex и oneliners
Но ПэХэПэ… Ух. Вроде как шаблонизатор встроенный, да. Но вроде как сейчас это уже не актуально, в эпоху-то mvc и отделения логики от представления. А что остается? уродский синтаксис да слеши в импорте модулей?
А если по существу?
Вы смотрели нормальные PHP фреймворки, а не убогие CMS?
Вы смотрели нормальные PHP фреймворки, а не убогие CMS?
Что есть «нормальные PHP фреймворки»? CodeIgniter и Symfony подойдут?
Так это и есть «существо».
Веб-фреймворки красивые сейчас есть у всех: у Руби, у Питона, на Php (да, я смотрел CodeIgniter, Zend и CakePhp). В этом смысле — все равно, они общую модель используют. Тут дело именно в языке, его выразительности, комфортности, удобоваримости.
Кроме того, выучил Питон — пишешь что угодно. Веб (с Django, Turbogears или еще чем-нить), игрушки (pygame и родственники), сетевые приложения (смотреть и радоваться Twisted), скриптование приложений (типа 3d-рисовалок blender или houdini), собирать С/C++ проекты (scons), писать интерфейсы (PyQt, PyGTK, WxWidgets). В общем, ВСЕ.
И везде преследуют удобство, легкость и простота.
Пусть бросит в меня камень тот, кто все это получит в php!
Веб-фреймворки красивые сейчас есть у всех: у Руби, у Питона, на Php (да, я смотрел CodeIgniter, Zend и CakePhp). В этом смысле — все равно, они общую модель используют. Тут дело именно в языке, его выразительности, комфортности, удобоваримости.
Кроме того, выучил Питон — пишешь что угодно. Веб (с Django, Turbogears или еще чем-нить), игрушки (pygame и родственники), сетевые приложения (смотреть и радоваться Twisted), скриптование приложений (типа 3d-рисовалок blender или houdini), собирать С/C++ проекты (scons), писать интерфейсы (PyQt, PyGTK, WxWidgets). В общем, ВСЕ.
И везде преследуют удобство, легкость и простота.
Пусть бросит в меня камень тот, кто все это получит в php!
Да сложно сказать.
Руби — типа двоюродный брат Питона, но с более развитой системой метапрограммирования и не такой строгой процедурой принятия фишек в ядро языка.
Я в свое время выбрал все же питон, потому как у него:
1) библиотек больше, они старше;
2) стабильный синтаксис;
3) очень жестко отбираются фишки под включение в язык;
4) в те времена интерпретатор Руби был в полтора раза медленней;
5) интерпретатор по умолчанию включен в поставку среднего линукса;
5) мне не нравится писать endif в конце блока :)
Руби — типа двоюродный брат Питона, но с более развитой системой метапрограммирования и не такой строгой процедурой принятия фишек в ядро языка.
Я в свое время выбрал все же питон, потому как у него:
1) библиотек больше, они старше;
2) стабильный синтаксис;
3) очень жестко отбираются фишки под включение в язык;
4) в те времена интерпретатор Руби был в полтора раза медленней;
5) интерпретатор по умолчанию включен в поставку среднего линукса;
5) мне не нравится писать endif в конце блока :)
Всетаки понятие «красоты синтаксиса языка программирования» — очень субъективная вещь =)
Прочитал ваш переченеь склонивших в сторону выбора Питона причин и попытался востановить аналогичный для Руби, когда сделал выбор в его сторону в аналогичной ситуации. Сейчас понимаю, что решающими были всего две:
1) Нестабильный синтаксис (по аналогии с вашим вторым пунктом, то есть нет столь жесткого навязывания форматирования кода на уровне самого языка и возможность довольно легкого переопределения даже базовых операторов).
2) При работе со сроками, как с индексированым массивом, возможно его прямая модификация (если есть text=«Тексты», то в Руби жизнеспособно text[-1]=«у» и значение text станет «Тексту», а в Питоне нет).
Сейчас использую с определенной периодичностью оба языка (решаюшим оказывается наличие готовых решений на том, или другом позволяющее наиболее быстро решить поставленную задачу). И понимаю наивность вышеобозначенных выводов =) Особенно с учетом того, что программирование для меня не является моим прямым профелем (я арт-директор), скорее определенный уровень знаний на этой ниве — следствие стремления не делать обезъяньей работы (первым был скриптик пакетной обаработки изображений, потом скрипты для гимпа и блендера, а дальше больше). Но при прочих равных все равно выбираю Руби. Наверное потому что первый (освоенный по собственному желанию, а не как Cи++, Pascal, Basic в ходе обучения в школьные и студенческие годы «из под палки»)…
«Кстати, на твой вкус — руби или питон?» — у меня лично вызывает улыбку, даже не над самим вопросом, а скорее от настольгии котую он у меня вызывает. И отвечаю обычно: «тот который нравится».
Прочитал ваш переченеь склонивших в сторону выбора Питона причин и попытался востановить аналогичный для Руби, когда сделал выбор в его сторону в аналогичной ситуации. Сейчас понимаю, что решающими были всего две:
1) Нестабильный синтаксис (по аналогии с вашим вторым пунктом, то есть нет столь жесткого навязывания форматирования кода на уровне самого языка и возможность довольно легкого переопределения даже базовых операторов).
2) При работе со сроками, как с индексированым массивом, возможно его прямая модификация (если есть text=«Тексты», то в Руби жизнеспособно text[-1]=«у» и значение text станет «Тексту», а в Питоне нет).
Сейчас использую с определенной периодичностью оба языка (решаюшим оказывается наличие готовых решений на том, или другом позволяющее наиболее быстро решить поставленную задачу). И понимаю наивность вышеобозначенных выводов =) Особенно с учетом того, что программирование для меня не является моим прямым профелем (я арт-директор), скорее определенный уровень знаний на этой ниве — следствие стремления не делать обезъяньей работы (первым был скриптик пакетной обаработки изображений, потом скрипты для гимпа и блендера, а дальше больше). Но при прочих равных все равно выбираю Руби. Наверное потому что первый (освоенный по собственному желанию, а не как Cи++, Pascal, Basic в ходе обучения в школьные и студенческие годы «из под палки»)…
«Кстати, на твой вкус — руби или питон?» — у меня лично вызывает улыбку, даже не над самим вопросом, а скорее от настольгии котую он у меня вызывает. И отвечаю обычно: «тот который нравится».
Еще больше улыбает то, что вопрос был задан человеку, пишущему в блоги Python/Django :)
Однако, согласитесь, Питон из-за своей предсказуемости на уровне интуиции воспринимается существенно легче; незнакомые решения и либы читаются быстрее даже человеком, слабо знакомым с языком.
Примеры же усложения из мира Руби, думаю, назвать сможете вы и без моих подсказок.
Однако, согласитесь, Питон из-за своей предсказуемости на уровне интуиции воспринимается существенно легче; незнакомые решения и либы читаются быстрее даже человеком, слабо знакомым с языком.
Примеры же усложения из мира Руби, думаю, назвать сможете вы и без моих подсказок.
Я бы советовал все же начать с Питона, если у вас нет большого профессионального опыта программирования на каком либо другом языке. Причина проста — Питон более строг, он «воспитывает» программиста, приучая его к принципам необходимым любому проффессионалу в этой области. И если вы дорастете до такого уровня, что «воспитание» будет вам мешать, вы с легкостью перейдете на «очень вольный» Руби, причем эта его «вольность» станет для вас преимуществом, а не как в любом другом случае недостатком. Причем перход фактически будет обусловлен изучением даже не самого языка а ифроструктуры вокруг него (фреймворки, библиотеки, готовые решения и прочее). По близкой мне аналогии, любой школьник от скуки закрашивал хоть раз на уроке клеточки ручкой, но Малевич посвятив пол жизни изучения классичекой хубожественной школе и уже после перейдя к привитивизму и кубизму написал «Черный квадрат», будоражущий до сих пор умы современников, не подходом и техникой, а самой идеей.
Соглашусь, более того, много проще воспринимается не только малознакомым с языком, но и не знакомым вообще с Питоном вообще, а лишь с поверхностно с каким то другим и с английским языком. Но эта его жесткая диктующая позиция, являющаяся безусловным плюсом в большинстве случаев является большим ограничением, когда речь идет о нетривиальном проекте, котороый решает уже состоявшийся программист высокого уровня (он уже знает как грамотно оптимизировать код, как его лучшим образом форматировать, причем в каждом отдельном случае а не «в общем» и навязывание лишь препятсвует его работе). И вот именно в этой нише отличительная черта Руби и проявляется как достоинство, а не недостаток. И именно поэтому я с различной периодичность «прыгаю» с одного языка на другой, именно исходя из задачи, а не личных предпочтений — такой подход, по крайней мере для меня, оказался боле продуктивным. А для задач математики, аналитики или преобразования и форматирования текста вообще все больше использую Javascript так как интерпритатор есть повсеместно и не требует инсталяции, а концепция языка, хоть изначально и не скажешь более всего близка к Perl, и в какой то степени его последователю Ruby.
А уверены, что в вашем нетривиальном случае надо использовать всякие хитрые ужимки? Не будет ли это «подарочком» для программиста, который придет после вас?
Обратите внимание на корпоративные руководства или официальные стили кода.
Правило номер 1: не выдумывайте, не извращайтесь, не запутывайте код.
Текст программы должен быть предсказуем. Функции остаются функциями, обычные операторы — операторами, классы — классами, а цыпленок — цыпленком.
На примере C++ могу указать на фишки в стиле Александреску, которые чаще просто запрещено использовать.
Код моих знакомых высококлассных программистов отличается не уникальными решениями, а:
1) читаемостью,
2) лаконичностью,
3) простотой,
4) архитектурной стройностью.
Обратите внимание на корпоративные руководства или официальные стили кода.
Правило номер 1: не выдумывайте, не извращайтесь, не запутывайте код.
Текст программы должен быть предсказуем. Функции остаются функциями, обычные операторы — операторами, классы — классами, а цыпленок — цыпленком.
На примере C++ могу указать на фишки в стиле Александреску, которые чаще просто запрещено использовать.
Код моих знакомых высококлассных программистов отличается не уникальными решениями, а:
1) читаемостью,
2) лаконичностью,
3) простотой,
4) архитектурной стройностью.
О том я и гвоорю =) Профессионал, тот кто точно знает меру своей осведомленности и работает только в ее рамках. Это в первую очередь подразумевает большой практический опыт. Перечисленные качества кода ваших знакомых это следствия, к которому они пришли «набив шишки» при получении этого опыта. Они уже без указок со стороны знают, как сделать решение более читаемым, лаконичным, простым и маштабируемым. Причем в каждом конкретном, отдельно взятом, случае, а не в общем. Они не будут тупо следовать шаблонам, и не станут разбивать на блоки, то что более понятно будучи записаным в одну строку, так как они уже знают где упрощение, а где недосказанность. Они, при необходимости, для какой либо предметной области создадут и используют DSL, сводящая фактически код программы к записи на английском языке или матиматической нотации, понятной даже не программисту. Их опыт это в первую очередь знание и умение использовать себе на пользу специфики.
Жесткая регламентация способствует конвееру, благодаря тому что таковая заложена в концепцию Питона, результат работы средних и даже откровенно слабых специалистов приносит максимальную эффективность для этого конвеера. Поэтому высококлассные специалисты в первую очередь, работая в рамках конвеера, придерживаются регламента и всячески его пропогандируют.
Рабочий собирающий фары не должен знать куда они будут ставится и даже не обязан понимать принцип их работы, но инженер разрабатывающий автомобиль долже знать, и не только это, но и многое другое. У любого правила есть исключения, это аксиома. Строгое следование правилу дает большую отдачу, но не работает в исключительных ситуациях в принципе. Вот Руби как раз и позволяет доробатывать эти исключения, за счет того, что следование общему правилу остается на совести разработчика, а следовать он ему будет лишь будучи профессионалом. По этой причине, на мой взгляд, Руби как и Перл будет оставаться нишевым продуктом. Для эксперементов и программирования возведенного в рамки исскуства. В массовое производство ему дорога закрыта, только для интузиастов и более удобной реализации творческой составляющей профессионалов. Однако это не относится к продуктам на его основе, как пример Рельсы, в полне себе конвеер, знания языка для его использования минимальны. Потому и так популярен, да настолько, что ранее многие начинающие вообще считали, что Руби и Рельсы синонимы.
Как то так. Немного в философию ударился, есть грешок. Но думаю мысль ясна =)
Жесткая регламентация способствует конвееру, благодаря тому что таковая заложена в концепцию Питона, результат работы средних и даже откровенно слабых специалистов приносит максимальную эффективность для этого конвеера. Поэтому высококлассные специалисты в первую очередь, работая в рамках конвеера, придерживаются регламента и всячески его пропогандируют.
Рабочий собирающий фары не должен знать куда они будут ставится и даже не обязан понимать принцип их работы, но инженер разрабатывающий автомобиль долже знать, и не только это, но и многое другое. У любого правила есть исключения, это аксиома. Строгое следование правилу дает большую отдачу, но не работает в исключительных ситуациях в принципе. Вот Руби как раз и позволяет доробатывать эти исключения, за счет того, что следование общему правилу остается на совести разработчика, а следовать он ему будет лишь будучи профессионалом. По этой причине, на мой взгляд, Руби как и Перл будет оставаться нишевым продуктом. Для эксперементов и программирования возведенного в рамки исскуства. В массовое производство ему дорога закрыта, только для интузиастов и более удобной реализации творческой составляющей профессионалов. Однако это не относится к продуктам на его основе, как пример Рельсы, в полне себе конвеер, знания языка для его использования минимальны. Потому и так популярен, да настолько, что ранее многие начинающие вообще считали, что Руби и Рельсы синонимы.
Как то так. Немного в философию ударился, есть грешок. Но думаю мысль ясна =)
Perl — нифига не нишевой продукт. Когда-то он был Главный Динамическим Языком, на котором делалось все: от однострочных скриптов до порталов.
Однако, синтаксические недостатки, сложность в освоении и поддерке сделали свое дело. И вот теперь он стал нишевым продуктом.
Подозреваю, что весь это hype вокруг RoR тоже сойдет на нет. И вот только после этого можно будет рассуждать, оказались ли специальные возможности языка излишеством или преимуществом.
Однако, синтаксические недостатки, сложность в освоении и поддерке сделали свое дело. И вот теперь он стал нишевым продуктом.
Подозреваю, что весь это hype вокруг RoR тоже сойдет на нет. И вот только после этого можно будет рассуждать, оказались ли специальные возможности языка излишеством или преимуществом.
Перл — нишевый продукт, но когда-то все было с точностью до наоборот.
Судьба Рельс и Руби уже сейчас идут паралельно, за исключением того что интерес к первому порождает большой приток людей интересующихся вторым.
У меня складывается стойкое впечатление, что я говорю сам с собой. Не втом смысле, что я не понят, а в том что схожий взгляд на вещи и ход рассуждений. =)
Судьба Рельс и Руби уже сейчас идут паралельно, за исключением того что интерес к первому порождает большой приток людей интересующихся вторым.
У меня складывается стойкое впечатление, что я говорю сам с собой. Не втом смысле, что я не понят, а в том что схожий взгляд на вещи и ход рассуждений. =)
В том то и дело, мб я один так считаю и Вы правы, но я считаю каждый должен заниматься своим, Py очень уважаю, но из-за идеологии чтоли не хочу тянуть их в Web, по мне так каждый должен заниматься своим, а PHP именно Web.
Про удобство кода — повторюсь, это дело привычки и опыта, если человек прекрасно пишет на PHP много лет и трудностей не испытывает — смысл ему из-за удобства переходить на другой язык?
Про удобство кода — повторюсь, это дело привычки и опыта, если человек прекрасно пишет на PHP много лет и трудностей не испытывает — смысл ему из-за удобства переходить на другой язык?
Это ведь тоже только мое мнение :)
Но я могу его обосновать.
Специализация — понятие относительное. Все идет к универсальности. Программистам не нравится изучать новый язык под каждую задачу. Именно поэтому Руби так силен своими Domain Specific Languages.
Опять же, специализация в этом случае ничего не дает, а только ограничивает. Повторюсь, и опять напишу, что фреймворки есть везде. Хорошие, плохие… На Перле, на Хаскелле, на Руби, на Питоне… Абсолютно везде они есть, и в этом смысле нет разницы, на чем писать.
Но какой-то язык прост, изящен и располагает к написанию понятного, чистого кода. Какой-то — обладает специфичными неинтуитивными особенностями, которые надо специально изучать.
Например, Перл. Правда, там ужасный синтаксис. Но зато в одну строчку можно сделать очень много.
В Php нет ничего нового или особенного, только некрасивый, избыточный синтаксис. При всех прочих равных условиях язык проигрывает.
Именно поэтому даже люди, много лет пишущие на php, часто поглядывают в сторону знаменитой изящности Питона или DSL в Ruby.
Но я могу его обосновать.
Специализация — понятие относительное. Все идет к универсальности. Программистам не нравится изучать новый язык под каждую задачу. Именно поэтому Руби так силен своими Domain Specific Languages.
Опять же, специализация в этом случае ничего не дает, а только ограничивает. Повторюсь, и опять напишу, что фреймворки есть везде. Хорошие, плохие… На Перле, на Хаскелле, на Руби, на Питоне… Абсолютно везде они есть, и в этом смысле нет разницы, на чем писать.
Но какой-то язык прост, изящен и располагает к написанию понятного, чистого кода. Какой-то — обладает специфичными неинтуитивными особенностями, которые надо специально изучать.
Например, Перл. Правда, там ужасный синтаксис. Но зато в одну строчку можно сделать очень много.
В Php нет ничего нового или особенного, только некрасивый, избыточный синтаксис. При всех прочих равных условиях язык проигрывает.
Именно поэтому даже люди, много лет пишущие на php, часто поглядывают в сторону знаменитой изящности Питона или DSL в Ruby.
Убедили =( Как не прискорбно осознавать =(
Будем пробовать. Пока студент. Пока время есть…
Будем пробовать. Пока студент. Пока время есть…
> В Php нет ничего нового или особенного, только некрасивый, избыточный синтаксис.
Обычно так ворчат люди, которые писали на PHP3(ну или те, которые используют PHP5, но пишут также как писали бы на PHP3):-)
Вообще Python много больше умеет по сравнению с PHP(например, множественное наследование, которого у PHP еще долго не будет), однако Python гораздо старше PHP. «Нормальная»(думаю вы поняли почему в кавычках:-)) ООП версия — PHP5 вышла примерно в 2004-2005 ), а Python в 1991 уже позиционировался, как ООП язык программирования. Поэтому логично, что разработчики «на» PHP смотрят в сторону более «умных» языков, но насчет синтаксиса, оформления кода — здесь на мой взгляд у Pythona дела обстоят гораздо хуже. Сравните, например, спецификаторы доступа: в Python это подчеркивания, а в PHP — ключевые слова. Какой код по вашему будет читать лучше? По моему мнению, гораздо лучше читать слова, а не считать подчеркивания.
Все… навеяло… пойду писать статью о сравнении синтаксиса PHP и Python :-)
Обычно так ворчат люди, которые писали на PHP3(ну или те, которые используют PHP5, но пишут также как писали бы на PHP3):-)
Вообще Python много больше умеет по сравнению с PHP(например, множественное наследование, которого у PHP еще долго не будет), однако Python гораздо старше PHP. «Нормальная»(думаю вы поняли почему в кавычках:-)) ООП версия — PHP5 вышла примерно в 2004-2005 ), а Python в 1991 уже позиционировался, как ООП язык программирования. Поэтому логично, что разработчики «на» PHP смотрят в сторону более «умных» языков, но насчет синтаксиса, оформления кода — здесь на мой взгляд у Pythona дела обстоят гораздо хуже. Сравните, например, спецификаторы доступа: в Python это подчеркивания, а в PHP — ключевые слова. Какой код по вашему будет читать лучше? По моему мнению, гораздо лучше читать слова, а не считать подчеркивания.
Все… навеяло… пойду писать статью о сравнении синтаксиса PHP и Python :-)
Вы смеетесь? Это я про спецификаторы доступа. Это вообще просто «джентельменское соглашение».
1) Питона в 91 году не было;
2) Питон с самого начала провозгласил своим кредо простоту и изящность;
3) уже к середине 90х он обрел современные очертания.
Так если php моложе, то он должен быть более современным. Так почему же получается, что он отстает?
1) Питона в 91 году не было;
2) Питон с самого начала провозгласил своим кредо простоту и изящность;
3) уже к середине 90х он обрел современные очертания.
Так если php моложе, то он должен быть более современным. Так почему же получается, что он отстает?
оп-па… Питон уже был. Пардон — деза.
Python изначально разрабатывался, как универсальный язык программирования, и поэтому у него значительно больше преимуществ. В отличие от PHP, который был разработан с целью «учета посетителей», однако именно это он делает лучше всех:-) А из-за простоты и понятности многим людям, в отличие от Python, в котором надо еще и философию знать:-), на PHP пересели множество быдлокодеров и из-за этого язык PHP ассоциируется у многих с отставанием мозга в развитии :-)
Что касается подчеркиваний, я почему-то очень верю, что вы, как и многие другие, используете это «джентельменское соглашение»:-) Вот, кстати еще один пример, исключения у нас бросают(кидают) и ловят как PHP(throw и catch), а не поднимают и исключают как в Python(raise и except). Конечно у Python с обработкой исключений лучше, чем у PHP, но код наглядней на PHP.
Что касается подчеркиваний, я почему-то очень верю, что вы, как и многие другие, используете это «джентельменское соглашение»:-) Вот, кстати еще один пример, исключения у нас бросают(кидают) и ловят как PHP(throw и catch), а не поднимают и исключают как в Python(raise и except). Конечно у Python с обработкой исключений лучше, чем у PHP, но код наглядней на PHP.
У ПХП есть одна особенность, выделяющая его на фоне других. Это повсеместная распростаненность на хостингах. Питон и Руби в этом отношении, в данный момент, в данной нише в роли догоняющих.
По своему опыту скажу — стоит. Мне было удобно на php, трудностей не испытывал, потом решил попробовать питон (спасибо кризису за свободное временя) — и с тех пор считаю те 4 года, что уделил php, практически бесполезной тратой времени. Как, кстати, и 4х-летнее усиленное разбирательство с тонкостями C++. Даже немного жалко потраченного на это все времени, ввиду крайне малой области разумного применения C++ и того, что (на мой нынешний вкус) php проигрывает python'у абсолютно во всем (синтаксис, библиотеки, коммьюнити, фреймворки, документация), ну нет у php преимуществ кроме сомнительного mod_php, который позволяет запустить все новичку почти без настройки (угу, а потом писать статьи о глобальной проблеме веб-разработки — ИНКЛУДЫ тормозят — а какого черта каждый раз при каждом запросе все вообще инклудится-то и с диска читается?).
Кроме того, может, это какая-то моя личная особенность, но, как сейчас вижу, меня разработка на php сначала приучала к каким-то корявым велосипедам. Потом наступала реакция в виде архитектурной астронавтики, как попытка от этой корявости уйти. Что, в итоге, было ничем не лучше. И причем, что самое неприятное, я был вполне доволен собой (и считал себя отличным программистом), когда писал отстойнейший код, который было невозможно поддерживать.
Кроме того, может, это какая-то моя личная особенность, но, как сейчас вижу, меня разработка на php сначала приучала к каким-то корявым велосипедам. Потом наступала реакция в виде архитектурной астронавтики, как попытка от этой корявости уйти. Что, в итоге, было ничем не лучше. И причем, что самое неприятное, я был вполне доволен собой (и считал себя отличным программистом), когда писал отстойнейший код, который было невозможно поддерживать.
> когда писал отстойнейший код, который было невозможно поддерживать.
Вы действительно считаете, что в этом виноват PHP? :-)
Вы действительно считаете, что в этом виноват PHP? :-)
php проигрывает python'у абсолютно во всем (синтаксис, библиотеки, коммьюнити, фреймворки, документация), ну нет у php преимуществ кроме сомнительного mod_php,
Хотя эти вещи напрямую не относятся к преимуществу языка и технологии, но утверждение спорное насчёт коммьюнити и документация.
Если документация, имеется ввиду, официальная, то тут ничего не могу сказать, но если считать количество литературы и статей по PHP, относительно статей и книг по веб-разработке на PYTHON, то PHP тут, наверняка, в выигрыше.
Тоже самое и насчёт коммьюнити.
Я думаю, что «попсовость» PHP, а следовательно и наличие большего количества литературы и обширного коммьюнити — это то, что заставляет многих начинающих, и не только, веб-программистов закрыть глаза на некоторые недостатки PHP в плане синтаксиса, ооп итд итп
Количество книг и статей вовсе не говорит об их качестве.
Хотя эти вещи напрямую не относятся к преимуществу языка и технологии, но утверждение спорное насчёт коммьюнити и документация.
Скажем, субъективное. Коммьюнити и документация лучше «на мой вкус». Дальше объясню, почему на мой вкус это так.
Если документация, имеется ввиду, официальная, то тут ничего не могу сказать, но если считать количество литературы и статей по PHP, относительно статей и книг по веб-разработке на PYTHON, то PHP тут, наверняка, в выигрыше.
Тоже самое и насчёт коммьюнити.
Я думаю, что «попсовость» PHP, а следовательно и наличие большего количества литературы и обширного коммьюнити — это то, что заставляет многих начинающих, и не только, веб-программистов закрыть глаза на некоторые недостатки PHP в плане синтаксиса, ооп итд итп
Понимаете, размер коммьюнити в тыс. человек и количество книг в штуках перестает иметь значение, когда становится достаточным, переходит за некоторый уровень. В питоне этот уровень превзойден многократно уже давно, так что проблем с недостатком мест, где можно почитать, не испытывал.
А с php ситуация какая (по крайней мере, была, когда я им занимался) — книг и статей много, а умных и хороших мало. Очень много информации от новичков для новичков. И среди все это приходится продираться, чтоб отыскать действительно полезную информацию. Одни названия некоторых книг чего стоят (http://www.bhv.ru/books/book.php?id=326).
О коммьюнити и документации я говорю с точки зрения более-менее опытного программиста, который решил перейти в веб, а не с точки зрения новичка, который только начинает программировать. Для второго, наверное, php будет проще, информации по нему больше. А для первого проще и понятнее должен оказаться питон — прочитал какой-нибудь dive into python и в путь.
Насчет коммьюнити — мне в питоне нравится, что там люди часто действительно грамотные, и нет такого большого количества самоуверенных новичков, дающих глупые советы, как в случае с php. Если, например, непонятно что-то в документации к logging — можно написать в python-users, и есть неплохая вероятность, что тебе грамотно ответит именно тот человек, что писал этот модуль 7 лет назад.
А простые вопросы, для которых важно огромное коммьюнити с большим количеством свободного времени, решаются обычно — тадам! — чтением документации, с которой полный порядок.
Но, вообще, это все не в ту степь. В коммьюнити главное вовсе не ответы на вопросы, главное в коммьюнити — это библиотеки. И вот тут коммьюнити php значительно проигрывает коммьюнити python'а. Большинство ведет наколеночные разработки велосипедов, коммуникации затруднены, качество кода часто плохое, разработками принято делиться в формате — вот написал что-то, скачайте архив. Так и живут. Идем, например, на github. Запрос по языку «php» выдаст 9513 репозитория. Запрос по языку «Python» — 15532. И это при том, что абсолютный размер коммьюнити у питона в разы меньше.
А вот почему так просиходит — думаю, из-за того, что в чужом коде на питоне разбираться значительно приятнее, чем на php.
Как пример — в php-фреймфорке symfony сделали отличный debug toolbar. Один джангонавт это увидел и подумал: «О, отличная идея!» Появился репозитрий на github. Сейчас за ним следит пол-тыщи человек, многие шлют патчи и улучшения, кто-то сделал офигенный дизайн, и сейчас джанговский тулбар уже ничуть не уступает, а, скорее всего, и значительно превосходит тот, что есть в symfony.
Это будет завтра. Времена меняются. Если Гвидо будет продолжать в том же духе — то лет пять-десять безболезненного существования нам вполне обеспечено.
А сегодня… php-скриптом можно сыграть, конечно, и сайт, и портал, и все такое. Но даже если закрыть глаза на синтаксис, то останется море задач, которые он решать не умеет.
Система сборки проекта? Игрушечки? Системное скриптование? Апплеты для Гнома, КДЕ? Интерфейсы на Qt?
Зачем один посредственный язык для веба и один хороший — для всего остального? Лучше свести все к общему знаменателю и не париться.
А сегодня… php-скриптом можно сыграть, конечно, и сайт, и портал, и все такое. Но даже если закрыть глаза на синтаксис, то останется море задач, которые он решать не умеет.
Система сборки проекта? Игрушечки? Системное скриптование? Апплеты для Гнома, КДЕ? Интерфейсы на Qt?
Зачем один посредственный язык для веба и один хороший — для всего остального? Лучше свести все к общему знаменателю и не париться.
Сразу оговорюсь — я достаточно много писал на PHP; много работал на Java.
За что влюбляешься в Питон — это за то, что там есть очень много приятных и казалось бы незначительных мелочей, которые вместе очень сильно упрощают и разработку и поддержку кода.
Из того, что важно для меня: 95% всякого однотипного мусора в коде можно нормально выносить за счет всяких декораторов и использования функционального программирования; очень грамотно организована работа с коллекциями и различными композитными типами; на Питоне действительно можно писать компактный легкочитаемый код.
Всего после пары недель общения с Питоном (вкупе с Джангой) у меня полностью пропало желание писать еще хоть что-нибудь на PHP :)
За что влюбляешься в Питон — это за то, что там есть очень много приятных и казалось бы незначительных мелочей, которые вместе очень сильно упрощают и разработку и поддержку кода.
Из того, что важно для меня: 95% всякого однотипного мусора в коде можно нормально выносить за счет всяких декораторов и использования функционального программирования; очень грамотно организована работа с коллекциями и различными композитными типами; на Питоне действительно можно писать компактный легкочитаемый код.
Всего после пары недель общения с Питоном (вкупе с Джангой) у меня полностью пропало желание писать еще хоть что-нибудь на PHP :)
Автор помоему имел ввиду другое, что PHP уступает во многом аналогам по функциональности.
Про удобство — это дело каждого. ИМХО конечно.
Про удобство — это дело каждого. ИМХО конечно.
Уступает. Например на PHP несколько затруднительно сделать что-нибудь вроде индикатора прогресса загрузки файла на сервер. Во всяком случае все реализации которые я встречал — использовали что-нибудь левое.
Левое это JS?
Нет, JS-тут не помог бы :)
Для контроля процесса получения файла я встречал либо небольшие Perl-скрипты на стороне сервера либо флеш на строне клиента.
Для контроля процесса получения файла я встречал либо небольшие Perl-скрипты на стороне сервера либо флеш на строне клиента.
Спать пора… JS и Flash попутал…
Будем пробовать в свободное время, будем сравнивать =)
Пока не считаю это критичным, Flash не люблю но все-таки серверная и клиентская части разные — поэтому не считаю это левым.
Будем пробовать в свободное время, будем сравнивать =)
Пока не считаю это критичным, Flash не люблю но все-таки серверная и клиентская части разные — поэтому не считаю это левым.
поискал побольше — какже не помог? а это: habrahabr.ru/blogs/jquery/75420/
Я там чуть выше про функциональность, доступную из языка, написал.
У php довольно таки тяжелый и уродливый синтаксис, особенно когда речь идет об объектах — на Руби все пишется раза в 2 короче (хотите — верьте, хотите — проверьте). Плю в Руби лучше с элементами фукц. программирования, вроде замыканий. Плюс в Руби строки и массивы — объекты (ну это просто синтаксический сахар, но приятно ведь).
Да? А они становятся? </сарказм> :)
1) Быстрее ли (и меньше ли потребляют памяти) сайты на Руби и Питоне, тем более с использованием тяжеленных RoR/Django (и использованных там ActiveRecord), чем на php
2) Меньше ли расходы на хостинг для Python/Ruby приложений.
Я в общем-то по поводу синтаксиса спорить не буду — Руби в разы приятней php (а как там все плохо с замыканиями и динамически создаваемыми функциями — даже вспоминать неохота). Но глупо тратить силы, чтобы в результате получился тормозной сайт, которому еще и нужен отдельный VPS.
2) Меньше ли расходы на хостинг для Python/Ruby приложений.
Я в общем-то по поводу синтаксиса спорить не буду — Руби в разы приятней php (а как там все плохо с замыканиями и динамически создаваемыми функциями — даже вспоминать неохота). Но глупо тратить силы, чтобы в результате получился тормозной сайт, которому еще и нужен отдельный VPS.
Я вас уверяю, на Джанго делаются тяжеленные сайты.
Не нравится скорость ORM? Нафиг. Шаблонизатор? Нафиг.
Хотя на самом деле даже это делать совсем не обязательно. Легко подключить memcached, управлять кэшированием запросов и отдельных видов. Ну и так далее, в светлое сверхзвуковое будущее :)
Совсем уж дзен-буддисты, конечно, могут использовать микрофреймворки… Но это не моя история, мне времени жалко.
Не нравится скорость ORM? Нафиг. Шаблонизатор? Нафиг.
Хотя на самом деле даже это делать совсем не обязательно. Легко подключить memcached, управлять кэшированием запросов и отдельных видов. Ну и так далее, в светлое сверхзвуковое будущее :)
Совсем уж дзен-буддисты, конечно, могут использовать микрофреймворки… Но это не моя история, мне времени жалко.
> Не нравится скорость ORM? Нафиг. Шаблонизатор? Нафиг.
Может тогда и джанго выкинуть? И смысл тогда писать все на чистом Питоне? И зачем было включать в Django ORM и шаблонизатор, если они тормозят?
А про «нагруженные» сайты — ну не надо этого, если поставить кучу VPS, так и Друпал летать будет (ubuntu.org кажется на Друпале ведь?). Только что-то ни твиттер, ни вконтакте тот же не используют никаких джанго.
Может тогда и джанго выкинуть? И смысл тогда писать все на чистом Питоне? И зачем было включать в Django ORM и шаблонизатор, если они тормозят?
А про «нагруженные» сайты — ну не надо этого, если поставить кучу VPS, так и Друпал летать будет (ubuntu.org кажется на Друпале ведь?). Только что-то ни твиттер, ни вконтакте тот же не используют никаких джанго.
Твиттер на Руби изначально делался, если что. множество очень крутых сервисов — на Джанго. У меня есть знакомая команда джангистов, которая именно на нагруженных сервисах специализируется.
Помимо шаблонизатора и ORM в джанго еще ОЧЕНЬ много чего есть. Да и не так они плохи, чтобы просто так выбрасывать. Все равно понадобится аналог.
Собственно, а что вы пытаетесь доказать? Что все вокруг с нуля на чистом php пишут? Или Java? Это просто-напросто неправда.
Те же rambler, yandex используют тот же Джанго для своих проектов. У меня есть знакомый в sun, который пишет на Джанго. Ну и так далее.
Помимо шаблонизатора и ORM в джанго еще ОЧЕНЬ много чего есть. Да и не так они плохи, чтобы просто так выбрасывать. Все равно понадобится аналог.
Собственно, а что вы пытаетесь доказать? Что все вокруг с нуля на чистом php пишут? Или Java? Это просто-напросто неправда.
Те же rambler, yandex используют тот же Джанго для своих проектов. У меня есть знакомый в sun, который пишет на Джанго. Ну и так далее.
«ТЯжеленные» — читай «нагруженные»
Мультиязычность в DjangoCMS2 очень хорошо реализовано, а в вашей статье о ней ни слова :)
PIL опасно так собирать. По крайней мере в Debian Lenny по умолчанию приведенным способом PIL будет собрана без поддержки jpeg. Чтоб PIL собралась с jpeg, следует кроме python-dev указать еще libjpeg-dev (и, может быть, zlib1g-dev, тут не запамятовал, может она для какого-то другого пакета нужна, но не помешает).
Хм. У меня Ubuntu, не проверял на jpeg. Думаете, отдельно и руками собрать в virtualenv?
«pip install pil» и так все собирает, в этом и затык
Если неправильно понял — прошу простить.
Имеется в виду вот что — есть 2 варианта:
1. Ставить PIL средствами apt (что-то вроде python-imaging, не помню, если честно)
2. Ставить PIL средствами pip или easy_install. По большому счету — без разницы, в virtualenv или нет. Но чтоб PIL правильно встал этим методом, необходимы еще предварительно установленные через apt libjpeg-dev и zlib1g-dev.
Поэтому в requirements PIL писать не следует, если нет контроля над тем, где будет идти установка, т.к. он может легко не собраться или собраться не правильно. А если контроль есть, то простой вариант — установить python-imaging через apt глобально. Или более сложный, если нужна последняя версия (или используется --no-site-packages) — устанавливать разные dev-пакеты.
В любом случае, просто pip install PIL — опасно.
Имеется в виду вот что — есть 2 варианта:
1. Ставить PIL средствами apt (что-то вроде python-imaging, не помню, если честно)
2. Ставить PIL средствами pip или easy_install. По большому счету — без разницы, в virtualenv или нет. Но чтоб PIL правильно встал этим методом, необходимы еще предварительно установленные через apt libjpeg-dev и zlib1g-dev.
Поэтому в requirements PIL писать не следует, если нет контроля над тем, где будет идти установка, т.к. он может легко не собраться или собраться не правильно. А если контроль есть, то простой вариант — установить python-imaging через apt глобально. Или более сложный, если нужна последняя версия (или используется --no-site-packages) — устанавливать разные dev-пакеты.
В любом случае, просто pip install PIL — опасно.
Я вот задумался. Получается, так легко «песочницу» с зависимостями не перетащить на произвольную машину? В любом случае как бы придется ставить глобальные либы?
Иными словами, надо будет писать какой-то особый установочный скрипт?
Иными словами, надо будет писать какой-то особый установочный скрипт?
Да, virtualenv+pip в общем случае недостаточно, даже если знаешь, на какую систему будет все ставиться.
Кроме того, после установки песочницы нужно ж еще апач настроить, к примеру.
Это все довольно просто автоматизируется с помощью fabric. Что-то вроде этого:
это кусок из реального проекта, если что.
Кроме того, после установки песочницы нужно ж еще апач настроить, к примеру.
Это все довольно просто автоматизируется с помощью fabric. Что-то вроде этого:
def create_instance():
install_system_packages()
create_virtualenv()
create_clone()
setup_hg_hooks()
pip_install('basic')
pip_install('django')
pip_install('apps')
deploy_geoip()
create_wsgi_file()
setup_apache()
это кусок из реального проекта, если что.
Ну а если речь идет про какое-нибудь, например, джанго-приложение, то сложные зависимости вроде PIL или mysqldb не помещают в requirements, а документируют.
Хорошая статья
а вот нельзяли по подробнее про virtualenv?
сделал я его под проект, наколбасил дофига туда, понаставлял кучу вкусных модклей pipом,
и что потом с этим делать?
сделал я его под проект, наколбасил дофига туда, понаставлял кучу вкусных модклей pipом,
и что потом с этим делать?
import your_module
вот и все. Суть там в том, что пути в окружении указывают на локальные пакеты в env, а не на системные.
можно потом легко зависимости разработки отследить и повторить в другом месте: pip может сгенерировать файл requirements.txt.
вот и все. Суть там в том, что пути в окружении указывают на локальные пакеты в env, а не на системные.
можно потом легко зависимости разработки отследить и повторить в другом месте: pip может сгенерировать файл requirements.txt.
тоесть какого-то логического завершения, типа сворачивания/разворачивания всего этого окружения нету?
типа инсталяшку сделать чтоб на где-нибудь хостинге развернуть.
типа инсталяшку сделать чтоб на где-нибудь хостинге развернуть.
Можно. Конструктор соцсетей на джанге — pinax — так и работает.
по файлу requirements.txt вытягивает нужные пакеты в место, где раскладывается пакет. Честно скажу, я не смотрел как именно это у них делается.
Но можно; думаю, надо будет — справимся и я, и вы :)
по файлу requirements.txt вытягивает нужные пакеты в место, где раскладывается пакет. Честно скажу, я не смотрел как именно это у них делается.
Но можно; думаю, надо будет — справимся и я, и вы :)
распространенный вариант:
virtualenv = изоляция проектов друг от друга
pip = автоматическая установка и обновление питоновских зависимостей
fabric = развертывание на сервере
virtualenv = изоляция проектов друг от друга
pip = автоматическая установка и обновление питоновских зависимостей
fabric = развертывание на сервере
Теперь надо подключить django-cms. В общем-то, это просто.
В опере ссылка ведёт на www.xn--django-ms-13h.org/en/documentation/2.0/installation/
Подозреваю, что в адресе www.django-cms.org буква «с» русская :)
Поправка: в джанге не MVC, а MTV (Model Template View).
Хабралюди Питонисты, если вы объясните мне, как писать веб-приложения на python'e, чтобы не надо было, каждый раз после правок, перезапускать сервер (интерпретатор или как его?) — я обязуюсь вернуться к изучению этого красивого по синтаксису, языка! Уперся в это неудобство и лоб уже разбил. Или это не сильно неудобно!? :)
Для разработки запускайте его в дебаго-моде:
Этот режим специально сделал для разработки — джанга постоянно проверяет не изменились ли файлы, если да, тот тут же подкачивает. Еще один плюс: ошибки валятся в консоль. Плюс можно использовать любимый пхп-метод отладки — печать. Все ваши print-ы из функций тоже пойдут в консоль.
$ ./manage.py runserver
Этот режим специально сделал для разработки — джанга постоянно проверяет не изменились ли файлы, если да, тот тут же подкачивает. Еще один плюс: ошибки валятся в консоль. Плюс можно использовать любимый пхп-метод отладки — печать. Все ваши print-ы из функций тоже пойдут в консоль.
хм. У меня в продакшне mod_python (да! Django! без прав рута! на модпитоне!). Сделал bzr push-and-update и все _сразу_ обновилось, без всяких перезапусков.
хочу попробовать питона=)
- Перенесите, пожалуйста, статью в блог django
- Если вы серьезно занимались расширением функционала django-cms, то может быть заметили проблему с диспетчеризацией url-ов при подклюении одного и того же приложения к нескольким страницам. Варианты решения были, поимо размножения urls[\d+].py?
Резоннно, перенес.
И нет, не сталкивался. Вы не могли бы поподробней? Что там происходит? ЧТо пишет? На что ругается? я прям сейчас пишу с ним жирный такой сайтик, надо бы знать о подводных камнях.
И нет, не сталкивался. Вы не могли бы поподробней? Что там происходит? ЧТо пишет? На что ругается? я прям сейчас пишу с ним жирный такой сайтик, надо бы знать о подводных камнях.
в общем, картина такая:
есть две страницы, к обеим прицеплено приложение блогов (blog). В блоге есть раздел архивов записей по годам/месяцам. Кусок urls.py для приложения выглядит как
есть две страницы, к обеим прицеплено приложение блогов (blog). В блоге есть раздел архивов записей по годам/месяцам. Кусок urls.py для приложения выглядит как
url(r'^$', archive, name='archive-root'), попытка указать в шаблоне страницы {% url archive-root %} приводит к тому, что каждый раз на обоих страницах урл генерится как бог на душу положит. То на одну страницу с приложением, то на другую. Есть задумка сделать отдельный тэг для этого. Покопавшись в нутрях самой djangocms я аналога не нашел, разве что mlurl, но он предназначен немного для других целей.
А-а-а-а… Ну так это не проблема DjangoCMS, это проблема ваших урлов.
Как, если по-вашему, диспетчер должен определять урл, если он просто дважды прописан? По идее, должен просто в порядке включения в коренной urls.py.
Мне казалось, что если по-разному назвать приложения в CMS_APPLICATION_URLS, то адреса должны быть разными. Или нет?
Как, если по-вашему, диспетчер должен определять урл, если он просто дважды прописан? По идее, должен просто в порядке включения в коренной urls.py.
Мне казалось, что если по-разному назвать приложения в CMS_APPLICATION_URLS, то адреса должны быть разными. Или нет?
Частично да, но само приложение пишется в базе как <app_name>.urls — соответственно, можно не просто добавлять паттерны в пространство имен, а изменять url.name. Диспетчеризация так же проходит через контекст cms, поэтому и вижу возможным создание соотв. механизма. А разные названия приложению не помогут, если они будут ссылаться на один и тот же модуль.
Интересно было бы увидеть сравнение по функция с Pinax. P.S. Я не знаю почему многие считают Pinax сац сетью это помоему просто CMS.
Я с Пинаксом полгода работал. Это просто большой комплект разных джанго-приложений. В рамках проекта разрабатываются всякие полезные штучки — ну и плюс просто хороший пример большой разработки.
Там нет дерева, не так легко и удобно страницы создавать и превращать в навигационное меню, нет вспомогательных CMS-штучек.
В общем, сравнивать их нельзя.
Там нет дерева, не так легко и удобно страницы создавать и превращать в навигационное меню, нет вспомогательных CMS-штучек.
В общем, сравнивать их нельзя.
А как вам «социальный» функционал пинакса?
С чем бы сравнить… на грубо, говоря, на нем можно поднять аналог хабра, ливстрита еще чего-нибудь такого?
С чем бы сравнить… на грубо, говоря, на нем можно поднять аналог хабра, ливстрита еще чего-нибудь такого?
а почему нет? Блог надо будет, конечно, расширить под конкретные нужны, tribes и wiki убрать — и вперед. cloud27.com — неплохой авторский пример того, что можно сделать с Пинаксом.
Есть и недостатки. В той версии, с которой я работал, были проблемы в том смысле, что некоторые приложения довольно глубоко связаны, приходилось много вырезать по корню.
В конце концов я пришел к тому, что просто вытаскивал и интегрировал отдельные приложения. Но у меня проект был очень уж нестандартный, можно было обойтись без таких мучений.
Есть и недостатки. В той версии, с которой я работал, были проблемы в том смысле, что некоторые приложения довольно глубоко связаны, приходилось много вырезать по корню.
В конце концов я пришел к тому, что просто вытаскивал и интегрировал отдельные приложения. Но у меня проект был очень уж нестандартный, можно было обойтись без таких мучений.
>>> что в мире Python существуют не менее мощные и даже гораздо более зрелые инструменты.
Вот тут стоит удерживаться от лишних эмоций. Беспристрастность — язык мудрости.
Я понимаю Ваш энтузиазм, однако при всем моем уважении к Джанго, для «гораздо более зрелых» нужно все-таки дозреть еще на пару-тройку тысяч плагинов в библиотеке. Так что думаю, есть куда развиваться.
А в остальном, спасибо за интересный обзор :)
Вот тут стоит удерживаться от лишних эмоций. Беспристрастность — язык мудрости.
Я понимаю Ваш энтузиазм, однако при всем моем уважении к Джанго, для «гораздо более зрелых» нужно все-таки дозреть еще на пару-тройку тысяч плагинов в библиотеке. Так что думаю, есть куда развиваться.
А в остальном, спасибо за интересный обзор :)
Это я не про DjangoCMS говорил, которая совсем свеженькая.
А про Zope и Plone. Это монстры, которые недооценены в России. Им много лет, тот же Zope уже давно перерос сам себя и собственные начальные цели.
А про Zope и Plone. Это монстры, которые недооценены в России. Им много лет, тот же Zope уже давно перерос сам себя и собственные начальные цели.
Точно, это «монстры». Нет, нет так — это сущие «кошмары в ночи».
Я с ними работал год, это чудовищно, категорически не хочется возвращаться.
Впечателние после них такое: задумка очень мощная, интересная, но реализация — ужас!
На практике постоянно напарываешься на какие-то грабли.
Я с ними работал год, это чудовищно, категорически не хочется возвращаться.
Впечателние после них такое: задумка очень мощная, интересная, но реализация — ужас!
На практике постоянно напарываешься на какие-то грабли.
В свое время они были очень, ОЧЕНЬ ничего. Да и никаких аналогов не было. Сейчас-то, конечно, резонней использовать решения на Django или Turbogears, одно из которых и предлагается в заметке.
А Zope… Zope как killer app отошел, да. Насколько понимаю, Zope3 — это уже не фреймворк, набор reusable элементов, которые встречаются много где. Скажем, в Twisted. Или один фирменный фремворк, на котором я работал с год.
Или Plone…
Да и настолько ли хорош какой-нибудь Drupal? Он уже подходит к состоянию Zope2, а скоро, пожалуй, и превзойдет его по сложности.
А Zope… Zope как killer app отошел, да. Насколько понимаю, Zope3 — это уже не фреймворк, набор reusable элементов, которые встречаются много где. Скажем, в Twisted. Или один фирменный фремворк, на котором я работал с год.
Или Plone…
Да и настолько ли хорош какой-нибудь Drupal? Он уже подходит к состоянию Zope2, а скоро, пожалуй, и превзойдет его по сложности.
только не надо писать «какой-нибудь Drupal» ;)
На каком-нибудь друпе написан какой-нибудь там сайт Белого Дома. Не думаю, что сисы американской администрации настолько глупы что не разберутся что хорошо, а что плохо. У друпа совершенно свой путь и сообщество следит за тем чтобы он не стал монстром. И он не станет. Это не самая шустрая CMS, но он и не создавался для маленьких проектов.
Неблагодарная это затея меряться CMS-ами, особенно без сформулированных критериев сравнения :)
На каком-нибудь друпе написан какой-нибудь там сайт Белого Дома. Не думаю, что сисы американской администрации настолько глупы что не разберутся что хорошо, а что плохо. У друпа совершенно свой путь и сообщество следит за тем чтобы он не стал монстром. И он не станет. Это не самая шустрая CMS, но он и не создавался для маленьких проектов.
Неблагодарная это затея меряться CMS-ами, особенно без сформулированных критериев сравнения :)
«Какой-нибудь» — это в смысле «один из».
А сайт ЦРУ — на каком-нибудь Plone сделан, который есть дитя Zope. :) Там и плагинов масса, и история, и бла-бла-бла. Как быть? :)
Zope-то стал. И тчк. Хотя сообщество было ого-го. Или даже из-за того, что сообщество было «ого-го» :) Вон, я ядра линукса тоже сообщество, а строчек кода за 6 млн зашкаливает.
В общем, я почему вспомнил и Plone, и Zope. Потому что с ними работают давно, так же как и с Drupal. Но так же как и Drupal, они стали сложными и тяжелыми.
А сайт ЦРУ — на каком-нибудь Plone сделан, который есть дитя Zope. :) Там и плагинов масса, и история, и бла-бла-бла. Как быть? :)
Zope-то стал. И тчк. Хотя сообщество было ого-го. Или даже из-за того, что сообщество было «ого-го» :) Вон, я ядра линукса тоже сообщество, а строчек кода за 6 млн зашкаливает.
В общем, я почему вспомнил и Plone, и Zope. Потому что с ними работают давно, так же как и с Drupal. Но так же как и Drupal, они стали сложными и тяжелыми.
В Зопе меня больше всего раздражала не сложность, а попытка вобрать в себя все, тот самый killer app. С идеологической стороны это грубое попрание UNIX-way (когда одно действие должна делать одна программа, а все остальное получается их комбинированием). А спрактической стороны получается, что этот комбайн все далает сам и делает фигово, а возможности заменить нет.
Например, нужно разрабатывать какие-то скрипты, шаблоны и прочее — все это делается через веб-интерфейс — жутко неудобно. Ладно, с гемором я пробил переход на фтп. Ага, фтп-сервер в зопе свой. Просто так сделать файл нельзя (получается объект неправильного типа), значит опять надо идти в веб-морду, создавать там объект, после чего его можно заливать через фтп. А как насчет контроля версий? Какой-то реализован в самой зопе. Но это опять кошмар! Как надо он не работает, внешний svn не подключишь.
А ZODB — это же беспросветнейший п… ц! Я могу ее годами матюкать, столько крови она у меня выпила! Это в полном соответствии с Кантом «вещь в себе». Работать нормально с ней можно только через веб-морду. Интегрироваться с ней извне — гемор. Мы делали крупный сайт, нам нужно было все увязывать с другими компонентами, чтобы данные поступали из КИС, текли на сайт и там отображались. Жуть! Лучшим решением оказалось избавиться от нее, хранить в ней только логику приложения и ходить за данными в нормальную реляционную базу. А что в итоге? Скрипты в неудобном для работы виде, данные в базе. Что там от зопы-то осталось? И ради чего это все тогда? Чтобы простой в техническом плане сайт отжирал на сервере 100 мегов и иногда падал? Работать нормально он мог только за очень агрессивной проксей, которая тупо кешировала все на существенное время. Но это тоже не выход.
Мой личный вывод: скопище оригинальных компонент, каждая из которых очень интересна задумкой, но неидеальна реализацией, а вместе просто вырвиглазый кошмар.
После зопы Django мне показалось землей обетованной, к которой я шел 40 лет :)
Правильное разделение на компоненты — тут у нас ОРМ, а тут шаблоны. Если шаблоны не нравятся, можно заменить на свой движок. Данные отдельно — в базе. К которой ты сам можешь независимо подключаться и работать с ней. Проблема интеграции с другими системами просто отсутствует — льешь в базу, забираешь из базы. Правильно реализованный unix way. Каждый компонент на своем месте. Все файлы скрипты и прочее — в файловой системе, а значит и фтп и svn работают как надо.
> Да и настолько ли хорош какой-нибудь Drupal?
Он лучше как минимум в одном — он не пытается вобрать в себя слишком много.
Например, нужно разрабатывать какие-то скрипты, шаблоны и прочее — все это делается через веб-интерфейс — жутко неудобно. Ладно, с гемором я пробил переход на фтп. Ага, фтп-сервер в зопе свой. Просто так сделать файл нельзя (получается объект неправильного типа), значит опять надо идти в веб-морду, создавать там объект, после чего его можно заливать через фтп. А как насчет контроля версий? Какой-то реализован в самой зопе. Но это опять кошмар! Как надо он не работает, внешний svn не подключишь.
А ZODB — это же беспросветнейший п… ц! Я могу ее годами матюкать, столько крови она у меня выпила! Это в полном соответствии с Кантом «вещь в себе». Работать нормально с ней можно только через веб-морду. Интегрироваться с ней извне — гемор. Мы делали крупный сайт, нам нужно было все увязывать с другими компонентами, чтобы данные поступали из КИС, текли на сайт и там отображались. Жуть! Лучшим решением оказалось избавиться от нее, хранить в ней только логику приложения и ходить за данными в нормальную реляционную базу. А что в итоге? Скрипты в неудобном для работы виде, данные в базе. Что там от зопы-то осталось? И ради чего это все тогда? Чтобы простой в техническом плане сайт отжирал на сервере 100 мегов и иногда падал? Работать нормально он мог только за очень агрессивной проксей, которая тупо кешировала все на существенное время. Но это тоже не выход.
Мой личный вывод: скопище оригинальных компонент, каждая из которых очень интересна задумкой, но неидеальна реализацией, а вместе просто вырвиглазый кошмар.
После зопы Django мне показалось землей обетованной, к которой я шел 40 лет :)
Правильное разделение на компоненты — тут у нас ОРМ, а тут шаблоны. Если шаблоны не нравятся, можно заменить на свой движок. Данные отдельно — в базе. К которой ты сам можешь независимо подключаться и работать с ней. Проблема интеграции с другими системами просто отсутствует — льешь в базу, забираешь из базы. Правильно реализованный unix way. Каждый компонент на своем месте. Все файлы скрипты и прочее — в файловой системе, а значит и фтп и svn работают как надо.
> Да и настолько ли хорош какой-нибудь Drupal?
Он лучше как минимум в одном — он не пытается вобрать в себя слишком много.
Ну нет больше большого Zope перед вами :) Не волнуйтесь вы так :)
Между прочим, даже Django обвиняли в попытках заново изобрести велосипед. А велосипед получился — ого-го!
Статья-то к чему… Что затребовала душа программиста простую CMS, написанную на хорошем фреймворке и легко с ним интегрирующаяся. Получается, у меня есть и фреймворк хороший в качестве инструмента, и CMS прозрачная, и язык толковый. Оп-па! И жить хорошо!
Между прочим, даже Django обвиняли в попытках заново изобрести велосипед. А велосипед получился — ого-го!
Статья-то к чему… Что затребовала душа программиста простую CMS, написанную на хорошем фреймворке и легко с ним интегрирующаяся. Получается, у меня есть и фреймворк хороший в качестве инструмента, и CMS прозрачная, и язык толковый. Оп-па! И жить хорошо!
А можно к джанге-цмс подключить haml в качестве шаблонов?
Спасибо за статью, хорошая.
Удивительно вообще, что на Django вменяемая CMS появилась не так давно.
А из CMS на Django есть ещё загадочная и никем невиданная www.ellingtoncms.com/ (коммерческая)
Удивительно вообще, что на Django вменяемая CMS появилась не так давно.
А из CMS на Django есть ещё загадочная и никем невиданная www.ellingtoncms.com/ (коммерческая)
Статья интересная.
Как небольшое дополнение
Twisted — интересный, но не уникальный :) В Руби есть похожий EventMachine
Как небольшое дополнение
Однако, Питон — язык универсальный; интересных фреймворков на нем больше (чего только Twisted стоит);
Twisted — интересный, но не уникальный :) В Руби есть похожий EventMachine
строчку. /env/bin/activate
я бы поправил на. ~/cms-project/env/bin/activate
Xubuntu по умолчанию лезет в корневую директорию.
я бы поправил на. ~/cms-project/env/bin/activate
Xubuntu по умолчанию лезет в корневую директорию.
> sudo apt-get install python-setuptools python-dev build-essential
Надо добавить python-virtualenv
Надо добавить python-virtualenv
>> sudo apt-get install python-setuptools python-dev build-essential
> Надо добавить python-virtualenv
И еще python-pip
> Надо добавить python-virtualenv
И еще python-pip
поправил
Может, лучше так?
easy_install pip
pip install virtualenv
а то будет старье разное устанавливаться
easy_install pip
pip install virtualenv
а то будет старье разное устанавливаться
Старье — это вы про версию pip?
А мне вот кажется, что, к примеру, в ubuntu пакеты довольно свежие, и ставить вне apt пакеты в систему — нечистоплотно.
А мне вот кажется, что, к примеру, в ubuntu пакеты довольно свежие, и ставить вне apt пакеты в систему — нечистоплотно.
Мне кажется, это не принципиально, всего-то будем иметь более свежую версию pip. Но, по крайней мере, устанавливать pip, и другие пакеты, нужно или из репозитариев, или так, чтобы они не путались с системными пакетами, иначе смысл всей затеи теряется.
Мне тоже кажется, что лучше или все пакеты ставить через pip, или все через apt, чтоб не путалось. Но через apt доступны неактуальные версии, и не все там есть, и это такая принципиальная штука, которая со временем не исправится. Поэтому, как мне кажется, выход в том, чтобы ставить все через pip, причем, желательно, в virtualenv.
Последний pip умеет uninstall, к примеру.
Ну да, есть еще такой вариант: ставим pip и virtualenv через apt, потом создаем virtualenv и там выполняем pip install -U pip. И потом питоньи пакеты никуда кроме virtualenv'ов не ставить.
Последний pip умеет uninstall, к примеру.
Ну да, есть еще такой вариант: ставим pip и virtualenv через apt, потом создаем virtualenv и там выполняем pip install -U pip. И потом питоньи пакеты никуда кроме virtualenv'ов не ставить.
А есть где-нибудь живой пример качнуть, а то что-то нихера не получается? Всё поставил, захожу на локалхост, а там:
«It worked!
Congratulations on your first Django-powered page.
…
* Start your first app by running python demosite/manage.py startapp [appname].»
«It worked!
Congratulations on your first Django-powered page.
…
* Start your first app by running python demosite/manage.py startapp [appname].»
поправьте строку:
". env/bin/activate"
на
«source env/bin/activate »
Проблема в том что, например в убунте, у меня не сработало, а так как я не знаю точно как оно должно выглядеть, возникли грабли при выполнении инструкции по установки.
". env/bin/activate"
на
«source env/bin/activate »
Проблема в том что, например в убунте, у меня не сработало, а так как я не знаю точно как оно должно выглядеть, возникли грабли при выполнении инструкции по установки.
насколько знаю, source и "." в баше означает одно и то же. Совершенно точно работало в Убунте и какой-то сборке Генту.
у меня zsh погоже так не катит.
Буду благожарен если пожскажете как обойти вот такую проблемку:
Уперся в проблему такого толка все ставлю, как описано но при вызове syncdb говорит, что не найден модуль MySQLdb
пробую pip install mysql-python -E env/ так и внутри env просто pip install говорит, что все установленно. :/
Куда копать?
Буду благожарен если пожскажете как обойти вот такую проблемку:
Уперся в проблему такого толка все ставлю, как описано но при вызове syncdb говорит, что не найден модуль MySQLdb
пробую pip install mysql-python -E env/ так и внутри env просто pip install говорит, что все установленно. :/
Куда копать?
ПРобуем по порядку. Я сейчас перескажу, что обычно делаю. Статья написана несколько месяцев назад, я с тех пор несколько изменил подход.
Допустим, вы уже создали среду:
virtualenv --no-site-packages env
Теперь активируем ее:
. env/bin/activate
Мы внутри окружения, и экземпляр питона не должен видеть внешних пакетов. Дальше ставим в окружение последний pip:
easy_install pip
Теперь у нас есть pip. Есть хорошая утилитка, показывающая установленные пакеты в текущем окружении. Ставим ее:
pip install yolk
Смотрим список пакетов:
yolk -l
Ну как-то так и можно посмотреть, стоит ли то, что надо. Проверьте две вещи:
1) делал все процедуры я уже после включения окружения как текущего!
2) Очень желательно всегда при создании окружения указывать флаг :--no-site-packages".Думаю, здесь ваша ошибка и заключалась.
Утилитой можно проверить ваше окружение использует глобальные пакеты — их тогда будет слишком много.
Допустим, вы уже создали среду:
virtualenv --no-site-packages env
Теперь активируем ее:
. env/bin/activate
Мы внутри окружения, и экземпляр питона не должен видеть внешних пакетов. Дальше ставим в окружение последний pip:
easy_install pip
Теперь у нас есть pip. Есть хорошая утилитка, показывающая установленные пакеты в текущем окружении. Ставим ее:
pip install yolk
Смотрим список пакетов:
yolk -l
Ну как-то так и можно посмотреть, стоит ли то, что надо. Проверьте две вещи:
1) делал все процедуры я уже после включения окружения как текущего!
2) Очень желательно всегда при создании окружения указывать флаг :--no-site-packages".Думаю, здесь ваша ошибка и заключалась.
Утилитой можно проверить ваше окружение использует глобальные пакеты — их тогда будет слишком много.
Кто-нибудь сравнивал django cms с fein cms?
Автор, то есть я, и сравнивал некоторое время назад, когда определялся с инструментом. Слышал неплохие отзывы об обоих.
В принципе, равнозначны, но покачественней показался сайт и портфолио пошире для DjangoCMS, поэтому и стал пользоваться.
Еще говорят, что feincms пониже уровнем и погибче, хотя сам пока не упирался в проблемы DjangoCMS.
В принципе, равнозначны, но покачественней показался сайт и портфолио пошире для DjangoCMS, поэтому и стал пользоваться.
Еще говорят, что feincms пониже уровнем и погибче, хотя сам пока не упирался в проблемы DjangoCMS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DjangoCMS2.0 — быстрее, больше, эффективней