📖C++20 STL Cookbook
🖋Weinman Bill 2022

В книге «Рецепты C++20 STL» вы найдете советы, которые помогут вам максимально эффективно использовать стандартную библиотеку шаблонов (Standard Template Library, STL) в C++, в том числе новые возможности, появившиеся в C++20.
C++ — богатый и мощный язык. Он основан на языке C с синтаксическими расширениями для обеспечения безопасности типов, обобщенного и объектно-ориентированного программирования. По сути, C++ — это язык низкого уровня. STL предоставляет широкий набор высокоуровневых классов, функций и алгоритмов, которые упрощают процесс программирования, делают его более эффективным и снижают вероятность ошибок.

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

Daily Coding #книги #Cpp & Max

В ходе познавательного интервью на полтора часа Фиона Фанг (Manager of the Claude Code and Cowork Teams в Anthropic) довольно подробно разбирает, как так вышло, что 80% кода пишет Клод и ничего страшного в компании не происходит, скорей — наоборот. Вот пять главных принципов:
1. В эпоху искусственного интеллекта узкое место в разработке смещается от кода к верификации, ревью, совместной работе и безопасности.
2. Процессы редко умирают естественным образом; вам необходимо активно устранять устаревшие.
3. Обсуждения технических вопросов от рисования на доске переходит к непосредственному созданию нескольких PR для сравнения.
4. Код становится единственным источником достоверности, что значительно сокращает количество проектных документов.
5. Менеджеры должны начинать как инженеры, а оргструктура должна быть как можно более плоской. Фиона настаивает на том, что все менеджеры должны сначала поработать инженерами на переднем крае; если они не согласны, с ними следует как можно скорее расстаться.
Звучит красиво, но воплощение как минимум п.2 и п.5 в большинстве организаций вряд ли получится:-/
Но вообще полезно послушать ее целиком или транскрипт почитать: дьявол, как обычно, в деталях, а не в принципах
https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering

⁣Деоптимизация ESM: глубокий импорт против Lazy Loading

Один из частых антипаттернов в Node.js — «островная» организация импортов, когда файл A статически импортирует B, B → C и так до 10+ уровней. Для CommonJS это было не так критично, но с ESM и строгой статической структурой модулей (resolution до выполнения кода) такая цепочка напрямую влияет на cold start.

Как это работает

При import в ESM рантайм строит граф зависимостей до выполнения. Чем глубже цепочка, тем больше модулей нужно зарезолвить, прочитать с диска, спарсить и скомпилировать. Каждый шаг — I/O (особенно без кэша ФС), в больших проектах — сотни файлов. Результат: старт приложения может проседать на 30-50%.

Пример: холодок и стек импортов

// entry.js → app.js → services/user.js → utils/validation.js → helpers/time.js
import './app.js' // тащит 4 файла за раз

На cold start все 4 резолвятся синхронно до выполнения кода. Если что-то не используется немедленно — деоптимизация.

Кейсы с lazy loading (динамический import)

Положительный пример: превращаем статический импорт в динамический.

// было:
import { expensiveFunction } from './heavy-module.js'
// стало:
const { expensiveFunction } = await import('./heavy-module.js')

await import() исполняется в момент вызова, не блокируя холодный старт. Полезно для: роутеров, сборщиков, SDK с тяжёлой инициализацией.

Но! Если heavy-module сам статически импортирует другие модули, при динамическом вызове весь его граф резолвится в момент выполнения — лаг переносится на первый запрос (cold start → warm request).

// heavy-module.js
import { superHeavy } from 'super-heavy-lib' // статический импорт
// при await import('./heavy-module.js') — superHeavy загружается синхронно

Решение: lazy экспорт всего модуля целиком или ESM-дерево с вершинным export, где все зависимости — динамические.

Ошибка: игнорировать цепочки при lazy loading

Типичная ошибка — думать, что любой await import() магически решает проблему cold start. На деле, если внутри модуля есть статические импорты, они все равно загрузятся синхронно при первой загрузке. Всегда проверяйте граф зависимостей под massive import.

Как применять на практике

В production не злоупотребляйте статическими импортами в long chains, если модули не нужны на старте. Lazy loading спасает cold start, но требует ревизии цепочек: load time может мигрировать. Best practice: в entry point оставлять только абсолютно необходимые модули. Всё остальное — под await import() с экспортами, где зависимости тоже динамические.

Вывод: Статические цепочки ESM синхронно резолвят весь граф на cold start, а lazy loading переносит лаг на первый запрос при наличии внутренних статических импортов.

Видимо школьники всё-таки не получат Steam Machine на Рождество.

Самая дешёвая версия стоит $1000, самая дорогая — $1500. Это сильно дороже консолей, с которыми она конкурирует за место под телевизором. Да ещё и продаётся по лотерее (которую я пока не выиграл и уже расхотел покупать).

Другого можно было не ждать. Valve никогда не выпускала массовые устройства.

Если бы Valve хотела агрессивно ворваться на рынок консолей, она могла бы продавать железо ниже себестоимости, как это делают Sony и Xbox, зарабатывая потом на каждой проданной игре. Но Valve свои 30% комиссии получает и так — независимо от того, купил пользователь Steam Machine или играет на обычном ПК.

Steam Machine (как и Steam Deck) выглядит как инструменты продвижения SteamOS, а не как попытка победить на рынке железа.

Valve хочет иметь план Б и постепенно снижать зависимость от Windows. Главный риск для Valve — не GOG и не Epic Store, а Microsoft, потому что именно Microsoft контролирует платформу, на которой работает Steam.

SteamOS — это страховка на случай, если Windows начнет переосмыслять свое положение в экосистеме ПК-игр и решит поменять правила не в пользу Valve.

Возможно, я переоцениваю ситуацию. Но интересно, что именно в тот момент, когда Microsoft всё активнее говорит о своей роли в игровой индустрии, Valve продолжает инвестировать в SteamOS.

• Сатья Наделла, 2025: "Remember the biggest gaming business is the Windows business."
• Сара Бонд, 2025: "We’re working closely with the Windows team to ensure that Windows is the number one platform for gaming."
• Аша Шарма, 2026: "Our presence on PC isn’t strong enough."

PS. Если бы Valve действительно хотела продать несколько миллионов Steam Machine быстро, у неё есть одно IP, которое мало кто может перебить.

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

Статья 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» — сильно аннотированный перевод китайского руководства по иглоукалыванию, включающий пять гравюр на меди (первые две — китайские точки акупунктуры, две — японские, и одна — изображение иглы и молотка) — стала его попыткой донести эту мудрость до Европы.