🔥 Хотите разобраться в ASP.NET Core на практике?

Репозиторий — это более 400+ римеров для всех версий ASP.NET Core (от 2.1 до 10 Preview).

Что внутри:
- Minimal API, Blazor, SignalR, gRPC
- Аутентификация, кэширование, health-checks
- Middleware, Razor Pages, HTMX и многое другое

Каждый пример запускается командой dotnet watch run и демонстрирует отдельную фичу.

⭐ Репо собрало уже 10k+ звёзд и считается одним из лучших ресурсов для изучения ASP.NET Core.

📌 Github

Какой язык программирования имеет самый запутанный код? 🤔

Команда TIOBE проанализировала более 8 000 коммерческих проектов и 1,5 млрд строк кода, чтобы выяснить, где цикломатическая сложность (количество возможных путей выполнения функции) выше всего.

📊 Вот результаты:

1️⃣ MATLAB (6.03 пути/функция) — часто используется учёными и инженерами-доменщиками, а не разработчиками, поэтому код выходит менее структурированным.
2️⃣ C (5.74) — ручная обработка ошибок → множество if/else и условий.
3️⃣ JavaScript (3.50) — быстрая разработка, постоянно меняющиеся требования и разный уровень фронтенд-разработчиков.
4️⃣ Go (3.39) — идиоматический паттерн обработки ошибок с множеством явных проверок.
5️⃣ Python (2.71) и TypeScript (2.51) — средняя сложность, отражающая гибкий синтаксис и широкий спектр применения.
6️⃣ C++ (2.45), Java (2.24), C# (2.08) — сравнительно ниже благодаря зрелым фичам и структурированным практикам.
7️⃣ Rust (1.32) — самая низкая сложность, подчёркивающая потенциал безопасных и простых решений.

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

📌 Подробности

#программирование #разработка #код #softwareengineering

уникальных идентификаторов

Многие разработчики используют UUID (или Guid в C#) как уникальные ключи в базе данных.

📌 Проблема старых UUID:
- 🔀 они «случайные» — удобно для распределённых систем, но…
- 🧱 занимают 16 байт → таблицы и индексы раздуваются
- 📉 вызывают фрагментацию индексов, ведь данные неупорядоченные

⚡ Решение — UUID V7
- содержит компонент времени, поэтому значения сортируются
- 👉 работает быстрее с индексами
- 🔧 в .NET 9 можно создать через Guid.CreateVersion7()
- 🐘 поддержка появится в Postgres 18

Вопрос: а вы бы стали использовать UUID V7 в своих проектах?

#dotnet #postgres #uuid #database

🧠 Инструмент визуализации памяти для C++

MV — это инструмент для реального времени, который помогает понять управление памятью в C++. Он визуализирует стек и кучу, что делает его идеальным для изучения таких концепций, как указатели, утечки памяти и управление кучей.

🚀 Основные моменты:
- Визуализация работы указателей и ссылок
- Понимание различий между стеком и кучей
- Выявление и анализ утечек памяти
- Поддержка базовых концепций C++

📌 GitHub: https://github.com/humblepenguinn/mv

#cpp

Подход к реализации постоянных параметров шаблонов через библиотеку

Ранее эти параметры шаблонов назывались нетиповыми параметрами шаблонов (non-type template parameters). Но с момента появления C++98 у нас всегда было три вида параметров шаблонов:

- типовые параметры (type template parameters)
- нетиповые параметры (non-type template parameters)
- шаблонные параметры-шаблоны (template template parameters)

Когда категорий всего две, можно называть их «X» и «не-X» (например, статические и нестатические методы). Но когда категорий три — это уже неудобно. А в C++26 таких категорий уже пять (добавились параметры переменных шаблонов и параметры концептов), и выходит, что почти все, кроме типовых, попадают под «нетиповые» — что нелогично. Поэтому старый термин заменили на гораздо более удачный: constant template parameter (постоянный параметр шаблона).

Этот блогпост стал продолжением моей работы с Ричардом Смитом (P2484), за которым последовала ещё одна статья по теме (P3380). И статья, и доклад основывались на блестящей идее Файсала Вали: рефлексия может предложить интересное решение задачи сериализации, ведь std::meta::info способен представлять что угодно.

На встрече в Софии все документы, касающиеся рефлексии, были включены в рабочий проект стандарта C++26, и для меня это очень воодушевляюще — видеть формулировки прямо в черновике (например, meta.reflection).

Однако моё решение по расширению поддержки постоянных параметров шаблонов в C++26 не войдёт. Как и решение проблемы non-transient constexpr allocation. Так что ограничения на типы, которые можно использовать в качестве постоянных параметров шаблонов, сохранятся ещё на один цикл.

А может… и нет?

https://brevzin.github.io/c++/2025/08/02/ctp-reflection/

#cpp #programming

🏎️ Сравнение производительности C++20

ComPPare — это инструмент для бенчмаркинга и валидации производительности различных реализаций функций на C++20. Он позволяет сравнивать время выполнения и проверять результаты для разных платформ, таких как CPU, OpenMP и CUDA, что упрощает портирование функций.

🚀 Основные моменты:
- Заголовочный файл, легко интегрируется в проекты.
- Поддержка любых функций, работающих на хосте.
- Подробная информация о времени выполнения и накладных расходах.
- Встроенная проверка ошибок для распространенных типов данных.

📌 GitHub: https://github.com/funglf/ComPPare

#cpp

⚡ 📬 Как построить лёгкую in-memory шину сообщений на .NET Channels - отличный разбор.

В статье показано, как без внешних брокеров организовать событийную архитектуру внутри приложения, используя System.Threading.Channels. Быстро, минималистично и эффективно.

🔗 Читать здесь: milanjovanovic.tech/blog/lightweight-in-memory-message-bus-using-dotnet-channels

#dotnet #csharp #architecture #messaging #inmemory```

🎶 Библиотека для музыкальных векторов и алгоритмов

Vectors — это C++ библиотека для представления и манипуляции музыкальными структурами, такими как гаммы, аккорды и ритмы. Она предлагает мощные инструменты для музыкальных теоретиков и разработчиков, интересующихся алгоритмической музыкой.

🚀 Основные моменты:
- Унифицированные классы векторов для позиций, интервалов и бинарных паттернов
- Генераторы ритмов и мета-операторы для музыкальных объектов
- Матричные операции для анализа музыкальных структур
- Поддержка циклической и модульной арифметики
- Расчеты расстояний и схожести между музыкальными векторами

📌 GitHub: https://github.com/sivabenepoivediamo/vectors

Прочитал у Вани Ходора, бэкендера из Лавки, пост про спекулятивное исполнение. Speculative execution — это мощный паттерн, где система предугадывает ваше следующее действие, заранее выполняя вычисления или подгружая данные.

В системном мире мы с этим живём постоянно. Процессоры уже десятилетиями предсказывают ветки кода, чтобы не простаивать. И именно поэтому они такие быстрые. Однако за эту высокую скорость пришлось платить — именно такой ценой появились уязвимости вроде Spectre. Даже железо может переусердствовать с догадками.

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

Я бы сказал так:

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

В C++ подобные вещи ощущаются буквально: лишние вычисления, преждевременные аллокации, работа с кэшем — всё это цена «догадок». Если не знаешь, ради чего ускоряешь, то, скорее всего, просто сжигаешь ресурсы.

Speculative execution — крутой инструмент, но использовать его стоит только там, где задержка реально убивает UX или бизнес-метрику. В остальных случаях лучше просто сделать код лаконичным и быстрым.

🧩 Почему Databento не переписали feed-handler на Rust

Кратко:
- Контекст: реальный поток 14 млн сообщений/с и задержки <100 мкс. Требовались native-язык, простая параллельность и минимум общей памяти.
- Итог: для переписывания feed-handler выбрали C++23, а не Rust — из-за нескольких «больно на практике» паттернов.

Где Rust мешал именно под их кейс:
1) Повторное использование буфера
Хотели выделять буфер вне цикла и переиспользовать на итерациях без копий. Ссылки + времена жизни → конфликт с borrow-checker, хотя логически данные не переживают итерацию.

2) Самоссылочные структуры (self-referential structs)
Базовый паттерн «владение состоянием в объекте + подкомпоненты держат ссылки» в Rust упирается в модель заимствования. Обходные пути — RC/Arc или протаскивать ссылки аргументами — добавляют оверхед/шум. В C++ — просто порядок полей и правила перемещения/копирования.

3) Компиляционные дженерики
Шаблоны C++ гибче (partial specialization, fold-expr, constexpr). В Rust те же идеи требуют trait-интерфейсов и шаблонного «лесовоздства». На десятках версий структур получается много шаблонного кода или макросов.

Нет, это не «Rust плох»:
- У Databento уже много Rust в проде: кодеки DBN, realtime-шлюзы, клиентская библиотека. Инструменты cargo, диагностика компилятора и безопасность — огромный плюс.
- Но под данный «узкий» участок C++ дал:
кодо-реюз со старой базы, тонкий контроль ресурсов, гибкие шаблоны и прямая экспертиза команды.

Вывод:
- В их финтех-стеке оба языка уместны: Rust — где важны безопасность и современная экосистема, C++ — где критичны сам паттерн владения/памяти и совместимость с существующим кодом. Поле меняется: C++ получает compile-time reflection, Rust развивает Polonius — решения всегда прагматичны под задачу.

https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-rust