Open source *

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

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

Я перепробовал десятки решений, но в каждом находил какие-то ограничения. Где-то были платные подписки или ограниченный функционал, где-то требовалась регистрация и данные о моих расходах улетали на сервера (зачем?), а где-то приложение просто не подходило мне по функционалу. В итоге я решил уйти от готовых приложений к учету в таблицах 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. Интересно узнать о других проектах? Мы уже рассказали о них в статье.

Repeater - планировщик для анализа данных, упрощенный Apache Airflow.

Repeater запускает задачи по расписанию. Задачи - последовательности консольных программ - описываются в toml-файлах. Запуски отображаются в веб-интерфейсе.

Пример задачи - запуск скриптов wiki_stats.py и wiki_pageviews.py импорта верхнеуровневой статистики Википедии в локальную базу.

title = "wiki"
cron = "0 55 * * * *"

[[tasks]]
name = "wiki_stats"
cmd = "python3 ./examples/wiki_stats.py"   

[[tasks]]
name = "wiki_pageviews"
cmd = "python3 ./examples/wiki_pageviews.py --end_date={{.scheduled_dt}}"

Бэкэнд написан на Go. Команды ниже запустят Докер-контейнер с сервисом и окружение для примеров:
- Repeater http://localhost:8080 - планировщик
- ClickHouse http://localhost:8123 и http://localhost:9000 - база данных
- ch-ui http://localhost:8001 - веб-интерфейс к базе данных
- Streamlit http://localhost:8002 - дашборды

git clone https://github.com/andrewbrdk/Repeater
cd Repeater
docker compose up --build

В примерах импорт количества просмотров страниц Википедии, курса биткоина, статистики репозитория Линукса на Гитхабе. Графики в Streamlit http://localhost:8002 .

Интересны применения проекта. Попробуйте! Впечатления пишите в комментариях. Спасибо!

Репозиторий: https://github.com/andrewbrdk/Repeater

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

Например, владельцу продукта может придти в голову идея внедрить жесткую монетизацию каких-либо фичей, или вставить рекламу, или изменить условия лицензии на часть кода, сделав её проприетарной, а не свободной.

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

Так появился проект CoMaps - полностью оффлайновые и бесплатные карты для мобильных устройств с фокусом на приватность: в приложении нет каких-либо трекеров, мы не собираем и не передаем кому-либо каких-либо данных.

А приставка "Co" намекает, что это именно community-driven проект, где ключевые решения принимаются после обсуждения внутри всего сообщества контрибьюторов и при необходимости - после сбора мнений путем голосования за тот или иной вариант.

За прошедшие три месяца команде разработчиков удалось наладить стабильную сборку приложения и карт из OpenStreetMap, провести доработку части функциональности приложения. Например, добавили изолинии (рельеф) с шагом 100 метров для всех возможных территорий, сделали локальный бэкап меток и записанных треков, изменили на более удобный для восприятия (ну, нам так кажется) картостиль.

Дальнейшее развитие проекта предполагает как развитие текущих и создание новых фичей на основе сбора обратной связи от самих пользователей, так и формализация самого статуса проекта. Прямо сейчас мы обсуждаем и рассматриваем разные варианты, в том числе создание "нон-профит" организации; или же можем придти под крыло какой-нибудь известной организации вроде SFC или подобной.

Так как сегодня, 3 июля 2025, мы сделали первый публичный релиз приложения в сторах, приложу пачку ссылок на ключевые ресурсы проекта:

• https://comaps.app - сайт проекта (там можно найти всю рабочую внутрянку - матрикс/телеграм/zulip чаты, репозитории, таск-трекинг, инструкции как присоединиться к разработке со своими идеями, и т. д.)

• Google Play Store: https://play.google.com/store/apps/details?id=app.comaps.google

• Apple App Store: https://apps.apple.com/app/comaps/id6747180809

• F-Droid: https://f-droid.org/packages/app.comaps.fdroid/

Такие дела.

Открыта регистрация на Kubernetes Community Day — главную сходку K8s-сообщества

31 июля в Москве состоится первая независимая конференция Kubernetes Community Day для открытого сообщества профи по куберу и тех, кто только начинает. Два пространства с техническими докладами, дискуссиями и хардкорными воркшопами, интерактивы и IT StandUp. Никаких HR-стендов и дорогих билетов — только бесплатное участие, сообщество, живое общение.

Цель мероприятия — создать площадку для объединения сообщества, обмена опытом и нетворкинга. В программе — актуальные выступления от коллег из различных компаний, которые дышат контейнерами: Yandex Cloud, ecom.tеch, VK, Luntry, МКБ, «Лаборатория Числитель», Lamoda Tech, Rebrain, Cloud ru и др.

Среди заявленных тем:

• «Legacy-кубы и как нежно увезти с них продукты»

• «Ретроспектива уязвимостей системных компонентов Kubernetes»

• «Блеск и нищета Cluster API Kubernetes»

• «Почему K8s — плохой продукт и он вам не нужен?»

• «Как мы переизобрели UI для Kubernetes: динамический фронт на основе OpenAPI и CRD».

Полная программа будет объявлена позже.

Зачем идти?

• Послушать истории коллег про реальные кейсы, факапы и «боли». 

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

• Встретиться со старыми друзьями и найти новых.

• Внести свой вклад в сообщество.

Формат: офлайн и онлайн.

Участие бесплатное. Количество мест на офлайн ограничено площадкой — успейте зарегистрироваться!

Следите за анонсами мероприятия в Telegram-канале генерального партнера конференции — платформы «Штурвал».

Информационные партнеры: Computerra, ICT Online, Cybermedia, Global Digital Space, AM Live, ict2go, Kubernetes_ru, DevOps For Love, IT STAND.

Представлен обновлённый проект Awesome Black Hat Tools, где собраны все инструменты, которые когда-либо были представлены на ИБ-конференциях Black Hat. Инструменты аккуратно структурированы по странам, где проходила конференция, по годам и категориям Red Teaming, Blue Teaming, OSINT & Recon, Exploit Development, Malware Analysis, DFIR & Forensics, Threat Intelligence, ICS/IoT/SCADA и Application Security (AppSec).

Также все презентации с выступлений Black Hat, начиная с 2023 года, собраны на отдельной странице GitHub.

Прошло довольно много времени с тех пор, как я в последний раз что-либо публиковал на Хабре, около 10 лет или около того, и сегодня настал день, чтобы поделиться своим небольшим Open Source проектом.

Проект под названием Gaunt Sloth Assistant — это CLI-клиент для ИИ (AI), созданный на TypeScript (LangChain.js), распространяемый через npm и работающий в Linux, Windows и Mac. Пользователь полностью контролирует промпты, и рекомендуется формировать свои собственные системные промпты, но у него также есть и стандартный.

GitHub: https://github.com/andruhon/gaunt-sloth-assistant

NPM: https://www.npmjs.com/package/gaunt-sloth-assistant

В настоящее время Gaunt Sloth имеет dependencies, позволяющие использовать простую конфигурацию JSON для VertexAI, Anthropic, Groq, DeepSeek, OpenA. Теоретически он должен работать с любой моделью, поддерживаемой LangChain; есть даже package для Яндекса, который я никогда не пробовал, но думаю, он должен работать, если установить пакет и предоставите конфиг в JS. OLLAMA? Возможно, это сработает; я никогда не пробовал, но буду признателен, если кто-нибудь поделится своим опытом.

Gaunt Sloth может просматривать запросы на слияние и сопоставлять их с требованиями из задачи Jira или GitHub, просматривать локальные различия, общаться в чате, имеет доступ к файловой системе и может записывать код в файловую систему.

Gaunt Sloth — это универсальный инструмент с рядом полезных возможностей:

• Просматривает запросы на слияние (например 42) и сопоставляет их с требованиями из задачи Jira или GitHub (например 12).

  • gth pr 42 12

• Просматривает локальные различия.

  • git --no-pager diff | gth review

• Предоставляет интерактивный сеанс чата.

  • gth chat

• Имеет доступ к файловой системе для чтения и записи кода.

  • gth code

Конечно, у него есть MCP и OAuth, так что вы можете подключиться к удаленному MCP, такому как Jira, и создавать и редактировать issues "like a boss".

У него также есть крошечная функция, которая может регистрировать время по задаче Jira, когда она заканчивает проверку PR. Это еще не задокументировано, но вы можете найти пример конфигурации в примечаниях к выпуску или спросить меня в комментариях (насколько я знаю, Jira MCP этого делать не может).

Кроме того, вы можете поставлять простые локальные инструменты ИИ в формате инструментов LangChainJS, такие как этот:

import { tool } from "@langchain/core/tools";
import { z } from "zod";
const multiply = tool(
  ({ a, b }: { a: number; b: number }): number => a * b,
  {name: "multiply", description: "Multiply two numbers", schema: z.object({ a: z.number(), b: z.number(), })}
);

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

Зачем?

Несколько месяцев назад я искал CLI-помощника на базе LangChainJS/LangGraphJS и не нашел многого. Был фактор любопытства и другие факторы.

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

Например gth code, говорите implement requirements.md, чтобы он прочитал файл и начал кодить.

GeminiCli, ClaudeCode? Они не были официально выпущены, и я не знал, что они находятся в разработке. Aider, Goose? Конечно, они вероятно лучше, но в них сложнее вносить свой вклад и добавлять нужные вам функции.

И что?

У меня больше идей по созданию функций, чем времени.
Приветствуются контрибьюторы.
Попробовать его и создать issue или поделиться отзывом — это тоже вклад; PR был бы еще лучше.

UART-сенсоры и браузер: читаем воздух через браузер на sensor.pollutants.eu

Привет, Хабр!
Делюсь своим простым, но мощным инструментом: веб-интерфейс для чтения данных с UART-сенсоров прямо через браузер. Да, без установки чего-либо. Просто открываешь страницу — и видишь, что творится в воздухе.

🤔 Зачем всё это?

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

И тут пришла идея: а почему бы не сделать всё в браузере?

🌐 HTML + JS + JSON = 👌

Ты заходишь на sensor.pollutants.eu, выбираешь нужный сенсор из списка (если в JSON их несколько), подключаешься к COM-порту — и данные потекли.

Без установки. Просто HTML-страница, в которой уже всё встроено:

• работа с Web Serial API,

• парсинг бинарных фреймов по структуре из JSON,

• визуализация данных через Chart.js,

• конфигурация через внешний JSON-файл.

• скачивание статистики в CSV

⚙️ Конфигурация сенсоров

Конфиг грузится с GitHub и содержит несколько сенсоров. Можeте загрузить свой JSON.
Проект на hackaday

Можно ли развернуть кластер Kubernetes на процессоре с открытой архитектурой RISC-V?

Короткий ответ: нет.

К сожалению, на данный момент «классический» K8s неполноценно портирован на RISC-V. Один из необходимых модулей K8s — kubelet — отказался запускаться на RISC-V-машине (в роли нее — микрокомпьютер Lichee Pi 4A).

Зато облегченная версия оркестратора K3s и Docker Swarm заработали на RISC-V, но с разными компромиссами:

→ Docker Swarm проще в развертывании.

→ K3s — более гибкий в работе, так как поддерживает Kubernetes-инструменты.

В синтетических тестах (stress-ng) K3s показал лучшую производительность на матричных вычислениях — он обошел показатели Docker Swarm примерно в 16 раз. В цифрах: 2.996 bogo ops/s (K3s) против 188 bogo ops/s (Docker Swarm). Возможно, это связано с оптимизацией Kubernetes или меньшими накладными расходами: K3s потребляет меньше ресурсов на фоновые процессы, такие как управление кластером и сетью, что важно для маломощных устройств.

Интересно узнать больше? Тогда переходите по ссылке и читайте подробности экспертимента по заапуску известных оркестраторов на RISC-V.