День 1900. #ЗаметкиНаПолях Добавляем Деконструктор в Сторонние ТипыДеконструктор — это функция языка C#, позволяющая определить метод, который будет вызываться при разделении объекта на компоненты. Это легко реализовать для ваших собственных типов, но можно добавить и для сторонних типов.

Например:

```
public class Point
{
public int X { get; }
public int Y { get; }

public Point(int x, int y)
{
X = x;
Y = y;
}

public void Deconstruct(out int x, out int y)
{
x = X;
y = Y;
}
}

// Использование
var point = new Point(3, 4);
var (x, y) = point;
```

Красиво и просто, но ваш класс должен определить метод Deconstruct. Что делать, если вы хотите деконструировать сторонний тип, который вы не можете изменить? Компилятор будет искать метод с сигнатурой Deconstruct в типе, который вы пытаетесь деконструировать, но он также будет искать и метод расширения с той же сигнатурой. Т.е. можно определить деконструктор для стороннего типа, определив метод расширения с той же сигнатурой:

```
public static class Extensions
{
public static void Deconstruct(
this Uri uri,
out string scheme,
out string host,
out string path,
out string query,
out string fragment)
{
scheme = uri.Scheme;
host = uri.Host;
path = uri.AbsolutePath;
query = uri.Query;
fragment = uri.Fragment;
}
}

// Использование
var url =
"https://www.google.com/search?q=dotnet#ip=1";
var (scheme, host, path, query, fragment)
= new Uri(url);

Console.WriteLine($"Scheme: {scheme}"); // https
Console.WriteLine($"Host: {host}"); // google.com
Console.WriteLine($"Path: {path}"); // /search
Console.WriteLine($"Query: {query}"); // ?q=dotnet
Console.WriteLine($"Fragment: {fragment}"); // #ip=1
```

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

Источник: https://steven-giesel.com/blogPost/0775d3d3-8f90-4546-95d8-71a6b1e7b0e8/equip-3rd-party-types-with-a-deconstructor

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

Урок 4. В требованиях главное особенности использования, а затем — функциональность
В индустрии ПО существует убеждение, что от 50 до 80% возможностей ПО используются редко или не используются никогда.

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

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

Меняется суть вопросов во время сбора информации. Вместо «Что вы хотите?» или «Что должна делать система?» можно спросить: «Как предполагается использовать систему?» Редкие пользователи запускают приложение ради определённой функции; подавляющее большинство стремится достичь конкретной цели. Я открываю приложение, имея определённое намерение, и выполняю последовательность шагов, вызывая функции, необходимые для решения задачи. Если всё хорошо, то я успешно решаю свою задачу и закрываю приложение.

Преимущества вариантов использования
1. Помогают пользователям задуматься о своих потребностях. Им сложно правильно сформулировать перечень функций продукта, но они легко расскажут о сценариях использования из своей жизни. По этим описаниям можно определить, какие функции должно предоставить приложение, чтобы пользователи могли решать поставленные задачи. Также учитывайте, какие ошибки могут возникнуть и как система должна их обрабатывать.
2. Помогают расставить приоритеты. Одни варианты использования будут более важными, поэтому должны быть реализованы в первую очередь. Наивысший приоритет имеет нормальный сценарий вместе с возможными нештатными ситуациями. Альтернативные сценарии имеют более низкий приоритет, их реализацию часто откладывают или отменяют вообще.
3. Более продуктивное взаимодействие с пользователем и более полное представление об ограничениях реализации, которое труднее получить, при разговоре о функциональности продукта.

Проблема пользовательских историй
Пользовательская история (user story) описывает функциональность, которая будет полезна как пользователю, так и покупателю системы. Они обычно записываются с использованием простого шаблона:

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

или

Как <тип пользователя>, я хочу достичь <некая цель>, чтобы <некий результат>.

Одна из проблем пользовательских историй в том, что они не имеют внутренней организационной схемы. Множество историй, даже записанных по шаблону, мало чем отличается от вопроса: «Чего вы хотите?» Вы получаете много кусочков важной информации, перемешанных с посторонними сведениями. Требуется, чтобы кто-то отсортировал их и выявил темы, связанные с пользовательскими задачами.

Альтернативой является шаблон истории работы (job story), который ёмко и структурированно описывает потребность:

Когда <ситуация>, я хочу выполнить <задачу>, чтобы я достичь <желаемый результат>.

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

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

День 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

День 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: 'alice@example.com'
};

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

День 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>

</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

День 1883. #МоиИнструменты Назначенные Задания с NCronJobHangfire/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);

}
}
```

Как видите, поддерживаются параметры. Это справедливо как для заданий, запускаемых через 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

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

Урок 1. Если вы неверно определили требования, неважно, как хорошо вы выполните остальную часть работы
IT-отдел взялся за создание новой информационной системы для своей компании. Разработчики считали, что прекрасно понимают требования и без опроса пользователей. Однако реакция пользователей на готовую систему была: «А если серьезно, где наше приложение?» Они категорически забраковали систему. Отказ от взаимодействия с пользователями, которое помогает убедиться в правильном понимании требований, был серьёзным упущением. Разработчики в итоге переделали систему, на этот раз внимательно прислушиваясь к пользователям. Это был дорогой урок о важности участия клиента в составлении требований.

Требования — это фундамент для всей последующей работы над проектом. Многочисленные исследования показали, что эффективная разработка и своевременное информирование о требованиях являются решающими факторами успеха любого проекта. И наоборот, неадекватное ви́дение проекта, неполные и неточные требования, а также меняющиеся требования и цели проекта — частые причины неудачи. При отсутствии качественной проработки требований заинтересованные стороны могут удивиться тому, что предлагает команда разработчиков. Такие программные сюрпризы часто оказываются неприятными.

Когда?
Нереально иметь полный набор требований перед началом реализации. Всегда будут появляться новые идеи, изменения и исправления, которые вы должны учитывать в своих планах развития. Но для любой части системы, которую вы создаёте, необходимо иметь как можно более полные и правильные требования. Либо планируйте доработку после окончания реализации. В проектах, практикующих Agile, предусмотрен дополнительный этап проверки требований. Чем дальше первоначальные требования от того, что действительно нужно клиентам, тем больше доработок понадобится. Учитывая, что всегда можно что-то добавить, вы никогда не сможете идеально выполнить требования. Но оговорённый объём разработки требует, чтобы вы сделали всё правильно, иначе успеха не видать.

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

Как?
Ничто не заменит постоянного взаимодействия с клиентами. Нельзя просто провести встречу в самом начале, а затем сказать клиентам: «Мы позвоним вам, когда закончим». В идеале команда должна быть на связи с представителями клиентов на протяжении всего времени разработки проекта. У разработчиков будет много вопросов и моментов, требующих уточнения.

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

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

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

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