Зачем.

В этой маленькой статье, которую с удовольствием прочитал бы сам неделю назад, я попытался собрать все вещи, которые понадобились бы человеку, задумай он «с нуля» написать приложение на RoR. То есть не углубляясь ни в одну из областей, описать необходимый минимум действий, чтобы установить, настроить и написать своё первое приложение.Здесь собрано, как мне кажется, всё, что нужно и я надеюсь этот текст сэкономит кому-нибудь несколько часов поиска в интернете). Сам изучаю RoR вторую неделю, так что не судите строго).

Установка.

Просто и быстро ror ставится через rvm c rvm.io.

>\curl -L https://get.rvm.io | bash -s stable --rails --autolibs=enabled

Запустить rvm:

>source /Путь_к_домашней_директории*/.rvm/scripts/rvm

*$HOME в дальнейшем.
После этого в $HOME/.bash_profile должна появиться строчка:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

и при каждом открытии консоли rvm будет подгружаться, но у меня этого не случилось — пришлось ещё в $HOME/bashrc прописывать:

. ~/.bash_profile

Теперь всё точно должно быть хорошо.
Устанавливаем нужную(скорее всего это будет самая последняя) версию руби (сколько их и в чём отличие можно посмотреть здесь -http://www.ruby-lang.org).

>rvm install 1.9.3

Проверка на успешность создания

>ruby -v

должна вернуть более подробную информацию, вроде

ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux].

В процессе установки я случайно установил несколько версий, что потом доставило некоторые неприятности). Посмотреть список установленных версий руби можно так:
>rvm list
Если версий несколько, то текущая будет помечена "=>", дефолтная — "*", а текущая и дефолтная — "=*". Поменять на нужную используемую версию можно так:

>rvm use ruby-1.9.2-p320 (любая нужная версия)

Чтобы поменять дефолтную версию руби пишем:

>rvm use ruby-1.9.2-p320 --default

В январе этого года, Sandi Metz представила свои правила для разработчиков в эфире подкаста Ruby Rogues. Примерно в это же время, я и моя команда начали новый проект. Эта статья описывает тот опыт, что мы получили, применяя эти правила к своему новому проекту.

Правила

1. Классы не могут содержать больше чем 100 строк кода.
2. Методы не могут быть длиннее чем 5 строк кода.
3. Нельзя передавать больше 4 параметров в метод. Значения хэша также считаются параметрами.
4. Контроллеры могут инстанциировать только один объект. Следовательно, представление может знать только об одной инстанс переменной и должно только слать сообщения этому объекту (@object.collaborator.value не допустим).

Здравствуйте, я — разработчик программного обеспечения на Ruby / Rails и я комментирую свой (а с недавних пор ещё и чужой) код. Голос из зала, вероятно, крикнул бы «Привет, разработчик!»

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

Об использовании JavaScript-фреймворка Backbone.js написано много, но просто и кратко — мало. Я постараюсь исправить этот недостаток и рассказать разработчикам web-приложений максимально просто, доступно и кратко о том, зачем им может пригодится этот фреймворк и как, в общих чертах, он работает. Профессионалы и специалисты по Backbone.js: можете не тратить время, этот рассказ для новичков. Если быть честным, то для чтения этой заметки не обязательно быть Rails-developer'ом, надеюсь, статья пригодится всем, кто работает с любым из МVC-фреймворком.

Rails 4 вышли две недели назад, а вы все еще сидите на третьих? Вас останавливает трудоемкий процесс проверки работоспособности всех подключенных гемов? Не беда! Буквально 10 дней назад стартовал веб-сервис по проверке совместимости гемов и Rails 4 от frodsan и Florent.

Миллион раз уже слышал о том, что делать проект на Heroku — признак слабого знания linux-систем и банальной лени. С одной стороны — есть в этом что-то такое, но с другой деплой приложений, в данном случае я говорю о Rails приложениях, одной строкой и отсутствие заморочек с настройкой машины — это шикарно. Так давайте поговорим о мифах против heroku, которые я слышал уже несколько сотен раз.

Аутентификация пользователей в экосистемах наподобие Google или Envato реализована в виде отдельных сервисов (accounts.google.com, account.envato.com), предоставляющих необходимые данные и токены сайтам-клиентам. В ходе разработки некоторых проектов на Ruby on Rails мне и пришлось столкнуться с подобной задачей. По-научному — single sign-on или технология единого входа.

Нужен был (1) общий сервис для всех сайтов экосистемы, с (2) преимущественно социальной авторизацией, в угоду входу по связке «логин+пароль».
Сервис, (3) аккумулирующий в себе данные из тех социальных сервисов, с помощью которых пользователь входит в систему, и (4) предоставляющий эти данные сайтам-клиентам.

Задача оказалась настолько же интересной, насколько и нестандартной. Началось все с полезной, но уже немного устаревшей статьи — автор предлагал использовать гем omniauth и кастомную стратегию на сайтах клиентах, а на сайте-провайдере — использовать тот же omniauth в связке с devise для аутентификации через соц. сервисы.

Devise в моем случае подходил мало (завязка на логине+пароле), поэтому предпочтение было полностью отдано omniauth. С этого и началось мое маленькое приключение, о ходе которого предлагаю вам ознакомиться в данной статье.

Доброго времени суток!

Перечитывая блог Signals Vs Noise я наткнулся на интересную статью

В ней рекомендовали создать rake задачу, которая полностью подготовит ваше приложение к разработке после клонирование из репозитория.

> `rake setup`

> All our apps has a rake setup task that’ll run bundler,
> create the databases, import seeds, and install any auxiliary
> software (little these days) or do any other setup. So when you git
> clone a new app, you know that “rake setup” will take care of you.

Я расскажу о том, как сделать подобную задачу в Ruby On Rails приложении.

Несколько дней назад Константин Хаасе, один из ключевых людей в сообществе Ruby, опубликовал запись в своём блоге, посвящённую анонсу предварительной версии Ruby 2.1. Изменений между версиями 2.0 и 2.1 накопилось достаточно, чтобы вчитаться в его изложение, и лучше — на русском языке.

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

I-Tier: Расщепление монолита

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

С самого начала весь веб-фронтенд американского Групона был единым исходным кодом Ruby. Код фронтенда быстро развивался, что затрудняло его поддержку и усложняло процесс добавления новых фич. В качестве решения проблемы с этом гигантским монолитом мы решили реструктурировать фронтенд посредством его разделения на меньшие, независимые и более простые в управлении части. Основой этого проекта стало разделение монолитного вебсайта на несколько независимых Node.js приложений. Мы также переделали инфраструктуру, чтобы обеспечить совместную работу всех приложений. Результатом стал Interaction Tier (I-Tier).

Вот некоторые из важных моментов этой глобальной архитектурной миграции:

• Страницы на сайте загружаются значительно быстрее

• Наши команды девелоперов могут разрабатывать и добавлять новые фичи быстрее и с меньшей зависимостью от других команд

• Мы можем избежать повторной разработки одних и тех же фич в разных странах, где доступен Групон.

Этот пост является первым из серии постов о том, как мы реструктурировали сайт и какие огромные преимущества мы видим в дальнейшем, которые будут лежать в основе продвижения компании Групон.

В своем прошлом посте я постарался достаточно детально описать все тонкости установки Redmine на Linux Ubuntu. В этом, хочу рассказать о тонкостях написания плагинов под Redmine, об основных возможностях изменения функциональности стандартного Redmine, о подводных камнях, которые встречались моей команде на этом пути.

Думаю, эта статья будет полезна тем, кто уже знаком с основами фреймворка Ruby on Rails и хочет начать разрабатывать плагины для Redmine.

Прежде всего, стоит разделить все плагины Redmine на две категории:

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

Все немного сложнее, когда плагин должен изменять встроенную функциональность!

Для изучающих Ruby / Rails, будет полезно ознакомиться с подборкой бесплатных онлайн курсов, туториалов и интерактивных занятий, посвященных языку программирования Ruby и фреймворку Ruby on Rails.

От переводчика: перевожу не ради холивара, сам RoR не знаю, но чувствую исходящее от специалистов по RoR положительное к нему отношение, мельком видел красоту и самого языка и фреймворка, но здесь не об этом. Цель перевода еще раз обратить внимание на Meteor, который развивается семимильными шагами — в начале 2014 ждем релиз 1.0. В англоязычном Интернете все кипит, а у нас тишина — лишь несколько статей.

Почему Meteor?

Помню как начинал заниматься Rails в 2004 году — это было «волшебное время» — и, конечно, я помню, что меня по крайней мере раз в неделю спрашивали, почему же стоит использовать rails. Я всегда отвечал одинаково: разработчикам нравится этот фреймворк, потому что он позволяет делать работу быстро и с удовольствием. К этому моменту я чуть больше месяца вплотную проработал с Meteor и готов ответить на вопрос: «Почему Meteor?» — который мне тоже часто стали задавать.

Не так давно, 18 декабря, состоялся релиз очередной версии Rails. Забавно, что существует пост, датированный 17-м декабря, и ссылающийся на статью из будущего. Из очередных полезностей новой версии:

• Ускорение загрузки с помощью Spring
• Единое место для хранения разнообразных ключей API, секретов и прочего: config/secrets.yml
• Предпросмотр email'ов: Action Mailer Previews
• Удобная генерация различного контента в зависимости от конкретного request с помощью Action Pack Variants
• Добавление enum-атрибутов в Active Record

Спецификации Ruby обновились до версии 2.1.0. В новой версии языка программирования сделано несколько эволюционных изменений. В неофициальных бенчмарках на Rails версия 2.1 показывает результат примерно на 20% выше, чем 2.0, которая, в свою очередь, на 60-70% быстрее 1.9.3.

Вкратце, самые важные из них:

• VM (кэширование методов)
• новый сборщик мусора RGenGC (см. презентацию ko1 на RubyKaigi и на RubyConf 2013)
• изменения в синтаксисе
  
  • новая запись дробей с использованием двух слэшей ("//") между числителем и знаменателем, см. #8430
    
    • 1 // 2 == Rational(1, 2)
    • 1 // 1 == Rational(1, 1)
    • 0 // 1 == Rational(0, 1)
  • новые суффиксы i, r и ri для записи комплексных и рациональных чисел
    
    • "42r" и "3.14r" расцениваются как рациональное число Rational(42, 1) и 3.14.rationalize, соответственно. Но экспоненциальная форму с суффиксом 'r', такая как "6.022e+23r", не принимается.
    • "42i" и "3.14i" расцениваются как Complex(0, 42) и Complex(0, 3.14), соответственно.
    • "42ri" и "3.14ri" расцениваются как Complex(0, 42r) и Complex(0, 3.14r), соответственно.
• определение функции def теперь возвращает символ её названия вместо nil, см. #3753

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

Devise — это ruby-гем, предоставляющий возможности для аутентификации в rails-приложениях. Devise работает в связке с гемом Warden, который в свою очередь предоставляет сам механизм для аутентификации в rack-базированных ruby-приложениях. Основные особенности Devise описаны ниже:

• основан на Rack;
• является законченным MVC-решением, основанным на Rails;
• разрешает вход в систему по нескольким моделям одновременно;
• основан на модульности: использует только то, что вам действительно необходимо.

Итак, приступим к установке и настройке Devise для вашего rails-приложения. Дальнейший процесс для удобочитаемости будет разбит на отдельные шаги.

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

• Facebook
• Twitter
• Livejournal
• Vkontakte

Когда я только начинал задумываться о том, чтобы приобщиться к миру веб-разработки, и выбирал язык, с которого начну, одна из википедий мне напела, что в основе философии Rails лежат 2 принципа: Convention over configuration (CoC) и Don’t Repeat Yourself (DRY). Что касается первого — я тогда вобще не понял о чём речь, а вот второй понял, принял и ожидал, что в недрах этого замечательного фреймворка, я отыщу нативный инструмент, позволяющий мне один раз написать правила валидации для атрибутов модели, и потом использовать эти правила как для front, так и для back проверок.

Представьте: Вы — веб-разработчик, который только недавно освоил Ruby on Rails. И тут Ваш первый проект подходит к стадии, когда его нужно выложить в интернет.
Вы, конечно, можете залить его на Heroku, но тамошние цены немного кусаются. Остается только купить VPS, настроить его и выложить проект туда.
«Что может быть проще? Найду какой-нибудь гайд, да следаю всё по нему» — подумаете Вы. Вот только гайдов, которые не просто выкладывают команды, но и объясняющие, что эти команды делают, — единицы, да и те используют уже устаревшую вторую версию Capistrano.

Поэтому я решил написать свой гайд, в котором постараюсь подробно рассмотреть:

• Первичную настройку сервера
• Установку и настройку nginx (с модулем PageSpeed), postgresql, redis
• Установку rvm, rails
• Настройку гема foreman для управления процессами Вашего приложения
• Настройку сервера Unicorn
• Настройку гема Capistrano (v3.1) для автоматизации деплоя

Я надеюсь, что этот гайд будет полезен не только новичкам, но и разработчикам со стажем.