Day 474:
SLAPS An independent creative company.
→ brandingthatslaps.com

Workflow The simplest way to manage creative work.
→ workflow.design

More on
→ curated.design

🛠 Devices.css - библиотека, в которой представлены современные мобильные устройства, созданные с использованием чистого CSS. В нее входят некоторые из самых популярных мобильных устройств, таких как iPhone X, Google Pixel 2 XL и Samsung Galaxy S8. Дизайн отличается элегантностью и высоким качеством и может быть использован для создания целевых страниц или скриншотов.

🌍 Сайт

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

⁣Atomics.wait заблокировал event loop — как не убить Node.js в production

Общая память через SharedArrayBuffer даёт мощную межпоточную синхронизацию, но некорректное использование Atomics.wait в worker_threads способно полностью парализовать приложение. Частая ошибка: разработчики забывают, что Atomics.wait — синхронный блокирующий вызов, который останавливает весь поток, включая event loop.

Как блокировка ломает Event Loop
Когда worker вызывает Atomics.wait(buf, 0, 0), он зависает, пока другой поток не изменит значение. В main thread такой вызов выбрасывает TypeError, но внутри worker это законно. Поток перестаёт обрабатывать сообщения и таймеры — worker становится мёртвым.

Production-сценарий: дедлок коммуникации
Часто main thread посылает worker задачу и ждёт ответа через postMessage. Если worker перед этим вызвал Atomics.wait и заблокировался — ответ никогда не придёт. Приложение зависает без краша или явной ошибки.

// worker.js
const { parentPort, workerData } = require('worker_threads');
const sab = new SharedArrayBuffer(4);
const view = new Int32Array(sab);
Atomics.wait(view, 0, 0); // Worker hangs forever
parentPort.postMessage('done'); // Never reached

Типичная ошибка: забыть про альтернативы
Многие пишут Atomics.wait без таймаута или не проверяют, что воркеры уже заняты. Всегда указывайте значение таймаута: Atomics.wait(buf, 0, 0, 1000) — хотя бы не бесконечное ожидание.

Практический совет: Atomics.waitAsync или изоляция
Используйте экспериментальный Atomics.waitAsync() для неблокирующего ожидания. Либо выносите всю логику блокирующих вызовов в отдельные воркеры, которые общаются только через Atomics.store и Atomics.load без синхронных ожиданий.

Вывод:
Atomics.wait в worker_threads может полностью убить event loop, если не контролировать время блокировки или связь с main thread.

Натуралистическое принятие решений: ментальная стимуляция
Отрывки из "Источники силы. Как люди принимают решения"

Во время посещения Национальной пожарной академии мы встретились с одним из старших разработчиков учебных программ. На встрече он вдруг встал, подошел к двери и закрыл ее. Потом сказал шепотом: «Чтобы стать хорошим руководителем тушения пожара, у вас должна быть богатая фантазия».
Он имел в виду способность применять воображение, представлять себе, как пожар начался, как будет распространяться и что случится при использовании какой-то новой процедуры. Руководителю тушения пожара, который не способен вообразить все это, будет сложно.

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

Мы обнаружили это в проведенных еще в 1946 году Адрианом де Гроотом исследованиях ментальной симуляции у гроссмейстеров. Два исследователя решений, Канеман и Тверски (Kahneman and Tversky, 1982), написали статью о симуляционной эвристике, основанную на лабораторных данных. Они описали, как испытуемый может создавать симуляцию для объяснения того, как нечто могло бы произойти; если симуляция требует слишком много невероятных событий, он может прийти к выводу, что она неправдоподобна.
Получив финансирование от Армейского исследовательского института, я вместе с Бет провел поисковое исследование ментальной симуляции, чтобы побольше узнать о ее природе. У нас была идея собрать и изучить несколько случаев, чтобы понять, существуют ли какие-то закономерности.
Рассматриваемые случаи по большей части были взяты из наших собственных записей (например, случай со спасательной привязью, спасательная операция при автокатастрофе), также мы включили истории из других источников, такие как инцидент с ливийским авиалайнером или примеры из книги Чарльза Перроу «Нормальные аварии» (Perrow, 1984), в которой приводятся подробные сведения по ряду катастроф и аварий. Кроме того, мы провели ряд неформальных интервью, а также попросили людей из нашей компании поискать подобные примеры.
После сбора всех случаев мы изучили их на предмет общих черт и отличий. Затем мы попытались кодифицировать их по таким качествам, как дефицит времени, опытность участников, использование визуальных или невизуальных симуляций и т. д. Мы отбросили около 20% случаев, поскольку в них описание не вполне ясно показывало, использовалась ли вообще ментальная симуляция. Мы можем себе представить, как человек мог использовать ментальную симуляцию, но, когда приходилось просто догадываться, мы не были уверены, что именно мы исследуем — фантазии человека или наши собственные.
В итоге у нас осталось семьдесят девять случаев. Эти случаи продемонстрировали наличие одних и тех же паттернов (Klein and Crandall, 1995). Люди конструировали свои ментальные симуляции примерно так же, как строится машина: «Вот начальный пункт. Затем это толкает здесь, поэтому это вот меняется, а потом происходит еще одна вещь, и вы оказываетесь здесь». Примерно так же проектируются часы или мышеловка.

В случае спасения с перехода при помощи спасательной привязи руководитель тушения пожара представил себе, как они спустят вниз ремень для лестницы, а потом поднимут женщину на один дюйм, заведут ремень под нее, пристегнут его и поднимут наверх. В случае спасения из автомобиля командир вообразил, как они снимут крышу, заберутся в автомобиль, зафиксируют шею мужчины, высвободят его из-за рулевой колонки, схватят его за руки и ноги, а потом потихоньку вытащат из машины.
Мы заметили еще кое-что: не все ментальные симуляции были достаточно проработанными. Каждая опиралась, похоже, лишь на несколько факторов и редко более чем на три. Это похоже на проектирование машины, у которой только три движущиеся части. Возможно, следовало учесть ограничения нашей оперативной памяти.

Была и еще одна закономерность: ментальные симуляции, похоже, разыгрывались примерно на шесть переходных состояний, обычно ненамного больше. Возможно, это также было результатом ограниченной оперативной памяти. Если вы не можете отслеживать бесконечные переходы, лучше сделать так, чтобы ментальная симуляция завершалась примерно за шесть шагов.

Таково «требование по комплектации» при построении ментальной симуляции: максимум три движущиеся части. Проектная спецификация: ментальная симуляция должна выполнять свою работу за шесть шагов. Это ограничения, которые мы соблюдаем при построении ментальных симуляций для решения проблем и принятия решений. То есть нам нужно собрать симуляцию в рамках этих ограничений.

Принцип ментальной симуляции - схема

Иллюстрации Tim Lahan