#humor

Геніально

#вакансія

🚀 У команду ALLO шукаємо Magento 2 PHP Developer.

Що буде в роботі:
• оптимізація продуктивності Magento;
• робота з високонавантаженим eCommerce;
• підтримка інтеграцій;
• участь в переході на SOA;

Буде плюсом: свіжий досвід роботи з Symfony

📍 Віддалено.
💰 Конкурентна компенсація, медичне страхування, англійська, корпоративні бонуси.

https://djinni.co/jobs/837209-magento-developer/

PS
Ми будуємо нову платформену архітектуру, поступово відходимо від моноліту та рухаємося в бік сучасних сервісних рішень. Це гарна можливість для Magento-розробника не лише працювати з eCommerce, а й поступово перейти до більш сучасної архітектури та розширити свою експертизу.

#humor

Хто першим постраждає при повстанні машин?

#humor

Жиза

#humor
Клуб анонімних ПХПшників

Трохи офтопу
Останніми днями я написав кілька пісень і є бажання робити це інколи і далі

Прошу послухати і якщо щось відгукується, підписуйтеся на канал і ставте лайки та пишіть коменти
https://www.youtube.com/@ashterix-band

#humor #quote #wtf

Якщо ви теж пройшли весь бекенд на 100%, як цей поважний пан — завантажуйте DLC "Symfony".
Нові квести, складніші боси, ще 2000 годин проходження та мінус 80% самооцінки.

#humor
Так і народжуються тімліди

#php #debug
Руснявість причаїлася там, де не чекав 🇺🇦

Сьогодні зловив цікавий баг, який вкотре нагадав, наскільки русифікованим був світ навколо нас до 2022 року.

Після чергового деплою Symfony-додаток почав віддавати 500. Причину знайшов швидко:


DateTimeZone::__construct(): Unknown or bad timezone (Europe/Kyiv)

Виявилося, що PHP на сервері не знає часового поясу Europe/Kyiv, хоча локально все працює і CI проходить без помилок.

А причина цікавіша, ніж здається.
До 2022 року часовий пояс Києва в базі IANA називався Europe/Kiev.
У версії tzdata 2022b його перейменували на Europe/Kyiv — відповідно до української транслітерації.

І ось у 2026 році сервер із застарілою базою часових поясів не розуміє, що таке Europe/Kyiv.

Тобто застосунок падає не через помилку в коді, не через несумісність PHP чи Symfony, а через те, що сервер досі називає Київ через русняву транслітерацію.

І приємно бачити, що навіть на рівні технічних стандартів світ поступово вчиться називати українські міста українськими іменами. 🇺🇦

#ai #architecture #longread

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

ШІ не прибирає складність системи, але суттєво спрощує її реалізацію.

Сильний інженер із ШІ вже сьогодні здатен самостійно реалізувати те, для чого раніше знадобилася б ціла команда.

Але тут виникає цікавий парадокс: що краще ШІ вміє писати код, то ціннішими стають інженери та архітектори, які розуміють, що саме він пише і які наслідки це матиме.

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

Нещодавно натрапив на цікаві думки кількох відомих інженерів та архітекторів програмного забезпечення.
Unmesh Joshi у дискусії LLMs and the what/how loop за участю Martin Fowler та Rebecca Parsons висловлює думку:

«Головний виклик розробки програмного забезпечення — створювати системи, здатні переживати зміни».

Martin Fowler у тій самій дискусії наголошує:

«Щоб спростити внесення змін, нам потрібно керувати когнітивним навантаженням».

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

А дядько Боб (Robert C. Martin) пішов ще далі.
У розмові про інженерію в епоху ШІ він розповідає, що дедалі менше читає згенерований агентами код, натомість контролює результат через архітектурні обмеження, статичний аналіз, тести та перевірки залежностей.

Фактично він переходить від контролю кожного рядка до контролю властивостей системи.

І ось тут, на мою думку, ми підходимо до найцікавішого.

Раніше значна частина цінності розробника полягала у здатності реалізувати рішення. Тепер сама реалізація поступово стає дешевшою, але вартість помилкового рішення нікуди не зникає. Навпаки, ШІ дозволяє масштабувати не лише правильні рішення, а й помилки.

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

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

ШІ може зробити сильного інженера значно продуктивнішим. Але він не перетворює автоматично слабкого інженера на сильного.

І наостанок висновок, який я сформулював на базі тієї думки:

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

Бо відповідальність за систему все одно залишається за інженером.