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


Изображение пользователя Макс Кириленко.
  


Рубрика:

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

Расскажу о 7 ступенях, по которым мне пришлось подняться, прежде чем попал в рай: 

Elysium

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 или сильной смены версии Друпала. Выбор плохо поддерживаемого модуля может в будущем повлечь невозможность обновлять проект.

Зеленые и красные модули

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

  • “Зеленые” модули. Не создают данные в своем собственном формате. Или создают в свое формате мелкие данные, которые не жалко потерять. Также сюда относятся модули, которые визуализируют данные, сохраненные в стандартных форматах Друпала. И модули, создающие удобства при работе со стандартными данными.
  • “Красные модули”. Создают серьезные данные в своем формате. При умирании такого модуля вместе с ним умирают наработанные им данные.

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

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

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

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

Стал реализовывать функционал сайтов только через зеленые модули.

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

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

Красных модулей у меня в установке принципиально нет.

Райская установка 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.ru:

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

..........................
Макс Кириленко, подбор названий и доменов


Помогите пожалуйста разобраться

Здравствуйте, у меня есть одна небольшая проблема, которую я описал тут http://drupal.ru/node/26558 - просто не хочу дублировать. Не могли бы Вы ответить там на форуме?

Заранее большое спасибо.

 


Изображение пользователя Макс Кириленко.
  

CCK - "красный" модуль Друпала

Помочь Вам не смогу, не понял из Вашего техзадания что именно Вам нужно.

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

Многие ссылаются на свой опыт, что обновление сторонних модулей (например, CCK) на новую версию Друпала у них проходит без проблем.

 

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

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

Можете еще учесть такой факт. Создатель Друпала кормится с Drupal.org и неплохо кормится. Он получает миллионные инвестиции на проекты, связанные с Друпалом. А создатели CCK работают на энтузиазме. В декабре создатель Друпала Дрис проводил офф-лайновый марафон, посвященный встраиванию CCK в 7-ую версию Друпала. Были приглашены авторы модуля CCK. Им был оплачен перелет, проживание, кофе с коржиками. На память пара фото с Дрисом, где создатели CCK лично жмут руку Дрису. Вот пожалуй и вся выгода от многолетней работы над модулем. Не ждите, что данные CCK будут сохраняться с тщательностью сохранения данных от родных модулей Друпала.

Возражение: "Фунциональность CCK будет встроена в Drupal-7"

Часто это подается как гарантия того что можно можно смело пользоваться сторонним модулем CCK.

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

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

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

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

Часто бывает, что помимо использования CCK на сайте пишут php-скрипты, завязанные на поля CCK. Скрипты тоже придется переделывать и довольно серьезно.

Пример использования стороннего модуля

Когда сайт Drupal.ru сидел на 5-ой версии, поставили на него модуль вики. К тому времени самый первый модуль Wiki уже умер, не сумев даже пережить портирование на версию 4.7 Друпала. Поставили на Drupal.ru, похоже, модуль Liquid. Был выделен домен третьего уровня, http://wiki.drupal.ru/ Администратор PVasily старательно тащил в Wiki.drupal.ru самые интересные материалы и побуждал к этому других.

Из принципа я отказывался на сайте Drupal.ru писать в wiki и продолжал пополнять свой блог. В 2007 г. в статье "Модули book и wiki в CMS Drupal" я писал: "Модуль Liquid запускает на сайте полноценный wiki-движок, хранит данные в собственном формате. Тоже когда-то умрет, как и модуль Wiki".

Прошло 2 года, модуль Liquid действительно умер в версии 5.x-1.x-dev. Drupal.ru перешел на 6-ую версию. И в одночасье умерли на wiki.drupal.ru все данные, которые модуль хранил в своем формате.

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

Или на худой конец скачать wiki.drupal.ru офф-лайновым браузером и по ошибке 404 показывать статичную версию вики. Пусть не будет редактирования, но поисковики будут по прежним адресам wiki.drupal.ru/* приводить посетителей. Главное, труд по созданию wiki не пропадет зря.

Однако результаты работы умершего модуля сохранить не смогли.

Бюджет

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

Когда на wiki.drupal.ru ставили модуль вики, думали что он будет поддерживаться вечно. А когда через 2 года модуль умер, то сохранение материалов wiki.drupal.ru в Drupal-6 оказалось за пределами возможностей бюджета сайта Drupal.ru. 

Зато все мои статьи, которые я писал в моем блоге на Drupal.ru, прекрасно живы. Модуль blog это родной модуль Друпала.

И все подшивки (книги) которые ведутся на Drupal.ru, прекрасно переходят с одной версии Друпала на другую. Модуль book это тоже родной модуль Друпала. Подшивки на сайте Drupal.ru будeт поддерживаться на Друпале все время, пока жив сам Друпал. Даже если от модуля Book откажутся или заменят его другим, будет сделан конвертор данных, накопленных встроенным модулем Book.

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

История

Модуль CCK родился не с нуля. До него был модуль Flexinode. Но CCK оказался более совершенным и все быстро перешли на него. Модуль Flexynode с трудом перевал в версию 4.7, но затем умер.

Еще спустя пару лет вышел Drupal-6 и прекратилась поддержка Друпала для версии 4.7. И на Drupal.org я прочитал крик души:

"У меня 40 сайтов на Друпале 4.7, все материалы накапливаются с помощью модуля Flexinode. Drupal-4.7 больше не поддерживается, к нему появились эксплойты. Что мне делать?"

Отказаться от использования "красных" модулей.

Бесплатный совет друпальщикам

Каждый имеет право на своем сайте ставить любой сторонний модуль. Но когда мы делаем серьезный проект, да еще клиенту, то нужно стараться все данные хранить только во встроенных форматах Друпала. Только они сохраняются на 100% при мажорных сменах версий Друпала.

Когда красный модуль сохраняет труд посетителей сайта в своем формате, то рано или поздно эти данные пропадут:

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

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

Пример 2

Сейчас делаем модуль "Монетизатор", он же многопользовательский магазин. (Проект "Друпальский Монетизатор сообществ").

Несмотря на его сложность, модуль будет зеленым. Большинство материалов будет хранится в родных для Друпала форматах:

  • Отзывы это отдельный тип материалов Друпала вида "отзыв". Оценка (положительная, нейтральная, негативная) представляет из себя категорию из трех соответствующих рубрик. Для ника продавца создается отдельная категория с полем для свободного ввода рубрики. Все отзывы на продавца будут накапливаться на одной накопительной странице средствами Друпала.
  • Товар это обычная нода вида "товар". Классифицируются товары через систему категорий Друпала. Опять же средствами Друпала поддерживаются RSS-каналы для подписки на определенные рубрики товара. Можно переводить товары на разные языки с помощью встроенных средств Друпала.
Модуль сохраняет в своем формате лишь цены. Даже если когда-то модуль "Монетизатор" умрет, то исчезнет лишь возможность продавать. Но останутся наработанные отзывы и товары. А вместе с ними будут живы все ссылки на эти страницы и сохранится поток посетителей с поисковиков. 

..........................
Макс Кириленко, подбор названий и доменов


во-первых -

во-первых - знаете ли Вы точно - что не будет сделана конвертация данных из старого ССК в седьмом Друпале? Вы это точно знаете? или просто предполагаете?

во-вторых - кто сказал что конвертация из модуля book будет возможна всегда? А если не будет сделана конвертация? и все данные модуля book погорят белым огнём в какой-нибудь девятой ветке? что тогда? Как Вы можете так уверенно это утверждать - вот что мне интересно? и мне интересны реальные доказательства всей этой теории?

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

 

Понимаете - лично для меня это всё пока просто размышления - не более. Бездоказательные пока что. Это просто Ваши предположения - не более того 


разработчики

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

 это с форума Друпал.ру. Что вы на это ответите?

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

 


Изображение пользователя Макс Кириленко.
  

Все сторонние модули - тестовые

Гость написал:
"разработчики Flexinode честно предупреждали, что этот модуль делается исключительно для тестов и не предусмотрен для чего-либо другого, тем более, для production сайтов. так что все справедливо."

Разработчики стороннего модуля CCK тоже честны. Они нигде не гарантируют что будут поддерживать модуль CCK вечно. В любой момент они имеют полное моральное право прекратить разработку своего модуля. Особенно если Друпал-7 вберет в себя основной функционал CCK.

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

Я бы большими буквами написал на каждом красном модуле: "Не рекомендуется для использования на production сайтов".

 

Гость написал:
"И приведите пожалуйста ещё примеры подобных модулей - из-за которых разработчики теряли свои данные - раз четверть модулей умирает с каждой новой версией друпала."

Пример http://wiki.drupal.ru/ Вас не убедил? Улыбка

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

Пройдитесь по списку сторонних модулей Друпала. Найдите модули, которых нет в версии Drupal-6 и которые создают данные. За каждым таким модулем стоит целая череда трагедий на сайтах, когда уже пора менять версию Друпала, а модуль не поддерживается.

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя Макс Кириленко.
  

Жить или не жить модулю CCK?

Гость:
"во-первых - знаете ли Вы точно - что не будет сделана конвертация данных из старого ССК в седьмом Друпале?"

Конвертация возможна 2-мя способами:

Способ 1. Дрис, основатель Друпала, будет строить работу с CCK на основе таблиц, уже сделанных модулем CCK в предыдущих версиях.

В Drupal-7 будет встроен не весь функционал CCK, часть данных Drupal не будет использовать. В этом способе работать данными, порожденными модулем CCK, будут 2 хозяина - модуль CCK (он уже есть для Drupal-7) и сам Drupal-7. Нереально полагать, что Дрис будет пожизненно подстраиваться под формат данных, которые развивает создатель CCK. Подстраиваются под формат Друпала создатели модулей, а Дрис работать на чужих форматах незачем, все форматы данных Друпала должны быть интегрированы с Друпалом.

С точки зрения разработчика Друпала-7 Дрис должен иметь свою собственную структуру данных, обеспечивающих некоторые возможности CCK. Только так Дрис может получить полную свободу и грамотно интегрировать некоторые возможности CCK в Drupal-7. 

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

Кто будет писать конвертер

Дрис? А зачем ему это? Дрис делает Друпал и ему хватает забот о сохранении данных, созданы родными модулями Друпала.

Может быть, создатель модуля CCK? А зачем ему тратить время на конвертер, когда они заняты разработкой более мощной версии CCK для Друпала-7?

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

Многие владельцы сайтов не смогут выделить достаточный бюджет для конвертирования и годами наработанные CCK поля пропадут.

Гость:
"Вы это точно знаете? или просто предполагаете?"

Если Вам нужны точные прогнозы на 2007-2019, то это к Павлу Глобе.

Но полагаю у Вас есть своя голова на плечах. И вы можете оценить ситуацию сами.

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

Разработчики старых CCK-ориентированных модулей должны будут сделать выбор:

  • поддерживать ли дальше свой модуль, ориентированный на формат CCK
  • или поддерживать аналогичные возможности, но уже опираясь на формат CCK-данных Drupal-7?

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

А все новые разработчики модулей поддержки CCK-формата данных будут сразу делать свои данные под CCK-возможности, предоставляемые Drupal-7.

Весьма скоро модуль CCK останется один-одинешенек. И, вполне возможно, даже не доживет до 8-ой версии Друпала.

"Гость написал"
"во-вторых - кто сказал что конвертация из модуля book будет возможна всегда? А если не будет сделана конвертация? и все данные модуля book погорят белым огнём в какой-нибудь девятой ветке? что тогда?"

У Дриса есть нет никакой ответственности за данных сторонних модулей. И есть большая ответственность за данные встроенных модулей Друпала.

Родной модуль Book из версии в версию встроен в Друпал. Накоплена масса информации в нем. С какого перепуга Дрис вдруг скажет "Все, мне book что-то разонравился, его больше не будет"?

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

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

Противоположный пример. А Вы можете себе представить, что инсталлятор Drupal-7 будет заботиться о конвертации данных стороннего модуля CCK в свой собственный формат? Я не представляю. Улыбка

Гость написал:
"Понимаете - лично для меня это всё пока просто размышления - не более. Бездоказательные пока что. Это просто Ваши предположения - не более того "

Точно такие же слова говорил администратор Drupal.ru PVasily, когда ставил на Drupal.ru вики-модуль. Он старательно пополнял вики и призывал к этому других друпальщиков.

Сходите на http://wiki.drupal.ru/ и посмотрите, что стало спустя 2 года с данными, которые старательно собирали wiki-модулем. От них осталась только пыль. И это на сайте, где нет проблем с квалифицированным друпальщиками.

При этом все мои статьи на Drupal.ru, которые я писал с помощью родного модуля Blog, прекрасно живут. Как живут подшивки (книги) созданные на Drupal.ru с помощью родного модуля Book. И будут жить еще очень долго.

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

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя Макс Кириленко.
  

Чужой ребенок

Гость:
"А если Дрис учёл ошибку - которая произошла с модулем flexinode? и постарается избежать такого в будущем. "

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

NewsProm.ru сообщает: "Воспитательница детского сада в Нижневартовске собирала детей на улицу. Она забыла одеть трехлетнему мальчику валенки. Ребенок около часа ходил по снегу в носках. Вызванная затем скорая помощь поставила диагноз — обморожение первой степени."

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

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

 

Гость:
"откуда Вы знаете - что Дрису ни до кого нету дела?"

MicroSoft сделала операционную систему Vista. Многие старые программы сторонних разработчиков на ней не идут. А значит и недоступны данные, созданные этими программами. Хорошо, если разработчик программы еще занимается и можно купить обновленную под Vista версию программу. А если программа больше не поддерживается, то можно будет еще несколько лет сидеть на XP, пока Microsoft не прекратит ее поддержку. Народу Vista не нравится, лучше бы XP подольше продолжали поддерживать.

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

Если бы Дрис создавал коммерческую CMS, то от него после первой же смены API ушло бы много клиентов, которые успели навертеть кучу своего кода. Но Дрис делает Drupal бесплатно и народ терпит. Народ пишет модули, скрипты, темы для Друпала, зная что уже через 1-2 года этот код перестанет работать.

Можем ли мы себе представить, что Java каждый год будет менять свое API и Ява-разработчикам придется переписывать свой код каждый год? Или что Консорциум Всемирной паутины W3C каждый год начнет менять стандарты HTML без обратной совместимости? А в Друпале именно так.

И после этого Вы серьезно верите в то, что Дрису есть дело до рядовых пользователей Друпала? 

..........................
Макс Кириленко, подбор названий и доменов


ну хорошо -

ну хорошо - история покажет

звучит у вас всё вроде убедительно. но на слово всё равно трудно поверить. Да - у меня пока опыт не так велик - но вы рисуете какую то уж слишком мрачную картину. Сплошные чёрные краски и серое небо. Буду разбираться подробнее.

ну - в общем спасибо большое за подробнейший ответ Улыбка


Изображение пользователя Макс Кириленко.
  

Небо-то как раз райское

Гость
"Да - у меня пока опыт не так велик - но вы рисуете какую то уж слишком мрачную картину. Сплошные чёрные краски и серое небо."

Небо-то как раз райское. Улыбка

Все определяется Вашими целями.

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

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

Сайты-зверинцы

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

  • на сайте зверинец движков
  • движки жестоко бьются между собой за файл index.php и за папку forum
  • бывший веб-мастер развел движки по разным доменам третьего уровня
  • движки перевязаны между собой самописными скриптами
  • нет единого поиска
  • нет единой авторизации
  • нет единого оформления
  • сайт регулярно ломают то через один, то через другой движок.

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

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

Зверинцы на друпаловских сайтах

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

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

Сайт, обвешанный "красными" модулями также лишен будущего, как и сайт стоящий на 10 разных движках.

Статистика

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

При таких условиях при смене версии Друпала 75% сторонних модулей выживает, 25% вымирает.

Считайте, если на сайте стоит 4 красных модуля, то каждый год один из них гарантированно умрет вместе со всеми данными, которые он создал.

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

..........................
Макс Кириленко, подбор названий и доменов


Большое

Большое спасибо за материал. Это вам не записки на тему "Как инсталлировать модуль TinyMCE". Это абстракция от абстракции, выводы многолетнего опыта.

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

(боюсь, модуль "карма" относиться к "красным")

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

С уважением - Михаил Сухарев


Изображение пользователя Макс Кириленко.
  

Модуль "Карма" - зеленый

Михаил Сухарев:
(боюсь, модуль "карма" относиться к "красным") 

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


Линия раздела между зелеными и красными модулями

Можно спокойно собирать и терять информацию от пользователей сторонними модулями, если:

  • эта информация выдается на сайте в обезличенном виде
  • не требует от пользователей больших движений

Например:

  • Views
  • Карма
  • Опросы при условии, что они проводятся только администрацией.
Это все зеленые модули.

Если же сторонний модуль:

  • собирает много информации от пользователей
  • эта информация выставлена на сайте
  • информация помечена именем пользователя
  • пользователь считает ее своей и гордится ею

то это красный модуль. Пример:

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

Хамелеоны

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

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

Но если в каком-то типе информации всего пара строчек, а остальное описывается через десятки полей CCK, то это уже красное применение CCK.

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

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

Цель

Главная цель "зеленого" построения сайтов - гарантировать пользователям, что 90-95% введеной ими информации будет сохранено спустя годы.

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

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя leo7.
  

Дрис - ни до кого нету дела?

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

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

Почему? Потому что ему действительно ни до кого нет дела. Можно переспросить у Глобы :)

на таком уровне информации достаточно (дата рождения Дриса известна).

..........................
Структурные форумы


Изображение пользователя Макс Кириленко.
  

Даже 2 года раздражает

Leo7: "Дрис именно так будет себя вести всегда - игнорировать напрочь интересы разработчиков сторонних модулей.Почему? Потому что ему действительно ни до кого нет дела"

Кстати, Дрис меняется. Сообщество Drupal.org понемногу наставляет его на путь истинный:

  • между API 4.7 и 5.0 промежуток был 5 месяцев
  • между 5.0 и 6.0 - год
  • между 6.0 и 7.0 - два года
  • ...

Но даже 2 года раздражает. В Windows программы сторонних разработчиков спокойно работают по 10 лет и более и их не переписывают каждые два года. Photoshop спокойно читает свои старые файлы. Совместимость от старых версий к новым всегда стараются соблюдать.

У меня одна программа еще под NT была написана. Работает.

..........................
Макс Кириленко, подбор названий и доменов


Но новый Photoshop

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

Похожая ситуация с ArchiCAD но совсем иная с 3ds Max. Аудитория пользователей гораздо моложе и значительно приобщенней к ИТ.


Изображение пользователя Макс Кириленко.
  

Друпал такой совместимостью явно н

Гость: "Но новый Photoshop некоторые старые форматы уже и не создает, хотя правильно они их все же читает."

И не только читает, но и может сохранить их в новом формате. Нельзя только из старого Photoshop читать файлы нового формата. Это называется "совместимостью снизу вверх".

Друпал такой совместимостью явно не обладает. Вы не сможете находясь в 6-ой версии Друпала вставить модуль из 5-ой версии и сохранить его как модуль 6-ой версии.

Также Photoshop бережно относится к сторонним плагинам. Он читает их все, даже самые старые.

У Друпала близко нет такого вежливого отношения к разработчикам сторонних модулей. API в нем меняются слишком часто.

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя leo7.
  

Дрис не меняется

Но даже 2 года раздражает. В Windows программы сторонних разработчиков спокойно работают по 10 лет и более и их не переписывают каждые два года. Photoshop спокойно читает свои старые файлы. Совместимость от старых версий к новым всегда стараются соблюдать. 

Т.е. вы утверждаете, что Дрис приготовил для кого-то БОЛЬШОЙ подарок? Кто-то, кто по-сообразительнее, смастрячит сервис, обеспечивающий востребованные совместимости, и отгребёт БОЛЬШУЮ кучу бабла?

:)

я в долю не пойду :)

Дрис не меняется, и не будет меняться. Он будет переть вперёд, просто у него новых дорог всё больше становится: пересечений, ответвлений, перекрёстков... вот и притормаживает. И ему на всех наплевать - природа у него такая :)

Таким он родился.  Хотите посмотреть аналоги?

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

Боб Хоскинс - у нас прославился исполнением роли Лаврентия Берии в фильме "Ближний круг". В его исполнении Лаврентий Павлович и смешон и страшен и убедителен, как никогда до этого в других фильмах.

..........................
Структурные форумы


нету ссылки одной в конце статьи

Обсуждение похожей темы "Drupal и будущее веба"

Изображение пользователя Макс Кириленко.
  

Добавил ссылку в статью

Спасибо, добавил ссылку в статью: "Drupal и будущее веба"

..........................
Макс Кириленко, подбор названий и доменов


Почитал,

Почитал, понравилось.
Это чем-то напоминает философию или политику, которую нужно использовать для стройности личного развития и развития системы.
Понравился и подход к классификации.
Но если быть честным, то такой подход справедлив для меня с моими знаниями. Я могу помочь сделать удобным и понятным только то, что уже существует. А с возможностями автора - знания инженерного программирования, это подход потребительский.
Как минимум свои сайты нужно было б делать с максимальным привлечением сторонних элементов, чтоб расширять спектр стабильных и интересных функций. Ведь именно так и не как иначе они появятся в движке или перейдут в разряд "зеленых". Да и такому специалисту с такой культурой программирования и философией просто обязательно нужно поддерживать разработку и техническое совершенствование и цмски, и сторонних модулей.
Ведь если взглянуть на движок, то политика как раз склоняется в сторону разделения и максимального выбора с унификацией стандартов разработки. Именно такой подход даже в работе с ССК позволит решить вопрос его существования. Хотя не спорю, что такой подход у независимого разработчика, простого стороннего компонента, вызовет массу внутренних возражений с еще большим количеством аргументов в пользу произвольного авторства.
Лично меня это все побудило к действию, так что цель статьи достигнута. За что автору отдельные комплименты.

Изображение пользователя Макс Кириленко.
  

Врачам не сильно нравится врач

Гость: "Как минимум свои сайты нужно было б делать с максимальным привлечением сторонних элементов, чтоб расширять спектр стабильных и интересных функций.

Зачем? Раскручивать клиента на еще больший бюджет? А через года-два появится новая версия Друпала и все "красные" функции отвалятся при переезде. 

Мастерство веб-мастера определяется переездом на новую версию CMS. Если после переезда половина данных сайта не смогла быть использована в новой версии, то все, профнепригоден.

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

Гость: "Ведь именно так и не как иначе они появятся в движке или перейдут в разряд "зеленых"."

Разработчики Друпала наблюдают за модулями. Функции самых интересных из них включают в ядро. Но при этом не заботятся о сохранении формата данных, наработанным этим модулем. Что называется, "сожрать модуль". Все те, кто годами пользоваться модулем и создавал ему популярность, теряют наработанные данные.

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

Гость: "Да и такому специалисту с такой культурой программирования и философией просто обязательно нужно поддерживать разработку и техническое совершенствование и цмски, и сторонних модулей."

Говорить про мою культуру программирования сложно. Я как раз в статье ратую поменьше программировать на PHP и заниматься программированием на сверхвысоком уровне - через кнопочки и галочки в браузере и строгим использованием зеленых модулей. В профессиональной программистской среде такие призывы не всегда воспринимаются однозначно.

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

..........................
Макс Кириленко, подбор названий и доменов


все тот же

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

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

Так что полностью с вами согласен. Но к сожалению в подлунном мире только так и идем в перед: придумали, навесили, полностью переделали, не получилось, сделали новое, получилось лучше чем ожидали и опять все с начала….

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


Внутренние мечты жлоба заказчика

"Мастерство веб-мастера определяется переездом на новую версию CMS"

Т.е. не CMS существует для сайта, а сайт для CMS?  Если сайт собран достойно на 6-ке - зачем его пересобирать на 7-ке? Из-за мифических, за 4 года не обнаруженных, багов безопасности, которые резко проявятся когда 6-ку перестанут поддерживать? И все сообщество будет как бараны реветь что Дрис не правит этот супер-баг и не сможет само исправить?

"Модуль умирает"

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

У вас какой то потребительский взгляд на процесс разработки ПО, в данном случае - сайта. Типа нашурашить мышкой и не кодить. А почему тогда Drupal позиционируется именно как гибкая CMF - фреймворк, на котором многие просто кодят. И не зависят ни от каких модулей. А при обычных требованиях заказчика - сделать какой им надо сайт, а не какой там мышкой потыкав можно сделать, ваши суждения вообще ни в какую не влазят. Даже на уровне тем не обходится без кодинга, а уж функционал ... Хуки и api - зря придуманы в друпале, ими нельзя пользоваться?

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

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

p.s. функционал друпала из коробки - бедноват, модулями исправляется, но все равно сайты далеко не любые а некие типичные можно собрать. Только CCK + Views улучшают ситуацию, но и то не кардинально. Сайты - это не только визитки и блоги ...


Изображение пользователя Макс Кириленко.
  

Ассемблер никто не отменял

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

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

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

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

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

 

Гость: "А те сайты, которые на самописах или фреймворках - вообще инопланетяне наверное делают. Для инопланетян. Это же надо - программируют там. А как они дальше то, а их клиенты несчастные ... "

Бюджеты разные бывают:

  • За 1000$ кодировать сайт с нуля возьмется только студент-энтузиаст
  • при бюджете 1 млн. долларов на готовый движок никто смотреть не будет, за такие деньги кодеры сделают все что скажешь.
Ассемблер никто не отменял, но на нем уже почти никто не программируют. Так и программирование сайта "через галочки в браузере" быстро вытесняет традиционный php-кодинг. 95% клиентов вполне устраивает тот функционал, который дает CMS и модули.

..........................
Макс Кириленко, подбор названий и доменов


Макс, спасибо

Макс, спасибо за ответ.

Там да - опечаточка - не клиенты-жлобы,  а заказчики-жлобы Улыбка Клиентов и мы любим.

Если сайты нужно создавать на языке CMS, без кодинга, то можете тогда озвучить роль программиста в мире друпал?  Бесплатно для других модули создавать? Пилить сук на котором сам сидишь? Чето не понимаю. Или потратить лучшие годы своей програмерской жизни разбираясь как настраивать написанное другими?

Вот например сейчас D7, тормозной намного предшественника, гора недоделанного, непротестенного(модули), работы программистам - немерянно. Переезд с 6-ки - наверное и не реален в большинстве случаев. Смысл кодерам напрягаться? Баги выявлять и т.д.? Ведь пользователи уже ждут. Когда какой модуль появится и в какой версии.  

Про ассемблер понятно, но с него ушли то куда - в delphi, c++, т.е. тоже в кодинг

>>За 1000$ кодировать сайт с нуля возьмется только студент-энтузиаст

с нуля - это со своих наработок наверное? верно сайты разные бывают. Возьмутся и еще как. Для провинции например сумма серьезная - на месяц работы.

И в заключении, чтобы не быть голословным, возьмем реальное прошлое ТЗ с сайта друпала:

http://www.drupal.ru/node/54844

возможно такое готовеньким сделать, не кодя? Если да, то например как и почему в теме разрабы тогда такие цены загибают? За настройку? На самописе например можно за месяц/полтора поднять. 1000/1500$ я писал.

 


Изображение пользователя Макс Кириленко.
  

Вариант без кодинга

Гость: "Если сайты нужно создавать на языке CMS, без кодинга, то можете тогда озвучить роль программиста в мире друпал? Бесплатно для других модули создавать? Пилить сук на котором сам сидишь?"

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

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

Но сильно расстраиваться по поводу ненадобности программистов я бы не стал. В свое время были телефонные барышни, которые вручную соединяли абонентов. Когда телефон пошел в массовы, стало очевидно, что барышень для облуживания телефонных разговоров скоро не хватит. Решение пришло в виде автоматического набора номеров телефонов. А барышни остались только в:

  • Кремле
  • военных коммутаторах
  • регистратуре гостиниц.

Сейчас идет повальное обзаведение народа собственными сайтами. Явно, что каждый начинающий интернетчик не будет обзаводится собственным программистом. Будущее за сайтами, поддерживаемыми без программистов. Один из вариантов - Ucoz.ru, где все программирование сайта делается через браузер включением нужных модулей и настройкой их.

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

 

Гость: "Про ассемблер понятно, но с него ушли то куда - в delphi, c++, т.е. тоже в кодинг"

Щелкание галочками в панели администратора - это тоже кодинг. Улыбка Только более высокоуровневый.

Программирование (настройка поведения сайта) сайта будет востребована всегда. Но она с годами становится все более и более человекопонятной и доступной даже начинающим.

Если говорить о Друпале, то в нем уже в 6-й версии начался переход от банальных настроек сайта к возможности программированию поведения сайта. Взять те же триггеры. Если воспринимать их как события в JavaScript, то они дают доступ к созданию полноценного языка программирования сайта на Drupal. Модуль Rules первый шаг к этому. Когда подобный модуль будет включен в ядро Друпала, он получит свой язык программирования высокого уровня. Причем пользоваться им смогут даже секретарши. (К примеру, доступ к php-кодингу секретерше никто не даст, это слишком низкоуровневая возможность).

 

Гость: "возьмем реальное прошлое ТЗ с сайта друпала: http://www.drupal.ru/node/54844 возможно такое готовеньким сделать, не кодя?"

Заказчик хочет получить Photoshop, встроенный в бизнес-процеес его фотолаборатории.

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

 

Гость: "На самописе например можно за месяц/полтора поднять. 1000/1500$ я писал."

Студент может взяться поднять этот заказ и за 300$, особенно если возьмет их вперед. Но доводить до ума, поддерживать и развивать самописный код вряд ли кто-то возмьется. В том числе сам студент.

Сайт это как автомобиль:

  • есть разовые расходы на покупку
  • дальше следуют постоянные расходы на содержание.

Купить машину можно и за 1000$, но в первые же пару месяцев придется еще вложить столько-же. Затем постоянно менять что-то сыпающееся. И ездить только каждую четную неделю.

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

Вариант без кодинга

Для клиента с фотолабораторией наем программиста очень дорогостоящая вещь.

Проще было бы и так небольшие 20 т.р. на проект потратить на нормальное проектирование сайта. А обработку фотографий отдать сторонним сервисам.

Например, пусть клиенты:

  • ставят Picasa
  • правят в ней фото
  • публикуют на Google
  • кидают фотолаборатории ссылку на свою галерею, которую нужно опубликовать.

Если клиенту не нужно править фото, то он может напрямую публиковать свои фото на Google.

Принять готовую ссылку на фотогалерею и сопутствующую информацию можно через готовый модуль webform. 

..........................
Макс Кириленко, подбор названий и доменов

Арендуйте или купите сайт Razgonka.ru

Аренда или покупка сайта Razgonka.ru
Подробнее...

Последние комментарии

Новые пользователи

  • Юлия Шпренгер
  • Evan
  • Роман12358
  • Наделяев Конста...
  • Olga D