Здравствуйте, TheOldMan, Вы писали:
TOM>Здравствуйте, DeZhavi, Вы писали:
DZ>>Здравствуйте, int 13h, Вы писали:
I1>>>Здравствуйте, Аноним, Вы писали:
А>>>>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP? А>>>>Просьба сильно не пинать, я чайник в сайтостроении.
I1>>>Apache + PHP + Eclipse (PDT) + XDebug + MySQL — довольно неплохой стандартный набор + комьюнити. DZ>>А как вам такая связка для разработки на php VS2005(VS2008) + PHP + MySql ну и Apache естественно?
TOM>не нравиться: только под windows
А мне нарвится, с учтом того что проекты и на ASo и на php очнь удобно
Здравствуйте, Mamut, Вы писали:
ДГ>>Перла я не знаю, но от словосочетания "PHP удобнее" меня блевать тянет. Домашние странички — да, удобнее, базару нет. Personal Home Page, блин. M>Чтобы не повторять: Re[4]: PHP vs. Perl
D>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
Главный минус этого “императивного” решения в том, что оно рушит барьеры абстракции. Вы не можете написать совершенно отвлеченную функцию, которая хочет писать в БД, и быть уверенными, что она работает всегда. Потому что если ее вызовет что-то в то время, когда активно слейв-соединение, она упадет.
За это меня все время ругает Андрей, и даже пророчит, что не пройдет и двух месяцев, как кто-нибудь наткнется на какой-нибудь трудноуловимый баг, связанный с этой императивностью. Теоретически, он прав. Но это единственное решение, которое я смог придумать, которое работает извне Джанго, не трогая ее код.
Перевожу: в рамках существующих фреймворков (Django и ORM) мы не нашли нормального решения данной проблемы и воткнули костыли, которые могут (и создадут!) проблемы в будущем — с управлением соединениями с базой вообще шутки плохи.
Дальше идут уже отмазки, почему все не так страшно и может быть это будет работать, потому что наша система на самом деле и т.п ...
Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
Re[9]: Почему я не люблю фреймворки
От:
Аноним
Дата:
18.03.08 15:48
Оценка:
Здравствуйте, dmz, Вы писали:
D>>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
dmz>Ага. А вот и "локализация проблемы": http://lenta.yandex.ru/read.xml?group=14
D>>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
dmz>Ага. А вот и "локализация проблемы": http://lenta.yandex.ru/read.xml?group=14
Мягко говоря проблема уже другая. И не проблема вовсе, а оптимизация.
dmz>Перевожу: в рамках существующих фреймворков (Django и ORM) мы не нашли нормального решения данной проблемы и воткнули костыли, которые могут (и создадут!) проблемы в будущем — с управлением соединениями с базой вообще шутки плохи.
А как добавить репликации в уже существующий код без костылей вы знаете? И сколько ресурсов потребовалось бы на разработку всей системы с нуля?
dmz>Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
Бонус от фреймворка уже получен — время разработки гипер короткое. Далее уже идут "хачу!", со всеми вытекающими. Решение получилось, не трогающее код фреймворка, и абсолютно стороннее — это хорошо. Тем более что Иван сразу знал, что начинает использовать инструмент где нет репликаций, а значит сделал этот осознано.
Саш, я бы, честно говоря, давно бросил спорить . Человек явно не готов менять свою точку зрения, и просто хочет победить в споре. Отсюда и эти выборочные цитаты, и разворачивание фактов удобной стороной... Например он благополучно не заметил, что производительность нам обеспечивает кеш, а не репликации. Продолжает твердить, что упал сервис из-за фреймворка, хотя из того поста понятно, что фреймворк ни при чем. Даже умудрился прицепиться к моему перфекционистскому бурчанию про императивный стиль кластерного бэкенда... Чудно .
D>А как добавить репликации в уже существующий код без костылей вы знаете?
Разрабатывать с нуля ничего не надо. Надо просто брать компоненты, которые делают что-то одно, но делают это хорошо. И делать так, что бы эти компоненты было легко переписать или заменить в случае чего.
Затем, надо выделять вещи очень важные и критичные — такие как работа с базой и коннекциями, которые влияют на вообще все, и сессии, которые при их наличии влияют масштабирование (есть сессии — нет масштабирования, гы-гы. шучу.)
Есть вещи менее важные — шаблонный движок, например, или middleware (хотя конкретно флуп тоже таит много открытий чудных)
Есть совсем маловажные — например, компонент, который отвечает за валидацию значений форм и возврат ошибочных значений ( хотя этого добра в питоне совсем немного, и нам пришлось написать свой, т.к. HtmlForms или как там его дюже мерзок)
Каждый компонент рассматривается отдельно, тестируется, оборачивается таким образом, что бы от него избавиться, не переделывая всей системы в целом.
Можно взять все оптом в виде джанги. Ну и получить то, что получили.
И не надо говорить, что можно или взять что-то от джанги, или там поменять в джанге ORM на что нибудь другое.
Никто этого в реальной жизни не делает, а как только начинает — то теряет то самое "гипер-короткое" время разработки напрочь совсем.
D>И сколько ресурсов потребовалось бы на разработку всей системы с нуля?
Ну это примерно известно. Был случай переписывания одной системы с web.py на TurboGears и с TG на набор компонентов с собственным glue. В общем-то очень немного по сравнению со временем написания системы, благодаря наличию выделенного слоя бизнес-логики, этот самый слой почти не пострадал. Хуже пришлось при выкидывании ORM, потому что он пускает свои метастазы между слоями...
Если бы писали сразу с нуля, то было бы вообще отлично. С нуля ведь это очень условно. Фактически, с нуля написан только валидатор форм и сериализаторы в xml и json, потому что те, которые есть не нравятся. Остальное все стандартное. Только обернутое. На всякий случай.
dmz>>Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
D>Бонус от фреймворка уже получен — время разработки гипер короткое.
Полгода, ага. И потом еще какое-то время, что бы работало. Собственно, данная история показывает именно этот сценарий, да? Возможно эти не все эти полгода ушли на программирование. Но тогда это "гипер" как-то теряет часть смысла.
И еще учтите, что "гипер" короткое оно у тех, кто хорошо знает. А чем сложнее фреймворк и чем больше связей — тем сложнее разбираться и больше на это надо времени.
D>Далее уже идут "хачу!", со всеми вытекающими. Решение получилось, не трогающее код фреймворка, и абсолютно стороннее — это хорошо.
Какие такие "хачу"? Мы говорим о базовых вещах, о нужности которых было известно заранее. Масштабирование там. Подразумевающее известно что.
D>Тем более что Иван сразу знал, что начинает использовать инструмент где нет репликаций, а значит сделал этот осознано.
Нет не "репликации". Нет управления соединениями.
Давайте мы абстрагируемся от личностей уже, ага? То, что получилось, это хороший и показательный кейс, и спасибо, что он рассказан честно. Выводы все заинтересованные сделают самостоятельно. Тут еще есть занятный пласт, связанный с навязанными джангой решениями (верстка, поддержка, etc), но это уже специфика конторы.
I>Саш, я бы, честно говоря, давно бросил спорить . Человек явно не готов менять свою точку зрения, и просто хочет победить в споре.
Мне менять точку зрения сейчас бессмысленно, потому что этот вопрос закрыт. Т.е. если считать плюсы и минусы, то получится вроде:
[+] Быстро писать
[-] Черный ящик с непредсказуемыми заранее особенностями
[-] Заставляет отказаться от хорошо зарекомендовавших себя практик в обмен на неизвестно что
I>Отсюда и эти выборочные цитаты, и разворачивание фактов удобной стороной...
Ну я не могу цитировать все, хотя может и стоило, т.к. очень интересно и познавательно.
I>Например он благополучно не заметил, что производительность нам обеспечивает кеш, а не репликации.
Вам. При этом тот факт что репликации, а точнее, управления коннекциями, отсутствуют. Для всех.
И когда выясниться, что кэш репликации не заменяет кому-то, то что?
I>Продолжает твердить, что упал сервис из-за фреймворка, хотя из того поста понятно, что фреймворк ни при чем.
Он упал из-за побочных эффектов применения джанги, а именно, особенности устройства сессий. В первый раз. Это не так?
В общем-то проблема не в том, что упал. Проблема в том, что бы быстро починить.
I>Даже умудрился прицепиться к моему перфекционистскому бурчанию про императивный стиль кластерного бэкенда... Чудно I>.
К стилю прицепился не только я, но еще некий Андрей, и сам автор данного решения. Я подозреваю с этим решением совершенно конкретные проблемы, но от спекуляций воздержусь, а проверить не имею возможности.
I>Ну не нравятся человеку фреймворки, пусть...
. Человек явно не готов менять свою точку зрения, и просто хочет победить в споре. Отсюда и эти выборочные цитаты, и разворачивание фактов удобной стороной... Например он благополучно не заметил, что производительность нам обеспечивает кеш, а не репликации. Продолжает твердить, что упал сервис из-за фреймворка, хотя из того поста понятно, что фреймворк ни при чем. Даже умудрился прицепиться к моему перфекционистскому бурчанию про императивный стиль кластерного бэкенда... Чудно 