Сегодня мы поговорим о разработке сервиса создания скриншотов сайтов. Так получилось, что я занимался этим для одного интранетовского проекта и, получив благословение и разрешение добродушного заказчика из лесистой Финляндии c аватаркой чрезвычайной усатости, публикую тут подробное описание процесса и технологий, возможно, это кого-то заинтересует. Использовать мы будем следущий инструментарий: NodeJS, SocketIO, Xvnc, xwd, Chromium и еще кучу всего другого. Вкратце постановка задачи выглядела подобным образом: нужен API, возвращающий скриншот сайта в PNG, проект сам по себе - внутренний сервис компании юзабилити тестирования. Только нужно было управиться без всех этих хитрожопых и кривых command-line конверсий по типу khtml2png, а грабить настоящий живой вывод современных браузеров. Я, почесав репу, решил выделить три уровня разработки и автоматизации: serverside, middleware и конечно же clientside, которые я вам сейчас и опишу, дорогие мои.

Начнем с самого глубокого серверсайда. В распоряжении имелся старенький слабенький сервачок с ненавистным CentOS-ом, ну делать было нечего. Прежде всего, нужно понять, что без иксов нам абсолютно никак не обойтись. Они нужны для виртуальных дисплеев, куда мы будем высаживать наши браузеры. Варианта два: мы можем использовать xorg-x11-server-Xvfb либо же vncserver, который представляет собой perl обертку вокруг Xvnc. Я советую остановиться на втором варианте преимущественно по причине меньшего количества dependencies, возможности удобного удаленного подключения для настройки того же браузера и отсутствия проблем с битностью цвета. К тому же, на старике-центосе Xvfb почему-то постоянно отваливался, а ядро было собрано без поддержки framebuffer, поэтому устройство /dev/fb[0-9] отсутствовало, сводя на нет все преимущества утилит fbdump и fbgrab. После установки vncserver, протестируем его работоспособность, вызвав vncserver :11 -geometry 1920х1200 -depth 24. У вас спросят пароль при первом запуске и, если все прошло без ошибок, то вы счастливчик. Иксы на виртуальном дисплее localhost:11 у вас уже есть. Можете рассказать это своему environment (ненавижу слово "окружение") c помощью export DISPLAY=:11. А еще вы можете запустить xterm и сконектиться через VNC клиент (для виндовса есть отличный бесплатный от RealVNC) и в очередной раз убедиться, что все работает. Теперь нам нужно как-то воровать экран и сохранять его в изображение. В интернетах советуют использовать утилиту import, входящую в набор ImageMagic, но это как перевозить две горошины на грузовом самолете. Вместо нее мы будем использовать xwd из xorg-x11-apps для снятия слепка с виртуального дисплея, и xwdtopnm плюс pnmtopng из netpbm-progs для конвертации его в PNG формат. Тут все еще проще, для получения скриншота вам нужно просто выполнить xwd -root -display localhost:11 | xwdtopnm 2>/dev/null | pnmtopng > screenshot.png. Большая часть серверной магии окончена, осталось сделать небольшой скрипт автоматизации и защиты от дураков. Оговорюсь сразу, что процесс генерации сриншотов будет последователен на основе очереди задач, никакого распараллеливания. О причинах этого мы поговорим чуточку позже. После установки Хромиума, что для ебучего CentOS-а, который сыпется пылью из всех щелей, тоже нихуя не тривиальная задача, мы сделаем небольшой скрипт для облегчения рутины создания скриншотов. Хромиум запускается в инкогнито режиме в фоне, мы ждем открытия страницы 6 секунд (для многих страниц этого времени не хватает, но для тестов сойдет), снимаем скришот и жестко тушим все открытые процессы. Если вам не нужны элементы оформления браузера аля адресная строка или панель табов, то можете добавить ключ --kiosk при запуске хрома. Все пропадет, останется лишь окно с отрендериной страницей, но это выглядит как-то менее эстетично ;). Таким образом, мы собрали все необходимое для создания скриншотов, осталось написать обертку и обертку над оберткой. Пару слов про безопасность: создайте отдельного пользователя из-под которого будете запускать браузер и иксы, отключите все плагины на внутренней странице about:plugins. Клиентская и серверная валидация ссылок в добавок к жесткому ограничению времени исполнения (у нас это 6 секунд) защищает от умников, которые мечтают о stack overflow и arbitrary code execution или пытаются банально загрузить html файл размером с пару гигабайт. От запуска нескольких инстансов браузера для многопоточной генерации пришлось отказаться по этой же самой причине. И да, все настройки хромиума хранятся в JSON формате в файле ~/.config/chromium/Default/Preferences, изменить вам придется параметры размеров окна, потому что даже с ключом --start-maximized у браузера развернуть окно на весь виртуальный экран почему-то не получается.

Часть вторая - middleware или, другими словами, прослойка между сервером-клиентом и своеобразный примитивный менеджер задач. Писать мы ее будем на NodeJS и SocketIO, оба решения мне полюбились event-based моделью. В стандартный набор ноде входит функция spawn объекта child_process для асинхронного запуска дочерних процессов и получения их stdout потоков, которая и будет работать с нашим небольшим bash скриптом. Для создания последовательной модели исполнения, нам нужен какой-то неблокирующий алгоритм task queue и именно поэтому нам не подходит метод Array.forEach. Я, признаться, не стал ебать себе мозг академическими решениями и просто сделал рекурсивную функцию, которая банально вызывала Array.push при добавлении новой задачи и Array.shift при завершении выполнения и переходе на новый цикл итерации с проверкой блокирующей переменной. Решение не идеальное и при больших нагрузках могут возникать проблемы с выпадающими из стека заданиями, но никто больших нагрузок и не ждет - идеальная отговорка для лентяя, который поленился сделать асинхронную модель обработки с помощью setInterval. Чтобы не быть голословным - вот вам код прослойки. Судя по коллекции сохраненных скриншотов, некоторые куллхакеры, думающие, что, выполнив в консоле isURL = function() {return true;}, они обойдут все проверки и удалят мне /etc/passwd, соснули хуйцов и посмотрели веселые картинки на сайте gay.ru. Кекеке!

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

Куда ж мы без живых примеров? Никто в наше время тексту не верит. Пришлось перенести все на свой старенький сервачок в далекой Фрицландии, сделать симпатичную обертку на скорую руку и теперь вы можете проверить работу теории на практике в разрастающейся секретной экспериментальной лаборатории интернетовских опытов имени Коли Цискаридзе. Ссылка на ScreenShooter, который старательной описывался в этой статье, работает до последнего посетителя. В качестве бонуса всем, кто дочитал достаточно сложную для формата блога статью, я дарю самодельный уникальный инструмент по раскрутке вашего сайта, известный подписчикам моего твиттера и гуглоплюса. А если серьезно, спасибо всем, кто активно плюсует гуглокнопкой мои посты. Это достаточно приятно и позволяет понять направление дальнейшего развития тематик. Продолжайте в том же духе, нажимайте +1, у меня еще много разнообразных интересностей в черновиках.

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

Давайте по порядку. Сейчас в моде real-time коммуникации, в техническом смысле этого слова. Контакт, лицокнига, гуглоплюсы - все перечисленные социальные сети имею свой WebIM, позволяющий в реальном времени общаться со своими друзьями и подругами. Правда, концепция там немного другая, чаты этих социалок, как правило, представляют собой JavaScript обертку вокруг XMPP протокола, но смысл понятен. Еще, справедливости ради, стоит заметить, что WebSockets и Server-Sent Events в настоящее время выделены из спецификации HTML5 в отдельные доки, но, опять таки, я утверждаю и буду утверждать, что HTML5 - не технология, а маркетинговый бренд и писькомерялка современных браузеров, поэтому отождествление понятий тут допустимо. Передо мной была поставлена задача создать приложение, позволяющее в реальном времени обмениваться информацией между сервером и клиентом с минимальными задержками. Благо, приложение это исключительно интранетовское и платформа использование - Google Chrome, а значит технически я не был ограничен. Вариантов было несколько: long-polling HTTP запросы, HTTP Streaming или fast-polling, все это называется Comet моделью. И у каждой реализации есть свой недостаток. В спецификации HTTP/1.1 четко указано, что браузер не должен создавать одновременно более 2х параллельных соединений к серверу. Конечно, современные браузеры могут поддерживать десяток connections и подобное нарушение стандарта не является фатальным, но в каждом из вариантов решения есть свои недостатки. Fast-polling, который представляет собой многократное повторение запроса (с завершением сессии) создает приличную нагрузку на сервер, а "висящие" запросы - костыли, которые приводят либо к memory-leak (в последнем фаерфоксе сделать garbage collector для буфера запроса не удосужились, в хроме и сафари память чистится, но только для запросов, возвращающих "Transfer-Encoding: chunked"), к тому же, контролировать Comet сессию сложнее, она может отваливаться без какой-либо видимой причины, да и изначально протокол создавался не для этого. Есть еще BOSH, который используется в вышеупомянутом XMPP, но он заточен больше под создание чатов и готовых решений для этой технологии очень мало. В PaaS Google App Engine, на котором расположен этот блог, есть Channel API, что-то вроде Comet-а, я даже пытался попробовать, но возможности тоже сведены до минимума. Конечно можно еще использовать обертки вокруг flash socket или java-апплета, но не этому учила нас партия.

Вот именно таким путем, перепробовав все вышеназванные методы и оценив ресурсоемкость, я решил остановиться на server-sent events и web-sockets, которые вроде даже выведены из статуса эксперементальных в последних версиях Webkit-а. Начнем с SSE, спецификацию можно почитать тут. По сути, это тот же HTTP Streaming на стероидах. Его смысл заключается в том, что в JavaScript коде или DOM создается объект EventSource со скриптом в src атрибуте или методе-конструкторе. Этот скрипт, прежде всего, должен в контексте "висящего" соединения (хотя и не обязательно) возвращать корректный Content-Type: text/event-stream и в дальнейшем push-ить обновление клиенту в виде строки data: any_text_info \n\n. То бишь, протокол абсолютно односторонний, нас это вполне устраивает, общаться обратно мы можем и через милый сердцу XHR. Есть в нем и вкусности, к примеру, ответ event: test-remote-event \n data: success \n\n, если верить стандарту, можно обрабатывать в addEventListener('test-remote-event' ,function(data){}), правда, это пока только на бумаге. В Chrome Canary у меня работал только event onmessage. Со стороны все всегда кажется таким красивым, но тут начались проблемы, бывает, что поток просто висит. Никакой onerror или onclose не вызывался, сервер продолжает исправно посылать данные, что проверяется curl-ом в консоли, но браузеру пофиг, хотя рестарт страницы помогает. Пробовал в Chrome Stable - та же  заморочка. ЧЯДНТ? Вторая и более серьезная проблема - отсутствие поддержки CORS, Access-Control-Allow-Origin: * отсылается, но браузерам на него с большой колокольни, они возвращают DOM Exception 18. Очередная брешь в стандарте, как так - XHR работает, а EventSource нет. Конечно, это все придирки, можно было бы завернуть трафик через proxy_pass в nginx, но в любом случае, осадок остался. К тому же, нужно уже было думать о проверке наличия \n\n в контенте, иначе была бы вероятность получить побитый ответ. Таким вот путем я и пришел к WebSockets. Рассказывать что-либо про клиентскую часть не имеет смысла, есть спецификация, все это делается одной строкой кода, давайте лучше кратко поговорим, как реализовать подобное на сервере. В качестве server-side для подобных проектов я всегда рекомендую брать NodeJS. Сама парадигма event based неблокирующего асинхронного сервера идеально подходит для высокозагруженных API, а этот самый интранет, он очень большой и запросы ресурсоемкие. К тому же, имеющегося в NPM добра с головой хватит для решения любых задач.

Для демонстрации возможностей, я написал небольшое приложение. Прописано оно по адресу. Работать должно в Chrome, Safari (в том числе и на iPad, iPhone с 4.2) и FF. Но в последнем нужно включить поддержку сокетов. Вот вам мануал. Долго думал, откуда бы взять большой поток данных для наглядного примера, как вспомнил про Twitter Streaming API. Код готового приложения можно невозбранно скачать архивом. Если демонстрация перестанет работать - прошу меня простить, мой старенький сервер очень нежный и неторопливый, и больше времени заняла компиляция node, чем прочтение документации или написание самого кода. Разумеется, в server.js нужно вписать свои логин и пароль. Вообще, я использую sample поток, а вы, прочитав документацию по твиттер апи и twitter-node, можете создать какой-то полезный сервис мониторинга и аналитики хештегов, или выводить в форме границ Украины аватары пользователей, написавших что-то на мове. Фантазии ограничены исключительно возможностями API твиттера, а их более чем хватает.

В заключение, хочу сказать, что я постепенно пересматриваю формат блога, если вам понравилась подобная статья - не поленитесь перейти на веб версию, если в РСС читаете, и воспользоваться кнопкой Google +1. Если соберется немного плюсов, то в ближайшее время мы поговорим про WebWorkers, Forms Validation, нарисуем мужской половой хуй в Canvas, напишем вращающийся чайник на WebGL и попробуем накладывать фильтры и получать информацию из тега <video>.

HTML5 это уже не просто 5 букв, не несущих для обывателя какую-либо смысловую нагрузку, это офигенная лейба, которая помогает повысить объемы продаж своих продуктов в кратные разы. А помните, как все начиналось? Всем было поебать на какие-то HTML5, все болели модным Web2.0 с аяксами, мокрым полом и прочей безвкусной хуитой. Только команда Firefox изредка почитывала драфты, добавляя фишки в свой браузер. Но всем и на это было похуй - в IE6 или Операх (самые стабильные по отсталости и технологической зажатости браузеры) эти понты не работали и не несли какой-либо смысловой или полезной нагрузки. Шли годы, Гугл повторял подвиги Мозиллы, гоняясь за набором максимальных баллов в пенисомерялках для браузеров. Но тут начался скандал: Стиви Джобс и его яблочный рай объявил войну несчастной Адобе, заявив, что "ваши флеши напрочь вешают наши маки". Казалось бы, причем тут Лужков Adobe, в этот момент явно пожалевшая, что в далеком n-ном году купила эту технологию у Макромедии, но армии эпплфагов уже выдвинулись с боевыми флагами на все тех. коммьюнити, новостные порталы и личные блоги, неся слово пасторское в массы. Ну как обычно - стадо овец, которые купились на непонятное сочетание букв и фотошоп с приклеенными к слову Adobe дьявольскими рогами. Apple подсуетились и выкатили галерею демок на "HTML5", которая работала полностью в Safari, само собой разумеется. Чего уж там говорить, даже на ленте.сру новый тренд стал уж больно часто мелькать в новостях. И понеслась новая гонка под названием "У кого HTML5 длиннее". Последними к ней присоединились патсаны из Microsof-а, запилив свой IE9 и по старой проверенной традиции, выкатив свою галерею с красотами, которая опять таки должна работать корректно исключительно под новым ослом, показывая ущербность других. Вы знаете, в мире технологий Майкрософт напоминает мне одного моего знакомого: он приходит с веселыми конкурсами, смешными историями, гитарными песнями и развлекаловками на вечеринку в тот момент, когда уже все нажрались в поросячьи стельки и всем как бы на этого весельчака уже ложить половые члены. И вот бедняга мотается туда-сюда, показывая очень даже неплохие фокусы, танцуя на руках, глотая шпаги (я образно, если что), но все уже давно заняты своими делами и его максимум - получить поджопник с просьбой (если это можно так назвать) доставить очередную бутылку топлива из холодильника. Так и Microsoft: яблоинжинеры и всякие каноникал пилили огромными темпами свои операционки, а Майкрософт выкатывал сервис паки, латающие дыры. iOS и Android сражаются за процентное соотношение на рынке умных телефонов, а ребята из Редмонда все хвастают, каким же охуительным должен стать Win7 Phone. И с браузерами все идет по тем же сценариями: все уже отахали и отохали, а тут приходит юродивый IE с плохо сверстанными промо страницами и начинает демонстрировать свои культи. Смешно же.

Вообще, само существо HTML5 - первоклассный маркетологичесий трюк. Вы, наверняка же знаете, как сильно я ненавижу этих крысюков. Именно из-за них скорость компьютера измеряется мегагерцами (а теперь еще и количеством ядер), именно из-за них вся техника у нас склеена из глянцевой пальцезагрязняемой пластмассы, именно они причастны к распятию Иисуса, смерти динозавров, голоду в КНДР и ценам на Apple iMac. Так вот, этот термин банально впаривается бедным несчастным домохозяйкам и домохозяевам, как что-то, что много круче веселых ферм в одноклассниках и видео с котятами на ютубах. Я же, как второе пришествие, пророк и просто хороший человек, после десятка лет медитаций и духовного роста познал всю суть, чем, собственно, и собираюсь с вами поделиться. Прежде всего, HTML5 в том виде, что он есть сейчас, является первозданным злом, еще похуже флешей и даже java апплетов, ага. Прежде всего, редакция спецификации все еще никак не выйдет из драфтов, и, зная опыт предыдущих инициатив W3C, затянуться это может на долгое-долгое время. По сути, то, что сейчас вам пихают, как высшей степени инновации и нанотехнологии, является ни чем иным, как тестовым образцом. Если завтра исчезнет тэг video, canvas или еще что - не стоит удивляться (я утрирую, разумеется дело касается более тонких материй, чем стирание абзацев про отдельный элемент), это будет просто очередная смена черновика, не более. Во-вторых, то, что сейчас называют HTML5 вышло слишком далеко за рамки своего определения: языка разметки. Взять тот же LaTeX, он обеспечивает основную задачу - верстку сложных текстов, исключая такие побочные процессы, как печать, рисование картинок для книги, генерацию рекламных текстов и прочее. HTMLпять же превращается в уродливого франкенштейна, который обрастает кусками из совершенно неадекватных функций, к примеру - нативная поддержка Drag`n`Drop или edit in place. Я уже молчу про canvas, которые совершенно не вяжется в контекст определения. Из всего этого возникает третья проблема - зависимозависимость HTML5. В первых версиях, разметка, заданная этим языком, была самодостаточная и не требовала использования чего либо, кроме официального мануала. Со временем, HTML начал обрастать CSS, а в последнее время уже и сложно представить одно без другого. Ну а теперь сюда еще входит и javascript. Иначе какой смысл от этого вашего канваса, draggable элементов и прочего?

Третья и самая основная проблема состоит в потере границ. Посмотрите исходный код модных HTML5 демосцен. Удивлены? Да, никакого хатээмэль там нету, CSS + Javascript на стероидах прекомпиляции (очень современная технология, биспезды!) и аппаратного ускорения. Вам пророчат торжество canvas над сильверлайтом или флешем? Верите? Долбоебы. Для JS не существует ни нормальных библиотек, ни адекватным врапперов, ни внятной документации с примерами для работы с холстом (ага, покурите маны libcanvas и я на вас посмотрю). Верите в миф про световую скорость современных технологий? Посмотрите демки на http://www.c3dl.org/ например, посмотрите загрузку процессора, размер исходного кода и сравните с аналогичными демками на flash. Все еще сомневаетесь? Тогда просто попробуйте написать элементарный пример, трансформацию квадрата обычно, изменение его размеров, прозрачности, вращение и прочее. Сравните потери времени, читаемость кода и получите однозначный и бесповоротный ответ. К тому же JS все же как бы client side. Нет, конечно же и для флеша существуют декомпиляторы, но бывают такие случаи, когда процесс общения клиента с серверной частью не стоит показывать всем и сразу, разве нет?

Мораль сего поста проста: не стоит гнаться за новым, забывая про старое. Я, признаться, сам ужасный противник flash, но отбрасывать эту технологию, которая верой и правдой служила интернету долгое время, без которой мог бы не появиться youtube (да и video html element, как логическое продолжение флеш видео), которая в настоящее время полностью документирована и быстродействие которой в разы выше костылей HTML5 - глупо, как минимум, и технологический популизм для одноклеточных эникейщиков, как максимум.

Added 30.10.2010 Вы только посмотрите, какой резонанс вызвал пост у закомплексованных джедаев браузеров. Чуть девушку не разорвали, а ведь одна она уловила смысл, мужланы вы неотесанные. Зрейте в корень, друзья. Пост был не про технологию, а про "медийный шум" и игре на этом. Но вы молодцы, пенисы у вас длинные и широкие и я рад, что дал вам возможность продемонстрировать это. Радует, что не все, сидя на куче дерьма троне профессионалов, утратили юмор.

Приветствую. Сегодня я хочу представить свое первое расширение (самый дебильный перевод слова extension) для браузера Google Chrome. Я когда-то эту поделку гугла облил с ног до головы дерьмом, но времена изменились и теперь хром мой основной браузер дома, на работе и даже на iMac-е, где он заменил тормозной фаерфокс с уродливым рендерином и родной Safari.

Но, ближе к делу. День назад мне почему-то стукнуло написать какой-то extension. Идея пришла сама собой, когда сидящий за спиной товарищ (не ахтунг) спросил, а когда же выйдет новая серия Хауса, которую можно было бы посмотреть под пивко. Погуглил - для хрома такой штуки небыло и вот за пару дней выкатил уже готовую версию. Прошу любить и жаловать, Show Forecast. Простой дизайн, настройка за 10 секунд и у вас уже есть своя личная программка любимых сериалов. Скриншоты, ссылку на загрузку и более подробное описание пожно найти на странице дополнений гугла.

Теперь пара слов о технической части. Я, as always, попытался выучить что-то новое. Как известно, все дополнения для Chrome пишутся банально на javascript + html. В подробности процесса я углубляться не буду, все и так отлично расписано в официальном мануале, просто пара слов об интересных вещах. В драфтах html5 появились много нового и инновационного, а в том числе и storage, который призван заменить кукисы для хранения данных client-side. В хроме реализованы 2 подсистемы хранения: web storage (и то только localStorage в виде переменной-массива) и web database. В детали первого углубляться не буду, это обычное key-value хранилище для integer и string (bool,float,double,array etc - все это по typeof в сторедже отдавало string), а вот второй механизм намного интереснее, так как представляет собой полноценный sqlite внутри браузера. Да-да, теперь в js можно писать запросы на языке sql. Все это реализовано на текущем этапе достаточно сыро, транзакции в БД являются ассинхронными без вариантов. Результат просто отдается в callback функцию. Причина этого понятна - нам не нужны зависания браузера, но вот написания кода с несколькими последовательными запросами это усложняет и замедляет. Код extension-а я отдельно выкладывать не буду, кому интересно - качайте crx файл, меняйте расширение на zip и смотрите сами. Код пока очень грязный, если мне будет и дальше это интересно, либо же на на этот плагин будет спрос, то непременно отрефакторю. В любом случае без этого на текущей версии планируемую i18n интернационализацию будет очень неудобно вводить. Будут вопросы, задавайте без зазрения совести на странице модуля.