Я храню список своих факапов...

У меня есть файл. Называется "failures .md". Там лежат все мои ошибки за последние годы.

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

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

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

Некоторые коллеги говорят, что это паранойя. Но когда в очередной раз кто-то наступает на те же грабли, я открываю свой файл и скидываю ссылку: "Почитай, у меня уже было".

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

А вы ведёте дневник ошибок или полагаетесь на память?

🌐 @helcode

Три вещи, которые я проверяю, когда сервер тормозит

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

Переписывал запросы, оптимизировал функции, добавлял кэши там, где они не нужны. А потом выяснялось, что проблема была вообще не в коде. Просто кто-то запустил бекап в "час пик" или диск забился логами.

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

Первое - память.

Самый частый сценарий: какой-то процесс утёк и сожрал всю оперативку. Система начинает свопиться - сбрасывать данные на диск. А диск даже самый быстрый - это не оперативная память. Всё встаёт колом.

Смотрю free -h. Если used почти равно total, а swap использован - значит, память под завязку. Дальше htop показывает, кто жрёт. Часто помогает простой перезапуск проблемного процесса, чтобы выиграть время на поиск настоящей причины.

Второе - диск.

Бывает, памяти дофига, процессор простаивает, а сервер еле шевелится. Это классический I/O wait - процессы висят в очереди на чтение или запись.

Смотрю iotop. Если вижу, что какой-то процесс постоянно долбит диск на максимальной скорости - вот он, виновник. Чаще всего это:

- Забытый бекап, который решил запуститься в обед
- Логи, которые пишутся в один файл без ротации годами
- База, которая выполняет тяжёлый запрос и не влезает в память

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

Третье - сеть.

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

Смотрю mtr до сервера из внешней точки. Если потери начинаются на конкретном узле до моего железа - вопрос к провайдеру. Если на самом сервере - проверяю загрузку сетевого интерфейса через iftop.

Что дальше

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

А вы с чего начинаете диагностику?

🌐 @helcode

Makefile: единый интерфейс для команд проекта

Каждый проект обрастает набором команд для установки, тестирования и запуска. Хранить их в памяти или в wiki - неэффективно. Makefile позволяет собрать все команды в одном месте и сделать их доступными через короткие алиасы.

Новый разработчик в проекте выполняет make help и видит все доступные операции.

* Вариант 1 (Python-проект): сокращение часто используемых команд.

.PHONY: install run test clean

install:
  pip install -r requirements.txt
  
run:
  python app.py
  
test:
  pytest tests/
  
clean:
  find . -type d -name "__pycache__" -exec rm -rf {} +

* Вариант 2 (Node.js + Docker): объединение нескольких шагов в один.

.PHONY: docker-build docker-run logs

docker-build:
  docker build -t myapp .

docker-run: docker-build
  docker run -p 3000:3000 myapp

logs:
  docker logs myapp-container

Makefile работает как документация. Если команда сложная, ее не нужно искать в истории терминала - она записана и всегда под рукой.

Используете ли вы Makefile в проектах, не связанных с C/C++?

P.S. Make умеет отслеживать изменения файлов и перезапускать только те команды, которые действительно нужны.

Важно! На Boosty расписал пост подробно. Телеграм имеет определенные ограничения на длину.

Я в Telegram - t.me/helcode
Я в VK - vk.com/helcode
Я на Boosty - boosty.to/helcode

Pre-commit хуки: автоматические проверки до коммита

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

Pre-commit хуки запускают проверки автоматически и не дают создать коммит, если код не соответствует стандартам.

➤ Вариант 1 (Базовый конфиг для Python): автоматическое приведение кода к единому стилю.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.4.0
    hooks:
      - id: trailing-whitespace  # Удаляет пробелы в концах строк
      - id: end-of-file-fixer     # Добавляет перевод строки в конце файла
  - repo: https://github.com/psf/black
    rev: 23.1.0
    hooks:
      - id: black                 # Форматирует код

➤ Вариант 2 (Проверка секретов): блокировка коммита с потенциальными ключами доступа.

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets

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

Есть ли у вас в проекте автоматические проверки перед коммитом?

P.S. Конфигурация pre-commit хранится в репозитории, поэтому все разработчики в команде используют одинаковые проверки.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Bash-скрипты для регулярных операций

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

Скрипт можно запустить вручную или по расписанию через cron. Результат всегда предсказуем.

➤ Вариант 1 (Бэкап БД с ротацией):

#!/bin/bash
BACKUP_DIR="/backups/postgres"
DB_NAME="myapp"
DATE=$(date +%Y%m%d_%H%M%S)

# Создание дампа
pg_dump $DB_NAME > $BACKUP_DIR/db_backup_$DATE.sql

# Сжатие
gzip $BACKUP_DIR/db_backup_$DATE.sql

# Удаление бэкапов старше 7 дней
find $BACKUP_DIR -name "db_backup_*.sql.gz" -mtime +7 -delete

echo "Backup completed: db_backup_$DATE.sql.gz"

➤ Вариант 2 (Синхронизация с S3):
tar -czf logs_$(date +%Y%m%d).tar.gz /var/log/myapp && aws s3 cp logs_$(date +%Y%m%d).tar.gz s3://myapp-logs-bucket/ --storage-class STANDARD_IA

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

Что в ваших проектах автоматизировано скриптами, а что до сих пор делается вручную?

P.S. Добавление в скрипты проверок кодов возврата (set -e) и логирования делает их пригодными для использования в промышленной среде.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

GitLab CI: автоматизация сборки и доставки

Ручной деплой на сервер требует запоминания последовательности команд и несет риск ошибки из-за человеческого фактора. CI/CD-пайплайны делают процесс воспроизводимым: одна и та же последовательность шагов выполняется каждый раз.

GitLab CI встроен в систему контроля версий, что позволяет привязать деплой к событиям в репозитории.

➤ Вариант 1 (Тесты и деплой на staging):

# .gitlab-ci.yml
stages:
  - test
  - deploy

run_tests:
  stage: test
  script:
    - npm install
    - npm run test

deploy_staging:
  stage: deploy
  script:
    - rsync -avz --delete ./ user@staging-server:/var/www/html/
  only:
    - develop

➤ Вариант 2 (Ручной деплой на продакшн по тегу):

deploy_production:
  stage: deploy
  script:
    - ansible-playbook -i prod.inventory deploy.yml
  only:
    - tags
  when: manual

Пайплайн гарантирует, что код перед попаданием на продакшен проходит все необходимые проверки в одинаковом окружении.

Кто выполняет деплой в вашей команде - разработчик или CI-система?

P.S. В GitLab CI можно переиспользовать шаблоны через include, чтобы не дублировать код пайплайнов в разных проектах.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Управление зависимостями Python: фиксация версий

Обновление пакетов в Python-проекте без системы управления зависимостями часто приводит к неожиданным поломкам. Пакет обновляется, тянет за собой другие версии библиотек, и приложение перестает работать.

Современные инструменты разделяют понятия "зависимости, которые нам нужны" и "конкретные версии, которые установлены".

* Вариант 1 (Poetry):

# Команды для работы с зависимостями
poetry add requests@latest          # Добавление или обновление пакета
poetry update                       # Обновление всех пакетов в рамках ограничений
poetry export -f requirements.txt --output requirements.txt # Экспорт для Docker

* Вариант 2 (pip-tools): pазделение на прямые и транзитивные зависимости.

# update_deps.sh
pip-compile requirements.in  # Генерация requirements.txt с фиксированными версиями
pip-sync requirements.txt    # Приведение окружения к состоянию из requirements.txt

Фиксация версий через lock-файлы гарантирует, что у всех разработчиков и на сервере будет одинаковый набор библиотек.

Используете ли вы pip freeze или более продвинутые инструменты для управления зависимостями?

P.S. Файл с зафиксированными версиями (poetry.lock или requirements.txt) должен быть в репозитории, а файл с верхнеуровневыми зависимостями (pyproject.toml или requirements.in) - тем более.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Vagrant: изоляция через виртуальные машины

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

Vagrant позволяет поднимать виртуальные машины с заданными параметрами и автоматически их настраивать.

* Вариант 1 (Веб-сервер под Ubuntu):

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/focal64"
  config.vm.network "private_network", ip: "192.168.56.10"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
    vb.cpus = 2
  end
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y apache2
  SHELL
end

* Вариант 2 (Кластер из двух машин): поднятие взаимодействующих серверов для тестирования распределенных приложений.

vagrant up создает чистую среду, vagrant destroy полностью ее удаляет. Это позволяет тестировать установку и настройку с нуля без захламления основной системы.

Для каких задач в вашей команде используют виртуальные машины вместо контейнеров?

*P.S. Vagrant работает поверх VirtualBox, VMware или гипервизоров облачных провайдеров, предоставляя единый интерфейс управления.*

🌐 @helcode

ERR в bash: отлавливаем ошибки там, где set -e бессилен

Все знают про set -e, который прерывает скрипт при первой ошибке. Но у него есть особенности: он срабатывает не на все ошибки, и его поведение может меняться в зависимости от контекста. Например, ошибка в конвейере (`cmd1 | cmd2`) не остановит скрипт, если не включен set -o pipefail. Или ошибка в условии if — там set -e вообще игнорируется.

Но есть механизм, который дает полный контроль над обработкой ошибок — ловушка ERR. trap 'echo "Ошибка в строке $LINENO"' ERR сработает при любой ошибке выполнения команды, независимо от настроек set -e. Причем вы получите номер строки, где это случилось.

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

Важно помнить: ловушка ERR не ловит ошибки в функциях, если они вызываны в подшеллах. И если вы явно игнорируете ошибку через cmd || true, ERR тоже не сработает.

Как вы обрабатываете неожиданные ошибки в скриптах — надеетесь на set -e или пишете полноценные обработчики?

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Midnight Commander - это та утилита, которая кажется бессмысленной, пока не появится задача на сервере, где нужно быстро перекинуть 50 файлов из одной папки в другую. cp -r с кучей флагов - это долго. А в mc это делается секунд за 10.

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

Запустили mc - две панели. Левая папка, правая папка. Стрелки - навигация. Tab - переключить панель. F5 - копировать, F6 - переместить, F7 - создать папку, F8 - удалить. Всё.

Где реально выручает

· Выборочное копирование. Нужно из 500 файлов перенести 20 конкретных? Отмечаем их пробелом, жмём F5 - готово.
· Редактирование на месте. Нажали F4 - открылся редактор с подсветкой. Поправили конфиг - Ctrl+S, F10 - вышел.
· Архивы. Нажали Enter на .tar.gz - внутри, как в обычной папке. Копируем файлы наружу, не распаковывая всё.

Скрытые плюсы

· Alt+O - открыть текущую папку на второй панели. Удобно, когда нужно скопировать файл в параллельную ветку.
· Внизу можно писать команды, не выходя из mc. Например, tar -czf backup.tar.gz * - и архив готов.
· Мышь работает, но лучше привыкнуть к клавишам.

Если вы помните все флаги rsync и find - mc не нужен. Если нет - ставится одной командой и экономит время каждый раз, когда нужно что-то переложить на сервере.

P.S. Прошу прощения за несколько уведомлений, Телеграм решил, что не будет планировать мой пост, а дропнет сразу…

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

fzf: поиск, который работает везде

Каждый день мы ищем: файлы в проекте, команды в истории, процессы для убийства. grep находит, но не выбирает. fzf добавляет интерактивный поиск с нечетким сопоставлением туда, где его раньше не было.

Утилита принимает список строк на вход, а на выходе отдаёт выбранную.

➤ Вариант 1 (Поиск по истории команд): привязка к Ctrl+R превращает поиск в истории из слепого перебора в интерактивную прогулку.

# Добавить в .bashrc или .zshrc
bind '"\C-r": "\C-e \C-u history | fzf --tac --no-sort | xargs -I {} echo {}"'

➤ Вариант 2 (Быстрый переход в папку): больше не нужно помнить, где лежит проект, запущенный месяц назад.

# Переход в любую папку в проектах
cd $(find ~/projects -type d 2>/dev/null | fzf)

# Или с предпросмотром содержимого
cd $(find ~/projects -type d | fzf --preview 'ls -la {}')

➤ Вариант 3 (Поиск и убийство процесса): нашел процесс глазами — убил, не выходя из поиска.

# Выбрали процесс — отправили SIGTERM
kill -15 $(ps aux | fzf | awk '{print $2}')

# С предпросмотром деталей процесса
kill -15 $(ps aux | fzf --preview 'echo {}' | awk '{print $2}')


fzf работает как пайплайн: слева что угодно (файлы, процессы, строки), справа — действие над выбранным. Один раз настроив, вы получаете интерактивность там, где раньше был только слепой grep.

Используете ли вы интерактивный поиск в терминале или предпочитаете старый добрый Ctrl+R?

*P.S. В zsh можно настроить автодополнение команд через fzf — набираем kill **, нажимаем Tab, и выбираем процесс из списка.*

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode (тут выходит более подробный материал)

ripgrep: grep, который не заставляет ждать

grep хорош, но на больших проектах он тормозит. ripgrep (команда rg`) ищет в 10-20 раз быстрее, умеет игнорировать .gitignore` по умолчанию и выводит результат с контекстом.

Фраза «подожди, я сейчас найду где это используется» — это симптом, который лечится заменой инструмента.

➤ Вариант 1 (Поиск по коду проекта): находит все вызовы функции за доли секунды, даже в проекте с 10k файлов.

# Найти все вызовы calculate_price во всём проекте
rg "calculate_price"

# Только в Python-файлах, игнорируя тесты
rg -t py "calculate_price" -g "!tests/**"

# Найти TODO и показать имя файла и номер строки
rg -n "TODO"

➤ Вариант 2 (Поиск с контекстом и подсветкой): видно не только где, но и что было до и после.

# Показать 3 строки до и после найденного
rg -C 3 "error" logs/application.log

# Только имена файлов, где нашлось
rg -l "password" --hidden

# Подсветка совпадений разными цветами
rg --colors 'match:bg:yellow' "TODO"

➤ Вариант 3 (Замена во всех файлах): безопасная замена с предварительным просмотром.

# Сначала посмотреть, что попадёт под замену
rg "old_function" --files-with-matches

# Потом заменить с бекапом
rg "old_function" --files-with-matches | \
  xargs sed -i.bak 's/old_function/new_function/g'


ripgrep использует SIMD-инструкции и умные алгоритмы поиска. На проекте с 10k файлов он находит всё за секунду, пока grep ещё думает. И главное - он "уважает" .gitignore, поэтому случайно не залезет в node_modules.

Пробовали ли вы rg или остались верны классическому grep?

*P.S. rg отлично дружит с fzf: rg --no-heading "TODO" | fzf — интерактивный поиск по всем TODO в проекте.*

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Короче, веселье. Минцифры решило подключить к блокировке VPN сами сайты и приложения. Не только операторов, а теперь ещё и «Яндекс», VK, Wildberries, Ozon, Сбер, Авито, Wink, ivi и ещё с десяток крупных игроков.

Что от них хотят? Чтобы к 15 апреля они:

- заблокировали доступ пользователям с включенным VPN по спискам РКН
-сами научились выявлять новые способы обхода
- в идеале - вообще отключали весь функционал, если видно VPN

А если не сделают? То лишат IT-льгот, выкинут из «белых списков» и из перечня ПО для предустановки на гаджеты. На мой взгляд - весьма болезненно.

Но есть нюансы, которые мне лично пока непонятны.

Как отличить «плохой» VPN от корпоративного? Технически трудно. То есть человек, который работает из дома через VPN компании, может попасть под блокировку. Просто потому, что система увидит «VPN».

А что с пользователями из Казахстана, Беларуси, Турции? Они без всяких VPN заходят, а алгоритм может решить, что это обход. И все, занавес🤷‍♂️

И главный прикол: требование пока только к крупным. Мелкие сервисы и иностранцы - мимо. То есть аудитория может просто перетечь туда, где не блокируют.

Моё мнение. Я понимаю задачу. Но когда под угрозой оказываются обычные люди с корпоративным VPN или наши же пользователи из-за границы - это уже не про блокировку, а про «лишь бы отчитаться». И пока нет чёткой методики, компании будут откровенно бояться что-то менять.

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

Как только все вопросы устаканятся и появится хоть какая-то ясность - вернемся к активным, разносортным постам и статьям!

P.S. Если Вам нравится мое творчество - буду рад подпискам на иные соцсети😁

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

fd: find, который не требует гуглить синтаксис

find - прекрасный инструмент, но синтаксис у него... мягко говоря специфический. Каждый раз, когда нужно найти что-то сложнее find . -name "*.py", приходится лезть в документацию. fd делает то же самое, но с человеческим интерфейсом.

Запоминать десятки флагов - это когнитивная нагрузка, которая отвлекает от реальной задачи.

➤ Вариант 1 (Поиск файлов по имени): интуитивно понятно даже для тех, кто не помнит синтаксис регулярных выражений.

# Найти все Python-файлы
fd .py

# Найти все файлы readme (регистронезависимо)
fd -i readme

# Найти все файлы с расширением .md или .txt
fd -e md -e txt

➤ Вариант 2 (Поиск с исключениями): игнорировать нужно чаще, чем искать.

# Искать всё, кроме папки tests
fd .py --exclude tests

# Искать, учитывая .gitignore (по умолчанию включено)
fd "config" --hidden  # включает поиск в скрытых папках

➤ Вариант 3 (Выполнить команду над найденным): нашел - сделал, без xargs и экранирования.

# Найти и удалить все .tmp файлы
fd -e tmp -x rm {}

# Найти и показать содержимое каждого найденного файла
fd -e md -x bat {} --style=plain

# Найти и выдать размер каждого файла
fd -e log -x du -h {}


fd по умолчанию игнорирует .gitignore, умеет цветной вывод и поддерживает регулярные выражения. Имена файлов, которые часто ищут (`*.py`, *.md, `*.json`), можно не экранировать. А цветная подсветка помогает сразу отличить файлы от папок.

*P.S. fd отлично работает в паре с fzf: fd | fzf - интерактивный выбор файла из всего проекта.*

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

bat: cat, который показывает код, а не просто текст

cat выводит файл. Всё. Ни подсветки, ни номеров строк, ни навигации. bat делает то же самое, но превращает вывод в читаемый документ с синтаксисом, разметкой и возможностью скроллить.

➤ Вариант 1 (Просмотр кода с подсветкой): синтаксис определяется автоматически под сотню языков.

# Вместо cat app.py
bat app.py

# Принудительно указать язык
bat --language=json config.json

# С нумерацией строк
bat --number app.py

➤ Вариант 2 (Просмотр с Git-аннотацией): видно, кто и когда менял каждую строку.

# Показать изменения относительно последнего коммита
bat --diff app.py

# С Git-блэйд (автор каждой строки)
bat --paging=always --line-range :50 app.py  # первые 50 строк

➤ Вариант 3 (В пайплайнах и скриптах): умное поведение — если вывод не в терминал, bat ведет себя как обычный cat.

# В пайпе не ломает скрипты
rg "error" | bat --language=log

# Сохранить подсвеченный вывод в файл
bat --plain app.py > app.txt  # --plain отключает подсветку


bat поддерживает более 300 языков, автоматически определяет синтаксис и показывает Git-изменения на полях. При этом если вывести bat в пайп или запустить не в терминале, он ведёт себя как обычный cat, не ломая скрипты и автоматизацию.

Сколько раз вы использовали cat и жалели, что нет подсветки синтаксиса?

*P.S. Можно сделать алиас alias cat='bat', но осторожно — в скриптах это может сломаться. Лучше оставить cat для скриптов, а в интерактиве использовать bat.*

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

socat - nc для сетей, который вы заслужили

netcat (nc) знают многие. Но когда задачи становятся сложнее - нужен SSL, нужен форк на несколько соединений, нужна привязка к конкретному интерфейсу - nc пасует. Здесь на сцену выходит socat.

Это как прокаченный nc. Он умеет соединять что угодно с чем угодно: файл с сокетом, TCP с SSL, Unix-сокет с UDP, и даже выполнять команду при подключении.

➤ Вариант 1 (Проброс трафика с одного порта на другой): классический use case для обхода фаерволов.

# Слушаем на 8080, пересылаем на внутренний сервер 3000
socat TCP-LISTEN:8080,fork TCP:localhost:3000

# fork — позволяет обрабатывать несколько соединений

➤ Вариант 2 (Туннель с SSL-терминацией): нужен HTTPS-сервер, а поднимать nginx ради одного эндпоинта — жирно.

# Принимаем HTTPS на 443, внутри отдаём на HTTP 8080
socat OPENSSL-LISTEN:443,cert=server.pem,verify=0,fork TCP:localhost:8080

➤ Вариант 3 (Работа с Unix-сокетами): контейнеры и демоны часто общаются через сокеты, отлаживать их неудобно.

# Подключиться к сокету Docker и отправить запрос
echo 'GET /info HTTP/1.0' | socat - UNIX-CONNECT:/var/run/docker.sock

# Проксировать Unix-сокет в TCP для внешнего доступа
socat TCP-LISTEN:9999,fork UNIX-CONNECT:/var/run/docker.sock

➤ Вариант 4 (Перенаправление ввода-вывода в сеть): передать вывод команды или файл по сети без ssh.

# На стороне получателя: слушаем, сохраняем в файл
socat TCP-LISTEN:1234,fork OPEN:backup.tar.gz,create,append

# На стороне отправителя: читаем файл, шлём
socat OPEN:backup.tar.gz TCP:192.168.1.100:1234

➤ Вариант 5 (Отладка и перехват трафика): посмотреть, что реально передаётся между клиентом и сервером.

# Эхо-сервер для отладки (возвращает то же, что получил)
socat -v TCP-LISTEN:1234,fork STDOUT

# -v выводит весь трафик в stderr
# Можно записывать в файл: 2>traffic.log

➤ Вариант 6 (Выполнение команд по сети): организовать примитивное удалённое управление.

# На сервере: при подключении выполняем скрипт
socat TCP-LISTEN:1234,fork EXEC:/bin/script.sh

# На клиенте: подключаемся, получаем результат
socat - TCP:server:1234

Главный минус socat - синтаксис. Он страшный. Но если освоить базовые паттерны (`TCP-LISTEN`, OPENSSL, `EXEC`), он закрывает сценарии, для которых иначе пришлось бы писать отдельный сервис.

P.S. Самый недооценённый режим: socat -T 60 - таймаут для безответных соединений. Спасает от подвисших сессий.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode (тут посты более подробные)

grep - возможности, о которых вы могли не знать

Все знают grep "что-то" файл. Но в утилите есть тёмные углы, которые превращают её из поиска строк в настоящий анализатор логов и кода.

➤ Вариант 1 (Поиск по временному диапазону в логах): логи обычно начинаются со времени. Нужно вытащить кусок между двумя метками.

# Логи с 10:00 до 10:15
grep "^2026-04-13 10:[0-1][0-9]" app.log

# С помощью флага -A (after) и -B (before)
grep -B 5 -A 10 "2026-04-13 10:15:00" app.log

➤ Вариант 2 (Поиск по сложным паттернам с переносом строк): когда ошибка размазана на несколько строк, а -A и -B не хватает.

# Использование pcre (Perl-совместимые регексы) через -P
grep -Pzo "(?s)Exception.*?\n\s+at.*?\n" app.log

# -z читает весь файл как одну строку
# -o выводит только совпадения
# -P включает переносы в регексах

➤ Вариант 3 (Работа с бинарными файлами): иногда нужно найти строку в дампе памяти или логе, который grep считает бинарным.

# Принудительно обрабатывать файл как текстовый
grep -a "password" memory.dump

# Или наоборот — исключить бинарники
grep -I "error" ./logs/*

➤ Вариант 4 (Статистика и группировка): не просто найти, а посчитать.

# Сколько раз встретился каждый код ответа в логах nginx
grep -oE '" [0-9]{3} ' access.log | sort | uniq -c | sort -rn

# -o выводит только совпадение (не всю строку)
# -E расширенные регексы

➤ Вариант 5 (Использование как фильтр с сохранением контекста): оставить в выводе только нужные колонки.

# Из строки "time=2026-04-13 level=error msg=crash"
grep -oP 'time=\K[^ ]+' app.log
# \K означает "начать вывод отсюда"

И главное, что забывают: grep можно комбинировать. Цепочка grep | grep -v | grep -o часто делает то, для чего в других языках пишут скрипты на 20 строк.

P.S. grep -c считает количество совпавших строк. grep -m 5 останавливается после пяти совпадений. Мелочи, которые экономят время.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Коллеги, всем доброго времени суток!

Чертовски рад сделать разговорный пост - давно их не было.

Думаю, многие заметили: постов стало меньше. Рассказываю, что произошло и когда снова будет разнообразие.

Помните голосование о миграции канала пару месяцев назад? Был там пункт про собственный сайт - тогда я его не сделал.

Теперь решил исправить.

После блокировок и новостей об импортозамещении (кстати, кого уже затронуло?) я ушёл в тему: можно ли своими силами с нуля запустить сайт?

Почему я этого хочу:
- код не превращается в кашу;
- статьи живут годами, а не тонут в ленте за два дня;
- туда помещается то, что сюда просто не влезает.

Сейчас сделал макет, разобрался с принципами. Основная работа позади - осталась доработка (а точнее - полная переработка макета в готовый продукт) и подготовка материалов.

Отвечая на главный вопрос: очень скоро посты снова выйдут на стабильный ритм.

P.S. В комментариях скриншот макета для тех, кому интересно. Если есть предложения - пишите, с удовольствием послушаю.

И если у вас есть опыт с хостингом, запуском сайтов, разработкой - делитесь. Любая информация пригодится😁

lsof - кто держит порт и открыл тот файл

Ситуация: пытаетесь запустить сервер, а он падает с "Address already in use". Порт занят, но кем? Или пытаетесь удалить файл, а система пишет "file is in use". Кто его держит?

lsof (List Open Files) отвечает на оба вопроса. В Linux «всё есть файл» - сетевые сокеты, пайпы, устройства, обычные файлы. lsof показывает, какие процессы какие «файлы» открыли.

Вариант 1 (Кто занял порт): классический кейс с запуском сервера.

# Кто слушает 3000 порт?
lsof -i :3000

# Вывод: COMMAND PID USER FD NAME
# node    1234 user  23u  IPv4 TCP *:3000 (LISTEN)

Вариант 2 (Какой процесс держит файл): не даёт удалить папку или файл.

# Кто использует файл лога?
lsof /var/log/app.log

# Кто работает в папке /home/user/project?
lsof +D /home/user/project

Вариант 3 (Все открытые файлы процесса): подозреваете конкретный процесс - смотрите, что он делает.

# Все файлы, открытые процессом с PID 1234
lsof -p 1234

# Сеть, которую использует процесс
lsof -p 1234 -i

Вариант 4 (Кто использует удалённый файл): монтирование не отдаёт, а кто мешает?

# Процессы, использующие файлы на смонтированном диске
lsof /mnt/usb

# Обычно это оболочка, которая "стоит" в папке на этом диске

lsof нужен, когда обычные инструменты молчат. Команда не показывает ошибку, но что-то мешает. lsof показывает «что именно» и «кто».

Альтернатива:

# Когда точно знаем, что ищем сетевой порт. Быстрее и чаще установлена по умолчанию.
ss -tlnp | grep 3000 

lsof выручает, когда:
1. Нужно посмотреть не только TCP, но и UDP
2. Проблема не с портом, а с файлом или папкой
3. Хотите увидеть все соединения процесса целиком

P.S. Самый частый сценарий: lsof -i :8080 - видим PID - kill -9 PID. Всё, порт свободен.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

strace - смотрим, что процесс делает на самом деле

Бывает, процесс висит, жрёт CPU, но не падает. Логи молчат. Что делать? Танцы с бубном? Нет. Есть strace - утилита, которая показывает все системные вызовы процесса.

В Linux любая программа постоянно общается с ядром: читает файлы, пишет в сокеты, выделяет память. strace перехватывает этот диалог и показывает его вам.

➤ Вариант 1 (Прицепиться к работающему процессу): процесс завис, но не умирает.

# Прицепиться к PID 1234
strace -p 1234

# Вывод:
# read(3, 0x7f8a2c000000, 4096) = -1 ETIMEDOUT (Connection timed out)
# Наглядно: процесс ждёт ответа от какого-то файлового дескриптора 3

➤ Вариант 2 (Запустить программу под strace): нужно понять, почему падает при запуске.

# Запускаем и смотрим
strace ./my_binary

# Ищем строки с -1 (ошибка)
strace ./my_binary 2>&1 | grep -1

➤ Вариант 3 (Фильтрация по конкретным вызовам): шума много, нужно только чтение файлов.

# Только open, read, write, close
strace -e trace=open,read,write,close ./my_binary

# Только сеть
strace -e trace=network ./my_binary

➤ Вариант 4 (Сохранить вывод в файл): процесс падает редко, нужно записать всё.

strace -o /tmp/strace.log ./my_binary

➤ Вариант 5 (Замерить время каждого вызова): где программа тормозит?

# -T показывает время выполнения каждого вызова
strace -T -e trace=read ./my_binary

# -c — сводная статистика в конце
strace -c ./my_binary

Когда strace бесполезен:
- Процесс тормозит, но не из-за системных вызовов (например, алгоритм O(n²))
- Проблема в самом ядре (туда уже нужен perf или trace-cmd)
- Программа работает с графикой/звуком через прямые вызовы драйверов

P.S. strace может влиять на производительность процесса в 10-100 раз. На проде прицепляйтесь аккуратно и ненадолго.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode