Всем привет!
Меня зовут Слава, некоторые могут знать меня, как @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'а вручную, я писал, и там прямо боль.

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