26 апреля в Питере в iClub прошло собрание любителей Ruby. Это было второе мероприятие в рамках railsclub.ru, поэтому информация о нем и материалы есть на официальном сайте. Для меня это был первый опыт орагнизации встречи и публичного выступления. Было довольно интересно и я надеюсь мы будем собираться регулярно. Меня несколько раз спрашивали о том, зачем вообще нужны эти встречи, кто может в них участвовать и т.д. Я хочу поделиться своими мыслями на этот счет с надеждой привлечь больше людей на будующие встречи, а так же сделать их лучше.

О чем рассказать на такой встрече

Все, чем Вы занимаетесь, что более-менее необычно, может быть интересно другим.

  • У Вас есть какая-то open source (или которой можно поделиться) наработка для решения какой-то задачи.
  • Есть проект, над которым Вы работаете и решили какие-то проблемы определенным образом (организация кода, процесса, производительность…).
  • Вы Начали использовать какой-то новый подход или инструмент и он Вам нравится.

Стоит только спросить — интересно ли это кому-то и почти наверняка найдутся интересующиеся.

Зачем выступать

Цели, которые можно достичь напрямую

  • Привлечь разработчиков к своему open source проекту

Чтобы их привлечь нужно показать, что проект полезный и интересный. Выступление с демонстрацией основных фишек — отличный способ это сделать.

  • Заинтересовать (напрямую или косвенно) своим коммерческим продуктом

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

  • Найти работников или работу

Невозможно получить полное представление о потенциальной работе по объявлению, одному разговору с менеджером по персоналу, директором и т.д. Так же невозможно понять подходит ли потенциальный работник, задав несколько шаблонных вопросов (почему Вы хотите работать в нашей компании? — Я понятия не имею — разослал резюме в миллиард мест) и получив на них такие же шаблонные ответы. Есть возможность узнать больше о компании или работнику по блогу, open source проектам и т.д. Но я думаю общение в неформальной и не связанной с рекрутингом обстановке может сказать даже больше. Выступление для компании — возможность рассказать о себе перед целевой аудиторией в контексте какого-то проекта например. Для разработчика — возможность выступить перед потенциальными работодателями или коллегами.

На одном из подобных собраний появился github

  • Сформировать бренд или реализовать амбиции (В хорошем смысле, если он вообще есть)

Jay Fields об этом написал явно лучше меня.

Цели, которые можно решить косвенно

  • Хорошо изучить предмет, о котором Вы будете рассказывать

Я узнал довольно много о cucumber и связанных вещах, когда готовился к выступлению.

  • По-новому посмотреть на инструмент (процесс, решение, и т.д.), который Вы используете

Раза 2 я поменял свое отношение к тому, как я пишу cucumber features. В какой-то момент задумался о том, нужно ли мне их вообще писать. Это произошло, потому что я попытался найти как можно больше материалов по теме от разных людей.

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

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

  • Научиться доступно излагать свои мысли и выступать публично

Думаю это полезно всем и каждому.

Глобальные цели

  • Привлечение новых людей в сообщество
  • Обучение начинающих

Новые люди — новые взгляды и новые проекты.

Зачем это мне?

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

Зачем приходить

Многое можно найти в Интернете и прочитать (и многие так и делают, когда перед ними встает проблема или задача). Зачем тогда приходить?

  • Организованное обучение (Не нужно искать, выбирать время, настраиваться и т.д.)
  • Можно влиять на процесс изложения (в своих интересах) — задавать вопросы
  • Встретить людей, решающих те же проблемы что и Вы
  • Пообщаться и интересно провести время

Как рассказывать

  • Коротко. На следующей встрече мы постараемся ограничится 15-20 минутами на выступление

Мои 40 минут были явно перебором.

  • Конкретная и специфическая тема лучше чем общая и пространная

Я набрал себе кучу тем и в итоге только поверхностно по ним прошелся. Лучше полноценно рассказать о чем-то небольшом.

  • Хорошо показывать на конкретном реальном примере

Маленькое конкретное приложение лучше, чем словесное описание абстрактной проблемы.

  • Кодинг в живую — это вероятно лучший способ, но это нужно уметь делать

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

  • Лучше подготовить все заранее, чтобы не тупить во время выступления

На выступлении я по сути первый раз пользовался маком. Как сделать шрифт крупнее? Куда ставятся gems? На эти вопросы не должны отвечать те, кто пришел послушать мое выступление.

  • Код должен быть хорошо виден

Иначе смысла нет его показывать. Настраивайте размер шрифта заранее.