WWDC 2014: Философия вместо “золотой формулы”

Создателей первого iPhone мучили сомнения. Даже когда все стало складываться очень неплохо, когда его показ был встречен овациями и он стал главной темой СМИ, сомнения не оставляли их ни на минуту. Яркий взлет, минута (или две) славы и восторга и… пшик. Судьба большинства сенсаций, в том числе и в мире цифровых искусств. Помните NeXTcube? Помните iCube? Уроки судьбы обошлись Стиву очень дорого, но если бы не они судьба iPhone могла быть именно такой.

Одним из открытий Стива стала “золотая формула”, определяющая идеальные размеры мобильного устройства с тач-интерфейсом на основании размеров и физиологических свойств человеческой ладони.

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

Формула продержалась до iPhone 4s, потом ей пришлось изменить. То что пришло ей на смену и дебютировало вместе с iPhone 5, назовем “серебряной формулой”. Она прожила еще меньше, и подтвердила неготовность действующей философии к еще более другим размерам.

Представляете как были счастливы iOS-разработчики когда им пришлось переделывать приложения, которые, с верой в обещания Apple, размеры экранов считали константой. И задавали координаты экранных элементов напрямую, числами. До iPhone 4s это работало. Адский ад, скрежет зубовный, стоны. Было.

Среда разработки была разработана с учетом “золотой формулы”. То есть, к изменениям размеров устройств она не была приспособлена вообще. У iPad была своя формула, почти не связанная с формулой для iPhone. Вместо того чтобы автоматически перераспределять экранные элементы в отведенном им пространстве, нужно было разрабатывать интерфейс для iPhone и iPad раздельно.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно;
Четвертая часть: WWDC 2014: Swift;
Пятая часть: WWDC 2014: Непрерывность (Continuity);
Шестая часть: WWDC 2014: Чистилище отменяется.

Жизнь и смерть золотой формулы

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

Но океан бушующих эмоций (публика) все настойчивее требовал устройств с большими размерами экранов, а конкуренты с радостью шли публике навстречу. В 2013 году стало ясно, что даже от “серебряной формулы” придется отказаться. В конце концов, она хоть и наследие Джобса, но не догма.

А чтобы не повторять адский ад и скрежет зубовный, а теперь должна была измениться не только высота (в “портретной” ориентации), но сразу всё, да еще и в двух вариантах, пути отхода с занимаемых позиций начали готовить заранее. Весной или летом 2013 года.

Перед Люком Хистерманом, инженерным менеджером проекта, поставили задачу: “лучшее сохранить, негативные последствия минимизировать, превратить iOS-интерфейс в самый адаптивный интерфейс в отрасли”. Задачи не имеющие решения – это именно то, зачем эти психи (инженеры Apple) шли работать в компанию. 2 июня 2014 года, во второй половине дня, то что у них получилось было впервые представлено участникам WWDC 2014.

Затем, в подробностях, с примерами, тайны “новой философии” раскрыли перед ними на десятке сессий посвященных Adaptability (адаптивности, способности приспосабливаться). На смену золотой и серебряной формулам в iOS 8 пришла философия адаптивности, из-за чего Люк Хистерман сравнил масштаб изменений в iOS 8 SDK с масштабом создания SDK в 2008 году.

По закону эволюции

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

И сколь бы не были мощны динозавры, царившие на планете сотни миллионов лет, закон эволюции не пощадил даже их.

Узнав про заявление Люка Хистермана, эксперты посчитали показателем масштаба iOS 8 числа: 4000 новых API (рекордно много), и едва ли не еще большее число API объявленных в iOS 8 устаревшими (еще один рекорд). Но Люк имел в виду именно изменение философии SDK, смещение акцентов и наступление новой эпохи в истории iOS.

Но Стива не было. Никто ничего публике не объяснил.

Все уже было

Задолго до iOS 8, программные средства для реагирования на изменение размеров уже работали в Android и Windows Phone. Число размеров устройств на этих платформах уже давно превысило все мыслимые пределы. Клиентам это нравилось, они за это платили, и в 2014 или 2015, добираясь на работу (а в метро что-то случилось, сгорели какие-то кабели, и ехать пришлось в битком набитом 27 троллейбусе) мужик напротив меня прижимал к уху устройство размером с малую саперную лопату, и сообщал начальнику что задержится.

Рука у него была огромная, но даже для него, как мне показалось, этот трюк легким не был. Но его лицо светилось от гордости за себя и за своего цифрового друга.

А чтобы облегчить жизнь разработчикам, экранные элементы на таких устройствах просто отодвигались друг от друга.

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

Первой реакцией на Adaptability со стороны экспертов с “другой стороны” были вовсе не обвинения Apple в воровстве. Они поражались сложности придуманного, предсказывали неработоспособность подобной системы. Почти не ошиблись – проблем было много.

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

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

Технические подробности про Adaptability я отложил на будущее. Когда-нибудь, когда дойдут руки, я о них напишу. Когда – не знаю.

Продолжение следует

WWDC 2014: Чистилище отменяется

Все легальные iOS-приложения, прежде чем попасть на полки App Store, прошли через iTunes Connect (iTC). С 2008 по 2014 года iTC был настоящим чистилищем. Медлительный, неудобный, бестолковый и невероятно неэстетичный интерфейс. Изменений уже даже не ждали. Их устали ждать. И вдруг, в июне 2014 году, все изменилось. Про прежний iTC никто и никогда не сказал ни одного доброго слова. Неудивительно. Ваяли его в страшной спешке, явно не мастера, дизайном интерфейсов не занимался никто, и нетрудно понятно почему. У создателей App Store и его инфраструктуры были куда более важные задачи, выполнить любую из них хуже чем идеально было бы просто бессмысленно – а времени не было совсем.

Решение опубликовать iPhone SDK и создать App Store было спонтанным и неожиданным. Все это нужно было делать года на два или на три раньше. Планомерно и с умом. Хотели ведь как лучше.

iTC не устраивал не только его пользователей, никто не любит публиковать уродливые вещи – но когда вся эта спешка будет позади и напряжение спадет, за него собирались взяться всерьез.

Прикинули нагрузку на разрабатываемую инфраструктуру. На основании объёма продаж и учитывая рост спроса на iPhone из-за сторонних приложений. На всякий случай, решили ориентироваться на еще большую нагрузку – на всякий случай. Времени конструировать что-то сложное и масштабируемое не было. Решились рискнуть.

Несколько месяцев App Store работал в отладочном режиме. Нагрузку ограничивали, в iOS Developer Program регистрировали только тех кто постоянно жил в США, и многим из них тоже отказали, предложив попытаться еще раз, когда закончится отладка. О работавших “по ту сторону” процесса узнать как все это было не удалось (молчат), но проблем было много, часто вся эта затея висела на волоске. Немного осталось, можно потерпеть.

А как только комплекс App Store — iTC — Портал разработчиков заработал в полную силу, нагрузка на него немедленно превысила ожидаемую, и продолжила расти, с ускорением.

Создатели iPhone и App Store, похоже, доигрались и запустили цепную реакцию ужасной мощи и неизвестной природы. Опять было не до интерфейса, iTC оброс заплатками как днище ракушками – и исправить ситуацию могла только разработка его с нуля. Заплатки плодились, аврал не кончался, казалось что так будет всегда. К нему привыкли.

И вдруг, в июне 2014, Apple показала радикально обновленный iTC. Даже публике. Совсем другой – живой и удобный. Участникам конференции его представили в подробностях, чем вызвали восторг и овации. Все это было здорово, но пугало: что случилось? Поток иссяк? В чем подвох?

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

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно;
Четвертая часть: WWDC 2014: Swift;
Пятая часть: WWDC 2014: Непрерывность (Continuity).

Интерфейс

В загадочном последнем номере журнала develop (он существовал только в электронной форме, пришел вместе с рассылкой “для служебного пользования”, я его читал и вот уже не одно десятилетие (!) не могу найти, была отличная статья про UI (User Interface). Автор писал: “интерфейс плохой если он заставляет умных людей чувствовать себя идиотами”.

И иллюстрировал свою мысль убедительными примерами. А вот их я не помню.

В старом iTC интерфейс мог добавить в тот список еще несколько примеров, но как вы уже поняли, им просто никто всерьез не занимался. Теперь интерфейс был. Под капотом тоже все изменилось – независимо от нагрузки (она продолжала расти, никакого спада и близко не было) теперь все работало. Как если бы это web-приложение было написано для самых обычных пользователей, приносящих компании прибыль. А если подумать, так оно и было.

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

Связки приложений, аналитика и “чего изволите?”

В 2010 или 2011 один из проектов умер не начавшись: клиенту требовалось не одно iOS-приложение, а несколько. В его целевой аудитории были пользователи нескольких типов, двух или трех – для каждого из них требовался свой набор. Старые солдатские способы (приобретать в App Store требуемые наборы вручную, реализовать наборы функций в виде приложений и тому подобное) клиента не устраивали.

В iTC 2010 года связки из нескольких приложений не поддерживались, следовательно их не могло быть и в App Store. В iTunes Connect образца 2014 года это стало возможно.

Технический менеджер проекта iTC Дейв ван Тассел с явным удовольствием показывал как это делается. До 10 приложений (из одного аккаунта, прошедших проверку в App Store) теперь можно было объединить в bundle, переведу это как “связка”.

Процесс создания связки запускался “нажатием” кнопки “New Bundle”. Разработчики iTC явно не читали Apple Human Interface Guidelines, или не знали что “New” – не глагол. Это я ворчу. Кнопка – это действие, действие это глагол. Вообще-то требование разумное.

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

Расположение приложений в списке менялось перетаскиванием. Надо же, UI в iTC!

У связки было собственное имя, своя цена (меньшая чем суммарная цена компонентов), а устанавливались приложения связки одновременно, в одно касание.

Прошедшее время я использую из-за того, что рассказываю про iTC 2014 года. В данном случае подошло бы и настоящее, в большинстве случаев.

До TestFlight

О том что такое бета-тестирование (тестирование бета-версий), рассказывать не буду. Это то, чего в принципе не может быть слишком много.

До 2014 года организовать бета-тестирование iOS-приложений было сложновато.

Если у вас одно или два приложения, а в команде разработчиков человек десять (вместе с начальником и штатными тестировщиками), особых проблем не возникало. iOS-устройства участников разработки вносились в список – тестируемое приложение устанавливалось только на устройства указанные в списке. Устанавливалось вручную. Не обходилось без любимых в народе плясок с бубном, но в основном все было достаточно просто.

Устройства всех тестировщиков извне тоже должны были включаться в этот список. Для этого тестировщик должен был прислать UDID (уникальный идентификатор) устройств на которых он собирается тестировать приложение, которые включались в список, для всех из них в iTC генерировались provision profiles, и вместе с инструкцией о том что и как надо сделать для их установки, отсылались тестировщику.

В список могло быть внесено только 100 устройств. При удалении записи из списка место, которое она занимала, продолжало считаться занятым. Освободить список от удаленных записей можно было один раз в год. После очередной оплаты членства в iOS Development Program, но до первого внесения в этот список новой записи. Жестко?

Если у вас десятки проектов, 30 человек (50 устройств), а заказчики каждого из проектов вместо двух-трех UDID (как бы их не просили) присылают по пять-шесть – как быть?

Выкручивались. Содержали несколько аккаунтов (99 долларов в год за каждый, плюс куча логистических сложностей) – нужда заставит и не так раскорячишься.

Происхождение TestFlight

В начале 2014 году Apple приобрела компанию Burstly, производившую в том числе и TestFlight, приложение для iOS и Android облегчавшее бета-тестирование, вместе с персоналом.

Приложение TestFlight было размещено в App Store и Google Play в конце декабря 2010 года. Разработали его Тристан Козминка и Бенджамин Сэттерфилд. Приложение и всю инфраструктуру необходимую для его работы в 2012 году приобрела компания Burstly.

А в начале 2014 года Apple выбрала именно их (на рынок подобные продукты поставляли сотни компаний, это был очень востребованный товар), закрыла все проекты для Android, и проекты TestPath (аналитика) и SkyRocket (управление монетизацией мобильных проектов).

Команде из Burstly поручили разработку (с нуля) нового iTC. Тристану Козминка поручили разработку App Analytics, техническим менеджером команды стал выходец из Burstly Дейв ван Тассел.

Сумма за которую Apple приобрела Burstly неизвестна. Скорее всего миллионов за десять долларов – в 2013 компания “стоила” 7,3 миллиона.

То есть, Apple (как всегда) украла эту программу. За деньги. Кроме шуток, их обвиняли в этом. Никому не рассказывайте о том, что вы постоянно, крадете продукты из магазинов, оставляя взамен презренные деньги. Я знаю что вы это делаете. Я и сам не без греха.

TestFlight в iTC

В июне 2014 года Apple объявила TestFlight. Это iOS-приложение, работающее в тесном взаимодействии с iTunes Connect. iOS-приложение, как и организация бета-тестирования, бесплатны.

Для добавления бета-тестировщика обмен UDID и Provision Profile больше не требовался. Все что для этого требовалось – адрес электронной почты тестировщика.

Отправлять релизы вручную тоже больше не требовалось. Их получала и устанавливала на устройства (на столько устройств, сколько нужно – ограничивалось число тестировщиков, не устройств) программа TestFlight.

Ограничения? Опять?

С точки зрения TestFlight, тестировщики делились на две категории: на внутренних (тех кто внесен в список аккаунта iTC), до 25 человек; и внешних, число которых в 2014 году было ограничено одной тысячью.

Внутреннее тестирование можно было начинать сразу, зарегистрировав приложение как бета-версию на iTC. Для внешнего тестирования требовалось пройти проверку, такую же какая необходима для размещения в App Store. Это несколько дней, возможен отказ, всё такое – но такова жизнь.

Сервис в iTC отвечавший за тестирование отслеживал действия тестеров: получили ли приглашение, активировали ли его, установили ли приложение и запускали ли его вообще.

В 2014 число внешних бета-тестировщиков ограничили 1000 человек, затем увеличили его до 2000, в настоящее время их число выросло до 10 000.

На одном аккаунте можно одновременно тестировать до 100 приложений. Есть и другие ограничения, но о них читайте в документации.

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате.

WWDC 2014: Непрерывность (Continuity)

Семь лет, начиная с 2007, когда вышел самый первый iPhone, Apple трогательно гордилась взаимной интеграцией её платформ. Объявляя недостатки в этой интеграции частностями, и объясняя их требованиями безопасности. В 2014, представив Continuity, компания молча признала своё отставание в этой области. Признала и исправила, интегрировав между собой все устройства типа Mac, iPhone и iPad с одним и тем же аккаунтом в iCloud (то есть, с одним и тем же Apple ID). От интегрируемых устройств требовалась поддержка Bluetooth 4.0, и нахождение в одной и той же сети WiFi.

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

Использовал Mac для ответа на телефонные звонки, начав почтовое сообщение на Mac’е дописывал его на iPad’е, который использовал для ответа на SMS. Теперь (после выхода в свет iOS 8 и Mac OS 10.10) такими фокусами смогут поражать все обладатели Mac’ов и iOS-устройств, совместимых с этими системами.

Объединить все его устройства в магическую непрерывность было легко. Даже еще легче. Правда ни в системных настройках обеих систем не было (и нет) раздела “Continuity”, и все что нужно включить на устройстве для этого надо было откуда-то узнать. Почему?

Continuity это не технология, это комплекс из четырех технологий, одну из которых можно считать за две. Ну и что? А операционная система – это тысячи технологий. Операционная система первого Mac’а именно этим и завоевала сердца пользователей: она первой из (ну второй – после Lisa OS) убирала подобные сложности с их пути.

Ни Стив, ни Скотт Форстолл, скорее всего, не остановились бы на технической стороне дела (непрерывность работала безупречно). Это я ворчу. Никто не знает как все было бы если бы все было не так как оно было…

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно;
Четвертая часть: WWDC 2014: Swift.

Аппаратно-Программный Комплекс “Непрерывность”

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

Комплекс – это четыре технологии:

— Handoff, то что позволяло Крейгу начав ввод какого-то текста на одном устройстве легко и просто (как будто так и надо) продолжать его на другом. А при необходимости еще и на третьем, четвертом, потом снова на первом. Программисты могли внедрить Handoff в свои программы, это было несложно;

— Call Relay и SMS/MMS Relay: это реквизит для фокусов с телефонными звонками (Call Relay) и с SMS/MMS;

— Instant Hotspot: почти то же самое что обычный Hotspot, превращающий iOS-устройство в беспроводной модем для Mac’ов, но обеспечивающий подключение к сотовой сети для всех Mac’ов включенных в Continuity;

— AirDrop: новая версия AirDrop, делающая возможным передачу данных между Mac’ами и iOS-устройствами. Но только “для своих”. Подробнее о ней поговорим чуть позже.

Основа всех этих фокусов – iCloud. Необходимые для них магические ингредиенты или входят в состав Mac’ов и iOS-устройств, поддерживающих Continuity, или устанавливаются на них при установке Mac OS 10.10 (и выше) или iOS 8 (и выше).

Пользователю остается включить элементы комплекса в нескольких разных местах, и все.

AirDrop

Технология AirDrop позволяет обмениваться данными между близко расположенными устройствам без подключения к общей сети. Apple запатентовала эту технологию в 2011 году, она впервые была использована в Mac OS 10.7 Lion.

Её не нужно искать в системных настройках (она всегда на виду, в списке фаворитов в каждом окне Finder’а), о том как ей пользоваться можно догадаться – всё очевидно. Для работы ей нужен Bluetooth. Если у пользователя Mac спроектированный для работы в системе образования, велика вероятность что Bluetooth он не поддерживает.

На таких компьютерах AirDrop не следует включать в список фаворитов. Это же Mac! Но, по-моему, от разработчиков никто уже не требует учитывать такие мелочи.

Apple постоянно объявляет себя самой передовой компанией в мире. Недоброжелатели называют её безнадежно отсталой. Истина где-то посередине. Подобные технологии стали появляться примерно в то же время, в 2010-2011 годах.

В окне AirDrop можно согласиться на прием данных от этого сервиса, здесь же список доступных получателей – все остальное элементарно.

В 2013 AirDrop появился и в iOS (в революционной iOS 7). Замечательно – вот только Mac’и могли обмениваться данными только с с Mac’ами, а iOS-устройства – только с такими же iOS-устройствами как они. Протоколы AirDrop в OS X и iOS были разными.

В 2014 AirDrop объявили частью Continuity. Рассказывая про Continuity, сообщили о том что протоколы AirDrop стали универсальными – и что обмен данными между Mac’ами и iOS-устройствами теперь возможен. Очень хорошая новость.

Я только не до конца понял при чем тут Continuity. Протоколы AirDrop были унифицированы в обеих системах 2014 года, в OS X Yosemite и в iOS 8. Обмен данными работал в точности как раньше, просто теперь в списке получателей были и Mac’и и iOS-устройства.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

WWDC 2014: история появления Swift

Главное событие пресс-конференции по случаю открытия WWDC 2014 года случилось в самом её конце. Ему уделили совсем немного времени. Крис Латнер, умеющий захватить внимание аудитории и делать с ней все что захочет, был скован и непохож на себя. И тем не менее, WWDC 2014 вошла в историю как “WWDC на которой был представлен Swift”. Новый язык программирования, название которого переводится просто и без затей как “Стриж”, пришел на смену Objective-C.

26 лет этот язык использовался в NeXTSTEP и во всех наследниках этой системы (Mac OS X, iOS, GnuStep, tvOS), стал одним из самых популярных языков в мире, а по моему мнению он был (есть?) лучшим из лучших. Я не могу быть объективным, с 2001 по 2016 Objective-C был моим основным языком программирования. До него были ObjectPascal и C++.

Все остальное, объявленное и представленное на той пресс-конференции (новые версии OS X, iOS и Xcode, и даже Metal) произвело значительно более слабый эффект.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно.

Раскол

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

В исходных кодах библиотек iOS и OS X десятки (если не сотни) миллионов строк кода на Objective-C. Переписать их на Swift в ближайшие лет десять-двадцать было нереально, тем более переписать по-умному, чтобы не утратить что-то важное и приобрести что-то очень важное и нужное.

Даже если бы Apple удалось идеально надстроить существенно другой по своей природе язык над всеми этими миллионами строк, проблемы были бы неизбежны. А сложное никто и никогда не делает идеально.

Что до самого языка, то сначала он мне очень не понравился. Скачав книгу про Swift (это шедевр технической документации, без капли иронии), и открыв её в первый раз, я увидел что-то вроде let aNumber = 42. Как в самых древних вариантах Basic’а! Отсталых уже тогда, когда я их изучал, лет за 20 до конца предыдущего тысячелетия. Оператор присваивания в них выглядел именно так, почти в точности (примерно так: LET ANUMBER = 42).

Я плюнул и закрыл эту электронную книгу. Возвратившись с работы и преодолев себя, я приступил к чтению. Оказалось что “let” в Swift имеет вполне достойное предназначение, но язык мне активно не нравился.

Строгий контроль за типами данных, сплошные “нельзя” и “обязательно” – это же кошмар, правда? Идея с optionals интересна, но как-то все непривычно. Не по-людски! А мне с ним жить.

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

Смелые обещания

Публике Swift представили как Objective-C без C. Будто бы из-за этого освоить его будет легче. Молодёжь к нему потянется, и напишет шедевры невероятной мощи. Стоп…

Человек, который не способен освоить C, может быть гением в любой области, но шедевр программистского искусства он не напишет никогда. Это не его.

К счастью, это всего лишь маркетинговый лозунг. C в Swift’е присутствует на каждом шагу, это C-подобный язык. Хотя собственно C, как отдельной сущности, в нем действительно нет.

Swift сконструирован по-умному, в нем предусмотрено многое из того о чем раньше никто не заботился. Язык очень предсказуем, безопасен, многие из самых типичных ошибок в нем физически невозможны – но вообще-то он сложнее чем C. В нем очень много правил о которых надо откуда-то узнать.

Современный, быстрый, компактный, продуманный, безопасный – пожалуй, эти обещания в новом языке были выполнены, с самого начала.

Но в то что Swift, с первого его дня, станет “гражданином первого сорта” в iOS и OS X я не поверил. В этом направлении Apple им команда Латнера сделали очень многое, возможное и невозможное, и даже (забегая вперед, в 2014 году об этом еще никто не знал) несколько раз все это переделали, улучшив и углУбив.

Некоторые из этих улучшений понравились мне даже больше чем сам Swift. Вы видели CoreGraphics в варианте для Swift, и другие библиотеки в оригинале написанные на C?

Когда системы хотя бы наполовину будут написаны на Swift, тогда это обещание будет исполнено.

Порадовало что никто не пообещал что даже самые-самые альтернативно одаренные товарищи смогут без труда писать в Swift отличный “софт”. Увы. Ни один язык в мире не гарантирует от ужасных программ.

Обещания (их было дюжины полторы) были “придуманы” в маркетинговой службе, со слов инженеров и менеджеров знавших про Swift и языки программирования не понаслышке. Их общение, скорее всего, было нервным – но продуктивным.

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

Swift 1.0

При всех его удивительных качествах, первый Swift был очень сырым, многое в нем вело себя не так как обещала Книга (бесплатная, отлично написанная, книга про Swift).

Согласно теории Жана-Поля Гассé, любое сложное техническое изделие (компьютер, программа, операционная система, графический или центральный процессор) не может “состояться” раньше чем в третьей его версии.

Теория работает не всегда: процессоры от Apple “состоялись” уже в первой их версии, в той которая называлась Swift (это Apple A6 и Apple A6X), а Cyclone (центральный процессор в Apple A7) уже просто громил конкурентов. Были и обратные примеры (но о грустном не буду).

Swift-который-язык состоялся именно в третьей версии.

Когда Крис ушел из Apple, самым главным в проекте Swift стал Тед Кременек, один из тех кто придумал, продумал и сделал реальностью это язык. Мне показалось что чуду пришел конец – но, судя по нынешней версии языка, я ошибался.

А какой язык лучше – Swift или Kotlin или современный C++?

Джеф Раскин говорил что сравнивать сложные сущности на лучше/хуже также нелепо как сравнивать точки на плоскости на больше/меньше. Джеф говорил много разных вещей. С очень многими его утверждениями я не согласен – но не с этим.

Про сам язык не пишу – о нем столько всего уже написано.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

WWDC 2014: Metal – это очень серьезно

Внимательно выслушав и прочитав все, что было сказано и написано на металлическую тему представителями Apple, лучшие из аналитиков пришли к единственно правильному выводу: Metal для iOS 8 и Apple A7 – это разведка боем. Что-то значительно более важное не заставит себя ждать. Apple решила взять под свой полный контроль еще одно тонкое место во всех её системах, тщательно взвесив все “за” и “против”. Уровень секретности был таким же, как при Стиве: не случилось ни одной утечки. Затея была очень рискованной.

Согласятся ли компании разрабатывающие программы зависящие от OpenGL и/или OpenCL для разных платформ, включая iOS и OS X? Некоторые из этих программ были очень важны для Apple. Доля Apple в доходах этих компаний хоть и была существенной, но её потеря их существованию не угрожала.

Что они предпочтут: тратить деньги на разработку в нестандартных API или потерять часть дохода? Пока не попробуешь – не узнаешь. И лучше всего двигаться к этому потихоньку, чтобы можно было вовремя притормозить, если что-то пойдет не так.

В 2014 не все согласились с лучшими из аналитиков. Многие не воспринимали это всерьез. Более важное случилось в июне 2018 года – но это пока не наша тема.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D.

Кризис

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

Производительность графических процессоров (GPU), год за годом, росла значительно быстрее чем производительность центральных процессоров (CPU) – отвечающих за все. В итоге, в отношениях между CPU и GPU сложилась революционная ситуация: верхи не могли (справиться), низы не хотели (думать самостоятельно, потому что не могли).

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

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

Графическая мощь требовалась и серьезным специалистам, но сколько их таких?

К середине первого десятилетия XXI века центральные процессоры (CPU) уже не могли в полной мере использовать мощь GPU. С такой же проблемой столкнулись авиационные оружейники когда сверхзвуковые скорости стали обычным явлением – все происходило настолько быстро что экипаж физически не успевал оценить обстановку и прицелиться.

Теперь в роли людей оказались CPU. Теперь они не могли одновременно “пилотировать” логику игры, готовить и проверять запредельно точные команды и отображать результаты на экране.

Приплыли?

Метод Apple

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

Что-то вроде этого они делают постоянно, это суть их метода.

Первый Mac был абсолютно невозможен: у него были неплохие тактико-технические характеристики для своего времени, но только на реализацию главной его “фишки” – того самого графического пользовательского интерфейса – их требовалось в разы больше чем у него было.

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

Первый iPhone был абсолютно невозможен, но они его сделали, таким же способом.

Использовать мощь GPU хотя бы наполовину было невозможно, но они научились делать это. Отношения CPU и GPU – невероятно сложная область человеческого знания. Потоки, конвейеры, шейдеры, ускорители, рендеринг – об этом написано множество толстых книг, перед прочтением которых нужно прочитать много-много других книг, а чтобы понять их…

Но то как они это сделали раскрывает суть их метода ярче и понятнее чем всё остальное.

Диагноз

Взаимодействием между CPU и GPU занимался “переводчик”, действия которого были далеки от оптимальных. Переводчиком был OpenGL. Язык, которому в 2014 было уже 25 лет (как WWDC по версии Apple), универсальный, поддерживающий все достойные этого платформы и все заслуживающие этого графические процессоры – от новейших с их почти термоядерной мощью до самых архаичных, из прошлого тысячелетия.

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

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

Естественно, OpenGL не был оптимален ни на одной из платформ где он использовался, он был компромиссным решением. То есть, тем самым “тонким местом”, где хронический по своей сути конфликт обострялся и наносил ощутимый ущерб.

Для большей ясности (которая, как говорил настоящий Мюллер, одна из форм полного тумана), исследуем взаимодействие CPU с GPU на примере типичной “стрелялки”. Игра – это какая-то логика, герои с какими-то свойствами, ландшафт, оружие и тому подобные виртуальные реалии. Это область отвественности CPU.

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

Эти указания готовит CPU. OpenGL, каждый раз заново, должен отрисовать все объекты которые должны появиться на экране. Указать их “физические” свойства (цвет, материал), определиться с источником или источниками света, перепроверить “шейдеры” (небольшие функции выполняемые GPU) управляющие тенями, отражениями и массой других вещей, и возможно, преобразовать их исходные коды в команды для GPU.

В том что все это делается снова и снова, есть смысл. Если поддерживаются платформы с самыми разными “странностями”, графические процессоры с разными возможностями.

1/30 секунды для современных CPU – это уйма времени. Но даже в сильно сокращенном виде комплекс действий по отрисовке единственного экрана впечатляет. На самом деле от CPU требуется на порядок или два больше действий. Результат: GPU терпеливо ждет, пока CPU подготовит все что нужно, стремительно исполняет новые указания, и снова ждет.

1/30 секунды часто оказывается недостаточно. Игра тормозит, хотя GPU самый-самый, на котором можно было бы кипятить чайники (если бы не системы охлаждения).

Рецепт от Apple (“варим” Metal)

Во-первых, нужно сконцентрироваться на одном-единственном GPU. На том который встроен в Apple A7, PowerVR G6430 в 4-кластерной конфигурации. На острие главного удара. Остальное (пока) игнорируем.

Во-вторых, пишем “переводчика” с чистого листа, как если бы никаких OpenGL никогда не было (но отлично помним обо всем, чего хотелось бы избежать).

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

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

Это если коротко.

И на этом месте Стив сказал бы “бум” – в некоторых случаях производительность связки CPU и GPU вырастала в 10 раз. Правда никто и ни разу не продемонстрировал подобные случаи, но ускорение в 5-6 раз случалось сплошь и рядом.

Ну приврали (слегка) маркетологи, у них работа такая.

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

На WWDC 2014 показали Zen Garden. На Apple A7, если использовать общепринятый OpenGL, показанное было бы абсолютно нереально.

И все это только для Apple A7 c PowerVR G6430 в 4-кластерной конфигурации? Не похоже ли это на абсолютную и непростительную глупость, за которую всем (даже непричастным) не может не быть стыдно?

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

Это было только начало. Metal смог заменить OpenGL (и ни в чем не виноватый OpenCL, который просто попал под руку) сначала в одной конкретной комбинации (iOS 8 и Apple A7), затем в еще одной, затем…

Другие причины создания Metal

Даже если бы Apple несла ущерб от неспособности OpenGL качественно выполнять его долг до 2009 или 2010 года, отказываться от него Apple не стала бы. Это было бы ошибкой, которая могла обернуться гибелью компании.

До мобильной революции Apple слишком сильно зависела от готовности разработчиков со стороны переносить известные на более распространенных платформах программы в OS X.

Теперь компания одним из лидеров рынка мобильных устройств, временами абсолютным лидером.

А успех с организацией разработки собственных процессоров (CPU и систем-на-чипе с их участием) добавил им уверенности в себе.

И кроме всего прочего, если вы еще не пробовали программировать в Metal – попробуйте! Это очень красиво. OpenGL на фоне Metal выглядит как биржевые сводки за прошлый год на фоне блестящей захватывающей прозы.

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате. Там и про Metal много.

WWDC 2014: Вспоминая QuickDraw 3D

Может показаться что попытки разработать собственный процессор в 80-е и создать свою технологию 3D-графики в 90-е – явления одного порядка. А в новом веке Apple наступила на те же грабли, но с совершенно другим результатом. Так ли это? На пресс-конференции по случаю открытия WWDC 2014 Apple представила Metal, скромно и почти оправдываясь: OpenGL мешает разработчикам игр для iOS реализовывать полет их фантазии, и вот – Metal. В ряде случаев он оказывается в 10 раз эффективнее чем OpenGL, он менее требователен к ресурсам, в iOS он и в самом деле уместнее чем OpenGL ES. И ни слова про QuickDraw 3D.

Я ни разу не эксперт по 3D-графике, но в начале нулевых в нескольких “эпизодах” одного из проектов живая трехмерная графика просто напрашивалась. Того же эффекта можно было добиться с помощью заранее нарисованных картинок – но их требовалось слишком много. И я попробовал.

В предисловии одного из учебников по регулярным выражениям (Regular Expressions, они же RegExp, а не то что некоторые могли бы подумать) было замечательное утверждение: “если вы не владеете RegExp и у вас проблема которую нужно решать с их помощью, то у вас уже две проблемы”.

Про OpenGL можно сказать то же самое. Как и про многие другие “палочки-выручалочки”. Проект завершился преждевременно, по независящем от разработчиков причинам, весь мой опыт в OpenGL – месяца полтора ученичества, в свободное от основной работы время. Что-то стало получаться, но экспертом я не стал.

Тогда же я обнаружил и “третью проблему” – Quesa. Проект с открытым исходным кодом, почти полностью повторяющий QD3D (это сокращение от QuickDraw 3D, если кто не понял), написанный той же командой что создавала его в Apple. “Доморощенная 3D-графика”, как ни странно, на фоне OpenGL смотрелась как Mac на фоне PC.

Quesa (как и QD3D) во многом уступала OpenGL, но не фатально – все это было устранимо и решаемо. А её достоинства были уникальны. Про QD3D обязательно надо вспомнить.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC.

1999

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

На январском MacWorld 1999 года Apple официально и окончательно поставила крест на QuickDraw 3D и его низкоуровневой составляющей RAVE (это Renderer Acceleration Virtual Engine, что-то вроде OpenGL): в Mac OS X эти технологии не войдут.

“Используйте OpenGL” – сказал Стив.

Решение было встречено аплодисментами: программисты, особенно те кто писал игры, от QuickDraw 3D были не в восторге. OpenGL уже считался стандартом 3D-графики на всех заслуживающих внимания платформах, доля рынка у Apple Computer была ничтожной, и даже если бы возможности QD3D на игровом поле были сопоставимы с возможностями OpenGL, желающих изучать еще одну нетривиальную технологию было бы немного.

Для написания игр QD3D не подходил. Его техническое задание преследовало иные цели, необходимая для игр скорость отрисовки оказалась в самом конце списка приоритетов.

Разработчики QD3D были уволены, а их детище, в которое они вложили душу и лучшие годы жизни, остались собственностью Apple. Исходный код в том числе. Столько всего осталось нереализованным! Обычная история, увы.

Летом 1999 года на свет появился проект с открытым исходным кодом Quesa (есть такой город в Валенсии), организованный бывшими разработчиками QuickDraw 3D. В проекте не было ни единой строчки из запретного для них QuickDraw 3D, но оригиналу он ни в чем не уступал. Такое тоже случается, но очень нечасто. Значит, что-то во всем этом было.

Проект Quesa тихо скончался в 2008 году. Если у вас другие сведения – пишите.

1995

Разработку QuickDraw 3D (тогда еще не имевшего названия) поручили подразделению QuickTime. Целью проекта было создание 3D-технологии, позволяющей промышленным программистам включать в программы для обычных компьютеров (не для рабочих станций) трехмерные интерфейсные элементы.

В группе продвинутых технологий (ATG) работали над концепцией 3-мерного интерфейса. О чем-то похожем писал в своих работах Джеф Раскин, идея носилась в воздухе – в ATG её попытались воплотить, и обнаружили что ни PHIGS (Programmer’s Hierarchical Interactive Graphics Standard), ни OpenGL (возможно, в то время еще Iris GL, разработка компании Silicon Graphics), с массовыми компьютерами начала 90-х несовместимы в принципе.

Когда-нибудь (например, с 4-ядерным RISC-процессором от Apple внутри) и у компьютеров для обычных Mac’овских пользователей появятся такие возможности, но мир нужно было поразить здесь и сейчас.

Кроме того, Apple Computer с восторгом тратила деньги. 3-мерный интерфейс – это очень впечатляюще. А нестандартно мыслящие и талантливые (что не одно и то же) инженеры вставали в очередь у дверей отдела кадров компании, и им было из кого выбирать. Так или иначе, на MacWorld 1995 года компания представила первую версию 3D-графики своей собственной разработки.

Как и убийству QuickDraw 3D в 1999 году, в 1995 его рождению устроили овацию.

Заслуживал ли этот проект случившегося с ним?

Обзорная экскурсия

QuickDraw 3D состоял из двух частей, верхнего (собственно QD3D) и нижнего уровня (RAVE). QD3D – это объектно-ориентированные API, организованные эргономично и даже элегантно, написанные на “чистом” C. Вы считаете что на C это невозможно? Вы не совсем правы, но спорить не буду. Пусть API будут объектно-ориентированными “псевдо”.

Уступая по тактико-техническим данным главному конкуренту (в 1995 OpenGL уже стал этим “главным конкурентом”), QD3D на голову превосходил его по простоте и легкости использования. Хороший программист, без ущерба для сроков, мог использовать QD3D и добиваться впечатляющих результатов.

Забавно: OpenGL, хулиганский и бунтарский проект Silicon Graphics, уступал прежнему лидеру в области 3D-графики PHIGS именно в этом. В 1995 с победы OpenGL над PHIGS прошло всего года три, и об этом еще очень хорошо помнили.

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

Гордо – но глупо. Гордость и глупость гораздо чаще идут рука об руку, чем считается. Но не будем отвлекаться.

О том что QD3D – кросс-платформенный продукт, почти никто не знал. О том что несмотря на простую для понимания и достаточно удобную для применения внешность QD3D еще и бесконечно изменяем – тоже.

Кто-то что-то писал, в каких-то СМИ – но вот маркетинговая машина Apple участия в этом не принимала.

Между тем это было абсолютной правдой. Собственно QuickDraw 3D был интерфейсом к низкоуровневому движку RAVE. При переносе на другие платформы перерабатывать надо было только движок.

Все, чем прославился OpenGL (загадочность, сложность, отсутствие ограничений) в RAVE было. Расширения добавленные в RAVE становились доступны на “верхнем этаже”, легко и просто. Достаточно большие компании с повышенными 3-мерными требованиями запросто могли найти персонал способный работать с RAVE, но об этом мало кто догадывался.

Если бы на развитие RAVE был реальный спрос, даже больная на всю голову Apple (в 1995-96 компания была опасно больна, это факт) не могла не отреагировать на это.

Судьба QuickDraw 3D вполне могла быть иной.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

WWDC 2014: по версии Apple, 25-я WWDC

Пресс-конференция по случаю открытия “25-й” WWDC (конференции!) отвечала неписаным канонам. В прошлом веке считалось что объявлять на этом ежегодном мероприятии какое-либо “железо” неуместно. Так оно и было, но без металла все-таки не обошлось. Кроме видео-инсталляции про разработчиков в самом начале, отторжения конференция не вызывала. Темы, качество изложения, изысканный фирменный юмор, тонкий вкус. Крейг и Грег (Джосвяк) сыграли на отлично.

Пересказывать пресс-конференцию нет смысла. Вот видеозапись (продолжительностью в 01:57:58):

Mac OS 10.10 (Yosemite), iOS 8, Swift (который язык), и Metal. Тот самый, который “убийца OpenGL и OpenCL”. Пока еще скромная технология в составе iOS 8, “для Apple A7”, но уже заслуживающая самого пристального внимания.

У Apple уже был QuickDraw 3D в середине 90-х, безумный, красивый и многообещающий конкурент Open GL. Объектно-ориентированные API, элегантный и удобный интерфейс, но доля рынка у Apple была ничтожной, она быстро сокращалась – у QuickDraw 3D не было ни малейшего шанса. Теоретически, QD3D обладал фантастическими способностями. Но для их воплощения в реальность требовались оптимизированные под QD3D драйверы, писать которые никто не собирался.

В 1999 году Apple Computer окончательно и бесповоротно отправила QD3D в отставку, его место в Mac OS X занял Open GL. QuickDraw 3D превратился в Quesa, проект с открытым исходным кодом, но… это уже совсем другая история.

Лотерея

В 2008 году, впервые в истории WWDC, все билеты на конференцию были проданы за три недели до завершения продаж. Об этом, с нескрываемым удовольствием, написали все СМИ относящиеся к Apple с симпатией. Можно ли было представить себе что-то подобное всего за десять лет до этого?

Участие в WWDC дело затратное. Билет стоит 1 599 долларов. Даже если участник живет в США, перемещение в Сан-Франциско и неделя в отеле обойдутся в копеечку. Это доступ к информации из первых рук, общение с инженерами компании, с коллегами со всего мира, возможность решить нерешаемые проблемы в своём коде (силами инженеров Apple!). Это кому-то нужно?

Судя по тому что в 2008 году спрос превысил предложение, да.

При этом, начиная c 2003 года Apple уже проводила WWDC в Moscone West, крупнейшем конференц-центре на Западном побережье США. Теперь даже он не мог вместить всех кто считал необходимым для себя принять участие в конференции.

Дальше ситуация только ухудшалась. Побочный эффект вызванный этим дефицитом – бум в строительной индустрии в Калифорнии. В реконструкцию конференц-центра в Сан-Хосе, где с 1988 по 2002 год проводились WWDC, были вложены дополнительные средства.

Обратите внимание на “1988” – это официальные данные. WWDC 1988 года проводилась в Сан-Хосе.

Но реконструкция – дело долгое. В 2011 году билеты были распроданы за 12 часов. В 2012 за 2 часа. В 2013 – меньше чем за три минуты. Граждане пошустрее не упустили свой шанс подзаработать скупая и перепродавая (в два-три раза дороже) билеты на WWDC, не будь их “достижения” Apple выглядели бы поскромнее – но даже за четыре с половиной тысячи все билеты раскупались.

Подобная спекуляция не противоречит закону штата Калифорния. Неэтично, некрасиво – но законно. Несправедливо. Участие в WWDC – важный ресурс для разработчика, который невозможно переоценить. То есть, поскольку “хватать и не пускать” нельзя, остается лишь смириться и терпеливо ждать завершения реконструкции конференц-центра в Сан-Хосе, в начале 2017 года?

3 апреля 2014 года Apple распространила пресс-релиз, суть которого “яблочные” СМИ тут же разнесли по всему миру. Решение было найдено. Любой участник платных программ Apple для разработчиков (официально зарегистрированный разработчик), Начиная с 3 апреля и до 10 утра по летнему тихоокеанскому времени 7 апреля, мог оставить заявку на специально отведенной для этого страничке на сайте Apple. Бесплатно.

7 апреля состоялся розыгрыш. Выигравшие получали право заплатить 1 599 долларов и принять участие в WWDC. Две трети заявок оказались проигрышными – но зато все было по честному. Подтверждено независимыми аудиторами. Бывает и такое!

Это еще не все: пользуясь случаем, Apple выделила 200 бесплатных мест для учащейся молодежи, женщин-программистов. Самому младшему участнику WWDC 2014 было 13 лет.

Аналогичным образом поступила и Google, вроде бы пришедшая к похожему решению одновременно с Apple, и разыгравшая билеты на участие в Google I/O, событии прошедшем в 20-х числах июня 2014 года. WWDC 2014 открывалась 2 июня 2014 года. Даже если кто-то из них позаимствовал эту идею у другого, ничего плохого в этом не вижу.

Интересно, за какое время были бы распроданы билеты на WWDC на этот раз?

Хронология (новая?)

По версии Apple, первая WWDC случилась в 1989 году: 1 200 сторонних разработчиков из нескольких стран мира были приглашены на презентацию System 7. Вступительное слово Джона Скалли, подписка о неразглашении, несколько детальных и совершенно секретных “сессий” посвященных разным аспектам операционной системы ближайшего будущего.

Про это событие информации у меня немного. В 1991 один из его участников подарил мне набор CD с материалами конференции. Несколько Гигабайт информации, невероятный для того времени объём. Про саму конференцию мне тоже что-то рассказывали, но я ничего не помню.

System 7 становилась реальностью, мне предстояло в ней программировать, своего CD-привода у меня не было – а информации был вагон и маленькая тележка, и все было очень важным и ценным.

О конференциях разработчиков до 1995 года почти ничего неизвестно. Только о двух из них – о той что состоялась в Монтерее (Калифорния) осенью 1983 года, и о конференции 1987 года (один из участников которой оставил воспоминания). Для себя, я считаю что они начались в 1983, но настаивать на этом я не буду.

Если глава Apple считает что первой Apple WWDC было событие 1990 года, значит так оно и было. Будем считать что конференции 1983 и 1987 годов не были WWDC – тем более что до 1995 года они даже назывались иначе.

Раз душа просит праздника, пусть будет юбилей. Кстати, если принять конференцию 1989 года за точку отсчета, WWDC 2019 – тридцатая. С юбилеем!

Подробности?

Многие из тем пресс-конференции заслуживают более детального рассмотрения. И мы этим обязательно займемся. Поэтому…

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате.

WWDC 2011: Про убийство и другие события

О том, что Apple убивает файловую систему, ссылаясь на слова самого Джобса, написали самые разные издания. Даже такие авторитетные, как Los Angeles Times. Будто бы в Apple уже давно испытывали к жертве неприязнь, и мечтали убрать её с пути… Вот эти слова Джобса: “Мы давно мечтали убрать с пути пользователя файловую систему, и теперь мы это сделали”. Внимательно прочитайте еще раз, если вы не поняли, зачем я их привел.

Даже если вы не имеете никакого отношения к следственным органам, и не прочитали за свою жизнь ни одного детектива, вы наверняка обратили внимание на некоторые детали. Если вы не возражаете, жертву этого убийства я буду обозначать инициалами. Ф.С., то есть “Файловая Система”.

Стив действительно признался в том, что в Apple хотели “убрать Ф.С. с пути”, но только не со своего пути, а с пути пользователя. В повествовании появляется еще один персонаж, но обозначать его инициалом мы не будем – при всей его важности для создателей программ и компьютеров для их исполнения, как только они его не называли. В том числе и букву П.

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

А сама Ф.С., кстати, через почти десять лет после её убийства, жива и более или менее здорова, в macOS, в iOS, и даже в остальных xxxOS…

Это продолжение серии про WWDC 2011, предыдущие части здесь:

Первая часть: WWDC 2011: Apple уходит на облака….

Она существует!

Среди пользователей iOS, в течение долгих лет, бытовало представление о том что в ней вообще нет никакой файловой системы. Есть только программы, сообщения, и картинки, есть какая-то загадочная песочница, которая как-то образом связана с безопасностью данных – но никаких файлов, директорий (или папок) нет.

И соответственно, нет никакой файловой системы. Где она? Покажите!

Потому что на “батуте” (программа, которая рисует на экране иконки приложений, папки и прочие сущности интерфейса iOS, называется SpingBoard, сама она невидима) есть только программы.

Проекты систем без системы (файловой) время от времени возникают на пространстве Интернета, но все они либо откровенный бред, либо иносказание: файловая система в них все-таки предполагается, но пользователь заботливо изолирован от неё.

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

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

Файловая система в iOS есть. Такая же, как в OS X, где большая её часть тоже спрятана от обычного пользователя, для его же блага.

А в iOS абсолютно все файлы и директории спрятаны от пользователя. В поздних версиях появилась программа “Файлы”, потому что совсем без файловой оказалось… даже еще хуже, чем с ними. А где файлы, там появляется и файловая система.

При чем тут iCloud?

Что они (Apple) сделали, чтобы убрать файловую систему с пути пользователя? В OS X Lion в этом великом избавлении участвовал не только iCloud.

Launchpad был едва ли не самым эффективным средством избавления. В связке с Mac App Store, он брал на себя заботы о всем цикле жизни приложения, от приобретения до смерти (удаления), включая обнаружение, запуск и обновления. Это аналог не менее тесной связки SpingBoard и App Store в iOS.

Но Launchpad с Mac App Store упрощают использование программ, а в OS X, о ужас, есть и просто файлы: контакты, сообщения электронной почты, картинки, видео, документы Word или Numbers.

До iCloud во всех (в большинстве) реализаций облачных технологий облако было всего лишь еще одним “диском”, размещавшимся где-то за пределами осязаемого мира. iCloud тоже размещает данные где-то, на одной из серверных ферм Apple (сегодня их десятки, в разных странах мира).

Почти все приложения для iOS (и очень многие приложения для OS X) задолго до iCloud уже использовали, по сути, облачные технологии – перекладывая на сервер часть задач, сохраняя на нем важные данные, используя сервер для координации действий.

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

Сообщения электронной почты (для аккаунтов “@me.com”), контакты, приобретенные в iTunes, iBook или App Store приложения, документы iWorks (Pages, Numbers и Keynote), и некоторые другие данные моментально (как правило) моментально появлялись на всех подключенных к аккаунту устройствах.

Без настроек и без освоения чего-либо, легко и непринужденно. Некоторые из них вообще бесплатно, другие, пока объем “платных” данных не превышал 5 Гигабайт, тоже бесплатно.

Со временем появилась возможность увеличения доступного пространства, за ежегодную плату (небольшую).

Для подключения к iCloud применялся Apple ID, идентификатор который привязан к адресу электронной почты, несложно было завести себе альтернативные хранилища в количестве, ограниченном только количеством адресов электронной почты (хоть миллиард!). Это менее удобно, магии становится меньше – зато Гигабайт на облаке может быть больше в разы.

Компьютеры перестали быть основной цифровой жизни (по мнению Apple), и все слабее подходили на роль “цифрового хаба”. То есть, центра цифровой жизни.

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

Это очень многое, но это – все. Параноидальные размышления о контроле Apple за всеми пользователями macOS и iOS параноидальны.

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате.

WWDC 2011: Apple уходит на облака…

6 июня 2011 года Apple объявила “облачную платформу iCloud”. Мало кто из слушателей остался равнодушным. Стив рассказал про iCloud поэтично и понятно, чтобы даже самые одаренные все поняли. Они все поняли, но по своему – и мало не показалось… Времена изменились. Еще совсем недавно (десять с небольшим лет назад) Apple была на самом краю забвения, рекламные щиты про “Поколение Next” на каждом шагу не имели никакого отношения ни к NeXT, ни к Apple, но воспринимались как “из Pepsi возникший, в Pepsi и уйдешь” – потому что эти щиты были рекламой Pepsi, а с 1983 по 1993 во главе Apple Computer был Джон Скалли, до того – самый молодой вице-президент Pepsi.

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

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

Времена изменились. С некоторых пор именно Apple стала мейнстримом из мейнстримов, и толпа (сущность неодушевленная и лишенная разума) с восторгом потребляла миллионы изделий этой компании, объявляла их модными и штурмовала прилавки с новинками.

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

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

Keynote (разновидность пресс-конференций) по поводу открытия очередной всемирной конференции разработчиков провел Стив. То, во что он их превращал, отличалось от общепринятого настолько, что в начале нулевых их стали называть stevenote (стивноут).

Это был последний стивноут…

Главной темой WWDC 2011 была “платформа iCloud”?

Облачные технологии iCloud, названные Стивом “новой платформой”, не требовали от обывателя никаких осмысленных действий. Главная её магия, синхронизация, от него никак не зависела. Она просто была и просто работала.

Магия активировалась вводом Apple ID и связанного с ним пароля либо в ответ на запрос одной из поддерживающих её систем, или в настройках такой системы. Если Apple ID еще не было, его стоило получить для получения своей доли чудес.

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

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

Но пресс-конференция в первый день WWDC и собственно WWDC – не одно и то же.

Из 120 сессий для связанных обетом молчания (подписавших NDA, “давших подписку об отвественности за разглашение”) действительных участников конференции (менеджеров и разработчиков), термин iCloud упоминался в названии единственного семинара, “Storing Documents in iCloud using iOS 5”. “Сохранение документов в iCloud средствами iOS 5”, если так будет понятнее. Не про iCloud, а про определенные действия с ним в конкретной OS.

Семинар где, среди прочих, рассматривалась та же тема для OS X Lion, обошелся без iCloud в названии. Комплекс классов для работы с документами появился в iOS из-за iCloud, он был позаимствован из OS X, где этот комплекс тоже изменился – в том числе и из-за внедрения средств для работы с iCloud.

Новый тип хранилища данных (Apple iCloud, кроме хранения данных, предлагал еще кое-что) привел к изменениям в файловой системе обеих операционных систем, но главной причиной изменений в файловой системе OS X был вовсе не iCloud. И без iCloud их было предостаточно.

Полное описание API (интерфейсов для программиста) iCloud и наставление по работе с ними для iOS, OS X или Windows умещалось на 10-15 страницах стандартного формата.

И для прикладных разработчиков iCloud не был “новой платформой”. iCloud был одной из трех главных тем “стивноута”. И важной, но далеко не главной темой WWDC.

Главные темы

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

Но две другие темы были актуальнее и насущнее: новые версии OS X и iOS. OS X Lion (она же – Mac OS 10.7) должна была выйти через полтора месяца, iOS 5 – осенью. Обе менялись радикально, компании было важно чтобы обыватель проникся ими и радостно перешел в пугающее и прекрасное будущее.

В том числе и для того, чтобы можно было гордо сообщить о невероятно быстром (обычно рекордном) переходе пользователей на следующую версию системы. И не для насыщения ненасытной утробы гигантского акционерного общества Apple Inc.

Лейтмотивом OS X Lion было воплощение лучших из уникальных достижений iOS за четыре года её истории. Мультитач, полноэкранный режим, Launchpad (фактически интерфейс iOS для OS X, неожиданно оказавшийся совсем не ужасным), объединение Exposé, Dashboard и Spaces вместе с Launchpad в целостную и элегантную “систему в системе” Mission Control, Mac App Store…

Пересказывать ролик не буду – Фил Шиллер и Крейг Федериги выполнили свою работу на отлично, особенно последний. Лучше один раз увидеть:

Продолжительность 01:58:23:

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

Актеры не подвели и сыграли как надо.

iOS 5, мобильная операционная система номер один в мире (44% рынка у iOS, 28% у её главного “любимого” конкурента Android, 19% у непобедимой RIM и 9% у остальных), 25 миллионов iPad, 200 миллионов iOS-устройств всех типоразмеров: и сделать её еще лучше прямая и важнейшая обязанность всего прогрессивного человечества.

Скотт Форстолл, без сомнения, был одной из самых ярких звезд “яблочной” сцены.

На мой взгляд, 10 важнейших новаций iOS 5 для пользователей (из заявленных 200), которые Скотт и Стив отобрали для презентации, захватывающе интересными не были.

Пожалуй, самым интересным был ответ критикам, высмеивавшим iOS-устройства, в свете заявлений их производителя о начале эпохи Post PC которым персональный компьютер был необходим как мать (или хотя бы няня) младенцу. Скотт назвал это PC Free (без PC), с эпитетом OTA (Over the Air, то есть “по воздуху”, без проводов).

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

Про OS X, iOS, Xcode 4, новую систему управления памятью ARC и даже про iCloud – пишу. Все WWDC важны и интересны, но эта – как мне кажется, была одной из самых-самых.

Реакции на реакцию

Вечером 6 июня (вечером по тихоокеанскому времени) на страницы бумажных и Интернет СМИ выплеснулось невероятное количество суждений, оценок, выводов и прогнозов. Это было невыносимо…

Журналисты услышали и поняли следующее:

— Apple изобрела облачные технологии! – это мы даже комментировать не будем;

— Стив Джобс лжет утверждая что Apple изобрела облачные технологии, которые… – я не один раз пересматривал это событие в видеозаписи, Стив на это даже не намекал;

— Apple уничтожит файловую систему – Стив, всего навсего, привел в качестве примера iOS, где с точки зрения пользователя файловой системы нет (на самом деле, конечно же, она никуда не делась), и iCloud действительно освобождал неспособных разобраться в файловой системе от части непосильных для них забот;

— Apple превращает Mac OS X в разновидность iOS – не так быстро, но видимо, когда-нибудь. На WWDC 2011 на это даже не намекали…

Это самые распространенные заблуждения и непонятки. Мир изменился. Пользователи Apple когда-то были членами элитного и почти запретного клуба, сама Apple была в то время на грани краха.

Теперь пользователями Apple была та самая толпа, которая чуть не затоптала компанию в её трудные годы.

Времена меняются, это их единственное свойство…

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Metrowerks: фантастический взлет маленькой компании

История маленькой канадской компании, без которой переход Mac’ов на PowerPC мог бы закончиться неудачей, чьи CodeWarrior и PowerPlant в течении нескольких лет были самым популярным инструментом разработки для Mac’ов, дважды убитой (невольно) Apple…

На пике популярности, Metrowerks не была ни маленькой, ни канадской – но это неважно.

Все началось в городке Хадсон, в франко-говорящей канадской провинции Квебек, в 1985. Сначала все было скромно и обычно – ничто не предвещало Metropolis Computer Networks ни всемирной популярности, ни фантастического взлета. Грег Галанос, в прошлом один из разработчиков Think C в компании Symantec, основал компанию по продаже Интернет-трафика в своем регионе, и без особых проблем занял в нем лидирующее положение. Бизнес спокойный, прибыльный, почти без потрясений.

В мире сотни, если не тысячи, провайдеров, которые десятилетиями кормят владельцев и сотрудников, если те не станут лениться и не наделают глупостей. Но человек с девизом Veni, Vidi, Codi (“пришел, увидел, закодировал”, переделанным из классического Veni, Vidi, Vici), вволю насладившись тихой и спокойной жизнью, взялся за старое.

В 1988 году, вместе с Жаном Беланже, Грег выпустил на рынок компилятор Modula-2 для Mac’а и для Unix’ов. Скорее всего, это был первый коммерческий компилятор Modula-2 в мире. Компилятор имел “умеренный успех”. Умеренный с точки зрения обозревателей из больших компьютерных журналов. Доход от продажи компилятора превзошел доход от основной деятельности компании на порядок.

В 1988 году Грег и Жан, впервые, задумались о переезде куда-нибудь, где налоги не такие высокие, как в Канаде (особенно для занимающихся“непрофильной деятельностью”).

Канада – это социальное государство, что стоит недешево.

В течении нескольких лет Metropolis Computer Networks, сменившая длинное и банальное название на короткое и загадочное Metrowerks, продолжала обслуживать пользователей, но совсем прекратить “непрофильную деятельность” они не смогли. Кстати, вы поняли откуда взялось новое название компании?

В 1992 году команда из нескольких человек, внутри небольшой компании, ввязалась не в своё дело: консорциум Apple+IBM+Motorola объявил о своих наполеоновских планах по внедрении RISC-процессоров (на основе POWER) в индустрии персональных компьютеров, и “огребла по полной”.

CodeWarrior

Отделение Symantec, разрабатывавшее широко известные в индустрии интегрированные среды разработчика и компиляторы для них, с 1988 по 1992 годы было убыточным. Могу только догадываться, почему. Неудачи Symantec стали одной из причин успеха наших героев.

В мире не так много разработчиков компиляторов высокого уровня. Грег, в свое время, был одним из них, связи с коллегами не терял, и когда они стали массово уходить из Symantec, он быстро и достаточно легко смог договориться с ними о совместном проекте.

Основой новой среды разработки стал прототип, созданный Андреасом Хоммелем еще в стенах Symantec, но не вызвавший интереса у руководства этой компании. Think Class Library и Think C, по мнению руководства, надо было вытаскивать из трясины, вместо того чтобы генерировать какие-то новые идеи.

Вскоре в Metrowerks работала целая команда выходцев из Symantec, прототип, который было решено использовать как основу, был выкуплен у Андреаса Хоммеля, время пошло.

Ситуация сложилась примерно как на Apple, во времена когда всю выручку от продаж Apple II направляли на разработку Mac’ов, которые были неспособны прокормить себя сами. Пользователи Хадсона и прилегающих к нему территорий платили за Интернет-услуги, а провайдер тратил эти деньги на…

Проект увлекал все сильнее: складывалось нечто фантастическое. Недостатки, которыми кишели существующие среды разработки от самых разных компаний, от Apple до Microsoft, были хорошо известны разработчикам, а изобретательности им было не занимать.

WWDC 1994

Компиляторы для PowerPC и для 68k показывали фантастические результаты, и через полтора года, на WWDC 1994 года в Сан Хосе, Metrowerks, впервые в своей истории, показала свой инструментарий широким кругам разработчиков. Сначала в качестве гостей на сцене в день открытия мероприятия, потом, с деталями и подробностями, в рабочие дни конференции.

Они надеялись на успех, но реальность превзошла все ожидания: оказалось, что переход Mac’ов на PowerPC под угрозой: ни у Apple (в Apple MPW), ни у Symantec, инструментария разработчика для Mac’ов с PowerPC практически еще не было, и в ближайшее время его выход не ожидался, по причине многочисленных сложностей и нестыковок. Компания, в которой работало всего человек 20, готова была предложить практически готовую среду CodeWarrior, DR/3 – с помощью которой уже прямо сейчас можно было разрабатывать, без лишних помех и сложностей, код для PowerPC.

CodeWarrior DR/3 был выпущен специально для WWDC, 5 мая 1994 года. Желающих его попробовать было очень много, число выявленных багов было огромно – еще никогда у Metrowerks не было столько тестировщиков. Сами по себе баги и тестировщики не были бы чем-то особенным, если бы не ситуация и не честь мундира.

Если вы предполагаете продавать среду разработки, с инструментами для отладки кода, вы просто не имеете права отлаживать свой продукт “на публике” слишком долго. Они еще ждали реакции огромных и богатых конкурентов. И, работая почти круглые сутки, смогли выпустить CodeWarrior 4 всего через полтора месяца, 26 июня 1994 года.

Успех был ошеломляющим, объемы продаж – фантастическими, пресса благосклонна, а среди клиентов внезапно оказалась даже сама Apple.

Успех… убивает. Я не раз видел, как небольшие и фанатически преданные своим идеям команды, сняв “джек-пот” (куда меньший чем тот, что свалился на Metrowerks), вспоминают о множестве разных вещей, о которых прежде не думали, и перестают работать.

Metrowerks успешно преодолела испытание медными трубами. Через полгода (на фоне ураганных объемов продаж), 12 декабря 1994 года, компания выпустила CodeWarrior 5.

Остин, Техас

В 1994 году, Metrowerks открыла отделение в Техасе, которое занималось продажами CodeWarrior, и участвовало в разработке. В 1994 году распределенная разработка еще не стала чем-то обыденным и повсеместным, и сулила отважным кучу проблем – но если вы разрабатываете средства разработки, подобный экстрим невероятно полезен для вас.

Как писал Гай Кавасаки, “сами пробуйте производимую вами собачью еду”.

В 1995 группы разработчиков работали уже в Европе (в Париже), в Канаде (Хадсон) и в США (Остин, Техас), попутно с более чем успешным развитием основного продукта накапливая бесценный опыт распределенного программирования.

Продолжение следует.