Всем привет!

Вчера я выпустил крупное обновление 1.0.0 для своей библиотеки async_yookassa — неофициального клиента для асинхронного взаимодействия с API ЮKassa. О том, что изменилось, зачем я вообще взялся её писать и почему официальный SDK может "убить" вашего бота — в этой статье.

Мне довольно часто приходится работать с только что созданными VPS — будь то развёртывание нового проекта, подготовка тестового окружения или эксперименты с инфраструктурой. Практически каждый такой сервер после создания находится в «сыром» состоянии и требует базовой первичной настройки.

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

Всем привет!

Прямо в канун Нового года — а именно 31 декабря — Telegram представил крупное обновление Bot API 9.3. И не просто представил, а громко заявил: «Революция ИИ в чатах».

И, если пробежаться по списку изменений, масштаб обновления для ботов действительно ощущается — особенно в проектах, где используется ИИ. Давайте вместе пройдёмся по чейнджлогу и посмотрим, что Telegram приготовил нам в подарок на Новый год.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и новостями. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

Всем привет!

В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.

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

Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

Всем привет!

Так вышло, что в месте, где я преподаю и занимаюсь менторством стажёров, начался переход с GitHub-репозиториев на GitLab, развёрнутый на собственных серверах. Пока что перенесли не все проекты, но даже этого оказалось достаточно, чтобы у стажёров возникло немало вопросов — особенно в части настройки CI/CD-процессов.

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

Всем привет!

За последние пару лет компания Astral буквально разрывает Python-мир своими инструментами. Даже если вы не слышали это имя напрямую, с большой вероятностью вы уже пользовались их продуктами — ruff или uv.

И это не преувеличение. И ruff, и uv сегодня фактически стали стандартом индустрии. Например, в свежем релизе PyCharm 2025.3 при создании нового проекта по умолчанию инициализируется именно окружение uv, а не привычный venv. Для open source-проекта — это очень серьёзный показатель доверия со стороны экосистемы.

Открытый исходный код и массовое принятие инструментов Python-разработчиками дали Astral тот самый «кредит доверия», который компания, судя по всему, пока что уверенно оправдывает.

И вот буквально на днях Astral объявили, что их новый «революционный» тайп-чекер ty переходит в стадию бета-тестирования. А если учитывать, что и uv, и ruff формально тоже всё ещё находятся в бете, то можно считать, что ty уже фактически вышел в релиз. Собственно, о нём и поговорим дальше.

Если вам интересны подобные материалы — подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков и полезными инструментами. А прямо сейчас у нас ещё и проходит новогодний розыгрыш.

Знаете, в чём проблема большинства гайдов и курсов, которые обещают научить всему и сразу — да ещё и устроить на работу? Часто они учат примитиву, выдавая это за качественный контент. В итоге появляется много низкокачественного кода: на первый взгляд он работает, но в реальности трудно поддерживается.

Если в проекте нет структуры, он быстро превращается в кашу. Каждая доработка — это не отдельный продуманный модуль, а «приматывание новых кусков кода синей изолентой» с мыслью: «хоть бы не сломалось». Для новичка это особенно опасно: кажется, что всё нормально, пока проект маленький, но при росте даже простые изменения начинают занимать часы и ломать соседние части.

Вы наверняка задаётесь вопросом: «Почему рубрика называется “ИИ бот-модератор”, а автор тут рассказывает про качество кода?» На самом деле, всё связано.

Telegram-бот для группы — отличный пример проекта, который очень быстро обрастает фичами: команды, настройки, роли, интеграции, хранение данных, логирование, админка, модерация, ИИ и т.д. Если делать всё “в одном файле”, это почти гарантированно закончится болью. Поэтому в этой рубрике мы будем строить бота так, чтобы его можно было развивать: добавлять функциональность без постоянного страха «сломать всё».

Всем привет!

В этой статье разберёмся с OpenAI Guardrails — одним из самых эффективных инструментов для обеспечения безопасности ИИ-систем. Это продолжение цикла о защите и контроле ИИ-агентов, в первой части мы рассмотрели инструмент модерации запросов.

Guardrails предоставляет намного более мощные возможности для защиты, позволяя создавать многоуровневую систему валидации входных и выходных данных.

Всем привет!

В последнее время всё чаще появляются новости о том, что искусственный интеллект (ИИ) удалось взломать или обойти его защитные механизмы. Это действительно актуальная проблема — особенно для тех, кто занимается разработкой ИИ‑агентов и интеграцией языковых моделей в продукты.

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

Недавно в нашем Telegram‑канале «Код на салфетке» мы опубликовали подробный разбор того, как можно попытаться обойти встроенные ограничения ИИ. Такие попытки обхода называют джейлбрейком (jailbreak). Это термин из сферы IT, который изначально использовался для обозначения взлома защитных механизмов мобильных устройств, а теперь применяется и к ИИ.

Существует множество техник джейлбрейка — от простых манипуляций с формулировками до сложных многоэтапных схем. Однако разработчики не стоят на месте: для каждой атаки создаются соответствующие защитные механизмы.

В этой статье мы сосредоточимся на одном из ключевых инструментов защиты — модерации контента. Разберём, как с помощью Moderation API автоматически фильтровать вредоносные или некорректные запросы, настроим пакетную проверку и логирование, а также рассмотрим практические примеры интеграции модерации в реальные сервисы.

Если спросить у питониста: «Чем парсить сайт?», — в большинстве случаев он ответит Selenium или Beautiful Soup. И будет по-своему прав — это два главных направления в мире парсинга на Python.

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

Beautiful Soup (или просто «суп») — полная противоположность. Он лёгкий, быстрый и прекрасно справляется с «простыми» сайтами, где нет интерактивных элементов и сложного JavaScript.

В этой статье я расскажу об альтернативе Beautiful Soup — библиотеке Selectolax, воплощающую в себе простоту использования и высокую скорость работы.

Всем привет!

Недавно мы с приятелем обсуждали, как устроены рабочие процессы в бигтех-компаниях и какую роль в них уже играет ИИ. Речь в основном шла о зарубежных компаниях — у него там есть знакомые, которые делились опытом изнутри. Один из самых любопытных моментов — использование искусственного интеллекта для предварительного код-ревью в Pull Request: прежде чем коллеги возьмутся проверять изменения, PR уже анализирует ИИ и указывает на потенциальные проблемы.

Эта идея меня зацепила, и я решил изучить, какие готовые решения уже существуют (кроме встроенного в GitHub Copilot). Из более-менее крупных нашёл только PR Agent. Я протестировал его, но по ряду причин он мне не подошёл: хотелось больше гибкости, настройки под свои нужды и возможности запускать всё самостоятельно, без передачи кода сторонним сервисам.

Так родился проект ReVu — self-hosted инструмент для автоматического код-ревью в Pull Request с помощью ИИ. Он универсален, легко кастомизируется и не требует доверять исходный код внешним платформам.

Если вам интересны подобные материалы и проекты, подписывайтесь на Telegram-канал «Код на салфетке» — там я делюсь гайдами для новичков, историями разработки и полезными инструментами.

Любому веб-приложению нужен веб-сервер для доступа извне. На самом деле, многие даже не уделяют выбору веб-сервера для своего приложения достаточного внимания: на Django берут "популярный" Gunicorn (а кто-то ещё и обвязывает его Uvicorn'ом), а для FastAPI Uvicorn практически стандарт. Тут "на сцену" выходит Granian, представляющий впечатляющие результаты производительности с простой настройкой.

В своём проекте "Код на салфетке" я использовал uWSGI, но недавно узнал про новый Granian и мне стало интересно на что он способен. Так появилась идея для этой статьи.

В этой статье узнаем:

Всем привет!

Этим летом моему проекту «Код на салфетке» исполнилось два года. Отметить это событие я решил проведением розыгрыша среди подписчиков. Разыгрывались 10 книг по программированию, которые, надеюсь, оказались полезными победителям.

Но было бы скучно использовать готового Telegram-бота для этого (дело не только в скуке, но об этом дальше по тексту). Тогда я решил сделать своего бота для проведения розыгрышей — Napkin Random Bot.

О том, почему я решил его сделать и как всё прошло, расскажу в этой статье.

Если вам интересны подобные материалы, подписывайтесь на наш Telegram-канал «Код на салфетке» — будем рады новым подписчикам! Впереди ещё больше розыгрышей и активностей.

Даже самые надёжные и отказоустойчивые системы иногда могут преподносить неприятные сюрпризы. Что уж говорить про обычные VPS-сервера и запущенные на них проекты. Рано или поздно может случиться ситуация, когда сайт или какой-то сервис «упал». Причины бывают разные: от внешних (например, сбой у провайдера или проблемы на стороне хостинга) до внутренних — ошибка в коде, нехватка ресурсов или некорректные настройки.

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

Один из удобных инструментов для этого — Uptime Kuma. Это относительно молодой (по сравнению с «тяжеловесами» вроде Zabbix) проект, который активно развивается, прост в установке и отлично подходит для новичков.

В этой статье мы разберёмся:

15 августа 2025 года Telegram выпустил обновление Bot API 9.2. Если прошлые версии (9.0 и 9.1) в основном усиливали возможности ботов в работе с платным контентом, подарками и чек-листами, то 9.2 делает шаг в сторону более тесной интеграции ботов с каналами и их экосистемой.

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

В одной из предыдущих статей, а именно в «Применение Portainer в CI/CD процессах», мы разобрались, что такое сборка Docker-образов и какие существуют варианты их хранения. В том примере использовался GitHub Docker Registry, а в своей работе я применяю хранилище в собственном Git-хостинге на базе Gitea.

Альтернативой хранению образов рядом с кодом является самостоятельный (self-hosted) репозиторий образов, например Harbor.

В этой статье мы разберём, что такое Harbor, как установить его на свой сервер и как начать им пользоваться.

Продолжаем знакомиться с Portainer и сферами его применения.

В этой статье узнаем как написать CI/CD для сборки Docker-образа и деплоя проекта, а также, как получить бесплатно Portainer BE.

Всем привет!

Недавно я провел опрос среди подписчиков моего Telegram-канала "Код на салфетке", спросив их о возникающих проблемах и ошибках при деплое. Ответов накопилось немало, и большинство из них касались применения Docker. Однако были и комментарии о том, как организовать проект и репозиторий.

В этой статье мы обсудим ключевые моменты, которые помогут вам правильно организовать git-репозиторий, подготовить Docker-файлы, а также сделать процесс деплоя более гладким. Кроме того, мы подробно рассмотрим механику деплоя на двух примерах: деплой приложения на облачную платформу Dockhost и классический деплой на VPS с помощью Docker Compose.

Telegram продолжает расширять возможности своего мессенджера — в свежем обновлении Bot API 9.1 разработчикам стали доступны удобные инструменты для работы с чек-листами, подарками и рядом других функций.

Рассмотрим их подробнее.

Нельзя просто так взять и управлять Docker’ами с разных VPS… или всё-таки можно?

В прошлой статье «Быстрый деплой бота (и не только) на Docker‑хостинге с Portainer» я рассказал о том, как легко развернуть приложение на DockerHosting.ru с предустановленным Portainer без необходимости подключаться к серверу по SSH. Но тот материал касался только управления контейнерами на одном сервере.

А что если у вас несколько VPS и вы хотите централизованно управлять всеми Docker-хостами из одного интерфейса? Portainer поддерживает добавление сторонних Docker‑движков, и это открывает широкие возможности для администрирования сразу нескольких серверов в единой панели.