У багатьох проєктах хуки стали рефлексом: їх додають автоматично, навіть там, де вони не потрібні. Але кожен зайвий хук — це додаткова складність, і часто — без вигоди. У цій доповіді разом з вами спробуємо розібратися, коли хуки не потрібні та як писати простіший та зрозуміліший код без зайвих use*.

Зараз дуже багате різноманіття інструментів для документування архітектури програмного забезпечення. При цьому з часом виникає питання, а чи є інструмент, який дозволяє не тільки зображувати архітектурні блоки як взаємопов'язані сервіси чи компоненти, а й включати комплексну інформацію про бізнес-прцеси, інформаційні системи та ІТ-інфраструктуру в єдиному вигляді? Таким інстурментом є Archimate. ArchiMate — мовa моделювання для опису, візуалізації й аналізу корпоративної архітектури, що разом з TOGAF стає потужним інструментом в руках архітектора. Під час доповіді розповім на прикладах про мову моделювання Archimate, покажу які є можливості в Archi для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.

Протягом багатьох років наша платформа для корпоративних клієнтів працювала на великому, надійному моноліті. Але з часом технічний борг, повільні релізи та залежності між модулями почали гальмувати розвиток. Настав час для переосмислення. Це історія еволюції для 150 тис. клієнтів: від паралельної роботи моноліту та мікросервісів — до Domain-Driven Development із понад 20 платформеними та продуктовими командами, від JSP до мікрофронтендів і дизайн-системи, від IBM до Open Source. Ключові інсайти: Чому стабільного моноліту вже недостатньо для сучасного банкінгу Як переходити без шкоди бізнесу і клієнтам Паралельна робота моноліту та мікросервісів — практичні уроки Domain-Driven Development у масштабі 20+ команд (платформені та продуктові) Мікрофронтенди та дизайн-система для швидших релізів Коли Open Source — правильний вибір, а коли варто купити

Пам'ятаєте часи, коли ми тиждень налаштовували Webpack до того як написати перший рядок кода? А що зараз? Зараз збірка глибоко інтегрована з фреймворком. Чи ви взагалі маєте уявлення яка конфігурація Vite у вашому Next.js чи Remix.js застосунку? Вам це потрібно? Що нам заважає позбутися збірки? Викинути її до дідька? Подивимося?

В цій доповіді Дмитро розповість як створив DSL мову для парсінга HTML сторінок, яка використовується для WEB скрапінга. Поговоримо про алгоритми дерев, оптимізацію JS-коду, DOM, а також спробуємо це все на прикладі live coding.

Не так-то вже й давно Remix фактично перестав існувати, повністю інтегрувавшись в React-router. Однак творці реміксу вже анонсували нову версію, яка буде, без перебільшення революційною – вони відмовляються від React (буде Preact), мають на меті нуль залежностей і головне – обіцяють вкотре кардинально змінити світ веб-розробки. Поки що предметно розмовляти про структуру Remix v3 ще зарано, однак ми спробуємо систематизувати чутки, пости в соцмережах та інтервʼю, щоб розібратися з тим: * кому і як знадобилося "змінювати веб-розробку"? Чи це дійсно потрібно, чи це просто черговий гучний хайп; * які ключові ідеї лежать в основі проєкту і яке моє ставлення до них; * і головне – чи це буде "той самий ремікс" в новій обгортці, чи це буде так само подібне як Angular та AngularJS.

Handling async operations in UI components can be tricky—flickering pending states, inefficient state updates, and unstable user experiences are common issues. Building accessible UI components presents additional challenges, as meeting accessibility requirements often requires extra effort, which can add complexity to the development process. In the context of the Next.js App Router, this session will demonstrate how React Server Components streamline data fetching, while other React 19 tools help manage mutations, loading states, and optimistic updates more effectively. We’ll combine these with Ariakit to simplify the process of building interactive, accessible UI components with less boilerplate. You’ll leave with practical strategies for managing async operations while ensuring a smooth, reliable user experience.

Доповідь присвячена архітектурному підходу для контролю якості AI-рішень, де замість традиційних методів тестування використовується інший AI в ролі «судді». На прикладі реального кейсу AI Calories Tracker, який щодня розпізнає 5000+ зображень страв, ми покажемо, як нестандартний підхід до контролю якості дозволяє ефективно керувати ризиками і підвищувати довіру до штучного інтелекту.

Уявіть, що одного дня вашій команді передають систему, яку 4 роки створювали шість різних команд, просто щоб перевірити гіпотези. Ніякої документації, просто гігантська монорепа і Jenkins для деплою. Саме в таких умовах ми вирішили зробити повну інвентаризацію — і почали з Architecture as Code. У цьому виступі я розповім, як ми системно підійшли до опису архітектури: від побудови C4-діаграм до створення Service Documentation, ERD та Sequence Diagram-ів. Ви дізнаєтесь, як ми на практиці відновили розуміння системи, впровадили архітектурну прозорість, а також які інструменти (PlantUML, Mermaid) та підходи спрацювали найкраще. Це не лише про діаграми — це про виживання в хаосі, командну синхронізацію та архітектурну еволюцію через прозорість.

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