Привет всем. Сегодня я поведаю о своей разработке для Rails 3 — MongodbLogger. Начнем по порядку.

Rails приложение по-умолчанию складывает логи запросов в папку logs. Сами по себе логи очень удобная штука — они помогают посмотреть какие запросы идут в ваше приложение, посмотреть trace ошибки и прочее. В них можно дописывать дополнительную информацию. Хотя файловый лог прост и эффективен, но у него есть определенные ограничения: при использовании множество веб-серверова, лог у каждого свой; нет простого доступа. Запись в РСУБД решает вопросы централизации и простого доступа логов, но сразу возникают другие проблемы: схема таблицы не настолько гибка, как может быть структура лога; запись может быть недостаточно быстра; чистка старых логов — задачи на Ваших плечах. И тут на помощь приходит MongoDB.

Одна из тривиальных задач для RoR-разработчика: реализовать функционал “инбоксов”, или личных сообщений. Решать эту задачу приходиться чуть ли не на каждом из проектов, поэтому столкнувшись с этим в очередной раз я принял решение создать удобный компонент мессенджера для приложения на Rails 3.1, который в дальнейшем можно будет легко и удобно подключать к любому приложению.
Представляю gem Inboxes.

Возможности:

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

Для авторизации и идентификации пользователей gem интегрируется с Devise, для проверки прав — с CanCan.

Вы знаете, что когда требуется организовать many-to-many отношения между двумя моделями, прогрессивная часть человечества применяет join-таблицы и метод has_many с опцией :through => :join_model_name. Каждая связь между двумя ActiveRecord-объектами представляет собой ActiveRecord-объект.

И это чудесно, ибо в join-таблице можно насоздавать полезных (так называемых «extra») полей с дополнительной информацией о связях между объектами.

Вопрос в том, как красиво достучаться до этих extra атрибутов.

Все скринкасты и книжки, как назло, оперируют простыми примерами. Например, дружат между собой модели Article и Category. Само собой, для join-класса интуитивно напрашивается имя Categorization или ArticleCategorization.



Соответственно, если у нас есть два объекта — article и category, и мы хотим найти AR-объект (или объекты), олицетворяющий связь между ними, то авторы книжек с чистым сердцем предлагают делать так:

relations = article.article_categorizations.find_by_category_id(category)

В жизни все сложнее. Модели нередко имеют длинные составные имена, либо между моделями такая связь, что придумывание имени для каждой join-модели превращается в маленькую пытку. Представим, что у нас модели не Article и Category, а UserGroup и Community, или Preorder и CustomerNotification. Как должна называться связующая модель? Возможны варианты.

Asset Pipeline — фреймворк для сборки и сжатия JS и CSS, который представляет собой одну из killer-feature версии 3.1. А еще он добавляет возможность «из коробки» писать их на других языках, таких как CoffeScript, SASS и ERB.
В версиях до 3.1 эта функциональность обеспечивалась через Jammit или Sprockets. Rails 3.1 включает gem sprockets-rails, который использует Sprockets.

По умолчанию, в каждом новом Rails-приложении asset pipeline включен. Отключить его можно в application.rb параметром config.assets.enabled=false

Предназначение

Основная функция Pipeline — объединение все подключаемых файлов (assets) в один, что ускоряет загрузку страницы браузером.
Вторая по важности функция — сжатие ресурсов. В CSS это удаление пробелов и переносов строк, в JS логика сжатия более продвинута. Вы можете выбрать любой компрессор JS из существующих (uglifier, closure-compiler, therubyracer или yui-compressor) или создать свой собственный.
Третья — возможность написание asset'а в любом формате. Asset pipeline соберет и сожмет файлы, написанные на любом поддерживаемом языке.

В одном из последних проектов понадобилось подписывать и шифровать с помощью сертификатов X.509 письма, отправляемые приложением на Ruby on Rails 3. Беглый поиск привёл к плагину actionmailer_x509, а вот дальше начались проблемы.

Выяснилось, что он не обновлялся с 2008 года, скорее всего не работает с Rails 3 (в частности, смущал комментарий автора: «It has been tested with Rails 2.0.1») и умеет только подписывать, но не шифровать письма. Поиск альтернативных решений ничего не дал, и пришлось знакомиться с плагином поближе.

Введение

В топике я рассмотрю создание PDF-документов средствами Ruby/Rails, их генерацию, скачивание напрямую с сайта или создание через rake task, а также возможность отправки во вложении через Mailer.
Работать будем с Rails 3.0.9 и gem'ом Prawn.

В рамках моего дипломного проекта мне предложили создать систему формирования проектных команд на основе технологий семантической паутины. Так как я уже переболел голым PHP, SQL, ZF, и имел опыт программирования на Ruby on Rails, ознакомившись с существующими гемами и решениями для работы с RDF, решил писать на нём, т.к. не очень люблю яву (да простят меня ява-разработчики), хотя она и является самым передовым языком в области semantic web, intelligent agents, data mining.

Статья расскажет о том, как получать сообщения от вашего Rails-приложения по протоколу XMPP (Jabber) и наоборот, управлять приложением, отправляя ему команды через XMPP.