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

ЦРУ буквально издает научный журнал интеллиджент анализа с книжками и пособиями для аналитиков разведовательной информации с четким фокусом на кабинетные исследования: это позволяет постоянно развивать культуру аналитической работы аналитиков как внутри разведывательных агентств, так и частных компаний
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

Погрузитесь в ИТ за 5 дней и получите доступ к высокооплачиваемым вакансиям!

Бесплатный короткий курс для тех, кто хочет не просто понять, чем занимаются айтишники, но и получить реальный опыт работы с ИТ‑системами.

Всего за 5 дней вы освоите ключевые компоненты ИТ‑сферы, разберёте 6 профессий и получите возможность выйти на зарплату 150–250 тыс.

Курс полностью практический. 8 мини‑проектов с реальными задачами, где вы научитесь: писать код, работать с инфраструктурой, разбираться в сетях, облаке и защите данных.

Подойдёт новичкам и тем, кто уже в ИТ. Количество мест ограничено — регистрируйтесь по ссылке и начинайте практику.

Реклама. Информация о рекламодателе по ссылкам в посте.

Vitaleaf Website

  #веб

📖Collaborative Software Design
🖋Baas-Schwegler Kenny, Van Kelle Evelyn, Verschatse Gien 2025

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

💾 Скачать книгу

Daily Coding #книги #архитектура & Max