День 2556. #ЧтоНовенького
EF Core 10 Превращает PostgreSQL в Реляционно-Документную БД. Окончание
Начало

Когда использовать JSONB
- Гибкая схема данных
Метаданные, настройки, определения рабочих процессов, конфигурация.
- Иерархические данные
Вложенные объекты или списки, которые плохо отображаются на реляционные таблицы.
- Часто изменяющиеся данные
Динамические поля, которые изменяются без необходимости миграции.
- Полуструктурированные или внешние данные
Полезные нагрузки веб-хуков, ответы API, интеграции.
- Снепшоты
Журналы аудита, история версий, журналы изменений.

Когда НЕ использовать JSONB
- Стабильные данные основного домена
Реляционные столбцы работают быстрее и обеспечивают соблюдение ограничений.
- Связи по внешним ключам
JSONB не может обеспечить ссылочную целостность.
- Данные с множественными объединениями (JOIN)
Объединения по реляционным полям производительнее извлечений JSON.
- Нагрузки OLTP с высокой частотой записи
Обновление JSONB перезаписывает весь документ.

Правильная индексация JSONB
Без индексации запросы к JSONB быстро деградируют.
Индекс GIN (наиболее частоиспользуемый):

CREATE INDEX idx_specs_gin ON products USING gin (specs);

Индекс-выражение для определённого поля:

CREATE INDEX idx_brand ON products ((specs ->> 'Brand'));

Используйте GIN-индексы для запросов на вхождение и индексы-выражения для фильтрации по определённым ключам.

Разработка гибридной схемы (рекомендуемый подход)
Наиболее надёжные архитектуры сочетают реляционный и JSONB стили.

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

JSONB для:
- Необязательных полей,
- Динамических или специфичных для клиента атрибутов,
- Метаданных, настроек и рабочих процессов.

Пример модели

public class Product
{
  public int Id { get; set; }
  public string Category { get; set; } = null!;
  public decimal Price { get; set; }

  public Specifications Specs { get; set; } = new();
}

Это даёт вашей схеме безопасность и гибкость.

Сводка производительности
JSONB быстрее для:
- Запросов на вхождение (@>);
- Чтения целых документов;
- Запросов, избегающих нескольких объединений таблиц.

JSONB медленнее для:
- Агрегации больших наборов данных;
- Частных обновлений больших документов;
- Сложной логики объединения (JOIN);
- Запросов, требующих строгих реляционных ограничений.

Практический пример
Конфигурация EF Core:

modelBuilder.Entity<Order>(entity =>
{
  entity.ComplexProperty(o => o.Metadata, b => b.ToJson());
  entity.ComplexCollection(o => o.Items, b => b.ToJson());
});

Запрос:

var orders = await context.Orders
  .Where(o => o.Items.Any(i => i.UnitPrice > 100))
  .ToListAsync();

Массовое обновление:

await context.Orders
  .Where(o => o.Metadata.Status == "Pending")
  .ExecuteUpdateAsync(s =>
    s.SetProperty(p => p.Metadata.Status, "Processing"));

Итого
EF Core 10 наконец-то предоставляет чистый, мощный и первоклассный способ использования JSONB в PostgreSQL через сложные типы:
- Сложные типы — новый стандарт для сопоставления JSON в .NET 10;
- JSONB идеально подходит для гибких, развивающихся иерархических данных;
- ExecuteUpdate повышает производительность при обновлениях JSON;
- Используйте гибридную реляционную модель + JSONB для оптимальной архитектуры;
- JSONB — мощный инструмент, но не замена реляционному проектированию.

При разумном использовании JSONB - один из наиболее эффективных инструментов, доступных разработчикам .NET для создания современных, гибких приложений.

Источник: https://trailheadtechnology.com/ef-core-10-turns-postgresql-into-a-hybrid-relational-document-db/

День 2557. #Карьера
Топ Советов по Повышению Продуктивности. Часть 6
Части 1, 2, 3, 4, 5

6. Алиасы команд и скрипты: автоматизируйте свою мышечную память
Быстрый тест: сколько команд вы набираете каждый день?
Для большинства разработчиков это одни и те же действия: запуск сервера разработки, запуск тестов, проверка статуса Git, и т.п. Вы набираете эти команды так часто, что они прочно засели в вашей мышечной памяти.

Секрет продуктивности: каждая повторяющаяся команда — это потраченное впустую время. Не потому, что набор текста медленный (хотя это так), а потому, что каждая команда — это точка принятия решения. «Какой тут флаг? На каком порту работает приложение?» Эти микрорешения накапливаются, превращаясь в сплошную рутину. Автоматизируйте всё, что вы делаете, более двух раз.

1. Алиасы терминала
Добавьте это в ваши .zshrc или .bashrc:

# Git
alias gs='git status'
alias gp='git pull'
alias gpo='git push origin'
alias gc='git commit -m'
alias gco='git checkout'
alias gb='git branch'

# Project
alias proj='cd ~/projects'
alias work='cd ~/projects/work'
alias ..='cd ..'
alias ...='cd ../..'

# Testing
alias run='dotnet run'
alias test='dotnet test'

2. Функции для сложных команд
Когда алиасов недостаточно, пишите функции:

# Новая ветка и пуш 
gnb() {
  git checkout -b "$1"
  git push -u origin "$1"
}

# Быстрый коммит 
qc() {
  git add .
  git commit -m "$1"
  git push
}

# Создать папку и перейти в неё 
mkcd() {
  mkdir -p "$1"
  cd "$1"
}

Теперь gnb feature/new-auth создаст и запушит новую ветку одной командой.

3. Скрипты для проектов
Создайте папку scripts/ в проекте и добавьте частые команды:

#!/bin/bash
# scripts/dev-rebuild.sh

echo "Rebuilding environment…"
dotnet clean
dotnet build
dotnet test
dotnet watch run

Теперь скрипт ./scripts/dev-setup.sh пересобирает, тестирует и запускает ваше приложение.

4. Автозагрузка
Добавьте скрипт в автозагрузку ОС. В скрипт добавьте обновление ваших репозиториев, открытие браузера с багтрекером, пересборку проектов и т.п.

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

Что автоматизировать:
- Настройка и очистка среды;
- Операции с БД (сброс, заполнение, резервное копирование, восстановление);
- Рабочие процессы развёртывания;
- Генерация кода (новые компоненты, конечные точки API, тесты);
- Задачи очистки (удаление веток, очистка кэша);
- Распространённые команды отладки.

Каждый раз, когда вы вводите сложную команду во второй раз, остановитесь. Создайте алиас или скрипт. Это займет 30 секунд и принесёт дивиденды навсегда. Храните файл .aliases в репозитории и синхронизируйте его между компьютерами. Лучшие разработчики не просто печатают быстрее — они автоматизируют всё, что не требует размышлений.

Источник: https://dev.to/thebitforge/top-10-productivity-hacks-every-developer-should-know-151h

День 2558. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

19. Глобализация и локализация
«Объясните, как реализовать глобализацию и локализацию в проекте веб-сайта ASP.NET Core MVC для поддержки нескольких языков и культур?»

Хороший ответ
Глобализация и локализация являются ключевыми факторами при разработке приложений, способных поддерживать несколько языков и культурных форматов. В ASP.NET Core это включает в себя настройку сервисов и промежуточного ПО для поддержки различных культур в целях локализации контента и форматирования данных в соответствии с предпочтениями пользователя.

Для реализации локализации в проекте веб-сайта ASP.NET Core необходимо настроить сервисы в файле Program.cs, добавив поддержку локализации для различных культур:

// Чтобы использовать RequestCulture
using Microsoft.AspNetCore.Localization;

var builder = WebApplication.CreateBuilder(args);

// Добавляем сервисы локализации
builder.Services.AddLocalization(options =>
  options.ResourcesPath = "Resources");

// Настраиваем поддерживаемые культуры
string[] cultures = ["en-US", "fr-FR", "ru-RU"];
builder.Services
 .Configure<RequestLocalizationOptions>(opts =>
{
  opts.DefaultRequestCulture = 
   new RequestCulture("ru-RU ");
  opts.SupportedCultures = cultures;
  opts.SupportedUICultures = cultures;
});

var app = builder.Build();

app.UseRequestLocalization();

app.MapGet("/", (IStringLocalizer<Program> localizer) => 
  localizer["WelcomeMessage"]);

app.Run();

Далее создадим файлы ресурсов для каждого языка в каталоге Resources, назвав их <ClassName>.<Culture>.resx, например, Program.en-US.resx, Program.ru-RU.resx.

Затем внедрим IStringLocalizer в MVC-контроллеры или компоненты представления для получения локализованных строк:

public class HomeController : Controller
{
  private readonly 
   IStringLocalizer<HomeController> _localizer;

  public HomeController(
   IStringLocalizer<HomeController> localizer)
  {
    _localizer = localizer;
  }

  public IActionResult Index()
  {
    ViewData["Message"] = _localizer["HomePageWelcome"];
    return View();
  }
}

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

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

Часто встречающийся неправильный ответ
«Для поддержки нескольких языков в веб-приложении можно использовать перевод текста на стороне клиента, используя JavaScript или клиентскую библиотеку».

Почему это неправильно:
- Зависимость от клиентской стороны: Этот подход предполагает чрезмерно упрощённый метод, полагаясь исключительно на перевод на стороне клиента, что может привести к несоответствиям и не обрабатывает рендеринг на стороне сервера или форматирование данных (например, дат и чисел) должным образом.
- Игнорирование возможностей ASP.NET Core: Подход игнорирует встроенную поддержку локализации в ASP.NET Core, которая разработана для интеграции с серверной архитектурой, обеспечивая согласованное сохранение настроек локализации во всём приложении.
- Игнорирование доступности и SEO: Локализация на стороне сервера имеет решающее значение для доступности и поисковой оптимизации - областей, которые рендеринг на стороне клиента не может в полной мере учитывать.

Обычно эта ошибка возникает из-за недостаточного понимания инструментов и конфигураций, предоставляемых ASP.NET Core для обработки локализации и глобализации как на стороне клиента, так и на стороне сервера.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md