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

9 мая, День Победы — один из самых главных праздников в странах бывшего СССР. По массовости празднования он может соперничать разве что с Новым Годом. Однако, мне кажется, с течением лет акцент этого праздника становится все более и более неправильным. Он превращается в символ военной доблести, военной мощи, величия. Бесспорно, все это было, и это сыграло важнейшую роль для победы как таковой. Честь и память всем, кто сражался за свободу наших родин, и тех, кто трудился в тылу и в оккупации.

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

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

P.S. Специально берег эту песню для сегодняшнего поста.

I’ve never really mentioned this on the Internet, but I’m podcast-addicted kind of person. At the moment I have about 20 different podcasts in my subscription list and I enjoy them very much. Actually, it turned out that listening to podcasts does two important things:

1. You don’t fall completely bored while doing some monotonic work like house cleaning or dish washing.
2. It delivers you most of the important news, keeping you up-to-date at no time cost. You know, you have to wash dishes at some point…

In my list there are two categories of podcasts: general tech news and hardcore-geeky-programming stuff. And actually I love latter the most. This kind of discussions make me thinking, directs me while exploring new technologies, teaches about things far beyond of my scope and so on. Unfortunately, there are not so many shows of this kind.

One of the young and promising podcasts is EaxCast and at this time they are raising funds for second season of the show. I’m not a kickstarter kind of person, but what makes these campaign special, is that collected money would be spent on creating text transcripts of the show. Actually, I know only about two tech podcasts, which make these transcripts. First is Security Now and the second is EaxCast.

Why text transcripts rule? Fucking obvious: it make 1 hour show searchable. When you heard something interesting in the middle of you way to work, you don’t have to scroll through all audio file to find it again. You just open a transcript, hit Ctrl+F and here you are.

Why am I writing this? There are only 4 days left and ~6k rubles to go. It’s 8%, they almost did it. So, if you are a programming geek, if you like what guys doing, than go donate them some money. If you don’t like it, go listen the first season of the podcast, like it and go donate.

Motivational song included.

Today I’m going to announce a pet project, which I’ve been working on for a last few month. It happened so that it’s live for more than two years and it’s the third major release, but I never announced it on my blog. Now I have to fix this.

Meet: Google Cache Browser.

The idea behind this project is pretty simple: when viewing Google’s search cache, click on any link on the cached page is going to send you back to live site, not to cache, and there are many situations when this is not what you want. For example, when you site of interest is under maintenance and you need to find something there, all internal links would be broken, leading you to “Temporary unavailable” page.

This is where Google Cache Browser comes in. It would inject himself into cached page, catch all click on links and redirect you to cached versions of paged they point to. The most beautiful thing is that you don’t have to install any kind of browser extensions: GCB is a pure JavaScript running is your browser.

There are two ways to use GCB:

1. Open cache.nevkontakte.com, put in URL of a page and hit “Go”.
2. Use GCB bookmarklet. It’s designed to take you to the cached version of page you’re currently viewing, plus adding all nice GCB features.

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

Еще раз перечислю причины перехода:

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

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

Я теперь о “последней соломинке”, которая заставила меня принят решение о смене языка. Обычно я стараюсь избегать политических тем, что здесь, что в твиттере, но это не лезет ни в какие рамки. Я говорю об очередном идиотском законе, принятом народными избранниками. Вкратце: если у вас есть страничка в интернете с посещаемостью более 3000 человек в сутки — добро пожаловать в море геморроя реестр, считайте себя СМИ. И хоть у меня посетителей гораздо меньше, я хочу быть подальше от этого маразма.

Напоследок, мое мнение обо всех “цензурных” законах последнего времени:

Пришло время завершить цикл постов о переезде этого блога на статический движок. Я уже успел рассказать о переносе самих постов и о манипуляциях со структурой адресов. Последняя оставшаяся не освещенной тема — перенос комментариев. За 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 блога и создания редиректов на месте старых ссылок.