Forwarded from Daily Coding 🔥
🛠 Buefy - легкий фреймворк UI для Vue.js построен с использованием популярного элемента на основе CSS библиотека Бульма. В ней есть все составляющие типичного веб-приложения должен в том числе динамические элементы, как модели, тосты и уведомления, что позволяет разработчикам быстро добавлять элементы пользовательского интерфейса в своих проектах Vue.js .
🌍 Сайт
Daily Coding #инструменты #Vue & Max
🌍 Сайт
Daily Coding #инструменты #Vue & Max
Forwarded from Node.JS [ru] | Серверный JavaScript
Diagnostics Channel: Загляни внутрь Node.js в production без console.log и перезаливок
Когда приложение падает в production, а логи пусты - начинается классика: залипаешь в терминал с
Что за зверь?
Модуль
Где выстрелит?
- Утечки HTTP-соединений - канал
- HTTP/2 сессии и их жизненный цикл
- Работа DNS-резолвера
- Создание и завершение Worker Threads
- Зависания событийного цикла - канал
Пример: ловим утечки HTTP-соединений
Кладёшь этот код в
Как тащить в production?
- Условный require:
- Или динамически подключай по
- Только помни: подписка - синхронная операция. Не делай внутри тяжёлых вычислений или блокирующих I/O, иначе забьёшь event loop и ухудшишь производительность
Вывод:
Diagnostics Channel позволяет заглянуть внутрь Node.js в реальном времени под нагрузкой, чтобы поймать утечки и задержки до того, как они уронят production, причём без единой правки кода приложения.
Когда приложение падает в production, а логи пусты - начинается классика: залипаешь в терминал с
console.log, комментируешь половину кода и перезаливаешь. Но у Node.js есть встроенный механизм для подписки на внутренние события движка и модулей без правки исходников. Называется diagnostics_channel.Что за зверь?
Модуль
diagnostics_channel даёт каналы, именуемые по схеме модуль.событие.подсобытие. Через них V8, libuv и сам Node.js эмитят структурированные данные о внутренних операциях. Подписаться можно без правки кода приложения - просто инициализируешь слушателя в отдельном файле и подключаешь через флаг --require.Где выстрелит?
- Утечки HTTP-соединений - канал
http.client.request.create- HTTP/2 сессии и их жизненный цикл
- Работа DNS-резолвера
dns- Создание и завершение Worker Threads
- Зависания событийного цикла - канал
tickПример: ловим утечки HTTP-соединений
const diagnosticsChannel = require('diagnostics_channel');
const clientRequestChannel = diagnosticsChannel.channel('http.client.request.create');
clientRequestChannel.subscribe(({ request, socket }) => {
const startTime = Date.now();
request.on('response', (res) => {
console.log(Request to ${request.hostname} completed (${Date.now() - startTime}ms));
});
socket.on('close', () => {
if (Date.now() - startTime > 5000) {
console.warn(Long-lived socket detected: ${socket.remotePort});
}
});
});Кладёшь этот код в
diagnostics.js, запускаешь с флагом node --require ./diagnostics.js app.js - и никаких изменений в исходниках приложения.Как тащить в production?
- Условный require:
NODE_DEBUG_DIAGNOSTICS=1 node app.js с проверкой в коде- Или динамически подключай по
process.env при старте, чтобы не плодить лишние подписки- Только помни: подписка - синхронная операция. Не делай внутри тяжёлых вычислений или блокирующих I/O, иначе забьёшь event loop и ухудшишь производительность
Вывод:
Diagnostics Channel позволяет заглянуть внутрь Node.js в реальном времени под нагрузкой, чтобы поймать утечки и задержки до того, как они уронят production, причём без единой правки кода приложения.
Forwarded from PSD | Дизайн-пространство
Media is too big
VIEW IN TELEGRAM
Vector Archects - Corporate webse
https://.com/shots/22571057-Vector-Archects-Corporate-webse
https://.com/shots/22571057-Vector-Archects-Corporate-webse
Forwarded from ai.dot(ufna, dev)
А это вы видели? Загружаем модельку вам прямо в браузер!
https://huggingface.co/spaces/webml-community/gemma-4-webgpu-kernels
https://huggingface.co/spaces/webml-community/gemma-4-webgpu-kernels
Forwarded from Daily Coding 🔥
Погрузитесь в ИТ за 5 дней и получите доступ к высокооплачиваемым вакансиям!
Бесплатный короткий курс для тех, кто хочет не просто понять, чем занимаются айтишники, но и получить реальный опыт работы с ИТ‑системами.
Всего за 5 дней вы освоите ключевые компоненты ИТ‑сферы, разберёте 6 профессий и получите возможность выйти на зарплату 150–250 тыс.
Курс полностью практический. 8 мини‑проектов с реальными задачами, где вы научитесь: писать код, работать с инфраструктурой, разбираться в сетях, облаке и защите данных.
Подойдёт новичкам и тем, кто уже в ИТ. Количество мест ограничено — регистрируйтесь по ссылке и начинайте практику.
Реклама. Информация о рекламодателе по ссылкам в посте.
Бесплатный короткий курс для тех, кто хочет не просто понять, чем занимаются айтишники, но и получить реальный опыт работы с ИТ‑системами.
Всего за 5 дней вы освоите ключевые компоненты ИТ‑сферы, разберёте 6 профессий и получите возможность выйти на зарплату 150–250 тыс.
Курс полностью практический. 8 мини‑проектов с реальными задачами, где вы научитесь: писать код, работать с инфраструктурой, разбираться в сетях, облаке и защите данных.
Подойдёт новичкам и тем, кто уже в ИТ. Количество мест ограничено — регистрируйтесь по ссылке и начинайте практику.
Реклама. Информация о рекламодателе по ссылкам в посте.
Forwarded from Daily Coding 🔥
📖Collaborative Software Design
🖋Baas-Schwegler Kenny, Van Kelle Evelyn, Verschatse Gien 2025
В книге «Совместное проектирование программного обеспечения» вы познакомитесь с принципами, методами и инструментами, способствующими безопасному общению при выявлении бизнес-проблем, формализации требований и реализации программного проекта. В ней рассказывается о таких признанных инструментах совместного моделирования, как «штурм событий», «составление примеров», «составление карт Уордли» и «сторителлинг предметной области», а также о уникальных подходах к управлению когнитивными искажениями, конфликтами и организационной иерархией. Независимо от того, являетесь ли вы заинтересованной стороной в бизнесе, техническим специалистом или профессиональным координатором, вы научитесь слышать всех участников процесса и извлекать пользу из их вклада.
💾 Скачать книгу
Daily Coding #книги #архитектура & Max
🖋Baas-Schwegler Kenny, Van Kelle Evelyn, Verschatse Gien 2025
В книге «Совместное проектирование программного обеспечения» вы познакомитесь с принципами, методами и инструментами, способствующими безопасному общению при выявлении бизнес-проблем, формализации требований и реализации программного проекта. В ней рассказывается о таких признанных инструментах совместного моделирования, как «штурм событий», «составление примеров», «составление карт Уордли» и «сторителлинг предметной области», а также о уникальных подходах к управлению когнитивными искажениями, конфликтами и организационной иерархией. Независимо от того, являетесь ли вы заинтересованной стороной в бизнесе, техническим специалистом или профессиональным координатором, вы научитесь слышать всех участников процесса и извлекать пользу из их вклада.
💾 Скачать книгу
Daily Coding #книги #архитектура & Max
Forwarded from Node.JS [ru] | Серверный JavaScript
Event Loop Lag при тысячах setTimeout: как очередь таймеров убивает latency в production
Когда на сервере больше 1000 активных setTimeout или setInterval, latency неожиданно растет, I/O начинает тормозить, а пользователи жалуются на задержки. Многие разработчики считают, что таймеры безвредны, но на практике их перебор в одной фазе event loop блокирует весь tick.
Всё упирается в фазы цикла событий:
- timers — коллбеки от setTimeout и setInterval
- pending callbacks — I/O ошибки
- idle, prepare — внутренняя кухня libuv
- poll — новые I/O события
- check — очередь setImmediate
- close callbacks — закрытие соединений
Проблема: когда у вас 10 000 активных setTimeout, фаза timers отрабатывает десятки миллисекунд. Всё остальное стоит в очереди. I/O, новые запросы, ответы — всё ждёт, пока переберутся таймеры.
Реальный случай из практики
Был сервис с heartbeats для клиентов. Каждый клиент держал рекурсивный setTimeout:
Для 5000 клиентов каждый tick на фазе timers прогонял до 5000 коллбеков. Попутно лагали все остальные запросы — пользователи чувствовали задержки, мониторинг показывал event loop lag > 100ms.
Что с этим делать?
Во-первых, отлаживать. Берём профайлер Node.js:
Смотрим лог — находим, сколько времени уходит на фазу timers. Часто это открытие.
Во-вторых, оптимизировать.
- Ограничьте количество активных таймеров. Сгруппируйте несколько heartbeat-задач в один setInterval.
- Там, где возможна замена, используйте setImmediate. Он живёт на фазе check — не блокирует poll и timers.
- Мониторьте event loop lag через
Можно ещё раскидать тяжёлые таймерные задачи по worker_threads — чтобы они не тормозили главный поток.
Вывод:
Большое количество таймеров — тихий убийца производительности, который часто замечают слишком поздно, но своевременный профилинг и рефакторинг очередей могут снизить latency в разы.
Когда на сервере больше 1000 активных setTimeout или setInterval, latency неожиданно растет, I/O начинает тормозить, а пользователи жалуются на задержки. Многие разработчики считают, что таймеры безвредны, но на практике их перебор в одной фазе event loop блокирует весь tick.
Всё упирается в фазы цикла событий:
- timers — коллбеки от setTimeout и setInterval
- pending callbacks — I/O ошибки
- idle, prepare — внутренняя кухня libuv
- poll — новые I/O события
- check — очередь setImmediate
- close callbacks — закрытие соединений
Проблема: когда у вас 10 000 активных setTimeout, фаза timers отрабатывает десятки миллисекунд. Всё остальное стоит в очереди. I/O, новые запросы, ответы — всё ждёт, пока переберутся таймеры.
Реальный случай из практики
Был сервис с heartbeats для клиентов. Каждый клиент держал рекурсивный setTimeout:
function heartBeat(clientId) {
setTimeout(() => {
// Тяжёлая операция с БД + проверка состояния
heartBeat(clientId);
}, 1000);
}Для 5000 клиентов каждый tick на фазе timers прогонял до 5000 коллбеков. Попутно лагали все остальные запросы — пользователи чувствовали задержки, мониторинг показывал event loop lag > 100ms.
Что с этим делать?
Во-первых, отлаживать. Берём профайлер Node.js:
node --prof app.js
Смотрим лог — находим, сколько времени уходит на фазу timers. Часто это открытие.
Во-вторых, оптимизировать.
- Ограничьте количество активных таймеров. Сгруппируйте несколько heartbeat-задач в один setInterval.
- Там, где возможна замена, используйте setImmediate. Он живёт на фазе check — не блокирует poll и timers.
- Мониторьте event loop lag через
process.hrtime или модуль event-loop-stats. Если lag > 50ms — это звоночек.Можно ещё раскидать тяжёлые таймерные задачи по worker_threads — чтобы они не тормозили главный поток.
Вывод:
Большое количество таймеров — тихий убийца производительности, который часто замечают слишком поздно, но своевременный профилинг и рефакторинг очередей могут снизить latency в разы.
Forwarded from Dezzigners
🧰 Isometric Scene Creator — большой набор (почти 50ГБ) высококачественных мокапов для Photoshop, с помощью которых вы сможете презентовать свой дизайн заказчику или в портфолио
Скачать
Dezzigners
Скачать
Dezzigners