Уж не знаю, кто виноват - но только что наблюдал интересное явление:

Т.е. сначала выполнился блок if (a & b), а потом - if (!a && !b).

Update: с булевой логикой все хорошо, оказывается там просто “;” в конце 722 строки

На прошедшей полмесяца назад в Питере RAFPUG мои уважаемые коллеги Nox Noctis и Delimeter рассказали о том, как борятся с утечками памяти. Каждый ведет по масштабному игровому проекту, Nox - Королевство, так что сомневаться в их опыте не приходится.

Основные их + мои мысли:

• Garbage Collector делает за нас только часть работы по освобождению ресурсов. Eсли не помогать ему освобождать их (память, объекты типа Sound, Loader, сетевые соединения и т.п.) - память будет утекать.
• Использование Weak Reference, которое я разрекламировал ранее, не является достаточной мерой для предотвращения утечек памяти.
• Повсеместное применение Weak Reference снижает качество кода. Их надо использовать только там, где это объективно необходимо.

• Помогать Garbage Collector’у нужно постоянно и системно - например, завести практически метод destroy(), который будет беспощадно все уничтожать.

  1. public function destroy():void
  2. {
  3.   // Отпишемся от всего, на что мы подписались на данный момент
  4.   removeEventListener(..., some_eventHandler);
  5.  
  6.   // Удалим всех детей
  7.   while (numChildren > 0)
  8.   {
  9.     removeChildAt(0);
  10.   }
  11.  
  12.   ...
  13. }
  14.  
  15. // Как вариант, завести эту функцию в родительском классе и переопределять в дочерних
  16. override public function destroy():void
  17. {
  18.   super.destroy();
  19.  
  20.   ...
  21. }
  22.  
• Если какая-то часть вашего приложения особенно часто создает новые объекты - есть шанс что можно единожды создать буфер на N таких объектов, а затем уже не создавать их каждый раз, а просто брать из буфера и затем складывать туда после использования. Примерно как с посудой Этот прием явно старше, чем кибернетика.

Такой вот антикризисный план по борьбе с утечками памяти. Удачи!

Сейчас, когда на базе отдыха “Спутник” компания “Flexis” продолжает праздновать свое 2-х летие вместе с оставшимися там участниками FlexCamp, я из своей уютной комнаты спешу заявить - FlexCamp состоялся.

Вот все, что есть у меня на фотоаппарате:

Сравнив фотографии, сделанные мной 1 год и 8 месяцев назад во время зимнего flex-семинара Flexis, вывод очевиден - профессионализм возрос многократно!

Спасибо Артемию и всей чудесной команде Flexis-а за мероприятие!

На днях запущен проект “Отжигатор” для Мамбы, которым я занимался будучи программистом ИЛ Ксан (и долгое время потом ).

Добраться до него непросто, необходимо зарегистрироваться, зайти в профайл другого пользователя, выбрать “Отправить отжиг".

И вот - он! Когда закончите креативить, вас огорчат тем, что услуга платная - 1$.

Если вы таки заплатите, то пользователь увидет ваш креатив в специальном проигрываете открыток.

Я уж думал никогда не запустим!

Автор фотографий - Алексей «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, и сохранение файлов без участия сервера. Большое спасибо ему за доклад!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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