Jeiwan

Лучше оставьте в стороне пока эти идеи об объединении Ангуляра и Рельс и просто почитайте rusrails.ru, поизучайте сами рельсы. Ну и вообще, потратьте какое-то время, чтобы разобраться, как вообще взаимодействует браузер с HTTP-сервером. Судя по вопросу, вы совершенно не представляете, что делаете, и любые попытки дальше работать с этими фреймворками будут только создавать проблемы.

А если по сути вопроса, то контроллеры Ангуляра и Рельс "объединяются" через HTTP-запросы: ангулярный контроллер обращается к ангулярному сервису, который отправляет асинхронный запрос рельсовому серверу, в котором этот запрос попадает в тот или иной контроллер.
Ангуляр и Рельсы — два разных фреймворка, написанные на разных языках, работающие на разных сторонах баррикады: Ангуляр — на фронтэнде (в браузере у пользователя), Рельсы — на бэкэнде (на сервере бородатого админа). Как может взаимодействовать браузер с HTTP-сервером? Только посредством HTTP-запросов.

Если у Item нету Collection, то и не будет поля, поэтому вторым параметром в fields_for нужно передавать инициализированную модель:

= f.fields_for :collection, @item.collection.new do |builder|

Нужно по-другому сформировать данные для списка, в параметр collection: нужно передавать:

[
  ['Московская область', 0, { lattitude: 55.5, longitude: 37.3 }],
  ['Ленинградская область', 1, { lattitude: 54.53, longitude: 34.345 }]
  ...
]

То есть массив массивов, первый элемент которых — текст для option, второй — value, третий — хеш атрибутов.

Задачу сформировать такой массив оставлю вам :)

/user/id1/create_event — это не Rails-way. В рельсах уже всё придумано за вас:

resources :users do
  resources :events
end

В общем, обычный вложенный ресурс. Для создания события использовать экшен create контроллера EventsController. Путь будет /users/:id/events, метод POST.
В контролллере EventsController в экшенах события искать через пользователя, т. е. (пример для show):

@user = User.find(params[:id]])
@event = @user.events.find(params[:event_id])

Путь для show будет /users/:id/events/:event_id.
Всё стандартно и обычно. Советую выучить www.rusrails.ru/rails-routing

www.rusrails.ru/active-record-callbacks

www.rusrails.ru (или guides.rubyonrails.org) – этого начинающему хватит на долгое-долгое время. Конкретно по работе с БД — раздел "2. Модели".
После освоения основ можно переходить к https://www.railstutorial.org/book, https://pragprog.com/book/rails4/agile-web-develop... и ко всему, что выдает гугл по запросам "ruby on rails tutorial", "ruby on rails book" и т. п.
На сайте https://mkdev.me/ можно скачать бесплатную книгу-путеводитель по разработке на Рельсах. А ещё сайт предлагает услуги менторства, что очень полезно.
После прохождения пары десятков туториалов и обретения навыка самостоятельной разработки небольших приложений можно записаться на отличный курс – www.thinknetica.com, а после него уже можно будет устраиваться на работу, а там уже... там уже, собственно, всё только и начнется.

Здесь не нужна таблица Assistants, а нужно просто правильно настроить ассоциации:

User.rb
has_many :assistants, class_name: 'User', foreign_key: 'main_id', primary_key: 'id'
belongs_to :main, class_name: 'User'

Ну и в Users нужно добавить колонку main_id, в которой для ассистентов будет указываться id'шник главного пользователя. У главного пользователя в этой колонке будет nil.

Как-то так:

constraints subdomain: 'admin' do
  scope module: 'admin', as: 'admin' do
    resources :users
  end
end

Во-первых, Рельсы — это просто Руби. Все достоинства Рельс вытекают из достоинств Рубей. У Руби довольно хороший АПИ, в котором присутствуют решения для большинства программистских рутинных задач — это очень удобно.
Во-вторых, Рельсы — это набор хорошо спроектированных гемов. Не нравится что-то? Можешь выкинуть или заменить. Никто не заставляет использовать все компоненты Рельс.
В-третьих, Рельсы — это хороший пример возможностей ООП Рубей.
В-четвертых, convention over configuration. Новички называют это магией, но для более-менее опытного руби-программиста в этом нет никакой магии. И благодаря этому подходу, опять же, удалось избавить программиста от постоянного рутинного выполнения одних и тех же, "операционных", задач. Другой пример, демонстрирующий этот принцип, — Backbone и Angular: в Бэкбоне нужно много рутинных задач решать (даже не решать, так как это примитивные задачи, а просто каждый раз прописывать их) самому, а в Англуяре эти задачи уже решены.
В-пятых, Рельсы — вполне зрелый инструмент решения задач веб-разработки. Он уже давно вышел из хипстерской стадии, и вместе с этим ушло большое количество людей, которых привлекают только модные, находящиеся у всех на слуху, технологии. Рельсы (как и Руби) до сих пор развиваются и не собираются умирать.
В-шестых, эстетика и лаконичность Руби. Лично я не вижу никакого смысла в излишних кавычка, скобках, точках с запятой. Не за чем визуально засорять код второстепенными элементами. Языки программирования постепенно становятся более социальными, более доступным людям — и это правильно.

Но это всё дело вкуса, в большей степени. У вас уже сложилось свое видение языков программирования, вам теперь кажется, что отсутствие типов — это недостаток. Лично я считаю, что это неправильно. Это такая же ситуация, как когда ты начинаешь чем-то заниматься (играть на гитаре, например) и изначально делаешь что-то неправильно (постановка пальцев), то у тебя эта вредная привычка закрепляется и потом мешает дальше развиваться. Тебе трудно становится переучиться на другое, так как ты уже сильно привык к этому, неправильному, способу. Я не говорю о том, что строгая типизация это неправильно, нет, дело в другом. Есть разные парадигмы программирования, есть разные подходы к программированию, и хороший программист должен владеть ими (ну или стремиться к этому) и не ставить какой-то из них во главу угла. Главное, не какой язык, а что на нем можно делать, какие задачи решать.

Видится только такое решение: добавить в таблицы products_videos и product_groups_videos колонку position, в которую сохранять порядковый номер видео в списке. То есть для этого примера:
Есть Товар 1 к которому относятся видео 4,1,3
у видео 4 position = 0, у видео 1 position = 1, у видео 3 position = 2 (точнее не у самих видео, а у записей в таблицах-связках). И потом сортировать по этой колонке.
А позиции эти можно задавать при создании товара и группы. Или вообще сделать, чтобы они автоматически проставлялись в зависимости от порядка загрузки видео.
По поводу выборки, должно получится что-то вроде этого: Product.find(1).videos.order('product_videos.position') — но я не уверен, что тут будет доступна product_videos для сортировки, не помню, какой запрос делается при has_and_belongs_to_many.

Всё это в теории, но, по идее, должно сработать. :)

factory – это метод, которому передается параметр :home (в руби, как известно, круглые скобки можно опускать) и блок (всё, что между do и end). factory вызывается в блоке, который передается в FactoryGirl.define, где define – метод класса FactoryGirl. И, да, всё это и есть тот самый DSL.
test = create (:home) – на самом деле, полная запись выглядит как FactoryGirl.create(:home). Просто чтобы не писать постоянно класс FactoryGirl, его методы инклудят в файле spec_helper.rb: config.include FactoryGirl::Syntax::Methods
Тема довольно трудная для понимания. О том, как устроен FactoryGirl очень хорошо написано в статье https://robots.thoughtbot.com/writing-a-domain-spe... – там пишется свой FactoryGirl с объяснением всех моментов.

Если статусов будет только два (Обработан/Не обработан), то достаточно булеана.
Если статусов будет много, то лучше прикрутить state-machine (AASM/Workflow). В этом случае можно будет сделать, чтобы на в разных статусах были доступны разные действия с заказом.
Если статусов будет много, но стейт-машина избыточна (или лень возиться с ней), то можно воспользоваться стандартной рельсовой фичей enum (edgeapi.rubyonrails.org/classes/ActiveRecord/Enum.html).

Создавать отдельную модель как-то совсем избыточно. Только если там ещё какой-то функционал будет, но сходу придумать какой-то пример не могу.

describe '.authenticate_with_token' do
  before do
    allow(authentication).to receive(:current_user).and_return(nil)
    allow(authentication).to receive(:render) do |args| # возвращаем аргументы
      args
    end
  end

  it 'returns error' do
    expect(authentication.authenticate_with_token![:json][:errors]).to eq 'Not authenticated'
  end

  it 'returns unauthorized status' do
    expect(authentication.authenticate_with_token![:status]).to eq :unauthorized
  end
end

Ваша ошибка в том, что вы думаете, что тестируете контроллер. На самом деле, контроллер здесь нужно только для того, чтобы было можно протестировать методы модуля (для инклуда модуля можно даже взять голый класс). И метод response тут будет недоступен, так как мы тестируем модуль, а не контроллер.