TeaCoder

Node.js в крылатой ракете: Реально ли написать систему наведения на JS?

2026-03-10T16:14:36.146Z

Приветствую всех, кто привык мерить производительность в миллисекундах ответа API. Сегодня мы поднимем планку.

Реально ли запустить Node.js в голове крылатой ракеты? Если отбросить священный трепет перед Ada и C++, технически - да. Современные бортовые вычислители на базе архитектур ARM Cortex-A достаточно мощны, чтобы прожевать рантайм V8. Но чтобы этот полет не закончился бесславным падением из-за сегфолта или заминки сборщика мусора, нам придется превратить Node.js в нечто совершенно иное.

1. Проблема жесткого реального времени (Hard Real-Time)

Крылатая ракета - это объект с непрерывным циклом управления. Каждые несколько микросекунд система должна выполнять цикл: Считывание -> Фильтрация -> Расчет -> Коррекция.

В обычном Node.js Event Loop работает по принципу «сделаю, как только освобожусь». В ракете это недопустимо. Если ваш скрипт занят парсингом JSON-конфигурации полета, а в это время датчик высоты кричит о приближении к скале, ракета должна бросить всё.

Для реализации этого на JS нам пришлось бы использовать Worker Threads и жесткую привязку к ядрам процессора (CPU Affinity), чтобы основной поток управления никогда не пересекался с фоновыми задачами.

2. Борьба с Garbage Collector: Zero-Allocation Style

Но главный страх это внезапная пауза на очистку памяти. Чтобы выжить, мы должны писать код в стиле Zero-Allocation. Мы не создаем объекты, не используем строки и не вызываем map/filter.

Мы используем SharedArrayBuffer - это кусок «сырой» памяти, общий для всех потоков, где данные лежат в виде байтов.

const telemetryBuffer = new SharedArrayBuffer(1024);
const telemetry = new Float64Array(telemetryBuffer);

const LATITUDE_IDX = 0;
const LONGITUDE_IDX = 1;
const ALTITUDE_IDX = 2;

function updateCourse(newLat, newLon, newAlt) {
  telemetry[LATITUDE_IDX] = newLat;
  telemetry[LONGITUDE_IDX] = newLon;
  telemetry[ALTITUDE_IDX] = newAlt;
}

Работа с координатами через типизированные массивы, чтобы не звать GC

3. Математика на лету: Фильтр Калмана на JS

Система наведения должна отделять полезный сигнал от шума датчиков. Для этого используется фильтр Калмана. В Node.js математика работает быстро благодаря JIT-компиляции, но нам важен прогрев. Если движок решит перекомпилировать функцию прямо во время маневра, ракета может дернуться.

Поэтому перед стартом система должна прогнать тысячи холостых циклов вычислений, чтобы V8 оптимизировал функции до состояния TurboFan (максимально быстрый машинный код) и больше их не трогал.

// Инициализируем пре-аллоцированные буферы
const state = new Float64Array(new SharedArrayBuffer(128));

function navigationLoop() {
  while (missionActive) {
    // Сбор данных через нативный аддон
    hardware.readSensorsToBuffer(state.buffer); 
    
    // Расчет фильтра Калмана
    // predict(state);
    // update(state);
    
    // Команда на приводы
    hardware.applyThrust(state[COURSE_VECTOR_IDX]);
    
    // Принудительная синхронизация времени
    waitPreciseMicroseconds(LOOP_TICK);
  }
}

Пример структуры кастомного цикла управления

4. Стык с железом: Node-API и прерывания

Node.js не умеет напрямую общаться с шиной данных ракеты (например, MIL-STD-1553 или CAN-bus). По этому понадобятся нативные аддоны на C++ или Rust.

В этой схеме JS выступает в роли стратега, а низкоуровневые модули в роли рефлексов. Когда датчик фиксирует критическое изменение курса, он посылает сигнал, который должен мгновенно пронзить все слои абстракции рантайма.

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

Конец

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

На этом наше погружение в мир детерминированного JavaScript окончено. Спасибо за внимание, всем удачного кодинга!

Infisical: менеджер секретов

2026-01-22T07:40:44.741Z

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

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

Зачем нужен менеджер секретов

В проектах секреты обычно хранят в .env файлах: переменные окружения для базы данных, API ключи и т.д. Это удобно на старте, но есть ряд проблем:

.env лежит в проекте или на сервере, и каждый, кто имеет доступ к файлу, видит все секреты.
Нет истории изменений - кто и когда менял значение, не видно.
Нельзя легко управлять разными окружениями: dev, staging, prod.

Например, обычный .env может выглядеть так:

NODE_ENV=development

HTTP_PORT=3000
CORS_ORIGIN=http://localhost:5173

STRIPE_API_KEY=sk_test_51LabcXYZ

DATABASE_URL=postgresql://user:pass@localhost:5432/dbname

Всё вроде просто, но что реально важно:

NODE_ENV, HTTP_PORT и CORS_ORIGIN - это локальные настройки, их можно оставить в .env.
А вот STRIPE_API_KEY, DATABASE_URL лучше перенести в менеджер секретов.

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

Cloud или Self-Hosted

Infisical можно использовать двумя способами: полностью управляемый cloud сервис или разворачивать на своём сервере. У self-hosted есть свои плюсы - полный контроль над данными, но для простого старта удобнее cloud версия.

Я буду показывать именно cloud, потому что её проще настроить и сразу работать с секретами в проекте.

Регистрация простая: заходите на сайт, создаёте аккаунт, подтверждаете почту и попадаете в панель управления.

Создание первой организации и проекта

После того как мы создали аккаунт, нам предлагают создать организацию. Организация в Infisical - это верхний уровень структуры, куда будут входить все ваши проекты и секреты.

Внутри организации Infisical создаёт первый проект автоматически, он называется Example Project. Это базовый проект, который можно использовать как пример или сразу удалять.

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

Добавление секретов

Я буду показывать всё на примере дефолтного проекта, который создаётся автоматически при создании организации. В нём уже есть несколько дефолтных переменных.

Для чистоты примера я сначала удаляю эти дефолтные переменные.

Теперь создадим свои переменные. В качестве примера возьмём DATABASE_URL и STRIPE_API_KEY. Чтобы добавить переменную, нажмите кнопку "Add Secret" в панели проекта. Появится форма создания новой переменной:

Разберём поля формы подробно:

Key - имя вашей переменной. Например DATABASE_URL. Это то, как её будут использовать в коде.
Value - здесь вводим реальное значение секрета.
Tags - теги помогают классифицировать секреты. Можно создавать теги по сервисам или по типу ключей, чтобы потом легко фильтровать.
Environments - выбор окружений, в которых будет создан секрет. В Infisical есть три стандартных окружения:

Development - для локальной разработки. Сюда обычно добавляют тестовые ключи или локальные строки подключения.
Staging - промежуточное окружение, где проверяются функции перед релизом. Здесь используют отдельные тестовые ключи и базы данных.
Production - боевое окружение, сюда добавляются реальные секреты, которые будут использоваться в продакшене.

Папки и окружения – dev/staging/prod и как их правильно разделять

Infisical позволяет разделять секреты по окружениям. Это помогает держать ключи для тестов отдельно от боевых данных.

Ещё есть папки, это удобный способ логически объединять переменные внутри окружения. Например, я создаю группу database для всех переменных базы, payment для Stripe и auth для JWT или OAuth токенов.

Интегрируем Infisical в приложение

Я буду показывать на примере простого Node.js приложения.

Для начала нам нужно установить Infisical CLI глобально, чтобы можно было работать с секретами через командную строку. Это делается одной простой командой:

npm i -g @infisical/cli

После установки нужно авторизоваться в Infisical. Для этого в терминале проекта пишем:

infisical login

CLI предложит выбрать способ использования: Infisical Cloud (US или EU регион) либо self-hosted. Выбираем нужный вариант(у меня это US) с помощью стрелок и нажимаем Enter. После этого происходит авторизация, и Infisical CLI получает доступ к вашим секретам.

Далее нужно привязать наш проект к CLI. Для этого в терминале выполняем команду:

infisical init

CLI покажет список доступных организаций. Выбираем организацию, из которой будем подгружать секреты. После этого в папке проекта создаётся файл конфигурации .infisical.json, который хранит ID проекта.

Теперь самое важное: чтобы приложение могло использовать секреты, его нельзя запускать обычной командой node index.js или npm run start. Нужно использовать команду:

infisical run node index.js

То есть при запуске любого кода, где мы используем переменные не из .env, а из Infisical, всегда добавляем infisical run перед командой. Это гарантирует, что Infisical подгрузит секреты в process.env на время выполнения.

В коде работать с ними можно точно так же, как с обычными переменными окружения:

console.log('Node environment:', process.env.NODE_ENV)
console.log('HTTP port:', process.env.HTTP_PORT)
console.log('Stripe API key:', process.env.STRIPE_API_KEY)
console.log('Database URL:', process.env.DATABASE_URL)

Если попытаться запустить приложение обычной командой node index.js, process.env для секретов Infisical будет пустым.

История изменений и аудит

Infisical ведёт детальный аудит всех действий с секретами в проекте. В панели управления есть раздел Audit Logs, где видно, кто, когда и что делал.

Например, на скрине показано, как я несколько раз просматривал список секретов в проекте. Каждое действие фиксируется с точным временем, типом события и аккаунтом пользователя:

event - что именно произошло (например, dashboard-list-secrets).
actor - кто совершил действие (например, user).
user_email - почта пользователя, чтобы можно было понять, кто именно сделал изменения.
timestamp - когда произошло событие (например, Jan 22nd 2026, 10:22 AM).

То есть аудит помогает отслеживать все изменения, предотвращать случайные удаления или утечки секретов и контролировать действия внутри команды.

Конец

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

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

До встречи в следующих статьях!

Как развернуть свой собственный статус-сервис с Uptime Kuma

2026-01-11T11:08:08.943Z

В этой статье я покажу, как развернуть свой собственный сервис для мониторинга сайтов и приложений с помощью Uptime Kuma. Мы установим сервис через Docker, настроим проверки для сайтов и API, подключим уведомления и сделаем публичную статус-страницу, чтобы ваши пользователи или команда всегда знали, что работает, а что нет.

Сайт проекта: https://github.com/louislam/uptime-kuma

Что такое Uptime Kuma

Uptime Kuma - это инструмент для мониторинга ваших сайтов и сервисов. Он показывает, работают ли ваши приложения и API и сразу уведомляет, если что-то упало.

С его помощью можно проверять доступность сайтов по HTTP(S), следить за TCP-соединениями и портами, WebSocket или просто пинговать сервер. Также он фиксирует скорость отклика чтобы понимать насколько быстро работают сервисы.

Главное преимущество это удобный веб-интерфейс. Он сохраняет историю проверок, показывает процент uptime и позволяет делать как публичные, так и приватные статус-страницы. Также можно настроить уведомления через Telegram, Discord, Slack, Email и другие каналы.

Запуск через Docker

Разворачивать Uptime Kuma мы будем через Docker - это самый простой способ.

Сначала создаём отдельную папку для проекта:

mkdir status
cd status

Дальше создаём файл docker-compose.yml:

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

Запускаем контейнер командой:

docker-compose up -d

Теперь веб-интерфейс доступен по адресу http://localhost:3001. Файл ./data хранит всю историю проверок и настройки, поэтому можно безопасно перезапускать контейнер.

Регистрация админского аккаунта

После того как вы запустили Uptime Kuma через Docker, первым делом нужно создать администратора.

На стартовой странице вводим логин и пароль. После подтверждения регистрации вы попадёте в основной интерфейс.

Создание монитора

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

Наc интересует кнопка Add New Monitor, которая позволяет создать новый монитор. Монитор - это настройка проверки конкретного сервиса: сайт, API, сервер или база данных. После создания монитор будет регулярно проверять доступность сервиса и уведомлять вас при сбоях.

Выбор типа монитора

Когда вы нажимаете Add New Monitor, первым делом нужно выбрать Monitor Type. Uptime Kuma предлагает несколько категорий:

HTTP(s) - проверка веб-сайтов и API через HTTP или HTTPS.
TCP Port - проверка доступности конкретного порта на сервере.
Ping - классический пинг сервера (ICMP).
HTTP(s) - Keyword - проверка наличия определённого текста на странице.
HTTP(s) - Json Query - проверка значений в JSON ответе.
gRPC(s) - Keyword - проверка gRPC сервисов.
DNS - проверка DNS записей.
Docker Container - проверка состояния контейнера Docker.

Есть также Specific Monitor Type, например базы данных (MySQL, PostgreSQL, MongoDB), игровые серверы (Steam, GameDig) и очереди сообщений (MQTT, Kafka).

Настройка HTTP(s) монитора

Давайте рассмотрим создание простого HTTP(s) монитора для веб-сайта.

Общие поля:

Friendly Name - имя мониторинга, например Website. Оно будет отображаться в панели и статус-страницах.
URL - адрес сайта, который проверяем, например https://teacoder.ru.
Heartbeat Interval - как часто проверять сервис. По умолчанию 60 секунд.
Retries - количество попыток до того, как сервис считается упавшим. Например, 0 отключает повторные попытки.
Heartbeat Retry Interval - интервал между повторными попытками, если первая проверка не прошла.
Request Timeout - время ожидания ответа от сервиса, по умолчанию 48 секунд.
Resend Notification if Down X times consecutively - повторная отправка уведомления, если сервис падает несколько раз подряд.

Расширенные настройки:

Certificate Expiry Notification - уведомление о скором окончании срока действия TLS/SSL сертификата.
Ignore TLS/SSL error for HTTPS websites - игнорировать ошибки сертификатов, если нужно проверять сайт с самоподписанным сертификатом.
Upside Down Mode - инвертирует статус: если сервис доступен, он будет отображаться как DOWN.
Max. Redirects - максимальное количество редиректов для HTTP-запроса, по умолчанию 10.
Accepted Status Codes - какие HTTP-коды считаются успешными (например, 200-299).

HTTP Options:

Method - GET, POST, PUT и т.д.
Body Encoding - JSON или XML.
Body - тело запроса для POST-запросов.
Headers - дополнительные HTTP-заголовки, например для авторизации.
Authentication - метод авторизации, если сайт защищён (Basic Auth, OAuth, NTLM, mTLS).

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

Настройка уведомлений

После того как мы создали первый монитор и он начал отслеживать сервис, важно настроить уведомления, чтобы узнавать о сбоях вовремя. В Uptime Kuma можно настроить уведомления через множество каналов: Telegram, Discord, Slack, Email, Webhook и другие. Я буду показывать на примере Telegram.

Создаём Telegram-бота

Откройте Telegram и найдите BotFather.
Нажмите /start, затем /newbot, чтобы создать нового бота.
Укажите имя бота и username.
После создания BotFather даст вам API ключ - сохраните его, он понадобится для настройки в Uptime Kuma.

Настройка уведомлений в Uptime Kuma

Далее откройте панель управления и перейдите в Settings → Notification. В этом разделе отображаются все существующие уведомления. Нажмите Setup Notification, чтобы добавить уведомление, и в поле Notification Type выберите Telegram.

Заполняем поля

Далее заполняем поля для уведомления. В поле Friendly Name можно указать любое имя, например Telegram Alerts. В поле Bot Token вставляем токен, который выдал BotFather. В Chat ID указываем идентификатор чата, куда бот будет отправлять уведомления - если это личный чат с ботом, используйте свой ID, если группа - ID группы. Чтобы узнать свой Chat ID, можно написать боту @userinfobot.

Внизу формы отметьте Default enabled и Apply on all existing monitors, чтобы уведомление сразу стало активным для всех мониторов. После сохранения уведомление будет работать автоматически, и бот сможет присылать сообщения о падениях и восстановлении сервисов.

Создание публичной статус-страницы

Теперь можно сделать публичную статус-страницу, чтобы пользователи видели, какие сервисы работают, а какие нет. Для этого в верхнем меню панели управления перейдите в Status Pages и нажмите New Status Page

В поле Name укажите любое имя страницы, например Services, а в Slug уникальный идентификатор для URL, например services. После сохранения страница будет доступна по адресу http://localhost:3001/status/services

На этом этапе страница уже создана, но она ещё не содержит мониторов. Чтобы добавить монитор на страницу, нажмите Add a monitor и выберите какие мониторы вы хотите добавить, я выбираю Website. Далее автоматически создастся группа с названием Services, в которую попадёт новый монитор. Вы также можете создавать свои группы и распределять мониторы по ним.

Заключение

Ну что же, я рассказал вам про основные моменты работы с Uptime Kuma: запуск через Docker, создание мониторов, уведомления и публичные статус-страницы.

Помимо этого, в панели есть разделы Reverse Proxy, Tags, Monitor History, Docker Hosts, Security, API Keys, Proxies и Backup, которые позволяют гибко управлять безопасностью и интеграциями. А для статус-страниц есть мелочи по типу: Footer Text, тема страницы, теги, Google Analytics и кастомные стили.

Спасибо, что прочитали статью, надеюсь она вам помогла!