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

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

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

Bombermine Online — результат последних двух недель тестирования и подготовки движка для большого кол-ва игроков онлайн.

Движок написан на Java + Jetty (бекэнд). Фронтэнд — HAProxy + Nginx + Node.js. Клиентсайд — GWT, который транслируется в HTML5/canvas + javascript + websockets. Хостится всё в облаке.

На данный момент рекорд — 50 игроков онлайн. Настроен весь необходимый софт для мониторинга нагрузки. После хабраэффекта обещаем выложить отчёт. Ждём гостей.

В прошлой статье я начал рассказывать о своём опыте разработки экспериментального WEB-проекта «Что делать?» на Node.JS. Первая часть была обзорной, в ней я постарался раскрыть плюсы и минусы технологии, а также предупредить о проблемах, с которыми, возможно, придётся столкнуться в ходе разработки. В этой статье я подробнее остановлюсь на технических деталях.

Несколько слов о «хабраэффекте»

Здравствуйте программисты начинающие, законченные, а также все сочувствующие. Как известно, ничто не познается так хорошо, как на собственном опыте. Главное, чтобы опыт был полезный. И в продолжении этой простой мысли я хочу предложить заняться несколькими полезными делами сразу:

• Побеседовать на тему «ООП с человеческим лицом».
• Разобраться с прототипами в javascript, коротко и сердито!
• Вспомнить, что «замыкание» это не только ценный мех… удар током.
• Написать на javascript класс Timer — этакий планировщик событий для запуска анимаций, событий, любых функций.
• Весело провести время!

Предупреждение! Если вы не ждете от статьи ничего веселого… то ошибаетесь. Людям с пониженным чувством юмора читать… еще более рекомендуется! Ну-с, приступим…

Методы создания классов на JavaScript уже не раз обсуждались по всему рунету и на хабре в том числе, я решил найти немного иной подход к созданию классов, приближенный к реальным классам. Одно важное отличие от других реализаций описанных во многих статьях, это возможность создавать аксессоры (setter's/getter's). Которые будут работать не только в современных браузерах, но и в долгоживущем IE ниже 9-ой версии. Об этом читайте ниже.

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

Hello World,

Этот топик о том, каким образом можно предварительно зарефакторить код так, чтобы улучшить его минимизацию. Недавно я перед релизом минимизировал библиотеку Helios Kernel (о которой написал позавчера). Исходник библиотеки весит 28112 байт, в нём щедрые комментарии, и поэтому он с пол пинка ужимается YUI компрессором до 7083 байт. Не то что бы мне показалось, что 7 килобайт — слишком жирно. Но просто, посмотрев своими глазами на минимизированный код, я смог увидеть кучу мест, где можно было бы сэкономить ещё:



Посмотрим, что можно сделать с кодом, чтобы превратить 7083 байт в 4009 3937.

Многие слышали о рекомендациях WAI-WCAG (Web Accessibility Initiative Web Content Accessibility Guidelines), призванных в частности помочь пользователям с ограниченными возможностями (например с дефектами или отсутствием зрения).

Но, зачастую, он игнорируется или отправляется как backlog task в долгий ящик. Это кажется лишним, не востребованным, да и в принципе, что слепой будет делать у меня на сайте?



Я все же попробую немного обосновать «полезность» двумя словами.
Во-первых, — это качество. Ваш сервис станет более удобным и простым в пользовании.
А, во-вторых, это конкурентноспособность – целевую аудиторию расхватывают быстро, поэтому поиск новых ниш – задача первоочередная, это вам скажет любой маркетолог.

В моем же случае — это требование заказчика. Согласно Section 508 если я хочу продать продукт любому федеральному органу США – я должен поддерживать этот стандарт.

Многие скажут, что вряд ли собираются что-то продавать правительству США, но в России такой стандарт тоже есть (ГОСТ Р 52872–2007) и никто не гарантирует, что завтра он вас/нас не коснется.

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

Всё же приведу ряд рекомендаций которые покрывают значительную часть элементов разметки. Их можно взять на заметку и смело использовать при следующей верстке.