Jeiwan

Если у 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

Прокачатьcя во фронтенде - получить ачивку "Front-end develop". Создать портфолио, набраться опыта).
Двинуться к Back-end (Ruby/Rails).
Параллельно учиться рисовать и работы выкладывать на стоки.

Ну вот ты и решил свою проблему. Что ещё нужно? Пробуй, что можешь, и делай, что нравится. Как там у тебя всё сложится — хрен его знает, у бабы Ванги сегодня выходной.

Устройся на работу – это самый лучший вариант обучения. И это единственная возможность получить опыт в решении конкретных прикладных задач, за которые и платят деньги. Если хорошо знаешь верстку, то, думаю, тебе не проблема будет устроиться верстальщиком с перспективой развития до фронт-энд разработчика — довольно часто ищут не матерых спецов, а людей с горящими глазами, желающих развиваться.
Нет смысла тратить годы на подготовку. Поищи вакансии, походи на собеседования, посмотри, что тебе нужно подтянуть, подтяни. Устроишься на работу — и навыки пойдут в гору.

Сначала нужно расписать функционал приложения по пунктам: составить список тех функций, которые будут у приложения. Далеко в будущее заходить не надо, так как планы могут поменяться.
Потом взять те пункты, без которых приложение не состоится, самые минимальные и базовые вещи, и сделать их. Например, для магазина это: витрина товаров, возможность заказать товар, указав адрес доставки. Корзина и регистрация на этом этапе не обязательны, так как магазин может работать и без них. А без витрины и возможности заказать товар не может. После реализации этих базовых функций уже можно накручивать функционал дальше.
Суть в том, что на каждом этапе у тебя должно быть законченное, рабочее приложение. Разница между этапами — степень проработки деталей функционала приложения. Это метод прогрессивного джипега :) Или agile.
Чтобы понять, с чего начать, нужно посмотреть на приложение глазами пользователя: пользователь заходит на сайт, видит витрину товаров, видит описание у товара, цену, другие параметры, кнопку купить и т. д. То есть нужно реализовывать сценарии поведения пользователя. Можно даже acceptance-тесты накатать — помогает собрать мысли.

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

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

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