День 1906. #ЗаметкиНаПолях 8 Способов Задать URL в Приложении ASP.NET Core. Окончание
Начало
Способы 1-3
Способы 4-6
Способ 7

8. KestrelServerOptions.Listen()
Kestrel настроен по умолчанию в большинстве приложений ASP.NET Core. При желании вы можете настроить конечные точки для Kestrel, если вам требуется тонкая настройка, например, сертификатов HTTPS, протоколов SSL/TLS и комбинаций шифров, а также конфигураций SNI. Доступно множество вариантов конфигурации (см. документацию).

Например, вы можете использовать функции Listen(), предоставляемые KestrelServerOptions, следующим образом:

```
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(opts =>
{
opts.Listen(IPAddress.Loopback, port: 5002);
opts.ListenAnyIP(5003);
opts.ListenLocalhost(5004,
listenOptions => listenOptions.UseHttps());
opts.ListenAnyIP(5005,
listenOptions =>
{
listenOptions.UseHttps("testCert.pfx", "testPassword");
});
});

var app = builder.Build();
…
```

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

Но и конфигурацию Kestrel можно привязать с помощью IConfiguration, аналогично urls или http_ports. Например, приведенную выше конфигурацию Kestrel можно настроить в appsettings.json:

{ "Kestrel": { "Endpoints": { "HttpLoopback": { "Url": "http://localhost:5002" }, "HttpAny": { "Url": "http://*:5003" }, "HttpsDefaultCert": { "Url": "https://localhost:5004" }, "HttpsInlineCertFile": { "Url": "https://*:5005", "Certificate": { "Path": "testCert.pfx", "Password": "testPassword" } } } } }

Это позволяет полностью настроить привязку вашего приложения и конфигурацию сертификата HTTPS из IConfiguration. Т.е. вы можете воспользоваться безопасным секретным хранилищем, например Key Vault, для хранения сертификатов и паролей сертификатов.
Если вы используете конфигурацию appsettings.json, указанную выше, не нужно вызывать ConfigureKestrel().

Источник: https://andrewlock.net/8-ways-to-set-the-urls-for-an-aspnetcore-app/

День 1905. #ЗаметкиНаПолях 8 Способов Задать URL в Приложении ASP.NET Core. Продолжение
Начало
Способы 1-3
Способы 4-6

7. launchSettings.json
Помимо файла appsettings.json, большинство шаблонов проектов .NET также включают файл launchSettings.json в папке Properties. Этот файл не добавляет значений в конфигурацию, а содержит различные профили для запуска разрабатываемого приложения в dotnet run. Он управляет выпадающим списком отладки в Visual Studio.

Типичный файл содержит определения для запуска профиля из командной строки и из IIS Express:

{ … "iisSettings": { … "iisExpress": { // URL для профиля IIS Express "applicationUrl": "http://localhost:49412", "sslPort": 44381 } }, "profiles": { // профиль только HTTP "http": { "commandName": "Project", "dotnetRunMessages": true, "launchBrowser": true, "applicationUrl": "http://localhost:5005", "environmentVariables": { "ASPNETCORE\_ENVIRONMENT": "Development" } }, // профиль HTTP и HTTPS "https": { // аналогично "http" … }, "IIS Express": { "commandName": "IISExpress", "launchBrowser": true, "environmentVariables": { "ASPNETCORE\_ENVIRONMENT": "Development" } } } }

Как видите, launchSettings.json также предоставляет простой способ установки дополнительных переменных окружения в environmentVariables.
Когда вы запускаете приложение из командной строки с помощью dotnet run, оно будет использовать свойства applicationUrl из команды Project: http://localhost:5005 в профиле http выше. В IISExpress - будет использовать applicationUrl из узла iisSettings.iisExpress: http://localhost:49412.

Этот файл — самый простой способ настроить среду при локальной разработке. Чтобы запустить приложение без использования launchSettings.json, нужно добавить параметр:

dotnet run \-\-no\-launch\-profile

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

Источник:* https://andrewlock.net/8-ways-to-set-the-urls-for-an-aspnetcore-app/

День 1904. #ЗаметкиНаПолях 8 Способов Задать URL в Приложении ASP.NET Core. Продолжение
Начало
Способы 1-3

4. Переменные окружения
ASP.NET Core добавляет в систему конфигурации всё нижеследующее:
- Все переменные окружения.
- Переменные с префиксом DOTNET_ (без префикса).
- В приложениях ASP.NET Core (кроме сервисов, созданных через HostApplicationBuilder) переменные с префиксом ASPNETCORE_ (без префикса).
Таким образом, можно задать любой вариант переменной окружения для URL: URLS, ASPNETCORE_URLS или DOTNET_URLS.

Вы можете установить переменные окружения обычным способом в зависимости от вашей среды:

setx ASPNETCORE\_URLS "http://localhost:5001"

PowerShell:

$Env:ASPNETCORE\_URLS="http://localhost:5001"

Bash:

export ASPNETCORE\_URLS="http://localhost:5001;https://localhost:5002"

Можно передавать несколько адресов (для HTTP и HTTPS), разделяя их точкой с запятой.

5. Переменные окружения для портов
В .NET 8 добавлены новые ключи конфигурации. Вместо указания URL вы указываете HTTP_PORTS и HTTPS_PORTS, и они используются для привязки любого IP-адреса. Можно указать несколько портов, используя точку с запятой. Например, следующие переменные окружения:

HTTP\_PORTS=5001;5002 HTTPS\_PORTS=5003

Соответствуют привязке следующих URL:

http://*:5001 http://*:5002 https://*:5003

Точно так же можно использовать префиксы ASPNETCORE_ и DOTNET_.

Замечание: если вы добавите значения и для PORTS, и для URLS, URLS будет иметь приоритет, и будет записано предупреждение:
warn: Microsoft.AspNetCore.Hosting.Diagnostics[15]
Overriding HTTP_PORTS '5002' and HTTPS_PORTS ''. Binding to values defined by URLS instead 'http://:5003'.*

В образах докера с .NET 8 переменная ASPNETCORE_HTTP_PORTS по умолчанию установлена в 8080 (в предыдущих версиях была ASPNETCORE_URLS).

6. appsettings.json
appsettings.json и файлы appsettings.<Environment>.json, специфичные для среды, включены практически в каждый шаблон приложения .NET и предоставляют простой способ добавления значений в систему конфигурации ASP.NET Core.

Используем те же самые ключи urls:

{ "urls": "http://*:5003", … }

или http_ports и https_ports:

{ "http\_ports": "5001;5002", "https\_ports": "5003", … }

Если вы хотите использовать разные порты при разработке и в производстве, можно использовать appsettings.json в производстве и appsettings.Development.json для разработки.

*Продолжение следует…

Источник:* https://andrewlock.net/8-ways-to-set-the-urls-for-an-aspnetcore-app/

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