День 2192. #Оффтоп
Когда Прекратится Поддержка .NET Framework?
Вы когда-нибудь задумывались, когда мы наконец избавимся от старого доброго .NET Framework? Короткий ответ: непонятно. Майкрософт обещают продолжать его поддерживать, но это ведь не может продолжаться бесконечно.
Если посмотреть официальную страницу, вы увидите табличку на картинке выше.
Итак, все версии выше .NET Framework 4.7 по-прежнему поддерживается (и даже у 4.6.2 всё ещё 2 года в запасе). Примечание: эти версии практически не имеют конфликтов, поэтому обновление с 4.6.2 до 4.8.1 не должно вызвать никаких проблем.
В любом случае, одним из основных факторов долговечности фреймворка является то, что он связан с Windows. Windows Server 2022 поставляется с .NET 4.8.1. Дата окончания поддержки Windows Server 2022 — октябрь 2031 года. И даже Windows Server 2025 (последняя версия) содержит фреймворк, а её расширенная поддержка заканчивается ещё через 3 года — в 2034 году.
Поэтому весьма вероятно, что .NET Framework 4.8.x будет существовать плюс-минус до этого момента. Возможно, будут выпущены более новые версии с исправлениями из-за проблем с безопасностью (например, SHA-2 устареет или в нём обнаружится уязвимость, и людям придётся перейти на что-то другое).
Конечно, для новой разработки следует использовать .NET 8 и более поздние версии, если возможно. Однако очень маловероятно, что .NET Framework перестанет работать в ближайшее время. Хорошо это или нет, решать вам.
Источник: https://steven-giesel.com/blogPost/6de02565-a08e-4968-b610-22826582c1f1/when-will-net-framework-retire
Когда Прекратится Поддержка .NET Framework?
Вы когда-нибудь задумывались, когда мы наконец избавимся от старого доброго .NET Framework? Короткий ответ: непонятно. Майкрософт обещают продолжать его поддерживать, но это ведь не может продолжаться бесконечно.
Если посмотреть официальную страницу, вы увидите табличку на картинке выше.
Итак, все версии выше .NET Framework 4.7 по-прежнему поддерживается (и даже у 4.6.2 всё ещё 2 года в запасе). Примечание: эти версии практически не имеют конфликтов, поэтому обновление с 4.6.2 до 4.8.1 не должно вызвать никаких проблем.
В любом случае, одним из основных факторов долговечности фреймворка является то, что он связан с Windows. Windows Server 2022 поставляется с .NET 4.8.1. Дата окончания поддержки Windows Server 2022 — октябрь 2031 года. И даже Windows Server 2025 (последняя версия) содержит фреймворк, а её расширенная поддержка заканчивается ещё через 3 года — в 2034 году.
Поэтому весьма вероятно, что .NET Framework 4.8.x будет существовать плюс-минус до этого момента. Возможно, будут выпущены более новые версии с исправлениями из-за проблем с безопасностью (например, SHA-2 устареет или в нём обнаружится уязвимость, и людям придётся перейти на что-то другое).
Конечно, для новой разработки следует использовать .NET 8 и более поздние версии, если возможно. Однако очень маловероятно, что .NET Framework перестанет работать в ближайшее время. Хорошо это или нет, решать вам.
Источник: https://steven-giesel.com/blogPost/6de02565-a08e-4968-b610-22826582c1f1/when-will-net-framework-retire
👍16
День 2193.
Каналу 6 лет!
Минул ещё один год. Вас набралось почти 6000. Спасибо, что читаете, лайкаете и комментируете.
Для тех, кто пришёл недавно, вот здесь подборка тематических тегов. Кроме того, вы просто можете поискать по сообщениям в канале то, что вас интересует. Это, конечно, не гугл, но всё равно за 6 лет набралось довольно много полезной информации.
Кроме того, добро пожаловать в наш чат, где собралась неплохая компания, и где вам всегда постараются помочь.
Ещё раз спасибо, что читаете, а те, кто кроме этого хочет поддержать, добро пожаловать в Boosty или Patreon. А ещё монетки в телеге появились, если кому так удобнее)))
Каналу 6 лет!
Минул ещё один год. Вас набралось почти 6000. Спасибо, что читаете, лайкаете и комментируете.
Для тех, кто пришёл недавно, вот здесь подборка тематических тегов. Кроме того, вы просто можете поискать по сообщениям в канале то, что вас интересует. Это, конечно, не гугл, но всё равно за 6 лет набралось довольно много полезной информации.
Кроме того, добро пожаловать в наш чат, где собралась неплохая компания, и где вам всегда постараются помочь.
Ещё раз спасибо, что читаете, а те, кто кроме этого хочет поддержать, добро пожаловать в Boosty или Patreon. А ещё монетки в телеге появились, если кому так удобнее)))
3👍70👎1
День 2194. #UX
UX Кодов Доступа
Сегодня поговорим на немного отвлечённую тему. Все мы много раз вводили одноразовый код для входа в систему или подтверждения какой-то операции. Дизайн форм для ввода кода везде разный, каждый изощряется, как может. Если ваш продукт отправляет СМС/e-mail с кодами, то пользовательский опыт должен быть максимально хорошим.
Плохо
СМС/e-mail просто не приходит. Пользователь оказывается в подвешенном состоянии и в итоге вынужден искать ссылку «Не получили код? Отправить повторно», а то и ждать по 30-60 секунд перед повторной отправкой. Потом, конечно, после запроса повторной отправки приходит первый код, который уже не работает.
Сообщения вокруг кода длинные или странные. Иногда код приходит в длинном сообщении, где говорится о спаме/фишинге/безопасности, что в итоге делает весь процесс подозрительным. Куча вариантов испортить жизнь пользователю: неясная тема письма, код, зарытый в текст, код, стилистически не отличающийся от остальной части сообщения, код в конце длинного текста, так, что он не показывается в сокращённом уведомлении телефона и приходится его открывать полностью и т.п.
Странная форма. Мне не нравятся формы, где каждая цифра — отдельное поле. Всё должно быть понятно и просто, но тут это не так. Можно ли вставить скопированный код? Куда его вставлять? Перенесутся ли при вставке цифры в отдельные ячейки или вставится только первая? Часто в коде есть дефис он вставится? И т.п.
Код странный. Цифры – хорошо. Буквенно-цифровой код - пойдёт. 12 знаков, включая специальные символы, – зачем?
Запрет копирования/вставки кода. Зачем так делают? Вынуждать пользователя переключаться туда-сюда между приложениями, пытаясь удержать в голове случайные цифры – это издевательство!
Лучше
Код приходит быстро. Не нужно сидеть у почтового ящика, постоянно его обновляя.
Сообщение ясное и краткое. Вероятность того, что я не буду читать этот текст, составляет 99%, поэтому не пишите длинные тексты (ещё лучше – уберите текст вообще!)
Код выделен. Мой разум настроен на «где этот чёртов код?», поэтому выделение кода — это здорово. В Android есть удобная кнопка «Скопировать 434345», которая значительно упрощает процесс. В e-mail используйте форматирование и другие базовые методы дизайна, чтобы выделить код.
Лёгкие копирование и вставка. Конечно, вы можете выделить любой текст, но это может быть болезненно, если код находится в тексте абзаца. Лучше, когда он на отдельной строке и его можно легко скопировать. Идеально, когда приложение автоматически заполняет код и отправляет форму, как только вы его скопировали и переключились обратно на форму.
Отлично
Лучше всего, если этого кошмарного процесса вообще не существует. Я знаю, знаю, безопасность и вот это всё, но это лишние сложности и боль, как смерть от 1000 порезов бумагой. Это похоже на наказание.
Существуют и другие методы двухфакторной аутентификации, но каждый метод приносит свою боль. Приложения для аутентификации только добавляют стресса. А от того, что методы аутентификации в разных приложениях разные: смс/пуш/e-mail/приложение аутентификации, - вообще голова кругом идёт. Я ловлю себя на том, что нажимаю случайные кнопки, в метаниях между Chrome, e-mail клиентом и телефоном, не совсем понимая, что происходит, но в конце концов я нажимаю достаточно, чтобы меня впустили. И не дай бог вернуться спустя годы к какому-то приложению, где был зарегистрирован давно заброшенный e-mail!
В любом случае, между отличным UX и отличной безопасностью есть реальное противоречие, и понятно, что существует множество трудностей и компромиссов, необходимых для достижения баланса. Но, кажется, с этим надо что-то делать. Как минимум, если уж заставлять пользователей проходить через это, то упростить процесс максимально.
Источник: https://bradfrost.com/blog/post/the-ux-of-login-codes/
UX Кодов Доступа
Сегодня поговорим на немного отвлечённую тему. Все мы много раз вводили одноразовый код для входа в систему или подтверждения какой-то операции. Дизайн форм для ввода кода везде разный, каждый изощряется, как может. Если ваш продукт отправляет СМС/e-mail с кодами, то пользовательский опыт должен быть максимально хорошим.
Плохо
СМС/e-mail просто не приходит. Пользователь оказывается в подвешенном состоянии и в итоге вынужден искать ссылку «Не получили код? Отправить повторно», а то и ждать по 30-60 секунд перед повторной отправкой. Потом, конечно, после запроса повторной отправки приходит первый код, который уже не работает.
Сообщения вокруг кода длинные или странные. Иногда код приходит в длинном сообщении, где говорится о спаме/фишинге/безопасности, что в итоге делает весь процесс подозрительным. Куча вариантов испортить жизнь пользователю: неясная тема письма, код, зарытый в текст, код, стилистически не отличающийся от остальной части сообщения, код в конце длинного текста, так, что он не показывается в сокращённом уведомлении телефона и приходится его открывать полностью и т.п.
Странная форма. Мне не нравятся формы, где каждая цифра — отдельное поле. Всё должно быть понятно и просто, но тут это не так. Можно ли вставить скопированный код? Куда его вставлять? Перенесутся ли при вставке цифры в отдельные ячейки или вставится только первая? Часто в коде есть дефис он вставится? И т.п.
Код странный. Цифры – хорошо. Буквенно-цифровой код - пойдёт. 12 знаков, включая специальные символы, – зачем?
Запрет копирования/вставки кода. Зачем так делают? Вынуждать пользователя переключаться туда-сюда между приложениями, пытаясь удержать в голове случайные цифры – это издевательство!
Лучше
Код приходит быстро. Не нужно сидеть у почтового ящика, постоянно его обновляя.
Сообщение ясное и краткое. Вероятность того, что я не буду читать этот текст, составляет 99%, поэтому не пишите длинные тексты (ещё лучше – уберите текст вообще!)
Код выделен. Мой разум настроен на «где этот чёртов код?», поэтому выделение кода — это здорово. В Android есть удобная кнопка «Скопировать 434345», которая значительно упрощает процесс. В e-mail используйте форматирование и другие базовые методы дизайна, чтобы выделить код.
Лёгкие копирование и вставка. Конечно, вы можете выделить любой текст, но это может быть болезненно, если код находится в тексте абзаца. Лучше, когда он на отдельной строке и его можно легко скопировать. Идеально, когда приложение автоматически заполняет код и отправляет форму, как только вы его скопировали и переключились обратно на форму.
Отлично
Лучше всего, если этого кошмарного процесса вообще не существует. Я знаю, знаю, безопасность и вот это всё, но это лишние сложности и боль, как смерть от 1000 порезов бумагой. Это похоже на наказание.
Существуют и другие методы двухфакторной аутентификации, но каждый метод приносит свою боль. Приложения для аутентификации только добавляют стресса. А от того, что методы аутентификации в разных приложениях разные: смс/пуш/e-mail/приложение аутентификации, - вообще голова кругом идёт. Я ловлю себя на том, что нажимаю случайные кнопки, в метаниях между Chrome, e-mail клиентом и телефоном, не совсем понимая, что происходит, но в конце концов я нажимаю достаточно, чтобы меня впустили. И не дай бог вернуться спустя годы к какому-то приложению, где был зарегистрирован давно заброшенный e-mail!
В любом случае, между отличным UX и отличной безопасностью есть реальное противоречие, и понятно, что существует множество трудностей и компромиссов, необходимых для достижения баланса. Но, кажется, с этим надо что-то делать. Как минимум, если уж заставлять пользователей проходить через это, то упростить процесс максимально.
Источник: https://bradfrost.com/blog/post/the-ux-of-login-codes/
👍12
День 2195. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 41. Не стоит недооценивать сложность изменения культуры организации при переходе к новым методам работы
Глупо думать, что стоит просто описать новые процедуры работы в крупной компании – и всё получится само собой. Нужно объявить и объяснить политики, как они должны применяться, определить пути перехода к новым методам работы и спрашивать с людей за несоблюдение правил. Вы не можете просто отправить всех на тренинг, а затем ожидать, что люди начнут эффективно работать по-новому. Это только сбивает с толку, вызывает напряжение и подрывает доверие к руководству.
Ценности, модели поведения и практика
Здоровая культура разработки ПО подразумевает общие ценности, модели поведения и технические приёмы. Вовлечение членов команды в процесс совершенствования повышает их заинтересованность. Лидеры изменений должны объяснить:
- почему изменения необходимы;
- какие проблемы они решат;
- каких результатов организация надеется достичь;
- как изменения повлияют на организационную структуру;
- любые новые роли, должности или обязанности;
- сроки реализации;
- ответственность за конструктивный вклад в инициативу.
Меняться тяжело. Не все хотят этого, и вы не сможете развивать культуру, если люди активно сопротивляются, не желая покидать свою зону комфорта. Но нельзя позволять сопротивляющимся сдерживать всю инициативу. Старайтесь найти баланс между навязыванием нового образа жизни в приказном порядке и попытками сделать всех счастливыми. Преданные делу лидеры действуют и подают пример: ставят конкретные цели, предоставляют ресурсы и демонстрируют поведение, соответствующее намеченному результату. Руководители, стремящиеся к устойчивым изменениям, умеют формировать их так, чтобы они вызывали положительные эмоции и стимулировали действия. Общие фразы, предписания и директивы не помогут.
Направлять членов команды к новым ценностям и поведению означает, что их требуется каждодневно убеждать. У людей в организации есть три варианта: 1) помочь возглавить инициативу, 2) последовать ей и внести посильный вклад или 3) уйти с дороги. Если изменения заставляют кого-то чувствовать себя слишком некомфортно, эти люди, скорее всего, уйдут, но это лучший выход для всех. Хуже, если на словах они поддержат развитие, но будут игнорировать или подрывать его при каждой возможности.
Agile-разработка и изменение культуры
Переход на Agile — серьёзное изменение в работе организации. Многие аспекты культуры должны измениться, в том числе:
- организационная структура и состав команды;
- терминология;
- ценности и принципы;
- роли в проекте;
- методы составления графиков и планов;
- характер сотрудничества и общения;
- оценка прогресса;
- ответственность за результаты.
Переход к Agile предполагает резкое изменение мышления и практик. Простого обучения недостаточно, чтобы добиться приверженности новым ценностям, изменить индивидуальное поведение и принять новые методы. Людям нужно время, чтобы забыть прошлые навыки и освоиться с новыми способами работы.
Интернализация
Под интернализацией подразумевается укоренение новых способов работы в умах отдельных членов команды. Когда члены команды принимают новые методы и модели поведения, то не потому, что этого требует руководитель, а потому, что это лучший из известных им способов выполнения работы. Освоив лучший способ работы, вы автоматически продолжите использовать его.
Фундаментальный переход от устоявшихся методов работы к чему-то совершенно иному требует изменения множества аспектов: организационных, управленческих, лидерства в проектах, практики вознаграждения, технических приёмов, индивидуальных привычек и поведения команды. Высшее руководство должно быть привержено изменениям и убедительно доказывать их необходимость всем, кого они касаются. Культурный переход — более сложная задача, чем установка новых приёмов и методов; не решив её, вы почти наверняка потерпите неудачу.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 5.
Уроки 50 Лет Разработки ПО
Урок 41. Не стоит недооценивать сложность изменения культуры организации при переходе к новым методам работы
Глупо думать, что стоит просто описать новые процедуры работы в крупной компании – и всё получится само собой. Нужно объявить и объяснить политики, как они должны применяться, определить пути перехода к новым методам работы и спрашивать с людей за несоблюдение правил. Вы не можете просто отправить всех на тренинг, а затем ожидать, что люди начнут эффективно работать по-новому. Это только сбивает с толку, вызывает напряжение и подрывает доверие к руководству.
Ценности, модели поведения и практика
Здоровая культура разработки ПО подразумевает общие ценности, модели поведения и технические приёмы. Вовлечение членов команды в процесс совершенствования повышает их заинтересованность. Лидеры изменений должны объяснить:
- почему изменения необходимы;
- какие проблемы они решат;
- каких результатов организация надеется достичь;
- как изменения повлияют на организационную структуру;
- любые новые роли, должности или обязанности;
- сроки реализации;
- ответственность за конструктивный вклад в инициативу.
Меняться тяжело. Не все хотят этого, и вы не сможете развивать культуру, если люди активно сопротивляются, не желая покидать свою зону комфорта. Но нельзя позволять сопротивляющимся сдерживать всю инициативу. Старайтесь найти баланс между навязыванием нового образа жизни в приказном порядке и попытками сделать всех счастливыми. Преданные делу лидеры действуют и подают пример: ставят конкретные цели, предоставляют ресурсы и демонстрируют поведение, соответствующее намеченному результату. Руководители, стремящиеся к устойчивым изменениям, умеют формировать их так, чтобы они вызывали положительные эмоции и стимулировали действия. Общие фразы, предписания и директивы не помогут.
Направлять членов команды к новым ценностям и поведению означает, что их требуется каждодневно убеждать. У людей в организации есть три варианта: 1) помочь возглавить инициативу, 2) последовать ей и внести посильный вклад или 3) уйти с дороги. Если изменения заставляют кого-то чувствовать себя слишком некомфортно, эти люди, скорее всего, уйдут, но это лучший выход для всех. Хуже, если на словах они поддержат развитие, но будут игнорировать или подрывать его при каждой возможности.
Agile-разработка и изменение культуры
Переход на Agile — серьёзное изменение в работе организации. Многие аспекты культуры должны измениться, в том числе:
- организационная структура и состав команды;
- терминология;
- ценности и принципы;
- роли в проекте;
- методы составления графиков и планов;
- характер сотрудничества и общения;
- оценка прогресса;
- ответственность за результаты.
Переход к Agile предполагает резкое изменение мышления и практик. Простого обучения недостаточно, чтобы добиться приверженности новым ценностям, изменить индивидуальное поведение и принять новые методы. Людям нужно время, чтобы забыть прошлые навыки и освоиться с новыми способами работы.
Интернализация
Под интернализацией подразумевается укоренение новых способов работы в умах отдельных членов команды. Когда члены команды принимают новые методы и модели поведения, то не потому, что этого требует руководитель, а потому, что это лучший из известных им способов выполнения работы. Освоив лучший способ работы, вы автоматически продолжите использовать его.
Фундаментальный переход от устоявшихся методов работы к чему-то совершенно иному требует изменения множества аспектов: организационных, управленческих, лидерства в проектах, практики вознаграждения, технических приёмов, индивидуальных привычек и поведения команды. Высшее руководство должно быть привержено изменениям и убедительно доказывать их необходимость всем, кого они касаются. Культурный переход — более сложная задача, чем установка новых приёмов и методов; не решив её, вы почти наверняка потерпите неудачу.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 5.
👍4
День 2196. #ЗаметкиНаПолях #Microservices
Отказоустойчивые HTTP-запросы в .NET. Начало
Не всегда всё идет по плану: запросы по сети рандомно завершаются неудачей, серверы приложений перегружаются, и возникают неожиданные ошибки. Отказоустойчивые приложения могут восстанавливаться после временных сбоев и продолжать функционировать. Устойчивость достигается путём проектирования приложений, которые могут корректно обрабатывать сбои и быстро восстанавливаться. Рассмотрим инструменты и методы, которые есть в .NET для создания отказоустойчивых систем.
Зачем?
Отправка HTTP-запросов — распространённый подход к связи между удалёнными сервисами. Но они подвержены сбоям из-за проблем с сетью или сервером. Эти сбои могут нарушить доступность сервисов, особенно по мере увеличения зависимостей и риска каскадных сбоев. Вот несколько стратегий повышения устойчивости:
- Повторные попытки - повторить запрос, который завершился неудачей из-за временной ошибки.
- Тайм-ауты - отмена запросов, которые превышают указанный лимит времени.
- Хэджирование и откаты - альтернативные действия или результаты для неудавшихся операций.
- Аварийное отключение - временное прекращение связи с недоступными сервисами.
Эти стратегии можно использовать по отдельности или в сочетании для оптимальной устойчивости HTTP-запросов.
Конвейеры устойчивости
Начиная с .NET 8 интеграция отказоустойчивости в приложения стала намного проще. Можно использовать Microsoft.Extensions.Resilience и Microsoft.Extensions.Http.Resilience, которые построены на основе Polly. Polly — библиотека отказоустойчивости и обработки временных сбоев в .NET. Она позволяет определять стратегии обеспечения устойчивости, описанные выше. Polly получила новый API в последней версии (V8), который был реализован в сотрудничестве с Microsoft. Если вы ранее использовали Microsoft.Extensions.Http.Polly, теперь рекомендуется использовать следующие пакеты:
Cначала создадим конвейер, состоящий из стратегий отказоустойчивости. Каждая стратегия, которую мы настраиваем как часть конвейера, будет выполняться в порядке конфигурации. Порядок важен! Создадим конвейер с помощью построителя:
Вот что мы добавляем в конвейер отказоустойчивости:
- AddRetry — настраивает стратегию повторных попыток, которую мы можем дополнительно настроить, передав экземпляр RetryStrategyOptions. Здесь вы предоставляем предикат для свойства ShouldHandle, чтобы определить, какие исключения (ConflictException) должна обрабатывать стратегия. Также мы указываем максимальное количество попыток повтора и настраиваем время ожидания до следующего повтора. В данном случае оно будет экспоненциально расти (DelayBackoffType.Exponential) и в разных случаях будет немного варьироваться (UseJitter). См. подробнее про настройки стратегии повтора.
- AddTimeout — настраивает стратегию тайм-аута, которая выдаст TimeoutRejectedException, если делегат не завершится до истечения времени ожидания. Мы можем передать нужное ожидания в экземпляр TimeoutStrategyOptions. Время ожидания по умолчанию - 30 секунд.
В конце мы строим конвейер, и используем настроенный экземпляр для HTTP-запроса в методе ExecuteAsync.
Продолжение следует…
Источник: https://www.milanjovanovic.tech/blog/building-resilient-cloud-applications-with-dotnet
Отказоустойчивые HTTP-запросы в .NET. Начало
Не всегда всё идет по плану: запросы по сети рандомно завершаются неудачей, серверы приложений перегружаются, и возникают неожиданные ошибки. Отказоустойчивые приложения могут восстанавливаться после временных сбоев и продолжать функционировать. Устойчивость достигается путём проектирования приложений, которые могут корректно обрабатывать сбои и быстро восстанавливаться. Рассмотрим инструменты и методы, которые есть в .NET для создания отказоустойчивых систем.
Зачем?
Отправка HTTP-запросов — распространённый подход к связи между удалёнными сервисами. Но они подвержены сбоям из-за проблем с сетью или сервером. Эти сбои могут нарушить доступность сервисов, особенно по мере увеличения зависимостей и риска каскадных сбоев. Вот несколько стратегий повышения устойчивости:
- Повторные попытки - повторить запрос, который завершился неудачей из-за временной ошибки.
- Тайм-ауты - отмена запросов, которые превышают указанный лимит времени.
- Хэджирование и откаты - альтернативные действия или результаты для неудавшихся операций.
- Аварийное отключение - временное прекращение связи с недоступными сервисами.
Эти стратегии можно использовать по отдельности или в сочетании для оптимальной устойчивости HTTP-запросов.
Конвейеры устойчивости
Начиная с .NET 8 интеграция отказоустойчивости в приложения стала намного проще. Можно использовать Microsoft.Extensions.Resilience и Microsoft.Extensions.Http.Resilience, которые построены на основе Polly. Polly — библиотека отказоустойчивости и обработки временных сбоев в .NET. Она позволяет определять стратегии обеспечения устойчивости, описанные выше. Polly получила новый API в последней версии (V8), который был реализован в сотрудничестве с Microsoft. Если вы ранее использовали Microsoft.Extensions.Http.Polly, теперь рекомендуется использовать следующие пакеты:
Install-Package Microsoft.Extensions.Resilience
Install-Package Microsoft.Extensions.Http.Resilience
Cначала создадим конвейер, состоящий из стратегий отказоустойчивости. Каждая стратегия, которую мы настраиваем как часть конвейера, будет выполняться в порядке конфигурации. Порядок важен! Создадим конвейер с помощью построителя:
ResiliencePipeline pipeline =
new ResiliencePipelineBuilder()
.AddRetry(new RetryStrategyOptions
{
ShouldHandle = new PredicateBuilder()
.Handle<ConflictException>(),
Delay = TimeSpan.FromSeconds(1),
MaxRetryAttempts = 2,
BackoffType = DelayBackoffType.Exponential,
UseJitter = true
})
.AddTimeout(new TimeoutStrategyOptions
{
Timeout = TimeSpan.FromSeconds(10)
})
.Build();
await pipeline.ExecuteAsync(
async ct => await httpClient
.GetAsync("https://google.com", ct),
cancellationToken);
Вот что мы добавляем в конвейер отказоустойчивости:
- AddRetry — настраивает стратегию повторных попыток, которую мы можем дополнительно настроить, передав экземпляр RetryStrategyOptions. Здесь вы предоставляем предикат для свойства ShouldHandle, чтобы определить, какие исключения (ConflictException) должна обрабатывать стратегия. Также мы указываем максимальное количество попыток повтора и настраиваем время ожидания до следующего повтора. В данном случае оно будет экспоненциально расти (DelayBackoffType.Exponential) и в разных случаях будет немного варьироваться (UseJitter). См. подробнее про настройки стратегии повтора.
- AddTimeout — настраивает стратегию тайм-аута, которая выдаст TimeoutRejectedException, если делегат не завершится до истечения времени ожидания. Мы можем передать нужное ожидания в экземпляр TimeoutStrategyOptions. Время ожидания по умолчанию - 30 секунд.
В конце мы строим конвейер, и используем настроенный экземпляр для HTTP-запроса в методе ExecuteAsync.
Продолжение следует…
Источник: https://www.milanjovanovic.tech/blog/building-resilient-cloud-applications-with-dotnet
👍31
День 2197. #ЗаметкиНаПолях #Microservices
Отказоустойчивые HTTP-запросы в .NET. Продолжение
Начало
Внедрение зависимостей
.NET 8 представляет новый метод расширения AddResiliencePipeline для интерфейса IServiceCollection, который позволяет регистрировать конвейеры отказоустойчивости. Каждый конвейер должен иметь уникальный ключ, который мы можем использовать для разрешения соответствующего экземпляра конвейера:
Также можно указать обобщённые аргументы, чтобы настроить типизированный конвейер, используя ResiliencePipelineBuilder<TResult>. Так мы можем получить доступ к стратегиям хеджирования и отката.
В следующем примере мы настраиваем стратегию отката, вызывая AddFallback. Это позволяет предоставить «запасное» значение, которое мы можем вернуть в случае сбоя. Оно может быть статическим значением или поступать из другого HTTP-запроса или БД.
Чтобы использовать конвейеры из DI-контейнера, можно использовать метод GetPipeline класса ResiliencePipelineProvider, передав ему ключ:
Стратегии отказоустойчивости и Polly
Стратегии устойчивости являются основным компонентом Polly. Они предназначены для запуска пользовательских обратных вызовов, одновременно добавляя отказоустойчивость. Мы не можем запускать стратегии напрямую, только через конвейер. Polly делит стратегии на:
- Реактивные - обрабатывают определённые исключения или результаты.
- Проактивные - решают прервать или отменить выполнение обратных вызовов с помощью стратегий ограничения скорости или тайм-аута.
Polly имеет следующие встроенные стратегии отказоустойчивости:
- Повтор - классический подход «попробуйте ещё раз». Отлично подходит для временных сетевых сбоев.
- Аварийное отключение - предотвращает нагрузку на отказавшую систему. Если ошибки накапливаются, временное отключение даёт системе время на восстановление.
- Откат - обеспечивает безопасный ответ по умолчанию, если основной вызов не удаётся.
- Хеджирование - выполняет несколько запросов одновременно, принимая первый успешный ответ. Полезно, если в системе есть несколько способов обработки чего-либо.
- Тайм-аут - предотвращает вечное зависание запросов, завершая их, если превышено время ожидания.
- Ограничитель скорости - ограничивает исходящие запросы, чтобы предотвратить перегрузку внешних сервисов.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/building-resilient-cloud-applications-with-dotnet
Отказоустойчивые HTTP-запросы в .NET. Продолжение
Начало
Внедрение зависимостей
.NET 8 представляет новый метод расширения AddResiliencePipeline для интерфейса IServiceCollection, который позволяет регистрировать конвейеры отказоустойчивости. Каждый конвейер должен иметь уникальный ключ, который мы можем использовать для разрешения соответствующего экземпляра конвейера:
services.AddResiliencePipeline("retry", builder =>
{
builder.AddRetry(new RetryStrategyOptions
{
Delay = TimeSpan.FromSeconds(1),
MaxRetryAttempts = 2,
BackoffType = DelayBackoffType.Exponential,
UseJitter = true
});
});Также можно указать обобщённые аргументы, чтобы настроить типизированный конвейер, используя ResiliencePipelineBuilder<TResult>. Так мы можем получить доступ к стратегиям хеджирования и отката.
В следующем примере мы настраиваем стратегию отката, вызывая AddFallback. Это позволяет предоставить «запасное» значение, которое мы можем вернуть в случае сбоя. Оно может быть статическим значением или поступать из другого HTTP-запроса или БД.
services.AddResiliencePipeline<string, GitHubUser?>(
"gh-fallback", builder =>
{
builder.AddFallback(
new FallbackStrategyOptions<GitHubUser?>
{
FallbackAction = _ =>
Outcome.FromResultAsValueTask<GitHubUser?>(
GitHubUser.Empty
)
});
});
Чтобы использовать конвейеры из DI-контейнера, можно использовать метод GetPipeline класса ResiliencePipelineProvider, передав ему ключ:
app.MapGet("users", async (
HttpClient httpClient,
ResiliencePipelineProvider<string> plProv) =>
{
var pipeline =
plProv.GetPipeline<GitHubUser?>("gh-fallback");
var user = await pipeline.ExecuteAsync(async token =>
await httpClient.GetAsync("api/users", token),
cancellationToken);
});Стратегии отказоустойчивости и Polly
Стратегии устойчивости являются основным компонентом Polly. Они предназначены для запуска пользовательских обратных вызовов, одновременно добавляя отказоустойчивость. Мы не можем запускать стратегии напрямую, только через конвейер. Polly делит стратегии на:
- Реактивные - обрабатывают определённые исключения или результаты.
- Проактивные - решают прервать или отменить выполнение обратных вызовов с помощью стратегий ограничения скорости или тайм-аута.
Polly имеет следующие встроенные стратегии отказоустойчивости:
- Повтор - классический подход «попробуйте ещё раз». Отлично подходит для временных сетевых сбоев.
- Аварийное отключение - предотвращает нагрузку на отказавшую систему. Если ошибки накапливаются, временное отключение даёт системе время на восстановление.
- Откат - обеспечивает безопасный ответ по умолчанию, если основной вызов не удаётся.
- Хеджирование - выполняет несколько запросов одновременно, принимая первый успешный ответ. Полезно, если в системе есть несколько способов обработки чего-либо.
- Тайм-аут - предотвращает вечное зависание запросов, завершая их, если превышено время ожидания.
- Ограничитель скорости - ограничивает исходящие запросы, чтобы предотвратить перегрузку внешних сервисов.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/building-resilient-cloud-applications-with-dotnet
👍15
День 2198. #ЗаметкиНаПолях #Microservices
Отказоустойчивые HTTP-запросы в .NET. Окончание
Начало
Продолжение
Отказоустойчивость HTTP-клиентов
Библиотека Microsoft.Extensions.Http.Resilience поставляется с готовыми к использованию конвейерами отказоустойчивости для отправки HTTP-запросов. Мы можем добавить отказоустойчивость к исходящим запросам HttpClient с помощью метода AddStandardResilienceHandler, в том числе настроив его по умолчанию для всех HTTP-клиентов приложения:
В стандартном обработчике отказоустойчивости можно настроить 5 стратегий: ограничение скорости, тайм-аут попытки, общий таймаут запроса, повторы, автоматическое отключение.
Проблема в том, что, если вам потребуется другая стратегия для какого-то специфического сценария, она не будет применена, а будет использована стратегия по умолчанию. Это большое упущение команды .NET, и они о нём в курсе. Над предложением по исправлению этой проблемы уже работают (проследить можно здесь). А пока есть решение вручную.
Создадим метод расширения, который очищает все обработчики из конвейера отказоустойчивости. Это позволит удалить обработчики по умолчанию и добавить свои:
Теперь его можно использовать, чтобы удалить стандартную стратегию отказоустойчивости и добавить другую в случаях, когда стандартная не подходит:
Итого
Отказоустойчивость — основной принцип создания надёжных программных систем. Имея в нашем распоряжении такие мощные инструменты, как Microsoft.Extensions.Resilience и Polly, мы можем использовать их для проектирования систем, которые грамотно обрабатывают любые временные сбои.
Источник: https://www.milanjovanovic.tech/blog/overriding-default-http-resilience-handlers-in-dotnet
Отказоустойчивые HTTP-запросы в .NET. Окончание
Начало
Продолжение
Отказоустойчивость HTTP-клиентов
Библиотека Microsoft.Extensions.Http.Resilience поставляется с готовыми к использованию конвейерами отказоустойчивости для отправки HTTP-запросов. Мы можем добавить отказоустойчивость к исходящим запросам HttpClient с помощью метода AddStandardResilienceHandler, в том числе настроив его по умолчанию для всех HTTP-клиентов приложения:
builder.Services
.AddHttpClient()
.ConfigureHttpClientDefaults(
http => http.AddStandardResilienceHandler(o =>
{
o.Retry.Delay = TimeSpan.FromSeconds(1);
…
}));
В стандартном обработчике отказоустойчивости можно настроить 5 стратегий: ограничение скорости, тайм-аут попытки, общий таймаут запроса, повторы, автоматическое отключение.
Проблема в том, что, если вам потребуется другая стратегия для какого-то специфического сценария, она не будет применена, а будет использована стратегия по умолчанию. Это большое упущение команды .NET, и они о нём в курсе. Над предложением по исправлению этой проблемы уже работают (проследить можно здесь). А пока есть решение вручную.
Создадим метод расширения, который очищает все обработчики из конвейера отказоустойчивости. Это позволит удалить обработчики по умолчанию и добавить свои:
public static class ResilienceExtensions
{
public static IHttpClientBuilder
RemoveAllResilienceHandlers(
this IHttpClientBuilder builder)
{
builder.ConfigureAdditionalHttpMessageHandlers(
static (handlers, _) =>
{
for (int i = handlers.Count - 1; i >= 0; i--)
{
if (handlers[i] is ResilienceHandler)
{
handlers.RemoveAt(i);
}
}
});
return builder;
}
}
Теперь его можно использовать, чтобы удалить стандартную стратегию отказоустойчивости и добавить другую в случаях, когда стандартная не подходит:
builder.Services
.AddHttpClient("github")
.ConfigureHttpClient(cl =>
{
cl.BaseAddress = new Uri("https://api.github.com");
})
.RemoveAllResilienceHandlers()
.AddResilienceHandler("custom", p =>
{
// Настраиваем другую политику
// для Http-клиента GitHub…
});
Итого
Отказоустойчивость — основной принцип создания надёжных программных систем. Имея в нашем распоряжении такие мощные инструменты, как Microsoft.Extensions.Resilience и Polly, мы можем использовать их для проектирования систем, которые грамотно обрабатывают любые временные сбои.
Источник: https://www.milanjovanovic.tech/blog/overriding-default-http-resilience-handlers-in-dotnet
👍18
Честно, не подглядывая, что произойдёт при попытке компиляции и запуска такого кода? #Quiz #CSharp
var var = new();
class var {};
var var = new();
class var {};
Anonymous Quiz
74%
ошибка компиляции
3%
ошибка времени выполнения
22%
это валидный код C#
2👍24👎22
День 2199.
Сегодня порекомендую вам интервью, которое взял Ник Чапсас у одного из разработчиков языка C#, Мэдса Торгенсена.
Какие новинки готовит нам C#14? Что случилось с типами-расширениями? Почему в первичные конструкторы не добавили readonly параметры? Когда уже появятся дискриминируемые объединения в C#? И вообще, как команда языка определяет, какие новые функции добавлять в язык и как это делать?
А в конце беседы Мэдс рассказывает, какие функции языка он ненавидит и с радостью убрал бы.
Ко вчерашнему квизу про var. В компиляторе огромное количество логики, которая определяет правильность использования ключевых слов. И в этом конкретном случае var в начале объявления переменной будет рассматриваться как тип, если он существует. А второе слово в объявлении будет именем переменной. И такой код будет прекрасно компилироваться и работать. Более того, Мэдс рассказал, что так в отдельных командах ненавистники ключевого слова var запрещали его использование. Просто создавали пустой класс var, и тогда любое использование var в объявлении приводило к созданию экземпляра этого класса. Таким образом, приходилось отказываться от var и явно объявлять тип переменной.
https://youtu.be/T9UqIkuGnuo
Сегодня порекомендую вам интервью, которое взял Ник Чапсас у одного из разработчиков языка C#, Мэдса Торгенсена.
Какие новинки готовит нам C#14? Что случилось с типами-расширениями? Почему в первичные конструкторы не добавили readonly параметры? Когда уже появятся дискриминируемые объединения в C#? И вообще, как команда языка определяет, какие новые функции добавлять в язык и как это делать?
А в конце беседы Мэдс рассказывает, какие функции языка он ненавидит и с радостью убрал бы.
Ко вчерашнему квизу про var. В компиляторе огромное количество логики, которая определяет правильность использования ключевых слов. И в этом конкретном случае var в начале объявления переменной будет рассматриваться как тип, если он существует. А второе слово в объявлении будет именем переменной. И такой код будет прекрасно компилироваться и работать. Более того, Мэдс рассказал, что так в отдельных командах ненавистники ключевого слова var запрещали его использование. Просто создавали пустой класс var, и тогда любое использование var в объявлении приводило к созданию экземпляра этого класса. Таким образом, приходилось отказываться от var и явно объявлять тип переменной.
https://youtu.be/T9UqIkuGnuo
👍19
По мотивам интервью выше, какую функцию языка C# вам больше всего хотелось бы, чтобы переделали или убрали совсем?
Anonymous Poll
18%
события
11%
делегаты
26%
dynamic
7%
async/await
3%
var
8%
nullable-типы
2%
LINQ
16%
первичные конструкторы классов
4%
сопоставление по шаблону
7%
другую (напишу в комментариях)
2200.png
47.1 KB
День 2200. #ЗадачиНаСобеседовании
Код Ревью
Давно не было темы задач на собеседовании (если что, другие посты смотрите по тегу выше). А вот эта показалась интересной. Не буду говорить, откуда. Кто знает, тот знает. Ну и, надеюсь, не раскрою никакой тайны, вроде NDA не подписывал 😊
Итак, вам на ревью прислали вот такой код. А картинкой – это чтоб интереснее было, а то знаю я вас, сразу скопируете и в какой-нибудь жпт запихнёте))). Проверьте код и дайте фидбек. Всё, что вы сможете найти, насколько бы мелким и незначительным на фоне остального это ни казалось. Единственное замечание – мы исходим из того, что код компилируется и вообще проект успешно собирается, то есть все необходимые юзинги на месте, хоть их здесь и нет.
Удачи, жду ревью в комментариях.
Код Ревью
Давно не было темы задач на собеседовании (если что, другие посты смотрите по тегу выше). А вот эта показалась интересной. Не буду говорить, откуда. Кто знает, тот знает. Ну и, надеюсь, не раскрою никакой тайны, вроде NDA не подписывал 😊
Итак, вам на ревью прислали вот такой код. А картинкой – это чтоб интереснее было, а то знаю я вас, сразу скопируете и в какой-нибудь жпт запихнёте))). Проверьте код и дайте фидбек. Всё, что вы сможете найти, насколько бы мелким и незначительным на фоне остального это ни казалось. Единственное замечание – мы исходим из того, что код компилируется и вообще проект успешно собирается, то есть все необходимые юзинги на месте, хоть их здесь и нет.
Удачи, жду ревью в комментариях.
👍9
День 2201. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
👍17
День 2202. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало
3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.
Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.
Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.
4. Медленное внесение простых изменений
Если простое изменение, вроде создания нового класса, приводит к бюрократическому ужасу согласований, изменений конфигурации и документации, это даже не красный флаг, а пожарная тревога. Высокопроизводительные команды имеют свободу быстро и легко принимать решения, не спрашивая разрешения у кого-либо.
Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.
Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.
5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.
Красный флаг
Разработчики чувствуют себя деморализованными, не заслуживающими доверия или подверженными микроменеджменту, и не рекомендуют своего работодателя друзьям.
Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.
6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.
Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.
Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.
Окончание следует…
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Продолжение
Начало
3. Фокус на процессе вместо результатов
Наша цель — поставить пользователям хорошее работающее ПО и постоянно поддерживать способность делать это. Не имеет значения, сколько историй мы поставляем в спринте, если они не представляют ценности для пользователей. Насколько хорошо наше тестовое покрытие не имеет значения, если у нас всё ещё много ошибок, которые мешают пользователям использовать ПО. Тот факт, что каждая функция имеет аккуратные комментарии, не имеет значения, если наш код все ещё трудно изменять.
Красный флаг
Команды, оцениваемые по тому, сколько стори-пойнтов они поставляют, если при этом никто не проверяет, действительно ли эти функции приносят пользу пользователям.
Что делать?
Измерять реальные результаты:
- Сколько времени требуется для поставки изменений в производство?
- Довольны ли пользователи?
- Минимально ли количество ошибок и быстро ли они устраняются?
Эти вещи сложнее измерить, но они гораздо важнее. Поэтому, если ваш проект измеряется по тому, насколько хорошо вы содействуете какому-то процессу, но вы не можете ответить на вопросы вроде перечисленных выше, это предупреждающий знак, что вы сбиваетесь с пути. Начните измерять вещи, которые действительно имеют значение, а затем принимайте решения на основе результатов этих измерений.
4. Медленное внесение простых изменений
Если простое изменение, вроде создания нового класса, приводит к бюрократическому ужасу согласований, изменений конфигурации и документации, это даже не красный флаг, а пожарная тревога. Высокопроизводительные команды имеют свободу быстро и легко принимать решения, не спрашивая разрешения у кого-либо.
Красный флаг
Чрезмерная бюрократия или отсутствие доверия командам разработчиков в принятии собственных решений.
Что делать?
Предоставить разработчикам автономию для принятия решений по проектированию и реализации, не дожидаясь одобрения на каждом этапе.
5. Моральный дух команд разработчиков
Если команды разработчиков думают, что их система плохая, они обычно правы. Те, кто производит отличное ПО, как правило, знают, что они преуспевают, поэтому если моральный дух команды низкий, это должно быть большим предупреждающим знаком того, что что-то фундаментально не так.
Красный флаг
Разработчики чувствуют себя деморализованными, не заслуживающими доверия или подверженными микроменеджменту, и не рекомендуют своего работодателя друзьям.
Что делать?
Повысить автономность. Мастерство и чётко обозначенная цель позволяют командам принимать ключевые решения, поощрять обучение и гарантировать, что все знают, почему работа, которую они делают, действительно важна.
6. Зависимость от героев
Если судьба проекта зависит от разработчиков-«рок звёзд», это очень серьезный предупреждающий знак.
Красный флаг
Один человек, который является единственным, кто может исправить или понять определённые области кода или определённые практики.
Что делать?
Распространять эти знания. Это можно делать это с помощью таких методов, как парное или групповое программирование, обзоры кода, митапы и т.п.
Окончание следует…
Источник: https://youtu.be/-6KHhwEMtqs
👍8
День 2203. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение
7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.
Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.
Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.
8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.
Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.
Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.
9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.
Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.
Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.
10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.
Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.
Что делать?
Вовлекать реальных пользователей в процесс разработки, либо набирать тестовых пользователей, которые могут давать вам предложения и отзывы по мере создания ПО. Либо более частый выпуск ПО в производство и наблюдение за ним, чтобы определить, как оно используется и какие части игнорируются.
Источник: https://youtu.be/-6KHhwEMtqs
10 Признаков Того, Что Проект на Пути к Провалу. Окончание
Начало
Продолжение
7. Низкие баллы по метрикам DORA
Метрики DevOps Research and Assessment (DORA) измеряют стабильность и пропускную способность, т.е. качество ПО, которое мы производим, и эффективность, с которой мы можем создавать ПО такого качества. Если у вас низкие баллы по обоим метрикам, то вы поставляете некачественное ПО и делаете это медленно. Это почти гарантированный путь к провалу.
Красные флаги
- низкая частота развертывания,
- большие сроки выполнения,
- высокая частота отказов,
- большое время восстановления после сбоев.
Что делать?
Начать внедрять такие методы, как непрерывная интеграция, автоматизированное тестирование, частые релизы и быстрые откаты или исправления для повышения скорости и качества циклов обратной связи и раннего обнаружения проблем.
8. Достижение прогресса большими шагами
Большие многомесячные планы уменьшают ваши возможности учиться и адаптироваться. Лучшая альтернатива – рассматривать разработку как постоянный цикл экспериментов и открытий, а не пытаться найти и затем воплотить в каком-то плане то, что, по вашему мнению, является лучшими идеями. Гораздо эффективнее предположить, что ваши идеи в начале проекта неправильны, поэтому продумайте, что делать, если ваши идеи потерпят неудачу. Также создавайте системы так, чтобы их было легко изменить, чтобы вы могли исправить ошибки, когда вы их обнаружите.
Красный флаг
Обычно виден как функции, запланированные далеко на будущее и не выпущенные или не протестированные в течение месяцев или лет.
Что делать?
Работать небольшими итерациями. Выпускать чаще и получать быструю обратную связь от реальных пользователей. Если вы обнаружите, что ваша команда работает над подробными планами работы, которая будет выполнена через несколько месяцев, или функциями, которые не будут выпущены в течение недель, месяцев или даже лет, это большой предупреждающий знак. Выясните, как оптимизировать ваш процесс разработки, чтобы вы могли выпускать функциональность в любое время. Быстрая обратная связь и другие методы непрерывной доставки, позволяют работать более размеренно, развивая ПО пошагово. Это даёт больше возможностей для обучения и корректировки курса, когда мы обнаруживаем ошибку.
9. Плохая или отсутствующая обратная связь
Хорошие короткие циклы обратной связи позволяют направлять наши проекты к успеху. Если мы не знаем, работают ли наши новые функции для пользователей, то мы двигаемся вслепую.
Красные флаги
- Редкая или отсутствующая обратная связь от пользователей.
- Отсутствие автоматизированных проверок.
Что делать?
Сократить циклы обратной связи на каждом уровне. Автоматизированная сборка обратной связи от пользователей, непрерывная интеграция и частые выпуски - всё это инструменты, которые помогают нам достичь этого.
10. Разработка неправильной вещи
Это может показаться очевидной ошибкой, которую никто никогда не сделает, но на самом деле это чрезвычайно распространено. В своём исследовании Microsoft обнаружили, что 2/3 их идей дали нулевой или отрицательный выхлоп. Оценки того, как часто функции, которые мы производим как отрасль, вообще никогда не используются, варьируются от 40 до 90%. Поэтому создание неправильных вещей, по крайней мере, так же, а то и более распространено, чем создание вещей, которые люди хотят.
Красные флаги
- Отсутствие пользователей и обратной связи.
- Отсутствие отчётов об ошибках, хотя мы знаем, что наше ПО работает неверно.
Что делать?
Вовлекать реальных пользователей в процесс разработки, либо набирать тестовых пользователей, которые могут давать вам предложения и отзывы по мере создания ПО. Либо более частый выпуск ПО в производство и наблюдение за ним, чтобы определить, как оно используется и какие части игнорируются.
Источник: https://youtu.be/-6KHhwEMtqs
👍6
День 2204. #ЧтоНовенького
Новинки в Visual Studio 2022
Несколько новинок было представлено в VS 2022 с начала года.
1. Настройка сообщений коммита, сгенерированных ИИ
VS уже какое-то время назад представила автоматическую генерацию сообщений коммита с помощью ИИ, описывая сделанные вами изменения. У меня нет большого опыта её использования, но несколько раз пробовал, и получается довольно неплохо (по крайней мере, по-английски). Нынешняя новинка позволяет вам легко адаптировать сообщения о коммитах в соответствии с вашим рабочим процессом и стандартами команды: указать количество и длину строк, стиль сообщения и т.п. Copilot понимает такие термины, как «тема», «тело» и «нижний колонтитул». Например (буду использовать примеры по-английски, т.к. на русском не пробовал):
Use all lowercase
Limit subject to 50 characters
Limit body to 2 sentences
Add a footer with three hash marks
Follow Conventional Commits standard
Чтобы это настроить, перейдите в Tools > Options > GitHub > Copilot (Инструменты > Параметры > GitHub > Copilot) и введите нужные параметры.
2. Настройка индикаторов свёрнутого текста
Теперь вы можете персонализировать цвет и фон индикатора свёрнутого текста в редакторе, установив пользовательские цвета для индикаторов свёрнутого и развёрнутого текста в отдельности. Эта функция доступна через меню Tools > Options > Environment > Fonts and Colors (Инструменты > Параметры > Среда > Шрифты и цвета).
Две новые записи в списке настроек редактора тестов, которые управляют цветом индикатора свернутого текста:
- Collapsed Text Indicator (Collapsed)
- Collapsed Text Indicator (Expanded)
(Индикатор свёрнутого текста (свёрнутый)
Индикатор свёрнутого текста (развёрнутый))
Цвета индикаторов и фона индикаторов можно устанавливать независимо друг от друга.
3. Сохранение шрифта при смене темы
Последнее обновление в VS 2022 позволяет переключать темы, не влияя на настройки шрифтов. Эта функция сохраняет выбранный шрифт и размер независимо от выбранной темы, в то время как цвета шрифтов продолжают адаптироваться к теме. Перейдите в Tools > Options > Environment > Manage Preview Features и найдите настройку Separate font settings from color theme selection (Отделить настройки шрифтов от выбора цветовой темы). Снятие этого флажка привяжет ваш шрифт напрямую к теме.
Источники:
- https://devblogs.microsoft.com/visualstudio/customize-your-ai-generated-git-commit-messages/
- https://devblogs.microsoft.com/visualstudio/customizing-collapsed-text-indicators/
- https://devblogs.microsoft.com/visualstudio/your-fonts-are-now-preserved-when-changing-theme/
Новинки в Visual Studio 2022
Несколько новинок было представлено в VS 2022 с начала года.
1. Настройка сообщений коммита, сгенерированных ИИ
VS уже какое-то время назад представила автоматическую генерацию сообщений коммита с помощью ИИ, описывая сделанные вами изменения. У меня нет большого опыта её использования, но несколько раз пробовал, и получается довольно неплохо (по крайней мере, по-английски). Нынешняя новинка позволяет вам легко адаптировать сообщения о коммитах в соответствии с вашим рабочим процессом и стандартами команды: указать количество и длину строк, стиль сообщения и т.п. Copilot понимает такие термины, как «тема», «тело» и «нижний колонтитул». Например (буду использовать примеры по-английски, т.к. на русском не пробовал):
Use all lowercase
Limit subject to 50 characters
Limit body to 2 sentences
Add a footer with three hash marks
Follow Conventional Commits standard
Чтобы это настроить, перейдите в Tools > Options > GitHub > Copilot (Инструменты > Параметры > GitHub > Copilot) и введите нужные параметры.
2. Настройка индикаторов свёрнутого текста
Теперь вы можете персонализировать цвет и фон индикатора свёрнутого текста в редакторе, установив пользовательские цвета для индикаторов свёрнутого и развёрнутого текста в отдельности. Эта функция доступна через меню Tools > Options > Environment > Fonts and Colors (Инструменты > Параметры > Среда > Шрифты и цвета).
Две новые записи в списке настроек редактора тестов, которые управляют цветом индикатора свернутого текста:
- Collapsed Text Indicator (Collapsed)
- Collapsed Text Indicator (Expanded)
(Индикатор свёрнутого текста (свёрнутый)
Индикатор свёрнутого текста (развёрнутый))
Цвета индикаторов и фона индикаторов можно устанавливать независимо друг от друга.
3. Сохранение шрифта при смене темы
Последнее обновление в VS 2022 позволяет переключать темы, не влияя на настройки шрифтов. Эта функция сохраняет выбранный шрифт и размер независимо от выбранной темы, в то время как цвета шрифтов продолжают адаптироваться к теме. Перейдите в Tools > Options > Environment > Manage Preview Features и найдите настройку Separate font settings from color theme selection (Отделить настройки шрифтов от выбора цветовой темы). Снятие этого флажка привяжет ваш шрифт напрямую к теме.
Источники:
- https://devblogs.microsoft.com/visualstudio/customize-your-ai-generated-git-commit-messages/
- https://devblogs.microsoft.com/visualstudio/customizing-collapsed-text-indicators/
- https://devblogs.microsoft.com/visualstudio/your-fonts-are-now-preserved-when-changing-theme/
👍6
День 2205. #Testing
Нагрузочное Тестирование с Помощью K6 в Windows. Начало
Понимание того, как ваша система реагирует на входящий сетевой трафик, имеет решающее значение для определения ее стабильности, способности соответствовать ожидаемому SLO и исправности базовой инфраструктуры и архитектуры. Рассмотрим, как использовать K6 для запуска нагрузочных тестов и локального отображения конечного результата.
Что это?
Нагрузочное тестирование имитирует реальные условия использования, чтобы убедиться, что ПО может обрабатывать большой трафик без ущерба для производительности или пользовательского опыта. Его важность заключается в способности выявлять узкие места в системе, которые могут привести к медленному времени отклика, ошибкам или сбоям в условиях нагрузки.
Проводя нагрузочное тестирование, разработчики могут вносить необходимые оптимизации и улучшения, гарантируя, что ПО будет надёжным, стабильным и масштабируемым. Система, неспособная обрабатывать большой входящий трафик, может полностью или частично выйти из строя, что приведёт к недовольству пользователей, потере дохода и ущербу репутации компании.
В идеале вы должны запланировать наличие автоматических нагрузочных тестов в конвейерах непрерывной доставки или, по крайней мере, убедиться, что вы время от времени запускаете нагрузочные тесты в своей производственной среде, а затем сравниваете результаты тестирования с предыдущими, чтобы убедиться, что вы не создали узкие места в последних выпусках.
Демо проект
Создадим простой проект .NET API. Одна конечная точка,
Здесь добавлены:
- случайная задержка delayMs, эмулирующая запрос из БД;
- потокобезопасный счётчик параллельных операций concurrency;
- логирование сообщений внутри lock для избежания проблем параллелизма.
Это, конечно, не идеальное решение, но оно подойдёт для демонстрации.
Далее посмотрим, как провести нагрузочное тестирование этого API.
Продолжение следует…
Источник: https://www.code4it.dev/blog/k6-load-testing/
Нагрузочное Тестирование с Помощью K6 в Windows. Начало
Понимание того, как ваша система реагирует на входящий сетевой трафик, имеет решающее значение для определения ее стабильности, способности соответствовать ожидаемому SLO и исправности базовой инфраструктуры и архитектуры. Рассмотрим, как использовать K6 для запуска нагрузочных тестов и локального отображения конечного результата.
Что это?
Нагрузочное тестирование имитирует реальные условия использования, чтобы убедиться, что ПО может обрабатывать большой трафик без ущерба для производительности или пользовательского опыта. Его важность заключается в способности выявлять узкие места в системе, которые могут привести к медленному времени отклика, ошибкам или сбоям в условиях нагрузки.
Проводя нагрузочное тестирование, разработчики могут вносить необходимые оптимизации и улучшения, гарантируя, что ПО будет надёжным, стабильным и масштабируемым. Система, неспособная обрабатывать большой входящий трафик, может полностью или частично выйти из строя, что приведёт к недовольству пользователей, потере дохода и ущербу репутации компании.
В идеале вы должны запланировать наличие автоматических нагрузочных тестов в конвейерах непрерывной доставки или, по крайней мере, убедиться, что вы время от времени запускаете нагрузочные тесты в своей производственной среде, а затем сравниваете результаты тестирования с предыдущими, чтобы убедиться, что вы не создали узкие места в последних выпусках.
Демо проект
Создадим простой проект .NET API. Одна конечная точка,
/randombook, которая возвращает информацию о случайной книге, хранящейся в БД в памяти:int requests = 0;
int concurrency = 0;
object _lock = new();
app.MapGet("/randombook", async (CancellationToken ct) =>
{
Book? book = default;
var delayMs = Random.Shared.Next(10, 10000);
try
{
lock (_lock)
{
requests++;
concurrency++;
app.Logger.LogInformation(
@"Request {Count}.
Concurrent Executions {Executions}.
Delay: {DelayMs}ms",
requests, concurrency, delayMs);
}
using var ctx = new ApiContext();
await Task.Delay(delayMs, ct);
if (ct.IsCancellationRequested)
{
app.Logger.LogWarning("Cancelled");
throw new OperationCanceledException();
}
var books = await ctx.Books.ToArrayAsync();
book = Random.Shared
.GetItems(books, 1).First();
}
catch (Exception ex)
{
app.Logger.LogError(ex, "Error ");
return Results.Problem(ex.Message);
}
finally
{
lock (_lock)
{
concurrency--;
}
}
return TypedResults.Ok(book);
});
Здесь добавлены:
- случайная задержка delayMs, эмулирующая запрос из БД;
- потокобезопасный счётчик параллельных операций concurrency;
- логирование сообщений внутри lock для избежания проблем параллелизма.
Это, конечно, не идеальное решение, но оно подойдёт для демонстрации.
Далее посмотрим, как провести нагрузочное тестирование этого API.
Продолжение следует…
Источник: https://www.code4it.dev/blog/k6-load-testing/
1👍18
День 2206. #ЗаметкиНаПолях #Testing
Нагрузочное Тестирование с Помощью K6 в Windows. Продолжение
Начало
Запуск K6 в Windows
С помощью K6 вы можете запустить нагрузочные тесты, определив конечную точку для вызова, количество запросов в минуту и некоторые другие настройки.
Этот бесплатный инструмент можно установить с помощью Winget:
Проверить правильность установки можно через командную строку (не Powershell):
Теперь можно инициализировать инструмент:
Команда сгенерирует файл script.js, в котором надо будет настроить конфигурацию тестов. Например:
Здесь:
-
-
-
-
То есть, в течение 30 секунд k6 будет посылать до 10 параллельных запросов, потом ждать 1 секунду, и повторять. После он истечения времени теста, он даст ещё 30 секунд приложению, чтобы завершить текущие запросы.
Для запуска убедитесь, что API запущен, и выполните следующую команду:
В консоли API мы увидим логи запросов:
А в консоли k6 отчёт вроде представленного на рисунке выше.
Окончание следует…
Источник: https://www.code4it.dev/blog/k6-load-testing/
Нагрузочное Тестирование с Помощью K6 в Windows. Продолжение
Начало
Запуск K6 в Windows
С помощью K6 вы можете запустить нагрузочные тесты, определив конечную точку для вызова, количество запросов в минуту и некоторые другие настройки.
Этот бесплатный инструмент можно установить с помощью Winget:
winget install k6 --source winget
Проверить правильность установки можно через командную строку (не Powershell):
k6 --version
Теперь можно инициализировать инструмент:
k6 new
Команда сгенерирует файл script.js, в котором надо будет настроить конфигурацию тестов. Например:
import http from "k6/http"
import { sleep } from "k6"
export const options = {
vus: 10,
duration: "30s",
}
export default function () {
http.get("https://localhost:7123/randombook")
sleep(1)
}
Здесь:
-
vus: 10 - виртуальные пользователи, симулирующие параллельные входящие запросы;-
duration: "30s" – общее время теста;-
http.get("https://…") - основная функция, вызывающая конечную точку и считающая ответы, метрики, тайминг и т.п.;-
sleep(1) – время паузы между итерациями.То есть, в течение 30 секунд k6 будет посылать до 10 параллельных запросов, потом ждать 1 секунду, и повторять. После он истечения времени теста, он даст ещё 30 секунд приложению, чтобы завершить текущие запросы.
Для запуска убедитесь, что API запущен, и выполните следующую команду:
k6 run script.js
В консоли API мы увидим логи запросов:
[15:19:51 INF] Request 1. Concurrent Executions 1. Delay: 7124ms
[15:20:02 INF] Request 2. Concurrent Executions 1. Delay: 4981ms
…
[15:20:27 INF] Request 57. Concurrent Executions 10. Delay: 7655ms
А в консоли k6 отчёт вроде представленного на рисунке выше.
Окончание следует…
Источник: https://www.code4it.dev/blog/k6-load-testing/
👍12
День 2207. #ЗаметкиНаПолях #Testing
Нагрузочное Тестирование с Помощью K6 в Windows. Окончание
Начало
Продолжение
Отчёт
Вернёмся к отчёту, показанному на картинке в предыдущем посте. Либо, установив 2 переменные окружения, вы можете получить более визуально приятный отчёт в виде HTML документа, показанного на рисунке выше.
В отчёте множество значений, названия которых в основном говорят сами за себя:
- data_received и data_sent - размер отправленных и полученных данных;
- продолжительность и ответы HTTP-запросов (http_req_duration, http_req_sending, http_reqs);
- информация о фазах HTTP-соединения, например http_req_tls_handshaking;
- конфигурации K6 (iterations, vus и vus_max).
Вы можете увидеть среднее значение, минимальное и максимальное значение, а также некоторые процентили для большинства значений.
Прочие настройки нагрузочного тестирования
В официальной документации K6 есть много информации, поэтому рассмотрим лишь некоторые основные настройки.
HTTP-методы
Мы использовали только метод GET, но можно использовать все доступные HTTP-методы с помощью соответствующей функции Javascript:
-
-
-
-
Стадии
Вы можете определить несколько стадий тестирования, например:
Здесь определены 3 стадии:
1. 30 сек – нагрузка в 20 виртуальных пользователей,
2. 1м 30 сек – 10,
3. 20 сек – время на завершение оставшихся запросов.
Сценарии
Сценарии позволяют определять детали итерации запросов. Мы можем определять пользовательские сценарии, чтобы настраивать различные параметры, используемые для определения того, как должен действовать тест.
Сценарий — это элемент JSON, в котором вы определяете аргументы, такие как продолжительность, количество пользователей (как мы рассмотрели выше), а также переменные среды, время старта и т.д. Определив сценарий, вы можете запустить тесты на той же конечной точке, но с использованием разных поведений. Например, создать один сценарий для постепенного роста пользователей, a другой - для резкого взлёта их количества.
Источник: https://www.code4it.dev/blog/k6-load-testing/
Нагрузочное Тестирование с Помощью K6 в Windows. Окончание
Начало
Продолжение
Отчёт
Вернёмся к отчёту, показанному на картинке в предыдущем посте. Либо, установив 2 переменные окружения, вы можете получить более визуально приятный отчёт в виде HTML документа, показанного на рисунке выше.
set K6_WEB_DASHBOARD=true
set K6_WEB_DASHBOARD_EXPORT=html-report.html
k6 run script.js
В отчёте множество значений, названия которых в основном говорят сами за себя:
- data_received и data_sent - размер отправленных и полученных данных;
- продолжительность и ответы HTTP-запросов (http_req_duration, http_req_sending, http_reqs);
- информация о фазах HTTP-соединения, например http_req_tls_handshaking;
- конфигурации K6 (iterations, vus и vus_max).
Вы можете увидеть среднее значение, минимальное и максимальное значение, а также некоторые процентили для большинства значений.
Прочие настройки нагрузочного тестирования
В официальной документации K6 есть много информации, поэтому рассмотрим лишь некоторые основные настройки.
HTTP-методы
Мы использовали только метод GET, но можно использовать все доступные HTTP-методы с помощью соответствующей функции Javascript:
-
get() – метод GET, -
post() - метод POST,-
put() - метод PUT,-
del() - метод DELETE.Стадии
Вы можете определить несколько стадий тестирования, например:
export const options = {
stages: [
{ duration: "30s", target: 20 },
{ duration: "1m30s", target: 10 },
{ duration: "20s", target: 0 },
],
}Здесь определены 3 стадии:
1. 30 сек – нагрузка в 20 виртуальных пользователей,
2. 1м 30 сек – 10,
3. 20 сек – время на завершение оставшихся запросов.
Сценарии
Сценарии позволяют определять детали итерации запросов. Мы можем определять пользовательские сценарии, чтобы настраивать различные параметры, используемые для определения того, как должен действовать тест.
Сценарий — это элемент JSON, в котором вы определяете аргументы, такие как продолжительность, количество пользователей (как мы рассмотрели выше), а также переменные среды, время старта и т.д. Определив сценарий, вы можете запустить тесты на той же конечной точке, но с использованием разных поведений. Например, создать один сценарий для постепенного роста пользователей, a другой - для резкого взлёта их количества.
Источник: https://www.code4it.dev/blog/k6-load-testing/
👍9
Какие приложения вы в основном (чаще раза в год) разрабатываете на .NET?
Anonymous Poll
58%
веб-API (для внешних клиентов)
55%
веб-сервисы (в микросервисной среде)
15%
веб-сайты (MVC, Razor pages)
8%
Blazor-приложения
19%
десктоп приложения Windows Forms/сервисы под Windows
5%
кросс-платформенные/мобильные приложения
19%
небольшие консольные скрипты
3%
игры
19%
библиотеки/NuGet-пакеты
4%
другое (напишите в комментариях)
👍1
День 2208. #Книги
В подарок на шестилетие канала от издательства «Питер» пришла книга «Kubernetes для разработчиков» Уильяма Денниса.
Книга только что вышла в печать. Издательству «Питер» большое спасибо. Почитаю и оценю.
В подарок на шестилетие канала от издательства «Питер» пришла книга «Kubernetes для разработчиков» Уильяма Денниса.
Книга только что вышла в печать. Издательству «Питер» большое спасибо. Почитаю и оценю.
👍26
День 2209.
Сегодня порекомендую вам интервью, которое Руслан Шишмарев взял у какого-то левого мутного чувака, застрявшего на одном месте работы в жутком легаси. Но почему-то Руслан решил поспрашивать его про смену работы, собесы, карьерные пути и новые технологии)))
В общем, не буду пересказывать свои путаные мысли. Кому некуда деть полтора часа, гляньте. И не судите строго, это моё первое живое интервью (из увидевших свет, по крайней мере).
https://youtu.be/XMr6KP8U3pY
Сегодня порекомендую вам интервью, которое Руслан Шишмарев взял у какого-то левого мутного чувака, застрявшего на одном месте работы в жутком легаси. Но почему-то Руслан решил поспрашивать его про смену работы, собесы, карьерные пути и новые технологии)))
В общем, не буду пересказывать свои путаные мысли. Кому некуда деть полтора часа, гляньте. И не судите строго, это моё первое живое интервью (из увидевших свет, по крайней мере).
https://youtu.be/XMr6KP8U3pY
YouTube
ПРОГРАММИСТ С БОЛЬШИМ ОПЫТОМ | Сергей Бензенко
Друзья, у меня для вас крутейший гость! Сегодня в новом выпуске подкаста Сергей Бензенко. .NET-разработчик с колоссальным опытом - целых 18 лет в IT, причем 17 из них в одной компании! Да-да, вы все правильно поняли. В эпоху частых смен работы и проектов…
10👍40👎1