Всем привет! В преддверии НГ не хочется оставаться без банки кабачковой икры. Собственно, ищу работу удалённо уже около 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 и сопутствующий инструментарий.
Был у меня как-то двухнедельный отпуск. Можно было расслабиться, никуда не ехать отдыхать (айтишники совсем заелись, скажете вы). От программирования устал, решил переключиться на какое-то другое занятие на эти пару недель. Уже давно была идея написать песню про IT. Даже некоторые черновики и наброски были. Тут я подумал, что это отличное время, чтобы воплотить идею в жизнь.
Исходные данные
Китайский микрофон fifine за 4к
Установленный по дефолту на макбуке garageband
Овер 10 лет опыта в айтишке
Очень базовые навыки в музыке (как раз к этому времени бросил занятия на фортепиано после 6 месяцев с нуля)
Моя домашняя студия
Работа над песнями
Первый текст собрал из черновиков. Он был про всеми известные принципы ООП и SOLID, но развернутый в уличный манер. Хотелось сделать переплетения айтишных терминов с жизненными ситуациями. Текст был написан довольно быстро, где-то за час.
Подумал, что писать музыку с нуля в 2025 может уже и лишнее. Зашел на сайтик бесплатных битов. Нашел интересный бит, скачал, попробовал записать что-то в garageband. В целом получилось атмосферно, хоть и на коленке. Мне не хотелось получить что-то высококачественное. Руководствовался тем, что нужно сначала выпустить MVP, собрать обратную связь, а уж потом работать над качеством.
Показал запись трека нескольким друзьям-айтишникам. Одни говорили, что я спятил, делать нечто такое в свои 35. Другие сказали, что им весьма зашло.
Тем временем вооружившись ютубом я начал осваивать garageband. Написал еще штук 6 песен. Решил полученные навыки опробовать на практике, и биты для новых песен писал уже сам. Где-то придумал на клавишах мелодию, где-то записал гитару, что-то собрал из готовых семплов.
Мои попытки освоить garageband
Проблемы
Когда записывал вокал в разные дни - не мог повторить тот же звук голоса, что был записан несколькими днями ранее. Так как париться с этим не хотелось - записал какие-то вещи поверх, в каких-то отдельных кусках вокал звучит по-другому. Но, подумал, что так даже искренее, чем когда все вылизано и четко.
Кент по музыке сказал, что нужно пытаться попать в плейлисты яндекс-музыки. А альбомы нет смысла выкладывать, пока нет аудитории. Вобщем решил последовать его совету, несмотря на то, что это задумывалось, как небольшой узконаправленный проектик.
Я забыл, где скачал бит для первой песни. На стриммингах можно легко нарушить авторские права. Очень долго пытался найти источник. В итоге в истории браузера нашел ссылку. Мне повезло - бит был под лицензией CC0, считай передан в народное творчество.
Звук у первого трека вышел совсем плохой. Отсутствие навыков сведения и мастеринга дали о себе знать. Не получилось даже сбалансировать громкость вокала и музыки. Но к следующим композициям стало получше.
Проблем было больше, но все перечислять долго и не очень целесообразно в рамках этой статьи.
Запуск и продвижение
Обсудили с кентом по музыке, что будем выкладывать по 1 треку с перерывом в 4-5 недель. В итоге я перестал рассчитывать на попадание в плейлисты и стратегию поменял. Сейчас на стримингах 2 трека, ожидаю в ближайшие 2 недели еще 2.
Название придумал сомнительное, но в голову больше ничего не пришло. DeadOS -с одной стороны связано с DDoS, с другой стороны нечто мрачное (dead), ну и в целом созвучно с ласковым названием деда (пожилого человека).
Я состою в нескольких IT-сообществах, а также делюсь творчеством с коллегами. Это сейчас основная моя аудитория слушателей, если можно так назвать =)
Пару синглов уже на стриммингах, еще пару выйдут в ближайшие пятницы
Фидбэк у людей неоднозначный. Но многим заходит - это здорово. А главное, что мне самому нравится! Делаю в первую очередь для души) Многие сравнивают с кровостоком из-за монотонной подачи. Кто-то с "кантейниром", но тут наверное сходства случайны (почти не слушал их). Кому-то нравятся панчи, кому-то сторителлинг. Но даже те, кому нравятся треки, редко подписываются на соцсети. Возможно айтишники этого не любят 😔
Если кому-то история зайдет, напишу еще про разные нюансы: модерации обложек, верификации на стриммингах, боль от вертикальных видео, другие возникающие проблемы. Про то, как объяснял жене, про что вообще эти песни.
P.S. Если кто-то дослушал ООП до конца - да, я действительно писал на php в свои 22 года.
Разработка на 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 и скрипты — «сторожи качества» при коммите и пуше;
обязательное тестирование новых и изменённых классов.
Если внедрить всё это, можно:
сократить время на исправления;
поддерживать единообразный стиль кода;
повысить предсказуемость и стабильность приложения;
и главное — освободить команду для работы над функционалом, а не над «ремонтами кода».
Сделал телеграм бота, внезапоно, на php. Решил попробовать асинхронность с помощью ReactPhp и мне показалось это очень удобным. Буду дальше копать эту тему, если идейки по другим простым ботам.
Получился очень шустрый и бот пока с минимальным функционалом генерация картинки по коду в чат режиме и inline через @codepreview_bot Нет ни интграция с pastebin и пока плохо стилизует код для разных языков, но если бот людям зайдет это будет несложно добавить. Для моих целей пока хвататет.
