#вакансія

🚀 У команду 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) пішов ще далі.
У розмові про інженерію в епоху ШІ він розповідає, що дедалі менше читає згенерований агентами код, натомість контролює результат через архітектурні обмеження, статичний аналіз, тести та перевірки залежностей.

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

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

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

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

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

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

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

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

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

#longread #php #symfony #magento #architecture #cleancode
🚀 Він йшов у моноліт на Magento, а потрапив у SOA на Symfony
або Чому я забрав Magento-розробника в команду мікросервісів?

Нещодавно проводив співбесіду на позицію Magento Backend Developer. Прийшов молодий хлопець із приблизно 2,5 роками комерційного досвіду, переважно на Magento 2. Звичайна, здавалося б, співбесіда. Але в процесі розмови я зрозумів, що в команді Magento-розробників йому немає чого робити.

І справа не в знанні Magento чи інших технологій. Із технічною базою там усе добре, він навіть встиг мігрувати Magento на PHP 8.4.

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

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

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

Чому?
Бо Symfony можна вивчити. Його компоненти, DI-контейнер, Messenger, Doctrine та інші інструменти — це питання часу й практики. А от архітектурне мислення, здатність бачити систему цілісно, розуміти межі відповідальності та оцінювати наслідки технічних рішень — це значно фундаментальніші навички.

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

Хто навчався на моїх курсах, напевно пам'ятає один із моїх основних підходів до викладання: складні речі ми розкладаємо на прості поняття, а нові концепції пояснюємо через те, що вже знайоме.

Так влаштований мозок: нові знання легше засвоювати, пов'язуючи їх з уже відомими поняттями.

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

Частину цього матеріалу я вирішив опублікувати на своєму сайті цілим пулом статей:
📖 Magento → Symfony: перехід для Backend Developer

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

У Magento ми працюємо всередині вже сформованої системи: модулі, service contracts, repositories, plugins, observers, dependency injection — усе має своє місце та визначені механізми взаємодії.

Тоді як Symfony пропонує інший підхід. Він надає інструменти, але не диктує, як саме організувати бізнес-логіку, де провести межі між компонентами та як побудувати взаємодію між ними.

Можна побудувати моноліт або мікросервіси, застосувати DDD, Hexagonal Architecture чи простішу структуру.
І жоден із цих варіантів не стане правильним лише тому, що ми використали Symfony.

Свобода архітектурних рішень передбачає відповідальність за їхні наслідки.

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

Якщо тема переходу з Magento на Symfony цікава — запрошую до статті.
Там розбираємо знайомі Magento-розробникам концепції, їхні відповідники у Symfony та принципові архітектурні відмінності.

А головна думка, яку хотів донести цією історією, проста:

Не плутайте знання інструмента з інженерною компетентністю.

Іноді найкращий кандидат на вакансію — це людина, яка ще не знає вашого технологічного стеку.
———
P.S. Знаю, що ти це читаєш, тому не зазнавайся. Поки що це лише шанс! 😉