Кеды Ковальского

Зал и Claude-based тренер. Расскажу вам сегодня об одном эксперименте - о том как использовал Клод для тренировок в зале. Где-то в марте я перестал заниматься с тренером, а в мае решил попробовать с Клодом расписать программу тренировок. В наличии была накопленная база по прошлым тренировкам - упражнения, веса, подходы - все это дело я дисциплинированно вел, сначала в эксельке, сейчас уже в навайбкоженной аппке - healthops. Так вот, за вечер с opus-4.7 мы обсудили и составили план на следующие 3 месяца. Ключевые цели ставил без точных цифр: 1. поднять подтягивания, это одно из любимых упражнений - тут цель просто улучшить просевший результат. 2. подтянуть жопу ягодичный мост, здесь цель - поддержка, кхе-кхе, мужского здоровья. 3. уменьшить талию - тут цель убрать спасательный круг вокруг пуза, ибо впереди лето, пляж, сап. 4. и заполнить остаток тренировки вспомогательными упражнениями. Дни тренировок - понедельник, среда пятница, план - 3 силовых и 1 кардио. Получилась программа на 12 недель, с отправной точкой as-is (просевшие показатели) и целевой точкой to-be. После каждой тренировки предполагалось фиксировать прогресс и делать промежуточный анализ. Должна была получиться хорошая трассировка прогресса с возможностью корректировки целей - все как в е*учем менеджменте, ага🙈 Так вот, интересные наблюдения за три месяца: 1. На первый взгляд, для непрофессионального тренера, программа кажется ооочень убедительной ))) а-ха-ха, как и любой другой результата труда агентов. Это на поверхностный взгляд, но дьявол же в деталях. 2. Теперь детали - уже в зале, выполняя тренировку закрадывается мысль - а не желает ли этот, сука, агент убить тебя?? Проходящие мимо тренера, при этом подбадривают тебя и говорят: да-да, дорогой, ты должен зае*аться!! На деле оказывается что некоторые веса подобраны неоптимально. Но точечно, по моей прикидке где-то ~5% программы. 3. Корректируя программу после тренировки - обезьяна агент признает ошибки и вносит правки и обещает больше так не делать😅, но он корректирует не все, а только следующую одну ))) и на последующих тренировках дисбаланс снова вылазит наружу. 4. Выходят новые версии моделей и летом появляются opus-4.8 и opus-5 - при смене модели, агенты анализируют всю программу и, о божэ!, ужасаются работе предыдущего коллеги: всё как в жизни. Что за долбоёб писал этот код? Надо немедленно всё переписать с нуля на расте. В результате, оставшаяся часть программы корректируется - меняются в основном веса, а упражнения (ядро программы) остается как есть. 5. В итоге, сейчас opus-5 уже не пытается убить меня так откровенно и даже слегка дрейфует в другую сторону и местами осторожничает🙂 Поэтому приходится чуть детальнее расписывать как прошла тренировка, чтобы он был посмелее (ощущения, запас по повторениям, развал техники и пр.). Какой итог - мне понравилось, следующие три месяца я уже прикинул новые цели и планирую составить новую программу и буду двигаться по ней. А еще временами, ловил себя на мысли - если выгорю в айтишке, пойду в фитнес-тренеры😁 Всем хороших выходных и больше спорта в жизни!😘

С добрым утром😊☕️

Эпигонство внутри возрожденного канона. Катаюсь по северам и проездом оказался в Югорске. Прогуливаясь по центру, зашел в храм. Внешне вполне обычный храм-новодел, каких нынче очень много - в деталях отличаются, но в общем и целом все под копирку. Задался я вопросом, что же такого произошло с церковной живописью, что работы XVIII века выглядят как итальянский Ренессанс, а нынешние работы как страдающее средневековье. Букв много, но зацепила фраза «эпигонство внутри возрожденного канона». Иконопись XIV-XV веков держалась до XVII века и резко поменялась (буквально за 50 лет) и к XVIII-XIX веку плотно обросла императорской бюрократией и академизмом. В начале XX века при расчистке старых икон под слоями олифы обнаружили средневековую живопись совершенно другого качества. И утвердился взгляд, что академизм XVIII века, это все западное влияние (кругом иноагенты ага) и вообще отход от Православия. И эта же установка победила спустя 70 лет когда началось массовое восстановление храмов. Утраченный канон живописи возрождался по книгам, альбомам и фотографиям. Вот и получается, строительный бум последних тридцати лет требует расписать тысячи храмов быстро и дёшево, и артель художников работает по фотокопиям, а не по старой школе. При подражании возрожденным правилам получается однотипная рисовка, без уникальности, форма вроде каноническая, а лицо как глянцевая иллюстрация, румянец приторный, линия безвольная. Нет души, сплошной CI/CD конвейер. У мастера XV века такого не было, потому что он не копировал - он работал. Можно подумать что раньше могли и умели, а сейчас разучились, но нет - и в XVIII веке провинциальные артели гнали попсу, и сегодня работают мастера у которых канон живой.

мама я в телевизоре тг-канале 😁

У кого-то работа — делать работу других проще. Попросили руководителя разработки Postgres Pro Enterprise Manager Алексея Лесовского рассказать о команде, чей продукт делает жизнь DBA лучше. Листайте карточки, чтобы узнать, чем Алексей занимается, пока в Москве все спят.

Как дела? Ух, сколько раз я задавал этот вопрос на 1-1, и почти всегда ответ на него - нормально! 🙈 Со временем я перестал воспринимать этот вопрос серьезно и сейчас начинаю с него как с приветствия. У вопроса очень широкая рамка и чтобы ответить честно, надо заглянуть внутрь себя, оценить своё состояние, выбрать соответствующее и решить, что безопасно озвучить в данный момент. Это вообще-то рефлексия и задача даже не на одну минуту. А ответ "Нормально" стоит ноль. Поэтому при такой широкой рамке, собеседник выбирает самое простой и дешёвый ответ. Так что на вопрос "как дела" не стоит ожидать серьезного, быстрого и осознанного ответа 🫠

PostgreSQL 19 REPACK. Заметил новость, в PostgreSQL 19 подвезут команду REPACK, как плавную замену VACUUM FULL и возможно CLUSTER. VACUUM FULL отмечен как deprecated, а CLUSTER пока как эквивалент. Из хорошего: - Меньше пишущей нагрузки - pg_repack вешает на таблицу триггер (каждый IUD пишется в log-таблицу, имеем двойную запись плюс WAL), а REPACK сразу читает изменения из WAL; на горячей таблице разница по нагрузке может быть о-го-го. Еще как следствие, никакого DDL на боевой таблице. - Поставка сразу из коробки, не нужен отдельный пакет/бинарник/экстеншен, нет привязки версии утилиты к мажорной версии. В закрытых контурах исчезает вопрос, а что за левое говно ПО вы тут ставите на прод?🤨 - Работа через привилегию MAINTAIN, которую можно выдать грантом (не нужен SUPERUSER). - Меньше шансов нарваться на блокировку, REPACK CONCURRENTLY берет одну блокировку на своп таблицы, а pg_repack берёт ACCESS EXCLUSIVE дважды. - Видимость прогресса через pg_stat_progress_repack, в то время как у pg_repack видимость нулевая: процесс идёт, подождешь, не развалишься😁 - Встроенная обработка индексов, без необходимости отдельного REINDEX CONCURRENTLY, т.е. меньше скриптовать. - Минимальные телодвижения при настройке, достаточно wal_level = replica, плюс слоты живут в отдельном пуле max_repack_replication_slots без риска отжать слоты у реплик или логических подписок. Но есть и нюансы: - Нужна полная копия таблицы, индексов, плюс временный файл под изменения за время копирования, плюс WAL, удерживаемый слотом. Запас по х2 - всё как раньше🤷‍♂️ - Партиционированные таблицы CONCURRENTLY не поддерживаются, с партициями придется поприседать. - SET lock_timeout в виде предохранителя от idle-транзакций (как обычно). - Никаких DDL сбоку во время операции (тоже как обычно). - CONCURRENTLY не MVCC-safe: старый снапшот увидит таблицу пустой. Пока получается что REPACK выигрывает в механике (меньше блокировок, нет триггерного оверхеда, наблюдаемость из коробки, нет стороннего ПО), а pg_repack выигрывает в функциональности (параллелизм, tablespace, партиции, политика ожидания, массовые режимы). Плюс pg_repack единственный вариант на всём, что меньше 19. Так что, отправлять на пенсию pg_repack рановато - для старых версий это единственный вариант, но и в 19 версии остается своя ниша - партиции и миграция на другой tablespace и таблицами/индексами где нужен параллелизм.

Раздувание задач Есть место которое болит - делать больше чем надо. Раньше я называл это scope creep, но если углубиться, то кроличья нора окажется гораздо глубже🙈 Часто кажется что расползание задач это внешняя проблема, но мало кто замечает что чаще оно начинается изнутри - от исполнителя, который хочет сделать пиздато хорошо. В литературе даже есть целая классификация: - Scope creep и его замечают чаще всего, это доработки извне (заказчик принес, стейкхолдеры и смежники накидывают "а ещё бы вот это") без пересмотра сроков и ресурсов🤨 Следующие варианты интереснее и приходят изнутри, от самого исполнителя: - Gold plating или золочение, это самое интересное! Исполнитель от любви к искусству делает больше или качественнее, чем требует DoD задачи )) заказчик об этом обычно не узнаёт. Я называю это "приводить японский сад в порядок". - Yak shaving это рекурсивное погружение - чтобы сделать A, надо починить B, для B нужен C, и каждый шаг оправдан, а суммарно пол-спринта ушло налево. Если вовремя не выйти, то увлекательное путешествие превращается в круги ада. - Discovered work - исполнитель наткнулся на то, что DoD объективно неполон. Это алмаз, правильно работающая инженерная внимательность, тут нужна правильная и аккуратная огранка и получится бриллиант. - Second-system effect - автор запилил скрипт на коленке, обрел успех и уверенность, решился на второй заход чтобы реализовать все задумки которые попридержал и вуа-ля! работающий скрипт превращается в космолет. Простой пример, есть тикет "эндпоинт отдаёт 500 вместо 400" - инженер вскрыл, что валидации нет во всём поддереве из 10 эндпоинтов, и юнит-тестов тоже нет. И вот развилка - починить 1 эндпоинт и закрыть тикет, или упороться и системно починить все 10 эндпоинтов (и взять кубок проблем-солвера). Пример сильно упрощенный, в жизни разглядеть эту развилку бывает непросто и увлеченный инженер обычно идет по второй тропинке. Но источник расползания определяет наличие процедуры: у внешнего scope creep есть пересмотр сроков и ресурсов через владельца скоупа, и вопрос там больше переговорный (поножовщина🤗). У внутреннего перфекционизма процедуры нет, исполнитель один на один со своей совестью, и все четыре внутренних механизма изнутри выглядят одинаково "надо сделать хорошо". Для внутренних случаев вопрос один - работа придуманная или обнаруженная? Цена путаницы двусторонняя: - придуманное, принятое за обнаруженное - раздувает спринт - обнаруженное, принятое за придуманное - дефект тихо остается в коде, потому что о нем никто не узнает. В итоге, прежде чем расширять задачу, стоит ответить - эта работа существовала бы, если бы я её не заметил? От ответа зависит, что с ней делать.