Сегодня 5 июля, суббота

Какой рейтинг вас больше интересует?

получить код

Главная /

Каталог блогов

/

Cтраница блогера Flash Ripper | ru - flash, flex, air, swf, flv, mpeg4, fla, ruby

Записи в блоге

	Flash Ripper \| ru - flash, flex, air, swf, flv, mpeg4, fla, ruby Голосов: 1 Адрес блога: http://flash-ripper.com/ Добавлен: 2008-06-12 21:16:04 блограйдером ZaiSL

Видео-записи докладов со встречи UAFPUG-43 в Киеве

2013-11-12 21:14:01 (читать в оригинале)

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

Блиц-доклады: каждый рассказал немного о себе и о том, что его волнует. См. видео ниже.
Лена Кузнецова рассказала о том, как не развалить проект. О популярных ошибках в работе команды, усвоенных на личном опыте. Смотрите видеозапись доклада.
Перерыва не было -- мы были слишком увлечены!
Иван Филимонов поведал девять тысяч важных сведений об асинхронном программировании. Изложил опыт лучших фреймворков, как клиентских, так и серверных. И презеновал фреймворк, этот опыт впитавший. Смотрите видео ниже.
Разыграли главный приз. Победил Sergey 'sencher' Senkov, Киев, Avenue Games. Поздравляем!
Обсудили близкий мастер-класса Роба Бейтмана по Away 3D TypeScript в Киеве 6 декабря 2013 г (за день до DevGamm 2013). Следите за объявлениями!
Обсудили новую инициативу (тсс! все подробности потом).

Видео блиц-докладов с UAFPUG-43

Блиц-доклад -- это когда каждый участник встречи выходит и коротко представляет себя и рассказывает о том, что его занимает сейчас. К сожалению, записать удалось далеко не всех, простите! Вот то, что есть:

Блиц: Иван Филимонов

Блиц: Михаил Ткачук

Блиц: Игорь Руссо

Блиц: Виталий Снитко

Блиц: Валерий Баштовой

Блиц: Александр Бурдун

Блиц: Лена Кузнецова

Блиц: Виктор Примак

Перейдем к докладам. Их было два, но они были объемными, а обсуждения заняли времени чуть ли не больше, чем сами доклады. Итак:

Доклад Ивана Филимонова на встрече UAFPUG-43: Асинхронное программирование

Презентация к докладу Ивана Филимонова

Доклад Лены Кузнецовой на встрече UAFPUG-43: Эффективная работа команды и наоборот

Презентация к докладу Лены Кузнецовой

Дискуссия после доклада Лены Кузнецовой:

Фото дискуссии:

Спасибо всем, кто пришел и сделал этот день таким интересным и вдохновляющим!

Ссылки:

Презентация к докладу Лены Кузнецовой о командной работе: http://vk.com/doc13147855_231442402
Презентация к докладу Ивана Филимонова о паттернах асинхронного программирования: http://www.slideshare.net/sunrize531/fpug-dzyga-presentation
Фреймворк Dzyga, реализующий удачные паттерны асинхронного программирования из доклада Ивана Филимонова: https://github.com/wysegames/dzyga
Регистрация на встречу UAFPUG-44 в Харькове -- харьковчане, не пропустите!

Тэги:

UAFPUG

UAFPUG-43

Записи докладов

Комментарии | Постоянная ссылка

Flash vs WebRTC в борьбе за браузерные VoIP звонки

2013-10-29 16:43:37 (читать в оригинале)

Если в каком-нибудь коммюнити спрашивают про аудио- или видеозвонки из браузера, как правило, получают ответ: "Попробуйте WebRTC". WebRTC, действительно, подходящая для этого технология и имеет ряд преимуществ над другими способами передачи аудио и видео в браузере.

Адепты WebRTC уже давно похоронили Flash, несмотря на то, что WebRTC местами имеет сырые реализации и доступна далеко не повсеместно. В настоящей статье представлены TOP 3 технологий звонков из браузера с описанием их преимуществ и недостатков.

Как известно, сам браузер "звонить" до последнего времени не умел. Не умел обрабатывать звук с микрофона, посылать, принимать и воспроизводить. Относительно недавно в некоторых браузерах появилась возможность захвата с микрофона и вебкамеры и дальнейшей отправки этих данных по защищенному SRTP протоколу, а так же воспроизведение потока с использованием адаптивного jitter buffer. Все эти новые возможности и есть не что иное, как WebRTC. Здесь стоит заметить, что браузерные звонки существовали за много лет до появления WebRTC, поэтому начнём с наиболее древних.

TOP 3 – Java

Временем появления браузерных звонков можно считать момент, когда Java апплеты стали поддерживать захват аудио с микрофона. Java Runtime Environment (JRE), как правило, уже установлена в системе, будь-то Linux или Windows. JRE так же присутствует в виде плагина в большинстве известных браузеров. Например, если заглянуть во вкладку chrome://plugins браузера Google Chrome, можно найти там NPAPI Java плагин. Этот плагин и будет средой для выполнения Java апплета. Второй, более продвинутый способ запуска, это JNLP (Java Network Launch Protocol), который позволяет, к примеру, кустомизировать окно "Загрузка апплета...".

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

Плюсы решения на Java:

простое;
нет лишних звеньев, возможность прямого взаимодействия с сервером по RTP;
широкая распространенность и доступность JRE для конечного пользователя.

Кажется, что все идеально? К сожалению, в Java есть проблемы с DSP для VoIP. А это весь "must have" набор:

AEC (Acoustic Echo Cancellation);
AGC (Automatic Gain Control);
Adaptive Jitter Buffer;
Noise suppression.

Теперь представим звонок с Java апплета без гарнитуры (наушников с микрофоном). Если провести этот эксперимент ночью, поставив колонки на полную громкость, можно напугать соседей до заикания. Всё из-за эхоподавления. Его нет. Отсутствие AGC заставит ваших пользователей крутить уровень громкости (нормальный AGC должен делать это за пользователя, чтобы не было слишком тихо или слишком громко). А отсутствие Adaptive Jitter Buffer выльется либо в большую задержку либо в "choppy audio" – прерывистый неразборчивый звук. В результате качество коммуникации будет далеким от оптимального.

Все недостающие алгоритмы можно теоретически реализовать на Java, но есть пара проблем. Во-первых, реализовать универсальные и производительные алгоритмы (например AEC) достаточно сложно: такая реализация потребует высоких трудозатрат и расходов на R&D. Во-вторых, реализация таких алгоритмов на Java может работать в несколько раз медленнее, чем на C/C++, что может повлечь серьезные проблемы с производительностью и перерасход ресурсов клиентского CPU.

Производители Java апплетов с функцией звонков реализуют собственные DSP процессоры или используют уже существующие решения на C/C++. Как правило, они подкладывают к апплету DLL библиотеки, которые берут на себя обработку вышеописанных DSP алгоритмов. В результате Java апплет имеет стандартные VoIP функции для обеспечения качественного звонка со всеми "must have" VoIP алгоритмами.

В конечном итоге остается два минуса Java:

кроссплатформенность - придется снабжать апплеты DLL библиотеками под Win и SO библиотеками под Linux;
сложность реализации этих DSP библиотек.

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

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

Незаслуженно покинута она по двум причинам:

недостаток встроенных возможностей по работе с DSP;
более распространенные для Web конкурирующие платформы, которые лишены такого недостатка.

О них далее.

TOP 2 – Flash

До некоторого времени Flash был технологией для красивых интерактивных баннеров.

В 2002 году появилась в релизе версия Flash Communication Server MX 1.0 - прародитель сегодняшнего Adobe Media Server. Flash Player 6, являясь тогда продуктом компании Macromedia, умел взаимодействовать с FCS MX 1.0 и обмениваться с сервером аудиопотоками. Это еще раз указывает на то, что WebRTC припозднился на 10 лет, а также то, что рынок начинает закрывать свои потребности за 10 лет до появления вменяемой технологии браузерного интерактива.

В это время Flash Player 6 уже умел захватывать аудио и жать его в NellyMoser и видео - в Sorenson Spark. Java в это время была слабо представлена в веб и Flash Player 6 в связке с сервером претендовали на мировое господство в области web-стриминга. Позже появились Red5, Wowza, но это немного другая история.

В качестве транспорта для аудио и видео в Flash Player 6 использовался протокол RTMP, который сегодня имеет открытую спецификацию, опубликованную Adobe.

Flash Player 6 в связке с сервером стал платформой для браузерных звонков, обладающей следующими функциями:

NellyMoser, Sorenson spark;
RTMP.

До полноценного браузерного VoIP тогда было еще очень далеко. AEC (Acoustic Echo Cancellation) в тот период, наверное, даже не было в планах. Но платформа делала свое дело и передавала звук и видео от одного плеера к другому через сервер.

Все, кто работают с VoIP, рано или поздно сталкиваются с задержкой. Когда разработчик впервые тестирует написанное им VoIP приложение, он не обращает внимания на задержку: звук есть, картинка есть - и хорошо. Первыми задержку замечают пользователи и пишут репорты типа: «I say "one" then Bob says "two" and it seems it takes about 5 seconds. Why?» Потом уже два разработчика начинают тестировать звук и не понимают, куда пропали эти 5 секунд, ведь у них сервер Xeon на 100500 ядер и он не может тормозить.

Задержка была в связке Flash Player 6 + Flash Communication Server MX 1.0, а также осталась в следующих версиях сервера, включая последнюю Adobe Media Server, с ней безуспешно боролись на Wowza и Red5. Причина, конечно, проста и известна каждому VoIP разработчику: RTMP протокол работает поверх TCP, а потому не приспособлен для полноценного VoIP. Сохранить пакеты любой ценой – это не тот случай, когда дело касается передачи звука либо видео. Но это главная задача TCP протокола: сохраняем пакеты и получаем задержку. Все просто.

Отсутствие полноценного UDP транспорта сделало невозможным развитие интерактивных сервисов. Например, если участник вебинара хочет пообщаться face-to-face с ведущим, у него не всегда получится это сделать нормально. Все в значительной степени зависит от качества сети и потерь. В результате на базе RTMP развивались, в основном, video on demand сервисы, или live video, или вебинары с одним ведущим, где задержка не так важна.

Кстати, здесь вопрос к Macromedia: почему они не сделали audio и video стриминг по UDP. Это бы значительно упростило жизнь всем разработчикам и конечным пользователям. Очевидно, что VoIP функция браузера была на переферии и над ней никто особо не задумывался, а для интерактива с данными (sharedobjects, callbacks итд) TCP подходит оптимально.

Ситуацию с UDP в Flash Player сдвинула компания Adobe, когда в версии плеера 10 ввели поддержку нового протокола RTMFP и эхоподавление. В 11 версии Flash Player добавили поддержку кодеков G.711 и H.264. В AS3 API так же имеются упоминания про Adaptive Jitter Buffer для G.711 и Speex.

VoIP возможности Flash Player 11:

Nelly Moser, Speex, G.711, Sorenson Spark, H.264;
RTMP, RTMFP;
AEC;
Adaptive Jitter Buffer;
AES шифрование.

Благодаря этим нововведениям, Flash Player имеет практически все необходимое, чтобы стать VoIP платформой №1 для браузера: шифрование AES защищает трафик между браузером и сервером от посторонних; AEC и Jitter Buffer обеспечивают качество воспроизведения звука; новые кодеки совместимы с традиционным VoIP, а RTMFP протокол работает по UDP. Не хватает AGC (Automatic Gain Control). Его отсутствие не смертельно, но неприятно для тех, кто понимает пользу этой функции для VoIP и не понимает, почему её до сих пор нет. Помогает перенос AGC-фильтра на сторону сервера.

Еще одна маленькая неприятность от Adobe - невозможность во Flash Player нормально проиграть H.264 поток, закодированный для передачи по RTP. В багтрекере Adobe cуществует "by design" баг, который накладывает ограничение 1 NALU per video frame. Это ограничение отрубает все H.264 кодеры, которые дают поток, совместимый с RTP. В результате приходится применять транскодинг, что в свою очередь вызывает избыточное потребление ресурсов CPU, которого в принципе хотелось бы избежать.

Flash RTMFP основан на UDP и довольно прилично передает звук. Но и здесь не обошлось без сюрпризов. В доках Adobe AS3 сказано, что RTMFP для аудио и видео поддерживает три режима: надежная доставка (reliable), частично-надежная доставка (partially reliable), ненадежная доставка (unreliable). В этих же доках есть только два флага для audioReliable и videoReliable: true, false. False описывается как режим частичной доставки (partially reliable). В итоге, получается, что ненадежная доставка (unreliable) пропала, а для передачи звука она наиболее важна.

Частичная доставка – это TCP подобные ретрансмиты, которые происходят очень ограниченное время, но и этого хватает, чтобы испортить звук на нестабильной сети. Такие ретрансмиты вызывают джиттер, который портит поток. Jitter buffer на принимающей стороне в данном случае не помогает, т.к. идет очень большой разброс. Решением является переход к ненадежной доставке (unreliable) звука. В Flash Player API нет возможностей её включить, и приходится добавлять её на уровне протокола на серверной стороне.

Например, в WebRTC - Flash RTMFP SIP Gateway Flashphoner Web Call Server реализован хак на уровне RTMFP протокола, который позволяет полностью исключить ретрансмиты в RTMFP и обеспечить unreliable доставку. Это в разы повышает устойчивость потока к потерям и лагам сети. Можно получить разборчивый Speex поток до 12% потерь в сети. Тот же поток заметно рвется в случае частичной доставки(partially reliable) причем рвется на тестах с Adobe Flash Media Gateway, несмотря на то что эта часть Adobe Media Server должна по задумке являться эталонной реализацией RTMFP протокола.

Плюсы Flash:

самый широкий охват браузеров;
привычная технология для разработчиков - Flex/AS3;
качественная VoIP передача аудио и видео.

Минусы Flash:

требует промежуточного сервера (не поддерживает открытые UDP протоколы, такие как RTP/SRTP);
относительно медленное улучшение VoIP части разработчиком (Adobe): отсутствие AGC, H.264 1 NALU per frame problem.

Кстати, что мешает разработчикам Flash Player внедрить WebRTC стек?

TOP 1 – WebRTC

И наконец, любимец публики, зомбирующая разработчиков, кошмарящая телекомов и активно обсуждаемая технология WebRTC. Рынок живет ожиданиями, а в ожиданиях сегодня доминирует WebRTC.

На текущий момент WebRTC присутствует в трех распространенных браузерах в состоянии production:

Google Chrome;
Mozilla Firefox;
Mozilla Firefox mobile.

А также в двух браузерах в состоянии beta:

Google Chrome Beta Mobile;
Яндекс Браузер.

Яндекс Браузер не проверяли, но по информации в сети, он не всегда корректно работает с WebRTC, поэтому мы поставили его в beta в нашем списке.

Даже в Chrome браузере WebRTC продолжает оставаться недоработанной, хотя уже прошло немало времени после релиза. Простые вещи работают, но когда дело доходит до смены состояния сессии по SDP (аналог re-INVITE в SIP) или при других нетривиальных действиях, появляются разные сюрпризы, которые сильно огорчают.

Однако это не мешает WebRTC завоевывать все новые умы и определять вектор развития VoIP и вообще интерактивных технологий в Web. И это не удивительно по двум причинам:

WebRTC поддерживается гигантами индустрии;
WebRTC имеет действительно удачную и продуманную архитектуру, избавленную от ошибок и недостатков, выявленных в браузерных плагинах, которые существовали до неё.

На технологической начинке WebRTC хотелось бы остановиться отдельно, это:

SRTP, DTLS, ICE, STUN, AEC, AGC, Adaptive Jitter Buffer, Opus, VP8

Выглядит так, как будто в браузер встроили софтфон. Не хватает только поддержки SIP.

Действительно, набор используемых в WebRTC технологий больше похож на VoIP SDK. SRTP и DTLS обеспечивает защиту трафика между WebRTC узлами. ICE и STUN помогают преодолеть NAT, выставив с обеих сторон кандидатов для созвона в виде простых пар host:port. AEC, AGC и Jitter Buffer работают для того чтобы сделать аудио и видео качественным – без лагов и задержек. Кодеки Opus и VP8 хорошо подходят для глобального Интернета, где битрейт до конечного пользователя может легко падать до очень низких значений вопреки обещаниям провайдеров про каналы в 100Mbps.

Несколько омрачает картину отсутствие поддержки WebRTC в других браузерах, таких как IE, Safari, Opera и т.д. К недостаткам еще можно отнести несовместимость с традиционным VoIP оборудованием. Например, производители SIP/VoIP продуктов, коих великое множество, были бы очень признательны поддержке обычных SIP/RTP протоколов и кодеков для совместимости с миллионами устройств.

Здесь стоит упомянуть, что WebRTC изначально задумана как peer-to-peer между браузерами и ориентирована на шифрованный SRTP трафик. Скорее всего, именно поэтому VoIP вендорам, которые обмениваются стандартными RTP потоками, придётся внедрять у себя WebRTC совместимый транспорт и кодеки.

Хотя и здесь не все так плохо. Существуют шлюзы для обеспечения такого рода совместимости. Например WebRTC SIP Gateway Flashphoner Web Call Server 3 является шлюзом, который может соединить WebRTC клиента и стандартное SIP/RTP устройство будь то VoIP свитч или GSM шлюз, работающий по SIP. Таким образом, данная проблема вполне решаема путем ввода промежуточного ПО.

Преимущества и недостатки WebRTC достаточно прозрачны:

Плюсы WebRTC:

полноценное VoIP в браузере

Минусы WebRTC:

недостаточно поддерживающих браузеров
отсутствие RFC (Cпецификации находятся в draft-ах и меняются, хотя нужно признать, что по сравнению с тем, что было год назад, сейчас все более-менее стабильно).
отсутствие совместимости с традиционным VoIP (by design).

Ожидания и ресурсы, стоящие за WebRTC, с лихвой перекрывают текущие минусы, поэтому смело отдаем ей законное первое место TOP1 в списке браузерных технологий для VoIP.

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

Итак, мы закончили разбор трех технологий для web звонков, обобщим все описанное выше в виде следующих таблиц:

VoIP фильтры

Сетевые протоколы и спецификации

Аудио кодеки

Видео кодеки

Поддерживаемые браузеры

Некоторые пояснения:

Все возможности Java клиента отмечены символом \\*. Это означает, что все вышеописанное может быть теоретически реализовано на Java. Вопрос в том сколько времени это займет, как хорошо это будет работать и сколько будет весить исполняемый файл со всеми библиотеками.
С символами "плюс", "минус" и "вопрос" все должно быть понятно.
В последний столбец таблицы было решено добавить для сравнения один из продвинутых VoIP софтфонов "традиционной" VoIP телефонии - Bria.

Ну вот и пришло время заняться подсчетом.

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

Первое место в этой гонке VoIP технологий и коммуникационных протоколов занимает VoIP софтфон - 54% (21 попугай из 39). На втором месте WebRTC - 44% (17 попугаев из 39) и Flash, который идет за WebRTC с 41% (16 попугаев из 39).

В окончании, хотелось бы поставить вопрос: если мы строим облако для web-звонков с выходом на SIP/VoIP/PSTN, на чем мы будем это облако строить, какие материалы использовать?

Отвечая на этот вопрос, придется затронуть еще пару моментов. Первый из них связан с мобильными устройствами, второй - с проходимостью через брандмауэры.

Не секрет, что сейчас важна поддержка Android, iOS SDK и кроссплатформенность. С мобильными устройствами все более или менее понятно. Есть несколько вариантов:

Adobe Air – тот же Flash с поддержкой тех же RTMP/RTMFP протоколов. Серьезный недостаток – нет эхоподавления. Преимущество – кроссплатформенность. Разворачиваем один и тот же код на Android и IOS.
Браузер с поддержкой WebRTC. Недостаток – не очень удобно. Нативное мобильное приложение будет лучше в look and feel терминах.
Портировать WebRTC код под IOS и Android. Недостаток – не кроссплатформенно и нетривиально.
Использовать стандартный VoIP SDK с поддержкой SIP/RTP и портировать на IOS и Android. Недостаток – не кроссплатформенно, несовместимо с WebRTC. Преимущества – совместимо с традиционным VoIP оборудованием.

Теперь про брандмауэры(firewalls). Как звук пройдет через брандмауэр, если UDP на нем отключен? Ответ: для этого потребуется переключение на TCP транспорт. Подойдет например Flash RTMP.

А если весь трафик организации идет через proxy, и админ закрыл весь не HTTP трафик? Тогда придется использовать HTTP туннелированные, например RTMPT, что, кстати, не лучшим образом скажется на задержке.

В итоге получаем супероблако для VoIP звонков такого вида: для передачи аудио и видео используем WebRTC, RTMFP, RTMP, RTMPT, Java Applet. Для интеграции со стандартным VoIP используем SIP, RTP. Для мобильных устройств: Adobe Air, WebRTC, SIP/RTP клиентов.

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

Что из нее убрать, чтобы облегчить – решать вам.

Материал подготовлен при участии специалистов компании Flashphoner

Тэги:

WebRTC

flash

java

voip

sip

Jitter

aec

AGC

Transcoding

Applet

UDP

TCP

flash player

RTP

SRTP

NALU

ICE

NAT

h.264

H.263

VP8

G.711

Speex

G.729

STUN

TURN

Opus

NellyMoser

iLBC

Adobe AIR

iOS

android

RTMP

RTMFP

Hold

Transfer

Комментарии | Постоянная ссылка

Как баннеры убили флэш

2013-10-24 02:41:42 (читать в оригинале)

На FWA -- статья про 10 причин, почему ФЛЭШ НЕ УМРЕТ НИКОГДА. Неожиданно из нее я понял обратное: ПОЧЕМУ ФЛЭШ ДОЛЖЕН БЫЛ УМЕРЕТЬ и почему ему не дадут умереть спокойно. Итак:

За три года HTML5 и близко не подошел к тому, что может флэш. И это -- гуманно.

Я могу все объяснить! И сейчас объясню:

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

Они не нужны сети

Не нужны обычным людям. Их не пойдут читать еще раз. Они нужны лишь брэндам, пытающимся через них БЫСТРО ВПАРИТЬ СВОЙ ТОВАР. Также они нужны студиям, зарабатывающим на создании этих сайтов. А людям они не нужны и часто -- вредны.

Флэш -- слишком сильный инструмент продаж

И он в этом не виноват. Он не виноват в том, что его использовали столь алчно. Флэш гибнет несправедливо. Но справедливости не существует.

Маркетинговый трэш надоел

С помощью флэша легко делать вещи, подавляющие волю и сознание пользователя, легче впаривать ему товарчики. Он увидит и купит. Или не купит. В любом случае, его сознание было подвергнуто насилию и он тратил энергию на то, что не просил. Поэтому в нем родится фрустрация. Возможно, он даже не поймет причину, осознает ее позже, когда в тысячный раз увидит ФЛЭШ-БАННЕР. В нем родится пассивная ненависть к этому узурпатору внимания. Ведь он хочет сам РЕШАТЬ КУДА СМОТРЕТЬ. А флэш-баннеры грубо нарушают право на эту свободу -- свободу смотреть куда хочешь.

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

Некогда во флэше было модно шутить о мировом доминировании. Это была лишь часть шутки. Флэш стал диктатором на самом деле. И был свергнут. Это была революция против тирании ГИПЕРИНТЕРАКТИВНОСТИ над сознанием.

Флэш - это многомерное гипервидео, и в какой-то момент его стало слишком много. От него просто устали. Людям захотелось жить без страха, что на тебя из-за угла набросится агрессивный флэш-баннер и тебе придется с ним бороться. У многих к флэшу появился почти болевой рефлекс, и он сработал, когда пришло время.

Да, на HTML5 все еще очень трудно создавать такие гипермедийные продукты, как на флэше, смешивающие в себе все: видео, интерактив, графику и типографику, интерактивность.

HTML5 гуманнее Flash, потому что он слабее

С его помощью труднее перегружать сознание зрителя, чинить насилие над вниманием того, кто не просил. Всплеск HTML5 - это бессознательная попытка сети вернуться к своему более примитивному и гуманному состоянию. Чтобы можно было серфить спокойно, не шарахаясь. Это тоже закончится. Но сейчас HTML5 молод и неопытен, как когда-то флэш. Сейчас главные эксперименты "просто так" делают на нем, как когда-то делали на Флэше.

А флэш стал коммерческим на 99% -- и он, конечно не умрет, пока его не убъет Adobe.

Которая, кстати, на нем не зарабатывает, а терпит убытки.

И я люблю Флэш -- как бессмысленное искусство.

Тэги:

HTML5 vs. Flash

Философия флэшера

Обман восприятия

Комментарии | Постоянная ссылка

Как быстро найти все полезные комментарии к хабрапосту

2013-10-22 17:33:18 (читать в оригинале)

Заинтересовался я такой темой: как учить маленьких детей программированию.

И мне добрый человек Ваня Филимонов (он на UAFPUG-43 очень интересно рассказал про асинхронное программирование во всех его проявлениях, и доклад его мы скоро выложим) тут же дал мне ссылку на хорошую статью на Хабре: "Из опыта создания кружка программирования для детей"

Автор статьи, дай ему Господь терабайты счастья, изложив свою методику, обратился к аудитории за ссылками на полезные игры, софт и материалы по теме.

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

Пошаговая инструкция:

Откройте любую статью на Хабре.
Откройте консоль браузера ( Ctrl+Shift+J в Chrome и FF, F12 в IE ).
Введите туда этот код на jQuery и нажмите Enter:
```
$(".comment_body").hide().has(".message>a").show();
```
Готово -- видны только комментарии, содержащие ссылки!
Тут же находится крутейшая ссылка про то, Как научить дошкольника Лямбда-исчислению!

Если вам интересно, то этот код работает и читается так (слева направо):

"Найди все элементы с классом ".comment_body" и спрячь() их, а потом найди те из них, у которых есть потомки с классом ".message", содержащие>ссылки, и покажи() их."

А вот -- пример того же функционала, только переписанного правильно:

$(".comment_body:not(:has(.message>a))").hide();

А в это время в реальной жизни:

Продолжается регистрация на встречу UAFPUG-44 в Харькове 16 ноября!

Тэги:

habr

Ваня Филимонов

jquery

Инструменты

обучение

Комментарии | Постоянная ссылка

Вакансия Flash Developer, Киев, офис

2013-10-20 14:41:19 (читать в оригинале)

Молодая, динамично развиващющаяся компания... Кхм, о чем это я.

В общем ищем двух человеков, pyton и flash.

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

http://wysegames.com/ru/

Юзаем git, jira, флешеры живут на своих великах и as3, питонисты - на tornado, 2.7 питоне

Подавляющее большинство работают на idea и pyCharm

Библиотеки написанные на рабочем месте можно вытаскивать в опенсорц, всячески юзать и повышать чсв (https://github.com/wysegames). Код - страшный, честно разгребаем на модули и приводим в состояние чтобы не было мучительно стыдно.

Офис находится на Петровке. Вилки от меня не будет.

skype: kyzi_007

Тэги:

work

Комментарии | Постоянная ссылка

Страницы: ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 ...

Блограйдеров
14514

Блогов
219965
(+0 сегодня)

Сообществ
1311
(+0 сегодня)

Рыбалка
по среднему баллу (5.00) в категории «Спорт»

Категория «Политики»

Взлеты Топ 5


+93	129	обаятельный инквизитор
+2	95	Технология пошива штор. Обучение. Подъёмные шторы.

Загрузка...

BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.