Привет, Хабр! Меня зовут Влад Лундышев, мне 22 года, я учусь в онлайн-магистратуре ИТМО в партнёрстве с Яндекс Практикумом на направлении «Фронтенд- и бэкенд-разработка» и параллельно работаю разработчиком на Python. В статье расскажу, как я стал разработчиком, как искал свою первую работу, ещё будучи студентом бакалавриата и почему сейчас учусь на разработчика на С++.
В условиях стремительного роста объёмов интернет‑трафика особое значение приобретают высоконагруженные системы. Под этим термином понимают подкласс систем массового обслуживания, предназначенных для обработки большого числа запросов при минимальном времени отклика. Стабильность таких систем определяется их способностью сохранять работоспособность при увеличении нагрузки и обеспечивать предсказуемый рост задержек.
Для достижения требуемого уровня производительности применяется масштабирование. Его принято разделять на два основных подхода: вертикальное масштабирование, при котором увеличиваются вычислительные ресурсы отдельных узлов, и горизонтальное масштабирование, предполагающее добавление в систему дополнительных сервисов, обслуживающих запросы. Однако независимо от выбранного подхода сетевой уровень остаётся критическим фактором, влияющим на производительность. Это связано с тем, что сетевую часть невозможно масштабировать столь же гибко, как остальные компоненты системы.
Так, при вертикальном масштабировании увеличение числа процессоров ускоряет обработку запросов, но количество сетевых интерфейсов остаётся ограниченным: клиенты продолжают взаимодействовать с сетевым адресом, привязанным к конкретной сетевой карте. При горизонтальном масштабировании все запросы проходят через балансировщик нагрузки, который остаётся единственной точкой входа. В результате именно эффективность сетевой обработки может стать узким местом, нивелирующим преимущества масштабирования.
Как следствие, при проектировании высоконагруженных систем необходимо уделять особое внимание организации сетевой обработки. В моей практике эта задача особенно остро проявилась при разработке VPN‑сервиса, который можно рассматривать как типичный пример высоконагруженной системы. В статье будет показано, как применение нестандартных технических решений позволяет существенно повысить скорость сетевой обработки и, как следствие, улучшить общую производительность системы.
Обычно энтропия — мера хаоса. Но наш сегодняшний герой — IH-анализ (Information-Entropy analysis) — вычисляет информационную энтропию, чтобы измерить обратное: степень детерминированности связи между признаками и целевой переменной. Мы будем вычислять: насколько утверждение «если А, то Б, и, если не А, то и не Б» выполняется в наших данных устойчиво. Одновременная работа с категориальными и количественными признаками нас не затруднит.
Ко мне на кафедре обратились двое старшекурсников. Они пишут программу для археологов: пользователь фотографирует, что нашел, программа лезет в модель (которая натренирована на исторические архивах) и возвращает карту вероятностей, где поблизости могут лежать неметаллические артефакты, которые металлоискатель не ловит. Дерево, керамика, кость, ткань и тд. Для обучения модели им нужен был большой датасет фотографий находок времен WW2 (значки, гильзы, медали, фрагменты обмундирования) под разными углами и наклонами.
Они прикинули два варианта: либо снимать каждый предмет вручную с разных ракурсов, перетаскивая штатив или поворачивая объект пальцами, либо сначала вылепить 3D-модель каждого артефакта вручную и потом программно крутить её в виртуальной сцене под разным светом, рендеря оттуда кадры для датасета. По обоим выходило пара месяцев работы.
Я предложил собрать автоматическую поворотку. Спроектировал, напечатал, написал прошивку и питоновский скрипт. Сразу не заработало, переделал пару дней. К ночи рабочей версии я сидел за столом и каждые 12 минут жал ресет на Arduino, меняя предмет на платформе. К утру датасет был готов.
Ксения Прокофьева, руководитель отдела разработки C3D Converter, C3D Labs, рассказывает об обновлениях и перспективах развития модуля C3D Converter.
До недавнего времени модуль C3D Converter поддерживал только стандартные форматы обмена данными — SAT, STEP, Parasolid и пр. С 2020 г. началась активная работа с проприетарными форматами: изначально с использованием сторонних решений. А начиная с 2023 г. началось развитие собственных разработок (рис. 1).
Эта возможность есть в нескольких популярных языках программирования - но она настолько невостребованна, что и не все-то коллеги о ней знают - а в других не менее популярных языках её отказываются добавлять, несмотря на запросы энтузиастов. Этакий живой курьёз.
В этой коротенькой заметке-памятке - взглянем на формат записи (он может показаться не вполне логичным и не вполне шестнадцатеричным, вопреки названию) и поддержку стандарта разными языками. Основным же применением для этой "фичи" может быть, наверное - троллить друг друга на собеседованиях :)
Если вам случалось использовать такую запись на практике - поделитесь в комментариях. Или хотя бы если вы можете придумать случай когда она потенциально пригодится.
io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.
Эта статья про мои эксперименты с языковыми моделями, в которых не используется машинное обучение и аппаратное ускорение. Чтобы избежать недопонимания поясню, что я имею ввиду под языковой моделью (ЯМ).
ЯМ это совокупность алгоритмов, структур данных и собственно данных для генерации связного текста в ответ на запрос. Каким образом ЯМ генерирует ответы определяется способом её реализации. В канонической реализации ЯМ используются методы машинного обучения и мощные аппаратные ускорители. В моей реализации ЯМ я хочу получать связный текст в ответ на запрос без машинного обучения и без аппаратного ускорения.
Если свериться с Википедией на английском и на русском языках, или с многочисленными публикациями про (Large/Small) Language Models, то мои определение и понимание… несколько неканонические. Поскольку я экспериментирую для себя (я сам себе работодатель), то заранее соглашусь с любыми мнениями о неканоничности моего определения ЯМ.
Буду благодарен комментариям - если окажется, что подобное изложенному в этой статье уже было на просторах интернета. Как минимум такие подсказки избавят меня от хождения по тупикам. А как максимум, я надеюсь, позволят сделать мои дальнейшие эксперименты более успешными.
Последующий текст состоит из нескольких небольших частей. Сначала расскажу о своих мыслях, из которых возникли мои идеи для экспериментов. Далее, о своём текущем подходе к реализации ЯМ. Пока он совсем прост. Чем-то напоминает классический подходы Markov chains и n-grams, но без статистических и вероятностных методов.
Пока индустрия спорит о безопасности памяти, комитет ISO и разработчики продолжают ковать будущее любимого многими языка, мы собрали самые интересные события в мире C++ за последнее время, а также полезные материалы.
С момента публикации статьи на Хабре «Импортозамещаем numpy, pandas, scipy и sklearn» прошло почти три года. В течение этого времени я приостановил работу над проектом из-за нехватки времени, ресурсов и сил. К тому же, меня расстроило, что не смог выполнить просьбу пользователя @N-Cube, который активно интересовался моей библиотекой и хотел ускорить работу своего Jupyter Notebook.
В самый критический момент на помощь пришел волшебный AI, который, хоть и иногда проявлял недостаток гибкости, с готовностью исполнял все пожелания своего хозяина. Благодаря этому проект начал продвигаться вперед.
За это время в библиотеки были добавлены поддержка CUDA, множество ручных SIMD-оптимизаций с динамическим выбором SIMD, несколько реализаций линейной регрессии и многое другое.
Давайте рассмотрим, что на сегодняшний день позволяет сделать моя библиотека.
Я представлю несколько тестовых примеров в двух вариантах: с использованием AVX-2 на процессоре Intel® Core™ i7-4790K и AVX-512 на Intel® Xeon. Также покажу результаты замеров для каждого из них. Все тесты проводились без использования GPU, исключительно на процессоре. Это позволяет сравнивать производительность Python и моей библиотеки на равных условиях. Операционная система – Ubuntu 24.04, компилятор – GNU 13.3.0.
В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек видаLoadTexture("bark.dds"), а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы.
Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме.
Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds, которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться.
Более явный пример для шейдеров будет, когда lighting.fx, скомпилированный с дефайном SIMPLE_BUMP_MAPPING, и lighting.fx, скомпилированный с PARALLAX_BUMP_MAPPING, физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый.
С мешами история та же самая, и ship.mesh, загруженный в менеджере ресурсов, и тот же ship.mesh, лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет.
Привет, Хабр!
В этой статье я расскажу об эволюции моего проекта — GroupModerBot, бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.
Обзор будущего продукта. Distributed Occupancy Intelligence Platform - это распределённая система мониторинга и аналитики присутствия людей в зданиях и инфраструктурных объектах без использования камер и сбора персональных данных.
Мысли о нейминге приватных переменных в C++ и неочевидные моменты из стандарта, о которых легко забыть в реальном коде
Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения.
Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке.
C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С).
И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил.
Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать.
Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.
В этой статье мы на практическом примере разберём создание консольной симулятора файтинга на C++ с двумя персонажами на арене. Вы увидите, как работают основные принципы ООП: инкапсуляция, наследование и полиморфизм. Мы реализуем базовый класс Character и трёх наследников — Warrior, Orc и Magician — каждый со своими уникальными атаками, дальностью обнаружения врага и поведением (преследование / побег). Также покажем простейшую анимацию выстрелов, отрисовку карты 14×14 и игровой цикл с пошаговой логикой боя. Статья будет полезна новичкам, которые уже знакомы с синтаксисом C++ и хотят увидеть, как теория превращается в работающую игру.
Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.
Segmentation fault - одна из тех ошибок, с которой сталкивался каждый, но мало кто разбирался что за ней стоит. В этой статье копаем глубже обычного: смотрим как ядро Linux понимает что произошло, какие типы ошибки бывают - с реальными примерами и исходниками ядра Linux.
Если нужно спрятать дерево, прячьте его в лесу. Лес интернета состоит из TLS-соединений (>70% трафика, если верить статистике): вкладок браузера, WebSocket-потоков, долгоживущих HTTPS-запросов, клиентов игр, мобильных приложений, телеметрии, видеоплееров, чатов и тысяч спокойных TCP/443-соединений, которые выглядят настолько обычно, что именно это и делает их интересной средой для, кхм, исследования.
Очевидно, единственная и конечная цель существования интернета — быть распределённым хранилищем порно, так почему бы не использовать его по прямому назначению и не хранить смешные картинки прямо в трафике?
У меня есть книга, которая называется Game++ и несколько статей, где я разбирал какие паттерны применяются в играх и движках. В книге почти сто страниц отведено про эти самые паттерны и подробно рассказано какие они бывают, как выглядят в C++, где у них подводные камни и как их применять. Т.е. ровно те мелочи реализации, которые обычно интересно перечитать, когда вы в очередной раз решаете делать фабрику отдельным классом или попробовать обойтись std::function. Когда я её писал, мне казалось, что это будет очень полезный практический текст, и он таким и получился, и человек с опытом довольно быстро находит там нужное.
Но если читать книгу целиком, а не эти отдельные главы, то хорошо видно, как я по неопытности и уверенности молодого автора в собственной правоте взял с места в карьер и сразу начал рассказывать про реализации, как будто читатель уже всё для себя решил и его интересует только синтаксис, предположив, что мы все тут делаем условный AAA-движок, в котором сериализация неизбежна, а скрипты обязательны. В результате получился классический случай, когда книжка отвечает на вопрос «как», но обходит вопрос «а собственно зачем», а без ответа на него все ответы про «как» оказываются либо случайно-полезными, либо системно-вредными, потому что человек берёт оттуда подход, переносит его в проект или прикручивает к своей мини-игре и потом жалуется, что у него теперь полторы тысячи строк инфраструктуры на ту же мини-игру, а работает она ровно так же, как раньше, только медленнее.
Если вам вдруг надоест читать эти 106 минут, там в конце есть TL;DR секция, где собрано краткое описание.
