Иногда мне кажется, что большинство инженерных историй похожи как две капли воды. Вот и эта история началась с того, что в одном большом отчете цифры не сходились раза в два. Мысленно закурив трубку, как Шерлок Холмс, я взялся за дело. Вот таким образом выглядела модель, по которой считались цифры (я опускаю ненужные подробности). class OfferDescription < ActiveRecord::Base has_many :children, :class_name => 'OfferDescription', :foreign_key => :parent_id end В отчете данные группировались по родительским объектам OfferDescription.

Так сложилось, что у нас накопилось достаточно много старых исключений в airbrake — сервисе по сбору и хранению исключений. Ошибки эти не то, чтобы мешали, но мозолили глаза. И закрыть их руками не представлялось возможным, тем более, что в airbrake это реализовано очень неудобно — необходимо открыть отдельную страницу с исключением, и там тыкнуть на достаточно неудобный самописный элемент управления. Когда такую операцию надо сделать несколько сотен раз, автоматически опускаются руки.

Тема этого поста навеяна обсуждением пакетных менеджеров в рассылке Erlang. К сожалению, обсуждение завяло, так и не успев начаться.

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

Если вы делаете обычные бэкапы и запускаете в час ночи pg_dump, а в час дня ваш сервер БД умер, то вы потеряете данные за 12 часов и доверие ваших пользователей. Для многих web-сервисов такой сценарий неприемлем, и, чтобы минимизировать потери данных, стоит использовать непрерывный бэкап.

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

Если вы делаете обычные бэкапы и запускаете в час ночи pg_dump, а в час дня ваш сервер БД умер, то вы потеряете данные за 12 часов и доверие ваших пользователей. Для многих web-сервисов такой сценарий неприемлем, и, чтобы минимизировать потери данных, стоит использовать непрерывный бэкап.

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

На Групоне у нас есть внутренняя страница, на которой динамически отображаются данные о продажах по различным городам. Результаты этой страницы зависят от параметров, которые передаются в метод show. А потом эта страница динамически обновляется с помощью ajax-запросов. # dashboard.rb class Admin::DashboardsController < Admin::BaseController layout "admin" def show # Здесь сложные-сложные запросы к БД if request.xhr? render 'show', :layout => false end end end Поскольку запросы очень тяжелые, да и сама страничка непростая, то отдача ее сильно нагружала БД и app-сервера.

Для выкатки (deploy) я не знаю другого инструмента, кроме capistrano. Слышал про vlad, но в глаза его никогда не видел. Использовать capistrano имеет смысл при любом размере проекта, будь то сайт из 3-5 страничек, или что-то большое. Во втором случае отказ от использования capistrano — форменное безумие с моей точки зрения. Начать знакомиться лучше всего отсюда. Если вкратце, то заходим в каталог проекта и набираем: capify . Дальше правим файл config/deploy.

Очень часто для небольших проектов нет необходимости усложнять инфраструктуру с использованием chef-server. Существует мнение, что chef server, вообще, не нужен, и многие аргументы в пользу этой идеи кажутся мне вполне убедительными. Для людей, которым нравится DSL chef и не нужен chef server, есть chef-solo. Чтобы готовить с его помощью, нужен специальный нож — knife-solo. Это инструмент, который значительно упрощает использование chef-solo. Для начала поставить knife-solo gem install knife-solo Если у вас есть уже готовый репозитарий для chef, как, например, наше тесто, то следующий шаг можно пропустить.

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

Расскажу одну очень поучительную и одновременно типичную историю, которая случилась со мною года 3 назад. Однажды один из наших серверов вышел из строя. Казалось бы, обычная ситуация, но беда была в том, что работа приложения была сильно завязано на 10-15 различных cron-задач, которые были прописаны на этой машине. Еще большая проблема была в том, что писались скрипты, которые вызывались по cron, различными людьми, многие их которых к тому времени не работали в компании.

31 марта буду выступать на конференции CodeFest. Мой доклад «Как мы делали Групон» будет в 17:05 во втором зале. А второго апреля я проведу мастер-класс «Устройство и оптимизация Postgresql». Я хочу выразить большую благодарность организаторам конференции за их работу. Поскольку у меня есть опыт в этой области, я понимаю, какой объем работы надо проделать, чтобы привезти докладчиков со всех концов России в Новосибирск. Верю, что конференция пройдет продуктивно и на позитивной волне.

Расскажу одну очень поучительную и одновременно типичную историю, которая случилась со мною года 3 назад. Однажды один из наших серверов вышел из строя. Казалось бы, обычная ситуация, но беда была в том, что работа приложения была сильно завязано на 10-15 различных cron-задач, которые были прописаны на этой машине. Еще большая проблема была в том, что писались скрипты, которые вызывались по cron, различными людьми, многие их которых к тому времени не работали в компании.

Термин «Непрерывная поставка ПО» (Continuous Delivery, CD) прочно вошел в обиход в конце 2010 году, после выпуска одноименной книги. В книге описываются достаточно простые идеи о том, как сделать процесс поставки ПО таким, чтобы его можно было выкатывать после каждого комита. И, хотя прошло уже больше четырех лет, до сих пор такой подход к поставке ПО не стал стандартом. По вполне понятным причинам множество компаний продолжает использовать кустарное либо мануфактурное производство, вместо перехода к конвейеру.

О непрерывной интеграции (Continuous Integration) можно почитать у Мартина Фаулера (Martin Fowler) здесь. В друх словах, это практика постоянной интеграции наработок каждого программиста. Обычно это заключается в том, что на какой-нибудь машине постоянно (после каждого изменения в исходных кодах) собирается проект и прогоняются все тесты. Результаты этих действий высылаются разработчикам по почте. Это позволяет постоянно сохранять проект в относительно рабочем состоянии. Удобным инструментом непрерывной интеграции является CruiseControl. К сожалению в своей оригинальной версии он поддерживает только систему контроля версий svn.

О непрерывной интеграции (Continuous Integration) можно почитать у Мартина Фаулера (Martin Fowler) здесь. В друх словах, это практика постоянной интеграции наработок каждого программиста. Обычно это заключается в том, что на какой-нибудь машине постоянно (после каждого изменения в исходных кодах) собирается проект и прогоняются все тесты. Результаты этих действий высылаются разработчикам по почте. Это позволяет постоянно сохранять проект в относительно рабочем состоянии. Удобным инструментом непрерывной интеграции является CruiseControl. К сожалению в своей оригинальной версии он поддерживает только систему контроля версий svn.

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

Для выкатки (deploy) я не знаю другого инструмента, кроме capistrano. Слышал про vlad, но в глаза его никогда не видел. Использовать capistrano имеет смысл при любом размере проекта, будь то сайт из 3-5 страничек, или что-то большое. Во втором случае отказ от использования capistrano — форменное безумие с моей точки зрения. Начать знакомиться лучше всего отсюда. Если вкратце, то заходим в каталог проекта и набираем: capify . Дальше правим файл config/deploy.

На «Групоне» мы давно уже переходим с 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-ветке, который конвертил сессию третьих рельс во вторую. Пользуйтесь с осторожностью.

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

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

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

Тема этого поста навеяна обсуждением пакетных менеджеров в рассылке Erlang. К сожалению, обсуждение завяло, так и не успев начаться.

Когда у вас есть две ветки разработки, которые достаточно сильно друг от друга отличаются, периодически возникают проблемы с их слиянием (merge).

По-моему, в «Прагматичных программистах» было написана фраза, которую я часто люблю повторять: «Программист должен в совершенстве владеть двумя инструментами — текстовым редактором и системой контроля версий». Программист работает с текстом, особенно программист, который пишет на высокоуровневом языке, таком как Ruby. Зачастую можно не вдаваться в подробности того, что происходит внутри, хотя иногда, конечно, надо. Так вот, текст надо уметь изменять, а потом этими изменениями как-то обмениваться со своими коллегами. Про текстовый редактор я рассказывал немного раньше, а сегодня я хочу рассказать про систему контроля версий git.

Допустим, вы сделали commit в git, но поняли, что он недостаточно хорош. В таком случае можно продолжить правки, а при следующем коммите набрать git commit -a --amend Ключ --amend (улучшить, в переводе с английского) позволяет добавить к последнему коммиту новые изменения. Если вы сделали commit в git, но поняли, что он достаточно плох, то можно сделать и так: git reset --soft HEAD^ Эта команда отменит последний коммит (но не изменения, которые вы внесли, они сохранятся).

Представим следующую ситуацию (она постоянно возникает у нас при разработке). У нас есть ветка master в git, а в день релиза мы создаем ветку b1. Мы добавляем какие-то изменения в ветки b1 и master. И тут вдруг (хотя слово «вдруг» не очень подходит к регулярным событям) менеджмент решает добавить что-то из master в релиз. Если комитов было мало, то можно воспользоваться git cherry-pick (если их несколько, то может помочь ключ -n).

Сегодня у нас перестали ходить отчеты по почте. Ходили, ходили и вдруг перестали. Kлассы выглядели следующим образом (ненужные подробности я опустил). class ReportSender def initialize(report_instance) @report_instance = report_instance @params = report_instance.params @emails = @params.delete(:mail_to) end class Report def initialize(params = {}) @params = self.class.default_values.merge(params) end К классам отчетов были добавлены значения по-умолчанию, и, как оказалось, из-за них были все проблемы. Хеш params, которые передается в класс Report — это тот самый params из контроллера.

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

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

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

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

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

Очень часто для небольших проектов нет необходимости усложнять инфраструктуру с использованием chef-server. Существует мнение, что chef server, вообще, не нужен, и многие аргументы в пользу этой идеи кажутся мне вполне убедительными. Для людей, которым нравится DSL chef и не нужен chef server, есть chef-solo. Чтобы готовить с его помощью, нужен специальный нож — knife-solo. Это инструмент, который значительно упрощает использование chef-solo. Для начала поставить knife-solo gem install knife-solo Если у вас есть уже готовый репозитарий для chef, как, например, наше тесто, то следующий шаг можно пропустить.

Хотя я так и не написал толком, как пользоваться PgQ и Londiste, но уже написал плагин, который облегчает его использование вместе с рельсами. http://github.com/evtuhovich/pgq/tree/master В README всё написано на плохом английском (с хорошим английским у меня плохо). Совсем скоро я добавлю туда возможность прогонять миграции на master и slave базах данных одновременно. Тогда при очередной выкатке необходимо будет сделать только rake londiste:update в самом конце, после того, как все миграции прогонятся.

В продолжении темы о нескольких базах данных в одном rails-приложении расскажу о том, как изящно перенести одну большую таблицу в другую БД postgresql. Пусть у нас есть таблица messages с большим количеством данных (10 миллионов записей), которые мы решили перенести на другой сервер. Мы сделали, как написано в статье, указанной выше, а также создали в новой БД таблицу messages с такой же структурой. Теперь с помощью londiste настраиваем репликацию из первой БД во вторую для таблицы messages (об этом я напишу подробнее попозже, пока же можно прочитать об этом у Андрея Стихеева в рассылке ror2ru).

Все ситуации, о которых я здесь пишу, встретились мне в повседневной работе. Единственное, что я делаю — меняю название классов, чтобы не утруждать моего читателя незнакомой для него предметной областью. Итак, у нас есть следующие модели: # shop.rb class Shop < ActiveRecord::Base has_many :categories cached_methods do def wait_orders_count Order.count :conditions => {:status_id => Order::WAIT} end def paid_orders_count Order.count :conditions => {:status_id => Order::PAID} end def bad_orders_count Order.count :conditions => {:status_id => Order::BAD} end end end class Category < ActiveRecord::Base belongs_to :shop has_many :products end class Product < ActiveRecord::Base belongs_to :category has_many :orders end class Order belongs_to :product end Методы внутри cached_methods выполняются в том случае, если значение для них не нашлось в кэше (например, в memcached).

Я давно мечтаю об Ubuntu, которая работает так же хорошо, как OSX. К несчастью, большинство пользовательских программ в Ubuntu хуже, чем в OSX, а что касается серверной части - OSX очень сильно отстает от Ubuntu (Debian).

К примеру, по-умолчанию, в Postgresql в OSX сломана сортировка русских слов. Решение я нашел здесь.

Тема этого поста навеяна обсуждением пакетных менеджеров в рассылке Erlang. К сожалению, обсуждение завяло, так и не успев начаться.

Вчера я разворачивал наше приложение в системе CI Jenkins, и обнаружил, что bundler не находит gem paperclip. В Gemfile была явно прописана версия 3.0.1. Зайдя на rubygems, я увидел, что эту версию гема его создатели удалили, а версия 3.0.2 и старше не поставилась, выругавшись на то, что ей нужен ruby 1.9.2 и старше.

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

Извечная проблема о том, как добавлять и обновлять плагины в vim решилась благодаря легендарному Tim Pope. Сегодня утром узнал от Ярослава Маркина о существовании pathogen. Статья на английском о том, как им пользоваться, лежит здесь. Правда, я потратил полчаса, чтобы догадаться, что надо добавить call pathogen#runtime_append_all_bundles() в файл ~/.vimrc. После установки pathogen.vim в ~/.vim/autoload можно хранить все плагины в папке ~/.vim/bundle, причем каждый в своей папке. А еще огромный плюс - в конце этой статьи код, который позволяет обновлять все плагины одной командой.

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

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

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

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

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

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

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

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

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

Хотя я так и не написал толком, как пользоваться PgQ и Londiste, но уже написал плагин, который облегчает его использование вместе с рельсами. http://github.com/evtuhovich/pgq/tree/master В README всё написано на плохом английском (с хорошим английским у меня плохо). Совсем скоро я добавлю туда возможность прогонять миграции на master и slave базах данных одновременно. Тогда при очередной выкатке необходимо будет сделать только rake londiste:update в самом конце, после того, как все миграции прогонятся.

При большом количестве запросов к приложению (в широком смысле этого слова) иногда целесообразно ``размазать’’ пиковую нагрузку во времени. Для этого удобно использовать очереди. То есть, если какое-то запрос наверняка должен быть выполнен, но не имеет значение произойдет это прямо сейчас или чуть попозже, можно создать событие в очереди. И когда до этого события дойдет очередь —– оно будет выполнено. Таким образом можно развести сложные запросы во времени. Очереди подходят для таких задач, как, например, рассылка большого количества сообщений и обновление различных счетчиков в БД (если их актуальность не очень критична).

RubyNoName подкаст нашел постоянных новых ведущих — это Кирилл Шатров и Андрей Дерябин. Они уже выпустили первый выпуск, а также обновили страницу о подкасте, на которой вы можете узнать о них немного больше. Пока мой коллега Никита Борзых отдыхал в Париже, я записал интервью с Локомотивом DevOps Движения России Александром Титовым для нашего нового подкаста Девопс Дефлопе. Мы организовали очередную встречу DevOps митапа в Яндексе, она будет бесплатная, пройдет 25 января в офисе Яндекса на улице Льва Толстого.

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

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

Vim — прекрасный редактор, который я использую для разработки на Ruby и Rails. Его можно использовать в чистом виде, но если добавить немного плагинов, то удобство работы значительно возрастает. Об этом я и хочу рассказать, правда рассказ получится длинным. Я выступал на последнем RailsClub’е с докладом Vim Or Die (посмотреть его можно на univertv.ru), в котором неплохо раскрыл тему Vim и полезных плагинов. Cами слайды, которые малополезны без видео, можно найти на slideshare.

Так сложилось, что я управляю транспортным средством больше, чем час в день (на работу, на тренировку, домой). И я давно уже хотел слушать английские тексты в это время, потому что музыка часто надоедает. Я пробовал слушать «обычные» тексты, но потом подумал, что гораздо интереснее слушать то, что тебя волнует. Поэтому я порылся в дебрях интернета и нашел следующие подкасты, которые я регулярно слушаю. The Ruby Show — выходит по вторникам, длится минут 15-20.

Мой коллега Егор Рогов из ППГ недавно издал книгу “PostgreSQL изнутри”. Книгу можно бесплатно скачать в формате pdf на сайте Postgres Professional. Для любителей читать книги, сделанные из переработанных трупов зверски убитых деревьев, ее без труда можно найти на сайте “ДМК Пресс”.

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

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

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

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

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

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

Чтобы рассказать о тонких моментах pg_repack, мне понадобится немного углубиться в тему блокировок в PostgreSQL. Конечно, лучше всего начать читать про них в официальной документации. Для этой статьи достаточно понимать, что эксклюзивная блокировка (ACCESS EXCLUSIVE LOCK) препятствует выполнению всех операций, включая SELECT, и она нужна для операции ALTER TABLE.

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

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

Вообще, сам не узнаю себя, уже ровно месяц прошел с выпуска Postgresql 9.2, даже вышло обновление 9.2.1, исправляющее некоторые баги, а я все еще ничего не написал об этом.

Поэтому сегодня рассказ будет о Index Only Scan — самом заметном, по моему мнению, изменении в 9.2. Кстати, именно это изменение стоит первым в Release Notes, а значит я не одинок.

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

Если вы делаете обычные бэкапы и запускаете в час ночи pg_dump, а в час дня ваш сервер БД умер, то вы потеряете данные за 12 часов и доверие ваших пользователей. Для многих web-сервисов такой сценарий неприемлем, и, чтобы минимизировать потери данных, стоит использовать непрерывный бэкап.

Я давно мечтаю об Ubuntu, которая работает так же хорошо, как OSX. К несчастью, большинство пользовательских программ в Ubuntu хуже, чем в OSX, а что касается серверной части - OSX очень сильно отстает от Ubuntu (Debian).

К примеру, по-умолчанию, в Postgresql в OSX сломана сортировка русских слов. Решение я нашел здесь.

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

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

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

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

Хотя я так и не написал толком, как пользоваться PgQ и Londiste, но уже написал плагин, который облегчает его использование вместе с рельсами. http://github.com/evtuhovich/pgq/tree/master В README всё написано на плохом английском (с хорошим английским у меня плохо). Совсем скоро я добавлю туда возможность прогонять миграции на master и slave базах данных одновременно. Тогда при очередной выкатке необходимо будет сделать только rake londiste:update в самом конце, после того, как все миграции прогонятся.

В продолжении темы о нескольких базах данных в одном rails-приложении расскажу о том, как изящно перенести одну большую таблицу в другую БД postgresql. Пусть у нас есть таблица messages с большим количеством данных (10 миллионов записей), которые мы решили перенести на другой сервер. Мы сделали, как написано в статье, указанной выше, а также создали в новой БД таблицу messages с такой же структурой. Теперь с помощью londiste настраиваем репликацию из первой БД во вторую для таблицы messages (об этом я напишу подробнее попозже, пока же можно прочитать об этом у Андрея Стихеева в рассылке ror2ru).

На таблице postgresql с большим количеством данных невозможно быстро создать либо пересоздать индекс. При создании индекса таблица блокируется для операций INSERT, UPDATE и DELETE. В таких случаях может помочь конкурентное создание индекса. Иногда на postgresql стоит пересоздавать индексы, чтобы уменьшить их фрагментацию (и увеличить скорость). Создание конкурентного индекса будет частным случаем его пересоздания. Пусть имеется таблица orders с 1 миллионом записей (приблизительно) в которой хранятся заказы. И в этой таблице есть поля country_id, region_id, city_id, на которых создан индекс.

При большом количестве запросов к приложению (в широком смысле этого слова) иногда целесообразно ``размазать’’ пиковую нагрузку во времени. Для этого удобно использовать очереди. То есть, если какое-то запрос наверняка должен быть выполнен, но не имеет значение произойдет это прямо сейчас или чуть попозже, можно создать событие в очереди. И когда до этого события дойдет очередь —– оно будет выполнено. Таким образом можно развести сложные запросы во времени. Очереди подходят для таких задач, как, например, рассылка большого количества сообщений и обновление различных счетчиков в БД (если их актуальность не очень критична).

Миграции в rails — это очень правильный инструмент. Правда, иногда случаются казусы, потому что конкретная БД перестает быть «сферическим конем в вакууме», как только количество данных и нагрузка на нее становится существенной. Пусть у нас есть таблица posts, в которой 10 миллионов записей. И мы решили добавить в нее поле is_searchable. $ script/generate migration add_is_searchable_to_posts class AddIsSearchableToPosts < ActiveRecord::Migration def self.up add_column :posts, :is_searchable, :boolean, :default => true, :null => false end def self.

Могущественная скорлупа — это, конечно же, шуточный перевод PowerShell. Обратиться к этой теме старого любителя Linux заставило не праздное любопытство, а насущная производственная необходимость. Конечно же, в мире Linux принято весело хохотать и поливать грязью все, что относится к Windows. Но, надо сказать, что многое изменилось в мире Windows, за последнее время. Во-первых, появился аналог ssh. По протоколу WinRM с помощью PowerShell можно ходить по другим машинкам не хуже, чем по ssh.

Групон сейчас активно переводится с rails 3.0 на rails 3.2. Самая досадная неожиданность, которая встретилась в процессе переезда — это изменение формата хранения flash сообщений в сессии. Если бы при этом flash сообщение пропадало, то это было бы не страшно, но при декодировании сессии происходит исключение, и пользователь видит 500 ошибку до тех пор, пока не почистит куки. Конечно, пользователей, у которых в сессии будет flash сообщение в момент переключения с версии 3.0 на 3.2 будет не так и много, но это пользователи, потерянные навсегда.

На «Групоне» мы давно уже переходим с 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-ветке, который конвертил сессию третьих рельс во вторую. Пользуйтесь с осторожностью.

Иногда мне кажется, что большинство инженерных историй похожи как две капли воды. Вот и эта история началась с того, что в одном большом отчете цифры не сходились раза в два. Мысленно закурив трубку, как Шерлок Холмс, я взялся за дело. Вот таким образом выглядела модель, по которой считались цифры (я опускаю ненужные подробности). class OfferDescription < ActiveRecord::Base has_many :children, :class_name => 'OfferDescription', :foreign_key => :parent_id end В отчете данные группировались по родительским объектам OfferDescription.

На Групоне у нас есть внутренняя страница, на которой динамически отображаются данные о продажах по различным городам. Результаты этой страницы зависят от параметров, которые передаются в метод show. А потом эта страница динамически обновляется с помощью ajax-запросов. # dashboard.rb class Admin::DashboardsController < Admin::BaseController layout "admin" def show # Здесь сложные-сложные запросы к БД if request.xhr? render 'show', :layout => false end end end Поскольку запросы очень тяжелые, да и сама страничка непростая, то отдача ее сильно нагружала БД и app-сервера.

Часто один и тот же rails-проект используется и для web-части, и для каких-то других задач, выполняемых по расписанию или для создания демонов. В таких случаях иногда хочется, чтобы логи разных частей писались в разные файлы. Готового способа для этого я не нашел. Например, посмотрим на такой пример: $ ./script/console Loading development environment (Rails 2.3.5) >> ActiveRecord::Base.logger = Logger.new(STDOUT) => #&lt;Logger:0xb192594 @progname=nil, @level=0, @default_formatter=#&lt;Logger::Formatter:0xb19255c @datetime_format=nil>, formatternil, logdev#&lt;Logger::LogDevice:0xb19247c @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#&lt;IO:&lt;STDOUT>, mutex#&lt;Logger::LogDevice::LogDeviceMutex:0xb192444 @mon_owner=nil, @mon_count=0, @mon_mutex=#&lt;Mutex:0xb19240c> >> User.

Хотя я так и не написал толком, как пользоваться PgQ и Londiste, но уже написал плагин, который облегчает его использование вместе с рельсами. http://github.com/evtuhovich/pgq/tree/master В README всё написано на плохом английском (с хорошим английским у меня плохо). Совсем скоро я добавлю туда возможность прогонять миграции на master и slave базах данных одновременно. Тогда при очередной выкатке необходимо будет сделать только rake londiste:update в самом конце, после того, как все миграции прогонятся.

Пусть в модели User у нас описана валидация для поля email validates_uniqueness_of :email, :case_sensitive => false, :message => i18n_proxy(:email_already_registered) Следующий код генерирует вот такой запрос к базе данных: SELECT * FROM users WHERE lower(email) = 'thmth' LIMIT 1 А на таблице users у нас индекс по полю email. В postgresql запрос, что вверху, не будет использовать индекс. Представьте, что будет, когда в таблице users десятки тысяч записей, а на каждое изменение любого поля в users вызывается такой запрос.

Возможно, в сайте из 3 контроллеров и 15 страниц, тесты и не нужны. Я обычно не делаю тесты на маленьких проектах, которые пишу один. В случае, если проект собирается быть большим, длиться долго, а команда состоит больше чем из одного человека, то тесты — крайне желательный инструмент для того, чтобы разработка не вышла из под контроля. Без тестов в какой-то момент невозможно внести серьезное изменение в код, потому что знаешь, что такое изменение заденет еще некоторые части и точно знаешь, что все зависимости точно не учтешь.

Все ситуации, о которых я здесь пишу, встретились мне в повседневной работе. Единственное, что я делаю — меняю название классов, чтобы не утруждать моего читателя незнакомой для него предметной областью. Итак, у нас есть следующие модели: # shop.rb class Shop < ActiveRecord::Base has_many :categories cached_methods do def wait_orders_count Order.count :conditions => {:status_id => Order::WAIT} end def paid_orders_count Order.count :conditions => {:status_id => Order::PAID} end def bad_orders_count Order.count :conditions => {:status_id => Order::BAD} end end end class Category < ActiveRecord::Base belongs_to :shop has_many :products end class Product < ActiveRecord::Base belongs_to :category has_many :orders end class Order belongs_to :product end Методы внутри cached_methods выполняются в том случае, если значение для них не нашлось в кэше (например, в memcached).

Миграции в rails — это очень правильный инструмент. Правда, иногда случаются казусы, потому что конкретная БД перестает быть «сферическим конем в вакууме», как только количество данных и нагрузка на нее становится существенной. Пусть у нас есть таблица posts, в которой 10 миллионов записей. И мы решили добавить в нее поле is_searchable. $ script/generate migration add_is_searchable_to_posts class AddIsSearchableToPosts < ActiveRecord::Migration def self.up add_column :posts, :is_searchable, :boolean, :default => true, :null => false end def self.

Сегодня я хочу рассказать о пользе конференций в жизненной практике любого специалиста. Если вы просто работаете в своей профессии и не хотите стать и быть Специалистом (именно так, с большой буквы), то дальше можете не читать.

В субботу 17 декабря прошла конференция Railsclub, которую посетило приблизительно 170 человек. Я рад, что в этот раз нам удалось привезти иностранных коллег: Sven Fuchs, Konstantin Haase и Piotr Sarnacki. Но помимо самой конференции, было еще несколько посиделок, где можно было поговорить со всеми в неформальной обстановке. Я старался о всех публичных мероприятиях сообщать в твиттере конференции @railsclub_ru. Очень понравилось, что Свен остался специально на день подольше, чтобы потусоваться с русскими разработчиками, специально посетил «Злых Марсианах», чтобы посмотреть, что у нас делается.

В некоторых ситуациях необходимо использовать более чем одну базу данных в проекте. Например, статистику и большие таблицы хранить на другом сервере, у которого большой и медленный диск, а данные, которые нужны постоянно, хранить на основном сервере с маленьким и быстрым диском. В нашем случае хотелось унести большие таблицы на другой сервер, чтобы в дисковом кэше (а у главного сервера БД 32 Гб оперативной памяти) хранились все рабочие таблицы и никогда оттуда не убегали.

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

В некоторых ситуациях необходимо использовать более чем одну базу данных в проекте. Например, статистику и большие таблицы хранить на другом сервере, у которого большой и медленный диск, а данные, которые нужны постоянно, хранить на основном сервере с маленьким и быстрым диском. В нашем случае хотелось унести большие таблицы на другой сервер, чтобы в дисковом кэше (а у главного сервера БД 32 Гб оперативной памяти) хранились все рабочие таблицы и никогда оттуда не убегали.

Возможно, в сайте из 3 контроллеров и 15 страниц, тесты и не нужны. Я обычно не делаю тесты на маленьких проектах, которые пишу один. В случае, если проект собирается быть большим, длиться долго, а команда состоит больше чем из одного человека, то тесты — крайне желательный инструмент для того, чтобы разработка не вышла из под контроля. Без тестов в какой-то момент невозможно внести серьезное изменение в код, потому что знаешь, что такое изменение заденет еще некоторые части и точно знаешь, что все зависимости точно не учтешь.

Использование дебаггера при разработке — это плохой тон. Это значит, что вы не понимаете, как работает ваша программа. Но иногда жизнь без дебаггера становится невыносимой. Есть отличный плагин vim-ruby-debugger для редактора vim. Но он пока сыроват и не все возможности в нем есть. По крайней мере в моем случае, чтобы понять, что происходить внутри спека, он не помог. Тогда я воспользовался старым дедовским способом: require 'ruby-debug' Debugger.start И вставил вызов debugger в том месте, где мне это необходимо.

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

В очередной раз компания Puppet совместно с DORA ( DevOps Research and Assessment — компания, которая решила активно продавать DevOps, что бы это не значило) опубликовали отчет о состоянии DevOps, который называется «2017 State of DevOps Report». Скачать его можно бесплатно, если оставить свою почту. Насколько я знаю, это единственное регулярное исследование ИТ-рынка на предмет проникновения DevOps практик.

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

Компания Puppet (как ни удивительно — это разработчики одноименной системы управления конфигурацией) опубликовали свой очередной ежегодный отчет о состоянии DevOps.

Они опросили 4600 инженеров со всего мира и по результатам этого опроса составили отчет на 55 страниц. Я кратко резюмирую здесь их результаты для тех, кому лень читать оригинальный отчет.

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

В некоторых ситуациях необходимо использовать более чем одну базу данных в проекте. Например, статистику и большие таблицы хранить на другом сервере, у которого большой и медленный диск, а данные, которые нужны постоянно, хранить на основном сервере с маленьким и быстрым диском. В нашем случае хотелось унести большие таблицы на другой сервер, чтобы в дисковом кэше (а у главного сервера БД 32 Гб оперативной памяти) хранились все рабочие таблицы и никогда оттуда не убегали.

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

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

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

Пусть в модели User у нас описана валидация для поля email validates_uniqueness_of :email, :case_sensitive => false, :message => i18n_proxy(:email_already_registered) Следующий код генерирует вот такой запрос к базе данных: SELECT * FROM users WHERE lower(email) = 'thmth' LIMIT 1 А на таблице users у нас индекс по полю email. В postgresql запрос, что вверху, не будет использовать индекс. Представьте, что будет, когда в таблице users десятки тысяч записей, а на каждое изменение любого поля в users вызывается такой запрос.

Vim — прекрасный редактор, который я использую для разработки на Ruby и Rails. Его можно использовать в чистом виде, но если добавить немного плагинов, то удобство работы значительно возрастает. Об этом я и хочу рассказать, правда рассказ получится длинным. Я выступал на последнем RailsClub’е с докладом Vim Or Die (посмотреть его можно на univertv.ru), в котором неплохо раскрыл тему Vim и полезных плагинов. Cами слайды, которые малополезны без видео, можно найти на slideshare.

Извечная проблема о том, как добавлять и обновлять плагины в vim решилась благодаря легендарному Tim Pope. Сегодня утром узнал от Ярослава Маркина о существовании pathogen. Статья на английском о том, как им пользоваться, лежит здесь. Правда, я потратил полчаса, чтобы догадаться, что надо добавить call pathogen#runtime_append_all_bundles() в файл ~/.vimrc. После установки pathogen.vim в ~/.vim/autoload можно хранить все плагины в папке ~/.vim/bundle, причем каждый в своей папке. А еще огромный плюс - в конце этой статьи код, который позволяет обновлять все плагины одной командой.

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

Если вы делаете обычные бэкапы и запускаете в час ночи pg_dump, а в час дня ваш сервер БД умер, то вы потеряете данные за 12 часов и доверие ваших пользователей. Для многих web-сервисов такой сценарий неприемлем, и, чтобы минимизировать потери данных, стоит использовать непрерывный бэкап.

На «Групоне» мы давно уже переходим с 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-ветке, который конвертил сессию третьих рельс во вторую. Пользуйтесь с осторожностью.

Если необходимо сериализовать/десериализовать какой-то объект, то yaml формат хорошо для этого подходит. В моем проекте мы записывали объекты в очередь, использую yaml-сериализацию. На тестах все было хорошо. Но на живом эта самая сериализация стала выполняться очень долго. Оказалось, что если у объекта есть связные объекты, то он их тоже засовывает в yaml, а если таких объектов очень много, то это будет сложная операция. Понятно, что в примитивных тестах этого было не видно, а подумать хорошо головой в тот раз не получилось.

Чтобы рассказать о тонких моментах pg_repack, мне понадобится немного углубиться в тему блокировок в PostgreSQL. Конечно, лучше всего начать читать про них в официальной документации. Для этой статьи достаточно понимать, что эксклюзивная блокировка (ACCESS EXCLUSIVE LOCK) препятствует выполнению всех операций, включая SELECT, и она нужна для операции ALTER TABLE.

Сегодня мне исполнилось 39 лет, я стою на пороге вечности.

Шутка, конечно. Не знаю, смешная или нет, но мне нравится. Вообще, помню, раньше меня пугало, что я делаю еще один шаг на пути к смерти. А в 35 перестало. Не знаю, даже, с чем это связано. В 32 года в день рождения я разбил машину. В 33 года - за два дня до дня рождения. В 34 я специально за неделю до ДР не садился за руль.

Помню, когда мне исполнялось 24, я перепутал, что мне 25 и тоже перепугался - а чего я сделал к своим 25. А потом вспомнил, что мне только 24 и отпустило.

А вот в 35 как-то перестал бояться. Топаешь себе на пути к смерти и топаешь.

Готовить я, по большому счету, не умею. Вот мой брат, или там, Саша с Пашей (вы их вряд ли знаете, но все равно) — это да, а я так, любитель. Но тем не менее, поскольку окружающая меня действительность несколько раз взывала к тому, чтобы я рассказал про сырники, то я не буду молчать. Итак, сырники (про яичницу тоже напишу попозже, хотя что там писать). Все секреты я почерпнул у мамы, шаг за шагом перенимая у нее секреты мастерства.

Вообще, сам не узнаю себя, уже ровно месяц прошел с выпуска Postgresql 9.2, даже вышло обновление 9.2.1, исправляющее некоторые баги, а я все еще ничего не написал об этом.

Поэтому сегодня рассказ будет о Index Only Scan — самом заметном, по моему мнению, изменении в 9.2. Кстати, именно это изменение стоит первым в Release Notes, а значит я не одинок.

Пусть в модели User у нас описана валидация для поля email validates_uniqueness_of :email, :case_sensitive => false, :message => i18n_proxy(:email_already_registered) Следующий код генерирует вот такой запрос к базе данных: SELECT * FROM users WHERE lower(email) = 'thmth' LIMIT 1 А на таблице users у нас индекс по полю email. В postgresql запрос, что вверху, не будет использовать индекс. Представьте, что будет, когда в таблице users десятки тысяч записей, а на каждое изменение любого поля в users вызывается такой запрос.

На таблице postgresql с большим количеством данных невозможно быстро создать либо пересоздать индекс. При создании индекса таблица блокируется для операций INSERT, UPDATE и DELETE. В таких случаях может помочь конкурентное создание индекса. Иногда на postgresql стоит пересоздавать индексы, чтобы уменьшить их фрагментацию (и увеличить скорость). Создание конкурентного индекса будет частным случаем его пересоздания. Пусть имеется таблица orders с 1 миллионом записей (приблизительно) в которой хранятся заказы. И в этой таблице есть поля country_id, region_id, city_id, на которых создан индекс.

Наконец-то я заканчиваю свою великую киноэпопею, и раздаю трехлетние долги просмотренных фильмов. Как обычно, в подборке из 74 фильмов и сериалов, которым я отдал свою жизнь в 2019 году, осталось только то, что я настоятельно бы рекомендовал к просмотру, а именно 26 фильмов и ни одного сериала (просто не повезло им в этот раз). Поскольку все они очень хороши, то место в списке ничего не значит.

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

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

Ниже список фильмов, которые я посмотрел в 2017 году. Поскольку весь список — это фильмов 50, то я оставил только то, что понравилось и достойно просмотра.

Я как-то забросил традицию писать про кино, хотя смотреть его не переставал. Сейчас я быстренько пройдусь по второму полугодия 2016 (ага, сам в шоке) года, и буду продолжать. Как обычно, фильмы отсортированы в порядке убывания того, как сильно они мне понравились.

Что же, продолжу отдавать свой кинодолг обществу, которое меня окружает. Фильмы второго квартала 2016 года, долг большой, каюсь.

Ого, уже больше года я ничего не писал про просмотренные фильмы. Что же, постараемся наверстать упущенное. Как обычно, внизу список фильмов, которые я посмотрел на январь-март 2016 года, сверху самые интересные, на мой субъективный и непрофессиональный взгляд. Всего получилось 13 наименование, часть из этого не совсем кино (есть и сериалы и мультфильмы), поэтому объективно рассортировать было достаточно сложно.

В какой-то момент писать о фильмах стало совсем тяжело, но это не повод останавливаться. Ниже привожу описание фильмов, которые посмотрел в сентябре-декабре 2015 года. Как обычно, сверху — самые интересные фильмы с моей точки зрения.

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

Ниже привожу описание фильмов, которые посмотрел с апреля по август.

А я продолжаю рассказывать про фильмы, которые посмотрел в Великий Пост. Хотя это и вторая половина фильмов, среди них много достойных.

За январь и февраль я посмотрел всего 4 фильма, а вот в марте во время поста я опять заболел, и за 5 дней я пересмотрел такое количество фильмов, что самому от этого стало немного нехорошо. Вашему требовательному вкусу представляются 24 фильма, традиционно сверху самые яркие из них, по моему мнению.

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

Три недели в этом ноябре я провел в отпуске. Отпуск хорош тем, что появляется много свободного времени, которое надо обязательно чем-то заполнить, ведь иначе образовавшаяся пустота может поглотить тебя и, не дай бог, перенести на новый духовный уровень. Как обычно, вначале списка — самые хорошие фильмы.

Так сложилось, что 25 августа у меня родился сын Никита, поэтому сентябрь в киноплане оказался скудным, посему я объединил сентябрь и октябрь вместе, хотя сильно лучше от этого не стало.

В смысле кино август оказался крайне бедным месяцем. Смешно сказать, всего четыре фильма. Но, тем не менее, и они стоят того, чтобы о них рассказать.

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

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

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

Тут недавно был в отпуске, и чтобы заполнить время, смотрел различные фильмы. О них сегодня я вам и расскажу, на этот раз в порядке убывания моего субъективного рейтинга, потому что вначале хочется рассказать о самом ярком и интересном. В этот раз сделать это было гораздо сложнее, потому что плохих фильмов в этот список не попало, все они интересные, на мой взгляд, и достойны просмотра.

В пост я обещал посмотреть 7 новых хороших фильмов. Сказано — сделано, правда, не все их них были хорошими. В том смысле, что даже начиная их смотреть, я прекрасно понимал, что часть из них — чистая развлекуха, и это совсем не кино. Расскажу о них в порядке возрастания красоты.

Вчера закончил читать книга Михаила Хазина “Воспоминания о будущем. Идеи современной экономики”.

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

Мелвин Конвей в 1968 году (48 лет назад!) опубликовал свою работу, в которой сформулировал следующую идею: «Организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникации в этой организации». Более просто эту идею перефразировал Эрик Реймонд: «Если над компилятором работает четыре группы разработчиков, вы получите четырехпроходный компилятор». Желающие могут прочитать оригинал статьи здесь.

6–7 декабря 2014 на базе отдыха им. Стрельникова под Омском состоялась очередная конференция HappyDev. Я давно не попадал на такую интересную и яркую конференцию. Во-первых, место проведения. На базе под омском с общей столовой на второй день всех знаешь в лицо. После бани с открытым бассейном многих знаешь по именам. И такой формат снимает некоторую зажатость, которая традиционно бывает у русских айтишников. Опять же, именно это позволило докладам и бар-кэмпам проходить в дружеской и непринужденной атмосфере.

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

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

В эту субботу 15 декабря я выступал в Ульяновске с докладом «Нетрадиционное использование Ruby и PostgreSQL». Несмотря на несколько провокационное название, доклад был посвящен вполне обыденным вещам: о том, как использовать Ruby и PostgreSQL не в web-проекте с Rails. Я рассказал о Ruby внутри Vim, hstore и PostgreSQL массивах внутри Rails (кстати, hstore и ARRAY неоднократно упоминались на конференции, так что я был неоригинален), а самая забавная часть моего доклада была посвящена несуществующей документоориентированной БД rmongo.rb. Видеозапись второго дня еще доступна на сайте Railsclub, и я надеюсь, что и первый день скоро появится в общем доступе.

Исходные коды, которые связаны с докладом, я выложил на Gist, сам доклад я выложил на Slideshare.

Сегодня я хочу рассказать о пользе конференций в жизненной практике любого специалиста. Если вы просто работаете в своей профессии и не хотите стать и быть Специалистом (именно так, с большой буквы), то дальше можете не читать.

31 марта буду выступать на конференции CodeFest. Мой доклад «Как мы делали Групон» будет в 17:05 во втором зале. А второго апреля я проведу мастер-класс «Устройство и оптимизация Postgresql». Я хочу выразить большую благодарность организаторам конференции за их работу. Поскольку у меня есть опыт в этой области, я понимаю, какой объем работы надо проделать, чтобы привезти докладчиков со всех концов России в Новосибирск. Верю, что конференция пройдет продуктивно и на позитивной волне.

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

В субботу 17 декабря прошла конференция Railsclub, которую посетило приблизительно 170 человек. Я рад, что в этот раз нам удалось привезти иностранных коллег: Sven Fuchs, Konstantin Haase и Piotr Sarnacki. Но помимо самой конференции, было еще несколько посиделок, где можно было поговорить со всеми в неформальной обстановке. Я старался о всех публичных мероприятиях сообщать в твиттере конференции @railsclub_ru. Очень понравилось, что Свен остался специально на день подольше, чтобы потусоваться с русскими разработчиками, специально посетил «Злых Марсианах», чтобы посмотреть, что у нас делается.

Так случилось, что в этом году я снова закурил. Я никогда не делал секрета из того, что в молодости я курил с перерывом суммарно пять лет, а в 26 лет прочитал известную книгу Алена Карра и бросил курить. В 2015 году я начал покуривать с друзьями трубку. В трубке было что-то волнительное и зажигательное, она требует ритуала, удобного места и компании, ее нельзя курить на лету. Но в конце-концов я скатился к тому, что стал курить трубку по быстренькому в одиночестве в подъезде.

10 сентября умер Михаил Литвак, ему было 82 года. Он был популяризатором психологии, но не уверен, что многие знают это имя, хотя суммарный тираж его книг более 5 миллионов.

Его книга попалась мне лет в 20, и тогда я начал смутно догадываться, что большинство человеческих поступков происходят, как бы так сказать, сами собою, а мы потом придумываем им объяснение. Теперь я полностью в этом уверен 🙂

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

Спешу сообщить радостную весть — очередной мастер-класс Brainwashing, который проводит компания «Злые Марсиане», пройдет 14 и 15 июля. Мастер-класс посвящен разработке web-приложений на ruby on rails, и будет интересен программистам, руководителям разработки и техническим директорам. В интенсивном двухдневном курсе мы расскажем выжимку из нашего опыта и раскроем практически все темы, связанные с разработкой, начиная с систем контроля версий, устройства фреймворка rails, и заканчивая оптимизацией фронтенда, базами данных и выкаткой. Как и раньше, Мастер-класс вместе со мною будут проводить Тимофей Цветков и Саша Косс.

Две недели назад мы провели Мастер-Класс, в котором в сжатой форме попытались изложить самое важное, на наш взгляд, в web-разработке. За два достаточно напряженных дня мы рассказали обо всем, от Git, баз данных, до SASS, HAML и Rails 3. Все это перемежалось постоянными практическими заданиями. В конце Мастре-Класса мы сделали анкетирования, из которого можно смело заявить, что в целом идея удалась. Более того, на конференции RailsClub я попросил некоторых из наших участников лично поделиться впечатлениями от посещения.

В современном мире хочется учиться быстро. И знать только то, что нужно знать, потому что все знать, к сожалению, невозможно. Мне всегда казалось, что можно иметь какую-то «фундаментальную» картинку мира, на которую просто наматываются подробности. Я всегда представляю себе дерево: если есть ствол, то к нему можно прицепить ветки и листья. Но только из веток и листьев дерево не получится. Поэтому мы в «Злых Марсианах» решили подготовить Мастер-Класс, в котором бы обобщили наши лучшие практики при разработке различных web-проектов.

В продолжении темы о нескольких базах данных в одном rails-приложении расскажу о том, как изящно перенести одну большую таблицу в другую БД postgresql. Пусть у нас есть таблица messages с большим количеством данных (10 миллионов записей), которые мы решили перенести на другой сервер. Мы сделали, как написано в статье, указанной выше, а также создали в новой БД таблицу messages с такой же структурой. Теперь с помощью londiste настраиваем репликацию из первой БД во вторую для таблицы messages (об этом я напишу подробнее попозже, пока же можно прочитать об этом у Андрея Стихеева в рассылке ror2ru).

Продолжая разговор о микросервисной архитектуре, нельзя не упомянуть о Service Discovery. К сожалению, в русском языке до сих пор так и не появилось адекватного перевода этого термина. Дословное «обнаружение сервисов» звучит слишком топорно и неизящно, а «каталог сервисов» хоть и неплох, но имеет много других значений.

Русская википедия про Service Discovery (далее — sd) не знает ничего и дает вместо этого список протоколов для sd, английская, впрочем, тоже.

О микросервисной архитектуре не говорит сейчас только ленивый, но если вы впервые встречаетесь с этим термином, то прочитайте статью Мартина Фаулера или ее перевод на русский.

В пост я обещал послушать 7 новых для себя музыкальных альбомов. Сказано — сделано, правда, альбомов было больше, но новых авторов было 7.

Долгие годы этот блог велся на Octopress — платформе для ведения технических блогов. Он был первым и восхищал меня долгое время, я даже хотел написать о нем отдельный пост, но руки так и не дошли. Но были у октопресса и откровенные недостатки, как то: медлительность — он реально подтупливает на генерации страниц; асинхронность — от внесения правки, до появления ее в браузере проходило значительное время, а это сильно раздражало; сложность — поменять что-то внутри не представляется возможным; отсутствие поддержки — с 2011 года официальный сайт не обновлялся; он, вообще, сломался с ruby 2.

Технологии, конечно, технологиями, но иногда хочется рассказать чего-то «про жизнь». А именно про то, как работают хорошие команды. Собственно, этот рассказ тоже о технологиях, только о человеческих.

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

Прежде всего, я хочу рассказать историю про стрижку быка (в английском варианте Yak Shaving).

Поскольку я поставил Octopress, то теперь сбылась моя мечта и я могу вести блог в своем любимом текстовом редакторе vim. Про octopress я напишу как-нибудь потом отдельно, потому что система для инженера программных систем просто необыкновенная: простая и удобная. Но сегодня я хочу поговорить о «простыне» — так я шутя называют длинный последовательный кусок кода. Так вот, моя основная мысль — простыня является самым лучшим кодом. Это так по одной простой причине, что последовательный код гораздо проще читать и понимать.

Я вношу в список задач те темы, про которые я хочу написать, так вот про Никиту я хотел написать уже очень давно, но все как-то не доходили руки. А завтра ему уже два года. Тут, конечно, должны быть фраза: «Как время-то идет, как дети-то растут», но это было бы слишком банально, хотя и правда. Как и все родители, мы придумывали Никите ласковые имена, и одно из них было Бобитка (Никтка-бобитка), которое и превратилось в Бобиткомен.

Начнем с того, что на шестой неделе я сорвался. Поэтому результаты этого поста более чем скромные — всего лишь 40%. Это на 8% меньше, чем в прошлом году. Из приятного — посетил Усачевские бани и тем самым закрыл великий банный гештальт — посетил все общественные бани Москвы внутри третьего кольца.

Пост был зафейлен. За неделю до конца поста был на конференции Secon, где был смущен бесплатным пивом и хорошей компанией. А потом как-то жизненные трудности навалились, что решил закончить я пост досрочно. Тем не менее, что-то было сделано, об этом сейчас и напишу.

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

Программа на этот пост, за некоторыми изменениями, повторяет прошлогоднюю.

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

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

Программа на пост, за некоторыми изменениями, повторяет прошлогоднюю.

Некоторым интересно, зачем в чем-то себе отказывать семь недель. Короткий ответ — чтобы лучше узнать себя. Длинный ответ я дать пока не готов.

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

«Пост не прост» — говорили великие люди. До великих людей мне еще далеко (хотел написать «уже никогда», но как-то совсем уж мрачно), но все же в этом году решил выдержать пост. Лет 6 назад я уже делал такой опыт, но пост ограничивался только едой, в этом же году я хочу значительно усилить ограничения.

Я вношу в список задач те темы, про которые я хочу написать, так вот про Никиту я хотел написать уже очень давно, но все как-то не доходили руки. А завтра ему уже два года. Тут, конечно, должны быть фраза: «Как время-то идет, как дети-то растут», но это было бы слишком банально, хотя и правда. Как и все родители, мы придумывали Никите ласковые имена, и одно из них было Бобитка (Никтка-бобитка), которое и превратилось в Бобиткомен.

В эту субботу 15 декабря я выступал в Ульяновске с докладом «Нетрадиционное использование Ruby и PostgreSQL». Несмотря на несколько провокационное название, доклад был посвящен вполне обыденным вещам: о том, как использовать Ruby и PostgreSQL не в web-проекте с Rails. Я рассказал о Ruby внутри Vim, hstore и PostgreSQL массивах внутри Rails (кстати, hstore и ARRAY неоднократно упоминались на конференции, так что я был неоригинален), а самая забавная часть моего доклада была посвящена несуществующей документоориентированной БД rmongo.rb. Видеозапись второго дня еще доступна на сайте Railsclub, и я надеюсь, что и первый день скоро появится в общем доступе.

Исходные коды, которые связаны с докладом, я выложил на Gist, сам доклад я выложил на Slideshare.

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

Во-первых, я хочу выразить большую благодарность Кириллу Мокевнину, который встретил нас на вокзале на машине, помог поселиться, показал город, показал мне свой офис, а также организовал небольшую Ульяновскую ruby-тусовку. Кирилл организовал достаточно большой офис ruby-разработки, где много света, красиво, аккуратно и стеклянные туалеты. Поначалу они пугают, но стекло матовое и в целом это скорее забавно, чем неуютно.

По айкидошным делам посещу IT Мекку России — славный город Ульяновск. Сказания и легенды о необычайно плотности IT мысли в Ульяновске слышал я уже давно, вот теперь воочию смогу убедиться в том, что это правда. Я планирую провести ruby/chef/rails пьянку 22 июня (в пятницу) вечером, но подробности можно будет прочитать в моем твиттере, потому что я их и сам не знаю. Так же у меня будут более-менее свободны все три дня: четверг, пятница и суббота.