Автор фотографий - Алексей «Vooparker» Аникутин

На 6-ой встрече нашей RAFPUG Constantiner предложил сделать 30-минутный доклад о проблемах и решениях flash-клиента на портале top4top.ru. Я предложил своим коллегам Филиппу «FSB» Бондареву и Игорю «peace» Андрееву сделать наш доклад вместе (по сути переложил на них всю работу ), и так уж получилось что они вместо 25 минут рассказывали 2 часа.

Начал наш архитектор, Игорь. Одна из первых фраз была типа «то ли руки не оттуда ростут, то ли условия были таковы», на что Артемий предложил не впадать в уныние Сотрудники Flexis соорудили доступ в интернет, и Игорь перешел от слайдов к показу живого сайта через Internet Explorer.

То ли за полгода мы так и не соорудили нормальное определение версий, то-ли и правда в IE был старый плеер, но все увидели предложение обновить плеер вместо top4top Фидбек от Flexis? Какой там плеер в IE был? В Опере все сразу заработало. Следующие 20-30 минут Игорь ходил по top4top.ru в браузере и оказалось, что функционала-то немало.

Затем он перешел к более системным вещам и решениям, скоро тут появиться его презентация.

Настала очередь Филиппа. Он рассказывал про User Account, показывал запретные картинки, создавал и уничтожал планеты во вселенной.

Особенно запомнился момент, когда Филипп стал убирать красные глаза с помощью инструмента редактирования фото в User Account’е «Человеку-Жопе», символу IT-отдела портала:

Презентация Филиппа:

| View | Upload your own

После короткого перерыва я за 5 минут протараторил свою презентацию:

| View | Upload your own

Выводы (Филипп и Игорь со мной не согласны, их выводы я надеюсь тоже добавить в пост):

• Использование двух кривых версий (flash и html) одного контента - это победа технологий над здравым смыслом.
• На данный момент мне ясно, что лучшим является html решение с вставками flash там, где это абсолютно необходимо и с возможностью получить хоть что-то если FP недостаточно высокой версии
• Требование установить последний релиз плеера отпугнет от Вас бОльшую часть аудитории (если она состоит не из флешеров)
• Если не страшен предыдущий пункт и решено сделать портал на FP, то необходимо использовать Flex Framework

И, наконец, главный вывод:

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

Я.

В целом получилось позитивно и, надеюсь, не очень занудно. Спасибо вам за вопросы и за то, что пришли.

Отвечаем на разные вопросы.

Настала очередь Артемия. Его доклад о нововведениях во Flash Player 10 Beta состоял из демонстрации множества примеров и активных обсуждений в зале. Мне больше всего понравилась генерация звука - вспомнился MS DOS, и сохранение файлов без участия сервера. Большое спасибо ему за доклад!

Bookmark this article at …

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

Bookmark this article at …

Недавно сделали презентацию, основанную на xml-описании.
Задача была следующая: у фирмы есть много объектов, разбросанных по всем регионам России, и нужно сделать презентацию (для каждого объекта - фотография, тексты) которая смогла бы все это охватить. Дизайн слайдов с объектами - единый. Также наряду с автоматической работой (на выставке) нужна навигация (для оператора).

Что получилось в итоге (см. схему): внешний xml-файл, в котором каждый тег - это слайд (соответствующего типа), последовательность тегов образует последовательность слайдов а также есть специальные теги (меню), которые могут содержать в себе другие (что реализует пункты меню).
Возможно скоро расскажу про нее подробней.

Bookmark this article at …

Пилотная версия

Была создана в момент выбора технологии для реализации данного элемента UI.

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

Первая версия

Ее я делал постепенно, не спроектировав изначально всю функциональность и не очень волнуясь по поводу масштабируемости. Результатом стала тупиковая версия, которую пришлось бросить вот почему:

• Классы были выделены не совсем верно и не были организованны в packages
• Не было разделения Представления и Логики
• Схема взаимодействий превратилась из дерева в граф и стала сильносвязной
• Поэтому код запутался и дальнейшая его разработка стала невозможной

Вторая версия

Она же финальная на данный момент. Создавалась она с “нуля", в ней я постарался учесть все предыдущие ошибки, но опять таки не додумал до конца, так что ближе к концу проект стал снова крениться набок. Вот, что получилось в итоге:

• Функции разделены между “режимами работы": Сосуды, Топология, Шунты и т.п.
• Часто используемая информация находится “ближе” к пользователю, чем остальная
• Все взаимодействия сделаны как можно более наглядными (напр. установка перетоков, ср. с первой версией)

Bookmark this article at …

Прежде, чем сразу выкладывать решение, опишу Вам задачу.

В институте им. Склифасофского делают операции людям в предынфарктном состоянии (или уже перенесшим инфаркт) для устранения его причины - закупоренности сосудов, питающих сердце.

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

Вот какая модель:

• Область кровоснабжения делится на сосуды
• Сосуды - на части (3 трети + устье)
• Каждая часть является объектом, с которым может быть связана информация
• Между сосудами возможны перетоки крови

Особенности:

• Топология сосудов может меняться от пациента к пациенту
• Могут добавляться новые сосуды, искуственным образом добавленные пациенту в ходе вмешательств. Для них справедливы те же пункты, что и для обычных
• Информация, ассоциируемая с частью сосуда, разнородна и ее много.
• Есть два исследования, работающие с этой моделью, но с разными ее аспектами

Bookmark this article at …

Однажды мне предложили сделать диск-архив и в качестве бонуса - очень похожий по функциональности диск по соседней тематике. Первым был диск «Ускользающие шедевры», вторым - «Радиоискусство» (версии без картинок на free-lance.ru).

Из чего должен состоять диск:

• Заставка
• Два раздела с простым статическим контентом
• Один раздел - поиск по базе изображений. Поиск по одному из трех параметров, вывод результатов.

Подобный проект можно реализовать практически любым из известных науке способом программирования на ActionScript:

• Пользоваться фреймами и крепить код к ним
• Разделить все по символам-классам, в самих классах вести разработку как душе угодно
• Разделить все на символы-классы и с надеждой на повторное использование кода во второй части проекта («Радиоискусство») попытаться грамотно использовать наследование и события

Путь с фреймами в проекте такого размера ведет к очень плохим последствиям, жертвой которых я сам становился не раз: в каких-то местах код скапливается в огромных количествах и его уже не получается чинить/модернизировать - просто невозможно понять, где нужный кусок находится и зачем эта строчка тут.

Если попробовать полностью положиться на классы как панацею от всех бед без обдумывания структуры проекта то получиться может все что угодно

На самом деле достаточно воспользоваться очевидными особенностями задачи:

• Три раздела - для них можно сделать один базовый класс, в нем - вся общая функциональность (переключение между разделами, открытие, закрытие)
• Поскольку дизайн у двух дисков разный, а функцинальность одна - то нужно отделать внешний вид от кода полностью

В итоге второй диск получился из первого примерно за 5 часов, в то время как стоил столько же.

Конечно, не все было чудесно, при разработке были допущено довольно много стратегических ошибок во имя ускорения процесса и которые в итоге привели к потере времени И тем не менее, код первого диска - 20 файлов (75 кб), код второго - 10 файлов (40 кб, все наследуют у файлов с такими же именами из кода первого проекта с внесением нужных изменений, порядочно copy-paste). Он (сopy-paste) появился из-за того, что я поленился хорошо разделить код на функции/обработчики событий и из-за мелкого изменения в функции приходилось перегружать ее полностью.

Это самый простой и действенный пример пользы от использования хотябы каких-то приемов ООП.

Bookmark this article at …