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

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

Простота — это тоже прогресс

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

JSON - это популярный текстовый формат, который используется для обмена данными. Он был разработан на основе JavaScript синтаксиса, но является полностью независимым от языка, что позволяет использовать его почти в любом программном окружении.

В контексте игродела JSON нередко используют для внутриигровых сохранений. Фактически мы преобразовываем экземпляры наших классов и структур в удобный формат, а далее помещаем это в файл с расширением .json

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

После прочтения большинства этих статей и нескольких лет кодинга на C# я заявляю: «ООП - это один большой обман. Никто не понимает, что это такое. Люди просто говорят какие-то умные термины, их собеседники с умным видом кивают, хотя на деле трактуют эти же термины совершенно по-разному».

И вот почему.

Привет, Хабр!

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

Всем привет, на связи Петр Никитин, frontend-разработчик Mindbox.

Mindbox — это платформа автоматизации маркетинга. Одна из задач, которую наши клиенты решают с помощью нее — запуск email-рассылок и сценариев. Чтобы облегчить им задачу и не заставлять маркетологов писать HTML-код, мы разработали конструктор рассылок: письмо собирается из готовых блоков, а содержание можно настраивать под свои задачи.

В этой статье я расскажу про процесс разработки конструктора, с какими вызовами мы сталкивались и как находили решения. Например, почему в какой-то момент мы решили, что нам тесно в рамках HTML и решили поменять способ разметки шаблонов, а для этого понадобился собственный язык на базе C# — Quokka Mindbox

За годы своего развития C# существенно эволюционировал; одна из самых мощных фич языка — это сопоставление с образцом (pattern matching).

Работая недавно над небольшим хобби-проектом, я наткнулся на такую прекрасную строку кода C#.

if (person is not null and { Age: > 18 })

{}

Выглядит изящно. Откровенно говоря, она заставила меня призадуматься.

Годами я писал проверки на null и свойства-аксессоры классическим образом:

if (person != null && person.Age > 18)

{}

Функционально? Да. Удобочитаемо? Не особо. Безопасно? Спорно, особенно когда код становится сложнее.

Я решил создать шорт YouTube об этом современном синтаксисе. Это небольшое забавное напоминание о том, что C# позволяет при помощи сопоставления с образцом комбинировать проверки на null и обращение к свойству в одно условие.

Я понятия не имел, что это короткое видео приведёт к гораздо более глубокому исследованию, и покажет мне, насколько полезно и универсально сопоставление с образцом в современном C#.

Эта фича повышает читаемость, уменьшает объём бойлерплейта и обеспечивает более выразительную обработку логики.

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

Сам себе awaiter

Здравствуйте. Меня зовут Валерий и я — кодоголиклюблю писать программы. И иногда в процессе написания программ сами собой возникают интересные истории. Об одной такой история я и хочу рассказать в этой статье.

За десять с лишним лет, прошедших с момента изобретения конструкции async/await, она стала привычной и широко используемой. В наше время мало у кого вызывает затруднение написать самому или же понять смысл написанного кем-то другим выражения типа await stream.ReadAsync(buffer,async, count) — ясно, что это — чтение из потока в некий буфер, и что программа тут отдает управление на то время, пока это чтение выполняется, чтобы по завершении чтения получить управление продолжить свое выполнение дальше.

Но что вы скажете, увидев в коде вот такое выражение: await this в одном из методов класса, совершенно не похожего на Task/ValueTask или ещё что-то, что привычно видеть после await? Не правда ли это вас смутит и уж, тем более, вы вряд ли напишете такое сами? А я однажды такое написал в здравом уме и трезвой памяти. И если вам интересно, зачем это было так написано и что за магия тут творитсякак это работает, и как вообще определить свой класс, чтобы ссылку на него можно было указать после await — читайте статью.

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

Итак, начну с собственного реноме. Меня зовут Богдан, я работаю в одном достаточно большом отечественном финтеке вот уже 7-й год и добрую половину из них занимаю позицию Java-лида в одной из интеграционных команд. За такое (относительно) длительное время в энтерпрайзе периодически приходят требования на разработку, от которых хочется или плакать, или смеяться, а то и всё вместе. Происходит это по самым разным причинам, которые мы сегодня касаться не будем. Скажу лишь, что никого не осуждаю, не пытаюсь никого принизить и наверняка сам генерировал нечто схожее, о чем пойдет речь ниже. Также стоит учесть, что мой бэкграунд преимущественно бэкендово-интеграционный, соответственно, и кейсы будут из этой области и контекста. Ну а дальше — по кейсам, по тем 7 кейсам, когда прочитав требования, внутри что-то скукоживается от отвращения либо раздается улыбка во всё лицо — у кого как.

Немного глобального контекста: проект, вокруг которого будут описаны курьезные запросы, — интеграционная шина данных, напичканная самой разной интеграционной логикой, Java-приложение, состоящее из невообразимого количества SOAP/REST-методов, шедуллеров и всяческих очередей.

Зимняя школа RISC-V — совместный проект YADRO и ведущих технических вузов России и Беларуси. В этом году зимняя школа прошла во второй раз: 12 лекций по разработке на RISC-V в январе и проектная работа с защитой в начале февраля. Далее в статье мы расскажем об итогах школы, дадим слово кураторам и начнем делиться самыми интересными проектами потока.

Для проектов мы предложили 19 тем, которые распределили по пяти вузам — СПбГУ, ИТМО (Санкт-Петербург), ННГУ (Нижний Новгород), НГУ (Новосибирск) и БГУИР (Минск). В итоге своих героев не нашла только одна тема: почти 100 студентов защитили 18 проектов. Забегая вперед, скажем: два проекта мы осветим в этой статье, а некоторые другие — в отдельных.

В этом цикле статей рассмотрим как можно легко и быстро делать на C# любые однотипные действия просто навешивая атрибуты на доменные сущности

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

В мире .NET разработки, работа с базами данных – неотъемлемая часть. Entity Framework Core (EF Core) предоставляет удобный способ взаимодействия с данными, но при работе с SQL Server, особенно в сложных сценариях, LINQ запросы могут уступать в производительности и гибкости T-SQL. Статья рассматривает эту дилемму, предлагая гибридный подход. Мы погрузимся в проблему: как эффективно использовать мощь T-SQL, не отказываясь от преимуществ EF Core? Обсудим интеграцию T-SQL через Raw SQL, Views, UDF и Stored Procedures. Раскроем лучшие практики: разделение ответственности, оптимизацию запросов, безопасность и тестирование. Поймем, как сочетать удобство ORM с производительностью SQL Server, применяя Data-Driven Design и, при необходимости, Domain-Driven Design. Статья – руководство для .NET разработчиков, стремящихся к оптимальному балансу между производительностью, гибкостью и удобством разработки при работе с SQL Server и EF Core.

Когда я начал работу над Architect of Ruin в декабре 2023 года, то решил делать её в игровом движке Bevy. Мой выбор был мотивирован собственным интересом к Rust — языку, от работы с которым я получаю много удовольствия. Ещё больше меня привлекла в этом движке модель ECS, с которой мне тоже нравится работать, а также сообщество Bevy, которое мне очень симпатично.

Поэтому стало неожиданностью то, что в январе 2025 года мы выполнили миграцию нашей игры с Rust и Bevy. Я потратил примерно шесть недель, чтобы полностью переписать игру на C#, и последние три месяца мы работаем в Unity.

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

Но мы решились на это, и в посте я объясню, почему.

В этой статье рассмотрим пример реализации .NET сервиса для работы с API Яндекс Метрики, включая авторизацию, получение данных и их синхронизацию с БД.

Рано или поздно каждый программист должен задуматься о вопросах архитектуры приложения. Архитектура это про выделение ответственностей, определение компонентов их реализующих и связей между ними. Начинается все с ответственностей, а грани тонки. Очень часто будет сложно определить где начинается одна роль и заканчивается другая, сформулировать признаки по которым мы разделяем. Человеку требуются ориентиры, точки опоры и чем проще тем лучше.

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

В этой статье мы поговорим о математических основах вращения объектов, Эйлеровых углах и проблематике их использования, а также о Кватернионах и причинах выбрать Кватернионы перед Эйлеровыми углами.

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

Привет, Хабр! Меня зовут Никита, мне 14 лет, и я владелец телеграмм канала NikitaTech Nexus. С детства мечтал создавать игры, но со временем мои амбиции выросли - теперь я планирую разрабатывать не только игры, но и серьезные десктопные приложения. В этой статье хочу поделиться своим прогрессом, текущими проектами и планами на будущее.