В статье рассмотрены три модуля для работы под Gulp -

1
gulp-rename
,
1
gulp-notify
,
1
gulp-autoprefixer
.

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

Подготовка проекта

Подготовим проект, создав его базовую основу. Первым файлом создадим файл

1
package.json
и наполним его таким содержимым:

$ touch package.json
  $ cat package.json
  {
    "name" : "three_modules",
    "version" : "0.0.1"
  }

Затем установим локально Gulp.js и укажем

1
npm
, чтобы он внес этот пакет в качестве зависимостей в файл
1
package.json
:

$ sudo npm install --save-dev gulp
  $ cat package.json
  {
    "name": "four_modules",
    "version": "0.0.1",
    "devDependencies": {
      "gulp": "~3.8.8"
    }
  }

Создаем js-файл, в котором будем прописывать задачи для Gulp:

$ touch gulpfile.js
  $ cat gulpfile.js
  var gulp = require('gulp');

  // Default Task
  gulp.task('default', function(){
    // body...
  });

Основа для тестирования отдельных модулей готова.

Gulp-rename - переименование файлов

Задача модуля

1
gulp-rename
предназначена для одной маленькой цели - переименования файлов. Установим модуль с указанием зависимостей:

$ sudo npm install --save-dev gulp-rename
  $ cat package.json
  {
    "name": "four_modules",
    "version": "0.0.1",
    "devDependencies": {
      "gulp": "~3.8.8",
      "gulp-rename": "~1.2.0"
    }
  }

И создадим задачу в файле

1
gulpfile.js
для установленного модуля
1
gulp-rename
:

$ cat gulpfile.js
  var gulp = require('gulp'),
      rename = require('gulp-rename');

  // Rename Task
  gulp.task('rename', function(){
    gulp.src('css/style.css')
    .pipe(rename('pretty_styles.css'))
    .pipe(gulp.dest('build/css/'));
  });

В задаче под именем

1
rename
для Gulp “говориться” следующее: найти файл
1
style.css
-
1
gulp.src('css/style.css')
; переименовать его в имя
1
pretty_styles
-
1
.pipe(rename('pretty_styles.css'))
; переименованный файл положить в папку по пути
1
build/css/
-
1
.pipe(gulp.dest('build/css/'))
.

Запускаю задачу

1
rename
в консоли и вижу, что процесс прошел успешно:

$ gulp rename
  Using gulpfile /media/aaron/application/develop/training/gulp_connect/gulpfile.js
  Starting 'rename'...
  Finished 'rename' after 11 ms

Проверяю, “положил” ли Gulp переименованный файл

1
pretty_styles.css
по пути
1
build/css/
:

$ ls build/css/
  pretty_styles.css

Да, все верно, файл

1
pretty_styles.css
находиться там, где он и должен находиться.

Рассмотренный выше пример очень прост. Более сложные и интересные возможности модуля

1
gulp-rename
показаны на его официальной странице - gulp-rename. А именно - возможности переименования с помощью функций или с помощью префиксов\суффиксов.

Gulp-notify - уведомление о событиях

Установка модуля

1
gulp-notify
выполняется как обычно:

$ sudo npm install --save-dev gulp-notify
  $ cat package.json
  {
    "name": "four_modules",
    "version": "0.0.1",
    "devDependencies": {
      "gulp": "~3.8.8",
      "gulp-rename": "~1.2.0",
      "gulp-notify": "~1.6.0"
    }
  }

Затем создаю задачу

1
notify
, которая будет отслеживать все изменения в файле
1
css/style.css
. Задача информирования об изменениях подразумевает ее использование в фоновом режиме.

Поэтому, создаю еще одну задачу для мониторинга -

1
watch
, которую помещаю в дефолтную задачу
1
default
. В общем случае файл
1
gulpgile.js
будет выглядеть следующим образом:

var gulp = require('gulp'),
  rename = require('gulp-rename'),
  notify = require('gulp-notify');

  // Default Task

  gulp.task('default', ['watch']);

  // Notify Task

  gulp.task('notify', function(){
    gulp.src('css/style.css')
    .pipe(notify('File style.css was changed!'));
  });

  // Watch Task

  gulp.task('watch', function(){
    gulp.watch('css/style.css', ['notify']);
  });

В консоли запускаю Gulp с дефолтной задачей

1
default
:

$ gulp
  Using gulpfile /media/aaron/application/develop/training/gulp_connect/gulpfile.js
  Starting 'watch'...
  Finished 'watch' after 8.79 ms
  Starting 'default'...
  Finished 'default' after 7.97 μs

Теперь вношу в файл

1
css/style.css
изменения и сохраняю их. На Рабочем столе мгновенно появляется всплывающее окно с уведомлением о внесенных в файл
1
css/style.css
изменениях. Не знаю, как в других системах, но на Linux Mint 17 Cinnamon это окошко выглядит очень симпатично.

На странице GitHub автора модуля представлены более интересные примеры создания и использования

1
gulp-notify
.

Gulp-autoprefixer - браузерные префиксы

Интересный модуль

1
gulp-autoprefixer
для управления браузерными префиксами в проекте. Задача у него - не просто устанавливать префиксы для тех CSS3-свойств, которые нуждаюся в этом на данный момент (другими словами - для включения их поддержки в браузерах).

С помощью

1
gulp-autoprefixer
можно управлять “глубиной” версий браузеров, которые должны поддерживать работу конкретного проекта. Другими словами, можно указать модулю
1
gulp-autoprefixer
, что необходимо отслеживать поддержку префиксов только в двух последних версиях каждого (из всех существующих) браузера -
1
last 2 versions
(кстати, это значение по умолчанию для данного модуля).

Или же учитывать только две последние версии браузера Google Chrome -

1
last 2 Chrome versions
. При задании префиксов можно учитывать глобальную статистику использования браузера -
1
> 5%
(если брузер используют больше 5% населения Интернет).

Модуль

1
gulp-autoprefixer
использует собственные имена для браузеров при задании параматров работы своей работы. С полным списком еще более интересных возможностей для задания выборки браузеров можно (и нужно) ознакомиться на странице GitHub.

Работа модуля

1
gulp-autoprefixer
основана на известном ресурсе Can I Use. Именно оттуда он берет инормацию о поддержке браузерами того или иного CSS3-свойства на данный момент. Кстати, известный фреймворк Compass также основывается на Can I Use при работе со своими миксинами (mixin).

Сервис Can I Use

Помимо этого, модуль

1
gulp-autoprefixer
умеет красиво форматировать CSS-свойства с браузерными префиксами в виде визульного каскада:

a {
-webkit-box-sizing: border-box;
   -moz-box-sizing: border-box;
        box-sizing: border-box;
}

За такую возможность отвечает параметр

1
cascade
, который включен по умолчанию в данном модуле. Вообще, по умолчанию модуль
1
gulp-autoprefixer
имеет такие параметры в виде массива (array):
1
> 1%, last 2 versions, Firefox ESR, Opera 12.1
.

Вступление было достаточно долгим и подробным - это потому, что модуль

1
gulp-autoprefixer
интересный и нужный. Приступаю к его установке:

$ sudo npm install --save-dev gulp-autoprefixer
  $ cat package.json
  {
    "name": "four_modules",
    "version": "0.0.1",
    "devDependencies": {
      "gulp": "~3.8.8",
      "gulp-rename": "~1.2.0",
      "gulp-notify": "~1.6.0",
      "gulp-autoprefixer": "~1.0.0"
    }
  }

Создаю задачу

1
autoprefixer
с описанием того, что нужно отслеживать изменения в файле
1
css/style.css
и при добавлении в него CSS3-свойств преобразовывать их в свойства с браузерными префиксами. При этом учитывать только две последние версии браузеров и результат помещать по пути
1
build/css/
.

var gulp = require('gulp'),
  autoprefixer = require('gulp-autoprefixer');

  // Autoprefixer Task

  gulp.task('autoprefixer', function(){
    gulp.src('css/style.css')
    .pipe(autoprefixer({
      browsers: ['last 2 versions']
    }))
    .pipe(gulp.dest('build/css/'));
  });

Внесу в файл

1
css/style.css
CSS3-свойство
1
transform
, которое заведомо нужно использовать с префиксами (для этого я заранее “подглядел” его на “Can I Use”):

.block {
  width: 100px;
  height: 100px;
  background-color: #778899;
  transform: rotate(7deg);
  }

Запускаю задачу

1
autoprefixer
и смотрю результат:

.block {
  width: 100px;
  height: 100px;
  background-color: #778899;
  -webkit-transform: rotate(7deg);
          transform: rotate(7deg);
  }

Все четко - под условие “не ниже второй версии” попали только браузеры на движке Webkit - можно свериться здесь.

Можно немного “углубить” условие и “опуститься” до третьей версии всех браузеров:

// Autoprefixer Task

  gulp.task('autoprefixer', function(){
    gulp.src('css/style.css')
    .pipe(autoprefixer({
      browsers: ['last 3 versions']
    }))
    .pipe(gulp.dest('build/css/'));
  });

… и посмотреть результат:

.block {
  width: 100px;
  height: 100px;
  background-color: #778899;
  -webkit-transform: rotate(7deg);
      -ms-transform: rotate(7deg);
          transform: rotate(7deg);
  }

Вывод в

1
build/css/style.css
красивый благодаря
1
cascade
, который можно и отключить, установив
1
cascade: false
.


Сегодня по подписке мне на почту пришла ссылка на статью “Bootstrap’s Grid System vs. Susy: A Comparison”. Пришла как нельзя кстати - я сам задавался для себя таким вопросом - что лучше выбрать для себя в качестве системы построения разметки (grid system) - мега-популярный Bootstrap или менее популярную, но более гибкую и функциональную Susy? И вот пожалуйста - сравнительное описание уже готово - осталось его только прочитать!

Более того, c автором статьи Zell Liew я заочно знаком - на моем бложике есть переводы его статьей по теме Susy: “Краткое руководство по Susy 2”, “Краткое введение в Susy 2 (Часть 2)”, “Статические сетки с помощью Susy 2”. Более того, к этому времени он уже успел написать собственную книгу, посвященную Susy - Learning Susy.

Как мне кажется, данная статья является нужной и своевременной, как нельзя кстати. Естественно, я не мог удержаться от того, чтобы не прочитать и не сделать ее вольный перевод (для себя и возможно - для читателей).

Введение

На сегодняшний день существует достаточно систем построения разметки (grid system), которые можно выбрать для своей работы. Из всего множества фреймворком подобного типа одним из самых любимых и самых ненавидимых определенно является Bootstrap.

Сегодня я хотел бы представить вашему вниманию менее известный фреймворк - Susy. В этой статье я сделаю сравнение между системами построения разметки (grid system) Susy и Bootstrap. Благодаря этой статье читатель может четко уяснить для себя, что собой представляет Susy и можно ли ее использовать на практике.

Что такое Susy

Для того, чтобы ответить на этот вопрос, нужно сначала ответить на другой вопрос - “Что такое grid (CSS-сетка)?”

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

Система сеток (grid system) на web-странице

Эти вертикальные линии помогают выполнить задачу разделения всего пространства web-страницы на два вида полос. Более широкий вид полосы называется колонкой (column), а более узкий - канавкой (gutter). Организация и расположение элементов страницы “привязывается” к этим колонкам (columns) и канавкам (gutters):

Колонки (columns) и канавки (gutters) в Grid System

Систему сеток (grid system), описанную выше, используют множество CSS-фреймворков. Наиболее известные (в качестве примера) из них:

  • 960 grid system
  • 1140px grid system
  • Bootstrap
  • Foundation

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

Susy является движком для создания разметки web-страницы (layout). Это набор инструментов, с помощью которых можно создать произвольную CSS-сетку (grid), которая отвечает потребностям дизайна конкретной web-страницы. Susy предоставляет в ваше распоряжение гибкость и свободу действий в web-разработке.

Что такое Bootstrap

Bootstrap - это больше, чем просто фреймворк для создания CSS-сетки (grid) разрабатываемой web-страницы. Это полноценный набор инструментов, имеюший в своем составе большое количество самых разнообразных возможностей для создания web-страницы:

  • система построения разметки (grid system);
  • готовые CSS-стили для большинства стандартных элементов web-страницы, таких как навигация, формы, иконки;
  • готовые jQuery-плагины для сложных элементов web-страницы, таких как аккордеон или карусель.

Теперь, когда стала ясна разница между Susy и Bootstrap, становится понятно, что невозможно сравнивать между собой два таких разных программных продукта. Основа у этих инструментов совершенно разная.

Тем не менее, в дальнейшей части этой статьи будет произведено детальное сравнение между Susy и системой построения разметки (grid system) фреймворка Bootstrap. Между ними все же существует несколько общих черт, по которым можно произвести аналогию:

  • Язык используемого препроцессора
  • Способ создания разметки (markup)
  • Возможность редактирования CSS-сетки
  • Возможность настройки breakpoints
  • Взаимосвязь HTML и CSS
  • Документация и сообщество

Язык используемого препроцессора

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

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

Последняя версия Susy (Susy 2) работает только совместно с Sass версии 3.3. и выше, потому что для Susy 2 необходима поддержка Sass-карт Sass maps. Предыдущая более ранняя версия “Susy One” использует для своей работы Sass ниже версии 3.3. К сожалению, Susy не подерживает Less.

Способ создания разметки (markup)

Чтобы увидеть разницу в способе создания разметки (markup) web-страницы, давайте создадим простой пример:

Пример разметки (markup) страницы

Фреймворк Bootstrap требует использования в обязательном порядке классов наподобие

1
.row
или
1
.col-md-4
при создании разметки страницы - для того, чтобы к HTML-документу смогли примениться CSS-стили.

Вышеупомянутое требование является наиболее критикуемым моментом в Bootstrap. Противники Bootstrap заявляют, что все подобные классы относятся к репрезентационным и им не место в HTML-разметке страницы.

Ниже приведен пример кода, с помощью которого создается разметка на Bootstrap - со всеми необходимыми классами в данном случае. Дополнительно применены классы, относящиеся непосредственно к системе построения разметки (grid system):

<div class="container-fluid">
  <div class="row">
    <div class="col-md-8 content">
      <h2>
        Content
      </h2>
    </div>
    <div class="col-md-4 sidebar">
      <h2>
        Sidebar
      </h2>
    </div>
  </div>
</div>

Для сравнения, ниже приведен код на Susy для создания аналогичной разметки (markup):

<div class="wrap">
  <div class="content">
    <h2>
      Content
    </h2>
  </div>
  <div class="sidebar">
    <h2>
      Sidebar
    </h2>
  </div>
</div>

Как хорошо видно, разметка на Susy гораздо проще и более семантичная, нежели аналогичная разметка на Bootstrap. Однако, создание разметки с помощью Susy на этом не заканчивается - необходимо добавить CSS-стили для классов

1
content
и
1
sidebar
, чтобы они применились к создаваемой HTML-разметке. Поэтому давайте выполним небольшую стилизацию с помощью этих классов с тем, чтобы показать, как работает Susy.

Первое, на что необходимо обратить внимание, так это тот факт, что Bootstrap добавляет канавки (gutters) в качестве CSS-свойства

1
padding
по обе стороны каждой колонки (column) в CSS-сетке:

Канавки (gutters) в Bootstrap

По умолчанию, Susy “прилепляет” канавку (gutter) в качестве CSS-свойства

1
margin
только с одной (правой) стороны каждой колонки (column). Для того, чтобы изменить поведение Susy на точно такое же, как в Bootstrap, необходимо изменить значение переменной
1
gutter-position
в Sass-карте
1
#susy
:

$susy: (
  gutter-position: inside
)

Примечание переводчика - автор немного “поскромничал”, не сказав, что у него имеется своя собственная статья, посвященная позиционированию gutter в Susy - “Understanding Gutter Positions in Susy”.

В каждой CSS-сетке, создаваемой с помощью Susy, к классу

1
.container
необходимо применить миксин
1
container
. В рассмотренном выше примере вместо класса
1
.container
используется класс
1
.wrap
в качестве класса у блока-обертки, имеющей максимальную ширину в 1140px:

.wrap {
  @include container(1140px);
}

В предыдущем случае, когда выполнялась разметка с помощью Bootstrap, выделялись 8 колонок (columns) под контент и 4 колонки (columns) под блок с классом

1
.sidebar
. При создании разметки на Susy необходимо воспользоваться миксином
1
span
, с помощью которого можно создать 8 колонок для блока с классом
1
.content
и 4 колонки для блока с классом
1
.sidebar
:

.content {
  @include span(8 of 12);
}

.sidebar {
  @include span(4 of 12);
}

Разметка на Susy более простая, нежели на Bootstrap. Однако, обратной стороной этой простоты является факт, что придется выполнить больше работы по подключению миксинов и общей настройке классов. В то время как Bootstrap предоставляет все необходимые классы в готовом виде.

Возможность редактирования CSS-сетки

Bootstrap предоставляет возможность редактирования системы построения разметки (grid system) только в ограниченных пределах. Имеется возможность свободно изменять такие вещи, как:

  • количество колонок (columns)
  • размер канавки (gutter)
  • значения четыре доступных breakpoints (
    1
    xs
    
    ,
    1
    sm
    
    ,
    1
    md
    
    ,
    1
    lg
    
    )

Все вышеперечисленные параметры можно настроить двумя способами:

  • выполнить конфигурирование на вкладке “Customize and download” официальной страницы Bootstrap прежде, чем скачивать готовый дистрибутив
  • если используется любой из препроцессоров (Sass или Less), то изменить значения соответсвующих переменных
    1
    _variables
    

В обоих случаях, настройки для колонок (columns) и канавок (gutters) находятся в разделе с названием Grid System; настройки для медиа-запросов (media queries) находятся в разделе под названием Media Queries Breakpoints.

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

  • количество колонок (columns)
  • размер каждой из колонки в отдельности
  • размер канавки (gutter)
  • позиционирование канавок (gutters)
  • количество breakpoints
  • направление потока слева направо или справа налево
  • блочную модель (box model)

… и еще много чего.

Наподобие других систем для построения разметки (grid system), таких как Singularity или GridsetApp, которые наиболее часто применяются для постороения ассиметричной разметки (asymmetric layout), Susy также умеет создавать ассиметричные CSS-сетки. Хорошие примеры построения таких сеток размещены здесь:

  • The Marber - Gridset
  • The Gerstner - Gridset
  • Typekit + Gridset Demos

Примечание переводчика - у автора статьи на его официальном сайте имеется статья, посвященная созданию ассиметричной разметки на Susy - “Creating Asymmetric Layouts With Susy”.

Одна из таких сеток, созданная Nathan Ford мне нравиться и я сделал аналогичный вариант ассиметричной разметки с помощью Susy. Теперь нет необходимости применять какую-либо стандартную систему построения разметки (grid system) - Susy может удовлетворить всем требованиям разработчика.

Примечание переводчика - автор статьи использовал online-инструмент SassMeister для написания кода под препроцессор Sass. Если данный вопрос незнаком читателю, то можно обратиться к ссылке - “Знакомимся с редактором SassMeister”.

Возможность настройки breakpoints

Как уже упоминалось ранее, Bootstrap имеет возможность применения в создаваемой разметке до 4 контрольных точек (breakpoints):

1
xs
,
1
sm
,
1
md
,
1
lg
. Эти breakpoints заранее определены в фреймворке Bootstrap

В рассматриваемом нами примере, если попробовать уменьшить размер окна браузера меньше 991px, то блок с классом

1
.content
займет всю ширину блока-родителя; блок с классом
1
.sidebar
переместиться вниз и также займет всю ширину.

Предположим, что возникла задача сделать так, чтобы оба блока с классами

1
.content
и
1
.sidebar
занимали каждый ровно половину окна браузера при уменьшении его размеров ниже 991px:

<div class="container-fluid">
  <div class="row">
    <div class="col-xs-6 col-md-8 content">
      <h2>
        Content
      </h2>
    </div>
    <div class="col-xs-6 col-md-4 sidebar">
      <h2>
        Sidebar
      </h2>
    </div>
  </div>
</div>

Если точно такую же задачу выполнять с помощью Susy, то в этом случае изменения коснуться CSS вместо HTML, как в первом случае. HTML-разметка останется прежней и в нее не будет ничего добавлено:

<div class="wrap">
  <div class="content">
    <h2>
      Content
    </h2>
  </div>
  <div class="sidebar">
    <h2>
      Sidebar
    </h2>
  </div>
</div>

В данном случае необходимо добавить контрольную точку

1
breakpoint
в Sass-файл.

При создании такой контрольной точки

1
breakpoint
имеет смысл выполнить подход по принципу “Mobile First” и сначала задать стилевые правила для блоков
1
.content
и
1
.sidebar
таким образом, чтобы они занимали ровно половину окна браузера каждый. При увеличении размера окна (больше чем 991px) блок с классом
1
.content
станет занимать 8 колонок, а блок с классом
1
.sidebar
- 4 колонки от общего пространства окна браузера:

.content {
  @include span(6 of 12);
  @media (min-width: 980px) {
    @include span(8 of 12);
  }
}

.sidebar {
  @include span(6 of 12);
  @media (min-width: 980px) {
    @include span(4 of 12);
  }
}

Bootstrap требует аккуратного обращения с именами CSS-классов при создании HTML-разметки. Когда создается проект на Bootstrap, мне всегда приходиться помнить точные имена классов для контрольных точек.

В Susy наоборот - весь процесс кодинга перемещается из области HTML-документа в область Sass-файла, в котором также необходимо соблюдать осторожность. Я предпочитаю размещать контрольные точки (breakpoints) именно в таблице стилей, так как в этом случае общая картина проекта становиться более наглядной для меня.

В зависимости от предпочтений, можно использовать Bootstrap или Susy - оба они хорошо выполняют свою задачу построения разметки. Лично я предпочитаю Susy, так как в этом случае имется возможность “разъединить” HTML и CSS между собой. Данный факт плавно приводит меня к следующему вопросу.

Взаимосвязь HTML и CSS

На сегодняшний день почти все сайты в Интернет содержат в себе массу кода на HTML и CSS. И чем плотнее взаимосвязь между двумя этими типами файлов, тем сложнее выполнять поддержку таких сайтов.

Просто представим на минуту то время, когда весь CSS-код размещался внутри HTML-кода с помощью атрибута

1
style
. Использование классов Bootstrap наподобие
1
.col-xs-6
,
1
.col-md-4
или
1
.row
аналогично использованию атрибута
1
style
в HTML-документе.

Если в HTML-документе имеется множество элементов, которые требуют специфической разметки с помощью классов

1
.col-
, то количество случаев, когда придется воспользоваться такими классами значительно возрастает. Что, если возникла задача изменить дизайн таким образом, чтобы блок с классом
1
.content
занимал не 8 колонок (columns), а 7 колонок (columns)? Потребуется изменить имя класса везде, где оно встречается внутри HTML-документа:

<div class="col-md-7 content">
  <h2>
    Content
  </h2>
</div>

Становиться понятно высказывание о том, что HTML и CSS-файлы с такой тесной взаимосвязью очень тяжело поддерживать.

Лично я предпочитаю использовать Susy и размещать все презентационные классы во внешнем CSS-файле, там где они и должны находиться. Например, при ипользовании Susy, если необходимо изменить размер блока с классом

1
.content
до 7 колонок, то для этого достаточно изменить всего лишь один миксин
1
span
:

.content {
  @include span(7 of 12);
}

Как мне кажется, выполнять поддержку HTML и CSS-файлов, взаимосвязанных подобным образом, гораздо легче.

Так как благодаря Susy появляется возможность свободного управления HTML и CSS-файлами, то можно применить на своей практике любую из популярных CSS-методологий, таких как SMACSS, OOCSS или BEM. При этом отпадает необходимость заботиться о том факте, каким образом любая из этих методологий будет взаимодействовать с вашим конкретным HTML-файлом.

Документация и сообщество

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

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

Напротив, документация по Susy не такая детальная; а сообщество (пока) не слишком большое. При изучении возможностей Susy и способов создания web-сайтов на основе этого фреймворка могут возникнуть проблемы, которые и отталкивают многих от перехода с Bootstrap на Susy. Для того, чтобы попробовать устранить этот недостаток, мною написана книга “Learning Susy”. Всем интересующимся можно ознакомиться с ней.

Заключение

Несмотря на тот факт, что Bootstrap и Susy являются совершенно различными инструментами, в этой статье мы смогли произвести сравнение между системами построения разметки (grid system) обоих фреймворков. Как я уже упоминал ранее, у меня есть твердое убеждение в том, что Susy является гораздо более удобным инструментом для создания разметки.

Если вы заинтересовались возможностью дальнейшего изучения Susy, посетите официальный сайт этого проекта, почитайте документацию к этому фреймворку или скачайте бесплатно “5 глав из моей книги”.


Продолжаю увлекательное знакомство новичка с сервисом GitHub и с системой контроля версий Git.

Так как имею учетную запись на GitHub, которую регулярно использую, то у меня возник вопрос, который не мог не возникнуть, рано или поздно. Касается он такой темы, как fork.

Не знаю даже, как правильно поступить дальше - попытаться самому описать вопрос, своими словами; или же попытаться сделать вольный перевод статьи на эту тему - Fork A Repo. Но лучше все же расскажу своими словами.

Fork - это копия репозитория

Fork - это вcего навсего копия репозитория. Это тоже самое, что branch в Git. Только на GitHub такой branch называется

1
fork
- присутствует своя терминология. Само слово fork в переводе означает ответвление. Для того, чтобы воспользоваться
1
fork
, нужно иметь свою собственную учетную запись на GitHub; и нужно войти под ней на GitHub в момент выполнения
1
fork
.

Для чего нужен

1
fork
? Для тех же целей, что и branch в Git. С помощью него создается точная копия оригинального репозитория, только на сервисе GitHub. В копии репозитория можно вносить свои собственные изменения, редактировать файлы или удалять директории.

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

1
pull request
.

Если авторам оригинального репозитория ваши изменения понравятся, то они могут внести их в свой собственый оригинальный репозиторий - принять запрос и выполнить слияние.

Существование fork полностью отвечает идеологии OpenSource и GitHub, в частности. Идеология OpenSource заключается в свободном обмене исходным кодом программ и fork однозначно помогает в этом деле. С помощью fork можно одним движением получить копию любого исходного кода, выложенного на GitHub в свободном доступе.

Fork - создание копии репозитория

Давайте от слов перейдем к делу и на практике выполним хотя бы один fork на GitHub. К слову сказать, в приведенной выше статье-оригинале Fork A Repo дается ссылка на репозиторий Spoon-Knife, созданный авторами статьи для учебных целей - научиться работать с fork на GitHub. Вы, уважаемый читатель, также можете свободно воспользоваться им для себя, чтобы научиться пользоваться fork.

Я воспользуюсь другим репозиторием, который выложен в свободном доступе достаточно известным верстальщиком Юрием Артюхом (akella). Ниже привожу шаги по созданию Fork на GitHub.

  • захожу на GitHub под своей учетной записью
  • перехожу по ссылке github/akella/sass, по которой расположен репозиторий akella/sass

Репозиторий akella/sass на GitHub

Фактически, теперь я нахожусь в репозитории akella/sass пользователя akella (Юрий Артюх). Об этом красноречиво говорит надпись akella/sass в левом верхнем углу окна браузера. В правом верхнем углу окна браузера нахожу кнопку Fork.

И нажимаю на нее:

Выполненный fork репозитория akella/sass

Может случиться, что вы, уважаемый читатель, ничего и не заметите. Но это не так на самом деле. Приглядитесь к “главной” надписи - она изменилась с

1
akella/sass
на
1
gearmobile/sass
; а ниже мелким шрифтом еще -
1
forked from akella/sass
. Думаю, тут и говорить больше нечего - все и так понятно.

Теперь этот репозиторий мой - точнее, у меня теперь копия оригинального репозитория

1
akella/sass
. Я могу делать с ним все, что мне понадобиться - просто пользоваться или же вносить свои собственные изменения.

Если изменения мне покажутся существенными, то я могу отправить пользователю akella запрос на слияние

1
pull request
моего репозитория
1
gearmobile/sass
с его репозиторием
1
akella/sass
. Если пользователь akella посчитает эти изменения действительно существенными (с его точки зрения), то он может и принять мой запрос.

Я также могу удалить репозиторий gearmobile/sass, если в нем отпадет надобность. Надеюсь, вы хорошо помните, как удалять репозиторий на GitHub - “Как удалить репозиторий на GitHub”.

Продолжаю совместно с вами постепенно изучать магию Git\GitHub.

Слово магия здесь применено не случайно - не иначе, как магией возможности Git\GitHub не назовешь. По крайней мере, я впечатлен этими возможностями. Другое дело, что процесс изучения Git у меня лично идет как-то тяжеловато. Ну, это не страшно - главное, не останавливаться!

В этом разделе я попытаюсь осветить для себя (и возможно, для вас, уважаемый читатель) вопрос создания ветвей (branches) в Git, перемещение между ветвями (branches), слияние (merge) ветвей. Этот вопрос очень подробно и хорошо описан на странице официальной документации - “Git Branching - Basic Branching and Merging”. Здесь я попробую самостоятельно описать данный вопрос.

Инициализация Git-репозитория

Создаю тестовую директорию

1
git_branches
, в которой будут производиться эксперименты по созданию ветвей в Git. Внутри этой директории создаю два файла - индексный файл и файл таблиц стилей. А затем инициализирую Git-репозиторий, добавляю созданные файлы под версионный контроль Git:

$ mkdir git_branches
$ cd git_branches
$ touch index.html
$ touch style.css

$ git init
Initialized empty Git repository in /home/username/Desktop/projects/git_branches/.git/

$ git add .
$ git commit -m 'first launch'
[master (root-commit) eeb12ca] first launch
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html
 create mode 100644 style.css

$ git status
On branch master
nothing to commit, working directory clean

Обратите на строку

1
On branch master
в выводе команды
1
git status
. Это не пустой набор служебной информации - здесь говориться о том, что в ветви
1
master
нечего фиксировать и рабочая директория чистая.

Итак, мы уже кое-что узнали. А именно - при инициализации Git-репозитория была автоматически создана ветвь (branch) по имени

1
master
. И на данный момент мы находимся в этой ветви.

Конечно, на самом деле это пока мало о чем говорит, так как не с чем сравнивать. Поэтому давайте я немного отредактирую оба файла

1
index.html
и
1
style.css
, проиндексирую\зафиксирую их.

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

Git - ветвь (branch) master

Git - создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

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

Давайте я на практике осуществлю вышесказанные действия. Для этого создаю новую ветвь с произвольным именем

1
second
, которая на этом этапе будет точной копией ветви
1
master
:

$ git checkout -b second
  Switched to a new branch 'second'

Строка

1
Switched to a new branch 'second'
услужливо информирует, что меня автоматически “перебросило” во вновь ветвь
1
second
. Можно проверить себя, набрав в консоли:

$ git status
  On branch second
  nothing to commit, working directory clean

Строка

1
On branch second
говорит сама за себя.

Отлично! Теперь давайте я внесу некоторые изменения в файлы

1
index.html
и
1
style.css
и мы вместе посмотрим на результат в окне браузера. Изменения будут касаться добавления блока-обертки, еще нескольких параграфов и другой легкой стилизации.

Не забуду также проиндексировать и зафиксировать внесенные изменения. Обратите внимание на вид команды -

1
git commit -a
. Эта команда является сокращенным вариантом двух команд:
1
git add
и
1
git commit -m
. Применяется, когда нужно “проскочить” этап индексирования и сразу зафиксировать изменения.

$ git commit -a -m 'Modify Brach Second'
  [second e4b5d5d] Modify Brach Second
  2 files changed, 24 insertions(+), 14 deletions(-)
  rewrite index.html (72%)

Смотрим, что у нас получилось в окне браузера - то, что и ожидалось:

Git - ветвь (branch) second

Git - переключение между ветвями (branches)

А теперь настал самый интересный момент. Как вы помните, мы сейчас находимся в ветви

1
second
. Давайте я переключусь в ветвь
1
master
и мы снова посмотрим в окно браузера:

$ git checkout master
  Switched to branch 'master'

Git - ветвь (branch) master

Оп! Мы видим старую картину - Git “запечатлел” тот момент, когда мы совершили переход из ветви

1
master
в ветвь
1
second
. Другими словами, мы вернулись в последнее зафиксированное состояние ветви
1
master
:

$ git log --pretty=oneline
  b7105dab98d2f3798b5456c35695a4e906a80e92 Master Branch
  eeb12ca79f224af90cd31cf470143998a6312249 first launch

Если я снова вернусь в ветку

1
second
и запущу команду просмотра логов Git, то коммитов окажется больше:

$ git checkout second
  Switched to branch 'second'

  $ git log --pretty=oneline
  e4b5d5df7a4b9a3ee56a7298726bdab4691a5a58 Modify Brach Second
  b7105dab98d2f3798b5456c35695a4e906a80e92 Master Branch
  eeb12ca79f224af90cd31cf470143998a6312249 first launch

Мне кажется, уже сейчас должно быть понятно, что такое ветви (branches) в Git и для чего они предназначены. На самом деле это действительно очень просто.

Git - слияние ветвей (branches)

В предыдущем шаге я создал ветвь

1
second
, в которую внес “рискованные” изменения, чтобы проверить, “оправдают” ли они себя. Изменениями я доволен и хотел бы добавить их в первоначальную ветку
1
master
, чтобы потом продолжить развитие проекта уже с этого места.

Фактически, я хочу сделать слияние двух веток -

1
master
и
1
second
. Это сделать очень просто - для этого я перехожу в ветку
1
master
. То есть, я должен находиться в той ветке, в которую я вношу изменения из другой ветки. А затем произвожу само слияние:

$ git checkout master
  Switched to branch 'master'

  $ git merge second
  Updating b7105da..e4b5d5d
  Fast-forward
   index.html | 8 ++++++--
   style.css  | 6 ++++++
   2 files changed, 12 insertions(+), 2 deletions(-)

Команда слияния проста - я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.

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

Давайте снова “заглянем” в окно браузера - что он нам интересного покажет?

Git - результат слияния двух ветвей master и second

Показал он то, что и следовало показать - результат объединения двух ветвей

1
master
и
1
second
.

Git - графическое представление ветвей (branches)

Система Git имеет в своем составе возможность графического представления ветвления в репозитории. Причем, такое представление можно сделать даже в консоли, с помощью псевдографики.

Это можно сделать, набрав в консоли команду:

$ git log --oneline --abbrev-commit --all --graph

На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды

1
git log
:

Красивая псевдографика команды git log

Красивая псевдографика команды git log

На самом деле вариантов использования команды

1
git log
с ключом
1
--graph
бесчисленное множество. Поэтому нужно выбирать именно то, что нужно и нравиться именно вам.

Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux - Gitk или Gitg:

Приложение Gitg под Linux

Git - удаление ветви (branch)

В разделе слияния ветвей в Git я научился процессу объединения двух ветвей в одну. Такой процесс в Git имеет название

1
merge
(слияние). Теперь ветвь
1
master
имеет в себе все, что есть и в ветви
1
second
. Поэтому ветвь
1
second
можно удалить.

Выполняется это командой:

$ git branch -d second
  Deleted branch second (was 19a8328).

Посмотрим на вывод команды

1
git hist
:

$ git hist
  * fa8b252 2014-09-03 | Last Commit in Master Branch (HEAD, master)
  *   22a9487 2014-09-03 | Merge Second Branch in Master Branch (origin/master, origin/HEAD)
  |\
  | * 19a8328 2014-09-03 | Six Commit in Second Branch
  | * e273e6c 2014-09-03 | Fifth Commit in Second Branch
  | * 8e2fe40 2014-09-03 | Fourth Commit in Second Branch
  | * 3290a23 2014-09-03 | Third Commit in Second Branch
  | * 0584a1c 2014-09-03 | Second Commit in Second Branch
  | * 38fab33 2014-09-03 | First Commit in Second Branch
  * | 8543256 2014-09-03 | Seventh Commit in Master Branch
  * | e852688 2014-09-03 | Six Commit in Master Branch
  * | d6ccde3 2014-09-03 | Fifth Commit in Master Branch
  * | c0d8e2f 2014-09-03 | Fourth Commit in Master Branch
  * | 7d2377a 2014-09-03 | Third Commit in Master Branch
  |/
  * b3e0f1f 2014-09-03 | Second Commit in Master Branch
  * be4e1f0 2014-09-03 | First Commit in Master Branch
  * ac2961a 2014-09-03 | Added git_branches
  * db9e01b 2014-09-03 | Initial commit

У меня осталась одна ветвь -

1
master
.


Еще один важный практический вопрос при работе с Git - это операции с файлами.

В частности, это операции удаления и переименования файлов. В системе Git имеются специальные команды, которые очень похожи на консольные команды

1
rm
и
1
mv
в Linux/Mac OS. Но для Git они выглядят несколько иначе:
1
git rm
- для удаления файлов и
1
git mv
- для переименования файлов. Ниже я рассмотрю обе эти комадны более подробно.

Команда git rm

Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда

1
git rm
. Ее отличие от обычной консольной команды
1
rm
(в том же Linux) заключается в особенности самой системы Git.

Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.

Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:

$ rm index.html
$ git add .
$ git commit -m 'Delete file index.html'

Команда

1
git rm
является ни чем иным, как “вшитым” в Git сокращением двух первых команд:

$ rm index.html
$ git add .

Сделано это всего лишь для удобства пользования системой Git. Давайте на примере посмотрим работу команды

1
git rm
. Предположим, что имеется файл
1
index.html
, который проиндексирован и зафиксирован.

Удалим его командой

1
git rm
:

Команда git rm - удаление файлов в Git

Видим, что файл

1
index.html
был сразу удален из двух областей: рабочего каталога “Working Directory” и области индексации “Staging Area”. Но в репозитории файл все же остался, о чем говорит вывод команды
1
git status
.

Любой последующий commit зафиксирует удаление этого файла:

Фиксация удаления файла командой git rm

Команда git rm -cached

У команды

1
git rm
имеется пара полезных ключей, одним из которых является ключ
1
--cached
. Задача этого ключа - позволить команде
1
git rm
удалить файл из области индексирования “Staging Area”, но при этом оставить его в области рабочего проекта “Working Directory”. Давайте рассмотрим пример, когда создан файл
1
second.html
и произведена его индексация (но не фиксация):

Созданный файл second.html

Удалим его командой

1
git rm --cached
:

Команда git rm -cached

Отлично! Видим, что произошло удаление файла

1
second.html
. Кроме того, команда
1
git status
показывает, что в рабочей области “Working Directory” имеется неотслеживаемый (untracked) файл по имени
1
second.html
.

Команда git rm -f

В предыдущем разделе я рассмотрел вариант, когда созданный и проиндексированный файл удаляется из области индексирования “Staging Area”, но остается в области “Working Directory”. Выполняется это с помощью команды

1
git rm --cached
.

Логическим продолжением этой команды является та же самая команда

1
git rm
, но с ключом
1
-f
-
1
git rm -f
. Такая команда удаляет проиндексированный (но еще не зафиксированный) файл как из области “Staging Area”, так и из области “Working Directory”.

Давайте рассмотрим на примере созданного и проиндексированного файла

1
third.html
его удаление с помощью команды
1
git rm -f
:

Созданный файл third.html

Команда git rm -f

Файл

1
third.html
удален как из области “Staging Area”, так и из области “Working Directory”. В итоге можно сказать, что между командой
1
git rm -f
и командой
1
git rm
практически нет никакой разницы.

Команда git mv - перемещение или переименование файлов

В системе Git имеется “своя” команда для перемещения или переименования файлов. Слово “своя” здесь не даром взято в кавычки - аналогия с командой

1
git rm
полная. Команда
1
git mv
перемещает или переименовывает файлы, автоматически “уведомляя” об этих событиях область “Staging Area”:

Команда git mv - перемещение файла в Git

Остается только зафиксировать эти изменения любым коммитом:

$ git commit -m 'Move index.html to papka'
  [master 868d428] Move index.html to papka
   1 file changed, 0 insertions(+), 0 deletions(-)
   rename index.html => papka/index.html (100%)

Переименуем файл

1
index.html
с помощью команды
1
git mv
:

Команда git mv - переименование файла в Git

Вот и все несложные операции по перемещению\переименованию или удалению файлов с помощью команд

1
git rm
и
1
git mv
, под всевидящим оком Git.