Хобби

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

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

Ключевое слово тут "социальное". Это не спорт (бывают спортивно-бальные танцы, в программу которых входит латина, и в её числе танго), не фитнес, не фольклорный кружок. Социальные танцы это хобби, которым занимаются миллионы людей во всём мире, и сейчас я вам расскажу, почему это идеальное занятие для аудитории Хабра: инженеров-разработчиков ПО, тестировщиков, SRE и прочих, кого ещё недавно снисходительно называли nerds и geeks (пока наши компании не стали получать миллиардные оценки, а мы сами - становиться миллионерами в те самые 30).

Ещё один важный признак социальных танцев они танцуются в парах, где есть роли ведущего и ведомого, leader и follower (вот во что, кстати, надо было переименовывать неполиткорректные master и slave). Пары эти формируются экспромтом: в танго есть понятие кабесео/мирада, когда потенциальные партнёры встречаются взглядами, кивают друг другу, партнёр подходит к партнёрше и приглашает её жестом на танцпол. В других социальных танцах наверное есть свои, более или менее формальные способы договориться о танце. Сами социальные танцы в значительной мере импровизационные, в них, конечно, есть отдельные фигуры и связки, но как именно и в каком порядке их компоновать ведущий в паре решает в процессе танца, исходя из музыки, своего настроения и наличия свободного места на танцполе.

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

Таким образом, типичная неделя ученика в группе социальных танцев состоит из двух групповых уроков по полтора часа и минимум трёх часов самостоятельной практики, без которой уроки практически не имеют смысла: на уроках мы только усваиваем материал, а для механического запоминания требуется его многократное повторение. Помимо уроков и практик вам придётся хотя бы минимально потратиться на одежду и обувь. Со временем вы захотите посещать более дорогие семинары и интенсивы и даже брать частные уроки (я со своим более чем десятилетним стажем продолжаю это делать регулярно), а также покупать или шить на заказ танцевальную "экипировку". Ради чего, спрашивается, такие вложения денег, и, что важнее, времени? И почему именно работникам сферы IT я так настойчиво рекомендую этим заниматься?

В первую очередь, социальные танцы это замечательный способ социализации (каламбур намеренный). На уроках и практиках, а также на милонгах (так называются танго-вечеринки), сальсатеках и вечеринках других танцев встречаются самые разные люди, с которыми вас будут объединять общие интересы, темы для бесед, и это прекрасно как для удовлетворения базовой потребности в общении, так и для заведения новых полезных контактов, а также, last but not least, знакомств с противоположным полом. Женщины в социальных танцах отрываются по полной по части платьев, обуви, причёсок и макияжа: всё, чего им иногда не хватает в повседневной жизни, они могут в полной мере воплотить на танцполе, поэтому с непривычки глаза разбегаются, а пульс учащается до легкой тахикардии. Ритуалы выбора партнёров и партнёрш изрядно напоминают аналогичные гендерные ритуалы флирта и соблазнения, а сам пятнадцатиминутный танец может выразить без слов множество эмоций и помогает узнать друг друга лучше, чем переписки в Тиндере или свидания в кофейнях. Впрочем, перейти от танца к непринуждённой беседе проще простого: напоминаю, работает бар!

(не прерывайте чтение на предыдущем абзаце, это не все ништяки социальных танцев!)

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

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

Но и это ещё не всё! Третий кит танцев это физическая форма. На первый взгляд кажется, что большинство социальных танцев, в отличие от бально-спортивных, особых усилий не требуют, особенно если речь об аргентинском танго, а не буги-вуги или линди-хопе. Но впечатление это обманчиво: музыка бывает быстрая, фигуры и связки сложные и требующие определённой ловкости, а также много сил требуется на сохранение баланса (стопы и голеностоп), удержание своей оси (мышцы спины и корсетные мышцы), объятия с партнёршей (мыщцы рук). Каждый шаг в танго акцентирован и, начинаясь от пола, заканчивается в точке контакта пары, задействуя все мускулы по дороге. И так полтора часа урока, два часа практики или 3-4 часа милонги!

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

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

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

Во-вторых, в танго больше всего сложных эмоций и чувств. Нормой для танго является близкое объятие, когда корпуса партнёра и партнёрши плотно прижаты в районе груди. Мы фактически танцуем, обнявшись! Чувствовать микродвижения друг друга, деликатно касаться ступнями, слышать дыхание, замирать или срываться с места в унисон для меня бесценно. Ну и просто обниматься с другими людьми полезно для здоровья (да, есть научные исследования).

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

Лично для меня не последнюю роль играет такая штука, как танго-туризм. Аргентинское социальное танго так широко раскинулось по планете, что танцующие тусовки есть практически в любом крупном городе мира, кроме стран, где телесный контакт между малознакомыми людьми считается неэтичным или вообще запрещён. Отправляясь в любую поездку, я кидаю в сумку пару танцевальной обуви, и практически уверен, что если захочу пойти потанцевать без труда найду себе такую возможность, как это много раз бывало в Израиле, на Кипре, в Турции, Греции, Хорватии, Италии, Франции, Испании, Германии, Дании, США, да где только не бывало. До коронавируса по всему миру, и в том числе в России и Беларуси проводились танго-фестивали, включающие как просто милонги, так и мастер-классы маэстро мирового уровня. Это было отличным поводом выбрать место для очередного отпуска: и город посмотреть, и вечером всегда есть чем заняться. Питер, Нижний, Челябинск, Минск, Стамбул, Неаполь, Генуя, Барселона вот только некоторые места, где я посещал отличные эвенты и знакомился с классными людьми.

И напоследок: когда базовые движения затанцованы до автоматизма, а нужные группы мышц постоянно находятся в тонусе, требования к физической форме становятся не такими острыми, как в начале пути. В результате танго можно танцевать и в достаточно преклонном возрасте 60-70 лет, в отличие от остальных социальных танцев, где такое скорее исключение. На милонгах в Аргентине, где танго-культура наиболее жива и интегрирована в общество, не будет сюрпризом встретить танцоров 80 лет и даже старше. Просто посмотрите, как великий Карлос Гавито в почти 60 лет танцует с 35-летней Марселой Дюран под музыку Освальдо Пульезе. Это шоу стало одним из катализаторов моего прихода в танго, а мелодия до сих пор одна из самых любимых:

Теперь у вас, наверное, остался один вопрос: с чего начать свой путь в социальные танцы, как понять, моё это или нет? Если статья вызовет интерес я напишу продолжение об этом и многом другом, что встретится на пути социального танцора, а также поделюсь личным опытом. А пока вместо ссылки на продолжение ссылка на открытый урок, который пройдёт 19 февраля (пятница) в 20:00 в московской студии El Gato Tango в Армянском переулке, где я занимаюсь бльшую часть своей танго-жизни и которую, разумеется, от души рекомендую. Преподаватели расскажут об истории и современности танго, покажут танцевание в разных стилях и под разную музыку, а под конец поставят желающих в пары и покажут несколько простых движений в учебном объятии.

Доброго всем дня! В предыдущей части я представил на суд свою реализацию избитой идеи подсветки лестничного марша. Статья касалась только "железной" части проекта. В этот раз постараюсь описать процесс "оживления" сего девайса. Процесс получился достаточно затяжной, поскольку проект ведется "в свободное от основной работы время" с перерывами и явно проигрывает по важности прочим домашним делам :). Доработка ведется и сейчас, но уже есть, что показать.

Среда разработки

Пусть меня закидают грязными тряпками, но тут для меня однозначно лучшая - Keil uVision (4)5. Эта одна из самых мощных IDE для большого количества камней. Я даже не буду агитировать за нее и описывать все преимущества, поскольку мое мнение в данном вопросе крайне предвзято. Просто я давно работаю с этой IDE и она мне нравится. Самый большой ее минус - она платная и стоит очень конских денег. Но только не в данном случае. На наше счастье у Keil есть демо режим с ограничением в 32Кб. А в LPC11C14 всего 32Кб! Получается для этого камня можно вполне легально и полноценно использовать этот мощный инструмент! Достаточно скачать его с официального сайта. Заполняем простую анкету и получаем ссылку на скачку.

Остался открытым вопрос работы с "железом". Самый удобный - это использовать заводской программатор. Keil поддерживает большое количество отладочных систем и JTAG адаптеров. Такой подход позволит вести полноценную отладку проекта. А что делать, если нет отладчика\программатора и требуется только прошить контроллер? А на этот случай есть замечательная утилита Flash Magic, которая позволяет оживить устройство, используя вшитый в ARM загрузчик. Данная утилита работает только с контроллерами NXP. Загрузка происходит через UART. Эта замечательная прога не раз выручала меня в командировках, когда под рукой не было программатора или он выходил из строя. Замечу, что все необходимые сигналы у девайса уже выведены на разъем для программирования. Ссылка для скачивания Flash Magic здесь.

Сборка платы

Долго ли, коротко ли шли платы из Поднебесной, но вот они у меня на столе.

Монтаж не заставил себя долго ждать и вот что получилось в результате:

Далее была написана простенькая тестовая программка для проверки всех основных узлов платы. Как обычно пишется в этих случаях - при правильной сборке из исправных компонентов должна заработать сразу. Должна - заработала!

Подготовка софта

По началу тут было всё относительно просто. Пишем\адаптируем все необходимые драйверы для периферии, а именно:

• драйвер датчика освещенности MAX44009EDT

• драйвер датчика расстояния VL53L0X

• драйвер управления адресной лентой

• драйвер CAN интерфейса

После того, как все драйвера были подготовлены наступила очередь первого тестового включения на публике.

Признаюсь честно - особого эффекта сия конструкция на домашних не произвела. Папаня и раньше всякие свистелки-перделки делал. Одним фонариком больше, одним меньше. Интерес проявила лишь домашняя любимица - кошка Куня. И та все норовила лапой зацепить светлячка. Ну да ладно, будем делать дальше.

Здесь хотел сделать небольшое техническое отступление, поскольку хронологически событие, с которым оно связано, именно здесь и наступило. Я раньше не работал с компонентами из ближайшего магазина и цели максимально снизить стоимость у меня на работе не стоит. Спрос идет за качество. А тут я в полной мере ощутил что значит "китайское электричество до конца не изучено". Просто все работало - работало, а в один не очень прекрасный день вдруг перестало. Причина была выявлена очень быстро. Сгорел линейный стабилизатор AMS1117-5.0. И не просто сгорел сам и все, а прикинулся перемычкой и утащил с собой всех, кто на него надеялся. Цензурных слов у меня в тот момент не было. Я, как человек, привыкший доверять техническому описанию на компоненты не мог понять, что не так. Стабилизатор работал в штатном режиме. А фраза из описания "The AMS1117 series have internal power and thermal limiting circuitry designed to protect the device under overload conditions" уже была похожа на издевку. Немного полазив по просторам инета я понял, что не у меня одного такие проблемы с этим стабилизатором. А что вы хотите? Дешево! Какой спрос? Короче, не имея никакого желания заново перепаивать половину схемы я поставил годами проверенный вариант - LM1117-5.0 (кстати, не в Чип-Дипе купленный). На мое счастье он встал на плату как родной.

Ну да ладно, плата восстановлена, можно двигаться дальше.

И тут наступил какой-то творческий ступор. А что дальше? Есть железо, на котором можно сделать много разных эффектов. А что делать конкретно? Можно просто включать монотонную подсветку (неинтересно и скучно), можно поиграть с цветами (пестрота быстро надоест), можно организовать необычные динамические сцены. Много чего можно, надо на чем-то остановиться. Здесь главное не переборщить с творчеством!

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

• в темноте светится дежурная подсветка (первая ступень)

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

• как только линия вдоль пролета разгорелась, она разделяется на две, которые расходятся в стороны (посадочные огни вдоль полосы)

• между этими огнями начинает плавно по очереди разгораться подсветка ступеней

Это описание касается только стадии включения. Гашение ступеней можно сделать аналогично, только в обратную сторону или просто плавно погасить.

Что-же потребуется для реализации?

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

Для того, чтобы выполнить вышеописанные условия ленту пришлось уложить "змейкой".

Кроме этого необходимо не забыть, что потребление сего чуда достаточно большое и питание каждого фрагмента (ступени) желательно сделать индивидуальным.

Для того, чтобы проще было "рисовать" на таком "экране" и не требовалось каждый раз вычислять положение нужной LED-точки в программе подготавливается массив, содержащий "карту" их расположения:

// создание карты светодиодов (см. файл LED-карты)void CREATE_LEDS_MAP (void){static const uint8_t stepPerStair = STAIRS_NUM;static const uint8_t ledsPerStep = LEDGROUPS_FOR_STAIR;for (uint8_t step = 0; step < stepPerStair; step++){for (uint8_t led = 0; led < ledsPerStep; led++){if (step % 2 == 0){LedMap[led][step] = ((step) * ledsPerStep) + led + 1;            }            else            {LedMap[led][step] = ((step + 1) * ledsPerStep) - led;            }        }    }}

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

В качестве заключения

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

Печатная плата

Программа

P.S. Если у кого-то будет желание доделать или внести что-то свое могу отдать два комплекта пустышек (по комплекту на лестницу) и процы к ним (как помните, у меня их много).

Их было шестеро - барабанщик, басист, клавишник, гитарист, баянист и человек с татуировками. Как-то так начинался бы фильм о нас, о музыкальной группе Sun-Techniki.

Вы, возможно, скажете ШТА?! Я точно на Хабре? Причём тут какой-то фильм о музыкальных сантехниках?

Да, это Хабр, и это рассказ про музыкальную группу, состоящую из сотрудников одной продуктовой IT-компании.

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

Кратко о нас: мы не профессионалы в музыке, мы профессионалы в разработке софта. Наш софт обслуживает 6% активных веб-сайтов мира (согласно Netcraft), а наша группа выступает на корпоративах в качестве хедлайнеров и за восемь выступлений мы подготовили и сыграли без малого сорок каверов. На каждое выступление мы готовим новую программу, при этом текст часто переделывается так, чтобы отражать тему корпоратива и события в жизни компании. В поддержку выступления идут слайды, которые крутит наш слайд-жокей.

Рассказ получился объёмным, поэтому без оглавления никуда:

1. Старт проекта / Прикидываем программу выступления

2. Управление проектом / Дисциплина бьёт талант

3. Прототип / Щупаем номера

4. MVP (точнее, MAP) / Минимально допустимое выступление

5. Тестирование, багфиксинг / Гоняем программу, находим места для улучшений

6. Релиз (раскатка) / Выступление

7. Ретроспектива

8. Заключение / Почему вам тоже стоит заниматься музыкой

9. Бонусы

Вступление закончено, начинаем!

Старт проекта / Прикидываем программу выступления

Дедлайн / Дата выступления

Корпоратив состоится 21 декабря - если ждать такого письма, то ничего не успеешь. Но зачем ждать, если известно, что корпоративы будут в конце декабря и в конце июля, а восьмое марта будет седьмого марта? Мы ретроспективно знаем свою capacity, поэтому собираемся за три месяца до предполагаемого дедлайна. Позже будет известна точная дата, позже будет известна точная тема, но мы уже должны начинать.

Содержание проекта / Треклист

Начинаем мы с кандидатов в треклист выступления. У выступления есть стандартный общий план:

• выход (что-то пафосное, заряжающее, вызывающее аппетит)

• разогрев (может быть совмещён с выходом)

• заполнение (обычно что-то спокойное)

• набор напряжения (мы называем это ebanukha, что в переводе с суахили означает это воняет, то есть что-то панковское отвязное, может быть треш)

• финал, в котором должен произойти катарсис и поставлена точка

Ресурсы / Кто участвует в выступлении

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

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

Брейншторм

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

Про брейншторм на Хабре писали, например, тут: 15 способов превратить мозговой штурм в результат огонь

Брейншторм у нас не совсем классический - после вброса кандидата мы сразу обсуждаем его. Кандидат отбрасывается если:

• кто-то против. Достаточно одного голоса.

• штука очевидно нам не по зубам на текущий момент. Такой кандидат обычно идёт в бэклог - в следующий раз может быть мы будем к нему готовы.

• вещь никак не сочетается с другими кандидатами или темой (конь-цепцией). Тоже в бэклог.

• вещь очевидно заметно слабее тех, кто уже есть в кандидатах. Нет смысла тратить на неё время сейчас. В бэклог.

• вещь очевидно не будет принята аудиторией или другими заинтересованными лицами

Очевидно у нас означает мнение большинства. Мы отлично знаем, что нет ничего очевидного.

Как пример пункта 5 - я всегда хотел на восьмое марта (а лучше на 14 февраля) выпустить кавер на трек Pussy от Rammstein. Моё извращённое чувство юмора считает, что это постирония и очень смешно. Но как Product Manager я понимаю, что core segment аудитории этот пассаж не оценит.

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

Управление проектом / Дисциплина бьёт талант

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

Другое дело релиз концерта. Это проект: тут есть понятный бюджет (наш бюджет - это время, которое мы можем потратить на подготовку), чёткий expected result, жёстко зафиксированная дата, есть неопределённость пути от начала к концу. Поэтому для работы над концертом мы выбираем не гибкие методологии (мы их тоже умеем), а традиционное PMBoK-овское проектное управление.

План (Work Breakdown Structure a.k.a. Иерархическая структура работ)

Ключевые вещи в проектном управлении - это WBS (Work Breakdown Structure), майлстоуны (то есть промежуточные дедлайны), зависимости, ресурсы и управление рисками.

Про проектное управление: PMBoK за 2.5 часа: интервью с Иваном Селиховкиным

Про конкретно WBS: 4 инструмента по полочкам. Управление проектами с WBS, Диаграммой Ганта, CPM и Time-Cost или Преимущества Иерархической Структуры Работ (WBS) для менеджеров ИТ проектов

Про оценку задач: Оценка. Рассчитать и уложиться

Про управление рисками расскажу сам ниже.

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

Капитанские, но, оказывается, не всем очевидные принципы построения WBS:

• строй WBS справа налево (вот так: <--), то есть:

  • справа напиши результат - концерт готов

  • задай вопрос что мешает считать, что результат достигнут? - номера не готовы, сцена не готова

  • и так рекурсируй до элементарных задач

• после составления WBS пройди уже слева направо (-->) и на каждую задачу задай вопрос а почему я не могу эту задачу выкинуть?

• майлстоуны аналогично - справа налево (опять <--). Потому что дедлайн у нас задан заранее

В традиционных трудах по WBS эту структуру рисуют сверху вниз (вверху цель, внизу этапы), но сейчас чаще это всё укладывают в диаграмму Ганта (ужас какой), поэтому я и пишу про справа налево.

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

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

Инструментарий

Мы не используем ничего тяжёлого - нас не так много, проект структурно не такой сложный. Нам хватает каталога в Google Drive на концерт, в этом каталоге несколько документов:

• тексты и прочие заметки по номерам

• документ по планам и рискам (в нём несколько секций, в том числе и оперативные - worklog, brainstorm, шорт-лист треков и подобное)

• чеклист на сам концерт, он же райдер ;)

• после концерта в каталог добавится документ по ретроспективе

Отдельно, в корне, лежит документ с общим бэклогом.

Управление рисками

Отдельно коснусь моей любимой темы - управление рисками. Почему тема любима - потому что она незаслуженно игнорируется очень многими. А ведь это просто и полезно!

Как и обещал, про риски рассказываю прямо здесь, без ссылок.

Алгоритм:

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

2. У риска оценивается вероятность срабатывания и тяжесть последствий

3. Риски сортируются по вероятности и тяжести, и в работу берётся N топов в каждой категории. N зависит от бюджета на работу над рисками

4. Риску прописываются два плана:

   1. План А - что надо сделать для уменьшения вероятности срабатывания риска

   2. План Б - что надо будет сделать для уменьшения тяжести последствий в случае срабатывания риска

Когда у тебя есть такая таблица, то ты мало-мальски готов встретиться с фортуной лицом к лицу, а не как обычно.

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

Для первого риска (участник заболел) предлагаю вам придумать План А и План Б и написать его в комментариях, а про второй (номер не получается) расскажу сам - План Б там вовремя понять, что не прёт и заменить трек на резервный.

Резервный трек отбирается так, чтобы его можно было легко и быстро подготовить. Как вариант резервного трека можно взять старый трек, который мы уже когда-то готовили. Если даже План Б провалился, то есть План Б2 - выкинуть трек вообще и выходить сокращённой программой. Ну либо затащить слабый номер харизмой ;)

Из типичных рисков - плохой звук на площадке. Здесь хорошего Плана Б нет, поэтому в План А (грамотно подготовить площадку и звук на ней) вкладывается довольно много ресурсов, это и выезд на площадку заранее (чтобы можно было перенести площадку в другое место), и найм крутых звуковиков, и несколько саундчеков, и детальнейший чеклист. Но про это ниже.

Из рисков, которые мы не учитывали, но которые сыграли - это выход из строя оборудования. Один раз у нас сломался баян за пять дней до выступления. Сломался жёстко, я не смог его починить. План Б мы выдумали и осуществили очень оперативно - попросили баян взаймы у знакомых. А План А я потом выполнял самостоятельно - купил новый баян.

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

Прототип / Щупаем номера

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

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

В случае музыки багоопасность - это, например, сложная партия, особенно вокальная, для хорошего выполнения которой нужны конкретные физические кондиции в конкретный момент. Мы все достаточно неплохо играем на инструментах (у половины полноценное музыкальное образование), но никто не занимался вокалом профессионально, потому если говорить о тесситуре, то нужно, чтобы песня укладывалась в октаву-полторы, если больше - то скорее всего надо что-то делать. Нередко мы разбиваем партии на несколько голосов, ибо по диапазону голоса у нас разные.

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

Это всё и выясняется на прототипировании, или, как мы это называем, на прощупывании.

MVP (точнее, MAP) / Минимально допустимое выступление

Из продуктового опыта мы знаем, что лучше всего сделать MVP (Minimum Viable Product), и потом его дободрить. Почему? Тема для отдельной статьи ;)

В нашем случае более правильно говорить не MVP, а MAP - Minimum Awesome Product. Ни нам, ни нашей публике не нужно тухлое выступление, нужно awesome выступление!

Про MVP: MVP: что это такое и как работает? (а тут разбор знаменитой картинки с самокатом: Как определить функционал MVP и влюбить клиента в пилотную версию продукта) и сорри за Medium, но на Хабре не нашёл подходящей статьи: The MVP is dead, long life to the MAP.

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

Вовлечение / Эмоциональная кривая

В концерте, как и в любом художественном произведении, нужна завязка, развитие и финал. За этим нужно следить на всех уровнях - вечер целиком (наше выступление должно быть кульминацией), само выступление, отдельный номер.

Отличаемся от других / Фишки номеров

Для успеха продукт должен чем-то выделяться, чем-то отличаться от остальных. Мало кому (а прежде всего нам самим) интересны каверы один в один. Это значит, что в кавере должно быть что-то своё. Это может быть другой стиль, это могут быть какие-то фишечки с заменой инструментов или переплетением разных треков. И всё это должно быть не в одной песне, а цельно на всё выступление.

Кто услышит тут отсылочку к совершенно другому произведению - пишите в комментах! И отдельное спасибо программе "Соль" за proof of concept участия баяна в этой песне.

UI, UX / Тексты

Мы всегда хотим, чтобы тексты у нас были готовы уже на этапе MVP, но как правило по самым разным причинам у нас это не получается. Практически никогда тексты не были готовы заранее. Не делайте так ;) Тексты - это сложно, это важно, они могут поменять аранжировку (когда выбранная аранжировка плохо поддерживает текст). Делайте тексты как можно раньше.

С IT-продуктами аналогично - нужны фишечки, нужны эмоции и нужны тексты, ибо тексты - это UX. И нужно это как можно раньше, ибо чем раньше найдена проблема, тем дешевле её исправление.

Но есть и отличие - в IT часто нужна поддержка разных языков, в музыке такое обычно не делают, хотя синхронный сурдоперевод встречается на концертах всё чаще и чаще.

Тестирование, багфиксинг / Гоняем программу, находим места для улучшений

До этапа MVP ты думаешь, что всё будет классно, вы опять зажжёте, будете прекрасно восприниматься, всё хорошо и всё такое. Но когда MVP по сути готов, происходит скачок требований, и ты начинаешь докапываться до себя. Здесь не то, и тут не так. Это ужасно, с этим нельзя выходить на сцену, это позор! Тут главное не опускать руки, спокойно остановиться, осмотреться и понять, что конкретно нужно доработать.

Product Walkthrough / Прогоны, сценические образы

На этом этапе мы уже начинаем прогонять программу целиком, включая слова между номерами, думая над движениями и расстановкой на сцене, прикидывая образы. Очень помогает запись прогона и прослушивание - где провисы, где скучно, где неуверенно, где непонятно, где переход излишне резок или излишне плавен. Включается режим максимального докапывания (я бы даже написал слово пожёстче, но РКН не дремлет).

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

Как не вспомнить анекдот:

Ветеринар на на приёме у Терапевта:

Терапевт: На что жалуетесь?

Ветеринар: Не, ну так-то каждый может!

Бета / Последние штрихи, препродакшн

В теории продуктового менеджмента где-то здесь нужно привлечь фокус-группу, но мы такой радости лишены, ибо наше выступление должно быть сюрпризом, и все детали держатся в тайне. Так что в нашем HADI-цикле буква D означает данные только изнутри системы, без участия целевой аудитории. Однако к помощи эксперта-критика мы обращаемся - у нас есть специальный человек, который подключается как раз на этапе тестирования. Это наш слайд-жокей.

Про HADI-цикл: Кейс: как ускорить развитие проекта

За какое-то время до дедлайна появляются слайды, которые будут идти фоном на выступлении, может быть делается фотосессия, плакаты, баннеры, начинается подогрев интереса, тизеры, спойлеры и всё такое. На самом вечере также необходим разогрев (поверьте нам, мы пробовали без разогрева, это совершенно, абсолютно не то - вспомните трёхактную схему, про которую я говорил выше).

Релиз (раскатка) / Выступление

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

Работа с аутсорсерами / Саундчек

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

О да, это всё должно быть в WBS, о котором я говорил в начале статьи.

Очень важно, нет, не так ОЧЕНЬ ВАЖНО провести нормальный саундчек. Нормальный - это значит прогнать программу несколько раз. В нашем случае программа обычно полчаса, значит, на саундчек нужно три часа. Это не считая монтажа оборудования, который может занимать часа два (иногда и больше).

Это типичная работа с аутсорсерами, со всеми плюсами и минусами. Кто из продуктовых команд и имел такой опыт, вероятно, сейчас смахнули скупую слезу. Да, это может быть сложным и, что самое неприятное, это может быть провальным.

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

Чеклисты

Что позволяет нормально работать с аутсорсерами? Прежде всего это грамотное ТЗ, которое составляется за несколько итераций и является опытом, сыном ошибок трудных. Также хорошей идеей является провести дополнительный саундчек на базе у звукорежа, чтобы он не на бумаге все моменты узнал, а по факту, и заранее.

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

Про ТЗ: Стандарты и шаблоны для ТЗ на разработку ПО

Ретроспектива

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

Обычная такая ретроспектива - что было хорошо и что мы будем продолжать делать; что можно улучшить и каким образом.

Обратная связь (ищем Market Product Fit)

Нередко на аудиторию запускается анонимный опросник. Мы пробовали разные форматы - NPS, market product fit, и так далее, я полагаю, тут всё очень индивидуально. Также мы слушаем, что говорят люди, какие фотки и видео они выкладывают в инстаграм, какие видео на нашем канале набирают больше просмотров, ну в общем после релиза происходит этап валидации успеха и анализ произошедшего. Результаты этого анализа используются при подготовке следующего концерта.

Про market product fit: Market Fit или как найти точку G у стартапа

Growth hacking / Щупаем аудиторию быстро

Я выше говорил, что в нашем цикле HADI нет внешних данных. Как вы сейчас поняли, это немного не так ;) Правильнее говорить, что у нас просто длинный цикл - для проверки гипотезы нам нужен релиз. Многие продакты сейчас, возможно, ударят себя ладонью по лбу, но это та реальность, в которой мы работаем.

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

А на самом деле мы ведь больше для себя это делаем, а не для аудитории. Просто так уж сложилось, что нам с нашей аудиторией по пути. Всем бы продуктам так, да? ;)

Заключение / Почему вам тоже стоит заниматься музыкой

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

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

Так вот, я таки понял, чтобы что.

Средство против выгорания

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

На Хабре про выгорание пишут много, но я бы выделил вот эту статью: Профессиональное выгорание айтишников: 15 ответов психиатра Максима Малявина

Как не выгорать? Это просто (картинка с Тони Роббинсом):

1. заниматься интересным ненаскучивающим делом

2. регулярно в этом деле побеждать (получать подкрепление)

3. работать с удовольствием

Так как крайне сложно найти одно занятие, в котором всё это будет соблюдаться, то очевидный трюк - найти несколько занятий и заниматься ими по очереди. Обязательно нужно, чтобы одно из этих занятий имело проектный характер, и чтобы достижение побед (то есть успешное завершение проекта) было не очень долгим.

Музыка - это хороший вариант такого занятия. То есть музыка - это средство против выгорания. А у айтишников в музыке есть преимущество - мы умеем в процессы, у нас есть дисциплина.

Занимайтесь музыкой, выступайте. Не обязательно выступать на площадках - ютуб также отличное место.

Бонусы

• Как все начиналось? История становления музыкальной группы Sun-Techniki

• Наш ютуб-канал. Подписывайтесь, ставьте лайки и всё такое :) Может быть когда-нибудь встретимся на каком-нибудь музыкальном фестивале.

В первой части Разработка стековой виртуальной машины и компилятора под неё (часть I) сделал свою элементарную стековую виртуальную машину, которая умеет работать со стеком, делать арифметику с целыми числами со знаком, условные переходы и вызовы функций с возвратом. Но так как целью было создать не только виртуальную машину, но и компилятор C подобного языка, пришло время сделать первые шаги в сторону компиляции. Опыта никакого. Буду действовать по разумению.

Одним из первых этапов компиляции является синтаксический анализ (parsing) исходного кода нашего "C подобного языка" (кстати, надо какое-то название дать как только он станет более формальным). Задача простая - "нарубить" массив символов (исходный код) на список классифицированных токенов, чтобы последующий разбор и компиляция не вызывали сложности.

Итак, первый шаг - определиться с типами токенов (интуитивно будем ориентироваться на синтаксис C), символами которые будут отделять токены друг от друга, а также определить структуру для хранения токена (тип, текст токена, длина, строка и столбец в исходном коде).

constexpr char* BLANKS = "\x20\n\t";constexpr char* DELIMETERS = ",;{}[]()=><+-*/&|~^!.";enum class TokenType {NONE = 0, UNKNOWN, IDENTIFIER,CONST_CHAR, CONST_INTEGER, CONST_REAL, CONST_STRING,COMMA, MEMBER_ACCESS, EOS, OP_BRACES, CL_BRACES, OP_BRACKETS, CL_BRACKETS, OP_PARENTHESES, CL_PARENTHESES,BYTE, SHORT, INT, LONG, CHAR, FLOAT, DOUBLE, STRING, IF, ELSE, WHILE, RETURN,ASSIGN, EQUAL, NOT_EQUAL, GREATER, GR_EQUAL, LESS, LS_EQUAL,PLUS, MINUS, MULTIPLY, DIVIDE, AND, OR, XOR, NOT, SHL, SHR,LOGIC_AND, LOGIC_OR, LOGIC_NOT};typedef struct {TokenType type;          char* text;              WORD length;             WORD row;                WORD col;                } Token;

Далее напишем класс для разбора, ключевым методом которого станет parseToTokens(char*). Тут алгоритм простой: идем до разделителя (BLANKS и DELIMETERS), определяем начало и конец токена, классифицируем его и добавляем в вектор (список) токенов. Особые случаи разбора - это отличать целые числа от вещественных, вещественные числа (например, "315.0") отличать от применения оператора доступа к членам структуры/объекта ("obj10.field1"), а также отличать ключевые слова от других идентификаторов.

void VMParser::parseToTokens(const char* sourceCode) {TokenType isNumber = TokenType::UNKNOWN;bool insideString = false;                                         // inside string flagbool isReal = false;                                               // is real number flagsize_t length;                                                     // token length variablechar nextChar;                                                     // next char variablebool blank, delimeter;                                             // blank & delimeter char flagstokens->clear();                                                   // clear tokens vectorrowCounter = 1;                                                    // reset current row counterrowPointer = (char*)sourceCode;                                    // set current row pointer to beginningchar* cursor = (char*)sourceCode;                                  // set cursor to source beginning char* start = cursor;                                              // start new token from cursorchar value = *cursor;                                              // read first char from cursorwhile (value != NULL) {                                            // while not end of stringblank = isBlank(value);                                          // is blank char found?delimeter = isDelimeter(value);                                  // is delimeter found?length = cursor - start;                                         // measure token length    // Diffirentiate real numbers from member access operator '.'isNumber = identifyNumber(start, length - 1);                    // Try to get integer part of real numberisReal = (value=='.' && isNumber==TokenType::CONST_INTEGER);     // Is current token is real numberif ((blank || delimeter) && !insideString && !isReal) {          // if there is token separator                   if (length > 0) pushToken(start, length);                      // if length > 0 push token to vectorif (value == '\n') {                                           // if '\n' found rowCounter++;                                                // increment row counterrowPointer = cursor + 1;                                     // set row beginning pointer}nextChar = *(cursor + 1);                                      // get next char after cursorif (!blank && isDelimeter(nextChar)) {                         // if next char is also delimeterif (pushToken(cursor, 2) == TokenType::UNKNOWN)              // try to push double char delimeter tokenpushToken(cursor, 1);                                      // if not pushed - its single char delimeterelse cursor++;                                               // if double delimeter, increment cursor} else pushToken(cursor, 1);                                   // else push single char delimeterstart = cursor + 1;                                            // calculate next token start pointer}else if (value == '"') insideString = !insideString;             // if '"' char - flip insideString flag else if (insideString && value == '\n') {                        // if '\n' found inside string// TODO warn about parsing error}cursor++;                                                        // increment cursor pointervalue = *cursor;                                                 // read next char}length = cursor - start;                                           // if there is a last tokenif (length > 0) pushToken(start, length);                          // push last token to vector}

Наряду с методом parseToTokens, помогать в разборе и классификации нам будут простые методы, определяющие разделители и тип найденного токена. Плюс метод добавления токена в вектор.

class VMParser {public:VMParser();~VMParser();void parseToTokens(const char* sourceCode);Token getToken(size_t index);size_t getTokenCount();  private:vector<Token>* tokens;WORD rowCounter;char* rowPointer;  bool isBlank(char value);bool isDelimeter(char value);TokenType pushToken(char* text, size_t length);TokenType getTokenType(char* text, size_t length);TokenType identifyNumber(char* text, size_t length);TokenType identifyKeyword(char* text, size_t length);};

Попробуем используя класс VMParser разобрать строку исходного кода C подобного языка (исходный код бессмысленный, просто набор случайных токенов для проверки разбора):

int main(){    printf ("Wow!");    float a = 365.0 * 10 - 10.0 / 2 + 3;while (1 != 2) {    abc.v1 = 'x';}if (a >= b) return a && b; else a || b; };

В итоге получаем в консоли следующий перечень классифицированных токенов:

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

Для простоты сначала реализуем компилятор арифметических выражений с целыми числами (приоритет "*" и "/" над "+" и "-" учитывается), без скобок, унарных операций и других важных вещей, в том числе проверки синтаксических ошибок. Разбор выражений напишем вот так:

void VMCompiler::parseExpression(size_t startIndex, VMImage* destImage) {Token tkn;currentToken = startIndex;parseTerm(destImage);tkn = parser->getToken(currentToken);while (tkn.type==TokenType::PLUS || tkn.type==TokenType::MINUS) {  currentToken++;  parseTerm(destImage);  if (tkn.type==TokenType::PLUS) destImage->emit(OP_ADD); else destImage->emit(OP_SUB);  tkn = parser->getToken(currentToken);}}void VMCompiler::parseTerm(VMImage* destImage) {Token tkn;parseFactor(destImage);currentToken++;tkn = parser->getToken(currentToken);while (tkn.type == TokenType::MULTIPLY || tkn.type == TokenType::DIVIDE) {  currentToken++;  parseFactor(destImage);  if (tkn.type == TokenType::MULTIPLY) destImage->emit(OP_MUL); else destImage->emit(OP_DIV);  currentToken++;  tkn = parser->getToken(currentToken);}}void VMCompiler::parseFactor(VMImage* destImage) {Token tkn = parser->getToken(currentToken);char buffer[32];strncpy(buffer, tkn.text, tkn.length);buffer[tkn.length] = 0;destImage->emit(OP_CONST, atoi(buffer));}

Попробуем скормить этому компилятору выражение "3+5*6+2*3+15/5", запускаем компилятор с выводом скомпилированных команд и сразу запускаем виртуальную машину. Ожидаем, что результат вычисления должен остаться на вершине стека - 42.

Ура! Получилось! Первые шаги в сторону компилятора сделаны.

По ходу разработки генератора кода для виртуальной машины понял, что виртуальная машина не готова к полноценным вызовам функций, с передачей аргументов и хранением локальных переменных функций. Поэтому её необходимо доработать. А именно, нужно определиться с Соглашением о вызовах (calling convention). Есть много разных вариантов, но конечный выбор за разработчиком. Главное - это обеспечить целостность стека, после вызова.

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

На сегодняшний день, наиболее знакомые мне Соглашения о вызове (calling convention), регулирующее правила передачи аргументов функции, очистки стека после вызова, а также логика хранения локальных переменных - это C declaration (cdecl, x86/64) и pascal. Попробую применить эти знания с небольшими модификациями, а именно без прямого доступа программы к регистрам виртуальной машины (она же всё таки стековая, а не регистровая). Итак, логика будет следующая:

Поясню что происходит. Функция main() вызывает функцию sum() и передаёт ей два аргумента - значение переменной i и константное число 10. Осуществляется передача аргументов путём добавления значений аргументов в стек слева направо (как в pascal). После чего осуществляется вызов функции инструкцией виртуальной машины call, которой указывается адрес вызова и количество передаваемых через стек аргументов - 2.

Дальше команда call должна сделать следующие вещи:
1) сохранить в стек адрес возврата после вызова IP (Instruction Pointer + 1)
2) сохранить в стек значение Frame Pointer (регистр виртуальной машины, которым мы показываем до куда очищать стек после вызова).
3) сохраняем в стек значение Locals Pointer (регистр указывающий на место в стеке где начинаются локальные переменные вызывающей функции).
4) выставить значение Frame Pointer на первый аргумент в стеке, чтобы мы знали докуда очищать стек после завершения выполнения функции.
5) выставить значение Locals Pointer на адрес в стеке сразу после сохранных значение IP, FP, LP.

В свою очередь команда ret должна выполнить действия в обратном порядке:
1) Восстановить из стека предыдущие значения IP, FP, LP.
2) Взять результат выполнения функции с вершины стека.
3) Выставить SP = FP (очистить стек в состояние до вызова).
4) Положить на вершину стека результат выполнения функции.

Так как делаем стековую, а не регистровую виртуальную машину, не хочу давать прямой доступ к регистрам, поэтому доработаем инструкцию CALL / RET, а также добавим четыре дополнительные инструкции LOAD (положить в стек значение локальной переменной с указанным индексом), STORE (взять верхнее значение в стеке и сохранить в локальной переменной с указанным индексом), ARG (добавить в стек значение аргумента функции с указанным индексом), а также DROP - инструкция выбросить из стека верхнее значение. Последняя инструкция DROP нужна для функций значение которых нам не нужно, так как мы не даём прямой доступ к регистрам.

case OP_CALL:a = memory[ip++];      // get call address and increment addressb = memory[ip++];      // get arguments count (argc)b = sp + b;            // calculate new frame pointermemory[--sp] = ip;     // push return address to the stackmemory[--sp] = fp;     // push old Frame pointer to stackmemory[--sp] = lp;     // push old Local variables pointer to stackfp = b;                // set Frame pointer to arguments pointerlp = sp - 1;           // set Local variables pointer after top of a stackip = a;                // jump to call addressbreak;case OP_RET:a = memory[sp++];      // read function return value on top of a stackb = lp;                // save Local variables pointersp = fp;               // set stack pointer to Frame pointer (drop locals)lp = memory[b + 1];    // restore old Local variables pointerfp = memory[b + 2];    // restore old Frame pointerip = memory[b + 3];    // set IP to return addressmemory[--sp] = a;      // save return value on top of a stackbreak;case OP_LOAD:a = memory[ip++];         // read local variable indexb = lp - a;               // calculate local variable addressmemory[--sp] = memory[b]; // push local variable to stackbreak;case OP_STORE:a = memory[ip++];         // read local variable indexb = lp - a;               // calculate local variable addressmemory[b] = memory[sp++]; // pop top of stack to local variablebreak;case OP_ARG:a = memory[ip++];         // read parameter indexb = fp - a - 1;           // calculate parameter addressmemory[--sp] = memory[b]; // push parameter to stackbreak;case OP_DROP:                   // pop and drop value from stacksp++;break;

Скомпилируем код представленный на иллюстрации выше чтобы протестировать как работают новые инструкции CALL, RET, LOAD, STORE, ARG (примечание: syscall 0x21 - это распечатка числа с вершины стека в консоль):

Запустим исполнение этого кода с распечаткой состояния виртуальной машины после выполнения каждой инструкции:

[   0]    iconst  5     IP=2 FP=65535 LP=65534 SP=65534 STACK=[5] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[5,5] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[5,4] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[5,4,4] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[4,4,4] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[4,4,4,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[4,4,4,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[4,4,4,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,4] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[4,4,4,10,14,65535,65534,10,4,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,14] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[4,4,4,10,14,65535,65534,10,14,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,4] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[4,4,4] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[4,4,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[4] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[4,3] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[4,3,3] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[3,3,3] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[3,3,3,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[3,3,3,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[3,3,3,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,3] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[3,3,3,10,14,65535,65534,10,3,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,13] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[3,3,3,10,14,65535,65534,10,13,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,3] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[3,3,3] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[3,3,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[3] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[3,2] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[3,2,2] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[2,2,2] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[2,2,2,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[2,2,2,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[2,2,2,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,2] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[2,2,2,10,14,65535,65534,10,2,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,12] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[2,2,2,10,14,65535,65534,10,12,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,2] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[2,2,2] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[2,2,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[2] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[2,1] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[2,1,1] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[1,1,1] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[1,1,1,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[1,1,1,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[1,1,1,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,1] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[1,1,1,10,14,65535,65534,10,1,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,11] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[1,1,1,10,14,65535,65534,10,11,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,1] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[1,1,1] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[1,1,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[1] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[1,0] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[1,0,0] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[0,0] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[0,0,0,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[0,0,0,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[0,0,0,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,0] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[0,0,0,10,14,65535,65534,10,0,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,10] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[0,0,0,10,14,65535,65534,10,10,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,0] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[0,0] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[  18]    icmpjg  [2]   IP=20 FP=65535 LP=65534 SP=65534 STACK=[0] -> TOP[  20]    ---- halt ----IP=21 FP=65535 LP=65534 SP=65534 STACK=[0] -> TOPEXECUTION TIME: 0.620997s

В консоли данная программа выдает следующее

Эти числа в консоли говорят, что вызовы функций, передача аргументов, аллокация локальных переменных, возврат значения и восстановление стека после вызова работают нормально. Значит можно полностью переходить и фокусироваться на разработке компилятора для этой виртуальной машины (AST и генерацию кода). Теперь в виртуальной машине есть всё необходимое.

Ура! Это вдохновляет!