вторник, января 31, 2006

Mtasc 1.12 вышел

Вышла новая версия бесплатного компилятора ActionScript 2-классов Mtasc. Теперь он дорос до версии 1.12. Улучшения новой версии:

  • Возможность использования опции -keep с опцией -header.

  • Возможность объявления dynamic static классов (?).

  • Улучшенная поддержка кривых в Flash 8.

  • Возможность доступа к приватным переменным внутри локально объявленных функций.

  • Улучшенная скорость парсинга swf.

Качаем!

воскресенье, января 29, 2006

ArcWeb Explorer от ESRI

ESRI (Environmental Systems Research Institute - Исследовательский Институт Систем Окружающей Среды), который известен своими продуктами, связанными с GIS (геоинформационные системы), наконец-то выпустил первое полноценное web-приложение, основанное на Flash-платформе. ArcWeb Explorer написан с использованием Flex 1.x и использует ESRI's ArcWeb Services.

Самое интересное, что этот замечательный продукт (сделан весьма неплохо и впечатляюще) подтвердил мои давние мысли о том, что GIS-приложения, сделанные для Flash-платформы, имеют весьма перспективное будущее. Особенно в свете выхода Flex 2. Самое интересное, что у нас в России есть свои фирмы, разрабатывающие перспективные GIS-приложения. В частности при моем родном Факультете Информатики возникло в свое время НПО "СИБГЕОИНФОРМАТИКА". А мой одногруппник возглавляет другую перспективную фирму, занимающуюся GIS, ИндорСофт. После этой небольшой порции ненавязчивой рекламы остается спросить - а видят ли отечественные производители целесообразность в производстве GIS-продуктов для web? И если видят, то осознают ли, что более подходящей платформы, чем Flash для таких продуктов просто не существует (тут я до кучи упомяну еще такой сервис как Yahoo Maps, который, как замечается многими, гораздо более юзабелен, чем Google Maps)? И скорый выход Flex 2 - это просто открытая дорога в будущее :)

пятница, января 27, 2006

Eclipse 3.1.2

Пока готовится следующий релиз Eclipse (3.2) вышел небольшой промежуточный релиз 3.1.2. Качаем?

FlashCommand 0.9.1

Мы уже писали о модификации инструмента FlashCommand от Майка Чамберса. Там меня все пугал один неприятный баг, который я воспринимал как фичу. А именно то, что он не позволял последовательно компилировать несколько fla-файлов в пакетном режиме: компиляция следующего запускалась когда еще не закончилась компиляция предыдущего. Это делало практически невозможной сборку проектов, состоящих из нескольких fla-файлов, с помощью Apache Ant. Немного поработав над кодом, я понял, что это была не фича, а все-таки баг. На данный момент я его исправил. В итоге мы имеем версию 0.9.1. Исходники для Visual Studio 2003 можно скачать отдельно.

Просьба всем заинтересовавшимся потестировать и сообщать о возможных багах и пожеланиях.

вторник, января 17, 2006

FlashCommand 0.9.0 update

Мы уже писали о новой версии FlashCommand. На данный момент я ее слегка обновил и улучшил. Теперь все супер. А именно:


  • Приложение работает под .Net 1.1.

  • Прилагаются исходники.


Повторю, что FlashCommand 0.9.0 можно скачать здесь. Исходники для Visual Studio 2003 можно скачать здесь. Пример ant-сборки с помощью FlashCommand здесь. Прошу прощения за неудобства при скачивании. Хостинг дурацкий, но какой есть.

Уще раз напомню как сей продукт устанавливается: просто копируем в каталог FlashCommand вашего каталога Program Files. Далее путь к этому каталогу добавляем в переменную окружения PATH (думаю, вы это умеете). Перезагружаете компьютер и просто набираете из коммандной строки: FlashCommand. А если у вас установлен Apache Ant или Eclipse, то вы можете попробовать build.xml из примера.

Остальные аспекты освящены в предыдущем посте. Вопросы, пожелания, комментарии, сообщения о багах - приветствуются.

понедельник, января 16, 2006

FlashCommand 0.9.0 с возможностью добавлять classpaths

В течение последней недели я тратил часть своего свободного времени на выработку технологии сборки flash-проектов, которая бы преследовала следующие цели:


  • Она должна надежно собирать мой проект.

  • Она должна по возможности быстро собирать мой проект.

  • Она должна собирать мой проект легко и непринужденно на любой Windows-машине (при условии, конечно, что там будет установлено необходимое программное обеспечение).

  • Эта методика не предназначена для опенсорсной flash-разработки.


В общем-то, неизвестных много, но много и известных. Безусловно, для сборки должен использоваться ANT. Это зарекомендовавший себя инструмент. К тому же он прост в использовании.

Быстроту мне обеспечит mtasc. Через задачу exec он легко интегрируется в ant'овский скрипт. Но обладает существенным недостатком: он не компилирует mx-классы. Поэтому мне не обойтись при компиляции начальной swf-ки, а также при изменении элементов дизайна приложения средой разработки Flash. Также я испытываю острую необходимость компилировать билды с помощью среды разработки Flash - скажем так для надежности (это все-таки поддерживаемая коммерческая среда). Но, скажем, ежедневные билды будут компилиться всего раз в день и, в общем-то, этот процесс может быть и продолжительным.

Ну вот, собственно, тут и начинается основная заморока: приложение в среде Flash трудно компилировать из командной строки. Есть ряд способов (сводящихся в основном к использованию jsfl), которые более-менее позволяют это делать, но у всех способов есть один существенный недостаток: пути к классам должны прописываться либо в среде Flash, либо во fla-файле. Это, по сути, напрочь убивает все преимущества компиляции из командной строки. И это служило основным камнем преткновения во всей замышляемой цепочке.

И тут возникает выбор: воспользоваться ANT Task'ами FlashAnt Арала Балкана или FDT (в котором тоже есть - fdt.flashCompile)? Это кроссплатформенные решения (а платформы всего две и в связи со спецификой России меня Маки не интересуют). Есть более простое решение.

И тут я вспомнил про старый добрый и, вроде, ничем не примечательный инструмент Майка Чамберса FlashCommand. Он бесплатен, с открытым исходным кодом, написан на C# под .Net. И сам Майк пишет, что его можно улучшать на здоровье:

Use at your own risk. The code is not documented well, and I haven't touched it in 6 months, but I wanted to make it available to anyone who wanted to work on it or improve it (and it could use a lot of improvements).

Ну вот я и улучшил. Версия Майка была 0.8.2. Теперь можно скачать версию 0.9.0.

Мною сделаны мелкие багфиксы, поддержка Flash 8 (при нормальной инсталляции последняя версия определяется и запускается автоматически, без указания путей), и, главное, возможность задавать classpaths в коммандной строке. Опять же, если Flash был нормально установлен и у вас на машине есть админские права, все должно работать. Задается classpath с помощью ключа -cp , за которым следуют пути к классам сплошняком через ;. Если в этой строке будут пробелы, то можно заключить ее (и остальные такие строки) в кавычки. Ниже приведу все доступные ключи:


Использование:

FlashCommand.exe -e | -c | -p [-q] [-v] [-x] [-q] (-s ) ([-l] []) ([-o] ) ([-f] ) ([-t] ) ([-cp] <"classpath1;classpath2;classpath3">)

-version : Выводит информацию о программе.
-help | Выводит информацию об использовании.

-e : Осуществляется экспорт приложения.
-c : Save and compact.
-p : Публикация клипа.

-l : Определяет файл, в который будет вывоится лог. Не обязательный. В дополнительном необязательном параметре путь к файлу лога. Если не определен, лог будет находиться в \log
-q : Тихий режим. Не обязательный. Если указан, вывод не будет производиться в консоль (но может производиться в лог).
-v : Подробный вывод.
-d : Задает каталог для временных файлов (не обязательный).
-s : Мсходный fla-файл. Лбязательный.
-o : Определяет выходной swf-файл если установлен флаг-e. Не обязательный. Если не указан, файл будет располагаться в одном каталоге с исходным.
-x : Если указан, среда разработки Flash будет закрыта после компиляции. Не обязательный.
-k : Если указан, временный jsfl-файл не будет удален. Не обязательный.
-f : Указывает путь к исполняемому файлу, запускающему Flash. Не обязательный.
-t : Задает таймаут. Не обязателен
-d : Задает временный каталог. Не обязателен.
-cp : Задает пути к классам. Можно указать несколько каталогов, разделяя их ";", а также заключить их все в кавычки если там содержатся пробелы. Не обязателен.

Для установки просто скопируйте в свой любимый каталог. Можно добавить каталог с программой к переменным окружения чтобы не задавать путь в ant-скрипте.

Пример мини-проекта с использованием ant можно скачать. Скрипт для ant довольно простой и на моей машине работает как часы:

<?xml version="1.0" encoding="UTF-8"?>
<!-- ======================================================================
15.01.2006 22:37:23

Cats
Тренируемся на кошках

Constantiner (constantiner gav-gav gmail dot com)
====================================================================== -->
<project name="Cats" default="flashCommandBuild" basedir="../">
<description>
Тренируемся на кошках
</description>

<property name="flashCommandExe" location="D:\Program Files\FlashCommand\FlashCommand.exe"/>
<property name="bin" location="bin/"/>
<property name="fla" location="fla/"/>
<property name="classpath1" location="src1/"/>
<property name="classpath2" location="src2/"/>
<property name="buildFile" location="${fla}/cats.fla"/>
<property name="outputFile" location="${bin}/cats.swf"/>
<property name="logDir" location="log/"/>
<property name="logFile" location="${logDir}/log.txt"/>

<!-- =================================
target: flashCommandBuild
================================= -->
<target name="flashCommandBuild" depends="clearBin" description="--> Тренируемся на кошках">
<exec executable="${flashCommandExe}">
<arg line="-e"/>
<arg line="-x"/>
<arg line="-s ${buildFile}"/>
<arg line="-l ${logFile}"/>
<arg line="-o ${outputFile}"/>
<arg line="-cp &quot;${classpath1};${classpath2}&quot;"/>
</exec>
</target>

<!-- - - - - - - - - - - - - - - - - -
target: depends
- - - - - - - - - - - - - - - - - -->
<target name="clearBin">
<echo>Clear Output Dir...</echo>
<delete>
<fileset dir="${bin}"></fileset>
<fileset dir="${logDir}"></fileset>
</delete>
</target>

</project>


В общем, пользуйте на здоровье. Замечания, баги, пожелания - в комменты. Думаю, что в скором будущем выложу исходники.
UPD: Для работы приложения необходим .NET фрэймворк версии 2.0. Его можно скачать с сайта производителя. В Visual Studio 2005 я не очень еще разбираюсь. Вечерком попробую опубликовать под 1.1.

вторник, января 10, 2006

Ваше мнение об ARP

Арал Балкан в преддверии создания ARP3, о чем мы уже писали, просит разработчиков ответить на несколько вопросов, связанных с использованием данного фрэймворка. Понятно, что высказать свое мнение в мэйл-листе ARP может любой разработчик, имевший с ним дело.

И берет меня стыд, что мне-то написать нечего. А также есть стойкое подозрение, что мало кто из русскоязычных разработчиков может написать туда дельное. Обидно :(

Flash-ripper умер?

Плохая новость: что-то случилось с нашим любимым и уважаемым первопроходцем - Flash-ripper'ом. Рост, ты где? Нам не хватает твого детища!

понедельник, января 09, 2006

Mixins: что это такое, с чем это едят? Хорошо это или плохо?

По поводу возникшей в конференции ruFlash дискуссии насчет множественного наследования в компонентах v2 от Macromedia всплыл вопрос насчет так называемых mixins, которые присутствуют в аржитектуре этих компонент. Действительно, вопрос о mixins, насколько я знаю, в русскоязычных обзорах не поднимался и я попробую этот момент немного осветить. Для начала сам корень вопроса:

Неоторые краем уха слышали, что в макромедийном фрэймворке, целиком написанном на ActionScript 2, проворачивается такая штука, как множественное наследование. А, как мы все знаем, ActionScript 2.0 - это язык программирования с полноценным объектно-ориентированным синтаксисом. Я не зря говорю про синтаксис, ибо только им дело и ограничевается. Тут даже не нужен никакой Нео чтобы открыть полог матрицы, не очень ловко прикрывающей торчащий из-под AS2 несвежо попахивающий AS1. Да, друзья мои, все мы хорошо знаем и скорбим, но AS2 компилируется в обычный AS1-байткод. А что есть такое AS1?

«ActionScript, как и его прообраз JavaScript, являются прототипированными языками. В прототипированных языках вы можете изменять определения класса на этапе исполнения и таким образом с легкостью добавлять функциональность. Вы добавляете методы другого класса в ваш класс путем достуупа к прототипу вашего класса.»

Понятное дело, что это я не сам такой умный, а привожу цитату из статьи, опубликованной на сайте Macromedia и посвященной mixins в Flex (считается, что Flex - это среда для серьезных разработчиков, ничего не знающих о тяжком прошлом Flash-разработчиков и потому для них специально объясняют всякие дикости; так или иначе, но все, что описывается в этой статье касается AS2 и Flex 1.x Components Framework, ноги которого растут напрямую из v2 components framework от Macromedia). Желающие могут сразу читать статью на английском, а для ленивых (шутка :) я продолжу тезисный обзор.

Наш друг из солнечной Индии Abdul Qabiz тоже интересовался этим вопросом и нашел в википедии немного истории происхождения термина. Приведу на русском:

«В ОО-языках mixins являются попыткой воплотить классы, отличающиеся от широкоиспользуемой практики пришедшей из Симулы (то, что используется в Smalltalk, C++, Java, C#). Впервые mixins использованы в Flavors (раннее объектно-ориентированное расширение Лиспа). Преимущество mixins в их способствовании повторному использованию кода и избегании широкоизвестных патологий, связанных с множественным наследованием, но между тем mixins имеют и собственный набор компромиссов. С mixins определение класса описывает только атрибуты и параметры, методы же определяются в других местах.»

Из этого Flavors (вкусы, привкусы, приправы) и родились mixins в программировании (как термин). А придуман он был так: в 1970-х годах в Массачусетском Технологическом Институте было популярное место встреч - Мороженое Стива (Steve's Ice Cream). Вы могли сделать собственное мороженое просто выбрав основу и различные добавки, которые назывались mixins.

Понятно, что в этих вот широкоиспользуемых ОО-языках типа Java mixins представляют тот "душок" (code that smells), который устраняется путем рефакторинга и более продуманной и изящной архитектуры с более понятным и читаемым кодом. И, стремясь к лучшим образцам (об этом в коце статьи), мы (вернее Macromedia) и с помощью AS2 вполне можем избежать этих mixins, о которых так долго уже говорим, но вы, думаю, так еще и не поняли, о чем я конкретно толкую. Хорошо, перейдем к примеру.

Наиболее употребимый пример mixins - это использование событийной модели и класса mx.events.EventDispatcher. Вы создаете собственный класс и желаете иметь в нем ту же событийную модель, что и в остальных классах от Macromedia (в рамках пакета mx). А также вы хотите чтобы ваш класс был отнаследован от класса, такой модели не имеющего. Что вы делаете? Вы пишете:


Created with Colorer-take5 Library. Type 'actionscript'

0: import mx.events.EventDispatcher;
1:
2: class Client extends Date
3: {
4: public function Client ()
5: {
6: EventDispatcher.initialize (this);
7: }
8: }

И все. А дальше в дело вступают эти самые mixins. В классе mx.events.EventDispatcher мы видим:


13: class mx.events.EventDispatcher
14: {
.............
43: static function initialize(object:Object):Void
44: {
45: if (_fEventDispatcher == undefined)
46: {
47: _fEventDispatcher = new EventDispatcher;
48: }
49: object.addEventListener = _fEventDispatcher.addEventListener;
50: object.removeEventListener = _fEventDispatcher.removeEventListener;
51: object.dispatchEvent = _fEventDispatcher.dispatchEvent;
52: object.dispatchQueue = _fEventDispatcher.dispatchQueue;
53: }
..............................
143: }
144:

Именно здесь и совершается таинство mixins. Понятно, что для того чтобы методы addEventListener и removeEventListener нормально обрабатывались нашей IDE и компилятором, необходимо в классе Client присутствовали заглушки этих методов: просто для синтаксических нужд, не более. Есть два основных способа: написать их как свойства класса типа Function (тогда не будут проверяться компилятором типы параметров) и в виде метода с реальной сигнатурой, но без всякой имплементации (наподобии Template Method, но все-таки не он).

Я рассматриваю два вида техники mixins, которые существуют в AS2: добавление методов в класс (через ключевое слово prototype) и добавление методов в экземпляр (как в рассмотренном выше примере). Оба эти способа широко используются в макромедийных классах.

Недостатки такого способа очевидны: мы теряем контроль над кодом. Здесь есть два уровня этого недостатка: концептуальный и уровень конкретной реализации. На концептуальном уровне беспокоит возможность такого поведения языка программирования в принципе. Я не могу доверять стороннему коду пока досконально его не изучу: в таком подходе структура кода на уровне сигнатур методов и определения класса (то есть, скажем, изучение intrinsic-определения класса если он поставляется без исходного кода) я не могу быть твердо уверенным, что этот код не содержит чего-то такого, что меняет поведение и моего кода! Я могу делать любые предположения при отладке, но действительность может сыграть со мной гораздо более злую шутку: для переопределения через прототипы нет модификаторов public/private (как нет их в AS1)!

Уровень же конкретной реализации как минимум может предоставить мне трудноразгадываемую головоломку при разборе кода. И как максимум (в качестве следствия) - неуправляемую сложность кода, с трудом поддающегося отладке (не поможет ни синтаксический анализатор, ни компилятор).

А плюс только один - легкий путь избавления от дублирования кода. Как будто нет наработанной базы приемов рефакторинга, паттернов проектирования (они все ведут к той же цели!).

Но есть еще более существенный довод в пользу того чтобы понимать компромиссную природу mixins и знать, что заставляет их нас использовать сейчас, но не полагаться на них при других условиях: мы имеем уникальную возможность заглянуть в будущее. В ActionScript 3 у нас не будет ни прототипирования, ни возможности переопределять методы экземпляров. Не верите? Что же, запустите нижеприведенный код в Flex 2 Alpha и убедитесь сами:


0: package cats.mixins {
1: import flash.util.trace;
2:
3: public class Client
4: {
5: public function Client ()
6: {
7: EventDispatcher.initialize (this);
8: }
9:
10: public function addEventListener(event:String, handler:Function):Void
11: {
12: trace ("own addEventListener");
13: }
14: }
15:
16: private class EventDispatcher
17: {
18: private static var _fEventDispatcher:EventDispatcher;
19:
20: internal static function initialize (object:Object):Void
21: {
22: if (EventDispatcher._fEventDispatcher == null)
23: {
24: EventDispatcher._fEventDispatcher = new EventDispatcher ();
25: }
26: object.addEventListener = _fEventDispatcher.addEventListener;
27: }
28:
29: private function addEventListener(event:String, handler:Function):Void
30: {
31: trace ("mixing addEventListener success!");
32: }
33: }
34: }


0: package
1: {
2: import flash.display.MovieClip;
3: import cats.mixins.Client;
4:
5: public class Cats extends MovieClip
6: {
7: public function Cats()
8: {
9: var aClient:Client = new Client ();
10: aClient.addEventListener ("someEvent", handler);
11: }
12:
13: private function handler ():Void
14: {
15:
16: }
17: }
18: }

Я просто имитировал ситуацию с mx.events.EventDispatcher, средствами AS3. И получил логичный runtime error:

ReferenceError: Error #1037: Cannot assign to a method addEventListener on cats.mixins.Client
at cats.mixins$6$private::EventDispatcher$/cats.mixins$internal::initialize()
at cats.mixins::Client$iinit()
at Cats$iinit()

И вот уже в AS3 проблема с механизмом обработки событий решена гораздо изящнее: класс flash.events.EventDispatcher является суперклассом ряда классов, которые в нем нуждаются. А если не является - можно включить его в качестве композита.

Думаю, что на этом вполне можно закончить. Если вам понравился данный материал, то просьба выражать благодарности его инициатору Евгению Н. Спасибо.

воскресенье, января 08, 2006

Ресурс по вычислительной геометрии для ActionScript

Отличный ресурс, посвященный вычислительной геометрии и имеющий прямое отношение к ActionScript. Данная страничка содержит в себе ряд TechNotes по разным аспектом вычислительной геометрии (натуральные кубический сплайны, кривые Хермита, кубические и квадратичные кривые Безье, сплайны Гатмула-Рома). Каждая TechNote представлена в формате FlashPaper со всеми формулами и примером для скачивания на ActionScript 2. В связи с этим хочется упомянуть работы в этом направлении нашего соотечественника Ивана Дембицкого.

И снова о модульном тестировании

Наткнулся на интересную статейку написанную Mike Spille с критикой модульного тестирования (Unit Testing). Статья ставит своей целью разоблачение мифа об эффективности модульного тестирования и ведет критику в двух основных направлениях:

1. Модульное тестирование представляет наименее важный и малозначительный элемент тестирования программного продукта. Настолько малый и незначительный, что придавать ему сколько-нибудь важности и высокого смысла - ошибка. Майк утверждает, что 10 часов, потраченные на написание интеграционных тестов, тестов производительности и им подобных, сказываются неизмеримо сильнее на качестве программного продукта, нежели 10 часов, потраченные на написание модульных тестов.

2. Мартин Фаулер и другие властелины дум в области современных методик разработки программного обеспечения выдвигают подобные концепции лишь с целью рекламировать себя и свои консалтинговые услуги. Майк не говорит, что преподносимые идеологами идеи совершенно бессмысленны. Он лишь утверждает, что придание им такой важности и активное продвижение есть не что иное, как банальная пропаганда с целью привлечь внимание и заработать больше денег.

По мне мотив второго пункта безусловно отчасти имеет место. Действительно, если рассмотреть мотивы властелинов дум, то к чему, казалось бы, так легко и бесплатно делиться идеями, которые представляются высокопродуктивными и перспективными? Бескорыстное желание двигать прогресс? И это в мире дикого капитализма? :) Возможно. Но почему бы, действительно, не рассмотреть мотив привлечения клиентов к своим консалтинговым услугам (хотя бы в качестве весомой составляющей)?Я утверждаю, что моя фирма впереди планеты всей так как использует передовые методики. Но не какие-то там абстрактные передовые методики (которых, на деле, может, и нет), а вот такие-то вполне конкретные методики. И не просто где-то надерганные методики, а методики, которые придуманы мною. И не просто придуманы и высосаны из пальца, а проверенные и апробированные сообществом разработчиков, которое я же и инспирировал. Понятно, что такой подход ставит меня, как властителя дум, выше моих последователей. И клиент при прочих равных условиях пойдет ко мне, а не к моему последователю. Но и последователи имеют свой кусок хлеба с маслом. С этой точки зрения мотивы властителей дум вполне понятны и, с моей точки зрения, вполне уважаемы. Это и есть, по сути, тот разумный эгоизм, о котором писал в свое время Чернышевский, и который, возможно, более ценен, чем голый альтруизм, зачастую не приносящий плодов. Это практический подход, который удовлетворяет все заинтересованные стороны.

Более интересен в этой статье пункт номер один. С утверждением автора статьи в этой форме вполне можно согласиться. Но есть одно «но» (и это упоминают некоторые комментаторы статьи)! В связи с модульным тестированием неизменно всплывает фигура еще одного «продажного» властителя дум Кента Бека, автора классического труда по TDD (Test Driven Development, разработка через тестирование). Именно Кент, кстати, является (в сотрудничестве с Эрихом Гаммой) автором программного продукта jUnit - прототипа xUnit (инфраструктур модульного тестирования для разных языков и платформ). Ненадолго отвлекшись на ActionScript, можно вспомнить реализованные для него инструменты: AsUnit (AS2/3), AS2Unit (AS2), Flex Unit (Flex AS2), ASTUce (AS1).

Так вот Кент Бек как раз предложил такую методику тестирования, которая едва ли не перебивает по ценности все остальные типы тестов. TDD использует модульные тесты не для тестирования уже написанного кода, а для разработки ненаписанного. Эта методика дает разработчику уверенность. Запуская тесты и видя зеленую полосу мы можем делать шаг вперед твердо зная, что у нас надежный тыл. 

Разработка по методике TDD состоит из следующих шагов:


  • Добавьте небольшой тест.

  • Запустите все тесты и убедитесь, что тест не сработал.

  • Внесите в код необходимые изменения.

  • Запустите все тесты и убедитесь, что все они сработали.

  • Выполните рефакторинг и удалите дублирование.


В сочетании с другими методиками, составляющими XP (eXtreme Programming, экстремальное программирование), это дает полную уверенность в процессе, предсказуемый результат и наличие работающего кода в любой момент времени. Что еще надо разработчику чтобы чувствовать себя уверенным и смело двигаться вперед? Ведь я знаю, что сделав что-то не то на одном из шагов, я буду тут же извещен (красная полоса!). Я всегда вижу луч света впереди (зеленая полоса).

Именно в этом и заключается ценность модульных тестов - они помогают разрабатывать код. Но есть еще и дополнительные ценности: тесты содержат в себе четкую и лаконичеую документацию о том, как следует использовать написанный код! Лучшей документации и не найти! И декларируемая в рамках XP и TDD простота (реализуй задачу самым простым способом, который только существует!) в сочетании с тестами - это надежная гарантия командной работы, которая не заведет в темный тупик.

Так что, я думаю, отказываться от модульных тестов нет смысла. Просто ценность написания тестов к существующему коду и утешение при этом себя иллюзиями, что это способствует тестированию приложения в целом - глупо. Все хорошо к месту.

суббота, января 07, 2006

Wow! Вышел AFTERTHOUGHT 2.1!

Известная и незаменимая тулза AFTERTHOUGHT после более чем годового молчания (версия 1.0) возобновила свою деятельность! Понятно, что не сама тулза, а ее создатель - g.wygonik. Выпущена v 2.0, а вчера - v 2.1. Это очень хорошо!

Напомню, этот инструмент позволяет в удобной форме отображать трэйсы ваших swf'ок например в браузере и даже в некоторых случаях в standalone executable приложениях (прожекторах). Изменения касаются в основном GUI приложения, а также добавлена панель поиска в логах. Для его работы вам понадобится .NET 1.1 и Debug-версия Flash-плеера. Если проблемы с работой приложения остаются, то рекомендую проделать соотвествующие шаги.

Думаю, что осталось автору добавить еще такие фичи, как возможность настройки собственных фильтров и сохрание лога в txt/html/xml-файл.

ARP: что дальше?

Пока я раскачивался, Майкл Клишин в своем блоге уже анонсировал анонс Арала Балкана о планах на ARP 3. Налицо нарождающаяся конкуренция по части новостей, которая, я так думаю, приведет к возрастанию удельной доли аналитических материалов в русскоязычной блогосфере.

Попробую подойти к новости слегка с другого бокв и представить ее для людей, не сильно знакомых с предметом. Для начала, что такое ARP? Словами создателя этого фрэймворка Арала Балкана:

«ARP - это просто мощный структурный фрэймворк для создания насыщенных интернет-приложений (Rich Internet Applications, RIAs) на базе Macromedia/Adobe Flash-платформы. Простота и DRY (Don't Repeat Yourself, Не Повторяй Себя) - основные догматы ARP. ARP помогает повысить продуктивность разработчиков при написании и изучении кода, а также интегрируется с большинством серверов приложений и баз данных. По мере возможности ARP использует общепринятые паттерны проектирования, которые включают в себя такие паттерны, как Controller, Business Delegate и Value Object. ARP устанавливает соглашения по конфигурированию, что означает использование разумных значений по умолчанию и правил именования там, где только возможно. Конечной целью является сокращение начального этапа разработки новых RIA-проектов практически к нулю, а также продвижение передового опыта и тестирования перед разработкой при создании RIAs на базе Flash-платформы.»

Прочитать о планах на ARP 3 вы можете в вышеупомянутом блоге, а также в первоисточнике на языке оригинала или в дополнительном источнике. Я попытаюсь вкратце осветить историю и альтернативы данного решения. Арал Балкан известен рядом связанных с Flash-платформой продуктов и инициатив. Это и FlashAnt, и Ariaware Optimizer. Он основал консалтинговую фирму Ariaware, на базе которой был разработан коммерческий фрэймворк ARP (Ariaware RIA Platform). В качестве коммерческого продукта ARP эволюцинировал до версии 2.01, после чего был выпущен под опенсорсной лицензией в качестве версии 2.02. Данную версию, сопровожденную полной документацией на английском, и примеры приложений можно скачать с официального сайта. Инициатива выпуска продукта с исходным кодом не прошла бесследной для Арала. Назревало опенсорсное Flash-сообщество. И последней каплей, переполнившей кубок такого стремления, был выпуск бесплатного компилятора AS2 с открытым исходным кодом mtasc, которым мы обязаны Nicolas Cannasse (отдельная очень яркая личность опенсорсного Flash-сообщества). Арал стал инициатором объединения таких инициатив под эгидой сайта osFlash. Данный сайт имеет свой репозиторий исходных кодов, куда и было перенесено дальнейшее развитие ARP. Собственно, и сама страничка ARP перенесена туда.

В настоящий момент силами сторонних разработчиков ARP расширяется и развивается. Думаю, что рано или поздно это приведет к появлению оригинальных материалов на русском языке (об участии представителей русскоязычных разработчиков в мировом опенсорсном Flash сообществе стоит упомянуть отдельно: это пионер движения Евгений Потапенко aka john с его Flashout (буква F в FAMES, которая сейчас трансформировалась в AMES в связи со встраиванием функциональности Flashout в ASDT, с отсутствием поддержки Евгением своего плагина и, если быть честным, в связи с тем, что его плагин хоть и бесплатный, но не обладает открытым исходным кодом, так вот буква F - это его Flashout), это Игорь Садовский из Симферополя с проектом MX v.2 Components Patch, а также Игорь Агеев с интересным проектом MXML2UI. Если я кого-то забыл, думаю, благодарные читатели напишут об этом в комментариях :).

Теперь упомяну об альтернативах ARP. Таких я знаю две: это Cairngorm от iteration::two и ASAP ActionScript Application Framework. Все три фрэймворка (включая ARP) служат целью облегчить создание RIA и базируются на паттернах. Cairngorm, по моему мнению, наиболее близок ARP, но, как и вся деятельность iteration::two, направлен больше на Flex. Кстати, о паттернах, которые легли в основу Cairngorm, можно прочитать в главе из жутко переведенной на русский книги Macromedia Flash MX 2004 ActionScript 2.0. Справочник разработчика. Глава написана все теми же парнями из iteration::two. Также на их страничке, посвященной разработке RIA на AS2 можно скачать пример приложения, основанного на этих паттернах.

Теперь, я думаю, что я вас достаточно заинтересовал и предоставил всю необходимую информацию. Жду от вас дельных комментариев и интересных статей :)

пятница, января 06, 2006

Подходы к разработке сложных Flash-приложений

Jonathan Boutelle, разрабатывавший поисковую службу с механизмом визуального анализа MindCanvas, клиент которой реализован на базе Flash-технологии, делится своими соображениями по поводу разработки сложных Flash_клиентов (21 пакет, 188 классов, 20 000 строк кода). Наша фирма как раз занимается сейчас не менее объемными проектами и потому я могу тоже судить о правильности выводов, приведенных Джонатаном.

В ранней статье он приводит несколько принципов:


  • Не использовать таймлайн. Все приложение должно быть в одном фрэйме. Джонатан признается, что в консультации с парнями из Макромедии он выяснил, что концепция Screen'ов, появившаяся во Flash MX 2004 есть не более чем первая, несовершенная, попытка создания девелоперской среды. Flex Джонатан не рассматривает (понятно, что Flex 1.x не является средством разработки клиента - скорее некий серверный инструмент, чем уже является Flex 2, который еще не подлежит промышленному использованию). Только используемые в приложении графические элементы, созданные визуальными дизайнерами и не содержащие кода, могут иметь таймлайн. Сразу скажу, что компромиссный подход, когда фрэймы во fla-файле отображают некоторые «состояния» приложения, рассматривается, но признается неудобоваримым с точки зрения разработки, поддержки и тестирования. Подход отказа от таймлайна гарантирует более длительный начальный этап разработки, зато меньше проблем в будущем. От себя могу добавить, что я нахожу более-менее приемлимыми оба варианта (радикальный и компромиссный), но именно в связи с отсутствием идеального (Flex 2, I'm waiting for you! :)

  • Не больше одной строчки кода на весь fla-файл. Это довольно логическое требование, вытекающее из предыдущего. Возможно, идеален Flex'овый подход, при котором вообще ни одной строчки - только класс, навешанный на главный контейнер. Имея опыт отладки крупных приложений, в которых код раскидан по кадрам, могу сказать, что зачастую проще выкинуть такие приложения на помойку. Ибо кроме автора в них разобраться никто не сможет.

  • Использование существующих и опробованных процессов разработки. Тут нет вопросов. Использование систем контроля версий (мы используем Subversion, чего и вам желаем), инструментов сборки (ANT - не используем, но планируем), модульное тестирование (ASUnit, тоже планируем), системы багтрэкинга (Bugzilla, например, используемая нами). Это опробованные в других областях и языках разработки методики, которые пока не слишком опробованы в ActionScript разработке. Думаю, что именно в этих областях следует сконцентрировать достаточно плотное внимание русскоязычному Flash-сообществу.

  • Не кастрируйте дизайнеров :) Это подразумевает, что не стоит злоупотреблять программной анимацией там, где гораздо лече и уместнее использовать таймлайн. Программист не лезет в таймлайн - это епархия дизайнеров. На отрисованные ими графические элементы (мувиклипы) вешаются классы. Здесь, конечно, могут возникнуть сложные моменты коммуникации, но на что существует грамотный менеджемент? :)

  • Используйте паттерны, дарованные Богом. Это момент очевидный и тема для отдельного большого разговора.

  • Сначала код, потом визуальная часть. Предполагается, что сначала пишется код для всех графических элементов, а уже потом дизайнеры осуществляют дизайн, который «оживляет» данный код. Думаю, что это полезная практика, ибо часто выходит так, что дизайнеры, как люди «творческие» в понимании обыденном, мало заботятся о представлении результатов на практике. А тупые и прагматичные разработчики имеют об этом бОльшее представление :)

  • Не разрабатывайте того, что вы можете купить, взять или украсть :) Джонатан говорит, что двигаться вверх можно лишь встав кому-нибудь на плечи. Код, сделанный кем-то, опробованный и протестированный, лучше, чем написанный вами в короткий срок. Или как минимум дешевле. Про «украсть» Джонатан приукрасил конечно, но мысль очень правильная. Я на практике убеждался, что написание собственных UI-компонент вместо использования компонент от Macromedia выходит дороже, поддерживается из твоего же кошелька и содержит уж точно не меньшее количество багов, чем те, за которые уже заплачено. То же самое касательно структур данных, механизмов ведения лога итд. касательно библиотеки as2lib. Понятно, что в этой библиотеке код перерос несколько версий, прошел некоторую апробацию, нежели тот, что написан вами вчера ночью и который выдаст кучу багов в ночь перед сдачей вашего проекта.

  • Пользуйтесь строгой типизацией. Если вы не указываете тип в вашем коде, это, фактически, означает, что вы его не знаете. Но его не знает и компилятор. Его не знает тот, кто будет работать с вашим кодом завтра. И если в коде будет баг, связанный с неверным представлением о типах, то вам не поможет ни компилятор на этапе компиляции, вы и сами долго будете иной раз мучиться силясь понять, что же здесь имелось ввиду. Поэтому наличие правила «Всегда указывайте тип» лучше правила «Указывайте тип там, где необходимо». Это, по моему глубокому мнению, касается в том числе и эскизного программирования. Если человек не указывает тип в этом случае, то такое поведение говорит лишь о том, что человек указывает его иногда лишь вопреки своим правилам (либо он работает в ужасном IDE навроде Flash IDE, где лаконичность - залог быстрого письма).


От себя бы хотел добавить лишь правила, декларированные в рамках XP: коллективное владение кодом (и, как следствие, соглашения по кодированию в рамках комманды), простота, коммуникация, обратная связь, итеративный подход.

Джонатан считает, что Flash IDE используется только в двух случаях: дизайнерами и для компиляции проекта. Но жалуется на невыносимо долгое время компиляции. В качестве решения предлагается оснастить разработчиков более мощными компьютерами (поддерживаю!). Комментаторы, конечно же, указали на существование mtasc. Но это уже тема отдельного разговора: osFlash. Так или иначе, я тоже вижу перспективным использование mtasc, хотя это сопряжено с риском (связанным с поддержкой, совместимостью итд.).

Заслуживает интереса мнение одного из комментаторов (Pranav), описывающего разработку ERP-клиента на Flash, где было создано около 200 000 строк AS2-кода. Были взяты Java-разработчики и переучены на ActionScript. Проект начался с энтузиазмом, но впоследствии все пришли к выводу, к которому я тоже в свое время пришел: у Flash ActionScript нет будущего как языка программирования. Но луч надежды - это ActionScript 3. В него остается верить :)

PNG и JPEG Encoders от Tinic Uro

Tinic Uro, работающий в Adobe в команде разработчиков Flash Player'а, реализует на ActionScript 3 два интересных класса для работы с графическими форматами: PNG Encoder и JPEG Encoder.

Оба класса имеют методы encode(img:BitmapData):ByteArray, позволяющие конвертировать flash.display.BitmapData в flash.util.ByteArray, готовый к отправке на сервер.

Кто бы мог подумать, что технология шагнет вперед так далеко!?

Мартин Фаулер: имплементация неявного интерфейса

В свежем посте своего блога, почему-то названного Блики, Мартин поднимает довольно интересную проблему: почему в современных объектно-ориентированных языках программирования (Мартин рассматривает Java и C#, но к ActionScript 2/3 это в равной степени применимо) класс может имплементировать только явные интерфейсы (то есть те, что объявлены с ключевым словом interface):


0: interface A
1: {
2: public function someMethod ():Boolean;
3: }

0: class B implements A
1: {
2: public function B ()
3: {
4:
5: }
6:
7: public function someMethod() : Boolean
8: {
9: return true;
10: }
11: }

Причем, понятно, может имплементировать сколько угодно этих «чистых» интерфейсов. С классами же возможно только наследование. Класс наследуется только от одного класса. Но ведь набор публичных методов класса определяет его «неявный» интерфейс!

Так почему бы не ввести в языки программирования со статической типизацией возможность имплементировать интерфейс готового класса!? Например:


0: /**
1: * Это просто класс, содержащий "неявный" интерфейс (как и любой класс).
2: */
3: class A
4: {
5: public function A ()
6: {
7:
8: }
9:
10: public function someMethod ():Boolean
11: {
12: return true;
13: }
14:
15: private function somePrivateMethod ():Number
16: {
17: return 0;
18: }
19: }

0: /**
1: * Данный класс просто служит целям иллюстрации суперкласса.
2: */
3: class C
4: {
5: public function C ()
6: {
7:
8: }
9:
10: public function anotherMethod ():String
11: {
12: return "";
13: }
14: }

0: class B extends C implements A
1: {
2: public function B ()
3: {
4:
5: }
6:
7: /**
8: * Данный метод просто служит целям имплементации "неявного" интерфейса класса A.
9: */
10: public function someMethod ():Boolean
11: {
12: // Понятно, что super здесь не применим. Это имплементация, а не наследование.
13: return false;
14: }
15:
16: public function anotherMethod ():String
17: {
18: return someMethod () ? super.anotherMethod () : "Nothing";
19: }
20: }

Это же было бы просто чертовски архиудобно! Во-первых, во многих случаях не пришлось бы выделять интерфейс. Просто элементарно меньше работы.

Во-вторых, есть классы, которые не имплементируют интерфейсов (собственно, все классы, написанные Macromedia для <=8-го плеера). Но иногда очень надо сделать заглушку (скажем, для тестирования ) какого-нибудь заковыристого класса от Macromedia, который никакого интерфейса не имплементирует. И пишешь просто implements DataGrid. И все :)

И, присоединяясь к Мартину, я задаюсь вопросом: а почему этого нет? Почему?

Нет ответа...

среда, января 04, 2006

Блоговодческий оффтоп

Уф, кажется более-менее кастомизировал внешний вид блога. Но проблема в том, что я нифига не дизайнер... Так что если есть баги, несовместимости с маргинальными браузерами, некрасивости, поведение, недостойное советского офицера etc. - сообщайте! И не надо отключать картинки :)

Санкт-Петербург-'Google' разместит свой офис в Петербурге


«Российское представительство компании 'Google' откроется в ближайшие месяцы и будет, по последним данным, размещено в Санкт-Петербурге.

Возглавлять новое региональное подразделение лидера мирового рынка поисковых систем будет бывший гендиректор интернет-магазина 'Озон' Владимир Долгов.

Предполагается, что в российском офисе получат работу около 3 тысяч человек.

Предварительная информация о том, что 'Google' собирается открыть отделение в России, появлялась в течение года неоднократно. В октябре газета 'Коммерсант' писала, что это должно произойти до конца этого года, а вероятными кандидатами на руководящую должность назывались Владимир Долгов и Клифф Гонтлет, который около 5-ти лет занимал пост директора подразделения интернет-услуг холдинга 'Россия Онлайн'.

Кроме того, летом этого года о возможном приходе 'Google' в Россию говорил заместитель министра информационных технологий и связи РФ Дмитрий Милованцев, увязывая это событие с программой Мининформсвязи РФ по созданию технопарков.

'Google' давно имеет русскоязычную версию своего поискового сервиса наравне с многими другими локальными версиями. Для работы в России компания ранее использовала домен google.com.ru, а в апреле прошлого года ей удалось отобрать у киберсквоттеров и домен google.ru.»

Несмотря на то, что Google специализируется на AJAX и, по слухам, Python, интерес к Flash-технологии очевиден: сервисы Google Video и Google Analytics, подсказанный Antares'ом Gtalkr вовсю используют Flash-технологию. А очевидный успех Yahoo Maps, построенной на Flash-платформе с использованием Flex 1.5 - сигнал к тому, что AJAX, очевидно, не сказал своего последнего слова парням из Google. Конкуренция - великая вещь. О том, что проще украсть, чем сделать самому - мой следующий пост по материалам зарубежных корреспондентов :)

Так что держите свои CV наготове, девелоперы всех мастей :))

вторник, января 03, 2006

История Flash-платформы

В качестве первого поста нового блога могу предложить книгу Бытия Flash-технологии в виде истории ее создания, рассказанной отцом основателем Джонатаном с оригинальной фамилией Гей (к вопросу о перверсиях: вспомните как переводится слово flasher с английского :).

Думаю, что лучше, чем Jonathan Gay вам никто не расскажет (а пишет он все это в далеком 2001-м году):

«В 2001-м Macromedia выпустила уже пять версий, но в них до сих пор присутствует куча кода, написанного для компьютеров с графическими планшетами. Сейчас уже 50 человек работают над Flash вместо трех когда мы начинали работу над FutureWave. Среда Flash эволюцинировала от простого пакета рисования и анимации для Web в серьезную среду разработки мультимедия-продуктов с 500.000 разработчиками и свыше 325 миллионами пользователей Flash-плеера. Flash стал синонимом анимации в сети интернет. В настоящий момент, возможно, Flash-плеер является наиболее распространенным программным продуктом в сети интернет, превосходя даже Internet Explorer, Netscape Navigator или Real Player.»

Ну и от себя хочу добавить, что речь идет о среде Flash в чистом виде. Но концепция Flash-платформы, которая была выдвинута фирмой Macromedia незадолго до объявления о слиянии с Adobe, выводит Flash-плеер, лежащий в основе технологии, на лидирующее место в области клиентских насыщенных приложений в сети интернет (и не только).

И появление новых сред разработки (начиная от инструментов кодирования вроде плагинов для Eclipse - FDT, ASDT, заканчивая новым Flex Builder'ом 2 - инструментом для серьезных разработчиков, где лежащий в основе Flash-технологии таймлайн даже не фигурирует) - яркое тому подтверждение.