суббота, 6 декабря 2014 г.

Большое средство малой механизации

Да здравствует лень — величайший двигатель прогресса! Именно благодаря лени древний человек изобрёл колесо и приручил лошадь, не менее ленивые представители населения планеты изобрели и компьютеры. Это, так сказать, эпохальные проявления нежелания самостоятельно выполнять монотонную или тяжёлую работу. Есть и более скромные, но не менее полезные результаты «ленивых» изощрений: застёжка–«молния», пылесос, «крутилка» суши–роллов (как на картинке в начале статьи), гель для бритья, джин, поиск и замена в текстовых редакторах… Вот, только, растворимый кофе напрасно изобретали…

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

Меня тоже частенько накрывает плотной мягкой и тёплой волной ленивости: при малейшем удобном случае стремлюсь автоматизировать рутинные повторяющиеся операции и сформировать максимально комфортную среду для работы. В этой статье речь пойдёт о «малой механизации» в работе с таблицами стилей (CSS) и сценариями–скриптами (JS и jQuery). И выбор пал на систему сборки, оптимизации, проверки и упаковки всего перечисленного добра (и не только!) под игривым названием «Хрюк» (по–английски Grunt) — согласитесь, мечта лентяя (и в смысле функциональности, и, некоторой степени, в смысле названия).

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

Почти сразу образовалась альтернатива «злобному хрюку»: аналогичный пакет и даже с немного похожим английским названием — Gulp. Не то, чтобы я испугался свирепой кабаньей хари, но гораздо ближе по духу оказался «глоток» (по–английски gulp): и с кофе удачно ассоциируется (см. логотип справа), и поновее «хрюка», и те же функции реализованы на более прогрессивной концепции.

Также, как и в случае использования «хрюка», установка «глотка» начинается с установки Node.js — платформы, использующей V8 (движок Google Chrome, исполняющий сценарии Javascript) для запуска скриптов вне браузера. Ничего особенного в процессе установки пакета в Windows нет — запускаешь node-v0.10.33-x86.msi и отвечаешь на типовые вопросы, возникающие при инсталляции любой программы.

Следующий шаг — установка собственно Gulp, и для этого (а также последующей установки gulp–плагинов) используется встроенный в Node.js менеджер пакетов — npm (Node Package Manager). Сначала «гульп» устанавливается глобально. Для этого нужно перейти в каталог проекта, то есть, в папку, в которой будут размещены все ресурсы, из которых Gulp будет «собирать» компоненты для сайта и создать там файл package.json при помощи команды init, ответив на пошаговые вопросы. Если вдруг возникнет чувство неудовлетворённости простотой решения, файл package.json можно сварганить «руками» с использованием текстового редактора.

npm init
npm install --global gulp

Затем этот же пакет нужно установить локально — не спрашивайте, зачем нужна эта двойная инсталляция:

npm install --save-dev gulp

После этого в папке проекта устанавливаются все необходимые для полного счастья gulp–плагины:

npm install --save-dev <имя_плагина>

Я собрал для себя такую «коллекцию»:

  • beepbeep — включение системного звука (аргументы задают количество и продолжительность сигналов);
  • del — удаление файлов;
  • glob — выбор файлов по шаблону (например, *.js);
  • gulp-autoprefixer — добавление префиксов для адаптации CSS–файлов для использования с браузерами, поддерживающими собственный синтаксис (аналогично тому, как это делает Compass);
  • gulp-browserify — сборка исходных файлов со скриптами в один js–файл с контролем корректности синтаксиса языка программирования;
  • gulp-concat — «склеивание» исходных файлов в единый файл;
  • gulp-filesize — определение размера файла;
  • gulp-imagemin — минимизация файла изображения JPG, PNG. GIF и SVG;
  • gulp-livereload — обновление страницы в браузере;
  • gulp-minify-html — мнимизация HTML–файлов;
  • gulp-notify — вывод сообщения;
  • gulp-plumber — предотвращение прерывания потока (pipe) при возникновении ошибки;
  • gulp-rename — переименование файлов;
  • gulp-sass — преобразование SASS/SCSS–файлов в CSS («конкурент» фреймворка Compass, уже развёрнутого на моём компьютере);
  • gulp-sourcemaps — формирование «карт» объединённых файлов для возможности последующей отладки;
  • gulp-uglify — минимизация js–файлов;
  • gulp-uncss — удаление из CSS–файла стилей, не используемых в проекте;
  • gulp-util — вспомогательные функции (вывод сообщения, обработка ошибок, замена расширения файлов и т.п.);

Должен заметить, что некоторые плагины у меня не инсталлировались из виртуальной машины (я использую VMWare Player 6.0.1 build-1379776): попытки установить gulp-uncss, gulp-sass и некоторых других пакетов появлялись «ругательные» сообщения такого вида:

Проблему оказалось довольно просто обойти путём инсталляции тех же пакетов из основной системы (дерево моих проектов доступно и из основной, и из виртуальной систем).

Что касается формирования файла заданий gulpfile.js, который управляет работой Гульпа, то я нахожусь в самом начале пути, поэтому не буду изображать из себя гуру, копируя многочисленные рекомендации и примеры, которые сам нашёл в Сети. Но готов делится с громадой всеми удачными и ошибочными достижениями в этой области — следите за рекламой!

А начать решил с настройки автообновления страницы сайта: при изменение какого–либо из «контролируемых» файлов, состояние страницы в браузере должно немедленно и без дополнительной команды, то есть, самостоятельно обновляться. Для этой цели существует плагин gulp-livereload, но он, похоже, должен работать в тандеме с мини–сервером, предоставляемым другим плагином. Я пытался разобраться в этой спарке, но с налёта у меня не получилось, а долго ломать голову желания не возникло. Поэтому очень кстати оказалось одноимённое расширение к моему браузеру (Mozilla Firefox 34.0). Там же, такое же «удовольствие» имеется и для Google Chrome, и для Safari. Есть такое же расширение и для IE, но придётся разбираться с его установкой, потому что, например, на официальном «мозиловском» сайте предлагается расширение старой версии (и неизвестно, какая версия потребуется для IE).

// Файл gulpfile.js
var gulp = require('gulp'),
    refresh = require('gulp-livereload');

gulp.task('monitor', function(){
  refresh.listen();
  gulp.watch('css/*.css', ['css'])
      .on('change', refresh.changed);
})

Этим скриптом запускается встроенный в gulp-livereload сервер, а встроенная в gulp утилита наблюдения за изменениями файлов (gulp.watch) начинает следить за этими самыми изменениями.

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

> gulp monitor

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

P.S. Менее, чем через месяц предложенный список gulp–плагинов претерпел существенные изменения.

четверг, 4 декабря 2014 г.

Рубиновый механизм

Мало что изменилось за последние несколько столетий в отношении островного государства 日本国 (иероглифы означают «Солнце, начало, страна», то есть, «Страна восходящего Солнца»): как было окутано загадками, тайнами и мистикой «Опоньское царство», так и остаётся по сей день почти эквивалентом Беловодья, Шамбалы, Агартхи и не исключено, что бел–горюч камень Алатырь всё ещё находится там — «на море–окияне, на острое Буяне».

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

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

В общем, Япония так и продолжает оставаться «вещью в себе».

К чему этот географически–исторический экскурс? Дело в том, что в конце предыдущего века, в 1995 году, японский разработчик программного обеспечения опубликовал созданный им язык программирования Ruby, призванный, по замыслу автора, устранить недостатки Perl'а при помощи использования сильных сторон нескольких языков программирования. Свой, более «крепкий» язык Ю.Мацумото назвал «Рубином» (именно так переводится с английского слово ruby), очевидно в противовес «Жемчугу» (английское слово perl читается точно так же, как и pearl — жемчуг). То есть, с намёком на несравненно бо́льшую ценность.

Не исключено, что новый «рубиновый» язык изначально тоже предназначался для «внутреннего потребления» — его описание на английском языке появилось только спустя два года. Но с 1997 года начинается распространение Ruby по планете: был отмечен некоторый начальный всплеск интереса, но невероятной популярности, соответствующей «драгоценному» названию, он не приобрёл, хотя и занял свою нишу рядом с PHP, Python, Java и уже упоминавшимся Perl.

Пока в мои планы не входит переводить свой сайт «Заливная рыба» на Ruby — меня вполне устраивает старый добрый PHP, как бы ни исходили ненавистью к этому языку злопыхатели, — но эта статья возникла по другой необходимости: очень уж мне приглянулась система SASS/SCSS, а реализована она именно на Ruby.

Беглое ознакомление со «стилистически классными таблицами стилей» — так переводится с английского название системы, образующей аббревиатуру SASS — повергло меня в печаль великую: как же я раньше жил без этого «рубинового» механизма? Как можно по–старому верстать сайт, если в CSS–файла можно, оказывается, использовать переменные, вложенность, наследования, функции, подмешивания!

Я ни в коем случае не собираюсь разворачивать на страницах своего блога курсы работы с Ruby или SASS/SCSS: я сам только начинаю осваивать новые возможности по созданию таблиц стилей, а до изучения «Рубина» дело вообще может не дойти. В любом случае, в Сети есть прорва ресурсов, способных рассказать, показать, научить и первому, и второму. А также, третьему и четвёртому: эти самые «третий» и «четвёртый» — фреймворк Compass и система Scout — очень кстати обнаружились в процессе пятидневного разбирательства в ситуации (начитался я до одури всяких публикаций и про «рубин» и «рубинозависимые» приложения, а потом ещё дня три отходил от обилия информации и переваривал её).

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

Ещё более полезным оказался пакет Scout (мне досталась версия 0.7.1 для Windows) «3–in–1», как дерзко и цинично претендующая на звание кофе бурда MacCoffee. Вернее, я получил даже «четыре в одном»: и Ruby, и SASS/SCSS, и Compass и графическая оболочка (честно говоря, GUI можно назвать таковым весьма условно). Более того, всё моё новое достояние даже отдалённо не напоминает MacCoffee.

Установка пакета не занимает много времени и, в принципе, не может составлять какой–либо трудности: запускаешь ScoutAppInstaller-0.7.1.exe и отвечаешь на вопросы оконных диалогов (в какую папку ставить, куда выкладывать иконки и т.п.). В конечном итоге, пользователь получает возможность лицезреть серенькое окошко с заголовком «Scout» в левом верхнем углу и кнопкой со значком «+» в левом нижнем углу (см. скриншот внизу слева). Поскольку никаких иных элементов не наблюдается, шаловливые ручонки, практически без вмешательства головного и спинного мозгов нажимают кнопочку с плюсиком, что приводит к появлению диалога для выбора каталога, в котором размещён проект (см. скриншот справа внизу).

Искушённый читатель, наверное, уже догадался, что мой проект, базирующийся на домене «zaliv.info», располагается в папке с неожиданным именем Zaliv. После этого «Скауту» явно полегчало: он начал деловито собирать сведения о месте, где будут скрываться исходные SCSS–файлы (Input Folder) и куда потом нужно будет складывать результаты обработки «сырья», прошедшего горнило Compass и SASS (Output Folder — оба поля находятся в разделе Stylesheet Directories, см. скриншот внизу). Можно было указать и «Другие каталоги» (Other Directories), то есть, адреса папок, в которых расположены скрипты (Javascripts Folder), изображения (Imagess Folder), — говорят, что Scout с Compass'ом умеют «паковать» не только CSS, — но у меня насчёт всего остального (скрипты, изображения, страницы) были другие планы. Что касается файла конфигурации (Config File), то речь идёт, скорее всего, о тонких настройках работы системы: можно поиграться с различными параметрами, уходящими своими корнями в «рубиновый механизм», но я отложил эти эксперименты «на потом» (а может и «на никогда»).

Есть ещё два блока настроек: один связан с режимом вывода (Output Mode), а второй — с управлнием проектом (Manage Project). Сразу необходимо отметить, что управление проектом в Скауте оформлено очень незатейливо и сводится к его (проекта) удалению: рядом с лейбой «Удалить проект» (Remove Project) располагается кнопка удаления Remove. А вот режимы вывода предлагают выбор: то ли разработчик находится в процессе разработки (Environment:Devolopment в выпадающем списке), то ли формирует окончательный продукт для публикации (Environment:Production), то ли выходные файлы нужны во вложенном виде (Output Style::Nested), то ли развёрнутом (Output Style::Expanded), то ли компактном (Output Style::Compact), то ли сжатом (Output Style::Compressed). Вообще–то, разбираться в некоторых аспектах Скаута довольно непросто: пакет, практически недокументирован и пребывает в непонятном состоянии — ни альфа, ни бета, не говоря уже о пре-релизе. Да, и документация Компаса, хоть и подробна, но коряво организована, то есть, оставляет желать лучшего.

По некоторым косвенным данным можно предположить, что режим конечного продукта (Environment:Production) проводит какие–то более глубокие, трудоёмкие и длительные операции с исходными файлами. Режимы упаковки и сжатия (Output Style::Compact и Output Style::Compressed) удаляют из конечных файлов ненужности и красивости (например, комментарии, форматирующие пробелы и табуляции), что обеспечивает уменьшение размера CSS–файла и, соответственно, время на его загрузку.

«Шаловливые ручонки, нет покоя мне от вас!» Ну, как же утерпеть от проверки работоспособности установленной софтины?! Конечно же, наваял я простенький SCSS–файлик в своём прекрасном Блокноте и сохранил его в папку исходников (Input Folder) как test.scss:

@import "compass/css3"; 
@import "compass/support";

$color : green; 

.panella {
 background-color: $color;
 @include border-radius(25px);
}

Затем я запустил режим обработки SCSS–файла (при помощи кнопки Play в слоте моего проекта на левой панели). Как нетрудно заметить, графическая оболочка в этом месте «сдулась» и на глазах у изумлённой публики появилось традиционное окно для отображения командной строки (вот что я имел ввиду когда писа́л об «условном GUI»). При этом кнопка Play превратилась в кнопку Stop, то есть, Scout заступил на дежурство по наблюдению за изменениями в папке исходящих файлов, а на консоль выведено сообщение о замеченном изменении файла test.scss и его компиляции в файл test.css (на скриншоте внизу — верхние две строчки белым шрифтом на чёрном фоне). Любые попытки внести изменения в файл test.scss (например, удаление пробела) после его пересохранения немедленно обрабатывались системой с перезаписью файла test.css.

А вот так выглядит содержимое файла test.css:

/* line 6, scss/test.scss */
.panella {
  background-color: green;
  -webkit-border-radius: 25px;
  -moz-border-radius: 25px;
  -ms-border-radius: 25px;
  -o-border-radius: 25px;
  border-radius: 25px;
}

Как говорится, насладитесь результатом.

По ходу дела вскочила ещё одна заковыка: любовно настроенный под мои предпочтения Notepad++ взял за моду грубо «ругаться» при каждом сохранении SCSS–файла. Дело в том, что предвкушая дружную и слаженную работу с SASS/SCSS я добавил в плагин jN скрипт Sass-Auto-Compile.js, призванный дело то же самое, что и Scout (тогда ещё Скаут даже не маячил на горизонте). Оказалось, что скрипту для правильной работы необходимо знать путь к интерпретатору Ruby, а в установленном пакете Scout интерпретатор не обнаружен. Перемещение проблемного скрипта в папку disabled проблему ликвидировало (Блокно перестал выбрасывать возмущённые сообщения), но «неприятный осадок остался»: что же я такое установил?

Внимательное исследование лога установки пакета Scout показало, что дополнительно была установлена только среда выполнения Adoba AIR, а вместо Ruby был установлен его Java–клон jruby-complete.jar, и при запуске Scout система вызывает интерпретатор Java.