⚡ Kotobotov ⚡

мой взгляд -> проверять входящие аргументы желательно вообще на ВСЕХ функциях (особенно на критически важных), другое дело что я бы не бросал исключения (мысль такая, что если ты что-то обработал, то это уже не исключительная ситуация), я бы просто их логировал - и исправлял ошибки на возможно корректные или значения по умолчанию (заглушку).

в виндовсе сменил контр и альт местами в системных настройках, чтоб нажимать контл большим пальцем (тоесть теперь альт, по аналогии с cmd в маке).

кажущаяся простота, завышенный спрос, размазанная ответственность, в итоге сама индустрия приманивает таких людей, которые и в 40 могут себя вести как дети.

контейнеры лучше шарить через репозиторий, тк за счет кэширования слоев получается очень быстрая и эффективная схема работы.

Чтоб получить максимально отказоустойчивое, необходимо сочетание грамотного софта и грамотной инфраструктуры.
по поводу хорошей/грамотной инфраструктуры, ее может обеспечить любой облачный провайдер (гугл клауд, амазон, айбиэм и тд)
по поводу софта -> есть разные подходы, восновном они базируются на том, что сервис распределен по кластеру (возможно разным датацентрам), данные о состоянии приложения тоже распределены таким образом чтоб в случае падения отдельного узла, можно было автоматически восстановить это состояние.
Для восстановления состояния популярны пару схем:
1. Все изменения в системе логируются и состояние восстанавливается из этих логов (Event sourcing)
2. Состояние само хранится в распределенных типах данных (CRDT), которые самостоятельно восстанавливаются из своих реплик.
остальные схемы уже устарели (избыточное резервирование и тд).

думаю зависит от конкретных коллег и среды в которой ты находишься.
они как могут способствовать твоему росту так и наоборот его задерживать.
Ну если кому-то нравиться все самому - пожалуйста. Я бы все же предпочел найти позитивную для роста среду.

>обработчик активации аккаунта если почтовый адрес от gmail?
не вижу никаких проблем чтоб обработчик, в этом случае, сам создал команду на активацию эккаунта.
>Лично я вижу 2 варианта на проектирование комманд
рабочая схема, но вы начинаете множите сущности там где этого особо и не требуется, заставьте свой сайт использовать тотже самый апи, который будут использовать сторонние сервисы, и сделайте его единым для всех.
Мне кажется неплохо было бы разделить действия "запроса статьи" и "получения рекомендаций к статье".

все зависит от того как вы думаете, кому сложно визуализировать схемы в голове, тот их чертит на бумаге.
ну а вообще иметь черновую схему продукта (алгоритма), часто очень помогает.

продать идею?
если бы это было востребовано, был бы рынок идей, на котором ими бы и торговали, но его нет, по очевидным причинам.
И вообще что такое идея? - это типа сформулированная чья-то хотелка? в стиле хочу приложение в котором я нажимаю кнопку и мне смешно?
Нет, абстрактные хотелки ничего не стоят, нужны решения.

Шансов - ноль, зиро, никаких (даже на джуна).

обычная практика - небольшое тестирование (лайф кодинг, техническое собеседование), + оценка партфолио, потом человека нанимают на испытательный срок, и дают ему эти самые "тестовые задания", присматриваются к нему еще пару месяцев, если подходит оставляют, нет - расстаются.
Смысла делать тестовые задания ДО того как тебя наняли - нет абсолютно никакого (ну разве что тебе самому хочется бесплатно поработать, хотя для этого есть опенСорс).

время идет, мир меняется, а в месте с этим и потребности к продуктам, например сейчас сильно увеличилось количество фреймворков/инструментов требуемых для среднего разработчика, железо также сильно изменилось с тех времен когда разрабатывалась джава, стали массового распространены многоядерные системы, в обыденность вошли продукты которые работают на кластерах и тд. Scala - разработан чтоб упростить нарастающую сложность.
при этом Scala - это не better java, это не про ООП или ФП, это язык практикующий в первую очередь практичный/прагматичный подход, стремящийся упростить работу с фреймворками, многоядерными системами, кластерами, различными платформами (компилироваться в js, нативно компилироваться и работать без jvm, работа с видеокартами и тд).
И как любой прагматичный язык, он позволяют работать с ним таким образом, как кто-то уже привык работать, например работать как с Java.
один из примеров упрощения : типы в скала, автоматически выводятся, их не обязательно указывать, из-за чего легко можно эксперементировать с кодом и его рефакторить, все зависимости по типам будут автоматически выводится сами.
Например зная интерфейсы Scala коллекций ты автоматически знаешь интерфейсы подавляющей части существующих в экосистеме фреймворков (общие интерфейсы).
Также ты можешь код разработанный как однопоточный, перенести на многопоточную среду, а затем и на кластер, и тд.
Есть простые схемы для создания собственных элегантных домен специфичных языков (используя перегрузку операторов, неявные параметры, неявные функции, автоматическую конвертацию типов).