Laravel починаючи з версії 12.18 тепер підтримує чотири способи реєстрації політик авторизації:

1. Наслідковий: AuthServiceProvider
2. Ручний: Gate::policy()
3. Виявлення: дотримується naming conventions
4. На основі атрибутів (новий у 12.18): #UsePolicy(...)

Це чистіше, гнучкіше та створено для сучасного PHP.

💡 А ви знаєте, що функція filled() в рекветсах розумніша за has()?

Вона не тільки перевіряє наявність ключа, але й впевнюється, що його значення не є null або порожнім.

Приклад використання:

if (filled($request->input('field'))) {
    // Ваш код тут
}

Цінуйте зручність та потужність Laravel!

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

Ранку, панство! Маю надію всі живі і неушкоджені після чергової ночі терору.

Але попри все майте смачну кавусю та гарного понеділка!☕️

Ще одне опитування для вас підготував. Прошу долучитись до голосування.

А ще прошу відповісти на питання. Які теми в форматі Shorts вам були б цікаві? Формат відео вертикальний і до 3х хвилин якщо що 😅

Це дуже допоможе мені більш структуровано готувати відео для вас. Щоб було максимально цікаво і корисно для вас. Тому ваш фідбек неймовірно важливий для мене.

Напишіть ваші побажання в коментарях!

В Laravel У колекцій є метод splitIn, який ефективно ділить колекції на рівні групи. Це ідеально підходить для організації даних по кількох колонках, командам або одиницям обробки, забезпечуючи збалансоване розподілення у вашій аплікації.

Як варіант для методу chunk(), якщо вам не потрібно оброблювати кожну частину одразу в callback функції.

Таким чином, ви зможете зручно обробляти дані і зберігати їх порядок.

#laratip

Останні пару днів я знову активно користуюсь Junie та JetBrains AI.
Кредити тупо рандомно списуються. То активніше, то навпаки наче завмирають. Хоча роблю приблизно одні й ті самі обʼєми завдань щодня.

І схоже, що в JetBrains наразі є серйозні проблеми з ціноутворенням та квотами на використання їх AI агентів. Як зазначено в документації: "JetBrains не може розкрити точну кількість кредитів..."

Чому ж інші сервіси, такі як Cursor, можуть це зробити? Відсутність прозорості може призвести до того, що багато користувачів перейдуть на інші інструменти.

А ви що думаєте?

Ну ви в курсі... Вйо каву краще пити! ☕️

Пʼятниця і щось сьогодні є бажання трохи з вами поділитись думками не про Ларку. Хоча і про неї також насправді 🙂

А думки у мене про те, що ж мені дала айтішка в житті. Що я отримав, обравши таку професію.
Може ви не знаєте, але я починав взагалі (сюрпрайз-сюрпрайз)... з юриспруденції і, на мою думку, майже 5 років роботи в цій сфері точно були потрібними, щоб потім робити те, від чого кайфую і досі.
Паралельно з тим я займався тим, що дійсно подобалось - створював сайти. Це був дуже простий фріланс, але тут я отримував свої знання. І саме тоді я спробував Laravel 4.2.
Робив я крінжатіну, але нею пишався 💪🏻

Ну а далі я зрозумів, що хочу цим займатись професійно. І так від джуна в 2013 році я дістався того пункту карʼєри, коли маю бажання і час свій досвід передавати ще комусь, кому він допоможе стати крутішим і мати те, що маю я чи навіть більше в рази.

То що я маю завдяки айтішці?

По-перше, я займаюсь тим, що мене дійсно драйвить. Це вкрай важливо для мене.
По-друге, завдяки айтішці я отримав можливість подорожувати, чого я особливо не міг раніше (я не про зараз😑) разом з родиною. Я маю чудове авто, я маю комфортне житло для тих, кого люблю. Я працюю на топовій сучасній техніці і отримую задоволення від цього. Я закрив базові матеріальні потреби майже повністю. І це дуже круто в цьому непростому матеріальному світі.

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

Завдяки айтішці я працював кожен день з топовими ведучими і журналістами на телеканалі 1+1. Крутий досвід в дійсно медіа магнаті.

Завдяки айтішці я мав можливість бачити рекламні борди компанії, в якій працював, на матчах Чемпіонатів світу та Європи з футболу та Ліги чемпіонів УЄФА. Приємні відчуття, скажу я вам.

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

Тому айтішка подарувала мені дуже круті моменти життя і драйв робити ще крутіші речі далі. І я певен, що вони мені принесуть ще більше задоволення від життя. 😎

А що айтішка для вас? 😉

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

Доречі, на таких граблях сам на початку скакав 🫣

Якщо вам цікаво, то розкажу і про це 😉

Неділька. А це означає, що сьогодні ви (маю надію) відпочиваєте і постити щось для роботи я б не хотів.

Тому розповім вам про ті граблі , на яких я танцював немало поки був джуном. Рубрика ви просили - я відповідаю. 😎

Розповідь про те як я із «спеціально одрюченої людини» став свідомим розробником.

Перше на чому ти набиваєш свої перші ґулі на лобі - це безпека даних. Мої перші роботи, навіть комерційні, які робив під замовлення були дірявими, як сито, і тоді я банально не розумів, що окрім банальної SQL інʼєкції я можу отримати. Тільки коли пару разів я отримав XSS атаки, в мене почалось формуватись стійке розуміння, що користувачу не можна довіряти. Ніколи. Ніякому. Це - аксіома.

Разом з тим запушити конфіги з різними ключами від різних сервісів чи кредами до бази - було, як води попити. Тоді в мене, як у джуна були певні проєкти на підтримці. То були різні сайти бізнесів на WordPress, Symfony та Laravel. І от на одному з них я зупинюсь окремо.

Це був сайт, написаний на Symfony з прикрученим до нього ElasticSearch. Тоді це було модно для реального повнотекстного пошуку. Але нюанс був в тому, що source of truth цього сайту був саме в ElasticSearch, а не звичайній БД. Дані з бази "розігрівались" і пушились в еластіку. І багато чого кешувалось на рівні еластіки. Як воно працювало - для мене то було рокет сайнс. Джун...

І от якось мені потрібно було почистити кеш еластіки для застосування змін на проді. А як той кеш правильно чистити я не розумів. Але ж в мене є креди для доступу на продівський сервак 😎
Шо роблю я? Вірно - лізу в файлову систему де та еластіка живе і фізично видаляю файлики, які мені здавались кешем. Робив я бекап при цьому? Не питайте - звісно ж ні.
Коротше, я вбив продівську базу з купою даних, які поклали половину сервісів замовника в найпіковіший момент, коли клієнт очікував продажі.
Коли це було? Вірно - в пʼятницю 😆 Тому фобія деплою в пʼятницю у мене звідти почалась.

І таких речей було дуже багато. Але певно тепер розумію точно, що всі ті ґулі, граблі і той досвід змусили мене вивчати більше, заглиблюватись знаннями в різні технології та механізми їх застосування.
Саме ці помилки дали буст в розвитку і формуванні навичок, що потрібні в розробці великих і крутих ентерпрайзів.

А головне не боятись цих помилок. Це ваше навчання і ВАШ досвід. Я повторю свою думку: ваші знання та ваш досвід у вас ніхто не відбере. Це - ваш актив.

Плекайте і розвивайте його!

Почитав я тут статтю на DOU мовляв AI витіснить до 40% джунівських позицій. І тут мені хочеться трохи своїх думок викласти.

По-перше, щоб одразу закрити всі питання, я не вважаю, що от прямо витіснять.

А скоріше за все на нас чекає інтелектуальна стагнація серед розробників. Чому так відбуватиметься? Все доволі просто.

Зараз завдяки нейромережам у досвідчених розробників відбулось зміщення акценту від уміння писати код до уміння вирішити проблему за допомогою коду. В той час коли у джунів відбулось зміщення акценту з як мені вирішити цю проблему до дай мені рішення цієї проблеми. Відчуваєте різницю?

Раніше як було: розробник стикався з проблемою і намагався знайти рішення цієї проблеми. Подумати, згадати, пошукати... В хід йшли: Google, StackOverflow, документація, Github. Розробник шукав альтернативне рішення, він читав чужий код і це був ключовий момент. Він шукав різні рішення, продивлявся різні відповіді, аналізував, відсіював різні варіанти та вивчав чужий код самостійно. І це було найважливішим в його розвитку. Джун синтезував ВЛАСНЕ рішення на основі отриманої інформації і знань. І от якщо це не допомагало, то, звичайно, тоді він йшов до свого ментора, тімліда, техліда і просив допомоги у вирішенні проблеми в них.

Зараз же все набагато гірше. Джун бере свій код, кидає його в нейронку, а ще гірше в умовний Cursor або Junie і каже: "Дивись, ось мій код і він не працює. Виріши це!"

І одразу джун втрачає три основні навички розробника (і написання коду не являється одним з них):

1. Відсутність навички пошуку інформації. Уміння гуглити, розбиратись в інформації та знаходити рішення на основі цієї інформації - це фундаментальна навичка і вміння будь-якого кваліфікованого розробника. Це важливіше, ніж писати код.

2. Далі у нас зʼявляється поверхневе розуміння замість глибокого. Джуну дають певний код, він його вставляє, але він не розуміє як він працює, чому воно працює і головне чи являється це найоптимальнішим рішенням чи можливо це можна було вирішити якось інакше.

3. Відсутність навичок дебажити. Процес відладки - це мистецтво пошуку помилок. Якщо нейронка замість вас знаходить помилку і виправляє її, то ви втрачаєте цю навичку. Людина просто свідомо відмовляється від навички читати умовні логи і розуміти що там відбувалось.

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

Але прикол в тому, що нейронка все одно змогла б допомогти джуну у вирішенні складної задачі, якби у нього були знання і навички описати проблему ґрунтовно і направляти свого агента на вирішення задачі.

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

На фоні цього цінність і вартість реальних інженерів буде тільки зростати. Я в цьому впевнений. Тобто, люди, які володіють критичним мисленням, фундаментальними знаннями і вміннями вирішити нестандартні задачі будуть вартувати на ринку дорого. Розрив між звичайним АІшним копіпастером і реальним Problem Solver'ом буде колосальним.

То що, не використовувати ШІшки? Звісно використовувати! Їх треба використовувати як інструмент розумно, а не як замінника себе в роботі.

А от як зростати самому та не втрачати можливість користуватись сучасними інструментами і бути конкурентним на ринку я можу навчити на персональних заняттях.

Не втрачай час та можливості!
Записуйся на консультацію, ми знайдемо шлях розвитку саме для тебе!
Роби вклад в себе зараз! Час іде, а з ним і твої можливості.

Дивіться, що буває, коли деплоїтись в пʼятницю. Якщо ви думаєте, що я чисто по приколу вам це кожної пʼятниці пишу, то ні. Це реально проблема і це реально так відбувається. Чомусь.

А взагалі я побажаю гарного робочого дня усім. Майте смачну каву!

Якщо вам потрібно завантажувати дані за числовими значеннями — замініть метод whereIn() на whereIntegerInRaw() в Laravel. Це працює швидше, бо оптимізує SQL-запит під цілі числа. Наприклад:

// Замість цього:
Product::whereIn('id', range(1, 50))->get();

// Використовуйте так:
Product::whereIntegerInRaw('id', range(1, 50))->get();

Цей трюк економить час і ресурси при роботі з великими діапазонами чисел — рекомендую спробувати у своїх проектах.

Ось лайфхак для автоматичної відправки листів у потрібній мові в Laravel! 🚀

Щоб надсилати локалізовані email кожному користувачу мовою його вибору, достатньо:

- Використати метод Mail::locale() під час відправки листа:

Mail::to($user)->locale('uk')->send(new YourMailable());

- Або ще крутіше - реалізувати інтерфейс HasLocalePreference у моделі User і повернути метод preferredLocale(), який повертає мову користувача:

use Illuminate\Contracts\Translation\HasLocalePreference;

class User extends Model implements HasLocalePreference
{
    public function preferredLocale(): string
    {
        return $this->locale; // або інша логіка, де зберігається мова
    }
}

Тоді Laravel автоматично підставить потрібну локаль під час відправки пошти або нотифікацій без зайвого коду.

Це ідеально підходить для багатомовних аплікух, які прагнуть витонченого UX.

Вже використовую — рекомендую!

Документація тут: https://laravel.com/docs/12.x/mail

PHP-розробники, тримайте чистий чек-лист найкорисніших констант мови! Від DIR до UPLOAD_ERR_NO_FILE - усе акуратно згруповано та готово до PHP 8.4.

Константи в PHP — це ідентифікатори для незмінних значень, які автоматично глобальні по всьому скрипту. Їх можна створювати через define() або ключове слово const, але const не можна використовувати в блоках коду. З PHP7 з’явилася підтримка масивних констант через define().

Ось базові факти:
- Константи не змінюються після оголошення
- Імена починаються з літери або підкреслення (без знака $)
- Константи можна використовувати в будь-якій точці скрипту, навіть у функціях

Цей список – незамінний інструмент, щоб швидко орієнтуватись у PHP-константах та писати чистий, правильний код. Збережіть собі, використовуйте регулярно і поділіться з колегами!

Пʼятничне. Будьте котиками та краще посмакуйте кавусю сьогоді.