vdv_lg: так если вам нужна статистика на продуктовом сервере, то можно через awk забирать данные из того же log/nginx.access.log. Там есть и даты и ip-адреса. Это на много эффективнее, чем держать данные в базе.
madcore: не пользователь же записывает в базу. Связи только по уникальным айдишникам делаются. Если есть великое желание так извращаться, то создайте скоуп на Album и джойните с Song на name.
Max: на сколько я помню нужно зайти в "Мой компьютер" нажать правую клавишу мыши, выбрать свойства, вкладку "Расширенные". Далее выбрать "Переменные окружения". В появившийся форме найти перменную PATH и дописать через точку с запятой путь к ноде.
des1roer: так можно закрытый репозиторий сделать.
Помимо вашего кода, на сервере будут различные сервисы. Например, я в свой репозиторий добавляю линк на nginx-конфиг приложения. При его изменении нужно nginx рестартовать. Или решите прикрутить поисковой движок аля sphinx. А для него нужно делать переиндексацию при изменении конфигов. Плюс хранятся релизы ранних версий и можно переключаться в случае чего. А развернуть приложение на другом сервере так вообще в 1 команду можно.
В общем то, что вы хотите -- это путь курильщика. Но если хотите, то вперед)
des1roer: Нет) Так не делается. Это плохой способ, но если очень надо, то можно. Хороший способ -- это поставить капистрано. Потому что вы делаете не верстку, а пишете серверный код. Возможно даже используете Composer или что-то еще. Поэтому ваш админ должен вам настроить систему деплоя и вы не будете знать бед. А репозиторий можно держать и на гитхабе или гитлабе и не мучаться.
des1roer: ну вообще, если очень хочется, то можно сделать git init на сервере в той папке, где проект хранится. А потом у себя git clone user@ip_address:/home/user/путь_к_каталогу_с_репозиторием.
Тогда если править локально в репозитории, то при git push все будет улетать в репозиторий на сервере.
des1roer: если вам нужны репозитории именно на вашем сервере, то можно ставить гитлаб, чтобы не мучатся с тонкими настройками, а делать все в веб-интерфейсе. Это по сути локальный gitlab.com.
Юрий Левин: что такое стандартные инструменты для руби? Если возможности рельсы по кешированию, то они безграничны. Ну а так, Redis, Sphinx, индексы в базе, оптимизация базы на чтение или запись, правильное использование rails-методов. Понимаете, никто не сортирует на бэкенде большие массивы, не делает цикличные операции. Во что тогда может упираться производительность приложения? Только в базу, настройки сервера, настройки кэширования, общую инфраструктуру. Я не спорю, что руби из коробки может быть медленный в каких-то операциях. Но если вам нужно ускорить ваш руби-код, то пожалуйста. JRuby, rubinius = быстрый код на Java-машине, либо просто быстрый нативный код.
