Стачка.Backend

Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.

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

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

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

Это вторая инкарнация моего доклада о том какие ошибки допускают разработчики при работе с Postrges'ом.

Я с моими коллегами из Data Egret являемся Postgres-консалтерами и регулярно наблюдаем как команды разработки осознанно или нет, но допускают ошибки при работе с Postgres'ом.

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

В докладе я рассмотрю:

- проблемы, связанные с планированием, мониторингом и дефолтными конфигурациями, которые встречаются практически везде и всегда;

- антипаттерны, связанные с проектированием схем данных;

- проблему длинных транзакций, которая часто становится сюрпризом;

- еще будет про самописные системы очередей, HTAP workload, "бигдату", docker/kubernetes.

По ходу доклада слушатели узнают про некоторые best и worst practices при работе с СУБД и, уже смотря на свои базы, смогут заранее спрогнозировать возникновение неприятных ситуаций и предпринять меры.

Доклад будет полезен широкому кругу технических специалистов, вовлеченных в разработку ПО и обслуживание баз данных.

Пять лет мы жили с самописной шиной для обмена данными — теряли сообщения и страдали от однопоточного импорта. Сегодня мы используем Apache Kafka и Golang для обмена данными между сервисами.

Расскажу, как механизм «отложенных данных» помог нам организовать сбор информации от десятка команд. От десятка команд, чья очередность выгрузки непредсказуема. Поделюсь, как нам удалось построить зависимости и поставлять данные констистентно и в срок.

Незаметно для самих себя мы в Ecwid доросли до 100Gb (и 200 миллионов строк) логов каждые сутки. Unix-утилиты, конечно, дают жару, но grep/sed/awk на таких объемах увы, не справляются. Мы запихнули все эти десятки терабайт за несколько месяцев в ClickHouse, написали свой простой язык запросов, подкрутили тут, там и получилась очень простая и быстрая система работы с логами. В докладе я объясню как за пару дней на коленке построить себе такое же счастье.

На сегодняшний день ClickHouse одна из самых динамично развивающихся СУБД.

Давайте посмотрим как менялся ClickHouse за последние пару лет и на примерах разберем документированные, так и недокументированные возможности, которые позволяют создавать более эффективные приложения.

В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака. Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта. Доклад будет интересен разработчикам, которые хотят избежать проблем при работе с Postgres и полезен DBA, которые хотят узнать с какими трудностями сталкиваются клиенты их базы данных.

MariaDB давно переросла своего родителя MySQL за счёт функционала добавляемого в MDB. Одной из фичей стал engine для аналитической нагрузки - Columnstore AKA MariaDB AX, который отлично укладывается в парадигму MariaDB: каждой нагрузке свой движок.

В рамках доклада я познакомлю аудиторию со строением и возможностями Columnstore.

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

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

Доклад предполагает в дополнение к советам описания ситуаций, в которых эти приёмы помогли достичь поставленной цели.

У нас был незнакомый проект, сотня мегабайт исходных кодов, 5.5 млн пользователей, 50 гигов информации в базе данных, AWS S3 на десяток терабайт, SQS очереди, работающие через одно место, несколько микросервисов, полное отсутствие документации и Drupal под которым это все работало. Единственное, что меня беспокоило - это рефакторинг. В мире нет никого более беспомощного, безответственного и безнравственного, чем разработчик, собирающийся рефакторить незнакомый проект. И я знал, что довольно скоро мы в это окунемся. На примере Musescore.com - крупнейшей в мире библиотеки нот, я расскажу, о проблемах и решениях, с которыми вы столкнетесь, когда решите взять все и переписать.

Работал долгое время на Ruby, месяц работаю на Go.

Его создали языком, в котором сложно допустить непоправимые и сложнопоправимые ошибки, и с которым при этом разберётся любой джун.

Что ж, в этом есть и плюсы и минусы.

Минусы:

* приходится переизобретать много вещей заново

* чувствуешь себя ребёнком, у которого отобрали все любимые игрушки

Плюсы:

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

Я не буду рассказывать про идиомы языка, фреймворки, и инструменты.

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

Популярным сегодня языкам программирования уже много лет, и то, как выглядит код на C# или Java, очень сильно отличается от того, что задумывали разработчики -дцать лет назад. А ведь подходы, лежащие в их основе, парадигмы, остались все теми же. Как так получилось? По каким законам рождаются, растут и умирают парадигмы и почему это важно для нас, разработчиков? Что же, попробуем в этом разобраться!

Domain-driven design — набор подходов к разработке, который, с одной стороны, на слуху, а с другой, к нему очень сложно подступиться. Есть большие книги (Эванс, Вернон), но далеко не все их читают и еще меньше людей читают их до конца. А даже и дочитав, могут упустить суть за обилием деталей. Сотни статей в блогах и постов на StackExchange только усугубляют эту проблему.

О чем жалеет Эванс спустя 15 лет после выхода его книги?

Bounded context: имеет ли значение размер?

Все ли паттерны одинаково полезны?

И, наконец, в чем же суть domain-driven design?

Обо всём этом расскажет Алексей в своем докладе. Отличный повод узнать DDD и разложить по полочкам.

Прошёл хайп по микросервисной архитектуре. Rust уже не считается молодым языком программирования. Но что если соединить две технологии вместе?

В своём докладе я покажу как можно экономить ресурсы (железные и кожанные) на разработке и эксплуатации микросервисного приложения с использованием крутых (а Rust это очень круто) технологий:

Rust, Java, Kotlin, GCP, Raspberry Pi, красивый спикер - всё это ждёт вас, присоединяйтесь!

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

В докладе мы поговорим о весьма хорошо зарекомендовавших себя подходах, известных еще со времен Smalltalk и Erlang, - Message-oriented middleware и Event Sourcing. Обсудим пути миграции RPI-based приложения в сторону асинхронности и реактивности. Поговорим о трудностях возникающих на этом пути, посмотрим, как решаются вопросы с ACID и CAP, а также какие подходы можно применить для тестирования подобных систем.

Посмотрим вместе на современный PHP и фреймворки. Разберём что Yii за свою историю сделал хорошо и что плохо. Поговорим о будущем. О версии 3.0.

У нас в компании эксплуатируются тысячи микросервисов на .NET. Мы стараемся делать качественные продукты, поэтому особое внимание уделяем телеметрии: логам, метрикам и распределённым трассировкам.

Проект Vostok - это инструменты и практики, зарекомендовавшие себя внутри Контура, которые мы делаем частью OpenSource. Сегодня поговорим о той части Востока, которая обеспечивает централизованную обработку телеметрии.

Ключевые технологии:


- Apache Kafka


- Apache Cassandra


- Apache ZooKeeper


- Graphite


- ELK

Подать доклад

JIT (Just in Time) компиляция – неотъемлемая часть многих популярных платформ (JavaScript, Java). Задача компиляции в момент выполнения существенно отличается от классической AOT (Ahead of Time) компиляции.

Эволюция технологий JIT и AOT компиляции во многом идут параллельными путями.

В докладе будет рассказано о новейших достижениях JIT компиляторов для Java и JavaScript платформ, а так же о фундаментальных отличиях JIT и AOT компиляторов.

Рано или поздно любой проект задумывается о репликации данных. Цели могут быть разные — от резервирования до случаев когда данные элементарно не помещаются на одной физической машине.

Какую систему репликации для PostgreSQL выбрать? Какие могут быть ограничения или подводные камни? Какие системы есть в принципе?

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

В докладе поговорим:

Сравним REST/gRPC/WebSocket.

Чем хорош gRPC для разработки API на Go

Как поддерживать в продакшне и какие могут быть проблемы

Экосистема вокруг gRPC

Как профилировать и решать проблемы с производительностью

Тестирование gRPC API

Балансировка gRPС на сервере и клиенте

Observability в gRPC

Нам отдали развесистое API на Java, когда мы были фронтендерами, и попросили сделать его лучше. Сейчас мы уже переписали основную нагруженную часть на NodeJS, попутно столкнувшись с дилеммой выбора подходов к общению API с клиентами. Расскажу о том:

• как уменьшить количество данных в API
• как сохранить обратную совместимость и простоту разработки
• почему в 90% случаев не нужно отдельное api для фронтенда

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

Безусловно, можно заранее подготовить базу данных из бэкапа, а затем запустить тестирование, однако очевидно, что такие тесты будут тяжеловесными для запуска и займут много времени. Другим возможным сценарием может быть подмена сложных зависимостей на упрощенные, такие как in-memory хранилища, что в свою очередь приводит к сильному ухудшению достоверности и надежности тестов.

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

Доклад будет особенно интересен разработчикам, которые сконцентрированы на создании микросервисной архитектуры, а также тем, кто разочаровался в юнит-тестировании.

Технологии, которые будут затронуты в докладе: ASP.NET Core, Docker, Xunit.

В докладе я сравню процессы перехода на Go в двух компаниях с совершенно разными технологическими стеками (PHP и .NET). Я постараюсь сделал доклад сбалансированным и в равной степени осветить техническую и организационную сторону этого вопроса. Чего в этом докладе не будет: рассказа о том какой Go замечательный язык, об этом уже достаточно сказано.