Spring АйО

🍃 Hibernate тормозит, Java чинит конструкторы, 100% coverage — зло | Spring АйО Подкаст №73 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

🚀 Spring АйО запускает публичные mock-интервью Хотите проверить свои знания в разработке, потренироваться перед реальным собеседованием и понять, чего не хватает до следующего оффера? Друзья, мы запускаем публичные интервью с экспертами Spring АйО. Желающие могут его пройти и получить честную обратную связь с рекомендациями по дальнейшему развитию. Формат собеседования подберём вместе: • теоретические вопросы по Java, библиотекам и фреймворкам • code review • live coding • system design • алгоритмические задачи ❓ Как всё проходит: 1. Вы заполняете небольшую анкету. 2. Мы созваниваемся на 30 минут, знакомимся и обсуждаем детали. 3. Выбираем формат и удобную дату, время. 4. Проводим и записываем собеседование. 5. Вместе делаем ревью и готовим выпуск к публикации на площадках Spring АйО. ❗️ Уровень опыта не так важен. Гораздо важнее желание проверить себя, получить конструктивную обратную связь и поделиться этим опытом с сообществом. ✉️ Оставить заявку на участие Ждем на собес!

🔥 Завтра выходит Java 27! Главное: • Compact Object Headers включаются по умолчанию. Метаданные каждого объекта становятся компактнее, что может уменьшить потребление heap примерно на 20% и снизить нагрузку на GC. Раньше для этого требовался флаг -XX:+UseCompactObjectHeaders. • G1 становится сборщиком мусора по умолчанию во всех окружениях. Раньше JVM могла выбирать Serial GC на машинах и в контейнерах с небольшим количеством ресурсов. Поэтому после обновления стоит перепроверить память, паузы и CPU именно на маленьких инстансах. • JFR начинает автоматически скрывать чувствительные данные. Пароли, токены, API-ключи и секреты в аргументах JVM, переменных окружения и системных свойствах больше не должны случайно попадать в запись Flight Recorder. ⚠️ Но есть и изменения, способные сломать старые конфигурации Флаги -noverify и -Xverify:none окончательно удалены. -XX:InitiatingHeapOccupancyPercent переименован в -XX:G1IHOP, а JSON-дампы потоков получили новую версию формата и теперь записывают идентификаторы числами, а не строками. Java 27 не LTS, поэтому массовая миграция в продакшене вряд ли начнётся завтра. Но проверить сервисы и контейнеры уже стоит, так как часть оптимизаций включится автоматически, а старые JVM-флаги могут внезапно напомнить о себе. Редкий релиз, где отсутствие новых фич может уменьшить потребление памяти. 🔗 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1082138/

☄️ Вчера у наших друзей из Axelix вышел 1.1.0 релиз! Парни сфокусировались на том, чтобы Axelix Master соответствовал требованиям современных систем к мониторингу и безопасности. Подробности можно прочитать в Release Notes. Мы знаем, что среди участников Spring АйО довольно много контрибьютеров в ядро Axelix. Отдельный респект всем, кто контрибьютит!🧑‍💻 Это как раз возможность для тех кто давно хотел попробовать себя в Open Source, но никак не было возможности. Если вы давно хотели получить инструмент, который позволит вам заглянуть внутрь ваших Spring Boot приложений, то это инструмент для Вас! 👩‍💻 Исходный код 🔗 Документация Ну и конечно, ядро проекта Open Source, так что можно уже этим пользоваться уже сегодня

☕️ Java стала похожа на Rust. Кто-то явно пропустил несколько обновлений В X сравнили два фрагмента кода. Сверху современная Java, снизу Rust. Оба описывают температуру в Цельсиях и Фаренгейтах, разбирают варианты и обрабатывают результат преобразования строки в число. И если ваша Java до сих пор состоит из геттеров, сеттеров и бесконечных instanceof, верхняя половина картинки может удивить. В Java здесь работают вместе: ☑️ Records – чтобы описать данные без простыни служебного кода. ☑️ Sealed interface – чтобы ограничить набор допустимых вариантов. ☑️ Pattern matching в switch – чтобы сразу разобрать вариант и достать его содержимое. ☑️ Условия when – чтобы прямо в ветке проверить значение. В Rust похожая задача решается через enum и match. Синтаксис отличается, но ход мысли уже очень близкий - описали возможные состояния → явно обработали каждое. Правда, как в том анекдоте, есть нюанс. Оказанный в Java Result.of(...) – не стандартный аналог растовского Result. Его реализация на скриншоте не раскрыта. Так что принимать всю картинку за возможности Java из коробки не стоит. Но повод пересмотреть старые претензии к языку вполне есть. Шутки про многословную Java помнят все. А до records и pattern matching в собственном проекте добрались ещё не все. 👀 У вас современная Java уже в коде или пока только номер версии в сборке?

🔥 Java ускорила Ed25519 и X25519 почти на 50% 3 сентября 2026 команда Java опубликовала результаты оптимизаций криптографии в JDK 27/28. И цифры там весьма впечатляющие. В JDK 27 за счёт изменений реализации Curve25519 получили:

• X25519 key generation/agreement: +49–54% throughput • Ed25519 key generation/sign/verify: +46–49% • X25519MLKEM768, то есть hybrid post-quantum key exchange: +27–51%

Причём прикол в том, что разработчику для этого не нужно переписывать код. Ускорение получают обычные JCE API – KeyAgreement, Signature, KeyPairGenerator – и JSSE при TLS 1.3. А в JDK 28 они пошли дальше и добавили intrinsics для x86_64 и AArch64. JVM начинает использовать архитектурно-оптимизированные инструкции. Это даёт ещё примерно до +20% поверх программных оптимизаций в зависимости от алгоритма и архитектуры.

Java ускорила популярную криптографию почти в полтора раза. Просто обновлением JDK. Без нового API. Без изменения кода. Без новой зависимости.

И это не сторонний бенчмарк, ведь цифры опубликовала сама команда Java на Inside java 3 сентября. 🔗 Официальный материал Inside Java

☕️ Java, Valhalla и AI-агенты — встречаемся на митапе! Наши друзья из Axiom собирают Java Рок Стар Митап при поддержке Spring АйО. Будут два доклада и время на разговоры с Java-комьюнити. ☑️ Иван Углянский — про проект Valhalla и value-типы в Java.

Зачем они нужны, почему работа над ними растянулась на годы и какой новый подход приблизил проект к реализации. Заглянем под капот JVM и разберёмся, в каких задачах пригодятся value-классы.

☑️ Максим Козлов, CTO и сооснователь GitFlic, — про разработку с AI-агентами.

Агенты ускоряют работу, но как проверить, что в итоге получилось именно то, что требовалось? Поговорим о связи требований, изменений в коде и поведения системы, а также об обратной связи, которая помогает сохранять контроль над разработкой.

📅 18 сентября — сбор с 18:00, доклады с 19:00 📍 Москва, лофт Casa Picassa, Бауманская, 11, стр. 8, зал «Кандинский» Встреча пройдёт офлайн, после неё организаторы обещают записи выступлений. Участие бесплатное, нужна предварительная регистрация. 👉 Программа и регистрация

👩‍💻 Spring Data JDBC: укрощение строптивого Каждый Java разработчик в том или ином виде сталкивается с проблемой выбора инструментария для работы с БД. Если говорить про ORM-ы, то выбор у нас невелик: Spring Data JDBC или Hibernate. И тут часто возникает набор вопросов: - Когда выбирать Hibernate, а когда Spring Data JDBC? - Как дизайнить Aggregate-ы в Spring Data JDBC? - Что из DDD просто теория, а что реально важно на практике? и т.д. Мы оцифровали доклад Михаила Поливаха с прошедшего Spring I/O Barcelona. В докладе обсуждаются все эти и многие другие вопросы, с которыми часто сталкиваются люди при проектировании доменной модели в целом. Будет полезно, если присматриваетесь к Spring Data JDBC или уже используете его и накопили вопросы. ⚠️ А если хочется глубже погрузиться в разработку реальных приложений, у нас в Академии скоро стартует новый поток «Java в продакшене». 🔗 Статья 😉 Ссылка на доклад (на английском) 🔗 Курс «Java в продакшене»

👩‍💻 Линус Торвальдс пофиксил баг в ядре Linux при помощи ИИ После полного выключения и включения компьютера Linux показывал чёрный экран. Графическая оболочка постоянно перезапускалась, хотя сама система продолжала работать. Лечилось перезапуском оболочки. Фиксом занялся сам Линус Торвальдс. И в помощники он взял себе AI. Сама причина находилась в драйвере Intel Xe и расчёте границы видеопамяти. Часть VRAM видеокарта резервирует для служебных данных аппаратного сжатия. Драйвер получает адрес, с которого начинается эта закрытая область, и передаёт всю память ниже него обычным приложениям. Но адрес не всегда совпадал с границей страницы памяти. Легаси код использовал round_up() – округлял адрес вверх. Из-за этого граница свободной памяти сдвигалась внутрь зарезервированной области. На компьютере Линуса граница проходила посередине страницы размером 4 КБ: последние 2 КБ уже принадлежали механизму сжатия, но драйвер мог отдать всю страницу приложению. По итогу видеокарта записывала служебные данные поверх размещённой там таблицы страниц. Графическая оболочка теряла доступ к нужной области памяти и падала. Исправлением послужила замена round_up() на round_down(). Теперь адрес округляется вниз до начала страницы. Если хотя бы часть страницы занята служебными данными видеокарты, драйвер исключает из доступной памяти всю страницу. Теряется несколько килобайт VRAM, зато приложения больше не получают память, которую может перезаписать оборудование. Само исправление уместилось всего в одну строку. Но для его поиска потребовались 24 диагностических патча и 18 перезагрузок ядра. AI по сути занялся основной рутиной. Он добавлял различный диагностический код и анализировал результаты. Правда, несколько раз помощник объявлял проблему нерешаемой и предлагал остановиться на составлении отчёта 😅 . Как говорится, "лень прежде нас родилась". Но Линус был упрямее и каждый раз заставлял его продолжать. В конце Торвальдс признал, что AI оказал огромную помощь, и даже разрешил ему написать описание итогового коммита. Какую модель он использовал, Линус не сообщил. Мораль сей басни такова, что AI не нашёл ошибку одной волшебной командой и не заменил инженера (выдыхаем). Он выполнял механическую работу, пока человек строил гипотезы, проверял результаты и не принимал ответ, якобы это невозможно. ⚡Михаил Поливаха обещал обсудить баг на подкасте более детально. Ждем! 🔗 Источник: коммит в ядре Linux

100% покрытия. Все тесты зелёные. Значит, код надёжен? Не совсем. Можно выполнить каждую строку программы и всё равно пропустить важный сценарий. Например, проверить a > b и a < b, но забыть про a == b. Мутационное тестирование предлагает дерзкий способ оценить качество тестов: намеренно ломает код. Меняет > на >=, true на false, возвращаемое значение на null. Если тесты не замечают подмены, значит, «мутант» выжил, а в тестовом наборе есть слепая зона. Звучит как идеальный инструмент. Но на реальном проекте быстро появляются нюансы. Например, ложные срабатывания, долгие запуски и отчёты, которые всё равно приходится разбирать человеку. В новой статье на простом Java-примере показываем: – как работает мутационное тестирование с Pitest; – почему 100% покрытия недостаточно; – откуда берутся выжившие мутанты; – почему не стоит прогонять MT по всему проекту; – и в каких случаях этот подход действительно окупается. А ещё как поручить настройку и запуск Pitest AI-агенту с помощью готового skill. Мутационное тестирование само по себе не является серебряной пулей. Но иногда именно оно задаёт вашим тестам самый неприятный и самый полезный вопрос: «А вы точно хоть что-нибудь проверяете?» 🔗 Читать статью: https://habr.com/ru/companies/spring_aio/articles/1078564/

🦉 Один поток закончился. Следующий уже в продакшене! Во-первых, всех с началом учебного года. А во-вторых, давайте учиться. Весной мы провели первый поток Spring АйО Академии «Продвинутый Hibernate». И, судя по обратной связи, попали точно в цель. Мы собрали от участников отзывы. Ознакомиться с ними можно на главной странице Академии. Поэтому продолжаем. Открываем набор на новую осеннюю программу «Java в продакшене». Эта программа для Java- и Spring-разработчиков, которым уже мало просто написать работающий сервис. Пора разобраться, как он будет вести себя под реальной нагрузкой, во время сбоев и на релизах.

За 6 лекций разберём: — Circuit Breaking, Bulkhead и Load Shedding; — таймауты, ретраи, backoff + jitter и идемпотентность; — метрики, трассировку и логи с OpenTelemetry; — Blue/Green, Canary и релизы без простоя; — Vault, ротацию и защиту секретов; — эволюцию API без поломки клиентов.

В программе 12 часов живых занятий с Михаилом Поливаха, домашние задания с разбором, общение в закрытой группе и доступ к материалам на 90 дней. Если вы движетесь к уровню Senior/Staff, отвечаете за SLA и релизы или дежурите on-call, то у нас мэтч. 🔗 Посмотреть программу и записаться 🙃 Ну потому что works on my machine для серьёзных систем уже недостаточно

🍃 Apple хоронит Intel, Java получает JSON, зачем нам GraalVM | Spring АйО Подкаст №72 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE 🗯 Чуть позже... 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

🥇 Лучшие практики управления конфигурацией в Spring Boot Конфигурация Spring Boot приложений гораздо более сложная, чем может показаться на первый взгляд. Spring Framework позволяет потреблять конфигурацию из разных источников: - System Properties - Переменные окружения процесса ОС - Java Properties / YAML файлы и т.д. Как следствие сложно понять итоговое значение, а ошибка всплывает уже в работе. Кроме того, помимо потребления конфигурации, Spring Boot в частности позволяет получать свойства конфигурации разными способами: - @Value - @ConfigurationProperties - Environment / PropertySource-ы и т.д. Всё это способно создать небольшую кашу в голове. В новом переводе, мы вместе постараемся внести небольшую ясность в этот процесс. 🔗 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1076862/

Anthropic опубликовали AI-Native SDLC плейбук Его основная мысль: агенты уже способны генерировать код намного быстрее человека, но окружающие процессы почти не изменились. Планирование, согласования, тестирование, проверка безопасности и выпуск по-прежнему работают с человеческой скоростью. Узкое место просто переместилось из написания кода в соседние этапы. Anthropic называет предлагаемую модель AI-native SDLC. Привычный линейный процесс превращается в замкнутый цикл, внутри которого каждый этап создает версионируемый артефакт для следующего: intent.md -> spec.md -> plan.md -> код и тесты -> PR с результатами проверок -> отчет об инциденте или новый intent.md Все это хранится в Git. История коммитов одновременно становится журналом изменений: кто сформулировал задачу, что предложил агент, какие решения принял человек и что в итоге попало в продакшен. Как выглядит сам процесс? На этапе планирования автор идеи обсуждает проблему с Claude. Результат фиксируется в intent.md: что требуется изменить, зачем, какие системы затрагиваются и какие ограничения нужно учитывать. Владелец продукта проверяет документ и принимает решение о продолжении работы. Дальше агент превращает намерение в spec.md с требованиями и проектным решением. Политики безопасности, архитектурные правила и требования к интерфейсу подключаются через Skills. Спорные места агент должен явно отметить, а человек - разрешить до начала реализации. Разработка начинается с plan.md. В нем перечисляются изменяемые файлы, порядок работы, риски и проверки результата. После утверждения плана агент пишет код. Контекст проекта хранится в CLAUDE.md, повторяемые правила оформляются как Skills, а обязательные ограничения обеспечиваются через hooks. Для тестирования предлагается два уровня. Первый - обычные сборка, линтеры и автоматические тесты, которые агент обязан запустить перед завершением задачи. Второй - evals для проверки самого агента. Если команда меняет модель, системные инструкции, Skills или hooks, набор реальных задач должен показать, что качество работы не ухудшилось. Во время развертывания агент проверяет PR, исправляет замечания и готовит релиз. Человек оценивает соответствие исходному замыслу и уровень риска. Критические действия, включая выпуск в продакшен, защищаются программными ограничениями и явными согласованиями. Эксплуатация замыкает цикл. Детерминированный мониторинг обнаруживает выход метрик за допустимые границы, после чего агент подключается к диагностике. Небольшая проблема может закончиться PR или откатом. Более крупная превращается в новый intent.md и снова проходит весь процесс. Роль инженера в такой модели заметно меняется. Больше внимания уходит на формулирование намерения, проектирование ограничений, проверку артефактов и оценку риска. Стабильность процесса обеспечивают тесты, CI, изоляция, права доступа и автоматические шлюзы. Плейбук сильно привязан к Claude Code и продуктам Anthropic, однако сама схема применима шире. Главная идея заключается в перестройке всего процесса разработки вокруг работы агентов, а не в добавлении генерации кода в одну из существующих стадий. Плейбук в блоге Anthropic: https://claude.com/blog/the-ai-native-sdlc-playbook Какой подход при разработке с ИИ-агентами используете вы в рабочих проектах? Пишите в комментариях 😎

🖥 Ваш JSONB тормозит не из-за базы. Возможно, виноват Hibernate Когда Hibernate начинает проседать по производительности, первым делом обычно ищут лишние SQL-запросы. Тем не менее, с JSON или JSONB проблема может скрываться совсем в другом месте. Hibernate способен незаметно выполнять дорогую работу с JSON-объектами, даже когда вы этого не ожидаете. На небольших объёмах это почти не видно, а под нагрузкой превращается в серьёзный bottleneck. Хорошая новость состоит в том, что часто проблема решается довольно просто, и хватает всего пары аннотаций, чтобы сократить время обработки почти вдвое. 🔗 Что именно происходило и как это исправить: https://habr.com/ru/companies/spring_aio/articles/1075156/

Спека вместо кода: OpenSpec vs SpecKit Сколько строк сгенерированного кода вы реально прочитали за последнюю неделю? Вопрос неудобный, и именно из него растёт spec-driven development: описываем намерение явно, до генерации, и агент работает по спеке, а не по вашей интуиции. Новая статья на Хабре — сравнение OpenSpec и SpecKit: два взгляда на один процесс, разные компромиссы между простотой и контролем качества. Ну и конечно же: как OpenIDE Pro помогает работать со спеками на практике? 👉 Читаем тут

👩‍💻 В Java хотят дать возможность запретить читать поле до того, как ему присвоили значение Дело в том, что, когда создаётся объект, его поля сначала получают значения по умолчанию (null для ссылок, 0 для чисел, false для boolean) и только затем выполняется код инициализации. По итогу на уровне JVM существует короткий промежуток времени, когда поле уже можно прочитать, хотя ему ещё не присвоили настоящее значение. Давайте рассмотрим вот такой пример:

class Parent {
    Parent() {
        // Вызов попадёт в переопределённый метод Child (dynamic dispatch),
        // хотя конструктор Child ещё не закончил выполняться!
        printValue();
    }

    void printValue() {}
}

class Child extends Parent {
    private final int value;

    Child() {
        // Неявный super() уже был вызван, и только после него полю "value" присвоится 42.
        this.value = 42;
    }

    @Override
    void printValue() {
        // Пока выполняется Parent(), здесь всё ещё значение по умолчанию - печатается 0, а не 42
        System.out.println(value);
    }
}

И вот OpenJDK хочет сделать шаг на пути исправления этой проблемы. В рамках JEP 539 завозят новый механизм "строгих полей" (strict fields). Их поведение будет немного отличаться в зависимости от того, static поле или нет, но цель одна - не допустить ситуации выше. Например, если пометить value поле выше как strict (сейчас вы это никак не сделаете), то при загрузке класса будет VerifyError, т.к. строгие поля объектов необходимо присвоить до вызова super(). То есть Parent() уже не сможет вызвать printValue() и увидеть промежуточный 0: JVM отклонит некорректный байткод ещё при его проверке. Зачем вообще нечто подобное делать? В основном ради Project Valhalla и концепции "Integrity By Default", о которой мы уже писали. Java движется к value classes, а для них состояние объекта должно иметь гораздо более строгие гарантии. С точки зрения пользователя, Value классы нужны в основном для скаляризации (Вспоминаем девиз: "codes like a 'class', works like an 'int'"). А для того, чтобы JIT мог эффективно скаляризировать классы, он должен быть абсолютно уверен, что наблюдаемое им состояние объекта единственно верное, и остальные наблюдают его ровно таким же. Проблема в том, что даже для final полей в Java это не так. С одной стороны из-за проблемы выше, а с другой из-за того, что final на самом деле не совсем final. Соответственно, примерно через полгода мы уже, скорее всего, увидим эту фичу в preview. Подробнее можно почитать в самом JEP. ⚠️ Важно! Механизм строгих полей это opt-in механизм, который пока, по умолчанию, будет касаться только value классов. Существующий код механизм "строгих полей" пока не касается!. 🔗 JEP 539: https://openjdk.org/jeps/539

Вам доклады по Go или Java? VK приглашает на митап с двойной начинкой 26 августа VK собирает Go- и Java-инженеров, чтобы прокачать знания. В программе два трека — Go и Java, по три доклада в каждом. Трек Go: • «Компиляция Go в динамическую либу, или как мы ускорили выкатку фичи в два раза, но нам не понравилось», Михаил Кичигин, бэкенд-разработчик, Avito Tech • «Go-платформа VK: как мы построили единую основу для создания Go-сервисов», Александр Апанасенко, руководитель команды SDK Backend, VK • «Почтальон от Kubernetes до Palo Alto. Как осуществляется доставка информации об адресах», Дарья Кулькина, бэкенд-разработчик, Точка Банк Трек Java: • «Перформанс-трюки в поисковой платформе Ozon», Пётр Портнов, ведущий разработчик среднего поиска, Ozon • «Архитектура современного движка платёжной системы и переход к новой архитектуре», Игорь Крикунов, технический лидер разработки DBC, Альфа-Банк • «Переход от федерации S3-кластеров в пользу коммунального и мультитенантного кластера», Кирилл Боблак, ведущий разработчик One-cloud, VK А ещё будет мастер-класс по прокачке навыка, который сделает вас звездой любого вечера, и афтепати, чтобы обсудить доклады в неформальной обстановке. Встречаемся в 17:00, начало в 18:00. Участие бесплатное, регистрация обязательна.

🍃 ИИ придумал уязвимости, IDE всё ещё нужна, Spring Boot vs Quarkus | Spring АйО Подкаст №71 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE 🗯 Чуть позже... 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

Вам доклады по Go или Java? VK приглашает на митап с двойной начинкой 26 августа VK собирает Go- и Java-инженеров, чтобы прокачать знания. В программе два трека — Go и Java, по три доклада в каждом. Трек Go: • «Компиляция Go в динамическую либу, или как мы ускорили выкатку фичи в два раза, но нам не понравилось», Михаил Кичигин, бэкенд-разработчик, Avito Tech • «Go-платформа VK: как мы построили единую основу для создания Go-сервисов», Александр Апанасенко, руководитель команды SDK Backend, VK • «Почтальон от Kubernetes до Palo Alto. Как осуществляется доставка информации об адресах», Дарья Кулькина, бэкенд-разработчик, Точка Банк Трек Java: • «Перформанс-трюки в поисковой платформе Ozon», Пётр Портнов, ведущий разработчик среднего поиска, Ozon • «Архитектура современного движка платёжной системы и переход к новой архитектуре», Игорь Крикунов, технический лидер разработки DBC, Альфа-Банк • «Переход от федерации S3-кластеров в пользу коммунального и мультитенантного кластера», Кирилл Боблак, ведущий разработчик One-cloud, VK А ещё будет мастер-класс по прокачке навыка, который сделает вас звездой любого вечера, и афтепати, чтобы обсудить доклады в неформальной обстановке. Встречаемся в 17:00, начало в 18:00. Участие бесплатное, регистрация обязательна.