Insight IT

Вакансии: команда Python разработчиков в EVAplacer

Иван Блинков — Fri, 08 Feb 2013 10:20:00 +0400

Вакансии более не актуальны

Новая международная геоинформационная социальная сеть EVAplacer набирает команду разработчиков.

Ведущий разработчик серверной части на Python

Задачи

Разработка серверной части проекта на Python
Проектирование архитектуры системы и схемы базы данных
Организация взаимодействия серверной части проекта с клиентской
Принятие технических решений

Требования

Свежий опыт веб-разработки на Python без использования Django
Суммарный опыт веб-разработки от 5 лет
Самостоятельность и заинтересованность в качестве результата своей работы
Умение делегировать часть работы коллегам

Технологии

Предстоит работать со следующими технологиями:
- Flask + Jinja2
- MongoDB + Solr + memcached
- ZeroMQ
Опыт работы именно с ними очень желателен, но не обязателен

Зарплата

В диапазоне 100-150 тысяч рублей в месяц в зависимости от опыта

Клиентский разработчик

Задачи

Разработка клиентской части проекта
Работа на стыке с серверной частью (Python), создание HTML и других шаблонов на Jinja2
Оптимизация скорости загрузки страниц
Принятие технических решений по клиентской части

Требования

Опыт разработки на JavaScript/CoffeeScript и валидной верстки на HTML5
Понимание основных принципов клиентской оптимизации
Суммарный опыт веб-разработки от 3 лет
Усидчивость, самостоятельность и заинтересованность в качестве результата своей работы

Технологии

Предстоит работать со следующими технологиями:
- Jinja2 + webassets
- CoffeeScript + SASS
- Twitter Bootstrap
- jQuery
- Leaflet
Опыт работы именно с ними очень желателен, но не обязателен

Зарплата

В диапазоне 60-100 тысяч рублей в месяц в зависимости от опыта

Специалист по тестированию

Задачи

Основные:
- Разработка автоматических тестов для серверной части проекта на Python
- Регрессионное тестирование сайта с помощью Selenium или альтернатив
Дополнительные:
- Нагрузочное тестирование с использованием JMeter или альтернатив
- Ручное визуальное тестирование, в т.ч. на кроссбраузерность

Требования

Свежий опыт тестирования интернет-проектов, желательно на Python
Суммарный опыт в тестировании от 3 лет
Внимательность, самостоятельность и заинтересованность в качестве результата работы команды

Зарплата

В диапазоне 50-100 тысяч рублей в месяц в зависимости от опыта

Условия

Премии по достижении ключевых вех проекта
Офис в центре Москвы (м. Охотный ряд, меньше 5 минут пешком)
Работа на MacBook Pro

Вакансии более не актуальны

Оптимизация интерактивных сайтов

Иван Блинков — Sat, 20 Oct 2012 12:32:00 +0400

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

Оглавление серии "Интерактивные сайты"

Общая архитектура

Организация клиентской части

Постоянное соединение между браузером и сервером

Повторное использование шаблонов

Серверная часть интерактивного сайта и потоки сообщений

Оптимизация

Серверная часть

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

Когда разрабатывается первая версия сайта, то многие части функционала проще всего реализовать в виде массовых рассылок, как-то так: произошло какое-то публично-доступное событие, допустим кто-то куда-то поставил "мне нравится", отправляем его в брокер сообщений с пометкой "доставить всем" (fanout). В итоге все подключенные на данный момент клиенты получают это уведомление и каждый сам решает что с ним делать - что-то менять на текущей странице или просто проигнорировать.

Но при большом количестве соединений и потоке событий такой подход становится роскошью. Большинство подобных ситуаций можно реализовать подпиской на тематические (topic) рассылки для каждого пользователя индивидуально, то есть когда пользователь открывает ту или иную страницу - серверная сторона должна подписать его на уведомления, связанные именно с тем контентом, который находится у него на экране. Это позволит свести к минимуму количество доставленных зря сообщений.

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

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

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

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

Постоянное соединение между браузером и сервером

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

Межвкладочное взаимодействие (cross-tab communication)

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

Вкратце для тех, кто не в курсе: в самой простой реализации постоянное соединение между браузером и сервером устанавливается для каждой вновь открытой вкладки заново. Так как каждое такое соединение ресурсоемко, то этого хотелось бы избежать. Помочь в этом может организация межвкладочного взаимодействия или, другими словами, общения между вкладками/окнами браузера: одна вкладка избирается главной и устанавливает соединение с сервером, когда она получает новое сообщение - она переправляет его конкретной открытой вкладке или же всем сразу; те же, в свою очередь, когда хотят отправить сообщение на сервер, отправляют его сначала главной вкладке, а та уже пересылает на сервер. В итоге все работает как и раньше, но соединений не больше одного на браузер.

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

Flash Local Shared Cookies - даже не рассматривал как вариант, так как требуется Adobe Flash, плюс, кажется, постоянно всплывает окно вроде этого.
postMessage - отправка сообщения указанному окну по его идентификатору. Поддержка браузерами хорошая, но большинство примеров показывают общение с iframe, а сопутствующего API для получения списка всех открытых окон/вкладок я не нашел, может быть плохо искал.
Web Workers - в браузере создается не зависящий от вкладок поток, с которым можно общаться из вкладок. Поддержка браузерами хромает, а там где её нет - polyfill'ов пока не придумали.
Web Storage - локальное хранилище пар ключ-значение с ограничением в 5-10Мб на домен. Хорошая поддержка браузерами, а там где её нет - есть polyfill'ы. Еще бывает Web SQL, но для данной задачи это уже перебор.

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

Если есть желание и время можно работать напрямую с API хранилища, но все же самостоятельно разбираться с особенностями браузеров - занятие не благодарное, так что могу посоветовать взглянуть на имеющиеся opensource библиотеки-обертки. Из тех, что я пробовал, мне больше всего нравится jStorage из-за своей "зеленой" таблицы поддержки браузерами и готовому publish/subscribe API.

Итак, вкратце пройдемся по ориентировочному алгоритму реализации межвкладочного взаимодействия:

Каждая вкладка при своем открытии придумывает себе уникальный идентификатор (проще всего на основе Math.random), будем называть его tab_id.
В хранилище будут храниться список всех активных tab_id, допустим, tabs и tab_id главной вкладки, допустим, master. Каждая новая вкладка смотрит есть ли другие открытые вкладки. Если есть - просто дописывает себя в tabs, если нет - то еще и объявляет себя главной и открывает соединение с браузером.
Далее она подписывается на сообщения отправленные лично ей (по её tab_id) и на различные типы сообщений, которые могут быть интересны всем вкладкам.
В обработчике события window.onbeforeunload (происходит сразу же перед закрытием вкладки) каждая вкладка убирает себя из tabs и если она была главной, то и из master тоже. Альтернативный вариант: master сразу может выбирать себе "преемника". Так как это событие срабатывает не всегда (когда компьютер жестко вырубился питанием, фатальный сбой в браузере, плюс оно не поддерживается неоправданно популярной в рунете Оперой и мобильным Safari), то придется создать альтернативный механизм проверки активности master и очистки tabs.
Так как какого-либо API для проверки открыта ли вкладка по её tab_id по очевидным причинам нет, нужно придумать свою схему. Самый простой рабочий вариант, пришедший мне в голову:
- Главная вкладка пишет каждые несколько сотен миллисекунд в хранилище текущую дату/время, теоретически так как все происходит на одном компьютере, то текущее время во всех вкладках должно быть одно и то же;
- Не-главные вкладки каждые 1-3 секунд читают значение из того же места в хранилище и если оно отстает от текущего на, допустим, больше чем секунду, то главную вкладку, вероятно, закрыли и надо её "свергнуть" - удалить из tabs и master и назначить, например, первую или последнюю запись из списка tabs новой главной вкладкой;
- Если выбранная новая вкладка тоже оказалась уже закрыта, не беда - во всех случаях, кроме совсем неадекватных, этот не хитрый механизм переберет все tabs и найдет-таки нормальную открытую;
- Каждая вкладка подписывается на изменения значения master, чтобы если новое значение совпадет с её tab_id открыть соединение с сервером.
Отправка сообщений происходит по простому publish/subscribe, где master подписывается и ретранслирует в соединение с сервером, а отправляют все остальные вкладки. Если вкладка отправляет запрос, ответ на который хочет получить только она сама (чаще всего переход на другую страницу сайта или отправка формы), то она указывает в отправляемом запросе свой "обратный адрес" в виде tab_id. Master, получив ответ на такое сообщение с указанным обратным адресом, перенаправляет его отправителю.
Также в хранилище полезно иметь переменную-флаг (также с подпиской на изменения), обозначающую открыто ли сейчас где-то постоянное соединение, чтобы вместо того, чтобы отправлять сообщения в никуда вкладки использовали какой-то альтернативный способ (AJAX или переход по ссылке / отправка формы средствами браузера). В качестве альтернативы можно реализовать очередь неотправленных сообщений, но по факту когда с соединением проблемы, то неизвестно когда они устранятся и устранятся ли вообще, так что смысла в ней чаще всего мало.

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

Минимизация размера сообщений

JSON хоть и сильно выигрывает у XML по объему сериализованных сообщений, но все же является текстовым форматом с указанием схемы (название для каждого значения) внутри самого сообщения. Почему минимизация объема передаваемых по постоянному соединению данных - дело полезное, объяснять, думаю, не стоит.

Первое, что приходит в голову, чтобы уменьшить объем сообщений - избавиться от включенной в них схемы, оставив только чистые данные. Изобретать свой формат ни к чему, есть неплохой широко распространенный кандидат в виде Google Protocol Buffers. Кстати, недавно нашел библиотеку с JavaScript реализацией Protocol Buffers с хорошими отзывами, в ближайшее время думаю сам опробую: protojs. Если кто уже работал с ней - буду рад, если поделитесь впечатлениями.

Но на практике оказалось, что эта самая схема обычно занимает максимум 10-20% от сообщения, так как большинство данных все же текстовые. Использование Protocol Buffers было бы намного более выгодным, если бы было необходимо "упаковать" много чисел или флагов, для текстовых данных выигрыш намного меньше.

Экономии в разы можно добиться используя обычные алгоритмы компрессии (или, если так привычнее, архивации) данных. JavaScrtipt "из коробки" этого делать не умеет, но есть полно библиотек на любой вкус и цвет, правда все хромают и чаще всего не кроссбраузерные. Приведу несколько, которые запомнились после вечера, проведенного за изучением данного вопроса:

LZW - есть реализации на большинстве языков программирования, но компрессия не очень сильная (раза в полтора-два в лучшем случае), плюс реализация под интересующий меня Erlang оказалась дико неэффективна по памяти, а на бинарных строках сходу не нашлась.
zlib.js - умеет zlib (deflate) и gzip, но, к сожалению, в моем браузере не могла разжать обратно то, что сжала, плюс объем кода библиотеки очень большой.
js-deflate - не обновлялась уже 4 года, отсутствует документация, но зато в целом работает. Подбирать метод компрессии для серверной стороны пришлось почти экспериментально, оказался zlib (deflate) без заголовков и контрольной суммы (в Erlang встроенная функция zlib:zip). Компрессия примерно в 3-4 раза.

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

По поводу дополнительных вычислительных ресурсов, которые будут потребляться на компрессию/декомпрессию, вопрос, конечно, спорный, в целом надо все мерять и делать выводы. Но если учесть, что почти во всех современных устройствах, даже телефонах, как минимум 1Ггц процессор, а на сервере можно кэшировать уже сжатые данные, то это не особо большая проблема. К слову объем сообщений уменьшается тоже не гарантированно, бывает что "сжатая" версия оказывается такой же или даже чуть больше, чем оригинал. В общем, использовать компрессию нужно осторожно :)

Повторное использование шаблонов

Сообщение со списком шаблонов для использование на клиентской части, вероятно, будет самым большим по объему и больше других выиграет от компрессии. Но есть возможность легко минимизировать и количество таких сообщений. Помните, я писал, что локальное хранилище в браузере можно и для других целей использовать?

Кэширование шаблонов - идеальный пример. Получив от сервера шаблоны он кладет их не только в объект-обертку, но и в локальное хранилище. На сервере помимо самого JSON'а с шаблонами генерируем хэш (md5, sha или crc - не важно) текущей версии. Клиент, когда открывает соединение, сообщает серверу есть ли у него какая-то версия и если есть, то какая, сервер отправляет новую версию в ответ только если хэши не совпали.

Аналогичным образом можно кэшировать и другую редко меняющуюся объемную информацию, например данные для автодополнения в текстовых полях (autocomplete).

Заключение

Надеюсь предложенные в этой статье приемы окажутся Вам полезны. Буду рад, если Вы поделитесь своим опытом и приемами по данной теме в комментариях, а также с удовольствием обсужу подробности.

Эта статья - шестая и заключительная в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Вакансии: PHP и Python разработчики в Киеве

Иван Блинков — Thu, 20 Sep 2012 20:16:00 +0400

Вакансии более не актуальны

Киевская команда разработчиков игр для социальных и мобильных платформ Level UP ищет опытных специалистов по веб-разработке на Python и PHP.

Senior Python Developer

Задачи:

Разработка высоконагруженных веб-приложений;
Разработка внутренних и публичных API;
Разработка архитектуры комплексных сервисов;
Конвертирование бизнес-задач в технические решения (R&D).

Требования:

Опыт разработки на Python более 3х лет;
Сильные навыки применения реляционных и нереляционных баз данных;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт работы в команде.

Плюсом будет:

Опыт разработки комплексных проектов на PHP или серверном Javascript (node.js);
Опыт разработки инструментов для верстки, автоматизации верстки, шаблонизаторов и пр.

Senior PHP Developer

Задачи:

Разработка высоконагруженных социальных веб-приложений;
Работа в небольшой дружной команде до 15 человек;
Решение нетривиальных задач и создание инструментов для внутреннего использования;

Требования:

Опыт разработки на PHP более 3х лет;
Опыт работы с MySQL и MongoDB;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт примененения функционарного и юнит тестирования.

Плюсом будет:

Опыт разработки на Python или серверном Javascript (nodejs).

Условия для обоих вакансий

Зарплата в диапазоне \$2500-4000 в месяц по результатам собеседования;
Полный рабочий день в Киевском офисе, иногородним помощь с переездом;
За успешную рекомендацию специалиста по данным вакансиям компания выплачивает бонус в размере $1000 так что сообщите своим знакомым, кому-то это может быть интересно.

Заинтересовало?

Вакансии более не актуальны

Не лишним будет, если кроме резюме Вы напишите - почему Вам нравится серверная разработка на Python или PHP и почему Вам интересна данная вакансия. Плюс упомяните, пожалуйста, что Вы узнали о данной вакансии через Insight IT.

Вакансии: команда IT-звезд

Иван Блинков — Fri, 04 May 2012 18:20:00 +0400

Вакансии более не актуальны

Благодаря сайту Insight IT, компания RDM-Soft нашла ОТЛИЧНОГО тимлида! Теперь, тимлидер ищет в свою команду единомышленников и просто IT-звезд.

О компании

История компании началась в 2003 году. С этого момента выпущено много проектов. Некоторыми из них Вы, возможно, так или иначе пользовались. Сейчас запускается еще один проект: SEO-биржа. У Вас есть прекрасная возможность оказаться у истоков будущего хита!

Кто нужен?

Mr. Backend. Он же программист. (вакансия закрыта)
Мастер-ломастер. Он же инженер по контролю качества, проще говоря тестер.
Dr. Frontend. Он же фронтендщик. (вакансия закрыта)

Mr. Backend

Требования

Отличные знания: PHP, ООП, SQL, MVC, ZendFramework (либо альтернатив), Linux.
Опыт работы по специальности: от 3 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Разработка серверной части проекта. Включает в себя :
- бухгалтерия;
- бизнес-логика;
- статистика;
- различные парсеры.

Мастер-Ломастер (SQA)

Требования

Хорошие знания: PHP, SQL, Linux.
Отличные знания принципов whitebox и blackbox тестирования.
Опыт работы по специальности: от 2 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Написание юнит-тестов, автотестов.
Тестирование:
- бекенда;
- фронтенда;
- бизнес-логики;
- производительности;
- безопасности.
В общем, тоже очень много интересной работы.

Dr. Frontend

Требования

Понимание, как сделать интерфейс удобным и приятным для пользователя
Отличные знания: HTML, CSS, JavaScript (jQuery, ExtJS или других распространенных библиотек)
Опыт проектирования и реализации пользовательского интерфейса

Задачи

Прототипирование UI сервиса
Реализация спроектированного UI
Разработка расширений для Firefox и Chrome.

Условия

Удаленная работа.
Работа в профессиональной команде.
Полный рабочий день (5 дней в неделю по 8 часов).
Карьерный и профессиональный рост.
Прислушивание к Вашему мнению.
Зарплата по результатам собеседования:
- Mr. Backend: от $1500 до $2000
- Мастер-Ломастер: от $700 до $1500
- Dr. Frontend: от $1000 до $2000

Вакансии более не актуальны

Постоянное соединение между браузером и сервером

Иван Блинков — Tue, 10 Apr 2012 00:47:00 +0400

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

Сегодня мы рассмотрим основные варианты реализации этого принципа и как он сочетается с обсуждавшимися в предыдущих статьях серии темами.

Транспорт

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

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

WebSocket: пожалуй, самый эффективный с точки зрения производительности и нагрузки на сервер транспорт. Протокол относительно новый, появился в рамках работы над HTML5. Доступен только в очень свежих браузерах, имеет несколько более-менее стандартных версий. Используется одно соединение для обоих направлений обмена сообщениями.
EventSource: появился примерно в то же время, что и WebSocket, но по задумке должен использоваться для получения односторонних уведомлений от сервера. В совокупности с простыми AJAX запросами для отправки событий из браузера может использоваться для двустороннего общения. Но так как он доступен примерно в тех же версиях браузеров, что и WebSocket, со сценариями, когда он оказывался бы более предпочтительным, я не сталкивался. Технически очень похож на следующий транспорт.
AJAX Multipart aka HTTP Streaming: после получения HTTP-запроса от клиента сервер не "отпускает" его и по мере поступления отправляет в него свои сообщения. Для отправки сообщений из браузера при необходимости создается второе соединение.
AJAX/HTTP Polling: в отличии от предыдущего транспорта, сервер закрывает HTTP-соединение после каждого отправленного в него сообщения или по прошествии определенного таймаута (обычно порядка 20-40 секунд). А браузер сразу же после получения сообщения открывает новое соединение, таким образом у сервера по-прежнему практически всегда есть соединение, куда можно отправить сообщения. Хоть по нагрузке на сервер этот вариант самый тяжелый, поддерживают его практически все браузеры.
Adobe Flash: эта платформа может эмулировать поддержку WebSocket при определенном стечении обстоятельств (удачная комбинация Flash-плеера и браузера). Немного нетривиальна в настройке из-за своих особенностей.

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

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

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

Абстракция

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

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

При выборе такой библиотеки для конкретного проекта очень большую роль играет его основная серверная платформа: обычно хочется использовать тот же язык программирования для обработки сообщений, что и для реализаций основной серверной части. Чаще всего используется основанный на epoll или аналогах HTTP-сервер, что позволяет поддерживать большое количество пользователей онлайн:

Node.js на JavaScript
На Erlang есть несколько очень эффективных HTTP-серверов:
- cowboy
- misultin
- mochiweb
- yaws
Tornado на Python
netty на Java

Так как самих библиотек этой категории существует примерно пару десятков, расскажу вкратце о наиболее заслуживающих внимания на мой взгляд:

socket.io: поддерживает практически все возможные транспорты, включая Flash. Основная серверная платформа - node.js, силами сторонних разработчиков есть реализации протокола на других платформах. Имеет спорную репутацию, проект довольно громоздкий, в некоторых ситуациях ведет себя непредсказуемо.
SockJS: очень молодой проект, поддерживает необходимый минимум транспортов, прост в эксплуатации. Относительно стабилен и предсказуем. Серверная часть доступна на node.js, Tornado и cowboy/misultin, активно работают над другими платформами.

Существуют коммерческие решения, абсолютно идентичные по принципу работы и функционалу. Аналогичная обсуждавшимся opensource решениям библиотека дополняется брокером сообщений для организации паттерна "публикация-подписка" и в совокупности с хостингом "в облаках" продается с оплатой за количество переданных сообщений (или по подписке с каким-то лимитом), естественно с нехилой наценкой. Плюсы и минусы очевидны: отсутствие необходимости обо всем этом заботиться против относительно высокой стоимости, потере контроля при сбоях или необходимости изменений, привязке к стороннему поставщику услуг и т.п. Рекламировать их не буду, при желании легко гуглятся, ровно как и оставшиеся альтернативные opensource проекты.

Вернемся к интерактивным сайтам

Надеюсь, только что закончившегося лирического отступления на 3/4 статьи Вам будет достаточно, чтобы составить общее представление о построении постоянного соединения между браузером и сервером, а желательно и определиться с каким-то решением для автоматического выбора наиболее эффективного транспорта в контексте именно Вашего проекта.

Получив примитивный интерфейс в виде "отправить сообщение / отреагировать на сообщение" необходимо определиться с тем, что же мы будем передавать в этих сообщениях и как будем на них реагировать.

С форматом сериализации сообщений все довольно просто: выбор между XML и JSON очевиден в пользу последнего, а заморачиваться с чем-то более экзотическим смысла мало (хотя давно хочу попробовать в этой роли Protocol Buffers или BSON, но никак руки не доходят).

Намного интереснее вопрос о том, что, собственно, будет в этих сообщениях содержаться. В предыдущей статье мы остановились на использовании фреймворка для организации кода JavaScript-клиента. Предлагаемая ими концепция модели обычно по-умолчанию предоставляет возможность синхронизации с сервером посредством AJAX запросов и механизм изменения этого поведения. Для использовавшегося в качестве примера Backbone.js для этого необходимо переопределить функцию Backbone.sync. При сохранении модели клиент будет отправлять объект с идентификатором модели и списком её изменений. Запрос изменений с сервера будет происходить асинхронно, то есть после отправки сообщения о том, что нужны данные для такой-то модели, посредством метода fetch он сам не получит ответа. Собственно изменения в модели произведет обработчик получения сообщений, в котором должна быть реализована соответствующая логика. Далее подписанные на события изменений в моделях объекты-представления будут соответствующим образом обновлять DOM-дерево страницы, отображая пользователю нужную информацию. Это, пожалуй, наиболее правильный способ интегрировать постоянное соединение и клиентский фреймфорк.

Основными минусами его является очень серьезный объем работы по разработке клиентской части, а также дублирование достаточно большой части логики и HTML-шаблонов между серверной и клиентской сторонами. Я бы рекомендовал использовать этот подход, только если позволяют трудовые ресурсы (читай: есть хотя бы отдельный специализирующийся на JavaScript разработчик), либо когда проект по каким-то причинам решил отказаться от реализации статичного HTML-интерфейса.

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

Эта статья - третья в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Клиентская часть интерактивного сайта

Иван Блинков — Fri, 06 Apr 2012 21:17:00 +0400

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

Итак, сегодня мы будем обсуждать создание JavaScript-клиента для интерактивного сайта. Начнем, пожалуй, с организации кода проекта с целью облегчения его сопровождения при росте кодовой базы, перейдем к переопределению ключевых обработчиков событий, затем к сохранению стандартного поведения браузера и закончим синхронизацией состояния между клиентом и сервером.

Организация кода

Сборка

Первое, чем стоит обзавестись перед разработкой сложного JavaScript-приложения, это системой его сборки. С точки зрения клиентской оптимизации весь JavaScript-код по возможности должен быть минифицирован и собран в один файл, подключенный в конце HTML, желательно асинхронно. Работать с ним в таком виде невозможно, соответственно надо иметь возможность легко собирать его из набора красиво отформатированных файлов, используемых при разработке.

На вопрос "Какую систему сборки использовать?" в большинстве случаев правильный ответ: ту же, что и для сборки серверной части. Make, rake, maven, ant, rebar... - любому из них без труда можно поручить эту задачу. Для конкатенации можно использовать хоть консольную команду >>, для минимизации есть много альтернативных библиотек, в порядке моих симпатий:

Если хочется чего-то более гибкого, могу порекомендовать воспользоваться Webassets, который я уже упоминал в статье про Jinja2. В консольном режиме прекрасно подключается к любой системе сборки и языку программирования. Описать процесс сборки JavaScript и CSS можно очень подробно и именно так, как считаете нужным, естественно на Python. Сопоставимый по возможностям проект из мира Ruby - Asset Packager, наверняка есть много других.

Читабельный код

Не знаю как Вы, а я тихо ненавижу JavaScript все ~10 лет, которые я с ним знаком. Так как он по сути является монополией на рынке браузерных приложений (Flash, Java апплеты и ActiveX за альтернативы можно даже не считать), использовать его так или иначе приходится в любом сколько-либо серьезном интернет-проекте. Даже Google Dart вряд ли всерьез приживется.

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

Если Вас тоже не раз посещали подобные мысли, то Вы вероятно как и я при первой же возможности пересядете (или уже пересели) на CoffeeScript, компилируемый в JavaScript язык программирования. Немного рекламы этого проекта:

Золотое правило CoffeeScript: "It's just Javascript" (это просто JavaScript)
Прямое преобразование кода в JavaScript
Доступны абсолютно все JavaScript-библиотеки
Никаких точек с запятой в конце каждой строки
Структурирование кода на основе отступов, как в Python
Объявление функций просто стрелочкой ->
При вызове методов даже скобки писать не обязательно

Человеческое наследование: простое class MyClass extends MyParent превращается в довольно хитрую конструкцию с использованием прототипов и замыканий:

MMyClass = (function() {
    __extends(MyClass, MyParent);
    function MyClass() {
        MyClass.__super__.constructor.apply(this,
            arguments);
    }
    MyClass.prototype.initialize = function() {};
    return MyClass;
})();

Много укороченных команд ветвления кода (if, switch, циклы и т.п.)
В целом код выходит раза в полтора-два короче и намного приятнее для глаз
Консольный компилятор с функцией наблюдения за директориями
Легко подключается как фильтр в Webassets
Подробнее с примерами на официальном сайте
В общем рекомендую :)

Логическое разделение кода

Если Вы сталкивались со сколько-либо сложным пользовательским интерфейсом "на jQuery", то скорее всего не по наслышке понимаете откуда взялось выражение "спагетти-код". В связи с событийной парадигмой разработки браузерных приложений, очень часто JavaScript-код с использованием jQuery или альтернатив превращается в так называемый "коллбек на коллбеке, коллбеком погоняет" (коллбек - транслит от английского callback - обработчик события). При отсутствии четкой структуры такой код становится очень сложно поддерживать при его увеличении в объемах. Но это не повод отказываться от jQuery - от событий никуда не деться, и эта библиотека отлично справляется с абстракций от особенностей их реализации в различных браузерах.

На мой взгляд, одним из наиболее резонных способов решения (или заблаговременного предотвращения) этой проблемы является использование в разумных пределах объектно-ориентированные возможности JavaScript (благо CoffeeScript это дело сильно упрощает). Соответственно, используемые классы можно разумно располагать в какой-то иерархии с точки зрения наследования (для обеспечения DRY, don't repeat yourself - "не повторяйся") и с точки зрения расположения в файловой системе (с разложенными по папкам файлами работать намного проще, чем с здоровенной вереницей обработчиков событий в одном файле).

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

Модель (Model) - как и в традиционном MVC представляет собой класс, объект которого содержит локальную копию каких-то данных и предоставляет механизмы для её синхронизации с внешним хранилищем. Основное отличие от серверных моделей - хранилищем выступает не СУБД, а либо локальное хранилище браузера через HTML5, либо удаленный сервис через REST или другой интерфейс. Плюс так как они находятся вне "зоны доверия", то полученные от них данные нужно обязательно валидировать, фильтровать и проверять на серверной стороне, прежде чем что-либо с ними делать.
Представление (View) или контроллер (Controller) - тут, по моим впечатлениям, образовалась путаница и за обоими названиями в нашем контексте имеют ввиду примерно одно и то же. Объект такого класса следит за изменениями и событиями в связанных с ним моделях и элементах DOM, каким-либо образом на них реагируя. Таким образом большая часть кода, которая раньше была "вереницей обработчиков событий", оказывается методами этого класса. При этом базовый класс из библиотеки берет на себя нормальное поведение this и следит за тем, чтобы обработчики автоматически добавлялись на динамические созданные элементы DOM.
Маршрутизатор (Router) - следит за состоянием адресной строки и позволяет обрабатывать изменения, понадобится для восстановления поведения браузера.
Коллекция (Collection) - отсортированный набор однотипных моделей, с которым можно работать как с единым целым.

Не стоит рассматривать эти абстракций как единственный верный способ делать клиентские приложения, но при их использовании появляется хоть какая-то логика и становится более-менее понятно где какой кусок кода должен находиться и где его потом искать. Для абстракции особенностей реализаций браузеров они по-прежнему полагаются на $ в виде jQuery или Zepto.

Мне известны три библиотеки, предоставляющие большую часть изложенных выше абстракций. Вкратце о каждой:

Backbone.js - самая широко распространенная из трех, используется во многих серьезных проектах. Основана на библиотеке Underscore.js, которая с одной стороны предоставляет массу удобных функций и шаблонизатор, но с другой стороны - не особо-то и часто они оказываются нужны.
Spine.js - библиотека по-моложе, которая очень похожа на Backbone.js, но написана на CoffeeScript и из-за отсутствия внешних зависимостей вышла компактнее. Отличия в основном в терминологии и деталях реализации.
Knockout.js - эта библиотека пропагандирует использование data-* атрибутов из HTML5 для хранения метаданных, которые как-то управляют изменениями тегов-владельцев при определенных событиях, практически забирая на себя роль представления. Концепция кажется мне мутноватой, так что лично для себя я её использование всерьез и не рассматривал никогда.

Когда в этой статье дело будет доходить до примеров кода, я буду приводить их на основе Backbone.js, так как в свое время я остановился именно на ней. Почему? В основном из-за того, что она используется в очень многих проектах и стоит за ней целая компания, а не просто один разработчик, которому однажды может надоесть поддерживать проект (как в случае с Spine.js). Но в глубине души я, конечно, надеюсь, что однажды они уберут эту жесткую зависимость от Underscore.js, а то и может быть тоже перепишут все на CoffeeScript.

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

Обработчики событий

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

Напомню, то, что раньше было просто независимым обработчиком событий становится методом представления (по терминологии Backbone.js). У каждого представления создается "оглавление" методов-обработчиков в атрибуте events. Наверное многим хотелось бы увидеть какой-то пример кода, но так как статьями с примерами примитивных приложений на Backbone.js пестрит весь Интернет, тратить на это время желания совершенно никакого, сошлюсь на самый популярный: список задач TODO, для сравнения то же самое на Spine.js. К слову, при использовании CoffeeScript использовать стандартный механизм Backbone.****.extend({ ... }) не обязательно, class MyClass extends Backbone.**** прекрасно делает то же самое.

По мне, так намного интереснее не какие именно события обрабатываются (все равно 90% уникальны для проекта), а как их распределить по разным представлениям. Обычно получается что-то в этом духе:

Пользовательское представление будет модифицировать страницу в тех местах, где оно как-то связано с текущим пользователем: форма авторизации, надпись "Привет, ****!", кнопка выхода и пр. Вероятно, оно будет использовать модель текущего пользователя или в тривиальных случаях просто самостоятельно работать с cookie сессии.
Классы модели и представления, а вероятно и коллекции, понадобятся каждой логической сущности, которая каким-либо образом отражается в пользовательском интерфейсе. Это может быть что угодно, например задача в TODO-списке, статья, комментарий - все зависит от тематики проекта.
Если навигация по сайту каким-то образом динамически видоизменяется, то представление понадобится и для нее. Например, часто подсвечивают пункты в глобальной навигации на основе изменений в текущем адресе страницы.
И, последний пункт, который собственно и относится к сегодняшней теме - одно представление будет общим для всего сайта и будет отвечать за его интерактивность. Давайте его рассмотрим подробнее.

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

События клика на ссылки: по содержимому атрибута href нужно определить, что ссылка внутренняя и вызвать "цепную реакцию" в других представлениях, чтобы в итоге пользователь увидел то, что должен.
При отправке формы есть два сценария:
- Обновляется связанная модель и синхронизируется с сервером. В таком сценарии при необходимости можно вообще скрыть кнопку отправки и "автосохранять" изменения в модели.
- Связанной модели по каким-то причинам нет и нужно просто на основе данных формы что-то сделать, например выполнить поиск по указанной в форме фразе или отправить запрос на авторизацию.
Для отмены стандартной реакции браузера на события у jQuery есть два основных механизма: event.preventDefault() и return false. В данной ситуации (да и большинстве других), целесообразнее пользоваться последним, так как если вдруг в коде обработчика окажется какая-то ошибка, то пользователь просто увидит стандартную реакцию браузера, а не окажется в ситуации "некликающихся ссылок" и "неотправляющихся форм".

Восстановление поведения браузера

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

И первое, с чего стоит начать - с адресной строки, именно там должен появиться тот адрес, который был в href ссылки и action формы. Но на самом деле проще сказать, чем сделать:

Возможность просто полностью поменять текущий адрес в адресной строке из JavaScript без инициализации открытия страницы есть только в совсем свежих браузерах посредством HTML5 History API (pushState).
В старых браузерах переходы между внутренними страницами сайта можно эмулировать через изменения якоря ссылки, который в URL идет после # и обычно используется для "перелистывания" на середину HTML-документа. Для отслеживания таких изменений используется событие onhashchange.
В еще более старых браузерах это событие эмулируют разными трюками с iframe и setInterval.

Backbone.history.start() берет на себя абстракцию изменений в адресной строке, правда поддержку pushState нужно явно включить в аргументах. Заодно восстанавливается нормальное поведение кнопок "Назад" и "Вперед" в браузере.

Для обработки и создания событий, отражающихся в адресной строке, нужно сделать подкласс Backbone.Router. C ситуациями когда их имеет смысл создать несколько, я не сталкивался. По аналогии с серверными фреймворками в атрибуте routes задается соответствие паттернов адресов к методам-обработчикам, которые будут выполниться при переходе. В них вызываются необходимые изменения в коллекциях, моделях и представлениях, чтобы привести в нужное состояние текущий документ.

Для инициации "виртуального" перехода на новую внутреннюю страницу нужно вызвать метод navigate у нашего объекта-маршрутизатора, первым аргументом передав её адрес без первого /, а вторым - настройки:

trigger - вызывать ли обработчик из маршрутизатора?
replace - добавлять ли страницу, с которой мы уходим в историю браузера, чтобы можно было на нее вернуться при нажатии кнопки "назад"?

Таким образом, во внутренних ссылках мы используем нормальные относительные URL, начинающиеся с /. По ним будут нормально ходить роботы и браузеры без JavaScript. В обработчике кликов на них мы:

проверяем правда ли она внутренняя (начинается ли она с /);
"отменяем" стандартный переход, вернув false;
вызываем router.navigate(href.substring(1), {trigger: true}).

Осталась еще несколько атрибутов поведения браузера, которые необходимо починить, чтобы визуально все выглядело "как обычно":

Клик по ссылке с зажатым Shift должен открывать её в новом окне, а с зажатым Ctrl или при клике средней кнопкой мыши - в новой вкладке. Довольно не хитро делается на основе атрибутов объекта-события, который передает обработчику jQuery (button, shiftkey, metakey), для открытия окна или вкладки - window.open.
Если пользователь сделал какое-то действие, а прореагировать на него мгновенно не получается (так как что-то грузится, вероятно) - нужно включить курсор ожидания, установив в CSS cursor: wait, и, желательно, анимированный favicon.ico. И, соответственно, вернуть все как было, когда страница примет нужный вид. Для смены favicon до сих пор пользуюсь каким-то довольно старым плагином к jQuery, который не особо шикарно, но все же работает. Его сайт, видимо, накрылся, так что продублировал: https://gist.github.com/2320740, если кто знает более адекватные альтернативы - дайте знать в комментариях, пожалуйста, руки поискать все никак не доходят.

Синхронизация состояния

По-умолчанию Backbone.js предлагает хранить все состояние клиента в моделях и синхронизировать его с серверным посредством реализации простенького REST API на сервере (подробнее), к которому запросы отправляются посредством обычного $.ajax. Чтобы инициировать процесс нужно вручную вызвать у экземпляра модели метод fetch, чтобы обновить клиентское состояние данными с сервера, или метод save, для обратного процесса.

Для многих приложений этого, в целом, достаточно. Но ограничение очевидно - нет возможности мгновенно узнать, что на сервере что-то изменилось. Чего-то близкого можно достичь вызовом fetch раз в N секунд для каждой модели, но если пользователей предполагается хоть сколько-либо много, нагрузка на серверную часть будет неоправданно велика.

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

Эта статья - вторая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Анонс серии статей: интерактивные сайты

Иван Блинков — Sun, 01 Apr 2012 17:43:00 +0400

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

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

За последний год привнесение интерактивности в интернет-проекты - пожалуй, одна из самых популярных тем, с которой ко мне обращаются за консультацией. В итоге я решил не жадничать и поделиться с общественностью своими знаниями в этой области, что в итоге должно вылиться в серию связанных статей "Интерактивные сайты". В ней я хочу отразить практически пошаговую инструкцию от А до Я для создания интерактивного интернет-приложения с нуля или основываясь на существующем статичном проекте. Соответственно, по ходу дела сделаю легко доступное оглавление по аналогии с архитектурой высоконагруженных интернет-проектов.

Ориентировочные темы статей

Основной упор будет сделан именно на общую концепцию и сведение всех компонентов воедино, как на серверной стороне, так и на клиентской. Количество изобретаемых велосипедов постараюсь свести к минимуму: где-то будут просто рекомендации по использованию публично доступных технологий, где-то - сравнительные обзоры. Специфики каких-либо определенных типов проектов постараюсь избегать.

Пожелания, предложения, советы и вопросы в комментариях к этому посту очень приветствуются :)

Добро пожаловать в Сказку! (вакансия закрыта)

Иван Блинков — Mon, 14 Mar 2011 15:32:00 +0300

Вакансия более не актуальна

Компания SKAZKA, российский разработчик и издатель онлайн-игр, ищет опытного веб-разработчика на Python. Предлагается работа в команде MMO-проекта "Королевство", а также участие в разработке ряда новых игр (одна в активной разработке, а другая проектируется).

О проекте

Проект "Королевство" состоит из 2-х частей:

непосредственно игра (сервер – C+Python, клиент – Flash)
социальная сеть – веб-часть проекта, содержащая все полагающиеся атрибуты соцсетей в реалиях игры (nginx, Python, Twisted, XSLT, memcached, PostgreSQL)

Обязанности

Полная самостоятельная поддержка и разработка всех проектов компании со стороны веба
Оптимизация существующего кода для увеличения производительности и уменьшения нагрузок
Разработка модулей для существующего проекта
Доработка функционала, фикс багов
Интергация проектов с российскими и зарубежными соцсетями

Требования к кандидату

Уверенное знание Python
Уверенное знание JavaScript
Знание XSLT
Умение разбираться в чужом коде
Умение объективно оценивать собственные трудозатраты по той или иной задаче и укладываться в поставленные сроки
Английский язык на уровне чтения технической документации
Коммуникабельность, дисциплинированность и ответственность
Приветствуется опыт работы над сложными/высоконагруженными web-проектами

Условия работы

Полный рабочий день в офисе в Москве (пять минут пешком от метро Третьяковская)
Работа над интересными, перспективными проектами
Отличная команда единомышленников, каждый из которых является профессионалом в своей области
Начало рабочего дня: с 10.00 до 12.00 (по желанию)
Зарплата: 50-100 тыс. руб. в месяц

Куда писать?

Вакансия более не актуальна

P.S.: Если Вы не дотягиваете до требований, но в Сказку хочется - все равно пишите, еще есть вакансия джуниора.

Comet

Иван Блинков — Wed, 26 Mar 2008 21:13:00 +0300

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

Comet представляет собой архитектуру веб-приложений, основной особенностью которой является тот факт, что отправка данных от сервера к клиенту (в роли которого обычно выступает браузер) не требует какого-либо запроса данных со стороны клиента. Это позволяет пользователям приложения более оперативно реагировать на возникающие на сервере события и быть в курсе процесса работы приложения без необходимости непрерывно опрашивать сервер с помощью веб-клиента. Реализация этой технологии, как не сложно догадаться, основывается на JavaScript. Основной идеей является поддержание долговременных HTTP-соединений с каждым клиентом приложения и отправка новых данных клиентам с их помощью как только произошло их обновление или возникновение на сервере. Этот принцип послужил основой для альтернативных названий этой технологии: Server-push, Reverse AJAX. В случае классического AJAX (о котором тоже стоило бы сначала написать статейку, потом может быть соберусь) клиент асинхронно отправляет серверу запрос на получение какой-либо конкретной информации. В Comet же клиент с сервером как бы меняются ролями: инициатором передачи информации является сервер, а не клиент. Что же это меняет? Самым наглядным примером послужит реализация постоянного обновления какой-либо информации в реальном времени:

Классическая модель отправки запросов. Для решения задачи понадобится постоянно обновлять всю страницу целиком, вручную пользователем или альтернативными способами автоматически. Совсем не вариант, будет генерироваться огромное количество запросов к серверу, каждый из которых будет очень существеннен по объему. Большое количество одновременно работающих пользователей такое приложение явно не выдержит, да и доступность данных в реальном времени не обеспечит.
AJAX. По сравнению с предыдущим вариантом AJAX предоставляет массу преимуществ: размер передаваемых данных существенно уменьшается, особенно если использовать в качестве формата данных не XML, а JSON. Но тем не менее необходимость регулярно отправлять запросы серверу для получения обновленной информации останется. С ростом количества пользователей будет расти и количество запросов, открытие и закрытие которых будет неуклонно генерировать нагрузку на сервер. Для снижения нагрузки можно попытаться увеличивать интервал между запросами, но это лишь временная мера, обладающая существенным недостатком - увеличение этого промежутка времени повлечет за собой рост задержек между обновлением информации на сервере и обновлением клиентской части приложения.
Comet. С каждым клиентом поддерживается постоянное HTTP-соединение, как только данные на сервере обновились - сервер сразу же отправляет по уже открытому соединению уведомление о необходимости провести изменения в клиентской части, это позволяет существенно сократить нагрузку на сервер и практически избавиться от задержек между обновлением данных на сервере и клиенте.

Для написания серверной части приложения может использоваться практически любой язык программирования, наиболее распространенным решением, пожалуй, является Java Servlet, запущенный в каком-либо контейнере - Apache TomCat, Jetty или Sun GlassFish. Для реализации этого подхода к организации общения клиента с сервером написано достаточно большое количество framework'ов и библиотек, наиболее полный список, я думаю, можно найти в английской википедии.

Но и для Comet-приложений рано или поздно возникает вопрос масштабируемости, так как традиционные HTTP-сервера создают новый поток (thread) для обслуживания очередных нескольких очередных новых соединений. Каждый поток в состоянии обрабатывать только небольшое количество HTTP-соединений, а так как в случае с Comet соединения находятся в открытом состоянии неопределенно долго, для каждых нескольких новых пользователей веб-приложения приходится создавать новый поток. Количество одновременно существующих потоков не безгранично, что в один прекрасный момент приводит к существенному росту издержек, связанных с созданием новых и управлением существующими потоками, а также все чаще и чаще возникающим отказам потокам в предоставлении серверу необходимых вычислительных. В таких ситуациях некоторые пользователи встречаются с неприемлимыми задержками в работе приложения или непредвиденными сообщениями об ошибках. Наиболее простым и в то же время эффективным решением подобной проблемы является горизонтальное масштабирование Comet-серверов с балансировкой нагрузки на программном или аппаратном уровне.

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

Я же надеюсь написать статью более практической на направленности по этой теме лишь в обозримом будущем, не пропустить этот момент Вам поможет абонемент.

7 способов защитить свой интернет-ресурс от нежелательной информации

Иван Блинков — Thu, 03 Jan 2008 20:41:00 +0300

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

1. Классический вариант - графическая реализация

Самым популярным вариантом реализации является "графическая" captcha (позволю себе "обращаться" к этому слову в женском роде, просто из-за того, что по-моему оно так лучше звучит, не смотря на то, что по логике все же стоило использовать "он", так как при дословном переводе получилось бы слово "тест" с кучкой прилагательных и определений). Она представляет собой изображение, содержащее чаще всего какой-либо сильно искаженный текст или набор цифр, и перед посетителем ставится задача воспроизведения в текстовом поле, находящемся неподалеку, того что он/она видит на изображении. Большинству людей не составит труда прочесть и набрать на клавиатуре даже искаженный до неузнаваемости текст, а вот для программы данная задача является как минимум нетривиальной.

Существует некоторое количество алгоритмов (называются OCR), позволяющих программе пытаться понять что же за текст расположен на изображении. Эти алгоритмы разрабатывались для вполне мирных целей - для оцифровки книг и любых других напечатанных на бумаге документов. Но все же эти алгоритмы предназначены для распознавания аккуратно написанного текста черным шрифтом на белом фоне и являются плохо приспособленными для распознавания captch'и. Но все же существует довольно большое количество модификаций этих алгоритмов, приспособленных для чтения даже искаженного текста.

Казалось бы это существование таких алгоритмов делает бессмысленным использованием такого рода "защиты", но на практике это далеко не так: большинство из них пригодны только для распознавания только узкого набора реализаций графических captch, особенно это актуально для популярных готовых решений реализации этого типа защиты находящимся в свободном доступе в сети Интернет, а также сервисов, предоставляющих услуги по генерации такого рода изображений. Что делает довольно актуальным написание собственной реализации графической captch'и для появления уверенности в отсутствии готовой модификации OCR алгоритма, для преодоления используемой преграды. Об этом и пойдет речь в записи про собственноручную реализацию технологии CAPTCHA.

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

2. Сommon sense

Эта категория модификаций основывается на вопросах построенных на так называемом common sense, то есть на каких-то общеизвестных вещах, очевидных для любого человека, но не поддающимся четкому осознаванию программой с помощью какого-либо алгоритма. К сожалению, этот факт вместе с тем порождает и основной недостаток этой категории проверок- такой тест невозможно автоматически сгенерировать, что делает реализацию существенно более трудоемкой и неэффективной, что собственно и обуславливает редкость их применения на практике.

3. Математический тест

Помимо просто перенабирания некоторого набора цифр с изображения, авторы captch'и могут попросить своего посетителя выполнить какую-либо несложную операцию (например: 2 x 2 = ???). Но такого рода тесты также далеки от идеала, так как в подавляющем большинстве алгоритм их решения прост для безобразия - вполне достаточно бывает базового OCR и реализации калькулятора внутри crawler'a, чтобы он смог преодолеть такого рода барьер.

4. Выбор изображения

Хочется также упомянуть один из достаточно оригинальных вариантов реализации, являющийся по сути вариацией на тему common sense captch'и, который меня как минимум удивил, когда я его впервые увидел на сайте одного из мобильных операторов рядом с формой для online отправки SMS. Суть его заключалось в том, что предлагался набор небольших фотографий, из которых предлагалось выбрать 2-4 изображения обладающих каким-либо свойством, например являющимися живыми объектами. Помимо позитивненького оформления и симпатичных фотографий, чисто технически такой подход является достаточно эффективным и легко реализуемым, единственное предъявляемое к такой реализации требование - достаточно обширная база данных изображений.

5. Выход за рамки стандартов

Большинство вещей, предназначенных для массового использования, принято делать по принципу "чем проще тем лучше". Обусловлено это тем, что количество пользователей обратно пропорционально уровню требований, к ним предъявляемых. Формы на интернет-страницах, как ни странно, исключением из этого принципа не являются, что является причиной их построения с использованием только базовых языков разметки - HTML, XHTML или в крайнем случае XML. Именно такую форму и ожидает увидеть spider, попадая на страницу. Но если поступиться этим принципом - легко поставить программу в тупиковое положение, задействовав какую-либо непривычную для нее технологию. В качестве примера в голову приходит Flash-ролик вместо изображения в графическом варианте реализации.

Этот способ является очень эффективным, но обладает существенными недостатками, такими как, например, необходимость использования современных браузеров с определенными plug-in'ами.

6. Скрытие разметки

В качестве продолжения предыдущей мысли: JavaScript предоставляет далеко не один способ скрыть внутри себя код разметки, что позволяет сделать вид, что формы как бы не существует (в основном базирующиеся на обратимом шифровании), заставляя программу подумать "да тут и заполнять-то нечего" и пройти мимо на какой-нибудь другой сайт. Все бы хорошо, только посетители сайта с отключенным JavaScript'ом формы тоже не увидят...

7. Звуковое воплощение

Как не трудно было заметить, что все варианты, которые я упомянул до этого момента, так или иначе базировались на визуальном восприятии информации. И вполне обосновано - для большинства людей зрение играет роль основного чувства, но существуют и интернет-ресурсы, для которых важен абсолютно каждый посетитель, в том числе и люди с ограниченными способности, для которых стандартные проверки являются непреодолимыми. Для такой категории людей были сделаны альтернативные варианты, основывающиеся на таком чувстве, как слух. Суть же от этого изменилась: посетителя просят набрать с клавиатуры нечто услышанное при воспроизведении аудио-записи, либо ответить на какой-либо вопрос, основывающийся на уже упомянутом принципе common sense и заданный тоже с помощью в аудио-файле.

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