- DevOps, # 2.5, Вокальная студия
Не секрет, что сама парадигма DevOps ориентирована на какую-либо конкретную платформу. Это может быть голый Linux, Kubernetis, AWS и т.д.
Для каждой платформы существуют свои инструменты с присущими им плюсами и минусами. Работая над серьезными проектами небольшим коллективом
мы выработали для себя набор практик, которые в дальнейшем воплотили в своё собственное Open Source решение. На примере нашего решения будут раскрыты
основные понятия, такие как:
- Замкнутый цикл разработка-тестирование-развертывание;
- Инфраструктура как код и её версионирование;
- Шаблоны развертывания;
- Изолированные контейнеризированные окружения;
- Программно-определяемая среда выполнения.
Для каждой платформы существуют свои инструменты с присущими им плюсами и минусами. Работая над серьезными проектами небольшим коллективом
мы выработали для себя набор практик, которые в дальнейшем воплотили в своё собственное Open Source решение. На примере нашего решения будут раскрыты
основные понятия, такие как:
- Замкнутый цикл разработка-тестирование-развертывание;
- Инфраструктура как код и её версионирование;
- Шаблоны развертывания;
- Изолированные контейнеризированные окружения;
- Программно-определяемая среда выполнения.
- Всадники технологий, #1.1, Конференц-зал
В докладе сделан системный анализ 7 основных аспектов, присущих цифровому предприятию 4.0. Предложена модель перспективной архитектуры ИТ-платформы такого предприятия. Показано, что перед аналитиками, программистами и другими специалистами ИТ-индустрии открываются гигантские перспективы нового рынка программных продуктов. По каждому из 7 аспектов показаны направления возможного движения по созданию принципиально новых программных продуктов и решений, которые востребованы уже сейчас и будут востребованы в большом масштабе в самом ближайшем будущем. Что надо сделать для того, чтобы предприятие могло поэтапно трансформироваться из сегодняшнего состояние в состояние 4.0? Некоторые ответы стратегического характера будут даны в докладе.
- DevOps, # 2.5, Вокальная студия
Хочу поделиться опытом построения процессов CI\CD в компании с нуля.
С проблемами, затронутыми в данном докладе, сталкивается любой админ знакомый со страшным словом "Релиз".
Расскажу наш путь перехода от Ctlc+C/Ctrl+V к HotDeploy.
С проблемами, затронутыми в данном докладе, сталкивается любой админ знакомый со страшным словом "Релиз".
Расскажу наш путь перехода от Ctlc+C/Ctrl+V к HotDeploy.
- DevOps, # 2.5, Вокальная студия
Доклад расскажет, зачем нужен DevOps-подход, существуют ли DevOps-инженеры, на что обратить внимание при внедрении DevOps, на какие технологии сегодня стоит обратить внимание. Чтобы все это не было скучно, доклад наполнен увлекательными примерами из опыта консалтинга «Экспресс 42».
- Мастер-классы , #2.2, Информационный зал
В ходе мастер-класса мы нарисуем цифровой портрет в программе Photoshop, используя базовый инструментарий программы, разберём основные принципы стилизации форм на примере натуры.
- Java-программирование, #1.1, Конференц-зал
В докладе расскажем об особенностях lambda-архитектур, платформе микро-сервисов Amazon Lambda, а также подводных камнях и победах с Node.JS и многопоточной Java. Затронем тему эффективной разработки и тестирования надежного и устойчивого многопоточного кода на Java. Поделимся опытом организации промежуточного дифференциального хранилища и непростым выбором между LMDB (lightning memory-mapped database), LevelDB (используется в Bitcoin blockchain), Apache Derby и Berkeley DB. Подробно расскажем о тонкостях использования инфраструктуры очередей на базе Amazon SQS, NoSQL в DynamoDB и мониторинге системы для предотвращения потерь данных клиентов и минимизации рисков последствий отказов и аварий датацентров. Разберем практику применения алгоритмов кластерной координации на примере ZooKeeper/Curator для масштабирования приложения.
- AI, ML, BigData, #2.3, Инженерный зал
Соревнования по машинному обучению - это очень позитивное явление, в котором можно и нужно участовать по множеству причин. При должном подходе соревновательный опыт непосредственно транслируется в скиллы и наработки для разработки решений на базе машинного обучения. В докладе будет рассказано как это сделать на примере соревнований второй половины 2018 года. А также как с их помощью удалось разработать решение для анализа доступности товаров на полке в магазинах.
- Дизайн и компьютерная графика, #2.2, Информационный зал
Сегодня к интерфейсам мобильных и социальных игр выдвигается множество требований и одно из них — качество их визуальной составляющей. Как сделать интерфейсы красивыми и понятными, как управлять вниманием пользователя и применять знания из смежных областей, как помочь себе и коллегам? Вот темы, которые я хочу раскрыть в докладе.
- Мастер-классы , #2.4, Мастер-классы
Разбор конкретной методики UX Research - «Глубинное UX интервью». Максимум практики с разных сторон. Как вытянуть из слов пользователя "мне это не нравиться" в чем именно расхождение потребности и продукта. И в целом разберем и закрепим на практике подход к одному из основных методов качественные исследования в Customer Research. Будем разбирать примеры разных продуктов от сервисов и игр до магазинов и соц.сетей. Соберем и разберем все ошибки новичка.
- AI, ML, BigData, #2.3, Инженерный зал
В работе предлагается новая латентная модель естественных изображений, которую можно обучать на больших выборках изображений высокого разрешения. Процесс обучения обеспечивает получение латентного представления для каждого изображения из обучающей выборки, а также позволяет построить глубокую сверточную сеть, которая отображает латентное представление в пространство изображений. После обучения новая модель может быть использована как универсальное априорное распределение в пространстве изображений для решения ряда задач восстановления изображений, таких как заполнение пропущенных частей изображения, повышение разрешения, и раскраска.
Для моделирования естественных изображений высокого разрешения наш подход использует латентные пространства очень высокой размерности (на один-два порядка выше, чем предыдущие модели). Для работы с такой высокой размерностью мы используем латентные пространства со специальной структурой многообразий (сверточные многообразия), параметризованные сверточной сетью определенной архитектуры.
В экспериментах мы сравниваем изученные латентные модели с латентными моделями на основе автоэнкодеров, различными вариантами генеративных состязательных сетей и с сильной базовой системой с использованием более простой параметризации латентного пространства. Наша модель превосходит конкурирующие подходы при решении целого ряда задач восстановления.
Для моделирования естественных изображений высокого разрешения наш подход использует латентные пространства очень высокой размерности (на один-два порядка выше, чем предыдущие модели). Для работы с такой высокой размерностью мы используем латентные пространства со специальной структурой многообразий (сверточные многообразия), параметризованные сверточной сетью определенной архитектуры.
В экспериментах мы сравниваем изученные латентные модели с латентными моделями на основе автоэнкодеров, различными вариантами генеративных состязательных сетей и с сильной базовой системой с использованием более простой параметризации латентного пространства. Наша модель превосходит конкурирующие подходы при решении целого ряда задач восстановления.
- AI, ML, BigData, #2.3, Инженерный зал
Соревнование по машинному обучению - крайне уникальное явление. При должном подходе оно позволяет участникам прокачивать определенный набор скиллов за короткое время. А также выводит уровень понимания задач всего комьюнити на новую высоту. В докладе будет рассказано про сам процесс участия, про подходы к решению и отношение к соревнованиям.
- DevOps, # 2.5, Вокальная студия
- Мы — команда Трекера, которая сама использует свой сервис.
Задачи по разработке Трекера ведутся в нём самом, поэтому мы имеем возможность улучшать инструмент и этим улучшать собственные процессы.
- Проблема с “ненастоящим” скрамом: спринты есть, а скрама нет
У нас, как и у многих других, были спринты и встречи, похожие на описанные в Scrum Guide. Но скрам не работал. Расскажу, как мы его настроили.
- Проблема с потерей задач в процессе выполнения
Зачастую наши задачи повисали в промежуточных состояниях, например, в тестировании или "готовности к релизу", но не доезжали до продакшена.
- Организация скрам-команд: как ужиться фронтенду и бекенду? Как разрабатывать и тестировать фичу, затрагивающую несколько компонентов?
Специалисты разных типов должны работать вместе, чтобы выполнить задачу. Кроме того, при разработке могут понадобиться изменения в компонентах с разным релизным циклом: фронтенд, бекенд, библиотеки и т.д. Мы нашли удобное решение этих вопросов.
- Жизнь задачи: Как попасть в продакшен и не заблудиться?
Проблема с "зависшими" задачами и со сложным жизненным циклом решается удобным набором статусов задачи и переходов между ними. Расскажу про наш вариант.
- Организация ревью кода: как распределить задачи по ревьюверам? Что сделать, чтобы ревью заканчивалось в разумное время?
Организация ревью кода это не просто: сроки затягиваются, а разработчики в разной степени склонны проводить ревью. Мы пробовали разные варианты решения и автоматизировали их через Трекер, это помогло решить большую часть проблем.
- Git flow и его настройка под процесс, управление составом релизов, хотфиксы и откаты релизов.
Это может показаться банальным, но git flow действительно работает и приносит пользу. Однако, есть несколько близких вариантов его организации, и какой удобнее использовать — зависит от процессов в команде.
- Поддержка тестирования: Teamcity, docker и тестовые стенды
Teamcity настраивается гибко, а docker удобнее deb-пакетов. Расскажем, как это можно применить для поддержки тестирования.
- Проблемы со сложными релизами в нескольких окружениях, zero downtime релизы.
Каждый релиз каждого компонента должен деплоиться в несколько окружений. Мы научились избегать конфликта версий и не забывать об отдельных частях. И обновляться без перерыва в обслуживании при этом.
- Сервис для релизов и автоматизация
Любую рутину можно автоматизировать. Вот мы и сделали маленький инструмент для поддержки релизного цикла, а интеграция с Трекером позволила встроить его в процесс.
Задачи по разработке Трекера ведутся в нём самом, поэтому мы имеем возможность улучшать инструмент и этим улучшать собственные процессы.
- Проблема с “ненастоящим” скрамом: спринты есть, а скрама нет
У нас, как и у многих других, были спринты и встречи, похожие на описанные в Scrum Guide. Но скрам не работал. Расскажу, как мы его настроили.
- Проблема с потерей задач в процессе выполнения
Зачастую наши задачи повисали в промежуточных состояниях, например, в тестировании или "готовности к релизу", но не доезжали до продакшена.
- Организация скрам-команд: как ужиться фронтенду и бекенду? Как разрабатывать и тестировать фичу, затрагивающую несколько компонентов?
Специалисты разных типов должны работать вместе, чтобы выполнить задачу. Кроме того, при разработке могут понадобиться изменения в компонентах с разным релизным циклом: фронтенд, бекенд, библиотеки и т.д. Мы нашли удобное решение этих вопросов.
- Жизнь задачи: Как попасть в продакшен и не заблудиться?
Проблема с "зависшими" задачами и со сложным жизненным циклом решается удобным набором статусов задачи и переходов между ними. Расскажу про наш вариант.
- Организация ревью кода: как распределить задачи по ревьюверам? Что сделать, чтобы ревью заканчивалось в разумное время?
Организация ревью кода это не просто: сроки затягиваются, а разработчики в разной степени склонны проводить ревью. Мы пробовали разные варианты решения и автоматизировали их через Трекер, это помогло решить большую часть проблем.
- Git flow и его настройка под процесс, управление составом релизов, хотфиксы и откаты релизов.
Это может показаться банальным, но git flow действительно работает и приносит пользу. Однако, есть несколько близких вариантов его организации, и какой удобнее использовать — зависит от процессов в команде.
- Поддержка тестирования: Teamcity, docker и тестовые стенды
Teamcity настраивается гибко, а docker удобнее deb-пакетов. Расскажем, как это можно применить для поддержки тестирования.
- Проблемы со сложными релизами в нескольких окружениях, zero downtime релизы.
Каждый релиз каждого компонента должен деплоиться в несколько окружений. Мы научились избегать конфликта версий и не забывать об отдельных частях. И обновляться без перерыва в обслуживании при этом.
- Сервис для релизов и автоматизация
Любую рутину можно автоматизировать. Вот мы и сделали маленький инструмент для поддержки релизного цикла, а интеграция с Трекером позволила встроить его в процесс.
- Дизайн и компьютерная графика, #2.2, Информационный зал
Как обучаться цифровому рисованию, с чего начать и как не перегореть? В ходе доклада, Елизавета поделится личным опытом преподавания в современных реалиях развития индустрии, а также, расскажет про уникальный подход к обучению в стенах Skills Up School и о перспективах развития студентов.
- Мобильная разработка, # 1.3, Зал Солженицына
За рекордно короткие сроки мы поэтапно соберем рабочий прототип приложения сразу под две платформы. Все это мы сделаем с использованием нового мульти-платформенного фреймворка Flutter.
Что будет:
Немного познакомимся с самим фреймворком и его основными преимуществами
Инициализируем приложение и познакомимся со структурой проекта;
Сверстаем пару экранов;
Анимируем навигацию между этими экранами;
Получим изображение с фронтальной камеры устройства.
Что будет:
Немного познакомимся с самим фреймворком и его основными преимуществами
Инициализируем приложение и познакомимся со структурой проекта;
Сверстаем пару экранов;
Анимируем навигацию между этими экранами;
Получим изображение с фронтальной камеры устройства.
- Дизайн и компьютерная графика, #2.2, Информационный зал
Дизайн интерфейсов - достаточно молодая профессия, но, как и любая другая требует структурированного подхода и понимания основных терминов, процессов и принципов. В этой лекции я расскажу о факторах, влияющих на подход к проектированию и принципах построения интерфейсов.
- Мобильная разработка, # 1.3, Зал Солженицына
В наше время, люди с помощью смартфонов общаются в мессенджерах, сидят в социальных сетях, смотрят фильмы, делают покупки, слушают музыку, занимаются спортом, сидят в интернете и многое другое. Сейчас ещё больше сервисов уходит на мобильные устройства. В связи с этим всё больше становится востребована разработка мобильных приложений. Для их создания существует множество технологий. Чаще всего, когда заходит речь о разработке мобильных приложений силами frontend’а, имеют ввиду React Native. Но помимо этой технологии существуют и другие.
В докладе рассмотрим, какие сейчас есть технологии для мобильной разработки и наглядно сравнить как выглядят и работают идентичные приложения, одно из которых написано на React Native, а другое на Cordova. Определим сильные и слабые стороны каждого из решений.
В докладе рассмотрим, какие сейчас есть технологии для мобильной разработки и наглядно сравнить как выглядят и работают идентичные приложения, одно из которых написано на React Native, а другое на Cordova. Определим сильные и слабые стороны каждого из решений.
- Дизайн и компьютерная графика, #2.2, Информационный зал
Разберу роли UX исследователей и UX проектировщиков в командах и проектах, решаемые задачи и получаемые результаты.
Почему UX дизайнер чуть хуже проводит исследования, чем чистый исследователь, а так же другие расхождения в работе и решениях.
Проанализируем методы UX исследований и проектирования. Как ставить задачу, коммуницировать и принимать работы у исследователей и проектировщиков и как выстраивать этот процесс исполнителю.
Интересные примеры и нюансы из глубинных интервью и принятых из этого проектных решений.
- Мобильная разработка, # 1.3, Зал Солженицына
Несмотря на то, что последние полгода Room кочует из одной версии alpha в другую, разработчики используют эту часть Jetpack очень активно. ORM от Google привлекает их понятной структурой, малым количеством необходимого boilerplate-кода, лёгкими миграциями, простотой тестирования и ещё множеством приятных мелочей.
Если Вы ещё не используете Room в своих проектах, определенно, вам пора начинать! Я расскажу вам, как это сделать, избежав типичных ошибок и получить серьезный профит.
Рассмотрим вопросы:
- как сделать код работы с БД более читаемым и понятным
- как получить привязку выполнения запросов к БД к жизненному циклу Activity и Fragment
- как при этом следовать SOLID без лишних усилий
- как писать и тестировать миграции
Мой доклад рассчитан как на начинающих разработчиков, так и на опытных специалистов, возможно уже использующих Jetpack и модные сейчас coroutines языка Kotlin в своих проектах.
Если Вы ещё не используете Room в своих проектах, определенно, вам пора начинать! Я расскажу вам, как это сделать, избежав типичных ошибок и получить серьезный профит.
Рассмотрим вопросы:
- как сделать код работы с БД более читаемым и понятным
- как получить привязку выполнения запросов к БД к жизненному циклу Activity и Fragment
- как при этом следовать SOLID без лишних усилий
- как писать и тестировать миграции
Мой доклад рассчитан как на начинающих разработчиков, так и на опытных специалистов, возможно уже использующих Jetpack и модные сейчас coroutines языка Kotlin в своих проектах.
- Контроль качества, #1.2, Лермонтовский зал
Скорость и стабильность - вот что важно на текущем этапе развития автотестирования. Особенно когда количество автотестов исчисляется тысячами.
Как же нам сделать здоровыми и быстрыми наши тысячи маленьких и больших автотестов?
Лично мы решили их кормить правильной инфраструктурой из виртуальных *nix серверов, Docker контейнеров, WireMock заглушек, сервисов хранения тестовых данных и наивкуснейшего OpenShift'a.
А за результатами наших автотестов мы попросили проследить наших хороших друзей, таких как InfluxDB и Grafana.
Как же нам сделать здоровыми и быстрыми наши тысячи маленьких и больших автотестов?
Лично мы решили их кормить правильной инфраструктурой из виртуальных *nix серверов, Docker контейнеров, WireMock заглушек, сервисов хранения тестовых данных и наивкуснейшего OpenShift'a.
А за результатами наших автотестов мы попросили проследить наших хороших друзей, таких как InfluxDB и Grafana.
- AI, ML, BigData, #2.3, Инженерный зал
Задачей данного доклада является ознакомление аудитории с базовыми принципами машинного обучения и демонстрации того, что машинное обучение и статистика могут быть применимы к любым областям, в которых происходит сбор данных. Доклад состоит из трех частей:
- в первой части будет рассказано о том, что такое машинное обучение и какое место оно занимает в науке об искусственном интеллекте на примере линейной регрессии;
- во второй части слушатели ознакомятся с классическим А/Б тестированием;
- в третьей части будет представлен реальный пример из опыта работы с сетью розничной торговли, о том как можно использовать машинное обучение для обхода некоторых ограничение фреймворка А/Б тестирования в тестировании гипотез.
- в первой части будет рассказано о том, что такое машинное обучение и какое место оно занимает в науке об искусственном интеллекте на примере линейной регрессии;
- во второй части слушатели ознакомятся с классическим А/Б тестированием;
- в третьей части будет представлен реальный пример из опыта работы с сетью розничной торговли, о том как можно использовать машинное обучение для обхода некоторых ограничение фреймворка А/Б тестирования в тестировании гипотез.
- Java-программирование, #1.1, Конференц-зал
The Java programming language is growing, getting new features every new version. Some of them are coming from a functional programming paradigm, some from procedural one. How does it affect the object-orientation of Java? Do we lose the OO spirit or we gain it? Do we need it in the first place, if everything works just fine without it? I’ll try to analyze the changes Java introduced over the last years, since its version 1.6, and find out which of them are making the language better or worse.
- Контроль качества, #1.2, Лермонтовский зал
Что может быть не так с вёрсткой? Да все, что угодно! Ведь верстка - это не так просто, как кажется: она может не соответствовать макету, кодстайлу, некорректно работать в различных браузерах... А ещё она может ломаться в неожиданных местах. И всего одна строчка css кода может разломать страницу. Поэтому вёрстку необходимо тестировать.
Я расскажу о том, как мы внедряли регрессионное тестирование верстки на стороне фронтенд разработки в команде Mall.my.com (Mail.ru Group), о предпосылках его внедрения, сложностях, с которыми мы столкнулись, и о том, какие проблемы это помогло нам решить.
Также я научу работать с инструментом для тестирования BackstopJS, покажу примеры тестовых сценариев, расскажу, как у нас построен процесс тестирования.
Я расскажу о том, как мы внедряли регрессионное тестирование верстки на стороне фронтенд разработки в команде Mall.my.com (Mail.ru Group), о предпосылках его внедрения, сложностях, с которыми мы столкнулись, и о том, какие проблемы это помогло нам решить.
Также я научу работать с инструментом для тестирования BackstopJS, покажу примеры тестовых сценариев, расскажу, как у нас построен процесс тестирования.
- Контроль качества, #1.2, Лермонтовский зал
Хочу поделиться своим опытом и взглядом на такие ситуации, как
- Вхождение в отрасль. Трудно и страшно? Совсем нет.
- Общение с программистами. Суровые бородатые личности? Неа.
- Карьерный рост. Пришел, увидел, победил - миф? Реальность.
Надеюсь убедить, вдохновить и помочь тем, кто в этом нуждается.
- Вхождение в отрасль. Трудно и страшно? Совсем нет.
- Общение с программистами. Суровые бородатые личности? Неа.
- Карьерный рост. Пришел, увидел, победил - миф? Реальность.
Надеюсь убедить, вдохновить и помочь тем, кто в этом нуждается.
- Управление проектами, #1.1, Конференц-зал
Традиционно считается, что тестирование - это процесс, завершающий разработку и дающий разрешение на отправку продукта конечным пользователем. Такой подход ошибочен и вреден. Почему? Узнаете на докладе.
- Frontend программирование, #1.1, Конференц-зал
Прогрессивные веб-приложения уже получили действительно широкую известность и признание всеми вовлеченными сторонами: разработчиками браузеров (наконец, всеми!), разработчиками, пользователями. Идея приложений, не зависящих от подключения к сети, доказала свою жизнеспособность, и мы видим все больше и больше проектов, идущих по этому пути, что делает возможность работы в офлайне не только лучшей практикой, но просто и хорошей манерой в вебе. В моем докладе, основанном на глубоком исследовании возможностей Service Worker API (с использованием Cache Storage, Background Fetch, Background Sync) и собранных UX-находках, мы рассмотрим историю офлайн веба, важность рассмотрения подключения как привилегии, текущие проблемы (и их решения) и правильные инструменты.
В течение докдада мы спроектируем приложение, готовое к работе офлайн, применяя лучшие технологии и UX-практики и добавляя возможности одна за одной: оболочка приложения, кеширование ресурсов и данных, синхронизация при подключении к сети. Все ради наших пользователей, которые требуют нового уровня отказоустойчивости и скорости работы наших приложений.
В течение докдада мы спроектируем приложение, готовое к работе офлайн, применяя лучшие технологии и UX-практики и добавляя возможности одна за одной: оболочка приложения, кеширование ресурсов и данных, синхронизация при подключении к сети. Все ради наших пользователей, которые требуют нового уровня отказоустойчивости и скорости работы наших приложений.
- Контроль качества, #1.2, Лермонтовский зал
Каждый из нас хоть один раз ленился и ругал себя за это, но лень - это не всегда плохо, особенно, когда в итоге качество вашего продукта становится лучше. Я расскажу, как ленивость тестировщика помогает в развитии качественного продукта, настройки процессов и улучшению взаимоотношений в команде. Поговорим, как улучшить жизнь тестировщиков на проекте, поделюсь опытом и ошибками, которые возникали в процессе моей работы.
- Frontend программирование, #2.1, Губернаторский зал
Вместе с вами мы пройдем путь от простого маленького приложения к сложному и комплексному. Рассмотрим варианты организации кодовой базы. Доставки артефактов. Ответим на вопрос «Да что вообще черт возьми за артефакт?». Ну и попробуем понять когда и зачем нам может понадобиться монорепозиторий.
- Мастер-классы , #2.4, Мастер-классы
На мастер-классе участники смогут создать небольшой навык для голосового помощника Алиса с нуля. Ориентировочная длительность мастер-класса - 6 часов. Язык программирования - Python. Кроме непосредственно написания навыка будет показано как опубликовать его в тестовой среде, а также даны рекомендации по переводу его в продуктивную среду.
- Мастер-классы , #2.4, Мастер-классы
На мастер-классе участники смогут создать небольшой навык для голосового помощника Алиса с нуля. Ориентировочная длительность мастер-класса - 6 часов. Язык программирования - Python. Кроме непосредственно написания навыка будет показано как опубликовать его в тестовой среде, а также даны рекомендации по переводу его в продуктивную среду.
- Мастер-классы , #2.4, Мастер-классы
На мастер-классе участники смогут создать небольшой навык для голосового помощника Алиса с нуля. Ориентировочная длительность мастер-класса - 6 часов. Язык программирования - Python. Кроме непосредственно написания навыка будет показано как опубликовать его в тестовой среде, а также даны рекомендации по переводу его в продуктивную среду.
- Мастер-классы , #2.4, Мастер-классы
На мастер-классе участники смогут создать небольшой навык для голосового помощника Алиса с нуля. Ориентировочная длительность мастер-класса - 6 часов. Язык программирования - Python. Кроме непосредственно написания навыка будет показано как опубликовать его в тестовой среде, а также даны рекомендации по переводу его в продуктивную среду.
- Мобильная разработка, # 1.3, Зал Солженицына
В данном докладе мы познакомимся с возможностями ARKit:
0) Построение объектов 3D примитивами
1) Движение объектов в 3-х мерном пространстве
10) Прикрепление объектов к вертикальным и горизонтальным плоскостям
11) Создание плоскостей и наложение на них медиаконтента
100) Применение
P.S. В виде мастер-класса
0) Построение объектов 3D примитивами
1) Движение объектов в 3-х мерном пространстве
10) Прикрепление объектов к вертикальным и горизонтальным плоскостям
11) Создание плоскостей и наложение на них медиаконтента
100) Применение
P.S. В виде мастер-класса
- Frontend программирование, #2.1, Губернаторский зал
В докладе рассматриваются два основных способа создания компонентов на ReactJS (классы и функции) с точки зрения организации командной разработки коммерческого веб-приложения. Сравнивая оба подхода, мы разберёмся зачем нужен выбор единообразного способа создания компонентов, когда это необходимо и как убедить команду следовать правилам. Рассмотрим, как на этот выбор может повлиять активное распространение React Hooks.
- Frontend программирование, #2.1, Губернаторский зал
Все знают, что игры в браузере - это WebGL. С наскока эту технологию не взять, она выглядит так, будто она прилетела в веб с другой планеты. Стандарту уже почти 9 лет, а специалистов в нем крайне мало.
Разберемся, как рисовать 2D быстро, но просто, на примере написания игр, не забивая голову матрицами и сложным API. В докладе рассматриваются концепции пререндеринга, шейдеров и использования React-дерева для быстрого рисования на плоскости.
Разберемся, как рисовать 2D быстро, но просто, на примере написания игр, не забивая голову матрицами и сложным API. В докладе рассматриваются концепции пререндеринга, шейдеров и использования React-дерева для быстрого рисования на плоскости.
- AI, ML, BigData, #2.3, Инженерный зал
Хочу поделиться опытом разработки приложений на Spark в контексте Data Engineering.
Тема, которую я представлю на докладе - это реальный проект, разработкой которого я занимался.
Пример будет состоять из чтения данных из Kafka, обработки с помощью Spark Structured Streaming (включая stateful трансформации) и записи результатов в HDFS.
Также расскажу нюансы по деплою проекта (Yarn, HDFS, Apache Oozie).
Примеры будут на понятном для большинства слушателей подмножестве языка Scala (без монадных трансформеров и прочей живности).
Тема, которую я представлю на докладе - это реальный проект, разработкой которого я занимался.
Пример будет состоять из чтения данных из Kafka, обработки с помощью Spark Structured Streaming (включая stateful трансформации) и записи результатов в HDFS.
Также расскажу нюансы по деплою проекта (Yarn, HDFS, Apache Oozie).
Примеры будут на понятном для большинства слушателей подмножестве языка Scala (без монадных трансформеров и прочей живности).
- Контроль качества, #1.2, Лермонтовский зал
В больших проектах невозможно уследить абсолютно за всем, к тому же регрессионное тестирование очень утомляет, на помощь приходит автоматизация. Но и здесь остаётся много подводных камней: где запускать автотесты, когда, как формировать отчёты.
Система управления тестированием TestRail имеет возможности написания и хранения кейсов, а также объединения их в раны, плюс генерация сводных отчётов по проведенному тестированию.
Любые проекты и тесты будут храниться в Gitlab и запускаться в CI, а красивые репорты отправляться всем желающим. Таким образом, на выходе получаем универсальный подход к любым проектам.
Система управления тестированием TestRail имеет возможности написания и хранения кейсов, а также объединения их в раны, плюс генерация сводных отчётов по проведенному тестированию.
Любые проекты и тесты будут храниться в Gitlab и запускаться в CI, а красивые репорты отправляться всем желающим. Таким образом, на выходе получаем универсальный подход к любым проектам.
- Frontend программирование, #2.1, Губернаторский зал
Обсудим методологии Test-Driven Development и Behavior-driven development. Как мы это применяем в жизни, но почему-то не используем в разработке. На самом деле это стоит попробовать каждому, а те, кому это понравится, получат гору экспы и профита.
Попов Сергей Генеральный директор аутсорса по фронтенд-разработке Лига А., Лига А. / HTML Academy, Санкт-Петербург
- Frontend программирование, #2.1, Губернаторский зал
Доступность, валидность, базовые принципы — вещи, без которых нельзя запускать в продакшен ни один сайт. Раньше приходилось собирать информацию об этом по крупицам, использовать сложные решения для тестирования. А сейчас всё это собрано в одном инструменте, который встроен непосредственно в браузер! Как после этого вообще можно совершать ошибки? Мы либо не умеем им пользоваться, либо не хотим. Этот доклад для первых.