І знову мені впадлу було писати дофіга тестів сьогодні. Пʼятниця ж. Звичайно, це завдання віддав АІ агентам. Півдня дивився на ті художества: фейспалмив і писав купу промптів. Може треба було самому писати? 🫠

При чому останнім часом що бачу:
- Sonnet 3.7 став набагато гірше в порівнянні з Gemini 2.5 Pro.
- Gemini 2.5 Pro останнім часом дуже засмучувати став. Відверту дичину все частіше видає.
- Sonnet 4 поки веде себе найадекватніше.
- OpenAI для кодингу майже перестав використовувати.

Агенти:
- Github Copilot найадекватніше пише тести.
- Junie - джун для простої і рутинної роботи. Поки складнішу роботу не довірю.

Це в контексті роботи в PHP Storm.
Треба трохи часу поковбасити Cursor і MCP сервери попіднімати.


А який досвід у вас в цьому? Цікаво порівняти.

Продовжую навалювати, як старий дід

Пропоную вам швидкий самоперевірочний тест своїх навичок у маршрутизації Laravel!

9 швидких запитань. Без балів та результатів. Просто натискайте "Показати відповідь", щоб відразу побачити відповідь.

Яке ваше ставлення до такої самоперевірки час від часу? 🤔 Чи варто воно того?

👉 Перейти до тесту: https://t.co/ELgaJ51f9R

Сьогодні PHP святкує 30 років!

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

І ця мова, як її маскот слоник, просто йде своєю дорогою, не дивлячись на інших. Вітаю, PHP!

Порада щодо Pest у Laravel.

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

Але як автоматично запускати Seeders, якщо вам потрібно заповнити базу певними даними після міграцій?

Ось ще один рядок, який потрібно додати до Pest.php.

Не знайшов цього в документації.

Доречі, пропустив мажорний реліз Laravel Passport.

Якщо ви його використовуєте, дуже раджу ознайомитись зі змінами.

Всі нововведення тут: https://t.co/9jHMXHgdnJ

Розкажіть, хто вже випробував!

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

Майте смачну каву, панове! ☕️

Ну що, народ, вирішив я, що пора почати створювати гайди на YouTube логічно і структуровано.

І почати потрібно з простого та банального - встановлення PHP. Почнемо з Mac.
Далі буде вінда та лінуха. Ну а там вже почну робити для вас цікаві туторіали по ларці та пхп 💪🏻

Нове відео вже на каналі.
https://www.youtube.com/watch?v=0KE4O4QRnok

По всьому світі збої роботи ChatGPT. І наче не пʼятиця, щоб в прод релізити... Дивно 🧐

Хочете пришвидшити свої Eloquent запити в Laravel? Спробуйте поєднати withCount() та withSum() для оптимізації коду.

З використанням hasMany відносин, ви можете поєднати withCount() та withSum() в одному запиті Eloquent. Це економить час і спрощує ваш код!

Приклад синтаксису:

$model->relation()->withCount('relatedModel')->withSum('relatedModel', 'amount');

І знову день дебагу з шішкою.
А як ваш день, колеги?

Зміряти продуктивність коду без сторонніх інструментів – простіше простого!

Використовуйте Benchmark::dd() для вимірювання часу виконання. Це чудово підходить для порівняння запитів до бази даних, продуктивності алгоритмів та часу відповіді API.

Загляньте в документацію: https://t.co/B1FZEJeIta

Ще одна зручна шпаргалка по гіту

Доречі про Git. Чи знаєте ви що таке Git Flow і для чого він потрібен?

Буде цікаво дізнатися? Якщо так, то дайте знати і завтра підготую вам матеріали про цей підхід.

Ви просили - я відповідаю 😉

То що ж таке отой Git Flow та нахіба він взагалі здався?

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

Головне розуміти: Git Flow ≠ інший Git. Це набір правил для кращої командної роботи.

Основні гілки у Git Flow:

1. main (або master)
• Завжди містить продакшн-версію.
• Тільки стабільний код.

2. develop
• Основна гілка для розробки.
• Сюди зливають всі завершені фічі перед релізом.

Підгілки:

3. Feature-гілки (feature/*)
• Відходять від develop
• Використовуються для розробки нових фіч.
• Після завершення зливаються назад у develop.

4. Release-гілки (release/*)
• Відходять від develop для підготовки релізу.
• Виконуються фінальні правки, підготовка changelog.
• Зливаються в main та develop.

5. Hotfix-гілки (hotfix/*)
• Відходять від main.
• Використовуються для термінових виправлень продакшну.
• Зливаються в main і develop.

Давайте розглянемо детальніше у наступних постах 👇

Тож, давайте розглянемо всі команди Git Flow в дії.

📌 1. Початок роботи з Git Flow

Щоб увімкнути Git Flow у проєкті, введи:

git flow init

Git:
• Створить гілки main і develop
• Запитає, як ти хочеш називати інші гілки
• Налаштує шаблон Git Flow

Цю команду потрібно запускати лише раз для кожного репозиторію.

📌 2. Створення фічі

Розробляєш нову функцію?

git flow feature start login

Git створює feature/login від develop.

Тут ти працюєш над фічею. Коли готово:

git flow feature finish login

Git:
• Зливає feature/login у develop
• Видаляє цю гілку

Чисто, швидко, зручно.

Далі 👇

Шо там в нас далі по списку?

📌 4. Підготовка до релізу

Коли фічі готові до релізу:

git flow release start 1.0.0

Git створює гілку release/1.0.0 від develop. Тут можна:
• Тестувати
• Виправляти баги
• Готувати changelog

Коли все ок:

git flow release finish 1.0.0

Git:
• Зливає в main і develop
• Тегує реліз
• Видаляє гілку

📌 5. Терміновий хотфікс

Знайшов баг на проді? Почни хотфікс:

git flow hotfix start fix-login

Git створить гілку від main. Ти виправляєш проблему.

Після виправлення:

git flow hotfix finish fix-login

Git:
• Зливає у main і develop
• Створює новий тег (наприклад, 1.0.1)
• Видаляє гілку

Ну от і все. Якщо такий розбір був цікавий, дайте знати про це в коментарях. Тоді спробую робити такі пости частіше 😊