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

Современный смартфон представляет собой доступную COTS‑платформу с набором встроенных датчиков: камерой, GNSS‑приемником, 6-DoF IMU, барометром и микрофонами. По отдельности эти сенсоры ограничены, однако их совместное использование в распределенной сети потенциально позволяет создавать новые подходы к обнаружению низколетящих БПЛА.

Это не задача создания «смартфонного радара», а инженерная задача на стыке краудсорсинга, Edge Computing, машинного обучения и обработки сигналов.

Как превратить множество пользовательских устройств в единую распределенную апертуру? Попробуем рассмотреть возможную архитектуру такой системы.

REST API на Symfony писать удобно, но есть одна скучная особенность: контроллеры быстро начинают обрастать повторяющимся кодом. Парсинг запроса, валидация, однотипная JSON‑обёртка, try/catch с преобразованием исключений в HTTP‑ответы. Всё это несложно, но со временем размазывается по десяткам эндпоинтов и отвлекает от основной задачи.

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

Каждый раз, когда хотелось быстро попробовать что‑то на Symfony, начиналась одна и та же история: поднять контейнер с PHP‑FPM или FrankenPHP, провалиться в контейнер, поставить symfony/skeleton, настроить Nginx или Caddyfile, прописать переменные окружения... И всё это до того, как написана хоть одна строчка кода.

DI‑контейнер, консольные команды, компонентная архитектура... Ни для кого не секрет, Symfony заметно ориентируется на Java‑экосистему. Почему бы не попробовать сделать что‑то подобии start.spring.io подумал я.

Так появился пет-проект symfony-init.dev