Компьютерра - Журнал «Компьютерра» №46 от 15 декабря 2005 года

Через несколько лет, когда «браузерные войны» закончились безоговорочной победой Microsoft и представить себе появление нового игрока на этом рынке было почти невозможно, Opera тихой сапой продолжала собирать с пользователей сорокадолларовую дань, ничуть не переживая из-за того, что правила игры изменились. Возможность бесплатного использования Opera появилась лишь в конце 2000 года - до этого разработчики разрешали только почувствовать вкус «самого быстрого серфинга», ограничивая срок бесплатной работы тридцатью днями. Впрочем, бесплатность оказалась довольно условной: пользователи бесплатной версии «расплачивались» с разработчиками, отсматривая рекламные баннеры.
      При этом нельзя сказать, что браузер Opera был лишен недостатков. Технологический пуризм разработчиков привел к тому, что отдельные сайты в Opera вели себя, мягко говоря, странно. Конечно, в идеальном мире полной поддержки стандартов для нормальной работы было бы более чем достаточно, но противостояние Microsoft и Netscape привело к тому, что многие сайты - чьи создатели ориентировались прежде всего на более распространенный IE - верстались исключительно под браузер от Microsoft, а на «видимость» в Opera даже не проверялись. Не обошлось и без вредительства: как заявляют норвежцы, Microsoft не раз вносила в верстку собственных сайтов изменения, ущемлявшие возможности Opera (вплоть до выдачи устаревшего CSS).
      Однако ни высокая стоимость продукта, ни ограниченная совместимость не помешали компании не только дожить до 2005 года, но и сформировать сообщество преданных пользователей, уверенных в превосходстве своего браузера над конкурентами. Любой пользователь Opera объяснит вам, что поддержка открытых стандартов и есть единственно правильный подход, а люди, не способные грамотно сверстать сайт, наверное, должны найти себе другую профессию. Также очевидно, что Opera - самый быстрый, надежный и безопасный браузер. И самый удобный.
      Разумеется, удобство - понятие субъективное, но вряд ли кто-то возьмется отрицать, что интерфейс Opera - при том, что сам пакет занимает скромную долю рынка - частенько служит источником вдохновения для разработчиков других браузеров. К тому же влияние Opera на развитие браузеров к рыночной доле отнюдь не сводится. И не исключено, что если бы не упрямство норвежских разработчиков, мы бы до сих пор думали, что нормальный менеджер загрузок в браузере - это ненаучная фантастика, а TDI (tabbed document interface) - непонятная трехбуквенная аббревиатура. Opera - это такой Давид, который, наверное, не в состоянии свалить Голиафа, но постоянно заставляет его двигаться вперед.
      Ну и в конце концов, где вы найдете компанию, создатель которой пообещает переплыть Атлантический океан, когда количество загрузок новой версии ПО превысит миллион? Конечно, тут тоже можно придраться: отважная команда, состоящая из CEO Opera Йона фон Тетчнера (Jon von Tetzchner) и PR-менеджера компании, так и не успела далеко отплыть от родных берегов. Но с другой стороны, и причины были весьма уважительные - PR-менеджер внезапно начал тонуть, и лишь вмешательство отважного руководителя спасло его от неминуемой гибели. Вы много знаете боссов, готовых спасти подчиненного, рискуя собственной жизнью?
      В начале декабря отважный мореплаватель Йон фон Тетчнер прибыл в Россию с дружественным визитом. Самолетом. На пользователей посмотреть и себя показать.
 

То есть даром

 

      Неудачная попытка вырваться за пределы норвежских фьордов имела место в апреле этого года (и была приурочена к выходу версии 8.0), а с этого времени в жизни компании Opera многое изменилось. С сентября 2005 года настольный браузер стал распространяться абсолютно бесплатно. Если прежде у компании было три источника дохода на этом рынке (поступления от продажи лицензий, доходы от рекламы, показываемой в браузере, и отчисления от онлайновых сервисов, доступ к которым встроен в Opera), то теперь остался только один - сборы от онлайн-сервисов (45 процентов от прежних поступлений). Не является ли это решение слишком рискованным? Что произойдет, если завтра, например, откажется от сотрудничества Google?
      - Я не думаю, что это случится, - говорит Йон фон Тетчнер. - Но даже если и так, мы не привязаны к Google. Нам нравится работать с ними, но если они откажутся, мы можем зарабатывать и с Yahoo!. Кроме того, мы получаем деньги не только от поисковиков, но и от Amazon, eBay и др.
      КТ: В первые десять дней было сделано 2,4 миллиона бесплатных загрузок. Сейчас уже можно говорить о том, как ваш отказ от продажи лицензий повлияо на популярность браузера? Есть какая-то статистика?
      - Думаю, рановато рассуждать об изменениях нашей доли на рынке. Могу пока сказать, что количество ежемесячных загрузок с нашего сайта удвоилось. Если раньше скачивали 1-2 млн. инсталляционных пакетов в месяц, то сейчас статистика показывает 2-3,5 млн.
      КТ: В интервью The Register вы заявили, что собираетесь удвоить свою долю рынка к концу следующего года…
      (Тут нужно заметить, что в статистике есть некоторые расхождения. Согласно большинству независимых отчетов, доля Opera не превышает двух процентов. Однако точный подсчет невозможен из-за того, что ради максимальной совместимости многие пользователи настраивают браузер так, что он идентифицируется сервером как IE. Возможно, оптимистичная оценка Йоном количества пользователей Opera объясняется учетом этих соображений).
      - Мы хотим взять столько, сколько нам дадут, хотя, конечно, маловероятно, что нам удастся занять первое место. В некоторых регионах наша доля уже составляет от пяти до десяти процентов. И бесплатность Opera - лишь первый шаг. Но это если брать только рынок настольных приложений. В других секторах - например, на рынке мобильных устройств - мы чувствуем себя гораздо увереннее. Много тяжелой работы, толика удачи - и мы вполне можем быть первыми.
 

Новый друг хуже старых двух

 
      На прямые вопросы, зачем компании понадобилось делать браузер Opera бесплатным, Йон фон Тетчнер предсказуемо рассказывает о желании захватить долю рынка побольше, не особенно вдаваясь в подробности, почему это желание проявляется именно таким образом. Но причины вполне очевидны. Во-первых, рынок настольных браузеров больше не является для Opera главным источником прибыли. По словам Йона, настольный браузер - всего лишь витрина, на которой компания показывает пользователям возможности собственных технологий. Это не означает, что приоритеты компании поменялись и разработка настольного браузера теперь дело второстепенное, но увеличение количества пользователей для нее сейчас важнее, чем «потерянные» на продаже лицензий деньги. Вероятно, выход бесплатной версии Opera для ПК был неизбежен, но очевидно, что процесс ускорился благодаря невероятному успеху Firefox, который быстро подмял под себя почти десять процентов рынка.
      КТ: А что вы думаете о Firefox, Йон? Почему он так популярен?
      - Его популярность есть следствие сразу нескольких факторов. Во-первых, разработчики Firefox написали очень хороший браузер. Во-вторых, они вовремя вышли с ним на рынок. А в-третьих, у них отличный PR.
      КТ: Но не безопасность браузера?
      - Думаю, что защищенность Firefox - это часть удачной PR-кампании. Конечно, многие переходили на Firefox, потому что он более защищен, чем IE. Но если бы пользователи действительно сравнивали браузеры по защищенности, полагаю, они бы выбрали Opera.
      КТ: Не кажется ли вам, что защищенность Opera - побочный эффект ее меньшей популярности?
      - Да, это важный момент. Выбирать браузер - все равно что выбирать район для жительства. Вы можете жить в благополучном районе, можете жить в неблагополучном. Opera - это благополучный «район», а, например, IE - нет. Конечно, если вы преступник, вам выгоднее атаковать IE, потому что в этом «районе» живет больше людей. Так что ваше замечание справедливо для всех браузеров с меньшей рыночной долей, чем у IE.
      КТ: Но если вы увеличите свою долю рынка…
      - Дело в том, что у каждой компании своя тактика борьбы с атаками. Если у вас прореха в браузере - что вы делаете? Вы загружаете патч, так? Но посмотрите на IE. Недавно Microsoft выложила очередной патч, затыкающий прореху, о которой было известно еще в апреле-мае. Им потребовалось полгода. Нам в этом смысле проще. Мы меньше, мы мобильнее, мы можем решать такие проблемы быстрее. Если мы нашли дыру в Opera в мае, то и затыкаем ее тоже в мае. Больше того: если Microsoft может позволить себе отложить решение каких-то не слишком актуальных проблем с безопасностью, то мы этого не делаем. Мы стремимся к браузеру с нулевым количеством прорех. Даже если найденная дыра не кажется опасной - мы закрываем ее. Даже если попасться на нее может совсем уж глупый человек - мы закрываем ее. Потому что далеко не все пользователи сведущи в технических вопросах, а наивного пользователя легко обмануть. И мы делаем все возможное, чтобы нашего пользователя нельзя было одурачить, независимо от того, разбирается он в компьютерах или нет.
      КТ: Что вы думаете о расширениях? Насколько они важны для пользователей Firefox и насколько они важны для пользователей Opera?
      - Я думаю, что вопрос, на самом деле, в другом. Что вы хотите получить от расширений? То есть сами по себе расширения - это, конечно, неплохо. Они существенно увеличивают возможности пользователей, и многим это нравится. Но в то же время этот вопрос требует очень осторожного рассмотрения, потому что расширения могут снизить уровень безопасности браузера. Мы думаем над этим, но не хотим, чтобы нам пришлось выбирать между безопасностью и функциональностью. Потому что каждый раз, когда нам приходится делать такой выбор, мы выбираем безопасность.
      КТ: Есть ли еще какие-нибудь функции в других браузерах, которые вы хотели бы реализовать в следующей версии Opera (в октябре вышла Opera 9 Technology Preview, но главные изменения пока коснулись поддержки новых стандартов и работы движка, не слишком отразившись на интерфейсе)?
      - Автоматические апдейты. Но мы еще не решили, насколько это востребовано. Вообще, у меня такое впечатление, что большая часть интересных функций как раз позаимствована у нас…
      КТ: А когда вы видите свои решения в других браузерах, что вы чувствуете?
      - Я думаю, что это… хм… нормально. Мы придумали хороший функционал. Приятно, что люди обратили на него внимание.
      КТ: Не обидно?
      - Я смотрю на это иначе. Кроме того, большая часть нашего функционала до сих пор уникальна. Вы, конечно, можете как-то имитировать функциональность Opera в Firefox, но для этого вам потребуется полтора десятка плагинов. И я чувствую, что мы идем в верном направлении, если люди прикладывают такие усилия, чтобы сделать другой браузер похожим на наш.
 

Opera vs. Microsoft

 
      КТ: У Opera были и есть некоторые проблемы совместимости с рядом веб-сайтов. К примеру, Opera долгое время не могла работать с Gmail. Вам потребовался почти год на обеспечение поддержки Gmail, так?
      - Да, мы уже поддерживаем XMLHttpRequest, на котором построена функциональность GMail. Проблема в том, что не всегда новые технологии базируются на открытых стандартах, и XMLHttpRequest - это яркий пример проприетарной технологии, неожиданно получившей широкое распространение. Это разработка Microsoft, но ее практически никто не использовал до Google. Когда мы поняли, что необходимо поддерживать и ее, то занялись кодированием, но разработчики Mozilla управились быстрее.
      Что касается открытых стандартов, мы пытаемся реализовывать их так быстро, как только возможно - даже если эти стандарты пока не очень распространены. Мы реализуем их на сто процентов. Но если мы говорим о проприетарной технологии, то очень трудно реализовать ее по-настоящему хорошо, пока кто-то не начнет ее использовать.
      КТ: Если вспомнить об истории отношений Microsoft и Opera. Сейчас-то вы можете нам рассказать, кто заплатил Opera 12,7 млн. долларов в мае этого года? Тогда вы не раскрыли ни источник платежа, ни причины, побудившие неизвестную компанию расстаться с такой значительной суммой.
      - Э-э-э… нет. Я не могу ничего рассказать. И не могу сказать, что это была Microsoft. Я даже не могу сказать, что это был крупный поставщик ПО. Единственная информация, которой я могу поделиться, - этот платеж был получен не от нашего клиента, этот платеж никак не повлияет на наш бизнес, и этот платеж был получен от крупной компании.
 

Мобильный Интернет

 
      КТ: Вам не кажется, что конкуренция на рынке мобильных браузеров вскоре будет более ожесточенной?
      - О, это будет очень интересный рынок. Что отличает нас от других - мы на этом рынке работаем уже довольно долго, и у нас немного другой подход. Все остальные вендоры делают WAP-браузеры. У нас же был семилетний опыт разработки веб-браузеров, и мы решили перенести этот опыт на мобильную платформу (сейчас то же самое пытается сделать Mozilla). Я думаю, что в ближайшие несколько лет произойдет окончательный переход от WAP к Web, и это окажет очень сильное влияние на всех, кто занимается бизнесом в Сети.
      КТ: Вы не чувствуете давления Microsoft на этом рынке?
 

      - Реальность такова, что Microsoft сейчас больше озабочена продвижением платформы в целом. Вот смотрите: есть рынок телефонов. Примерно пять процентов от этого рынка составляют смартфоны. Из них примерно 80-90 процентов работают под управлением Symbian. А все остальное делят между собой Palm OS, Linux и операционные системы от Microsoft.
      Кроме того, мы уже поставляем браузер для платформы Microsoft, и он прекрасно работает. Конечно, Microsoft не стоит недооценивать, но текущая версия их мобильного браузера слегка отстала от жизни. Конечно, они его улучшат, но вот будет ли он таким же хорошим, как… В общем, сделают ли они его достаточно хорошим? В этом году вышла новая версия платформы, но я не заметил принципиальных улучшений в браузере.
      Нам даже звонили из Microsoft - не сам Билл Гейтс, конечно, - и просили поскорее выпустить браузер для их платформы. В самой компании люди понимают, что этот конкретный продукт недостаточно привлекателен.
      КТ: Такая компания как Microsoft не может сделать браузер?!
      - Одно дело теория, а другое - практика. Сделать хороший браузер очень трудно. Вспомните, с чего начала Microsoft. Их настольный браузер тесно интегрирован в ОС. И этот монстр не так-то просто сделать пригодным для запуска на устройстве, у которого, скажем, всего 30-40 Мбайт памяти.
      У них намного больше денег. У них намного больше людей. Умных людей. Но факт остается фактом. Написать ядро нового браузера с нуля очень тяжело. Новых движков не появлялось на рынке уже семь, а то и десять лет. Все актуальные браузерные движки имеют долгую историю. Тот же Firefox - это когда-то Mozilla, Mozilla когда-то была Netscape и т. д.
      КТ: А КПК?
      - Да рынок КПК уже очень мал, и уменьшается. Можно сказать, что он практически исчез. Поговорите с сотрудниками PalmSource, и они вам расскажут, что люди не хотят больше покупать просто КПК. Им нужны телефоны с КПК.
      СК[Сергей Костенок. - Здесь и далее прим. ред.]: Кстати, о Palm. Вы собираетесь поддерживать эту платформу?
      - Palm очень сложная для поддержки платформа. Трудно понять, в какую сторону она будет развиваться, и просвета не видно. Я знаю кое-кого в PalmSource уже несколько лет. И мы время от времени обсуждаем возможность поддержки продуктов от Palm, но тут же возникает вопрос: какую именно ОС нужно поддерживать? Пятую версию? Шестую? Linux?
      Но владельцы КПК от Palm могут использовать наш пакет Opera Mini[Opera Mini - как раз тот самый «не WAP, но Web», о необходимости которого говорит Йон. Это мобильный веб-браузер, рассчитанный на платформы, которые Opera пока официально не поддерживает. Если вы не можете использовать Opera Mobile, но в вашем телефоне есть поддержка J2EE, то с помощью Opera Mini вы получаете возможность гулять по Интернету (странички при этом будут подгоняться под небольшие размеры телефонного дисплея, но за преобразование отвечает не движок браузера Opera Mini, а специальный прокси-сервер, предоставляемый Opera)], если их устройства поддерживают J2EE. Честно говоря, мы сами не тестировали Mini на Palm’ах, но, судя по отзывам пользователей, она работает. Не без некоторых проблем, но работает, и это довольно популярное приложение.
      Кстати, у нас много пользователей и в России, хотя это совсем новый продукт и официально он здесь не представлен. Но мы были поражены искусством русских хакеров, которые перевели Opera Mini на русский язык и вообще слегка ее «подкрутили». Конечно, мы не в восторге от того, что кто-то взламывает наше ПО, но в данном случае очень впечатлены результатом. Взлом подобного уровня вполне подходящая причина для работы на Opera. Мы уже брали таких людей на работу.
      КТ: А русские разработчики в вашей команде есть?
      - Нет. У нас есть русские сотрудники, но, кажется, из разработчиков никого. Сисадмином работает русская женщина.
      КТ: А с удаленными программистами вы не работаете?
      - Нет. Дело в том, что мы поставляем Opera на множество платформ, на множество устройств. Но ядро нашей технологии едино. И для того, чтобы не разрушить эту схему, нам нужна очень сплоченная команда, а сплоченность и аутсорсинг совмещаются плохо. Но благодаря нашему подходу мы можем быстро переключаться с платформы на платформу. Обычно нам требуется на это всего лишь несколько недель, хотя внутренний рекорд составил девять часов.
      В беседе также участвовали Сергей Костенок («ДК»), Илья Шпаньков и Тор Одланд (непосредственный руководитель спасенного в апреле PR-менеджера, на фото - слева).
 

ТЕХНОЛОГИИ: Мы наш, мы новый билд построим

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

      Майкл Кузумано (Michael Cusumano) - известный эксперт на рынке программного обеспечения, специализирующийся на вопросах стратегий развития продуктов и предпринимательства в области разработки ПО. Но Кузумано не только признанный теоретик, за его плечами богатый опыт руководства различными компаниями-разработчиками. Сейчас он возглавляет шестую по величине софтверную компанию в Индии Patni Computer Systems. Кроме того, он оказывает консультационные услуги ведущим мировым корпорациям, среди которых Alcatel, AOL, AT amp;T, Business Objects, Cisco, Ericsson, Texas Instruments, Toshiba и другие. Из-под пера профессора выходят не только научные труды, но и книги для широкого круга читателей, включая мировой бестселлер «Microsoft Secrets"[M. Cusumano, R. Selby, „Microsoft Secrets“. - The Free Press/Simon amp; Schuster, NY, 1995. - Здесь и далее примечания Константина Курбатова] (в соавторстве с Ричардом Шелби), который переведен на четырнадцать языков. В конце октября Майкл Кузумано посетил Россию в рамках конференции для разработчиков программного обеспечения[Мы писали о ней в „КТ“ #613 от 10 ноября 2005 года], где и прочитал предлагающийся вашему вниманию доклад. - К.К.
 
      В прошлом и позапрошлом десятилетиях было популярно так называемое нисходящее программирование (способ разработки программ, при котором программирование ведется методом «сверху вниз», от общего к деталям), сейчас набирает обороты программирование итерационное, то есть разработка ПО методом постоянного выпуска неких обладающих минимальной функциональностью промежуточных билдов, каждый из которых приближает ее (функциональность) к требуемой. Вторая тенденция, которую необходимо отметить, - это замещение бизнес-модели, состоящей в выпуске готового программного обеспечения, на оказание услуг и сервисов.
      Но прежде чем обсуждать эти тенденции, хотелось бы вернуться на тридцать лет назад. Вот выдержка из отчета НАТО 1969 года, посвященного разработке ПО. «Главные проблемы в системе разработки программного обеспечения состоят в следующем:
      n недостаточное управление требованиями, увлечение производством кода в ущерб дизайну ПО;
      n ошибки в оценках, недостаток мониторинга процессов, разобщенность программистов;
      n низкая продуктивность, отсутствие оценочных факторов, низкая надежность (ошибки);
      n слишком сильная привязка к оборудованию, невозможность повторного использования кода;
      n высокая стоимость разработки».
      Звучит знакомо, не правда ли? Уже предпринимались попытки решения этих проблем путем смены парадигмы программирования. В истории можно выделить несколько моделей: стиль IBM (совершенствование классической схемы; 1960-70-е годы), японский стиль («фабрики ПО», стабильные команды программистов, отлаженные процедуры, максимальное повторное использование кода; 1970-80-е) и стиль, предлагаемый SEI[SEI - Software Engineering Institute] (главным образом состоит в предварительном ранжировании требований к разработке и контроле соответствия этим требованиям на каждом этапе, с 80-х; в настоящее время предлагается уже пятая версия документа).
      Пока ни один из них не может целиком решить задачи любого проекта разработки ПО. Различия в бизнес-моделях, заказчиках, квалификации исполнителей и других параметрах приводят либо к неоправданному повышению стоимости продукта, либо к снижению качества и удлинению периода разработки. Поэтому сейчас разработчики концентрируются именно на новой итеративной методологии, характерной чертой которой является постоянный выпуск условно «готового» ПО, при постоянном дальнейшем его развитии и насыщении.
      Внутри нее можно выделить следующие процессы: спиральная разработка архитектуры (от ядра системы к подключаемым модулям), постоянный выпуск прототипов (для контроля функциональности), выпуск наравне с бетами регулярных стабильных версий (для контроля ошибок), применение нисходящего программирования в микромасштабах (особенно для систем реального времени), набирающее популярность экстремальное программирование[Очень рекомендую посетить сайт www.xprogramming.ru] (постоянное взаимодействие с заказчиком; воплощение прежде всего тех функций, которые именно сейчас нужны пользователям; написание одного и того же кода парой программистов: один пишет - другой смотрит, потом меняются). На рисунке видно, как соотносятся эти методики.
      Итак, прогресс в области разработки программного обеспечения, несмотря на проблемы, сходные с проблемами конца 60-х, не стоит на месте. Мною проводились ежегодные исследования - какие методики применяют те или иные компании при разработке ПО. Были изучены корпоративные стандарты большинства крупных мировых компаний-разработчиков софта. В Индии: Motorola MEI, Infosys, Tata, Patni; в Японии: Hitachi, NEC, IBM Japan, NTT Data, SRA, Matsushita, Omron, Fuji Xerox, Olympus; в США: IBM, HP, Agilent, Microsoft, Siebel, AT amp;T, Fidelity, Merrill Lynch, Lockheed Martin, TRW, Micron Tech; в Европе: Siemens, Nokia, Business Objects, и многих других. В результате можно выявить несколько основных тенденций. Так, почти все из перечисленных компаний постоянно выпускают бета-версии, регулярно изменяют и дополняют документы, описывающие базовую архитектуру будущего ПО. Все проводят тестирование нового куска кода в рамках всего проекта (так называемый регрессионный анализ, который можно сравнить с порядком, установленным на конвейере компании Toyota, - если кто-либо из рабочих заметил дефект, он обязан остановить движение всего конвейера), чтобы не потерять достигнутой стабильности и функциональности.
      Однако видны и различия. В первую очередь выделяется Индия, где высок процент применения парного программирования, всегда имеется детальное описание проекта (для сравнения, в США только 30% проектов имеют этот документ), относительно низкий уровень применения генераторов кода. Япония в этом плане не слишком отличается от Индии. В Европе же гораздо чаще применяют методику микроциклов, больше развит выпуск бета-версий с независимым бета-тестированием. Таким образом, очевидна тенденция перевода «человекоемких» технологий в страны с дешевой рабочей силой и активное применение новых «технологических» (вроде кодогенераторов) решений вкупе со стремлением к сокращению сроков разработки в европейских странах.
 

 
      Япония, со своей традиционной методикой разработки ПО, стоит как бы в стороне, однако можно отметить высокий уровень организации бизнес-процессов, что отличает ее от Индии. Поэтому Япония имеет одно важное преимущество перед другими мировыми центрами разработки: при очень высоком уровне производства кода (почти 500 тысяч строк в месяц на человека, тогда как в Европе 436 тысяч, в Индии - всего 209 тысяч) поддерживается минимальный уровень ошибок - меньше 0,02 (!) ошибочных строчек на тысячу (в США - 0,4, в Индии - 0,26). Добиваются они этого активным повторным использованием уже отлаженного кода и наличием детальных описаний проектов.
      Анализируя результаты работы компаний, исповедующих различные подходы к организации процесса, можно выделить следующие факты. Компании, выпускающие первый прототип, обладающий всего лишь 20% функциональности, в итоге уменьшали количества ошибок на 27%. Далее, регрессионное тестирование снижает количество ошибок на 36%, уточнение архитектуры конечного продукта на каждом этапе дает 55% снижения. Кстати, ранний выпуск работающих прототипов повышает общую производительность программистов на 35%. А если прототипы выпускаются ежедневно, то она вырастает почти вдвое - вот какой эффект имеет осязаемость результатов своего труда!
      Итак, по разным оценкам, более 60% программного обеспечения создается на основе новых методов организации рабочего процесса. Только в 36% случаев применяется нисходящее программирование с детально проработанным планом и подробными спецификациями до начала его реализации. Можно смело утверждать, что мир разработки ПО окончательно изменился и большинство компаний применяют смесь из обычного программирования и итеративных методик. Это свидетельствует о том, что ориентация софтверных фирм на рынок «вообще» сменилась ориентацией на решение задач конкретного пользователя.
      При сегодняшнем росте сложности разрабатываемого ПО неизбежен и рост удельного количества ошибок в нем, поэтому стремление к постоянному наращиванию скорости производства кода уже не может являться главной целью. Удивительно низкий уровень ошибок японских производителей при сохранении традиционного подхода вряд ли может быть применим в других регионах, так как для этого необходимо перенести туда и японский менталитет. Качество же индийского кода, продолжая расти, все-таки пока остается на недостаточном для современных задач уровне.
 

ТЕХНОЛОГИИ: На холодный конец

 
      Автор: Константин Курбатов
      В начале двадцатого века паровозы доставляли пассажиров из Москвы в Санкт-Петербург за десять часов. При этом их КПД не превышал семи процентов. То есть использовалась только одна четырнадцатая часть энергии дров и угля, а остальные тринадцать обогревали атмосферу. Конструкторы тех лет придумывали самые изощренные способы, дабы сохранить тепло.
      Процессоры в современных серверных стойках тоже обогревают атмосферу, однако в данном случае конструкторы преследуют диаметрально противоположную цель - отвести от чипа как можно больше избыточного тепла.
      Современные высокопроизводительные процессоры греются не хуже ламп накаливания; «топовые» модели производят до 130 Вт тепла, а порой и больше. Теперь представьте, что в одном сервере толщиной в один юнит (1,75 дюйма, около 4,4 см) может находиться два таких процессора, а юнитов в стойке - до сорока двух штук. Количеству выделяемых стойкой калорий позавидует иная тепловая пушка, обогревающая производственные помещения.
 
      Но это не все трудности, встающие на пути инженеров-разработчиков высокопроизводительных систем. Вторая проблема - малый размер процессоров. Чтобы отвести тепло с небольшой площади радиатора, необходимо обдувать его очень большим количеством воздуха, а значит, вентиляторы должны быть высокопроизводительными и, как следствие, шумными.
      Компания Cray - всемирно известная своими суперкомпьютерами, пошла по иному пути. Например, в модели ETA-10 была применена система охлаждения процессоров жидким азотом, что позволило вдвое повысить производительность. С эффективностью такой системы не поспоришь, однако ее цена заставляет задуматься даже военные ведомства. Так что применение этой технологии пока остается уделом сверхплотных и сверхпроизводительных систем стоимостью несколько сот тысяч и даже миллионов долларов.
      Другой способ - закрытые кондиционированные шкафы, куда подается уже сильно охлажденный воздух. Но и здесь есть свои трудности. Во-первых, стоимость подобных шкафов и затраты на их эксплуатацию хоть и в разы меньше, чем у системы на азоте, тем не менее весьма высоки. Несмотря на кажущуюся простоту, приходится искать решения множества технологических задач, таких как равномерное распределение холодного воздуха в стойке, интенсивный отвод теплого воздуха, герметичность. Становится очень важным правильное распределение (не всегда совпадающее с желаемым) серверов внутри стойки и прочие тонкости. Да и КПД такой системы охлаждения тоже оказывается не на высоте: получается тройная передача тепловой энергии - сначала охлаждается фреон, который затем охлаждает воздух, а воздух, в свою очередь, охлаждает процессоры.
      Специалисты российской компании Kraftway, изучив проблему, подумали: а зачем вообще нужен воздух в этой системе «теплых взаимоотношений»? И решили охлаждать процессоры сразу фреоном кондиционера.
      Однако не все так просто. Подумайте, легко ли конфигурировать систему, насквозь пронизанную трубками с фреоном?! Поэтому было решено охлаждать не сами процессоры, которые располагаются в разных серверах по-разному, а сначала отводить тепло от раскаленных невероятной вычислительной мощностью ядер тепловыми трубками. То есть один ее конец располагается на самом процессоре, отбирая тепло, а другой - выводится на заднюю стенку сервера. Тем самым упрощается не только конструкция охладителя, но и процесс замены серверов: достаточно отвинтить тепловую трубку и вынуть корпус из стойки, не останавливая и не разбирая всю систему охлаждения.