Обновить
78
0

Пользователь

Отправить сообщение
Неделю назад столкнулся с проблемой производительности Raphael при интерактивном изменении документа в Opera и Firefox — пришлось отказаться. Первое время боялся, что придется пересаживаться на canvas, но потом попробовал jQuery SVG и оказалось, что для нашего юскейса его хватает.

А вообще никак не могу найти какую-нибудь библиотеку, которая из canvas переносит в SVG — в обратную сторону есть полно решений (что неудивительно — задача вполне себе несложная). У многих проектов такая фича заявлена как future, но ни один из них еще не предоставил хотя бы промежуточного кода. Жаль.

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

Автору спасибо за ссылки, хотелось бы поподробнее узнать об SVGweb — нас он оттолкнул тем, что использует Flash на старых IE.
Стал писать комментарий, который, я смотрю, стал розростаться до размеров статьи. Давайте я ее до ума доведу и опубликую на днях.
Насколько я понимаю, уязвимость в большей мере заключается в том, что WebGL дает страницам доступ к такому низкому уровню взаимодействия с аппаратной платформой, что у операционной системы остается слишком мало механизмов управления вычислительной нагрузкой.

Проще говоря, если тормозит флэш, то ОС может это отдетектить и предложить пользователю завершить процесс плагина, а вот с WebGL это становится проблемотичным. Т.е. некий злодей-флэшер может просто заставить повисеть или уронит браузер, а злодей-WebGL'ист — всю систему. Вот по этому поводу и разошлась дискуссия.
Использую Knockout в проекте и не могу сказать, что документация у него хорошая. Она неполная, нет того, что можно было бы назвать Reference. Но она завлекательная: классное видео с MIX11, где Стив Сандресон — автор фреймворка — за двадцать минут убедил меня, что MVVM — это именно то, что нужно на клиенте, а также заставил меня отказаться от Backbone, о чем, я, кстати, ни секунду не жалел. Примеры тоже впечатляют, есть ремарки на тему подписок — на каждое observable-поле можно подписаться — колбэк будет вызываться при изменении значения.

Но проблемы тоже есть. Например, на этой неделе вскрылось, что JSON сериализатор в нокауте не умеет работать с датами (Date object) вообще — при сериализации получаем null. Кроме того, не всегда понятно, когда в аттрибутах data-bind нужно писать выражения в кавычках или добавлять скобки для observable полей — понимание приходит с опытом, но не без необходимости пробежаться дебаггером по исходникам Нокаута.

Что еще? Темплейты не всегда подходят — иногда приходится собирать фрагменты DOM руками, и в этих случаях Knockout совсем не помогает, а может быть даже мешает, т.к. интеграция с ним требует дополнительных затрат кода.

Ну и наконец, однажды написав data-bind=«click: someHandler», я задумался: а чем же это отличается от onclick, которого все так боятся и ненавидят?..
Я сам так больше не пишу, а наличие клик-байндинга в фреймворке считаю ошибккой.
С точки зрения хранения да, UTC обычно хватает. А вот для решения всяких расчетных проблем, связанных с временем, без time zones не обойтись никак. На ХаккерНьюс предложили такой пример:

«Мы проводим еженедельный митинг каждый понедельник в 9 утра в Сан-Франциско. Вы сейчас в Лондоне и хотите присоединиться к митингу по Скайпу. Во сколько вы должны его включить?

7 марта 2011 — в 5 вечера
14 марта 2011 — в 6 вечера
29 марта 2011 — в 5 вечера

Чтобы рассчитать все это, требуется знать о правилах перехода на летнее время и о таймзонах в регионах участников»

Кроме того, строго говоря, проблема таймзон до сих пор не решена полностью. Сегодня большинство использует один источник правил работы с таймзонами — tzdata en.wikipedia.org/wiki/Tz_database
К сожалению, он не без багов. Например, Томская область долгое время значилась в зоне Новосибирска, хотя и перешла из одного пояса в другой в 2002 году. Обнаружили проблему только в 2008. Сейчас этот баг неактуален в связи с всеобщем сокращением поясов, но в случае с работой данными нескольких лет давности следует иметь его ввиду. Вполне вероятно, что подобный случай неединичен.
И в чем абсурд? Я уверен, что в западной Украине, которая частью СССР была где-то лет 40, есть люди, которые либо не знают языка вообще, либо им очень трудно воспринимать его.

Что такое 40 лет для страны? Пожилые люди разговаривают на украинском, но понимают русский. Их дети — ровесники наших родителей — учили в школе русский, но либо не смогли избавиться от акцента, либо вообще разговаривают на суржике. Их дети — наши ровесники и чуть постарше — вполне дуязычны (если в центре) — учили русский в школе, но знают украинский с детства благодаря общению с бабушками. Если они жили на западе, где даже в Советском Союзе украинский оставался языком делового общения, то говорить о двуязычии уже не приходится.

Кроме того, сейчас тем, кто родился в 91 году, уже 22 года — они отучились в школе и в институте — на Украинском.

Русский язык насаждался в стране, но родным он стал для одного-двух поколений. С учетом того, что язык для большинства был вторым, у многих словарный запас ограничен, их русская речь не отличается выразительностью и богатством. Многие в центральной Украине разговаривают на русском, но шутят, например, на Украинском — на русском они не могут отразить все аспекты настроения, всю иронию. Их любимые мультики — тоже на Украинском, многие действительно замечательные работы Киевнаучфильма даже не переводились на русский и их не показывали в остальных республиках Союза.

Да, есть восточные области, есть Закарпатье, но там ситуация особенная — они никогда не были ядром украинского этноса, и для них украинский — такой же чужой язык, как для остальной страны — русский, но по ним обо всей Украине судить нельзя. Кроме того, многие экономические и правовые термины известны населению только на украинском языке, и даже в русской речи они используются вместо русских аналогов.
На многих менее популярных среди разработчиков, но распространенных платформах вроде Symbian или Blackberry идут или Опера Мобайл, или Мини. Для них есть хорошие эмуляторы:

www.opera.com/developer/tools/

Кроме того, под Opera Mobile можно отлаживать с компьютера remote дебаггером в DragonFly. Кстати, на недавнем Google IO разработчики Андроида обещали, что такой же дебаггер появится и для их платформы.

Вообще довольно часто отладки под десктопными браузерами вполне достаточно: можно просто судить страницу и поправить строку запроса, чтобы она соответствовала устройству. Есть, конечно, различия между тем же Хромом и iOS Safari, но многие из них отражены в таблице ВебКитов, которую собирал PPK:

quirksmode.org/webkit.html
quirksmode.org/mobile/

За год они немного устарели, но пока еще остаются полезными.

Что еще? Держите ухо востро с современными технологиями — есть стереотип, что на современных мобильных платформах все появляется едва ли не в первую очередь, но не всегда это так. Например, в Android 2.x WebKit нет поддержки SVG — мы обожглись на этом. Также много нареканий на работу appCache в iOS, вплоть до того, что его категорически не рекомендуют использовать.
На мобильнике кнопка Обновить может быть скрыта, чтобы использовать экранное пространство по полной. Так и получается, что нажать на лого — один клик, а на Обновить — два кликаЖ показать контролы браузера — обновить.
Метод сам по себе интересный, другое дело, что применить на практике его довольно сложно. Возмем сценарий: один программист расставляет в коде случайные ошибки, а второй их ищет. Возникают вопросы:

1. Чем должен руководствоваться перый программист при создании ошибок. Он может расставить кое-где в методах throw new RuntimeException, или, например, поменять рандомно арифметические и логические операторы, или поудалять кое-какие условия. На мой взгляд, все эти внесенные ошибки будут весьма неглубокими и легко локализуемыми. Чего, к сожалению, нельзя сказать о настоящих ошибках. Может быть есть какой-то другой способ?

2. Как определить, сколько времени нужно дать на поиск ошибок? Допустим, у нас их десять. По часу на каждую? Можем ли мы утверждать наверняка?

Кроме того, если покрытие кода тестами заметное, то и внести ошибки в код таким образом, чтобы не падали тесты, очень трудно. С другой стороны, смысла вносить ошибки, которые приводят к падению тестов, нет. Так что задача «вредителя» — человека, расставляющего ошибки — очень усложняется. То есть мы не можем просто так взять и решить в середине проекта, что мы хотим оценить общее число ошибок, не учтя при этом, что как минимум двум разработчикам — «вредителю» и «ищущему» придется затратить на это весьма заметное время.

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

Самое главное, что все остались довольны. Теперь с нетерпением ждем следующего года.
Еще такой вопрос, правда ли, что длинна Url для IE ограничена 2 kb, и верно ли это для IE9?
1: есть изображение на канвасе. Требуется получить на сервере снапшот (png) какой-то отдельной прямоугольной области изображения.

2: есть изображение в одном канвасе. Как его скопировать в другой канвас? (Есть мысль, что первую проблему можно как-то с помощью этого решить).

3. Есть канвас, на котором сверху висит див с SVG. Как можно получить объединенное изображение в канвасе? (Есть мысль, что можно просто перенести SVG в канвас, а затем вставить один канвас в другой (вопрос 2), но не знаю, можно ли все єто сделать на клиенте)

Интересуют Chrome, FF4; IE9 и Opera по возможности, фолбэк на IE 8 не критичен.
Странно, у меня Андроид 2.1 и все аккаунты синхронизируются в бэкграунде. Вы точно уверены насчет ограничения 2.2 и выше?
А скажите, чем вы пользовались при написании программы: просто текстовым реактором и компилятором в командной строке или какой-то средой? Я пользовался плагином для Эклипса и остался доволен, несмотря на то, что он весьма сыроват.
Вообще здорово, статья понравилась. Конечно, я понимаю, что у вас какой-то опыт уже есть, и поэтому вы решили описать минимальную конфигурацию проекта, чтобы тот, кто следовал вашей инструкции, не наступал на ваши грабли, а дал Лейнингену сделать всю грязную работу. Но эффект внезапности оказался весьма сильным :) Получилось так: вот вам минимальная конфигурация, вот код, а вот очень сжатое объяснение по делу, что и где происходит. Пришлось статью потом еще раз внимательнее перечитать, чтобы заметить все детали.

Добавлю, что начинать с Clojure немного тяжеловато, особенно тем, кто приходит с традиционных языков (Java или C#) и привык к тому, что есть среда разработки, которая и подскажет где надо, и ошибки поотмечает в коде, и соломки подстелит, где надо, чтоб падать было помягче. Те, кто приходит с Лиспа или со скриптовых языков, как-то лучше подготовлены к тому, чтобы пользоваться редактором и вбивать команды в командной строке. Мне лично очень нравится LaClojure — плагин от JetBrains для своей IntelliJ. REPL, интеграция с Leiningen и какой-никакой автокомплит.

И еще вопрос: в чем преимущества clojure для веб-разработки? На мой взгляд, все-таки основной козырь языка — конкурентное программирование. Я лично пока использую его по аналогии с rule-engines — когда система правил компилируется в jar-файл, который потом используется приложением как черный ящик. Тут то же самое, только вместо какого-то языка правил — Lisp, а в результате получается не обязательно какой-то решатель или экспертная система, а все, что угодно. Сейчас получается так, что большая часть системы продолжает писаться на Java, но если есть узкие места — асинхронный процессинг или какая-то особенно изощренная логика, в проект кидается clojure.jar и вперед.
Есть еще один сервис, предоставляющий подробную статистику: trends.builtwith.com/ Существует он уже достаточно давно, хотя и не такой открытый — во всяком случае, я не нашел способа скачать исходные собранные данные.

Кроме сугубо контента они анализируют еще и http хедеры и по этим данным могут дать весьма интересную оценку, например, по вебсерверам: trends.builtwith.com/Web-Server

или по веб-фреймворкам: trends.builtwith.com/framework

или по операционным системам и софту: trends.builtwith.com/Server

Конечно, представление данных весьма условно, например, на последнем графике есть такие значения, как UNIX и mod_ssl, но все же посмотреть интересно.
Навскидку:

— свой движок для рендеринга страниц — Gecko
— свой движок для джаваскрипта — JagerMonkey
— XUL Runtime для поддержки расширений

Заставить все это работать на ограниченном железе достаточно тяжело.
Для поддержки расширений им требуется XUL runtime, который они за несколько лет и так ужали более чем в два раза. Добавьте к этому сам движок для рендера, который браузеры-надстройки вроде Dolphin с собой не тянут, и получится увесистый APK-файл.
Добавлю, что сами разработчики Мозилла говорят, что даже когда были доступны билды под ARMv6, производительность браузера была недостаточной для комфортного использования:

Sorry, the experimental ARMv6 builds are no longer available. They contained bugs that caused them to crash immediately, so they were no longer useful for testing.

While we'd like Firefox to run on as many phones as possible, we are focusing first on devices that can run current versions of Firefox with acceptable performance. As we improve Firefox's speed and memory use, it might become possible for us to support ARMv6 phones in the future, but we are not actively working on it now.

Звучит, прямо скажем, не сильно обнадеживающе. У самого Wildfire и очень хотел попробовать.

Пока пользуюсь связкой Opera Mini и Dolphin Mini (когда страница в Опере не работает).
Не будет, они используют NDK и предоставляют бинарники только для процессоров с поддержкой инструкций ARMv7. HTC Wildfire и многие другие популярные модели используют процессоры только с ARMv6.

Подробнее здесь:
wiki.mozilla.org/Mobile/Platforms/Android#System_Requirements

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Зарегистрирован
Активность