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

Для понимания написанного ниже желательно иметь базовое представление о Ruby и Rails, а так же желание немножко познакомиться с RSpec.

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

Эту проблему можно решить единственным способом — предоставить слово кому-то из менеджеров отдела разработки или любому другому человеку, занимающему адекватно высокий пост и разбирающемуся в разработке, а после — тянуть, тянуть из него все подробности. Примерно так поступили в Information Queue, опросив одного из инженеров Twitter'а — Эвана Уивера (Evan Weaver) о том, почему компания так долго развивавшаяся на «рельсах», решила переключиться на использование других технологий и какие это имело последствия.

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

Итак, история начинается в прошлом году, когда Twitter анонсировал изменения в архитектуре бэкэнда (message queue), а так же заявил о намерении переписать Twitter Storage на Scala, а весной началась работа по переписыванию всего поискового движка. Как часть этих изменений, БД MySQL (лежавшая в основе поиска) была заменена Lucene. И, наконец, совсем недавно команда разработчиков заявила о замене Ruby on Rails в области поиска — на его место встал Java-сервер, который они сами называют Blender. Результатом этой замены стало трехкратное снижение задержки при выполнении поискового запроса.

Чтобы легко и просто перегенерировать все картинки ваших продуктов в Spree, после добавления декоратора с новыми размерами, запустите такую команду в консоли: Image.all.each{|i| i.attachment.reprocess!}