Всем привет, с вами ваш писатель-программист и сегодня мы поговорим о такой штуке как "Архивация".
Представьте, что у вас есть таблица, в которой каждый день появляется 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 предлагал все более интересные модели.
Начались шуточные разговоры про бездушную машину, замену человека и прочие шутки в этом роде. И если вы подумали, что именно этого я боялся, то нет. Точнее на данном этапе я этого совсем не боялся.
Программа визуализирует решение и промежуточные результаты задачи Дирихле для уравнения Лапласа/Пуассона в прямоугольнике на CPU и GPU.
Уравнение Пуассона(при 
уравнение Лапласа) :
Задача Дирихле(краевые условия 1-го рода) - заданы значения 
на границе области(в данном случае в прямоугольнике).
Результаты визуализируются при помощи тепловой карты(HeatMap). Используются цвета и оттенки синего, сине-зелёного(циан), зеленого, желтого и красного цветов(от меньшего к большему значению).
Написал ИИ-оверлей для прохождения собеседований
Я — .NET-разработчик, и уже некоторое время прохожу собеседования. Иногда на них задают вопросы про такие «пыльные уголки» .NET, что если я и читал про них, то лишь в самом начале своего пути, листая книги Рихтера, Троелсена и Шилдта.
А ещё встречаются откровенно странные задачи, далёкие от реальной работы.
Зачем всё это? Очевидно, чтобы отсечь новичков из онлайн-курсов и тех, кто «вкатился» в IT без должной подготовки.
Ну а раз на собеседовании всё изначально настроено так сказать «враждебно», и интервьюер подозревает, что каждый мухлюет… почему бы действительно не начать мухлевать?
В рамках одного из обсуждении с чатах я предложил использовать функцию Merge для IAsyncEnumerable<T>, чтобы объединить результаты чтения однотипных данных из разных источников. Но когда попытался сделать пример оказалось что такой функции в System.Linq.Async нет. Есть аналог в Reactive Extensions, но тащить библиотеку для одного примера не захотел и решил написать сам.
В команде, большая часть серверных фич пишется с помощью стейт машин.
Стейт машина позволяет выразить окружающее состояние и то как с объектом можно взаимодействовать предельно конкретно. Хорошо составленный стейт граф позволяют понять как работает фича без глубокого погружения в код. При прохождении code review большое внимание уделяется составленному графу состояний. Часто возникает потребность в чтение или модификации уже существующего кода. Отсюда возникает потребность в ускорении процесса восстановления контекста или понимании как работает код.
На помощь приходит статический анализ кода.
Привет! Меня зовут Игорь, я занимаюсь разработкой на Unity c 2018 года.
В этой статье расскажу, как с помощью Roslyn можно автоматизировать задачи.
Привет, Хабр! На связи снова разработчик из компании АльфаСтрахование. Наша скрам-команда занимается автоматизацией бизнес-процессов Операционного блока, и для решения многих задач нам часто требуются фоновые операции. В этой статье я расскажу о шаблоне фонового сервиса на .NET, который мы используем в своей работе
Как вычисляется шанс того, что теннисист возьмёт следующий гейм? Или что футбольная команда забьёт гол в течение пяти минут? Всё это — не просто угадайка, а работа математической модели, построенной на статистике и обрабатывающей события матча в реальном времени.
В Altenar, разработчике решений для зарубежных операторов спортивных прогнозов, такие модели — часть большой системы. Моя команда работает над реализацией алгоритмов расчёта таких вероятностей.
В этой статье рассказываю, как формулируется гипотеза, как из неё строится модель, почему это важнее, чем «просто посчитать формулу», и как мы выбирали между несколькими .NET-библиотеками по точности и скорости. Всё на примере тенниса. Это один из самых сложных видов спорта для моделирования: стандартные подходы здесь не работают, счёт специфический, а сила игрока выражается не в счёте, а в вероятности взять очко на своей подаче.
Долгое время казалось, что 5–6 лет коммерческого опыта — это условный "безопасный уровень", после которого поиск работы перестает быть проблемой и превращается в формальность. Ты понимаешь рынок, знаешь, как проходить собеседования, и примерно представляешь, чего от тебя ждут.
За последние месяцы я столкнулся с ощущением, что эта логика больше не работает. Формально мой опыт и стек соответствуют большинству вакансий, но на практике процесс останавливается задолго до технического разговора. Эта статья — попытка разобраться, что именно изменилось и почему привычные стратегии поиска перестали давать результат.
Привет! Я Миша Симонов. Работаю в Контуре ведущим специалистом по тестированию и являюсь техлидом по автоматизации тестирования кластера из 18 команд.
Когда говорят про архитектуру UI-тестов на Selenium или Playwright, то ограничиваются объяснением паттерна Page Object Model. Но достаточно ли только знания POM в современном мире программирования?
В этой статье я постараюсь мягко провести вас от классического Page Object Model к архитектуре, основанной на композиции и Dependency Injection. Я убеждён, что написание тестов — это такое же программирование, как и разработка фич. Здесь нужны те же современные практики: DI, чистая архитектура, композиция, SOLID — всё, что делает код гибким и живучим.
Потому предлагаю рассмотреть значимые части архитектуры тестов и разобраться в том, что за зверь такой — композиция — и как его приготовить. А готовить мы будем на NUnit, Playwright на C# и Microsoft.DependencyInjection. 👨🍳
BlockingCollection<T> долгое время был стандартом для producer/consumer в .NET. Он работает, но построен на блокирующих примитивах — когда очередь пуста, читающий поток висит на Monitor.Wait(). В мире async/await это антипаттерн: заблокированный поток — потраченный ресурс.
System.Threading.Channels грамотно решил эту проблему. Lock-free структуры данных, async API, контроль backpressure, интеграция с пайплайнами обработки данных. Это не замена BlockingCollection — это просто другой уровень.
Разберём, как Channels устроены, когда их использовать, и какие паттерны они открывают.
Привет, Хабр! Меня зовут Гоша, я старший инженер-программист в Контуре. Практически любой сценарий ЭДО связан с использованием криптографии, будь то ЭДО с государством или контрагентами: где-то нужно подписать документы, где-то зашифровать архив с отчётом, где-то проверить подпись документа от контрагента. Каждый из таких сценариев хочется тестировать не на реальных данных, но на наиболее похожих в реальности. Помимо самих данных нам нужны сертификаты, имитирующие сертификаты участников ЭДО: организаций, физлиц, государственных органов. Ранее для генерации тестовых сертификатов мы использовали сервис на базе ПАК УЦ, проприетарной штуки, выпускающей сертификаты по определённым правилам, не позволяя издеваться над сроками действия серта как хочется.
Отсюда появилась идея в качестве эксперимента написать небольшой сервис, который мог бы генерировать какие угодно сертификаты с ГОСТ-алгоритмами, но при этом успешно работающие с КриптоПро. В этой статье хочу поделиться, какая техника скрывается под капотом такой функциональности.
Привет, коллеги!
Хочу поделиться подходом к логированию, который радикально упрощает архитектуру и усиливает SOLID.
Сделал пример кода GitHub, чтобы показать как работает теневое логирование (shadow decoupled logging) через события C#.
Теги: #monogame #gamedev #оптимизация #csharp #графика #индиразработка
Введение: Проблема падающих FPS и желание красоты
Каждый разработчик 2D-игр, мечтающий о живом, населённом мире, рано или поздно упирается в суровую реальность: рендеринг множества уникальных анимированных персонажей — это дорого. Хочется дать игроку кастомизацию, смену снаряжения, разнообразие врагов, но классический подход «нарисовать каждый спрайт отдельно» ведёт к сотням draw calls и падению производительности.
В своей инди-игре (симуляторе жизни в мире фэнтези-жуков) я столкнулся с этой проблемой в полный рост. Мне нужны были десятки NPC на экране, каждый — с возможной сменой брони и оружия. Решением стала гибридная система рендеринга, основанная на разделении персонажей по уровням детализации и использовании инстансинга. В статье я разберу её архитектуру, код и полученные выгоды.
Часть 1: Анализ проблемы — почему «в лоб» не работает
Допустим, у персонажа 10 слоёв: тело, голова, ноги, броня, шлем, оружие в каждой руке и т.д. Если рендерить каждый слой отдельным вызовом SpriteBatch.Draw(), для 50 NPC мы получим 50 × 10 = 500 draw calls. При целевом значении в 60 FPS у нас есть всего ~16.6 мс на кадр. Если один draw call занимает ~0.1 мс, только на отрисовку персонажей уйдёт 50 мс — это в три раза больше бюджета!
Ключевой инсайт: Не всем персонажам нужна одинаковая детализация. Фоновому горожанину или стае врагов не требуется динамическая смена снаряжения. А главному герою — требуется.
Часть 2: Гибридная архитектура — 3 уровня детализации
Вчера мы выпустили крупное обновление библиотеки EMX Controls для Avalonia UI. О новых возможностях библиотеки, а также о нашей новой программе поддержки open-source проектов мы расскажем в этой статье.
