1 мая 2007 в 11:19
Dries Buytaert выложил видеозапись своего выступления "State of Drupal" на Open Source CMS Summit at Yahoo! - http://buytaert.net/state-of-drupal-march-2007 (или здесь - http://drupal.org/node/131691).
Я не слишком хорошо воспринимаю английский на слух :), но мне было интересно почувствовать атмосферу этого собрания и посмотреть на нашего взъерошенного "отца-основателя" вживую. Ну и произношение, конечно - их "Джюп'ол" vs. наш "Друп'ал". 
А если серьезно, то один из тезисов выступления Dries состоит том, что будущее веба (и, соответственно, роль Drupal) - за реализацией тенденции на удаление "посредников" (дизайнеров, программистов) из человеческого взаимодействия в Интернете. (Так я понял после беглого просмотра текста этого выступления. Потерял ссылку и не могу прочитать внимательнее... Кстати, никто не переводил его на русский?)
С самим тезисом не могу не согласиться, верный тезис и тенденция такая есть. И соображения Макса (Razgonka.ru) о "взаимозаменяемости" drupal-девелоперов хорошо сюда вписываются.
Но, в силу известной "непростоты" Drupal, не получается ли, что какая-нибудь "попсовая Джумла" будет ближе к реализации этих принципов? Обсудим?
Комментарии
vadbars@drupal.org пишет: один из тезисов выступления Dries состоит том, что будущее веба (и, соответственно, роль Drupal) - за реализацией тенденции на удаление "посредников" (дизайнеров, программистов) из человеческого взаимодействия в Интернете. Но, в силу известной "непростоты" Drupal, не получается ли, что какая-нибудь "попсовая Джумла"
будет ближе к реализации этих принципов?
Мне кажется, что дело не в конкретной CMS, а во внутренней дисциплине разработчиков сайтов на CMS. Избавится от присутствия на сайте веб-программистов и веб-дизайнеров разработчики сайтов могут хоть сегодня. Было бы желание. И понимание необходимости такого шага.
Для чтения:
Статья "Веб-программирование, 7 ступенек в рай"
http://www.drupal.ru/node/5344
Из статьи:
Будущее, Lisp-подобный язык Dript заменит PHP в нодах
Подробнее о Дрипте не читал, но это направление мне уже не нравится, некий аналог TypoScript, осваивать ещё один синтаксис, зачем?
А интервью щас послушаю, спасибо vadbars за линки.
romand@drupal.org says: Подробнее о Дрипте не читал, но это направление мне уже не нравится, некий аналог TypoScript, осваивать ещё один синтаксис, зачем?
Если исходить из того, что Друпал это язык программирования сверхвысокого уровня и выбирается один раз и надолго, то PHP для него слишком низкоуровневый язык. Хорошо вот ты знаешь PHP, тебе проще изучить способы его вставки.
Для тех, кто никогда не знал PHP, проще изучить Dript. Он позволяет легко программировать в нодах и полностью заточен на Друпал. У Дрипта есть функции, позволяющие напрямую обращаться к базе, вытаскивая оттуда самую разную информацию. Даже секретаршу можно за полдня научить программировать на Dript, это вполне безопасно. А вот захочет ли админ разрешать PHP-вставки для посетителей - большой вопрос.
Рано или поздно создатели Друпала осознают, что это язык программирования сверхвысокого уровня. И что Друпал ставят слишком большое количество людей, которые умеют только заливать файлы по FPT и щелкать кнопками в формах. Тогда им неизбежно понадобится какой-то более высокий язык программирования, чем PHP. Так что вполне возможно, что когда-нибудь Dript встроят в ядро Друпала. Динамика придет не только на представление материалов на сайте, но и вовнутрь материалов. После чего Друпал окончательно станет полноценным языком программирования CMS.
Избавится от присутствия на сайте веб-программистов и веб-дизайнеров разработчики сайтов могут хоть сегодня.
Да,да. Совершенно верно. Застрелим программера, который написал нам CMS, и повесим дизайнера, который разработал нам темы для CMS. И начнем клепать говно, как обычно в рунете делается. Увеличивая количество общего говна, которое нас окружает, как в интернете, так и в повседневной жизни.
marazmus says: Застрелим программера, который написал нам CMS, и повесим дизайнера, который разработал нам темы для CMS. И начнем клепать г...о, как обычно в рунете делается. Увеличивая количество общего г...а, которое нас окружает, как в интернете, так и в повседневной жизни.
(Заменил в Вашей цитате некоторые буквы точками, чтобы не так пахло.)
Если программист и дизайнер выкладывают свой труд в Интернет для общего использования, то честь им и хвала. Плохо становится лишь тогда, когда программист начинает переделывать стандартную CMS на каждом сайте, который он поддерживает. А дизайнер начинает писать под каждый свой сайт новую тему. Они уйдут с проекта, через месяц CMS перейдет с 5-ой на 6-ую версию и все сделанное ими перестанет работать.
CMS это паровоз, который постоянно несется и обновляется во времени. Любая попытка изукрасить CMS под свой вкус закончится тем, что CMS вскоре поменяется в очередной раз и все покрашенное слетит. При этом слетевшая краска еще может унести с собой массу материала, который основывался на покрашенной части паровоза.
Надежнее подстраивать проект под возможности паровоза. Тогда сайт будет жить долго.
(Заменил в Вашей цитате некоторые буквы точками, чтобы не так пахло.)
Наверное, не стоит лицемерить здесь, все свои. Пахнет в вашем воображении, а не в моих словах.
Все ваши слова красивы и понятны. И про паровоз красиво сказано. Только есть еще одна сторона медали - когда CMS нужна под конкретный проект. Когда нельзя брать CMS, которая вам нравится и ломать заказчика, его техническое задание и функционал будущего проекта даже под такую отличную CMS как Друпал. Когда нельзя обойтись стандартной темой, сменив в ней логотип и цвета. Когда у заказчика есть свой фирменный стиль, сделанный мастерами своего дела, и нельзя опускаться ниже этого уровня на сайте заказчика. Когда нельзя садиться на поезд, ведомый паровозом, несущимся неизвестно куда, а нужно погрузить свой проект на танкер, построенный вменяемыми людьми, и который будут вести вменяемые люди. И когда заказчик не настолько жаден, чтобы жалеть даже ту сотню баксов, что он, морщась, вынул из кошелька в коридоре во время перекура - "Давай, сделай там че нить..."
По поводу внешнего вида - это отдельная беда рунета вообще. Хорошо, что в последнее время начали встречаться небольшие залежи драгметаллов в тех грудах дерьма, что наполняют рунет. И мне вообще крайне подозрительны те люди, что предлагают вообще обходиться без дизайна внешнего вида сайтов (или не хотят за него платить). Для меня это звучит как " В говне живем, в говне и умрем, зачем красоту наводить?" И тут уже мы с вами на разных сторонах, не обессудьте.
p.s. Я таки жалею, что ввязался в эту дискуссию, ибо на вашей стороне большой опыт разработки разного рода проектов на Друпале. В вашем случае все сказанное вами выше правильно, и стоит взятия на вооружение. Но с моей стороны - я бы не был так категоричен по отношению к таким частям команд, как программисты и дизайнеры. Без хорошего дизайнера сайт будет выглядеть как визуальная хрень. Максимум - приятно, но на уровне "это я уже где-то видел, ага, тема стандартная, точно". Мир нужно делать хоть немного красивее.
marazmus says: Когда нельзя брать CMS, которая вам нравится и ломать заказчика, его техническое задание и функционал будущего проекта даже под такую отличную CMS как Друпал.
Если Друпал не подходит, то на этот случай есть много других CMS, в которых тоже можно поддерживать "зеленую" установку. Нужно посоветовать клиенту найти другого специалиста.
Уважающий себя адвокат по гражданским делам никогда не будет брать уголовные дела. Другие клиенты у него еще будут, а проигранное уголовное дело может обернутся клиенту тюрьмой, а самому адвокату потерей репутации.
marazmus says: И мне вообще крайне подозрительны те люди, что предлагают вообще обходиться без дизайна внешнего вида сайтов (или не хотят за него платить).
Эта тема уже обсуждалась на Drupal.ru. Когда сайт на CMS только поднимается, нет смысла делать под него дизайн. Лучше пустить бюджет проекта на его качественную проработку. Когда сайт обрастет материалами и станет понятно какой нужен дизайн, то начинают ждать сильной смены версии Друпала. И под нее заказывают дизайн, если он нужен.
Дизайн же ради дизайна - пожалейте бюджет клиента. Представьте, сайт пустой, сделан прекрасный дизайн, хотя дизайнер знает, что уже в бета-версии есть следующая версия CMS. Через пару месяцев, вместо того, чтобы спокойно перейти на официальный релиз новой версии, дизайн под старую версию пригвоздит разработчика к старой версии.
to marazmus можно ваши примеры "залежей драгметаллов" и "не очень")?
to Razgonka.ru
то есть делать свою тему под новый проект это зло и работать она будет в лучшем случае на ближайшей версии? Не хочу спорить, просто интересно уточнить
to marazmus
насчет драгметалла хорошо сказано)
вообще-то тоже никак не пойму, как это можно обойтись без дизайнера. Может быть надо быть настоящим приверженцем идеи и делать только для себя?
Почитал обсуждения и стало грустно. Просто начал переделывать одну интересную тему - попросил знакомую дизайнера, она эскиз сделала. Теперь оказывается что даже если все получиться все равно тема долго не проживет?
Может есть рекомендации по долгоживущим темам?)
Сразу почти наткнулся, свежее - http://drupal.ru/node/5344
Насчет заморочек с переездами. Грамотно сделанная CMS и грамотно сверстанный и внедренный в ее систему шаблонов дизайн обычно не мешают переезду на новую версию. С Друпалом еще не пробовал, вам видней. Но на SMF и на Textpattern я проблем не заметил, все сработало как надо. А крутые изменения в системе шаблонов нужно просто отслеживать, и не ставить тупо обновление "на авось". Обычно в ридми к обновлению разработчики пишут, что оно затрагивает, а что нет.
И еще, возможно, я не совсем врубился в специфику вашего мнения. Фраза "Представьте, сайт пустой, сделан прекрасный дизайн" меня ввергает в непонимание. Обычно заказчика трясут по максимуму на наполнение сайта, потом уже, обговорив ТЗ и функционал, и сделав прототипы функционала, берутся за дизайн. Это вообще чуть ли не последняя часть работы, обычно. Но эта фраза, с другой стороны, имеет смысл, когда заказчику нужен "самозаполняемый" сайт-коммьюнити. В этом случае "пустота" сайта явление временное (хотя если идея сайта - говно, никакой движок ему не поможет). Так что сделайте оговорку, пожалуйста, для тех кто еще "не догнал", типа меня
- к примеру, "Все вышесказанное насчет ненужности дизайнеров и вредности самописок нужно читать и осмысливать строго в контексте создания сайтов коммьюнити-направленности". Типо так. Потому что я не могу представить, как уговорить заказчика с брендбуком за пять тысяч евро ограничиться стандартной темой Друпала 
marazmus says: Обычно заказчика трясут по максимуму на наполнение сайта, потом уже, обговорив ТЗ и функционал, и сделав прототипы функционала, берутся за дизайн. Это вообще чуть ли не последняя часть работы, обычно.
Все по разному работают с заказчиком. "Трясти" клиента, на мой взгляд, нет смысла. Клиент выделяет на проект какой-то бюджет, в рамках этого бюджета нужно выстроить проект. "Раскручивать" заказчика на траты сверх бюджета непрофессионально. Клиент не любит скрытые цены, когда в начале работы говорится одно, а в конце приходится платить в 2 раза дороже.
Сайт на CMS принципиально отличается от статического сайта тем, что его может наполнять не только разработчик, а кто угодно - посетители, сотрудники, сам клиент,... Первичное наполнение сайта на CMS обычно делается силами разработчика только для того, чтобы показать что сайт не пустой. Если разработчик сайта на CMS съедает бюджет на наполнение сайта, то он неправильно тратит бюджет. Секретарь клиента может сделать то же самое, а ее зарплата меньше, чем у разработчика.
Вместо наполнения сайта (что характерно для статических сайтов), в сайтах на CMS в бюджет прописывают строчку "обучение сотрудников наполнять сайт материалами". В офф-лайновых заказах это обучение происходит вживую, в заказ через Интернет разработчик выставляет на сайт материалы, где подробно описываются все необходимые шаги для создания материалов и отвечает на отдельном форуме на вопросы авторов (сотрудников,...) по созданию материалов.
marazmus says: Потому что я не могу представить, как уговорить заказчика с брендбуком за пять тысяч евро ограничиться стандартной темой Друпала
А зачем его уговаривать при таком бюджете? Нормальный дизайн стоит от 500$. При бюджете 5000 евро смело можно выделять на дизайн деньги из бюджета, на качестве структуры проекта это никак не отразится, а выглядеть сайт будет приятно. И будет не стыдно показать его в своем портфолио.
На небольших проектах с бюджетом 300-1000$ дизайн съедает существенную часть бюджета. Именно для малобюджетных проектов ориентирован мой совет отложить затраты на дизайн "на потом", чтобы не пострадало качество проекта при запуске.
Yandex - драгметаллы
Mail.ru и Rambler - то, что не драгметаллы
Драгметаллы - Почти все, что делает N.O.D. Из веб-студий - здесь, к примеру: http://www.1aim.ru/done, еще пара топовых.
Не-драгметалловых искать лень, у меня в ссылках почему-то в основном то, к чему глаз привык - более-менее человеческие сайты.
Все это спорно, и вкусы у всех разные. Но законов композиции, "золотых" пропорций, модульных сеток и желания сделать красиво это не отменяет.
Можно еще много времени потратить на такого рода списки - моего мнения это не поменяет. Я считаю, что рунет становится красивее, потому что дизайнеров и художников, работающим в этой сфере, наконец-то начали воспринимать как нормальные профессии. И оплачивать соответственно. Буржуины это поняли уже давно, поэтому в целом у них все намного красивее - и дома, и сайты. У нас все еще рулят разгонщики и их клиенты, которым западло вкладываться в сайт и его внешний вид. "Накидать контента" - и айда, вперед с песнями. Простите меня за сарказм, это лишнее, но меня уже не переделать.
Через пару месяцев, вместо того, чтобы спокойно перейти на официальный релиз новой версии, дизайн под старую версию пригвоздит разработчика к старой версии.
Неужели в Друпале дизайн настолько привязан к функционалу движка?
Exiton says: Неужели в Друпале дизайн настолько привязан к функционалу движка?
В теории дизайн тем в Друпале разделен от движка.
На практике в Друпале формат тем меняется каждые полгода. http://drupal.org/project/Themes :
4.6.x - 48 тем
4.7.x - 98 тем
5.x- 63 темы
Причем в темах 5.x часть тем вообще не имеет предшественников из версий 4.x. И только остальные темы смогли перерасти из 4.x в 5.x.
Примерно можно считать, что половина тем не переживает сильной смены версий Друпала. То же самое можно сказать про сторонние модули, половина из них остается без поддержки при сильной смене версий Друпала.
Что-то мне все это напоминает попытки реализовать "убийц" двигателя внутреннего сгорания и другие подобные штуки. Многие такие идеи действительно имеют право на жизнь, а у остальных при близжайшем рассмотрении обнаруживается какой-нибудь один маааленький недостаток, от которого все рассыпается, как карточный домик.
Razgonka.ru, то есть вы предлагаете не реализовывать новые возможности различных платформ, технологий и т.п. (как железных, так и софтовых)? Так давайте тогда вместе посетуем, что современные проги под новую версию ОС могут не запуститься на старой, или, что старенький Duron не получится заменить на двухъядерный Athlon64! Если мы будем так рассуждать, то прогресс остановится, не правда ли? Вот если выход нового поколения чего-то производится не ради прогресса, а для намеренного создания трудностей (выколачивания денег у пользователей) - да, это не очень хорошо, но это уже другой вопрос, и так, к счастью, не всегда происходит.
Всегда нужно стремиться к золотой середине. Если, например, проект можно реализовать так, чтобы потом было меньше проблем с переходом на новое поколение и совместимостью, почему бы этого не сделать? Но, опять же, только если трудоемкость проекта при этом не возрастет на порядки.
А если проекту нужны нестандартные возможности? Если нужен хороший, профессиональный дизайн? Что лучше - реализовать эти фишки и получить хороший, РАБОТАЮЩИЙ проект, или загадать на 10 лет вперед и штампануть очередной безликий "клон"?
И еще один вопрос "на засыпку". Вы думаете, прогноз на будущее возможен? Хороший совет - подбирать, скажем, материнскую плату с расчетом на будущую модернизацию, т.е. через пару лет выйдет навороченный проц под такой же разъем, и можно будет сделать недорогой апгрейд. Да вот беда - необходимое напряжение материнка не поддерживает! Придется, значит, менять и материнку, а с ней и память с видюхой, поскольку старые, увы, не поддерживаются. А если не повезет, так еще и БП, потому что мощности старого уже не хватает.
Здесь может случиться то же самое. Вот через пару версий перестанут поддерживать старый АPI, что вы тогда делать-то будете? Скажете, возьму "зеленые" модули, предназначенные под новый API? А если их не напишут? А если даже напишут, но данные уже по-другому в БД хранятся (или вообще не в БД)? А модулей, позволяющий конвертировать старое представление данных в новое, тоже нет? Т.е., я хочу сказать, что с довольно большой вероятностью когда-нибудь все равно придется переписывать если не все, то хотя бы часть. Так стоит ли в самом начале терять в функциональности и индивидуальности проекта?
Повторюсь: ИМХО, к каждому проекту можно поытаться применить описанный вами подход, но не в ущерб ФУНКЦИОНАЛЬНОСТИ и ИНДИВИДУАЛЬНОСТИ (читай - качеству)!
P.S. Почему программисты до сих пор существуют? Потому что универсальные решения не всем подходят, правда? А CMS - универсальное решение по определению. Тем более, что Друпал многие считают даже не CMS, а CMS-CMF.
shp says: Razgonka.ru, то есть вы предлагаете не реализовывать новые возможности различных платформ, технологий и т.п. (как железных, так и софтовых)?
Разные они, возможности.
Те, что встроены в ядро Друпала, будут существовать вечно, их можно свободно использовать. Равно как все, что делается зелеными модулями. Возможностей желтых и красных модулей лучше избегать. О самописном коде лучше вообще даже и не думать.
shp says: Вот если выход нового поколения чего-то производится не ради прогресса, а для намеренного создания трудностей (выколачивания денег у пользователей) - да, это не очень хорошо.
А хорошо ли менять API у CMS, когда очевидно, что через несколько месяцев выйдет новая версия? А хорошо менять мажорные версии не один раз в 5 лет, а каждый год и при этом требовать переписывать модули?
Как результат каждые полгода смерть проходится косой по половине друпаловских модулей и тем. И то, что подобную чехарду создатели Друпала делают бесплатно, ничуть не облегчает страдания тех, кто использует Друпал на своих сайтах.
Не думаю, что создатели коммерческих продуктов стали бы каждые полгода заставлять своих покупателей переписывать околопродуктовый самописный код. Остались бы без клиентов. В Microsoft Office код написанный на Vusual Basic работает годами. Версии Офиса меняются, а код работает.
shp says:А если проекту нужны нестандартные возможности? Если нужен хороший, профессиональный дизайн? Что лучше - реализовать эти фишки и получить хороший, РАБОТАЮЩИЙ проект, или загадать на 10 лет вперед и штампануть очередной безликий "клон"?
Это зависит от того, кто смотрит.
Разработчику хорошо получить красивый, работающий проект. Его можно будет показать в портфолио своим будущим клиентам.
А клиент уже через 5 лет будет проезжаться крепкими словами по разработчику, который устроил ему "красную" установку из-за которой стало невозможно обновлять проект. Если перепроектировать заново, то отвалится 2/3 материала. Если оставить все как есть, то проект устареет и его обойдут новые проекты. Еще год-два клиент разрывается между этими двумя альтернативами, а потом машет рукой и дает добро на реорганизацию проекта в "зеленом" стиле. Обходится проекту это в потерю 2/3 материалов и 2/3 постоянных авторов, не считая денежные затраты на реорганизация.
shp says: и штампануть очередной безликий "клон"
При чем здесь безликость. Дизайн относится к "зеленым" сущностям, он не влияет на надежность сайта. Вопрос дизайна это вопрос бюджета, а не вопрос надежности построения сайта.
Если бюджет позволяет, меняйте дизайн хоть каждые полгода. Желательно подгадывать смену дизайна к очередной смене API или мажорной смене версий Друпала.
Только не нужно на малобюджетных проектах половину денег стартапа тратить на дизайн. Плохо спроектированный проект может зайти в тупик уже через пару лет. И даже красивый дизайн его не спасет. Потому что к тому времени от дизайна тоже ничего не останется, его съест очередная смена API или мажорная смена версий Друпала.
shp says:Вот через пару версий перестанут поддерживать старый АPI, что вы тогда делать-то будете? Скажете, возьму "зеленые" модули, предназначенные под новый API? А если их не напишут? А если даже напишут, но данные уже по-другому в БД хранятся (или вообще не в БД)? А модулей, позволяющий конвертировать старое представление данных в новое, тоже нет? Т.е., я хочу сказать, что с довольно большой вероятностью когда-нибудь все равно придется переписывать если не все, то хотя бы часть.
Здесь я с Вами полностью согласен. Все самописное придется переписывать. И довольно часто. Поэтому выход прост - не писать код вообще, а пользоваться не API, а только ядром плюс "зелеными" модулями. Ну, если проект очень просит, то добавить некоторое количество "желтых" и "красных" модулей.
shp says: Почему программисты до сих пор существуют? Потому что универсальные решения не всем подходят, правда?
Программисты не существуют, они вымирают. Раньше вокруг одной ЭВМ крутилось 20 программистов. Сейчас на 100 компьютеров найдется ли один профессиональный программист, который кормится только с того, что 8 часов в день кодирует.
В 19 веке количество телефонов в мире росло, вместе с ним росло количество телефонных барышень. В 20 веке перешли на номерной набор и барышни-телефонистки как класс выжили только на армейских коммутаторах. Скучно без них военным. А все остальные стали сами-себе-телефонные-барышни и соединяются с нужным абонентом вполне самостоятельно. С помощью большого пальца.
В веб-программировании прямо на глазах идет подобный процесс. Друпал может использоваться полностью без единой строчки самописного кода. Что и делает большинство установщиков Друпала, потому что не умеет кодировать на PHP.
Дайте срок, в Друпале появится свой конструктор тем, не требующий знания HTML. Нечто подобное уже мелькало в виде тем, созданных через Excel.
Я понимаю Ваше желание убедить общественность и себя что только веб-программисты смогут придать сайту неповторимость и очарование. Но мир находит более простые способы выявить индивидуальность человека.
Раньше был индивидуальный пошив, сейчас засилье ширпотреба. Ателье вымерли, равно как и профессия портного. А если есть желание и деньги выразиться, то покупают одежду из готовых линий известных марок.
Совет
Если хочется придать друпаловскому сайту неповторимость, то заплатите 500$ за эксклюзивный дизайн и получите желаемое на полгода. Или обвешайте его зелеными модулями и будет он представлять материал совершенно уникальным образом.
Но ради бога, не шутите с созданием новых типов информации с помощью красного стороннего модуля. Посетители будут годами создавать на его основе свои материалы. А в один прекрасный день сторонний модуль прикажет долго жить.
Через подобный опыт уже прошли посетители некоторых русских друпаловских сайтов. Там ставили ставили "красные" wiki модули, которые спустя какое-то время загибались вместе с набитым материалом. 1-2 случая и теперь народ не особенно спешит писать в очередной http://wiki.drupal.ru/ . "Плавали - знаем".
Пусть Ваши посетители пишут лучше в дневник, в book, и другие стандартные типы информации. Это надежно.
Опоздавшая на дискуссию. Но все же, может, кто ответит. Как же быть, если нужен модуль?
Мне для сайта нужно разработать большую форму. Хотела использовать CCK для создания специального типа документа для этой формы. Но получается, что при обновлении версии Друпала моя форма прикажет долго жить? А если я ее просто напишу на html'е и сыром php? Будет ли это более надежным вариантом или нет?
Реализовали бы возможность управления сайтом с помощью мобильного телефона