Почему разработчикам опенсорсных приложений для Android может не потребоваться подтверждать свою личность
Недавно Google анонсировала, что скоро смартфоны на базе Android будут работать только с приложениями, чьи разработчики подтвердили свою личность непосредственно Google. Но как это будут проверять? Напрашивается проверка по ключам подписи, но погодите-ка…
Если вы более-менее интересуетесь опенсорсом, наверняка вы слышали про “магазин” F-Droid. Что примечательно в нём — все приложения в его главном (единственном по умолчанию) репозитории собираются из исходников и подписываются одной сущностью — F-Droid. Эта особенность делает данный источник приложений уникальным в своём роде — в Google Play или RuStore каждый разработчик собирает и подписывает приложение сам.
Если Google не передумает и действительно введёт блокировку на “анонимных” разработчиков, вполне возможно, что F-Droid просто создаст единый аккаунт для своего ключа подписи, и продолжит спокойно предоставлять приложения даже на “сертифицированных” Android-девайсах.
Но наверняка вы скажете, что там распространяются приложения, неугодные Google, и будете правы. Однако они и так ломаются каждый месяц самой же корпорацией ввиду открытых исходников этих приложений и способов парсинга контента без официального API. Так что, думаю, обойдётся.
На GitHub вышел открытый проект SeedBox Lite, который позволяет развернуть аналог Netflix у себя дома. Решение предоставляет библиотеку контента с торрентов — в бесплатном доступе все фильмы мира. Мгновенный старт — смотрите сразу, не дожидаясь загрузки. Плеер как у стримингов: субтитры, фуллскрин, жесты. Работает на смартфоне, планшете и ПК и вообще всем, где есть браузер. Можно закрыть паролем. Устанавливается за минуты по простому гайду.
Выводит материалы Joomla в виде меток на Яндекс.Карты. Используется API 3.0.
v.2.1.0. Что нового?
Сохранение последнего вида карты. Добавлены новые опции, позволяющие как для одного экземпляра модуля, так и для всех сохранять на устройстве пользователя последний использованный центр (координаты) и масштаб (zoom) карты. Это позволит открыть карту в том же месте после обновления страницы или при повторном открытии браузера.
Определение местоположения пользователя. Модуль может определять местоположение пользователя и центрировать карту на нём. При одновременном использовании с функцией сохранения последнего вида карты определение геопозиции будет срабатывать только в первый раз. В дальнейшем, если обнаружены сохранённые данные центра и масштаба - будут использоваться они.
CSS классы для маркеров карты. Всем маркерам карты добавлен CSS-класс wt-yandex-map-items-marker. Для просмотренных маркеров (по которым кликали) добавляется CSS-класс wt-yandex-map-items-marker-viewed, что позволит выделять просмотренные маркеры с помощью стилей в CSS-файлах вашего шаблона. Также для контейнеров маркеров ymaps на карте добавлены data-атрибуты: data-module-id - id модуля и data-marker-id - id маркера.
Обработка GET-параметров в URL.
Карта может реагировать на GET-параметры в url:
map[zoom] - устанавливает параметр масштаба.
map[center_latitude] и map[center_longitude] - широта и долгота центра карты.
map[marker_id] - id маркера, на котором центрируется карта. Таким образом вы можете создавать ссылку на карту с указанием конкретного маркера, на котором карта сфокусируется после загрузки маркеров. Например, https://site.ru/map?map[marker_id]=18465. Или же ссылку с указанием конкретных координат: https://site.ru/map?map[zoom]=16&map[center_latitude]=51.529706&map[center_longitude]=46.033922
Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.
Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.
Название поля НАД полем - parentclass="stack".
Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.
2 и более полей в ряд в параметрах модуля/плагина - классы span-*
Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.
span-1-inline - поле будет шириной в 1 колонку сетку. span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию. Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.
Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.
Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.
Название поля НАД полем - parentclass="stack".
Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.
2 и более полей в ряд в параметрах модуля/плагина - классы span-*.
Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.
span-1-inline - поле будет шириной в 1 колонку сетку.
span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию.
Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.
Мой обход блокировок Telegram и WhatsApp (колхозный?)
Живу в за пределами России и часто общаюсь с родственниками и друзьями из России. Основное общение всегда было через Скайп, Telegram и WhatsApp.
Скайп помер в Мае, а когда звонки начали глючить в Telegram и WhatsApp, сначала подумал, что у мамы Wi-Fi тупит. Просил перезагрузить роутер, попробовать выйти на улицу. Затем спросил знакомых, почитал новости и прозрел - звонки глючат у всех. MAX.
Что попробовал:
VPN на телефоне → тяжело для пожилых родственников, NordVPN - два года подписки в топку.
Viber → работает, но нестабильно.
Zoom → громоздкий для простых звонков.
Нужен более простой и независимый способ.
Решение
После поиска остановился на Jitsi Meet — системе для видеозвонков с открытым кодом. Её можно развернуть на своём сервере и не зависеть от блокировок.
Настройка
Поднял виртуалку на Ubuntu.
Настроил pfSense с NAT и SSL.
Установил Jitsi Meet в Docker.
Мои проблемы по пути:
DNS не резолвился → сделал Split DNS на pfSense.
SSL лучше сразу через Let’s Encrypt, без self-signed.
Компоненты Jitsi не стыковались → поправил конфиги.
Медиа не шло → открыл UDP 10000.
Пользователи за NAT всё равно не могли подключиться → добавил TURN-сервер.
Результат
Теперь у каждого есть ссылка вида https://calls.ДОМЕН/room1. Родственники открывают её в браузере или приложении, подключаются по линку, разговор без ограничений.
Решение получилось достаточно простым в использовании и устойчивым к блокировкам.
Notes: 1. В инструкциях я выделил переменные, которые нужно заменить на свое окружение (экономит время). 2. Уверен, вокруг масса инструкций по установке Jitsi, но я ориентировался на простоту установки и селф-хостинг на домашнем бесполезном ноуте. Такие инструкции не нашел, поэтому наколхозил для себя сам. 3. Первый пост на Хабре за 10+ лет чтения. Сильно не пинайте.
1С и цвет. Как из одной строчки HEX-кода выросла целая библиотека
Все началось с банальной задачи. Я хотел нормально сохранять настройки цветов в конфигурации «Управление IT-отделом 8».
В веб-разработке все привыкли к формату вроде #FABC01. Мне показалось логичным использовать его и в 1С. Это просто, понятно и универсально. Но оказалось, что в платформе нет готовых функций для конвертации такого формата в стандартный тип Цвет. И обратно.
Пришлось написать пару небольших процедур. А потом закрутилось. Раз уж я работаю с HEX, почему бы не добавить смешивание цветов? А потом генерацию случайных оттенков для диаграмм? А потом градиенты?
Так маленький «велосипед» постепенно оброс фичами и превратился в полноценную библиотеку color1c. Я понял, что решаю не только свою проблему, и выложил инструмент в опенсорс.
Полная конвертация Преобразование между Цвет1С, HEX, RGB, CMYK, HSV и HSL.
Манипуляции с цветом Смешивание нескольких цветов, получение контрастного или инвертированного цвета, градации серого.
Получение случайных светлых или темных оттенков, что идеально для диаграмм и графиков.
Каталоги Встроена работа с каталогами RAL, пастельные цвета и т.д. При этом можно легко добавлять свои.
Градиенты Расчет градиентного перехода между двумя и более цветами.
…
Это демонстрация, но здесь продемонстрировано гораздо меньше возможностей чем есть под капотом
Почему это важно не только для разработчика
Этот инструмент не просто для кодеров, он решает три важные задачи для руководителя.
Экономия ресурсов. Ваши разработчики перестают тратить часы на написание однотипного кода. Они берут готовую, отлаженную библиотеку и занимаются бизнес-задачей, а не технической рутиной.
Единый стандарт. У вас появляется один инструмент вместо десятка разных самописных реализаций. Это сильно упрощает код-ревью, поддержку и развитие всей системы.
Качество UX. Удобная работа с цветом позволяет быстро и без боли кастомизировать интерфейс. А хороший UI, как мы знаем, это не просто «красивости». Он снижает количество ошибок пользователя и повышает его производительность.
Мы у себя в «Управлении IT-отделом 8» уже давно перевели всю работу с цветом на этот механизм. Окупилось многократно.
Буду рад, если инструмент окажется полезным и вам. Если есть идеи по доработке или желание внести свой вклад, pull request на GitHub горячо приветствуются.
---
Понравилась моя разработка? В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными инструментами, мыслями и короткими кейсами, которые не всегда доходят до формата большой статьи.
Насколько лучше производительность в GP7 и Cloudberry относительно GP6? Насколько стабильно работают GP7 и Cloudberry? Стоит ли мигрировать с GP6 в 2025? И если да, то на что? Ответы на эти вопросы — в партнерском материале по нагрузочному тестированию GreenPlum 6.X, GreenPlum 7.X и Cloudberry ведущего архитектора группы компаний GlowByte Марка Лебедева.
Задался вопросом, а можно ли сделать программатор из подручных средств для 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 через CSI-драйвер и Swordfish API
Дальше 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 активных контрибьютора. Причем, это не мои друзья :)
Это самые умные модели, которые вы можете запустить у себя дома — маленькая 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 и звёздочкам. Всё как обычно :)
Представлен открытый редактор таблиц 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).
Порядок выполнения одного теста:
Открытие новой страницы в браузере.
Инициализация PerformanceObserver.
Начало сбора метрик.
Рендеринг компонентов.
Завершение сбора метрик.
Процесс измерения:
В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.
Результаты
Результаты замеров не содержат в себе абсолютных цифр. От окружения к окружению они, конечно же, могут варьироваться. Но этих цифр вполне достаточно, чтобы увидеть некоторые зависимости и сделать на их основании выводы:
@gravity‑ui/uikit показывает конкурентоспособные результаты:
В большинстве тестов находится в верхней части рейтинга.
Демонстрирует стабильное время рендеринга при разном количестве нод.
Особенно эффективен в компонентах Button, Checkbox и Switch.
Имеет проблемы со временем рендера компонента TextArea.
@mui/material также показывает хорошие результаты:
Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.
Имеет видимый рост времени рендера в зависимости от количества нод.
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.
Вырезка из коммента оставленного тощим ленивцем к PR на GitHub
Gaunt Sloth сейчас на версии 0.9.2, и достижения с момента последнего поста включают:
Добавление возможности запускать тесты и lint, так что Gaunt Sloth может закодить фичу целиком (мы используем его для разработки его собственных функций сейчас. Это полезно как часть тестирования)
Улучшение цикла чата (включая функцию retry, для случаев, когда ИИ выдает раздражающее сообщение "overloaded")
Подтверждение работы с локальными LLM от Ollama (не все модели работают. Нужна модель с text-generation и tools)
Добавление пресета для OpenRouter
Мы пересекли отметку в 500 коммитов
Планы
Большая часть документации находится в двух Markdown-документах. Мне все еще нужно найти время или контрибьютора для создания хорошей, годной документации. Мы, вероятно, будем использовать TypeDoc чтобы скомбинировать сгенерированную документацию и Markdown.
