Можете писать на php, вот ещё не закоммитил даже роутинг для прототипа:
<?php declare(strict_types=1);
use App\User\RegisterFormController;
use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;
return function (RoutingConfigurator $routes) {
$routes->add('register', '/{_locale}/register')
->methods(['GET'])
->requirements(['_locale' => 'uk|ru'])
->controller([RegisterFormController::class, '__invoke']);
};
На аннотациях/атрибутах явно лучше было бы
Перефразируя вас: зрелая технология должна только работать без ошибок, а не кому-то что-то указывать (кроме пользовательских ошибок, нарушающих спецификации).
А обязанности архитектор на каждом проекте разные: от нарисовать на листочке несколько фигурок до разработки production ready нескольких модулей как пример и код-ревью каждого коммита на предмет соблюдения спроектированной архитектуры.
Шаблонизатор там есть на уровне envsubst, но я неправильно, видимо понял вашу мысль про шаблоны конфигов: я понял как шаблон для девопса, а не как готовый шаблон для его инструментов. То есть вы предлагаете, чтобы вместо докерфайлов и ко разработчики писали роли и плэйбуки для своих приложений, а девопсы будут их накатывать в пайплайнах? Результат может оказаться ещё хуже (
Я знаю, что бывают "девопсы", которые полностью игнорируют идеологию девопс. Они даже на вопрос "вот у вас написано девопс-инженер, что вы под этим понимаете" отвечают на собесе "крутой администратор"
Если никто не проверяет, что уехало в продакшен в Докере, если никто не довёл до программиста, что можно, а что нельзя делать в докерфайлах, то явно проблема не в программисте, а в отсутствующих процессах поддержки жизненного цикла приложений в компании. Нет корпоративных стандартов хотя бы разработки — глупо пенять на их несоблюдение.
Мифические тимлиды — люди, которым ПМ делегирует свои менеджерские обязанности, если в команде проекта больше 5 человек
Дело не в том, что не понятно, а в том. что противно смотреть на что-то вроде https://github.com/WordPress/WordPress/blob/master/wp-content/plugins/hello.php
21-й год 21-го века, PHP 8, а код будто из 90-х на PHP 3
И чем это лучше?
Тряхнул стариной и леплю свой
фреймворквелосипед на базе Swoole и Symfony Components :)Можете писать на php, вот ещё не закоммитил даже роутинг для прототипа:
Даже не Друпал?
файлы без минусов они смогли выбрать )
С командой выбирали саги или санк
Мне это не очевидно из поста
Перефразируя вас: зрелая технология должна только работать без ошибок, а не кому-то что-то указывать (кроме пользовательских ошибок, нарушающих спецификации).
А обязанности архитектор на каждом проекте разные: от нарисовать на листочке несколько фигурок до разработки production ready нескольких модулей как пример и код-ревью каждого коммита на предмет соблюдения спроектированной архитектуры.
Но выбрали в итоге редакс с сагами… А не, хотя бы, mobx
Шаблонизатор там есть на уровне envsubst, но я неправильно, видимо понял вашу мысль про шаблоны конфигов: я понял как шаблон для девопса, а не как готовый шаблон для его инструментов. То есть вы предлагаете, чтобы вместо докерфайлов и ко разработчики писали роли и плэйбуки для своих приложений, а девопсы будут их накатывать в пайплайнах? Результат может оказаться ещё хуже (
Сорри. Не посмотрел кто ответил
Внешние сервисы можно прикрутить для оценок и комментариев )
Странно с такой позицией предъявлять претензии, что Docker не пишет логи (вернее stdout/stderr) контейнеров в /var/log — для него это смерть )
Dockerfile и есть скрипт установки на "голую" машину :)
Может для автора выбор был очевиден, но он обсуждал варианты с командой, которая опыта точно не имела. Собственно основная его ошибка
В блогах часто меняется. ) Вот Хабр — блог-платформа по сути ))
Я знаю, что бывают "девопсы", которые полностью игнорируют идеологию девопс. Они даже на вопрос "вот у вас написано девопс-инженер, что вы под этим понимаете" отвечают на собесе "крутой администратор"
Если никто не проверяет, что уехало в продакшен в Докере, если никто не довёл до программиста, что можно, а что нельзя делать в докерфайлах, то явно проблема не в программисте, а в отсутствующих процессах поддержки жизненного цикла приложений в компании. Нет корпоративных стандартов хотя бы разработки — глупо пенять на их несоблюдение.