Или: как embedded-разработчик случайно написал визуализатор временных рядов

Это моя первая статья и сразу на тему в которой я разбираюсь примерно никак. Ее можно воспринимать как условный "дневник разработчика".

Статья написана не без помощи LLM, от нее по большей части редактура. Прошу камнями не кидаться

Приятного чтения!

С чего всё началось

В миру я позиционирую себя как Embedded-разработчик, а как принято во многих местах в России разработчик встраиваемых систем - это инженер-разнорабочий. Написать firmware, развести не сложную PCB, поколдовать над ядром Linux,  провести исследования датчиков с китайского завода, напаять концевиков, собрать тестовый стенд, а если еще и осталось время - по возможности спроектировать корпус для устройства и произвести его прототип.

И в этот(и так немаленький список) периодически добавляется потребность в написании ПО под Пк, для работы с разрабатываемыми устройствами/датчиками и т.д. В основном, это несложные внутренние консольные утилиты, которые помогают общаться с устройством, логгировать данные, калибровать датчики и все в таком духе.

Но иногда появляется потребность в визуализации. Пока речь идет о низкочастотных датчиках и малом количестве данных - все довольно просто, но как только данных становится больше, а частоты выше - всплывает множество нюансов. При 70 кГц через 10 секунд работы датчика у меня уже 700 000 точек. Через минуту – 4.2 миллиона. А пользователь при этом хочет масштабировать/панорамировать оси, выделять области, нажимать кнопки – и всё это должно отзываться мгновенно. Стандартный подход «передать всё в библиотеку» ломается очень быстро.

Честный ответ: писать sin(x) руками в работе приходится далеко не всем. Подавляющему большинству — вообще никогда. И даже там, где синус трудится явно — в DSP, графике, геодезии — он давно спрятан за библиотеками: вы вызываете fft(), rotate(), routeTo(), а тригонометрию за вас написали тридцать лет назад.

Так что если вопрос — «набирал ли ты когда-нибудь s-i-n на клавиатуре за деньги», у тригонометрии всё плохо.

Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.

Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.

И самое интересное заключается в том, что так было не обязательно.

Демон «ничего не делал» — а одно ядро было загружено на 100%. История про виртуальный COM-порт для Linux/WSL2: PTY, epoll и эмуляция RS485, с кодом и граблями.

Рассказываю, как сделал vseriald — демон, который создаёт виртуальный последовательный порт /dev/ttyV0 в Linux и WSL2 и выводит его в сеть, FIFO или очередь сообщений. Разбираю три неочевидных места: псевдотерминал, после закрытия которого одно ядро уходит в 100%; притормаживание источника в однопоточном epoll-цикле без блокировок; эмуляцию полудуплексного RS485 как конечного автомата с таймингами и коллизиями. Плюс честный ответ на вопрос «зачем это, если есть socat и /dev/pts» — и код из реального проекта.

Срочно переписывайте свои устаревшие bloom фильтры на мой богоподобный lz77-фильтр. Совершенно бесплатно! Спасибо великому нанабанана за обложку!

Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную?

В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. 

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

Black-White Array (BWA) — это упорядоченная структура данных с амортизированным временем операций вставки/поиска/удаления и используемых участков памяти. Преимущества:

• Амортизированное время вставки/удаления/поиска сравнимое с реализацией BTree от Google;
• Низкое количество аллокаций памяти при операциях вставки - меньше давления на сборщик мусора, ниже фрагментация памяти;
• Массивы под капотом: данные лежат рядом, что улучшает кэшируемость процессором и скорость обхода/доступа к данным;
• Позволяет хранить элементы с одинаковыми ключами - не нужно использовать дополнительные структуры для группировки таких элементов;
• Низкий оверхед на хранение служебной информации - экономия памяти по сравнению с другими структурами данных;
• Удобен для вставки батчами;
• Простая сериализация и десериализация;

Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

Как разработать источник отрицательного напряжения? Легко, это делается из классического Buck конвертера!

Стандартное решение, которое может пригодиться всем, кто хоть раз сталкивался с разработкой DC/DC источников питания или столкнулся сейчас.

Файловая система во встраиваемых решениях — критическое звено. От её выбора зависят надёжность, детерминированность и задержки всей системы.

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

На практике всплывают одни и те же проблемы: дефрагментация, высокое потребление RAM, плохая детерминированность (плавающие задержки), неустойчивость к сбоям записи/питания и низкая скорость. Нередко корнем оказываются драйверы из SDK производителей чипов: они не оптимизированы для многозадачной среды и часто недоработаны под OSPI.

Я протестировал четыре файловые системы на платформе MC80 с внешней OSPI NOR Flash и разработал специализированный драйвер вместо стандартного из FSP — с полноценной поддержкой OSPI и RTOS.

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

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

Очередной электроквиз достиг публикации.
На этот раз состав участников весьма полярный: есть как обладатель кармы +525 и автор свыше 100 статей, так и участник с кармой +2 и нулём статей; как DIY-любители, так и представитель бизнеса, связанного с электроникой; как завсегдатаи Хабра, так и человек, узнавший об электроквизе на JoyReactor.

В остальном всё как и в предыдущие раз: 15 участников, 15 электротехнических вопросов и ответы на них.

Надругательство над C#, C++ и HLSL, игрища с булками и буферами, тройная полиглотность, SIMD, пепекторы, DirectX, экономия 800 Тб ОЗУ, новая парадигма программирования, многопроцессность, быстрая степень и многое другое.

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

Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?

В прошлом месяце я зарелизил ZLinq v1 — революционную LINQ-библиотеку, которая достигает zero allocation на структурах и дженериках. Она может похвастаться такими расширениями, как LINQ to Span, LINQ to SIMD, LINQ to Tree (FileSystem, JSON, GameObject и т.д.), drop-in replacement Source Generator для произвольных типов, поддержкой нескольких платформ, включая .NET Standard 2.0, Unity и Godot и на данный момент ZLinq имеет более 2000 звезд на GitHub.

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

17–18 апреля в Москве прошла выставка и конференция WBCE 2025, ставшая крупнейшей за все время проведения. За два дня мероприятие посетили более 1200 человек — интеграторы, разработчики, производители оборудования и энтузиасты автоматизации. В этом году участие приняли 42 компании, представившие на стендах свои разработки в области умного дома, диспетчеризации, микроклимата, SCADA, IoT и цифровизации жилых и коммерческих объектов.

В репортаже мы собрали обзор всех стендов WBCE 2025: рассказываем о компаниях, их решениях, новых продуктах и ключевых анонсах. Вы увидите, как меняется ландшафт автоматизации в России — от модульных контроллеров и BLE-сенсоров до платформ для управления целыми жилыми кварталами.

«Вспоминаю, как в 7-м классе ничего не понимал, когда мы начинали разбирать тригонометрию. С учителем мы не смогли найти общий язык, поэтому к 8–9-му классу я был уверен, что никогда не буду заниматься математикой, а уж тем более сидеть по несколько часов в день, утыкаясь в учебники Беклемишева или Кожевникова и параллельно просматривая лекции Физтеха…»

Всем привет! Идею этой статьи я вынашивал довольно долго, пока не набрался опыта в том, что сейчас стало моей каждодневной практикой. Надеюсь, мой опыт поможет кому-то из вас комфортнее и эффективнее подойти к изучению математики (а может, и других наук). Предлагаю познакомиться:

Меня зовут Ренат, мне 23 года, я родился в Москве, окончил обычную школу и вплоть до 19 лет не понимал, чем хочу заниматься — что называется «что меня драйвит». Сейчас живу на Кипре, работаю тут аналитиком, продолжаю параллельно учиться в России и скоро заканчиваю там университет.

За последние несколько лет я успел поработать аналитиком в Ozon, затем продуктовым аналитиком в Тинькофф (ныне Т-банк), перешёл в лондонский стартап, а сейчас тружусь над проектами в сфере Trust & Safety. И вот в один прекрасный день я решился «серьёзно ботать математику»: уже несколько месяцев уделяю 10–15 часов в неделю задачам, лекциям и подготовке к поступлению в магистратуру (решая вступительные от МГУ, ВШЭ, МФТИ). Именно об этом пути — как я ищу мотивацию, борюсь с прокрастинацией и стараюсь не выгореть — я и хочу вам рассказать.

Над созданием открытой шины данных АСУ ТП работают как российские, так и зарубежные разработчики. Причина понятна – уйти от проприетарных протоколов и решений и создать единую прозрачную среду передачи данных систем автоматики. Раскроем суть задач, стоящих перед разработчиками.