За последние пару лет WordPress из движка для блоггинга превратился в достаточно мощное программное обеспечение, при помощи которого можно создавать функциональные проекты малого/среднего масштаба. Несмотря на то, что изначально движок предназначен для создания блогов, его функционал можно просто расширить при помощи плагинов, коих написано великое множество.

За три года существования этого блога я опробовал на нем разные плагины, и до недавнего времени набор плагинов был стабилен. Ситуация начала меняться спустя некоторое время после выхода WP версии 3.3.1. Разработчики движка постепенно обновляют API, добавляют новые функции, обновляют старые или вовсе удаляют их. В результате, многие плагины начинают работать плохо либо перестают работать вовсе. Конечно же, проблему можно решить, поставив другой плагин. А можно и самому включиться в разработку и поддержку компонента. Другое дело, если разработчик у плагина есть, и ты ждешь от него реакции на протяжении продолжительного времени. Так, например, происходит с плагинами OpenID и Loginza. Эти два замечательных плагина перестали работать после одного из последних обновлений. Касаемо Loginza, плагин, конечно работает, но сыплет Warning'и в лог сервера из-за устаревших функций. В результате, при продолжительной работе в таком режиме через fastcgi (здесь не важно, что именно используется как cgi), скрипт просто прибивается сервером из-за большого количества ошибок. Понятное дело, это тянет за собой весь движок, и сайт становится недоступен для посетителей. С OpenID всё ещё сложнее — он вообще не пашет. То есть никак. И если Loginza можно поменять на что-то, либо потерпеть без него, то для OpenID альтернативы просто нет. Как следствие, приходится использовать другого OpenID-провайдера для целей авторизации. Аналогично было ещё с парой плагинов. В результате, за пару месяцев зимы набор плагинов сократился на пять штук. На данный момент я могу сделать вывод, что функциональность этого сайта определенно уменьшилась. У меня в голове уже бродила мысль о том, чтобы форкнуть OpenID-плагин и допилить его до нормального состояния, но пока я этим делом заниматься не могу. Так что, остаётся только ждать подвижек со стороны авторов.

Code Assist — чрезвычайно удобная и в тоже время настолько привычная и интуитивная штука в современных средах разработки, что некоторые порой просто не знают, как она называется . В Microsoft Visual Studio этот функционал называется IntelliSense. В Eclipse/Aptana — Content Assist. А бывает что и по всякому — и Code Assist, и Code completion, и даже иногда, по аналогии с упомянутым Visual Studio — IntelliSense. В Aptana Studio 3, по сравнению со второй версией, некоторые настройки реализованы иначе. Из-за этого включить Code Assist для какой-либо внешней библиотеки бывает не очень понятно. Когда я писал свой плагин фильтрации постов, я столкнулся с необходимостью подключения исходников WordPress. Копание было недолгим и результативным. Ниже я покажу, как подключить внешнюю php-библиотеку к проекту для получения Code Assist по нужным классам и функциям.

Для начала необходимо зайти в свойства нашего php-проекта через меню Project->Properties и в меню Project Natures поставить галочку напротив PHP:

Таким образом мы заставили Aptana определять web-проект как проект с php-кодом, после повторного посещения настроек проекта там можно будет увидеть специфические для PHP настройки. Теперь нужно подключить внешнюю библиотеку к текущему «Рабочему пространству». Для этого необходимо зайти в Window->Preferences->Aptana Studio->Editors->PHP->Libraries и добавить свою библиотеку:

Нажимаем New user library:

Называем как-нибудь попонятнее и добавляем нужные директории. Как вы можете увидеть на скриншоте, я добавил только wp-admin и wp-includes, где лежат все API-функции WordPress. Если вы ко всему этому добавите директорию wp-content, то вам станут доступны функции плагинов и тем (если такое предусмотрено разработчиками), находящихсяв ней. Жмем ОК, ждем, пока IDE просканирует исходники. Теперь вернемся в настройки проекта (Project->Properties), и в меню PHP Buildpath, на вкладке Libraries отметим галочку «Use project specific settings» и отметим добавленную библиотеку:

Apply, OK. И теперь пробуем в коде:

Если функции импортированной библиотеки не появились в Code Assist, то потребуется перезапуск IDE. После него все встанет на место.

Эту интересную новость я узнал из письма, упавшего мне на почтовый ящик сегодня ночью. Мне вообще было интересно знать, куда движется Twitter последнее время. Учитывая развитие блоггинговых возможностей у конкурентов (Facebook, Google Plus), было бы опрометчиво, на мой взгляд, со стороны руководства Twitter стоять на месте. Трудно рассматривать Posterous в качестве конкурента Twitter, хотя бы по нишевости контента, посещаемости и другим характеристикам. Как следствие, сомневаюсь что это обычное поглощение (как было, например, у Facebook и Friendfeed. В результате покупки Facebook фактически умертвил сервис, о чём я писал тут и упоминал тут). Скорее всего, это именно «приобретение» квалифицированного персонала и работающего функционала для развития основного проекта (похоже, это такие «модные» веяния в менеджменте IT-компаний последнее время). Безусловно, что Twitter имеет несколько иную направленность, нежели Facebook или Google Plus. Однако же, кое-чем их функционал всё-таки перекликается. Плюс, я не исключаю возможность того, что руководство Twitter, подгоняемое волной развития и роста популярности социальных сетей, может усилить социальную составляющую своего сервиса. Хотя, учитывая появление в сети таких проектов, как Diaspora или даже DuckDuckGo, стоит отметить, что эта самая волна многим уже порядком надоела, и, видимо, за максимумом постепенно последует спад. Короче, посмотрим.

Утилитка Spawn-FCGI, предназначенная для запуска процессов в FastCGI-режиме и являющаяся частью проекта Lighthttpd, уже давненько используется многими без самого Lighty. Связано это с её чрезвычайной полезностью, стабильностью и быстротой работы. Три года назад разработчики Lighthttpd даже вынесли её в отдельный проект. Не смотря на растущую популярность PHP-FPM, Spawn-FCGI находит своих «клиентов». Причем, не только среди запускающих посредством неё PHP-процессы. Недавно мне понадобилось поднять именно Spawn-FCGI для PHP на Debian-сервере. Проблемка в том, что пакет, поставляющий утилиту, не содержит в себе так необходимого для нормального управления init-скрипта. Об этом, кстати, есть баг-репорт. Неприятность затрагивает Debian и, как следствие, Ubuntu и, возможно, её производные. Поскребя по интернету, я нашел-таки скриптик от народных умельцев. Кое-чего в нём для меня не хватало, так что я устранил этот недостаток. Ниже — скрипт с отсебятинкой, работает на Squeeze и не жалуется.

Скопировать текст в файл, файл поместить в директорию /etc/init.d/, накинуть прав на выполнение:

Прописать в автозагрузку:

Готово. Само собой, для работы скрипта требуется наличие Spawn-FCGI и CGI-интерфейса, процессы которого будут плодиться. В данном случае, я использовал php-fastcgi. Как я упоминал выше, Spawn-FCGI, в общем-то, без разницы, какие CGI-процессы плодить. Это может быть и CGI для Python, например. Кстати, предпоследняя версия этого скрипта как раз была предназначена для запуска CGI для Mercurial — а это Python. Для того, чтобы этот скрипт запускал что-то другое, достаточно поменять значение переменной FCGIAPP на нужное, скопировать скрипт под другим именем и опять прописать в автозагрузку. Скрипт изменен таким образом, чтобы дополнительные настройки для него можно было менять, не редактируя сам скрипт — через файл /etc/default/<your filename>.

Поскольку об этой мелочи я постоянно забываю, я решил написать про неё в блог. Речь идет о Java-плагине для браузеров в Ubuntu/Mint. Этот плагин можно установить при помощи aptitude:

Однако, этого недостаточно, чтобы плагин был обнаружен и «воспринят» браузером. Для этого нужно создать символьные ссылки на библиотеку плагина для нужных браузеров. Причём, от дистрибутива к дистрибутиву путь, по которому размещён этот файл, изменяется. Поэтому, перед тем как раскидывать линки, лучше уточнить путь к файлу libnpjp2.so. В Linux Mint 11/Ubuntu Natty amd64 библиотека плагиина размещается по пути /usr/lib64/jvm/java-6-sun/jre/lib/amd64/. В Linux Mint 12/Ubuntu Oneiric этот путь уже эквивалентен /usr/lib/jvm/java-6-sun/jre/lib/. Eсли платформа не amd64, а x86, то путь тоже поменяется. Само собой, что нужно, чтобы браузеры и библиотека были скомпилированы под одну платформу. Для Opera директория с плагинами обычно размещается по пути /usr/lib/opera/plugins, для Firefox — /usr/lib/mozilla/plugins. Туда и нужно линковать. Выглядеть это будет примерно так:

Real deal от Google, по идее, «подхватывает» этот плагин автоматически. Отмечу, что я использовал для примера выше путь к libnpjp2.so для Mint 11/Ubuntu Natty.

После создания символьных ссылок следует перезапустить браузеры, чтобы они подключили плагин. У Opera, на месте, где должен загружаться апплет,  может появиться сообщение, что плагин не обнаружен. Чтобы заработало, нужно просто покликать по этой области. Chrome у меня пожаловался на то, что плагин устарел. Возможно, это было связано с тем, что уже есть седьмая версия Java.  В любом случае, единственную альтернативу запуску апплета, которую сейчас может предложить Chrome — установку Java из самораспаковывающегося архива либо из rpm-пакета — для deb-систем нет смысла использовать.

Сегодня обнаружил пренеприятную вещь. Если в WP, будучи авторизованным, производить какие-либо действия, через некоторое время сайт перестаёт отзываться и выпадает в осадок на непродолжительное время. После этого всё опять начинает работать, как ни в чём не бывало, до следующего такого же события. Я полез в логи в поисках источника проблемы. В /var/log/syslog я нашел исчерпывающую информацию:

Оказалось, что это полезняшка-Suhosin прибивает скрипт wp-admin/admin.php по причине того, что последний по непонятной причине начинает жрать очень уж много памяти. Гораздо больше, чем задано в настройках PHP. Начав копаться в движке, я обнаружил, что разработчики весьма щедро одарили свой движок памятью (wp-includes/default-constants.php:27):

Подобная запись присутствовала в WP и раньше. Тогда значение просто было жёстко прописано в те же 256Мб. В конфиге php у меня установлено максимальное значение в 128Мб. Именно по этой причине Suhosin и валил выполняющийся скрипт.

На данный момент я не очень представляю, чего же такого делает admin.php, что требует больше 128 мегабайт памяти. Особенно учитывая, что это происходит во время отправки комментария. Не смотря на то, что скрипту требуется память, я решил не раздвигать установленные в 128Мб рамки. Скорее наоборот, я решил придавить WordPress этими 128 мегабайтами. Как видно из кода выше, это совсем нетрудно сделать — достаточно определить константу WP_MAX_MEMORY_LIMIT в wp-config.php:

Тогда вышеупомянутый код в wp-includes/default-constants.php не будет выполняться. Конечно, это полурешение. Более того, я ожидаю, что, если скрипту понадобится больше 128Мб, он также будет убиваться, но уже интерпретатором PHP. Однако, я все же посмотрю, как оно будет работать.

У Amazon есть много вариантов использования их вычислительного облака. И это относится не только к широкой линейке тарифов. Можно сказать, что количество тарифов можно умножить на два, поскольку инстансы бывают двух типов — on-demand и reserved. Их отличие только в стоимости. Первый удобно заказывать, когда необходимо взять вычислительную мощность на время, меньшее чем 1 год. В других случаях действительно выгоднее брать reserved-тип либо комбинировать оба. В принципе, ничто не мешает гонят on-demand instance годами, но финансовые потери в такой ситуации будут существенны, да и глупо это. Например, я подсчитал, что примерная месячная стоимость on-demand t1.micro с параметрами как на Free Tier будет составлять около $15.76 (я рассчитывал так, что ресурсы будут израсходованы по максимуму):

• Собственно вычислительная мощь: 0.48 * 30 * 12 = 172.8
• 10 ГБ EBS: 0.1 * 10 * 12 = 12
• 1 млн. I/O-операций на EBS: 0.1 * 12 = 0.12
• 1 ГБ S3 storage для EBS: 0.14 * 12 = 1.68
• 14 ГБ исходящего трафика (потому, что первый ГБ трафика ежемесячно бесплатен): 0.12 * 14 * 12 = 20.16

В год это $206.76 — дешевле, чем самый дешевый тариф от Linode.com. У Linode, правда, свои прелести есть. Например, 200 ГБ трафика дают на самом дешевом тарифе. Тем не менее, по сравнению с тем же AWS, on-demand выглядит дороже, когда узнаешь цену на reserved instance. Она составляет $54/1 год и $82/3 года. В принципе, можно было бы даже не учитывать всё, что навешивается дополнительно, достаточно сравнить первую цифру из расчетов с этими двумя. Что выбрать — 1 on-demand или 3 reserved t1.micro на год и пачку пива на вечер? :)

Хорошо, цифры смотрятся красиво, так как купить зарезервированный инстанс?

Тут есть два варианта. Первый — воспользоваться EC2 API Tools. Второй — из консоли управления AWS. Первый вариант я не пробовал, но всё же доверяю написанному. Быть может, кто-то из вас его попробует и потом поделится в комментариях опытом с благодарным Олежкой и читателями его блога . Кстати, если вы вознамерились делать первый вариант, и у вас при этом есть Ubuntu, то пользоваться ссылкой, которую я дал в начале абзаца, необязательно. EC2 API Tools есть в стандартных репозиториях Ubuntu, и проще поставить их традиционным способом:

Второй вариант — из консоли управления AWS.

По цифрам на картинке — Закладка «EC2» -> В категории «Instances» кликнуть по «Reserved instances» -> Кликнуть по кнопке «Purchase Reserved instances»:

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

На снимке показаны те параметры, которые были нужны мне. Внимательно выбирайте нужные вам параметры. Тут зарыта маленькая, но немного воняющая собачка. Дело в том, что на самом деле вы покупаете не инстанс. Вы покупаете гарантию того, что какой-то из ваших инстансов (а может и все) будет работать непрерывно всё то время, которое вы оплатили. Проще говоря, после нажатия кнопки Continue вы не получите интерфейс для выбора AMI и прочей требухи для инстанса. После получения от вас подтверждения в ваших намерениях вам просто скажут «Всё окей, чувак, мы списали денежки с твой карточки, жди результата».

Результатом будет появление ваших инстансов в категории Reserved instances, которая ранее пустовала. Если у вас такого инстанса нет (еще раз, внимательно смотрите на параметры резервируемых инстансов), вам необходимо его создать. В моей ситуации я уже имел работающий инстанс и во время резервирования указал именно его параметры. Инстанс появляется в категории Reserved не сразу, а в течение примерно 1 часа.

Вообще метод предоставления услуги весьма интересный. Вот, например, случай, в котором он сработает на клиента: допустим, у вас есть t1.micro в us-east-1a c Linux на борту и он зарезервирован. Вам понадобилось полностью обновить ПО, вместе с операционной системой. Разумеется, для этого нужно погасить старый инстанс, создать новый (с теми же параметрами, что и у старого, т.е. Linux-инстанс t1.micro в зоне us-east-1a) с нужной ОС и накатить на него софт. Так и делаете. В результате у вас два инстанса. Удаляете старый, и по прошествии определенного времени уже новый становится зарезервированным. Таким образом, вы не теряете уплаченные деньги, вам не нужно кантовать саппорт с просьбами переключить что-то на что-то, чтобы вернуть деньги или направить их в нужное «русло». Вы как будто поменяли плашку оперативной памяти в своем компьютере. Подробнее про то, как оно работает, можно почитать в этой ветке форума об AWS.

Однако, есть у меня один вопрос. Скажем, есть два одинаковых инстанса, находящихся в одной зоне. И вы покупаете резерв только для одного. Получается, что один резервируется, и один остается on-demand. Поскольку процесс резервирования происходит в режиме, который не контролируется пользователем, неизвестно, какой именно из этих двух инстансов будет зарезервирован. Это не имеет значения, даже смысла, когда два инстанса идентичны вплоть до выполняемых ими задач. Однако же, это имеет значение в противном случае.

UPD: Каюсь, был невнимателен, когда читал их документацию. Дело в том, что, покупая у Amazon reserved-инстансы, вы покупаете серьёзную скидку за час работы инстанса. Т.е., после покупки reserved-инстанса, вам всё равно будут начислять денежки за пользование, но, конечно же, в итоге получится дешевле, чем on-demand. Так что, к стоимости вычислительной мощи reserved-инстанса нужно прибавить ежемесячное пользование. Для t1.micro это (на данный момент — декабрь 2011 года) 0.007 * 24 * 30 (тут, понятное дело, я взял усредненно количество дней). Даже при таком раскладе получается дешевле, чем, наверное, везде.

Вы, наверное, думали, что под заголовком много всякой писанины про геморрой с установкой и настройкой? Нет, всё гораздо проще — php-fpm просто нет в репозиториях по умолчанию для Debian Squeeze. Это который 6. Забавно, я отлично помню кодовые имена для Debian и совершенно не помню, к каким версиям они относятся. Для Ubuntu же всё наоборот . Чтобы установить это расширение, нужно добавить сторонний репозиторий. Например, этот: http://packages.dotdeb.org. Добавляем репозиторий и причиндалы:

Не забыть обновить список:

Теперь можно ставить:

Вот и всё.

Даже не предполагал, что в Linux Mint столкнусь с такой проблемой. Команда разработчиков этого дистрибутива вылизывает настройки интерфейса в Ubuntu до такой степени, что, вне зависимости от того, какая gui-библиотека была использована при написании программы, эта программа выглядит практически также, как и GTK-приложения. В результате, графический интерфейс Linux Mint выглядит взрослее, чем интерфейс его родителя. Однако же, я всё-таки напоролся на проблему со шрифтами. Вот как она выглядела:

Как видно на снимке, кириллические символы отображаются каким-то шрифтом с засечками с невероятным расстоянием между символами, в то время, как с латинскими символами всё в порядке — они отрисовываются тем шрифтом, который задан в настройках. Проблема возникла после того, как я поставил дополнительные ttf-шрифты из стандартного репозитория. Я не спроста упоминал GTK в начале заметки, т.к. эта ситуация наблюдается в QT-приложениях, например qtconfig-qt4 (на снимке вверху), Gwenview и Skype. Приложения же, использующие GTK для отрисовки интерфейса, отображаются при этом нормально. Собственно настройки шрифтов для QT регулируются в qtconfig. Однако, это не касается случаев, когда на закладке «Внешний вид» выбрана тема GTK+, либо пользовательсткие настройки, как это было у меня. Поскольку это Linux Mint, очевидно, что под «Пользовательскими настройками» имеется в виду та же тема GTK+, только, может быть, «подкрученная». Короче, в такой ситуации QT использует настройки шрифтов из настроек GTK. Однако в них я ничего не менял, шрифт там оставался стандартный — Sans — который, разумеется не имеет засечек  .

Скорее всего, QT в каких-то своих умолчальных настройках, которые недоступны либо труднодоступны пользователю, имеет умолчальное же семейство шрифтов. Это семейство шрифтов и используется при отрисовке gui. В моем, а возможно и во всех случаях, это оказалось семейство sans-serif — без засечек. Я предполагаю, что после установки дополнительных шрифтов, QT каким-то непонятным образом не нашла шрифт Sans (а может никогда раньше и не находила) и использовала первый попавшийся sans-serif шрифт. Который, в свою очередь, оказался без поддержки кириллицы; что привело к откату QT на первый попавшийся шрифт с поддержкой кириллицы. Смахивает, кстати, на Georgia. Но установить, что это за шрифт, конечно, трудно. Как и то, какой шрифт без засечек использовался для латинских символов. Потому что много шрифтов, которые называются по разному, но отличаются один от другого в незначительных деталях.

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

Заработало нормально :)

Тем не менее, этот обходной путь не решил проблему, а лишь скрыл её. Если кто-нибудь знает, как заставить QT отрисовывать нормально gui с тем шрифтом, который задан в GTK, отпишитесь, пожалуйста  .

Сегодня понадобилось развернуть сайт, построенный на MODx Evolution, на сервере под управлением Nginx. Ниже — конфиг для этого движка. Строки в угловых скобках < и > нужно заменить на свои значения.

Напоследок замечу, что данная конфигурация работает на Debian-системах, для Nginx версии 0.8.54 и MODx ветки Evolution версии 1.0.5. Стоит иметь в виду, что со временем что-то может измениться.