aks2dio: Unity и геймдев
Про GameDev, разработку на Unity и C#, менеджмент, образование, менторство и карьеру в целом.
Привет! Пожалуйста, рад поделиться полезным контентом 🎩
Все значимые кейсы последних 3-х лёт находятся под NDA.
Моя остальная карьерная информация доступна на LinkedIn: https://www.linkedin.com/in/antonkerp/
в том, что у вас статья не открывается
неверный ответ
Это не вопрос плагинов — это другой уровень взаимодействия.
Они сделали отличный "велосипед", за который лично я готов платить и довольный плачу уже много лет.
При этом разбесплатный Visual Studio и разоткрытый VS Code с его бесконечными форками у меня не вызывают желания ими пользоваться лишь потому, что ребята из JetBrains решили заработать на своём же продукте.
У меня есть возможность платить за удобный инструмент, который предоставляет мне возможность зарабатывать эффективнее, больше и с кайфом.
Никто не отбирает возможность пользоваться другими решениями. И никто не заставляет пользоваться продуктами JetBrains.
Сделает Сбер инструмент и для моих задач — посмотрим, посравниваем. Пока его нет. Jetbrains "дарить" свой никому не обязан.
Ну и GigaCode будет платным. Это официальная информация. GigaIDE при должной популярности тоже может получить проприетарную лицензию. Все хотят зарабатывать на своих продуктах и это нормально. Так что видимо в список контор пи***в ожидается пополнение.
С другой стороны – Rider это не про язык, это скорее про платформы.
Он предоставляет одни из лучших инструментов для разработки под .Net, Unity, Unreal Engine и Godot.
С Unity там и вовсе теснейшая интеграция, альтернатив которой попросту нет.
Есть Visual Studio, которая на многих дудах игрец, но и тесной интеграцией с движками она похвастать не может. И в той версии мультивселенной, где существует Rider, это большой рэд флэг для проф разработки. Т.к. вопрос уже даже не про простое удобство и скорость, а про повышенную контролируемость и вытекающую из этого стабильность.
С другими продуктами JetBrains наверняка схожая ситуация.
Первое — это стоимость. Он дороже в два раза большинства обычных ассистентов.
Второе — отсутствие нормальных плагинов для Jetbrains, которые бы оправдывали стоимость и были удобными.
Сам Cursor - это отдельный форк VS Code. Для профессиональной Unity-разработки Rider в качестве IDE заменить пока нечем. Производные VS Code — последнее, что стоило бы для этих целей использовать.
Работать с двумя активными IDE, чтобы в одной вайбкодить, а в другой делать всё остальное за $20 — экспириенс не для всех.
GigaIDE — не замена Rider. А GigaCode как отдельный плагин в контексте C# сильно слабее аналогов из-за отсутствия RAG
Тем не менее, сидим всей командой в РФ, продолжаем пользоваться всем стеком от JetBrains и в ус не дуем 🙂
В статьях по разработке встречал. Но в реальных проектах — пока не попадался. Будет повод попробовать самостоятельно на будущих новых 🤖
Про asmref'ы я даже успел написать раздел, но в общую канву, именно к итоговому примеру, они плохо подошли — решил не пытаться и не перегружать публикацию.
Пример с MemoryProfiler интересный — спасибо за наводку. В таком сценарии я их не использовал — будет интересно попробовать и сложить в копилку кейсов 👍
Тоже часто слышу от коллег, которые работают с графикой, что им приходится прибегать к таким хакам. Да, это интересный кейс. Пожалуй, будет повод всё же самому туда нырнуть осмотреться — спасибо за идею 💡
И человек ли??
Главное, чтобы это всех устраивало и не создавало вопросов.
Чаще всего сквош съедает кучу полезного контекста, который одним комментарием уже не получится описать. Если в ветке была аккуратненькая история — жалко её терять.
С другой стороны, если в ветке было множество не систематизированных коммитов, которые даже через Interactive Rebase полишить дорого, то, конечно, сквош будет более предпочтительным.
Благодарю за дополнение, полностью согласен — отличные советы 💯
аааа... я думал, сова 🦉
По результатам спринта составлять отчёты удобнее по фичам. Но непосредственно в работе мне постоянно приходится смотреть историю изменений по Selection'ам в коде, там уже важен более подробный контекст.
На больших долгих проектах важно понимать, почему на определённом месте происходят определённые действия. И вместо тысячи обращений к авторам, которых может уже и не быть в команде, история может ответить на большинство вопросов.
Если что-то интересное на просторах сети попадётся — обязательно поделюсь.
Пока что в этом направлении опыт встречается везде +- одинаковый, в т.ч. и в моей практике.
В гите по Git LFS хранится только контент под интеграцию. wip-контент — в облачных хранилищах или в SVN (или Figma, в случае с 2D-артом).
А кто спрашивает
Когда за собой замечаю такое, то делаю Stash и повторяю проделанное в несколько законченных шагов. Очень дисциплинирует )
И современные GUI позволяют удобно построчно выбивать правки из файлов, что в комбинации с amend в некоторых случаях позволяет разбить коммит на несколько.
Ветвление + Interactive Rebase перед слиянием помогают поддерживать порядок и проводить ретроспективу проделанной работы. Для соло разработки так же хорошо работают те же правила, что и для команды.
Это было бы очень классно 🤩
Добавляю статьи заочно в "вишлист" 📝
Если шутки в сторону оставить, то конечно не имеет смысла переусердствовать там, где этого не нужно.
Всё же зависит от эффективности и масштаба. По мере роста продуктов времени на ручное оперирование уходит всё больше, как и усложняются сами процессы, что повышает шанс на ошибку.
Какой-то момент станет переломным, когда настройка инфраструктуры под CI/CD становится необходимостью для дальнейшего "выживания".
Когда без этой инфраструктуры эффективность не страдает, то и тратить на это усилия будет нецелесообразным.
Бесконечно😅
На слове "ручной" где-то сморщился DevOps-инженер 😅
Ну единица измерения активности радионуклида же 🫠
Вообще мне сложно его защищать :)
В практике я уже долгое время обхожусь без этого всего.
Прям вот каких-то кейсов, что оно нужно — у меня нет.
Я видел много примеров неудачного применения. И я скорее больше сторонник того, чтобы этим лишний раз не пользоваться.
Но я и встречал коллег, которые умели очень аккуратно и элегантно его встраивать. Ничего кроме этой элегантности, по сути, оно не привносило. Но если ставить целью "упростить оформление" — такими средствами это достигается. И чтобы такое делать — требуется "набивать шишки" и накапливать удачные сценарии применения.
В посте эти условия обозначены — необходимость работы с данными именно как с потоками и потребность в их фильтрации и нетривиальной обработке.
Конкретные примеры привести сложно, т.к. у всех "болевой порог" разный.
Rx не является незаменимым инструментом, без которого невозможно жить. Это вспомогательный инструмент. Он не поможет решить что-то, что без него почему-то не решается. Он лишь поможет в каких-то ситуациях оформить решение элегантнее, понятнее, проще, короче, удобнее и т.д. Или наоборот усугубит.
Поэтому в первую очередь его полезность и применимость познаётся в сравнении. Если где-то профита получилось больше, чем неудобств — вот и кейс в копилку.
Попробую всё-таки в пример. Если вдруг начинает появляться какой-то слишком сложный обработчик, который внутри имеет кучи всяческих условий или пытается заиметь какое-то более глобальное состояние, и это не косяк проектирования, то в таком случае Rx вероятно бы смог помочь оформить это чуть удобнее.
Там, где нужны просто евенты, "простые советские" евенты подходят лучше всего 💯
Они не противопоставляются друг другу и не являются частным случаем друг друга — просто они отвечают за разные аспекты общей парадигмы разработки, хоть и отлично друг друга дополняют. Хотя могут быть использованы и отдельно друг от друга.
Асинхронность может работать как в рамках одного потока, так и применительно к отдельным потокам.
Как и работа с многопоточностью может быть реализована и асинхронно, и синхронно, с полной блокировкой исполнения ожидающего потока.
Асинхронность, как верно было замечено, лишь абстракция для неблокирующего исполнения кода. В своей внутренней реализации – простая машина состояний, которая умеет прерывать исполнение и возвращаться к нему.
Многопоточность – попытка в параллелизм и увеличение производительности.
В моменте, когда результаты работы потоков нужно синхронизировать, появляется вопрос в том, как это сделать. И одно из самых удачных, но не обязательных, решений этого вопроса – использование асинхронного ожидания.