Ruby on Rails *

Итак, у вас есть чистая Ubuntu, в консоли открыто ssh-соединение с сервером и консоль вас заманчиво приглашает — «root@my-awesome-host:~#» — и больше ничего нет. А хочется запустить и показать всему миру какое-то рельсовое приложение. Поехали от супа до орехов.

Думаю каждый кто работал с под-доменами в Rails 3 видел данный скринкаст.

Когда столкнулся с этим примером стояла задача сделать динамические поддомены + некоторые фиксированные. Динамические должны были соответствовать некоторому полю одной из моделей. Таким образом были выдвинуты условия для конечного решения:

• возможность указания фиксированного поддомена, либо группы поддоменов;
• возможность привязки к полю из модели ActiveRecord;
• удобный синтаксис для записи всего этого в routes.rb.

В данном посте я решил поделиться опытом разворачивания rails сервера на Amazon. Все предыдущие rails проекты я выкладывал на готовые сервера. Это были частные сервера, или широко известный сервис heroku. И единственные команды, которые я посылал серверу, были cap deploy и cap deploy:cold. Но в последнем проекте заказчик пожелал разместить сайт на своем амазоновском образе, поэтому пришлось погрузиться в тему более глубоко.

Хоть и пришла осень, а многих не покидает радостное чувство, что не нужно идти в школу или в институт. Все помнят как нужно было на вырванном листке писать программу на Delphi или С? Да уж, отставание системы образования особенно ярко выражается на примере предметов по информационным технологиям.

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

Тема простая, но мне пришлось потратить некоторое время, прежде чем из разрозненных источников я понял, как наиболее быстро и просто получить сообщения об ошибках валидации на русском. Этот пост поможет сэкономить немного времени новичкам.

Недавно друг спрашивал, нет ли у меня кода интеграции с робокассой для Rails, и так сложилось, что он у меня был. Я поделился и подумал, что, возможно, этот код может понадобится кому-либо еще, потому и решил создать этот топик здесь.

Сегодня мы предоставим вашему вниманию перевод поста Пета Аллана (Pat Allan), известного разработчика, приверженца Ruby, одного из победителей Ruby Hero Award 2009 года. Что это за награда? Она присуждается победителями прошлого года тем участникам сообщества, которые наиболее проявили себя: создали значимый обучающий контент, разработали плагины и гемы, участвовали в проектах с открытым кодом. Такая награда была создана для того, чтобы отметить наиболее проявивших себя людей и дать им признание, которое они заслуживают.

Пообщаться со Петом можно будет на конференции RubyC в Киеве 5-6 ноября этого года.

Значительную часть прошлого месяца я провел за написанием моего первого Rails engine — тем не менее я не закончил, да и сама работа была для клиента, так, что на деталях останавливаться я не могу.

В процессе разработки довольно быстро стало ясно, что необходим способ тестировать Rails engine. Не беря во внимание простейшие unit-тесты, довольно привычная практика для интеграционного тестирования — хранить копию приложения на рельсах внутри директории spec или test.

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

Привет! Есть такой замечательный JavaScript фреймворк под названием SproutCore. С помощью него можно довольно легко писать веб-приложения с приближенным к десктопному интерфейсом. Штука довольно популярная, используется например Apple в iWork.com. Под катом мы прикрутим SproutCore к последним рельсам.

Давно хотел попробовать Haml, но всё не было времени. Но вот недавно обнаружил новый шаблонизатор, который мне сразу понравился. По словам создателей, он взял лучшее от Jade и Haml. Основная задача — сократить объем кода, при этом не делая его страшным и непонятным.

Вот так выглядит шаблон с использованием Slim:

doctype html
html
  head
    title Slim Examples
    meta name="keywords" content="template language"

  body
    h1 Markup examples
    #content.example1
      p Nest by indentation

    = yield

    - unless items.empty?
      table
        - for item in items do
          tr
            td = item.name
            td = item.price
    - else
      p No items found

    #footer
      | Copyright © 2010 Andrew Stone

    = render 'tracking_code'

    script
      | $(content).do_something();

Сегодня мы предоставим вашему вниманию перевод поста Стива Клабника (Steve Klabnik), известного разработчика, приверженца Ruby, одного из победителей Ruby Hero Award этого года. Что это за награда? Она присуждается победителями прошлого года тем участникам сообщества, которые наиболее проявили себя: создали значимый обучающий контент, разработали плагины и гемы, участвовали в проектах с открытым кодом. Такая награда была создана для того, чтобы отметить наиболее проявивших себя людей и дать им признание, которое они заслуживают.
Пообщаться со Стивом можно будет на конференции в Киеве RubyC 5-6 ноября этого года.

Я часто говорю людям, что учил Ruby через Rails. Это один из худших способов, но к тому времени я уже выучил столько языков программирования, что это не мешало мне. Тем не менее, это дало мне слегка искаженное ощущение того, насколько тщательно проектировать классы, необходимые для Rails приложений. К счастью, я пристрастно просматриваю код, написанный другими, и заметил, что есть одна важная вещь, которая встречается в разработках у многих уважаемых мною людей.

Мне кажется, эти люди также считают эту вещь уникальной. Это не когда люди, не умеющие писать хороший код, стараются, но все равно получается плохо. Это как флаг, сигнал. Теперь, когда я вижу, как кто-то внедряет эту вещь, я сразу думаю: «он шарит». Возможно, я слишком сильно доверяю своему чувству, но эта продвинутая техника разработки предлагает множество взаимосвязанных преимуществ вашим Rails приложениям, легко применима и ускоряет тестирование на порядок или больше. К сожалению, для многих начинающих Rails разработчиков это неочевидно, но я хотел бы, чтобы вы писали код лучше и вот я здесь, чтобы, с вашего позволения, «раскрыть секрет» и поделиться этой мощной техникой с вами.

Обойдусь без копипастов и даже ссылок о том, что Ruby за зверь такой, ибо написано было уже сполна. В данном посте просто хочу рассказать о пути изучения Ruby (и, впоследствии фреймворка Ruby on Rails) человека далекого от программирования.

1. Любопытство

«Насколько далекого?», спросите вы, а я отвечу — «Чуть менее, чем полностью», так как в десятом классе в школе у меня были уроки программирования, парочка из которых были уделены Паскалю. Признаюсь, впоследствии о html узнал, и даже мог в Dreamweaver-e сверстать страничку или поставить готовый движок, да по инструкции налепить плагинов, но не более.
Хотя компьютеры мне нравились, пошел я учиться на экономиста* — бакалавриат, магистратура по бух. учету и аудиту, аспирантура по финансам, работа в банке, преподавание, страхование. Но не жилось мне спокойно в финансах, — финансовый калькулятор удовлетворял необходимости решения тривиальных задач, но не удовлетворял мой мозг. А ему хотелось посчитать не только будущую и приведенную стоимость актива, но и создать массив данных из исторических стоимостей этого актива за n лет, высчитать среднюю доходность, дисперсию и, в конце-концов построить красивый график!

Пост навеян долгим апробированием различных гипотез правильной работы с изображениями через Asset Pipeline после перехода на Ruby on Rails 3.1 с предыдущих версий.

Итак, Задача

В CSS файле указать изображение, находящееся в папке assets. Изображение в production-среде должно быть предварительно скомпилировано.
Казалось бы, ну что тут такого ведь есть официальный гайд, адаптированный перевод гайда, скринкаст, в конце-то концов. Здесь правило «It just works» работает только, если вы не допускали своих (или чужих) рук до чувствительных точек. Каких именно?

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

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

Представим, что в один прекрасный день вы решаете подключить oauth2 к своему проекту на ruby on rails. Так как аутентификация большинства rails приложений сейчас идет через devise, то неплохо было бы заинтегрировать oauth2 с этим гемом. Благо, все придумали до нас, поэтому встречайте — devise_oauth2_providable. С этим гемом интеграция и тестирование oauth2 провайдера у вас отнимет времени не больше, чем поход в магазин.

Эта статья ставит целью описать решение одной нетривиальной задачи — автоматическая односторонняя синхронизация данных в базах двух проектов средствами Ruby on Rails, гема legacy_migrations и относительно прямых рук.

Исходная ситуация

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

В большинстве рельсовых проектов основная концентрация кода приходится на модели. Все наверняка читали про Slim controllers & fat models и стараются впихать в модели как можно больше, а в контроллеры как можно меньше. Что ж, это похвально, однако в стремлении утолстить модели многие часто забывают про принцип DRY — don't (fucking) repeat yourself.

Я тут постараюсь вкратце расписать, как в районе моделей и рыбку съесть, и про DRY не забыть.

Популярность фреймворка Ruby on Rails постоянно растет, общество становится шире и, если раньше об использовании Ruby на Windows говорилось редко, то сегодня это вполне реальная практика.

Такие проекты как RubyInstaller (http://rubyinstaller.org/) и RailsInstaller (http://railsinstaller.org/) значительно упрощают создание рабочей среды на Windows. Вы можете использовать нативный MRI 1.8 и 1.9, JRuby или даже IronRuby работающий на .NET. С Windows работает большинство gem-пакетов, причем благодаря DevKit (https://github.com/oneclick/rubyinstaller/wiki/Development-Kit) «сишные» джемы можно собирать прямо из исходников.

Однако, несмотря на активное развитие средств разработки, до сих пор Windows и в частности веб-сервер IIS практически не использовались как «продакшн» решение для развертки Rails приложений. Но с появлением нового инструмента Helicon Zoo на базе Web Platform Installer – эта ситуация поменялась.

Helicon Zoo

Helicon Zoo – это репозиторий веб фреймворков и приложений, позволяющий легко устанавливать и запускать Rails, Django (фактически любые rack, wsgi или FastCGI приложения) и Mojolicious на веб-сервере IIS.

 

Недавно я столкнулся с необходимостью реализовать небольшой чат в одном из Rails-проектов. Существует много способов решения данной задачи, начиная от периодических опросов сервера с помощью AJAX и заканчивая использованием готовых решений сторонних сервисов. С целью минимизации трафика и времени отклика системы было принято решение использовать WebSocket API – одну из частей стандарта HTML 5, позволяющую серверу инициировать передачу данных, не дожидаясь запроса клиента. К сожалению WebSocket API поддерживается достаточно ограниченным числом браузеров, среди которых Google Chrome, Safari 5, Mobile Safari в iOS 4.2 и выше и пожалуй все (если я ошибаюсь – поправьте меня в комментариях). Конечно же этого недостаточно для боевого приложения, поэтому необходимо предложить запасной вариант для браузеров без нативной поддержки WebSocket API. Удобнее всего в этом случае использовать Flash Sockets. С помощью WebSocket API и Flash Sockets приложение покрывает большую часть возможных случаев, включая как настольные системы (MS Windows, Linux, Mac OS X), так и мобильные (Android, iOS).

Введение

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