Лаборатория сборки

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

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

Продолжаем тему миграции данных. Если простым языком, это про (полу)автоматическую поддержку предыдущих (в т.ч. промежуточных) версий форматов и протоколов. Зачем это и почему именно для нашего дата-подхода это крайне важно, писал в предыдущем посте. Вообще, я считаю, что абсолютно все разработчики долгоживущих проектов сталкиваются с этой задачей и решают как правило на месте, типа "открыть как Word 97". Ну а мы имеем дерзновение решить вопрос основательно, системно и чтоб работало во всех наших проектах без специальных танцев. В этом видео Дмитрий рассказывает получившуюся архитектуру, которая учитывает и версионность вложенных структов, и работу в разных ветках git-репозитория, и удаление ненужных версий. Ждём реализации.

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

Дуэль на рельсах 1х1 потными ладошками

Git-сервер Часть 2 - Изоляция и первый контакт

Ееее! Серёга подключил камеру! Прогресс, что называется, на лицо. В этом выпуске, продолжающим серию роликов по этой теме (1 выпуск, 2 выпуск), разберём на схемах подключение и покрутим настройки камеры.

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

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

Обнаружил, что картина импульсных откликов фильтров Субтрактора выглядит на разных устройствах по разному, при том что тестирую в одном и том же помещении. Не всегда удается прочитать на графике ярко выраженный пик. Потребовалось вывести дополнительные debug-метрики, чтобы разобраться в чем причина.

Инфраструктурный подкаст: "Суверенный Git-сервер" Часть 1 - Настройка системы и организация доступа

Нарушать правила — это прикольно! Когда можно сделать что-то непредусмотренное, это пробуждает внутреннего ребёнка. И это не только и не столько просто про "пошалить". Мозг награждает нас за отход от мейнстримных трасс дофаминовым ощущением первооткрывателя. Каждый здоровый программист испытывал это, когда сделал какой-то участок по-своему, и оно заработало! Или когда обошёл какие-то ограничения фреймворка, или когда разобрал/взломал/переделал чужое решение. Я часто повторяю, что конкуренция — это про отличие. Если ты делаешь как все, то и результат у тебя, как у всех (и денег, кстати, тоже). Поэтому у нас нет жёстких ТЗ, постановки задач по SMART и вся архитектура заточена под быстрые изменения. Именно для того, чтобы мы могли легко импровизировать, быть по-настоящему гибкими нетакусиками. В видео пример такого баловства, из-за которого вероятно у нас появится режим роглайт-прокачки танка в рамках одной битвы. Кстати, если бы мы делали f2p — мы были бы скованы необходимостью учитывать баланс, чтоб заставлять юзеров донатить, не давать им убер-комбинаций и прочее. Когда финансовый вопрос отцеплен от фана — можно делать что угодно, что может быть прикольным для игроков, вообще не оглядываться на метрики. Свобода — это делать по душе, а не по методичкам и кейпиай.

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

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

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

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

Естественно вытекающая из темы сериализации тема миграции данных. Живые системы не статичны, они меняются. Найти сегодня ПО и тем более онлайн-сервисы, которые не меняются — надо постараться. Мы в своём подходе изначально закладывали (и кажется что в 2020+ по-другому нельзя) что наш софт будет меняться и меняться часто (даже по нескольку раз в день). Причём как клиентская, так и серверная сторона. И желательно без простоев, на горячую. И ладно если изменение косметическое (кнопку там передвинуть или анимацию заменить) — самая жесть начинается при изменении структур данных, протоколов их передачи и хранения. Надо обеспечить их безопасный перенос в новый формат, обеспечить обратную совместимость или/и поддержку старых протоколов, пока всё (и все) не обновилось. Это кстати частая причина замедления развития проектов, т.к. делать конвертацию уже большого объёма накопленных данных (например, переписка или игровая статистика миллионов пользователей) — это либо полный останов сервиса на часы, либо делать это прямо наживую, начиная с "горячих" данных и постепенно перенося архивное. Зачастую это делают в несколько этапов, подготавливая сначала данные и уже потом накатывая новую логику. Короче, это требует серьёзной подготовки и очень ответственного подхода (поэтому хорошие девопсы ценятся даже во времена победившего нейрокодинга) — одно неловкое движение, данные ломаются, сервис встаёт, и даже восстановление из резерва может оказаться тем ещё челленджем (кстати, поучительная история на эту тему у моего коллеги Алексея Андросова в его недавно родившемся канале). Поэтому лишний раз стараются ничего не менять в уже работающей системе, а только добавлять, и то, осторожно. Это примерно как не выкидывать старые вещи из дома — за несколько лет проект и его данные превращаются в свалку всякого устаревшего вперемешку с новым (иногда дублирующимся). И с каждым разом поддерживать такое становится всё сложнее и сложнее. Релизы готовятся дольше, фиксы откладываются, нервозность повышается, а удовольствие от разработки падает. Это кстати не учитывают многие начинающие стартаперы-саасники (которых сегодня снова расплодилось на вайбкод-волне), они наивно экстраполируют лёгкость "начинания" на годы вперёд. В том числе по этой причине подавляющее большинство их не выживет. Мы пацаны битые, поэтому готовимся к саппорту не когда уже пора масштабироваться, а ещё на этапе закладывания фундамента. У нас в основе архитектуры — данные, а не команды (события, колбэки и пр.). Мы сразу закладываем то, что структуры данных будут постоянно меняться и хотим, чтобы этот процесс был максимально лёгким и дешёвым (бесплатно никак не получится, но хотя бы так). Поэтому у нас есть версионирование (слепки структур) и по возможности автоматическая конвертация из старых версий в новые (собственно, миграция). Это позволит обеспечить обратную совместимость и постепенное обновление данных при хранении на серверах, передачи (протокол обмена — это тоже сериализованные данные). И в том числе хот-релоад: - сохраняем состояние в сериализованный файл (сохранёнку) - закрываем программу - обновляем и запускаем - считываем старую сохранёнку - мигрируем данные в новые структуры - работаем дальше В видео Дима наглядно объясняет базу механизма миграции. Может в будущих видео расскажет и детали, как мы это всё делаем.

Всем привет! Продолжаю разбираться с аппаратным видео декодированием. Для macOS все получилось довольно быстро и просто через Video Toolbox. В текущий момент разбираюсь с MediaCodec на Android. Всю неделю разбирвался и пытался скормить MediaCodec правильные данные. Он очень капризный в этом плане. В итоге с декодированием разобрался. И получая HardwareBuffer надо было создать VkImage для vulkan. Там еще более тернистый путь с конверсией и тд. В итоге я получал черный экран. Никаких ошибок не было. Сегодня нашел причину! Не верно указал формат получаемого изображения. Как его точно определить - это еще мне предстоит. Продолжаем )

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

В основе нашей архитектуры — данные (потому и дата-подход). А данные нужно уметь сериализовывать (грубо говоря сохранять в какой-то однозначный формат, из которого мы сможем их прочитать в том же виде). Применений много: - Передача данных между серверами и клиентами - Хранение данных на диске (и на клиентах, и на серверах - мы не используем БД общего назначения) - Хот-релоад и накатывание апдейтов (сохраняем состояние, обновляемся, загружаем) Благодаря тому, что мы всё пишем на Rust, у нас получается компактный однозначный формат/протокол взаимодействия разных частей системы и он описан явным образом прямо в коде. Чётко, быстро, удобно, бережно. Мне, честно говоря, зубы сводит, когда я вижу это повальное перебрасывание JSON по REST — эти бы тераватт-часы/петафлопсы да в мирное русло. Ну да нас никто не заставляет, и то хорошо. В видео Дима наглядно объясняет Степану про сериализацию. Контент одобрен для просмотра даже детям и беременным женщинам (которых внезапно заинтересовала эта тема).