Пожалуй самый главный миф - "PHP медленный". Но если глянуть бенчмарки, из "большой тройки" скриптовых языков для веба (PHP, Python, Ruby) именно PHP является самым быстрым. Благодаря оптимизациям движка Zend и JIT‑компилятору в PHP 8, в сырых вычислениях и пропускной способности HTTP‑запросов PHP стабильно обгоняет стандартный CPython и Ruby.
Уважаемый@MountainGoat, причин накидать прототип чего‑то нового на PHP и сегодня достаточно. А некоторые такие "прототипы" потом вырастают в весьма значимые проекты: Nextcloud, Tumblr, Badoo, BlaBlaCar, видеохостинг Dailymotion, Trivago.. И да, при росте масштаба вокруг PHP вполне могут появляться Java, Go, Node.js, Kafka, Elasticsearch и так далее - но это уже вопрос архитектуры.
По поводу CMS. В нынешнее время особенно ЕС массово использует в своих правительственных и институциональных порталах Drupal. И, что интересно, это уже далеко не просто "старая CMS", а одна из самых активно развивающихся платформ. По данным из доклада на Пых.конф’25, за предыдущий год у Drupal было около 124 000 коммитов в ядро, 6 400 открытых PR и около 1 млн активных контрибьюторов, участвующих в ядре и связанных проектах.
А ещё Drupal довольно интересно подошёл к AI. Причём речь не просто про "давайте прикрутим chatGPT" или очередной вайб‑кодинг. AI глубоко интегрируется в саму модель Drupal: агенты работают с контентом и конфигурацией, конфигурации представлены в YAML и могут проходить обычный Git/CI/CD workflow, а права агента можно ограничивать на уровне ролей и permission'ов самого Drupal. То есть AI может генерировать и изменять конфигурацию, но результат остаётся контролируемым, проходит ревью и деплоится обычным способом.
В Drupal CMS 2.0, вышедшем в январе 2026 года, AI уже встроен в саму платформу, а не существует просто в виде внешнего чат‑бота.
И есть совсем интересные проекты вроде Boson - runtime/toolkit, который позволяет писать кроссплатформенные desktop‑приложения на PHP с привычным HTML/CSS/JS, но без Electron и Node.js. PHP runtime, код приложения и необходимые компоненты собираются в единый исполняемый файл, который можно распространять без отдельной установки PHP. Есть интеграции с Symfony и Laravel.
Интересный факт) А вы знали, что основа "той самой" Pornhub - это проверенная временем связка: Nginx, PHP, MySQL, Memcached и Redis? Вот интервью (от 2019 года) с разработчиком. Позже по мере роста нагрузки к этому стеку добавили ElasticSearch, Node.js, Go и Vertica.
И это далеко не застой: PHP продолжает развиваться - улучшается производительность, типизация, обсуждаются generics, data classes, async и новые возможности рантайма. Так что хоронить его, похоже, ещё рановато.
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 поддерживается без изменений кода.
Пожалуй самый главный миф - "PHP медленный". Но если глянуть бенчмарки, из "большой тройки" скриптовых языков для веба (PHP, Python, Ruby) именно PHP является самым быстрым. Благодаря оптимизациям движка Zend и JIT‑компилятору в PHP 8, в сырых вычислениях и пропускной способности HTTP‑запросов PHP стабильно обгоняет стандартный CPython и Ruby.
Уважаемый@MountainGoat, причин накидать прототип чего‑то нового на PHP и сегодня достаточно. А некоторые такие "прототипы" потом вырастают в весьма значимые проекты: Nextcloud, Tumblr, Badoo, BlaBlaCar, видеохостинг Dailymotion, Trivago.. И да, при росте масштаба вокруг PHP вполне могут появляться Java, Go, Node.js, Kafka, Elasticsearch и так далее - но это уже вопрос архитектуры.
По поводу CMS. В нынешнее время особенно ЕС массово использует в своих правительственных и институциональных порталах Drupal. И, что интересно, это уже далеко не просто "старая CMS", а одна из самых активно развивающихся платформ. По данным из доклада на Пых.конф’25, за предыдущий год у Drupal было около 124 000 коммитов в ядро, 6 400 открытых PR и около 1 млн активных контрибьюторов, участвующих в ядре и связанных проектах.
А ещё Drupal довольно интересно подошёл к AI. Причём речь не просто про "давайте прикрутим chatGPT" или очередной вайб‑кодинг. AI глубоко интегрируется в саму модель Drupal: агенты работают с контентом и конфигурацией, конфигурации представлены в YAML и могут проходить обычный Git/CI/CD workflow, а права агента можно ограничивать на уровне ролей и permission'ов самого Drupal. То есть AI может генерировать и изменять конфигурацию, но результат остаётся контролируемым, проходит ревью и деплоится обычным способом.
В Drupal CMS 2.0, вышедшем в январе 2026 года, AI уже встроен в саму платформу, а не существует просто в виде внешнего чат‑бота.
И есть совсем интересные проекты вроде Boson - runtime/toolkit, который позволяет писать кроссплатформенные desktop‑приложения на PHP с привычным HTML/CSS/JS, но без Electron и Node.js. PHP runtime, код приложения и необходимые компоненты собираются в единый исполняемый файл, который можно распространять без отдельной установки PHP. Есть интеграции с Symfony и Laravel.
Интересный факт) А вы знали, что основа "той самой" Pornhub - это проверенная временем связка: Nginx, PHP, MySQL, Memcached и Redis? Вот интервью (от 2019 года) с разработчиком. Позже по мере роста нагрузки к этому стеку добавили ElasticSearch, Node.js, Go и Vertica.
И это далеко не застой: PHP продолжает развиваться - улучшается производительность, типизация, обсуждаются generics, data classes, async и новые возможности рантайма. Так что хоронить его, похоже, ещё рановато.
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 поддерживается без изменений кода.