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

Конференция Highload++ Junior проходит в рамках профессионального фестиваля "Российские интернет-технологии". Вам, как участнику конференции, доступны все доклады этой конференции.

Кроме этого, Вы cможете посетить все общие доклады фестиваля, интересные широкой публике, и специализированные доклады конференций блока серверных технологий: конференции "RootConf 2017", "Backend Conf 2017".

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

Участники конференции Highload++ Junior также имеют возможность бесплатного прохода на любой из докладов смежной конференции Backend Conf. Конференция будет проходить параллельно в соседнем зале. Такое решение принял Программный комитет, когда устал ломать голову над тем, куда отнести тот или иной доклад :)

Оптимизация баз данных

MySQL: чек-лист для новичка в highload

Анастасия Распопина
Света Смирнова

В рамках данного доклада в формате "вопрос-ответ" будут рассмотрены наиболее распространённые вопросы по MySQL - от краткого обзора возможностей основных вариантов этой СУБД (актуальное состояние Oracle MySQL, Percona Server и MariaDB) до выбора наиболее оптимальных значений для конкретных параметров, чтобы справиться с ростом вашего проекта.

MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

CDN и облака

Реверс-инжиниринг архитектуры Amazon S3 по документации API и реализации

Владимир Перепелица

В этом докладе я хочу подробно рассмотреть анализ API Amazon S3 по описанию и поведению и как я проектировал и создавал аналогичный сервис в рамках Облака Mail.ru.

Целью выступления является передача личного опыта и обучение принципам построения облачной архитектуры.

Доклад будет состоять из следующих тем:
- как следует анализировать внешний API, на что обращать внимание;
- как построить модель и проверить её;
- отличия хорошей и плохой архитектуры облачного сервиса;
- как проверять свои гипотезы и предсказывать нагрузку.

API
,
Архитектурные паттерны
,
Работа с Amazon
,
Критерии выбора технологий для проекта
Программный комитет ещё не принял решения по этому докладу

Профилирование

Погружение в виртуальную память и большие страницы

Константин Новаковский

Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими.

* Как ядро работает с этими страницами?
* Как аппаратная часть помогает ядру ОС работать с виртуальной памятью?
* Какова цена виртуальной памяти?
* Для чего нужны большие страницы и почему их "прозрачное" использование может сделать хуже?
* Сколько памяти на самом деле потребляет приложение?

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

Оптимизация производительности
,
Профилирование
,
Аппаратное обеспечение
Доклад принят в программу конференции

Балансировка нагрузки

Балансировка HTTP-трафика

Антон Резников

С задачей балансировки трафика сталкивается любой растущий web-проект и почти
каждый сталкивается с проблемами и типичными ошибками в её решении. Цель доклада —
рассказать о распространённых ошибках и помочь слушателю выбрать подходящее
решение для своего проекта.

Мы рассмотрим три самые распространённые задачи: распределения запросов
динамического контента (HTML, API), раздачу статического контента и загрузку
данных от пользователя. На примере этих задач мы будем добиваться масштабируемости,
высокой доступности, затронем проблемы эксплуатации и гео-балансировку.

API
,
Отказоустойчивость
Доклад принят в программу конференции

Выбор технологий

Введение в архитектуру. Построй свое окружение!

Иван Михеев

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

В данном докладе хотелось бы осветить и разложить по полочкам:
- Типовые архитектуры нагруженных проектов. Что и куда подключать?
- Организация кластера. Что такое репликации и какие они бывают?
- Масштабирование App-сервера;
- Отказоустойчивость и балансировка нагрузки - в чем разница?
- Очереди и NoSQL, когда они становятся нужны?

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

Упрощаем сложное с помощью OpenStack TaskFlow

Павел Абалихин

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

Одним из таких решений является библиотека TaskFlow, созданная сообществом OpenStack. Разрабатывая собственные облачные продукты, мы выбрали её и остались довольны. Что умеет данный продукт и чем он может быть вам полезен - тема моего доклада.



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

Как сделать сложное простым. История создания Проект1917

Сергей Спорышев

В докладе я поделюсь нашим опытом разработки Project1917 - исторического проекта в реальном времени в формате социальной сети.

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

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

В программе:
- Организация фронта, архитектурные решения, чтобы все работало очень быстро, и стоимость изменений была минимальна.
- Организация пользовательской части "социальной сети" минимальными средствами: организация фидов/ленты, организация системы комментариев, организация системы лайков.
- Сложная, функциональная админка с постоянно работающими 100 редакторами.
- Разработка системы пуш-уведомлений в ночь перед запуском.
- Точно в срок без канбан и прочих методологий.

Single page application, толстый клиент
,
Генераторы статики
,
Взаимодействие с серверной стороной (API)
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
Фреймворки
,
PHP
,
Организация системы кеширования
,
Оптимизация производительности
,
Критерии выбора технологий для проекта
Программный комитет ещё не принял решения по этому докладу

Принципы масштабирования

Эффективное масштабирование архитектуры

Яков Якименко

Как быстро и просто развернуть и поддерживать масштабируемую архитектуру высоконагруженного проекта. Рекомендации по проектированию и используемым инструментам. (или: зачем нужны Docker, Ceph, Nginx и как их готовить).
Архитектура проекта должна не просто справляться с высокой нагрузкой, но и выдерживать случайные колебания нагрузки, а также правильно реагировать на аварии ПО и оборудования (поскольку в этих случаях потери данных - то есть, в конечном итоге, денег - могут быть очень большими), а значит, нужны средства балансировки нагрузки и репликации данных.
Одни компоненты хайлоад-проектов поддерживают распределение нагрузки и репликацию "из коробки", другие нет. И что тогда делать? Поговорим об этом.

Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

BigMemory - работа с сотнями миллионов бизнес-объектов в управляемых средах

Дмитрий Хмаладзе

Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.

Описываемый нами способ BigMemory Pile обкатан и применим для большинства современных приложений, связанных с социальными графами, обработкой потоков, IoT, stateful-алгоритмов/анализ, системами кэширования и отслеживания причинно-следственных связей.

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

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

Прочие языки
,
Базы данных / другое
,
Организация системы кеширования
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
Программный комитет ещё не принял решения по этому докладу

Антипаттерны, ошибки проектирования

ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам

Андрей Половов
Андрей Колаштов

Наша специализация — запуск и обслуживание высоконагруженных сервисов. За все время у нас не было ни одного проекта, в котором бы при запуске или эксплуатации сервиса не проявились нагрузочные проблемы, заложенные программистами или архитекторами. Цель доклада — структурировать типовые проблемы нагруженных проектов и дать практические советы по их урегулированию.

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

Доклад затронет следующие области:
* код,
* базы данных,
* архитектура,
* деплой,
* фронтенд,
* сеть,
* и самое неизбежное — человеческий фактор.

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

Ошибки проектирования высоконагруженных проектов

Максим Ехлаков

Наиболее типичные ошибки, которые совершаются при создании высоконагруженных продуктов: выбор используемых языков, фреймворков, СУБД и других инструментов. Каковы причины совершения этих ошибок, и как их избежать.
Во время проектирования и разработки высоконагруженных программных продуктов существует большой соблазн применить классические подходы. Однако не все они будут полезны, а какие-то даже вредны. При этом цена каждой такой ошибки всегда будет очень большой.
На примере нескольких реальных проектов мы поговорим об ошибках проектирования, разработки и управления, о том, почему они возникли, и о решениях, которые позволили (или не позволили) преодолеть их.

Фреймворки
,
PHP
,
Прочие языки
,
MongoDB
,
Микросервисы, SOA
,
Оптимизация производительности
,
Профилирование
,
Синхронизация данных, параллельная обработка, CDN
,
Проектирование информационных систем
Доклад принят в программу конференции

Реляционные СУБД для «чайников»

Николай Самохвалов

SQL – очень старый язык (работа над первым его стандартом началась ещё в 1983). Это очень «раздутый» язык. Но вместе с тем, SQL – один из самых популярных языков программирования в мире.

А такие реляционные СУБД (РСУБД) как PostgreSQL, Oracle, SQL Server и MySQL — популярные и активно развивающие системы с очень сильными принципами, возможностями. Реляционная модель данных пережила, как минимум, три волны «атак»: были объектные и объектно-реляционные СУБД в 90-х, потом была мода на «слабоструктурированные» данные (XML) в начале 00-х, ну и, наконец, завершающаяся эпоха NoSQL-решений (данные зачастую совсем без структуры, прежде всего JSON). Все эти «атаки» не только не пошатнули позиции РСУБД, но, наоборот, значительно укрепили их. РСУБД впитали в себя очень много новых возможностей, попутно укрепив свои сильные позиции (прежде всего ACID).

В РСУБД теперь можно использовать сложные типы данных — массивы, JSON, геометрические данные и т.д. Можно писать очень сложные аналитические запросы, применяя CTE. Можно выстраивать мощные процедуры проверки ограничений целостности и оптимизировать работу с данными, применяя хранимые процедуры, триггеры, представления и материализованные представления. Про различные «продвинутые» возможности современных РСУБД можно найти много докладов, статей и книг, но вот базовым вещам внимания уделяется очень мало.

Любой Full Stack Developer сегодня обязан иметь в своём арсенале опыт и умение работы хотя бы с одной популярной РСУБД. Но без понимания основ — того, какие задачи решают СУБД, как происходит работа с данными, какие есть базовые возможности для этой работы, — такие умения превращаются в воздушный замок, быстро разрушающийся при росте проекта.

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

Мы обсудим несколько фундаментальных примеров из реальной жизни, каждый из которых встретился автору совсем недавно:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;

- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- задачи machine learning.


Для каждого кейса мы сравним плюсы и минусы реализаций «на стороне СУБД» и «снаружи / на стороне приложения», прежде всего с точки зрения производительности. Постараемся понять, почему современные разработчики часто боятся использовать мощь РСУБД. Ну и, наконец, представим чеклист знаний, которые, по мнению автора, необходимо иметь, чтобы чувствовать себя увереннее при работе с РСУБД.

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

Прочие темы

Приключения проекта от компьютера разработчика до серьезных нагрузок

Андрей Минкин

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

Со временем проект становится популярнее и популярнее, нагрузка начинает расти и мы поговорим о том, что такое:
0. Нагрузка? Как ее анализировать? Как понять, где нагрузка? Как оптимизировать код? Когда внедрять кэширование и начинать масштабирование. Какие подводные камни вас ожидают?
1. Кэширование. Как внедрить, и какие есть подводные камни. Как оценить, что кэширование работает? Какие проблемы возникают, если кэширование работает плохо.
2. Путь масштабирования и борьба за ресурсы. Как жить, если все сервисы дерутся? Когда масштабировать, и какие есть варианты масштабирования
3. Проблемы балансировки.
4. Подводные камни в распределенных системах. Состояния гонки и проблемы конкурентного доступа. Целостность данных. Событийная целостность.

Миграции данных
,
Оптимизация производительности
,
Профилирование
Программный комитет ещё не принял решения по этому докладу

Рост с нуля до 15000 сообщений в секунду. Мучительный и поучительный

Юрий Колесов

Компания TIMCONNECT процессит банковские смс-сообщения, по возможности отправляя их как push.
История роста проекта со старта и до обработки 15000 смс/сек полна поучительных моментов, как нужно делать и как не нужно делать, если вы собираетесь расти. Доклад о собранных граблях и сделанных выводах.

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

Стабильный API - взгляд без стыда

Дарина Гордеева

- Основные проблемы при работе с API и как тестирование может помочь в их решении.
- Как тестировать API - white-box и black-box.
- Benchmark'и для API: скорость и стабильность.
- Как измерить профит от тестирования API.
- Как хорошая документация может помочь в тестировании API.
- Автоматизация тестирования API.
- Поддержка и актуализация тестов (про архитектуру и рефакторинг).

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

Анатомия распределенного хранения: строим кластерную СУБД на базе RAFT

Даниил Подольский

Последние годы нам - GitInSky - приходится работать с кластерными СУБД постоянно, поскольку они приобретают все большее распространение у клиентов.

На основе этого опыта мы - и не в последнюю очередь я - читали весь последний год разной направленности доклады на различных конференциях.

И вот парадокс - чем больше я читал докладов на эту тему, тем лучше я понимал, что не очень хорошо разбираюсь в кластерных СУБД.

Нет, я отлично представляю себе их эксплуатационные свойства! Я знаю, в каких условиях какие базы ведут себя одинаково, а в каких по-разному. Я представляю себе, как какая из них поведет себя в случае сбоя или экстремальной нагрузки...

Но, почему? Почему они ведут себя так или иначе, и почему они ведут себя по-разному?

Для ответа на эти "почему", очевидно, требуется понимать, как именно устроены кластерные СУБД в деталях и в общем.

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

И тогда я подумал - а почему бы не написать собственную кластерную СУБД?!

Нет, не для замены существующих, как предположил один из членов программного комитета. Исключительно для того, чтобы, идя "от задачи", понять, какие технические решения используются при создании кластерных СУБД и почему.

Объем работ выглядит в первом приближении жутко, но на деле оказался вполне подъемным. Оказалось, что все необходимые для построения кластерной СУБД кирпичи уже написаны и протестированы другими людьми, и можно просто "сосредоточиться на предметной области".

И я хочу поделиться приобретенным опытом!

На мастер-классе мы:
* Определим, какие задачи должна решать наша кластерная СУБД и какими свойствами обладать.
* Нарисуем диаграмму компонентов системы, которая, как мы думаем, "сможет решать и будет соответствовать".
* Глядя то на диаграмму, то в интернет, определимся со списком кирпичей.
* Посмотрим пристально на ключевой кирпич — протокол RAFT.
* Прикинем список "бутылочных горлышек" и проведем микробенчмарки соответствующих кирпичей. Самая интересная часть, с моей точки зрения!
* Соберем всю систему вместе и попробуем оценить, что же получилось.
* По ходу дела посмотрим, где и как промышленные кластерные СУБД пытаются "срезать углы", и каким образом это делает их лучше для одних задач и хуже для других.

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

SOA - давайте посмотрим на недостатки

Иван Круглов

Контейнеры и микросервисы - все это круто, модно и интересно. Переход на их использование принесет команде заметные преимущества. Но сервис-ориентированная архитектура (SOA) не лишена недостатков. Один их них - это то, что заменяя простой вызов функции на RPC, мы в неявном виде вводим в уравнение, отвечающее за стабильность системы, целую плеяду новых неизвестных. Например, простейший HTTP-запрос за время своей жизни проходит через множество всевозможных буферов, очередей и алгоритмов на своем пути от клиента к серверу и обратно. Совокупное поведение этих составляющих трудно предсказать, понять и правильно интерпретировать. И особенно трудно это сделать в нестандартных ситуациях.

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

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

Как заранее соломки подстелить или путь к 99,99% uptime проекта

Игорь Мызгин

Каждый проект проходит несколько жизненных стадий, на каждой из которых есть развилка: умереть, замереть на данной стадии или перейти на качественно новый уровень. Первой стадией является чуть ли не виртуалка / мокап / скетч на ноутбуке фаундера/кофаундера. Вторая стадия - это одна/две/три виртуалки на каком-нибудь хостинге. И третий этап - активный рост, развитие инфраструктуры, публикации на ТехКранче и прочие символы успеха.

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

В своем докладе я буду говорить о том, о чем надо не забывать пока маленьким проектам, чтобы смочь вырасти большими и при этом не потратить все ресурсы на создание инфраструктуры проекта. Я детально проговорю то, о чем 99% клиентов хостинга задумываются по факту:
- о разграничении ответственности между клиентом и хостером,
- о том, что написано в SLA и как этот / эти документы читать,
- что должен сделать проект сам, и почему за проект это не будет делать хостер,
- как спланировать свой рост и не стать заложником изначальной инфраструктуры при активном росте,
- о чем надо спросить "на берегу" провайдера/провайдеров.

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

Отказоустойчивость
,
Распределенные системы
,
Разделение представления и бизнес-логики, шаблонизация
,
Архитектуры / другое
,
Управление конфигурацией
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Большие проекты/команды
,
Работа со внешним заказчиком/исполнителем
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Программный комитет ещё не принял решения по этому докладу

Проксирование HTTP-запросов web-акселератором

Александр Крижановский

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

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

- Как работает HTTP-проксирование без кэша;
- Что такое персистентные соединения и чем они отличаются от HTTP keep alive;
- Как, когда и сколько соединений может устанавливать HTTP-акселератор с апстримом;
- Что становится с запросами, которые ждут очереди на отправку в соединение с апстримом, но апстрим "из коробки" и сбрасывает соединения каждые 100 запросов;
- Что такое HTTP pipelining, и как им пользуются современные HTTP-акселераторы;
- Что такое неидемпотентные запросы, и почему нужно о них беспокоиться.

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

Spring Cloud & Netflix integration

Алексей Романов

1. Обзор клиентов для rest.
2. Краткий рассказ про RestTemplate (getForObject, getForEntity).
3. В RestTemplate можно подложить имплементацию для выполнения запросов (setRequestFactory: OkHttp, Apache Http (sync/async), Netty).
4. Рассказ про Feign Client, его интеграция со Spring Cloud.
5. Encoder/Decoder, Retry, установка клиента для выполнения запроса, логирование.

6. Serive Discovery, что такое и зачем нужно.
7. Consul, кратко по агенты, интеграция через Spring Cloud.
8. Consul config server.
9. Eureka, запуск в нескольких зонах, авторизация.
10. Интеграция Feign Client с service-discovery (только про service-id).
11. Ribbon в роли client-side load balancer. Кратко: какие есть стратегии балансировки (RandomRule, WeightedResponseTimeRule, BestAvailableRule, ZoneAvoidanceRule).

12. Кратко про отказоустойчивость и таймауты.
13. Hystrix, что такое Circuit breaker, Hystrix Javanica. Как вырубить Hystrix для Feign Client.
14. Краткий рассказ про sync/async execution. (execute() -> Observable().toBlocking().toFuture())
15. Что делать, если rest-сервис строится на кодах ошибок (4xx). Интеграция Fiegn Client ErrorDecoder и проброс кастомных ошибок. (https://gist.github.com/anonymous/46ac361e96beb5274aed5e48f0be6d7d)
16. Кэширование запросов.
17. Объединение запросов в один (request collapsing).
18. Hystrix Dashboard. Рассказ про turbine (v. 1.x).
19. Turbine Instance Discovery (пока не пробовал, только читал, на выходных проверю).
20. Асинхронная передача метрик через RabbitMQ.

Фреймворки
,
Java
,
Архитектурные паттерны
,
Распределенные системы
Программный комитет ещё не принял решения по этому докладу

После подключения DDoS-защиты: как "положат" Ваши ресурсы

Рамиль Хантимиров

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

Защита информации
,
Бэкенд / другое
Программный комитет ещё не принял решения по этому докладу

Чеклист по клиентской оптимизации

Николай Лавлинский

Когда проект растёт, возникает множество проблем с масштабируемостью сервиса: БД, сервера приложений, хранилище. Однако, не менее важной становится клиентская часть веб-приложения.

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

Во-вторых, применение методик клиентской оптимизации даёт экономию серверных ресурсов: трафик, каналы, место на диске, иногда даже CPU. Для растущих проектов это становится важным.

Вот примерный чеклист по клиентской оптимизации, покрывающий большинство проблем среднего веб-проекта.
1. Базовая конфигурация Nginx для эффективной раздачи статики.
2. Клиентское кэширование: заголовки, сброс кэша, особенности браузеров.
3. Сжатие текстового контента: gzip, zopfli, brotli, статическое сжатие, поддержка Nginx и браузеров.
4. Быстрый TLS: конфигурация Nginx, нагрузка на сервер и клиент, наиболее оптимизированные шифры, типы сертификатов, stapling, кэширование сессий, HTTP/2.
5. Настройка TCP/IP-стека в Linux для веб-приложений.
6. Оптимизация картинок: для JPEG, PNG, SVG, применение WebP.
7. Веб-шрифты: форматы, подходы к оптимизации.
8. Общий подход к ускорению рендеринга страниц (синхронная/асинхронная загрузка CSS, JS, объединение ресурсов), клиентские SPOF.
9. Использование CDN: когда нужно, зачем. Влияние задержек сети на скорость.
10. Средства синтетического тестирования клиентской скорости.

Веб-графика, оптимизация изображений
,
Сетевое администрирование
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Выбор языка программирования для вашего проекта (и жизни)

Александр Чистяков

С высоты 11000 метров все языки программирования одинаковы и, если вы спросите кого-нибудь из тех, кто часто выступает на индустриальных конференциях, ответ может быть: "берите любой ЯП". Тем не менее, никто не начинает новые проекты не только на Visual Basic или COBOL, но и на Perl. Почему?

Python стал языком общего применения, который применяется в разных отраслях индустрии, от веб-разработки, до data science, тем не менее, в последние несколько лет появился и занял заметную нишу целый класс новых языков программирования.

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

Будут освещены особенности языков Nim, Elixir, Clojure, Elm - на каждом из них я попробовал сделать небольшой коммерческий или же Open Source проект. Особое внимание я уделю языку Rust, который предназначен для так называемого "низкоуровневого" программирования и максимально учитывает устройство платформы, на которой он будет исполняться (в частности, в языке Rust нет сборщика мусора). Кроме того, мы рассмотрим проникновение новых концепций в Java 8 и далее.

Фронтенд / другое
,
Java
,
Python
,
Прочие языки
,
Методы и техника разработки ПО
,
Критерии выбора технологий для проекта
Программный комитет ещё не принял решения по этому докладу