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

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

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

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

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

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

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

В субботу 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 из контроллера.

Расскажу одну очень поучительную и одновременно типичную историю, которая случилась со мною года 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 я напишу как-нибудь потом отдельно, потому что система для инженера программных систем просто необыкновенная: простая и удобная. Но сегодня я хочу поговорить о «простыне» — так я шутя называют длинный последовательный кусок кода. Так вот, моя основная мысль — простыня является самым лучшим кодом. Это так по одной простой причине, что последовательный код гораздо проще читать и понимать.