суббота, 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.

суббота, 29 ноября 2014 г.

Блокнот·два·плюса — форэва!

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

Как–то незаметно мои усилия по реорганизации инфраструктуры для разработки сайта (вернее, его переделки) во второй раз посягнули на святая святых разработчика — его редактор кодов. Напомню невнимательному читателю моего дневника, что однажды я уже перешёл с Homesite на Notepad++, а тут ещё раз шайтан взялся меня попутать — подсунул чудо современной программерско–компьютерной мысли, редактор Sublime Text. Грешен: повёлся! Ну, кто, скажите на милость, в здравом уме и при твёрдой памяти откажется от чуда чудного и дива дивного?

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

В конечном итоге, результаты заочного знакомства с новым редактором выглядели весьма оптимистично и привлекательно: и работает он шустрее, и интерфейс приятнее, и всяких приблуд для него видимо–невидимо… Весьма убедительны были традиционные пользователи Notepad++, которые стройными рядами, практически в едином порыве, с пламенным взором и песня́ми переходили под новые знамёна. Несколько настораживали встречавшиеся в Сети рекомендации о том, как изменить этот прекрасный редактор, чтобы он был похож на Notepad++.

И сегодня я, наконец–то, созрел: решил установить и попробовать — уж слишком много было хвалебных отзывов и практически отсутствовали весомые аргументы против (самым весомым являлась бесплатность Блокнота против «условнобесплатности» Сублима). Итак, установил, попробовал и …снёс, то есть, удалил. Фуфло!

Вообще–то, на этом можно было бы статью и закончить, но я решил, всё–таки, аргументировать свою позицию. Для начала повторю уже упоминавшийся аргумент: NPP (Notepad++) бесплатен, а ST (Sublime Text) пока условно бесплатен (лицензия стоит $70) — ключевой слово в этой фразе «пока», потому что никто не знает, когда разработчик включит обязательность приобретения лицензии, то есть, у пользователя возникнет необходимость поиска «таблэтки».

Кроссплатформенность ST, которую его апологеты выдвигают в качестве основного и весьма существенного преимущества, для меня неактуальна, а вот богатый инструментарий NPP для работы с различными кодировками кириллицы — весьма и весьма ценная фича. В ST я вообще не нашёл управления кодировками: наверное, потому, что редактор заточен под англоязычного пользователя, которому совершенно незачем заморачиваться со всякими там KOI–CP1251 и их многочисленными братьями–сёстрами. Я уж не говорю о том, что интерфейс редактора исключительно английский, и хотя у меня не возникает в этой связи языковой проблемы, русскоязычный NPP сердцу милее.

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

Правильно настроенный NPP может творить чудеса: макросы, расширения (один только Emmet, a.k.a ZenCoding чего стоит), с подсветкой синтаксиса, перекодировкой. Я, кстати, добавил «раскраску» синтаксиса для SCSS, HTML5 и CSS3, а также скрипт для компиляции SCSS в CSS прямо из NPP (без плагина jN скрипт не работает). Я уж не говорю о разнообразных «стандартных» плагинах (тех, которые устанавливаются через Plugin Manager), щедрой рукой добавляющих Блокноту·два·плюса разнообразные полезности и «вкусности»

В общем, снова здравствуй, Блокнот! Я вернулся.

понедельник, 17 ноября 2014 г.

Исправление весенней ошибки

Авторство в создании концепции «отвечающего» веб–дизайна (responsive web design, RWD) приписывается американскому дизайнеру из Бостона Итану Маркотту, хотя за шесть лет до опубликования его статьи на эту тему, другой дизайнер–разработчик, Камерон Адамс, выдвинул общую идею динамической адаптации представления веб–сайта на различных устройствах: смартфонах, планшетах, ноутбуках и офисных компьютерах.

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

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

Другими словами, решил сделать «работу над ошибками». В качестве резинки–ластика для стирания этих ошибок и карандаша, способного красивым почерком вписать в историю моего сайта правильные современные «слова», связав их в логически верные «предложения», которые, в конечном итоге, сложатся в интересный, увлекательный «роман» призван вызвать набор CSS/Javascript Bootstrap, недавно приобретённый вместе с пакетом HTML5 Bootstrap.

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

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

Для устройств с несколько бо́льшим разрешением (больше 768, но меньше 992 пикселей) — раскладка с двумя колонками для контента и дополнительной информации, «обрамлёнными» сверху и снизу блоками меню и вспомогательной информации (рисунок слева внизу). А для больших и очень больших разрешений — всего, что больше 992 пикселей в ширину, — ранее описанное трёхколоночное представление (для наглядности я повторил этот рисунок справа внизу).

Наверное, можно было бы всё это многообразие макетов реализовать и через таблицы (как мечталось в далёком апреле), но инструментарий пакета Bootstrap позволяет не только преодолеть возможную «головную боль» с дизайном, но и полностью её предотвращает. Спрашивается, зачем ломиться «скрозь» лес, ломая рогами ветки и треща валежником, если можно спокойно прогуляться по аллейке с рюмкой кофе в руках, наблюдая красоты окружающей природы? Я, например, выбрал «прогулку».

Речь идёт о наборе из четырёх типов классов, которые соответствуют четырём диапазонам разрешений экрана:

  • .col-xs- (eXtra Small) — колонка (столбец) для самого малого разрешения (меньше 768px);
  • .col-sm- (SMmall) — колонка для малого разрешения (от 768 до 992px в ширину);
  • .col-md- (MeDium) — колонка для среднего разрешения (между 992 и 1200px);
  • .col-lg- (LarGe) — колонка для большого разрешения (больше 1200px).

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

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

А теперь, прочувствуйте простоту и удобство вёрстки страницы с помощью сетки и Bootstrap: для самого маленького разрешения, которому соответствует группа классов .col-xs-, блок меню–навигации (жёлто–оранжевого цвета) будет «награждён» классом .col-xs-4 («простирается» на четыре полосы сетки), блок основного контента (зелёного цвета) и вспомогательной информации (лилового цвета) — .col-xs-12 (ширина всех 12 полос), а второй блок дополнительной информации — .col-xs-4.

Макет для планшетов и нетбуков (если такие ещё существуют) строка меню и левый блок дополнительной информации наделяются классом .col-sm-12 (занимают всю ширину экрана), блок основного контента — .col-sm-8 и правый блок вспомогательной информации — .col-sm-6.

По такому же принципу, — решительно и деловито, — назначаются классы для среднего разрешения: .col-md-6 — для блока основного контента и .col-md-3 — для всех остальных. Группу классов .col-lg- решил вообще не трогать: с экранами больших разрешений успешно справится «средняя» группа (.col-md-).

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

Первый порыв применения Bootstrap на практике, можно сказать, «проба пера» вылилась в такую конструкцию (интересно, как она себя поведёт в жизни, то есть, на сайте?):

<div class="container"> 
 <div class="row"> 
  <div class="col-sm-12 col-md-3 hidden-xs">
   <!-- на смартфонах меню спрятано и вызывается принудительно, по нажатию пиктограммы (механизм вызова меню здесь не рассматривается) -->
   <h2>Меню</h2>
   <p>(жёлто-оранжевый блок)</p>
   <div class="hidden-sm">
    <!-- ... а блок дополнительной информации отображается в другом месте и на смартфонах, и на планшетах (см. ниже) -->
    <h2>Доп.информация левой колонки</h2>
    <p>(лиловый блок)</p>
   </div>
  </div>
  <div class="col-xs-12 col-sm-8 col-md-6">
   <h2>Контент</h2>
   <p>(зелёный блок)</p>
  </div>
  <div class="col-xs-4 col-sm-4 col-md-3 hidden-xs">
   <!-- на смартфонах правая колонка спрятана и вызывается принудительно, по нажатию пиктограммы (механизм вызова блока здесь не рассматривается) -->
   <h2>Правая колонка</h2>
   <p>(синий блок)</p>
  </div>
 </div>
 <div class="row"> 
  <div class="col-xs-12 hidden-md hidden-lg">
   <!-- дополнительная информация из левой колонки на смартфонах и планшетах выводится под блоком с основным содержанием -->
   <h2>Доп.информация левой колонки</h2>
   <p>(лиловый блок)</p>
  </div>
 </div>
</div>

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

суббота, 15 ноября 2014 г.

Не изобретая велосипед…

Обновлять, так обновлять! Следуя этому девизу ещё семь месяцев тому назад я решили максимально кардинально подойти к модернизации сайта. Именно по этой причине совершались «шаманские пляски» вокруг базы данных по весне, а сейчас настала пора принципиально–кардинальных изменений всей веб–среды моего сайта.

Поскольку негоже «в наш век прогресса и прогрессивки» продолжать передвигаться на конной тяге, предстоит мне перебираться со старого доброго

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
на новый, но, похоже, тоже добрый
<!DOCTYPE html>
то есть, вливаться в стройные ряды приверженцев наиболее современного стандарта разметки html5.

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

Как всегда, мир оказался не без добрых людей, и эти самые добрые люди собрали воедино несколько независимых техник и подходов, которые позволяют разработчику не задумываться над проблемой совместимости. То есть, я создаю сайт по стандарту html5, а упомянутая разработка добрых людей гарантированно обеспечивает правильное отображение этого сайта в любом (ну, практически любом) браузере — даже старом, выпущенном до принятия html5, даже новом, но с коряво реализованной поддержкой нового стандарта.

Имя этой волшебной «приблуды» — HTML5 Boilerplate (переводится, примерно, как «заготовка для HTML5», но я бы назвал её «HTML5–костыли» — точнее отражает суть пакета). На момент публикации статьи доступна версия 4.3.0 и именно к её разворачиванию и приступаю. До этого я пару дней потратил на изучение предыстории возникновения и совершенствования набора, но для практического использования эта информация ценности не представляет, а наиболее любознательные могут воспользоваться поисковыми системами, чтобы повторить мои изыскания.

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

При входе на упомянутый ресурс, вы получаете возможность псевдовыбора: то ли вы возьмёте классический набор HTML5Boilerplate (серая кнопка), то ли классический пакет с довеском из html–шаблона, сработанного на принципе «отзывчивого» веб–дизайна (красная кнопка), то ли стандартный пакет с твиттеровским набором Bootstrap для создания собственных «отзывчивых» шаблонов (синяя кнопка).

Почему псевдовыбор? Потому, что нажимая на любую из трёх кнопок, соискатель нужного пакета переходит к единому экрану тонких настроек (Fine tuning) компонентов, составляющих пакет:

В первой колонке (HTML/CSS Template), собственно, и выбирается вариант, обозначенный тремя кнопками предварительной конфигурации (предыдущее изображение): классический пакет (только HTML5 Boilerplate), классический пакет с готовым «отзывчивым» шаблоном (Mobile-first Responsive) и классический пакет с набором Bootstrap (Twitter Bootstrap).

Вторая колонка (HTML5 Polyfills) позволяет выбрать между компонентами HTML5Shiv (исправляет ошибки реализации HTML5 в Internet Explorer) и Modernizr (CSS и JS расширенной функциональности, включая возможность HTML5Shiv). Третья позиция колонки может включить в общий пакет скрипт response.js, который позволяет решить проблемы старых мобильных устройств, не поддерживающих медийные запросы в CSS (Media Queries). Впрочем использование этого скрипта имеет некоторые скрытые недостатки, но альтернативой является

В третьей колонке можно выбрать вариант библиотеки jQuery — сжатый (Minified) и/или полный (Development). Традиционно рекомендуется использовать последнюю версию jQuery из сетевого репозитория, и эта рекомендация реализована разработчиками HTML5 Boilerplate, но, тем не менее, в пакет включается скрипт с библиотекой, главным образом, на случай каких–либо проблем с доступом к сетевому репозитарию. Вместе с тем, в другом разделе документации рекомендуется использовать только локальную копию: дескать, прилагаемая версия не вызывает конфликтов со скриптами (неизвестно, как поведёт себя более новая версия) и в ней предусмотрено более длительное кэширование.

Последний раздел — «подвал» формы тонких настроек, H5BP Optional — содержит несколько очевидных, не очень очевидных и, на неподготовленный взгляд, совершенно неочевидные дополнения: часть из них включены несколькими строками в базовый шаблон (как, например, классы для IE или блок для Google Analytics), а другие — в виде дополнительных файлов (например, plugins.js, robots.txt или .htaccess).

Для себя я выбрал такой пакет:

  • из опций «HTML/CSS Template» — набор стилей Bootstrap (тесноваты оказались для меня границы одного шаблона Mobile–first);
  • из вариантов «HTML5 Polyfills» — скрипты Modernizr и Respond;
  • «упакованный» вариант jQuery;
  • и всё из «H5BP Optional» (потом буду разбираться, что там лишнее).

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

<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
        <title></title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        <link rel="stylesheet" href="css/bootstrap.min.css">
        <style>
            body {
                padding-top: 50px;
                padding-bottom: 20px;
            }
        </style>
        <link rel="stylesheet" href="css/main.css">

        <script src="js/vendor/modernizr-2.6.2-respond-1.1.0.min.js"></script>
    </head>
    <body>
        <!--[if lt IE 7]>
            <p class="browsehappy">Вы используете <strong>устаревший</strong> браузер. Пожалуйста, <a href="http://browsehappy.com/" rel="nofollow noindex">обновите свой браузер</a> чтобы улучшить отображение страниц.</p>
        <![endif]-->
        
        

        <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
        <script>window.jQuery || document.write('<script src="js/vendor/jquery-1.11.1.min.js"><\/script>')</script>

        <script src="js/vendor/bootstrap.min.js"></script>

        <script src="js/plugins.js"></script>
        <script src="js/main.js"></script>

        <!-- Google Analytics: замените UA-XXXXX-X на свой идентификатор сайта. -->
        <script>
            (function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
            function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new Date;
            e=o.createElement(i);r=o.getElementsByTagName(i)[0];
            e.src='//www.google-analytics.com/analytics.js';
            r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
            ga('create','UA-XXXXX-X');ga('send','pageview');
        </script>
    </body>
</html>

Вот, отсюда теперь и предстоит плясать–танцевать.

пятница, 18 апреля 2014 г.

Переключение кодировки

Решил я, что пришло время изменить кодировку страниц своего сайта «Заливная рыба», по крайней мере, начать эту работу. Хорошо бы, конечно, для таких случаем иметь Большую Красную Кнопку — голубую мечту Доктора Кто. Написа́л предыдущее предложение, прочитал его и осознал двусмысленность: то ли мечта Доктора голубая из–за её несбыточности, то ли вследствие изрядной (хотя не вполне явной) «голубизны» самого Доктора. Осторожнее нужно быть с эпитетами…

В общем, кнопки нет и в обозримом будущем не предвидится, а процесс перевода предыдущей версии сайта из кодировки CP-1251 в более прогрессивную UTF-8 нужно начинать. Первым делом, взялся за базу данных: в ней уже накоплено сведения о 80 давно подготовленных статьях и таблицы словарей (теги, категории, рубрикаторы). Сначала, с помощью встроенной в панель управления моего хостинг–провайдера утилиты phpMyAdmin скопировал всё содержимое базы данных MySQL к себе на компьютер в один файл («экспорт» называется). Затем вычистил БД, то есть удалил все таблицы вместе с содержимым, после чего поменял кодировку базу на вожделенную utf8-general_ci.

Потом нужно было собственно перекодировать данные: ведь из базы данных они выгрузились на мой жёсткий диск в кодировке cp1251.

Долгое время я пользовался старым добрым Macromedia Homesite+ версии 5.5 — старичок натужно пыхтел, жрал немилосердно внушительные объёмы ресурсов, гадёныш, но привык я к нему (всё–таки 10 лет вместе!), несмотря на некоторые неудобства. Буквально месяц тому назад я вынужден был с ним «распрощаться навеки»: взялся я ваять новый сайт, непременно в кодировке UTF-8, а мой «старикашка» ни сном, ни духом не знает что это такое.

Пришлось искать альтернативу, и она нашлась довольно быстро — Notepad++. Редактор простой, мощный и, что немаловажно, бесплатный (мой старый Homesite без таблэтки работать отказывался). А главное — понимает любые кодировки и, будучи дополнительно укреплён–усилен плагинами (я установил Emmet, QuickText и некоторые другие) оказался не менее функциональным и исполнительным, чем привычная софтина.

В общем, открыл я в NPP (Notepad++) файл экспорта из БД и запустил перекодировку в «UTF-8 без BOM» — секунда дела! Перед тем, как сохранить перекодированный файл пришлось порихтовать свойства таблиц: вместо

) ENGINE=MyISAM AUTO_INCREMENT=148 DEFAULT CHARSET=cp1251;

прописать

) ENGINE=MyISAM AUTO_INCREMENT=148 DEFAULT CHARSET=utf8;

Мне пришлось это сделать 7 раз и только потом сохранить файл. Следующий шаг — загрузка данных обратно в БД («импорт» называется и производится всё через ту же phpMyAdmin)

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

Перекодировка всё в том же NPP файлов шаблонов и скриптов, а также замена кодировки страниц с


на


проблему не решили, хотя и принесли некоторое облегчение: кое–какие надписи стали читаемыми. Однако, всё, что «пришло» на страницу из базы данных, представляло собой одни вопросы, то есть, состояло сплошь из вопросительных знаков (моджибака, прости Господи!).

Тогда решил посмотреть, что вообще творится с переменными MySQL. Запустил запрос, получил ответ:

SHOW VARIABLES LIKE 'character_set%'
имя переменной значение
character_set_client utf8mb4
character_set_connection utf8mb4
character_set_database utf8
character_set_filesystem binary
character_set_results utf8mb4
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/

Оказалось, что кодировка utf8mb4 введена в MySQL начиная с версии 5.5.3 (в начале 2010 года) из–за того, что ранние версии MySQL могли сохранять только 5,88% символов Юникода, в то время как UTF–8 (Unicode Transformation Format, 8-bit — «формат преобразования Юникода, 8-битный») в состоянии отображать все 100%. Проблема в том, что UTF–8 использует для кодировки символов от 1 до 6 байтов (это теоретически, на практике же — от 1 до 4), а MySQL умела сохранять только трёхбайтовый UTF–8.

Стало быть, нужно ещё раз базу данных «перековать» в новую диковинку — utf8mb4. Только, вот какая штука: кодировка windows–1251 однобайтовая, а utf–8 — двухбайтова (для кириллицы, иврита, арабского, греческого, армянского, коптского алфавитов и таких экзотов, как тана, использующегося на Мальдивах и нко — в Гвинее и Мали; кстати, для грузинского алфавита требуется трёхбайтный код, как и для китайского, японского, корейского, индийского). Это значит, что для строки из 100 символов потребуется 100 байт в кодировке cp–1251 и 200 (а то и 300) в кодировке UTF–8.

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

В конечном итоге, получилось так (сравните первый вариант, от windows–1251 и второй, для utf–8 с добавкой от MySQL для одной из таблиц базы данных)

CREATE TABLE `vocabular` (
  `sysn` int(11) unsigned NOT NULL auto_increment,
  `ref` int(11) NOT NULL,
  `defen` varchar(100) NOT NULL,
  `lang` enum('en','ru','la') NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `voc_1` (`ref`,`defen`)
) ENGINE=MyISAM AUTO_INCREMENT=521 DEFAULT CHARSET=cp1251;
ALTER DATABASE `zalivryba` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

SET NAMES 'utf8mb4';

CREATE TABLE `vocabular` (
  `sysn` int(11) unsigned NOT NULL auto_increment,
  `ref` int(11) NOT NULL,
  `defen` varchar(400)  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `lang` enum('en','ru','la') NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `voc_1` (`ref`,`defen`(235))
) ENGINE=MyISAM AUTO_INCREMENT=521 DEFAULT DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Таким образом:

  • изменена кодировка всей БД, каждой из таблиц и каждого строкового поля (VARCHAR и TEXT) в таблицах;
  • увеличен в 4 раза размер каждого строкового поля;
  • установлены ограничения на размеры некоторых индексов — поскольку размер индекса не может быть более 1000 байт, то для поля, например, `defen` остаётся не более 989 байт (размер `ref` составляет 11 знаков), а это значит, что индексировать можно только первые 989:4 = 247 символов–знаков (ну, и хватит!)

Потом, как советуют бывалые люди, запустил восстановление (REPAIR) и оптимизацию (OPTIMIZE) всех таблиц, — быстро, из панели управления — и, дрожа от нетерпения, бросился смотреть на результат, а там… Ничего не изменилось: на экране была всё та же печальная моджибяковщина…

Очередная проверка переменных среды нарисовала странную картину:

За разъяснениями пришлось обращаться в службу поддержки хостинг–провайдера. Очень вежливые и обходительные специалисты настойчиво втолковывали мне, что они изменить ничего не могут, поскольку серверные установки могут повлиять на сайты всех остальных клиентов — хостинг–то sharing. В общем, ситуация сложилась тупиковая: впору опять всё возвращать в прежнюю кодировку windows–1251 и плакать по ночам от несбывшейся мечты про UTF–8 — не помогла даже очень хорошая статья толкового программера (то, что он является одним из авторов HTML5 Boilerplate, говорит само за себя).

Но решение нашлось, когда я бросил уже прощальный взгляд на мануал MySQL: там, в разделе «10.1.5 Configuring the Character Set and Collation for Applications»:

Приложениям, использующим базу данных, следует конфигурировать свои соединения с сервером при каждом подключении. Это можно сделать путём исполнения запроса SET NAMES 'utf8' после соединения. Этот запрос может использоваться независимо от способа подключения.

Решил напоследок попробовать ещё и этот вариант (а что я теряю?!), запустил в своём PHP–скрипте такую команду:

$db = DbSimple_Generic::connect("mysql://$user:$password@localhost/$name");
$db->query("SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'");

В первой строке кода — подключение к базе данных (я давно использую очень удобную библиотеку Дмитрия Котерова), а во второй — его настройка на utf8mb4 (перешибаются установки сервера character_set_server, collation_connection, collation_server и, наверное, многое другое). После этого всё… заработало!

Всё остальное вообще оказалось детской задачкой: изменил кодировки в заголовках страниц, перекодировал шаблоны, файлы инициализации строковых переменных — деловито и без проблем.

Voilà!

вторник, 15 апреля 2014 г.

Имя, сестра, имя!

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

Кому не хочется обзавестить звучным, коротким и ясным именем для своего сайта? Ещё на заре создания «Заливной рыбы» я твёрдо знал, что имя домена для сайта будет содержать слово «залив». Как вы понимаете, имена zaliv.com, zaliv.org или zaliv.net меня не ждали: первый до сих пор принадлежит судостроительному заводу «Залив» (гор.Керчь), второй — русскоязычной тусовке в Силиконовой долине (видимо, имеется ввиду Калифорнийский залив). Кем или чем были заняты эти же домены на TLD (Top Level Domain — домен верхнего уровня) .net и .info я уж и не упомню.

В общем, уже почти определилось имя 3aliv.info (по–моему, достаточно креативно), но случилось «отклонение от генеральной линии», и работа над сайтом прекратилась на неопределённый срок (как потом оказалось, на три года).

Среди задач, подлежащих решению при возобновлении разработки сайта, регистрация доменного имени, как вы помните, не значилась. А всё потому, что эта регистрация относится к категории архипервоочередных и суперсрочных, на два корпуса опережая все остальные. Выдержка хороша не только для вина, коньяка и виски, но и, как оказалось, для доменов: столь вожделенный zaliv.info уже оказался свободным! И по этой самой причине был немедленно зарегистрирован через самый удобный, на мой взгляд, сервис регистрации доменов — GoDaddy (в своё время перепробовал несколько и остановился на этом, пользуюсь много лет). С хостингом тоже давно определился — все мои проекты давным–давно базируются на WebHostingHub.com (надо бы его порекомендовать, если бы служба поддержки была бы более профессиональной).

После регистрации домена необходимо было активировать (на GoDaddy) его переадресацию на сервер хостинга, на котором размещены файл сайта (WebHostingHub). Процедура весьма проста и необременительна — заняла буквально пару минут, но потом начались долгие часы томительного ожидания. Дело в том, что для вступления в силу сделанных изменений, эти новые установки должны распространиться по всему миру. Обычно на это у моих новых доменов уходило несколько часов, но в случае с zaliv.info прошли сутки (14 апреля), а сайт всё ещё не виден в Интернете.

Обращения в службы поддержки обоих сервисов — и WebHostingHub, и GoDaddy — утешения не принесли: «ждите!». Зато нашлась интересная утилита, позволяющая следить за процессом синхронизации серверов. Непонятно, почему в этот раз процесс идёт так медленно: может быть, эти изменения служба доставки развозит между серверами на улитках?. Ждём–с…

Через двое суток после активации переадресации, сайт продолжает оставаться недоступным: о новых DNS–серверах моего сайта знают только Санкт–Петербург и Пекин из 21 города на планете, выборочно проверенных упомянутой утилитой «Какой у меня DNS». Неужели мой сайт, «Заливная рыба» (zaliv.info), невзначай затянуло в карнавал санкций в отношении России (хотя, об Интернет–санкциях и речи не было)? Более того, мой сайт украинский. Странно…

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

Удивительно полезной оказалась это найденная мной утилитка: я вывалил на службу технической поддержки хостинга все выявленные ошибки, поскучал у монитора 15 минут, пока пацаны на том конце наводили порядок в «синусоидах и амплитудах» и, буквально через несколько минут, — вы не поверите — про zaliv.info знали уже 20 DNS–серверов из упоминавшихся 21 (нерасторопным оказался ресурс в Малайзии).

У вас ведь тоже уже грузится «Заливная рыба»?

понедельник, 14 апреля 2014 г.

Битва слоёв с таблицами

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

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

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

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

В результате, мой новый выбор таков: структурирование страницы на самом высшем уровне осуществляется слоями, формирование колонок — при помощи таблиц, а наполнение ячеек таблиц — снова в div'ах, при необходимости (можно же и непосредственно в ячейку напихивать данные). Примерно так:

[...]
[...]

суббота, 12 апреля 2014 г.

Подключение скриптов и стилей

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

С помощью всё того же Гугла разыскал я JQuery–библиотеку под названием плагин JQuery Sintax Highlight для «красивизации» кодов, написанных на различных языках программирования (мне могут потребоваться Javascript, CSS, PHP и SQL).

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

Среди услуг, предоставляемых Гуглом имеется сервис для размещения и хранения документов — облачное хранилище Google Drive. Если у вас есть аккаунт на Google (например, почта), значит у вас есть и Google Drive.

Запустить этот сервис можно нажав на квадратик из точек в правом верхнем углу панели Google (см. скриншот вверху) и выбрав из выпадающего окна иконку «Диск» После этого можно создать папку для своих скриптов (у меня это папка jquery) — именно для этого и существует красная кнопка «Создать», перейти в созданную папку и, нажав на меньшую безымянную красную кнопку (со стрелкой вверх), примыкающую к кнопке «Создать», загрузить требуемые файлы (в рассматриваемом случае это файл скрипта jquery.highlight.js и сопровождающий его файл стилей jquery.highlight.css, заранее взятые из репозитария).

Следующий этап — «разблокирование» файлов для всеобщего доступа: по умолчанию, при загрузке доступ к файлу имеет только его владелец. На скриншоте вверху для файла установлен наивысший уровень доступа: «Общедоступно в Интернете» (любые другие варианты у моего блога вызывали острое неприятие и скрипт просто не загружался на страницу). Кстати, если вы создаёте отдельную папку для своих скриптов (как моя jquery) и на неё устанавливаете требуемый доступа, то все загружаемые в эту папку файлы тоже будут «общедоступны в Интернете» (нужно будет только подтвердить это в диалоговом окне после загрузки).

Очень важный этап — переделка адреса ссылки на загруженные файлы. Гугл генерирует ссылку примерно такого вида (находится в поле «Совместный доступ»):

https://drive.google.com/file/d/0D-SchqSURoSlR2Mk0Vm12GJSWcy/edit?usp=sharing

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

https://googledrive.com/host/0D-SchqSURoSlR2Mk0Vm12GJSWcy

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

Первым делом, выберите в боковом меню вашего блога позицию «Шаблон». После этого очень многие начинающие (а зачастую и продолжающие) блогеры сразу же, смело и решительно заходят в святая святых, нажимая на кнопку «Изменить HTML». Наш путь, по большому счёту, лежит туда же, но сначала предпримем простой и необременительный шаг для обеспечения собственной безопасности — нужно сделать резервную копию шаблона, для чего и предусмотрена кнопка «Резервное копирование и восстановление» на той же странице.

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

Теперь, если вы сохранили шаблон вашего блога, можно заходить в режим «Изменить HTML» и вставить в любое место шаблона между тегами <head> и </head> строки, сконструированные вами на предыдущем этапе, следя за тем, чтобы они не попали внутрь тела какого–либо условного выражения (я это делаю сразу после <title> и </title>):

<title><data:blog.pageTitle/></title>
<script language='JavaScript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js'/>
    
<!-- jquery.highlight.js и jquery.highlight.css -->
<script language='JavaScript' src='http://googledrive.com/host/0B-SczaUpoUUY5SlkhqVm12GJS2g'/>
<link type="text/css" rel="stylesheet" media="all" href="http://googledrive.com/host/0B-SchqVm12GJT2pYaUtJd2UydlU" /> 

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

  • подключить библиотеку jquery.js (или её уплотнённый вариант jquery.min.js — строка №2 в верхней врезке кода),
  • вставить туда же (между тегами <head> и </head>) ещё один фрагмент кода:
<script language='JavaScript'>
 $(document).ready(function(){
  $('pre.code').highlight({source:1, zebra:1, indent:'space', list:'ol',attribute: 'data-language'});
 });
</script>

Теперь осталось поместить код между тегами <pre class="code"> и </pre> — обязательно нужно указать имя класса и можно указать название языка, который находится в контейнере (допускаются варианты html, js, php, css и sql):

<pre class="code" lang="html"> <p>Привет, мир!</p> </pre>

Как наверняка уже догадался мой проницательный читатель, все примеры отображены уже с помощью плагина подсветки синтаксиса JQuery Sintax Highlight, то есть поставленная в начале статьи задача выполнена. Но в заключение должен сделать несколько замечаний. Во–первых, в первом контейнере указаны произвольные идентификаторы на файлы скрипта и таблицы стилей: вам нужно будет сформировать и свои собственные на Google Drive, поскольку эти — не рабочие.

Во–вторых, перед вставкой в контейнер HTML–кода необходимо предварительно преобразовать символы < и > в HTML–тегах на &lt; и &gt;, соответственно. Для этих целей удобно использовать онлайн перекодировщики, например, этот. В–третьих, кол, приведенный во втором контейнере ($(document).ready(function()…) тоже можно поместить в отдельный файл, загрузить этот файл на Google Drive, сформировать ссылку по изложенному в этой статье алгоритму и включить в заголовок документа в виде <script language='JavaScript' src='http://googledrive.com/host/[идентификатор файла]'/>.

пятница, 11 апреля 2014 г.

Начинаю начинать

Встречают, как говорится, по одёжке, а «одёжка» моего сайта, над которой я долго и старательно корпел, по прошествии бурных лет перестала ласкать мой взор (скриншот бывшей стартовой страницы приведен выше). Другими словами, дизайн придётся переделать. «Однозначно» © В.В.Жириновский.

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

Перво–наперво, предстоит изменить кодировку сайта: четыре года тому назад было совсем нестыдно делать сайт в кодировке CP-1251, а теперь — всё, что не UTF-8 считается чуть ли не признаком дурного тона. Это тенденция понятна, разумна и приемлема, поэтому придётся ей следовать.

Была мысль перенести весь сайт на какой–нибудь популярный движок CMS, например, Joomla, но под каждый раздел сайта в своё время были написаны уникальные скрипты и отказываться от них я не намерен. А вот их «перековка» под неродную систему может вылиться в несоизмеримые трудовые затраты. Тем более, что я настолько комфортно чувствую себя в компании библиотек XTemplate и DBSimple, что буду сильно печалиться и тосковать, если Джумла их не примет в своё лоно.

Ещё нужно будет «вычистить» из PHP–скриптов весь текст, который должен выводиться в браузер. Идеальным является решение с использованием функционала GetText, но затеваться на моноязычном сайте с системой, предназначенной для многоязычных, вряд ли разумно. Гораздо проще завести набор .INI файлов для определения всех требуемых значений. Так и сделаю.

Про систему комментирования статей я уже писа́л — решение почти найдено и его остаётся только воплотить. «Почти» — потому, что нужно дополнительно определиться с системой подключаемых комментариев: например, по Хабрахабру гораздо предпочтительнее (по сравнению с Disqus) смотрится Cackle, а ещё хвалят HyperComments (хотя в бесплатной версии очень скромная функциональность).

Продолжаются раздумья насчёт целесообразности изменения библиотеки для работы с миниатюрами и изображениями реального размера. В первой версии сайта используется Highslide на «чистом» Javascript и «весом» около 275К, но в новой редакции «Заливной рыбы» интенсивно применяется надстройка JQuery (ну, очень мне нравится!), и логично было бы использовать соответствующую библиотеку. Выбор пал на PicBox на JQuery, которая имеет размер около 30К, правда, требует вспомогательную библиотеку JQueryUI (ещё 60К в сжатом виде).

И это — только то, что лежит на поверхности! Хочется надеяться, что пока ещё невидимых подводных камней будет не слишком много. Вам тоже интересно? Тогда, «следите за рекламой»!