Nightwatch вийшов в реліз

Виглядає як реально крута заміна Telescope та Pulse.

Буду тестити.

https://blog.laravel.com/announcing-laravel-nightwatch

Рубрика #думкивголос

Давайте поговоримо про досвід. Сьогодні черговий раз його відчув.

Минулі два-три тижні (сорян комусь за вʼєтнамські флешбеки) ви, мабуть, помітили, що я часто за дедлайни якісь говорив.

Справа в тому, що ми в нашій команді мали завдання інтегрувати в наш сервіс досить великий функціонал, який наші клієнти ну дуже потребували. Я опущу той момент, що коли ми почали розробку і 2/3 всього було зроблено, нас догнали менеджерські реквайрменти що ж дійсно клієнт хоче мати. А фічу вже продали і дедлайни встановили… Класика сейлзів-менеджерів-девів, коротше.

Так ось про досвід. Далі в наступному пості буде 👇🏻

#думкивголос Продовження 👆

В такому режимі довелось форсити розробку в мінімальний час до дедлайнів. Перероблювали майже все.

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

Так ось, це я до чого. Досвід, в чому він.
А він в тому, що до моменту коли всі таски не були зібрані в одну купу для релізу, я свій код НІ РАЗУ навіть локально не запускав. А коду там багато, повірте. Лише через тести то все перевіряв, яких було багато.

І що думаєте? Воно працює так, як було задумано. 😎
Вже тестуємо і ганяємо код в хвіст і гриву.

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

Я собою можу пишатись і трохи видихнути та сфокусуватись на вас і контенті для вас. Фух!

А тести… Я буду топити за те, щоб покривати тестами все, що рухається, а що не рухається - розрухати і покрити то тестами.

Всім тихої ночі, обняв! ❤️

🚀 Нарешті тут! 🔥

В Laravel 12.19+ з'явилася бажаний атрибут — #[UseEloquentBuilder]! Тепер вам не потрібно використовувати newEloquentBuilder(). Просто чистий атрибут.
Це однозначно спростить код і зробить його більш читабельним. Ну це як на мене. Що скажете ви?

Замість того, щоб писати власну логіку повторних запитів для ненадійних API, просто використовуйте Http::retry(). Ця функція автоматично повторює невдалі запити з експоненційною затримкою.

Ось приклад:

$response = Http::retry(3, 100)->get('https://example.com/api');

Документація тут: https://t.co/OJpYYLSnO6#practicalLaravelDocs

Пʼятниця, а це значить, що сьогодні ми не деплоїмо. Ви ж це памʼятаєте?

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

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'ом буде колосальним.

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

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

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