Эта статья скорее всего будет полезна тем, кто продолжает разбираться или работать на платформах .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, чтобы найти объективные метрики «сеньорности».
По моей задумке (и уже работающему прототипу), методика позволит оценивать грейд не по лайв-кодингу, а по «цифровому следу» программиста — его репозиторию. Цель этой статьи — показать «внутреннюю кухню» исследования, поделиться первыми инсайтами о том, как нейросети видят наш код, и получить вашу обратную связь, чтобы подготовиться к главному вопросу на защите: «А зачем всё это надо?».
Всем привет, с вами ваш писатель-программист и сегодня мы поговорим о такой штуке как "Архивация".
Представьте, что у вас есть таблица, в которой каждый день появляется 100 000 новых записей. Через год в ней будет 36 миллионов записей. MySQL начнет "тормозить" на сложных аналитических запросах, а удалять старые данные нельзя — они нужны для отчетности.
Решение есть! ClickHouse!
У меня были несколько иные планы на часть 3, но я понял, что читатель узнает много основ C# и теоретического материала, но реальной практики не так много. Поэтому мой изначальный план на эту статью пришлось изменить. Вектор значительно сместился на более простые, но крайне важные вещи, вроде работы с файлами, процессами и т.д., а уже в них раскрою многое из того, что хотел изначально. Ну и, чтобы не запутывать читателя, я решил сделать новую нумерацию глав. Надеюсь, вам понравится!
Когда мы говорим о сборщике мусора, мы часто ограничиваемся фразой «он удаляет неиспользуемые объекты», однако в реальности GC — это сложнейшая система, которая взаимодействует с виртуальной памятью, потоками, стеком, регистрами и графом ссылок, и без понимания этих взаимодействий невозможно осознанно писать высоконагруженные приложения. В этом материале мы сосредоточимся именно на GC, рассматривая его не как магию runtime, а как конкретный набор алгоритмов и инженерных компромиссов. За каждой строкой new, за каждой локальной переменной и за каждым вызовом функции стоит конкретная архитектура процессора, виртуальная память операционной системы и довольно агрессивная инженерная математика сборщика мусора. Чтобы действительно понимать GC, необходимо начать не с него, а с того, на чём он стоит — с регистров, стека и кучи, поскольку именно они формируют корневую модель, на которую опирается любой современный runtime.
Перед тем как мы начнем давайте разберемся в типах хранилищ памяти и как они работают:
Продолжение моей статьи Мечтают ли архитекторы об электроовцах?, в которой я обещал привести практический пример.
В прошлой главе мы доделали все ключевые моменты DSL, которые были необходимы для более-менее комфортной работы с Godot. Далее я обещал финишировать эпопею заходом в реактивное программирование, но этот блок глав было решено отложить и опубликовать отдельно.
Дело в том, что на зимних каникулах я ходил в народ и внезапно обнаружил, что в данный момент моему циклу нужно не продолжение, а хорошая пачка «чекпоинтов». Поэтому мне пришлось отложить все заряженные ружья на потом, чтобы зафиксировать текущий прогресс в виде нескольких репозиториев с очень простыми проектами. Собственно разбору этих проектов и будут посвящены оставшиеся части цикла.
Сначала мы соберём всю инфраструктуру (упомянутую в рамках цикла) на базе проекта из этой статьи. Потом несколькими способами напишем одну и ту же сцену и в конце добьём всё дело ещё щепоткой инфраструктуры, о которой я упоминал лишь поверхностно, но без которой не могу жить.
В следующий раз мы продолжим возвращением к тайловым мирам. Мне вменяли в вину, что в начале цикла я обещал не совсем то, что сделал по итогу, так что я собрал чистовую версию вот такой песочницы спецом под Хабр:
<Картинка не влезла в превью.>
Она написана с применением только тех приёмов, что уже были хотя бы надкусаны в цикле, поэтому концовка получилась очень щадящая.
В прошлой статье мы оценили, что рынок ожидает от соискателей и можем ли мы на основании этих требований дать определение грейду. Теперь я предлагаю провести небольшой эксперимент и оценить возможность определить грейд уже на практике с помощью анализа кода.
Заваривайте чай и готовьтесь к погружению: сейчас мы будем препарировать код метриками, эмбеддингами и суровой статистикой
Здравствуйте!
Цель статьи - поделиться опасениями от использования ОТЛИЧНЫХ AI-ассистентов и услышать мнение сообщества по их поводу.
Я C# разработчик, и в своей работе в 90% случаев использую VisualStudio. 50% моей работы - создание типовых RESTful сервисов для бэкэнда нашего продукта. Еще процентов 30% - работа с обработкой изображений и видео. И процентов 20% рабочего времени я трачу на различные R&D исследования разной степени сложности.
В 2023 году ChatGPT плотно захватил умы прогрессивного человечества. Мы развлекались как могли. А я в свою очередь стал использовать ChatGPT, а затем и DeepSeek для рутинных задач. Например, сгенерировать набор классов по JSON, отредачить текстовку и т.п. Работа не всегда была выполнена чисто - то напутает с типами данных, то поломает стилистику. В общем приходилось ревьювить каждую генерацию. Но в целом, это здорово помогало экономить время. К тому же мало помалу я составил идеальные промты для каждой задачи, и казалось вот оно светлое будущее.
Затем появился Copilot и часть своих задач я начал выполнять непосредственно в VS. Copilot научился нативно интегрироваться в IDE, представлял удобнейший инструмент для включения результатов своей работы в код и остальные плюшки. Коллеги, между тем, на месте не стояли и расширяли набор сценариев взаимодействия с Copilot. Да и сам Copilot предлагал все более интересные модели.
Начались шуточные разговоры про бездушную машину, замену человека и прочие шутки в этом роде. И если вы подумали, что именно этого я боялся, то нет. Точнее на данном этапе я этого совсем не боялся.
