🎁 РОЗЫГРЫШ $2000 ОТ SERG ACCS

🥇 1 место — $1000
🥈 2 место — $700
🥉 3 место — $300

Как участвовать:
1️⃣ Подпишитесь на канал
2️⃣ Нажмите «✅ Участвую»
3️⃣ Получите 1 стартовый билет

Больше билетов:
🛒 Покупки — минимум 1 билет, далее +1 за каждые полные $50 реальной оплаты. Максимум — 50.
👥 Рефералы — +5 за первую подходящую покупку друга и +1 за каждые накопленные $100 его покупок. Максимум — 50.

Общий максимум — 100 билетов.
Чем больше билетов, тем выше шанс. Даже 1 билет участвует.

Призы начислим на баланс в боте SERG ACCS.

Итоги 15.09. Всем удачи! 🔥

5 ошибок в Symfony, которые ломают архитектуру раньше, чем код

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

— Смешивают HTTP, домен и доступ к данным в одном сервисе; потом любой рефакторинг превращается в раскопки.
— Тащат контейнер везде подряд: если класс нельзя создать без Service Locator, у вас уже не DI, а скрытая связность.
— Переиспользуют Form/Controller как бизнес-слой: валидация живёт отдельно, доменная логика — отдельно.
— Игнорируют события и сообщения там, где нужна развязка: синхронные цепочки быстро становятся хрупкими.

Ещё одна типовая проблема — «умные» сущности с побочными эффектами. В Symfony это особенно больно, потому что Doctrine и сервисы начинают тянуть друг друга за собой. Лучше держать сущности тупыми, а сценарии — в application-слое.

Если проект растёт, проверьте три вещи: кто принимает решение, где живёт транзакция и можно ли заменить один сервис без каскада правок. Если на эти вопросы нет короткого ответа, архитектура уже просит ревизии.

PHP ломается не в синтаксисе, а в мелких решениях, которые потом дороже переписывать

За неделю в репах чаще всего видно одно и то же: код работает, но живёт на случайностях. В PHP это обычно вылезает в трёх местах:
— смешали форматирование, доменную логику и запросы к БД в одном классе;
— начали передавать массивы вместо объектов и потеряли контракт;
— не проверили типы на границе входа, а потом ловят странные null и пустые строки.

Есть наблюдение которое стоит проверить: если метод нельзя назвать без слова «process», «handle» или «do», в нём, скорее всего, слишком много ответственности. Разделяйте чтение данных, преобразование и запись. Тогда тесты становятся короче, а баги — локальнее.

Для типичных PHP-проектов полезны простые правила:
— вход валидируется сразу, на краю системы;
— в бизнес-слое работают объекты, а не сырые массивы;
— наружу отдают DTO или ресурс, а не весь внутренний state;
— исключения не глотаются, а переводятся в понятные коды и сообщения.

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

Держите PHP-код скучным на поверхности и строгим внутри: меньше магии, больше явных контрактов, и поддержка перестаёт быть лотереей.

Composer ломается не из-за пакетов, а из-за грязного порядка зависимостей

Заархивировать проблему просто: Composer почти всегда падает не потому, что «плохой пакет», а потому что проект собран без дисциплины. Сначала смотрим composer.json: версии, конфликтующие расширения, лишние прямые зависимости. Потом — lock-файл: если он расходится с реальностью, воспроизведение багов превращается в лотерею.

Три проверки, которые экономят часы:
— composer validate перед коммитом
— composer install, если нужен воспроизводимый результат
— composer update vendor/package вместо общего апдейта, когда чините точечную проблему

Ещё одна типовая ошибка — автозагрузка. Если класс «виден локально, но не виден в CI», почти всегда виноваты namespace, PSR-4 или забытый dump-autoload. И отдельно проверьте скрипты: post-install/post-update часто тащат побочные эффекты, которые маскируют настоящую причину сбоя ⚙️

Держите Composer как инструмент контроля, а не как кнопку «переустановить всё». Чем точнее зависимость описана, тем быстрее проект собирается и тем легче ловить регрессии.

Composer ломает проект не тогда, когда пакеты плохие, а когда автозагрузка и версии не зафиксированы

Если Composer в проекте воспринимают как «установщик библиотек», проблемы обычно приходят в самый неудобный момент: разные окружения тянут разные деревья зависимостей, а `vendor/` перестаёт быть предсказуемым. Здесь важны не красивые команды, а дисциплина.

— фиксируйте ограничения в `composer.json`: `require`, `require-dev`, `conflict`, `provide`;
— коммитьте `composer.lock`, если проект не библиотека;
— не смешивайте ручное редактирование `vendor` и нормальную установку через Composer;
— проверяйте `autoload` и `autoload-dev`, если классы «исчезают» после деплоя.

Отдельно следите за пакетами с тяжёлым bootstrapping: они могут увеличивать время старта, тянуть лишние сервисы и ломать CLI-скрипты. Если пакет нужен только в dev-режиме, он не должен жить в runtime-контуре приложения.

Ещё один частый провал — слепое обновление зависимостей. Сначала смотрят, кто за что отвечает, потом обновляют по одному слою: framework, потом пакеты, потом мелкие утилиты. Так проще поймать конфликт раньше, чем он всплывёт на проде.

Держите Composer не как кнопку «обновить всё», а как контракт между кодом, окружением и деплоем — тогда половина «магических» багов исчезает ещё до запуска.

Лонгрид о мемном кейсе Melbet vs Pepper Partners - реально ли оценить в аффилейтке репутационный ущерб в деньгах?

История на $2,000 вряд ли разрушит крупный бренд. Но она вполне может стоить ему сотен тысяч долларов и более, если публично остаётся без внятного решения.

Я в аффилейт-маркетинге более 25 лет, а последние пару лет одно из моих основных направлений - B2B matchmaking. Поэтому я регулярно вижу споры между компаниями о выплатах и претензии, и таких ситуаций в рынке явно становится больше.

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

Вот например про один из таких кейсов писал уже здесь весной.

Если неконструктивны обе стороны (а бывает и так), то можно к этому относиться просто как к развлекательному контенту.

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

Сейчас самый заметный в аффилейт рынке пример это кейс Melbet <> Pepper Partners, который уже более месяца развивается в публичном поле и о нем уже писали и многие аффилейт медиа, и отдельные блоги, я наверно один из последних, кто у себя в блоге еще об этом не писал)

Изначальное заявление кейса и описание претензии от Pepper Partners можно почитать здесь.

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

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

Для мелкого и крупного бренда такие истории могут иметь очень разный эффект, поэтому здесь разберем на примере крупного бренда, так как Melbet в нашем рынке относится именно к таким.

Не знаю конечно их точные цифры затрат на PR в рамках афф рынка (участие в конфах, собственные ивенты, реклама в афф медиа и т.п.), но из того, что вижу как организатор ивентов с приличным опытом, этот бюджет явно измеряется в миллионах $ в год, если не выходит за $10млн+.

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

И вот уже более месяца в паблике незакрытый и не откоммуницированный публично кейс на $2k (две тысячи долларов).

В публичной дискуссии сейчас преобладает позиция, что Melbet в этом споре неправы.

Может их развернутая публичная позиция поменяла бы мнение, но ее нет, соответственно на данный момент так.

Какие материальные потери может понести бренд в такой истории?

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

Рухнет бренд (закроется, обанкротится) - значит плохо на них повлиял кейс.

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

Но это же совсем не так, ситуация не бинарная.

Представим не фактические цифры Melbet, которых у нас нет, а консервативную модель крупного рекламодателя.

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

Я не знаю внутренний LTV партнёра у Melbet. Но если принять для активного опытного аффилейта условные $10,000 LTV, десять таких потерянных партнеров - это уже шестизначная сумма $ недополученного дохода. И это без учёта крупных команд, в случае которых эффект может быть кратно выше и оказаться семизначным.

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

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

Одна известная в рынке команда публично рассказала о своем таком решении в моем чатике про scam-кейсы.

А теперь вернемся к миллионам долларов в год, которые Melbet тратит на публичный PR среди аффов через конфы и прочие активности.

У этих трат же есть определенные ожидаемые и реальные результаты, верно?

На каждый затраченный миллион ожидается определенное количество привлеченных новых партнеров и укрепление лояльности и увеличение оборотов с определенным количеством действующих партнеров.

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

При таком незакрытом публичном кейсе, вызывающем большой отклик и возмущение в рынке - останется эта сумма выхлопа с PR X без учета прочих факторов или она станет меньше X?

Очевидно станет меньше, доверие к бренду ниже, а значит и вложения в PR дают меньшую отдачу.

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

Когда бренд инвестирует миллионы в доверие рынка - через конференции, медиа, партнёрские активности и PR, игнорирование аргументированного публичного конфликта снижает отдачу от всех этих вложений. Репутация не выглядит отдельной строкой в P&L, но её потеря вполне превращается в недополученный доход, более дорогой PR и менее лояльных партнёров.

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

Всем отличной недели и благоразумия)

7 PHP-пакетов, которые стоит проверить до того как тащить код в прод

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

— Для конфигов и env-обвязки берут spatie/laravel-data или аналоги с явной схемой: меньше магии, проще тестировать.
— Для очередей, кэша, файлов и событий лучше пакеты, которые опираются на контракт Laravel, а не лезут в ядро через reflection.
— Для логики домена ищите библиотеки без фреймворк-зависимости: так их проще переиспользовать в Symfony, CLI или воркерах.
— Любой пакет с генерацией кода проверяйте на предсказуемость: что создаёт, как обновляет, как удаляет.

Перед установкой смотрите не только на звёзды, а на API, частоту breaking changes, наличие тестов и читаемость README. Если пакет нельзя быстро обернуть в свой адаптер, он почти всегда слишком дорогой в сопровождении.

Правило простое: пакет можно брать, если вы понимаете его границы и готовы удалить его без переписывания половины проекта.

$80 за FTD на СНГ — казино-оффер от ПОКЕРОК Partners

Ищете новый оффер для теста? Рассказываем, что предлагаем партнёрам:
• CPA $80 за FTD на все гео СНГ
• $100 к первой выплате для новых аффилиатов
• 5% по саб-реферальной программе
• прозрачная статистика в партнёрском кабинете
• поддержка личного менеджера

Принимаем различные источники: social, мессенджеры, YouTube / Twitch / Kick, SEO, PPC, in-app и медийный трафик.

В казино ПОКЕРОК также доступна GG99 — линейка из 20+ игр с RTP 99%, включая слоты, настольные игры, видеопокер и аркады. Это весомое преимущество для новых игроков в дополнение к приветственным бонусам.

И ещё один повод подключиться уже сейчас: 27 августа состоится Friendly Tournament для партнёров ПОКЕРОК Partners. Успейте подключиться до 25 августа, чтобы принять участие!

Присоединяйтесь к ПОКЕРОК Partners и начинайте зарабатывать на своём трафике уже сейчас!

Composer в проде ломается не из-за пакетов, а из-за слабой дисциплины lock-файла

composer.lock — не артефакт «для локалки», а снимок dependency graph. В приложении он должен жить в репозитории; без него staging, CI и prod могут собрать разные деревья даже при одинаковом composer.json.

Правила, которые экономят часы:
— composer install для деплоя и CI, update — только осознанно;
— не коммитить vendor, но кэшировать загрузки в пайплайне;
— фиксировать platform PHP/ext, если прод отличается от машины разработчика;
— проверять scripts: туда часто прячется побочный эффект сборки.

Есть наблюдение которое стоит проверить: большинство «мистических» падений после релиза связано не с Laravel, а с транзитивной зависимостью, подтянутой широким constraint вроде ^ без ревью diff в lock.

Минимальная гигиена: отдельный PR на обновление пакетов, просмотр changelog критичных библиотек, composer audit в CI и запрет ручного редактирования lock-файла. Composer должен быть повторяемым механизмом, а не рулеткой перед деплоем.

Filament ломается не в ресурсах, а в мелочах схемы и авторизации

Частая ошибка — тащить в админку «как в API»: отдельные сервисы, сложные DTO и магию в каждом поле. Filament лучше живёт, когда Form, Table и Action описывают один и тот же домен, а бизнес-логика вынесена в модели, policy и сервисы.

Проверь базовые вещи до первой страницы:
— видимость полей через hidden/visible, а не через if по всему компоненту;
— авторизацию на уровне policy, не только в кнопке;
— фильтры и сортировки на сервере, иначе таблица быстро начинает тормозить;
— повторяющиеся поля собери в схемы или traits, чтобы не плодить копии.

Ещё один частый провал — попытка сделать из Filament полноценный SPA. Он силён там, где нужен быстрый CRUD, вложенные relation managers, bulk actions и понятная админка для команды. Как только начинается тяжёлая интерактивность, сложные переходы состояния и много асинхронщины, лучше заранее проверить, не дешевле ли вынести это в отдельный экран.

Если держать логику рядом с доменом и не перегружать компоненты, Filament даёт очень быструю сборку админки без архитектурного мусора.

Octane ломает не Laravel, а привычки вокруг него: вот где чаще всего течёт память

Octane полезен там, где важны низкая задержка и высокая плотность запросов, но он меняет модель жизни приложения. Код перестаёт умирать после каждого запроса, а значит, любая «мелочь» может стать утечкой состояния.

Проверь в первую очередь:
— статические свойства и одиночки, которые копят данные между запросами;
— кеш в памяти процесса, который никто не сбрасывает;
— замыкания с захваченными объектами;
— мутируемые синглтоны в сервис-контейнере;
— соединения и клиентские объекты, которые создаются один раз и живут слишком долго.

Отдельный класс проблем — worker-safe код. Если пакет безопасен в обычном PHP-FPM, это ещё не значит, что он безопасен под долгоживущим воркером. Любая глобальная переменная, временный хелпер или «удобный» static cache могут дать странные побочные эффекты уже на втором запросе. Перед включением Octane прогоняй типовой сценарий под нагрузкой и смотри не на скорость, а на стабильность памяти и предсказуемость ответов.

Хорошее правило простое: всё, что должно быть уникальным для запроса, не должно жить дольше запроса. Если это соблюдено, Octane даёт прирост без сюрпризов; если нет — он просто ускоряет баги.