День 1879. #Оффтоп
Сегодня порекомендую вам очередное виде с ютуба, а также канал ThePrimeTime. Честно говоря, не смог найти подробной информации об авторе. Знаю только, что он работает в Netflix. Стек у него не .NET, но и в своих видео он мало касается какой-то определённой технологии, больше рассуждает об общих проблемах разработки.

Одно из последних его видео, которое мне понравилось, на самом деле, реакция на видео с канала Awesome (тоже про разработку). Видео называется The Harsh Reality of Good Software (Жёсткая Реальность Хорошего ПО).

В двух словах. Всем плевать, сколько вы потратили времени на ПО, какой красивый и хорошо структурированный у вас код и т.д., и т.п. Программе достаточно сломаться 1 раз у конечного пользователя – и ваше ПО оценивается как говно. Несмотря на всё это, нам надо создавать хорошее ПО. И прочие рассуждения на тему чистого и читаемого кода.

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

Наслаждайтесь (потребуются навыки английского, либо автосубтитры)
https://youtu.be/NiljDyzAOcI

PS: не знал про американские горки в Excel. Это великолепно!!!

День 1880. #ЧтоНовенького
.NET Smart Components
Новые достижения в области ИИ обещают революционизировать то, как мы взаимодействуем с ПО и используем его. Но добавление функций ИИ в существующее ПО может оказаться сложной задачей. Microsoft представили новые интеллектуальные компоненты .NET — набор компонентов UI на базе ИИ, которые можно быстро и легко добавлять в приложения .NET.

.NET Smart Components находятся на этапе эксперимента и пока доступны для страниц Blazor, MVC и Razor с .NET 6 и более поздних версий. Также планируется предоставить компоненты для других инфраструктур .NET, таких как .NET MAUI, WPF и Windows Forms.

Умная вставка
Smart Paste автоматически заполняет формы, используя данные из буфера обмена пользователя, одним нажатием кнопки. Вы можете использовать её с любой существующей формой веб-приложения. Это помогает пользователям добавлять данные из внешних источников ввода каждого поля в отдельности.

Умные поля для ввода
Вы можете настроить автоматическое завершение предложений в полях для ввода текса, используя свой предпочитаемый стиль текста, тон, политики, URL-адреса и т. д. Это поможет пользователям печатать быстрее.

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

Примеры
Демонстрацию работы .NET Smart Components можно посмотреть в этом видео. А попробовать их в Blazor или MVC/RazorPages, используя примеры приложений смарт-компонентов .NET на GitHub.
Для работы .NET Smart Components потребуется развернуть серверную часть Azure OpenAI, и добавить в файл конфигурации в корне решения ключ API, имя развертывания и URL конечной точки.

Добавление в существующее приложение
Чтобы добавить .NET Smart Components в существующие приложения Blazor, MVC или Razor Pages, посмотрите эти руководства:
- Начало работы с .NET Smart Components в Blazor
- Начало работы с .NET Smart Components в MVC или страницах Razor.

Обратная связь и поддержка
.NET Smart Components в настоящее время являются экспериментальными и официально не поддерживаются. В Microsoft хотят знать ваше мнение, полезны ли они и как их улучшить.

Источник: https://devblogs.microsoft.com/dotnet/introducing-dotnet-smart-components/

День 1881. #ЗаметкиНаПолях
Массовая Вставка в C# и EF Core. Начало
Независимо от того, создаёте ли вы платформу анализа данных, переносите устаревшую систему или привлекаете новых пользователей, вероятно, наступит момент, когда вам потребуется вставить огромный объём данных в БД. Традиционные методы слишком медленные. Поэтому необходимо понимание методов быстрой массовой вставки в C#. Сегодня рассмотрим несколько вариантов.

Примечание: Мы не будем рассматривать некоторые крайние варианты, вроде ручной генерации SQL запросов или использования параметров, возвращающих табличные значения (Table-Valued parameters).

Допустим, нам нужно вставить множество экземпляров класса User в соответствующую таблицу БД.

1. Простой (плохой) пример EF Core
Для сравнения рассмотрим простейший (плохой) вариант, где пользователи добавляются по одному:

using var ctx = new AppDbContext();
foreach (var u in GetUsers())
{
  ctx.Users.Add(u);
  await ctx.SaveChangesAsync();
}

Результаты ужасные (как и ожидалось из-за множества запросов в БД):

  100 пользователей - 20 мс,
 1000 – 260 мс,
10000 – 8,86 с.

Большее количество проверять бессмысленно, они занимают слишком много времени. Возьмём это за пример, как не надо делать массовую вставку.
*Заметьте, что время приведено только для сравнения между вариантами.

2. Добавление всех и сохранение в EF Core
Можно поправить пример выше, сначала добавив все записи в контекст, а затем 1 раз вызвав SaveChanges().

…
foreach (var u in GetUsers())
  context.Users.Add(u);
await ctx.SaveChangesAsync();

Результаты:

    100 - 2 мс,
   1000 - 18 мс,
  10000 - 203 мс,
 100000 - 2,13 с,
1000000 - 21,56 с.

3. AddRange в EF Core
Мы можем добавить в контекст сразу всю коллекцию, используя метод AddRange:

…
ctx.Users.AddRange(GetUsers());
await context.SaveChangesAsync();

Результаты аналогичны примеру выше, но код короче.

4. EF Core Bulk Extensions
Библиотеку EF Core Bulk Extensions можно использовать для повышения производительности. Кстати, она позволяет делать не только массовую вставку. Библиотека с открытым кодом, но платная для коммерческого использования. Для нашего варианта подойдёт метод BulkInsertAsync:

…
await context.BulkInsertAsync(GetUsers());

Результаты впечатляющие:

    100 - 1.9 мс,
   1000 - 8 мс,
  10000 - 76 мс,
 100000 - 742 мс,
1000000 - 8,3 с.

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

Источник: https://www.milanjovanovic.tech/blog/fast-sql-bulk-inserts-with-csharp-and-ef-core

День 1882. #ЗаметкиНаПолях
Массовые Вставки в C# и EF Core. Окончание
Начало

5. Dapper
Dapper — это простой преобразователь SQL в объекты .NET. Он позволяет нам легко вставить коллекцию объектов в БД:

using var conn = new SqlConnection(connString);
conn.Open();

var sql = @"
 INSERT INTO Users (FirstName, LastName, Email, …)
 VALUES (@FirstName, @LastName, @Email, …);";

await conn.ExecuteAsync(sql, GetUsers());

Результаты:

    100 пользователей - 10 мс
   1000 - 113 мс,
  10000 - 1,02 с,
 100000 - 10,9 с,
1000000 - 109,065 с.

6. SQL Bulk Copy
Наконец, для SQL Server мы можем попробовать использовать SqlBulkCopy. Эта реализация немного сложнее. Во-первых, нужно создать объект DataTable, содержащий объекты, которые мы хотим вставить:

DataTable GetUsersDataTable()
{
  var dt = new DataTable();
  dt.Columns.Add(nameof(User.FirstName),
   typeof(string));
  dt.Columns.Add(nameof(User.LastName),
   typeof(string));
  dt.Columns.Add(nameof(User.Email),
   typeof(string));
  …

  foreach (var u in GetUsers())
    dt.Rows.Add(
      u.FirstName, u.LastName, u.Email, …);

  return dt;
}

Теперь настроим SqlBulkCopy для выполнения вставки:

using var bc = new SqlBulkCopy(ConnString);

bc.DestinationTableName = "dbo.Users";
bc.ColumnMappings.Add(
 nameof(User.FirstName), "FirstName");
bc.ColumnMappings.Add(
 nameof(User.LastName), "LastName");
bc.ColumnMappings.Add(
 nameof(User.Email), "Email");

await bc.WriteToServerAsync(GetUsersDataTable());

Производительность невероятно высока:

    100 – 1,7 мс,
   1000 - 7 мс,
  10000 - 68 мс,
 100000 - 646 мс,
1000000 - 7,34 с.

Итого
SqlBulkCopy работает быстрее всех, однако EF Core Bulk Extensions обеспечивают фантастическую производительность, сохраняя при этом простоту использования, которой славится Entity Framework Core. Поэтому выбор зависит от требований вашего проекта:
- Главное – производительность? SqlBulkCopy или EF Core Bulk Extensions.
- Не хочется платить и нужна простота разработки? Грамотное использование EF Core всё равно даёт неплохие результаты.

Источник: https://www.milanjovanovic.tech/blog/fast-sql-bulk-inserts-with-csharp-and-ef-core

День 1883. #МоиИнструменты
Назначенные Задания с NCronJob
Hangfire/Quartz или фоновый сервис? А может что-то среднее? Если вам не нужен полноценный планировщик заданий с множеством настроек, но нужно нечто большее, чем просто BackgroundService, рассмотрите NCronJob.

Что это?
Простой и удобный планировщик заданий, работающий поверх IHostedService в .NET. Предоставляет два способа планирования заданий:
- Мгновенные задания — запуск задания прямо сейчас,
- Задания Cron — планирование задания, используя выражение cron.

Идея в том, чтобы иметь простой и лёгкий способ планирования заданий либо повторяющихся через нотацию cron, либо одноразовых (запускаемых с помощью мгновенных заданий). Библиотека построена на основе IHostedService и поэтому идеально подходит для приложений ASP.NET.

Особенности, отличающие NCronJob от BackgroundService:
- 2 вида заданий,
- передача параметров заданиям (как cron, так и мгновенным),
- (Скоро) Уведомления о завершении работы.

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

Как использовать?
Библиотека доступна в виде NuGet-пакета:

dotnet add package LinkDotNet.NCronJob

Для начала определим задание:

public class PrintHelloWorld : IJob
{
  private ILogger<PrintHelloWorld> logger;

  public PrintHelloWorld(
   ILogger<PrintHelloWorld> logger)
  {
    this.logger = logger;
  }
  
  public Task RunAsync(
   JobExecutionContext context, 
   CancellationToken ct = default)
  {
    logger.LogInformation(
     "Parameter: {Parameter}", context.Parameter);

    return Task.CompletedTask;
   }
}

Как видите, поддерживаются параметры. Это справедливо как для заданий, запускаемых через cron, так и для мгновенных заданий. Теперь зарегистрируем сервис:

builder.Services.AddNCronJob();
builder.Services
 .AddCronJob<PrintHelloWorld>(opt => 
 {
   // Каждую минуту
   opt.CronExpression = "* * * * *";
   // необязательный параметр
   opt.Parameter = "Hello Parameter";
 });

Готово!

Вы также можете запускать мгновенные задания откуда угодно:

public class MyService
{
  private IInstantJobRegistry jobReg;
  
  public MyService(IInstantJobRegistry jobReg) 
   => this.jobReg = jobReg;

  public void MyMethod() 
   => jobReg.AddInstantJob<MyJob>(
    "Необязательный параметр");
}

В настоящее время авторы пытаются добавить больше функций, поэтому, если вам не хватает важной функциональности, напишите им об этом в GitHub проекта.

Источник: https://steven-giesel.com/blogPost/f58777b8-e10b-4023-845b-9f5ad3b7e48f/ncronjob-scheduling-made-easy

День 1884. #ЗаметкиНаПолях
Генерация Спецификации OpenAPI при Сборке Проекта ASP.NET
Спецификация OpenAPI — мощный инструмент для описания и документирования API. Это стандарт, который позволяет вам определить структуру вашего API, включая конечные точки, модели запросов и ответов, а также требования безопасности. Спецификация OpenAPI — это файл JSON или YAML, который можно использовать для создания документации, клиентских библиотек и серверных заглушек.

Большинство разработчиков .NET генерируют спецификацию из кода. Библиотека Swashbuckle.AspNetCore — популярный выбор для создания спецификации OpenAPI на основе проектов веб-API ASP.NET Core. Вы можете легко добавить страницу для доступа к спецификации. Однако сложно проверить содержание спецификации, чтобы убедиться, что спецификация пригодна для использования потребителями. Один из способов улучшить это — сделать спецификацию частью вашего кода, чтобы вы могли просматривать ее во время проверок кода.

Microsoft предоставляет пакет NuGet Microsoft.Extensions.ApiDescription.Server, который позволяет генерировать спецификацию OpenAPI из кода во время сборки проекта.
Сначала создадим новый проект веб-API и добавим пакет Microsoft.Extensions.ApiDescription.Server:

dotnet new webapi --framework net8.0
dotnet add package Microsoft.Extensions.ApiDescription.Server

Теперь можно добавить следующие свойства в файл .csproj проекта, чтобы настроить генерацию спецификации OpenAPI:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>

    <OpenApiDocumentsDirectory>
     $(MSBuildProjectDirectory)
    </OpenApiDocumentsDirectory>
    <OpenApiGenerateDocuments>true</OpenApiGenerateDocuments>
    <OpenApiGenerateDocumentsOnBuild>
     true
    </OpenApiGenerateDocumentsOnBuild>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="8.0.3" />
    <PackageReference Include="Microsoft.Extensions.ApiDescription.Server" Version="8.0.3">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
  </ItemGroup>
</Project>

Теперь при сборке проекта спецификация будет сгенерирована в корне проекта в файле <ИмяПроекта>.json.

Источник: https://www.meziantou.net/generate-openapi-specification-at-build-time-from-the-code-in-asp-net-core.htm

День 1885. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 2. Основной результат разработки требований — общее видение и понимание
Материальным результатом разработки требований является документ в некой хранимой форме. Обычно это письменный документ, часто называемый спецификацией требований к ПО или бизнес-требованиями. Как вариант, требования можно оформить в виде карточек, стикеров на доске, диаграмм, приёмочных тестов или комбинации всего этого.

Но наиболее важными результатами разработки требований являются общее видение (понимание) и согласие заинтересованных сторон в отношении решения, которое будет создано командой проекта. Добившись этого понимания, можно проверить, соответствуют ли предлагаемый объём и бюджет проекта необходимым возможностям и характеристикам решения.

Управление ожиданиями — важная часть управления проектами. Разработка требований направлена на формирование общих ожиданий у представителей заинтересованных сторон. Спецификации требований содержат информацию об особенностях соглашения. Так согласовывается вся деятельность, связанная с проектом:
- работа, которую финансирует спонсор проекта;
- решение, которое, как ожидают клиенты, позволит им достичь бизнес-целей;
- ПО, которое проверяют тестировщики;
- продукт, который отделы маркетинга и продаж предложат миру;
- планы и списки задач, создаваемые руководителями и командами разработчиков проекта.

Часто трудно определить, одинаково ли понимают несколько человек нечто столь сложное, как проект по разработке ПО. Эти различия могут привести к тому, что участники будут стремиться к противоположным целям.
Изложение концепции (заявление о видении - Vision statement) определяет общую стратегическую цель, к достижению которой должны стремиться все участники проекта. Оно помогает достичь общего понимания и непротиворечивых ожиданий.

Вот примерный шаблон заявления о видении:

Для
[целевые клиенты]
Которые
[изложение бизнес-потребностей или возможностей]
Предполагается создать
[название продукта или проекта]
Являющийся
[тип продукта или проекта]
Позволяющий
[основные возможности продукта; основные преимущества, которые он обеспечит; веская причина покупки продукта или реализации проекта]
В отличие от
[текущей реальности или альтернативных продуктов]
Наш продукт
[краткое изложение основных преимуществ этого продукта по сравнению с текущей реальностью или товарами конкурентов]

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

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.

День 1886. #Здоровье
10 Упражнений, Чтобы Предотвратить Боли в Спине
Давно ничего не писал на тему здоровья. Многие из нас из-за сидячей работы сталкиваются с болью в спине. И не просто периодической скованностью, а с постоянной ноющей болью, которая возникает из-за долгих сеансов программирования. Вот 10 важных упражнений, которые помогут её избежать.

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

2. Сведение лопаток
Что делать: сядьте/встаньте прямо. Представьте, что держите карандаш между лопатками и сведите их. Удерживайте 10 секунд, отпустите и повторите.
Преимущества: Упражнение нацелено непосредственно на мышцы вокруг лопаток. Улучшает осанку, уменьшает напряжение в верхней части спины и плечах, а также может помочь облегчить боль в шее за счет укрепления мышц, поддерживающих верхнюю часть позвоночника.

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

4. Отжимания на столе стоя
Что делать: встаньте спиной к столу, положив руки на край, и медленно опустите тело, затем снова поднимитесь.
Преимущества: Использование стола для отжиманий помогает задействовать трицепсы, плечи и даже грудные мышцы. Это упражнение требует минимума движений, но развивает силу верхней части тела, которая поддерживает осанку. Укрепление этих мышц означает, что ваш позвоночник получит больше поддержки, что потенциально уменьшит боль в спине.

5. Планка для ног
Что делать: сядьте на край стула, ноги вместе, выпрямите их перед собой и задержите. Попробуйте для начала секунд 30.
Преимущества: это упражнение, представляющее собой сидячую версию планки для корпуса, позволяет сохранять прямое положение ног, активируя основные мышцы. Более сильные мышцы корпуса улучшают осанку, уменьшают нагрузку на поясницу и могут улучшить баланс и устойчивость как в кресле, так и вне его.

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

Источник: https://learnhub.top/10-essential-exercises-for-programmers-to-prevent-back-pain/

День 1887. #Здоровье
10 Упражнений, Чтобы Предотвратить Боли в Спине. Окончание
Начало

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

7. Прогулки
Что делать: каждый час совершайте 5-минутную прогулку. Будь то дома или в офисе.
Преимущества: улучшает кровообращение и предотвращает скованность, возникающую при длительном сидении. Улучшает общее состояние сердечно-сосудистой системы, повышает уровень энергии и даже может повысить креативность и способность решать проблемы, давая вашему мозгу отдохнуть от экрана.

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

9. Кошка-корова
Что делать: встаньте на четвереньки. Выгните спину вверх, прижав подбородок к груди (кошка), затем опустите спину вниз, задрав голову вверх (корова).
Преимущества: мягкое плавное движение, которое растягивает позвоночник и помогает придать гибкость всей спине и снять напряжение в пояснице. Это также отличное средство от стресса и помогает сосредоточиться.

10. Растяжка кобры
Что делать: лягте на живот, ладони прижмите к груди. Отожмитесь от пола, подняв только грудь, выгибая спину и задирая голову вверх.
Преимущества: укрепляет позвоночник и раскрывает грудь и плечи, противодействуя наклону вперед. Улучшает силу и гибкость позвоночника, уменьшает напряжение в пояснице и может помочь облегчить дискомфорт, связанный с осанкой. Это также полезно для улучшения дыхания и снижения стресса.

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

Источник: https://learnhub.top/10-essential-exercises-for-programmers-to-prevent-back-pain/

День 1888. #ProjectManagement
Что Такое SLI, SLO и SLA
При проектировании архитектуры ПО мы должны учитывать как функциональные, так и нефункциональные требования. Сегодня разберём SLO, SLA и SLI и как они влияют на жизненный цикл ПО.

1. Индикатор уровня обслуживания (Service Level Indicator - SLI)
Измеримая мера некоторого аспекта уровня предоставляемого обслуживания: процент времени безотказной работы, время ответа или частота сообщений об ошибках. SLI используются для объективного измерения производительности сервиса и для проверки SLO.

Как отслеживать?
- Тщательно определите проверяемые метрики. Например «ошибки HTTP» - недостаточно чётко. Какие именно? 404, 401 и 500 — обозначают ошибки, но их появление может как указывать, так и не указывать на ошибки в системе.
- Определите функции для проверки качества релизов, чтобы гарантировать, что новый релиз не ухудшит существующие значения SLI.

2. Целевой уровень обслуживания (Service Level Objective - SLO)
Целевой уровень обслуживания между поставщиком услуг и конечным пользователем, который измеряется конкретными показателями. Если SLI —фактическое значение измерения, SLO — конечная цель, которую необходимо достичь для этого SLI. SLO - желаемая цель для некоторых показателей (обычно производительности и надёжности), которых стремится достичь сервис. Вы можете указать значение SLO для каждой метрики, которая важна для вас и ваших клиентов. Например:
- 99% запросов к веб-сервису должны иметь задержку менее 300 мс;
- 99,9% запросов к определённой конечной точке должны иметь задержку менее 100 мс;
- 99,9% запросов должны возвращать успешный код состояния.
SLO являются конкретными, подробными и измеримыми. Например, заявление: «Запросы, как правило, должны быть быстрыми» - слишком расплывчато, и его невозможно измерить.

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

3. Соглашение об уровне обслуживания (Service Level Agreement - SLA)
Официальное соглашение между поставщиком услуг и клиентом. В отличие от SLO, SLA имеют юридическую силу и предусматривают последствия несоблюдения. Если продукт не соответствует SLA, это может вести к штрафам, неустойкам и т.п. Примером SLA является скорость реагирования техподдержки, например, закрывать открытую клиентом заявку в течение 24 часов.

Взаимодействие между SLO, SLA и SLI существенно влияет на решения по архитектуре ПО:
- SLO и SLI помогают архитекторам определить показатели надёжности и производительности, которым должна соответствовать система. Это влияет на выбор технологий и шаблонов, позволяющих достичь этих показателей. Микросервис или монолит? С# или Rust? Локально или в облаке?
- Для соблюдения требований SLO системе может потребоваться обрабатывать большое количество запросов в секунду, что требует масштабируемых архитектур, таких как микросервисы или бессерверные вычисления.
- Необходимость соблюдения SLA может привести к внедрению механизмов резервирования и аварийного переключения для обеспечения высокой доступности и минимизации времени простоя.
- SLI требуют надёжных систем мониторинга и оповещения для отслеживания производительности услуги в режиме реального времени и уведомления, когда SLO подвергаются риску нарушения.
- Необходимость удовлетворять SLO может влиять на распределение ресурсов, что приводит к принятию решений о балансировке нагрузки, сегментировании базы данных или использовании сетей доставки контента (CDN).
- Штрафы, связанные с SLA, могут повлиять на стоимость, побуждая архитектуру быть более экономичной, при этом соответствуя уровням обслуживания.

Источник: https://www.code4it.dev/architecture-notes/sli-vs-slo-vs-sla/

День 1889. #ЗаметкиНаПолях
Проверка Схемы Json в .NET
Часто бывает полезно проверять документы JSON на соответствие схеме. Схема JSON — это словарь, который можно использовать для аннотирования и проверки документов JSON. Например, вы можете проверить документ JSON, полученный от REST API, или файл конфигурации, написанный пользователем. Сегодня посмотрим, как проверить данные JSON на соответствие схеме в .NET.

Совет. В PowerShell, вы можете использовать командлет Test-Json для проверки данных JSON на соответствие схеме JSON.

.NET не поддерживает проверку схемы JSON «из коробки». Однако существует несколько сторонних библиотек, которые можно использовать для проверки данных JSON на соответствие схеме. Здесь мы используем библиотеку JsonSchema.Net https://www.nuget.org/packages/JsonSchema.Net.

Создадим проект:

dotnet new console
dotnet add package JsonSchema.Net

Следующий код показывает, как проверить данные JSON на соответствие схеме:

using System.Text.Json.Nodes;
using Json.Schema;

//пример схемы
var schema = """
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/product.schema.json",
  "title": "Product",
  "description": "A product from Acme's catalog",
  "type": "object",
  "properties": {
    "productName": {
      "description": "Name of the product",
      "type": "string"
    },
    "price": {
      "description": "The price of the product",
      "type": "number",
      "exclusiveMinimum": 0
    }
  },
  "required": [ "productName", "price" ]
}
""";

// полученные данные
var json = """
{
  "productName": "test",
  "price": -1
}
""";

// Проверка
var jsonSchema = JsonSchema.FromText(schema);
var result = jsonSchema
 .Evaluate(JsonNode.Parse(json));

if (!result.IsValid)
{
  Console.WriteLine("Invalid document");
  if (result.HasErrors)
  {
    foreach (var error in result.Errors)
      Console.WriteLine(error.Key + ": " + error.Value);
  }
}

Источник: https://www.meziantou.net/json-schema-validation-in-dotnet.htm

День 1890. #ЧтоНовенького
В C# 13 Разрешат ref и unsafe в Итераторах и Асинхронном Коде
Сейчас вы не можете написать так:

async Task MyMethodAsync()
{
  await AnAsyncMethod();
  ref int x = ref GetRef();
  DoSomething(ref x);
  await AnohterAsnycMethod();
}

Проблема совместного использования await и ref заключается в том, что компилятор не может гарантировать, что ссылка по-прежнему будет действительна после await. Но в приведённом выше случае это не должно быть проблемой, поскольку x используется только между двумя вызовами await, где ссылка всё ещё действительна.

То же самое относится и к ссылочным структурам, таким как Span<T> или ReadOnlySpan<T>. Вы не можете использовать их в итераторах (yield) или асинхронных методах. Предложение позволит писать так:

async Task MyMethodAsync()
{
  var result = await AnAsyncMethod();
  var span = result.AsSpan();
  DoSomething(span);
  await AnohterAsnycMethod();
}

Подробности предложения здесь.

Источник: https://steven-giesel.com/blogPost/0d4216e5-4445-48c4-8d9c-3ff5aa1bfdc3/c-13-allow-ref-and-unsafe-in-iterators-and-async

День 1891. #ЗаметкиНаПолях
Используем localStorage в Современных Приложениях. Начало
API localStorage позволяет разработчикам хранить пары ключ-значение в браузере пользователя. Сегодня рассмотрим различные аспекты API localStorage, преимущества, ограничения и альтернативные варианты.

Что это?
API localStorage — встроенная функция браузеров, позволяющая веб-разработчикам постоянно хранить небольшие объёмы данных в формате «ключ-значение» на устройстве пользователя. Данные остаются доступными даже после того, как пользователь закрывает браузер или уходит со страницы. Это удобный способ поддерживать состояние и сохранять пользовательские настройки, не полагаясь на хранилище на стороне сервера.

// Сохранение
localStorage.setItem('username', 'john_doe');

// Извлечение
let user = localStorage.getItem('username');

// Удаление
localStorage.removeItem('username');

// Очистка
localStorage.clear();

Хранение сложных данных возможно с помощью сериализации JSON (JSON.stringify и JSON.parse):

let user = {
  name: 'Alice',
  age: 42,
  email: '[email protected]'
};

localStorage.setItem('user', 
 JSON.stringify(user));

let storedUser = 
 JSON.parse(localStorage.getItem('user'));

Ограничения
1. Неасинхронный API. Любые операции в localStorage потенциально могут заблокировать основной поток.
2. Ограниченная структура данных. Простое хранилище ключ-значение делает localStorage непригодным для хранения сложных структур данных или управления связями между элементами данных.
3. Накладные расходы. Хранение JSON требует сериализации, потенциально замедляя операции до 10 раз.
4. Отсутствие индексации. Нет возможности индексирования, что затрудняет эффективный поиск или перебор данных на основе определённых критериев.
5. Блокировка вкладок. Операции localStorage на одной вкладке могут повлиять на производительность других вкладок, монополизируя ресурсы ЦП.
6. Ограничение хранилища. Обычно около 5 МБ для каждого источника localStorage.

Причины использовать
API localStorage в JavaScript работает на удивление быстро по сравнению с альтернативными решениями. Он превосходно справляется с хранением небольших данных. Доступ к данным localStorage и их изменение требуют минимальных затрат.

Когда не использовать
1. Данные извлекаются через запросы по критериям.
localStorage не предоставляет таких возможностей. Сложный поиск данных может привести к неэффективному коду и снижению производительности.
2. Большие документы JSON.
Важно оценить размер данных и рассмотреть более надёжные решения для обработки значительных наборов данных.
3. Множество операций чтения/записи.
Чрезмерное количество операций чтения и записи в localStorage может привести к снижению производительности.
4. Нет необходимости в постоянном хранении данных.
Если приложению не нужно хранить данные между сеансами, лучше использовать структуры данных в памяти, такие как Map или Set. Они обеспечивают скорость и эффективность обработки временных данных.

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

Источник: https://rxdb.info/articles/localstorage.html

День 1892. #ЗаметкиНаПолях
Используем localStorage в Современных Приложениях. Окончание
Начало

Что использовать вместо localStorage в JavaScript?

IndexedDB
IndexedDB предназначена для хранения не только пар ключ-значение, но и документов JSON. В отличие от localStorage, может обрабатывать значительно большие наборы данных, поддерживает индексирование, упрощает выполнение запросов, делая возможными запросы по диапазонам. Однако сложные запросы могут создавать проблемы. Существуют библиотеки-оболочки, такие как RxDB или Dexie.js. Они дополняют IndexedDB такими функциями, как сложные запросы и наблюдаемость, повышая удобство использования для современных приложений.

API файловой системы (OPFS)
Обеспечивает прямой доступ к изолированной под каждый источник файловой системе, которая высоко оптимизирована для производительности и предлагает доступ для записи. Однако работа с API OPFS может быть сложной, и она доступна только внутри WebWorker. Чтобы упростить его использование и расширить его возможности, есть библиотеки-оболочки, такие как OPFS RxStorage, которая создает комплексную базу данных поверх API OPFS.

Куки
Куки когда-то были основным методом хранения данных на стороне клиента, но потеряли популярность в современной веб-разработке из-за своих ограничений. Они могут хранить данные, но работают примерно в 100 раз медленнее, чем API localStorage. Кроме того, куки включаются в заголовок HTTP, что может повлиять на производительность сети. Куки не рекомендуются для хранения данных в современных веб-приложениях.

WebSQL
WebSQL предлагает SQL-интерфейс для хранения данных на стороне клиента, но является устаревшей технологией, и её следует избегать. Этот API постепенно выводится из современных браузеров.

sessionStorage
Этот механизм хранения сохраняет данные только на время работы вкладки или сеанса браузера. Он выдерживает перезагрузку и восстановление страниц. Но важно отметить, что sessionStorage ограничен по объёму и может не подходить для всех случаев использования.

AsyncStorage для React Native
Подходящее решение, похожее на localStorage, но с поддержкой асинхронного кода. Удобная альтернатива для сохранения данных в приложениях React Native.

node-localstorage для Node.js
Нативный localStorage не определён в Node.js (Next.js). npm-пакет node-localstorage устраняет этот пробел.

localStorage в расширениях браузера
Расширения для Chrome и Firefox поддерживают API localStorage, но не рекомендуется использовать его в этом контексте. Браузер очищает данные во многих сценариях, например, когда пользователи очищают историю просмотров. Вместо этого для расширений браузера следует использовать Extension Storage API. Он работает асинхронно, обеспечивает автоматическую синхронизацию для репликации данных между всеми экземплярами браузера, где пользователь авторизован, а также способен хранить JSON-объекты, вместо простых строк.

Итого
Простота и скорость localstorage делают его отличным выбором для небольших данных. Но по мере роста сложности приложений разработчики должны тщательно оценивать потребности в хранилище. Для сценариев, требующих расширенных запросов, сложных структур данных или операций с большими объёмами, альтернативы, такие как IndexedDB или API для конкретной платформы, предлагают более надёжные решения.

Источник: https://rxdb.info/articles/localstorage.html

День 1893. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 3. Интересы всех сторон пересекаются в требованиях
Успех проекта – это удовлетворение всех требований и соблюдение всех ограничений, определяющих ожидания заинтересованных сторон. Команда разработчиков должна определить заинтересованные стороны и порядок взаимодействия с ними.
Заинтересованная сторона — это любое лицо или группа людей, активно участвующих в проекте, затрагиваемых им или способных влиять на его продвижение. Обычно это команда разработки, клиенты, прямые пользователи, косвенные пользователи, регулирующие органы и т.п.

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

Чтобы упростить исследование требований, разделите пользователей на группы с разными наборами потребностей. Пользователи могут быть даже не людьми, а аппаратными устройствами или другим ПО. Нужно определить людей, которые могут предоставить требования от имени этих компонентов.
Могут быть и непрямые пользователи продукта. Например, получатели годовых отчётов компании не взаимодействуют с ПО напрямую, но они основные заинтересованные стороны. Необходимо также определить классы нежелательных пользователей, которые не должны иметь возможности пользоваться системой. Например, хакеры не являются заинтересованной стороной (не определяют требования или ограничения), но нужно предвидеть и пресекать их злые намерения.

Для каждой группы заинтересованных сторон, опишите:
1. Кто они? Чтобы все участники проекта понимали, кто это.
2. Насколько они заинтересованы? Как сильно результат проекта повлияет на группу и как их желание участвовать в проекте. Их ожидания, интересы, опасения и ограничения.
3. Какое влияние на проект они имеют? Какие решения могут и не могут принимать. Кто влияет больше всего? Особое внимание группам, которые проявляют наибольший интерес и оказывают наибольшее влияние.
4. С кем лучше говорить? Представители каждой группы, с которыми нужно работать. Они должны быть авторитетными источниками информации.
5. Где они? Проще получить информацию, если есть прямой доступ к представителям группы. Либо продумайте процесс коммуникации.
6. Что нам нужно от них? Информация, решения и данные, которые понадобятся получить от каждой группы. Некоторые группы будут накладывать ограничения на проект, например:
- финансовые, временные и ресурсные;
- применимые политики, нормы и стандарты (бизнес-правила);
- совместимость с другими продуктами, системами или интерфейсами;
- юридические или договорные;
- требования к сертификации;
- ограничения возможностей продукта (что не должно включаться в продукт).
7. Что им нужно от нас? Одних нужно проинформировать о проблемах, другим может понадобиться пересмотреть требования.
8. Как и когда с ними взаимодействовать?
9. Какие стороны наиболее важны при разрешении конфликтов? При разрешении противоречий и принятии важных решений оцените, какой результат больше всего соответствует целям проекта. Проанализируйте влияние и интересы сторон, не ждите, пока назреет первый конфликт.

Мы все на одной стороне
Определите лиц, принимающих решения. Иногда это один человек (спонсор или владелец продукта). Чаще придётся определять правильные группы людей для принятия решений из разных областей. Групповые решения требуют больше времени, но лучше отражают все интересы, соответствующие целям проекта. Цели, ограничения и другие бизнес-требования обычно оформляются в виде заявления о видении.

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.

День 1894. #Карьера #Продуктивность
Начинайте Работу Через Минуту После Пробуждения
Ваша утренняя рутина, скорее всего ужасна. Вы либо делаете одно и то же, чтобы проснуться и подготовиться к работе: принимаете контрастный душ, пьёте кофе, делаете зарядку и т.п., и не начинаете работу до 10-11 часов. Либо наоборот, вы откладываете будильник до последнего, а потом в спешке бежите на работу. Или пропускаете её вовсе, потому что легли поздно, и утром не хочется ничего делать.

Однако наиболее продуктивные люди в мире ничего такого не делают. Они просто просыпаются и начинают работать. Поначалу это может показаться странным и трудным – работать не до конца проснувшись. Но на самом деле это самое продуктивное время дня. Психолог Михай Чиксентмихайи в 1970х назвал это склонностью к потоку (flow proneness) – это настрой организма к работе в потоке.

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

Но дело в том, что, когда вы просыпаетесь, ваша склонность к потоку наиболее высока по естественным причинам:
1) Низкая когнитивная нагрузка. Вы только проснулись, мозг ещё не нагружен новой информацией.
2) Активность мозга после пробуждения близка к состоянию потока. После сна он готов воспринимать новую информацию.
Поэтому занимать это время утренней рутиной, которая призвана помочь войти в поток позже, не имеет смысла.

Наиболее продуктивные люди приступают к самым важным задачам сразу после пробуждения. Проблема в том, что погружаться в работу сразу и на весь день - прямой путь к выгоранию. Если вы привыкли испытывать состояние расслабленности от медитации, зарядки или йоги, вам будет этого не хватать.

Дело в том, что состояние потока не бинарное, его нельзя включить и не выключать или выключать по желанию. Это цикл. Состояние потока требует восстановления. То есть нам нужно нечто посередине: и использовать самые продуктивные часы после пробуждения, и восстанавливаться, занимаясь утренней рутиной.

Проснитесь, и сразу приступайте к самой важной работе. Не через час, не через 10-15 минут, а в течение 60-90 секунд, пока вы ещё наполовину спите. В течение нескольких минут вы полностью проснётесь и будете работать в состоянии потока. Поработайте так 1-3 часа. После этого займитесь тем, что обычно поднимает вам настроение с утра и позволяет подготовиться к рабочему дню: чашка кофе, контрастный душ, йога, прогулка. Воспринимайте это как утреннюю рутину наоборот: сначала поработать, потом восстановиться. Так мы используем самое продуктивное время после пробуждения, данное нам природой, и восстанавливаемся после этого, чтобы зарядиться энергией на оставшийся день.

И ещё два совета.
1) Подготовьтесь заранее. Составьте подробный список дел накануне вечером. Так, чтобы с утра не думать, что надо делать, а сразу приступать к делу.
2) Выделите достаточно времени. 1-3 часа на активную работу в состоянии потока, не отвлекаясь.

Попробуйте начать завтра. Сегодня составьте список самых важных день на завтра, а как проснётесь (в идеале, в течение 60-90 секунд), принимайтесь за работу. После этого позвольте себе восстановиться и перезагрузиться, чтобы настроиться на продуктивную работу в оставшееся время дня.

Источник: https://youtu.be/XJOsPyyYork

День 1895.
Сопоставление с Образцом и Компилятор Могут Удивлять
Сопоставление с образцом — мощная функция C#. Она позволяет сопоставлять значение с шаблоном и извлекать информацию из значения. Компилятор творит за вас волшебство, но иногда этим и поражает.

Вот такой фрагмент кода рассылки писем:

Console.WriteLine(
  GetHashCode(new PostCard { Subject = "Test" }));

static int GetHashCode(Document doc)
{
  return doc switch
  {
    PostCard { Subject: { } s, Text: { } t }
     => HashCode.Combine(s, t),
    Mail { Subject: { } s }
     => s.GetHashCode(),
    _ => 0,
  };
}

public class Document;
public class Mail : Document
{
  public string? Subject { get; set; }
}
public class PostCard : Mail
{
  public string? Text { get; set; }
}

Функция GetHashCode принимает Document и возвращает хэш-код. Она использует сопоставление с образцом для сопоставления типа и получения хэш-кода. Интересная часть PostCard { Subject: { } s, Text: { } t } по сути гарантирует, что Subject и Text не null. Второе условие проверяет только базовый тип (мы идём от более конкретного к более общему). В чём тут сюрприз? В том, что код выдаёт предупреждение:
Program.cs(11,9): Warning CS8602 : Dereference of a possibly null reference (Разыменование возможно нулевой ссылки).
Вот в этом месте

Mail { Subject: { } s }
  => s.GetHashCode(),

Учитывая, что мы явно проверяем, что Subject не null, почему компилятор на это жалуется? Для этого нам нужно взглянуть на сгенерированный компилятором код:

internal static GetHashCode(Document doc)
{
  PostCard postCard = doc as PostCard;
  string subject2;
  if (postCard != null)
  {
    string subject = postCard.Subject;
    if (subject != null)
    {
      string text = postCard.Text;
      if (text == null)
      {
        Mail mail = (Mail)doc;
        subject2 = mail.Subject;
        goto IL_0057;
      }
      return HashCode.Combine(subject, text);
    }
  }
  else
  {
    Mail mail = doc as Mail;
    if (mail != null)
    {
      subject2 = mail.Subject;
      if (subject2 != null)
      {
        goto IL_0057;
      }
    }
  }
  return 0;
IL_0057:
  return subject2.GetHashCode();
}

Кажется, статический анализатор видит проблему в операторе goto в ветке PostCard. Заметьте, что subject проверяется на null, a subject2 нет.

Так что, если в вашем коде есть именно такой шаблон, возможно, вам стоит об этом знать. Оговорюсь, что случаи, когда этот код фактически выдаст исключение NullReferenceException – крайне редкие. Вот такой вымышленный пример:

public class Mail : Document
{
  private string? subject;
  public string? Subject
  {
    get
    {
      Console.WriteLine("Вызвали get");
      var r = subject;
      subject = null;
      return r;
    }
    set => subject= value;
  }
}

В этом случае при вызове

Console.WriteLine(
  GetHashCode(new PostCard { Subject = "Test" }));

аксессор get свойства Mail.Subject будет вызван дважды:
1) в строке string subject = postCard.Subject;
2) в строке subject2 = mail.Subject;
И из-за нашего специального кода get выше, во втором случае get выдаст null, поэтому return subject2.GetHashCode(); выбросит NullReferenceException. Выполнив этот код, вы увидите «Вызвали get» в консоли дважды перед исключением.

Источник: https://steven-giesel.com/blogPost/9892bd03-96bf-4ab0-aacc-973a99d5f5e0/pattern-matching-and-the-compiler-can-be-surprising

День 1896. #Оффтоп #Безопасность
Бэкдор в SSH Linux
«Linux безопасен», - говорили они. «В Linux нет вирусов», - говорили они.

Зато туда едва не проник бэкдор, который мог позволить его автору получать root доступ к любой (!!!) машине под управлением Linux и в которой была установлена нужная версия библиотеки XZ Utils. Причём сделал это один из её главных контрибуторов и довольно хитро - в make-файле (которые обычно никто досконально не проверяет). Бэкдор активировался при сборке проекта. Насколько я понял, достаточно было добавить малозаметную точку в файл в очередном релизе, чтобы сборка «выбрасывала ошибку» при поиске одной из нужных библиотек, и вместо неё использовала «стандартную» с уязвимостью. После этого оставалось только ждать, пока все серверы обновят версию библиотеки и…

По иронии судьбы обнаружил это парень из Microsoft. Он заметил, что его входы в систему стали занимать дольше обычного (2,5 секунды против 2х раньше), и стал копать. Из-за этой счастливой случайности уязвимость не успела распространиться далее нескольких превью версий.

Национальная база данных уязвимостей США присвоила этой уязвимости критичность 10 из 10.

Больше подробностей об этом, а также чем процесс релиза кода в Microsoft отличается от процесса в «диком опенсорсе» смотрите в видео Dave’s Garage.