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

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

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

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

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

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

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

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

В субботу 17 декабря прошла конференция Railsclub, которую посетило приблизительно 170 человек. Я рад, что в этот раз нам удалось привезти иностранных коллег: Sven Fuchs, Konstantin Haase и Piotr Sarnacki.

Но помимо самой конференции, было еще несколько посиделок, где можно было поговорить со всеми в неформальной обстановке. Я старался о всех публичных мероприятиях сообщать в твиттере конференции @railsclub_ru.

Очень понравилось, что Свен остался специально на день подольше, чтобы потусоваться с русскими разработчиками, специально посетил «Злых Марсианах», чтобы посмотреть, что у нас делается. Мне показалось, что эта неформальная часть получилась не менее интересной и насыщенной, чем сама конференция. И хотелось бы, чтобы в дальнейшем, такие неформальные тусовки посещало больше моих коллег из Москвы и других городов России.

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

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

Мысленно закурив трубку, как Шерлок Холмс, я взялся за дело. Вот таким образом выглядела модель, по которой считались цифры (я опускаю ненужные подробности).

    class OfferDescription < ActiveRecord::Base
      has_many :children, :class_name => 'OfferDescription', :foreign_key => :parent_id
    end

В отчете данные группировались по родительским объектам OfferDescription. Именно у объектов, у которых были дети, в отчетах были все нули. Рассчитывал отчеты приблизительно вот такой код.

Сегодня у нас перестали ходить отчеты по почте. Ходили, ходили и вдруг перестали. 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 из контроллера. У него базовый класс — HashWithIndifferentAccess.

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

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

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

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

# dashboard.rb
class Admin::DashboardsController < Admin::BaseController
  layout "admin"

  def show
    # Здесь сложные-сложные запросы к БД

    if request.xhr?
      render 'show', :layout => false
    end
  end
end

Поскольку запросы очень тяжелые, да и сама страничка непростая, то отдача ее сильно нагружала БД и app-сервера.

Поскольку я поставил Octopress, то теперь сбылась моя мечта и я могу вести блог в своем любимом текстовом редакторе vim. Про octopress я напишу как-нибудь потом отдельно, потому что система для инженера программных систем просто необыкновенная: простая и удобная.

Но сегодня я хочу поговорить о «простыне» — так я шутя называют длинный последовательный кусок кода. Так вот, моя основная мысль — простыня является самым лучшим кодом. Это так по одной простой причине, что последовательный код гораздо проще читать и понимать. Конечно, если при этом не происходит нарушения правила OOO (Once and Only Once), то есть нет ненужного дублирования кода. Простыня — это способ выполнять правило KISS (Keep It Simple, Stupid), то есть правила держать систему максимально простой.