C3 — системный язык в традициях C — пять лет использовал unsigned типы для размеров и индексов, как C, C++, Rust и Zig. Казалось логичным: размер не может быть отрицательным. Но на практике это порождало классические баги: бесконечные циклы при декременте, сломанные сравнения при смешивании signed и unsigned, неявные конвертации, которые превращали -1 в огромное положительное число.
Точкой перелома стал невинный пример
Ещё один показательный случай — кольцевой буфер. С signed типами
Автор языка отмечает, что Java в 90-х полностью отказалась от unsigned типов, а Go — язык низкого уровня от разработчиков, прекрасно знавших цену unsigned, — изначально выбрал signed размеры. Границы unsigned (0 и 4 млрд для 32-бит) лежат критически близко к рабочему диапазону, тогда как у signed опасная зона — где-то в районе ±2 млрд. Переполнение unsigned не бросается в глаза: оно даёт вполне правдоподобное число, просто неправильное.
После перехода на signed тип
Полная статья: https://c3-lang.org/blog/unsigned-sizes-a-five-year-mistake/
@prog_stuff
Точкой перелома стал невинный пример
(foo + a) % 2. В C3 операция int + uint продвигалась в signed, что чаще работало правильно. Но если foo оказывался больше INT_MAX, результат становился непредсказуемым. Проблема не в сложности исправления, а в том, что это неожиданно: везде «просто работало», а тут вдруг ломается.Ещё один показательный случай — кольцевой буфер. С signed типами
((start + offset) % length + length) % length корректно обрабатывает отрицательный offset. С unsigned та же формула молча даёт неправильный результат, и компилятор не подскажет, что offset_back обработан неверно.Автор языка отмечает, что Java в 90-х полностью отказалась от unsigned типов, а Go — язык низкого уровня от разработчиков, прекрасно знавших цену unsigned, — изначально выбрал signed размеры. Границы unsigned (0 и 4 млрд для 32-бит) лежат критически близко к рабочему диапазону, тогда как у signed опасная зона — где-то в районе ±2 млрд. Переполнение unsigned не бросается в глаза: оно даёт вполне правдоподобное число, просто неправильное.
После перехода на signed тип
sz (вместо usz) код оказался проще и очевиднее. Неявные конвертации между signed и unsigned убраны полностью. Автор признаётся, что привычка использовать unsigned была настолько глубоко внутренней, что переход казался «запрещённым» — но данные оказались неумолимыми.Полная статья: https://c3-lang.org/blog/unsigned-sizes-a-five-year-mistake/
@prog_stuff
C3 Programming Language
Unsigned sizes: a five year mistake
C3 is the ergonomic, safe evolution of C. Familiar syntax, full ABI compatibility, optionals, slices, contracts and zero-cost abstractions.
❤1👍1
Автор финско-английского словаря Taskusanakirja рассказал, как сжал 3-гигабайтную SQLite-базу до 10-мегабайтного бинарника.
Проблема была в финском языке — он агглютинативный, у одного слова может быть больше ста форм с разными окончаниями. Trie, который использовался для поиска по префиксам, справлялся с 400 тысячами слов (~50 МБ), но отказался масштабироваться на десятки миллионов форм. Временный костыль — SQLite с полнотекстовым поиском на 3 ГБ, с которым нужно было таскать трёхгигабайтную загрузку.
Решение — finite state transducer (FST) из Rust-крейта fst от BurntSushi. FST, в отличие от trie, сжимает и суффиксы тоже, а для финского с его повторяющимися окончаниями это идеально. Итог: 10 МБ вместо 3 ГБ, сжатие в 300 раз, и весь словарь теперь помещается в один статический бинарник.
Полная версия: https://til.andrew-quinn.me/posts/replacing-a-3-gb-sqlite-database-with-a-7-mb-fst-finite-state-trandsucer-binary/
@prog_stuff
Проблема была в финском языке — он агглютинативный, у одного слова может быть больше ста форм с разными окончаниями. Trie, который использовался для поиска по префиксам, справлялся с 400 тысячами слов (~50 МБ), но отказался масштабироваться на десятки миллионов форм. Временный костыль — SQLite с полнотекстовым поиском на 3 ГБ, с которым нужно было таскать трёхгигабайтную загрузку.
Решение — finite state transducer (FST) из Rust-крейта fst от BurntSushi. FST, в отличие от trie, сжимает и суффиксы тоже, а для финского с его повторяющимися окончаниями это идеально. Итог: 10 МБ вместо 3 ГБ, сжатие в 300 раз, и весь словарь теперь помещается в один статический бинарник.
Полная версия: https://til.andrew-quinn.me/posts/replacing-a-3-gb-sqlite-database-with-a-7-mb-fst-finite-state-trandsucer-binary/
@prog_stuff
👍2
Страуструп в своём FAQ отвечает на вопрос «Как бороться с утечками памяти?» — коротко: «Пишите код, в котором их нет».
Если
Ключевая идея — сократить количество объектов, за которыми программист следит вручную, с десятков тысяч до нескольких десятков. Тогда задача становится управляемой.
Если в вашей области нет готовых библиотек, то стройте их сами, используя шаблоны и стандартную библиотеку. Если не получается систематически применять эти техники, то используйте детектор утечек или сборщик мусора.
Полная версия: https://www.stroustrup.com/bs_faq2.html#memory-leaks
@prog_stuff
Если
new, delete и арифметика указателей разбросаны по всей кодовой базе, рано или поздно вы ошибётесь — сложность превысит усилия, которые можете себе позволить. Решение — прятать выделение и освобождение памяти внутри управляемых типов: контейнеры (vector, string) сами следят за своей памятью. Страустроп приводит пример программы без единого явного управления памятью, макросов, кастов и проверок переполнения.Ключевая идея — сократить количество объектов, за которыми программист следит вручную, с десятков тысяч до нескольких десятков. Тогда задача становится управляемой.
Если в вашей области нет готовых библиотек, то стройте их сами, используя шаблоны и стандартную библиотеку. Если не получается систематически применять эти техники, то используйте детектор утечек или сборщик мусора.
Полная версия: https://www.stroustrup.com/bs_faq2.html#memory-leaks
@prog_stuff
👍2
Vite+ — один CLI вместо разрозненного стека
Исчерпывающий гайд по инструменту от VoidZero: один бинарник
Раньше всё это жило в разных файлах:
Гайд разбирает каждый компонент: где Vite+ хорошо подходит (новые проекты, стандартный стек) и где нужна осторожность, например в production-базах с кастомными ESLint-плагинами.
Читать полный гайд, чтобы понять, стоит ли переезжать.
Исчерпывающий гайд по инструменту от 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-плагинами.
Читать полный гайд, чтобы понять, стоит ли переезжать.
👍1
Как российская антивирусная индустрия выросла из дискет
На 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
На 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
Tproger
История российского IT: 90-е и нулевые — от дискет до Рунета
Как появился Рунет, зачем дефолт 1998 года помог аутсорсу и почему первые банковские карты были почти бесполезны. История российской IT-индустрии от первых ПК до 2010 года.
❤1👍1
Саймон Уиллисон выступил на 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
Главная мысль: ноябрь 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
Simon Willison’s Weblog
The last six months in LLMs in five minutes
I put together these annotated slides from my five minute lightning talk at PyCon US 2026, using the latest iteration of my annotated presentation tool. # I presented this lightning …
👍1👌1🤪1
Как ломаются мобильные приложения: пять багов на стыке систем
Разбор кейсов из практики мобильного тестирования. Общее у всех одно: формально каждая часть системы работала правильно, а баг появлялся там, где две части впервые встречались с реальными данными и железом.
Перечислять конкретные кейсы не буду, лучше сразу статью глянуть: https://tproger.ru/articles/kak-lomayutsya-mobilnye-prilozheniya
@prog_stuff
Разбор кейсов из практики мобильного тестирования. Общее у всех одно: формально каждая часть системы работала правильно, а баг появлялся там, где две части впервые встречались с реальными данными и железом.
Перечислять конкретные кейсы не буду, лучше сразу статью глянуть: https://tproger.ru/articles/kak-lomayutsya-mobilnye-prilozheniya
@prog_stuff
👍2
Lock-free очередь на C++ с нуля — подробный разбор того, как собрать MPMC-очередь, которая обгоняет
Автор идёт от наивной реализации к финальной и на каждом шаге объясняет, что и почему ломается:
🔘 mutex-вариант разваливается из-за context switch в ядре;
🔘 наивный CAS-подход спотыкается о ABA и use-after-free;
🔘 батчинг по 1024 слота на узел убирает аллокатор с горячего пути и чинит cache locality;
🔘 hazard pointers безопасно освобождают память без локов;
🔘 thread-local кэш узлов окончательно убирает кучу с быстрого пути.
По ходу хорошо разобраны мелочи:
Бенчмарки на 5 млн элементов и 16-ядерном CPU:
🔘 2P/2C — 150 мс против 250 мс у мьютекса;
🔘 8P/8C — 309 мс против 2152 мс;
🔘 16P/16C — 299 мс против 2600 мс;
🔘 1P/8C — 254 мс против 3138 мс.
В конце автор замечает: для пары потоков
Полная версия: https://jaysmito.dev/blog/blog/04-fast-lockfree-queues/
@prog_stuff
std::queue под std::mutex в восемь раз при 16 потоках.Автор идёт от наивной реализации к финальной и на каждом шаге объясняет, что и почему ломается:
По ходу хорошо разобраны мелочи:
alignas(64) против false sharing, выбор между compare_exchange_strong и weak, индивидуальный подбор acquire/release/relaxed/seq_cst под каждую операцию, паттерн DEFER в духе Go для парного Protect/Release.Бенчмарки на 5 млн элементов и 16-ядерном CPU:
В конце автор замечает: для пары потоков
std::mutex остаётся правильным выбором, lock-free нужен там, где много контеншена — рендеринг, HFT, аудио, массовый ingestion.Полная версия: https://jaysmito.dev/blog/blog/04-fast-lockfree-queues/
@prog_stuff
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Багу 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
Закрыт в этом году.
В июне 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
Oracle
No More Silent Foreign Key Cascades: MySQL 9.7 Lets Child Triggers Speak Up
👍1
Как вызвать API из письма без JavaScript — инженер из Redo рассказывает, как они шлют миллионы интерактивных писем (отложить подписку, отменить заказ) без редиректа и скриптов.
Подход — два несвязанных куска:
🔘 AMP Email от Google. Работает в Gmail и Yahoo, итого около 25% покрытия. Автор честно расписывает, чем AMP бесит: жёсткая валидация, нет
🔘 CSS-трюки добивают покрытие до 70%. Прячем
Подвохи у CSS-фокуса:
🔘 ловится только первый клик по кнопке. Обходится цепочкой одинаковых кнопок, которые скрывают предыдущую и показывают следующую;
🔘 поведение лениво подгружаемого
В тексте есть рабочий пример карточки «отложить подписку на неделю или месяц» с полным HTML и CSS, копируется и работает в AMP, Apple Mail, Thunderbird и новом Outlook.
Полная статья: https://redo.com/eng-blog/how-to-call-an-api-from-an-email/
@prog_stuff
Подход — два несвязанных куска:
:has, prefers-color-scheme, !important, @keyframes, ::before/::after, баги годами не чинят, одобрение домена занимает пять дней через Google Form с CAPTCHA.<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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Ваша память ещё работает или нейронки уже и помнят всё за вас?
Чтобы это проверить мы приготовили для вас «Меморину» — игру, которая поможет проверить вашу память.
Всё просто: нужно запомнить и выбрать одинаковые карточки. Если память плохая, то рано или поздно вы всё равно справитесь. А если хорошая, то сможете увидеть ваш потолок скорости.
Ну что, готовы проверить? Тогда переходите по ссылке: https://tprg.ru/cyhK
Чтобы это проверить мы приготовили для вас «Меморину» — игру, которая поможет проверить вашу память.
Всё просто: нужно запомнить и выбрать одинаковые карточки. Если память плохая, то рано или поздно вы всё равно справитесь. А если хорошая, то сможете увидеть ваш потолок скорости.
Ну что, готовы проверить? Тогда переходите по ссылке: https://tprg.ru/cyhK
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 уже стоит прогнать на тестах.
@prog_stuff
Главное: стандарт добавляет 13 047 символов. Всего в Unicode будет 172 848 символов.
Что появится:
Для разработчиков важнее не эмодзи. Unicode 18 меняет правила переноса строк, разбиения текста на графемы, сортировки, security/confusables и variation sequences.
Это может влиять на поиск, username, домены, markdown/rendering, редакторы, шрифты, regex и любые системы, которые режут текст «по символам».
Обычным приложениям можно ждать, пока Unicode 18 доедет через ОС, браузеры, ICU и языковые рантаймы. А если вы делаете редактор, текстовый движок, font tooling, security-проверки идентификаторов или поддержку CJK, beta уже стоит прогнать на тестах.
@prog_stuff
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Сенсоры maintainability: как не дать ИИ-агентам нарастить техдолг
Подробный гайд про контроль качества кода от генеративных агентов — стоит сохранить, если вы используете Claude, Cursor или Copilot в production. В материале на martinfowler.com Birgitta Böckeler из Thoughtworks показывает, как окружить агента системой ограничений и проверок.
Тесты как регрессионный сенсор, статический анализ и проверки сложности работают как автоматический фильтр, не пропускающий проблемы на человеческое ревью. Без такой системы агенты создают техдолг быстрее, чем ускоряют разработку. С ней вы сохраняете контроль над архитектурой и качеством кода.
Подробный гайд про контроль качества кода от генеративных агентов — стоит сохранить, если вы используете Claude, Cursor или Copilot в production. В материале на martinfowler.com Birgitta Böckeler из Thoughtworks показывает, как окружить агента системой ограничений и проверок.
Тесты как регрессионный сенсор, статический анализ и проверки сложности работают как автоматический фильтр, не пропускающий проблемы на человеческое ревью. Без такой системы агенты создают техдолг быстрее, чем ускоряют разработку. С ней вы сохраняете контроль над архитектурой и качеством кода.
✍1❤1
AI Engineer — не переименованный ML-инженер и не разработчик с доступом к API LLM. Это самостоятельная дисциплина со своим мышлением и метриками
Глубокий разбор о том, чем прикладной слой отличается от модельного, почему собрать демо занимает пять минут, а сделать систему надёжной становится полноценной работой, и какие четыре навыка западные работодатели выделяют в отдельную роль.
ML-инженер живёт в модельном слое: датасеты, обучение, архитектура. AI Engineer берёт готовую модель и превращает её в продукт. Разница сидит не в коде, а в слое ответственности. Цикл сборки, оценки и улучшения не заканчивается никогда, и главная сложность в том, чтобы выбрать правильные метрики качества.
RAG, evals, агенты и продакшен-деплой: навыки, которые встречаются в вакансиях снова и снова. Разбираем, что из этого реально нужно и почему в России эта специальность только набирает обороты.
Глубокий разбор о том, чем прикладной слой отличается от модельного, почему собрать демо занимает пять минут, а сделать систему надёжной становится полноценной работой, и какие четыре навыка западные работодатели выделяют в отдельную роль.
ML-инженер живёт в модельном слое: датасеты, обучение, архитектура. AI Engineer берёт готовую модель и превращает её в продукт. Разница сидит не в коде, а в слое ответственности. Цикл сборки, оценки и улучшения не заканчивается никогда, и главная сложность в том, чтобы выбрать правильные метрики качества.
RAG, evals, агенты и продакшен-деплой: навыки, которые встречаются в вакансиях снова и снова. Разбираем, что из этого реально нужно и почему в России эта специальность только набирает обороты.
👍1
Tproger собрал разбор облачных провайдеров для хостинга 1С на 2026 год.
Внутри простым языком: какие облака подходят для 1С, зачем смотреть на CPU, NVMe, SLA, резервные копии, 152-ФЗ и поддержку миграции.
@prog_stuff
Внутри простым языком: какие облака подходят для 1С, зачем смотреть на CPU, NVMe, SLA, резервные копии, 152-ФЗ и поддержку миграции.
@prog_stuff
Tproger
Хостинг 1С в облаке 2026: сравнение провайдеров — ITGLOBAL, Selectel, K2 Cloud и другие
Сравниваем облачных провайдеров для 1С в 2026 году: процессоры, дисковая подсистема, SLA и реальные кейсы. ITGLOBAL.COM, K2 Cloud, Selectel, MWS, Beeline Cloud — разбираем архитектуру, чтобы вы выбрали под свою нагрузку.
❤1👍1
Попалась статья, где автор нам напоминает про недооценённый файл в Linux —
Просто
Зачем это нужно: снять «слепок» памяти зависшего приложения и восстановить данные, обойти антиотладку или просто заглянуть процессу внутрь. Стандартный отладочный интерфейс
В 2002 году автор написал на этой механике утилиту memfetch для съёмки памяти процесса, а на выходных обновил её под современные 64-битные системы. Бонусом — история про то, как в Linux 2.2 можно было вызвать
@prog_stuff
/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
Substack
Weekend trivia: your process' memory is a file
The underappreciated gem of /proc/<pid>/mem
❤1👍1
Обстоятельная статья о том, что нужно, чтобы быстро транспонировать матрицу. Андрей Гудков берёт самую наивную реализацию на 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
Казалось бы, куда проще: ни деления, ни корней, просто перекладываем байты. Но именно поэтому транспонирование оказывается идеальным полигоном для изучения узких мест железа. Тут вылезает всё разом: высокая задержка памяти, особенности устройства кэша и неспособность компилятора векторизовать код сам.
По пути автор каждый раз находит бутылочное горлышко, объясняет его на уровне тактов процессора и придумывает обход. Этапы примерно такие:
Полезного по дороге много. Например, наглядно показано, во сколько обходится промах кэша: попадание в L1d почти бесплатно (4-5 тактов), L2 уже 12-15, L3 — 40-45, а промах до RAM стоит до 300 тактов. И что любой доступ к одному байту на самом деле тянет в кэш всю 64-байтную линию, поэтому весь фокус в том, чтобы успеть подгрузить данные заранее.
Хорошее чтение на вечер, если интересна low-level оптимизация под x86_64. Со схемами, анимацией обхода кэша и кодом каждой версии.
https://gudok.xyz/transpose/
@prog_stuff
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Большой разбор 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
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 часов.
В разборе показывают путь расследования:
Главная цифра: firmware upgrade automation сократили с почти 4 часов до 3 минут, а последующий single boot — примерно с 20 минут до менее чем минуты.
Сохранять тем, кто отвечает за bare metal, firmware updates, PXE/iPXE-загрузку или просто любит production-разборы, где проблема прячется не в коде приложения, а в цепочке до старта ОС. Тут хорошо видно, почему boot order, таймауты и vendor quirks стоит тестировать так же внимательно, как обычный rollout.
@prog_stuff
Please open Telegram to view this post
VIEW IN TELEGRAM
The Cloudflare Blog
How we reduced core unit boot time from hours to minutes
We investigated why firmware updates were causing our core servers to take four hours to reboot. By diving into UEFI data structures and iPXE automation, we eliminated unnecessary timeouts and cut boot times back down to minutes.
Эссе Марка Брукера, инженера в 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
Брукер заходит от электроники. Обратная связь, пожалуй, самая мощная идея в инженерии: заверни слабый компонент в петлю обратной связи, и на выходе получишь поведение, на которое сам компонент не способен. Классический пример: операционный усилитель с умножителем вместе превращаются в извлекатель квадратного корня.
ИИ-агент устроен так же. Внутри сидит LLM, полезный, но небезупречный компонент с разомкнутым поведением. Агент оборачивает его в петлю: сгенерировал, собрал, прогнал тесты, увидел ошибку, поправил. Вся эволюция инструментов за последние пару лет именно про это, обратная связь переехала от человека за клавиатурой внутрь самого агента.
Отсюда его гипотеза: в долгую агенты будут щёлкать задачи, где есть быстрая и точная обратная связь, и спотыкаться там, где её нет. Потолок задаёт качество этого сигнала «правильно или нет». Размер модели тут уже вторичен.
Это уже заметно. Агенты сильны в оптимизации производительности, где есть бенчмарки. Rust своими явными ошибками компиляции буквально ведёт агента к корректному коду. Property-based тесты бесценны. А вот с архитектурой беда: тут обратная связь в духе «пойму, когда увижу». И с конкурентным кодом так же, там ошибка молча портит данные в рантайме.
Дальше самое интересное. Сравните две задачи: сверстать приятный фоторедактор в вебе и написать корректный высокопроизводительный движок хранения для базы данных. Кажется, первое проще. Но по гипотезе Брукера в долгую проще как раз второе. У движка БД есть чёткая спецификация: API, гарантии безопасности и живучести, и итерироваться к успеху можно вообще без участия людей. А «приятный» сайт упирается в человека в петле, а человек медленный и непоследовательный судья.
Вывод переворачивает привычную интуицию: SaaS и интерфейсы окажутся трудными, а системный софт лёгким. И на первый план выходит спецификация, умение записать, что значит «хорошо», плюс инструменты, которые это проверяют: Rust, Verus, TLA+, симуляторы, моки. Сама по себе генерация кода становится вторичной.
Хорошее чтение, чтобы переосмыслить, куда вкладывать силы в ближайшие годы.
https://brooker.co.za/blog/2026/05/18/whats-easy-whats-hard.html
@prog_stuff
brooker.co.za
What's Easy Now? What's Hard Now? - Marc's Blog
👍1
Почему передача репозитория не равна передаче проекта
Programming as Theory Building — классический текст Питера Наура о том, что программирование не сводится к коду, документации и диаграммам. Всё это важные артефакты, но они не содержат всю «теорию» системы.
Главное в тексте — очень точное объяснение боли legacy: проект можно формально передать полностью, но новая команда всё равно не получит систему. Репозиторий есть, README есть, схемы есть, backlog есть, а уверенности в изменениях нет.
Теория у Наура — это понимание, которое держат в голове разработчики: почему решения приняты именно так, какие варианты уже пробовали, какие ограничения нельзя трогать и какие изменения выглядят локально разумно, но ломают общий смысл конструкции.
Отсюда хорошо считываются последствия для сопровождения. Документация помогает, но не заменяет участие в разработке. Code review проверяет не только строки, но и то, совпадает ли изменение с теорией системы. Онбординг — это не экскурсия по файлам, а постепенная передача причин, ограничений и инженерной памяти.
Сохранять тем, кто занимается legacy, онбордингом, ревью, архитектурой или передачей проектов между командами. Текст старый, но после него иначе смотришь на фразу «мы всё задокументировали».
https://pages.cs.wisc.edu/~remzi/Naur.pdf
Programming as Theory Building — классический текст Питера Наура о том, что программирование не сводится к коду, документации и диаграммам. Всё это важные артефакты, но они не содержат всю «теорию» системы.
Главное в тексте — очень точное объяснение боли legacy: проект можно формально передать полностью, но новая команда всё равно не получит систему. Репозиторий есть, README есть, схемы есть, backlog есть, а уверенности в изменениях нет.
Теория у Наура — это понимание, которое держат в голове разработчики: почему решения приняты именно так, какие варианты уже пробовали, какие ограничения нельзя трогать и какие изменения выглядят локально разумно, но ломают общий смысл конструкции.
Отсюда хорошо считываются последствия для сопровождения. Документация помогает, но не заменяет участие в разработке. Code review проверяет не только строки, но и то, совпадает ли изменение с теорией системы. Онбординг — это не экскурсия по файлам, а постепенная передача причин, ограничений и инженерной памяти.
Сохранять тем, кто занимается legacy, онбордингом, ревью, архитектурой или передачей проектов между командами. Текст старый, но после него иначе смотришь на фразу «мы всё задокументировали».
https://pages.cs.wisc.edu/~remzi/Naur.pdf
Где держать 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
Tproger собрал подборку из шести VPS-провайдеров под этот сценарий: от тарифов за пару сотен рублей в месяц до конфигураций с DDR5 и портом 10 Гбит/с. У каждого свой акцент — где-то посуточная оплата и запуск за минуту, где-то API для CI/CD, бэкапы и приватные сети, где-то зарубежные локации.
Внутри по каждому провайдеру: реальные конфигурации, цены, на какой нагрузке тестировали и под какой сценарий брать.
https://tproger.ru/articles/gde-razvernut-bota-ili-api---podborka-vps--kotorye-ne-tormozyat
@prog_stuff
Tproger
Где развернуть бота или API — подборка VPS, которые не тормозят
Мы собрали подборку провайдеров VPS, где можно быстро поднять сервис — от тестового окружения до продакшн-нагрузки.