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

В целом думаю в 6 этапов сделать переезд пета на реакт:

0. Допить кофе.
1. Поехать в загородный клуб праздновать с женой юбилей, 4 года вместе как никак.
2. Просто начать собирать весь JS (о боже мой, целых 3 функции!) в один файл веб-паком, а странички (на самом деле одну страничку, гг) продолжать рендерить на бэкенде. Ну то есть аккуратно замержить ветку с 10 тяп-ляп коммитами, которая ещё и отстала на 20 коммитов от мастера с фиксами.
3. Притащить реакт и какой-нибудь хелловорлд на нём отрендерить.
4. Вытащить рендеринг главной странички из jinja2 в реакт/JSX.
5. Посмотреть, а как вообще у пацанов принято, глядишь, человечно сделаю.
6. А чо б и на typescript не перейти, буду модный, буду стильный, буду красивый.

Как же хочется посмотреть на этот троллейбус из буханки через полгода, с PWA и асинхронным ORM поверх SQLite базы на 36кб, только kafka не хватает, ей богу... Надо ещё репликацию в Казахстан замутить для пущей отказоустойчивости.

Нашёл я тут значит свои наработки 8-летней давности на #bash и немножко причесал.

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

Заточена под то, чтобы хранилось не больше 42 + лет эксплуатации резервных копий при ежедневном копировании и не больше 66 + лет эксплуатации - при ежечасном.

Найти #бэкап легко. Один и тот же бэкап может одновременно лежать в ежегодных, ежемесячных, ежедневных и ежечасных копиях, но, благодаря хардлинкам, это будет один файл. И создаваться он будет всего один раз. В итоге экономится дисковое I/O.

А самая прелесть - офигенно простая очистка лишнего. Просто ищем файлы с одной единственной ссылкой.

#бэкапы

https://github.com/strizhechenko/backup_scheme/tree/master

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

Зашёл на их сайт.

1. Не может запомнить откуда я, хотя один раз явно указал город.
2. Калькулятор стоимости калитки заканчивается сбором контактных данных (разумеется без реальной калькуляции). Ну ладно, калитка это сайд-проект, но тоже надо.
3. Предположил какие у меня размеры проёма. По ТЗ нашёл ширину, фактическую, которая получилась не измерял. А ещё нужна высота. И высота перегородки над воротами, до потолка. Ну, ляпнул наугад. Предлагает 4 варианта с ценами, снизу карусель на 5-6 вариантов без цен. Какого-либо способа сравнить их - нет.
4. Открыл те 4 варианта в отдельных вкладках, прокрутил до характеристик, попрыгал между вкладками, чтобы увидеть разницу. Разница - только в весе. От 6 до 11.5кг на квадратный метр полотна. Интересно, насколько легко в случае чего будет 75кг поднимать руками... Самые тяжёлые - дороже. Ну, вес - это надёжность.

Кажется их успех в продажах обеспечивается вообще _не_ официальным сайтом.

Сделали бы интерфейс вида:

Введите высоту, введите ширину.

Вводишь, получаешь:

- Ворота А - открываются, закрываются.
- Ворота Б - всё то же самое + варят кофе за 5000р.
- Ворота В - всё то же самое + за 2000р можно закрыться от жены и дрочить вприсядку (ну а зачем ещё гараж)
- Ворота Г - всё то же самое + поговорят с вами за жизнь и нальют водочки + за 3000р встроенная секция для маринования огурчиков.

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

Открыл комплектацию. Из всех слов понял только "сендвич-панель", наверное это про эксплуатацию секс-работников за еду.

#ФедиЧитальня #PostgreSQL15 не совсем из книги, но по той же теме.

Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:

- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими журналами одновременно)
- statement based - сплошная боль, есть места где можно получить неконсистентные данные между master и slave, но в случае условной бигдаты - очень низкие накладные расходы на передачу данных по сети, большой update на всю таблицу прилетит практически одним запросом; разве что выполнять его придётся заново на slave, из-за этого может быть длинный лаг репликации.

Если slave может блокировать удаление журнала master'ом, чтобы догнаться в случае ребута, чем больше отставание, тем больше размер журнала. Если slave вообще не догоняет master в принципе и отставание только нарастает - со временем это закончится забитым дисковым хранилищем.

В PostgreSQL есть Logical Log Streaming Replication, который позволяет не миррорить часть таблиц на slave. Как это применять - я не придумал. В теории можно не хранить на слейвах для актуальных данных архивные данные, что позволит немного сэкономить на дисковом пространстве, особенно если slave'ов много.

P.S:
- Раньше жил в прекрасном мире, где БД находится на том же сервере, где и приложение, ни о какой репликации и не думал.
- Сейчас живу в прекрасном мире, где БД поддерживает отдельная команда, репликация уже готова, хоть и без гарантии синхронных записи на мастер и чтения со слэйва (а я и не против), бери да пользуйся.

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

1. Личный пользовательский десктопный компьютер, на который легко переключаться с рабочего ноутбука, которые находятся на одном и том же рабочем столе. Из-за этого часть личных дел "протекла" на рабочий ноутбук. Вряд ли на нём есть много чего для слежки за сотрудниками, тут базовые рабочие процессы-то на линуксах не особо поддерживают, на входе я пару часов ёбся с интранет SSL-сертификатами и сменой пароля к SSL-сертификату для VPN (в итоге сделал это внутри контейнера с предыдущей Ubuntu LTS). У всех маки. Возможно переключаться будет впадлу и здесь меня может спасти nextcloud. А может и не спасти.

Вообще переключение у меня устроено так - есть usb-свитч, есть два HDMI-провода, воткнутые в большой монитор. Для переключения надо нажать кнопочку на USB-свитче, а потом кнопочку на мониторе для переключения источника. Такое себе удобства. Так-то второй монитор есть, но я его чот не использую, хотя казалось бы - разберись уже с usb type-c -> displayport и будет тебе счастье. Глядишь, ещё и заряжаться от монитора можно будет. Или монитор питать. Но эт не точно. А пока блок питания ноута (гигантский, сука, весит больше чем макбук про 15' наверное) прикрутил стяжками к столу и мне норм.

2. Планировщик для того чтобы внятно и раздельно планировать краткосрочную рутину, среднесрочные дела и встречи и долгосрочные проекты. Постоянно всё проёбываю, календарь игнорирую по той причине что он гвоздями прибит к _датам_ вместо _последовательностей_.

У меня в целом есть где-то на 60% дописанный планировщик поддерживающий нужный мне подход, я бы кое-где поэкспериментировал ещё с подходом, но чтобы двигаться нормально нужно менять архитектуру, очень многое зависит от удобства интерфейса, а на формах, которые рендерятся на бэкенде далеко не уедешь. Наверное за день реально распилить проект на бэк, состоящий из API и фронт на реакте (заодно, глядишь, на работе смогу фронтам ТЗ мерж-реквестами ставить, пока я в режиме read-only там, потому что даже не ебу как это всё протестировать).

3. Дневник, чтобы спускать пар, поэтому у меня стала всё чаще взрываться жопа. Куда-то просрал свой контейнер с мастодоном, надо ещё раз порыться по /var/lib/lxc на трёх железках.

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

Сходил вчера к нутрициологу. Теперь у меня в жизни появилась женщина, которая спрашивает как я покушал и как я покакал. Аж на слезу пробило, лол.

По её словам, в принципе если процентов на 5 скорректировать мои пищевые привычки и чуток дожать дисциплину, усвоение пищи и витаминов подрастут процентов на 15, можно будет меньше хавать, а я слегка схудну и её приёмы отобьются по баблу за счёт экономии на продуктах за 2-3 месяца :D

Самое сложное это, конечно, правильно жрать колёса. Те, которые я ем за полчаса до еды ещё ладно. Но тут она чот парочку ещё накинула, хотя у меня свои уже в таблетницу не влезают. Сейчас я иногда такой "бляяя колёса" и просто закидываю всю дневную пачку в себя. Плохо, но всяко лучше, чем не закинуть. А тут "это за полчаса до еды утром, после нельзя; это между приёмами пищи, но перекусы можно игнорировать, это через полчаса после еды, а это прямо с едой, но только если она достаточно жирная".

Ещё сейчас смотрю на результаты анализов и прям вижу, как дисциплина, в теории, позволяет сократить дозировку колёс. И это тоже, сука, экономит бабки! Вот думаю, стоит ли с этой идеей к эндокринологу идти (по ДМС, конечно, а то его приём 2к стоит почти уже, без ДМС я бы даже не сомневался) или развлекаться самолечением.

Смущает то, что мы проворачиваем три эксперимента одновременно - снижаем кислотность желудка, докидываем лёгкое желчегонное и меняем 10% сливки в кофе на 3.2% молоко. Из-за этого не можем точно определить, что было эффективно, а что нет.

#дед #кряхтит на #ЗОЖ

Подумал тут, а ведь корелляции в трафике можно выявлять через эдакое подобие производных функций, не держа вообще всё в памяти. Берём 1000 пакетов. Накладываем 128 байт payload ethernet фрейма первого пакета на 128 таких же байт второго, совпадающая битмаска будет хэш-ключиком счётчика. Читаем третий, забываем первый, сравниваем со вторым. Повторяем. Берём топ счётчика и если он больше 50% то что-то тут не так. Так #ддосы можно в 99% случаев вообще вслепую выявлять, вообще не парся пакеты.

При хайлоадах можно просто 5-10-50-500 пакетов/сек хватать и как-нибудь скользящее окно замутить, чтобы всегда актуальная инфа была. Или 2 счётчика иметь, заполнять сперва один, потом второй, сравнивать между собой, потом первый занулять, заполнять заново. Ух бля, статистикал лёрнинг, нахуй.

Записался на сдачу грейдов, но ощущаю это гиблым делом.

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

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

Тут заметил упоминание ЧПУ.

Вспомнил, как я в 2012 мастерил "убийцу микротика" для провайдеров - дистрибутив Linux для небольших провайдеров, заточенный под работу 10гбит/сек, назвали его XGE, типа X Gigabit Ethernet. В неправильной раскладке получалось ЧПУ, за что меня коллеги прозвали оператором ЧПУ.

В целом колхоз-колхозом, но опыт интересный. Много ядерного программирования, не только ОБЫЧНЫЙ ЛИНУКС ВЗЯЛ И НАСТРОИЛ И ДЕНЕГ ХОЧЕТ, а прям побитый продакшном проект, вот прям из коробки хоба и взлетает многое. Единый конфиг опять же, копию развернуть - буквально _один_ файл скинуть на новую установку, IP-адреса поменять и погнали. Да и в целом после предыдущей версии нашего роутера без ipset - это был глоток свежего воздуха в вопросе масштабирования, раньше на дереве цепочек iptables что acl, что NAT, что шейперы работали и это была жопа где-то после 2000 абонентов.

Увы, проект не взлетел, потому что небольшие провайдеры зажимают любую копеечку, а большие хотят большой американский вендор аппаратного решения. В целом, если бы в проект вложили где-то в 6-7 раз больше денег (и наняли в 3-4 раза больше людей, а не одного человека на полставки, потому что появился ещё один более выгодный проект), может быть что-то из этого и получилось. Но вышло немного иначе.

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

Такая вот грустная история импортозамещения.