Можно сделать через proxy_store, можно поставить больше таймаут, это уже дело вкуса.
А можно радоваться тому, что неиспользуемые миниатюрки сами уничтожаться через сутки.
Всё зависит от того, чего мы хотим добиться
Всё-таки на сервере частенько нужно знать часовой пояс текущего посетителя, а Javascript-ом можно заполнять значение по-умолчанию в профиле или писать в куку для незарегистрированных
Интересность же может быть не только в идее. Может быть интересный новый сервис на старый проект, или технически интересная задача: новый компонент, хитрая оптимизация, прикручивание клёвой новой технологии для чего-либо из этого.
settings.TIME_ZONE по часовому поясу сервера, впрочем, это не так важно. В базе (PostgreSql) они хранятся в типе timestamp with timezone, т.е. UTC + часовой пояс, и база сама его переводит в текущий (для базы) пояс при выдаче
Тоже вариант. Пара недостатков:
— каждый раз передавать request не особо красиво
— request-а может просто не быть, если мы, например, выполняем что-то по крону
— если понадобиться работать во вьюхе, то придётся преобразовывать время вручную, то же с передачей в форму
— твой фильтр зависит от приложения, поэтому придётся его переписывать если ты, к примеру, станешь использовать другой профиль, захочешь определять время по ip или выбраному городу
Я-то хотел универсальный вариант, да и просто мне нравится немного магии :)
Есть несколько вещей, которые ещё стоит учесть:
— у Django чертовски хорошая документация
— Ruby более гибкий, на мой взгляд, язык, чем python. Те же блоки кода в качестве аргументов — отличная вещь когда научишься ими пользоваться.
— Django состоит из отдельных (довольно толковых) компонентов связываемых удобным питоновым кодом
— Rails связывает компоненты скрытой магией, что может и само по себе сбивать с толку и затруднять возможность делать что-то нестандартное
Ну и в конце концов, выбери проект, который будешь делать, от него и пляши — выбирай, что удобнее.
А можно радоваться тому, что неиспользуемые миниатюрки сами уничтожаться через сутки.
Всё зависит от того, чего мы хотим добиться
Остаются вьюхи и email-ы.
— каждый раз передавать request не особо красиво
— request-а может просто не быть, если мы, например, выполняем что-то по крону
— если понадобиться работать во вьюхе, то придётся преобразовывать время вручную, то же с передачей в форму
— твой фильтр зависит от приложения, поэтому придётся его переписывать если ты, к примеру, станешь использовать другой профиль, захочешь определять время по ip или выбраному городу
Я-то хотел универсальный вариант, да и просто мне нравится немного магии :)
— у Django чертовски хорошая документация
— Ruby более гибкий, на мой взгляд, язык, чем python. Те же блоки кода в качестве аргументов — отличная вещь когда научишься ими пользоваться.
— Django состоит из отдельных (довольно толковых) компонентов связываемых удобным питоновым кодом
— Rails связывает компоненты скрытой магией, что может и само по себе сбивать с толку и затруднять возможность делать что-то нестандартное
Ну и в конце концов, выбери проект, который будешь делать, от него и пляши — выбирай, что удобнее.