⌨️ Git Aliases: как перестать печатать длинные команды?

Если ты ловишь себя на том, что в сотый раз за день вводишь git status или git commit -m "...", пора признать: лень — двигатель прогресса. В Git можно создавать свои короткие псевдонимы (алиасы), превращая сложные конструкции в пару букв.

Задача:
— Сократить время на ввод стандартных команд.
— Создать свои «супер-команды», которые объединяют несколько действий в одно.

Решение:

Алиасы настраиваются через глобальный конфиг. После этого они будут работать во всех твоих проектах.

# 1. Самые популярные сокращения
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm "commit -m"

# 2. Продвинутый лог (красивое дерево истории одной командой 'git lg')
git config --global alias.lg "log --graph --oneline --all --decorate"

# 3. Как это использовать в терминале:
git st          # вместо git status
git co main     # вместо git checkout main
git cm "feat: add login"

Почему это маст-хэв?
— Скорость — git lg за секунду показывает всю структуру веток, которую в обычном логе не разобрать.
— Меньше опечаток — чем короче команда, тем меньше шанс ошибиться в буквах.
— Кастомизация — ты можешь настроить Git под свой стиль работы, как удобное кресло.

Совет: Если ты хочешь посмотреть все свои текущие алиасы, введи git config --get-regexp alias. А если работаешь в Zsh или Oh My Zsh, там уже встроены сотни готовых сокращений (например, gst для статуса).

🔥 — если твой .gitconfig уже забит алиасами
🤝 — если до сих пор пишешь команды целиком для тренировки памяти

➡️ GitHub Ready | #урок

MathCode

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

Случайно наткнулся на опенсорс-проект под названием MathCode. Он принимает описание математической задачи на естественном языке и автоматически конвертирует его в теоремы для Lean 4, после чего пытается завершить формальное доказательство.

Проще говоря, это ассистент для доказательства теорем прямо в терминале. Вводишь фразу вроде «Докажи, что квадрат чётного числа — чётный», и он сам проходит весь пайплайн: от формализации до доказательства.

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

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

Если интересна формальная верификация математики или вы используете Lean 4 и считаете ручной процесс слишком трудоёмким, этот инструмент стоит попробовать.

➡️ Cсылка на GitHub

🌲 Git Worktree: как работать в двух ветках одновременно?

Представь ситуацию: ты пишешь огромную фичу в ветке feature, у тебя открыты десятки файлов, проект запущен. Вдруг прилетает критический баг в main, который нужно поправить прямо сейчас. Обычно ты делаешь stash, переключаешься на main, правишь, возвращаешься и делаешь stash pop. Это долго и сбивает фокус.

Задача:
— Работать над main и feature одновременно.
— Иметь две разные папки на компьютере для одного и того же репозитория.

Решение:

Команда git worktree позволяет «развернуть» любую ветку в отдельную соседнюю папку. Ты просто открываешь её во втором окне IDE.

# 1. Создаем отдельную папку для ветки hotfix (Git сам создаст папку и переключит ветку)
git worktree add ../my-project-hotfix main

# 2. Теперь у тебя на компьютере два независимых рабочих пространства:
# - ~/projects/my-project (твоя текущая фича)
# - ~/projects/my-project-hotfix (чистый main для правок багов)

# 3. Когда баг исправлен и запушен, удаляем рабочее дерево
git worktree remove ../my-project-hotfix

Почему это киллер-фича?
— Никаких переключений — тебе не нужно останавливать сервер, пересобирать зависимости (npm install) или прятать код в stash.
— Параллельные тесты — ты можешь запустить тесты в одной папке и продолжать писать код в другой.
— Чистота — файлы не перемешиваются, ты не рискуешь случайно закоммитить код фичи в ветку багфикса.

Совет: Чтобы посмотреть список всех активных рабочих деревьев, используй команду git worktree list. Это поможет не забыть удалить старые папки, когда они станут не нужны.

🔥 — если worktree звучит как спасение для больших проектов
🤝 — если по старинке клонируешь репозиторий второй раз в новую папку

➡️ GitHub Ready | #урок

🚀 Turborepo: Как собирать гигантские проекты за пару секунд?

Когда у тебя в монорепозитории лежат три приложения и пять общих библиотек, обычный запуск тестов или сборка (build) превращаются в пытку. Ты меняешь одну строчку в UI-китовой кнопке, а твой компьютер начинает пересобирать вообще всё.

Задача:
— Перестать тратить по 10 минут на ожидание билда в CI/CD и локально.
— Запускать только те задачи, которые реально затронуты изменениями.

Решение:

Внедряем Turborepo — инструмент, который превращает выполнение скриптов в умный и кэшируемый процесс.



1. Умное кэширование (Caching)
Turborepo запоминает хэш файлов и результат их сборки.
— Если ты нажал build, он собрал проект.
— Ты ничего не менял и нажал build снова? Turborepo отдаст результат из кэша мгновенно.
— Кэш можно шерить с коллегами через облако: если кто-то один собрал ветку, остальным скачается готовый билд.

2. Граф зависимостей (Task Graph)
Ты объясняешь Turbo, как связаны твои задачи. Например: «Не собирай веб-сайт, пока не готова библиотека стилей». Он сам построит оптимальный маршрут и запустит всё параллельно, где это возможно.

3. Нулевая настройка
Тебе не нужно переписывать весь проект. Достаточно добавить один файл turbo.json, где ты описываешь, какие папки (например, dist) нужно кэшировать и от чего зависят твои команды.

Почему это маст-хэв?
— Экономия времени: билд в CI/CD сокращается с минут до секунд.
— Фокус на коде: тебе не нужно помнить, какие пакеты нужно пересобрать после изменений — Turbo сделает это за тебя.
— Кросс-платформенность: работает одинаково быстро и на Mac, и на Linux, и в облачных пайплайнах.

Совет: Чтобы начать, просто введи npx turbo build. Он подхватит настройки твоих воркспейсов (NPM, Yarn или PNPM) и сразу начнет кэшировать задачи.

🔥 — если уже ощутил мощь кэша в CI/CD
🤝 — если по старинке ждешь сборку и пьешь чай

➡️ GitHub Ready | #урок

⚔️ Nx vs Turborepo: Что выбрать для проекта в 2026?

Если ты решил переезжать на монорепозиторий, перед тобой два главных игрока. В 2026 году разрыв между ними стал еще понятнее: это битва между «простотой и скоростью» и «инфраструктурой на стероидах».

Задача:
— Выбрать инструмент, который не станет обузой через год.
— Понять, нужна ли тебе просто быстрая сборка или полноценная экосистема.

Решение:

Выбор зависит от того, насколько «умным» должен быть твой репозиторий.



1. Turborepo (Скорость и простота)
Это «гоночный болид» от Vercel. Его главная цель — сделать билд максимально быстрым.
— Плюсы: Настройка за 10 минут. Он не лезет в структуру твоего кода, а просто кэширует задачи. Идеально для JS/TS проектов на 5–50 пакетов.
— Минусы: Меньше инструментов для контроля архитектуры. В 2026 году он всё еще остается в основном в рамках экосистемы Node.js.

2. Nx (Мощность и контроль)
Это «швейцарский нож» и целая платформа. Nx не просто запускает задачи, он понимает связи между каждой строчкой кода.
— Плюсы: В 2026 году Nx внедрил AI-агентов для самолечения билдов и детекции багов. Он поддерживает не только JS, но и Python, .NET, Go. Есть генераторы кода и строгие правила: например, можно запретить библиотеке UI зависеть от API-клиента.
— Минусы: Высокий порог входа. Конфигов будет больше, и тебе придется выучить «путь Nx».

Что выбрать?
— Выбирай Turborepo, если у тебя небольшая или средняя команда, вы пишете только на TS и вам просто нужно, чтобы npm run build не шел вечность.
— Выбирай Nx, если у тебя огромный энтерпрайз, разные языки программирования (Polyglot) и ты хочешь, чтобы инструмент сам генерировал код и следил за архитектурными границами.

Совет: В 2026 году оба инструмента поддерживают удаленное кэширование. Это значит, что если твой CI собрал проект, тебе не нужно собирать его локально — ты просто скачаешь готовый результат.

🔥 — если за минимализм Turborepo
🛠 — если любишь мощь и порядок Nx

➡️ GitHub Ready | #урок

🕸 Граф зависимостей: как увидеть хаос в своём проекте?

Когда в монорепозитории становится больше 10 пакетов, понимать, что от чего зависит, становится невозможно. Кто-то импортировал тяжелую библиотеку в легкий UI-кит, и теперь сборка фронтенда тянет за собой половину бэкенда. Чтобы не гадать, нужно визуализировать Dependency Graph.

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

Решение:

Современные инструменты (Nx, Turborepo, Madge) умеют строить интерактивные карты твоего кода.



Как это сделать?

— В Nx: просто введи npx nx graph. Откроется браузер с крутой интерактивной схемой, где можно кликнуть на любой проект и увидеть, кто его использует.
— В Turborepo: используй npx turbo build --graph. Он создаст файл (например, в формате PDF или DOT), который покажет путь выполнения задач.
— Для обычного JS/TS: библиотека Madge. Команда npx madge --image graph.png src/index.ts нарисует связи между твоими файлами.

Почему это важно?

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

Совет: В 2026 году графы стали «умными». Теперь они показывают не только связи кода, но и время сборки каждого узла. Если какой-то квадрат на схеме горит красным — значит, именно он тормозит всю твою команду.

🔥 — если любишь рассматривать графы своего проекта
🤝 — если и так держишь всю структуру в голове

➡️ GitHub Ready | #урок

🛡 Module Boundaries: Как запретить «плохие» импорты?

В больших проектах часто случается архитектурный кошмар: кто-то случайно импортировал логику из backend в frontend или заставил общую UI-библиотеку зависеть от специфичного бизнес-кейса. Это превращает код в запутанный узел. Module Boundaries — это автоматические правила, которые бьют по рукам за такие связи.

Задача:
— Установить четкие границы между слоями (Shared, Features, Apps).
— Гарантировать, что стабильные библиотеки не зависят от изменчивых фич.
— Пресечь появление циклических зависимостей на корню.

Решение:

Мы используем теги и правила линтера (ESLint), чтобы софт сам проверял архитектуру при каждой попытке импорта.



Как это работает (на примере Nx):

1. Раздаем теги: В конфиге каждого модуля прописываем его роль. Например, type:ui для компонентов и type:app для приложений.
2. Описываем правила: В .eslintrc.json добавляем логику:
— type:ui может зависеть только от других type:ui.
— type:app может зависеть от чего угодно.
— Запрещено: type:ui -> type:app.

Почему это спасает проект?

— Чистая архитектура: ты физически не сможешь создать импорт, который нарушает правила. IDE подсветит ошибку красным еще до того, как ты сохранишь файл.
— Ускорение тестов: если модули изолированы, при изменении одного компонента нужно тестировать только его, а не всё дерево зависимостей.
— Масштабируемость: новые разработчики не смогут случайно испортить структуру проекта, потому что правила «зашиты» в код.

Совет: Если ты не используешь Nx, похожую логику можно настроить с помощью плагина eslint-plugin-import и правила no-restricted-imports, либо через инструмент Sheriff. Это превращает архитектурные гайдлайны из пожеланий в закон.

🔥 — если за жесткий порядок в импортах
🤝 — если полагаешься на сознательность коллег на ревью

➡️ GitHub Ready | #урок

🔄 Type-Safe Sync: как подружить фронтенд и бэкенд без боли?

Самая частая причина багов в больших проектах — когда бэкенд изменил структуру ответа (API), а фронтенд об этом не узнал. Ты ждешь user.id, а прилетает user.uuid. Чтобы не переписывать типы вручную каждый раз, нужно использовать автогенерацию кода.

Задача:
— Гарантировать, что фронтенд всегда знает актуальные форматы данных бэкенда.
— Перестать писать API-клиенты (fetch/axios запросы) руками.
— Ловить ошибки несовместимости типов еще на этапе компиляции, а не в продакшене.

Решение:

Используем схему как «единый источник правды». Бэкенд описывает API, а фронтенд автоматически скачивает готовые типы и функции.



Как это реализовать в 2026 году?

— Swagger / OpenAPI: если бэк на Java, Python или Go, он генерирует openapi.json. Фронтенд запускает openapi-typescript и получает готовые интерфейсы.
— tRPC: если и фронт, и бэк на TypeScript, это ультимативное решение. Ты просто импортируешь типы роутов бэкенда во фронтенд. Если на бэкенде изменится поле в базе — фронтенд сразу «покраснеет» от ошибок в IDE.
— Zod + TanStack Query: бэкенд отдает схему валидации, а фронтенд использует её, чтобы гарантировать: данные, пришедшие извне, именно те, что мы ждем.

Почему это маст-хэв?

— Минус 90% багов на стыке систем: типизация пронизывает всё приложение насквозь.
— Скорость разработки: разработчику фронтенда не нужно лезть в документацию или Postman. IDE сама подскажет все доступные поля и методы через автодополнение.
— Автоматический рефакторинг: поменял название поля на бэкенде — и твоя IDE сразу покажет все места на фронте, где это поле нужно переименовать.

Совет: В 2026 году стандарт де-факто для TS-проектов — это tRPC или Kysely для связи с БД. Если у вас до сих пор «договорняки» в Телеграме о том, какое поле придет в JSON — самое время внедрить генерацию из схем.

🔥 — если за полную типизацию от БД до кнопки
🤝 — если доверяешь any и своей интуиции

➡️ GitHub Ready | #урок

📦 Оптимизация Docker: как сжать образ в 10 раз?

Если твой Docker-образ весит 1 ГБ, он медленно качается, долго деплоится и ест лишнее место на сервере. В 2026 году стандарт индустрии — это Multi-stage builds и использование легковесных базовых образов.

Задача:
— Уменьшить размер финального образа.
— Оставить в продакшене только скомпилированный код без лишнего мусора (исходников, кэша npm).

Решение:

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

# Этап 1: Сборка (Build)
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Этап 2: Финальный образ (Production)
FROM node:20-alpine
WORKDIR /app
# Копируем только билд и зависимости для продакшена
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm install --omit=dev

CMD ["node", "dist/main.js"]

Почему это работает?

— Alpine Linux: вместо тяжелого Debian (200 МБ+) мы берем Alpine (всего 5 МБ).
— Отсечение лишнего: в финальный образ не попадают src, tsconfig.json и тяжелые devDependencies (типы, линтеры, тесты).
— Слои: Docker кэширует каждый шаг. Если ты не менял package.json, этап установки зависимостей пролетит мгновенно.

Результат:
Образ на базе стандартного Node.js может весить 800+ МБ, а оптимизированный через Multi-stage и Alpine — всего 80–120 МБ.

Совет: Используй файл .dockerignore, чтобы Docker даже не пытался копировать в контекст сборки папку node_modules или логи с твоего компьютера. Это еще сильнее ускорит процесс.

🔥 — если выжимаешь максимум из каждого байта
🤝 — если не паришься и просто берешь node:latest

➡️ GitHub Ready | #урок

🛡 Distroless: Как сделать образ, который невозможно взломать?

Если тебе кажется, что Alpine (5 МБ) — это предел, то познакомься с Distroless от Google. Это образы, в которых нет вообще ничего: ни оболочки (sh/bash), ни пакетного менеджера, ни даже команды ls или cd. Только твое приложение и его зависимости.

Задача:
— Уменьшить размер образа до абсолютного минимума.
— Максимально защитить сервер: если хакер попадет внутрь контейнера, он не сможет выполнить ни одной команды, так как терминала просто не существует.

Решение:

Используем Multi-stage билд, но в качестве финального образа берем gcr.io/distroless.

# Этап 1: Сборка проекта
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Этап 2: Финальный защищенный образ
FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app /app
WORKDIR /app

CMD ["dist/main.js"]

Почему это киллер-фича?

— Безопасность: В обычном образе хакер может скачать вредоносный скрипт через curl или wget. В Distroless этих утилит нет. Там нет даже rm, чтобы замести следы.
— Вес: Образ становится еще легче, так как вырезаны все системные библиотеки, не нужные для работы Node.js, Python или Java.
— Скорость: Чем меньше слоев и файлов, тем быстрее образ проверяется сканерами безопасности и разворачивается в кластере.

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

Совет: Если тебе всё же нужно «зайти» внутрь такого контейнера для отладки, используй временные контейнеры (Ephemeral Containers) в Kubernetes или специальные инструменты отладки, так как обычный docker exec -it ... sh выдаст ошибку.

🔥 — если безопасность на первом месте
🤝 — если важнее иметь возможность зайти в контейнер и «посмотреть, что там»

➡️ GitHub Ready | #урок

К такому не подготовишься 😱

🔔 Uptime Kuma: Как узнать о падении сервиса раньше пользователей?

Нет ничего хуже, чем узнать о том, что твой проект "лежит", из гневных сообщений в личке. Чтобы не проверять сайт каждые пять минут вручную, разработчики ставят Uptime Kuma — это стильный и бесплатный self-hosted мониторинг, который сделает всё за тебя.

Задача:
— Круглосуточно следить за доступностью сайтов, контейнеров и баз данных.
— Получать мгновенные уведомления в Telegram, Discord или Slack, если что-то сломалось.
— Видеть красивую статистику аптайма и времени отклика (пинг).

Решение:

Разворачиваем одну из самых популярных опенсорс-панелей мониторинга за пару минут через Docker.

# Запуск Uptime Kuma в Docker
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Что она умеет?

— Разные типы проверок: HTTP(s), TCP, Ping, DNS, и даже проверка срока действия SSL-сертификата (она напомнит, когда пора его продлевать).
— Уведомления: Поддерживает более 90 сервисов. Самый простой вариант — создать бота в Telegram и вставить его токен.
— Status Page: Можно создать публичную страницу (как у больших сервисов), чтобы пользователи сами видели: сейчас идут технические работы или всё "зеленое".
— Proxy-поддержка: Легко работает за Nginx или Traefik.

Почему это лучше внешних сервисов?

— Бесплатно: Никаких лимитов на количество проверяемых сайтов или частоту запросов.
— Приватность: Все данные о твоих серверах хранятся только у тебя.
— Скорость: Ты можешь проверять локальные сервисы внутри своей сети, которые не видны из интернета.

Совет: Установи интервал проверки в 60 секунд. Этого достаточно, чтобы оперативно среагировать на проблему и при этом не создавать лишнюю нагрузку на сервер постоянными запросами.

🔥 — если следишь за каждым процентом аптайма
🤝 — если узнаешь о падении только от клиентов

➡️ GitHub Ready | #урок

📜 Dozzle: Как читать логи всех контейнеров в одном окне?

Когда у тебя запущено много сервисов, прыгать между ними через docker logs становится мучительно. Если Lazydocker хорош для терминала, то Dozzle — это идеальный веб-интерфейс для тех, кто хочет просто и быстро просматривать логи через браузер.

Задача:
— Видеть логи всех контейнеров в реальном времени в одном месте.
— Иметь возможность быстрого поиска по тексту во всех логах сразу.
— Не нагружать сервер тяжелыми системами вроде ELK (Elasticsearch, Logstash, Kibana).

Решение:

Dozzle — это крошечный сервис, который подключается к Docker-сокету и выводит всё в удобный UI.

# Запуск Dozzle за одну секунду
docker run -d --name dozzle -p 8888:8080 -v /var/run/docker.sock:/var/run/docker.sock amir20/dozzle:latest

Почему это удобно?

— Интеллектуальный поиск: ты можешь мгновенно отфильтровать логи по ключевому слову (например, Error или Timeout) сразу по всем запущенным контейнерам.
— Никакой базы данных: Dozzle не хранит логи на диске, он просто транслирует их. Это значит, что он практически не потребляет ресурсы сервера.
— Живой поток: логи подгружаются мгновенно без перезагрузки страницы.
— Простота: не нужно ничего настраивать в самих контейнерах — Dozzle сам подхватит всё, что запущено на хосте.

Кому это нужно?

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

Совет: Если ты выставляешь Dozzle в интернет, обязательно закрой его паролем через Reverse Proxy (например, Nginx или Traefik), так как в логах могут проскакивать конфиденциальные данные.


🔥 — если любишь чистоту и порядок в логах
🤝 — если по-прежнему грепаешь текстовые файлы в /var/lib/docker/containers

➡️ GitHub Ready | #урок

200 тыс.₽ сейчас РЕАЛЬНО базовый минимум ⏺️

Который нужен для комфортной жизни в любом месте⤵️

Не знаешь, где словить такой куш?

Удаленка в долларах 💸 — канал для профи из СНГ с вакансиями в стабильной валюте.

IT, маркетинг, дизайн, крипта: ты точно в этом разбираешься

Осталось только начать нормально зарабатывать!

15+ актуальных вакансий за сегодня уже в канале:
https://t.me/+qoCsrhInumQyN2Ni 🔗

🤖 Watchtower: Как забыть об обновлении Docker-контейнеров?

Обновление контейнеров вручную — это рутина: нужно зайти на сервер, сделать docker pull, остановить старый контейнер и запустить новый. В 2026 году это делает Watchtower. Он следит за выходом новых версий твоих образов в Docker Hub или другом реестре и сам перезапускает сервисы.

Задача:
— Всегда иметь актуальные версии софта и патчи безопасности.
— Автоматизировать процесс обновления без участия человека.
— Избежать простоев из-за ручного переповтора команд.

Решение:

Запускаем один контейнер Watchtower, который будет мониторить все остальные.

# Запуск Watchtower для автоматического обновления всех контейнеров
docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Почему это удобно?

— Полная автономия: он сам проверяет наличие обновлений, скачивает их и перезапускает контейнер с теми же параметрами (те же порты, вольюмы и сети).
— Очистка мусора: с флагом --cleanup он удаляет старые образы после обновления, чтобы они не занимали место на диске.
— Выборочность: если ты не хочешь обновлять какой-то конкретный сервис (например, базу данных, где важна стабильность), просто добавь ему лейбл com.centurylinklabs.watchtower.enable=false.
— Уведомления: Watchtower может присылать отчеты об обновлениях прямо в Telegram.

Кому это нужно?

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

Совет: Будь осторожен с обновлением баз данных (PostgreSQL, MySQL) в автоматическом режиме. Мажорные версии (например, с 15 на 16) могут требовать миграции данных, поэтому для них автообновление лучше отключать.

🔥 — если за полную автоматизацию
🤝 — если предпочитаешь обновлять всё под своим контролем

➡️ GitHub Ready | #урок

NtWARden

NtWARden — набор инструментов для анализа и исследования Windows

Инструмент инспекции системы Windows на базе ImGui + DirectX 11, поддерживает работу как в пользовательском режиме, так и в режиме ядра.

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

Cсылка на GitHub

➡️ GitHub Ready | #урок