Материалы доклада на DrupalConf 2011 в Москве

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

Чтобы было проще, слайды презентации вставил картинками в текст.

Текст доклада "Друпал для Ленивых"

Ленивые всё делают быстро. Чтобы поскорее отделаться от работы. И делают качественно. Чтобы потом не переделывать. © чей-то твит

Добрый день. Меня зовут Дубовской Александр, Саша, и тема моего доклада - Друпал для ленивых. Хотя это скорее история, а не доклад - история небольшой провинциальной студии, которая началась года 4 назад. Мой старший брат, Дима, всегда любил идею открытой информации. Лет 10-12 назад у нас была нода, если кто помнит - это узел сети фидонет, где каждый мог бесплатно позвонить и получить модемом какую-либо информацию, почту, файлы. В фидо не было компаний, организаций, коммерции, а были люди - общающиеся, передающие опыт, иногда продающие что-либо. И когда все начали потихоньку мигрировать в интернет, оказалось, что тут все иначе. Оказалось, что в интернете нет места людям. Оказалось что тут разговаривают только с компаниями.

Я имею в виду, что частному предпринимателю, у которого нет возможности / опыта / времени сделать себе сайт, негде его взять. В прямом смысле. Подавляющее количество знакомых нам студий первым делом делали вот что: Узнавали, сколько денег есть у заказчика на сайт и если меньше 2-3 тысяч долларов, то ненавязчиво извинялись и отсылали куда подальше. Студии общались с компаниями. Потом стали популярны фриланс-биржи, где люди начали общаться с людьми. Возникла следующая проблема - отсутствие гарантий. У меня помимо прочего, есть юридическое образование, я могу многое рассказать о том как надо правильно оформлять сделку - ничто из этого не делается большинством фрилансеров и заказчиков.

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

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

Сейчас мы делаем более 60 сайтов в месяц, все они на друпале. Мы продолжаем быть маленькой компанией, со штатом из 4х сотрудников, и продолжаем искать “...как же сделать это еще проще, еще эффективней и дешевле”.

Результатами этих поисков мне и хочется поделится с вами.

Начну не с инструментария, а с друпала вообще. Четыре года назад мы страдали болезнью начинающих коллективов - нам нужна была “СИСТЕМА УПРАВЛЕНИЯ ВСЕМ”, которая бы учитывала клиентов, вела внутреннюю документацию и прочее прочее прочее... Мы уже тогда начали работать с друпалом и решили для себя что “мы специализируемся в нем и пишем сайты только на нем”.

Но, из-за отсутствия опыта, видимо, мы решили что нам надо вести отчетность, к примеру.... в SugarCRM... кто знает, кто сталкивался, помнят эту монстрообразную штуку, которая умеет записывать все, вплоть до интимных связей агентов и контрагентов, клиентов и менеджеров. Мы еще выбирали, наверное, месяц, что лучше - Sugar или VtigerCrm... Понятно что эффективности там было ни на грамм? Потому что как возникала задачка по созданию дополнительного поля - мы лезли в документацию Sugar и искали “как же тут это прикрутить”... Благо продолжалось это относительно недолго...

Пока мы не пересели на Redmine. Великолепный багтрекер, с wiki, документами, ревизиями... Супер-выбор для ребят, которые не знают Ruby, да? Надо признать, нам вполне понравилось, мы пользовались им больше года. 

Пока не появилась необходимость дать нашим контент-менеджерам удобную возможность вести списки диалогов в сети (форумах и т.п.). Вот тогда мы собрали то решение, которым пользуемся и по сей день. Мы сделали небольшой сайт на Drupal, с ограничением доступа, простым дизайном, несколькими js-удобностями (табами по категориям проектов, ajax-поиском через вьюсы и т.п.), заточенный именно под наши нужды. А когда нам требовалось, к примеру, поставить в нужном месте блок с автопоиском, для наших девчат контент-менеджеров, мы не тратили десятки минут на то чтобы объяснить “как добраться до этого функционала”, а встраивали в дашборд для нужных нам пользователей, затрачивая минут по 10-15.

Следующий вектор поиска был направлен на темизацию. Уходило уйма времени на то чтобы привязать дизайн к друпалу. Начиналось все с создания подтем для Zen... Кто собирал, помнят какой там объем кода “на всякий случай”, “авось пригодится”... На средний сайт (каталог) у меня уходило 28-35 часов. Причин этому много, разберемся с двумя наиболее на тот момент значимыми:

  • page.tpl.php от Zen
  • zen.css

Сейчас Zen я рассматриваю как хороший учебник для начала работы, но не более. Года два назад я активно начал работать с ninesixty, и сделал с десяток сайтов на ней. Естественно, я переписал ninesixty и сделал свой “старт-пакет”, где я просто вычистил все лишнее, в итоге page.tpl.php на старте всего 40 строчек. Казалось бы - это мелочь, но с несколькими другими мелочами, такими как сниппеты для netbeans, бранчи в git, срок разработки среднего каталога сократился до 3-4 дней (14-18 часов). В два раза. Это значит мы могли смело зачеркивать цену на данную категорию сайтов и писать в 2 раза меньшую (что мы и сделали). Тут важно отметить еще раз специфику - мы работаем с маленькими сайтами, для больших сайтов это не работает или работает не совсем так, там процент затраченного времени на темизацию значительно меньше, значительно чаще сетка может скорее мешать чем помогать и надо каждый раз принимать решение что же именно использовать. Но для маленьких сайтов это работает более чем хорошо.

Некоторое время все было прекрасно, десятки сайтов были собраны на базе ninesixty, своей темы, пока мы не увидели Fusion. Для того чтобы рассказать о красоте fusion мне необходимо рассказать о том, что происходило у нас в течение 2009-2010 года. А происходил процесс, когда все что касается поддержки клиентских сайтов мы отдавали сотрудницам, контент-менеджерам. Мы следовали принципу “от кода к кликам”. И оказалось, что Fusion имеет ряд полезнейших для наших задач преимуществ:

  • Контейнеры на 100% ширину
  • Skinr
  • 960gs сетка (но другое именование и немного другая логика)
  • Разметка блоков через skinr по сетке
  • Различные параметры меню (выпадающее, горизонтальное/вертикальное) и т.п.

Я рассматривал многие темы. Фактически, мое любопытство приводит к тому что раз в месяц я захожу на drupal.org и пересматриваю все drupal-темы, где в описании есть намек что это framework-тема. И Fusion мне показалась (и на данный момент это все еще так) наиболее оптимальной с точки зрения кода/удобства. Хотя, признаю, во многом это дело вкуса верстальщика.

Еще один вектор поисков - набор модулей и инструментов.
Следующим упростившим жизнь выбором было принятие CCK, Views, Panels, Features, Context. Именно в такой последовательности. Лучше даже не так - не принятие “мы пользуемся этими модулями” (мы всегда ими пользовались), а отсутствие колебаний и размышлений (написать это своим сниппетом или использовать фунционал этой связки). Когда появился Features жизнь стала лишь чуть менее чем очень прекрасной - теперь можно создавать готовые решения, которые очень просто дублировать на разных сайтах.

Я помню, как мы сидели с Димой, у нас в офисе и взирали на большую очередь задач, которую было бы неплохо разрешить за вечер. Как назло настроение было нерабочее - никак не получалось сфокусировать внимание на задачах, а браузер постоянно открывал то гуглоридер, то drupal.org в поисках новостей. И так я случайно набрел на скринкаст от DevelopmentSeed. Вы их все знаете по OpenAtrium’у, модулю Spaces, проекту Aegir. Скринкаст был посвящен Features. Возможности этого нестабильного на тот момент модуля меня очень порадовали - тем, что значительную часть задач я решил, скопировав через Features решения с уже сделанных нами сайтов ранее.

Отдельно про Features хочется заметить следующее:

  • Удобно, если вы создаете некий “module.css”, базовую разметку которую почти всегда используете и добавляете ее через drupal_add_css.
  • Аналогично со скриптами.
  • Храните историю в Git (или любом другом VCS), features красиво все оформляет в .inc файлах, удобно отслеживать изменения.

Мне очень хочется верить, что за Features будущее. Я поговорю еще отдельно про Drupal 7, но уже сейчас можно найти просто замечательные проекты, которые присутствуют на drupal.org как например Case Tracker Plus. Это, что называется, features-based модуль, который на базе Views, CCK (Date, FileField, Node Reference, Number, User Reference), jsGantt Views, Comment Driven, Spaces, Features, Strongarm предоставляет систему управления задачами и проектами, с диаграммами Ганта, иерархией и так далее. Единственное “но”, создан он специально под OpenAtrium, что видно в .info файле. Вообще, крайне рекомендую поставить Atrium и Case Tracker Plus чтобы посмотреть как люди собирают на Features крайне объемный функционал. Знаю сегодня будет выступать andypost, который подробно опишет такое начинание как KIT - набор спецификаций для создания тем и фьючесов, где будут собраны рекомендации для сообщества, как именно лучше создавать свои features-based модули, чтобы избежать конфликтов с разными сборками, версиями, и самими фьючесами.

Еще 2 вектора поисков, которые важны, но о которых я не расскажу:
1. Хостинг
2. Собственные модули
Не расскажу потому что это входит в область компетенции моего брата, и эта область мне просто незнакома.

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

На этом я заканчиваю с темами и модулями. Мы на работе просмотрели статистику 2008 года по проектам, сколько времени у меня занимала сборка “Сайта-каталога” тогда и сколько - сейчас (начало 2011). 28-35 часов тогда, 7-8 сейчас. Это результат, это цифры.

Последний вектор поисков это сообщество. Сообщество может значительно сэкономить время и помочь. Причем не следует понимать под сообществом сайт drupal.ru или любой другой друпал-сайт. Реальную значимую помощь оказывают лично знакомые вам профессионалы. Я помню случай, когда мне довольно “горело” доделать один из сайтов и из головы вылетело название модуля, я не мог его найти/нагуглить, на поиски могло уйти пару часов, которых у меня не было.

Я задал вопрос на d.ru, где мне ответил буквально за 10-15 минут Stan Ezersky, знакомый всем вам по проекту Друпалогия. Стен - еще раз спасибо :) И такие ситуации повторялись - мы обсуждали собственные друпал-црмки с Левандовским из InternetDevels, друпал-сборки с Швецом из ShvetsGroup, и это все сэкономило мне кучу времени и принесло кучу опыта. Секрет прост - если вы что-то даете сообществу, вы что-то получаете.

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

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

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


 

Партнерская программа

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

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

Тогда, добро пожаловать в партнерку :)