Пришло время завершить цикл постов о переезде этого блога на статический движок. Я уже успел рассказать о переносе самих постов и о манипуляциях со структурой адресов. Последняя оставшаяся не освещенной тема — перенос комментариев. За 6 лет существования блога их накопилось немало, и было бы обидно от них отказаться.

Так как Acrylamid — полностью статический движок, его средств недостаточно для обеспечения комментирования на блоге, и у меня возник выбор: либо использовать сторонние сервисы, либо поднять на своем сервере собственное решение (например, ISSO от того же разработчика). Взвесив все альтернативы, я понял, что совершенно не хочу заморачиваться с собственным решением и, по крайней мере поначалу, воспользуюсь услугами стороннего сервиса.

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

Впрочем, есть и негативные моменты, которые скорее всего вынудят меня однажды пойти искать другую платформу. Первый среди них — тяжеловесность клиентского JS даже в сжатом виде — около 700 КБ. Это гораздо больше, чем мне хотелось бы.

Теперь дело было за малым — сгенерировать дамп для импорта в Disqus. Конечно, для Drupal существует модуль, позволяющий импортировать все комментарии в Disqus, но он не мог ничего знать про новую структуру адресов постов, и, стало быть, после смены движка снова стал бы бесполезен. Так что я пошел по уже проторенному пути, и стал писать свой экспорт комментариев из Drupal. К счастью, Disqus умеет импортировать комменты в формате WXR (родной формат экспорта Wordpress), который представляет собой достаточно простой XML.

Достать комментарии из базы Drupal было проще простого:

SELECT cid, pid, nid, comment, hostname, timestamp, name, mail, homepage
        FROM drupal_comments
        WHERE status = 0

Сохранить его в нужном формате почти так же просто, если использовать модуль питона lxml. Единственная тонкость — указывая ссылку на пост, по которой Disqus потом определит принадлежность комментариев, нужно указывать новый адрес поста, консультируясь с картой перенаправлений, полученной на [предыдущем этапе](/2014/Changing URL structure for Acrylamid.html).

Дальнейшие шаги хорошо документированы на справочном сайте Disqus:

1. Добавление сайта в систему.
2. Импорт файла с комментариями (обычно занимает минут 5).
3. Установка кода на сам блог.

На этом, пожалуй, все, что касается переезда. Надеюсь, кому-то это пригодится :-)

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

Прежде чем приступить к разбору замечу, что такой концентрации бреда на единицу текста с тех пор, как перестал модерировать один крупный форум. И так:

1. Побойтесь бога, не присылайте текст в картинке. Понимаю, что вы хотите избежать спам-фильтров, но для этого отлично подойдет pdf без текстового слоя. Ни одна уважающая себя корпорация не рассылает документы в картинках, зато pdf любят все.
2. Не позволяйте себе фамильярности, пишите канцеляритом. Ну разве можно располагать на соседних строчках фразы “official notification letter” и “it is obvious that this notification will come to you as a surprise”.
3. Пишите по делу. Если уж вы пишите жертве, что она выиграла лотерею, так напишите детально, что за лотерея, почему она в ней участвует и вообще. Еще лучше, дайте ссылку на “сайт” лотереи, желательно на домене Google.
4. Не мелочитесь. Если уж обещаете приз в 950 тысяч фунтов, то хотя бы не приписывайте к этому жалкий Google Nexus 10.
5. Так же не стоит злоупотреблять восклицательными знаками, даже если слово “WARNED” так и просит поставить еще парочку.
6. Наконец, вы нарисовали вполне убедительную печать (хотя я лучше умею, да и чернила не того оттенка, и слишком ровные), подделали подпись Ларри Пейджа. Ну зачем еще рисовать совершенно нереалистичную красную наклейку “Google Incorporation”?! Поставьте тебя на место лоха, подумайте, что вам показалось бы подозрительным, я что — нет. Подсказка: наклейка очень подозрительная.
7. И совсем последнее, на картинке этой детали нет, что не умаляет её важности. Не отправляйте “официальное” письмо от Google с ящика в домене ieu.edu. Подделать отправителя совсем не сложно.

P.S. Disclaimer: я не призываю рассылать спам. Я призываю включать мозги.

P.P.S. А вы заметили, что логотип Google в верхней части это просто вставленный скриншот, при том древний, так как он перекрывает “водяные знаки”, покрывающие страницу. Между прочим, актуальное лого Выглядит так, и это png с прозрачностью, которая позволила бы такого ляпа избежать. Взято с Google.com.

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

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

1. Большая часть постов у меня так или иначе связана с решением тех или иных технических задач. Будучи изложенным на английском, решение смогут найти и прочесть куда большее количество людей.
2. Писать о технических вещах, как правило тоже легче на английском языке. Все-таки изобретение русскоязычных аналогов для технической терминологии — дело довольно неблагодарное.
3. Языковая практика. Чтение на английском уже давно не представляет для меня проблемы, но вот с речью есть определенные трудности, в основном грамматического толка, вызванные недостатком практики. Ну а блоггинг на английском — неплохой способ практику восполнить.

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

Так что я хотел бы узнать, как мои подписчики относятся к английскому языку, и насколько неприятен для них будет переход на него. Ниже я размещаю голосование и очень прошу потратить полминуты на ответ. А если вашего варианта в ней не найдется — велкам в комментарии ;-)

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

Напомню еще раз о задачах, которые я перед собой поставил:

• Сделать более-менее вменяемые URL постов. Например, транслитерированный кошмар вроде /blog/aleks/ispolzuem-svn-v-upravlenii-saitom-chast-pervaya-teoreticheskie-soobrazheniya превратить в более вменяемое /2008/Use-SVN-website-governance-Part-one-theoretical-considerations.html.
• Скорректировать все внутренние ссылки на посты, чтобы они указывали на правильные адреса постов. Попутно — все внутренние ссылки, картинки и тому подобное с полными адресами виде http://nevkontakte.(com|org.ru)/whatever позаменять на просто /whatever, чтобы обезопасить себя от проблем в случае смены домена или, например, перехода на https.
• Организовать редиректы со старых адресов постов на новые для поисковиков и внешних ссылок.

О решении первых двух проблем я уже успел вкратце рассказать в [предыдущем посте](/2014/Importing content into Acrylamid.html), поэтому сегодня сосредоточусь на том, как сопрячь старые и новые адреса постов по возможности ничего не поломав ни для людей, ни для поисковиков:

1. Внешние ссылки на посты по старым адресам не должны быть сломаны.
2. При запросе старого адреса страницы поисковики должны получать редирект 301 на новый адрес, чтобы они могли корректно переиндексировать сайт.
3. В будущем, как настоящий гик, я хочу захостить блог на GitHub Pages, раз уж он у меня полностью статический.

Единственная сложность — GitHub Pages не предусматривает никакой возможности задать 301-й редирект для определенного адреса. Поэтому, решение состоит из двух шагов:

1. Сгенерировать .htaccess с редиректами для поисковиков, и дождаться переиндексации, оставаясь на старом хостинге, который работает на Apache.
2. Так же сгенерировать набор страничек-заглушек с перенаправлением через <meta http-equiv="refresh">, которые будут служить для перенаправления пользователей после переезда на GitHub.

Имея адреса новых и старых страниц сделать это не так уж и сложно:

1. Код генерации .htaccess. На выходе — длинный-длинный .htaccess, с правилами для mod_rewrite.
2. Код генерации заглушек для GH Pages. Результат работы — по адресу старой странички генерируется почти пустой HTML документ, содержащий в себе лишь meta redirect на нужный адрес с нулевой задержкой.

Есть один лайф-хак, связанный с таким решением. Если хостинг не поддерживает “умных” средств передачи файлов типа rsync, можно сэкономить кучу времени, не загружая на сервер заглушки для гитхаба — их работу сделает .htaccess.

Я уже довольно давно являюсь слушателем Радио-Т и, хотя частенько не разделяю мнения ведущих, нахожу шоу довольно интересным. Однако, в выпуске Radio-T от 8 марта было два эпизода, которые меня слегка покоробили. Первый — фирменный троллинг от Umputun’a на тему ненужности сисадминов. Впрочем, я склонен считать, что у него с логикой все в порядке, и этот пассаж является всего лишь любимой, хоть и надоевшей, шуткой.

Второй раз я расстроился в тот момент, когда ни гости, ни ведущие подкаста не смогли дать внятного ответа на поставленный Umputun’ом вопрос о том, что такое веб-фреймворки. Между тем, этот вопрос одновременно и близок мне, и достаточно прост. На него я и попытаюсь ответить.

Что такое фреймфорк?

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

С библиотекой всё просто:

Библиотека (от англ. library) в программировании — это подпрограмм или объектов, используемых для разработки программного обеспечения (ПО) (wiki).

С фреймворком путаницы больше, но, на самом деле, она легко разрешима, если посмотреть определение этого слова. Например, в толковом словаре Оксфорда:

framework — An essential supporting structure of a building, vehicle, or object (основная несущая конструкция здания, транспортного средства или объекта).

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

Что такое веб-фреймворк?

Ладно, с «просто» фреймворком разобрались, вернемся к изначальному вопросу, о природе веб-фреймворков и, собственно, к тому, что меня расстроило в подкасте.

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

Веб-фреймворк — это нечто, определяющее архитектуру веб-приложения.

Но вот попытки привести это определение к более “материальному” виду начинают порождать проблемы. Так, в статье, которая обсуждалась в Радио-Т, утверждалось, что веб-фреймворк — это библиотека, решающая задачу разбора HTTP запроса внутри приложения и построения ответа на него. Однако, такая точка зрения у меня вызывает много вопросов. Например, Doctrine ORM, Twitter Bootstrap и AngularJS несомненно так же являются веб-фреймворками, но при этом они не решают вопросы разбора HTTP зарпосов и ответов.

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

Резюмируя

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

В этой заметке я постараюсь рассказать о процессе переноса постов из старого блога на Drupal в новый на Acrylamid.

Прежде всего надо отдать ему должное — он из коробки неплохо умеет импортировать контент из произвольных движков через RSS или дамп в формате Wordpress. В простых случаях этого более, чем достаточно, но мне нужно было нечто большее.

Задачу перед собой я поставил так:

• Перенести все посты и комментарии к ним.
• Содержимое постов:
  • По возможности сохранить форматирование, в том числе и в самых старых постах, где я использовал bbcode.
  • Преобразовать html в markdown для тех случаев, где это возможно.
  • Заменить метки друпаловского модуля Inline на обычные ссылки.
  • Извлечь из тела поста «feature images» (не могу подобрать адекватный перевод :-( «Картинка для привлечения внимания»?..) и перенести в мета-информацию о посте, чтобы можно было правильно ее стилизовать и размещать без лишней мороки.
  • Аналогично поступить с музыкальными видео, которые я добавляю в конец поста в виде постскриптума, при этом необходимо сохранить и их правильные заголовки.
• Структура адресов:
  • Сделать более-менее вменяемые URL постов. Например, транслитерированный кошмар вроде /blog/aleks/ispolzuem-svn-v-upravlenii-saitom-chast-pervaya-teoreticheskie-soobrazheniya превратить в более вменяемое /2008/Use-SVN-website-governance-Part-one-theoretical-considerations.html.
  • Скорректировать все внутренние ссылки на посты, чтобы они указывали на правильные адреса постов. Попутно — все внутренние ссылки, картинки и тому подобное с полными адресами виде http://nevkontakte.(com|org.ru)/whatever позаменять на просто /whatever, чтобы обезопасить себя от проблем в случае смены домена или, например, перехода на https.
  • Организовать редиректы со старых адресов постов на новые для поисковиков и внешних ссылок.

Желающие могут сразу отправляться изучать репозиторий на ГитХабе, в который я залил скрипты, выполняющие всю эту работу.

Для того, чтобы решить все эти задачи, мне нужно было добыть из базы данных Друпала сведения из четырех таблиц: drupal_node и drupal_node_revisions (посты, sql), drupal_comments (комментарии, sql) и drupal_url_alias («человекопонятные» адреса постов, sql). В целом процесс импорта выглядел примерно так: извлечение нужных данных из БД → конвертация базовой мета-информации в объекты Python → приведение её в формат, близкий к тому, что используется в Acrylamid → присвоение посту нового, аккуратного URL → применение цепочки фильтров к содержимому постов, решающих большую часть из поставленных задач → экспорт постов в формат Acrylamid → построение карт переадресаций для поисковиков и людей, приходящих по старым внешним ссылкам.

Генерация URL постов

Как я уже упомянул, на Drupal адрес поста генерировался путем банальной транслитерации русского заголовка поста, и выглядел он совершенно нечитаемо. Как мне сейчас кажется, лучше уж было использовать короткие адреса /node/1234. С другой стороны, в переходить на такую схему адресов мне представлялось неудобным, так как на новом движке пришлось бы нумеровать из вручную, а это уничтожает второе достоинство такого подхода.

Единственная альтернатива — использовать в адресе не транслитерацию, а перевод заголовка на английский. И чтобы не насиловать себя переводом заголовков двухсот с лишним постов (233-х, если быть точным) стоило воспользоваться машинным переводом. С одной стороны, это неизбежно даст некоторое количество ляпов, с другой стороны это не критично и в большинстве случаев перевод вполне адекватен.

К моему разочарованию, у Google Translate не оказалось нормального API и даже «пиратской» обертки на python к их веб-интерфейсу. Я уже было собрался лезть и с помощью Firebug выяснять, как он общается с сервером, когда меня неожиданно выручил Яндекс со своим Яндекс.Переводчиком. Качество перевода у него было похуже, но зато имелся вполне официальный API и даже готовый модуль для питона.

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

Преобразование формата постов

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

Some people, when confronted with a problem, think: “I know, I’ll use regular expressions.” Now they have two problems.

Jamie Zawinski

Спасла меня, как оказалось, довольно известная библиотека: Beautiful Soup 4. Несмотря на довольно странное название, она позволяет буквально творить чудеса с HTML-кодом. Помимо достаточно богатых возможностей по манипулированию DOM, она умеет искать в нем по самым разным хитрым критериям, вплоть до самописных функций-предикатов.

Этот код сначала находит тег <iframe> и <object>, которые могут быть вставленным кодом youtube, потом ищет перед ним тег <h3>, откуда извлекает название и исполнителя песни, добавляет их в мета-информацию поста и вырезает уже ненужные теги из тела. Как бы я это безумие делал рерулярками — страшно подумать…

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

To be continued…

В следующем посте я подробнее рассмотрю проблему смены структуры URL блога и создания редиректов на месте старых ссылок.

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

И так, технических причин, побудивших меня отказаться от Drupal, которым я пользовался последние 5 лет, было три:

1. Хлопотность обслуживания. Помимо регулярных патчей для самого движка едва ли не каждую неделю выходили обновления для парочки из трех десятков используемых модулей. А автообновления в Drupal 6 предусмотрено не было.
2. Избыточная сложность. Все-таки Drupal предназначен для создания куда более сложных и развесистых сайтов, чем личный блог. Поэтому многие его возможности в лучшем случае играли роль мертвого груза, а в худшем — требовали совершать лишние клики, действия и шанс как-нибудь накосячить.
3. Тяжеловесность. За функционал надо платить, и плата выражается в потребляемой памяти, скорости работы и занимаемом дисковом пространстве. В последний год Drupal завел дурную привычку отжирать до 150 Мб в БД под какие-то свои кэши. И это при том, что объем всего контента этого блога на данный меньше 30 Мб, включая картинки, приаттаченные файлы и так далее. На мой взгляд, это как-то совсем неприлично для скромного блога.

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

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

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

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

Одним из первых таких генераторов стал Jekyll, за которым последовала масса клонов на самых разных языках и с разной специализацией. Вот несколько из них, наиболее известных: Octopress (ruby), Pelican (python), Second Crack (php), Blacksmith (node.js), Nikola (python), Hyde (опять python).

Среди всего этого многообразия я выбрал Acrylamid по трем причинам. Во-первых, он изначально ориентирован на блоги. Во-вторых, из коробки он умеет очень многое из того, что мне было нужно, а значит, не требовал мучительного поиска плагинов на каждый чих. В-третьих, написан он на python, который я знаю гораздо лучше ruby или node.js.

Вот краткий список того, что он умеет:

• markdown,
• живая перекомпиляция сайта при редактировании и локальный предпросмотр,
• перекомпиляция только изменившихся страниц,
• типографика и формулы,
• постраничный вывод списка постов,
• многоязычные посты,
• компиляция LESS,
• интеграция с Disqus
• и много другого полезного.

И самая важная фитча — «живой» разработчик, который активно развивает движок и охотно принимает pull request’ы. Выбор оказался удачным — для удовлетворения всех моих капризов мне хватило нескольких модификаций, которые были оперативно приняты в апстрим.

Однако, техническая разница между acrylamid и Drupal настолько велика, что перенос контента казался задачей очень нетривиальной. Само собой, терять посты и комментарии за 7 лет я был неготов. В качестве дополнительного усложнения задачи служило желание не накосячить в глазах поисковиков, так как смена движка вела к почти неизбежной смене структуры адресов страниц. В следующей заметке я как раз к этим вопросам и обращусь :-)