.NET *

Всем привет! Меня зовут Виктор, и я программист. Восемь лет работаю в команде Т-Банка и все это время вместе с коллегами занимаюсь проектом «Т-Телефония». Моя команда разрабатывает сервисы, которые обеспечивают голосовую коммуникацию внутри и вне банка. 

Звонки — один из основных способов связи с нами, поэтому система критична для бизнеса с высоким требованием к доступности. Она обрабатывает более 2 млн звонков в день. Если происходит сбой в любой пользовательской системе и нашим клиентам плохо, количество звонков сразу увеличивается, а нагрузка на систему повышается в два-три раза.

Когда мне прилетела первая задача с дампом, единственным инструментом, который я знал, был WinDbg. Я потратил несколько дней, чтобы хоть немного разобраться в нем. С развитием проекта приходилось все чаще снимать дампы, и теперь я знаю о них намного больше.

В статье покажу, что такое дампы, какие есть инструменты для работы с ними и какие у них особенности, покажу наши примеры проблем, расскажу, как мы их решали.

На прошлой неделе мы выпустили обновление кроссплатформенной библиотеки контролов Eremex Controls для Avalonia UI. О новых ее возможностях расскажем в этой статье, но уже в рамках нового корпоративного блога нашей компании Эремекс.

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

Небольшая статья об алгебраических типах данных и о том как их собрать в C#, где всё ещё нет нативной реализации Discriminated Unions.

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

Начинали мы с нуля, с эскизов. Задача была реализовать систему, обладающую следующими функциональными и техническими требованиями:

• поддержка разговора с абонентом в режиме реального времени
• адаптация на высокую нагрузку + масштабируемость (тысячи одновременных звонков)
• доп. фичи, в виде отправки расшифровки разговора абоненту, текстовые нотификации в телеграмм и прочее.

Мат рождается в душе. Больше всего его рождается когда сталкиваешься с чем-то похожим на <подставь свой фреймворк>. Инструмент с прекрасными целями и задачами постепенно превращается во все больший и больший кусок г.. в котором приходиться копаться. Ощущаешь себя жужжащей мухой, летающей вокруг по необходимости.

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

Сейчас все поменялось.
Подключение новой фичи чаще всего присоединяет к твоему коду 100500 дополнительных фиговин, которые мало того, что чаще не нужны, но и которые мешают запустить твой код.
Они подключаются по дефолту сами, и ты ищешь как их отключить. Но так как библиотеки постоянно меняются, это не так просто. Сколько раз подключал <подставь свой фреймворк>, ещё не разу не было одинакового кода. Постоянно меняются названия методов, их параметры, типы.

Раньше было просто. Возьмем для примера <подставь свой фреймворк>. Ты подключал и говорил ему, что нужно делать в первом случае, что во втором, что в третьем.
Сейчас же так просто не работает. Все стало сложнее. Ты указываешь доступный всем метод по старинке, но не тут то было. Клиенты получают в ответ фигу. Ты думаешь, что поменялся синтаксис, ищешь новые незадеприкейчаные методы (которых по количеству уже меньше, чем задеприкейчаных), но все равно клиенты получают фигу. Один и тот же код разрешает пользователям работать с одними запросами, но не разрешает с другими. Уверен, что это как-то объясняется. Просто подключается ещё куча бинов по дефолту, с доп параметрами по дефолту, и т.д. Идеология упрощения.
Но то, что прямо игнорируется команда разработчика, это уже перебор.

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

"Тесты должны работать на вас, а не превращать жизнь в бесконечный дебаг.
В статье — как сделать автотесты читаемыми, стабильными и предсказуемыми: Fluent API, централизованные данные, логирование, retry и философия «ошибка — это информация».
Без боли, без магии — только архитектура и здравый смысл."

Доброе утро, Хабр!

Разработка технического демо длиной в пять лет подошла к концу, а работа над полной версией The Goddess's Will обещает быть интенсивной и сложной.
Сегодня я принёс статью о базовых проблемах, с которыми мы столкнулись при производстве графики, разрабатывая современную игру в эстетике пререндера.

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

Добро пожаловать под кат. Там вас ждут кровь, пот, рендеры, а также тематические мемы и движущиеся картинки!

Работа с графикой невозможна без специальных инструментов — графических редакторов. Но что если ваш редактор вылетит прям во время работы из-за багов?

Давайте с помощью статического анализатора поищем потенциальные ошибки и странные места в исходном коде открытого проекта PixiEditor.

Всем привет, я Кирилл, и я оказался на рынке труда осенью 2025 года. Давайте разберем, почему же нам, разработчикам с большим стажем перестали приходить отклики, количество собеседований уменьшилось до нуля, а со всех сторон все HR-специалисты трубят о нехватке кадров в IT. А также рассмотрим новую боль всех HR-ов. Статья носит статистический характер, пару советов и философские высказывания автора, и немного юмора.

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

В этой статье я расскажу, как правильно создать сервис для конкурентных обновлений остатков данных в базе данных. Буду использовать .NET, C#, Entity Framework и PostgreSql.

В предыдущей статье рассмотрены основы сборки RPM пакета и автоматизации процесса.

Данная публикация завершает цикл. Продемонстрировав практическую реализацию готового решения, включая:

Разработку Web сервиса.

Регистрацию сервиса в качестве системной службы с автозагрузкой (systemd) при установке пакета.

Внедрение централизованного логирования через journald.

В результате создана полнофункциональная заготовка для быстрого развертывания сервисов с последующей публикацией их в RPM пакет.

Семейство методов Rank Fusion включает различные алгоритмы объединения нескольких ранжированных списков результатов в один улучшенный ранжированный список с целью повышения качества и надежности итогового ранжирования.

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

Rank Fusion широко применяется в информационном поиске, мультимедийном поиске, гибридных системах поиска, системах на основе модели Retrieval Augmented Generation (RAG), а также в задачах ансамблевого обучения.

В статье описан новый алгоритм семейства Rank Fusion, а может и не новый, дайте знать.

Привет! Я Алексей из команды Fiji, которая занимается внутренним продуктом для хранения и редактирования геоданных. Мы уже немного рассказывали о нем на Хабре: раз, два, три, четыре.

Наш проект активно развивается уже 10 лет, недавно ещё и команда выросла вдвое. Соответственно, почти вдвое увеличилось количество задач, а вместе с ним — и сложность интеграций с другими командами. Требования часто дополняются и меняются по ходу реализации, статьи в Confluence не всегда актуализируются, а часть информации оседает в чатах и на созвонах. Только код в мастере стабильно отражает то, что реально работает на продакшне.

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

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

В предыдущей статье "Адаптированный паттерн Command с использованием Dependency Injection", я описывал как инкапсуляция логики приложений в отдельные объекты-функции позволяет получить преимущества в архитектуре приложений.

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

Эта статья пытается исправиль допущенную автором ошибку.

Статья является дополнением к предыдущей.

Представьте команду бэкенд-разработчиков, которые привыкли писать бэкенды на .NET и немного фронтенд на Typescript + React. Это мы, ага. А теперь представьте, что этой команде прилетает задача: написать рабочее десктоп-приложение для печати этикеток.

Сложно даже подумать о таком? А с нами всё так и случилось! Сегодня расскажу, как бэкендеры писали приложение для Windows, опираясь на привычную для себя строгую структуру кода, тесты и CI/CD, и о том, что из этого получилось.

Files — это сторонний файловый менеджер для Windows. Он сделан для того, чтобы быть лучшим открытым файловым менеджером для ОС, который поддерживается сообществом. А в этой статье мы взглянем на ошибки в исходном коде Files и внесём свой вклад в open source сообщество.

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

В статье показано как совмещение Command с Dependency Injection (DI) даёт дополнительные преимущества в архитектуре приложений.

Статья будет полезна разработчикам всех уровней, а также архитекторам приложений.

В современном бизнесе интеграция фискальных регистраторов с CRM-системами перестала быть опцией — это необходимость для эффективного ведения дел. Однако существующие решения часто требуют дорогостоящего оборудования или привязывают к конкретным платформам. Мы решили эту проблему, разработав 1ОС.Касса — облачную кассу, которая объединяет преимущества онлайн и оффлайн касс.