DocOps

Раз воркшоп на конференции у нас превратился в live-coding-show, мы решили делать воркшопы онлайн. И не один раз, а много, регулярно и серийно. О принципах, на которых мы будем строить эти воркшопы, я напишу отдельный пост. А пока что хочу сказать, что первый воркшоп я провожу сегодня, через 2.5 часа, и за последние сутки его содержимое поменялось больше чем наполовину. Про то, почему так и какие выводы я из этого сделал, тоже напишу. А пока что пожелайте мне удачи. :)

Пора рассказать, что у нас получилось с воркшопом. Мы предполагали, что на воркшопе случатся все возможные технические проблемы: люди придут с ноутбуками на самых разных ОС, заранее точно никто ничего не скачает и не настроит, а интернет на конференции будет отвратительный. Так обычно бывает, когда сотни человек собираются в одном помещении. Ещё мы рассчитывали, что все будут немного уставшие на третий день, что яркость экрана может быть плохой, что будет шумно. А еще совершенно точно мы будем в последний момент находить баги, исправлять их, релизить, и участники должны будут использовать последний релиз. В общем, было понятно, что надо подстраховать участников всеми возможными способами. Вот что у нас получилось: Последовательность действий разбили на шаги. Каждый шаг — длинная команда в консоли или пара команд. Всё это мы завернули в один скрипт, чтобы каждый шаг в первый раз выполнять одной командой, вроде run.sh compile. А потом, когда в перый раз всё получилось, можно развернуть подробную инструкцию, где объясняется каждый параметр в длинной команде, и выполнить еще разок. Завернули всё в докер, чтобы не заморачиваться с настройкой окружения. Получилось два образа: в одном наш компилятор, в другом тулзы для работы с веб-сервисом. Буквально в последний день добавился третий, в котором локально поднимается нода Ethereum и на ней смарт-контракт выполняет завершающий шаг вокршопа. Чтобы была уверенность, что шаги работают, мы положили их все в CI. Вот буквально тесты поднимают контейнеры и в них проверяют, как воркшоп проходится по шагам. Версии всех образов зафиксировали, так что любое обновление проходило через CI. Это очень помогло нам в последний день до воркшопа, последнее обновление закинули буквально за полчаса до начала. Чтобы не тратить время и интернет на подготовку окружения, мы сделали готовые виртуальные машины в AWS. На них сразу был клонирован репозиторий с кодом для воркшопа, установлен Docker, и скачана пара нужных образов. Так мы защитились от плохого интернета, неработающего докера и неподдерживаемых архитектур проца. У меня был готовый inventory, так что с помощью Ansible я мог быстро обновлять код и образы на машинках. И еще был плейбук для того чтобы раскидать по машинкам ключи, чтобы люди могли зайти по SSH. Соединение по SSH — штука нетребовательная и довольно живучая. Даже с плохим каналом можно зайти и работать. Конечно же мы всё это отрепетировали: и техническую сторону, и контентную. У нас был чат в дискорде, мы были готовы отвечать там на вопросы участников по ходу вокршопа, чтобы снять нагрузку с ведущего. Подготовились в целом отлично. Не учли только один риск, и как раз он и случился. Как вы думаете, что это было?

Мы (=nil;) едем на большую конференцию и готовим воркшоп. На нем участники пройдут по всему процессу разработки с нашим тулчейном: скомпилируют код в специальное представление — circuit, отправят его на маркетплейс, потом закажут на этом маркетплейсе криптографический пруф вычислений на конкретных данных и получат результат. А еще там в начале надо будет качнуть с гитхаба сотню мегабайт репозитория и пару гигов докер-образа. Еще раз все части списком: — Конференция на сотни человек, интернет наверняка плохой. — Рабочее окружение проще всего получить в докере, остальные способы даже не рассматриваем. — Код на плюсах, субмодули на субмодулях, всё как принято в плюсовой экосистеме. Как видите, есть куча мест, где всё может сломаться. Я думаю о том, как подстраховать участников на каждом шаге. Некоторые идеи есть, но всё равно обращаюсь к коллективному опыту читателей. Если вы проводили или участвовали в таких тренингах/воркшопах, расскажите, где всё сломается и как это заранее починить? Как проведем, напишу еще один пост про то, что мы делали и как всё прошло.

KnowledgeConf возвращается. Следующая конференция будет этой осенью, 30 ноября и 1 декабря, на одной площадке с TeamLead Conf и TechLead Conf. Мы уже принимаем заявки на доклады. Читайте подробности и подавайте заявки: https://cfp.knowledgeconf.ru/. А прямо сегодня, через час, будет встреча с программным комитетом. Приходите, если хотите выступить с докладом. Особенно если хотите, но сомневаетесь. Регистрация тут: https://conf.ontico.ru/event/join/open_kc2023.html.

Oh yeah, me grug brained too, can relate. https://grugbrain.dev/

Опубликовали запись нашего разговора о профессии техписателя, ролях, навыках и задачах. Кажется, это лучший опыт моего участия в подкастах на сегодняшний день. Всё что считал важным, успел сказать. И я очень благодарен моим собеседникам, Александре и Андрею. Они были конструктивны, настроены на сотрудничество, и при этом невероятно душевны. Приходите слушать: https://youtu.be/cI5yxP276Eg

Через 15 минут будем трындеть как будто про техписателей и аналитиков, но больше о том, как всё перепутано в ролях и профессиях, и как это починить. Присоединяйтесь: https://nextway.timepad.ru/event/2465836/.

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

Технические коммуникации можно поделить примерно на три группы: 1. Что надо сделать и зачем. 2. Как именно мы это сделаем или уже сделали, как оно внутри работает, как это эксплуатировать. 3. Как этим пользоваться и зачем. Думаю, что про первое лучше всего думают и пишут менеджеры продукта и аналитики, про второе — разработчики, архитекторы и (дев)опсы, а про третье — техписатели. Но бывает как угодно: аналитиков заставляют писать доки, техписателей — делать ТЗ, продакты сами идут проектировать API, а знания об эксплуатации передаются устно, как фольклор, в процессе починки инцидента. Через неделю, 19 июня, мы попробуем разобраться хотя бы в части этой истории. Александра Камзеева и Андрей Бураков позвали меня к себе в подкаст, чтобы обсудить техписателей и аналитиков: их роли, задачи и навыки. Что общего, в чем отличия, как те и другие могут друг другу помогать. Приходите послушать нас! И накидывайте вопросы заранее: здесь или в комментариях в @nextway_news. (Да, надо сразу сказать, что я себя не считаю «гуру техписательства», но побуду в роли techwriter advocate. Раз у разработчиков есть авокадо, значит и у техписателей могут быть.)

Подборка каналов для тимлидов. Я недавно уже публиковал папку с подборкой тимлидских каналов. А теперь хорошие ребята, авторы таких каналов собрались и сделали свою папку. В ней разные каналы непосредственно про управление разработкой и просто полезные для тимлидов. На две трети я уже был подписан, а про остальные просто рад был узнать. Ну и мой там тоже есть. Путь из линейных сотрудников (individual contributor) в руководители сложный и тяжёлый. А читать заметки других людей, которые проходят тот же путь, что и вы, это большая поддержка и помощь. Я бы точно не вывез, если бы не читал разных хороших людей и не общался с ними. Как-то так вышло, что несколько человек, которые на меня значительно повлияли, ведут свои каналы, и они есть в этой папке. Держите, подписывайтесь. Там можно на всё сразу, а можно повыбирать. https://t.me/addlist/mDWR2gD6UEhlOWRi

В develop relations мне не нравится одна вещь — само название. Я вот не могу прийти к сообществу разработчиков и сказать «привет, я Коля, я тут чтобы с вами отношения налаживать». Я и у себя в голове не могу такое всерьёз сказать, для меня это звучит очень неестественно. Я думал, почему это так, и вот что придумал. Вот я соскучился по друзьям и предлагаю им созвониться или поиграть в настолки. Такие встречи поддерживают наши отношения. Но я же не пишу "my dudes, я хочу улучшить нашу дружбу, давайте сделаем ивент, будем играть в террарию на выходных". Или вот представьте, что вы зовёте на свидание девушку или парня, которые вам нравятся. Или вы уже 20 лет в браке, суть та же. Будет максимально кринжово сказать «давай сходим в ресторан, чтобы улучшить наши отношения». И будет очень так нормально сказать «хочу провести с тобой время и тебя порадовать». Так и с профессиональными сообществами, например, с инженерами, которые используют наши технологии. Если сделать так чтобы людям было понятно как работать, дать им хорошие инструменты, чувство причастности и признания в сообществе, то и отношения будут норм. Выходит, что отношения — это такой сайд-эффект всего, что мы делаем и проживаем вместе. Это побочный результат, но не сам наш опыт, ради которого мы это делаем и проживаем. И develop relations — это не предмет деятельности и не цель, а некоторая характеристика результата. Метрика. И определять профессию через метрику это в самом деле что-то странное. Так что привет, я Коля, моя задача в том, чтобы вам было удобно и понятно как работать.

Вакансии в команду Developer Relations в nil.foundation Итак, у меня есть две вакансии в мою команду. Мы пишем и рассказываем про сложные штуки: компиляторы, криптографию, базы данных, протоколы. Нужен отличный английский, хороший технический бэкграунд, способность работать автономно и самостоятельно формулировать цели. Мы стартап, будьте готовы разбираться в куче всего нового и выстраивать процесс работы по ходу работы. Ссылки на вакансии, там внутри есть почта: — Technical writer — Developer advocate Подробнее про команду и мой подход к работе я писал в прошлом посте. Нужно находиться за пределами РФ и РБ, в идеале — в Европе или Штатах. Релокация на Кипр «под ключ» или в другую страну по номад-визе.

Короче, пора рассказать, что я теперь делаю. С февраля я работаю в компании, которая делает инструменты для разработчиков. Про компанию расскажу отдельным постом, пока что про себя. Я тут занимаюсь developer relations. Сейчас объясню, что это за штука такая. Давайте начнем с простого, представим что мы с вами — техписатель в начале карьеры. Техписатель пишет документацию для инженеров где-то вне компании, чтобы они могли использовать продукты этой компании. Теперь сделаем “unfold”, развернем одно из ограничений. Будем писать не только документацию, а еще статьи в блог, учебные задачки с подробным объяснением и разные другие текстовые форматы. Мы же умеем хорошо писать, зачем ограничиваться документацией, другие форматы тоже могут решать нашу задачу. Ещё один unfold: мы вдруг поняли, что внутри компании тоже есть инженеры, для них тоже можно писать. Разработчики, тестировщики, инженеры эксплуатации, техписатели, исследователи. Они и так раньше почитывали документацию, но теперь мы можем написать что-то и специально для них. Потом оказывается, что иногда текст воспринимается плохо, надо рассказывать и показывать. Мы с вами тренируемся это делать, осваиваем всякие комбинированные форматы: выступления, воркшопы, курсы, live coding всякий, тренинги. Теперь наша с вами специальность — технические коммуникации, а инструментов у нас много и мы их подбираем под конкретную задачу и аудиторию. К этому этапу работы уже так много, что в одиночку ее никак не сделать, появляется команда. Можно пойти в тимлиды, можно остаться линейным сотрудником в команде. Все варианты хороши. Но и усилий одной команды недостаточно, если только она занимается коммуникациями. Мы-то неплохо так умеем писать и выступать, а люди вокруг нас часто умеют хуже, и мы их собой не заменим. Пришло время помогать и обучать, повышать культуру коммуникаций. Теперь мы чувствуем ответственность и влияем на коммуникации внутри компании и наружу, про технологии и не только, текстом и голосом. Успеваем всё это делать сами, но половину пользы приносим в том, что все остальные с каждым днем начинают коммуницировать немного лучше, легче, чаще и точнее. >>> Вы находитесь здесь <<< Всё это в индустрии называется developer relations и этим я занимаюсь. Нас в команде двое, прямо сейчас есть вакансии на еще двоих: technical writer и developer advocate. Я напишу пост про вакансии на этой неделе, но если вам уже интересно, пишите в личку @nick_volynkin прямо сейчас.

Купил новую бутылку для воды. Принес домой, радостно налил в неё воду из помпы, потом заметил что внутри лежит инструкция. Инструкция колд-брю — идеальный напиток для человека, который пишет инструкции.

Недавно подал заявку доклад на DevRelCon в Лондоне. Заявки сочиняли на троих с Бáрухом @JBaruch Садогурским и ChatGPT4 — сейчас расскажу, как это было. Но начну с того, как вообще обычно люди подают доклады на конференции, чтобы было понятно. В общем случае, надо придумать тему, написать про нее и отправить этот текст программному комитету конфы. Это можно делать по-разному. — Простой сценарий: автор доклада самостоятельно думает про тему, формулирует тезисы и сочиняет заявку. Это долго, сложно и мучительно. До финиша доходят не все. — Хороший сценарий: автор рассказывает свои мысли помощнику, тот задает вопросы, уточняет, спорит, подсказывает. Вместе они формулируют тезисы и сочиняют заявку. Это уже интересно, более продуктивно, но все еще сложно в конце написать текст заявки. Особенно сложно, когда язык не родной. — Наш крутецкий сценарий: автор с помощником так же общаются, спорят и делятся идеями. Потом все эти идеи вот как есть пишут в ChatGPT, получают в ответ красивую формулировку, дополнительными запросами уточняют смысл, пока в ответ не получат текст, который идеально выражает мысль. У меня доклад был вообще для новичков и всех-всех-всех, его мы сформулировали минут за 15 до состояния, когда можно нажимать кнопку в форме подачи. У Баруха посложнее, он вводит новую концепцию, так что ушло минут 45. На скриншоте мой abstract. С первого раза получилось сразу хорошо, а вторая попытка не понравилась, так что я взял первую. Итог: классно работать в команде с хорошими людьми и с хорошими инструментами. Барух, спасибо!

Каналы про тимлидов и про коммуникации. Телеграм только что выкатил новую фичу: теперь папками из телеграма можно делиться. Я взял свои папки про тимлидство и про технические коммуникации (доки + управление знаниями + деврел), убрал из них 1-1 и закрытые чатики, и вот что получилось. TeamLead: https://t.me/addlist/l5DYX3mRhwtiYWU6 DocOps: https://t.me/addlist/3GI1i-KgDPI3ODli Если не работает — обновите приложение :) Подборки полностью субъективны, я наверняка что-то хорошее пропустил, так что фидбек и предложения принимаю. Пишите комменты )

Расскажите про IT-сообщества и всякий движ в Армении и Грузии? Что там по митапам и конференциям? Хочу совместить приятное с полезным: познакомиться с вами, выступить с каким-нибудь полезным докладом, посмотреть на страну, поесть вкусной еды. Если вам удобнее голосом — давайте созвонимся и обсудим за утренним кофе. Букайте встречу. :) А, и если есть какие-то хорошие айтишные чатики в телеге, скиньте ссылки, пожалуйста. Можно на любом языке.