О хуман факторс в/на Украине

Статья Military Situation Awareness: Ukrainian Experience - осведомлённость о ситуации (Situational Awareness, SA) стала одним из ключевых понятий в военной сфере. Российско-украинская война привела к развитию информационных технологий в Украине для управления войсками и боевой обстановки. Работа классифицирует информационные решения, оценивает распределение продуктов по различным классификационным секторам и проводит SWOT-анализ
https://www.acigjournal.com/Military-Situation-Awareness-Ukrainian-Experience,190341,0,2.html

Одним из результатов войны между Россией и Украиной стал стремительный рост информационных технологий в украинской армии. Основной причиной этого процесса является необходимость получения преимущества над противником на поле боя и при планировании соответствующих операций. Помимо сугубо военных компонентов, это также включает аспекты безопасности управления территориальными органами, осуществляющими региональное и местное управление, а также информирование населения о существующих военных и иных угрозах.

В этой связи становится актуальным изучение формирования наиболее распространённых подходов к организации информационного взаимодействия на военном и гражданском уровнях на основе концепции ситуационной осведомлённости (SA) и концепции сетецентрической войны (Network-Centric Warfare, NCW).
Ситуационная осведомлённость представляет собой модель ситуационного суждения. Одним из наиболее известных исследователей в этой области является Мика Эндсли, которая сформулировала следующее определение: «Ситуационная осведомлённость — это восприятие элементов и событий окружающей среды во времени и пространстве, понимание их значения и прогнозирование их состояния в ближайшем будущем». Цель ситуационной осведомлённости заключается в активном выявлении и анализе информации, относящейся к текущей операционной устойчивости и безопасности, а также в координации этой информации внутри организации для обеспечения того, чтобы все её подразделения действовали в рамках единой операционной картины.

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

Восприятие — уровень 1 SA: Первый этап достижения ситуационной осведомлённости — это восприятие состояния, характеристик и динамики объектов в окружающей среде. Например, оператору необходимо различать важные объекты в окружении, такие как другие летательные аппараты, рельеф местности и сигнальные индикаторы, а также их значимые характеристики.
Понимание — уровень 2 SA: Второй этап — это понимание ситуации, основанное на интеграции разрозненных элементов первого уровня SA. Уровень 2 выходит за рамки простого осознания элементов среды и связан с формированием понимания их значимости в контексте целей оператора. Кратко, уровень 2 SA можно определить как понимание объектов в окружающей среде, особенно при их совместном рассмотрении, в связи с целями оператора. Например, оператор должен понимать взаимосвязь и значимость воспринимаемых элементов. Менее опытный оператор может достигать того же уровня восприятия (уровень 1), что и более опытный, но испытывать трудности с объединением этих элементов и соотнесением их с целями для полноценного понимания ситуации (уровень 2 SA).
Прогнозирование — уровень 3 SA: Третий уровень связан со способностью прогнозировать будущие действия объектов в окружающей среде, по крайней мере в краткосрочной перспективе. Такой прогноз основывается на осознании состояния и динамики элементов среды и их понимании. Кратко, уровень 3 SA можно определить как предсказание или оценку будущего состояния объектов в окружающей среде. Например, на основе воспринятой и осмысленной информации опытные операторы прогнозируют возможные будущие события (уровень 3 SA), что даёт им знания и время для выбора наилучшего курса действий для достижения своих целей.

Ситуационная осведомлённость (и оперативная обстановка как её компонент) является функцией времени и может быть представлена следующим образом:
CO(t)≤OO(t),M
где:
CO(t) — ситуационная осведомлённость за период времени t;
OO(t) — оперативная обстановка за период времени t;
M — ментальная модель.

Понятие «ситуационной осведомлённости» в контексте анализа военной компоненты тесно связано с концепцией сетецентрической войны (Network-Centric Warfare, NCW).

Уровни Situation awareness из статьи
+ классификации существующих систем: показетельны годы запуска проектов - с 2014 года

Тут должен быть, наверное, какой-то вывод относительно русских хуман факторс и/или инженерной/когнитивной психологии, но, пожалуй, воздержусь

Фигму прокачали

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

Для анимаций в интерфейсах больше не нужен отдельно афтер эффектс, тоже влияние заметное окажет, хоть и ждали на пару лет раньше эту возможность.

Совмещение интерактивных макетов, закоженных и обычных на одном холсте, тоже не неожиданность, скорее непонятно было зачем делать отдельный фигма мейк для этого.

figma.com/blog/config-2026-recap/

Почему дизайнеры не понимают бизнес — и как это исправить

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

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

Не переживай, через пару недель в App Store что-то типа такого

🛠 pitrery - это набор инструментов для упрощения управления резервными копиями и восстановлениями PITR

🌍 Сайт

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

⁣WebSocket backpressure в Node.js: когда ws.send() без контроля ведёт к OOM

Игнорирование скорости потребления данных клиентом при push-рассылках — одна из частых причин падения Node.js-процесса из-за нехватки памяти. Проблема кроется в том, что библиотека ws буферизует неотправленные фреймы в очереди, которая растёт линейно при медленных или спящих клиентах.

Через bufferedAmount
Каждый сокет библиотеки ws имеет свойство bufferedAmount, показывающее количество байт в очереди на отправку. Перед вызовом ws.send() проверяйте порог. Если он превышен — пауза отправки.

if (ws.bufferedAmount > 1_000_000) {
  ws.pause();
}

Событие drain
После освобождения буфера сокет генерирует событие drain. Его можно использовать для возобновления отправки, выстраивая собственную очередь с контролем размера.

function sendOrQueue(ws, data) {
  if (ws.bufferedAmount > 0) {
    ws.once('drain', () => ws.send(data));
  } else {
    ws.send(data);
  }
}

Типичная ошибка — навешивать drain на каждый send() без очистки предыдущих обработчиков. Это приводит к утечкам слушателей.

Собственная очередь с лимитом
Если число неотправленных сообщений превышает лимит, отключайте клиента через ws.terminate(). Иначе память растёт неконтролируемо.

const MAX_QUEUE = 2000;
if (ws.bufferedAmount > MAX_QUEUE * 1000) {
  ws.terminate();
  return;
}

В production при push-рассылках на 10 тысяч клиентов с bufferedAmount > 1 MB каждый, процесс потребляет 10+ GB RAM и падает с OOM.

Мониторинг
Логируйте клиентов с bufferedAmount > 512 KB. Это ранний индикатор проблем. В библиотеке ws до версии 8.x отсутствовал встроенный контроль потока, а net.Socket использует backpressure через write() + drain, но ws его не учитывает по умолчанию.

Вывод: Проверяйте bufferedAmount, используйте drain и задавайте жёсткие лимиты очереди — иначе незаметный OOM гарантирован при любой расходящейся нагрузке.

Странные визуализации: диаграммы меридианов

К концу книги Виллема тен Рэйне (1647–1700) «De Acupunctura» нидерландский врач рассказывает о том, что, по-видимому, было первым случаем, когда он увидел выполнение процедуры иглоукалывания.
https://archive.org/details/BIUSante_71050/page/n214/mode/1up

Он находится на корабле вместе с императорским японским солдатом во время hofreis — тысячекилометрового путешествия из Нагасаки ко двору императора в Эдо. Солдат страдает от морской болезни, а возможно, и от излишней любви к удовольствиям. Есть только одно решение, и он выполняет его сам:

В моём присутствии он выполнил иглоукалывание следующим образом (на основании этого случая, читатель, суди и о других). Лёжа на спине, он вонзил иглу в левую сторону живота выше привратника желудка в четырёх разных местах. (Для этого он осторожно держал остриё иглы кончиками пальцев.) Пока он постукивал по игле молотком (поскольку его кожа была довольно жёсткой), он задерживал дыхание. Когда игла вошла примерно на ширину пальца, он повернул её рукоятку. Затем он прижал пальцами место укола. После извлечения иглы крови, однако, не появилось; остался лишь едва заметный след от прокола. Освободившись от боли и излечившись этой процедурой, он восстановил здоровье.

Для европейского врача XVII века, чьё гиппократовское образование всё ещё опиралось на учение о жидкостях организма, отсутствие крови при процедуре, вероятно, было не меньшим удивлением, чем всё остальное. Молоток, который использовал солдат, был японским нововведением в почти двухтысячелетней китайской традиции иглоукалывания.

Тен Рэйне сразу же взялся выяснить, как это работает. «De Acupunctura» — сильно аннотированный перевод китайского руководства по иглоукалыванию, включающий пять гравюр на меди (первые две — китайские точки акупунктуры, две — японские, и одна — изображение иглы и молотка) — стала его попыткой донести эту мудрость до Европы.

Почему пользователи лучше воспринимают детали через компактные окна, выезжающие в режиме slideover

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

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

Умеет программировать? Да — технарь-программист
Умеет рисовать? Да — артист/художник

Оба ответа нет? Техарт!

🛠 Faker - быстро вставляйте данные-заполнители, используя популярную JavaScript-библиотеку Faker. Вы можете генерировать случайные имена, адреса, изображения, номера телефонов или просто абзацы из классической Lorem Ipsum. Каждая категория имеет различные подкатегории, чтобы вы могли адаптировать данные к своим потребностям.

🌍 Сайт

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

⁣Утечка памяти, которую вы не заметите: rejections в for await...of и стримы

Обработка ошибок в асинхронных итераторах и стримах кажется интуитивной, но неочевидные rejections внутри генератора или метода _read() могут привести к зависанию итерации и неосвобождению памяти. В production это проявляется как постепенный рост heap-usage без видимых причин.

Почему это происходит?
Когда вы используете for await...of, движок ожидает объект { value, done } от итератора. Если внутри асинхронного генератора возникает rejection (например, от необработанного промиса), итерация может зависнуть в бесконечном ожидании, а буферы стрима или данные генератора останутся в памяти.

Пример с генератором:

async function* gen() {
  yield 1;
  await Promise.reject(new Error('fail'));
  yield 2; // не достигнется
}
for await (const v of gen()) { } // зависнет?

Хотя ошибка пробросится, внутренние ресурсы — открытые соединения, таймеры — могут остаться висеть.

В стримах ситуация опаснее:

const { Readable } = require('stream');
const stream = new Readable({
  async read() {
    const data = await riskyOp();
    this.push(data);
    // если rejection без this.destroy() - утечка
  }
});
for await (const chunk of stream) { }

Если read() не завершится вызовом this.destroy(err), стрим не сгенерирует событие 'error' и не очистит внутренний буфер.

Практические советы:
* Всегда обрабатывайте rejections через try-catch внутри итератора и явно завершайте итерацию — throw или return.
* Для стримов используйте this.destroy(err) при ошибках в _read или предпочтительно pipeline для автоматической обработки.
* Добавьте finally для гарантированной очистки ресурсов (закрытие соединений, таймеров).
* Проверяйте утечки через heap snapshots или process.on('warning') — не стесняйтесь мониторить.

Вывод: for await...of не обеспечивает автоматической очистки, и необработанные rejections — прямой путь к утечке памяти, поэтому всегда завершайте итерацию явно.