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

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

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

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

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

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

Перше на чому ти набиваєш свої перші ґулі на лобі - це безпека даних. Мої перші роботи, навіть комерційні, які робив під замовлення були дірявими, як сито, і тоді я банально не розумів, що окрім банальної 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-константах та писати чистий, правильний код. Збережіть собі, використовуйте регулярно і поділіться з колегами!

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

Кияни, маю надію ви в порядку. Ніч у нас була пекельна. Як ви?

Якщо ви використовуєте AI агентів у своїй роботі, то ви точно знаєте, що таке MCP сервери. І тоді наступна новина саме для вас.

PHP MCP v3.0 вийшов, і це справжній прорив! Тепер як серверна, так і Laravel-пакети підтримують останню специфікацію MCP (2025-03-26) з ключовими нововведеннями:

- Потоковий HTTP-транспорт із можливістю відновлення передачі
- Провайдери автодоповнення для зручних підказок
- Просунуте керування сесіями

Ця версія робить інтеграцію з AI та обробку запитів ще швидшою і зручнішою. Рекомендую оновитись.

Новий RectorPHP 2.1 вже тут

✅ 4 нових правила для PHP 8.4!
✅ 2 нові опції конфігурації для поступового оновлення без зміни конфіг
✅ Нова типізована колекція set з 20 новими правилами для Doctrine
✅ 30 виправлень помилок... і ще багато іншого

Думаю тим, хто перейшов на PHP 8.4 точно варто оновитись.

Колеги, а хтось з Hetzer працює? Є питання по їх VPS.

Треба працювати. Пішов старий код рефакторити.
Майте смачну каву та легкого початку робочого тижня!

І анжуманя

Прискоріть виконання Laravel Pint за допомогою паралельного режиму

Як розробник, я завжди слідкую за новими технологіями, які можуть прискорити мої проєкти. "Паралельний режим" у Laravel Pint дозволяє виконувати форматування коду швидше, ніж зазвичай. Для цього потрібно використати параметр --parallel, наприклад:

./vendor/bin/pint --parallel

Цей режим дозволяє виконувати кілька завдань одночасно, що значно збільшує швидкість виконання. Крім того, можна використовувати інші параметри, такі як --test для перевірки коду без змін, або --diff для перевірки лише змінених файлів за допомогою Git:

./vendor/bin/pint --test
./vendor/bin/pint --diff=main

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

Огляд оновлення Laravel 12.20.0

1. Короткий огляд: Останнє оновлення Laravel 12.20.0 включає кілька цікавих функцій. Найбільш значущими є можливість припинення виконання черги під час обробки винятків, а також метод fakeFor() для фасаду черги. Крім цього, з’явився метод remember() для контексту та можливість налаштовувати метод pluck() колекцій за допомогою callback-функції.

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

3. Нові методи для роботи з даними: Застосунок отримав новий метод remember() для контексту та можливість використовувати callback-функції для методу pluck() колекцій. Такі оновлення дозволяють більш гнучко керувати даними й важливі для розробників, які бажають оптимізувати свої бази даних та підвищити продуктивність застосунку.

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

Кияни, ви як після ночі Вʼєтнаму? Всі в порядку?

Вайб ранку після обстрілу вночі

Ви думаєте я вас лишу без заклику не деплоїти сьогодні? Фіг там. Хто деплойне сьогодні, той на вихідних не відпочиватиме 💁‍♂️