#полезное
🛞 AI-генератор бесконечных карт

Nano Banana Infinimap — экспериментальный генератор карт, использующий ИИ для создания бесшовных тайлов. Проект демонстрирует возможности модели Nano Banana, позволяя генерировать огромные карты с учетом соседних тайлов.

Основные моменты:
🔵 Бесконечные карты с навигацией на базе Leaflet
🔵 Генерация тайлов с использованием модели Google Nano Banana
🔵 Учет соседних тайлов для плавных краев
🔵 Локальное хранение данных

GitHub: https://github.com/seezatnap/nano-banana-infinimap

👉Новости 👉База вопросов

#полезное
😊 Чистая архитектура фронтенд-приложений

Чистая архитектура фронтенд-приложений — это подход к организации кода, чтобы приложение было простым в поддержке, тестировании и масштабировании. Его цель — разделить логику приложения на слои, чтобы изменения в одном слое минимально влияли на другие. Продолжаем делиться циклом статей, где автор дает советы по организации чистой архитектуры.
Читать статью

👉Новости 👉База вопросов

#Собес #git
🤔 Как вы разрешаете конфликты в Git?

💬 Кратко:
Конфликты возникают, когда изменения из удаленного и локального репозиториев пересекаются. Чтобы разрешить конфликт, нужно вручную отредактировать проблемные файлы, выбрать правильную версию, а затем зафиксировать изменения.

📌 Полный разбор + примеры использования — на платформе:
👉 Перейти к разбору

📣 Хочешь получать больше таких разборов?
Подпишись на наш главный канал

#полезное
😴 Window Mode: Погружение в 3D мир через веб-камеру

Window Mode — это демонстрация 3D-камерного контроллера, который создает иллюзию окна в виртуальный мир. С помощью отслеживания положения лица пользователя, проектируется 3D-сцена, создавая эффект присутствия. Работает с любыми 3D-видео и не требует специального оборудования.

Основные моменты:
🟠 Эмуляция окна в 3D пространстве.
🟠 Использует MediaPipe для отслеживания лица.
🟠 Поддержка форматов .vv и .splv для 3D-сцен.
🟠 Реализация на NextJS с использованием веб-воркеров.
🟠 Ожидается открытие исходников библиотек.

GitHub: https://github.com/True3DLabs/WindowMode

👉Новости 👉База вопросов

Что такое DLQ в микросервисах 🙃

Dead Letter Queue — это “очередь для неудачных сообщений”
Когда микросервис не может обработать сообщение после нескольких попыток, оно не удаляется и не крутится бесконечно, а попадает в DLQ

😐 Зачем это нужно
— чтобы не блокировать основную очередь
— чтобы можно было позже разобраться, почему сообщение не обработалось
— чтобы при необходимости повторно отправить сообщение вручную или автоматически

📦 Пример
Допустим, у тебя есть очередь orders, и воркер обрабатывает заказы.
Если из-за ошибки воркер несколько раз подряд не смог обработать заказ, сообщение попадёт в orders.DLQ.
Туда можно подключить отдельный обработчик или просто просматривать ошибки

Еще советую добавить Alert на метрику, когда сообщений в очереди больше одного 😇

🚀 Пост Guru Node.js: @DemetraIT

🐱 DataLoader и проблема N+1

Когда ты делаешь запрос на список сущностей, а для каждой из них внутри цикла идёт ещё один запрос — поздравляю, ты поймал N+1 проблему

Например:

const users = await db.query('SELECT * FROM users');
for (const user of users) {
user.posts = await db.query('SELECT * FROM posts WHERE user_id = $1', [user.id]);
}

Результат — один запрос на юзеров и N запросов на посты. На 100 юзеров это уже 101 запрос.
Больно для БД 😱😱😱

⚙️ Решения:
1) JOIN — часто помогает, если нужно просто склеить данные
2) IN-запрос — SELECT * FROM posts WHERE user_id IN (...)
3) DataLoader — если у тебя GraphQL или сложные вложенные запросы

🧠 Как работает DataLoader
DataLoader — это умный батчер и кэшер от Facebook

Он не делает магии, а просто:
1) Копит ключи (например, userId), по которым нужно загрузить данные
2) Выполняет один общий запрос, вроде:

SELECT * FROM posts WHERE user_id IN (1,2,3,...)

3) Раскладывает результат обратно по пользователям

Почитать подробнее можно тут

🚀 Пост Guru Node.js: @DemetraIT

😐 Уровни изоляции транзакций и аномалии

Когда несколько транзакций работают одновременно, они могут мешать друг другу и создавать странные эффекты — аномалии.
Чтобы держать порядок, базы данных вводят уровни изоляции — насколько сильно транзакции изолированы друг от друга.

⸻

⚠️ Типичные аномалии

— Dirty Read (грязное чтение) — читаешь данные, которые ещё не закоммичены.
Если транзакция откатится — ты прочитал “призрак”.

— Non-repeatable Read (неповторяемое чтение) — читаешь одну и ту же строку дважды, а результат разный, потому что другая транзакция изменила её между запросами.

— Phantom Read (фантомное чтение) — при повторном запросе появляются новые строки, подходящие под условие, которых раньше не было.

⸻

🔒 Уровни изоляции
1) READ UNCOMMITTED — можно читать даже незакоммиченные данные. Самый быстрый и самый опасный.

2) READ COMMITTED — читаешь только закоммиченные данные.
Нет грязных чтений, но возможны неповторяемые и фантомные.
(По умолчанию в PostgreSQL)

3) REPEATABLE READ — при повторном чтении данные не меняются.
Нет грязных и неповторяемых чтений, но фантомы возможны.

4) SERIALIZABLE — максимальная изоляция, всё выглядит как последовательное выполнение. Полностью без аномалий, но возможны откаты при конфликтах

💡 Чем выше уровень изоляции — тем меньше аномалий, но ниже производительность

🚀 Пост Guru Node.js: @DemetraIT

😳 Почему Query Builder лучше, чем ORM

ORM — звучит красиво: пишешь классы, аннотации, а база сама как-то живёт. Но на практике — это как ездить закрытыми глазами на машине на автопилоте

🐗 1. Query Builder делает ровно то, что ты просишь

Query Builder — это тонкая обёртка над SQL.
Ты чётко контролируешь какой запрос пойдёт в базу, какие JOIN’ы выполняются и какие поля читаются.
Он не “угадывает”, что ты хотел сделать — он просто выполняет твой запрос

С Query Builder:

await db('users')
.select('id', 'email')
.where('is_active', true);

SQL под капотом — предсказуемый:

SELECT id, email FROM users WHERE is_active = true;

А ORM может внезапно решить “загрузить” связи, добавить лишние поля или сделать 3 подзапроса вместо одного.
Ты думаешь, что сделал findOne, а реально — отправил 5 SQL-запросов

🍆 2. Работа с данными — это высокие риски

База данных — сердце системы.
Если ты не понимаешь, какой SQL реально выполняется, ты не контролируешь производительность и целостность данных

ORM часто скрывает логику за “удобным” API, но любая сложная операция превращается в дебри.
Query Builder же заставляет мыслить на уровне SQL, а не на уровне магии “entities” и “relations”


🙂 3. Меньше магии — меньше проблем

TypeORM, Sequelize, Prisma — все они в какой-то момент начинают диктовать свои правила.
Тебе нужно не просто “сделать запрос”, а ещё угадать, как ORM это интерпретирует
• Миграции — можно и нужно писать руками. Так надёжнее
• Сущности (Entity) в TypeORM — часто мешают, особенно когда структура БД не совпадает 1:1 с моделями кода
• При изменениях в схеме ORM может внезапно удалить или пересоздать таблицу, если ты где-то забыл флаг


😱 4. Иногда ORM тоже нормик

ORM удобно, пока проект маленький и нужно собрать быструю гипотезу на коленке


🚀 Пост Guru Node.js: @DemetraIT