На прошлых выходных был на конференции по экосистеме .Net, к которой относится мой основной язык - c#: DotNext.
В первый день прослушал 4 доклада, во второй - 5.
Далее будет серия постов по прослушанным докладам, с тегом #dotnext@eshu_coding
#conf
В первый день прослушал 4 доклада, во второй - 5.
Далее будет серия постов по прослушанным докладам, с тегом #dotnext@eshu_coding
#conf
#dotnext, день 1, доклад 1.
Workflow архитектура сервисов в .Net
Узнал, что в природе существует отдельно выделяемая workflow-архитектура - построение приложения вокруг определенных путей, которые проходит в своем жизненном цикле бизнес-сущность.
Самый простой пример - заявление, курсирующие между начальникам, оставляющими визу или завораживающими на доработку.
Раньше подобные вещи я решал через конечные автоматы, описывая логику в переходах между состояниями, решать ту же проблему через описание пути выглядит достаточно интересным ходом.
Также в докладе рассказали о готовых либах, реализующих workflow в c#. По случаю может и пригодится.
P.S. Отдельным бонусом к либам идёт возможность генерации блок схемы наших workflow
#conf
Workflow архитектура сервисов в .Net
Узнал, что в природе существует отдельно выделяемая workflow-архитектура - построение приложения вокруг определенных путей, которые проходит в своем жизненном цикле бизнес-сущность.
Самый простой пример - заявление, курсирующие между начальникам, оставляющими визу или завораживающими на доработку.
Раньше подобные вещи я решал через конечные автоматы, описывая логику в переходах между состояниями, решать ту же проблему через описание пути выглядит достаточно интересным ходом.
Также в докладе рассказали о готовых либах, реализующих workflow в c#. По случаю может и пригодится.
P.S. Отдельным бонусом к либам идёт возможность генерации блок схемы наших workflow
#conf
👍2
#dotnext, день 1, доклад 2.
Когда 100% cpu ничего не значит.
Доклад был посвящен некоторым нюансам, понижающим производительность приложений когда в коде все нормально.
Основная полезная информация, которую я вынес - о механизме устройства конвейера виртуальных машин, за мощности которых мы платим хостерам.
Если наш сервис постоянно потребляет мизерное количество ресурсов, хостер, в рамках оптимизации, может засунуть его миллионной виртуалкой на запасной сервер.
И тут к нам приходит лавинообразная нагрузка. Реально выделенных (а не тех, за которые уполчено) выделенных ресурсов нам перестает хватать, автоматика хостера пытается как-то выдать нам оплаченное и теперь востребованное - и тратит на это время, в течение которого наш сервис может захлёбываться на ровном месте.
Другой интересный момент - взятие лишнего десятка ядер CPU, как раз таки на такой случай, не спасает, а наоборот делает хуже. Чем больше запрашиваемые нами ресурсы - тем сложнее приткнуть нашу виртуалку туда, где они есть.
Ещё было занятно про k8s и гармоничные настройки потребления памяти, но кубером я пока не проникся, потому прошло мимо.
#conf
Когда 100% cpu ничего не значит.
Доклад был посвящен некоторым нюансам, понижающим производительность приложений когда в коде все нормально.
Основная полезная информация, которую я вынес - о механизме устройства конвейера виртуальных машин, за мощности которых мы платим хостерам.
Если наш сервис постоянно потребляет мизерное количество ресурсов, хостер, в рамках оптимизации, может засунуть его миллионной виртуалкой на запасной сервер.
И тут к нам приходит лавинообразная нагрузка. Реально выделенных (а не тех, за которые уполчено) выделенных ресурсов нам перестает хватать, автоматика хостера пытается как-то выдать нам оплаченное и теперь востребованное - и тратит на это время, в течение которого наш сервис может захлёбываться на ровном месте.
Другой интересный момент - взятие лишнего десятка ядер CPU, как раз таки на такой случай, не спасает, а наоборот делает хуже. Чем больше запрашиваемые нами ресурсы - тем сложнее приткнуть нашу виртуалку туда, где они есть.
Ещё было занятно про k8s и гармоничные настройки потребления памяти, но кубером я пока не проникся, потому прошло мимо.
#conf
👍1
#dotnext, день 1, доклад 3.
Кафка и распродажи в Озоне.
Доклад был посвящен перемалыванию пиковых нагрузок в Озоне. Довольно много касалось Apache Kafka, ну и рассказывали что и как у них устроено. В целом - очень интересно, но прям совсем ничего нового. Хотя, поиграться с такими нагрузками желание появилось.
Из забавного - у них считается нормальным тестить на проде, точнее не тестить, а устраивать учения:)
#conf
Кафка и распродажи в Озоне.
Доклад был посвящен перемалыванию пиковых нагрузок в Озоне. Довольно много касалось Apache Kafka, ну и рассказывали что и как у них устроено. В целом - очень интересно, но прям совсем ничего нового. Хотя, поиграться с такими нагрузками желание появилось.
Из забавного - у них считается нормальным тестить на проде, точнее не тестить, а устраивать учения:)
#conf
😁3
#dotnext, день 1, доклад 4.
Dependecy Injection в тестах.
Автор из Яндекса пропагандировал использование стандартных практик написания кода внутри тестов, ну и рассказал об основных тестовых фреймворках в .Net (я и так знал, что использую самый дремучий - MSTest).
Звучит круто и логично, но на моей практике пока ничего хорошего из попыток написать тесты также как обычный код не вышло: поддержка из редактура становилась слишком трудоёмкой.
Пока наиболее оптимальным выглядит путь максимального говнокода с копипастой. И совсем чуть-чуть выноса повторяющихся простынь в отдельные методы.
#conf
Dependecy Injection в тестах.
Автор из Яндекса пропагандировал использование стандартных практик написания кода внутри тестов, ну и рассказал об основных тестовых фреймворках в .Net (я и так знал, что использую самый дремучий - MSTest).
Звучит круто и логично, но на моей практике пока ничего хорошего из попыток написать тесты также как обычный код не вышло: поддержка из редактура становилась слишком трудоёмкой.
Пока наиболее оптимальным выглядит путь максимального говнокода с копипастой. И совсем чуть-чуть выноса повторяющихся простынь в отдельные методы.
#conf