Батискаф FuntooMacs

Goodbye, мой блог, goodbye!

2012-09-08T00:00:00+03:00

Итак, данный блог прекращает своё существование (хоть я и не планирую его удалять). С блоговедением как формой проведения досуга я не порываю, уже выбрав местечко для нового блога, на этот раз, имеющего собственное доменное имя и не привязанного к GitHub Pages (на данный момент он размещён на OpenShift). Выбор GitHub Pages в качестве платформы относится к раннему периоду моего увлечения блогами, это первая проба пера и одновременно proof-of-concept. Так уж вышло, что необходимость перемен назрела раньше, чем данный блог достиг своей зрелости. Надеюсь, что произведённые перемены пойдут мне только на пользу.

Перемены произошли не во всём: я всё ещё остаюсь верен Jekyll, но почувствовал необходимость в использовании расширений, которые de facto на GitHub запрещены по соображениям безопасности. Причины не в том, что мне стало невыносимо скучно без рюшечек и свистелок, а лежат гораздо глубже; о чём, пожалуй, стоит рассказать подробнее.

GitHub Pages и блоги

Изначально выбор пал на GitHub Pages, поскольку данный сервис рассматривался мною как полноценная платформа для блога. Конечно, не такая популярная, как Blogger или Google+; да и вообще, насколько оправданно называть платформой для блогов место, подходящее разве что для размещения заметок программистов? Понятие платформы для меня более широкое, и воспринимается как общепризнанный инструмент внутри определённого сообщества людей, в данном случае — пользователей GitHub. Чего стоит для разработчика, использующего GitHub для своих проектов, завести статический сайт? А раз так, то GitHub Pages, несомненно, является платформой, хоть и предназначенной для узкого круга людей. Платформы, как правило, получают гораздо больше поддержки со стороны сообщества, чем тот или иной движок для генерации сайта сам по себе. А в то, что проснувшись завтра, мы обнаружим GitHub Pages канувшим в лету, мне верится с трудом. Значит и платформа, и Jekyll, как её важная составляющая, будут получать поддержку, хотят их разработчики того или нет.

Переход от Markdown к Org Mode

Звучит странно, но что именно меня не устроило — это языки разметки Markdown и Textile, поддерживаемые Jekyll. И тот, и другой по-своему хорош, но оба достаточно плохо приспособлены для конвертации в форматы, отличные от HTML. Это и обусловило мой переход к Org Mode: захотелось в придачу к HTML иметь полноценную поддержку LaTeX. Всё же я не считаю, что те вещи, о которых сообщается в блоге, не имеют ценности за пределами интернета. Число веб-сервисов, использующих Markdown, растёт день ото дня, и если эта тенденция сохранится, то идея использовать Markdown для чего ещё (LaTeX, DocBook) так и не достигнет своей зрелости. Не говоря уже о том, что лучшего способа ведения заметок в Emacs, чем Org Mode, попросту не существует. Важным открытием для меня стал пакет org-ruby, который подключается к Jekyll через расширение jekyll-org и позволять писать посты сразу в Org Mode.

Комментарии в блоге

Следует признать, что система комментариев в данном блоге не ахти, да и требование регистрации на GitHub неоправданно жёсткое. Но возвращаться к корням в лице Disqus или IntenseDebate мне не хотелось. Мало того, что представленные платформы закрытые (и с неясной политикой сервисов, которые в один не самый прекрасный момент могут перестать быть бесплатными), так ещё и требуют от комментаторов навыков владения HTML. Markdown намного приятнее в обращении, поэтому мой выбор пал на систему комментариев Juvia, которая к тому же является open-source проектом. Также всем желающим доступен довольно простой пример размещения Juvia на OpenShift. Комментаторы тоже останутся довольны, поскольку в новом блоге никакая регистрация на GitHub больше не нужна!

P.S. В новый блог перенесён, дополненный и приукрашенный, пост про установку Linux на компьютер с предустановленной Windows. Как оказалось, упоминавшийся в нём проект «Grub 2 For DOS» уже переименован в «Grub 2 Win».

Установка Linux на компьютер с предустановленной Windows

2012-06-23T00:00:00+03:00

Сегодня многие компьютеры и ноутбуки попадают в руки поклонников Linux с предустановленной Windows, любезно предоставленной заводом-изготовителем. Возникает дилемма: удалять или не удалять, и способ установки уже любимой OS зависит от её решения. Как правило, изготовитель заранее побеспокоился о том, чтобы установка дополнительной OS доставила вам множество незабываемых минут, часов, дней и прочих радостей. Труден путь тех, кто не решился стереть все воспоминания о Windows с диска, но дорогу осилит идущий.

Подготовка разделов диска

Способов установки дополнительной системы к Windows мало, поскольку последняя поддерживает только таблицу разделов MBR, возможности которой ограничены 4 первичными разделами или 3 первичными и одним расширенным. Как правило, три первичных раздела уже задействованы: один — под восстановление системы, и ещё два — под Windows. Мы же силами Linux LiveCD и редактора разделов Gparted подвинем полномочия Windows, уменьшив его раздел, а на освободившемся пространстве создадим расширенный (Extended) раздел под Linux. Предварительно, полезно ознакомиться с тем, как правильно выравнивать разделы диска. Для Linux желательно создавать не менее трёх логических разделов: подкачки (swap), корневой и под домашний каталог.

Установка загрузчика

Можно было бы поместить загрузчик Grub на один из Windows-разделов, если бы не неприкрытая любовь MicroSoft к NTFS. Для Grub эта файловая система не подходит, поэтому установите Grub в корневой раздел Linux и скопируйте файл настройки (/boot/grub/grub.cfg для Grub 2) в место, доступное из-под Windows. BIOS будет передавать управление Windows, а уже потом будет грузиться Grub. Однако, Windows не обладает способностью грузить разделы с файловыми системами Linux. Нам нужен посредник, для чего можно воспользоваться проектом Grub For DOS или Grub 2 For DOS. Оба они равноправны, первый создан на основе Grub, второй — на основе Grub 2. Об использовании Grub For DOS очень обстоятельно рассказано здесь, ну а для пользователей дистрибутивов на основе Grub 2 настоящей находкой является Grub 2 For DOS, о котором и пойдёт речь дальше.

Установка Grub 2 For DOS очень проста: скачайте архив с сайта и распакуйте в корень Windows-раздела (обычно, это диск C), там должна появиться папка grub. Запустите C:\grub\install\grub24dos.exe и выполните его настройку, после этого инсталлятор добавит новую запись «Grub 2 For DOS» в меню загрузки Windows. Для наших целей достаточно выставить «Windows boot timeout», остальные данные продублируйте из своего дистрибутива, поместив сохранённый grub.cfg в C:\grub. Теперь выбор «Grub 2 For DOS» в меню загрузки перенесёт вас в Grub 2.

Прим. При любых изменениях, вносимых в конфигурацию Grub 2, не забывайте обновлять меню, подкладывая Grub 2 For DOS изменённый grub.cfg.

Ручная настройка BCD

Наверняка вам известно, что для загрузки, начиная с Windows Vista, используется Boot Configuration Data (BCD), которую модифицирует Grub 2 For DOS. Для тонкой настройки меню загрузки предназначена специальная утилита bcdedit. Желательно перед любыми изменениями создавать резервную копию BCD в соответствии с инструкцией.

С помощью строки поиска в главном меню Windows найдите интерпретатор командной строки cmd и выберите вариант запуска «Run as administrator». Используя подробную справку bcdedit /v по записям в BCD, каждой из которых соответствует уникальный GIUD, найдите «Grub 2 For DOS». Можно выставить «Grub 2 For DOS» первым в меню

bcdedit /displayorder {GUID} /addfirst

а также сделать пунктом по умолчанию

bcdedit /default {GUID}

Дальнейшее описывает шаги по созданию записи «Grub 2 For DOS» с нуля на тот случай, если вы пожелаете это сделать самостоятельно. Новая запись в BCD создаётся командой

bcdedit /set {GUID} path \grub\winloader\grub.boot

После этого будет отображен GUID новой записи, который нужно подставлять в следующих командах. Укажем раздел, на котором находится Grub 2 For DOS

bcdedit /set {GUID} device partition=C:

и местоположение загрузчика

bcdedit /set {GUID} path \grub\winloader\grub.boot

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

bcdedit /displayorder {GUID} /addfirst

Если /addfirst заменить на /addlast, то новая запись будет добавлена в меню загрузки не первой, а последней. Остаётся сделать запись выбором по умолчанию

bcdedit /default {GUID}

и установить время ожидания меню

bcdedit /timeout 5

Создание системы комментариев на основе GitHub

2012-05-07T00:00:00+03:00

После того, как была описана система комментариев на основе GitHub, возникает законный вопрос о том, как же её получить. В отличие от статических страниц GitHub Pages, использование только Jekyll для этих целей недостаточно. Нам понадобится сценарий JavaScript для загрузки и отображения комментариев, а также место для их хранения, в качестве которого используется Issue-трекер GitHub.

Создание ветки комментариев

Создайте issue на Issue-трекере в репозитории блога для хранения комментариев к вашему посту. Например, вот issue для комментариев предыдущего поста, ссылка на который состоит из базового URL https://github.com/visconte/visconte.github.com/issues/ и уникального id (1 в данном примере). Данный issue используется читателями блога для отправки комментариев, что выглядит примерно так:

После этого включите полученный id в YAML-заголовок исходного текста поста, чтобы использовать его для загрузки комментариев на соответствующую страницу блога (значение id указано напротив commentIssueId):

---
layout: post
title: "GitHub Pages: дальнейшая интеграция, или комментарии блога на GitHub"
commentIssueId: 1
category: GitHub
---

Вот фрагмент layout-файла, генерирующего страницы блога (post.html в данном примере), с ссылкой на issue. Внутри неё используется Liquid-шаблон, извлекающий id для issue (часть page.commentIssueId, заключённая в двойные фигурные скобки):

<div id="comments">
  <h2>Отправить комментарий</h2>
  <p>
    Комментарии блога предоставлены сервисом
    <a href="https://github.com/">GitHub</a>.
    Вы можете отправить комментарий с
    <a href="https://github.com/visconte/visconte.github.com/issues/{{ page.commentIssueId }}#discussion_bucket">данной страницы</a>
    (необходима <a href="https://github.com/signup/free">регистрация на GitHub</a>)
    или связаться со мной по
    <a href="" class="user-email">email</a>.
  </p>
</div>

Загрузка комментариев с Issue-трекера

Добавим JavaScript сценарий, извлекающий комментарии к посту блога из соответствующего issue на GitHub. GitHub issues API как раз то, что нам сейчас нужно — сделать XHR-запрос и получить все комментарии для конкретного issue. Для каждого комментария вы таким образом получаете id пользователя GitHub, что оставил данный комментарий, id его Gravatar-изображения; порядковый номер комментария на issue, время его создания и модификации, а также сам комментарий. Вот часть layout-файла, которая забирает комментарии поста посредством jQuery (заметьте, что вам нужен Liquid-шаблон для определения ссылки на issue, чтобы извлекать оттуда комментарии):

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>

<script type="text/javascript">
$.ajax('https://api.github.com/repos/visconte/visconte.github.com/issues/{{ page.commentIssueId }}/comments', {
    dataType: 'json',
    headers: {Accept: 'application/vnd.github.html+json'},
    success: function(comments) {
        loadComments(comments);
    }
})
</script>

Подождите, разве не применяется Правило ограничения домена в случае XHR-запроса к GitHub API со страницы блога? Да, конечно применяется. И до недавнего времени, единственный способ обойти это ограничение состоял в использовании JSONP. Однако, JSONP не позволяет изменять HTTP-заголовок запроса, что необходимо для задания требуемого Mime-типа отклика GitHub API в заголовке Accept (смотри код выше). Но с недавних пор GitHub поддерживает спецификацию CORS, позволяющую делать кросс-доменные запросы. Способ, которым GitHub API реализует CORS, состоит в регистрации веб-сайтов как OAuth-приложений для доступа к API. Чтобы разрешить CORS блогу на GitHub, необходимо перейти к форме регистрации OAuth-приложений и создать новое приложение, указав при этом URL блога в полях «Main URL» и «Callback URL». Заметьте, что данный способ подходит (и остаётся неизменным) не только для блогов внутри доменной зоны GitHub (например, visconte.github.com), но и для блогов на GitHub, имеющих собственный домен.

Отображение комментариев в блоге

Включим скачиваемые комментарии в layout-файл, генерирующий страницы постов. Например, вот мой код для вставки комментариев:

<script type="text/javascript" src="http://datejs.googlecode.com/svn/trunk/build/date-ru-RU.js"></script>

<script>
function loadComments(comments) {
    for (var i=0; i<comments.length; i++) {
        var cuser = comments[i].user.login;
        var cuserlink = 'https://www.github.com/' + cuser;
        var clink = 'https://github.com/visconte/visconte.github.com/issues/{{ page.commentIssueId }}#issuecomment-' + comments[i].id;
        var cbody = comments[i].body_html;
        var cavatarlink = comments[i].user.avatar_url;
        var cdate = Date.parse(comments[i].created_at).toString("MMMM d, yyyy HH:mm");

        $('#comments').append('\
<div class="comment">\
  <div class="cmeta">\
    <p class="author">\
      <span class="gravatar"><img height="20" width="20" src="' + cavatarlink + '"></span>\
      <strong><a href="' + cuserlink + '">' + cuser + '</a></strong>\
      <a href="' + clink + '">комментирует</a>\
    </p>\
    <p class="date"><a href="' + clink + '">' + cdate + '</a> <span class="icon"></span></p>\
  </div>\
  <div class="body">' + cbody + '</div>\
</div>')
    }
};
</script>

Для придания лучшего вида комментариям, мною используется библиотека DateJS для представления даты комментария, а к пользователям добавляются их Gravatar-изображения. Остаётся добавить CSS-правила для комментариев, чтобы получить следующий вид:

Вот и всё! Создание системы комментариев было достаточно просто, ведь у GitHub уже есть все необходимые составляющие (Issue-трекер, GitHub API, регистрация OAuth-приложений), и всё, что нам было нужно — это немного клея, чтобы связать это воедино. Мне нравится, что система интегрируется с аккаунтами GitHub, комментарии блога можно видеть на страницах с issue, а также простота использования системы комментариев в целом. Весь код, что используется для системы комментариев, — единый layout-файл для постов блога и CSS-правила — вы найдёте здесь. Дайте мне знать, если вы обнаружите лучший способ для размещения комментариев блога на GitHub или найдёте, как улучшить этот.

Прим. Этот пост представляет собой близкое к оригиналу изложение поста GitHub hosted comments for GitHub hosted blogs пользователя Ivan Zuzak. Выражаю глубокую признательность автору за проделанный труд.

GitHub Pages: дальнейшая интеграция, или комментарии блога на GitHub

2011-12-09T00:00:00+02:00

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

Для отправки комментария достаточно перейти по ссылке в соответствующем разделе в конце поста. Ссылка ведёт на Issue-трекер GitHub, хранящий комментарии блога и предоставляющий им тот же арсенал средств, что и в проектах на GitHub. На страницах блога комментарии отображаются посредством JavaScript. Хотите больше узнать об их возможностях? Читайте дальше.

Создавайте разметку текста легко

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

Выражайте эмоции посредством Emoji

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

Принимайте участие в дискуссиях

Пригласить пользователя в дискуссию очень просто — достаточно в комментарии набрать @имя_пользователя, и ваш собеседник получит уведомление об этом.

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

Если нет желания вступать в дискуссии, то оповещения о вашем упоминании в комментариях можно отключить в Notification Center.

Отправляйте ответы по email

Свой ответ на комментарий вы можете послать по email, используя почтовый ящик, указанный в аккаунте GitHub.

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

Используйте поиск по комментариям

Данный поиск доступен на странице с комментариями.