Туманное будущее Друпала

15 июля 2011 в 16:30
Аватар пользователя Crea Crea 0 174

Drupal 7 уже был тревожным сигналом - ведь для стабилизации и приближения релиза, Аквии и многим другим компаниям пришлось выделить сотрудников на зарплате, занимающихся решением багов на фул-тайм.
В этом смысле, инициативы Дриза и компании по Drupal 8 очень пугающие:
- очень сильно повышены требования к количеству багов, которые вызывает то или иное изменение
- добавлены очень жесткие критерии приема патчей. Предполагается, что контрибутор должен будет ознакомиться с тонной документации, прежде чем провести какое-нибудь изменение. И это будет действительно тонны - я не шучу. Текущая сложность Drupal - learning curve, как ее называют, покажется детским садом по сравнению с новыми требованиями.

Все это - бюрократизация, дополнительные барьеры для участия многих контрибуторов. Непонятно, как можно забюрократизировать процесс по-максимуму, и рассчитывать что сообщество - добровольцы, будут разгребать все это.
Многие потенциальные контрибуторы уже давно не участвуют в разработке ядра по причине низкой эффективности труда:
- чтобы добавить то или иное изменение, нужно убедить кучу народа
- бесконечные споры по поводу реализации того или иного изменения. В условиях равноправности мнений, из спора очень трудно прийти к компромиссу
- готовые патчи могут висеть месяцами, ожидая своей участи. Стоит только вспомнить эпические изменения, связанные с состояниями гонки (race conditions) в Drupal 6 и каких усилий стоило реализовать их.
В этом смысле, я не вижу здесь тенденций к улучшению. Более того, все будет только усугубляться. Неудивительно, что такие инноваторы, как Development Seed, покинули мир Друпала. Этот процесс будет продолжаться и дальше. Бюрократизация - тормоз и злейший враг инноваций.

Как бы я решил эту проблему ? Я бы сделал процесс разработки распределенным, убрал узкое горлышко в виде небольшой группы комиттеров ядра. Это уже давно предлагалось: существовала так называемая инициатива Small Core, в рамках которой предлагалось разделить друпал на слабо связанные подсистемы, разрабатываемые отдельно, и оставить ядро минимального размера. Эта инициатива не нашла серьезной поддержки, к сожалению.
Дриз и ко вряд ли пошли бы на такое - ведь тогда они потеряли бы контроль над продуктом. Друпал, как торговый знак, перестал бы приносить дивиденды.

Мой прогноз: Drupal 8 намертво увязнет в своих проблемах, и чтобы вытащить его, бизнесам придется еще больше рассчитывать на свои силы, и еще меньше - на сообщество. Многие переосмыслят использование Drupal в своем бизнесе. Drupal перестанет быть продуктом сообщества, и станет больше продуктом корпораций. В этом смысле, наверное, он в чем-то повторит судьбу Linux.
Мы увидим больше дистрибутивов Drupal, мы увидим LTS редакции, для потребителей, не желающих гнаться за номерами версий, как белки в колесе. Аквия, которая во всем подражает Redhat, возможно разразится своим Acquia Enterprise Drupal с 10 летней поддержкой )))

Ссылки по теме:

http://www.drupal4hu.com/node/300
http://benbuckman.net/drupal-excessive-complexity
http://randyfay.com/node/110
http://www.unleashedmind.com/en/blog/sun/the-drupal-crisis
http://www.unleashedmind.com/en/blog/sun/crisis-conclusions

Комментарии

"Crea" wrote:
Как бы я решил эту проблему ? Я бы сделал процесс разработки распределенным, убрал узкое горлышко в виде небольшой группы комиттеров ядра. Это уже давно предлагалось: существовала так называемая инициатива Small Core, в рамках которой предлагалось разделить друпал на слабо связанные подсистемы, разрабатываемые отдельно, и оставить ядро минимального размера. Эта инициатива не нашла серьезной поддержки, к сожалению.
Дриз и ко вряд ли пошли бы на такое - ведь тогда они потеряли бы контроль над продуктом. Друпал, как торговый знак, перестал бы приносить дивиденды.

Вот с подсистемами идея мне нравится. Два дня ядро перетряхивал и до сих мелочи вылазят. Куча херово взаимосвязанного непонятного шлака.

15 июля 2011 в 16:45

"xxandeadxx" wrote:
например?

да везде, урлы через одно место, js тем же лесом. Мне не понятно на кой хрен 2 типа регионов для вывода и зачем маркеры типа core, module и прочее. Хотя тут наверное больше те, кто модули пишет косячат, но тем не менее.

Остальное. дофига всего несогласовано.

15 июля 2011 в 16:59

"Cyber" wrote:
урлы через одно место

тебе не нравится что урлы создаёт одна функция - url? или что?

"Cyber" wrote:
js тем же лесом

по конкретнее

"Cyber" wrote:
на кой хрен 2 типа регионов

чтобы не захламлять админку блоков

"Cyber" wrote:
и зачем маркеры типа core, module

что за маркеры?

"Cyber" wrote:
дофига всего несогласовано.

требую конкретики! Wink

15 июля 2011 в 17:09

"xxandeadxx" wrote:
по конкретнее

scripts[header]

scripts[footer]

----

вывод цепляется за $scripts и $closeure. Вот например захотел я перенести все скрипты в подвал, чтобы они аггрегировались в один файл, но потому что региона 2, простой перенос $scripts в подвал нихрена не даёт.

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

Помимо прочего, есть люди которые пишут инлайны зависящие от загрузки jQuery и выводимые на php генерации. Это то же по сути не лучший вариант. Ну и остальное.

Какой смысл?

15 июля 2011 в 17:15

"Crea" wrote:
Drupal 7 уже был тревожным сигналом - ведь для стабилизации и приближения релиза, Аквии и многим другим компаниям пришлось выделить сотрудников на зарплате, занимающихся решением багов на фул-тайм.

Думаю, это связано с тем, что ядро включило в себя многие до этого contrib модули.

15 июля 2011 в 22:37
Аватар пользователя Dan Dan 0

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

16 июля 2011 в 0:51
Аватар пользователя Dan Dan 0

Гы, вечных холивар - микроядро-макроядро. Хотя я тоже плюсую - то что казалось хорошим на момент выпуска ядра становиться хламом через год-два, причём с самого начала это было совсем необязательно в ядро и включать. Для 6-ки это профили, комменты, тригеры... Чёрт, да больше половины модулей можно спокойно выкинуть в контриб!

16 июля 2011 в 1:22

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

А у друпал все опенсурс-опенсурс.

18 июля 2011 в 22:53
Аватар пользователя Dan Dan 0

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

18 июля 2011 в 23:48

Они ушли целенаправленно заниматься проектами по маппингу, картографии, визуализациям и обработке больших массивов данных.
Пишут теперь на жабаскрипте под NodeJS. Почему ушли - мы все равно всех причин не узнаем. Официальная причина - низкая эффективность Drupal для их задач.
Все проекты бросили либо продали (а это такие алмазы как Open Atrium, Features, Aegir и т.д.)

19 июля 2011 в 0:12

"Crea" wrote:
Они ушли целенаправленно заниматься проектами по маппингу, картографии, визуализациям и обработке больших массивов данных.

когда начинешь лепить чтото сложное со своей спецификой - много JS, постоянные вызовы JSON - понимаешь что от друпал там кроме системы меню и разрешений + парочки функция для работы с URL, нихрена и не остаетсяю.
Как знать, может они и правы? Smile
правильный разработчик исходит из задач и уже под них подбирает инструменты.

19 июля 2011 в 1:04

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

19 июля 2011 в 1:23

"Crea" wrote:
Ведь чтобы бросить наработки стольких лет, должна быть более серьезная причина.

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

19 июля 2011 в 1:58

"Crea" wrote:
Дриз

Дрис. уважайте чужие имена.

"Ильич Рамирес Санчес" wrote:
понимаешь что от друпал там кроме системы меню и разрешений + парочки функция для работы с URL, нихрена и не остается

Именно. Современные фреймворки предлагают тонны готовых решений, при этом гибкость выше на порядки.

"Crea" wrote:
Ведь чтобы бросить наработки стольких лет, должна быть более серьезная причина.

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

19 июля 2011 в 5:05

kyky wrote:
"Crea" wrote:
Дриз

Дрис. уважайте чужие имена.

Вы лингвист ? Я так его назвал не потому что не уважаю, а потому что считаю это одним из возможных вариантов написания, как например, Andrei вместо Andrey.

19 июля 2011 в 16:47

Ильич Рамирес Санчес wrote:
"kyky" wrote:
Эта причина — взросление.

GPL в частности. если бы было BSD - больше контриба бы возвращалось в систему от серьезных контор, которые ПРОДАЮТ решения.
Да с чего вдруг? Конторы которые продают свои решения в основе которых программный код десять раз подумают, отдавать ли его в опенсорс. Чего они тогда продавать будут? И под BSD не обязывающей это делать скорей всего и не отдадут, если только не совсем ненужная вещь или не рекламная акция. С GPL десять раз подумают, прежде чем применить эту лицензию из-за накладываемых обязательств, зато уж если решились больше шансов, что код вернётся в исходный проект.

17 августа 2011 в 12:26

axel wrote:
Ильич Рамирес Санчес wrote:
"kyky" wrote:
Эта причина — взросление.

GPL в частности. если бы было BSD - больше контриба бы возвращалось в систему от серьезных контор, которые ПРОДАЮТ решения.
Да с чего вдруг? Конторы которые продают свои решения в основе которых программный код десять раз подумают, отдавать ли его в опенсорс. Чего они тогда продавать будут? И под BSD не обязывающей это делать скорей всего и не отдадут, если только не совсем ненужная вещь или не рекламная акция. С GPL десять раз подумают, прежде чем применить эту лицензию из-за накладываемых обязательств, зато уж если решились больше шансов, что код вернётся в исходный проект.

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

17 августа 2011 в 12:56

axel wrote:
Да с чего вдруг?

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

17 августа 2011 в 17:06
Аватар пользователя Dan Dan 0

"Crea" wrote:
Все проекты бросили либо продали (а это такие алмазы как Open Atrium, Features, Aegir и т.д.)

Ага, уже нашёл в их блоге про http://www.phase2technology.com
Жалко, ребята были хороши...

"Ильич Рамирес Санчес" wrote:
когда начинешь лепить чтото сложное со своей спецификой - много JS, постоянные вызовы JSON - понимаешь что от друпал там кроме системы меню и разрешений + парочки функция для работы с URL, нихрена и не остаетсяю.

В 7-ке появился AJAX Framework. Я ещё не прочувствовал, для меня он стрёмный или удобный, но работает вполне и того геморроя с AJAX, который был в 6-ке уже нет.

19 июля 2011 в 9:35

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

Давайте не будем путать понятия "бросили" и "продали за очень очень большое бабло". А то "бросили" как-то не описывает тот факт что ребята могут себе по яхте купить... И я как-то только про опенатриум в курсе и managin news, про остальное - не видел источников, ссылки пожалуйста дайте. И продали они другой здоровой Drupal-компании. Не будете же вы кричать "Linux умирает!" если RedHat продаст какую-то корпоративную разработку Убунте? Наоборот - "Покупка-продажа среди opensource компаний набирает обороты, сфера растет". Так и тут. Сфера то растет, многомиллионные продажи будут становиться нормой. Другим CMS до этого еще расти и расти Smile

19 июля 2011 в 9:39

adubovskoy wrote:
"Crea" wrote:
Я хотел сказать, что это может быть только вершина айсберга. Ведь чтобы бросить наработки стольких лет, должна быть более серьезная причина.

Давайте не будем путать понятия "бросили" и "продали за очень очень большое бабло".

Бросили то, что невозможно продать, например модули. Это же очевидно.
Откуда инфа про большое бабло ? Я вот уверен, что бабло было вполне умеренное. Чего там продавать то ? Торговый знак, и клиентская база. Это при том, что клиентов в США и так больше, чем студии могут переварить, нехватает работников. Были бы это проприетарные продукты - другое дело.

adubovskoy wrote:

А то "бросили" как-то не описывает тот факт что ребята могут себе по яхте купить...

Ну, смотря по какой яхте..с американскими зарплатами любой программист может себе позволить яхту. Тут ничего удивительного для меня нет. С Абрамовичем и Эллисоном явно им не потягаться ))

adubovskoy wrote:

И я как-то только про опенатриум в курсе и managin news, про остальное - не видел источников, ссылки пожалуйста дайте.

Берите любой их проект, модуль - Aegir, Managing News, Open Atrium, Features, Feeds, Context, Spaces, Purl - и т.д., список очень длинный. Везде смена мейнтейнера и тишина от Dev.Seed

adubovskoy wrote:

И продали они другой здоровой Drupal-компании. Не будете же вы кричать "Linux умирает!" если RedHat продаст какую-то корпоративную разработку Убунте? Наоборот - "Покупка-продажа среди opensource компаний набирает обороты, сфера растет". Так и тут. Сфера то растет, многомиллионные продажи будут становиться нормой. Другим CMS до этого еще расти и расти :)

А кто говорил о смерти ? Это вы мне приписываете слова, которых я не упоминал.

19 июля 2011 в 13:32
Аватар пользователя orb orb 0

"Crea" wrote:
Все проекты бросили либо продали (а это такие алмазы как Open Atrium, Features, Aegir и т.д.)
а что теперь с Atrium будет?
Отличная система

19 июля 2011 в 11:02

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

19 июля 2011 в 13:30

"acoder" wrote:
А есть ли вообще нормальные движки?

что не так с друпалом?

"acoder" wrote:
А есть ли вообще нормальные движки?

что есть "нормальный"?

19 июля 2011 в 13:31

"acoder" wrote:
А есть ли вообще нормальные движки?

Дрис хорошо высказался о движках (CMS) и месте Друпала среди них. В точку попал, прямо скажем.

19 июля 2011 в 13:42

"acoder" wrote:
Перешел с битрикса на друпал и слегка тоже разочаровываюсь, а тут еще этот ваш пост. Начинают появляться сомнения... А есть ли вообще нормальные движки? А то может мы сильно много требуем?

сам недавно об этом долго думал и спрашивал у знатоков.В осадке действительно осталась - тревога.
Что имеем:
1) друпал идет своим путем. Путь этот прокладывает не сильно большая группа людей(Дрис и фирмы крупные которые на друпале работают), которые на самом деле все и решают.
А им интересно сделать друпал - пригодным для своих "крутых" проектов. Что не совсем гармонирует с задачей обычного сайтостроительства, где сайты не супер-пупер сложные и вообще очень разные и лишнее им только мешает и ограничивает. Это видно по значительному увеличению дистрибутива семерки и тенденции безапелляционного использования нелегких решений - ctools, rules, panels и т.д. Убер 7-й зависит от первых двух...
Обычные фрилансеры с такими друпал сайтами будут проигрывать в той нише где они ловят рыбку. Сайты все таки должны не тупить на обычных хостингах.

2) Тенденция к "больше сделать не прогая" и минимум прогая. Программистам php, не сильно интересно создавать сайты копаясь в тоннах настроек вместо кодинга, в котором они спецы. Особенно для не сильно сложных сайтов, где проще нужный функционал на фреймворке собрать, чем знать о существовании модулей X, Y, которые в сочетании и при настройках... Плюс им тут создадут конкуренцию "настройщики" и занизят цену вопроса. Как в джумле, за 50 баксов сайт.

3) реализуя пункт 2)(чтобы все это реализовать) код ядра и api становится намного сложнее для понимания, для программирования "под друпал". С учетом особенно если это не сильно и будет востребовано, то зачем разбираться как ТС пишет в тоннах API?. Чтобы бесплатно модули для сообщества писать? А зачем? Программисту охота программированием деньги зарабатывать. Может привести к тому, что реально знать "что там происходит в этом друпале" и откуда растут проблемы(а для этого надо хорощо знать как он спрограммирован), люди перестанут. И это аукнется.

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

19 июля 2011 в 15:46

"tarasovvlad" wrote:
А им интересно сделать друпал - пригодным для своих "крутых" проектов. Что не совсем гармонирует с задачей обычного сайтостроительства, где сайты не супер-пупер сложные и вообще очень разные и лишнее им только мешает и ограничивает. Это видно по значительному увеличению дистрибутива семерки и тенденции безапелляционного использования нелегких решений - ctools, rules, panels и т.д. Убер 7-й зависит от первых двух...
Обычные фрилансеры с такими друпал сайтами будут проигрывать в той нише где они ловят рыбку. Сайты все таки должны не тупить на обычных хостингах.

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

"tarasovvlad" wrote:
2) Тенденция к "больше сделать не прогая" и минимум прогая. Программистам php, не сильно интересно создавать сайты копаясь в тоннах настроек вместо кодинга, в котором они спецы. Особенно для не сильно сложных сайтов, где проще нужный функционал на фреймворке собрать, чем знать о существовании модулей X, Y, которые в сочетании и при настройках... Плюс им тут создадут конкуренцию "настройщики" и занизят цену вопроса. Как в джумле, за 50 баксов сайт.

Покажите мне хоть одну студию, которая поддерживает более 50 сайтов на джумле и берет по "50$". Как думаете - почему так вышло?) А вот студии которые держат много маленьких сайтов на друпале - они есть, и у нас и за рубежом (там их больше). Повторный вопрос - как думаете, почему так вышло?

"tarasovvlad" wrote:
3) реализуя пункт 2)(чтобы все это реализовать) код ядра и api становится намного сложнее для понимания, для программирования "под друпал". С учетом особенно если это не сильно и будет востребовано, то зачем разбираться как ТС пишет в тоннах API?. Чтобы бесплатно модули для сообщества писать? А зачем? Программисту охота программированием деньги зарабатывать. Может привести к тому, что реально знать "что там происходит в этом друпале" и откуда растут проблемы(а для этого надо хорощо знать как он спрограммирован), люди перестанут. И это аукнется.

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

"tarasovvlad" wrote:
4) как в пункте 1) сказано, что идет своим путем, не считаясь с другими. В принципе можно сказать при создании 7-ки сильно ее переделали, что ставит друпал-разработчиков перед задачей заново учиться. Не доучить чуток, а именно заново. Как бы обесценили чужые знания(по d6), что не ведет к симпатии и многие уйдут от друпала из-за этого. Вдруг в восьмерке - тоже все заново учить. В самописных(включая фирменных) цмс и фреймах такого все таки нет, там обучение и профессионализм идет по возрастающей, а не со скатывания вниз на ноль, как в друпале

Ээм. Вот когда я копался в изменениях темизации, в рендере 7ки - я бы не сказал что "переучиваться", я бы даже не сказал что многое изменилось. А то что изменилось легко запомнить - тут мы выводили через theme, будем выводить через render, простые вещи, запоминается проще чем телефон такси.

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

19 июля 2011 в 16:39

adubovskoy wrote:

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

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

19 июля 2011 в 16:51

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

Все, можно забыть про одну любимую CMS на 10 лет, так, чтобы вложился, выучил и до пенсии прокачиваешься. Сегодня друпал король горы, вчера всех перло от RoR, завтра попрут фреймворки на python. Кто не сможет переучиться, тот в заднице.

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

19 июля 2011 в 16:40
Аватар пользователя Dan Dan 0

"tarasovvlad" wrote:
1) друпал идет своим путем.

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

"tarasovvlad" wrote:
Путь этот прокладывает не сильно большая группа людей(Дрис и фирмы крупные которые на друпале работают), которые на самом деле все и решают.

Это не так. Если бы Дрис единолично решал как и что сделать в друпале, то Аквии бы не было.

"tarasovvlad" wrote:
Сайты все таки должны не тупить на обычных хостингах.

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

"tarasovvlad" wrote:
2) Тенденция к "больше сделать не прогая" и минимум прогая.

На основании чего сделан подобный вывод? Да, контриб позволяет свести к минимуму кодинг. Установите 700 модулей и радуйтесь скорости. Кстати это первая причина по которой возникает миф про "не работает на шареде".
Но смотрим на новое АПИ 7-ки. Оно что, направлено на "больше сделать не прогая"? Имхо как раз наоборот.

"tarasovvlad" wrote:
Это видно по значительному увеличению дистрибутива семерки и тенденции безапелляционного использования нелегких решений - ctools, rules, panels и т.д. Убер 7-й зависит от первых двух...

Дистрибутив не вырос, считайте внимательней.
Что такое "нелёгкое решение"? И почему все решения должны быть "лёгкими"? А убер 6 - "лёгкое" решение?

"tarasovvlad" wrote:
Плюс им тут создадут конкуренцию "настройщики" и занизят цену вопроса. Как в джумле, за 50 баксов сайт.

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

"tarasovvlad" wrote:
3) реализуя пункт ...

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

"tarasovvlad" wrote:
4) как в пункте 1) сказано, что идет своим путем, не считаясь с другими. В принципе можно сказать при создании 7-ки сильно ее переделали, что ставит друпал-разработчиков перед задачей заново учиться. Не доучить чуток, а именно заново. Как бы обесценили чужые знания(по d6), что не ведет к симпатии и многие уйдут от друпала из-за этого. Вдруг в восьмерке - тоже все заново учить. В самописных(включая фирменных) цмс и фреймах такого все таки нет, там обучение и профессионализм идет по возрастающей, а не со скатывания вниз на ноль, как в друпале.

Бред. Что конкретно требует переучивания в 7-ке? Что принципиально нового? Назовите хотя бы три вещи.

19 июля 2011 в 17:05

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

19 июля 2011 в 17:42

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

А не на массового пользователя (как вордпресс например)

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

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

19 июля 2011 в 17:57
Аватар пользователя Dan Dan 0

"Crea" wrote:
Вообще забавно, как мысль о том, что с Друпалом что-то может быть не так, вызывает жесткий батхерт у Друпал-студий )))

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

19 июля 2011 в 17:59

Dan wrote:
"Crea" wrote:
Вообще забавно, как мысль о том, что с Друпалом что-то может быть не так, вызывает жесткий батхерт у Друпал-студий )))

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

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

А иногда и выдохнуть не успеешь ((

15 августа 2011 в 12:45
Аватар пользователя Dan Dan 0

"Valeratal" wrote:
Мне не нравится ориентация Дриса и Ко на кодеров. Оно конечно хорошо для студий - чем меньше юзер понимает, тем больше зарабатывают студии.

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

"Valeratal" wrote:
форум никакущий, магазины фиг знает, все в разработке, OG - тоже еще пилят.

Форум давно пора выпилить. Commerce - конфетка, но не готов, ОГ даже не знаю, вроде там вс совсем переделано, страшно даже смотреть Smile

19 июля 2011 в 18:08

посмотрел друпал 7 как пользователь. Ну и что там нового по функционалу?
Даже тут официально:
http://drupal.org/about/new-in-drupal-7,
списочек очень скромный. И в 6-ке модулями покрывается часть.
Юзабилити улучшено немного. И все в основном. И для этого ядро они переписывали? Мда...
Изменения ради изменений, а конечным веб-мастерам - хлопоты, вот наверно девиз друпала.

1 августа 2011 в 17:35

"tarasovvlad" wrote:
И для этого ядро они переписывали?

давайте сидеть на php3 и windows 95! ведь ничего нового - как были окошки, так они и остались в windows 7.

"tarasovvlad" wrote:
вот наверно девиз друпала.

девиз друпала - школота не пройдёт. и как видно он работает

1 августа 2011 в 17:47
Аватар пользователя Dan Dan 0

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

1 августа 2011 в 18:01

Есть сигналы, что Друпал скатится в УГ уже на 7 версии:
http://benbuckman.net/drupal-excessive-complexity
Любой разработчик, глубоко работающий с Друпалом, согласится с этой статьей.

Лично я для себя сделал вывод, что я стану лучшим программистом, если изучу другой фреймворк вместо API 7-го Друпала.

11 августа 2011 в 12:36

"Crea" wrote:
Есть сигналы, что Друпал скатится в УГ уже на 7 версии:

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

11 августа 2011 в 13:26

iHappy wrote:

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

Не путайте мнение толпы с мнением инсайдера, который знает всю систему изнутри, и каждый день ей пользуется. Да, и смерть и УГ - разные вещи совсем. Никто о смерти не говорит

11 августа 2011 в 13:41

Интересная статья. Автор приводит в пример модуль Date, монстра c 14000 строчек кода, с другой стороны восхваляет изящество и простоту корного Watchdog. Так разве ядро виновато, что пишут такие модули?

Вывод - писать под себя.

11 августа 2011 в 14:04

А вот писать под себя в друпале как раз очень сложно! АПИ толком не описан, примеров почти ноль, сложная сама по себе структура движка. Модуль под битрикс (хорошо с примерами описан АПИ) или cotonti (простейший для понимания код) написать как нефиг делать, по-ходу легко разобраться, а под друпал, извините, это совсем другое дело...

11 августа 2011 в 14:12

acoder wrote:
АПИ толком не описан, примеров почти ноль,...

Гугл
"drupal api" – About 2,460,000 results
"drupal tutorial module" – About 16,400,000 results

Нихерасебе "не описан, примеров почти ноль".

11 августа 2011 в 14:25

"acoder" wrote:
А вот писать под себя в друпале как раз очень сложно! АПИ толком не описан, примеров почти ноль, сложная сама по себе структура движка.

Абамлеть, а мужики то не знают

11 августа 2011 в 14:16

Еще раз повторяю, документация очень плохая! Нужен пример? Пожалуйста. Я новичок и знать не знаю (например) для чего нужна в друпале функция template_preprocess_node(&$variables). Я обращаюсь на официальный сайт http://api.drupal.org/api/drupal/modules--node--node.module/function/tem... и что я вижу? Перевод "документации":

---
template_preprocess_node(&$variables)
Процесс-переменные для node.tpl.php
Большинство тем используют свои собственные копии node.tpl.php. По умолчанию они находятся внутри "modules/node/node.tpl.php". Смотрите там на полный список переменных.
Массив $variables имеет следующие аргументы:
$node
$view_mode
$page
---

И что? Теперь я знаю для чего эта функция? Смешно.

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

11 августа 2011 в 14:37

"Crea" wrote:
Не путайте мнение толпы с мнением инсайдера, который знает всю систему изнутри, и каждый день ей пользуется. Да, и смерть и УГ - разные вещи совсем. Никто о смерти не говорит

А при чем тут мнение толпы?
Приведу пример: США - ей уже хз сколько лет, но предсказывают "смерть". Скатывание в УГ и тп и тд.
И что? Не особо она скатилась в УГ.
То что говорят, это одно. А что будет, это совсем другое.
Я думаю на д.орг сидят не идиоты. А были бы идиоты, вчастности сам Дрис, то не было бы друпала как такового.

11 августа 2011 в 14:58

iHappy wrote:
"Crea" wrote:
Не путайте мнение толпы с мнением инсайдера, который знает всю систему изнутри, и каждый день ей пользуется. Да, и смерть и УГ - разные вещи совсем. Никто о смерти не говорит

А при чем тут мнение толпы?

Есть аналитика, основанная на фактах, а есть мнения бабок на скамейке. Вы разницы не видите ?????

iHappy wrote:

Приведу пример: США - ей уже хз сколько лет, но предсказывают "смерть". Скатывание в УГ и тп и тд.
И что? Не особо она скатилась в УГ.

Угу, угу....и финансовый кризис тоже не результат УГ США...и понижение кредитного рейтинга США тоже не признак. Вы, видимо, живете в какой то другой реальности.

iHappy wrote:

То что говорят, это одно. А что будет, это совсем другое.
Я думаю на д.орг сидят не идиоты. А были бы идиоты, вчастности сам Дрис, то не было бы друпала как такового.

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

11 августа 2011 в 15:12

"acoder" wrote:
И что? Теперь я знаю для чего эта функция? Смешно.

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

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

К слову, на странице template_preprocess_node есть ссылка на node.tpl.php оттуда ссылка на template_process() и оттуда на theme api. Так что найти необходиму информацию можно.

10 ноября 2015 в 11:47

RxB wrote:
Матан...
Первый курс...
Фихтенгольц...
Демидович...
Краткий курс матанализа в трёх томах по 900 страниц...

Тебя тоже прет, брат-физик?)))))

12 августа 2011 в 12:52

"Crea" wrote:
Угу, угу....и финансовый кризис тоже не результат УГ США...и понижение кредитного рейтинга США тоже не признак. Вы, видимо, живете в какой то другой реальности.

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

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

о каких таких авторитетов ты говоришь? И с чего это ты решил, что я не могу думать головой?
Ты на основании ОДНОЙ статьи вынес вердикт. При этом, сам ставишь в авторитет их.
И мне кидаешь предъявы, что я ссылаюсь на авторитетов. И я не основываю свое суждение на ОДНОЙ статье.
"Crea" wrote:
Есть аналитика, основанная на фактах, а есть мнения бабок на скамейке. Вы разницы не видите ?????

Кто сказал, что аналитика той компании, верна? Они? Я за них, рад, но это не означает что они правы.
Аналитика вообще не благодарное действие.

11 августа 2011 в 15:34

"Crea" wrote:
Ага. Думать вообще вредно.

если ты насчет этого
"iHappy" wrote:
Аналитика вообще не благодарное действие.

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

11 августа 2011 в 16:06
Аватар пользователя Dan Dan 0

"acoder" wrote:
А вот писать под себя в друпале как раз очень сложно!

Пиши под меня!

"Crea" wrote:
Лично я для себя сделал вывод, что я стану лучшим программистом, если изучу другой фреймворк вместо API 7-го Друпала.

Хорошо троллишь Smile Я думаю самый профит сейчас, для тех кто знает 6-ку, изучать 7-ку и параллельно другую CMS - это позволит легко "перескочить".

Quote:
14,673 lines in Drupal’s Date module.

Мне с него смешно. Давайте уж сравнивать с другими фреймворками. По 300 тысяч строк в yii и symphony его не смущает? Не говоря про миллион в зенде.

11 августа 2011 в 22:09

"Crea" wrote:
Лично я для себя сделал вывод, что я стану лучшим программистом, если изучу другой фреймворк вместо API 7-го Друпала.

+1
Сам ушел на джангу, а от АПИ друпала теперь в холодный пот бросает.

12 августа 2011 в 10:19
Аватар пользователя Dan Dan 0

"kyky" wrote:
Сам ушел на джангу, а от АПИ друпала теперь в холодный пот бросает.

Предатели, кругом предатели! Smile

(тоже курю джангу, пока не осилил ни одного нормального сайта, но несколько человек на него пересадил. мне стыдно)))

12 августа 2011 в 13:09

"Maxim Click" wrote:
Может быть их создает HTML программист, вместе с CSS программистом) Есть да HTML программисты?

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

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

13 августа 2011 в 17:02

"<a href="mailto:Sentrashy@drupal.org">Sentrashy@drupal.org</a>" wrote:
все и вся что ты видишь на экране монитора связано с программированием ;)

даже немецкое концептуальное кино Smile

13 августа 2011 в 17:33

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

13 августа 2011 в 18:02

"acoder" wrote:
А вот писать под себя в друпале как раз очень сложно! АПИ толком не описан, примеров почти ноль, сложная сама по себе структура движка.

Интересно, и на каких фактах основано это утверждение?

13 августа 2011 в 18:10

"Maxim Click" wrote:
Это надо спрашивать у тех кто знает, я не из их числа. Я полагаю те кто Друпал программирует, должны быть с ними знакомы.

А если нет таких, тогда что?

13 августа 2011 в 18:34
Аватар пользователя Dan Dan 0

"Mirocow" wrote:
Интересно, и на каких фактах основано это утверждение?

Какая разница, битрикс же круче.

13 августа 2011 в 19:15

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

В более широком смысле под программированием понимают весь спектр деятельности, связанный с созданием и поддержанием в рабочем состоянии программ — программного обеспечения ЭВМ. Более точен современный термин — «программная инженерия» (также иначе «инженерия ПО»). Сюда входят анализ и постановка задачи, проектирование программы, построение алгоритмов, разработка структур данных, написание текстов программ, отладка и тестирование программы (испытания программы), документирование, настройка (конфигурирование), доработка и сопровождение.

На деле, HTML + CSS - это программирование, настройка CCK + Views - это тоже программирование. Это не "кодинг", но все еще "программирование".

15 августа 2011 в 12:38
Аватар пользователя Dan Dan 0

"otmoroz" wrote:
пока сделаешь несколько проектов, пока переучишься, по твоим словам сможешь "более-менее" узнать апи. а потом выдыхаешь, расслабляешься и тууут ХЕРАКС! Новый Друпал, погнали заново "несколько проектов", переучиваться.

А иногда и выдохнуть не успеешь ((


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

15 августа 2011 в 14:08

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

16 августа 2011 в 18:03

iHappy wrote:
очередной авторитет?

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

16 августа 2011 в 21:03

iHappy wrote:
я пока от тебя твоих мыслей не увидел.
Только мысли авторитетов ;)

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

17 августа 2011 в 12:58

"Maxim Click" wrote:
Это называется PHP-разработчик, WEB-разработчик, но не программист, программирование и web-разработка, это разные вещи. Модули пишутся, а не программируются.

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

16 августа 2011 в 2:56

"Maxim Click" wrote:
Модули пишутся, а не программируются.

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

16 августа 2011 в 4:21

Есть контр-пример на огромный модуль Date.
Посмотрите, насколько отличается размер модуля calendar ветки 2.x и 3.x. Примерно в 10 раз. Значит, при переходе на новую версию можно такого добиться!

16 августа 2011 в 6:49

Ой, на такую дискуссию я подпишусь. Максим, а у Вас есть опыт разработки на CSS и HTML? Просто я бы хотел Вам заказать одну функцию, раз на Вас так конкуренты ополчились.

17 августа 2011 в 14:41

"kyky" wrote:
У него Price from $2.990

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

17 августа 2011 в 17:18
Аватар пользователя Dan Dan 0

"kyky" wrote:
С того, что как ни крути, Друпал — это ограниченная архитектура, и какой бы гибкой она ни была, выйти из нее, не поломав ядро и не похакав контриб, невозможно.

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

"Cyber" wrote:
В чём выгода использовать 7 "сегодня" и какой ожидаемый профит "завтра"?

Восьмёрка же. Ты её ещё не поставил?

18 августа 2011 в 9:33

"Valeratal" wrote:
Понятие "выгода" не применимо к искусству. А сайт это произведение искусства!
(если конечно это не ГС)

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

18 августа 2011 в 10:04

Правильно я на joomla перешел. Joomla эволюционирует в лучшую CMS, а Drupal так ничего нового и не привнес.
Использование хуков и игнорирование возможностей ООП вместо прекрасно-подходящего для Web - MVC - это тупик.

18 августа 2011 в 10:45

perloid wrote:
Правильно я на joomla перешел. Joomla эволюционирует в лучшую CMS, а Drupal так ничего нового и не привнес.
Использование хуков и игнорирование возможностей ООП вместо прекрасно-подходящего для Web - MVC - это тупик.

вброс защитан.
но вордпресс еще лучше.

18 августа 2011 в 11:01

perloid wrote:
Правильно я на joomla перешел. Joomla эволюционирует в лучшую CMS, а Drupal так ничего нового и не привнес.
Использование хуков и игнорирование возможностей ООП вместо прекрасно-подходящего для Web - MVC - это тупик.

MVC наше всйо!!1

18 августа 2011 в 12:02

"perloid" wrote:
Использование хуков и игнорирование возможностей ООП вместо прекрасно-подходящего для Web - MVC - это тупик.

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

зы. правильно говорить Юмла!

18 августа 2011 в 11:00
Аватар пользователя Dan Dan 0

"perloid" wrote:
Drupal так ничего нового и не привнес

И не говори - иконок в админке до сих пор нет, о чём ещё можно говорить после этого.

18 августа 2011 в 11:53

"Ильич Рамирес Санчес" wrote:
но вордпресс еще лучше.

wordpress вообще дегенераты какие то создали.
новая версия вышла - там до сих пор код php вперемешку с html и ООП не используется.

18 августа 2011 в 13:29

"perloid" wrote:
новая версия вышла - там до сих пор код php вперемешку с html и ООП не используется.

А кого это волнует? Работает ведь и работает неплохо

Зато тем для ВП туча. Не сравнить с друпальскими.

ВП и Друпал это наверно как Вин и Никсы

Вторые могут сколько угодно вещать о "чисте расы кода", но пока повернуты к юзеру попой

18 августа 2011 в 14:05

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

Андрей, ты принял довольно активное участие в доработке 7ки, и мне странно, что ты считаешь что 8ка станет "непроходимой". Такое возможно для частных контрибуторов "одиночек", им действительно тяжело донести до остального сообщества полезность своих изменений. Но в целом процесс сходящийся и сложность ядра (имхо выросшая незначительно, ибо за 3 года это вполне себе адекватные вещи), говорит лишь о вовлеченности людей в процесс... разработка продолжалась 3 года! и тут как снег на голову нужда учить новые АПИ - такое писать как минимум говорит о некомпетентности!!!

ЗЫЖ браузеры новые не выходят? html5 стал проще? коменрческие продукты не меняют АПИ с мажорными релизами?

19 августа 2011 в 0:25

Вот если 8-ка выйдет через 3 года, тогда все нормально. А если через год, тогда это слишком частые мажорные релизы. ИМХО конечно.

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

19 августа 2011 в 12:55

Ты меня с кем то путаешь, я к 7 не притрагивался...Что касается сравнений с другими технологиями, мне кажется, аналогия некорректна, ведь появление html5 не выбрасывает html4 на свалку - браузеры, в отличие от Друпала, сохраняют обратную совместимость. А переписывание модулей для каждого релиза - большая роскошь, и скоро сообщество поймет это.

19 августа 2011 в 3:17

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

19 августа 2011 в 12:39
Аватар пользователя Dan Dan 0

"otmoroz" wrote:
Кстати, а почему разработчики едва закончив одну версию программы, сразу же принимаются за следующую? Потому что за время разработки новые требования появляются?

А надо возвращаться к предыдущей? Smile

19 августа 2011 в 13:04

"otmoroz" wrote:
Кстати, а почему разработчики едва закончив одну версию программы, сразу же принимаются за следующую? Потому что за время разработки новые требования появляются?

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

19 августа 2011 в 22:29

многие линуксы, например, перешли к rollover-релизам. т.е. как раз дорабатывая и время от времени меняя циферки в релизах)

22 августа 2011 в 15:51

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

Тем не менее, я бы не сказал что сейчас существует какая-то адекватная альтернатива для переезда, если вы хотиет и дальше заниматься рендомным сайтостроением и не концентрироваться на продуктах, как это сделали DevSeed. Девиз про suck less все еще актуален.

22 августа 2011 в 20:11

"neochief" wrote:
Тем не менее, я бы не сказал что сейчас существует какая-то адекватная альтернатива для переезда, если вы хотиет и дальше заниматься рендомным сайтостроением и не концентрироваться на продуктах

нахожусь в тяжелых размышлениях по этому поводу последние полгода.

24 августа 2011 в 1:43

restyler wrote:
"neochief" wrote:
Тем не менее, я бы не сказал что сейчас существует какая-то адекватная альтернатива для переезда, если вы хотиет и дальше заниматься рендомным сайтостроением и не концентрироваться на продуктах

нахожусь в тяжелых размышлениях по этому поводу последние полгода.


Для программистов полно альтернатив. Причем более мощных.
В одной из приведенных статей автор упоминал выступление про быстрое прототипирование - по-моему, повод для размышлений (легкий фреймворк + mongodb - очень многообещающая связка).
Юзерам да, тяжко..

24 августа 2011 в 1:59

Crea wrote:
Для программистов полно альтернатив. Причем более мощных.
В одной из приведенных статей автор упоминал выступление про быстрое прототипирование - по-моему, повод для размышлений (легкий фреймворк + mongodb - очень многообещающая связка).
Юзерам да, тяжко..

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

28 августа 2011 в 19:48

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

24 августа 2011 в 2:32

"Maxim Click" wrote:
Фреймворки хорошо, но это дороже для заказчика и дольше по времени. Хотя большинство заказов однотипные, вырисуется своя CMS в любом случаи.

Dreamviewer наше всё ты хотел сказать?

24 августа 2011 в 11:50

"kyky" wrote:
Тех, кто захочет делать продукты, ждет разочарование, что с Друпалом там ловить нечего.
Эра фреймворков, господа.

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

p.s. Значительное число моих заказчиков приходят от "студий пишущих на фреймворках". Как-то не получается у них по цене/качеству конкурировать... Так что господа потенциальные конкуренты - фреймворки ваш лучший выбор, начинайте прямо сейчас - вы не пожалеете!).

24 августа 2011 в 11:53

"Crea" wrote:
Для программистов полно альтернатив. Причем более мощных.

так это программировать надо будет!

24 августа 2011 в 12:37

"graker" wrote:
Если кому интересно, вчера и позавчера напереводил статьи на русский.
The Drupal Crisis
Crisis Conclusions

Большое спасибо, вчера одну статью прочитал Wink

26 августа 2011 в 10:00

спасибо. прочитал обе статьи. настрой, вроде, боевой у ребят.
сам сейчас решил начать изучать php, так как в нем совсем слабо разбираюсь. правильно ли я понимаю, что именно знание php даст мне наибольшую фору при изучении api друпала?

28 августа 2011 в 12:29
Аватар пользователя Dan Dan 0

"sumerokr" wrote:
что именно знание php даст мне наибольшую фору при изучении api друпала?

Drupal написан на PHP. Знание PHP это не фора, а необходимость Smile

28 августа 2011 в 19:09

Выводы и план действий - http://drupal4hu.com/node/303

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

Разработчики и программисты всегда будут иметь свой кусок хлеба с маслом независимо от систем и фреймворков! Так что опасения и нелепые доводы - смешны!

Путь от фреймворка до продукта никогда не был прямым и далеко не всегда существует. Нравится писать код - пишите на здоровье! За клиентов, которые придут с вашего "продукта" многие потом скажут большое спасибо, но не вам лично Smile

28 августа 2011 в 19:40

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
"кодерам" - очень стоит научиться думать о клиентах и поддержке, а не о "фичах" и удобстве разработки

Бугага xD

28 августа 2011 в 19:51
Аватар пользователя Dan Dan 0

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
"кодерам" - очень стоит научиться думать о клиентах и поддержке, а не о "фичах" и удобстве разработки

Я вот не понял этой фразы. Андрей, можешь развернуто написать?

28 августа 2011 в 20:17

Dan wrote:
"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
"кодерам" - очень стоит научиться думать о клиентах и поддержке, а не о "фичах" и удобстве разработки

Я вот не понял этой фразы. Андрей, можешь развернуто написать?

Smile расшифровать - "накодили много", а кто поддерживать будет и как? Я понимаю, что редкий сайт обходится без дополнительного кода (силами контриба всё не делается), но когда слишком много накодили, да и в нескольких поколениях (стадиях развития) сайта, то, как правило, такой проект редко кто-то берется поддерживать и развивать дальше без полной переписи/переделки.

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

28 августа 2011 в 20:25

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

Smile расшифровать - "накодили много", а кто поддерживать будет и как? Я понимаю, что редкий сайт обходится без дополнительного кода (силами контриба всё не делается), но когда слишком много накодили, да и в нескольких поколениях (стадиях развития) сайта, то, как правило, такой проект редко кто-то берется поддерживать и развивать дальше без полной переписи/переделки.

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


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

29 августа 2011 в 8:42
Аватар пользователя Dan Dan 0

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

28 августа 2011 в 21:08

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
"кодерам" - очень стоит научиться думать о клиентах и поддержке, а не о "фичах" и удобстве разработки

Всячески присоединюсь к этому заявлению. Правда здесь есть тонкий аспект, большинству заказчиков плевать на поддержку сайта. Запустили и забыли. Хотя сейчас ситуация стала меняться. )
"Dan" wrote:
Причём! Если там больше сделано через код, ты быстрее разберёшься, чем если через гуй - код нагляднее.

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

28 августа 2011 в 22:02
Аватар пользователя Dan Dan 0

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Всячески присоединюсь к этому заявлению. Правда здесь есть тонкий аспект, большинству заказчиков плевать на поддержку сайта. Запустили и забыли. Хотя сейчас ситуация стала меняться. )

Если плевать, то это не проблема Smile

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Все правильно, если код написан по стандартам с комментариями, тестами и прочим, и при обязательном условии, что это не самописный движок.

Да любой код! Даже код с регепсами зачастую лучше, чем кошмар с контриб-мясом.
Вся фишка в том, что нельзя выбрать "чистый" путь: либо код, либо контриб. Даже если пытаться всё делать максимум на модулях, по-любому 5-10-15% надо будет написать руками.
Вот пример: попросили изменить логику вывода блока (по дружбе, как отказать). Согласился (блок вывести-скрыть, что может быть проще?). Нужный блок нашёл быстро, но не в лёт - он был темизирован и стандартные идетификаторы скрыты. Оказалось, что этот блок - это два блока, один формируется в коде, другой - views. Тот который в коде - всё понятно и видно, тот который views - непонятно где логика его отображения. Вижу, что выводит его контекст, но правила для включения контекста отсутствуют. Я в ступоре, поиск по коду не помогает. Вот скажите мне, как? КАК?! я мог _найти_ установку контекста в PHP-обработчике аргумента views? Поиском по базе? А вот если бы логика была в коде - нашёл бы быстрее.

28 августа 2011 в 23:52

"Dan" wrote:
Тот который в коде - всё понятно и видно, тот который views - непонятно где логика его отображения. Вижу, что выводит его контекст, но правила для включения контекста отсутствуют. Я в ступоре, поиск по коду не помогает. Вот скажите мне, как?

Есть предложение не использовать views? И функциональность этого модуля повторять своим, правильным кодом? )

29 августа 2011 в 0:21
Аватар пользователя Dan Dan 0

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Есть предложение не использовать views? И функциональность этого модуля повторять своим, правильным кодом? )

Не, упаси боже Smile
Есть предложение не бояться выносить код в модули )

29 августа 2011 в 0:43

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
За клиентов, которые придут с вашего "продукта" многие потом скажут большое спасибо, но не вам лично :)

Очевидно, что проект, написанный на рельсах, нужно передавать спецу по рельсам, а не друпальщику. Аналогично с любым другим фреймворком, тогда будут все довольны.
"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
Просто стоит думать не о скорости написания кода, а о дальнейшей судьбе Продукта, а это как раз слабая сторона кодеров, которые обычно думают, что любой разработчик легко ворвётся в их "гениальный" код

Это проблема любых языков/платформ. Быдлокод на PHP не лучше, чем говонокод на Java. Поможет комментирование, документация, юнит-тесты, но ни как не выбор друпала как панацеи.

29 августа 2011 в 2:21

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Есть предложение не использовать views? И функциональность этого модуля повторять своим, правильным кодом? )

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

29 августа 2011 в 7:37
Аватар пользователя Dan Dan 0

"acoder" wrote:
А почему бы нет? Как показывает практика без модуля views вполне можно обходится.

Можно конечно. Как без любого другого модуля Drupal. Только когда его хорошо знаешь, с ним гораздо приятнее, чем без него Smile

"acoder" wrote:
Например, такого типа каталог чтобы создать при помощи views придется достаточно сильно поиграться с теминизацией.

Вывод всех нод с группировкой по полю + плюс переопределение одного шаблона? Или я что-то не заметил?

29 августа 2011 в 10:02

В детстве я увидел в газете Lamborghini Diablo, статья называлась - там где рождаются дъяволы и понял - это любовь. Да она стоит много, да она много жрёт бензина - но она пиздатая Smile Так и Drupal. В зависимости от подхода и способ работы разный, у меня есть проект в котором от Drupal осталось только ядрёные неотключаемые модули - всё остальное выкинуто и друпал используется как фраемворк (правда манов перед этим по API пришлось почитать и похакать ненужное немного - но это же фреймворк), есть сайты где движок используется как платформа (simpletest + features), есть сайты где Drupal используется как коробочное решение. Просто опыт приходит с количеством проектов, где то после 50-го приходит понимание, а к 100 достигаешь дзен (начинаешь смотреть на проект как на инвестицию и понимаешь что у Drupal - ROI больше).

Согласен с мыслью - что семёрку ещё долго будут пилить и будущее восьмёрки вижу как доведённую до ума семёрку через несколько лет (как Views 2 (с кэшем) после Views (обкатка идеи)).

Просто всем недовольным пора делать фреймворк сборку на подобии как pressflow (оптимизированная сборка), а к официальной версии относится как к LTS в Ubuntu.

29 августа 2011 в 11:45

"acoder" wrote:
Например, такого типа каталог чтобы создать при помощи views придется достаточно сильно поиграться с теминизацией.

Сайт достойный и стильный. Однако я не вижу, что там нельзя сделать вьюзами. Кроме того, основная разбивка наполненя страницы каталога, например, http://kuban-vino.ru/products/vino_shato_taman сделана таблицей. Верстальщику было совсем влом играться с темизацией?

29 августа 2011 в 11:49

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

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

29 августа 2011 в 12:11

"Dan" wrote:
Оказалось, что этот блок - это два блока, один формируется в коде, другой - views. Тот который в коде - всё понятно и видно, тот который views - непонятно где логика его отображения. Вижу, что выводит его контекст, но правила для включения контекста отсутствуют. Я в ступоре, поиск по коду не помогает. Вот скажите мне, как? КАК?! я мог _найти_ установку контекста в PHP-обработчике аргумента views? Поиском по базе?

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

29 августа 2011 в 12:37

"Maxim Click" wrote:
Речь о том, что на Друпал большинство сайтов разрабатывать быстрее и дешевле чем на фреймворках.

Речь о том, почему ребята, которые зажигали на Друпале, ушли на другие технологии.
Это потому, что если стоит выбор — много кодить для друпала или под фремворк, по лучше выбрать последнее. Сейчас фреймворки несут в себе много полезных абстракций, позволяющих сконцентрироваться на основной задаче.
Друпал во многом морально устарел — кеш в базе, переводы в базе, по 200 запросов в БД. Даже нормального ORM нет. В статье "Хватит красить губы свинье" правильно написано — шлифуются никому не нужные вещи, в то время как в ядре остаются скелеты с во времен 4.7

29 августа 2011 в 15:03

И много народу свалило на фреймворки после прочтения всего этого?
Наверное только те, кто даже друпал не устанавливал.

1 сентября 2011 в 19:01

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

15 августа 2012 в 2:07

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

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

Недавно провёл исследование (и, кстати, до сих пор провожу). Суть в следующем: пронаблюдать динамику изменения количества активных заявок для ядра Друпал, обоих гигантов электронной коммерции (Ubercart и Drupal Commerce), Views, CTools, CCK, Token, Pathauto и около десятка самых популярных модулей по данным официальной статистики. Рассуждаю так: каждую активную заявку разработчики рано или поздно продиагностируют и переведут её в соответствующий статус. Весь вопрос в том, рано или поздно? То есть, растёт ли со временем количество активных (подчёркиваю, именно активных - а не всех открытых вперемешку) или убывает?
С результатами исследования в виде красочных графиков можно ознакомиться здесь: Отчёт о Друпал статистике. Статья на английском - но графики понятны и так.

@Crea Насколько я вижу (судя по посту об общественно-полезном программировании), вам было бы интересно узнать, что сайт, на котором расположена статья, является первой платформой коллективного финансирования патчей. Те, кто заинтригован, - пожалуйста, заполните Adherent form (Анкету интересующегося) по ссылке выше.
Пост об этом проекте на Друпал.ру: Финансирование разработки патчей вскладчину (patch crowd funding).

17 сентября 2012 в 19:33