Why Pay for Entertainment? Access Thousands of Free Downloads Now!

.NET Разработчик

Description
Дневник сертифицированного .NET разработчика.

Для связи: @SBenzenko

Поддержать канал:
- https://boosty.to/netdeveloperdiary
- https://patreon.com/user?u=52551826
- https://pay.cloudtips.ru/p/70df3b3b
We recommend to visit

🛒 Магазин сообществ в соц. сетях 24/7
⚡️ В наличии любые тематики и количества, связь в ЛС @timur_chik1


ac99e5f0c33c6df9805b

Last updated 5 months ago

От создателей «Топора».
Сделаем лучший русскоязычный кибер тг-канал вместе.

Новости присылать сюда: @CyberTopor_bot

Для связи: @toporch

Ссылка для друзей и знакомых: https://t.me/+iI538bjZlGJmYWQy

Last updated 1 month, 1 week ago

NN
NN
1,236,156 @naebnet

Медиа про интернет, технологии и безопасность

Сотрудничество: @nnmanager
Ютуб: https://youtube.com/naebnet

Last updated 4 hours ago

1 month, 4 weeks ago

День 1795. #ЗаметкиНаПолях Изоляция Данных в Модульном МонолитеМодульный монолит — это архитектурный подход, который становится очень популярным. Он пытается побороть недостатки монолитной и микросервисной архитектур. Одна из проблем монолитной архитектуры, — тесная связь между компонентами и зависимости между различными частями системы. Модульные монолиты решают эту проблему, чётко определяя границы модулей и шаблоны взаимодействия. Но один аспект, который нельзя упустить из виду, — это изоляция данных между модулями, что гарантирует, независимость и слабую связанность модулей.

Изоляция модулей облегчает внесение новых изменений в систему. Когда компоненты слабо связаны, возникает меньше непреднамеренных побочных эффектов.

Модульный монолит имеет строгие правила целостности данных:
- Каждый модуль может обращаться только к своим таблицам.
- Запрещено совместное использование таблиц или объектов между модулями.
- Объединения разрешены только между таблицами одного модуля.

Модули должны быть автономными. Каждый модуль обрабатывает только свои данные. Другие модули могут получить доступ к этим данным, используя общедоступный API модуля.

Уровни изоляции
1. Отдельные таблицы

Изначально у нас нет изоляции на уровне базы данных. Таблицы для всех модулей находятся внутри одной БД. Определить, какие таблицы к какому модулю принадлежат, непросто. Этот подход отлично работает до определённого размера приложения. Но чем больше у вас таблиц, тем сложнее становится изолировать их между модулями. Это можно улучшить, добавив логическую изоляцию между таблицами.

2. Раздельные схемы
Группировка связанных таблиц в БД — это способ обеспечить логическую изоляцию. Вы можете реализовать это, используя схемы. Каждый модуль имеет уникальную схему, содержащую таблицы модуля. Теперь легко отличить, какой модуль какие таблицы содержит. В приложении это легко реализовать, используя несколько контекстов базы данных в EF Core. Вы также можете ввести правила, предотвращающие запрос данных из других модулей и проверять это, например, с помощью тестов архитектуры. Это первый этап изоляции данных при создании модульного монолита.

3. Раздельные БД
Этот подход имеет больше ограничений, чем изоляция данных с помощью схем, однако это лучший вариант, если вам нужны строгие правила изоляции данных между модулями. Недостатком является большая сложность эксплуатации. Вам необходимо управлять инфраструктурой для нескольких БД. Однако это отличный шаг к извлечению модулей. Сначала вы перемещаете таблицы модуля, который хотите извлечь, в отдельную БД. Это также заставит вас решать любые проблемы связанности между вашими модулями. Если все таблицы модуля извлечены в отдельную БД, значит он готов (при необходимости) существовать независимо в виде микросервиса.

4. Различные хранилища
Не обязательно использовать один и тот же тип БД для всех модулей. Реляционные БД решают широкий спектр проблем. Но иногда БД документов или графов оказывается гораздо лучшим решением. Идея здесь аналогичная: вы выполняете изоляцию данных, используя отдельные БД, но используете другой тип БД для решения конкретных проблем. Например, реляционную базу данных для большинства модулей и БД документов для отдельного модуля, где она имеет преимущество перед реляционной. Это может быть выгодным компромиссом для вашего варианта использования. Но требует тщательного планирования.

Итого
Как минимум, стоит попробовать использовать логическую изоляцию с использованием схем. Её легко реализовать, и она помогает лучше понять границы модулей и держать связанность модулей под контролем.

Источник: https://www.milanjovanovic.tech/blog/modular-monolith-data-isolation

1 month, 4 weeks ago

День 1794. #ЗаметкиНаПолях Препарируем Cookie в ASP.NET Core. Окончание
Начало

2. Cookie сессии
Сервис сессий в ASP.NET Core — это механизм управления пользовательскими данными между HTTP-запросами, который часто используется в таких сценариях, как обслуживание корзины покупок. Этот сервис отправляет браузеру защищённый файл cookie для отслеживания данных. Важно знать, что этот cookie и его назначение не связаны с cookie аутентификации.

Приложение может попросить сервис сессий запомнить временные данные текущего пользователя. Чтобы использовать сервис сессий, зарегистрируйте его в конвейере запросов:

// регистрация сервиса builder.Services.AddSession(options => { //… параметры … }); … //использование сервиса app.UseSession();

Cookie сессии выглядит примерно так:

Set\-Cookie: .AspNetCore.Session=CfDJ8MSO%2F2XEvalHlF%2Fgv69RLqD6mFWeTVC1MG3dYxNWftq625VyGyqF%2BeIq2 xaqgm1cd4McTp0ydSLcRYraIA4%2F%2Bn89FKFhz567AcC%2FeSnwabg4eRrlFAeWLFBq0K8zl2ISdMPcY0pj% 2BtAJQgC5NIte76QR4TlheM1ZhsD98WAdAvKM; path=/; samesite=lax; httponly

Этот cookie также защищён с помощью API защиты данных; однако для него нет возможности предоставить собственный класс защиты, как мы это сделали в предыдущем примере.

Один из вариантов посмотреть на содержимое — загрузить и изменить код промежуточного ПО сессий. Хотя, особой необходимости в этом нет. Cookie сессии хранит простой GUID - ключ, используемый для поиска объекта сессии для текущего запроса. Место хранения данных зависит от того, как вы настроили систему сессий. Система сессий в ASP.NET Core предоставляет различные варианты хранения, включая хранилище в памяти, распределённый кэш и внешних поставщиков хранилищ, что позволяет разработчикам выбирать наиболее подходящий метод для потребностей масштабируемости и производительности приложения.

3. Cookie защиты от подделки
Этот cookie предназначен для защиты от атак с подделкой межсайтовых запросов (CSRF). Он работает в системе на основе токенов, где токен хранится в файле cookie, а также встраивается в HTML-формы. При отправке формы токен из данных формы должен соответствовать токену в файле cookie для обеспечения безопасности.

DPAPI также защищает этот cookie. Реализацией этой защиты занимается класс DefaultAntiforgeryTokenSerializer, подробно изучить который можно здесь.

Вот пример такого cookie:

Set\-Cookie: .AspNetCore.Antiforgery.YCD23e8AirM=CfDJ8MSO\_2XEvalHlF\_gv69RLqDarftldkzWvbxvac LnZ4WtaTDcgSCPmxQdmK8OHbGfMIUvV0VhcFkx4Ys8jPppklGBUGWRTsXcwxhMBl7nqZA0s\_xYN5jJq3J7 LrH8EikY82bOYmSoA\_wEYCxkcrBEEAs; path=/; samesite=strict; httponly

Не будем здесь углубляться в особенности внутренней структуры токена, это можно посмотреть в коде класса сериализатора по ссылке выше.

Источник: https://nestenius.se/2023/11/22/exploring-what-is-inside-the-asp-net-core-cookies/

2 months ago

День 1793. #ЗаметкиНаПолях Препарируем Cookie в ASP.NET Core. Начало
ASP.NET Core создаёт несколько файлов cookie, включая cookie аутентификации, сессии и защиты от подделки (antiforgery). Рассмотрим, что они содержат и как защищены.

Защита cookie
Содержимое этих cookie защищено с помощью комбинации механизмов шифрования и подписи. Эти защитные меры, реализуемые через API защиты данных (DPAPI), обеспечивают конфиденциальность и целостность информации, хранящейся в них.
DPAPI — это платформа для защиты конфиденциальных данных, управления шифрованием и упрощения ротации ключей. Она предлагает унифицированный интерфейс для шифрования, дешифрования и подписи, что повышает безопасность данных приложений.

1. Cookie аутентификации
Поддерживает аутентификацию пользователя по HTTP-запросам. Когда пользователь входит в систему, система аутентификации обычно выдаёт клиенту cookie, вроде следующего:

Set\-Cookie: .AspNetCore.cookie=CfDJ8MSO\_2XEvwalH…; expires=Thu, 11 Jan 2024 07:38:16 GMT; path=/; secure; samesite=lax; httponly

DPAPI шифрует его, делая его содержимое недоступным и защищённым от несанкционированного доступа. К счастью, мы можем отключить эту защиту, подставив свой класс защиты данных:

```
public class MyProtector : IDataProtector
{
public IDataProtector
CreateProtector(string purpose)
{
return new MyProtector();
}

public byte[] Protect(byte[] text)
{
return text;
}

public byte[] Unprotect(byte[] data)
{
return data;
}
}
```

Добавим этот класс защиты в настройки cookie аутентификации:

builder.Services.AddAuthentication("cookie") .AddCookie("cookie", o => { o.DataProtectionProvider = new MyProtector(); });

Теперь выдаваемые системой cookie вообще не будут защищены. При входе в систему будет создан cookie аутентификации со всеми утверждениями (claims), которые были заданы в объекте ClaimsPrincipal:

Set\-Cookie: .AspNetCore.cookie=BQAAAAZjb29ra…01U; expires= Thu, 11 Jan 2024 07:57:04 GMT; path=/; secure; samesite=lax; httponly

Содержимое cookie - просто текст, закодированный в Base64. Если выполнить декодирование (любым инструментом Base64Decode), мы увидим что-нибудь вроде следующего:

......cookie.....cookie...........Jon Smith.......... =http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.email@server.com...........JobTitle.Developer...........persistent...issued.Thu, 28 Dec 2023 07:57:04 GMT..expires.Thu, 11 Jan 2024 07:57:04 GMT

*здесь нечитаемые символы были заменены точками.

То есть, внутри cookie размещён весь тикет аутентификации (состоящий из ClaimsPrincipal и AuthenticationProperties).

*Окончание следует…

Источник:* https://nestenius.se/2023/11/22/exploring-what-is-inside-the-asp-net-core-cookies/

3 months, 3 weeks ago

День 1742. #ЧтоНовенького «Короткая» Маршрутизация в .NET 8
Маршрутизация в ASP.NET Core обрабатывается двумя частями промежуточного ПО:
- EndpointRoutingMiddleware (RoutingMiddleware) — выбирает, какую зарегистрированную конечную точку выполнить для данного запроса.
- EndpointMiddleware — обычно размещается в конце конвейера промежуточного ПО и выполняет выбранную конечную точку.

Это разделение помогает размещать промежуточное ПО между RoutingMiddleware и EndpointMiddleware, которое может изменять своё поведение на основе метаданных, связанных с конечной точкой, и выполняться до выполнения самой конечной точки. Например, так работают AuthorizationMiddleware и CorsMiddleware.
См. схему

Обычно именно так работает маршрутизация независимо от того, используете ли вы минимальные API или контроллеры MVC, и она легко расширяема. Вы можете добавить дополнительные метаданные к конечным точкам, а затем добавить дополнительное промежуточное ПО между RoutingMiddleware и EndpointMiddleware, чтобы обеспечить новое поведение. Но иногда конечной точке не требуется авторизация, поддержка CORS и т.п.

«Короткая» (short-circuit) маршрутизация — новая функция в .NET 8, которая означает, что конечная точка «пропускает» промежуточное ПО между RoutingMiddleware и EndpointMiddleware. Т.е. RoutingMiddleware немедленно выполняет конечную точку и отбрасывает остальную часть конвейера.

Например:

```

app.MapGet("/", () => "Hello World!")
.ShortCircuit();

```

Здесь конечная точка "/" будет выполнена сразу в RoutingMiddleware. Также можно добавить код HTTP статуса:

```

….ShortCircuit(201);

```

Когда это полезно
Основной вариант использования — сократить накладные расходы на запросы, которые, как вы знаете, либо вернут ответ 404, либо никогда не потребуют авторизации или CORS. Некоторыми примерами могут быть известные URL-адреса, которые браузеры запрашивают автоматически, или другие стандартные пути. Например:
- /robots.txt — сообщает веб-роботам, таким как Google, что индексировать.
- /favicon.ico — значок вкладки в браузере, который автоматически запрашивается браузером.
- /.well\-known/* (все пути имеют префикс .well-known/) — используется различными спецификациями, такими как OpenID Connect, security.txt или webfinger.

Это простые, хорошо известные URL-адреса, которые браузер и другие сайты могут запрашивать автоматически. Если вы не добавите их на свой сайт, то каждый запрос на них будет проходить через промежуточное ПО, только чтобы вернуть 404. Это большая лишняя работа. «Короткие» маршруты позволяют избежать этих накладных расходов.

```

var builder = WebApplication
.CreateBuilder(args);
var app = builder.Build();

// возвращаем 404
app.MapGet("/favicon.ico",
() => Task.CompletedTask)
.ShortCircuit(404);

// возвращаем корректный robots.txt
app.MapGet("/robots.txt",
() => """
User-agent: *
Allow: /
""")
.ShortCircuit(200);

// любой запрос к /.well-known/ вернёт 404
app.MapShortCircuit(404, ".well-known");

// все другие запросы будут проходить
// через полный конвейер промежуточного ПО
app.MapGet("/", () => "Hello World!");

app.Run();

```

Источник: https://andrewlock.net/exploring-the-dotnet-8-preview-short-circuit-routing/

3 months, 3 weeks ago

День 1741. #ЗаметкиНаПолях#UnitTesting Пишем Тесты с AutofixtureAutoFixture - мощный инструмент для юнит-тестирования повседневных задач. Он помогает писать меньше кода в блоке Arrange. Рассмотрим его использование на примере совместно с библиотекой xUnit.

Сначала надо создать AutoFixture в тестовом классе:

```

private readonly IFixture _fixture;
public SampleTests()
{
_fixture = new Fixture();
}

```

AutoFixture использует обобщённый метод Create, генерирующий случайные данные для заданного типа, например:

```

var name = _fixture.Create<string>();
var age = _fixture.Create<int>();

```

Однако, с помощью дополнительного пакета AutoFixture.Xunit2, вы можете автоматически создавать целые классы, вообще без блока Arrange с помощью атрибута AutoData:

```

[Theory, AutoData]
public void TestEmployee(
string name, int age,
string pos, decimal rate)
{
// Act
var emp = new Employee(name, age, pos, rate);
// Assert
emp.Name.Should().Be(name);
emp.Age.Should().Be(age);
emp.Position.Should().Be(pos);
emp.Rate.Should().Be(rate);
}

```

Либо можно использовать метод Create:

```

[Fact]
public void TestEmployee()
{
// Arrange
var emp = _fixture.Create<Employee>();
var comp = _fixture.Create<Company>();

}

```

Здесь все свойства классов будут заданы случайными значениями.

Вы можете управлять созданием, задавая данные для определённых свойств. Также можно создавать коллекции элементов:

```

var emps = _fixture
.CreateMany<Employee>(5).ToList();
var comp = _fixture.Build<Company>()
.OmitAutoProperties()
.With(x => x.Employees, emps)
.Without(x => x.City)
.Create();

```

Здесь вызов OmitAutoProperties не будет задавать случайные значения свойствам, у которых есть значения по умолчанию. А Without не будет задавать значение выбранного свойства (в примере выше City останется null).

Вы можете создавать реализации интерфейсов с помощью метода Register:

```

_fixture.Register<IMyInterface>(() =>
new FakeMyInterface());

```

Здесь каждый раз, когда Autofixture нужно будет создать класс, зависящий от IMyInterface, будет создаваться экземпляр FakeMyInterface.

AutoFixture также можно использовать с пакетами для создания моков, вроде Moq или NSubstitute. Для этого надо настроить создание Autofixture (пример для Moq):

```

var _fixture = new Fixture()
.Customize(new AutoMoqCustomization
{ ConfigureMembers = true });

```

Тогда Autofixture можно будет использовать для создания реализаций интерфейсов:

```

var result = _fixture.Create<IMyInterface>();

```

При этом установка ConfigureMembers в true приводит к тому, что для классов-реализаций интерфейсов Autofixture сгенерирует случайные значения для свойств.

Здесь можно посмотреть множество других примеров использования AutoFixture.

Источник: https://dev.to/serhii_korol_ab7776c50dba/you-write-unit-tests-wrong-5d9f

3 months, 3 weeks ago

День 1740. #Карьера Чек-листы. Как Ничего не Забыть
Основная проблема разработки ПО в том, что происходит огромное количество процессов, а наш мозг не способен решать несколько задач одновременно.

Проблема не в том, что вы не знаете, как сделать, а в том, что вы забываете это сделать, хотя знаете, что должны. Простое решение - чек-листы.

Контрольный список поможет вам сосредоточиться на сложных частях вашей задачи, отвлекая внимание от разных мелочей. Однако он не должен ограничивать вас — он существует, чтобы помочь вам не забывать выполнять тривиальные, но важные действия.

Чек-листы бывают двух видов:
- Прочитал—сделал. Цель — читать каждый пункт и выполнять действия строго друг за другом.
- Сделал—отметил. Цель - выполнять действия, а затем проверять и подтверждать завершённые действия отметкой.

Например, чек-лист для новой кодовой базы:
1. Использовать Git.
2. Автоматизировать сборку.
3. Включить все сообщения об ошибках.

1. Использовать Git.
Первое, что нужно сделать в новой кодовой базе, — инициализировать локальный репозиторий Git. Рекомендация – делать это для любой кодовой базы, которая должна прожить больше недели. Вы всегда можете всё отменить, просто удалив папку .git.

2. Автоматизировать сборку.
Создайте минимальный объём кода, который сможете развернуть. Даже если у вас нет конвейера развёртывания или доступа к производственной среде. Создайте файл сценария, выполняющего сборку, и тоже отправьте коммит в Git. Например, простой .bat файл с командой:

dotnet build \-\-configuration Release

Обратите внимание на сборку в режиме Release. Автоматизированная сборка должна отражать то, что в итоге будет запущено в производство. По мере добавления шагов сборки их следует добавлять и в скрипт.

3. Включить все сообщения об ошибках.
Старайтесь использовать предупреждения компилятора и другие автоматические инструменты — они способны находить разные проблемы с кодом. Быстро устранить сотню существующих предупреждений может быть сложно. Гораздо проще реагировать на предупреждение в момент его появления. Поэтому первое, что нужно сделать в новой кодовой базе, — включить параметр «Представлять предупреждения как ошибки». Это поможет избежать накопления любых предупреждений компилятора.

Кроме того, добавьте статические анализаторы кода, такие как Roslyn. Статический анализ кода похож на автоматизированный код-ревью. В отличие от предупреждений компилятора, статические анализаторы часто дают ложные срабатывания, но обычно предлагают разные варианты их подавления, так что не стоит их игнорировать.

Добавление проверок в существующую кодовую базу
Часто вы можете включить один тип предупреждений за раз. В существующей кодовой базе уже могут быть сотни предупреждений. Извлеките список и сгруппируйте его по типам. Выберите конкретный тип предупреждений, исправьте их, пока они ещё являются предупреждениями, чтобы можно было продолжать работу с кодом. А после превратите эти предупреждения в ошибки. Затем перейдите к другому типу предупреждений или другой части кодовой базы.

Ключевой момент — правило бойскаута: оставлять код в лучшем состоянии, чем вы его нашли.

Преимущество обработки предупреждений как ошибок в том, что вы переходите на новый уровень качества. При рассмотрении предупреждений как ошибок и включении статического анализа кода вы теряете часть контроля. Это звучит неприятно, но может стать вашим преимуществом.

Когда сверху от вас требуют «просто сделать побыстрее», т.к. «нет времени делать как положено», представьте, что вы отвечаете: «Если я сделаю так, код не скомпилируется». Даже если это будет не очень честно, вы всегда сможете утверждать, что конечная цель — это качественное ПО. Это должно быть выгодно для всей организации.

Источник: Марк Симан “Код, который умещается в голове”. СПб.: Питер, 2023. Глава 2.

3 months, 4 weeks ago

День 1735. #ЗаметкиНаПолях Фоновые Задачи и Как Их Использовать. ОкончаниеНачалоОчистка кэша с помощью фоновой задачи
Вы можете создать фоновую задачу, которая запускается через регулярные промежутки времени, например раз в час или раз в день, чтобы проверять срок действия кэшированных элементов. Каждый кэшированный элемент может иметь метку времени или значение времени жизни (TTL), связанное с ним, чтобы указать, когда его следует считать устаревшим.

Вот как будет выглядеть упрощённое управление кэшем в приложении:

```

var cache = new CacheManager();

// Добавляем элементы в кэш
cache.AddItem("item1", "value1",
TimeSpan.FromSeconds(30));
cache.AddItem("item2", "value2",
TimeSpan.FromMinutes(1));

// Начинаем очистку кэша
_ = Task.Run(() => cache.StartCleanup(
TimeSpan.FromSeconds(15)));

// Продолжаем работу приложения
Console.WriteLine("Приложение работает...");
Console.ReadLine();

```

В этом примере CacheManager управляет кэшем и имеет фоновую задачу (StartCleanup), которая периодически удаляет устаревшие элементы в зависимости от их меток TTL. Это гарантирует, что кэш будет оставаться актуальным и не будет расти бесконечно:

```

class CacheManager
{
private Dictionary<string, CacheItem>
cache = new();

public void AddItem(
string key,
object value,
TimeSpan expiration)
{
var item = new CacheItem(
value,
DateTime.Now.Add(expiration));
cache[key] = item;
}

public async Task StartCleanup(
TimeSpan interval)
{
while (true)
{
await Task.Delay(interval);
var now = DateTime.Now;
var toRemove = new List<string>();

<pre> foreach (var kvp in cache) { if (kvp.Value.Expiration < now) toRemove.Add(kvp.Key); } foreach (var key in toRemove) { Console.WriteLine($"{key} удалён"); cache.Remove(key); } } </pre>

}
}

class CacheItem
{
public object Value { get; }
public DateTime Expiration { get; }

public CacheItem(object value,
DateTime expiration)
{
Value = value;
Expiration = expiration;
}
}

```

Вывод:

```
Приложение работает…
// через 30 секунд
item1 удалён
// через 1 минуту
item2 удалён

```
Фоновые задачи по очистке кэша помогают поддерживать производительность приложений, обеспечивая эффективность кэша и избегая использования устаревших данных.

ИтогоФоновые задачи – полезный инструмент для приложений .NET.
- Фоновые задачи предотвращают блокировку основного потока приложения длительными операциями, сохраняя отзывчивость UI и предотвращая зависание приложения.
- Выполняя ресурсоемкие задачи в фоновом режиме, приложения могут более эффективно использовать системные ресурсы, что приводит к повышению производительности и масштабируемости.
- Фоновые задачи обеспечивают параллельное выполнение задач, позволяя приложениям одновременно обрабатывать несколько операций, что важно для обработки больших рабочих нагрузок.
- Они идеально подходят для автоматизации рутинных задач, таких как очистка кэша, синхронизация данных и обслуживание баз данных, сокращая количество ручного вмешательства и обеспечивая точность данных.
- Фоновые задачи помогают эффективно управлять ресурсоёмкими операциями, такими как обработка изображений или доставка электронной почты, предотвращая истощение ресурсов.
- Они способствуют масштабируемости приложения, позволяя ему справляться с возросшей нагрузкой и требованиями без значительного снижения производительности.

Источник: https://stefandjokic.tech/posts/background-tasks-how-to-use-them

3 months, 4 weeks ago

День 1734. #ЗаметкиНаПолях Фоновые Задачи и Как Их Использовать. НачалоВ .NET фоновые задачи — это асинхронные операции, которые выполняются независимо от основного потока приложения. Они используются для выполнения задач, которые не должны блокировать основной поток, например длительных вычислений, операций ввода-вывода или задач, которые могут выполняться одновременно.Одной из распространённых реализаций является использование async/await:

```

Console.WriteLine("Основной поток: старт");
var bgTask = Task.Run(() => DoBgWork());

// продолжаем работу в основном потоке
for (int i = 0; i < 5; i++)
{
Console.WriteLine($"Основной поток: {i}...");
await Task.Delay(1000);
}

// ждём завершения фоновой задачи
await bgTask;

Console.WriteLine("Основной поток: завершено.");

static void DoBgWork()
{
Console.WriteLine("Фоновый поток: старт");
// какая-то длительная работа
for (int i = 0; i < 5; i++)
{
Console.WriteLine($"Фоновый поток: {i}...");
Task.Delay(1000).Wait();
}

Console.WriteLine("Фоновый поток: завершено.");
}

```

Варианты использования в реальных приложениях1. Уведомления по email:Отправка уведомлений по email может занимать много времени и вызывать задержки в сети. Вы не хотите, чтобы основной поток приложения ждал завершения доставки email.

2. Обработка изображений и файлов:Такие задачи, как изменение размера изображения, загрузка файлов или перекодирование видео, могут требовать больших ресурсов и времени.

3. Очистка и обслуживание базы данных:В приложениях с БД рутинные задачи обслуживания, такие как архивирование, очистка старых данных или переиндексация, могут быть критически важными, но отнимать много времени. Такие задачи можно реализовать в фоновом процессе и запланировать на время минимальной нагрузки основного приложения.

4. Обслуживание кэша:Со временем в кэшах могут накапливаться устаревшие данные, что приводит к неэффективности и увеличению использования памяти.

Завтра рассмотрим пример, как реализовать фоновую задачу очистки кэша.

*Окончание следует…

Источник:* https://stefandjokic.tech/posts/background-tasks-how-to-use-them

4 months ago

День 1733. #BestPractices#ProjectManagement Принципы Бережливой Разработки ПОБережливая Разработка ПО (Lean Software Development) — это гибкая система управления проектами и разработки продуктов, основанная на принципах бережливого производства. Основное внимание уделяется обеспечению ценности для клиента путём оптимизации ресурсов, рабочих потоков и процессов. Ниже рассмотрим основные принципы бережливой разработки.1. Устранение потерьЭта концепция заимствована из мира бережливого производства, где она известна как «муда» (от японского бесполезность, расточительность). В разработке ПО потерями может быть что угодно: от написания ненужного кода до чрезмерных совещаний, которые не приносят никакой пользы. Цель состоит в том, чтобы оптимизировать рабочий процесс, выявляя и удаляя всё, что не помогает конечному продукту или не удовлетворяет потребностям клиента.

2. Усиленное обучениеОбучение является неотъемлемой частью разработки. Принцип усиленного обучения подчёркивает, что команда всегда должна находиться в состоянии непрерывного обучения. Будь то проверка кода, обратная связь или изучение новых материалов, этот принцип предполагает, что более информированная команда производит продукт более высокого качества. Такие практики, как предметно-ориентированное проектирование (DDD), помогают команде сосредоточиться на изучении и правильном моделировании предметной области.

3. Принятие решения как можно позжеСлишком раннее принятие решений может привести к переработке, если эти решения окажутся неправильными. Этот принцип советует отложить принятие решения до последнего ответственного момента. Это позволит команде получить максимальное количество информации и контекста перед принятием решения, тем самым снижая вероятность дорогостоящих ошибок.

4. Максимально быстрая поставкаСкорость и эффективность являются ключевыми факторами в бережливой разработке программного обеспечения. Этот принцип направлен на максимально быструю поставку функционального продукта покупателю. Речь идет не о спешке, а о поиске оптимального потока, который позволит выполнить быструю поставку без ущерба для качества. Важными показателями, которые команды могут отслеживать, чтобы определить скорость поставки готовых продуктов, являются
- время цикла (cycle time) - время, которое нужно команде, чтобы создать продукт,
- время поставки (lead time) – время между выставлением заказа клиентом и исполнением заказа.

5. Расширение возможностей командыВ рамках бережливой разработки ПО мотивированная и самостоятельная команда считается более эффективной и гибкой. Расширение прав и возможностей команды предполагает предоставление им автономии в принятии решений и ответственности за выполнение своих задач. Это создаёт чувство ответственности среди членов команды, повышая их производительность и продуктивность.

6. Обеспечение целостностиКачество не должно быть второстепенным вопросом; оно должно быть интегрировано в продукт с самого начала. Обеспечение целостности означает создание надёжной, удобной в обслуживании и адаптируемой системы с самого начала. Это требует стремления к совершенству от каждого члена команды на каждом этапе процесса разработки.

7. Оптимизация всегоПринципы бережливого производства подчеркивают важность рассмотрения процесса разработки как единого целого. Вместо того, чтобы сосредотачиваться исключительно на отдельных задачах или модулях, важно понять, как каждый элемент вписывается в общую картину. Оптимизируя всю систему, а не её части, вы можете обеспечить максимальную эффективность всего процесса.

Помните: «система, порождающая дефекты, является дефектной системой» - Джеффри Палермо. Обеспечьте качество всего процесса и выявляйте проблемы до того, как они покинут процесс.

Источник: https://ardalis.com/principles-lean-software-development/

5 months, 1 week ago

День 1692. #ЗаметкиНаПолях Общее Хранилище или Долгоживущие Ветки Функций?Эффективные стратегиях разработки ПО, часто делятся на два подхода: разработка на основе общего хранилища кода и долгоживущие ветки функций. Каждый имеет свои преимущества и проблемы, и знание того, какой подход выбрать, может существенно повлиять на успех вашего проекта.Общее хранилищеПодход к разработке ПО, при котором разработчики часто интегрируют свои изменения кода в одну общую ветку, известную как trunk. Цель — выполнять небольшие инкрементные обновления, чтобы минимизировать конфликты слияния и оптимизировать конвейер разработки. Непрерывная интеграция (CI) часто является неотъемлемой частью этой стратегии, поскольку позволяет быстро обнаруживать и решать проблемы.

Плюсы:- CI обеспечивает мгновенную обратную связь, что упрощает раннее выявление проблем.
- Слияние становится проще благодаря частым интеграциям.
- Частые слияния улучшают общение в команде.
- Функции можно развёртывать быстрее и чаще.
- Единый источник достоверной информации (общая ветка) упрощает настройку CI/CD.

Минусы:- Без надежных автоматизированных тестов может быть рискованным. Важно знать, что каждое новое изменение не сломало что-то в системе.
- Значительные обновления может быть сложно реализовать поэтапно. Хотя, крупные изменения в качестве исключения могут быть выделены в отдельные ветки.
- Флаги функций могут добавить дополнительный уровень сложности. Условная логика добавляет хаоса, и после добавления функций необходимо приложить дополнительные усилия для удаления условных операторов.

Долгоживущие* ветки функцийЭтот подход предполагает создание отдельных веток для разработки новых функций или внесения существенных изменений. Они существуют независимо от основной в течение длительного периода времени, что позволяет разработчикам работать изолированно. Как только функция или изменение готовы и протестированы, ветка сливается с основной, что часто требует всестороннего анализа и потенциально сложного разрешения конфликтов.

Термин «долгоживущий» даётся без какой-либо конкретной меры. Его «долголетие» зависит от того, насколько активна кодовая база. Важным фактором является количество изменений в основной ветке с момента открытия ветки функции, а не календарное время.Плюсы:*- Разработчики могут работать над большими функциями, не затрагивая основную ветку.
- Основная ветка остается стабильной. Легче гарантировать, что только проверенный рабочий код будет разрешён для слияния с основной веткой.
- Идеально подходит для реализации значительных изменений.
- Функции можно выпускать массово, используя (ещё одну) ветку для релиза и объединяя несколько веток функций в ветку релиза. Особенно полезно для взаимозависимых функций.

Минусы:- Чем старше ветка, тем сложнее её объединить. Разрешение конфликтов слияния может отнять значительное время, если веткам часто позволено отклоняться от основной на длительные периоды времени.
- Интеграция происходит реже. Проблемы и несовместимости между функциями будут обнаружены позже, часто только после попытки слияния.
- Работа в изоляции может оказаться контрпродуктивной. Дублирование кода, недопонимание, застой в работе и т.п. могут встречаться чаще в изолированной ветке, чем в основной, над которой активно работает вся команда.
- Ветка функции может значительно отличаться от основной. Обычно это происходит, когда разработка основной ветки продолжается. Слияние изменений из основной ветки в ветку функции может смягчить эту ситуацию, но часто игнорируется членами команды.

ИтогоОба подхода могут иметь смысл в разных контекстах. Если вы используете один подход, а кто-то из команды предлагает другой, подумайте над этим. Что выбор во многом зависит от потребностей вашей команды, сложности проекта и требований бизнеса. Лучшая стратегия — та, которая адаптируется к потребностям вашего проекта и одновременно смягчает его проблемы. Это не вопрос универсального подхода, а поиск идеального решения для вашей команды.

Источник

We recommend to visit

🛒 Магазин сообществ в соц. сетях 24/7
⚡️ В наличии любые тематики и количества, связь в ЛС @timur_chik1


ac99e5f0c33c6df9805b

Last updated 5 months ago

От создателей «Топора».
Сделаем лучший русскоязычный кибер тг-канал вместе.

Новости присылать сюда: @CyberTopor_bot

Для связи: @toporch

Ссылка для друзей и знакомых: https://t.me/+iI538bjZlGJmYWQy

Last updated 1 month, 1 week ago

NN
NN
1,236,156 @naebnet

Медиа про интернет, технологии и безопасность

Сотрудничество: @nnmanager
Ютуб: https://youtube.com/naebnet

Last updated 4 hours ago