Рубрика странные визуализации

Диаграмма, показывающая, как выглядели бы различные лунные затмения при Землях разной формы. Иоганнес Буно, ок. 1711.

Знаменитая гравюра немецкого теолога и педагога Иоганна Буно , опубликованная около 1711 года в книге "Универсальная география"

На гравюре показано, как выглядела бы тень, отбрасываемая Землей на Луну во время затмения, если бы наша планета имела другую форму:

Ряд 1 (Шарообразная Земля): Реальная ситуация. Круглая Земля отбрасывает круглую тень, что мы и видим на Луне.
Ряд 2 (Треугольная Земля): Если бы Земля была трехгранной пирамидой или треугольником, то на Луну проецировалась бы угловатая треугольная тень.
Ряд 3 (Ромбовидная Земля): Земля в форме ромба или куба оставляла бы на лунном диске ромбовидный след.
Ряд 4 (Шестиугольная Земля): Планета в форме гексагона проецировала бы на Луну четкую шестиугольную тень.

https://commons.wikimedia.org/wiki/File:Four_diagrams_of_Solar_eclipses_(1711)_by_Johannes_Buno._Original_from_Library_of_Congress._Digitally_enhanced_by_rawpixel._(50623610866).jpg

Центры HCI в мире - давно не было рубрики. Сегодня про духовность и HCI

Коллектив центра SPIRITED состоит из исследователей и учёных из самых разных областей, которых объединяет глубокий — как академический, так и личный — интерес к вопросам и проблемам на стыке религии, духовности, дизайна и интерактивных технологий.
https://spiritedhci.org/

Главная цель коллектива — собрать в одном пространстве различных участников: исследователей и дизайнеров HCI, специалистов по религиозным исследованиям, теологов и практикующих, — и установить долгосрочные, устойчивые и трансдисциплинарные отношения.

Что изучают на стыке духовности и проектирования?
Из интересного - внезапно византийские исследования технологий в стиле иеротопии Алексея Лидова, которая изучает сакральные пространства и создание сакральных мест: при помощи ряда технологий и интерфейсов концепции обретают новый смысл. Предлагается создавать ТЕХНОЧАСОВНИ (почти в стиле вархаммера)
Дадим слово авторам идеи:

Техно-часовня Малой Части (T-CLP) вдохновлена Часовней Малой Части, расположенной в святилище Джейн Блаффер Оуэн в Нью-Хармони, штат Индиана, США . Часовня Малой Части — это небольшая часовня, которая в основном используется посетителями святилища для тихой индивидуальной молитвы и медитации. Она была вдохновлена и призвана напоминать посетителям церковь Санта-Мария-дельи-Анджели в Порциункуле — маленькую церковь (примерно 18 × 10,5 футов), которую в 1209 году перестроил святой Франциск Ассизский
https://dl.acm.org/doi/10.1145/3689050.3704954

T-CLP задумана как отдельно стоящее кубическое сооружение с внутренними размерами 12' × 12' × 12' (примерно 3,66 × 3,66 × 3,66 м), состоящее из одного помещения. Здание построено из крупных камней местного карьера, чтобы гармонично вписаться в окружающую застройку Нью-Хармони. Внешний вид лишён украшений — это воспроизводит минималистичную эстетику оригинальной Часовни Малой Части (и Порциункулы до позднейших художественных дополнений фасада) и отражает преобладающую в современной сакральной архитектуре тенденцию к аскетизму
https://robertleeblafferfoundation.org/walking-map-of-blaffer-sanctuary/chapel-of-the-little-portion-attraction/

Вход в пространство осуществляется через простую деревянную дверь с системой доступа через сенсорную панель. При касании панели на ней появляется изображение креста, который посетитель должен обвести пальцем в качестве пароля. После этого дверь открывается с тихим щелчком.
Войдя внутрь, посетитель видит гладкий каменный пол, четыре небольшие (3 фута длиной) передвижные скамьи, простой каменный алтарь (4' высотой × 2' шириной × 2' глубиной) у дальней стены, в котором скрыты процессор и другие системы, необходимые для интерактивных компонентов, а также небольшую чувствительную к давлению коврик для коленопреклонения перед алтарём, также подключённый к системе. Всё пространство освещается белой светодиодной линейной врезной подсветкой (3 дюйма), расположенной в 1 футе от потолка и подключённой к панели управления.
https://dl.acm.org/doi/10.1145/3689050.3704954

Не менее интересно и направление разработок религиозной утвари!
Прототипирование еврейских ритуальных предметов: носимые возможности для намерения и связи
Вместо филакте́рии - пара коробочек из выкрашенной чёрной краской кожи кошерных животных - предлагается - гаджет с с радиоприемником, динамиком и тфилином в разобранном виде.
https://dl.acm.org/doi/epdf/10.1145/3686169.3686193

Отдельным способом работы являются гаджеты для медитаций для удаленки - куда же без них: буддийские ритуальные предметы с умной колонкой https://dl.acm.org/doi/epdf/10.1145/3689050.3704422 Работает он так: это сферический осязаемый интерактивный объект, разработанный специально для буддийской общины (в частности, практикующих Nichiren Buddhism — повторение мантры «Namu Myōhō Renge Kyō»).
Гаджет предназначен для удалённой совместной практики чтения мантр: он помогает членам сообщества чувствовать присутствие друг друга, даже когда они находятся в разных местах (особенно актуально после пандемии, когда Zoom оказался неудовлетворительным).


Список публикаций центра исследований вот тут
https://spiritedhci.org/publication-library/

А в этом году я буду в комитете ReserchExpo 2026 - присылайте свои доклады и с радостью их послушаю, сделаю ревью и помогу советом (или не помогу)
Вот кружочек

https://researchexpo.ru

Кабинетные исследования: а какие еще бывают? Практики ЦРУ

ЦРУ буквально издает научный журнал интеллиджент анализа с книжками и пособиями для аналитиков разведовательной информации с четким фокусом на кабинетные исследования: это позволяет постоянно развивать культуру аналитической работы аналитиков как внутри разведывательных агентств, так и частных компаний
https://www.cia.gov/resources/

На что я бы обратил внимание? Ну во-первых, есть настоящий взрослый журнал с темами - ИИ, как заниматься OSINT в Китае, эпистемологические и методологические проблемы сбора данных.
https://www.cia.gov/resources/csi/studies-in-intelligence/
Естественно, что все пдф находятся в открытом доступе, читать и скачивать можно https://www.cia.gov/resources/csi/static/UNCLASSIFIED-EXTRACTS-Studies-Vol-70.-No-2-June-2026.pdf

Больший интерес, скорее представляет собой практика работы с данными и с управлением командой аналитиков разведки:
A Tradecraft Primer: Structured Analytic Techniques for Improving Intelligence Analysis представляет собой учебник ремесла с фокусом на правилах взаимодействия аналитиков разведки. Прежде всего это упражнения и практики по оценке гипотез и отрицанию гипотез - “А вдруг в терракте виновато не Аум Синрике?” “А если этот факт на самом деле дезинформация другой разведки?” “Какие есть аргументы против тезиса о слабости режима в стране ИКС”. Разные упражнения должны тренировать скепсис и сомнения аналитиков, включать дискуссию. Иногда разведчик защищает гипотезы, а остальные атакуют, иногда это совместная работа относительно того или иного исследовательского проекта

Типичные упражнения, которые мне понравились - это проверка допущений(допущение — это любая гипотеза, которую аналитики приняли за истинную и которая лежит в основе оценки. Например, военный анализ может сосредоточиться исключительно на анализе ключевых технических и военных переменных (иногда называемых факторами) вооружённых сил и «допустить», что эти силы будут действовать в определённой среде (пустыня, открытые равнины, арктические условия и т. д.). Однако предположение других условий или допущений может существенно повлиять на оценку).

Второе, что тоже понравилось - это практика проверки достоверности источников - обычно в кабинетках, все-таки это опускают, “верят” или делают на основании экспертизы - предполагается, что основные источники можно перепроверить другими источниками, чтобы избежать ситуации, когда ключевые источники подвешены в воздухе

Третье - это матрица анализ конкурирующих гипотез: Выявление альтернативных объяснений (гипотез) и оценка всех доказательств, которые могут их опровергнуть, а не подтвердить. “А вдруг в теракте в метро Токио виновато не Аум Синрике?”: табличка факторов, разные оценки факторов - религиозные фанатики, политическая партия и тд и тп. Наверняка, продуктовые менеджеры сходу назовут много подобных матриц, но тут интересно, что, в целом, гораздо более смелые альтернативы
https://www.cia.gov/resources/csi/static/Tradecraft-Primer-apr09.pdf

Что еще занятное для прикладного исследователя в айти или около?
Есть система исследований и влиянии на анализ письма и чтения: передовые данные когнитивных наук 2010ых на то, какие практики письма делают проще для восприятия - я не совсем согласен, так как тема readability уже давно является предметом моего интереса. Приведу цитату из введения, так сказать, для затравки
“Наши представления о работе мозга слишком часто формируются на основе наблюдений за больными и инвалидами. Трудно уловить и зафиксировать, не говоря уже о понимании, стремительного полета разума, работающего на пике своих возможностей.
Писатель в процессе работы – это мыслитель, постоянно находящийся в состоянии когнитивной перегрузки.
На следующих страницах речь пойдет о «разуме, работающем на пике своих возможностей», – и в Управлении разведки, которое работает в основном в письменном режиме, это обычно означает разум «постоянно находящийся в состоянии когнитивной перегрузки»”
https://www.cia.gov/resources/csi/static/Thinking-and-Writing.pdf

Ну и напоследок, кто является отцом-основателем подходов и методов, которые стали институциональным фундаментом для подобного рода центров? Шерман Кент — профессор истории Йельского университета, который во время Второй мировой войны и в течение 17 лет службы в Центральном разведывательном управлении (ЦРУ) в эпоху холодной войны

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

Кент считал, что аналитики должны систематически анализировать свою работу в поисках улучшения практик, а также изучения ошибок. Ошибки неизбежны, но аналитики могут извлечь важные уроки из критического разбора неудач — особенно если анализ выявляет recurring модели ошибок, такие как «зеркальное отображение» (mirror imaging) или допущения, которые не пересматриваются, несмотря на изменение обстоятельств. Честное признание и объяснение аналитических ошибок, скорее всего, повысит, а не снизит доверие со стороны политиков-клиентов.

⁣Стратегии борьбы с throttle в event loop при работе с Native Addons и FFI через worker_threads

Node.js живёт на одном потоке — это знают все. Но когда в дело вступают Native Addons (napi, C++ модули) и FFI (Foreign Function Interface), event loop может неожиданно "зависнуть". Даже если ты используешь worker_threads, throttle всё равно случается. Почему? Потому что нативные вызовы не всегда изолируются полностью. Блокирующий системный вызов в аддоне может зацепить libuv thread pool или V8, и основной поток начинает тормозить.

FFI тут особенно неприятен. Библиотеки типа ffi-napi или koffi вызывают shared library синхронно — event loop просто стоит и ждёт, пока вызов вернётся. Все остальные задачи замораживаются.

Что с этим делать?

1. Вынос в dedicated worker.
Создаёшь отдельный worker, грузишь туда аддон, общаешься через MessageChannel. Главное — не передавай shared memory без синхронизации, если аддон не thread-safe.

const { Worker } = require('worker_threads');
const worker = new Worker('./native-worker.js', { workerData: {} });
worker.postMessage({ task: 'heavyCalc', data: [1, 2, 3] });
worker.on('message', result => console.log('Результат:', result));

Внутри worker:

const { parentPort } = require('worker_threads');
const nativeAddon = require('native-addon');
parentPort.on('message', msg => {
  const result = nativeAddon.heavySync(msg.data);
  parentPort.postMessage(result);
});

2. Асинхронные API для аддонов.
Если пишешь аддон сам — используй n-api async work (napi_create_async_work). Для FFI — заворачивай вызовы в setImmediate или setTimeout с нулевой задержкой. Это даёт event loop шанс обработать другие задачи.

3. Пул worker'ов с очередью.
Задачи распределяются, и один тяжёлый вызов не может монополизировать все ресурсы. Стандартный паттерн — берёшь задачу из очереди, отдаёшь свободному воркеру.

4. Atomics и SharedArrayBuffer.
Блокировка без захвата event loop. Но требует поддержки SharedArrayBuffer и аккуратной реализации.

5. Мониторинг.
Замеряй время вызовов через process.hrtime.bigint() или performance.now(). Если вызов длится дольше 50ms — это красный флаг. Логируй и переключай на worker.

Коротко:
- worker_threads — база, но не панацея.
- Для своих аддонов — async n-api.
- Для FFI — пулы и очереди.

Вывод:
Изоляция нативных вызовов через worker_threads с асинхронными API и мониторингом — единственный способ избежать throttling event loop в production.

Если чуть пролить аналитику, то длинный ответ будет такой:

Из железа у тебя прям щас есть выбор из:

1. Малый компьют с дохера объёма (370/395/спарки/макбуки/мини/студио/нэйм ит);
2. Средний компьют с мало объёма (3090/4090/b60/b70/7900/9700/нэйм ит);
3. Толстый компьют с дохера объёма (PRO6000/A100/H100/H200/MI250/нэйм ит).

Что отсутствует? Всё верно - средний компьют с дохера объема. Условно говоря, что-то типа RTX4090 на 64гб за недорого. На рынке ровно ничего подобного нет. И вот это довольно интересный момент, потому что РОВНО ТАКАЯ железка всем и нужна в массовом секторе имхо. В какой-то степени я даже удивлён, что всё ещё никто ничего подобного не предлагает, потому что отрывали бы с руками кмк.

Докидываем сюда мультипликатор веселья в виде охуевших цен не разное и всё становится ещё интереснее.

Но допустим, что такая железка у нас есть. Вопрос теперь не менее интересный: а что в неё грузить?

Если говорить про квантованные модели, то у тебя есть:
1. Квен/гемини 27B/31B под 24-32Гб;
2. Целый ворох устаревших на 3-4 поколения моделей типа 70B/120b для 48-64гб;
3. Весь прочий жир типа 0.3T-1T++ моделей, для чего надо 250-300++ Гб.

Что отсутствует? Всё верно - что-то между 2 и 3. Тупо нет и пока не предвидится хороших, качественных моделек такого объёма. Условно говоря, у тебя до сих пор нет какого-нибудь "Qwen 3.6 Coder Next", который при своих 80B как раз влезал в 48 гиговые карточки. То есть, условная 120-ка должна без проблем влезать в 64гб. Но такой модельки сука нет, а всё остальное в подобном типоразмере - либо старое говно, либо не сильно лучше младших квенов/гемини 27B/31B, пусть даже и тоже недавно вышли.

И вот она та самая жопа из первого абзаца - нет средней руки железки и нет средней руки модельки. В итоге либо ты сидишь на 24/48гб и юзаешь условный квен 27б, либо ты въёбываешь пятизнак грина в систему, собирая кластерок из пары PRO 6000, либо ты собираешь бюджет из четырёх-шести-восьми B70 и и втыкаешь туда что-нибудь интересное о 200+ гигах

Всё остальное будет полумерами и постоянным примирением с чем-то имхо. Ну типа, тот же Spark при всей своей пиздатости крайне плохо работает с dense модельками >20B или просто с любыми, где надо жирный компьют, потому что как бы а что вы хотите от такой малышки в коробке из-под конфет. Тот же мистраль медиум там выдаёт ~7 токенов, если мне память не изменяет. Это смешно. Я думаю, ты и сам на клавиатуре с такой же скоростью можешь печатать. :D

Собственно, в подтверждение всего вышесказанного можно процедить тот же реддит и увидеть, что публика там так и делится:
1. Пацаны с 24-32Gb, которые юзают квены/гемини 27б/31б;
2. Те же пацаны, но с несколькими видяхами на 48-96гб, которые юзают либо то же самое на жирных квантах и бОльших контекстах, либо что-то типа старого кодер некста;
3. Пацаны на ламбо с несколькими RTX6000, H200 и прочие подобные ребята из гугла, которым пойти пощупать новый GLM 5.2 на полтора терабайта - как воды попить.

Как видим, пропасть между 1-2 и 3 не заполнена ничем. Отвечая на незаданный вопрос "какого хуя" мысль такая: потому что ровно здесь и кроется sweet spot, который потенциально может закопать весь коммерс по предоставлению облачных решений. Те, что поменьше, угрозы не представляют, а тех, что побольше - слишком мало, чтобы угрожать. Но дай ты людям за недорого то же Qwen3.6 27B, только умноженный на пять или десять, и в целом всё, досвидос, облачка можно закрывать, клиентов у вас не будет. Примерно точно так же в своё время рендер-фермы сдохли - видяхи стали достаточно жирными, чтобы ребята могли у себя дома вменяемо рендерить, а большинству студий достаточно 6-10 на ферме и всё это за копейки.

Сайт by Robbin Cenijn  #сайт

🛠 Buefy - легкий фреймворк UI для Vue.js построен с использованием популярного элемента на основе CSS библиотека Бульма. В ней есть все составляющие типичного веб-приложения должен в том числе динамические элементы, как модели, тосты и уведомления, что позволяет разработчикам быстро добавлять элементы пользовательского интерфейса в своих проектах Vue.js .

🌍 Сайт

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

⁣Diagnostics Channel: Загляни внутрь Node.js в production без console.log и перезаливок

Когда приложение падает в 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, причём без единой правки кода приложения.

Vector Archects - Corporate webse
https://.com/shots/22571057-Vector-Archects-Corporate-webse