Асинхронный итератор не выполняется не выполняется до начала перечисления. Поэтому исключение вылетит не в момент вызова метода, а только на await foreach. Это такой небольшой и понятный нюанс но просто нужно про него помнить.
Еще yield нельзя обернуть в try/catch. Разрешён только try/finally. То есть если к примеру в середине сессии случится разрыв соедниения с базой, то поймать и обработать ошибку прямо внутри итератора вокруг выдачи элементов не получится. Ловить приходится вокруг await foreach.
Нужно не забывать помечать CancellationToken параметром [EnumeratorCancellation] иначе в методы после компиляции пропихнется не раельный токен а CancellationToken.None. В целом, забыть сложно, так как компилятор отметит этот момент в коде. Но это тоже нюанс. В примерах как раз все отмечено как надо
Это не совсем про примеры из статьи. Но есть нюанс, что finally в асинхронном итераторе отработает даже если цикл перечисления прервать. Проще всего на вот таком коде это показать:
async IAsyncEnumerable<int> ReadAsync()
{
Console.WriteLine("открыли ресурс");
try
{
for (int i = 0; i < 100; i++)
{
await Task.Delay(10);
yield return i;
}
}
finally
{
// сюда попадём даже если потребитель прервётся на середине
Console.WriteLine("закрыли ресурс");
}
}
await foreach (var x in ReadAsync())
{
Console.WriteLine(x);
if (x == 3) break; // прерываем не доходя до конца цикла из 100 итераций и думаем что код из строчки 15 не выполнится
}
// Но оказывается что код выполнится, хотя вроде цикл мы прервали посередине
Вот такой вывод получится:
открыли ресурс
0
1
2
3
закрыли ресурс <- finally всё равно отработал
// Еще интересно что фактически выполнение вот этого метода
Console.WriteLine("закрыли ресурс");
// будет вызвано в контексте вот этого метода:
await foreach (var x in ReadAsync())
{
Console.WriteLine(x);
if (x == 3) break; // прерываем не доходя до конца цикла из 100 итераций и думаем что код из строчки 15 не выполнится
}
Да, это действительно хорошая штука, но вся прелесть в веб-сокетах, что это двухсторонняя связь! То есть вы можете гонять пакеты туда, сюда и вообще построить кучу взаимодействий на этой штуке.
Но для некоторых сценариев это абсолютный оверкилл. К примеру если вы стримите логи, то нет никакого смысла в двухсторонней связи. А чтобы настроить ws придется повозиться. Поднять SignalR чтобы у вас связь корректно работала на нескольких копиях приложения к примеру.
В общем да, веб-сокеты это топ, просто геморный и вот для описанных сценариев легче без него)
Спасибо за статью! Делаем примерно похожую штуку у себя. А такой вопрос, что использовали для доступа к моделькам? Просто по API или какой-то харнесс строили? Может дотнетовскую библиотечку какую-то?
И еще вопрос, а какая моделька/модельки использовалась? Ну и еще вопрос, покрывали как-то это все тестами, может тот же LLM as judge использовали?
Блин, вот тут тоже надо видимо тестировать все же. С этими зазвездёнными репами видимо со всеми такая проблема. Короче, потестирую тоже эту штуку пристально. Хотя вот вроде смотришь описание и такой: Ну вроде же логично, что если ты чутка вербозность подсократишь и вывода инструмента, то все должно стать лучше.
"13 автономных команд. Последние годы Mindbox рос на 30–40% в год. В итоге продукт стал настолько сложным, а команда такой большой, что мы выделили восемь продуктовых зон: платформы данных, рассылки, рекомендательные системы и так далее."
Да у меня и так получился суп из семи шагов))) Но во второй части, конечно всё будет))
Ну вот если про физический блокнот речь, то у меня с ними были проблемы, что по нему иногда Ctrl+F не сделаешь) Но тут дело вкуса. Кто-то умеет блокноты круто оформлять со всякими там стикерами. Я пробовал, но не прижилось.
Конечно в моде! Просто он не всем доступен/подходит/нравится. Телеграм-канал, это просто конкретная имплементация "чего-то, что могут посмотреть другие люди" Если вам нравится веб, то можно и веб – не проблема.
Так я как раз вот и думаю, что есть менее прожорливые штуки для профессионалов – просто записи в личных текстовых блогах. Не обязательно делать какой-то популярный, приносящий деньги блог. Иногда достаточно просто делиться небольшими штуками. Это и времени много не занимает, и кому-то экономит усилия.
Дело в том, что крутые гуру так и не решаются что-либо запостить из-за синдрома самозванца и страха, что в "комментах заклюют". Те же, кто находятся под эффектом Даннинга-Крюгера идут и пилят контент. В общем, я за то, чтобы раскачивать на делёжку опытом первых. При этом, я не против и вторых, если они развиваются, то почему бы и нет. Все мы делаем ошыбки ?
И очень круто узнать было про архитектуру самого Хекслета. Я бы ни в жизнь не додумался сделать решения на контейнерах, которые по коммиту просто запускаются. Я бы там шину как обычно поднял бы и пересылал в разных консьюмеров сырой код)
Очень крутая статья, но на деле постоянно забываешь что-то абстрагировать и, как итог, вместо итеративной интеграции, куча конфликтов) Это прям надо тренировать в себе, как мне кажется ?
Очень классная статья! Очень полезно было почитать, из каких компонентов вообще состоит диалог (условия, шаг, действия, стартовый триггер). Интересно, как реализовали в коде все эти штуки? Использовалась ли какая-то бибилиотека для стейт-машины или свою решили написать? Как хранятся флоу с учетом версионирования? Очень было бы инетресно про архитектуру решения почитать в ощем ?
Перегреть браузером не получится, но вот горячим воздухом от печи, вполне. Но это не самый важный аргумент, да. Смотрите, тут еще момент, что нужно убедить франчази купить дополнительное оборудование и научить это оборудование настраивать. Это не так просто, так как человек уже вложил в пиццерию 12-14 миллионов. А когда таких партнеров много, это становится еще более тяжелым делом.
Самый сложный фактор – это легаси. В 2012, когда эти экраны только только появлялись, Raspberry Pi только вышла в релиз и не особо могла похвастаться тем уровнем поддержки, производительности, количества доступных стабильных систем, которые есть сейчас. И вот на дворе 2019 год и нужно убедить франчази, что то, на что 7 предыдущих лет хватало телевизора, теперь нужно еще докупать какое-то устройство. Причем для каждого телевизора отдельно, а их в пиццерии 2-4, а иногда и больше и висят они, порой, на разных этажах. Конечно, можно так сделать, но тогда получится время раскатки решения на все 500+ пиццерий увеличится до нескольких лет, и все это время придется поддерживать оба решения.
Но честно скажу, мы тоже на самом деле в какой-то момент очень хотели взять малинку ? Возможно когд-анибудь к ней придем все же. Но на тот момент у нас можно сказать и выбора не было.
Выше уже отвечал на подобный вопрос, но, если коротко, то не хватило, по причинам того что нам нужно поддерживать общий стек и нам это помогло. К примеру новые темы для новых концепций удалось внести буквально за несколько минут, потому что стек общий и людям из других проектов понятно, куда смотреть.
Сейчас у нас 753 пиццерий в каждой по 2-4 таких экрана, в некоторых пиццериях больше. Где-то 2200 клиентов получается. У нас три пода не очень больших держат эту нагрузку. На них ограничение в 300 MHz стоит и по памяти они каждая ограничены в 512 Mb по памяти. Но они каждая используют сейчас около половины этих ресурсов. В общем в простейшую вдску может и влезла бы ?
Если широкими мазками, то да, все так, только постгресс не потребовался.? Ну и чтобы отобразить в браузере десять чисел, потребовалось пол часа. А чтобы отобразить уже десятки чисел на сотнях экранов и в нескольких версиях браузеров, да потребовалось месяц отлаживться и придумывать такие решения. ? Если у Вас есть идеи, как оптимизировать этот процесс, я бы почитал!
Да, нам нужно по экрану кликнуть, это ограничение браузера, иначе он ошибку выдает. Но у нас для открытия на полный экран, как раз нужен клик по экрану, так что убиваем двух зайцев одним кликом ?
Я там в выводах коротко написал про вариант к примеру с Raspberry Pi? Думаю, что с остальными стиками там тоже могут быть проблемы. Но я так скажу, что на малых масштабах, думаю, в целом Raspberry Pi тоже неплохое решение, но вот в нашем случае все же нет. Нужно чтобы телек не только поддерживаемым достаточно долгое время но и по экрану не выходил из строя.
Если вкратце, основные нюансы такие:
Асинхронный итератор не выполняется не выполняется до начала перечисления. Поэтому исключение вылетит не в момент вызова метода, а только на await foreach. Это такой небольшой и понятный нюанс но просто нужно про него помнить.
Еще yield нельзя обернуть в try/catch. Разрешён только try/finally. То есть если к примеру в середине сессии случится разрыв соедниения с базой, то поймать и обработать ошибку прямо внутри итератора вокруг выдачи элементов не получится. Ловить приходится вокруг await foreach.
Нужно не забывать помечать CancellationToken параметром [EnumeratorCancellation] иначе в методы после компиляции пропихнется не раельный токен а CancellationToken.None. В целом, забыть сложно, так как компилятор отметит этот момент в коде. Но это тоже нюанс. В примерах как раз все отмечено как надо
Это не совсем про примеры из статьи. Но есть нюанс, что finally в асинхронном итераторе отработает даже если цикл перечисления прервать. Проще всего на вот таком коде это показать:
Да, это действительно хорошая штука, но вся прелесть в веб-сокетах, что это двухсторонняя связь! То есть вы можете гонять пакеты туда, сюда и вообще построить кучу взаимодействий на этой штуке.
Но для некоторых сценариев это абсолютный оверкилл. К примеру если вы стримите логи, то нет никакого смысла в двухсторонней связи. А чтобы настроить ws придется повозиться. Поднять SignalR чтобы у вас связь корректно работала на нескольких копиях приложения к примеру.
В общем да, веб-сокеты это топ, просто геморный и вот для описанных сценариев легче без него)
Не подумал про это! Спасибо большое!
Спасибо большое! Такие отзывы мотивируют писать дальше)
Спасибо за статью! Делаем примерно похожую штуку у себя. А такой вопрос, что использовали для доступа к моделькам? Просто по API или какой-то харнесс строили? Может дотнетовскую библиотечку какую-то?
И еще вопрос, а какая моделька/модельки использовалась? Ну и еще вопрос, покрывали как-то это все тестами, может тот же LLM as judge использовали?
Ну это жёстко. Я если честно, не думал, что эта штука как-то так бездумно это все режет( Потестирую на дотнете тоже.
Спасибо!
Блин, вот тут тоже надо видимо тестировать все же. С этими зазвездёнными репами видимо со всеми такая проблема. Короче, потестирую тоже эту штуку пристально. Хотя вот вроде смотришь описание и такой: Ну вроде же логично, что если ты чутка вербозность подсократишь и вывода инструмента, то все должно стать лучше.
"13 автономных команд. Последние годы Mindbox рос на 30–40% в год. В итоге продукт стал настолько сложным, а команда такой большой, что мы выделили восемь продуктовых зон: платформы данных, рассылки, рекомендательные системы и так далее."
А как выделяли зоны?
Да у меня и так получился суп из семи шагов))) Но во второй части, конечно всё будет))
Ну вот если про физический блокнот речь, то у меня с ними были проблемы, что по нему иногда Ctrl+F не сделаешь) Но тут дело вкуса. Кто-то умеет блокноты круто оформлять со всякими там стикерами. Я пробовал, но не прижилось.
Конечно в моде! Просто он не всем доступен/подходит/нравится. Телеграм-канал, это просто конкретная имплементация "чего-то, что могут посмотреть другие люди" Если вам нравится веб, то можно и веб – не проблема.
Так я как раз вот и думаю, что есть менее прожорливые штуки для профессионалов – просто записи в личных текстовых блогах. Не обязательно делать какой-то популярный, приносящий деньги блог. Иногда достаточно просто делиться небольшими штуками. Это и времени много не занимает, и кому-то экономит усилия.
Дело в том, что крутые гуру так и не решаются что-либо запостить из-за синдрома самозванца и страха, что в "комментах заклюют". Те же, кто находятся под эффектом Даннинга-Крюгера идут и пилят контент. В общем, я за то, чтобы раскачивать на делёжку опытом первых. При этом, я не против и вторых, если они развиваются, то почему бы и нет. Все мы делаем ошыбки ?
Топовая статья получилась!
Как-то тоже игрался с онлайн-компиляцией, но я что-то гораздо более громоздкое видимо использовал, получилось вот так: https://gist.github.com/Undermove/719cef1796bc0e6a5aab911e3f5bdab7#file-gistfile1-txt
И очень круто узнать было про архитектуру самого Хекслета. Я бы ни в жизнь не додумался сделать решения на контейнерах, которые по коммиту просто запускаются. Я бы там шину как обычно поднял бы и пересылал в разных консьюмеров сырой код)
Очень крутая статья, но на деле постоянно забываешь что-то абстрагировать и, как итог, вместо итеративной интеграции, куча конфликтов) Это прям надо тренировать в себе, как мне кажется ?
Очень классная статья! Очень полезно было почитать, из каких компонентов вообще состоит диалог (условия, шаг, действия, стартовый триггер). Интересно, как реализовали в коде все эти штуки? Использовалась ли какая-то бибилиотека для стейт-машины или свою решили написать? Как хранятся флоу с учетом версионирования? Очень было бы инетресно про архитектуру решения почитать в ощем ?
Перегреть браузером не получится, но вот горячим воздухом от печи, вполне. Но это не самый важный аргумент, да. Смотрите, тут еще момент, что нужно убедить франчази купить дополнительное оборудование и научить это оборудование настраивать. Это не так просто, так как человек уже вложил в пиццерию 12-14 миллионов. А когда таких партнеров много, это становится еще более тяжелым делом.
Самый сложный фактор – это легаси. В 2012, когда эти экраны только только появлялись, Raspberry Pi только вышла в релиз и не особо могла похвастаться тем уровнем поддержки, производительности, количества доступных стабильных систем, которые есть сейчас. И вот на дворе 2019 год и нужно убедить франчази, что то, на что 7 предыдущих лет хватало телевизора, теперь нужно еще докупать какое-то устройство. Причем для каждого телевизора отдельно, а их в пиццерии 2-4, а иногда и больше и висят они, порой, на разных этажах. Конечно, можно так сделать, но тогда получится время раскатки решения на все 500+ пиццерий увеличится до нескольких лет, и все это время придется поддерживать оба решения.
Но честно скажу, мы тоже на самом деле в какой-то момент очень хотели взять малинку ? Возможно когд-анибудь к ней придем все же. Но на тот момент у нас можно сказать и выбора не было.
Выше уже отвечал на подобный вопрос, но, если коротко, то не хватило, по причинам того что нам нужно поддерживать общий стек и нам это помогло. К примеру новые темы для новых концепций удалось внести буквально за несколько минут, потому что стек общий и людям из других проектов понятно, куда смотреть.
Сейчас у нас 753 пиццерий в каждой по 2-4 таких экрана, в некоторых пиццериях больше. Где-то 2200 клиентов получается. У нас три пода не очень больших держат эту нагрузку. На них ограничение в 300 MHz стоит и по памяти они каждая ограничены в 512 Mb по памяти. Но они каждая используют сейчас около половины этих ресурсов. В общем в простейшую вдску может и влезла бы ?
Если широкими мазками, то да, все так, только постгресс не потребовался.? Ну и чтобы отобразить в браузере десять чисел, потребовалось пол часа. А чтобы отобразить уже десятки чисел на сотнях экранов и в нескольких версиях браузеров, да потребовалось месяц отлаживться и придумывать такие решения. ? Если у Вас есть идеи, как оптимизировать этот процесс, я бы почитал!
Да, нам нужно по экрану кликнуть, это ограничение браузера, иначе он ошибку выдает. Но у нас для открытия на полный экран, как раз нужен клик по экрану, так что убиваем двух зайцев одним кликом ?
Я там в выводах коротко написал про вариант к примеру с Raspberry Pi? Думаю, что с остальными стиками там тоже могут быть проблемы. Но я так скажу, что на малых масштабах, думаю, в целом Raspberry Pi тоже неплохое решение, но вот в нашем случае все же нет. Нужно чтобы телек не только поддерживаемым достаточно долгое время но и по экрану не выходил из строя.