DIY или Сделай сам

Неисповедимы пути ©
Как проектирование ЧПУ станков довело
до церковнославянского справочника.
И неясно, куда занесет ещё.

Я инженер. Работаю с достаточно сложными проектами в нефтянке
в роли СТО да проектного менеджера с упором на технические вопросы.
Всякое там ТОиР, стройка, проектирование, производство, КиП и тому подобное

Как частный личный проект с год назад с товарищами
задумали и начали делать 3–4 осевые ЧПУ станки небольших форматов.
Итогом добрались до церковнославянского сайта‑справочника и нейросеток.
Грабли банальные, если оглядываться назад и, видимо,
для многих «в теме» очевидные. Но мы по ним
оттоптались знатно. Думаю — будет еще много

Логика странная, но есть.
1. Для отработки конструкционных решений — нужно делать тесты.
Для наших ЧПУ — что‑то с большим количеством мелких элементов,
достаточно объемное и сложное. При этом недорогое и, чтоб не в мусор,
если получается что‑то приятное. Ибо обидно выкидывать.
Случайно наткнулись на православные иконы из дерева.
Подходит. Пробуем. Для отработки нюансов с ЧПУ оказалось шикарно.

2. Проект нежданно расширился в сторону производства икон. Ибо интересно.
Наловили кучу факапов и тонкостей с материалами, фрезами, химией.
Будучи агностиками по сути, реально получаем удовольствие. Факт.
Выяснилось, что тут свой большой объемный и непростой мир. Забавно.
Кардинально пересмотрели некоторые инженерные решения по станкам. Cool

3. Проект расширился в сторону 3D моделирования.
Выяснили, что 3D моделей хороших мало. При том количестве разного,
что «в интернетах есть» — реально качественного и достойного очень немного.
Есть свои тесные сообщества со своими правилами и ценами,
репутацией, рейтингами и «чужим входа нет».
Нейросетки не катят, как оказалось. Увы. «Все ручками».
Поэтому жесткая и очень ресурсная наработка опыта
работы с моделированием трехмерного разного.

4. Проект расширился снова, теперь в програминг для станков. Оказалось,
что есть глобальная разница в G‑code для станка по разному сделанного.
Одна и та‑же модель на одном железе дает кратно разные результаты.
Итогом курсы, обучение, тесты, бессонные ночи и в 2 раза меньше
машинного времени при сильно лучшем результате на той‑же «базе»
Ибо 28 часов работы станка на одно изделие, и 15 таки
существенная разница по всем понятиям.

5. И снова проект расширился. Теперь в сторону информационную.
При всей «банальности» иконы как объекта, нашлась уйма нюансов.
Оказалось, что все сильно непросто в части надписей, шрифтов,
расположений элементов и тому подобных «мелочей». И даже
в епархиях часто спорят и не знают, как «правильно» и «нужно».
Итогом — сайт‑справочник, с надписями, словарем, шрифтами,
написанием и кучей новых (для нас) знаний о старославянском.

6. И снова расширение. Потому что моделей уже сотни,
вариантов куча, программы разные, фото‑видео копятся.
Нужно это все каким‑то образом хранить, холить и лееять.
Да и показывать надо порой выбранные вещи, что уже сложно
в части оперативного поиска да выборки. Банальные каталоги
где‑то на облаке не рабочее решение. Увы.
И снова в помощь codex да grok, и снова
очередной проект, теперь хранилища.

Зачем пишу?
Поделиться очередной иллюстрацией того,
как жизнь порой разворачивается в странные
и забавные проекты, задачи, решения, контакты.
Как относительно простой проект вдруг превращается
превращается, превращается в шорты © в какую‑то экосистему,
и укапывание в неизвестные досель области знаний.

Открытый проект KeyForge3D позволяет преобразовать фотографию ключа в файл для 3D-печати. Приложение выделяет контур ключа, добавляет ему толщину и сохраняет результат в STL для дальнейшей печати. Система работает локально без нейросетей и подписок — внутри обычный OpenCV.

Школьница Светлана под руководством двух инженеров - меня и ее отца - освоила концепции трех технологий проектирования схем и теперь демонстрирует их на этом видео:

1. Сборка цифровых схем на макетной плате с микросхемами малой степени интеграции. Этот метод старинный, изобретен еще в 1968 году, но и сейчас годен для обучения школьников начиная с детсада (мы вчера видели как 6-летний понял функциональность логического элемента XOR). Светлана показывает на видео схему с ALU которую она собрала.

2. Синтез схем из кода на языке описания аппаратуры SystemVerilog с реализацией в микросхемах реконфигурируемой логики FPGA. Этот способ широко применяется для прототипирования, специальных приложений (например в космических ракетах SpaceX и Blue Origin) и обучения студентов (см. напр. курс MIT 6.111).

3. Синтез для микросхем ASIC. Этот способ применяется последние 35 лет для всех массовых устройств. Смартфон который вы держите в руках - это несколько ASIC-ов и окружающая их периферия.

Светлана будет присутствовать на Zoom-звонке на русской части лекций, которые будет читать наш коллега из Грузии Леваном Чагелишвили, где мы покажем плату TinyTapeout в действии. Вы можете подключиться по линку

https://bit.ly/yuri-panchul-zoom

Chip Designed in the Country of Georgia: ASIC design flow and prototyping on FPGA

Чип спроектированный в Грузии: разбор маршрута проектирования для ASIC и прототипирования на FPGA

Пятница 18 сентября, 8 am по Калифорнии, 19.00 по Тбилиси, 18.00 по Москве: лекция на английском.

Cуббота 19 сентября, 8 am по Калифорнии, 19.00 по Тбилиси, 18.00 по Москве: лекция на русском.

Воскресенье 20 сентября, 8 am по Калифорнии, 19.00 по Тбилиси, 18.00 по Москве: лекция на грузинском.

Ждем вас на лекции!

Экстремальная модернизация охлаждения домашнего сервера. 9⁰С в простое, 60 в полной нагрузке (1250 Вт)

Было 60 и 90.

🤡 Новый фреймворк на NodeJS

Это не draft, а работающий код из прода. Посмотрите код сервиса, код http контроллера и код декларации

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

import { provide, inject } from "di-kit";

export class WalkerLogicPublicService {

  private readonly loggerService = inject<LoggerService>("loggerService");

  ...

}

...

provide("loggerService", () => new LoggerService());

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

import { createActivator } from "di-kit";

export const { init, inject, provide } = createActivator("separate-scope");

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

Пораскинув в хорошем смысле мозгами, сделал такую подборку:

• Основа — linux, linux-firmware, grub, runit, coreutils, util-linux, kmod, shadow, kbd

• Сеть — iproute2, dhcpcd, ca-certificates

• Окружение — kmscon/fbterm, tmux, nerd-fonts, mc

• Мастхэв: sudo, file, procps-ng, neovim, git, wget, openssh, openssl, gcc, make, glibc, tar, zstd, unzip, less, grep, sed, awk, findutils, man-db, man-pages

Если немножко додать жиру, то — yazi, neomutt, lynx/w3m, newsboat, alsa-lib, alsa-utils, mpv.

Наверняка чего-то упустил / чего-то захочется ещё. Но такова природа человека… Иначе до пятидесятого гнома мы бы не дошли.

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

И распивая чаи со спиртом (опционально), буду читать здесь холивары о гноме и кедах 😁

Пост выходного дня посвящу не столько профессиональным делам, сколько хобби)

Я занимаюсь фехтованием (HEMA, рапира) - и перед соревнованиями мы проводим спарринги по всем правилам, с таймером и подсчётом очков. Ещё в прошлом году я решил упростить работу судьи, собрал в Lovable простое одноэкранное веб-приложение, и испытал его на ближайшей же тренировке.

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

К счётчику очков/таймеру добавились:

• ростер бойцов (уже на отдельном бэкенде);

• хранение истории боёв;

• статистика.

То есть вырос уже MVP для небольших клубов. И на этом я не останавливаюсь, планов ещё много)

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

https://fencing-scorer.konbo.me 

Это по-прежнему веб-приложение, не требует установки. Но свёрстано сразу под телефоны, чтобы было всегда под рукой. Чтобы просто считать очки в спаррингах регистрация не требуется (она нужна только для истории и статистики) - можно просто нажать на "Быстрый бой" внизу.

Погонял llama.cpp на пяти NVIDIA CMP 90HX и сравнил layer split с tensor split.

Конфигурация:

• 5 × NVIDIA CMP 90HX по 10 ГБ

• суммарно llama.cpp видит 49 383 MiB VRAM

• 4 карты подключены по PCIe x8

• 1 карта подключена по PCIe x4

• применен rejoin15

• модель - Qwen3.8-27B-Heretic

• квант - Q8_0

• размер GGUF - 26.62 GiB

• параметров - 26.90B

• llama.cpp build e107984

• распределение по GPU - 1/1/1/1/1

• все слои загружены на GPU

• KV cache - F16, тоже на GPU

• Flash Attention - auto

С tensor split картина получилась довольно интересная.

На пустом контексте генерация выросла с 23.76 до 31.93 tok/s. Это примерно +34%.

На 32K контекста - с 22.15 до 31.06 tok/s, то есть уже около +40%.

Для чистой генерации tensor split реально быстрее.

Но есть обратная сторона - prompt processing просел очень сильно.

На пустом контексте:

• Layer - 1992.67 tok/s

• Tensor - 268.46 tok/s

На 32K:

• Layer - 1457.97 tok/s

• Tensor - 246.84 tok/s

То есть обработка входного контекста в tensor split получилась примерно в 6-7 раз медленнее.

На 64K tensor-тест дальше не пошел - модель выгрузилась из памяти. Причину пока отдельно не разбирал, поэтому данные для tensor на 64K, 96K и 128K не привожу.

Layer split при этом нормально прошел весь тест до 128K.

Скорость генерации по мере заполнения контекста:

• 0K - 23.76 tok/s

• 32K - 22.15 tok/s

• 64K - 20.75 tok/s

• 96K - 19.53 tok/s

• 128K - 18.44 tok/s

То есть даже при 128K контекста dense-модель на 26.9B параметров в Q8 все еще работает со скоростью около 18.4 tok/s.

Prompt processing тоже падает постепенно, без резкого провала:

• 0K - 1992.67 tok/s

• 32K - 1457.97 tok/s

• 64K - 1136.52 tok/s

• 96K - 916.35 tok/s

• 128K - 724.86 tok/s

Для обычного чата tensor split может быть интересен, если контекст короткий, а ответы длинные. Там прирост с 24 до 32 tok/s ощущается.

Но если чат уже большой и модель каждый раз должна перерабатывать много входных токенов, выгода быстро начинает пропадать из-за очень медленного prefill.

Для кодового агента вроде Hermes я бы оставил layer split.

Агент постоянно читает файлы, получает куски исходников, и добавляет все это в контекст. В таком режиме скорость обработки входа важнее, чем дополнительные 8 tok/s на генерации.

Плюс layer split у меня стабильно работает вплоть до 128K, а tensor пока отвалился уже при переходе к 64K.

Итог пока такой:

• короткий чат и длинные ответы - tensor split может быть быстрее

• длинный чат - уже спорно

• кодовый агент и большие проекты - layer split выглядит намного практичнее

Сами CMP 90HX тоже порадовали. Qwen3.8-27B dense Q8 дает около 24 tok/s на пустом контексте и около 18.4 tok/s на 128K.

После того как выкрутил вентиляторы на 100%, самая горячая карта держится примерно на 65 градусах.

Наконец мой мессенджер прошёл тест в Google Play . За время тестирования он научился совершать звонки по udp. Это позволило по udp получать не только голос, но и пинок от сервера на проверку сообщений в реальном времени. Осталось придумать как без внешних сервисов, вроде FCM, не засыпать вместе с системой и не давать андроиду прибить процесс приложения, чтоб принять udp пендаль в любое время. Так как мессенджер ориентирован на пользователей роутеров Mikrotik, на роутер и была возложена такая задача. Не давать телефону спать :). В качестве энергетика будет выступать DHCP Lease. В приложении я подписываюсь на изменения параметров сети, и выполняю задачу в обычном executor.

private void registerNetworkCallback() {
        ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
        if (connectivityManager != null) {
            connectivityManager.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() {
                @Override
                public void onAvailable(@NonNull Network network) {
                    isNetworkActive.set(true);
                    if (userId > 0) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                    offlineHandler.removeCallbacks(resetStatusesRunnable);
                    Log.d(LOG_TAG, "Network: WiFi Connected. " + network);
                }

                @Override
                public void onLinkPropertiesChanged(@NonNull Network network, @NonNull LinkProperties linkProperties) {
                    Log.d(LOG_TAG, "LINK CHANGED DNS=" + linkProperties.getDnsServers());
                    if (userId > 0 && isNetworkActive.get()) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                }

                @Override
                public void onLost(@NonNull Network network) {
                    isNetworkActive.set(false);
                    offlineHandler.postDelayed(resetStatusesRunnable, 15000);
                    Log.d(LOG_TAG, "Network lost. Scheduled offline reset in 15s...");
                }
            });
        }
    }

который тригерится в том числе и на изменение списка DNS серверов. В роутере я указываю время аренды DHCP для подключённых устройств 6 минут. Соответственно устройства будут обновлять аренду каждые 3 минуты. С таким же интервалом 3 минуты, скриптом меняем список DNS серверов для локальной сети.

:local netId [/ip dhcp-server network find address="192.168.88.0/24"];
:local currentDns [/ip dhcp-server network get $netId dns-server];
:if ($currentDns = "192.168.88.1,8.8.8.8") do={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.4.4";
} else={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.8.8";
}

Этих трёх минут вполне хватает чтоб не заснуть, и пингануть разочек сервер для прогрева udp порта.

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

Собирайся, народ, кто в настолку играть идет. Как я делал прототип настольной игры на компьютере

Или: почему Яндекс Таблицы для меня стал игровым движком

Кратко об игре

«Война киборгов» — это настольная игра в стиле GTA и киберпанк для 2–6 игроков. Вы собираете своего персонажа по частям (руки, ноги, тело, голова), прокачиваете автомобиль и боевого питомца, используете 6 уникальных локаций (Арена, Автодром, Лаборатория, Оружейная, Логово, Свалка), сражаетесь на кубиках и пытаетесь первым вернуться на базу до того, как сработает электромагнитная бомба. Партия занимает 30–40 минут, правила объясняются за 5 минут.

Зачем нам Яндекс Таблицы

Мы уже 8 месяцев тестируем игру, отыграли больше 200 партий, отточили механики, сделали дизайн коробки. Но до печати тиража ещё нужно дойти, а играть хочется уже сейчас. Поэтому мы сделали цифровой прототип в Яндекс Таблицах. Да-да, в обычных таблицах.

Вот как это выглядит:

• Карта игрового поля — разбита на клетки, по которым двигаются игроки.

• Карточки персонажей — у каждого свой киборг со слотами для деталей.

• Справочная таблица — чтобы не держать правила в голове.

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

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

Что я хочу сделать

Я планирую:

1. Провести тренировочные игры — чтобы желающие могли попробовать, освоиться и понять механику.

2. Организовать турнир — когда все освоятся, устроим соревнование.

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

Что нужно от вас

Если вы хотите стать тестером или участником турнира:

• Подпишитесь на наших ботов.

• У вас должны быть наушники и микрофон — для общения и координации.

Как записаться

Для записи на игры я использую Telegram-бота и бота в MAX. Там вы сможете:

• Выбрать удобное время для игры.

• Увидеть расписание.

• Получить уведомления о начале.

Все игры будут бесплатными — это возможность увидеть игру до релиза, повлиять на её финальную версию и просто интересно провести время.

Почему вам стоит участвовать

• Вы увидите игру до релиза — одними из первых.

• Сможете повлиять на финальную версию — ваши отзывы помогут сделать игру лучше.

• Это просто интересно — посмотреть, как работает «GTA на столе» в цифре.

• Это бесплатно — мы не берём деньги за участие.

Дальнейшие планы

После серии тренировочных игр мы:

• Составим турнирные таблицы.

• Определим расписание.

• Проведём полноценный турнир с победителями и призами.

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

Telegram-бот — https://t.me/voina_kiborgov_bot
MAX-бот — https://max.ru/id332760632995_2_bot

Апгрейд контроллера Xbox 360 стиками с TMR датчиками

Энтузиаст оснастил контроллер Xbox 360, спроектированный больше двадцати лет назад, современными TMR (туннельными магниторезистивными) датчиками.

Для этого нужно только...

• взять модули Ginfull для контроллера Xbox 360 с датчиками на эффекте Холла (датчики выкинуть);

• взять TMR датчики для использования с механизмом ALPS, например, от той же Ginfull;

• прифранкенштейнить TMR датчики к механизму;

• ???

• Profit

Разведка боем: Скрытая карта режимов 8BitDo Zero v1 и прошивка по воздуху через Linux

Короткая заметка для тех, кто ковыряет ретро-железо. Стояла задача: использовать микро-геймпад 8BitDo Zero 1-го поколения (Bluetooth 2.1) для специфического HID-ввода, изменив раскладку “намертво” внутри устройства.

Официальный софт под Windows давно заброшен, поэтому ремап делался по воздуху через Linux (RFCOMM). В процессе удалось полностью разобрать структуру конфигурационного пакета, отправляемого контроллеру.

Структура KEYMAP-пакета

При отправке команды +KEYMAP; геймпад принимает массив, где блоки идут друг за другом в зависимости от режима удержания кнопок при включении (по 12 байт на режим в аппаратном порядке: Вверх/Вниз/Влево/Вправо/Select/Start/B/A/X/Y/L/R):

1. START — Режим стандартного джойстика (Usage Page 0x09)

2. R + START — Режим PC-джойстика

3. START + B — Стандартная клавиатура (Usage Page 0x07), выдает стрелки (52 51 50 4f) и Enter/Esc (28/29).

4. START + B + R — Расширенная клавиатура.

5. START + A — Режим iCade (раздельные HEX-коды на Press и Release).

6. START + X — Скрытый сервисный/Emu-Touch режим прошивки (0F 0E 0D 0C...).

7. Shutter (Селфи-пульт) — Комбинированный режим. Позволяет сочетать стандартные кнопки клавиатуры (Page 0x07) и мультимедиа-коды Consumer Page 0x0C (Громкость: 80/81, Яркость: 6F/70, Снимок: 65).

Как шить (Пайплайн в 3 окна)

1. В первом окне терминала поднимаем RFCOMM-канал на 1-м L2CAP канале геймпада: sudo rfcomm connect 0 [MAC_АДРЕС] 1

2. Во втором окне правим HEX-массив и инжектируем его Python-скриптом напрямую в /dev/rfcomm0 (скрипт прикреплен ниже). Контроллер должен вернуть успешную сигнатуру 0e0100a6.

3. В третьем окне контролируем прохождение пакетов через sudo btmon.

В конце пакета обязательно должны идти маркеры валидации aa 55 aa 55, иначе чип отвергнет прошивку. Мне удалось успешно собрать кастомный Shutter-режим, внедрив туда нужные клавиатурные скан-коды (30 и 40) рядом с системными. Код скрипта прилагаю.

import serial
import time

# Настройки порта
PORT = '/dev/rfcomm0'

# Ваши данные для записи (с 07 07 07 07)
DATA = b'\x00\xa6WR+KEYMAP;\x00\x00\x64\x00\x00\x00\x00\x00\x1a\x1b\x11\x10\x13\x14\x16\x17\x01\x01\x01\x01\x1a\x1b\x11\x10\x13\x14\x16\x17\x52\x51\x50\x4f\x28\x29\x4d\x4e\x4a\x4b\x0e\x10\x13\x14\x15\x04\x1b\x1c\x18\x05\x16\x17\x19\x1a\x1a\x1b\x04\x07\x0f\x12\x0b\x18\x0d\x1c\x0e\x0c\x08\x1d\x14\x06\x19\x0a\x15\x09\x11\x17\x13\x10\x0f\x0e\x0d\x0c\x09\x00\x08\x07\x05\x06\x04\x03\x52\x51\x50\x4f\x28\x29\x4d\x4e\x4a\x4b\xea\xe9\xaa\x55\xaa\x55'

try:
    print(f"--- Попытка открыть {PORT} ---")
    # Открываем порт с таймаутом 2 секунды
    with serial.Serial(PORT, baudrate=115200, timeout=2) as ser:
        print("Порт открыт. Отправка данных...")
        ser.write(DATA)
        ser.flush()  # Гарантируем отправку всех байт
        
        print("Данные отправлены. Ждем подтверждения от геймпада...")
        response = ser.read(16) # Читаем ответ
        
        if response:
            print(f"ОТВЕТ ПОЛУЧЕН (HEX): {response.hex()}")
            if "0e0100a6" in response.hex():
                print("УСПЕХ: Геймпад подтвердил запись ремапа!")
            else:
                print("ВНИМАНИЕ: Ответ получен, но он не похож на стандартное подтверждение.")
        else:
            print("ОШИБКА: Геймпад ничего не ответил (таймаут).")

except Exception as e:
    print(f"КРИТИЧЕСКАЯ ОШИБКА: {e}")

Пользователь установил своему хомяку систему, которая считывает пробежки в клетке по беговому колесу и загружает эти данные в соцсеть для спортсменов Strava. На колесе установлен магнит и специальный датчик, который считает количество оборотов колеса. Микроконтроллер фиксирует время, скорость и дистанцию питомца, а потом эти данные загружается в спортивную соцсеть. Средний ночной пробег хомяка Молли составляет 10 км, а его личный рекорд — более 11 километров за ночь.

Господа! Я приехал в отпуск в Тбилиси и Батуми и мы тут с местными коллегами из sandb0x.space решили устроить митап. Пока в Тбилиси 12 августа, но если будут желающие и в Батуми, можно и там тоже (я буду там 7, 8 и утром 9). Вот объявление:

12.08.2026, Wednesday, 19:00
Merab Aleksidze Street, 1
Donation welcome
Lang: ru/en
Host: Yuri Panchul

For the last 40 years, chip designers have used Verilog hardware description language and logic synthesis technology to create the devices we see everywhere: smartphones, computers, ML hardware accelerators.

While the logic of most mass–produced chips, called ASIC (Application Specific Integrated Circuits), is fixed at the silicon foundry, there is a special kind of chips with changeable logic, called FPGA, or Field Programmable Gate Array. FPGAs are used for prototyping, education and applications like high-frequency trading.

During the workshop, we are going to use Verilog to configure FPGA, starting with simple arithmetic, then doing 2D graphics.

Bring your laptop (Win, Linux, Mac)

https://t.me/sandbox_events/144

Как кусок ламината помогает не сжечь насос

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

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

После накопителя установлена насосная система, которая поддерживает нормальное давление в доме.

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

Чтобы не следить за уровнем воды вручную, я поставил на накопитель датчик. А насос подключил через умную розетку.

Получился довольно простой сценарий:

– датчик следит за уровнем воды; 
– когда вода опускается ниже минимальной отметки, система получает сигнал; 
– умная розетка отключает насос; 
– когда вода возвращается, насос можно снова включить.

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

Выглядит, конечно, не как заводское решение, но зато работает)

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

Владелец Steam Deck под ником ConroyyJenkinss решил защитить от родных гаджет шипастым корпусом, камерой наблюдения и электрошокером сверху.

Сначала пользователь поставил пароль на гаджет, но родых это не остановило. Тогда он смоделировал в Blender ярко-оранжевый корпус с крупными шипами и напечатал его на 3D-принтере, чтобы консоль было физически неприятно брать в руки. Следом добавилась электроника — одноплатный компьютер, динамик и камера с распознаванием объектов. Дальше система действует сама. Скрипт следит за картинкой с камеры и, стоит человеку попасть в кадр, включает резкий неприятный звук. Если незваный гость не уходит, сервопривод приводит в действие закреплённый сверху электрошокер. Сам создатель уточняет, что задача устройства — отпугнуть, а не ударить кого-то током.

Собрал 52 гайда по AI: от первой модели в Ollama до своего агента

Дисклеймер: я не AI-исследователь и не senior ML-инженер. Я обычный разработчик, который решил разобраться в теме — и понял, что хороших сводных материалов катастрофически не хватает.

Большинство статей либо «что такое нейросети за 5 минут» (бесполезно), либо «запускаем LLM с нуля на кластере из 8 A100» (неприменимо). Между этими крайностями — пропасть.

Я решил собрать то, чего мне самому не хватало: практический хендбук, который ведёт от полного нуля до работающих агентов. Без воды, без маркетинга, без «ChatGPT заменит программистов».

Весь проект — 52 файла, ~6 часов чтения. Уровни: зелёный (начало) → красный (глубоко).

Репозиторий: https://github.com/bestdeejay-design/awesome-ai-handbook

О чём это вообще

Хендбук покрывает пять разделов:

Zero Level — база. Что такое LLM, как они устроены (без математики), облако vs локальный запуск, как выбирать железо (RAM, VRAM, квантование), глоссарий на 35 терминов. Рассчитан на тех, кто вчера открыл терминал.

Local Models — установка Ollama, выбор моделей под задачу (Qwen, Llama, Mistral…), квантование (Q4/Q5/Q8), сравнение инструментов, бенчмарки на Apple Silicon, продвинутая настройка (Modelfile, кастомные API, окружение).

AI Agents — архитектура, паттерны (ReAct, Multi-Agent), фреймворки (LangGraph, CrewAI), память, system prompts, safety, туториалы: первый агент, команда агентов, кодинг-агент.

Use Cases — реальные сценарии: кодинг с Continue/Aider, RAG с Open WebUI и ChromaDB, автоматизация с n8n, Telegram-боты, контент-пайплайны.

Resources — сообщества (Reddit, Discord), курсы (EN/RU), ссылки на всё полезное.

Почему это не очередной awesome-list

Я намеренно не делал просто список ссылок. Каждый файл — это полноценный материал с:

• Контекстом и пояснениями

• Сравнением вариантов (например, когда выбрать Ollama, а когда LM Studio)

• Командами, которые можно скопировать и выполнить

• Предостережениями (грабли, на которые сам наступал)

Пример. В разделе про квантование не просто таблица методов, а объяснение: на что влияет Q4 vs Q8, как считать VRAM под свою задачу, и когда квантование ломает ответы модели.

Или раздел про агентов — не ссылка на документацию LangChain, а пошаговые туториалы с реальным кодом: от «агент с одним инструментом» до «команда агентов с очередью задач».

Структура проекта

awesome-ai-handbook/
├── basics/           # 🟢 нулевой уровень (9 файлов)
├── local-models/     # 🔵 локальные модели (11 файлов)
├── agents/           # 🤖 AI агенты (17 файлов)
├── use-cases/        # 💼 применение (5 файлов)
└── resources/        # 📖 ссылки и курсы (5 файлов)

Каждый раздел — законченная тема. Можно читать подряд или прыгать в конкретный файл по каталогу (catalog.md). Уровни сложности маркированы цветом — от зелёного (ничего не знаю) до красного (пишу код).

Кому это будет полезно

• Разработчикам, которые хотят использовать AI в работе, но не знают с чего начать

• Тем, кто уже запустил Ollama, но хочет разобраться глубже — с агентами, RAG, пайплайнами

• Тем, кто ищет альтернативу ChatGPT и хочет запустить модель локально, но не уверен в выборе

• Тем, кто читал пять статей про AI-агентов и всё ещё не понимает, как их собрать

Почему Open Source

Хендбук лежит на GitHub под MIT-лицензией. Я планирую поддерживать его актуальным — модели и инструменты меняются быстро, и это не работа одного человека.

Если найдёте ошибку, устаревшую информацию или захотите добавить свой раздел — открывайте issue или PR. Я за мердж-реквесты с чаем и печеньками.

Ссылки

• Репозиторий: https://github.com/bestdeejay-design/awesome-ai-handbook

• Читать с нуля: basics/README.ru.md

• Каталог всех файлов: catalog.ru.md

• Если знаете английский: README.md

Надеюсь, кому-то сэкономит недели поиска. Если понравилось — киньте звезду на GitHub, для проекта это лучшая поддержка.

Энтузиаст электроники и ПК под ником Uwoslab собрал внешнюю «батарею» из 192 обычных пальчиковых батареек AA (высокотоковые щелочные Pookell) и заставил на ней работать ПК без подключения к сети, без штатного блока питания.

В начале проекта Uwoslab запланировал использовать 400 батареек: закупил четыре упаковки по сотне и 50 групп по восемь элементов. В процессе работы конструкция вышла проще. На всё ушло 192 батарейки. Энтузиаст распределил элементы по трём блокам, по 64 штуки в каждом. Ток от этой такой мегабатареи идёт напрямую в материнскую плату через переходник 12V DC-to-ATX.

По прикидкам Uwoslab, именно сборка из 400 таких батареек могла бы выдавать около 160 Вт на протяжении десяти часов. Характеристики ПК: система на сокете AM4 со встроенной графикой и без накопителя. ОС грузится прямо с флешки - Hannah Montana Linux на базе Debian.

На старте батарейный блок выдавал около 13 В, а под нагрузкой встроенного теста stress-ng, когда процессор загрузили на 98%, напряжение просело лишь до стабильных 11,95 вольта — ПК работал штатно. По остаточному заряду автор предположил, что она могла бы протянуть ещё пару часов, прежде чем напряжение упадёт слишком сильно. Также энтузиаст запустил на таком ПК FreeDoom.

Поднял домашний мониторинг на Raspberry Pi. Дешевле любого облака

Надоело платить за облачный мониторинг для домашних серверов. Решил собрать своё.

Взял Raspberry Pi 4 который валялся без дела. Поставил Prometheus и Grafana. Добавил node_exporter на все машины в сети. Уведомления настроил через Telegram-бота, теперь когда что-то падает или температура процессора уходит в красную зону, приходит уведомление.

Заняло один выходной. Большую часть времени не настройка, а борьба с тем что Grafana на Pi жрёт память активнее чем ожидалось. В итоге вынес Grafana на основной комп, а Pi оставил только для сбора метрик.

Что получилось в итоге:

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

Уведомления в Telegram работают быстрее чем у большинства платных сервисов которые я пробовал.

Стоимость: Pi уже был, электричество копейки.

Минус один: когда Pi сам падает, мониторинг молчит. Решил просто поставить watchdog и пока хватает.

Кто делал что-то похожее, на чём остановились в итоге?

Сказал Алисе выключить свет – пришлось бежать на улицу к щитку

Продолжаю делиться цифровыми находками для дома.

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

После подключения система почему-то определила его как осветительный прибор. Я не придал этому особого значения. Устройство добавилось, сценарии выполняются, значит, всё работает. А когда сказал «Алиса, выключи свет», Алиса послушно выключила всё, что считала светом. И сама отключилась следом, словно диверсант.

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

У устройств есть разные типы: лампочка, выключатель, розетка, датчик и так далее. И от выбранного типа зависит, как Алиса будет реагировать на общие команды.

Если устройство обозначено как лампочка, оно может выключиться после фразы «выключи свет». Даже если на самом деле это автомат, который отвечает за электричество во всём доме.

Поэтому теперь после подключения нового устройства я проверяю:

– какой тип ему присвоила система;
– в какую комнату оно добавлено;
– реагирует ли оно на общие команды;
– не попало ли случайно в ненужную группу или сценарий.

Особенно это важно, когда умный дом собран из нескольких экосистем. У меня примерно 80% устройств работают через Алису, но часть подключена через Smart Life и другие приложения. Всё потому что ещё нет устройств, которые бы работали напрямую в экосистеме умного дома Алисы. 

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

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