Доклады

ORM, QueryBuilder'ы и прочие абстракции связывают руки при попытке использовать БД на полную катушку. Какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции?

В докладе я расскажу, как мы в Happy Inc. прошли путь от Doctrine ORM через DBAL и кастомный QueryBuilder до нативных запросов в чистом виде, и объясню, почему это во всех смыслах выгодное архитектурное решение.

Также я представлю нашу open-source-библиотеку Thesis, которая позволяет без боли оформлять SQL-запросы, на лету внедрять параметры любых типов и играючи работать с резалт-сетом.

Расскажу, как продвигается работа над JIT и какие другие идеи, направленные на повышение производительности, были реализованы в PHP 8.0 и готовятся в PHP 8.1.

Как же иногда хочется получить побыстрее новые возможности в языке — неизменяемые объекты, дженерики, перегрузку операторов и многое-многое другое. Думаю, вам всем знакомо это чувство ожидания выхода новой версии PHP, чтобы попробовать что-то новое, сделать лучше свой код. К сожалению, такие изменения появляются не очень быстро.

А что же делать, если очень хочется или очень нужно?

В этом докладе мы заглянем под капот самого PHP, поймем, какие у нас есть возможности и далее научимся писать свои расширения на обычном PHP. Иммутабельность — пару минут! Перегрузка операторов — проще простого!

При проектировании архитектуры высоконагруженных приложений ключевой проблемой является балансировка нагрузки между устройствами хранения данных. Важно найти компромисс между объемом хранилища, скоростью доступа и стоимостью хранения данных. Как известно из универсального принципа Парето, 80% запросов приходятся на 20% данных, и задача состоит в том, чтобы выявить эти 20% данных и разместить их в быстрой памяти с использованием систем кэширования.

Кэш — это не единое хранилище, а множество различных уровней на всем пути следования информации от первоисточника до браузера пользователя. Вы можете разместить кэш на диске и в памяти, на сервере, в сети (прокси) и в браузере, а затем использовать данные локально и распределённо. В итоге вы получаете сложнейшую распределенную архитектуру, в процессе управления которой необходимо решать нетривиальные задачи обеспечения согласованности кэшей и их инвалидации в комплексе с различными проблемами распределенных параллельных вычислений.

Хотя задача кэширования выглядит на первый взгляд довольно простой и прямолинейной, в процессе ее решения вас ожидают подводные камни и поиски компромиссов. В кэшировании, как, впрочем, и в любой задаче проектирования высоконагруженных систем, нет "серебряной пули", а есть набор отработанных техник. И вам остается лишь подобрать комбинацию техник для вашей задачи, используя их достоинства и нивелируя недостатки.

В докладе не затрагиваются вопросы использования конкретной программной реализации системы кэширования (Redis, Memcached, ...) и конкретных библиотек для взаимодействия с кэшем. Доклад сосредоточен на рассмотрении техник серверного кэширования в оперативной памяти.

Мы почти превратили наш "молодой динамично развивающийся проект" в big ball of mud.
Нам нужно было организовать процесс общения между оператором и клиентом. Сначала у нас был виджет, который просто транслировал e-mail-переписку, потом мы добавили whatsapp, смс, пуши, звонки, другие мессенджеры... И столкнулись с классикой: тяжело добавлять новые фичи, тяжело тестировать, много багов.
Я расскажу, как мы героически из этого выкарабкивались — что планировали, что менялось и что получили почти год спустя на проде:
* Почему не стали ничего выносить, инкапсулируя сервисы и сохраняя их границы в монорепе.
* Распил монолита по принципам пакетного дизайна. Примеры из реального проекта на PHP. От каких болячек избавились и какие приобрели.
* Как добиться, чтобы все сервисы жили в одной базе и не ругались. С какими проблемами столкнулись.
* Что мы будем делать дальше? Немного о планах по выделению пакетов в микросервисы.

Микросервисная архитектура постепенно завоевывает мир. Но она также добавляет множество проблем, которых не было в монолитных приложениях.

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

- Зачем нужны системы оркестрации?
- О Temporal.IO (Candence, AWS SWF).
- Интеграция Temporal с RoadRunner и миром PHP.
- Обработка ошибок в распределенных приложениях.

Разберём принципы, позволяющие писать код, который ломается меньше:
- композиция и как её форсировать;
- private по умолчанию;
- именованные конструкторы;
- состояние и иммутабельность;
- цепочки вызовов;
- зависимости и их инъекция;
- flow внутри метода, цикломатическая сложность;
- исключения: как ловить, ловить ли. Что нужно делать исключениями, а что не стоит;
- value object;
- DTO;
- типизация;
- сервисы, их зависимости и состояние;
- как писать, чтобы работало под RoadRunner / Swoole;
- как всё это тестировать;
- CQS;
- слои и абстракция.

Замечали ли вы, что public/private/protected недостаточно для инкапсуляции? Хочется описывать более сложные отношения, например: "вот этот метод — он, конечно, public, но он конвертирует id'шники из представления базы в бизнес-логику, поэтому дёргать его только из ORM, окей?". Или — "эта функция вызывается 500 раз на запрос, давайте она не будет вызывать медленное логирование".

У нас в ВК полно таких кейсов в гигантском монолите. Временами кто-то да и отправит в продакшн код, который вызывает базу в цикле из server-side rendering'а — неспециально, так просто получилось, потому что эти вызовы на 10 слоёв вложены и не видны при ревью.

Мы придумали паттерн, чтобы описывать такие отношения. Чем-то похоже на deptrac, но гибче: мы отслеживаем произвольный уровень вложенности (а не только прямые вызовы), мы умеем описывать исключения, плюс мы не используем регулярки по именам классов, а пишем всё в аннотациях. Рантайм-оверхед нулевой, т.к. всё отслеживается во время анализа (в случае KPHP — компиляции). Можно описывать модульность и internal-функции.

Расскажу про концепцию, про аналогию call graph'ов и CSS, про алгоритм реализации на 200к функциях, а также — как попробовать, если понравится.

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

Список тезисов:
- От простого к сложному: посмотрим на решение «в лоб» и эволюционируем его в базовый шаблон. Поймем, зачем нужен каждый архитектурный слой.
- Где документация? Или как забыть про этот вопрос.
- Что делать, чтобы проект не испытывал проблем, когда интеграция начинает долго отвечать. Какие стратегии защиты мы используем в Юле.
- Как понять, что клиент живой, и какую информацию стоит собирать при создании новой интеграции.

Мы любим чудо-штуки и поиск серебряной пули. Мы накручиваем десятки инженерных систем, сотни компонентов и тысячи вендорных зависимостей, формируя големоподобные системы для решения повседневных задач по борьбе с высокими нагрузками. Как только это происходит, есть 2 пути.

Первый: пойти вперед и начать делить систему, выделяя под каждую задачу вполне целевые инструменты. У нас появляются кафки, кубы, колоночные бд, шардирование, балансировщики и т.д. и т.п.

Второй: пойти назад. Посмотреть в зеркало заднего вида, разобрать свою систему, пристально посмотреть на практики, которые могут негативно влиять на производительность проекта, и расширить инженерный фундамент прежде, чем строить на нём сложные конфигурации для решения простых задач.

Пройдемся по основным точкам появления бутылочных горлышек на примере PHP.

Однажды, еще до работы в Badoo, мне предложили сделать пет-проект. Идея была находить похожие фотографии — после кропа, ресайза, наложения ватермарков — в базе из десятков миллионов. При этом обрабатывать предстояло 150 тысяч фотографий в сутки. До этого я занимался только несложными ресурсами на PHP + MySQL. Казалось, сделать поиск было нереально, но я был молод и полон энтузиазма.

В итоге все оказалось не так плохо. Шаг за шагом выяснилось, что для успеха было достаточно вузовских алгоритмов и свободного времени в течение года. В докладе я расскажу, как прошел путь от прочитанной на Хабре статьи до работающего гибридного PHP-кластера, и как этот неожиданный опыт помог мне устроиться в компанию, где я сейчас и работаю.

На мастер-классе будет представлен доклад об основных (известных и очень известных) угрозах информационной безопасности в веб-приложениях. Чтобы не растекаться мыслью по древу, мы изучим каждый из разделов на практике и разберем несколько реальных задач. Вы узнаете, на что необходимо обращать внимание при тестировании и реализации различной функциональности в веб-приложениях и что может произойти в случае несвоевременного использования тех или иных функций.

Почему prepared statements только усложняют код, а возможность внедрения JavaScript-кода на сайте не является багом? В ходе практического мастер-класса вы узнаете ответы на все перечисленные вопросы. На практике попробуем накрутить лайков в социальных сетях, украдем криптовалюту и получим доступ к самым большим секретам пользователей. Более того, вы узнаете, что нужно делать, чтобы не допустить подобных случаев в вашем веб-приложении.

В программе:
* Современные угрозы: от забытых файлов до проблем с аутентификацией.
* Сценарии защиты: что необходимо учитывать на этапе разработки веб-приложения, какие существуют фундаментальные принципы безопасности веб-приложений.
* 20/80: теория и дальнейший разбор на конкретных примерах и решение множества задач на практике.
* В рамках воркшопа будет рассмотрено 9-10 лабораторных работ.

Чтобы лучше понимать, как защищать приложения, нужно иметь представление о том, как их атаковать.

В докладе я расскажу про некоторые уязвимости, специфичные для приложений на PHP, такие, как type juggling, insecure deserialization и local file include. Рассмотрим все уязвимости на примерах, покажу, как их эксплуатировать.

В своем докладе я расскажу про то, как писать юнит-тесты, а в частности:
* техники тест-дизайна;
* техники написания тестов;
* о суровой реальности, которая не дает нам писать красивые тесты.

Иногда при разработке на PHP требуется использовать не только PHP. Зачем? Аннотации, DQL, Yaml, JSON5, С headers (FFI), GraphQL или какое-то своё решение — всё это задачи довольно узконаправленные, но когда потребуется реализовать что-то подобное, то придётся изучить множество литературы для банального понимания, как решать подобные задачи. Более того: даже банальные (ха-ха) задачи реализации статического анализа требуют полного разбора исходного кода и понимания его Control Flow!

В этом докладе мы ознакомимся с тем, как ~~упороться~~ (зачёркнуто) работают парсеры, из чего они состоят, почему синтаксис PHP именно такой, какой есть, и, возможно, придём к пониманию того, как работают языки программирования (в том числе и сам PHP).

Если вы задумывались о версионировании API, то наверняка вы сталкивались с целым рядом вопросов и проблем:
1. Какие варианты реализаций версионирования API известны? Какие у них достоинства и недостатки?
2. Как переиспользовать код в разных версиях?
3. Как поддерживать актуальность документации для всех версий?
4. Как тестировать разные версии API? Как справиться с ростом тестов после каждой новой версии?

В своем докладе мы расскажем, как эти задачи решила наша команда:
* какой способ версионирования реализовали мы;
* как нам удалось почти целиком избавиться от влияния версий на кодовую базу API;
* как мы документируем наши версии;
* как мы тестируем наши версии, и как мы научились определять и "схлопывать" идентичные для разных версий тесты.

На примере .env files support-плагина будет описана внутренняя архитектура среды IDEA(PhpStorm), как плагины взаимодействуют друг с другом. Как минимум пару раз докладчик выразит своё восхищение простотой и мощью данной архитектуры. Вероятно, кто-то из слушателей после конференции быстро накидает плагин для использования внутри проекта, а то и общего назначения.

Автоматические тесты помогают нам быть уверенными, что код работает и будет работать, как ожидается. И одной из метрик автоматического тестирования является Code Coverage — процент покрытия кода.

Но насколько хорош этот показатель? Можем ли мы ему доверять и имеет ли он хоть какой-то практический смысл?

Насколько вы сами уверены в своих тестах? Покрывают ли они все ветки выполнения кода?

Данный доклад отвечает на все эти вопросы и знакомит с методологией Мутационного Тестирования, описывает, как она может быть использована в повседневной работе и как контролировать качество тестов программно.

Здесь рассматриваются проблемы показателя Code Coverage, каким образом они решаются с помощью Мутационного Тестирования, а также описывается фреймворк для Мутационного Тестирования в PHP — Infection.

- Разработка приложений по долгоживущей модели, используя RoadRunner;
- Гибридная диспетчеризация, используя Golang-сервер и PHP-консьюмеры;
- Изоляция пользовательского контекста;
- Обзор экосистемы.

Вас только что наняли в проект, которому 5+ лет, чтобы добавлять новые фичи и фиксить баги, вам все нравится, но вы открываете ide и понимаете — это легаси и с ним невозможно работать: нет архитектуры, разделений на слои, а когда вы что-то где-то меняете, ломается в другом месте.

Последнее время я работал только с легаси-проектами. И у меня накопилось много опыта: как успешных практик, так и фейлов, которыми бы я хотел поделиться.

В докладе мы обсудим:
- Почему работа с legacy может быть увлекательной.
- Стратегии работы с легаси: и так сойдет vs переписать полностью vs постепенное улучшение.
- Как улучшить проект, не переписывая всё с нуля.

1. Классический PHP — "рожденный, чтобы умереть". Почему проекты хорошо масштабируются, но медленно работают.
2. А давайте сделаем "как в Node.js"? Асинхронщина в проектах React / Amp.
3. Надо делать не как у всех, а как лучше! Новые фреймворки Swoole, RoadRunner, Workerman.
4. Особенности кода, плюсы и минусы, быстродействие в типичных кейсах.
5. Новые идеи, фреймворки, стандарты — чем это может быть полезным лично для меня?
6. История одного проекта, который в итоге стал новым фреймворком :) Workerman в боевых условиях.
7. Comet 2.0 — презентация новой версии, сравнение быстродействия с другими фреймворками на PHP, Go, Node.js.

Badoo и другие наши приложения — взрослые проекты с миллионами строк кода. Код активно меняется, мы постоянно его ускоряем и улучшаем.

Было время, когда мы использовали сразу три статических анализатора одновременно: PHPStan, Psalm и Phan. Опыт получился любопытным.

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

Доклад будет полезен разработчикам, техническим лидерам команд и QA.