WWDC 2016, отчет и впечатления

В апреле 2016 года я впервые выиграл лотерею для покупки билета на конференцию. В этом отчете опишу события происходящие на конференции и личные впечатления.

Что такое WWDC

World Wide Develop Conference — всемирная ежегодная конференция для разработчиков, где Apple представляет новые технологии и изменения в платформы. Участники общаются с инженерами Apple и слушают доклады на технические темы. Продолжительность 5 дней, 5000 участников.

Впервые WWDC состоялась в городе Монтерей в 1983 году. С 1988 года по 2002 проходила в Сан Хосе, с 2003 по 2016 в Сан Франциско.

Регистрация на лотерею

В 2014 году, из-за большого количества желающих купить билет, Apple ввели лотерею на покупку.

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

Розыгрыш билетов

Apple утверждает, что билеты распределяются случайным образом, но исходя из количества участников из разных стран, это кажется не точным. Возможно, розыгрыш происходит по странам среди поданных заявок по заданной квоте. Большинство программ разработчика зарегистрировано в США и при действительно случайном распределении из других стран попасть на конференцию было бы почти невозможно. Косвенно, это доказывается тем, что программой разработчика из Украины выигрываю второй раз подряд.

WWDC приложение

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

Воскресенье, получения пропуска

Организатор указывает, что пропуск можно получить в воскресенье в Bill Graham Center. Отстояв довольно небольшую очередь, я получил пластиковый пропуск и фирменную куртку. Рекомендую не откладывать регистрацию до понедельника, так как очередь в этот день минимальна.

Понедельник, Keynote, Platform of the Union и Design Awards.

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

После, снова вышли на площадь перед зданием, где выдавали обеды и напитки.

В 14:00 снова зашли для просмотра Platform of the Union. Зная, какая очередь ведёт на первый этаж, мне удалось попасть на второй ряд под сценой.

Design award получали разрабочики и участники scholarship.

Вторник/Пятница

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

В пятницу короткий день, доклады только до 14:00. Видно, что участников стало значительно меньше. Многие уходят раньше.

Bash party

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

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

Cocoapods, коммитить или нет?

cocoa-pods

На сегодняшний день использование менеджера зависимостей cocoapods для ios проектов фактически является стандартом. В этой записи не будем рассматривать использование Carthage, git modules или совсем уж рагульский вариант вброса библиотек в проект вручную.

Итак зададим главный вопрос: Коммитить ли Pods папку в репозиторий? И постараемся на него ответить максимально аргументировано, дабы закрыть его навсегда.

Что бы знать куда бежим, надо определить конечную точку. Зачем мы используем менеджер зависимостей?

  • Не собирать библиотеки в проект в ручном режиме
  • Не собирать зависимости в проект в ручном режиме библиотек
  • Не решать в ручном режиме проблемы совместимости различных зависимостей
  • Иметь общее хранилище спецификаций на доступные библиотеки

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

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

Что будет если коммитить только Podfile + Podfile.lock?

Плюсы

  • Наш репозиторий содержит только наш код
  • Merge измений в Podfile гараздо проще, чем merge Pods папки (некоторые утверждают 😉

Минусы

  • Так как центральный репозиторий содержит ТОЛЬКО описание и ссылку на сам код библиотек, вероятен черный лебедь, что сама библиотека будет не доступна на момент pod install.
  • Если не указывать версию используемой зависимости, то при выходе свежей версии, можем получить нерабочий код. С проектами на objc, такие проблемы могут проявляться в рантайм, что делает их сложно выявляемыми. Решается коммитом Podfile.lock.
  • Фактически не компилирующийся код в репозитории. Испраляется костылями в виде скриптов для сборки
  • Нельзя собрать проект если нет cocoapods, который не поставляется ни с системой, ни с Xcode

Вывод: Как решение экономии времени не подходит, цель исключительно лежит в developer value, но не business value. Так как в некоторых случаях (и не нами контролируемых) мы получаем проект, где пропадает чужой репозиторий с библиотекой и мы затратим время на его восстановление. Единственный устойчивый случай, если вы контролируете исходники библиотек или делаете fork всем используемым библиотекам.

Чтоб будет если коммитить Pods папку в репозиторий?

Плюсы

  • Гарантия, что проект всегда будет собираться и работать у всех одинаково
  • Проект атомарен, собирается даже если в системе нет cocoapods (клиенты, CI)
  • Нет проблем с явными/скрытыми несовместимостями при соборке/выполнении

Минусы

  • Дополнительная папка Pods и увеличенный размер репозитория
  • Возможные проблемы при merge Pods папки

Выводы: Экономия времени, так как больше никаким образом не тратиться время на библиотеки в ущерб размеру репозитория. Совпадает с изначально поставленной задачей.

Что говорит моя практика?

  • У нас было пару случаев, когда пропадали зависимости с чужих github репозиториев. Да, проблема была решена поиском форков. Остался осадочек и нежелание тратить время в будущем
  • Единственный раз была проблема с коммитом Pods с yandex maps SDK, где скомпиленная либа не «влазила» в репо по лимитам бесплатного аккаунта
  • В 80% Pods содержит только исходники и вес в среднем в больших проектах ~50 MB
  • Часто клиент собирает проект из репозитория, но не все могут поставить cocoapods
  • Было пару случаев, когда я не смог собрать заранее склоненный проект зарание в поезде из-за отсутствия интернета
  • Merge совместных обновлений папки Pods прост как лом. Просто удаляется папка и заново делается pod install с правильными версиями библиотек. Результат коммититься в репо. Плюс, сразу обращаешь внимание на совместимость со своим кодом.
  • Больше 100 наших проектов содержат Pods папку и это дает только положительные результаты.

Спонсором написания выступило бамболео у Josser’а. Готов послушать аргументацию при использования Cocoapods, а не «у них такая же нога и совсем не болит» для NPM, Gems и иже с ними.

– Господин редактор, вы не скажете, что в городе происходит?

Оливье доедено, последние остатки спиртного выпиты из домашней чашки, дом убран, а новогодний мусор давно запакован и вынесен. Город неспешно погрузился в уютные, как домашние тапки, первые выходные в новом году. Это время остаться наедине с собой, и не просто «собой», а «нооооовым собой». По сюжету в этот момент необходимо достать ручку и записную книжку, и найдя чистую страницу, озаглавить ее «План на 2013 год». Потом задумчиво посмотреть и начать рисовать каракули вместо первого пункта…

Не стоит марать бумагу, необходимо просто действовать. Как например Дима, взять и пробежать 21 километр или как Серега написать новый пост.

Ну что ж не буду тянуть и в который раз «перезагружу» блог и пойду писать pet project.