| « Flex 3 beta 2 и Adobe AIR beta 2 доступны! | Обзор русскоязычных ресурсов по Silverlight » |
Новости о Flex 3 beta 2: продолжение
В трудах праведных я не успел вовремя отреагировать в блоге на целых два поста Теда Патрика, касающихся нововведений во Flex Builder’е.
Итак, в среду Тед посвятил свой пост CRUD-мастеру. Мы говорим наше Вау! Нет, действительно круто. Посмотрим, как будет работать в действительности, что за код генерится. Но у меня есть некоторые ремарки.
Как себе это представляю я. Данный вариант Flex Builder’а не содержит в себе элементарных фич, присущих многим бесплатным (не говоря о коммерческих) IDE на базе платформы Eclipse. Я много раз перечислял эти фичи, но могу сразу вспомнить элементарные две. Это темплейты для кода и квикфиксы. А их нет и не присутствуют ни в какой форме. Конечно, мы пока не видим планов на release candidate, но, кажется мне, что тенденция налицо. Больше фич. Вместо того, чтобы сделать конфетку из старых.
И что мне еще кажется странным, так это сам путь развития. Ведь совершенно очевидно, что все эти генераторы кода по сути являются отдельным плагином, интегрированным во Flex Builder. И вот что мне непонятно. Почему бы дествительно не доработать саму среду, а подобные фичи выпускать в виде отдельных дополнительных плагинов отдельной командой разработчиков? Пускай за отдельные деньги. Но все же. Ведь подобный плагин уже существует и довольно давно. Мало того, он в чем-то даже более продвинут. Называется он Clear Data Builder и разработан Farata Systems на основе генератора кода DaoFlex. Данный генератор работает только под Flex Data Services (LiveCycle Data Services), хотя поддерживается и openamf. То есть речь идет о remoting’е на базе J2EE. Но с точки зрения генерируемого клиентского кода примеров он явно превосходит представленные скриншоты. Но посмотрим. А желающие могут изучить документацию по Clear Data Builder’у.
Вернемся из нашего лирического отступления. Итак, я глубоко убежден, что вместо того, чтобы обвешивать продукт подобными фичами и заявлять, что он стал значительно круче, стоит довести до ума существующее, а подобные решения поставлять в качестве дополнительных плагинов. А то получится, что формально забота о разработчике есть, но она какая-то не вглубь, а вширь.
Но вот что точно вглубь, так это забота о дизайнере. В четверговом посте Тед пишет в основном об усовершенствованиях для них. Ну тут прямо все совершенствуется очень круто. Сами посмотрите.
О дайте, дайте же мне Flex Builder Express! Пусть будет такая версия без CRUD-визарда, без Design View. Можно даже бесплатно. Но зачем мне, разработчику, который пишет код больше времени, чем генерирует серверный код с DTO, чем работает в Design View (вовсе его не открываю), говорить, что обо мне заботятся и делают продукт лучше? То есть покупая продукт, я плачу больше половины его стоимости за фичи, мне ненужные, но как раз самые дорогостоящие с точки зрения разработки!
Ну хэлп стал красивее, и это круто! А в довесок (помните как в старые советские времена к книгам и продуктам продавали довески в виде чего-то не сильно нужного, но что обязательно надо продать?) прилагают лежавшую до этого в запасе JSEclipse. Вообще, создается впечатление, что нам, разработчикам, пытаются впарить старый продукт, но в новой, красочной и большой упаковке! На боках которой умещается очень много красивых картинок и рекламных слоганов.
В общем, пока обзоры Теда Патрика лично меня разочаровывают. Посмотрим дальше. Тед обещает интересный рассказ про дебагер и профайлер. Хоть здесь постарались! Также интригующе звучит «FLEX 3 PRICE Enhancements». То есть цены стали больше или все же появились разные комплектации продукта с разными ценами? Второе было бы интереснее. Ну и в «FLEX 3 FAMILY Enhancements» нам очевидно представят Thermo. Посмотрим, что это такое 
В общем, будем смотреть вперед с оптимизмом! Чего и вам желаю. Прорвемся! 
Bookmark this article at
Трекбек адрес этой записи
URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)
12 комментариев
во флексе единственное что люблю, так сам SDK, а билдер как был позорищем так похоже и будет.
Всетаки у макромедии был и есть(но уже у Адоба) один из лучших маркетинговых отделов в мире.
Они засунули флэш плеер на каждую машину, и они же умудряются паять самую дебильные IDE и в уродских упаковках, и продовать их как золотые.
С каждым днем я хочу с ними познакомится все больше и больше, хотя бы просто посмотреть на этих гениев(без шуток).
Психология такова, что люди любят новенькое, и им это новенькое скармливают. Еще фактор: стоимость доработки/отладки старых фич и стоимость разработки новых соотносятся, по оценкам британских ученых, как 80 и 20. 20 процентов времени требуется, чтобы написать что-то работающее. 80 нужно, чтобы довести это до ума. Так вот у Адоба почти все сделано на 20%. И новые фичи, о которых пишет Тед, с высокой вероятностью будут обладать той же степенью "сделанности".
Мы пользуемся не средой разработки - но ее прототипом. Платным Ж-)
Но прочь сомненья. Вчера в Киеве мне был показан продвинутый 3Д-движок и написанное на нем приложенье. Автор пишет код в Far'е.
Психология такова, что люди любят новенькое, и им это новенькое скармливают.
Ну вроде того. Чтобы представлять сруду разработки потенциальным покупателям нужно произвести впечатление. Но встречают по одежке...
И вот что мне непонятно. Почему бы действительно не доработать саму среду, а подобные фичи выпускать в виде отдельных дополнительных плагинов отдельной командой разработчиков? Пускай за отдельные деньги.
А нет никакой информации, что Adobe готова заплатить эти отдельные деньги в виде очень хорошей суммы?
Чисто теоретически, с точки зрения маркетинга, чтобы выжить в конкурентной борьбе, я бы, на месте главы соотв. подразделения Adobe - заплатит бы очень приличные бабки, за это.
>чтобы выжить в конкурентной борьбе, я бы, на месте
>главы соотв. подразделения Adobe - заплатит бы
>очень приличные бабки, за это.
Чисто теоритически с точки зрения экономики, ты бы разорился если бы платил каждый раз бабки чтобы довести все до ума.=)
В основном причина успеха заключалась в том, что компании поручили бОльшую часть работы другим компаниям. Они покупали компоненты у поставщиков с хорошей репутацией, а затем собирали их в единое целое на своих заводах. Производители компьютеров не тратили время и деньги на разработку и создание блоков питания, дисководов, материнских плат и других компонентов. Они давали возможность другим компаниям ... Если бы производители компьютеров разрабатывали все блоки самостоятельно, они бы затрачивали на выпуск каждой модели неизмеримо больше усилий.
...
Достаточно рассмотреть деятельность компании Compaq, чтобы убедиться в высокой эффективности такого подхода. Создавать ли объект самостоятельно или покупать его у других программистов -- решение зависит лишь от наличия денег и времени."
(c) "Java 2. Том 1. Основы." К. С. Хорстман, Г. Корнелл. Издательский дом "Вильямс", 2007
Деньги по моему водятся. А вот потратить годы на доводку продукта... к тому времени сменятся пару фреймворков...
В итоге потенциально получается перманентное отставание. Глупо, IMHO. Тем более что "технологически" - платформа Eclipse дает широкие возможности отдать реализацию на аутсорс.
Кстати, флексовский фреймворк - не индусы, случайно, программировали?
RSS лента комментариев этой записи