Тоже удивлен что в 2к24 требуется целая статья на Хабре, чтобы поставить винду. Процесс как по мне очень простой. Ставишь на современное железо - официальный образ с MSDN и MediaCreationTool. На не очень современное - старый добрый Rufus c двумя галками. А если уж на очень не современное (COM-порт, non-UEFI, 128Гб) - виндовс этот 11ый не нужен тебе, юный падаван.
И по надуманным проблемам все свалено в кучу, и SafeMode, и OCCT и драйвера несчастной nVidia. Автору хочется взять и подарить загрузочную дискету Win98, чтоб простой тест на адекватность и умение снимать галки проходился проще.
Грустно, что то что в мои школьные годы делалось за банку пива, сегодня - целая статья по "системному администрированию". Напомнило "зуммеры изобрели погреб".
Ниже аргумент про жепег кстати невалидный, у jpg (впрочем как и у bmp) есть header, и он у всех жпегов один.
Сразу вопрос: зачем нам nullable-типы в проекте, что мы хотим получить? В статье мотивация не раскрыта, обозначу сам -- чтобы получать предупреждение в редакторе о потенциальных NRE в коде.
Для этого существует Rider и аннотации, в частности [CanBeNull]. А здесь автор предлагает каждый класс пачкать директивой, так еще и по всему коду сборки бегать расставлять обратный костыль-директиву, в случае сборок разумеется.
Отдельно отмечу что единственный профит от сборок (AssemblyDefenition) - ускорение перекомпиляции скриптов проекта. Когда их добавляют на геймплейные модули и системы - больше проблем от распутывания референсов, чем выигрыша от реюза кода. Все примеры обожания асм-дефов которые я наблюдал начинались из-за неадекватно большого желания сэкономить время (= жадности) и/или большой глупости и заканчивались плачевно для проекта. Проекты были ГК и матч3, с попыткой выделения SDK и "собственного" фреймворка, чтоб конвеерно шлёпать прототипы. Конец немного предсказуем. В больших и хардкорных проектах такого недуга не наблюдал. Поэтому asmdef-ы использую только для того кода, который никогда не меняется -- сторонние библиотеки и фреймворки (если еще не) и базовые UI-компоненты (окна/кнопки для префабов, кладу в отдельную папку и сборку).
Отдельно поворчу, что: 1. Неизменяемые данные лучше делать struct или хотя бы record. Судя по [Serializable] ,UserResponse - это все таки данные, одноразовые, зачем они class? 2. Их открытые члены -- свойствами, а не полями. Есть еще атрибут [field:], если вдруг для Инспектора захочется не городить свойства+поля. 3. Пул также совершенно зря наследуется от MonoBehaviour. Монобехи это бридж между C#-классами сервисов и миром Unity - объектами сцены. Не могу представить какие ссылки со сцены нужны пулу, ну если он только не спавнер одновременно.
Да, в основном -- дело вкуса и привычки. Но постараюсь формализовать аргументы:
Стоимость и сроки внедрения, погружения команды. Zenject де-факто индустриальный стандарт, применяется в большинстве проектов и по нему больше материалов и кейсов разобрано (на английском, и надо поискать). Проще внедрить в проект, найти или обучить разработчиков.
Стоимость поддержки. Давно не обновлялся, был отдельный форк (Extenject), но старый баг лучше новых двух. Если его правильно готовить - отлично справляется со своими задачами как DI-контейнер.
В этой статье я как раз постарался собрать все практики и примеры использования в кучу, показать как Zenject встраивается и поддерживает архитектуру. Выбор в пользу Zenject делаю ориентируясь на команду (с чем готовы работать) и с расчетом на проверенный, обкатанный инструмент. Лично для меня тема не холиварная, если в проекте будет vContainer - буду работать с ним.
Тоже удивлен что в 2к24 требуется целая статья на Хабре, чтобы поставить винду. Процесс как по мне очень простой. Ставишь на современное железо - официальный образ с MSDN и MediaCreationTool. На не очень современное - старый добрый Rufus c двумя галками. А если уж на очень не современное (COM-порт, non-UEFI, 128Гб) - виндовс этот 11ый не нужен тебе, юный падаван.
И по надуманным проблемам все свалено в кучу, и SafeMode, и OCCT и драйвера несчастной nVidia. Автору хочется взять и подарить загрузочную дискету Win98, чтоб простой тест на адекватность и умение снимать галки проходился проще.
Грустно, что то что в мои школьные годы делалось за банку пива, сегодня - целая статья по "системному администрированию". Напомнило "зуммеры изобрели погреб".
Ниже аргумент про жепег кстати невалидный, у jpg (впрочем как и у bmp) есть header, и он у всех жпегов один.
Сразу вопрос: зачем нам nullable-типы в проекте, что мы хотим получить? В статье мотивация не раскрыта, обозначу сам -- чтобы получать предупреждение в редакторе о потенциальных NRE в коде.
Для этого существует Rider и аннотации, в частности [CanBeNull]. А здесь автор предлагает каждый класс пачкать директивой, так еще и по всему коду сборки бегать расставлять обратный костыль-директиву, в случае сборок разумеется.
Отдельно отмечу что единственный профит от сборок (AssemblyDefenition) - ускорение перекомпиляции скриптов проекта. Когда их добавляют на геймплейные модули и системы - больше проблем от распутывания референсов, чем выигрыша от реюза кода. Все примеры обожания асм-дефов которые я наблюдал начинались из-за неадекватно большого желания сэкономить время (= жадности) и/или большой глупости и заканчивались плачевно для проекта. Проекты были ГК и матч3, с попыткой выделения SDK и "собственного" фреймворка, чтоб конвеерно шлёпать прототипы. Конец немного предсказуем. В больших и хардкорных проектах такого недуга не наблюдал. Поэтому asmdef-ы использую только для того кода, который никогда не меняется -- сторонние библиотеки и фреймворки (если еще не) и базовые UI-компоненты (окна/кнопки для префабов, кладу в отдельную папку и сборку).
Отдельно поворчу, что:
1. Неизменяемые данные лучше делать
structили хотя быrecord. Судя по[Serializable],UserResponse- это все таки данные, одноразовые, зачем ониclass?2. Их открытые члены -- свойствами, а не полями. Есть еще атрибут
[field:], если вдруг для Инспектора захочется не городить свойства+поля.3. Пул также совершенно зря наследуется от
MonoBehaviour. Монобехи это бридж между C#-классами сервисов и миром Unity - объектами сцены. Не могу представить какие ссылки со сцены нужны пулу, ну если он только не спавнер одновременно.Да, в основном -- дело вкуса и привычки. Но постараюсь формализовать аргументы:
Стоимость и сроки внедрения, погружения команды. Zenject де-факто индустриальный стандарт, применяется в большинстве проектов и по нему больше материалов и кейсов разобрано (на английском, и надо поискать). Проще внедрить в проект, найти или обучить разработчиков.
Стоимость поддержки. Давно не обновлялся, был отдельный форк (Extenject), но старый баг лучше новых двух. Если его правильно готовить - отлично справляется со своими задачами как DI-контейнер.
В этой статье я как раз постарался собрать все практики и примеры использования в кучу, показать как Zenject встраивается и поддерживает архитектуру. Выбор в пользу Zenject делаю ориентируясь на команду (с чем готовы работать) и с расчетом на проверенный, обкатанный инструмент. Лично для меня тема не холиварная, если в проекте будет vContainer - буду работать с ним.