Если вдруг надумаете реализовать, хочу еще сделать одну ремарку. Рендеринг UI может включать в себя недетерминированные алгоритмы (у нас, например, это хорошо заметно на антиалиасинге шрифтов, которым видимо занимается графическая система), поэтому при сравнении успехом считается совпадение двух картинок с определенной заранее заданной максимальной погрешностью. В прочем, алгоритм расчета этой погрешности может быть индивидуальным.
Спасибо за ссылку, насколько я понял, пробежавшись по сайту, sikuli все-таки заточено под функциональное тестирование, несмотря на то что, технически позволяет искать шаблонную картинку на экране. Плюс, если Вы намеренно изменили внешний вид, то Вам придется менять сами тесты, в нашей системе в 99% случаев тесты остаются неизменными. Но замечу, что наш робот тоже изначально занимался лишь функциональным тестированием, модуль тестирования скриншотов появился позже и достаточно хорошо вписался в существующую архитектуру.
Мы для тестирования верстки в наших проектах используем другой, более «тупой», но, возможно, более эффективный подход. Робот запускает браузер, устанавливает ему заданный размер и начинает прокликивать указанные в тестовом скрипте страницы. В том же скрипте указано какие страницы (и какую область) нужно сфотографировать (сделать скриншот) и какое имя дать скриншоту. Робот фотографирует и смотрит наличие на диске существующего скриншота с таким же именем. Если такой скриншот найден, то он считается эталонным и происходит попиксельное сравнение двух скриншотов. Если скриншоты совпадают, тест считается пройденным. Если скриншот не найден, то он создается на диске. Процедура создания эталонных скриншотов проста, запускаем все скрипты, просматриваем все полученные картинки один раз глазами, чтобы убедиться что все выглядит правильно, далее робот все делает за вас. Если тест упал, открываем невалидную картинку (робот делает diff, и подсвечивает различающиеся области красным) проверяем глазами была ли разметка сломана или это плановое изменение. Если поломано — чиним, если все нормально, удаляем «плохой» эталон и запускаем тест еще раз, чтобы создать новый.
Анимация и функциональность это вещи не взаимоисключающие, более того, часто правильная анимация значительно улучшает UX. А с приходом touch уже сложно представить себе полностью статичный интерфейс.
Мне показалось что lublushokolad имел ввиду реализацию паттерна Deferred именно в jQuery. В любом случае Deferred имеет смысл использовать если у запроса может быть несколько подписчиков. Это опять же зависит от конкретных задач приложения и от стиля программирования. Для демонстрации я выбрал вариант с одним подписчиком.
Ну 20 ответов там или 20000 сложность отладки от этого не должна зависеть. Есть две части системы, которые друг о друге ничего не знают. Каждая часть просто хорошо делает свое дело. А делает она его хорошо, потому что когда Вы писали эти части вы описывали сценарии которые они реализуют юнит-тестами. Интерфейс взаимодействия между ними настолько прост, что вероятность ошибки там очень мала. Но если ошибки все-таки обнаружатся, то процесс отладки прост. Воспроизводим проблему, отключаем кэш, если проблема осталась ищем ошибку в приложении с отключенным кэшем, если ошибка пропала, локализуем ошибку в кэше, покрываем тестом и продолжаем радоваться жизни не боясь что кто-то снова что-то сломает во вновь написанном коде.
> Какой смысл кешировать данные с ключом запроса?
Сами же отвечаете: "> Сервер всегда выдает актуальные данные и конфигурируется запросом (это ожидается)"
> Что это за мини-memcache?
Если мини-memcache для Вашего приложения не подходит, напишите свою реализацию localCache, всего-то реализовать 2 метода get(key) и set(key, data), хоть на соседний сервер сохраняйте, который пингуется лучше.
> Фишка в том что кеширует по строке запроса, а это впринципе неправильно
Это всего лишь один (самый простой для примера) вариант реализации.
>если ваша аппликуха зовет один и тот же урл много раз в своем процессе. Это какие-то костыли из-за недостатка навыка в разработке high avalability
Навыков в разработке high availability приложений у меня действительно не много, но все что я хочу, так это писать в своем приложении сколь угодно много раз так:
var myData = dataProvider.getData({ ...settings... });
при этом не задумываясь какой урл и сколько раз позовет моя аппликуха, и позовет ли вообще, пусть об этом позаботятся те люди, которые хорошенько изучив статистику запросов и распределение времени «протухания» данных разных типов правильно реализуют кэширующий слой или докажут его несостоятельность и ограничатся настройкой HTTP кэширования (задача тоже не тривиальная). Ну а если такие специально обученные люди отсутствуют, то к этому вопросу я могу вернуться сам после реализации бизнес-логики моего приложения и основательно занявшись оптимизацией, не модифицируя при этом логику.
Думаю мне стоит оговорится, что предложенное решение не панацея от всех бед, а лишь несколько паттернов, для которых можно найти как правильное, так и неправильное применение. И здесь видимо тот случай, когда «незнание законов не освобождает от ответственности».
В последнее время набираются популярность мобильные html5 приложения, которые могут работать оффлайн. Используя localStorage кэш, Вы можете какое-то время работать (просматривать, а если постараться, то и редактировать данные), даже не подозревая об отсутствии связи. И здесь важно кэширование именно на уровне запросов к данным.
> как получилось так, что операциям нужны одни и те же данные N раз
А что, если я сегодня посчитал числа фибоначи до миллиона, то завтра мне это уже точно не потребуется? :)
> 1-й запрос — браузер ответил данными и сказал, что их можно хранить 5 минут
Вероятно Вы имели ввиду сервер, а не браузер.
Спасибо, за очень доходчивый туториал по кэшированию http запросов. Но, во-первых, как браузер справится с кэшированием результатов работы функции complicatedStuff. Во-вторых, сценарии работы с данными на клиенте иногда выходят за привычные запрос/готовый ответ. Например, два ответа от сервера инициированные двумя разными запросами могут содержать пересекающиеся данные. Если сделать кэш более интеллектуальным, то ответ последнего запроса может обновить данные в кэше для первого запроса. Браузер с такой задачей точно не справится.
В целом я согласен, что в предложении «Не смотря на то, что кэширование может быть настроено на уровне HTTP протокола, часто оно не удовлетворяет реальным требованиям» слово «часто» лучше заменить на «иногда».
Кэширование на сервере означает необходимость пойти на сервер и спросить либо результат запроса (если он закэширован на сервере), либо информацию о том что данные не менялись и можно показать то что есть в кэше браузера. Но вот сама необходимость на каждый чих спрашивать у сервера «как там дела» может значительно снижать производительность клиентского приложения, да и лишняя нагрузка серверу не нужна. Как я уже упомянул в статье время соединения с сервером может в несколько раз превышать обработку запроса и время пересылки данных.
Во-первых, если в Вашем приложении простой алгоритм кэширования, например нужно обновлять данные раз в день, то естественно это лучше реализовать на уровне HTTP. Во-вторых, как было сказано в статье, решение, позволяет кэшировать не только результаты HTTP запросов. По-поводу размера local storage, логика чистки может быть реализована в классе localCache. В простейшем варианте это может быть полный сброс кэша при достижении лимита, в более сложных — отслеживание частоты запросов или любой другой алгоритм на Ваше усмотрение.
Если бы в условии задачи было обязательное использование jQuery для реализации слоя, то Deffered там скорее всего был бы. Здесь демонстрируется решение не завязанное ни на какую стороннюю JS библиотеку.
Сами же отвечаете: "> Сервер всегда выдает актуальные данные и конфигурируется запросом (это ожидается)"
> Что это за мини-memcache?
Если мини-memcache для Вашего приложения не подходит, напишите свою реализацию
localCache, всего-то реализовать 2 методаget(key)иset(key, data), хоть на соседний сервер сохраняйте, который пингуется лучше.> Фишка в том что кеширует по строке запроса, а это впринципе неправильно
Это всего лишь один (самый простой для примера) вариант реализации.
>если ваша аппликуха зовет один и тот же урл много раз в своем процессе. Это какие-то костыли из-за недостатка навыка в разработке high avalability
Навыков в разработке high availability приложений у меня действительно не много, но все что я хочу, так это писать в своем приложении сколь угодно много раз так:
при этом не задумываясь какой урл и сколько раз позовет моя аппликуха, и позовет ли вообще, пусть об этом позаботятся те люди, которые хорошенько изучив статистику запросов и распределение времени «протухания» данных разных типов правильно реализуют кэширующий слой или докажут его несостоятельность и ограничатся настройкой HTTP кэширования (задача тоже не тривиальная). Ну а если такие специально обученные люди отсутствуют, то к этому вопросу я могу вернуться сам после реализации бизнес-логики моего приложения и основательно занявшись оптимизацией, не модифицируя при этом логику.
> как получилось так, что операциям нужны одни и те же данные N раз
А что, если я сегодня посчитал числа фибоначи до миллиона, то завтра мне это уже точно не потребуется? :)
Вероятно Вы имели ввиду сервер, а не браузер.
Спасибо, за очень доходчивый туториал по кэшированию http запросов. Но, во-первых, как браузер справится с кэшированием результатов работы функции complicatedStuff. Во-вторых, сценарии работы с данными на клиенте иногда выходят за привычные запрос/готовый ответ. Например, два ответа от сервера инициированные двумя разными запросами могут содержать пересекающиеся данные. Если сделать кэш более интеллектуальным, то ответ последнего запроса может обновить данные в кэше для первого запроса. Браузер с такой задачей точно не справится.
В целом я согласен, что в предложении «Не смотря на то, что кэширование может быть настроено на уровне HTTP протокола, часто оно не удовлетворяет реальным требованиям» слово «часто» лучше заменить на «иногда».
localCache. В простейшем варианте это может быть полный сброс кэша при достижении лимита, в более сложных — отслеживание частоты запросов или любой другой алгоритм на Ваше усмотрение.