C# *

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

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

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

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

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

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

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

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

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

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

Dependency Injection (или DI) — концепция, которая настолько естественно вплелась в повседневную практику программирования, что, кажется, её игнорирование можно смело записать в список смертных грехов наравне с отсутствием контроля версии. Но почему же DI стал столь важным?

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

Теперь о цели: DI — это вовсе не про навык освоения модной технологии, а про универсальный архитектурный инструмент, понятие которого пересекается в совершенно разных экосистемах. Изучение DI в нескольких языках и средах помогает не просто улучшить понимание самой концепции, но и значительно расширяет взгляд на проектирование систем, приходит понимание, что, несмотря на разницу в синтаксисе, фундаментальные идеи стремятся к одним и тем же архитектурным целям.

Кому будет полезна эта статья? Если вы давно уже подружились с .NET с его IServiceCollection, но всегда хотели разобраться, что из себя представляют Angular Injectors, — добро пожаловать. И наоборот, если вы пишете код в TypeScript, но слово "Transient" у вас вызывает только вопросы, — прошу к прочтению. Мы разберемся, как похожие концепции адаптируются в двух разных мирах и почему их изучение в обеих экосистемах позволит вам лучше проектировать свои приложения.

Я сделал простейшую утилиту для регистрации реализаций в контейнере.

Теперь можно легко и быстро тянуть все из сборок одной командой.

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

Если интересен контекст моего баттхерта, то стоит посмотреть оригинальное видео, если же нет — можно перейти сразу сюда к моей реализации...

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

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

Это новый вариант статьи, уже выложенной на Хабре. Та статья писалась на эмоциях, сразу после первых декабрьских версий. Нынешняя — это результат трехмесячных воскресных посиделок в Visual Studio. Тут и параллельные процессы и манипуляции в js и даже примитивный шахматный движок на C#.

Думаешь, микросервисы — это сложно? В этой статье я коротко и простыми словами объясняю как написать микросервис на .NET, какие технологии использовать и как избежать типичных ошибок.

📌 Что разберем:

✅ Как правильно разделять логику: CQRS, слои приложения

✅ Какие инструменты использовать: MediatR, MassTransit, MinimalApi и др.

✅ Настройка инфраструктуры: базы данных, документирование API

✅ Практические примеры: разберем код, покажу, как все работает

Привет, Хабр! AI инструменты широко используются в разработке и других сферах, казалось бы, что ещё можно в них улучшить или добавить? Всё зависит от предметной области, в области Business Intelligence при работе с языком запросов DAX актуальными могут быть работа с мерами и создание новых мер. Рутинной задачей при этом является создание схемы данных и заполнение её данными для каждой меры, или можно использовать уже имеющуюся схему, однако при этом при переходе с одной схемы (где выполняются запросы) на другую приходится переименовывать таблицы и столбцы, сопоставлять типы данных и т. д. В связи с этим актуальным может быть инструмент для создания схемы данных для меры «на лету» и выполнения запроса с мерой, т. е. построение запроса и дашборда (концептуально, без форматирования) по мере «на лету».

В dax.do можно строить DAX запрос только для существующих схем, т. е. приходится тратить время на переименование полей и таблиц в DAX запросе при переносе написанного DAX‑запроса из dax.do.

В этой статье рассматривается решение такой проблемы — генерация схемы, связей, запроса и дашборда «на лету» (концептуально, по аналогии с отображением дашборда на основе DAX в dax.do), но только сугубо средствами AI, без реальных DAX движков. Надеюсь, такие инструменты или идеи могут быть полезны аналитикам и разработчикам для повседневной работы, если Вам интересен AI в DAX — добро пожаловать под кат :)

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

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

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

Лучший способ научиться чему‑то — научить других. Второй лучший способ научиться чему‑то — сделать это самому. Я решил объединить эти два способа и научить себя и вас программировать DeFi сервисы на Ethereum (и любых других блокчейнах, основанных на EVM — Ethereum Virtual Machine).

Мы сосредоточимся на том, как работают эти сервисы, попытаемся понять экономическую механику, которая делает их такими, какие они есть (а все DeFi основаны на экономической механике). Мы будем выяснять, разбирать, изучать и создавать основные механизмы DeFi.

Продолжение темы использования библиотеки контрактного тестирования Pact для .NET. В первой части темы были рассмотрены теория и процесс контрактного тестирования взаимодействий по HTTP.

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

В этой статье подробнее остановимся на тестировании асинхронных коммуникаций на примере RabbitMq, а также познакомимся с инструментом PactBroker.

Необходимость написания тестов каждый определяет сам для себя. Модульные и интеграционные тесты вполне могут спасти нас от ошибок, вызванных нашей забывчивостью: убрали проверку на null или удалили строку сохранения сущности в БД? Хороший тест скорее всего обратит наше внимание на эту оплошность, и мы исправим её ещё до того, как задача перейдёт в стадию тестирования.

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

Есть ли способ зафиксировать контракт, обеспечить его неизменяемость и сделать результаты тестирования наглядными для всех участников взаимодействия? Да, библиотека Pact позволяет писать кроссплатформенные контрактные тесты, в результатах которых заинтересованы сразу несколько систем.

Всем привет! Это мой первый пост на Хабре, в котором я бы хотел поделиться процессов разработки своего сервиса для публикации препринтов ScienceArchive.

Меня зовут Гаврилов Антон и я .NET бэкенд разработчик. Мне интересно изучать новые технологии и подходы к проектированию и разработке систем и приложений и относительно недавно я решил испытать свои навыки в полном цикле создания собственного веб-сервиса, которым и стал ScienceArchive.

С исходниками проекта также можно ознакомиться на GitHub.

В статье рассматриваются назначение, основные особенности и возможности Фреймворка “DBGridChart”  и OLAP – приложения “Экспресс_обработка.exe” (разработчик – Плещев В.В., http://vipuskniki.usue.ru/Docum.html - DLL, исходные тексты, описание и демонстрационные примеры).

Фреймворк ориентирован на автоматизацию разработки программ на C# по формированию входных табличных и ленточных документов для ведения баз данных c СУБД SQL Server, PostgeSQL, MySQL, Access  в режиме непостоянного соединения ADO .NET и немедленного (без промежуточного накопления изменений) добавления, удаления или изменения записей с соблюдением целостности базы данных, а также для формирования заранее нерегламентированных аналитических таблиц и диаграмм для анализа данных, по унифицированной технологии (с использованием управляющих элементов  dataGridView и Chart в C#) с много функциональным, унифицированным, адаптивным и комфортным для пользователей готовым интерфейсом.

OLAP-приложение  “Экспресс_обработка.exe” позволяет: вынести описания запросов  Select из исходных текстов программ в отдельный текстовый файл, что исключает необходимость в разработке оригинальных программ для ведения баз данных с различными СУБД и формирования аналитических таблиц и диаграмм. Для формирования запросов разработан специальный визуальный конструктор.

Информация о таблицах, запросах Select и их полях берется автоматически конструктором из базы данных. Не выходя из приложения, пользователь может оперативно визуальным конструктором запросов формировать, сохранять и использовать запросы  для анализа данных и ведения базы данных. Само приложение реализовано средствами Фреймворка “DBGridChart”. 

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

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

Однако, получение данных требует постоянно висящего приложения (на C#), и надо понять что же конкретно оно делает.

Давайте разберёмся как общаться с железом и избавимся от балласта!.. Переписав на Kotlin. Почему Kotlin? Потому что я на нем никогда еще не писал.