Меня зовут Илья, я занимаюсь Backend разработкой более 6 лет.
Я занимаюсь разработкой сайтов, интернет-магазинов, интеграций для CRM систем и ботов для социальных сетей.
Каждый раз, когда я хочу опубликовать пост в интернете — будь то статья, короткий анонс или заметка — возникает одна и та же проблема: текст готов, а вот публикация превращается в марафон.
Копировать сюда, вставлять туда, подгонять формат, учитывать ограничения по длине и стилю для каждой платформы… Вроде бы мелочи, но суммарно они съедают кучу времени. Простая задача «опубликовать пост» быстро превращается в рутину, которая раздражает и отнимает энергию.
В новой записи я вам расскажу о своём open source проекте - Postery.
Postery — это инструмент, который позволяет публиковать на несколько платформ через один интерфейс.
Если вам понравится данный проект, я буду рад если вы поддержите его ⭐️ на GitHub! Это мотивирует меня продолжать развивать данный проект.
Как работает Postery
Начать работу с Postery просто!
Сначала нужно добавить платформы, на которых вы планируете публиковать посты. Сейчас поддерживаются два типа платформ для публикации: Telegram (группы или каналы) и группа ВКонтакте.
Важно, что вы можете подключать неограниченное количество источников одного типа. То есть, если у вас несколько каналов или групп в одной платформе, все их можно использовать одновременно, и один пост будет опубликован сразу в нескольких местах.
Postery. Список источников для публикации в Telegram
После этого переходим к созданию поста. На первом этапе нужно указать заголовок и описание, добавить теги и изображения.
Postery. Создание публикации
Когда пост сформирован, можно выбрать, на каких источниках он будет опубликован.
Postery. Выбор источника публикации
Следующий шаг — адаптация контента под конкретные площадки. Для каждой платформы можно изменить заголовок и текст, чтобы пост выглядел органично. Таким образом один пост легко подстраивается под требования разных источников.
Postery. Редактирование поста для источника
Наконец, публикация и планирование. Каждый пост можно запланировать на конкретную дату и время.
Всё вместе создаёт удобный и быстрый поток: вы создаёте пост один раз, адаптируете его под разные площадки и планируете публикацию. Рутинная работа уходит на второй план, а вы можете сосредоточиться на контенте.
AI как инструмент
Одной из самых удобных функций Postery является возможность использовать AI для генерации контента. Это инструмент, который экономит время и помогает адаптировать посты под разные платформы.
После подключения AI-провайдера вы можете создавать заголовки и описания автоматически. В настройках указываются стиль текста, структура поста и ограничения по длине. Таким образом, каждый пост под конкретную платформу может быть сгенерирован с учётом её особенностей.
Postery. Список AI провайдеров
Например, вы создаёте пост для Telegram и ВКонтакте. Вместо того чтобы придумывать разные заголовки и описания вручную, можно задать правила для AI, и система предложит варианты текста, которые подойдут под каждую платформу. При желании генерацию можно запускать для каждого поста вручную или включить автоматическую работу для всех публикаций.
На данный момент Postery поддерживает два AI-провайдера: GigaChat и OpenAI. Их можно подключить в разделе настроек, после чего использовать прямо на странице редактирования поста.
В настройках источника, в разделе "Настройка AI" указываются промпты для генерации контента с помощью AI. В данном разделе вы можете описать стиль текста, структуру поста, ограничения по длине. Таким образом, каждый пост под конкретную платформу может быть сгенерирован с учётом её особенностей.
Postery. Настройки AI для источника
AI генерация помогает не только с экономией времени, но и с поддержкой единого стиля публикаций на разных платформах, что особенно важно для блогеров и авторов, которые ведут несколько каналов одновременно.
Планирование и публикация
После того как пост создан и адаптирован под нужные платформы, следующим шагом становится публикация и планирование.
Каждому посту можно назначить несколько дат публикации. Например, один и тот же пост можно сначала опубликовать в Telegram, а через пару дней — в ВКонтакте, или повторять публикацию с нужной периодичностью. Это особенно удобно, если вы ведёте несколько каналов и хотите поддерживать регулярный поток контента без лишних усилий.
Postery. Перепубликация
Раздел «Календарь» показывает публикации в формате сетки по дням. Нажав на конкретный день, можно увидеть все посты, которые запланированы на этот день, а также время их выхода. Такой визуальный подход позволяет сразу оценить нагрузку на платформы и корректировать публикации, не открывая каждую платформу отдельно.
Postery. Календарь публикаций
В разделе «Аналитика» вы можете увидеть, сколько постов уже опубликовано, а какие находятся в очереди.
Postery. Аналитика
В результате управление публикациями становится прозрачным и удобным: вы планируете пост один раз, назначаете даты выхода, а Postery автоматически публикует его в нужное время. Такой подход экономит ваши ресурсы и позволяет сосредоточиться на создании контента, вместо постоянного контроля за технической частью процесса.
Техническая часть
С технической точки зрения, проект написан на Python с использованием FastAPI. Благодаря этому его можно запускать как локально на своём компьютере, так и на сервере с поддержкой популярных операционных систем.
Таким образом, Postery сочетает в себе простоту использования для конечного пользователя и гибкость для разработчиков. Это делает его удобным инструментом как для блогеров и авторов контента, так и для тех, кто хочет изучить проект и при необходимости доработать его под свои задачи.
Текущее состояние проекта
Postery сейчас находится на стадии MVP и активно развивается. Это значит, что все базовые функции уже работают, но проект продолжает расширяться, и у пользователей есть возможность влиять на его развитие.
Вы можете предложить идеи или проголосовать за улучшения в нашей Telegram-группе - https://t.me/postery_app
Мы активно развиваем Postery вместе с сообществом, и каждый голос и предложение учитываются.
В этой статье я хочу поделиться своим опытом и первыми шагами в Open Source-разработке. Свой путь я начал в начале 2025 года и за это время мои проекты в сумме набрали более 200 звёзд на GitHub.
За прошедший год мне удалось выпустить несколько релизов, выстроить базовые процессы тестирования, а также привлечь первых контрибьюторов к своим проектам.
Я не считаю свой опыт в Open Source разработке большим, однако уверен, что некоторые наблюдения и практические советы могут быть полезны тем, кто только планирует начать свой путь, а также разработчикам, которые уже делают первые шаги в открытых проектах.
Основной фокус статьи будет направлен на процессы разработки: с какими трудностями я столкнулся, какие решения оказались удачными и на какие аспекты, на мой взгляд, стоит обратить внимание на ранних этапах создания Open Source-проекта.
Большинство Open Source-проектов создаётся не с целью прямой монетизации, а ради социального признания. К таким показателям можно отнести звёзды на GitHub, лайки и подписчиков в социальных сетях. Эти метрики позволяют получить внешнюю оценку проделанной работы и, в определённой степени, повысить свою заметность на рынке.
Прямой финансовый доход от подобных проектов, как правило, не предполагается. Возможны донаты или спонсорская поддержка, однако на начальных этапах разработки не стоит рассчитывать на значительный заработок.
Исходя из этого, я рекомендую начинать с проектов, которые полезны вам лично. В таком случае у вас появляется естественная мотивация поддерживать и развивать проект, даже если внешняя обратная связь минимальна.
Отдельное внимание стоит уделить масштабу проекта. Оптимальное время разработки до первой MVP-версии не должно превышать 1–2 недель. Более длительный цикл без ощутимого результата значительно повышает риск выгорания и потери интереса к проекту.
Для вдохновения вы можете посмотреть проекты которые сейчас в тренде на GitHub или подписаться на Topic по интересующему вас направлению (https://github.com/trending).
Выбор аудитории
При создании Open Source-проекта важно заранее определить целевую аудиторию, поскольку от этого решения будет зависеть практически вся дальнейшая разработка.
В общем случае проекты можно условно разделить на два типа:
проекты для разработчиков;
проекты для конечных (сторонних) пользователей.
На этапе планирования необходимо чётко понимать, для кого именно создаётся продукт, так как выбранная аудитория напрямую влияет на архитектуру, набор функций, требования к документации и способы распространения проекта.
Проекты для разработчиков
Если вы разрабатываете библиотеку, фреймворк или инструмент для разработчиков, имеет смысл ориентироваться на технологии, которые востребованы на рынке. Использование популярных языков программирования и экосистем, как правило, позволяет охватить более широкую аудиторию.
Однако существует и альтернативный подход: вместо выбора языка можно отталкиваться от актуальных рыночных трендов. Например, изучить популярные проекты и экосистемы и создать для них вспомогательную библиотеку, плагин или интеграционный шлюз.
В таком случае даже использование менее распространённого языка программирования может стать преимуществом: конкуренция будет ниже, а проект сможет привлечь значительную аудиторию за счёт решения актуальной задачи. Типичный пример — разработка полезного инструмента или библиотеки для новой технологии или нейросети, которая находится на пике интереса.
Проекты для конечных пользователей
Если проект ориентирован на пользователей, не связанных с разработкой (как в моём случае), приоритеты смещаются. Здесь особенно важно уделять внимание:
производительности и оптимизации;
качественной и понятной документации;
простоте установки и быстрому развёртыванию проекта.
Необходимо учитывать, что такая аудитория, как правило, не имеет технического бэкграунда. Поэтому ключевой фактор успеха — минимальный порог входа и понятный пользовательский опыт.
Наблюдения из практики
По моему опыту, проекты для разработчиков чаще получают звёзды на GitHub, поскольку их аудитория хорошо ориентируется в экосистеме платформы и активно использует такие метрики. Однако подобные проекты сложнее продвигать и выделять среди конкурентов.
Проекты для конечных пользователей, в свою очередь, обычно получают меньше звёзд, но их аудитория охотнее идёт на контакт и более заинтересована в развитии продукта, особенно если он напрямую влияет на их бизнес-процессы.
Начало разработки
На ранних этапах разработки важно сразу продумать сценарий использования проекта с точки зрения пользователя. В идеале процесс установки и первичной настройки не должен превышать 2–3 шага — чем ниже порог входа, тем выше вероятность, что пользователь действительно попробует ваш продукт.
Если вы разрабатываете библиотеку, имеет смысл ориентироваться на популярные менеджеры пакетов соответствующей экосистемы. Это позволяет пользователям подключать ваше решение к проекту с помощью нескольких команд в терминале, без дополнительной ручной настройки.
Если же проект представляет собой отдельный сервис (как в моём случае), стоит заранее задуматься о контейнеризации. Использование Docker позволяет изолировать зависимости, стандартизировать окружение и значительно упростить процесс установки и запуска проекта.
В процессе разработки проекта tg-support-bot я предусмотрел два варианта установки:
Полный вариант — развёртывание через docker-compose, включающее все необходимые сервисы: PostgreSQL, PgAdmin, Loki, Grafana, Redis и другие компоненты.
Упрощённый вариант — установка проекта на обычный хостинг с возможностью подключения внешней базы данных и отключения необязательных сервисов.
При этом важно избегать жёстких зависимостей между контейнерами. Пользователи должны иметь возможность отключать или заменять отдельные сервисы внутри docker-compose без нарушения работоспособности основного приложения.
Линтинг, настройка CI и тесты
Перед публикацией проекта важно настроить надежную систему тестирования и линтинга. Это помогает предотвратить ошибки, повышает стабильность проекта и облегчает совместную разработку.
Code style и линтеры
Для каждого проекта важно определить и задокументировать правила code style. Чем строже и однозначнее эти правила, тем проще поддерживать читаемость кода и единый стиль среди участников проекта.
Также необходимо настроить линтеры, которые проверяют код на:
синтаксические ошибки и типизацию;
соответствие имен переменных и функций выбранному стилю;
распространённые ошибки и потенциальные уязвимости.
Автоматическое тестирование
Автотесты критически важны для поддержания стабильности проекта и ускорения разработки. Чем больше функций покрыто тестами, тем безопаснее вносить изменения и привлекать сторонних контрибьюторов.
В проекте tg-support-bot я реализовал систему shell-скриптов для автоматизации линтинга и тестирования с передачей дополнительных параметров к инструментам анализа.
Скрипты интегрированы с git-хуками:
При коммите запускаются проверки только для файлов, включённых в индекс.
Статический анализатор PHPStan проверяет код на ошибки и нарушения типизации;
Выполняются unit-тесты для изменённых классов;
Если изменён Dockerfile, запускается Hadolint для проверки Dockerfile;
Если изменены shell-скрипты, применяется ShellCheck для выявления ошибок и потенциальных уязвимостей.
При push выполняется проверка всего проекта: PHPStan анализирует весь код, запускаются все unit-тесты и линтеры. Это позволяет выявить проблемы, которые могли быть пропущены при коммите.
На этапе CI система повторно проверяет весь проект, что особенно важно для Open Source: сторонние контрибьюторы могут внести изменения, которые нарушат работу проекта.
Пример работы CI в проекте tg-support-bot
В случае обнаружения ошибки системы блокирует изменения до исправления ошибок.
Таким образом, процесс тестирования делится на три уровня:
Локальная проверка при коммите — только файлы, добавленные в коммит.
Проверка при push — весь проект для предотвращения глобальных ошибок.
CI/CD — полная автоматическая проверка, включая сторонние изменения.
Продуманная система тестирования и линтинга позволяет снизить риски и обеспечивает стабильность проекта, что особенно важно в Open Source-разработке.
Структура GitHub репозитория
В процессе разработки вы будете создавать множество веток, которые в дальнейшем будут сливаться с основной веткой main. От правильной организации веток напрямую зависит качество проекта и удобство командной работы.
Структура веток
На своих проектах я использую следующую схему:
Ветка main является основной. Прямые коммиты в неё запрещены — все изменения вносятся через дочерние ветки.
Релизные ветки создаются перед планированием релиза. Например, для шестого релиза создаётся ветка release_6. В этой ветке я фиксирую все задачи, которые должны войти в релиз.
Ветки задач создаются для каждой отдельной задачи из релиза. В наименовании ветки обязательно указывается номер соответствующего Issue. Это строгое правило: ветка с некорректным именем не пройдет проверки CI, и изменения не смогут быть слиты в проект.
Такой подход помогает:
Приучиться создавать Issues для любых изменений;
Контролировать работу сторонних контрибьюторов;
Поддерживать прозрачность процесса разработки.
Пример описания коммитов
Структура коммитов
Для упрощения отслеживания изменений я использую shell-скрипты, которые автоматически:
Добавляют в начало описания коммита номер задачи (issues-62 | update tests);
Формируют список изменённых файлов с пометками Added, Changed, Deleted.
Также важно соблюдать грамотное описание релизов: каждая версия должна содержать чёткий список изменений и исправленных задач. Такой подход обеспечивает:
прозрачное ведение истории изменений;
удобство для контрибьюторов и пользователей;
облегчение поддержки проекта в долгосрочной перспективе.
Строгая структура веток и коммитов повышает контроль над изменениями, улучшает читаемость истории проекта и минимизирует ошибки при совместной разработке в Open Source.
Документирование
Документирование — один из ключевых аспектов Open Source-разработки. Хорошая документация делает проект доступным для пользователей и контрибьюторов, ускоряет внедрение и снижает количество ошибок при использовании.
Формат: версия, дата релиза, исправления, новые функции.
Отдельно хочу выделить раздел Wiki на GitHub...
GitHub Wiki — это встроенный инструмент для более подробной и структурированной документации проекта. В отличие от README, Wiki позволяет создавать несколько страниц, объединённых логической структурой, что удобно для больших проектов.
Использование Wiki целесообразно для расширенной документации: здесь можно описать архитектуру проекта, инструкции по деплою и CI/CD, гайды по использованию библиотек и сервисов, а также рекомендации для контрибьюторов. Важно, чтобы Wiki дополняла README, а не дублировала его, оставляя последний кратким и ориентированным на быструю установку и запуск.
Практические рекомендации
Документируйте всё ключевое сразу, не откладывая на будущее. Это экономит время и снижает риск потери информации.
Используйте шаблоны и стандарты (например, Markdown, OpenAPI, DocBlock), чтобы документация была однородной.
Поддерживайте документацию в актуальном состоянии — каждая новая функция или изменение должно сопровождаться обновлением описаний.
Для сторонних пользователей делайте упор на простоту и понятность, для разработчиков — на технические детали и примеры использования.
Взаимодействие с аудиторией
Для успешного развития Open Source-проекта важно активно взаимодействовать с аудиторией и привлекать пользователей из сторонних источников. Это помогает не только продвигать проект, но и получать ценные отзывы для улучшения функционала.
Первым шагом является выбор удобного канала коммуникации. Это может быть форма обратной связи на сайте, отдельная почта для обращений пользователей или группа в популярной социальной сети. Главное — чтобы пользователи могли легко задавать вопросы и получать ответы.
В проекте tg-support-bot я создал отдельную группу, где публикую новости, отвечаю на часто задаваемые вопросы и взаимодействую с пользователями.
Этот подход оказался очень эффективным: со временем пользователи стали помогать друг другу, отвечая на вопросы без моего участия. Кроме того, участники активно тестируют новые функции, выявляют ошибки и предлагают улучшения, что значительно ускоряет развитие проекта.
Дополнительно в Telegram-группе я получаю от пользователей идеи для нового функционала и провожу голосования, что позволяет учитывать мнение сообщества при планировании развития проекта.
Таким образом, налаженная коммуникация с аудиторией позволяет объединить пользователей, повысить вовлечённость и создать сообщество вокруг проекта, что является ключевым фактором успешного Open Source-развития.
Скриншот из группы TG Support Bot | Бот для технической поддержки
Популяризация проекта
Для расширения аудитории важно привлекать пользователей из внешних источников. Одним из эффективных способов является создание видеоконтента в формате «Dev-блог», где можно показывать процесс разработки и делиться опытом по созданию проекта.
Видеоинструкции по установке и настройке проекта также оказывают большую помощь пользователям, снижая порог входа и повышая интерес к проекту.
Дополнительно полезно публиковать статьи на популярных ресурсах, таких как Хабр или Пикабу, чтобы привлечь новую аудиторию и рассказать о проекте более широкой публике.
Если проект содержит интересные технические решения, он может привлекать внимание даже тех пользователей, которые не планируют использовать его напрямую, но хотят наблюдать за процессом разработки и изучать технические детали.
Заключение
Open Source — это не только код, но и процессы, сообщество и взаимодействие с пользователями. Продуманная структура репозитория, тесты, документация и активная коммуникация помогают проекту развиваться и привлекать новых участников.
Если вам интересно следить за моими проектами и участвовать в их развитии, подписывайтесь на мой GitHub — там вы найдёте все обновления и сможете присоединиться к работе над проектами.
Разработка на Laravel становится действительно эффективной, если автоматизировать каждую стадию — от поднятия окружения до тестирования и проверки кода. В этой статье я расскажу, как выстроить рабочий процесс, который минимизирует рутинную работу, повышает качество кода и ускоряет выпуск новых фич.
Материал рассчитан на тех, кто уже знаком с Laravel и хочет внедрить автоматизацию: проверки, стиль, статический анализ, готовый Docker-Compose и др. Ниже — конкретные инструменты, советы и примеры из реального проекта.
независимые контейнеры, чтобы компоненты не мешали друг другу;
быстрое развёртывание и минимизацию «работы вручную».
Сервисы, которые я поднимаю:
php-fpm — чтобы исполнять PHP-код,
PostgreSQL — база данных,
Redis — кэш и очереди,
Grafana + Loki — для логов и мониторинга,
pgAdmin — интерфейс к БД,
queue - контейнер для очередей запускает php artisan queue:work.
Каждый сервис — в отдельном контейнере. Это даёт гибкость: можно обновлять один сервис без простоя остальных, менять версии без конфликта, и так далее.
интеграция в процесс разработки минимально мешает.
Git Hooks и shell-скрипты для проверок
Для поддержания качества кода я использую Git Hooks, которые автоматически проверяют код перед коммитом и пушем. Все проверки вынесены в отдельные shell-скрипты, что позволяет гибко настраивать их для разных проектов.
Основные подходы:
1. Pre-commit: проверка изменённых файлов
Проверяются только новые или изменённые файлы, что ускоряет процесс;
Скрипты запускают Pint и PHPStan, автоматически исправляют стиль и выявляют ошибки;
Если проблем нет, коммит продолжается без задержек.
2. Постепенное исправление старых ошибок
Для старых проектов скрипты проверяют, что количество ошибок в файле уменьшилось хотя бы на 1–2 по сравнению с предыдущим коммитом;
Такой подход позволяет внедрять проверки без блокировки разработки.
3. Проверка наличия тестов для классов
4. Проверка работы Docker-сборки
Совет: интегрируйте эти скрипты с самого начала проекта, чтобы автоматизация стала частью привычного рабочего процесса.
Для достижения этой цели я использую скрипт, который проверяет наличие тестов для каждого PHP-класса, добавленного или изменённого в коммите.
Скрипт получает список изменённых и добавленных PHP-файлов и ищет соответствующий тестовый файл в директории tests.
Например, если в проекте есть класс app/Services/UserService.php, скрипт потребует создать файл теста tests/Unit/Services/UserServiceTest.php. Таким образом, любой новый или изменённый класс обязательно должен иметь соответствующий тест, что помогает поддерживать качество и надёжность кода.
Не менее важно регулярно проверять работу Docker сборки. Для этого я создаю отдельный shell-скрипт, который перезапускает все контейнеры и проверяет, что они успешно запустились. Такой подход позволяет убедиться, что изменения в конфигурации или коде не нарушили работу сервисов и приложение корректно поднимается в локальной среде.
Скрипт может автоматически останавливать текущие контейнеры, заново собирать их и запускать в фоне. После запуска выполняется проверка состояния через docker ps или docker compose ps, чтобы убедиться, что все контейнеры находятся в статусе healthy или up.
#!/bin/bash
echo "=== Остановка всех контейнеров ===" docker-compose down
echo "=== Запуск контейнеров в фоне ===" docker-compose up -d
# Пауза для запуска сервисов echo "=== Ждем 5 секунд для старта сервисов ===" sleep 5
echo "=== Проверка состояния контейнеров ===" # Получаем статус всех контейнеров STATUS=$(docker-compose ps --services --filter "status=running")
if [ -z "$STATUS" ]; then echo "Ошибка: ни один контейнер не запущен!" exit 1 else echo "Запущенные контейнеры:" docker-compose ps fi
# Дополнительно можно проверять HEALTHCHECK каждого контейнера echo "=== Проверка состояния HEALTH ===" docker ps --filter "health=unhealthy" --format "table {{.Names}}\t{{.Status}}"
echo "=== Скрипт завершен ==="
exit 0
Таким образом, перед деплоем или важными изменениями можно убедиться, что сборка полностью работоспособна и готова к развёртыванию.
Итоги и ключевые принципы
Автоматизация в Laravel — не «фича», а часть рабочего процесса.
Вот основные практики:
настроенное окружение через Docker Compose;
автоматические проверки стиля (Pint);
статический анализ (PHPStan + Larastan);
Git Hooks и скрипты — «сторожи качества» при коммите и пуше;
обязательное тестирование новых и изменённых классов.
Если внедрить всё это, можно:
сократить время на исправления;
поддерживать единообразный стиль кода;
повысить предсказуемость и стабильность приложения;
и главное — освободить команду для работы над функционалом, а не над «ремонтами кода».
За последние пару месяцев я проделал большую работу по развитию данного проекта. Я написал много инструкций отталкиваясь от обращений пользователей, упростил команды для сборки проекта, а также разработал много полезного функционала.
Я продолжаю активно развивать свой проект и в этом посте расскажу, какие новые возможности появились в свежем релизе.
О моём проекте
Если вы не знакомы с моим проектом, вы можете посмотреть этот обзор
AI-помощник
Я давно планировал добавления AI-помощника в данный проект и вот этот момент настал!
Теперь вы можете интегрировать в свою техническую поддержку ИИ модель, которая будет отвечать на сообщения пользователей, опираясь на базу знаний (промт описывающий ответы на популярные вопросы).
В промте вы можете описать поведения AI-помощника, ответы на популярные вопросы и формат возвращаемого текста.
Как это работает?
В чат-теме вы можете запустить команду /ai_generate и указать контекст для AI помощника.
/ai_generate напиши инструкцию по настройке SSL сертификата для бота
После отправки команды, AI помощник даст ответ на основе базового промта и вашего сообщения.
В чате появится сообщение с клавиатурой, с помощью которой вы можете принять или отклонить ответ от AI помощника, а также отредактировать ответ, после чего отправить его пользователю.
Поддерживаемые ИИ модели
Мой проект имеет гибкую систему для работы с ИИ моделями. На данный момент организована поддержка OpenAI и DeepSeek, но будут добавляться новые.
Проголосовать за добавления новых AI можно в TG группе:
Все инструкции есть в разделе Wiki на GitHub, но в двух словах:
создаёте дополнительного Telegram-бота (для разделения логики AI и менеджеров);
указываете ключи AI-моделей в .env;
настраиваете доступ для бота-помощника;
включаете параметр AI_ENABLED=true;
прописываете промты, которые будут использоваться для генерации ответов.
Если возникнут трудности — пишите в группу, всегда рады помочь.
Дополнительные улучшения
В новый релиз заехало большое количество улучшений уже добавленного функционала.
API
Переработал API — теперь структура запросов стала проще, а файлы отправляются отдельными запросами.
Обработка лимитов
Доработал обработку лимитов Telegram. Теперь при превышении лимита, запросы ставятся в очередь и отправляются с задержкой. Это позволило избежать ошибок при, которых сообщения могли потеряться.
Переработал инструкции
Были переработаны текста для инструкций и добавлено много новой полезной информации.
Живой чат для сайта
Эта фича немного задерживается: не хватало времени, но уже есть хорошие новости!
Готов дизайн MVP
Я нашел программиста, который взял на себя frontend-разработку
По срокам сказать сложно, но мы активно двигаемся в этом направление.
Итог
Я развиваю проект, опираясь на ваши идеи и запросы.
Всем привет! Вы просили - я сделал! Я выпустил релиз №3 для бота технической поддержки на GitHub.
Прошло уже несколько месяцев с последнего обновления, и бот за это время получил вдвое больше звёзд на GitHub, что очень мотивирует продолжать развитие и поддержку проекта.
За последний месяц ко мне поступило несколько запросов расширить функционал бота за счёт подключения новых источников трафика. Изначально я думал добавить интеграции с популярными мессенджерами, такими как WhatsApp или Viber. Но в итоге решил, что в первую очередь стоит реализовать API, чтобы вы сами могли подключать любые свои источники.
В этой статье расскажу о новом API для подключения внешних источников — живых чатов, CRM и других систем, а также о других важных обновлениях и планах на будущее.
Предисловие
Для тех, кто не знаком с проектом: TG Support Bot — это бот на Laravel, который объединяет клиентов и менеджеров через Telegram и ВКонтакте, скрывая личные аккаунты и маршрутизируя общение через темы в Telegram-группе.
Пользователь пишет боту, сообщение автоматически пересылается в выделенную тему для менеджеров, а их ответы возвращаются обратно от имени бота — так сохраняется приватность и удобство общения.
Буду благодарен, если вы поддержите мой проект ⭐ на GitHub!
Руководство по установки
Я записал видео-инструкцию для установки данного решения на VPS с предустановленным Docker Compose.
Для улучшения коммуникации с пользователями, я создал группу в Telegram, в которой вы можете задавать свои вопросы и писать предложения по расширению функционала.
Также сюда будут публиковаться новости по выпуску обновлений.
API — не альтернатива мессенджерам, а универсальный инструмент
Хочу сразу уточнить: разработка API не заменяет расширение списка поддерживаемых мессенджеров и соцсетей. Я продолжаю работать над интеграциями с ними и буду добавлять новые источники трафика.
Однако API необходим для подключения кастомных источников — живых чатов, CRM-систем, форм на сайте и других нестандартных каналов.
Что входит в первую версию API?
В API реализованы базовые маршруты для работы с сообщениями:
GET api/external/messages — получение списка сообщений с возможностью фильтрации
GET api/external/messages/{id_message} — получение конкретного сообщения по ID
POST api/external/messages — отправка нового сообщения
PUT api/external/messages — изменение существующего сообщения
DELETE api/external/messages — удаление сообщения
Для работы с API необходимо создать пользователя и сгенерировать для него API-токен. Рекомендую создавать отдельного пользователя под каждый источник.
Также нужно прикрепить к источнику ресурс, куда будут поступать сообщения от обработчика.
Как это работает?
Процесс довольно простой:
На вашей стороне генерируется уникальный ID пользователя — это может быть хэш ключ или любой уникальный идентификатор.
При отправке сообщения в тело запроса передаются: ID пользователя, код источника, текст сообщения и, при необходимости, файлы.
Система идентифицирует пользователя или создаёт новую запись, если это первое сообщение от него.
Сообщение из вашего источника направляется в Telegram-группу поддержки.
Менеджеры в группе, как и раньше, могут отвечать любыми типами сообщений. Текст отправляется как текст, остальные — конвертируются в файлы. В названии темы указывается ID клиента и источник сообщения.
Таким образом, вы легко сможете подключить практически любой внешний источник к вашему боту.
Подробная инструкция по работе с API уже есть в разделе wiki на GitHub.
Добавлены новые консольные команды
Я добавил несколько полезных консольных команд.
php artisan telegram:set-webhook
Artisan команда, которая производит подключения хука бота к вашему проекту. Ранее это делалось через отправку запроса в telegram или по специальной ссылке, а теперь это можно сделать запустив команду в консоле.
php artisan app:generate-token
Команда, которая генерирует токен для подключения к API вашего бота. Вы можете подключить неограниченное количество источников графика и для каждого создать уникальный токен.
Swagger для API
Для API был разработан генератор swagger документа.
Ранее я хотел использовать готовое решение для генерации swagger документации, но большинство решений очень сильно нагромождают код. Поэтому я решил написать собственный генератор, который собирает документацию.
Принцип прост! Вы описываете документацию по частям в resources/swagger. Важно граматно подходить к именованию файлов и компонентов.
После создания структуры, вы запускаете artisan команду и документация собирается в единый документ.
php artisan swagger:generate
На выходе вы получаете 2 версии документации
В формате json, которую можно использовать для нейросетей или программ
В формате Swagger-ui для просмотра в браузере
Мелкие доработки
Улучшено логирование ошибок — все логи теперь доступны в Grafana;
Исправил баги, о которых вы писали в Issues;
Добавил контейнер redisinsight для просмотра Redis данных через WEB интерфейс;
Переписал инструкции для подключения и настройки бота;
Спасибо всем за поддержку и обратную связь! Продолжаю работать над улучшениями и буду рад новым предложениям и вопросам.
Если нужно, могу помочь с примерами использования API или подсказать, как правильно настроить интеграцию.
Месяц назад я выложил на GitHub своего бота для технической поддержки. Он собирает сообщения от пользователей и помогает обрабатывать их в одном месте. Неожиданно для себя, за месяц я получил больше 100 клонирований и 40+ звёзд — как для моего проекта, это прям успех!
Раньше бот работал только с Telegram. Теперь можно подключить ещё и сообщество ВКонтакте — и объединить все сообщения в одну Telegram-группу. Все, кто пишет в ВК, будут "видны" в Telegram.
Работают все основные форматы сообщений: текст, файлы, картинки, голосовушки и даже контакты. Правда, некоторые штуки пришлось адаптировать — например, контакт из Telegram теперь приходит как обычный текст: имя + телефон.
🐳 Добавил docker-compose
Теперь бот можно легко запустить через Docker. Просто собрал нужные контейнеры, запустил — и всё работает.
Что внутри:
nginx + php + PostgreSQL
веб-интерфейс для работы с базой — PgAdmin
и даже Grafana + Loki — чтобы отслеживать логи, ошибки, запросы и всё такое
В будущем хочу ещё добавить метрики, алерты и всякие полезности для мониторинга.
Что дальше?
Все эти фичи — это не просто "что бы было". Их реально просили пользователи. Спасибо каждому, кто не поленился написать Issue ❤️
Как только наберём 80 звёзд на GitHub, начну работу над подключением нового источника сообщений.
Если интересно — вот тут лежит проект на GitHub Буду рад, если зацените, поставите ⭐ и напишете, что бы вы хотели видеть дальше.
Привет, Пикабу! 👋 Хочу показать вам Telegram-бота, которого я написал на Laravel. Он помогает вести персонализированную поддержку пользователей прямо в Telegram.
Я веду блог по разработке, и мне часто пишут подписчики. Сначала я просто отвечал вручную, но быстро понял, что чат захламляется, сообщения теряются, и всё становится неудобно.
Хотелось:
централизованной переписки,
без спама в личке,
и чтобы пользователи не видел личный аккаунт.
Так и родилась идея: бот, который принимает сообщения от клиентов, создаёт для каждого отдельную тему в Telegram-группе, и пересылает туда все сообщения. Я отвечаю в теме — бот отправляет ответ клиенту от своего имени.
Никаких личных контактов. Никаких потерянных сообщений. Всё — в одной группе.
Как работает бот?
Очень просто:
Создаём группу в Telegram для фиксирования чатов.
В настройках группы включаем темы и добавляем бота в группу с правами администратора.
Пользователь пишет боту.
Если это новый клиент, бот создаёт отдельную тему в группе.
Вы отвечаете в этой теме — бот пересылает ответ клиенту.
🎯 Бонус: Бот не хранит переписки, фото и файлы — только ID сообщений и клиентов. Никаких баз данных с чувствительной инфой. Всё по-честному.
Что умеет?
Поддерживает все типы сообщений: текст, голос, видео, документы, фото.
Подходит для небольших команд, которым нужна простая и быстрая поддержка через Telegram.
Настраивается примерно за 30-60 минут.
Название темы формируется из символа "#" и id пользователя.
У темы меняется иконка, в зависимости от последнего сообщения. Если последнее сообщение от клиента, то ставится иконка "облачко", а если оно написано со стороны администратора, то ставится "зелёная галочка".
Также вы можете получить информацию о пользователе с котором ведёте общение.Подобное сообщение отправляется при создание темы или после отправки команды /contact.
Как установить?
Процесс установки очень прост. Если что-то не получится — пишите мне в Telegram: 📬 https://t.me/prog_time_bot
При разработке API на Laravel часто возникает необходимость тестировать валидацию входящих данных. Один из способов — вручную писать тесты с различными вариантами входных параметров. Однако этот процесс может быть трудоемким и рутинным.
Чтобы упростить задачу, я разработал пакет laravel-request-testdata, который автоматически создает тестовые данные на основе правил валидации Laravel Request.
Разработчикам, которые хотят автоматизировать тестирование валидации запросов.
Тем, кто пишет много API-тестов и хочет минимизировать рутинные задачи.
Всем, кто хочет быстро получать корректные тестовые данные без необходимости вручную прописывать каждый вариант входных данных.
Как работает модуль?
Рассмотрим стандартный Laravel Request с простыми правилами:
Теперь используем laravel-request-testdata для получения тестовых данных:
Выходные данные могут выглядеть так:
Проанализировав передаваемый Request класс, модуль возвращает массив с параметрами для запроса. Полученные данные вы можете использовать в авто-тестах вашего приложения.
При таком подходе вам нужно меньше следить за актуальностью тестов при редактирование правил валидации + это избавляет вас от необходимости вручную прописывать тестовые данные.
В процессе планирования разработки модуля я долго изучал вариации правил валидации в Laravel и постарался описать все возможные кейсы правил валидации.
Разные форматы правил валидации
Данный модуль может обрабатывать правила валидации в разном формате.
Правила в формате массива
Вы можете описать правила в виде строки, как это было сделано в предыдущих примерах, а можете передать массив со списком параметром:
Использование сложных условий
По мимо типичных правил валидации, модуль также понимает такие правила, как: in, exists, unique и так далее.
Использование класса Rule для описания правил
В некоторых Request классах правила валидации описываются в формате Rule конструкций. Это может быть Rule::unique для проверки на уникальность или Rule::in для проверки на соответствие конкретным значениям.
Генерация тестовых файлов для проверки валидации
Что касается валидации загружаемых файлов, то тут всё немного сложнее. На данный момент мой модуль может сгенерировать файлы таких типов, как: yml, xml, svg, sql, png, log, json, jpg, html, gif и csv.
Количество доступных форматов будет постепенно увеличиваться, по мере развития данного модуля.
Для данной проблемы есть обходной вариант, который мы рассмотрим ниже.
Указание своих тестовых данных
Бываю моменты когда вам нужно для тестирования передавать свои данные, которые более корректно смогут настроить проверку работы приложения.
Для этого необходимо в Request классе создать метод requestTestData(). Данный метод должен возвращать параметры запроса с заполненными тестовыми данными.
Через метод requestTestData() вы также можете передавать тестовые файлы в форматах, которые на данный момент не поддерживаются моим модулем.
Таким образом я постарался разработать полезный модуль, который позволит сократить время на написание тестов и облегчит поддержку уже написанных авто-тестов.
Данный модуль не требует дополнительной настройки, его легко можно установить через composer и использовать в своих тестах.
Я надеюсь вам понравилось моё решение. Я буду очень благодарен если вы поддержите данный модуль звёздочкой на GitHub и напишите свой комментарий под данным постом.
