RubyNoName подкаст нашел постоянных новых ведущих — это Кирилл Шатров и Андрей Дерябин. Они уже выпустили первый выпуск, а также обновили страницу о подкасте, на которой вы можете узнать о них немного больше.

Пока мой коллега Никита Борзых отдыхал в Париже, я записал интервью с Локомотивом DevOps Движения России Александром Титовым для нашего нового подкаста Девопс Дефлопе.

Мы организовали очередную встречу DevOps митапа в Яндексе, она будет бесплатная, пройдет 25 января в офисе Яндекса на улице Льва Толстого. Если вам интересно узнать Chef, Docker и другие инструменты, а также увидеть, как живут инженеры в Яндексе — приходите на митап.

В суете и быстротечности нашей жизни нет ничего неизменного, лишь непостоянство — верный признак того, что жизнь продолжается. Почти два года мы с Иваном Самсоновым бесперебойно раз в две недели выпускали свежий и сочный выпуск RubyNoName подкаста, но в какой-то момент эта деятельность перестала приносить нам обоим радость и счастье. А что есть жизнь, как не попытка успеть за отведенный нам на земле срок испытать как можно больше счастья? Моя жизнь тесно переплелась с Chef, Vagrant и автоматическим управлением инфраструктурой, и это был вопрос времени, когда разработка с помощью Ruby, Rails и их друзей перестанет меня интересовать.

До выхода PostgreSQL 9.3 еще 5 дней, поэтому самое время поговорить не о технических вещах.

28 сентября в Москве в «Цифровом Октябре» пройдет очередная конференция RailsClub. Как и в прошлом году, в этот раз будет много известных иностранных докладчиков, но лучше сходите на сайт, чтобы я не пересказывал здесь всю программу. После конференции, по традиции, будет after party, поэтому планируйте эту субботу так, чтобы у вас осталось хотя бы несколько часов после конференции. Как всегда, я рад буду познакомиться со всеми, кого знаю виртуально или, вообще, не знаю, ведь именно для этого и существуют оффлайновые мероприятия.

Любой блог либо обновляется, либо мертв. Конечно, и этот блог тоже когда-то умрет, но время для этого еще не пришло, так что сегодня мы поговорим о CAP-теореме.

В вольной формулировке это звучит приблизительно так: «Любая распределенная система не может быть одновременно непротиворечива, доступна и устойчива к выходу из строя узлов». За подробностями отсылаю к русскоязчыной статье Ивана Сагалаева.

CAP теорема прекрасна тем, что позволяет взглянуть на многие сложные системы гораздо проще. Более того, она позволяет легко объяснить, почему создать систему, которая «будет правильно работать всегда», невозможно. Но все это было бы просто интересным поводом для размышления, если бы никак не применялось на практике.

Иногда при эксплуатации проекта возникает вопрос, какие запросы в БД выполняются дольше всего или потребляют наибольшее количество времени или ресурсов.

До версии 9.2 неплохой ответ на этот вопрос можно было получить с помощью проекта pgBadger. Если прорваться через достаточно простую процедуру его настройки, описанную в документации, то в результате можно получить достаточно красивый отчет. К сожалению, этот подход имеет достаточно много слабых сторон. Во-первых, чтобы получить полную картину, необходимо писать логи всех запросов к БД, которые при значительной нагрузке отъедают огромное количество дискового пространства, а также производительность дисковой подсистемы. Во-вторых, в сухом остатке получается только суммарное время исполнения всех запросов и их количество. Это полезная информация, но хотелось бы знать много чего еще.

Во-первых, я давно хотел это сделать, а сегодня сделал — теперь блог будет доступен по адресу http://evtuhovich.ru. По старому адресу он тоже будет доступен, но основным теперь будет этот. Дело в том, что этот блог — это единственное место, где я публикую хоть какие-то тексты, поэтому оставлять его на домене третьего уровня мне показалось неправильно.

Во-вторых, 14 июня в Москве пройдет конференция DevConf. На ней в очередной раз я в составе RailClub помогаю организовывать Ruby-секцию. Пока заявок на доклады немного, всего 5, но мы уже работаем над тем, чтобы это была достойная локальная Ruby тусовка, так что приглашаю прийти всех желающих. О докладах я напишу подробнее попозже, когда список окончательно сформируется.

Два дня назад, 13 мая, вышла beta 1 PostgreSQL 9.3. Во-первых, это хороший знак, что уже пора обновляться на 9.2, либо выбирать 9.2 как основную БД. 9.3 планируется зарелизить в третьем квартале 2013 года.

Обо всех новых возможностях 9.3 можно почитать на официальной wiki.

Но чтобы не только почитать, но и попробовать, я напишу здесь, как поставить 9.3 beta 1 на OSX.

В прошлый раз я обещал написать о том, что в проектах с более менее серьезной нагрузкой БД либо помещается в память, либо не работает. Ситуация в современном мире меняется в связи с появлением SSD дисков, но пока что они стоят достаточно дорого, по сравнению со старыми добрыми вращающимися дисками. Чтобы «потрогать» это руками, проделаем несложный тест.

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

Иногда так случается, что на проекте необходимо использовать более одного сервера баз данных. Оказывается, в rails можно достаточно удобно поддерживать актуальность нескольких БД с помощью миграций.