Всем привет!
Меня зовут Слава, некоторые могут знать меня, как @rayslava, и я задумался о том, что есть у меня уже всякие социальные (и не слишком) сети, и пора бы обзавестись собственным ТГ-каналом.

Последние лет десять я работаю в тулчейн-команде C++-девелопером, шатаю в разные стороны компилятор, системные библиотеки, системы сборки, и окрестный тулинг, связанный с компилятором.
Да, буквально, как в анекдоте:
— Я C++ разработчик!
— Не, чувак, это я C++ разработчик

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

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

Исторически у меня тотемным зверем был барсук, который много где сопровождает меня на аватарках, не избежит этой участи и канал, на который я буду постить свой отборный тяжёлый барсукор!

Решил я тут сделать себе универсальную читалку, чтобы комфортно читать pdf, переходить по ссылкам, синхронизироваться с ttrss и wallabag, в осмотрелся вокруг, позадавал вопросы в феди.

В итоге получилось что оптимальным по соотношению цена/качество будет какой-нибудь недорогой планшет на андроиде, с LineageOS, чтобы обновлялся.

Ну, сказано — сделано. Посмотрел, что подходящего можно отыскать на рынке, на озоне отыскался SM-T500 чуть дороже десяти тысяч рублей.

Да, я понимаю все риски покупки планшета пятилетней давности с доставкой из Китая, однако планируемая цена/фичастость меня устроила.

Что имеем в итоге:
● Планшет приехал, это хорошо.
● Похоже, он refurbished, потому что KG status Prenormal (Knox Guard говорит, что что-то этакое туда уже шили), а GRDM status: Abnormal (FFFFFFFF), значит, скорее всего, лазили куда-то в системные разделы. Это не очень хорошо.
● Всё работает, как положено, корпус целый, экран не царапаный, родная прошивка встала хорошо. Это снова хорошо.

В итоге читалка получилась на загляденье:
1. Шьём самую свежую европейскую официальную прошивку с xda-developers
2. Ставим страной Германию (чтобы самый суровый GDPR применился)
3. При первоначальной настройке не принимаем никаких лицензий, отказываемся от всех аккаунтов, запрещаем всем сервисам доступ ко всем фичам
4. Чтобы не запускать предустановленный хром, и не соглашаться на его «Я доложу о каждом шаге, куда надо!», на компьютере качаем apk с F-Droid, заливаем по adb, устанавливаем
5. Ставим весь нужный софт из F-Droid

В моём случае для читалки это:
● Fennec в качестве нормального браузера, с AdNauseam, и всем прочим
● KOReader как читалка любых книжек и pdf, ну и читалка Wallabag, при желании
● Приложение Wallabag
● Wikipedia (удобно, что есть офлайн-кеширование)
● FeedMe, его пришлось скачать в виде apk с гитхаба, потому что сопоставимого открытого аналога под андроид я так и не нашёл

Получился отличный планшет чуть больше, чем за $100, который никуда не стучит, ничего не просит, и позволяет комфортно потреблять контент. Мы великолепны!

И, естественно, я бы не был собой, если бы на этом остановился! Мне тут недавно попалась на глаза новость, что у GNU Emacs появилась android-сборка. Ну грех же не проверить! Проверил. Работает.

А самое крутое: можно скрестить emacs с termux'ом, и, добавив BT-клавиатуру с али, получить даже не просто полноценный носимый терминал, но вполне себе сверхпортативный недо-laptop для труЪ-нищеброда. Мой конфиг емакса подхватился практически в полном объёме (за исключением частей, требующих нативных тулов, их пока было лень собирать), а в репозиториях у termux'а оказался доступен даже свежий clang. Ну да, хелловорлд собирается пятнадцать секунд, зато локально!

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

Из новых развлечений: Убедился, что нода MinIO довольно несложно поднимается в k8s, и отлично скрещивается там с Drone CI для хранения артефактов через AWS S3 Plugin, и всё это добро прекрасно работает с k8s-runner'ом и исходниками из Gogs.
Теперь у меня есть не только домашний «уже-почти-github-actions», но и домашний «уже-почти-s3» 🙂

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

Чтобы было стильно, модно, молодёжно, писать решил, разумеется на Rust. Со стеком определился более-менее быстро: Axum на бек и htmx на фронт, чтобы запросами пуляться.
А вот с шаблонизотором было чуть сложнее, одним из популярных решений, насколько я понял, является Askama, но это шаблонизатор, который, вдумайтесь, вкомпилирует шаблон в вашу программу. В смысле буквально:

It generates Rust code from your templates at compile time based on a user-defined struct to hold the template's context.

Изначально у меня возникло две мысли:
1. Да они поехавшие там все!
2. Не, ну с другой стороны, а чего ещё можно ждать от Rust-сообщества?

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

Естественно, просто на страничке я остановиться не смог, и накрутил всякого вокруг по-мелочи: авторизацию с JWT (кстати, рекомендую статью), метрики для выгрузки статистики в Prometheus, и прочее по-мелочи.

В общем, потратив 3-4 вечера, я стал немножечко веб-фулстеком, и в принципе могу даже рекомендовать такой сетап. Axum с middleware через Tower позволяют очень удобно навешивать авторизацию в нужные места, sqlx и askama валидируют запросы и шаблоны во время компиляции, а после того, как ты собираешь первично работающий скелет, и вникаешь в логику происходящего, вроде очерёдности применения middleware и передачи данных между layer'ами в tower, процесс написания начинает даже казаться вполне комфортным.

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

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

У меня уже пару лет есть домашний сервер, на котором поднят kubernetes-кластер из одной ноды. Я его себе поднял из интереса и для изучения популярной технологии (ну да, на полный сетап с calico меня, конечно, не хватило, и сеть у меня на flannel, но тем не менее). В целом эксперимент оказался не только довольно интересным, я более-менее разобрался, как жить в k8s, но в какой-то мере даже весьма полезным: я там поднял себе кучу сервисов (да, я давний обитатель /r/selfhosted), которыми я пользуюсь постоянно.
Например, у меня там ttrss и wallabag, которые я использую для чтения новостей, и всякие вспомогательные штуки, вроде rtorrent+rutorrent для скачивания дампа википедии и раздачи убунты.
Естественно, self-hosted сетап для разработки из gogs и drone, куда ж без него! Теперь вот ещё minio для хранения всякого.
Там же живёт одна из нод syncthing'а, который я использую для синхронизации всего, в том числе и моих заметок (наверное, сделаю отдельный пост, как работаю с заметками, календарями и базой знаний, ставьте 🤓, пишите комменты, если интересно про возможности org-mode и обвязку).

И вот теперь к сути: недавно меня попросили написать пару небольших статеек, которые я, само собой, тоже пишу в org-mode, как в самой удобной среде подготовки структурированного текста, и хранил в этом самом syncthing'е. Но поскольку статейку читать будут не только собратья-разработчики, то надо её показывать красиво, для того, чтобы красиво показывать, я обычно пользуюсь org-export с собственным шаблоном, но тут проблема в том, что для рендера нужно иметь под рукой компьютер с texlive и всякими прочими тулами, а я писал на бегу, и периодически использовал планшет из поста выше.

Ну какое решение может принять программист? Конечно же «я потрачу десять часов на автоматизацию задачи, вместо десяти минут на задачу»! В итоге теперь я могу клепать статьи в промышленных масштабах 🙂

В итоге теперь процесс выглядит так:
1. Пишу обычный plain text где угодно, как угодно, нужна просто клавиатура
2. Пушу в git
3. Gogs берёт новую версию, забрасывает в Drone на сборку
4. Drone, используя k8s worker, создаёт новую ноду для сборки
5. На ноде поднимается контейнер с emacs, texlive, и прочей требухой
6. Скриптом прогоняется экспорт, и результат выгружается в MinIO
7. Новая веб-морда подхватывает новую версию, и обновляет ссылку
8. Читатель просто переходит по ссылке и читает красивый pdf с картинками

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

А мог создать новый файл в Google Docs и дать ссылку.

И вдогонку к предыдущему посту, с примером «подобной задачи»: этот самый сайт на rust, который раздаёт файлики со статьями, работает ровно на этом же самом пайплайне:

1. Сделал исправление
2. Запушил в гит
3. Gogs пнул Drone
4. Drone пытается собрать код и прогнать тесты
5. Если всё получилось, запускается сборка Docker image с новой версией сайта
6. Когда image собрался, он заливается в registry, который хостится здесь же, в соседнем k8s-неймспейсе
7. Последним шагом Drone дёргает k8s API за rollout, заставляя deployment с сайтом перекачать image с новой версией, и перезапустить pod, обслуживающий сайт
8. Когда обновлённый pod готов и загружен, ingress переключается на него, и веб-морда получает новую версию прямо без downtime'а

Из раздражающих меня моментов здесь — шестой пункт. Сборка через docker plugin для Drone использует docker-in-docker, поэтому несмотря на то, что у меня и registry и сам docker находятся на этом же хосте (и подключен как container backend к k8s), при каждой сборке эта зараза перекачивает все базовые образы, так как не может использовать кеш хостового docker'а.

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

В рамках общего любопытства я продолжил изучение веб-технологий с Rust'ом.

На этот раз мне на глаза попался тележный бот, который выдавал красивую страничку по кнопке Menu, пошёл посмотреть, как это делается, и обнаружил, что телеграм предоставляет для этого WebApps API. Я про это слышал и раньше, но со стороны разработчика пошёл изучать первый раз.

Штука оказалась в среднем довольно неплохая, фич там навешено немало, и они довольно практичные — буквально читаешь API reference, и понятно, что и зачем сделано. Одобряю.

Чего я не одобряю — это того, что оно всё на JS, ну вот есть у меня определённые сомнения и предвзятость на его счёт. Поэтому попробовать штуку, конечно, хотелось, а вот писать её на JS — нет. И тут я понял, что настало время протестировать WASM, всё равно давно собирался. Ну и раз уж бэкенд у меня на расте, то надо и фронтенд брать на нём же.

Итоговый стек подобрался следующий:
● Axum/HTMX/Askama из поста выше
● wasm-bindgen + wasm-pack для упаковки фронта
● Внезапная eruda, чтобы хоть как-то понимать, что идёт не так, про проверке на телефоне

А теперь, господа, пристегнитесь. Сейчас со всей этой хренотой мы попробуем взлететь!

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

Инсайты:
1. Это работает. Да, криво, косо, местами требует выворачивания рук и поклейки обоев через замочную скважину, но работает.
2. На первом заходе вы будете страдать. Стандарт — сыроват, инструментарий — сырой, документация — недостаточна, пользователей — мало, ответы не гуглятся. Чтение исходников, отладка, и здравый смысл — лучшие друзья разработчика.
3. Разработчики на Rust — значительно более высокого мнения о разработчиках на JS, чем те заслуживают. Вся интеграция и интероп предполагают использование ES6 с модулями, импортом/экспортом, TypeScript'ом там, где можно, и прочие изыски. На практике — есть глобальный объект внутри window, и делай, что хочешь, вся работа идёт через js_sys::Reflect
4. Когда вы не можете нормально доступиться к объекту, unchecked_into() ваш друг. Да, на Rust выглядит грустно, и приходится читать очень много панических логов (полезность: console_error_panic_hook), но иначе никак.
5. Когда до вас не может нормально доступиться объект, let obj = js_sys::Object::new(); js_sys::Reflect::set() ваш друг. Да, криво, косо, многословно, но только так и работает.
6. Нормальной документации нет, в чатах никто не отвечает. Лучшие подсказки можно найти в тикетах на гитхабе, там из детального описания проблемы можно вычленить логику происходящего.

Заметки на полях:
1. iPhone в Lockdown Mode отключает WebAssembly напрочь, проверять пришлось на другом айфоне
2. Интерфейс Телеграма реально неплохо реализован и плюс-минус одинаково работает на разных платформах.

Ну и в целом, осталось немножечко попрактиковаться в написании смарт-контрактов на Rust под Solana, и я готов в одну каску бахнуть криптостартап в телеграме! А то все делают, чем я хуже?

Как-то всё начало канала у меня вышло про Rust, а я всё же работаю C++-разработчиком, пришла пора поделиться и плюсовыми мыслями.

Я тут недавно сходил на C++ Russia, послушал, что нового творится в языке. Из того, о чём я сильно задумался после конференции — поддержка корутин в C++20. Сам доклад Марселя Галимуллина был довольно лайтовый, фактически просто краткий пересказ стандарта, и приведение примеров, с которыми и раньше проблем особо не было (скажем, раз, два, и далее сколько вам нужно). Но вот то, что оно, наконец, более-менее заработало, заставило меня вновь засучить рукава, и потыкать палочкой в новый GCC.

Первое впечатление от плюсовых корутин, особенно на фоне чего-то, вроде Rust с Tokio, в меру отталкивающее, а у неподготовленного человека эта имплементация может вызвать реакцию вида

— О, ура, завезли корутины!
— Так, а что за struct promise_type внутри моего класса?
— Стоп, как это надо самому писать типы, в которых хранится std::coroutine_handle?
— Да в смысле специфицированы только интерфейсные функции?
— А̶͕̐А̷͌А̶̘͛А̸͇̓А̶͓͝А̵̠͌!̶͕̏ ̶̭̚*̶̠̔H̴̛̼Ẽ̸͇ ̶͓̌Ĉ̸̡O̷̼̒M̴̞̀E̷̘͊S̵̻̍*̴͂͜

В общем, если вам просто «взять и запустить прямо сейчас», берите folly, и будет норм.

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

Я поставил несколько экспериментов, и оно выглядит, как очень хорошая штука для работы с медленным и печальным накопителем, или какой-нибудь сетью в условиях нестабильного соединения, включая in-device сети, вроде i²c.

На устройстве мы можем сделать условный std::vector<std::coroutine_handle<>> и при каждом действии складывать туда эти самые корутины, вызывая их по очереди, когда возникнут подходящие условия. Например, освободится возможность записи в хранилище, или можно сделать очередь для загрузки данных в моменты, когда появится сеть, причём мы можем «замереть» в тот момент, когда сеть снова отвалилась, а потом продолжить с того же места, когда снова появилась.

Навскидку мне кажется, что лучшее применение — embedded. Да, есть проблема, что корутины в C++ — stackless, поэтому для вашей платформы придётся реализовать поддержку heap'а, но это не настолько большая проблема, по сравнению с написанием вот такого scheduler'а вручную, я писал, и там прямо боль.

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

Давно ничего не писал: в связи с переездом было как-то немного не до того, но, наконец, набрался материал для настоящего барсукора!

Итак, перебравшись на новое место, я решил организовать себе новый умный дом. Поскольку здесь жильё у меня съёмное, проложить километр кабеля в стенах — не получится, в итоге остановился на zigbee, начал с покупки первой лампы на потолок, и наладки инфраструктуры:
- Гейтвей UZG-1
- Мозг из RPi5 и к нему всякого, по-мелочи, вроде UPSа на двух 18650.
- Нормальная сеть на hAP ax³

C железом понятно, а что с софтом? Вроде, всё понятно — ставим на RPi любую ОС, и набрасываем сервисы. Но это не путь настоящего джедая! Раньше я хранил данные в постгресе, и статистику в графане, но всё это жило на сервере в k8s, как я писал раньше.

Но когда я переезжал — не переть же с собой стойку через полмира! В итоге сервер уехал на колокейшен к дружественному ящеру @skobkin (у него, кстати, есть @sporadic_podcast, куда я, наверное, загляну с рассказом про эти приключения), и вот пришла пора задуматься, как бы «вернуть» сервер!

Сперва планировал проброс порта, чтобы подключиться к базе, но затем задумался: «А почему, собственно, порта?». Мне же всё равно нужно как-то управлять софтом, контролировать версии, собирать статистику, то есть нужна оркестрация. И ведь у меня буквально под рукой есть самый популярный оркестратор — k8s! Control Plane и рабочая нода крутятся на сервере, осталось только сделать из RPi ещё одну ноду и дело в шляпе! Осталось наладить связность.

И здесь начались приключения! Первой моей мыслью был VPN: поднял wireguard здесь, поднял там, а они не видят друг друга. Потыкался-потыкался, по логам выглядит, будто сжираются пакеты, погуглил, выяснил, что РКН режет wireguard на многих провайдерах. «— Ладно,» — думаю — «не будут же они уничтожать весь VPN, как-то работать-то надо!», и начал настраивать IKEv2. Настроил. Даже шифры подобрал, совместимые между mikrotik'ом и strongswan'ом. Предложения уходят, приходят, соединение есть, а ESP-пакеты не идут. Промучился несколько дней, выяснил, что на ТСПУ теперь режут любой недостаточно правоверный ipsec. Хочется, конечно, пожелать на новый год тем «специалистам» по разрушению сети, которые этим занимаются, мелкоклеточного неоперабельного рака яичек со множественными метастазами во всё подряд, но к решению задачи это не приближает.

Из рациональных способов на каждый день (ну всегда остаются «коннекты последней надежды» через всякие zerotier и i2p) остался https, и вариантов, как обычно, несколько. Остановился я на wstunnel'е, потому что во-первых уже с ним работал, а во-вторых настройка довольно примитивная: выставить эндпойнт куда-нибудь в nginx, и ждать соединения. Из интересного обнаружилось, что Mikrotik добавили docker в ROS (с версии 7.4beta), можно держать контейнер прямо на hAP'е! После заворачивания wireguard'а в websocket всё завелось. Теперь у меня при загрузке роутера стартует контейнер с wstunnel'ом, пробивает тоннель до сервера, поднимает внутри этого тоннеля wireguard и подключает маршрутизацию. Со всеми извращениями пинг получается порядка двухсот миллисекунд, что, конечно, многовато, но мне тут не в шутеры играть, поэтому в целом норм.

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

В связи с неутихающим (а скорее даже разрастающимся) хайпом вокруг #LLM в программировании, я решил посмотреть, что у нас интересного появилось в области тулинга, посмотрел полезные штуки, а сегодня вот собрал и протестировал любопытный сетап: скрестил aider и ollama.

Собственно, ollama, полагаю, в особом представлении не нуждается — это самая, наверное, популярная запускалка локального инференса. Да, она выжимает не всё из железа, и если вы, скажем, руками правильно соберёте тот же llama.cpp, который у ollama под капотом, под свою машину и своё конкретное использование, есть возможность выиграть десятки процентов производительности. Однако ollama все любят за удобство: просто запускаешь одну программу, а дальше она сама — и модель скачает, и запустит, и по видеокарте и процессору пропорционально разложит, в общем — бери и используй.

А вот aider — это генератор промптов, заточенный на написание кода. Из особенностей — он умеет не только в чате рассказывать, что надо написать (это можно и просто в ollama сделать), но и умеет сканировать гит, собирая оттуда файлы, скармливать их в контекст, и переформулировать запрос, если что-то пошло не так. Из особо любопытного: флаг --watch-files, который заставляет его сканировать файлы текущего репозитория в поисках комментов с AI? и AI!, причём первый заставляет его прокомментировать тот кусок кода, в котором он написан, а вот второй — заставляет что-то сделать. То есть буквально пишем // AI! Add iteration over the strings and make them upcase, сохраняем. и смотрим, как начинает возникать код.

На моей 6900 XT со включенным контекстом на 16k токенов запрос вида «напиши вот здесь на go новый endpoint, который будет принимать из веба строчку и делать ей upcase» занял 43.86 секунды. И реально написал рабочий код, я просто запустил, и оно делает то, что должно!

Если включить режим архитектора через /architect, то он начнёт ещё и ругаться, что ты не того просишь, и подсказывать, как переработать код, чтобы получилось лучше. Для написания реально сложного кода, конечно, лучше подключить какой-то облачный бэкенд, по тестам, что я видел, лучшие результаты для кода даёт Sonnet, поэтому API лучше купить у Antropic. Я пробовал его и OpenAI, на моих тестах разница не очень видна, и там и тут хорошо.

Но здесь мне было интересно именно попробовать, насколько можно изолироваться, а тут как раз MS выкатили модель phi4. Вывод: можно изолироваться!

В моём случае выглядит как:

docker run -it --device dev/kfd --device /dev/dri -v /home/ray.ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama:rocm
docker run -it --user $(id -u):$(id -g) --volume $(pwd):/app --env OLLAMA_API_BASE=http://172.17.0.2:11434 paulgauthier/aider-full --model ollama_chat/phi4:latest --watch-files

А потом просто говорим в чат aider'у "create simple html", он делает шаблон. Открываем этот html в редакторе и комментом пишем "AI! create a simple backend in go that will serve this html, add there a sample endpoint returning string and add an async request here".

И оно реально за сорок секунд пишет простой сервер, куски js, вот это всё. Остаётся только запустить и убедиться, что оно и правда работает.

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

Про компактный код на Rust

Некоторое время назад мне попадались обсуждения размеров бинарников на Rust. Некоторые утверждали, что исполняемые файлы на Rust слишком большие, в то время как на C можно получить реально крошечные бинарники, поэтому этот ваш раст не нужо́н.

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

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

Я вдохновился проектом tiny-rust-demo от Keegan McAllister и kilo от Antirez'а, и попробовал реализовать небольшой редактор на Rust.

Результат — based. Моё первое Linux-приложение (именно Linux, не GNU/Linux), которое имитирует некоторое количество emacs'овых клавиш (так как в emacs'е я живу, это был самый простой путь). Программа умещается в 32 КБ и требует только ядра Linux для запуска.

В процессе я активно использовал Claude Code, но, похоже, «вайб-кодинг» не очень хорошо работает на уровне таких приложений — хотя при написании тестов он очень сильно помогает. Нужно ещё немного поработать с ним, чтобы сделать окончательные выводы, но пока это кажется очень полезным (хоть и довольно дорогим) инструментом для разработчика. По крайней мере, на работе я точно буду его использовать: он прямо драматически уменьшая объём бойлерплейта и автоматизирует некоторые скучные задачи.

Не уверен, нужен ли миру ещё один редактор, но по совпадению на этой неделе Microsoft выпустила свой edit.

И да, он тоже написан на Rust и тоже не имеет внешних зависимостей. Правда, он весит ~300 КБ, а не 30 КБ. Но это уже вполне полноценный редактор, а не просто proof-of-concept.

Так что подход работает и уже используется корпорациями.

Что-то давно у меня тут тишина, надо, наверное, немножечко оживить.
Пока оживлю ссылкой на дружественный умеренно хардкорный подкаст про Meshtastic
https://t.me/sporadic_podcast/35

Я давний пользователь org-mode для всевозможных GTD-штук, в целом мой подход похож на подход Jethro Kuan с небольшими доработками.

Для того, чтобы на ходу добавлять новые задачи, я использую org-mobile, который пополнял либо руками, либо с помощью умеренно кривого скрипта, который просто копировал строчку, регэкспом и интерполяцией собирая из неё org-mobile-совместимую заметку, а уже потом, во время разбора инбокса я смотрел, что ж я там положил, описывал, и каталогизировал.

Для синхронизации файлов у меня везде используется syncthing, просто, чтобы не зависеть от серверов какой-то компании, и не отдавать свои данные куда ни попадя. Так что скрипт просто сидел, ждал пинга, и дописывал в файл. Последнее время я поймал себя на мысли, что во время разбора инбокса периодически пинаю свой gpt.el на предмет генерации заметочки, перед тем, как смотреть самому.

И тут меня осенило, что у меня ж LLMки кругом, надо это автоматизировать! Сказано — сделано! Сел, почесал репу, подумал, сформулировал пожелания, решил, что надо тогда уж красивенько принимать данные на вход ещё и из телеги. И веб-морду бы неплохо. Ну и почту ещё, которая до этого просто выкачивалась.

Получился inbox! Принимает на вход текст, ссылку, картинку, что там можно прислать, базово анализирует, кладёт в inbox.org в формате org-mobile.

А теперь хардкор: изначально я прикрутил openrouter, потому что удобно, дёшево, и сердито. Потом подумал, что платить за юнит-тесты я не хочу, и сделал юнит-тесты на локальной ollama. А потом потестировал, и понял, что для этих целей локальной ollama тупо достаточно!

Более того, у меня к моему домашнему k8s-кластеру был подключен raspberry pi, который у меня был подключён как k8s-нода, чтобы собирать данные с датчиков, я просто положил туда qwen3.5:4b и выставил API. И чудесным образом оказалось, что его достаточно для ста процентов моего применения, и можно даже за API не платить! Идеально формулирует краткую справку о том, что я кладу в инбокс.

Встала следующая проблема: современный веб — место недружелюбное и полное чудищ javascript'а, но неплохо бы как-то смотреть, что там происходит. На выручку приходит crawl4ai: тупо запускает хром и отдаёт ручки LLMке. В результате можно ходить на любой сайт, и смотреть, что происходит.

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

Стало лучше? Да. Стал бы я это делать без помощи Клода? Нет, конечно! Сколько лет жил без этого тула, и ещё столько же прожил бы.

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