Не секрет, что продукты, разработанные на Ruby on Rails представляют собой жесть при установке. Разные версии ruby, разные версии конфликтующих gem и все такое делают жизнь тяжелее и грустнее.

 Пока не появился docker. Docker это чудо. Это Git для файловой системы.При помощи Docker установка gitlab или redmine становится почти тривиальной. 

Я попробую объяснить что такое Docker "на пальцах". Во-первых проще всего понять docker если рассматривать его как эдакую виртуализацию. Во-вторых docker имеет инструментарий для связывания одного виртуального окружения с другими окружениями. В-третьих это реализация концепции "одна роль – один сервер". В случае докера замените сервер на "контейнер" и получим "одна роль – один контейнер". Что круто само по себе и имеет ряд интересных эффектов. Один из таких эффектов это возможность передавать на тестирование, в продакшен или еще куда наше веб-приложение, которое уже установлено и гарантированно работает так же как и у разработчика. 

Вот несколько концепций, которые вам помогут понять, что такое docker.

1. Docker Image. Образ файловой системы, ее слепок с необходимыми библиотеками и софтом. Скажем, окружение веб-сервера. Вы можете создавать образы самостоятельно или загружать уже готовые, такие как gitlab или redmine.

2. Docker container. Используя образ файловой системы запущенный в памяти (или лежащий незапущенный на диске) производный образ от docker image. Допустим, запущенный веб-сервер.

3. Volume. "Расшаренная папка" между контейнером и хостовой файловой системой.

4. Port. "Проброс портов" или когда сетевой порт хостовой машины соответствует порту контейнера.

5. Link. Линковска это способ взаимодействия контейнеров между собой. Один контейнер ничего не знает про другой, но используя линковку можно ставить переменные окружения, внутренние хосты, которые будут уквзывать на ресурсы второго контейнера. Например, линкуя наш контейнер с контейнером с базой данных мы будем иметь доступ к порту базы данных и IP сервера базы данных из другого контейнера. 

Ниже я опишу установку такой специфичной штуки как gitlab. С docker это сделать очень просто. 

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

Вот пример запуска gitlab в две строки!

wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml

docker-compose up

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

 

 

Не секрет, что после установки Snow Leopard много чего перестало работать корректно, в т.ч. и mysql gem.

Рецепт излечения предлагаю познать из нижеследующей ссылки: http://www.icoretech.org/2009/08/install-mysql-and-mysql-ruby-gem-on-snow-leopard-64-bit/ 

 

Попробую пояснить термины приведенные выше.

Scrum - методология разработки основанная на agile. Если в двух словах вся разработка делится на Истории (Функционал), созданные совместно командой разработчиков и заказчиком. Заказчик излагает требования по функционалу, например, хочу редактировать статьи. Разработчики пишут три сценария для такого функционала: добавление, изменение и удаление статьи.

Каждая история получает очки по скорости разработки, например, добавление и изменение по 10 очков, а удаление статьи 5 очков. Добавляем параметр важности. Например, важность добавления - 5, важность изменения 10 и важность удаления 15.

Производительность команды измеряется в очках/период разработки. Например, принимаем производительность команды за период 3 недели (эти три недели будут называться Спринт) в 15 очков. Отсюда видно, что заказчик может или потребовать реализацию удаления и изменения за один Спринт, или реализацию удаления и добавления повысив важность фичи добавления.

А в следующий Спринт будет добавлен недостающий функционал, например, добавления статьи. 

Обязательным моментом в описании Сценариев является описание методики тестирования, например, нажми туда, смотри здесь и получишь это. 

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

Свежепоявившийся Cucumber позволяет в почти такой же манере scrum описывать функционал со сценариями и ... проводить тестирование rails приложения иногда называемое интеграционными тестами.

Для тестирования в Cucumber может использоваться как библиотека Webrat, по сути рендерит выдачу HTML эмулируя браузер, и позволяет такие вещи, как заполнить поле формы, нажать на кнопку,открыть ссылку прямо в коде ruby и получить результат, который будет  сравнен с ожидаемым. Типично - заполнить пароль и логин в форме, и сравнить, есть ли в выдаче сообщение "добро пожаловать _пользователь_". При еще более глубоком погружении есть возможность использовать Selenium - фреймворк для тестирования прямо через вызовы браузера и использования его DOM, т.е. натурально, запускается фаерфокс, и через его DOM производится тестирование вывода страницы. Что вообще говоря позволяет вовсю тестировать Ajax плагины, работу Prototype и jQuery, что, если не ошибаюсь, Webrat  делать не умеет.

Следует заметить, что Cucumber  это верхний уровень абстракции тестирования который заменяет традиционные интеграционные тесты, для тестов на нижнем уровне все равно прийдется использовать Test::Unit или RSpec, выбор за вами.

Очень подробно тематика освещена здесь.

 

Между тем Mocha - прекрасный фреймворк - замена c более красивым названием mocking and stubbing для RoR.

 Выглядит примерно так:

  def test_mocking_a_class_method
    product = Product.new
    Product.expects(:find).with(1).returns(product)
    assert_equal product, Product.find(1)
  end

  def test_mocking_an_instance_method_on_a_real_object
    product = Product.new
    product.expects(:save).returns(true)
    assert product.save
  end

 

Features. Это прекрасно!

Продолжая тему BDD следует отметить, что story runner выпочковался в отдельный фреймворк под названием Cucumber (огурец).

Теперь истории выглядят так:

мой реальный пример из features/admin_artices.feature

Функционал: Админ может добавлять, удалять и изменять статьи
  Что бы админ мог управлять статьями
  Как администратор сайта
  Я должен иметь возможность удалять, добавлять и изменять статьи
  Как пользователь
  Я должен видеть отредактированные статьи

Сценарий: добавление новой статьи
  Сначала admin is logged in as nexus
  И can view article list in admin zone
  Если I create new article title bbb
  То user should see it in the articles list /articles/my-new-article

Сценарий: редактирование существующей статьи
  Сначала admin is logged in as nexus
  Если admin edit article foo and save content blabla
  То user should see blabla at url /articles/foo

Сценарий: удалить существующую статью foo
  Сначала admin is logged in as nexus
  И статья с url foo доступна пользователю
  Если админ удаляет статью с урл foo
  То юзер в списке статей не видит ссылку на статью foo

  читать далее >>

Вот ведь как бывает, когда обновляешь систему с rails сайтами.

Все сайты крутились под Freebsd 4.11 и как-то незаметно пришло время обновиться. Поставилась FreeBSD 7, установились свежие рельсы, и наступила пора переноса сайтов. Ох.

Некоторые сайты крутились еще на fcgi, и использовались rails 1.1.6.

А не перевести ли на Rails 2? Сказано-сделано. Для начала завести все как было на новом хосте.

Не буду утомлять, пришлось сделать правки в mysql.rb как написано здесь 

http://railized.com/2008/2/17/wrong-argument-error-when-running-rails-1-1-6-with-ruby-1-8-6

и в boot.rb заменить require_gem на gem в двух местах. И, в принципе, все поднимается.

Ах да, если юзалась LoginSystem от Rails 1, то в Rails 2 об этом следует забыть и часть кода попросту переписать.

PS. Git рулит!

 

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

Тем, кто пользуется для разворачивания приложений capistrano есть хорошая новость: сделать такую вещь весьма несложно.

Итак, у нас в production FreeBSD 7.0, для разработки пользуемся рабочей станцией с ubuntu 8.04.

Рецепт capistrano слегка модифицированный взят отсюда: http://programmingishard.com/code/495

добавляем в config/deploy.rrb

 desc "Load production data into development database"
task :load_production_data, :roles => :db, :only => { :primary => true } do
  require 'yaml'
 
  database = YAML::load_file('config/database.yml')
 
  filename = "dump.#{Time.now.strftime '%Y-%m-%d_%H:%M:%S'}.sql"
  on_rollback { delete "/tmp/#{filename}" }
 
  run "mysqldump -u #{database['production']['username']} --password=#{database['production']['password']} #{database['production']['database']} > /tmp/#{filename}" do |channel, stream, data|
    puts data
  end
  get "/tmp/#{filename}", filename
#  exec "/tmp/#{filename}"
  exec "mysql -u #{database['development']['username']} --password=#{database['development']['password']} #{database['development']['database']} < #{filename}; rm -f #{filename}"
end

после чего пользуемся:

cap load_production_data

и вуаля, свежая копия базы с production у нас в development!

 

Тихо и незаметно вызрел еще один сайт на Ruby on Rails. 

Сей сайт находится по адресу http://nxt.com.ua

Rails 2.0, пользует плагины acts_as_tree, in_place_editing, restful_authentication, tiny_mce 

 

 

От читателя поступил вопрос, как сделать так, что бы в браузере изображений url были бы не вида ../../images, а /images ?

Очень просто, достаточно добавить в вызов tiny_mce  в контроллере такие параметры:

:relative_urls=>false,
:convert_urls=>true

и ваши url будут вида /images  и т.д.
хотя, при правильной разработке, этого не требуется.