Доклад для тех, кто уже занимается разработкой на одном из популярных с-подобных языков и задумывается, можно ли лучше или хотя бы по-другому. Clojure — одно из возможных направлений поиска ответа на этот вопрос. Разберём основные отличия-преимущества в сравнении с другими языками, если до вас доходили какие-то слухи про Clojure — постараемся из развеять (или подтвердить). Научимся читать код и даже немного попишем (да, это можно успеть сделать за доклад).

Из доклада вы узнаете, что можно писать код:

• без статических типов
• и без объектов
• и синтаксис тоже не нужен
• и изменяемое состояние тоже выкинем

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

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

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

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

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

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

Знакомая ситуация?

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

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

И самое главное не испортить при этом жизнь вашим бэкендерам =)

Поиск в Яндексе — это большой проект с богатой историей и непрерывным развитием. Над поисковой страницей одновременно работают больше 50 человек. Для успешной разработки необходимо поддерживать современную инфраструктуру. Именно поэтому мы решили перейти от i-bem.js (JS + jQuery) к актуальному стеку на TS + React.

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

Дополнительно расскажем, какие оптимизации можно применить к React, чтобы не просадить метрики скорости и удобства пользователей, но при этом и не сломать удобство использования для разработчиков. Как принести улучшения в сторонний фреймворк, сохранив приятный developer expirience и не породить чудовище Франкенштейна.

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

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

Пользователь жалуется — медленно работает веб-страница. Что делать?

Разберемся с тем, что происходит с html-страницей в браузере, в частности рассмотрим два аспекта: работу с сетью и рендеринг. Какие узкие места производительности могут быть, как их обнаружить и что с ними делать. Набор общих рекомендаций по улучшению производительности frontend-приложений. Разбор некоторых случаем провисания производительности.

Доклад будет интересен тем, кто относительно недавно начал знакомство с такой темой как performance frontend-приложений, а также тем, кому хочется окунуться в мир frontend’а и браузеров.

Поговорим о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.

Расскажем, как c помощью этого инструмента мы сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.

Вы узнаете:

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

Многие программисты до сих пор считают, что терминал — это инструмент бородатых админов из 80-х годов. На самом деле это не так — каждый год в сообществе появляются новые консольные инструменты, которые улучшают ежедневную рутину программиста: упрощают работу с гитхабом, поиск файлов, переход между проектами. Есть инструменты с говорящими названиями, к примеру tldr ускоряет чтение документации, а fuck — исправляет ошибку в последней введённой команде.


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

В рамках воркшопа мы спарсим данные об аэропортах из открытого источника и разработаем Rest API для работы с этими данными.
Для реализации будем использовать Python (Django) и PostgreSQL.
В процессе реализации:

• Развернем приложение, упакуем в Docker
• Создадим миграции, первоначальное заполнение данными из источника
• Реализуем методы REST API
• Покроем API тестами
• Задокументируем написанное API

В результате у нас получится Rest API для фронтенда, покрытый авто-тестами.

В рамках воркшопа мы спроектируем и разработаем интерфейс для визуализации данных об аэропортах.
Для реализации будем использовать React JS, TypeScript и Rest API из первого воркшопа.
В процессе реализации мы затронем следующие стадии разработки:

• Соберем интерфейс на основе готового шаблона
• Верстка темплейтов c Tailwind CSS
• Создание основных компонентов, настройка роутинга
• Разработка API-слоя, разработка сторы
• Интеграция сторы с интерфейсом
• Частичное покрытие функционала тестами

В результате у нас получится интерфейс веб-приложения, который использует Rest API из первого воркшопа.

VK Cloud Solutions и GitHub.


— Рассмотрим работу с Docker в VK Cloud Solutions

— Опубликуем и настроим работу Rest API

— Настроим сборку и публикацию в облаке фронтенда на React, TypeScript

— Настроим GitHub Actions (Gitlab CI) для автоматизации запуска тестов и публикации приложений в облако


Результатом станет опубликованное приложение в инфраструктуре VK Cloud Solutions, которое работает как SPA с Rest API и доступно в глобальной сети.