Краткое описание некоторых интересных гемов

gem-review

== Resque

Гем для обработки фоновых задач. Использует Redis для хранения очереди.

+ redis
+ web-интерфейс для просмотра текущих задач, перезапуска зафэйленых и т.п.
+ разные очереди, можно создавать отдельные обработчики для них
+ можно обрабатывать задачи, не загружая полностью рельсовое окружение

- polling (так же как и в delayed_job)
- для обработки каждой задачи надо создавать отдельный класс, нельзя просто вызвать x.delayed.do_something как в delayed_job

Вроде бы как на нем работает гитхаб, то есть держит неплохие нагрузки.

Имхо, поскольку мы используем Redis, в нашем случае это весьма хороший вариант если не влом писать отдельный класс под каждую задачу. 
Хотя при большом желании можно сделать небольшую обертку, которая будет мультиплексить вызовы и получить в точности delayed_job интерфейс.

== Kaminari

Гем для пагинации.

+ использует Rails 3 scopes
+ настраиваемый вид пагинатора - это engine для которого можно сгенерировать виьюхи в приложении
+ AJAX-пагинация делается мегапросто - достаточно передать опцию :remote => true и определить js-файл, который будет обновлять содержимое страницы. http://www.joshondevelopment.com/post/3752155526/ajax-pagination-with-kaminari

- уж слишком имхо навороченная система партиалов, не будет ли оно тормозить?

Имхо, поудобнее чем will_paginate, мне нравится использование скопов, да и ajax-пагинация радует весьма.

== CarrierWave

Гем для обработки аттачей.

* основное отличие - логика обработки аттачей хранится не в классе модели, а в отдельном классе
* в отличии от paperclip не вызывает identify, не хранит content_type, размеры и прочее

+ основан на Rack, работает со всем подряд
+ поддерживает не только active_record, а опять же все подряд
+ поддерживает обработку с помощью всяких произвольных методов RMagick (также можно использовать MiniMagick или написать свой модуль)
+ возможна реализация кроппинга как нам надо без сверхусилий - http://ananasblau.com/2010/2/19/reprocessing-images-in-carrierwave

еще полезная информация относительно кроппинга здесь - http://stackoverflow.com/questions/5985079/carrierwave-crop-specific-version

впрочем для paperclip тоже реализуют без особых проблем - http://asciicasts.com/episodes/182-cropping-images

Имхо, в случае выделения в отдельный класс обработка как-то выходит менее размазана по приложению по сравнению с Paperclip
Хотя, когда кропы не нужны, paperclip проще

== Paper Trail

Гем для хранения истории изменений моделей

* хранит всю историю в одной таблице по умолчанию, данные хранятся в сериализованном в YAML виде
* позволяет проходить по версиям, откатывать, сравнивать версии

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

== Decent Exposure

Маленький гем, который позволяет эффективно писать куски кода вида

def comments
  @comments ||= article.comments
end

helper_method :comments

в виде

expose(:comments) { article.comments }

Если писать в таком стиле код контроллеров вроде бы выглядит несколько чище (из действий уходит загрузка моделей из базы в явном виде и остается только логика что с чем сделать)
Я пробовал юзать, мне понравилось =)

Непонятно, насколько это совместимо с inherited_resources (боюсь, что не совместимо вообще)
Но с другой стороны, это возможно и не проблема, поскольку я бы использовал inherited_resources в админке, а decent_exposure во фронте

== Inherited Resources

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

В любом случае - в админке для него неплохое место, если не использовать что-то автогенерируемое, типа rails_admin, там как раз обычно всюду CRUD