Обычно юзается addTo при подписках. То есть, простое правило: написал subscribe, пиши addTo. В р3 запись выглядит так: ...Subscribe().AddTo(ref disposable); Добавился реф.
@@savaslive Хмм, почему-то AddTo не хочет принимать IDisposable, нет такой перегрузки метода. Вместо этого передал туда CompositeDisposable, причем без ref.
А как эта штука устроена под капотом? Как сильно это может повлиять на производительность? Если куча скалярных пропертей объектов сами становятся объектами?
Observable это ссылочной тип, несомненно, и он придуман не для того, чтобы создавать объекты каждый кадр. Нет, создал и пользуйся. Сама задача (уведомление об изменении) не подходит под вопрос оптимизации, ты либо используешь события, либо обёртка, либо сравнения и т.д.
Здравствуйте, как вы боролись с выгоранием во время учёбы? Каждый раз после того как позанимаюсь , чувствую себя самозванцем и думаю что стоит все бросить. С трудом перебарываю такие мысли
Извини за непрошенный совет, просто меня тоже посещают подобные мысли. Я в таких случаях просто говорю себе про свой код: "да пофиг, работает - и ладно" 😁 В конце концов, самое первое и главное требование к коду, которое всегда было, есть и будет - это чтобы код корректно выполнял свою работу. При том, что я, само собой, не пишу "на отъе..ись", а стараюсь каждый раз выжимать из себя по максимуму качества, на которое способен. Но всё равно же путь к профессионализму лежит через мегабайты говнокода, - это неизбежность 😁 Еще можно вспоминать (и даже просматривать) код, который ты писал полгода или год назад. Там сразу первые мысли: "Фу, ну и навалил же я тогда кринжа, сейчас бы я ни в жизнь не написал такое убожество, я бы сделал вот так и так, - это было бы намного лучше". И вторая мысль: "хм, ну, значит, прогресс-то есть, - и, судя по всему, немаленький". Главное - не броситься тут же переписывать его, чтобы не тратить время зря 😁 Ну и, в целом, поскольку "синдром самозванца" очень часто меня беспокоит вообще абсолютно во сферах жизни - далеко не только в программировании 😁- у меня сложилась такая своеобразная тактика борьбы с ним. Мой внутренний голос часто требует от меня "рассудить" ситуацию по "справедливости" типа "А достоин ли я вообще того-то и того-то?" И я научился быстро "включать циника" и переключаться на мысли типа: "Мне всё равно: если я смог что-то себе урвать, - значит, я это заслужил. И неважно, справедливо это или нет." Как-то так, в общем. Еще раз извини за непрошенный совет.
@@igor_mutny В дополнение. Сначала надо заставить свой код работать, потом уже приводить его к адекватному виду. Так всегда было и есть, попытка написать сразу идеальную архитектуру на боевом проекте приведет к выгоранию, медленной разработке, увольнению (если это в компании), потому что там основная задача - закрывать таски, а не тешить свое эго
@@bigbimba2448 а существует ли она, эта идеальная архитектура? А то есть подозрение, что это что-то наподобие идеальной сферы. Типа можно какой-нибудь деревянный шарик шлифовать до бесконечности, но он все равно никогда не станет идеальной сферой. Рано или поздно всё равно нужно махнуть рукой и сказать: "Ладно, так сойдет!" 😁
Выгорание - вещь стремная. Я много лет страдал от выгорания, и пару лет исследовал эту проблему. Пришёл к выводу, что оно происходит, когда долго не видишь результата. То есть делаешь чёт делаешь, не знаешь, правильно или нет, плюс вообще не понятно, когда кончится все это и все, уже ничего не хочешь. В общем, для профилактики выгорания, сокращаешь задачки: и общее количество, и сами задачки по продолжительности. Например, вместо большой системы диалогов, перепрыгиваешь на вёрстку UI, делаешь пару кнопок и довольный идёшь отдыхать. А система диалогов потом доделать, когда состояние востановится
@@shockkxd редко, но используется. Реактивные свойства в целом уменьшают надобность в отдельных событиях, но не совсем их убирают. Плюс сохраняется консистентность для подписки-отписки, что лучше читается
Я установил все точно так же как в видео, но почему то IDisposable не видит в R3, IDE предлагает только из библиотеки System.IDisposable, нормально ли использовать для R3 IDisposable из System?
@@gamedevlavka просто из комментариев было про AddTo(ref disposable), попробовал с IDisposable из System, у меня это не сработало. Ну да ладно, думаю это не так важно. Спасибо тебе за то что ты делаешь) Я по учебе делаю игру параллельно с твоим проектом Пилим Игру, ты мне очень помогаешь! Надеюсь доделаю и поделюсь в ТавернеРазработчика)
@@issatay8876 и R3 и UniTask существуют для одной задачи - асинхронное программирование, но работают совершенно по разному. Так что концептуально, да, но эти видео не совсем добавят понимание
![Quando Rondo - Life Goes On [Official Music Video]](http://i.ytimg.com/vi/eIf3fhMXAow/mqdefault.jpg)
Спасибо за видео! Очень интересно про реактивное программирование. А также про Nuget для Unity )
Огромное спасибо! Канал очень помогает развиваться.
Спасибо большое за видео
Обычно юзается addTo при подписках. То есть, простое правило: написал subscribe, пиши addTo. В р3 запись выглядит так: ...Subscribe().AddTo(ref disposable);
Добавился реф.
Да, кстати, совсем забыл об этом
это значит, что слева от выражения не обязательно приваивать к IDisposable, вместо этого addTo?
@@shockkxd да, это взаимозаменяемые варианты. С addTo покороче, компактнее.
@@savaslive Хмм, почему-то AddTo не хочет принимать IDisposable, нет такой перегрузки метода. Вместо этого передал туда CompositeDisposable, причем без ref.
@@shockkxd у меня так-же
Ура! Новый видос
Спасибо!
А как эта штука устроена под капотом? Как сильно это может повлиять на производительность? Если куча скалярных пропертей объектов сами становятся объектами?
Observable это ссылочной тип, несомненно, и он придуман не для того, чтобы создавать объекты каждый кадр. Нет, создал и пользуйся. Сама задача (уведомление об изменении) не подходит под вопрос оптимизации, ты либо используешь события, либо обёртка, либо сравнения и т.д.
Не рассмотрено ReactiveCommand :(
Все то вы знаете)
♥
Здравствуйте, как вы боролись с выгоранием во время учёбы? Каждый раз после того как позанимаюсь , чувствую себя самозванцем и думаю что стоит все бросить. С трудом перебарываю такие мысли
Извини за непрошенный совет, просто меня тоже посещают подобные мысли.
Я в таких случаях просто говорю себе про свой код: "да пофиг, работает - и ладно" 😁 В конце концов, самое первое и главное требование к коду, которое всегда было, есть и будет - это чтобы код корректно выполнял свою работу. При том, что я, само собой, не пишу "на отъе..ись", а стараюсь каждый раз выжимать из себя по максимуму качества, на которое способен. Но всё равно же путь к профессионализму лежит через мегабайты говнокода, - это неизбежность 😁
Еще можно вспоминать (и даже просматривать) код, который ты писал полгода или год назад. Там сразу первые мысли: "Фу, ну и навалил же я тогда кринжа, сейчас бы я ни в жизнь не написал такое убожество, я бы сделал вот так и так, - это было бы намного лучше". И вторая мысль: "хм, ну, значит, прогресс-то есть, - и, судя по всему, немаленький". Главное - не броситься тут же переписывать его, чтобы не тратить время зря 😁
Ну и, в целом, поскольку "синдром самозванца" очень часто меня беспокоит вообще абсолютно во сферах жизни - далеко не только в программировании 😁- у меня сложилась такая своеобразная тактика борьбы с ним. Мой внутренний голос часто требует от меня "рассудить" ситуацию по "справедливости" типа "А достоин ли я вообще того-то и того-то?" И я научился быстро "включать циника" и переключаться на мысли типа: "Мне всё равно: если я смог что-то себе урвать, - значит, я это заслужил. И неважно, справедливо это или нет."
Как-то так, в общем. Еще раз извини за непрошенный совет.
@@igor_mutny В дополнение. Сначала надо заставить свой код работать, потом уже приводить его к адекватному виду. Так всегда было и есть, попытка написать сразу идеальную архитектуру на боевом проекте приведет к выгоранию, медленной разработке, увольнению (если это в компании), потому что там основная задача - закрывать таски, а не тешить свое эго
@@bigbimba2448 а существует ли она, эта идеальная архитектура? А то есть подозрение, что это что-то наподобие идеальной сферы. Типа можно какой-нибудь деревянный шарик шлифовать до бесконечности, но он все равно никогда не станет идеальной сферой. Рано или поздно всё равно нужно махнуть рукой и сказать: "Ладно, так сойдет!" 😁
Выгорание - вещь стремная. Я много лет страдал от выгорания, и пару лет исследовал эту проблему. Пришёл к выводу, что оно происходит, когда долго не видишь результата. То есть делаешь чёт делаешь, не знаешь, правильно или нет, плюс вообще не понятно, когда кончится все это и все, уже ничего не хочешь.
В общем, для профилактики выгорания, сокращаешь задачки: и общее количество, и сами задачки по продолжительности. Например, вместо большой системы диалогов, перепрыгиваешь на вёрстку UI, делаешь пару кнопок и довольный идёшь отдыхать. А система диалогов потом доделать, когда состояние востановится
@@gamedevlavka спасибо за ваш совет!
Я так понимаю, пример №4 не особо используется?
Ибо, зачем это, если это буквально шарповский ивент?
@@shockkxd редко, но используется. Реактивные свойства в целом уменьшают надобность в отдельных событиях, но не совсем их убирают. Плюс сохраняется консистентность для подписки-отписки, что лучше читается
Я установил все точно так же как в видео, но почему то IDisposable не видит в R3, IDE предлагает только из библиотеки System.IDisposable, нормально ли использовать для R3 IDisposable из System?
@@Erosrolf так так и должно быть) IDisposable из System используется
@@gamedevlavka просто из комментариев было про AddTo(ref disposable), попробовал с IDisposable из System, у меня это не сработало. Ну да ладно, думаю это не так важно. Спасибо тебе за то что ты делаешь) Я по учебе делаю игру параллельно с твоим проектом Пилим Игру, ты мне очень помогаешь! Надеюсь доделаю и поделюсь в ТавернеРазработчика)
Только у меня звук немного шипит?
Можно ли R3 заменить UnitTask?
@@issatay8876 и R3 и UniTask существуют для одной задачи - асинхронное программирование, но работают совершенно по разному. Так что концептуально, да, но эти видео не совсем добавят понимание
я оба плагина в своих проектах юзают, сочитаются они великолепно