vsuhachev

Если имеется в виду кэширование фрагментов, то вот

Гляньте генераторы статических сайтов

Если речь идет о рельсах - ассеты собираются в один файл и по другому никак. Если вы хотите запилить свой сборщик то поставьте гем sass и вызывайте sass-convert с указанием ваших путей.

Hint: изучите Rake, с ним свой сборщик можно создать за 5 минут

Наиболее подходящий вариант нельзя посоветовать не зная ваших объемов данных и того как вы планируете это использовать.

Если время поиска не критично, типов данных мало, нужно простое и переносимое решение, то я бы посоветовал вариант 1 с сериализацией различных типов в строку.

Вариант с постгревыми json/jsonb добавляет гибкости/производительности, но в json простые типы это число, строка и булев. Даты и прочих типов там нету. Для jsonb поддерживаются индексы. Это решение означает жесткую привязку к PG.

Есть еще вариант похожий на 1, но с заданием разнотипных колонок и хранением в каждом свойстве его типа. Запросы будут выглядет как-то так

SELECT * FROM profile_field_values
WHERE 
  (property_field="дата рождения"
  and value_type="date" and value_date > ?)
and
  (property_field="размер ноги"
  and value_type="integer" and value_integer < ?)

По скорости вы выиграете, но получите сложности с реализацией и интеграцией всего этого в рельсы.

Еще есть вариация на тему решения N3 - внешний сервис для поиска: Sphinx, Solr, etc...

Скорее всего либо в исходниках, либо в БД кириллица не в юникоде. Руби ждет юникод, вместо этого получает невалидные последовательности байт и сыпится. А вообще смотрите в логах рельс какая ошибка конкретно возникает, иначе трудно гадать.

Непонятно, что вас смущает в варианте с Redis? Создаете контроллер, который принимает токен+координаты, проводит авторизацию и сохраняет данные в Redis.

Потом создаете контроллер который читает координаты из Redis по просьбе от карт с маркерами и выдает все новые маркеры за запрошенный интервал времени.

module My::Localized
  def self.params_localized
  end
end

и потом include My::Localized

Либо

module My::Localized
  def params_localized
  end
end

и потом extend My::Localized

Либо Concerns

PS:
Еще немного не по теме, ваш код со сменой локалей можно сделать более удобным

def with_locale(locale)
  old_locale = I18n.locale
  I18n.locale = locale
  begin
    yield
  ensure
    I18n.locale = old_locale
  end
end

Использование:

with_locale :ru do
  # ...
end

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

1) Сбрасывать кэш по истечении определенного интервала времени. Например каждый час.
2) Сбрасывать кэш по событию. Например функция по созданию транзакций сбрасывает кэш
3) Сбрасывать кэш по дате обновления кэшируемого объекта. Это когда хранятся время создания кэшированных данных и при обращении к кэшу сравнивается со временем модификации объекта, если оно позже то кэш обновляется.

Как уже вам посоветовали - ознакомьтесь с системой кэширования. В 4 рельсах она из коробки и достаточно продвинутая.

Один из вариантов который я видел - cоздать классы Dashboard::Post и Admin::Post отнаследованные от Post. Сам такое не использовал, возможно есть какие-то слабости у этого решения, раз оно не сильно распространено

Я решал подобную проблему с помощью явного указания нэймспэйса form_for [:admin, @post]

guides.rubyonrails.org

Проблема в том что вы не создаете много объектов Photo каждый с одной картинкой (как вы описали в вашей модели), а создаете один Photo и пытаетесь воткнуть в него несколько файлов картинок

Чтобы все работало так как вы хотите вам нужно
1) В форме иметь просто одно поле с картинками, не забудьте его разрешить для strong parameters

= form_for [:admin, @post], html: { multipart: true } do |f|
    = f.file_field :images, multiple: true

2) В методе контроллера перебрать массив params[:images] и для каждого изображения создать свой объект Photo и привязать его к родительскому Post

params[:images].each do |image|
  @post.photos.build(image: image)
end

Фактически вы создаете 2 отдельных приложения. Оба приложения могут быть написаны на одном и том же языке, если нравится/знаете PHP - пишите все на нем. Для выполнения длительных ресурсоемких задач используйте очереди . В любом случае одновременно использовать разные стеки технологий (PHP и .NET) без веских на то причин не рационально, лучше работать в одном стеке.