На «Групоне» мы давно уже переходим с Rails 2.3 на Rails 3.0. На этой неделе перешли — полет нормальный. Но поскольку сразу переход у нас не получился, то мы переходили по частям. И тут возникла проблема, что в rails3 нужен новый devise (1.5.3), которому нужен warden (1.1.1). А в rails2 используется devise (1.0.9), которому нужен warden (0.10.7). И вот этот вот warden стал по-другому сериализовать сессию. А devise стал хранить remember_token в подписанной (signed) cookie. Более того, из самих рельс пропал класс ActionController::Flash::FlashHash, поэтому при десериализации сессии происходило неуловимое исключение в Marshal.load.

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

В третьем квартале 2012 должна выйти версия PostgreSQL 9.2, в которой добавят много интересных возможностей. Среди них — базовая поддержка так полюбившегося всем web-разработчикам формата JSON. На данном этапе появится только возможность проверять JSON на валидность, но судя по списку рассылки, к версии 9.3 будет добавлена возможность строить индексы на JSON объектах подобно тому, как это можно сделать на hstore. Конечно, JSON объекты гораздо сложнее hstore, и как именно и в каком объеме будет реализована поддержка индексов в JSON — пока не ясно.

Давече у нас на Групоне возникла следующая проблема — начала тормозить одна страница в админке. Причем до того сильно, что ее sql запрос стал регулярно появляться в списке медленных запросов в newrelic. Для большей понятности я поменяю название моделей на книги (Book) и авторы (Author), при этом, очевидно, «авторы имеют много книг», то есть связь один ко многим.

Удивительное дело, что я до сих пор не написал про PgBouncer. Как написано на сайте — это «Lightweight connection pooler for PostgreSQL». Я бы первел это следующим образом. PgBouncer — это легкий менеджер соединений для PostgreSQL.

Сегодня я выложил наш первый совместный с Иваном Самсоновым эпизод RubyNoName подкаста (плюсуйте анонс на Хабре).

Хочу сразу сказать, что дело это оказалось далеко не такое простое, как я думал раньше. Начиная с того, что непринужденно рассказывать о новостях в ruby-мире без мыканья, эканья, запинок, фраз «ну» и «как бы» получается у нас гораздо хуже, чем писать код на ruby. И заканчивая тем, что свести две дорожки в редакторе, а потом сделать из этого что-то, что хорошо слушается, вообще для меня пока что очень сложная задача, которая к тому же занимает очень много времени.

В эту пятницу в Москве пройдет конференция .toster, посвященная языку программирования ruby. Меня удостоили большой чести выступать среди 6 известных во всем мире ruby-разработчиков. Если кто-то еще не успел купить билеты, самое время это сделать.

Мне переодически задают вопросы, зачем ходить на конференции, ведь все можно найти в интернете. Мое личное мнение, которое я никому не хочу навязывать, но все же поделюсь, следующее. Во-первых, сама по себе техническая информация — это просто техническая информация. Только поняв интерпретации и взлягды других людей на эту технологию, можно сложить какое-то более объективное мнение о ней. Во-вторых, мы обычно ищем только то, что находится в нашем «поле зрения». И конференция — это способ заглянуть за границы привычного. В-третьих, конференция дает возможность познакомиться живьем и пообщаться с людьми из-за рубежа в расслабленной обстановке. Для меня это, пожалуй, самое интересное. Ну, и конечно, это возможность встетиться с коллегами и друзьями, которые работали раньше вместе с тобою.

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

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

Рассмотрим один из таких модулей - hstore. Этот модуль нужен для того, чтобы в одном поле в БД хранить много значений key/value, фактически, просто какой-то хеш. При этом и ключи и значения могут быть только строками. О том, чем это лучше, нежели просто хранить в текстовом поле сериализованный хеш, я расскажу чуть-чуть попозже. Понадобится это может в том случае, если у вас есть модели с произвольным набором полей.

Очень странно, что я до сих пор не написал о Vagrant — инструменте создания и распространения виртуальных окружений.

Vagrant нужен для одной простой цели — тестировать выкатку и изменение конфигурции. Причем он позволяет делать это очень просто, особенно для Chef и Puppet. Vagrant — это надстройка над платформой виртуализации VirtualBox, которая позволяет легко и быстро создавать виртуальные машины по шаблону.

Работать с ним очень легко. Вы берете какой-нибудь готовый образ ОС (например, отсюда) или создаете свой, который и будет вашим шаблоном. А потом проверяете, как на этот образ накатываются ваши Chef-рецепты, причем можете делать это каждый раз с чистого листа. Конечно, образ должен быть точно такой же, который вы используете в бою, на staging-сервере, на CI-сервере и, вообще, везде. Это позволит вам выловить максимальное количество проблем до того, как они попадут на production. Более того, это гораздо удобнее, чем писать chef-рецепты «вслепую». Все, что происходит тяжело, надо делать часто, чтобы научиться делать это хорошо. Выкатка с изменением конфигурации обычно происходит тяжело. Поэтому стоит тренироваться менять конфигурацию и выкатываться, при этом желательно делать это в «песочнице», а не на сервере, который обслуживает ваших пользователей (и приносит деньги).

Если вы работаете с postgresql и сталкиваетесь с затруднительными ситуациями, ответы на которые даже не ясно, как гуглить, то, скорее всего, вам не хватает каких-то фундаментальных знаний этой БД.