Книга: Джоэл и снова о программировании
Назад: Глава шестнадцатая. Формирование сообществ с помощью программного обеспечения
Дальше: Глава восемнадцатая. Почему форматы файлов Microsoft Office такие сложные (и как это обойти)

Часть четвертая. Управление большими проектами

Глава семнадцатая. Наушники для марсиан

17 марта 2008 года, понедельник

Сейчас перед вами предстанет главная из всех священных войн, ведущихся в интернет-форумах, где толкутся веб-разработчики. Сталинградская битва в сравнении с ней — все равно что тот случай, когда ваша невестка унеслась с чаепития у бабушки и обернула дерево своим «Мустангом».
Этим предстоящим сражением будет руководить Дин Хашамович (Dean Hachamovitch), ветеран Microsoft, в данное время возглавляющий команду, которая готовит нам очередную версию Internet Explorer — 8.0. Команда IE 8 находится в процессе принятия решения, проходящего в точности по линии разлома между двумя типами мировоззрения. Это различие между консерваторами и либералами, между «идеалистами» и «реалистами», это глобальный джихад между членами одного семейства, программисты против компьютерных теоретиков и «Лексусы» против оливковых деревьев.
А решения нет. Но наблюдать будет очень и очень интересно, потому что 99% участников религиозных войн и не пытаются разобраться в том, что они обсуждают. И это не просто зрелище: это обязательное чтение для разработчиков, проектирующих интероперабельные системы.
Эта война страстей будет вестись вокруг предмета, называемого «стандартами Сети». Пусть Дин сам познакомит вас с существующей проблемой (blogs.msdn.com/ie/archive/2008/03/03/microsqfi-s-interoperabiltty-principles-and— ie8.aspx):
Во всех броузерах есть режим «Standards» — назовем его «режим Standards», — применяемый для выбора лучшей реализации вебстандартов, имеющейся в броузере. В каждой версии любого броузера есть собственный режим Standards, поскольку с каждой версией поддержка веб-стандартов улучшается. Есть режимы Safari 3 Standards, Firefox 2 Standards, IE 6 Standards и IE 7 Standards, и все они отличаются друг от друга. Мы хотим, чтобы в IE8 режим Standards был намного лучше режима IE 7 Standards.
И вся проблема заключается в такой мелочи, как решить, что должен делать IE 8 со страницей, которая объявляет, что поддерживает «стандарты», но на самом деле, вероятно, протестирована только с IE 7.
Да что за штука этот чертов «стандарт»?
Разве нет стандартов во всех инженерных областях? (Есть.)
Разве они обычно не работают? (Ну, это как посмотреть...)
Почему «веб-стандарты» так чудовищно запутаны? (В этом вина не только Microsoft, но и ваша тоже. А также Джона Постела (Jon Postel [19431998]). Объясню позднее.)
Решения нет. Любое решение оказывается абсолютно неверным. Эрик Бэнджимен (Eric Bangeman) пишет на Ars Technica: «Команда IE должна пройти по тонкой линии между поддержкой стандартов W3C и обеспечением правильного отображения сайтов, написанных для более ранних версий IE» (arstechnica.com/news. ars/post/20071219-ie8-goes-on-an-acid2-trip-beta-due-in-first-half-of-2008. html). Это неверно. Это не тонкая линия. Это линия отрицательной ширины. Тут негде пройти. Они обречены, если пойдут по ней, и обречены, если не пойдут.
Поэтому я не могу и не буду принимать чью-либо сторону в этом вопросе. Но каждый программист-практик должен хотя бы понимать, как действуют стандарты, как они должны действовать и как мы попали в эту заваруху, поэтому я постараюсь немного объяснить, в чем суть проблемы, и вы увидите, что причина та же, по которой так плохо продается Microsoft Vista, и предмет спора тот же, о котором я писал, рассказывая о противостоянии в Microsoft лагеря Рэймонда Чена (Raymond Chen), «прагматиков», и лагеря MSDN, «идеалистов», в котором победил лагерь MSDN, и теперь никто не может понять, куда делись их любимые команды меню в Microsoft Office 2007, и никому не нужна Vista, и идет все тот же спор, в котором вы на стороне идеалистов («красных») или прагматиков («голубых»).
Но начну сначала. Подумаем, как сделать, чтобы вещи могли работать вместе.
Какие вещи? Да практически любые. Карандаш и точилка. Телефонный аппарат и телефонная сеть. Страница HTML и веб-броузер. Графическое Windows-приложение и операционная система Windows. Facebook и Facebook-приложение. Стереонаушники и стереосистема.
В том месте, где происходит контакт между этими вещами, нужно согласовать много характеристик, иначе они не смогут работать вместе.
Разберу простой пример.
Предположим, что вы отправились на Марс и обнаружили, что у тамошних жителей нет карманных музыкальных плееров. Они все еще пользуются большими музыкальными ящиками.
Вы обнаруживаете огромные возможности для бизнеса и начинаете продавать карманный MP3-плеер (на Марсе его называют Qxyzrhjjjjukltk) и наушники для них. Чтобы подключить к MP3-плееру наушники, вы придумываете аккуратный металлический штекер, вот такой:
Поскольку и плеер, и наушники находятся под вашим контролем, можно гарантировать, что ваш плеер будет работать с вашими наушниками. Это рынок «один-к-одному». Один плеер, одни наушники.
Один к одному

 

Возможно, вы напишете спецификацию, в расчете что кто-то еще станет изготавливать наушники разных цветов, потому что марсиан очень волнует, какого цвета то, что они вставляют себе в уши.
Но, составляя спецификацию, вы забыли указать, что напряжение должно составлять около 1,4 вольт. Ну, просто забыли. И вот появляется первый честолюбивый изготовитель 100%-совместимых наушников, рассчитанных на 0,014 вольт, а когда он тестирует прототип, взрываются либо его наушники, либо барабанные перепонки слушателя — смотря что прочнее. После некоторого усовершенствования он получает наушники, которые отлично работают — может быть, чуточку хуже, чем ваши.
Появляются все новые и новые изготовители совместимых наушников, и мы оказываемся на рынке «один-ко-многим».
Один ко многим

 

Пока все идет хорошо. Есть стандарт наушников де-факто. Письменная спецификация — неполная и неточная, но каждый желающий производить совместимые наушники может просто воткнуть их в ваш плеер и проверить, работают ли они, и если да, то можно продавать, и все в порядке.
Пока вы не решаете выпустить новую версию, Qxyzrhjjjjukltk 2.0.
В Qxyzrhjjjjukltk 2.0 дополнительно имеется телефон (сотовые телефоны марсианам тоже не удалось изобрести самим), а в наушники встроен микрофон, для чего нужен еще один провод, поэтому вы переделываете разъем в нечто совершенно несовместимое и довольно уродливое, зато с большими возможностями расширения:
И Qxyzrhjjjjukltk 2.0 терпит полный провал на рынке. Пусть в нем есть замечательный телефон, но он не интересует марсиан. Их интересуют огромные коллекции наушников, которые они собрали. Я же не зря говорил, что марсиане очень озабочены цветом того, что вставляют себе в уши. У следящих за модой марсиан накопились целые шкафы замечательных наушников. Вам кажется, что все они одинаковые (красные), но марсиане поразительно тонко различают оттенки красного. В рекламе новейших дорогих квартир на Марсе сказано, что в них есть готовые шкафы для наушников. Кроме шуток.
Итак, новый разъем не пользуется успехом, и вы быстро придумываете новую схему:
Обратите внимание, что теперь на центральном стержне имеется дополнительный контакт, обеспечивающий подключение микрофона, но беда в том, что ваш Qxyzrhjjjjukltk 2.1 не знает, какие наушники в него вставляются — с микрофоном или без, а ему нужно это выяснить, чтобы решить, включать ли телефон. Тогда вы изобретаете некий протокол... Новое устройство подает сигнал на контакт микрофона и проверяет, появляется ли он на «земле» — если да, значит это трехконтактный разъем, и микрофона нет, поэтому устанавливается режим обратной совместимости, в котором можно только играть музыку. Вот такой простой протокол согласования.
Теперь это уже не рынок «один-ко-многим». Все стереоустройства производятся одной фирмой, одно за другим, поэтому я назову такой рынок «серия-ко-многим»:
Вот несколько знакомых вам рынков «серия-ко-многим»:
1. Facebook: около 20 000 Facebook-приложений
2. Windows: около 1 000 000 Windows-приложений
3. Microsoft Word: около 1 000 000 000 документов Word
Можно привести еще сотни примеров. Главное — помнить, что когда слева появляется новая версия устройства, она должна обеспечивать автоматическую обратную совместимость со всеми старыми аксессуарами справа, рассчитанными на работу со старым устройством, потому что эти старые аксессуары, скорее всего, проектировались без учета появления нового продукта. Марсианские наушники уже изготовлены. Нельзя вернуться назад и все их переделать. Гораздо легче и разумнее переделать новое устройство, чтобы, столкнувшись со старыми наушниками, оно действовало как старое.
А поскольку вы хотите двигаться вперед, предлагая новые возможности и функции, то новым устройствам требуется новый протокол, и правильно сделать так, чтобы оба устройства сначала потратили какое-то время на согласование и выяснили, могут ли они оба работать по новейшему протоколу.
«Серия-ко-многим» — это закон развития мира Microsoft.
Однако есть еще один вариант — рынок «многие-ко-многим».
Проходит несколько лет; Qxyzrhjjjjukltk по-прежнему нарасхват, но на рынке появилось множество клонов Qxyzrhjjjjukltk, типа FireQx с открытым исходным кодом, и множество наушников, и каждый производитель изобретает все новые функции, требующие изменений в конструкции разъема, от чего изготовители наушников сходят с ума, потому что им нужно тестировать свои новые изделия с каждым клоном Qxyzrhjjjjukltk, что дорого и долго, и, по правде говоря, у большинства из них нет на это времени, поэтому они проверяют совместимость с самой популярной версией Qxyzrhjjjjukltk 5.0, и если она есть, то удовлетворяются этим; но, конечно, если воткнуть эти наушники в FireQx 3.0, то полюбуйтесь — они взорвутся прямо у вас в руках, потому что никто не может понять до конца одну туманную штуку в спецификации, носящую название hasLayout, хотя всем известно, что когда идет дождь, свойство hasLayout имеет значение «истина», и нужно поднять напряжение, чтобы обеспечить работу щеток-стеклоочистителей, но есть разные мнения по поводу того, считать ли град и снег за дождь по отношению к hasLayout, потому что в спецификации о них ничего не сказано. FireQx 3.0 считает, что между снегом или дождем нет разницы, потому что стеклоочистители нужны и тогда, когда идет снег, но в Qxyzrhjjjjukltk 5.0 это не так, потому что программист, писавший эту функцию, живет в теплой части Марса, где не бывает снега, да и вообще у него нет водительских прав. Да, на Марсе есть свои водительские права.
Наконец, какая-то зануда из зануд, воспользовавшись ошибкой, имеющейся в Qxyzrhjjjjukltk 5.0, пространно описывает в своем блоге трюк, благодаря которому Qxyzrhjjjjukltk 5.0 поведет себя так же, как FireQx 3.0, считая, что идет дождь, хотя на самом деле это снег, — для этого надо растопить немного снега, и несмотря на всю нелепость все так и поступят, потому что нужно решить проблему несовместимости hasLayout. Но затем разработчики Qxyzrhjjjjukltk в версии 6.0 исправили эту ошибку, то есть вы опять влипли и должны искать еще какую-нибудь ошибку, чтобы с ее помощью обеспечить совместимость своих оснащенных стеклоочистителями наушников с каждым из устройств.
Итак. Вот вам рынок «многие-ко-многим». Слева — множество участников, которые не сотрудничают между собой, справа тоже бесчисленное множество участников. И все они допускают ошибки, потому что Людям Свойственно Ошибаться.
Многие-ко-многим

 

Несомненно, ту же ситуацию мы наблюдаем в HTML. Десятки броузеров и миллиарды веб-страниц.
С течением времени на рынке «многие-ко-многим» все громче раздаются требования выработать «стандарты», чтобы «все участники» (в смысле «мелкие игроки») получили равные возможности показывать правильно все восемь миллиардов веб-страниц, и, что еще важнее, чтобы разработчики этих восьми миллиардов страниц могли проверить их всего в одном броузере, применяя «веб-стандарты», и без проверки в остальных броузерах убедились, что и те отобразят их страницу правильно.
Как видите, идея в том, что вместо тестирования «многих-ко-многим» появляется тестирование «многие-к-стандарту» и «стандарт-ко-многим», что радикально сокращает количество проверок. Не говоря уже о том, что не нужно добавлять в веб-страницы особый код для обхода ошибок в отдельных броузерах, потому что в этом идеализированном мире не бывает ошибок.
Так выглядит идеал.
На практике есть одна проблема, связанная с Сетью: отсутствие возможности протестировать страницу на соответствие стандарту, поскольку не существует эталонной реализации, совместимость с которой гарантировала бы совместимость со всеми остальными броузерами. Нет такой в природе.
Поэтому приходится «тестировать» в голове, проводя чисто мысленный эксперимент, проверяя соответствие ряду стандартизирующих документов, которые вы, вероятно, не читали, а если и читали, то не до конца поняли.
Эти документы крайне запутанны. В спецификациях полно выражений вроде «если сестринский структурный блок (который не является плавающим и не позиционирован абсолютно) следует за вставляемым блоком, то последний становится первым строковым блоком структурного блока. Вставляемый блок не может входить в блок, который уже начинается с вставляемого или который сам является вставляемым». Когда я читаю нечто подобное, то начинаю сомневаться, можно ли вообще корректно удовлетворить такой спецификации.
Не существует реального способа проверить, удовлетворяет ли спецификации веб-страница, которую вы написали. Есть валидаторы, но они ничего не скажут вам о том, как должна выглядеть страница, а что толку от того, что страница «правильная», если на ней куски текста перекрываются, не выровнены и ничего нельзя разобрать! Поэтому ограничиваются тем, что добиваются правильного вида страницы в одном или двух броузерах. А если есть какая-то ошибка, но в IE и Firefox все выглядит хорошо, то автор даже не заметит, что сделал ошибку.
Но может случиться, что такие страницы будут неправильно показаны в следующих версиях броузера.
Если вам доведется посетить в Иерусалиме какие-нибудь ультраортодоксальные еврейские общины, стремящиеся ни на йоту не отступать от своего Закона, то вы обнаружите, что несмотря на всеобщее согласие относительно того, какая пища является кошерной, раввин одной такой общины не согласится отобедать в доме раввина другой ортодоксальной общины. Веб-дизайнеры открывают для себя то, что было давным-давно известно евреям из Меа Шеарим: общее согласие жить по одной книге не обеспечивает совместимость, потому что законы настолько сложны и запутанны, что почти невозможно разобраться в них в достаточной мере, чтобы избежать ловушек и мин, поэтому для надежности лучше взять блюдо из фруктов.
Стандартизация, конечно, замечательная цель, но чтобы не превратиться в фанатичного приверженца стандартов, следует понять, что из-за человеческого несовершенства стандарты могут неправильно интерпретироваться, оказываясь непонятными и даже двусмысленными.
Суть проблемы в том, что вам кажется, будто существует единый стандарт, но поскольку невозможно проверить соответствие этому стандарту, то он не настоящий: это теоретический идеал вместе с рядом его неверных интерпретаций, а потому такой стандарт не служит решению задачи сократить матрицу тестирования для рынка «многие-ко-многим».
Тег DOCTYPE — это миф.
Простой смертный, веб-дизайнер, помещающий на своей веб-странице тег DOCTYPE, который должен свидетельствовать о соблюдении им стандарта HTML, впадает в грех гордыни. Он не может знать, соблюден стандарт или нет. Тег надо воспринимать лишь как сообщение о том, что автор стремился соблюсти стандарт HTML. В действительности он знает только то, что страница показывается в броузерах, которые он проверил — IE,
Firefox, иногда еще Opera и Safari. А может, он просто скопировал тег DOC-TYPE из учебника, не понимая, что он означает.
В реальном мире, где живут несовершенные люди, нельзя установить стандарт с помощью одной лишь спецификации: должна существовать еще очень строгая эталонная реализация, которую все должны применять для тестирования. В противном случае у вас получится дюжина разных «стандартов», а это все равно что ни одного.
Джон Постел спровоцировал проблему в 1981 году, сформулировав принцип надежности: «Будьте консервативны в том, что делаете сами, и либеральны в том, что принимаете от других» (tools.ietf.org/html/rfc793). Этим он хотел сказать, что для надежной работы протоколов нужно максимально точно придерживаться спецификаций самому и в то же время быть снисходительнее к партнерам, не вполне следующим спецификации, если вы в состоянии понять, что они хотят сказать на самом деле.
Так, для того чтобы сделать абзац с маленьким текстом, формально нужно написать <p><small>, но многие пишут <small><p> что формально неверно, хотя большая часть веб-разработчиков этого не понимает, но вебброузеры «прощали» им это, делая текст маленьким, понимая, что именно это имелось в виду.
Так и появились все эти страницы с ошибками, потому что все разработчики первых броузеров сделали суперлиберальные, дружелюбные и терпимые программы, которые любили вас за то, какие вы есть, и не наказывали за ошибки. И мы получили кучу ошибок, и принцип Постела оказался неэффективен. На эту проблему не обращали внимания долгие годы. В 2001 году Маршалл Роуз (Marshall Rose) наконец-то написал (tools.ietf.org/ html/rfc3117):
Вопреки интуиции, принцип надежности Постела (будь консервативен в том, что отправляешь, и снисходителен к тому, что принимаешь) часто ведет к проблемам в развертывании решений. Почему? Когда выходит новая реализация чего-либо, она сначала сталкивается лишь с ограниченным набором существующих реализаций. Если эти реализации следуют «принципу надежности», то ошибки в новой реализации могут остаться незамеченными. Тогда новая реализация получает некоторое, хотя и не очень широкое, распространение. С появлением новых реализаций процесс неоднократно повторяется. В конце концов не вполне корректная реализация наталкивается на другие реализации, настроенные не столь либерально, как предшествующие. Легко представить себе, что произойдет.
Нужно отдать должное Джону Постелу за его огромный вклад в появление Интернета и не стоит винить его за этот несчастный принцип надежности. 1981 год — давняя история. Если бы Постел знал, что 90 миллионов людей без специальной подготовки и отнюдь не программистов станут создавать веб-сайты и делать это со всевозможными ошибками, а первые броузеры ввиду ошибочного милосердия их авторов станут прощать эти ошибки и все равно отображать страницу, он бы понял, что его принцип не верен и что на самом деле идеалисты веб-стандартов правы, и Сеть «должна была» строиться на очень и очень строгих стандартах, и каждый броузер должен был быть решительно несносным, показывая все ошибки, а разработчика, не сумевшего «быть консервативным в том, что делаешь», следовало лишать возможности публиковать свои страницы где бы то ни было, пока не научится правильно работать.
Но, конечно, если бы это произошло, возможно, у Сети могло и не быть такого взлета, а мы все, скажем, пользовались бы гигантской сетью Lotus Notes под управлением AT&T. (Бр-р-р.)
Если бы да кабы... Что теперь говорить. Мы там, где мы есть. Мы не можем изменить прошлое — только будущее. Да и будущее-то изменить не так просто.
Если бы вы были прагматиком в команде Internet Explorer 8.0, то в вашей памяти были бы выгравированы слова Реймонда Чена. Он описывал, как Windows XP пришлось эмулировать ошибочное поведение старых версий Windows (blogs, msdn. com/oldnewthing/archive/2003/12/23/45481. aspx):
Поставьте себя на место покупателя. Вы купили программы X, Y uZ. Потом вы обновились до Windows XP. В результате ваш компьютер стал регулярно зависать, а программа Z не работает вообще.
Вы скажете друзьям: «Не обновляйтесь до Windows XP. Она виснет и несовместима с программой Z». Вы же не будете заниматься отладкой, чтобы выяснить, что зависание вызывает программа Х, а программа Z не работает потому, что использует недокументированные сообщения окон! Вместо этого вы просто вернете Windows XP и потребуете назад деньги. (Вы купили программы X, Y и Z достаточно давно, и 30-дневный период для возврата истек. Так что все, что вы можете вернуть, — это Windows XP.)
Сразу приходит в голову... хм-м-м... что сегодня можно написать иначе:
Победа идеалистов над прагматиками в Microsoft, о которой я говорил в 2004 году, — прямая причина того, что Vista получает ужасные отзывы и плохо продается.
А как это относится к команде IE?
Поставьте себя на место покупателя. Вы посещаете 100 сайтов в день. Затем вы обновились до IE 8. И теперь половина страниц неправильно отображается, а Google Maps не работает вообще.
Вы скажете друзьям: «Не обновляйтесь до IE 8. Он неправильно отображает страницы, а Google Maps не работает вообще». Вы же не станете просматривать исходный код страницы, чтобы определить, что на сайте X-нестандартный HTML, а Google Maps не работает потому, что использует нестандартные объекты JavaScript из старых версий IE, которые так никогда и не были одобрены комиссией по стандартизации? Вместо этого вы просто удалите IE 8. (Сайты вам неподвластны. Те, кто разрабатывал некоторые из них, уже умерли. Так что все, что вы можете сделать, — это вернуться к IE 7).
Итак, если вы разработчик в команде IE 8, то первым вашим побуждением будет сделать то, что всегда работало на рынках «серия-ко-многим». Вы решите добавить в протокол небольшое согласование, чтобы продолжать эмулировать старое поведение для каждой страницы, которая не сообщит явно, что она ожидает нового поведения, так что все существующие страницы будут работать по-прежнему, а новое красивое поведение достанется только тем сайтам, которые поставили у себя флажок, говорящий программе: «Эй! Я понимаю IE 8! Пожалуйста, осчастливьте меня Благодатью IE 8!»
И действительно, именно о таком решении команда IE сначала объявила 21 января. Веб-броузер должен был молча поддерживать существующие страницы, действуя как старый, напичканный ошибками и ненавидимый веб-разработчиками IE 7, чтобы никому не пришлось модифицировать свой сайт.
Прагматичный программист сказал бы, что первое решение команды IE было правильным. Но молодые идеалисты «стандартов» взбунтовались.
Они заявили, что IE должен предоставлять поведение по стандартам без особого тега «Эй! Меня протестировали в IE 8». Их тошнило от специальных тегов. На каждой чертовой странице нужно было сделать тридцать семь уродливых хаков, чтобы ее было нормально видно в пяти или шести популярных броузерах. Хватит уродливых хаков! Будь они прокляты, эти восемь миллиардов страниц!
И команда IE сделала резкий поворот. Их вторым — надо думать, не последним — решением стал идеалистический подход: обращаться со всеми сайтами, заявляющими о своей «совместимости со стандартами», как с разработанными и протестированными для IE 8.
Почти все сайты, которые я посетил в IE8, отображались с теми или иными искажениями. Сайты, на которых много JavaScript, обычно вообще мертвы. У некоторых страниц некоторые проблемы отображения: что-то не на том месте, вместо всплывающего меню — раскрывающееся, а посредине — откуда-то взявшиеся полосы прокрутки. На некоторых сайтах проблемы видны не сразу: они выглядят нормально, но потом оказывается, что какая-нибудь важная форма не отсылается или ведет на пустую страницу.
И это ошибки не страниц. Обычно это веб-сайты, тщательно построенные в соответствии со стандартами Сети. Но ни IE 6, ни IE 7 в действительности не соблюдали эти стандарты, поэтому данные сайты содержат маленькие хаки, типа «в Internet Explorer: подвинуть этот блок на 17 пикселов вправо, чтобы компенсировать ошибку в IE».
IE 8 — это тоже IE, но у него больше нет бага, имевшегося в IE 7 и двигавшего ту штуку на 17 пикселов влево от того места, где она должна была быть по стандарту. И теперь код, который был вполне оправданно написан, не работает.
IE 8 не в состоянии правильно отобразить большинство страниц, пока вы не сдадитесь и не нажмете кнопку «ЭМУЛИРОВАТЬ IE 7». Но идеалистам все равно: они считают, что все эти страницы нужно переписать.
Некоторые страницы невозможно переписать. Одни могут находиться на CD-ROM. Другие написаны теми, кого нет в живых. Большинство из них создано людьми, не имеющими ни малейшего понятия, что происходит и почему их страница, за которую они заплатили разработчикам 4 года назад, перестала работать.
Идеалисты возрадовались. Сотни их снизошли до блога IE, чтобы впервые в жизни написать что-то хорошее о Microsoft.
Я посмотрел на часы...
Тик-тик-тик.
Делом секунд было подождать пока в форумах начнут появляться сообщения вроде следующего (forums.microsaft.com/MSDN/ShowPost.aspx7Post-ID=2972194&SiteID=iy.
Я скачал IE8 и баги вместе с ним. Некоторые из моих сайтов, например «HP», трудно читать, потому что вся страница очень маленькая... Скорость соединения с Интернетом тоже иногда падала. При работе с Google Maps полно наложений, поэтому очень неудобно!
Да-а-а. Все самодовольные идеалисты смеются над этим новичком-идиотом. Но потребитель не идиот. Это ваша жена, к примеру. Так что перестаньте смеяться. 98% пользователей в мире поставит IE 8 и скажет. «В нем ошибки, и я не вижу своих страниц». И они абсолютно не разделяют глупый религиозный энтузиазм по поводу выпуска веб-броузера, который строго следует мистическому идеалистическому «стандарту», нигде реально не воплощенному. Им не интересны ваши объяснения по поводу хаков, портящих страницы. Им нужен броузер, который работает с реальными сайтами.
Итак, вы видите ужасающий пример пропасти между двумя лагерями.
Лагерь веб-стандартов напоминает троцкистов. Вы думаете что они -левое крыло, но если вы сделали веб-сайт, который претендует на поддержку стандартов, но на деле оказывается не так, то идеалисты превращаются в Джо Арпайо (Joe Arpaio), самого жестокого шерифа Америки. «ТЫ СДЕЛАЛ ОШИБКУ И ТВОЙ САЙТ ДОЛЖЕН СЛОМАТЬСЯ! Мне плевать, что 80% ваших сайтов перестанет работать. Я вас всех засажу в тюрьму, и вы будете носить розовые пижамы, есть сэндвичи за 15 центов и работать сидя на цепи. И мне плевать, если вся страна окажется в тюрьме. Закон есть закон!»
С другой стороны — прагматичный, чувствительный, теплый, белый и пушистый программист. «Почему бы не сделать режим IE 7 режимом по умолчанию? Одна строчка кода... Вжик! Готово!»
Раскрыть вам тайну? Я думаю, все будет так. Команда IE 8 скажет всем, что в IE 8 по умолчанию будет установлен режим веб-стандартов, и начнет долгое бета-тестирование, на протяжении которого будет просить всех проверить свои страницы в IE 8 и постараться заставить их работать. А ближе к выпуску окончательной версии, когда окажется, что только 32% всех страниц в мире отображается корректно, они скажут: «Ребята, нам очень жаль, мы действительно хотели, чтобы режим стандартов был установлен по умолчанию, но мы не можем поставлять неработающий броузер» и вернутся к прагматичному решению. Или не вернутся, потому что прагматики в Microsoft уже давно не у дел. В этом случае IE потеряет значительную часть рынка, что бесконечно обрадует идеалистов, а годовая премия Дина Хашамовича, скорее всего, не уменьшится ни на цент.
Видите? Правильного ответа нет.
Как обычно, идеалисты на 100% правы в принципах и, как обычно, прагматики правы на практике. Флейм будет продолжаться годами. Этот спор делит мир ровно пополам. Если вы знаете, где купить акции Священных Войн Интернета, то сейчас самое время это сделать.

 

Назад: Глава шестнадцатая. Формирование сообществ с помощью программного обеспечения
Дальше: Глава восемнадцатая. Почему форматы файлов Microsoft Office такие сложные (и как это обойти)