Я прямо сейчас пишу большое дерево поведения для проекта и BT ни разу не панацея. Да, ряд плюсов имеется, но Боже упаси реализовывать такую дуру для каких нибудь аркад да roguelike. Отсутствие Transition замещается NodeState, с которым конечно проще работать, но потребуется написать и распихать не один декоратор. С разделяемыми ресурсами проблемы остаются, вообще главное отличие дерева - его высокий уровень абстракции и масштабируемости, и из-за этого отличия местами приходится накостыливать по полной, либо 2 вариант - дерево имеет тонну зависимостей, и при каждой новой фиче разработчик умывается своей кровью.
Опыт строительства инфраструктурных объектов во внеземных условиях вполне имеет смысл. Как минимум - обкатать будущие проекты на Марсе, если человечество дотянет до его колонизации, конечно.
Я читал вашу статью и понял что вы хотели донести, но как лично я вижу это: Есть Клири (надеюсь правильная транслитерация) и есть, допустим, Metanit. Первый говорит что асинхронность не создает потоки вообще никогда (хотя на самом деле, если прокликать его сайт, то можно наткнуться и на await Task.Run() в частных случаях), а второй говорит полностью обратное. И тут есть момент: лучше человеку вбить в голову что асинхронность != потоки, чем вбить обратное. Объясню на примере: я сам учебный план строил по Metanit, просто я разбавлял его поверхностность конкретикой с msdn и пр., и я помню, что асинхронность у него идет сразу после TPL. Таким образом, учитывая, что его статьи написаны для начинающих, и написаны слишком уж коротко, получается такой вопрос: а зачем оно надо, когда задачу можно решать синхронно-мультипоточно. Если же человеку сказать обратное, то у него как минимум возникнет вопрос "а как тогда это работает", и дальше он уже сам нагуглит и про контексты и про configureAwait и про UI/ASP потоки. Конечно, лучше всего написать простыню текста, объясняющего все азы async/await, но это работа для Майкрософт (хотя, надо признать, их async/await написан вполне человеческим языком, да и половина статей там за авторством Клири).
Асинхронные методы выполняются в отдельных потоках
Не буду говорить за все остальное, но async/await блок провальный. Буквально с первой же фразы - асинхронность, это чуть ли не противоположность многопоточности, кроме пары исключений.
Пока я писал ответ на этот пост, решил сделать свой с ссылками на материалы для изучения. И я даже знаю корень проблемы - Metanit. Сайт прекрасный, Евгений молодец, но без связки с MSDN это тикающая бомба. И в теме асинхронности она взорвалась, отсюда и вышеприведенная цитата, и Thread.Sleep() в примерах кода. Без негатива, но лучше незнание, чем лжеучение.
Дайте этому Глебу Воронцову уже скачать WeChat. Ситуация напоминает поговорку "когда ты молоток..", только в данном случае все вокруг кажется гвоздями в гроб площадки, по крайней мере дезигна.
Да, но есть одна мудрость: если нужно сделать Task.Run(), значит код не требует async/await. Т.е. если у нас операция CPU-bound и нам нужно распараллелить работу - async/await здесь не потребуется.
ConfigureAwait обычно используется в рамках оптимизации, когда мы точно уверены, что продолжение async не потребует, например, получать доступ к UI потоку для UI приложений соответственно, т.е. когда захват контекста и размещение в нем континьюации, идущей после await - бессмысленная операция. В таком случае не захватывать контекст выйдет дешевле. Ну и да, континьюацию подхватит поток из пула потоков при false.
Название хакатона как философия жизни..
Я прямо сейчас пишу большое дерево поведения для проекта и BT ни разу не панацея. Да, ряд плюсов имеется, но Боже упаси реализовывать такую дуру для каких нибудь аркад да roguelike. Отсутствие Transition замещается NodeState, с которым конечно проще работать, но потребуется написать и распихать не один декоратор. С разделяемыми ресурсами проблемы остаются, вообще главное отличие дерева - его высокий уровень абстракции и масштабируемости, и из-за этого отличия местами приходится накостыливать по полной, либо 2 вариант - дерево имеет тонну зависимостей, и при каждой новой фиче разработчик умывается своей кровью.
А что с Win+Shift+S?
А разработчики игры "Смута" не уронили отварную сосиску случаем?
Кто слил в бд яндекса мое резюме?
Обучашки +
Задачки +
Объясняшки +
Объясняшки похуже но попонятнее
Млять кто эти названия придумывает... Они или настолько увлечены разработкой, что нет минуты выслушать идеи по названиям, или им настолько насрать
Да я тоже купился поначалу. И поймал себя на мысли, что лет 5 назад не воспринял бы всерьез.
Пожалуй, я сегодня постараюсь не заходить на сей сайт..
Тьфу ты
А потом ещё и аббревиатуру можно придумать чтоб по классике "росвросгосспрос", красота
О, а вы тоже вчера на Ютуб через ТВ зашли?
Опыт строительства инфраструктурных объектов во внеземных условиях вполне имеет смысл. Как минимум - обкатать будущие проекты на Марсе, если человечество дотянет до его колонизации, конечно.
Отвлекся от работы на эту статью...
Не совсем понял про SQL Server & Xamarin
Я читал вашу статью и понял что вы хотели донести, но как лично я вижу это:
Есть Клири (надеюсь правильная транслитерация) и есть, допустим, Metanit. Первый говорит что асинхронность не создает потоки вообще никогда (хотя на самом деле, если прокликать его сайт, то можно наткнуться и на await Task.Run() в частных случаях), а второй говорит полностью обратное.
И тут есть момент: лучше человеку вбить в голову что асинхронность != потоки, чем вбить обратное. Объясню на примере: я сам учебный план строил по Metanit, просто я разбавлял его поверхностность конкретикой с msdn и пр., и я помню, что асинхронность у него идет сразу после TPL. Таким образом, учитывая, что его статьи написаны для начинающих, и написаны слишком уж коротко, получается такой вопрос: а зачем оно надо, когда задачу можно решать синхронно-мультипоточно. Если же человеку сказать обратное, то у него как минимум возникнет вопрос "а как тогда это работает", и дальше он уже сам нагуглит и про контексты и про configureAwait и про UI/ASP потоки.
Конечно, лучше всего написать простыню текста, объясняющего все азы async/await, но это работа для Майкрософт (хотя, надо признать, их async/await написан вполне человеческим языком, да и половина статей там за авторством Клири).
Окинув взглядом этот пост еще раз я понял - бездушная копипаста. Это даже не GPT, сурс.
Не буду говорить за все остальное, но async/await блок провальный. Буквально с первой же фразы - асинхронность, это чуть ли не противоположность многопоточности, кроме пары исключений.
Пока я писал ответ на этот пост, решил сделать свой с ссылками на материалы для изучения.
И я даже знаю корень проблемы - Metanit. Сайт прекрасный, Евгений молодец, но без связки с MSDN это тикающая бомба. И в теме асинхронности она взорвалась, отсюда и вышеприведенная цитата, и Thread.Sleep() в примерах кода. Без негатива, но лучше незнание, чем лжеучение.
Дайте этому Глебу Воронцову уже скачать WeChat. Ситуация напоминает поговорку "когда ты молоток..", только в данном случае все вокруг кажется гвоздями в гроб площадки, по крайней мере дезигна.
Да, но есть одна мудрость: если нужно сделать Task.Run(), значит код не требует async/await. Т.е. если у нас операция CPU-bound и нам нужно распараллелить работу - async/await здесь не потребуется.
ConfigureAwait обычно используется в рамках оптимизации, когда мы точно уверены, что продолжение async не потребует, например, получать доступ к UI потоку для UI приложений соответственно, т.е. когда захват контекста и размещение в нем континьюации, идущей после await - бессмысленная операция. В таком случае не захватывать контекст выйдет дешевле. Ну и да, континьюацию подхватит поток из пула потоков при false.