Антон Дьячук

Во первых, у вас есть свзяь вопросов и ответов, например questions has_many answers
тогда вам доступно с статическом режиме(одно поле для ответа в ваших терминах)

<%= f.fields_for :answers, @question.answers.new do |answer_fields| %>
    <%= answer_fields.text_area :text %>

Аналогично, для существующих у вопроса ответов

<%- @question.answers.each do |answer| %>
<%= f.fields_for :answers, answer do |answer_fields| %>
    <%= answer_fields.text_area :text %>
#etc

Во вторых, вам вручную нужно сконструировать форму для динамического добавления формы, если вы хотите добавить форму нового ответа к вопросу через javascript
Или сохранять текущий вопрос стандартно, и рендерить форму заново в которой будут поля для существующих ответов и поля для нового ответа

В третьих, вам нужны accepts_nested_attributes :answer_attributes для обслуживания ответов вложенных в вовпросы
Обо всем этом тут написано в общих чертах

> remote: ! Detected sqlite3 gem which is not supported on Heroku.
> remote: ! https://devcenter.heroku.com/articles/sqlite3

Первое что нужно сделать, это научиться читать то что пишет деплоер, а не постить вопросы в тостер.

Задача не имеет общего решения, поздравляю вас.
Я в свое время выносил в обработчик, который генерировал теги на основании правил контроллеров, собирал коллекции объектов. Вызывал в апп контроллере и йелдил в шаблоны. Тексты хранил в I18n.

Очевидно в my.js

Во первых, на таких количествах достаточно уведомления
Во вторых, ФИО и адрес не позволяет идентифицировать личность
Для успокоения совести достаточно уведомить регулятора

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

Извините за оффтоп, но свиньи очень разборчивы в апельсинах. Прошу не обижать попусту этих милых животных :)

rake db:drop
rake db:create
rake db:migrate

mperham.github.io/sidekiq
https://github.com/tobiassvn/sidetiq

class MyWorker
  include Sidekiq::Worker
  include Sidetiq::Schedulable

  recurrence { monthly }

  def perform
    # do stuff ...
  end
end

Начал давать платные консультации месяц назад, пока 1 клиент, полет нормальный.

Покупайте, хорошая вещь!

За то, что, код можно прочитать в слух, и код от этого не потеряет ясность.
За то, что англо-русский словарь нужен для именования переменных
За то, что именование переменных и выбор общего алгоритма — едиснтвенное о чем приходится думать.
За то, что при программировании на Ruby 99% уходит на проектирование поведения, и 1% на программирование
За то, что по первой строке ошибки можно определить где и в чем ошибка
За то, что интеграционные тесты можно писать на русском, от чего заказчик обливается слезами умиления и расстается с деньгами
За то, что вызывает ООП головного мозга
За то, что технилогический уровень, и технологическое качество на голову выше программы ВУЗ-ов
За то, что высокий порг вхождения по IQ на нет сокращает количество быдлокодеров
За то, что разработка вызывает просто животный восторг граничащий с оргазмом
За то, что разработкой в кайф реально можно заниматься по 16 часов в сутки и не сломать себе мозг
За то, что на форуме тебе не скажут: лол ты нуб иди читай маны днище!!111адинадин
За то, что, возможно, ваше изящное решение еще никто не использовал
мне на работу пора, а так я могу очень долго писать

groups.google.com/forum/?hl=ru&fromgroups#!forum/ror2ru

Самые полезные плагины, как мне кажется, пишутся вручную

1. 30 млн строк и 200 записей в сутки
150000 суток — 410 лет
С учетом «десятка мелких таблиц связанных» 41 год, даже в этом случае записи устареют
2. Вменяемая структура, с грамотными индексами даст вам производительность сопоставимую с 1к записей и 10м.
3. Денормализация таблицы может быть полезна для организации эффективной системы индексов.
4. 86400 секунд в сутках, 8640 запросов в сутки может обработать ваша система, даже если длительность запроса будет доходить до 10 секунд.
5. Обратите внимание на то, каков будет результат выборки, может ли результат каждой выборки содержать 1м записей? Ограничивайте результаты.
6. Шардинги необходимы на больших нагрузках, в случае тысяч записей в сутки, шардинг, как мне кажется не нужен.
7. При таком объеме, база будет занимать 15-150Гб ориентировочно, опять же, как мне кажется шардинг снова не нужен.

1. Как мне кажется наиболее эффективный метод работы выглядит следующим образом
GET /reports(.:format) reports#index (коллекция)
GET /reports/:report_id/images image#index (коллекция)
POST /reports(.:format) reports#create (создание)
GET /reports/new(.:format) reports#new (инициализация, удобный прием, в разрезе REST можно не рассматривать)
GET /reports/:id/edit(.:format) reports#edit (иницаилизация, данные для редактирования)
GET /reports/:id(.:format) reports#show (конкретный объект)
PUT /reports/:id(.:format) reports#update
DELETE /reports/:id(.:format) reports#destroy
DELETE /reports/:report_id/images images#destroy
PUT для коллекций ниразу не пришлось использовать, выдумывать ничего не буду

2. Вторая часть рест — коды ошибок
Например эффективно используется в связке с jQuery: евенты success, error и т.д. отзываются корректно.

3. (самое важное) Межсистемное взаимодействие.
Restfull API интуитивно понятен разработчикам сторонней системы, если конечно разработчики представляют что такое рест
В любом случае, при межсистемном взаимодействии, важно пользоваться единым стандартом, а разрабатывать его налету — опасно. Большинство выбрали REST, если я не заблуждаюсь.

4. Никакой путаницы.
Ни в приложении, ни во фронтенде, ни в API, при использовании REST, вы совершаете одинаковые действия, с одинаковыми объектами, обращаясь на одинаковые URL, с одинаковыми наборами параметров. Поведение всех систем предсказуемое, все подвластно единой концепции.

1. у Ruby есть OpenStruct, поищите реализацию для PHP
Rails позволяет сериализовывать в OpenStruct
2. На монге свет клином не сошелся, можно использовать все что угодно. Мой MySQL сложные поиски по нормализованным данным производит за считанные миллисекунды при сотнях тысяч записей. PostgreSQL умеет делать это еще быстрее. Для поиска можно использовать Sphinx.
3. Нормализация большого количества атрибутов имеет разумный предел. Недавно писал таблицу с 150 полями. Хранить все 150 полей одного объекта в нормализованном виде — бред и адский труд.

Давно уже пора уходить в облака, и не тратить ресурсы на поддержку собственных решений.
Google Apps