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

Приходите слушать: https://youtu.be/cI5yxP276Eg

Oh yeah, me grug brained too, can relate.

https://grugbrain.dev/

KnowledgeConf возвращается.

Следующая конференция будет этой осенью, 30 ноября и 1 декабря, на одной площадке с TeamLead Conf и TechLead Conf.
Мы уже принимаем заявки на доклады. Читайте подробности и подавайте заявки: https://cfp.knowledgeconf.ru/.

А прямо сегодня, через час (в 17 часов Мск), будет встреча с программным комитетом. Приходите, если хотите выступить с докладом. Особенно, если хотите, но сомневаетесь. Регистрация тут: https://conf.ontico.ru/event/join/open_kc2023.html.

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

Еще раз все части списком:
— Конференция на сотни человек, интернет наверняка плохой.
— Рабочее окружение проще всего получить в докере, остальные способы даже не рассматриваем.
— Код на плюсах, субмодули на субмодулях, всё как принято в плюсовой экосистеме.

Как видите, есть куча мест, где всё может сломаться. Я думаю о том, как подстраховать участников на каждом шаге. Некоторые идеи есть, но всё равно обращаюсь к коллективному опыту читателей. Если вы проводили или участвовали в таких тренингах/воркшопах, расскажите, где всё сломается и как это заранее починить?

Как проведем, напишу еще один пост про то, что мы делали и как всё прошло.

Пора рассказать, что у нас получилось с воркшопом.

Мы предполагали, что на воркшопе случатся все возможные технические проблемы: люди придут с ноутбуками на самых разных ОС, заранее точно никто ничего не скачает и не настроит, а интернет на конференции будет отвратительный. Так обычно бывает, когда сотни человек собираются в одном помещении. Ещё мы рассчитывали, что все будут немного уставшие на третий день, что яркость экрана может быть плохой, что будет шумно. А еще совершенно точно мы будем в последний момент находить баги, исправлять их, релизить, и участники должны будут использовать последний релиз.

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

Последовательность действий разбили на шаги. Каждый шаг — длинная команда в консоли или пара команд. Всё это мы завернули в один скрипт, чтобы каждый шаг в первый раз выполнять одной командой, вроде run.sh compile. Это должно было застраховать участников от ошибок, когда они невнимательно переписали команду или что-то пропустили. А потом, когда в перый раз всё получилось, можно развернуть подробную инструкцию, где объясняется каждый параметр в длинной команде, и выполнить еще разок.

Завернули всё в докер, чтобы не заморачиваться с настройкой окружения. Получилось два образа: в одном наш компилятор, в другом тулзы для работы с веб-сервисом. Буквально в последний день добавился третий, в котором локально поднимается нода Ethereum и на ней смарт-контракт выполняет завершающий шаг вокршопа.

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

Чтобы не тратить время и интернет на подготовку окружения, мы сделали готовые виртуальные машины в AWS. На них сразу был клонирован репозиторий с кодом для воркшопа, установлен Docker, и скачана пара нужных образов. Так мы защитились от плохого интернета, неработающего докера и неподдерживаемых архитектур проца. У меня был готовый inventory, так что с помощью Ansible я мог быстро обновлять код и образы на машинках. И еще был плейбук для того чтобы раскидать по машинкам ключи, чтобы люди могли зайти по SSH. Соединение по SSH — штука нетребовательная и довольно живучая. Даже с плохим каналом можно зайти и работать. Рассчитывали на 15-30 участников, поэтому заранее подняли 30 машинок.

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

Подготовились в целом отлично. Не учли только один риск, и как раз он и случился. Как вы думаете, что это было?

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

---

Если что, всё прошло нормально, я жив, напишу ещё про опыт.

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

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

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

Есть хорошая топология документации: tutorials, guides, explanations, reference. Я писал про нее три года назад и с тех пор активно использую в работе. Всё это время я видел в ней только логику пользовательского пути:

1. Разработчик пишет hello world, чтобы попробовать и заинтересоваться.
2. Проходит несколько гайдов, чтобы опробовать технологию в деле или разобраться, как решать конкретную задачу.
3. Потом читает объяснительные статьи и разбирается в тонкостях технологии. Это путь к профессиональному владению инструментами.
4. Наконец, после пары лет уверенного пользования инструментом, разработчик только заглядывает в референс, когда не помнит деталей API.

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

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

2. Гайды по решению конкретных задач нужны для того, чтобы ускорить разработку до состояния прототипа, proof of concept. На основании этого прототипа бизнес будет решать, вкладывать ли дальше ресурсы в разработку решения на вашей технологии, или выбрать что-то другое. А еще набор типичных решаемых задач помогает предпринимателям находить такие задачи в окружающем мире и решать их именно с помощью вашей технологии.

3. Статьи про то, как делать правильно, нужны на этапе разработки приложения после одобренного прототипа. Там будут появляться первые большие проблемы: производительность, надежность, безопасность, масштабируемость решения. Для того, чтобы эти проблемы решить, разработчикам понадобятся объяснительные статьи. До этого этапа они не нужны — рано еще решать проблемы, надо выжить. Результат этого этапа — MVP, первая версия продукта, у которой есть пользователи и которая решает их задачу. Но и дальше такие статьи не теряют своей ценности.

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

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

Желаю вашим продуктам дожить до этого прекрасного времени. :)

Нет времени объяснять, запрыгивайте в трансляцию :)
https://www.youtube.com/watch?v=NBdZmyNGdcQ

Когда-то я купил микрофон и радовался ему. Заодно обещал курс и митапы. С тех пор я сменил работу и пару стран, курса всё ещё нет, зато митапы я на работе теперь делаю. И вот новый микрофон приехал.

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

О чем бы вы послушали? О чем бы пришли поговорить со мной?

Хорошая новость в том, что такое можно репортить в @NoToScam. Плохая новость в том, что репорты никто не читает, похоже. Мой прошлый репорт так и висит с 2020 года.

Тем временем, поддельную учетку переименовали и я закиберсквоттил имя себе.

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

Зарегался в Вастрик-клубе, занёс долор, написал интро. Если вы тоже там, давайте дружить и общаться.

https://vas3k.club/user/nickvolynkin/

Пока нормальные посты не пишутся, поделюсь смешным видео. Человек читает мануал neovim с начала до конца, девять с половиной часов.

Как вы думаете, мануал такой длинный, потому что продукт сложный, или же потому что в него вложено недостаточно труда, чтобы сделать его короче и понятнее? А может, надо было в сам редактор вложить побольше труда, чтобы он был понятнее? (Конечно же нет, чем сложнее тем лучше, тут же ценность в преодолении страданий и достижении абсолютной эффективности.)

https://www.youtube.com/watch?v=rT-fbLFOCy0

Goodhart's Law (xkcd)

[later] I'm pleased to report we're now identifying and replacing hundreds of outdated metrics per hour.

(сохраните на случай переговоров про метрики со своим менеджером)

Doom на дашборде Grafana! Гениальный devrel-проект. Снимаю шляпу, восхищаюсь, хочу куда-нибудь украсть эту идею.

Ну и если где-то я увижу «в графане нельзя сделать Х», буду в ответ кидать эту ссылочку.

https://play.grafana.org/d/ePolu9Lnk/doom-half-resolution?orgId=1

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

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

Ладно бы только длина полоски противоречила идее сообщения. Они еще и слово удлиннили, и полоску закрасили красным. Красная полоска в метриках это что? Это всегда что-то плохое.

Так досадно, хоть письмо пиши.

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

Старый мем переродился