У 2026 році Kafka Streams виповнюється десять років. Фреймворк потокової обробки, що є частиною проєкту Apache Kafka під егідою Apache Software Foundation, давно вийшов за межі «додатку до брокера» і став основою місійно критичних систем у великих компаній. У свіжому епізоді Confluent Developer Podcast співрозмовником ведучого Тіма Берглунда став Матіас Й. Сакс, один із ключових контриб’юторів Kafka Streams. На тлі ювілею вони детально обговорили, як розробники сьогодні будують і тестують стрімінгові застосунки — через високорівневий DSL, низькорівневий Processor API та утиліту TopologyTestDriver, а також які зміни готуються для більш реалістичного тестування багатопартиційних топіків.

DSL проти Processor API: два обличчя Kafka Streams

Архітектура Kafka Streams з самого початку будувалася як компроміс між зручністю та контролем. Цей компроміс матеріалізувався у двох основних програмних інтерфейсах: високорівневому DSL та низькорівневому Processor API.

DSL (Domain-Specific Language) — це те, з чим стикається більшість розробників, коли вони вперше беруться за Kafka Streams. Він надає «флюєнтний» інтерфейс для опису топології обробки: потоки можна фільтрувати, групувати, агрегувати, приєднувати, трансформувати, не замислюючись про деталі внутрішньої реалізації. Код виглядає як послідовність декларативних операцій над потоками даних, де кожен крок логічно випливає з попереднього.

Цей підхід добре масштабується в командах, де важливо швидко будувати бізнес-логіку, не занурюючись у тонкощі керування станом, розподілу партицій чи внутрішніх протоколів. DSL приховує складність, дозволяючи мислити категоріями «що робити з даними», а не «як саме це реалізувати на рівні кожного запису».

На іншому полюсі — Processor API. Це нижчий рівень, де розробник отримує доступ до обробки кожного запису окремо та прямий доступ до state stores. Тут уже немає зручних ланцюжків з filter і aggregate; натомість є процесори, які викликаються для кожного повідомлення, і явні виклики до сховищ стану. Processor API дає повний контроль над логікою, продуктивністю, схемою доступу до даних і навіть тим, як саме організовано зберігання.

Такий рівень контролю потрібен там, де DSL виявляється надто обмежувальним: наприклад, коли потрібні нетипові патерни обробки, складні взаємодії з кількома state stores, специфічна оптимізація під навантаження або нестандартні гарантії щодо порядку обробки. Не дивно, що частина користувачів свідомо обирає будувати все виключно на Processor API, жертвуючи зручністю заради передбачуваності поведінки та тонкого налаштування продуктивності.

Гібридний підхід: коли DSL і Processor API працюють разом

Попри те, що DSL і Processor API часто протиставляють, Kafka Streams дозволяє поєднувати їх в одній топології. Це важливий, але не завжди очевидний для новачків аспект: розробник може описати більшу частину обробки через DSL, а в окремих вузлах «вбудувати» власні процесори, написані на Processor API.

Технічно це виглядає як вставка кастомних процесорів у топологію, визначену DSL. Потік даних проходить через стандартні операції на кшталт map, filter, groupByKey, а в певний момент потрапляє в користувацький процесор, де вже доступний повний низькорівневий контроль: можна напряму працювати зі state stores, реалізовувати нетривіальні алгоритми, змінювати структуру даних, керувати побічними ефектами.

Такий гібридний підхід дозволяє уникнути крайнощів. Замість того щоб повністю відмовлятися від DSL через одну-дві «нестандартні» ділянки логіки, команда може залишити більшість коду на високому рівні, а Processor API застосувати лише там, де це дійсно виправдано. Це знижує поріг входу для нових розробників, спрощує супровід і водночас не обмежує можливості системи.

Втім, є й інший табір: деякі користувачі свідомо будують усе виключно на Processor API. Мотивація тут зрозуміла. Коли система працює під екстремальним навантаженням або виконує критично важливі функції, максимальна прозорість і контроль над кожним кроком обробки стають пріоритетом. Processor API дає змогу точно знати, що відбувається з кожним записом, як організований доступ до стану, як поводиться застосунок під час відмов і відновлень. Для таких команд додатковий рівень абстракції DSL — це не допомога, а потенційне джерело невизначеності.

У результаті Kafka Streams фактично підтримує три стилі розробки: «чистий» DSL, «чистий» Processor API та гібридний варіант. Вибір між ними визначається не лише технічними вимогами, а й культурою команди, її досвідом у розподілених системах і готовністю інвестувати час у глибоке розуміння внутрішньої кухні фреймворку.

Як TopologyTestDriver перетворює тестування Streams на звичайні unit-тести

Як тільки мова заходить про складні стрімінгові топології, неминуче постає питання: як усе це тестувати? Історично розробникам доводилося запускати тестові кластери Kafka, використовувати testcontainers або інші інструменти для інтеграційних тестів. Це давало реалістичну картину, але було важким, повільним і погано підходило для швидких ітерацій.

Kafka Streams відповіла на цю проблему утилітою TopologyTestDriver. По суті, це засіб для unit-тестування, який симулює середовище виконання Kafka Streams без реального кластера Kafka. Розробник бере свою топологію — незалежно від того, побудована вона через DSL, Processor API чи їхню комбінацію, — і «підключає» її до тест-драйвера.

Далі сценарій виглядає дуже схожим на звичайні unit-тести. Створюються вхідні та вихідні топіки в межах TopologyTestDriver. У вхідні топіки подаються тестові записи, після чого з вихідних топіків зчитуються результати, над якими виконуються звичні для тестів перевірки: порівняння значень, перевірка порядку, наявності чи відсутності певних ключів тощо.

Ключова перевага такого підходу — затримка вимірюється мілісекундами. Немає мережевих викликів до брокера, немає запуску контейнерів, немає очікування, поки підніметься кластер. Дані «прокачуються» через топологію майже миттєво, що робить цикл «змінив код — запустив тести — отримав зворотний зв’язок» надзвичайно коротким. Для команд, які активно практикують TDD або просто покладаються на щільне покриття unit-тестами, це суттєво змінює досвід розробки.

Це не означає, що інтеграційні тести з реальним кластером стають непотрібними. Навпаки, у багатьох випадках комбінація обох підходів — єдиний спосіб упевнитися, що система працює коректно як на рівні бізнес-логіки, так і на рівні інфраструктури. Але TopologyTestDriver дозволяє винести значну частину перевірок на рівень unit-тестів, де вони дешевші, швидші й простіші в обслуговуванні.

Не дивно, що саме обмеження TopologyTestDriver стало предметом окремої ініціативи з боку спільноти. І тут на сцену виходить Michelin — один із найактивніших користувачів Kafka Streams.

Michelin, scaffolding і боротьба за реалістичне багатопартиційне тестування

Michelin — важкий користувач Kafka Streams, який побудував навколо фреймворку власне «scaffolding» для внутрішнього використання. Ці надбудови спрощують розробку, стандартизують підходи до обробки та тестування, а також закривають прогалини, які команда виявила в базовому API. Важливо, що Michelin відкрив цей код на GitHub, а інженери компанії пішли далі й почали вносити свої напрацювання назад у Kafka Streams через KIP-и (Kafka Improvement Proposals).

Деякі з цих ідей уже стали частиною основного проєкту. Покращена обробка винятків, включно з можливістю тонко налаштовувати реакцію на помилки, — один із таких прикладів. Інший — поява dead letter queue (DLQ) як повноцінної функції Kafka Streams. Те, що колись було внутрішнім патерном у Michelin, тепер доступне всім користувачам фреймворку.

Наступна ціль — TopologyTestDriver. Головне обмеження утиліти сьогодні полягає в тому, що вона моделює кожен вхідний топік лише з однією партицією. Для багатьох сценаріїв цього достатньо, але як тільки логіка застосунку залежить від розподілу ключів по партиціях, від стратегії keying або від поведінки при ребалансі, така модель стає надто спрощеною.

У реальному продакшені топіки майже завжди багатопартиційні. Від того, як саме ключі розподіляються між партиціями, залежить локальність стану, навантаження на окремі інстанси, поведінка при масштабуванні та відмовах. Якщо тестове середовище завжди працює з однією партицією, воно не дозволяє виявити цілий клас помилок: від неправильного вибору ключа до неочікуваних «гарячих» партицій.

Саме тому інженери Michelin запропонували KIP, який робить TopologyTestDriver «multi-partition aware». Ідея полягає в тому, щоб дозволити тест-драйверу моделювати кілька партицій для вхідних топіків і, відповідно, давати змогу тестам перевіряти поведінку застосунку в умовах, ближчих до реальних. Це включає тестування стратегії розподілу ключів, коректності роботи з локальними state stores, а також сценаріїв, де порядок обробки в межах партиції критично важливий.

Реалізація такої можливості — нетривіальне завдання. Потрібно зберегти простоту API TopologyTestDriver, не перетворивши його на повноцінний, але важкий емулятор кластера Kafka. Водночас тестове середовище має достатньо точно відображати семантику багатопартиційних топіків, щоб тести дійсно виявляли проблеми, які можуть проявитися в продакшені.

Попри складність, напрямок зрозумілий: спільнота прагне зробити unit-тести в Kafka Streams не лише швидкими, а й реалістичними. Ініціатива Michelin — показовий приклад того, як великі користувачі не просто адаптують фреймворк під себе, а повертають свої напрацювання в ядро проєкту, роблячи інструмент кращим для всіх.

Коли Processor API стає єдиним вибором

Повертаючись до Processor API, варто окремо зупинитися на тому, чому деякі команди обирають його як єдиний інструмент, навіть маючи під рукою зручний DSL і потужні засоби тестування.

Одна з причин — бажання повністю контролювати поведінку застосунку в умовах високого навантаження. DSL, попри всі оптимізації, залишається шаром абстракції. Він приймає за розробника низку рішень щодо того, як саме будуть організовані внутрішні вузли топології, як будуть використовуватися state stores, як оброблятимуться певні крайові випадки. Для більшості застосунків це плюс: менше коду, менше можливостей помилитися. Але в системах, де кожен відсоток продуктивності має значення, а поведінка під навантаженням повинна бути абсолютно передбачуваною, такий «автоматизм» може сприйматися як ризик.

Інша причина — необхідність реалізувати патерни, які погано вкладаються в модель DSL. Наприклад, складні маршрутизаційні рішення, динамічне створення та керування кількома state stores, нетипові схеми повторної обробки або власні механізми дедуплікації. У таких випадках Processor API дає змогу будувати все «з нуля», не підлаштовуючись під обмеження високорівневих операторів.

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

Важливо, що Kafka Streams не нав’язує жодного з підходів як «правильний». Фреймворк надає інструменти, а вибір між DSL, Processor API та їхньою комбінацією залишається за командою. У цьому сенсі розвиток TopologyTestDriver, включно з майбутньою підтримкою багатопартиційності, однаково важливий для всіх трьох стилів: незалежно від рівня абстракції, розробники отримують можливість швидко й детально тестувати свою логіку.

Спільнота, якість PR і роль великих користувачів

За останні 12 місяців Kafka Streams пережив сплеск активності спільноти. Кількість зовнішніх PR і KIP-ів помітно зросла, настільки, що мейнтейнерам доводиться буквально «наздоганяти» чергу на рев’ю. На тлі загальної дискусії про роль AI в розробці коду неминуче виникає питання: як це вплинуло на якість внесків?

Картина виявляється менш драматичною, ніж можна було б очікувати. Так, трапляються поодинокі PR-и, які виглядають як «AI-слоп»: тисячі змінених файлів без зрозумілої мети, відсутність опису, ніякої реакції автора на коментарі. Такі запити очікувано закриваються. Але загалом якість внесків залишається високою, і за кодом часто неможливо однозначно сказати, чи був він згенерований за допомогою AI, чи написаний вручну.

Ключову роль тут відіграє культура рев’ю. Мейнтейнерів не цікавить, як саме був створений код; важливо, щоб він був зрозумілим, обґрунтованим, супроводжувався адекватним описом і проходив через звичні для open source процедури обговорення. У цьому сенсі рекомендації для потенційних контриб’юторів залишаються незмінними: готувати PR так, ніби ви «готували десерт для когось» — акуратно, з поясненнями, з повагою до часу тих, хто буде це «пробувати».

Приклад із header support для state stores добре ілюструє, як виглядає продуктивна взаємодія спільноти та «ядра» проєкту. Ініціатива була пріоритезована в Confluent, до неї залучили кількох інженерів, але до роботи долучилися й 4–5 людей із ширшої спільноти. У результаті в Kafka Streams 4.3 з’являються нові типи state stores, які зберігають не лише ключ і значення, а й часову мітку та заголовки, наближаючи модель зберігання до того, як працюють самі повідомлення в Kafka.

Цей приклад важливий і в контексті Processor API. Раніше розробники, яким потрібні були заголовки в стані, змушені були будувати власні типи значень, інкапсулюючи в них і payload, і метадані. Це призводило до додаткового шаблонного коду, ускладнювало міграції та робило логіку менш прозорою. Тепер значна частина цієї роботи перекладається на сам фреймворк, а Processor API залишається інструментом там, де дійсно потрібна повна кастомізація.

Висновок: контроль, зручність і швидкий зворотний зв’язок

Десятиріччя Kafka Streams показує, що зрілість фреймворку вимірюється не лише кількістю функцій, а й тим, наскільки добре він балансує між різними потребами розробників. Високорівневий DSL дає змогу швидко будувати топології, низькорівневий Processor API — тримати під контролем кожен запис і кожен байт у state stores, а TopologyTestDriver — перевіряти все це з мілісекундною затримкою, не піднімаючи кластера Kafka.

Обмеження, які ще вчора здавалися неминучими, сьогодні стають предметом KIP-ів. Однопартиційна модель TopologyTestDriver — один із таких прикладів. Ініціатива Michelin зробити тест-драйвер багатопартиційно обізнаним показує, як великі користувачі можуть впливати на еволюцію інструменту, від якого самі залежать.

На тлі зростання ролі AI в розробці, збільшення кількості контриб’юторів і розширення команди Kafka Streams у Confluent, фреймворк продовжує рухатися в бік більшої гнучкості та кращої підтримки життєвого циклу застосунків — від написання коду до його тестування й експлуатації. І в центрі цього руху залишаються ті самі принципи: прозорість, контроль і швидкий зворотний зв’язок для розробника.

Джерело

Confluent Developer Podcast — 10 Years of Kafka Streams with Matthias J. Sax | Ep. 32

У 2026 році Kafka Streams святкує десятиріччя. Для проєкту, який починався як «ще один підпроєкт» у складі Apache Kafka під егідою Apache Software Foundation, це рубіж, що більше схожий на дорослішання, ніж просто на круглу дату. У розмові на Confluent Developer Podcast (епізод записано 13 травня 2026 року) інженер Confluent і багаторічний мейнтейнер Kafka Streams Матіас Й. Сакс озирається на шлях технології, яка з експериментальної бібліотеки для обробки потоків у Java перетворилася на основу місійно‑критичних систем і центр тяжіння для активної open source‑спільноти.

Від «молодшого брата Kafka» до місійно‑критичних навантажень

Kafka Streams з’явилася як відповідь на потребу обробляти дані безпосередньо «на краю» Kafka — у застосунках, а не в окремому кластері стримінгового рушія. За десять років ця бібліотека пройшла шлях від новинки до невід’ємної частини екосистеми Apache Kafka.

Сьогодні Kafka Streams використовується для дуже критичних для бізнесу навантажень у низці компаній. Йдеться не про допоміжні сервіси, а про системи, збій яких напряму впливає на гроші, безпеку або ключові бізнес‑процеси. Факт, що організації довіряють бібліотеці такого рівня відповідальності, — найкращий індикатор її зрілості.

За ці роки Kafka Streams встигла пройти через ключові етапи розвитку Kafka як платформи: підтримку Exactly Once, зміни в механізмах ребалансування consumer‑груп, еволюцію семантики обробки за подієвим часом. Але важливо, що при цьому вона залишилася частиною ядра Apache Kafka, а не окремим продуктом. Це означає спільну модель розробки, загальну спільноту та єдині стандарти якості під парасолькою Apache Software Foundation.

Паралельно змінювався і ландшафт стримінгових технологій. Поява керованих сервісів на кшталт Flink у хмарних провайдерів, зокрема й у Confluent, породжувала питання: чи не стане Kafka Streams «другорядним» інструментом? Поточний стан проєкту дає чітку відповідь: ні. Kafka Streams не тільки не зникає, а й отримує новий імпульс розвитку.

Стратегічна ставка Confluent: розширена команда і довгострокові інвестиції

Один із найпомітніших маркерів зрілості Kafka Streams — те, як із нею працює комерційна екосистема навколо Apache Kafka. Confluent, співзасновники якого стояли біля витоків Kafka, останніми роками суттєво наростив інженерну команду, що займається саме Kafka Streams, і відкрито позиціонує її як стратегічну технологію.

За словами Матіаса Сакса, протягом останнього року команда Kafka Streams у Confluent помітно зросла, і всередині компанії проєкт рухається «на повній парі». Це важливий сигнал для ринку з кількох причин.

По‑перше, це відповідь на побоювання, що поява керованого сервісу Flink може відволікти увагу від Kafka Streams. Інвестиції в команду, нові фічі й активна участь у розробці KIP‑ів (Kafka Improvement Proposals) демонструють протилежне: Confluent бачить Kafka Streams як окремий, самодостатній і довгостроковий напрям.

По‑друге, розширення команди означає, що в проєкту з’являється більше «пропускної здатності» для роботи зі спільнотою: рев’ю pull request‑ів, супровід KIP‑ів, планування релізів, узгодження архітектурних рішень. Для великого open source‑проєкту це критично: без достатньої кількості мейнтейнерів навіть найактивніша спільнота швидко впирається в «вузьке горлечко» у вигляді черги непроглянутих змін.

По‑третє, стратегічний фокус означає, що Kafka Streams продовжує розвиватися не лише еволюційно, а й за рахунок великих, багаторелізних ініціатив. Прикладом є масштабні зміни в роботі зі state stores, які вимагають координації кількох інженерів і залучення зовнішніх контриб’юторів. Такі проєкти складно реалізувати «на волонтерських засадах» — тут потрібна інституційна підтримка.

У результаті Kafka Streams опиняється в рідкісній для open source позиції: з одного боку, це повноцінний проєкт Apache з відкритим процесом ухвалення рішень; з іншого — він має потужного корпоративного «якоря», який гарантує стабільне фінансування й довгострокову технічну дорожню карту.

Michelin як кейс: коли користувач стає співархітектором

Один із найцікавіших сюжетів останніх років у житті Kafka Streams — історія співпраці зі світовим виробником шин Michelin. Компанія стала одним із найважчих користувачів Kafka Streams і побудувала навколо неї власний «каркас» — внутрішнє scaffolding‑рішення, яке спрощує використання Streams у продакшені.

Цей каркас вирішував типові для великих організацій завдання: стандартизація виняткових ситуацій, повторювані патерни обробки помилок, інтеграція з внутрішньою інфраструктурою, типові топології, які розробники можуть перевикористовувати. Замість того, щоб кожна команда самостійно винаходила підхід до обробки помилок або побудови топологій, Michelin централізував ці практики у вигляді бібліотеки поверх Kafka Streams.

Ключовий момент — компанія не залишила це рішення закритим. Scaffolding було відкрито на GitHub як окремий open source‑проєкт. Це вже нетиповий крок для корпоративного користувача, але історія на цьому не закінчилася. Команда Kafka Streams звернула увагу на те, що частина функціональності цього каркасу насправді має бути не зовнішнім шаром, а вбудованою можливістю самої бібліотеки.

Далі почався процес, який добре ілюструє зрілість екосистеми Kafka: інженери Michelin стали авторами KIP‑ів, що описують, як інтегрувати їхні напрацювання безпосередньо в Kafka Streams. Ці пропозиції пройшли обговорення, рев’ю і врешті були реалізовані в ядрі проєкту.

Серед уже інтегрованих можливостей — покращена обробка винятків та підтримка dead letter queue (DLQ) у Kafka Streams. Обидві функції виросли з практичних потреб великого продакшен‑користувача і тепер доступні всій спільноті як стандартні інструменти.

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

Ще один напрямок, над яким працюють інженери Michelin, — розширення TopologyTestDriver, утиліти для юніт‑тестування Kafka Streams. Їхня пропозиція — зробити тестовий драйвер багатосекційно‑обізнаним, щоб можна було повноцінно тестувати сценарії з кількома партиціями. Це логічне продовження тієї ж ідеї: усе, що стало де‑факто стандартом у внутрішньому каркасі Michelin, має шанс стати де‑юре стандартом у самій Kafka Streams.

Цей кейс показує, як великі користувачі можуть впливати на еволюцію open source‑проєктів не лише через баг‑репорти чи точкові патчі, а як повноцінні співархітектори. Для Kafka Streams це означає, що її дизайн усе більше відображає реальні продакшен‑потреби, а не лише бачення мейнтейнерів.

Сплеск контрибуцій: як спільнота масштабує розвиток Streams

Останні 12 місяців перед травнем 2026 року стали періодом різкого зростання активності спільноти навколо Kafka Streams. Мейнтейнери зафіксували «великий стрибок» у кількості контрибуцій: більше KIP‑ів, більше pull request‑ів, більше людей, які намагаються впливати на розвиток проєкту.

З одного боку, це природний наслідок зрілості технології. Чим більше компаній використовують Kafka Streams у продакшені, тим більше розробників стикаються з реальними обмеженнями й бачать можливості для покращень. З іншого — це виклик для мейнтейнерів: обсяг роботи з рев’ю й обговоренням змін зростає швидше, ніж кількість людей, які можуть цим займатися.

Матіас Сакс визнає, що в певні моменти команда була «трохи перевантажена» спробами встигнути за потоком KIP‑ів і PR‑ів. Проте загальна оцінка якості контрибуцій залишається позитивною. Попри побоювання щодо «AI‑генерованих PR‑ів» і «шуму» від автоматизованих інструментів, більшість змін виглядають осмисленими й технічно коректними.

Так, мейнтейнери бачать поодинокі приклади відверто низькоякісних PR‑ів: змінено тисячі файлів без зрозумілого опису, відсутність будь‑якого пояснення, що саме намагається зробити автор, і повна тиша у відповідь на запити прояснити контекст. Такі запити, як правило, просто закриваються після кількох тижнів очікування — це нормальна практика для великих open source‑проєктів.

Однак ці випадки радше виняток, ніж правило. У більшості PR‑ів складно навіть сказати, чи використовував автор AI‑інструменти: код виглядає цілком якісним, а процес рев’ю дозволяє відфільтрувати потенційні проблеми. Ключовий фактор — не походження коду, а те, наскільки ретельно автор підготував контриб’юшн: чи є опис, чи зрозуміла мотивація, чи враховано зворотну сумісність.

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

Це класична історія для зрілих open source‑проєктів: на певному етапі саме спільнота стає головним драйвером еволюції, а роль мейнтейнерів зміщується від «авторів» до «архітекторів і модераторів».

TopologyTestDriver і наступний рубіж тестованості

Окремий пласт еволюції Kafka Streams — це інструменти для тестування. Для бібліотеки, яка працює з розподіленими потоками даних, можливість швидко й надійно тестувати бізнес‑логіку — не розкіш, а необхідність. Саме тут у центрі уваги опиняється TopologyTestDriver.

TopologyTestDriver — це юніт‑тестова утиліта, яка симулює середовище виконання Kafka Streams. Розробник описує свою топологію, створює «віртуальні» вхідні та вихідні топіки, надсилає дані на вхід і одразу читає результати з виходу, перевіряючи, чи відповідають вони очікуванням. Усе це відбувається локально, без підняття реального кластера Kafka, з латентністю на рівні мілісекунд.

До появи TopologyTestDriver типовий підхід до тестування Kafka Streams полягав у використанні тестових контейнерів або локальних кластерів Kafka. Це давало високу наближеність до продакшен‑середовища, але було важким і повільним: кожен тест вимагав запуску зовнішньої інфраструктури. TopologyTestDriver змінив баланс, дозволивши винести значну частину перевірок у швидкі юніт‑тести, а інтеграційні тести залишити для вузького кола сценаріїв.

Втім, у поточній реалізації в TopologyTestDriver є суттєве обмеження: він моделює вхідний топік як односекційний (single partition). Це означає, що розробник не може повноцінно протестувати сценарії, де критичною є стратегія розподілу ключів по партиціях, порядок обробки між кількома партиціями або поведінка при ребалансуванні.

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

Саме цю прогалину намагається закрити новий KIP, над яким працюють інженери Michelin: пропозиція зробити TopologyTestDriver «багатосекційно‑обізнаним». Ідея полягає в тому, щоб дозволити тестовому драйверу моделювати топіки з кількома партиціями, даючи змогу тестувати ключові стратегії, розподіл навантаження й поведінку обробки в умовах, ближчих до реального кластера.

Якщо ця ініціатива буде реалізована, TopologyTestDriver зможе закрити ще більшу частину спектру тестових сценаріїв, залишивши інтеграційним тестам роль «останньої лінії оборони», а не основного інструменту. Для команд, які будують складні стримінгові системи на Kafka Streams, це означатиме суттєве прискорення циклу розробки: швидкі тести з мілісекундною латентністю замість хвилин очікування на підняття контейнерів.

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

Висновок: Kafka Streams входить у друге десятиліття як спільний проєкт індустрії

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

Стратегічні інвестиції Confluent у команду Kafka Streams, кейс Michelin як приклад глибокої інтеграції користувача в архітектуру проєкту, сплеск контрибуцій і еволюція інструментів тестування — усе це ознаки того, що Kafka Streams входить у друге десятиліття не як «додаток» до Kafka, а як повноцінний центр тяжіння в екосистемі стримінгових технологій.

При цьому вона зберігає ключову рису успішних open source‑проєктів: розвиток визначається не лише баченням однієї компанії, а й практичними потребами широкого кола користувачів. Саме ця взаємодія між мейнтейнерами, корпоративними командами й індивідуальними контриб’юторами, схоже, і стане головним фактором, який визначатиме, якою буде Kafka Streams у 2036‑му.

Джерело

10 Years of Kafka Streams with Matthias J. Sax | Ep. 32 | Confluent Developer Podcast

Команди розробників роками скаржаться на одне й те саме: більшість часу йде не на створення нового функціоналу, а на спроби розібратися в тому, що вже написано. Канал IBM Technology пропонує концепцію agentic coding — підхід, у якому AI-агенти стають повноцінними «співрозробниками» для модернізації складних систем без ризику все зламати.

Чому модернізація гальмує бізнес

Дослідження показують: 60–70% часу розробників витрачається на розуміння контексту перед тим, як безпечно змінити хоч один рядок коду. Це особливо болісно для компаній, які працюють на великих легасі-системах.

Типовий приклад — фінансова установа з монолітним Java-додатком, що одночасно обробляє:

• клієнтські рахунки
• кредитні заявки
• платежі
• звітність

Бізнес хоче додати нову можливість — AI-аналіз ризиків у реальному часі для миттєвих кредитних рішень. Але будь-яка зміна в такій системі ризикує зламати вже працюючі процеси.

Проблема не стільки в «старому» коді, скільки у втраченому розумінні:

• Чому перевірки в процесі схвалення кредиту виконуються в певному порядку?
• Чому звітний джоб запускається саме о 2:00 ночі?
• Чому одна зміна в платіжному потоці колись заморозила рахунки клієнтів на чотири години?

Документації немає, автори коду давно пішли, поверх — роки патчів і «гарячих» виправлень.

Ситуацію ускладнюють три типові фактори:

1. Заплутані залежності
   Частини системи непомітно «зрослися». Зміна формули розрахунку відсоткової ставки раптом ламає модуль комплаєнс-звітності — бо обидва тихо ділили одну таблицю в базі, про що ніхто не пам’ятав.

2. Розриви між версіями фреймворків
   Додаток працює на Java 8, а перехід на Java 17 відкриває десятки прихованих проблем у бібліотеках, які роками ніхто не чіпав. Потоки, пам’ять, сумісність — усе змінюється.

3. Неописані зовнішні інтеграції
   Система підключена до бюро кредитних історій, платіжних мереж, регуляторних шлюзів — кожен зі своїми жорсткими форматами даних. Одна зміна формату поля всередині може «покласти» нічну звітність, і команда не одразу зрозуміє чому.

У результаті кожна спроба додати новий функціонал наштовхується на страх: «А що ми ненароком зламаємо?»

Що таке agentic coding і роль AI-партнера

Agentic coding — це підхід, у якому AI-системи:

• автономно досліджують кодову базу
• будують модель зв’язків і залежностей
• пропонують зміни
• виконують технічні завдання з мінімальним втручанням людини

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

Ключовий момент: це не одноразовий аудит, а ітеративний цикл модернізації:

1. Зрозуміти, що вже існує
2. Запропонувати безпечну зміну
3. Перевірити її
4. Розширити зміни далі

Такий AI-партнер не замінює розробників, а бере на себе найважчу частину — «археологію легасі-коду».

Як AI-агент модернізує кредитну систему: покроковий цикл

У сценарії з фінансовою установою команда прагне винести логіку ухвалення кредитних рішень в окремий сервіс, щоб додати туди AI-оцінку ризиків у реальному часі. Agentic coding структурує цей процес у п’ять кроків.

1. Аналіз кодової бази

AI-агент:

• сканує додаток
• будує модель викликів (call paths)
• відстежує потоки даних
• виявляє приховані залежності

У процесі з’ясовується, що кожна кредитна заявка проходить через суворо визначену послідовність:

1. кредитні перевірки
2. перевірка по списках спостереження
3. комплаєнс-валідатори

Цей порядок ніде не був задокументований. Без такого відкриття команда могла б винести «не той» шматок логіки, і система почала б повертати некоректні рішення — проблема, яка дуже швидко проявляється в регуляторних звітах.

2. Визначення безпечних меж змін

Маючи модель системи, AI-агент:

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

Він додатково підсвічує:

• крайові умови
• спільні дані
• приховане зчеплення модулів

Команда не «вгадує» межі, а перевіряє вже змодельовані варіанти.

3. Генерація тестового покриття

До будь-яких змін AI-агент створює набір тестів, спираючись на реальну поведінку системи:

• не лише «щасливі» сценарії, а й edge cases
• тайм-аути кредитних перевірок
• часткові збої в обробці заявок
• ситуації, коли клієнт потрапляє в список спостереження посеред процесу

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

4. Роль розробників: рев’ю та затвердження

На цьому етапі люди повертаються в центр процесу:

• переглядають запропоновані межі сервісу
• перевіряють припущення
• оцінюють згенеровані тести
• затверджують кожен крок

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

5. Паралельний запуск старого й нового

Новий сервіс ухвалення рішень не підміняє старий миттєво. Обидві версії працюють паралельно:

• на вхід подаються однакові дані
• на виході — два результати для порівняння

Якщо є розбіжності, AI-агент:

• одразу їх фіксує
• надає контекст: що змінилося і де саме відбулося розходження

Це дозволяє виправити проблеми до того, як їх відчують клієнти чи виявлять регулятори.

Безпека й контроль: як не перетворити AI на «чорну скриньку»

Запуск AI-агентів у системах, що обробляють реальні кредитні заявки та формують регуляторну звітність, вимагає жорстких запобіжників. У підході agentic coding вони закладені з самого початку.

Три ключові принципи:

1. Людина завжди затверджує зміни
   Особливо ті, що впливають на звітність і регуляторні процеси. Жоден критичний апдейт не проходить без рев’ю розробника.

2. Повна історія змін у Git
   Усі правки фіксуються в системі контролю версій, їх легко переглянути й відкрутити назад у разі потреби.

3. Жодних автономних деплойментів
   AI не виводить зміни в продакшн самостійно. Останнє слово — за командою.

За таких умов agentic coding перетворюється з ризикованого експерименту на інструмент, придатний для систем, від яких щодня залежать клієнти й регулятори.

Результат для описаної фінансової організації показовий: час, який раніше зникав на «археологію» легасі-коду, був перенаправлений у розробку нового функціоналу. Команда вклалася в терміни й запустила AI-оцінку ризиків у реальному часі без критичних збоїв.

Джерело

What Is Agentic Coding? How AI Agents Modernize Code — IBM Technology

Apple на WWDC 2026 показала найбільш цілісне оновлення своєї екосистеми за останні роки — з глибокою інтеграцією штучного інтелекту, новою Siri AI та масовим «прибиранням» у системі. Оглядом і критикою ключових змін поділився канал «Канал Лучкова», на основі якого можна скласти цілісну картину того, куди рухається iOS 27 і вся платформа Apple.

Фокус на екосистемі, а не на окремих ОС

WWDC 2026 помітно відрізнялася від класичної структури презентацій Apple. Замість блочного підходу «ось нове в iOS / macOS / watchOS» компанія будувала розповідь навколо функцій, які одразу працюють на всіх типах пристроїв.

Крейг Федерігі окреслив три головні пріоритети:

• глибоке покращення самої платформи;
• посилення безпеки;
• інтеграція Apple Intelligence та нової Siri AI.

Apple заявляє, що «перекопала» буквально кожен куток системи — від macOS до смартгодинників. Ідея проста: те, що працює на смартфоні, має працювати скрізь, без відчуття, що це різні світи.

Новий вигляд і плавність інтерфейсу

Візуальні зміни не обмежуються косметикою:

• Liquid Glass тепер можна налаштовувати повзунком — від повної прозорості до максимальної матовості.
• Усі іконки в усіх ОС перероблено, до них додано додатковий шар Liquid Glass, який адаптується й налаштовується, щоб сторонні й рідні застосунки виглядали цілісно, але помітно.
• Apple окремо підкреслює роботу над плавністю анімацій і швидкістю перемикань між екранами, наводячи внутрішню аналітику: застосунки відкриваються на десятки відсотків швидше.

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

Оптимізація продуктивності навіть для старих iPhone

Один із найпомітніших технічних кроків — оновлення CPU Scheduler:

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

Результат — краща пріоритизація застосунків у фоні, менше «вбивань» програм у пам’яті та швидше повернення до вже відкритих задач навіть на відносно старих моделях.

Пошук і спільні фотоальбоми з Android

Apple переробила систему пошуку:

• нові файли на смартфоні, планшеті чи комп’ютері миттєво індексуються;
• пошук працює не лише за назвою, а й за вмістом файлів і листів.

У застосунку «Фото» з’являється важливий крок до міжплатформенності:
спільні альбоми тепер підтримують користувачів Android. Фото, зроблені на Android-смартфон, можуть автоматично з’являтися в спільному альбомі на iOS — це знімає одну з типових «екосистемних стін» Apple.

Безпека й контроль для сімей

Окремий блок змін стосується безпеки та батьківського контролю.

Дитячі акаунти та конвертація існуючих профілів

Apple додає можливість:

• створити дитячий акаунт на пристрої;
• детально контролювати, хто може телефонувати дитині, що вона може дивитися та якими застосунками користуватися;
• конвертувати вже існуючий звичайний Apple ID дитини в дитячий.

Це дозволяє не починати «з нуля», а перевести поточний профіль у безпечний режим із додатковими обмеженнями.

Паролі під контролем

Новий застосунок Passwords отримує функцію масової зміни вразливих паролів:

• система виявляє скомпрометовані чи слабкі паролі;
• користувач може одним натисканням оновити їх одразу на кількох сервісах — як у застосунках, так і в сторонніх вебсервісах.

Для епохи постійних витоків даних це одна з найпрактичніших новацій.

Siri AI та Apple Intelligence: асистент, який «бачить» екран

Головний технологічний стрибок — це Apple Intelligence у зв’язці з Google Gemini та поява Siri AI.

Контекст на екрані та нові способи виклику

Siri AI перетворюється на повноцінного асистента, який:

• розуміє, що саме зараз відбувається на екрані;
• може аналізувати контент у застосунках (наприклад, в Instagram) і працювати з ним: визначати локацію на фото й одразу відкривати її в оновлених Apple Maps;
• запускається трьома способами:
• голосом («Siri»),
• свайпом донизу з Dynamic Island,
• бічною клавішею (яку можна налаштувати).

Інтерфейс теж змінюється: спершу Siri з’являється як прозорий віджет, а при жесті розгортання перетворюється на повноцінний чат-бот.

Глибока інтеграція з файлами на Mac

На Mac Siri AI отримує доступ до файлової системи й може працювати з кількома файлами одночасно:

• користувач виділяє, наприклад, три файли різних форматів у папці;
• натискає «Запитати Siri»;
• дає завдання — порівняти дані в цих файлах;
• асистент виконує аналіз без необхідності відкривати кожен документ вручну.

Це наближає Siri до ролі універсального «надбудованого» інструмента для роботи з даними на всіх пристроях — від смартфона до ноутбука й годинника. Для цього Apple навіть створює окремий застосунок Siri App, щоб продовжувати взаємодію між девайсами.

Safari, вкладки й моніторинг сторінок

Apple Intelligence заходить і в браузер:

• розумне групування вкладок за темами (topics) — замість хаотичного списку;
• відстеження змін на вебсторінках із push-сповіщеннями;
• можливість словами описати, за якими саме змінами треба слідкувати.

Це перетворює Safari на інструмент не лише для перегляду, а й для пасивного моніторингу важливих сторінок.

Шорткати через промпти

Система Shortcuts отримує логічне AI-оновлення:

• щоб створити нову команду, достатньо словами описати бажану дію Siri;
• користувачі фактично починають ділитися не готовими шорткатами, а промптами, які їх генерують.

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

AI для зображень і фото: Image Playground та Spatial Reframing

Візуальний блок Apple Intelligence теж отримує помітні оновлення.

Image Playground: нарешті придатний генератор

Застосунок Image Playground, який раніше генерував доволі дивні іконки, тепер:

• вміє створювати якісніші зображення;
• працює з обмеженнями, що залежать від рівня підписки iCloud — про наявність лімітів прямо заявив Крейг Федерігі;
• використовує неназвану модель, але результат виглядає переконливіше, ніж раніше.

Spatial Reframing: зміна перспективи фото

Функція Spatial Reframing, яка прийшла з Apple Vision Pro, тепер доступна для фото:

• дозволяє міняти перспективу й нахил будь-якого знімка за допомогою AI;
• підходить як для креативних задач (наприклад, прев’ю для YouTube), так і для корекції невдалих ракурсів.

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

Core AI та мовні моделі

Нова система Core AI має дозволити:

• підключати різні мовні моделі до Siri AI;
• гнучко керувати тим, як саме працює асистент.

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

Головний удар по користувачах: Siri AI не працюватиме в Європі

Фінальний акорд презентації став для європейських користувачів холодним душем. Наприкінці Крейг Федерігі уточнив:

• Siri AI та пов’язані з нею функції Apple Intelligence не будуть доступні в Європі та Китаї;
• причиною названо регуляторні та безпекові обмеження в цих регіонах.

У списку підтримуваних мов немає й української. Але ключова проблема навіть не в цьому, а в тому, що головна тема WWDC 2026 — оновлений AI-асистент — просто не запрацює для європейського регіону.

Для частини користувачів технічною «обхідною дорогою» може стати:

• зміна регіону пристрою на США;
• використання VPN та інших сервісів.

Однак це не універсальне рішення й навряд чи підходить усім. Багато людей оновляться до iOS 27, очікуючи на нові AI-функції, й виявлять, що «нічого не працює» саме через регіональні обмеження.

Це піднімає принципове питання:
наскільки місце проживання тепер визначає, що користувач може робити зі своїм гаджетом? І чи не перетворюється глобальний ринок на набір «цифрових зон», де можливості пристроїв різко відрізняються?

Поки Apple готує бета-версії iOS 27, а ентузіасти вже планують тестувати новинки на американському регіоні, для Європи ситуація виглядає суперечливо: платформа стає розумнішою й ціліснішою, але ключові інструменти штучного інтелекту залишаються за географічним бар’єром.

Джерело

YouTube: iOS 27 та НОВА Siri AI від Google ШОКУЄ нюансами | WWDC 2026

YouTube Premium уже багато років викликає гарячі дискусії: одні користувачі не розуміють, навіщо платити тільки за відсутність реклами, інші ж переконують, що сервіс вартий кожної копійки. У квітні суперечки спалахнули з новою силою — YouTube знову підняв вартість Premium. Окрім головної фішки у вигляді відсутності преролів і рекламних вставок посеред відео, Premium дає доступ до YouTube Music, дозволяє завантажувати ролики в застосунку для офлайн-перегляду та дає змогу відтворювати відео у фоновому режимі на смартфонах та планшетах.

Чи буде підписка YouTube Premium корисною саме вам, значною мірою залежить від того, чи використовуєте ви всі її можливості. Переваги — від невеликих покращень досвіду перегляду до зазначених ключових функцій. Важливо й те, скільки ви фактично платите: часто можна знайти знижки в пакетах з іншими товарами та послугами. YouTube також запустив тариф Premium Lite, який урізає деякі функції в обмін на нижчу ціну — $9 на місяць, але тут ми говоримо саме про повноцінну версію сервісу. Базова ціна цього рівня стартує приблизно з $16 на місяць.

З огляду на це — кілька способів, як справді отримати максимум від YouTube Premium.

Використовуйте бонусні місяці від операторів і виробників

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

На більш щедрому боці спектра — шість безкоштовних місяців YouTube Premium при підключенні до мобільного оператора Google Fi (акція актуальна на момент написання матеріалу й діє для нового підключення до тарифу Unlimited Premium). Компанія також пропонує три місяці безкоштовного Premium разом із новим смартфоном Pixel 10a. У деяких випадках такі пропозиції можна комбінувати. Але важливо уважно читати умови.

Наприклад, авторові вдалося активувати пропозицію від Google Fi поверх уже чинної підписки, коли він підключав новий номер для огляду смартфона. Натомість у деталях акції з Pixel вказано, що вона діє тільки для нових користувачів YouTube Premium. Кілька років тому автор взагалі отримав цілий рік YouTube Premium безкоштовно після купівлі нового смартфона і планшета Samsung (станом на момент написання матеріалу в Samsung немає чинних пропозицій щодо YouTube Premium).

YouTube, звісно, розраховує, що ви продовжите підписку після закінчення бонусного періоду, але штрафів за відміну немає. Навіть якщо ви залишаєтеся з сервісом надовго, такі «безкоштовні» місяці знижують середню вартість. Якщо, наприклад, шість місяців із року ви не платите, то річна підписка фактично обходиться вполовину дешевше.

Замініть окремі музичні сервіси на YouTube Music

Якщо у вас активна підписка YouTube Premium, ви автоматично отримуєте доступ до YouTube Music. Якщо ви паралельно платите за інший сервіс — на кшталт Spotify чи Apple Music, має сенс спробувати перейти на YouTube Music (і скасувати інші підписки), щоб зекономити, особливо якщо вам не критичні «просунуті» можливості на кшталт lossless-аудіо або якщо ви й так часто слухаєте музику безпосередньо на YouTube.

Вашу історію переглядів YouTube можна використати як стартову точку — YouTube Music відразу «знатиме» ваші смаки. У тестах автора автоматичні плейлисти та мікси добре витягували треки, про які він уже забув, і досить непогано підбирали нову музику.

Якщо у вас велика бібліотека локальних музичних файлів, YouTube Music — зручний спосіб слухати їх у дорозі. На комп’ютері можна просто перетягнути треки у веб-версію сервісу, і після завантаження та обробки вони з’являться у вашій бібліотеці на будь-якому пристрої. На відміну від інших сервісів із підтримкою локальних завантажень, як-от Apple Music, у YouTube Music є окрема вкладка «Завантаження» в мобільних застосунках, що дозволяє зручно відділяти стримінгову бібліотеку від особистої.

Оскільки це продукт Google, YouTube Music добре інтегрується з Google Home, Android Auto, Google TV та Gemini. У сервісі є й подкасти — логічно, адже на самому YouTube їх величезна кількість. Чи буде YouTube Music достатньою заміною для вашого музичного сервісу, залежить від того, чи вам підходить «ютубівський» підхід до контенту. Але якщо ви розглядаєте платну підписку на YouTube, шанси, що сервіс вам зайде, значно вищі.

Кешуйте відео для офлайн-перегляду

Ще одна перевага YouTube Premium — можливість кешувати відео для локального відтворення в мобільних застосунках для iOS та Android, а також у веб-версії YouTube на комп’ютері. Якщо у вас безлімітний мобільний інтернет і стабільне покриття, це може бути не настільки важливо. Але для тих, хто часто літає, їздить у метро, живе в зоні зі слабким сигналом або має лімітний мобільний тариф, ця можливість дуже корисна.

Перебуваючи в мережі Wi‑Fi або мобільній 4G/5G, можна завантажити відео через меню з трьома крапками поруч із роликом. Переглянути завантажене можна в розділі «Ви» (You) внизу праворуч, у підрозділі «Завантаження». Якщо є довге відео, яке ви хочете подивитися в літаку чи в метро без ривків і буферизації, офлайн-режим дає змогу уникнути дорогого й нестабільного Wi‑Fi у літаку чи обривів під землею.

Пов’язана функція — Smart Downloads («Розумні завантаження»). Коли ви під’єднуєтеся до Wi‑Fi, застосунок автоматично завантажує відео, які алгоритм YouTube вважає для вас найцікавішими. Після перегляду таких роликів застосунок може сам видалити їх із пам’яті пристрою, звільняючи місце.

Smart Downloads за замовчуванням увімкнено для передплатників Premium, і це може дратувати деяких користувачів (у тому числі автора). По-перше, «розумні» завантаження можуть під’їдати заряд акумулятора в невідповідний момент. По-друге, якість таких завантажень обмежена 1080p, що розчаровує власників екранів 1440p чи 4K. На щастя, функцію можна вимкнути в меню налаштувань застосунку в розділі «Завантаження».

Використовуйте фонове відтворення та «картинку в картинці»

Одна з найкорисніших переваг підписки YouTube Premium — фонове відтворення. За замовчуванням застосунки YouTube для iOS та Android ставлять відео на паузу, коли ви їх закриваєте. Але якщо у вас є Premium, ролики продовжують грати у фоні, поки ви користуєтеся іншими застосунками на смартфоні чи планшеті.

Довгий час популярним «хакам» було відкривати YouTube в мобільному браузері, наприклад Chrome, і таким чином домагатися фонового відтворення. Однак на початку цього року Google перекрив і цей варіант. Це доволі відверта спроба монетизації — адже сама функція фонового відтворення не створює для компанії суттєвих додаткових витрат — але, попри це, вона є реально корисною частиною пакета Premium.

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

Користувачам Android варто пам’ятати про одну проблему: через агресивне енергозбереження в системі «ненажерливий» до батареї застосунок YouTube часто стає одним із перших процесів, які ОС вбиває у фоні. Це може призвести до раптової зупинки фонового відтворення, і вам доведеться знову відкривати застосунок і тиснути «Play».

Для безкоштовних користувачів лишається один обхідний варіант — режим «картинка в картинці» (Picture-in-picture, PiP). У цьому режимі відео продовжує відтворюватися в маленькому вікні у кутку екрана, поки ви працюєте в інших застосунках. YouTube відкрив PiP для всіх користувачів раніше цього року. Водночас, коли ви вимикаєте екран, відтворення все одно припиняється.

Отримуйте доступ до експериментальних та «розумних» функцій

Ті, хто готовий платити за YouTube Premium, отримують доступ до експериментальних можливостей і функцій у бета-режимі. Нині це здебільшого інструменти на базі ШІ. На момент написання матеріалу доступна, наприклад, експериментальна функція «Ask YouTube» — пошук, заснований на моделі Gemini від Google. Часи такі. Але іноді з’являються й цілком практичні оновлення інтерфейсу та функцій YouTube.

У квітні YouTube запустив для передплатників Premium функцію Auto Speed. Якщо ви регулярно пришвидшуєте відтворення довгих відео, це може стати справжнім «ґеймченджером». Замість фіксованого коефіцієнта швидкості Auto Speed динамічно підлаштовує її залежно від того, що відбувається в ролику: прискорює, коли хтось говорить повільно, та сповільнює, коли пояснюють складну інформацію. До речі, передплатники Premium також можуть вмикати вищі швидкості відтворення — до 3.0x — і мають доступ до зручного повзунка з дрібнішим кроком зміни швидкості.

Корисна ексклюзивна функція Premium — кнопка Jump Ahead («Перейти вперед»). Коли ви двічі торкаєтеся екрана, щоб перемотати відео на 10 секунд, у нижньому правому кутку плеєра з’являється ця кнопка. Натискання на неї переносить вас у той момент ролика, до якого найчастіше перемотують інші глядачі. Це дозволяє легко «перестрибувати» нудні або рекламні фрагменти — і робить перегляд по-справжньому вільним від реклами.

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

Джерело

Engadget

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

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

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

Питання до DOGE щодо можливого масштабного витоку даних соціального страхування

Минув рік відтоді, як співробітники очолюваного Ілоном Маском угруповання руйнівників держапарату під назвою Департамент урядової ефективності (Department of Government Efficiency, або DOGE) пройшлися федеральними агентствами зсередини, фактично їх демонтувавши. І досі стають відомими нові подробиці про провали в захисті даних, допущені під їхнім керівництвом.

Після входу DOGE до Адміністрації соціального страхування США досі незрозуміло, що саме сталося з одними з найчутливіших у країні даних — про це тривають судові баталії у федеральних судах. Найтривожніше повідомлення викривача полягає в тому, що DOGE нібито завантажили «живу» копію бази даних соціального страхування на ненадійний сторонній сервер, що спричинило паніку та спроби з’ясувати, яку саме інформацію там зберігали. За твердженнями, у базі могли бути номери соціального страхування й пов’язані з ними персональні дані більшості живих американців.

У судових документах Адміністрація соціального страхування визнає, що не знає напевно, що саме було на сервері, але зазначає, що DOGE уклали угоду із зовнішньою політичною адвокаційною організацією під приводом пошуку доказів виборчого шахрайства — те, на чому президент Трамп і далі наполягає без будь-яких підтверджень. Є побоювання, що базу могли використати для вибіркового переслідування американців з надуманих причин.

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

Хакери дедалі частіше атакують системи водопостачання та енергомережі

Хвиля кібератак по Європі, спрямованих проти цивільних енергетичних і водних об’єктів — електростанцій і гребель, — останнім часом задає тривожний тренд. Кілька інцидентів, приписаних (або частково покладених) на Росію, створили реальну загрозу для громад та населення.

Енергосистема Польщі зазнала атаки із використанням шкідливого ПЗ, що знищує комп’ютери, наприкінці минулого року. Також було уражено шведську теплоелектростанцію і норвезьку греблю, через що з неї вилилися об’єми води, співмірні з басейнами. На початку цього року хакери знову атакували Польщу — цього разу її об’єкти водоочистки, що свідчить: гібридна агресія Росії продовжує виходити далеко за межі суто цифрового простору.

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

Іранські урядові хакери зламали Stryker й знищили десятки тисяч пристроїв

На цьому тлі в березні відбулася гучна кібератака на американську медичну технокомпанію Stryker: іранські хакери зламали її корпоративну мережу й віддалено стерли десятки тисяч пристроїв співробітників одним ударом, що на кілька днів серйозно паралізувало діяльність компанії.

Цей інцидент став помітним зсувом у тактиці іранських кібероперацій у розпал війни на Близькому Сході. Іран, який раніше зосереджувався переважно на шпигунстві та зламах з подальшими «зливами» даних в інтересах політичних цілей, перейшов до відверто деструктивних атак у відповідь на воєнні дії. Уряд США пов’язав групу, що стоїть за атакою, з одним із підрозділів іранської розвідки. Злам мав відчутний вплив на фінансові показники Stryker у першому кварталі — навіть після того, як компанія повернула контроль над своїми системами.

Instructure під ударом ShinyHunters

Група ShinyHunters продовжує свою кампанію атак, спрямованих проти десятків компаній, використовуючи прості, але надзвичайно ефективні голосові фішингові схеми. Англомовні хакери майстерно вдають із себе IT-підтримку або, навпаки, працівників, які «забули пароль», і таким чином виманюють доступ до внутрішніх систем компаній.

Наслідки таких атак як ніхто відчули в edtech-гіганті Instructure. Хакери зламали його флагманську систему керування навчанням Canvas і викрали конфіденційні дані та персональну інформацію понад 30 мільйонів студентів і співробітників. Коли компанія відмовилася платити викуп, зловмисники зламали Canvas вдруге — цього разу вони спотворили сторінки входу до системи, через які студенти отримують доступ до екзаменів і навчальних матеріалів. Другий злам стався під час фінальної сесії у вишах і школах, зірвавши іспити для студентів по всіх США. Зрештою Instructure таки заплатила викуп, попри те, що ФБР намагалося відмовити компанію від такого кроку.

Instructure далеко не єдина жертва ShinyHunters. Це угруповання стоїть за деякими з найбільших за кількістю викрадених записів зламів: приблизно 40 мільйонів записів інтернет-провайдера Charter, щонайменше 6 мільйонів клієнтських записів круїзної компанії Carnival, а також атаки на низку організацій у сфері вищої освіти, фінансів і держсектору.

Під прицілом — ланцюги постачання, open source та великі технокомпанії

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

Деякі з найвідоміших інструментів для безпеки — зокрема Trivy від Aqua Security, менеджер паролів Bitwarden, рішення Checkmarx, а також інші великі open source-проєкти — цього року були скомпрометовані. Це дало змогу хакерам викрадати паролі, ключі доступу та інші чутливі токени з комп’ютерів усіх, хто встановив версії програм із «закладками» або в кого ПЗ оновилося автоматично й підхопило шкідливе оновлення.

Отримані в такий спосіб облікові дані використовувалися для подальшого розповсюдження атак й відкривали шлях до «каскадних» зламів великих компаній, які покладаються на вразливе ПЗ. Серед них — AI-гігант OpenAI і хостинг-платформа Vercel. Нові інциденти відбуваються майже щотижня, і світ open source залишається однією з найуразливіших ланок у ширшій техноекосистемі.

Злам системи стеження ФБР став «серйозним кіберінцидентом»

Федеральне бюро розслідувань США в квітні було змушене оголосити про «серйозний кіберінцидент», що, згідно із законом, потребувало офіційного повідомлення Конгресу. Причина — виявлення компрометації однієї з його систем нагляду. За повідомленнями, під загрозою опинилися телефонні номери людей, які перебували під стеженням федеральних агентів.

У зламі не класифікованої мережі, яка зберігала чутливу інформацію про цілі прослуховувань та інших перехоплень зв’язку (зокрема, дані pen register), підозрюють китайських шпигунів. Оскільки Бюро повідомило про інцидент законодавцям, він, імовірно, досяг порогу «відчутної шкоди» для нацбезпеки США.

Hasbro тижнями не могла відновити роботу після атаки

Історія з іграшковим гігантом Hasbro — черговий приклад того, що трапляється, коли велику корпорацію вражає кіберінцидент, до якого вона виявляється неготовою. Минуло кілька тижнів відтоді, як наприкінці березня в її системах виявили хакерів, а 103-річна компанія все ще значною мірою залишалася офлайн: її сайт був недоступним, а клієнти — без сервісу.

Компанія, яка володіє такими брендами, як Transformers, Peppa Pig і Dungeons & Dragons, майже нічого не розповіла про сам інцидент: які саме дані (якщо взагалі) було викрадено й чи платила вона викуп. Втім, навіть один лише тривалий простій, імовірно, боляче вдарить по фінансових показниках — їхній публічний реліз довелося відкласти через те, що компанія кинула всі ресурси на ліквідацію наслідків атаки.

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

Мільйони паспортів і водійських посвідчень опинилися у відкритому доступі

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

Ці масштабні витоки відбуваються на тлі того, як дедалі більше закритих спільнот і сервісів в інтернеті запроваджують процедури «знай свого клієнта» (KYC), змушуючи користувачів підтверджувати особу для доступу до платформи, а уряди просувають закони про перевірку віку, що також передбачають звірку документів дорослих для допуску до великих сегментів мережі.

Джерело

TechCrunch

Провідний репортер і «домашній» експерт з батарей TechCrunch Тім Де Чант відвідав величезний технічний центр General Motors у Воррені поблизу Детройта, щоб дізнатися більше про плани автовиробника здешевити наступне покоління своїх електромобілів. Висновок: GM робить ставку на батареї LMR і новий центр розробки акумуляторних елементів, який розглядають як міст між R&D і повномасштабним виробництвом.

Курт Келті, віцепрезидент GM з питань батарей і сталого розвитку, розповів нові деталі про ініціативу компанії вартістю $900 млн і про те, як нова хімія дасть змогу зберегти запас ходу, водночас суттєво знизивши собівартість. Наприклад, Chevrolet Silverado EV може подешевшати приблизно на $6 000.

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

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

Авторка також раніше писала про Ferrari Luce EV і про те, чому шквал критики навколо цієї моделі мало що змінює. Читачі надсилали відгуки на цю тему, однак опитування показало: попри велику увагу в медіа, більшість аудиторії майже не цікавиться Luce.

На запитання «Подобається, не подобається чи байдуже?» приблизно 44% відповіли, що їм байдуже, а решта рівномірно розділилися між «люблю» та «ненавиджу».

Авторка припускає, що в майбутньому Luce EV може стати своєрідною «покупкою заради хайпу» для заможних клієнтів, яких Ferrari вважатиме «достойними» отримати цю модель.

Угоди

Майбутнє IPO SpaceX уже називають угодою десятиліття — принаймні для інвестбанкірів і CEO Ілона Маска. Але воно може вплинути й на акціонерів Tesla.

У межах процесу реєстрації перед виходом на біржу компанії часто подають численні поправки до документів. SpaceX уже подала кілька таких змін до форми S‑1. Старший репортер TechCrunch Шон О’Кейн звернув увагу на нове формулювання, яке може мати великі наслідки: «Ми можемо випустити значний обсяг акцій у зв’язку з майбутніми транзакціями».

Хоча теоретично SpaceX може використати очікувані близько $75 млрд для купівлі різних компаній, найімовірнішою ціллю для M&A багато хто вважає саме Tesla. Це речення внесли до розділу «фактори ризику», і воно, схоже, має підготувати майбутніх інвесторів до потенційного суттєвого розмивання часток у разі великої угоди.

Ще одну цікаву угоду О’Кейн помітив у документах, пов’язаних із Carvana та Slate Auto — стартапом електромобілів, який підтримує Джефф Безос. Згідно з документами, отриманими TechCrunch, Carvana отримала опціон на інвестицію в Slate Auto. Це може свідчити про підготовку до глибшого партнерства між компаніями.

Інші угоди, на які звернули увагу:

• Layup Parts, стартап, що прагне стати «Amazon» для композитних деталей, залучив $42 млн у раунді Series A, який очолив фонд подвійного призначення Marlinspike. У раунді також взяли участь нові інвестори Cerberus Ventures та Pinegrove Venture Partners, а також чинні — Founders Fund і Lux Capital.
• Mach Industries, трирічний оборонний техстартап, який розробляє вже п’ять автономних платформ, залучив $300 млн у раунді Series C з оцінкою $1,8 млрд. Раунд очолили Infinite Capital і Ribbit Capital, також долучилися Bedrock Capital, Sequoia Capital і Khosla Ventures.
• Molfar Defence Technologies, польсько‑український оборонний стартап, що розробляє антидронові радарні системи, закрив перший транш раунду фінансування обсягом €2 млн. Як повідомляє Tech.Eu, шведський інвестор Front Ventures зобов’язався вкласти €1,5 млн.
• Spiro, африканський стартап в галузі електромобільності, залучив $215 млн у раунді, який наблизив оцінку компанії до $1 млрд, пише Bloomberg.

Помітні новини й інші подробиці

CEO Avride Дмитро Поліщук поділився кількома цифрами про стартап автономного транспорту в LinkedIn. Компанія виконала 60 000 поїздок для користувачів Uber у Далласі від моменту запуску в грудні. (Роботаксі Avride доступні в застосунку Uber у цьому місті.) Парк компанії, що включає тестові авто та роботаксі Uber, проїхав уже понад 1,3 млн миль, причому 1 млн із них — лише за перші п’ять місяців 2026 року.

Компанія Lectric eBikes запустила вже третій бренд за останні шість місяців — на це спрямовано близько $10 млн. Попри те, що багатьом гравцям ринку електровелосипедів довелося скоротитися або закритися, цей семирічний бізнес активно розширюється.

Щорічний індекс втрачених речей від Uber за останнє десятиліття перетворився на своєрідне антропологічне дослідження звичок пасажирів. Цього року компанія оприлюднила окремий список предметів, залишених у роботаксi, які можна викликати через застосунок Uber. Список доволі дивний і ще раз підкреслює, як Uber шукає нові способи вийти на зародковий ринок автономних авто й заробляти на ньому. Зокрема, Uber планує вивести на дороги 500 автомобілів‑збирачів даних цього року в межах нового підрозділу AV Labs.

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

Woven Capital, фонд зростання Toyota, підвищив Ярека Хойліана та Манаса Пунхані до партнерів‑принципалів. Нагадаємо, що Woven Capital запустив другий фонд обсягом $800 млн у вересні 2025 року.

Ще одна річ: оновлений Subaru Solterra

На тлі виходу нових електромобілів Subaru варто згадати, з чого все починалося. Йдеться про Solterra, створений у межах партнерства Toyota та Subaru для спільної розробки платформи під батарейні електромобілі.

Оглядачка провела тиждень із білим перламутровим Subaru Solterra 2026 модельного року у комплектації Premium, яка стартує від $38 495. Попри те, що камера Ring у подруги впізнала Solterra як «міні‑гольфкар», у цього EV є що запропонувати. Так, він доволі базовий. І так, він не стартує зі світлофора, як Tesla, Lucid чи Porsche Taycan. Але йому це й не потрібно.

Головне — Solterra справді став кращим, і це було необхідно.

Модель 2026 року отримала низку важливих оновлень, які покращили потужність, запас ходу та зручність використання.

Передній і задній електромотори оновили, разом із новим контролером, який поліпшує розподіл потужності та керованість. У сумі це дає 233 к.с. (у версії XT — до 388 к.с.). Як і більшість сучасних EV, Solterra тепер має інтегрований зарядний порт NACS — це система, розроблена Tesla. Запас ходу зріс до орієнтовних 288 миль за EPA, що показово, зважаючи, що ємність батареї збільшили лише на 2 кВт·год, а запас ходу — більш ніж на 50 миль. Додали й режим попереднього підігріву батареї перед заряджанням, що суттєво скорочує час зарядки.

Subaru оновила й мультимедійний блок: у салоні тепер 14‑дюймовий тачскрин із підтримкою Apple CarPlay та Android Auto, а також бездротові зарядні пристрої для смартфонів потужністю 15 Вт у базовій комплектації.

Водночас у Solterra немає повноцінного керування «однією педаллю» — функції, яка стала стандартом для багатьох електромобілів. Замість цього за кермом розташовані підрульові пелюстки, які дозволяють збільшувати рекуперативне гальмування, якщо водій цього хоче. Але авто не зупиняється повністю без натискання гальма, як це роблять інші популярні EV з режимом «однієї педалі». Досвідчених власників електрокарів це може розчарувати, зате для тих, хто переходить з ДВЗ‑авто, така поведінка машини може виявитися комфортнішою та звичною.

Джерело

TechCrunch

Так званий «супердодаток» OpenAI може нарешті вийти в користувачів, повідомляє The Financial Times. За даними видання, оновлений ChatGPT заохочуватиме людей не лише спілкуватися в чаті, а й активніше використовувати «інструменти для кодування, генерацію зображень та застосунки партнерів, зокрема Canva і Booking.com». Очікується, що перероблений ChatGPT почнуть запускати протягом найближчих тижнів, і спершу зміни з’являться у вебверсії та мобільних додатках.

Попри популярність чат-бота серед безплатних користувачів, OpenAI, за даними FT, хоче залучити більше корпоративних клієнтів за допомогою цього оновлення, яке робить акцент на виконанні різних завдань, а не лише на відповідях на запитання. Від редизайну очікують зростання доходів завдяки великим компаніям, які розгорнуть новий ChatGPT для всієї своєї команди. Це, своєю чергою, може підтримати плани OpenAI вийти на біржу вже у вересні цього року.

Крім того, OpenAI, ймовірно, намагається зберегти конкурентоспроможність щодо свого головного суперника — Anthropic, який також оголосив про намір провести первинне публічне розміщення акцій (IPO).

Джерело

Engadget

OpenAI планує впродовж найближчих тижнів запустити оновлену версію ChatGPT — у вигляді «супердодатка» з інструментами для програмування та AI-агентами, повідомляє Financial Times.

За даними видання, компанія прагне стати більш конкурентною з Anthropic, особливо в сегменті бізнес-клієнтів, а також наблизитися до прибутковості перед можливим IPO. Для цього ChatGPT мають перетворити на точку входу, яка вестиме безплатних користувачів до продуктів, за які вони потенційно платитимуть, наприклад до інструмента для розробників Codex. Financial Times цитує одного з топменеджерів OpenAI, який заявив: «Чат мертвий».

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

Якщо це звучить знайомо, то тому, що про плани OpenAI створити супердодаток повідомляли ще торік.

Джерело

TechCrunch

Польська студія Bloober Team анонсувала нову гру у всесвіті Star Trek, яка, ймовірно, розділить фанатів франшизи. Star Trek: Shadow Frontier описують як «дорослу психологічну action-adventure», і хоча розробники прямо не називають її грою жахів, за тизер-трейлером вона саме так і виглядає. Головну роль виконує Ро Ларен, відома за серіалом «Зоряний шлях: Наступне покоління», до образу повертається акторка Мішель Форбс.

За сюжетом Star Trek: Shadow Frontier Ро зазнає аварії на «далекій планеті, захопленій дивною свідомістю», яка змусить її зіткнутися з власним непростим минулим, намагаючись вижити. У описі гри зазначається: «Чим більше вона дізнається, тим глибше занурюється в спотворений лабіринт, де її спогади викривлюються, а планета загрожує обірвати зв’язок із реальністю. Лише розгадавши таємниці цього дивного світу, Ро зможе примиритися з демонами минулого, вирушаючи у серце пітьми, як ніколи раніше».

Джерело

Engadget

Microsoft без зволікань відкрила свою велику презентацію Summer Game Fest з Gears of War: E-Day. У новому трейлері показали мікс ігрового процесу та кат-сцен, трохи більше контексту щодо того, що сталося із Землею, а також дату виходу: 6 жовтня 2026 року. Схоже, не всі ігри Xbox тікають із дороги GTA VI.

Трейлер геймплею демонструє чимало жорстоких сутичок на близькій дистанції, кислотних монстрів і понівечену планету. E-Day, як випливає з назви, розгортається в день, коли Локус прийшли у наш світ. Ролик починається з ветерана серії Маркуса Фенікса у цілком «цивільному» вбранні й закінчується моментом, коли Фенікс зустрічає свого товариша Домініка Сантьяго, схоже, уперше.

Мабуть, найгучніша новина стосується того, чим E-Day не буде. У межах перегляду планів нова очільниця Xbox Аша Шарма оголосила, що гра більше не вийде на PlayStation 5. Натомість вона з’явиться на Xbox, ПК та в Xbox Cloud. Здавалося, це може запустити хвилю подібних розворотів, але трейлери Fable та Halo: Campaign Evolved, показані пізніше під час презентації, усе ще містили блискучий логотип PS5.

Джерело

Engadget

Halo: Campaign Evolved виходить на PlayStation 5, Xbox Series X/S та ПК 28 липня. Покупці Premium Edition та Collector’s Edition отримають ранній доступ із 23 липня — за пʼять днів до релізу. Гру також додадуть до підписки Xbox Game Pass і сервісів хмарного стримінгу.

Campaign Evolved — це ремейк у 4K сюжетної кампанії оригінальної Halo: Combat Evolved, яка вийшла у 2001 році та на роки вперед визначила шутерні амбіції бренду Xbox. Окрім візуальних покращень і додавання зброї та механік з наступних частин Halo, Campaign Evolved пропонує три нові бонусні місії. Саме цей новий сегмент — Operation: METEORITE — Microsoft і студія Halo Studios показали разом з анонсом дати виходу під час недільної презентації Xbox у рамках Summer Game Fest.

Operation: METEORITE — це сюжетна арка з трьох місій, дія якої відбувається за рік до подій Combat Evolved. У ній знову зʼявляються Мастер Чіф і сержант Джонсон, які вирушають на дослідницький корабель Ковенанту, щоб щось здобути й утекти, але план іде шкереберть. Operation: METEORITE додає до гри нові локації, варіації ворогів і класичну зброю з серії Halo.

Джерело

Engadget