КТ: Что вы думаете о расширениях? Насколько они важны для пользователей 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). Добиваются они этого активным повторным использованием уже отлаженного кода и наличием детальных описаний проектов.