Архив категории «Прочее»

  • Веб-разработка в Eclipse: JavaScript

    Как отмечалось ранее, для работы JS вместо Spket IDE я теперь использую Eclipse JSDT, который входит в состав Eclipse Web Tools Project. Причины для такого перехода вполне естественные: проекты, с которыми я работаю, становятся всё сложнее и больше, нужно больше удобства и контроля над ситуацией.

    В JSDT меня больше всего привлекло следующее:

    • Рефакторинг: переименование объектов, выделение блока в отдельную переменную, объединение определения переменной и присваивания и т.д. Некоторые вещи вроде выделения в метод пока толком не работают, но, надеюсь, в ближайшее время это будет исправлено.
    • Валидация кода. Помимо обычной проверки синтаксиса, можно настроить более сложные проверки вроде поиска неиспользованных переменных, недостижимый код, переопределение переменной из внешней области видимости и т.д.
    • Выделение фрагментов camelCase-переменных с помощью Shift+Alt+← и Shift+Alt+→
    • Поддержка JSDoc.
    • Удобный Outline/Quick outline; дополнительные окна, в которых показывается документация и код определения текущего объекта.
    • Автоматическая отбивка кода при его перемещении из/в блок.
    • Подключение внешних библиотек.
    • Встроенный дебаггер.

    Лучше всего будет, если читатель поставит Eclipse for JavaScript Web Developers и изучит все настройки и менюшки — в том числе контекстные — JSDT (лучше включить перспективу JavaScript), потому что возможностей действительно очень много и их сложно описать в одной статье.

    Однако при всей «крутости» этой среды разработки, в ней есть ряд проблем, с которыми пришлось столкнуться прежде, чем окончательно перейти на JSDT.

    Начинаем работу

    Для того, чтобы полноценно использовать все возможности JSDT, обязательно нужно создать проект с JavaScript-природой. Делается очень легко: вызываем File > New > Project… и в появившемся окошке выбираем JavaScript Project. В появившемся диалоговом окне вводим название проекта и жмём Finish. По умолчанию создаётся веб-проект с поддержкой DOM, папкой с JS-исходниками является сам проект. Когда вы лучше освоитесь с JSDT, то сможете более тонко настраивать проект: указывать подключаемые библиотеки, исключать ненужные файлы и папки из индекса. Пока оставим как есть.

    Module pattern

    Главным преимуществом для меня в Spket IDE была поддержка современных паттернов, в том числе и модуля:

    var module = (function() {
    	return {
    		method: function() {}
    	};
    })();
    

    В Spket такая конструкция без проблем отображается в outline и по ней работает code complete, но в JSDT ни то, ни другое не работает:

    ss011

    Небольшой JSDoc исправит ситуацию:

    /**
     * @type module
     */
    var module = (function() {
    	return {
    		/**
    		 * @memberOf module
    		 */
    		method: function() {}
    	};
    })();
    

    Теперь работает как надо:

    ss021

    Но есть ещё одна проблема: приватные переменные и методы модуля не отображаются в Outline, а очень хотелось бы. Это можно исправить, описав самовызывающуюся функцию как конструктор несуществующего класса:

    /**
     * @memberOf __module
     * @type module
     */
    var module = (/** @constructor */ function() {
    
    	function myPrivateMethod() {
    
    	}
    
    	return {
    		/**
    		 * @memberOf module
    		 */
    		method: function() {}
    	};
    })();
    

    ss031

    Как видно из примера, я описал несуществующий класс __module, двойное подчёркивание я использую в качестве своеобразного соглашения об именовании объектов. Проблема в том, что этот несуществующий класс попадёт в code complete всего проекта, и использование двойного подчёркивания — простой и понятный способ отфильтровать ненужные данные при вызове code complete. Однако этот недостаток очень легко можно превратить в достоинство: таким образом можно описывать структуры объектов, доступ к описанию которых затруднён из-за отсутствия строгой типизации в JS:

    ss041

    Поддержка популярных библиотек

    Базовый набор библиотек для JSDT довольно невелик: это стандартные объекты JavaScript (Array, String и прочее) и стандартный DOM (HTMLElement, document и так далее). То есть если мы напишем, например, document. и вызовем code complete, то увидем список свойств и методов объекта document, экземпляра класса Document. Но современная веб-разработка немыслима без использования популярных библиотек вроде jQuery.

    Имея в своём распоряжении JSDoc, можно создать описание практически любого популярно фреймворка и использовать его для подсказок в коде. Так как таких описаний в интернете найдено не было, я воспользовался своим любимым принципом «если хочешь, чтобы что-то было сделано хорошо, сделай это сам» и запустил проект, в котором создаю описания популярных библиотек и фреймворков, с которыми работаю:

    jsdt-docs — JSDoc для популярных библиотек

    В этом проекте сейчас есть следующие библиотеки:

    • Modernizr 2
    • Browser Addons — разные методы и свойства, которые почему-то отсутствуют в стандартном описании DOM в JSDT.
    • console — небольшое описание объекта console, который присутствует в современных браузерах.
    • CSS2Properties — список CSS-свойств для свойства style DOM-элементов. Несмотря на то, что он называется CSS2, в нём присутствуют и CSS3-свойства: такое название выбрано потому, что в стандартном описании Element.prototype.style является объектом класса CSS2Properties.
    • JS SIgnals
    • Node.JS
    • Socket.IO
    • Underscore.js.
    • Zepto.js

    Добавить библиотеку довольно просто:

    1. Идём в настройки: Preferences > JavaScript > Include Path > User Libraries.
    2. Создаём новую библиотеку: нажимаем кнопку New…
    3. Вводим название библиотеки в появившемся окне и жмём ОК.
    4. Выделив только что добавленную библиотеку, нажимаем на кнопку Add .js file… и выбираем один или несколько файлов, относящихся к данной библиотеке.

    После того, как библиотека была создана, нужно добавить её в проект:

    1. Идём в настройки проекта: Project > Properties > JavaScript > Include Path > Libraries.
    2. Жмём кнопку Add JavaScript Library, выбираем User Library, а затем и библиотеки, которые хотим добавить.

    Теперь у вас в проекте будет работать code complete для указанных библиотек:

    ss051

    Поддержка jQuery

    Добавление поддержки своего любимого фреймворка оказалась не такой уж и простой задачей. Во-первых, он довольно большой и содержит внушительных объемов документацию. Во-вторых — многие методы в нём «перегружены»: например, val() возвращает текстовое значение поля, а val(str) — записывает его и возвращает уже jQuery-объект.

    К счастью, у документации к jQuery есть публичный API, который выдаёт описание всех методов в XML. Я написал парсер на node.js, который опрашивает API и преобразует XML в JSDoc, понятный для JSDT (и, надеюсь, другим IDE). Так что в случае выхода новой версии jQuery можно быстро перегенерировать всё документацию. Парсер я писал для себя и по-простому, он не поддерживает передачу параметров через командную строку, всё настраивается в main.js:

    • Можно сгенерировать документацию для определённой версии jQuery (TARGET_VERSION).
    • Можно сгенерировать описание в виде нескольких файлов. Это связано с особенностью JSDT. Как уже отмечалось ранее, в jQuery много «перегруженных» методов, и если их описать в одном JS-файле, то JSDT будет использовать только одно (самое последнее) описание. Однако если сохранить описание методов с одинаковым названием в разных файлах, то JSDT вполне неплохо покажет по ним code complete и документацию. Так что у вас есть выбор: при создании библиотеки jQuery добавить все файлы вида jquery-jsdoc-N.js (Eclipse JSDT) или же только jquery-jsdoс.js если ваша IDE способна прочитать описание с перегруженными методами.
    • Можно переписать некоторые определения для более удобной работы с code complete (class_map, prefix_map). Например, так переписываются описания для Deferred и Promise объектов, чтобы можно было использовать их описание в JSDoc:

    ss06

    В описании есть ряд классов, которые можно использовать в JSDoc: __jQueryDeferred, __jQueryPromise и __jQueryEvent.

    Пишем плагины к jQuery

    Собственно, как писать плагины рассказывать нет смысла, это подробно описано в документации. Покажу лишь как сделать так, чтобы ваш плагин появился в code complete. А сделать это очень просто, достаточно методу плагина указать, что он является членом класса jQuery:

    jQuery.extend(jQuery.fn, {
    	/** @memberOf jQuery */
    	myPlugin: function() {
    
    	}
    });
    
    $('div').m // тут можно вызвать code complete
    

    Поддержка Node.JS

    Отдельно стоит упомянуть Node.JS, так как к модулям нужно обращаться не напрямую, а через функцию require():

    var http = require('http');
    http.createServer(function() {
    
    });
    

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

    Все модули в моей документации описаны в виде классов Node{Name}Module, например: httpNodeHttpModule, utilNodeUtilModule. Поэтому для переменной, в которую записывается модуль, указываем через JSDoc нужный тип:

    /** @type NodeHttpModule */
    var http = require('http');
    http. // вызываем code complete
    

    Советы

    В качестве заключения дам несколько советов, которые помогут вам в работе с JSDT:

    • Не используйте фигурные скобки при указании типа переменной с помощью тэга @type — в некоторых случаях JSDT не сможет подцепить тип переменной. Лучше писать так: @type Array (вместо @type {Array}).
    • При описании модуля тэг @memberOf moduleName достаточно указать только у одного свойства/метода в литерале, все остальные подцепятся автоматически.
    • Если у вас в проекте есть непосредственно код библиотек (например, jQuery), то его лучше исключать из индекса, чтобы он не мешал работе code complete. Делается это так: заходите в настройки проекта Project > Properties > JavaScript > Include Path > Source. Разворачиваете папку с исходниками, двойной клик по фильтру Excluded и в диалоговом окне в секцию Exclusion patterns добавляете файлы, которые надо исключить.
  • XV — удобная работа с XML-файлами

    Мне по долгу службы приходится много работать с XML-файлами, которые генерирует CMS. Как правило, для онлайн-просмотра XML-файлов используется Firefox или Internet Explorer, но что делать таким как я, которые используют Safari/Chrome в качестве основного инструмента разработки? Есть плагин xmlview для Safari на Маке от Marc Liyanage, который хоть и спасает ситуацию, но не сильно.

    Поэтому решил написать свой просмотрщик XML-файлов для браузеров на движке Webkit. Встречайте — XV:

    overview-2

    Что умеет

    • Сворачивание/разворачивание элементов. Для избавления от визуального шума соответствующие стрелочки появляются при наведении на элемент. Alt-клик по стрелке сворачивает/разворачивает все внутренние элементы.
    • Outline для удобного обзора больших документов
    • Поиск по названию или XPath. По умолчанию ищет вхождение подстроки в названии тэгов и атрибутов, если используются спецсимволы вроде ‘/’ или ‘[‘ то поиск автоматически переключается в XPath-режим.
    • Режим Quick XPath — моя самая любимая фича. Зажмите клавишу Control (Mac) или Ctrl (PC) при наведении курсора на название элемента или атрибута чтобы войти в этот режим (появится специальный тултип). Нажимайте на клавишу Shift чтобы переключаться между доступными вариантами XPath, а затем просто перетаскивайте текущий элемент в текстовый редактор (используется drag’n’drop). Пользователи Google Chrome могут кликнуть по элементу, чтобы скопировать XPath в буфер обмена. Этот режим очень удобно использовать внутри IDE, например, вот так:

    ide

    Скачать

    Можно также использовать и в Firefox как стандартный стиль для XML-файла, если скачать соответствующий XSL-файл:
    <?xml-stylesheet type="text/xsl" href="xv-browser.xsl"?>.

    Демонстрация

    Посмотреть, как это выглядит, можно на тестовой страничке (хорошо работает в Safair/Chrome, в Opera и Firefox глючит drag’n’drop).

    Исходный код доступен на GitHub: http://github.com/sergeche/xmlview/
    Там же можно сообщения об ошибках (тестировал только на своих XML-файлах) и пожелания.

    Метки: , , ,
  • Идея для сниффинга браузеров

    Возникла одна идея, как можно скрестить клиентское и серверное «вынюхивание» браузера.

    Как это делается сейчас? На сервере мы смотрим на заголовок User Agent и определяем, что это за браузер. Но этот заголовок можно легко подменить (причём необязательно это делать в самом браузере, это может сделать прокси-сервер), поэтому такая проверка совсем ненадёжна. На клиентской стороне у нас гораздо больше возможностей: мы можем не только проверить User Agent браузера, но и его возможности (например, поддержку определённых CSS и JS свойств), что даст нам более точные характеристики браузера.

    Собственно, сама идея как раз заключается в том, чтобы скрестить эти два способа: определить с помощью CSS и JS характеристики браузера и в нужный момент сообщить их на сервер. Основа алгоритма — Chunked Transfer Encoding, позволяющий передать ответ (например, HTML-документ) не целиком, а кусками. Итак, сам алгоритм:

    1. Когда пользователь запрашивает HTML-страницу, отдаём ему первый фрагмент (chunk), в котором содержится sniffing-код. После этого соединение удерживается на некоторое время, чтобы отдать второй фрагмент документа.
    2. Браузер, получив первый фрагмент, тут же его парсит и пытается отобразить.
    3. В этом первом фрагменте у нас sniffing-код, результатом работы которого является CSS-свойство background-image, применяемое к элементу <html>.
    4. Путь к этой фоновой картинке является уникальным для каждого браузера и так уж получилось, что как только мы применили это свойство элементу, браузер открывает второе соединение и тут же пытается загрузить эту картинку.
    5. Сервер, получив запрос к нашей «картинке» понимает, каким браузером мы зашли и отдаёт вторую часть ответа в первом соединении.
    6. Если обращения к «картинке» не было (например, зашли поисковым роботом), то через какой-нибудь небольшой промежуток времени отдаём стандартный ответ.
    7. После первого «вынюхивания» можно поставить куку, чтобы потом сразу отдавать нужный ответ.

    В итоге получаем следующие преимущества:

    • Нет никаких редиректов: ответ о типе браузера получаем в одном соединении (полезно для SEO).
    • Очень сложно обмануть такой сниффер: можно до посинения менять строку User Agent, но результат останется прежним. Гугл сможет эффективней банить Оперу.
    • Более сложные проверки: можно не просто определять название браузера, но и его возможности, благодаря CSS Media Queries.

    Для желающих поэкспериментировать я написал демонстрацию этого подхода на node.js. К сожалению, у меня на VPS не хватает памяти, чтобы собрать node.js, поэтому предлагаю читателю самому его установить и проверить у себя. Если кто выложит это в онлайн — буду премного благодарен. Выложили: http://tbms.ru:8126/ (спасибо Николаю Митину).

    Полезные уроки

    Пока писал эту демонстрацию, вынес для себя много ценной информации:

    1. Первый чанк должен быть достаточно большим, чтобы все браузеры смогли его применить. Самый большой лимит — у движка Webkit: около 2 КБ. Поэтому приходится «добивать» первый фрагмент пробелами, чтобы всё работало как надо.
    2. Webkit очень плохо ведёт себя при переопределении CSS-свойств. Например:
      html { background-image:url(image1.png); }
      html { background-image:url(image2.png); }
      		

      В этом случае Webkit (и десктопный, и мобильный) загрузит обе картинки, хотя понятно, что нужна только последняя. Это ещё одно подтверждение, что мобильные версии сайта лучше делать отдельным проектом, а не вставлять через CSS Media Queries. Иначе попытки сократить траффик заменой больших фоновых картинок на маленькие приведёт к обратному эффекту. Хотя тут нужно больше исследований, возможно, это издержки работы с локальным сервером.

    3. Firefox не отработает первый чанк до тех пор, пока не получит элемент <body>. Это довольно серьёзный недостаток в том случае, если вы захотите выдавать уникальные стили и скрипты для браузера в секции <head>. С другой стороны, если послать <script>alert(1)</script>, то чанк отработает нормально, даже без <body>. Что наталкивает на мысль о существовании неких триггеров, которые заставят браузер сделать то, что нам нужно, осталось только найти наиболее безопасный.

    Повторюсь, что это только идея, а не призыв к действию. Буду рад, если кто-то на её основе сделает что-то крутое и интересное.

  • Content assist для элемента textarea

    Очередной эксперимент в поисках идеального средства для простого и быстрого написания кода.

    <textarea>, да и веб-технологии в целом привлекают меня своей простотой, доступностью и возможностью сделать так, как нужно мне. Есть Zen Coding, который позволяет быстро и удобно работать с большим объёмом XHTML-данных, но для пущего удобства не хватает автодополнения кода. Поиск в интернете не дал никаких вменяемых результатов, поэтому решил написать свой:

    content-assist

    Проверить автодополнение можно на тестовой странице. Попробуйте написать несколько английских слов, начинающихся на «a» (awesome, animal, amazing). Должно работать везде, включая IE6.

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

    • TextViewer — по сути, обёртка для <textarea>. Основное предназначение: дать удобный интерфейс для получения содержимого элемента. Один из основных методов — getCharacterCoords(char_ix), возвращает координаты для определённого символа. Метод возвращает объект со свойствами x и y в пикселях, отсчёт идёт от левого верхнего угла <textarea> до левого верхнего угла нужного символа. Метод getAbsoluteCharacterCoords(char_ix) возвращает то же самое, только относительно offsetParent. Как не трудно догадаться, этот класс можно переписать для работы с content-editable блоком, и у вас будет автодополнение для более серьёзного редактора.
    • ContentAssistProcessor — процессор, который высчитывает и предлагает список дополнений. По умолчанию ищет левую и правую границу английского слова (см. метод isAllowedChar), ищет префикс (от левой границы слова до каретки) и предлагет по этому префиксу список дополнений.
    • CompletionProposal — предложение для автодополнения. Главный метод — apply(), который применяет текущее предложение к TextViewer-объекту.
    • ContentAssist – основной класс. Связывает между собой TextViewer и ContentAssistProcessor, а также управляет всплывающим окном с подсказками.
    • tx_utils — набор всяких DOM-утилит.

    Для добавления поддержки автодополнения для <textarea> нужно инициализировать все эти классы:

    var viewer = new TextViewer(document.getElementById('my-textarea'));
    var processor = new ContentAssistProcessor(['word1', 'word2', 'word3']);
    var content_assist = new ContentAssist(viewer, processor);
    

    Для удобства есть класс BasicContentAssist, который делает всё то же самое для простых случаев (автодополнение по фиксированному словарю):

    new BasicContentAssist(document.getElementById('my-textarea'), ['word1', 'word2', 'word3']);
    

    У класса ContentAssistProcessor есть метод completitionProposalFactory, который должен возвращать объект класса CompletionProposal. Внешний вид попапа с предложениями был нагло позаимствован из редактора Espresso и полностью управляется через CSS. Окошко с предложениями можно вызвать принудительно по Ctrl+Space (не работает в Опере и немного тупит в Файерфоксе) либо по Alt+Space (хвала разработчикам Оперы: это тоже не работает, по крайней мере на Маке) и заменить текущее слово (зависит от позиции каретки).

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

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

    Метки: ,
  • Узнаём строку CSS-правила в Safari/WebKit/Chrome Web Inspector

    В браузерах на движке WebKit есть замечательный инструмент для отладки веб-страниц — Web Inspector. По сути, это аналог Firebug, со своими сильными и слабыми сторонами. В последнее время я всё чаще предпочитаю пользоваться Web Inspector’ом, однако один его недостаток постоянно не давал мне покоя — это отсутствие номера строки редактируемого CSS-правила:

    css-tab

    Если погуглить, то можно убедиться, что не одного меня беспокоит эта проблема. Руководствуясь правилом «если хочешь что-то сделать — сделай это сам» я написал небольшой хак, который позволяет узнать номер строки CSS-правила:

    Web Inspector CSS hack

    Установка довольно простая: нужно всего лишь подключить файл SC-CSSAdditions.js в inspector.html (Safari, WebKit) или devtools.html (Google Chrome). Подробная инструкция написана на странице проекта.

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

    Весь Web Inspector практически полностью базируется на возможностях браузера, предоставляемых спецификацией W3C. Соответственно, номер строки CSS-правила просто так не узнаешь. Я написал альтернативный CSS-парсер, который достаёт из исходника правила, но при этом сохраняет их позицию в коде. Перед тем, как Web Inspector выводит список правил, принадлежащих элементу, происходит сопоставление этих правил с моими (по позиции в списке или по селектору) и к имени файла добавляется номер строки:

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

  • Ambilight для тэга video

    В некоторых топовых моделях телевизоров Philips есть такая прикольная штука, как Ambilight. По сути, это светодиодная подсветка телевизора, которая меняет цвет в зависимости от цвета картинки. Смотреть кино на таком телевизоре — одно удовольствие.

    На флэше уже есть реализации такой подсветки, ну а чем мы — фронтовики — хуже? Дабы в очередной раз разобраться, на что способны современные браузеры, на свет появился очередной эксперимент:

    Ambilight для тэга <video> (Firefox 3.5, Opera 10.5, Safari 4, Google Chrome 4)

    Далее рассмотрим, как это было сделано.

    Алгоритм

    Прежде, чем начать что-то писать, нужно составить алгоритм, по которому будет работать наша подсветка.

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

    Исходя из этого описания, нам нужно проделать следующее: определить цвет каждого диода для текущего кадра и отрисовать его свечение. Что ж, приступим.

    Определяем цвет диода

    Для удобства предположим, что в нашем «телевизоре» всего по 5 светодиодов с каждой стороны. Соответственно, нужно взять фрагмент кадра, разделить его на области по количеству диодов и найти усреднённый цвет в каждой области — это и будут цвета подсветки:

    get-color

    Чтобы получить изображение текущего видео-кадра, достаточно отрисовать его в <canvas> через метод drawImage():

    var canvas = document.createElement('canvas'),
    	video = document.getElementsByTagName('video')[0],
    	ctx = canvas.getContext('2d');
    
    // обязательно выставляем размер холста
    canvas.width = video.width;
    canvas.height = video.height;
    
    // рисуем кадр
    ctx.drawImage(video, 0, 0, video.width, video.height);
    

    Текущий кадр получили, теперь нужно узнать, какого цвета пиксели сбоку изображения. Для этого воспользуемся методом getImageData():

    /** Ширина области, которую будем анализировать */
    var block_width = 50;
    
    var pixels = ctx.getImageData(0, 0, block_width, canvas.height);
    

    В объекте pixels есть свойство data, в котором содержатся цвета всех пикселей. Причём хранятся они в немного необычном формате: это массив RGBA-компонетнов всех пикселей. К примеру, чтобы узнать цвет и прозрачность первого пикселя, нужно взять первые 4 элемента массива data, второго пикселя — следующие 4 и так далее:

    var pixel1 = {
    	r: pixels.data[0],
    	g: pixels.data[1],
    	b: pixels.data[2],
    	a: pixels.data[3]
    };
    
    var pixel2 = {
    	r: pixels.data[4],
    	g: pixels.data[5],
    	b: pixels.data[6],
    	a: pixels.data[7]
    };
    

    Нам нужно разделить все полученные пиксели на 5 групп (по количеству светодиодов, которое мы выбрали ранее) и проанализировать каждую группу по очереди:

    function getMidColors() {
    	var width = canvas.width,
    		height = canvas.height,
    		lamps = 5, //количество светодиодов
    		block_width = 50, // ширина анализируемой области
    		block_height = Math.ceil(height / lamps), // высота анализируемого блока
    		pxl = block_width * block_height * 4, // сколько всего RGBA-компонентов в одной области
    		result = [],
    
    		img_data = ctx.getImageData(0, 0, block_width, h),
    		total = img_data.data.length;
    
    	for (var i = 0; i < lamps; i++) {
    		var from = i * width * block_width;
    		result.push( calcMidColor(img_data.data, i * pxl, Math.min((i + 1) * pxl, total_pixels - 1)) );
    	}
    
    	return result;
    }
    

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

    function calcMidColor(data, from, to) {
    	var result = [0, 0, 0];
    	var total_pixels = (to - from) / 4;
    
    	for (var i = from; i <= to; i += 4) {
    		result[0] += data[i];
    		result[1] += data[i + 1];
    		result[2] += data[i + 2];
    	}
    
    	result[0] = Math.round(result[0] / total_pixels);
    	result[1] = Math.round(result[1] / total_pixels);
    	result[2] = Math.round(result[2] / total_pixels);
    
    	return result;
    }
    

    Итак, мы получили цвета для светодиодов, но они слишком тусклые: ведь диоды светят очень ярко чтобы добиться достаточного уровня свечения. Нужно увеличить яркость цветов, а также увеличить насыщенность, чтобы добавить глубины свечению. Для этих целей очень удобно пользоваться цветовой моделью HSV — hue, saturation, value, — достаточно домножить два последних компонента на некий коэффициент. Но цвета у нас хранятся в модели RGB, поэтому сначала конвертируем цвет в HSV, увеличиваем яркость и насыщенность, а затем обратно конвертируем в RGB (формулы конвертирования RGB→HSV и обратно легко находятся в интернетах):

    function adjustColor(color) {
    	color = rgb2hsv(color);
    	color[1] = Math.min(100, color[1] * 1.4); // насыщенность
    	color[2] = Math.min(100, color[2] * 2.7); // яркость
    	return hsv2rgb(color);
    }
    

    Рисуем свечение

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

    Градиент рисуется просто: сначала создаём его с помощью createLinearGradient(), а потом добавляем цвета через addColorStop() и отрисовываем его:

    // для свечения создаём новый холст
    var light_canvas = document.createElement('canvas'),
    	light_ctx = light_canvas.getContext('2d');
    
    light_canvas.width = 200;
    light_canvas.height = 200;
    
    var midcolors = getMidColors(), // полчаем усреднённые цвета
    
    	grd = ctx.createLinearGradient(0, 0, 0, canvas.height); // градиент
    
    for (var i = 0, il = midcolors.length; i < il; i++) {
    	grd.addColorStop(i / il, 'rgb(' + adjustColor(midcolors[i]).join(',') + ')');
    }
    
    // рисуем градиент
    light_ctx.fillStyle = grd;
    light_ctx.fillRect(0, 0, light_canvas.width, light_canvas.height);
    

    Получим что-то вроде этого:

    gradient

    Маска

    Маску мы нарисуем в фотошопе. Есть замечательный фильтр Lightning Effects (Filters→Render→ Lightning Effects...), который позволяет создавать источники света. Заливаем слой белым цветом и вызываем этот фильтр примерно с такими настройками:

    lightning

    Получим вот такое световое пятно:

    spot

    Меняем режим наложения на Lighten, дублируем, крутим, меняем масштаб, играемся с прозрачностью, правим уровни и получаем вот такой результат:
    spot-grid

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

    result

    Но самое главное — мы легко сможем менять внешний вид и интенсивность свечения, не прибегая к программированию.

    Свечение для левой стороны готово, осталось проделать то же самое для правой стороны, добавить плавную смену подсветок и написать контроллер, который с определённым интервалом будет эту подсветку обновлять. Расписывать это — долго и нудно, проще посмотреть исходник.

    UPD: как показал эксперимент, далеко не у всех нормально работает HD-видео (изначально размер ролика был 1280×544), снижение разрешения до 592×256 решило проблему.

    Метки: , , ,
  • Автоматическое копирование файлов на FTP/SSH в Eclipse

    В последнее время все чаще и чаще слышны просьбы веб-разработчиков сделать удобную работу в любимом редакторе/IDE, чтобы изменившиеся файлы автоматически попадали на удаленный сервер. Самый простой способ решить эту задачу — редактировать файлы напрямую на сервере. Хотя это вполне рабочее решение, у него есть ряд недостатков, самый большой из которых: отсутствие локальной копии файла. В случае, если ваш коллега через 5 минут закачает свою, исправленную и дополненную версию файла, можно быть уверенным, что ваши изменения потеряются безвозвратно. Более того, этот способ годиться только для мелких исправлений, на 5—10 минут. Если же нужно решить какую-то более глобальную задачу, дней на 5, например, вам в любом случает придется держать локальную копию проекта, чтобы спокойно переводить его в нерабочее состояние.

    Самый правильный способ решения задач с синхронизацией файлов, который проповедуют все маститые разработчики — использовать систему версионного контроля (VCS), вроде SVN или Git. Рабочий процесс в этом случае выглядит следующим образом. Разработчик локально, у себя на компьютере, вносит необходимые изменения и делает коммит в репозиторий. В этот момент у репозитория срабатывает хук (некий скрипт), который берет изменившиеся файлы и закачивает на продакшн-сервер. Это идеальное решение для командной работы, когда необходимо объединять свои исправления с чужими. И еще, как бонус: нет необходимости бегать по 10 разным папкам и вручную копировать изменившиеся файлы на сервер. Достаточно нажать всего на одну кнопку — и абсолютно все необходимые файлы оказываются на сервере. Многих, почему-то, пугает такая «сложность», хотя на настройку окружения требуется времени не больше, чем на очередной перекур или чтение новостей.

    Ну ладно, оставим это на совести каждого конкретного человека. Недавно у меня возникла, скажем так, промежуточная задача. Весь проект лежит в SVN, автоматом закачивается на продакшн — все работает просто замечательно. Только сайт написан на Java, и для его локального запуска требуется ой как много ресурсов, особенно если параллельно работает Eclipse, фотошоп и виртуальная машина с виндой. Обычный рефреш страницы занимал минуту. И я озадачился тем, чтобы над проектом можно было работать локально, а вот проверять его можно было на удаленном dev-сервере. То есть я правлю файл, сохраняю его, при необходимости делаю build (объединение и минификация JS и CSS) и все изменившиеся файлы автоматически попадают на dev-сервер, без каких-либо лишних телодвижений. Решение оказалось довольно простым и элегантным, возможно, сработает и для других редакторов и IDE. Итак:

    1. Под *nix системы есть замечательный проект под названием FUSE, который позволяет монтировать удаленный сервер как обычную папку в локальной файловой системе. На Маке я использовал MacFuse + оболочку MacFusion для настройки FTP/SSH-серверов. На винде можно использовать платный WebDrive или NetDrive для этих же целей.
    2. Устанавливаем FUSE или WebDrive/NetDrive, настраиваем подключение к серверу и монтируем его как локальную папку.
    3. Для Eclipse ставим плагин FileSync, задача которого — автоматически синхронизировать проект с какой-нибудь внешней папкой. Синхронизация одностронняя: копируются файлы из проекта в папку, но не из папки в проект.
    4. Идем в настройки проекта (Project → Properties) в секцию File synchronization и настраиваем синхронизацию для проекта (пример с сайта разработчика):

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

    5. Не забываем включить автобилд (Project → Build Automatically), чтобы при любом изменении ресурсов проекта файлы автоматически синхронизировались, и опцию General → Workspace → Refresh automatically в настройках Eclipse, чтобы файлы, добавленные вне Eclipse (например, картинку новую скопировали) автоматически появлялись в проекте.

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

    UPD: Решение от Neolord для работы со стандартным синхронизатором из Aptana.

  • Установка Aptana на Eclipse Galileo 3.5

    UPD: вышла Aptana 1.5, которая без проблем ставится на Eclipse 3.5 из update site: http://update15.aptana.org/studio/24896/ (спасибо Vii за ссылку). Так что все остальное тут написанное можно рассматривать как еще один способ установки плагинов.

    Вышел новый Eclipse Galileo 3.5, а в месте с ним появились очередные проблемы с совместимостью со старыми плагинами. Одна из самых неприятных проблем для меня — Aptana ни в какую не хочет ставится из update site. Как выяснилось, эта проблема вполне решаемая.

    1. Качаем любой дистрибутив Eclipse Galileo и распаковываем его.
    2. Качаем альфа-версию Aptana Andretti по секретной ссылке. Скачивать лучше zip-архив, а не установщик. Также распаковываем его.
    3. Запускаем Aptana Andretti. При первом запуске появится окошко Install Additional Features, в самом низу выбираем опцию Do not show again. Закрываем Aptana.
    4. Из той папки, где у вас находится Aptana, берем папки plugins и features и копируем их в папку dropins той директории, куда вы распаковали дистрибутив Eclipse.
    5. Запускаем Eclipse. Он при запуске спросит, какой workspace хотите использовать. Нужно выбрать тот, который был создан Aptana (папка Aptana Studio Workspace где-то внутри стандартной директории с документами), иначе при каждом запуске Eclipse будут вываливаться ошибки. Насколько я понял, их вызывает тот самый Install Additional Features, который пытается запуститься при запуске (поэтому нужно было выбрать Do not show again). Отключается это некой переменной, хранящейся внутри .metadata рабочего пространства, которую пока лень искать.
    6. Для надежности в настройках отключаем Welcome Screen (Aptana → My Aptana → Never display after startup) и перезапускаем Eclipse. Должно все работать как надо.
    Метки: , ,
  • Firefox: редактируем textarea во внешнем редакторе

    Наконец-то добрались руки до поля поиска расширений для Firefox. Хотелось найти что-нибудь такое, что позволит редактировать содержимое полей во внешнем редакторе, а то уже запарился в CMS голый текст писать. Первый же запрос вывел на замечательный плагин It’s All Text!, который как раз делает то, что нужно. Этот плагин добавляет кнопочку edit в правом нижнем углу у <textarea>, позволяя открыть и редактировать содержимое поля в любимом редакторе.

    Пользователям Mac OS придется немного поплясать с бубном: Firefox не позволяет открыть app-бандлы напрямую. Для этого нужно написать небольшой скрипт. Создайте файл, например edit_in_coda.app (расширение обязательно app, иначе плагин не позволит выбрать скрипт) и написать там следующее:

    #!/bin/sh
    open -a Coda "$@"
    

    Затем в консоли нужно выставить этому файлу права на исполнение:

    chmod +x edit_in_coda.app
    

    Теперь вот правлю текст в Coda Espresso (там гораздо удобнее), в котором через Zen Coding можно быстро писать XML/HTML. Красота!

    Метки: ,
  • СЕО-порно

    Я уже привык ко всякого рода сеошным извращениям на сайте, чтобы поднять его повыше в результатах поиска, но этот пример просто убил меня. В Яндексе по запросу «скачать аудиокниги» на первом месте появляется замечательный сайт mp3-kniga.com с не менее замечательным вступительным текстом:

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

    Там еще слева опрос «в тему», ага.

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

    PS: есть еще примеры подобного маразма на сайтах?

    UPD: компания Арманд ненавязчиво объясняет, как правильно писать слово Peugeot (спасибо biseptol).

    Метки: ,

← cтарое