День 1981. #ProjectManagement Настоящий 10х-Разработчик Делает Всю Команду Лучше
Все знакомы с концепцией 10х-инженера: «занудного, асоциального гения, который создаёт новаторские продукты почти случайно». Суперразработчик, который в десять раз умнее и продуктивнее своих коллег, о котором ходят мифы и на которого идут венчурные инвесторы.

Истина в том, что отдельные люди имеют меньшее значение для успеха или провала проекта, чем вы думаете (и это хорошо, иначе уровень выгорания будет зашкаливать). Гораздо важнее качество сообществ обучения, к которым имеют доступ ваши сотрудники. Вместо инженера, который на порядок «лучше» своих коллег, лидеры должны искать людей, которые хотят и способны учиться, а также помогать всей команде учиться и работать.

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

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

Это требует времени и энергии сотрудников. Не отвлекает ли это их от основных должностных обязанностей?

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

Вот некоторые конкретные способы, с помощью которых разработчики (и их менеджеры) могут построить культуру общего обучения:
- Если вы менеджер или старший сотрудник, подавайте пример, уделяя приоритетное внимание собственному обучению. Как бы вы ни были заняты, старайтесь уделять регулярное время изучению и отработке новых навыков. Сообщайте подчинённым, что вы делали и что вы узнали, чтобы они осознали, что постоянное обучение приветствуется в организации.
- Убедитесь, что сотрудники уделяют время обучению. Предоставьте командам возможность выделять время для обучения. Иначе им придётся посвящать личное время обучению, а не делать обучение неотъемлемой частью вашей организационной культуры и повседневной работы.
- Делитесь ошибками с коллегами. Любая ошибка — это возможность учиться — не только для того, кто допустил ошибку, но и для остальных участников проекта. А когда старшие разработчики и менеджеры бесстрашно признают свои ошибки, перспектива становится менее пугающей для младших разработчиков.
- Предоставьте учебные ресурсы. Это ключ к развитию культуры обучения.

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

Источник: https://stackoverflow.blog/2024/06/19/the-real-10x-developer-makes-their-whole-team-better/

День 1980. #ЗаметкиНаПолях ReadOnly-Коллекция не Является Неизменяемой
Коллекция «только для чтения» не означает, что она не изменяема. Сегодня посмотрим, как можно изменить ReadOnlyCollection.

ReadOnlyCollection, которая существует со времен .NET Framework 2.0, — это хороший способ сообщить: «Вот коллекция, которую вы не можете изменить». С точки зрения реализации это всего лишь оболочка поверх коллекции, которая запрещает такие операции, как добавление, удаление или очистку. Но это не означает, что её элементы не могут изменяться.

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

```
var numbers = new List { 1, 2 };
var asReadOnly = numbers.AsReadOnly();
var readOnly = new ReadOnlyCollection(numbers);

Console.WriteLine($"List: {numbers.Count}");
Console.WriteLine($"AsReadOnly: {asReadOnly.Count}");
Console.WriteLine($"ReadOnly: {readOnly.Count}");
```

Вывод довольно очевиден:

List: 2 AsReadOnly: 2 ReadOnly: 2

Но что, если мы добавим элемент в исходный список?

numbers.Add(3);

Получим:

List: 3 AsReadOnly: 3 ReadOnly: 3

Как и представление в базе данных, наше представление списка «только для чтения» обновляется. Это плохо? Нет, потому что имеет некоторые преимущества. Самое главное - базовая операция по созданию ReadOnlyCollection очень дёшева. Она занимает O(1) времени, поскольку аллокации памяти не требуется.

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

```
var immutable = numbers.ToImmutableList();
Console.WriteLine($"List: {numbers.Count}");
Console.WriteLine($"Immutable: {immutable.Count}");

numbers.Add(4);

Console.WriteLine($"List: {numbers.Count}");
Console.WriteLine($"Immutable: {immutable.Count}");
```

Вывод:

List: 3 Immutable: 3 List: 4 Immutable: 3

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

Итого
ReadOnly-коллекции не являются неизменяемыми. Это просто представление коллекции, доступное только для чтения. Вы как потребитель не можете их изменить, но это не значит, что изначальный создатель/владелец списка не может этого сделать. Если вам действительно нужно текущее состояние, которое не может измениться, используйте ImmutableArray/ImmutableList или Frozen-коллекции.

Источник: https://steven-giesel.com/blogPost/c20eb758-a611-4f98-9ddf-b9e2b83fcac9/readonlycollection-is-not-an-immutable-collection

День 1979. #ЧтоНовенького Новинки ASP.NET Core 9 Preview 5Недавно Microsoft выпустили 5й превью .NET 9, добавив значительные улучшения в ASP.NET Core.

1. MapStaticAssets
Основным улучшением в этом выпуске является оптимизация доставки статических веб-ресурсов. Новый API MapStaticAssets предназначен для замены UseStaticFiles в большинстве случаев (кроме обслуживания внешних ресурсов). MapStaticAssets оптимизирован для ресурсов, известных на момент сборки и публикации. Он сжимает ресурсы с помощью gzip и brotli, уменьшая их размер и ускоряя время загрузки для пользователей.
MapStaticAssets также настраивает заголовки ETag на основе содержимого, гарантируя, что браузер загружает файлы только в случае изменения их содержимого. Это упрощает процесс для разработчиков, поскольку новые библиотеки или ресурсы JS/CSS автоматически оптимизируются и обслуживаются быстрее, что особенно полезно для мобильных пользователей с ограниченной пропускной способностью.
Утверждается, что даже приложения, использующие сжатие на стороне сервера, могут извлечь выгоду из MapStaticAssets, поскольку он допускает более высокие степени сжатия, замедляя при этом процесс сборки. Однако использование сжатия Brotli может уменьшить, например, bootstrap.min.css со 163КБ до 17,5КБ.

2. Повторные подключения к серверу в Blazor
Для работы серверных приложений Blazor требуется подключение в режиме реального времени. Новые изменения вводят экспоненциальную стратегию отсрочки попыток повторного подключения:
- Когда пользователь возвращается к приложению с отключенным каналом, попытка повторного подключения выполняется немедленно. Это улучшает взаимодействие с пользователем при возвращении к приложению на вкладке браузера, которая перешла в спящий режим.
- Если попытка повторного подключения достигает сервера, но сервер уже разорвал канал, обновление страницы происходит автоматически. Это избавляет пользователя от необходимости вручную обновлять страницу.
- По умолчанию первые несколько попыток повторного подключения происходят быстро друг за другом, прежде чем между попытками вводятся задержки. Размер задержек можно настраивать.
- Также улучшен UI повторных подключений.

3. Определение режима рендеринга компонента во время выполнения
Класс ComponentBase теперь включает свойство Platform, которое вскоре будет переименовано в RendererInfo, со свойствами Name и IsInteractive. Эти свойства помогают разработчикам понять, где работает их компонент и является ли он интерактивным. Новое свойство AssignedRenderMode также предоставляет информацию о том, как компонент будет отображаться после пререндеринга.

4. Упрощена сериализация состояния аутентификации в Blazor
Если вы начали с шаблона проекта веб-приложения Blazor и выбрали параметр «Индивидуальные учетные записи», всё работает хорошо. Но требуется написать много кода, если вы пытаетесь добавить аутентификацию в существующий проект. Новые API, AddAuthenticationStateSerialization и AddAuthenticationStateDeserialization, упрощают этот процесс, добавляя необходимые сервисы для сериализации и десериализации состояния аутентификации и расширяя возможности приложения для доступа к состоянию аутентификации.

5. Шаблон приложения .NET MAUI Blazor
Этот шаблон упрощает создание приложений, предназначенных для Android, iOS, Mac, Windows и Интернета, одновременно обеспечивая максимальное повторное использование кода.
Ключевые особенности шаблона:
- Возможность выбрать режим интерактивного рендеринга Blazor для веб-приложения.
- Автоматическое создание соответствующих проектов, включая веб-приложение Blazor и гибридное приложение .NET MAUI Blazor.
- Созданные проекты используют общую библиотеку классов Razor (RCL) для поддержки компонентов пользовательского интерфейса Razor.
- Включен пример кода, который демонстрирует, как использовать внедрение зависимостей для предоставления различных реализаций интерфейса для гибридного приложения Blazor и веб-приложения Blazor.

Источники:
- https://www.infoq.com/news/2024/06/asp-net-core-9-preview5/ - https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-9.0

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

Урок 6. Agile-требования не отличаются от других. Начало
Многие компании, занимающиеся разработкой ПО, используют методы Agile. Бизнес-аналитики и владельцы продуктов иногда применяют термин «Agile-требования». Но они не отличаются от требований в проектах с другим подходом.

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

1. Роли и обязанности
В состав большинства традиционных проектных групп входит один или несколько бизнес-аналитиков, которые отвечают за работу по выявлению требований к проекту, анализу, спецификации, проверке и управлению или возглавляют её. Во многих Agile-проектах отсутствует официальная должность бизнес-аналитика. Разработка требований — совместный процесс, в котором участвуют владелец продукта, представители пользователей и другие заинтересованные стороны. Но за полноту информации в историях ответственность несут разработчики, а не бизнес-аналитики.

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

3. Детальность документации
Agile-методы полагаются на доступность документации в нужный момент. Благодаря тесному сотрудничеству клиентов с разработчиками в Agile-проектах требования могут содержать меньше деталей, чем в традиционных проектах. Заинтересованные стороны могут сообщить все необходимые детали, когда это действительно потребуется, на встречах и в соответствующей документации. Некоторые пользовательские истории могут содержать мало подробностей, а сложные или важные функции могут прорабатываться более детально. Но не стоит чрезмерно полагаться только на устное общение. Каждой проектной группе необходимо создать достаточный объём документации, позволяющей решать задачи поддержки и совершенствования системы, но при этом не тратить время на запись информации, которую никто не будет использовать.

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

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

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

День 1912. #ЗаметкиНаПолях Реализуем Пессимистическую Блокировку в EF Core. Окончание
Начало

Варианты блокировки и когда их использовать
Чтобы операция не ждала, пока другие транзакции освободят заблокированные строки, вы можете объединить FOR UPDATE с:
- NO WAIT — вместо ожидания снятия блокировки, сообщает об ошибке, если строку невозможно заблокировать.
- SKIP LOCKED — пропускает любые выбранные строки, которые нельзя заблокировать. Заметьте, что в этом случае вы будете получать противоречивые результаты из БД. Однако это может быть полезно, чтобы избежать конфликта блокировок, когда несколько потребителей обращаются к таблице, похожей на очередь. Реализация паттерна Outbox является отличным примером.

В SQL Server для аналогичного эффекта можно использовать подсказку запроса WITH (UPDLOCK, READPAST). Однако SQL Server блокирует все строки, которые ему необходимо прочитать, чтобы получить нужную. Таким образом, если не определить индекс для прямого доступа к строке, все предшествующие строки будут заблокированы. Допустим, есть таблица TBL с полем id. Вы хотите заблокировать строку с id=10. Необходимо определить индекс для id (или других полей, по которым выбираете):

CREATE INDEX TBLINDEX ON TBL ( id );

А затем запросить блокировку только тех нужных строк:

SELECT * FROM TBL WITH (UPDLOCK, INDEX(TBLINDEX)) WHERE id=10;

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

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

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

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

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

Итого
И сериализуемые транзакции, и пессимистическая блокировка с помощью SELECT FOR UPDATE — отличные варианты обеспечения согласованности данных. При выборе учитывайте требуемый уровень изоляции, потенциальное влияние на производительность и вероятность взаимоблокировок.

Источник: https://www.milanjovanovic.tech/blog/a-clever-way-to-implement-pessimistic-locking-in-ef-core

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