Dev News от Максима Соснова
Відкрити в Telegram
Привет! Меня зовут Максим Соснов и по утрам я читаю всякие разные дайджесты про фронтенд, разработку и управление разработкой. Самые интересные, по моему мнению, ссылки из этих дайджестов я кидаю в этот канал с небольшим описанием. Контакт: @msosnov
Показати більше2 784
Підписники
Немає даних24 години
-37 днів
-930 днів
Завантажуємо дані
Схожі канали
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
жовтень '26жовт '26
жовтень '26
+13
в 0 каналах
вересень '26
+30
в 0 каналах
Get PRO
серпень '26
+31
в 0 каналах
Get PRO
липень '26
+35
в 0 каналах
Get PRO
червень '26
+46
в 0 каналах
Get PRO
травень '26
+46
в 1 каналах
Get PRO
квітень '26
+41
в 0 каналах
Get PRO
березень '26
+39
в 0 каналах
Get PRO
лютий '26
+41
в 0 каналах
Get PRO
січень '26
+31
в 0 каналах
Get PRO
грудень '25
+27
в 1 каналах
Get PRO
листопад '25
+33
в 1 каналах
Get PRO
жовтень '25
+65
в 2 каналах
Get PRO
вересень '25
+54
в 1 каналах
Get PRO
серпень '25
+52
в 0 каналах
Get PRO
липень '25
+86
в 7 каналах
Get PRO
червень '25
+50
в 0 каналах
Get PRO
травень '25
+57
в 0 каналах
Get PRO
квітень '25
+68
в 4 каналах
Get PRO
березень '25
+79
в 2 каналах
Get PRO
лютий '25
+72
в 2 каналах
Get PRO
січень '25
+75
в 1 каналах
Get PRO
грудень '24
+88
в 2 каналах
Get PRO
листопад '24
+156
в 1 каналах
Get PRO
жовтень '24
+96
в 1 каналах
Get PRO
вересень '24
+87
в 0 каналах
Get PRO
серпень '24
+134
в 3 каналах
Get PRO
липень '24
+87
в 1 каналах
Get PRO
червень '24
+111
в 0 каналах
Get PRO
травень '24
+795
в 2 каналах
Get PRO
квітень '24
+41
в 0 каналах
Get PRO
березень '24
+55
в 1 каналах
Get PRO
лютий '24
+63
в 1 каналах
Get PRO
січень '24
+98
в 1 каналах
Get PRO
грудень '23
+94
в 2 каналах
Get PRO
листопад '23
+31
в 1 каналах
Get PRO
жовтень '23
+88
в 1 каналах
Get PRO
вересень '23
+58
в 0 каналах
Get PRO
серпень '23
+47
в 0 каналах
Get PRO
липень '23
+36
в 0 каналах
Get PRO
червень '23
+44
в 0 каналах
Get PRO
травень '23
+27
в 0 каналах
Get PRO
квітень '23
+54
в 0 каналах
Get PRO
березень '23
+61
в 0 каналах
Get PRO
лютий '23
+33
в 0 каналах
Get PRO
січень '23
+42
в 0 каналах
Get PRO
грудень '22
+35
в 0 каналах
Get PRO
листопад '22
+138
в 0 каналах
Get PRO
жовтень '22
+65
в 0 каналах
Get PRO
вересень '22
+114
в 0 каналах
Get PRO
серпень '22
+18
в 0 каналах
Get PRO
липень '22
+48
в 0 каналах
Get PRO
червень '22
+32
в 0 каналах
Get PRO
травень '22
+15
в 0 каналах
Get PRO
квітень '22
+4
в 0 каналах
Get PRO
березень '22
+4
в 0 каналах
Get PRO
лютий '22
+21
в 0 каналах
Get PRO
січень '22
+64
в 0 каналах
Get PRO
грудень '21
+6
в 0 каналах
Get PRO
листопад '21
+8
в 0 каналах
Get PRO
жовтень '21
+333
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 18 жовтня | 0 | |||
| 17 жовтня | 0 | |||
| 16 жовтня | +2 | |||
| 15 жовтня | +1 | |||
| 14 жовтня | +1 | |||
| 13 жовтня | 0 | |||
| 12 жовтня | 0 | |||
| 11 жовтня | +3 | |||
| 10 жовтня | 0 | |||
| 09 жовтня | +1 | |||
| 08 жовтня | +1 | |||
| 07 жовтня | +1 | |||
| 06 жовтня | 0 | |||
| 05 жовтня | 0 | |||
| 04 жовтня | +1 | |||
| 03 жовтня | +1 | |||
| 02 жовтня | 0 | |||
| 01 жовтня | +1 |
Дописи каналу
Responsive iframes in Chrome 154
В Chrome 154 добавили возможность автоматически подстраивать размер iframe под контент внутри. Годами разработчики делали связку через
postMessage с передачей текущего размера и установкой этого размера iframe, но теперь жизнь может стать немного проще.
Чтобы автоматический ресайз работал, необходимо сделать несколько простых шагов.
Первый: в родительском документе установить frame-sizing.
iframe {
width: 100%;
frame-sizing: content-height;
}
meta-тег.
<meta name="responsive-embedded-sizing" content="allow-origins=*">
window.requestResize() для обновления размера в родительском окне. Это нужно, чтобы избежать бесконечного цикла ререндера.
https://developer.chrome.com/blog/responsive-iframes
#development #chrome #css #iframe| 2 | Electron to PWA: There and Back Again
Автор год собирал EPUB-редактор на Electron, потом около полугода переписывал его в PWA и вернулся обратно.
Переезд на PWA рассматривался по нескольким причинам.
Первая — это размер Chromium, который требуется бандлить в бинарь при создании Electron-приложения. Это примерно 250 МБ. Однако автор сразу же пишет, что это не такая важная проблема, т.к. вкладка Twitter съедает гораздо больше.
Вторая — это DX разработки на Electron. Electron слишком низкоуровневый и застрял в нулевых по уровню DX: устоявшихся паттернов нет, HMR нет, удобного управления окнами нет и прочее. Есть проекты типа electron-builder и electron-vite, но они не сильно помогают.
PWA же выглядит как хорошее решение: все DX-плюшки веб-разработки доступны, а также никакого налога на оболочку и возможность установить приложение на телефон.
Выглядит хорошо, но оказалось, что у PWA тоже есть проблемы:
- File System API и OPFS сделаны очень хорошо, но настройка ассоциаций файлов и параметров запуска сделана не очень хорошо
- Кроме того, достаточно быстро автор зарепортил 2 бага в базовом API для PWA
- PWA работает по-разному в разных браузерах, и у разработчика не так много возможностей сказать пользователю, чтобы он установил PWA из правильного браузера
- Окна приложений на десктопе сделаны криво, и нет возможности сделать нормально
- Нельзя кастомизировать меню в трее или доке
- Нельзя сделать системные хоткеи
- Нельзя сделать хоткеи Cmd+Q и Cmd+S, которые зарезервированы за браузером (хотя Cmd+Q — системный хоткей уровня Alt+F4)
- Нельзя интегрировать PWA в системные фичи вида «открой файл через приложение»
В итоге вернулся к Electron.
В целом вывод такой:
Если вам не нужны фичи Electron в виде интеграций с ОС, то берите PWA — DX лучше, кода меньше, тестировать проще.
https://kettanaito.com/blog/electron-to-pwa-and-back-again
#development #electron #pwa #desktop | 626 |
| 3 | Improving site performance by shipping more CSS
GitHub улучшил перформанс, переведя код со styled-components на чистый CSS.
В чём суть. Есть Primer — библиотека компонентов GitHub: кнопки, баннеры, крошки. Все стили в ней были реализованы через CSS-in-JS.
Использование CSS-in-JS негативно сказывается на перформансе:
- на первом заходе стили инициализируются в браузере
- сбор стилей на сервере тормозит SSR
- да и вообще все стили вместо простой вставки в браузер каждый раз надо рассчитывать на каждый рендер компонента
Решение проблемы достаточно наивное — использовать CSS Modules.
Переписывание Primer проводили покомпонентно и безопасно. Сначала перевели все внутренние стили на чистый CSS, и это уже ускорило SSR на 55%, а инициализацию компонентов на 25%.
Но остались использования CSS-in-JS в местах вызова Primer-компонентов, где использовались возможности CSS-in-JS для кастомизации поведения. Поэтому следующим шагом было опубликовать 2 вариации библиотеки Primer — с поддержкой CSS-in-JS и на чистом CSS.
Переход на чистый CSS в местах вызова занял ещё где-то полгода, и в июне 2026 года GitHub полностью на CSS Modules.
В целом очевидная проблема и очевидное решение. Полезно, что есть реальные цифры налога на использование CSS-in-JS.
https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css/
#development #css #performance #github #react #css-in-js | 784 |
| 4 | How we made claude.ai 3x faster in two weeks
Пользователи жаловались на проблемы с перформансом claude.ai и десктопного приложения Claude. Anthropic за две недели ускорили оба продукта примерно в три раза.
Результаты двухнедельной работы (цифры — p75):
- время до возможности печатать при свежей загрузке сайта: 3.1 с → 0.55 с
- новая сессия Claude Code: 0.8 с → 0.3 с
- загрузка облачной сессии Cowork: 2.6 с → 0.73 с
Как и что они делали.
Во-первых, взяли 4 основных пользовательских сценария, скорость которых оптимизировали:
- Открыть приложение
- Начать чат
- Открыть старый чат
- Отправить сообщение
Сам процесс оптимизации примерно следующий:
- В Slack создаётся тред с агентом, где разработчик ставит задачу по оптимизации
- Агент исследует, находит проблемы, приносит решения. Человек их смотрит
- Все проблемы и решения сначала подтверждаются локально: сначала формируется перформанс-бенчмарк, который красный на текущем коде, а после фикса должен стать зелёным
- Если чего-то не хватает — агент дополнительно инструментирует код
- Рискованные изменения раскатываются не сразу на всех пользователей, а поэтапно
Сами оптимизации и исследование достаточно сложные. Я бы сказал, что ни я, ни кто-то из моих коллег так глубоко бы не копал, чтобы ускорить сайт. Чтобы понять, почему я так считаю, достаточно взглянуть на то, что сделано в рамках исследования проблем.
Замер обычного времени выполнения и отрисовки плавает в зависимости от нагрузки CPU, сети, GC и других факторов. Поэтому анализ делался на следующих метриках:
- Количество инструкций CPU, которые понадобились для прохождения сценария
- Количество вызовов функций JS
- Коммиты React
- Пересчёт стилей
- Мутации DOM
Чтобы сделать тесты на инструкции CPU детерминированными, гоняли Node с флагом --predictable: одно и то же выполнение даёт одинаковое расписание GC и компиляции, поэтому число инструкций стабильно от прогона к прогону.
Также обычных метрик кое-где не хватило. Например, CLS не ловил дёрганье сайдбара, поэтому добавили свои события через Layout Instability API.
Отдельно собрали стенд Chrome на 120 Hz, чтобы убедиться, что отрисовка стрима длинного ответа не проседает ниже 120 fps.
Что сделано в рамках улучшения перформанса:
- Пока React не инициализировался, поле ввода уже доступно как статический HTML. Затем React рендерит приложение поверх без миганий, потери ввода и сдвигов лейаута (отдельными тестами проверяют, что нет сдвига ни на пиксель)
- Нашли селектор :root:has(), из-за которого каждое изменение DOM вело к лишним 24 мс пересчёта стилей
- Удалили забытый location.reload() — он давал около полумиллиона скрытых перезагрузок в день, которые обычные load-метрики не видели
- Подсветка кода зависала примерно на секунду из-за em dash: любой non-Latin-1 символ клал всю строку в UTF-16, и regex шли по медленному двухбайтовому пути. Фикс на 20 строк — скопировать блок кода в однобайтовую строку до подсветки
- Зашили code cache V8 в десктопное приложение, чтобы приложик сразу работал с байткодом, а не компилировал JS каждый раз при открытии
- После ускорения обнаружили кейс с пререндером. Когда в адресной строке вводишь сайт, Chrome уже рендерит страницу в фоне, но может сделать это не с той высотой (на корпоративных устройствах часть высоты пустого таба забирает плашка «браузер управляется политиками компании»). До ускорения рендера этого не замечали, после ускорения — пришлось фиксить
Чтобы не было деградации, перформанс-бенчмарки повесили в CI — так меньше шансов потом уронить скорость.
Как итоги:
- Ускорение в 3 раза
- 3000 мерджей
- 200 изменений в день
- 150 тредов с агентом
Ну, а в целом итог такой:
- Раньше ускорение сайта это была работа на недели, а то и месяцы и с результатом можно было идти с докладом на конференцию
- Теперь достаточно оплатить подписку для любого агента и он за короткий срок сделает тот же результат, что делает человек за месяц работы
https://claude.dev/blog/how-we-made-claude-ai-faster
#development #performance #claude #ai #frontend #observability | 1 051 |
| 5 | Дайджест за 2026-09-07 - 2026-09-09
Playwright v1.62.0
Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook.
Mobile View — see your site on desktop & mobile at once
Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. | 1 157 |
| 6 | Mobile View — see your site on desktop & mobile at once
Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво.
Это, конечно, не полноценный симулятор, но решение очень хорошее как для тестирования, так и для демонстрации.
Строго рекомендую хотя бы ознакомиться.
https://mobileview.app/
#development #chrome #tools #responsive #frontend | 1 310 |
| 7 | Playwright v1.62.0
Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook.
Забавно, что инструкция по установке начинается с «запустите LLM». Буквально.
> Step 1: Point your coding agent at the skill
npx playwright init-skills
Set up component testing using the playwright-component-testing skill.
Затем надо немного сконфигурировать конфиг Playwright.
Затем создать давно знакомые нам stories-файлы
src/components/Button.story.tsx
import { Button } from './Button';
export const Primary = () => <Button title='Submit' />;
export const Disabled = () => <Button title='Submit' disabled />;
Т.е. по сути один в один истории Storybook. Интересно, не будет ли конфликтов? Пока выглядит, что Playwright-сборка должна будет уметь обрабатывать и исполнять все плагины и декораторы Storybook, либо придётся как-то делить истории Storybook и истории Playwright.
Затем пишем тесты
import { test, expect } from '@playwright/test';
test('renders primary button', async ({ mount }) => {
const component = await mount('components/Button/Primary');
await expect(component.getByRole('button')).toHaveText('Submit');
});
test('disabled button is disabled', async ({ mount }) => {
const component = await mount('components/Button/Disabled');
await expect(component.getByRole('button')).toBeDisabled();
});
Затем запускаем
npx playwright test --project=components
В доке также описаны ещё основные паттерны для тестирования. На них останавливаться не буду.
Надо будет попробовать в своём пет-проекте.
https://github.com/microsoft/playwright/releases/tag/v1.62.0
#development #playwright #testing #component-testing #releaseNotes | 1 124 |
| 8 | Дайджест за 2026-08-31 - 2026-09-04
How to find a Next.js memory leak in production
Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать.
Canvas UI
Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML.
Measuring soft navigations
Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. | 871 |
| 9 | Measuring soft navigations
Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations.
Что определяется как soft navigation:
1. Действие перехода инициировал пользователь
2. Пользователь видит изменение URL
3. Есть видимое изменение (paint)
Спека пока обсуждается, поэтому могут быть изменения. На странице очень подробно описано, какие изменения будут у записей в Performance API (новые типы Entry + navigationId для идентификации метрик каждой отдельной страницы), как их включить, обрабатывать и мониторить.
Очень большой и подробный гайд. Ждём стабилизации.
https://developer.chrome.com/docs/web-platform/soft-navigations
#development #chrome #performance #web-vitals #spa #browser | 866 |
| 10 | Canvas UI
Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML.
Вместо тысячи слов лучше пройти по ссылке и посмотреть, как это выглядит. А выглядит это прям бомбически.
Также в библиотеке предусмотрено graceful degradation для браузеров, где не включен html-in-canvas, но результат может быть хуже.
https://canvasui.dev/
#development #webgl #canvas #ui #react #frontend | 982 |
| 11 | How to find a Next.js memory leak in production
Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать.
Если ваше приложение использует Next.js версии между 15.5 и 16.2, то в них есть 3 задокументированных утечки памяти. Вот как их диагностировать:
1. Если утечка медленная и коррелирует с количеством уникальных урлов, которые обслужило приложение, то это утечка Router LRU-кеша
2. Если утечка пропорциональна трафику, то вполне вероятно это утечка дерева рендеринга
3. Если утечка не плавная, а ступеньками, а запросы обрабатываются через middleware, то это утечка айдишников таймаутов
Немного подробнее про каждую утечку.
№1: У роутера в Next.js есть LRU-кеш, и его размер ограничен одним мегабайтом. Но размер определяется некорректно. Собственно сами урлы и не учитываются, что даёт возможность для утечки на сотни мегабайт. Банально любой бот, который перебирает урлы, вызовет эту утечку. Если не можете обновиться — отфильтровывайте урлы до их обработки роутером Next.js.
№2: Дерево RSC-рендера не освобождается, если клиент разорвал соединение. Утечка может достигать 2 МБ на 1 отменённый запрос (что вообще-то нехило).
№3: У middleware отдельный TimeoutsManager, который хранит id таймаутов. id отпускается только если явно вызвать clearTimeout.
А дальше интересный личный кейс автора. У него приложение крутилось как serverless на Vercel, поэтому вместо OOM он получал 504 FUNCTION_INVOCATION_TIMEOUT на tag-страницах блога.
Автор провёл расследование. Сначала подозревал рендер MDX, но оказалось, что он достаточно быстрый — до 100 мс. Оказалось, что причина в функции, которая резолвила slug для страницы. Чтобы зарезолвить один единственный slug, функция грузила и парсила все посты для каждого слага, что давало квадратичную сложность и выливалось в 18 тысяч чтений с диска и 30 секунд на рендер.
Фикс простой: вместо парсинга всех постов на каждый запрос — распарсить единожды и сложить в кеш на инстанс. Скорость работы после исправления:
- next build: ~17.5 мин → 34 сек
- prerender поста: ~32 сек → ~1.6 сек
- on-demand tag page: 504 → ~134 мс
Для поиска утечек автор собрал CLI `next-leak`, который автоматизирует диагностику.
Также отдельно отмечу, что у автора очень красиво задизайнен блог. Не знаю, готовая ли это тема или он сам собрал — но выглядит очень красиво.
https://xabierlameiro.com/blog/nextjs/nextjs-memory-leak-in-production
#development #nextjs #memory #performance #debugging | 934 |
| 12 | Дайджест за 2026-08-24 - 2026-08-28
Check out the New Node.js API Documentation Preview
Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.
When and what should I be logging?
Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм.
We Stopped Using RSC on TanStack.com
История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 773 |
| 13 | We Stopped Using RSC on TanStack.com
История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился.
Как было. Есть сайт с докой, в которой используются тяжёлые библиотеки для рендера markdown и подсветки синтаксиса. Суммарно эти библиотеки занимали 358 КБ.
Как сделали. Включили RSC, тяжёлые библиотеки остались на сервере, на клиент идёт сразу готовый рендер. И перформанс-метрики сразу подскочили. Но позже оказалось, что RSC несёт свои проблемы и неудобства.
Затем инженеры подумали, что переход на RSC — это, возможно, было неверное решение. Перенесли рендер на бэкенд вместо того, чтобы оптимизировать сами тяжёлые зависимости.
Что переделали. Взяли более лёгкие библиотеки, допилили их и вернулись на обычный SSR. Получили заметное ускорение работы + упрощение архитектуры.
Какой итог:
- RSC хорош для решения проблемы с «тяжёлым» кодом
- Но он даёт сложность. Если есть вариант обойтись без RSC — стоит рассмотреть этот вариант.
https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com
#development #react #rsc #tanstack #performance #ssr | 933 |
| 14 | When and what should I be logging?
Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм.
Итак, что надо логировать:
Runtime decisions. В коде часто есть ветвление по различным условиям — по условиям типа isMobile, по фичефлагам. Вот все эти условия нужно логировать, чтобы понимать, как работал код в каждом конкретном случае. Например, логировать конфигурацию фичетогглов.
Шаги в многошаговых фичах. Например, есть какой-то последовательный долгий процесс. В этом случае лучше логировать каждый шаг и его результат.
Аудит. Если пользователь или система делает какое-то действие, необходимо логировать, кто и что сделал. Любые создания, обновления и удаления сущностей.
Контекст вокруг ошибок. Недостаточно просто залогировать ошибку. Нужно логировать весь контекст, в котором она произошла — какой это был ретрай, какой статус-код, какой URL и всё остальное, что может помочь при дебаге.
Как писать логи:
Используй структурированные логи. Не просто строка в логах, а структура. Например, JSON-объекты. В идеале логи должны содержать ответы на вопросы «что произошло?», «кто это сделал?» и «когда это произошло?».
Наращивай контекст логов. Сначала пользователь может быть неавторизован, но когда он авторизовался — его данные (userId, например) должны попадать в контекст последующих логов. Отдельно полезно делать связь логов через трейсинг.
Что не надо логировать
Избыточное логирование. Не надо логировать вызов всех функций и всех строчек кода.
Секреты и персональные данные. Тут в целом всё понятно.
Большой объём данных без чёткой цели. Тут тоже, думаю, понятно. Хотя, если бы не было проблемы с хранением и обработкой больших данных, то думаю, этого пункта не было бы.
https://blog.sentry.io/logging-best-practices/
#development #logging #observability #sentry #best-practices | 998 |
| 15 | Check out the New Node.js API Documentation Preview
Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.
https://beta.docs.nodejs.org
#development #nodejs #documentation #dx | 880 |
| 16 | Дайджест за 2026-08-17 - 2026-08-21
postmortem.io · the library of real postmortems
postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов.
The secure way to release an npm package in 2026
Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты.
npm publish-time malware scanning and dual-use metadata
npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 881 |
| 17 | npm publish-time malware scanning and dual-use metadata
npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки.
Как это работает:
- Вы публикуете пакет
- npm сканирует его. Сканирование может идти до 15 минут для больших пакетов
- Если всё ок — пакет будет доступен для скачивания
- Если не ок — то либо будет ручное ревью, либо блокировка публикации
- В случае блокировки пришлют уведомление. В худшем случае могут потребоваться действия с аккаунтом.
https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/
#development #javascript #npm #security #supply-chain #github | 1 081 |
| 18 | The secure way to release an npm package in 2026
Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты.
В целом чеклист следует завету «не доверяй никому, кроме себя».
Чеклист:
1. Trusted Publisher: укажите конкретный воркфлоу, с которого можно только публиковать staged-версии библиотек
2. Запретить публикацию через токены
3. Включить 2FA для всех
4. Дать возможность создавать теги в GitHub только админам
5. Зафиксировать версии GitHub Actions, которые вы используете
6. Добавьте автоматический линт безопасности
7. Установите 3 дня кулдауна на новые версии зависимостей
8. Используйте npm 12 или другой пакетный менеджер, который не исполняет postinstall-скрипты
9. Создайте workflow для публикации, как в статье
Это не гарантия безопасности, но очень снижает риски того, что ваш пакет украдут.
От каких конкретно рисков защита:
1. Trusted Publisher — разрешаем публикацию только конкретному воркфлоу
2. Запрещаем публикацию напрямую (без стейджинга) и через токены. Если токен украдут — опубликовать не смогут. Сам стейджинг гарантирует ручной апрув
3. 2FA требует подтверждения через второе устройство
4. Т.к. публикация только по тегам, то разрешаем создавать теги только админам
5. Фиксация версий GitHub Actions позволяет не попасться на взлом CI Actions
6. Линт безопасности автоматически проведёт основные проверки безопасности
7. Кулдаун 3 дня на новые зависимости даёт время обнаружить malware до того, как вы его подтянете
8. Запрет postinstall-скриптов убирает целый кластер атак
9. Аккуратный publish-workflow (без лишних deps в critical job) сужает поверхность атаки при релизе
И, конечно же, в статье есть скилл для агента, который настроит всё за вас.
https://evilmartians.com/chronicles/the-secure-way-to-release-an-npm-package
#development #javascript #npm #security #ci #supply-chain #evilMartians | 1 090 |
| 19 | postmortem.io · the library of real postmortems
postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов.
https://postmortem.io/
#development #sre #devops #postmortem #reliability | 1 022 |
| 20 | Дайджест за 2026-08-10 - 2026-08-14
Announcing TypeScript 7.0
Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались.
TanStack Charts
TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков.
Investigating three real-world incidents in our cybersecurity evaluations
Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 1 054 |
