Open to work · Middle/Senior Go · Москва / гибрид / удалёнка · от 140 тыс. ₽

Полх Тимофей Александрович

Middle → Senior Go Developer / Backend Engineer · Tech Lead (de facto)

Москва, Россия tupotim12q@gmail.com +7 (921) 261-29-52 @titrom101 github.com/titrom

Скачать PDF · краткая версия

~2 года

коммерческий опыт

~44k LOC

flagship anti-drone

16 пакетов

hexagonal monolith

7 race-багов

устранено в velocity

Tech Lead

де-факто

О себе

Go-разработчик с ~2 годами коммерческого опыта проектирования real-time распределённых систем: обработка радарных данных, PTZ-управление камерами по протоколу Pelco-D, интеграция ML-сервисов, hardware-in-the-loop тестирование.

Начинал стажёром computer-vision инженером, за полгода под задачи проекта переквалифицировался в Go-разработчика и вошёл в штат как младший. За 2 года органически вырос до фактической роли тех-лида: принимаю архитектурные решения, выбираю технологический стек, координирую frontend-команду, составляю сайзинги инфраструктуры, веду пользовательскую и техническую документацию, выступаю техническим экспертом на встречах с заказчиком.

Сильные компетенции в concurrency (goroutines, channels, sync primitives), event-loop архитектуре, hexagonal / ports-and-adapters, полной observability (Prometheus, pprof, slog), Docker и CI/CD.

Карьерный путь

CV Engineer Intern

Старт в Softline. Задачи computer vision для будущего anti-drone продукта.

Junior Go Developer

Переквалификация CV → Go под нужды проекта, зачисление в штат.

Tech Lead (de facto)

Архитектура, стек, frontend-координация, сайзинги, защита решений у заказчика.

Softline · 2024 — настоящее время

Первое место коммерческой разработки. Пришёл стажёром computer-vision инженером — работал над задачами CV для будущего anti-drone продукта. Через ~6 месяцев под нужды центрального проекта переквалифицировался в Go-разработчика и был зачислен в штат как младший Go-разработчик.

За 2 года вырос до фактической роли тех-лида на флагманском anti-drone проекте: с самого начала отвечал за архитектурные решения, выбор стека, координацию с frontend-командой, подготовку сайзингов инфраструктуры и выступал техническим экспертом на встречах с заказчиком.

Тех-лид ответственность

Архитектурные решения и выбор технологического стека

Определяю паттерны (Ports & Adapters, event-loop, state-machine), обосновываю выбор языка, фреймворков, хранилищ и протоколов под требования проекта.

Составление архитектурных документов

Описываю компоненты, интерфейсы, data-flow, контракты между подсистемами.

Координация frontend-команды

Формирую REST / WebSocket контракты, провожу ревью предложений, синхронизирую frontend-roadmap с backend-разработкой.

Сайзинг инфраструктуры

Расчёт CPU, RAM, network, disk, GPU для ML-компоненты под развёртывание на объектах заказчика.

Пользовательская и техническая документация

Инструкции для конечных пользователей системы на объектах, API-доки, runbook'и для операторов.

Технический point-of-contact на встречах с заказчиком

Презентую архитектурные решения, защищаю технические выборы, собираю требования, отвечаю на вопросы по реализации.

Проекты в рамках Softline

Anti-Drone General Service · flagship

Go 1.25+ Python WebSocket CBOR ONNX Runtime Docker Prometheus ThingsBoard

2024 — настоящее время · ~44 000 LOC · 137 Go-файлов · 16 пакетов

Real-time распределённая система детектирования, сопровождения и автономного подавления БПЛА. Центральный координационный узел: приём радарных данных, управление PTZ-камерами, оркестрация джаммеров, интеграция с ML-сервисом классификации и IoT-платформой ThingsBoard.

Спроектировал и реализовал модульный монолит по паттерну Ports & Adapters (hexagonal): ~44 000 LOC, 137 Go-файлов, 43 test-файла, 16 внутренних пакетов — autoaim, tracking, storage, ml, ws, diagnostics, kalman, corridor, camerapolygons, platform и др.
Реализовал event-loop обработки радарных треков с sub-millisecond latency через in-memory thread-safe stores (sync.RWMutex, sync.Map, atomic).
Разработал алгоритм назначения треков на башни на основе scoring-функции (distance / availability / threat), и state-machine jamming-последовательностей с anti-deadlock защитой через rebalance history + cooldown.
Интегрировал ONNX ML-микросервис (Python / FastAPI / CUDA) для классификации bird vs UAV по доплеровским спектрам — async очередь, rate-limiting, frame-skip при перегрузке.
Реализовал WebSocket-клиент радарного фида (JSON / CBOR через fxamacker/cbor), с auto-reconnect, экспоненциальным backoff и watchdog на liveness main loop.
Разработал алгоритм Smooth Aim: грубое наведение камеры по LLA-координатам цели + точная корректировка по CV bounding box через P-controller в velocity-режиме.
Построил интеграцию с ThingsBoard IoT: JWT с auto-refresh на 401-й ответ, debounce телеметрии (100–500 мс), батчинг, alarms.
Настроил полный observability-стек: Prometheus metrics, pprof endpoints (CPU / heap / goroutine / mutex / block), структурированное slog-логирование, custom speed / angle / data-loggers.
CI/CD: race-тесты, gosec / staticcheck SAST, 2-часовые stress-прогоны, multi-stage Docker (~15 МБ).
Реализовал 3D Kalman-фильтрацию траекторий, point-in-polygon geo-fencing, camera FOV polygons для расчёта покрытия.
Спроектировал и реализовал встроенный веб-dashboard (internal/dashboard, отдельный HTTP-порт, embed-статика): real-time просмотр активных треков, состояния джаммеров и режимов работы, история ошибок из error_log.json, агрегированная статистика драйверов (driver_stats_logger), лог переключений режимов (mode_logger) — операторам не нужен отдельный Grafana/Kibana для повседневной диагностики.
Выстроил систематический сбор данных для улучшения алгоритмов: на ключевых decision-points (tracking, autoaim, jammer-assignment, ML-classification) пишу структурированные события с correlation-ID, решающими признаками и выбранной ветвью. Собранные логи прогоняются офлайн → находим пограничные случаи → правим пороги / scoring / Kalman-параметры. Каждый инцидент с объекта превращается в датасет, по которому регрессионно проверяется фикс.

Sub-millisecond латентность на радарных событиях

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

Решение: полностью in-memory event-loop с thread-safe stores на sync.RWMutex / sync.Map / atomic; никакого I/O в горячем пути (БД, сеть, диск); вычисления разнесены по воркерам с неблокирующими каналами; profiling через pprof для поиска контеншна на локах.

Deadlock в state-machine jamming-последовательностей

Состояние джаммеров переключается по событиям (цель обнаружена, потеряна, пришла команда). При конкурирующих событиях system мог зацикливаться в rebalance: джаммер A отдаёт цель джаммеру B, B возвращает A, и так бесконечно.

Решение: anti-deadlock защита через rebalance history (не перекидывать цель туда, откуда она только что пришла) + cooldown на повторные переназначения. State-машина стала детерминированной, повторяющиеся переходы исключены.

Конфликт Smooth Aim (LLA) с velocity-режимом (bbox)

Smooth Aim наводит камеру по GPS-координатам цели (PointToGeo), а корректировка по CV bbox — в velocity-режиме через P-controller. Обе подсистемы параллельно шлют команды в PTZ-драйвер: velocity Move перебивается устаревшим PointToGeo, камера уходит в GPS-target и теряет bbox-захват. Тесты давали всего 1/5 пасс.

Решение: ввёл проверку freshness bbox на стороне anti-drone (в executeSmoothAimStep и startPointCommandWorker): если bbox пришёл <100 мс назад, PointToGeo-команды подавляются. Независимо от флага BBoxAimEnabled — убрал его из условия, потому что по умолчанию он был false и не включался. После фикса: стабильно 5/5 test pass.

Watchdog main-loop liveness

В редких сценариях main loop радарного фида мог зависнуть на блокирующем вызове (например, при split-brain состоянии сети) — процесс продолжал работать, но треки переставали обрабатываться. Визуально сложно отличить от «нет целей».

Решение: watchdog-горутина проверяет timestamp последней итерации main loop каждые N секунд; если gap превышает threshold — логирует критическую ошибку, инкрементирует Prometheus метрику, триггерит alarm в ThingsBoard. Независимый reconnect на WebSocket фид с экспоненциальным backoff.

Перегрузка ML-сервиса классификации

ONNX ensemble inference на GPU всё ещё занимает десятки мс на образец. При всплесках (много целей в FOV одновременно) очередь на классификацию росла, latency end-to-end уходила в секунды.

Решение: async очередь с rate-limiting перед ML-сервисом; при загрузке очереди >80% включается frame-skip (берём только каждую N-ю выборку); low-confidence обновления дропаются; метрики queue depth и drop rate выведены в Prometheus.

ThingsBoard JWT истекает в середине сессии

ThingsBoard IoT отдаёт JWT с ограниченным TTL. На длительных прогонах телеметрия внезапно переставала уходить — сервер возвращал 401, клиент молча ошибался.

Решение: собственный middleware-слой поверх HTTP-клиента: перехватывает 401, автоматически рефрешит JWT через refresh-endpoint, повторяет исходный запрос. Телеметрия дополнительно debouncится (100–500 мс) и батчится, чтобы не долбить ThingsBoard на каждое обновление.

PTZ Camera Driver (Pelco-D)

Go Gin TCP Pelco-D Docker

2024 — настоящее время · 60+ REST endpoints · собственный HIL-симулятор

Production-grade драйвер PTZ-камер по протоколу Pelco-D с REST API и собственным hardware-in-the-loop физическим симулятором. Используется anti-drone сервисом для наведения камер на цели в реальном времени.

Реализовал priority command queue на sync.Mutex / sync.Cond с дедупликацией CommandPosition / Zoom / Focus и configurable worker pool.
Разработал waiter-pattern TCP dispatcher — регистрация response-handlers до отправки команды предотвращает hijack ответов в concurrent-сценариях.
Написал парсер и энкодер Pelco-D бинарного протокола (7-байт стандарт + 15-байт extended), 60+ REST endpoints на Gin.
Реализовал P / PD-controller для velocity-режима (kP=200, deadzone=0.02, maxSpeed=63) + auto-stop через 300 мс после последнего bbox.
Построил полную WGS-84 геодезическую цепочку: LLA → ECEF → ENU + rotation matrices + tilt correction для sub-degree наведения.
Написал hardware-in-the-loop симулятор камеры (20 Hz физический tick, 113°/s pan, 38°/s tilt, PTZ-protocol-aware), matching real hardware refresh rate.
Реализовал auto-reconnect TCP с backoff, relay-hardware reboot trigger при offline, circuit breaker на угловые обновления.
Docker multi-stage build, graceful shutdown (10 с timeout), async / sync режимы API, Prometheus метрики на все эндпоинты.

Hijack TCP-ответов в concurrent-сценарии

Pelco-D TCP-соединение — один сокет, через который идут команды и приходят ответы от камеры. Если горутина A отправила команду, а горутина B читает сокет, ответ A может попасть к B. Классический response-hijack в асинхронном протоколе без встроенного correlation-id.

Решение: waiter pattern — перед отправкой команды горутина регистрирует свой channel в map (waiters[commandID] → chan Response), затем отправляет команду, затем ждёт свой канал. Отдельный reader-loop читает сокет, парсит ответ, находит нужный waiter по command-id и кладёт ответ в его канал. Никакой гонки, никакого hijack.

Velocity move перебивается устаревшими GPS-target командами

В velocity-режиме anti-drone шлёт десятки Move-команд в секунду (корректировка по bbox). Параллельно сверху могут прилетать PointToGeo (наведение по GPS-координатам цели). Если PointToGeo попадает в очередь после Move — он перебивает активное velocity-движение, камера «дёргается» на GPS-цель и теряет bbox.

Решение: при enqueue CommandMove из очереди удаляются все pending CommandPosition (с nil callback, чтобы не сломать waiter'ы). Velocity-move всегда «выигрывает» у устаревших GPS-target команд в рамках одной очереди.

Race в auto-stop velocity-режима

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

Решение: timer identity check — каждый раз при рестарте таймера увеличивается generation-counter. Когда таймер срабатывает, он сравнивает свой generation с текущим под мьютексом, и только если совпало — отправляет Stop. Все предыдущие таймеры молча умирают.

Снап-бек к GPS-цели после остановки velocity

После auto-stop velocity-движения камера снова начинала ехать к последнему GPS-target — симулятор помнил «HasTarget = true» и тихо продолжал следовать за виртуальной точкой.

Решение: во всех 8 Move-командах (левая, правая, верх, низ + 4 диагонали) и в stopAllMovement() явно выставляется HasTarget = false. Любое velocity-движение отменяет GPS-target режим. Snap-back исчез.

Hardware недоступен для разработки

Реальная PTZ-камера стоит на объекте заказчика. Без доступа к железу невозможно было отлаживать velocity-режим, проверять геодезические преобразования и воспроизводить баги.

Решение: написал hardware-in-the-loop симулятор — отдельный бинарь на том же Pelco-D протоколе, с физическим тиком 20 Hz (совпадает с hardware refresh rate), правильными скоростями (113°/s pan, 38°/s tilt при speedByte=63), аккуратным tilt-encoding (tilt < 0 → PTZ = tilt + 360). Вся разработка и регрессионные тесты велись против симулятора.

Sub-degree наведение по GPS-координатам

Anti-drone даёт цель в WGS-84 (широта, долгота, высота). Камера стоит на отдельной GPS-точке, наклонена на площадке, имеет собственную ориентацию. Нужно перевести координаты цели в azimuth / elevation относительно камеры с точностью до долей градуса.

Решение: реализовал полный геодезический пайплайн LLA → ECEF → ENU (локальная система координат камеры) + rotation matrices по установочной ориентации + tilt correction. Отдельно — нормализация azimuth через модульную арифметику (избегает багов на переходе 359° → 0°).

INK-ML Radar Classification Service

Python 3.10 FastAPI ONNX Runtime CUDA Docker

2024 — настоящее время

Python-микросервис классификации радарных доплеровских спектров (bird vs UAV), вызываемый из Go-сервиса Anti-Drone. Поддерживаю параллельно основному Go-коду — опыт переквалификации из CV-стажёра позволяет закрывать и ML-ops домен.

FastAPI /predict endpoint для классификации доплеровских спектров.
Ensemble inference нескольких ONNX-моделей + TTA (test-time augmentation: noise, shift, scale) для повышения robustness.
Preprocessing pipeline: log-scaling, percentile clipping, dB auto-detection, нормализация.
Runtime config-reload без рестарта сервиса — можно менять веса моделей и параметры препроцессинга на живом продакшене.
CUDA inference с fallback на CPU.
Docker-образ на nvidia/cuda:12.1.1-cudnn8 с GPU passthrough.

Входные спектры в разных форматах

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

Решение: dB auto-detection в препроцессинге — по распределению значений (статистики, диапазон) определяется, в какой шкале пришли данные, и при необходимости применяется log-scaling. Пайплайн стал устойчив к формату источника.

Overfitting одной модели

Одиночная ONNX-модель давала высокую точность на валидации, но при реальных условиях (шум, смещение, изменение масштаба спектра) уверенность падала.

Решение: ensemble из нескольких моделей + TTA: к каждому входу применяется набор аугментаций (noise, shift, scale), предсказания усредняются по ансамблю и по TTA-вариантам. Confidence стала существенно выше и стабильнее.

CUDA недоступна / GPU не справляется

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

Решение: fallback-стратегия на CPU — при инициализации пробуем CUDA, при ошибке переключаемся на CPU-провайдер ONNX Runtime. Сервис продолжает работать с увеличенной latency. Факт fallback'а логируется и уходит в метрики.

Обновление моделей без downtime

Исследовательская команда регулярно выкатывает новые версии моделей. Перезапуск сервиса означал бы потерю классификации на несколько секунд — неприемлемо для real-time системы.

Решение: runtime config-reload — подмена путей к ONNX-файлам и параметров препроцессинга по watch-сигналу на конфиг; старый ансамбль остаётся активным пока новый не прогрет, переключение — атомарно под мьютексом. Downtime = 0.

Hardware Test Stand / Integration Testing

Go WebSocket HTTP bbox-tester

2024 — настоящее время · 4-terminal simulation stack

Стенд для end-to-end тестирования всей радарно-камерной цепочки без реального железа. Критичен для разработки и регрессионной отладки без выезда на объект.

Собрал 4-terminal симуляционный стек: radar_sim → anti-drone → driver → camera_sim.
Реализовал генерацию реалистичных радарных данных в формате Enot (range_step = 3.0 м, speed_step = 0.7484 м/с, CFAR, RCS).
Конфигурируемые источники, треки, тики, GPS-координаты сценариев.
Написал bbox-tester — отдельный тул, который проигрывает фиксированные сценарии через anti-drone /api/bbox и замеряет итоговую ориентацию камеры.
Нашёл и исправил 7 критических багов в velocity-режиме.

Невозможно отлаживать velocity-режим на живом железе

Камера стоит на объекте заказчика. Каждое изменение кода означало бы релиз + поездку + живые замеры. Регрессии ловились только при приёмке.

Решение: собран полноценный симуляционный стек из 4 компонентов, которые общаются по тем же протоколам, что и продакшен (WebSocket для радара, HTTP для anti-drone API, Pelco-D TCP для камеры). Любой velocity-сценарий воспроизводится локально за секунды.

Радарные данные нестабильны и нерепродуцируемы

Запись реальных радарных сессий — дорого и неполно. Нужны были синтетические данные, которые проходят валидацию anti-drone парсера (формат Enot, корректные CFAR, RCS, range и speed steps) и при этом воспроизводимы сценарий в сценарий.

Решение: написал генератор радарных фреймов в формате Enot с правильными физическими константами (range_step = 3.0 м, speed_step = 0.7484 м/с), валидными CFAR-порогами и RCS-значениями. Сценарии описаны в JSON, полностью воспроизводимы.

bbox-tester ловил только 1/5 сценариев

Первоначальный запуск bbox-tester показывал пасс всего 1 из 5 сценариев. Падения были разнородные: где-то snap-back к GPS-цели, где-то «+1.89° tilt» после остановки, где-то Δaz = +309° (обход через весь круг).

Решение: системно диагностировал каждый случай и закрыл 7 корневых причин:

Конфликт smooth-aim PointToGeo с P-controller velocity-moves — убран gate BBoxAimEnabled из bbox-freshness проверки (в executeSmoothAimStep и startPointCommandWorker).
Race в resetVelocityAutoStop — Stop теперь отправляется только при совпадении timer identity под мьютексом.
Snap-back к GPS-target — во все Move-команды и stopAllMovement() добавлен HasTarget = false.
Стале PointToGeo после первого bbox — в Enqueue() при добавлении CommandMove все pending CommandPosition удаляются из очереди.
Дефолты конфига — BBoxTimeout = 40 с по умолчанию, если BBOX_TIMEOUT_SEC не задан.
Pointing manager на радарных апдейтах — pointTowerToNewRadarPointUnsafe тоже проверяет bbox-freshness; подавление PointToGeo не зависит от BBoxAimEnabled.
Azimuth wrap в bbox-tester — normAngle оборачивает дельту в [-180, 180], исправив Δaz = +309° на -51°.

После всех фиксов — стабильно 5/5 test pass на десятках повторных прогонов.

Сценарии ломались при смене разрешения

Первая версия сценариев задавала bbox в пикселях для фиксированного разрешения 1920×1080. При смене камеры (другое разрешение) вся калибровка слетала.

Решение: переписал сценарии на фрактальные координаты [0..1] относительно фрейма. Ширина / высота теперь передаются флагами -width / -height, координаты корректно масштабируются. Один набор сценариев работает на любом разрешении.

Личные проекты

rmouse — кросс-ОС shared mouse/keyboard

Go 1.25+ Wails (GUI) WinAPI hooks X11 / evdev / uinput XTest TLS 1.3

2025 · pet-project · github.com/titrom/rmouse

Go-утилита для объединения нескольких компьютеров в одно рабочее пространство: одна физическая мышь и клавиатура управляют всеми машинами, курсор перетекает с экрана на экран при пересечении границы. Аналог Synergy / Barrier / Mouse Without Borders.

Спроектировал клиент-серверную архитектуру (1 сервер + N клиентов) с опциональным relay-узлом для NAT/CGNAT-сценариев. Транспорт — TLS 1.3 с pre-shared pairing token, relay видит только зашифрованный трафик (end-to-end).
Реализовал платформенные адаптеры захвата/инжекта ввода: на Windows — low-level WinAPI hooks + SendInput; на Linux/X11 — /dev/uinput capture + XTest injection. Кроссплатформенная CLI-сборка, GUI через Wails.
Построил GUI-сервер с drag-and-drop расстановкой клиентов на визуальной сетке вокруг физических мониторов: snap-to-grid с конфигурируемым шагом, ring-search при коллизиях, halo-подсказки валидных позиций, ghost rect при drag'е. Placement персистится в JSON-конфиг, восстанавливается при переподключении.
Реализовал hotplug мониторов хоста (подключение/ отключение/смена разрешения) онлайн без рестарта — сервер пересчитывает bbox, GUI перерисовывает раскладку, клиенты остаются на своих местах. На Linux — X RandR subscribe.
Сделал gap-crossing курсора между мониторами: raycast по push-оси на сервере + teleport-across-gap на server-facing кромке клиента при release — курсор плавно перепрыгивает визуальные зазоры, работает в обе стороны.
Хранение секретов — через OS keyring (Windows Credential Manager / GNOME Keyring / KWallet), self-signed сертификаты с SHA-256 fingerprint, trust-on-first-use.
CI-сборки под Windows/Linux, готовые релизные бинарники на GitHub Releases.

Коллизии при drag-and-drop расстановке клиентов

При перетаскивании клиентского экрана в произвольную точку сетки rounding к grid-шагу мог уронить его внутрь уже занятого монитора (server или другой client). Просто отменять drop — плохой UX: пользователь не понимает, где место есть.

Решение: двухуровневая защита. (1) во время drag'а axis-движение блокируется на кромке любого существующего экрана — курсор физически не затаскивает клиент внутрь. (2) после drop'а findFreeGridSpot делает ring-search по grid'у (до 30 колец) и приземляет в ближайшую свободную ячейку; при полном отсутствии места — откат к позиции начала drag'а. Плюс halo-подсветка валидных позиций во время drag'а, чтобы было видно, куда вообще можно примкнуть.

Залипание модификаторов при grab-переходе

Если пользователь переходил на клиента с зажатым Ctrl/Shift, на сервере hook фиксировал key-down, но key-up уже улетал в клиент (или наоборот) — модификатор «залипал» на одной из сторон, курсор и ввод начинали вести себя неадекватно.

Решение: router явно синхронизирует набор зажатых модификаторов при каждом grab-переходе: на сторону, с которой уходим, дожимает синтетические key-up; на сторону, куда приходим — восстанавливает зажатые key-down. Состояние модификаторов стало свойством router'а, а не платформенного хука.

Gap между мониторами: курсор «туда смог, обратно нет»

В GUI между сервером и клиентом можно оставить визуальный зазор. Курсор корректно перелетал на клиент по push-оси, но вернуться не мог — raycast на сервере отрабатывал, а на клиенте gap-teleport при release не срабатывал, курсор «застревал» на кромке удалённого экрана.

Решение: симметричный gap-cross в обе стороны — на сервере raycast по направлению push'а, на клиенте teleport-across-gap на server-facing кромке в момент release управления. Проверено на диагональных и не-смежных раскладках.

Hotplug мониторов без перезапуска

Подключение/отключение внешнего монитора или смена разрешения в первой версии требовали рестарта сервера — иначе bbox и координаты placement'ов уезжали в никуда, клиенты оказывались в невидимой зоне.

Решение: онлайн-пересчёт bbox при событиях display change (WinAPI WM_DISPLAYCHANGE / X RandR subscribe). GUI перерисовывает раскладку, placement'ы клиентов пересчитываются относительно новой геометрии, клиенты остаются на своих местах. Wayland не поддерживается намеренно — протокол не даёт нужного capture.

Технические навыки

Языки и ядро

Архитектура

Сеть / протоколы

Observability

Инфраструктура

Тестирование

Domain / математика

ML-ops

Образование

МП

Московский политехнический университет

Бакалавриат · Прикладная математика и информатика

2022 — 2026

Тема диплома: «Разработка нейросетевого сервиса для детекции беспилотных летательных аппаратов и птиц с последующей интеграцией в системы защиты наземных объектов, включая транспортные средства».

Дополнительное образование

Samsung IT School — школьные курсы по разработке мобильных приложений (Android).
Android-разработка — самостоятельно в старших классах, до поступления в ВУЗ.
Самообразование — профессиональная литература по Go, concurrency, distributed systems, software architecture.

Софт скиллы

Deep ownership

От стажёра до тех-лида за 2 года в одной компании, закрываю все домены проекта (Go, Python/ML, hardware, infra).

Системный дебаг

Диагностика race conditions, deadlock'ов, распределённых проблем (пример: 7 критических багов в velocity-режиме anti-drone, найдены и закрыты).

Self-starter

Переквалификация CV → Go под задачи проекта по собственной инициативе.

Внимание к деталям

Sub-degree наведение, sub-millisecond latency, точные геодезические преобразования.

Преданность делу, трудолюбие

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

Языки