Сохранёнки программиста

Где держать Telegram-бота или API, чтобы они не падали под нагрузкой и не съедали бюджет? Tproger собрал подборку из шести VPS-провайдеров под этот сценарий: от тарифов за пару сотен рублей в месяц до конфигураций с DDR5 и портом 10 Гбит/с. У каждого свой акцент — где-то посуточная оплата и запуск за минуту, где-то API для CI/CD, бэкапы и приватные сети, где-то зарубежные локации. Внутри по каждому провайдеру: реальные конфигурации, цены, на какой нагрузке тестировали и под какой сценарий брать. https://tproger.ru/articles/gde-razvernut-bota-ili-api---podborka-vps--kotorye-ne-tormozyat @prog_stuff

Почему передача репозитория не равна передаче проекта Programming as Theory Building — классический текст Питера Наура о том, что программирование не сводится к коду, документации и диаграммам. Всё это важные артефакты, но они не содержат всю «теорию» системы. Главное в тексте — очень точное объяснение боли legacy: проект можно формально передать полностью, но новая команда всё равно не получит систему. Репозиторий есть, README есть, схемы есть, backlog есть, а уверенности в изменениях нет. Теория у Наура — это понимание, которое держат в голове разработчики: почему решения приняты именно так, какие варианты уже пробовали, какие ограничения нельзя трогать и какие изменения выглядят локально разумно, но ломают общий смысл конструкции. Отсюда хорошо считываются последствия для сопровождения. Документация помогает, но не заменяет участие в разработке. Code review проверяет не только строки, но и то, совпадает ли изменение с теорией системы. Онбординг — это не экскурсия по файлам, а постепенная передача причин, ограничений и инженерной памяти. Сохранять тем, кто занимается legacy, онбордингом, ревью, архитектурой или передачей проектов между командами. Текст старый, но после него иначе смотришь на фразу «мы всё задокументировали». https://pages.cs.wisc.edu/~remzi/Naur.pdf

Как работать с ИИ без марафона по промптам и десятка вкладок? Aperio — это онлайн-сервис с готовыми ИИ-ассистентами для жизни, работы и бизнеса. Не универсальный чат, где ты сам должен придумать, как выжать пользу, а набор помощников под конкретные сценарии. Пригодится, чтобы: — структурировать мысли перед задачей или созвоном; — разобрать рабочую ситуацию; — потренировать навык или накидать план действий. Главная фишка в том, что не нужно выбирать модель, писать идеальный промпт и собирать себе рабочий процесс из разных сервисов: заходишь, выбираешь нужный сценарий и сразу работаешь. Ассистентов делает собственная команда Aperio, а часть из них создаётся вместе с профильными специалистами. Поэтому это не просто набор ботов с красивыми названиями, а понятные прикладные инструменты. Есть бесплатный пробный период — можно зайти, потыкать разные сценарии и понять, что полезно именно вам. Вариант для тех, кто давно хотел добавить ИИ в свою рутину, но не хотел превращать это в отдельный пет-проект. ➡️ Попробовать ассистентов Aperio: https://aperio.cloud/ Это #партнёрский пост

Эссе Марка Брукера, инженера в AWS, с неожиданным выводом о том, какие задачи окажутся для ИИ-агентов лёгкими, а какие трудными. И ключ тут вовсе не в интеллекте модели. Брукер заходит от электроники. Обратная связь, пожалуй, самая мощная идея в инженерии: заверни слабый компонент в петлю обратной связи, и на выходе получишь поведение, на которое сам компонент не способен. Классический пример: операционный усилитель с умножителем вместе превращаются в извлекатель квадратного корня. ИИ-агент устроен так же. Внутри сидит LLM, полезный, но небезупречный компонент с разомкнутым поведением. Агент оборачивает его в петлю: сгенерировал, собрал, прогнал тесты, увидел ошибку, поправил. Вся эволюция инструментов за последние пару лет именно про это, обратная связь переехала от человека за клавиатурой внутрь самого агента. Отсюда его гипотеза: в долгую агенты будут щёлкать задачи, где есть быстрая и точная обратная связь, и спотыкаться там, где её нет. Потолок задаёт качество этого сигнала «правильно или нет». Размер модели тут уже вторичен. Это уже заметно. Агенты сильны в оптимизации производительности, где есть бенчмарки. Rust своими явными ошибками компиляции буквально ведёт агента к корректному коду. Property-based тесты бесценны. А вот с архитектурой беда: тут обратная связь в духе «пойму, когда увижу». И с конкурентным кодом так же, там ошибка молча портит данные в рантайме. Дальше самое интересное. Сравните две задачи: сверстать приятный фоторедактор в вебе и написать корректный высокопроизводительный движок хранения для базы данных. Кажется, первое проще. Но по гипотезе Брукера в долгую проще как раз второе. У движка БД есть чёткая спецификация: API, гарантии безопасности и живучести, и итерироваться к успеху можно вообще без участия людей. А «приятный» сайт упирается в человека в петле, а человек медленный и непоследовательный судья. Вывод переворачивает привычную интуицию: SaaS и интерфейсы окажутся трудными, а системный софт лёгким. И на первый план выходит спецификация, умение записать, что значит «хорошо», плюс инструменты, которые это проверяют: Rust, Verus, TLA+, симуляторы, моки. Сама по себе генерация кода становится вторичной. Хорошее чтение, чтобы переосмыслить, куда вкладывать силы в ближайшие годы. https://brooker.co.za/blog/2026/05/18/whats-easy-whats-hard.html @prog_stuff

Большой разбор Cloudflare, почему серверы начали грузиться по четыре часа Cloudflare разобрали, как обычное обновление firmware превратило перезагрузку bare-metal серверов в многочасовое ожидание. Отличный пример того, как маленькая деталь в UEFI boot order ломает rollout почти на 2 000 машин. Суть проблемы: после обновления firmware серверы проходили POST нормально, но потом линейно перебирали неподходящие варианты сетевой загрузки. IPv4 HTTPS boot, IPv4 iPXE, снова таймауты — и только потом рабочий IPv6 HTTPS boot. Каждый неудачный network boot съедал примерно по 5 минут. На одном reboot неприятно, а в firmware upgrade automation, где несколько компонентов обновляются через последовательные перезагрузки, это раздувалось почти до 4 часов. В разборе показывают путь расследования: 🔘 serial console вместо гадания по мониторингу; 🔘 как UEFI, PXE, iPXE и HTTPS boot участвуют в загрузке; 🔘 почему firmware начал перебирать интерфейсы не в том порядке; 🔘 как Cloudflare стала задавать network boot interface order заранее в pre-boot PXE stage; 🔘 какие ограничения всплыли: старые UEFI-версии не поддерживают boot ordering, а настройки могут сбрасываться после firmware upgrade; 🔘 как всё завели через существующий release pipeline без ручного похода в BIOS. Главная цифра: firmware upgrade automation сократили с почти 4 часов до 3 минут, а последующий single boot — примерно с 20 минут до менее чем минуты. Сохранять тем, кто отвечает за bare metal, firmware updates, PXE/iPXE-загрузку или просто любит production-разборы, где проблема прячется не в коде приложения, а в цепочке до старта ОС. Тут хорошо видно, почему boot order, таймауты и vendor quirks стоит тестировать так же внимательно, как обычный rollout. @prog_stuff

Обстоятельная статья о том, что нужно, чтобы быстро транспонировать матрицу. Андрей Гудков берёт самую наивную реализацию на C++ (два вложенных цикла, dst[c,r] = src[r,c]) и шаг за шагом разгоняет её на x86_64 до 25 раз. Казалось бы, куда проще: ни деления, ни корней, просто перекладываем байты. Но именно поэтому транспонирование оказывается идеальным полигоном для изучения узких мест железа. Тут вылезает всё разом: высокая задержка памяти, особенности устройства кэша и неспособность компилятора векторизовать код сам. По пути автор каждый раз находит бутылочное горлышко, объясняет его на уровне тактов процессора и придумывает обход. Этапы примерно такие: 🔘Наивная версия как точка отсчёта. 🔘Разворот порядка обхода. 🔘Блочная разбивка матрицы под размер кэш-линии. 🔘Программный префетч. 🔘 Векторизация на 64-битном SIMD, потом на 256-битном. 🔘 Буферизация вывода. Полезного по дороге много. Например, наглядно показано, во сколько обходится промах кэша: попадание в L1d почти бесплатно (4-5 тактов), L2 уже 12-15, L3 — 40-45, а промах до RAM стоит до 300 тактов. И что любой доступ к одному байту на самом деле тянет в кэш всю 64-байтную линию, поэтому весь фокус в том, чтобы успеть подгрузить данные заранее. Хорошее чтение на вечер, если интересна low-level оптимизация под x86_64. Со схемами, анимацией обхода кэша и кодом каждой версии. https://gudok.xyz/transpose/ @prog_stuff

Попалась статья, где автор нам напоминает про недооценённый файл в Linux — /proc/<pid>/mem. Через него можно читать и записывать память любого процесса в реальном времени. Просто cat /proc/self/mem выдаёт ошибку ввода-вывода. Чтобы добраться до данных, нужно сначала сделать lseek на нужное смещение, а потом read или write — либо сразу передать смещение через pread/pwrite. После этого можно вытащить или поменять содержимое памяти. Зачем это нужно: снять «слепок» памяти зависшего приложения и восстановить данные, обойти антиотладку или просто заглянуть процессу внутрь. Стандартный отладочный интерфейс ptrace умеет то же самое через PTRACE_PEEKDATA и PTRACE_POKEDATA, но работать с ним заметно муторнее. В 2002 году автор написал на этой механике утилиту memfetch для съёмки памяти процесса, а на выходных обновил её под современные 64-битные системы. Бонусом — история про то, как в Linux 2.2 можно было вызвать mmap на этом файле и подвесить всю систему. @prog_stuff

Tproger собрал разбор облачных провайдеров для хостинга 1С на 2026 год. Внутри простым языком: какие облака подходят для 1С, зачем смотреть на CPU, NVMe, SLA, резервные копии, 152-ФЗ и поддержку миграции. @prog_stuff

AI Engineer — не переименованный ML-инженер и не разработчик с доступом к API LLM. Это самостоятельная дисциплина со своим мышлением и метриками Глубокий разбор о том, чем прикладной слой отличается от модельного, почему собрать демо занимает пять минут, а сделать систему надёжной становится полноценной работой, и какие четыре навыка западные работодатели выделяют в отдельную роль. ML-инженер живёт в модельном слое: датасеты, обучение, архитектура. AI Engineer берёт готовую модель и превращает её в продукт. Разница сидит не в коде, а в слое ответственности. Цикл сборки, оценки и улучшения не заканчивается никогда, и главная сложность в том, чтобы выбрать правильные метрики качества. RAG, evals, агенты и продакшен-деплой: навыки, которые встречаются в вакансиях снова и снова. Разбираем, что из этого реально нужно и почему в России эта специальность только набирает обороты.

Сенсоры maintainability: как не дать ИИ-агентам нарастить техдолг Подробный гайд про контроль качества кода от генеративных агентов — стоит сохранить, если вы используете Claude, Cursor или Copilot в production. В материале на martinfowler.com Birgitta Böckeler из Thoughtworks показывает, как окружить агента системой ограничений и проверок. Тесты как регрессионный сенсор, статический анализ и проверки сложности работают как автоматический фильтр, не пропускающий проблемы на человеческое ревью. Без такой системы агенты создают техдолг быстрее, чем ускоряют разработку. С ней вы сохраняете контроль над архитектурой и качеством кода.

Unicode 18.0 готовится к релизу 15 сентября 2026 года. Сейчас это beta/draft, но набор новых символов уже заморожен. Главное: стандарт добавляет 13 047 символов. Всего в Unicode будет 172 848 символов. Что появится: 🔘 4 новые письменности: Chisoi, Jurchen, Seal и архаические клинописные числа. 🔘 Seal — самое крупное добавление: больше 11 тысяч символов древней китайской «малой печати». 🔘 Эмодзи тоже обновятся: cracking face, жесты большим пальцем влево/вправо, гусеница монарха, pickle, маяк, метеор, ластик и сачок. Для разработчиков важнее не эмодзи. Unicode 18 меняет правила переноса строк, разбиения текста на графемы, сортировки, security/confusables и variation sequences. Это может влиять на поиск, username, домены, markdown/rendering, редакторы, шрифты, regex и любые системы, которые режут текст «по символам». Обычным приложениям можно ждать, пока Unicode 18 доедет через ОС, браузеры, ICU и языковые рантаймы. А если вы делаете редактор, текстовый движок, font tooling, security-проверки идентификаторов или поддержку CJK, beta уже стоит прогнать на тестах.

Ваша память ещё работает или нейронки уже и помнят всё за вас? Чтобы это проверить мы приготовили для вас «Меморину» — игру, которая поможет проверить вашу память. Всё просто: нужно запомнить и выбрать одинаковые карточки. Если память плохая, то рано или поздно вы всё равно справитесь. А если хорошая, то сможете увидеть ваш потолок скорости. Ну что, готовы проверить? Тогда переходите по ссылке: https://tprg.ru/cyhK

Как вызвать API из письма без JavaScript — инженер из Redo рассказывает, как они шлют миллионы интерактивных писем (отложить подписку, отменить заказ) без редиректа и скриптов. Подход — два несвязанных куска: 🔘AMP Email от Google. Работает в Gmail и Yahoo, итого около 25% покрытия. Автор честно расписывает, чем AMP бесит: жёсткая валидация, нет :has, prefers-color-scheme, !important, @keyframes, ::before/::after, баги годами не чинят, одобрение домена занимает пять дней через Google Form с CAPTCHA. 🔘CSS-трюки добивают покрытие до 70%. Прячем <input type="checkbox">, связываем с <label>, а в #cb:checked ~ .card { background-image: url(...); } подсовываем URL своего API. Браузер лениво загружает картинку только после клика — это и есть тихий GET-запрос. Сервер отдаёт прозрачный пиксель и делает нужный side effect. Подвохи у CSS-фокуса: 🔘ловится только первый клик по кнопке. Обходится цепочкой одинаковых кнопок, которые скрывают предыдущую и показывают следующую; 🔘поведение лениво подгружаемого background-image не специфицировано. Теоретически Apple Mail может однажды начать бот-кликать CSS-урлы, как уже делает с <img>. У Redo на этот случай висит «Interactive Email Doomsday» мониторинг. В тексте есть рабочий пример карточки «отложить подписку на неделю или месяц» с полным HTML и CSS, копируется и работает в AMP, Apple Mail, Thunderbird и новом Outlook. Полная статья: https://redo.com/eng-blog/how-to-call-an-api-from-an-email/ @prog_stuff

Багу MySQL #11472 — почти 21 год. Закрыт в этом году. В июне 2005 года Omer Barnir сообщил: если строки в child-таблице меняются из-за каскадной FK-операции на parent-таблице (ON DELETE CASCADE, ON UPDATE CASCADE, ON DELETE SET NULL), триггеры AFTER DELETE/UPDATE на child-таблице не вызываются. Баг получил severity S2 (Serious). Каждые пару лет в комментариях появлялись новые сообщения от разработчиков: аудит-логи и денормализованные колонки в child-таблицах не отражали реальных изменений после каскада на parent. Причина архитектурная: каскады обрабатывались внутри InnoDB, а триггеры живут на SQL-уровне сервера. Engine-level каскады просто не могли вызвать триггер. В 2009-м баг переоткрывали в 5.1, в 2010-м обещали починить в форке lp:6.1-fk. Что починили: - в MySQL 9.6 ввели SQL-layer foreign key handling, переменная innodb_native_foreign_keys; при OFF каскады выполняются на уровне сервера и можно вызвать триггер; - в MySQL 9.7 добавили opt-in переменную enable_cascade_triggers; при ON и при отключённых native FK в InnoDB BEFORE/AFTER триггеры на child-таблицах вызываются для DELETE/UPDATE CASCADE и SET NULL; - цепочка каскада ограничена 30 таблицами на одно выражение, чтобы триггер на child не мог войти в бесконечную рекурсию через parent; - транзакционная семантика сохранена: ошибка в триггере откатывает всё SQL-выражение. Включается per session, по умолчанию выключена. Приложения, которые годами рассчитывали на текущее поведение, по умолчанию не ломаются. Баг-репорт: https://bugs.mysql.com/bug.php?id=11472 Разбор от Oracle: https://blogs.oracle.com/mysql/no-more-silent-foreign-key-cascades-mysql-9-7-lets-child-triggers-speak-up @prog_stuff

Lock-free очередь на C++ с нуля — подробный разбор того, как собрать MPMC-очередь, которая обгоняет std::queue под std::mutex в восемь раз при 16 потоках. Автор идёт от наивной реализации к финальной и на каждом шаге объясняет, что и почему ломается: 🔘mutex-вариант разваливается из-за context switch в ядре; 🔘наивный CAS-подход спотыкается о ABA и use-after-free; 🔘батчинг по 1024 слота на узел убирает аллокатор с горячего пути и чинит cache locality; 🔘hazard pointers безопасно освобождают память без локов; 🔘thread-local кэш узлов окончательно убирает кучу с быстрого пути. По ходу хорошо разобраны мелочи: alignas(64) против false sharing, выбор между compare_exchange_strong и weak, индивидуальный подбор acquire/release/relaxed/seq_cst под каждую операцию, паттерн DEFER в духе Go для парного Protect/Release. Бенчмарки на 5 млн элементов и 16-ядерном CPU: 🔘2P/2C — 150 мс против 250 мс у мьютекса; 🔘8P/8C — 309 мс против 2152 мс; 🔘16P/16C — 299 мс против 2600 мс; 🔘1P/8C — 254 мс против 3138 мс. В конце автор замечает: для пары потоков std::mutex остаётся правильным выбором, lock-free нужен там, где много контеншена — рендеринг, HFT, аудио, массовый ingestion. Полная версия: https://jaysmito.dev/blog/blog/04-fast-lockfree-queues/

Как ломаются мобильные приложения: пять багов на стыке систем Разбор кейсов из практики мобильного тестирования. Общее у всех одно: формально каждая часть системы работала правильно, а баг появлялся там, где две части впервые встречались с реальными данными и железом. Перечислять конкретные кейсы не буду, лучше сразу статью глянуть: https://tproger.ru/articles/kak-lomayutsya-mobilnye-prilozheniya @prog_stuff

Саймон Уиллисон выступил на PyCon US 2026 с пятиминутным докладом про последние полгода в LLM, а потом разложил всю презентацию с комментариями к каждому слайду. Получился сжатый, но плотный обзор с ноября 2025 по май 2026. Главная мысль: ноябрь 2025 года стал точкой перелома, особенно для агентов-программистов. До ноября они «часто работают». После ноября они «работают почти всегда» и могут стать основным инструментом, не отнимая половину времени на правку их ошибок. Условное звание «лучшей модели» сменило хозяина пять раз за полгода: Claude Sonnet 4.5, потом GPT-5.1, дальше Gemini 3, GPT-5.1 Codex Max, и наконец Anthropic вернул лидерство с Opus 4.5. Уиллисон тестирует это всё на личном бенчмарке «сгенерируй SVG пеликана на велосипеде»: задача, под которую ни одна лаборатория модели не обучает. Второй большой тренд: модели с открытыми весами выросли быстрее ожиданий. Gemma 4 от Google, крупнейшая серия с открытыми весами от американской лаборатории. GLM-5.1 от китайской GLM, открытая модель на 1,5 ТБ. И Qwen3.6-35B-A3B на 20,9 ГБ запускается на ноутбуке Уиллисона и рисует пеликана лучше, чем Claude Opus 4.7. Февральская часть посвящена «эпохе Claws»: после OpenClaw и подобных персональных ИИ-агентов в индустрии прижился общий термин Claws. Mac Mini начали раскупать в Силиконовой долине именно под локальный запуск этих агентов. Полный разбор со слайдами и оригинальными подписями: https://simonwillison.net/2026/May/19/5-minute-llms/ @prog_stuff

Как российская антивирусная индустрия выросла из дискет На Tproger вышла вторая часть истории российского IT, про 90-е и нулевые. Один из больших разделов — про то, как защита от вирусов из академического побочного проекта превратилась в экспортную технологию. В начале 90-х вирусы расползались через дискеты: принесли программу, заодно принесли вирус. Чем больше компьютеров появлялось в офисах и институтах, тем быстрее расходились заражённые файлы. Первой отечественной попыткой был Tadpole, затем антивирусный сканер Tornado, которые потом объединились в Spider's Web. В 1993 году появился Dr.Web, а в 1994-м вышла его первая коммерческая версия. Параллельно Евгений Касперский после работы в НИИ Министерства обороны ушёл в коммерческий IT, занимался антивирусами в КАМИ и в итоге собрал собственную фирму. Самое интересное случилось в 1996–1997: команда договорилась с иностранными вендорами, и зарубежные антивирусные продукты стали использовать российский движок внутри. Технология заработала на экспорт раньше, чем большая часть индустрии. В этом же материале: про Контур и переход налоговой на дискеты, рождение Rambler и Яндекса, дефолт 1998 года и появление первых онлайн-банков. Полная статья: https://tproger.ru/articles/kakim-bylo-it-v-90-h-i-nulevyh-modemy-kompy-defolt-i-pervye-o @prog_stuff

Vite+ — один CLI вместо разрозненного стека Исчерпывающий гайд по инструменту от VoidZero: один бинарник vp заменяет пять отдельных конфигов (Vite, Vitest, Oxlint, Oxfmt, Rolldown, Vite Task и управление версиями Node.js). Раньше всё это жило в разных файлах: .eslintrc, .prettierrc, vitest.config.ts, .nvmrc. Теперь всё в одном vite.config.ts. vp check запускает форматирование, линтинг и типы разом. vp env заменяет NVM. Vite Task работает как кэшированный аналог Turborepo для монорепо. Гайд разбирает каждый компонент: где Vite+ хорошо подходит (новые проекты, стандартный стек) и где нужна осторожность, например в production-базах с кастомными ESLint-плагинами. Читать полный гайд, чтобы понять, стоит ли переезжать.

Страуструп в своём FAQ отвечает на вопрос «Как бороться с утечками памяти?» — коротко: «Пишите код, в котором их нет». Если new, delete и арифметика указателей разбросаны по всей кодовой базе, рано или поздно вы ошибётесь — сложность превысит усилия, которые можете себе позволить. Решение — прятать выделение и освобождение памяти внутри управляемых типов: контейнеры (vector, string) сами следят за своей памятью. Страустроп приводит пример программы без единого явного управления памятью, макросов, кастов и проверок переполнения. Ключевая идея — сократить количество объектов, за которыми программист следит вручную, с десятков тысяч до нескольких десятков. Тогда задача становится управляемой. Если в вашей области нет готовых библиотек, то стройте их сами, используя шаблоны и стандартную библиотеку. Если не получается систематически применять эти техники, то используйте детектор утечек или сборщик мусора. Полная версия: https://www.stroustrup.com/bs_faq2.html#memory-leaks @prog_stuff