День девятьсот четырнадцатый. #Оффтоп
Участники нашего чата знают, что я в последнее время приглядывал себе офисное кресло для работы. Старое прослужило лет 5 или 7. Не могу сказать, что верой и правдой, т.к. газлифт на нём стал шалить буквально через пару месяцев после покупки. Все 5 лет хотел довезти его до сервиса, но, видно, не судьба. В итоге недавно что-то в нём сломалось окончательно, и спинка тоже отказалась держать меня в вертикальном положении.
Решил купить новое кресло, и остановился на модели Samurai S2.04 (на фото). В чате посоветовали рассмотреть сетку, и мне вполне понравилось. Не так проваливаешься, как в подушку. Нижним полушариям с непривычки немного жестковато, зато стимулирует работать в режиме 25-5 (об этом тут).
Использую уже больше недели, пока всё устраивает. Нужные места продуваются и не потеют, поднимается довольно высоко, крепко держит спину вертикально, удобный упор для поясницы, подголовник тоже вполне неплох. И бонусом пристёгивающаяся подушка «на зиму».
Участники нашего чата знают, что я в последнее время приглядывал себе офисное кресло для работы. Старое прослужило лет 5 или 7. Не могу сказать, что верой и правдой, т.к. газлифт на нём стал шалить буквально через пару месяцев после покупки. Все 5 лет хотел довезти его до сервиса, но, видно, не судьба. В итоге недавно что-то в нём сломалось окончательно, и спинка тоже отказалась держать меня в вертикальном положении.
Решил купить новое кресло, и остановился на модели Samurai S2.04 (на фото). В чате посоветовали рассмотреть сетку, и мне вполне понравилось. Не так проваливаешься, как в подушку. Нижним полушариям с непривычки немного жестковато, зато стимулирует работать в режиме 25-5 (об этом тут).
Использую уже больше недели, пока всё устраивает. Нужные места продуваются и не потеют, поднимается довольно высоко, крепко держит спину вертикально, удобный упор для поясницы, подголовник тоже вполне неплох. И бонусом пристёгивающаяся подушка «на зиму».
День девятьсот пятнадцатый. #DesignPatterns #Microservices
Паттерны в Микросервисах
8. Прерыватель Цепи (Circuit Breaker)
В микросервисной архитектуре, где микросервисы обмениваются данными синхронно, один микросервис обычно вызывает другие сервисы для выполнения бизнес-логики. Вызов другого сервиса может завершиться ошибкой из-за временных сбоев (медленное сетевое соединение, тайм-ауты или временная недоступность). В таких случаях повторные вызовы могут решить проблему. Однако, если есть серьёзная проблема (полный отказ микросервиса), сервис будет недоступен в течение более длительного времени. Выполнение повторных попыток бессмысленно и впустую тратит драгоценные ресурсы (блокируется поток, тратятся циклы ЦП). Кроме того, отказ одного сервиса может привести к каскадным сбоям во всем приложении. В таких сценариях немедленный отказ - лучший подход.
В таких случаях на помощь может прийти паттерн «Прерыватель Цепи». Микросервис запрашивает другой сервис через прокси-сервер, который работает аналогично электрическому выключателю. Прокси-сервер должен подсчитывать количество недавних сбоев и использовать эти данные, чтобы решить, разрешить ли выполнение операции или просто немедленно вернуть исключение. См. картинку ниже.
Прерыватель цепи может находиться в следующих трёх состояниях:
- Замкнут: прерыватель цепи направляет запросы в микросервис и подсчитывает количество сбоев за заданный период времени. Если количество отказов за определённый период времени превышает пороговое значение, он отключается и переходит в разомкнутое состояние.
- Разомкнут: запрос от микросервиса немедленно завершается ошибкой, и возвращается исключение. По истечении времени ожидания прерыватель цепи переходит в полузамкнутое состояние.
- Полузамкнут: только ограниченное количество запросов от микросервиса может пройти и вызвать выполнение операции. Если эти запросы выполнены успешно, прерыватель цепи переходит в замкнутое состояние. Если какой-либо запрос терпит неудачу, прерыватель цепи переходит в разомкнутое состояние.
Преимущества
- Повышение отказоустойчивости микросервисной архитектуры.
- Прерывание каскадной передачи сбоев в другие микросервисы.
Недостатки
- Нужна сложная обработка исключений.
- Дополнительное логирование и мониторинг.
- Необходимость поддержки ручного сброса.
Когда использовать
- В тесно связанной микросервисной архитектуре, где микросервисы обмениваются данными синхронно.
- Если один микросервис зависит от нескольких других микросервисов.
Когда не использовать
- Слабо связанная микросервисная архитектура, управляемая событиями.
- Если микросервис не зависит от других микросервисов.
Поддержка
API Gateway, Service Mesh, various Circuit Breaker Libraries (Hystrix, Reselience4J, Polly.
Подробнее
- Паттерн Прерыватель Цепи
- Microservices Pattern: Circuit Breaker
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Паттерны в Микросервисах
8. Прерыватель Цепи (Circuit Breaker)
В микросервисной архитектуре, где микросервисы обмениваются данными синхронно, один микросервис обычно вызывает другие сервисы для выполнения бизнес-логики. Вызов другого сервиса может завершиться ошибкой из-за временных сбоев (медленное сетевое соединение, тайм-ауты или временная недоступность). В таких случаях повторные вызовы могут решить проблему. Однако, если есть серьёзная проблема (полный отказ микросервиса), сервис будет недоступен в течение более длительного времени. Выполнение повторных попыток бессмысленно и впустую тратит драгоценные ресурсы (блокируется поток, тратятся циклы ЦП). Кроме того, отказ одного сервиса может привести к каскадным сбоям во всем приложении. В таких сценариях немедленный отказ - лучший подход.
В таких случаях на помощь может прийти паттерн «Прерыватель Цепи». Микросервис запрашивает другой сервис через прокси-сервер, который работает аналогично электрическому выключателю. Прокси-сервер должен подсчитывать количество недавних сбоев и использовать эти данные, чтобы решить, разрешить ли выполнение операции или просто немедленно вернуть исключение. См. картинку ниже.
Прерыватель цепи может находиться в следующих трёх состояниях:
- Замкнут: прерыватель цепи направляет запросы в микросервис и подсчитывает количество сбоев за заданный период времени. Если количество отказов за определённый период времени превышает пороговое значение, он отключается и переходит в разомкнутое состояние.
- Разомкнут: запрос от микросервиса немедленно завершается ошибкой, и возвращается исключение. По истечении времени ожидания прерыватель цепи переходит в полузамкнутое состояние.
- Полузамкнут: только ограниченное количество запросов от микросервиса может пройти и вызвать выполнение операции. Если эти запросы выполнены успешно, прерыватель цепи переходит в замкнутое состояние. Если какой-либо запрос терпит неудачу, прерыватель цепи переходит в разомкнутое состояние.
Преимущества
- Повышение отказоустойчивости микросервисной архитектуры.
- Прерывание каскадной передачи сбоев в другие микросервисы.
Недостатки
- Нужна сложная обработка исключений.
- Дополнительное логирование и мониторинг.
- Необходимость поддержки ручного сброса.
Когда использовать
- В тесно связанной микросервисной архитектуре, где микросервисы обмениваются данными синхронно.
- Если один микросервис зависит от нескольких других микросервисов.
Когда не использовать
- Слабо связанная микросервисная архитектура, управляемая событиями.
- Если микросервис не зависит от других микросервисов.
Поддержка
API Gateway, Service Mesh, various Circuit Breaker Libraries (Hystrix, Reselience4J, Polly.
Подробнее
- Паттерн Прерыватель Цепи
- Microservices Pattern: Circuit Breaker
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
👍2
День девятьсот шестнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
93. Пишите код так, как если бы вам пришлось поддерживать его всю оставшуюся жизнь
Спросите сотню программистов, что самое важное должен знать и делать каждый программист, и вы можете получить сотню разных ответов. Это пугающе много советов. Все советы хороши, все принципы верны, и все истории убедительны, но с чего начать? И главное, как начать и продолжить придерживаться всех лучших практик, которые вы усвоили, и как сделать их неотъемлемой частью своей практики программирования?
Я думаю, что ответ кроется в вашем настрое или, проще говоря, в вашем отношении. Если вас не заботят коллеги-разработчики, тестировщики, менеджеры, специалисты по продажам и маркетингу, а также конечные пользователи, то вы не станете, например, использовать разработку через тестирование или писать ясные комментарии https://t.iss.one/NetDeveloperDiary/1109 в своем коде. Я думаю, что есть простой способ изменить свое отношение и всегда стремиться поставлять продукт самого высокого качества:
«Пишите код так, как будто вам придётся поддерживать его всю оставшуюся жизнь.»
Вот и всё. Если вы примете это правило, произойдёт много чудесных вещей. Если бы вы согласились с тем, что любой из ваших предыдущих или нынешних работодателей имел право позвонить вам посреди ночи и попросить вас объяснить, почему вы именно так написали метод fooBar, вы бы постепенно стали профессиональным программистом. Вы, естественно, захотели бы придумывать лучшие имена переменных и методов. Вы бы держались подальше от блоков кода, состоящих из сотен строк. Вы бы искали, изучали и использовали паттерны проектирования https://t.iss.one/NetDeveloperDiary/361. Вы должны были бы постоянно писать комментарии, тестировать свой код и проводить рефакторинг. Поддержка всего кода, который вы когда-либо писали, до конца своей жизни, также должна быть масштабируемой задачей. Поэтому у вас не было бы выбора, кроме как стать лучше, умнее и эффективнее.
Если задуматься, то код, который вы написали много лет назад, по-прежнему влияет на вашу карьеру, нравится вам это или нет. Вы оставляете след своих знаний, отношения, упорства, профессионализма, обязательности и удовлетворённости в каждом методе, классе и модуле, которые вы разрабатываете и пишете. Люди будут формировать мнение о вас на основе кода, который они видят. Если эти мнения будут постоянно отрицательными, вы получите меньше от своей карьеры, чем рассчитывали. Позаботьтесь о своей карьере, о своих клиентах и о своих пользователях в каждой строчке кода: пишите код так, как будто вы должны будете поддерживать его всю оставшуюся жизнь.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yuriy Zubarev
97 Вещей, Которые Должен Знать Каждый Программист
93. Пишите код так, как если бы вам пришлось поддерживать его всю оставшуюся жизнь
Спросите сотню программистов, что самое важное должен знать и делать каждый программист, и вы можете получить сотню разных ответов. Это пугающе много советов. Все советы хороши, все принципы верны, и все истории убедительны, но с чего начать? И главное, как начать и продолжить придерживаться всех лучших практик, которые вы усвоили, и как сделать их неотъемлемой частью своей практики программирования?
Я думаю, что ответ кроется в вашем настрое или, проще говоря, в вашем отношении. Если вас не заботят коллеги-разработчики, тестировщики, менеджеры, специалисты по продажам и маркетингу, а также конечные пользователи, то вы не станете, например, использовать разработку через тестирование или писать ясные комментарии https://t.iss.one/NetDeveloperDiary/1109 в своем коде. Я думаю, что есть простой способ изменить свое отношение и всегда стремиться поставлять продукт самого высокого качества:
«Пишите код так, как будто вам придётся поддерживать его всю оставшуюся жизнь.»
Вот и всё. Если вы примете это правило, произойдёт много чудесных вещей. Если бы вы согласились с тем, что любой из ваших предыдущих или нынешних работодателей имел право позвонить вам посреди ночи и попросить вас объяснить, почему вы именно так написали метод fooBar, вы бы постепенно стали профессиональным программистом. Вы, естественно, захотели бы придумывать лучшие имена переменных и методов. Вы бы держались подальше от блоков кода, состоящих из сотен строк. Вы бы искали, изучали и использовали паттерны проектирования https://t.iss.one/NetDeveloperDiary/361. Вы должны были бы постоянно писать комментарии, тестировать свой код и проводить рефакторинг. Поддержка всего кода, который вы когда-либо писали, до конца своей жизни, также должна быть масштабируемой задачей. Поэтому у вас не было бы выбора, кроме как стать лучше, умнее и эффективнее.
Если задуматься, то код, который вы написали много лет назад, по-прежнему влияет на вашу карьеру, нравится вам это или нет. Вы оставляете след своих знаний, отношения, упорства, профессионализма, обязательности и удовлетворённости в каждом методе, классе и модуле, которые вы разрабатываете и пишете. Люди будут формировать мнение о вас на основе кода, который они видят. Если эти мнения будут постоянно отрицательными, вы получите меньше от своей карьеры, чем рассчитывали. Позаботьтесь о своей карьере, о своих клиентах и о своих пользователях в каждой строчке кода: пишите код так, как будто вы должны будете поддерживать его всю оставшуюся жизнь.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yuriy Zubarev
День девятьсот семнадцатый. #Оффтоп
Отбываю в (очень) жаркую страну отдохнуть. Посты продолжат выходить, но, возможно, не такие информативные, как обычно.
А пока сообщу вам, что у нас появилось сообщество на Яндекс.Кью, куда будут дублироваться посты, и где можно пообщаться отдельно. Зачем это всё надо, я пока не совсем понимаю. Просто предложили сделать автопостинг туда, ну пусть будет. Выживет так выживет. Да, посты пока туда публикуются немного криво. Не обессудьте, все вопросы в Яндекс.Кью :)
Ну и напоследок, вот вам очередной комикс от Monkeyuser. Ставь лойс, если он вызвал страшные флешбеки)))
Отбываю в (очень) жаркую страну отдохнуть. Посты продолжат выходить, но, возможно, не такие информативные, как обычно.
А пока сообщу вам, что у нас появилось сообщество на Яндекс.Кью, куда будут дублироваться посты, и где можно пообщаться отдельно. Зачем это всё надо, я пока не совсем понимаю. Просто предложили сделать автопостинг туда, ну пусть будет. Выживет так выживет. Да, посты пока туда публикуются немного криво. Не обессудьте, все вопросы в Яндекс.Кью :)
Ну и напоследок, вот вам очередной комикс от Monkeyuser. Ставь лойс, если он вызвал страшные флешбеки)))
День девятьсот восемнадцатый. #Оффтоп
Неожиданные Преимущества Наставничества. Начало
В какой-то момент вашей карьеры вам вполне могут посоветовать поискать наставника. Идея в том, что, если вас направляет кто-то, кто продвинулся дальше на своём пути, вы сможете двигаться быстрее на своём. Чаще всего это правильный совет. Наличие наставника может дать вам бесценную информацию, наставник может оказать индивидуальную поддержку и заставить вас думать так, как вы иначе не стали бы. Однако сегодня рассмотрим, какие преимущества вам может принести быть наставником для других.
1. Углубляйте знания, обучая других
Изучая что-то новое, большинство людей сосредотачиваются на теории. Они берут новый курс, следуют инструкциям и думают, что дело сделано. Гораздо меньшее количество людей затем приступают к применению полученных знаний на практике. Ещё меньше людей решают учить этому других. Не пройдя весь процесс: изучение теории, практика, обучение других, - вы можете упустить важные нюансы на пути к мастерству.
Даже если вам кажется, что вы знакомы с предметом, всегда найдутся новые подходы и способы осмыслить тему. Обучая других, вам нужно не просто понимать теорию. Вам необходимо так сформулировать основные концепции, чтобы другие поняли и усвоили их. Объяснение концепций другим - отличный способ укрепить и углубить свои знания.
Люди подходят к проблемам с разных сторон. Если вы не отвечаете на вопросы и не решаете проблемы других людей, вы видите предмет только с одной стороны. Часто существует множество способов добиться одного и того же результата. Я обнаружил, что мои ментальные модели и подходы к решению проблем менялись, когда я общался с разработчиками разных уровней опыта.
2. Наставничество улучшает софт скилы
В любой профессии ваш набор навыков можно разделить на две категории: «жёсткие» (hard) и «мягкие» (soft). Жёсткие навыки, как правило, представляют собой «техническую» часть вашей профессии (написание кода, разработка архитектуры, контроль версий и т. д.). Мягкие навыки, такие как общение и командная работа, труднее поддаются количественной оценке. Наставляя других, вы обучаете жёстким навыкам, используя свои мягкие навыки, и у вас обоих есть шанс стать лучше.
Мы уделяем много внимания обучению жёстким навыкам. У нас есть множество курсов, учебных пособий и руководств, рассказывающих о новейших и лучших инструментах и технологиях. Но часто именно ваши мягкие навыки выделяют вас среди других в вашей области.
Хотя это и не строгое правило, вы часто можете слышать, как люди говорят, что они предпочли бы работать с менее технически одарёнными, но более разносторонними товарищами по команде, чем с пресловутой «рок-звездой» без мягких навыков. Время, потраченное на улучшение ваших коммуникативных навыков, командной работы и лидерства путем наставничества других, сделает вас лучше как товарища по команде в вашей профессиональной жизни и не будет потрачено зря.
3. Новые знакомства и построение прочных отношений
Существует не так много способов лучше произвести на кого-то неизгладимое впечатление, чем показать свою готовность помочь человеку и направить его на правильный путь. Наставничество - отличный способ познакомиться с другими людьми из вашей области и расширить круг знакомств.
Ваша профессиональная жизнь - это не только работа, которую вы делаете; это также люди, которых вы встречаете на своем пути. Вы никогда не знаете, кого вы можете встретить, каких друзей и знакомых заведёте. Я до сих пор поддерживаю контакты со многими людьми, которых учил, и даже получил множество запросов на собеседование от компаний, в которых бывший студент рекомендовал меня на должность.
Окончание следует…
Источник: https://stackoverflow.blog/2021/07/07/the-unexpected-benefits-of-mentoring-others/
Автор оригинала - Matt Studdert
Неожиданные Преимущества Наставничества. Начало
В какой-то момент вашей карьеры вам вполне могут посоветовать поискать наставника. Идея в том, что, если вас направляет кто-то, кто продвинулся дальше на своём пути, вы сможете двигаться быстрее на своём. Чаще всего это правильный совет. Наличие наставника может дать вам бесценную информацию, наставник может оказать индивидуальную поддержку и заставить вас думать так, как вы иначе не стали бы. Однако сегодня рассмотрим, какие преимущества вам может принести быть наставником для других.
1. Углубляйте знания, обучая других
Изучая что-то новое, большинство людей сосредотачиваются на теории. Они берут новый курс, следуют инструкциям и думают, что дело сделано. Гораздо меньшее количество людей затем приступают к применению полученных знаний на практике. Ещё меньше людей решают учить этому других. Не пройдя весь процесс: изучение теории, практика, обучение других, - вы можете упустить важные нюансы на пути к мастерству.
Даже если вам кажется, что вы знакомы с предметом, всегда найдутся новые подходы и способы осмыслить тему. Обучая других, вам нужно не просто понимать теорию. Вам необходимо так сформулировать основные концепции, чтобы другие поняли и усвоили их. Объяснение концепций другим - отличный способ укрепить и углубить свои знания.
Люди подходят к проблемам с разных сторон. Если вы не отвечаете на вопросы и не решаете проблемы других людей, вы видите предмет только с одной стороны. Часто существует множество способов добиться одного и того же результата. Я обнаружил, что мои ментальные модели и подходы к решению проблем менялись, когда я общался с разработчиками разных уровней опыта.
2. Наставничество улучшает софт скилы
В любой профессии ваш набор навыков можно разделить на две категории: «жёсткие» (hard) и «мягкие» (soft). Жёсткие навыки, как правило, представляют собой «техническую» часть вашей профессии (написание кода, разработка архитектуры, контроль версий и т. д.). Мягкие навыки, такие как общение и командная работа, труднее поддаются количественной оценке. Наставляя других, вы обучаете жёстким навыкам, используя свои мягкие навыки, и у вас обоих есть шанс стать лучше.
Мы уделяем много внимания обучению жёстким навыкам. У нас есть множество курсов, учебных пособий и руководств, рассказывающих о новейших и лучших инструментах и технологиях. Но часто именно ваши мягкие навыки выделяют вас среди других в вашей области.
Хотя это и не строгое правило, вы часто можете слышать, как люди говорят, что они предпочли бы работать с менее технически одарёнными, но более разносторонними товарищами по команде, чем с пресловутой «рок-звездой» без мягких навыков. Время, потраченное на улучшение ваших коммуникативных навыков, командной работы и лидерства путем наставничества других, сделает вас лучше как товарища по команде в вашей профессиональной жизни и не будет потрачено зря.
3. Новые знакомства и построение прочных отношений
Существует не так много способов лучше произвести на кого-то неизгладимое впечатление, чем показать свою готовность помочь человеку и направить его на правильный путь. Наставничество - отличный способ познакомиться с другими людьми из вашей области и расширить круг знакомств.
Ваша профессиональная жизнь - это не только работа, которую вы делаете; это также люди, которых вы встречаете на своем пути. Вы никогда не знаете, кого вы можете встретить, каких друзей и знакомых заведёте. Я до сих пор поддерживаю контакты со многими людьми, которых учил, и даже получил множество запросов на собеседование от компаний, в которых бывший студент рекомендовал меня на должность.
Окончание следует…
Источник: https://stackoverflow.blog/2021/07/07/the-unexpected-benefits-of-mentoring-others/
Автор оригинала - Matt Studdert
👍1
День девятьсот девятнадцатый. #Оффтоп
Неожиданные Преимущества Наставничества. Окончание
Начало
4. Подтвердите свои взгляды
Как упоминалось ранее, наставничество других - отличный способ узнать точку зрения других людей. Однако наставничество также является прекрасным способом убедиться (а иногда усомниться) в ваших собственных убеждениях и любимых методиках.
Ваш опыт до этого момента в вашей карьере сформировал ваше понимание тем, которые вы выбрали для изучения. Со временем вы узнаёте, что работает, а что нет. Вы получаете знания о конкретных передовых методиках, рабочих процессах и идеях, которые могут помочь вам в повседневной жизни.
Посредством наставничества вы будете постоянно рекомендовать определённые подходы, чтобы помочь другим усовершенствовать и улучшить свои процессы. Постоянно говоря о том, что сработало для вас, вы постоянно напоминаете себе, как делать правильно, что может быть чрезвычайно ценно.
5. Повысьте ценность своего резюме
Если вы ищете новую работу, наставничество поможет повысить ваши шансы попасть в компанию и получить работу. На любую должность, на которую вы подаёте заявку, вероятно, найдется множество других разработчиков с аналогичным набором навыков.
Наставничество - отличный способ продемонстрировать свои знания, способности и энтузиазм потенциальным работодателям. Ваши подопечные могут даже выступать в качестве дополнительных рекомендаций, чтобы помочь менеджеру по найму глубже понять вашу личность и темперамент.
Демонстрация того, что вы активно помогаете другим через наставничество, может только помочь склонить чашу весов в вашу пользу.
Где наставлять других
1. Отвечать на вопросы
Stack Overflow - ярчайший пример. Если успеете! По опыту ответ на новый вопрос появляется там быстрее, чем вы успеете его напечатать, если только это не супер узкая тема. Есть русская версия, там в этом плане попроще.
2. Анализ кода и отзывы о проекте
Отзывы о проекте с открытым кодом или добавление ишью или пул реквеста - отличный способ наставлять других без каких-либо официальных обязательств. Предоставляя членам сообщества поддержку и обратную связь, вы поможете другим разработчикам улучшить свои знания и даже сможете сами научиться новым трюкам!
Обзор PR в вашей собственной компании и по проектам с открытым исходным кодом - ещё один способ помочь другим посредством анализа кода и обратной связи. Чтение чужого кода и его анализ - невероятный опыт обучения. Критическое мышление о коде и предоставление конструктивной обратной связи - это самостоятельный ценный набор навыков. Вы можете даже столкнуться с новыми ошибками, о которых раньше не задумывались, что еще больше расширит ваше понимание.
2. Наставничество один-на-один
CodingCoach - это бесплатная платформа с открытым исходным кодом, которая сводит наставников-добровольцев с подопечными.
3. Отзывы о задачах на кодирование
Если вы предпочитаете более алгоритмические упражнения, то отзывы на таких платформах, как Codewars и Exercism, могут быть идеальными. Поскольку многие люди выполняют упражнения и ждут отзывов, эти платформы всегда ищут разработчиков, которые поддержат других.
Итого
Даже если вы не совсем готовы взять на себя роль наставника, я настоятельно рекомендую попробовать. Вам не нужно знать всё о предмете, чтобы начать работу. Если вы прошли на один или два шага дальше, чем кто-то другой, вы в состоянии помочь ему. К тому же помогать другим очень приятно!
Источник: https://stackoverflow.blog/2021/07/07/the-unexpected-benefits-of-mentoring-others/
Автор оригинала - Matt Studdert
Неожиданные Преимущества Наставничества. Окончание
Начало
4. Подтвердите свои взгляды
Как упоминалось ранее, наставничество других - отличный способ узнать точку зрения других людей. Однако наставничество также является прекрасным способом убедиться (а иногда усомниться) в ваших собственных убеждениях и любимых методиках.
Ваш опыт до этого момента в вашей карьере сформировал ваше понимание тем, которые вы выбрали для изучения. Со временем вы узнаёте, что работает, а что нет. Вы получаете знания о конкретных передовых методиках, рабочих процессах и идеях, которые могут помочь вам в повседневной жизни.
Посредством наставничества вы будете постоянно рекомендовать определённые подходы, чтобы помочь другим усовершенствовать и улучшить свои процессы. Постоянно говоря о том, что сработало для вас, вы постоянно напоминаете себе, как делать правильно, что может быть чрезвычайно ценно.
5. Повысьте ценность своего резюме
Если вы ищете новую работу, наставничество поможет повысить ваши шансы попасть в компанию и получить работу. На любую должность, на которую вы подаёте заявку, вероятно, найдется множество других разработчиков с аналогичным набором навыков.
Наставничество - отличный способ продемонстрировать свои знания, способности и энтузиазм потенциальным работодателям. Ваши подопечные могут даже выступать в качестве дополнительных рекомендаций, чтобы помочь менеджеру по найму глубже понять вашу личность и темперамент.
Демонстрация того, что вы активно помогаете другим через наставничество, может только помочь склонить чашу весов в вашу пользу.
Где наставлять других
1. Отвечать на вопросы
Stack Overflow - ярчайший пример. Если успеете! По опыту ответ на новый вопрос появляется там быстрее, чем вы успеете его напечатать, если только это не супер узкая тема. Есть русская версия, там в этом плане попроще.
2. Анализ кода и отзывы о проекте
Отзывы о проекте с открытым кодом или добавление ишью или пул реквеста - отличный способ наставлять других без каких-либо официальных обязательств. Предоставляя членам сообщества поддержку и обратную связь, вы поможете другим разработчикам улучшить свои знания и даже сможете сами научиться новым трюкам!
Обзор PR в вашей собственной компании и по проектам с открытым исходным кодом - ещё один способ помочь другим посредством анализа кода и обратной связи. Чтение чужого кода и его анализ - невероятный опыт обучения. Критическое мышление о коде и предоставление конструктивной обратной связи - это самостоятельный ценный набор навыков. Вы можете даже столкнуться с новыми ошибками, о которых раньше не задумывались, что еще больше расширит ваше понимание.
2. Наставничество один-на-один
CodingCoach - это бесплатная платформа с открытым исходным кодом, которая сводит наставников-добровольцев с подопечными.
3. Отзывы о задачах на кодирование
Если вы предпочитаете более алгоритмические упражнения, то отзывы на таких платформах, как Codewars и Exercism, могут быть идеальными. Поскольку многие люди выполняют упражнения и ждут отзывов, эти платформы всегда ищут разработчиков, которые поддержат других.
Итого
Даже если вы не совсем готовы взять на себя роль наставника, я настоятельно рекомендую попробовать. Вам не нужно знать всё о предмете, чтобы начать работу. Если вы прошли на один или два шага дальше, чем кто-то другой, вы в состоянии помочь ему. К тому же помогать другим очень приятно!
Источник: https://stackoverflow.blog/2021/07/07/the-unexpected-benefits-of-mentoring-others/
Автор оригинала - Matt Studdert
👍1
День девятьсот двадцатый. #Оффтоп #Курсы
30-дневный Челлендж от Microsoft
30-дневный Челлендж от Microsoft может помочь вам развить свои навыки подготовиться к сертификации Майкрософт. Курс содержит теоретические материалы и практические задания, выполнив которые вы получите скидку в 50% на соответствующий экзамен Майкрософт. Челленджи предлагаются по следующим направлениям:
1. Azure AI Fundamentals
Фундамент для использования концепций машинного обучения и искусственного интеллекта, таких как компьютерное зрение, обработка естественных языков и виртуальный собеседник на основе ИИ.
Экзамен AI-900: Microsoft Azure AI Fundamentals
2. Azure Solutions Architect
Узнайте, как с помощью инфраструктуры Azure усовершенствовать свои приложения и стать архитектором решений Azure.
Экзамены:
- AZ-303: Microsoft Azure Architect Technologies
- AZ-304: Microsoft Azure Architect Design
3. Microsoft 365 Developer
Разрабатывайте, создавайте, тестируйте и обслуживайте приложения и решения с помощью Microsoft 365, Microsoft Teams, Microsoft Identity и Microsoft Graph.
Экзамен MS-600: Building Applications and Solutions with Microsoft 365 Core Services
4. Azure IoT Developer
Научитесь внедрять и обслуживать облачные и периферийные компоненты решений из сферы Интернета вещей.
Экзамен AZ-220: Microsoft Azure IoT Developer
5. Azure Developer
Участвуйте во всех этапах разработки комплексных облачных решений. Проектируйте, создавайте, тестируйте и обслуживайте облачные приложения с помощью служб вычислений, хранения, управления и обеспечения безопасности на платформе Azure.
Экзамен AZ-204: Developing Solutions for Microsoft Azure
6. Java on Azure Developer
Начните разрабатывать современные приложения на Java в облаке с использованием служб управляемых вычислений, базами данных и DevOps.
Экзамен AZ-204: Developing Solutions for Microsoft Azure
7. Power Platform App Maker
Создавайте решения, включающие в себя приложения, функции ИИ и отчетность, практически без написания программного кода и необходимости что-то настраивать.
Экзамен PL-100: Microsoft Power Platform App Maker
8. DevOps Engineer
Проектируйте и внедряйте процессы и методы DevOps. Управляйте исходным кодом с помощью GitHub для оптимизации взаимодействия и автоматизации процессов разработки и развертывания.
Экзамен AZ-400: Designing and Implementing Microsoft DevOps Solutions
9. Azure Data Scientist
Узнайте, как создавать модели машинного обучения, прогнозные модели без написания программного кода и решения в сфере машинного обучения, а также выполнять обработку и анализ данных в облаке.
Экзамен DP-100: Designing and Implementing a Data Science Solution on Azure
10. Azure Synapse Analytics
Научитесь интегрировать, преобразовывать и консолидировать данные из различных структурированных и неструктурированных систем, чтобы получать структуры данных, на основе которых можно строить решения для аналитики.
Источник: https://developer.microsoft.com/ru-ru/offers/30-days-to-learn-it
30-дневный Челлендж от Microsoft
30-дневный Челлендж от Microsoft может помочь вам развить свои навыки подготовиться к сертификации Майкрософт. Курс содержит теоретические материалы и практические задания, выполнив которые вы получите скидку в 50% на соответствующий экзамен Майкрософт. Челленджи предлагаются по следующим направлениям:
1. Azure AI Fundamentals
Фундамент для использования концепций машинного обучения и искусственного интеллекта, таких как компьютерное зрение, обработка естественных языков и виртуальный собеседник на основе ИИ.
Экзамен AI-900: Microsoft Azure AI Fundamentals
2. Azure Solutions Architect
Узнайте, как с помощью инфраструктуры Azure усовершенствовать свои приложения и стать архитектором решений Azure.
Экзамены:
- AZ-303: Microsoft Azure Architect Technologies
- AZ-304: Microsoft Azure Architect Design
3. Microsoft 365 Developer
Разрабатывайте, создавайте, тестируйте и обслуживайте приложения и решения с помощью Microsoft 365, Microsoft Teams, Microsoft Identity и Microsoft Graph.
Экзамен MS-600: Building Applications and Solutions with Microsoft 365 Core Services
4. Azure IoT Developer
Научитесь внедрять и обслуживать облачные и периферийные компоненты решений из сферы Интернета вещей.
Экзамен AZ-220: Microsoft Azure IoT Developer
5. Azure Developer
Участвуйте во всех этапах разработки комплексных облачных решений. Проектируйте, создавайте, тестируйте и обслуживайте облачные приложения с помощью служб вычислений, хранения, управления и обеспечения безопасности на платформе Azure.
Экзамен AZ-204: Developing Solutions for Microsoft Azure
6. Java on Azure Developer
Начните разрабатывать современные приложения на Java в облаке с использованием служб управляемых вычислений, базами данных и DevOps.
Экзамен AZ-204: Developing Solutions for Microsoft Azure
7. Power Platform App Maker
Создавайте решения, включающие в себя приложения, функции ИИ и отчетность, практически без написания программного кода и необходимости что-то настраивать.
Экзамен PL-100: Microsoft Power Platform App Maker
8. DevOps Engineer
Проектируйте и внедряйте процессы и методы DevOps. Управляйте исходным кодом с помощью GitHub для оптимизации взаимодействия и автоматизации процессов разработки и развертывания.
Экзамен AZ-400: Designing and Implementing Microsoft DevOps Solutions
9. Azure Data Scientist
Узнайте, как создавать модели машинного обучения, прогнозные модели без написания программного кода и решения в сфере машинного обучения, а также выполнять обработку и анализ данных в облаке.
Экзамен DP-100: Designing and Implementing a Data Science Solution on Azure
10. Azure Synapse Analytics
Научитесь интегрировать, преобразовывать и консолидировать данные из различных структурированных и неструктурированных систем, чтобы получать структуры данных, на основе которых можно строить решения для аналитики.
Источник: https://developer.microsoft.com/ru-ru/offers/30-days-to-learn-it
День девятьсот двадцать второй. #DesignPatterns #Microservices
Паттерны в Микросервисах
9. Внешняя конфигурация
Каждое бизнес-приложение имеет множество параметров конфигурации для различной инфраструктуры (например, база данных, сеть, адреса подключенных служб, учетные данные, путь к сертификату). Кроме того, в корпоративной среде приложение обычно развёртывается в различных средах выполнения (локальной, тестовой, производственной). Один из способов добиться этого - использовать конфигурацию внутри каждого приложения в каждом случае, что является фатальной плохой практикой. Это может привести к серьёзным угрозам безопасности, поскольку производственные учётные данные могут быть легко скомпрометированы. Кроме того, при любом изменении параметра конфигурации необходимо пересобрать приложение. Это ещё более важно в микросервисной архитектуре, поскольку у нас потенциально есть сотни сервисов.
Лучшим подходом является экстернализация всех конфигураций. В результате процесс сборки отделён от среды выполнения. Кроме того, это сводит к минимуму риск безопасности, поскольку файл конфигурации используется только во время выполнения или через переменные среды.
Плюсы
- Рабочие конфигурации не являются частью кодовой базы и, таким образом, сводят к минимуму уязвимость системы безопасности.
- Параметры конфигурации можно изменить без новой сборки.
Минусы
- Нам нужно выбрать фреймворк, поддерживающий внешнюю конфигурацию.
Когда использовать
- Любое серьезное производственное приложение должно использовать внешнюю конфигурацию.
Когда не использовать
- В тестовых приложениях.
Включение технологий
Практически все современные фреймворки корпоративного уровня поддерживают внешнюю конфигурацию.
Подробнее
- Microservices Pattern: Externalized configuration
- Build Once, Run Anywhere: Externalize Your Configuration
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Паттерны в Микросервисах
9. Внешняя конфигурация
Каждое бизнес-приложение имеет множество параметров конфигурации для различной инфраструктуры (например, база данных, сеть, адреса подключенных служб, учетные данные, путь к сертификату). Кроме того, в корпоративной среде приложение обычно развёртывается в различных средах выполнения (локальной, тестовой, производственной). Один из способов добиться этого - использовать конфигурацию внутри каждого приложения в каждом случае, что является фатальной плохой практикой. Это может привести к серьёзным угрозам безопасности, поскольку производственные учётные данные могут быть легко скомпрометированы. Кроме того, при любом изменении параметра конфигурации необходимо пересобрать приложение. Это ещё более важно в микросервисной архитектуре, поскольку у нас потенциально есть сотни сервисов.
Лучшим подходом является экстернализация всех конфигураций. В результате процесс сборки отделён от среды выполнения. Кроме того, это сводит к минимуму риск безопасности, поскольку файл конфигурации используется только во время выполнения или через переменные среды.
Плюсы
- Рабочие конфигурации не являются частью кодовой базы и, таким образом, сводят к минимуму уязвимость системы безопасности.
- Параметры конфигурации можно изменить без новой сборки.
Минусы
- Нам нужно выбрать фреймворк, поддерживающий внешнюю конфигурацию.
Когда использовать
- Любое серьезное производственное приложение должно использовать внешнюю конфигурацию.
Когда не использовать
- В тестовых приложениях.
Включение технологий
Практически все современные фреймворки корпоративного уровня поддерживают внешнюю конфигурацию.
Подробнее
- Microservices Pattern: Externalized configuration
- Build Once, Run Anywhere: Externalize Your Configuration
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
👍1
День девятьсот двадцать третий. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
94. Пишите тесты для людей
Вы пишете тесты для части или для всего вашего кода? Поздравляю! Вы пишете тесты перед написанием кода? Ещё лучше! Это делает вас одним из первых, кто встал на передовые позиции в области разработки программного обеспечения. Но хорошие ли вы пишете тесты? Как вы можете их оценить? Один из способов - спросить: «Для кого я пишу тесты?» Если ответ - «Для себя, чтобы избавить себя от усилий по исправлению ошибок» или «Для компилятора, чтобы убедиться, что они проходят», то велика вероятность, что вы пишете не самые лучшие тесты. Так для кого же вы должны писать тесты? Для человека, пытающегося понять ваш код.
Хорошие тесты служат документацией для кода, который они тестируют. Они описывают, как работает код. Для каждого сценария использования тест(ы):
1. Описывают контекст, отправную точку или предварительные условия, которые должны быть выполнены.
2. Иллюстрируют, как запускается программное обеспечение.
3. Описывают ожидаемые результаты или постусловия, которые необходимо проверить.
В разных сценариях использования эти три пункта будут немного различаться. Человек, пытающийся понять ваш код, должен иметь возможность взглянуть на несколько тестов и, сравнив эти три части в рассматриваемых тестах, понять, что заставляет программное обеспечение вести себя по-разному. Каждый тест должен чётко иллюстрировать причинно-следственную связь между этими тремя частями.
Это означает, что то, что не видно в тесте, так же важно, как и то, что видно. Слишком много кода в тесте отвлекает читателя несущественными мелочами. По возможности скрывайте такие мелочи за осмысленными вызовами методов - рефакторинг Extract Method - ваш лучший друг. И убедитесь, что вы дали каждому тесту осмысленное имя, которое описывает конкретный сценарий использования, чтобы читателю тестов не приходилось копаться в коде, чтобы понять, каковы могут быть различные варианты. Имена тестового класса и его методов должны включать по крайней мере название тестируемой начальной точки и сценарий использования. Это позволяет проверить покрытие тестами, просто быстро прочитав имена методов. Также может быть полезно включить ожидаемые результаты в названия тестовых методов, если это не сделает их слишком длинными.
Также неплохо протестировать свои тесты. Вы можете убедиться, что они обнаруживают ошибки, которые, по вашему мнению, они должны обнаруживать, вставив эти ошибки в рабочий код (вашу личную копию, которую вы, конечно же, выбросите). Убедитесь, что они сообщают об ошибках полезным и содержательным образом. Вы также должны убедиться, что ваши тесты будут понятны человеку, пытающемуся понять ваш код. Единственный способ сделать это - попросить кого-нибудь, кто не знаком с вашим кодом, прочитать ваши тесты и рассказать вам, что он узнал. Внимательно слушайте, что он говорит. Если он чего-то не понял, то, вероятно не потому, что он не очень сообразителен. Скорее всего, ваши тесты были не очень ясны. Вы также можете поменяться ролями, читая его тесты.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Gerard Meszaros
97 Вещей, Которые Должен Знать Каждый Программист
94. Пишите тесты для людей
Вы пишете тесты для части или для всего вашего кода? Поздравляю! Вы пишете тесты перед написанием кода? Ещё лучше! Это делает вас одним из первых, кто встал на передовые позиции в области разработки программного обеспечения. Но хорошие ли вы пишете тесты? Как вы можете их оценить? Один из способов - спросить: «Для кого я пишу тесты?» Если ответ - «Для себя, чтобы избавить себя от усилий по исправлению ошибок» или «Для компилятора, чтобы убедиться, что они проходят», то велика вероятность, что вы пишете не самые лучшие тесты. Так для кого же вы должны писать тесты? Для человека, пытающегося понять ваш код.
Хорошие тесты служат документацией для кода, который они тестируют. Они описывают, как работает код. Для каждого сценария использования тест(ы):
1. Описывают контекст, отправную точку или предварительные условия, которые должны быть выполнены.
2. Иллюстрируют, как запускается программное обеспечение.
3. Описывают ожидаемые результаты или постусловия, которые необходимо проверить.
В разных сценариях использования эти три пункта будут немного различаться. Человек, пытающийся понять ваш код, должен иметь возможность взглянуть на несколько тестов и, сравнив эти три части в рассматриваемых тестах, понять, что заставляет программное обеспечение вести себя по-разному. Каждый тест должен чётко иллюстрировать причинно-следственную связь между этими тремя частями.
Это означает, что то, что не видно в тесте, так же важно, как и то, что видно. Слишком много кода в тесте отвлекает читателя несущественными мелочами. По возможности скрывайте такие мелочи за осмысленными вызовами методов - рефакторинг Extract Method - ваш лучший друг. И убедитесь, что вы дали каждому тесту осмысленное имя, которое описывает конкретный сценарий использования, чтобы читателю тестов не приходилось копаться в коде, чтобы понять, каковы могут быть различные варианты. Имена тестового класса и его методов должны включать по крайней мере название тестируемой начальной точки и сценарий использования. Это позволяет проверить покрытие тестами, просто быстро прочитав имена методов. Также может быть полезно включить ожидаемые результаты в названия тестовых методов, если это не сделает их слишком длинными.
Также неплохо протестировать свои тесты. Вы можете убедиться, что они обнаруживают ошибки, которые, по вашему мнению, они должны обнаруживать, вставив эти ошибки в рабочий код (вашу личную копию, которую вы, конечно же, выбросите). Убедитесь, что они сообщают об ошибках полезным и содержательным образом. Вы также должны убедиться, что ваши тесты будут понятны человеку, пытающемуся понять ваш код. Единственный способ сделать это - попросить кого-нибудь, кто не знаком с вашим кодом, прочитать ваши тесты и рассказать вам, что он узнал. Внимательно слушайте, что он говорит. Если он чего-то не понял, то, вероятно не потому, что он не очень сообразителен. Скорее всего, ваши тесты были не очень ясны. Вы также можете поменяться ролями, читая его тесты.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Gerard Meszaros
👍1
День девятьсот двадцать четвёртый. #ЧтоНовенького
.NET 6: Улучшения Потоковой Обработки. Начало
Продолжаем знакомиться с новинками .NET 6.
Несмотря на то, что существует множество библиотек, позволяющих абстрагироваться от сложностей асинхронного и параллельного программирования, разработчикам всё же необходимо время от времени использовать низкоуровневую логику обработки потоков.
1. Асинхронный Parallel.ForEach
Когда был создан класс Parallel, в C# не было языковой поддержки асинхронного программирования. Хотя в .NET 1.1 был шаблон
Это стало проблемой, поскольку акцент сместился на асинхронный код с использованием async/await. В настоящее время нет встроенной поддержки для запуска операции
Однако программисты всё время нуждаются в этом. Они используют очень плохие обходные пути, такие как одновременный запуск всех элементов параллельно с последующим вызовом
Чтобы решить эту проблему, был создан набор методов
Хотя в целом эта функция была хорошо принята, одним из спорных моментов было то, следует ли требовать от разработчиков предоставления значения степени параллелизма. Оно означало бы примерное количество потоков, которые будут назначены для выполнения параллельной операции.
Было решено, что, поскольку большинство разработчиков не знают идеальной степени параллелизма для своей рабочей нагрузки, то и ожидать от них передачи этого значения было бы контрпродуктивно. По умолчанию выбрано
Окончание следует…
Источник: https://www.infoq.com/news/2021/08/net6-Threading/
.NET 6: Улучшения Потоковой Обработки. Начало
Продолжаем знакомиться с новинками .NET 6.
Несмотря на то, что существует множество библиотек, позволяющих абстрагироваться от сложностей асинхронного и параллельного программирования, разработчикам всё же необходимо время от времени использовать низкоуровневую логику обработки потоков.
1. Асинхронный Parallel.ForEach
Когда был создан класс Parallel, в C# не было языковой поддержки асинхронного программирования. Хотя в .NET 1.1 был шаблон
IAsyncResult, он не получил широкого распространения, и подавляющее большинство кода было разработано для синхронного выполнения.Это стало проблемой, поскольку акцент сместился на асинхронный код с использованием async/await. В настоящее время нет встроенной поддержки для запуска операции
Parallel.ForEach и асинхронного ожидания результата. Однако программисты всё время нуждаются в этом. Они используют очень плохие обходные пути, такие как одновременный запуск всех элементов параллельно с последующим вызовом
WhenAll. То есть запускают 10000 HTTP-вызовов и задаются вопросом, почему это так плохо работает. Либо приходится делить задачи на пакеты. Это также не столь эффективно, т.к. задачи в пакете выполняются синхронно и степень параллелизма уменьшается. Или же приходится писать циклы с коллекциями задач и странными схемами ожидания.Чтобы решить эту проблему, был создан набор методов
Parallel.ForEachAsync. Каждый метод принимает IEnumerable или IAsyncEnumerable. Опционально могут быть переданы экземпляр ParallelOptions или токен отмены:public static Task ForEachAsync<TSource>(
IEnumerable<TSource> source,
ParallelOptions parallelOptions,
Func<TSource, CancellationToken, ValueTask> body);
public static Task ForEachAsync<TSource>(
IAsyncEnumerable<TSource> source,
CancellationToken cancellationToken,
Func<TSource, CancellationToken, ValueTask> body);
Parallel.ForEachAsync - один из редких случаев, когда вместо Task используется ValueTask. Основная идея здесь в том, что поскольку значения будут обрабатываться в цикле, дополнительные накладные расходы на создание полного объекта Task неоправданы.Хотя в целом эта функция была хорошо принята, одним из спорных моментов было то, следует ли требовать от разработчиков предоставления значения степени параллелизма. Оно означало бы примерное количество потоков, которые будут назначены для выполнения параллельной операции.
Было решено, что, поскольку большинство разработчиков не знают идеальной степени параллелизма для своей рабочей нагрузки, то и ожидать от них передачи этого значения было бы контрпродуктивно. По умолчанию выбрано
Environment.ProcessorCount.Окончание следует…
Источник: https://www.infoq.com/news/2021/08/net6-Threading/
👍1
День девятьсот двадцать пятый. #ЧтоНовенького
.NET 6: Улучшения Потоковой Обработки. Окончание
Начало
2. Thread.ManagedThreadId устарел
Свойство
Чтобы направить разработчиков к лучшему варианту, для
Хотя это фактически означает, что
3. Thread.UnsafeStart
Новая функция для запуска потоков называется «небезопасной», потому что она не захватывает контекст выполнения.
Эта функция уже используется:
- в
- в
- в
- в
При запуске в браузере
4. Класс PeriodicTimer
Класс
- Этот API имеет смысл только для таймеров, которые срабатывают многократно. Таймеры, которые срабатывают один раз, могут быть основаны на задачах (у нас уже есть
- Таймер будет приостановлен во время выполнения кода пользователя и вернёт следующий тик после его завершения.
- Таймер можно остановить с помощью
- Контекст выполнения не захватывается.
Таймер также можно остановить, вызвав
В .NET уже есть пять других таймеров, но ни один из них не имеет этого конкретного набора функций. В документацию планируется добавить новое руководство по выбору правильного таймера.
Интересный факт: класс
-
.NET 6: Улучшения Потоковой Обработки. Окончание
Начало
2. Thread.ManagedThreadId устарел
Свойство
Environment.CurrentManagedThreadId было введено в .NET 4.5 как более эффективная альтернатива свойству Thread.ManagedThreadId. Однако об этом никогда не сообщалось в документации, и разработчики продолжают использовать Thread.ManagedThreadId.Чтобы направить разработчиков к лучшему варианту, для
Thread.ManagedThreadId было добавлено предупреждение для анализатора кода.Хотя это фактически означает, что
Thread.ManagedThreadId устарел, он не помечается как устаревший. Разработчики могут продолжать использовать его в обозримом будущем, даже при том, что Environment.CurrentManagedThreadId теперь является предпочтительным.3. Thread.UnsafeStart
Новая функция для запуска потоков называется «небезопасной», потому что она не захватывает контекст выполнения.
UnsafeStart был добавлен, потому что нужно было лениво создавать потоки пула потоков и поток таймера в контексте выполнения по умолчанию. UnsafeStart избегает захвата текущего контекста выполнения и его восстановления при запуске потока. Есть и другие места, где создаются потоки, которые могут использовать аналогичную логику.Эта функция уже используется:
- в
FileSystemWatcher для OS X,- в
SocketAsyncEngine для Unix,- в
CounterGroup в Tracing API,- в
ThreadPoolTaskScheduler, когда задача помечена как LongRunning.При запуске в браузере
UnsafeStart выбросит PlatformNotSupportedException.4. Класс PeriodicTimer
Класс
PeriodicTimer предназначен для использования в асинхронном контексте. Как вы можете видеть ниже, необходимо использовать await между каждым тиком таймера:var second = TimeSpan.FromSeconds(1);Основные свойства класса
using var timer = new PeriodicTimer(second);
while (await timer.WaitForNextTickAsync())
Console.WriteLine($"Tick {DateTime.Now}");
PeriodicTimer:- Этот API имеет смысл только для таймеров, которые срабатывают многократно. Таймеры, которые срабатывают один раз, могут быть основаны на задачах (у нас уже есть
Task.Delay для этого).- Таймер будет приостановлен во время выполнения кода пользователя и вернёт следующий тик после его завершения.
- Таймер можно остановить с помощью
CancellationToken.- Контекст выполнения не захватывается.
Таймер также можно остановить, вызвав
Stop или Dispose, даже если в настоящее время выполняется вызов WaitForNextTickAsync.В .NET уже есть пять других таймеров, но ни один из них не имеет этого конкретного набора функций. В документацию планируется добавить новое руководство по выбору правильного таймера.
Интересный факт: класс
PeriodicTimer будет первым таймером, который разделит пространство имен с другим таймером. Ранее каждый таймер помещался в отдельное пространство имен:-
System.Timers.Timer
- System.Threading.Timer
- System.Windows.Forms.Timer
- System.Web.UI.Timer
- System.Windows.Threading.DispatcherTimer
Источник: https://www.infoq.com/news/2021/08/net6-Threading/👍2
День девятьсот двадцать седьмой. #ЧтоНовенького
System.Threading.RateLimiting для .NET
Хотя ограничение пропускной способности является хорошо известной проблемой для веб-серверов, существует множество других ситуаций, когда требуются аналогичные возможности. Например, клиентское приложение может выиграть, если будет иметь собственное встроенное ограничение, чтобы оно не заставляло срабатывать ограничения веб-сервера. И для других ресурсов, таких как файловые серверы и серверы баз данных, могут потребоваться ограничения пропускной способности, чтобы клиенты не могли монопольно использовать их.
Хотя теоретически разработчики могут создавать свои собственный функционал ограничений, используя семафоры, такой код может быть трудным и подвержен ошибкам. .NET предложит новый пакет под названием System.Threading.RateLimiting. Этот пакет будет определять общую структуру ограничений пропускной способности и предоставлять несколько вариантов ограничений из коробки.
Абстрактный базовый класс, который должны реализовать все ограничители, просто называется
В настоящее время предлагаются четыре встроенных ограничителя. Самым простым является
Если ограничитель не может удовлетворить запрос на слот, его поведение меняется. Для синхронного случая возвращается
Один из вариантов использования, который эта библиотека явно не поддерживает, - это агрегированные ограничители. Объясняется это тем, что для поддержки сценариев, в которых требуется агрегированный ограничитель, требуется отдельная абстракция. К примеру, чтобы реализовать ограничение скорости по IP, ограничителю придётся реализовать отдельное ограничение для каждого сегмента, то есть принимать идентификатор сегмента (IP адрес). Здесь же реализованы более простые ограничители, где идентификатор не требуется. Пока каких-либо вариантов использования агрегированных ограничителей в dotnet/runtime не нашли, поэтому их решили не добавлять в текущую реализацию.
Если вам нужен агрегированный ограничитель, можете рассмотреть, например, пакеты, разработанные специально для ASP.NET Core, такие как AspNetCoreRateLimit.
Источник: https://www.infoq.com/news/2021/08/DotNet-Rate-Limiting/
System.Threading.RateLimiting для .NET
Хотя ограничение пропускной способности является хорошо известной проблемой для веб-серверов, существует множество других ситуаций, когда требуются аналогичные возможности. Например, клиентское приложение может выиграть, если будет иметь собственное встроенное ограничение, чтобы оно не заставляло срабатывать ограничения веб-сервера. И для других ресурсов, таких как файловые серверы и серверы баз данных, могут потребоваться ограничения пропускной способности, чтобы клиенты не могли монопольно использовать их.
Хотя теоретически разработчики могут создавать свои собственный функционал ограничений, используя семафоры, такой код может быть трудным и подвержен ошибкам. .NET предложит новый пакет под названием System.Threading.RateLimiting. Этот пакет будет определять общую структуру ограничений пропускной способности и предоставлять несколько вариантов ограничений из коробки.
Абстрактный базовый класс, который должны реализовать все ограничители, просто называется
RateLimiter. Он предлагает как синхронный, так и асинхронный способ получения слота (lease), а также подсчёт доступных слотов. Слот - это разрешение ограничителя на выполнение работы. Он представлен классом RateLimitLease, который должен быть возвращён в пул после завершения текущей задачи.В настоящее время предлагаются четыре встроенных ограничителя. Самым простым является
ConcurrencyLimiter, который, как семафор, позволяет одновременно использовать только определённое количество параллельных рабочих процессов.FixedWindowRateLimiter и SlidingWindowRateLimiter ограничивают количество запросов в течение заданного временного окна. Первый использует простой временной интервал для сброса счетчика. Второй предлагает более сложный вариант, когда временное окно разделено на N сегментов со счётчиком запросов для каждого сегмента.TokenBucketRateLimiter основан на алгоритме token bucket. Обычно рабочий процесс приобретает один слот, но бывают сценарии, когда их требуется несколько одновременно. Например, каждый слот может представлять собой разрешение на использование ядра ЦП или блока памяти. В этом случае TokenBucketRateLimiter может быть более полезным. Он может организовать запросы на основе количества слотов, которые требует каждый рабочий процесс, и доступных слотов в каждом ограниченном по времени сегменте.Если ограничитель не может удовлетворить запрос на слот, его поведение меняется. Для синхронного случая возвращается
RateLimitLease с флагом, указывающим на сбой. В асинхронном случае запросы могут быть поставлены в очередь. Если очередь превышает настраиваемый предел, рабочие процессы могут быть отвергнуты. Программисты могут настроить, будет ли отвергнут самый старый или самый новый запрос в этом сценарии.Один из вариантов использования, который эта библиотека явно не поддерживает, - это агрегированные ограничители. Объясняется это тем, что для поддержки сценариев, в которых требуется агрегированный ограничитель, требуется отдельная абстракция. К примеру, чтобы реализовать ограничение скорости по IP, ограничителю придётся реализовать отдельное ограничение для каждого сегмента, то есть принимать идентификатор сегмента (IP адрес). Здесь же реализованы более простые ограничители, где идентификатор не требуется. Пока каких-либо вариантов использования агрегированных ограничителей в dotnet/runtime не нашли, поэтому их решили не добавлять в текущую реализацию.
Если вам нужен агрегированный ограничитель, можете рассмотреть, например, пакеты, разработанные специально для ASP.NET Core, такие как AspNetCoreRateLimit.
Источник: https://www.infoq.com/news/2021/08/DotNet-Rate-Limiting/
День девятьсот двадцать восьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
95. Вы должны заботиться о коде
Не нужно способностей Шерлока Холмса, чтобы понять, что хорошие программисты пишут хороший код, а плохие программисты… нет. Они производят чудовищ, которых всем остальным приходится истреблять. Вы ведь хотите писать хороший код? Вы хотите быть хорошим программистом.
Хороший код не появляется из воздуха или случайно во время парада планет. Чтобы получить хороший код, нужно поработать над ним. Хорошо поработать. И чтобы получить хороший код, нужно стараться получить хороший код.
Хорошее программирование не рождается только из технической компетенции. Я видел высокоинтеллектуальных программистов, которые могут создавать сложные и впечатляющие алгоритмы, которые знают языковые стандарты наизусть, но которые пишут ужаснейший код. Его больно читать, больно использовать и больно изменять. Я видел более скромных программистов, которые придерживаются очень простого кода, но при этом пишут элегантные и выразительные программы, с которыми приятно работать.
Основываясь на моем многолетнем опыте в сфере разработки программного обеспечения, я пришёл к выводу, что настоящая разница между просто программистами и великими программистами заключается в отношении к результатам своей работы. Хорошее программирование заключается в профессиональном подходе и желании писать наилучшее программное обеспечение, которое вы можете, в реальных ограничениях и под давлением.
Код в ад вымощен благими намерениями. Чтобы быть отличным программистом, вы должны подняться над благими намерениями и действительно заботиться о коде: поощрять позитивные взгляды и развивать здоровое отношение. Отличный код тщательно отшлифован с тщательностью высококлассного ремесленника, а не бездумно набросан неряшливыми программистами или таинственным образом возведён самопровозглашенными гуру программирования.
Вы хотите писать хороший код. Вы хотите быть хорошим программистом. То есть вам небезразличен код. Поэтому вам придётся:
1. При написании любого кода отказываться от быстрых костылей, которые только кажутся работающими. Стремитесь создать элегантный код, который очевидно является правильным (и имеет хорошие тесты, подтверждающие его правильность).
2. Писать код, который можно обнаружить (который другие программисты могут легко найти и понять), который обслуживаем (вы или другие программисты сможете легко его изменить в будущем), и который является правильным (вы предпринимаете все возможные шаги чтобы определить, что вы решили проблему, а не просто сделали вид, что программа работает).
3. Хорошо работать с другими программистами. Никакой программист не существует в вакууме. Немногие программисты работают в одиночку. Большинство из них работают в команде программистов в корпоративной среде либо над проектом с открытым исходным кодом. Учитывайте мнение других программистов и создавайте код, который другие могут прочитать. Ваша цель в том, чтобы все как команда писали наилучшее возможное программное обеспечение, а не демонстрировали друг другу личные умения.
4. Каждый раз, когда вы касаетесь фрагмента кода, стремитесь оставить его лучше, чем вы его нашли (лучше структурированным, лучше протестированным, более понятным…).
5. Заботиться о коде и программировании, поэтому постоянно изучать новые языки, идиомы и методы. Но применять их только тогда, когда это необходимо.
К счастью, если вы читаете эти советы, то вам небезразличен код. Это ваша страсть. Получайте удовольствие от программирования. Наслаждайтесь сокращением кода для решения сложных задач. Создавайте программное обеспечение, которым вы будете гордиться.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Pete Goodliffe
97 Вещей, Которые Должен Знать Каждый Программист
95. Вы должны заботиться о коде
Не нужно способностей Шерлока Холмса, чтобы понять, что хорошие программисты пишут хороший код, а плохие программисты… нет. Они производят чудовищ, которых всем остальным приходится истреблять. Вы ведь хотите писать хороший код? Вы хотите быть хорошим программистом.
Хороший код не появляется из воздуха или случайно во время парада планет. Чтобы получить хороший код, нужно поработать над ним. Хорошо поработать. И чтобы получить хороший код, нужно стараться получить хороший код.
Хорошее программирование не рождается только из технической компетенции. Я видел высокоинтеллектуальных программистов, которые могут создавать сложные и впечатляющие алгоритмы, которые знают языковые стандарты наизусть, но которые пишут ужаснейший код. Его больно читать, больно использовать и больно изменять. Я видел более скромных программистов, которые придерживаются очень простого кода, но при этом пишут элегантные и выразительные программы, с которыми приятно работать.
Основываясь на моем многолетнем опыте в сфере разработки программного обеспечения, я пришёл к выводу, что настоящая разница между просто программистами и великими программистами заключается в отношении к результатам своей работы. Хорошее программирование заключается в профессиональном подходе и желании писать наилучшее программное обеспечение, которое вы можете, в реальных ограничениях и под давлением.
Код в ад вымощен благими намерениями. Чтобы быть отличным программистом, вы должны подняться над благими намерениями и действительно заботиться о коде: поощрять позитивные взгляды и развивать здоровое отношение. Отличный код тщательно отшлифован с тщательностью высококлассного ремесленника, а не бездумно набросан неряшливыми программистами или таинственным образом возведён самопровозглашенными гуру программирования.
Вы хотите писать хороший код. Вы хотите быть хорошим программистом. То есть вам небезразличен код. Поэтому вам придётся:
1. При написании любого кода отказываться от быстрых костылей, которые только кажутся работающими. Стремитесь создать элегантный код, который очевидно является правильным (и имеет хорошие тесты, подтверждающие его правильность).
2. Писать код, который можно обнаружить (который другие программисты могут легко найти и понять), который обслуживаем (вы или другие программисты сможете легко его изменить в будущем), и который является правильным (вы предпринимаете все возможные шаги чтобы определить, что вы решили проблему, а не просто сделали вид, что программа работает).
3. Хорошо работать с другими программистами. Никакой программист не существует в вакууме. Немногие программисты работают в одиночку. Большинство из них работают в команде программистов в корпоративной среде либо над проектом с открытым исходным кодом. Учитывайте мнение других программистов и создавайте код, который другие могут прочитать. Ваша цель в том, чтобы все как команда писали наилучшее возможное программное обеспечение, а не демонстрировали друг другу личные умения.
4. Каждый раз, когда вы касаетесь фрагмента кода, стремитесь оставить его лучше, чем вы его нашли (лучше структурированным, лучше протестированным, более понятным…).
5. Заботиться о коде и программировании, поэтому постоянно изучать новые языки, идиомы и методы. Но применять их только тогда, когда это необходимо.
К счастью, если вы читаете эти советы, то вам небезразличен код. Это ваша страсть. Получайте удовольствие от программирования. Наслаждайтесь сокращением кода для решения сложных задач. Создавайте программное обеспечение, которым вы будете гордиться.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Pete Goodliffe
День девятьсот двадцать девятый. #Оффтоп
Удивительная История Алгоритма Нахождения Обратного Квадратного Корня из Quake III
Я, кажется, как-то уже писал, что не считаю себя труЪ программистом. Я скорее разработчик, использующий строительные блоки, созданные другими, чтобы собрать из них что-то работающее, как из деталей конструктора. Настоящими же программистами лично я считаю людей, создающих уникальные алгоритмы или эффективные способы хранения данных и манипуляций над ними.
И сегодня речь пойдёт как раз о таком случае. Дейв Пламер на своём канале рассказывает историю одного такого алгоритма вычисления обратного квадратного корня, который нашли в выпущенном в 2005м году исходном коде игры Quake III Arena.
В двух словах. Графика в игре постоянно имеет дело с векторами. И самой распространённой задачей является нормализация вектора, т.е. преобразование заданного вектора в вектор в том же направлении, но с единичной длиной. Например, для вектора
Алгоритм, представленный в исходном коде Quake III, не имел ничего общего с обычными алгоритмами нахождения квадратного корня, вроде итеративного нахождения корня функции. Он же использовал приведения чисел с плавающей точкой в целые и обратно, а также магическую константу. И при этом он работал в 30 раз быстрее.
Подробнее в 2х частях видео от Дейва Пламера:
- Часть 1
- Часть 2
Сразу предупреждаю, очень много математики.
Удивительная История Алгоритма Нахождения Обратного Квадратного Корня из Quake III
Я, кажется, как-то уже писал, что не считаю себя труЪ программистом. Я скорее разработчик, использующий строительные блоки, созданные другими, чтобы собрать из них что-то работающее, как из деталей конструктора. Настоящими же программистами лично я считаю людей, создающих уникальные алгоритмы или эффективные способы хранения данных и манипуляций над ними.
И сегодня речь пойдёт как раз о таком случае. Дейв Пламер на своём канале рассказывает историю одного такого алгоритма вычисления обратного квадратного корня, который нашли в выпущенном в 2005м году исходном коде игры Quake III Arena.
В двух словах. Графика в игре постоянно имеет дело с векторами. И самой распространённой задачей является нормализация вектора, т.е. преобразование заданного вектора в вектор в том же направлении, но с единичной длиной. Например, для вектора
{x, y, z}, его длина будет определяться как sqrt(x*x + y*y + z*z), а нормальный вектор получится путём деления каждой величины на эту длину. Таким образом, задача состоит в быстром нахождении значения 1.0/sqrt(x).Алгоритм, представленный в исходном коде Quake III, не имел ничего общего с обычными алгоритмами нахождения квадратного корня, вроде итеративного нахождения корня функции. Он же использовал приведения чисел с плавающей точкой в целые и обратно, а также магическую константу. И при этом он работал в 30 раз быстрее.
Подробнее в 2х частях видео от Дейва Пламера:
- Часть 1
- Часть 2
Сразу предупреждаю, очень много математики.
День девятьсот тридцатый. #DesignPatterns #Microservices
Паттерны в Микросервисах
10. Тестирование Контрактов, Ориентированных на Потребителя
В микросервисной архитектуре зачастую разные микросервисы разрабатываются отдельными группами. Эти микросервисы работают вместе для выполнения бизнес-требований (например, запроса клиента) и взаимодействуют друг с другом синхронно или асинхронно. Интеграционное тестирование микросервиса со стороны потребителя - непростая задача. Обычно в таких сценариях используется объект-имитация для более быстрой и дешёвой реализации тестов. Но он зачастую не полностью представляет собой настоящий микросервис провайдера. Кроме того, если микросервис провайдера изменяет свой API или сообщение, объект-имитация не может это отразить. Другой вариант - провести сквозное тестирование. Хотя сквозное тестирование является обязательным перед выпуском продукта, оно хрупкое, медленное, дорогое и не может заменить интеграционное тестирование.
В этом случае нам может помочь тестирование контрактов, ориентированных на потребителя (Consumer-Driven Contract Testing). При этом группа, разрабатывающая микросервис потребителя, пишет набор тестов, содержащий его запрос и ожидаемый ответ (для синхронного взаимодействия) или ожидаемые сообщения (для асинхронного взаимодействия) под конкретный микросервис провайдера. Эти наборы тестов называются явными контрактами. Для микросервиса провайдера все наборы тестов из контракта его потребителей добавляются в его набор автоматизированных тестов. Когда выполняется автоматизированное тестирование конкретного микросервиса провайдера, запускаются его собственные тесты и тесты по контракту. Таким образом, проверка контракта может помочь в автоматическом поддержании целостности микросервисной коммуникации.
Плюсы
- Если провайдер неожиданно изменяет API или сообщение, это автоматически обнаруживается за короткое время.
- Меньше неожиданностей и больше надёжности, особенно в корпоративном приложении, содержащем множество микросервисов.
- Повышается автономность команд.
Минусы
- Требуется дополнительная работа по разработке и интеграции контрактных тестов в микросервис провайдера, поскольку разные команды могут использовать разные инструменты тестирования.
- Если проверка контракта не соответствует реальному сценарию потребителя сервиса, это может привести к сбою в производственной среде.
Когда использовать
- В крупномасштабных корпоративных бизнес-приложениях, где, как правило, разные команды разрабатывают разные сервисы.
Когда не использовать
- В относительно более простых и небольших приложениях, в которых одна команда разрабатывает все микросервисы.
- Если микросервисы провайдера относительно стабильны и не находятся в активной разработке.
Поддержка
Pact, Postman, Spring Cloud Contract
Подробнее
- Microservices Pattern: Service Integration Contract Test
- Consumer-Driven Contracts: A Service Evolution Pattern
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Паттерны в Микросервисах
10. Тестирование Контрактов, Ориентированных на Потребителя
В микросервисной архитектуре зачастую разные микросервисы разрабатываются отдельными группами. Эти микросервисы работают вместе для выполнения бизнес-требований (например, запроса клиента) и взаимодействуют друг с другом синхронно или асинхронно. Интеграционное тестирование микросервиса со стороны потребителя - непростая задача. Обычно в таких сценариях используется объект-имитация для более быстрой и дешёвой реализации тестов. Но он зачастую не полностью представляет собой настоящий микросервис провайдера. Кроме того, если микросервис провайдера изменяет свой API или сообщение, объект-имитация не может это отразить. Другой вариант - провести сквозное тестирование. Хотя сквозное тестирование является обязательным перед выпуском продукта, оно хрупкое, медленное, дорогое и не может заменить интеграционное тестирование.
В этом случае нам может помочь тестирование контрактов, ориентированных на потребителя (Consumer-Driven Contract Testing). При этом группа, разрабатывающая микросервис потребителя, пишет набор тестов, содержащий его запрос и ожидаемый ответ (для синхронного взаимодействия) или ожидаемые сообщения (для асинхронного взаимодействия) под конкретный микросервис провайдера. Эти наборы тестов называются явными контрактами. Для микросервиса провайдера все наборы тестов из контракта его потребителей добавляются в его набор автоматизированных тестов. Когда выполняется автоматизированное тестирование конкретного микросервиса провайдера, запускаются его собственные тесты и тесты по контракту. Таким образом, проверка контракта может помочь в автоматическом поддержании целостности микросервисной коммуникации.
Плюсы
- Если провайдер неожиданно изменяет API или сообщение, это автоматически обнаруживается за короткое время.
- Меньше неожиданностей и больше надёжности, особенно в корпоративном приложении, содержащем множество микросервисов.
- Повышается автономность команд.
Минусы
- Требуется дополнительная работа по разработке и интеграции контрактных тестов в микросервис провайдера, поскольку разные команды могут использовать разные инструменты тестирования.
- Если проверка контракта не соответствует реальному сценарию потребителя сервиса, это может привести к сбою в производственной среде.
Когда использовать
- В крупномасштабных корпоративных бизнес-приложениях, где, как правило, разные команды разрабатывают разные сервисы.
Когда не использовать
- В относительно более простых и небольших приложениях, в которых одна команда разрабатывает все микросервисы.
- Если микросервисы провайдера относительно стабильны и не находятся в активной разработке.
Поддержка
Pact, Postman, Spring Cloud Contract
Подробнее
- Microservices Pattern: Service Integration Contract Test
- Consumer-Driven Contracts: A Service Evolution Pattern
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
👍2
День девятьсот тридцать первый. #ЗаметкиНаПолях
Генерация случайных чисел в .NET
Уже давно мы можем использовать класс
Однако Random в C# использует значение посева, которое затем используется в алгоритме генерации чисел. Передав одно и то же значение посева, вы получите ту же последовательность случайных чисел. Например:
Поэтому в .NET Framework, согласно документации:
В большинстве систем Windows случайные объекты, созданные с интервалом в 15 миллисекунд, скорее всего, будут иметь идентичные начальные значения.
Но это происходит только в том случае, если вы создаёте генератор случайных чисел несколько раз. Если вместо этого вы каждый раз используете один и тот же экземпляр
Использование класса RandomNumberGenerator
Этот класс фактически присутствует во всех версиях .NET, но в .NET Core 3+ в нём появились вспомогательные методы, помогающие вам оперировать не случайными байтами, а сразу числами:
Зачем же тогда вообще использовать Random?
Одной из причин может быть скорость. Вызов метода
Источник: https://dotnetcoretutorials.com/2021/08/10/generating-random-numbers-in-net/
Генерация случайных чисел в .NET
Уже давно мы можем использовать класс
Random для генерации «случайных» чисел:var randomGenerator = new Random();Этот код выдаст случайное число от 1 до 1 миллиона.
randomGenerator.Next(1, 1000000);
Однако Random в C# использует значение посева, которое затем используется в алгоритме генерации чисел. Передав одно и то же значение посева, вы получите ту же последовательность случайных чисел. Например:
var randomGenerator = new Random(123);И вы, вероятно, скажете: «Тогда просто не передавайте ему то же самое число посева». На самом деле в класс Random всегда передаётся посев, нравится вам это или нет. Когда конструктору
var random1 = randomGenerator.Next(1, 1000000);
randomGenerator = new Random(123);
var random2 = randomGenerator.Next(1, 1000000);
Console.WriteLine(random1 == random2); //true
Random не передан посев, в .NET Framework он использует миллисекундную часть времени в качестве посева, а в .NET Core/.NET5+ используется генератор псевдослучайных чисел.Поэтому в .NET Framework, согласно документации:
В большинстве систем Windows случайные объекты, созданные с интервалом в 15 миллисекунд, скорее всего, будут иметь идентичные начальные значения.
Но это происходит только в том случае, если вы создаёте генератор случайных чисел несколько раз. Если вместо этого вы каждый раз используете один и тот же экземпляр
Random, то такой коллизии не возникнет:var randomGenerator = new Random();Класс
var random1 = randomGenerator.Next(1, 1000000);
//другое число из того же экземпляра Random
var random2 = randomGenerator.Next(1, 1000000);
Random в .NET хорош, но не «по-настоящему случаен». Если вы используете один и тот же экземпляр Random в своем коде для генерации нескольких случайных чисел, скорее всего, у вас всё будет хорошо, но это не идеальный вариант. Что же мы можем использовать, когда нужно больше случайности?Использование класса RandomNumberGenerator
Этот класс фактически присутствует во всех версиях .NET, но в .NET Core 3+ в нём появились вспомогательные методы, помогающие вам оперировать не случайными байтами, а сразу числами:
var random = RandomNumberGenerator.GetInt32(1, 1000000);Этот генератор случайных чисел построен на основе API криптографии, чтобы быть максимально случайным. Таким образом, если вам нужно что-то по-настоящему случайное (например, соль для пароля), вам следует использовать
RandomNumberGenerator, а не класс Random.Зачем же тогда вообще использовать Random?
Одной из причин может быть скорость. Вызов метода
Next класса Random гораздо быстрее, чем использование RandomNumberGenerator.GetInt32. Поэтому, если вам не критична «настоящая случайность», но требуется создать много псевдослучайных чисел, лучшим вариантом будет создание объекта Random и генерация серии чисел через последовательный вызов метода Next на этом объекте.Источник: https://dotnetcoretutorials.com/2021/08/10/generating-random-numbers-in-net/