Знавал я таких "девопсов": "у себя в разработке делайте что хотите, а на прод мои пайплайны будут выкатывать как мне надо", а потом не может ни сам пофиксить что-то, ни предоставить информацию для локализации и фикса, ни внятно запросить информацию нужную ему. А следить за хоть как-то, но работающими докерфайлами, где, например, все нужные зависимости перечислены, отказывается — требует отдельный список всех пакетов для него вести, причём для какой-нибудь CentOS, которую никто из разрабов в глаза не видел.
Даже то, как Докер хранит свои логи, уже указывает на то, что делался он без соблюдения хоть каких-то стандартов, потому что логи должны лежать в /var/log/, а не в рандомном месте ОС.
Most logs must be written to this directory or an appropriate subdirectory. — вы про этот стандарт? А он вообще официально принят?
А причём тут лень? Поднимать инфраструктуру для докера с нуля довольно утомительно для программиста, имхо. С другой стороны, часто именно с докеризации начинается нормальная автоматизация деплоев и вот это вот всё — с докером уже rsync c дев машины не запустишь.
А кто её должен выполнять, если девопса в штате нет? Или он один на несколько десятков разработчиков? И если не каждый день новый сервис, то новая зависимость? И вообще чем работа девос отличается от работы админа продакшен-сервера?
А сколько всего разработчиков будет писать на реакте? Будут те, что учиться будут? Если так то посадите этих двоих чтоб задокументировали общие принципы разработки приложения. Хотя в любом случае посадите. )
Я как раз про то, что серьёзные проекты, которым они чем-то помогут, явно не большинство. Это у них активно в проде асинхронный пхп уже используется и им не хватает многопоточности.
Выкатить могут, но вот как донести разработчикам магазина ООО "Рога и копыта", что переход на новые принципы упростит их работу, ускорит деливери бизнес-фич? Особенно если это будет неправдой. ))
Переводить не обязательно, но пометить как техдолг и выработать стратегию работы с ним типа "при любой задаче на изменение компонента переводим его на новый лад" надо.
Просто перестаньте относиться к реакту как к тому, чем он не является — полноценному фреймворку.
Ок. Реакт навязывает единственную вещь: вью — чистая функция от переданных свойств и, опционально, стэйта и рендерится автоматически при их изменении в терминах JS. Если собираетесь с этим бороться, то это будет больно.
Через psalm не всем подходит. Но вообще, да, это не главная проблема. С другой стороны, многопоточность и асинхронность явно не те фичи, которые как-то заметно помогут большинству проектов на PHP.
Скорее всего автор имеет в виду "использующие серверный рендеринг html хотя бы раз в ответ на http запрос". Но из поста это не совсем очевидно, мягко говоря.
Знавал я таких "девопсов": "у себя в разработке делайте что хотите, а на прод мои пайплайны будут выкатывать как мне надо", а потом не может ни сам пофиксить что-то, ни предоставить информацию для локализации и фикса, ни внятно запросить информацию нужную ему. А следить за хоть как-то, но работающими докерфайлами, где, например, все нужные зависимости перечислены, отказывается — требует отдельный список всех пакетов для него вести, причём для какой-нибудь CentOS, которую никто из разрабов в глаза не видел.
Most logs must be written to this directory or an appropriate subdirectory. — вы про этот стандарт? А он вообще официально принят?
А причём тут лень? Поднимать инфраструктуру для докера с нуля довольно утомительно для программиста, имхо. С другой стороны, часто именно с докеризации начинается нормальная автоматизация деплоев и вот это вот всё — с докером уже rsync c дев машины не запустишь.
1 ещё актуально? )
А кто её должен выполнять, если девопса в штате нет? Или он один на несколько десятков разработчиков? И если не каждый день новый сервис, то новая зависимость? И вообще чем работа девос отличается от работы админа продакшен-сервера?
А сколько всего разработчиков будет писать на реакте? Будут те, что учиться будут? Если так то посадите этих двоих чтоб задокументировали общие принципы разработки приложения. Хотя в любом случае посадите. )
Я как раз про то, что серьёзные проекты, которым они чем-то помогут, явно не большинство. Это у них активно в проде асинхронный пхп уже используется и им не хватает многопоточности.
Выкатить могут, но вот как донести разработчикам магазина ООО "Рога и копыта", что переход на новые принципы упростит их работу, ускорит деливери бизнес-фич? Особенно если это будет неправдой. ))
Переводить не обязательно, но пометить как техдолг и выработать стратегию работы с ним типа "при любой задаче на изменение компонента переводим его на новый лад" надо.
Есть в команде хоть один человек, хорошо знающий реакт?
Другая парадигма предполагает другие правила хорошего тона. И задача архитектора задать их и донести до команды, особенно пришедшей с другого стэка.
Просто перестаньте относиться к реакту как к тому, чем он не является — полноценному фреймворку.
Ок. Реакт навязывает единственную вещь: вью — чистая функция от переданных свойств и, опционально, стэйта и рендерится автоматически при их изменении в терминах JS. Если собираетесь с этим бороться, то это будет больно.
2 Со временем всё сложнее будет находить специалистов, готовых с этим работать. Особенно вдолгую.
Не баг, а не реализовано. На приложение вообще официально забили.
Через psalm не всем подходит. Но вообще, да, это не главная проблема. С другой стороны, многопоточность и асинхронность явно не те фичи, которые как-то заметно помогут большинству проектов на PHP.
Ну вот все страницы со ссылкой надо перегенерировать, да, когда картинку надо поменять?
Скорее всего автор имеет в виду "использующие серверный рендеринг html хотя бы раз в ответ на http запрос". Но из поста это не совсем очевидно, мягко говоря.
Есть международных корпорации. Есть страны с несколькими языками.
Вот реакт как раз ничего особо не форсирует
Просто во вкладке или в режиме PSA?
Какие-то карты составлять типа:
а не
а потом выгребать по id