В этом году на конференции Full Frontal, оффлайн-приложения были популярной темой. Пол Кинлан сделал отличный доклад «Строим веб-приложения будущего. Завтра, сегодня и вчера» (вот его слайды), в котором он сравнивал ощущения пользователей от работы с 50 популярными мобильными приложениями для iOS и Android с ощущениями от веб-сайтов и приложений.

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

Обратите внимание! Я не рассматриваю вопросы кэширования ресурсов приложения — вы можете использовать App Cache или гибридное решение (вроде PhoneGap), это не принципиально [От переводчика: на Хабре есть подробная статья про особенности работы с Application Cache API]. Это руководство посвящено скорее тому, как спроектировать архитектуру веб-приложения для работы в оффлайн-режиме, а не тому, какие механизмы использовать для его реализации.
Читать дальше →

У разработчиков веб-приложений на Caché и Ensemble часто возникает задача «file upload» — загрузки файлов с браузера. Недавно на форуме по Caché на SQL.ru снова возникло несколько вопросов о том, как сделать фоновую загрузку файлов. Решил описать как это можно сделать с использованием технологий CSP и ZEN.
Читать дальше →

Добрый день!
В этой статье мы расскажем о том, как мы работаем с кешем в plus1.wapstart.ru, какие проблемы у нас возникали и как мы решали некоторые частные случаи.

Для начала о терминологии.

Под «кешем» в этой статье я буду понимать какое-то быстрое хранилище, которое может использоваться, в том числе, и для кеширования. При этом хранилище должно обладать стандартизированным интерфейсом.
Сервер/хранилище — это какое-нибудь приложение, которое может хранить данные и давать к ним доступ по интерфейсу, который описан ниже. Например, этим приложением может быть memcached.

Мы используем фреймворк onPHP. В нем есть абстрактный класс CachePeer, от которого должны наследоваться все реализации кешей. Интерфейс любой реализации сводится к следующим методам.

		abstract public function get($key);
		abstract public function delete($key);
		
		abstract public function increment($key, $value);
		abstract public function decrement($key, $value);
		
		abstract protected function store(
			$action, $key, $value, $expires = Cache::EXPIRES_MEDIUM
		);
		
		abstract public function append($key, $data);

В нашем мире существуют следующие реализации CachePeer (кликабельно)

Читать дальше →

Всем привет! Плагин Hyper Cache — лучшее средство для снижение нагрузки на блог WordPress, о нем я бы и хотел поговорить. Те кто добивался высокой посещаемости на своем блоге (высокая, это от 1000 человек) знают, что нагрузка на хостинг сильно возрастает, страницы начинают долго грузиться, короче сайт начинает тупить. Расскажу немного, от чего появляется нагрузка на [...]

В этой статье я расскажу о том, как мы подружили Cache + Erlang, и зачем нам это нужно. СУБД Cache была выбрана в качестве хранилища данных. Также мы создали и эксплуатируем MCA(Middleware for Cache Applications) — промежуточное программное обеспечение, обеспечивающее конкурентную модель взаимодействия Erlang и Cache.

Для взаимодействия Erlang и Intersystems Cache реализованы возможности:

• Обрабатывать в Cache сообщения из Erlang, транслируя Erlang tuples (внутренний древовидный формат данных Erlang) в глобалы Cache.
• Посылать из Cache сообщения процессам Erlang, транслируя глобалы Cache в Erlang tuples.

Разработанное MCA состоит из трёх основных компонент:

• Message Dispatcher(MD) — управляет обменом сообщениями в конкурентных условиях между различными Erlang-node(EN) и Cache-процессами, обеспечивает кэширование сообщений по определенным правилам. Запускается в соответствующем EN.
• C-node — обеспечивает подгрузку С/C++ библиотек и обмен сообщениями между ними, взаимодействие системы с shared-memory, EN, CallIn/CallOut (функциональностью, реализованной в Cache на языке С) и т.д. На данный момент к С-node, для веб-приложений, c использованием Cache, нами подключены библиотеки для поддержки XSLT преобразования, обработки регулярных выражений.
• Porte – шлюз обмена сообщениями (Messaging Gateway) c MD для Cache. Запускается как отдельный background job, который будем называть Porte-job(PJ).

Как это работает?