Веб-программирование, 7 ступенек в рай

Главные вкладки

Аватар пользователя Макс К. Макс К. 2 мая 2007 в 11:48

7 ступеней в небесаПролог

Рано или поздно веб-программист уходит с проекта и на его место приходит другой веб-программист. “Как сделать так, чтобы смена веб-программиста проходила безболезненно для заказчика сайта” – эта проблема волновала меня долгие годы.
Расскажу о 7 ступенях, по которым мне пришлось поднятся, прежде чем получил ответ на свой вопрос.

1–ая ступенька, стиль программирования
В бытность свою веб-программистом писал крутые, как казалось, программы в рекурсивном стиле:

// Вычисление факториала N! = 1 * 2 * ... * N
// Факториал не натурального числа примем равным нулю
function factorial ($N) {
if (1 > $N) return 0;
if (1 == $N) return 1;
return (factorial($N - 1) * $N);
}
?>

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

// Вычисление факториала N! = 1 * 2 * ... * N
// Факториал не натурального числа примем равным нулю
function factorial ($N) {
if ((intval($N) != $N ) || (1 > $N)) return 0;
$Fac = 1;
for ($i = 1; $i <= $N; $i ++) {
$Fac *= $i;
}
return $Fac;
}
?>

Такой код легко стало поддерживать не только мне.
2–ая ступенька, классы
Задачи у веб-программистов примерно похожие. Закодированные решения многие из них оформляли в виде классов и выкладывали в Интернет. Скоро понял, что проще использовать готовые классы, решающие типовые задачи:

  • SMTP-класс
  • класс-прослойка между PHP и MySQL
  • класс обработки ошибок
  • класс корзина для E-Commerce

Брал готовые классы, правил их как мне надо и использовал на сайтах. Работа сразу пошла вперед, благо основная часть кода была написана автором класса.
Прошло время и опять столкнулся с тем, что правленый мной класс другие не могли поддерживать. Другому программисту проще взять класс-исходник и править его или применить свой любимый класс.
Пришлось отказаться и от классов.
Для краткости пропущу изложение идей PHP-unit, рефракторинга, Selenium и других интересных технологий программирования. Они работали и делали свое дело. Но если под какую-то технологию трудно найти программиста на его поддержку и сопровождение, то использование такой технологии в будущем будет вызывать проблемы у заказчика.
Тем более что к тому времени стало набирать силу гораздо более интересное явление – готовые “движки” под ключ.
3–ья ступенька, движки
Собирал их по всем Интернету, раскладывал по гигабайтным папочкам, запускал на локальном сервере, любовно сравнивал их характеристики и отбирал самые удачные в своей нише.
Движки это красота. Все готовое, нужно было только ставить и наслаждаться. Если движок что-то делал не так, то небольшой правкой кода (на жаргоне “хак”) можно было привести движок к нужному мне функционалу. Разве можно было сравнивать такие возможности с каменным бинарным exe-шником.
Прошло время и опять столкнулся с тем, что сайт с движками тоже тяжело поддерживать:

  • Движки постоянно дрались между собой за общие ресурсы. За папку “/forum”, за папку “/image”, за файл “/index.php”, за место в дизайне на главной странице,…
  • Приходилось разводить движки по разным доменам третьего уровня. Это порождало новые проблемы: с куками, с запоминанием лишней точки в домене, с обновлением по FTP,…
  • На каждом движке была своя система логинов-паролей, своя система профилей и свой стиль набивки материалов, что очень раздражало посетителей
  • Каждый движок имел свой суверенный поиск
  • Движки время от времени обновлялись и помимо обновления масса времени уходила на поддержание в рабочем состоянии любимых хаков.

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

Если б я был султан,
Я б имел трёх жён
И тройной красотой Был бы окружён.
Но с другой стороны
При таких делах
Столько бед и забот.
Ах, спаси Аллах!

Не сильно радовала перспектива провести всю свою жизнь между взаимными движковыми обидами и постоянным обновлением версий движков и хаков. Также было совершенно непонятно, кто будет поддерживать “зоопарк” движков на сайтах после моего ухода с проектов.
4–ая ступенька, системы управления сайтом (CMS)
Выход пришел в виде систем управления сайтом.
Любой специализированный движок с легкостью перекрывает аналогичные возможности CMS. Но зато у CMS возможности разных движков встроены в ядро и хорошо ладят между собой. Единая регистрация, единое управление любыми возможностями, единый дизайн в котором одновременно могут выдавать свои результаты разные отделы CMS, единый поиск. Вот далеко не полный перечень того единого, что прекрасно существует в рамках одной CMS.
Если CMS проигрывает каждому движку по части специализации, то по легкости сопровождения CMS даст 100 очков вперед любой связке из 5–6 движков.
Поддерживать CMS просто, потому что это один движок. И когда у клиента появится необходимость сменить веб-мастера, ему не нужно будет искать специалиста по связке из движков. Достаточно будет найти специалиста по выбранной CMS.
В качестве CMS был выбран Drupal.
Легкая установка, легкое сопровождение. Сайты на Друпале у меня стали плодится как кролики. Освободившееся время тратил на то, что лез в ядро и правил его под нужды проекта.
Но если разнокалиберные движки на одном сайте обновлялись по очереди, то версию Друпала на всех сайтах нужно было обновлять одновременно. Также одновременно приходилось обновлять все хаки. Вначале еще это было терпимо, но по мере роста количества поддерживаемых сайтов, возня с хаками ядра стала сильно раздражать.
5–ая ступенька, использование API
“API, вот решение вопроса с хаками”, родилась мысль. Благо в Друпале API на редкость элегантное и приятное в использовании. Не лезть в ядро, а все необходимое получать через API. Это так естественно.
Но в один прекрасный день Друпал поменял свое API. И пришло осознание, что использование API влечет такие проблемы, как и хак ядра Друпала. Вся разница лишь в том, что API меняется пореже, чем происходит обновление версий в Друпале с ликвидацией критических ошибок.
Но все равно, после моего ухода с проекта рано или поздно API сменится в очередной раз. И клиент окажется брошенным на камни с моим API-шным кодом. Ему придется искать специалиста, знающего API и который сможет переписать код на новое API. Это будет стоить клиенту гораздо дороже, чем наем обычного специалиста по Друпалу.
6–ая ступенька, самописные модули
Помимо ядра и API, в Друпале существует прекрасная возможность написания своих модулей. При мелких обновлениях Друпала самописные модули не требуют никакого обновления.
Веб-программисту, сменившему меня, виделось мне, будет гораздо легче разбираться с текстом моих модулей, чем отлавливать по всему движку API-шные вставки. Самописные модули в друпаловском стандарте были бы прекрасной возможностью получить доступ к низкоуровневым возможностям Друпала и в то же время облегчить свою последующую поддержку.
Но оставался нерешенным тот же самый вопрос. Имею ли я право навечно обременять клиента поисками специалистов, которые регулярно будут переписывать все мои самописные модули?
7–ая ступенька, сторонние модули
После долгих раздумий заставил себя смотреть только в сторону готовых сторонних модулей, написанных другими друпальщиками. Их в Друпале написано около двух тысяч на все вкусы. Установка стороннего модуля занимает всего несколько минут.
При мелких обновлениях Друпала сторонние модули вообще не требуют замены. У сторонних модулей есть хозяева, которые обновят модули при смене API или версий. Казалось, надо будет лишь подождать пока произойдет обновление установленных на сайте сторонних модулей и можно будет обновить сам Друпал.
Но когда Друпал в течение нескольких месяцев поменял сначала API, а потом обновился с 4–ой версии на 5–ую, то у меня закрались некоторые сомнения в верности моих мыслей. Прошло несколько месяцев после перехода на 5–ую версию, а до сих пор половина модулей из версии 4.* так и не обновились до версии 5.*. И похоже, не обновятся уже никогда.
Стало понятно, что надежность сильно зависит от количества сторонних людей, готовых обновлять код.

  • Самая низкая надежность у кода, написанного одиноким программистом с помощью API. Поддержка кода полностью зависит от автора-программиста.
  • Код, выложенный на Drupal.org в виде модуля, доступен для многих и привлекает внимание многих программистов. Поэтому предположительно он более надежен. Если идея модуля удачна, то он обновится быстро или автором модуля или теми, кто пользуется этим модулем. Но в каждый второй модуль не переживает смену API или сильную смену версий Друпала.
  • Код ядра Друпала и его встроенных модулей самый надежный в смысле поддержки. За ним стоят тысячи друпальщиков, присылающих свои обновления для ядра Друпала и его стандартных модулей.

За одиноким программистом стоит только он сам. За Друпалом стоят тысячи. Сколько же людей стоят за каждым сторонним друпальским модулем? Этого, к сожалению, на модулях не пишут и выяснится только после смены API или сильной смены версии Друпала. Выбор плохо поддерживаемого модуля может в будущем повлечь невозможность обновлять проект.
Как выиграть в рулетку с модулями? Пришлось мысленно разделить сторонние модули на 3 группы:

  • “Зеленые” модули. При отключении таких модулей на сайте сохраняется полный доступ к накопленной информации;
  • “Желтые” модули. Их отключение повлечет потерю доступа к части накопленной информации. Но путем работы с базой можно попробовать вручную конвертировать недоступную информацию к какому-нибудь стандартному виду;
  • “Красные модули”. При отключении такого модуля вернуть к использованию наработанные этими модулями данные практически невозможно.

Примеры зеленых модулей:

  • Все модули в стандартной поставе Друпала
  • редактор TinyMCE
  • Read More Tweak
  • Blog Information
  • captha
  • comment_mover
  • темы
  • Blog Information
  • Print Friendly Pages
  • Login Toboggan
  • Comment Mail
  • Blogger - топ всех блогов
  • Remember me
  • вики-модуль wikitools

Примеры желтых модулей

  • Signature module
  • Quote
  • вставка тэгов phpBB
  • Web Links

Примеры красных модулей

  • webform
  • Content Construction Kit
  • e-commerce
  • Gallery2
  • fudforum
  • вики-модуль Liquid

Стал реализовывать функционал сайтов только через зеленые модули.
Ставить желтый или красный модуль означало возможность жестоко подставить клиента при ближайшей смене API или сильной смене версий Друпала, которая произойдет в мое отсутствие. Такие модули использовал только при крайней необходимости, сто раз продумав этот шаг. При выборе желтого или красного модуля всегда старался брать не самый подходящий под требования проекта, а самый часто цитируемый и поддерживаемый, пусть он даже реализовывал только часть нужного мне функционала.
В результате смена API и сильная смена версий Друпала проходит теперь на моих сайтах очень просто. Нужно подождать 2–3 месяца, сменить Друпал и поменять все сторонние модули которые успели обновится к этому сроку под новое API или новую версию Друпала. Даже если какие-то зеленые модули так и не обновились, то сайт прекрасно будет существовать без них.
Желтых и красных модулей у меня в установке обычно нет или в единичных количествах. Выбираю их среди самых поддерживаемых модулей, поэтому в течение 2–х месяцев они обычно уже обновляются.
Райская установка CMS
Пройдя 7 ступеней, попал в настоящий рай:
Elysium
Спешу рассказать, что в раю принята такая установка динамических сайтов:

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

Поддержка сайтов в раю до смешного легкая. Сайты сохраняют свой функционал даже при смене API и сильной смене версий Друпала. Обновление версий на друпаловских сайтах занимает полчаса на сайт и отлажена как часы. И что приятно, смену версий может провести даже самый начинающий житель рая.
Грустная новость. В раю очень мало веб-программистов и веб-дизайнеров. Раньше они собирали жатву практически с каждого сайта, теперь одного веб-программиста и одного веб-дизайнера хватает для обслуживания десятков сайтов, да и то часто их помощь самая минимальная. На постоянной основе работает лишь специалист по чистому использованию CMS.
Язык сверхвысокого уровня, язык CMS
Райская установка CMS без единой строки программирования это следующее поколение языков веб-программирования, язык сверхвысокого уровня. Его еще можно назвать языком CMS. У каждой CMS он свой.
Роль стандартных конструкций обычного языка программирования в CMS выполняют модули. Обращение к стандартным функциям языка и подстановка нужных параметров в языке CMS тоже существует и выглядит как щелканье галочками в настройках модуля.
На вход языка CMS подается активность посетителей, на выходе получаются готовый сайт. Умелым написанием программы CMS (т.е. настройкой CMS) разработчик создает сайт, который превращает активность посетителей в готовый сайт.
Практически, выбирая CMS, программист выбирает язык программирования сверх-высокого уровня, которым будет творить последующие годы.
Самодостаточность языка CMS
Язык CMS это полноценный язык. Он практически не нуждается в низкоуровневых самописных вставках. Большей частью такие вставки делаются по привычке веб-программиста программировать, а не от необходимости.
Если ограничить себя рамками языка CMS, то, к удивлению, оказалось возможным обеспечить большинство потребностей посетителей средствами самой CMS.
Проекты, сделанные на одном лишь языке CMS, просты в поддержке и надежны в работе. (Например, наш сайт Razgonka.ru принципиально сделан без единой строчки самописного кода).
Мастерство
Для привлечения к себе внимания веб-программистов, системы управления сайтами дают им ту или иную возможность встроить встроить в себя низкоуровневый самописный код. Но это не означает, что нужно использовать такую возможность.
Любой самописный байт потребует пожизненной поддержки, которая тяжким бременем ляжет на бюджет проекта. Самописные байты накапливаются и наступит момент, когда их поддержка съест весь бюджет выделенный на поддержку проекта. За этим последует крах проекта.
Легко определить уровень разработчика сайтов на CMS. Посмотрите, насколько он склонен в своих проектах применять код, за которым стоит только один человек. Неумеренное использование красных модулей тоже выдает специалиста, который не заботится о будущем проекта.
Профессионализм разработчика сайта на CMS заключается в том, чтобы последовательно развивать сайт и при этом опираться только на код, который поддерживают как минимум десятки человек, а еще лучше сотни и тысячи. Только при этих условиях динамический сайт будет годами устойчиво работать и развиваться, часто при весьма скромном бюджете.
Ссылки в тему
Программирование:

CMS Drupal:

Постоянный адрес статьи:

Обсуждение похожей темы "Drupal и будущее веба" - http://www.drupal.ru/node/5323

Комментарии

Аватар пользователя romandor romandor 2 мая 2007 в 12:05

Прочитал. Браво!

Более того, рекомендую тебе опубликовать эту статью в других курилках для разработчиков, например phpinside.ru

Аватар пользователя Макс К. Макс К. 2 мая 2007 в 12:45

romand@drupal.org says:рекомендую тебе опубликовать эту статью в других курилках для разработчиков, например phpinside.ru

Публикация на PHPinside.ru никак меня не накормит. У моих клиентов нет сомнения, что PHP-программистов он всегда найдут. Их пугает, что они после меня не смогут найти друпальщиков на поддержку своих сайтов. Им нужен список толковых специалистов по Друпалу. Такой список мне проще составить на Drupal.ru, чем на PHPinside.ru.

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

Аватар пользователя romandor romandor 2 мая 2007 в 12:50

Дело в том, что тут большинство из твоих аргументов (тезисов) более-менее все понимают и используют (кто интуитивно, кто сознательно). А чтобы у твоих клиетов был больший резерв специалистов-друпальщиков стоит опубликовать статью в более других местах (даже joom-както-там.ru, откуда я собственно и узнал о друпале Smile

Аватар пользователя Макс К. Макс К. 2 мая 2007 в 13:14

romand@drupal.org says: Дело в том, что тут большинство из твоих аргументов (тезисов) более-менее все понимают и используют (кто интуитивно, кто сознательно).

Ты оптимист.

PHP на Друпаловских сайтах не используют только те, кто его не знают. Да и то переживают за свое незнание и хотят научится, чтобы стать "настоящими друпателями". Общее мнение на Drupal.ru такое, что настоящий друпатель это и PHP-программер, и кудесник MySQL и при случае не побоится тему сваять. Вопрос "кто будет поддерживать сайты после нас" насколько помню, ни разу не ставился.

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

romand@drupal.org says: А чтобы у твоих клиетов был больший резерв специалистов-друпальщиков стоит опубликовать статью в более других местах

Если все PHP-программеры перетекут на установку CMS, то кто же будет разрабатывать и поддерживать CMS? Пусть живут как жили. Smile

Аватар пользователя blackvl@drupal.org blackvl@drupal.org 2 мая 2007 в 13:41

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

Аватар пользователя Макс К. Макс К. 2 мая 2007 в 14:11

blackvl@drupal.org says: По каким признакам/тестам определить "цвет" модуля, ведь все не попробуешь на себе?.. Даже просто поставить много модулей на "потестить" и то большой труд. Так что без громадного труда (и опыта) в "друпарай" не попадешь.

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

По каждому модулю проводится голосование всеми, кто работал с ним и понимает концепцию красно-желтых-зеленых модулей. По результатам голосования модуль заносят в один из трех списков, красно-желто-зеленых модулей. Все последующие друпатели могут пользоваться списками протестированных модулей. Если есть желание применить какой-то модуль вне списка, то друпатель тестирует его и заодно вносит его в соответствующий список. Так что при желании можно вообще ничего не тестировать и сразу попасть в "друпарай" на опыте других. Нужен реестр модулей.

Не могу обещать, что возьмусь организовывать такой реестр, потому что сначала нужно создать реестр разработчиков сайтов на Друпале и выяснить, насколько они заинтересованы в том, чтобы сайты после них было легко поддерживать. Если проблема легкой передачи сайта от одного друпателя к другому волнует только меня одного, то тестировать модули для реестра будет просто некому. Я могу расписать некоторое количество модулей по цветам, но это всего лишь мое частное мнение. Нужно голосование специалистов, только тогда список будет рабочим.

Аватар пользователя blackvl@drupal.org blackvl@drupal.org 2 мая 2007 в 14:00

И еще, специально отдельным комментом, А ЗАЧЕМ ОБНОВЛЯТЬ БЕЗУПРЕЧНО РАБОТАЮЩИЙ САЙТ!!! Не в смыcле обновлений по безопасности (4.7.4->4.7.6) а вот так взять и просто "поднять" версию... Пусть себе живет, пока хозяин не захочет редизайн и не найдет на это 10000 евро... а под этот бюджет и программист и дизайнер и специалист по "разгонке" найдется!

Аватар пользователя Макс К. Макс К. 2 мая 2007 в 14:30

blackvl@drupal.org says: А ЗАЧЕМ ОБНОВЛЯТЬ БЕЗУПРЕЧНО РАБОТАЮЩИЙ САЙТ!!! Не в смыcле обновлений по безопасности (4.7.4->4.7.6) а вот так взять и просто "поднять" версию...

"Drupal 5.1 and 4.7.6 released. Upgrading your existing Drupal sites is strongly recommended."
http://drupal.org/

Веточка 4.6.* уже похоже не поддерживается. А она сидела на старом API. Получается, если год назад кто-то заказал сайт на версии 4.6 и разработчик обвесил ему все красными модулями и своим кодом, взял деньги и исчез, то сейчас сайт на версии 4.6 ходит каждый день над пропастью. Хотя еще не прошло и года. (В точных сроках и номерах версий не вполне уверен, но идею Вы надеюсь поняли).

blackvl@drupal.org says: Не в смыcле обновлений по безопасности (4.7.4->4.7.6)

Откидывать соображения безопасности можно лишь какое-то время. Затем у Вашего бывшего клиента отдефейсят его сайт. И бывший клиент будет очень недоволен, что никто не берется перевести Вашу "красную" установку на свежую версию Друпала.

Вернее, перевести можно, но отвалится половина материала, сделанного на "красных" модулях. Потому что по предыдущий опыт показывает: смену API или сильную смену версию Друпала не переживает половина модулей. Зайдите в любую рубрику по модулям и убедитесь сами.

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

Аватар пользователя blackvl@drupal.org blackvl@drupal.org 2 мая 2007 в 14:51

Откидывать соображения безопасности можно лишь какое-то время.
Я как раз и НЕ ОТКИДЫВАЮ, я говорю о том, что достаточно поднимать версию по соображениям безопасности, а не заниматься подъемом на единицу (4->5, а уже и 6 не за горами...) всех подряд поддерживаемых сайтов. Переход на 5-ку был осуществлен уже на моей "друпал" памяти, когда стабильной считалась 4.7.3... теперь 4.7.6 Конечно удобнее поддерживать движок одной версии и т.п., но если "красный" модуль - основа сайта?! (думаю модуль i18n такой) то стоит ли бороться..
В целом я со статьей согласен, но это идеал, который врядли достижим.

Аватар пользователя Макс К. Макс К. 2 мая 2007 в 19:31

blackvl@drupal.org says: Наверное, не стоит лицемерить здесь, все свои. Пахнет в вашем воображении, а не в моих словах.

Ну еще не хватало, чтобы Вы на клавиатурах всех посетителей Drupal.ru реальную кучку наложили. В Интернет все в воображении. И статьи и собеседники и сайты. Друпаллеры бывают не только ребята, но и девушки. Так же как прекрасный пол тоже заказывает сайт. Говорить в Интернет нужно примерно на таком же уровне, как мы говорим в фойе театре. Без грубых слов и другой экспрессивной лексики. Впрочем, если Вы не ожидаете клиентов и клиенток с Drupal.ru, то можете говорить как считаете нужным.

blackvl@drupal.org says: Конечно удобнее поддерживать движок одной версии и т.п., но если "красный" модуль - основа сайта?! (думаю модуль i18n такой) то стоит ли бороться.

Если не видеть последствия, то да, бороться не особенно хочется.

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

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

blackvl@drupal.org says:В целом я со статьей согласен, но это идеал, который врядли достижим.

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

Аватар пользователя blackvl@drupal.org blackvl@drupal.org 2 мая 2007 в 21:40

Цитата про запах не моя... как-то нечаянно замарались все из-за одного... Sad не хорошо это.
Вообще не стоило заострять на этом внимание, а особенно, цитировать.

Теперь по сути обсуждения. Видимо стремиться к идеалу нужно, но я все же очень сомневаюсь, что без своих разработок возможна какая-то индивидуальность сайта. Друпал ведь не родился с 2000 модулей! А как они появились? Возникла у кого-то задача - он ее решил и поделился со всеми... А если надеятся только на то, что кто-то что-то уже сделал... потом перенес на новую версию - мне лично не по характеру, хотя известной долей лени обладают все програмеры Smile
Вот вам, Максим, чувствующему и понимающему друпал, самое то, выкладывать свои наработки в виде (хорошо документированных) модулей. Отсутствие документации - главная причина отказа стороннего программиста поддерживать чужую разработку.
А отсутствие "образованности" у тех, кого вы увлечёте "кнопконажимательством" загубят вашу идею.

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 13:58

blackvl@drupal.org says: Видимо стремиться к идеалу нужно, но я все же очень сомневаюсь, что без своих разработок возможна какая-то индивидуальность сайта.

Цель сайта не в том, чтобы установщик проявил свою индивидуальность по полной программе. Цель сайта в том, чтобы на сайте было удобно посетителям и тем, кто наполняет сайт материалами (авторам). Ваша личная индивидуальность не нужна ни посетителям, ни авторам. У них своей индивидуальности более чем достаточно. Хороший разработчик проекта даже когда спит думает о том, как дать посетителям и авторам проявить свою индивидуальность.

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

За Вашими индивидуальными разработками стоите только Вы. Как только Вы уйдете с проекта, все Ваши разработки придется поддерживать другим людям. Отношение к чужому коду известное, чужой код - чужой ребенок. Все материалы на сайте, которые были созданы с использованием Вашего кода, еще некоторое время поживут на проекте. А вместе с очередной сильной сменой версии Друпала исчезнут. Новому человеку на поддержке не улыбается рыскать по всему сайту, искать Ваш код и поддерживать его. Ему проще сказать клиенту, что Ваш код нужно удалить, потому что он не совместим с новой версией Друпала.

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

blackvl@drupal.org says: Друпал ведь не родился с 2000 модулей! А как они появились? Возникла у кого-то задача - он ее решил и поделился со всеми...

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

Большинство установщиков Друпала, кстати, ничего в ядро и не пишут. И модули свои на Drupal.org не выкладывают.

blackvl@drupal.org says: А если надеятся только на то, что кто-то что-то уже сделал... потом перенес на новую версию - мне лично не по характеру,

Причем здесь Ваш характер? Клиент хочет получить сайт, который будет развиваться годами. И хочет получить его независимо от Вашего характера. Клиент имеет на это право, раз платит. Думайте интересами клиента, Ваш характер сразу присмиреет, а вскоре исчезнет вовсе.

blackvl@drupal.org says: Вот вам, Максим, чувствующему и понимающему друпал, самое то, выкладывать свои наработки в виде (хорошо документированных) модулей.

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

Да и оценивать модули несложно самому. Перед тем как ставить очередной сторонний модуль, спросите себя: "А что будет, если через год придется удалить этот модуль с сайта из-за отсутствия поддержки?". Ответ придет сам собой.

Аватар пользователя blackvl@drupal.org blackvl@drupal.org 3 мая 2007 в 15:20

Браво Максим! У вас удивительная способность переворачивать все слова собеседника в свою пользу!!!
Все, что вы написали в этом ответе для меня тривиальная истина...
Я говорил про индивидуальность сайта, в не свою! Индивидуальность сайта это не только заказной дизайн, но и заказная функциональность. Мое возражение касалось именно того, как в рамках вашей концепции идеального стиля разработки реализовать не заложенную в друпал функциональность? Ведь модуль для того и пишется... И опять таки, я говорил о модуле, т.е. не портить ядро, причем документированном модуле. Почему вы считаете возможным разбирать код модуля выложенного на орг и так сильно сопротивляетесь, если получите документированный модуль от предшественника? В чем принципиальная разница?
И еще, конечно, друпал ориентирован на "социальные" проекты, но ведь не только! А тогда, от пользователей мало что зависит - они приходят на сайт получить информацию и получить ее так как попросил заказчик (ему виднее Wink )... Думаю такой сайт может быть с любым набором модулей, реализующим его функциональность.

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 16:41

blackvl@drupal.org says: Браво Максим! У вас удивительная способность переворачивать все слова собеседника в свою пользу!!!

А что тогда спорите, если знаете что я все равно выверну Ваши слова в мою пользу? Smile

blackvl@drupal.org says: Я говорил про индивидуальность сайта, в не свою! Индивидуальность сайта это не только заказной дизайн, но и заказная функциональность.

Какая разница - Ваша индивидуальность или индивидуальность заказчика? Обе индивидуальности не имеют никакого отношения к индивидуальности посетителей, для которых собственно и делается сайт.

Когда из-за неправильного проектирования сайта через несколько лет придется перекраивать сайт по новому, индивидуальности посетителей будет нанесен большой удар. После большой реорганизации сайт может потерять до 50-70% своих постоянных авторов, которые уходят на сайты к конкурентам и уже не возвращаются оттуда.

blackvl@drupal.org says: как в рамках вашей концепции идеального стиля разработки реализовать не заложенную в друпал функциональность?

Если не заложенная в Друпал функциональность занимает весомый процент, то с самого начала имеет смысл подумать о другой CMS.

В остальных случаях недостающую функциональность пытаются сначала организовать стандартными модулями Друпала. Если 70-80% потребностей в какой-то функции покрывается стандартным модулем, то нужно использовать его. Это надежно.

Если подходящего стандартного модуля нет, то ищется какой-то подходящий "зеленый" модуль, которому опять таки достаточно покрыть лишь 70-80% потребностей от требуемой функции.

Если и зеленого модуля не нашлось, то начинают искать среди "желтых" модулей. Вдруг среди них найдется какой-то, который покроет 70-80% потребностей.

Линия смерти

Между желтыми и красными модулями находится Dead Line. Переходить ее чревато для проекта.

Нужно подумать, действительно ли нужна ли такая проблемная функция для проекта. Помогает отложить реализацию функции на 2-3 месяца. Часто за этот срок отпадает надобность в реализации функции.

Если потребность осталась, то переходят к поискам среди "красных" модулей. Допустим, нашелся какой-то красный модуль, который реализует хотя бы 70% процентов требуемой функции. Прекрасно, ставьте его.

Если не нашлось ничего подходящего, то опять берете паузу на 2-3 месяца. Возможно, за этот срок отпадет необходимость в проблемной функции.

И только затем начинаете думать о самописном модуле.

Вот раньше

Раньше в церквях проходили обряд обручения, после которого жених и невеста могли присматриваться друг к другу в течение года. И только после успешно пройденного года обручения происходило венчание, на всю оставшуюся жизнь. Это было разумно. Когда принимается решение последствия которого будешь нести всю жизнь, нельзя спешить.

Сейчас же бросаются делать самописный модуль буквально в тот же день, как появилась в нем потребность. Подождите год, потом и пишите. 2/3 реализованных функций оказываются ненужными уже через полгода, пророки из нас никакие. Этим можно пользоваться и как можно дальше оттягивать принятие решений об установке красных или самописных модулей.

blackvl@drupal.org says: Почему вы считаете возможным разбирать код модуля выложенного на орг и так сильно сопротивляетесь, если получите документированный модуль от предшественника? В чем принципиальная разница?

Между сторонним модулем выложенным на Drupal.org (пусть даже и красным) и модулем от предшественника есть принципиальная разница. У стороннего модуля на Drupal.org есть шанс, что какое-то время он будет обновляться своим автором. А модуль от предшественника придется обновлять самому.

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

Но если каждый Ваш предшественник насовал в проект десяток самописных модулей и когда у Вас с десяток таких проектов и когда Друпал вдруг в очередной раз сменит API и когда Вам в течение короткого времени придется менять код в сотне модулей от Ваших предшественников - вот здесь Вам чужие самописные модули как-то сразу перестанут нравится. А когда через несколько месяцев Друпал снова сделает сильное обновление своих версий, Вы начнете злится. А когда на форуме будут с восторгом описывать возможности следующей версии Друпала которая ожидается через полгода, Ваше недовольство предшественниками будет очень велико.

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

Скажите себе, что Вы не будете вечно сидеть на Ваших проектах. Любой Ваш самописный код будет тяжелым грузом лежать на том, кто придет после Вас. Даже если Вам повезет с тем, кто придет на сайт и тот сможет поддерживать Ваш код, он тоже не будет вечным. За ним придет следующий, кто не захочет поддерживать чужой код. И Ваш код будет отключен. Какой бы Ваш код не был гениальным и нужным для проекта, он будет отключен в течение 0..2 лет после Вашего ухода с проекта.

Гонка

Темп гонке задают создатели Друпала.

Отбить охоту к самописным модулям можно 2-мя способами. Можно запретить писать самописные вставки. А можно выпускать новые версии и менять API каждые полгода. Создатели Друпала пошли вторым путем. Они взялись постоянно наращивать возможности Друпала. Обратная сторона этого - невозможность самостоятельно поддерживать самописные модули.

Раньше между мажорными версиями проходил период 5 лет. Сейчас этот период сократился до 1 года. Да еще в промежутках могут API меняют для полноты счастья.

В этой гонке ничего страшного нет. Прекращайте дополнять Друпал самописными вставками и полностью опирайтесь только на возможности его ядра и сторонних модулей. Тогда смена версий Друпала и API будет проходить для Вас без проблем.

Аватар пользователя blackvl@drupal.org blackvl@drupal.org 4 мая 2007 в 0:13

Спасибо за развернутые ответы. Ваша позиция прояснилась.
Выводы:
1. "Лечить" заказчика.
Это не всегда возможно без собственных материальных потерь.
2. Похоже вы пытаетесь воплотить принцип конвейера в веб программировании.
Наверное это не плохо, вот только для того, чтобы его применять надо набрать достаточно большой опыт в друпале, т.к. самый простой способ не всегда сразу приходит в голову (особенно начинающему друпалеру).
3. Пора начинать конвертить сайты на 6-ку!...

Аватар пользователя Макс К. Макс К. 4 мая 2007 в 10:09

blackvl@drupal.org says: Выводы: 1. "Лечить" заказчика. Это не всегда возможно без собственных материальных потерь.

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

Если проект "не вписывается" в Ваше представление о правильном проекте, то можно отдать его другому специалисту по Друпалу или по другой CMS. А он пришлет Вам своих клиентов, с которыми не смог работать по тем или иным причинам. Все зависит от Вашего желания быть благодарным тому, кто привел Вам клиента.

Благодарные специалисты быстро находят друг друга и ничуть не затрудняются ссылаться друг на друга. Wink

blackvl@drupal.org says: 2. Похоже вы пытаетесь воплотить принцип конвейера в веб программировании.

От Вашего проницательного взгляда не скрыться. Smile Да, нужен конвейер. Примерно как в производстве автомобилей.

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

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

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

Раньше конвейер в веб-программировании был невозможен, PHP слишком низкоуровневый, чтобы заставить писать всех веб-мастеров одинаковым образом. С появлением Друпала ситуация изменилась. Это универсальная среда разработки сайтов, на которой можно поднять половину сайтов Интернета. На Друпале можно организовать реальный конвейер по производству и поддержке сайтов и этим сделать более доступным для клиентов владение динамическими сайтами.

blackvl@drupal.org says: Наверное это не плохо, вот только для того, чтобы его применять надо набрать достаточно большой опыт в друпале, т.к. самый простой способ не всегда сразу приходит в голову (особенно начинающему друпалеру).

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

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

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

Пример стандартной процедуры

Смерть для сайтов на Друпале наступает, когда клиент говорит веб-мастеру: "Со следующего месяца я не смогу выделять денег ни на поддержку сайта ни на хостинг". Веб-мастер должен знать, как на последние деньги правильно законсервировать сайт с выгодой для клиента. Если кратко, то нужно сделать следующее:

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

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

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

Перед уходом веб-мастер оставляет клиенту CD с последним бэкапом базы и всех файлов. Клиент передаст CD покупателю, который может появится только через ...надцать лет. Присутствие веб-мастера при продаже сайта уже будет ненужным.

Консервация сайта стандартная процедура. Таких стандартных процедур в жизненном цикле друпаловского сайта много:

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

Корпоративный стандарт

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

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

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

У нашего микросообщества есть свой корпоративный стандарт разработки сайтов на Друпале (см. статью CMS Друпал на концептуальном уровне) . Некоторые стороны нашего стандарта я рассказываю на Drupal.ru в своем дневнике.

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

Аватар пользователя KCEOH KCEOH 3 мая 2007 в 0:33

Макс, а вот чем заменить CCK или Views ?

В статье речь идет про обычные сайты, которые можно штамповать практически на любой CMS. А вот если клиенту нужно что-то, а-ля хабрхабра, или сайта с документооборотом?

PS
"Спешу рассказать, что в раю принята такая установка динамических сайтов:"
Господу Богу руку не жал еще?

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 13:59

KCEOH says: а вот чем заменить CCK или Views ?

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

В 5-ой версии Друпал встроил в ядро слабый вариант CCK. Можно создавать новый тип материалов. Допускается всего 2 поля, заголовок + текст. Но большой плюс, что созданные через ядро новые типы материалов будут поддерживаться Друпалом вечно.

Я уже начал на некоторых сайтах обратно переводить материалы в формате CCK на новый тип материалов, созданных через ядро Друпала. Это позволит мне удалить с этих сайтов связку CCK+Views. Обнаружилось также, что вместо создания и показ нового материала через CCK+Views часто можно обойтись таксономией.

Views, несмотря на свою изощренность, в общем-то, модуль вполне мирный и "зеленый". Он представляет материал, но сам не создает нового типа материала. При смене версий на крайний случай можно его отключить. Будет не такой удобный доступ к материалу, но сам материал не пострадает.

Разбивка модулей по цветам

Вообще, все модули заточенные на показ содержимого тем или иным способом, "зеленые". А модули создающие новые типы содержимого - красные.

Если есть принципиальный способ конвертировать новый тип, создаваемый модулем, в какой-нибудь стандартный тип (заголовок+текст) и потом обратно, то модуль считается желтым.

Например, модуль ссылок, рождающий тип заголовок+описание+ссылка считается "желтым" модулем. Если ссылочный модуль перестанет поддерживаться, то все наработанным им материалы можно будет конвертировать его к какому-нибудь стандартному типу (заголовок + описание в конце дать ссылку) и продолжать наращивать материалы. А когда появится какой-то другой модуль ссылок, еще раз конвертировать под новый модуль. В качестве ссылки скрипт-конвертор может взять самую последнюю ссылку в материала.

Но если создать через CCK какой-то тип материала из 20 полей, то в лучшем случае наработанный материал можно конвертировать в стандартный тип (заголовок+текст). Материал будет наращиваться уже в стандартном типе. А позже обратной возможности восстановить из стандартного типа какой-то специальный тип возможно и не будет. Поэтому CCK это все же красный модуль. Удобный, но чреватый.

KCEOH says: В статье речь идет про обычные сайты, которые можно штамповать практически на любой CMS. А вот если клиенту нужно что-то, а-ля хабрхабра, или сайта с документооборотом?

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

Если возможности Друпала в целом устраивает потребности клиента, то возможны два подхода для построения проекта:

1. "Красная" установка. Проект строится исходя из целей проекта, как их видит клиент. Плюсы, клиент получает то что хочет. Минус, клиент не друпальщик, и часто его желания идут вразрез с возможностями Друпала. Как результат, при сильном обновлении версии Друпала все неродное для Друпала будет сметено.

2. "Зеленая" установка. Проект строится исходя из встроенных возможностей Друпала. Плюс некоторое количество зеленых модулей. Из минусов, что не все желания клиента будут реализованы. Плюс один, он не виден сразу, но он решает все. Будет надежная и устойчивая работа сайта, версии будут меняться незаметно для посетителей и авторов.

Когда клиент заказывает сайт, он предполагает, что ему сделают "зеленую" установку. Клиенты всегда заинтересованы в том, чтобы сайт работал без проблем долгие годы. И с пониманием относятся к ограничению некоторых возможностей проекта для увеличения надежности.

Но неопытные сайтростроители часто предпочитают "красную" установку. С ней можно сделать клиенту все что тот хочет. Вопрос долговременной поддержки у неопытных сайтостроителей не стоит. Если он только полгода назад начал ставить сайты, то его не очень волнует что будет с сайтом через 5 лет, поскольку он никогда не поддерживал так долго сайты.

KCEOH says: Ты написал: "Спешу рассказать, что в раю принята такая установка динамических сайтов:" Господу Богу руку не жал еще?

Жал, как не жать. Время от времени выпадает такой счастье. После чего неделю руку не мою. Smile

Бог установщиков сайтов это Клиент. Служите не деньгам Клиента, а интересам Клиента. Клиент в ответ будет любить Вас. И будете Вы с Клиентом работать вместе долго и счастливо.

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

Аватар пользователя kiev1 kiev1 3 мая 2007 в 8:25

>а вот чем заменить CCK или Views ?
написать свои или заменить кучей своего кода вернувшись на круг первоначальных проблем

Аватар пользователя kiev1 kiev1 3 мая 2007 в 16:14

без CCK друпал не совсем то что хотелось - на CCK красиво завязаны шаблоны вывода, права доступа к отдельным полям, views, imagefield и многое другое, сам-же код CCK до элементарности прост.
например вчера заказчик хотел вывод данных в виде одних таблиц блоков из группы раздела, а завтра по другому, а потом понадобилось сортировку поменять в одном из разделов и чего-то исключить из раздела или наоборот - каждый раз будем в код лезть? А я люблю когда одним однотипным действием делается в системе большинство функционала - поэтому flexinode и его продолжение CCK - незаменимая штука.

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 17:06

kiev1 says: без CCK друпал не совсем то что хотелось - на CCK красиво завязаны шаблоны вывода, права доступа к отдельным полям, views, imagefield и многое другое, сам-же код CCK до элементарности прост.

Ну что сказать, "красные" модули они тоже разные. Если на какой-то сторонний модуль завязано много других модулей, то есть шанс, что модулю-папе не дадут пропасть.

Но все равно остается опасность более высокого уровня. Создатели ядра Друпала постоянно вбирают в ядро возможности лучших модулей. Когда в ядре будет сделан более-менее полноценный вариант CCK, то не факт, что создатели ядра побеспокоятся о том, чтобы материалы накопленный на CCK можно было конвертировать в во встроенные возможности Друпала. После встраивания варианта CCK в Друпал поддержка модуля CCK быстро затухнет за ненадобностью. Материалы накопленные на CCK начнут сдерживать смену версий на сайте.

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

Не нужно опираться на труд пчел, сидящих снаружи ядра Друпала. На 100% надежно только ядро Друпала, вот и опирайтесь на него. И будет тогда всем счастье. И тому кто поддерживает сайт и клиенту и посетителям.

Аватар пользователя KCEOH KCEOH 3 мая 2007 в 20:04

Гы... - только это и могу сказать Smile

Макс, противоречие самому себе. В 4-ом шаге - "Выход пришел в виде систем управления сайтом. В качестве CMS был выбран Drupal." и тут же - "Если задача не "ложится" на Друпал, то клиенту нужна другая CMS или какой-то специализированный движок, который больше подходит под его задачу."

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

Вся эта фигня, что клиент - Бог... Я не боготворю клиентов и деньги, у меня акценты ценностей смещены в иную сторону.

Нужную для себя информацию из статьи и комментариев почерпнул, спасибо. Тема уже превращается в фарс, и пиар, читать неитересно.

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

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 22:15

KCEOH says: Макс, противоречие самому себе. В 4-ом шаге - "Выход пришел в виде систем управления сайтом. В качестве CMS был выбран Drupal." и тут же - "Если задача не "ложится" на Друпал, то клиенту нужна другая CMS или какой-то специализированный движок, который больше подходит под его задачу."

Когда переходим на Друпал, то теряем в универсальности. Вместе с ней отпадает половина заказов, которая не укладывается в ложе Друпала. Но зато для второй половины клиентов можно делать сайты на Друпале несколько порядков быстрее. Соответственно, рынок клиентов расширяется в десятки раз.

KCEOH says: Вся эта фигня, что клиент - Бог... Я не боготворю клиентов и деньги, у меня акценты ценностей смещены в иную сторону.

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

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

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 4 мая 2007 в 0:47

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

Кстати, когда отказываемся от программирования, от универсальности не отказываемся?

Аватар пользователя Макс К. Макс К. 4 мая 2007 в 10:26

ultraboy@drupal.org says: Макс пишет: "Когда переходим на Друпал, то теряем в универсальности.". Ну что тут можно сказать... Мягко говоря, не согласен. В друпале очень много универсальности. И ты сам уже об этом писал...

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

Например, если нужен интернет-магазин с большим оборотом, то лучше посмотреть на Bitrix. Там не только магазин, но и маркетинговая часть на должной высоте. Или если предполагается, что на сайте будет один лишь сверхпопулярный форум, то можно приглядеться к VBulletin, для создания статей к нему можно прицепить небольшую портальную систему VBPortal. Если нужен магазин и CMS в одном флаконе, то интересным вариантом будет наверное Куби.

Теоретически можно доработать сайт на Друпале до любой потребности. Но использование Друпала не в своей нише вызовет перерасход бюджета у клиента. Лучше переориентировать клиента на другую CMS, если видно что задача явно не друпальская.

ultraboy@drupal.org says: Кстати, когда отказываемся от программирования, от универсальности не отказываемся?

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

Но все равно, сайтов которых можно поднять на Друпале без всякого программирования очень много, это как минимум половина сайтов Интернета. Пройдитесь по сайтам с желтых страниц Интернета. На каждом втором смело можно ставить галочку: "Его можно было бы сделать на Друпале без всякого программирования".

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 22:15

Valeratal says: А разве CMS и движок это не одно и тоже?

"Движок" - это жаргонное обозначение готовой программы, которая работает на сайте и организует какой-то сервис.

Движок может поддерживать:

- форум
- чат
- магазин
- блог
- ...

CMS это система управления сайтом. Она вбирает в себя возможности нескольких движков.

CMS тоже является движком, но более универсальным чем другие движки.

Друпал (на всякий случай) является одним из представителей CMS.

Аватар пользователя kiev1 kiev1 3 мая 2007 в 21:48

> материалы накопленный на CCK можно было конвертировать
ССК как и флексинод был - сделан он правильно - то есть пару таблиц и все в них ясно, сконвертировать даже вручную думаю будет не очень сложно.

Аватар пользователя Макс К. Макс К. 3 мая 2007 в 22:29

kiev1 says: ССК как и флексинод был - сделан он правильно - то есть пару таблиц и все в них ясно, сконвертировать даже вручную думаю будет не очень сложно.

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

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

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

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

Аватар пользователя axel axel 4 мая 2007 в 10:56

Пример с рекурсией по-моему не удачен. В PHP подобные конструкции встречаются не часто (в друпале это есть в работе таксономии), скорее наглядней было бы привести пример объектной программы vs использующей функции, но опять таки как раз в друпале классического объектного PHP очень мало. Рекурсия напротив на мой взгляд очень наглядна, а в функциональных языка (LISP и др.) ещё и более эффективна в реализации (в императивных языках чаще наоборот). В общем много неоднозначного с приёмами программирования - что уместно в одной системе, не катит в другой. Даже в рамкамх одного я/п.

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

Аватар пользователя Макс К. Макс К. 4 мая 2007 в 23:19

romand@drupal.org says: хм, а кто приходит на их место?

Между недорогими фрилансерами (вольными работниками) и дорогими фирмами есть еще третий игрок, сообщества фрилансеров.

При заказе через фрилансера клиенту приятно, что исполнитель получает все деньги без посредников. Но надежность никакая. Сегодня он есть, завтра его нет.

При заказе через фирмы основные деньги съедает аренда, оплата труда секретарш и прочего персонала. До собственно установщика сайта доходит в лучшем случае 20-30% от стоимости заказа. Зато надежно, фирма так быстро не исчезнет, как фрилансер.

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

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

По мере роста сообществ фрилансеров они будут отъедать свою долю рынка у одиночных фрилансеров и у фирм.

Аватар пользователя gsnx gsnx (не проверено) 22 ноября 2007 в 14:28

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

Аватар пользователя Станислав_Евтушенко Станислав_Евтушенко 11 января 2012 в 15:20

Статья "Веб-программирование, 7 ступенек в рай" действительно резко отличается от большинства статей программистов. Чувствуется, что заказчику легко работать с Максимом, а ему - с заказчкиком. Наверное, начинающий программист во многом похож на заказчика и поэтому эту статью и все комментарии к ней прочел с большим интересом.
Один вопрос:
- Какого рода задачи неудобны для Друпала, ну, скажем так, 7й версии (максимально абстрактно) и, особенно, в перспективе, и с чем в нём это связано?
Дело в том, что мне надо быстренько сделать сайт и нет времени пробовать разные CMS.
-

Аватар пользователя Orion76 Orion76 11 января 2012 в 16:34

излишества в любую сторону - нехорошо ...

Хотя , как мне кажется, эта статья задумывалась для других целей и она этих целей достигла-))

Аватар пользователя Станислав_Евтушенко Станислав_Евтушенко 12 января 2012 в 14:11

Статья поднимает по-видимому, перспективную проблему - проблему поддержки сайтов в условиях постоянно меняющейся среды программирования.
В принципе решений два:
- либо усложнять среду так, чтобы она не отрицала, а снимала в себе предыдущие (то есть понимала стариков, скажем, латала дырки безотносительно к "цвету" кода);
- либо обеспечить механизм обновлений за счет стандартизации и унификации программных кодов.
Именно второму способу решения этой проблемы и посвящена эта статья.
Предлагаемое решение банально, но важно то, что оно в русле второго направления, во-первых, похоже, единственное, во-вторых, заманчиво для тех, у кого нет претензий сделать не просто легко и дешево поддерживаемый, а именно хороший сайт, ибо использование только готовых блоков хоть и суживает функционал, но зато резко облегчает работу.
Единственный недостаток этой стратегии в том, что вся сеть становится кривой на одну и ту же ногу. Этот вопрос автор статьи обсуждать отказывается и правильно делает - это действительно проблема другой ветки.
Но тот вопрос, что задал я - про абстрактную типологию задач, плохо решаемых Друпалом - по-моему, вполне может быть рассмотрен, как относящийся к ветке о тотальном применении стандартов той или иной CMS.