Design Language System: новая парадигма дизайна с ИИ-агентами

Новая статья: Нейросети переплюнули дизайнеров? Узнай, как искусственный интеллект творит дизайн быстрее и лучше

Читать на дизайнерс | #статья

🛠 pgsh - Инструменты PostgreSQL для локальной разработки

🌍 Сайт

Daily Coding #инструменты #SQL & Max

🧰 Monochrome Square Halftone — набор монохромным текстур

Cкачать

Dezzigners

⁣Implicit ABA в async-генераторах: тихая гонка в очередях сообщений

Работа с очередями в Node.js — дело привычное. Kafka, RabbitMQ, Redis Streams. Берёшь async-генератор, читаешь сообщения, обрабатываешь. Но implicit ABA problem в async-генераторах выстреливает в production неожиданно: yield — точка прерывания, и пока генератор приостановлен, другой воркер может изменить состояние очереди.

Где прячется проблема

Вот production-ориентированный пример:

async function* readMessages(queue) {
  let lastOffset = await queue.getLatestOffset();
  while (true) {
    const messages = await queue.poll(lastOffset);
    if (messages.length === 0) continue;
    yield messages;
    for (const msg of messages) {
      if (msg.offset >= lastOffset) {
        lastOffset = msg.offset + 1;
      }
    }
  }
}

Проблема: пока ты висел на yield, другой процесс мог удалить сообщение, сместить offset. Ты возвращаешься — работаешь с устаревшим состоянием. Это классическая implicit ABA, где "последний offset" меняется под капотом.

Как диагностировать

Логируй время до и после yield. Если пауза больше пары секунд при высокой конкурентности — это красный флаг. Используй детерминированные идентификаторы сообщений, не полагайся на offset как на истину. Смотри на время обработки: между итерациями риск ABA растёт.

Что делать

Самый прямой путь — транзакционная обработка с блокировкой:

async function* safeReader(queue) {
  while (true) {
    const result = await queue.pollWithLock();
    yield result;
    await queue.commit();
  }
}

Совет: используй снэпшоты и проверяй их свежесть на каждой итерации. Или явно проверяй поколение очереди — если оно изменилось, рвать цикл.

Ошибка

Не пытайся кэшировать offset между yield в глобальных переменных. Это усугубляет ABA, особенно в системах с несколькими воркерами и долгими HTTP-запросами. Если есть такой код в проде — скорее всего, ты уже видел странные баги, которые не воспроизводятся локально.

Вывод: Async-генераторы элегантны, но их "заморозка" между yield требует явного управления состоянием очереди, иначе гонка становится неявной и трудноуловимой.

Не могу разобраться с собой и карьерой в 2026 году. Что делать?

В 2026 году многие дизайнеры сталкиваются с неопределённостью и сложным рынком. В статье дают практические рекомендации, как разобраться в своих целях, выбрать направление и двигаться вперёд, даже когда всё кажется размытым.

Читать на дизайнерс | #Карьера

Деконструкция красоты: почему "неправильно” новое "круто"?

Узнайте у дизайнеров, почему концепция "идеального дизайна" мертва в 2026 году. Второй выпуск Rebuilding Creativity ждет вас

Читать на дизайнерс | #статья

Разработчики Eve Online опубликовали исходники движка игры.

Выложили кучу модулей, начиная с симуляции физики и графического движка, заканчивая модуля для UI, звука и сетки.

И всё по MIT-лицензии. Т.е. можно спокойно и в коммерческих целях использовать.

🛠 MenuSpy позволяет отслеживать, какой раздел веб-страницы виден, и отображать это в навигационном меню. В нем нет никаких настроек оформления, только JavaScript API для добавления / удаления классов. Однако есть пара интересных демонстраций, которые вы можете скопировать.

🌍 Сайт

Daily Coding #инструменты #JavaScript & Max

⁣Deadlock из-за AbortSignal.timeout в middleware: как не убить свой сервер

Использование AbortSignal.timeout с Promise.race в цепочках middleware кажется простым способом ограничить время выполнения запроса. Однако на практике это приводит к молчаливым зависаниям, которые не ловятся даже unhandledRejection, а сервер начинает накапливать незавершённые запросы.

Симптомы проблемы
Запрос висит ровно timeout секунд, после чего падает с TimeoutError. Middleware не перехватывает ошибку — она улетает в catch верхнего уровня или теряется вовсе. Процесс не падает, но следующие запросы блокируются из-за незакрытых ресурсов.

Пример проблемного кода

app.use(async (req, res, next) => {
  const controller = new AbortController();
  const timeoutSignal = AbortSignal.timeout(3000);
  const result = await Promise.race([
    someAsyncTask(req, { signal: controller.signal }),
    timeoutSignal
  ]);
  next(); // deadlock: never called
});

Здесь AbortSignal.timeout(3000) создаёт независимый сигнал. Promise.race завершается, когда один из промисов срабатывает, но не передаёт отмену вашему controller. Дочерние задачи продолжают висеть, а middleware не вызывает next(), блокируя цепочку.

Правильное решение: единый сигнал
Используйте AbortSignal через req.signal и таймаут на уровне роутера:

app.use(async (req, res, next) => {
  const controller = new AbortController();
  res.on('close', () => controller.abort());
  req.signal = controller.signal;
  next();
});

app.use(async (req, res, next) => {
  const timeout = setTimeout(() => {
    req.signal.abort();
    res.status(408).send('timeout');
  }, 3000);
  res.on('finish', () => clearTimeout(timeout));
  next();
});

Диагностика в продакшене:
- Используйте async_hooks или cls-hooked для трейсинга запросов.
- Добавьте логирование в каждый middleware через console.time.
- Проверяйте открытые соединения через db.$pool.waitingClients.

Вывод: AbortSignal.timeout должен быть частью контракта middleware, а не хаотично переброшен в Promise.race, иначе deadlock обеспечен.

Индустриальные новости

Делаю для себя LLM-wiki проекта Цифровой геноцид: в каком-то смысле это замена RAG, но помню, еще лет 10 назад, когда читал теории системной инженерии Анатолия Левенчука думал, что хорошей и правильной практикой создания внешнего, "рукотворного" мозга может быть блог.

Насколько могу судить по развитию современных новых медиа, то теперь подобного рода проекты маркируются под брендом "digital garden", что любителя "Сада расходящихся тропок" Борхеса может быть ироничной отсылкой. С середины 2010‑х digital garden начинают описывать как публичную персональную вики/PKM, где заметки открыты, межсвязаны и постоянно перерабатываются, например, вот тут история, хотя любитель широких исторических аналогий управления знаний увидит прототип в Commonplace book Джона Локка.

Сама по себе идея в целом повторяет практики менеджеров знаний - в молодости я так в шутку использовал Протеже, который предлагал связывать в базе знаний каждую сущность с другой в формате XML
https://syg.ma/@vitaliy-bolataev/ontoinzhienieriia-na-sluzhbie-filologhii-kak-sozdavat-ontologhii-litieraturnykh-proizviedienii?ysclid=ma0zkbfdlu6159277

Собственно, LLM-wiki Карпатого - это паттерн работы с ИИ, в котором сама LLM по сырому корпусу данных постепенно строит и поддерживает живую вики-базу знаний (Markdown‑страницы, перелинковкой и индексами), если обычный RAG завязан на машиночитаемости(ну не прочтешь ты чанки), то это более человекочитаемый инструмент https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Знаниевые графы и правда переживают второе рождение