⚡️ Полное руководство по Bash: от основ к продвинутым темам

Bash (Bourne Again SHell) — это одна из самых популярных Unix-оболочек, широко используемая для запуска команд и написания скриптов в Linux и macOS.

Скрипты Bash позволяют автоматизировать рутинные задачи, объединять команды в программы и управлять системой через командную строку.

Данное руководство последовательно познакомит вас с основами Bash (синтаксис, переменные, условия, циклы и т.д.), а затем перейдет к продвинутым возможностям (таким как настройка strict mode, использование trap-обработчиков, планирование задач через cron и др.). Мы рассмотрим практические примеры скриптов, сопровождая их поясняющими комментариями, чтобы у вас сложилось цельное понимание создания надежных Bash-скриптов.

https://uproger.com/polnoe-rukovodstvo-po-bash-ot-osnov-k-prodvinutym-temam/

Видео: https://www.youtube.com/watch?v=ei0a1TT4ukU

«Обзор нововведений в C# 14»

Статья от PVS-Studio на Хабре описывает, что именно добавили в C# 14 и как эти изменения делают код чище и короче.

1. Ключевое слово field
Теперь в сеттере свойства можно обращаться к скрытому полю без его явного объявления.
Это уменьшает шаблонный код и делает свойства компактнее.

Пример было:

private string _email;
public string Email
{
  get => _email;
  set => _email = value.Trim();
}

Пример стало:

public string Email
{
  get;
  set => field = value.Trim();
}

Лямбды с модификаторами без указания типа
Если в параметрах используются ref, out, in, теперь можно не писать тип.
Это улучшает читаемость и уменьшает шум.

Было:

(value, out string error) => ...

Стало:

(value, out error) => ...

Перегрузка операторов составного присваивания (+=, -=, *=, /=)
Теперь такие операторы можно перегружать напрямую, а не через комбинацию бинарного оператора и присваивания.
Это делает пользовательские типы более естественными и управляемыми.

nameof для открытых обобщённых типов
Теперь можно писать:

nameof(List<>)

Это полезно при генерации кода, рефлексии и работе с API, где нужны именно открытые generics.

C# 14 - небольшое, но важное обновление языка, направленное на упрощение синтаксиса и уменьшение шаблонного кода. Наиболее заметные улучшения - field и новые правила для лямбд.

⚡️ Полезное о блокировках в C#. Многие собеседования заваливаются именно здесь.

Коротко по сути:

lock не работает в `async`-методах.
Причина проста — выполнение может продолжиться на другом потоке, и гарантии взаимного исключения теряются.

Что использовать вместо `lock` в асинхронном коде:

- SemaphoreSlim — основной вариант
- Semaphore
- Mutex
- Monitor (в синхронных сценариях)

Правильный шаблон:

1. Всегда используйте таймаут, чтобы избежать зависаний.
2. Освобождайте ресурс в `finally`, иначе возможна утечка блокировки.

Примерный подход:

- попытаться войти с ограничением времени
- выполнить критическую секцию
- гарантированно освободить семафор

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

Вопрос для практики:
Как реализовать блокировку на уровне базы данных, чтобы синхронизировать несколько инстансов приложения?

Ответ — в разборе по distributed locking:
milanjovanovic.tech/blog/distributed-locking-in-dotnet-coordinating-work-across-multiple-instances

Крутая статья - «Building an Event Queue in ASP.NET Core» от Deepumi.

🔹 Она показывает, как правильно построить очередь событий внутри ASP.NET Core-приложения:
• использовать встроенные механизмы (middleware / DI)
• распределять события между обработчиками
• обрабатывать события асинхронно и надёжно

🔹 Такая архитектура помогает:
• реализовать decoupled компоненты, которые не знают друг о друге
• централизовать событие-поток (логика, оповещения, триггеры и т.п.)
• легче масштабировать и тестировать код

Если работаешь с ASP.NET Core и хочешь сделать систему событий - стоит заглянуть.

Подробнее: deepumi.com/blog/building-an-event-queue-in-aspnet-core.html

🚦 Feature Flags в .NET - как управлять релизами без redeploy

Feature flags (фиче-флаги) позволяют включать и выключать функциональность на лету, без повторного деплоя и риска для продакшена.

Идея простая:
код задеплоен → поведение управляется конфигурацией.

Что это даёт на практике:
— Постепенные релизы
Можно включить новую фичу сначала для 1%, 10% или конкретной группы пользователей.
— Быстрый rollback
Если что-то пошло не так — просто выключаете флаг. Без откатов и срочных хотфиксов.
— A/B тесты
Разные пользователи получают разное поведение одного и того же кода.
— Targeting пользователей

Фичи можно включать:
• по user id
• по роли
• по региону
• по environment (dev / staging / prod)

— Меньше фиче-веток
Код живёт в main, а не за флагами в git.

В .NET обычно используют:
- Microsoft.FeatureManagement
- Azure App Configuration
- LaunchDarkly / Unleash / ConfigCat

Где это особенно полезно:
- публичные API
- high-traffic сервисы
- SaaS-продукты
- экспериментальные и рискованные фичи

Коротко:
Feature flags превращают релиз из «одного опасного момента» в управляемый процесс.

Это один из самых мощных инструментов для зрелой backend-архитектуры.

👉 Подробнее

🛠 Как оживить протухшую ветку без merge-хаоса

Бывает: вы увлеклись разработкой, прошло пару недель (или месяцев), а основная ветка уже ушла далеко вперёд. В итоге — боль, конфликты и бесконечные merge-коммиты.

В таких случаях может спасати ребейз на свежую ветку:

git pull --rebase origin release/1.2.0

Она подтянет последние изменения из релизной ветки и наложит ваши коммиты поверх, сохранив линейную историю.

Конфликты всё равно придётся разруливать, но по одному — в контексте конкретного коммита, а не в гигантской свалке.

После успешного ребейза пушим с --force-with-lease, чтобы аккуратно обновить удалённую ветку, и продолжаем работать так, как будто отставания и не было.

🔥 Как правильно работать с конфигурацией в .NET

Самый чистый и масштабируемый способ получать настройки в .NET - это Options pattern.

Где живет конфигурация
Настройки приложения могут приходить из разных источников:
- переменные окружения
- JSON-файлы appsettings
- user secrets
- другие configuration providers

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

Поэтому IConfiguration напрямую лучше не использовать в бизнес-коде.

Options pattern - как правильно
Вместо этого используется Options pattern:

1. Создаешь класс настроек
- один класс = одна логическая группа конфигурации

2. Биндишь его к appsettings.json
- через services.Configure<T>

3. Используешь настройки через DI
- IOptions
- IOptionsSnapshot
- IOptionsMonitor

Плюсы подхода
- строгая типизация
- автокомплит в IDE
- централизованная конфигурация
- проще рефакторить
- можно добавить валидацию через data annotations

Например:
- [Required]
- [Range]
- [EmailAddress]

Это позволяет ловить ошибки конфигурации при старте приложения, а не в продакшене.

Важно знать
Существуют разные интерфейсы:
- IOptions - статические настройки на все время жизни приложения
- IOptionsSnapshot - обновляются на каждый запрос (scoped)
- IOptionsMonitor - отслеживают изменения конфигурации в рантайме

Понимание разницы между ними сильно влияет на корректность архитектуры.

Если пишешь production .NET - Options pattern должен быть стандартом по умолчанию.

https://www.milanjovanovic.tech/blog/how-to-use-the-options-pattern-in-asp-net-core-7

3 простые оптимизации, которые реально ускоряют код

1️⃣ Забирай данные пачкой
Меньше запросов — меньше сетевых задержек.
Вместо десятков запросов — один IN (...).

2️⃣ Делай больше параллельно
Если задачи не зависят друг от друга — выполняй их одновременно.
Асинхронность часто даёт бесплатный прирост скорости.

3️⃣ Кэшируй результаты
Если данные не меняются — не пересчитывай и не запрашивай их заново.
Память дешевле времени.

Никакой магии и сложных алгоритмов — просто базовые приёмы, которые в реальных проектах дают самый заметный эффект.

🔥 На stepik вышел курс, который учит Создавать настоящие AI-сервисы, а не просто запускать скрипты?

Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом.

Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям.

Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт.

🎁 48 часов действует скидка в 40% процентов

👉 Начать учиться на Stepik

⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга

Если в проекте 20+ endpoint’ов, app.MapGet/MapPost превращается в ад.
Решение - авторегистрировать endpoints через DI.

Идея:
1) Делаешь общий интерфейс IEndpoint
2) Каждый endpoint реализует его
3) На старте приложения сканируешь сборку, регистрируешь все реализации в DI
4) Достаёшь их из DI и вызываешь MapEndpoints()

Плюсы:
✅ чистый Program.cs
✅ каждый endpoint в отдельном файле
✅ масштабируется без хаоса
✅ легко тестировать и поддерживать

Пример паттерна:

builder.Services.AddEndpoints(typeof(Program).Assembly);

public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(this IServiceCollection services, Assembly assembly)
    {
        var endpoints = assembly.DefinedTypes
            .Where(t => !t.IsAbstract && !t.IsInterface && typeof(IEndpoint).IsAssignableFrom(t))
            .Select(t => ServiceDenoscriptor.Transient(typeof(IEndpoint), t))
            .ToArray();

        services.TryAddEnumerable(endpoints);
        return services;
    }

    public static void MapEndpoints(this WebApplication app)
    {
        foreach (var endpoint in app.Services.GetServices<IEndpoint>())
            endpoint.Map(app);
    }
}