Заявки на доклады

Поиск по тегам:
Показать только принятые доклады

Базы данных и ORM

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

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

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

Программный комитет ещё не принял решения по этому докладу

Внутренности PHP

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

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

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

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

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

Итак, вы планируете или уже переходите с монолита на микросервисы. Причем докеризированные. Вы хороший программист, но вы споткнетесь…

Мы уже прошли путь от монолита до 100 с лишним PHP-сервисов на базе Docker Swarm, причем в контексте множества команд — как продуктовых (их сервисы близки к конечному пользователю), так и сервисных (их работа важная для компании). И, кажется, за последний год мы добились правильной и стабильной работы этого “зоопарка”.

Расскажу:
+ Как правильно приготовить Докер, делить сервисы и как делать нельзя.
+ Про опыт внедрения health-check приложений в Сварме.
+ Как внедрить стандарт трассировки и логирования.
+ Как устроить деплой без разрывов.
+ Фоновые задачи — как сделать их хорошо.
+ Нужен ли fpm.
+ Как дебажить контейнеры, особенно когда нет доступа.
+ Как построить Service Map: Zipkin vs NewRelic.
+ про APM и не только.

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

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

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

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

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

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

Мы почти превратили наш "молодой динамично развивающийся проект" в big ball of mud.
Нам нужно было организовать процесс общения между оператором и клиентом. Сначала у нас был виджет, который просто транслировал email переписку, потом мы добавили whatsapp, смс, пуши, звонки, другие мессенджеры... И столкнулись с классикой: тяжело добавлять новые фичи, тяжело тестировать, много багов.
Я расскажу, как мы героически из этого выкарабкивались - что планировали, что менялось и что получили почти год спустя на проде:

-- Почему не стали ничего выносить, инкапсулируя сервисы и сохраняя их границы в монорепе.

-- Распил монолита по принципам пакетного дизайна. Примеры из реального проекта на PHP. От каких болячек избавились и какие приобрели.

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

-- Что мы будем делать дальше? Немного о планах по выделению пакетов в микросервисы.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

- О Temporal.io (candence, AWS SFW).
- Event Sourcing и стейт-машины.
- Распределенные и отказоустойчивые бизнес-процессы на RoadRunner.
- Пишем код на любом языке.
- Примеры использования.

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

Лучшие практики

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

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

Чаще всего вам рассказывают о том, как улучшить ваше приложение. Практики codestyle, DDD, performance engineering, SOLID и прочее, причём не особо вдаваясь в детали реализации. Почему бы не поговорить о том, как насолить CTO и уничтожить ваше приложение, приведя его к состоянию «пора всё переписывать с нуля»?

Вредные советы для разработчиков на примере PHP. От использования конкретных практик до конкретных инженерных решений. Overload, overengineering, overarchitecture и все прелести, которые ждут вас от несоблюдения best practices.

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

Другое

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

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

Мастер-класс проведёт технический директор образовательной платформы Hacktory Иван Юшкевич.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Разработка приложений по долгоживущей модели, используя RoadRunner;
- гибридная диспетчеризация, используя Golang-сервер и PHP-консюмеры;
- изоляция пользовательского контекста, используя IoC-замыкания;
- Cycle ORM и динамический маппинг datamapper-схем в рантайме.

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

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

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

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

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

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

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

Современный PHP все больше проникает в Enterprise-разработку и успешно перенимает многие архитектурные подходы из мира Java и C#. Такие термины, как MBA, SOA, DDD, а, возможно, и CQRS с Event Sourcing (ES) прочно входят в обиход PHP-разработчиков. Но правильно ли мы их применяем?

Как построить гибкую архитектуру проекта на основе этих решений? Как успевать за стремительно меняющимися бизнес-требованиями? Чтобы ответить на эти вопросы, важно понимать, какие проблемы призваны решать эти архитектурные паттерны и как выявить их в своем проекте.

В этом докладе я поделюсь своим видением области применения CQRS и ES для PHP, расскажу об OpenSource-библиотеках, помогающих внедрить CQRS- и MBA-подходы в свой проект, и сравним их с решениями для C#, Java и Erlang.

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

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

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

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

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

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

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

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