День 2308. #ЧтоНовенького
Вышла Новая Версия Dev Proxy
Вышел Dev Proxy версии 0.27. В этой версии улучшили опыт разработчиков с помощью нескольких новых функций, упростили генерацию спецификаций API, улучшили предложения по редактированию и заложили основу для будущих интеграций с AI.
Dev Proxy, ранее называвшийся Microsoft 365 Developer Proxy, - это инструмент командной строки, используемый для имитации поведения API во время тестирования приложений. С помощью Dev Proxy разработчики могут создавать устойчивые приложения, умеющие управлять ошибками и ограничениями. См. подробнее про Dev Proxy.
Одной из ключевых функций в этой версии - возможность генерировать определения TypeSpec из перехваченных запросов. TypeSpec — это новый метод моделирования API и генерации кода в различных экосистемах. Это обновление позволяет Dev Proxy быстро создавать определения TypeSpec из реального трафика, что упрощает и ускоряет моделирование API. Подобно созданию спецификаций OpenAPI, разработчики теперь могут использовать эту функцию для ускорения своей работы.
Ещё одним заметным дополнением является экспериментальный сервер Dev Proxy MCP. Он позволяет пользователям настраивать Dev Proxy с помощью естественного языка, предоставляя контекстную помощь и помогая пользователям находить и понимать функции Dev Proxy. Интеграция сервера Model Context Protocol (MCP) с агентами ИИ направлена на упрощение процесса настройки, позволяя пользователям работать с платформой более интуитивно. Однако эта функция в настоящее время доступна в экспериментальной версии для инсайдеров Visual Studio Code с более широкой доступностью через npm.
Обновление также включает значительные улучшения локального соединения с языковой моделью Dev Proxy. Команда разработчиков заявляет следующее:
«Мы реорганизовали локальное соединение с языковой моделью, сделав его универсальным. Ранее логика соединения была тесно связана с Ollama. В этом обновлении мы вводим поддержку подключения Dev Proxy к любому клиенту языковой модели, который предоставляет API, совместимые с OpenAI, что упрощает подключение к поставщикам ИИ, которые вы предпочитаете.»
Кроме того, схемы JSON Dev Proxy были улучшены описаниями и поддержкой markdown. Это изменение упрощает разработчикам понимание и настройку свойств в конфигурации Dev Proxy, особенно при работе в Visual Studio Code.
Прочие обновления улучшают перехват URL-адресов и перезагрузку моков при внесении изменений. Предыдущая проблема с производительностью, когда файлы моков перезагружались несколько раз, была устранена. Обновление также уточняет определение URL-адресов для включения и исключения, улучшая общую обработку моков.
Расширение Dev Proxy Toolkit для Visual Studio Code также было обновлено, в него добавлены новые команды для создания файлов конфигурации и перезапуска Dev Proxy, а также обновлённые фрагменты кода, которые теперь включают последнюю схему и конфигурации TypeSpecGeneratorPlugin.
Полный список изменений в этой версии доступен тут.
Источник: https://www.infoq.com/news/2025/05/microsoft-dev-proxy-0-27/
Вышла Новая Версия Dev Proxy
Вышел Dev Proxy версии 0.27. В этой версии улучшили опыт разработчиков с помощью нескольких новых функций, упростили генерацию спецификаций API, улучшили предложения по редактированию и заложили основу для будущих интеграций с AI.
Dev Proxy, ранее называвшийся Microsoft 365 Developer Proxy, - это инструмент командной строки, используемый для имитации поведения API во время тестирования приложений. С помощью Dev Proxy разработчики могут создавать устойчивые приложения, умеющие управлять ошибками и ограничениями. См. подробнее про Dev Proxy.
Одной из ключевых функций в этой версии - возможность генерировать определения TypeSpec из перехваченных запросов. TypeSpec — это новый метод моделирования API и генерации кода в различных экосистемах. Это обновление позволяет Dev Proxy быстро создавать определения TypeSpec из реального трафика, что упрощает и ускоряет моделирование API. Подобно созданию спецификаций OpenAPI, разработчики теперь могут использовать эту функцию для ускорения своей работы.
Ещё одним заметным дополнением является экспериментальный сервер Dev Proxy MCP. Он позволяет пользователям настраивать Dev Proxy с помощью естественного языка, предоставляя контекстную помощь и помогая пользователям находить и понимать функции Dev Proxy. Интеграция сервера Model Context Protocol (MCP) с агентами ИИ направлена на упрощение процесса настройки, позволяя пользователям работать с платформой более интуитивно. Однако эта функция в настоящее время доступна в экспериментальной версии для инсайдеров Visual Studio Code с более широкой доступностью через npm.
Обновление также включает значительные улучшения локального соединения с языковой моделью Dev Proxy. Команда разработчиков заявляет следующее:
«Мы реорганизовали локальное соединение с языковой моделью, сделав его универсальным. Ранее логика соединения была тесно связана с Ollama. В этом обновлении мы вводим поддержку подключения Dev Proxy к любому клиенту языковой модели, который предоставляет API, совместимые с OpenAI, что упрощает подключение к поставщикам ИИ, которые вы предпочитаете.»
Кроме того, схемы JSON Dev Proxy были улучшены описаниями и поддержкой markdown. Это изменение упрощает разработчикам понимание и настройку свойств в конфигурации Dev Proxy, особенно при работе в Visual Studio Code.
Прочие обновления улучшают перехват URL-адресов и перезагрузку моков при внесении изменений. Предыдущая проблема с производительностью, когда файлы моков перезагружались несколько раз, была устранена. Обновление также уточняет определение URL-адресов для включения и исключения, улучшая общую обработку моков.
Расширение Dev Proxy Toolkit для Visual Studio Code также было обновлено, в него добавлены новые команды для создания файлов конфигурации и перезапуска Dev Proxy, а также обновлённые фрагменты кода, которые теперь включают последнюю схему и конфигурации TypeSpecGeneratorPlugin.
Полный список изменений в этой версии доступен тут.
Источник: https://www.infoq.com/news/2025/05/microsoft-dev-proxy-0-27/
День 2309. #ЗаметкиНаПолях
Уходим от Анемичных Моделей. Пример DDD-Рефакторинга. Начало
Если вы когда-либо работали с устаревшей кодовой базой C#, вы знаете боль анемичной модели домена. Вы открывали какой-нибудь OrderService и думали: «Этот класс делает всё: логика ценообразования, правила скидок, проверка остатков, запись в БД и т.п.» Это работает… какое-то время. Но новые функции превращаются в регрессионную рулетку, а тестовое покрытие резко падает, потому что доменная логика погребена под инфраструктурной.
Это классический симптом анемичной модели домена, где сущности — это всего лишь держатели данных, а вся логика находится в другом месте. Это затрудняет понимание системы, и каждое изменение превращается в угадайку.
В этой серии мы:
- Изучим типичную анемичную реализацию.
- Определим скрытые бизнес-правила, которые делают её хрупкой.
- Выполним рефакторинг в сторону агрегата с богатым поведением.
- Выделим конкретные выгоды, чтобы вы могли обосновать изменение для членов команды.
Начало: Божественный Класс Сервиса
Ниже приведён (к сожалению, распространённый пример) OrderService. Помимо расчёта итоговых сумм он также:
- применяет скидку VIP 5%,
- выбрасывает исключение, если какой-то товар отсутствует на складе,
- отклоняет заказы, которые превышают кредитный лимит клиента.
Что здесь не так?
1. Разрозненные правила: применение скидок, проверка остатков и проверки кредитного лимита зарыты внутри сервиса.
2. Тесная связь: OrderService должен знать о ценах, запасах и EF Core только для того, чтобы разместить заказ.
3. Болезненное тестирование: каждому модульному тесту нужны моки для доступа к БД, ценообразования, запасов и потоки для VIP и не VIP клиентов.
Наша цель - внедрить эти правила в домен, чтобы прикладной уровень занимался только оркестрацией.
Руководящие принципы
1. Размещаем защитные инварианты близко к данным.
Проверки остатков, скидок и кредита относятся к месту, где находятся данные — внутри агрегата Order.
2. Раскрываем намерение, скрываем механику.
Прикладной уровень должен читаться как история: «разместить заказ», а не «рассчитать итоги, проверить кредит, записать в БД».
3. Выполняем рефакторинг в срезах.
Каждый ход безопасен и компилируется; никаких больших переписываний.
4. Балансируем чистоту с прагматизмом.
Изменяйте правила только тогда, когда выгода (ясность, безопасность, тестируемость) перевешивает дополнительные строки кода.
Продолжение следует…
Источник: https://www.milanjovanovic.tech/blog/from-anemic-models-to-behavior-driven-models-a-practical-ddd-refactor-in-csharp
Уходим от Анемичных Моделей. Пример DDD-Рефакторинга. Начало
Если вы когда-либо работали с устаревшей кодовой базой C#, вы знаете боль анемичной модели домена. Вы открывали какой-нибудь OrderService и думали: «Этот класс делает всё: логика ценообразования, правила скидок, проверка остатков, запись в БД и т.п.» Это работает… какое-то время. Но новые функции превращаются в регрессионную рулетку, а тестовое покрытие резко падает, потому что доменная логика погребена под инфраструктурной.
Это классический симптом анемичной модели домена, где сущности — это всего лишь держатели данных, а вся логика находится в другом месте. Это затрудняет понимание системы, и каждое изменение превращается в угадайку.
В этой серии мы:
- Изучим типичную анемичную реализацию.
- Определим скрытые бизнес-правила, которые делают её хрупкой.
- Выполним рефакторинг в сторону агрегата с богатым поведением.
- Выделим конкретные выгоды, чтобы вы могли обосновать изменение для членов команды.
Начало: Божественный Класс Сервиса
Ниже приведён (к сожалению, распространённый пример) OrderService. Помимо расчёта итоговых сумм он также:
- применяет скидку VIP 5%,
- выбрасывает исключение, если какой-то товар отсутствует на складе,
- отклоняет заказы, которые превышают кредитный лимит клиента.
// OrderService.cs
public void PlaceOrder(
Guid customerId,
IEnumerable<OrderItemDto> items)
{
var customer = _db.Customers.Find(customerId);
if (customer is null)
throw new ArgumentException("Клиент не найден");
var order = new Order { CustomerId = customerId };
foreach (var dto in items)
{
var inventory = _invService
.GetStock(dto.ProductId);
if (inventory < dto.Quantity)
throw new InvalidOperationException("Товара недостаточно");
var price = _pricingService
.GetPrice(dto.ProductId);
var lineTotal = price * dto.Quantity;
// скидка 5% для VIP
if (customer.IsVip)
lineTotal *= 0.95m;
order.Items.Add(new OrderItem
{
ProductId = dto.ProductId,
Quantity = dto.Quantity,
UnitPrice = price,
LineTotal = lineTotal
});
}
order.Total = order.Items
.Sum(i => i.LineTotal);
if (customer.CreditUsed + order.Total > customer.CreditLimit)
throw new InvalidOperationException("Кредитный лимит превышен ");
_db.Orders.Add(order);
_db.SaveChanges();
}
Что здесь не так?
1. Разрозненные правила: применение скидок, проверка остатков и проверки кредитного лимита зарыты внутри сервиса.
2. Тесная связь: OrderService должен знать о ценах, запасах и EF Core только для того, чтобы разместить заказ.
3. Болезненное тестирование: каждому модульному тесту нужны моки для доступа к БД, ценообразования, запасов и потоки для VIP и не VIP клиентов.
Наша цель - внедрить эти правила в домен, чтобы прикладной уровень занимался только оркестрацией.
Руководящие принципы
1. Размещаем защитные инварианты близко к данным.
Проверки остатков, скидок и кредита относятся к месту, где находятся данные — внутри агрегата Order.
2. Раскрываем намерение, скрываем механику.
Прикладной уровень должен читаться как история: «разместить заказ», а не «рассчитать итоги, проверить кредит, записать в БД».
3. Выполняем рефакторинг в срезах.
Каждый ход безопасен и компилируется; никаких больших переписываний.
4. Балансируем чистоту с прагматизмом.
Изменяйте правила только тогда, когда выгода (ясность, безопасность, тестируемость) перевешивает дополнительные строки кода.
Продолжение следует…
Источник: https://www.milanjovanovic.tech/blog/from-anemic-models-to-behavior-driven-models-a-practical-ddd-refactor-in-csharp
День 2310. #ЗаметкиНаПолях
Уходим от Анемичных Моделей. Пример DDD-Рефакторинга. Продолжение
Начало
Пошаговый рефакторинг
Цель здесь не в погоне за чистотой или академическим DDD. Она в постепенном улучшении связности и создании пространства для самовыражения домена. На каждом шаге мы спрашиваем: должно ли это поведение принадлежать домену? Если да, мы добавляем его внутрь домена.
Внедрение логики создания и проверки
Первый шаг — сделать агрегат ответственным за самосборку. Статический метод Create даёт нам единую точку входа, где все инварианты могут работать по принципу «fail fast».
Хотя добавление проверки остатков в Order улучшает тестируемость, оно связывает поток заказов с доступностью товаров на складе. В некоторых доменах лучше смоделировать это как событие домена и проверять асинхронно.
Зачем мы это сделали?
Создание заказа теперь быстро завершается неудачей, если какой-либо инвариант нарушен. Сервис больше не занимается микроуправлением запасами или скидками.
Обратите внимание, как мы теперь следуем принципу «Скажи, не спрашивай». Вместо того, чтобы сервис проверял условия и затем манипулировал заказом, мы говорим заказу создать себя с необходимыми встроенными проверками. Это фундаментальный сдвиг в сторону инкапсуляции.
Замечание: О внедрении сервисов в методы домена
Передача сервисов, таких как IPricingService или IInventoryService, в метод домена, такой как Order.Create, на первый взгляд может показаться нетрадиционной и спорной. Но это осознанный выбор дизайна: он сохраняет оркестрацию внутри модели домена, где естественным образом находится бизнес-логика вместо того, чтобы раздувать сервис приложения процедурными рабочими процессами.
Такой подход сохраняет автономность сущности, при этом по-прежнему согласуясь с принципами внедрения зависимостей: зависимости передаются явно, а не разрешаются изнутри. Это мощный метод, но его следует использовать избирательно — только тогда, когда операция явно вписывается в сферу ответственности домена и выигрывает от прямого доступа к внешним сервисам.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/from-anemic-models-to-behavior-driven-models-a-practical-ddd-refactor-in-csharp
Уходим от Анемичных Моделей. Пример DDD-Рефакторинга. Продолжение
Начало
Пошаговый рефакторинг
Цель здесь не в погоне за чистотой или академическим DDD. Она в постепенном улучшении связности и создании пространства для самовыражения домена. На каждом шаге мы спрашиваем: должно ли это поведение принадлежать домену? Если да, мы добавляем его внутрь домена.
Внедрение логики создания и проверки
Первый шаг — сделать агрегат ответственным за самосборку. Статический метод Create даёт нам единую точку входа, где все инварианты могут работать по принципу «fail fast».
Хотя добавление проверки остатков в Order улучшает тестируемость, оно связывает поток заказов с доступностью товаров на складе. В некоторых доменах лучше смоделировать это как событие домена и проверять асинхронно.
// Order.cs (Фабричный метод)
public static Order Create(
Customer customer,
IEnumerable<(Guid productId, int quantity)> lines,
IPricingService pricingService,
IInventoryService invService)
{
var order = new Order(customer.Id);
foreach (var (id, quantity) in lines)
{
if (invService.GetStock(id) < quantity)
throw new InvalidOperationException("Товара недостаточно");
var price = pricingService.GetPrice(id);
order.AddItem(id, quantity,
price, customer.IsVip);
}
order.EnsureCreditWithinLimit(customer);
return order;
}
Зачем мы это сделали?
Создание заказа теперь быстро завершается неудачей, если какой-либо инвариант нарушен. Сервис больше не занимается микроуправлением запасами или скидками.
Обратите внимание, как мы теперь следуем принципу «Скажи, не спрашивай». Вместо того, чтобы сервис проверял условия и затем манипулировал заказом, мы говорим заказу создать себя с необходимыми встроенными проверками. Это фундаментальный сдвиг в сторону инкапсуляции.
Замечание: О внедрении сервисов в методы домена
Передача сервисов, таких как IPricingService или IInventoryService, в метод домена, такой как Order.Create, на первый взгляд может показаться нетрадиционной и спорной. Но это осознанный выбор дизайна: он сохраняет оркестрацию внутри модели домена, где естественным образом находится бизнес-логика вместо того, чтобы раздувать сервис приложения процедурными рабочими процессами.
Такой подход сохраняет автономность сущности, при этом по-прежнему согласуясь с принципами внедрения зависимостей: зависимости передаются явно, а не разрешаются изнутри. Это мощный метод, но его следует использовать избирательно — только тогда, когда операция явно вписывается в сферу ответственности домена и выигрывает от прямого доступа к внешним сервисам.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/from-anemic-models-to-behavior-driven-models-a-practical-ddd-refactor-in-csharp
День 2311. #ЗаметкиНаПолях
Уходим от Анемичных Моделей. Пример DDD-Рефакторинга. Окончание
Начало
Продолжение
Защищаем Внутреннее Состояние Агрегата
Зачем?
1. Инкапсуляция
Потребители не могут напрямую изменять _items, гарантируя сохранение инвариантов.
2. Самозащита
Модель домена защищает свою собственную согласованность, а не полагается на проверки на уровне сервисов.
3. Истинный ООП
Объекты теперь объединяют данные и поведение, как и задумано объектно-ориентированным программированием.
4. Более простые сервисы
Сервисы приложений могут сосредоточиться на координации, а не на бизнес-правилах.
Сокращаем слой приложения до чистой оркестрации
Метод PlaceOrder сокращается в 3 раза, при этом бизнес-логика отсутствует.
Что мы получили
- Агрегат владеет всеми бизнес-правилами; сервис только оркеструет.
- Чистые тесты предметной области — контейнер базы данных не требуется.
- Большинство изменений изолированы в агрегате Order.
Итого
Настоящая ценность рефакторинга анемичных моделей не техническая, а стратегическая. Переместив бизнес-логику ближе к данным, мы:
- Уменьшили площадь распространения изменений;
- Сделали бизнес-правила явными и проверяемыми.
Именно так устаревшие системы превращаются в удобные в обслуживании архитектуры.
Источник: https://www.milanjovanovic.tech/blog/from-anemic-models-to-behavior-driven-models-a-practical-ddd-refactor-in-csharp
Уходим от Анемичных Моделей. Пример DDD-Рефакторинга. Окончание
Начало
Продолжение
Защищаем Внутреннее Состояние Агрегата
// Order.cs (вырезка)
private readonly List<OrderItem> _items = new();
public IReadOnlyCollection<OrderItem> Items
=> _items.AsReadOnly(); // C# 12 -> [.._items]
private void AddItem(Guid id, int quantity,
decimal price, bool isVip)
{
if (quantity <= 0)
throw new ArgumentException("Количество должно быть положительным");
var finalPrice = isVip
? price * 0.95m
: price;
_items.Add(
new OrderItem(id, quantity, finalPrice)
);
RecalculateTotal();
}
private void EnsureCreditWithinLimit(Customer customer)
{
if (customer.CreditUsed + Total > customer.CreditLimit)
throw new InvalidOperationException("Кредитный лимит превышен");
}
Зачем?
1. Инкапсуляция
Потребители не могут напрямую изменять _items, гарантируя сохранение инвариантов.
2. Самозащита
Модель домена защищает свою собственную согласованность, а не полагается на проверки на уровне сервисов.
3. Истинный ООП
Объекты теперь объединяют данные и поведение, как и задумано объектно-ориентированным программированием.
4. Более простые сервисы
Сервисы приложений могут сосредоточиться на координации, а не на бизнес-правилах.
Сокращаем слой приложения до чистой оркестрации
public void PlaceOrder(
Guid customerId,
IEnumerable<OrderLineDto> lines)
{
var customer = _db.Customers.Find(customerId);
if (customer is null)
throw new ArgumentException("Клиент не найден");
var input = lines.Select(l => (l.ProductId, l.Quantity));
var order = Order.Create(
customer, input,
_pricingService, _inventoryService);
_db.Orders.Add(order);
_db.SaveChanges();
}
Метод PlaceOrder сокращается в 3 раза, при этом бизнес-логика отсутствует.
Что мы получили
- Агрегат владеет всеми бизнес-правилами; сервис только оркеструет.
- Чистые тесты предметной области — контейнер базы данных не требуется.
- Большинство изменений изолированы в агрегате Order.
Итого
Настоящая ценность рефакторинга анемичных моделей не техническая, а стратегическая. Переместив бизнес-логику ближе к данным, мы:
- Уменьшили площадь распространения изменений;
- Сделали бизнес-правила явными и проверяемыми.
Именно так устаревшие системы превращаются в удобные в обслуживании архитектуры.
Источник: https://www.milanjovanovic.tech/blog/from-anemic-models-to-behavior-driven-models-a-practical-ddd-refactor-in-csharp
День 2312. #Карьера
Советы по Эффективной Письменной Рабочей Коммуникации. Начало
Важность эффективной, чёткой коммуникации сейчас так же важна, как и когда-либо.
Разве ИИ не может сделать это за меня?
ИИ может создавать контент для вас — и вы даже можете включить некоторые из советов ниже в промпт. Но контент, который вы создаёте, исходит от ВАС, поэтому он по-прежнему отражает вашу способность создавать чёткое сообщение.
Типы коммуникаций
Список ниже, безусловно, не является исчерпывающим, но охватывает многие из форматов общений, которые создают разработчики:
- Email
- Сообщения в блогах
- Сообщения в соц. сетях
- Teams/Slack
- Официальные деловые заметки
- Резюме для руководства
- Презентации Power Point
- Страницы Wiki / Документация
- Файлы Readme
Вот несколько советов и предложений, которые позволят вашему сообщению дойти до адресата максимально эффективно и результативно.
1. Знайте свою аудиторию
Определите цель общения и подумайте, что у вас общего и различного с аудиторией. Вот несколько вопросов, которые могут помочь:
- Выполняют ли они ту же работу, что и я?
- Это в той же области бизнеса?
- У них тот же уровень опыта?
- Должен ли контент быть актуальным через год? Больше?
Ваше общение должно быть направлено не на то, чтобы показать, как много вы знаете, а на то, что вы хотите, чтобы ваша аудитория получила от него, или на действия, которые вы хотите, чтобы они предприняли. Зачастую они не знают вашу работу или ваш бизнес.
2. Используйте списки и форматирование
Чтение длинного повествования или абзаца — сложная задача. Краткое изложение ключевых моментов помогает читателям быстрее усваивать контент.
- Сделайте это лёгким
- Пусть маркеры будут простыми
- Используйте форматирование, чтобы привлечь внимание к ключевым моментам
3. Меньше значит больше
После того, как вы создали контент, перечитайте его и удалите ненужные слова и абзацы.
Вот пример потенциальных гиперссылок:
- Нажмите здесь, чтобы сделать что-то интересное
- Нажмите здесь, чтобы сделать что-то ещё
Его можно легко упростить:
- Сделайте что-то интересное
- Сделайте что-то ещё
Обратите внимание, что ссылка сама «говорит», что нужно сделать. В зависимости от реальной ситуации слова могут быть потенциально упрощены ещё больше.
4. Избегайте внутренних шуток
Чем шире ваша аудитория, тем меньше вероятность того, что все поймут юмор, который вы включаете в сообщение. Прежде чем включать сленг, юмор, шутки или подобный контент, подумайте, будет ли этот контент одинаково понятен всем, кто может его прочитать. Наличие контента, который некоторые не понимают, часто будет означать, что остальная часть вашего сообщения также будет менее понятна.
Сохранение игривого тона 😄 возможно, просто будьте осторожны с «внутрячками», которые поймут лишь немногие.
5. Минимизируйте предположения
Предположения часто могут иметь форму TLA (трехбуквенных аббревиатур), и, если вас немного сбила с толку «TLA» — это и является примером такого рода предположений, которые могут отвлечь читателей от сути сообщения.
Чёткое понимание аудитории и того, что они могут знать, а что нет, может помочь. Использование аббревиатур может быть приемлемым в случаях, когда вы уверены, что все их знают.
Окончание следует…
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
Советы по Эффективной Письменной Рабочей Коммуникации. Начало
Важность эффективной, чёткой коммуникации сейчас так же важна, как и когда-либо.
Разве ИИ не может сделать это за меня?
ИИ может создавать контент для вас — и вы даже можете включить некоторые из советов ниже в промпт. Но контент, который вы создаёте, исходит от ВАС, поэтому он по-прежнему отражает вашу способность создавать чёткое сообщение.
Типы коммуникаций
Список ниже, безусловно, не является исчерпывающим, но охватывает многие из форматов общений, которые создают разработчики:
- Сообщения в блогах
- Сообщения в соц. сетях
- Teams/Slack
- Официальные деловые заметки
- Резюме для руководства
- Презентации Power Point
- Страницы Wiki / Документация
- Файлы Readme
Вот несколько советов и предложений, которые позволят вашему сообщению дойти до адресата максимально эффективно и результативно.
1. Знайте свою аудиторию
Определите цель общения и подумайте, что у вас общего и различного с аудиторией. Вот несколько вопросов, которые могут помочь:
- Выполняют ли они ту же работу, что и я?
- Это в той же области бизнеса?
- У них тот же уровень опыта?
- Должен ли контент быть актуальным через год? Больше?
Ваше общение должно быть направлено не на то, чтобы показать, как много вы знаете, а на то, что вы хотите, чтобы ваша аудитория получила от него, или на действия, которые вы хотите, чтобы они предприняли. Зачастую они не знают вашу работу или ваш бизнес.
2. Используйте списки и форматирование
Чтение длинного повествования или абзаца — сложная задача. Краткое изложение ключевых моментов помогает читателям быстрее усваивать контент.
- Сделайте это лёгким
- Пусть маркеры будут простыми
- Используйте форматирование, чтобы привлечь внимание к ключевым моментам
3. Меньше значит больше
После того, как вы создали контент, перечитайте его и удалите ненужные слова и абзацы.
Вот пример потенциальных гиперссылок:
- Нажмите здесь, чтобы сделать что-то интересное
- Нажмите здесь, чтобы сделать что-то ещё
Его можно легко упростить:
- Сделайте что-то интересное
- Сделайте что-то ещё
Обратите внимание, что ссылка сама «говорит», что нужно сделать. В зависимости от реальной ситуации слова могут быть потенциально упрощены ещё больше.
4. Избегайте внутренних шуток
Чем шире ваша аудитория, тем меньше вероятность того, что все поймут юмор, который вы включаете в сообщение. Прежде чем включать сленг, юмор, шутки или подобный контент, подумайте, будет ли этот контент одинаково понятен всем, кто может его прочитать. Наличие контента, который некоторые не понимают, часто будет означать, что остальная часть вашего сообщения также будет менее понятна.
Сохранение игривого тона 😄 возможно, просто будьте осторожны с «внутрячками», которые поймут лишь немногие.
5. Минимизируйте предположения
Предположения часто могут иметь форму TLA (трехбуквенных аббревиатур), и, если вас немного сбила с толку «TLA» — это и является примером такого рода предположений, которые могут отвлечь читателей от сути сообщения.
Чёткое понимание аудитории и того, что они могут знать, а что нет, может помочь. Использование аббревиатур может быть приемлемым в случаях, когда вы уверены, что все их знают.
Окончание следует…
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
День 2313. #Карьера
Советы по Эффективной Письменной Рабочей Коммуникации. Окончание
Начало
6. Эффективно используйте визуальные элементы
Изображение стоит тысячи слов. Потоки, отношения или архитектуры можно кратко представить с помощью диаграммы. Код — ещё один пример хорошего визуального элемента, но имейте в виду, что если вы используете какой-то «реальный» код, удалите лишние строки, не существенные для примера (даже несущественные комментарии, как в примере ниже):
7. Резюмируйте заранее
Обычное сокращение в мире технологий — tl;dr — что означает «слишком долго;не читал» (для олдов: «ниасилил ибо войнаимир»). В верхней части сообщения добавьте краткое резюме того, о чём оно будет.
Краткое резюме может помочь читателю понять, СТОИТ ли ему продолжать читать, поскольку оно обобщает всё содержимое в короткой аннотации. Если аннотация интересна, он может продолжить чтение и углубиться в детали.
Резюмирование особенно важно, если вы просите о действии или даёте рекомендацию. В таких случаях сразу переходите к сути (и используйте форматирование), как в следующих примерах, которые могут быть в начале сообщения:
- Пожалуйста, создайте функцию до следующего вторника
- Рекомендую использовать фреймворк A
Далее вы можете подробно изложить как требования, так и рекомендации, но изложение своей точки зрения сразу устраняет путаницу.
8. Избегайте метафор
Метафоры могут отвлекать от реального сообщения, которое вы пытаетесь донести. Часто они сами по себе не очень понятны, и то, что вы пытаетесь представить, теперь зависит от метафоры.
9. Избегайте «Привет»-ственных сообщений
Не начинайте новое общение с одного сообщения, типа: «Привет, Имярек».
Это раздражающее сообщение встречается слишком часто и не помогает общению. Никакого ответа не требуется, а собеседник понятия не имеет, что вы хотите, и вынужден ждать продолжения. Это особенно раздражает, если он сосредоточен на чём-то, а теперь нужно подумать о том, кто отправитель и чего он может хотеть.
Гораздо лучше написать: «Привет, Имярек, нужна твоя помощь с багом, который мы получили…»
На этом этапе собеседник даже может оценить приоритет на основе дополнительного контекста сообщения и решить, заняться ли им немедленно или ответить позже, когда не будет занят.
10. Создавайте важные сообщения в два этапа
При написании важного сообщения создайте черновик, а затем выполните одно из двух действий или оба:
- Вернитесь к нему позже (лучше всего на следующий день, после сна).
- Попросите людей, которым вы доверяете, дать отзыв
Часто свежий взгляд и вторая пара глаз могут помочь улучшить сообщение или избежать проблемной фразы.
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
Советы по Эффективной Письменной Рабочей Коммуникации. Окончание
Начало
6. Эффективно используйте визуальные элементы
Изображение стоит тысячи слов. Потоки, отношения или архитектуры можно кратко представить с помощью диаграммы. Код — ещё один пример хорошего визуального элемента, но имейте в виду, что если вы используете какой-то «реальный» код, удалите лишние строки, не существенные для примера (даже несущественные комментарии, как в примере ниже):
public void SomeMethod()
{
// логика метода тут
}
7. Резюмируйте заранее
Обычное сокращение в мире технологий — tl;dr — что означает «слишком долго;не читал» (для олдов: «ниасилил ибо войнаимир»). В верхней части сообщения добавьте краткое резюме того, о чём оно будет.
Краткое резюме может помочь читателю понять, СТОИТ ли ему продолжать читать, поскольку оно обобщает всё содержимое в короткой аннотации. Если аннотация интересна, он может продолжить чтение и углубиться в детали.
Резюмирование особенно важно, если вы просите о действии или даёте рекомендацию. В таких случаях сразу переходите к сути (и используйте форматирование), как в следующих примерах, которые могут быть в начале сообщения:
- Пожалуйста, создайте функцию до следующего вторника
- Рекомендую использовать фреймворк A
Далее вы можете подробно изложить как требования, так и рекомендации, но изложение своей точки зрения сразу устраняет путаницу.
8. Избегайте метафор
Метафоры могут отвлекать от реального сообщения, которое вы пытаетесь донести. Часто они сами по себе не очень понятны, и то, что вы пытаетесь представить, теперь зависит от метафоры.
9. Избегайте «Привет»-ственных сообщений
Не начинайте новое общение с одного сообщения, типа: «Привет, Имярек».
Это раздражающее сообщение встречается слишком часто и не помогает общению. Никакого ответа не требуется, а собеседник понятия не имеет, что вы хотите, и вынужден ждать продолжения. Это особенно раздражает, если он сосредоточен на чём-то, а теперь нужно подумать о том, кто отправитель и чего он может хотеть.
Гораздо лучше написать: «Привет, Имярек, нужна твоя помощь с багом, который мы получили…»
На этом этапе собеседник даже может оценить приоритет на основе дополнительного контекста сообщения и решить, заняться ли им немедленно или ответить позже, когда не будет занят.
10. Создавайте важные сообщения в два этапа
При написании важного сообщения создайте черновик, а затем выполните одно из двух действий или оба:
- Вернитесь к нему позже (лучше всего на следующий день, после сна).
- Попросите людей, которым вы доверяете, дать отзыв
Часто свежий взгляд и вторая пара глаз могут помочь улучшить сообщение или избежать проблемной фразы.
Источник: https://knowyourtoolset.com/2025/05/tips-for-communication/
День 2314. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 53. Боль — лучшая мотивация для изменения методов работы
Для команд и организаций, как и для отдельных людей, боль является мощным мотиватором, подталкивающим к изменениям. Мы говорим не о боли, искусственно вызванной извне, когда руководители или клиенты требуют невозможного, а о боли, которую команда испытывает от используемых методов работы.
Мероприятия по совершенствованию процессов не особенно приятны. Они отвлекают от «настоящей работы», которая более интересна членам команды и приносит пользу бизнесу. Усилия по изменению могут казаться сизифовым трудом, поскольку много факторов препятствуют проведению устойчивых организационных изменений. Чтобы мотивировать людей участвовать в изменении, обещанное уменьшение боли должно перевешивать дискомфорт, вызываемый самой процедурой совершенствования. И в какой-то момент участники должны почувствовать, что боль уменьшилась, иначе откажутся участвовать в подобной работе в следующий раз.
Боль причиняет неудобства!
Как бы вы определили «боль» в вашей организации? Какие хронические проблемы возникают в ваших проектах? Определив их, вы сможете сконцентрировать усилия по совершенствованию там, где они принесут наибольшую пользу. Вот несколько типичных примеров «болей» в проектах:
- несоблюдение запланированных сроков поставки;
- выпуск продуктов с чрезмерным количеством дефектов или функциональными недостатками;
- неспособность поспевать за запросами на изменение;
- создание систем, которые трудно расширять без значительных доработок;
- поставка продуктов, не отвечающих в должной мере потребностям клиентов;
- частые сбои системы, вынуждающие дежурного специалиста по поддержке работать по ночам;
- взаимодействие с руководителями, недостаточно хорошо разбирающимися в текущих технологических проблемах и подходах к разработке ПО;
- сложности из-за рисков, которые не были выявлены или уменьшены.
Цель любой деятельности по оценке процесса (группового обсуждения, ретроспективного обзора проекта или оценки сторонним консультантом) — выявить эти проблемные области. После этого появляется возможность определить основные причины проблем и предпринять шаги по их устранению.
Незаметная боль
Проблемы, затрагивающие одних участников проекта, могут быть незаметны другим. Вы можете работать с командой над созданием какой-то функциональности, фонтанировать идеями о постоянном её улучшении. Но с точки зрения команды это будет кошмаром, потому что вы никак не можете определиться с требованиями или выбрать один метод работы. Это подчёркивает необходимость чёткого информирования всех заинтересованных сторон об ожиданиях и проблемах.
Кроме того, трудно продать мышеловку тому, кто не знает, что у него есть мыши. Если вы не замечаете негативных последствий использования текущего подхода, то, скорее всего, не будете восприимчивы к предложениям об изменениях. Любое предлагаемое изменение должно выглядеть как решение проблемы. Поэтому важным аспектом совершенствования процессов выступает выявление причин и затрат, обусловленных проблемами, которые порождает процесс, и последующее информирование тех, кого это касается. Такая осведомлённость может побудить всех участников начать поступать иным образом.
Иногда вы можете стимулировать это осознание. Часто даже групповое обсуждение проблем, с которыми сталкиваются разные члены команды: бизнес-аналитики, руководители проекта, разработчики, заказчики, тестировщики, маркетологи и т.д., - помогает людям понять трудности других и служит хорошей отправной точкой для совершенствования подходов к работе, приносящего пользу всем.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 53. Боль — лучшая мотивация для изменения методов работы
Для команд и организаций, как и для отдельных людей, боль является мощным мотиватором, подталкивающим к изменениям. Мы говорим не о боли, искусственно вызванной извне, когда руководители или клиенты требуют невозможного, а о боли, которую команда испытывает от используемых методов работы.
Мероприятия по совершенствованию процессов не особенно приятны. Они отвлекают от «настоящей работы», которая более интересна членам команды и приносит пользу бизнесу. Усилия по изменению могут казаться сизифовым трудом, поскольку много факторов препятствуют проведению устойчивых организационных изменений. Чтобы мотивировать людей участвовать в изменении, обещанное уменьшение боли должно перевешивать дискомфорт, вызываемый самой процедурой совершенствования. И в какой-то момент участники должны почувствовать, что боль уменьшилась, иначе откажутся участвовать в подобной работе в следующий раз.
Боль причиняет неудобства!
Как бы вы определили «боль» в вашей организации? Какие хронические проблемы возникают в ваших проектах? Определив их, вы сможете сконцентрировать усилия по совершенствованию там, где они принесут наибольшую пользу. Вот несколько типичных примеров «болей» в проектах:
- несоблюдение запланированных сроков поставки;
- выпуск продуктов с чрезмерным количеством дефектов или функциональными недостатками;
- неспособность поспевать за запросами на изменение;
- создание систем, которые трудно расширять без значительных доработок;
- поставка продуктов, не отвечающих в должной мере потребностям клиентов;
- частые сбои системы, вынуждающие дежурного специалиста по поддержке работать по ночам;
- взаимодействие с руководителями, недостаточно хорошо разбирающимися в текущих технологических проблемах и подходах к разработке ПО;
- сложности из-за рисков, которые не были выявлены или уменьшены.
Цель любой деятельности по оценке процесса (группового обсуждения, ретроспективного обзора проекта или оценки сторонним консультантом) — выявить эти проблемные области. После этого появляется возможность определить основные причины проблем и предпринять шаги по их устранению.
Незаметная боль
Проблемы, затрагивающие одних участников проекта, могут быть незаметны другим. Вы можете работать с командой над созданием какой-то функциональности, фонтанировать идеями о постоянном её улучшении. Но с точки зрения команды это будет кошмаром, потому что вы никак не можете определиться с требованиями или выбрать один метод работы. Это подчёркивает необходимость чёткого информирования всех заинтересованных сторон об ожиданиях и проблемах.
Кроме того, трудно продать мышеловку тому, кто не знает, что у него есть мыши. Если вы не замечаете негативных последствий использования текущего подхода, то, скорее всего, не будете восприимчивы к предложениям об изменениях. Любое предлагаемое изменение должно выглядеть как решение проблемы. Поэтому важным аспектом совершенствования процессов выступает выявление причин и затрат, обусловленных проблемами, которые порождает процесс, и последующее информирование тех, кого это касается. Такая осведомлённость может побудить всех участников начать поступать иным образом.
Иногда вы можете стимулировать это осознание. Часто даже групповое обсуждение проблем, с которыми сталкиваются разные члены команды: бизнес-аналитики, руководители проекта, разработчики, заказчики, тестировщики, маркетологи и т.д., - помогает людям понять трудности других и служит хорошей отправной точкой для совершенствования подходов к работе, приносящего пользу всем.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
День 2315. #ЧтоНовенького
Представляем dotnet run app.cs. Начало
В .NET 10 превью 4 упрощено начало работы с C#. Теперь вы можете запустить файл C# напрямую с помощью
До сих пор для выполнения кода C# с помощью dotnet CLI требовалась структура проекта, включающая файл .csproj. Теперь с помощью «файловых приложений» (file-based apps), вы можете запустить автономный файл .cs напрямую, как и в случае с такими языками сценариев, как Python или JavaScript.
Это снижает порог входа для изучения C# и делает язык гораздо более привлекательным выбором для сценариев обучения, прототипирования или автоматизации:
- Быстрый старт, не требуется файл проекта — отлично подходит для обучения, экспериментов и небольших скриптов.
- Первоклассная интеграция CLI — никаких дополнительных инструментов, никаких зависимостей, только dotnet и файл .cs.
- Масштабируется до реальных приложений — это не отдельный диалект или среда выполнения. Когда скрипт вырастет, он может превратиться в полноценный проект, использующий тот же язык, синтаксис и инструменты.
Новые директивы уровня файла для файловых приложений C#
Файловые приложения также поддерживают набор мощных директив уровня файла, которые позволяют объявлять небольшое количество важных вещей, хранящихся в файлах проекта для стандартных приложений. Эти директивы делают файловые приложения более гибкими и выразительными, сохраняя совместимость с концепциями MSBuild.
Ссылаемся на NuGet-пакеты
Вы можете добавить ссылку на NuGet-пакет напрямую в файле .cs, используя директиву #:package:
Указываем SDK
По умолчанию файловые приложения используют Microsoft.NET.Sdk SDK. Если вы создаете что-то вроде веб-API, вы можете изменить SDK с помощью директивы #:sdk:
Это сообщает инструментам, что файл следует обрабатывать так, как если бы он был частью веб-проекта, что позволяет использовать такие функции ASP.NET Core, как Minimal API и MVC.
Настраиваем MSBuild
Вы можете настроить дополнительные свойства сборки с помощью #:property:
Это позволяет файловому приложению использовать расширенные языковые функции и таргетинг на платформу без необходимости в полном файле проекта.
Использование строк шебанг для шелл-скриптов
Файловые приложения также поддерживают строки шебанг (#!), что позволяет писать кроссплатформенные шелл-скрипты на C#, которые можно выполнять непосредственно в Unix-подобных системах:
Вы можете сделать файл выполняемым и выполнить его напрямую:
Это позволяет сделать C# удобной опцией для утилит CLI, скриптов автоматизации и тулинга, никакой настройки проекта не требуется.
Окончание следует…
Источник: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/
Представляем dotnet run app.cs. Начало
В .NET 10 превью 4 упрощено начало работы с C#. Теперь вы можете запустить файл C# напрямую с помощью
dotnet run app.cs. Т.е. больше не нужно создавать файл проекта или создавать каркас целого приложения для запуска быстрого скрипта, тестирования фрагмента кода или простого эксперимента.До сих пор для выполнения кода C# с помощью dotnet CLI требовалась структура проекта, включающая файл .csproj. Теперь с помощью «файловых приложений» (file-based apps), вы можете запустить автономный файл .cs напрямую, как и в случае с такими языками сценариев, как Python или JavaScript.
Это снижает порог входа для изучения C# и делает язык гораздо более привлекательным выбором для сценариев обучения, прототипирования или автоматизации:
- Быстрый старт, не требуется файл проекта — отлично подходит для обучения, экспериментов и небольших скриптов.
- Первоклассная интеграция CLI — никаких дополнительных инструментов, никаких зависимостей, только dotnet и файл .cs.
- Масштабируется до реальных приложений — это не отдельный диалект или среда выполнения. Когда скрипт вырастет, он может превратиться в полноценный проект, использующий тот же язык, синтаксис и инструменты.
Новые директивы уровня файла для файловых приложений C#
Файловые приложения также поддерживают набор мощных директив уровня файла, которые позволяют объявлять небольшое количество важных вещей, хранящихся в файлах проекта для стандартных приложений. Эти директивы делают файловые приложения более гибкими и выразительными, сохраняя совместимость с концепциями MSBuild.
Ссылаемся на NuGet-пакеты
Вы можете добавить ссылку на NuGet-пакет напрямую в файле .cs, используя директиву #:package:
#:package Humanizer@2.14.1
using System.Globalization;
using Humanizer;
Thread.CurrentThread.CurrentUICulture = new CultureInfo("ru-ru");
var net9Release = DateTimeOffset.Parse("2024-12-03");
var since = DateTimeOffset.Now - net9Release;
Console.WriteLine($"Прошло {since.Humanize()} с релиза .NET 9.");
// Прошло 25 недель с релиза .NET 9.
Указываем SDK
По умолчанию файловые приложения используют Microsoft.NET.Sdk SDK. Если вы создаете что-то вроде веб-API, вы можете изменить SDK с помощью директивы #:sdk:
#:sdk Microsoft.NET.Sdk.Web
Это сообщает инструментам, что файл следует обрабатывать так, как если бы он был частью веб-проекта, что позволяет использовать такие функции ASP.NET Core, как Minimal API и MVC.
Настраиваем MSBuild
Вы можете настроить дополнительные свойства сборки с помощью #:property:
#:property LangVersion preview
Это позволяет файловому приложению использовать расширенные языковые функции и таргетинг на платформу без необходимости в полном файле проекта.
Использование строк шебанг для шелл-скриптов
Файловые приложения также поддерживают строки шебанг (#!), что позволяет писать кроссплатформенные шелл-скрипты на C#, которые можно выполнять непосредственно в Unix-подобных системах:
#!/usr/bin/dotnet run
Console.WriteLine("Привет из скрипта C#!");
Вы можете сделать файл выполняемым и выполнить его напрямую:
chmod +x app.cs
./app.cs
Это позволяет сделать C# удобной опцией для утилит CLI, скриптов автоматизации и тулинга, никакой настройки проекта не требуется.
Окончание следует…
Источник: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/
День 2316. #ЧтоНовенького
Представляем dotnet run app.cs. Окончание
Начало
Преобразование в приложение на основе проекта
Когда ваше файловое приложение становится сложнее или вам просто нужны дополнительные возможности, предоставляемые полноценными приложениями на основе проектов, вы можете преобразовать его в стандартный проект с помощью:
Эта команда создаст новый каталог с именем файла, файл .csproj и преобразует все директивы #: в свойства и ссылки MSBuild. Например, из этого файла:
Будет создан такой файл .csproj:
Это делает переход плавным, от одного файла к полностью функциональному, собираемому и расширяемому проекту.
Существующие способы запуска C# без проектов
Это далеко не первый случай, когда разработчики хотят запустить C# без проекта. Такие проекты сообщества, как CS-Script, dotnet-script, Cake и другие, уже давно выполняют эту роль, обеспечивая рабочие процессы сценариев, возможности REPL и другие возможности C#.
Эти инструменты остаются ценными и заслуживают внимания, особенно для более сложных сценариев. Однако новая встроенная поддержка позволяет начать работу немедленно: не требуется дополнительных шагов по установке и настройке.
Что дальше?
Эта новая функция делает C# более доступным, сохраняя при этом всю мощь и глубину экосистемы .NET. Независимо от того, изучаете вы язык, обучаете ему других, создаёте прототипы или производственные системы, эта функция поможет вам быстрее перейти от идеи к реализации.
В предстоящих предварительных версиях .NET 10 обещают улучшить опыт работы с файловыми приложениями в VS Code с улучшенным IntelliSense для новых файловых директив, улучшенной производительностью и поддержкой отладки. Для командной строки идёт работа над обеспечением поддержки файловых приложений с несколькими файлами и способами ускорения запуска.
Создатели призывают вас попробовать новую функцию и ждут ваших отзывов на GitHub.
Источник: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/
Представляем dotnet run app.cs. Окончание
Начало
Преобразование в приложение на основе проекта
Когда ваше файловое приложение становится сложнее или вам просто нужны дополнительные возможности, предоставляемые полноценными приложениями на основе проектов, вы можете преобразовать его в стандартный проект с помощью:
dotnet project convert app.cs
Эта команда создаст новый каталог с именем файла, файл .csproj и преобразует все директивы #: в свойства и ссылки MSBuild. Например, из этого файла:
#:sdk Microsoft.NET.Sdk.Web
#:package Microsoft.AspNetCore.OpenApi@10.*-*
var builder = WebApplication.CreateBuilder();
builder.Services.AddOpenApi();
var app = builder.Build();
app.MapGet("/", () => "Hello, world!");
app.Run();
Будет создан такой файл .csproj:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="10.*-*" />
</ItemGroup>
</Project>
Это делает переход плавным, от одного файла к полностью функциональному, собираемому и расширяемому проекту.
Существующие способы запуска C# без проектов
Это далеко не первый случай, когда разработчики хотят запустить C# без проекта. Такие проекты сообщества, как CS-Script, dotnet-script, Cake и другие, уже давно выполняют эту роль, обеспечивая рабочие процессы сценариев, возможности REPL и другие возможности C#.
Эти инструменты остаются ценными и заслуживают внимания, особенно для более сложных сценариев. Однако новая встроенная поддержка позволяет начать работу немедленно: не требуется дополнительных шагов по установке и настройке.
Что дальше?
Эта новая функция делает C# более доступным, сохраняя при этом всю мощь и глубину экосистемы .NET. Независимо от того, изучаете вы язык, обучаете ему других, создаёте прототипы или производственные системы, эта функция поможет вам быстрее перейти от идеи к реализации.
В предстоящих предварительных версиях .NET 10 обещают улучшить опыт работы с файловыми приложениями в VS Code с улучшенным IntelliSense для новых файловых директив, улучшенной производительностью и поддержкой отладки. Для командной строки идёт работа над обеспечением поддержки файловых приложений с несколькими файлами и способами ускорения запуска.
Создатели призывают вас попробовать новую функцию и ждут ваших отзывов на GitHub.
Источник: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/
День 2317. #ЗаметкиНаПолях
Почему Перебор List Быстрее, чем IList?
Если у нас есть List<T> и IList<T>, перебор List<T> быстрее, чем IList<T>. Почему?
Запустим бенчмарк
Результаты будут примерно такие:
40 байт
Откуда взялись эти 40 байт? Когда вы вызываете List<T>.GetEnumerator() (что будет в каждом цикле foreach), вы получаете структуру с именем Enumerator. Когда вы вызываете IList<T>.GetEnumerator(), вы получаете переменную типа IEnumerator, которая содержит упакованную версию указанного перечислителя. Это объясняет 40 байт выделения в куче и некоторую разницу в производительности.
Вызовы виртуальных методов
Но есть и второе измерение. Когда вы вызываете IList<T>.GetEnumerator(), он должен вызвать виртуальный метод, что медленнее, чем вызов невиртуального метода. По сути, кто-то должен проверить, какой конкретный тип действительно используется, а затем вызвать правильный метод. Это не относится к List<T>, который уже является конкретным типом.
Источник: https://steven-giesel.com/blogPost/c624c170-c16c-4414-8506-2ae25ba54df7/why-is-enumerating-over-list-faster-than-ilist
Почему Перебор List Быстрее, чем IList?
Если у нас есть List<T> и IList<T>, перебор List<T> быстрее, чем IList<T>. Почему?
Запустим бенчмарк
[MemoryDiagnoser]
public class Benchmark
{
private List<int> list
= [.. Enumerable.Range(0, 10_000)];
private IList<int> ilist
= [.. Enumerable.Range(0, 10_000)];
[Benchmark(Baseline = true)]
public int GetSumOfList()
{
var sum = 0;
foreach (var n in list) { sum += n; }
return sum;
}
[Benchmark]
public int GetSumOfIList()
{
var sum = 0;
foreach (var n in ilist) { sum += n; }
return sum;
}
}
Результаты будут примерно такие:
|Method |Mean |…|Allocated|
|-------------|--------:|…|--------:|
|GetSumOfList | 4.214 us|…| -|
|GetSumOfIList|19.508 us|…| 40 B|
40 байт
Откуда взялись эти 40 байт? Когда вы вызываете List<T>.GetEnumerator() (что будет в каждом цикле foreach), вы получаете структуру с именем Enumerator. Когда вы вызываете IList<T>.GetEnumerator(), вы получаете переменную типа IEnumerator, которая содержит упакованную версию указанного перечислителя. Это объясняет 40 байт выделения в куче и некоторую разницу в производительности.
Вызовы виртуальных методов
Но есть и второе измерение. Когда вы вызываете IList<T>.GetEnumerator(), он должен вызвать виртуальный метод, что медленнее, чем вызов невиртуального метода. По сути, кто-то должен проверить, какой конкретный тип действительно используется, а затем вызвать правильный метод. Это не относится к List<T>, который уже является конкретным типом.
Источник: https://steven-giesel.com/blogPost/c624c170-c16c-4414-8506-2ae25ba54df7/why-is-enumerating-over-list-faster-than-ilist
День 2318. #ЗаметкиНаПолях
DTO и Маппинг: Хорошее, Плохое, Лишнее. Начало
DTO — это объекты, используемые для передачи данных между различными слоями или уровнями приложения. Они часто используются для сопоставления (маппинга) данных из одного представления в другое, особенно при пересечении границ, например, между БД и слоем UI или API.
Часто возникает путаница вокруг термина «сущность». Некоторые думают о сущностях в контексте ORM, такого как Entity Framework в .NET. В этом случае сущность — это просто сопоставление модели данных с таблицей БД. Другие думают о сущностях в смысле DDD, где это модель с поведением и идентичностью в пределах предметной области.
Зачем добавляют DTO?
Самая распространённая причина - нежелание раскрывать свою базовую модель данных или модель домена. Например, если сущность ORM напрямую отображается в схему БД, вы можете не захотеть отправлять именно эту сущность через API или на другой уровень приложения. Вместо этого вы создаёте DTO (отображение этой сущности), который отправляете дальше. Это справедливо в некоторых контекстах. Но почему просто не возвращать базовую сущность?
Сервисы сущностей и HTTP API: корень некоторых догм DTO
Часто люди создают DTO, почти идентичные своим сущностям. Конечные точки API сопоставляют операции CRUD напрямую с таблицами БД:
- GET – получение заказа,
- POST – создание,
- PUT – обновление,
- PATCH - частичное обновление,
- DELETE – удаление.
При этом API напрямую отображает методы HTTP на CRUD-операции БД. В этом поначалу нет ничего плохого, но это заставляет вас следовать определённым путем. В итоге вы начинаете думать об API просто как о тонком слое поверх схемы БД. Но API не должен быть таким. Ресурсы, предоставляемые API, не должны быть идентичны записям БД. В приложении, где UI создаётся на стороне сервера, вы бы собирали данные из нескольких источников, чтобы создать полноценное HTML-представление, а не брали бы голые данные из одной таблицы.
Например, если вы возвращаете DTO созданного заказа вы бы включили только его ID, дату создания и статус. Но если вы создаёте UI на стороне сервера, вы бы добавили информацию о клиенте (например, имя), которой может не быть непосредственно в объекте заказа. Также вы бы отобразили возможные действия, которые может выполнить пользователь, вроде «Выполнить», «Отменить» или «Отметить оплату».
Когда вы думаете исключительно в терминах сервисов сущностей и записей БД, вы упускаете эту более богатую композицию. В итоге вы получаете DTO, которые являются просто тонкими оболочками вокруг таблиц БД, не сильно отличающимися от самих сущностей.
Реальная ценность DTO
Есть два основных преимущества использования DTO:
1. Управление связанностью.
DTO помогают контролировать, насколько тесно внешние слои или потребители связаны с внутренними моделями данных.
2. Композиция
DTO позволяют составлять данные из нескольких источников или моделей в единую удобную форму, оптимизированную для конкретного варианта использования или потребителя.
Если вы не делаете никакой композиции и ваши DTO почти идентичны записям БД, то вы, скорее всего, делаете лишнюю работу. Каждый раз при смене базовой модели данных, вы вынуждены обновлять несколько DTO на разных уровнях, что добавляет сложности и накладных расходов на обслуживание, не обеспечивая при этом реальной ценности.
Но, если вы хорошо управляете связанностью и контролируете, как отображаются ваши внутренние модели, DTO становятся очень полезными. Они действуют как защитный слой, который позволяет развивать внутренние модели данных, не нарушая внешних потребителей. Если у вас пока нет этой проблемы (у вас немного потребителей, и вы хорошо управляете связями), то создание нескольких DTO «на всякий случай» может оказаться преждевременной оптимизацией.
Окончание следует…
Источник: https://codeopinion.com/dtos-mapping-the-good-the-bad-and-the-excessive/
DTO и Маппинг: Хорошее, Плохое, Лишнее. Начало
DTO — это объекты, используемые для передачи данных между различными слоями или уровнями приложения. Они часто используются для сопоставления (маппинга) данных из одного представления в другое, особенно при пересечении границ, например, между БД и слоем UI или API.
Часто возникает путаница вокруг термина «сущность». Некоторые думают о сущностях в контексте ORM, такого как Entity Framework в .NET. В этом случае сущность — это просто сопоставление модели данных с таблицей БД. Другие думают о сущностях в смысле DDD, где это модель с поведением и идентичностью в пределах предметной области.
Зачем добавляют DTO?
Самая распространённая причина - нежелание раскрывать свою базовую модель данных или модель домена. Например, если сущность ORM напрямую отображается в схему БД, вы можете не захотеть отправлять именно эту сущность через API или на другой уровень приложения. Вместо этого вы создаёте DTO (отображение этой сущности), который отправляете дальше. Это справедливо в некоторых контекстах. Но почему просто не возвращать базовую сущность?
Сервисы сущностей и HTTP API: корень некоторых догм DTO
Часто люди создают DTO, почти идентичные своим сущностям. Конечные точки API сопоставляют операции CRUD напрямую с таблицами БД:
- GET – получение заказа,
- POST – создание,
- PUT – обновление,
- PATCH - частичное обновление,
- DELETE – удаление.
При этом API напрямую отображает методы HTTP на CRUD-операции БД. В этом поначалу нет ничего плохого, но это заставляет вас следовать определённым путем. В итоге вы начинаете думать об API просто как о тонком слое поверх схемы БД. Но API не должен быть таким. Ресурсы, предоставляемые API, не должны быть идентичны записям БД. В приложении, где UI создаётся на стороне сервера, вы бы собирали данные из нескольких источников, чтобы создать полноценное HTML-представление, а не брали бы голые данные из одной таблицы.
Например, если вы возвращаете DTO созданного заказа вы бы включили только его ID, дату создания и статус. Но если вы создаёте UI на стороне сервера, вы бы добавили информацию о клиенте (например, имя), которой может не быть непосредственно в объекте заказа. Также вы бы отобразили возможные действия, которые может выполнить пользователь, вроде «Выполнить», «Отменить» или «Отметить оплату».
Когда вы думаете исключительно в терминах сервисов сущностей и записей БД, вы упускаете эту более богатую композицию. В итоге вы получаете DTO, которые являются просто тонкими оболочками вокруг таблиц БД, не сильно отличающимися от самих сущностей.
Реальная ценность DTO
Есть два основных преимущества использования DTO:
1. Управление связанностью.
DTO помогают контролировать, насколько тесно внешние слои или потребители связаны с внутренними моделями данных.
2. Композиция
DTO позволяют составлять данные из нескольких источников или моделей в единую удобную форму, оптимизированную для конкретного варианта использования или потребителя.
Если вы не делаете никакой композиции и ваши DTO почти идентичны записям БД, то вы, скорее всего, делаете лишнюю работу. Каждый раз при смене базовой модели данных, вы вынуждены обновлять несколько DTO на разных уровнях, что добавляет сложности и накладных расходов на обслуживание, не обеспечивая при этом реальной ценности.
Но, если вы хорошо управляете связанностью и контролируете, как отображаются ваши внутренние модели, DTO становятся очень полезными. Они действуют как защитный слой, который позволяет развивать внутренние модели данных, не нарушая внешних потребителей. Если у вас пока нет этой проблемы (у вас немного потребителей, и вы хорошо управляете связями), то создание нескольких DTO «на всякий случай» может оказаться преждевременной оптимизацией.
Окончание следует…
Источник: https://codeopinion.com/dtos-mapping-the-good-the-bad-and-the-excessive/
День 2319. #ЗаметкиНаПолях
DTO и Маппинг: Хорошее, Плохое, Лишнее. Окончание
Начало
CQRS для иллюстрации DTO в действии
В CQRS вы разделяете систему на две части:
1. Запросы отвечают за извлечение и составление данных, возвращая данные, адаптированные для конкретных вариантов использования.
2. Команды отвечают за намерение и действия, такие как обновление или удаление данных.
При этом ваши ответы на запросы по сути являются DTO, которые содержат все объединённые данные, необходимые для конкретного варианта использования. Например, если вы создаёте UI для отображения сведений о заказе, DTO запроса может включать не только данные заказа, но и сведения о клиенте и доступные действия, такие как «Выполнить» или «Отменить».
Команды, с другой стороны, представляют собой конкретные действия, которые вы хотите выполнить. Вместо того чтобы думать в терминах общих операций CRUD, вы думаете в терминах команд, специфичных для домена, таких как «ОтменитьЗаказ» или «ОтметитьЗаказОплаченным». Эти команды инкапсулируют намерение и поведение, а не просто обновления данных.
CQRS не требует разных БД для команд и запросов. Он больше про то, как вы моделируете свою систему и её взаимодействия. Команды и запросы могут работать с одной БД, но представлять разные модели и DTO, адаптированные для их конкретных целей.
Размышления о DTO
1. Внешние и внутренние данные
- Внутри - данные приватные для системы, детали реализации: схема БД и модели домена.
- Снаружи - данные, предоставляемые публично: контракты API или сообщения в очереди.
Цель в сохранении конфиденциальности внутренних данных, чтобы вы могли развивать и изменять их, не влияя на внешних потребителей. Внешние данные следует рассматривать как контракт, который необходимо тщательно версионировать, поскольку вы не контролируете всех потребителей.
Если вы владеете обеими сторонами взаимодействия и можете эффективно управлять связанностью, возможно, DTO не нужны везде. Но если вы предоставляете данные внешним сторонам или хотите разделить слои, чтобы обеспечить независимую эволюцию, DTO бесценны.
2. Количество потребителей
Сколько потребителей зависят от вашей внутренней модели данных? Если всего пара, и вы хорошо управляете связью, вы можете спокойно возвращать сущность напрямую без DTO. Если 50+, это, вероятно, признак того, что нужно ввести уровень абстракции с DTO, чтобы избежать критических изменений и защитить внутренние модели.
Не перебарщивайте с DTO
Часто люди увлекаются и создают множество слоёв отображений DTO-на-DTO-на-другие-DTO. Это только добавляет сложности без реальной выгоды. Если ваши DTO и сущности почти идентичны, и вы просто копируете данные туда-сюда, это уже лишняя работа.
DTO должны служить чёткой цели, например:
- Разделение внутренних моделей данных от внешних контрактов;
- Составление данных из нескольких источников для конкретных вариантов использования;
- Добавление версионирования для публичного API.
Итого
- DTO в первую очередь предназначены для управления связями и композицией данных. Они помогают избежать раскрытия деталей внутренней реализации и позволяют формировать данные, адаптированные для конкретных потребителей.
- Не создавайте DTO просто так. Если внутренние модели и внешние потребители жёстко контролируются и ограничены, может быть удобно возвращать сущности напрямую.
- Остерегайтесь чрезмерных слоёв сопоставления. Они только добавляют ненужной сложности.
- Используйте шаблоны, вроде CQRS, чтобы по-другому думать о запросах и командах. Это помогает моделировать данные и действия таким образом, чтобы они естественным образом соответствовали DTO и композиции.
- Думайте о данных как о внутренних (частных) и внешних (публичный контракт). Такой образ мышления поможет решить, где необходимы DTO и как версионировать ваш API.
Источник: https://codeopinion.com/dtos-mapping-the-good-the-bad-and-the-excessive/
DTO и Маппинг: Хорошее, Плохое, Лишнее. Окончание
Начало
CQRS для иллюстрации DTO в действии
В CQRS вы разделяете систему на две части:
1. Запросы отвечают за извлечение и составление данных, возвращая данные, адаптированные для конкретных вариантов использования.
2. Команды отвечают за намерение и действия, такие как обновление или удаление данных.
При этом ваши ответы на запросы по сути являются DTO, которые содержат все объединённые данные, необходимые для конкретного варианта использования. Например, если вы создаёте UI для отображения сведений о заказе, DTO запроса может включать не только данные заказа, но и сведения о клиенте и доступные действия, такие как «Выполнить» или «Отменить».
Команды, с другой стороны, представляют собой конкретные действия, которые вы хотите выполнить. Вместо того чтобы думать в терминах общих операций CRUD, вы думаете в терминах команд, специфичных для домена, таких как «ОтменитьЗаказ» или «ОтметитьЗаказОплаченным». Эти команды инкапсулируют намерение и поведение, а не просто обновления данных.
CQRS не требует разных БД для команд и запросов. Он больше про то, как вы моделируете свою систему и её взаимодействия. Команды и запросы могут работать с одной БД, но представлять разные модели и DTO, адаптированные для их конкретных целей.
Размышления о DTO
1. Внешние и внутренние данные
- Внутри - данные приватные для системы, детали реализации: схема БД и модели домена.
- Снаружи - данные, предоставляемые публично: контракты API или сообщения в очереди.
Цель в сохранении конфиденциальности внутренних данных, чтобы вы могли развивать и изменять их, не влияя на внешних потребителей. Внешние данные следует рассматривать как контракт, который необходимо тщательно версионировать, поскольку вы не контролируете всех потребителей.
Если вы владеете обеими сторонами взаимодействия и можете эффективно управлять связанностью, возможно, DTO не нужны везде. Но если вы предоставляете данные внешним сторонам или хотите разделить слои, чтобы обеспечить независимую эволюцию, DTO бесценны.
2. Количество потребителей
Сколько потребителей зависят от вашей внутренней модели данных? Если всего пара, и вы хорошо управляете связью, вы можете спокойно возвращать сущность напрямую без DTO. Если 50+, это, вероятно, признак того, что нужно ввести уровень абстракции с DTO, чтобы избежать критических изменений и защитить внутренние модели.
Не перебарщивайте с DTO
Часто люди увлекаются и создают множество слоёв отображений DTO-на-DTO-на-другие-DTO. Это только добавляет сложности без реальной выгоды. Если ваши DTO и сущности почти идентичны, и вы просто копируете данные туда-сюда, это уже лишняя работа.
DTO должны служить чёткой цели, например:
- Разделение внутренних моделей данных от внешних контрактов;
- Составление данных из нескольких источников для конкретных вариантов использования;
- Добавление версионирования для публичного API.
Итого
- DTO в первую очередь предназначены для управления связями и композицией данных. Они помогают избежать раскрытия деталей внутренней реализации и позволяют формировать данные, адаптированные для конкретных потребителей.
- Не создавайте DTO просто так. Если внутренние модели и внешние потребители жёстко контролируются и ограничены, может быть удобно возвращать сущности напрямую.
- Остерегайтесь чрезмерных слоёв сопоставления. Они только добавляют ненужной сложности.
- Используйте шаблоны, вроде CQRS, чтобы по-другому думать о запросах и командах. Это помогает моделировать данные и действия таким образом, чтобы они естественным образом соответствовали DTO и композиции.
- Думайте о данных как о внутренних (частных) и внешних (публичный контракт). Такой образ мышления поможет решить, где необходимы DTO и как версионировать ваш API.
Источник: https://codeopinion.com/dtos-mapping-the-good-the-bad-and-the-excessive/
День 2320. #SystemDesign101
Прямой Прокси и Обратный Прокси
На схеме показаны различия между прямым и обратным прокси.
Прямой прокси — промежуточный сервер (программа) в компьютерных сетях, выполняющий роль посредника между пользователем и целевым сервером (при этом о посредничестве могут как знать, так и не знать обе стороны), позволяющий клиентам как выполнять косвенные запросы (принимая и передавая их через прокси-сервер) к другим сетевым сервисам, так и получать ответы.
Использование:
- доступ клиентов локальной сети к Интернет,
- кэширование и сжатие данных,
- защита локальной сети от внешнего доступа,
- обход ограничений,
- блокировка доступа к определённому контенту.
Обратный прокси ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.
Использование:
- защита и сокрытие серверов локальной сети и их характеристик,
- защита от распространенных веб-атак, таких как DoS или DDoS,
- шифрование и дешифрование SSL-сообщений,
- балансировка нагрузки между несколькими серверами,
- кэширование статического и динамического контента,
- сжатие содержимого для уменьшения времени его загрузки,
Источники:
- https://github.com/ByteByteGoHq/system-design-101
- https://ru.wikipedia.org/wiki/Прокси-сервер
- https://ru.wikipedia.org/wiki/Обратный_прокси
Прямой Прокси и Обратный Прокси
На схеме показаны различия между прямым и обратным прокси.
Прямой прокси — промежуточный сервер (программа) в компьютерных сетях, выполняющий роль посредника между пользователем и целевым сервером (при этом о посредничестве могут как знать, так и не знать обе стороны), позволяющий клиентам как выполнять косвенные запросы (принимая и передавая их через прокси-сервер) к другим сетевым сервисам, так и получать ответы.
Использование:
- доступ клиентов локальной сети к Интернет,
- кэширование и сжатие данных,
- защита локальной сети от внешнего доступа,
- обход ограничений,
- блокировка доступа к определённому контенту.
Обратный прокси ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.
Использование:
- защита и сокрытие серверов локальной сети и их характеристик,
- защита от распространенных веб-атак, таких как DoS или DDoS,
- шифрование и дешифрование SSL-сообщений,
- балансировка нагрузки между несколькими серверами,
- кэширование статического и динамического контента,
- сжатие содержимого для уменьшения времени его загрузки,
Источники:
- https://github.com/ByteByteGoHq/system-design-101
- https://ru.wikipedia.org/wiki/Прокси-сервер
- https://ru.wikipedia.org/wiki/Обратный_прокси
День 2321. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 54. Внедряя новые методы работы, делайте это мягко, но непрерывно
Никто не может по-настоящему изменить что-то, что, по мнению других, работает и даёт положительный результат. В конечном счёте каждый сам решает, готов ли он в будущем действовать иначе.
Руководство
Для того чтобы новые способы работы в организации, занимающейся разработкой ПО, внедрялись эффективно, руководители должны оказывать постоянное мягкое давление в нужном направлении. Чтобы задать желаемое направление, нужно чётко определить цели инициативы и довести их до сведения всех участников. Кроме того, они должны нести пользу бизнесу. Радикальные изменения всем даются с трудом. Постепенные изменения менее разрушительны, и к ним легче адаптироваться. Людям нужно время, чтобы усвоить новые практики и новый образ мышления.
Все участники должны понимать, какой вклад они могут внести в успех проекта. Ищите первых последователей, более восприимчивых к нововведениям, которые могут выступать в качестве пропагандистов изменений среди коллег.
Вот несколько советов, как мягко оказывать давление для достижения цели:
- Определите цели, мотивацию и основные желаемые результаты. Расплывчатые цели, такие как «до¬стичь мирового уровня» или «стать лидерами по продуктивности», бесполезны.
- Выберите метрики (ключевые показатели эффективности), которые будут показывать прогресс в достижении целей и влияние этих из¬менений на ускорение разработки, но имейте в виду, что последние показатели являются запаздывающими. Деятельность по изменению инициируется, поскольку мы уверены, что новые подходы помогут добиться лучших результатов. Однако для того, чтобы эти новые подходы повлияли на проекты, нужно время.
- Ставьте реалистичные и осмысленные цели и ожидания.
- Относитесь к изменениям как к проекту с конкретными действиями, результатами и обязанностями. Не забывайте о ресурсах. Предусмотрите дополнительное время, чтобы люди могли привыкать к новым подходам параллельно с выполнением своих обязанностей по разработке проекта.
- Регулярно информируйте о продвижении инициативы изменений.
- Призывайте людей ответственно относиться к их обязательствам по выполнению определённых мероприятий в рамках изменений.
- Стремитесь добиваться небольших успехов как можно раньше, чтобы показать, что инициатива приносит результаты.
- Обеспечьте обучение новым методам работы. Обучение — это инвестиции в будущие результаты.
Управление вышестоящими руководителями
Ценный навык для любого, кто осуществляет внедрение изменений. Если этим занимаетесь вы, научите своих руководителей говорить публично, какие модели поведения и результаты следует искать, а также какие результаты должны вознаграждаться или корректироваться. Это требует понимания корпоративной политики и умения находить подход к разным людям, представляя ценность изменений каждому руководителю так, чтобы найти у них отклик и получить поддержку.
Независимо от того, стремитесь вы к организации более зрелой модели процессов, такой как CMMI, или внедряете Agile-разработку во всей организации, руководителям важно понимать, как должны измениться их собственные действия и ожидания. Руководители, подающие пример, сами практикуют новые способы работы, публично поощряют их и посылают положительный сигнал всем остальным, что способствует изменению культуры.
Есть такое выражение: «Если вы когда-нибудь окажетесь в толпе людей, пытающихся войти туда же, куда надо и вам, просто перебирайте ногами — и толпа сама внесёт вас». То же самое верно и в отношении совершенствования процессов разработки ПО. Продолжайте двигаться в нужном направлении — и будете постепенно осваивать новые и лучшие способы работы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 54. Внедряя новые методы работы, делайте это мягко, но непрерывно
Никто не может по-настоящему изменить что-то, что, по мнению других, работает и даёт положительный результат. В конечном счёте каждый сам решает, готов ли он в будущем действовать иначе.
Руководство
Для того чтобы новые способы работы в организации, занимающейся разработкой ПО, внедрялись эффективно, руководители должны оказывать постоянное мягкое давление в нужном направлении. Чтобы задать желаемое направление, нужно чётко определить цели инициативы и довести их до сведения всех участников. Кроме того, они должны нести пользу бизнесу. Радикальные изменения всем даются с трудом. Постепенные изменения менее разрушительны, и к ним легче адаптироваться. Людям нужно время, чтобы усвоить новые практики и новый образ мышления.
Все участники должны понимать, какой вклад они могут внести в успех проекта. Ищите первых последователей, более восприимчивых к нововведениям, которые могут выступать в качестве пропагандистов изменений среди коллег.
Вот несколько советов, как мягко оказывать давление для достижения цели:
- Определите цели, мотивацию и основные желаемые результаты. Расплывчатые цели, такие как «до¬стичь мирового уровня» или «стать лидерами по продуктивности», бесполезны.
- Выберите метрики (ключевые показатели эффективности), которые будут показывать прогресс в достижении целей и влияние этих из¬менений на ускорение разработки, но имейте в виду, что последние показатели являются запаздывающими. Деятельность по изменению инициируется, поскольку мы уверены, что новые подходы помогут добиться лучших результатов. Однако для того, чтобы эти новые подходы повлияли на проекты, нужно время.
- Ставьте реалистичные и осмысленные цели и ожидания.
- Относитесь к изменениям как к проекту с конкретными действиями, результатами и обязанностями. Не забывайте о ресурсах. Предусмотрите дополнительное время, чтобы люди могли привыкать к новым подходам параллельно с выполнением своих обязанностей по разработке проекта.
- Регулярно информируйте о продвижении инициативы изменений.
- Призывайте людей ответственно относиться к их обязательствам по выполнению определённых мероприятий в рамках изменений.
- Стремитесь добиваться небольших успехов как можно раньше, чтобы показать, что инициатива приносит результаты.
- Обеспечьте обучение новым методам работы. Обучение — это инвестиции в будущие результаты.
Управление вышестоящими руководителями
Ценный навык для любого, кто осуществляет внедрение изменений. Если этим занимаетесь вы, научите своих руководителей говорить публично, какие модели поведения и результаты следует искать, а также какие результаты должны вознаграждаться или корректироваться. Это требует понимания корпоративной политики и умения находить подход к разным людям, представляя ценность изменений каждому руководителю так, чтобы найти у них отклик и получить поддержку.
Независимо от того, стремитесь вы к организации более зрелой модели процессов, такой как CMMI, или внедряете Agile-разработку во всей организации, руководителям важно понимать, как должны измениться их собственные действия и ожидания. Руководители, подающие пример, сами практикуют новые способы работы, публично поощряют их и посылают положительный сигнал всем остальным, что способствует изменению культуры.
Есть такое выражение: «Если вы когда-нибудь окажетесь в толпе людей, пытающихся войти туда же, куда надо и вам, просто перебирайте ногами — и толпа сама внесёт вас». То же самое верно и в отношении совершенствования процессов разработки ПО. Продолжайте двигаться в нужном направлении — и будете постепенно осваивать новые и лучшие способы работы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
День 2322. #ЧтоНовенького
Запись Логов по Требованию с Буферизацией. Начало
Обычно нужны подробные логи, когда что-то идёт не так, но когда всё хорошо, зачем платить за хранение логов, которые никогда не проверяются. Хотя выборка логов (log sampling) помогает сократить их объём, сохраняя только часть, иногда нужен другой подход.
Буферизация логов в .NET 9 временно сохраняет логи в памяти и позволяет позже решить, записывать ли их. Буферизация даёт контекстный контроль над тем, какие логи сохраняются на основе фактических результатов выполнения.
Концепция
Буферизация логов представляет новый шаблон потока:
1. Код генерирует логи обычным образом,
2. Нужные логи сохраняются в памяти, а не пишутся немедленно,
3. Позже, на основе определённых условий, вы решаете:
- Очистить буфер и записать все захваченные логи,
- Дать времени жизни буфера истечь, фактически отбрасывая ненужные логи.
Так, например, вы можете буферизировать подробные логи для транзакции, сохраняя их только в случае сбоя транзакции и отбрасывая в случае её успеха.
Две стратегии буферизации
.NET 9 предоставляет две стратегии буферизации: глобальная и по запросу.
1. Глобальная буферизация
Хранит логи в кольцевых буферах, общих для всего приложения. Это подходит для буферизации логов, связанных с длительными процессами или фоновыми задачами. Для базовых сценариев включите буферизацию:
Эта конфигурация буферизует все логи от уровня Information. Для более сложных сценариев определите конкретные правила:
- MaxBufferSizeInBytes – максимальный размер буфера.
- MaxLogRecordSizeInBytes – максимальный размер отдельных записей лога.
- AutoFlushDuration – как долго буферизация лога будет оставаться отключенной после запуска операции записи (flush). В примере выше буферизация будет оставаться отключенной в течение 30 секунд, что позволит приложению нормально писать все логи.
Запись глобального буфера
Чтобы записать буферизованные логи, внедрите класс GlobalLogBuffer и вызовите его метод Flush():
В этом примере подробные логи о процессе оплаты сохраняются только в случае возникновения исключения.
Окончание следует…
Источник: https://devblogs.microsoft.com/dotnet/emit-logs-on-demand-with-log-buffering/
Запись Логов по Требованию с Буферизацией. Начало
Обычно нужны подробные логи, когда что-то идёт не так, но когда всё хорошо, зачем платить за хранение логов, которые никогда не проверяются. Хотя выборка логов (log sampling) помогает сократить их объём, сохраняя только часть, иногда нужен другой подход.
Буферизация логов в .NET 9 временно сохраняет логи в памяти и позволяет позже решить, записывать ли их. Буферизация даёт контекстный контроль над тем, какие логи сохраняются на основе фактических результатов выполнения.
Концепция
Буферизация логов представляет новый шаблон потока:
1. Код генерирует логи обычным образом,
2. Нужные логи сохраняются в памяти, а не пишутся немедленно,
3. Позже, на основе определённых условий, вы решаете:
- Очистить буфер и записать все захваченные логи,
- Дать времени жизни буфера истечь, фактически отбрасывая ненужные логи.
Так, например, вы можете буферизировать подробные логи для транзакции, сохраняя их только в случае сбоя транзакции и отбрасывая в случае её успеха.
Две стратегии буферизации
.NET 9 предоставляет две стратегии буферизации: глобальная и по запросу.
1. Глобальная буферизация
Хранит логи в кольцевых буферах, общих для всего приложения. Это подходит для буферизации логов, связанных с длительными процессами или фоновыми задачами. Для базовых сценариев включите буферизацию:
builder.Logging
.AddGlobalLogBuffer(LogLevel.Information);
Эта конфигурация буферизует все логи от уровня Information. Для более сложных сценариев определите конкретные правила:
builder.Logging.AddGlobalBuffer(o =>
{
// Буферизация логов уровня Information, категории "PaymentService"
o.Rules.Add(
new LogBufferingFilterRule(
categoryName: "PaymentService",
logLevel: LogLevel.Information));
o.MaxBufferSizeInBytes = 100 * 1024 * 1024;
o.MaxLogRecordSizeInBytes = 50 * 1024;
o.AutoFlushDuration = TimeSpan.FromSeconds(30);
});
- MaxBufferSizeInBytes – максимальный размер буфера.
- MaxLogRecordSizeInBytes – максимальный размер отдельных записей лога.
- AutoFlushDuration – как долго буферизация лога будет оставаться отключенной после запуска операции записи (flush). В примере выше буферизация будет оставаться отключенной в течение 30 секунд, что позволит приложению нормально писать все логи.
Запись глобального буфера
Чтобы записать буферизованные логи, внедрите класс GlobalLogBuffer и вызовите его метод Flush():
public class PaymentService
{
private ILogger<PaymentService> _logger;
private GlobalLogBuffer _buffer;
public PaymentService(
ILogger<PaymentService> logger,
GlobalLogBuffer buffer)
{
_logger = logger;
_buffer = buffer;
}
public async Task ProcessPayment(
PaymentRequest req)
{
try
{
_logger.LogInformation(
"Старт обработки платежа для транзакции {TransId}", req.TransactionId);
// Обработка платежа...
_logger.LogInformation("Платёж обработан");
}
catch (Exception ex)
{
_logger.LogError(ex, "Сбой обработки");
// Записываем буфер для записи детальных логов
_buffer.Flush();
throw;
}
}
}
В этом примере подробные логи о процессе оплаты сохраняются только в случае возникновения исключения.
Окончание следует…
Источник: https://devblogs.microsoft.com/dotnet/emit-logs-on-demand-with-log-buffering/
День 2323. #ЧтоНовенького
Запись Логов по Требованию с Буферизацией. Окончание
Начало
2. Буферизация по запросу
Для веб-приложений ASP.NET Core буферизация по запросу обеспечивает более детальный контроль, поддерживая отдельные буферы для каждого HTTP-запроса. Подходит для отслеживания полного контекста отдельных взаимодействий пользователей.
Добавляем буферизацию по запросу:
Ключевое отличие от глобальной буферизации - когда HTTP-запрос завершается, буфер очищается и все его логи удаляются.
Очистка буфера по запросу
Чтобы выдать буферизованные логи для определённого запроса, внедрите класс PerRequestLogBuffer:
Запись (flush) буфера по запросу также записывает глобальный буфер, гарантируя, что все соответствующие логи будут записаны при возникновении ошибки.
Динамические обновления конфигурации
Если вы используете провайдер конфигурации, поддерживающий перезагрузки (например, File Configuration Provider), вы можете обновить правила буферизации без перезапуска приложения.
Это особенно ценно в производственных сценариях, где может потребоваться временно увеличить детализацию логов для диагностики проблемы, а затем вернуться к обычным уровням после её устранения.
Рекомендации
1. Стратегия буферизации
Буферизуйте подробные логи с уровня Information, но позвольте логам Error и Critical записываться немедленно. Это гарантирует, что важные проблемы всегда будут видны, а подробный контекст будет доступен только при необходимости.
2. Создайте явные триггеры записи (flush)
Определите конкретные условия, при которых контекст лога имеет значение, и добавьте явные вызовы записи:
- При исключениях или ошибках,
- Когда операции превышают ожидаемую продолжительность,
- Когда обнаружено что-то подозрительное.
3. Добавьте выборку логов для максимальной эффективности
Для приложений с большим объёмом логов используйте буферизацию и выборку:
- Фильтруйте обычные логи для уменьшения общего объёма,
- Буферизируйте подробные логи для записи контекста очистки при необходимости.
Ограничения
-.NET 9 и выше,
- Точный порядок логов может не сохраняться (временные метки сохраняются),
- Области (scope) логов не поддерживаются,
- Некоторые расширенные свойства записи логов (например, ActivitySpanId) не сохраняются.
Производительность
Буферизация логов — это компромисс между памятью и хранилищем:
- Буферизованные логи потребляют память, пока они не будут либо записаны, либо отброшены,
- Записывая логи только в определённых сценариях, вы можете радикально сократить расходы на хранение.
Для больших распределённых приложений накладные расходы памяти минимальны по сравнению с потенциальной экономией хранилища.
Источник: https://devblogs.microsoft.com/dotnet/emit-logs-on-demand-with-log-buffering/
Запись Логов по Требованию с Буферизацией. Окончание
Начало
2. Буферизация по запросу
Для веб-приложений ASP.NET Core буферизация по запросу обеспечивает более детальный контроль, поддерживая отдельные буферы для каждого HTTP-запроса. Подходит для отслеживания полного контекста отдельных взаимодействий пользователей.
Добавляем буферизацию по запросу:
builder.Services.AddPerIncomingRequestBuffer(o =>
{
// Логи Information от API контроллеров
o.Rules.Add(
new LogBufferingFilterRule(
categoryPrefix: "MyApp.Controllers",
logLevel: LogLevel.Information));
o.AutoFlushDuration = TimeSpan.FromSeconds(5);
});
Ключевое отличие от глобальной буферизации - когда HTTP-запрос завершается, буфер очищается и все его логи удаляются.
Очистка буфера по запросу
Чтобы выдать буферизованные логи для определённого запроса, внедрите класс PerRequestLogBuffer:
[ApiController]
[Route("[controller]")]
public class OrderController : ControllerBase
{
private ILogger<OrderController> _logger;
private PerRequestLogBuffer _buffer;
public OrderController(
ILogger<OrderController> logger,
PerRequestLogBuffer buffer)
{
_logger = logger;
_buffer = buffer;
}
[HttpPost]
public IActionResult CreateOrder(
OrderRequest request)
{
try
{
_logger.LogInformation("Заказ для клиента {CustomerId}", request.CustomerId);
// Обработка заказа…
_logger.LogInformation("Заказ {OrderId} создан", orderId);
return Ok(new { OrderId = orderId });
}
catch (Exception ex)
{
_logger.LogError(ex, "Сбой заказа");
_buffer.Flush();
return StatusCode(500, "Сбой создания заказа");
}
}
}
Запись (flush) буфера по запросу также записывает глобальный буфер, гарантируя, что все соответствующие логи будут записаны при возникновении ошибки.
Динамические обновления конфигурации
Если вы используете провайдер конфигурации, поддерживающий перезагрузки (например, File Configuration Provider), вы можете обновить правила буферизации без перезапуска приложения.
Это особенно ценно в производственных сценариях, где может потребоваться временно увеличить детализацию логов для диагностики проблемы, а затем вернуться к обычным уровням после её устранения.
Рекомендации
1. Стратегия буферизации
Буферизуйте подробные логи с уровня Information, но позвольте логам Error и Critical записываться немедленно. Это гарантирует, что важные проблемы всегда будут видны, а подробный контекст будет доступен только при необходимости.
2. Создайте явные триггеры записи (flush)
Определите конкретные условия, при которых контекст лога имеет значение, и добавьте явные вызовы записи:
- При исключениях или ошибках,
- Когда операции превышают ожидаемую продолжительность,
- Когда обнаружено что-то подозрительное.
3. Добавьте выборку логов для максимальной эффективности
Для приложений с большим объёмом логов используйте буферизацию и выборку:
- Фильтруйте обычные логи для уменьшения общего объёма,
- Буферизируйте подробные логи для записи контекста очистки при необходимости.
Ограничения
-.NET 9 и выше,
- Точный порядок логов может не сохраняться (временные метки сохраняются),
- Области (scope) логов не поддерживаются,
- Некоторые расширенные свойства записи логов (например, ActivitySpanId) не сохраняются.
Производительность
Буферизация логов — это компромисс между памятью и хранилищем:
- Буферизованные логи потребляют память, пока они не будут либо записаны, либо отброшены,
- Записывая логи только в определённых сценариях, вы можете радикально сократить расходы на хранение.
Для больших распределённых приложений накладные расходы памяти минимальны по сравнению с потенциальной экономией хранилища.
Источник: https://devblogs.microsoft.com/dotnet/emit-logs-on-demand-with-log-buffering/
День 2324. #TipsAndTricks
Развенчиваем Миф Производительности SQL "Сначала Фильтр Потом JOIN"
В интернете часто можно встретить описание «трюка, повышающего производительность запросов в SQL», который звучит "Сначала Фильтр Потом JOIN". В нём утверждается, что вместо того, чтобы сначала объединять таблицы, а затем применять фильтр к результатам, нужно делать наоборот.
Например, вместо:
использовать:
Смысл в том, что БД сначала уберёт ненужные данные из одной таблицы, а потом выполнит соединение меньшего объёма, экономя время и память. Звучит логично. Но дело в том, что для современных БД этот совет не имеет смысла.
Вот пример плана выполнения (EXPLAIN ANALYZE) обоих запросов в PostgreSQL над таблицами с 10000 записями в users и 5000000 в orders.
«Неоптимальный» план запроса:
«Оптимальный» план запроса:
Как видите, планы запросов идентичны, и «оптимизация» ничего не добилась.
Основные операции:
- Последовательное сканирование (Seq Scan) таблицы orders с применением фильтра;
- Последовательное сканирование таблицы users;
- Операция хеширования (Hash) меньшей таблицы (users);
- Хеш-соединение по user_id.
Оптимизаторы запросов умнее вас
Современные БД используют стоимостную оптимизацию. Оптимизатор имеет статистику о таблицах: количество строк, распределение данных, наличие индекса, селективность столбцов и т.п. – и использует её для оценки стоимости различных стратегий выполнения. Современные БД, такие как PostgreSQL, MySQL и SQL Server, уже автоматически выполняют «выталкивание предикатов» и переупорядочивание соединений. Т.е. оба запроса переписываются по одному и тому же оптимальному плану. Поэтому ручная оптимизация в подзапрос не ускоряет работу, а просто затрудняет чтение SQL-кода.
Итого
Пишите понятный, читаемый SQL. Позвольте оптимизатору делать свою работу. В непонятных ситуациях используйте EXPLAIN ANALYZE, чтобы понять, что на самом деле делает БД и действительно ли один запрос быстрее другого.
Источник: https://www.milanjovanovic.tech/blog/debunking-the-filter-early-join-later-sql-performance-myth
Развенчиваем Миф Производительности SQL "Сначала Фильтр Потом JOIN"
В интернете часто можно встретить описание «трюка, повышающего производительность запросов в SQL», который звучит "Сначала Фильтр Потом JOIN". В нём утверждается, что вместо того, чтобы сначала объединять таблицы, а затем применять фильтр к результатам, нужно делать наоборот.
Например, вместо:
SELECT *
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.total > 500;
использовать:
SELECT *
FROM (
SELECT * FROM orders WHERE total > 500
) o
JOIN users u ON u.id = o.user_id;
Смысл в том, что БД сначала уберёт ненужные данные из одной таблицы, а потом выполнит соединение меньшего объёма, экономя время и память. Звучит логично. Но дело в том, что для современных БД этот совет не имеет смысла.
Вот пример плана выполнения (EXPLAIN ANALYZE) обоих запросов в PostgreSQL над таблицами с 10000 записями в users и 5000000 в orders.
«Неоптимальный» план запроса:
Hash Join (cost=280.00..96321.92 rows=2480444 width=27) (actual time=1.014..641.202 rows=2499245 loops=1)
Hash Cond: (o.user_id = u.id)
-> Seq Scan on orders o (cost=0.00..89528.00 rows=2480444 width=14) (actual time=0.006..368.857 rows=2499245 loops=1)
Filter: (total > '500'::numeric)
Rows Removed by Filter: 2500755
-> Hash (cost=155.00..155.00 rows=10000 width=13) (actual time=0.998..0.999 rows=10000 loops=1)
Buckets: 16384 Batches: 1 Memory Usage: 577kB
-> Seq Scan on users u (cost=0.00..155.00 rows=10000 width=13) (actual time=0.002..0.341 rows=10000 loops=1)
Planning Time: 0.121 ms
Execution Time: 685.818 ms
«Оптимальный» план запроса:
Hash Join (cost=280.00..96321.92 rows=2480444 width=27) (actual time=1.019..640.613 rows=2499245 loops=1)
Hash Cond: (orders.user_id = u.id)
-> Seq Scan on orders (cost=0.00..89528.00 rows=2480444 width=14) (actual time=0.005..368.260 rows=2499245 loops=1)
Filter: (total > '500'::numeric)
Rows Removed by Filter: 2500755
-> Hash (cost=155.00..155.00 rows=10000 width=13) (actual time=1.004..1.005 rows=10000 loops=1)
Buckets: 16384 Batches: 1 Memory Usage: 577kB
-> Seq Scan on users u (cost=0.00..155.00 rows=10000 width=13) (actual time=0.003..0.348 rows=10000 loops=1)
Planning Time: 0.118 ms
Execution Time: 685.275 ms
Как видите, планы запросов идентичны, и «оптимизация» ничего не добилась.
Основные операции:
- Последовательное сканирование (Seq Scan) таблицы orders с применением фильтра;
- Последовательное сканирование таблицы users;
- Операция хеширования (Hash) меньшей таблицы (users);
- Хеш-соединение по user_id.
Оптимизаторы запросов умнее вас
Современные БД используют стоимостную оптимизацию. Оптимизатор имеет статистику о таблицах: количество строк, распределение данных, наличие индекса, селективность столбцов и т.п. – и использует её для оценки стоимости различных стратегий выполнения. Современные БД, такие как PostgreSQL, MySQL и SQL Server, уже автоматически выполняют «выталкивание предикатов» и переупорядочивание соединений. Т.е. оба запроса переписываются по одному и тому же оптимальному плану. Поэтому ручная оптимизация в подзапрос не ускоряет работу, а просто затрудняет чтение SQL-кода.
Итого
Пишите понятный, читаемый SQL. Позвольте оптимизатору делать свою работу. В непонятных ситуациях используйте EXPLAIN ANALYZE, чтобы понять, что на самом деле делает БД и действительно ли один запрос быстрее другого.
Источник: https://www.milanjovanovic.tech/blog/debunking-the-filter-early-join-later-sql-performance-myth
День 2325. #TipsAndTricks
Не Изобретайте Велосипед — Конфигурация
Часто в различных решениях dotnet core, можно встретить код вроде следующего:
EnvironmentHelper выглядит так:
С этим кодом есть проблема. Каждый раз, когда вызывается EnvironmentHelper.IsLocal, он создаёт новый экземпляр ConfigurationBuilder и считывает
Примечание: Вообще, идея регистрировать различные реализации в зависимости от того, в какой среде исполняется код, тоже не очень, но это уже другая история.
При регистрации сервисов можно использовать перегрузку, которая даёт доступ к провайдеру сервисов:
Здесь мы извлекаем IHostEnvironment из провайдера сервисов. Но это требует регистрации как MockClient, так и ClientService, поскольку мы используем контейнер для разрешения экземпляров.
Лучшим подходом является использование построителя. Он содержит свойство Environment:
По умолчанию фреймворк устанавливает среду на основе значения переменной среды
Бонус
Если же вы не можете избавиться от текущей реализации EnvironmentHelper из-за объёма рефакторинга, можно использовать такой «костыль», чтобы хотя бы не создавать ConfigurationBuilder при каждом обращении:
Источник: https://josef.codes/dont-reinvent-the-wheel-configuration-dotnet-core/
Не Изобретайте Велосипед — Конфигурация
Часто в различных решениях dotnet core, можно встретить код вроде следующего:
// Program.cs
…
if(EnvironmentHelper.IsLocal)
services
.AddSingleton<IClient, MockClient>();
else
services
.AddSingleton<IClient, ClientService>();
…
EnvironmentHelper выглядит так:
public static class EnvironmentHelper
{
public static bool IsLocal =>
{
var config = new ConfigurationBuilder()
.AddJsonFile("appsettings.json", optional: false)
.Build();
return config.GetValue<bool>("IsDevelopmentEnvironment");
}
}
С этим кодом есть проблема. Каждый раз, когда вызывается EnvironmentHelper.IsLocal, он создаёт новый экземпляр ConfigurationBuilder и считывает
appsettings.json с диска. Код используется по всей кодовой базе. Нехорошо. Мы можем избежать этого и использовать встроенные инструменты фреймворка вместо того, чтобы придумывать собственные решения.Примечание: Вообще, идея регистрировать различные реализации в зависимости от того, в какой среде исполняется код, тоже не очень, но это уже другая история.
При регистрации сервисов можно использовать перегрузку, которая даёт доступ к провайдеру сервисов:
builder.Services
.AddSingleton<IClient>(provider =>
{
var env = provider.GetRequiredService<IHostEnvironment>();
if(env.IsDevelopment())
return provider.GetRequiredService<MockClient>();
return provider.GetRequiredService<ClientService>();
});
Здесь мы извлекаем IHostEnvironment из провайдера сервисов. Но это требует регистрации как MockClient, так и ClientService, поскольку мы используем контейнер для разрешения экземпляров.
Лучшим подходом является использование построителя. Он содержит свойство Environment:
var builder = WebApplication.CreateBuilder(args);
if(builder.Environment.IsDevelopment())
builder.Services
.AddSingleton<IClient, MockClient>();
else
builder.Services
.AddSingleton<IClient, ClientService>();
По умолчанию фреймворк устанавливает среду на основе значения переменной среды
ASPNETCORE_ENVIRONMENT/DOTNET_ENVIRONMENT, поэтому нет никакой необходимости задействовать appsettings.json вообще.Бонус
Если же вы не можете избавиться от текущей реализации EnvironmentHelper из-за объёма рефакторинга, можно использовать такой «костыль», чтобы хотя бы не создавать ConfigurationBuilder при каждом обращении:
public static class EnvironmentHelper
{
private static readonly Lazy<bool> _isLocal;
static EnvironmentHelper()
{
_isLocal = new Lazy<bool>(() => {
var config = new ConfigurationBuilder()
.AddJsonFile("appsettings.json", optional: false)
.Build();
return config.GetValue<bool>("IsDevelopmentEnvironment");
},
LazyThreadSafetyMode.ExecutionAndPublication);
}
public static bool IsLocal => _isLocal.Value;
}
Источник: https://josef.codes/dont-reinvent-the-wheel-configuration-dotnet-core/
День 2326. #SystemDesign101
Распространённые Алгоритмы Балансировки Нагрузки
Статические алгоритмы
1. Круговой Алгоритм (Round Robin)
Клиентские запросы отправляются в различные экземпляры сервисов в последовательном порядке. Сервисы обычно должны быть без сохранения состояния.
Недостаток
- Эта простейшая версия алгоритма будет эффективно работать только в сферической среде в вакууме, где все серверы обладают почти одинаковой конфигурацией, а все входящие запросы (задачи, процессы) имеют одинаковые приоритет и продолжительность.
2. Закреплённый Круговой Алгоритм (Sticky Round Robin)
Усовершенствование кругового алгоритма. Если первый запрос Алисы отправляется в сервис A, следующие запросы также отправляются в сервис A.
3. Взвешенный Круговой Алгоритм (Weighted Round Robin)
Администратор может указать вес для каждого сервиса. Сервисы с более высоким весом обрабатывают больше запросов, чем другие.
4. Хэш IP/URL
Применяет хеш-функцию к IP или URL входящих запросов. Запросы направляются в соответствующие экземпляры на основе результата хеш-функции.
Преимущества
- Постоянство сессии – алгоритм гарантирует, что запросы от одного клиента всегда попадают на один и тот же сервер.
- Облегчает кеширование данных на стороне сервера для конкретных клиентов.
Недостатки
- Если много пользователей приходят из одного диапазона IP, один сервер может быть перегружен.
- Неэффективен в средах, где IP клиентов часто меняются (мобильные сети).
- Может привести к неравномерной нагрузке, если некоторые клиенты генерируют больше трафика.
Динамические алгоритмы
5. Наименьшее Количество Соединений (Least Connections)
Новый запрос отправляется в экземпляр сервиса с наименьшим количеством одновременных подключений.
Преимущества
- Более мощные серверы естественным образом будут обрабатывать больше запросов и, следовательно, иметь больше соединений. И напротив, менее мощные серверы будут получать меньше запросов, что предотвращает их перегрузку.
- Гибкость – если один сервер начинает работать медленнее, он будет получать меньше новых запросов.
Недостатки
- Алгоритм считает все соединения одинаковыми, не учитывая, что некоторые запросы могут быть более ресурсоёмкими.
- Вновь добавленный сервер может получить слишком много запросов, т.к. изначально у него 0 соединений.
6. Наименьшее Время Ответа (Least Time)
Новый запрос отправляется в экземпляр сервиса с самым быстрым временем ответа. Аналогичный алгоритм - Наименьший объем трафика (Least Bandwidth).
Преимущества
- Учёт текущей производительности серверов и динамическая адаптация обеспечивают оптимальный баланс и наилучший пользовательский опыт.
- Хорошо работает с серверами разной мощности и приложениями с разными характеристиками.
Недостаток
- Сложность реализации – требует постоянного мониторинга и анализа производительности серверов, отсюда повышенная нагрузка на балансировщик.
Источники:
- https://github.com/ByteByteGoHq/system-design-101
- https://proglib.io/p/6-glavnyh-algoritmov-balansirovki-nagruzki-2024-08-06
Распространённые Алгоритмы Балансировки Нагрузки
Статические алгоритмы
1. Круговой Алгоритм (Round Robin)
Клиентские запросы отправляются в различные экземпляры сервисов в последовательном порядке. Сервисы обычно должны быть без сохранения состояния.
Недостаток
- Эта простейшая версия алгоритма будет эффективно работать только в сферической среде в вакууме, где все серверы обладают почти одинаковой конфигурацией, а все входящие запросы (задачи, процессы) имеют одинаковые приоритет и продолжительность.
2. Закреплённый Круговой Алгоритм (Sticky Round Robin)
Усовершенствование кругового алгоритма. Если первый запрос Алисы отправляется в сервис A, следующие запросы также отправляются в сервис A.
3. Взвешенный Круговой Алгоритм (Weighted Round Robin)
Администратор может указать вес для каждого сервиса. Сервисы с более высоким весом обрабатывают больше запросов, чем другие.
4. Хэш IP/URL
Применяет хеш-функцию к IP или URL входящих запросов. Запросы направляются в соответствующие экземпляры на основе результата хеш-функции.
Преимущества
- Постоянство сессии – алгоритм гарантирует, что запросы от одного клиента всегда попадают на один и тот же сервер.
- Облегчает кеширование данных на стороне сервера для конкретных клиентов.
Недостатки
- Если много пользователей приходят из одного диапазона IP, один сервер может быть перегружен.
- Неэффективен в средах, где IP клиентов часто меняются (мобильные сети).
- Может привести к неравномерной нагрузке, если некоторые клиенты генерируют больше трафика.
Динамические алгоритмы
5. Наименьшее Количество Соединений (Least Connections)
Новый запрос отправляется в экземпляр сервиса с наименьшим количеством одновременных подключений.
Преимущества
- Более мощные серверы естественным образом будут обрабатывать больше запросов и, следовательно, иметь больше соединений. И напротив, менее мощные серверы будут получать меньше запросов, что предотвращает их перегрузку.
- Гибкость – если один сервер начинает работать медленнее, он будет получать меньше новых запросов.
Недостатки
- Алгоритм считает все соединения одинаковыми, не учитывая, что некоторые запросы могут быть более ресурсоёмкими.
- Вновь добавленный сервер может получить слишком много запросов, т.к. изначально у него 0 соединений.
6. Наименьшее Время Ответа (Least Time)
Новый запрос отправляется в экземпляр сервиса с самым быстрым временем ответа. Аналогичный алгоритм - Наименьший объем трафика (Least Bandwidth).
Преимущества
- Учёт текущей производительности серверов и динамическая адаптация обеспечивают оптимальный баланс и наилучший пользовательский опыт.
- Хорошо работает с серверами разной мощности и приложениями с разными характеристиками.
Недостаток
- Сложность реализации – требует постоянного мониторинга и анализа производительности серверов, отсюда повышенная нагрузка на балансировщик.
Источники:
- https://github.com/ByteByteGoHq/system-design-101
- https://proglib.io/p/6-glavnyh-algoritmov-balansirovki-nagruzki-2024-08-06
День 2327. #ЧтоНовенького
Вам не Хватало Vim в Windows? Представляем Edit!
Edit — это новый текстовый редактор командной строки в Windows. Edit имеет открытый исходный код. Вы можете посмотреть код на GitHub или установить его, выполнив следующую команду:
Edit будет доступен для предварительного просмотра в программе Windows Insider в ближайшие месяцы. После этого он будет поставляться как часть Windows 11.
Как использовать?
Введите
Возможности
Edit — это небольшой, легкий текстовый редактор. Он занимает менее 250 КБ. Он пока находится на ранней стадии разработки, но у него есть несколько готовых функций:
1. Поддержка режима мыши
Пункты меню другие элементы UI поддерживают использование мыши, а также горячие клавиши.
2. Открытие нескольких файлов
Вы можете открыть несколько файлов в Edit и переключаться между ними с помощью
3. Поиск и замена
Вы можете найти и заменить текст с помощью
4. Перенос по словам
Edit поддерживает перенос по словам. Чтобы использовать перенос по словам, вы можете использовать
Зачем нам ещё один CLI-редактор?
Edit - текстовый редактор CLI по умолчанию в 64-разрядных версиях Windows. 32-разрядные версии Windows поставляются с редактором MS-DOS, но в 64-разрядных версиях редактор CLI не установлен.
В Microsoft решили, что нужен немодальный редактор для Windows (в отличие от модального редактора, в котором новым пользователям пришлось бы запоминать различные режимы работы и как переключаться между ними). К сожалению, это ограничило выбор списком редакторов, которые либо не имели собственной поддержки для Windows, либо были слишком большими, чтобы включать их в каждую версию ОС. В результате родился Edit.
Источник: https://devblogs.microsoft.com/commandline/edit-is-now-open-source/
Вам не Хватало Vim в Windows? Представляем Edit!
Edit — это новый текстовый редактор командной строки в Windows. Edit имеет открытый исходный код. Вы можете посмотреть код на GitHub или установить его, выполнив следующую команду:
winget install Microsoft.Edit
Edit будет доступен для предварительного просмотра в программе Windows Insider в ближайшие месяцы. После этого он будет поставляться как часть Windows 11.
Как использовать?
Введите
edit в командной строке или edit <your-file-name>, чтобы открыть файл. Теперь вы можете редактировать файлы непосредственно в командной строке без переключения контекста.Возможности
Edit — это небольшой, легкий текстовый редактор. Он занимает менее 250 КБ. Он пока находится на ранней стадии разработки, но у него есть несколько готовых функций:
1. Поддержка режима мыши
Пункты меню другие элементы UI поддерживают использование мыши, а также горячие клавиши.
2. Открытие нескольких файлов
Вы можете открыть несколько файлов в Edit и переключаться между ними с помощью
Ctrl+P (или щелкнув на список файлов в правом нижнем углу).3. Поиск и замена
Вы можете найти и заменить текст с помощью
Ctrl+R или выбрать Edit > Replace в меню. Также есть поддержка регистра и регулярных выражений.4. Перенос по словам
Edit поддерживает перенос по словам. Чтобы использовать перенос по словам, вы можете использовать
Alt+Z или выбрать View > Word Wrap в меню.Зачем нам ещё один CLI-редактор?
Edit - текстовый редактор CLI по умолчанию в 64-разрядных версиях Windows. 32-разрядные версии Windows поставляются с редактором MS-DOS, но в 64-разрядных версиях редактор CLI не установлен.
В Microsoft решили, что нужен немодальный редактор для Windows (в отличие от модального редактора, в котором новым пользователям пришлось бы запоминать различные режимы работы и как переключаться между ними). К сожалению, это ограничило выбор списком редакторов, которые либо не имели собственной поддержки для Windows, либо были слишком большими, чтобы включать их в каждую версию ОС. В результате родился Edit.
Источник: https://devblogs.microsoft.com/commandline/edit-is-now-open-source/