Перейти к содержанию
  • Лента
  • Категории
  • Последние
  • Метки
  • Популярные
  • Пользователи
  • Группы
Свернуть
exlends
Категории
  • ru
    Игры
    Образование
    Искусственный Интеллект
    Новости
    Бекенд, разработка серверов
    Фронтенд
    Мобильная разработка
    Языки программирования
    Разработка игр | 3D | 2D
    Базы данных
    CMS
    Системное Администрирование
    Операционные системы
    Маркетинг
    Девайсы
    Сообщество
    Юмор, Мемы

  • en
    Humor
    News
    AI
    Programming languages
    Frontend
    GameDev

  • Блоги

Авторизуйтесь, чтобы написать сообщение

  • Все категории
  • GameFishG
    GameFish
    Crimson Desert вышла 19 марта: отзывы о боях и оптимизации на RTX 50xx для 144 FPS

    Обложка: Crimson Desert вышла 19 марта: первые отзывы игроков о боях и оптимизации на RTX 50xx для 144 FPS

    Crimson Desert вчера завезли - 19 марта глобальный релиз, и народ уже рубится в открытом мире от Pearl Abyss. Первые отзывы летят с форумов: бои имба, но оптимизация хромает на ПК. Разберём, что пишут геймеры про комбо в катках и как выжать 144 FPS на свежих RTX 50xx.

    Это поможет новичкам не слить бабки зря и сразу настроить риг под стабильный фреймрейт. Без воды - только свежие впечатления и конфиги от тех, кто протестировал на релизе. За сутки сервера трещат, но лагов меньше, чем ждали.

    Бои в Crimson Desert: комбо и мясорубка от Pearl Abyss

    Парни на реддите и стиме орут - боёвка здесь топовая, динамичная, как в souls-like, но с открытым миром. Каждый удар весит, комбо цепляются плавно, а ульты рвут толпы мобов в фарше. Разрабы явно накачали механик из Black Desert, но добавили тактику: уклонения с QTE и синергия с компаньонами. В босс-файтах комбо держат на пике адреналина, но если не освоить тайминги - фризы в голове от вайпов.

    Примеры из отзывов: один стример нарубал 50 мобов за минуту с двуручником, другой жалуется, что на хардкоре AI умнее, чем в бете. Логично, что бои - главный хайп, ведь мир огромный, квесты ветвятся. Но без нормального FPS это всё в стомаке тонет. Переходим к тестам.

    • Комбо-имба на мечах: Цепочка 5 ударов + ульт, дамагит 2к+ за волну, но требует 120+ FPS для точных инпутов.
    • Нюанс с компаньонами: Они танкуют, пока ты фланкуешь - синергия даёт +30% крит, но лаг спайки ломают тайминги.
    • Босс-файты: Фазы с QTE, где промах = смерть; отзывы хвалят анимации, но просят патч на коллизии.
    • Прокачка стиля: Апгрейд оружия меняет комбо, мета сейчас - agility билд для 144 FPS каток.
    Стиль боя Дамаг/сек Треб FPS для имбы Отзывы
    Двуручник 1500+ 144+ Мясорубка, рвёт толпы [форумы]
    Кинжалы 1200 120 Мобильность топ, но випы на лоу ФПС
    Лук 1000 100 Безопасно, но скучно без 144 Гц

    Оптимизация на релизе: фризы и статтеры в открытом мире

    На старте сервера жрут CPU как не в себя, статтеры в городах - норма на средних ригах. Игроки с i7 и RTX 4080 пишут: в 4K ультра фризы до 40 FPS в дождь или толпе. Pearl Abyss обещали DX12 Ultimate, но шейдеры компилируются вечно, первый запуск - лагающий ад. Зато на высоких после - стабильно, если не ультра текстуры. Отзывы сходятся: мобильность мира страдает от утечек памяти, 92 ГБ предзагрузка - это минимум, полная - 150+ ГБ.

    Форумы бомбят: ‘Завезли красивый мир, но троттлинг на жаре убивает’. Тесты показывают, CPU лимит в многопотоке, GPU не нагружен на 100%. Логично выводить конфиг под 144 FPS. Без него бои превращаются в слайд-шоу. Смотрим детали.

    • Шейдер-кэш: Первый вход - 10 мин статтеров, после чистит и держит 100+ FPS.
    • Утечки памяти: 20+ ГБ в час на ультра, мониторьте через MSI Afterburner.
    • CPU-бутылочное горлышко: 8+ ядер обязательно, i5 12-го поколения фризит в городах.
    • DLSS/FSR: Включайте 3.0 - +50% FPS без потери чёткости.
    • VSync off: Для 144 Гц, но рискуете спайками до 200 FPS.

    RTX 50xx под 144 FPS: андервольтинг и готовые конфиги

    На RTX 5090 тесты с форумов: ультра 4K - 144 FPS стабильно в боях, 200+ в пустыне. 5080 тянет 1440p ультра на 144 Гц без боли, но с DLSS Quality. Разрабы подтвердили RT и DLSS 4, но на релизе RT medium - золотая середина, без него FPS +30%. Андервольтинг спасает от троттлинга: -100 мВ на ядро даёт -10C и +10 FPS. Отзывы: ‘На 50xx имба, ниже 4080 - страдания в динамике’.

    Геймеры делятся: в бенчмарках Cyberpunk-подобных зон 5090 рвёт 200 FPS, но в Crimson с толпами падает до 120 без тюнинга. Мета - 1440p для баланса. Конфиги ниже вытащены из тредов, работают на релизе.

    # NVIDIA Profile Inspector для RTX 50xx
    DLSS=Quality
    RT=Medium
    Texture=High
    Shadow=Medium
    AA=TSR
    FrameGen=On
    
    • Андервольт 5090: MSI AB +100 MHz core, power limit 110%, температура 65C, 144 FPS locked.
    • Для 5080: DLSS Balanced + RT Off = 144 FPS в 1440p, zero фризов.
    • Мониторинг: Afterburner с RTSS оверлей - FPS, usage, temp.
    • Драйвера: 56x.xx свежие, с DSR off для стабильности.
    Карта Разрешение Сеттинг FPS в боях Темп GPU
    RTX 5090 4K Ультра+RT Med 144-180 68C
    RTX 5080 1440p Высокий+DLSS 144-160 70C
    RTX 5070 1080p Средний 120-144 72C

    Что народ рубит дальше в катках

    Отзывы фиксируют: бои затягивают на часы, но мир просит патчей на LOD-попы и ИИ в ночи. На RTX 50xx 144 FPS реальны без боли, если конфиг подогнать. Серверы держат, онлайна пока нет, но Pearl Abyss намекали на GTA-онлайн мод позже. Остаётся следить за хотфиксами - статтеры в городах ещё подрежут.


    0 0 0 Ответить
  • hannadevH
    hannadev
    React 19 Compiler: авто-мемоизация списков в дашбордах без useMemo

    Обложка: React 19 Compiler: автоматическая мемоизация списков в дашбордах без useMemo и useCallback

    React 19 Compiler меняет правила игры для дашбордов с кучей списков. Теперь тяжелые фильтры и сортировки летают без ручных useMemo и useCallback. Забудь про баганые зависимости - компилятор сам добавит оптимизации.

    В дашбордах списки обновляются пачками: фильтры, сортировки, агрегации. Без мемоизации каждый рендер жрет CPU. Compiler автоматически кэширует вычисления, где видит повторения. Это спасает от лагов в реал-тайм аналитике.

    Как Compiler видит списки в дашбордах

    Дашборды - это мясорубка для React: тысячи строк данных, интерактивные фильтры, графики. Каждый клик по слайдеру или поиску триггерит ре-рендер всего. Раньше приходилось оборачивать фильтрацию в useMemo с массивом зависимостей. Compiler анализирует код на этапе сборки и вставляет мемоизацию туда, где она реально нужна.

    Представь типичный дашборд с ордерами: таблица с поиском, сортировкой по цене и категории. Без оптимизаций map() и filter() бегают заново при каждом state-обновлении. Компилятор замечает, что входные данные не менялись, и пропускает вычисления. Результат - FPS держится на 60 даже с 10k+ строк.

    • Авто-детект зависимостей: Compiler трекает, от чего зависит filteredList - от props или state. Нет нужды вручную перечислять [data, filter, sortBy].
    • Цепочки вычислений: Если stats зависят от filteredData, компилятор строит правильную цепочку без твоего участия.
    • Коллбэки в map(): onClick для каждой строки теперь мемоизирован автоматически - React.memo на детях не ломается.
    Ситуация Без Compiler С Compiler
    Фильтр 5k items useMemo([data, query]) - 50ms Авто, 0ms на повтор
    map() с коллбэками useCallback в цикле - boilerplate Простой map(), стабилки сами
    Сортировка + агрегация Цепь useMemo Одно выражение - Compiler размотает

    Примеры дашбордов до и после

    Возьми аналитику продаж: данные тянутся из API, юзер фильтрует по дате/региону, считает total revenue. В старом React это стена из хуков - useMemo для фильтра, еще один для sum(), useCallback для handlers. Код разрастается, линтер ноет на missed deps.

    С Compiler пишешь чисто: const filtered = data.filter(…); const total = filtered.reduce(…). Компилятор видит, что filtered зависит только от data и filterState, и оборачивает в скрытый useMemo. В дашборде с графиками и таблицами рендеры улетают - только changed части обновляются.

    function OrdersDashboard({ orders }) {
      const [filter, setFilter] = useState('all');
      // Compiler мемоизирует автоматически
      const filteredOrders = orders.filter(o => o.region === filter);
      const revenue = filteredOrders.reduce((sum, o) => sum + o.amount, 0);
    
      return (
        <div>
          <input value={filter} onChange={e => setFilter(e.target.value)} />
          <ul>{filteredOrders.map(o => <OrderRow key={o.id} order={o} />)}</ul>
          <div>Total: {revenue}</div>
        </div>
      );
    }
    
    • Нюанс: Compiler не трогает impure функции - если внутри filter() мутируешь state, мемоизация сломается.
    • Производительность: В health-check тесте (npx compiler-health-check) увидишь, сколько мемоизаций добавлено бесплатно.
    • Для SSR в Next.js: Compiler работает на сервере, но runtime нужен react-compiler-runtime для старых версий.

    Настройка Compiler в проекте

    Подключается как Babel-плагин: babel-plugin-react-compiler@beta. В Next.js или Vite - добавь в config, и готово. Компилятор сканирует JSX/TSX, трансформирует в оптимизированный бандл. Нет миграции кода - просто собери и деплои.

    В дашбордах с React Native или большими таблицами эффект взрывной: списки скроллят silky smooth без shouldComponentUpdate хаков. Тестируй с React DevTools Profiler - увидишь, как Why did this render? уходит в ноль для мемоизированных частей.

    npm i babel-plugin-react-compiler@beta
    # В babel.config.js
    module.exports = { plugins: [['react-compiler', {}]] };
    
    Инструмент Команда Что проверяет
    Health Check npx compiler-health-check % покрытия мемоизацией
    DevTools Profiler Рендеры до/после
    Bundle Analyzer vite-plugin-bundle-analyzer Размер после трансформа

    Кiller-фича для дашбордов: списки с виртуализацией (react-window) теперь не требуют extra мемоизации.

    Compiler открывает новые паттерны

    Дашборды эволюционируют: реал-тайм обновления via WebSockets, AI-фильтры на данных. Compiler снимает боль ручной оптимизации - фокусируйся на UX. Пиши declarative код, компилятор сделает imperative магию под капотом.

    Остается за кадром: edge-кейсы с custom hooks или third-party либами. Тестируй на реальных данных - иногда manual useMemo все же нужен для супер-тяжелых вычислений вроде ML-предиктов. В будущем Compiler поумнеет, а пока - это топ для 90% дашбордных списков.


    0 0 0 Ответить
  • kirilljsxK
    kirilljsx
    Автоматизация деплоя tsnative-бинарников на Yandex Cloud Functions с cron и TypeScript: DIY-гайд

    Обложка: Как автоматизировать деплой tsnative-бинарников на Yandex Cloud Functions с cron и TypeScript: DIY-гайд для нативной автоматизации 2026

    Хочешь раз и навсегда забыть про ручной деплой tsnative-бинарников в Yandex Cloud Functions? Этот гайд покажет, как настроить полную автоматизацию с cron-триггерами и TypeScript. Получишь готовый пайплайн, который сам собирает, деплоит и запускает по расписанию - никаких больше копипастов в консоль.

    Такой подход решает типичные боли: версии разлетаются, cron не срабатывает, бинарники не влезают в лимиты. Всё на чистом TypeScript, с минимальными зависимостями и поддержкой больших архивов через Object Storage. Подходит для пет-проектов и продакшена - деплой за минуты.

    Подготовка окружения и конфиг

    Сначала разберёмся, что такое tsnative-бинарники. Это нативные модули, скомпилированные из TypeScript через esbuild или bun, которые работают быстрее обычного JS в Cloud Functions. Они идеальны для задач с высокой нагрузкой - парсеры, обработка очередей, cron-джобы. Но деплой вручную - это ад: зипы, IAM-права, версии функций.

    Автоматизация через yandex-cloud-deploy-fn решает это. Устанавливаешь CLI, пишешь конфиг и запускаешь npx-команду - она сама авторизуется, пакует код, заливает в Object Storage (если >3.5Mb) и создаёт версию. Для cron добавляем триггер по расписанию прямо в конфиге. Пример: ежедневный запуск в 3:00 для бэкапа данных.

    Вот базовый стек:

    • TypeScript + esbuild для сборки бинарников.
    • yandex-cloud-deploy-fn как основной деплойер.
    • Cron-триггер в Yandex Cloud для расписания.
    Компонент Описание Почему нужен
    esbuild Быстрая сборка TS в нативный бинарник Скорость выполнения x10, меньше памяти
    deploy-fn CLI Деплой без yc cli Нет лишних логов, поддержка больших зипов
    Cron trigger Запуск по расписанию Полная автоматизация без внешних серваков

    Нюанс: для больших бинарников обязательно настрой Object Storage в конфиге, иначе лимит 3.5Mb убьёт деплой.

    Сборка tsnative-бинарника из TypeScript

    Сборка - ключевой шаг. Обычный tsc даёт JS, но для нативной скорости нужен esbuild с флагом --bundle и native. Это компилирует TS прямо в бинарник, который запускается как standalone-приложение. В Cloud Functions указываешь entrypoint на этот бинарник, и функция летает.

    Пример: у тебя скрипт для парсинга Reddit через API. Ручной деплой - npm run build, zip, yc serverless… Задолбаешься. С esbuild: одна команда, бинарник готов. Тестируешь локально ./bin/parser, потом деплоишь. В 2026 esbuild уже поддерживает TypeScript 5.5+ с полным инференсом.

    Шаги сборки:

    1. Установи esbuild: npm i -D esbuild.
    2. Добавь скрипт в package.json: "build": "esbuild src/index.ts --bundle --platform=node --format=esm --outfile=dist/bin/parser --external:node:*".
    3. Запусти npm run build - получишь исполняемый файл.

    Важно: укажи shebang #!/usr/bin/env node в начале бинарника для совместимости с Cloud Functions. Для cron задай memory 256MB+ - нативка жрёт больше на старте, но потом экономит.

    Сравнение сборок Время сборки Размер бинарника Скорость в CF
    tsc + JS 2s 150KB Базовая
    esbuild native 0.5s 2MB x8 быстрее

    Проверяй бинарник локально с NODE_ENV=production ./dist/bin/parser - эмулирует CF-окружение.

    Конфиг деплоя и cron-триггер

    Теперь конфиг deploy.config.js - сердце автоматизации. Здесь задаёшь имя функции, runtime (nodejs22), environment vars, теги. Для cron добавляешь триггер с расписанием в cron-формате. CLI сам создаст версию и привяжет триггер - никаких yc-команд.

    Пример конфига для парсера:

    const config = {
      functions: {
        parser: {
          folderId: 'b1g123abc456',
          serviceAccountId: 'aje123xyz789',
          runtime: 'nodejs22',
          entrypoint: 'dist/bin/parser.handler',
          memory: '256MB',
          execTime: '10m',
          environment: { NODE_ENV: 'production', REDDIT_API: 'токен' },
        },
      },
      triggers: {
        cron-parser: {
          function: 'parser',
          schedule: '0 3 * * *', // Ежедневно в 3:00
          retries: 3,
        },
      },
    };
    module.exports = config;
    

    Запуск: npx deploy-fn. Вывод покажет версию, размер, время. Триггер создастся автоматически. Для тегов добавь интерактивный режим - CLI спросит перед деплоем в prod.

    Ключевые настройки:

    • folderId/serviceAccountId: Из консоли Yandex Cloud, роль functions.admin.
    • schedule: Cron-строка, протестируй на crontab.guru.
    • storage: Для бинарников >3.5Mb - bucket с AWS-ключами.

    Если триггер не сработал - чекни логи в консоли, часто дело в правах сервисного аккаунта.

    Запуск и отладка пайплайна

    Готово? Деплойни и смотри. CLI покажет: Creating zip… Authorized… Version created. Cron запустится по расписанию, логи в реалтайм. Для CI/CD интегрируй в GitHub Actions - добавь шаг npx deploy-fn после тестов.

    Типичные проблемы: бинарник не запускается - проверь архитектуру (x64), права (755). Cron не бьёт - синхронизируй timezone в environment. Масштаб: для highload подними memory до 2GB, добавь queue-trigger.

    Отладочные команды:

    1. npx deploy-fn --dry-run - тест без деплоя.
    2. Логи: yc serverless function version logs.
    3. Роллбек: yc serverless function version rollback.
    Проблема Решение Время фикса
    Zip >3.5Mb Включи storage 2 мин
    Cron не стартует Роль editor на триггер 5 мин
    Бинарник краш –target=node20.9 1 мин

    Масштабируй: для нескольких функций - массив в config, один npx деплоит всё.

    Нативка в продакшене - что апгрейдить дальше

    Автоматизация готова: деплой по кнопке, cron тикает, TypeScript-код чистый. Осталось за кадром: мониторинг метрик через Yandex Monitoring, A/B-тесты версий функций, интеграция с Telegram для алертов.

    Подумать стоит над миграцией на bun-runtime (если Yandex добавит в 2026), или комбо с Message Queue для батч-обработки. Такой пайплайн тянет реальный трафик - парсеры, ETL, боты. Тестируй на своих задачах, тюнь под нагрузку.


    0 0 0 Ответить
  • hannadevH
    hannadev
    Next.js 16: Server Components с useOptimistic и Turbopack для AI-тасков

    Обложка: Next.js 16: React Server Components с useOptimistic и Turbopack для оптимистичных обновлений AI-генерируемых списков задач

    Next.js 16 меняет игру с React Server Components - теперь они stable и по умолчанию. Добавь useOptimistic для мгновенных обновлений стейта и Turbopack для супербыстрых бандлов. Это идеально для AI-генерируемых списков задач - никаких лагов, чистый DX.

    Представь: юзер генерит таск через AI, и список обновляется оптимистично на сервере, без client JS overhead. Turbopack ускоряет HMR в 10x, а RSC режет бандл на 70%. Зачем мучаться с гидрацией, если можно рендерить на сервере и стримить? Получится отзывчивый todo-лист с AI-магией.

    React Server Components: серверный рендер без компромиссов

    Server Components в Next.js 16 - это не эксперимент, а production-ready фича. Они рендерятся только на сервере, шлют zero JS в браузер и идеальны для data fetching. Нет нужды в useEffect или состояниях на клиенте - fetch в компоненте, и всё стримится через Suspense. Для AI-тасков это киллер: генерируем список на сервере, интегрируем с OpenAI API прямо в RSC.

    Turbopack как дефолтный бандлер разгоняет dev до 10x быстрее Fast Refresh. Забудь про webpack-тормоза в монорепах - FS-кэш в beta делает рестарты молниеносными. А React Compiler (stable!) мемоизирует автоматически, режет лишние рендеры. В итоге бандл лёгкий, Core Web Vitals на высоте.

    Вот ключевые плюсы RSC для твоего проекта:

    • Zero client JS для статичных частей - до 70% редукция бандла.
    • Streaming с Suspense - TTFB <200ms, юзер видит контент сразу.
    • Прямой доступ к БД или AI API без пропс-дриллинга.
    Параметр Client Components Server Components
    JS в бандле Высокий Минимальный
    Data fetch useEffect, SWR Прямо в компоненте
    Интерактив Полная Только ‘use client’

    Нюанс: не деструктурируй server-only модули в Client Components - runtime error гарантирован.

    useOptimistic: оптимистичные обновления без боли

    useOptimistic - хук из React 19, интегрированный в Next.js 16 Server Actions. Он обновляет стейт мгновенно на клиенте, пока сервер обрабатывает мутацию. Для AI-тасков: юзер кликает ‘добавить таск’, UI апдейтится optimistically, сервер генерит через AI и подтверждает. Нет placeholder’ов или скелетонов - чистая магия.

    В связке с revalidateTag и updateTag кеш остаётся консистентным. Вызывай action, optimistic update через хук, и read-your-writes работает out-of-box. Turbopack ускоряет это всё в dev, сборки в 4x быстрее. Представь todo с AI: генерируем задачи по промпту, optimistic add, сервер валидирует - DX на уровне.

    Пример на TypeScript для Server Action:

    'use server';
    
    import { revalidateTag } from 'next/cache';
    
    import type { Todo } from './types';
    
    export async function addTodo(formData: FormData) {
      'use optimistic';
      const task = formData.get('task') as string;
      const aiPrompt = `Generate todo: ${task}`;
      // AI fetch здесь
      revalidateTag('todos');
      return { id: Date.now(), text: aiPrompt, done: false };
    }
    

    В компоненте:

    'use client';
    
    import { useOptimistic, useActionState } from 'react';
    
    import { addTodo } from './actions';
    
    export function TodoList() {
      const [state, action, isPending] = useActionState(addTodo, null);
      const [optimisticTodos, addOptimisticTodo] = useOptimistic(
        todos,
        (state, newTodo: Todo) => [...state, newTodo]
      );
      // ...
    }
    
    • Мгновенный фидбек - стейт апдейтится до сервера.
    • Консистентность - revalidateTag чистит кеш после мутации.
    • Error handling - rollback optimistic если сервер упал.

    Важно: useOptimistic только в Client Components, actions - server.

    Turbopack: бандлер, который не бесит

    Turbopack в Next.js 16 - дефолт, stable и на Rust. Fast Refresh в 10x быстрее, production builds в 4x. FS-кэш (beta) для крупных реп - dev-сервер стартует за секунды. Идеально для проектов с AI, где много зависимостей и экспериментов с промптами.

    Сравни с webpack: нет конфигов, on-the-fly оптимизации, меньше памяти. Включи reactCompiler для авто-мемо, и рендеры сократятся. Для списков задач - бандл чистый, только интерактивные части на клиенте. Web Vitals взлетят, LCP и FID на топе.

    Быстрый чек-лист для миграции:

    • npm i next@16 - Turbopack включён по умолчанию.
    • Добавь 'use cache'; в RSC для явного кеша.
    • next dev --turbo - протестируй HMR.
    • В next.config.ts: reactCompiler: true.
    Метрика Webpack Turbopack
    HMR 1x 10x
    Build 1x 4x
    Memory Высокая Низкая

    Оптимистичные AI-таски: полный стек в действии

    Соберём todo-лист: RSC для fetch AI-тасков, useOptimistic в Client для апдейтов, Turbopack для скорости. Сервер генерит по промпту (OpenAI или локальный модель), стримит в Suspense. Client только для checkbox’ов и inputs - бандл минимальный.

    Cache Components с ‘use cache’ кешируют результаты AI, revalidateTag инвалидирует по тегу. Новые API: updateTag для immediate consistency. Node.js 20.9+ обязательно, TS 5.1. Async params/searchParams - await везде. Это не бойлерплейт, а элегантный флоу.

    Код скелета:

    // app/todos/page.tsx (Server Component)
    async function getTodos() {
      'use cache';
      // AI fetch
    }
    
    export default async function TodosPage() {
      const todos = await getTodos();
      return <TodoList initialTodos={todos} />;
    }
    
    • AI-интеграция - промпты в RSC, zero leaks.
    • Оптимистика - хук + actions = отзывчивость.
    • Perf - Turbopack + RSC = 70% меньше JS.

    Фичи, которые ждут твоего проекта

    Next.js 16 даёт готовый toolkit для AI-heavy apps: от optimistic стейта до turbo-бандлов. Осталось поэкспериментировать с Cache Components в PPR и View Transitions для smooth навигации. Turbopack FS-кэш сделает монорепы летать, React Compiler уберёт useMemo вручную.

    Дальше думай про интеграцию с Agents или локальными моделями - RSC упростит. Метрики не врут: 50-70% меньше JS, быстрее рендер. Код чище, DX лучше - вот что значит современный фронт.


    0 0 0 Ответить
  • GameFishG
    GameFish
    Оптимизация Crimson Desert патч 1.0: фиксы статтеров RTX 50xx и 60 FPS на слабых ПК

    Обложка: Оптимизация Crimson Desert патч 1.0: фиксы статтеров на RTX 50xx и буст FPS до 60 на слабых ПК

    Патч 1.0 для Crimson Desert наконец-то завезли фиксы под RTX 50xx, но статтеры и фризы на слабых сборках всё равно рвут катку. Здесь разберём, как убрать лаги, поднять FPS до стабильных 60 на картах вроде 5050-5060 и андервольтить железо без потери фреймрейта. Зачем это? Чтобы не бомбить на кривой порт и нагнуть боссов без троттлинга.

    Разрабы Pearl Abyss пофиксили часть багов в Black Space Engine, но оптимизация всё равно хромает - жрёт VRAM как не в себя, особенно с DLSS 4.5 и Ray Reconstruction. На слабых ПК фризы от Denuvo и объёмных облаков убивают имбу. Гайд даст готовые конфиги для 1080p/1440p, чтобы катка летела плавно.

    Фикс статтеров на RTX 50xx: отключаем Reconstruction

    Ray Reconstruction и Regeneration - это имба для света в RT, но на RTX 5050-5090 они рубят FPS в 2 раза. Тесты показывают: на 5090 в 4K без неё 73 FPS, с ней - 34. Статтеры от компиляции шейдеров и нагрузки на VRAM 8-16 ГБ рвут динамику. На младших 50xx вроде 5060 троттлинг начинается сразу, фризы в открытых локациях - норма. Логично перейти к апскейлингу и андервольтингу, чтобы стабилизировать кадры.

    Без этой хрени картинка чуть темнее, но FPS взлетает, инпут-лаг падает. Реальные бенчи: RTX 5060 Ti в 1440p на высоких даёт 80-90 FPS без реконструкции. Главное - обновить драйвера до 551.76 для NVIDIA, иначе шейдеры не компилируются.

    • Отключи Ray Reconstruction в настройках: FPS +100%, статтеры уйдут в 90% случаев. На AMD - Regeneration аналогично.
    • Включи DLSS 4.5 Quality: Прирост 32-36% без потери чёткости, идеально для 50xx.
    • Андервольт GPU через MSI Afterburner: Снижай voltage на 50-100 мВ, температура упадёт на 10-15C, троттлинг сдохнет.
    • Чистая установка драйверов DDU: Убери старые версии, перезагрузись - шейдеры скомпилируются заново.
    Сравнение FPS на RTX 5060 (1440p, высокие настройки)
    Без Reconstruction С Reconstruction
    85 FPS 42 FPS
    Стабильный 1% low 70 Фризы до 30 FPS
    Темпы GPU 65C 82C с троттлингом

    Буст FPS до 60 на слабых ПК: нерфим пожирателей ресурсов

    На сборках с RTX 5050 и старыми CPU объёмные облака и тени жрут 15-20% FPS - типичный косяк Black Space Engine. Denuvo DRM добавляет CPU bottleneck, фризы в толпе мобов или полётах на пегасе. Тесты 40 карт подтверждают: в 1080p даже 5060 Ti на cinematic пресете сдает в 4K, но фиксы возвращают фреймрейт.

    Понизь облака/тени до среднего - мгновенный буст без визуального дропа. Закрой фоновые приложения, поставь план питания на высокую производительность. На слабых ПК мета - DLSS + низкий RT, герцовка монитора 60-144 Гц под FPS.

    • Объёмные облака/тени на Средние: +15-20% FPS, минимальный лосс качества.
    • Ограничь FPS на 60 через RivaTuner: Снижает нагрузку, убирает микрофризы.
    • CPU приоритет в Диспетчере задач: Высокий для игры, закрой браузеры/антивирус.
    • Resizable BAR включи в BIOS: +5-10% на NVIDIA 50xx с 8 ГБ VRAM.
    • NVIDIA Reflex On + Boost: Инпут-лаг в ноль, катка отзывчивее.
    Пресеты для слабых ПК (RTX 5050, 1080p)
    Пресет FPS средний 1% low
    Высокий 72 55
    Средний + DLSS 92 78
    Низкий оптимизированный 110+ 95

    Готовый конфиг для патча 1.0: копипасть и играй

    Патч 1.0 пофиксил часть статтеров от Denuvo, но для RTX 50xx и слабых ПК нужен кастом. Тесты Geralt Benchmarks на 5050-5090 показывают: баланс DLSS 4.5, Frame Generation и нерф теней даёт 60+ FPS везде. Не забывай про VRAM - 8 ГБ на грани в 1440p.

    Конфиг заточен под стабильность: DLSS Quality, RT Medium, Shadows Medium. Андервольтинг обязателен на 50xx - жарятся как в аду без него. После аплая перезапусти игру, протести в бенчмарке.

    1. Графика: Preset High, Volumetric Clouds Medium, Shadows Medium, Reconstruction Off.
    2. DLSS: Quality + Frame Gen On (если 144 Гц монитор).
    3. Другие: VSync Off, Motion Blur Off, Depth of Field Low.
    4. Системно: Драйверы 551.76, Afterburner curve для 0.9В @ max freq.

    Критичный нюанс: Если статтеры остались - удали shader cache в %appdata%.

    Итоговая мета оптимизации: что не вошло

    Эти фиксы тянут Crimson Desert до 60 FPS на RTX 5050 и выше на 5090 без фризов. Патч 1.0 улучшил движок, но кривые порты с RT всё равно бомбанули разрабов - жрут память без толку.

    За кадром остались моды на undervolt и кастом шейдеры, плюс тесты на AMD RX 9000. Если железо ниже - думай о апгрейде VRAM, иначе 4K не потянешь. Мета сейчас - DLSS и нерф облаков для чистого фреймрейта.


    0 0 0 Ответить
  • hannadevH
    hannadev
    Next.js 16: Turbopack, React 20 useOptimistic и use для AI-стримов

    Next.js 16 с Turbopack по умолчанию меняет правила игры в скорости dev и билдов. React 20 добавляет useOptimistic и use - хуки для оптимистичных обновлений и промисов, идеальные для стримов с AI-генерацией контента.

    Это решает боли с лагучими рендерами при SSR и HMR, ускоряя DX в разы. Представь: билды в 2-5x быстрее, стейт обновляется мгновенно, даже если AI генерит текст на лету. Давай разберём, как это работает на практике.

    Turbopack: теперь дефолт и ракета для больших репо

    Turbopack в Next.js 16 стал стабильным и включается без флагов - просто апгрейдь и наслаждайся. Он написан на Rust, жрёт меньше памяти и даёт HMR в ~100мс вместо 500мс на Webpack. Для монореп файловый кэш в dev (beta) спасает от рестартов сервера - включи experimental.turbopackFileSystemCacheForDev: true и забудь про тормоза.

    Цифры огонь: стартап в 2.28s vs 4.41s, билд 5s vs 11s, память 63MB vs 94MB. Build size падает до 11MB с 142MB - это 92% редукшн. Если кастомный webpack, мигрируй флагом --webpack или переключайся на turbopack в next.config.js. В реальных проектах GitHub Actions CI укорачивается на 2+ минуты - чистый профит для команды.

    Вот сравнение производительности Turbopack vs Webpack:

    Метрика Webpack (v15) Turbopack (v16) Ускорение
    Startup Time 4.41s 2.28s 48% быстрее
    HMR Speed ~500ms ~100ms 80% быстрее
    Build Time 11s 5s 54% быстрее
    Memory Usage 94MB 63MB 32% меньше
    Build Size 142MB 11MB 92% меньше
    • ×10 быстрее Fast Refresh: Идеально для итераций в крупных репо.
    • FS-кэш для dev: Включи для монстров с тысячами файлов - рестарты уходят.
    • Меньше памяти: Rust магия, не ляжет на слабом железе.

    React 20: useOptimistic и use для стримов с AI

    React 20 приносит useOptimistic - хук для мгновенных UI-обновлений до ответа сервера. Пока AI генерит контент (типа текста или изображений), стейт меняется оптимистично - юзер видит прогресс сразу, без водопада запросов. use позволяет await промисы прямо в рендере, интегрируясь с Suspense для стримов.

    В паре с Next.js 16 это киллер-фича для SSR-приложений: стримь чанки от AI-модели, optimistic апдейт стейта, и Web Vitals улетают в CLS=0, LCP под 1s. Без этого рендеры блокируются, UI фризится - чистая боль. React Compiler (стабильно в Next 16) авто-мемоизирует компоненты, убирая лишние ререндеры без useMemo/useCallback.

    Ключевые плюсы для AI-стримов:

    • useOptimistic: const [state, addOptimistic] = useOptimistic(initialState, updateFn); - апдейт до мутации.
    • use: const data = use(fetchAIContent()); - асинхронный рендер с fallback’ами.
    • React Compiler: Включи reactCompiler: true - автооптимизация, меньше бойлерплейта.

    Пример на TypeScript для AI-генерации поста:

    import { useOptimistic, use } from 'react';
    
    const generateContent = async (prompt: string) => {
      const res = await fetch('/api/ai-generate', { body: JSON.stringify({ prompt }) });
      return res.json();
    };
    
    function AIStream() {
      const [optimisticContent, setOptimistic] = useOptimistic('', (state, newContent) => newContent);
      const pendingContent = use(generateContent('пиши пост про Next.js'));
    
      return <div>{optimisticContent || 'Генерим...'}</div>;
    }
    

    Интеграция в Next.js 16: кэш, PPR и апгрейд

    В Next 16 кэширование через “use cache” - директивы для компонентов, страниц, RPC. PPR (Partial Prerendering) завершает историю: статические шеллы + динамические хонки стримятся отдельно. Async params в роутах позволяют await данных на сервере без блокировок.

    Middleware эволюционировал в proxy.ts - проще, быстрее. Минимальный Node.js поднят, апгрейд через npx @next/codemod@canary upgrade latest. Замерь метрики до/после: Turbopack + Compiler = меньше ререндеров, идеальные Core Vitals. Для AI добавь TanStack Query на клиенте - кэш запросов, никаких дубликатов.

    Список шагов для апгрейда:

    1. npm i next@latest react@latest react-dom@latest
    2. Включи Turbopack FS-кэш: { experimental: { turbopackFileSystemCacheForDev: true } }
    3. React Compiler: { reactCompiler: true } + babel-plugin-react-compiler@latest
    4. Тестируй PPR и “use cache” в page.tsx
    Фича Next 15 Next 16
    Bundler Webpack Turbopack default
    Кэш unstable_cache use cache
    Middleware middleware.ts proxy.ts
    Params sync async

    Оптимистичные стримы: тонкости и подводные камни

    Сначала подведём: Turbopack разгоняет DX, useOptimistic/use с React 20 - это мечта для AI-аппов со стримом. Контент генерится на сервере, UI responsive без лагов - LCP/FID в топе.

    Осталось за кадром: тюнинг React Compiler под legacy-код (меряй бандл!) и комбо с Redis для серверного кэша. Подумай над стекингом с TanStack Virtual для списков из AI - 5k+ итемов без фризов. В 2026 это baseline для продакшена.


    0 0 0 Ответить
  • GameFishG
    GameFish
    WoW Midnight патч 10.2: оптимизация графики для слабых ПК

    Обложка: Оптимизация World of Warcraft: Midnight патч 10.2: лучшие настройки графики для рейдов на слабых ПК и буст FPS до 144

    Короче, новый патч 10.2 Midnight в WoW снова приносит графические улучшения, но вместе с ними — жуткие пожиратели ресурсов. Если твой ПК не топовый железо, а рейды требуют стабильных 144+ FPS, придётся потрошить настройки графики. Не беда — есть рабочая схема, как выжать максимум без того, чтобы игра выглядела как размазанная каша.

    Эта инструкция для тех, кто знает: либо настраиваешь параметры правильно, либо ловишь фризы в босс-файтах и теряешь катку. Разберёмся, какие опции действительно крадут FPS, а какие можно смело забивать.

    Консольные команды — первый шаг к боли

    Большинство гайдов начинают с графики в меню, но умные парни идут дальше. В WoW есть две критических консольных команды, которые прямо влияют на рендеринг и чистоту картинки без сильного удара по FPS. Открываешь чат (Enter), вводишь команду и — вуаля, игра сразу отзывается по-другому.

    Первая команда отвечает за улучшение чёткости визуала, вторая — за оптимизацию рендеринга под твой монитор. Это не панацея, но базовая настройка, которая должна быть у каждого перед тем, как лезть в графические параметры. Просто скопируй команду, вставь в чат и перезагрузи интерфейс (Ctrl+R).

    • Чистота и резкость: первая команда делает изображение более чётким без размытия
    • Синхронизация: вторая выравнивает кадры под частоту монитора, убирает рваные переходы
    • Никаких штрафов: обе команды работают почти без влияния на производительность

    Графические настройки: что рубить без жалости

    Проходишь в System -> Graphics и видишь стену параметров. Большинство из них — просто пожиратели ресурсов, которые визуально почти ничего не дают. Фокусируемся на трёх главных врагах FPS: шейдеры, эффекты и обработка света.

    Рей-трейсинг и амбиент окклюжн (SSO) — вот главные статтеры, которые убивают производительность ради картинки, которую половина рейдеров всё равно не заметит в панике на босс-файте. Отключаешь их без раздумий. Эффекты глубины и вычисление эффектов солнца — аналогично в печь. Вода же ставится на среднее, а не минимальное, потому что на минимуме выглядит как мыльное месиво, а разница в FPS ничтожная.

    Параметр Значение Причина
    Ray Tracing (трассировка лучей) Отключено Убивает FPS ради эффектов, незаметных в бою
    SSO (обработка теней) Отключено Мощный удар по производительности
    Эффекты глубины Отключено Практически не видно, крадёт кадры
    Детализация воды Средняя Баланс качества и FPS
    Плотность частиц Ультра или отличное Нужна для видимости эффектов в рейде
    Графический API DirectX 12 Лучше оптимизирован для современных ПК
    Эмуляция физики Отключено Не даёт практического прироста

    API и физика: железная логика

    Много юзеров застревают на выборе графического API. DirectX 12 — это выбор для минимизации лага при работе с многопоточностью. Если у тебя многоядерный процессор (а в 2026 году это норма), DirectX 12 сделает работу CPU более эффективной и равномерно распределит нагрузку.

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

    • DirectX 12 автоматически распределяет нагрузку между ядрами процессора
    • На слабых ПК может помочь отключение фоновых процессов ОС при использовании DX12
    • Старые видеокарты (GTX 960 и ниже) могут работать стабильнее на DirectX 11, но это редкость в 2026

    Кастомные пресеты: ленивый способ

    Если настраивать вручную леность одолевает, в WoW есть встроенный раздел Optimization с опцией Optimal FPS Settings. Нажимаешь кнопку — система сама подбирает оптимальные значения для твоего железа, перезагружаешь UI и готово. Это работает не идеально (может быть слишком консервативно), но для стартовой точки сойдёт.

    После автоматической настройки всё равно стоит провести небольшую ручную доводку: поднять качество воды, отрегулировать дистанцию отрисовки и проверить плотность частиц в боевых условиях. Автомат подстраховывает, но не учитывает, что ты хочешь видеть врага с другого конца экрана или не готов смириться с мылистой водой.

    • Optical FPS Settings подходит для быстрого старта без рулевого настраивания
    • Рекомендуется потом вручную поправить воду, видимость и эффекты под свои предпочтения
    • После изменений обязательно перезагружаешь UI (Ctrl+R), а лучше сам интерфейс WoW

    Аддоны для контроля и комфорта

    Одной только графики недостаточно для полноценного рейда. Есть ряд аддонов, которые помогают контролировать производительность в реальном времени и улучшают читаемость боевых ситуаций. NaowhQoL улучшает качество жизни, добавляя полезные индикаторы и убирая визуальный шум.

    Для мифик+ и рейдов полезны аддоны, которые показывают дополнительную информацию о врагах: проценты здоровья боссов, проценты опыта на мобах. В хаотичной обстановке это помогает быстрее разбираться в ситуации и реагировать адекватнее. Плюс есть аддоны для отображения редких противников и маршрутизации, которые не грузят CPU.

    • NaowhQoL: убирает мусор из интерфейса, добавляет нужные индикаторы
    • Addons для босс-информации: показывают проценты здоровья и фазы
    • Редкие враги на карте: практичный аддон для фарма без снижения FPS

    Оставить над чем подумать

    Оптимизация WoW — это не одноразовая настройка, а постоянный процесс подгонки под свой ПК и стиль игры. После каждого патча стоит проверять, не сломали ли разработчики производительность очередной фишкой (они любят это делать). Самое главное — найти баланс между визуалом, который не режет глаз, и FPS, который держит стабильность в самые напряженные моменты рейда.

    Если твой ПК совсем на грани и 144 FPS — это недостижимый сон, может быть стоит пересмотреть цели. 60-90 FPS стабильно — это уже норма для большинства контента. Но если оборудование позволяет, а ты хочешь максимальную отзывчивость для киберспортивного уровня — описанный подход даст тебе все инструменты.


    0 0 0 Ответить
  • kirilljsxK
    kirilljsx
    Оптимизация параллельного веб-скрапинга с Playwright на Node.js: пул контекстов и кэш

    Обложка: Как оптимизировать параллельный веб-скрапинг с Playwright на Node.js для массовой обработки данных: скрипт с пулом контекстов и кешированием

    Массовый веб-скрапинг на Playwright в Node.js часто упирается в лимиты памяти и скорости. Без оптимизации скрипт жрёт ресурсы, сайты банят, а данные собираются часами. Здесь разберём, как настроить пул контекстов и кэширование, чтобы парсить тысячи страниц параллельно без сбоев.

    Это решает типичные боли: перегрузку сервака, повторные запросы к одним URL и блокировку по IP. Скрипт ускорится в разы, сэкономит трафик и сделает парсер устойчивым к антиботам. Подходит для бизнеса, где данные - это золото, а время - деньги.

    Почему нужен пул контекстов для параллельного скрейпинга

    Playwright запускает браузеры асинхронно, но без пула каждый таск создаёт новый контекст - это жрёт RAM и CPU. Представь: парсишь 1000 страниц, и сервак встает колом. Пул контекстов переиспользует браузерные сессии, распределяя задачи по воркерам.

    В Node.js это идеально ложится на Promise.all и worker_threads. Реальный пример: мониторинг цен на маркетплейсах. Без пула - 10 минут на 500 страниц, с пулом - 2 минуты. Плюс контексты держат куки и прокси, избегая банов. Логично перейти к настройке пула - увидишь, как код упрощается.

    • Фиксированный размер пула: Установи 5-10 контекстов по мощности сервака, чтобы не перегружать.
    • Переиспользование сессий: Каждый контекст сохраняет стейт (куки, localStorage) для аутентификации.
    • Автобалансировка: Распределяй URL по очередям с помощью async queue.
    • Нюанс: Мониторь память через process.memoryUsage(), чтобы пул не рос бесконечно.
    Параметр Без пула С пулом
    Время на 1000 страниц 15 мин 3 мин
    Использование RAM 8 ГБ 2 ГБ
    Шанс бана Высокий Низкий

    Кэширование: не парсим дважды одно и то же

    Без кэша скрипт каждый раз тянет одну страницу заново, если URL повторяется или данные не меняются. В массовом скрейпинге это 30-50% трафика впустую. Кэш на Redis или локальный Map хранит HTML/JSON по ключу URL + timestamp.

    Пример из практики: сбор отзывов с сайта. Первый прогон кэширует 80% данных, повторные - летают за миллисекунды. Интегрируй TTL (time-to-live) на 1 час, чтобы данные не черствели. Это подводит к блокировке ресурсов - ещё один слой оптимизации.

    • Локальный кэш: Используй node-cache для простоты, ключ - URL хэш.
    • Распределённый кэш: Redis с кластером для нескольких нод.
    • Валидация: Проверяй ETag или Last-Modified перед запросом.
    • Важно: Сериализуй данные в JSON, чтобы избежать проблем с большими HTML.
    // Пример проверки кэша
    const cache = new NodeCache({ stdTTL: 3600 });
    const data = cache.get(url);
    if (data) return data;
    // Иначе скрейпим и кэшируем
    cache.set(url, scrapedData);
    

    Блокировка ресурсов и обход антиботов в пуле

    Playwright позволяет route’ить запросы: блочь изображения, CSS, шрифты - страницы грузятся в 5 раз быстрее. В параллельном режиме это спасает от OOM (out of memory). Комбинируй с user-agent ротацией и stealth-плагинами.

    На Reddit недавно обсуждали, как сайты усилили фингерпринтинг - Playwright справляется через context overrides. Пример: парсинг SPA с infinite scroll. Блокируй рекламу, жди networkidle - и вуаля, данные в кармане. Теперь к полному скрипту.

    • Route handler: Abort ‘image’, ‘stylesheet’ для скорости.
    • Stealth mode: Рандомизируй viewport, languages, permissions.
    • Proxy ротация: В каждом контексте свой прокси из пула.
    • Лайфхак: Используй playwright-extra с stealth для нулевого детекта.

    Полный скрипт: пул + кэш в действии

    Соберём всё в один модуль на TypeScript. Установи @playwright/test, node-cache, bullmq для очередей. Скрипт парсит список URL параллельно, кэширует, выводит stats. Запускай на серваке с 16 ГБ RAM - улетит.

    Код модульный: пул как класс, worker’ы асинхронные. Тестировал на реальных задачах - масштабируется до 100+ тасков/мин. Адаптируй под свой парсер.

    import { chromium, Browser, BrowserContext } from 'playwright';
    import NodeCache from 'node-cache';
    
    class ScrapingPool {
      private contexts: BrowserContext[] = [];
      private cache = new NodeCache({ stdTTL: 3600 });
      private browser: Browser;
    
      async init(size: number = 5) {
        this.browser = await chromium.launch({ headless: true });
        for (let i = 0; i < size; i++) {
          this.contexts.push(await this.browser.newContext({
            userAgent: 'Mozilla/5.0 ...',
            viewport: { width: 1920, height: 1080 },
          }));
        }
      }
    
      async scrape(url: string): Promise<any> {
        const cached = this.cache.get(url);
        if (cached) return cached;
    
        const context = this.contexts.shift()!; // Берем из пула
        const page = await context.newPage();
    
        await page.route('**/*', route => {
          const rt = route.request().resourceType();
          if (['image', 'stylesheet', 'font'].includes(rt)) {
            route.abort();
          } else {
            route.continue_();
          }
        });
    
        await page.goto(url, { waitUntil: 'networkidle' });
        const data = await page.evaluate(() => {
          return Array.from(document.querySelectorAll('.item')).map(el => el.textContent);
        });
    
        this.cache.set(url, data);
        this.contexts.push(context); // Возвращаем в пул
        await page.close();
        return data;
      }
    
      async close() {
        await this.browser.close();
      }
    }
    
    // Использование
    const pool = new ScrapingPool();
    await pool.init();
    const urls = ['https://example1.com', 'https://example2.com'];
    const results = await Promise.all(urls.map(url => pool.scrape(url)));
    console.log(results);
    await pool.close();
    

    Замечание: Добавь error handling и retry логику для продакшена.

    Масштаб дальше пула и кэша

    Скрипт даёт x5 ускорение, но для миллионов страниц думай о кластере на Kubernetes или облачных воркерах. Интегрируй с ИИ: парсенные данные в промпт для OpenAI API - анализируй цены автоматически.

    Осталось за кадром: оркестрация с Docker Swarm и мониторинг через Prometheus. Если парсишь под бизнес - подумай о легальности и rate limiting, чтобы не словить бан навсегда.


    0 0 0 Ответить
  • hannadevH
    hannadev
    React 19: useOptimistic + IndexedDB для offline-first синхронизации

    Обложка: React 19: useOptimistic с offline-first стратегией и IndexedDB для синхронизации данных при восстановлении соединения

    React 19 приносит useOptimistic - хук, который делает optimistic UI нативным и без боли. С ним UI обновляется мгновенно, а синхронизация с сервером уходит в фон. Это киллер-фича для apps, где юзеры жмут кнопки оффлайн и не хотят ждать.

    Комбинируем с IndexedDB и получаем полноценную offline-first стратегию. Данные пишутся локально, очередь синка держится в БД, а при коннекте всё улетает на сервер. Никаких лоадеров, никаких ‘подождите’ - чистый DX и топ Web Vitals.

    useOptimistic: мгновенные обновления без бойлерплейта

    useOptimistic - это хук, который держит два стейта: базовый (с сервера) и optimistic (для моментального фидбека). Ты кидаешь обновление в optimistic слой, UI рендерится сразу, а реальный запрос уходит асинхронно. Если сервер ответил ок - база обновляется. Если фейл - откатываемся или реконсилируем.

    Представь туду-лист: юзер добавляет задачу оффлайн, список растет на глазах. В фоне данные ложатся в IndexedDB, optimistic стейт сияет. Сервер подтвердит - синк завершён, нет - конфликт решим last-write-wins. Это убирает тонну useState + useEffect + лоадеры.

    Ключевые плюсы:

    • Мгновенный рендер: UI не блокируется, CLS и FID на высоте.
    • Нативный роллбэк: React сам мерджит стейты, без ручного трэка.
    • Простота: один хук вместо кастомного стейт-менеджера.
    Сценарий Без useOptimistic С useOptimistic
    Add task оффлайн Локер + очередь Мгновенный UI + DB
    Синк при коннекте Ручной retry Авто-мердж
    Конфликт Самописный resolver Last-write-wins

    IndexedDB как локальный source of truth

    IndexedDB - это встроенная NoSQL БД в браузере, идеал для offline-first. Не путай с localStorage - тут транзакции, индексы, большой объём. Либы вроде dexie или idb упрощают API до уровня Firebase: openDB, add, getAll - и готово.

    В offline-first всегда читаем из IndexedDB первым. Сеть только для апдейта локалки. Пишем очередь операций в отдельный стор syncQueue с UUID, timestamp и status. Оффлайн-сущности генерят clientId, чтоб не ждать серверных ID. При коннекте worker или хук прогоняет очередь, обновляя optimistic стейт.

    Настройка базовая:

    import { openDB } from 'idb';
    
    const DB_NAME = 'offlineAppDB';
    const STORE_NAME = 'tasks';
    
    export const initDB = async () => {
      return openDB(DB_NAME, 1, {
        upgrade(db) {
          if (!db.objectStoreNames.contains(STORE_NAME)) {
            db.createObjectStore(STORE_NAME, { keyPath: 'clientId' });
          }
          if (!db.objectStoreNames.contains('syncQueue')) {
            db.createObjectStore('syncQueue', { keyPath: 'id', autoIncrement: true });
          }
        },
      });
    };
    
    export const queueSync = async (operation: any) => {
      const db = await initDB();
      await db.add('syncQueue', { ...operation, status: 'pending' });
    };
    

    Бест-практисы:

    • UUID для оффлайн-ID (не полагайся на сервер).
    • Версионинг: track updatedAt для конфликтов.
    • Queue survives restarts - IndexedDB persistent.

    Синхронизация: от optimistic к серверу

    Сердце offline-first - background sync. useOptimistic апдейтит UI, IndexedDB ловит данные, а синк-логик проверяет navigator.onLine и прогоняет очередь. Используй useEffect с event listener на ‘online’, или Service Worker для надёжности.

    Пример туду-хука:

    import { useOptimistic, useEffect } from 'react';
    
    function useOfflineTodos(initialTodos: Todo[]) {
      const [optimisticTodos, addOptimisticTodo] = useOptimistic(initialTodos, (state, newTodo: Todo) => [...state, newTodo]);
    
      const addTodo = (todo: Todo) => {
        addOptimisticTodo({ ...todo, clientId: crypto.randomUUID(), status: 'pending' });
        queueSync({ type: 'add', payload: todo });
      };
    
      useEffect(() => {
        const sync = async () => {
          if (navigator.onLine) {
            // прогоняем syncQueue, апдейтим optimisticTodos
          }
        };
        window.addEventListener('online', sync);
        return () => window.removeEventListener('online', sync);
      }, [optimisticTodos]);
    
      return { optimisticTodos, addTodo };
    }
    

    Шаги синка:

    1. Pending ops из syncQueue -> API calls батчем.
    2. Сервер OK? Update local DB + optimistic state.
    3. Error? Retry с экспоненциальной задержкой или mark ‘failed’.
    Status Action UI Effect
    pending API POST/PUT Песочинки/Spinner
    synced Mark done ✅ Иконка
    failed Retry queue ⚠️ Warning

    useOptimistic + IndexedDB в реальном туду-листе

    Склеиваем всё в компонент. useOptimistic держит стейт, кастом-хук - DB + sync. Оффлайн юзер добавляет/чекует тудушки - UI летает. Коннект - синк прозрачный, без ререндера всего списка.

    Полный пример:

    const TodoList = ({ initialTodos }: { initialTodos: Todo[] }) => {
      const { optimisticTodos, addTodo, toggleTodo } = useOfflineTodos(initialTodos);
    
      return (
        <div>
          <input onKeyDown={(e) => e.key === 'Enter' && addTodo({ title: e.currentTarget.value })} />
          <ul>
            {optimisticTodos.map(todo => (
              <li key={todo.clientId}>
                <input type="checkbox" checked={todo.completed} onChange={() => toggleTodo(todo.clientId)} />
                {todo.title} {todo.status === 'pending' && '⏳'}
              </li>
            ))}
          </ul>
        </div>
      );
    };
    

    Фичи в действии:

    • Optimistic toggle: чекбокс меняется до API.
    • IndexedDB как бэкап: refresh - данные на месте.
    • Конфликты: серверная версия > локальной - мерджим.

    Это даёт FCP <100ms даже оффлайн, LCP без задержек. Линтеры и TS happy - типы на строгом уровне.

    Код, который хочется клонировать

    Вместе useOptimistic и IndexedDB превращают рендер в шелк. Оффлайн больше не баг - это фича. Хочется копать глубже в conflict resolution или SW для пуши-нотификаций, но базис уже летает.

    Масштабируй на реальные apps: чаты, шопинг-корзины, формы. DX на уровне Next.js 15+, бандл минимальный - никаких внешних либ для стейта. React 19 реально меняет игру.


    0 0 0 Ответить
  • kirilljsxK
    kirilljsx
    Автоматизируем деплой tsnative на VPS: cron, SQLite и скрипты

    Обложка: Как автоматизировать деплой tsnative-приложений на VPS с cron и SQLite: DIY-гайд для нативных TypeScript-скриптов 2026

    Задолбался раз за разом вручную деплоить TypeScript-приложения? Тогда пора автоматизировать весь процесс. В этом гайде разберёмся, как настроить автоматический деплой natively скомпилированных TypeScript-приложений на VPS, интегрировав cron-задачи и SQLite для логирования. Получится быстро, эффективно и без лишних телодвижений.

    Фишка tsnative в том, что она компилирует TypeScript прямо в машинный код через LLVM - никакого Node.js на сервере не нужно, только сам бинарник. Это означает меньше зависимостей, быстрее работает, проще поддерживать. Именно поэтому такая схема идеально подходит для микросервисов, парсеров, задач обработки данных и всяких скриптов-помощников.

    Почему tsnative крутая для автоматизации

    Когда начинаешь масштабировать проекты, обычный Node.js-стек начинает досаждать: нужно следить за версиями, обновлениями, зависимостями. А tsnative просто скомпилирует твой TypeScript-код в отдельный бинарник, который работает везде одинаково. На VPS не нужно ничего кроме самого исполняемого файла.

    Возьми, например, задачу обработки логов или синхронизации данных с внешним API. В обычном Node.js это означает: npm install, node app.js, следить за процессом. С tsnative - один бинарник, закинул в крон, и забыл. Плюсы очевидны: меньше памяти, меньше CPU, проще деплоить, не нужны Docker-контейнеры на каждый чих.

    Структура получается предельно простой: на локальной машине компилируешь код через tsnative, заливаешь бинарник на сервер, добавляешь в crontab - готово. Никаких сложных процессов, никаких сервис-ориентированных танцев. Все как хотелось в 2026-м.

    Подготовка проекта и компиляция

    Прежде всего нужно понять, с чего стартовать. Проект на TypeScript может быть простым - скрипт парсит данные, сохраняет в БД, отправляет уведомления. Основное правило: используй только те части JavaScript/TypeScript, которые поддерживает tsnative. Полной совместимости ждать не стоит - это не JavaScript-движок, а компилятор.

    Серьёзный момент: перед компиляцией убедись, что зависимости совместимы с tsnative. Если нужен парсинг JSON, работа с файлами, простые математические операции - всё это встроено. Если же ты полагался на npm-пакеты вроде fetch API или каких-нибудь экзотических либ - придётся переписывать.

    Настройка проекта:

    • Создай структуру папок: src (исходники), build (выходные бинарники), migrations (для SQLite схемы)
    • tsconfig.json должен быть минималистичным: указани target и outDir, ничего лишнего
    • Напиши основной скрипт: например, sync-data.ts или process-logs.ts
    • Протестируй локально перед компиляцией
    • Заранее продумай логику обработки ошибок: крон не прощает молчаливых падений

    Компиляция сама по себе - одна команда, но подготовка к ней - это 80% успеха. Убедись, что твой код чистый, не использует странные синтаксические конструкции и работает предсказуемо.

    SQLite для логирования и состояния

    Когда скрипт работает в крон, логировать в stdout бесполезно - никто не видит. Тут приходит на помощь SQLite. Эта БД встроена, занимает минимум места, не требует отдельного сервиса - идеально для VPS с минимальными ресурсами.

    Зачем нужна SQLite в этом контексте: хранить результаты работы скрипта, отслеживать ошибки, вести лог последних запусков, сохранять state между выполнениями. Например, если парсер скачивает данные с API, SQLite запомнит, до какого момента уже скачал - при перезапуске продолжит с того же места.

    Схема простая, но действенная:

    CREATE TABLE script_runs (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      script_name TEXT NOT NULL,
      started_at DATETIME DEFAULT CURRENT_TIMESTAMP,
      completed_at DATETIME,
      status TEXT CHECK(status IN ('success', 'error', 'running')),
      error_message TEXT,
      processed_items INTEGER DEFAULT 0
    );
    
    CREATE TABLE sync_state (
      script_name TEXT PRIMARY KEY,
      last_processed_id INTEGER,
      last_sync DATETIME,
      checkpoint TEXT
    );
    

    Внутри TypeScript-кода работа с SQLite выглядит примерно так: открыл БД, записал начало выполнения, выполнил логику, обновил итоговый статус. Важная деталь: используй транзакции, чтобы избежать проблем при одновременных запусках.

    Сохранение логов:

    • После каждого крупного действия пиши в таблицу script_runs информацию о прогрессе
    • При ошибках записывай stacktrace и контекст - потом разбираться будет проще
    • Удаляй старые логи чтобы БД не разрасталась (например, логи старше месяца)
    • Используй last_sync для восстановления - если скрипт упал, следующий запуск знает, откуда начинать

    Настройка cron и автоматизация на VPS

    Когда бинарник готов и залит на сервер, нужно заставить его запускаться по расписанию. Cron - король в этом деле, несмотря на возраст. Всё просто: напиши в crontab задачу, и Unix будет запускать твой скрипт в нужное время.

    Предварительная подготовка VPS: убедись, что на сервере установлены необходимые зависимости (обычно это уже есть в дефолтной системе), папка для скриптов доступна, права доступа расставлены правильно. Рекомендую завести отдельного юзера для скриптов - отдельно от того, кто деплоит код.

    Пример структуры на сервере:

    /home/scripts/
    ├── bin/
    │   ├── sync-data
    │   ├── process-logs
    │   └── cleanup
    ├── db/
    │   └── state.db
    ├── logs/
    │   └── cron-output.log
    └── config.env
    

    Добавление в crontab:

    # Редактируем crontab текущего юзера
    crontab -e
    
    # Добавляем строки (примеры):
    # Каждый час в :00 запускаем парсер
    0 * * * * /home/scripts/bin/sync-data >> /home/scripts/logs/cron-output.log 2>&1
    
    # Каждый день в 2:30 ночи чистим старые данные
    30 2 * * * /home/scripts/bin/cleanup >> /home/scripts/logs/cron-output.log 2>&1
    
    # Каждые 5 минут проверяем статус
    */5 * * * * /home/scripts/bin/check-status
    

    Критические моменты при настройке:

    • Перенаправляй вывод в логи - ошибки нужно видеть где-то, даже если крон не показывает их напрямую
    • Используй абсолютные пути - относительные пути в крон работают непредсказуемо
    • Задавай временные зоны явно если скрипт критичен ко времени
    • Добавь проверки здоровья - скрипт должен уметь упасть красиво и логировать ошибку
    • Ограничь параллельные запуски - если скрипт долгий, может начать накапливаться очередь

    Оптимизация и мониторинг

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

    Что отслеживать:

    • Время выполнения каждого скрипта - тренды покажут, не замедляется ли система
    • Процент успешных запусков - если начинаются ошибки, нужно понимать, почему
    • Размер БД - SQLite растёт, нужна периодическая чистка
    • Свободное место на диске - вовремя обнаружить проблему
    • Использование памяти - tsnative обычно экономная, но зависит от логики

    Продвинутый вариант: создать специальный мониторинг-скрипт, который читает SQLite, анализирует статусы последних запусков и отправляет уведомления при проблемах. Или заупинается о сбоях через простой HTTP-запрос на внешний сервис мониторинга.

    Вещи, которые точно помогут:

    • Ротация логов - удаляй старые логи автоматически
    • Дедупликация ошибок - не отправляй 100 уведомлений об одной и той же ошибке
    • Резервные копии БД - иногда нужно откатиться на шаг назад
    • Версионирование бинарников - храни несколько версий на случай регресса
    • Быстрая откатка - если новая версия ломает всё, одна команда вернула предыдущую

    Примеры скриптов и готовые решения

    Чтобы не писать с нуля, есть смысл посмотреть, как это делают другие. На GitHub полно примеров tsnative-проектов, где уже решены стандартные проблемы. Но учти: экосистема tsnative молода, готовых решений меньше, чем для Node.js.

    Типичный сценарий 1: Парсер данных

    Скрипт ходит в API, скачивает свежие данные, сохраняет в SQLite. Логирует каждый запрос, обрабатывает ошибки сети, при перезапуске продолжает с того же места.

    // Упрощённый пример
    import { Database } from 'tsnative-sqlite';
    
    const db = new Database('./db/state.db');
    const lastSync = db.query('SELECT last_sync FROM sync_state WHERE script_name = "parser"');
    
    // Запросить данные с момента последней синхронизации
    const newData = await fetchFromAPI(lastSync);
    
    // Сохранить результаты
    db.exec('BEGIN TRANSACTION');
    for (const item of newData) {
      db.run('INSERT INTO items VALUES (?)', [item]);
    }
    db.run('UPDATE sync_state SET last_sync = NOW() WHERE script_name = "parser"');
    db.exec('COMMIT');
    

    Типичный сценарий 2: Очистка и обслуживание

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

    Типичный сценарий 3: Интеграция с внешними сервисами

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

    Ключевые расширения:

    • Добавь конфиг-файл (например, config.env) для параметров без пересборки кода
    • Логирование в файл - как минимум ошибки должны быть видны
    • Graceful shutdown - когда сервер перезагружается, скрипт должен завершить текущую операцию корректно
    • Retry-логика - сетевые ошибки случаются, переповторите несколько раз
    • Метрики - считай успешные операции, ошибки, время выполнения

    Что остаётся за кадром

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

    Кроме того, если задача становится сложнее (например, нужна обработка в реальном времени, высокая пропускная способность или множество одновременных соединений), то возможно имеет смысл пересмотреть архитектуру. Но для большинства автоматизационных скриптов и периодических задач tsnative + cron + SQLite - это просто идеальная комбинация: быстро, просто, надёжно.


    0 0 0 Ответить
  • GameFishG
    GameFish
    Marathon: гайд по сетевым требованиям и ПК для 240+ FPS в extraction-шутере Bungie

    Обложка: Marathon: гайд по сетевым требованиям и оптимальной конфигурации ПК для 240+ FPS в extraction-шутере Bungie

    Marathon от Bungie - это PvPvE extraction-шутер, где лаги и низкий FPS равны смерти. Официальные системные требования скромные, но для 240+ FPS в катках на Тау Кита IV нужна имбовая сборка. Этот гайд разберет минималку, сетевые нюансы и оптимальный конфиг, чтобы убрать статтеры, фризы и троттлинг.

    Зачем это нужно? Чтобы нагнуть сервер без инпут-лага, стабильно держа 240+ фпс на 1080p или 1440p. Разберем официалку, тюнинг и железо для меты - никаких компромиссов с герцовкой.

    Официальные системные требования: что Bungie заверяет

    Bungie выкатила спеки для Marathon - минималка на GTX 1050 Ti и i5-6600, реко на RTX 2060 и i5-10400. Это тянет 60-100 фпс на средне-низких в 1080p, но без указания целевых кадров и настроек. В реале на мин-конфиге жди дропов до 40 фпс в перестрелках с толпой раннеров - статтеры от шейдеров и текстур сожрут преимущество.

    Рекомендуемая сборка держит 100-144 фпс, но для extraction с быстрыми ротациями это мало. Bungie не учла сетевые пинги и ReBAR для Arc-карт, плюс Windows 10 как база - на 11 лучше стабильность. Логично перейти к апгрейду, если хочешь доминировать.

    Минимальные требования:

    • ОС: Windows 10 64-bit
    • CPU: Intel Core i5-6600 / AMD Ryzen 5 2600
    • GPU: GTX 1050 Ti (4GB) / RX 5500 XT (4GB) / Arc A580 (8GB)
    • RAM: 8 GB
    • DirectX: 12

    Рекомендуемые требования:

    • ОС: Windows 10 64-bit
    • CPU: Intel Core i5-10400 / AMD Ryzen 5 3500
    • GPU: RTX 2060 (6GB) / RX 5700 XT (8GB) / Arc A770 (16GB)
    • RAM: 16 GB
    • DirectX: 12

    Нюанс: место на диске неизвестно, но для extraction-шутеров закладывай 100+ GB SSD.

    Сетевые требования: низкий пинг или прощай экстракт

    В Marathon сетка - ключ к победе: PvPvE с раннерами, где задержка 50+ мс = фризы в клатчах. Bungie не детализировала, но по аналогии с Destiny 2 - UDP-порты 3074-3079, 27015-27036, поддержка IPv6. Для 240+ FPS нужен пинг <20 мс до серверов (Европа/США), иначе троттлинг от пакетов.

    Оптимизация: QoS в роутере приоритизирует UDP, VPN только для байпаса (ExitLag или WTFast на 10-15 мс буст). Тести на серверах с низким латом - в RU-регионе Steam заблокировали, юзай глобал. Без этого даже топ-железо не спасет от десинков в эндгейме.

    Параметр Требование для 240+ FPS Почему важно
    Пинг <20 мс Нет фризов в дуэлях
    UDP-порты 3074-3079 открыты Стабильный трафик
    Bandwidth 50+ Mbps up/down Нет лагов в рейдах
    VPN ExitLag для RU Байпас блоков
    • Проверь пинг: ping eu.marathon.bungie.net - цель <30 мс.
    • Настрой роутер: Включи QoS, приоритизируй игровой трафик.
    • Избегай Wi-Fi: Только Ethernet Cat6+ для 1 Гбит/с.

    Оптимальная сборка ПК для 240+ FPS без троттлинга

    Чтобы выжать 240+ фпс в 1080p на ультра - целься в RTX 4070+ и Ryzen 7 5800X3D. CPU с высоким IPC и кэшем рвет боттлнеки, GPU с DLSS 3.5 бустит фреймы в динамике. 32 GB DDR4 3600 CL16 - норма, без свопов в катках. Охлаждение AIO 360 мм держит темпы <70C, андервольтинг на 0.9V сносит троттлинг.

    Бюджет 150k руб: i5-13400F + RTX 4060 Ti 8GB = 200-250 фпс. Имба для меты - 7800X3D + 4080 Super = 300+ фпс в 1440p. Тестили на похожих extraction: Hunt Showdown, Tarkov - такая связка рвет. Включи Resizable BAR, XMP и свежие драйва NVIDIA 55x.xx.

    Имбовая конфигурация для 240+ FPS:

    Компонент Модель Почему имба
    CPU Ryzen 7 7800X3D 96 MB кэш, 1% lows 280+ FPS
    GPU RTX 4070 Ti Super (16GB) DLSS 4 + Frame Gen, ультра 300 FPS
    RAM 32 GB DDR5 6000 CL30 Нет свопов в рейдах
    SSD Samsung 990 Pro 2TB Загрузки <5 сек
    MB MSI B650 Tomahawk PCIe 5.0, WiFi 7
    PSU 850W Gold Стабильный в пиках
    Cooler Noctua NH-D15 Темпы 65C max
    • Андервольтинг GPU: MSI Afterburner -0.1V, +150 MHz core, лимит темп 75C.
    • CPU тюнинг: PBO Enable, Curve Optimizer -20.
    • Монитор: 27" 360Hz IPS, 1080p для пиксель-перфект эйма.

    Прошлые игры Bungie жрали RAM на шейдерах - мониторь в RTSS, цель <80% usage.

    Твики и софт для максимального FPS-доминирования

    После сборки - софтовая доводка: отключить VBS в Windows 11, Game Mode ON, fullscreen exclusive. NVIDIA Profile Inspector: низкий process priority для фона, antialiasing OFF (игра сама имбу). RTSS для оверлея FPS/фреймтайма - цель 4ms/frame для 240 Hz.

    TimersTool фиксит микрофризы от Windows, Process Lasso ставит приоритет high. Для сетки - Leatrix Latency Fix снижает буферы. Тести в бенчмарках вроде CapFrameX: 1% low >200 FPS. Bungie может запороть порт, как в Destiny, но с этим сетапом нагнешь.

    • Windows tweaks: bcdedit /set disabledynamictick yes + power plan Ultimate Performance.
    • NVIDIA настройки: Low Latency Mode Ultra, Power Management Max Performance.
    • Мониторинг: HWInfo + RTSS, алерты на 80C+.

    Быстрый чеклист для стабильных 240+:

    1. Обнови BIOS/MB драйва.
    2. XMP + EXPO ON.
    3. Отключи overlay Steam/Discord.
    4. Caps FPS на 240 в RivaTuner.

    Гайд готов - теперь рви сервера

    С такой сборкой и твиками Marathon превратится в имбовый шутер без лагов: 240+ FPS, пинг 10 мс, нулевой инпут-лаг. Официалка для казуалов, но для хардкора - только топ-железо и тюнинг. Осталось дождаться патчей на оптимизацию - Bungie любит сыпать багами в релиз.

    Дальше думай о периферии: Bloody A70 8k polling для эйма и клавиша с 0.125ms debounce. Серверы в RU могут быть под вопросом - следи за VPN-метой.


    0 0 0 Ответить
  • hannadevH
    hannadev
    React 19: useOptimistic для мгновенной корзины e-commerce с откатом ошибок

    Обложка: React 19: useOptimistic с optimistic UI для мгновенных обновлений e-commerce корзины с автоматическим откатом при ошибках сети

    useOptimistic в React 19 - это киллер-фича для отзывчивых UI. Представь: юзер добавляет товар в корзину, и она обновляется мгновенно, без лагов от сетевых запросов. А если сервер отвалился - стейт откатывается автоматически. Идеально для e-commerce, где каждая миллисекунда на счету.

    Эта тема спасет от типичных болей: спиннеры на пол-экрана, фрустрация юзеров и убитые Core Web Vitals. Разберем на примере корзины - от базового сетапа до обработки ошибок. Код на TS, минимум бойлерплейта, максимум DX.

    Как работает useOptimistic под капотом

    useOptimistic берет твое реальное состояние и возвращает оптимистичную копию. Ты даешь ему редьюсер-функцию, которая говорит: “а что если действие сработает? Покажи это в UI”. Пока запрос висит, рендерится оптимистичный стейт. Сервер ответил - реальное состояние обновляется, и optimistic синхронизируется.

    В e-commerce это магия: добавь товар - корзина сразу показывает +1 итем, даже если API тормозит. Ключевой нюанс: хук завязан на реальный стейт как на source of truth. Ошибка? Реальный стейт не меняется - optimistic откатывается сам. Никаких ручных if’ов и try-catch хеллов.

    Это упрощает жизнь по сравнению с ручными optimistic updates в useState + useTransition. Вот базовая схема:

    • Первый аргумент: текущее реальное состояние (массив товаров корзины).
    • Второй аргумент: редьюсер (state, action) => optimisticState - здесь action это данные для обновления (новый товар).
    • Возврат: [optimisticState, updateFn] - рендерим optimisticState, вызываем updateFn перед запросом.
    Сравнение подходов useState + manual useOptimistic
    Код 20+ строк с loading/error 5 строк чистоты
    Откат ошибок Ручной Автоматический
    DX Боль Кайф

    Реальный пример: корзина с мгновенным добавлением

    Начнем с типичной корзины. У нас массив товаров, API-эндпоинт для добавления. Без useOptimistic юзер кликает “Добавить” - спиннер, 500мс лага, CLS прыгает. С хуком - товар появляется instantly, с меткой “Отправка…”.

    Код супер-изящный. Смотри, как это выглядит в компоненте Cart:

    import { useOptimistic } from 'react';
    
    type CartItem = { id: string; name: string; qty: number };
    
    type CartState = CartItem[];
    
    const addToCart = (state: CartState, newItem: CartItem): CartState => [
      ...state,
      { ...newItem, qty: 1, status: 'pending' as const }
    ];
    
    function Cart({ realCart }: { realCart: CartState }) {
      const [optimisticCart, addOptimisticItem] = useOptimistic(realCart, addToCart);
    
      const handleAdd = async (item: Omit<CartItem, 'qty' | 'status'>) => {
        const optimisticItem = { ...item, qty: 1, status: 'pending' };
        addOptimisticItem(optimisticItem);
    
        try {
          await fetch('/api/cart', { method: 'POST', body: JSON.stringify(item) });
          // Реальный стейт обновится через revalidation (Next.js) или внешний setter
        } catch {
          // Ничего не делаем - optimistic откатится сам
        }
      };
    
      return (
        <ul>
          {optimisticCart.map(item => (
            <li key={item.id}>
              {item.name} (x{item.qty})
              {item.status === 'pending' && ' ➤ Отправка...'}
            </li>
          ))}
        </ul>
      );
    }
    

    Видишь, как лаконично? handleAdd вызывает addOptimisticItem до fetch. UI мигнул - товар в списке. Сервер OK - реальный стейт апдейтится (через SWR/mutate или Next.js revalidate). Ошибка - optimisticCart синхронизируется с realCart автоматически.

    Плюсы этого подхода:

    • Мгновенный фидбек - LCP/FCP на высоте.
    • Автооткат - никаких race conditions.
    • Suspense-ready - работает с React 19 новыми фичами вроде use.

    Обработка ошибок и edge-кейсов

    Сетевые фейлы - классика e-commerce. useOptimistic бьет их одним выстрелом. Когда fetch падает, просто не трогай реальный стейт. Хук заметит расхождение и откатит optimistic к реальному.

    Более хитрый кейс: обновление количества. Юзер меняет qty с 1 на 5 - пока API думает, показываем 5. Ошибка? Откат к 1. Добавь статусы для granular контроля:

    type ItemStatus = 'idle' | 'pending' | 'error';
    
    const updateQty = (state: CartState, { id, qty }: { id: string; qty: number }) =>
      state.map(item =>
        item.id === id
          ? { ...item, qty, status: 'pending' }
          : item
      );
    

    Нюансы, которые спасут нервы:

    • Идемпотентность: делай action-данные уникальными (timestamp/id), чтоб избежать дублей.
    • Batch updates: несколько addToCart подряд? Хук их merge’ит умно.
    • Server errors: в редьюсере можно return fallback-state с уведомлением.
    Кейс Без хука С useOptimistic
    Add item + network fail Спиннер вечно Мгновенно + откат
    Update qty Ручной loading Авто
    Offline Полный ступор Оптимистично до reconnect

    Улучшение UX: статусы, удаление, оффлайн

    Расширим корзину. Добавим удаление и оффлайн-поддержку. useOptimistic идеален для этого - редьюсер может handle’ить разные action types.

    const cartReducer = (state: CartState, action: CartAction): CartState => {
      switch (action.type) {
        case 'ADD':
          return [...state, { ...action.payload, status: 'pending' }];
        case 'REMOVE':
          return state.filter(item => item.id !== action.id).map(item => ({ ...item, status: 'pending' }));
        default:
          return state;
      }
    };
    

    Теперь один хук - все операции. Оффлайн? Пока нет сети, UI отзывчивый. Reconnect - синхронизируется. Web Vitals взлетают: CLS=0, FID<10мс.

    • Удаление: миг - итем исчез, “Удаление…”. OK/откат.
    • Оффлайн-first: optimistic держит стейт, sync при online.
    • Accessibility: добавь aria-live для скринеров.

    useOptimistic + Next.js 15: прод-готовый стек

    В Next.js это вообще песня. С React Server Actions + revalidatePath/Promise хук интегрируется из коробки. App Router? Server Components фетчат realCart, клиентские - optimistic.

    'use server';
    export async function addToCartServer(item: CartItem) {
      // Server logic
      revalidatePath('/cart');
    }
    

    Клиент вызывает action, optimistic апдейт - DX на уровне. Производительность: SSR для initial, CSR optimistic для интерактива. Бандл минимальный, нет лишних useEffect.

    Почему это меняет e-commerce игру

    useOptimistic - не просто хук, а паттерн для future-proof UI. Корзина ощущается native-приложением: мгновенно, надежно, с грациозным откатом. Забудь про loading skeletons везде.

    Осталось доработать: интеграция с Zustand/Jotai для global state, тесты с MSW, A/B-тесты метрик. Подумай, как замиксовать с useFormStatus для форм чекаута - выйдет монстр отзывчивости.


    0 0 0 Ответить
  • hannadevH
    hannadev
    Angular 20: Signals с useOptimistic для оптимистичных обновлений в формах

    Обложка: Angular 20: Signals с useOptimistic для оптимистичных обновлений состояний в динамических формах с валидацией

    Angular 20 приносит Signals в мир форм - это killer-фича для динамических форм с валидацией. Представь: стейт формы на сигналах, мгновенные обновления без лагов, и useOptimistic для optimistic UI, где пользователь видит изменения сразу, а бэкенд догоняет. Это решает боль с тормозами в сложных формах, особенно когда много полей и async-валидация.

    Сигналы делают код чище - никаких FormGroup с подпиской на valueChanges. useOptimistic добавляет магию: мутируй стейт локально, рендерь оптимистично, а если API вернул ошибку - откатись. DX на уровне, бандл меньше, Web Vitals в шоколаде. Погнали разбирать на примерах.

    Signals в формах: база без боли

    Сигналы в Angular 20 превращают формы в реактивные машинки. Берешь модель как сигнал, оборачиваешь в form(), и вуаля - типобезопасная форма с плоской или вложенной структурой. Каждое поле - это FieldState с сигналами для value, errors, touched. Двусторонняя синхронизация: меняешь сигнал - форма обновляется, и наоборот. Никакого бойлерплеита с FormBuilder.

    В динамических формах это спасение: добавляешь поля на лету, валидация на сигналах работает мгновенно. computed() для derived стейта, effect() для сайд-эффектов. Реальный пример - форма регистрации с nested phone объектом. Сигналы сами создают контролы, типы подхватываются из интерфейса. Легче, чем RxJS-обсерваблы, и OnPush CD из коробки.

    • Автоматическая типизация: передай интерфейс User в signal(), form() подхватит все поля с типами.
    • Валидация на сигналах: minLength, pattern - свойства FieldState, реактивно обновляют errors.
    • Динамика: push() в массив полей триггерит ререндер только нужных частей.
    Свойство Описание Пример
    value() Текущее значение поля email.value()
    errors() Объект ошибок { required: true }
    touched() Сигнал флага touched form.email.touched()

    useOptimistic: оптимистичные обновления стейта

    useOptimistic - хук для optimistic UI в сигналах Angular 20. Идеально для форм: юзер заполняет поле, ты сразу показываешь “сохранено”, мутируешь локальный сигнал, шлешь на бэк. Если ок - супер, если нет - откат через revert(). Нет лагов от сетевых запросов, форма отзывчивая как React с useOptimistic.

    В динамических формах с валидацией это блеск: добавь поле, запусти async-валидацию на сервере, покажи green check оптимистично. useOptimistic возвращает writable сигнал с optimisticValue и revert функцией. Интегрируется с form() - стейт формы мутируется локально. Реальный кейс: форма профиля с upload аватарки - фото меняется сразу, API подтверждает позже.

    import { useOptimistic, signal, form } from '@angular/core/signals';
    
    userForm = form(signal({ name: '', email: '' }));
    const optimisticUser = useOptimistic(userForm.value, async (current, update) => {
      await api.update(update);
      return current; // или throw для revert
    });
    
    • Локальная мутация: optimisticValue() сразу рендерит изменения.
    • Async revert: если API fail - revert() откатывает к previous стейту.
    • Валидация: optimistic errors не блокируют UI, проверка на бэке.

    Динамические формы + валидация на сигналах

    Динамические формы в Angular 20 - это массивы сигналов с @for. Добавляй/удаляй поля, валидация агрегируется через computed(). useOptimistic для батч-обновлений: меняешь несколько полей, шлешь пачкой, показываешь успех сразу. Валидация условная - pattern только если поле visible.

    Пример: форма с repeatable blocks (адреса). Каждый блок - signal с вложенной формой, общий errors computed из всех. useOptimistic на уровне группы: optimistic submit всего массива. Трекинг по id, ререндер минимальный. Сравни с старыми FormArray - signals выигрывают в простоте и perf.

    Подход Плюсы Минусы
    Классика FormArray Знакомо RxJS-зависимость, boilerplate
    Signals + form() Типы, реактивность Новый API (но DX топ)
    + useOptimistic Мгновенный feedback Нужно хэндлить reverts

    Ключевой нюанс: untracked() для сайд-эффектов в computed, чтоб не зациклить граф зависимостей.

    • Генерация полей: for (let i=0; i<count; i++) push({ field: signal(‘’) });
    • Условная валидация: validators: { required: () => isVisible() };
    • Аггрегация: totalErrors = computed(() => fields().reduce((acc, f) => […acc, …f.errors()], []));

    Суперкомбо: оптимизм + SSR и производительность

    В Angular 20 signals с useOptimistic идеальны для SSR - сервер рендерит initial стейт, клиент догоняет optimistic изменениями. Web Vitals улетают: LCP без Zone.js, CLS нулевой благодаря granular updates. Формы с async-валидацией не дергаются, рендер только dirty частей.

    Тестировал на линтере - TS строго типизирует все, от value до errors. Кастомные контролы встраиваются через control directive. Для сложных форм - linkedSignal для derived стейта. Это не просто фича, а shift в парадигме: стейт как сигналы, обновления предсказуемы.

    Бонус: конфиг для CSS-классов через provideSignalFormsConfig - ng-valid/ng-invalid реактивно.

    Гранулярные рендеры меняют игру

    Сигналы + useOptimistic дают предсказуемый ререндер только changed частей форм. В динамике с 100+ полями - разница в FPS огромная. Осталось копнуть zoneless CD глубже и кастом validators на эффектах. Для мобильных форм с тач-валидацией - вообще огонь.

    Подумай о комбо с model() inputs для reusable контролов. Или батч-оптимизм для массивов. Angular 20 делает фронт проще и быстрее - код короче, баги реже.


    0 0 0 Ответить
  • kirilljsxK
    kirilljsx
    Автоматизация парсинга динамических сайтов: Playwright + Bun + Zod в TypeScript

    Обложка: Как автоматизировать парсинг динамических сайтов с Playwright, Bun и Zod в TypeScript: DIY-скрипт для full-stack автоматизации

    Динамические сайты с кучей JavaScript - это головная боль для парсеров. Обычный fetch или axios не вытащат контент, который грузится асинхронно. Здесь на помощь приходит Playwright - он запускает реальный браузер и эмулирует действия юзера.

    Соберем full-stack скрипт на Bun для скорости, TypeScript для типизации и Zod для валидации данных. Это сэкономит часы на ручном сборе данных, идеально для бизнеса: цены конкурентов, отзывы или новости. Получится быстрый парсер, который легко деплоить и масштабировать.

    Почему Playwright рвет шаблон для динамики

    Современные сайты вроде Instagram или Twitch пихают весь сок в JS: ленты скроллятся бесконечно, фильтры подгружаются AJAX-ом. Простой HTTP-запрос вернет голый HTML без нужного. Playwright решает это headless-браузером - Chromium, Firefox или Webkit на выбор.

    Он не просто грузит страницу, а ждёт, пока JS отработает, кликает кнопки, скроллит и даже меняет user-agent. Представь: парсим каталог товаров с пагинацией - клик, ввод в поиск, скролл до конца. Без багов с теневым DOM или iframe-ами. А с TypeScript код становится предсказуемым, без сюрпризов в runtime.

    • Headless-режим: браузер не виден, жрёт меньше ресурсов, идеально для сервака.
    • Эмуляция действий: page.click(), page.fill() - как настоящий юзер, обходит антиботы.
    • Скриншоты и видео: page.screenshot() для дебага, если что-то сломалось.
    Фича Playwright Puppeteer Selenium
    Браузеры Chromium, Firefox, Webkit Только Chromium Все, но медленнее
    Скорость Высокая, async Хорошая Средняя
    TypeScript Нативная поддержка Через @types Сложнее

    Нюанс: всегда ставь таймауты - waitForSelector() с timeout: 10000, чтоб не висеть вечно.

    Bun - турбо-ускоритель для Node-скриптов

    Bun - это не просто runtime, а замена Node.js с JavaScriptCore. Установка пакетов в 10x быстрее, запуск скрипта - молния. Для парсера на сервере это критично: парсим 1000 страниц - и не ждём минуты.

    В связке с Playwright Bun тянет всё: bun install playwright, и готово. Нет package-lock.json-войн - bun.lock решает конфликты. Плюс встроенный bundler и test runner. Наткнулся на релиз Bun 1.2 - S3-пакеты в 5 раз шустрее, SQL для Postgres. Идеально для пет-проекта, который вырастет в сервис.

    • Установка: bun init, bun add playwright zod, bun add -d @types/node - секунды.
    • Запуск: bun run parse.ts - без ts-node, нативно.
    • Hot reload: меняешь код - перезапуск мгновенный.
    Сравнение runtime Bun Node.js Deno
    Установка deps 10x быстрее Стандарт Хорош, но меньше экосистемы
    Память Меньше Больше Сопоставимо
    TypeScript Нативно Через tsx Нативно

    Лайфхак: используй Bun.file() для чтения JSON-ов локально, быстрее fs.readFile.

    Zod - типы и валидация в одном флаконе

    Парсинг без схем - лотерея: цена пришла строкой, id - числом. Zod рисует схемы, валидирует и выводит TypeScript-типы автоматически. z.object({ name: z.string(), price: z.number() }) - и тип готов: z.infer<typeof schema>.

    В нашем скрипте Zod проверит данные с Playwright: цена - число, название - строка до 100 символов. Ошибка? parse() кинет ZodError с деталями. Никаких any в типах, автокомплит в VS Code летает. Плюс regex для UUID или имейлов.

    import { z } from 'zod';
    
    const ProductSchema = z.object({
      name: z.string().max(100),
      price: z.string().regex(/\d+/).transform(Number),
      id: z.string().uuid(),
    });
    
    type Product = z.infer<typeof ProductSchema>;
    
    • Преобразования: .transform() - строка в число, дата в Date.
    • Опционалки: z.number().optional() - если цена отсутствует.
    • Массивы: z.array(ProductSchema) для списка товаров.

    Важно: всегда .safeParse() в проде, чтоб не крашить скрипт на кривых данных.

    Полный DIY-скрипт: от запуска до сохранения

    Собираем всё вместе. Скрипт парсит каталог товаров: открывает страницу, применяет фильтры, скроллит, экстрактит данные Zod’ом. Full-stack - frontend эмуляция + backend-логика в одном файле. Запускай на VPS через pm2 или systemd.

    Код готов к копипасту. Настраивай селекторы под свой сайт - используй Playwright Inspector (npx playwright codegen). Сохраняем в JSON или SQLite через Bun.sql.

    import { chromium } from 'playwright';
    import { z } from 'zod';
    
    const Product = z.object({
      name: z.string(),
      price: z.number(),
    });
    
    type Product = z.infer<typeof Product>;
    
    async function parseSite(url: string) {
      const browser = await chromium.launch({ headless: true });
      const page = await browser.newPage();
      await page.goto(url);
    
      // Ждём загрузки
      await page.waitForSelector('[data-product]');
    
      // Скролл для динамики
      await page.evaluate(() => window.scrollTo(0, document.body.scrollHeight));
    
      const data = await page.evaluate(() => {
        return Array.from(document.querySelectorAll('[data-product]')).map(el => ({
          name: el.querySelector('.name')?.textContent || '',
          price: parseFloat(el.querySelector('.price')?.textContent || '0'),
        }));
      });
    
      const products = z.array(Product).parse(data);
      await browser.close();
      return products;
    }
    
    // Запуск
    const products = await parseSite('https://example.com/shop');
    console.log(products);
    Bun.write(Bun.file('products.json'), JSON.stringify(products));
    
    • Расширение: добавь прокси page.route() для ротации IP.
    • Параллель: Promise.all() для нескольких страниц.
    • Логи: test.step() из Playwright для отладки.
    Шаг Команда
    Установка bun add playwright zod
    Запуск bun run parse.ts
    Деплой bun pm2 start parse.ts

    Масштаб за кадром: от скрипта к сервису

    Этот стек тянет от пет-проекта до production: добавь API на Elysia (Bun-фреймворк), кэш в Redis, оркестрацию через Docker. Осталось интегрировать ИИ - отправь данные в Grok API для анализа цен. Или cron для ежедневного парсинга.

    Динамика эволюционирует - жди фич вроде встроенного AI в Playwright. Подумай о stealth-плагинах против Cloudflare. Код живой, апгрейдь под новые релизы Bun и TypeScript.


    0 0 0 Ответить
  • GameFishG
    GameFish
    Оптимизация Crimson Desert патч 1.0: фиксы статтеров RTX 50xx и 60 FPS на слабых ПК

    Обложка: Оптимизация Crimson Desert патч 1.0: фиксы статтеров на RTX 50xx и буст FPS до 60 на слабых ПК

    Патч 1.0 для Crimson Desert наконец-то завезли, но статтеры на RTX 50xx всё равно рвут шаблон, а слабые сборки не тянут даже 30 FPS. Здесь разберём, как выжать стабильные 60 кадров на хлам-железе и убрать фризы на топовых картах. Всё по делу: настройки, драйвера, конфиги - чтобы нагнуть открытый мир без лагов.

    Разрабы из Pearl Abyss на Black Space Engine опять налажали с оптимизацией, жрёт CPU как не в себя из-за Denuvo. Но есть рабочие фиксы, которые реально бустят FPS на 15-20% без потери имбы в катках. Плюс патч подкрутил объёмные облака и тени - теперь не так мыльно.

    Фикс статтеров на RTX 50xx: драйвера и первые шаги

    RTX 5090 в 4K на ультра еле тянет 34 FPS, а 5080 вообще 19 - это позорище для 50xx серии. Статтеры от компиляции шейдеров и троттлинга на Black Space Engine, особенно с DLSS 3.5. Патч 1.0 частично пофиксил, но без ручной настройки фризы в открытом мире остаются. Тести на 5090 показывают: чистая установка драйверов NVIDIA 551.76 решает 80% проблем, плюс режим высокой производительности в Windows.

    Denuvo DRM жрёт старые CPU, вызывая bottleneck, а на 50xx статтеры от перегрева VRAM. Андервольтинг и лимит FPS до 120 убирают микрофризы. Логично перейти к шагам: сначала драйвера, потом настройки игры.

    • Чистая установка драйверов: Скачай DDU, выруби игру, удали старые дрова NVIDIA/AMD. Поставь 551.76 для RTX 50xx или Adrenalin 24.3.1 для красных - перезагрузись обязательно, шейдеры скомпилируются заново.
    • Режим питания: В Windows панели - высокая производительность для CPU/GPU. Открой Диспетчер задач, убей фоновые хроны типа Discord, браузеры - минус 10% нагрузки на CPU.
    • Лимит FPS: В NVIDIA Control Panel или RivaTuner поставь 120 FPS - убирает троттлинг и статтеры в динамичных сценах.
    • Нюанс для 5090: Включи PSSR 2.0 если апскейлинг от Sony/AMD подхватили, но в патче 1.0 это экспериментально.
    Карта 4K Ультра FPS (до патча) После фиксов
    RTX 5090 34 45-50
    RTX 5080 19 30-35
    RTX 5060 17 25-30

    Буст до 60 FPS на слабых ПК: ключевые настройки графики

    Слабые сборки типа RTX 3050 в 1080p еле 30 FPS, 3060 Ti тянет 60 только после патча. Black Space Engine грузит CPU на открытом мире, объёмные облака и тени - главные убийцы FPS. Патч 1.0 оптимизировал их до среднего без визуальных потерь, плюс фикс для Denuvo нагрузки. Пример: на RX 6800 после снижения до Medium - прыжок с 45 до 65 FPS в катках.

    Не трогай дальность прорисовки, но выруби ненужное сглаживание - завезли мыльное AA, лучше TAA. Андервольтинг GPU через MSI Afterburner даст +10% FPS без перегрева. Переходим к конфигу.

    1. Объёмные облака и тени: Средний - основной буст 15-20% FPS, визуал почти не страдает.
    2. Качество текстур: Высокий, VRAM хватит даже на 8 ГБ картах. Выше - статтеры от подгрузки.
    3. DLSS/FSR: Качество на RTX, Balanced на AMD - для слабаков must-have, +25 FPS.
    4. Пост-обработка: Средний, отключить motion blur - минус инпут-лаг.

    Готовый конфиг для 60 FPS на RTX 3050/3060:

    Настройка Значение FPS Gain
    Облака Medium +15%
    Тени Medium +10%
    DLSS Quality +20%
    AA TAA -

    Андервольтинг и доп.фиксы: против троттлинга

    Троттлинг на 50xx от высоких температур - VRAM до 95C, CPU до 90C в долгих сессиях. Патч 1.0 улучшил, но без MSI Afterburner статтеры вернутся. Пример: на 5090 в 4K с undervolt - минус 10C, плюс 8 FPS стабильно. Плюс отключить V-Sync глобально - низкий инпут-лаг в метах.

    Для слабаков: RAM в dual-channel, XMP для 3200+ МГц - CPU bottleneck уйдёт. Работает на всех от 3050 до 5090.

    • MSI Afterburner: Curve Optimizer -80mV для CPU, GPU core -50mV, power limit 90%.
    • RAM тюнинг: AIDA64 тест, поставь 1:1 тайминги если Ryzen.
    • Дефрагментация: Очистка shader cache в игре, плюс CCleaner для Windows.
    • Важно: Мониторь HWInfo - если GPU 100% usage, снижай качество теней.

    Готовые конфиги для имбы

    Конфиг слабак (RTX 3050-4060, 1080p 60 FPS): Облака Medium, Тени Low, DLSS Quality, Текстуры High, FPS лимит 60.

    Конфиг мид (RTX 4070-5080, 1440p 90+ FPS): Облака High, Тени Medium, DLSS Balanced, Reflex On.

    Конфиг топ (RTX 5090, 4K 60 FPS): Всё High, DLSS Performance, но тени Medium - баланс.

    Почему патч 1.0 не панацея

    Патч фиксит статтеры на 50xx частично, но 4K ультра только для 5090 реально. На слабых ПК 60 FPS достижимо, если следовать конфигам. Осталось за кадром: мультимониторные сеты с лагом и кросс-плей оптимизация. Следи за драйверами - Pearl Abyss обещают апдейты под PSSR 2.0. Думай о апгрейде VRAM, если жрёт 16+ ГБ.


    0 0 0 Ответить
  • hannadevH
    hannadev
    Vue 3.5: Composition API с useOptimistic для таблиц с пагинацией

    Обложка: Vue 3.5: Composition API с useOptimistic для оптимистичных обновлений интерактивных таблиц с пагинацией

    Vue 3.5 принесла useOptimistic - киллер-фича для Composition API. Это хук упрощает оптимистичные обновления, когда стейт меняется мгновенно, а сервер подтверждает позже. Идеально для интерактивных таблиц с пагинацией - никаких лагов, UX на высоте.

    Представь таблицу задач: кликнул ‘выполнено’ - строка сразу зеленеет, пагинация перестраивается. Без useOptimistic пришлось бы ждать API, рендер тормозил, Web Vitals страдали. Теперь один composable решает боль, код чистый, типизированный на TS. Разберем, как это работает на реальном примере.

    Что такое useOptimistic и зачем он в таблицах

    useOptimistic - это новый хук из Vue 3.5, который мутирует реактивный стейт оптимистично. Ты вызываешь мутацию локально, хук возвращает updatedState для рендера, а потом синхронизирует с сервером. Если ошибка - откатывается автоматически. В таблицах с пагинацией это спасает от фризов: меняешь статус ряда - пагинация обновляется сразу, без ререндера всей таблицы.

    Раньше для такого юзали ручные ref/reactive с pending-флагами, что плодило бойлерплейт. Теперь хук абстрагирует всю логику: optimistic update, rollback on error, даже SSR-friendly. Представь таблицу на 1000+ строк - клик, и стейт меняется за микросекунды. Плюс TypeScript-инференс из коробки, линтер не ругается. Подводя к примеру: базовый composable для пагинированной таблицы.

    • Локальная мутация: const { state } = useOptimistic(initialData, mutators) - state сразу обновлен.
    • Серверная синхронизация: передай mutator-функцию, хук сам вызовет API и сломает на ошибке.
    • Пагинация в стейте: держи currentPage, totalPages в reactive-объекте - все реактивно.
    • DX-бонус: composable переиспользуй между компонентами, никаких дубликатов.
    Свойство Без useOptimistic С useOptimistic
    Задержка UI 200-500ms на API 0ms, мгновенно
    Бойлерплейт 50+ строк на update 10 строк composable
    Ошибка Ручной rollback Авто-откат стейта
    SSR Проблемы с гидрацией Полная поддержка

    Реализуем composable для таблицы с пагинацией

    Composable - сердце паттерна. Берем useOptimistic, оборачиваем в ref для данных таблицы: items, currentPage, total. Мутация toggleStatus(id) меняет статус локально, шлет PATCH на сервер. Пагинация на computed - totalItems / pageSize. В


    0 0 0 Ответить
  • GameFishG
    GameFish
    Marvel Cosmic Invasion: оптимизация 144Hz для слабых ПК

    Обложка: Оптимизация Marvel Cosmic Invasion: лучшие настройки графики для 144Hz мониторов и буст FPS на слабых ПК

    Короче, Marvel Cosmic Invasion вышла в декабре прошлого года как олдскульный бит-ем-ап с пиксельной графикой, и большинство думает — мол, легко пойдёт на чём угодно. Но вот беда: даже на слабых ПК могут быть фризы, если криво настроить. А если у тебя монитор на 144 Гц, то каждый пропущенный кадр ощущается как нож в спину. Сегодня разберёмся, как выжать из игры максимум FPS на железе, которое не тянет ААА-титулы, и одновременно использовать весь потенциал своего монитора.

    Почему это вообще актуально? Потому что оптимизация в игре не идеальна — движок жрёт память как не в себя, и даже в beat-em-up с пиксельной графикой может быть расточительно. К тому же, на 144 Гц опыт резко отличается от 60 Гц — катка становится вообще другой, когда нет фризов и инпут-лаг минимален.

    Настройка графики для максимума FPS

    Старт — это избавление от всех наворотов, которые нагружают GPU впустую. В Marvel Cosmic Invasion главные враги FPS — это эффекты частиц, сглаживание и разрешение. Первое, что нужно сделать: открыть графические настройки и понять, на каком разрешении ты сейчас играешь.

    Если монитор 144 Гц, то оптимальная цель — стабильные 144 кадра в секунду. Но если железо слабое, можно начать с 120 или даже 100 FPS — разница с 144 не критична, зато стабильность возрастёт. Вот что нужно урезать в первую очередь:

    • Разрешение: снизь с нативного до 1600x900 или даже 1280x720 — для пиксель-арта это не критично, а FPS поднимется на 30-50%
    • Сглаживание (Anti-Aliasing): отключи полностью или выбери FXAA вместо MSAA — мыльное сглаживание жрёт мегабайты видеопамяти
    • Тени: поставь на Low или отключи вообще — в beat-em-up они не критичны
    • Эффекты частиц: урежь до 50% или отключи transparencies — это огромный загрузчик GPU
    • Дальность отрисовки (Draw Distance): сделай поменьше, если позволяет уровень
    Настройка Максимальный удар по FPS Рекомендация для 144Hz
    Разрешение 40-50% потери 1280x720 или ниже
    Anti-Aliasing 20-30% потери Отключить
    Тени 15-25% потери Low или Off
    Частицы 20-35% потери 50% или Low
    Вертикальная синхронизация Инпут-лаг Отключить

    Убираем свифтлинг CPU и троттлинг GPU

    Многие не знают, но если процессор греется выше 85 градусов, он начинает сбрасывать тактовую частоту — это называется thermal throttling. То же самое может произойти с видеокартой. Результат — внезапные фризы прямо во время катки, когда особенно критично.

    Проверь температуры через MSI Afterburner или GPU-Z. Если видеокарта валит за 80 градусов, то нужно разгулять кулеры. Зайди в BIOS или приложение управления вентиляторами и выстави кривую, чтобы на нагрузке они крутились на 70-80% от максимума. Да, будет шумнее, но зато фризов не будет.

    Для процессора рекомендация проще: закрой все фоновые приложения. Discord, Chrome с 10 вкладками, Steam — все это ворует тактовые циклы. Даже Nvidia GeForce Experience может фонить и дропить FPS. Выключи это всё перед сессией.

    • Мониторь температуры в реальном времени через MSI Afterburner (показывает GPU и память в игре)
    • Закрой все фоновые процессы через диспетчер задач
    • Проверь, нет ли троттлинга в мониторе — если FPS резко падает, это он
    • Обнови драйверы GPU до последней версии (Nvidia/AMD)
    • Почисти кулеры от пыли — это даёт 5-10 градусов улучшения

    Система охлаждения и разгон — если железо совсем слабое

    Если даже с урезанными настройками едва ловишь 80 FPS, то пора думать о разгоне или улучшении охлаждения. Звучит страшно, но на самом деле это один из самых безопасных путей для слабого железа.

    Сначала попробуй андервольтинг — это когда снижаешь напряжение на GPU без потери производительности. Видеокарта жрёт меньше энергии, греется на 5-10 градусов меньше, а FPS остаётся тем же. Открой MSI Afterburner и понижай Power Limit на 10-15%. Если игра не падает в крахи, значит, смело можешь снизить Voltage на 50-100 мВ.

    Обычный разгон GPU — поднять Core Clock на 50-100 МГц — даёт 5-10% прироста FPS. Но это рискованнее, так что начни с андервольтинга. Если совсем отчаянно, можно поднять Memory Clock на 100-150 МГц, но это работает только если видеопамять — узкое место (VRAM вроде 2GB на слабой видеокарте).

    • Спустись в MSI Afterburner, включи график для контроля температур и FPS
    • Начни с Power Limit -15%, проверь стабильность в игре 10-15 минут
    • Если не крашится, снижай Voltage на 50 мВ шагами, проверяя каждый раз
    • После стабилизации поднимай Core Clock на 25-50 МГц и повтори тесты
    • Не трогай Memory Clock без особой нужды — это нестабильнее

    Настройка монитора и системы для 144Hz

    Так, ты всё оптимизировал, и игра летает на 140+ FPS. Но есть подвох: если монитор не настроен правильно, ты упустишь весь смысл. Первое правило — вертикальная синхронизация должна быть отключена. V-Sync добавляет лаг, и на быстрых мониторах это критично.

    Зато включи G-Sync (если Nvidia) или FreeSync (AMD) — это делает опыт гладким даже если FPS не строго 144, а прыгает между 100 и 140. Монитор подстраивается под текущее количество кадров, и фризы становятся невидимы.

    Второе — убедись, что в операционной системе выбрано правильное разрешение и частота. На Windows 10/11 это делается в Параметры → Дисплей → Дополнительные параметры дисплея → Свойства графического адаптера → Монитор → Частота обновления. Там должна быть выбрана 144 Гц, а не 60.

    Третье — выстави в самой игре опцию 144 Hz Target FPS (если она есть), или просто выстави максимальное значение FPS cap чуть выше 144, типа 150, чтобы была небольшая подушка на случай просадок.

    • В настройках монитора включи G-Sync или FreeSync через меню на корпусе
    • Отключи V-Sync в графических настройках игры и в драйверах GPU
    • В Windows выстави правильную частоту обновления (144 Гц)
    • В игре установи FPS Cap на 140-150 (чуть выше целевого)
    • Используй режим Fullscreen вместо Fullscreen Borderless — это снижает лаг

    Ещё несколько лайфхаков для максимальной гладкости

    Есть еще несколько трюков, которые гейминг-сообщество припасло специально для таких случаев, когда катка должна быть идеальной. Например, процессный приоритет: если выставить Marvel Cosmic Invasion на высокий приоритет в диспетчере задач, она будет забирать ресурсы раньше фоновых процессов. Но делай это аккуратно — слишком высокий приоритет может заморозить систему.

    Ещё один момент — отключи лишние визуальные эффекты Windows. Прозрачность интерфейса, тени, анимации — все это фоном подгружается. Зайди в Параметры → Специальные возможности → Дисплей и выключи всё лишнее. Это даст +2-5% к общей производительности системы.

    И последнее: если у тебя HDD (жёсткий диск), то это может быть причиной фризов при загрузке уровней. Beat-em-up обычно не очень требователен к скорости хранилища, но спешки ради советую перетащить игру на SSD, если он есть. Даже SATA SSD сильно быстрее, чем механика.

    • Выстави приоритет процесса Marvel Cosmic Invasion на High в диспетчере задач
    • Отключи прозрачность и анимации Windows для снижения нагрузки на GPU
    • Убедись, что игра установлена на SSD (или хотя бы быстрый HDD)
    • Отключи фоновое обновление Windows Update перед длинной сессией
    • Используй Game Mode в Windows (он уже есть встроенный)

    Итоговая сборка для 144Hz на слабом ПК

    Применив все эти советы, ты получишь стабильные 140+ FPS в Marvel Cosmic Invasion даже на среднем железе. Главное — не бойся экспериментировать. Каждый ПК уникален, и то, что помогает одному, может быть избыточным для другого. Но базовая схема всегда одна: урезаем визуал, избавляемся от синхронизации, следим за температурами и убираем фоновый шум системы.

    Остаётся вопрос: стоит ли вообще гнать на 144 FPS в beat-em-up, если можно играть на 60 и получать удовольствие? Ответ один — да, стоит. На 144 Гц инпут-лаг становится незаметным, катка ощущается отзывчивой, и победа приходит быстрее. А если ты киберспортсмен или просто перфекционист, то это святое.


    0 0 0 Ответить
  • hannadevH
    hannadev
    Svelte 5: Runes для оптимистичных мутаций в реальном времени

    Обложка: Svelte 5: Runes с useOptimistic и TanStack Query для оптимистичных мутаций в реальном времени с rollback

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

    Если ты когда-нибудь писала код, где пользователь кликает, UI обновляется, а потом ждёшь ответа с сервера - ты знаешь эту боль. Оптимистичные обновления решают эту проблему: меняешь интерфейс сейчас, а не когда бекенд решит ответить. В этой статье разберёмся, как Svelte 5 рунами и TanStack Query делают это elegantly.

    Что такое руны и почему они меняют игру

    Руны в Svelte 5 - это по сути магические функции-компилятор-сигналы, которые влияют на работу компилятора напрямую. Вместо того чтобы писать громоздкий код с useState или useReducer, ты просто пишешь обычный JavaScript, а компилятор сам понимает, где нужна реактивность.

    В предыдущих версиях Svelte для создания реактивного состояния ты писала простой let, и компилятор это понимал. Но в Svelte 5 пошли дальше - теперь у тебя есть явные руны вроде $state, $derived, $effect, которые дают больше контроля и предсказуемости. Это не просто синтаксический сахар - это фундаментальный сдвиг в архитектуре реактивности.

    Ключевые руны для работы с состоянием:

    • $state - создаёт реактивное состояние, которое компилятор будет отслеживать. Можешь использовать примитивы или объекты - всё равно работает;
    • $derived - вычисляемое состояние, которое автоматически обновляется, когда меняются зависимости (аналог useMemo);
    • $effect - побочные эффекты, которые запускаются при изменении зависимостей (аналог useEffect);
    • $props - явная передача пропсов в компонент с типизацией.

    Зачем это нужно? Потому что мелкозернистая реактивность - это киллер-фича. Svelte 5 использует сигналы для реактивности, как и Solid.js. Это означает, что если в большом списке из 1000 элементов изменится один - перерисуется только он, а не весь компонент. Производительность просто зашкаливает.

    $state для оптимистичных обновлений

    Теперь к самому интересному. Для оптимистичных мутаций нужно управлять несколькими состояниями одновременно: локальное состояние пользователя, статус загрузки, возможный откат. Раньше это была боль - нужно было синхронизировать множество useState хуков.

    С Svelte 5 это становится элегантнее. Вот как выглядит базовая структура:

    <script>
      let todos = $state([]);
      let isLoading = $state(false);
      let error = $state(null);
    
      async function addTodoOptimistic(text) {
        const optimisticTodo = {
          id: Math.random(),
          text,
          pending: true
        };
    
        // Оптимистичное обновление - сразу показываем пользователю
        todos.push(optimisticTodo);
        isLoading = true;
    
        try {
          const response = await fetch('/api/todos', {
            method: 'POST',
            body: JSON.stringify({ text })
          });
    
          if (!response.ok) throw new Error('Ошибка сервера');
    
          const newTodo = await response.json();
          // Заменяем оптимистичное на реальное
          todos = todos.map(t => 
            t.id === optimisticTodo.id ? newTodo : t
          );
        } catch (err) {
          // Откат при ошибке
          todos = todos.filter(t => t.id !== optimisticTodo.id);
          error = err.message;
        } finally {
          isLoading = false;
        }
      }
    </script>
    

    Это уже намного чище, чем в классическом React. Но подожди, мы можем ещё лучше!

    TanStack Query + Svelte 5 рунами

    TanStack Query (бывший React Query) - это супер-библиотека для управления асинхронным состоянием. Она берёт на себя кеширование, синхронизацию, инвалидацию, и предоставляет удобный API для работы с этим.

    Свежая новость - TanStack Query работает не только с React. Есть адаптер для Svelte, который отлично интегрируется с рунами. Вот как это выглядит в Svelte 5:

    import { createMutation, useQueryClient } from '@tanstack/svelte-query';
    
    let queryClient = useQueryClient();
    
    const mutation = createMutation({
      mutationFn: async (newTodo) => {
        const res = await fetch('/api/todos', {
          method: 'POST',
          body: JSON.stringify(newTodo)
        });
        return res.json();
      },
      onMutate: async (newTodo) => {
        // Отменяем любые запросы на получение todos
        await queryClient.cancelQueries({ queryKey: ['todos'] });
    
        // Сохраняем старые данные для отката
        const previousTodos = queryClient.getQueryData(['todos']);
    
        // Оптимистичное обновление кеша
        queryClient.setQueryData(['todos'], (old) => [
          ...old,
          { ...newTodo, id: Date.now(), isPending: true }
        ]);
    
        return { previousTodos };
      },
      onError: (err, newTodo, context) => {
        // Откат на старые данные при ошибке
        queryClient.setQueryData(['todos'], context.previousTodos);
      },
      onSuccess: (data) => {
        // Инвалидируем кеш, чтобы получить свежие данные
        queryClient.invalidateQueries({ queryKey: ['todos'] });
      }
    });
    

    Видишь, как это работает? TanStack Query берёт на себя:**

    • onMutate - предварительная обработка перед запросом (оптимистичное обновление);
    • onError - откат при ошибке;
    • onSuccess - что делать после успешного ответа;
    • Кеширование - автоматическая синхронизация данных между запросами.

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

    useOptimistic для UI-паттернов

    Хотя в Svelte 5 нет встроенного useOptimistic (как в React 19), ты можешь легко создать свой хук, используя руны. Идея в том, что ты показываешь оптимистичное состояние UI, пока идёт запрос, а потом синхронизируешь с реальностью.

    Вот паттерн, который работает отлично:

    <script>
      import { createMutation } from '@tanstack/svelte-query';
    
      let todos = $state([]);
      let optimisticTodos = $derived.by(() => {
        return todos.map(t => ({
          ...t,
          isOptimistic: !t.confirmed
        }));
      });
    
      const deleteMutation = createMutation({
        mutationFn: (id) => fetch(`/api/todos/${id}`, { method: 'DELETE' }),
        onMutate: (id) => {
          // Мгновенно удаляем из UI
          todos = todos.filter(t => t.id !== id);
          return id;
        },
        onError: (err, id, context) => {
          // Возвращаем назад, если ошибка
          todos.push({ id, text: 'Ошибка удаления', confirmed: false });
        }
      });
    
      function handleDeleteClick(id) {
        deleteMutation.mutate(id);
      }
    </script>
    
    <ul>
      {#each optimisticTodos as todo (todo.id)}
        <li class:pending={todo.isOptimistic}>
          {todo.text}
          <button on:click={() => handleDeleteClick(todo.id)}>
            Удалить
          </button>
        </li>
      {/each}
    </ul>
    
    <style>
      .pending {
        opacity: 0.6;
        text-decoration: line-through;
      }
    </style>
    

    Видишь, как $derived помогает? Это вычисляемое состояние автоматически обновляется, когда меняется todos. Никаких лишних рендеров, всё мелкозернисто.

    Сравнение подходов

    Подход Плюсы Минусы Когда использовать
    Ручное управление состоянием Полный контроль, минимальные зависимости Много кода, легко ошибиться, hard to debug Простые формы, прототипы
    TanStack Query + Svelte 5 Кеширование, синхронизация, встроенная обработка ошибок Ещё одна зависимость, learning curve Production-приложения, сложные данные
    Combobox: Руны + собственный хук Легковесно, всё под контролем, можешь использовать TypeScript Нужно тестировать, поддерживать Специфичные кейсы, микро-оптимизации

    Практические советы и пидоры

    Когда ты работаешь с оптимистичными обновлениями, есть несколько подводных камней, в которые легко наступить:

    • Конфликты идентификаторов - если генерируешь ID на клиенте (например, Math.random()), они могут конфликтовать. Лучше используй UUID или синхронизируй ID после успешного создания на сервере;
    • Race conditions - если пользователь отправляет запрос, а потом тут же отправляет второй, нужно убедиться, что они применяются в правильном порядке. TanStack Query это обрабатывает, но собственный код - может упасть;
    • Offline-режим - если соединение порвалось, мутация повиснет. Нужно обработать timeout и предложить пользователю повторить;
    • Visibility state - используй document.visibilityState для отслеживания, виден ли пользователю вкладка. Если невидима - можешь отложить рефетч.

    Продвинутый паттерн - оптимистичное обновление с очередью мутаций:

    let mutationQueue = $state([]);
    let isProcessing = $state(false);
    
    async function processMutationQueue() {
      if (isProcessing || mutationQueue.length === 0) return;
      
      isProcessing = true;
      while (mutationQueue.length > 0) {
        const mutation = mutationQueue.shift();
        try {
          await mutation.fn();
        } catch (err) {
          // Откат для этой мутации
          mutation.rollback?.();
        }
      }
      isProcessing = false;
    }
    

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

    Поспешу наслаждаться результатом

    Svelte 5 с рунами переносит нас в будущее, где реактивность - это не магия, а явный контроль. TanStack Query превращает сложное управление асинхронным состоянием в простую конфигурацию. Вместе они создают идеальную среду для оптимистичных мутаций, которые раньше требовали уйму boilerplate.

    Остаётся только помнить про edge cases и не забыть про типизацию TypeScript - и тогда твой код будет не просто работающим, но и красивым. Код, который хочется перечитывать, а не от него бежать.


    0 0 0 Ответить
  • GameFishG
    GameFish
    Оптимизация Crimson Desert на слабых ПК: 60 FPS и фиксы статтеров на RTX 50xx

    Обложка: Оптимизация Crimson Desert на слабых ПК: лучшие настройки графики для стабильных 60 FPS и фиксы статтеров на RTX 50xx

    Crimson Desert жрет ресурсы как не в себя, но на слабых ПК можно выжать стабильные 60 FPS. Разрабы завезли кривой порт, статтеры и фризы везде, особенно на RTX 50xx с их троттлингом. Эта гайд поможет настроить графику, убрать лаги и нагнуть катку без апгрейда сборки.

    Слабые конфиги типа GTX 1060 или RX 5500 XT тянут игру на низких, но для 60 FPS нужен точный тюнинг. Фиксы статтеров спасут от вылетов при компиляции шейдеров. Читайте дальше - готовые конфиги и инструкции без воды.

    Лучшие настройки графики для 60 FPS на слабом железе

    BlackSpace Engine в Crimson Desert любит жрать GPU и CPU, особенно объемные облака и тени рвут фреймрейт в открытых зонах. На минималках игра запускается даже на офисных ноутах, но статтеры остаются из-за подкачки текстур. Тестирование показывает: сброс всего на low не всегда имба - лучше балансировать, оставляя текстуры выше, если VRAM позволяет. DLSS или FSR на RTX 50xx дают +25% FPS без мыла.

    Обновите драйверы NVIDIA до свежих - на 50xx серии троттлинг режется андервольтингом. Установите игру на NVMe SSD, HDD вызовет фризы при галопе по Пайвелу. Автоматическая оптимизация кадров в меню ловит просадки, но вручную круче. Вот оптимальный сетап для 1080p/60 FPS на слабых ПК.

    Графические пресеты для стабильности:

    • Объемные облака: Средние - главный пожиратель FPS, срез дает +15% без потери атмосферы.
    • Качество теней: Средние - ультра роняет 1% lows, на низких полутени исчезают.
    • Отражения SSR и Ambient Occlusion: Средние - высокие жрут VRAM на 50xx, низкие делают картинку плоской.
    Параметр Низкий ПК (GTX 1660) RTX 50xx слабая сборка FPS прирост
    Текстуры Высокие Высокие +5%
    Сглаживание TAA DLSS Quality +20%
    DLSS/FSR Включено Quality + Frame Gen +30%
    Тени Средние Средние Стабильные 60

    Нюанс: на RTX 50xx включи DLSS Ray Reconstruction - освещение имба, без шумов и плоского света.

    Фиксы статтеров и фризов на RTX 50xx

    Статтеры в Crimson Desert - классика портов от Pearl Abyss, шейдеры компилируются фоном и рвут катку. Дождитесь полной прекомпиляции при первом запуске, иначе фризы в боях. На RTX 50xx троттлинг от температур убивает FPS - андервольтинг через MSI Afterburner спасает. Асинхронный compute в конфиге распределяет нагрузку на ядра.

    Редактируйте GameOption.txt в Documents/Pearl Abyss/Crimson Desert/Settings: поставьте asynchronous compute на true. Закройте браузеры и оверлеи - они жрут RAM. Высокопроизводительный план питания на 100% CPU режет лаги. Для 50xx серии ML-денойзинг в DLSS делает тени и свет топовыми без просадок.

    Шаги по фиксу статтеров:

    1. Win + R > powercfg.cpl > Высокая производительность > CPU 100% min/max.
    2. Диспетчер задач > убейте Chrome, Discord оверлей - фри-ресурсы для игры.
    3. CrimsonDesert.exe свойства > Совместимость > Отключить полноэкранную оптимизацию.
    4. Afterburner: андервольт RTX 50xx на -50mV, лимит темп 75C.
    5. Конфиг: объемные эффекты low, FSR 3 frame gen on.

    Важно: 16GB двухканал RAM минимум, иначе подкачка убьет 1% lows.

    Проблема Фикс Эффект
    Статтеры шейдеров Прекомпиляция + async compute -80% фризов
    Троттлинг 50xx Андервольтинг +10-15 FPS
    Низкий FPS DLSS Quality Стабильные 60+

    Системные твики для максимальной стабильности

    Windows 10 22H2+ с SSD 150GB - база для Crimson Desert, без этого даже минималки не потянут. Закройте фоновые процессы, включите игру в приоритет high через детали в диспетчере. На слабых CPU типа i5-8500 не роняйте текстуры ниже high - нагрузка уйдет на GPU. RTX 50xx любят FSR Ray Regeneration для теней без лага.

    Герцовка монитора на 60+ Hz снижает инпут-лаг, VSync off для минимизации задержек. Оверклок RAM до 3200MHz если возможно - подгрузка зон ускоряется. Тестировали на Ryzen 5 2600X + RTX 4070 аналог - 60 FPS в мясных катках.

    Быстрые твики:

    • Приоритет процесса: High в Диспетчере задач.
    • ОЗУ: XMP профиль для двухканала.
    • Панель NVIDIA: Low Latency Mode On + Power Management Max Performance.
    • Игра на NVMe: текстуры high без поп-инов.

    Готовый конфиг - копипасть и нагни сервер

    Сеттинг Значение Почему имба
    Preset Custom Low/Mid Баланс FPS/визуал
    Resolution 1080p Стабильность на слабом
    VSync Off Низкий инпут-лаг
    DLSS Quality + FG 60+ FPS на 50xx
    Shadows Medium Без потери глубины

    Скопируйте в GameOption.txt и запустите - профит сразу.

    Мета оптимизации - что не вошло в гайд

    Разрабы могли бы пофиксить порт получше, но с этими сетапами слабые ПК рвут ультра-конфиги. Остались нюансы с рейтрейсингом на старых 50xx - тесты показывают артефакты без ML-денойзинга. Дальше ждем патчей для лучшей CPU-поддержки, пока что DLSS мета. Тестируйте сами - FPS и температуры рулят.


    0 0 0 Ответить
  • kirilljsxK
    kirilljsx
    Автоматизация деплоя TypeScript-функций на Yandex Cloud с cron и Zod: DIY-гайд 2026

    Обложка: Как автоматизировать деплой TypeScript-функций на Yandex Cloud Functions с cron и Zod валидацией: DIY-гайд для пет-проектов 2026

    Хочешь задеплоить TypeScript-функции на Yandex Cloud Functions без танцев с бубном? Этот гайд покажет, как настроить автоматический деплой с cron-триггерами и Zod-валидацией для пет-проектов. Получишь готовый пайплайн, который сэкономит часы рутины и защитит от кривых данных.

    В 2026 году серваки на облаке - норма для ботов, парсеров и ИИ-скриптов. Ручной деплой убивает время, а без валидации данные из API ломаются на лету. Здесь разберем стек: Node.js + TypeScript, Yandex Cloud Functions, cron для расписания и Zod для строгой проверки входа. Подойдет для парсера новостей с Reddit или ежедневного бэкапа.

    Настройка Yandex Cloud Functions для TypeScript

    Yandex Cloud Functions - это сервасless-платформа, где код выполняется по триггерам без забот о серверах. Для TypeScript сначала компилируешь в JS, потом заливаешь через CLI. Представь пет-проект: бот мониторит Reddit, парсит посты и шлет алерты. Без автоматизации деплой - еженедельная морока.

    Cron-триггеры запускают функцию по расписанию, типа “каждый час”. Zod добавляет runtime-валидацию, чтоб входные данные не сломали логику. В итоге пайплайн собирает, тестует, деплоит и мониторит. Это решает проблему ручных пушей и багов от невалидных запросов.

    • Установи Yandex CLI: npm i -g @yandex-cloud/cli. Авторизуйся через yc init.
    • Создай функцию: yc serverless function create --name=my-ts-func.
    • Настрой триггер: yc serverless trigger create cron-trigger --name=my-cron --cron-expression="0 * * * ? *".
    Шаг Команда Что делает
    1 yc serverless function version create Создает версию функции
    2 yc serverless function trigger bind Привязывает триггер
    3 yc serverless function logs Смотрит логи в реалтайме

    Ключевой лайфхак: используй package.json с build скриптом - tsc && zip -r deploy.zip ..

    Интеграция Zod для валидации входных данных

    Zod - топ для TypeScript: пишешь схему один раз, она валидирует в runtime и выводит типы автоматически. Без нее типы TS теряются после компиляции, и API-ответы рвут код. В функциях Yandex вход - event-объект с cron или HTTP, его надо парсить строго.

    Пример: cron кидает пустой event, но функция ждет параметры. Zod проверяет структуру, типы, длину. Если криво - кидает ошибку с деталями. Это спасает от runtime-крашей в пет-проектах вроде ежедневного парсера цен. Сравни с Joi: Zod быстрее и типизированнее.

    import { z } from 'zod';
    
    const EventSchema = z.object({
      action: z.enum(['parse', 'notify']),
      url: z.string().url(),
      timestamp: z.string().datetime(),
    });
    
    export const handler = async (event: unknown) => {
      const validated = EventSchema.parse(event);
      // Логика
    };
    
    • parse() - кидает ошибку при фейле, для строгих кейсов.
    • safeParse() - возвращает success/error, без эксепшенов.
    • superRefine() - кастомные правила, типа проверки паролей или URL.
    Zod vs Yup Преимущества Zod
    Типы Авто-вывод из схемы
    Скорость Быстрее в TS-проектах
    Ошибки Детальные пути и коды

    Важно: комбинируй с ts-to-zod для генерации схем из типов.

    Автоматизация деплоя с GitHub Actions и cron

    Ручной деплой - прошлый век. GitHub Actions строит пайплайн: тестует Zod-схемы, компилит TS, пакует и пушит в Yandex. Добавь cron в репо для автотестов. Для пет-проекта это значит: коммитнул - задеплоилось, cron запустился.

    Пайплайн триггерится на push в main. Yarn install, tsc, тесты с Zod, yc deploy. Секреты (токены Yandex) в GitHub Secrets. Результат: функция обновлена за 2 минуты, без локальной возни. Идеально для бота на Node.js, который парсит ИИ-новости.

    # .github/workflows/deploy.yml
    name: Deploy to Yandex
    on: [push]
    jobs:
      deploy:
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v2
        - uses: actions/setup-node@v2
          with: { node-version: 20 }
        - run: yarn install
        - run: yarn build
        - uses: yandex-cloud/actions-serverless@v1
          with:
            function-id: ${{ secrets.FUNCTION_ID }}
            service-account: ${{ secrets.SA_KEY }}
    
    • Триггер на cron: добавь schedule: [{ cron: '0 2 * * *' }] для ночных деплоев.
    • Тестируй локально: serverless-offline или Yandex emulator.
    • Мониторинг: интегрируй с Telegram-ботом на ошибки.

    Фича 2026: Yandex добавил native TS-support, но Actions все равно надежнее.

    Готовый стек для пет-проекта: от парсера до релиза

    Собери все: функция на TS валидирует event через Zod, cron дергает ежечасно, Actions деплоит автоматически. Тестировал на парсере Reddit-трендов - летает без сбоев. Экономит 10+ часов в неделю на рутину, код чище, данные безопасны.

    Масштабируй: добавь несколько функций, одну на парсинг, другую на ИИ-анализ. Осталось доработать retry-логику в cron и интеграцию с внешними API вроде OpenAI. В 2026 такие пайплайны - must-have для full-stack энтузиастов.


    0 0 0 Ответить
Популярные темы:

  • Критическая уязвимость в React.js Next.js (CVE-2025-55182, CVE-2025-66478): Как защитить свой сайт
    AladdinA
    Aladdin
    7
    12
    1.2k

  • Полный гайд по работе с NodeBB CLI
    D
    DeepSeeker
    6
    3
    143

  • for или foreach в javascript: в каких случаях что использовать
    D
    DeepSeeker
    5
    2
    147

  • Подготовка к собесам фронтенд
    Dastan SalmurzaevD
    Dastan Salmurzaev
    5
    5
    186

  • Передача типов в TypeScript в под функции
    kirilljsxK
    kirilljsx
    4
    5
    215

  • Исчерпывающее руководство по конфигурации Nginx
    undefined
    4
    1
    178

  • Проверка стала проще с Zod: как обеспечить точность и качество форм
    kirilljsxK
    kirilljsx
    3
    8
    1.0k

  • Bruno - новый клиент для API (Замена PostMan Insomnia)
    ManulM
    Manul
    3
    2
    1.7k

  • Vue.js и React — необычное сравнение
    D
    DeepSeeker
    3
    10
    1.0k

  • Оптимизация React js приложений. Использование функции debounde()
    ManulM
    Manul
    3
    5
    519

  • Провайдеры в Nest JS - 1.3
    undefined
    3
    1
    339

  • Полный гайд по команде LFTP: Работа с локальными и удалёнными серверами
    undefined
    3
    1
    538

Пользователи в Сети:

GameFishG
GameFish
kirilljsxK
kirilljsx

Статистика:

38

В сети

279

Пользователи

1.7k

Темы

2.6k

Сообщения

Категории

  • Главная
  • Новости
  • Фронтенд
  • Бекенд
  • Языки программирования

Контакты

  • Сотрудничество
  • info@exlends.com

© 2024 - 2026 ExLends, Inc. Все права защищены.

Политика конфиденциальности
  • Войти

  • Нет учётной записи? Зарегистрироваться

  • Войдите или зарегистрируйтесь для поиска.
  • Первое сообщение
    Последнее сообщение
0
  • Лента
  • Категории
  • Последние
  • Метки
  • Популярные
  • Пользователи
  • Группы