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

В этой статье приведу ряд приемов, которые, на мой взгляд, помогут в разработке любого крупного проекта. Этот материал для вас, если вы уже написали свой todo лист на vue.js+vuex, но еще не зарылись в крупное велосипедостроение.

Недавно написал одно приложение для собственного удобства, и сначала не хотел о нем рассказывать. Потом подумал, что оно может пригодиться кому-то еще. По сути это сервис для планирования автомобильных маршрутов, собранный из готовых компонентов google maps api. Это — клон Google Maps Engine, однако без досадных ограничений последнего. Бесплатный, опенсурсный, чистый фронтэнд без сервера, код выложен на github.

Демо

Я работаю над визуализацией парапланерных соревнований — пишу плеер просмотра гонки для Airtribune.com. В процессе работы мне попадаются интересные и нестандартные задачи. Одна из них — задача быстрой отрисовки маркеров и треков на карте google maps.

Масштабы такие: есть ~200 трекеров в довольно ограниченной области (50x50км), каждый передает данные о своем положении раз в 10 секунд. Нужно их все отрисовать на карте и плавно перемещать при изменении координат. За каждым маркером должен отрисовываться трек. Картинка примерно следующая:



Скоро обнаружилось, что встроенные объекты — google.maps.Marker и google.maps.Polyline — для данной задачи работают слишком медленно. Была куча идей по оптимизации, и в результате получилось решение на canvas-е, которое работает со скоростью 40fps даже на тысяче маркеров. Впрочем, fps вы можете померить сами — я собрал тестовое приложение для сравнения 4-х движков, в котором на лету можно подключать разные фишки и смотреть на скорость работы.

Я тут пишу одну эпическую мегахрень, которую хочу пропиарить на хабре. Эта штука типа распределенной социальной сети. Там есть ядра с api, которые общаются по некоторому стандарту и фронтенд. Особенностью сети является то, фронтенд живет «отдельно» от ядра, то есть сеть не имеет своего домена — берем html, ставим ссылку на любое ядро и получаем сеть, которая живет поверх сайта. Внешне это похоже на социальные плагины фейсбука — комментарии и лайки оттуда можно поставить на любую свою страницу — только вместо тегов fb-like используются мощные биндинги knockout.js + пользователь не ограничивается огрызками из комментариев и лайков — на сайт можно импортировать практически любой блок из сети и сделать почти любое действие. Фронтенд написан на тех же технологиях, которые юзер может использовать и дописывать на своей странице.

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

Расскажу про систему, которая встраивается на html-страницу через биндинги нокаута. Код живет в подключаемых виджетах, которые состоят из html-шаблонов с knockout-обвязкой. Виджеты могут быть вложены друг в друга. Все это использует require.js и живет в amd форме. Зависимости от внешней страницы сведены к минимуму, все библиотеки (jquery, knockout и плагины) используются только свои в локальном пространстве с namespace-ами. Для сборки кода используется r.js. Еще как крутые перцы напишем на базе бутстраповского диалога полноценный оконный менеджер — с нокаутом это как два пальца об асфальт…

Есть такая библиотека knockout.js. Она отличается от прочих хорошим туториалом для начинающих и кучей понятных рабочих примеров. Еще там стройная MVVM модель, декларативные связи и так далее.

Короче, если вы, как и я, поиграли с этой библиотекой, понаписали красивых формочек, и вам это понравилось, то все это дело захотелось применить на реальном проекте. И тут проблема — в реальном проекте формочек больше чем одна. А раз такие инструменты, то хочется single web page application и никак иначе. А делать один контроллер и все темплейты заверстывать на одну страницу тоже тупо и тормозно.

Под катом приведу основу своего сложного приложения. Само оно совсем не сложное, но модульное и допускает расширения, а темплейты и модели подгружаются динамически. Идея была подсмотрена в этой презентации — http://www.knockmeout.net/2012/08/thatconference-2012-session.html, код презентации выложен на github — https://github.com/rniemeyer/SamplePresentation — на базе этого кода будем писать свой.

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

Грубо говоря, проблема в том, что в браузере работает javascript, а на сервере его нет. Нужно либо писать интерпретатор js на одном из серверных языков (jParser и jTokenizer), либо ставить на сервер браузер, посылать в него запросы и вытаскивать итоговое dom-дерево.

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

Сейчас появились более продвинутые средства — xulrunner (crowbar) и watir. Первый — безголовый firefox. У crowbar есть даже ff-плагин для визуального выделения нужных данных, который генерит специальный парсер-js-код, однако там не поддерживаются cookies, а допиливать неохота. Watir позиционируется разработчиками как средство отладки, но мы будем его использовать по прямому назначению и в качестве примера вытащим какие-нибудь данные с сайта travelocity.com.

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

В сети есть плагины для синхронизации phpbb и wordpress (WP-United) и универсальные руководства (1,2), но последние, как правило, начинаются словами «скопипастить эти… дцать функций из functions.php» и «вставить в эти 3 таблицы вот такие данные».

Другой метод интеграции — начать использовать таблицы пользователей и методы к ним из phpbb на остальном сайте, но это обычно требует значительных модификаций системы.

Расскажу про свой способ, который тормознее обычных, но зато требует минимальных изменений файлов сайта и форума (по 10 строчек на каждом для подключения файла с классом-синхронизатором в 5кб).

Неделю назад мои знания action script ограничивались тем, как добавить событие onclick на баннер перед загрузкой в баннерную сеть. В качестве загрузчика файлов я использовал swfupload, и очень не хотел влезать внутрь swf-ника и разбираться в коде. Мне не нравится flash, я ни разу не дизайнер и теряюсь, когда вижу все эти слои, кадры, инструменты для рисования звездочек и motion guides.

Потом я наткнулся на эту эту потрясающе-красивую штуку, и узнал, что есть flex. И что flex — это круто, потому что даже такой супер-начинающий как я, с нуля за несколько дней смог написать загрузчик фотографий с предпросмотром, ресайзом на клиенте и upload-баром, примерно такой, какой используется на сайте vkontakte.ru.

Есть три причины, из-за которых я решил использовать flash для загрузки фотографий. Это FileReference, FileReferenceList и flash.display.Bitmap. В 10-й версии флеш плеера у FileReference появилась функция load(), с помощью которой можно просматривать выбранные фотографии в ролике локально без загрузки на сервер. FileReferenceList позволяет в файловом диалоге с помощью shift-а выбрать сразу несколько фотографий. Bitmap делает ресайз картинок перед отправкой на сервер. Все это нельзя сделать на чистом javascript-е.

Итак, пишем загрузчик фотографий как vkontakte на flex (пошаговое пособие для совсем начинающих).

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

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