Flex и RIA блоги

Почему же не получилось шоколада?

Причин в этом несколько.

1. Стабильность

Когда я был маленький, у нас вел программирование “злой дядя” Овсянник В.Н. , “злым” его считали за то, что он валил практически любую программу принесеную на ему на здачу (дз или курсач). Делал он это довольно просто - брал и вводил неадекватные данные (если нужно было ввести строку то пихал в нее этак символов 500, или нажимал клавиши кнопки не в той последовательности), и ПО юного программиста падало. Это было его первым действием и оно было на эффективно почти на все 100%. Естественно юные таланты отправлялись дорабатывать свою программу.

Таким способом я поступил со своим прототипом плеера. Получилось полная лажа.

Если у нас кроме плей и стоп, есть премотка, а еще не дай бог мы решили менять source у
VideoDisplay, то плеер наш “держится” аж 10-15 секунд усиленого клика ). Потом он уходит в ступор и уже не реагирует на кнопки и обратно уже не возвращается, о своем плохом состоянии он ничего никому не говорит. UPD: говорит, и возвращаеться! только ждать нужно ооооочень долго, в зависимости от наклацаного и коннекта у меня оказываеться просто не хвалило терпения дождаться, дождется ли пользователь? Помогает только F5.

2. Удобство для пользователя

Пользователь, сука, нервный.

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

Ситуация 2:
Я пользователь смотрю видео, но некоторые места мне не интересны я начинаю кликать по перемотке и если не дай бог какие-то тормоза (коннект, или машина слабая) и плеер не успевает мгновенно отреагировать то я кликаю еще раз что только усилывает тормоза, затем еще раз… а потом я решаю вернутся назад… вобщем кликаю много.
В при использовании VideoDislpay это вообще фатально ибо, у него не точный seek, что особенно заметно на очень маленьких роликах, он хранит всю(!) истории этих кликов (вернее команд перемодки). т.е. при перемотки он перематывает сначало на первый клик, раздупляется, мотает на второй, и т.д. А пользователь за время раздупления может сделать 5 кликов. И они все отобразятся. Выглядит просто это супер особенно если мотать на разные места, такая машина времени ), пользователь начинает нерничать и кликает еще и еще и плееру становится все хуже и хуже… Я пробовал - можно наклацать так что этот дергаться будет еще секунд 30 :D, а иногда оно просто уходит в ступор.

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

3. Удобство для разработчика

После того как я обернул VideoDisplay захотев шоколада, я захотел исправить ситуацию с неточностью у seek’a. Seek живет все в том же VideoPlayer, уже стало немного страшно. Но не теряя оптимизма я ринулся в бой. В VideoDisplay, плеер (VideoPlayer) объявлен как

вроде ниче страшного, дальше у VideoPlayer есть public метод seek - вообще замечательно, т.е. если сделать класс наследник от VideoDisplay и ему всесто VideoPlayer подсунуть наследника от VideoPlayer с оверайднутым seek’oм ситуация будет спасена. Но не тут то было публичный seek у VideoPlayer’а это иллюзия, фактическая перемотка происходит в приватном методе _seek который использует приватные переменные VideoPlayer’а причем одна из перменных является экземпляром класса VideoPlayerNetStream (наследник от NetStream), который объявлен в самом VideoPlayer.as, т.е. видимость этого класса начинается и заканчивается VideoPlayer’ом. Ну и за ними также тянуться все классы из mx.controls.videoclasses.*. Вобщем-то приплыли.

В результате получили чтобы доработать напильничном пару методов нужно копипастить все классы из mx.controls.videoclasses.* в свой пакетик, делать децельный рефакторинг (небольшой минут 15), потом брать свое приложение и менять в нем mx.controls.VideoDisplay на moy.mega.noviy.VideoDisplay и после этого мы готовы переписать требуемые методы.

Скажите не правдали удобно? на онанизм не похоже? Помоемому похоже.

Вобщем так и было вначале сделано, потом полезли всякие неприятности по стабильности плеера, это “приятная” очередь из seek’ов, уходы плеера в астрал если слишком много клацали по клавишам и т.д.

Сначало была мысль вылечить сам VideoPlayer, но посмотрев еще раз код, всего 3к строк (правда включая коментарии) + то что еще он супер универсальный

VideoPlayer is an easy to use wrapper for Video, NetConnection,
NetStream, etc. that makes playing FLV easy. It supports streaming
from Flash Communication Server (FCS) and http download of FLVs.

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

Выводы

• Не все то золото что блястит.
• VideoDisplay тупиковая ветка развития. UPD: все еще можно исправить? Лучшее решение это ждать что адоб сам исправит ситуацию
• Вывод VideoDisplay из тупика своими не поддается оценке времени в человекочасах и никому это особо не нужно при таких раскладах UPD: не все потеряно) Достаем бубен из кармана?
  
• Возвращаемся к истокам (Video) и пытаемся родить свой работоспособный, пользователеустойчивый(с) аналог VideoDisplay учитывая, что
  • нам не нужно (пока) support streaming
    from Flash Communication Server (FCS)
  • Конструкция должна быть легкая и устойчивая в примении
  • Постаратся использовать чуть меньше таймеров
  • Нам не нужен хоровод из сиков
  • его внедрение в готовый код должно занять минимум усилий

Текущий результат

Имеем пока кучу потраченого в никуда времени и плеер который работает, если ничего не трогать.

В следующих сериях вы услышите увлекательные рассказы о NetStream и Video.

UPD: Мотыль Нарожняк подсказал новую ветку развития событий и еще раз показал, что не нужно суетится, а нужно изучать доки как можно внимательнее, [тут еще пара отмазок почему это произошло]).

Но всеравно NetStream”y достанется

Почему же не получилось шоколада?

Причин в этом несколько.

1. Стабильность

Когда я был маленький, у нас вел программирование “злой дядя” Овсянник В.Н. , “злым” его считали за то, что он валил практически любую программу принесеную на ему на здачу (дз или курсач). Делал он это довольно просто - брал и вводил неадекватные данные (если нужно было ввести строку то пихал в нее этак символов 500, или нажимал клавиши кнопки не в той последовательности), и ПО юного программиста падало. Это было его первым действием и оно было на эффективно почти на все 100%. Естественно юные таланты отправлялись дорабатывать свою программу.

Таким способом я поступил со своим прототипом плеера. Получилось полная лажа.

Если у нас кроме плей и стоп, есть премотка, а еще не дай бог мы решили менять source у
VideoDisplay, то плеер наш “держится” аж 10-15 секунд усиленого клика ). Потом он уходит в ступор и уже не реагирует на кнопки и обратно уже не возвращается, о своем плохом состоянии он ничего никому не говорит. UPD: говорит, и возвращаеться! только ждать нужно ооооочень долго, в зависимости от наклацаного и коннекта у меня оказываеться просто не хвалило терпения дождаться, дождется ли пользователь? Помогает только F5.

2. Удобство для пользователя

Пользователь, сука, нервный.

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

Ситуация 2:
Я пользователь смотрю видео, но некоторые места мне не интересны я начинаю кликать по перемотке и если не дай бог какие-то тормоза (коннект, или машина слабая) и плеер не успевает мгновенно отреагировать то я кликаю еще раз что только усилывает тормоза, затем еще раз… а потом я решаю вернутся назад… вобщем кликаю много.
В при использовании VideoDislpay это вообще фатально ибо, у него не точный seek, что особенно заметно на очень маленьких роликах, он хранит всю(!) истории этих кликов (вернее команд перемодки). т.е. при перемотки он перематывает сначало на первый клик, раздупляется, мотает на второй, и т.д. А пользователь за время раздупления может сделать 5 кликов. И они все отобразятся. Выглядит просто это супер особенно если мотать на разные места, такая машина времени ), пользователь начинает нерничать и кликает еще и еще и плееру становится все хуже и хуже… Я пробовал - можно наклацать так что этот дергаться будет еще секунд 30 :D, а иногда оно просто уходит в ступор.

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

3. Удобство для разработчика

После того как я обернул VideoDisplay захотев шоколада, я захотел исправить ситуацию с неточностью у seek’a. Seek живет все в том же VideoPlayer, уже стало немного страшно. Но не теряя оптимизма я ринулся в бой. В VideoDisplay, плеер (VideoPlayer) объявлен как

вроде ниче страшного, дальше у VideoPlayer есть public метод seek - вообще замечательно, т.е. если сделать класс наследник от VideoDisplay и ему всесто VideoPlayer подсунуть наследника от VideoPlayer с оверайднутым seek’oм ситуация будет спасена. Но не тут то было публичный seek у VideoPlayer’а это иллюзия, фактическая перемотка происходит в приватном методе _seek который использует приватные переменные VideoPlayer’а причем одна из перменных является экземпляром класса VideoPlayerNetStream (наследник от NetStream), который объявлен в самом VideoPlayer.as, т.е. видимость этого класса начинается и заканчивается VideoPlayer’ом. Ну и за ними также тянуться все классы из mx.controls.videoclasses.*. Вобщем-то приплыли.

В результате получили чтобы доработать напильничном пару методов нужно копипастить все классы из mx.controls.videoclasses.* в свой пакетик, делать децельный рефакторинг (небольшой минут 15), потом брать свое приложение и менять в нем mx.controls.VideoDisplay на moy.mega.noviy.VideoDisplay и после этого мы готовы переписать требуемые методы.

Скажите не правдали удобно? на онанизм не похоже? Помоемому похоже.

Вобщем так и было вначале сделано, потом полезли всякие неприятности по стабильности плеера, это “приятная” очередь из seek’ов, уходы плеера в астрал если слишком много клацали по клавишам и т.д.

Сначало была мысль вылечить сам VideoPlayer, но посмотрев еще раз код, всего 3к строк (правда включая коментарии) + то что еще он супер универсальный

VideoPlayer is an easy to use wrapper for Video, NetConnection,
NetStream, etc. that makes playing FLV easy. It supports streaming
from Flash Communication Server (FCS) and http download of FLVs.

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

Выводы

• Не все то золото что блястит.
• VideoDisplay тупиковая ветка развития. UPD: все еще можно исправить? Лучшее решение это ждать что адоб сам исправит ситуацию
• Вывод VideoDisplay из тупика своими не поддается оценке времени в человекочасах и никому это особо не нужно при таких раскладах UPD: не все потеряно) Достаем бубен из кармана?
  
• Возвращаемся к истокам (Video) и пытаемся родить свой работоспособный, пользователеустойчивый(с) аналог VideoDisplay учитывая, что
  • нам не нужно (пока) support streaming
    from Flash Communication Server (FCS)
  • Конструкция должна быть легкая и устойчивая в примении
  • Постаратся использовать чуть меньше таймеров
  • Нам не нужен хоровод из сиков
  • его внедрение в готовый код должно занять минимум усилий

Текущий результат

Имеем пока кучу потраченого в никуда времени и плеер который работает, если ничего не трогать.

В следующих сериях вы услышите увлекательные рассказы о NetStream и Video.

UPD: Мотыль Нарожняк подсказал новую ветку развития событий и еще раз показал, что не нужно суетится, а нужно изучать доки как можно внимательнее, [тут еще пара отмазок почему это произошло]).

Но всеравно NetStream”y достанется

Ahmet Gyger, в своем блоге, выложил несколько видео уроков, на тему “ActionScript 3 для начинающих”:

• helloWorld
• Display & control MC
• Flash Video with AS3
• Animating MC with Timer Class
• Xml & Actionscript 3.0
• Display Audio Spectrum

Т.е. Все то что нужно начинающему или переходящему на ActionScript 3 программеру.

А Mr.doob по прежнему продолжает делится исходниками. В это раз исходники актуальные - PV3D AudioVisualisations. Это давно пора было сделать :)

Друзья, спасибо за массу советов по выбору оптимальной Linux-системы. Не удержусь, перепечатаю последний комментарий целиком. Пишет (буду рад поставить ссылку) Dan:

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

Первым был Alt Linux, не помню точно какой версии. Честно купленный одним знакомым за полторы тыщи рублей и нагло спираченный мною на болванки.
Альт поставился, но иксы запускаться не захотели. Как впоследствии оказалось - Альт не понял, что такое 14-дюймовый монитор.

Позвал я другого знакомого, который типа шарит в линухах. Он поковырялся в Альте и сказал - будем ставить Слаку.
Убили Alt, поставили Slackware, она тоже не поняла, что такое 14-дюймовый монитор. После танцев с бубном и редактирования xorg.conf иксы запустились, но изображение расползалось - неверно были заданы параметры развёртки. А хто бы знал, какими они должны быть.

Потом была Ubuntu. Убунту поняла, что такое 14-дюймовый монитор, но не поняла, что такое COM-овская мышка. К счастью, в Убунту есть такая замечательная штука, как Ubuntu Device Database. Это специальная такая программулина с графическим интерфейсом, которая очень дружелюбно решает проблемы с железом.
Она задаёт вопросы, типа: монитор нормально работает? а звук нормально работает? а сетевуха нормально работает? А ты ей отвечаешь: да, нет, пофиг.
Так как меня интересовала только мышка, я просто жал Enter и переходил дальше. И вот долгожданный вопрос: работает ли мышка? И стандартный Group Box: Yes, No, N/A.
По умолчанию выбрано Yes. И тут обнаруживается, что с помощью клавиатуры невозможно ответить No! Я перепробывал Tab, Shift+Tab, стрелки, всё на свете - возможности переключаться между радиокнопками не оказалось. Зато обнаружил совершенно ненужную мне возможности перейти на текстовое поле с вопросом и отредактировать его. Но вот для того, чтобы сказать, что у меня не работает мышка, мне нужна была работающая мышка.
После этого Убунта была жестоко убита.

Дальше была Fedora Core 4. Тоже поняла монитор, не поняла мышку. К счастью, меня тогда уже научили, что надо поправить в конфигах, чтобы это исправить. Тем не менее эта штука работала довольно тормозно, постоянно просилась обновиться. Кроме того, я так и не понял, как там переключаться на русскую раскладку. Хотя эта общая проблема - я и в других дистрибах её испытывал.

Самое смешное, что на тот же самый компутер я поставил Windows XP Home Edition, и никаких проблем ни с мышкой, ни с монитором, ни с раскладкой не было. Более того, даже смог поработать в Visual Studio, хотя крайне некомфортно из-за тормозов.

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

Дальше я уже экспериментировал с нормальным компутером, без антикварных девайсов. Попробывал микролинухи: DSL, Puppy, SLAX. Запускал их из под винды в эмуляторе. Наиболее интересным оказался SLAX, поскольку остальные уж больно порезанные.
На десктоп такой линух ставить конечно без толку, но для флешки - самый раз.

Последний линух, который я пытался осились - это Mandriva 2007. В основном польстился на мега-3D-десктоп - хотел глянуть хоть что это такое. Увы, один из образов оказался запоротым, поэтому идущие в комплекте драйвера видеокарты ставиться отказались. При этом выдавали какое-то очень страшное сообщение об ошибке.
Ах, кстати... Когда запускаешь Менеджер источников программ, появляется сообщение: "Добро пожаловать в Менеджер источников программ! Эта утилита поможет вам настроить источники пакетов, которые вы желаете использовать на своём компьютере. Затем они будут доступны для цстановки пакетов новых программ или для выполнения обновлений. Всё в порядке? Можно продолжать? (Да/Нет)"
Вот это "всё в порядке?" убило меня наповал.
Ну дык вот... Драйвера, которые в комплекте не ставились. Я скачал распоследние драйвера с сайта NVidia. Запускаю. Говорит: ты не root. Ладно, запускаю через sudo. Говорит: надо сперва закрыть иксы. Странно, в винде вроде ставиться и так, ну да пофиг. Закрываю иксы, запускаю из консоли. Говорит: нет прекомпилированных интерфейсов, давай поищем на сайте. Ну ок, ищи. Говорит: на сайте тоже нет, давай перекомпилируем. Ну давай. Фигушки, говорит, нужны сорцы, а у тебя их нет.
А их то ли в комплекте не оказалось, то ли они на запоротом диске - вобщем, поставить их так и не получилось и мега-3d-десктоп я так и не увидел.

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

P.S.
Как бы не начался холивор :)

А мы ж и не холивора ради: но история может оказаться полезной для таких как я начинающих линукусойдов. В комментах спрашивали, на каком линухе я остановился. Отвечаю: пока ни на каком; буду пробовать Ubuntu, Кубунту, OpenSUSE, Дебиан и Mandriva 2007.

А альфа-версия Flex Builder, как оказалось, пока только для Ubuntu...

Emmy Huang написала статью "Tips for learning ActionScript 3.0" еще в 2006 году, но многое из нее будет полезно и сейчас. Особенно тем, кто только начинает изучать язык. Итак, я взял на себя смелость и начал перевод этой статьи. Возможно, при помощи наших старших товарищей, мы все вместе сможем дополнить список советов собственными.

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

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

——-
Немного оффтопа:
Почему я ругаю адоб (вернее индусов которые там работают), я просто зол на них, а почему я зол на них? Я не считаю себя супер программистом, или гением и “по умолчанию” я считаю что в комманде разработчиков адоба работают не дураки и всем есть чему у них поучиться (не зря ж они работают там). Поэтому я изначально доверяю их коду, а если прибавить рекламу что “все стало удобнее и легко, и делается все с пол пинка” то и вроде доверия больше. Исходя из этих тезисов получается такая конструкция “Если у тебя что-то не работает, а адоб крут, то наверное это глюк в твоем коде, проверь все 3 раза”.. После чего ты проверяешь пару раз свой код, читаешь хелп, копипастишь из него примеры, а оно нихера не работает. И тут закрадывается сомнение, а может таки это косяк в коде от адоба? Начинается колупание в коде фреймворка. Вы скажете ну и что колупайся, ищи, изучай пиши свои решения, модифицируй существующий код. Я с этим почти согласен, но тут есть одно мрачное НО - это эстимейт. Когда делается проект у него есть сроки, чтобы выставить эти сроки, таратится время на изучение возможности реализации и сроков реализации той или иной функциональности. Естетсвенно почитав оптимистичные доки от адоба “а тут все в пол пинка делается”, прикинув вероятные трудности, ты устанавливаешь сроки реализации проекта, ушлый клиент тоже не дремлет, он тоже знает о фичах и если ты ему скажешь, что я заскиную тебе скрол за месяц, то он очень удивится, и скажет батенька да вы гоните тут работы на 2 часа. Потом придя к взаимовыгодному решению, заполнив бумажки вы стартуете проект, клиент ждет. После этого начинаеться самое интересное, делаешь это “пол пиночное” решение и видишь что ничего не работает, проверяешь себя пару раз(на проверку время-то тратится), вроде все правильно, лезешь в фрейворк начинаешь смотреть там (а миноточки и часы идут), фрейворк не маленьки, вы наверное это заметили ? )), зависимостей много, в результате найдя в чем проблема вы пытаетесь ее решить, сначало малой кровью (очень часто так не получается), затем уже глобальными способами, а время бежит, и способа сделать 36 часов в сутки никто еще не предложил. В итоге мы имеем просроченный дедлайн, если клиент адекватный и ему можно объяснить почему так, то все вроде хорошо, а если нет + мы имеем моральное неудовлетворени, нервотрепка, стрессы, вобщем нету кайфа от процесса. Поэтому я зол на адоб, ну на себя тоже (ибо я не идеален), но видоваты оба (хотя я люблю себя любимого, поэтому адоб больше %) ). Наверное эта ситуация знакома каждому?
——–

…Подумал, что я что-то не так делаю, или я “просто не умею его готовить”, перелопатив свой код я не нашел подвоха, полез во фреймворк и увидел в коде VideoPlayer следующее

Бабах эксепшин, всего лишь 7 эксепшинов бабахается в VideoPlayer на неверный play, pause, seek и т.д. Так лезем в доку, в чем проблемы то, дока молчит, но посмотрев коментарий у VideoPlayer.play() вижу следующую инструкцию

упс, думаю я, читатать нужно внимательнее хелп, но потом вспоминаю в хелпе нету этого класса, этот класс спрятан от чужих глаз!
Проверил VideoDisplay, там тоже никто ничего не проверяет.

Ну что же подумал я, не вопрос дабы сильно не напрягатся наследуюсь от VideoDisplay, оберну эти методы проверочками, не пущу эксепшины дальше и будет все в шоколаде. Обернул. Шоколада не получилось.

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

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

——-
Немного оффтопа:
Почему я ругаю адоб (вернее индусов которые там работают), я просто зол на них, а почему я зол на них? Я не считаю себя супер программистом, или гением и “по умолчанию” я считаю что в комманде разработчиков адоба работают не дураки и всем есть чему у них поучиться (не зря ж они работают там). Поэтому я изначально доверяю их коду, а если прибавить рекламу что “все стало удобнее и легко, и делается все с пол пинка” то и вроде доверия больше. Исходя из этих тезисов получается такая конструкция “Если у тебя что-то не работает, а адоб крут, то наверное это глюк в твоем коде, проверь все 3 раза”.. После чего ты проверяешь пару раз свой код, читаешь хелп, копипастишь из него примеры, а оно нихера не работает. И тут закрадывается сомнение, а может таки это косяк в коде от адоба? Начинается колупание в коде фреймворка. Вы скажете ну и что колупайся, ищи, изучай пиши свои решения, модифицируй существующий код. Я с этим почти согласен, но тут есть одно мрачное НО - это эстимейт. Когда делается проект у него есть сроки, чтобы выставить эти сроки, таратится время на изучение возможности реализации и сроков реализации той или иной функциональности. Естетсвенно почитав оптимистичные доки от адоба “а тут все в пол пинка делается”, прикинув вероятные трудности, ты устанавливаешь сроки реализации проекта, ушлый клиент тоже не дремлет, он тоже знает о фичах и если ты ему скажешь, что я заскиную тебе скрол за месяц, то он очень удивится, и скажет батенька да вы гоните тут работы на 2 часа. Потом придя к взаимовыгодному решению, заполнив бумажки вы стартуете проект, клиент ждет. После этого начинаеться самое интересное, делаешь это “пол пиночное” решение и видишь что ничего не работает, проверяешь себя пару раз(на проверку время-то тратится), вроде все правильно, лезешь в фрейворк начинаешь смотреть там (а миноточки и часы идут), фрейворк не маленьки, вы наверное это заметили ? )), зависимостей много, в результате найдя в чем проблема вы пытаетесь ее решить, сначало малой кровью (очень часто так не получается), затем уже глобальными способами, а время бежит, и способа сделать 36 часов в сутки никто еще не предложил. В итоге мы имеем просроченный дедлайн, если клиент адекватный и ему можно объяснить почему так, то все вроде хорошо, а если нет + мы имеем моральное неудовлетворени, нервотрепка, стрессы, вобщем нету кайфа от процесса. Поэтому я зол на адоб, ну на себя тоже (ибо я не идеален), но видоваты оба (хотя я люблю себя любимого, поэтому адоб больше %) ). Наверное эта ситуация знакома каждому?
——–

…Подумал, что я что-то не так делаю, или я “просто не умею его готовить”, перелопатив свой код я не нашел подвоха, полез во фреймворк и увидел в коде VideoPlayer следующее

Бабах эксепшин, всего лишь 7 эксепшинов бабахается в VideoPlayer на неверный play, pause, seek и т.д. Так лезем в доку, в чем проблемы то, дока молчит, но посмотрев коментарий у VideoPlayer.play() вижу следующую инструкцию

упс, думаю я, читатать нужно внимательнее хелп, но потом вспоминаю в хелпе нету этого класса, этот класс спрятан от чужих глаз!
Проверил VideoDisplay, там тоже никто ничего не проверяет.

Ну что же подумал я, не вопрос дабы сильно не напрягатся наследуюсь от VideoDisplay, оберну эти методы проверочками, не пущу эксепшины дальше и будет все в шоколаде. Обернул. Шоколада не получилось.

Решил поделиться рецептом для осуществления копирования большого количества файлов в связке Flex + MDM Zink под Mac OS.

Проблема с копированием большого количества файлов, используя MDM Zink API для работы с файловой системой, скажем, с CD на винт, и расфасовке их по папкам под Mac OS заключается в том, что MDM Zink Flex projector просто-напросто переставал копировать, не выдавая при этом никаких признаков того, что процесс копирования умер и ждать собственно нечего, плюс ко всем этим прелестям он копирует довольно долго даже сравнительно не большие файлы до 100 kb.

Служба поддержки у MDM Zink говорила в ответ на запрос, что, мол, таки да, но пока ничего поделать не будем.

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

В результате всех этих неуспешных попыток настало время кардинальных методов; в начале пробовал реализовать копирование файлов посредством AppleScript (только для Mac OS), благо в API у MDM Zink заложена такая возможность. Но снова решение не совсем удалось, во-первых, из-за того, что AppleScript обладает не совсем привычным синтаксисом, и с первого раза не “раскуришь” все тонкости “языка яблок”, простенький пример, который считает количество файлов в папке “Applications”:

Да и не очень удобно было производить отладку, так как в начале приходилось писать код на Mac’e, в его чудном редакторе ScriptEditor, потом переносить в MDM Zink под Win, так как проект собирался на Flex + MDM Zink под Windows, где он не всегда компилировался. В итоге я не нашел консенсуса с “языком яблок” и принялся искать другое решение.

Финальная часть “марлезонского балета”: ситуация спасена благодаря тому, что MDM Zink API предусмотрел возможность работы с MacShell, он же bash. Посредством команд MacShell мы успешно копируем файлы.

Итого, алгоритм действий, которые позволяют решить проблему с копированием большого количества файлов из MDM Zink под Mac OS:

1. Подготавливаем заранее пути для создания каталога/ов и для копирования файлов (откуда и куда; путь, куда копировать, нужен еще для того, что иногда хочется файл переименовать). Времени много не отберёт, но разгрузит нагрузку под Mac OS и упростит создание дерева каталогов, во время подготовки путей для каталогов можно отсеять дубликаты.
2. Создаём каталоги, это можно реализовывать через MDM Zink API, методом mdm.FileSystem.makeFolder();
3. Копируем файлы поштучно, используя MacShell, с небольшой задержкой (я ставил 600 мс);
4. Радуемся жизни.

Помимо всего, выигрышем в использовании MacShell является возможность радовать глаз пользователя такой замечательной вещью, как прогресс копирования файлов, чего никак нельзя сделать, если мы делаем какие-либо операции с файловой системой, используя MDM Zink API. Потому что он просто посылает Flex приложение в глубокий нокаут до завершения своих злодеяний, и на примере прогресса копирования счастливый пользователь увидит только состояние в 100%. Также мы легко можем сделать паузу/отмену копированию. В общем, сплошная радость.

Бонусный рецепт для тех, кто дочитал до конца :). Рецепт, как закрыть ваше MDM Zink приложение, работающее под Mac OS, да еще и в fullscreen режиме. При попытке закрыть приложение путем MDM Zink API (mdm.Application.exit()), приложение бывает просто уходит в ступор и жалобно просит “force quit”, то есть “снять задачу”.

MDM Zink сапорт, когда-нибудь напишу про него отдельную статью, лаконично ответил: “А вы не юзайте fullscreen”.

Но выход есть, немного грубо, но работает, просто запускаем, через mdm.MacShell.exec(), чудную команду - “killall mdm-static”.

Fin.

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

ps. сорри за битый пост, была проблема с wordpress и code snippet плагином, чтото не дает сохранить пост с кодом

Два флекс-хардкорщика, Дима 'Reijii' Кочетов и Илья '__i' Панин решили проблему со ссылками. Они много раз помогали сайту Ф. Потрошителя материально (присылая интересные материалы) и всегда, публикуя такие новости, я не мог дать ссылку на источник: писал просто имя, и это было неп-ра-виль-но!

Илья и Дима решили проблему: открыли собственные блоги, где уже есть содержательные записи.

RIA crumbs от Димы 'Reijii' Кочетова:
О естестве флэшеров, о нелегкой судьбе SWF в среде Mozilla и о том, как упростить жизнь простого скиновальщика флекс-приложений и даже о том, что Илья Панин открыл блог.

33 коровы Ильи '__i' Панина:
Не стесняясь в выражениях, Илья рассказывает о рабочих буднях флекс-хардкор-девелопера. Вся правда о Видео во Flex: Вступление, Часть 1. Буфер и Часть 2. VideoDisplay и даже пишет о том, что Дима Кочетов открыл свой блог.

Ресурсы обещают быть мегаувлекательными: оба парня имеют богатый сексуальный опыт с Флексом (в частности, Илья дошел до того, что распарсил Flex 2 Framework в Enterprise Architect (для чего ему пришлось обработать классы напильником).

Встречаем: блог Ильи Панина и  блог  reijii,
начатые отличными статяьми о видео во флексе и работе swf в Mozilla соответственно …а еще я забыл упомянуть об открывшемся несколько дней назад Life.FLEX -  родственнике LIFE.Flash
.Интересного и познавательного все больше!

Тед Патрик недавно написал о различных новостях от Adobe, в том числе и о Flex Skin Design Extension. Которое должно облегчить жизнь дизайнерам при создании скинов для Flex приложений. Плагин идет под Photoshop, Flash, Illustrator и под FireWorks.

Общая логика - это предоставление набора шаблонов базового внешнего вида Flex компонент, взятых из стандартной темы AeonGraphical, поставляемой с Flex 3, которые путем простого редактирования можно превратить в кастомные скины.

Попытаюсь кратко рассказать про extension под Photoshop и Flash (все CS3).

Итак, начнем с Flash. Extension поставляется в виде mxp файла, установка которого не составляет больших проблем. Благо инсталлируя продукты линейки CS3 помимо самих продуктов, мы получаем еще кучу нужных и не очень штук, в числе нужных - Adobe Extension Manager.

После запуска Flash CS3 на splash screen в разделе “Create From Template” появляется выбор Flex Skins. В котором можно выбрать скин по видам виджетов.

Выбрав интересующий скин, создается новый Flash CS3 документ, в котором уже все готово для редактирования, и все довольно приятно разнесено по папочкам в библиотеке. Осталось только изменить то что нам требуется. Scale-9 учтен.

Итогом работы станет SWC , содержащий измененый нами скин. При паблише есть галочка Export SWC, выбрана по умолчанию. Импортируем нашу SWC в проект (File->Import..->Skin Artwork), мы получаем уже отскинованые компоненты. То есть, в нашем случае скролбары будут выглядеть, так как мы над ними поиздевались, без указания стилей и прочего.

Обзор как все сделать используя Flex Skin Design Extension и Photoshop будет во второй части.

Появилось два новых отличных блога - первый от Ильи Панина с забавным названием “33 коровы”. Название хоть и забавное, а начинает автор с серьезного - Вся правда о Видео во Flex. (там аж целый цикл статей)

Второй от reijii - RIA crumbs и только открывшись, появились интересные рассуждение на тему Mozilla vs SWF (Всем столкнувшимся с проблемой передачи фокуса своему Flash/Flex приложению в Mozilla (FF) посвящается.)

Удачного плавания!

P.S. А на Flex Developer Center появилась статья Communicating between Flex and .NET от двух русских авторов - Denis Sosnovtsev и Alexey Vedernikov (я сужу по фамилии). Наши на Adobe )

А вот и про них поподробнее, правда на английском:

Denis Sosnovtsev is a rising junior undergraduate Computer Science student at the University of Maryland at College Park. He is currently employed as a software engineering intern at Atellis, a Washington, DC area software engineering firm specializing in the development of rich Internet applications (RIAs).

Alexey Vedernikov is a senior undergraduate student majoring in Computer Science at the University of Maryland, College Park. He is pursuing a software engineering internship at B-Line Medical (Atellis), a software development company located in Washington, DC metro area.

С приходом осени пора уже начинать считать не только цыплят, но и блоги Помимо моего, новоявленного шедевра русского RIA творчества :), появился на свет блог от Ильи Панина, теплым названием “33 коровы”, надеюсь автор как-нибудь объяснит мне, почему “33 коровы”

В своем блоге Илья собирается писать, как я понял, в стиле AS IS, то есть о том как оно все есть и что у него накипело за время работы с Flex 2 Кому-то он покажется грубым и не литературным, а кому-то нет. Но послушать стоит, так как несмотря на абсолютно вегетарианское название, он съел довольно много собак на поприще Flex 2.

Вообщем попутного ему ветра, и путь Адобы услышат его слова и сделают мир лучше

Я буду самым первым кто расскажет миру о новом блоге от Reijii.
RIA crumbs
Судя по всему Дима будет тоже ругаться на жизнь, и искать счастья в коде.

Теперь бы кто еще бы про меня рассказал миру? )

Я буду самым первым кто расскажет миру о новом блоге от Reijii.
RIA crumbs
Судя по всему Дима будет тоже ругаться на жизнь, и искать счастья в коде.

Теперь бы кто еще бы про меня рассказал миру? )

Всем столкнувшимся с проблемой передачи фокуса своему Flash/Flex приложению в Mozilla (FF) посвящается.

Недавно захотелось, чтобы приложение сходу, после запуска в браузере, без “стартового” клика по нему, “отлавливало” события мышиного колеса, к примеру.

В ходе детальных экспериментов и мучительных поисков, выяснилось, что в IE, как это ни странно, реализовать это очень просто. Достаточно просто-напросто при помощи JavaScript передать фокус вашей флешке, и все сразу счастливы:

Но тут и вступает в игру FireFox, в котором фокус и события упорно игнорируют ваше приложение. На просторах Гугла и Яндекса нашлось много интересного, но все сводится к тому, что по-хорошему работать ничего не будет. Есть варианты, которые “лечат” эту болезнь у FireFox, но порождают болезни у Flex, отключение мультиселекта и fullscreen.

Такой вариант заключается в том, что приложению ставится wmode=”transparent” или wmode=”opaque”, а фокус передается тем же JavaScript, но с небольшим изменением, перед передачей фокуса приложению, даем его нашему body:

Метод хорош, но мы теряем важные для большинства, как мне кажется, людей функциональности, причем fullscreen теряется как в IE, так и в FF.

Ответ Mozilla, по поводу этой проблемы, взято отсюда:

Mozilla hired a contractor to do the work, who stopped before finishing. Now
it’s too late in the release cycle to take the change, especially since there is
no one available and qualified to do the work.

I will push hard to get Mozilla Corporation to put someone on it after Firefox 3.

- Aaron

Есть варианты, где люди предлагают передавать события клавиатуры и мышки, в Flash/Flex через ExternalInterface. Чем-то это решение и хорошо, но при большом приложении можно немного затеряться при “расфасовке” входящих событий из JavaScript. И все равно остаётся проблема автофокуса.

Итого, будем ждать и надеяться, что в FireFox 3 все будет хорошо, и все им дружно будут пользоваться, или …

Но, есть еще метод от _etc, который предлагает зайти со стороны AS2. Главными идеями метода, являются:

• Подписываться на глобальные события мыши, как в AS2, везде и всюду, в любом классе;
• Не иметь привязки ни к какому InteractiveObject, необходимости наследования, отрисовки чего-либо;
• Захват скролла мыши от браузера (в AS3 скролл продолжает работать в самом браузере).

Более подробно почитать и взять на вооружение этого решения можно здесь.

ps. Если кому удалось решить данную проблему, просьба поделится со страждущими

pss. В JavaScript примерах использовался синтаксис суперзамечательной библиотеки jQuery, о которой мне рассказал Майкл Клишин. За что ему большое человеческое спасибо.

Теперь переходим к VideoDisplay - это просто ахтунг!

В видео дисплее живет класс который называется VideoPlayer (mx.controls.videoClasses.VideoPlayer). Это сущее порождение зла), что мы можем узнать о нем? В хелпе его нету, заглянем ка во внутрь ради спортивного интереса

Едить-колотить да это супер клад который легко позволит нам работать с видео! Но почему же мы его не видим нигде? да потому что он сырой, недоделанный, причем по коментам сразу видно, что его тупо не успели сделать и спрятали с глаз долой - “только фанаты заглянут внутрь”.

теперь листаем дальше. А там [цензура][цензура][цензура][цензура][цензура]!

представляете какую жопу можно организовать с таким количество таймеров, но не переживайте все 13 интервалов (интересное количество, наверное им все и объясняется) мы использовать не будем, в конструкторе мы проинициализировали всего лишь 9(!) таймеров. Я лично поставлю ящик пива кто сможет не запутавшись, написать и гарантировать мне корректность работы с таким количеством таймеров. А если еще добавить сюда NetStream который подкидывает программеру еще разные приятности, то хочется сказать:

“Респект и Уважуха Адобу! С его лучшим видео!”

а еще спасибо за все заботы о бедных программистах.
В следующих выпусках мы поговорим о практическом применением VideoDisplay и чем это грозит, поговорим NetStream’e и может что-то достанется и Video. До встречи

Теперь переходим к VideoDisplay - это просто ахтунг!

В видео дисплее живет класс который называется VideoPlayer (mx.controls.videoClasses.VideoPlayer). Это сущее порождение зла), что мы можем узнать о нем? В хелпе его нету, заглянем ка во внутрь ради спортивного интереса

Едить-колотить да это супер клад который легко позволит нам работать с видео! Но почему же мы его не видим нигде? да потому что он сырой, недоделанный, причем по коментам сразу видно, что его тупо не успели сделать и спрятали с глаз долой - “только фанаты заглянут внутрь”.

теперь листаем дальше. А там [цензура][цензура][цензура][цензура][цензура]!

представляете какую жопу можно организовать с таким количество таймеров, но не переживайте все 13 интервалов (интересное количество, наверное им все и объясняется) мы использовать не будем, в конструкторе мы проинициализировали всего лишь 9(!) таймеров. Я лично поставлю ящик пива кто сможет не запутавшись, написать и гарантировать мне корректность работы с таким количеством таймеров. А если еще добавить сюда NetStream который подкидывает программеру еще разные приятности, то хочется сказать:

“Респект и Уважуха Адобу! С его лучшим видео!”

а еще спасибо за все заботы о бедных программистах.
В следующих выпусках мы поговорим о практическом применением VideoDisplay и чем это грозит, поговорим NetStream’e и может что-то достанется и Video. До встречи

Начнем с буфера у Video в 9 плеере/AS3.

Раньше было все хорошо, при проигрывании буфер равнялся порции видео которое было доступно для проигрывания/перемотки. Но индусы поразмыслив решили, что это лишняя информация о которой программеру вообще не нужно знать, и теперь мы имеем буфер в размере “децл” по умолчанию он скачет где-то 0.1 - 0.2 секунды, если мы задали буфер ручками то это наше число + этот децл. Спрашивается нахера нам это нужно знать? Мне эта инфа совсем не нужна, мне гораздо интереснее знать на сколько я могу позволить пользователю подвинуть бегунок перемотки, сколько у меня фактически загружено, а не этот “важный” децл. Теперь с подачи индусов у нас отняли все более менее нормальные способы довести до пользователя состояния видео (всего каких-то 3 показателя длинна, сколько уже загружено(в секундах) и где мы играем). Остались только мега извраты для определения состояния видео если нету у видео мета тегов, но мега извраты мы не используем.

*Немного о мега извратах:
самый извратистый изврат это сделать seek в бесконечность в какой-то момент времени и он вернет количество секунд которые на данный момент. Располагая этой инфой можно в приблизительно прикинуть длину видео без мета тегов, и воссоздать наши 3 заветные величины. Но опять же это ИЗВРАЩЕНИЕ.

Скажем дружно “Респект и Уважуха Адобу! С его лучшим видео!”

Начнем с буфера у Video в 9 плеере/AS3.

Раньше было все хорошо, при проигрывании буфер равнялся порции видео которое было доступно для проигрывания/перемотки. Но индусы поразмыслив решили, что это лишняя информация о которой программеру вообще не нужно знать, и теперь мы имеем буфер в размере “децл” по умолчанию он скачет где-то 0.1 - 0.2 секунды, если мы задали буфер ручками то это наше число + этот децл. Спрашивается нахера нам это нужно знать? Мне эта инфа совсем не нужна, мне гораздо интереснее знать на сколько я могу позволить пользователю подвинуть бегунок перемотки, сколько у меня фактически загружено, а не этот “важный” децл. Теперь с подачи индусов у нас отняли все более менее нормальные способы довести до пользователя состояния видео (всего каких-то 3 показателя длинна, сколько уже загружено(в секундах) и где мы играем). Остались только мега извраты для определения состояния видео если нету у видео мета тегов, но мега извраты мы не используем.

*Немного о мега извратах:
самый извратистый изврат это сделать seek в бесконечность в какой-то момент времени и он вернет количество секунд которые на данный момент. Располагая этой инфой можно в приблизительно прикинуть длину видео без мета тегов, и воссоздать наши 3 заветные величины. Но опять же это ИЗВРАЩЕНИЕ.

Скажем дружно “Респект и Уважуха Адобу! С его лучшим видео!”

Буду периодически писать о моем продуктивном общении с видео во Flex/AS3.

Для начала скажу следующее:

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

И так для затравки поругаемся на длину видео:

если повезло все гуд, а если конвертили неизвестно чем, то жопа + меня раздражает злобное твоение еще на то время макромедии - звук и видео мы меряем в секундах, спрашивается какого лешего, если всеравно у нас есть дробные части и мы их можем использовать? не проще ли использовать миллисекунды?

Недавно искал в Яндексе рецепты как победить нежелание у FireFox передать флешке фокус, и набрёл на очень, как на мой взгляд интересную статью, которая раскрывает все естество людей работающих с Flash / Flex. Очень она меня порадовала, и отвлекла от проблем насущных. Приятного прочтения господа Вспышко-разработчики

Текст сохранен без изменений, источник rusarticles.com/article_37800.html:

Firstly будет вспышкой? Хорошая вспышка ссылается и к игроку Macromedia внезапному и к multimedia authoring программа используемая для того чтобы создать содержание оно (such as игры и киноие). Внезапный игрок будет применением клиента имеющимся в большинств браузерах стержня. Он отличает поддержкой для вектора и графиков растра, scripting вызванным языком АчтионСчрипт и двухнаправленным течь аудиоего и видеоего.
Вспышкой Macromedia будет интегрированная окружающая среда развития (ide) и внезапный игрок будет фактически машиной используемой для того чтобы побежать внезапные архивы, но nowadays эти термины были смешанными: “вспышка” может намереваться или authoring окружающая среда, игрок, или комплекта материалов заявки.

С своего введения в 1996, внезапная технология стала очень популярным методом для добавлять одушевленност и интерактивность к страницам стержня. Вспышку можно использовать для того чтобы создать сказовые одушевленност; конструировать элементы стержн-straniqy и также добавить видеоего к местам стержня. Websites сделанное с вспышкой может быть очень более взаимодействующе и flashieree (помилование каламбур) чем место сделало с только html.

Архивы вспышки, или “внезапные киноие”, обычно имеют дополнение к файлу swf и могут появиться как элемент web page или “быть сыгранным” в standalone внезапном игроке.

Должно к широкому использованию вспышки в рекламах стержня и экстренном времени оно принимает для того чтобы нагрузить эти страницы, инструменты вытекли для преграждать внезапное содержание в некотором или всех местах стержня, или временно или постоянно поворачивать внезапного игрока, such as FlashBlock и Adblock для браузера Mozilla Firefox.

Если вспышка была выведена из строя в web browser после этого, то потребители могут быть неспособны достигнуть некоторых Вспышк-zavisimyx websites, или могут испытать ухудшенную поверхность стыка потребителя.

Использование внезапного содержания хранит содержание web page в бинарном архиве и в виду того что вспышка использует одушевленност, конструкция страницы не статическая. Эти факторы делают Вспышк-osnovannoe содержимое неподобающе для индексировать двигателями поиска.

‘ misuse ‘ внезапного средства программирования водил к творению нового термина “Flashterbation индустрии,” где технология использована в дороге которая нуждается фокусе клиента.

На MAX 2007 Майк Дауни представил нового сотрудника Шаи Авидана, одного из создателей приложения iSeam Image Application (вместе с Ариэлем Шамиром). С его помощью можно растягивать и сжимать фото сохраняя не только качество, но и важные детали а также их пропорции. Берете фото парня на велике. Растягиваете по горизонтали традиционным образом—картинка искажается. А растягиваете методом iSeam—все остается на местах. Другой пример—удаление объектов. Почистить картинку от лодки не сотавляет никакого труда. Из кучи ботинок выбросить несколько—автоматика. В тот вечер зал стоял на ушах.

Но лучше один раз увидеть технологию еще до ее покупки Adobe'ом:

Или саму презентацию на Adobe MAX 2007:

А можно сразу попробовать rsizr.com — живое флэш-приложение.

Вышел уже и плагин Liquid Resize к Gimp. Работает пока медленно и бывают искажения. Пример работы. И еще один пример работы (из ранних).

Как это

При обработке картинки по технологии iSeam изменяются малозначимые для глаза области, подобно тому, как в mp3 при сжатии звука вырезаются "неслышимые" звуки (тихие после громких и т.п.). Как это происходит—хорошо видно на первом видео: картинка "сканируется" и определяется энергия каждой области. Области с низкой энергией становятся малозначимыми и будут трансформироваться первыми. Также в iSeam можно явно указать важные "неприкасаемые" области, или наоборот малозначимые—те, что "пострадают" в первую очередь. Дебианщик уже писал об этой технологии, не поленившись перевести часть оригинальной статьи (20 Мб, много формул).

И теперь этой техологией овладевает Adobe.

• BookmarkPanel
• AsClassWizard
• FlashApi
• SourceOptions
• StickiesNotes
• CodeReformatter
• RegularExpressionPanel
• SharedObjectReader

Начну с обычного примера:
(more…)

Все конечно уже читали, но вдруг кто-то пропустил: 7 reasons I switched back to PHP after 2 years on Rails.

Автор рассказывает, как два года переписывал PHP-движок на Ruby вдвоем с реально сильным Ruby-программистом (Jeremy Kemper aka bitsweat), а потом, обнаружив что за два года сделана только половина работы, все бросил и переписал на PHP за два месяца, сам. А Джереми ушел писать на Ruby в 37signals.

Мне нравится последний аргумент статьи:

"Rails — отличный учитель... Я люблю Руби за то, что он заставил меня по-настоящему понять ООП. Боже, Руби так прекрасен. Я люблю тебя, Ruby.
Но главная причина, по которой любой программист, изучая новый язык, думает, что новый язык НАМНОГО лучше старых — потому что он сам стал лучшим програмистом, чем был. Ты оглядываешься назад и видишь свой старый уродливый код на PHP, сравниваешь его со своим новым прекрасным кодом на Ruby и думаешь: “Боже, как уродлив этот PHP!” Но не забывай, что ты написал тот PHP-код годы назад и теперь несправедливо дискриминируешь целый язык.
Язык тут вообще ни при чем (вообще-вообще). Все дело в тебе, чувак. Ты стал лучше. Ты заслужил.
ОК. Я хочу сказать, что буду использовать Rails, когда начну новый проект с нуля, буду делать его с мышлением в духе Rails.
Но я надеюсь, что эта статья дойдет до кого-то думающего "Боже, как уродлив наш код. Если бы мы выбросили его нафик и переписали все на Rails, все было бы намного лучше!”

А вывод такой: пиши на том языке, который лучше знаешь.

15-18 октября 2007 года в Барселоне, Испания пройдет Adobe MAX 2007 Europe. Здесь все 200 сессий MAX Europe с фильтрацией—выбирай на вкус.

Говорят, в Испании недорогие дома: три дома у моря по цене 1 квартиры в Москве?

Собственно, так и есть. Начало блога было положено Ростом, вернее его словами, которые гласили: “Эй, чувак, когда ты откроешь свой блог ?”. И я таки созрел, иногда есть что-то полезное, чем хочется поделится, а пока достучишься к Росту, чтобы он запостил у себя, пройдет немало времени. Теперь буду сам пытаться :). Надеюсь, что принесу пользу и добавлю интересности в жизнь читателей

ps. блог пока на стадии настройки, так что пока тут будут я думаю проблемы внешним видом и может с некоторыми фичами :(.

Многоуважаемый ShaggySmile, один из популярнейших авторов русскоязычного Flash комьюнити, запустил новый проект под названием <a href="http://lifeflex.shaggysmile.com/">Life.FLEX</a>. Формат публикаций - конкретика, никакого мусора. В основном переводы. Очень полезный ресурс. Советую как начинающим так и профессионалам.

Вот например <strong><a href="http://lifeflex.shaggysmile.com/cookbook/streaming_an_mp3_with_flex_2_and_flash_media_server.html">Flex 2 и Flash Media Server - пример загрузки потокового MP3</a></strong>

Набрел на еще один интересный ресурс — сайт Компьютерной газеты. Честно говоря, я так и не понял, оффлайновое ли это издание, и можно ли номера газеты купить в России и в других странах СНГ (судя по доменной зоне, газета белорусская). Если это возможно, то я бы с удовольствием подписался на ее выпуски.

(more…)