В современном мире генерация изображений с помощью нейросетей стала возможна не только большим компаниям с суперкомпьютерами, но и рядовым пользователям с простым геймерским железом.
И возможно, кому-то захотелось не только самому пользоваться этими нейросетями, но и дать доступ к ним большому кругу людей, что может быть сопряженно с некоторыми трудностями.
В современном мире enterprise-разработки часто встречается необходимость реализации распределённых блокировок. Недавно у меня как раз возникла необходимость реализации распределённой блокировки, и я применил пакет RedLock.NET, о чём и хочу рассказать.
Однако когда я писал статью, как-то «слово за слово», она вылилась в сравнительный анализ RedLock.NET и других решений, которые я тоже рассматривал. Мне кажется, все описанные ниже очевидные и не очень решения будет вспомнить вполне уместно. Надеюсь, получится не так уж длинно и будет полезно для читателей.
Под катом вы не найдете откровений, но найдете размышления (для кого-то, возможно, очевидные) разработчика над задачей, которую все вроде знают, как реализовывать, но когда нужно реализовать, то все опять «подзабыли».
В этом гайде я покажу, как интегрировать возможности YandexGPT (в частности, генерацию текста и картинок) в ваш ASP.NET Core проект.
Дорогие гости, прошу, присаживайтесь. Сегодня в меню: DllImport по-домашнему, рагу из C# и C++, запечёные в NuGet-пакете x64 и ARM. Также будет предложена закуска в виде истории о безумствах ИИ. Bon appetit!
Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.
Pure.DI — это генератор кода для внедрения зависимостей (Dependency Injection), который работает на этапе компиляции. Pure.DI развивает идею «чистого DI»: вместо контейнера и рефлексии вы получаете обычный C#‑код, который создаёт композиции объектов. В этой статье — новые возможности, которые упрощают настройку композиций, делают корни гибче, а диагностику — понятнее.
В прошлых частях мы научились:
- делать кастомные сообщения (и поняли, что там есть подводные камни)
- использовать Custom и Must для сложной логики
Теперь новый челлендж. Проект растёт, валидаторов становится много. И вы замечаете, что одни и те же правила переезжают из класса в класс. Давайте-ка вынесем их.
Эта статья скорее всего будет полезна тем, кто продолжает разбираться или работать на платформах .NET . Предупреждаю! Здесь будет далекое плавание в разные места, и с точки ОС будет упомянуто достаточно много!
На просторах Хабра есть несколько хороших статей про устройство и поведение .NET. Мне хотелось бы стать "чем-то по связующим" между ними.
Доброго здоровья!
Предполагается, что статья будет интересна тем, кто любит четкие контракты в своих проектах, строгость и чистоту в инкапсуляции, новые подходы в ООП. А также тем, кто уважает функциональное программирование.
Эти темы и затрагиваются в предлагаемом «Elvis-модификаторе доступа», реализованным через Roslyn Analyzer. Все исходники и nuget пакеты прилагаются.
В этой статье я постарался собрать краткий гайд по Singleton, Transient и Scoped. Статья рассчитана на тех, кто хотя бы немного знаком с DI в .NET и не является полноценным туториалом.
Создание .NET приложения для аудиообработки с привлекательными SKSL-шейдерами
Давайте создадим симпатичное приложение для Android, iOS, MacCatalyst и Windows, которое будет рисоваться на холстике как Flutter, а писать мы будем на C#, как максимум - отвлечемся на синтаксис шейдеров SKSL от Гугла. Забудем, все, что мы слышали про .NET MAUI и начнем творить на Skia холсте..
3 фазы, 12 недель, 750к-1.3 млн — пошаговый фреймворк внедрения AI-агента с конкретными бюджетами, milestones и чеклистом готовности. Финальная статья серии.
Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени.
Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день.
Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.
«К Петрову лучше не ходить в пятницу после обеда» — это знает каждый в офисе. Но нигде не записано. Как передать такие знания AI-агенту: RAG, плейбуки, shadowing — с кодом на Python.
Modbus — это открытый и очень распространённый протокол обмена данными в промышленной автоматизации. Он работает по модели master–slave: мастер (например, PC-приложение) запрашивает данные у ведомого устройства (ПЛК), получая или записывая значения регистров.
На практике Modbus кажется простым — всего лишь массив 16-битных регистров. Но как только возникает задача читать типизированные переменные, поддерживать несколько проектов в одном ПЛК, минимизировать количество запросов и безопасно работать с соединением, всё быстро усложняется.
В этой статье я описываю реальный подход, который использовал для чтения и записи переменных из ПЛК и отображения их в приложении на C#.
API OpenAI лёг — что делает ваш агент? Circuit Breaker, Graceful Degradation и 5 уровней деградации. Код на Python + чеклист вопросов подрядчику.
Статья для junior‑разработчиков C#, которые хотят развиваться в профессии, но теряются в разнообразии источников знаний: книги, подкасты, видео, разборы, ChatGPT. Читать и смотреть все подряд никакой жизни не хватит, а выделить нужный базовый стэк сложно — не хватает знаний и опыта. В статье даем структуру: какие темы и по каким источникам изучать, чтобы получить необходимую базу для профессионального роста.
Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом.
Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно.
Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями.
Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими.
Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди.
В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.
Хочу поделиться проектом, который может оказаться полезным тем, кто всё ещё разрабатывает/поддерживает десктопные .NET Framework приложения на WinForms.
В моей организации - как, наверное, и во многих других - среда разработки Microsoft Visual Studio оказалась под запретом, причём как её коммерческие версии, так и Community Edition. Всем было рекомендовано перейти на VS Code, которая хороша во всём, кроме полноценной поддержки WinForms-приложений. А именно - VS Code, в отличие от "обычной" Visual Studio, не имеет встроенного редактора (дизайнера) форм, без которого вёрстка сложных форм становится как минимум неудобной. Если с редактированием "code behind" файла проблем нет (Form1.cs, UserControl1.cs), то с файлом, описывающим «визуальщину» (Form1.designer.cs, UserControl1.designer.cs) - беда: в VS Code его можно править только на уровне кода, "WYSIWYG experience" тут недоступен.
Привет, Хабр! Я магистрант первого курса по направлению «Искусственный интеллект и предиктивная аналитика» и параллельно — действующий разработчик. Пройдя несколько кругов ада собеседований, я задалась почти философским вопросом: а можно ли самостоятельно определить собственный грейд, еще и не ошибиться относительно рынка и целевой компании?
Этот вопрос стал основой моей ВКР на тему «Разработка методики определения квалификационного уровня программиста на основе мультимодального анализа».
Вместо того чтобы гадать, я решила довериться данным. Я собрала датасет из 721 вакансии стека C#/.NET и 16 различных репозиториев, прогнала их через LLM (Saiga Llama 3) и нейросеть GraphCodeBERT, чтобы найти объективные метрики «сеньорности».
По моей задумке (и уже работающему прототипу), методика позволит оценивать грейд не по лайв-кодингу, а по «цифровому следу» программиста — его репозиторию. Цель этой статьи — показать «внутреннюю кухню» исследования, поделиться первыми инсайтами о том, как нейросети видят наш код, и получить вашу обратную связь, чтобы подготовиться к главному вопросу на защите: «А зачем всё это надо?».
