Open source *

Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.

Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.

Название поля НАД полем - parentclass="stack".

Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.

<field type="text"
     name="map_center"
     label="MOD_WTYANDEXMAPITEMS_MAP_CENTER"
     description="MOD_WTYANDEXMAPITEMS_MAP_CENTER_DESC"
     default="51.533562, 46.034266"
     hint="51.533562, 46.034266"
     parentclass="stack"
/>

2 и более полей в ряд в параметрах модуля/плагина - классы span-*.

Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.

• span-1-inline - поле будет шириной в 1 колонку сетку.

• span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию.

Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.

<field type="list"
     name="map_zoom"
     label="MOD_WTYANDEXMAPITEMS_MAP_ZOOM"
     default="7"
     parentclass="stack span-2-inline"
     filter="integer">
          <option value="0">0</option>
          <option value="1">1</option>
          <option value="21">21</option>
</field>
<field type="list"
     name="map_type"
     label="MOD_WTYANDEXMAPITEMS_MAP_TYPE"
     parentclass="stack span-2-inline"
     default="scheme">
          <option value="scheme">MOD_WTYANDEXMAPITEMS_MAP_TYPE_MAP</option>
          <option value="satellite">MOD_WTYANDEXMAPITEMS_MAP_TYPE_SATELLITE</option>
</field>

Мой обход блокировок Telegram и WhatsApp (колхозный?)

Живу в за пределами России и часто общаюсь с родственниками и друзьями из России.
Основное общение всегда было через Скайп, Telegram и WhatsApp.

Скайп помер в Мае, а когда звонки начали глючить в Telegram и WhatsApp, сначала подумал, что у мамы Wi-Fi тупит.
Просил перезагрузить роутер, попробовать выйти на улицу. Затем спросил знакомых, почитал новости и прозрел - звонки глючат у всех.
MAX.

Что попробовал:

• VPN на телефоне → тяжело для пожилых родственников, NordVPN - два года подписки в топку.

• Viber → работает, но нестабильно.

• Zoom → громоздкий для простых звонков.

Нужен более простой и независимый способ.

Решение

После поиска остановился на Jitsi Meet — системе для видеозвонков с открытым кодом. Её можно развернуть на своём сервере и не зависеть от блокировок.

Настройка

1. Поднял виртуалку на Ubuntu.

2. Настроил pfSense с NAT и SSL.

3. Установил Jitsi Meet в Docker.

Мои проблемы по пути:

• DNS не резолвился → сделал Split DNS на pfSense.

• SSL лучше сразу через Let’s Encrypt, без self-signed.

• Компоненты Jitsi не стыковались → поправил конфиги.

• Медиа не шло → открыл UDP 10000.

• Пользователи за NAT всё равно не могли подключиться → добавил TURN-сервер.

Результат

Теперь у каждого есть ссылка вида https://calls.ДОМЕН/room1. Родственники открывают её в браузере или приложении, подключаются по линку, разговор без ограничений.

Решение получилось достаточно простым в использовании и устойчивым к блокировкам.

Скрипты и инструкции:
http://softcreator.com/static/temp/jitsi_deployment.tar.gz

Notes:
1. В инструкциях я выделил переменные, которые нужно заменить на свое окружение (экономит время).
2. Уверен, вокруг масса инструкций по установке Jitsi, но я ориентировался на простоту установки и селф-хостинг на домашнем бесполезном ноуте.
Такие инструкции не нашел, поэтому наколхозил для себя сам.
3. Первый пост на Хабре за 10+ лет чтения. Сильно не пинайте.

1С и цвет. Как из одной строчки HEX-кода выросла целая библиотека

Все началось с банальной задачи. Я хотел нормально сохранять настройки цветов в конфигурации «Управление IT-отделом 8».

В веб-разработке все привыкли к формату вроде #FABC01. Мне показалось логичным использовать его и в 1С. Это просто, понятно и универсально. Но оказалось, что в платформе нет готовых функций для конвертации такого формата в стандартный тип Цвет. И обратно.

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

Так маленький «велосипед» постепенно оброс фичами и превратился в полноценную библиотеку color1c. Я понял, что решаю не только свою проблему, и выложил инструмент в опенсорс.

Ссылка на GitHub, забирайте: https://github.com/Diversus23/color1c

Что умеет инструмент, если коротко

• Полная конвертация Преобразование между Цвет1С, HEX, RGB, CMYK, HSV и HSL.

• Манипуляции с цветом Смешивание нескольких цветов, получение контрастного или инвертированного цвета, градации серого.

• Получение случайных светлых или темных оттенков, что идеально для диаграмм и графиков.

• Каталоги Встроена работа с каталогами RAL, пастельные цвета и т.д. При этом можно легко добавлять свои.

• Градиенты Расчет градиентного перехода между двумя и более цветами.

• …

Почему это важно не только для разработчика

Этот инструмент не просто для кодеров, он решает три важные задачи для руководителя.

1. Экономия ресурсов. Ваши разработчики перестают тратить часы на написание однотипного кода. Они берут готовую, отлаженную библиотеку и занимаются бизнес-задачей, а не технической рутиной.

2. Единый стандарт. У вас появляется один инструмент вместо десятка разных самописных реализаций. Это сильно упрощает код-ревью, поддержку и развитие всей системы.

3. Качество UX. Удобная работа с цветом позволяет быстро и без боли кастомизировать интерфейс. А хороший UI, как мы знаем, это не просто «красивости». Он снижает количество ошибок пользователя и повышает его производительность.

Мы у себя в «Управлении IT-отделом 8» уже давно перевели всю работу с цветом на этот механизм. Окупилось многократно.

Буду рад, если инструмент окажется полезным и вам. Если есть идеи по доработке или желание внести свой вклад, pull request на GitHub горячо приветствуются.

---

Понравилась моя разработка? В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными инструментами, мыслями и короткими кейсами, которые не всегда доходят до формата большой статьи.

Нагрузочное тестирование GP6 vs GP7 vs Cloudberry

Насколько лучше производительность в GP7 и Cloudberry относительно GP6? Насколько стабильно работают GP7 и Cloudberry? Стоит ли мигрировать с GP6 в 2025? И если да, то на что? Ответы на эти вопросы — в партнерском материале по нагрузочному тестированию GreenPlum 6.X, GreenPlum 7.X и Cloudberry ведущего архитектора группы компаний GlowByte Марка Лебедева.

Материал был анонсирован в статье «Тестирование систем и движков массивно-параллельных вычислений. Часть II. TPC-DS» и продолжает серию публикаций о нагрузочных тестированиях технического руководителя решений Data Ocean Nova и Data Ocean Flex Loader Евгения Вилкова.

Прошиваем CH32V003 с помощью платы Arduino

Задался вопросом, а можно ли сделать программатор из подручных средств для CH32V003 на экстренный случай? Или это еще может пригодится тем, у кого его еще нет.

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

В проекте ch32fun есть программа minichlink, так вот она умеет прошивать WCH микроконтроллеры с помощью разных программаторов, например, b003boot, ardulink, esp32s2chfun. Нас интересует программатор ardulink.

Код программатора Ardulink можно взять из arduino-ch32v003-swio. На гитхабе есть обертка его для PlatformIO, кому как удобнее. Он написан под atmega328p, поэтому спокойно запускается на Arduino Nano. Подсоединяем провод от D8 (PB0) ножки Ардуино к SWIO (например, восьмая ножка у CH32V003J4M6), питание к питанию, земля к земле. Всего 3 провода. (Ножку D9 (PB1) так и не понял к чему подключать, но про нее есть в Readme.)

Дальше выполняем команды:

minichlink.exe -c COM3 -i этой командой можно проверить определяется ли микроконтроллер, где COM3 номер порта платы Ардуино, которую используем как программатор.

minichlink.exe -c COM3 -w .\firmware.bin flash -b а этой командой можно залить файл прошивки, где firmware.bin сам файл.

Пока у меня не получилось подключить такой программатор напрямую к PlatformIO, только получилось работать из командой строки, но при желании это сделать можно.

SourceCraft поддержит опенсорс‑разработчиков: старт грантовой программы с 16 августа и новые возможности платформы

Платформа для разработчиков SourceCraft открывает приём заявок на участие в грантовой программе поддержки: гранты на облачные технологии Yandex Cloud в размере 600 тыс. рублей на год получат важные и интересные опенсорс‑проекты, отвечающие критериям отбора. Подать заявку можно с 16 августа на сайте программы.

Оценивать проекты будут эксперты Яндекса. Среди ключевых критериев оценки:

• активность репозитория,

• актуальность,

• практическая польза проекта,

• понятный вектор развития.

Дополнительно, будет учитываться позиция в общем рейтинге на платформе SourceCraft, которая также пополнилась новыми инструментами:

• интеллектуальным алгоритмом для оценки значимости репозитория,

• системой личных достижений в профилях разработчиков.

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

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

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

CSI-драйвер и Swordfish API: как заставить Kubernetes дружить с любым хранилищем

В современных enterprise-средах важно обеспечить стандартизированный доступ к системам хранения данных (СХД) от разных производителей, избегая жесткой привязки к конкретному вендору. Одним из решений этой задачи является использование CSI-драйвера, который взаимодействует с Swordfish API. Такая интеграция позволяет Kubernetes автоматически создавать, подключать и удалять тома, избавляя команды от множества ручных операций.

Процесс выглядит так: когда приложение в Kubernetes запрашивает постоянное хранилище, оркестратор формирует PersistentVolumeClaim (PVC) с нужными параметрами — размером, типом и характеристиками. Kubernetes определяет, что создание тома должно выполняться через CSI-драйвер, и передает запрос в эмулятор Swordfish API. Тот создает том, а в случае работы с файловыми системами (например, NFS) дополнительно настраивает подключение к серверу и возвращает CSI-драйверу сведения о готовом ресурсе.

Дальше Kubernetes связывает созданный том с заявкой PVC, после чего CSI-драйвер монтирует его на рабочий узел к нужному контейнеру или поду. Эмулятор Swordfish API при этом добавляет путь к каталогу в конфигурацию NFS (/etc/exports), что позволяет клиентам подключаться к сетевому хранилищу.

Когда хранилище больше не нужно:

• DevOps удаляет PVC.

• Kubernetes вызывает NodeUnpublishVolume для размонтирования тома с узла.

• CSI-драйвер передает команду Swordfish API.

• API удаляет том и освобождает ресурсы (в случае NFS — удаляет запись из /etc/exports и каталог).

• Kubernetes удаляет объект PV, завершая процесс.

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

Если интересно, как самостоятельно разработать CSI-драйвер с поддержкой Swordfish API и запустить его даже без реального оборудования, то об этом — в статье, где пошагово показано, как реализовать и протестировать решение.

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

Согласитесь, идея довольно проста: мобильное приложение, в котором можно было бы записывать свои расходы и строить какие-нибудь планы по тратам. Количество таких инструментов в магазинах приложений, по моим ощущениям, сравнимо с количеством самописных будильников и калькуляторов - их довольно много.

Я перепробовал десятки решений, но в каждом находил какие-то ограничения. Где-то были платные подписки или ограниченный функционал, где-то требовалась регистрация и данные о моих расходах улетали на сервера (зачем?), а где-то приложение просто не подходило мне по функционалу. В итоге я решил уйти от готовых приложений к учету в таблицах Excel. Но такой подход тоже был неудобным, и я понял, что пора создать свое собственное приложение: приватное, бесплатное и, самое главное, открытое.

В общем, так появилось Profitocracy - бесплатное Open Source мобильное приложение, написанное на .NET MAUI. Его главная цель — помочь пользователям организовать учет личных расходов по популярному правилу 50-30-20, а также обеспечить конфиденциальность данных. Profitocracy хранит всю информацию локально на вашем устройстве. Приложение не передает никакие данные третьим лицам и полностью свободно от рекламы и монетизации.

Среди основных особенностей приложения я хотел бы выделить:

• Автоматическое планирование бюджета. Вы указываете дату окончания периода (получение зарплаты, например), и приложение расчитает для вас ежедневные расходы, расходы по типам (по правилу 50-30-20), а также по категориям (которые вы можете создать сами).

• Индивидуальная настройка. Вы можете создавать собственные профили расходов: для личных нужд, на время отпуска или поездку в командировку. Причем столько сколько вам потребуется.

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

• Открытый исходный код. Исходный код проекта выложен на GitHub (ссылка на репозиторий). Каждый может внести свой вклад, предложить новый функционал или изучить как работает приложение.

• Кроссплатформенность. Приложение доступно как для Android, так и для iOS.

• Перевод на несколько языков. Profitocracy поддерживает русский, английский и другие языки.

На момент написания поста проект завоевал небольшой, но значимый отклик в сообществе разработчиков:

• 100+ звезд на GitHub;

• 20+ форков;

• 3 активных контрибьютора. Причем, это не мои друзья :)

Ссылки на скачивание:

• Google Play Market

• App Store

Буду рад вашим отзывам, предложениям и комментариям как на GitHub, так и здесь. Надеюсь, Profitocracy поможет вам так же, как оно помогло мне!

OpenAI выпустили в Open Source две бесплатные модели gpt-oss, которые почти не уступают o3 и o4-mini.

Это самые умные модели, которые вы можете запустить у себя дома — маленькая gpt-oss-20b летает на домашнем ПК. А ещё это первый релиз в опенсорс от OpenAI за 6 лет — последний раз они так выпускали GPT-2.

gpt-oss доступна в двух версиях: с 20 млрд и 120 млрд параметров. Для первой для работы требуется минимум 16 ГБ видеопамяти, а для второй — 80 ГБ.

TypeScript и C++ в одном бинаре. Первый open source-проект от МойОфис

Команда МойОфис выложила в open source собственную разработку — компилятор tsnative. Это кроссплатформенный инструмент, который объединяет удобство TypeScript с производительностью C++ в одном приложении. Исходники — на GitHub под лицензией Apache 2.0.

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

AntiQ разделен на два самостоятельных компонента. Сейчас в open source опубликован только tsnative — главный модуль, в котором сосредоточена основная логика и заложены архитектурные принципы всей платформы.

Зачем это нужно?

tsnative — это кроссплатформенный компилятор, преобразующий TypeScript в нативный машинный код. Он обеспечивает бесшовную интеграцию с C++ без glue-кода или JavaScript-движков, объединяя удобство высокоуровневой разработки с производительностью системного кода. В результате вы получаете один бинарник, собранный из двух языков.

Как это работает:

• C++-функции помечаются TS_EXPORT;

• генерируются .d.ts-декларации для TS;

• TypeScript- и C++-код собираются через LLVM;

• на выходе — один исполняемый файл, без обёрток.

// math.cpp
#include "TS.h"
TS_EXPORT int add(int a, int b) {
return a + b;
}
// index.ts
console.log(add(2, 3)); // -> 5

// index.ts
console.log(add(2, 3)); // -> 5

Проект может быть интересен тем, кто:

• делает нативные приложения, но хочет писать часть логики на TS;

• ищет замену закрытым коммерческим компиляторам;

• любит ковыряться в сборке, кросс-компиляции и низкоуровневом коде.

Открытый код — не просто «выложили и забыли». Мы хотим, чтобы проектом пользовались, коммитили, обсуждали. Поэтому будем рады pull request’ам, issue и звёздочкам. Всё как обычно :)

Исходники на GitHub

Если у вас есть вопросы или комментарии, вы можете задать их в чате проекта: https://t.me/antiqmyoffice

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

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

Сравнение производительности 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, обсудим. А также не забывайте ставить звёздочки проекту!

Как мы синхронизировали съемку для возрожденного проекта 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.

С моего последнего поста о Gaunt Sloth Assistant мы достигли ряда достижений.

Напоминаю, Gaunt Sloth — это открытый CLI-клиент ИИ с открытым исходным кодом, написанный на TypeScript и распространяемый через NPM.
Он работает на Linux, Windows и Mac. Основная функция — ревью PR и просто кода. Gaunt Sloth компактный, означает, не пртдётся тратить драгоценные минуты на ожидание установки этого инструмента в build pipeline. Репозиторий на GitHub: https://github.com/Galvanized-Pukeko/gaunt-sloth-assistant.

Gaunt Sloth сейчас на версии 0.9.2, и достижения с момента последнего поста включают:

• Два новых контрибьютора

• Создание примера workflow GitHub для ревью PR. Этот workflow есть в нашем репо, и мне удалось развернуть его в пайплайне сборки на работе: https://github.com/Galvanized-Pukeko/gaunt-sloth-assistant/blob/main/.github/workflows/review.yml (обратите внимание: использование AI-ревью в публичном репо с PR от незнакомцев может привести к утечке ваших API-ключей; do your homework)

• Добавление возможности запускать тесты и lint, так что Gaunt Sloth может закодить фичу целиком (мы используем его для разработки его собственных функций сейчас. Это полезно как часть тестирования)

• Улучшение цикла чата (включая функцию retry, для случаев, когда ИИ выдает раздражающее сообщение "overloaded")

• Подтверждение работы с локальными LLM от Ollama (не все модели работают. Нужна модель с text-generation и tools)

• Добавление пресета для OpenRouter

• Мы пересекли отметку в 500 коммитов

Планы

Большая часть документации находится в двух Markdown-документах. Мне все еще нужно найти время или контрибьютора для создания хорошей, годной документации. Мы, вероятно, будем использовать TypeDoc чтобы скомбинировать сгенерированную документацию и Markdown.

Обновлён бесплатный обучающий Python репозиторий «Think Python, 3rd edition» на GitHub, где есть вся база от основ синтаксиса до продвинутых концепций ООП. Материалы четко структурированы, множество примеров кода. Все оформлено в Jupyter‑notebook — материал легко читается, а по содержанию легко найти нужный раздел.

На Steam Deck вышел неофициальный плагин lsfg‑vk для утилиты Lossless Scaling, позволяющий повысить производительность в играх путём генерации кадров. Для установки плагина на портативный ПК, потребуется сперва купить основную версию Lossless Scaling в Steam, установить менеджер плагинов Decky Loader и открыть в нём архив с lsfg‑vk. После установки плагина для использования генерации кадров в конкретной игре, её необходимо открывать с командой «~/lsfg%command%» в параметрах запуска.

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

Cataclysm: Dark Days Ahead (2025) — как живёт и развивается roguelike, который до сих пор учит выживать

Игра без маркетинга. Без издателя. Без бюджета. Но с кодом, который живёт дольше многих ААА-проектов. Почему Cataclysm DDA всё ещё актуальна — и что из неё может почерпнуть разработчик?

📌 Что это вообще за игра?

Cataclysm: Dark Days Ahead (или просто CDDA) — roguelike-выживалка с открытым исходным кодом. Изначально создана в 2010-х, проект уже давно перерос статус инди-хобби. Вокруг игры сформировалась уникальная архитектура разработки, напоминающая open-source проекты вроде Godot или Blender.

При этом CDDA — это не просто «рогалик». Это огромный симулятор выживания, в котором учитывается всё: климат, диета, микроорганизмы, ткани, генетика, сила удара, источник света, запах, химия топлива, рефлексы NPC…
Она не для всех — но от неё сложно оторваться.

🧬 Почему она до сих пор развивается?

Проект жив благодаря:

• Cообществу разработчиков, регулярно вносящих правки на GitHub

• Модульной архитектуре — почти всё, кроме движка, вынесено в JSON

• Открытому патч-процессу: pull-request может отправить любой желающий

• Строгому CI — игра проверяется на стабильность при каждом изменении

CDDA — это не Unity и не Unreal. Но это отличный пример того, как жить без них. Игра написана на C++ с минимальной внешней зависимостью и на удивление гибкой логикой.

🧠 Архитектура и интересные решения

• 📁 JSON Everywhere: почти все предметы, существа, профессии, здания, сценарии, книги, мутанты и их поведение — вынесены в конфиги. Даже атакующие свойства NPC настраиваются без перекомпиляции.

• 🧪 Эволюция и симуляция: монстры «видят» запах, запоминают игрока, боятся огня, ищут пищу, воспринимают звуки и реагируют на источник света.

• 🔧 Модификации на лету: моддинг работает в реальном времени. Можно изменить структуру мутанта или добавить новую машину, не трогая движок.

• 🛠 Технический долг признан открыто: разработчики не скрывают костыли. В issues открыто обсуждаются недоработки, устаревшие решения и предложения по рефакторингу.

🎮 Почему стоит попробовать?

Если ты разработчик — это почти живая документация по построению системной игры с открытым исходником.
Если ты игрок — это один из самых глубоко проработанных симуляторов выживания с огромной свободой действий.

🤔 А если хочется поучаствовать?

• Репозиторий: github.com/CleverRaven/Cataclysm-DDA

• Discord-разработка: discord.gg/cataclysmdda

• Редактировать можно всё: от предметов и диалогов — до поведения монстров

• Написать мод — можно за вечер

💬 И всё же...

Что делает старый roguelike привлекательным даже в 2025 году?
Что заставляет людей править JSON-файлы, компилить на локальной машине, и устраивать «чистки баланса» спустя 10 лет после релиза?

Возможно, потому что эта игра живёт, а не просто запускается.

Мой обзор на YouTube: https://www.youtube.com/live/B_IGiKw2BuQ
Дубликат на RuTube: https://rutube.ru/video/a91c9c71da3808af7381b87e10e5daca/

Joomla: как тестировать? Всего 8 минут.

Над CMS Joomla постоянно ведётся работа: создаётся новый функционал, исправляются ошибки, делаются мелкие правки. Разработка ведётся на GitHub. Изменения оформляются в виде Pull Request (PR). Для того, чтобы изменения могли войти в ядро - их обязательно должны успешно протестировать минимум 2 человека КРОМЕ автора изменений. А помочь с большинством PR можно очень и очень быстро, это не занимает много времени, чему подтверждением служит это видео.

Смотреть видео на YouTube

Смотреть на Vk Video

Смотреть на RuTube

Аркадный автомат на RISC-V: сбиваем астероиды с микроконтроллером MIK32 АМУР

Вадим Новиков решил реализовать игровую физику в условиях bare metal, используя свой предыдущий опыт на C++/SFML. В проекте использовалась плата Elbear Ace-Uno на базе микроконтроллера MIK32 АМУР, SPI OLED-дисплей SSD1306 разрешением 128×64 и джойстик HW-504 (KY-023), а также модули SPI (цифровой интерфейс передачи данных), аналого-цифровой преобразователь для калибровки и чтения положения джойстика и GPIO для вывода настройки и ввода состояния кнопки.

Код на C включал непрозрачные типы, которые позволяют реализовать подобие инкапсуляции из ООП. С ними можно объявить в заголовочном файле указатель на некую структуру, но не определять ее. А в единственной трансляции определить структуру и статические функции для взаимодействия с внутренними полями, которые недоступны извне. И поместить туда, соответственно, реализацию открытого интерфейса. Вместо использования регистров напрямую Вадим подключил библиотеку hardware abstraction layer (HAL), чтобы впоследствии было проще портировать проект на STM32 и другие микроконтроллеры.

Результатом работы стала Asteroids — реинкарнация классической игры эпохи аркадных автоматов. Корабль игрока непрерывно выпускает снаряды. После столкновений снаряда с астероидом исчезают оба объекта, при столкновении с кораблем — только астероид. Астероиды, вышедшие за нижнюю границу, возвращаются сверху экрана. Корабль же выйти за границы экрана не может.

Это лишь один из интереснейших проектов, реализованных студентами по итогам последнего потока курса YADRO по программированию микроконтроллеров на RISC-V. Интересно узнать о других проектах? Мы уже рассказали о них в статье.