Приветствую! Есть работающее приложение на Laravel. ERP система для контроля и управления производственными процессами. Сейчас успешно работает на 2-х предприятиях. Для дальнейшего продвижения нужно провести - аудит и код-ревью текущей кодовой базы (Laravel), - выявление узких мест, - доработка и развитие фронтенда, - подготовка к масштабированию для большого количества предприятий. Нужен специалист отлично знающий PHP, JavaScript, HTML, CSS, Laravel. Если есть интерес, пишите в личку, все подробно расскажу и покажу.
Представьте, что вы открыли сайт выставки, нашли интересное событие и перешли в раздел другого павильона. Цвета изменились. Меню стало другим. Кнопки находятся в новых местах. Кажется, будто вы случайно ушли с сайта и попали на чужой ресурс.
Примерно так раньше выглядело цифровое пространство ВДНХ. У разных направлений было 14 отдельных сайтов. И объединить их оказалось намного сложнее, чем нарисовать одинаковое меню.
14 сайтов одной локации
Коллаж интерфейсов главных страниц тематических сайтов
У музеев, выставочных площадок и других направлений ВДНХ были отдельные сайты. Они создавались в разное время и выглядели по-разному.
Посетитель мог открыть афишу на одном ресурсе, перейти к другому событию и оказаться в совершенно новом интерфейсе. Приходилось заново искать меню, расписание и покупку билетов.
Сотрудникам было не проще. Одну новость нужно было размещать сразу в нескольких местах. Если менялось расписание или закрывался павильон, информацию приходилось обновлять в разных системах.
Логичным решением казалось объединить все сайты. Но здесь началась самая сложная часть.
Старый сайт нельзя было просто выключить
С ним уже работали мобильное приложение и информационные экраны на территории ВДНХ. Они регулярно запрашивали расписание, описания мест и другую информацию.
Если бы старую систему просто заменили новой, часть этих устройств и приложений могла перестать работать. Тогда к проекту сайта добавилась бы срочная переделка всех подключенных сервисов.
Поэтому новую платформу научили отвечать старым приложениям на привычном для них языке. Внутри система стала другой, но мобильное приложение и информационные экраны продолжили получать данные как раньше.
Это похоже на переезд магазина в новое помещение, при котором старый вход временно оставляют для постоянных покупателей.
Одна база, разные разделы
События, новости и места перенесли в общую систему. Теперь информацию достаточно добавить один раз.
Если событие относится к нескольким разделам, оно появляется там автоматически. Редактору больше не приходится копировать один и тот же текст.
При этом направления ВДНХ не стали одинаковыми. У них сохранились собственные цвета, меню и оформление. Разница в том, что теперь все они собираются из одной системы.
Обучение сотрудников заняло 2 часа. Техническая команда заказчика уже через неделю смогла самостоятельно добавлять новые функции.
Почему сайт стал быстрее
Раньше серверу часто приходилось заново собирать одну и ту же страницу для каждого посетителя.
В новой системе часто используемые данные подготавливаются заранее. Если страница не изменилась, пользователю показывают уже готовую версию. Дополнительные элементы загружаются только тогда, когда они действительно нужны.
Особенно сложной была афиша. Пользователь может выбрать дату, цену, возраст, тему и другие параметры. Всего вариантов фильтрации было больше 100.
Если при каждом выборе обращаться к основной базе, она быстро перегружается. Поэтому события заранее распределили по упорядоченным спискам. Когда посетитель выбирает несколько условий, система находит пересечение этих списков.
Например, подборка бесплатных детских концертов на ближайшие выходные формируется за 3-5 мс. Нагрузка на основную базу сократилась на 90%.
Почему не пришлось покупать новые серверы
У городского портала нагрузка меняется в зависимости от событий. В обычный день посетителей может быть относительно немного. После открытия катка или крупной выставки их число быстро растет.
Система была разделена на несколько самостоятельных частей. Если одна из них начинает получать слишком много запросов, можно временно запустить дополнительные экземпляры именно этой части.
Это позволило оставить прежнюю инфраструктуру и при этом подготовить сайт к более высокой посещаемости.
Карта тоже могла стать дорогой
Интерактивная карта использует внешний картографический сервис. Некоторые обращения к нему оплачиваются.
Если отправлять запрос после каждого изменения, расходы постепенно растут. Поэтому маршруты пересчитываются только тогда, когда редактор завершил работу и нажал отдельную кнопку.
Часть информации о местах хранится внутри платформы. Повторно запрашивать названия, значки и другие базовые данные не нужно.
Если пользователь находится далеко от ВДНХ, построение маршрута может переключаться на Яндекс Карты.
Что получилось
Результаты на дашборде PageSpeed Insights
Разработка заняла 6 месяцев вместе с дизайном, согласованиями и документацией.
Время ответа серверной части сократилось с 900 до 62 мс. Это почти 15-кратное ускорение. Первый экран загружается менее чем за 2 секунды даже при высокой посещаемости.
Но для посетителя важнее другое. Сайт перестал выглядеть как набор несвязанных ресурсов. События, места и маршруты находятся в одной системе.
Для сотрудников исчезла часть повторной работы. Для технической команды появилась возможность развивать отдельные части сайта, не перестраивая его целиком.
Самый заметный результат проекта находится не на экране. Он проявляется в тот момент, когда меняется расписание, появляется новое мероприятие или резко вырастает число посетителей, а система продолжает работать как обычно.
Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах - приходите в мой тг https://t.me/alekseypostrigaylo. Там - сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.
Всем привет! В преддверии НГ не хочется оставаться без банки кабачковой икры. Собственно, ищу работу удалённо уже около 2 месяцев(HH, VK, спец. форумы), откликаюсь активно, но откликов много, а предложений мало. Решил попробовать здесь — вдруг кто-то из HR или тимлидов ищет сотрудника.
Катаюсь на горах просмотров.
О себе вкратце:
Опыт: Почти 6 лет в PHP, из них 3+ года на Laravel.
Уровень: Миддл.
Позиция: Backend или Fullstack(с уклоном в бэк) PHP-разработчик.
**Формат: удалённая работа**
Чем приходилось заниматься на прошлых местах:
Архитектура: Превращать legacy-монолит в аккуратное API. Сделал 40+ эндпоинтов, внедрил JWT, Swagger и поднял покрытие тестами с 20% до 80%.
Производительность: Заменять прожорливый Elasticsearch на Meilisearch. Точность поиска выросла на 40%, а потребление памяти упало на 60%.
Надёжность: Устранять проблему, когда сервер падал(OOM) при выгрузке сотен тысяч товаров. Реализовал чанкование и курсоры — выгрузка ускорилась в 5 раз.
Бизнес-логика: Строить систему прав доступа, чтобы админы могли гибко настраивать всё через визуальный интерфейс.
Парсинг: Парсить данные с разных крупных маркетплейсов(синих, фиолетовых, авто).
С последнего места ушёл не сам — проект закрыли, инвесторы слились. Оказывается, и такое бывает.
Если в Вашей компании/отделе ищут такого сотрудника — черкните, пожалуйста, контакты для связи. Скину резюме, всё расскажу подробнее.
Docker, CI/CD, PostgreSQL/MySQL и сопутствующий инструментарий.
Привет. Решил рассказать, как взялся писать собственного чат-менеджера.
Чат-менеджер - это система, которая управляет ботом в чатах ВК, Телеграма и других платформ. Обычно такие боты умеют банить, мутить, фильтровать спам, давать фишки вроде установки ника, просмотра погоды и т.д.
Я пользовался разными готовыми чат-менеджерами, но всё чаще видел, что функционала не хватает. Просьбы о доработках игнорировались. Плюс когда-то я занимался разработкой игровых серверов на Source-движке (Valve/Steam) и использовал плагины, которые связывали сервера с чатами ВК/ТГ. Работало это криво: возможностей мало, обновлений почти нет. Поэтому я решил сделать свой вариант - бесплатный.
В тот же день сел и начал писать. Выбрал Laravel на PHP - удобный и живой фреймворк.
Что уже работает:
• мультиплатформенный чат-бот с собственной архитектурой;
• интеграция с ВКонтакте и Telegram;
• интеграция с игровыми серверами Counter-Strike Source v34/v93 (OB) и CS:GO Legacy;
• модерирование: бан, мут, капча;
• развлекательные команды: ники, браки, мини-игры, погода и др.;
• серверные фишки: репорт-система, онлайн, статус сервера, обмен сообщениями.
На стороне игровых серверов работает плагин на SourcePawn под Sourcemod. Архитектура - ядро + модули, взаимодействующие через REST API.
Сейчас доделываю обновление, которое позволит любому пользователю привязать свой Steam ID и смотреть игровую статистику прямо из чата. Для этого сделал конвертер SteamID → Steam2 / Steam3 / Steam64 / AccountID / URL Profile.
Планы: завершить «базовую часть» - статистику чата, глобальные антиспам-детекторы, команду /спам. После этого - расширения под CS 1.6 (AMXX 1.9+) и под CS2 (C#). Опыт есть в обеих средах, а вот времени не очень.
Возможно позже посмотрю в сторону модулей для Discord и Max. Да, знаю - Max сейчас все хейтят, так что не кидайтесь сильно 🙂
Разработка на 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 и скрипты — «сторожи качества» при коммите и пуше;
обязательное тестирование новых и изменённых классов.
Если внедрить всё это, можно:
сократить время на исправления;
поддерживать единообразный стиль кода;
повысить предсказуемость и стабильность приложения;
и главное — освободить команду для работы над функционалом, а не над «ремонтами кода».
Всем привет! Вы просили - я сделал! Я выпустил релиз №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
