.NET *

Слой приложения persistence layer является в определённом смысле уникальным в смысле узкой направленности его функционала по сравнению с другими слоями приложения. Если рассматривать его только для работы с реляционными базами данных, то реализацию функционала слоя можно разбить на два основных варианта - с использованием ORM фреймворка и без использования ORM фреймворка. Каждый из этих вариантов можно реализовать достаточно универсальным образом.

В этой статье рассмотрен пример реализации слоя persistence layer без использования ORM фреймворка. Предлагаемое решение является простым и в тоже время достаточно универсальным для использования в языках программирования, поддерживающих объектную модель.

Перед тем как перейти к рассмотрению предложенных изменений в работе асинхронности в C#, давайте разберемся — зачем все это нужно, как устроено сейчас и какие имеются проблемы, раз разработчики начали искать способы улучшения существующей логики.

Для начала давайте поймем, а зачем вообще нам нужна асинхронность и какие проблемы она решает?

Представим какой‑то абстрактный web‑api, который ходит за данными в БД. При однопоточном синхронном выполнении следующий запрос может быть обработан только тогда, когда полностью был выполнен предыдущий, что неэффективно, т.к. вся нагрузка ложится только на 1 ядро процессора, а остальные простаивают.

Добро пожаловать на восьмой выпуск нашего дайджеста, посвящённого новостям и событиям в мире .NET! В этот раз мы расскажем про уже ожидаемые .NET 10 preview 4 и 5, новую команду dotnet run app.cs и множество интересных статей. Команда PVS-Studio рада представить вам подборку самых интересных и полезных материалов. Поехали!

Я занимаюсь разработкой уже 10 лет, большую часть времен... Так, это из прошлой статьи. Давайте заново.

Я играю в игры уже 27 лет, большую часть времени играю один, но пару раз в неделю собираюсь играть с друзьями и каждый раз, чтобы собраться, нужно пройти 10 круг опросов: кто, когда, во сколько, на сколько, во что и 1001 другой вопрос. В какой-то момент я понял, что больше так жить нельзя и решил использовать свои навыки программиста, чтобы решить эту проблему.

Я занимаюсь разработкой уже 10 лет, большую часть времени на C# и ASP.Net и взбрело мне в голову разобраться, что такое эти ваши телеграм боты и как они работают.

Спойлер: Это просто вебсервер с webhook или вообще консольное приложения с long-pooling.

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

Первое что меня удивило в примерах кода других ботов, это god метод в контроллере, который имеет несколько свитч-кейсов один в другом, а внутри ещё какие-то условные операторы. Мне сразу показалось это странным и я решил пойти по-другому пути. Типа такого, но пример не настоящий.

В нашей компании анализируются звонки менеджеров отдела продаж для оценки их эффективности, устранения недочётов и улучшения сервиса. На сегодняшний день это составляет немалый массив ручной работы, для облегчения которой мы задумали привлечь технологии искусственного интеллекта. Идея следующая: забираем записи звонков, распознаём речь (преобразовываем в текст), подключаем LLM для анализа текста, знакомимся с выводами, при необходимости (например, возникновении каких-то аномалий) контролируем происходящее вручную.

Распознавание аудио решили делать через сервис Speech2Text, пример использования API которого я и покажу в этой статье. В черновом варианте получаем примерно следующую схему работы (нас сейчас интересует прямоугольник с подписью Speech2Text connector):

CoreBus (старое название «Терминальная программа») — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII.

Ребрендинг, новые фичи и Native AOT (+ боль и разочарование).

Как-то было свободных полчаса перед встречей. Ни туда, ни сюда. Дай, думаю, сниму трейс с приложения. Вдруг что-то интересное найдётся.

А в качестве бонуса: использование var может привести к багам? Узнаем в самом конце ;)

Мы ковыряли поиск пути через A* на протяжении двух глав и при этом были сосредоточены на синтаксических изысках F#. В этой главе мы отдохнём от синтаксиса и посмотрим на то, как этот алгоритм мог бы развиваться в более функциональном стиле.

Всем привет. Я сеньор и тимлид на .NET (C#). До недавнего времени работал в Росатоме, пока там внезапно не сократили целую дирекцию по цифровизации. Так что пришлось срочно выходить на рынок, причём, впервые в моей жизни (до этого работа находила меня сама). По результатам нескольких циклов собеседований получился неплохой дневник, который я здесь привожу.

Предисловие: вот и прошел этап критики и самоопределения после публикации моей первой статьи. Теперь это уже вторая. Хотел бы сказать что первая статья не была научной публикацией и сведением графиков по GPT. Это было исследованием экспериментом таким: если человек не может изобрести AGI, то почему бы не попросить об этом LLM? Вот это как раз сейчас и делается в данной работе. Результат смотрите сами. И да это не очередной RAG как приводилось в комментариях, это становится новой парадигмой.

🧠 От Линейного Преобразования к Живому Мышлению: Критика LLM и Архитектура AGI как Субъекта

Автор: [Твоё имя или псевдоним]
Версия: 1.0 | Июль 2025

В прошлой статье мы рассмотрели теоретическую основу такого понятия как полиморфизм. Теперь же перейдем к рассмотрению что там «под капотом».

Сравнивая различный code-style в проектах, я упоминал про методы проверки коллекций на наличие элементов. Самые очевидные способы – это использование LINQ-метода Any() или сравнение свойства Count с нулем. И если вы выбрали первый вариант, то у вас могут быть проблемы. Поэтому предлагаю подробнее рассмотреть этот вопрос. Кстати, если вы выбрали второй вариант, то у вас тоже могут быть проблемы.

Вообще, эта статья — по сути краткий обзор современных инструментов логирования, которые часто используются в.NET. Но из‑за того, что настройка ELK — относительно трудоемкий процесс, весь фокус по итогу сместился в сторону использования сего стека. Я просто смирился с этим. Надеюсь, мой опыт сэкономит время и силы читателю, желающему ознакомиться с ELK.

Нет, речь не про кэш в памяти. Так было бы слишком просто. У нас сегодня будет препарирован ORM, который честно запрашивает данные у реляционной СУБД, маппит в объекты, подключает связи и отдаёт в логику приложения в виде объектов. И всё на порядки быстрее, чем прямой запрос из кода приложения.

Да, здесь есть нюанс. Об этом нюансе, а также о том, зачем я написал в пятый раз кастомный ORM и будет эта статья. Эта разработка тесно переплетена с моей личной историей, когда я переходил с одной работы на другую, а затем был уволен. Я не хочу оставлять сухой технический текст, поэтому эта статья будет скорее рассказом моей работе в этой компании.

Код в статью я старался включать по минимуму. Он точно не полный и возможно ошибочный, потому что дорабатывался по мере написания статьи. Полный и исправленный вариант будет доступен по ссылке в конце статьи.

Когда мне было 16, я устроился работать в небольшую студию. Это была по факту официальная работа: с реальными задачами, пайплайном, дедлайнами и даже большим издателем. Тогда это казалось чем-то невероятным. Игра, над которой мы работали, выглядела амбициозно. У неё были красивые промо, целевая аудитория, маркетинг — всё как у взрослых.

А в центре команды был парень, старший разработчик, которому на тот момент было 23. Для меня он был почти как герой: я только начинал, а он уже 7 лет программировал. Уверенный, спокойный, очень самостоятельный. Я всерьёз думал, что именно к этому и стоит стремиться.

Но потом к нам присоединились более опытные ребята. Разработчики, у которых за плечами были и запущенные проекты, и провальные — но главное — была реальная практика и мышление архитектора. Они сразу начали задавать вопросы: — Почему у нас 6000 строк в одном скрипте? — Почему нет нормального разделения логики? — Почему переменные называются a, b1, mainLogic, veryImportantManager?

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

🧨 А потом проект провалился. Несмотря на издателя

Это - вторая публикация в серии DDD и кодогенерация

(первая часть, вторая часть, третья часть, четвертая часть)

В этой части мы научимся получать данные через рефлексию и Roslyn в одинаковой форме.

А атрибуты из Roslyn - как объекты.

Привет! Меня зовут Арсен, я разработчик в DDPlanet и сегодня хочу поделиться нашим опытом разработки системы KPI для оценки производительности сотрудников в нашей компании. Как мы пришли к необходимости такой системы, как реализовывали первую и последующие версии и почему выбрали те или иные инструменты при разработке.

Классический ILogger.LogInformation($"User {userId}") выглядит безобидно, но на деле компилятор: формирует итоговую строку через string.Format‑like логику, боксит userId, DateTime, struct‑ы и прочее добро, а так же линкует все в object[] ради структурированных логов.

Аллокационная цена вопроса — порядка 80 Б на сообщение (плюс трансферы в LOH, если вы особо многословны).

В.NET 8 Microsoft даже вынесла отдельный раздел «high‑performance logging» и честно сказала: «Да, обычные extension‑методы логов боксят и аллоцируют»

С выходом C# 10 компилятор научился разбирать $"строка" не напрямую в string, а в handler: структуру, которая получает куски литералов и плейсхолдеры. Базовый — DefaultInterpolatedStringHandler.

Что может заставить обратить внимание на красно-чёрные деревья, и как их реализовать? Статья ответит на оба эти вопроса. Бонусом будет показано, как на основе красно-чёрного сконструировать дерево интервалов.