Если не хватает свежей насмотренности, загляните в Recent.

Каждый день сервис публикует новую подборку лучшего дизайна со всего интернета.

recent.design

Сайт-портфолио дизайнера Felipe Elioenay выделяется среди других за счет яркой цветовой палитры и пролистывания экранов, как карточек. По структуре все достаточно просто. Нет кнопки "вверх", но есть большой ярковыраженный переход на главную, так что не потеряешься. В целом все контрастно, ярко и по делу.

Сайт тут

🛠 История активных сессий для Postgres — облегченная выборка событий ожидания без раздувания.

🌍 Сайт

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

⁣Неявный pinning в V8: как скрытые ссылки в прототипах и замыканиях мешают GC собирать мусор в production

Замечали, как Node.js внезапно начинает жрать память, хотя все объекты вроде уже не нужны? Чаще всего проблема в неявном pinning — GC просто не видит, что объекты можно собирать, из-за скрытых ссылок, живых прототипов и замыканий, которые V8 ошибочно считает нужными.

Прототипы и скрытые классы
У каждого объекта в V8 есть скрытый класс (HiddenClass) и ссылка на прототип. Пока жив экземпляр, весь прототип со всеми методами и данными остаётся в памяти. Это особенно критично для утечек через кеши:

function Data(id) {
  this.id = id;
  this.buffer = new ArrayBuffer(100);
}
const obj = new Data(1);
// Если obj утёк через замыкание — Data.prototype не соберётся GC

Замыкания и живые контексты
V8 оптимизирует замыкания, но ошибается: если внутри замыкания объявлена большая переменная, а используется только часть контекста, GC всё равно держит всю аллокацию:

function createProcessor() {
  const hugeData = new ArrayBuffer(500); // утечка
  return {
    process: () => console.log('ok'),
    release: () => {}
  };
}
// Пока жив processor, hugeData не соберётся

Неявные ссылки через WeakMap и Symbol.species
Слабая карта не гарантирует сборку — если ключ жив, значение тоже живёт. Symbol.species в подклассах может создать неявную ссылку на конструктор, удерживая целый прототип. Типичная ошибка — использовать Map для кеша, когда нужно WeakMap.

Что делать в production:
* Для кеширования используй WeakMap, а не Map — это единственный безопасный способ.
* В замыканиях явно зануляй большие объекты: hugeData = null после создания.
* Снимай heap snapshots через node --inspect или Chrome DevTools — ищи пачки объектов с одинаковым прототипом.
* После создания массива экземпляров можно занулить Constructor.prototype.constructor = null — это ломает ссылку на конструктор, но рискованно.

Вывод:
Одна невидимая ссылка через прототип или замыкание может закрепить сотни мегабайт в куче — используй WeakMap, явное зануление и профилирование, чтобы production не упал по памяти.

🧰 Origin Coffee Mockup — набор из 7 качественных мокапов, с помощью которых вы можете презентовать дизайн кофейного бренда

Cкачать

Dezzigners

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). Люди конструировали свои ментальные симуляции примерно так же, как строится машина: «Вот начальный пункт. Затем это толкает здесь, поэтому это вот меняется, а потом происходит еще одна вещь, и вы оказываетесь здесь». Примерно так же проектируются часы или мышеловка.

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

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

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

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