22 октября 2008 в 9:46
Заметка является переводом статьи Ника Льюиса (Nick Lewis)
Оригинал статьи здесь
Джефф Ваткот (Jeff Whatcott) высказывается почему Drupal не является доминирующим средством для разработки социальных приложений PHP разработчиков. В качестве основной пролемы он указывает недостаточную информированность и понимание проблем среди большей части разработчиков Drupal-сообщества. При этом взгляде решение проблемы кроется в информационно-пропагандистских мерах и образовании. Лично я скептически отношусь к тому, что разработчики, выбирающие системы отличные от Drupal делают это из-за отсутствия знаний или осведомленности.
Я думаю, что решение менее рационально
I. Наш API может пригодиться только при хороших знаниях о нём разработчика - Когда разработчик впервые начинает кружить вокруг Drupal, он совершенно не знают о том, как работает hook_menu, из чего состоит formapi, как перекрывается шаблон движка и т.д. .. Если он найдёт время, чтобы прочитать все документы, он, вероятно, станет Drupal-разработчиком. К сожалению, разработчики ленивы, и думают о вещах которые недопонимают - это "ерунда".
II. Разработчики глубоко уверены, что их инструмент является лучшим - Превращение Rails-разработчика в Drupal-разработчика представляется как переход из мусульманства в иудаизм. Многие из нас пытаются убедить Rails-разработчиков в модульности Drupal, в том что его использование даст им огромное преимущество для построения сложных приложений, которые должны расти с течением времени? Ага, я закончил с этим делом 3 года назад...
III. Разработчики часто делают вывод на основании чужих суждений (а не исходя из собственного опыта) - Большинство разработчиков, прислушиваются к мнению других. Поэтому когда есть сомнения, они, естественно надеятся что мнению кого-то другого им поможет. Еще хуже, разработчики имеют тенденцию соглашаться с поверхностными тестами тех или других систем.
IV. Анти-PHP или неприятие PHP. Неприятие PHP является огромным фактором. PHP репутация среди элиты лидеров общественного мнения в развитии сообщества представляется такой же, как большинство людей воспринимает коммунизм. Несмотря на то, что PHP5 позаботился о большинстве проблем, они тем не менее продолжают шарлатанить и напевать старую анти-PHP песню, и кивать в сторону Drupal.
V. Drupal не позволяет работать быстро разработчикам, которые не являются Drupal-ниндзя - Обучение Drupal занимает много времени. Если времени мало, и разработчики не знакомы с API, я бы тоже не рекомендовал им работать с Drupal
Комментарии
я не понял эту фразу
Тех, кого убедили Rails-разработчиков в модульности Drupal дали им огромное преимущество для построения сложных приложений, которые должны расти с течением времени? Да, я точно так остановился 3 года назад...
Я перевел эту фразу таким образом:
"Все из нас пытались убедить Rails-разработчиков в модульности Drupal, которое дает огромные преимущества для построения сложных и расширяющихся с течением времени систем? Ага, я закончил с этим делом 3 года назад..."
Согласен.
Тут есть некоторый замкнутый круг.
Что бы разобраться в API drupal необходимо быть не просто разработчиком php а очень хорошим разработчиком php с врождённым пониманием ооп.
Чтобы делать качественный контент необходимо хорошо представлять реляционную основу, фактически БД, самого друпала.
Резюмируя.
Друпал позволяет очень быстро выложить простой сайт с минимальным дизайном при нулевом уровне знаний в разработке.
Друпал является логичным и целенаправленным.
Друпал сложная система для начинающих разработчиков.
Друпал очень простая система для опытных разработчиков.
Друпал или очень похожая на него система в скором будущем будет являться стандартом для публикации контента в сети.
всё бред.
в том числе и этот мифический "порог входа" в друпал. пару дней посидеть над первым сайтом, с пивом - и всё нормально.
Однажды на сайте IBM прочитал золотую мысль, дословно не помню, но мысль её такова - в большинстве случаев дешевле купить дополнительный интернет сервер для вашего бизнеса, чем нанять несколько программистов которые перепишут вашу CMS на другой язык или создадут Вам новую CMS (в контексте имелось ввиду не CMS, а программа для бизнеса).
А свои CMS пишут из лени покупать книгу и разбираться в коде чужого приложения. Для вывода странички из базы народ пишет 3 строки на PHP и говорят, что их CMS готова. Когда же начинается доводка напильником, тогда и хватаются за голову, зачем же мы её писали. Знаю это по личному опыту - написав для эксперимента CMS на FreePascal, поработав с множеством других "самописных" CMS и в команде разработчиков (вернее доводящих до ума) "самописных" CMS на PHP (имеется ввиду CMS созданные в каждом случае для нужд конечного сайта).
Drupal стал понятен и ясен довольно быстро (как разработчику), после прочтения книги на русском :), главное себя заставить почитать :).
Stalker-g2
пару дней???? что можно на друпале для первого сайта делать пару дней? или это был сайт CNN или NASA?
Порог есть. О его существовании говорит количество и качество сырых модулей. То есть если бы было всё всем понятно откуда столько глюков в общем то простой разработке?
Пытаться писать модули для друпал не будучи хорошим программистом на php5 вот это настоящий бред. Это всё-таки CMS, а не RAD&VCL
Читал - ничего не понял...
Автор в + или - ?
И к чему это PR себе любимому в стиле розовой кофточки?
Есть преимущества есть недостатки, как сказал автор - основатель:
"All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005."
бред, для меня ООП закончилось тогда, когда я cдал последнюю лабу по C#,
но как ни странно я разбираюсь в API дру
высокого порога нет. Есть несколько закавык.
1. Отсутствие сборок (с русским языком, с визуальным редактором и тд) - хотя вот Ромыч выкладывал швабр, Русская (голая, без модулей) сборка также существует, так что в этом есть позитивные тренд. "-" как это найти человеку с улицы???. Создателям друпал ру в общем то "проблемы негров не волнуют белого шерифа".
2. Местами не логичная админка. Обновления прав доступа найти сложно даже если уже один раз пользовался.
3. Отсутствие FAQ. Сколько спрашивают про ошибку 500. Вы сами знаете. С 10 вопросов задаются регулярно.
ну ну ) Батенька. Я вам сейчас на вскидку задам пару вопросов на которые ответить можно только серьезно расковыряв ядро друпала. Потому что в документации этого НЕТ. И в книгах этого НЕТ. А в апи друпал есть только формальное описание функции.
Вот вам на вскидочку, нужна форма ввода информации, при этом форма должна выглядеть так как ее нарисовал дизайнер а не так как ее формирует дурпал форм апи, шаблон формы должен быть ПОЛНОСТЬЮ независим от модуля(кода php) и вынесен в отдельный файл - шаблона. И при этом сохранить все возможности друпал то есть отдельные модули могли бы вносить в вашу форму свои необходимые данные (например имаже капча.)
И это еще не говоря о том, что просто чтение описания механизма хуков и форм апи, и прочих необходимых апи займет у Вас более двух дней.
Так что с двумя днями вы погорячились.
Наивная аргументация.
1. Our API is Only as Powerful as the Developer's Knowledge of It
2. Developers Hold a Deeply Held Believe that *their* tool is the best
3. Developers Often Don't Form Opinions From Experience
4. Anti-PHP snobbery
5. Drupal Doesn't Speed Up Development for Developers Who Aren't Drupal Ninjas
Пунткы 1-3 относятся к любой системе, даже не компьютерной. Это общечеловеческие принципы
Пунтк 4 - наивно. Разработчик, который не может разделить личные предпочтения и требования ситуации -- не очень хорош.
Пункт 5 сводится к п.1 и сводится у универсальному "Чем ты профессиональнее, тем быстрее/лучше делаешь работу".
Goodboy, поправил
есть еще причина.
VI. иногда нужны нормальные узкоспециализированные решения в которых бааальшой код друпала оказывается тааким громоздким
penexe
Вы бы потрудились выдохнуть и посчитать до 10 прежде чем что то сказать.
То что для вас ООП закончилось на лабах - это плохо. В мире достаточное количество плохих программистов. Одним теперь больше.
А то что вы разбираетесь без ООП в API Drupal - это настоящее чудо. Вам бы в передачу Очевидное-невероятное.
Друпал начинался когда в PHP не было поддержки ООП. И разработчикам пришлось самостоятельно написать ядро близкое по возможностям к полнофункциональному ООП.
Я думаю с переходом на PHP5 друпал перепишется под стандарт ООП.
Именно потому что нужно не просто знать ООП а и понимать как разработчики его понимали и как понимают сейчас - это и есть основная сложность друпала.
http://api.drupal.org/api/file/developer/topics/oop.html/5
Долой машинный перевод, Автор перечитайте статью, исправьте ошибки и стилистику русского языка и перепишите текст на русский.
7ка нифига не ооп.
врядли. разве что Zend начнет тупо давить простое функциональное кодирование.
PS: Zend Framework мне понравилась... Вкурив ее как следует могу обходиться вообще без CMS с примерно такими же сроками...
Да в том то и дело что ООП только самописное. Отсюда и путаница с терминами и главная опасность для будущего Друпала.
самописное ООП? это из области подземных стуков и потустороннего?
правильно поставленный вопрос содержит в себе ответ
ваш вопрос поставлен неправильно.
ЗЫ. это не шутка.
а сейчас я открою вам тайну. только ТСССС - никому не говорите.
причина сырости многих модулей не в незнании API друпала. сами подумайте, в чём.
EllECTRONC, мне лень
Всем кто считает что Друпал не написан с использованием принципов и парадигмы ООП вот ссылка ещё раз.
http://api.drupal.org/api/file/developer/topics/oop.html/5
Во время его создания php не поддерживал ООП. Теперь поддерживает. А Друпал является ООП - эшной надстройкой над уже поддерживающим ООП PHP.
Это кстати и причина его тормознутости и падения надёжности на высоконагруженных сайтах и даже произвольного убивания таблиц или записей в базе.
С другой стороны что такое ООП без PEAR. А включение груши в разработку сильно усложнило бы простоту установки и настройки. Так что выбирая между пользователями и разработчиками решили оставить первых. И видимо это правильно.
Как соскочить с этой иглы разработчики видимо не знают. Нужно полностью поменять движок. Фактически оставить только логотип и идиологию (патерн). Или не нужно ничего менять. Система всё равно намбе уан и видимо долго такой останется. Пока .net не сожрёт весь интернет.
Для начала, никогда о подобном не слышал, хотя, возможно, в интерфейсе работы с СУБД были когда-то такие проблемы. Сейчас их нет, хотя кривые руки некоторых сторонних программистов, конечно, остались. Совершенно не очевидно, как бы изменилась производительность системы при полном её переписыванием с использованием ООП-конструкций PHP. Хотя бы потому, что это уже была бы немного другая система. Да, действительно, а что такое ООП? Объясните, какое отношение к этому имеет набор классов PEAR.
бред. меньше месяца.
Zend framework или любой другой MVC framework освоить гораздо сложнее на том уровне чтобы выпекать модули как блинчики.
drupal легче.
Мой вопрос возможно не по адресу, но ...
Давно приглядываюсь к друпалу (по началу все непонятно было, пока не прочитал книгу), но от использования в работе останавливает:
Собственно вопрос: есть система, в которой своя таблица хранения юзеров, обращение к ним осуществляется через хранимые процедуры. Как в таком случае правильнее интегрировать? Писать модуль, который будет полностью обрабатывать hook_user, не обращая внимания на собственную таблицу в drupal? Если заглядывать дальше, следующие непонятки у меня возникают в вопросе интеграции прав доступа.
Писать свой модуль для синхронизации пользователей в вашей базе и в Drupal.
А зачем много писать, можно например взять [module=ldap_integration] изавязать с oracle internet directory или что-там-вы используете... все уже написано, нужно тюнить под себя
Ilya1st, это Ник Льюис написал)
если бы было написано, что друпал прост в освоении, вы бы всё равно стали спорить.
whisk@drupal.org
1. Доступ к БД с помощью стандартных классов даёт больше шансов вашим данным на целостность. Наприме, сейчас на локальной машине при доступе из разных броузеров одновременно к одним нодам могут отпадать права доступа у юзера. Подобных проблем при любой стандартной аутентификации не наблюдается.
2. Друпал дважды ООП. Один раз OOD второй раз ООП. Это не добавляет скорости работы. О тормознутости уже при 1000 конектов написано в документации.
3. Без PEAR или любого другого депозитария классов пришлось бы по новой писать все велосипеды. ООП как парадигма без содержания ничего не стоит. Её основная ценность это возможность повторного использования классов, в том числе и сторонних. Наиболее разумно было бы включить его в поставку. Но многие хостинги не включают грушу. То есть это не проблема но уже были бы сложности для большинства пользователей.
Я когда полез в кишочки друпала и понял что мне предстоит выучить фреймвок сомнительного качества просто плюнул. Возможно смалодушничал. Но та скорость с которой отпадают старые разрбатки наверное говорит об обратном. Нужно очень любить друпал чтобы быть его разработчиком. Или зарабатывать на друпале.
Для конечных же пользователей - лучшей системы чем Друпал я не видел.
предложите лучше.
[b]albert t@drupal.org[/b], мне кажется, вы не вполне различаете парадигму программирования, её реализацию в языке и реализацию функциональности в коде. PEAR этот пресловутый хотя бы при каждом случае не упоминайте.
ну еп. иногда надо что-то упоминать чтобы
выевыглядеть крутымЛюди я поня одну вещь.
Для чего-то серьезного нужно делать свой движок. Мучения с Друпал по времени примерно столько же времени занимают сколько написание своего движка.
Только почему все остальные, не пишут свои движки? Не потому, что они идиоты. Просто большая часть из них, уже попыталась это сделать и быстро (никому не говоря:-) свернула свои попытки. Ответа почему они это сделали, я дать не могу, каждый должен осознать это сам.
да. мы просто втупую его патчим чтобы из 500 запросов на страницу на боевом сервере стало хотя бы 200
а так да. нельзя сказать что он плохой
DRUPAL определенно тормозит и что бы сделать посещаемый проект надо выдумывать нечто невероятное, в то же время целенаправленные разработки под что то определенно тормозят гораздо меньше, особенно написанные не на PHP.
А так как даже малые проекты сейчас имеют посещаемость как средние 3 года назад - надобность друпала ставится под очень большое сомнение.
вывод: каждый при своем мнении, поэтому инодрупаловидных просим удалиться
Может вы и правы.
Разница между мной и Вами в том что я знаю ответ а Вы видимо нет.
Экскюзми, но самописных движков насмотрелся сотнями когда заказчики обращаются перенести старый сайт, который "делала веб-Студия xxxxx" на drupal- везде узкая специализация, невозможность наращивания функционала и банально кривой, не систематизированый код (хотя и ООП).
Всем кто собирается писать говносамописку:
Конечным пользователям дешевле докупить железа для компенсации тормозов drupal чем оплачивать "команду псевдоспециалистов-самописцев" и потом бороться с последствиями отсутствия техподдержки.
нормальные конечные пользователи если проект большой - с проектом договариваются и об ОПЛАЧИВАЕМОЙ поддержке.
я на друпал, простите за мой французкий, пару раз такую гавнину видел, разбор которой был бы не дешевле толкового кода писанного с НУЛЯ.
так что отсутсвие техподдержки у заказчика - это по любому прямой путь проекта в жопу.
пишем. довольно часто. потому что НАДО.
Когда ведущий програмист "ОПЛАЧИВАЕМОЙ поддержке" попадает в аварию, тогда "попадает"
в авариюи "конечные пользователи".Да действительно Гавнина и на drupal встречается.
Самописку пишете небось шоб лавандосиков побольше содрать
Даже в случае с сателитами(куда уж проще сайт может быть) drupal с включеным кешем и со своим(само-дописным для s-a-p-e) кешрутером работает быстрее cmsimple и их подобных...
Сорри за мою французкий.
не совсем. есть задачи в которые сувать то что дает опенсорс или рынок == подставлять клиента. я решаю проблему.
вот и все.
еще про лавандосик:
начните с себя
я не занимаюсь сателлитами.
если так подходить к вопросу - можно сразу сворачивать любой бизнес. в малом бизнесе в 90% предприятий на начальном этапе все завязывается на основателя.
Про лавандосики я же совершенно не в обиду сказал, хотел узнать мотивы для написания...
А про саты - бывает... грешу... но здесь указано для примера использования drupal в казалось бы занятой нише, и это не просто я нахваливаю drupal а реально проводил замеры.
Например, нужно обслуживать до 200 тыс. уникальных посетителей в сутки, и при этом у нас нет денег на аренду половины датацентра
Ilya1st , мне нравятся ваши высказывания тем, что они лишены фанатичности , столь свойственной многим разработчикам-друпальщикам.
Я полагаю, что все дебаты в этой теме сводятся к тому, что хотя друпал хорошо подходит для решения многих задач, в буднях вебмастера всегда находятся проекты, для реализации которых нужно применять самопис или третьи разработки.
Недавно стал ковырять ZendFramework -- подтверждаю, что особо сложные проекты на нем можно поднимать, вообще не используя CMS.
Быстренько пробегусь по пунктам топика:
I. Наш API может пригодиться только при хороших знаниях о нём разработчика -- для того, чтобы пользоваться чем-то чужим, всегда нужно знать API, хоть в Друпале, хоть в Дельфи, и даже в ассемблере
II. Разработчики глубоко уверены, что их инструмент является лучшим не вижу тут загвоздки -- дописывайте модули, расширяйте функционал...
III. Разработчики часто делают вывод на основании чужих суждений действительно, для того, чтобы показать кому-то все возможности Друпала, нужно время. Чаще всего люди говорят что это какой-то блоговый движок и ставят битрикс
IV. Анти-PHP или неприятие PHP Не смотря на эволюцию всяких Руби, Питона, КолдФьюжена, PHP является основным языком разработчиков
V. Drupal не позволяет работать быстро разработчикам, которые не являются Drupal-ниндзя Выбор средства разработки -- это как выбор жены -- в серьез и надолго. Уж извините, рзрабатывать на Дру -- это не вордпресс ставить.
В России (заповеднике Unix-only вебсерверов)? Частое мелькание *.aspx в строке адреса не смущает ещё?
Правильно говорят: если страница долго формируется - ставь сервер\бд мощнее, но если долго писать\сложно сопровождать код, то пора менять инструмент...
ps посмешили некоторые товарищи со своим "ООП друпала ООПее ООПа php5"
В России (заповеднике Unix-only вебсерверов)? Частое мелькание *.aspx в строке адреса не смущает ещё?
Правильно говорят: если страница долго формируется - ставь сервер\бд мощнее, но если долго писать\сложно сопровождать код, то пора менять инструмент...
ps посмешили некоторые товарищи со своим "ООП друпала ООПее ООПа php5"
Почему некоторым людям так нравится казаться тупыми? Точнее высокомерными и тупыми.
Вот короткий и верный ответ про ООПешность Друпала.
Short answer: Drupal is OOD (Object Oriented Design) but not OOP (Object Oriented Programming).
И наверное самое главное - Друпал, если кто забыл, это CMS, а не среда разработки. Написать нечто своё, близкое по стабильности, расширяемости, поддержке сообществом и удобству для пользователей, это не один год человеко-часов.
Друпал это CMS номер один в рейтингах, за счёт и множества разработчиков в том числе.
Так что выбора особо и нет.
Надо изучать. Если есть зачем.
Относительно aspx vs php пока есть только одно преимущество - netовцам платят больше в 1,5-2 раза
В конечном итоге конкурентоспособность системы определяется в комплексе и в своём сегменте. Глупо сравнивать Drupal с Visual Studio 2008. И так же глупо писать на aspx сайт на десять статических страниц. Так что всему своё место и время.