1) Правовой аспект. Вы абсолютно правы насчет текущих ограничений на съемку последствий атак. Однако концепция системы рассчитана на раннее предупреждение (за десятки километров до города), а не на фиксацию последствий атак. 2) РЭБ и связь. Отсутствие GPS и интернета - это не упущение, а ключевое граничное условие. Именно поэтому в архитектуре заложены альтернативные каналы (Mesh, LoRa) и алгоритмы, устойчивые к асинхронности данных. 3) Цель статьи. Это не питч готового продукта и не призыв что-то скачать. Это архитектурный мысленный эксперимент. Главный вопрос статьи: возможно ли технически и алгоритмически заставить обычные COTS-устройства работать как распределенный сенсорный массив, компенсируя их шумы математикой?
В этом сервисе упор был на то, чтобы у пользователя не было лишних зависимостей: только скачать ZIP и запустить docker compose. Спасибо за вариант, про Copier не знал - полезно!
Спасибо за идею с Makefile и make init - одну точку входа действительно удобно иметь. По поводу переноса тяжёлых процессов на получателя: чтобы в проекте был composer.lock (воспроизводимые сборки), composer install на сервере в любом случае нужен - без него lock не получить. Значит, от того, что получатель дополнительно запускает composer install по make init, нагрузка с сервера не снимается, выигрыш в основном в размере архива (не кладем vendor/ в ZIP). Для такого утилитарного стартера это не такой уж большой выигрыш, а усложнять логику не хочется.
Совершенно верно - и #[MapRequestPayload] с автовалидацией, и централизованная обработка через kernel.exception - это стандартные инструменты Symfony. Ваш пример хорошо показывает, что в рамках одного проекта можно обойтись без дополнительного бандла и держать всё под контролем. Собственно, я и сам делал именно так - через subscriber с маппингом исключений и единым JsonResponse. Бандл решает немного другую задачу. Он не добавляет новую механику поверх Symfony, а упаковывает уже существующие практики в переиспользуемый слой. Когда проектов становится много (микросервисы, разные команды, разные подрядчики), важна не просто централизованная обработка ошибок, а гарантированная консистентность формата ответов между сервисами - без копирования listener’ов из проекта в проект и без постепенного "дрейфа" структуры. В случае с ExceptionResponseSubscriber его действительно несложно написать. Сложнее - поддерживать синхронность изменений между несколькими репозиториями, когда формат ответа эволюционирует. Кстати, по RFC 7807 - идея хорошая! Если кому-то нужен полноценный problem+json технически это реализуемо через ResponseFactoryInterface который уже есть в бандле. Можно добавить ProblemDetailsResponseFactory как альтернативную реализацию и переключать через конфиг (format: problem+json). Единственный нюанс - RFC 7807 стандартизирует только формат ошибок, для успешных ответов общего стандарта нет, поэтому это скорее опциональный режим, а не замена дефолтному формату. Если будет запрос - реализовать несложно. В общем, ваш подход полностью корректен для проекта, где всё находится под контролем одной команды. А бандл может быть полезен там, где нужна стандартизация между несколькими проектами "из коробки".
Спасибо за конкретику - всё по делу. По.gitattributes, export-ignore и recipes принято, это очевидный пропуск. По поводу версий - это ошибка, не намерение. Я случайно запинил 7.4.* вместо ^7.4|^8.0. Бандл не использует deprecated API, поэтому Symfony 8.0 поддерживается без изменений кода.
1) Правовой аспект. Вы абсолютно правы насчет текущих ограничений на съемку последствий атак. Однако концепция системы рассчитана на раннее предупреждение (за десятки километров до города), а не на фиксацию последствий атак.
2) РЭБ и связь. Отсутствие GPS и интернета - это не упущение, а ключевое граничное условие. Именно поэтому в архитектуре заложены альтернативные каналы (Mesh, LoRa) и алгоритмы, устойчивые к асинхронности данных.
3) Цель статьи. Это не питч готового продукта и не призыв что-то скачать. Это архитектурный мысленный эксперимент. Главный вопрос статьи: возможно ли технически и алгоритмически заставить обычные COTS-устройства работать как распределенный сенсорный массив, компенсируя их шумы математикой?
В этом сервисе упор был на то, чтобы у пользователя не было лишних зависимостей: только скачать ZIP и запустить docker compose. Спасибо за вариант, про Copier не знал - полезно!
Спасибо за идею с
Makefileи make init - одну точку входа действительно удобно иметь. По поводу переноса тяжёлых процессов на получателя: чтобы в проекте былcomposer.lock(воспроизводимые сборки), composer install на сервере в любом случае нужен - без него lock не получить. Значит, от того, что получатель дополнительно запускает composer install по make init, нагрузка с сервера не снимается, выигрыш в основном в размере архива (не кладемvendor/в ZIP). Для такого утилитарного стартера это не такой уж большой выигрыш, а усложнять логику не хочется.Совершенно верно - и
#[MapRequestPayload]с автовалидацией, и централизованная обработка черезkernel.exception- это стандартные инструменты Symfony. Ваш пример хорошо показывает, что в рамках одного проекта можно обойтись без дополнительного бандла и держать всё под контролем. Собственно, я и сам делал именно так - через subscriber с маппингом исключений и единым JsonResponse.Бандл решает немного другую задачу. Он не добавляет новую механику поверх Symfony, а упаковывает уже существующие практики в переиспользуемый слой. Когда проектов становится много (микросервисы, разные команды, разные подрядчики), важна не просто централизованная обработка ошибок, а гарантированная консистентность формата ответов между сервисами - без копирования listener’ов из проекта в проект и без постепенного "дрейфа" структуры.
В случае с
ExceptionResponseSubscriberего действительно несложно написать. Сложнее - поддерживать синхронность изменений между несколькими репозиториями, когда формат ответа эволюционирует.Кстати, по RFC 7807 - идея хорошая! Если кому-то нужен полноценный
problem+jsonтехнически это реализуемо черезResponseFactoryInterfaceкоторый уже есть в бандле. Можно добавитьProblemDetailsResponseFactoryкак альтернативную реализацию и переключать через конфиг (format: problem+json). Единственный нюанс - RFC 7807 стандартизирует только формат ошибок, для успешных ответов общего стандарта нет, поэтому это скорее опциональный режим, а не замена дефолтному формату. Если будет запрос - реализовать несложно.В общем, ваш подход полностью корректен для проекта, где всё находится под контролем одной команды. А бандл может быть полезен там, где нужна стандартизация между несколькими проектами "из коробки".
Спасибо за конкретику - всё по делу. По
.gitattributes,export-ignoreи recipes принято, это очевидный пропуск. По поводу версий - это ошибка, не намерение. Я случайно запинил7.4.*вместо^7.4|^8.0. Бандл не использует deprecated API, поэтому Symfony 8.0 поддерживается без изменений кода.