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

3. Черный прямоугольник

После того как мы увидели демоверсию Ричарда, мы все еще очень много не знали о браузере с открытым исходным кодом Konqueror, но мы хотели выяснить, так ли он хорош, как кажется. Дон предложил повнимательнее изучить исходный код – написанные программистами текст с инструкциями, которые и делают программное обеспечение тем, чем оно является. Он хотел, чтобы мы начали с отделения Konqueror от остального KDE, – занялись одной из трудностей, которую обошел Ричард, чтобы сделать свою демоверсию. Также Дон хотел оценить сложность Konqueror, так что мы решили подсчитать строки исходного кода. Сделав это, мы могли бы сравнить его с Mozilla и понять, насколько трудно будет превратить демоверсию Ричарда в реальный продукт.

Дон поручил работу по подсчету строк мне, вероятно, дав возможность внести свой вклад в достижение Ричарда. Если он хотел меня так мотивировать, то ему это удалось. На следующее утро после показа браузера я пришел в офис примерно на час раньше обычного, около шести утра. На стол рядом со своим Macintosh я установил PC с системным блоком типа «башня». Я собирался установить на него Linux и загрузить весь исходный код KDE. Сделав это, я бы изучил код и провел несколько тестов, чтобы начать процедуру отделения Konqueror от окружающей его системы.

Пока все устанавливалось, я смотрел на стоящие передо мной два компьютера: персональный компьютер с Linux и Macintosh. На моем столе их разделяло всего несколько сантиметров, но в плане ПО они были гораздо дальше друг от друга. Хотя можно проследить общее происхождение Linux и Mac OS X, восходящее к UNIX, операционной системе, созданной как исследовательский проект в лаборатории Bell в 1969 году, обе системы сильно отдалились от своей предшественницы. Со временем Linux и Mac стали напоминать две местности, в которых говорили на одном языке, но с разными диалектами. Linux говорил «трейлер», а Mac – «фура». Если говорить о таких приложениях, как веб-браузеры, то между ними едва ли существовала совместимость, но, если копнуть глубже, на уровне алгоритмов, с которыми работают программисты, сходство двух систем проявлялось сильнее. В них была общая техническая грамматика, обе системы позволяли компилировать и запускать программы, написанные на C++, языке программирования, который разработчики Konqueror использовали для написания исходного кода. Но даже при этом Linux и Mac использовали разные словари и идиомы программирования для написания программ на C++, особенно когда речь шла о графических пользовательских интерфейсах. В конечном счете мы не могли просто скопировать код с одного компьютера на другой. Если мы хотели использовать Konqueror как основу для нашего проекта веб-браузера, мы должны были залатать все подобные терминологические и технические отличия в исходном коде Konqueror под Linux и заменить оболочку Ричарда прочным фундаментом программного обеспечения. Адаптация кода, написанного для одной операционной системы, так, чтобы он работал на другой, настолько распространена, что у программистов даже есть специальное слово для описания этой задачи – портирование. Поскольку на выходе нам нужно было получить браузер стандарта Apple, исходный код которого должен был работать так, будто он изначально был написан для Mac (хотя это было не так), нам в самом деле предстояла большая работа по портированию.

Для того чтобы выделить код браузера из системы KDE, мне не потребовалось много времени. Программное обеспечение было организовано очень аккуратно, и Konqueror обитал, в основном, в двух директориях: KHTML и KJS.

После того, как я отделил код, я дал компьютеру задание подсчитать общее количество строк в этих двух директориях. Это должно было дать нам примерное представление о том, какой объем портирования нас ждет. Поскольку портирование могло потребоваться для каждой строчки кода, то, чем меньше их будет, тем лучше. Увидев результат, я улыбнулся, а когда я сообщил о нем Дону и Ричарду, они тоже расплылись в улыбке. В Konqueror было чуть больше 120 000 строк, и он составлял менее одной десятой размера Mozilla¹². Сначала мы просто не могли поверить, что между двумя массивами исходного кода со схожими функциями может быть такая разница.

Дон объяснил, почему так произошло. Руководители проекта Mozilla разрабатывали систему, которая, как они надеялись, превратит их программное обеспечение в компоненты, соединяющиеся друг с другом, как кубики LEGO. Тем не менее такая схема требовала большого количества дополнительного стереотипного кода: программисты должны были сделать что-то вроде заполнения кучи форм, чтобы регистрировать новый код при повторном запуске системы, и эта волокита поглотила браузер. Теперь мы видели результат применения этого инженерного решения – размер кода Mozilla соотносился с кодом Konqueror как 10 к 1. Очевидно, работа с этими составляющими вышла из-под контроля. Mozilla оказался раздутым, громоздким и ненадежным.

Команда Konqueror использовала противоположный подход. Их код был аккуратным и без излишеств. Они превыше всего ставили лаконичность. Их стиль в программировании больше всего напоминал Хемингуэя, а вот Mozilla – Фолкнера.

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

Успехи добавили нам уверенности взяться за дело. Дон сказал, что он вместе с Ричардом покажет его демоверсию всей цепочке руководителей, отвечающих за создание программного обеспечения. Они надеялись получить одобрение Скотта Форсталла, его начальника Бертрана Серле и босса Бертрана Эви Теваняна на то, чтобы использовать Konqueror как основу нашего проекта по созданию веб-браузера.

Через несколько дней выяснилось, что наши руководители приятно удивлены, как мы и надеялись.

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

После получения их одобрения нужно было разработать стратегию портирования 120 000 строк кода Konqueror на Macintosh. Чтобы понять, какую сложную программистскую задачу нам предстояло попытаться решить, потребуется некоторое знание жаргона разработчиков.

* * *

Когда я хочу, чтобы компьютер выполнил какую-то работу, я пишу точные инструкции, используя один из языков программирования, например, C++ – тот язык, который разработчики KDE использовали для создания Konqueror.

Возможно, подобные фразы не совсем понятны, если вы не знакомы с лексикой, которую используют программисты, но если оставить в стороне технические подробности, то компьютерные программы напоминают рецепты из кулинарной книги. И те и другие предлагают конкретные шаги, чтобы выполнить определенную задачу. Тем не менее, если шеф-повара пишут кулинарные книги, которые будут читать люди, программисты не могут писать для компьютеров таким же образом, потому что компьютеры по умолчанию не воспринимают языки программирования. Машины «говорят» на двоичном коде из нулей и единиц, поэтому, чтобы заставить компьютер выполнить мое задание, мне нужно преобразовать мой код на C++ в понятную компьютеру бинарную форму с помощью программы под названием «компилятор». Этот процесс преобразования из того, что может прочитать человек, в то, что может выполнить компьютер, называется «компиляцией» или «сборкой». Также эта процедура объясняет, почему строки кода, написанные на языке программирования, называют «исходным кодом». Это исходный материал, переводимый компилятором в бинарный код, который компьютер может «прочитать» и сделать.

Поскольку полнофункциональные программы, такие как браузер, требуют большого количества исходного кода – более 100 000 строк для достаточно скромного Konqueror, например, – программисты разбивают все эти строки на отдельные файлы исходного кода. Это помогает им организовать и структурировать отдельные подзадачи. В случае с веб-браузером код, отвечающий за обработку веб-адресов (URL) может содержаться всего в одном файле исходного кода, тогда как связанная с ним более сложная составляющая, например использование URL для загрузки информации, может быть распределена по многим файлам исходного кода.

Шеф-повара также разделяют свои рецепты на отдельные части. Рецепт яиц «Бенедикт», к примеру, помимо инструкций по приготовлению яйца-пашот, поджаривания канадского бекона и английских булочек, будет содержать часть с рецептом голландского соуса. Тем не менее, автор кулинарной книги может не привести полное описание рецепта голландского соуса непосредственно для яиц «Бенедикт», особенно если этот соус встречается в других блюдах в той же книге, например в рецепте приготовления спаржи. В большой кулинарной книге, скорее всего, будет только один рецепт голландского соуса, на который автор будет ссылаться при описании всех блюд, где он используется, примерно вот так: «см. Голландский соус, с. 123».

Программисты тоже так делают. Когда я пишу файл исходного кода, чтобы загружать информацию из интернета, мне нужен код для обработки URL. Я не копирую этот код полностью в каждое место, где он необходим. Я ссылаюсь на файл исходного кода URL с помощью директивы включения, которая сходна с отсылкой читателя к способу приготовления голландского соуса в рецепте яиц «Бенедикт». Директива включения в программном обеспечении существует по тем же причинам, что и перекрестные ссылки на определенную страницу в кулинарной книге. Она помогает программистам сохранять структуру и приводить только одну копию набора инструкций для каждой отдельной задачи.

Эта система не идеальна, поскольку в схеме перекрестных ссылок могут быть ошибки. Например, если я нахожусь в середине приготовления яиц «Бенедикт» и пытаюсь найти ссылку на голландский соус на странице 123, я могу открыть кулинарную книгу на 132 странице, и нужного мне рецепта там не будет.

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

Когда я делаю похожую ошибку в программе, компилятор выдает мне сообщение об ошибке. Обычно такие сообщения бывают краткими и точными: «expected expression, line 3, column 5» («ожидается выражение в строке 3, колонке 5»). Это может оказаться и ошибкой при наборе, и простой логической ошибкой. Такое сообщение напоминает шеф-повара на суматошной кухне, который бросает один взгляд через плечо помощника, готовящего тарелку яиц «Бенедикт», и выносит приговор: «Голландский соус слишком густой!» Оба этих сообщения констатируют ошибку, и, хотя в них нет четких инструкций решения проблемы, они чрезвычайно полезны.

Когда я готовлю, результаты могут получиться очень разными, даже если я следую рецептам из отличной кулинарной книги. Иногда еда получается очень вкусной, иногда нужно подсолить, а иногда мои кулинарные способности меня подводят, и блюдо совсем не так прекрасно, как я надеялся. На компьютере даже после того, как я исправляю все ошибки компиляции и мне удается успешно собрать программу, она далеко не всегда с первого раза абсолютно правильно выполняет поставленную задачу. Успешно скомпилированный код может не давать нужный результат. В такой сложной программе, как веб-браузер, могут возникнуть бесчисленные ошибки поведения программы: текст может отображаться не в том месте, картинка может показываться криво из-за багов с графикой, кнопка или ссылка могут не работать по щелчку мыши. Программа может даже сразу «упасть» из-за серьезной ошибки – если продолжать аналогию с приготовлением еды, то такая ошибка похожа на упавшую на пол миску с ингредиентами. Для внесения поправок и улучшения программы с момента успешной компиляции и до того, как удастся заставить ее работать так, как предполагалось, приходится регулярно делать шаг назад и пытаться снова и снова. Как и приготовление идеального блюда, компиляция и правильный запуск программы требуют большого количества попыток: переписывание исходного кода, чтобы улучшить программные инструкции, исправление ошибок при компиляции, перекомпиляция кода, запуск программы или приложения, поиск ошибок и снова возвращение к исходникам, чтобы внести правки и повторить все снова и снова. Скоро вы поймете, о чем я.

* * *

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

Прежде всего мы должны были вернуться к демоверсии Ричарда и разобраться со всеми трудными местами, которые он в ней обошел. Чтобы сделать это, нам предстояло скопировать исходный код Konqueror на Macintosh и скомпилировать его. Затем нужно было все проверить и выловить ошибки, чтобы в результате код браузера выглядел как написанный для системы Mac.

Также, поскольку Konqueror относился к свободному ПО, нам приходилось подчиняться лицензии Столлмана, которую авторы прикрепили к своему софту. Наше руководство хотело опубликовать исходный код части программного обеспечения, но по большей части он должен был быть закрытым и проприетарным[15]15
  Проприетарное программное обеспечение – ПО, являющееся объектом авторского права и имеющее правообладателей. – Прим. ред.


[Закрыть]. Причина проста: Mac OS X была продуктом, который приносил Apple прибыль. В эру iPhone компания начала публиковать бесплатные обновления программного обеспечения, но во времена, о которых идет речь, операционная система Macintosh в Соединенных Штатах стоила 129 долларов для одного компьютера¹³. Когда мы продумывали нашу стратегию разработки веб-браузера, руководство предпочитало не «свободное, как свобода слова» и не «бесплатное, как бесплатное пиво» ПО, а «хорошо спрятанное, как деньги».

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

Дон обожал занудствовать по поводу деталей лицензий свободного ПО. За время работы в Netscape и Eazel он подробно изучил эту тему и любил чесать языком, обсуждая достоинства, недостатки и положения различных лицензий. Он явно получал удовольствие, объясняя хитросплетения стандартной общественной лицензии ограниченного применения исходного кода Konqueror. Эти положения гласили, что если мы включаем Konqueror в «кулинарную книгу» Macintosh как отдельную главу, используя его код только с помощью перекрестных ссылок, и открыто публикуем любые изменения, которые делаем, чтобы рецепт Konqueror «получался вкусным» на Macintosh, мы работаем в соответствии с лицензией свободного программного обеспечения Столлмана.

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

Я был где-то посередине.

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

Более того, если мы не будем соблюдать условия лицензионного соглашения Konqueror, это может привести к судебному иску в отношении Apple. Я не хотел зацикливаться на всех этих лицензиях, но считал важным потратить некоторое время и удостовериться, что мы учли все варианты и с технической, и с юридической точки зрения.

К лицензированию мы относились по-разному, так что совещание, посвященное нашей будущей стратегии, выглядело как бестолковая постановка сказки «Три медведя». К счастью, было не слишком трудно сделать все «правильно», и через пару часов у нас был план. Чтобы объяснить его подробности, я снова обращусь к аналогии с кулинарными книгами.

Представим, что миллионы строк кода, которые составляют операционные системы Linux и Mac, – это большие кулинарные книги, написанные разными авторами. Иногда представленные в них рецепты пересекаются, но отдельные блюда отличаются. В книге рецептов Mac браузера нет. В разделе KDE кулинарной книги Linux он есть, в главе под названием Konqueror. Наш план состоял в том, чтобы выдернуть эту главу, уничтожить то, что останется от KDE и Linux, и добавить страницы Konqueror в кулинарную книгу Mac. Все это вело к одной совершенно очевидной проблеме. Таким образом мы уничтожим все перекрестные ссылки, связывающие Konqueror с другими частями кулинарной книги, которую мы планировали выкинуть. Не будет больше никакого рецепта голландского соуса на с. 123.

Чтобы эта схема с изъятием страниц работала, мы должны были, перенося Konqueror на Mac, тщательно изучить каждую разрушенную перекрестную ссылку в каждом рецепте. Если подходящий эквивалент уже существует в программном обеспечении Apple – например, общие вычислительные ресурсы, такие как цвета или шрифты, – мы можем переназначить для них перекрестные ссылки. Если эквивалента нет – скажем, для системы, создающей закладки веб-страниц, – нам нужно написать новые рецепты с чистого листа. Мы предполагали, что переделки коснутся как Konqueror, так и Mac, чтобы блюдо вышло таким, как надо.

Мы понимали, что после того, как скопируем код Konqueror на Macintosh и попробуем его скомпилировать, он не будет работать нормально. Каждая разрушенная перекрестная ссылка приведет к ошибке компиляции. И даже после того, как мы исправим все эти ошибки, браузер вряд ли сразу заработает как надо. Мы знали, что ошибок будет очень много. Но главное – после компиляции исходного кода у нас будет прочное основание в виде браузера Konqueror и мы сможем начать поиск ошибок, проверку и «полировку» кода.

Мы добавили к нашей стратегии один последний элемент. По нашим предположениям, программистам придется уделить особое внимание некоторым частям кода Konqueror, чтобы они начали хорошо работать на Mac. Мы решили добавить к исходному коду примечания, чтобы напомнить себе, что позднее нам следует вернуться и улучшить адаптацию кода в этих местах. Программисты часто используют такие заметки. Мы называем их FIXME. Логично было предположить, что в такой большой работе по портированию, какую мы запланировали, будет очень много таких FIXME. Пару месяцев спустя мы были очень рады тому, что приняли это решение и что прилежно добавляли эти пометки везде, где сомневались в каком-то участке кода во время редактирования. Каждая FIXME была еще одним пунктом в нашем списке того, что надо сделать.

В целом у нашей стратегии было несколько весомых преимуществ. Мы были уверены в том, что можем использовать Konqueror, не нарушая каких-либо положений любой лицензии свободного ПО. Добавление FIXME создавало базу для поиска ошибок после того, как мы скомпилируем программное обеспечение. Первый этап – сборка – не вызывал особых затруднений: нужно уничтожить все ошибки компиляции, вызванные нарушенными перекрестными ссылками. 120 000 строк кода Konqueror были распределены по 300 файлам исходного кода, и мы прикинули, что компиляция каждого файла займет больше месяца, но меньше двух.

В тот момент это звучало неплохо, но мы оказались не готовы к тому, какой утомительной окажется работа по компиляции. Вот как проходили мои дни на этом этапе проекта. Я пытался скомпилировать файл исходного кода Konqueror, у меня ничего не получалось, и сообщение компилятора об ошибке докладывало мне об отсутствующей перекрестной ссылке, о чем-то, что разрушила наша схема с вырванными страницами. Я исправлял проблему и пытался скомпилировать снова. Еще одно сообщение об ошибке. Еще одно исправление. И снова. И снова. Это все продолжалось и продолжалось. Смотрю на экран компьютера в своем кабинете. Компилирую, читаю сообщение об ошибке и разбираюсь с ним. Я уже чувствовал себя героем экзистенциалистской пьесы, приговоренным к без конца повторяющейся беседе с компилятором.

АКТ I. СЦЕНА XXXVI.

Кампус компании Apple Infinite Loop, Купертино. Кабинет Кена.

Кен сидит за столом. Его руки лежат на клавиатуре. Он печатает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 200: use of undeclared identifier «protocol»

(ошибка в строке 200: использование необъявленного идентификатора «протокол»)

Кен ищет соответствующий идентификатор для «протокол». Печатает его.

КЕН: Вот тебе, компилятор! Я определил «протокол». Пожалуйста, попробуй еще раз!

Кен снова вбивает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 201: use of undeclared identifier «host»

(ошибка в строке 201: использование необъявленного идентификатора «хост»)

Кен ищет соответствующий идентификатор для «хост». Печатает его.

КЕН: Надо же, я забыл определить идентификатор «хост»! Ну вот он! Попробуем еще раз.

Кен опять вбивает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 201: use of undeclared identifier «port»

(ошибка в строке 201: использование необъявленного идентификатора «порт»)

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

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

Наша прикидка насчет двух месяцев оказалась правильной. Наконец, компилятор перестал выдавать сообщения об ошибках. Konqueror скомпилировался на Macintosh, и у нас было приложение, которое можно было запустить двойным щелчком мыши. Когда мы запускали его, наш новый браузер показывал пустое белое окно. Теперь мы должны были заставить код делать то, для чего нужны браузеры, – загружать веб-страницы. Пока наш браузер только «падал» при попытке что-то загрузить. Или вообще ничего не делал.

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

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

В самом начале этого этапа вылавливания ошибок отчет содержал такие строки: «Отрисовка изображений не осуществляется… Ссылки на веб-страницы не работают… Выполнение JavaScript не осуществляется». Позднее, когда мы улучшили код, многие из этих «не осуществляется» превратились в «осуществляется частично». Когда мы понимали, что область с пометкой FIXME наконец доведена до ума, мы удаляли примечание совсем. Но, как бы то ни было, после того, как мы исправили массу таких проблем, окно нашего браузера по-прежнему не подавало никаких признаков жизни. Оно оставалось пустым пространством из белых пикселей, а многочисленные отчеты FIXME продолжали указывать, как много нам еще предстоит сделать.

Мы двигались вперед, и после нескольких недель монотонного труда Ричард взял пару выходных. Он занимался обработкой графических данных для отображения элементов на экране и считал, что близок к тому, чтобы избавиться от нескольких наиболее важных FIXME. Он передал работу мне, и я начал с того места, где он остановился. После нескольких часов анализа я нашел место, где, как мне казалось, программа, грубо говоря, пытается нарисовать что-то на странице, на самом деле не касаясь ручкой бумаги. Будто браузер играет на воображаемой гитаре. Я написал код, чтобы исправить это, затем скомпилировал приложение и запустил его.

Я набрал URL-адрес: http://www.yahoo.com. Как обычно, отчет FIXME заполнялся строка за строкой, но браузер не падал. Прошло несколько секунд, а потом браузер кое-что сделал. Он показал мне картинку.

Я закрыл приложение и попробовал снова. Я опять загрузил домашнюю страницу Yahoo. Отчет FIXME заполнился, браузер не упал, снова та же короткая пауза… и тот же черный прямоугольник!

Черный прямоугольник. Первая настоящая «веб-страница», которую наш браузер Apple загрузил из интернета

Я выбежал в коридор, чтобы позвать Дона. Когда мы вернулись, я закрыл приложение, снова открыл и загрузил главную страницу Yahoo. Во время паузы мы затаили дыхание… и опять увидели все тот же черный прямоугольник! Браузер наконец что-то сделал!

Мы начали кричать, улюлюкать и хлопать друг друга по спине. Мы вели себя как персонажи из фильма «2001 год: Космическая одиссея», когда наши отдаленные предки австралопитеки вошли в контакт с инопланетным Черным монолитом, чему посвящены первые десять минут фильма. Мы даже превзошли их.

Мы тыкали пальцами в экран и вопили. Я попытался снова загрузить страницу. Браузер опять сработал… еще один черный прямоугольник! Это действительно случилось!

Хотя наше достижение и может показаться ничем не примечательным, мы были в восторге. Все три месяца после того, как Ричард показал свою демоверсию, мы делали ставку на нашу стратегию портирования. Но ее результаты мы могли отследить только опосредованно, по цифрам: столько-то файлов исходного кода скомпилировано, столько-то перекрестных ссылок исправлено, столько-то FIXME убрано. Теперь мы могли видеть веб-страницы в окне браузера.

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

Во всей моей карьере в Apple было всего два момента, когда я был готов кричать «Эврика!», и это был один из них. Я жалел, что с нами нет Ричарда, чтобы разделить радость этого мгновения. Его демоверсия показала потенциал Konqueror, а встреча с черным прямоугольником была следующим большим шагом. Она показывала, что стратегия портирования действительно работает, и стала на пути превращения демоверсии в продукт.

Больше таких периодов, когда недели проходят без каких-то видимых успехов, у нас не было. После того как мы увидели, что страницы загружаются, мы с каждым днем наблюдали, как браузер становится все лучше и лучше. Еще до конца недели мы превратили черный прямоугольник в страницу, где отображался весь текст с домашней страницы Yahoo. Еще пару дней спустя ссылки на другие страницы приобрели голубой цвет и подчеркивания, как было тогда принято. На следующей неделе появились первые картинки. Когда я загрузил первую веб-страницу, это было похоже на щелчок выключателя, после которого комнату заливает свет.

В наши дни большинство людей воспринимают браузеры как что-то само собой разумеющееся, поэтому аналогия со светом вполне уместна. Мы ныряем в интернет, не задумываясь о том, что браузер – это технология, которая когда-то и кем-то создана. То же самое было и с электричеством, и я думаю, что, пытаясь в XXI веке создать браузер, мы могли бы кое-чему поучиться у Эдисона, который в XIX веке создавал свою лампу накаливания.

Эдисону тоже приходилось сражаться с техникой, например, искать материал для нити накаливания, который мог бы гореть ярко и долго. Мне очень нравится, как причудливо описываются эти поиски в книге 1910 года под названием «История великих открытий».

Однажды вечером [Эдисон] размышлял над проблемой и, сам того не осознавая, крутил в руках кусочек ламповой сажи [красителя, изготавливающегося из копоти], смешанной со смолой, которую он использовал при создании телефона. Не думая о том, что он делает, Эдисон скатал эту смесь сажи и смолы в нить. Тут он посмотрел на то, что у него получилось, и в голову ученому пришла мысль: «А почему бы не пропустить электрический ток через этот углеродный материал?» Он попробовал, и в результате получилась яркая вспышка…

Затем Эдисон решил найти лучший вариант углеродного материала для своих целей. Он покрывал углем бумагу и различные породы дерева – да и любые материалы, все, из чего можно было сделать углеродную нить. Он пробовал даже использовать японский веер из бамбука, и обнаружил, что это волокно светится лучше, чем что-либо еще. Потом он начал искать лучший вид бамбука. Ученый узнал, что существует 2000 разновидностей этого растения. Он должен был заполучить все образцы. Эдисон отправлял людей по всему миру в разные места, где рос бамбук. Одному из них пришлось преодолеть 48 тысяч миль и повстречаться по дороге с дикими животными. Наконец, в Японии нашелся бамбук, который был лучше других сортов. Поиск материала для углеродной нити обошелся примерно в 100 000 долларов¹⁴.

В этой короткой истории есть все. Озарение! Отважные люди! Огромные расстояния! Столкновения с дикими животными! Громадные суммы денег! Даже автор истории великих открытий носил имя, подходящее для рассказчика, – Элмер Элсуорт Бернс.

Конечно, настоящая история создания лампочки гораздо сложнее, и, думаю, мы с вполне обоснованно можем спросить, действительно ли Эдисон крутил в руках кусочек ламповой сажи и смолы, а затем ему пришла в голову потрясающая идея пропустить электрический ток через получившуюся у него нить, напоминающую провод. Как Стивен Джонсон пишет в своей книге «Откуда берутся хорошие идеи»[16]16
  Полное название «Откуда берутся хорошие идеи. Рождение и судьба инноваций», автор Стивен Джонсон (изд-во АСТ, 2014 г.) – Прим. ред.


[Закрыть]: «Народная молва утверждает, что Эдисон является изобретателем лампы накаливания, но, на самом деле она появилась в результате сложной системы взаимодействий между Эдисоном и его соперниками… Эдисон опирался на разработки, по крайней мере, полдюжины других изобретателей, предшествующих ему. Среди них были Джозеф Суон и Уильям Сойер»¹⁵.