В стандартном Review можно уточнять дальнейшие шаги реализации. Реализованно ли это в ChatGPT-CodeReview или он дает только первоначальные замечания по коммиту и при следующих комментах (реакциях) от юзера в PullRequest будет тишина?
как происходит доставка конечного бинарника на Playdate, у них есть какой-то собственный стор или только локальная установка? интересен момент именно шаринга между юзерами
в текущее время какие-то проекты еще приносят доход, обновляются или большая часть их уже заархивирована? еще бы был интересен интервал по проектам от создания до первой релизной версии.
если бы критика была действительно контексту статьи это одно.
но если определение:
GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.
сделает статью интересней для читателя или деталней объяснит проблематкику, то ок.
конкретно по 2 пункту, field-property Стандартный Unity JsonUtility не умел сериализовать свойства и при вызове метода JsonUtility.ToJson результатом был пустой json. Отпишите, если вдруг в какой-то версиях это добавили, данный формат в Unity поддерживала только зависимость на Newtonsoft.Json
по поводу обмазывания аннотация никто это делать не предлагает, это лишь примеры как включить статический анализ в конкретных местах, никто не запрещает сделать один глобальный конфиг nullable или все доменную область Game.asmdef отметить данной аннотацией
для этого их и сделали необязательным, чтобы можно было потихоньку включить анализ лишь для отдельных частей,
в конретной практике скажу, что это удобно даже больше для UPM packages, где юзер получает внешнее API и ему явно указывается контракт Для меня это просто банально выглядиь читаемый, чем подстановки [CanBeNull] аттрибуты, особенно в случае с сигнатурами.
Это стоит воспринимать как еще один помощник статическу анализаторому, а не панацею от всех бед, т.к даже в офф. гите MS, можно найти довольно уникальный кейсы когда анализатор даже не заметит NullRef, т.к с новыми версиями .Net они дорабатывают ее.
если структура координально не меняется, то да Unity автоматом биндит их (например обновляются ассеты или конфиги), но с некоторыми критами, как например при последней обнове Google SDKs, где порефакторили прям структуру package, придется распаковывать ручками в нужную папку
Т.к при большом кол-во ассетов в родительская папка довольно быстро засоряется. Как решали данный момент или оставляли все как есть, т.к многие разработчики все еще не переходят на UPM registry
В стандартном Review можно уточнять дальнейшие шаги реализации.
Реализованно ли это в ChatGPT-CodeReview или он дает только первоначальные замечания по коммиту и при следующих комментах (реакциях) от юзера в PullRequest будет тишина?
было бы интересно узнать еще про инструменты перевода, например DeepL и аналоги, насколько они подходят под переводы тех. статей.
Интересно было бы узнать, применяются ли internal решения для ваших Open Source проектов и как там формируется Review и автоматизация проверок.
как происходит доставка конечного бинарника на Playdate, у них есть какой-то собственный стор или только локальная установка? интересен момент именно шаринга между юзерами
будут ли материал в открытом доступе или обязательна регистрация через личный кабинет c доступом только на время курса?
в текущее время какие-то проекты еще приносят доход, обновляются или большая часть их уже заархивирована?
еще бы был интересен интервал по проектам от создания до первой релизной версии.
если бы критика была действительно контексту статьи это одно.
но если определение:
GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.
сделает статью интересней для читателя или деталней объяснит проблематкику, то ок.
в 4 строчке статьи указана расшифровка
GRASP расшифровывается как общие шаблоны распределения ответственностей.
в случае использования
JsonUtilityчерез свойства с[field: SerializeField],получится json c backing fields вида:
{<Id>"k__BackingField":30518,<Name>"k__BackingField":"mesh"}что явно может ломать backend, если на нем не используется явнай парсер от Unity
Newtonsoft.Json же при сериализации property, имеет стандартный формат вида:
{"Id":30518,"Name":"mesh"}конкретно по 2 пункту, field-property
Стандартный Unity
JsonUtilityне умел сериализовать свойства и при вызове методаJsonUtility.ToJsonрезультатом был пустой json.Отпишите, если вдруг в какой-то версиях это добавили,
данный формат в Unity поддерживала только зависимость на
Newtonsoft.Jsonпо поводу обмазывания аннотация никто это делать не предлагает, это лишь примеры как включить статический анализ в конкретных местах,
никто не запрещает сделать один глобальный конфиг nullable или все доменную область Game.asmdef отметить данной аннотацией
для этого их и сделали необязательным, чтобы можно было потихоньку включить анализ лишь для отдельных частей,
в конретной практике скажу, что это удобно даже больше для UPM packages, где юзер получает внешнее API и ему явно указывается контракт
Для меня это просто банально выглядиь читаемый, чем подстановки [CanBeNull] аттрибуты, особенно в случае с сигнатурами.
Это стоит воспринимать как еще один помощник статическу анализаторому, а не панацею от всех бед, т.к даже в офф. гите MS, можно найти довольно уникальный кейсы когда анализатор даже не заметит NullRef, т.к с новыми версиями .Net они дорабатывают ее.
Cпс, за комменты
по поводу мотивиции, как раз указанн в самом вверху статьи 'Ключевые особенности' -
Поиск потенциальных мест с
NullReferencec 1-3 согласен, но данной контекс лишь изолированный пример, он служит только для показа nullable аннотаций
если структура координально не меняется, то да Unity автоматом биндит их (например обновляются ассеты или конфиги), но с некоторыми критами, как например при последней обнове Google SDKs, где порефакторили прям структуру package, придется распаковывать ручками в нужную папку
Недавно делал импортер который позволяет лить ассеты в обход root пути
.unitypackagehttps://user-images.githubusercontent.com/7010398/221209668-6680d81d-01b9-4071-9a5c-06f8d13e267a.mp4
Т.к при большом кол-во ассетов в родительская папка довольно быстро засоряется.
Как решали данный момент или оставляли все как есть, т.к многие разработчики все еще не переходят на UPM registry