#laratip
Laravel Collections: Магія методу pipe()

Ти знаєш цей біль: пишеш довгий ланцюжок методів у Collection, і тут бац — треба додати кастомну логіку або умовне сортування, якого немає в стандартному наборі. Що ми робимо? Перериваємо ланцюжок, створюємо тимчасову змінну...

Для таких випадків у нас є pipe(). Що він робить?

pipe() дозволяє "загорнути" поточну колекцію в замикання (closure), виконати з нею будь-які брудні (або не дуже) справи та повернути результат назад у потік.

Де це юзати?

Умовні маніпуляції: Коли сортування або фільтрація залежать від $request.

Кастомна обробка: Якщо треба прогнати дані через сервіс, який не є частиною Collection API.

Дебаг на льоту: Вставити tap() з логером посеред ланцюжка, щоб глянути, що там з даними, не зупиняючи виконання.

Це дотримує принцип Fluent Interface. Твій код читається як історія, зверху вниз, без стрибків по змінних. Це і є той самий "Developer Experience", за який ми так любимо Laravel.

Порада: Не плутайте з tap(). tap() повертає ту саму колекцію (корисно для побічних дій), а pipe() повертає результат виконання колбеку.

Менше бруду в коді — менше багів на продакшені!

Лінус Торвальдс навайбкодив проект для гітари за допомогою Google Antigravity

Автор Linux офіційно приєднався до табору тих, хто не соромиться генерувати код через AI. Підрив засад!

Днями Лінус Торвальдс виклав на GitHub проект AudioNoise – невелику утиліту для цифрової обробки аудіосигналу. Судячи з семплу в репозиторії, безпосередньо для бас-гітари.

В описі Торвальдс пояснює: це продовження попередніх експериментів з педалями ефектів, тільки тепер фокус змістився з фізичних інтерфейсів на чисто програмну обробку звуку.

Але прикол не в проекті як такому – там якась DSP-магія для гітарних ефектів, нічого революційного. Прикол у тому, що частину коду Торвальдс написав за допомогою Google Antigravity - IDE з вбудованим кодуванням AI.

Лінус Торвальдс — той самий чоловік, який у 1991 році в 21 рік написав ядро ​​операційної системи, що стала основою половини інтернету. Людина, яка десятиліттями вручну рев'юїла патчі в Linux і була відома жорсткими відмовими на неякісний код. Автор легендарних флеймів у розсилках розробників ядра.

І ось він сидить, вайбкодить гітарні ефекти і спокійно зізнається: «Так, я використав AI-асистента». Без драми, без виправдання, просто як інструмент.

Звичайно, можна сказати: «Ну, це ж не ядро ​​Linux, а якийсь пет-проект для музики, нічого серйозного». Справедливо. Але символічність від цього не змінюється. Один з головних стовпів програмування, людина, репутація якої побудована на хардкорному ручному кодингу, публічно використовує генеративний AI для написання коду.

Для когось це сигнал легітимації: якщо сам Торвальдс не соромиться, то мені можна. Для інших маркер того, що часи дійсно змінюються, і навіть легенди адаптуються під нові інструменти.

Ну що, продовжуємо працювати з інтеграцією платіжного сервісу WayForPay в життя розробників.

Бібліотека для .NET вже навіть має перші скачування. Це мотивує.

Але, ми ж тут з вами на ларці пишемо. Тому, вирішив розімʼятись та створити пакет під ларку для WayForPay.

Так, вони мають свій нативний SDK під PHP.

Але я вирішив, що можна і під нашу ларку пакет замутити, щоб наші типові e-commerce проєкти на Laravel мали можливість працювати з цією платіжкою.

Чекаю на ваші відгуки і потік Issues в Github 💪🏻

https://github.com/AratKruglik/wayforpay-laravel

Доречі, документація для пакету вже доступна в Context7. Тобто ви можете згодовувати його для ваших AI агентів через MCP.

Започаткую рубрику #бидло_промпт_інженірінг

Якщо впізнали себе і маєте подібний досвід - кидайте скріншотики в коментарі 😁

Пофіксив багу з генерацією HTML для форми віджета. Оновлюйтесь, якщо встигли встановити, звісно 😆

Підсумки періоду. Писати код самостійно — круто 😅
Добраніч і тихої ночі!

Якщо працюєте з Livewire, то коротка новина.

Відбувся реліз Livewire 4

https://github.com/livewire/livewire/releases/tag/v4.0.0

Вау! Дуже класна презентаха. Слідуйте інструкціям і гортайте сторінки. Дуже топ! Інформативно та зрозуміло.

https://yermilov.github.io/pragmatic-vibe-clauding-ua

Етюди сьогодення розробників в Україні. Як ви, шановні?

Не пройшов і рік, як наш проєкт нарешті майже мігранув на Laravel 12.

Мені скоро огляд 13ї дарки робити, а тут слоупок паті в реалі.

А шо у вас? Всі на останній ларці в проєктах у себе?

Смачної кавусі і боже збав вас сьогодні шось деплоїти. Світла нема, інтернету дефіцит, а ви ще дебажити зібрались. Ну майте совість!

Тут підписник цікавиться: у всіх такі ПМи? 🫠

Ну що, пігулочки запили смачною кавусею і погнали ту айтішку шабуршить! ☕️

#laratip

Laravel Validation Hack: Коли `required_if` вже не стягує

Знаєте ці моменти, коли валідація форми перетворюється на спробу розгадати ієрогліфи? Коли у вас є поле, яке стає обов'язковим тільки якщо "зірки зійшлися", а клієнт вибрав тип аккаунту "Platinum Business Plus"?

Звісно, можна напхати required_if:type,customer, але що як умова складніша? Ось тут на сцену виходить метод sometimes().

Суть методу

sometimes() дозволяє додавати правила валідації лише за умови, що переданий колбек поверне true. Це набагато гнучкіше за стандартні required_with чи required_unless, оскільки ви працюєте з чистим PHP всередині замикання.

Аналіз кейсів зі скріна:

1. Ізольована логіка: Правило required|email активується лише для типу customer. Це чистіше за довгі рядки валідації, особливо коли логіка виходить за межі простої перевірки "рівно/не рівно".

2. Групова валідація: Можна передати масив полів ['phone', 'address']. Це ідеально для ситуацій, коли вибір однієї опції (наприклад, способу доставки) робить обов'язковим цілий блок даних.

3. Complex Logic: В замикання приходить об'єкт $input (екземпляр Fluent). Тут можна будувати складні ланцюжки: перевіряти вкладені параметри, бізнес-ліміти чи навіть робити запити до БД. На скріні бачимо комбінацію типу аккаунту та фінансового порогу — реалізувати таке через стандартні string-правила майже неможливо.

Senior Tips

Form Requests: Не пишіть валідатор у контролері. Використовуйте FormRequest та метод withValidator($validator). Саме там цим правилам і місце, щоб тримати контролер суто для координації потоку.

DX та типи: У Symfony ми б городили FormEvents::PRE_SUBMIT або складні Callback констрейнти. Laravel дає лаконічний інтерфейс, але пам'ятайте про читабельність — якщо умова в sometimes() займає 20 рядків, краще винести її в окремий приватний метод.

Legacy: Якщо бачите в проєкті if ($request->has(...)) { $rules['field'] = ... } — це прямий кандидат на рефакторинг через sometimes().

Такий підхід робить валідацію декларативною та легшою для тестування.

Час кохве наколотити і вджобувати. Гарного дня, колеги! ☕️

Для такого нейромережі нам потрібні 💪🏻

#laratip

Custom Validation Rules: від костилів до елегантних рішень

Коли вбудованих required, string або exists стає замало, у нас є два шляхи. Вибір залежить від того, чи збираєтесь ви перевикористовувати цю логіку.

1. Inline-валідація (Closures) Підходить для унікальної логіки "тут і зараз".

Плюс: Швидко, не засмічує структуру проєкту.

Мінус: Важко тестувати окремо, копіпаст — гріх. У замикання прокидається $fail. Якщо викликали — валідація не пройшла.

2. Rule Objects (Artisan make:rule) Це вже дорослий підхід. Але зверніть увагу: на скрині старий підхід з passes() та message(). У сучасних версіях Laravel ми використовуємо один метод validate(string $attribute, mixed $value, Closure $fail): void.

Senior Tips:

Якщо логіка валідації потребує запитів до БД — виносьте в Rule-клас.

Використовуйте Rule::macro, якщо хочете додати метод у загальний білдер валідатора.

Для складних DTO та Domain-Driven Design валідацію краще тримати ближче до шару Application, а не тільки в Request-класах.

Що по коду на скрині?
Приклад з strtoupper — ок для демо, але в реалі враховуйте локалізацію та мультибайтові рядки (mb_strtoupper).

Валідувати кейс юзернейма — специфічний кейс, зазвичай ми просто робимо $request->merge() або валідуємо через Regex.

Продовжуємо корисне впровадження АІ

Пишіть ваші жарти в коментарях

Я пушу не протестований код в пʼятницю.

Девопс, який вночі на чергуванні: