Количество запросов от нагрузки не очень зависит (Ну друпал может переводится, в режим экономии и опятьже много кэшировать, но все равно оптимизации кода на лету пока не придумали, а ленивых я не припомню для цмсок:). Поставьте друпал, модуль views (очень популярный), забейте немного данных и вьюху для них и модуль devel вам все покажет. Не так давно в интенетах пробегало сравнение техже друпала и джумлы и друпал при таких вот показателях оказался более экономным. По поводу того что мне что-то там не поможет: в CMS обычно кроме базы стандартных и необходимых модулей есть еще определенный API. Т. е. конечно можно лезть в ядро и переписывать все подряд или изобретать свои оптимизированные велосипеды, но это все потом придется поддерживать и может быть даже обновлять. Архитектура у джумлы и друпала вполне себе нормальная (кому-то нравится кому-то нет, но стройная система с которой работают много много разработчиков везде присутствует), просто они универсальны сразу имеют много наворотов (вроде интернационализации, расширяемости, подсистем модулей и шаблонов и много т. п.) отсюда и оверхеды такие.
«нормальное дело» для больших цмс. 1-2 сотни запросов это норма если вы используете обвешаный друпал или джумлу (про остальные, правда, не знаю). Спасает кэширование, есть мысль что если требуется не по-быстрому состряпать default_site, то лучше фреймворки
это скорее сбор дивидендов от прожитой жизни и применение опыта как основного качества. Думаю, в любой компании, а тем более таких крупных, непосредственным принятием решений занимается армия менеджеров звеном пониже.
_было_ модно и любить и ненавидеть, когда на выражение ненависти тебе могут предложить купить мак/поставить линукс, то все ненавистные глюки воспринимаются уже как «особенности», причем такое хараткерно для всех трех миров:)
и было бы чудно если бы кто-нибудь из начинающих попробовал сравнить сложность, например, использования ORM в джанге пользуясь ссылкой которую я давал (могу найти и русский перевод, правда для устаревающей уже 0.96) и вот такого вот (sql ли ?):
к тому что PHP начинался как этакий навороченный чуть более чем шаблонизатор, от чего и пострадал сильно
> Если вы сами создали «мешанину логики и представления» — вам её и поддерживать.
Язык даёт средства, как вы ими пользуетесь дело ваше.
Нет это совсем не так, мы недавно отказались поддерживать много индусской вермишели на ASP (не .NET а старенький) в котором тоже можно лепить все в одну кучу.
> Говнокод — не минус или плюс языка, а наглядный результат жизнедеятельности отдельно взятого программиста.
Так я и говорю, что нетрудно догадываться(вспомнить), что сказал бы Артемий, еслибы ему кто-то заявил что верстке и дизайне каждый может как угодно самовыражаться, не освоив основ профессии.
«Parser в известном смысле — макроязык, в нём нет оператора print; весь текст, набранный в исходном файле, суть большой оператор print. Конструкции Parser являются погруженными в текст.
Получается, что вы не пишете программу, которая выводит текст — наоборот, в имеющийся текст вы добавляете логику, ^if(условие){действие}, и организацию, блоки(методы), на которые вы разбиваете HTML-код»
если в парсере и возможно отделять данные, логику и представление, то не надо учить людей, что без этого тоже можно. Знаете ведь за что многие люто не переносят PHP, на котором тоже можно правильно программировать? А на Perl можно делать просто гениальные вещи. Я в комментарии повыше упомянул, что сайт это тоже ПО. Так вот ПО надо поддерживать. Поддерживать мешанину логики и представления очень трудно и часто дороже чем переписать все заново. Возвращаясь к той же Джанге, в ее шаблонном языке логика отключена напрочь, там нельзя ни присванивать значений, ни делать сложных условий и это правильный подход, которому стоит учиться.
видимо просто нужен Лебедев от программизма на Code Assurance, а именно понимание что сайт часто это тоже немного ПО, а не только дизайн + верстка + контент. Это наверное и отличает веб-девелопмент 95го года от текущего.
ну заказчик же как-то оценивает профессионализм исполнителя, хотя, конечно ничего в этом не понимает. А вот Вася в отместку сотруднику Пете может влепить минус совершенно профессионально его обосновав
наоборот, если бы оценивали перпендикулярные друг другу отделы можно было бы избежать основной обсуждаемой тут проблемы (сговор) или пускай это будут случайно выбранные на период люди.
в линуксе вкладка с ~5 флеш банерами съедает все кпу и вызывает желаение побыстрей ее закрыть. Я спасаюсь flashblock'ом и баннеров не вижу совсем, т. е. задача показа мне рекламы реализуемая с помощью Flash решается плохо.
^if(def $form:date && def $form:header && def $form:body){
^connect[$connect_string]{
^void:sql{insert into news
(date, header, body)
values
('$form:date', '$form:header', '$form:body')
}
…сообщение добавлено
}
}{
а то может я правда за непонятное ратую
к тому что PHP начинался как этакий навороченный чуть более чем шаблонизатор, от чего и пострадал сильно
> Если вы сами создали «мешанину логики и представления» — вам её и поддерживать.
Язык даёт средства, как вы ими пользуетесь дело ваше.
Нет это совсем не так, мы недавно отказались поддерживать много индусской вермишели на ASP (не .NET а старенький) в котором тоже можно лепить все в одну кучу.
> Говнокод — не минус или плюс языка, а наглядный результат жизнедеятельности отдельно взятого программиста.
Так я и говорю, что нетрудно догадываться(вспомнить), что сказал бы Артемий, еслибы ему кто-то заявил что верстке и дизайне каждый может как угодно самовыражаться, не освоив основ профессии.
Получается, что вы не пишете программу, которая выводит текст — наоборот, в имеющийся текст вы добавляете логику, ^if(условие){действие}, и организацию, блоки(методы), на которые вы разбиваете HTML-код»
если в парсере и возможно отделять данные, логику и представление, то не надо учить людей, что без этого тоже можно. Знаете ведь за что многие люто не переносят PHP, на котором тоже можно правильно программировать? А на Perl можно делать просто гениальные вещи. Я в комментарии повыше упомянул, что сайт это тоже ПО. Так вот ПО надо поддерживать. Поддерживать мешанину логики и представления очень трудно и часто дороже чем переписать все заново. Возвращаясь к той же Джанге, в ее шаблонном языке логика отключена напрочь, там нельзя ни присванивать значений, ни делать сложных условий и это правильный подход, которому стоит учиться.
djangobook.com/
вот этот гайд, например, сразу объясняет как решать задачи эфективно и красиво