resources :company do
member do
# /company/50/:photos
resources :photos
end
collection do
get :category, to: "category#index"
end
end
Полноценный рестфулл - это ресурсы. А в ресурсы можно вкладывать мембер (то, что вешается на конкретный ресурс) и коллекецию (то, что на весь ресурс). Что имеется ввиду под категориям, не совсем понял, поэтому пример абстрактный.
Придётся отмечать себя любимую как решение! =)
Оказывается есть такое свойство как -webkit-overflow-scrolling: touch - оно то и даёт плавность. К моему удивлению нашла Я это в комментариях к статье которую отложила в долгий ящик для прочтения на выходных. Поддержка iOS 5.0 +, думаю и большего не нужно для счастья.
Все зависит от того, что вам с этими данными надо будет делать.
Если просто хранить, то добро пожаловать в PostgreSQL и тип колонки json (хоть черта лысого туда пишите).
Если нужно искать, то я бы остался с PostgreSQL и навесил сверху ElasticSearch и в нем бы уже искал.
А эти все EAV хороши только на картинке. Когда начинаются сложные запросы - "поплыли".
Присоединюсь к коллегам.
Проще всего следовать принципу "одна задача-один исполнитель" и создавать подзадачи для группировки параллельных обработок если нужен контроль по общей задаче и контроль статусов по подзадачам.
Исключение - когда последовательно по задаче должны отработать исполнители в рамках рабочего процесса, тогда подзадачи создавать необязательно, но статусная схема должна отражать рабочий процесс.
Хотя если сильно хочется извращений - технически можно одну группу создать средствами почтового сервера и ей назначать в РМ, однако статусы только кто-то один будет менять в момент очередного обновления.
Потому что читаем секцию "Establishing connection" документации пакета.
В вашем случае соединение будет установлено не в момент вызова createConnection, а в момент выполнения первого запроса, следовательно 370мс это не "чистое" время запроса.
В документации есть пример с принудительным коннектом.