{"blog":[{"date":"2026-01-14","lastmod":"2026-01-19T15:24:31+03:00","md_url":"https://apkhmv.xyz/blog/code-review-sucks/index.md","slug":"code-review-sucks","tags":["код ревью","AI","процессы"],"title":"Я больше не могу это ревьювить","url":"https://apkhmv.xyz/blog/code-review-sucks/"}],"episodes":[{"abstract":"Пилотный выпуск без гостей. Александр Пахомов рассказывает, почему десятипальцевая (слепая) печать — важный навык для программиста и где её освоить, а затем разбирает проектирование ошибок публичного REST API: какие HTTP-коды возвращать и почему тело ошибки стоит отдавать в формате RFC 7807 (problem+json).","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/01_Pilot_1.mp3","chapters":[{"chunk_id":"episode-01#c0","idx":0,"start":19,"title":"Вступление"},{"chunk_id":"episode-01#c1","idx":1,"start":56,"title":"Слепая печать: зачем она программисту"},{"chunk_id":"episode-01#c2","idx":2,"start":223,"title":"Как и где освоить слепую печать"},{"chunk_id":"episode-01#c3","idx":3,"start":331,"title":"Ошибки REST API: постановка задачи"},{"chunk_id":"episode-01#c4","idx":4,"start":352,"title":"Что такое REST и требования к ошибкам"},{"chunk_id":"episode-01#c5","idx":5,"start":467,"title":"HTTP-коды по группам (1xx–5xx)"},{"chunk_id":"episode-01#c6","idx":6,"start":960,"title":"Тело ошибки и RFC 7807 (problem+json)"},{"chunk_id":"episode-01#c7","idx":7,"start":1309,"title":"Заключение и ссылки"}],"date":"2022-10-03","duration_sec":1366,"guests":[],"key_takeaways":["Слепая (десятипальцевая) печать ценна не столько скоростью, сколько лёгкостью входа в состояние потока и комфортом работы без подсказок IDE.","Осваивать слепую печать удобно короткими подходами на тренажёрах TypingClub и Clava; Clava умеет тренировать символы языков программирования.","Для внутреннего API достаточно команде договориться о формате ошибок; публичный API обязан следовать внешним конвенциям HTTP.","Коды 4xx сигнализируют об ошибке клиента и требуют понятного тела с объяснением, что не так и что делать; коды 5xx означают ошибку на стороне сервера.","В ответах 5xx нельзя раскрывать детали (stack trace, версии библиотек) — это security-антипаттерн; возвращайте абстрактный «internal server error».","Коды 503 и 504 обычно возвращает инфраструктура (например, Kubernetes), а не код приложения.","Стандарт RFC 7807 (медиатайп application/problem+json) задаёт единое тело ошибки с полями type, title, status, detail и instance.","В экосистеме Spring формат problem+json даёт библиотека Zalando Problem; на Micronaut обёртку легко написать самостоятельно."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"TypingClub — тренажёр слепой печати","url":"https://www.typingclub.com"},{"title":"Clava — тренажёр печати для программистов","url":"https://clava.org"},{"title":"RFC 7807 — Problem Details for HTTP APIs","url":"https://www.rfc-editor.org/rfc/rfc7807"},{"title":"Zalando Problem — библиотека problem+json для Spring","url":"https://github.com/zalando/problem"}],"md_url":"https://apkhmv.xyz/podcast/episode-01/index.md","number":1,"season":1,"slug":"episode-01","tags":["слепая печать","REST API","HTTP-коды","обработка ошибок","RFC 7807"],"title":"#1: Пилот: слепая печать, коды ошибок","transcript_date":"2026-09-15","transcript_status":"reviewed","url":"https://apkhmv.xyz/podcast/episode-01/"},{"abstract":"Александр Пахомов разбирает, почему коммит-месседж — это история проекта, а не формальность: правила оформления заголовка и тела, conventional commits, атомарные коммиты и главное правило — договориться о формате со всей командой. Во второй части — OpenAPI-спецификация: подходы code-first и design-first, генерация документации и всегда актуального клиента, сервисы, которые продают API без спеки, и история о том, как несовершенный туллинг съел два дня работы из-за стёртых при компиляции имён параметров.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/02_TF_OpenAPI.mp3","chapters":[{"chunk_id":"episode-02#c0","idx":0,"start":21,"title":"Вступление"},{"chunk_id":"episode-02#c1","idx":1,"start":70,"title":"Комментарии к коммитам: пишем историю проекта"},{"chunk_id":"episode-02#c2","idx":2,"start":177,"title":"Правила коммит-месседжа"},{"chunk_id":"episode-02#c3","idx":3,"start":325,"title":"Метаданные, conventional commits, атомарность"},{"chunk_id":"episode-02#c4","idx":4,"start":464,"title":"OpenAPI: что это и зачем"},{"chunk_id":"episode-02#c5","idx":5,"start":583,"title":"Code-first против design-first"},{"chunk_id":"episode-02#c6","idx":6,"start":647,"title":"Single source of truth"},{"chunk_id":"episode-02#c7","idx":7,"start":737,"title":"Кодогенерация, валидация, документация"},{"chunk_id":"episode-02#c8","idx":8,"start":836,"title":"Сервисы без спеки"},{"chunk_id":"episode-02#c9","idx":9,"start":908,"title":"Несовершенный туллинг: история на два дня"},{"chunk_id":"episode-02#c10","idx":10,"start":1294,"title":"Заключение"}],"date":"2022-10-17","duration_sec":1341,"guests":[],"key_takeaways":["Коммит-месседж должен отвечать на вопросы «что» и «почему»: что поменялось, видно в диффе, а вот почему — только из сообщения коммита.","Базовые правила: заголовок до 50 символов, с большой буквы, без точки, в imperative mood (add, fix, improve); строки тела до 72 символов; тело отделяется пустой строкой.","Правило №0 — формат коммитов должен быть единым: о нём надо договориться со всей командой, иначе git log превращается в помойку, по которой невозможно искать.","Если коммит трудно описать — вы либо сделали лишнее, либо слишком много за раз: это сигнал разбить изменение на более атомарные коммиты.","Conventional commits добавляют scope и структуру, чтобы поверх git-лога автоматизировать релиз-ноуты и версионирование.","OpenAPI-спецификация — описание HTTP API, читаемое и человеком, и машиной: из неё генерируются документация и всегда up-to-date клиент.","Выбор между code-first и design-first — это выбор single source of truth: либо код определяет спецификацию, либо спецификация — код.","Туллинг несовершенен: Java стирает имена параметров интерфейсов при компиляции (arg0, arg1), из-за чего Micronaut-плагин терял связь @PathVariable с path — два дня на «бинарный поиск» причины."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Conventional Commits — спецификация","url":"https://www.conventionalcommits.org"},{"title":"OpenAPI Initiative","url":"https://www.openapis.org"},{"title":"Подкаст «Запуск завтра»","url":"https://libolibo.ru/zapuskzavtra"}],"md_url":"https://apkhmv.xyz/podcast/episode-02/index.md","number":2,"season":1,"slug":"episode-02","tags":["git","коммит-месседжи","OpenAPI","REST API","документация"],"title":"#2: Гундосая спека: комменты, Open API","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-02/"},{"abstract":"Александр Пахомов делится практикой селф-ревью: как отстраниться от собственного кода и отревьюить свой pull request так, будто его прислал незнакомый человек. А затем разбирает Homebrew: почему в macOS нет родного пакетного менеджера, что такое формулы, кеги и краны, как написать собственную формулу — на примере базы данных Ignite 3 — и отправить её в homebrew-core.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/03_TF_Homebew.mp3","chapters":[{"chunk_id":"episode-03#c0","idx":0,"start":21,"title":"Вступление"},{"chunk_id":"episode-03#c1","idx":1,"start":69,"title":"Селф-ревью: сделай ревью себе сам"},{"chunk_id":"episode-03#c2","idx":2,"start":254,"title":"Homebrew: зачем macOS пакетный менеджер"},{"chunk_id":"episode-03#c3","idx":3,"start":301,"title":"Терминология: формулы, кеги, краны"},{"chunk_id":"episode-03#c4","idx":4,"start":389,"title":"Как работает установка"},{"chunk_id":"episode-03#c5","idx":5,"start":464,"title":"Пишем собственную формулу"},{"chunk_id":"episode-03#c6","idx":6,"start":579,"title":"Pull request в homebrew-core и обновления"},{"chunk_id":"episode-03#c7","idx":7,"start":621,"title":"Аналитика и собственные tap'ы"},{"chunk_id":"episode-03#c8","idx":8,"start":666,"title":"Заключение: книга с кабанчиком"}],"date":"2022-10-31","duration_sec":762,"guests":[],"key_takeaways":["Селф-ревью: прежде чем просить ревью у коллег, отревьюй свой pull request сам — глазами человека со стороны, который не писал ни строчки этого кода.","Отстраниться помогает пауза: отправить PR драфтом вечером и отревьюить утром со свежей головой — или закоммитить до обеда и посмотреть после.","Homebrew — «недостающий пакетный менеджер macOS»: из коробки его нет, потому что Apple продвигает App Store.","Терминология Homebrew — из пивоварения: формула (рецепт пакета на Ruby), кега, Cellar (/usr/local/Cellar), tap (git-репозиторий с формулами), bottle (предсобранный пакет), cask (GUI-приложения).","Homebrew — это программа на Ruby поверх git: формулы лежат в репозитории homebrew-core, а brew update — по сути git pull, поэтому его важно выполнять перед каждой установкой.","Своя формула: brew search — проверить имя, brew create \u003curl\u003e — создать Ruby-файл, описать метод install на DSL и отправить pull request в homebrew-core; open-source с адекватной лицензией обычно принимают.","Доставка обновления — это просто pull request с новой ссылкой на дистрибутив и обновлённой чек-суммой.","Если в основной репозиторий нельзя — создайте собственный tap: пользователи подключат его командой brew tap."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Homebrew — The Missing Package Manager for macOS","url":"https://brew.sh"},{"title":"Репозиторий homebrew-core","url":"https://github.com/Homebrew/homebrew-core"},{"title":"«Designing Data-Intensive Applications» — та самая книга с кабанчиком","url":"https://dataintensive.net"},{"title":"Плейлист Distributed Systems от Мартина Клеппмана","url":"https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB"}],"md_url":"https://apkhmv.xyz/podcast/episode-03/index.md","number":3,"season":1,"slug":"episode-03","tags":["Homebrew","macOS","пакетные менеджеры","код ревью"],"title":"#3: Пакетный менеджер: Homebrew, self-review","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-03/"},{"abstract":"Новая рубрика подкаста: разбор тем книги «Программист-прагматик» — топики It's Your Life, The Cat Ate My Source Code и Software Entropy, про ответственность, отговорки и теорию разбитых окон в коде. Во второй части Александр Пахомов признаётся, что пишет тесты до реализации: как устроен цикл TDD, почему он работает даже в легаси-системах, какие плюсы даёт — от тестов-спецификаций до крепкого сна — и лайфхак с красным тестом как чекпоинтом для выхода из состояния потока.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/04_Pragmatic_TDD.mp3","chapters":[{"chunk_id":"episode-04#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-04#c1","idx":1,"start":71,"title":"«Программист-прагматик»: новая рубрика"},{"chunk_id":"episode-04#c2","idx":2,"start":207,"title":"Топик 1: It's Your Life"},{"chunk_id":"episode-04#c3","idx":3,"start":370,"title":"Топик 2: The Cat Ate My Source Code"},{"chunk_id":"episode-04#c4","idx":4,"start":515,"title":"Топик 3: Software Entropy и разбитые окна"},{"chunk_id":"episode-04#c5","idx":5,"start":807,"title":"TDD: признание и история про ETL"},{"chunk_id":"episode-04#c6","idx":6,"start":944,"title":"Как работает цикл red–green"},{"chunk_id":"episode-04#c7","idx":7,"start":1110,"title":"TDD в реальных проектах с легаси"},{"chunk_id":"episode-04#c8","idx":8,"start":1217,"title":"Плюсы: спецификация, инфраструктура, дизайн"},{"chunk_id":"episode-04#c9","idx":9,"start":1598,"title":"Лайфхак: красный тест как чекпоинт"},{"chunk_id":"episode-04#c10","idx":10,"start":1719,"title":"Заключение и цитата Кента Бека"}],"date":"2022-11-14","duration_sec":1785,"guests":[],"key_takeaways":["It's Your Life: у программистов редкая свобода выбора; как говорил Мартин Фаулер — «вы можете изменить свою организацию или сменить организацию». Сначала попытайтесь улучшить, и только потом уходите.","The Cat Ate My Source Code: доверие в команде строится на ответственности за свою работу — предоставляйте решения, а не отговорки.","Software Entropy: техдолг распространяется по проекту как разбитые окна по району — одна допущенная небрежность легитимизирует следующие. Не живите с разбитыми окнами: чините сразу или прикрывайте тикетом.","Цикл TDD: красный тест → минимально достаточная реализация → зелёный тест → следующий тест; повторять, пока не покрыты все значимые кейсы.","TDD работает и в легаси: не рефакторьте всё подряд — выносите новую логику в отдельную сущность, разрабатывайте её через тесты и интегрируйте уже проверенной.","Тесты, написанные до кода, читаются как спецификация, а тестовая инфраструктура и DSL появляются сами: тестом вы формулируете требование, а мысль плохим кодом не выразишь.","TDD улучшает дизайн продакшн-кода: компоненты становятся инкапсулированными «чёрными ящиками», код — более компонуемым и гибким, а уверенность в нём даёт спокойный сон.","Лайфхак: красный тест — чекпоинт для выхода из потока; на следующий день запускаешь упавший тест и мгновенно возвращаешься в контекст."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"Кент Бек — «Экстремальное программирование. Разработка через тестирование»","url":"https://www.oreilly.com/library/view/test-driven-development/0321146530/"}],"md_url":"https://apkhmv.xyz/podcast/episode-04/index.md","number":4,"season":1,"slug":"episode-04","tags":["TDD","тестирование","Программист-прагматик","техдолг","книги"],"title":"#4: Прагматичные тесты: TDD, техдолг","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-04/"},{"abstract":"Продолжение разбора «Программиста-прагматика»: каша из топора и сваренная лягушка, good enough software, портфель знаний, техники критического мышления и почему коммуникация — половина работы инженера. Во второй части Александр Пахомов разбирает SOLID не по учебнику, а по практике: какие принципы он применяет каждый день (single responsibility, open-closed), к каким относится скептически (interface segregation) и почему главное в принципах — разумность, а не догма. Рекомендация выпуска — книга «Пиши, сокращай».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/05_SOLID_skills.mp3","chapters":[{"chunk_id":"episode-05#c0","idx":0,"start":19,"title":"Вступление"},{"chunk_id":"episode-05#c1","idx":1,"start":47,"title":"Каша из топора: будьте катализатором изменений"},{"chunk_id":"episode-05#c2","idx":2,"start":181,"title":"Сваренная лягушка: помните о большой картине"},{"chunk_id":"episode-05#c3","idx":3,"start":325,"title":"Good enough software"},{"chunk_id":"episode-05#c4","idx":4,"start":574,"title":"Портфель знаний"},{"chunk_id":"episode-05#c5","idx":5,"start":1021,"title":"Челленджи: что и как учить"},{"chunk_id":"episode-05#c6","idx":6,"start":1339,"title":"Критическое мышление"},{"chunk_id":"episode-05#c7","idx":7,"start":1689,"title":"Communicate: говорите и пишите хорошо"},{"chunk_id":"episode-05#c8","idx":8,"start":2447,"title":"SOLID на практике"},{"chunk_id":"episode-05#c9","idx":9,"start":3013,"title":"Заключение: «Пиши, сокращай»"}],"date":"2022-11-28","duration_sec":3065,"guests":[],"key_takeaways":["Будьте катализатором изменений: не просите у людей готовый результат — услышите «нет»; начните сами, как странник с кашей из топора, и люди подтянутся со своими «ингредиентами».","Не сваритесь как лягушка: держите «градусник» — следите за большой картиной, чтобы вовремя заметить, что проект (или вы сами) движется не туда.","Good enough software сегодня чаще всего лучше фантазий об идеальном завтра: выпускайте раньше, собирайте фидбэк — и, как художник у картины, знайте, когда остановиться.","Знания — это инвестиционный портфель: вкладывайтесь регулярно, диверсифицируйте, управляйте рисками (узкая экспертиза может «сгореть» вместе с технологией) и периодически ребалансируйте.","Софт-скиллы — harder than hard: софт мы пишем для людей, поэтому нетехническая литература не менее важна технической.","Критическое мышление по авторам: пять «почему», кто выгодоприобретатель, каков контекст (best practices — best для кого?), своевременно ли это и почему это вообще проблема.","Одинаково важно, что вы говорите и как: плохая презентация нивелирует гениальную идею; формулируйте мысль до документа и доклада и подбирайте язык под аудиторию.","SOLID — не догма: SRP и OCP делают код проще и расширяемым, LSP — базовая гигиена контрактов, а ISP и DIP легко довести до абсурда; соблюдайте разумность."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"Максим Ильяхов, Людмила Сарычева — «Пиши, сокращай»","url":"https://book.glvrd.ru"}],"md_url":"https://apkhmv.xyz/podcast/episode-05/index.md","number":5,"season":1,"slug":"episode-05","tags":["Программист-прагматик","SOLID","soft skills","коммуникация","книги"],"title":"#5: Солидные скиллы: soft skills, SOLID","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-05/"},{"abstract":"Разбор второй главы «Программиста-прагматика»: хороший дизайн — тот, который легче изменить, DRY — про знания, а не только про код, ортогональные системы и обратимость решений. Во второй части Александр Пахомов делится первыми впечатлениями Java-разработчика от Go: почему не Kotlin, не Rust и не Python, как Advent of Code стал полигоном для нового языка и чем подкупают gofmt, go mod и простота вместо вопроса «как реализован HashSet». Рекомендация выпуска — «Чистая архитектура» Роберта Мартина.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/06_Golang.mp3","chapters":[{"chunk_id":"episode-06#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-06#c1","idx":1,"start":141,"title":"Важность дизайна: хороший дизайн легче изменить"},{"chunk_id":"episode-06#c2","idx":2,"start":461,"title":"DRY: не дублируйте знания"},{"chunk_id":"episode-06#c3","idx":3,"start":1007,"title":"Ортогональные системы"},{"chunk_id":"episode-06#c4","idx":4,"start":1313,"title":"Обратимость изменений"},{"chunk_id":"episode-06#c5","idx":5,"start":1426,"title":"Go: почему именно он"},{"chunk_id":"episode-06#c6","idx":6,"start":1698,"title":"Advent of Code как полигон"},{"chunk_id":"episode-06#c7","idx":7,"start":1825,"title":"Первые впечатления: gofmt, модули, простота"},{"chunk_id":"episode-06#c8","idx":8,"start":2033,"title":"Set из мапы и независимость от IDE"},{"chunk_id":"episode-06#c9","idx":9,"start":2297,"title":"Заключение: «Чистая архитектура»"}],"date":"2022-12-12","duration_sec":2351,"guests":[],"key_takeaways":["Хороший дизайн — тот, который легче изменить: все принципы проектирования (SRP, DRY, open-closed) в конечном счёте служат лёгкости изменений.","Лёгкость изменений — это ценность, а не правило: для одноразового скрипта «хороший дизайн» может быть оверкилом.","DRY — про знания, а не только про код: не дублируйте документацию, описание API и схемы данных — генерируйте их из единственного источника правды (OpenAPI, генераторы клиентов).","Не всякое дублирование — зло: одинаковые сегодня валидации двух разных бизнес-правил (18+ для покупки вина и для брака) объединять не стоит — завтра правила разойдутся, и общий код станет проблемой.","Ортогональность — изменения в одной части не трогают другие: это локализует баги, позволяет собирать компоненты как кубики и прячет вендора в одном месте.","Золотое правило: лёгкость написания юнит-тестов — отличный признак ортогональности системы.","Не существует окончательных решений: AWS завтра сменится на bare metal — проектируйте большие изменения обратимыми и разбивайте даже монолит на компоненты.","Go подкупает прагматизмом: единый gofmt и модули из коробки убирают холивары, язык читается без вопросов, порог входа — пара часов; Advent of Code — идеальный полигон для изучения нового языка."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"Go by Example","url":"https://gobyexample.com"},{"title":"A Tour of Go","url":"https://go.dev/tour/"},{"title":"Advent of Code","url":"https://adventofcode.com"},{"title":"Роберт Мартин — «Чистая архитектура»","url":"https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/"}],"md_url":"https://apkhmv.xyz/podcast/episode-06/index.md","number":6,"season":1,"slug":"episode-06","tags":["Программист-прагматик","Go","проектирование","DRY","книги"],"title":"#6: Прагматичный Golang: design, dry, Go","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-06/"},{"abstract":"Продолжение второй главы «Программиста-прагматика»: чем трассирующий код отличается от прототипа и почему первый — это продакшн-скелет с урезанной функциональностью, а второй всегда выкидывается. Затем — предметно-ориентированные языки (DSL): внутренние и внешние, и почему тесты — идеальное место для первого собственного DSL. И большая тема оценивания: как точность оценки задаёт ожидания, техника PERT с тремя сценариями, модель с критическими параметрами и лучший ответ на просьбу об оценке — «я к тебе вернусь». Полезняшка — игра Vim Adventures.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/07_Estimations.mp3","chapters":[{"chunk_id":"episode-07#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-07#c1","idx":1,"start":62,"title":"Стрельба трассирующими"},{"chunk_id":"episode-07#c2","idx":2,"start":265,"title":"Преимущества трассирующего кода"},{"chunk_id":"episode-07#c3","idx":3,"start":379,"title":"Когда выстрел мимо: итерации"},{"chunk_id":"episode-07#c4","idx":4,"start":536,"title":"Прототипы: учиться малой кровью"},{"chunk_id":"episode-07#c5","idx":5,"start":752,"title":"Прототип архитектуры и опасность недопонимания"},{"chunk_id":"episode-07#c6","idx":6,"start":973,"title":"DSL: предметно-ориентированные языки"},{"chunk_id":"episode-07#c7","idx":7,"start":1371,"title":"Оценивание: точность задаёт ожидания"},{"chunk_id":"episode-07#c8","idx":8,"start":1739,"title":"Модель, критические параметры, PERT"},{"chunk_id":"episode-07#c9","idx":9,"start":2072,"title":"Слона едят по частям"},{"chunk_id":"episode-07#c10","idx":10,"start":2171,"title":"Заключение: Vim Adventures"}],"date":"2022-12-26","duration_sec":2258,"guests":[],"key_takeaways":["Трассирующий код — не прототип: это полноценный продакшн-скелет (база, CI/CD, интеграции) с урезанной функциональностью, который быстро доставляет пользователю работающий end-to-end сценарий.","Преимущества трассирующего кода: ранняя обратная связь, продуктивные разработчики (цикл доставки уже настроен) и всегда есть что показать заказчику.","Промах трассирующего выстрела — нормально: скелет и пайплайн остаются, следующая итерация корректирует направление.","Прототип, наоборот, всегда выкидывается: прототипируйте, чтобы учиться, а не чтобы кого-то убедить; валидацию, полноту и устойчивость к ошибкам можно смело игнорировать.","Главная ошибка прототипирования — позволить воспринять прототип как почти готовый продукт; если донести это не получается, пишите трассирующий код.","DSL приближает код к предметной области: внутренние DSL (Spock, RSpec) ограничены языком-хостом, внешние (Cucumber) — только своим парсером; самое безопасное место для первого DSL — тестовая инфраструктура.","Точность оценки задаёт ожидания: «130 дней» провоцирует планирование день в день — скажите «около полугода»; до 15 дней оценивайте в днях, до 6 недель — в неделях, до 20 недель — в месяцах, дальше — подумайте дважды.","Оценивайте через модель (компоненты → критические параметры → сценарии) и PERT (оптимистичная/вероятная/пессимистичная оценки со сценариями); итерируйте оценки вместе с кодом, а лучший ответ на просьбу об оценке — «я к тебе вернусь»."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"Vim Adventures — игра для прокачки навигации в Vim","url":"https://vim-adventures.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-07/index.md","number":7,"season":1,"slug":"episode-07","tags":["Программист-прагматик","прототипирование","DSL","оценка проектов","книги"],"title":"#7: Трассирующий код: прототипы, оценки","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-07/"},{"abstract":"Почему Java стартует медленно — класс-лоадинг, интерпретация, прогрев JIT — и как GraalVM native image ускорил command-line-приложение Александра с 3,5 секунд до 40 миллисекунд: closed-world assumption, инициализация классов в build time и цена в виде ручных метаданных для рефлексии. Плюс обзор альтернатив — AppCDS и CRaC от Azul. Во второй части — расследование флэки-тестов: как Mockito записывает вызовы в глобальный shared-state стек внутри when/thenReturn, почему это ломается в многопоточности и когда вместо мока нужен стаб, фейк или интеграционный тест. Полезняшка — «Распределённые данные» Алекса Петрова.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/08_GraalVM.mp3","chapters":[{"chunk_id":"episode-08#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-08#c1","idx":1,"start":61,"title":"Затравка: с 3,5 секунд до 40 миллисекунд"},{"chunk_id":"episode-08#c2","idx":2,"start":117,"title":"Как стартует Hello World на Java"},{"chunk_id":"episode-08#c3","idx":3,"start":381,"title":"Сравнение с Go"},{"chunk_id":"episode-08#c4","idx":4,"start":478,"title":"GraalVM: native image и closed world"},{"chunk_id":"episode-08#c5","idx":5,"start":783,"title":"Приседания: метаданные, рефлексия, агент"},{"chunk_id":"episode-08#c6","idx":6,"start":1206,"title":"CDS и AppCDS"},{"chunk_id":"episode-08#c7","idx":7,"start":1353,"title":"CRaC от Azul"},{"chunk_id":"episode-08#c8","idx":8,"start":1502,"title":"А нужно ли это вам?"},{"chunk_id":"episode-08#c9","idx":9,"start":1678,"title":"Mockito: флэки-тесты и shared state"},{"chunk_id":"episode-08#c10","idx":10,"start":2097,"title":"Моки, стабы, фейки — и когда мок не нужен"},{"chunk_id":"episode-08#c11","idx":11,"start":2492,"title":"Заключение: Database Internals"}],"date":"2023-01-09","duration_sec":2552,"guests":[],"key_takeaways":["Java-старт дорог из-за класс-лоадинга и интерпретации до прогрева JIT: Hello World — около 800 мс на Java 17 против 5 мс у скомпилированного Go.","GraalVM native image переносит класс-лоадинг и компиляцию в build time (closed-world assumption) — старт CLI-приложения ускорился с 3,5 секунд до 40 миллисекунд, на два порядка.","Graal меняет привычную семантику: статические блоки исполняются при сборке (значение env, прочитанное в build time, «зашьётся» и в проде), а рефлексия, ресурсы и динамическая загрузка требуют явных метаданных — иначе ClassNotFound в рантайме.","Альтернативы: AppCDS — дамп загруженных классов приложения (примерно вдвое быстрее старт), и CRaC от Azul — восстановление уже прогретого приложения за десятки миллисекунд, но с очень узкой нишей.","Всегда спрашивайте, является ли проблема проблемой: микросервису за лоад-балансером с хелс-чеками скорость старта почти не важна, а вот для CLI-утилиты на Java это фактически бизнес-требование — идеальная ниша GraalVM.","Флэки-тесты от Mockito: конструкция when(...).thenReturn(...) пишет вызовы в глобальный shared-state стек, и конкурентный вызов мока из другого потока вклинивается между push и pop — отсюда «несовпадение типов».","Моки — для тестирования поведения (Фаулер, «Mocks Aren't Stubs»); если мок — просто затычка для конструктора из семи сервисов, это запах: подойдут стаб, фейк или дамми, а лучше — интеграционный тест с реальным кодом.","Мок оправдан на крайней точке системы — например, mock-сервер для вендорного REST API, к которому нет тестовых серверов."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"GraalVM","url":"https://www.graalvm.org"},{"title":"Проект CRaC (Coordinated Restore at Checkpoint)","url":"https://openjdk.org/projects/crac"},{"title":"Мартин Фаулер — «Mocks Aren't Stubs»","url":"https://martinfowler.com/articles/mocksArentStubs.html"},{"title":"Алекс Петров — «Database Internals» («Распределённые данные»)","url":"https://www.databass.dev"}],"md_url":"https://apkhmv.xyz/podcast/episode-08/index.md","number":8,"season":1,"slug":"episode-08","tags":["Java","GraalVM","производительность","Mockito","тестирование"],"title":"#8: Медленная Java: GraalVM, Mockito","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-08/"},{"abstract":"Глава «Программиста-прагматика» про ежедневные инструменты: почему plain text — самое живучее представление знаний, как сделать shell своей вотчиной (темы, prompt, алиасы, fish), чек-лист совершенства во владении редактором, зачем всегда нужна система контроля версий и философия дебаггинга — чинить проблему, а не искать виновных, воспроизводить багу тестом и читать чёртово сообщение об ошибке. Бонус: подкаст зафичерил Apple, и Александр рассказывает, на что это похоже. Полезняшка — лекция Джона Остерхаута «A Philosophy of Software Design».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/09_Pragmatic_tools.mp3","chapters":[{"chunk_id":"episode-09#c0","idx":0,"start":19,"title":"Вступление: подкаст зафичерил Apple"},{"chunk_id":"episode-09#c1","idx":1,"start":211,"title":"Сила plain text"},{"chunk_id":"episode-09#c2","idx":2,"start":491,"title":"Shell: терминал как вотчина"},{"chunk_id":"episode-09#c3","idx":3,"start":826,"title":"Power editing: чек-лист совершенства"},{"chunk_id":"episode-09#c4","idx":4,"start":1310,"title":"Система контроля версий"},{"chunk_id":"episode-09#c5","idx":5,"start":1492,"title":"Поиск багов: чините проблему, а не виновных"},{"chunk_id":"episode-09#c6","idx":6,"start":1865,"title":"Сначала тест, потом фикс"},{"chunk_id":"episode-09#c7","idx":7,"start":2482,"title":"Управление текстом: awk, sed, Python"},{"chunk_id":"episode-09#c8","idx":8,"start":2622,"title":"Инженерные ежедневники"},{"chunk_id":"episode-09#c9","idx":9,"start":2740,"title":"Полезняшка: A Philosophy of Software Design"}],"date":"2023-01-23","duration_sec":2792,"guests":[],"key_takeaways":["Plain text — самое живучее представление знаний: оно не устаревает вместе с софтом и из коробки дружит со всеми Unix-инструментами и git.","Используйте силу командной строки и сделайте shell своей вотчиной: тема, prompt с git-веткой, алиасы для SSH-серверов, автокомплиты — а fish продуман по UX прямо из коробки.","Добейтесь совершенства во владении редактором: пройдите чек-лист (выделение, навигация, мультикурсор, сортировка строк, поиск по regex) и доводите найденные пробелы до мышечной памяти, исключая «авторепит».","Всегда используйте систему контроля версий — и проведите мысленный эксперимент с пролитым на ноутбук кофе: сколько времени займёт восстановление рабочего окружения?","Дебаггинг — это problem solving, а не поиск виновных: «не имеет значения, чья это была ошибка, — это всё ещё ваша проблема».","Сначала тест, потом фикс: воспроизведённая юнит-тестом бага — это подтверждение находки, доказательство фикса и страховка от регрессии.","Читайте чёртово сообщение об ошибке; «ифы не сломались» — в 99% случаев проблема в вашем коде; а предположения ничего не значат, пока не доказаны тестом или скриптом.","После фикса рефлексируйте: почему о баге не узнали раньше и что изменить (статанализ, новые тесты), чтобы этот класс ошибок больше не доходил до продакшна."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"oh-my-zsh","url":"https://ohmyz.sh"},{"title":"fish shell","url":"https://fishshell.com"},{"title":"Todoist","url":"https://todoist.com"},{"title":"Джон Остерхаут — лекция «A Philosophy of Software Design»","url":"https://www.youtube.com/watch?v=bmSAYlu0NcY"}],"md_url":"https://apkhmv.xyz/podcast/episode-09/index.md","number":9,"season":1,"slug":"episode-09","tags":["Программист-прагматик","инструменты","shell","git","дебаггинг"],"title":"#9: Прагматичные тулы: plain text, git, shell","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-09/"},{"abstract":"Юбилейный десятый выпуск, записанный в студии. Design by contract из «Программиста-прагматика»: предусловия, постусловия и инварианты через тройки Хоара, почему предусловия — не валидация пользовательского ввода, и спор с авторами о том, может ли TDD заменить контракты. Затем — практика: контракты в джавадоке, тесты в структуре given/when/then и ArchUnit — библиотека для тестирования архитектуры, которой Александр зафиксировал инвариант стартап-хуков прямо в build time. Полезняшка — 37signals.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/10_Design_by_contract.mp3","chapters":[{"chunk_id":"episode-10#c0","idx":0,"start":20,"title":"Вступление: юбилейный выпуск из студии"},{"chunk_id":"episode-10#c1","idx":1,"start":62,"title":"Контракты и тройки Хоара"},{"chunk_id":"episode-10#c2","idx":2,"start":197,"title":"Инварианты и где живут контракты"},{"chunk_id":"episode-10#c3","idx":3,"start":319,"title":"TDD против design by contract"},{"chunk_id":"episode-10#c4","idx":4,"start":508,"title":"Контракты в Java: джавадок и ассерты"},{"chunk_id":"episode-10#c5","idx":5,"start":739,"title":"Тесты в стиле given/when/then"},{"chunk_id":"episode-10#c6","idx":6,"start":987,"title":"ArchUnit: тестируем архитектуру"},{"chunk_id":"episode-10#c7","idx":7,"start":1335,"title":"Кейс: инвариант стартап-хуков в build time"},{"chunk_id":"episode-10#c8","idx":8,"start":1698,"title":"Заключение: 37signals"}],"date":"2023-02-06","duration_sec":1770,"guests":[],"key_takeaways":["Design by contract — это предусловия, постусловия и инварианты, формально — тройки Хоара: выполнено предусловие P → команда C исполнима → гарантировано постусловие Q.","Инвариант — условие, соблюдающееся всю жизнь класса: классика — баланс банковского аккаунта не бывает отрицательным.","Предусловия — про коммуникацию классов и команд между собой, а не про валидацию пользовательского ввода: пользователи о контракте ничего не знают.","Авторы считают, что TDD тестирует только happy path и потому не заменяет контракты; Александр не согласен: разбиение входных данных на классы эквивалентности покрывает и нарушения контракта.","В Java встроенных контрактов нет: описывайте их в джавадоке больших публичных классов — DbC прежде всего техника мышления; ассерты в коде громоздки и отключаются флагом.","Структура тестов given/when/then (комментариями) помогает увидеть покрытые предусловия и постусловия — и тиммейты перенимают подход сами, без просьб: лучший знак, что он работает.","ArchUnit цементирует архитектуру юнит-тестами: зависимости между пакетами, слоистая архитектура, аннотации, наследование — выразительный DSL плюс вся сила рефлексии.","Кейс: инвариант «число стартап-хуков равно ожидаемому» проверяется ArchUnit в build time — нарушенный контракт ломает сборку с информативным сообщением, а не падает где-то в рантайме."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"ArchUnit — тестирование архитектуры в Java","url":"https://www.archunit.org"},{"title":"37signals","url":"https://37signals.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-10/index.md","number":10,"season":1,"slug":"episode-10","tags":["Программист-прагматик","design by contract","ArchUnit","тестирование","Java"],"title":"#10: Design by contract: инварианты, Archunit","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-10/"},{"abstract":"Эмоциональный выпуск про первый опыт Александра в роли докладчика на локальном IT-митапе: сорванные тайминги, слабая модерация и девять слушателей на докладе про GraalVM. Из этого — выводы: почему митапу нужна модерация докладов, сколько докладов выдерживает аудитория и когда «сделай сам» — единственный выход. Во второй части — как Александр готовит презентации: белые слайды, минимум текста, интерактивность, и связка iPad + Concepts + Google Slides. Полезняшка — доклад Вадима Макишвили «36».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/11_meetup_keynotes.mp3","chapters":[{"chunk_id":"episode-11#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-11#c1","idx":1,"start":52,"title":"Как я вписался в митап"},{"chunk_id":"episode-11#c2","idx":2,"start":225,"title":"Доклад про GraalVM и спин-офф про DI в CLI"},{"chunk_id":"episode-11#c3","idx":3,"start":384,"title":"Как всё прошло: тайминги и модерация"},{"chunk_id":"episode-11#c4","idx":4,"start":609,"title":"Единственный хороший доклад"},{"chunk_id":"episode-11#c5","idx":5,"start":735,"title":"Мой доклад для девяти человек"},{"chunk_id":"episode-11#c6","idx":6,"start":899,"title":"Выводы: модерация, лимит докладов, «сделай сам»"},{"chunk_id":"episode-11#c7","idx":7,"start":1307,"title":"Какой я вижу хорошую презентацию"},{"chunk_id":"episode-11#c8","idx":8,"start":1757,"title":"Инструменты: iPad, Concepts, Google Slides"},{"chunk_id":"episode-11#c9","idx":9,"start":2101,"title":"Полезняшка: «36» Вадима Макишвили"}],"date":"2023-02-20","duration_sec":2147,"guests":[],"key_takeaways":["Не все митапы стоят внимания докладчика: коммитьтесь, только если знаете организаторов лично или проверили их прошлые мероприятия — зритель может уйти, докладчик заложник до конца.","Митап без модерации докладов — ошибка: непросмотренные доклады съедают время зрителей и размывают качество всего мероприятия.","Три-четыре доклада — потолок: дальше аудитория устаёт и расходится (из ~50 человек до седьмого доклада дожили девять).","Попутное открытие: DI-фреймворки задизайнены под серверы — в CLI-приложении Micronaut утроил время старта (400 мс → 1,5 с); для command-line лучше обойтись без DI.","Хороший доклад начинается с вопроса «зачем и для кого» — если ценности для аудитории нет, идею доклада стоит отмести ещё до слайдов.","Слайды вторичны и дополняют речь: белый фон, крупный шрифт, минимум текста, выводы появляются по одному — это управление вниманием зрителя.","Тайминги — уважение к другим докладчикам: 30 минут — идеальная длина, и обязателен хотя бы один прогон живому человеку.","Связка iPad + Concepts + Google Slides: фиксированная зона экспорта в Concepts даёт «дорисовывающиеся» от слайда к слайду схемы без прыжков картинки."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Concepts — приложение для скетчей и диаграмм","url":"https://concepts.app"},{"title":"Вадим Макишвили — доклад «36»","url":"https://www.youtube.com/watch?v=FxljIvLxUqQ"}],"md_url":"https://apkhmv.xyz/podcast/episode-11/index.md","number":11,"season":1,"slug":"episode-11","tags":["митапы","публичные выступления","презентации","GraalVM","сообщество"],"title":"#11: Горе-митап: опыт выступления, презентации","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-11/"},{"abstract":"Связность — враг изменений: по мотивам «Программиста-прагматика» Александр разбирает признаки высокого каплинга и способы его снижать — от инкапсуляции и отказа от глобального стейта до недооцененных конечных автоматов, observer-паттерна и pub-sub с реактивным программированием. Кульминация — «налог на наследование»: почему наследование классов — самый сильный способ связать код намертво и чем его заменить: интерфейсы, делегирование и миксины (даже в Java — через аннотации, как @Mixin в Picocli). Полезняшка — канал «500 дней геймдева».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/12_Inheritance_tax.mp3","chapters":[{"chunk_id":"episode-12#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-12#c1","idx":1,"start":49,"title":"Связность — враг изменений"},{"chunk_id":"episode-12#c2","idx":2,"start":128,"title":"Знаки высокой связанности"},{"chunk_id":"episode-12#c3","idx":3,"start":206,"title":"Инкапсуляция и глобальный стейт"},{"chunk_id":"episode-12#c4","idx":4,"start":400,"title":"Конечные автоматы"},{"chunk_id":"episode-12#c5","idx":5,"start":674,"title":"Observer и pub-sub: реактивщина"},{"chunk_id":"episode-12#c6","idx":6,"start":882,"title":"Transformation thinking"},{"chunk_id":"episode-12#c7","idx":7,"start":982,"title":"Налог на наследование"},{"chunk_id":"episode-12#c8","idx":8,"start":1362,"title":"Альтернативы: интерфейсы, делегирование, миксины"},{"chunk_id":"episode-12#c9","idx":9,"start":1696,"title":"Полезняшка: «500 дней геймдева»"}],"date":"2023-03-06","duration_sec":1763,"guests":[],"key_takeaways":["Связность — враг изменений: искусство инженерии не в том, чтобы написать работающий код (это сделает и нейросеть, и базовый джун), а в том, чтобы его потом было легко менять.","Знаки высокого каплинга: неочевидные зависимости между модулями, изменения расползаются по кодовой базе, разработчики боятся трогать код, а фичи согласуются митингами на много команд.","База декаплинга: инкапсулируйте стейт внутри объектов; глобальная переменная — это лишний параметр, добавленный каждому методу кодовой базы; синглтон — «паттерн-антипаттерн».","Конечные автоматы недооценены: состояния, ивенты и экшены разделены by design, система получается open-closed — и это тот случай, когда стоит написать свою простую реализацию, а не искать библиотеку.","Observer-паттерн прост, но синхронен и хрупок (упавший обзервер рвёт цепочку); pub-sub добавляет каналы и развязывает источники и слушателей — это и есть реактивное программирование: идеально для UI, на бэкенде — по необходимости.","Наследование классов — самый сильный способ увеличить связность: наследуются методы, данные и API, и контракт родителя железобетонно сковывает наследника (поменяли getPower у vehicle — рефакторишь весь код, использующий car).","Альтернативы: интерфейсы для типизации и контрактов, делегирование (композиция) для переиспользования кода, миксины/трейты для подмешивания поведения.","Базовый класс в тестах — то же наследование с теми же проблемами: extensions в JUnit 5 решают задачу чище."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"ReactiveX — language-agnostic спецификация реактивного программирования","url":"https://reactivex.io"}],"md_url":"https://apkhmv.xyz/podcast/episode-12/index.md","number":12,"season":1,"slug":"episode-12","tags":["Программист-прагматик","наследование","конечные автоматы","проектирование","Java"],"title":"#12: Налог на наследование: конечные автоматы","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-12/"},{"abstract":"Любимый паттерн Александра — Builder: закрытый конструктор, immutable-объекты, валидации в сеттерах, именованные параметры, которых нет в Java, тестовые фикстуры — и как он пишет билдеры руками, без Lombok (а Copilot их отлично генерирует). Во второй части по мотивам «Программиста-прагматика» — конкурентность: чем она отличается от параллелизма, почему shared state is hard, как устроена модель акторов и почему её современное воплощение — микросервисы с Kafka-«мейлбоксом» и Kubernetes-«супервайзером». Полезняшки — плейлист про устройство баз данных и фичи новой Java.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/13_Builder.mp3","chapters":[{"chunk_id":"episode-13#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-13#c1","idx":1,"start":47,"title":"Паттерн Builder: что это"},{"chunk_id":"episode-13#c2","idx":2,"start":168,"title":"Плюсы: immutable, контроль, именованные параметры"},{"chunk_id":"episode-13#c3","idx":3,"start":445,"title":"Этапы создания и тестовые фикстуры"},{"chunk_id":"episode-13#c4","idx":4,"start":633,"title":"Как я пишу билдеры"},{"chunk_id":"episode-13#c5","idx":5,"start":818,"title":"Когда билдер не нужен"},{"chunk_id":"episode-13#c6","idx":6,"start":929,"title":"«Лишний код» и Copilot"},{"chunk_id":"episode-13#c7","idx":7,"start":1094,"title":"Конкурентность ≠ параллелизм"},{"chunk_id":"episode-13#c8","idx":8,"start":1315,"title":"Shared state is hard"},{"chunk_id":"episode-13#c9","idx":9,"start":1572,"title":"Модель акторов"},{"chunk_id":"episode-13#c10","idx":10,"start":1856,"title":"Микросервисы как актёры"},{"chunk_id":"episode-13#c11","idx":11,"start":2094,"title":"Полезняшки: базы данных и новая Java"}],"date":"2023-03-20","duration_sec":2163,"guests":[],"key_takeaways":["Builder — один из самых полезных паттернов в современной Java: закрытый конструктор плюс билдер-компаньон дают immutable-объекты, корректные по построению.","Билдер привносит в Java именованные параметры: вместо конструктора из одиннадцати null'ов — читаемые сеттеры, понятные и на ревью без подсветки IDE.","Валидации живут в сеттерах билдера: каждая проверка рядом со своим полем, тестируется отдельно — и если объект существует, он гарантированно провалидирован.","Билдер — не для всего: сервисы и контроллеры создаёт DI-фреймворк, а стихия билдера — дата-классы (Person, Configuration, Address) и тестовые фикстуры, достраиваемые в каждом тесте.","«Лишний код» — слабый контраргумент: написание билдера заставляет заранее продумать дефолты и инварианты объекта, а Copilot генерирует такой код почти без ошибок.","Конкурентность — выполнение кода «как будто параллельно», параллелизм — реально параллельно; любой поход по сети, в базу или файловую систему — кандидат на асинхронность.","Shared state is hard: гонки данных, дедлоки, а мьютекс — устная договорённость, которую компилятор не проверяет; предпочитайте узкие примитивы (атомики с CAS, CountDownLatch) широким блокировкам.","Модель акторов изящна и скейлится (Erlang), но её современное воплощение — микросервисы: Kafka как мейлбокс, Kubernetes как супервайзер; используйте там, где польза очевидна, а начинайте со здравого монолита."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"JDK 20 — список фичей релиза","url":"https://openjdk.org/projects/jdk/20/"},{"title":"JDK 21 (LTS) — план релиза","url":"https://openjdk.org/projects/jdk/21/"},{"title":"CMU Database Group — лекции об устройстве баз данных","url":"https://www.youtube.com/@CMUDatabaseGroup"}],"md_url":"https://apkhmv.xyz/podcast/episode-13/index.md","number":13,"season":1,"slug":"episode-13","tags":["паттерны","Java","конкурентность","модель акторов","Программист-прагматик"],"title":"#13: Любимый паттерн: Builder, Concurrency, Actors","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-13/"},{"abstract":"Взгляд прагматичного инженера на GPT-хайп весны 2023-го: как Александр реально использует ChatGPT в ежедневной работе — пишет гуглдоки и джира-тикеты «потоком сознания» с нативной редактурой, почему Copilot в коде чаще мешает, чем помогает, но отлично пишет JavaDoc и подсказывает забытые тест-кейсы. Плюс Copilot CLI, плагины ChatGPT через OpenAPI-спеку и проверенная руками (и отложенная) идея пайплайна Whisper → ChatGPT → телеграм-посты из выпусков подкаста. Полезняшка — браузер Arc.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/ChatGPT_Copilot.mp3","chapters":[{"chunk_id":"episode-14#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-14#c1","idx":1,"start":32,"title":"Хайп против прагматичного взгляда"},{"chunk_id":"episode-14#c2","idx":2,"start":96,"title":"Как работают генеративные модели"},{"chunk_id":"episode-14#c3","idx":3,"start":212,"title":"Юзкейс 1: гуглдоки"},{"chunk_id":"episode-14#c4","idx":4,"start":453,"title":"Юзкейс 2: джира-тикеты"},{"chunk_id":"episode-14#c5","idx":5,"start":541,"title":"Copilot: помощь или помеха"},{"chunk_id":"episode-14#c6","idx":6,"start":656,"title":"Где Copilot хорош: JavaDoc и тесты"},{"chunk_id":"episode-14#c7","idx":7,"start":832,"title":"Copilot CLI и плагины ChatGPT"},{"chunk_id":"episode-14#c8","idx":8,"start":1026,"title":"Пэт-проект: Whisper + ChatGPT для подкаста"},{"chunk_id":"episode-14#c9","idx":9,"start":1296,"title":"Выводы: пользуйтесь по назначению"},{"chunk_id":"episode-14#c10","idx":10,"start":1411,"title":"Полезняшка: браузер Arc"}],"date":"2023-04-04","duration_sec":1467,"guests":[],"key_takeaways":["Смотрите на GPT-хайп как инженер: это генеративная лингвистическая модель — «генератор следующего слова», и именно из этого понимания рождаются рабочие юзкейсы.","Главный юзкейс — тексты: пишешь поток сознания на «своём» английском, ChatGPT с коротким контекст-промптом переписывает нативно; остаётся ~5% редактуры — так пишутся гуглдоки и джира-тикеты.","Copilot в коде чаще мешает: ложных срабатываний сильно больше полезных, проверка предложений съедает внимание, а сгенерированный код порой даже не компилируется — «сынок, хочешь помочь — не мешай».","Зато Copilot отлично пишет JavaDoc для публичного API (текст, а не код) и подсказывает забытые тест-кейсы — null, минус один и прочие краевые случаи.","Плагины ChatGPT интегрируются через OpenAPI-спецификацию — ещё одна причина писать спеки для своих сервисов.","Идею «Whisper → текст подкаста → ChatGPT → телеграм-посты» Александр проверил руками за полчаса вместо недель имплементации: модель не вытянула объём текста — идея спокойно отложена. Сначала проверка гипотезы, потом инженерия.","Ожидайте стабилизации и специализации инструментов — например, умный автокомплит в терминале, продолжающий команды «серым», как fish suggestions.","Бояться «потерять скилл» из-за инструментов — путь в никуда: пользуйтесь технологиями по назначению."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"OpenAI Whisper","url":"https://github.com/openai/whisper"},{"title":"DeepL — переводчик","url":"https://www.deepl.com"},{"title":"GitHub Copilot","url":"https://github.com/features/copilot"},{"title":"Браузер Arc","url":"https://arc.net"}],"md_url":"https://apkhmv.xyz/podcast/episode-14/index.md","number":14,"season":1,"slug":"episode-14","tags":["ChatGPT","Copilot","AI","инструменты","продуктивность"],"title":"#14: Используем технологии по назначению","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-14/"},{"abstract":"Глава «While You Are Coding» из «Программиста-прагматика» глазами Александра: как победить боязнь белого листа прототипом-игрой, почему нельзя коммитить код, который не понимаешь (история с незадокументированным бином Spring Shell), «мышление графиками» вместо зубрёжки О-большого, атомарный рефакторинг с точки зрения свежеиспечённого коммитера Apache-проекта, TDD без карго-культа, property-based testing для проверки инвариантов и капитанские, но забываемые правила security. И хохма про Fib.nth, давшая выпуску имя.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/15_Fib.nth_2.mp3","chapters":[{"chunk_id":"episode-15#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-15#c1","idx":1,"start":129,"title":"Боязнь белого листа"},{"chunk_id":"episode-15#c2","idx":2,"start":309,"title":"Programming by coincidence"},{"chunk_id":"episode-15#c3","idx":3,"start":576,"title":"Осознанное программирование"},{"chunk_id":"episode-15#c4","idx":4,"start":790,"title":"Алгоритмы и мышление графиками"},{"chunk_id":"episode-15#c5","idx":5,"start":1138,"title":"Рефакторинг: атомарные изменения"},{"chunk_id":"episode-15#c6","idx":6,"start":1387,"title":"TDD без карго-культа"},{"chunk_id":"episode-15#c7","idx":7,"start":1702,"title":"Property-based testing"},{"chunk_id":"episode-15#c8","idx":8,"start":1973,"title":"Security: stay safe out there"},{"chunk_id":"episode-15#c9","idx":9,"start":2320,"title":"Fib.nth: хохма про именование"},{"chunk_id":"episode-15#c10","idx":10,"start":2490,"title":"Заключение"}],"date":"2023-04-18","duration_sec":2539,"guests":[],"key_takeaways":["Против боязни белого листа: начните с «прототипа-игры» без ответственности, получите end-to-end эффект — а потом сотрите всё и пишите нормальный продакшн-код.","Не коммитьте код, который не понимаете: «работает» на ваших данных — ещё не значит работает; обход контракта библиотеки (незадокументированный бин Spring Shell) рано или поздно ломается мажорным обновлением.","Документируйте вынужденные хаки максимально подробно — это тот случай, когда комментарии в коде необходимы, — и тестируйте сами предположения: assumeThat в JUnit 5 скипает тест, а не валит его.","О-большое — это «мышление графиками»: представьте кривую — и понятно, как время растёт от размера входа; лучший в теории алгоритм на маленьких данных может проигрывать простому линейному.","Рефакторинг — регулярная практика, но атомарная: не мешайте его с фичами в одном pull request — оставьте TODO со слинкованным джира-тикетом; ревьюеры скажут спасибо.","Тест, дизайн и кодинг — всё это программирование: оценивать имплементацию без тестов бессмысленно; а 100% покрытие — вообще не про TDD, это просто метрика.","Property-based testing проверяет инварианты (вероятность всегда от 0 до 1) на сотнях сгенерированных входов и находит кейсы, о которых вы не подумали.","Security капитанская, но забываемая: входные И выходные данные — векторы атаки («такой пароль уже используется» — подарок брутфорсеру), а аутентификация отсекает DoS-запросы до базы данных."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«The Pragmatic Programmer», 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"«Cracking the Coding Interview»","url":"https://www.crackingthecodinginterview.com"},{"title":"LeetCode","url":"https://leetcode.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-15/index.md","number":15,"season":1,"slug":"episode-15","tags":["Программист-прагматик","тестирование","алгоритмы","рефакторинг","безопасность"],"title":"#15: Fib.nth: о чем не думают инженеры","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-15/"},{"abstract":"Первый «спэшл» — короткий тематический выпуск между основными. Александр разбирает модель управления доступом Role-Based Access Control (RBAC): три её кита (пользователи, роли, привилегии), надстройки в виде иерархии ролей и ограничений (разделение обязанностей и лимиты на назначение ролей), а затем на пальцах сравнивает реализации в Postgres (где путаются пользователи и роли) и ClickHouse (с хорошей иерархией привилегий, но возможностью выдавать их и пользователям напрямую — что ломает каноническую модель).","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/16_.mp3","chapters":[{"chunk_id":"episode-16#c0","idx":0,"start":18,"title":"Вступление: новый формат «спэшл»"},{"chunk_id":"episode-16#c1","idx":1,"start":81,"title":"Что такое RBAC"},{"chunk_id":"episode-16#c2","idx":2,"start":162,"title":"Три кита: пользователи, роли, привилегии"},{"chunk_id":"episode-16#c3","idx":3,"start":259,"title":"Пример: GRANT и контроль на уровне ролей"},{"chunk_id":"episode-16#c4","idx":4,"start":366,"title":"flat RBAC и иерархия ролей"},{"chunk_id":"episode-16#c5","idx":5,"start":418,"title":"Ограничения: разделение обязанностей и лимиты"},{"chunk_id":"episode-16#c6","idx":6,"start":517,"title":"RBAC в СУБД: критерии и NIST"},{"chunk_id":"episode-16#c7","idx":7,"start":561,"title":"Postgres: путаница пользователей и ролей"},{"chunk_id":"episode-16#c8","idx":8,"start":650,"title":"ClickHouse: иерархия привилегий и её изъян"},{"chunk_id":"episode-16#c9","idx":9,"start":758,"title":"Итог"}],"date":"2023-04-20","duration_sec":792,"guests":[],"key_takeaways":["RBAC строится на трёх сущностях — пользователи, роли, привилегии — и двух связях: «роль — привилегия» (permission assignment) и «пользователь — роль» (role assignment).","Главное преимущество RBAC — контроль доступа на уровне ролей: право выдаётся и отзывается один раз у роли, а не у каждого пользователя; один `REVOKE` на роль закрывает доступ всем её носителям.","Плоская модель (flat RBAC) расширяется иерархией: роли наследуют друг друга, поэтому вместо назначения нескольких ролей одному пользователю заводят агрегирующую роль (например, `Manager`).","Ограничения (constrained RBAC) дают разделение обязанностей — например, запрет совмещать роли `Admin` и `QA` у одного пользователя.","Ограничением может быть любой предикат, включая лимит на число носителей роли: если самую мощную роль разрешено выдать лишь двоим, при взломе злоумышленник не сможет её присвоить.","Ориентир «правильного» RBAC — модель из статей NIST (с 1996 года): реализация должна быть простой и не добавлять того, чего в стандарте нет.","В Postgres нет чёткого разделения пользователей и ролей (роль с `LOGIN`/`NOLOGIN`, `CREATE ROLE` в SQL против `createuser` в shell) — понятия смешиваются, хотя в остальном система гибкая, вплоть до row-level security.","ClickHouse хорошо иерархирует привилегии (`ALTER` → `ALTER TABLE` → `ALTER COLUMN` → …), но позволяет назначать привилегии и ролям, и пользователям напрямую — что нарушает каноническую RBAC-модель."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"NIST RBAC — модель управления доступом на основе ролей","url":"https://csrc.nist.gov/projects/role-based-access-control"},{"title":"ClickHouse — управление доступом и привилегии","url":"https://clickhouse.com/docs/en/operations/access-rights"},{"title":"PostgreSQL — роли базы данных","url":"https://www.postgresql.org/docs/current/user-manag.html"}],"md_url":"https://apkhmv.xyz/podcast/episode-16/index.md","number":16,"season":1,"slug":"episode-16","tags":["RBAC","контроль доступа","базы данных","безопасность","ClickHouse"],"title":"#16: Спэшл: RBAC","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-16/"},{"abstract":"Выпуск по мотивам книги «Программист-прагматик». Александр Пахомов доказывает, что требования нужны в первую очередь самим разработчикам — чтобы уточнить, чего на самом деле хочет заказчик, и не писать лишний код, — и разводит требования с бизнес-политиками, которые нельзя зашивать в хардкод. Затем он разбирает приёмы решения запутанных задач (сузить проблему, загрузить данные в подсознание, найти «уточку»), делится своим взглядом на парное программирование и живое общение против асинхронного, а под конец разоблачает agile-коучей и спорит с культом спринтов.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/17_Requirements.mp3","chapters":[{"chunk_id":"episode-17#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-17#c1","idx":1,"start":51,"title":"Что такое требования и откуда страх перед ними"},{"chunk_id":"episode-17#c2","idx":2,"start":201,"title":"Зачем требования нужны разработчику"},{"chunk_id":"episode-17#c3","idx":3,"start":237,"title":"Пример: бесплатная доставка от 50 долларов"},{"chunk_id":"episode-17#c4","idx":4,"start":412,"title":"В каком виде представлять требования"},{"chunk_id":"episode-17#c5","idx":5,"start":495,"title":"user story и уточнение деталей"},{"chunk_id":"episode-17#c6","idx":6,"start":581,"title":"Требования против политик и словарь терминов"},{"chunk_id":"episode-17#c7","idx":7,"start":744,"title":"Решение запутанных задач: советы из книги"},{"chunk_id":"episode-17#c8","idx":8,"start":1255,"title":"Парное программирование и живое общение"},{"chunk_id":"episode-17#c9","idx":9,"start":1787,"title":"Разоблачение agile-коучей и культ спринтов"},{"chunk_id":"episode-17#c10","idx":10,"start":2157,"title":"Итог и полезняшка: Java Swag"}],"date":"2023-05-01","duration_sec":2219,"guests":[],"key_takeaways":["Требования нужны прежде всего разработчику: чтобы задать направление и не писать код, который не нужен или который придётся переделывать, — а не как спущенный сверху документ на исполнение.","Никто не знает на 100%, чего хочет; задача инженера — вопросами вытащить детали и корнер-кейсы из заказчика, а иногда и отговорить от фичи, ведь ненаписанный код — лучший код.","Требования разрабатываются в диалоге из верхнеуровневой `user story`: заказчика волнует результат, а низкоуровневые детали — забота разработчиков.","Требования (`requirements`) нужно отличать от политик (бизнес-правил вроде размера скидки): политики со временем меняются, поэтому их выносят в метаданные, конфиги или админку, а не зашивают в хардкод.","В документе с требованиями полезен словарь терминов: если `customer`, `client` и `user` означают разное, это стоит зафиксировать с примерами, чтобы не искажать смысл.","Озарение при решении сложной задачи не приходит из ниоткуда — подсознанию нужно скормить много сырых данных, фактов и экспериментов; параллельно проблему сужают и по возможности воспроизводят тестом.","Из парного программирования полезно брать совместное исследование кода вдвоём и обсуждение документа голосом в онлайне — так получаешь более включённый фидбэк, чем от асинхронной пересылки.","Agile — это про гибкость и ценности из манифеста (люди важнее процессов, работающий код важнее документации), а не про навязанные тулы и спринты; коуч, который насаждает процессы, agile как раз не понимает."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«Программист-прагматик» (The Pragmatic Programmer)","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"Manifesto for Agile Software Development","url":"https://agilemanifesto.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-17/index.md","number":17,"season":1,"slug":"episode-17","tags":["требования к ПО","парное программирование","Agile","софт-скиллы","решение задач"],"title":"#17: Гибкие требования: парное программирование, Agile","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-17/"},{"abstract":"Спэшл-выпуск «положение дел»: Александр рассказывает, что подкаст не заканчивается, а он расширяет территорию — выходит на YouTube (первый видос будет про сам подкаст) и присматривается к TikTok. Большая часть выпуска — подробный дневник погружения дилетанта в видеопроизводство: камера Sony A7 III, микрофон, свет как самая важная часть кадра (схема из трёх источников: ключевой, контровый, подсветка фона), монтаж в DaVinci Resolve вместо тормозящего iMovie, музыка и авторские права, а также генерация обложек через Midjourney с промтами от GPT-4.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/18_.mp3","chapters":[{"chunk_id":"episode-18#c0","idx":0,"start":17,"title":"Вступление: расширение территории"},{"chunk_id":"episode-18#c1","idx":1,"start":59,"title":"YouTube и первый видос — про подкаст"},{"chunk_id":"episode-18#c2","idx":2,"start":122,"title":"Как я подхожу к новой сфере"},{"chunk_id":"episode-18#c3","idx":3,"start":214,"title":"Камера: Sony A7 III"},{"chunk_id":"episode-18#c4","idx":4,"start":311,"title":"Микрофон: почему подкастерский не подходит"},{"chunk_id":"episode-18#c5","idx":5,"start":394,"title":"Свет — самое важное в кадре"},{"chunk_id":"episode-18#c6","idx":6,"start":732,"title":"Сценарий и подход к монтажу"},{"chunk_id":"episode-18#c7","idx":7,"start":861,"title":"DaVinci Resolve против iMovie"},{"chunk_id":"episode-18#c8","idx":8,"start":1169,"title":"Генерация картинок: Midjourney и GPT-4"},{"chunk_id":"episode-18#c9","idx":9,"start":1375,"title":"TikTok как ещё одна платформа"},{"chunk_id":"episode-18#c10","idx":10,"start":1503,"title":"Итог: положение дел"}],"date":"2023-05-04","duration_sec":1561,"guests":[],"key_takeaways":["Подкаст остаётся основным форматом (раз в две недели плюс спонтанные спэшлы), но параллельно запускается YouTube-канал, а первый ролик будет как раз про подкаст и его влияние на автора.","Для видео важнее хорошего оборудования грамотный свет: приличной камеры (или даже настроенного телефона) достаточно, потому что вся оптика по сути поглощает свет, а дешёвые офисные лампы дают низкий индекс цветопередачи и стробят.","Классическая схема освещения — три источника: ключевой светит на лицо под ~45° и чуть сверху для мягкого контраста, контровый бьёт сзади в затылок и отделяет «говорящую голову» от фона, третий цветом подсвечивает бэкграунд.","Белый подкастерский микрофон `Rode Podcaster` не годится для видео: он остаётся в кадре (нужен на расстоянии кулака) и бликует под светом, поэтому для съёмки нужен чёрный микрофон.","`DaVinci Resolve` — оптимальный редактор для старта: есть бесплатная версия, а `iMovie` начинает фризиться и тупить на длинных роликах (например, при монтаже 4K-видео с iPhone).","Обучаться ремеслу стоит через погружение в среду профессионалов: автор изучал монтаж по плейлистам канала «Хохлов Сабатовский» и смотрел стримы «Гарик Тарано» про Sony и свет.","Обложки к выпускам удобно генерировать нейросетью: `Midjourney` рисует картинку, а `GPT-4` превращает описание на обычном языке в качественный промт для неё.","На чужую музыку в видео на YouTube действуют авторские права: за трек правообладателя грозит страйк или принудительный шеринг монетизации, поэтому автор берёт биты у знакомого битмейкера и принципиально считает воровство недопустимым."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"DaVinci Resolve — редактор видео (Blackmagic Design)","url":"https://www.blackmagicdesign.com/products/davinciresolve"},{"title":"Хохлов Сабатовский — YouTube-канал про монтаж и DaVinci Resolve","url":"https://www.youtube.com/@khs_yt"},{"title":"Гарик Тарано — YouTube-канал про съёмку, Sony и свет","url":"https://www.youtube.com/channel/UC3XJcYENqqGmJhgXeL0TUmQ"},{"title":"Midjourney — генерация изображений нейросетью","url":"https://www.midjourney.com"},{"title":"ChatGPT / GPT-4 (OpenAI)","url":"https://chat.openai.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-18/index.md","number":18,"season":1,"slug":"episode-18","tags":["подкастинг","YouTube","видеопроизводство","монтаж видео","нейросети"],"title":"#18: Спэшл: положение дел, YouTube","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-18/"},{"abstract":"Сольный выпуск по мотивам «Программиста-прагматика». Александр Пахомов размышляет об оптимальном размере команды (5–7 человек) и о пользе функциональных команд, способных выдавать end-to-end результат, разбирает происхождение термина «карго-культ» и его проявления в скраме, а затем формулирует три практики из Pragmatic Starter Kit, которые должны быть в любом проекте: система контроля версий, тестирование и полная автоматизация. В финале — идея, что инженер прежде всего problem solver, призыв «подписывать свою работу» и наводка на YouTube-канал Computerphile.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/19_Small_Teams.mp3","chapters":[{"chunk_id":"episode-19#c0","idx":0,"start":20,"title":"Вступление и постановка тем"},{"chunk_id":"episode-19#c1","idx":1,"start":53,"title":"Оптимальный размер команды"},{"chunk_id":"episode-19#c2","idx":2,"start":176,"title":"Функциональные команды и трассирующий выстрел"},{"chunk_id":"episode-19#c3","idx":3,"start":483,"title":"Айдентика команды: имена и символы"},{"chunk_id":"episode-19#c4","idx":4,"start":621,"title":"Карго-культ: происхождение термина"},{"chunk_id":"episode-19#c5","idx":5,"start":720,"title":"Карго-культ в разработке и критическое мышление"},{"chunk_id":"episode-19#c6","idx":6,"start":875,"title":"Pragmatic Starter Kit и система контроля версий"},{"chunk_id":"episode-19#c7","idx":7,"start":993,"title":"Тестирование и регрессионное тестирование"},{"chunk_id":"episode-19#c8","idx":8,"start":1053,"title":"Тестирование тестов и мутационное тестирование"},{"chunk_id":"episode-19#c9","idx":9,"start":1299,"title":"Автоматизация и CI/CD как источник кайфа"},{"chunk_id":"episode-19#c10","idx":10,"start":1618,"title":"Инженер как problem solver"},{"chunk_id":"episode-19#c11","idx":11,"start":1757,"title":"Sign your work и open source"},{"chunk_id":"episode-19#c12","idx":12,"start":1939,"title":"Полезняшка: канал Computerphile"}],"date":"2023-05-16","duration_sec":2034,"guests":[],"key_takeaways":["Оптимальный размер команды — примерно 5–7 человек: столько контекстов реально удержать в голове, а сверх этого команда превращается в набор людей под общим названием.","Команда эффективнее всего, когда способна выдать end-to-end результат («трассирующий выстрел») — неполную, но работающую фичу, по которой сразу видно, туда ли идёт разработка.","Функциональная команда (бэкенд, фронтенд, мобилка в одном юните) минимизирует межкомандные зависимости; при разделении по слоям координация двух команд усложняет доставку.","Не нужно копировать процессы Netflix или Spotify (трайбы, гильдии): вы не они — практику надо выбирать под свой контекст и проверять экспериментом, а не по карго-культу.","Карго-культ — из реального «культа даров небесных» в Меланезии: островитяне строили аэродромы из соломы, копируя форму без понимания причин; так же слепое следование ритуалам скрама имитирует форму без результата.","Три обязательные практики любого проекта (Pragmatic Starter Kit): система контроля версий, регрессионное тестирование и полная автоматизация (CI/CD).","Тесты надо проверять: хороший тест обязан ловить баги, поэтому в код вносят багу и смотрят, что тест перешёл из красного в зелёный (как в TDD); мутационное тестирование автоматизирует это, разворачивая условия в `source code`.","Инженер — это problem solver, а не «кодер»: он доставляет value кодом, конфигом, ресёрчем или `kill -9`, а способ решения — деталь имплементации; свою работу стоит «подписывать»."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"The Pragmatic Programmer — Andrew Hunt, David Thomas","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"},{"title":"Computerphile — YouTube-канал","url":"https://www.youtube.com/user/Computerphile"},{"title":"Testcontainers для Java","url":"https://java.testcontainers.org"},{"title":"progressbar — библиотека прогресс-баров для терминала на Java","url":"https://github.com/ctongfei/progressbar"}],"md_url":"https://apkhmv.xyz/podcast/episode-19/index.md","number":19,"season":1,"slug":"episode-19","tags":["размер команды","карго-культ","тестирование","CI/CD","командные процессы"],"title":"#19: Выдал базу: три важнейших вещи в разработке","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-19/"},{"abstract":"Юбилейный двадцатый выпуск без гостей. Александр Пахомов рассказывает про свой магистерский диплом — «мертворождённый» инструмент, который генетическим алгоритмом писал бы юнит-тесты на Java-код. По пути он даёт вводную в теорию тестирования (классы эквивалентности, критерии покрытия от строк до MC/DC, мутационное тестирование, фазинг и Search-Based Software Testing), разбирает устройство абстрактного генетического алгоритма и объясняет, как он спроецировал его понятия — популяцию, гены, функцию приспособленности, мутацию и скрещивание — на генерацию тестов, а в конце признаёт, что как продукт затею убил Copilot.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/20_Genetic_algorithms.mp3","chapters":[{"chunk_id":"episode-20#c0","idx":0,"start":20,"title":"Вступление: юбилейный 20-й выпуск"},{"chunk_id":"episode-20#c1","idx":1,"start":66,"title":"Идея диплома: тесты для legacy-кода"},{"chunk_id":"episode-20#c2","idx":2,"start":365,"title":"Как я писал диплом: LaTeX, GitHub, без научрука"},{"chunk_id":"episode-20#c3","idx":3,"start":637,"title":"Теория тестирования: классы эквивалентности"},{"chunk_id":"episode-20#c4","idx":4,"start":908,"title":"Структурное тестирование и критерии покрытия"},{"chunk_id":"episode-20#c5","idx":5,"start":1191,"title":"MC/DC: только значимые тесты"},{"chunk_id":"episode-20#c6","idx":6,"start":1350,"title":"Тестирование с помощью ИИ: мутации и фазинг"},{"chunk_id":"episode-20#c7","idx":7,"start":1514,"title":"Search-Based Software Testing"},{"chunk_id":"episode-20#c8","idx":8,"start":1592,"title":"Как устроен генетический алгоритм"},{"chunk_id":"episode-20#c9","idx":9,"start":1853,"title":"Генетический алгоритм для генерации Java-тестов"},{"chunk_id":"episode-20#c10","idx":10,"start":2321,"title":"Выводы: стоило ли оно того, и олдскульная полезняшка"}],"date":"2023-05-29","duration_sec":2629,"guests":[],"key_takeaways":["Search-Based Software Testing сводит генерацию тестов к задаче оптимизации: тесты генерируются и уточняются, пока критерий покрытия не достигнет 100% или не выйдет тайм-аут.","Класс эквивалентности — это подмножество входных данных, приводящих к одному и тому же пути исполнения кода; для тест-кейсов берут по одному представителю из каждого класса плюс значения на границах.","Покрытие строк (line coverage) считать легче всего, но оно ломается при рефакторинге (тернарник → `if/else`); покрытие ветвлений и условий адекватнее, но требует экспоненциально больше входных данных.","Критерий MC/DC оставляет только значимые тесты: каждый следующий кейс меняет ровно один входной параметр так, чтобы поменялся результат, — генерация останавливается, когда такого изменения больше не найти.","Мутационное тестирование проверяет качество тестов, внося мелкие мутации в исходный код (например, меняя знак сравнения): если тест не «падает» на мутанте, он плохой.","В генетическом алгоритме мутация нужна, чтобы вырваться из локального максимума: без случайных изменений генов популяция застревает и никогда не достигает глобального оптимума.","При проекции генетического алгоритма на тесты особь — это тестовый класс, гены — его методы, помеченные `@Test`, а функция приспособленности — достигнутое тестами покрытие кода.","Как продукт идею убил Copilot: генетический алгоритм — «долгая фигня», а генеративные модели пишут тесты быстрее; как исследовательский проект диплом прокачал навык ресёрча и не был потрачен зря."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Kent Beck — Test-Driven Development: By Example","url":"https://www.oreilly.com/library/view/test-driven-development/0321146530/"},{"title":"The Fuzzing Book — интерактивный учебник по фазингу и генерации тестов","url":"https://www.fuzzingbook.org/"},{"title":"jqwik — property-based testing для JVM","url":"https://jqwik.net/"},{"title":"Testcontainers (AtomicJar)","url":"https://testcontainers.com/"},{"title":"Максим Ильяхов, Людмила Сарычева — «Пиши, сокращай»","url":"https://sokratil.ru/"},{"title":"LanguageTool — проверка орфографии и грамматики","url":"https://languagetool.org/"},{"title":"Алексей Шипилёв — «Fork/Join» (доклад, JEEConf 2012)","url":"https://shipilev.net/talks/jeeconf-May2012-forkjoin.pdf"}],"md_url":"https://apkhmv.xyz/podcast/episode-20/index.md","number":20,"season":1,"slug":"episode-20","tags":["генетические алгоритмы","тестирование","генерация тестов","покрытие кода","дипломная работа"],"title":"#20: Выживает сильнейший: генетические алгоритмы","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-20/"},{"abstract":"Первый выпуск второго сезона, посвящённого базам данных. Александр Пахомов объясняет, почему глубокое, а не поверхностное понимание баз данных важнее знания конкретного языка, фреймворка или СУБД, прослеживает историю от реляционных систем 70-х через NoSQL и NewSQL до облачных и shared-disk-решений, а затем освежает ключевые концепции SQL: `SELECT`/`WHERE`, агрегаты, `GROUP BY`/`HAVING`, `JOIN`, оконные функции и common table expressions.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/21_into_into_databases.mp3","chapters":[{"chunk_id":"episode-21#c0","idx":0,"start":20,"title":"Вступление: второй сезон про базы данных"},{"chunk_id":"episode-21#c1","idx":1,"start":108,"title":"Базы данных на собеседовании — сложный топик"},{"chunk_id":"episode-21#c2","idx":2,"start":358,"title":"language-, framework- и database-agnostic"},{"chunk_id":"episode-21#c3","idx":3,"start":710,"title":"История баз данных: 60-е — 90-е"},{"chunk_id":"episode-21#c4","idx":4,"start":901,"title":"NoSQL и Not Only SQL"},{"chunk_id":"episode-21#c5","idx":5,"start":972,"title":"NewSQL: распределённость плюс транзакции"},{"chunk_id":"episode-21#c6","idx":6,"start":1025,"title":"Облако и shared-disk-системы"},{"chunk_id":"episode-21#c7","idx":7,"start":1205,"title":"Графовые и time series базы данных"},{"chunk_id":"episode-21#c8","idx":8,"start":1324,"title":"Что их объединяет: SQL"},{"chunk_id":"episode-21#c9","idx":9,"start":1400,"title":"SQL как стандарт и основы запросов"},{"chunk_id":"episode-21#c10","idx":10,"start":1734,"title":"GROUP BY, HAVING, функции и их причуды"},{"chunk_id":"episode-21#c11","idx":11,"start":2105,"title":"ORDER BY, LIMIT, оконные функции, CTE"},{"chunk_id":"episode-21#c12","idx":12,"start":2322,"title":"Итог и анонс следующего выпуска"}],"date":"2023-06-12","duration_sec":2381,"guests":[],"key_takeaways":["Глубокое понимание алгоритмов и внутреннего устройства баз данных ценнее знания конкретного языка, фреймворка или СУБД: подход language-agnostic масштабируется до framework-agnostic и database-agnostic.","Реляционные базы данных появились в середине 70-х, победили конкурентов к 80-м (Oracle, Ingres → Postgres, Informix, DB2), а в 90-х начался их бум (MS SQL Server, MySQL, Postgres, SQLite).","`NoSQL` расшифровывается как Not Only SQL; такие системы (документные, key-value) жертвовали схемой и `ACID`-транзакциями ради масштабируемости в эпоху интернет-бума 2000-х.","NewSQL-системы 2010-х (Google Spanner, CockroachDB, YugabyteDB, Apache Ignite 3) совмещают распределённость, `SQL` и полноценные транзакции.","В shared-disk-архитектуре (Spark, Snowflake, Redshift, Impala) файловая система (`HDFS`, `S3`) — общая абстракция, а масштабируется отдельный слой compute; это противопоставлено shared-nothing.","`SQL` — не язык программирования, а стандарт: базовый уровень совместимости — `SQL-92`, последний принятый стандарт — 2016 года, стандарт 2023 добавляет графовые запросы.","Без явных `DISTINCT` или `ORDER BY` результат `SQL`-запроса не является множеством и не отсортирован — в нём могут быть дубли; сортировка по умолчанию замедлила бы и чтение, и вставку.","`WHERE` фильтрует строки до агрегации, `HAVING` накладывает предикат уже на результат агрегации; рекурсивные CTE (`WITH RECURSIVE`) по сути задают рекурсивную функцию."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Apache Ignite — распределённая база данных","url":"https://ignite.apache.org"},{"title":"CockroachDB — distributed SQL database","url":"https://www.cockroachlabs.com"},{"title":"Google Cloud Spanner","url":"https://cloud.google.com/spanner"},{"title":"Neo4j — графовая база данных","url":"https://neo4j.com"},{"title":"Apache Hadoop (HDFS)","url":"https://hadoop.apache.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-21/index.md","number":21,"season":1,"slug":"episode-21","tags":["базы данных","SQL","история технологий","NoSQL","реляционные СУБД"],"title":"#21: Введение в базы данных: История и SQL","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-21/"},{"abstract":"Второй выпуск сезона про базы данных. Через развёрнутую аналогию с сортировочным складом Александр Пахомов разбирает верхнеуровневую архитектуру почти любой СУБД — транспортный уровень, обработчик запросов с оптимизатором, подсистему выполнения и подсистему хранилища (диспетчеры транзакций, блокировок, буфера, восстановления и средства доступа), — а затем классифицирует базы данных по методам хранения: OLTP против OLAP, in-memory против дисковых, строковые против колоночных. В финале — идея композируемости: современные СУБД собираются из переиспользуемых блоков, но абстракции между слоями неизбежно текут ради скорости.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/22_Database_Architecture.mp3","chapters":[{"chunk_id":"episode-22#c0","idx":0,"start":20,"title":"Вступление: компоненты и классификация БД"},{"chunk_id":"episode-22#c1","idx":1,"start":70,"title":"Аналогия со складом"},{"chunk_id":"episode-22#c2","idx":2,"start":244,"title":"Склад как база данных: расшифровка аналогии"},{"chunk_id":"episode-22#c3","idx":3,"start":353,"title":"Четыре слоя и транспортный уровень"},{"chunk_id":"episode-22#c4","idx":4,"start":383,"title":"Обработчик запросов: парсер и оптимизатор"},{"chunk_id":"episode-22#c5","idx":5,"start":484,"title":"Подсистема выполнения: локальная и удалённая"},{"chunk_id":"episode-22#c6","idx":6,"start":524,"title":"Подсистема хранилища и её диспетчеры"},{"chunk_id":"episode-22#c7","idx":7,"start":699,"title":"Чем различаются БД: OLTP и OLAP"},{"chunk_id":"episode-22#c8","idx":8,"start":878,"title":"In-memory против дисковых баз данных"},{"chunk_id":"episode-22#c9","idx":9,"start":967,"title":"Колоночные против строковых хранилищ"},{"chunk_id":"episode-22#c10","idx":10,"start":1220,"title":"Композируемость: переиспользование блоков"}],"date":"2023-06-19","duration_sec":1450,"guests":[],"key_takeaways":["Почти любая СУБД состоит из четырёх слоёв: транспортный уровень, обработчик запросов (парсер + оптимизатор), подсистема выполнения и подсистема хранилища.","Транспортный уровень двусторонний: одна подсистема общается с клиентом, другая — между нодами кластера, и они могут переиспользовать общий код.","Обработчик запросов сперва парсит и валидирует запрос (включая проверку доступа к объектам), а затем оптимизатор строит план запроса — дерево исполнения, которое видно через `EXPLAIN`.","Подсистема выполнения бывает локальной (`JOIN`-ы, сортировки, агрегации, чтение и запись данных) и удалённой (передать запрос или его часть на другую ноду).","Подсистема хранилища — самая сложная: диспетчер транзакций, диспетчер блокировок, средства доступа (`LSM`- или `B-Tree`-деревья), диспетчер буфера и диспетчер восстановления.","Большинство СУБД не полагаются на виртуальную память ОС для кэширования страниц, а реализуют собственный диспетчер буфера — это осознанное решение.","OLTP-базы (Postgres, Oracle) оптимизированы под частые одиночные чтения и записи и обычно строковые; OLAP-базы оптимизированы под редкие тяжёлые аналитические запросы и обычно колоночные.","Колоночное хранение выигрывает на агрегатах по одному полю (векторные `SIMD`-инструкции, лучшее сжатие однотипных данных), но проигрывает строковому на выборке всех полей одной записи."],"lastmod":"2026-09-16T11:54:17+03:00","links":[],"md_url":"https://apkhmv.xyz/podcast/episode-22/index.md","number":22,"season":1,"slug":"episode-22","tags":["базы данных","архитектура СУБД","OLAP и OLTP","колоночные хранилища","подсистема хранения"],"title":"#22: Архитектура баз данных: компоненты и классификация","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-22/"},{"abstract":"Выпуск второго сезона про базы данных. Александр Пахомов объясняет, как внутреннее устройство накопителей — механическая головка HDD и блочная организация SSD (ячейка → строка → массив → страница → блок, где чтение и запись идут страницами, а удаление — блоками) — диктует примитивы, которыми оперируют хранилища. Разбирает иерархию памяти и таблицу задержек «Latency Numbers Every Programmer Should Know», а затем — устройство страницы в базе данных: заголовок и записи, фрагментацию с дефрагментацией и в итоге слотированные страницы (slotted pages) со слот-массивом, растущим навстречу данным.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/23_SSD_and_HDD_disks.mp3","chapters":[{"chunk_id":"episode-23#c0","idx":0,"start":21,"title":"Вступление: как жёсткий диск сменился на SSD"},{"chunk_id":"episode-23#c1","idx":1,"start":169,"title":"HDD: магнитный диск, головка и random seek"},{"chunk_id":"episode-23#c2","idx":2,"start":260,"title":"SSD: ячейки, страницы и блоки"},{"chunk_id":"episode-23#c3","idx":3,"start":337,"title":"Почему нам вообще приходится идти на диск"},{"chunk_id":"episode-23#c4","idx":4,"start":409,"title":"Иерархия хранилищ: volatile и non-volatile"},{"chunk_id":"episode-23#c5","idx":5,"start":519,"title":"Latency Numbers Every Programmer Should Know"},{"chunk_id":"episode-23#c6","idx":6,"start":675,"title":"Как базы данных представляют данные: страницы"},{"chunk_id":"episode-23#c7","idx":7,"start":814,"title":"Устройство страницы: заголовок и записи"},{"chunk_id":"episode-23#c8","idx":8,"start":1033,"title":"Переменные записи, фрагментация и дефрагментация"},{"chunk_id":"episode-23#c9","idx":9,"start":1193,"title":"Слотированные страницы (slotted pages)"},{"chunk_id":"episode-23#c10","idx":10,"start":1496,"title":"Итог и не-хэппи-энд истории с диском"}],"date":"2023-06-26","duration_sec":1601,"guests":[],"key_takeaways":["HDD — это магнитные пластины со считывающей головкой; перемещение головки (random seek) — медленная механическая операция, поэтому базы данных оптимизируют под последовательное чтение и запись и минимизируют случайные обращения.","В SSD головки нет, а память организована иерархически: ячейка → строка → массив → страница → блок; минимальная единица чтения и записи — страница (обычно 4 КБ), а минимальная единица удаления — блок.","Из-за поблочного удаления страницы часто лишь помечают как удалённые, а не стирают физически: соседняя страница в том же блоке может быть ещё не готова к удалению.","Иерархия хранилищ делится на volatile (регистры, CPU cache, RAM — быстрый побайтовый random access, но теряется при выключении) и non-volatile (SSD, HDD, сеть — блочный доступ, но данные сохраняются).","Таблица «Latency Numbers Every Programmer Should Know»: регистр ~1 нс, CPU cache ~4 нс, RAM ~100 нс, SSD ~16 000 нс, HDD ~2 000 000 нс, сеть ~50 000 000 нс — в человеческом масштабе это 1 с, 4 с, 100 с, 4,5 часа, 3,5 недели и полтора года.","Базы данных хранят данные в страницах фиксированного размера (обычно 4 КБ); страница идентифицируется id, который мапится на физическое смещение на диске, а страницы собираются в файлы — например, в `heap`-файл.","Страница состоит из заголовка (`header`, ~5–10%: размер, чек-сумма, версия формата, транзакционные данные) и записей-`tuple`; записи переменной длины при удалении из середины ведут к фрагментации, с которой борются дефрагментацией.","В слотированной странице (`slotted page`) сразу за заголовком идёт слот-массив смещений, растущий слева направо, а сами записи пишутся с конца страницы справа налево; клиенты ссылаются на записи через слоты, поэтому дефрагментация незаметна и не требует блокировок."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Latency Numbers Every Programmer Should Know","url":"https://gist.github.com/jboner/2841832"},{"title":"CMU 15-445/645 — Intro to Database Systems (Andy Pavlo)","url":"https://15445.courses.cs.cmu.edu/"},{"title":"Apache Ignite — распределённая база данных","url":"https://ignite.apache.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-23/index.md","number":23,"season":1,"slug":"episode-23","tags":["базы данных","устройство дисков","SSD и HDD","слотированные страницы","иерархия памяти"],"title":"#23: SSD и HDD: устройство дисков и слотированные страницы","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-23/"},{"abstract":"Продолжение сезона про базы данных. Александр Пахомов объясняет, почему главной структурой данных в индексах стало именно B-дерево: сначала на пальцах разбирает бинарное дерево поиска, его инвариант и вырождение в список, затем — балансировку и логарифмический поиск, и показывает, почему бинарные деревья не годятся для диска (большая высота → много случайных чтений). Дальше на примере библиотеки с указателями на стеллажах он раскрывает устройство `B+tree` (внутренние узлы-указатели, листовые узлы с данными, связанный список листьев для sequential scan) и объясняет, чем оно лучше классического `B-tree`.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/24_B-tree.mp3","chapters":[{"chunk_id":"episode-24#c0","idx":0,"start":21,"title":"Вступление: B-дерево в индексах"},{"chunk_id":"episode-24#c1","idx":1,"start":64,"title":"Просьба поддержать подкаст"},{"chunk_id":"episode-24#c2","idx":2,"start":110,"title":"Бинарное дерево поиска и его инвариант"},{"chunk_id":"episode-24#c3","idx":3,"start":247,"title":"Вырождение в список и балансировка"},{"chunk_id":"episode-24#c4","idx":4,"start":369,"title":"Поиск по ключу, а не «да/нет»"},{"chunk_id":"episode-24#c5","idx":5,"start":417,"title":"Почему бинарные деревья не годятся для диска"},{"chunk_id":"episode-24#c6","idx":6,"start":491,"title":"B+tree: аналогия с библиотекой"},{"chunk_id":"episode-24#c7","idx":7,"start":581,"title":"Устройство внутренних узлов B+tree"},{"chunk_id":"episode-24#c8","idx":8,"start":684,"title":"Листовые узлы и связанный список для scan"},{"chunk_id":"episode-24#c9","idx":9,"start":837,"title":"Заполнение узлов, вставка и удаление"},{"chunk_id":"episode-24#c10","idx":10,"start":984,"title":"B+tree против B-tree и итог"}],"date":"2023-07-03","duration_sec":1219,"guests":[],"key_takeaways":["Бинарное дерево поиска держит инвариант «слева строго меньше, справа строго больше», что даёт бинарный поиск, но без балансировки может выродиться в список со сложностью `O(N)`.","Сбалансированное дерево (глубина левого и правого поддеревьев различается не более чем на единицу) даёт поиск за `O(log₂ N)`: в дереве из 1024 элементов — максимум 10 переходов по указателям.","Баланс не поддерживается сам собой — при каждой вставке и удалении структура проверяется и указатели при необходимости переставляются.","Бинарные деревья не годятся для диска: степень ветвления 2 делает дерево высоким, а множество переходов по указателям превращается в множество случайных чтений (random seek), которые на диске медленны.","Для диска нужна структура с высокой степенью ветвления и низкой высотой — этим и берёт `B-tree`; поэтому внутри индексов почти всегда лежит именно оно.","Когда говорят `B-tree`-индекс, почти всегда имеют в виду `B+tree`: внутренние узлы хранят только пары «указатель — ключ» (обычно в слотированной странице), а сами данные (пары ключ-значение) лежат только в листовых узлах.","Листовые узлы `B+tree` связаны в список (связанный список связанных списков), что даёт быстрый sequential/full scan без «американских горок» вверх-вниз по дереву, которыми страдает классический `B-tree`.","Инвариант заполнения гарантирует, что каждый узел занят не меньше чем наполовину: при переполнении узел разделяется или часть данных переливается в соседний, при недозаполнении узлы сливаются — всё ради минимизации числа страниц и случайных чтений."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Andy Pavlo — CMU Intro to Database Systems","url":"https://15445.courses.cs.cmu.edu"},{"title":"B+ Tree Visualization (David Galles, USF)","url":"https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html"}],"md_url":"https://apkhmv.xyz/podcast/episode-24/index.md","number":24,"season":1,"slug":"episode-24","tags":["базы данных","структуры данных","B-дерево","индексы","работа с диском"],"title":"#24: Лучшая структура данных: B-tree, B+tree","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-24/"},{"abstract":"Продолжение сезона про базы данных. Александр разбирает, как СУБД управляют памятью: что такое buffer pool, зачем нужны dirty pages и отложенная запись, чем опасен `fsync` (включая почти двадцатилетний баг в Postgres, из-за которого ошибка `fsync` приводила к потере данных) и почему поэтому многие базы пишут собственный кэш в обход ОС через `O_DIRECT`, несмотря на знаменитую отповедь Линуса Торвальдса. Во второй половине — политики вытеснения страниц: FIFO, LRU, 2Q, Clock и TinyLFU из библиотеки Caffeine.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/25_Buffer_pool_and_fsync.mp3","chapters":[{"chunk_id":"episode-25#c0","idx":0,"start":21,"title":"Вступление"},{"chunk_id":"episode-25#c1","idx":1,"start":59,"title":"Кэширование и buffer pool"},{"chunk_id":"episode-25#c2","idx":2,"start":166,"title":"Грязные страницы и отложенная запись"},{"chunk_id":"episode-25#c3","idx":3,"start":282,"title":"Вытеснение страниц из пула"},{"chunk_id":"episode-25#c4","idx":4,"start":307,"title":"Buffer pool ОС и флаг O_DIRECT"},{"chunk_id":"episode-25#c5","idx":5,"start":413,"title":"buffered I/O, write и fsync"},{"chunk_id":"episode-25#c6","idx":6,"start":504,"title":"20-летний баг с fsync в Postgres"},{"chunk_id":"episode-25#c7","idx":7,"start":741,"title":"Пиннинг страниц и оптимизация ссылок"},{"chunk_id":"episode-25#c8","idx":8,"start":848,"title":"Политики замещения: FIFO, LRU, 2Q"},{"chunk_id":"episode-25#c9","idx":9,"start":1151,"title":"Clock, CAS и TinyLFU (Caffeine)"},{"chunk_id":"episode-25#c10","idx":10,"start":1543,"title":"Итог и анонс"}],"date":"2023-07-10","duration_sec":1616,"guests":[],"key_takeaways":["Buffer pool кэширует страницы БД в оперативной памяти: запросы идут не на диск, а в пул, и получают указатель на страницу, подгружая её с диска только при промахе.","Изменённые страницы помечаются как dirty pages и сбрасываются на диск не сразу, а пачками, чтобы не ходить на диск при каждой модификации; это ускоряет запись, но само по себе не гарантирует долговечность при сбое питания.","Чтобы гарантировать долговечность в buffered I/O, после `write` нужно вызвать `fsync`, но `fsync` сбрасывает на диск все грязные страницы кэша, а не одну — поэтому паттерн неоптимален.","Почти 20 лет Postgres неверно обрабатывал ошибку `fsync`: делал retry, но после первой ошибки ОС уже очищала грязные страницы из памяти, и повторный `fsync` затирал данные на диске.","ОС очищает грязные страницы после ошибки `fsync`, чтобы избежать утечки памяти (например, если `fsync` шёл на выдернутую флешку), — из-за этой универсальности страдают разработчики БД.","Свой buffer pool с флагом `O_DIRECT` даёт БД контроль (пиннинг горячих страниц, знание, что это узлы `B+`-дерева) в обход кэша ОС, против которого в 2007 году резко высказывался Линус Торвальдс.","FIFO как политика вытеснения не учитывает частоту и вымывает из кэша горячие страницы (корень дерева); LRU это чинит переносом обращённых страниц в конец очереди, но создаёт contention на одной структуре под конкуренцией.","Clock (модификация используется в Linux) прост и CAS-friendly: стрелка обходит кольцо страниц, гася бит доступа, и вытесняет ту, чей бит остался нулём; TinyLFU из Caffeine, наоборот, ищет кандидатов на сохранение через частотный фильтр и очереди приёма/испытания/защиты."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"PostgreSQL — управление памятью и shared buffers","url":"https://www.postgresql.org/docs/current/runtime-config-resource.html"},{"title":"Caffeine — high-performance caching library для Java","url":"https://github.com/ben-manes/caffeine"}],"md_url":"https://apkhmv.xyz/podcast/episode-25/index.md","number":25,"season":1,"slug":"episode-25","tags":["buffer pool","базы данных","fsync и долговечность","вытеснение страниц","кэширование"],"title":"#25: Buffer pools: почему БД реализуют часть ОС","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-25/"},{"abstract":"Продолжение сезона про базы данных: разбор проблем классического B+tree и инженерных приёмов их решения. Александр Пахомов объясняет, зачем деревьям нужны защёлки (latches) и почему в мире СУБД «блокировки» и «защёлки» значат не то же, что в языках программирования, показывает метод latch crabbing с оптимистичным спуском, а затем разбирает две продакшен-оптимизации записи — copy-on-write B+tree (движок LMDB в OpenLDAP) и буферизацию дельт в Lazy/Buffered B+tree (движок WiredTiger в MongoDB).","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/26_Latches.mp3","chapters":[{"chunk_id":"episode-26#c0","idx":0,"start":58,"title":"Напоминание: B+tree из 24-го выпуска"},{"chunk_id":"episode-26#c1","idx":1,"start":108,"title":"Проблема 1: блокировки и защёлки (путаница терминов)"},{"chunk_id":"episode-26#c2","idx":2,"start":186,"title":"Реализация защёлок: mutex и read-write lock"},{"chunk_id":"episode-26#c3","idx":3,"start":290,"title":"Защёлки в B-дереве и гонки данных"},{"chunk_id":"episode-26#c4","idx":4,"start":504,"title":"Latch crabbing: спуск «крабиком»"},{"chunk_id":"episode-26#c5","idx":5,"start":645,"title":"Оптимистичный подход и deadlock"},{"chunk_id":"episode-26#c6","idx":6,"start":779,"title":"Проблема 2: структурные изменения при записи"},{"chunk_id":"episode-26#c7","idx":7,"start":801,"title":"Copy-on-write B+tree и LMDB / OpenLDAP"},{"chunk_id":"episode-26#c8","idx":8,"start":1006,"title":"WiredTiger в MongoDB: буферизация дельт"},{"chunk_id":"episode-26#c9","idx":9,"start":1288,"title":"Заключение"}],"date":"2023-07-17","duration_sec":1345,"guests":[],"key_takeaways":["В мире СУБД термины перевёрнуты относительно языков программирования: «защёлка» (latch) синхронизирует потоки (это `mutex` / `read-write lock` из кода), а «блокировка» (lock) синхронизирует пользовательские транзакции на более высоком уровне.","`read-write lock` пускает много читателей одновременно, но лишь одного писателя, и на время записи блокирует всех; `mutex` — эксклюзивная блокировка на один поток независимо от чтения или записи.","Наивная поэтажная блокировка B-дерева сверху вниз превращает корень в узкое место — каждый поток держит на нём защёлку, и дерево фактически становится однопоточной структурой; так не делает ни одна СУБД.","Latch crabbing («крабинг») отпускает защёлку родителя сразу, как только взята защёлка потомка, — как краб на двух ножках, — поэтому корень заблокирован лишь на миг принятия решения.","Крабинг спускается оптимистично с read-защёлками, а при необходимости структурных изменений (каскад сплитов до корня) возвращается наверх и повторяет спуск уже с write-защёлками; из-за указателей между листьями возможны deadlock'и, которые решаются таймаутами и retry.","В copy-on-write B+tree страницы иммутабельны: запись копирует нужную страницу с изменением и порождает новую версию дерева, поэтому читателям не нужны защёлки — но они могут прочитать устаревшую версию данных.","Copy-on-write B+tree — не только теория: движок `LMDB` (Lightning Memory-Mapped Database) на его основе используется в OpenLDAP.","Buffered/Lazy B+tree не мутирует страницы при записи, а складывает дельты (`+1`, `−1`, …) в маленький буфер на страницу: чтение платит применением дельт, зато фоновый демон редко схлопывает буферы на диск — так устроен движок `WiredTiger` в MongoDB."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"LMDB — Lightning Memory-Mapped Database","url":"https://www.symas.com/lmdb"},{"title":"OpenLDAP","url":"https://www.openldap.org"},{"title":"WiredTiger — storage engine","url":"https://source.wiredtiger.com"},{"title":"MongoDB — WiredTiger storage engine","url":"https://www.mongodb.com/docs/manual/core/wiredtiger/"}],"md_url":"https://apkhmv.xyz/podcast/episode-26/index.md","number":26,"season":1,"slug":"episode-26","tags":["B+tree","защёлки","базы данных","storage engine","copy-on-write"],"title":"#26: Оптимизируем B+tree: копирование, пакетирование","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-26/"},{"abstract":"Выпуск сезона про базы данных: почему хэш-таблицы проиграли `B+`-деревьям гонку за звание главной структуры данных для индексов. Александр Пахомов разбирает устройство хэш-таблицы и её два ключевых архитектурных решения — выбор хэш-функции (trade-off «скорость против collision rate», от `MurmurHash` и `CityHash` до state-of-the-art `xxHash`) и схему хэширования: статические (linear probe, Robin Hood, cuckoo) и динамические (chained, extendable, linear hashing).","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/27_HashTables.mp3","chapters":[{"chunk_id":"episode-27#c0","idx":0,"start":20,"title":"Вступление: слон в комнате — хэш-таблицы"},{"chunk_id":"episode-27#c1","idx":1,"start":60,"title":"Что такое хэш-таблица"},{"chunk_id":"episode-27#c2","idx":2,"start":103,"title":"Массив как хэш-таблица и остаток от деления"},{"chunk_id":"episode-27#c3","idx":3,"start":232,"title":"Условия наивной таблицы, коллизии"},{"chunk_id":"episode-27#c4","idx":4,"start":276,"title":"Два архитектурных решения: функция и схема"},{"chunk_id":"episode-27#c5","idx":5,"start":470,"title":"Хэш-функции: MurmurHash, CityHash, xxHash"},{"chunk_id":"episode-27#c6","idx":6,"start":661,"title":"Linear probe hashing и маркер удаления"},{"chunk_id":"episode-27#c7","idx":7,"start":953,"title":"Robin Hood и cuckoo hashing"},{"chunk_id":"episode-27#c8","idx":8,"start":1186,"title":"Динамические схемы: chained hashing"},{"chunk_id":"episode-27#c9","idx":9,"start":1441,"title":"Extendable hashing по битам хэша"},{"chunk_id":"episode-27#c10","idx":10,"start":1759,"title":"Linear hashing и split pointer"},{"chunk_id":"episode-27#c11","idx":11,"start":1900,"title":"Итог: почему индексы строят на B+"}],"date":"2023-07-24","duration_sec":1968,"guests":[],"key_takeaways":["Хэш-таблица — неупорядоченный ассоциативный массив, отображающий ключ на значение; позицию в массиве задаёт хэш-функция, а сложность поиска обычно `O(1)`, в худшем случае `O(n)`. Обычный массив — её вырожденный случай: ключ = индекс, хэш-функция тождественна, а произвольный хэш приводят к диапазону индексов остатком от деления на длину массива.","«Идеальная» хэш-функция без коллизий на практике недостижима, поэтому коллизии (один хэш для разных ключей) приходится разрешать всегда.","Выбор хэш-функции — trade-off между скоростью и collision rate: константа быстра, но даёт максимум коллизий; `xxHash` от автора `zstd` — state of the art, по throughput в 2–3 раза быстрее `MurmurHash` и `CityHash`.","В ячейках хранят пару ключ-значение, а не только значение: после позиционирования по `hashCode` нужен ещё `equals`, чтобы убедиться, что найден именно нужный ключ.","Linear probe hashing разрешает коллизию переходом к следующей ячейке; при удалении обязателен маркер (tombstone), иначе пустота оборвёт линейный скан и живой ключ «потеряется».","Cuckoo hashing держит `N` таблиц с `N` хэш-функциями (различаются только сидом): коллизия в одной таблице разрешается вставкой в другую, что резко снижает число коллизий.","Extendable hashing навигирует по битам хэша через global counter и при переполнении сплитит только переполненный бакет, удваивая ассоциативный массив, — старые страницы на диске не трогаются.","Индексы почти всегда строят на `B+`-дереве, а не на хэш-таблицах: `B+` даёт сопоставимый перформанс даже при чтении по единственному ключу и вдобавок умеет быстрое построение индекса на отсортированных данных, чтение по диапазону и эффективное отсортированное сканирование."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"xxHash — extremely fast hash algorithm","url":"https://github.com/Cyan4973/xxHash"},{"title":"MurmurHash","url":"https://github.com/aappleby/smhasher"},{"title":"Google CityHash","url":"https://github.com/google/cityhash"},{"title":"CMU 15-445 Database Systems — Hash Tables (Andy Pavlo)","url":"https://15445.courses.cs.cmu.edu/"}],"md_url":"https://apkhmv.xyz/podcast/episode-27/index.md","number":27,"season":1,"slug":"episode-27","tags":["хэш-таблицы","хэш-функции","схемы хэширования","базы данных","индексы"],"title":"#27: Хэш таблицы: функции и схемы хэширования","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-27/"},{"abstract":"Сольный выпуск из серии про базы данных. Александр Пахомов разбирает ACID-транзакции: сначала «зазубренный» ответ на собеседовании (атомарность, консистентность, изоляция, долговечность) с комментариями к каждому свойству и упоминанием реализаций через write-ahead log и shadow paging, а затем — главную часть про изоляцию. На аналогии со складом он объясняет аномалии параллельного исполнения (грязное и неповторяемое чтение, фантомы, потерянное обновление, грязная запись, write skew), выстраивает из них уровни изоляции вплоть до `serializable` и разбирает, что вообще стоит за сериализуемостью — конфликты, граф зависимостей и разница между conflict- и view-serializable.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/28_ACID_Transactions.mp3","chapters":[{"chunk_id":"episode-28#c0","idx":0,"start":20,"title":"Вступление: ACID и сериализуемость"},{"chunk_id":"episode-28#c1","idx":1,"start":134,"title":"Простой ответ про ACID на собеседовании"},{"chunk_id":"episode-28#c2","idx":2,"start":223,"title":"Атомарность, WAL и shadow paging"},{"chunk_id":"episode-28#c3","idx":3,"start":372,"title":"Консистентность и путаница с CAP-теоремой"},{"chunk_id":"episode-28#c4","idx":4,"start":472,"title":"Долговечность"},{"chunk_id":"episode-28#c5","idx":5,"start":529,"title":"Изоляция и склад из 21-го выпуска"},{"chunk_id":"episode-28#c6","idx":6,"start":767,"title":"Аномалии: грязное, неповторяемое, фантомное чтение"},{"chunk_id":"episode-28#c7","idx":7,"start":908,"title":"Lost update, dirty write и write skew"},{"chunk_id":"episode-28#c8","idx":8,"start":1107,"title":"Уровни изоляции: от read uncommitted до serializable"},{"chunk_id":"episode-28#c9","idx":9,"start":1305,"title":"Что стоит за serializable: конфликты, граф, conflict- и view-serializable"},{"chunk_id":"episode-28#c10","idx":10,"start":1742,"title":"Итог и анонс двухфазных блокировок"}],"date":"2023-07-31","duration_sec":1799,"guests":[],"key_takeaways":["Транзакция — последовательность операторов одного клиента над базой данных: `begin transaction` открывает её, а `commit` или `abort`/`rollback` завершает.","ACID = Atomicity, Consistency, Isolation, Durability; атомарность нужна прежде всего для удобства программиста — группу изменений хочется выполнять как один осмысленный юнит «всё или ничего».","Атомарность и долговечность база обеспечивает в основном через write-ahead log; альтернатива — shadow paging (теневые страницы), как в copy-on-write-хранилище LMDB из 26-го выпуска, но так делают немногие.","Consistency в ACID (сохранение инвариантов и констрейнтов) — это совсем не то же, что буква C в CAP-теореме; их постоянно путают.","Все аномалии сводятся к одному: одна или несколько транзакций производят запись, а дальше в зависимости от того, кто пишет и кто читает, получаются non-repeatable read, phantom read, lost update, dirty read/write или write skew.","Уровни изоляции отличаются друг от друга набором допускаемых аномалий: `read uncommitted` разрешает всё, `read committed` убирает грязные чтения/записи, `repeatable read` — неповторяемые и фантомные чтения, `serializable` — ещё и write skew.","`serializable` даёт гарантию, что результат параллельного исполнения транзакций доказуемо совпадает с результатом какого-то последовательного (serial) их выполнения.","Conflict-serializable = граф зависимостей между операциями транзакций не содержит циклов; view-serializable — более широкий класс планов, но считать его дорого по CPU, поэтому в 99% случаев на практике речь про conflict-serializable."],"lastmod":"2026-09-16T11:54:17+03:00","links":[],"md_url":"https://apkhmv.xyz/podcast/episode-28/index.md","number":28,"season":1,"slug":"episode-28","tags":["ACID","транзакции","уровни изоляции","сериализуемость","аномалии чтения и записи"],"title":"#28: ACID transactions: аномалии и сериализуемость","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-28/"},{"abstract":"Продолжение сезона про базы данных: как СУБД на самом деле гарантируют уровни изоляции. Александр разбирает три протокола управления конкурентностью — пессимистичную двухфазную блокировку (2PL) с её строгой версией, детекцией дедлоков по waits-for-graph, гранулярностью и intention locks; оптимистическое управление (OCC) с private workspace и фазами чтения/валидации/записи; и мультиверсионность (MVCC), которая хранит несколько версий объекта, даёт snapshot isolation почти бесплатно и лежит в основе большинства современных СУБД. Попутно — таймстемп-ординг как теоретический фундамент, аномалия write skew, дефолтные уровни изоляции в Postgres, Oracle и Google Spanner, а также хранение версий, сборка мусора и вторичные индексы в MVCC.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/29_Concurrency_control.mp3","chapters":[{"chunk_id":"episode-29#c0","idx":0,"start":20,"title":"Вступление: как СУБД гарантируют изоляцию"},{"chunk_id":"episode-29#c1","idx":1,"start":76,"title":"Блокировки в базах данных: shared и exclusive"},{"chunk_id":"episode-29#c2","idx":2,"start":280,"title":"Двухфазная блокировка (2PL)"},{"chunk_id":"episode-29#c3","idx":3,"start":393,"title":"Каскадный откат и strong strict 2PL"},{"chunk_id":"episode-29#c4","idx":4,"start":519,"title":"Дедлоки и waits-for-graph"},{"chunk_id":"episode-29#c5","idx":5,"start":696,"title":"Гранулярность блокировок и intention locks"},{"chunk_id":"episode-29#c6","idx":6,"start":982,"title":"Таймстемп-ординг без блокировок"},{"chunk_id":"episode-29#c7","idx":7,"start":1280,"title":"Optimistic concurrency control"},{"chunk_id":"episode-29#c8","idx":8,"start":1635,"title":"Фантомные записи и предикатные блокировки"},{"chunk_id":"episode-29#c9","idx":9,"start":1831,"title":"Уровни изоляции: Postgres, Oracle, Spanner"},{"chunk_id":"episode-29#c10","idx":10,"start":2105,"title":"MVCC: мультиверсионность"},{"chunk_id":"episode-29#c11","idx":11,"start":2472,"title":"Хранение версий, сборка мусора, индексы"},{"chunk_id":"episode-29#c12","idx":12,"start":2764,"title":"Заключение и анонс LSM-деревьев"}],"date":"2023-08-07","duration_sec":2829,"guests":[],"key_takeaways":["Блокировки в базах данных (`shared`/`exclusive`) поддерживают уровни изоляции транзакций и управляются отдельной подсистемой Lock Manager — это не то же самое, что мьютексы в языках программирования.","Двухфазная блокировка (2PL) делит жизнь транзакции на growing phase (только захват блокировок) и shrinking phase (только освобождение); строгая версия (strong strict 2PL) отпускает все блокировки лишь на коммите, что убирает каскадный откат.","Дедлоки неизбежны под нагрузкой: Lock Manager строит waits-for-graph, и цикл в нём означает дедлок — его разрывают, выбирая транзакцию-жертву и откатывая её.","Intention locks (`IS`, `IX`, `SIX`) — это не блокировки, а маркеры на родительском узле иерархии, позволяющие не обходить все тюплы, чтобы понять, можно ли взять блокировку на всю таблицу.","Базовый timestamp ordering не использует блокировок, а сравнивает read/write-таймстемпы у объекта; в чистом виде он неприменим из-за контеншена на запись метаданных, но лежит в основе реальных алгоритмов OCC и MVCC.","Optimistic concurrency control работает через private workspace и три фазы (чтение → валидация → запись); он идеален для read-only и непересекающихся транзакций, но долгие транзакции под ним страдают — фейл случается только на валидации в самом конце.","Даже под 2PL возможна аномалия фантомной записи (phantom read), поэтому serializable требует дополнительных приёмов — повторного чтения датасета, предикатных блокировок или index locking.","MVCC хранит несколько физических версий одного логического объекта: писатели не блокируют читателей и наоборот, snapshot isolation достигается почти бесплатно, но остаётся аномалия write skew; расплата — хранение версий, сборка мусора и обновление вторичных индексов."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"PostgreSQL — уровни изоляции транзакций","url":"https://www.postgresql.org/docs/current/transaction-iso.html"},{"title":"Google Cloud Spanner","url":"https://cloud.google.com/spanner"}],"md_url":"https://apkhmv.xyz/podcast/episode-29/index.md","number":29,"season":1,"slug":"episode-29","tags":["управление конкурентностью","транзакции","уровни изоляции","MVCC","базы данных"],"title":"#29: Concurrency control: 2PL, OCC, MVCC","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-29/"},{"abstract":"Юбилейный тридцатый выпуск про Log-Structured Merge Tree — структуру данных, оптимизированную под запись и ставшую основной альтернативой `B+`-деревьям в современных key-value-хранилищах. Александр Пахомов объясняет RUM-трейд-офф (read-update-memory) и слабые места `B+`-дерева на записи, разбирает устройство двух- и многокомпонентного LSM (дерево в памяти + write-ahead log + иммутабельные `SSTable` на диске, compaction по уровням, tombstone-удаления), показывает, почему чтение в LSM платит за быструю запись, и связывает популярность LSM с физикой SSD, который тоже пишет и стирает блоками журналируемо.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/30_LSM_Tree.mp3","chapters":[{"chunk_id":"episode-30#c0","idx":0,"start":20,"title":"Вступление: юбилейный выпуск про LSM"},{"chunk_id":"episode-30#c1","idx":1,"start":70,"title":"Зачем нужна структура, отличная от B+ дерева"},{"chunk_id":"episode-30#c2","idx":2,"start":108,"title":"RUM-трейд-офф и слабые места B+ на записи"},{"chunk_id":"episode-30#c3","idx":3,"start":319,"title":"Чтение против записи: цена апдейта в B+"},{"chunk_id":"episode-30#c4","idx":4,"start":464,"title":"LSM: иммутабельность, append-only, tombstone"},{"chunk_id":"episode-30#c5","idx":5,"start":578,"title":"Плюсы иммутабельности: нет блокировок, экономия места"},{"chunk_id":"episode-30#c6","idx":6,"start":701,"title":"Двухкомпонентный LSM: память + диск + WAL"},{"chunk_id":"episode-30#c7","idx":7,"start":934,"title":"Многокомпонентный LSM и compaction по уровням"},{"chunk_id":"episode-30#c8","idx":8,"start":1212,"title":"Почему чтение платит за быструю запись"},{"chunk_id":"episode-30#c9","idx":9,"start":1477,"title":"SSTable, Bloom-фильтры, проверка границ"},{"chunk_id":"episode-30#c10","idx":10,"start":1682,"title":"Инсайты: LSM и физика SSD, сквозные журналы"},{"chunk_id":"episode-30#c11","idx":11,"start":1980,"title":"Итог: как выбирать хранилище под нагрузку"}],"date":"2023-08-14","duration_sec":2049,"guests":[],"key_takeaways":["LSM-дерево (`Log-Structured Merge Tree`) — по сути единственная реальная альтернатива `B+`-деревьям как низкоуровневому key-value-хранилищу базы данных.","RUM-гипотеза (read-update-memory) гласит, что из трёх параметров — чтение, запись и занимаемое место — одновременно можно оптимизировать только два; `B+`-дерево оптимизировано под чтение, LSM — под запись.","В `B+`-дереве точечный апдейт стоит двух дисковых операций (считать страницу целиком, изменить, записать 4 КБ обратно), а страницы держат ~30% свободного места про запас — из-за этого оно проседает под интенсивной записью.","Данные внутри LSM строго иммутабельны и `append-only`: апдейт добавляет новую версию записи, а удаление — специальный маркер `tombstone`; за счёт этого на низком уровне не нужны блокировки (latch'и).","Двухкомпонентный LSM — это дерево в памяти (плюс `write-ahead log` для recovery) и одно дерево на диске; на практике почти не встречается, повсеместно используется многокомпонентный вариант с множеством иммутабельных деревьев на диске.","Compaction — фоновый процесс, сливающий мелкие иммутабельные таблицы в более крупные по уровням; размер уровней растёт геометрически, что математически минимизирует число дисковых операций при слиянии.","Чтение в LSM медленнее, чем в `B+`-дереве: чтобы получить актуальное значение ключа, приходится открыть итераторы по всем деревьям, где он может лежать, собрать все версии и по timestamp выбрать последнюю (в помощь идут `Bloom`-фильтры и проверка границ ключей).","Популярность LSM исторически связана с SSD: журналируемая запись блоками и иммутабельность ложатся на физику твердотельного накопителя лучше, чем постраничный in-place-апдейт `B+`-дерева."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Database Internals — книга Алекса Петрова","url":"https://www.databass.dev"},{"title":"RocksDB — встраиваемое key-value-хранилище на LSM","url":"https://rocksdb.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-30/index.md","number":30,"season":1,"slug":"episode-30","tags":["LSM-дерево","структуры данных","хранилища баз данных","compaction","SSD"],"title":"#30: LSM Tree: структура данных взрывает мозг","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-30/"},{"abstract":"Выпуск про Write-Ahead Log — механизм, который обеспечивает атомарность и долговечность транзакций и лежит в сердце почти любой базы данных. Александр объясняет, зачем логировать изменения, если оперативная память быстрая, но недолговечна, разбирает политики буферизации (`steal`/`no-steal`, `force`/`no-force`) и альтернативу в виде shadow paging, а затем на пальцах проходит устройство самого лога (append-only, immutable, log records, checkpoint) и семейство алгоритмов восстановления ARIES с его фазами analysis, redo и undo.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/31_WAL.mp3","chapters":[{"chunk_id":"episode-31#c0","idx":0,"start":21,"title":"Вступление: WAL — сердце базы данных"},{"chunk_id":"episode-31#c1","idx":1,"start":62,"title":"Какую проблему решаем: быстрая, но недолговечная память"},{"chunk_id":"episode-31#c2","idx":2,"start":163,"title":"Две задачи: откат и восстановление, трейд-оффы"},{"chunk_id":"episode-31#c3","idx":3,"start":217,"title":"Альтернатива: писать всё на диск на каждый коммит"},{"chunk_id":"episode-31#c4","idx":4,"start":335,"title":"Политики буферизации: steal/no-steal, force/no-force"},{"chunk_id":"episode-31#c5","idx":5,"start":443,"title":"shadow paging и почему побеждает steal/no-force"},{"chunk_id":"episode-31#c6","idx":6,"start":518,"title":"Устройство лога: append-only, immutable, log records"},{"chunk_id":"episode-31#c7","idx":7,"start":623,"title":"Буфер лога, два строгих правила и grouped commit"},{"chunk_id":"episode-31#c8","idx":8,"start":808,"title":"Физическое и логическое логирование, checkpoints"},{"chunk_id":"episode-31#c9","idx":9,"start":1005,"title":"Восстановление и ARIES: LSN, CLR, ATT и DPT"},{"chunk_id":"episode-31#c10","idx":10,"start":1372,"title":"Три фазы ARIES: analysis, redo, undo"},{"chunk_id":"episode-31#c11","idx":11,"start":1633,"title":"Итог"}],"date":"2023-08-21","duration_sec":1739,"guests":[],"key_takeaways":["WAL решает сразу две задачи — как откатывать незавершённые транзакции и как восстанавливаться после сбоя, — обеспечивая атомарность и долговечность (`durability`) из `ACID`.","Перед коммитом транзакции хвост лога обязан быть сброшен на диск (`fsync`), но дорогие грязные страницы с данными на диск не пишутся сразу — они дозаписываются асинхронно; это и есть выигрыш WAL перед подходом «писать всё на каждый коммит».","Правило write-ahead: любая модификация страницы сначала записывается в лог и только потом применяется к странице в буфере — сначала декларируем намерение, затем совершаем действие.","Большинство баз данных работают по политике `steal` + `no-force` (можно писать незакоммиченные страницы на диск и не ждать записи страниц на коммите); альтернатива `no-steal` + `force` — это shadow paging с быстрым восстановлением, но дорогими random writes.","Лог — это append-only и immutable структура: писать можно только в конец, а неизменяемость гарантирует, что читающие при восстановлении процессы не увидят подмены данных под ногами.","Checkpoint отсекает уже сброшенную на диск часть лога, чтобы не читать её при восстановлении; современные базы используют неблокирующий fuzzy checkpoint (`begin`/`end`) вместо stop-the-world.","ARIES (Algorithms for Recovery and Isolation Exploiting Semantics) восстанавливает базу в три фазы: analysis (наполнение `active transaction table` и `dirty page table` от последнего checkpoint), redo (проигрывание изменений до состояния на момент краха) и undo (откат незакоммиченных транзакций).","Log Sequence Number (`LSN`) — монотонно растущий идентификатор записи лога; вместе с `prev-LSN` и page LSN он задаёт порядок и цепочки, а во время undo пишутся compensation log records (`CLR`), чтобы повторный сбой не откатывал одно и то же дважды."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"ARIES — оригинальная статья Mohan et al. (ACM)","url":"https://dl.acm.org/doi/10.1145/128765.128770"}],"md_url":"https://apkhmv.xyz/podcast/episode-31/index.md","number":31,"season":1,"slug":"episode-31","tags":["базы данных","write-ahead log","восстановление после сбоя","транзакции","ARIES"],"title":"#31: WAL: сердце любой базы данных","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-31/"},{"abstract":"Продолжение сезона про базы данных. Александр Пахомов разбирает, как СУБД сортируют и соединяют таблицы, когда данные не влезают в оперативную память. Сначала — алгоритмы сортировки (`quicksort`, top-N heap sort, external merge sort) и их оптимизации (early/late materialization, prefetch, кодогенерация под типы, сравнение бинарных префиксов), затем hash aggregate для `GROUP BY`, и наконец три способа соединения таблиц — nested loop join, sort-merge join и hash join — с выводом, почему hash join обычно самый эффективный.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/32_Joins.mp3","chapters":[{"chunk_id":"episode-32#c0","idx":0,"start":20,"title":"Вступление"},{"chunk_id":"episode-32#c1","idx":1,"start":65,"title":"Query-план: дерево операторов"},{"chunk_id":"episode-32#c2","idx":2,"start":146,"title":"Диск, память и зачем нужны сортировки"},{"chunk_id":"episode-32#c3","idx":3,"start":300,"title":"Сортировка в памяти: quicksort и top-N heap sort"},{"chunk_id":"episode-32#c4","idx":4,"start":366,"title":"External merge sort и early/late materialization"},{"chunk_id":"episode-32#c5","idx":5,"start":517,"title":"External merge sort пошагово и prefetch"},{"chunk_id":"episode-32#c6","idx":6,"start":714,"title":"Оптимизации сравнения: кодогенерация и бинарные префиксы"},{"chunk_id":"episode-32#c7","idx":7,"start":845,"title":"Сортировка через B+-дерево индекс"},{"chunk_id":"episode-32#c8","idx":8,"start":946,"title":"Hash aggregate для GROUP BY"},{"chunk_id":"episode-32#c9","idx":9,"start":1125,"title":"Join: постановка и метрика I/O"},{"chunk_id":"episode-32#c10","idx":10,"start":1238,"title":"Nested loop, sort-merge и hash join"}],"date":"2023-08-28","duration_sec":1834,"guests":[],"key_takeaways":["План запроса (query-план) — дерево операторов: снизу операторы доступа к данным (`sequential scan`, `index scan`), выше — соединения, фильтрации и агрегации, а в корне — `SELECT` с нужными полями.","Реляционная алгебра не знает про порядок строк, поэтому сортировка нужна отдельно — для `ORDER BY`, `DISTINCT`, эффективной вставки в B+-дерево и группировки в `GROUP BY`.","Если таблица влезает в память — сортируем `quicksort`; при `LIMIT N` — top-N heap sort (куча размера `N` за один full scan); иначе — external merge sort с фазами «нарезать и отсортировать чанки» и «слить отсортированные пробеги».","External merge sort упирается в диск, поэтому применяют prefetch: I/O в одном потоке подгружает следующие страницы в буфер, пока CPU сортирует текущую.","Сравнение ключей оптимизируют кодогенерацией под конкретные типы (`int sort`, `string sort`) вместо указателя на функцию, а строки сравнивают по бинарным префиксам байтов с fallback на медленное посимвольное сравнение.","`GROUP BY` считают через hash aggregate: строят хеш-таблицу «ключ → running-агрегат»; если она не влезает в память — external hash aggregate раскладывает данные по бакетам на диск, затем делает `rehash` каждого бакета.","Из трёх join-алгоритмов nested loop join (даже блочный или с индексом) почти всегда худший; sort-merge join окупается, когда данные уже отсортированы на диске или результат нужно сортировать дальше.","Hash join строит хеш-таблицу по первой таблице (`linear probing`) и пробивает её второй; при нехватке памяти переходит в Grace hash join с партиционированием на диск и рекурсивным партиционированием при перекосе; Bloom-фильтр отсекает лишние обращения к хеш-таблице."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Grace hash join — Wikipedia","url":"https://en.wikipedia.org/wiki/Hash_join"},{"title":"Bloom filter — Wikipedia","url":"https://en.wikipedia.org/wiki/Bloom_filter"}],"md_url":"https://apkhmv.xyz/podcast/episode-32/index.md","number":32,"season":1,"slug":"episode-32","tags":["базы данных","сортировки","join","hash join","query-план"],"title":"#32: Merge sort и hash join: соединяют и сортируют","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-32/"},{"abstract":"Финал второго сезона про базы данных. Александр Пахомов разбирает один из самых сложных компонентов СУБД — оптимизатор запросов: как выглядит план запроса и как по нему текут данные, три модели обработки (итератор, материализация, векторизация), методы доступа к данным (`sequential scan` с его оптимизациями и `index scan`), Halloween Problem и JIT-компиляцию выражений. Вторая половина — параллелизм: модели воркеров (процесс на воркер, тред на воркер, embedded), горизонтальное распараллеливание плана и место самого оптимизатора в конвейере от парсера до физического плана, где он применяет эвристики и cost-based-оптимизации на основе статистик.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/33_Query_Optimizations.mp3","chapters":[{"chunk_id":"episode-33#c0","idx":0,"start":21,"title":"Вступление: оптимизатор запросов и финал сезона"},{"chunk_id":"episode-33#c1","idx":1,"start":66,"title":"Что такое план запроса и как текут данные"},{"chunk_id":"episode-33#c2","idx":2,"start":219,"title":"Три модели обработки: итератор, материализация, векторизация"},{"chunk_id":"episode-33#c3","idx":3,"start":554,"title":"Методы доступа: sequential scan и его оптимизации"},{"chunk_id":"episode-33#c4","idx":4,"start":883,"title":"index scan, Halloween Problem и JIT-компиляция"},{"chunk_id":"episode-33#c5","idx":5,"start":1159,"title":"Параллельное выполнение: throughput и latency"},{"chunk_id":"episode-33#c6","idx":6,"start":1320,"title":"Модели воркеров и свой слой поверх ОС"},{"chunk_id":"episode-33#c7","idx":7,"start":1540,"title":"Как распараллелить план: горизонтальный параллелизм"},{"chunk_id":"episode-33#c8","idx":8,"start":1772,"title":"Место оптимизатора: от парсера до физического плана"},{"chunk_id":"episode-33#c9","idx":9,"start":2027,"title":"Эвристики: pushdown, подзапросы, переписывание предикатов"},{"chunk_id":"episode-33#c10","idx":10,"start":2387,"title":"Cost-based: косты, статистики и магические константы"},{"chunk_id":"episode-33#c11","idx":11,"start":2748,"title":"Итог сезона и анонс распределённых баз данных"}],"date":"2023-09-04","duration_sec":2810,"guests":[],"key_takeaways":["План запроса — это дерево операторов, по которому данные текут снизу вверх: внизу методы доступа (`sequential scan`, `index scan`), выше — фильтры, `JOIN`, агрегации и проекция на вершине.","Есть три модели обработки: итераторная (`next` по одному тюплу, самая распространённая), материализации (оператор целиком собирает результат в память — хороша для маленьких таблиц) и векторизации (`next` возвращает вектор тюплов, к которому применяются SIMD-инструкции — типична для аналитических СУБД вроде Snowflake и ClickHouse).","`sequential scan` — худший, но иногда единственный способ доступа; его оптимизируют prefetch-ем страниц, buffer pool bypass, параллельным чтением, late materialization и data skipping (approximate queries и zone maps с предпосчитанными агрегатами в заголовке страницы).","Halloween Problem — это когда `UPDATE` (например, надбавка тем, кто получает меньше 100k) многократно находит и снова повышает одну и ту же запись; решается трекингом id уже обновлённых в текущем запросе строк.","Некоторые СУБД (Postgres) умеют JIT-компилировать выражения `WHERE` в нативную C-функцию вместо интерпретации дерева выражения для каждого тюпла.","Параллельное выполнение повышает throughput и снижает latency; в plan-driven-модели СУБД сама шедулит воркеров (SQL Server реализует собственный слой поверх ОС с кооперативным `yield`), что умнее, чем полагаться на планировщик операционной системы, как делает модель «процесс на воркер» в Postgres.","Поиск оптимального плана — NP-полная задача, поэтому ищут не идеальный, а «достаточно хороший» план; оптимизатор работает уже после парсера, байндера (имена → id из системного каталога) и tree-rewriter-а, превращая логический план в физический с конкретными методами доступа и реализациями `JOIN`.","Оптимизации делятся на эвристики (predicate/projection pushdown, разбиение и слияние предикатов, разворачивание подзапросов в `JOIN`, отсечение всегда-`false` условий) и cost-based, опирающиеся на статистику: гистограммы, скетчи (`HyperLogLog`), сэмплы и магические константы вроде «оперативка в 400 раз быстрее диска» в Postgres."],"lastmod":"2026-09-16T11:54:17+03:00","links":[],"md_url":"https://apkhmv.xyz/podcast/episode-33/index.md","number":33,"season":1,"slug":"episode-33","tags":["оптимизация запросов","план запроса","оптимизатор запросов","параллелизм в базах данных","cost-based оптимизация"],"title":"#33: Query optimizations: эвристики и cost-based","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-33/"},{"abstract":"Большой «спэшл» с гостем — Дмитрием Волыхиным, ведущим подкаста Java Swag и лидером комьюнити FAANG Talks, который получил оффер в Meta. Вместе с Александром они подробно разбирают весь путь подготовки к интервью в big tech: почему это лотерея и стоит ли платить за буткемпы, как устроены три части собеседования (алгоритмы, system design, behavioral), сколько готовиться и как выбрать между «спринтом» и «марафоном». Отдельно — про моки, про 7 шагов system design, про метод STAR, про грейды и деньги (`levels.fyi`), релокацию и главный инсайт: подготовка к FAANG делает тебя сильнее как инженера здесь и сейчас.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/FAANG_Interview.mp3","chapters":[{"chunk_id":"episode-34#c0","idx":0,"start":60,"title":"Вступление и знакомство с Димой"},{"chunk_id":"episode-34#c1","idx":1,"start":199,"title":"Что такое FAANG (и MANGO)"},{"chunk_id":"episode-34#c2","idx":2,"start":399,"title":"Буткемпы, курсы или готовиться самому"},{"chunk_id":"episode-34#c3","idx":3,"start":662,"title":"Собес как ЕГЭ? Формат алго-интервью"},{"chunk_id":"episode-34#c4","idx":4,"start":829,"title":"Роль алгоритмического бэкграунда"},{"chunk_id":"episode-34#c5","idx":5,"start":1141,"title":"Сколько готовиться: спринт против марафона"},{"chunk_id":"episode-34#c6","idx":6,"start":1469,"title":"Курсы, чат единомышленников, топ-ресурсы"},{"chunk_id":"episode-34#c7","idx":7,"start":1736,"title":"Кривая подготовки и переход к system design"},{"chunk_id":"episode-34#c8","idx":8,"start":2489,"title":"System design: 7 шагов, high- и low-level"},{"chunk_id":"episode-34#c9","idx":9,"start":3813,"title":"System design без опыта, моки и рисовалки"},{"chunk_id":"episode-34#c10","idx":10,"start":4114,"title":"Behavioral-интервью и метод STAR"},{"chunk_id":"episode-34#c11","idx":11,"start":4681,"title":"Грейд, деньги, levels.fyi и релокация"},{"chunk_id":"episode-34#c12","idx":12,"start":6099,"title":"Кринж-истории и польза подготовки"}],"date":"2023-11-07","duration_sec":6508,"guests":["dmitry-volyhin"],"key_takeaways":["Интервью в FAANG — это во многом лотерея: имеет смысл повышать вероятность прохождения, подаваясь сразу в пул компаний, а не целясь в одну «компанию мечты».","Буткемп оправдан только если вам нужен внешний график и комьюнити; свой «буткемп» можно собрать бесплатно — найти единомышленников и созваниваться, разбирая задачи с `LeetCode`.","Для алго-интервью нужно знать язык досконально (сложности операций у `HashMap`, `ArrayList`, `LinkedList`), чтобы синтаксис был «на кончиках пальцев» и всё мыслетопливо уходило на саму задачу.","Алгоритмический бэкграунд сильно решает и не забывается, как езда на велосипеде; при его отсутствии «марафон» (~час в день) выгоднее «спринта», потому что накопленная база служит и в следующем цикле.","Ключевой навык алго-интервью — не написать идеальный код молча, а провести интервьюера по его чек-листу: уточнить условия и ограничения, предложить brute-force и улучшение, покрыть тесты и дебаг; поэтому обязательны моки на английском.","System design строится по ~7 шагам (функциональные/нефункциональные требования, back-of-the-envelope, high-level, low-level, scaling); на low-level нужно предлагать варианты, но не называть `Kafka` без пометки «alternatives», чтобы не утонуть в деталях и уложиться в 40 минут.","Behavioral-интервью меряет ваш грейд по масштабу решённых проблем; истории пишут в Google Doc по методу STAR (Situation, Task, Action, Result), по 2 истории на вопрос, и они должны матчиться с CV.","Компенсацию в big tech смотрят на `levels.fyi` с учётом location; помимо base есть стоки и бонусы, зарплата считается в год (не в месяц), а сама подготовка к интервью прокачивает как инженера и на текущей работе."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"LeetCode — платформа для подготовки к алго-интервью","url":"https://leetcode.com"},{"title":"levels.fyi — зарплаты и грейды в IT-компаниях","url":"https://www.levels.fyi"},{"title":"Java Swag — подкаст Дмитрия Волыхина","url":"https://javaswag.github.io"},{"title":"Курс по алгоритмам Роберта Седжвика (Coursera)","url":"https://www.coursera.org/learn/algorithms-part1"},{"title":"Курс по алгоритмам Павла Маврина (ИТМО)","url":"https://www.youtube.com/@pavelmavrin"},{"title":"Cracking the Coding Interview — Gayle Laakmann McDowell","url":"https://www.crackingthecodinginterview.com"},{"title":"System Design Interview — Alex Xu","url":"https://www.amazon.com/System-Design-Interview-insiders-Second/dp/B08CMF2CQF"},{"title":"Excalidraw — доска для схем на system design интервью","url":"https://excalidraw.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-34/index.md","number":34,"season":1,"slug":"episode-34","tags":["FAANG","собеседования","алгоритмы","system design","карьера в IT"],"title":"#34: Спэшл: Подготовка к FAANG и важность алгоритмов","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-34/"},{"abstract":"Специальный выпуск про устройство IntelliJ IDEA: Александр Пахомов расспрашивает разработчика JetBrains Даниила Овчинникова о том, из чего собран IDE изнутри. Разбирают разделение на платформу и плагины (поддержка Java — тоже плагин), `PSI` как абстрактное синтаксическое дерево «на стероидах» и пайплайн его построения (`Lexer` → парсер → `AST` → `PSI`), устройство автодополнения через вставку скрытого идентификатора `IntelliJ IDEA RULES`, модель экшенов и гетерогенный контекст, инкрементальный репарсинг, многослойное тестирование (парсинг, инспекции, quick fix, completion, property-тесты на `JetCheck`), а также вечный спор о форматах конфигурации (`XML` против `JSON`/`YAML`/`HOCON`) и планы вынести UI на Compose Multiplatform.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/35_IntelliJ_IDEA_ep.mp3","chapters":[{"chunk_id":"episode-35#c0","idx":0,"start":33,"title":"Гость выпуска: Даня Овчинников"},{"chunk_id":"episode-35#c1","idx":1,"start":60,"title":"Строчки кода как метрика и большие рефакторинги"},{"chunk_id":"episode-35#c2","idx":2,"start":312,"title":"Платформа против плагинов"},{"chunk_id":"episode-35#c3","idx":3,"start":457,"title":"Голосовые сообщения в inlay: протёкшая абстракция"},{"chunk_id":"episode-35#c4","idx":4,"start":727,"title":"Что такое PSI"},{"chunk_id":"episode-35#c5","idx":5,"start":952,"title":"Как PSI строится: Lexer, парсер, AST"},{"chunk_id":"episode-35#c6","idx":6,"start":1508,"title":"Автодополнение и «IntelliJ IDEA RULES»"},{"chunk_id":"episode-35#c7","idx":7,"start":1813,"title":"Экшены и гетерогенный контекст"},{"chunk_id":"episode-35#c8","idx":8,"start":2144,"title":"Extension points, Lombok и бандлы"},{"chunk_id":"episode-35#c9","idx":9,"start":2271,"title":"Kotlin против Java в IDEA, переезд на JDK"},{"chunk_id":"episode-35#c10","idx":10,"start":2456,"title":"Как всё это тестируется"},{"chunk_id":"episode-35#c11","idx":11,"start":2917,"title":"XML против JSON, YAML и HOCON"},{"chunk_id":"episode-35#c12","idx":12,"start":3139,"title":"Будущее: Compose Multiplatform и удалённый UI"}],"date":"2023-12-19","duration_sec":3293,"guests":["daniil-ovchinnikov"],"key_takeaways":["В IntelliJ IDEA всё поделено на платформу и плагины: платформа — это общая, языконезависимая логика (например, сам экшен «показать документацию»), а всё языкоспецифичное (включая поддержку Java) вынесено в плагины.","`PSI` (Program Structure Interface) — это абстрактное синтаксическое дерево «на стероидах»: параллельная структура над `AST`, обогащённая семантикой (ссылки с методом `resolve`, типы), по которой IDE подсвечивает ошибки несовместимости типов.","Пайплайн построения дерева в Java-плагине: рукописный `Lexer` регулярками бьёт текст на токены, рукописный парсер собирает из них `AST`-ноды, а поверх `AST` строится `PSI`.","Автодополнение работает через вставку скрытого идентификатора `IntelliJ IDEA RULES` в копию файла: он даёт в дереве ссылку, которую можно `resolve` и предложить все имена в текущем скоупе.","Репарсинг инкрементальный: при вводе перепарсивается не весь файл, а только ближайший блок кода до первых фигурных скобок, поэтому автодополнение и подсветка работают быстро даже в больших файлах.","Экшен — это объект, который знает, как выполниться (по сути лямбда) и как показать себя в UI; по нажатию шортката в keymap находятся все подходящие экшены, каждый решает, доступен ли он в текущем контексте (гетерогенной мапе), затем применяются промоутеры.","В IntelliJ почти нет чистых юнит-тестов: тесты поднимают приложение и проект в памяти; отдельные фикстуры тестируют парсинг (текст → дерево), инспекции и quick fix (`Alt+Enter`), completion, а `property`-тесты на своей библиотеке `JetCheck` проверяют, что репарс блока даёт тот же результат, что и парсинг файла целиком.","Текстовые форматы конфигурации (`XML`) выбирают, чтобы избежать class-loading: вынос всего class-loading из UI-потока в фон сделал стартап IDE почти мгновенным; `XML` предпочтён `Kotlin`-DSL (не требует загрузки классов) и `YAML` (где `no` — Норвегия — парсится как `false`)."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"IntelliJ Platform — открытая платформа для разработки инструментов","url":"https://www.jetbrains.com/opensource/intellij-platform/"},{"title":"IntelliJ Community — исходный код на GitHub","url":"https://github.com/JetBrains/intellij-community"},{"title":"Grammar-Kit — генератор лексера, парсера и PSI по BNF","url":"https://github.com/JetBrains/Grammar-Kit"},{"title":"jetCheck — property-based тестирование от JetBrains","url":"https://github.com/jetbrains/jetCheck"}],"md_url":"https://apkhmv.xyz/podcast/episode-35/index.md","number":35,"season":1,"slug":"episode-35","tags":["IntelliJ IDEA","устройство IDE","парсеры и PSI","тестирование","разработка плагинов"],"title":"#35: IntelliJ IDEA: самый популярный редактор для Java","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-35/"},{"abstract":"Первый «хардкорный» выпуск: Александр Пахомов и Максим Кита (разработчик ClickHouse, контрибьютор компилятора Swift, коммитер LLVM) разбирают, как устроен современный компилятор — фронтенд, middle-end и бэкенд, `LLVM IR` в `SSA`-форме, basic-блоки и phi-ноды. По пути — почему на C++ тяжело писать без санитайзеров и `clang-tidy`, чем силён `borrow checker` в Rust, что такое compile-time-полиморфизм и `if constexpr`, как деление превращается в умножение, и как реально законтрибьютить в LLVM и компилятор Swift.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/36_Rust_C_LLVM_Clickhouse.mp3","chapters":[{"chunk_id":"episode-36#c0","idx":0,"start":8,"title":"Вступление: хардкорный выпуск с Максимом Кита"},{"chunk_id":"episode-36#c1","idx":1,"start":89,"title":"Векторные базы, RAG-агенты и borrow checker в Rust"},{"chunk_id":"episode-36#c2","idx":2,"start":213,"title":"Рефакторинг мьютексов в ClickHouse и thread safety"},{"chunk_id":"episode-36#c3","idx":3,"start":584,"title":"Почему на C++ тяжело: санитайзеры, coverage, clang-tidy"},{"chunk_id":"episode-36#c4","idx":4,"start":840,"title":"if constexpr, SFINAE и compile-time-полиморфизм"},{"chunk_id":"episode-36#c5","idx":5,"start":1559,"title":"JIT, портируемый бинарник и инструкции SSE/AVX"},{"chunk_id":"episode-36#c6","idx":6,"start":1736,"title":"M-процессоры, ARM и модель стоимостей"},{"chunk_id":"episode-36#c7","idx":7,"start":1991,"title":"Как правильно мерить перформанс: до и после"},{"chunk_id":"episode-36#c8","idx":8,"start":2346,"title":"Устройство компилятора: frontend, middle-end, backend"},{"chunk_id":"episode-36#c9","idx":9,"start":2654,"title":"LLVM IR, SSA, basic-блоки и phi-ноды"},{"chunk_id":"episode-36#c10","idx":10,"start":3630,"title":"Как контрибьютить в компилятор Swift"},{"chunk_id":"episode-36#c11","idx":11,"start":3918,"title":"Книги по компиляторостроению и код LLVM"},{"chunk_id":"episode-36#c12","idx":12,"start":4819,"title":"Деление через умножение и трюки оптимизатора"},{"chunk_id":"episode-36#c13","idx":13,"start":5023,"title":"Пакетные менеджеры C++, сабмодули и версионирование"},{"chunk_id":"episode-36#c14","idx":14,"start":5715,"title":"Как законтрибьютить в LLVM и инструмент Alive"},{"chunk_id":"episode-36#c15","idx":15,"start":6564,"title":"Зачем контрибьютить в сложные проекты"}],"date":"2023-12-29","duration_sec":6832,"guests":["maxim-kita"],"key_takeaways":["Компилятор состоит из трёх слоёв: фронтенд переводит язык в промежуточное представление, middle-end оптимизирует его backend-агностично, а бэкенд генерирует ассемблер под конкретную архитектуру; `LLVM` — это middle-end плюс бэкенд, а фронтенды (`clang`, Rust, Swift) отдают ему `LLVM IR`.","`LLVM IR` — это ассемблер в форме `SSA` (static single assignment) с бесконечным числом регистров: код разбит на basic-блоки, а phi-ноды выбирают значение регистра в зависимости от того, из какой ветки пришло управление.","На C++ трудно писать безопасно: нужны юнит-, интеграционные и стресс-тесты, фаззеры с покрытием и прогон под всеми санитайзерами (address, memory, thread, undefined behavior), плюс включённые ворнинги и `clang-tidy`.","Compile-time-полиморфизм (`if constexpr`, шаблонное метапрограммирование, `SFINAE`) генерирует специализации на этапе компиляции без runtime-оверхеда; в ClickHouse так диспетчеризуют операции над колонками разных типов.","Деление — дорогая операция (64-битное может занимать порядка сотни тактов), поэтому компилятор заменяет деление на константу умножением и сдвигом; почти все операции выражаются через `and` и `not`.","Перформанс-тесты надёжнее гонять, сравнивая версию «до» и «после» одновременно на одной машине, а не два прогона в разные дни: так исключаются шумы окружения, а нестабильные тесты видно сразу.","Alive (`alive2`) верифицирует, что оптимизация `LLVM IR` корректна для всех входов — это как `TLA+` для распределённых систем, только для трансформаций компилятора; к пул-реквестам в LLVM прикладывают alive-proof.","Контрибьютить в LLVM просто: вся разработка на GitHub, есть лейбл `good first issue` и теги вроде performance/vectorizer; недавно процесс переехал с Phabricator на pull-request'ы, а изменение в мастере тут же подтягивается сабмодулем в ClickHouse."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"LLVM","url":"https://llvm.org"},{"title":"ClickHouse","url":"https://clickhouse.com"},{"title":"Swift","url":"https://www.swift.org"},{"title":"Clang Thread Safety Analysis","url":"https://clang.llvm.org/docs/ThreadSafetyAnalysis.html"},{"title":"LLVM Kaleidoscope: My First Language Frontend","url":"https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/"},{"title":"Alive2 — верификация оптимизаций LLVM","url":"https://github.com/AliveToolkit/alive2"},{"title":"Agner Fog — оптимизационные мануалы","url":"https://www.agner.org/optimize/"}],"md_url":"https://apkhmv.xyz/podcast/episode-36/index.md","number":36,"season":1,"slug":"episode-36","tags":["LLVM","компиляторы","Rust","C++","open source"],"title":"#36: LLVM: Rust, современный C++, как законтрибьютить","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-36/"},{"abstract":"Александр Пахомов зовёт в гости Вастрика (vas3k) — технологического блогера и основателя Вастрик-клуба — чтобы разобрать, на каком стеке живут его pet-проекты и почему инженерная простота — это не тупость, а опыт. Гость рассказывает, как из ЖЖ вырос блог на `Django` с `Postgres` в `Docker`, деплоем по `SSH` и одной машиной на Hetzner под `Cloudflare`, и объясняет главный тезис: код для себя и код на работе решают противоположные задачи. Финал — манифест против SPA и ода `HTMX` как «расширенному HTML» для бэкендеров.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/37_CEO_OF_HTMX.mp3","chapters":[{"chunk_id":"episode-37#c0","idx":0,"start":0,"title":"Холодный старт: я ненавижу SPA"},{"chunk_id":"episode-37#c1","idx":1,"start":114,"title":"Вступление: гость — vas3k"},{"chunk_id":"episode-37#c2","idx":2,"start":273,"title":"Первая версия Вастрик-блога: ЖЖ, CMS, Django"},{"chunk_id":"episode-37#c3","idx":3,"start":364,"title":"Таймлайн и инди-веб"},{"chunk_id":"episode-37#c4","idx":4,"start":516,"title":"Эншитификация платформ и закрытые API"},{"chunk_id":"episode-37#c5","idx":5,"start":714,"title":"Стек блога: Django, Markdown, тексты через БД"},{"chunk_id":"episode-37#c6","idx":6,"start":1254,"title":"Cloudflare: кэш, DDoS, SSL"},{"chunk_id":"episode-37#c7","idx":7,"start":1487,"title":"Sentry: error tracker против логеров"},{"chunk_id":"episode-37#c8","idx":8,"start":1672,"title":"Одна тачка, Docker Compose и деплой по SSH"},{"chunk_id":"episode-37#c9","idx":9,"start":2147,"title":"Дисклеймер: pet-проект против работы"},{"chunk_id":"episode-37#c10","idx":10,"start":2335,"title":"Managed Postgres, Supabase и аналитика"},{"chunk_id":"episode-37#c11","idx":11,"start":2883,"title":"Redis, async.io и многопоточность в Python"},{"chunk_id":"episode-37#c12","idx":12,"start":3347,"title":"Философия инди-хакинга"},{"chunk_id":"episode-37#c13","idx":13,"start":4133,"title":"Скиллы инди-хакинга против работы"},{"chunk_id":"episode-37#c14","idx":14,"start":4895,"title":"Django и Postgres: бери, что знаешь"},{"chunk_id":"episode-37#c15","idx":15,"start":5107,"title":"Фронтенд без SPA: Vue поверх HTML и HTMX"}],"date":"2024-02-16","duration_sec":6467,"guests":["vas3k"],"key_takeaways":["Код для pet-проекта и код на работе преследуют противоположные цели: первый ты пишешь, чтобы его было удобно поддерживать тебе будущему, второй — чтобы он «бил по рукам» многим другим людям после тебя.","Инди-стек Вастрик-клуба намеренно примитивен: `Django` + `Postgres` в `Docker Compose` на одной машине Hetzner, деплой по `SSH` из GitHub Actions, `volume` с базой на том же диске и ежедневный бэкап.","`Cloudflare` перед сервером закрывает кэширование статики, защиту от DDoS, бесплатный SSL и мини-аналитику — так блог переживал сотни тысяч просмотров в сутки на самой маленькой машине.","Ошибки продакшена ловит `Sentry` как error tracker (глобальный «try-catch» поверх приложения), а не как логер; в Java-мире его реже используют из-за культа настраиваемых логеров.","Выбор технологии почти не влияет на успех pet-проекта, а вот навредить может: бери язык, на котором пишешь «не приходя в сознание», иначе утонешь в проблемах новичка и забросишь проект.","Большие системы почти никогда не проектируются с нуля — они вырастают из «одноклеточного» MVP, который сначала проверяет гипотезу, а потом переписывается командой набело.","Инди-хакинг — это компания одного человека, которая делает десятки дешёвых продуктов в год ради одного выстрелившего; деньги приносит решение чужих проблем, а не сложность инфраструктуры.","`HTMX` — это «расширенный HTML»: любой тег может слать любой HTTP-запрос и получать в ответ кусок HTML для замены, поэтому интерактивность живёт поверх честных страниц без SPA и «фестиваля спиннеров»."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Вастрик-блог","url":"https://vas3k.blog"},{"title":"Вастрик-клуб","url":"https://vas3k.club"},{"title":"HTMX","url":"https://htmx.org"},{"title":"Supabase — self-hosted Postgres","url":"https://supabase.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-37/index.md","number":37,"season":1,"slug":"episode-37","tags":["инди-хакинг","веб-разработка","HTMX","pet-проекты","деплой"],"title":"#37: vas3k: CEO OF HTMX","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-37/"},{"abstract":"Александр Пахомов и коммитер ClickHouse Максим Кита разбирают, почему самая популярная аналитическая база данных не тормозит: от разницы OLAP и OLTP и колоночного хранения до движков семейства `MergeTree`, агрегатных функций, проекций и `FINAL`. Во второй половине — инженерная культура ClickHouse: stateless-тесты вместо моков, фаззинг, Jepsen и `TLA+`, интроспекция и профилирование запросов через flame graph, а также разбор инцидента с высокой конкурентностью у одного крупного клиента, где глобальный mutex в контексте заменили на read-write.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/38_Clickhouse.mp3","chapters":[{"chunk_id":"episode-38#c0","idx":0,"start":7,"title":"Вступление: вторая серия про ClickHouse"},{"chunk_id":"episode-38#c1","idx":1,"start":90,"title":"История с тормозящей базой на проде"},{"chunk_id":"episode-38#c2","idx":2,"start":172,"title":"OLAP против OLTP: колоночное хранение"},{"chunk_id":"episode-38#c3","idx":3,"start":631,"title":"Сжатие данных и два множителя производительности"},{"chunk_id":"episode-38#c4","idx":4,"start":1035,"title":"HTAP, single store и Change Data Capture"},{"chunk_id":"episode-38#c5","idx":5,"start":1591,"title":"Философия ClickHouse: рамки ради оптимизации"},{"chunk_id":"episode-38#c6","idx":6,"start":1890,"title":"Агрегатные функции как тип данных"},{"chunk_id":"episode-38#c7","idx":7,"start":2211,"title":"MergeTree, sparse-индекс и FINAL"},{"chunk_id":"episode-38#c8","idx":8,"start":3072,"title":"Кликстрим, топ-5 сайтов и преагрегаты"},{"chunk_id":"episode-38#c9","idx":9,"start":3105,"title":"Проекции против материализованных представлений"},{"chunk_id":"episode-38#c10","idx":10,"start":3714,"title":"Транзакции в ClickHouse: Jepsen и TLA+"},{"chunk_id":"episode-38#c11","idx":11,"start":4568,"title":"Баги в алгоритмах: компараторы и бинарный поиск"},{"chunk_id":"episode-38#c12","idx":12,"start":4808,"title":"Тестирование: stateless-тесты вместо моков"},{"chunk_id":"episode-38#c13","idx":13,"start":5342,"title":"Memory leak с логерами и интроспекция"},{"chunk_id":"episode-38#c14","idx":14,"start":5893,"title":"Профилирование запросов и flame graph"},{"chunk_id":"episode-38#c15","idx":15,"start":6786,"title":"Физический план, executor и work-stealing"},{"chunk_id":"episode-38#c16","idx":16,"start":7513,"title":"Инцидент TinyBird: Critical Sections Bound"},{"chunk_id":"episode-38#c17","idx":17,"start":8441,"title":"Инженерная культура ClickHouse и контрибьютинг"}],"date":"2024-04-01","duration_sec":9361,"guests":["maxim-kita"],"key_takeaways":["OLAP-базы хранят данные колоночно (структура массивов вместо массива структур), поэтому читают только нужные колонки и на аналитических запросах бывают в сотни-тысячи раз быстрее строковых OLTP-баз.","Похожие данные в одной колонке сжимаются кратно лучше, чем разнородный профиль строки целиком, — это второй множитель производительности после сокращения объёма чтения.","ClickHouse сознательно отказывается от универсальности (не претендует на OLTP/HTAP): жёсткие рамки для пользователя дают движку больше пространства для оптимизации.","Движки семейства `MergeTree` (`ReplacingMergeTree`, `AggregatingMergeTree`, `SummingMergeTree`) применяют логику к строкам с одинаковым первичным ключом во время фонового merge; `FINAL` применяет её на лету при чтении.","Агрегатная функция в ClickHouse — это тип данных с методами `create`/`merge`/`finalize`; `merge` двух состояний позволяет агрегировать в много потоков и хранить преагрегаты как в `AggregatingMergeTree`.","Проекция отличается от материализованного представления тем, что консистентна и лежит в том же куске данных, поэтому оптимизатор может прозрачно читать запрос из неё вместо основной таблицы.","ClickHouse тестируют не юнит-тестами с моками, а stateless-тестами через SQL-интерфейс плюс интроспекция (сколько прочитано байт, строк, засечек); всё гоняется под санитайзерами и фаззерами.","Инцидент TinyBird (10 000 запросов/сек) — это `Critical Sections Bound`: глобальный mutex контекста упирался в шедулер; починили, разделив mutex на глобальный и локальный и заменив на read-write."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"ClickHouse — колоночная аналитическая база данных","url":"https://clickhouse.com"},{"title":"TinyBird — real-time аналитика на ClickHouse","url":"https://www.tinybird.co"},{"title":"Jepsen — тестирование распределённых систем","url":"https://jepsen.io"}],"md_url":"https://apkhmv.xyz/podcast/episode-38/index.md","number":38,"season":1,"slug":"episode-38","tags":["ClickHouse","базы данных","OLAP","производительность","тестирование"],"title":"#38: Почему ClickHouse не тормозит","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-38/"},{"abstract":"Александр Пахомов и Иван Ямщиков (профессор ИИ в THWS, Вюрцбург) уходят от техники в сторону науки и образования: как устроена академическая карьера в Европе (аспирантура — постдок — профессура) и почему письмо незнакомому учёному способно изменить траекторию. Через эмпирический принцип POSIWID («смысл системы в том, что она делает») Иван разбирает, чему на самом деле учит школа, а в финале выводит систему профессионального роста программиста: любопытство джуна, пет-проекты мидла и менторство сеньора.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/39_LLMs_Science_Education.mp3","chapters":[{"chunk_id":"episode-39#c0","idx":0,"start":14,"title":"Вступление: не совсем технический выпуск"},{"chunk_id":"episode-39#c1","idx":1,"start":71,"title":"Как Александр пришёл к подкастам и «Проветримся»"},{"chunk_id":"episode-39#c2","idx":2,"start":414,"title":"«Нейронная оборона» и путь Ивана в генеративные сети"},{"chunk_id":"episode-39#c3","idx":3,"start":770,"title":"Юрген Йост: как учёный видит горящих людей"},{"chunk_id":"episode-39#c4","idx":4,"start":1085,"title":"Письмо незнакомому учёному как способ сменить траекторию"},{"chunk_id":"episode-39#c5","idx":5,"start":1129,"title":"Академическая карьера в ЕС: аспирантура и постдок"},{"chunk_id":"episode-39#c6","idx":6,"start":1828,"title":"Будущее есть везде: против линейного мышления"},{"chunk_id":"episode-39#c7","idx":7,"start":2216,"title":"Школьная травма: чтение, зубрёжка дат"},{"chunk_id":"episode-39#c8","idx":8,"start":2454,"title":"Принцип POSIWID: смысл системы в том, что она делает"},{"chunk_id":"episode-39#c9","idx":9,"start":2687,"title":"Чему учит школьный звонок и «Отупляя нас»"},{"chunk_id":"episode-39#c10","idx":10,"start":3477,"title":"Индия против Европы: ответы или вопросы"},{"chunk_id":"episode-39#c11","idx":11,"start":3631,"title":"Монтессори и воспитание агентности"},{"chunk_id":"episode-39#c12","idx":12,"start":4095,"title":"Технооптимизм и три совета, как учиться после вуза"},{"chunk_id":"episode-39#c13","idx":13,"start":4324,"title":"Любопытство, пет-проекты, сообщество"},{"chunk_id":"episode-39#c14","idx":14,"start":4844,"title":"Джун, мидл, сеньор: система роста"},{"chunk_id":"episode-39#c15","idx":15,"start":5424,"title":"Спорт, дозирование нагрузки и прощание"}],"date":"2024-04-15","duration_sec":5610,"guests":["ivan-yamshchikov"],"key_takeaways":["Написать письмо практически любому учёному сегодня несложно, и по тому, как он отвечает, видно, выйдет ли совместная работа; это реальный способ сменить карьерную траекторию.","Академическая карьера в ЕС — это ступени аспирантура (≈4 года, зарплата выше медианной) → постдок (переезды каждые 1–2 года) → профессура как почти пожизненное трудоустройство с максимальной интеллектуальной свободой.","Принцип POSIWID Стаффорда Бира (`point of the system is what it does`) велит судить о системе по её результатам, а не по декларируемым целям: если школа отбивает желание учиться, значит в этом её фактический смысл.","Будущее наступает всегда и везде; каким будет ваше личное будущее, зависит от вас, а не от свойств места или времени — линейное «резюме-мышление» этому мешает.","Методика Монтессори растит агентность через три опоры: заниматься задачей столько, сколько нужно; самому выстраивать социальные связи; убирать за собой — дисциплина не инвазивная, а естественная.","Каждый человек на нелюбимой работе делает беднее всех вокруг: меньше создаёт ценности, медленнее растёт, платит меньше налогов и добавляет обществу проблем.","Система роста программиста: джуна отличает любопытство («глаза горят»), мидла — способность самому довести пет-проект от и до, сеньора — умение оценивать чужие проекты и собирать вокруг себя комьюнити.","Пет-проект стоит затевать не ради одного фреймворка, а когда рядом накопился целый кластер смежных тем, про каждую из которых знаешь шапочно, — тогда один проект закрывает сразу несколько лакун."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Подкаст «Проветримся» (подкаст Ивана Ямщикова)","url":"https://provetrimsya.mave.digital"},{"title":"Learn How to Learn — курс на Coursera","url":"https://www.coursera.org/learn/learning-how-to-learn"},{"title":"Sir Ken Robinson: How to escape education's death valley (TED)","url":"https://www.ted.com/talks/sir_ken_robinson_how_to_escape_education_s_death_valley"},{"title":"John Taylor Gatto — «Dumbing Us Down»","url":"https://newsociety.com/books/d/dumbing-us-down-25th-anniversary-edition"}],"md_url":"https://apkhmv.xyz/podcast/episode-39/index.md","number":39,"season":1,"slug":"episode-39","tags":["образование","академическая карьера","профессиональный рост","генеративные модели","лайфхаки обучения"],"title":"#39: Иван Ямщиков: Наука, Образование и лайфхаки","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-39/"},{"abstract":"Первый оффлайн-выпуск «Тысячи фичей»: в гостях у Александра Пахомова — Илья Ильиных, автор YouTube-канала «Куда войти?». Почти два часа они разбирают эргономику рабочего места (посадка, монитор, сплит-клавиатуры, механические свитчи, слепая печать), путь от IntelliJ IDEA через Emacs к `NeoVim` и то, почему модальность и Unix-философия редактора заставляют программиста по-настоящему познакомиться со своими инструментами. Во второй половине — большой разговор про TDD как способ проектирования и «обуздания» легаси, про моки и интеграционные тесты и про то, стоит ли программировать по выходным.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/neovim_offline.m4a","chapters":[{"chunk_id":"episode-40#c0","idx":0,"start":0,"title":"Холодный открывок и подводка"},{"chunk_id":"episode-40#c1","idx":1,"start":112,"title":"Здоровье и эргономика программиста"},{"chunk_id":"episode-40#c2","idx":2,"start":286,"title":"Монитор: высота, дистанция, один экран"},{"chunk_id":"episode-40#c3","idx":3,"start":751,"title":"Сплит-клавиатуры и механические свитчи"},{"chunk_id":"episode-40#c4","idx":4,"start":1165,"title":"Перерывы, спорт и «дать мозгу поварить»"},{"chunk_id":"episode-40#c5","idx":5,"start":1664,"title":"Слепая печать как навык"},{"chunk_id":"episode-40#c6","idx":6,"start":2195,"title":"Комбинации клавиш и страдающий мизинец"},{"chunk_id":"episode-40#c7","idx":7,"start":2480,"title":"Emacs, Evil и путь к Vim"},{"chunk_id":"episode-40#c8","idx":8,"start":2937,"title":"Что такое NeoVim: модальность"},{"chunk_id":"episode-40#c9","idx":9,"start":3352,"title":"Unix-философия и композиция плагинов"},{"chunk_id":"episode-40#c10","idx":10,"start":3862,"title":"dotfiles в git и переносимая среда"},{"chunk_id":"episode-40#c11","idx":11,"start":3974,"title":"«Красноглазики»: споры вокруг Vim"},{"chunk_id":"episode-40#c12","idx":12,"start":4299,"title":"Форматирование в Java и знакомство с инструментами"},{"chunk_id":"episode-40#c13","idx":13,"start":4865,"title":"TDD: писать тесты вперёд даже в легаси"},{"chunk_id":"episode-40#c14","idx":14,"start":5383,"title":"TDD как индукция и код как авторский почерк"},{"chunk_id":"episode-40#c15","idx":15,"start":6179,"title":"Переработки, work-life balance и заключение"}],"date":"2024-04-21","duration_sec":6928,"guests":["ilya-ilyinykh"],"key_takeaways":["Здоровый программист — тот, кто задумался о своём здоровье: важнее спорта сделать эргономичным само рабочее место, где ты проводишь 8+ часов (монитор на уровень глаз и подальше, один экран, подставка под кисти).","Сплит-клавиатура разводит половины под каждую руку, распрямляя плечи и открывая диафрагму, — говорить на созвонах становится легче.","Слепая печать нужна не ради скорости, а чтобы не перефокусировать глаза между монитором и клавиатурой (это как «челночный бег» для глазных мышц) и чтобы вообще сесть за сплит.","Модальность `Vim` переиспользует удобные клавиши home row (`h`, `j`, `k`, `l`) и для ввода текста, и для навигации; в немодальном редакторе навигации достаётся неудобное пространство под мизинец.","`NeoVim` устроен по Unix-философии: плагины на `Lua` композируются между собой и переиспользуют общий UX (`quickfix`-листы, `Telescope`); выделенный текст можно прогнать через любую bash-команду (`!`) без плагинов.","Конфиг-`dotfiles` лежат в git, версионируются и клонируются на сервер — и там разворачивается та же среда разработки; в Java нет консольного форматтера, а `gofmt`/`spotless` показывают, как это должно работать.","TDD помогает даже в жёстком легаси (по книге «Working Effectively with Legacy Code»): тесты изолируют изменения, формулируют требование как код и превращают разработку в индукцию — «рисуешь по одной линии», а не строишь весь замок в голове.","Хороший код с достаточными тестами и зелёным пайплайном самоценен, как авторский почерк: если чек-стайл и тесты проходят, придираться к стилю не стоит (так же льют код разработчики ClickHouse)."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"«Куда войти?» — YouTube-канал Ильи Ильиных","url":"https://www.youtube.com/@kydavoiti"},{"title":"obs.nvim — Obsidian-подобный плагин Ильи для NeoVim","url":"https://github.com/IlyasYOY/obs.nvim"},{"title":"MonkeyType — тренажёр скоростной печати","url":"https://monkeytype.com"},{"title":"TypingClub — тренажёр слепой печати","url":"https://www.typingclub.com"},{"title":"Better Display — High-DPI-масштабирование внешних мониторов на Mac","url":"https://betterdisplay.pro"},{"title":"Spotless — форматтер и линтер для сборки (в т.ч. Java)","url":"https://github.com/diffplug/spotless"},{"title":"«Working Effectively with Legacy Code», Michael Feathers","url":"https://www.oreilly.com/library/view/working-effectively-with/0131177052/"},{"title":"«Test-Driven Development: By Example», Kent Beck","url":"https://www.oreilly.com/library/view/test-driven-development/0321146530/"},{"title":"«Growing Object-Oriented Software, Guided by Tests»","url":"http://www.growing-object-oriented-software.com/"}],"md_url":"https://apkhmv.xyz/podcast/episode-40/index.md","number":40,"season":1,"slug":"episode-40","tags":["эргономика","NeoVim","TDD","слепая печать","тестирование"],"title":"#40: Спэшл: Эргономика, NeoVim и TDD","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-40/"},{"abstract":"Александр Пахомов и Андрей Васнецов (CTO и сооснователь Qdrant) разбирают, как устроен векторный поиск и почему Qdrant — это поисковый движок, а не «векторная база данных». По пути: откуда берутся эмбеддинги (word2vec, BERT, ONNX) и какими свойствами обладают векторы; почему точный индекс не работает в размерности полторы тысячи и как вместо него применяется приближённый `HNSW`; в чём киллер-фича Qdrant — фильтруемый `HNSW` со вторичными индексами; как всё это шардируется и реплицируется поверх `RAFT`; и большой финальный блок про Rust — от безопасного рефакторинга и `cargo` до вставок на ассемблере, квантизации и `io_uring`.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/41_Qdrant.mp3","chapters":[{"chunk_id":"episode-41#c0","idx":0,"start":12,"title":"Вступление: гость и почему это не «векторная база»"},{"chunk_id":"episode-41#c1","idx":1,"start":117,"title":"Что такое векторный поиск: Google Lens и эмбеддинги"},{"chunk_id":"episode-41#c2","idx":2,"start":673,"title":"Векторы, метрики и косинусное расстояние"},{"chunk_id":"episode-41#c3","idx":3,"start":1169,"title":"Слова в векторы: word2vec, BERT, ONNX"},{"chunk_id":"episode-41#c4","idx":4,"start":1678,"title":"В чём проблема: 6 КБ на эмбеддинг и брутфорс"},{"chunk_id":"episode-41#c5","idx":5,"start":2122,"title":"Проклятие размерности и приближённый поиск HNSW"},{"chunk_id":"episode-41#c6","idx":6,"start":2616,"title":"Киллер-фича: фильтруемый HNSW и вторичные индексы"},{"chunk_id":"episode-41#c7","idx":7,"start":3482,"title":"Распределённость: шарды, репликации и RAFT"},{"chunk_id":"episode-41#c8","idx":8,"start":3988,"title":"Поисковый движок как вторичное хранилище"},{"chunk_id":"episode-41#c9","idx":9,"start":4281,"title":"Тестирование распределёнки и local mode"},{"chunk_id":"episode-41#c10","idx":10,"start":4637,"title":"REST против gRPC и боль генерации OpenAPI-клиентов"},{"chunk_id":"episode-41#c11","idx":11,"start":5428,"title":"Производительность и бенчмарки"},{"chunk_id":"episode-41#c12","idx":12,"start":5919,"title":"Почему Rust: рефакторинг, гарантии и порог входа"},{"chunk_id":"episode-41#c13","idx":13,"start":7731,"title":"Ассемблер, квантизация, io_uring и latency памяти"},{"chunk_id":"episode-41#c14","idx":14,"start":8829,"title":"Vision продукта и контрибьютинг в open source"},{"chunk_id":"episode-41#c15","idx":15,"start":9437,"title":"Совет для карьеры: сначала проблема, потом демка"}],"date":"2024-05-29","duration_sec":9678,"guests":["andrey-vasnetsov"],"key_takeaways":["Эмбеддинг — это машинно-читаемое представление объекта (текста, картинки, аудио): близость векторов по выбранной метрике означает семантическую близость, и сравнивать всегда нужно относительно (скор `0.7` интереснее `0.6`), а не по абсолютному значению.","Метрику (`cosine`, евклидово расстояние, `dot product`) выбирают под то, на чём обучалась нейросеть; на практике удобнее всего `dot product` — он самый дешёвый в вычислении.","Один эмбеддинг OpenAI — это ~1500 float'ов ≈ 6 КБ; на миллионе записей это уже ~6 ГБ, которые ради скорости приходится держать в RAM.","Точный индекс (`B-tree`, геохэш) ломается о «проклятие размерности», поэтому применяется приближённый поиск `ANN` на графе `HNSW` (Hierarchical Navigable Small Worlds) — жадный обход с несколькими лучами, сложность ~`O(log n)`.","Киллер-фича Qdrant — фильтруемый `HNSW`: векторный индекс знает про вторичные индексы (цена, локация) и достраивает дополнительные рёбра между отфильтрованными вершинами, что дешевле, чем join-индекс, и не ломается на низкой кардинальности (там просто `fullscan`).","Qdrant — поисковый движок, а не source-of-truth: его гарантии — скорость, масштабирование и отказоустойчивость (как у Elasticsearch), а в `RAFT`-консенсусе хранится только маленькая, но важная мета-информация о шардах, не сами векторы.","Rust выбран потому, что это system programming language для программ, которыми пользуются другие программы; компилятор даёт безопасный рефакторинг (паттерн-матчинг находит все места правки) и гарантии против data race и segfault ценой высокого порога входа и медленной компиляции.","Самый горячий код — вычисление `dot product` — написан на ассемблере под каждую архитектуру (даёт ~10× к наивной реализации); а `io_uring` позволяет на этапе рескоринга слать тысячи параллельных чтений к диску одним процессом, снижая latency одного запроса."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Qdrant — векторный поисковый движок на Rust","url":"https://qdrant.tech"},{"title":"Qdrant на GitHub","url":"https://github.com/qdrant/qdrant"},{"title":"ONNX — Open Neural Network Exchange","url":"https://onnx.ai"},{"title":"Tokio — асинхронный рантайм для Rust","url":"https://tokio.rs"},{"title":"Rayon — data-parallelism для Rust","url":"https://github.com/rayon-rs/rayon"},{"title":"io_uring (эффективный асинхронный I/O в Linux)","url":"https://en.wikipedia.org/wiki/Io_uring"}],"md_url":"https://apkhmv.xyz/podcast/episode-41/index.md","number":41,"season":1,"slug":"episode-41","tags":["векторный поиск","базы данных","Rust","HNSW и эмбеддинги","распределённые системы"],"title":"#41: Qdrant: Векторная база данных на Rust","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-41/"},{"abstract":"Александр Пахомов и Мекан Байрыев (специалист по безопасности веб-приложений в Mad Devs, автор YouTube-канала MrCyberSec) проходят путь атакующего от IP-адреса до `root`: сканирование портов `nmap`, перебор директорий и API-эндпоинтов, SQL-инъекции, хранение паролей и хеширование, reverse shell и эскалацию привилегий через SUID-биты, capabilities и cron. По ходу — типовые кейсы (утечка данных через незащищённую ручку, побайтовое чтение `id_rsa` через хеш-оракул, бэкдор в цепочке поставок и история с `xz`), подборка ресурсов для обучения (Hack The Box, TryHackMe, CTF) и чек-лист гигиены для бэкенд-разработчика, сводящийся к принципу минимальных привилегий.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/42_Cybersec.mp3","chapters":[{"chunk_id":"episode-42#c0","idx":0,"start":0,"title":"Вступление и знакомство с гостем"},{"chunk_id":"episode-42#c1","idx":1,"start":196,"title":"Разведка: nmap, порты и баннеры сервисов"},{"chunk_id":"episode-42#c2","idx":2,"start":504,"title":"Порт-нокинг и сокрытие сервисов"},{"chunk_id":"episode-42#c3","idx":3,"start":786,"title":"Перебор директорий и API-эндпоинтов"},{"chunk_id":"episode-42#c4","idx":4,"start":1276,"title":"OpenAPI/Swagger, dev- и QA-поддомены"},{"chunk_id":"episode-42#c5","idx":5,"start":1563,"title":"Broken access control и утечки данных"},{"chunk_id":"episode-42#c6","idx":6,"start":1770,"title":"SQL-инъекции: от sleep до дампа базы"},{"chunk_id":"episode-42#c7","idx":7,"start":2066,"title":"Хеширование паролей: MD5, bcrypt, соль"},{"chunk_id":"episode-42#c8","idx":8,"start":2809,"title":"RCE и reverse shell"},{"chunk_id":"episode-42#c9","idx":9,"start":3191,"title":"Эскалация привилегий до root"},{"chunk_id":"episode-42#c10","idx":10,"start":3812,"title":"SUID, capabilities и цепочки уязвимостей"},{"chunk_id":"episode-42#c11","idx":11,"start":4296,"title":"Цепочка поставок и бэкдоры: история xz"},{"chunk_id":"episode-42#c12","idx":12,"start":4460,"title":"Ресурсы, книги, Hack The Box и CTF"},{"chunk_id":"episode-42#c13","idx":13,"start":4911,"title":"Чек-лист бэкендера и менеджмент секретов"}],"date":"2024-06-14","duration_sec":5572,"guests":["mekan-bairyev"],"key_takeaways":["Разведка начинается с `nmap`: по открытым портам и баннерам сервисов (через `netcat`) видны версии ПО (`OpenSSH`, `Redis`, `nginx`, `Spring Boot`), а по ним — известные уязвимости; порт-нокинг прячет порт до правильной последовательности «стуков».","Перебор директорий и эндпоинтов (`GoBuster`, `ffuf`, `KiteRunner`) по словарям находит скрытые ручки по нестандартному ответу (`401`/`200` среди `404`); rate-limiting лишь замедляет атаку, но не спасает.","Найденная документация OpenAPI/Swagger или dev/QA-поддомен (через фаззинг субдоменов) — лучший подарок атакующему: учебный кейс — ручка без авторизации отдавала имена, хеши паролей и другие клиентские данные (broken access control).","SQL-инъекция через конкатенацию пользовательского ввода в запрос позволяет читать таблицы (`information_schema`), добавлять пользователей, а иногда выполнять код и читать файлы (`LOAD_EXTENSION` в SQLite, `LOAD_FILE` в MySQL); защита — prepared statements и валидация ввода.","`MD5` для паролей брутфорсится мгновенно; нужен медленный алгоритм (`bcrypt`) с солью и пароли от 12–16 символов, но утёкшие базы «хеш → пароль» обнуляют даже стойкий пароль, если он туда попал.","`RCE` реализуется через reverse shell: атакующий слушает `netcat` на открытом наружу порту (80/443), а на жертве перенаправляет `/bin/bash` в TCP-поток; без исходящего доступа команды гоняют по одной через саму уязвимость.","Эскалация до `root` — это цепочка: мисконфигурация `sudo`, SUID-бит на кастомной утилите, capabilities, перехват Python-импорта из writable-директории в cron; `LinPEAS`/`WinPEAS` автоматически подсвечивают такие векторы.","Базовая гигиена бэкендера сводится к принципу минимальных привилегий (least privilege): по умолчанию нет доступа ни к чему, права выдаются гранулярно; CI-боту нельзя давать `root`, а секреты и БД надо разграничивать между сервисами."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"MrCyberSec — YouTube-канал Мекана Байрыева","url":"https://www.youtube.com/@MrCyberSec"},{"title":"Hack The Box","url":"https://www.hackthebox.com"},{"title":"TryHackMe","url":"https://tryhackme.com"},{"title":"Root Me","url":"https://www.root-me.org"},{"title":"CTFtime — агрегатор CTF-соревнований","url":"https://ctftime.org"},{"title":"picoCTF","url":"https://picoctf.org"},{"title":"OWASP Top 10","url":"https://owasp.org/www-project-top-ten/"},{"title":"Подкаст «Смени пароль» (Лаборатория Касперского)","url":"https://podcast.smenipowl.ru"}],"md_url":"https://apkhmv.xyz/podcast/episode-42/index.md","number":42,"season":1,"slug":"episode-42","tags":["кибербезопасность","SQL-инъекции","reverse shell","хеширование паролей","эскалация привилегий"],"title":"#42: MrCyberSec: что нужно знать про безопасность","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-42/"},{"abstract":"Александр Пахомов и Максим Кита (ментейнер LLVM, коммитер ClickHouse) разбирают Just-In-Time-компиляцию: сначала на классическом примере JVM, где JIT девиртуализирует вызовы, инлайнит `get` у `ArrayList` и убирает bound-check, а потом — как тот же приём работает в базах данных. На примере ClickHouse, Postgres и YDB они показывают, как выполнение выражений над `union`-типами компилируется в одну плотную функцию через `LLVM IR`, чем OLAP-компиляция отличается от OLTP и почему `JIT` — это ещё и постоянный источник проблем с безопасностью и падениями.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/43_JIT.mp3","chapters":[{"chunk_id":"episode-43#c0","idx":0,"start":8,"title":"Вступление: JIT и гость Максим Кита"},{"chunk_id":"episode-43#c1","idx":1,"start":65,"title":"JIT: что это и зачем, пример с List и ArrayList"},{"chunk_id":"episode-43#c2","idx":2,"start":707,"title":"Bound check elimination"},{"chunk_id":"episode-43#c3","idx":3,"start":808,"title":"Виртуальные вызовы и прогрев JVM"},{"chunk_id":"episode-43#c4","idx":4,"start":1011,"title":"JIT против AOT-компиляции"},{"chunk_id":"episode-43#c5","idx":5,"start":1148,"title":"Размер ссылки в Java против структур в Rust"},{"chunk_id":"episode-43#c6","idx":6,"start":1620,"title":"Простой код против умного в ClickHouse"},{"chunk_id":"episode-43#c7","idx":7,"start":1675,"title":"Страх linked list: баг с конфигом на Poco"},{"chunk_id":"episode-43#c8","idx":8,"start":1947,"title":"Самый быстрый LRU-кэш в ClickHouse"},{"chunk_id":"episode-43#c9","idx":9,"start":2465,"title":"Кейси Моратори против чистого кода"},{"chunk_id":"episode-43#c10","idx":10,"start":3323,"title":"JIT в базах данных: Postgres"},{"chunk_id":"episode-43#c11","idx":11,"start":3436,"title":"Union-типы, страницы и Volcano-модель"},{"chunk_id":"episode-43#c12","idx":12,"start":3961,"title":"Инлайнинг констант и специализация функций"},{"chunk_id":"episode-43#c13","idx":13,"start":4639,"title":"Когда компилировать: OLAP против OLTP"},{"chunk_id":"episode-43#c14","idx":14,"start":5171,"title":"JIT по шагам: машинный код и LLVM IR"},{"chunk_id":"episode-43#c15","idx":15,"start":5983,"title":"Безопасность и краши LLVM"},{"chunk_id":"episode-43#c16","idx":16,"start":6327,"title":"Компиляция всего запроса и как стать инженером"}],"date":"2024-07-15","duration_sec":7765,"guests":["maxim-kita"],"key_takeaways":["`JIT` (just-in-time) компилирует горячий код в рантайме под конкретную машину: он знает `instruction set` процессора (вплоть до `AVX-512`) и потому может сгенерировать код лучше, чем заранее собранный `AOT`-бинарь в C/C++/Rust/Go.","Классический выигрыш в JVM: `get` у полиморфного `List` — виртуальный вызов через таблицу диспетчеризации; после того как JIT видит, что там всегда `ArrayList`, он девиртуализирует и инлайнит вызов, даёт `bound check elimination` и разворачивает цикл — ускорение в десятки-сотни раз.","В классической СУБД строка — это массив `union`-типов, а выполнение выражений идёт по дереву (точнее, `DAG`) через полиморфный `execute`; это куча виртуальных вызовов и распаковки типов, которая жутко тормозит на миллионах строк.","`JIT` в базе компилирует граф выражений в одну функцию с уже подставленными типами и константами (`id * 2` превращается в сдвиг), убирая виртуальные вызовы и промежуточные аллокации; руками покрыть все комбинации типов нереально — для `a + b + c` это тысячи функций.","OLAP-системы (ClickHouse) компилируют синхронно прямо в пайплайне — 15 мс на фоне 200 мс запроса терпимы; OLTP (Postgres, YDB) обязаны компилировать асинхронно, иначе один `row` вместо 5 мс даст пик, ломающий SLA.","На низком уровне `JIT` через `LLVM` строится из `LLVM IR` (`Module` → `Function` → basic-блоки) с помощью `IRBuilder`, компилируется в `binary object`, линкуется, кладётся в `mmap`-страницы с правами `read+execute` — права `write+execute` одновременно недопустимы, это прямой `RCE`.","`JIT` опасен: любой баг — это падение без стектрейса или порча памяти; даже валидные с виду `LLVM IR` могут ронять сам LLVM (баг в векторайзере), поэтому LLVM линкуют статически, а компиляцию форкают в отдельный процесс.","Прокачиваться в инженерии стоит от задач с понятным `definition of done` в виде кода, которые доводятся до работающего состояния за пару дней; лучше всего — в open-source-проектах, которые нравятся (ClickHouse, LLVM, Spring)."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"LLVM — компиляторная инфраструктура","url":"https://llvm.org"},{"title":"ClickHouse","url":"https://clickhouse.com"},{"title":"PostgreSQL","url":"https://www.postgresql.org"},{"title":"YDB","url":"https://ydb.tech"},{"title":"asmjit — генерация машинного кода на C++","url":"https://asmjit.com"},{"title":"Umbra — СУБД с data-centric code generation (TUM)","url":"https://umbra-db.com"},{"title":"Amazon Redshift","url":"https://aws.amazon.com/redshift/"}],"md_url":"https://apkhmv.xyz/podcast/episode-43/index.md","number":43,"season":1,"slug":"episode-43","tags":["JIT","компиляторы","LLVM","базы данных","ClickHouse"],"title":"#43: Как работает JIT в базах данных","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-43/"},{"abstract":"Александр Пахомов и коммитер ClickHouse Максим Кита разбирают процессоры глазами системного инженера — от иерархии кэшей, стека и prefetch до суперскалярности, спекулятивного выполнения и протокола когерентности `MESI`. Во второй половине разговор уходит в модели памяти (`happens-before`, relaxed / acquire-release / sequential consistency), false sharing и лок-фри-примитивы, а затем — в главную тему: `SIMD`, автовекторизацию, `CPU dispatch` и хитрые SIMD-алгоритмы вроде гугловой Swiss-хеш-таблицы, которыми ClickHouse ускоряет обработку данных.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/44_SIMD.mp3","chapters":[{"chunk_id":"episode-44#c0","idx":0,"start":7,"title":"Вступление: процессоры глазами инженера"},{"chunk_id":"episode-44#c1","idx":1,"start":101,"title":"Как работает процессор: инструкции, регистры, память"},{"chunk_id":"episode-44#c2","idx":2,"start":274,"title":"Иерархия кэшей и кэш-линии"},{"chunk_id":"episode-44#c3","idx":3,"start":756,"title":"Стек: почему память на нём всегда прогрета"},{"chunk_id":"episode-44#c4","idx":4,"start":973,"title":"ArrayList против LinkedList и prefetch"},{"chunk_id":"episode-44#c5","idx":5,"start":1161,"title":"Суперскалярность и спекулятивное выполнение"},{"chunk_id":"episode-44#c6","idx":6,"start":1427,"title":"Протокол когерентности кэшей MESI"},{"chunk_id":"episode-44#c7","idx":7,"start":1532,"title":"Пример с перемножением матриц"},{"chunk_id":"episode-44#c8","idx":8,"start":1996,"title":"False sharing, барьеры и store-буфер на x86"},{"chunk_id":"episode-44#c9","idx":9,"start":2337,"title":"Модели памяти и happens-before"},{"chunk_id":"episode-44#c10","idx":10,"start":2667,"title":"Relaxed, acquire-release, sequential consistency"},{"chunk_id":"episode-44#c11","idx":11,"start":3624,"title":"Шардированный счётчик и паддинг кэш-линий"},{"chunk_id":"episode-44#c12","idx":12,"start":4065,"title":"Лок-фри, wait-free и CAS"},{"chunk_id":"episode-44#c13","idx":13,"start":4460,"title":"SIMD: широкие регистры, автовекторизация, история AVX"},{"chunk_id":"episode-44#c14","idx":14,"start":5573,"title":"Портируемость и CPU dispatch"},{"chunk_id":"episode-44#c15","idx":15,"start":7028,"title":"SIMD-алгоритмы: Swiss-хеш-таблица и финал"}],"date":"2024-07-29","duration_sec":7761,"guests":["maxim-kita"],"key_takeaways":["Процессор в тысячу раз быстрее оперативной памяти, поэтому доступ идёт через иерархию кэшей (`L1`/`L2`/`L3`), которая подтягивает данные кэш-линиями (обычно 64 или 128 байт), эксплуатируя пространственную и временную локальность.","Итерация и копирование `ArrayList` быстрее `LinkedList`, потому что непрерывный массив читается кэш-линиями и хорошо предсказывается prefetch'ем, а связный список даёт кэш-промах почти на каждом элементе.","Транспонирование второй матрицы перед перемножением превращает обход «строка на столбец» в «строка на строку» и ускоряет наивный алгоритм в 3–10 раз — та же математика, но последовательный доступ к памяти.","На реальном железе `x86` тест «два потока пишут и читают» может выдать `0,0` из-за store-буфера; отсюда нужны модели памяти, которые отвечают, «какая запись видна какому чтению», не заставляя думать про внутренности процессора.","Три уровня гарантий атомиков: relaxed даёт только `modification order` (годится для счётчиков), acquire-release триггерит `happens-before`, а sequential consistency добавляет глобальный порядок — и позволяет рассуждать в модели чередования, если нет data race.","False sharing убивает производительность даже без data race: несколько потоков, пишущих в соседние переменные одной кэш-линии, гоняют её между ядрами — лечится паддингом (`hardware_destructive_interference_size`, 64 байта на `x86`).","`SIMD` (Single Instruction Multiple Data) — широкие регистры (`XMM`/`YMM`/`ZMM`, 128/256/512 бит) и инструкции над ними; вместе с автовекторизацией и loop-unrolling дают ускорение простых циклов в 2–4 раза, а в идеале до 16×.","Портируемость решается через `CPU dispatch`: одна функция компилируется под `SSE4.2`/`AVX2`/`AVX-512`, а на рантайме по `CPUID` выбирается доступная версия; `AVX-512` при этом опасен (нет на AMD, роняет частоту), поэтому Google и ClickHouse по умолчанию берут `SSE4.2`."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"ClickHouse — колоночная СУБД (GitHub)","url":"https://github.com/ClickHouse/ClickHouse"},{"title":"simdjson — парсинг JSON на SIMD","url":"https://github.com/simdjson/simdjson"},{"title":"Agner Fog — оптимизация ПО и справочники по инструкциям","url":"https://www.agner.org/optimize/"},{"title":"Andy Pavlo — курс по базам данных (CMU)","url":"https://15445.courses.cs.cmu.edu/"}],"md_url":"https://apkhmv.xyz/podcast/episode-44/index.md","number":44,"season":1,"slug":"episode-44","tags":["процессоры","SIMD","модели памяти","кэши","ClickHouse"],"title":"#44: SIMD в базах данных","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-44/"},{"abstract":"Александр Пахомов и Алексей Кладов (matklad — автор IntelliJ Rust и rust-analyzer, теперь разработчик TigerBeetle) подробно разбирают, чем TigerBeetle не похож на остальные СУБД: написана на `Zig`, без `SQL`-интерфейса, со статической аллокацией памяти и жёстко зашитой доменной моделью из аккаунтов и трансферов. По ходу — почему `OLTP` стоит вернуть к процессингу именно финансовых транзакций (а `SQL` назвать `OLGP`), как реплицированная state machine на консенсусе `VSR` переживает ненадёжные сеть и диск, как устроены чек-суммы, суперблок, батчинг и детерминированный компакшн `LSM`-деревьев, и почему системное программирование на самом деле простое — надо просто брать и писать код.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/1724936820522_45_TigerBeetle_matklad.mp3","chapters":[{"chunk_id":"episode-45#c0","idx":0,"start":0,"title":"Вступление: чем TigerBeetle не похож на остальных"},{"chunk_id":"episode-45#c1","idx":1,"start":167,"title":"Кто такой matklad и что такое TigerBeetle"},{"chunk_id":"episode-45#c2","idx":2,"start":526,"title":"Какую базу выбрать для финансовой системы"},{"chunk_id":"episode-45#c3","idx":3,"start":681,"title":"OLTP против OLGP: вернуть транзакции в транзакции"},{"chunk_id":"episode-45#c4","idx":4,"start":1067,"title":"Conway's Law и два разных стора"},{"chunk_id":"episode-45#c5","idx":5,"start":1338,"title":"Generic-код, Zig и state machine"},{"chunk_id":"episode-45#c6","idx":6,"start":1488,"title":"Симулятор и code reuse для анимаций"},{"chunk_id":"episode-45#c7","idx":7,"start":1607,"title":"Абстракции над сетью и диском"},{"chunk_id":"episode-45#c8","idx":8,"start":2088,"title":"Свой каунтер, LSM и чекпоинты"},{"chunk_id":"episode-45#c9","idx":9,"start":2501,"title":"Когда просто взять Postgres: контеншен и COST"},{"chunk_id":"episode-45#c10","idx":10,"start":2725,"title":"Консенсус, ненадёжный диск и починка по кворуму"},{"chunk_id":"episode-45#c11","idx":11,"start":3592,"title":"Суперблок в четырёх копиях и атомарность"},{"chunk_id":"episode-45#c12","idx":12,"start":3980,"title":"Три уровня батчинга: автобус вместо машин"},{"chunk_id":"episode-45#c13","idx":13,"start":4313,"title":"Throughput против latency и перформанс"},{"chunk_id":"episode-45#c14","idx":14,"start":4787,"title":"Детерминированный компакшн и резервирование блоков"},{"chunk_id":"episode-45#c15","idx":15,"start":5050,"title":"Устройство диска: один файл, грид, блок №0"},{"chunk_id":"episode-45#c16","idx":16,"start":5452,"title":"Статическая аллокация без malloc"},{"chunk_id":"episode-45#c17","idx":17,"start":5615,"title":"Системное программирование — это просто"},{"chunk_id":"episode-45#c18","idx":18,"start":5904,"title":"Главный совет: брать и писать код"},{"chunk_id":"episode-45#c19","idx":19,"start":6403,"title":"Челлендж: TigerBeetle на Rust без аллокаций"}],"date":"2024-08-29","duration_sec":6587,"guests":["matklad"],"key_takeaways":["TigerBeetle специализирован под `OLTP` в узком смысле — процессинг финансовых транзакций, где нужна строгая сериализуемость; остальное (аутентификация, скоринг, аватарки) выносится в обычную `OLGP`-базу вроде Postgres.","Проблема, которую решает TigerBeetle, — контеншен: задачи, которые фундаментально не параллелятся (перевод денег с одного популярного счёта банка), где `COST` из статьи Фрэнка Макшерри «Scalability! But at what COST?» фактически бесконечен.","Клиенты никогда не пишут в TigerBeetle напрямую — stateless `API Gateway` собирает запросы конечных пользователей в батчи (до 8000 трансферов) и шлёт их одним сообщением; вся бизнес-логика double-entry booking живёт в гейтвее.","Ядро TigerBeetle — реплицированная state machine (кластер из 6 машин на консенсусе `VSR`), параметризованная бизнес-логикой; в `Zig` это выражается функциями, которые принимают тип и возвращают тип, что даёт почти 100%-й code reuse в детерминированном симуляторе.","TigerBeetle предполагает почти византийский диск: он может вернуть мусор или записать данные не по тому адресу, поэтому чтение блока идёт по паре «адрес + чек-сумма», а битый блок прозрачно чинится копией с кворума других реплик.","На диске лежит функциональная (persistent) структура данных: ничего не перезаписывается in-place, а `superblock` в четырёх копиях с последовательной записью и `fsync` даёт атомарность чекпоинта поверх неатомарной записи.","Три уровня батчинга (8000 трансферов на консенсус, компакшн каждые 32 сообщения, чекпоинт каждые 1024) амортизируют работу; детерминированный компакшн достигается процедурой резервирования блоков, дающей byte-for-byte идентичный диск на всех репликах.","TigerBeetle не использует `malloc`/`free` — вся память аллоцируется на старте, что заставляет весь код работать с фиксированным бюджетом; главный совет гостя — не читать, а брать и писать код: системное программирование очень простое."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"TigerBeetle — база данных для финансовых транзакций","url":"https://tigerbeetle.com"},{"title":"TigerBeetle на GitHub","url":"https://github.com/tigerbeetle/tigerbeetle"},{"title":"Блог Алексея Кладова (matklad)","url":"https://matklad.github.io"},{"title":"rust-analyzer","url":"https://rust-analyzer.github.io"},{"title":"Frank McSherry — Scalability! But at what COST?","url":"https://www.usenix.org/system/files/conference/hotos15/hotos15-paper-mcsherry.pdf"},{"title":"Zig — язык программирования","url":"https://ziglang.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-45/index.md","number":45,"season":1,"slug":"episode-45","tags":["базы данных","распределённые системы","Zig","консенсус","системное программирование"],"title":"#45: TigerBeetle: база данных не похожа на остальные","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-45/"},{"abstract":"Александр Пахомов и Никита Прокопов (tonsky) — автор шрифта Fira Code, библиотеки DataScript и блога «Стой под стрелой» — разбирают, каким должен быть современный редактор кода. От эргономики (сплит-клавиатуры, home row, стрелки на `EJKL`) через спор о Vim, терминале и модальности к расширяемости и «шумности» IntelliJ IDEA. Никита объясняет, почему он много лет сидит в Sublime Text, почему «умный» редактор делает тебя тупее, и как маленькая команда без денег на nice-to-have фичи выигрывает у раздутых IDE.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/46_nikitonsky.mp3","chapters":[{"chunk_id":"episode-46#c0","idx":0,"start":0,"title":"Вступление"},{"chunk_id":"episode-46#c1","idx":1,"start":157,"title":"Эргономика клавиатуры: home row и сплит"},{"chunk_id":"episode-46#c2","idx":2,"start":571,"title":"Стрелки на home row: хук Vim и EJKL"},{"chunk_id":"episode-46#c3","idx":3,"start":908,"title":"Почему большинство не переходит на сплит"},{"chunk_id":"episode-46#c4","idx":4,"start":1592,"title":"Переход к Vim и Neovim"},{"chunk_id":"episode-46#c5","idx":5,"start":1640,"title":"Никита о Vim: модальность и система команд"},{"chunk_id":"episode-46#c6","idx":6,"start":1984,"title":"Саша защищает Vim: visual mode, макросы, escape"},{"chunk_id":"episode-46#c7","idx":7,"start":2573,"title":"Программирование в терминале в 2024-м"},{"chunk_id":"episode-46#c8","idx":8,"start":2827,"title":"Скорость и клавиатурность — не свойство терминала"},{"chunk_id":"episode-46#c9","idx":9,"start":3197,"title":"Расширяемость редактора и плагины"},{"chunk_id":"episode-46#c10","idx":10,"start":3619,"title":"Copilot в одну строчку; Atom против VS Code"},{"chunk_id":"episode-46#c11","idx":11,"start":3841,"title":"Шумность интерфейса IntelliJ IDEA"},{"chunk_id":"episode-46#c12","idx":12,"start":4241,"title":"Много денег — много булшита; фокус Sublime"},{"chunk_id":"episode-46#c13","idx":13,"start":4676,"title":"Sublime Text: почему он его выбрал"},{"chunk_id":"episode-46#c14","idx":14,"start":5266,"title":"Умные IDE делают тебя тупее"},{"chunk_id":"episode-46#c15","idx":15,"start":5525,"title":"Zed, языковые модели и Fleet"},{"chunk_id":"episode-46#c16","idx":16,"start":5954,"title":"Fleet и заключение"}],"date":"2024-09-30","duration_sec":6332,"guests":["nikita-prokopov"],"key_takeaways":["Раскладка со смещёнными рядами — исторический артефакт печатных машинок; эргономичнее ortho-linear колонки и сплит на ширину плеч, но всем good enough, поэтому индустрия не меняет стандарт.","Самое доступное улучшение для любого — перенести стрелки на home row (`EJKL`/`HJKL`) через системный ремап (Karabiner), а не только внутри Vim; тогда навигация одинакова во всех приложениях.","Навык сам по себе не растёт: человек находит локальный максимум и застревает — чтобы улучшиться, нужно сознательное усилие, а не просто «дольше вариться».","Никита ушёл с Vim из-за модальности (невидимый режим) и того, что редактирование в нём живёт по своим правилам, не совместимым с остальной системой; Sublime работает как весь macOS.","«Скорость терминала» — не свойство терминала: графический редактор можно написать таким же быстрым; Vim просто старый и рассчитан на слабое железо, а хорошая клавиатурность достижима и в GUI.","Расширяемость обязательна, но модель важна: Emacs/NeoVim дают хачить свой редактор (`init.lua`, одна строчка на плагин), а VS Code требует оформлять плагин и ограничивает API ради контроля экосистемы.","«Умная» IDE (`Go to Definition`, авто-рефакторинг) снижает, как ты интернализируешь код: перестаёшь помнить, где что лежит; в «тупом» редакторе понимаешь структуру плотнее и чувствуешь код своим.","Много денег вредит продукту: JetBrains и VS Code пихают nice-to-have фичи и нотификации, а команда Sublime из трёх человек делает только критичное — редактор целиком помещается в голове."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Fira Code — моноширинный шрифт с лигатурами","url":"https://github.com/tonsky/FiraCode"},{"title":"«Cursor keys belong at the center of your keyboard» — статья Никиты про EJKL","url":"https://tonsky.me/blog/cursor-keys/"},{"title":"Karabiner-Elements — ремаппинг клавиш на macOS","url":"https://karabiner-elements.pqrs.org"},{"title":"Neovim","url":"https://neovim.io"},{"title":"Sublime Text","url":"https://www.sublimetext.com"},{"title":"Zed — редактор на Rust","url":"https://zed.dev"},{"title":"Helix — модальный редактор","url":"https://helix-editor.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-46/index.md","number":46,"season":1,"slug":"episode-46","tags":["редакторы кода","Vim и Neovim","эргономика клавиатуры","инструменты разработчика","Sublime Text"],"title":"#46: Nikitonsky про современные редакторы кода","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-46/"},{"abstract":"Александр Пахомов и Андрей Зайцев (инженер JetBrains, архитектор редактора Fleet) разбирают внутреннее устройство Fleet как одновременно редактора кода и мутабельной базы данных. Разговор идёт от трёх исходных челленджей (remote development, коллаборация, полиглотность) через `React`-подобный UI, чистые функции и персистентные структуры данных к главной идее — распределённым оптимистичным транзакциям на механике «переписывания истории» в духе git-rebase, где всё состояние редактора это одно значение. По пути — параллели с `Datomic` и `MVCC`, детектор конфликтов на хэшах, нативный рендеринг через `Skia` и бюджет кадра при 120 FPS, а также роль garbage collector в функциональном коде.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/47_fleet.mp3","chapters":[{"chunk_id":"episode-47#c0","idx":0,"start":0,"title":"Вступление: зачем понадобился Fleet"},{"chunk_id":"episode-47#c1","idx":1,"start":102,"title":"Три челленджа: remote, коллаборация, полиглотность"},{"chunk_id":"episode-47#c2","idx":2,"start":792,"title":"React, Redux и облачная IDE"},{"chunk_id":"episode-47#c3","idx":3,"start":1381,"title":"Плавность UI как архитектурная цель"},{"chunk_id":"episode-47#c4","idx":4,"start":1557,"title":"Computational avoidance: не звать юзер-код"},{"chunk_id":"episode-47#c5","idx":5,"start":1848,"title":"Функциональное программирование как освобождение"},{"chunk_id":"episode-47#c6","idx":6,"start":2492,"title":"Datomic: база данных как значение"},{"chunk_id":"episode-47#c7","idx":7,"start":2924,"title":"Наблюдатель всегда смотрит в прошлое"},{"chunk_id":"episode-47#c8","idx":8,"start":3326,"title":"Оптимистичные транзакции Fleet и два таймстемпа"},{"chunk_id":"episode-47#c9","idx":9,"start":3658,"title":"CRDT, operational transformation и путь ребейза"},{"chunk_id":"episode-47#c10","idx":10,"start":3961,"title":"Конфликт как причинно-следственная связь и хэш-трюк"},{"chunk_id":"episode-47#c11","idx":11,"start":4279,"title":"Персистентность против фризов"},{"chunk_id":"episode-47#c12","idx":12,"start":4976,"title":"Fleet как продукт: полиглотный и лёгкий"},{"chunk_id":"episode-47#c13","idx":13,"start":5637,"title":"Нативный рендеринг: Skia, draw calls, GPU"},{"chunk_id":"episode-47#c14","idx":14,"start":6184,"title":"Garbage collector против ручной памяти"},{"chunk_id":"episode-47#c15","idx":15,"start":7409,"title":"Совет: учить Clojure и больше писать"}],"date":"2024-11-01","duration_sec":7785,"guests":["andrei-zaitsev","nikita-prokopov"],"key_takeaways":["Всё состояние Fleet — это одно персистентное значение (мутабельная база данных в памяти в духе `React` + `Redux`/`Re-frame`); UI это чистые функции от этого значения, а транзакции меняют значение отдельно от отрисовки.","Fleet задумывался как ответ на три челленджа, которых не было у IntelliJ IDEA изначально: remote development, совместная разработка над одним workspace и полиглотность (быть редактором «для разработчиков», а не для конкретного стека).","Главная идея быстрого UI — computational avoidance: по максимуму не звать пользовательский код; движок знает, какие компоненты какие части базы читали, и перевызывает только те, чьи данные изменились.","Совместное редактирование реализовано не через `CRDT` и не через operational transformation, а через путешествие во времени и `git-rebase`: транзакции это чистые функции, которые можно переиграть поверх нового состояния.","Конфликт определяется не записью в одно место, а нарушением причинно-следственной связи — тем, что для решения о записи ты прочитал то, что записал другой; детектируется пересечением множеств хэшей (read/write set), почти как блокчейн.","Персистентность базы даёт чтение без блокировок (не нужен read-лог), позволяет гонять массу фоновых рутин против состояния и так борется с фризами; bottleneck остаётся единственный транзактор, применяющий функции по очереди.","Fleet рисуется как игра — каждый кадр весь экран заново: UI-фреймворк строит список draw-call'ов и одним махом отправляет их на GPU через `Skia`; бюджет кадра при 120 FPS около 8 мс, из них в userspace остаётся ~4–5 мс.","В функциональном коде аллокации происходят «как дыхание», поэтому GC с компактящим молодым поколением часто выигрывает у ручного `malloc`/`free`; а место, которое много аллоцирует, обычно и есть медленный код."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"JetBrains Fleet","url":"https://www.jetbrains.com/fleet/"},{"title":"Datomic — база данных как значение","url":"https://www.datomic.com"},{"title":"Clojure","url":"https://clojure.org"},{"title":"Skia — 2D graphics library","url":"https://skia.org"},{"title":"Zed — редактор кода","url":"https://zed.dev"}],"md_url":"https://apkhmv.xyz/podcast/episode-47/index.md","number":47,"season":1,"slug":"episode-47","tags":["редакторы кода","функциональное программирование","распределённые транзакции","рендеринг UI","базы данных"],"title":"#47: Fleet: редактор с оптимистичными транзакциями","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-47/"},{"abstract":"Александр Пахомов и Стас Кельвич (сооснователь Neon — serverless Postgres as a service, где он сделал storage layer) с высоты птичьего полёта осматривают весь ландшафт баз данных: почему `SQL` пережил полвека и все попытки его заменить, что осталось от волны `NoSQL`, зачем Neon отдаёт Postgres по `HTTP` для edge-воркеров на V8, и где заканчивается один сервер. По пути — «константы скорости света» для пропускной способности (30–40k транзакций в секунду в одно соединение), инженерия шардирования и shuffle join, а также распределённые транзакции: двухфазный и трёхфазный коммит, Paxos Commit и подходы к изоляции. Это первая, обзорная часть; технические кишки Neon — в следующем выпуске.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/48_databases_overview.mp3","chapters":[{"chunk_id":"episode-48#c0","idx":0,"start":0,"title":"Вступление: в гостях ко-фаундер Neon"},{"chunk_id":"episode-48#c1","idx":1,"start":39,"title":"SQL исполнилось 50 лет"},{"chunk_id":"episode-48#c2","idx":2,"start":184,"title":"Почему SQL так живуч и консервативен"},{"chunk_id":"episode-48#c3","idx":3,"start":780,"title":"NoSQL: что из волны прижилось"},{"chunk_id":"episode-48#c4","idx":4,"start":961,"title":"Key-value, Redis и CRDT"},{"chunk_id":"episode-48#c5","idx":5,"start":1241,"title":"Realm и SDK для мобилок"},{"chunk_id":"episode-48#c6","idx":6,"start":1409,"title":"CRUD-сервисы, GraphQL и Facebook"},{"chunk_id":"episode-48#c7","idx":7,"start":1630,"title":"Neon: branching и HTTP вместо Postgres-протокола"},{"chunk_id":"episode-48#c8","idx":8,"start":2189,"title":"Datomic, Стоунбрейкер, векторный и полнотекстовый поиск"},{"chunk_id":"episode-48#c9","idx":9,"start":2684,"title":"Какую базу выбрать: расчёты на салфетке и SQLite"},{"chunk_id":"episode-48#c10","idx":10,"start":2931,"title":"«Скорость света»: константы производительности"},{"chunk_id":"episode-48#c11","idx":11,"start":3345,"title":"Зачем распределять: пропускная способность и отказоустойчивость"},{"chunk_id":"episode-48#c12","idx":12,"start":4537,"title":"Инженерия шардирования"},{"chunk_id":"episode-48#c13","idx":13,"start":5075,"title":"Distributed execution и shuffle join"},{"chunk_id":"episode-48#c14","idx":14,"start":6044,"title":"Распределённые транзакции: 2PC, Paxos Commit, изоляция"},{"chunk_id":"episode-48#c15","idx":15,"start":6836,"title":"Итоги и анонс части про Neon"}],"date":"2024-11-22","duration_sec":6971,"guests":["stas-kelvich"],"key_takeaways":["`SQL` — декларативный язык: ты описываешь желаемый результат, а система сама придумывает, как его получить; с рекурсивными запросами (`WITH RECURSIVE`) он формально Turing-полный.","Базу данных итерировать труднее, чем компилятор или язык: люди не прощают потерю данных, поэтому рынок ценит в СУБД в первую очередь надёжность и годы безотказной работы — это тормозит эксперименты и делает индустрию консервативной.","Волна `NoSQL` начала 2010-х в итоге эволюционировала обратно к классике: у той же MongoDB появились write-ahead log, B-деревья и buffer manager, и она стала похожа на обычную базу, просто с другим языком запросов.","В edge-средах (Cloudflare Workers, V8 isolates) нельзя открыть произвольный TCP-сокет, а долгоживущие соединения не переиспользуются между запросами — поэтому Neon отдаёт Postgres по `HTTP`: stateless-запросы V8 агрессивно переиспользует, экономя лишние round-trip'ы.","«Константа скорости света» для честного пинг-понга «запрос-ответ» в одно соединение — 30–40 тысяч транзакций в секунду в любой базе (Postgres, Redis, свой кэш на C++); упирается в CPU и планировщик ОС, а не в саму базу. Без сети и диска, батчами — миллионы (уровень Java `ConcurrentHashMap`).","Распределяют данные ради двух вещей: пропускной способности (масштабировать за предел одного сервера) и отказоустойчивости (реплики переживают сбой ноды) — но 10 машин отказывают чаще одной, выигрыш даёт только система, умеющая восстанавливаться от отказов.","Распределённый `JOIN` больших таблиц чаще всего сводится к shuffle join: перешардировать данные по ключу через сеть, локально сджойнить и смёржить; узкое место — не CPU, а бэкплейн сетевого свитча.","Атомарность распределённой транзакции обеспечивают двухфазным коммитом (блокирующий: нужна доступность всех участников), а корректный неблокирующий вариант — Paxos Commit; изоляцию делают либо кросс-нодовым snapshot isolation (Spanner, CockroachDB, TiDB), либо детерминированным реордерингом неинтерактивных транзакций (FaunaDB, YDB)."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Neon — serverless Postgres as a service","url":"https://neon.tech"},{"title":"Datomic — база данных с датолог-подобным языком запросов","url":"https://www.datomic.com"},{"title":"pgvector — векторный поиск для Postgres","url":"https://github.com/pgvector/pgvector"},{"title":"Google Cloud Spanner","url":"https://cloud.google.com/spanner"},{"title":"CockroachDB — distributed SQL database","url":"https://www.cockroachlabs.com"},{"title":"YDB — распределённая база данных (Яндекс)","url":"https://ydb.tech"},{"title":"Выпуск про Qdrant и векторный поиск","url":"https://apkhmv.xyz/podcast/episode-41/"}],"md_url":"https://apkhmv.xyz/podcast/episode-48/index.md","number":48,"season":1,"slug":"episode-48","tags":["базы данных","SQL и NoSQL","распределённые системы","шардирование","распределённые транзакции","Postgres"],"title":"#48: Реплицируем RDBMS с ко-фаундером Neon","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-48/"},{"abstract":"Александр Пахомов и Стас Кельвич (сооснователь Neon, где он сделал storage layer) разбирают внутреннее устройство serverless-Postgres. Как Neon отделяет compute от storage: `compute` — это чуть подхаченный Postgres, у которого чтение с диска заменено на чтение по сети, а `storage` — свои сервисы на Rust (Safekeeper — консенсусный `WAL` на модифицированном Raft/DiskPaxos, и PageServer — партиционированное LSM-дерево поверх S3). По пути — процессы Postgres-комьюнити (commit-fest'ы, пятилетние патчи, `TLA+`), branching через copy-on-write и запросы к истории по `LSN`, live-миграция виртуалок ради вертикального скейлинга без разрыва соединений, авторизация по `HTTP` для V8-isolate'ов, а также будущее многопоточного Postgres. Это вторая, глубоко техническая часть; обзорная — в выпуске 48.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/49_Neon_Database.mp3","chapters":[{"chunk_id":"episode-49#c0","idx":0,"start":0,"title":"Вступление: вторая часть, погружаемся внутрь Neon"},{"chunk_id":"episode-49#c1","idx":1,"start":70,"title":"Что такое Neon и экономика Postgres-комьюнити"},{"chunk_id":"episode-49#c2","idx":2,"start":600,"title":"История Postgres: System R, Ingres, Lisp → C"},{"chunk_id":"episode-49#c3","idx":3,"start":1072,"title":"Релиз-цикл, commit-fest'ы и пятилетние патчи"},{"chunk_id":"episode-49#c4","idx":4,"start":1425,"title":"Тестирование Postgres: green trunk, фаззинг, MVCC"},{"chunk_id":"episode-49#c5","idx":5,"start":1791,"title":"Язык C, Rust и надёжность через людей"},{"chunk_id":"episode-49#c6","idx":6,"start":2002,"title":"Как основали Neon: команда и вижен"},{"chunk_id":"episode-49#c7","idx":7,"start":2228,"title":"Разделение compute и storage, опыт Aurora"},{"chunk_id":"episode-49#c8","idx":8,"start":2558,"title":"shared-everything против shared-nothing"},{"chunk_id":"episode-49#c9","idx":9,"start":2782,"title":"compute как Postgres с сетевым чтением WAL и durability"},{"chunk_id":"episode-49#c10","idx":10,"start":3231,"title":"System design: Safekeeper, PageServer и S3"},{"chunk_id":"episode-49#c11","idx":11,"start":3836,"title":"Консенсус: Paxos, Raft, DiskPaxos и TLA+"},{"chunk_id":"episode-49#c12","idx":12,"start":4737,"title":"PageServer: LSM, append-only и история по LSN"},{"chunk_id":"episode-49#c13","idx":13,"start":5275,"title":"Branching: copy-on-write и preview-окружения"},{"chunk_id":"episode-49#c14","idx":14,"start":6039,"title":"Маскирование данных, RLS и HTTP-авторизация"},{"chunk_id":"episode-49#c15","idx":15,"start":6292,"title":"Автоскейлинг: live-миграция виртуалок"},{"chunk_id":"episode-49#c16","idx":16,"start":7061,"title":"Перформанс в облаке: виртуализация, OLTP против OLAP"},{"chunk_id":"episode-49#c17","idx":17,"start":7555,"title":"Open source, форк Postgres и многопоточность"},{"chunk_id":"episode-49#c18","idx":18,"start":8705,"title":"Вопросы слушателей: реплики, конкуренты, Rust"},{"chunk_id":"episode-49#c19","idx":19,"start":9671,"title":"Заключение: пробуйте себя в open source"}],"date":"2024-12-25","duration_sec":9869,"guests":["stas-kelvich"],"key_takeaways":["Neon разделяет `compute` и `storage`: compute — это Postgres, у которого чтение страниц с диска заменено чтением по сети, а запись `WAL` идёт в свой storage; storage выглядит для Postgres как реплика на запись и как диск на чтение.","Storage-слой multi-tenant и stateless-по-compute: `HA` и защита от split-brain живут в storage, поэтому compute-ноды (`stateless` Postgres) можно агрессивно перезапускать в Kubernetes — это резко упрощает эксплуатацию миллионов баз силами 10 человек.","Durability строится двумя тирами: Safekeeper коммитит `WAL` в 2 из 3 availability-зон (аналог quorum commit), затем PageServer материализует журнал в 8-килобайтные страницы и как можно быстрее сбрасывает их в S3 — «горячую картошку» отдают S3 как фундаменту durability.","Safekeeper реализует консенсус модифицированным Raft (по сути DiskPaxos): роли разделены — Postgres-compute только пропоузер/лидер, Safekeeper только фолловер; корректность части протокола проверяли на `TLA+` (это model checker, не доказательство — как property-based testing).","PageServer — партиционированное LSM-дерево, но append-only ради дешёвой выгрузки в S3 (S3 не даёт менять префикс); без garbage collection хранится вся история, поэтому запрос страницы на произвольном `LSN` дёшев — отсюда time-travel, дешёвые исторические запросы и восстановление до точного `LSN`.","Branching — это copy-on-write: бранч терабайтной базы создаётся мгновенно, данные копируются лишь при записи; это раскрывает preview-окружения на реальных данных, тест миграций против прода и (в разработке) анонимизацию/маскирование данных на бранче.","Вертикальный автоскейлинг делают live-миграцией виртуалки (QEMU/KVM, pre-copy/post-copy), утаскивая за собой IP через `VXLAN`: `TCP`-соединения, транзакции и контекст сессии переживают переезд с одной Kubernetes-ноды на другую — обычный HTTP-style rescheduling для Postgres не годится из-за долгоживущих запросов и сессионного состояния.","Форк Postgres у Neon крошечный (10–20k строк, адаптация новой версии — меньше месяца), потому что почти всё вынесено в расширения; будущее — многопоточный Postgres (thread-local вместо static-переменных), над которым команда работает в апстриме, а не в своём форке."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Neon — serverless Postgres as a service","url":"https://neon.tech"},{"title":"Socrates: The New SQL Server in the Cloud (Microsoft Research, SIGMOD 2019)","url":"https://www.microsoft.com/en-us/research/publication/socrates-the-new-sql-server-in-the-cloud/"},{"title":"TLA+ — язык и model checker Лесли Лэмпорта","url":"https://lamport.azurewebsites.net/tla/tla.html"},{"title":"pgrx — фреймворк для расширений Postgres на Rust","url":"https://github.com/pgcentralfoundation/pgrx"},{"title":"Amazon Aurora","url":"https://aws.amazon.com/rds/aurora/"},{"title":"Supabase — Postgres-платформа для приложений","url":"https://supabase.com"},{"title":"Выпуск 48: обзор ландшафта баз данных с ко-фаундером Neon","url":"https://apkhmv.xyz/podcast/episode-48/"}],"md_url":"https://apkhmv.xyz/podcast/episode-49/index.md","number":49,"season":1,"slug":"episode-49","tags":["serverless Postgres","распределённые системы","консенсус и Paxos","storage-движки","облачные базы данных"],"title":"#49: Serverless Postgres: как работает Neon Database","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-49/"},{"abstract":"Сольный, юбилейный 50-й выпуск: Александр Пахомов возвращается к формату монолога и разбирает, что за год ощутимо подняло его продуктивность как программиста. Разговор идёт по четырём слоям — эргономика рабочего места (кресло `ErgoHuman`, кронштейн для ноутбука, ортолинейная сплит-клавиатура), софт (`Ghostty` + `tmux` + `Neovim` как единая среда, `fish`, единая тема во всех программах), пет-проект «база данных на Rust» и его влияние на уверенность в языке, и, наконец, здоровье — отказ от соцсетей и новостных каналов ради «свободного места в голове» плюс спорт как способ прокачать не тело, а майндсет времени и дисциплины.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/50_productivity.mp3","chapters":[{"chunk_id":"episode-50#c0","idx":0,"start":13,"title":"Юбилейный монолог: без гостей и без технических деталей"},{"chunk_id":"episode-50#c1","idx":1,"start":119,"title":"Эргономика: рабочее место и стол"},{"chunk_id":"episode-50#c2","idx":2,"start":194,"title":"Как выбирать кресло: ErgoHuman против Herman Miller"},{"chunk_id":"episode-50#c3","idx":3,"start":696,"title":"Кронштейн для ноутбука и осанка"},{"chunk_id":"episode-50#c4","idx":4,"start":980,"title":"Один или два монитора; MacBook M3 Max"},{"chunk_id":"episode-50#c5","idx":5,"start":1277,"title":"Сплит-клавиатура и ортолинейность"},{"chunk_id":"episode-50#c6","idx":6,"start":1810,"title":"Софт: терминал Ghostty на Zig"},{"chunk_id":"episode-50#c7","idx":7,"start":2182,"title":"tmux и Neovim как единая среда"},{"chunk_id":"episode-50#c8","idx":8,"start":2774,"title":"База данных на Rust: пет-проект и уверенность в языке"},{"chunk_id":"episode-50#c9","idx":9,"start":3135,"title":"Телеграм-бот и веб-сервер на Rust за 200"},{"chunk_id":"episode-50#c10","idx":10,"start":3493,"title":"Отказ от соцсетей и новостных каналов"},{"chunk_id":"episode-50#c11","idx":11,"start":4010,"title":"Спорт: майндсет времени и дисциплины"},{"chunk_id":"episode-50#c12","idx":12,"start":4667,"title":"Заключение: никаких фетишей"}],"date":"2025-01-24","duration_sec":4797,"guests":[],"key_takeaways":["Эргономичное кресло надо выбирать не по цене и не по интернет-обзорам, а сидя в шоуруме по 10–15 минут на каждой модели: `Herman Miller Aeron` за ~2000$ подошёл автору хуже, чем `ErgoHuman Elite 2` за ~1000$ — под конкретное тело кресло подбирается индивидуально.","Кронштейн, поднимающий экран на уровень глаз, снимает постоянное напряжение задних мышц шеи: когда голова висит вперёд над ноутбуком, эти мышцы держат её всё время, что у автора доходило до пульсирующей боли и бессонницы.","Одного хорошего монитора достаточно почти всегда; два монитора реально нужны только под стриминг (один транслируется целиком, второй — под `OBS`), а постоянно крутить голову между экранами — неестественная нагрузка.","Ортолинейная сплит-клавиатура (клавиши строго друг под другом) резко снижает промахи слепой печати по спецсимволам и скобкам, а разведённые на ~30 см половины расправляют плечи и грудную клетку — 8 часов в день со сведёнными руками сгорбливают.","Связка `Ghostty` (терминал на Zig) + `tmux` + `Neovim` под единой темой `Gruvbox` стирает границу между терминалом, командной строкой и редактором — весь интеллектуальный труд, кроме Java (её автор оставляет в `IntelliJ IDEA` + IdeaVim), делается в одном окне.","Пет-проект «своя база данных на Rust» оказался без обозримого скоупа (у больших компаний первая версия — это ~5 лет), но именно он превратил формальное «знаю Rust» в реальное умение: автор смог по ходу дела написать на Rust веб-сервер, отдающий `200` для health-check `Traefik`.","Отказ от Twitter, новостных телеграм-каналов, TikTok и Instagram освободил «пространство в голове» и энергию: любое чтение таких лент запускает фоновое «думание», а без него у автора появились силы на второй сезон подкаста и другое творчество.","Спорт даёт не только здоровую спину и «промытую» кардио голову, но и переносимый на работу майндсет: как штангу в 100 кг не взять за пару тренировок, так и большую фичу или пет-проект берёт наложение времени и дисциплины на деятельность, а не только талант и желание."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Ghostty — терминал на Zig","url":"https://ghostty.org"},{"title":"Neovim","url":"https://neovim.io"},{"title":"tmux","url":"https://github.com/tmux/tmux"},{"title":"fish shell","url":"https://fishshell.com"},{"title":"Gruvbox Material — цветовая схема","url":"https://github.com/sainnhe/gruvbox-material"},{"title":"QMK Firmware — прошивка клавиатур","url":"https://qmk.fm"},{"title":"Vial — конфигуратор клавиатур","url":"https://get.vial.today"},{"title":"n8n — платформа автоматизации","url":"https://n8n.io"},{"title":"Traefik — reverse proxy","url":"https://traefik.io"}],"md_url":"https://apkhmv.xyz/podcast/episode-50/index.md","number":50,"season":1,"slug":"episode-50","tags":["продуктивность","эргономика","рабочее место","Rust","цифровой детокс"],"title":"#50: Как я повысил свою продуктивность за этот год","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-50/"},{"abstract":"Александр Пахомов и коммитер ClickHouse Максим Кита разбирают, как в большом open-source-проекте устроено код-ревью: почему оно неотделимо от мощного CI, от которого зависит, сколько ответственности можно снять с ревьюера, и от того, как сами контрибьюторы готовят свой код. По пути — какие тесты и санитайзеры гоняет ClickHouse, почему `code coverage` как хардстоп чаще вредит, какие пул-реквесты страшнее всего ревьюить (вероятностные алгоритмы), как «запал» автора и человеческая психология определяют судьбу PR, и почему изоляция кода через `factory`-паттерн и принцип open-closed так важна для контрибьютабельности.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/51_code_review_Clickhouse.mp3","chapters":[{"chunk_id":"episode-51#c0","idx":0,"start":0,"title":"Вступление: зачем говорить про код-ревью"},{"chunk_id":"episode-51#c1","idx":1,"start":93,"title":"Что такое код-ревью и чем он отличается от проекта к проекту"},{"chunk_id":"episode-51#c2","idx":2,"start":296,"title":"Главная задача ревьюера — задавать вектор"},{"chunk_id":"episode-51#c3","idx":3,"start":718,"title":"CI как помощник ревьюера"},{"chunk_id":"episode-51#c4","idx":4,"start":847,"title":"Форматирование: gofmt против clang-format"},{"chunk_id":"episode-51#c5","idx":5,"start":1481,"title":"Тесты, санитайзеры и фаззеры в ClickHouse"},{"chunk_id":"episode-51#c6","idx":6,"start":1780,"title":"Флэки-тесты и споры про code coverage"},{"chunk_id":"episode-51#c7","idx":7,"start":2213,"title":"Самые тяжёлые PR: хардкорные и вероятностные алгоритмы"},{"chunk_id":"episode-51#c8","idx":8,"start":2582,"title":"Взаимодействие ревьюера и автора: запал и психология"},{"chunk_id":"episode-51#c9","idx":9,"start":3053,"title":"99% мержа: как в ClickHouse доделывают чужие PR"},{"chunk_id":"episode-51#c10","idx":10,"start":3263,"title":"Селф-ревью: как автору готовить код к ревью"},{"chunk_id":"episode-51#c11","idx":11,"start":4336,"title":"Структура кода: factory-паттерн и изоляция"},{"chunk_id":"episode-51#c12","idx":12,"start":5163,"title":"Паттерны, open-closed и итоги"}],"date":"2025-04-12","duration_sec":5382,"guests":["maxim-kita"],"key_takeaways":["В ClickHouse код-ревью — обязательная часть перед мержем, и оно неотделимо от CI: чем сильнее CI, тем больше ответственности можно снять с ревьюера, чтобы внешний контрибьютор мог сам увидеть и починить проблему.","Главная задача ревьюера в большом open-source-проекте — не ловить опечатки, а задавать вектор: понимать мотивацию PR и то, как фичу правильно реализовать в духе проекта; если ревьюер сам не знает, как её сделать, полноценного ревью не получится.","Проблема форматирования решена «одной кнопкой» в Go (`gofmt`) и Rust, но не в C++ и не на JVM: почти у каждого C++-проекта свой конфиг `clang-format` поверх шаблона (Chromium, LLVM, WebKit), а вопрос `camelCase` vs `snake_case` в C++ так и не устоялся.","ClickHouse гоняет stateless-, stateful-, unit- и интеграционные тесты, стресс-тесты, фаззеры (в том числе SQL-фаззер) и перф-тесты под ARM и x86 — со всеми санитайзерами (address, thread, memory, UB); зелёный CI делает вероятность бага очень маленькой.","`code coverage` как хардстоп чаще вредит: 100% покрытия не гарантирует работоспособность, люди забивают его пустыми тестами, а такие тесты потом ломаются при рефакторинге и замедляют эволюцию кода.","Самые тяжёлые для ревью пул-реквесты — с хардкорным алгоритмическим кодом, особенно вероятностными алгоритмами: тут нужно понять код на 100%, потому что опечатка (например, в большом простом числе) может незаметно сломать алгоритм.","Судьбу PR во многом решает психология: у автора есть «запал», который с каждым днём падает, поэтому важно отвечать быстро и сразу давать максимум фидбэка; антипаттерн — ревьюить по верхам, гонять по нитпикам, а через несколько итераций сказать «тут всё архитектурно неправильно».","Изолируйте код: `factory`-паттерн и принцип open-closed позволяют добавлять функцию или парсер отдельным файлом, который ничего наружу не торчит и ничего не ломает; но паттернами (адаптеры, декораторы) легко упороться — обёртки оправданы, только когда оборачиваемый тип нельзя поменять."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"ClickHouse — колоночная СУБД (GitHub)","url":"https://github.com/ClickHouse/ClickHouse"}],"md_url":"https://apkhmv.xyz/podcast/episode-51/index.md","number":51,"season":1,"slug":"episode-51","tags":["код-ревью","ClickHouse","open source","C++","тестирование"],"title":"#51: Код ревью в Clickhouse","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-51/"},{"abstract":"Александр Пахомов и Андрей Володин (сооснователь и CTO стартапа Gracia, ex-founding engineer Prisma и сооснователь NetMonet) разбирают, как вайб-кодинг и AI-агенты меняют профессию разработчика в середине 2025 года. Отправной точкой служит кейс Андрея: не будучи фронтендером, он с нуля собрал в Cursor комплексную админку (backend-driven UI, three.js, парсинг COLMAP) за ноль строк ручного кода. Отсюда — почему «попсовые» стеки (React, TypeScript) под наибольшим давлением, а low-level, робототехника и diptech пока «тихая гавань»; зачем разработчику смещаться в сторону бизнеса; и как экономическая конъюнктура (конец ZIRP, стагнация рынка смартфонов) переопределяет ценность кода — от «читабельности» к «нераспространению говнокода».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/podcast_17_v4_1.mp3","chapters":[{"chunk_id":"episode-52#c0","idx":0,"start":0,"title":"Холодный старт: тезисы Андрея"},{"chunk_id":"episode-52#c1","idx":1,"start":129,"title":"Вступление"},{"chunk_id":"episode-52#c2","idx":2,"start":190,"title":"Знакомство: Prisma, NetMonet, Gracia"},{"chunk_id":"episode-52#c3","idx":3,"start":573,"title":"Кейс: админка в Cursor без фронтендера"},{"chunk_id":"episode-52#c4","idx":4,"start":1590,"title":"AI-трансформация команды и метрики"},{"chunk_id":"episode-52#c5","idx":5,"start":2097,"title":"Попсовые vs непопсовые сферы, джуны и сеньоры"},{"chunk_id":"episode-52#c6","idx":6,"start":3215,"title":"Университеты и фундаментальные знания"},{"chunk_id":"episode-52#c7","idx":7,"start":4262,"title":"Разработчик как «предатель»: нативка vs веб"},{"chunk_id":"episode-52#c8","idx":8,"start":4878,"title":"Экономика: конец ZIRP и бума смартфонов"},{"chunk_id":"episode-52#c9","idx":9,"start":5158,"title":"Код как «ассемблер для документации»"},{"chunk_id":"episode-52#c10","idx":10,"start":5878,"title":"Инструменты: агенты, MCP, init.md, тестирование"},{"chunk_id":"episode-52#c11","idx":11,"start":6615,"title":"Модели: не прыгать с модельки на модельку"},{"chunk_id":"episode-52#c12","idx":12,"start":6817,"title":"Языки: попсовые побеждают, бан на breaking change"},{"chunk_id":"episode-52#c13","idx":13,"start":7597,"title":"Соло-фаундер против команды-свитспота"},{"chunk_id":"episode-52#c14","idx":14,"start":8614,"title":"Ламповое напутствие и финал"}],"date":"2025-06-09","duration_sec":8779,"guests":["andrey-volodin"],"key_takeaways":["Опытный разработчик без фронтенд-опыта собрал в `Cursor` комплексную админку (backend-driven UI, `three.js`, парсинг `COLMAP`) за ноль строк ручного кода — быстрее, дешевле и без усталости по сравнению с наймом фрилансера.","Ценность кода теперь не в читабельности, а в том, что он «не распространяет метастазы»: self-contained-модули не шерят общие утилиты, поэтому поломка в одном месте не ломает всё остальное.","Давление AI сильнее всего в «попсовых» стеках (`React`, `TypeScript`), потому что нейросети обучены на огромном объёме именно такого кода; асинхронные агенты первыми «выжрут» задачи джунов и мидлов.","Low-level computing (`CUDA`-кернелы, шейдеры, профайлинг), embedded, робототехника и research пока «тихая гавань»: мало открытых данных и сложно построить `reinforcement learning` feedback loop.","Университеты должны делать double down на фундаментал (алгоритмы, компиляторы, линейная алгебра, сети), а не гнаться за хайпом: fastfood-знания вроде «слайдер на React» и так выдаёт AI за секунду.","Почасовая оплата разработчика абсурдна и напрямую мотивирует работать хуже; платить надо за результат — «за сапог, а не за часы».","Код — это «ассемблер для документации и продуктовых задач»: если слить на торренты фронтенд крупного банка, `literally nothing will happen`, потому что вне своего бизнеса он ценности не несёт.","Целевая команда будущего — не соло-фаундер (его скопируют 50 тысяч таких же), а свитспот в 10–30 ультра-профессионалов, где роли смерживаются в «имплементаторов» и «бизнес-визионеров»."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Gracia — объёмное 4D-видео (Gaussian Splatting)","url":"https://gracia.ai"},{"title":"Cursor — AI-редактор кода","url":"https://cursor.com"},{"title":"Aider — терминальный AI-агент для кода","url":"https://aider.chat"},{"title":"Browserbase / Stagehand — AI-browser automation","url":"https://www.browserbase.com"},{"title":"Repomix — упаковка репозитория для LLM","url":"https://repomix.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-52/index.md","number":52,"season":1,"slug":"episode-52","tags":["вайб-кодинг","AI-агенты","профессия разработчика","рынок труда в IT","языки программирования"],"title":"#52: Трансформация профессии разработчика в 2025","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-52/"},{"abstract":"Александр Пахомов и Никита Прокопов (Nikitonsky — автор Fira Code, DataScript и телеграм-канала «Стой под стрелой») разбирают Datomic — базу данных, которая идёт против течения индустрии. Начав с боли, когда оптимизатор `Postgres` внезапно замедляет запрос в сто раз, они переходят к устройству Datomic: модель `Entity-Attribute-Value` вместо таблиц, язык запросов `Datalog` вместо `SQL`, разделение чтения и записи, однопоточный транзактор и иммутабельная база с путешествием во времени. Отдельная линия разговора — как маленькая команда за счёт радикальной простоты решает те же задачи минимальными средствами.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/53_Datomic.mp3","chapters":[{"chunk_id":"episode-53#c0","idx":0,"start":0,"title":"Вступление: гость Nikitonsky и рок-н-рольная БД"},{"chunk_id":"episode-53#c1","idx":1,"start":66,"title":"История про Postgres: оптимизатор запросов подводит"},{"chunk_id":"episode-53#c2","idx":2,"start":350,"title":"Контроль против оптимизатора: хочется управлять планом"},{"chunk_id":"episode-53#c3","idx":3,"start":639,"title":"Datomic как альтернатива: другой взгляд на данные"},{"chunk_id":"episode-53#c4","idx":4,"start":985,"title":"Триплы: Entity-Attribute-Value и датомы"},{"chunk_id":"episode-53#c5","idx":5,"start":1680,"title":"Datalog: паттерн-матчинг вместо SQL и индексы"},{"chunk_id":"episode-53#c6","idx":6,"start":2338,"title":"Транзакции: add/retract и деконструкция базы данных"},{"chunk_id":"episode-53#c7","idx":7,"start":2471,"title":"Разделение чтения и записи, однопоточный транзактор"},{"chunk_id":"episode-53#c8","idx":8,"start":2772,"title":"Рок-н-ролл: осознай свой масштаб"},{"chunk_id":"episode-53#c9","idx":9,"start":3060,"title":"Чтение на клиенте и произвольные функции на Clojure"},{"chunk_id":"episode-53#c10","idx":10,"start":3508,"title":"Только Clojure/Java: почему Datomic не взлетел широко"},{"chunk_id":"episode-53#c11","idx":11,"start":3678,"title":"Storage и иммутабельность: путешествие во времени"},{"chunk_id":"episode-53#c12","idx":12,"start":4955,"title":"DataScript: TripleStore как удобная структура данных"}],"date":"2025-07-05","duration_sec":5372,"guests":["nikita-prokopov"],"key_takeaways":["Оптимизатор `Postgres` снимает головную боль в ~90% случаев, но когда инженер точно знает нужную последовательность операций, отсутствие прямого контроля над планом становится проблемой — добавление no-op-фильтра может замедлить запрос примерно в 100 раз.","Зависимость запроса от индекса в `SQL` неявная: запрос молча предполагает, что индекс есть, но нигде его не указывает — отсюда идея спустить абстракцию на уровень ниже, вплоть до `SELECT ... FROM table USING INDEX`.","Datomic хранит данные не таблицами, а тройками `Entity-Attribute-Value` (датомами); это делает разреженные поля, множественные значения и ссылки бесплатными по overhead, а обратные ссылки — такими же дешёвыми, как прямые.","Datomic использует `Datalog` — паттерн-матчинг по тройкам с автоматическим джойном и рекурсивными правилами; он эквивалентен `SQL` по мощности, но `order by`/`limit` в нём нет — их выносят в постобработку на клиенте.","Datomic «деконструирует» базу данных: чтение идёт напрямую из network-attached storage мимо сервера, а записи обслуживает единственный однопоточный транзактор, который просто линеаризует поток транзакций.","Однопоточного writer'а хватает для подавляющего большинства бизнес-приложений (порядка тысячи транзакций в секунду); отказ решать проблемы, которых у тебя нет, радикально упрощает систему.","Datomic — иммутабельная база: клиент держит ссылку на конкретную версию (эпоху) и видит консистентный снапшот всей базы, а также умеет запрашивать состояние на любой момент в прошлом — фантомные чтения как явление просто исчезают.","Радикальная простота Datomic родилась из ограничения маленькой команды; эта же модель `TripleStore` + `Datalog` реализуется в ~200 строк и легла в основу `DataScript` — in-memory клона, удобного даже без персистентности."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Datomic — база данных","url":"https://www.datomic.com"},{"title":"DataScript — immutable database и Datalog для Clojure/Script","url":"https://github.com/tonsky/datascript"},{"title":"Fira Code — шрифт с лигатурами для программистов","url":"https://github.com/tonsky/FiraCode"},{"title":"PostgreSQL","url":"https://www.postgresql.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-53/index.md","number":53,"season":1,"slug":"episode-53","tags":["Datomic","базы данных","Clojure","Datalog","PostgreSQL"],"title":"#53: Datomic: самая рок-н-рольная БД","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-53/"},{"abstract":"Александр Пахомов и Иван Ямщиков (сооснователь Pleias, профессор THWS) разбирают, как генеративные модели и «вайб-кодинг» меняют работу инженера в середине 2025 года: где модели реально полезны (быстрое прототипирование) и где буксуют (тестирование, валидация и дебаг сгенерированного кода). По пути — как из «восстановления пропусков в тексте» вырос reasoning, почему модель в чате не дообучается на вашем фидбэке, чем маленькие модели и RAG интересны бизнесу с чувствительными данными, и какой навык остаётся за человеком: придумывать тесты и удерживать «вкус» к задаче.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/54_Vibe.mp3","chapters":[{"chunk_id":"episode-54#c0","idx":0,"start":0,"title":"Вступление"},{"chunk_id":"episode-54#c1","idx":1,"start":42,"title":"Вайб-кодинг: прототипы против дебага"},{"chunk_id":"episode-54#c2","idx":2,"start":314,"title":"Тестирование агентов и баланс с человеком"},{"chunk_id":"episode-54#c3","idx":3,"start":792,"title":"Reasoning: chain of thought и декомпозиция"},{"chunk_id":"episode-54#c4","idx":4,"start":1091,"title":"Дообучение и катастрофическое забывание"},{"chunk_id":"episode-54#c5","idx":5,"start":1663,"title":"Маленькие модели, Common Corpus и RAG"},{"chunk_id":"episode-54#c6","idx":6,"start":2093,"title":"Локальные модели и приватность данных в enterprise"},{"chunk_id":"episode-54#c7","idx":7,"start":2607,"title":"Главный навык: придумывать тесты"},{"chunk_id":"episode-54#c8","idx":8,"start":2893,"title":"Практический совет: завайб-кодить пет-проект"},{"chunk_id":"episode-54#c9","idx":9,"start":3312,"title":"Заключение"}],"date":"2025-07-28","duration_sec":3384,"guests":["ivan-yamshchikov"],"key_takeaways":["Вайб-кодинг силён для прототипирования, но дебаг и тестирование сгенерированного кода — узкое место, и оно же сдерживает автономных агентов.","Баланс автономии агента и контроля человека похож на дилемму фрилансера с заказчиком: проверять слишком часто — делать лишнюю работу, слишком редко — рискнуть выдать нерабочий результат.","Reasoning сводится к восстановлению пропусков в цепочке рассуждений (chain of thought) плюс декомпозиции задачи на подзадачи и трате большего «компьюта» на ответ.","Модель в чате не дообучается на вашей обратной связи — она предобучена; непрерывное дообучение упирается в «катастрофическое забывание» (catastrophic forgetting).","Большая модель ценна не столько качеством на одной задаче, сколько гибкостью: её можно дообучать под много задач, а маленькую под каждую новую приходится радикально переучивать.","Стартап Pleias обучает маленькие (350M–1,2B) модели только на открытом датасете Common Corpus; они мультиязычны, сильны в RAG и умеют цитировать источники «из коробки».","Спрос enterprise — локальные и гибридные пайплайны: не отдавать чувствительные данные и код в OpenAI/Anthropic, а часть задач решать маленькой локальной моделью.","Главный навык программиста в эпоху агентов — придумывать тесты и удерживать «вкус» к задаче; написание кода всё больше делегируется модели."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Common Corpus — открытый датасет Pleias (Hugging Face)","url":"https://huggingface.co/datasets/PleIAs/common_corpus"},{"title":"Pleias — лаборатория Ивана","url":"https://pleias.fr"}],"md_url":"https://apkhmv.xyz/podcast/episode-54/index.md","number":54,"season":1,"slug":"episode-54","tags":["вайб-кодинг","ИИ-агенты","языковые модели","reasoning","RAG","тестирование"],"title":"#54: Вайбим с Иваном Ямщиковым","transcript_date":"2026-09-15","transcript_status":"reviewed","url":"https://apkhmv.xyz/podcast/episode-54/"},{"abstract":"Александр Пахомов и Вова — основатель компании Unison и продукта yuchat, с которым Александр работает больше четырёх лет, — разбирают, как мыслит предприниматель: почему работа должна давать не только «плюшки», но и рост, зачем нанимать «под человека», а не «под вакансию», и что такое ламповый «социум», который плохо масштабируется. Во второй половине — про инструменты для живого удалённого общения (спонтанная коммуникация как в open space, возможность догнать пропущенный созвон на скорости), про вкус и креатив в профессии и про новую реальность, в которой всё труднее доверять коду и контенту, сгенерированному ИИ.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/55_Business_Vova.mp3","chapters":[{"chunk_id":"episode-55#c0","idx":0,"start":28,"title":"Вступление: кто такой Вова"},{"chunk_id":"episode-55#c1","idx":1,"start":146,"title":"Работа, комфорт и «социум»"},{"chunk_id":"episode-55#c2","idx":2,"start":393,"title":"Молодые специалисты и «оголтелый студент»"},{"chunk_id":"episode-55#c3","idx":3,"start":696,"title":"Информационный шум и навык фильтрации"},{"chunk_id":"episode-55#c4","idx":4,"start":1206,"title":"«Я начальник, ты дурак» и масштаб культуры"},{"chunk_id":"episode-55#c5","idx":5,"start":1474,"title":"Искать человека, а не закрывать вакансию"},{"chunk_id":"episode-55#c6","idx":6,"start":1918,"title":"Эйфория основателя и продуктовая трансформация"},{"chunk_id":"episode-55#c7","idx":7,"start":2442,"title":"Спонтанность и разгрузка головы"},{"chunk_id":"episode-55#c8","idx":8,"start":2891,"title":"Единственный, кто с тебя спросит, — ты сам"},{"chunk_id":"episode-55#c9","idx":9,"start":3271,"title":"Инструменты для живого удалённого социума"},{"chunk_id":"episode-55#c10","idx":10,"start":3946,"title":"Спонтанная коммуникация против асинхронной"},{"chunk_id":"episode-55#c11","idx":11,"start":4612,"title":"Киллер-фича: догнать пропущенный созвон"},{"chunk_id":"episode-55#c12","idx":12,"start":4911,"title":"AI-инструменты и кризис доверия к сгенерированному"}],"date":"2025-09-02","duration_sec":5602,"guests":["vova"],"key_takeaways":["Работа — большая часть жизни, поэтому «плюшек» (массажные кресла, психолог в офисе, завтраки) недостаточно: по пирамиде потребностей они внизу, а сверху человеку нужно понимать, к чему он растёт.","Выгорание — это потеря мотивации; личный рецепт против него — всегда держать следующую, чуть более высокую цель, чтобы мотивация не заканчивалась.","Главное требование к junior-специалисту — быть «оголтелым»: думать головой и искренне вовлекаться, а не присылать сгенерированный `буллшит` ради скорости.","Новый и ещё несформированный навык — фильтровать колоссальный поток информации и отделять важное; молодому поколению это даётся тяжелее, потому что объём растёт почти экспоненциально.","Ламповый «социум» единомышленников имеет ограниченную ёмкость (десятки-сотни, не тысячи) и плохо масштабируется — в большом enterprise ценности, спускаемые сверху вниз, обычно не работают.","Правильный найм — искать человека, с которым можешь работать, а не «закрывать вакансию под требования»; человеку нужно время присмотреться, в той ли он культуре.","Спонтанность и «услышать» разговор коллег важнее расписания: креатив и брейншторминг по календарю не букаются, а слух вовлекает, не перегружая и без того занятое зрение.","Удобство решает: если догнать пропущенный созвон неудобно (почта → Google Drive → плеер), этого просто не произойдёт; маленький шаг вроде прослушивания записи на `X2` разблокирует целую рабочую практику."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"yuchat — продукт компании Unison","url":"https://yuchat.ai"}],"md_url":"https://apkhmv.xyz/podcast/episode-55/index.md","number":55,"season":1,"slug":"episode-55","tags":["предпринимательство","мотивация","корпоративная культура","удалённая работа","ИИ-инструменты"],"title":"#55: Как мыслит предприниматель","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-55/"},{"abstract":"Александр Пахомов и Дмитрий Константинов (коммитер Apache Cassandra) проходят путь запроса end-to-end со стороны клиента: как устроен драйвер Cassandra и как, поняв его, написать собственный. Разбирают contact points и service discovery, равноправные ноды и rolling upgrade, CQL и модель данных (keyspace, partition/clustering ключи, upsert без чтения), prepared statement с кэшем на сервере, кодеки-сериализацию, выбор ноды и локальность дата-центров, а на нижнем уровне — бинарный протокол поверх Netty: нарезку TCP-потока на фреймы, корреляцию ответов через stream id, таймауты на hash wheel timer, идемпотентные и спекулятивные ретраи, backpressure. Это первая часть трилогии; серверная сторона — в следующих выпусках.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/56_Cassandra_podcast_1.mp3","chapters":[{"chunk_id":"episode-56#c0","idx":0,"start":0,"title":"Вступление: сквозной путь запроса в Cassandra"},{"chunk_id":"episode-56#c1","idx":1,"start":120,"title":"Клиент-серверная модель и языковые драйверы"},{"chunk_id":"episode-56#c2","idx":2,"start":347,"title":"Contact points: подключение к распределённому кластеру"},{"chunk_id":"episode-56#c3","idx":3,"start":959,"title":"Равноправные ноды и rolling upgrade"},{"chunk_id":"episode-56#c4","idx":4,"start":1231,"title":"Аутентификация и TLS"},{"chunk_id":"episode-56#c5","idx":5,"start":1956,"title":"CQL, keyspace и создание таблицы"},{"chunk_id":"episode-56#c6","idx":6,"start":2512,"title":"Primary, partition и clustering ключи"},{"chunk_id":"episode-56#c7","idx":7,"start":2993,"title":"Upsert и три вида statement"},{"chunk_id":"episode-56#c8","idx":8,"start":3581,"title":"Prepared statement, MD5-хэш и кэш"},{"chunk_id":"episode-56#c9","idx":9,"start":4558,"title":"Кодеки: сериализация Java-объектов в байты"},{"chunk_id":"episode-56#c10","idx":10,"start":5442,"title":"Дата-центры, локальность и выбор ноды"},{"chunk_id":"episode-56#c11","idx":11,"start":6540,"title":"Протокол, хедеры и нарезка TCP-потока"},{"chunk_id":"episode-56#c12","idx":12,"start":7408,"title":"Корреляция запросов и ответов: stream id"},{"chunk_id":"episode-56#c13","idx":13,"start":7999,"title":"Таймауты и hash wheel timer"},{"chunk_id":"episode-56#c14","idx":14,"start":8854,"title":"Ретраи, идемпотентность и спекулятивные запросы"},{"chunk_id":"episode-56#c15","idx":15,"start":9431,"title":"Backpressure, rate limiting и итоги"}],"date":"2025-11-06","duration_sec":9972,"guests":["dmitry-konstantinov"],"key_takeaways":["Cassandra — кластер равноправных нод без выделенного лидера: клиенту дают `contact points`, а полный список адресов драйвер вытягивает из служебных таблиц `system.local`/`system.peers` — это встроенный service discovery.","Модель данных задаётся на этапе `CREATE TABLE`: обязательный `PARTITION KEY` определяет шардирование (все строки одного ключа лежат вместе), а опциональный `CLUSTERING KEY` задаёт порядок внутри партиции — по сути двухуровневая распределённая хэш-таблица.","`INSERT` и `UPDATE` в Cassandra — это один и тот же upsert без чтения предыдущего значения (`read-before-write` отсутствует), поэтому нет `UNIQUE`-констрейнтов, зато запись быстрая и почти всегда идемпотентная.","`PREPARED STATEMENT` кэшируется на конкретной ноде под `MD5`-хэшем запроса; репликации нет — если нода не знает id, драйвер обязан переподготовить запрос, а сервер держит кэш ограниченного размера (Caffeine).","Драйвер выбирает ноду стратегией `load balancing policy`: отсекает мёртвые и удалённые дата-центры, предпочитает локальный DC и реплики партиции, учитывает загрузку и даже uptime ноды (JVM-прогрев).","Бинарный протокол работает поверх Netty: TCP — это поток, который надо res* нарезать на фреймы по длине из хедера; ответы коррелируются с запросами через `stream id`, что позволяет держать десятки тысяч запросов in-flight на одно соединение.","Таймауты реализованы через `hash wheel timer` — кольцевой массив-«циферблат» с хэшированием по остатку от деления, дешёвый на постановку и отмену тысяч одноразовых таймеров.","Идемпотентные запросы драйвер может ретраить; поверх обычных ретраев есть спекулятивные (hedged) запросы — по 90-му перцентилю латентности драйвер шлёт дубль в другую ноду и берёт ответ того, кто ответит первым, снижая хвостовые задержки."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Apache Cassandra","url":"https://cassandra.apache.org"},{"title":"Netty — асинхронный сетевой фреймворк","url":"https://netty.io"},{"title":"Caffeine — кэш-библиотека для Java","url":"https://github.com/ben-manes/caffeine"},{"title":"ANTLR — генератор парсеров","url":"https://www.antlr.org"},{"title":"Google SRE Book (глава про hedged requests)","url":"https://sre.google/sre-book/table-of-contents/"}],"md_url":"https://apkhmv.xyz/podcast/episode-56/index.md","number":56,"season":1,"slug":"episode-56","tags":["Apache Cassandra","распределённые базы данных","клиент-серверная архитектура","сетевые протоколы","Java"],"title":"#56: Apache Cassandra, часть 1: клиент, сервер","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-56/"},{"abstract":"Вторая часть разбора Apache Cassandra: Александр Пахомов и Дмитрий Константинов (коммитер Apache Cassandra) прослеживают путь одной операции записи от серверного сокета до диска. По дороге — серверный `Netty` с нативным `epoll`, flow control через TCP backpressure, аутентификация и авторизация, consistent hashing с виртуальными нодами, consistency level и кворумы, gossip-протокол и hinted handoff, а затем локальная запись: `commit log`, трёхуровневый memtable (`ConcurrentSkipListMap`/trie над `B-tree`), «last write wins» по таймстемпам, сброс в `SSTable`, компакция и, наконец, удаления через tombstones.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/57_Cassandra.mp3","chapters":[{"chunk_id":"episode-57#c0","idx":0,"start":0,"title":"Вступление: часть 2, погружаемся в сервер"},{"chunk_id":"episode-57#c1","idx":1,"start":39,"title":"Серверный Netty и нативный транспорт"},{"chunk_id":"episode-57#c2","idx":2,"start":539,"title":"Flow control: rate limiting и TCP backpressure"},{"chunk_id":"episode-57#c3","idx":3,"start":1417,"title":"Обработка запроса: парсинг и авторизация"},{"chunk_id":"episode-57#c4","idx":4,"start":1792,"title":"Координатор и задача шардирования"},{"chunk_id":"episode-57#c5","idx":5,"start":2388,"title":"Consistent hashing, кольцо и виртуальные ноды"},{"chunk_id":"episode-57#c6","idx":6,"start":3329,"title":"Consistency level и кворумы"},{"chunk_id":"episode-57#c7","idx":7,"start":3749,"title":"CAP-треугольник и толерантность к отказам"},{"chunk_id":"episode-57#c8","idx":8,"start":4265,"title":"Gossip, seed-ноды и определение живости"},{"chunk_id":"episode-57#c9","idx":9,"start":4936,"title":"Мёртвые реплики и hinted handoff"},{"chunk_id":"episode-57#c10","idx":10,"start":5619,"title":"Локальная запись: commit log и fsync"},{"chunk_id":"episode-57#c11","idx":11,"start":6873,"title":"Memtable: мапа мап, trie и B-деревья"},{"chunk_id":"episode-57#c12","idx":12,"start":7790,"title":"SSTable, сброс на диск и компакция"},{"chunk_id":"episode-57#c13","idx":13,"start":8079,"title":"Удаление: tombstones и shadowing"},{"chunk_id":"episode-57#c14","idx":14,"start":8794,"title":"Tombstones и консистентность реплик"},{"chunk_id":"episode-57#c15","idx":15,"start":8993,"title":"Итог, книги и анонс третьей части"}],"date":"2025-12-01","duration_sec":9193,"guests":["dmitry-konstantinov"],"key_takeaways":["Серверная сторона Cassandra на `Netty` симметрична клиентской и умеет включать нативный транспорт (`epoll` на Linux, `BoringSSL` для TLS) простой подкладкой JAR в classpath — прирост порядка 10–15% «за бесплатно».","Flow control на входе Cassandra ограничивает не число in-flight запросов, а их суммарный размер в байтах (по умолчанию ~10% от хипа); при перегрузке чаще всего просто перестаёт читать из сокета, опираясь на TCP backpressure.","Cassandra шардирует данные через consistent hashing: `Murmur3`-хэш ключа кладётся на кольцо, реплики находятся бинарным поиском по кольцу, а виртуальные ноды (`vnodes`) выравнивают распределение при добавлении/удалении нод.","`consistency level` (`ONE`, `QUORUM`, `LOCAL_QUORUM`, `ALL`, `ANY`) — параметр запроса, задающий число ответивших реплик; он двигает систему по CAP-треугольнику между доступностью и консистентностью.","Живость нод Cassandra отслеживает gossip — эпидемический протокол: нода шлёт heartbeat в seed-ноду и несколько случайных, и информация о `membership` расходится по кластеру, как инфекция.","Запись на реплике сначала идёт в `commit log`, но по умолчанию `fsync` не синхронный (раз в ~10 секунд) — Cassandra меняет надёжность одной ноды на скорость, полагаясь на репликацию; включение синхронного `fsync` роняет производительность примерно на порядок.","Memtable — это трёхуровневая структура «мапа мап»: `ConcurrentSkipListMap` или trie по partition-ключу, персистентное `B-tree` по clustering-ключу и `B-tree` по колонкам; слияние идёт по правилу «побеждает больший таймстемп», поэтому в Cassandra критична синхронизация часов клиентов.","Удаление в LSM — это вставка `tombstone` (могильной плиты) с таймстемпом; выкинуть его при компакции безопасно, только доказав отсутствие «затенённых» записей — по min/max таймстемпам и ключам SSTable и через `Bloom filter`, иначе старые данные воскресают."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Apache Cassandra","url":"https://cassandra.apache.org"},{"title":"Netty — асинхронный сетевой фреймворк","url":"https://netty.io"},{"title":"Caffeine — кэш-библиотека для Java","url":"https://github.com/ben-manes/caffeine"},{"title":"Wireshark","url":"https://www.wireshark.org"},{"title":"«Designing Data-Intensive Applications», Martin Kleppmann","url":"https://dataintensive.net"},{"title":"«Database Internals», Alex Petrov","url":"https://www.databass.dev"}],"md_url":"https://apkhmv.xyz/podcast/episode-57/index.md","number":57,"season":1,"slug":"episode-57","tags":["Apache Cassandra","распределённые базы данных","LSM-деревья","consistent hashing","репликация и консистентность"],"title":"#57: Apache Cassandra, часть 2: как работает запись","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-57/"},{"abstract":"Заключительная, третья часть разбора Apache Cassandra: Александр Пахомов и Дмитрий Константинов (коммитер Apache Cassandra) прослеживают путь запроса на чтение от координатора до диска. По дороге — какие чтения Cassandra делает эффективно (по `partition`- и префиксу `clustering`-ключа) и почему это OLTP-, а не аналитическая база; кворумная математика `R + W \u003e N` и `strong consistency`; выбор реплик через `Snitch`, спекулятивные ретраи и оптимизация «данные с одной реплики, digest с остальных»; `read-repair` и пагинация без `OFFSET`; а на нижнем уровне — `Bloom filter`, `primary index` с `index summary`, `key cache`, блочное сжатие с `compression metadata`, вынос метаданных в off-heap и, наконец, боль tombstones при чтении «очередей».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/58_Cassandra_Read.mp3","chapters":[{"chunk_id":"episode-58#c0","idx":0,"start":0,"title":"Вступление: часть 3, читаем данные"},{"chunk_id":"episode-58#c1","idx":1,"start":33,"title":"Краткий пересказ частей 1 и 2"},{"chunk_id":"episode-58#c2","idx":2,"start":375,"title":"Виды чтений: partition- и clustering-ключи"},{"chunk_id":"episode-58#c3","idx":3,"start":897,"title":"Полное сканирование, DSBulk и токены"},{"chunk_id":"episode-58#c4","idx":4,"start":1274,"title":"Координатор чтения и маскирование колонок"},{"chunk_id":"episode-58#c5","idx":5,"start":1602,"title":"Consistency level и кворумная математика"},{"chunk_id":"episode-58#c6","idx":6,"start":2378,"title":"Выбор реплик и Snitch"},{"chunk_id":"episode-58#c7","idx":7,"start":3002,"title":"Спекулятивные ретраи и чтение со всех реплик"},{"chunk_id":"episode-58#c8","idx":8,"start":3529,"title":"Слияние ответов: digest вместо данных"},{"chunk_id":"episode-58#c9","idx":9,"start":4132,"title":"Read-repair: чтение чинит реплики"},{"chunk_id":"episode-58#c10","idx":10,"start":4364,"title":"Пагинация и её особенности"},{"chunk_id":"episode-58#c11","idx":11,"start":5049,"title":"Локальное чтение: memtable и SSTable"},{"chunk_id":"episode-58#c12","idx":12,"start":5491,"title":"Bloom filter"},{"chunk_id":"episode-58#c13","idx":13,"start":6169,"title":"Primary index, index summary и key cache"},{"chunk_id":"episode-58#c14","idx":14,"start":6894,"title":"Сжатие и compression metadata"},{"chunk_id":"episode-58#c15","idx":15,"start":7565,"title":"Off-heap, unsafe и эволюция JVM"},{"chunk_id":"episode-58#c16","idx":16,"start":8092,"title":"Tombstones и антипаттерн очереди"},{"chunk_id":"episode-58#c17","idx":17,"start":8316,"title":"Что осталось за кадром: LWT, Accord, SAI"},{"chunk_id":"episode-58#c18","idx":18,"start":8796,"title":"Совет напоследок: затюньте, чтобы понять"}],"date":"2025-12-16","duration_sec":8891,"guests":["dmitry-konstantinov"],"key_takeaways":["API драйвера для чтения и записи одинаковый (те же `PreparedStatement`/`BoundStatement`); разница лишь в обработке результата — при чтении данные текут обратно от сервера, и почти всегда работает пагинация.","Cassandra — OLTP-, а не аналитическая база: эффективны чтения по полному `partition`-ключу плюс диапазону или префиксу `clustering`-ключа; запрос без полного `partition`-ключа вырождается в full scan по всем нодам, потому что хэш от части ключа не связан с хэшом целого.","Кворумное чтение опирается на неравенство `R + W \u003e N`: если множество ответивших на запись реплик пересекается с множеством читаемых хотя бы в одной ноде, чтение увидит последнюю запись (в терминах Cassandra — `strong consistency`); `replication factor` при этом отвечает за долговечность, а не за консистентность.","Координатор выбирает реплики через `Snitch` (по умолчанию dynamic snitch — по медиане времени ответа), но такая обратная связь может входить в автоколебания; поэтому иногда выгоднее слать запрос сразу во все реплики ради предсказуемой нагрузки.","Голосования между репликами нет: ответы сливаются по «последний по таймстемпу побеждает»; в оптимизации Cassandra запрашивает полные данные лишь с одной (обычно локальной) реплики, а с остальных — `MD5`-digest, и сравнивает хэши (это ~3% CPU из-за неудачно выбранного `MD5`).","`read-repair`: если при чтении данные на репликах разошлись, координатор не только вернёт клиенту актуальную версию, но и запишет её обратно на устаревшие реплики — то есть чтение может породить запись.","Пагинация в Cassandra — только «вперёд» через закладку (курсор в партиции), без `OFFSET`/прыжков на произвольную страницу; консистентность гарантируется лишь в пределах одной страницы, а не всего запроса.","На чтении Cassandra отбрасывает лишние `SSTable` по min/max ключам и `Bloom filter`, находит позицию через `primary index` + `index summary` в памяти и `key cache`, а данные хранит блоками под сжатием (`LZ4` по умолчанию, `ZSTD`), что требует отдельного `compression metadata` для маппинга смещений."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Apache Cassandra","url":"https://cassandra.apache.org"},{"title":"DataStax Bulk Loader (DSBulk)","url":"https://github.com/datastax/dsbulk"},{"title":"Caffeine — кэш-библиотека для Java","url":"https://github.com/ben-manes/caffeine"},{"title":"Amazon Corretto Crypto Provider","url":"https://github.com/corretto/amazon-corretto-crypto-provider"},{"title":"Zstandard (ZSTD)","url":"https://github.com/facebook/zstd"},{"title":"Accord — распределённые транзакции для Cassandra (CEP-15)","url":"https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions"}],"md_url":"https://apkhmv.xyz/podcast/episode-58/index.md","number":58,"season":1,"slug":"episode-58","tags":["Apache Cassandra","распределённые базы данных","консистентность и кворумы","LSM-деревья","Bloom filter"],"title":"#58: Apache Cassandra, часть 3: читаем данные","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-58/"},{"abstract":"Александр Пахомов и Дима Королёв (инженер, несколько лет в Web3) разбирают блокчейн и Ethereum инженерным языком — без маркетингового буллшита. Как биткоин Сатоши стал первым leaderless-леджером с инвариантом no double spend через `proof of work`; почему у биткоина нет финалити, а балансы — это derived-вьюха поверх лога блоков; как Ethereum добавил EVM, смарт-контракты и `ERC-20`, а `proof of stake`, валидаторы со стейком и L2-шардинг сделали транзакции дешёвыми. Попутно — MEV-атаки, мосты и `WBTC`, CAP-теорема через partial order и аналогию с Kafka, DEX против CEX, и как идеи Web3 (доказуемые гарантии, secure chip, confidential compute) просачиваются в Web2.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/59_podcast.mp3","chapters":[{"chunk_id":"episode-59#c0","idx":0,"start":0,"title":"Вступление: блокчейн и эфир инженерным языком"},{"chunk_id":"episode-59#c1","idx":1,"start":45,"title":"Что такое Web3: от Сатоши к сети без доверия"},{"chunk_id":"episode-59#c2","idx":2,"start":252,"title":"Биткоин — не первая сеть: торренты и e-mail"},{"chunk_id":"episode-59#c3","idx":3,"start":532,"title":"Как поднять ноду и Satoshi consensus"},{"chunk_id":"episode-59#c4","idx":4,"start":645,"title":"У биткоина нет финалити"},{"chunk_id":"episode-59#c5","idx":5,"start":979,"title":"Proof of work изнутри: хэши, mempool и MEV"},{"chunk_id":"episode-59#c6","idx":6,"start":1254,"title":"Минусы биткоина: цена и доверие"},{"chunk_id":"episode-59#c7","idx":7,"start":1554,"title":"Эфир: EVM, смарт-контракты и gas"},{"chunk_id":"episode-59#c8","idx":8,"start":1894,"title":"DeFi: WBTC, залог и заём"},{"chunk_id":"episode-59#c9","idx":9,"start":2311,"title":"Proof of stake, валидаторы и слэшинг"},{"chunk_id":"episode-59#c10","idx":10,"start":2801,"title":"L1/L2, CAP-теорема и partial order"},{"chunk_id":"episode-59#c11","idx":11,"start":3009,"title":"Шардинг L2 и settlement в L1"},{"chunk_id":"episode-59#c12","idx":12,"start":3809,"title":"Биллинг, ордербуки и трейдинг"},{"chunk_id":"episode-59#c13","idx":13,"start":4116,"title":"DEX против CEX и кастомные сети"},{"chunk_id":"episode-59#c14","idx":14,"start":4419,"title":"Как эфир катит апдейты; минусы эфира"},{"chunk_id":"episode-59#c15","idx":15,"start":4734,"title":"Web3 влияет на Web2: secure chip и confidential compute"},{"chunk_id":"episode-59#c16","idx":16,"start":5398,"title":"Совет слушателям и Stateful Compute"}],"date":"2026-01-06","duration_sec":5566,"guests":["dima-korolev"],"key_takeaways":["Биткоин — первая самоподдерживающаяся система, распределяющая ценность без доверия между участниками; её главный инвариант — no double spend (нельзя потратить больше, чем есть).","`Satoshi consensus` (он же `proof of work`) устроен так, что всем майнерам выгодно достраивать одну самую длинную цепь: максимальный reward получает тот, кого принял majority сети, а не тот, кто «первый» — физического времени в сети нет, только логическое.","У биткоина нет финалити: состояние вероятностно, и теоретически историю можно переписать — но каждый новый блок стоит астрономических вычислений, поэтому после ~5 блоков перезапись практически невозможна.","Балансы в леджере биткоина не хранятся — хранится лог блоков с транзакциями, а таблица балансов это derived materialized-вьюха; атака `50% + 1` даёт контроль заморозить/цензурировать транзакции, но не украсть чужие токены (нет валидной подписи).","Ethereum добавил EVM и смарт-контракты на `Solidity` с `gas fees`: правила зашиты не в протокол, а в код; стандарт `ERC-20` позволил хранить ненативные токены на леджере эфира и запустил DeFi (лендинг под `collateral`, `WBTC`, стейблкоины).","`Proof of stake` заменяет гонку всех майнеров на псевдослучайно выбранный небольшой набор валидаторов со «золочённым» стейком (слэшинг за читерство); это дёшево, но финалити всё ещё вероятностная — чекпоинт в эфире наступает примерно раз в полчаса.","L1-сети (`proof of work` Bitcoin, `proof of stake` Ethereum) дают total order и потому медленные и дорогие; L2 — это шардинг на независимые партиции (аналог партиций в Kafka) с периодическим settlement в L1, что роняет стоимость транзакции до десятков центов.","Идеи Web3 просачиваются в Web2: доказуемые криптографические гарантии вместо голого доверия провайдеру, `secure chip`/passkey в каждом устройстве и confidential compute (докер-образ на secure-чипе в облаке с подписью вендора) — движение к системам с меньшим baseline-доверием."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Stateful Compute — Substack Димы Королёва","url":"https://dimakorolev.substack.com/p/stateful-compute"},{"title":"Substrate — фреймворк для блокчейнов (Polkadot SDK)","url":"https://substrate.io"},{"title":"«Designing Data-Intensive Applications», Martin Kleppmann","url":"https://dataintensive.net"},{"title":"Telegram-канал подкаста «Тысяча фичей»","url":"https://t.me/tfeat"}],"md_url":"https://apkhmv.xyz/podcast/episode-59/index.md","number":59,"season":1,"slug":"episode-59","tags":["Web3","блокчейн","Ethereum","смарт-контракты","распределённые системы"],"title":"#59: Основы Web3: Blockchain и Ether","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-59/"},{"abstract":"Александр Пахомов и Дмитрий Рожков (менеджер и автор YouTube-канала «Senior Software Vlogger») разбирают, как `Claude Code` меняет работу инженера: Дмитрий, будучи менеджером и не Swift-программистом, полностью написал моделями Mac-приложение `Summit AI Notes` и продаёт его в App Store. Отсюда разговор уходит к главному тезису выпуска — «инженерной ответственности»: за код, который сгенерировала модель, отвечает не Anthropic, а инженер. По пути — почему важен строгий `harness` вокруг модели, чем `Opus 4.5` лучше `Sonnet 4`, почему классическое код-ревью упирается в бутылочное горлышко по Голдратту и как программирование с LLM превращается в менеджмент.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/60_Engineering_AI.mp3","chapters":[{"chunk_id":"episode-60#c0","idx":0,"start":0,"title":"Холодный старт: инженерная ответственность"},{"chunk_id":"episode-60#c1","idx":1,"start":39,"title":"Summit AI Notes: локальная запись звонков на Mac"},{"chunk_id":"episode-60#c2","idx":2,"start":186,"title":"Из Swift-любителя в менеджеры, а код пишет Claude"},{"chunk_id":"episode-60#c3","idx":3,"start":315,"title":"Реальный продукт: продажи, установки, crash-репорты"},{"chunk_id":"episode-60#c4","idx":4,"start":600,"title":"Почему Swift: мало open source, но выборка качественнее"},{"chunk_id":"episode-60#c5","idx":5,"start":698,"title":"Оценка кода как чёрного ящика и ревью синьором"},{"chunk_id":"episode-60#c6","idx":6,"start":1057,"title":"Sonnet 4 против Opus 4.5 и борьба со ScreenCaptureKit"},{"chunk_id":"episode-60#c7","idx":7,"start":1830,"title":"Harness, срезание углов и контекст перед глазами"},{"chunk_id":"episode-60#c8","idx":8,"start":2204,"title":"Мигающие курсоры, циклы и вайб-кодинг по Карпати"},{"chunk_id":"episode-60#c9","idx":9,"start":2635,"title":"Менеджерская оптика и инженерная ответственность"},{"chunk_id":"episode-60#c10","idx":10,"start":3196,"title":"Смерть код-ревью: Голдратт, bottleneck и мультиагенты"},{"chunk_id":"episode-60#c11","idx":11,"start":4040,"title":"Конкретные тулы: Claude Code, Qoder, Cursor, голос"},{"chunk_id":"episode-60#c12","idx":12,"start":4440,"title":"Заключение: относитесь к модели как к джуниору"}],"date":"2026-01-28","duration_sec":4509,"guests":["dmitry-rozhkov"],"key_takeaways":["Инженерная ответственность — ключевой тезис выпуска: Anthropic нельзя привлечь за плохой pull-request, а инженера можно, поэтому теперь ты отвечаешь не за свой код, а за код, который сгенерировала модель.","Менеджер, не будучи Swift-программистом, полностью написал моделями (`Claude Code`, `Gemini CLI`, `Codex`) Mac-приложение `Summit AI Notes` на ~50 тысяч строк Swift, продаёт его в App Store, и за всё время у приложения лишь два crash-репорта.","Качество сгенерированного кода на незнакомом стеке оценивается как чёрный ящик — работает, не течёт по памяти и CPU, проходит строгий линтер — а не построчным чтением; для Swift-приложения помогает и то, что компилятор сам себя верифицирует.","Модель по умолчанию срезает углы там же, где люди: не пишет тесты, валит всё в один файл без архитектуры — поэтому решают строгий `harness` (форматтер, самый строгий линтер, правила в `CLAUDE.md`) и сеньорское мышление, а не «сделай красиво».","`Opus 4.5` для многих стал водоразделом: он реже, чем `Sonnet 4`, ходит кругами и сам понимает, когда надо подумать, — то, что раньше приходилось вымучивать (запись двух аудиопотоков через `ScreenCaptureKit`), решается быстрее.","Классическое код-ревью умирает: под лавиной сгенерированных pull-request'ов оно становится бутылочным горлышком по Голдратту («Цель»), а три его функции — обмен знаниями, менторинг и ловля багов — можно раздать отдельным агентам (по требованиям, security, перформансу).","Программирование с LLM по сути превращается в менеджмент, только с быстрыми итерациями и без коммуникации с людьми; главное, чего не хватает агентам, — агентности и самостоятельного принятия решений, и именно этим человек их дополняет.","Инженерная ответственность требует не меньше, а больше: программировать надо лучше, чем раньше, проверять — ещё больше, потому что за два дня плотного кодирования с LLM создаётся объём контекста, который раньше нарастал два месяца."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Senior Software Vlogger — YouTube-канал Дмитрия Рожкова","url":"https://www.youtube.com/@SeniorSoftwareVlogger"}],"md_url":"https://apkhmv.xyz/podcast/episode-60/index.md","number":60,"season":1,"slug":"episode-60","tags":["вайб-кодинг","Claude Code","инженерная ответственность","код-ревью","ИИ-агенты"],"title":"#60: Claude Code и инженерная ответственность с Senior Software Vlogger","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-60/"},{"abstract":"Александр Пахомов и Александр «Саша» Ланцов (Java-разработчик в финтехе, Мир Plat.Form) на примере двух рантаймов — HotSpot JVM и Go — прослеживают всю эволюцию сборщиков мусора: от фундаментальных алгоритмов (reference counting, mark-and-sweep, mark-compact, копирующий) и трёхцветной маркировки до `Serial`/`Parallel`, `CMS`, `G1`, `Shenandoah`, `ZGC` и нового `Green Tea` в Go. По пути — гипотеза о поколениях и почему её нет в Go, card table и GC-барьеры, фрагментация и спаны, указатели Брукса, цветные указатели и трюк с виртуальной памятью, спираль смерти. В финале — как осознанно выбрать GC под latency, пропускную способность и размер хипа.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/61_GC_Java_Go.mp3","chapters":[{"chunk_id":"episode-61#c0","idx":0,"start":0,"title":"Вступление: два рантайма — Java и Go"},{"chunk_id":"episode-61#c1","idx":1,"start":363,"title":"Зачем это знать: собеседования и low-latency"},{"chunk_id":"episode-61#c2","idx":2,"start":536,"title":"Фундамент: reference counting и трассирующие сборщики"},{"chunk_id":"episode-61#c3","idx":3,"start":859,"title":"Маркировка и трёхцветный алгоритм"},{"chunk_id":"episode-61#c4","idx":4,"start":1376,"title":"Mark and Sweep и фрагментация"},{"chunk_id":"episode-61#c5","idx":5,"start":1862,"title":"Mark-Compact и копирующий коллектор"},{"chunk_id":"episode-61#c6","idx":6,"start":2774,"title":"GC нужно место «дышать»: спираль смерти"},{"chunk_id":"episode-61#c7","idx":7,"start":3162,"title":"Гипотеза о поколениях, card table и барьеры"},{"chunk_id":"episode-61#c8","idx":8,"start":3920,"title":"Serial и Parallel GC в Java"},{"chunk_id":"episode-61#c9","idx":9,"start":4451,"title":"Древний Go: спаны и классы размеров"},{"chunk_id":"episode-61#c10","idx":10,"start":5160,"title":"Частично конкурентные сборщики и барьеры"},{"chunk_id":"episode-61#c11","idx":11,"start":5796,"title":"Конкурентный Go и отказ от поколений"},{"chunk_id":"episode-61#c12","idx":12,"start":6200,"title":"G1: регионы и remembered set"},{"chunk_id":"episode-61#c13","idx":13,"start":6939,"title":"Shenandoah и указатели Брукса"},{"chunk_id":"episode-61#c14","idx":14,"start":7451,"title":"ZGC: цветные указатели и виртуальная память"},{"chunk_id":"episode-61#c15","idx":15,"start":8612,"title":"Green Tea в Go: маркировка спанов"},{"chunk_id":"episode-61#c16","idx":16,"start":8835,"title":"Итоги: компактизация, поколения, выбор в Java и Go"},{"chunk_id":"episode-61#c17","idx":17,"start":9131,"title":"Как выбрать GC под свою задачу"},{"chunk_id":"episode-61#c18","idx":18,"start":10059,"title":"Заключение и где копнуть глубже"}],"date":"2026-02-10","duration_sec":10177,"guests":["alexander-lantsov"],"key_takeaways":["Трассирующие сборщики мусора ищут не мусор, а живые объекты: стоимость маркировки пропорциональна количеству достижимых объектов, а не общему размеру хипа.","`Mark-and-Sweep` прост и не двигает объекты (указатели не инвалидируются), но страдает от фрагментации; `Mark-Compact` и копирующий коллектор её решают ценой переноса объектов и позволяют дешёвую аллокацию через bumping pointer.","Гипотеза о поколениях работает только вместе с card table и write-барьером, отслеживающими редкие ссылки из старого поколения в молодое; в Go её нет, потому что escape-анализ и структуры уводят большинство короткоживущих объектов на стек.","Конкурентная маркировка требует барьеров: `SATB` (snapshot-at-the-beginning) ловит запись ссылки из чёрного объекта в белый и перекрашивает, сохраняя инвариант; барьеры дешевы за счёт цепочки ранних `if`.","`CMS` давал конкурентную маркировку, но без дефрагментации накапливал фрагментацию и падал в однопоточный `Full GC` с `Mark-Compact`; `G1` разбивает хип на регионы с remembered set и регулирует паузу, выбирая, сколько регионов собрать (garbage first).","`Shenandoah` сначала защищал перенос указателями Брукса (лишний указатель раздувал объект), в версии 2.0 переехал в `mark word`; поддерживает сжатые указатели, поэтому хорош для небольших хипов с низким latency.","`ZGC` хранит цвет прямо в 64-битном указателе и умеет переносить объекты силами мутаторов; из-за этого не поддерживает сжатые указатели, зато проектировался под гигантские хипы; трюк с мульти-маппингом виртуальной памяти из версии 1.0 в версии 2.0 убрали.","Единого «лучшего» GC нет: `Parallel` — под пропускную способность (Spark), `ZGC`/`Shenandoah` — под низкий latency, `G1` — гибрид и дефолт в Java; выбор нужно проверять профилированием на своей нагрузке, а не «астрологией»."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"The Garbage Collection Handbook","url":"https://gchandbook.org"},{"title":"The Green Tea Garbage Collector — блог Go","url":"https://go.dev/blog/greenteagc"},{"title":"HotSpot JVM GC options cheat sheet — блог Алексея Рагозина","url":"http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html"},{"title":"TCMalloc — аллокатор от Google","url":"https://github.com/google/tcmalloc"},{"title":"The Pragmatic Programmer, 20th Anniversary Edition","url":"https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/"}],"md_url":"https://apkhmv.xyz/podcast/episode-61/index.md","number":61,"season":1,"slug":"episode-61","tags":["сборка мусора","JVM","Go runtime","производительность","низкая задержка"],"title":"#61: Лучший GC: Java и Go","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-61/"},{"abstract":"Александр Пахомов и Иван Чернов (системный архитектор в Островке) разбирают, как выглядит внедрение ИИ не в демках, а в реальном энтерпрайзе. Иван рассказывает про свой путь от GitHub Copilot к Cursor и Claude Code, про безопасную среду на базе LiteLLM и OpenWebUI, три риска информационной безопасности (персданные, коммерческая тайна, и почему код сам по себе ничего не стоит), токеномику и лимиты для пользователей, дообученную локальную модель для переводов, ИИ-ревьюера за 8 центов и Bitter Lesson как рамку для техно-оптимизма. Александр держит контрапункт от лица индивидуального контрибьютора, который просто заливает задачи Opus 4.5 напрямую.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/AI_in_Enterprise.mp3","chapters":[{"chunk_id":"episode-62#c0","idx":0,"start":0,"title":"Клауд-бот как личный ассистент"},{"chunk_id":"episode-62#c1","idx":1,"start":41,"title":"Prompt injection и история OpenClaw"},{"chunk_id":"episode-62#c2","idx":2,"start":163,"title":"Agent Swarm и автоматизация менеджмента"},{"chunk_id":"episode-62#c3","idx":3,"start":491,"title":"GLM 4.7, дешёвые подписки и токеномика"},{"chunk_id":"episode-62#c4","idx":4,"start":769,"title":"Кризис селекции: будущее наступило неравномерно"},{"chunk_id":"episode-62#c5","idx":5,"start":919,"title":"Где юникорны и новые продукты?"},{"chunk_id":"episode-62#c6","idx":6,"start":1124,"title":"iOS/Android и end-to-end тест как definition of done"},{"chunk_id":"episode-62#c7","idx":7,"start":1436,"title":"Philosophy of Software Design и глубокие интерфейсы"},{"chunk_id":"episode-62#c8","idx":8,"start":1732,"title":"Подписки за $200 и кто за них платит"},{"chunk_id":"episode-62#c9","idx":9,"start":1838,"title":"Enterprise: как внедряли ИИ в Островке"},{"chunk_id":"episode-62#c10","idx":10,"start":2238,"title":"Три риска безопасности: код ничего не стоит"},{"chunk_id":"episode-62#c11","idx":11,"start":2637,"title":"Claude разблокировал среду: стек LiteLLM + OpenWebUI"},{"chunk_id":"episode-62#c12","idx":12,"start":2987,"title":"Langfuse, трейсинг промптов и гардрейлы"},{"chunk_id":"episode-62#c13","idx":13,"start":3543,"title":"Какие модели используют power users"},{"chunk_id":"episode-62#c14","idx":14,"start":4136,"title":"Системные аналитики, легаси и цифровой бункер"},{"chunk_id":"episode-62#c15","idx":15,"start":4521,"title":"Совет слушателям"}],"date":"2026-03-09","duration_sec":4550,"guests":["ivan-chernov"],"key_takeaways":["В энтерпрайзе точка контроля — прокси (`LiteLLM` + `OpenWebUI`): она регулирует бюджет, разрешённые модели и `guardrails`, позволяя гонять `Claude Code` без индивидуальной учётки Anthropic через выданный `API`-токен.","Информационная безопасность выделяет три риска работы модели на кодовой базе — персональные данные, коммерческая тайна и credentials; сам по себе код почти ничего не стоит — ценность в договорах, людях и операционке вокруг него.","Пользователям нужны жёсткие лимиты: без ограничения (по умолчанию ~$100/мес на учётку) новички за 36 часов сжигают сотни долларов — ответственность за среду несёт тот, кто её организует, а не пользователи.","Дообученная `LoRA` локальная модель для переводов интерфейса (с `self-judge` по confidence и откатом на краудсорсинг) срезала ~95% затрат и повысила среднее качество относительно краудсорса.","ИИ-ревьюер, реализованный не агентом, а прогоном диффа с задачей и контекстом, дал ~8 центов за ревью против ~$2–3 у `slash review`; ускорил мерж веток на ~10%, хотя precision около 50% и со временем появляется `alert fatigue`.","`Opus 4.5` ревьюит код лучше среднего человека и лишён негативных предубеждений; при правильно поданном контексте даже `Sonnet` даёт примерно те же замечания, что и человек, — после линтеров и тестов остаётся «сэничек здравомыслия».","Обсуждать языки программирования теперь имеет смысл не по синтаксису, а по `capabilities` (borrow checker, система типов) и тулингу — модель сама решит, как писать; TypeScript силён по скорости попадания с первого раза, Rust даёт гарантию «собралось — работает».","`Bitter Lesson`: масштаб вычислений бьёт хитрые алгоритмы, и узкое место сместилось с людей на деньги — грамотную команду инженеров всё чаще заменяют время и бюджет на токены и GPU."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"The Bitter Lesson — Rich Sutton (2019)","url":"http://www.incompleteideas.net/IncIdeas/BitterLesson.html"},{"title":"A Philosophy of Software Design — John Ousterhout","url":"https://web.stanford.edu/~ouster/cgi-bin/aphilosophyofsoftwaredesign.php"},{"title":"LiteLLM — прокси для LLM","url":"https://www.litellm.ai"},{"title":"Open WebUI","url":"https://openwebui.com"},{"title":"Langfuse — трейсинг и телеметрия LLM","url":"https://langfuse.com"},{"title":"Amazon Bedrock","url":"https://aws.amazon.com/bedrock/"},{"title":"Ostrovok.ru","url":"https://ostrovok.ru"}],"md_url":"https://apkhmv.xyz/podcast/episode-62/index.md","number":62,"season":1,"slug":"episode-62","tags":["ИИ в энтерпрайзе","Claude Code","локальные модели","информационная безопасность","токеномика LLM"],"title":"#62: AI в Энтерпрайзе","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-62/"},{"abstract":"Александр Пахомов и Иван Закутний (инженер и engineering manager, ученик мастерской инженеров-менеджеров Анатолия Левенчука) разбирают, как остаться востребованным инженером в 2026 году, когда `Claude Code` и агенты обесценили «перекладывание JSON». Их ответ — системное мышление и `First Principles Framework` (FPF) Левенчука: спецификация на ~800 тысяч токенов, которая через RAG заставляет LLM рассуждать по ADI-циклу (abduction–deduction–induction), формализовать уровни доверия L0/L1/L2 и оставлять за собой decision records. По пути — почему галлюцинируют и люди, и модели, чем задача отличается от проблемы, зачем нужно «мышление письмом» и экзокортекс, и как не свалиться в дофаминовую яму от четырёх параллельных агентов.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/63_FPF.mp3","chapters":[{"chunk_id":"episode-63#c0","idx":0,"start":0,"title":"Заходим в «виртуальный бар»"},{"chunk_id":"episode-63#c1","idx":1,"start":35,"title":"Как остаться у кормушки: она не сужается"},{"chunk_id":"episode-63#c2","idx":2,"start":269,"title":"Узкая специализация против конкуренции с моделями"},{"chunk_id":"episode-63#c3","idx":3,"start":473,"title":"Инженеры и CEO движутся навстречу (FOMO)"},{"chunk_id":"episode-63#c4","idx":4,"start":711,"title":"Системное мышление и мастерская инженеров-менеджеров"},{"chunk_id":"episode-63#c5","idx":5,"start":896,"title":"Что такое FPF — First Principles Framework"},{"chunk_id":"episode-63#c6","idx":6,"start":1531,"title":"ADI-цикл: abduction, deduction, induction"},{"chunk_id":"episode-63#c7","idx":7,"start":1853,"title":"Задача против проблемы; когда замедляться по Канеману"},{"chunk_id":"episode-63#c8","idx":8,"start":2227,"title":"Как применять FPF: проект в ChatGPT и RAG"},{"chunk_id":"episode-63#c9","idx":9,"start":2671,"title":"Интеграция в Claude Code, skill-pack, Qwen Code"},{"chunk_id":"episode-63#c10","idx":10,"start":3236,"title":"Прокачивать надо собственные мозги"},{"chunk_id":"episode-63#c11","idx":11,"start":3574,"title":"Agile, Scrum и код-ревью на пенсию"},{"chunk_id":"episode-63#c12","idx":12,"start":4310,"title":"Уровни доверия L0/L1/L2 и decision records"},{"chunk_id":"episode-63#c13","idx":13,"start":4838,"title":"Дофаминовая яма и контекст-свитчинг"},{"chunk_id":"episode-63#c14","idx":14,"start":5745,"title":"Мышление письмом, экзокортекс и личный блог"},{"chunk_id":"episode-63#c15","idx":15,"start":6449,"title":"Moldbook, prompt injection и заключение"}],"date":"2026-03-20","duration_sec":6855,"guests":["ivan-zakutniy"],"key_takeaways":["Кормушка не сужается, а возвращается к норме: написание кода всегда было ~5–15% работы, а с `Claude Code` этот навык обесценился — ценность смещается к системной инженерии и менеджменту.","Узкая специализация в старом смысле (оптимизировать горячие пути, переписывать на ассемблер) ведёт к прямой конкуренции с моделями; выигрывает дженералист-инженер-менеджер, который умеет правильно делегировать.","`First Principles Framework` (FPF) Анатолия Левенчука — спецификация ~65 тысяч строк / ~800 тысяч токенов, дистиллирующая практики системного мышления в контекст для LLM; целиком в контекст не влезает.","Базовый приём FPF — ADI-цикл: `abduction` (выдвинуть гипотезы), `deduction` (проанализировать, на чём они основаны), `induction` (проверить минимальным POC/тестом); он же — ядро научного подхода.","Лучший практический способ применения FPF — не агент, а проект в `ChatGPT Pro` (Extended Thinking): туда drag-and-drop'ом кладётся Markdown-спека, индексируется под RAG, и модель начинает рассуждать по FPF даже в бытовых вопросах.","FPF формализует уровни доверия (L0 — сырая гипотеза, L1 — подтверждённая источником, L2 — проверенная) и оставляет decision records с датой и причинами — экзокортекс, к которому можно вернуться через недели.","Задача — то, что ты уже умеешь решать (замедляться не надо); проблема требует затормозить и включить «медленное мышление» по Канеману — тут и полезны FPF, TDD и BDD, а `code review` и Agile-церемонии обесцениваются.","«Мышление письмом» остаётся тренажёром собственных мозгов и маркером сильного инженера: те, кого не увольняют и зовут на работу, обычно ведут текстовый блог; голосовые интерфейсы хороши для команд, но не для моделирования."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Гарри Поттер и методы рационального мышления — Элиезер Юдковский","url":"https://hpmor.com/"},{"title":"Школа системного менеджмента (Анатолий Левенчук)","url":"https://system-school.ru/"},{"title":"Блог Анатолия Левенчука (ailev)","url":"https://ailev.livejournal.com/"}],"md_url":"https://apkhmv.xyz/podcast/episode-63/index.md","number":63,"season":1,"slug":"episode-63","tags":["системное мышление","вайб-кодинг","ИИ-агенты","инженерный менеджмент","промпт-инжиниринг"],"title":"#63: Системное мышление для инженера","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-63/"},{"abstract":"Александр Пахомов и Алексей Лебедев — инженер систем низкой задержки, создатель стриминговой платформы AlgoX2 («убийца Kafka») и открытого фреймворка кодогенерации OpenACR — разбирают, как строить большие системы из простых, доказуемо корректных частей. Первые два часа сознательно исключают «агентную разработку»: single entry / single exit и single static action, программа как вложенные циклы и глобальная in-memory база данных, отказ от исключений и многопоточности в пользу однопоточных процессов, общающихся сообщениями (CSP, RDMA/InfiniBand, scale-out). На этом фундаменте построена AlgoX2 — «файловая система из стримов», где всё есть append-only-стрим и управление идёт через тот же стриминг; она обгоняет Kafka по latency в 10–100 раз. Ядро системы генерируется из SSIM-описаний генератором, который на 95% состоит из собственного сгенерированного кода. В финале — как Claude Code усиливает такой подход и какой навык остаётся ключевым для инженера.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/64_Alexey_Lebedev.mp3","chapters":[{"chunk_id":"episode-64#c0","idx":0,"start":0,"title":"Вступление"},{"chunk_id":"episode-64#c1","idx":1,"start":98,"title":"Single entry, single exit: программа как вложенные циклы"},{"chunk_id":"episode-64#c2","idx":2,"start":830,"title":"Транспонированная модель, flowchart и самоподобность"},{"chunk_id":"episode-64#c3","idx":3,"start":1678,"title":"Single static action и единая база данных стейта"},{"chunk_id":"episode-64#c4","idx":4,"start":2076,"title":"Глобальные переменные, DOM и отказ от ООП"},{"chunk_id":"episode-64#c5","idx":5,"start":2569,"title":"Исключения как многоуровневый return; про баги"},{"chunk_id":"episode-64#c6","idx":6,"start":2813,"title":"Однопоточные процессы и Communicating Sequential Processes"},{"chunk_id":"episode-64#c7","idx":7,"start":3165,"title":"HFT, InfiniBand и scale-out через RDMA"},{"chunk_id":"episode-64#c8","idx":8,"start":3571,"title":"AlgoX2: всё есть стрим, /sys/cmd и Distributed OS"},{"chunk_id":"episode-64#c9","idx":9,"start":3963,"title":"Как устроена Kafka: брокер, topic, partition, offset"},{"chunk_id":"episode-64#c10","idx":10,"start":4560,"title":"Scale-out через multicast: latency против throughput"},{"chunk_id":"episode-64#c11","idx":11,"start":4958,"title":"Путь записи в AlgoX2: секвенсор и ACK level"},{"chunk_id":"episode-64#c12","idx":12,"start":5327,"title":"Commit, NVMe, wear-leveling и append-only"},{"chunk_id":"episode-64#c13","idx":13,"start":5878,"title":"Цифры против Kafka: latency в 10–100 раз"},{"chunk_id":"episode-64#c14","idx":14,"start":6042,"title":"Кодогенерация: OpenACR, SSIM и model-компилятор"},{"chunk_id":"episode-64#c15","idx":15,"start":6822,"title":"Самоприменимость: Lisp REPL, self-hosting генератор"},{"chunk_id":"episode-64#c16","idx":16,"start":8030,"title":"Возвращение в 2026: Claude Code и эта система"},{"chunk_id":"episode-64#c17","idx":17,"start":8609,"title":"Опыт с Claude Code: «велосипед» для инженера"},{"chunk_id":"episode-64#c18","idx":18,"start":8997,"title":"Какой навык остаётся ключевым; финал"}],"date":"2026-04-20","duration_sec":9296,"guests":["alexei-lebedev"],"key_takeaways":["Single entry / single exit (SESE) делает программу самоподобной: любой блок можно вырезать и вставить как одну строку в другой, а к каждой точке привязать инвариант в духе preconditions Дейкстры; из этого же следует запрет на исключения — `throw` есть многоуровневый `return` на неизвестно сколько уровней вверх.","Single static action: любое поле любой структуры пишется ровно в одном месте кода, поэтому весь стейт можно держать в единой глобальной in-memory-«базе данных» `db` — глобальные переменные не вредны сами по себе, вредна их модификация из разных мест.","Программы у Лебедева однопоточные; масштабирование — не потоками, а деревом процессов, общающихся только сообщениями (идея из `Communicating Sequential Processes` Хоара, наследники — каналы Go и Plan 9 / 9P).","Ставка на однопоточность оправдалась через scale-out: RDMA-карты (InfiniBand/Mellanox, теперь внутри Nvidia) пишут байт в память соседнего хоста за ~600 нс с kernel bypass и умеют multicast — «железо догонит», а latency между дата-центром и одним компьютером объяснять не нужно.","AlgoX2 — «Distributed OS», где всё есть append-only-стрим (2^64 сообщений, две операции: дописать и прочитать), а управление кластером идёт через служебный стрим `/sys/cmd`, который каждый процесс читает с нуля; Kafka по сути single-host-система, а её `topic` + `partition` — это просто стрим.","Внутренние компоненты работают с `ACK level` 1 (сообщение существует в одном экземпляре), внешние потребители — с уровнем 2–3 (реплицировано и надёжно); один и тот же механизм подписки реализует и то, и другое.","Хранение — строго append-only ради NVMe: флеш нельзя перезаписать без стирания блока (wear-leveling), при random-write включается garbage collection и производительность падает в ~100 раз; свой движок пишет и данные, и индекс в один файл (структура «Log Structured Try»).","Ядро системы задаётся `SSIM`-файлами (реляционные key-value-записи) и генерируется фреймворком OpenACR (`acr`/`amc`): на одну рукописную строку приходится ~20–25 сгенерированных, ~95% кода генерирует генератор, который сам на 95% состоит из собственного сгенерированного кода — без темплейтов, с одним breakpoint на функцию.","AlgoX2 обгоняет Kafka по latency в 10–100 раз (например 50 мкс против 5 мс) и по throughput в десятки раз под нагрузками с жёстким окном задержки; при насыщении ресурсов, где Kafka упирается в железо, преимущества нет.","Claude Code для Лебедева — «велосипед»: он написал почти весь движок, попав туда же, куда дошёл бы пешком; маленький код, делающий много, умещается в голову, а дефицитным ресурсом инженера становится время и умение решать, где углубиться, а что делегировать модели."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"OpenACR — фреймворк кодогенерации (acr/amc, SSIM) Алексея Лебедева","url":"https://github.com/alexeilebedev/openacr"},{"title":"Communicating Sequential Processes — C.A.R. Hoare","url":"https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf"},{"title":"LevelDB — движок хранения на основе LSM (Jeff Dean, Sanjay Ghemawat)","url":"https://github.com/google/leveldb"},{"title":"Apache Pulsar — распределённая стриминговая платформа","url":"https://pulsar.apache.org"},{"title":"SPDK — Storage Performance Development Kit (доступ к NVMe из user space)","url":"https://spdk.io"}],"md_url":"https://apkhmv.xyz/podcast/episode-64/index.md","number":64,"season":4,"slug":"episode-64","tags":["распределённые системы","кодогенерация","низкая задержка","Kafka и стриминг","вайб-кодинг"],"title":"#64: Быстрее Кафки на два порядка: Алексей Лебедев про то как строить сложные системы","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-64/"},{"abstract":"Александр Пахомов и Дмитрий (Kisa) — автор канала о нейросетях, пришедший в вайб-кодинг из криптоиндустрии, — разбирают, как генеративный AI меняет работу автора и инженера: где проходит граница между авторским контентом и «нейрослопом», как через `Claude Code` и `Remotion` собираются YouTube-ролики, и почему картиночная ниша (включая 18+) держится на китайских open-source-моделях и локальных `ComfyUI`-воркфлоу, а не на зацензуренных фронтир-моделях. Во второй половине — теория «мёртвого интернета», выгорание от скорости агентов, деградация моделей (`4.6` против `4.7`, кодекс) и большой мотивационный разговор про ответственность и «эпоху эгоистов».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/65_AI_.mp3","chapters":[{"chunk_id":"episode-65#c0","idx":0,"start":0,"title":"Холодный интро: главное — не быть глупым"},{"chunk_id":"episode-65#c1","idx":1,"start":64,"title":"Как Дима пришёл в вайб-кодинг из крипты"},{"chunk_id":"episode-65#c2","idx":2,"start":487,"title":"Знакомство: Kisa, криптомедиа и блог про нейросети"},{"chunk_id":"episode-65#c3","idx":3,"start":646,"title":"Claude как новый интерфейс: Remotion и ролики"},{"chunk_id":"episode-65#c4","idx":4,"start":1054,"title":"Нейрослоп против авторского контента"},{"chunk_id":"episode-65#c5","idx":5,"start":1310,"title":"Код утилитарен, а текст и голос — авторские"},{"chunk_id":"episode-65#c6","idx":6,"start":1677,"title":"Теория мёртвого интернета"},{"chunk_id":"episode-65#c7","idx":7,"start":1916,"title":"Что дальше: сингулярность и философия"},{"chunk_id":"episode-65#c8","idx":8,"start":2078,"title":"Плыть по течению: вайб-кодинг как поток"},{"chunk_id":"episode-65#c9","idx":9,"start":2640,"title":"Сон, отдых и выгорание от скорости агентов"},{"chunk_id":"episode-65#c10","idx":10,"start":2939,"title":"Деградация моделей: 4.6 против 4.7 и кодекс"},{"chunk_id":"episode-65#c11","idx":11,"start":3977,"title":"Генерация картинок и ниша 18+"},{"chunk_id":"episode-65#c12","idx":12,"start":4736,"title":"Дипфейки, секс и мёртвый интернет"},{"chunk_id":"episode-65#c13","idx":13,"start":5067,"title":"Нищепанк, комплекс бога и «сахарная» аналогия"},{"chunk_id":"episode-65#c14","idx":14,"start":5460,"title":"Нормесы, эго и гигиена работы с AI"},{"chunk_id":"episode-65#c15","idx":15,"start":6020,"title":"Ответственность, «эпоха эгоистов» и мотивационный финал"}],"date":"2026-05-19","duration_sec":6909,"guests":["kisa"],"key_takeaways":["Граница между авторским контентом и «нейрослопом» — в предпосылке: генерируешь текст/голос ради трафика (слоп) или используешь нейросеть как инструмент, оставляя авторство (сценарий, голос, вкус) за собой.","`Claude Code` — это агент, обученный управлять системой, поэтому им можно делать что угодно, а не только писать код: ролики в `Remotion` (React-кадры, которые пишет сам Claude), обложки через CSS-графику, вызов внешних image-моделей по API.","Хайп `Claude Code` в массах начался с выхода `Opus 4.5`: до него код приходилось ревьюить и направлять, после — задаёшь спецификации и архитектуру, а код и тесты модель пишет почти автономно.","18+-генерация и провокационный контент держатся на локальных китайских open-source-моделях (`ComfyUI`-воркфлоу, Lora, `Wan`, `Seedance`, `Kling`), потому что фронтир-модели зацензурены; коммерческих open-source-моделей под баннеры/обложки при этом нет.","Теория «мёртвого интернета» (2020) сбылась: в 2026 объём AI-контента превысил человеческий — существуют сервисы, автоматизирующие и написание постов, и комментарии-реплаи ботами, чтобы привлечь живой трафик.","Скорость агентов вызывает новый тип выгорания: пятидневная задача схлопывается до 20 минут, и человек не успевает осознать, что построил, — лечится только настоящим перерывом на неделю, а не «дотягиванием лямки».","Инструкции агенту (`AGENTS.md`, память) лучше всего пишет и понимает та же модель, что их создала: markdown, написанный `Opus` под себя, хуже воспринимается `GPT`, и при смене модели инструкции приходится переписывать.","Дипфейки с политиками не взлетели, а 18+-генерация стала целой индустрией — вероятно, потому что аналитическая часть мозга сразу «палит» фейк-политика, а древняя (либидо) на сгенерированность не реагирует; секс по-прежнему продаёт."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Remotion — видео на React","url":"https://www.remotion.dev"},{"title":"ComfyUI — нодовый интерфейс для генеративных моделей","url":"https://github.com/comfyanonymous/ComfyUI"},{"title":"Cursor — AI-редактор кода","url":"https://cursor.com"},{"title":"Polymarket — рынок предсказаний","url":"https://polymarket.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-65/index.md","number":65,"season":4,"slug":"episode-65","tags":["вайб-кодинг","генеративный AI","нейрослоп и авторство","генерация изображений","мёртвый интернет"],"title":"#65: AI-кисы: нейрослоп против авторского контента","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-65/"},{"abstract":"Александр Пахомов и Михаил Костицын (разработчик кодинг-агента veai, IDE-native агента для JetBrains IDE) по шагам «собирают» кодинг-агента: от ассистента-чата к агенту с инструментами — терминалом, чтением/записью файлов, поиском — и разбирают ключевой трейд-офф между свободой (один универсальный терминал) и контролем (набор узких, надёжных тулов), а также контекст-менеджмент как главный ресурс. Отталкиваясь от IntelliJ-платформы, они показывают, что даёт агенту IDE поверх терминала — LSP и PSI, инспекции, декомпиляцию, дебаггер и «формальные методы» (инструментация байткода, анализ моргающих тестов, символьное исполнение, SAST), — и обсуждают enterprise-спрос на локальные модели, бенчмарк-систему veai с верифайерами и LLM-судьёй, проблему бенчмаксинга и dogfooding.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/18_alex_podcast.mp3","chapters":[{"chunk_id":"episode-66#c0","idx":0,"start":0,"title":"Вступление: гость, veai и голос ведущего"},{"chunk_id":"episode-66#c1","idx":1,"start":141,"title":"Что такое кодинг-агент: от ассистента к агенту"},{"chunk_id":"episode-66#c2","idx":2,"start":301,"title":"Первый инструмент: tool-call-токен и описание для модели"},{"chunk_id":"episode-66#c3","idx":3,"start":881,"title":"Аналогия «мозг в банке»"},{"chunk_id":"episode-66#c4","idx":4,"start":1236,"title":"Дизайн тулов: чтение, запись, поиск, список файлов"},{"chunk_id":"episode-66#c5","idx":5,"start":1845,"title":"Терминал: свобода против контроля и безопасности"},{"chunk_id":"episode-66#c6","idx":6,"start":2640,"title":"Билд и тесты: IDE как абстракция над языками"},{"chunk_id":"episode-66#c7","idx":7,"start":3236,"title":"CLI- против IDE-агентов; выбор IDE"},{"chunk_id":"episode-66#c8","idx":8,"start":3698,"title":"LSP: синтаксис и AST в редакторе кода"},{"chunk_id":"episode-66#c9","idx":9,"start":4130,"title":"PSI: семантика поверх AST и findUsages"},{"chunk_id":"episode-66#c10","idx":10,"start":4792,"title":"Инспекции IntelliJ как инструмент; история с ID-инспектом"},{"chunk_id":"episode-66#c11","idx":11,"start":5315,"title":"Декомпиляция и месяц с ReSharper в Rider"},{"chunk_id":"episode-66#c12","idx":12,"start":5983,"title":"Дебаггер внутри агента"},{"chunk_id":"episode-66#c13","idx":13,"start":6773,"title":"Enterprise и безопасность: локальные модели"},{"chunk_id":"episode-66#c14","idx":14,"start":7312,"title":"Формальные методы: инструментация и анализы"},{"chunk_id":"episode-66#c15","idx":15,"start":7811,"title":"Метрика успеха: бенчмарки, верифайеры и судья"}],"date":"2026-06-03","duration_sec":8799,"guests":["mikhail-kositsyn"],"key_takeaways":["Кодинг-агент = LLM плюс чат плюс инструменты: инструмент — это функция `input → output`, о которой модель узнаёт через специальный tool-call-токен и описание в системном промпте.","Каждый добавленный тул живёт в «горячем» контексте, который гоняется на каждом шаге; лишние тулы (и MCP, и скиллы) съедают контекст, а после ~80–85% заполнения модели начинают деградировать — проверяйте это через `/context`.","Главный трейд-офф — один универсальный терминал (безграничная свобода, но и безграничное пространство ошибок и риск безопасности) против набора узких, надёжных тулов (`read`, `write`, `search`, `ls`), которые контролируемы и экономят токены; практичное решение — совмещать, оставив терминал на крайний случай.","IDE — это готовая абстракция над language-specific туллингом: вместо отдельных тулов на каждый язык агенту дают высокоуровневые `build`/`test`/`fmt`, которые инкапсулируют язык внутри, а IntelliJ-платформа определяет язык проекта через включённые плагины.","`LSP` приносит в редактор синтаксис (лексер + парсер → AST) и базовый автокомплит; `PSI` (Program Structure Interface) в IntelliJ добавляет семантику — `findUsages`, различение использования и override — и потому куда лучше подходит как инфраструктура для агента, чем греп в терминале.","IDE-инспекции, декомпиляция и дебаггер — киллер-инструменты для агента: инспекции дают статический анализ без запуска, декомпилятор превращает `.class`/зависимости без документации в читаемые исходники, а встроенный дебаггер (breakpoint + evaluate expression) экономит время и токены против цикла «добавь принт → пересобери».","Ставка veai на IntelliJ обоснована enterprise-спросом: банки и финтех не готовы «сливать код в Anthropic», поэтому нужны локальные модели в контуре (`GLM`, `DLP`-шлюз), а мощные IDE-тулы позволяют слабее-догадливым моделям работать надёжно.","Качество агента veai мерят бенчмарк-системой с эмулятором пользователя, жёсткими верифайерами (сборка/тесты/покрытие) и LLM-судьёй; набор верифайеров работает как система сдержек и противовесов против бенчмаксинга, а поверх всего — ручное QA и dogfooding."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"veai — IDE-native AI-агент для JetBrains IDE","url":"https://veai.ru"},{"title":"Claude Code","url":"https://www.anthropic.com/claude-code"}],"md_url":"https://apkhmv.xyz/podcast/episode-66/index.md","number":66,"season":4,"slug":"episode-66","tags":["кодинг-агенты","ИИ-агенты","IntelliJ платформа","инструменты для LLM","контекст-менеджмент","локальные модели"],"title":"#66: Veai: БАЗА ПО КОДИНГ АГЕНТАМ","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-66/"},{"abstract":"Александр Пахомов и Миша Поливаха — практикующий Java-разработчик, стоявший у истоков сообщества Spring.io, — разбирают, на чём держится Java в 2026-м. Почему энтерпрайз не переписывает и не апгрейдит (патчинг CVE для Java 6 как живой бизнес), как Spring выиграл у Java EE на скорости эволюции и правильных продуктовых решениях Рода Джонсона и команды Spring Boot, чем занят Project Leyden и почему AppCDS отбирает у Quarkus его главное преимущество. Вторая половина — спор двух подходов: для гостя тулинг это IDE, стартеры и dev mode, для ведущего, который код руками не пишет, — quality gates, которыми обкладывают агента; отсюда претензии к Java-экосистеме на фоне `clippy --fix`, история отказа OpenJDK принимать сгенерированные PR и финальное расхождение о том, можно ли нарастить экспертизу, не написав код руками.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/alex_podcast_19.mp3","chapters":[{"chunk_id":"episode-67#c0","idx":0,"start":0,"title":"Гость: Java, Spring.io и конференции"},{"chunk_id":"episode-67#c1","idx":1,"start":51,"title":"Что сейчас происходит в JVM-мире"},{"chunk_id":"episode-67#c2","idx":2,"start":290,"title":"Консолидация против «библиотеки из Небраски»"},{"chunk_id":"episode-67#c3","idx":3,"start":374,"title":"Сертификации Oracle и вьетнамские флешбеки"},{"chunk_id":"episode-67#c4","idx":4,"start":463,"title":"Почему энтерпрайз не переписывает и не апгрейдит"},{"chunk_id":"episode-67#c5","idx":5,"start":847,"title":"«Работает — не трожь» и взаимозаменяемые юниты"},{"chunk_id":"episode-67#c6","idx":6,"start":940,"title":"Кроме Spring, ничего нет"},{"chunk_id":"episode-67#c7","idx":7,"start":993,"title":"Род Джонсон и боли Java EE"},{"chunk_id":"episode-67#c8","idx":8,"start":1048,"title":"Что такое Java EE и откуда взялась Java"},{"chunk_id":"episode-67#c9","idx":9,"start":1252,"title":"Eclipse Foundation как чердак истории"},{"chunk_id":"episode-67#c10","idx":10,"start":1469,"title":"Почему Java EE проиграла: JSR-305 и медленная эволюция"},{"chunk_id":"episode-67#c11","idx":11,"start":1697,"title":"Появляется Spring Boot"},{"chunk_id":"episode-67#c12","idx":12,"start":1822,"title":"Дефолты, которые никто не переопределяет"},{"chunk_id":"episode-67#c13","idx":13,"start":1980,"title":"Quarkus и ставка на Jakarta EE"},{"chunk_id":"episode-67#c14","idx":14,"start":2255,"title":"Project Leyden, AppCDS и ramp-up"},{"chunk_id":"episode-67#c15","idx":15,"start":2621,"title":"JEP'ы, PetClinic и связка Oracle со Spring"},{"chunk_id":"episode-67#c16","idx":16,"start":2904,"title":"Как ведущий писал Spring Boot-стартеры"},{"chunk_id":"episode-67#c17","idx":17,"start":3045,"title":"Продуктовый майндсет Рода Джонсона"},{"chunk_id":"episode-67#c18","idx":18,"start":3347,"title":"Догфудинг и лидер, принимающий решения"},{"chunk_id":"episode-67#c19","idx":19,"start":3609,"title":"Что даёт IntelliJ: дебаггер, декомпиляция, база данных"},{"chunk_id":"episode-67#c20","idx":20,"start":3779,"title":"Поддержка фреймворков и сборщиков"},{"chunk_id":"episode-67#c21","idx":21,"start":4194,"title":"Quality gates: Spotless, Error Prone, NullAway"},{"chunk_id":"episode-67#c22","idx":22,"start":4353,"title":"Тулинг глазами оператора агентов"},{"chunk_id":"episode-67#c23","idx":23,"start":4589,"title":"Спор о форматтерах: культура или тулинг"},{"chunk_id":"episode-67#c24","idx":24,"start":4870,"title":"Время запуска и цикл обратной связи для агента"},{"chunk_id":"episode-67#c25","idx":25,"start":4982,"title":"Что на самом деле долгое в Java-билде"},{"chunk_id":"episode-67#c26","idx":26,"start":5386,"title":"Кэширование Spring-контекстов и флаки-тесты"},{"chunk_id":"episode-67#c27","idx":27,"start":5571,"title":"Останется ли Java для новых проектов"},{"chunk_id":"episode-67#c28","idx":28,"start":5954,"title":"Мы пережили Stack Overflow"},{"chunk_id":"episode-67#c29","idx":29,"start":6158,"title":"Род Джонсон делает фреймворк для агентов"},{"chunk_id":"episode-67#c30","idx":30,"start":6306,"title":"Почему агенты ломаются на обновлениях"},{"chunk_id":"episode-67#c31","idx":31,"start":6596,"title":"Spring AI: зонтик проектов"},{"chunk_id":"episode-67#c32","idx":32,"start":6878,"title":"Почему у Spring нет своих скиллов"},{"chunk_id":"episode-67#c33","idx":33,"start":7093,"title":"OpenJDK не принимает сгенерированные PR"},{"chunk_id":"episode-67#c34","idx":34,"start":7384,"title":"Боттлнек не в коде, а в ревью и дизайне"},{"chunk_id":"episode-67#c35","idx":35,"start":7575,"title":"Позиция Линуса: несите ответственность за свой код"},{"chunk_id":"episode-67#c36","idx":36,"start":7876,"title":"Экспертиза как то, что дорожает"},{"chunk_id":"episode-67#c37","idx":37,"start":8257,"title":"Не подпускать агента туда, где учишься"},{"chunk_id":"episode-67#c38","idx":38,"start":8380,"title":"Нейрофизиология: мы учимся руками"},{"chunk_id":"episode-67#c39","idx":39,"start":8614,"title":"Напутствие: развивайте глубину экспертизы"}],"date":"2026-06-16","duration_sec":8726,"guests":["misha-polivakha"],"key_takeaways":["Java держится в энтерпрайзе не техническим превосходством, а консолидацией экосистемы: одна проблема — один канонический способ решения, единый «паровоз» (виртуальные потоки Spring поддержал сразу) и взаимозаменяемость инженеров между командами.","Java EE проиграла Spring на скорости: спецификации согласовывались годами (многострадальный JSR-305 в итоге отозвали, а JSpecify появился уже силами консорциума — Google, JetBrains), и Oracle в конце концов отдал javax в Eclipse Foundation.","Ключевых решений у Spring два: Spring Boot признал, что 80% конфигурации никто не переопределяет, и дал дефолты; и Spring не поворачивался спиной к экосистеме — в отличие от Quarkus, который заперся в Jakarta EE и остался «чёрным лебедем» со своими реализациями всего.","Project Leyden и AppCDS съедают главное преимущество Quarkus — быстрый старт. Команды Oracle и Spring работают настолько плотно, что Spring PetClinic фигурирует в официальных JEP'ах как референсная имплементация.","У собеседников разное понимание тулинга: для Поливахи это то, что помогает писать код (IDE, стартеры, Docker Compose Starter, dev mode), для Пахомова, который код руками не пишет, — quality gates, которыми обкладывают агента, чтобы проще брать на себя ответственность за его код.","Претензия к Java: в Rust `clippy --fix` и `rustfmt` идут батарейкой вместе с языком и снимают сам спор о стиле, а в Java форматтеры и статические анализаторы собираются плагинами — и обсуждения code style живы до сих пор. Контраргумент гостя: это вопрос инженерной культуры и экспрессивности языка, а не тулинга.","Долгий Java-билд — это почти всегда тесты (подъём Spring-контекстов, Testcontainers), а не компиляция: монорепа Axelix с полутора тысячами тестов собирается за две-три минуты.","OpenJDK отказался принимать сгенерированные pull request'ы, потому что у них боттлнек не в написании кода, а в дизайне и согласовании совместимости. Пахомов видит в этом риск остаться за бортом, Поливаха — разумную выжидательную позицию, как у Линуса Торвальдса: «несите ответственность за свой код»."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Spring AI","url":"https://spring.io/projects/spring-ai"},{"title":"Embabel — фреймворк Рода Джонсона для агентов на JVM","url":"https://github.com/embabel/embabel-agent"},{"title":"Spring PetClinic","url":"https://github.com/spring-projects/spring-petclinic"}],"md_url":"https://apkhmv.xyz/podcast/episode-67/index.md","number":67,"season":4,"slug":"episode-67","tags":["Java","Spring","JVM","ИИ-агенты","инструментарий разработчика","экспертиза инженера","код-ревью"],"title":"#67: Java и Spring в 2026","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-67/"},{"abstract":"Александр Пахомов и Владимир Ситников — мейнтейнер PostgreSQL JDBC-драйвера (pgjdbc) и Apache JMeter, около двадцати лет в Java и производительности SQL-систем — разбирают агентскую разработку на конкретных артефактах: тридцать тысяч строк подсистемы кодеков, которые невозможно отревьюить глазами, кросс-ревью тремя моделями, скилл технического английского, появившийся после того, как правки в документацию отклонили как AI-слоп. Обсуждают, что идёт в скилл, а что в CLAUDE.md, APM как пакетный менеджер для агентских конфигов, орду ревьюеров-персон, профилировщик и фаззинг как обязательные гейты агентского SDLC, комментарии, которые описывают прошлое, и декомпиляцию вместо чтения исходников. В финале — где проходят границы моделей и человека и на что инженеру сейчас тратить время.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/20__Alex.mp3","chapters":[{"chunk_id":"episode-68#c0","idx":0,"start":0,"title":"Гость: pgjdbc, JMeter и программные комитеты"},{"chunk_id":"episode-68#c1","idx":1,"start":149,"title":"Project Hub: работа с двадцатью репозиториями"},{"chunk_id":"episode-68#c2","idx":2,"start":250,"title":"Промпт для ревью: код, архитектура или план"},{"chunk_id":"episode-68#c3","idx":3,"start":446,"title":"Тридцать тысяч строк, которые не помещаются в голову"},{"chunk_id":"episode-68#c4","idx":4,"start":533,"title":"Кросс-ревью тремя моделями"},{"chunk_id":"episode-68#c5","idx":5,"start":659,"title":"Куда девать промпты, планы и ресёрчи"},{"chunk_id":"episode-68#c6","idx":6,"start":780,"title":"Скилл кросс-ревью через Codex"},{"chunk_id":"episode-68#c7","idx":7,"start":874,"title":"Инженерная гигиена: брутальное ревью на каждый PR"},{"chunk_id":"episode-68#c8","idx":8,"start":1023,"title":"Свои скиллы против чужих"},{"chunk_id":"episode-68#c9","idx":9,"start":1105,"title":"Скилл технического английского и ярлык «AI-слоп»"},{"chunk_id":"episode-68#c10","idx":10,"start":1366,"title":"Скиллы устареют? Адаптировать модель или себя"},{"chunk_id":"episode-68#c11","idx":11,"start":1522,"title":"Что идёт в скилл, а что в CLAUDE.md"},{"chunk_id":"episode-68#c12","idx":12,"start":1800,"title":"Кто должен писать CLAUDE.md"},{"chunk_id":"episode-68#c13","idx":13,"start":1893,"title":"APM: пакетный менеджер для агентских конфигов"},{"chunk_id":"episode-68#c14","idx":14,"start":2147,"title":"Орда ревьюеров: UX, совместимость, маркетолог"},{"chunk_id":"episode-68#c15","idx":15,"start":2352,"title":"Не производим ли мы слоп для чужих мозгов"},{"chunk_id":"episode-68#c16","idx":16,"start":2482,"title":"Ответ для людей и ответ для агентов"},{"chunk_id":"episode-68#c17","idx":17,"start":2607,"title":"Где смотреть код, а где не смотреть"},{"chunk_id":"episode-68#c18","idx":18,"start":2750,"title":"Недосказанность: что не попадает в pull request"},{"chunk_id":"episode-68#c19","idx":19,"start":2904,"title":"Комментарии, которые описывают прошлое"},{"chunk_id":"episode-68#c20","idx":20,"start":3126,"title":"Модель не умеет оценивать сложность"},{"chunk_id":"episode-68#c21","idx":21,"start":3358,"title":"Тулинг для людей, сорцы для нейронок"},{"chunk_id":"episode-68#c22","idx":22,"start":3507,"title":"Агентские сессии как база знаний проекта"},{"chunk_id":"episode-68#c23","idx":23,"start":3707,"title":"JAVA_HOME, тулчейны и где модель спотыкается"},{"chunk_id":"episode-68#c24","idx":24,"start":3886,"title":"CLAUDE.md: писать только то, где модель накосячила"},{"chunk_id":"episode-68#c25","idx":25,"start":3934,"title":"Скепсис к исследованиям: исследователь сам себя"},{"chunk_id":"episode-68#c26","idx":26,"start":4083,"title":"Инструментарий: терминал, tmux, GitHub"},{"chunk_id":"episode-68#c27","idx":27,"start":4166,"title":"Почему десктоп-приложение вместо CLI"},{"chunk_id":"episode-68#c28","idx":28,"start":4380,"title":"Свой тулинг: дашборды и CLI под себя"},{"chunk_id":"episode-68#c29","idx":29,"start":4559,"title":"Можно ли глазами понять, что код быстрый"},{"chunk_id":"episode-68#c30","idx":30,"start":4754,"title":"Профилировщик как часть агентского SDLC"},{"chunk_id":"episode-68#c31","idx":31,"start":5051,"title":"Фаззинг: случайные байты и структурные объекты"},{"chunk_id":"episode-68#c32","idx":32,"start":5375,"title":"Coverage-guided фаззинг и генетические алгоритмы"},{"chunk_id":"episode-68#c33","idx":33,"start":5509,"title":"PR через шесть лет и +Infinity, найденный перебором"},{"chunk_id":"episode-68#c34","idx":34,"start":5794,"title":"«Шашечки или ехать»: Fable против Opus"},{"chunk_id":"episode-68#c35","idx":35,"start":5895,"title":"Прощупывание пределов моделей"},{"chunk_id":"episode-68#c36","idx":36,"start":6023,"title":"Как Opus написал парсер хипдампа"},{"chunk_id":"episode-68#c37","idx":37,"start":6131,"title":"Логи и CI: скрипт вместо каждого грепа"},{"chunk_id":"episode-68#c38","idx":38,"start":6373,"title":"Декомпиляция вместо чтения исходников"},{"chunk_id":"episode-68#c39","idx":39,"start":6786,"title":"Что стоило бы деливерить вместе с библиотекой"},{"chunk_id":"episode-68#c40","idx":40,"start":7208,"title":"На что инженеру тратить время: границы сферы"},{"chunk_id":"episode-68#c41","idx":41,"start":7316,"title":"Круги Эйлера: границы модели и твои собственные"},{"chunk_id":"episode-68#c42","idx":42,"start":7611,"title":"Писать код руками — потеря времени?"},{"chunk_id":"episode-68#c43","idx":43,"start":7810,"title":"Кто такой современный программист"},{"chunk_id":"episode-68#c44","idx":44,"start":8058,"title":"Дерево Фенвика"},{"chunk_id":"episode-68#c45","idx":45,"start":8222,"title":"Открытый микрофон: в Клоде нет социума"}],"date":"2026-07-12","duration_sec":8363,"guests":["vladimir-sitnikov"],"key_takeaways":["Тридцать тысяч строк кодеков, сгенерированных агентом, человек физически не может отревьюить — выход в том, чтобы ревьюить тем же инструментом: три независимых ревью (Opus, GPT, Fable) плюс кросс-сравнение вердиктов, где каждая модель находит что-то своё.","Промпт «сделай ревью» бесполезен, пока не выбран фокус: построчное ревью, архитектурное или план дальнейших действий — сужение фокуса дало заметно лучший результат на всех моделях.","Скилл технического английского (компиляция публичных style guides) появился после того, как правки в документацию pgjdbc отклонили как AI-слоп; теперь он стоит глобально и, в частности, формирует описание PR — «почему это делается».","Оба сидят на минималистичных сетапах: развесистые чужие скиллы дают контекст-полюшен. Писать стоит только то, на чём модель уже спотыкалась, — к тому же выводу приходит и разбор CLAUDE.md у Тео Брауна.","APM (Microsoft Agent Package Manager) — фактически npm для агентских конфигов: версионируемые пакеты скиллов, хуков и промптов, переносимые между Claude Code и Codex; корпоративные конвенции ставятся одной зависимостью.","Профилировщик и фаззинг должны стать частью агентского SDLC наравне с юнит- и интеграционными тестами: без жёстких верификаторов агент не понимает, где важна производительность, а где — краевые случаи.","Coverage-guided фаззинг (JQF + JetCheck) нашёл в кодеках реальные баги — например, `+Infinity`, подобранный эволюционно, а не «придуманный» моделью. При этом сам код фаззера модель пишет плохо: в обучающих выборках фаззеров почти нет.","Модель не умеет оценивать сложность и экспертность: для неё `A + B` и дерево Фенвика примерно одно и то же — поэтому она не понимает, что комментировать, а что нет, и пишет комментарии про то, почему не работал старый код."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"pgjdbc — PostgreSQL JDBC Driver","url":"https://github.com/pgjdbc/pgjdbc"},{"title":"Apache JMeter","url":"https://jmeter.apache.org"}],"md_url":"https://apkhmv.xyz/podcast/episode-68/index.md","number":68,"season":4,"slug":"episode-68","tags":["ИИ-агенты","Claude Code","Java","PostgreSQL","код-ревью","фаззинг","производительность","контекст-менеджмент"],"title":"#68: Исследуем границы современных моделей вместе Владимиром Ситниковым","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-68/"},{"abstract":"Александр Пахомов и Александр Орлов — сооснователь Школы менеджмента «Стратоплан», ранее Sun Microsystems и Intel, психолог по второму образованию — разбирают работу инженера как психологическую. Почему поток так трудно поймать и удержать, что происходит с командой в фазах форминга и шторминга по Такману и почему спор о скобке в code style на самом деле спор об иерархии и уважении. Обсуждают эго-состояния по Берну, три способа реагировать на неустраивающую ситуацию (изменить, принять, выйти) и четвёртый, худший — терпеть; ресурсы, которые определяют вашу раздражительность на код-ревью; visibility через уровень как механику карьеры. В финале — как агентская разработка поднимает когнитивную нагрузку до потолка и почему soft skills дорожают именно сейчас.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/69_Freud.mp3","chapters":[{"chunk_id":"episode-69#c0","idx":0,"start":0,"title":"Тизер: либидная и мортидная энергия"},{"chunk_id":"episode-69#c1","idx":1,"start":75,"title":"Гость: от Sun и Intel к Школе менеджмента"},{"chunk_id":"episode-69#c2","idx":2,"start":301,"title":"Вторая вышка или психотерапия: что нужнее инженеру"},{"chunk_id":"episode-69#c3","idx":3,"start":464,"title":"Онлайн или офлайн и почему состояние психики влияет на код"},{"chunk_id":"episode-69#c4","idx":4,"start":552,"title":"Недооценённая когнитивная нагрузка общения"},{"chunk_id":"episode-69#c5","idx":5,"start":628,"title":"Что такое поток и как в него попадать"},{"chunk_id":"episode-69#c6","idx":6,"start":754,"title":"Рецепт потока: сон, изоляция, ранние часы"},{"chunk_id":"episode-69#c7","idx":7,"start":926,"title":"Кризисы 30–35 и 40–45; пять утра для себя"},{"chunk_id":"episode-69#c8","idx":8,"start":1149,"title":"Мыслительный эксперимент: собираем команду с нуля"},{"chunk_id":"episode-69#c9","idx":9,"start":1251,"title":"Модель Такмана: форминг, шторминг, норминг, перформинг"},{"chunk_id":"episode-69#c10","idx":10,"start":1467,"title":"Эффект первого дня в детском саду и спор о скобках"},{"chunk_id":"episode-69#c11","idx":11,"start":1721,"title":"«Самая сильная команда, которую я видел»: как убрать шторминг"},{"chunk_id":"episode-69#c12","idx":12,"start":1959,"title":"Руководитель — не родитель и не психолог"},{"chunk_id":"episode-69#c13","idx":13,"start":2087,"title":"За code style прячется борьба за иерархию"},{"chunk_id":"episode-69#c14","idx":14,"start":2248,"title":"Потребности, которые выбирают нас"},{"chunk_id":"episode-69#c15","idx":15,"start":2411,"title":"Как заметить, что вас задело"},{"chunk_id":"episode-69#c16","idx":16,"start":2523,"title":"Ковать железо, пока холодно: пауза вместо срача"},{"chunk_id":"episode-69#c17","idx":17,"start":2686,"title":"Пять ресурсов и почему вы раздражаетесь на код-ревью"},{"chunk_id":"episode-69#c18","idx":18,"start":2855,"title":"Ритуал check-in Джима Маккарти"},{"chunk_id":"episode-69#c19","idx":19,"start":2959,"title":"Созвон, который мог быть письмом"},{"chunk_id":"episode-69#c20","idx":20,"start":3158,"title":"Три способа реагирования — и четвёртый, худший"},{"chunk_id":"episode-69#c21","idx":21,"start":3418,"title":"Эрик Берн: родитель, взрослый, ребёнок"},{"chunk_id":"episode-69#c22","idx":22,"start":3805,"title":"Конструктивная конфронтация и умение слушать"},{"chunk_id":"episode-69#c23","idx":23,"start":4005,"title":"Упражнение «Кулак»"},{"chunk_id":"episode-69#c24","idx":24,"start":4207,"title":"Личность меняется, но не быстрее чем за полгода"},{"chunk_id":"episode-69#c25","idx":25,"start":4410,"title":"Четыре сферы жизни по Пезешкиану"},{"chunk_id":"episode-69#c26","idx":26,"start":4570,"title":"Soft skills на обеих карьерных лестницах"},{"chunk_id":"episode-69#c27","idx":27,"start":4631,"title":"Visibility: кто на самом деле решает вашу карьеру"},{"chunk_id":"episode-69#c28","idx":28,"start":4703,"title":"Почему soft skills дорожают в эпоху агентов"},{"chunk_id":"episode-69#c29","idx":29,"start":4861,"title":"Как агентская разработка меняет команды"},{"chunk_id":"episode-69#c30","idx":30,"start":4990,"title":"Десять окон агентов и потолок когнитивной нагрузки"},{"chunk_id":"episode-69#c31","idx":31,"start":5175,"title":"Заниматься собой как активом"}],"date":"2026-07-29","duration_sec":5397,"guests":["alexander-orlov"],"key_takeaways":["«Десять сеансов психотерапии не помешают никому»: вторая вышка по психологии для инженерной позиции скорее избыточна, а терапия даёт больше — но важен мэтч со специалистом, который складывается не с первой встречи даже по рекомендациям.","На вход в поток уходит 15–20 минут, и любое прерывание обнуляет их; воспроизводимые условия у обоих участников похожи — сон, изоляция, лёгкий стимулятор и ранние часы до того, как открыты рабочие чаты.","Модель Брюса Такмана: группа проходит форминг → шторминг → норминг → перформинг, и это цикл, а не прямая; на первых двух фазах команда работает хуже, чем те же люди поодиночке, а перформинг — это, по сути, командный поток.","Участие команды в найме и честно проговорённая ценность человека («ты лучший из пятидесяти») почти убирают шторминг — но только если это правда: неискренность считывается моментально.","За спором о code style стоит не код, а выстраивание социальной иерархии: кто кого слушает и чьё мнение весит больше. Скобку переставит скрипт — вопрос всегда был не в ней.","Есть три способа реагировать на ситуацию, которая вас не устраивает: изменить, принять или озвучить своё отношение и выйти. Чаще всего выбирают четвёртый — терпеть, и он заканчивается смещением: срывом на коллегах или дома.","Транзактный анализ Берна: конструктив идёт из позиции «взрослый — взрослый», а формальные погоны часто переключают человека в «родителя» — и любая транзакция «родитель — ребёнок» пересекается и вызывает эмоции вместо решения.","«Карьера — это сумма решений, которые в отношении нас принимают другие люди» (Миша Завилейский): отсюда важность visibility через уровень — и сокращения, и повышения решаются на уровень выше вашего непосредственного руководителя."],"lastmod":"2026-09-16T11:54:17+03:00","links":[],"md_url":"https://apkhmv.xyz/podcast/episode-69/index.md","number":69,"season":4,"slug":"episode-69","tags":["психология инженера","soft skills","командная динамика","поток","карьера инженера","тимлид","выгорание"],"title":"#69: Психология инженера с Александром Орловым","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-69/"},{"abstract":"Александр Пахомов и Станислав Лукьянов — коммитер Apache Ignite, инженер GridGain (теперь часть MariaDB), ранее Java Platform в Oracle, последние годы живёт в Нью-Йорке — записывают незапланированный выпуск: интро к разговору про in-memory data grid переросло в двухчасовую беседу о том, как AI меняет работу инженера. Обсуждают 9-9-6 и тревожность по ту сторону океана, поколение AI-native фаундеров, которые не читают код, и то, во что вкладываться сейчас: системное мышление, математику, системное программирование и семантический слой для агента. Вторая половина — про экономику и про себя: токены как новый ресурс и бюджеты, которые растут вместе с грейдом, три грани ответственности, массовая слежка за сессиями и этика чужих промптов, FOMO пятичасового окна, сон, спорт и легализация отдыха на 24 часа без компьютера.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/22__v4.mp3","chapters":[{"chunk_id":"episode-70#c0","idx":0,"start":0,"title":"Вступление: случайность вместо выпуска про базы данных"},{"chunk_id":"episode-70#c1","idx":1,"start":74,"title":"Гость: Apache Ignite, GridGain и переезд в Нью-Йорк"},{"chunk_id":"episode-70#c2","idx":2,"start":168,"title":"9-9-6, Долина и permanent underclass"},{"chunk_id":"episode-70#c3","idx":3,"start":421,"title":"AI-native фаундеры, которые не читают код"},{"chunk_id":"episode-70#c4","idx":4,"start":686,"title":"Опыт инженера: мудрость или якорь"},{"chunk_id":"episode-70#c5","idx":5,"start":876,"title":"Критические секции: где остаётся ценность системного программирования"},{"chunk_id":"episode-70#c6","idx":6,"start":1269,"title":"Математика как запасной план"},{"chunk_id":"episode-70#c7","idx":7,"start":1619,"title":"Системное мышление как универсальный скилл"},{"chunk_id":"episode-70#c8","idx":8,"start":1807,"title":"Онтология системы и семантический слой для агента"},{"chunk_id":"episode-70#c9","idx":9,"start":1982,"title":"«Не можешь объяснить — значит, сделал херню»"},{"chunk_id":"episode-70#c10","idx":10,"start":2090,"title":"Клод смешивает контексты; инженер как психолог"},{"chunk_id":"episode-70#c11","idx":11,"start":2460,"title":"Ванильный Клод против скиллов и контекст-полюшен"},{"chunk_id":"episode-70#c12","idx":12,"start":2904,"title":"Возврат в терминал: git, tmux и наш unfair advantage"},{"chunk_id":"episode-70#c13","idx":13,"start":3285,"title":"Оператор ПК → оператор IntelliJ → оператор Клода"},{"chunk_id":"episode-70#c14","idx":14,"start":3441,"title":"Медицина, «Доктор Хаус» и специализированные операторы Клода"},{"chunk_id":"episode-70#c15","idx":15,"start":3868,"title":"Когнитивная нагрузка: контекст-свитчинг вместо потока"},{"chunk_id":"episode-70#c16","idx":16,"start":4002,"title":"FOMO пятичасового окна и работа инжиниринг-менеджера"},{"chunk_id":"episode-70#c17","idx":17,"start":4365,"title":"Экономика токенов: подписки, энтерпрайз и бюджеты"},{"chunk_id":"episode-70#c18","idx":18,"start":4549,"title":"Мета-харнес: анализ сессий и оптимизация трат"},{"chunk_id":"episode-70#c19","idx":19,"start":4986,"title":"Слежка за сессиями и этика чужих промптов"},{"chunk_id":"episode-70#c20","idx":20,"start":5362,"title":"Бюджет, который растёт вместе с грейдом"},{"chunk_id":"episode-70#c21","idx":21,"start":5622,"title":"Три грани ответственности"},{"chunk_id":"episode-70#c22","idx":22,"start":5950,"title":"Токены как новое электричество"},{"chunk_id":"episode-70#c23","idx":23,"start":6058,"title":"Персональные workflow: NeoVim, tmux и их ROI"},{"chunk_id":"episode-70#c24","idx":24,"start":6304,"title":"Сон и режим дня: сколько агентов ты вытягиваешь"},{"chunk_id":"episode-70#c25","idx":25,"start":7052,"title":"Простить себя: тренды, лупы и графы"},{"chunk_id":"episode-70#c26","idx":26,"start":7426,"title":"Кто реально шипит: вайбкодинг у нетехнических фаундеров"},{"chunk_id":"episode-70#c27","idx":27,"start":7881,"title":"Спорт, добавки и work-life balance"},{"chunk_id":"episode-70#c28","idx":28,"start":8177,"title":"Легализация отдыха: 24 часа без компьютера"},{"chunk_id":"episode-70#c29","idx":29,"start":8328,"title":"Limitless: кем ты хочешь быть через три часа"},{"chunk_id":"episode-70#c30","idx":30,"start":8597,"title":"37signals, чистый стол и Rework"},{"chunk_id":"episode-70#c31","idx":31,"start":8819,"title":"Открытый микрофон"}],"date":"2026-08-14","duration_sec":8941,"guests":["stanislav-lukyanov"],"key_takeaways":["Режим 9-9-6 — история в первую очередь про Долину: в Нью-Йорке это ощущается слабее, но расслоение (инженер в AI-лабе за ~900 тысяч против инженера в банке за 150) заставляет думать об этой гонке даже тех, кто в неё не хочет.","Дифференциация сместилась с механического навыка писать и ревьюить код к умению «видеть лес за деревьями», но в сложных системах старый опыт всё ещё выигрывает: Митчелл Хашимото соптимизировал руками в пятьдесят раз то, что агент ускорил в пять.","Работа с агентом — это построение онтологии и семантического слоя: у модели нет встроенного понимания, что «яблоки надо сравнивать с яблоками», и всё, что попало в контекст, для неё вещи одного порядка.","Оба ведущих сидят на ванильном сетапе: скиллы дают контекст-полюшен, и никто не публикует эвал, который проверял бы, что скилл НЕ инвочится, когда не надо, — на длинной сессии он подгрузится почти наверняка.","Unfair advantage индустрии — не понимание того, как устроены LLM, а пятьдесят лет автоматизации работы с текстом: терминал и `git` оказались лучшей средой для агентов, чем Excel или Google Docs.","Практический совет по токенам: пока вы не выжираете лимиты 20-долларовой подписки — токен-максьте; оптимизировать имеет смысл там, где вы упираетесь в окно. На энтерпрайзе (у Anthropic Team — до 150 мест, дальше Enterprise) включается pay-per-token, и трейд-офф «бюджет против throughput» станет темой 2027 года.","Прогноз к 2030-му: бюджет на агентов станет частью грейда — джуну двадцатидолларовая подписка, staff-инженеру тысячи долларов, principal — десятки тысяч; отчитываться придётся и за перерасход, и за недоиспользование бюджета.","Ответственность распадается на три грани — accountability за ресурсы, принятие рисков (one neck to chop) и ownership; централизованный анализ сессий даёт организации value, но неизбежно превращается в массовую слежку, поэтому агрегаты должны быть за семью замками."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Apache Ignite","url":"https://ignite.apache.org"},{"title":"GridGain","url":"https://www.gridgain.com"},{"title":"Ghostty — терминал Митчелла Хашимото","url":"https://ghostty.org"},{"title":"37signals","url":"https://37signals.com"}],"md_url":"https://apkhmv.xyz/podcast/episode-70/index.md","number":70,"season":4,"slug":"episode-70","tags":["ИИ-агенты","Claude Code","контекст-менеджмент","карьера инженера","продуктивность","экономика токенов","системное программирование"],"title":"#70: Режим 9-9-6 для Claude","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-70/"},{"abstract":"Александр Пахомов и Станислав Лукьянов разбирают in-memory data grid снизу вверх: от локальной HashMap до распределённого хранилища с логическими шардами, репликами, консенсусом и SQL. На примере Apache Ignite они показывают, как коллокация данных и вычислений убирает сетевые пересылки, зачем Java-системы ушли в off-heap и где остаются проблемы GC, JIT, безопасности и эксплуатации. В финале формулируют критерии выбора такой технологии и обсуждают её возможное будущее в памяти агентов и LLM KV-кэшах.","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/71_IMDG_Apache_Ignite.mp3","chapters":[{"chunk_id":"episode-71#c0","idx":0,"start":0,"title":"Вступление: Ignite"},{"chunk_id":"episode-71#c1","idx":1,"start":60,"title":"Как Apache Ignite стал технологическим феноменом"},{"chunk_id":"episode-71#c2","idx":2,"start":486,"title":"Что такое in-memory data grid"},{"chunk_id":"episode-71#c3","idx":3,"start":790,"title":"Серверная обработка и бесконечная мапа"},{"chunk_id":"episode-71#c4","idx":4,"start":1180,"title":"От Java HashMap к распределённому хранилищу"},{"chunk_id":"episode-71#c5","idx":5,"start":1635,"title":"Как разложить огромную мапу по машинам"},{"chunk_id":"episode-71#c6","idx":6,"start":2016,"title":"Эластичное шардирование: consistent и rendezvous hashing"},{"chunk_id":"episode-71#c7","idx":7,"start":2686,"title":"High availability начинается с репликации данных"},{"chunk_id":"episode-71#c8","idx":8,"start":3007,"title":"CAP-теорема: консистентность или доступность при разделении"},{"chunk_id":"episode-71#c9","idx":9,"start":3484,"title":"Подтверждение записи: от Primary Sync до Raft"},{"chunk_id":"episode-71#c10","idx":10,"start":3785,"title":"За пределами key-value: документы и SQL"},{"chunk_id":"episode-71#c11","idx":11,"start":4178,"title":"Decision support без превращения в OLAP"},{"chunk_id":"episode-71#c12","idx":12,"start":4348,"title":"Зачем SQL понадобился поверх хеш-мап"},{"chunk_id":"episode-71#c13","idx":13,"start":4699,"title":"Распределённый SQL, частичные результаты и shuffle"},{"chunk_id":"episode-71#c14","idx":14,"start":5207,"title":"Коллокация: связанные данные должны лежать вместе"},{"chunk_id":"episode-71#c15","idx":15,"start":5797,"title":"Join, который наглядно объясняет коллокацию"},{"chunk_id":"episode-71#c16","idx":16,"start":6041,"title":"Collocated compute: переносим бизнес-логику к данным"},{"chunk_id":"episode-71#c17","idx":17,"start":6405,"title":"Динамический деплой кода, лямбды и sandbox"},{"chunk_id":"episode-71#c18","idx":18,"start":6887,"title":"Почему русскоязычные инженеры полюбили data grid"},{"chunk_id":"episode-71#c19","idx":19,"start":7114,"title":"Garbage Collector встречает low-latency-нагрузки"},{"chunk_id":"episode-71#c20","idx":20,"start":7635,"title":"От распределённых объектов к off-heap storage"},{"chunk_id":"episode-71#c21","idx":21,"start":7921,"title":"Три причины перехода на off-heap"},{"chunk_id":"episode-71#c22","idx":22,"start":8324,"title":"Делает ли современный ZGC off-heap ненужным"},{"chunk_id":"episode-71#c23","idx":23,"start":8613,"title":"JIT-компиляция: Java против движков баз данных"},{"chunk_id":"episode-71#c24","idx":24,"start":8975,"title":"Когда не стоит выбирать распределённое хранилище"},{"chunk_id":"episode-71#c25","idx":25,"start":9249,"title":"Где data grid оправдывает свою сложность"},{"chunk_id":"episode-71#c26","idx":26,"start":9557,"title":"Кризис идентичности in-memory data grid"},{"chunk_id":"episode-71#c27","idx":27,"start":9730,"title":"Могут ли data grid пригодиться AI-агентам"},{"chunk_id":"episode-71#c28","idx":28,"start":9961,"title":"KV-кэши и распределённый AI-инференс"},{"chunk_id":"episode-71#c29","idx":29,"start":10143,"title":"Напутствие: изучайте системы, потом выбирайте инструмент"}],"date":"2026-09-03","duration_sec":10274,"guests":["stanislav-lukyanov"],"key_takeaways":["In-memory data grid — не просто кэш: система объединяет память нескольких машин и строит API так, чтобы минимизировать I/O, сетевые пересылки и движение данных между диском и памятью.","Ключ сначала отображается в логический шард, а шард — в физический узел; consistent и rendezvous hashing позволяют менять состав кластера, не перекладывая заново весь набор данных.","Репликация требует явного выбора между доступностью и консистентностью: Ignite 2 предлагал режимы Primary Sync и Full Sync, а Ignite 3 использует Raft и подтверждает запись большинством реплик.","SQL поверх распределённого key-value-хранилища становится эффективным, когда связанные данные коллоцированы: partition pruning и локальные join'ы убирают shuffle между узлами.","Collocated compute переносит Java-бизнес-логику к данным и сводит операцию к одному сетевому переходу, но повышает требования к безопасности, изоляции, multi-tenancy и квалификации команды.","Переход в off-heap решал сразу три задачи: снижал давление на Garbage Collector, давал предсказуемый бинарный layout для индексов и SQL и позволял сохранять страницы на диск.","Распределённое хранилище оправдано при сочетании низкой latency и большого параллелизма; прежде чем вводить его сложность, стоит проверить scale-up, кэш и репликацию обычной базы.","Идеи data grid могут вернуться в AI-инфраструктуре как масштабируемый слой памяти агентов, семантических кэшей и распределённого хранения LLM KV-кэшей рядом с инференсом."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"Apache Ignite","url":"https://ignite.apache.org"},{"title":"GridGain","url":"https://www.gridgain.com"},{"title":"Hazelcast","url":"https://hazelcast.com"},{"title":"Oracle Coherence","url":"https://www.oracle.com/middleware/technologies/coherence.html"},{"title":"Redis","url":"https://redis.io"},{"title":"Database Internals — Alex Petrov","url":"https://www.oreilly.com/library/view/database-internals/9781492040330/"},{"title":"Выпуск 24: B-tree и B+tree","url":"https://apkhmv.xyz/podcast/episode-24/"}],"md_url":"https://apkhmv.xyz/podcast/episode-71/index.md","number":71,"season":4,"slug":"episode-71","tags":["Apache Ignite","in-memory data grid","распределённые системы","шардирование","консистентность","распределённый SQL","JVM","off-heap"],"title":"#71: Как работает IMDG Apache Ignite","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-71/"},{"abstract":"Александр Пахомов и Антон Архипов — Developer Advocate в JetBrains, Java Champion, в прошлом разработчик JRebel — разбирают вопрос, который Антон задал Java-сеньорам на анконференции JCrete: нужна ли вообще IDE, если код пишут агенты? Все ответили «нужна», но объяснить зачем смогли только крайние случаи: Клифф Клик открывает IDE, чтобы дебажить, Питер Лори переписывает сгенерированный код руками. Отсюда разговор идёт к тому, что узкое место переехало из написания кода в code review, инструменты ревью не менялись пятнадцать лет, а люди превращаются в «клей между двумя Клодами». Во второй половине собеседники придумывают IDE будущего — завод по переработке задач с наблюдаемым пайплайном, бюджетами токенов и доказательствами на выходе, — спорят, что из этого сожрут OpenAI и Anthropic и почему LSP, скиллы и другие надстройки обнуляет каждая новая модель, и заканчивают ответственностью за код, который никто не читал, и ответом Антона на вопрос «нужна ли IDE в августе 2026».","audio_url":"https://traffic.libsyn.com/secure/173caf0e-b8e8-4056-8a73-2d60d94118ef/72_New_IDEA.mp3","chapters":[{"chunk_id":"episode-72#c0","idx":0,"start":0,"title":"Вступление: Антон Архипов, JetBrains, выходной в Эстонии и вопрос «нужен ли вам IDE?»"},{"chunk_id":"episode-72#c1","idx":1,"start":152,"title":"JCrete: анконференс на Крите, рулетка Хайнца Кабуца, лекции Клиффа Клика и AI-Crete"},{"chunk_id":"episode-72#c2","idx":2,"start":546,"title":"Пузыри и ожидания: вопрос сеньорам с 20+ годами Java и взгляд патологоанатома"},{"chunk_id":"episode-72#c3","idx":3,"start":699,"title":"Ответы: Клифф Клик дебажит в IDE, Питер Лори переписывает сгенерированный код руками"},{"chunk_id":"episode-72#c4","idx":4,"start":998,"title":"Зачем вообще код, code review как главная задача и «moment of shame» того, кто не читает код"},{"chunk_id":"episode-72#c5","idx":5,"start":1336,"title":"Хрустальный шар: 80%, что инструмент уже не нужен, страх и идентичность вокруг кода"},{"chunk_id":"episode-72#c6","idx":6,"start":1618,"title":"Цена инференса: две тысячи в месяц на токены и код лучше, чем у 90% программистов"},{"chunk_id":"episode-72#c7","idx":7,"start":1758,"title":"Теория Голдратта: горлышко переехало в code review, PR на 10 тысяч строк и зачем ревью на самом деле"},{"chunk_id":"episode-72#c8","idx":8,"start":2081,"title":"Инструменты ревью не менялись 15 лет: хочу историю инкремента, а не дифф с комментариями"},{"chunk_id":"episode-72#c9","idx":9,"start":2363,"title":"«Мы клей между двумя Клодами»: ревью через агентов и коммуникация с потерями"},{"chunk_id":"episode-72#c10","idx":10,"start":2549,"title":"Чат вместо редактора: как Антон смотрит диффы, а Саша программирует графы агентов"},{"chunk_id":"episode-72#c11","idx":11,"start":2827,"title":"Задачи инструмента: дебаггинг, ревью, артефакты на входе — Jira, транскрипт созвона, дамп из головы"},{"chunk_id":"episode-72#c12","idx":12,"start":3153,"title":"Завод по переработке задач: наблюдаемость пайплайна, зерно на ладони и артефакт на выходе"},{"chunk_id":"episode-72#c13","idx":13,"start":3387,"title":"Доказательства: тесты в середине, метрики перформанса на выходе и делегирование валидации агенту"},{"chunk_id":"episode-72#c14","idx":14,"start":3618,"title":"Визуальный пайплайн с бюджетами, агенты общаются между сессиями, токены как новый ресурс и канбан агентов"},{"chunk_id":"episode-72#c15","idx":15,"start":4041,"title":"Скиллы, экономия токенов и как Клод поглощает надстройки: self-review, отчёты, Codex строит IDE"},{"chunk_id":"episode-72#c16","idx":16,"start":4232,"title":"Борьба с ветряными мельницами: новая модель обнуляет ваши тулы, агент пишет инструменты на лету"},{"chunk_id":"episode-72#c17","idx":17,"start":4514,"title":"LSP для агента: поиск, рефакторинги, matklad с грепом и юниксовые тулзы"},{"chunk_id":"episode-72#c18","idx":18,"start":4796,"title":"Essential против nice-to-have: JRebel, компилятор, git и где теперь живут незаменимые инструменты"},{"chunk_id":"episode-72#c19","idx":19,"start":4981,"title":"Два динозавра OpenAI и Anthropic: где не стоять на пути, контекстное окно и локальные модели"},{"chunk_id":"episode-72#c20","idx":20,"start":5260,"title":"Терминал или UI: Codex Desktop, глючный Claude Desktop и Джонни Мнемоник в VR"},{"chunk_id":"episode-72#c21","idx":21,"start":5448,"title":"Если редактор заменить на Codex: список сессий и новый плагин JetBrains"},{"chunk_id":"episode-72#c22","idx":22,"start":5588,"title":"Видимость работы и отчётность: токены на задачу, governance-слой, Central, покупка DX Atlassian-ом"},{"chunk_id":"episode-72#c23","idx":23,"start":6061,"title":"Динамический UI на пути динозавров: интерактивный plan mode и инструмент для принятия решений"},{"chunk_id":"episode-72#c24","idx":24,"start":6254,"title":"Раскол комьюнити и псевдокод-дифф: понять критичный код без чтения тысяч строк"},{"chunk_id":"episode-72#c25","idx":25,"start":6591,"title":"Баг импорта Maven в IDEA: починил агентом и не знаю, что сломал; legacy, COBOL и adoption 5%"},{"chunk_id":"episode-72#c26","idx":26,"start":6944,"title":"Ответственность: агент-археолог на 10 миллионов токенов, индемнити Copilot и последняя кнопка перед уходом домой"},{"chunk_id":"episode-72#c27","idx":27,"start":7247,"title":"Урок девопсов: меньше знаешь — лучше спишь, Fable находит баги в проде, баги есть всегда"},{"chunk_id":"episode-72#c28","idx":28,"start":7592,"title":"Софт для самолётов и спутников: избыточность, 10 записей в студии и 10 отказов"},{"chunk_id":"episode-72#c29","idx":29,"start":7937,"title":"Волшебная кнопка: чёрный ящик, потеря экспертизы, франкенштейн Саши на Opus 4.5 и вакансии внедрения"},{"chunk_id":"episode-72#c30","idx":30,"start":8286,"title":"Финальный вопрос: нужна ли IDE в августе 2026, маятник стандартизации и once in a lifetime"}],"date":"2026-09-11","duration_sec":8617,"guests":["anton-arhipov"],"key_takeaways":["На JCrete все опрошенные Java-сеньоры с 20+ годами опыта ответили, что IDE им нужна, но почти никто не смог сказать зачем. Внятные ответы дали только крайние случаи: Клифф Клик пишет большую часть кода с Claude Code и открывает IntelliJ IDEA, чтобы дебажить Java, а Питер Лори генерирует весь код агентом и переписывает его руками — и по его же замерам стал выдавать заметно больше кода в день.","Пока код остаётся центром продукта, инструменты для работы с кодом никуда не денутся, но их задача сместилась: не писать и не рефакторить, а проверять. По теории ограничений Голдратта узкое место переехало из написания кода в code review — раньше в команде был один человек, наваливающий PR на три тысячи строк, теперь таких десяток, и они делают это очень быстро.","Инструменты ревью не менялись пятнадцать лет: максимум, что появилось, — комментарии к строчкам в GitHub, а AI-ревьюеры вроде Greptile и CodeRabbit выдают тот же дифф с замечаниями. Антон хочет «историю инкремента»: семантическое объяснение, как и почему изменилась функциональность, со ссылкой на задачу и на то, как поменялся тест-сьют.","Когда автор сгенерировал PR своим Клодом, ревьюер сгенерировал замечания своим, а автор скормил их обратно своему, люди становятся «клеем между двумя Клодами»: это коммуникация со сжатием с потерями, где решений минимум, а ресурсов и времени уходит много.","Инструмент будущего по версии Александра — завод по переработке задач: артефакты на входе (тикет, транскрипт созвона, дамп из головы), наблюдаемый пайплайн с бюджетом токенов на каждом шаге, в который можно «зачерпнуть зерно» и заглянуть, тесты в середине, метрики перформанса и end-to-end-валидация агентом на выходе.","Всё, что строится поверх агента — скиллы, LSP, MCP-серверы, self-review-плагины, — экономит токены только до выхода следующей модели, а полезные надстройки Anthropic и OpenAI поглощают за месяцы. Делать на них ставку — борьба с ветряными мельницами; нишу стоит искать там, куда «два динозавра» не пойдут: комбинация ограниченных контекстных окон, локальные модели, работа с результатом, а не с входом.","IDE перестаёт быть essential-инструментом: агенту хватает bash, file и ещё пары тулов, а JetBrains, всегда делавшая обязательные для программиста продукты, впервые оказывается в категории nice-to-have — как когда-то JRebel. При этом Codex и Claude Code по факту строят IDE нового образца: сессии, диффы, ветки, интерактивный plan mode.","Принимать ответственность за код, который никто не читал, помогает не знание, а доказательства: SRE или менеджер раскатывают релиз по зелёному пайплайну и аппрувам, не заглядывая в код. Разработчику нужна такая же система — иначе, починив агентом баг импорта Maven в IDEA, ты не знаешь, что при этом сломал.","Ответ Антона на вопрос «нужна ли IDE в августе 2026»: для части рынка она уже nice-to-have, но маятник стандартизации вернёт индустрию к общему инструменту — сегодняшняя IDE трансформируется или её сменит новое поколение, и это всё равно будет IDE."],"lastmod":"2026-09-16T11:54:17+03:00","links":[{"title":"JCrete — анконференс Java-разработчиков на Крите","url":"https://www.jcrete.org"},{"title":"Антон Архипов — сайт и блог","url":"https://antonarhipov.com"},{"title":"JRebel","url":"https://www.jrebel.com"},{"title":"Koog — агентский фреймворк JetBrains на Kotlin","url":"https://github.com/JetBrains/koog"},{"title":"Greptile","url":"https://www.greptile.com"},{"title":"CodeRabbit","url":"https://www.coderabbit.ai"},{"title":"Теория ограничений Голдратта","url":"https://ru.wikipedia.org/wiki/Теория_ограничений"},{"title":"Выпуск 45: TigerBeetle — matklad в гостях","url":"https://apkhmv.xyz/podcast/episode-45/"}],"md_url":"https://apkhmv.xyz/podcast/episode-72/index.md","number":72,"season":4,"slug":"episode-72","tags":["IDE","IntelliJ IDEA","ИИ-агенты","Claude Code","Codex","код-ревью","инструменты разработчика","экономика токенов"],"title":"#72: Зачем IDEA в 2026","transcript_date":"2026-09-15","transcript_status":"draft","url":"https://apkhmv.xyz/podcast/episode-72/"}],"generated_at":"2026-09-16T18:24:11Z","people":[{"aliases":["Саша"],"bio":"Java-разработчик в финтехе: писал low-latency-алготрейдинг и работает над распределённой БД и расчётно-платёжными системами; интересуется рантаймами Java и Go, low-latency и конкурентным программированием. Спикер JPoint.","episodes":[61],"id":"alexander-lantsov","md_url":"https://apkhmv.xyz/people/alexander-lantsov/index.md","name":"Александр Ланцов","role":"guest","sameAs":["https://www.linkedin.com/in/alantsov/"],"url":"https://apkhmv.xyz/people/alexander-lantsov/"},{"aliases":[],"bio":"Сооснователь и управляющий партнёр Школы менеджмента «Стратоплан» (обучение тимлидов, руководителей отделов и C-level, шестнадцать лет). Начинал инженером: четыре года в Sun Microsystems (руководил группой тестирования Java на мобильных устройствах), затем Intel — менеджер команды в проекте опенсорсной Java Apache Harmony. Практический психолог по второму образованию.","episodes":[69],"id":"alexander-orlov","md_url":"https://apkhmv.xyz/people/alexander-orlov/index.md","name":"Александр Орлов","role":"guest","sameAs":[],"url":"https://apkhmv.xyz/people/alexander-orlov/"},{"aliases":["Алексей"],"bio":"Инженер систем низкой задержки; строит распределённую стриминговую платформу AlgoX2 (позиционируется как «убийца Kafka»). Автор открытого фреймворка кодогенерации OpenACR (инструменты acr/amc, SSIM-файлы), который генерирует ~95% собственного исходного кода. Учился программировать в начале 90-х, ранее занимался высокочастотной торговлей.","episodes":[64],"id":"alexei-lebedev","md_url":"https://apkhmv.xyz/people/alexei-lebedev/index.md","name":"Алексей Лебедев","role":"guest","sameAs":["https://github.com/alexeilebedev","https://github.com/alexeilebedev/openacr"],"url":"https://apkhmv.xyz/people/alexei-lebedev/"},{"aliases":["Андрей"],"bio":"Инженер JetBrains, стоял у истоков редактора Fleet и является его архитектором; ранее работал над IntelliJ IDEA и код-браузером Absource.","episodes":[47],"id":"andrei-zaitsev","md_url":"https://apkhmv.xyz/people/andrei-zaitsev/index.md","name":"Андрей Зайцев","role":"guest","sameAs":["https://de.linkedin.com/in/deadzajac"],"url":"https://apkhmv.xyz/people/andrei-zaitsev/"},{"aliases":["Андрей"],"bio":"CTO и сооснователь Qdrant — векторного поискового движка на Rust; ранее ML-инженер в поисковых командах.","episodes":[41],"id":"andrey-vasnetsov","md_url":"https://apkhmv.xyz/people/andrey-vasnetsov/index.md","name":"Андрей Васнецов","role":"guest","sameAs":["https://github.com/generall","https://qdrant.tech/about-us/"],"url":"https://apkhmv.xyz/people/andrey-vasnetsov/"},{"aliases":["Андрей"],"bio":"Сооснователь и CTO стартапа Gracia (объёмное 4D-видео на Gaussian Splatting для VR/AR); ранее founding engineer в Prisma и сооснователь NetMonet (продан Альфа-Банку). Автор телеграм-канала «Три сигмы».","episodes":[52],"id":"andrey-volodin","md_url":"https://apkhmv.xyz/people/andrey-volodin/index.md","name":"Андрей Володин","role":"guest","sameAs":["https://gracia.ai"],"url":"https://apkhmv.xyz/people/andrey-volodin/"},{"aliases":["Антон"],"bio":"Developer Advocate в JetBrains (команда Kotlin), Java Champion с 2014 года. Больше десяти лет делает инструменты для разработчиков: в стартапе ZeroTurnaround работал над JRebel и XRebel. Живёт в Эстонии.","episodes":[72],"id":"anton-arhipov","md_url":"https://apkhmv.xyz/people/anton-arhipov/index.md","name":"Антон Архипов","role":"guest","sameAs":["https://github.com/antonarhipov","https://antonarhipov.com","https://x.com/antonarhipov","https://www.linkedin.com/in/antonarhipov/","https://www.youtube.com/@AntonArhipov"],"url":"https://apkhmv.xyz/people/anton-arhipov/"},{"aliases":["Александр"],"bio":"Software engineer и open-source энтузиаст, ведущий подкаста «Тысяча фичей».","episodes":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72],"id":"apkhmv","md_url":"https://apkhmv.xyz/people/apkhmv/index.md","name":"Александр Пахомов","role":"host","sameAs":["https://github.com/PakhomovAlexander","https://www.linkedin.com/in/aleksandr-pakhomov-178696186/","https://t.me/tfeat"],"url":"https://apkhmv.xyz/people/apkhmv/"},{"aliases":["Даня"],"bio":"Разработчик в JetBrains, работает над API для языковых плагинов и межъязыкового взаимодействия в IntelliJ Platform; раньше активно развивал плагин для Groovy.","episodes":[35],"id":"daniil-ovchinnikov","md_url":"https://apkhmv.xyz/people/daniil-ovchinnikov/index.md","name":"Даниил Овчинников","role":"guest","sameAs":["https://github.com/dovchinnikov"],"url":"https://apkhmv.xyz/people/daniil-ovchinnikov/"},{"aliases":["Дима"],"bio":"Инженер, в прошлом олимпиадник, несколько лет занимается Web3; ведёт технический митап и Substack «Stateful Compute» про будущее вычислительных движков.","episodes":[59],"id":"dima-korolev","md_url":"https://apkhmv.xyz/people/dima-korolev/index.md","name":"Дима Королёв","role":"guest","sameAs":["https://dimakorolev.substack.com","https://substack.com/@dkorolev"],"url":"https://apkhmv.xyz/people/dima-korolev/"},{"aliases":["Дмитрий"],"bio":"Системный архитектор и Java-разработчик, коммитер Apache Cassandra; специализируется на распределённых системах, производительности и отказоустойчивости. Регулярный спикер JPoint/Joker, на Хабре — @netudima.","episodes":[56,57,58],"id":"dmitry-konstantinov","md_url":"https://apkhmv.xyz/people/dmitry-konstantinov/index.md","name":"Дмитрий Константинов","role":"guest","sameAs":["https://habr.com/ru/users/netudima/","https://jpoint.ru/archive/2024/persons/5c2f4e3f50d9404aaa889cd9870b4efc/"],"url":"https://apkhmv.xyz/people/dmitry-konstantinov/"},{"aliases":["Дмитрий"],"bio":"Инженерный менеджер и автор YouTube-канала «Senior Software Vlogger»; полностью написал моделями Mac-приложение Summit AI Notes для записи и разбора звонков.","episodes":[60],"id":"dmitry-rozhkov","md_url":"https://apkhmv.xyz/people/dmitry-rozhkov/index.md","name":"Дмитрий Рожков","role":"guest","sameAs":["https://www.youtube.com/@SeniorSoftwareVlogger"],"url":"https://apkhmv.xyz/people/dmitry-rozhkov/"},{"aliases":["Дмитрий"],"bio":"Java-разработчик в бигтехе, ведущий подкаста Java Swag и лидер комьюнити FAANG Talks по подготовке к интервью в big tech.","episodes":[34],"id":"dmitry-volyhin","md_url":"https://apkhmv.xyz/people/dmitry-volyhin/index.md","name":"Дмитрий Волыхин","role":"guest","sameAs":["https://javaswag.github.io","https://www.linkedin.com/in/volyihin/","https://t.me/javaswag"],"url":"https://apkhmv.xyz/people/dmitry-volyhin/"},{"aliases":["Илья"],"bio":"Программист (Java, переходит на Go), автор YouTube-канала «Куда войти?»; пишет в NeoVim и сделал Obsidian-подобный плагин obs.nvim.","episodes":[40],"id":"ilya-ilyinykh","md_url":"https://apkhmv.xyz/people/ilya-ilyinykh/index.md","name":"Илья Ильиных","role":"guest","sameAs":["https://www.youtube.com/@kydavoiti","https://github.com/IlyasYOY"],"url":"https://apkhmv.xyz/people/ilya-ilyinykh/"},{"aliases":["Иван"],"bio":"Системный архитектор в Островке (Ostrovok); внедряет ИИ-инструменты и агентов в enterprise-разработку. Ведёт телеграм-канал «Чернов шарит».","episodes":[62],"id":"ivan-chernov","md_url":"https://apkhmv.xyz/people/ivan-chernov/index.md","name":"Иван Чернов","role":"guest","sameAs":["https://piterpy.com/persons/12deec8c8af24816baae4693689845ff/"],"url":"https://apkhmv.xyz/people/ivan-chernov/"},{"aliases":["Иван"],"bio":"Профессор ИИ в THWS (Вюрцбург), глава AI-института CAIRO и сооснователь лаборатории Pleias (открытый датасет Common Corpus). Исследует генерацию естественного языка и компактные языковые модели.","episodes":[39,54],"id":"ivan-yamshchikov","md_url":"https://apkhmv.xyz/people/ivan-yamshchikov/index.md","name":"Иван Ямщиков","role":"guest","sameAs":["https://www.linkedin.com/in/kroniker/","https://scholar.google.com/citations?user=y77r-h4AAAAJ"],"url":"https://apkhmv.xyz/people/ivan-yamshchikov/"},{"aliases":["Иван"],"bio":"Инженер и engineering manager: проектирует AI-системы, строит внутренние платформы разработки и отказоустойчивую инфраструктуру; учится в мастерской инженеров-менеджеров (школе системного менеджмента Анатолия Левенчука) и автор эксперимента Qwen Code, приземляющего First Principles Framework на разработку. IT-наставник.","episodes":[63],"id":"ivan-zakutniy","md_url":"https://apkhmv.xyz/people/ivan-zakutniy/index.md","name":"Иван Закутний","role":"guest","sameAs":["https://getmentor.dev/mentor/zakutniy-ivan-3813"],"url":"https://apkhmv.xyz/people/ivan-zakutniy/"},{"aliases":["Дима"],"bio":"Автор Telegram-канала о нейросетях и вайб-кодинге; делает YouTube-контент и небольшие инструменты на базе AI-агентов.","episodes":[65],"id":"kisa","md_url":"https://apkhmv.xyz/people/kisa/index.md","name":"Дмитрий (Kisa)","role":"guest","sameAs":[],"url":"https://apkhmv.xyz/people/kisa/"},{"aliases":["Алексей"],"bio":"Разработчик TigerBeetle (распределённая БД для учёта финансовых транзакций на Zig); ранее — автор IntelliJ Rust и rust-analyzer, IDE-поддержки языка Rust.","episodes":[45],"id":"matklad","md_url":"https://apkhmv.xyz/people/matklad/index.md","name":"Алексей Кладов","role":"guest","sameAs":["https://github.com/matklad","https://matklad.github.io"],"url":"https://apkhmv.xyz/people/matklad/"},{"aliases":["Максим"],"bio":"Разработчик ClickHouse, контрибьютор компилятора Swift и коммитер проекта LLVM.","episodes":[36,38,43,44,51],"id":"maxim-kita","md_url":"https://apkhmv.xyz/people/maxim-kita/index.md","name":"Максим Кита","role":"guest","sameAs":["https://github.com/kitaisreal","https://maksimkita.com/"],"url":"https://apkhmv.xyz/people/maxim-kita/"},{"aliases":["Мекан"],"bio":"Специалист по безопасности веб-приложений в Mad Devs, автор YouTube-канала MrCyberSec.","episodes":[42],"id":"mekan-bairyev","md_url":"https://apkhmv.xyz/people/mekan-bairyev/index.md","name":"Мекан Байрыев","role":"guest","sameAs":["https://www.youtube.com/@MrCyberSec","https://www.linkedin.com/in/mekan-bairyev/","https://hackerone.com/mrcybers3c"],"url":"https://apkhmv.xyz/people/mekan-bairyev/"},{"aliases":["Михаил"],"bio":"Разработчик кодинг-агента veai (IDE-native AI-агент для JetBrains IDE на базе IntelliJ-платформы); руководит несколькими командами, ранее делал агента для Rider (.NET). Специализируется на индексах, PSI и формальных методах (символьное исполнение, генерация тестов).","episodes":[66],"id":"mikhail-kositsyn","md_url":"https://apkhmv.xyz/people/mikhail-kositsyn/index.md","name":"Михаил Костицын","role":"guest","sameAs":[],"url":"https://apkhmv.xyz/people/mikhail-kositsyn/"},{"aliases":["Миша"],"bio":"Практикующий Java-разработчик, стоял у истоков сообщества Spring.io. Разрабатывает в опенсорсе Axelix — мониторинговое решение для Spring Boot-приложений. Выступает на конференциях (JPoint, Spring.io, Devoxx).","episodes":[67],"id":"misha-polivakha","md_url":"https://apkhmv.xyz/people/misha-polivakha/index.md","name":"Миша Поливаха","role":"guest","sameAs":[],"url":"https://apkhmv.xyz/people/misha-polivakha/"},{"aliases":["Никита"],"bio":"Nikitonsky — автор шрифта Fira Code, библиотеки DataScript и телеграм-канала «Стой под стрелой».","episodes":[46,47,53],"id":"nikita-prokopov","md_url":"https://apkhmv.xyz/people/nikita-prokopov/index.md","name":"Никита Прокопов","role":"guest","sameAs":["https://tonsky.me","https://github.com/tonsky","https://mastodon.online/@nikitonsky"],"url":"https://apkhmv.xyz/people/nikita-prokopov/"},{"aliases":["Станислав"],"bio":"Инженер распределённых систем и developer-facing продуктов (около девяти лет в распределённых системах, тринадцать — в продуктах для разработчиков). Коммитер Apache Ignite, работает над GridGain (теперь часть MariaDB); ранее — Java Platform в Oracle. Живёт в Нью-Йорке.","episodes":[70,71],"id":"stanislav-lukyanov","md_url":"https://apkhmv.xyz/people/stanislav-lukyanov/index.md","name":"Станислав Лукьянов","role":"guest","sameAs":[],"url":"https://apkhmv.xyz/people/stanislav-lukyanov/"},{"aliases":["Стас"],"bio":"Сооснователь Neon (serverless Postgres as a service), где сделал storage layer и WAL-стриминг; ранее хакал кластерный Postgres в Postgres Professional и работал в команде баз данных Яндекса.","episodes":[48,49],"id":"stas-kelvich","md_url":"https://apkhmv.xyz/people/stas-kelvich/index.md","name":"Стас Кельвич","role":"guest","sameAs":["https://github.com/kelvich"],"url":"https://apkhmv.xyz/people/stas-kelvich/"},{"aliases":[],"bio":"Технологический блогер и основатель Вастрик-клуба (vas3k.club) и Вастрик-блога; инди-хакер, живёт в Берлине.","episodes":[37],"id":"vas3k","md_url":"https://apkhmv.xyz/people/vas3k/index.md","name":"Вастрик","role":"guest","sameAs":["https://vas3k.blog","https://vas3k.club"],"url":"https://apkhmv.xyz/people/vas3k/"},{"aliases":["Владимир"],"bio":"Около двадцати лет в Java и производительности SQL-систем. Мейнтейнер PostgreSQL JDBC-драйвера (pgjdbc) и Apache JMeter; участник программных комитетов конференций JUG Ru Group (Joker, JPoint, Heisenbug, SmartData, DevOops), помогает спикерам готовить доклады.","episodes":[68],"id":"vladimir-sitnikov","md_url":"https://apkhmv.xyz/people/vladimir-sitnikov/index.md","name":"Владимир Ситников","role":"guest","sameAs":["https://github.com/vlsi"],"url":"https://apkhmv.xyz/people/vladimir-sitnikov/"},{"aliases":[],"bio":"Основатель компании Unison и продукта yuchat.","episodes":[55],"id":"vova","md_url":"https://apkhmv.xyz/people/vova/index.md","name":"Вова","role":"guest","sameAs":[],"url":"https://apkhmv.xyz/people/vova/"}],"products":[{"external_url":"https://af.apkhmv.xyz/","id":"af","md_url":"https://apkhmv.xyz/products/af/index.md","name":"af","releases":[{"date":"2026-09-15T20:41:52Z","name":"v0.9.0-rc.2","notes_md":"### Authority compatibility\n\nPrerelease: `af task start` now captures and previews without dispatching Workers, including\nwith `--json`. Review the plan, then run with `--confirm-plan` and its full captured ID.\nAutomation must explicitly opt into `--execute` on start or on the first run of a plan.\nAdmitted Tasks can resume and finished Tasks replay as before. This CLI confirmation never\nreplaces signed developer approval for a generated plan. Existing `.af` authority remains\nsupported; legacy `.review` migration and exact release pin verification still apply.\n\n### Changes\n\n- Render captured Task plans as compact ASCII flows or expanded `task explain --tree` views,\n  with embedded calls, actual Worker models/efforts/accounts, inputs, outputs, effects and limits.\n- Stop new Tasks before execution and refuse stale plan confirmations, including a plan change\n  before the writer lease is acquired. Explicit automation retains existing runtime admission.\n- Keep JSON inspection schemas unchanged, sanitize terminal display text, and document the\n  preview/approval workflow for Claude and Codex.\n\nThe live pilot and complete consumer migration/rollback acceptance remain pending. This\ncandidate does not declare stable-release readiness or change the active consumer's pin.","prerelease":true,"tag":"v0.9.0-rc.2","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.9.0-rc.2"},{"date":"2026-09-15T18:16:10Z","name":"v0.9.0-rc.1","notes_md":"### Authority compatibility\n\nThis is a prerelease for Task integration and migration validation. Live pilot acceptance\nand complete consumer migration/rollback verification remain pending; this candidate does\nnot establish stable-release readiness or replace the known-good consumer installation.\n\nNew Task execution requires its versioned `.af` catalog, Pipeline/Worker contracts and lock.\nEvery generated Execution Plan requires an authorized developer's exact-plan approval.\nLocal bindings do not travel with shared definitions. Existing `.review` consumers still\nneed the supported `af onboard --migrate --apply` path; validate migrated authority together\nwith the chosen released binary and its verified archive digests before switching launchers.\n\nNew Review executions use the common Task runtime. Historical paid Campaigns preserve their\ncaptured executor, authority and accounting; they are not rewritten into new Tasks. Keep the\noriginal Store and known-good release for historical continuation and rollback. An older\nbinary must not reinterpret unsupported new state, and rollback cannot refund recorded usage\nor reopen completed work. Release-bound migration and rollback evidence are release gates.\n\n### Changes\n\n- Make Task the common durable execution model for implementation, Review and documents,\n  with typed Pipeline input/output contracts, captured context and shared budget accounting.\n- Compose reusable Review Pipelines inside implementation, with independent acceptance and\n  bounded repairs that retain Finding and Snapshot provenance.\n- Select fitting shared Pipelines; persist generated definitions and plans for developer\n  review when configured generation is needed; export definitions for subsequent reuse.\n- Share versioned Pipeline/Worker packages and starter workflows through Git, with local\n  Provider bindings, deterministic contract checks, Jira/local source capture and explicit\n  delivery to a new local worktree.\n- Preserve Provider usage and recovery evidence across cancellation, writer loss and storage\n  failures, and capture explicit admission allowances in Task catalog V2.\n- Preserve nested Jira requirements, resolve explicit relative refresh files from the caller's\n  directory, and retain plans when only unselected Jira fields or update timestamps change.\n- Make identical authenticated plan-revocation requests idempotent and refuse revocation of\n  decisions that were never approved.\n- Reduce repeated captured Review validation, heartbeat and receipt-query work while retaining\n  fresh artifact, lease, approval and usage checks; stream raw usage transcripts with bounded memory.\n- Open the repository: `install.sh` installs from a public release with `curl` alone, verifies\n  the release signature by default when `minisign` is present, and keeps `gh` only as a\n  fallback; the release also ships `LICENSE` (Apache-2.0), `SECURITY.md`, `CONTRIBUTING.md`\n  and a restructured `docs/` (architecture, tasks, migration, non-goals, design notes).\n\n- Account for every model reported by native Claude Task usage; preserve auxiliary charges\n  and refuse unapproved auxiliary activity instead of accepting an Opus selector alone.\n- Use native JSON schemas and structured output for typed Claude Task replies while retaining\n  independent Kernel output validation and the existing legacy text transport.\n- Preserve prerelease versions in migrated authority so the candidate can read its own output.\n- Retry transient executable-busy process starts and correct concurrent Linux test allowances.\n- Explain logged-out Provider status and install declared toolchain components in release jobs.\n\n### Validation boundary\n\nThe release workflow checks the tagged source on Linux and macOS, runs consumer fixtures,\nand signs archive checksums. These deterministic checks do not replace specialist reviews,\nlive Task measurements or actual consumer migration and rollback rehearsals. See\n[Task execution](docs/task-execution.md) for the contracts; candidate publication does not\nclaim those remaining acceptance gates have passed.","prerelease":true,"tag":"v0.9.0-rc.1","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.9.0-rc.1"},{"date":"2026-09-09T11:15:13Z","name":"v0.8.0","notes_md":"### Authority compatibility\n\nRequires `af onboard --migrate --apply` for a consumer still on `.review/`: legacy authority is\nno longer read for new Campaigns (ADR-0043). A repository already on `.af/` keeps working, but\nre-pin it with `af onboard --refresh-lock` so the lock records the per-target archive digest this\nrelease binds to. A `0.7.1` default cannot read a lock written by `0.8.0` (its `[af]` table is an\nunknown field to the older parser), so it neither dispatches to `0.8.0` nor plans: run\n`af self update` first on such a machine.\n\n### Changes\n\n- Route pipelines by changed paths; switch oversized Diffs to a bounded pipeline (#64)\n- Show Campaign state on disk and reclaim it with af review gc (#66)\n- One release train, a pin that binds bytes, and .review/ retired (ADR-0045) (#68)\n- Commit the minisign release public key: every release from 0.8.0 ships a signed `SHA256SUMS`","prerelease":false,"tag":"v0.8.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.8.0"},{"date":"2026-09-03T13:06:20Z","name":"v0.7.1","notes_md":"## What's Changed\n* docs: record v0.7.0 release by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/44\n* Plan consumer policies with every built af by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/48\n* Validate and migrate legacy .review/ policy in af onboard by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/49\n* Refresh the hub consumer fixture: one correctness reviewer by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/51\n* Make wall-clock, provider usage, and dispositions visible per review by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/54\n* Let a Worker node declare its own Attempt cap by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/60\n* Render a Worker's exact input token-free by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/61\n* Refuse a Worker input that exhausts its Attempt cap before admission by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/62\n* Make af self-managed: clap tree, scoped help, completions, af self, dispatch, config ladder by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/63\n* release: prepare v0.7.1 by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/65\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.7.0...v0.7.1","prerelease":false,"tag":"v0.7.1","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.7.1"},{"date":"2026-09-01T16:30:39Z","name":"v0.7.0","notes_md":"## What's Changed\n* Record v0.6.0 release by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/30\n* Harden review planning and provider admission by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/31\n* release: prepare v0.7.0 by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/43\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.6.0...v0.7.0","prerelease":false,"tag":"v0.7.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.7.0"},{"date":"2026-09-01T11:21:29Z","name":"v0.6.0","notes_md":"## What's Changed\n* Complete Review Kernel M7-M9 by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/28\n* Release v0.6.0 by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/29\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.5.0...v0.6.0","prerelease":false,"tag":"v0.6.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.6.0"},{"date":"2026-08-31T19:51:51Z","name":"v0.5.0","notes_md":"## What's Changed\n* Record the v0.4.0 onboarding release by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/14\n* Complete M3 grouping and M4 evidence resolution by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/18\n* Fix remaining M4 verification findings by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/19\n* Implement M6.3 broker handles by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/24\n* Default review campaigns to light mode by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/25\n* Release: prepare v0.5.0 by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/26\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.4.0...v0.5.0","prerelease":false,"tag":"v0.5.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.5.0"},{"date":"2026-08-27T18:15:42Z","name":"v0.4.0","notes_md":"## What's Changed\n* Record the v0.3.0 trusted-pilot release by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/12\n* Add deterministic review onboarding by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/13\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.3.0...v0.4.0","prerelease":false,"tag":"v0.4.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.4.0"},{"date":"2026-08-27T15:49:51Z","name":"v0.3.0","notes_md":"## What's Changed\n* Complete V3.1 trusted client pilot delivery by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/11\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.2.0...v0.3.0","prerelease":false,"tag":"v0.3.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.3.0"},{"date":"2026-08-25T10:41:43Z","name":"v0.2.0","notes_md":"## What's Changed\n* M2.5: derive report scope from round subjects by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/5\n* Fenced provider admission before reviewer dispatch by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/7\n* feat: report Claude weekly and Fable limits by @apkhmv-agent in https://github.com/PakhomovAlexander/afactory/pull/6\n* Release v0.2.0: complete M2 review authority and scope by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/9\n\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/compare/v0.1.0...v0.2.0","prerelease":false,"tag":"v0.2.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.2.0"},{"date":"2026-08-24T08:27:21Z","name":"v0.1.0","notes_md":"## What's Changed\n* Establish the Afactory CLI and private release boundary by @PakhomovAlexander in https://github.com/PakhomovAlexander/afactory/pull/2\n* feat(reviewctl): show provider subscription status by @apkhmv-agent in https://github.com/PakhomovAlexander/afactory/pull/4\n\n## New Contributors\n* @PakhomovAlexander made their first contribution in https://github.com/PakhomovAlexander/afactory/pull/2\n* @apkhmv-agent made their first contribution in https://github.com/PakhomovAlexander/afactory/pull/4\n\n**Full Changelog**: https://github.com/PakhomovAlexander/afactory/commits/v0.1.0","prerelease":false,"tag":"v0.1.0","url":"https://github.com/PakhomovAlexander/afactory/releases/tag/v0.1.0"}],"repo":"https://github.com/PakhomovAlexander/afactory","status":"alpha","tagline":"многоагентная фабрика для git-репозиториев","url":"https://apkhmv.xyz/products/af/"}],"schema_version":1,"site":{"api":"https://apkhmv.xyz/api/v1","mcp":"https://apkhmv.xyz/mcp","name":"Тысяча фичей","url":"https://apkhmv.xyz/"}}