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

Поиск по тегам:

General

1. Знакомство с Китаем: как иностранные приложения чувствуют себя на китайском рынке.
2. Перспективы развития приложений на рынке страны, полезные секреты-плюшки для разработчиков.
3. Что придется преодолеть для покорения рынка Поднебесной.
4. Методология вывода мобильного приложения в КНР, как все сделать без ошибок.

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

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

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

Теперь это всеобщая тема — любой ux/ui дизайнер и менеджер апеллирует к закону Миллера из далекого 1956 года, стараясь упростить интерфейс. Но мало кто помнит, что же еще было в том классической статье и почему все не совсем так. Разберемся в мелочах, истории и в том, как этот закон правильно трактовать и использовать.

1 Эволюция. Как в целом работает наша память и память других приматов. Почему у нас именная такая оперативная память? Человек тут не венец природы. Обезьяны запоминают лучше. Почему?

2 Information foraging theory. Теория говорит нам, что человек в поиске информации ведет себя так же, как собиратели в поисках еды в саванне прошлого. Затраты энергии, cчитываемость маркеов и понятность. Вспомним еще более старое Hick-Hyman Law.

3 Кластеризация. Человек не цифровая машина, мы работаем иначе. Изменять в битах запоминаемое не совсем верно. Тем более мы очень хорошо обожаем, работаем со структурой. Разбивание и структурирование помогает усложнить систему не нарушая закон Миллере.

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

5 Шум. Человек, не смотря на невероятную информационная перегрузку все еще считает себя многозадачным. Вспомним эксперимент Дэниэла Сименса с гориллой. Как экономить когнитивный ресурс.

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

Все чаще разработчики интегрируют в свои приложения подписочную модель монетизации, а API In-App Purchases все также оставляет желать лучшего даже спустя годы. И если с локальной верификацией чеков и подписок все более менее известно, минное поле пройдено, фреймворки написаны, то о взаимодействии между клиентом и сервером информации пока маловато. Какие баги есть на стороне Apple? Как обойти те или иные ошибки? С какими корнер-кейсами можно столкнуться при проектировании системы? На эти вопросы мы и постараемся ответить в своем докладе, осветив вопрос со стороны iOS и Бэкенда. Мы расскажем о том как работать с чеками на стороне бэкенда, что может пойти не так и какие "сюрпризы" может преподнести Apple. А на стороне клиента расскажем какие существуют корнер-кейсы, что делать если Apple и Бэкенд "не договорились" и предоставить пользователю максимально качественный UX.

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

Технологии развиваются бурными темпами. То что вы использовали вчера, уже сегодня может никому не пригодиться. Вспомните сколько раз за 5 лет у вас менялись технологии и библиотеки в рамках одного и того же фреймворка. Как эффективно развиваться, получать новые знания и не перегореть? Автор Telegram канала Android Broadcast поделится своим опытом и даст советы как увеличить эффективность обучения

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

Технологии iOS

На WWDC’19 Apple представила технологию Mac Catalyst, которая позволит “быстро и просто” создавать приложения под macOS на основе Ваших iPad-приложений. Сразу после анонса мы решили попробовать запустить наше приложение Abbyy Business Card Reader на Mac и посмотреть, чего нам это будет стоить.
(спойлер: 2 недели стажера, топорный дизайн и отрубленные фреймворки)

В докладе мы сравним ожидания и реальность использования технологии Mac Catalyst и подробно рассмотрим основные трудности, с которыми Вы можете столкнуться при портировании приложения под macOS. Также сделаем небольшой обзор того, как и зачем разработчики из других IT-компаний проводят аналогичные эксперименты с Mac Catalyst. И более того, расскажем и покажем(!), что у нас в итоге получилось, и зачем мы вообще затеяли эту историю.

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

В 2020 году на сессии WWDC Apple представила доработанную версию своего фреймворка SwiftUI, предлагающего новый подход к реализации UI без InterfaceBuilder и AutoLayout. Однако, несмотря на свою заявленную готовность к использованию в бою, работа с данной технологией требует знания ряда нюансов и узких мест, решение которых может оказаться не простым и не быстрым. Одним из таких важных моментов является реализация полноценной навигации в приложении SwiftUI.

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

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

Знали ли Вы что тип Observable в RxSwift не несет в себе никакой информации о синхронности доставки событий и их scheduling'е? А также, тот факт, что имплементации многих операторов в RxSwift опираются на постоянную работу с RecursiveLock, что замедляет и утяжеляет код? Вы когда-либо хотели увидеть как можно имплементировать Reactive Extensions не опираясь на объектно-ориентированное программирование? Можете не искать дальше - это доклад для Вас!

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

Простота прекрасна, мы используем понятные для нас концепции, создаем на их основе свои компоненты, чтобы возводить на них грандиозные проекты. Однако, данный доклад не о простоте, нам предстоит разобраться в деталях. Этим докладом я начну демистификацию абстракций, к которым мы так привыкли, а именно о взаимоотношениях атомарности и Swift.
Apple рекомендуют синхронизацию при помощи GCD потоков, все что можно найти про многопоточность в iOS упирается в использование высокоуровневых функций GCD, доступные примитивы синхронизации импортируются из C, реализация lock free алгоритмов остается прерогативой C подобных языков на платформах Apple. Давайте раскроем тему Атомарности, избегаемую в iOS сообществе, посмотрим как это работает на самом деле и рассмотрим перспективы Swift в этом направлении.

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

Первое, что бросается в глаза разработчику, решившего попробовать на зуб фреймворк SwiftUI, это новый подход к реализации UI без InterfaceBuilder и AutoLayout.
Декларативный конструктор ViewBuilder – это мощный инструмент SwiftUI, который самостоятельно располагает и настраивает визуальные элементы интерфейса, делая большую часть действий за разработчика. Более того, он позволяет при необходимости не ограничиваться реализацией по умолчанию, а создавать что-то свое собственное.

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

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

Полгода назад мы в Delivery Club начали работу над новой вертикалью: Grocery - доставка продуктов. На тот момент наш iOS-проект представлял из себя монолит из legacy на Objective-C, что не позволяло беспрепятственно ввести новый flow. Хаотично переписывая и вынося модули, понимая всю боль связанного кода, мы вводили строгие правила для каждого решения. Набивая шишки о собственные грабли, мы смогли найти такие подходы, которые оказались надёжными и гибкими. Теперь наш проект состоит из 30+ модулей на Swift и имеет утверждённую архитектуру на каждом слое.

Мой доклад про best practice в iOS-приложениях. В нём не будет сравнений подходов, а только набор лаконичных решений, позволяющих сделать проект гибким и понятным. Я расскажу про наш опыт: что позволило новым сотрудникам быстро войти в проект, а затем легко запустить нашу следующую вертикаль.

В докладе рассмотрим
• построение модулей в иерархию в соответствии с Clean Architecture;
• перестройку навигации на Coordinator, проблемы с ним и как быть с таб-баром;
• разбиение сущностей репозиториев, менеджеров и сервисов для удобного тестирования;
• архитектуру экрана на VIP и вёрстки на коллекциях с кастомными layouts в pixel-perfect;
• системы собеседований, онбординга и адаптации при быстром росте команды на фоне изоляции;
• работу нескольких команд в одном проекте, систем ревью и релизов с feature toggles.

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

Сложные разнородные ленты, например, корзина в интернет магазине может оказаться очень сложной в разработке: много состояний, связей между компонентами и много логики в целом. В докладе я представлю своё видение того, как можно все это упорядочить и добиться архитектурой стройности экрана несмотря на его сложность. А поможет мне в этом Combine ;)

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

Кросс-платформенная разработка

Многие годы специализация macOS-developer была чем-то особенным и требовала изучения кучи специфичных фреймворков, которые к тому же ещё и толком не обновлялись. Но осенью 2019 всё изменилось: Apple представила широкой общественности Mac Catalyst, развитие проекта Marzipan, о котором многие слышали, но практически никто не видел. Теперь у каждого iOS-разработчика появилась возможность портировать своё мобильное приложение на macOS буквально одной галочкой в настройках проекта.
Но так ли всё красиво, как заявляет стартовая страница гайда от Apple? Давайте разберёмся на примере (почти) реального production-приложения.

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

Архитектура

Мы проводим очень много A/B тестов. Я расскажу, с какими трудностями можно столкнуться при проектировании архитектуры A/B тестов, что стоит учесть, и как достичь удобства использования A/B тестов в большом проекте.

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

Процессы разработки

Доклад о том, как мы сократили время, затрачиваемое на настройку CI/CD в 4 раза и заменили 14 действий в 5 инструментах для выпуска новых сборок всего одной консольной командой. В докладе будет произведено сравнение Jenkins и GitLab CI, а так же обзор Fastlane и конечной реализации CI/CD процесса в Redmadrobot. Доклад будет полезен, как новичкам, которые не знают как и зачем настраивать CI/CD, так и опытным специалистам.

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

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

Кроме прозрачности процессов мы получили прирост эффективности в среднем на 13 500 рублей в месяц в команде из 9 человек. В докладе расскажу о том, как перестраивались инструменты и люди.

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

Технологии Android

- Почему измерение скорости билда важно
- Подробный разбор программы для измерения скорости билда gradle-profiler
- Краткий обзор статистических методов для анализа полученных результатов
- Практические примеры использования профайлера времени сборки в Сбербанке

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

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

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

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

Как использовать все возможности системы уведомлений по максимум? Как сделать уведомления на каждой версии ОС использовать возможности по максимуму? NotificationCompat не решит все за вас. Давайте разбираться!

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

Kotlin Coroutine поменяли асинхронную работу и уже стали рекомендация для асинхронных операций в Android от Google. В ходе доклада мы взглянем на призму архитектуры Android приложений через призму Coroutine, изучив как концепции асинхронного подхода из Kotlin прекрасно решают задачи UI приложений. В ходе доклада мы разберем ценность Coroutine, Structured Concurrency, Flow и почему они должны быть в вашем следующем Android проекте.

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

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

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

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

В докладе будут рассмотрены ограничения, которые могут нам помешать выполнить какую-либо задачу в фоне, а также инструменты, которые помогают эти ограничения обходить. Мы рассмотрим как эти инструменты эволюционировали, какие ограничения появлялись в разных версиях Android и как их можно обойти на текущий момент. Познакомимся с новыми ограничениями, которые были введены в последних версиях Android и узнаем как они могут повлиять на работу приложения. В частности будут рассмотрены: Doze Mode, App Standby Mode, Service launch from background, Activity launch from background, App Buckets, Services, JobScheduler, AlarmManager, WorkManager, Location.

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

В докладе рассмотрим, как сделать дизайн-систему в проекте с большим количеством кода, команд и легаси. Как программистам и дизайнерам разговаривать на одном языке? Разберёмся в инструментах для стандартизации UI в Android, поговорим о нюансах и неочевидных моментах.

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