Xpoint
   [напомнить пароль]

крик души провинциального Web-мастера: жаверские технологии в PHP (тема для холи-вор)

Метки: [без меток]
[арх]
2006-02-27 13:01:13 [обр] Дмитрий Попов(15/509)[досье]

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

А я вот тоже считаю, что Smarty (для тех, кто не в курсе - монстроподбный шаблонизатор со своим псевдо-языком, написанный на PHP) - величайшее заблуждение всех времен и народов.
Еще я считаю, что всякие паттерны MVC, "трехуровневые модели" для классических Web-проектов - тоже бред.

Сейчас меня можно пнуть, за то, что мол "слишком однобоко воспринимаю понятие Web-проекта", но я постараюсь увернуться.
Увы, но "классический сайт" - делается на один раз, по конкретному заказу от конкретной компании.
И основная задача такого "классического сайта" - сделав его один раз, дать ему возможность работать как можно дольше.
Сайт должен быть быстрым, масштабируемым, и работающим.

Все навороты - сильно усложняют (да, я именно так считаю) разработку и поддержку сайта. Да, у них есть преимущества. Но они далеко не всегда оправданны.
Потому как конструкция (грубо говоря), echo $string; будет всегда работать быстрее чем
{file.html}

{a}

{file.php}
$class = new templateclass();
if($class->getblock('output')) $class->assign('a',$string);

Более того, оно будет работать быстрее независимо от того, какое кеширование вы туда присобачите.

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

Назовите меня презрительно "Web-мастером", "кодером"... Но я не возьму к себе в отдел на работу человека, у которого в резюме, в первую очередь и большими буквами написано "MVC", "Smarty".
А вот человека, у которого написано "C", "Алгортимика", "Разработка низкоуровневых приложений" возьму с удовольствием (естественно, термин "написано") не надо понимать буквально.

Хотите делать сайты - делайте сайты. Хотите делать сложные системы - делайте сложные системы.

Но не надо делать сложные сайты.

UPD: Да, кстати, - я против шаблонизаторов ничего не имею. Сам пользуюсь. Потому как удобно. Но не монстроподным смарти, а простйшими системами, не умеющими ничего кроме того, что должны уметь: отображать блоки и выводить переменные. И то, я уверен, что это не всегда надо.

спустя 48 минут [обр] Василий М.+(1/171)[досье]

В целом и согласен и нет.

Сейчас сижу на работе и думаю, как бы отсюда уйти. Повежливее...
Первая причина - разработка программ для экономистов - не моё.
Вторая причина - что мне тут светит? Про это поподробнее: я в очередной раз разбираю проект, где опять же, б***ь, вместо красивого и элегантного

$a_row = $myDB->get_rezult('select * from `?` limit 1', $tbl_name, 'assoc');

идёт это:

$result= mysql_query('select * from '.$tbl_nm.' limit 1 ') or print(mysql_error());
$a_row=mysql_fetch_row($result);

в перемешку вот с этим:

print "<tr><td colspan=\"4\" bgcolor=\"#E1E1E3\" height=\"26\">";
print "<font face=\"Times New Roman, Times, serif\" ><strong>&nbsp;Поиск по</strong></font>";
print "</td></tr>";

Я понимаю, что приложение (сайт) должно быть "быстрым, масштабируемым, и работающим", но что для одного разработчика удобно, для другого окажется либо неподъемным, либо до скуки тривиальным. Палка о двух концах.

PS: А когда мы обсуждали "готовые решения" (что очень тесно переплетается с этой темой), меня все били.

спустя 4 минуты [обр] Игорь Лебедев(0/7)[досье]

Видимо наболело у человека :-)
У меня тоже были такие мысли, когда я искал себе шаблонизатор.

Поскольку автор не ставит в теме открытого вопроса, то вот что я думаю:

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

Сам я на perl'е работаю, очень он мне импонирует, использую CGI::FastTemplate и свой фрэймворк. Проще некуда! :-)

спустя 7 минут [обр] Давид Мзареулян(31/1003)[досье]

Дмитрий Попов[досье]

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

Сайт должен быть быстрым, масштабируемым, и работающим.

Противоречие выделено мной. Сайт а-ля визитка/каталог, сделанный на конкретный заказ и без сопровождения (таких и в самом деле большинство) не требует масштабируемости. Он годами будет висеть в том же виде, а когда его захотят переделать, то скорее всего перепишут полностью. Тут шаблоны и прочие MVC не нужны.

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

спустя 3 минуты [обр] Дмитрий Попов(15/509)[досье]
Давид Мзареулян[досье]
Да, я, скорее всего, несколько неправильно выразился в терминах.
В целом примерно это я и имел ввиду.
спустя 5 минут [обр] Василий М.+(1/171)[досье]

Игорь Лебедев[досье] Шаблонизаторы как раз в большинсте случаев и есть главная причина тормозов и неуклюжести. И для средних и малых проектов они не нужны, особенно в PHP, ибо как знают многие избранные, PHP сам превосходно выполняет роль шаблонизатора. Главное — уметь правильно его использовать.

Смотря многие темы понимаешь, что в том же PHP Smarty - действительно заблуждение. И использование шаблонизатора к вопросу масштабируемости проекта — относится, но это не настолько, что бы судить о расширяемости проекта по шаблонизатору.
 
Масштабируемость проекта — это удобство, качество и функциональность всего движка, в целом. Структуры и кода программы.

спустя 36 минут [обр] Андрей Брайнин(3/127)[досье]

"лучше"-"хуже", "усложняют"-"упрощают" - это все субъективные ощущения. если вам удобней и удается работать "без наворотов" - прекрасно.
лично мне удобней оперировать понятиями моделей, контролов, контроллеров, видов.
и разрабатывать даже самый простой сайт я начну с выделения сущностей предметной области с их последующей инкапсуляцией в объекты, к которым я буду обращаться в шаблонах. потому что лично мне так и удобней и проще и быстрее.

P.S.

  1. на собственном опыте убедился в справедливости первого пункта вот этого документа:

http://badyam.ru/programming/design/ThinkingInJava/AppendixC.html

  1. в поддержку людей, у которых в резюме все-таки написно "MVC":

не возьму к себе на работу человека у которого в резюме написано "PHP" (наличие этих трех букв в резюме уже большой минус), и при этом нет никаких слов, компенсирующих этот недостаток - ООП, MVC, ORM и т.п. :)

спустя 1 минуту [обр] Андрей Пахомов(8/310)[досье]
Шаблонизаторы как раз в большинсте случаев и есть главная причина тормозов и неуклюжести. И для средних и малых проектов они не нужны

о как... Для больших, значит проектов, когда все и так тормозит без шаблонизатора, то его использовать надо, а вот в маленьких и средних, которые отрабатывают на раз, и где один коннект к базе весит больше чем все отработка шаблонизатора вместе с запросами - мы должны отказаться от его использования, экономя на спичках. А смысл, извините в этом случае использовать разные подходы в применяемых методиках ? Чтобы потом, в случае внезапного прихода клиента с просьбой поменять дизайн сидеть и плеваться, отделяя зерна от плевел ? Да, этого может и не быть, но если есть наработанный инструментарий, позволяющий быстро и гибко делать сайты любой сложности - зачем отказываться от него, в попытке ускорить то, что не тормозит и так, и тратить на это свое время. Лично я, как разработчик, который делает сайты различной степени сложности, предпочитаю делать все рамках одного выбранного мной подхода - в данном случае, используя Smarty и делая контроллер ведомым. По крайней мере, это гарантирует, что я имея в этом богатый опыт смогу гораздо точнее оценить объем работ и сроки, чем если бы я скакал между подходами и для разных проектов могу использовать одни и те же наработки не задумаваясь о совместимости.

И использование шаблонизатора к вопросу масштабируемости проекта — относится, но это не настолько, что бы судить о расширяемости проекта по шаблонизатору.

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

В общем, мое результирующее ИМХО -нет смысла делить сайты на простые и сложные, чтобы использовать для них разные подходы при разработке(шаблоны vs echo), потому как в одном случае мы разницы просто не почувствуем, а во втором поимеем проблем с поддержкой. Пока писал, Андрей уже сказал то же самое, только короче :)

спустя 52 минуты [обр] Дмитрий Попов(15/509)[досье]

Опять не о том говорим. Я не имею ничего против MVC (хотя имею многое против Smarty). Для своих задач - пусть используется.

И против проектирования ничего не имею.

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

Андрей Пахомов[досье]
Я помню, как-то правил проект на PHP, который сделал человек, позже ушедший в Java-разработчики.

Что бы исправить одну мелкую ошибку, надо было перескочить через четыре полупустых класса, оттуда выйти на псевдо-интерфейс, и только там увидеть функцию.

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

Так вот, к чему это я. К том, что в недокументированном коде, использующем сложные объектные подходы, я твердо убежден, как правило разбораться гораздо сложнее, чем в линейном простом, но при этом грамотно написанном.
Безусловно и там и там есть исключения.
Но я не понимаю, откровенно не понимаю, когда на сайте, представляющем из себя набор текстовых лент, для генерации одной от начал до конца необходимо перелопать пять классов. И это не считая абстракции.

При том, повторюсь, я уверен, что человек, писавший этот код, действительно неплохо знает проектную область. Более того, потратив две недели только на разбор кода, я таки понял идеологию, и признаю, что система масштабируема. Прьблема в том, что я потратил две недели, на проект, которым год никто не занимался. Сделал 3-часовые правки. И им еще год никто заниматься не будет. А потом опять две недели потратят вместо трех часов.

спустя 1 час 32 минуты [обр] Андрей Брайнин(3/127)[досье]
Однако я однозначно против технологий, которые призваны упростить разработку, а на деле усложняют её.

Во-первых, технологий великое множество, а во-вторых оценки технологий субъективны.
Что кажется сложным Вам, покажется простым Вашему товарищу. И наооборот.
Это утверждение касается и разбирательства в чужом коде.
Вы лишь выбираете ту технологию, которая удобна Вам.
Если кажется сложным и нецелесообразным разбираться в ОО-коде - используйте процедурный, набирайте соответствующих спецов и живите в счастье :)

Кстати, похожая тема недавно обсуждалась вот здесь:
Функциональный и классовый подход

спустя 45 минут [обр] Thirteensmay(3/157)[досье]
Дмитрий Попов[досье] Есть такое дело... ;) сам такой... Но куда тут денешся ? Некоторые просто привыкли так работать, комуто удобно, комуто лень, а ктото просто слабо понимает что делает. Подавляющее количество задач не требует никаких ухищрений и может быть написано очень просто, и даже код вместе с версткой. Но на практике большая часть из них значительно переутяжелены в силу вышеописанных причин. Да, конечно, есть 5-7% (может немного больше) тех задач в которых без этого нормально не обойтись, но остальная масса то... ;) и XML сюдаже, и иже с ним... Кроме усложнения понимания и тормозов, в этом случае не менее поганым моментом являются дополнительные требования к базовому ПО - как посмотришь - боже мой, сколько всякой гадости тащится в след, которая там нафиг ненужна... начинаеш все это ставить - конфликты... бр-р-р... IMHO проблема в том что многие страдают необоснованной гигантоманией - делают то что интересно а не то что надо, а некоторые просто незнают как можно сделать проще, еще много таких которые делают так как им сказали... Поглядите как у нас сейчас учат большинство студентов (лучше бы вообще не учили) - VB, СBuilder, CASE - я его родственник ;) И чегоже Вы в результате хотите ? Алгортмизации - практически ноль, в лучшем случае немного математики. Чтобы написать простую толковую вешь - надо много думать (анализировать, оптимизировать), а кому оно надо ? проще в вижалах мышей тыкать и плодить тучи ничегонеделающих классов - на всякий случай - иного не умеем-с... И не говорите мне "Java" - тошнит уже, хотите чтобы еще и воняло ? Еще немного и я начну ее целенаправленно угнетать, слава богу работаю в таком месте что у меня получится ;)
Андрей Брайнин[досье] Проблема не в выборе технологии, а в том что приходится болтаться в куче барахла, и многие при этом утверждают что это барохло - счастье, и никуда не денешся, приходится... Вон, поставил вчера ASDSee 8 - мля, она запускается на 2 гигагерцовом камне 10 секунд... а в DOSe на 20 мегах - запускалась мгновенно... зато она вся такая крутая... обьектовая...
спустя 4 часа 34 минуты [обр] Andrey Nikolaev(0/4)[досье]

Использование фреймворков с поддержкой OOP/MVC/ORM значительно ускоряет разработку даже самых простых сайтов. Я согласен, что смарти - зло. Но не надо интерполировать "смарти=зло" на все остальные инструменты и технологии.

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

p.s. http://www.rubyonrails.org/screencasts - all 'evil' in one place ,-)

спустя 15 минут [обр] Давид Мзареулян(31/1003)[досье]
Andrey Nikolaev[досье] У PHP с фреймворками, мягко говоря, хреново…
спустя 12 часов [обр] Дмитрий Попов(15/509)[досье]

Andrey Nikolaev[досье]
Мой меня абсолютно устраивает. Но там, увы ни Смарти, ни MVC.

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

Давид Мзареулян[досье] Во-во =(

спустя 6 часов [обр] Давид Мзареулян(31/1003)[досье]
Дмитрий Попов[досье] Скорее, PHP для неё плохо применим. И вообще для развитой ОО-разработки. Что, конечно, плохо.
спустя 3 часа 6 минут [обр] Дмитрий Попов(15/509)[досье]

Давид Мзареулян[досье]
Я именно это и писал:

Тем более когда на этот язык переносятся решения с совершенно другой, специализированной платформы (плевок в сторону переквалифицировавшихся жаверов).

Ну нет в PHP много того, что есть там. Зато есть многое другое.
И все это надо использовать тогда где надо и там где надо.

спустя 4 часа 31 минуту [обр] Владимир Михайленко(1/33)[досье]

Порадую и я вас, что ли :)

Повторюсь. Здесь есть многое то, чего нет там. То, чего нет там и есть здесь - используйте здесь. А то то, что есть там здесь не катит.

> величайшее заблуждение всех времен и народов.
свежайшее: http://phorror.livejournal.com/16384.html . В PHP в последнее время много величайшего.

> Прьблема в том, что я потратил две недели, на проект, которым год никто не занимался. Сделал 3-часовые правки. И им еще год никто заниматься не будет.
В этом виноват MVC, Smarty, ООП... Что еще?

Вы писали:
>Сайт должен быть быстрым, масштабируемым, и работающим.
потом:
> Более того, потратив две недели только на разбор кода, я таки понял идеологию, и признаю, что система масштабируема.
И так далее. И хочется, и колется...

ЗЫ Поначалу (да и сейчас) ощущение что это все шутка...

спустя 9 часов [обр] Дмитрий Попов(15/509)[досье]
сообщение промодерировано

Phlinten[досье]
Лично я исторически не слежу за модными веяниями. Со смарти я работал. Сам болел этой системой ровно три года назад. Т.ч. моё мнение вряд-ли можно назвать голословным (хотя несогласиться вполне можно).

> В этом виноват MVC, Smarty, ООП... Что еще?
В этом виновата болезнь разработчика явой и Страуструпом. Причем болезнь паталогическая. Использование всего этого с откровенным перебором.

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

спустя 2 часа 8 минут [обр] Thirteensmay(3/157)[досье]
> В этом виновата болезнь разработчика явой и Страуструпом. Причем болезнь паталогическая. Использование всего этого с откровенным перебором.
-> Да, я знаю таких больных лично, но проблема далеко не только в этом, причин множество... В плане решения невозможно несогласиться с предыдущими высказываниями по поводу выбора технологии, но это не панацея потому как многие делают этот выбор исключительно в свою пользу, а результатами пользуются другие, и хаить их за это глупо... На выходе имеем то что имеем - скажем так разнообразие ;) и это IMHO не плохо, за исключением опять таки вышевысказанных минусов. Вобщем то это уже философия, да этот мир таков, всегда есть выбор и соответственно вы его никогда не сделаете однозначно... А что касается конкретного случая, считаете что Smarty - зло, ну и ату его... А если немогете то можно повыть на луну... и Java никуда не денется... В чем проблема ?
спустя 2 часа [обр] Александр Самойлов(5/342)[досье]
А я-то думал, что такое жаверские технологии.
Что характерно и в yandex и в google по слову жаверские находится только эта тема.
спустя 15 минут [обр] Дмитрий Попов(15/509)[досье]
спустя 1 час 1 минуту [обр] Старынин Валерий(2/57)[досье]
А кто может поведать про ведущие и ведомые контроллеры?
спустя 1 час 12 минут [обр] Василий М.+(1/171)[досье]
Я
спустя 2 часа 49 минут [обр] Старынин Валерий(2/57)[досье]
Василий М.[досье] Поведайте, плз!
спустя 1 час 41 минуту [обр] Владимир Михайленко(1/33)[досье]

Это отдельная тема, но... Ведущий контроллер вызывает что-то. В случае же ведомого контроллера, что-то вызывает контроллер.

Например, ведущий контроллер обрабатывает запрос пользователя, засовывает сгенерированные данные в шаблон и рендерит его (шаблон). В случае ведомого контроллера, шаблон вызывает контроллер, тот обрабатывает запрос и возвращает данные в шаблон, а шаблон решает, что с этими данным делать. Все, как всегда, свелось к тому, кто кого имеет :) Считается, что с ведомым контроллером система получается гибче. Но в случае
> что должны уметь: отображать блоки и выводить переменные. И то, я уверен, что это не всегда надо.
ведомый контроллер отпадает.

спустя 2 дня 6 часов [обр] Владимир Палант(80/4445)[досье]
! Phlinten[досье]
Офф-топик удален. Устное предупреждение — отвечайте в тему лишь в том случае, если вам есть, что сказать.
спустя 8 минут [обр] Владимир Палант(80/4445)[досье]
Однако я однозначно против технологий, которые призваны упростить разработку, а на деле усложняют её.
Да, разработчиков таких framework'ов нередко заносит — они начинают гнаться за универсальностью, абстрагируются от всего, и при этом упускают из виду, что в результате пользоваться их творением становится абсолютно невозможно. Именно такое впечатление у меня создалось к примеру от Java 2 Enterprise Edition — попадаются очень перспективные идеи, но в конечном счете разработка приложений усложнена до абсурда, а программа бОльшую часть времени занимается самоорганизацией. Как оказалось, такое впечатление возникло не только у меня: Joel Spolsky: Why I Hate Frameworks
спустя 25 дней [обр] Даниэль Алиевский(9/125)[досье]

Дмитрий Попов[досье] Поддержу вас, пожалуй. Полагаю, что вовсе не всегда грамотный и чудесно продуманный ООП-проект лучше корявого, но маленького линейного процедурного кода. К счастью, время от времени приходилось работать в обоих стилях. Со временем вырабатывается интуиция, какой подход лучше применить. Например (хотя формулировки интуицию не заменяют): если предполагается дальнейшее активное развитие проекта, причем не очень ясно, что, собственно, должно получиться в конце концов, то желательно тщательно продумать архитектуру и по максимуму использовать известные технологии и шаблоны проектирования. А вот если надо решить абсолютно конкретную задачу, пусть даже сложную, то процедурный подход вполне себя оправдывает.

Среди множества случаев приведу пример WebWarper - вы бы пришли в ужас, узнав, насколько неправильно он написан. Perl, чудовищные процедуры с массой параметров, ветвлений и regexp-ов. Но задача конкретная и четко определенная! Дальнейшие усовершенствования вот уже много лет сводятся к дописыванию (или удалению) десятка-другого строк. Да, в силу плохой архитектуры, иногда приходится тратить часы, чтобы понять, как и почему работает кусок моего же собственного кода. Но эти часы приходится тратить, грубо говоря, раз в месяц. Зато тривиальность архитектуры гарантирует, что при этом ничего не будет испорчено, а сама архитектура не потребует переделки. Уже не говоря о времени, которое бы пришлось затратить на создание этой самой архитектуры.

Есть и прямо обратный пример. Недавно я разрабатывал универсальную библиотеку работы с изображениями (Java). Достаточно универсальную, чтобы с ее помощью можно было обрабатывать изображения любой разрядности (8, 16, 32 бита, int/float), цветности (битовые, полутоновые, RGB, HSV и т.д.) и представления в памяти (массив, мапируемый файл, "внешний" объект вроде стандартнго класса BufferedImage). Да, тут без грамотной архитектуры - никуда, ибо предполагается наполнение библиотеки громадным количеством возможностей, пока даже неизвестных. Но усилия потребовались поистине титанические, и несмотря на это работу довести до конца пока не удалось. Пока используем (очень успешно, уже много лет) более старый вариант библиотеки, тоже неплохо спроектированный, но работающий только с 8-битовыми изображениями (256 градаций каждой цветовой компоненты).

В общем, holy war тут неуместны, по-моему. Каждой ситуации - свой подход. А лучше всего научиться обоим подходам, чтобы грамотно выбирать между ними.

Кстати, в последнее время использую собранный "на коленках" "шаблонизатор" (если я правильно его назвал). Маленький препроцессор на Perl, позволяющий управлять HTML-файлами вместо SSI. Мне очень удобно, я радуюсь и иногда (в последнее время очень редко) пополняю его новыми возможностями. Первый вариант написал за день или два. Вот он: Собрал "на коленках" некий инструмент верстки - вдруг пригодится? Что характерно, пока никто пользоваться не хочет :)

спустя 18 часов [обр] Александр aka Efreeti(3/111)[досье]
если предполагается дальнейшее активное развитие проекта, причем не очень ясно, что, собственно, должно получиться в конце концов, то желательно тщательно продумать архитектуру

В таком случае я бы использовал XP , т.к. если задача до конца не ясна, если этап анализа не прояснил ситуацию, то тогда время, потраченное на проектирование, может пропасть зря, т.к. изменяться требования.

Впрочем, извиняюсь, это уже совсем оффтоп.

спустя 20 часов [обр] Thirteensmay(3/157)[досье]
Если не ясно, что, собственно, должно получиться в конце концов, то надо...
Вот это да мужики... аж до слез ;) Если не ясно - НАДО ПРОЯСНЯТЬ ! а не заниматься туфтой. Вот какраз из за такого подхода и получаются монстры - человек просто не понимает что он делает, я уже об этом писал.
Александр aka Efreeti[досье] Просветите пожайлуста темного в краце что есть XP, жуть как интересно ;)
спустя 2 часа 25 минут [обр] Алексей Севрюков(13/1280)[досье]
Thirteensmay[досье] eXtreme Programming :-)
спустя 4 часа 21 минуту [обр] Александр aka Efreeti(3/111)[досье]
Thirteensmay[досье]
Не всегда можно прояснить до конца, чтобы проектировать всё и сразу.
Впрочем, тут уже получиться holy war, поэтому я думаю стоит свернуть этот оффтопик.
спустя 1 день 18 часов [обр] Даниэль Алиевский(9/125)[досье]

Thirteensmay[досье]

Вот это да мужики... аж до слез ;) Если не ясно - НАДО ПРОЯСНЯТЬ ! а не заниматься туфтой.

Эй, давайте поспокойней :) Бывает так, а бывает эдак. Я ведь привел конкретный пример. Универсальные библиотеки для представления, хранения и обработки изображений. Ну как я могу "прояснить", какие именно свойства библиотеки будут максимально востребованы через 5 лет? Способность к распределенным вычислениям? float-овская точность представления? Легкость интеграции с другими библиотеками, которые, может быть, появятся и окажутся очень ценными? Преодоление 4-гигабайтного барьера нынешних 32-битных OS? (Вдруг уже через пару лет мы все будем "жить" в 64-разрядном мире и спокойно пользоваться RAM на 16 GB.) А библиотеки пишутся, чтобы ими пользовались многие годы, иначе работа просто не окупается. Вот и стараешься предусмотреть максимум случаев, делая библиотеки максимально гибкими. Здесь ООП и шаблоны проектирования очень полезны.

Сейчас вот проблема старых библиотек - ограничение 8 битов на цветовую компоненту. 10 лет назад, когда они первоначально создавались, казалось маловероятным, что устройства ввода будут работать с 16-битовой точностью. Тогда даже true-color-режим (3*8 битов) казался чем-то крайне экзотическим. Зато была потрачена масса усилий, чтобы преодолеть барьер DOS в 640 KB (своя "виртуальная память"). Грамотно построенная, гибкая технология позволяет минимизировать потери на "напрасный труд" такого рода.

спустя 21 час [обр] Thirteensmay(3/157)[досье]
Ну да, это Вы себе представляете зачем оно нужно... Думаете все так поступают ? А тщательный анализ позволяет минимизировать потери на "напрасное проектирование" ;) И чем система проще, тем с ней легче...
спустя 10 дней [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]
сообщение промодерировано

У нас в компании сейчас разработан (и продолжает разрабатываться) свой FrameWork. С безумным количеством модулей, со своей специфической архитектурой (напоминающей самостоятельную ОС).
На нем работает очень много сайтов. Большинству из них достаточно уже разработанных модулей. Для некоторых разрабатываются специфические модули.
Все это "завязано" на не самый быстрый для PHP XML+XSLT.

Но:

  1. В силу отлаженности архитектуры разработка простого модуля занимает меньше времени, чем возможное написание его же "с чистого листа прямым кодом". И написанный однажды модуль может в последствии нативно использоваться в любом проекте. Это масштабируемость. И объектная ориентированность.
  2. Многоуровневое кеширование позволяет достаточно быстро обрабатывать вывод. И делать как динамические и статические страницы, так и "смешанные". Оно же позволяет оптимально понижать нагрузку на отдельные компоненты системы.
  3. "Свой язык разметки" значительно упрощает и стандартирует разработку интерфейсов
Хотите делать сайты - делайте сайты. Хотите делать сложные системы - делайте сложные системы.


Но не надо делать сложные сайты.

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

Сложен ли сайт, в котором в CMS на нужных страницах размещены спец-теги?
Сложен ли сайт в котором у администратора есть простой интерфейс для управления доступными ему модулями?

спустя 3 дня [обр] Алексей Пешков(0/19)[досье]

Поднято два вопроса:

  1. "монстроподобные" шаблонизаторы

Есть тьма шаблонизаторов разной степени популярности — можно сделать вывод, что задача, которую они пытаются решить, пока не имеет зрелого решения. То же самое можно сказать про PHP-фреймворки. Смешно устраивать религиозные войны из-за одной из библиотек для реализации одной из задач веб-программирования.

  1. "всякие паттерны MVC, "трехуровневые модели" для классических Web-проектов". Сайт должен быть ..., ..., и работающим.

"Код, который не тестировался — не работает". К сожалению, линейно-процедурная альтернатива не позволяет использовать такие современные методики разработки, как автоматизированное модульное тестирование.

спустя 13 часов [обр] Сергей Чернышев(39/589)[досье]
Вопрос, а зачем нужен PHP если к нему еще и шаблонизатор нужен?
спустя 7 часов [обр] Давид Мзареулян(31/1003)[досье]
Сергей Чернышев[досье] Зачем нуже PERL, если к нему ещё и шаблонизатор нужен? Или Вы пишете в стиле print "<h1>Hello, world!</h1>";?
спустя 5 часов [обр] Сергей Чернышев(39/589)[досье]

Давид Мзареулян[досье]
Ну, на данный момент все объективный аргументы в пользу PHP (со стороны его фанатов ) против Perl-а для меня сводились к всегда доступному ядру функций и тому что можно прямо в HTML-е код писать. Если нужен шаблонизатор то нет ни того ни другого.

Что касается Perl-а, то там изначально сразу после установки меньше зашито в ядро (все доступно через модули и пр.) и нельзя внутри HTML-а писать код (если сразу не поставлен ePerl или его аналог) - против этого я никогда и не спорил, а все остальное там всегда было и есть - от разных шаблонизаторов, фреймворков, модулей под все случаи жизни и до mod_perl-а.

Так что ваш аргумент не актуален.

спустя 27 минут [обр] Давид Мзареулян(31/1003)[досье]
Сергей Чернышев[досье] Вам просто не повезло с собеседниками-«фанатами»…
спустя 2 часа 49 минут [обр] arto(3/494)[досье]
а где можно ознакомиться с не-фанатскими аргументами?
спустя 1 час 28 минут [обр] Давид Мзареулян(31/1003)[досье]
На мой скромный взгляд, если человек понимает, что такое шаблоны и зачем они нужны, или хотя бы вообще понимает MV(C)-идею, то ему (этому человеку) должно быть совершенно всё равно, какой язык используется — хоть PHP хоть Java.
спустя 7 часов [обр] Сергей Чернышев(39/589)[досье]
arto[досье]
+1 хотелось бы услышать свежей аргументации от нефанатов, а "знатоков дела".
спустя 2 часа 55 минут [обр] Василий М.+(1/171)[досье]

Давид Мзареулян[досье]
Тем не менее, все говорят, что Смарти - это "круто", но кто реально может объяснить, чем функции шаблонизации в Смарти хуже самих функций шаблонизации в PHP?

- Конструкции управления
- Директива подключения include и require
- ob_start etc...

-- всё это есть в PHP.

Я когда спросил у гениальных веб-программистов на своей работе, я не получил НИ ОДНОГО ответа почему Смарти лучше. В ответ было лишь мычание типа "Ну это же удобно..".

Удобно что? Юзать псевдоязык, который ещё и коряв до немогу?
А потом генерировать этим языком PHP-код?
Бугага!!

спустя 1 час 42 минуты [обр] Андрей Пахомов(8/310)[досье]

Василий М.[досье]
да основной плюс Смарти в том, что он достаточно прост для непрофессионала... Конечно, я понимаю, что сайты должны делать высококвалифицированные специалисты, но где вы найдете грамотного верстальщика которого не смутит PHP-код в шаблоне и который на раз не поломает ваш код стерев точку с запятой ? Чтобы не было разговоров о том, что мол де мелкие проекты в верстальщиках не нуждаются, там достаточно одного программиста, а в крупных можно и найти такого верстальщика , который помимо верстки еще и пых знает, приведу один пример:
я сотрудничаю с одной мелкой дизайн-студией, которая помимо всего делает своим клиентам сайты. Сайтов мало, он все не очень сложные и крупные, поэтому программист им как таковой не нужен, и когда у них возникает потребность сделать сайт они просто покупают у меня CMS систему, на базе которой создают сайт. Поскольку там ведомый контроллер, то для того чтобы реализовать пользовательскую логику им достаточно одной доки по Smarty и краткого описания пары самописных модулей. Все. Человек, никогда до этого не имевший дела с программированием освоил это за пару недель, при этом он даже не подозревает о той куче функций и наворотов, которые предоставляет PHP, потому как это ему не нужно. Совсем.
Ваше стремление к эффективности не подразумевает того простого факта, что народ стремится к удешевлению продукта, и использование Смарти - один из способов сделать продукт дешевым. Если бы вы искали себе верстальщика и сравнили уровень зарплат верстальщиков со знанием PHP, или без оного, то я думаю у вас отпало желание утверждать что Смарти - это зло. Просто нельзя подходить к использованию инструмента или технологии только с точки зрения программиста. Иначе мы рискуем скатится на уровень спора: PHP vs Java, VC vs VB и пр. Глупо сравнивать что либо не учитывая экономическую составляющую, потому как именно она и является определяющей. Что у вас первым делом спрашивает заказчик ? Какую технологию вы планируете использовать для создания его сайта ? НЕТ ! Он спрашивает, а сколько будет это стоить ? Вот от этого и пляшите, тогда не будет появляться вопросов, нужно ли использовать ООП, Смарти или PHP. Посчитаете цены и все встанет на свои места. А эти возгласы - мое кунг-фу круче вашего - это дилетанство.

PS. Все вышесказанное - мое ИМХО и личный опыт, так что просьба не воспринимать как наезд.

спустя 9 минут [обр] Алексей Севрюков(13/1280)[досье]
Вроде бы в теме не упоминалось что скорость разработки проекта с использованием хорошего шаблонизатора больше на порядок. Не знаю как в PHP, а в Perl точно.
спустя 13 минут [обр] Давид Мзареулян(31/1003)[досье]
Сергей Чернышев[досье] Про шаблоны я уже ответил. А агитировать за PHP я не собираюсь — язык как язык, для веб-применений не лучше и не хуже любого другого.
спустя 34 минуты [обр] Дмитрий Попов(15/509)[досье]

Мне кажется проблема опять же в однобокости, все-тики.

когда смарти используется как обычный пассивный шаблонизатор, я, например, тоже считаю это извращением еще тем...
Когда же смарти используется для реализации MVC модели - тут уже вопрос в другом: Зло или не Зло MVC?
Но про именно смарти здесь говорить уже неправильно.

спустя 1 день 4 часа [обр] Thirteensmay(3/157)[досье]

А ну хотите можно в раз обосновать что никакой однобокости нет - былобы желание ;) а можно и совсем наоборот. Я вот PHP вообще не пользую, и не испытываю при этом никаких проблем, но это не значит что PHP безполезная фигня. Тут как уже было отмечено не может быть однозначного решения, да и вообще, делать однозначные решения - как минимум страшно ;) Однако есть всякие разные предрасположенности... Так что IMHO все как обычно - под задачу. Остальное - холивар. Изначально вижу эту тему лишь в плане вопроса необоснованного распухания проектов, и тут получилось что квалификация разработчика/пользователя и технико-экономические условия ;) не всегда позволяют обойтись без этого даже в той подавляющей массе случаев когда можно былобы обойтись. Ну чтож остается только сожалеть об этом и разгребать местами кучи сопель, ну не может же быть все идеально ;) Из последних постов улыбнуло следующее:, спасибо авторам за настроение ;)

У нас в компании разработан (и продолжает разрабатываться) свой FrameWork. С безумным количеством модулей, со своей специфической архитектурой (напоминающей самостоятельную ОС). Многоуровневое кеширование позволяет достаточно быстро обрабатывать вывод, Любой сайт, постоенный на нашей системе, прост...

- О да ;) знакомо, "Обнаружен новый пользователь, вставте диск с программным обеспечением пользователя и откиньтесь...". А мы тут давеча разбирали одну систему и выкидывали всякую дрянь потому как тормозило жутко, особенно невпопадное многоуровневое кеширование. Она была признана неадекватным сложным монстром, как Жаба. Но деньги папе таскала успешно...

Код, который не тестировался — не работает". К сожалению, линейно-процедурная альтернатива не позволяет использовать такие современные методики разработки, как автоматизированное модульное тестирование.

- Великолепный тонкий стеб, спасибо, люди с извращенным понятием модуля отдыхают... ;)

Смарти - один из способов сделать продукт дешевым. Что у вас первым делом спрашивает заказчик ? Какую технологию вы планируете использовать для создания его сайта ? НЕТ ! Он спрашивает, а сколько будет это стоить. И где вы найдете грамотного верстальщика которого не смутит PHP-код в шаблоне и который на раз не поломает ваш код стерев точку с запятой

- Реклама - искусство одурачивания с сокрытием косяков. Уж договаривайте что заказчику придется доделывать самому, и если че без Вас он никуда не денется ;) И ненадо про тупых верстальщиков, здесь не полные идиоты сидят - во первых специфика работы верстальщика подразумевает гораздо больше мозгов чем хватит на убиение кода - иначе он верстать не сможет даже если ему код в руки не давать, а во вторых нахрена ему код вообще давать, скрытие на раз реализуется классическими методами вообще без шаблонов. Ну и напоследок: по опыту знаю что все эти шаблоны, ООП, MVC и прочие CASE приводят к разрастанию (требований, объема, трафика, геморроя и пр.), хотя конечно в некоторых редких случаях без них не обойтись, но в основе повторюсь - запросто. Так вот, конечному потребителю как правило не говорят о том что потребуется модернизация существующей инфраструктуры, а это бабки несравнимые с вашей мизерной экономией.

P.S. Народ хочет денег, халявы и готов ради этого на подвиги, не всегда конечно, но бывает... Без желания кого либо оскорбить, просто к сведению начинающих чтобы не попутали ;) Для тех кто в танке - основная идея: Сначала четко определяемся что делаем, потом оптимизируем, и только тогда рожаем вещь. Иначе - будет пухнуть все что на это способно. По поводу "не всегда удается понять чего хочется" - умолчу ;) Случай кошения бабла - отдельный там свои законы (точнее их отсутствие), и здесь не рассматривается (хотя народ пытался). Я не против шаблонов, ООП, MVC и пр. - а лишь за их целесообразное использование.

спустя 17 часов [обр] Андрей Пахомов(8/310)[досье]
Реклама - искусство одурачивания с сокрытием косяков. Уж договаривайте что заказчику придется доделывать самому, и если че без Вас он никуда не денется ;)

Зачем ему надо что то самому доделывать ? Вы о чем ? Сайт делают программисты, верстальщики, дизайнеры и пр, но никак не сам заказчик. Ему вообще фиолетово, что и как вы там делаете, лишь бы это отвечало поставленным им целям. И ему не нужно знать, что сайт написан на PHP, использует MySQL и шаблоны отрабатывают на Смарти. Никто не будет рассказывать закачику, что мол де все будет дешево и быстро, потому как мы иcпользуем MVC и Smarty - это все равно ему ничего не скажет. Просто у кого-то получается делать сайты быстро используя эти вещи, и медленнее - если не использовать.

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

Ух ты! Вообще то речь шла о людях, которые не сидят на xpoint.ru, и которые не являются профессиональными верстальщиками. Таких хватает, сам встречал. И можно поподробнее о сокрытии кода без шаблонов классическими методами ?

спустя 3 часа 26 минут [обр] Thirteensmay(3/157)[досье]

Зачем ему надо что то самому доделывать ? Вы же сами писали:

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

Вот и получается что Ваш заказчик (мелкая дизайн-студия) должна доделать пользовательскую логику конечному потребителю. Я не против Вашей схемы - работает, деньги приносит - отлично :), именно это я и высказал как основную идею своего поста - распухание за счет того что конечной целью является не качество результирующего ПО а получение денег (см. фразу "технико-экономические условия ;) не всегда позволяют...", обр. внимание на смайл). Можно сделать эффективнее, в этом случае отпадет необходимость в шаблонизаторе, двух конторах, добавочной стоимости и лишних людях. Всего то и нужен один нормальный программер ;) завернет он часто используемый функционал в библиотеку, заюзает движек, соберет впрямую - получится быстрее, качественнее, дешевле и пр. Вот только косяк, ни Вы ни Ваша CMS, ни тупой верстальшик никому будут ненужны. Так в чем заключается экономическая эффективность ? и самое главное для кого ? ;)

спустя 4 часа 48 минут [обр] Андрей Пахомов(8/310)[досье]

как то обще у вас все, поэтому выглядит красиво, но только на словах. Что значит - соберет напрямую ? Сам! разверстает дизайн, и влепит туда PHP код, со всеми его прелестями. Допустим, что да, можно все вынести в библиотеку, и в шаблоне будут только вызовы функций и циклы, но и где здесь простота для клиента ? Если ему надо что то поправить или добавить на странице - он сам никогда этого не сделает, все равно к вам придет. А если он решит сэкономить на ваших услугах(допустим у вас ценник высокий), то что - ему нужно брать не верстальщика даже, а программиста, который будет в состоянии понять, как у вас все работает и дописать нужные вещи, что дешевле не будет. А насчет

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

Вас послушать, так все CMS системы, которые присутствуют на рынке - ущербны, потому как предоставляют некие универсальные средства разработки и значит не могут гарантировать качество результирующего ПО. Бред, если честно. Сами то наверняка все с нуля под конкретную задачу не пишете, пользуетесь неким движком, который абстрагирует все низкоуровневые операции и в основном реализуете как раз таки бизнес-логику. Какая разница то по сути, будет ли эта логика реализовываться в шаблонах, или в PHP-файлах. Быстродействие и в том и в другом случае будет определяться не шаблонизатором или его отсутствием, а качеством и продуманностью движка, которому абсолютно безразлично, откуда его методы дергают. Или вас коробит мысль о том, что пользуясь упрощенным языком того же смарти и такого рода CMS, любой студент второго курса сможет писать достаточно сложные сайты за короткие сроки при этом не забивая себе голову всеми премудростями PHP ? Чтобы использовать чужой опыт, много ума не надо, и далеко не факт, что при этом результат будет хуже чем у профи.

Всего то и нужен один нормальный программер ;) завернет он часто используемый функционал в библиотеку, заюзает движек, соберет впрямую - получится быстрее, качественнее, дешевле и пр. Вот только косяк, ни Вы ни Ваша CMS, ни тупой верстальшик никому будут ненужны.

Как раз в моем подходе - нормальный программер требуется только один раз - для написания CMS, потом достаточно 1-го тупого верстальщика, при том, что результаты будут одинаковы, но его оплата будет гораздо меньше. Так что быстрее и дешевле с Вами - ну никак не получится :)

спустя 2 часа 10 минут [обр] Сергей Круглов(35/2057)[досье]

Программеры тоже разного уровня бывают. Один CMS пишет, а другой на ее основе сайты.

Чтоб, к примеру, даже на PHP выбрать из базы все имена и адреса страниц верхнего уровня, пользуясь уже написанной функцией, и нарисовать из них меню, много квалификации не надо.

спустя 14 часов [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]

Thirteensmay[досье]

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

Если у Вас в системе много "всякой дряни" - это вопрос ущербности архитектуры.
Если тормозит кеширование - это проблема ущербности архитектуры возведенная в степень кривизны рук разработчиков.

И не надо путать такие понятия как CMS и CMF.

по опыту знаю что все эти шаблоны, ООП, MVC и прочие CASE приводят к разрастанию (требований, объема, трафика, геморроя и пр.), хотя конечно в некоторых редких случаях без них не обойтись, но в основе повторюсь - запросто.

Написать-то CMF без использования "всех этих" невозможно, иначе будет это уже не CMF, а просто набор библиотек..

спустя 6 часов [обр] Thirteensmay(3/157)[досье]

Андрей Пахомов[досье]

Как то обще у вас все, поэтому выглядит красиво, но только на словах.

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

Что значит - соберет напрямую ? Сам! разверстает дизайн, и влепит туда PHP код...

Да, а что тут такого ? Для среднестатистического программера это элементарно

Если ему надо что то поправить или добавить на странице - он сам никогда этого не сделает

Тупой верстальщик не сделает, а я вам и говорю он тут нахрен не нужен, только ресурсы отжирает

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

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

Вас послушать, так все CMS системы, которые присутствуют на рынке - ущербны. Сами то наверняка все с нуля под конкретную задачу не пишете

Нет конечно ;) Все зависит от задачи, часто CMS великое но обходимое благо ;) иногда - смерть, но распухает от этого в любом случае.

Вас коробит мысль что пользуясь упрощенным языком смарти и такого рода CMS, любой студент сможет писать сложные сайты за короткие сроки не забивая голову премудростями PHP ? Использовать чужой опыт, много ума не надо, не факт, что при этом результат будет хуже чем у профи

Я работаю в учебных учреждениях 7 лет, оно меня не коробит, оно меня зае.ало до потери пульса разгребать эти каши. Люди "не забивая себе голову" такого наворачивают что полсетки ложится от одного захода на их сайт, я уж не говорю о производительности, элементарно выудить материал из системы после того как она лопается дорогого стоит. Что может родить непрофессионал, не забивая себе голову известно, обосновывать этим необходимость смарти и пр. имхо глупо. Результат будет хуже чем у профи - это факт, если в создании системы принимает участие дилетант - это всегда отражается. В общем случае это относится к первой части "квалификация разработчика/пользователя и технико-экономические условия ;) не всегда позволяют" ;)

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

А в моем вообще нужен только один нормальный программер. В ваших условиях когда сайты не сложные, так и вообще весьма средней квалификации. Тупой верстальщик без программера не обойдется, среднему программеру еще один не нужен, у нас такой стоит 5 т.р./мес.

Евгений Бондарев aka Eugene Bond[досье]

Если у Вас в системе много "всякой дряни" - это вопрос ущербности архитектуры. Если тормозит кеширование - это проблема ущербности архитектуры возведенная в степень кривизны рук разработчиков.

Все так, но откуда ущербная архитектура ? - в первую очередь от непрофессионализма, а во вторую от запудривания мозгов. Почитал преподаватель/студент/разработчик о том какую вы мегаклассную штуку сделали и давай зеленым травить, этоже проще чем объяснять как оптимально сделать конкретную вещь, те тоже рады - взял слобал побыстрому и пошел пиво пить, что из этого получается см. чуть выше. Разработчики таких штук о особенностях ;) умалчивают - а именно о том что такими вещами пользоваться надо уметь, а не бездумно юзать. А если уметь то оказывается что В ПОДАВЛЯЮЩЕМ большинстве случаев такие монстры ненужны, как я подозреваю и большинство функционала вашего CMF.

Написать-то CMF без использования "всех этих" невозможно, иначе будет это уже не CMF, а просто набор библиотек..

Возможно ;) я же написал когда диплом защищал ;), это 50кб ядра + 150кб библиотек + 70кб общих инструментов + соглашения об использовании. Прибл. 20% кода - ООП. Может быть с точки зрения функционала не фонтан и сыровато, но модульно, гибкое распределение доступа, единый визуальный интерфейс, подсистема настроек, подсистема единого справочника, модуль PDF, админка, удаленная разработка и пр. если чего не надо - на раз отключается, хоть визуализация, хоть идентификация, хоть другие вкусности. Конечно не чистый CMF а некая помесь CMS/CMF но вполне удобно и гибко, при этом никаких шаблонов/MVC и пр. нет, требования к базовому ПО минимальны - Perl в обчной комплектации, MySQL и один дополнительный модуль - PDF::API2, все... Юзаю, пока доволен, и не один я. Скорость правда не велика, на средненьком целике 3 запр./сек. - дотянем, поэтому пока не засунул нагруженные сервисы типа системы тестирования (имхо отдельная история), но обычные АРМ делаются нормально. Сдается мне что подавляющее большинство задач, особенно после оптимизации эта штука будет способна накрыть, кончно на уровень рамблеров и пр. яндексов не претендую, ну да сколько их таких, остальное - запросто. Вот предвкушаю смеетесь ;) вылез тут со своей фигуличкой, мы такие большие хмурые дядьки, сделали настоящий CMF а тут такая фигня... Да фигня, не куплю я у Вас его, точно также как у била дотнет, потому что фигулички заглаза хватает ;)

Еще раз повторюсь, я не против шаблонов, ООП, MVC и пр. - а лишь за их целесообразное использование. Квалификация разработчика/пользователя и технико-экономические условия/цели ;) не всегда позволяют обойтись без распухания даже в той подавляющей массе случаев когда можно былобы обойтись. - Вот это помоему интересно обсудить а не уперать на технические детали. Я так думаю сюда можно добавить еще коечто, никак не могу уловить из постов что именно, - сформулируйте.
Впрочем пока не появится третий обиженный ;)

спустя 8 часов [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]

Thirteensmay[досье]

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

На то они и студенты. И то, что курсовые на самом деле учат их планировать, проектировать, реализовывать и документировать - они поймут уже гораздо позже.. А опыт, как известно, - сын ошибок трудных..
Ваши студенты же не занимаются разработкой коммерческих продуктов? Тогда они имеют полное право "лабать по-быстрому"!

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

Это касается абсолютно любого аспекта жизни.
Что касается студентов - но, извиняюсь за сравнение, сексом заниматься тоже надо уметь, а не бездумно сунул-высунул.. И почему-то почти все это прекрасно понимают. А те, кто не понимают про секс - понимают про то что надо уметь проектировать-планировать-документировать..

А если уметь то оказывается что В ПОДАВЛЯЮЩЕМ большинстве случаев такие монстры ненужны, как я подозреваю и большинство функционала вашего CMF.

Конечно Васе Пупкину на его "хомяке" кроме CMS ничего не надо. А подавляющее МЕНЬШИНСТВО случаев, когда надо мощную связку из eCommerce+CRM+CMS+RMS (хотя бы 2 из этих ключевых пунктов) - это тот сегмент рынка на который мы ориентируемся. На Пупкина мы не претендуем. Чесное пионерское!

Другой вопрос стоит в том, что PHP только начинает приспосабливаться для таких разработок. Будучи изначально "заточенным" под совершенно другие нужды и цели он сейчас начинает стремительно "стряхивать" с себя весь налет из ламеров-выучивших-весь-пхп-за-два-дня, которые заполонили просторы интернета (отдельная тема для холли варс).

То, что PHP захватывает рынок "тяжелых решений" - это логичная и правильная политика развития. Два-три года назад сложно было бы представить нормальную реализацию на PHP ядра полноценной масштабируемой системы (не CMS ;-)) которая одновременно была бы гибкой, но могла бы работать под большими нагрузками. Поэтому система писалась на Java или .NET.
Сейчас это возможно и очень даже осуществимо.

спустя 2 дня 9 часов [обр] Андрей Пахомов(8/310)[досье]

Thirteensmay[досье]

Да, а что тут такого ? Для среднестатистического программера это элементарно

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

спустя 49 минут [обр] Thirteensmay(3/157)[досье]

Евгений Бондарев aka Eugene Bond[досье]
По поводу студентов: Вас как учили снизу вверх или сверху вниз, пожалуй одновременно в обоих направлениях ? imho сейчас явно наблюдается относительный перекос в сторону сверху вниз, понятно почему ;(, и реализация соответственно смещается тудаже, вчерашние студенты - сегодняшние разработчики. Такчто с таким подходом опять таки imho неоптимальность будет только расти.
А опыт, как известно, - сын ошибок трудных... Что делает современный среднестатистический разработчик когда видит жабость решения - начинает оптимизировать, я предлагаю думать об этом раньше.

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

Да блин ;), причем первые быстрее размножаются со всеми вытекающими...

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

А он об этом знает ? Вообще имхо ценное замечание.
Андрей Пахомов[досье]
Ну как сказать... Нам же тоже чемто кормиться надо ;) Это вовсе не означает что без использования шаблонов, MVC и пр. систему невозможно сделать понятной, как по мне так даже наоборот. Тут похоже кто к чему привык... Модульность, комментарии, нормальную тех. документацию, эффективное использование ООП и пр. никто не отменял, если платят конечно ;), если нет - хай трахаются, помоему это честно.

спустя 1 час 8 минут [обр] Андрей Пахомов(8/310)[досье]
Нам же тоже чемто кормиться надо ;)

С этого и надо было начинать :) А то оптимизация, убирание монстроподобности...

Это вовсе не означает что без использования шаблонов, MVC и пр. систему невозможно сделать понятной, как по мне так даже наоборот. Тут похоже кто к чему привык... Модульность, комментарии, нормальную тех. документацию, эффективное использование ООП и пр. никто не отменял, если платят конечно ;), если нет - хай трахаются, помоему это честно.

это работает только в том случае, если работаете как фрилансер, и сами от начала до конца делаете заказчику сайт. В этом случае, если он захочет сэкономить на вас и попробует обратится к студенту чтобы он доделывал какие то вещи - тогда имеет смысл писать garbage code, в котором разобраться сможете только вы. А если речь идет о работе в компании ? Что, если вы вдруг решили уволиться весь отдел веб-разработки должен вешаться в попытках разобраться что вы там нагородили в процессе работы над проектом год назад ? В общем, как я понял, вы против MVC, шаблонов, ООП и пр. совсем не потому что они не делают сайт маштабируемым и удобным для понимания, а наоборот, в силу того что они это делают слишком эффективно и тем самым позволяют удешевлять поддержку и развитие сайтов отодвигая вас в сторону и давая возможность работать менее квалифицированной (читай: более дешевой) раб. силе :)

спустя 1 час 46 минут [обр] Thirteensmay(3/157)[досье]
Андрей Пахомов[досье]
Не ну Вы меня прям исчадием ада нарисовали ;) То что у меня день рождения 13 мая еще ни о чем не говорит ;) Поясняю - можно по человечи - и оптимально и понятно, за понятно - дополнительная мзда и то по абстоятельствам ;), иначе - просто оптимально. Если меня считают за человека - я даю полную документацию, и готов слегка бесплатно помоч даже если не участвую в проекте. Еслиже меня считают раб.силой я обеспечу максимальный геморрой. Я не против MVC, шаблонов, и уж темболее ООП, сам их пользую (за исключением MVC в чистом виде), но меня бесит когда этим начинают тупо злоупотреблять, и полюбому это распухание. Да, можно использовать тупую раб. силу и покласть на нее в любое время ;) Но от этого надо избавляться потому как не способствует эффективности, и еще кучей косяков отражается. Вы были правы когда обратили внимание на экономическую сторону дела, вопрос с какой точки зрения ее рассматривать...
спустя 2 часа 47 минут [обр] Андрей Пахомов(8/310)[досье]
но меня бесит когда этим начинают тупо злоупотреблять, и полюбому это распухание

со временем это проходит. В смысле, злоупотребление. Особенно если система, написанная единожды эксплуатируется потом в течение большого срока. А если люди изначально руководствуются приницпами XP, то скорее всего и не возникает изначально. Правда, мне пока людей которые бы сходу началали использовать XP, и сразу получали очень хорошие результаты не попадались, но не факт что таких нет :). В общем, чувствую, что если мы будем продолжать диалог в таком же ключе, то это надолго, предлагаю подвести итоги и вести разговор по существу, если оно еще осталось:)

Сухой остаток на мой взгляд:

  1. Есть масса технологий и инструментов типа: MVC, шаблоны и Smarty в частности, OOP и пр. Вопрос в том, что нужно ли их использовать для создания сайтов на PHP и если нужно то, в каких случаях.
  2. Минусы при их использовании (или короче говоря плюсы обычного линейного программирования):

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

  1. Плюсы:

3.1. Сокрытие низкофункциональной логики, что дает возможность сосредоточится на бизнес-логике, что приводит к росту производительности программиста.
3.2. Поскольку для реализации бизнес-логики не требуется глубокого понимания работы низкоуровневых операций имеется возможность использовать менее квалифицированных программистов или верстальщиков без ущерба для качества.
3.3. Изучение базовых классов дает полное представление о том, что может данный CMF/CMS, что позволяет постороннему программисту достаточно быстро разобраться в их возможностях и приступить к реализации новых вещей, в коих возникла необходимость.

Теперь посмотрим, можно ли каким то образом избавится от минусов:
минус 2.1. - для мелких сайтов падение производительности некритично, для крупных - как правило раньше всего начинает торзмозить БД, поэтому оптимизация запросов и переход на более мощные БД дает больший прирост производительности чем отказ от вышеперечисленных технологий.
2.2. это лечится граммотным проектированием (либо использованием XP)
2.3. в приницпе этот минус как таковой можно не рассматривать. Если имеется привычка строить сайты используя ООП и пр. то смысла отказываться от них и сбивать руку упрощая и отптимизируя все под клиента, который к тебе не вернется я не вижу. На производительности это сильно не скажется да и, еще раз повторюсь, не критична она в этих случаях.
2.4. Вот единственное, что может заставить человека, пишущего код, как заправский обфускатор, отказаться от использования ООП и пр. :) Правда есть eaccelerator.

спустя 3 часа 12 минут [обр] Даниэль Алиевский(9/125)[досье]

Ну вот, это уже можно читать. Спасибо, Андрей :)

2.1. Падение производительности мне как раз кажется сомнительным фактором. Грамотное применение ООП к этому обычно не приводит. А вот раздувание кода - это проблема. Если задачу можно полностью решить линейным скриптом из 300 строк, вряд ли стоит вместо этого реализовывать универсальное расширяемое решение из 300 методов различных классов.
2.4. Ну какой же это минус. Разобраться в ООП-коде куда сложнее, по моему опыту :) А писать его непонятно на порядок легче :) ООП упрощает чтение и анализ только после некоторого стартового времени, потраченного на изучение общей архитектуры, системы понятий и т.д. И только при условии соблюдения всех вспомогательных правил, вроде грамотного выбора идентификаторов и тщательного документирования.

3.1. Я бы добавил: рост производительности программиста имеет место только для большого проекта, когда важно повторное использование кода и быстрая модификация готовой системы. Реализовать 20-страничный сайт (или утилиту сбора специальной статистики) куда быстрее в "линейном" подходе.
3.2. Вот тут в принципе не согласен. Для поддержки ООП-проекта необходима достаточно высокая квалификация исполнителей. Безответственная работа с ООП-модулями может очень быстро запутать систему до невозможности. В линейном подходе все не так: к конечной 300-строчной write-only утилите предъявляется лишь одно требование, чтобы она работала. Если программист неквалифицированный, и в будущем поддерживать утилиту не удастся, что ж - столь же быстро другой программист напишет эквивалентную 300-строчную утилиту.
3.3. Добавил бы: при условии, что базовые классы грамотно спроектированы и документированы (что требует очень высокой квалификации).

Мне кажется, есть и куда более важные плюсы. Скажем, гибкость. Обычно простой заменой модуля можно радикально изменить поведение системы, как только это потребуется. Или надежность: при грамотном проектировании можно изначально исключить возможность очень многих ошибок. Или масштабы: таким способом можно разрабатывать большие системы, в принципе неподъемные при "линейном" программировании. ("Линейные" программы почти всегда страдают трудноустранимыми ошибками, количество которых катастрофически возрастает по мере роста проекта.)

спустя 6 часов [обр] Дмитрий Котеров(13/912)[досье]

Есть вот еще один подход, который мне в последнее время кажется весьма удобным, и более удобную альтернативу которому я пока не видел. Вкратце это:
- Практически вся логика - на хранимых процедурах в базе. Кому, как не базе, лучше знать, как работать с данными в БД? Вне базы вообше ничего никуда не пишется и не читается.
- Скрипты в основном только и делают, что обращаются к хранимым процедурам (возможно, джойня одну с другой для получения комбинированного результата) и выводят в парный себе шаблон. Шаблоны могут друг в друга вкладываться как блоки, для каждого блока - свой скрипт-обработчик. Т.е. это и не ведущий, и не ведомый контроллер; это - парный контроллер.
- Система позволяет навешивать кучу пост-фильтров на выходной поток, которые занимаются разнообразными действиями. Типичный пример - проставляют везде вместо ID-шников URL-ы объектов за один быстрый запрос к базе, кэширование картинок из базы и т.д.

В такой схеме много плюсов, основные из которых:
- Код скриптов получается чрезвычайно простым, и, действительно, шаблонные языки уже не нужны (ну разве что xslt можно, при желании).
- Все файлы read-only, хакеру никакого простора для творчества.
- Процедуры можно отлаживать и писать совершенно отдельно от сайта.
- Можно не думать про целостность базы: она поддерживается автоматически, т.к. все можно делать только через хранимые процедуры, а прямой доступ к таблицам запрещен.
- Очень легко делать бэкап сайта и переносить его.

Правда, нужна база, которая хорошо поддерживает хранимки - например, Postgres или FireBird.

спустя 1 день 7 часов [обр] Андрей Пахомов(8/310)[досье]

Дмитрий Котеров[досье]
мысль хорошая, но написание и отладка хранимых процедур под тот же самый Postgres гораздо неудобней чем реализация той же логики на PHP, хотя бы чисто из-за того, что отсутствуют нормальные средства разработки, позволяющие достаточно легко написать и оттестировать получившуюся процедуру. Может это мне не попадались нормальные IDE (PgAdmin - это несерьезно) для БД, но делать в консоли

BEGIN WORK;
CREATE FUNCTION func_name...
SELECT func_name(...);
ROLLBACK WORK;

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

спустя 1 час 25 минут [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]
На счет захвата рынка тяжелых решений: хорошая статья. Так что "жаверские технологии" просто необходимы ;-)
спустя 1 час 57 минут [обр] Thirteensmay(3/157)[досье]
Андрей Пахомов[досье] я года 3 назад принимал участие во внедрении системы построенной по принципу Дмитрий Котеров[досье], это была достаточно большая система электронных продаж центральной аптеки краевого центра - могу сказать что работало нормально. БД - была на Interbase и процедуры правились изменялись и тестились вполне удобно. Тут как говорится вопрос просто в выборе инструмента. Реализация логики скриптом конечно гибче, тут я с Вами согласен, но с точки зрения целостности, транзакций, производительности и разделения функционала - этот вариант очень не плох. В той системе которую мы внедряли кстати было ядро которое практически не изменялось - вся доводка под конкретные требования реализовывалась процедурами. Правда сам в своих проектах я этот подход не использую, меня несколько угнетает держать в голове всю эту триггерно-процедурную модель, а если этого не делать - не понятно как работает, хотя конечно это пожалуй просто мое имхо, и есть наверное подходы к просветлению ?
спустя 42 минуты [обр] Андрей Пахомов(8/310)[досье]
это все понятно, я не отрицаю удобства такого подхода, и хотя на 100% он у меня нигде не реализован, частично он у меня используется. Лично меня остановило отсутствие нормальных IDE для написания триггеров, когда не надо во время отладки постоянно создавать и удалять процедуры. Вопрос в этом и стоял, есть ли что то более приличное для того же постгреса чем консоль и PgAdmin.
спустя 1 день 1 час [обр] Дмитрий Котеров(13/912)[досье]
Андрей Пахомов[досье]
Во-первых, посмотрите EMS PostgreSQL Manager. В нем много есть, и уж точно консоль не нужна.
Во-вторых, в случае FireBird (Interbase) все гораздо приятнее, т.к. там есть утилита - IBExpert, в которой не
только можно разрабатывать процедуры, но также и их отлаживать в режиме пошаговой трассировки! К сожалению, стабильность FireBird и грядущие перспективы ее разработки не просто неудовлетворительны, а гораздо хуже.
спустя 18 часов [обр] Андрей Пахомов(8/310)[досье]
Дмитрий Котеров[досье]
спасибо, посмотрю.
спустя 4 дня [обр] fetis(0/82)[досье]

Дмитрий Котеров[досье]

К сожалению, стабильность FireBird и грядущие перспективы ее разработки не просто неудовлетворительны, а гораздо хуже.

Не соглашусь. Не знаю насчет *nix платформ, но в win-решениях каких-то особых проблем с производительностью не наблюдается. На подходе версия 2.0.

спустя 9 часов [обр] Андрей Пахомов(8/310)[досье]
fetis[досье]
и много вы видете хостингов для веб-сайтов на Win-платформах да еще и с FireBird ?
спустя 11 часов [обр] Дмитрий Попов(15/509)[досье]
Андрей Пахомов[досье]
А хостинг на DB2 вы когда последний раз встречали?
спустя 11 часов [обр] Андрей Пахомов(8/310)[досье]
Дмитрий Попов[досье]
А я DB2 и не использовал никогда... Я как то все больше под Postgres. Он по крайней мере практически на всех хостингах встречается.
спустя 2 часа 47 минут [обр] Дмитрий Попов(15/509)[досье]
Я тоже никогда DB2 не использовал. Однако не вижу связи между стабильностью и перспективами развития DB2 с встречаемостью её на хостингах.
спустя 22 минуты [обр] Андрей Пахомов(8/310)[досье]
Как сказать.Сам факт отсутствия хостеров, предлагающих такую БД говорит о том, что дл веба данная база данных не является популярной и перспективы развития ее в этом направлении - минимальны. Хотя в других сферах ее использование вполне может быть оправдано и перспективно.
спустя 3 часа 29 минут [обр] Дмитрий Попов(15/509)[досье]

Андрей Пахомов[досье]
Что Вы подразумеваете под "для Web'а"? Какая связь между Web'ом и виртуальным хостингом?
И вообще какая связь между Web'ом и БД?

Web - это не только виртуальные сайтики. Да их много, но они далеко не являются индустриеобразующими.

Думаю, денежные потоки среди этих миллиардов сайтиков сравнимы с миллионами проектов, которым виртуальный хостинг не нужен.

Есть тысячи, если не миллионы Web-проектов, использующих Oracle, Почти столько же использующих DB2. Не мало используют Interbase, Firebird.

Популярность же MySQL и PostgreSQL связанна исключительно с их легкостью, простотой и доступностью. Т.е. тремя китами на которых делается "маленький Web".
Но абсолютно неправильно говорить, что "Oracle не подходит для Web", лишь для того, что хостингов с MySQL гораздо больше. Не путайте понятия

спустя 1 час 14 минут [обр] fetis(0/82)[досье]
Андрей Пахомов[досье]
Собственно, Дмитрий Попов[досье] вам уже ответил.
спустя 5 часов [обр] Дмитрий Котеров(13/912)[досье]
Насчет FireBird для Linux - просто штука в том, что в этой СУБД нельзя реализовать даже скрипт счетчика, т.е. скрипт, который увеличивает на 1 значение некоторого элемента некоторой таблицы. Это самый простейший пример. Когда запускается очень много таких скриптов одновременно, БД выдает сообщение о deadlock, в то время как параметры транзакции вообще наличие deadlock-а исключают даже в теории (IBASE_WRITE | IBASE_COMMITTED | IBASE_WAIT | IBASE_REC_NO_VERSION). Это происходит из-за бага в FB, который разработчики исправлять и не думают вот уже года 2.
спустя 22 минуты [обр] Давид Мзареулян(31/1003)[досье]
Мораль — люди, юзайте постгрес. Лучшее, что есть из бесплатных.
спустя 2 часа 43 минуты [обр] Сергей Чернышев(39/589)[досье]
Кстати, я не хочу вызывать тут бурю в стакане, но может кто сравнит постргес с мускулем?
спустя 1 минуту [обр] Сергей Чернышев(39/589)[досье]
Забыл добавить для желающих меня укорить - меня интересует именно ваш опыт и именно свежий ибо я на обоих писал относительно давно и достаточно много чтобы иметь общее представление.
спустя 1 минуту [обр] Владимир Палант(80/4445)[досье]
Может вынести обсуждение баз данных в другую тему?
спустя 8 часов [обр] Андрей Пахомов(8/310)[досье]

Дмитрий Попов[досье]

Web - это не только виртуальные сайтики. Да их много, но они далеко не являются индустриеобразующими

ну вот приехали: 90% всего веба не является индустриеобразующей массой. Если еще учесть что ни одна поисковая система не использует РСУБД и разговор о каких то сторонних БД в этом ключе для них вообще не имеет смысла, получается удел вышеперчисленных вами БД - это интернет/интранет решения, ориентированные на крупный бизнес, который выдвигает совершенно другие требования по надежности, поддержке и производительности. Если учесть, что 90% ВВП любой страны - это мелкий и средний бизнес (OFF:Россию с ее нефтью и газом не рассматриваем), для которого это все не нужно, то ни в плане массы веб-проектов, ни в плане финансовой прибыльности эти ваши БД погоды не делают. Они занимают свою весьма узкую нишу и на большее не претендуют. Все это говорилось для чего: что на данный момент те технологии о выносе бизнес-логики в БД в виде триггеров и процедур как метода построения сайтов применимо только если в качестве БД рассматривать Postgres. Все. Остальные БД имеет смысл рассматривать только если Postgres чем то не устраивает и данный проект по своим объемам или нагрузке не помещается на виртуальный сервер и имеется свой сервер, на котором и можно городить огород. Для веб-студий, перед которыми стоит задача делать массу сайтов и выбор метода реализации является определяющим (им же в дальнейшем придется их поддерживать) - выделять под каждый сайт свой сервер не принято. Для них писать сайты на экзотике типа DB2 - это можно рассматривать только как попытку удержать клиента на своем хостинге. В общем, я не хочу устраивать холивар по БД, но надежды на то, что DB2 придет на массовый рынок и у рядового программиста, работающего в веб-студии будет возможность выбирать эту БД не задумываясь о том, что потом у клиента могут быть проблемы с хостингом - мало. А крупные проекты с использованием Oracle и MSSQL оставим в стороне, они не конкуренты ни MySQL, ни Postgres.

спустя 1 час 4 минуты [обр] Дмитрий Попов(15/509)[досье]

Андрей Пахомов[досье]
Это Вы с кем сейчас разговаривали?

Я Вам несколько про другое писал, не находите?

З.Ы. DB2 такая же экзотика как Oracle и MSSQL. Это в россии он менее популярен

спустя 38 минут [обр] Андрей Пахомов(8/310)[досье]
Дмитрий Попов[досье]
да как сказать... с вами разговаривал. Если я ничего не путаю, речь шла о том, что ряд БД можно использовать для написания сайтов и при этом хранить всю логику в самих БД в виде процедур. Также было сказано, что для этого на данный момент можно использовать Postgres и FireBird, но последний имеет смутные перспективы развития, из чего я сделал вывод что использовать его для написания сайтов нехорошо, в силу его малой распространенности у хостеров. На что мне начали приводить примеры малораспространненых БД такого уровня, что писать с их использованием обычные(под словом обычные я понимаю сайты, которые вполне уместно размещать на вирутальных хостингах) сайты нормальный человек не станет (лично я не буду писать интернет-магазин с посещяемостью в 200 человек в день на Oracle). Мы не о том сегменте рынка говорим. Я понимаю, что есть большие дяди, которые ваяют проекты в сотни тысяч человеко-часов и там MySQL также неуместен, как Oracle на homepage мелкой компании, но это не наши клиенты. Там то как раз таких вопросов: нужно ли использовать ООП или MVC, не стоит. Или крик души провинциального веб-мастера касался именно таких проектов, а я тут с FireBird на виртуальном хостинге не в тему вылез ?
спустя 44 минуты [обр] Дмитрий Котеров(13/912)[досье]

Кратко MySQL 5.0 и PostgreSQL.

MySQL 5.0:
+ отличное кэширование результатов запросов, ускоряет работу в разы!
+ быстро работает, есть непрошибаемая InnoDB
- хранимые процедуры совсем неудобные, нельзя даже их join-ить; все сделано на курсорах
- триггеры не очень удобные
- недостаточные возможности для поддержания целостности базы
- транзакции в зародыше

PostgreSQL:
- нет кэширования запросов
+ практически полная поддержка стандартов
+ хранимые процедуры нормальные, короче - с точки зрения полной поддержки SQL все там замечательно
- работает (по субъективному опыту) медленнее MySQL
- не настолько устойчива, как InnoDB (тоже по субъективному опыту)

спустя 7 минут [обр] fetis(0/82)[досье]
Дмитрий Котеров[досье]
Для счетчиков в FB есть генераторы, а почему у вас получается deadlock я не знаю, надо смотреть что вы с базой делаете. Если вы уверяете, что это баг, то приведите тогда ссылку на него.
спустя 16 минут [обр] Давид Мзареулян(31/1003)[досье]

Дмитрий Котеров[досье] Кэширование запросов в Постгрессе есть. Не сравнивал его с MySQL-ным, может у того и лучше, но постгрес совершенно точно отдаёт результаты последовательных одинаковых запросов из собственного кэша (просто по времени видно). Устойчивость — лично у меня за шесть лет использования в разных видах не было ни одной проблемы с устойчивостью самой базы. Падало всё что угодно, кроме неё, и даже при вырубании питания при транзакции база включалась, вакуумилась и продолжала работать как ни в чём ни бывало. Опять же, не сравниваю с InnoDB — не работал.

У Постгреса есть один недостаток с точки зрения скорости — слишком сильная блокировка на аггрегатные функции (count(), max() и пр.), из-за чего они выполняются медленно на частообновляемых таблицах. Ну, это особенность такая неприятная, надо о ней просто знать. Ещё есть странности с реализацией наследования таблиц, но, насколько я понимаю, в MySQL такого понятия вообще нет.

спустя 5 часов [обр] Дмитрий Попов(15/509)[досье]

Андрей Пахомов[досье]
Нет, просто речь шла о перспективах Firebird как базы для Web-приложений в целом, а Вы начали говорить о перспективах Firebird, для разработки мелких сайтов.

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

спустя 3 часа 21 минуту [обр] Дмитрий Котеров(13/912)[досье]

fetis[досье], вот чья-то статья, по мотивам, так сказать: http://www.ibase.ru/devinfo/norecver.htm
Генераторы тут ни при чем, я привожу "минимальный код, воспроизводящий проблему" - "запрос, увеличивающий на 1 значение некоторого поля некоторой записи некоторой таблицы" - всего одной, в одной и той же записи, одной и той же таблице. Этот запрос при правильных параметрах транзакции, исключающих в теории блокировку, тем не менее, выдает сообщение о deadlock (причем не тот deadlock, что в теории трактуется как цикл, а какой-то собственный, firebird-овский deadlock). Вот еще:
http://forum.ibase.ru/phpBB2/v......stdays=0&postorder=asc&start=0
http://forum.ibase.ru/phpBB2/viewtopic.php?t=2045

Давид Мзареулян[досье], под "устойчивостью" я имел в виду именно устойчивость к сбоям электропитания. Например, MySQL можно бюэкапить, прямо не выключая - многолетняя практика показала, что при этом, если отдельные записи и бьются, то восстанавливаются по REPAIR TABLE. Постгрес и FB, насколько я знаю, этим похвастаться не могут.

спустя 53 минуты [обр] Давид Мзареулян(31/1003)[досье]
Дмитрий Котеров[досье] Да мы его, вообще-то, так и бэкапим — не прерывая процесса.
спустя 54 секунды [обр] Давид Мзареулян(31/1003)[досье]
Да и вообще. Что это за база, которую для бэкапа останавливать надо?
спустя 1 час 46 минут [обр] Дмитрий Котеров(13/912)[досье]
Я имел в виду "жесткий" бэкап - tar+gz, пофайловый. :-)
MySQL его выдерживает великолепно.
спустя 2 года 2 месяца [обр] xxx+++(0/10)[досье]
Дима, по проишествию 2 лет, интересно, ты изменил свое мнение?
спустя 5 часов [обр] Дмитрий Попов(15/509)[досье]

Не совсем. Вернее совсем не. Кое с чем не согласен - по мелочам. А с большинством сказанного - однозначно согласен.
Более того за эти два года я как раз перешел в область работы над очень крупными интернет-проектами с очень большой посещаемостью и нагрузками. И еще более стал уверен что сложные ява-образные технологии даже при развитии объектной модели в PHP5 абсолютно тут не применимы, а вот геммору и проблем подкинуть могут много.

Хотя как раз использование сложных фреймворков при разработке небольших корпоративных сайтов считаю возможным и может быть даже правильным.

спустя 1 час 51 минуту [обр] Давид Мзареулян(31/1003)[досье]
Дмитрий Попов[досье] Так вот прямо Привет, <?php echo htmlspecualchars($name)?>!?
спустя 2 дня 14 часов [обр] Дмитрий Попов(15/509)[досье]
сообщение промодерировано

Давид Мзареулян[досье] Ну, не до такой степени конечно =)

З.Ы. Кстати, ошибки в написании функций допускать некошерно )

спустя 13 часов [обр] Иванов Михаил aka Ivanych(3/70)[досье]
Дмитрий Попов[досье] Писать простые русcкие слова "Post Scriptum" как "З.Ы." тоже некузяво:)
Powered by POEM™ Engine Copyright © 2002-2005