книги хакеры / журнал хакер / 184_Optimized

Brunch

Brunch создавался с той же задачей — уделать Grunt по всем фронтам, но подошел к ней совсем с другой стороны. Разработчики Brunch решили взять хорошим пониманием предметной области, то есть сделать менее универсальный инструмент, который будет заточен именно под задачи фронтенда, например без всяких настроек понимать, что *.js — это файл со скриптами, *.coffee — CoffeeScript и так далее. Brunch

довольно быстрый, гораздо быстрее Grunt, но чуть медленнее Gulp. К безусловным достоинствам Brunch стоит отнести также действительно компактный конфиг, меньше, чем у Grunt и Gulp, в разы. Вот, например, простой конфиг Brunch:

exports.config =

files:

javascripts:

joinTo:

'javascripts/app.js': /^app/

'javascripts/vendor.js': /^(bower_

components|vendor)/

stylesheets:

joinTo: 'stylesheets/app.css'

order:

after: ['vendor/styles/helpers.css']

templates:

joinTo: 'javascripts/app.js'

Заметь, что конфиг можно писать как на CoffeeScript (как в данном случае), так и на обычном JS. Мы создаем обычный модуль, который возвращает JSON с настройками сборки.

Обрати внимание на ключи joinTo и order. Это и есть знание предметной области, о котором я упоминал, — на уровне конфига Brunch знает, что ты, скорее всего, захочешь склеить файлы, причем некоторые раньше остальных. Именно это позволяет заменить 400 строк конфига Grunt на 20–30 строчек

Brunch.

Плюс к этому экосистема Brunch гораздо меньше, чем

уGrunt и даже чем у Gulp. Плагинов около 50 (сравни с 450+

уGulp, например), развитие идет не очень быстро, в общем, здесь все довольно печально.

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

ENB

Ну и под конец самое сладкое. Хочу рассказать про систему сборки, разработанную в Яндексе Маратом Дулиным, которая называется ENB. Именно ее мы сейчас и используем на нашем проекте. Ее подход принципиально отличается от всех описанных систем: изначально она создавалась для работы с проектами, использующими BEM-методологию, хотя, как отмечает автор, ее платформа свободна от идеологии BEM и может быть использована для всех проектов подходящей структуры.

Вкратце, в чем суть. В ENB мы оперируем понятием цели, то есть конечного файла, который нужно собрать, или ноды (папки, в общем случае страницы), для которой нужно собрать некоторый набор файлов. Для того чтобы собрать целевой файл, мы используем некоторое количество технологий (грубо говоря, плагинов в терминах Grunt, хотя технологии меньше по размерам и более специализированы). Первым делом ENB определяет исходный набор файлов, которые нужны для сборки целей (этим занимаются несколько базовых технологий, по умолчанию работающие с методологией BEM, то есть они ищут *.bemdecl-файл, в котором прописаны зависимости данной ноды от разных блоков), полностью разворачивает это дерево зависимостей (когда блок, от которого зависит твоя страница, сам зависит от другого, подключаются оба в нужном порядке), а затем находит файлы, необходимые для каждой зарегистрированной технологии. Затем ENB придерживается описанной в конфиге последовательности трансформаций файлов (тут можно проследить некоторую аналогию с Gulp). Несмотря на некоторые отличия от стандартного подхода си-

стем сборки, разобравшись с основными понятиями, дальше работать с ENB довольно легко.

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

К недостаткам можно отнести то, что конфиг ENB достаточно многословный, так как есть возможность управлять абсолютно всеми этапами сборки. Плюс ENB все-таки писался для BEMметодологии, и прикрутить его к проекту с совершенно другой структурой потребует лишних телодвижений. Для ENB не так много написанных технологий (порядка 60), но с большинством задач BEM-проектов он справляется на ура.

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

ţŖťŨŞŭŲŞū

ťŦŖŘŖū Надоело ходить на сайты JavaScript-библиотек и качать

архивы каждый раз, как надо добавить на сайт очередной jQueryплагин? Бовер сделает все сам.

Артём Сапегин frontend-разработчик, Badoo artem@sapegin.ru

Установка Бовера

Для работы с Бовером тебе потребуются

Node.js и Git. Уста-

новка предельно проста: npm install -g bower

енеджеры пакетов упрощают установку и обновле-

Мние зависимостей проекта, то есть сторонних библиотек, которые он использует: jQuery, Fotorama, все, что используется на твоем сайте и написано

не тобой.

Хождение по сайтам библиотек, скачивание и распаковка архивов, копирование файлов в проект — все это заменяется парой команд в терминале.

У многих языков программирования есть стандартные менеджеры пакетов, которыми разработчики пользуются для установки всех библиотек: gem у руби, pip у питона и другие. У серверного яваскрипта есть npm (почему он не подходит для клиентского — дальше), а у клиентского яваскрипта до недавнего времени ничего не было. Было множество раз-

ных пакетных менеджеров (Jam, Component, Volo, Ender),

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

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

Бовер не навязывает пользователю свою систему сборки, разработчику пакетов — метод подключения библиотеки (AMD, CommonJS и другие). Все, что делает Бовер, — устанавливает нужные проекту пакеты подходящих версий вместе с их зависимостями. Другими словами: просто загружает файлы нужных библиотек и все, что нужно для их работы, в специальную папку. Остальное остается на усмотрение разработчика.

Работаспакетами

Попробуем что-нибудь установить, например jQuery:

bower install --save jquery # ǨȟȜ bower i -S jquery

Эта команда скачает jQuery последней версии в папку

bower_components/jquery.

Флаг --save говорит Боверу, что он должен сохранить имя пакета и его версию в файл-манифест — bower.json. В этом файле хранится список всех зависимостей проекта (пакетов, установленных через Бовер) и другие метаданные, нужные для создания своих пакетов. Вместе с именами пакетов можно указать версии, с которыми твой проект гарантированно будет работать.

У нас такого файла еще нет, о чем и говорит строчка «No bower.json file to save to, use bower init to create one» в логе.

Создадим его:

bower init

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

Enter.

На вопрос «Set currently installed components as dependencies?» нужно ответить «Yes» — все ранее установленные компоненты (в нашем случае это jQuery) автоматически попадут в созданный JSON-файл. А на вопрос «Would you like to mark this package as private which prevents it from being accidentally published to the registry?» — тоже «Yes» — это пре-

дотвратит случайную регистрацию пакета в реестре Бовера. Поставим еще несколько пакетов и посмотрим, что у нас

получилось:

bower install --save social-likes jquery-icheck

bower list

the project dependencies..

На птичьих правах

bowertest#0.0.0 /Users/admin/bowertest

ʹͻͻ jquery#2.1.0 (2.1.1-beta1 available)

ʹͻ jquery-icheck#1.0.2

ͻͻ jquery#2.1.0 (2.1.1-beta1 available)

ͻ social-likes#3.0.2

ͻͻ jquery#2.1.0

Команда bower list показывает список всех установленных пакетов. Тут мы видим, что все пакеты зависят от jQuery и что Бовер смог найти подходящую всем версию — jQuery 2.1.0. Каждый пакет устанавливается в свою папку, вложенных пакетов нет, jQuery встречается только один раз. В корне проекта лежит созданный командой bower init файл bower.json, но теперь там перечислены уже все пакеты, которые показывает bower list, а не только jQuery.

Для удаления пакетов используется команда bower uninstall <packageName>.

РАЗВЕРТЫВАНИЕПРОЕКТА

Есть два подхода к развертыванию проектов:

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

2. В репозиторий добавляется не только bower.json, но и папка bower_components. Так развертывание не зависит от внешних серверов, но репозиторий раздувается десятками (а то и сотнями) лишних файлов.

СЕМАНТИЧЕСКИЕВЕРСИИ(SEMVER)

Semver (semver.org) — это, во-первых, подход к версионированию библиотек: формат номера версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ и правила, по которым следует увеличивать то или иное число.

А во-вторых — это способ описания требуемых версий зависимостей, который используют Бовер и npm.

При установке с флагом --save версии пакетов добавляются в bower.json в виде ~1.0.1. Тильда в начале говорит о том, что при установке будет выбрана версия 1.0.1 или с большим последним числом (ПАТЧ), если она есть. Таким образом будет установлена версия с последними исправлениями ошибок, но полностью совместимая с той, что указана в файлеманифесте.

ОБНОВЛЕНИЕЗАВИСИМОСТЕЙ

В Бовере есть команда bower update, но она обновляет пакеты с учетом требований файла-манифеста. Например, если там требуется jQuery ~2.0.0, то он сможет обновить его, например, до 2.0.9, но 2.1.0 уже не поставит, потому что он не соответствует формуле ~2.0.0.

Для обновления пакетов (и bower.json) до действительно последних версий можно воспользоваться bower-update.

Устанавливаем (npm install -g bower-update), запускаем (bower-update) — и вуаля!

ПОИСКПАКЕТОВ

Есть два способа найти пакет в Бовере: гиковский и обычный. Гиковский:

bower search jquery

Search results:

jquery git://github.com/jquery/jquery.git

jquery-ui git://github.com/components/jqueryui

...

Обычный: открыть в браузере bower.io/search/.

АВТОМАТИЧЕСКАЯСБОРКА

Бовер перекладывает проблемы сборки установленных пакетов на плечи разработчика.

Самый легкий способ — просто склеить JS-файлы Грантом, Галпом или любой другой системой сборки, которой ты пользуешься.

Почему не npm

Главное отличие npm и Бовера — подход к установке зависимостей пакетов. Npm устанавливает зависимости для каждого пакета отдельно, в итоге получается большое дерево пакетов (node_modules/grunt/ node_modules/glob/node_modules/…), где может быть несколько версий одного и того же пакета. В клиентском яваскрипте это недопустимо: нельзя подключить на страницу две версии jQuery или любой другой библиотеки. В Бовере каждый пакет устанавливается один раз (jQuery всегда будет в папке bower_components/jquery, сколько бы пакетов

от него ни зависело), и в случае конфликта зависимостей Бовер просто не станет устанавливать пакет, несовместимый с уже установленными.

Я пользуюсь Грантом, поэтому расскажу, как склеивать пакеты им. О том, как пользоваться Грантом, была большая статья в июльском номере прошлого года, поэтому покажу сразу конфиг плагина grunt-contrib-concat:

concat: {

main: {

src: [

'bower_components/jquery/jquery.min.js',

'bower_components/fotorama/….js',

'bower_components/jquery-icheck/….js',

'bower_components/social-likes/

social-likes.min.js',

// DZȞȤȜȣȦȯ ȦȖȢșȗȢ ȥȔȝȦȔ

'scripts/*.js'

],

dest: 'build/scripts.js'

}

}

У этого способа есть много недостатков: тебе нужно смотреть имена файлов для каждого пакета и следить, чтобы файлы собирались в правильном порядке (например, jQuery должен быть выше, чем скрипты, зависящие от него). Плагин grunt-bower-concat (https://github.com/sapegin/grunt-bower- concat) может делать это сам: он автоматически склеивает все установленные зависимости в правильном порядке в один файл:

Cover Story

ŠŤťŖśŢŧŵ ŘŵůŞŠś

Денис Чинин, frontend-разработчик, Immo Smart chininden@gmail.com

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

Что же такое Smart TV? Это интернет

и интерактивные сервисы в телевизоре или телевизионном ресивере, или, вкратце, компьютер в форм-факторе «зомбоящика». Первую попытку реализовать подобие Smart TV предприняла компания Microsoft в далеком 1997 году, но идея провалилась из-за dial-up-соединения и CRT-телевизоров.

Позднее возник другой способ сделать телевизор «умным»: в 2000 году стали появляться устройства Set Top Box (STB) различных производителей, расширяющие функционал стандартного (кабельного, спутникового) ТВ. STB — это обычная телевизионная приставка, принимающая сигнал цифрового телевидения, декодирующая и преобразующая его в аналоговый сигнал

для вывода через разъемы RCA или SCART либо выводящая сигнал через разъем HDMI на телевизор. Но с ростом скорости соединения и новыми технологиями экранов стали появляться телевизоры со встроенным функционалом Smart TV, и с 2009 года

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

визоры, ресиверы цифрового телевидения, Blu-ray-проигрыватели, игровые консоли

и аналогичные им девайсы. Приложения умного ТВ позволяют

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

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

•Если планируешь разработку для моделей 2011 года и старше, то не рассчитывай на помощь CSS3. Вспоминай, как делать

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

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

•Слабая документация у некоторых производителей, а иногда

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

•Для тестирования придется использовать реальные телевизоры. Эмуляторы не повторяют полного функционала устройств

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

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

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

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

•Разнообразие JavaScript API платформ усложнит кроссплатформенную разработку в разы, каждый производитель предоставляет свой API для взаимодействия с внутренним функционалом (проигрывание видео, отображение клавиатуры и прочее).

Ниже краткое описание популярных платформ, чтобы ты знал, с чем придется работать.

Samsung

Samsung сейчас занимает наибольшую долю среди всех телевизоров

споддержкой технологии Smart TV. В моделях 2010 и 2011 года в качестве движка браузера используется MAPLE — сильно измененная версия Gecko, который был в Firefox 3.0. К счастью разработчиков, компания отказалась продолжать изобретать свой велосипед и с 2012 года в теле-

визорах Samsung Smart TV используется WebKit.

Помимо управления с пульта ДУ, в этой платформе можно использовать управление голосом и жестами (начиная с моделей 2012 года), а также подключать привычную мышь и клавиатуру.

Для разработчиков Samsung предоставляет SDK с эмуляторами

и своей средой разработки на базе Eclipse. На сайте есть документация

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

Ключевые возможности API: управление звуком из приложения, получение данных сети и модели, широкие возможности управления плеером.

LG

Отличительная черта этой платформы — возможность использовать Magic Remote, гироскопический анатомический пульт управления. Движение пульта в пространстве сопровождается движением курсора на экране, что очень сильно упрощает навигацию внутри приложений. Из других способов управления — многокнопочный пульт и распознавание голоса. Во всех моделях LG Smart TV используется WebKit,

что значительно сокращает количество «специфичных» багов.

LG предоставляет для разработчиков подробную документацию и SDK с эмуляторами и средой разработки, построенной на основе

Eclipse. У платформы LG есть еще одна особенность — приложение необходимо зашифровать на сайте перед выгрузкой на устройство.

Компания LG является учредителем Smart TV Alliance — это проект, созданный в 2012 году совместными усилиями с TP Vision (компанией, производящей телевизоры под брендом Philips) в целях создания унифицированной платформы приложений для умных телевизоров.

Philips

Достаточно своеобразная платформа. Вторая по объемам продаж в России, но, несмотря на это, разработка для Philips конкретно прокачивает навыки логического мышления, так как документация невероятно скудная :).

Вот что известно про эту платформу:

•До моделей 2012 года вместо HTML необходимо было использовать CE-HTML (специально разработанный стандарт для телевизоров и мобильных устройств на основе XHTML).

•Нет структурированной документации, зато есть примеры и немного статей, из которых можно крупицами собирать информацию.

•Очень плохой эмулятор и отсутствие возможности запустить приложение полноценно в телевизоре. Для тестирования приходится открывать приложение во встроенном в устройство браузере.

Cover Story

Копаемся в ящике

// ȣȟȔȦȨȢȤȠȯ

SB(function(){

App.initialize();

});

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

App.initialize = function () {

this.$wrap = $('.wrap');

// ǯȢȞȔțȯȖȔșȠ ȟșȗșȡȘȧ

$$legend.show();

this.setEvents();

//ǧȔȣȧȥȞȔșȠ ȡȔȖȜȗȔȪȜȲ (Ȗ ȨȢȞȧȥș ȕȧȘșȦ ȣșȤȖȯȝ

//ȖȜȘȜȠȯȝ ȱȟșȠșȡȦ ȥ ȞȟȔȥȥȢȠ nav-item)

$$nav.on();

};

App.setEvents = function () {

var self = this;

// ǮȦȢȕȤȔȚȔșȠ ȥȪșȡȧ ȣȤȜ ȞȟȜȞș ȡȔ ȱȟșȠșȡȦș ȠșȡȲ

$('.menu').on('click', '.menu-item', function(e){

// ǨȠșȡȡȢ țȘșȥȰ Ȝ ȡȧȚșȡ ȔȦȤȜȕȧȦ data-content

var scene = e.currentTarget.getAttribute

('data-content');

self.showContent(scene);

});

$(document.body).on({

//DZȞȤȯȖȔșȠ/ȢȦȢȕȤȔȚȔșȠ ȜȡȦșȤȨșȝȥ ȣȤȜ ȞȟȜȞș

//ȣȢ ȥȜȡșȝ ȞȡȢȣȞș ȣȧȟȰȦȔ ȜȟȜ ȞȟȔȖȜȬș D

//ȡȔ ȞȟȔȖȜȔȦȧȤș

'nav_key:blue': function() {

self.toggleView();

},

// remote events

'nav_key:stop': function () {

Player.stop();

},

'nav_key:pause': function () {

Сцена с инпутами и виртуальной клавиатурой