Конференция завершена. Ждем вас на PHP Russia в следующий раз!

Доклады

Базы данных и ORM (1)

Thesis: как забыть про ORM и перейти на нативные SQL-запросы

PHP
Базы данных / другое
Разработка библиотек, включая open source библиотеки

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

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

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

Доклад принят в программу конференции

Внутренности PHP (2)

PHP 8.* — еще быстрее

PHP
Оптимизация производительности

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

Доклад принят в программу конференции

Выходя за рамки ООП. Разработка расширений для PHP ... на PHP!

C/C++
PHP
Разработка библиотек, включая open source библиотеки

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

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

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

Доклад принят в программу конференции

Архитектура и масштабируемость (3)

Уходим в кэш в высоконагруженных системах

PHP
Организация системы кеширования
Архитектурные паттерны
Оптимизация производительности
Распределенные системы

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

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

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

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

Доклад принят в программу конференции

Архитектура на “микросервисах” в монолите: примеры из практики

PHP
Микросервисы, SOA
Архитектурные паттерны
Поддержка и развитие legacy систем

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

Доклад принят в программу конференции

Строим эффективный сетевой обмен в микросервисах

PHP
Микросервисы, SOA
Архитектурные паттерны
Отказоустойчивость
Оптимизация производительности
Распределенные системы

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

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

Доклад принят в программу конференции

Фреймворки и библиотеки (1)

Распределенные Workflow на PHP

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

Доклад принят в программу конференции

Лучшие практики (4)

Поговорим про код

PHP
Архитектурные паттерны
Стандарты кодирования
Рефакторинг

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

Доклад принят в программу конференции

Валидируем архитектуру и производительность без запуска кода

PHP
Архитектурные паттерны
Разделение представления и бизнес-логики, шаблонизация
Лайфхаки
Александр Кирсанов

VK, Вконтакте

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

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

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

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

Доклад принят в программу конференции

Отказоустойчивая работа с клиентами

PHP
Бэкенд / другое
Отказоустойчивость

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

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

Доклад принят в программу конференции

Типичные бутылочные горлышки в проектах на PHP

PHP
Архитектурные паттерны
Стандарты кодирования
Другое

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

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

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

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

Доклад принят в программу конференции

Реальный опыт (1)

Найти за полсекунды: сравниваем похожие фотографии

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

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

Доклад принят в программу конференции

Другое (4)

Мастер-класс "Веб-безопасность для начинающих"

PHP

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

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

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

Доклад принят в программу конференции

Уязвимости в приложениях на PHP и способы их эксплуатации

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

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

Доклад принят в программу конференции

Unit-тесты — ничего нового, только старое

Юнит-тестирование

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

Доклад принят в программу конференции

Разработка DSL и ЯП на PHP: как и зачем?!

PHP
Разработка библиотек, включая open source библиотеки
Алгоритмы и их сравнение
Архитектуры / другое

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

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

Доклад принят в программу конференции

PHP, стандарты, фреймворки, библиотеки, OpenSource (7)

Версионирование API. Единая кодовая база для всех версий

API
PHP

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

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

Доклад принят в программу конференции

Плагины для PhpStorm. Проще, чем кажется

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

Доклад принят в программу конференции

Мутационное тестирование в PHP

PHP
Maks Rafalko

Itransition

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

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

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

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

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

Доклад принят в программу конференции

Spiral — высокопроизводительный фреймворк

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

Доклад принят в программу конференции

Быстрый способ разобраться с легаси и начать жить

PHP
Стандарты кодирования
Рефакторинг
Сергей Жук

ВсеИнструменты.ру

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

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

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

Доклад принят в программу конференции

PHP на скорости света — обзор Swoole, RoadRunner, Workerman

Фреймворки

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.

Доклад принят в программу конференции