перед этим обязательно выполним очистку кэша докера через команду: docker system prune -a
Чтобы наверняка - можно еще винды переустановить Должно быть достаточно:
docker compose build --no-cache
перед стартом, чтобы гарантировано получить полностью новые latest-образы сервисов (или сервиса, передав его имя последним аргументом), которые подтянутся при создании новых контейнеров.
нет никакой надобности делать класс "Договор" с методом "Подписать" и другими методами, которые пытаются имитировать действия над договором в реальном мире
Такая необходимость - это работа с требованиями. Гораздо проще жить имея бизнес-слой, который со стороны вызовов будет читаться по буквам требований, а под капотом - осуществлять привязку к технической реальности, вроде схемы БД.
std.stdio.write - шаблонная функция, полагаю, вам намекают на статический полиморфизм. Кстати, в том же C# компилятор умеет делать мономорфизацию для аргументов-типов в дженериках с where T: struct, что позволяет обходиться без боксинга для значимых типов.
У них других дел нет, чтобы еще и в программистов успевать играть?) Самые разные конторы и проекты были. От типичного заказного бизнес-софта, до банковсковского энтерпрайза и бигтехов. И там бывали разные вариации деления ответственностью, но настолько программистов до писателей исключительно простого кода без обязанности принятия технических решений нигде не опускали)
Архитектор или девопс вам кафку не подключат в приложение. Тимлид - это тоже программист. Но он и человек, который может заболеть или уволиться. Да и прочих дел у него хватает, нередко бывает так, что лиды сами код не пишут. Да и на добавлении кафки приключения не заканчиваются - вокруг нее могут (да и будут, чего уж там) возникать разного рода проблемы, которые необходимо отлаживать. И, нет, архитектор с девопсом не полезут в код сервиса смотреть, по какой причине был отвал.
Практически - не никогда, инфраструктурный код из воздуха не рождается. Отсюда возвращаемся бугурту в начале треда: при прочих равных выгоднее нанять программиста, который уже овладел необходимым, чем упереться в его "созревание", когда это таки понадобится.
Если вся команда состоит из лида и толпы джуниоров - явно такие задачи будет тянуть только первый. Если же там сеньеры через одного - можно привлекать любого.
Что касается прочих - они код приложения не пишут.
Что касается классических баз данных, по моему опыту изменение схемы, миграции данных, профилирование запросов с расставлены индексов и прочим - на плечах разрабатывающей фичу команды. При глобальных изменениях или когда изменения пересекаются несколькими командам - привлекается архитектор. Говорят, где-то бывают даже целые базисты (выделенные разработчики БД), но не встречал таких в живую. Масштабирование - да, работа в компании с DBA/девопсами, но инициатива и поддержка этого со стороны приложения - на команде разработки. Лид там представляет команду разработки или сеньеры, или все вместе (см. scrum) - это уже зависит от уровня команды и целевой автономности. Если вся команда состоит из лида и толпы джуниоров - явно такие задачи будет тянуть только первый. Если же там сеньеры через одного - можно привлекать любого.
С кафкой прикол в том, что половина её обвязки - ответственность клиентского кода, её подгоняют под конкретную ситуацию, вариаций порядочно. На каждой второй конференции будет часовой доклад про то, как у себя делали transactional outbox, какие ноги в процессе поотстреливали и к каким компромиссам в итоге пршли.
Инфраструктурный код пишут такие же программисты, а не мифические существа. Как правило, это та команда,которая первой столкнулась с необходимостью брокера на проекте. Возникающие проблемы приложения с ней решают тоже программисты, при необходимости привлекая девопсов и архитектора, если нужна донастройка со стороны эксплуатации или отеческое напутствие. И тут как с любым другим чужим кодом: чтобы его грамотно использовать важно знать его применимость и ограничения, а значит и устройство, хотя бы в общих чертах, включая саму кафку.
Чтобы шаблонные строки написать кто-то сначала должен написать шаблоны. Как без знания устройства кафки сделать сколь-либо надежный обмен сообщениями (приблизиться к пресловутому exactly-once), при этом не растеряв производительность? Как сделать месштабируемый сервис с ней? Куда бежать и на какие кнопки жать, если что-то пойдет не так, если сообщения иногда пропадают или консьюмеры постоянно падают?
Кто хочет деталей, тот читает спецификацию, а не MDN и иже с ним) Абстракции придумывают затем, чтобы было проще: хорошая абстракция позволяет не погружаться в детали реализации.
Ничего не имею против желания поделиться свежим открытием, но подача выглядит так, что тут fun fact пытаются выдать за срывание покровов.
Зачем с ними совмещаться? Добровольно-принудительно мигрировать в сторону ODF.
И огребите неочевидных проблем от чего-то вроде файлов с пробелами в именах.
И не режиссер.
Чтобы наверняка - можно еще винды переустановитьДолжно быть достаточно:перед стартом, чтобы гарантировано получить полностью новые latest-образы сервисов (или сервиса, передав его имя последним аргументом), которые подтянутся при создании новых контейнеров.
А это уже не проблема или ограничение C#. Если надо - кладите структуру в другую структуру и в Span/stackalloc, язык это позволяет.
Такая необходимость - это работа с требованиями. Гораздо проще жить имея бизнес-слой, который со стороны вызовов будет читаться по буквам требований, а под капотом - осуществлять привязку к технической реальности, вроде схемы БД.
std.stdio.write- шаблонная функция, полагаю, вам намекают на статический полиморфизм. Кстати, в том же C# компилятор умеет делать мономорфизацию для аргументов-типов в дженериках сwhere T: struct, что позволяет обходиться без боксинга для значимых типов.Это сработает на этапе JIT-компиляции, а в байткоде - честный callvirt.
Уже сделано - Web Components.
Silverlight тут стоит вспомнить тогда уже, как продолжение идеи WPF c XAML-версткой.
Расскажите, как без знания устройства кафки выбрать ключ для сообщений в новом топике и не огрести потом, когда потребуется масштабировать?
Скорее как добавить новую таблицу. И индексы расставить, с оглядкой на сценарии использования.
У них других дел нет, чтобы еще и в программистов успевать играть?)
Самые разные конторы и проекты были. От типичного заказного бизнес-софта, до банковсковского энтерпрайза и бигтехов. И там бывали разные вариации деления ответственностью, но настолько программистов до писателей исключительно простого кода без обязанности принятия технических решений нигде не опускали)
Архитектор или девопс вам кафку не подключат в приложение. Тимлид - это тоже программист. Но он и человек, который может заболеть или уволиться. Да и прочих дел у него хватает, нередко бывает так, что лиды сами код не пишут.
Да и на добавлении кафки приключения не заканчиваются - вокруг нее могут (да и будут, чего уж там) возникать разного рода проблемы, которые необходимо отлаживать. И, нет, архитектор с девопсом не полезут в код сервиса смотреть, по какой причине был отвал.
Практически - не никогда, инфраструктурный код из воздуха не рождается. Отсюда возвращаемся бугурту в начале треда: при прочих равных выгоднее нанять программиста, который уже овладел необходимым, чем упереться в его "созревание", когда это таки понадобится.
Что касается прочих - они код приложения не пишут.
Что касается классических баз данных, по моему опыту изменение схемы, миграции данных, профилирование запросов с расставлены индексов и прочим - на плечах разрабатывающей фичу команды. При глобальных изменениях или когда изменения пересекаются несколькими командам - привлекается архитектор. Говорят, где-то бывают даже целые базисты (выделенные разработчики БД), но не встречал таких в живую. Масштабирование - да, работа в компании с DBA/девопсами, но инициатива и поддержка этого со стороны приложения - на команде разработки. Лид там представляет команду разработки или сеньеры, или все вместе (см. scrum) - это уже зависит от уровня команды и целевой автономности. Если вся команда состоит из лида и толпы джуниоров - явно такие задачи будет тянуть только первый. Если же там сеньеры через одного - можно привлекать любого.
С кафкой прикол в том, что половина её обвязки - ответственность клиентского кода, её подгоняют под конкретную ситуацию, вариаций порядочно. На каждой второй конференции будет часовой доклад про то, как у себя делали transactional outbox, какие ноги в процессе поотстреливали и к каким компромиссам в итоге пршли.
Инфраструктурный код пишут такие же программисты, а не мифические существа. Как правило, это та команда,которая первой столкнулась с необходимостью брокера на проекте. Возникающие проблемы приложения с ней решают тоже программисты, при необходимости привлекая девопсов и архитектора, если нужна донастройка со стороны эксплуатации или отеческое напутствие. И тут как с любым другим чужим кодом: чтобы его грамотно использовать важно знать его применимость и ограничения, а значит и устройство, хотя бы в общих чертах, включая саму кафку.
Чтобы шаблонные строки написать кто-то сначала должен написать шаблоны. Как без знания устройства кафки сделать сколь-либо надежный обмен сообщениями (приблизиться к пресловутому exactly-once), при этом не растеряв производительность? Как сделать месштабируемый сервис с ней? Куда бежать и на какие кнопки жать, если что-то пойдет не так, если сообщения иногда пропадают или консьюмеры постоянно падают?
Шаверма же!
Кто хочет деталей, тот читает спецификацию, а не MDN и иже с ним) Абстракции придумывают затем, чтобы было проще: хорошая абстракция позволяет не погружаться в детали реализации.
Ничего не имею против желания поделиться свежим открытием, но подача выглядит так, что тут fun fact пытаются выдать за срывание покровов.