Finally, I’ve completed transition of this blog to GitHub pages, planned over two years ago. I did the first step — migration to a static site engine (specifically, Acrylamid) — back in March 2014. And since than I’ve been saying to myself “one day I must move it to a GitHub as it’s a best free hosting for a static site”.

I couldn’t tell for how long I’d continue slacking like this, but now I had to do this. This site was hosted at free hosting service provided by EOMY.net since it’s very beginning and recently I’ve received a notification, that EOMY shuts down it’s shared hosting, completely focusing on VDS. It’s a bit sad news, as EOMY managed to provide fantastically stable and reliable hosting for all this years, so great thank you for them and good luck with VDS business!

By the way, I have plans on implementing an automated process of site generation and deployment using TravisCI the way it’s done for GCB-JS. If i do this, I’d be able to blog right from GitHub interface, which would be pretty cool :-)

In a past few years I’ve been using C++ as my main programming language and during this time I’ve been in constant search for better IDE for it which would run on Linux. I was very happy when Jetbrains released CLion IDE and immediately gave it a try. Though there is a lot to improve yet, I’d say that it has best autocompletion and modern C++ support among C++ IDEs on Linux. The only problem I had with it was a build toolchain which it uses.

Currently CLion supports only CMake projects (with is totally fine for me) with GNU Make generator (which is sad). When using CMake, I always preferred Ninja build system, especially for large projects like one I work on as my main job. For some reason Make does not a very good job at incremental builds. For example, even if there is nothing to rebuild, it spends 5 seconds to only verify this fact, which is pretty annoying. On other hand, Ninja does this in like 200 ms.

Unfortunately, CLion developers currently have no plans on supporting Ninja (I realize that they have many things to do way more important than Ninja support), so I decided to solve this problem by myself.

CMake-Ninja wrapper for CLion

I’ve found a kind of solution for my problem on internet but it had two very critical drawbacks:

1. You meed to edit manually CMake cache for each project you work on.
2. You have to run cmake -G Ninja manually eash time you add or remove files from your project.

After messing around CMake and ~/.clion11 directory for a while I’ve came up with a simple python script which wrapped around CMake binary used by CLion, replacing -G "Unix Makefiles" command line option with -G Ninja. It did work in terms of making CLion using Ninja for building a project and didn’t require any additional actions from me unlike previous solution. Unfortunatelly, it absolutely broke autocompletion support in the IDE, since it relied upon some artifacts, which Unix Makefiles generator was producing.

After some trial and errors I modified my script to act according following rules:

1. Whenever it’s called outside of CLion’s private directory (~/.clionXX) or there is no -G option in command line, it simply passes control over to CMake.

2. If there is -G option, it does some black magic to make me, CMake and CLion happy:

   1. First, it calls real CMake with original arguments, producing Makefiles required by CLion.
   2. Then it alters CMakeCache.txt to make CMake think that previous generator used was Ninja, not Unix Makefiles.
   3. Finally, replace “Unix Makefiles” occurrance in generator name with “Ninja” and call CMake again.

You may grab the script on GitHub. I’ve tested it on Linux and Python 2.7 but I suppose it should work on Windows and Mac too, maybe with minor modifications. Please, let me know in comments if it worked for you :-)

Finally, this script has several imperfections, which I’ll fix in future. One of the most important is that it currently mizes stderr and stdout of CMake which seems to confuse CLion a little bit when dealing with invalid CMakeList.txt file.

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

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.