Октябрь 2011
Стратегия Microsoft в
отношении Visual FoxPro
Краткий исторический обзор эволюции и стратегии Visual FoxPro в
Microsoft за 15 лет
Кен Леви (Ken Levy)
Фирма Microsoft никогда не раскроет исходные коды СУБД VFP, потому что с
точки зрения бизнеса нет никакой причины, по которой это следовало бы
сделать, и есть целый ряд причин, чтобы этого не делать. Эволюция VFP
вступает в следующее десятилетие вместе с новыми и дополненными продуктами,
работающими с VFP, с проектами сообщества, такими, как VFPX, и конечно с
самим VFP-сообществом.
Стратегия фирмы Microsoft в отношении FoxPro на раннем этапе
Покупка в 1992 году за 173 миллиона долларов фирмы Fox Software оказалась
для Microsoft очень дальновидным решением, и это было самое крупное из всех,
когда-либо сделанных Microsoft к тому времени, корпоративных приобретений.
По-прежнему пользовалась популярностью СУБД dBase фирмы Ashton-Tate, у фирмы
Borland имелись СУБД Paradox, а также интегрированная среда разработки
PowerBuilder – продукт, главенствовавший тогда среди инструментов для
клиент-серверной разработки. От сделки с Fox Software фирме Microsoft нужны
были три вещи – коллектив разработчиков Fox, Fox-технология и доля рынка,
принадлежавшая покупателям FoxPro и FoxBase. Microsoft только приступила
тогда к разработке СУБД Access, и этот продукт в большей степени был нацелен
на опытных пользователей, хотя некоторое пересечение все-таки существовало.
Язык программирования Visual Basic пока еще переживал свои первые дни.
На пике, – он пришелся на 1995 год, – число FoxPro-разработчиков оценивалось
в 500 000, и в наличии имелись миллионы компьютеров, на которых работали
FoxPro-приложения (или на базе DOS, или в операционной системе Windows).
Только спустя почти 4 года, – не ранее, чем появилась версия VFP 5.0, –
стратегия Microsoft стала сосредотачиваться в большей степени на языке
программирования VB и в меньшей – на VFP. По сути дела, рост
пользовательской базы СУБД VFP и объема ее продаж сменился падением, а как
говорят в бизнесе: если вы не растете, вы умираете.
В первые годы после поглощения Fox Software фирма Microsoft вкладывала
огромные усилия и массу ресурсов в создание версии VFP 3.0. В Fox-команде
насчитывалось примерно 50 человек, и она имела большой маркетинговый бюджет.
В последующие годы выросла доля на рынке как СУБД Access, так и языка VB, и
они также в некоторых отношениях стали конкурировать с рынком VFP (а также в
области информационной поддержки продуктов), и ко времени выхода версии VFP
5.0 многие топ-менеджеры хотели, чтобы Microsoft просто прекратила на этом
развитие VFP. Фактически, на некоторое непродолжительное время так и было
сделано. Я присутствовал на том совещании, в котором участвовало 40 человек,
и где команде разработчиков Fox официально было объявлено о том, что VFP
прекратила свое существование. Это совещание проходило в самом начале 1996
года и привело к тому, что компания Gartner Group выпустила собственный
отчет, в котором говорилось о кончине СУБД VFP, что серьезно сказалось на ее
дальнейших продажах. Однако, члены Fox-команды вместе с сообществом подняли
большой шум, объединившись с людьми, вроде Эрика Раддера [Eric Rudder,
архитектор версии VFP 3.0, ставший техническим помощником Билла Гейтса (Bill
Gates)]. Эрик убедил руководство подразделения, занимавшегося инструментами
разработки, продолжать развитие VFP, сократив при этом объем выделяемых
ресурсов. На самом деле, главная причина, по которой VFP продержалась еще
одно десятилетие, на протяжении которого были выпущены еще 4 версий, связана
в большей степени с продажами ОС Windows, нежели с продажами самой VFP.
Существует очень много Windows-компьютеров, на которых работают
VFP-приложения. Когда Стив Баллмер (Steve Ballmer) скачет как мартышка и
выкрикивает «разработчики, разработчики, разработчики», его больше заботит
продажа ОС Windows, нежели продажа инструментов разработки.
История Visual FoxPro в фирме Microsoft
Для каждой новой версии VFP, например, для версий 6.0 и 7.0, сокращались
объем выделяемых ресурсов, численность коллектива разработчиков и
маркетинговый бюджет. Когда VFP включили в коробку с Visual Studio, это была
просто общая упаковка, без интеграции. Когда сообщество увидело VFP,
работающую в среде Visual Studio, и возможность ее выполнения на базе .NET
framework, они также осознали, что если развитие VFP пойдет по такому пути,
это очень отрицательно скажется на обратной совместимости FoxPro-кода, и
интерактивная среда разработки (IDE) VFP со временем будет утрачена. Фирма
Microsoft никогда не задавалась целью разрабатывать одновременно и
автономную VFP, и VFP для платформы .NET. Существование новой VFP,
предназначенной для платформы .NET, просто отнимало бы ресурсы, выделяемые
на развитие языков VB.NET и C#, затрудняло бы продажи Visual Studio и .NET
framework и вообще не имело бы никаких полезных результатов, поскольку
старый VFP-код нельзя было бы выполнять в том виде, как он есть.
Затем, после появления версии VFP 7.0, решено было сохранить VFP как
автономный продукт, не входящий в комплект Visual Studio, поскольку эта СУБД
не будет частью платформы .NET. Решение было оправданным и позволило
составить для VFP отдельный график поставки новой версии. С выходом каждой
новой версии предполагалось, что она является последней. Никто в
Fox-команде, ни один человек, не ожидал появления новой версии после выхода
VFP 8.0. Продажи с каждым годом продолжали сокращаться, и то же самое
происходило с маркетинговым бюджетом. Единственным способом, который
позволил бы нарастить и увеличить продажи VFP, было завершение работы над
Visual Studio и изъятие бюджета и ресурсов у этого продукта. В самом деле,
Visual Studio (а не Delphi или какой-то другой продукт, не принадлежащий
Microsoft) была самым серьезным конкурентом VFP. Большинство сотрудников,
занимавшихся маркетингом и менеджментом в фирме Microsoft, предпочли бы,
чтобы Fox-разработчики использовали Delphi.NET фирмы Borland, а не Microsoft
VFP, поскольку тогда их разработки базировались бы на платформе .NET, а не
на старой унаследованной модели COM. Модель COM превратилась во врага, от
которого надо было уводить людей, точно так же, как сегодня действующим
врагом для платформы Microsoft является связка HTML/JavaScript.
Над версией VFP 9.0 работала команда, насчитывавшая не более 8 человек, и
даже в этом случае, по мнению сообщества, версия VFP 9.0 оказалась лучшим
релизом, нежели версии VFP 7.0 и VFP 8.0. Вскоре после выхода версии VFP 9.0
фирма Microsoft решила создать для свободного распространения
Xbase-дополнение (add-on), чтобы поддержать продажи обновления для исходного
продукта, а также оптимистическое восприятие VFP. В результате появился план
проекта Sedna – предназначенного для скачивания пакета полезных примеров
приложений и утилит, сфокусированных на взаимодействии VFP с другими
продуктами Microsoft (платформой .NET, сервером SQL Server, пакетом офисных
программ Office, операционной системой Windows и так далее). Другой причиной
появления проекта Sedna было стремление отсрочить объявление конца VFP,
чтобы сохранить продажи версии VFP 9.0, а также защитить Fox-сообщество и
рынок труда для разработчиков, использующих этот инструмент.
Отказ предоставить исходный код Visual FoxPro
Обращение к фирме Microsoft с просьбой открыть базовый исходный код Visual
FoxPro является всеобщим (и логичным). Вот некоторые догадки относительно
того, почему Microsoft никогда не сделает исходный код Visual FoxPro
открытым. В VFP присутствуют технологии, например, оптимизированная
индексация Rushmore, которые используются в других продуктах этой фирмы – в
серверной СУБД SQL Server и в «настольной» СУБД Access. Это не одна и та же
база кода на языках C и C++, но многие методики и алгоритмы родом из VFP.
Фирма Microsoft смотрит на них как на интеллектуальную собственность,
активы, с которыми она не хочет расставаться.
Но две более важные причины не имеют ничего общего с причиной, названной
выше. Они связаны с бизнесом. Тогда, как продажи VFP не являются ее главной
заботой, внимание фирмы Microsoft сосредоточено на продажах Visual Studio и
на том, чтобы была принята вся платформа Microsoft (целый набор продуктов и
услуг). Выпуск VFP в виде открытого исходного кода привел бы к сокращению
числа VFP-разработчиков, использующих текущую (современную) платформу
продуктов Microsoft, но это также может привести к тому, что кто-то или
какая-нибудь фирма создадут продукт, соперничающий с продуктами Microsoft. В
фирме Microsoft не хотели бы наблюдать, как этот код используется для
развития конкурентоспособного продукта, и там также не хотели бы видеть, как
создание этого нового продукта вклинивается в продажи Visual Studio или
препятствует распространению платформы .NET.
Стратегия Microsoft в отношении Visual FoxPro на завершающем этапе
В последние 5 лет существования Visual FoxPro в фирме Microsoft, когда я был
ее последним менеджером по продукции (Product Manager) (маркетинг и
сообщество), стратегия сводилась к сбыту VFP членам сложившегося сообщества
пользователей (главным образом посредством обновлений), к всемерному
сохранению сильного Fox-сообщества, а также к тому, чтобы заставить
VFP-разработчиков перейти на другие продукты фирмы Microsoft (платформу .NET
и SQL Server). В этой своей роли я всегда видел себя в 2 ипостасях: в одной
я представлял фирму Microsoft как ее сотрудник, а в другой – был членом
FoxPro-сообщества, который в стенах Microsoft делает для Fox все, что в его
силах, ради развития, сохранения, продвижения и помощи VFP и сообществу,
насколько это возможно. Примерно половину своего времени я тратил на
маркетинг VFP внутри фирмы Microsoft, в штаб-квартире в Редмонде (Redmond) и
в периферийных отделениях, на информирование и поддержку позитивного
представления о VFP как о живом продукте.
Решения по вопросам VFP-стратегии принимало вышестоящее руководство фирмы
Microsoft, а не основная Fox-команда. Никто из членов основной Fox-команды
не обладал правом принимать решения, связанные с маркетинговым бюджетом или
выделяемыми ресурсами, или определять дальнейшие действия после поставки
каждой новой версии. В команде было несколько ключевых фигур, которые,
вероятно, совместными усилиями продлили жизнь VFP как минимум на одну
дополнительную версию и на несколько лет.
Я думаю, еще одной движущей силой, позволившей на столь долгий срок продлить
существование VFP после выхода версии 6.0, была преданность пользователей.
Но к моменту выхода версии VFP 9.0 суммарный годовой объем продаж всех
версий VFP приносил доход, который был меньше того, что фирма Microsoft
получала от продаж Visual Studio за один день. Соотношение затрат на
развитие VFP и суммы приносимого ею дохода (return on investment , ROI) было
много меньше в сравнении с вложением дополнительных ресурсов в Visual Studio
и языки платформы .NET. Плюс, некоторые члены коллектива разработчиков Fox
готовы были совершить переход внутри фирмы или покинуть Microsoft, и
практически невозможно было найти им квалифицированную замену. Полезно
взглянуть на все это с точки зрения перспективы, если вы рассматриваете
Visual Studio как продукт, конкурирующий с VFP, хоть бы даже они и
принадлежали одной фирме. Вспомните, когда фирма Apple работала одновременно
над компьютерами Mac и Lisa, уцелел только один из них. Если говорить о СУБД
VFP, она продержалась целое десятилетие после того, как была по существу
лишена жизни (и потеряла из-за этого статус стратегического продукта).
Вступая в следующее десятилетие
15-ого января 2010 года заканчивается основная поддержка версии VFP 9.0.
Хотя платная расширенная поддержка просуществует еще 5 лет, я не предвижу
появления каких-либо дополнительных исправлений (hotfixes) или чего-то еще,
что будет сделано для VFP; разве только в исключительном случае, когда
проблемы работы VFP в операционной системе Windows 7 не позволят
пользователям, эксплуатирующим VFP-приложения, выполнить обновление до
последней версии ОС Windows. Некоторые предполагают, что фирма Microsoft
убила VFP преждевременно, но можно по-другому взглянуть на закулисную
историю и убедиться в том, что VFP просуществовала еще много лет и пережила
несколько версий сверх того, что было запланировано. Хотя фирма Microsoft
могла бы сделать для VFP больше, реальных шансов для этого у нее просто не
было при условии, что она одновременно продвигала на рынке и отдавала
ресурсы СУБД Access, языку VB, а затем среде разработки Visual Studio.
Только те разработчики, которые пользовались FoxPro, действительно понимают,
что это был за продукт, и чем он пока еще является.
Программирование Visual
FoxPro
Приемы эффективной работы, часть VI
Джим Бут (Jim Booth)
В этой серии статей мы рассмотрели широкий круг вопросов, связанных с
разработкой высококачественных систем программного обеспечения. Мы
проанализировали методы, которые позволяют обеспечить эффективность нашей
деятельности, направленной на разработку, а также сделать результативной
попытку уменьшить риск появления ошибок в нашем программном коде.
В данной статье из этой серии мы начнем заглядывать в будущее и займемся
исследованием того, что можно сделать сегодня, чтобы создаваемые нами
системы программного обеспечения могли развиваться с точки зрения их
функциональности, а также адаптироваться к технологическим изменениям, с
которыми мы сталкиваемся.
Каким образом удается нам разрабатывать свои программы так, что мы
оказываемся в состоянии примениться к неизвестной будущности и способны
воспользоваться технологиями, которые не можем представить себе даже
мысленно? Даже для того, чтобы только начать отвечать на этот вопрос,
существует лишь один путь – оглянуться назад и посмотреть, что тогда помогло
нам адаптироваться к изменениям, через которые мы уже прошли.
Использование
средств перевода Google из программы VFP
Дуг Хениг (Doug Hennig)
Приложение Stonefield Query достаточно легко перевести на другой язык: все
строки, отображаемые пользователю, хранятся в ресурсном файле и мы
предоставляем редактор ресурсов, который позволяет разработчику перевести
строки на другие языки. Это означает, что кто-то должен сделать перевод, а
потом поддерживать перевод в актуальном состоянии, по мере выхода новых
версий. Сами понимаете, это довольно трудоемкая задача.
Вдохновленный докладом Кристофа Волленхаупта "Googlefy Your Apps"на
конференции Southwest Fox 2011, я обратился к Google Translate API для
автоматизации перевода и расширения числа языков, на которые мы переводим
элементы интерфейса. Решение оказалось довольно простым.
Интересные часы с
использованием GDI+X
Бернар Бут (Bernard Bout)
Некоторое время назад я наткнулся интересные часы, созданные средствами
HTML5 с использованием элемента canvas. Так как элемент canvas похож на
imgcanvas в составе GDI+X, я решил создать похожие часы средствами GDI+X.
Если нужно сделать изменения, откройте вкладку Favourites в вашем редакторе
свойств и сделайте необходимые изменения.
Если нужно изменить размер, тогда измените контейнер класса и запустите
форму.
На диске, сопровождающем журнал, включена форма с примером использования
часов с разными размерами и некоторыми измененными свойствами.
String.Format для VFP
Эрик Селье (Eric Selje)
Если вы не пользовались методом String.Format() в языке C#, это истинное
удовольствие. Среди встроенных возможностей VFP нет ничего подобного, но мы,
безусловно, можем смастерить свой собственный эквивалент. Он облегчит чтение
и сопровождение нашего кода. Данная статья продемонстрирует, почему и как
стоит этим заняться.
Насколько это в моих силах, я стараюсь выполнять максимум работы в среде
Visual FoxPro, но бывают случаи, когда существует другое инструментальное
средство, прямо предназначенное для решения стоящей перед нами задачи, и
тогда мы знакомимся с иными возможностями и философией других языков
программирования. Недавно я переносил для заказчика данные из настольной
СУБД Access в среду SQL Server/ ASP.Net и использовал язык C# для
программирования логики веб-страницы. По моему мнению, переход на язык C#
является довольно легким для программистов, работающих с Visual FoxPro,
поскольку синтаксис достаточно похож, чтобы вы не чувствовали дискомфорта.
Работая с языком C#, я начал испытывать привязанность к одному конкретному
методу – String.Format(). Эта команда похожа на VFP-команду TRANSFORM(), но
обладает много большими возможностями.
