Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса - Кен Косиенда

истории Киддер за многие годы распространились по миру высоких технологий, и многие сотрудники Apple читали эту книгу (я лично читал даже не один раз), поэтому мы все были в курсе, что такое «подписаться», и делали это, хотя и не называли именно так.

Самое близкое выражение, которое было в лексиконе Apple, относилось скорее к менеджерскому жаргону: непосредственная личная ответственность (в разговорах мы называли ее D-R-I)[22]. Ее брал на себя человек, который делал все, что необходимо, чтобы разработать часть аппаратного или программного обеспечения, какую-то технологию или критически важную вещь. Лично ответственным (DRI) называли человека, который отвечал за проект головой.

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

— Хорошо, Скотт, я сделаю все, что смогу.

Ответ ему понравился.

Вот так я стал ответственным за то, чтобы добавить в WebKit редактирование веб-страниц — технологию, о которой я почти ничего не знал.

* * *

Когда я начал эту работу по функции редактирования в электронной почте, нажатие кнопки «Ответить», если в почте была веб-страница, заставляло программу пытаться создать ответную страницу в простом компоновщике электронных писем, который использовался в те дни в Apple Mail. Эта система не предлагала почти ничего, кроме базового оформления текста (жирный шрифт, курсив, подчеркивание). Поскольку компоновщик электронных писем веб-браузером не являлся, он не мог правильно передавать веб-страницы. Ответ на электронное письмо с веб-страницей начинался словами: «31 января 2003 года вы написали», но то, что шло дальше, часто представляло собой спутанный, трудный для чтения веб-контент.

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

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

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

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

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

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

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

Сложное правило: в обычном блоке текста в конце строки может содержаться бесконечное число пробелов. Это может показаться абсурдным, но именно это правило делает возможным выравнивание текста по левому краю. Без этого блоки текста с многочисленными пробелами в конце строки стали бы «зазубренными» по левому краю. Чтобы увидеть, как работает это правило, поместите курсор после последнего символа в строке в середине абзаца текста. Начните нажимать на «пробел». Когда курсор дойдет до конца, то есть до того места, где текст переходит на следующую строку, добавьте еще несколько пробелов, и это не приведет ни к каким изменениям ни в тексте, ни в положении курсора. Лишние пробелы превратятся в ничто. Чтобы увидеть все свои пробелы, измените размер окна или по-другому разбейте текст на строки, добавив или удалив символы.

«СЛОЖНОЕ» ПРАВИЛО ТОЧКИ ВВОДА

До того, как я приступил к проекту редактирования в WebKit, я думал, что благодаря этим правилам, все будет работать примерно так, как, в общем, и должна работать обработка текста. И я был уверен, что замечу, если какое-то из этих правил перестанет работать — например, почему выровненный по левому краю текст вдруг стал неровным слева? Да, умом я эти правила не понимал. Теперь, когда мне предстояло превратить функцию WebKit в полноценный текстовый редактор, я больше не мог позволить себе роскошь опираться на интуитивные ощущения при наборе и редактировании электронных писем. Я должен был стать экспертом, знающим все тонкости текстовых редакторов. По этой теме не существует учебников для программистов, поэтому мне приходилось проводить эксперименты, чтобы выяснять, что и как работает. Мне нужно было сжиться с буквой и духом всех этих правил, простых и сложных. Я потратил много времени, прощупывая различные текстовые редакторы: Microsoft Word, Apple Mail и BBEdit — редактор, который я использовал для того, чтобы писать программы. Я проверял, «прокликивал», набирал текст, щелкал мышью. Постепенно я узнал и о других правилах, и о том, как написать код, чтобы обеспечить их выполнение. Сделав это, я попал в тупик.

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