Разработка

Неделю назад OpenGroup анонсировали публикацию черновика стандарта Archimate версии 3.3 (официально номер не обозначен - это мое предположение) для ознакомления с ним более широкой аудитории.

Я тоже скачал, полистал... Замечательно, когда есть раздел с кратким описанием отличий. Так вот, что же нас ждет:

• удалили связь композиции (composition) - теперь вместо него либо просто агрегация, либо специализация;

• удалили элемент "взаимодействие" (interaction) на всех уровнях, а также ограничение (constraint), разрыв (gap), контракт и представление (representation);

• элементы поведения на всех уровнях объединили в общие элементы "сервис", "процесс", "функция" и "событие";

• "событие" ("event") на слое implementation также заменено на общий элемент "событие";

• элемент "коллаборация" объединен для всех уровней (бизнес, приложения, технология);

• бизнес-роль стала просто "ролью";

• вместо представления фреймворка в виде аспектов и слоев теперь остался только шестиугольник Archimate;

• термин "слой" заменили на "домен";

• раздел по "Общей метамодели" заменили на главу 4, описывающую общие элементы (см. выше);

• путь ("Path") теперь входит в общий домен;

• вместо агрегации от пути к внутреннему активному структурному элементу теперь реализация от активного структурного элемента к пути;

• появилось визуальное отражение мощности связей (для отображения ограничений)

В качестве подходов для трансформации моделей из спецификации 3.2 в 3.3 предлагается выполнить замену (в т.ч. с использованием специализации соответствующего концепта):

• композицию - на агрегацию

• ограничения - на требование (requirement)

• контракт - на бизнес-объект

• разрыв (gap) - на оценку (assessment) или результата (deliverable)

• представление (representation) - на объект данных, артефакт или материал

• взаимодействия - на процессы и функции

• в целом элементы поведения с разных уровней - на универсальный аналог

• отмененные виды связей между конкретными типами элементов - на связь ассоциации

Если сравнивать с предыдущими версиями - они были менее революционными, и в основном добавляли что-то новое, дополняли. Грядущая же версия обещает чистку и унификацию - в т.ч. за счет активного применения введенного в предыдущих версиях понятия специализации для любого элемента / связи. По заверениям представителей OpenGroup это должно увеличить ясность и согласованность моделей, а также улучшить взаимопонимание при межкомандном взаимодействии.

На мой взгляд такое активное использование специализаций элементов алфавита языка Archimate с одновременным сокращением самого состава алфавита, с одной стороны повысит гибкость в подходах к моделированию, а с другой, после выработки этих подходов - потребует детализации соглашения по моделированию для конкретной организации/проекта/команды (т.е. насчет "лучшего взаимопонимания команд" я бы еще поспорил).

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

P.S.: в Acknowledgements изменений нет - моя фамилия единственная русская :-)

В Китае выпустили ИИ‑трактор Honghu T70, который сам катается по полю и выполняет фермерские задачи. Без руля, без водителя и даже без кабины. Внутри устройства есть GPS, датчики LiDAR и нейросети, которые помогают анализировать пространство, качество почвы, распознавать семена и менять глубину вспашки под каждую конкретную культуру. ИИ‑транспорт работает на полях Хэбэя, а скоро появится по всей стране.

Выпущена новая версия СУБД Picodata — Picodata 25.3 

Компания Picodata (входит в Группу Arenadata) выпустила новую версию СУБД Picodata — Picodata 25.3. Обновление включает расширенные возможности SQL, механизм автоматического обновления схемы данных, а также повышение стабильности кластера.

Улучшение обратной совместимости

В Picodata 25.3 реализовано автоматическое обновление схемы данных при переходе инстансов на новый релиз Picodata. Этот механизм учитывает сделанные изменения в системных таблицах и сохраняет обратную совместимость при обновлении на следующий релиз СУБД: при переводе кластера на новую версию Picodata необходимые DDL/DML-команды выполнятся без вмешательства администратора, а требуемые в новой схеме внутренние функции также будут созданы автоматически.

Новые возможности SQL

В релиз добавлены новые возможности языка SQL в Picodata, в частности:

• поддержка NULLS FIRST/LAST при сортировке результатов запроса (ORDER BY);

• обработка конфликтов при вставке данных в глобальные таблицы (INSERT INTO … ON CONFLICT DO FAIL/REPLACE/NOTHING);

• новая встроенная оконная функция LAST_VALUE();

• оператор % для определения остатка деления по модулю для целых чисел;

• возможность определения лидера raft-группы через функции pico_raft_leader_id() и pico_raft_leader_uuid();

• возможность определения версии текущего инстанса с помощью функции version();

• изменение, связанное с совместимостью: вместо скалярной функции instance_uuid (которая теперь объявлена устаревшей), рекомендуется использовать новую функцию pico_instance_uuid.

Улучшенная совместимость с PostgreSQL

Picodata теперь поддерживает безопасное соединение при обращении к внешнему LDAP-серверу. При подключении через протокол PostgreSQL (например, с помощью клиента psql) с методом аутентификации LDAP можно задействовать TLS-шифрование (при условии, что оно включено на LDAP-сервере). На стороне Picodata для этого потребуется установить значения у трёх переменных окружения. Например:

export TT_LDAP_URL="ldap://127.0.0.1:1389"
export TT_LDAP_DN_FMT='cn=$USER,ou=users,dc=example,dc=org'
export TT_LDAP_ENABLE_TLS=true

Изменение в конфигурации

Добавлен новый параметр instance.pg.advertise — публичный адрес сервера для подключения по протоколу PostgreSQL. По умолчанию, его значение соответствует значению instance.pg.listen. Этот параметр пригодится в ситуации, когда снаружи инстанс доступен по адресу, отличающемуся от адреса во внутренней сети.

Улучшенный веб-интерфейс

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

• на панели Cluster ID отображается больше полезной информации, включая список включённых плагинов;

• в области просмотра сведений об инстансе теперь присутствует адрес подключения по протоколу PostgreSQL.

Механизм плагинов

При подключении плагина к кластеру Picodata теперь допускается расхождение минорных версий плагина и инстанса (например, плагин, собранный для версии 25.3.1, будет работать в Picodata 25.3.2).

Полный список нововведений и список исправленных ошибок доступны в документе CHANGELOG.

Роль Picodata для Ansible

Выпущена новая версия роли Picodata для Ansible, которая совместима с Picodata 25.3. Изменения в роли:

• при сборке информации при сбое (тег crash_dump) можно исключить сборку snap- и xlog-файлов;

• добавлена возможность выполнять lua-команды на инстансах кластера (тег command);

• исправлена работа с несколькими плагинами в инвентаризационном файле и ряд прочих ошибок.

Для установки Picodata 25.3 следуйте инструкциям на сайте. Готовые пакеты доступны для следующих дистрибутивов Linux:

• Astra 1.8

• Debian 12 (bookworm)

• RHEL/Rocky 9

• Fedora 41–42

Инструкции и руководства по установке, использованию и администрированию Picodata размещены на портале документации Picodata.

Хотите подтянуть свои знания Go?

Тогда новый бесплатный курс для вас!

Язык Go называют одним из самых удобных для бэкенда. Дело тут не в примитивности: его специально стремились сделать простым и лаконичным, чтобы пользователям было легко работать с синтаксисом и понимать чужой код.

Если вы уже знакомы с Go, но не хватает практики, приглашаем пройти новый курс в Академии Selectel. С ним вы научитесь писать простые сервисы на Go и использовать его в некоторых рабочих задачах, а еще получите большую подборку ресурсов для погружения в этот язык. 

Несколько материалов для старта.

• Как написать свой REST API на Go? Разрабатываем сокращатель ссылок. Делимся пошаговой инструкцией, как написать REST API сервис URL Shortener и развернуть готовое приложение на сервере.

• Fuzzing-тесты в Go после v1.18. Рассказываем, как устроено fuzzing-тестирование в Go и как проверить функцию на корректную валидацию данных.

• Создаем сервис авторизации. Пошаговое руководство по написанию полноценного gRPC-сервиса с архитектурой на Go.

Открыть курс →

Винтик, Шпунтик, включения и исключения.

Некоторое время назад я опубликовал задачу, в которой требовалось посчитать число раскрасок грани кубика Рубика в 3 цвета определенным способом. К этой задаче сводится тернарный кейс Винтика и Шпунтика. Напомню,

у нас есть грань размера 3x3 и нам надо покрасить 9 ячеек в три цвета. 3 - в красный, 3 - в желтый, и 3 - в зеленый. Сколько существует раскрасок при которых ни одна строка и ни один столбец не закрашены одним цветом?

Картинка ниже дает примеры возможных и невозможных раскрасок

Задачку эту я решил, но решение мне не нравилось, потому что по сути оно является "ручным перебором" возможных раскрасок. И вот недавно, читая статью Артема, я сообразил, что все это можно описать в терминах "формулы включений - исключений". Для этого из полного числа раскрасок в три цвета нам надо исключить все "невозможные". Для это нужно просто аккуратно считать число раскрасок и чередовать знаки. Через к в дальнейшем обозначается номер шага, через n - размерность пространства. через В нашем случае она равна 3.

1. Шаг 0. Знак +. Полное число раскрасок 9 ячеек в три цвета.

   

2. Шаг 1. Знак -. Число раскрасок, при которых одна строка или один столбец закрашен одним цветом. Строки и столбы у нас "равноправны". Таким образом, мы получаем множитель 2, исходя из геометрии (а точнее просто размерности) задачи. Теперь, допустим, мы закрашиваем одну строчку(столбец) каким то одним цветом (допустим красным). Выбор цвета(1 из 3) дает нам С(3,1)=3 варианта. Выбор позиции дает еще 3 варианта. Запишем это как n!/(n-k)! Теперь нам нужно покрасить еще 6 (n(n-1)) ячеек в два цвета (желтый и зеленый). Что дает В итоге,

   

3. Шаг 3. Знак +. Когда у нас одновременно есть две строки или два столбца закрашенные одним цветом. Аналогично, 2- множитель размерности. Теперь нам надо выбрать 2 из 3 трех цветов. Получим, С(3,2) =3. Геометрическое размещение дает множитель 3!/(3-2)!. Ну и далее нам останется закрасить оставшиеся три ячейки оставшимся цветом. Что дает нам ровно С(3,3) = 1 вариант. Получаем,

   

4. Шаг 4. Знак -. Все три столбца или строки закрашены одним цветом. 2 - геометрический множитель. С(3,3) = 1 - выбор цветов. 3!/(3-3)! = 6 количество размещений. Итак,

   

   А теперь соберем все вместе и получим.

   

Или для нашего случая n = 3

И это правильный ответ. При домножении на дает 10752 - решение задачи Винтика и Шпунтика в тернарном случае.

Формулу (*) наверняка можно как то упрощать, но я не буду сейчас этим заниматься. Скажу лишь, что она работает для любых n. В частности, если нам нужно посчитать раскраски квадрата 4x4 в 4 цвета формула* дает.

В кватернарном случае Винтика и Шпунтика дело обстоит сложнее. Появляется дополнительная размерность и исключений становится больше. Однако, достоинством формулы (*) является относительное малое количество слагаемых (пусть и более сложного вида) по сравнению с тем, что предложил Артем.

Я не стал писать полноценную статью здесь и решил ограничиться форматом поста. Моей задачей было показать идею. Надеюсь, она стимулирует применить этот подход к кватернарному случаю Винтика и Шпунтика. Так что дерзайте. Ведь челлендж наш продолжается.

Хотел как лучше, а получилось... или снова о качестве описания CVE

В статье "Как я зарегистрировал CVE и разозлил вендора" я писал:

Желательно, чтобы CVE были достаточно хорошо описаны. У CVE-2024-45244 на данный момент есть некоторые проблемы. Описание в части версий некорректно: на момент создания CVE версия 2.5.9 была крайней в своей ветке. Но, далее в этой ветке продолжился выпуск версий без фикса. Фикс для стабильных версий вышел в рамках версии 3.0.0. Я планирую обратиться в MITRE с целью улучшить содержательную часть CVE.

После моего обращения описание CVE было обновлено. Было:

Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.

Стало:

Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window.

Честно говоря, такое описание вводит меня в ступор. Например, версия 2.5.13 по такому описанию уязвима? С одной стороны да: она до 3.0.0. С другой - нет: она после 2.5.9. И, если я не ошибаюсь, в версиях 2.4.х проблема тоже есть.

Это уже не первый раз, когда описание CVE в части версий неточное - даже после обращения с целью сделать точнее. Ранее нечто похожее было с моей попыткой улучшить описание для CVE-2018-14847.

Всё это в очередной раз наводит на мысли, что доверять описанию CVE полностью нельзя. И качество анализа CVE влияет на безопасность: у атакующих может быть преимущество, если они дотошно перепроверяют условия реализации уязвимости. А у защищающихся часто нет такой дотошности (часто - из-за огромного количества уязвимостей, с которыми работаешь в рамках Vulnerability Management). В итоге в этой гонке у атакующих бывает преимущество. Помнится, я даже для CTF задачку на эту тему делал: изюминка была связана именно с неверным описанием CVE в части версий. К сожалению, тогда работодатель мою идею не одобрил. А ведь это был бы хороший практический урок для начинающих специалистов по безопасности.

Проблема с описанием версий иногда обостряется из-за позиции вендора. Как я писал в статье:

Разработчики, имея больше информации о своём продукте, могли бы повлиять на более точное описание CVE. Но, вместо этого им захотелось устроить борьбу "за честь мундира".

OpenAI представила новый режим Study Mode для ChatGPT.

Вместо того чтобы сразу выдавать ответ, ChatGPT задаёт наводящие вопросы, предлагает подсказки и помогает студенту самостоятельно прийти к решению. Это как личный репетитор, который подстраивается под ваш уровень знаний.

Основные возможности Study Mode для ChatGPT:

• интерактивные подсказки. ChatGPT использует вопросы в стиле Сократа, чтобы стимулировать мышление и развивать понимание;

• пошаговые объяснения. Сложные темы разбиваются на простые части, чтобы не перегружать учащегося;

• персонализация. Уроки адаптируются под ваш уровень знаний и цели;

• проверки знаний. Короткие тесты и вопросы помогают закрепить материал и отследить прогресс;

Режим обучения Study Mode для ChatGPT можно включать или выключать в любой момент разговора.

Linux 6.16 принесет более быстрые файловые системы, улучшенную поддержку памяти и больше Rust

Linux продолжает развиваться, становясь больше и лучше. Вот что нового и примечательного в релизе 6.16, а также что нужно знать о 6.17. Изменения в последнем ядре Linux, версии 6.16, могут быть небольшими, но среди них есть весьма значимые. Сам Линус Торвальдс охарактеризовал этот релиз как "выглядит хорошо, небольшой и спокойный", но "не слишком интересный (в лучшем смысле этого слова!)".

Появились биндинги Rust к ядру для инфраструктуры драйверов и подсистемы PCI-устройств. Это упростит добавление новых драйверов оборудования, написанных на Rust. Интегрированы новые абстракции Rust в подсистему Direct Rendering Manager (DRM).

Файловые системы

XFS: Теперь поддерживает большие атомарные записи. Это означает, что операции записи, охватывающие несколько блоков, выполняются "атомарно" – либо обновляются все блоки, либо ни один. Усиливает целостность данных и предотвращает ошибки записи. Важно для компаний, использующих XFS в базах данных и системах хранения масштаба предприятия.

Самая популярная файловая система Linux, Ext4, также получает множество улучшений. Эти усовершенствования включают ускоренные пути фиксации (commit paths), поддержку больших фолио (large folio) и атомарные записи, охватывающие несколько блоков файловой системы (fsblocks) для файловых систем с bigalloc.

Прочее

Если вы через ноутбук на Linux проигрываете музыку, еще одна приятная новая функция — теперь вы можете транслировать аудио по USB, даже когда остальная часть системы находится в спящем режиме. Эта возможность была доступна в Android какое-то время, но теперь она стала частью основного (mainline) Linux.

Если безопасность является для вас приоритетом, ядро 6.16 теперь поддерживает Intel Trusted Execution Technology (TXT) и Intel Trusted Domain Extensions (TDX). Это дополнение, наряду с улучшенной поддержкой AMD Secure Encrypted Virtualization и Secure Memory Encryption (SEV-SNP) в Linux, позволяет шифровать память вашего программного обеспечения в рамках так называемых конфиденциальных вычислений (confidential computing). Эта функция повышает безопасность облаков, шифруя память виртуальной машины пользователя, что означает, что злоумышленник, взломавший облако, не сможет получить доступ к вашим данным.

В этом релизе есть и другие улучшения поддержки чипов в Linux. Для начала, Linux теперь поддерживает Intel Advanced Performance Extensions (APX). С APX Linux теперь может использовать 32 общецелевых регистра x86. Это вдвое больше, чем 16 регистров у старых чипов. Это улучшение означает, что вы увидите повышенную производительность от процессоров Intel следующего поколения, таких как Lunar Lake и серверные Granite Rapids Xeon.

Linux 6.16 приносит улучшенную поддержку GPU Nvidia Blackwell. Чипы Blackwell, используемые в основном для ИИ, уже развертываются в высокопроизводительных Linux-рабочих станциях.

На сетевом фронте изменения в работе TCP/IP с DMABUF позволят устройствам, включая GPU и ИИ-ускорители, ускорять свои сетевые операции, не нагружая при этом CPU. Хотя обычный пользователь может не заметить это изменение, пользователи высокопроизводительных сетей увидят ускорение.

И есть шанс, что обычные пользователи увидят преимущества, если они используют OpenVPN. Собственный сетевой протокол OpenVPN по-прежнему не будет работать так же быстро, как WireGuard, но, по крайней мере, даст ему больше шансов в гонке.

Источник (https://www.zdnet.com/article/linux-6-16-brings-faster-file-systems-improved-confidential-memory-support-and-more-rust-support/)

Windows 10 — 10 лет

Ровно 10 лет назад, 29 июля 2015 года, Microsoft официально выпустила Windows 10. Не планировал писать об этом отдельно, но, не увидев ни одной публикации на Хабре, решил опубликовать этот короткий пост.

Хотя сам я почти не пользовался Windows 10 — уже более 15 лет на Linux, — она всё же стояла в дуалбуте на моём старом ноутбуке и иногда использовалась, чтобы что-то скомпилировать под Windows. Как ни крути, это всё равно важная веха в истории компьютерного мира.

Казалось бы, совсем недавно все решали, стоит ли обновляться с Windows 7 до "десятки". Некоторые уже успели попробовать "плиточную" Windows 8 и ломали голову, что ещё "инновационного" придумает Microsoft. Однако, вопреки опасениям, в Windows 10 вернулся более классический интерфейс.

Издания наперебой писали, почему Windows 10 стала быстрее, безопаснее и почему обязательно нужно обновиться. На форумах шли горячие споры: кто-то держался за Windows 7, а кто-то уверял, что человечество ничего лучше XP ещё не придумало.

Затем случился неожиданный поворот: Microsoft внезапно развернулась в сторону Open Source, стала нанимать известных разработчиков из Linux-сообщества, появилась WSL.

А вот Microsoft уже похоронила Skype...

Казалось, всё это было совсем недавно.

Windows 10 уже исполнилось 10 лет.

Находки на рыбалке: FastStream! Сходили с автором половить рыбу и пожарить всякое вкусное на углях. И пока было время – говорили про программирование.

Для тех, кто еще не успел познакомиться с новинкой, рассказываю: FastStream – аналог FastAPI, но для работы с событиями в брокерах / очередях.

Пример:

from faststream import FastStream
from faststream.kafka import KafkaBroker

broker = KafkaBroker("localhost:9092")
app = FastStream(broker)

@publisher("another-topic")
@subscriber("first-topic")
async def handle(user: str) -> str:
     return f"Hi, {user}!"

Что делает данный код? Читает сообщения из first-topic, парсит из них поле user типа str, выполняет вашу логику обработки, отправляет новое сообщение в another-topic. Просто? Удобно? Да!

Что нам дает такой подход?

• Декларативное описание, чего мы хотим. Не надо руками создавать коннекты и рулить потоком выполнения

• AsyncAPI документацию (аналог OpenAPI в вебе)

• Удобное тестирование

• Кучу других плюшек!

Внутри видео обсудили:

• Детали работы DI фастстрима

• Встроенное Observability

• Open Tracing

• Сообщество фреймворка (тут не будет проблемы "одного автора", сообщество живет!)

• Отличия от Celery: почему интструменты совсем разные?

Репозиторий: https://github.com/ag2ai/faststream
Документация: https://faststream.ag2.ai

Обсуждение: используется ли в ваших проектах асинхронная архитектура? Как вы работаете с событиями?

Как устроен livepatch-модуль для ядра Linux

С точки зрения пользователя (в данном случае человека, отвечающего за обновления данной Linux-системы) лайвпатч — это просто модуль ядра Linux, в котором содержится как минимум следующее: 

• исправленный код одной или более функций из vmlinux и/или из модулей ядра,

• метаданные, указывающие, как применить эти исправления к соответствующим компонентам ядра Linux. 

Чтобы применить лайвпатч-обновление, нужно загрузить этот модуль ядра, например, с помощью insmod или modprobe, а затем активировать его, как правило, через sysfs. 

При этом старый код ядра Linux (тот, который хотим обновить) и новый (тот, что в лайвпатч-модуле) сосуществуют в памяти системы. Это дает возможность при необходимости отменить лайвпатч-обновление в runtime: деактивировать его через sysfs, а затем выгрузить лайвпатч-модуль.

Важный момент: если используются средства для работы с лайвпатчами из mainline-ядра, то при активации и деактивации лайвпатч-обновлений работающие процессы не нужно завершать или даже останавливать на сколько-нибудь существенное время.

Примечания:

• У TuxCare / KernelCare лайвпатчи поставляются в другом, проприетарном, формате, но мы его рассматривать не будем.

• Для некоторых архитектур, например RISC-V, при активации и деактивации патча вызывается stop_machine(), то есть работающие процессы при этом все-таки останавливаются на некоторое время. Начиная с версии 6.16 ядра Linux, для RISC-V stop_machine() уже, вероятно, не будет использоваться в таких ситуациях.

Все, что нужно знать о лайвпатингче для ядра Linux, вы найдете в цикле статей: от подготовки лайвпатча до работы на x86, ARM и RISC-V.

Читать первую часть →

Читать вторую часть →

Новые вакансии в SSP SOFT: расширяем команду аналитиков

Привет Хабр! Когда ИТ-рынок охлаждается, мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы ты получал удовлетворение от работы.

✔️ Гарантируем интересные задачи
✔️Для каждого нового сотрудника есть наставник
✔️ Центр компетенций помогает прокачивать навыки
✔️ С нами ты можешь работать из любой точки мира
✔️ Для экстравертов у нас есть уютные офисы в Москве и Томске
✔️ Оптимальный Work Life Balance

🎁 Наши плюшки: ДМС со стоматологией, обучение от компании и бонусная программа.

📢 Мы ищем:

1️⃣Аналитика 1C (https://tomsk.hh.ru/vacancy/123248946?from=employer&hhtmFrom=employer)

2️⃣Системного аналитика (https://tomsk.hh.ru/vacancy/122192419?from=employer&hhtmFrom=employer)

3️⃣ Аналитика DWH (https://tomsk.hh.ru/vacancy/122295631?from=employer&hhtmFrom=employer)

👉 присылай резюме в ЛС нашему HR Lead @AONikitina
Подробности о вакансиях читай на ХХ.ру (https://hh.ru/employer/5648224?hhtmFrom=vacancy)
Ждем тебя в команду SSP SOFT!

Сравнение производительности React-компонентов: Gravity UI vs другие библиотеки

Я core‑разработчик Gravity UI, и периодически нам в команду поступают вопросы про производительность react‑компонентов из нашей библиотеки @gravity‑ui/uikit. Я решил сделать небольшое исследование этого вопроса, и всё написанное ниже является отправной точкой для дальнейших исследований и попыткой ответа на вопрос «Почему Gravity тормозит?»

Обычно этот запрос пишут без дополнительных деталей, поэтому я исхожу из предположения, что одна (но, конечно же, не единственная) из основных проблем производительности — долгое время отрисовки. В рамках этого исследования мы рассмотрели затраты на первый рендеринг отдельных компонент каждой из библиотек в изолированной среде. Для сравнения были выбраны библиотеки @adobe/react‑spectrum, @mui/material и antd.

Методология исследования

Технический стек:

• Playwright — фреймворк для автоматизации тестирования кода в разных браузерах (подробнее).

• PerformanceObserver API — браузерный API для измерения производительности (подробнее).

Условия выполнения тестов:

• Каждый тест запускается в отдельном контексте браузера.

• Единовременно выполняется только один тест (настройка workers в конфиге Playwright), что гарантирует выделение одинакового количества ресурсов на каждый тест.

• Каждый тест повторяется 50 раз.

• Тесты проводятся с разным количеством нод (10, 100, 1000).

Порядок выполнения одного теста:

1. Открытие новой страницы в браузере.

2. Инициализация PerformanceObserver.

3. Начало сбора метрик.

4. Рендеринг компонентов.

5. Завершение сбора метрик.

Процесс измерения:

В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.

Результаты

Результаты замеров не содержат в себе абсолютных цифр. От окружения к окружению они, конечно же, могут варьироваться. Но этих цифр вполне достаточно, чтобы увидеть некоторые зависимости и сделать на их основании выводы:

1. @gravity‑ui/uikit показывает конкурентоспособные результаты:

   • В большинстве тестов находится в верхней части рейтинга.

   • Демонстрирует стабильное время рендеринга при разном количестве нод.

   • Особенно эффективен в компонентах Button, Checkbox и Switch.

   • Имеет проблемы со временем рендера компонента TextArea.

2. @mui/material также показывает хорошие результаты:

   • Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.

   • Имеет видимый рост времени рендера в зависимости от количества нод.

3. antd и React Spectrum:

   • Показывают более высокое время рендеринга в большинстве тестов.

   • Имеют больший разброс между минимальным и максимальным временем.

С помощью этого инструмента можно провести замеры производительности на своей локальной машине, а также добавить тесты для компонентов, которых ещё нет. Нам поможет, если вы развернёте его у себя и пришлёте в PR результат работы на своём компьютере.

В этой статье я раскрыл один из примеров, как мы работаем с библиотекой. Но нам очень важна обратная связь от сообщества: если у вас есть конкретный пример, где Gravity UI показывает себя сильно хуже других библиотек, или если вы видите ошибку в нашей методологии тестирования, приходите в комментарии к этому посту или создавайте issue, обсудим. А также не забывайте ставить звёздочки проекту!

В работе с данными важна системность — от понимания основ до практического применения инструментов. Мы подготовили подборку из ресурсов, которая поможет новичкам освоить необходимые навыки и развить понимание аналитики в разных аспектах.

• Визуализация данных для начинающих: что почитать, чем вдохновиться и на кого подписаться — подборка для тех, кто только начинает осваивать визуализацию данных или хочет расширить арсенал инструментов и источников вдохновения

• Базовый Python для аналитика данных: подборка для самостоятельного обучения — собрали в основном бесплатные курсы. Попробуйте несколько из списка и остановитесь на том, который вам больше всего подходит.

• Анализ данных: 8 ссылок для погружения в бизнес и продукт — материалы, которые помогут погрузиться в контекст бизнеса, узнать, с какими метриками работают аналитики, и научиться рассчитывать эти показатели с помощью Python.

• Математика без боли: как освоить предмет, если не занимались им со школы — рекомендации и немного литературы для начинающих аналитиков, которым математика нужна для работы.

Если хочется продолжить изучать основы и сделать шаги к практике — посмотрите на бесплатные курсы и вводные темы на курсах Практикума. Вы можете порешать математические задачки или изучить основы статистики.

Разбираюсь с бюджетными преобразователями USB CAN. В качестве параметра для классификации удобно использовать тип применяемого протокола, по которому данные передаются на ПК.

slcan - текстовый протокол который применяется еще и с интерфейсом RS2232, с оборудованием фирм LAWICEL и VScom, переросшим в связку USB-UART-CAN, с виртуальным последовательным портом, а затем - в USB CAN на единственном микроконтроллере. C которым можно работать из обычной терминальной программы, без особого софта.
Существует множество реализаций и расширений этого протокола, на разных микроконтроллерах, в том числе STM32, включая поддержку CAN-FD (на STM32G431, STM32G01) в основном в виде проектов на GitHub.
Проект canable (VID:PID AD50:60C4 либо 0x0403:0x6015) (и еще ранний вариант под названием cantact), прошивается в доступные платки на базе контроллеров STM32F042 и STM32F072 (на Ali похоже уже только на F072 продают). Получил развитие в виде canable v2 (STM32G431, 0x16D0:0x117E).
Вариация USB2CANFDV1 от WeAct studio (STM32G01, 0x0483:0x5740) - зашифрованная прошивка без исходников.
Помимо этого: stm32-slcan (STM32L433, 0x0483:0x5740, протокол урезан), UCCBEmbedded (STM32F042, 0x0483:0x5740), CFDC_embedded-slcan (STM32G431, 0x0483:0x5741), CAN2USB (STM32F105, 0x0483:0x5740), CANsniffer (STM32F042, 0x0483:0x5740).
Проект USBtin (PIC18, 0x04D8:0x000A) представляет собой скорее исторический интерес, в его состав входят макросы для поддержки протокола slcan в легендарной HyperTerminal.
Проект ESP32RET использует текстовый протокол LAWICEL в качестве подмножества команд для двоичного протокола GVRET как через USB так и WiFi (TCP). Проект WiCAN реализует поддержку протокола slcan через USB, WiFi, BLE, а так же протокола для программы RealDash. Так же эти прошивки знают известный протокол ELM327 для автодиагностики, это тестовый протокол со множеством реализаций, однако при его помощи "сырой" CAN захватить либо трудно либо нельзя.

gs_usb более известный как candleLight (0x1D50:0x606F) по названию платы (разработка Linux Automation GmbH, так же фигурирует наименование USB2CAN by Geschwister Schneider Technologie-, Entwicklungs- und Vertriebs UG). Это уже двоичный протокол. Который рассчитан в первую очередь на контроллеры STM32F042/STM32F072, поддержка контроллера STM32G01 и CAN-FD на текущий момент только создается.
Однако есть проект bugetcan - прошивка для "most STM32 devices", есть готовые пресеты для STM32F042, STM32G01, STM32G431, STM32G473, STM32H743, STM32H745.

uCAN_FD - упомянутый ранее CFDC_embedded (uCAN CanFD USB Converter(CFUC)) также предлагают свой собственный протокол, но он, похоже, работает только в софте из этого проекта.

pcan и kvaser по названию соответствующих фирм. Реализованы не только для фирменного оборудования, но и для тех же дешевых платок canable/cantact на STM32F042 (0x0bfd:0x0120 и 0x0483:0x000C), что дает возможность использовать софт рассчитанные именно на эти платы.

usb_8dev для 8 devices USB2CAN, реализован в открытом проекте CANalyze (STM32F042, 0x0483:0x1234), который, похоже, больше не развивается

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

Разные программы для мониторинга CAN обращаются с протоколами по разному. Например мощная программа BUSMASTER умеет работать с оборудованием VScom (в том числе и через TCP) и PEAK, а значит можно попробовать использовать ее с дешевыми платами перепрошитыми на поддержку такого протокола. SavvyCAN и CANgaroo умеют работать с LAWICEL/slcan, протокол candleLight - через драйвер для Windows. Ну а в linux (с относительно свежим ядром) некоторые перечисленные протоколы уже встроены в виде драйверов сетевых (устройств) SocketCAN, что тоже поддержано большим количеством софта.

Запускаем регистрацию на GoCloud Tech 2025 — IT-конференцию про AI, облака и работу с данными ☁️ + 🤖 + 💿

Всем привет! Приглашаем на нашу уже вторую технологическую конференцию о создании решений на базе AI и облаков. 

Что вас ждет:

• 4 трека про облака, технологии, искусственный интеллект, изнанку наших сервисов и возможности облачной платформы собственной разработки;

• демо и интерактивные зоны новых AI-сервисов и сервисов платформы Cloud․ru Evolution;

• технические воркшопы;

• нетворкинг, кастомный мерч и afterparty.

Основные темы конференции:

• реальные кейсы внедрения AI- и ML-решений,

• тренды в создании облачной инфраструктуры,

• актуальные практики для работы с данными в облаке,

• инструменты, ускоряющие разработку.

Зарегистрироваться 👈

📆 Когда: 3 сентября

📍 Где: в Лофт-пространстве Goelro в Москве и онлайн в VK и на Twitch

---

Скоро мы поделимся программой и начнем анонсировать доклады — не переключайтесь! А как прошли предыдущие конференции Cloud.ru можно почитать в статьях:

• Бороздим облака будущего: впечатления айтишника о конференции GoCloud

• «Все говорили, что зашло» — как прошла ламповая IT-конференция для инженеров и технарей — GoCloud Tech

• Темы, доклады, две конфы: история трека для инженеров и исследователей «Под капотом»

• Как прошла GoCloud 2025 — масштабная IT-конференция про облака и AI. Делимся итогами

Учёные из Великобритании, Канады и США обнаружили, что мягкая стимуляция префронтальной коры головного мозга электрическим током может существенно улучшить математические способности, особенно у людей с изначально низким уровнем подготовки.

В эксперименте с участием 72 добровольцев использовался метод транскраниальной стимуляции случайным шумом (tRNS), который оказался безопасным и безболезненным. Участники проходили пятинедельное обучение новым математическим техникам: часть из них получала настоящую электрическую стимуляцию, а часть — плацебо.

Результаты показали: у тех, у кого исходно наблюдались слабые связи между префронтальной и теменной областями мозга, прогресс в обучении при стимуляции оказался значительно выше. Благодаря воздействию тока их результаты сравнялись с успехами более подготовленных сверстников,

Исследователи отметили, что этот метод можно использовать для сокращения образовательного неравенства, связанного с биологическими особенностями мозга. При этом техника не дает преимуществ тем, кто и так учится легко — она лишь помогает догнать лидеров, не увеличивая разрыв.

Unity: VR-игра, где монстры слышат твой страх

Всем привет!

Я запускаю новый проект: начинаю разрабатывать хоррор-игру в VR на Unity. Параллельно буду вести дневник разработчика - делиться этапами, мыслями и техническими находками.

В ближайшее время выйдет первая статья.

Я буду рада вашим комментариям, советам и предложениям. Если у вас есть опыт в разработке игр или вы только начинаете - давайте обсуждать и учиться вместе!

Следите за обновлениями - будет интересно!

Как мы синхронизировали съемку для возрожденного проекта DPED

Команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева продолжает рассказывать о работе по возрождению и улучшению DPED (Deep Photo Enhancement Dataset). 

Мы решили задачи автоматизации, но столкнулись с еще одной проблемой: фото на планшете и камере снимались с некоторой задержкой относительно друг друга. Использование простых пауз (time.sleep) оказалось ненадежно и неэффективно. Тогда мы реализовали многопоточное решение:

• Первый поток управляет съемкой с камеры с помощью библиотеки pyautogui.

• Второй поток управляет съемкой с планшета через ADB.

• Оба потока обмениваются информацией через очередь (queue.Queue() из стандартной библиотеки Python) — это потокобезопасная структура данных, которая позволяет одному потоку передать сигнал другому. В нашем случае очередь используется для передачи сигнала о начале съемки с камеры. Получив этот сигнал, планшет почти без задержки запускает захват изображения.

В процессе тестирования среднее время задержки составило 50 мс, но разброс данных достигал 93 мс. То есть, существуют случаи, когда мы получаем изображения с непозволительной задержкой в 100 мс и более. Мы отметили этот момент, но продолжили собирать датасет, а изображения с большой задержкой — удалять.

Скрипт автоматизации съемки кадров:

import subprocess
from threading import Thread
import pyautogui
import time
from queue import Queue

# координаты для кликов мыши

CAMERA_SHUTTER_BUTTON = (329, 748)    # кнопка затвора в приложении

FOCUS_POINT = (1189, 204)            # точка фокуса или область кадра


def tablet(q):
    time.sleep(0.1)
    if q.get() == 1:
        p = subprocess.Popen(r'.\adb.exe shell', stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        p.stdin.write(b'input keyevent 27')
        p.stdin.close()

def camera(q):
    pyautogui.click(*CAMERA_SHUTTER_BUTTON)
    pyautogui.moveTo(*FOCUS_POINT)
    q.put(1)
    pyautogui.mouseDown()
    time.sleep(0.02)
    pyautogui.mouseUp()

q = Queue()
thread1 = Thread(target=camera, args=(q,))
thread2 = Thread(target=tablet, args=(q,))
thread1.start()
thread2.start()

В оригинальной работе DPED точные значения задержки не указывались: авторы фиксировали устройства на механическом стенде и выполняли съемку вручную, без программной синхронизации или последующего анализа временного лага между кадрами. Насколько нам удалось выяснить, синхронизация производилась «на глаз», что не позволяет оценить точность в миллисекундах. Таким образом, можно утверждать, что наша реализация обеспечивает более детерминированный и измеримый результат по синхронизации.

Читайте в статье, как команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ доводит снимки с планшета YADRO KVADRA_T до качества полупрофессиональной камеры Sony Alpha ILCE 6600.

А зачем вообще проводить исследования? А вот интересно посмотреть на сферу глазами тех самых ребят, кто каждый день работу эту самую работает, узнать, где больше всего болит и где можно усилиться — то есть в будущем предложить решение, которого ещё нет или чего мало.

Так появилось исследование тестировщиков 👇

Ещё можно углубиться в лендинг: https://qa-survey-2025.2gis.ru. Посмотреть разные цифры: собирали данные скрупулезно по профильным каналам, 1000 QA-инженеров начали опрос, 570 стойко ответили на все 45 вопросов!

К слову, и про статистику сбора данных: 37% тестировщиков проходили опрос на Android, 29% на iPhone, 23% на Windows, 9% на MacOS и даже 2% c Linux.

Заглядывайте и пишите, за что взгляд зацепился, обсудим!