Что нового в PostgreSQL 19?

PostgreSQL 19 продолжает одну важную тенденцию. Postgres превращается во что-то гораздо большее, чем просто реляционная база.

Самые интересные новинки:

Графовые запросы через SQL/PGQ
PostgreSQL 19 научился выполнять SQL Property Graph Queries. Теперь можно запрашивать связи прямо на SQL, без отдельной графовой базы. Пригодится для соцсетей, рекомендаций, поиска мошенничества и графов зависимостей.

GROUP BY ALL
Вместо того чтобы перечислять все колонки в GROUP BY, пишешь GROUP BY ALL. Postgres сам группирует по неагрегатным колонкам. Меньше шаблонного кода, меньше ошибок.

WAIT FOR LSN
Фича для приложений, которые используют реплики чтения. Позволяет подождать, пока реплика догонит основную базу, прежде чем читать данные. Полезно для консистентности «прочитал то, что написал».

Лучшая поддержка JSON
Postgres и дальше улучшает работу с полуструктурированными данными, не теряя при этом SQL, индексы, соединения и транзакции.

PostgreSQL 19 пока в бете. Детали могут поменяться к релизу. Но направление понятно. Postgres потихоньку становится одной платформой под всё: реляционные данные, документы, графы, аналитика и векторы для AI.

👉 @KodBlog

Мой племянник учится на втором курсе программной инженерии. Позвонил недавно, попросил помочь с поиском стажировки. И среди прочего спросил, где лучше разобраться с Git. Я удивился. На втором курсе студенты всё ещё обходят Git стороной. А потом это бьёт по ним на собеседованиях.

Я посоветовал ему отличный гайд от Beej.

Он перезвонил сегодня. Полный восторга. Делился впечатлениями. Так что вот, снова рекомендую. Для всех студентов и всех, кто только начинает знакомство с Git.

https://beej.us/guide/bggit/

👉 @KodBlog

20 законов разработки, которые должен знать каждый инженер

1. Закон Галла: Работающая сложная система вырастает из работающей простой.

2. KISS: Делай проще. Всё остальное — оверхеад.

3. Закон Конвея: Компании проектируют системы, которые повторяют структуру их коммуникаций.

4. Закон Хайрума: У достаточно большого API уже неважно, что ты обещал в контракте. Кто-нибудь уже зависит от каждого observable-поведения твоей системы.

5. CAP-теорема: Выбери два: консистентность, доступность, устойчивость к разделению.

6. Закон Завински: Любая программа разрастается до тех пор, пока не научится читать почту.

7. Закон Брукса: Добавление людей в опаздывающий проект делает его ещё более поздним.

8. Эффект Рингельмана: Производительность каждого участника группы падает с ростом группы.

9. Закон Прайса: Половину работы делают квадратный корень от всех людей.

10. Эффект Даннинга — Крюгера: Новички переоценивают свои способности, эксперты — недооценивают.

11. Закон Хофштадтера: Всё занимает больше времени, чем ты планируешь, даже с учётом этого закона.

12. Закон Паркинсона: Работа расширяется, чтобы заполнить всё отведённое на неё время.

13. Закон Гудхарта: Когда метрика становится целью, она перестаёт быть хорошей метрикой.

14. Закон Гилба: Измерять неточно лучше, чем не измерять вообще.

15. Принцип Кнута: Забудь о микрооптимизациях в 97% случаев. Преждевременная оптимизация — корень всех зол.

16. Закон Амдала: Ускорение одной части системы ограничено долей времени, которое эта часть реально используется.

17. Закон Мёрфи: Если что-то может пойти не так, оно пойдёт не так.

18. Закон Постела: Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь.

19. Закон Стерджена: 90% всего на свете — фигня.

20. Закон Каннингема: Лучший способ получить правильный ответ в интернете — не задать вопрос, а написать неправильный ответ.

👉 @KodBlog

Postgres использует эффективный по кешу и CPU алгоритм, когда за ORDER BY следует _разумный_ LIMIT. С LIMIT алгоритм сортировки может использовать всего 25кБ памяти. Без LIMIT алгоритму сортировки требуется хранить весь результирующий набор в кеше.

Логично, правда? Если бы вас попросили взять 10 самых больших камней из кучи в 100 камней, вы бы не выстраивали все камни от маленького к большому, а потом брали 10 самых больших. Вы бы отложили 10 в порядке, а затем сравнивали каждый камень с самым маленьким из этих 10 и заменяли бы его, если новый камень больше. (У вас есть возможности, которых нет у баз данных: «быстрый визуальный поиск больших объектов», операторы вроде «визуальная оценка размера» и «взять камень и сравнить ощущаемый вес».)

Это top-N heapsort (пирамидальная сортировка top-N).

При выполнении EXPLAIN ANALYZE на запросе ниже приведён пример top-N heapsort:

Sort  (cost=...) (actual time=... rows=10 loops=1)
  Sort Key: created_at DESC
  Sort Method: top-N heapsort  Memory: 25kB
  ->  Seq Scan on events  (rows=1000000 ...)

Всего 25кБ памяти? Это та маленькая кучка камней, которую вы держите в памяти, пока сканируете всю таблицу.

Без LIMIT используется quicksort (быстрая сортировка), которой нужно держать в памяти весь входной набор, отсортировать его, а затем вернуть первые N строк. Top-N heapsort поддерживает min-кучу фиксированного размера ровно из N кортежей и прогоняет через неё поток входных данных. Вычислительная сложность — O(M log N), где M — количество просканированных строк, а N — LIMIT. По сравнению с O(M log M) для полной сортировки, top-N heapsort также быстрее для CPU.

Используемая память = N × row_size (где N — LIMIT). Для LIMIT 10 со строками по 20 байт это 200 байт. Postgres округляет до минимума в 25кБ для выравнивания и служебных данных. В любом случае, для _разумного_ LIMIT сброса на диск не произойдёт независимо от размера таблицы.

А что насчёт _неразумного_ лимита?

Видели когда-нибудь URL пагинации с per_page=10? Что произойдёт, если изменить его на per_page=1000000, а приложение не валидирует ввод, и запрос получает LIMIT 1000000?

Когда лимит становится слишком большим, Postgres в конечном счёте переключается на quicksort или внешнюю сортировку слиянием (а это убийственно).

Postgres принимает решение на этапе планирования, основываясь на соотношении оценочного количества входных строк к N. Когда N приближается к числу сортируемых строк, поддержание кучи перестаёт быть выгодным, и вступает quicksort. Точная точка перехода зависит от размера строки и оценки планировщика. Ниже приведён гипотетический пример переключения планировщика с top-N heapsort на quicksort. Использование памяти — это объём памяти, занятый сортировкой, а не общее потребление памяти запросом.

LIMIT 10:       Sort Method: top-N heapsort  Memory: 25kB
LIMIT 100:      Sort Method: top-N heapsort  Memory: 30kB
LIMIT 1,000:    Sort Method: top-N heapsort  Memory: 97kB
LIMIT 10,000:   Sort Method: top-N heapsort  Memory: 914kB
LIMIT 100,000:  Sort Method: quicksort       Memory: 9,113kB

Не забывайте про индексы

Top-N heapsort — это оптимизация сортировки неиндексированного набора данных. Она всё равно требует полного последовательного сканирования входных данных. Для 10 самых последних событий среди 1M строк она каждый раз сканирует все 1M строк. Индекс по (created_at DESC) извлёк бы эти 10 строк напрямую, без сканирования всего набора данных.

👉 @KodBlog

Вот лучший способ версионировать API.

Но никто его не использует.

Слышали про версионирование через media type?

Это самый чистый подход к версионированию API.

1. Вы указываете версию API в заголовке Accept.
2. Сервер направляет запросы к соответствующему эндпоинту.

Вы не засоряете URL версиями. Это также можно расширить с помощью контент-nego.

Но версионирование API — лишь средство для достижения цели. Лучший API вообще не использует версионирование.

Вместо этого вам нужен change management.

Change management означает развитие API без неожиданностей и поломок для существующих клиентов. Вместо того чтобы сразу создавать v2, вы сначала спрашиваете: можно ли сделать изменение аддитивным, могут ли старая и новая функциональность сосуществовать, безопаснее ли новая операция, чем изменение существующей, и можно ли обработать deprecation через документацию, runtime-сигналы, миграционные гайды и телеметрию.

👉 @KodBlog

Исторический момент. Новый HTTP-метод в стандарте.

QUERY. Альтернатива GET и POST.

Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.

Только что повышен до Proposed Standard.

👉 @KodBlog

ОДИН РАЗРАБОТЧИК ЗАНОВО ПРИДУМАЛ ФОРМАТ PDF. И проблема, которую он решил, до смешного очевидна.

Банк попросил его предоставить 17 PDF-файлов для оформления ипотеки.

Он открывал их по одному.
Закрывал их по одному.
Объединял их в один файл.
Стало только хуже.

Тогда он подумал: а что, если PDF работал бы как Figma?

Горизонтальная прокрутка — между страницами.
Вертикальная — между файлами.

До него этого никто не сделал.

Поэтому он расширил стандарт PDF, добавив метаданные.
Он придумал новый формат.
Назвал его .pdfx.

Claude сделал 80% проекта за 2 часа.

В этом и разница между тем, чтобы десятилетиями жаловаться на нерешённую проблему… и однажды настолько устать от неё, что взять и исправить всё самому.

https://github.com/AlexandrosGounis/pdfx

👉 @KodBlog

Сможешь решить типичную задачу с собеседований?

Нужно понимать, как работают бинарные деревья.
Я давно с деревьями не работал — со времён университета.
Поэтому на разбор ушло несколько минут.

Вспомнил, что для обхода в ширину (Breadth-first traversal) нужна очередь, с этого и начал.
На выходе получилось: 1 2 3 4 5 6.
Значит, узлы обрабатывались в правильном порядке.

Следующий вопрос — когда печатать перевод строки.
Решил отслеживать уровень каждого узла в дереве. По мере обхода увеличивал текущий уровень.
В целом — нормальное упражнение.

В универе я бы такое сделал не задумываясь.
Это вообще имеет отношение к работе?
Может и да, но люди часто не понимают смысл.
Тут проверяют умение решать задачи.

Можешь придумать другое решение?
P.S. Постарайся не использовать ИИ для этого… ради всего, что связано с разработкой.

👉 @KodBlog

Прежде чем код можно будет переиспользовать, он должен быть пригоден к использованию.

Большинство разработчиков строят абстракции для кода, который живёт ровно в одном месте.

Один интерфейс. Одна реализация. Один вызывающий. Навсегда.

И называют это «чистым кодом».

Вот в чём ловушка →

Абстракция, построенная для переиспользования, которое никогда не наступает — не переиспользуема. Это просто лишний слой, который надо прочитать, чтобы понять, что код на самом деле делает.

📌 Сначала удобство использования. Переиспользование — то, что вы зарабатываете потом.

Самая частая пустая трата, которую я вижу:

- ❌ IThingService с одной реализацией «на всякий случай»
- ✅ Конкретный класс, который можно прочитать от начала до конца
- ❌ Общая база «для будущей гибкости», которая никогда не гнётся
- ✅ Простая прямая версия, решающая сегодняшнюю задачу
- ❌ Фабрика, оборачивающая создание одного объекта
- ✅ Внедрение объекта напрямую через DI

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

Больше файлов для открытия. Больше косвенности для трассировки. Больше догадок, зачем это существует.

👉 Честный тест перед тем, как выносить абстракцию:

1. Есть ли у меня второй или третий реальный вызывающий код прямо сейчас? (Не «может быть потом»)
2. Это делает код проще в использовании или просто даёт повод гордиться собой?
3. Сможет ли следующий разработчик разобраться в этом без моих объяснений?

Если ответ «нет» — удаляйте слой. Пишите конкретную реализацию.

Вы не теряете переиспользование.

Вы сохраняете код удобным до тех пор, пока переиспользование действительно не появится.
А когда оно появится — правильная абстракция станет очевидной, потому что у вас наконец будет два или три реальных примера, чтобы её сформировать.

Преждевременная абстракция — это сложность, за которую вы платите сегодня ради выгоды, которая может никогда не наступить.

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

👉 @KodBlog

Если хочешь стать по-настоящему сильным в .NET,
изучи следующие концепции:

1. CLR и JIT-компиляция
2. Сборка мусора (Garbage Collection)
3. Поколения памяти (Gen 0/1/2 и LOH)
4. Типы значений (Value Types) и ссылочные типы (Reference Types)
5. Boxing и Unboxing
6. Стек и куча (Stack vs Heap)
7. Span<T> и Memory<T>
8. ref struct и stackalloc
9. IDisposable и using
10. Финализаторы (Finalizers)
11. Async/Await
12. Task и ValueTask
13. SynchronizationContext
14. ConfigureAwait
15. CancellationToken
16. IAsyncEnumerable
17. Потоки и пул потоков (Threading & Thread Pool)
18. lock, Monitor и Semaphore
19. Channels
20. Parallel и PLINQ
21. LINQ и отложенное выполнение (Deferred Execution)
22. IEnumerable и IQueryable
23. Делегаты и события (Delegates & Events)
24. Func, Action и Predicate
25. Деревья выражений (Expression Trees)
26. Дженерики и ограничения (Generics & Constraints)
27. Ковариантность и контравариантность
28. Records и сопоставление с образцом (Pattern Matching)
29. Nullable Reference Types
30. Внедрение зависимостей (Dependency Injection)
31. Жизненные циклы сервисов (Scoped/Singleton/Transient)
32. Конвейер middleware (Middleware Pipeline)
33. Minimal APIs и Controllers
34. Привязка моделей и валидация (Model Binding & Validation)
35. Конфигурация и паттерн Options
36. IHostedService и BackgroundService
37. Entity Framework Core
38. Отслеживание изменений (Change Tracking)
39. Миграции (Migrations)
40. Проблема N+1
41. Пул подключений (Connection Pooling)
42. Dapper и Raw SQL
43. Кэширование (IMemoryCache и Distributed Cache)
44. Output Caching
45. Генераторы исходного кода (Source Generators)
46. Рефлексия и атрибуты (Reflection & Attributes)
47. AssemblyLoadContext
48. Native AOT
49. Бенчмаркинг (BenchmarkDotNet)
50. Профилирование памяти и настройка GC (Memory Profiling & GC Tuning)

👉 @KodBlog

Твоё .NET MAUI приложение, скорее всего, уже не только мобильное.

VisualStateManager + AdaptiveTrigger могут переключать layout, когда окно становится шире — прямо в XAML.

Без кода с SizeChanged и всей этой каши с событиями. Удобно.

Ссылка на документацию ниже.

https://learn.microsoft.com/ru-ru/dotnet/maui/fundamentals/triggers?view=net-maui-10.0#state-triggers

👉 @KodBlog

Если ты уже знал все 25 приёмов — отпишись от меня.

Почти никто не доходит до 11-го приёма по .NET.

(№23 удивил даже меня):

1. Используй async до самого низа стека вызовов. Один блокирующий .Result может привести к взаимной блокировке всей цепочки.

2. ConfigureAwait(false) нужен в библиотеках. Не в коде приложения.

3. Возвращай Task напрямую, если не используешь await. Так не создаётся лишняя state machine.

4. ValueTask подходит для горячих путей, которые обычно завершаются синхронно. Не стоит использовать его повсеместно.

5. IEnumerable — ленивый. Переберёшь его дважды — запрос выполнится дважды.

6. Здесь большинство перестаёт читать. IQueryable выполняется на стороне базы данных. IEnumerable сначала загружает всё в память.

7. Слишком ранний вызов .ToList() ломает оптимизацию фильтрации. Вызывай Where до материализации.

8. Проблема N+1 возникает незаметно. Включи логирование запросов EF Core — и увидишь её в работе.

9. Для операций чтения используй AsNoTracking(). Отслеживание изменений не бесплатно.

10. Проецируй данные в DTO через Select. Не загружай всю сущность целиком.

11. Scoped-сервис внутри Singleton — это ошибка с захваченной зависимостью, которая рано или поздно проявится.

12. Не создавай новый HttpClient для каждого запроса. Используй IHttpClientFactory.

13. Span<T> и stackalloc позволяют работать с данными без выделения памяти в куче. Нулевая нагрузка на GC.

14. В циклах используй StringBuilder вместо +=. Каждая конкатенация создаёт новую строку.

15. Предпочитай string.Create и буферы из пула, чтобы избежать скрытых выделений памяти.

16. Records подходят для неизменяемых данных. Оператор with позволяет бесплатно создавать копии с изменениями.

17. Pattern matching лучше длинных цепочек if/else. Switch-выражения читаются проще.

18. Включай nullable reference types с первого дня. Эти предупреждения — ошибки, до которых ты ещё не добрался.

19. Вместо внедрения IConfiguration используй паттерн Options. Он даёт строгую типизацию и валидацию.

20. Передавай CancellationToken во все асинхронные методы. Прокидывай его дальше по цепочке, а не игнорируй.

21. Используй BackgroundService, а не случайный Task.Run(). Пусть жизненным циклом управляет хост.

22. Сначала измеряй, потом оптимизируй. Используй BenchmarkDotNet, а не интуицию.

23. Именно это удивило меня: по умолчанию делай свои классы sealed. Это даёт JIT бесплатную возможность для оптимизации.

24. Используй Native AOT для быстрого запуска и минимального размера приложения. Убирай всё лишнее при тримминге.

25. Последнее правило — и единственное, которое действительно имеет значение: читай SQL, который генерирует EF Core. Абстракция может вводить в заблуждение, пока не посмотришь, что она создаёт.

👉 @KodBlog

Хватит использовать изменяемый Dictionary для данных, которые никогда не меняются.

Если вы строите справочные данные один раз, а читаете их часто, FrozenDictionary может подойти лучше.

Загвоздка: заморозка стоит ресурсов. Используйте его для долгоживущих справочников, а не для обычного состояния приложения.

Ссылка на документацию ниже.

https://learn.microsoft.com/ru-ru/dotnet/core/whats-new/dotnet-8/runtime#performance-focused-types

👉 @KodBlog

Почему используется Event-Driven Architecture?

Представьте систему с двумя микросервисами:
1) payments
2) emails

Когда платеж подтверждён, payments вызывает emails, чтобы отправить чек.

Но приложение растёт. Теперь нужно ещё сгенерировать счёт, обновить метрики и отправить уведомление.

Чтобы это сделать, payments начинает вызывать каждый из них.

Каждая новая функциональность добавляет ещё один вызов. Со временем такой поток становится всё сложнее поддерживать.

Event-Driven Architecture предлагает другой способ коммуникации.

Когда платеж подтверждён:
1) payments публикует событие "payment confirmed".
2) emails отправляет чек.
3) billing генерирует счёт.
4) metrics обновляет дашборды.

Если завтра вы добавите ещё один микросервис, ему просто нужно реагировать на это событие. Payments не меняется.

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

Очевидно, не всё только преимущества. Система также становится сложнее. Возникают такие проблемы, как повторные попытки, дублирующиеся события, порядок обработки и наблюдаемость.

На практике обычно используется брокер (например, Kafka или RabbitMQ), который получает событие и распределяет его по подписанным микросервисам.

👉 @KodBlog

Ваш фоновый цикл, вероятно, не нуждается в Task.Delay.

Для периодической асинхронной работы PeriodicTimer делает намерение гораздо понятнее: дождаться следующего тика, выполнить работу, повторить.

Просто помните: один потребитель за раз, диспоозьте его, передавайте токен.

Ссылка на документацию ниже.

https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.periodictimer?view=net-10.0

👉 @KodBlog