Генератор миниатюрок из Nginx-а

Я понимаю почему, но мне кажется это нелогичным. Ответ Not Modified этот модуль к примеру не фильтрует.
И как отловить 404? Я использую вот такой, не самый элегантный способ:

location ... {
    ...
    if (!-f $request_filename) {
        rewrite ^.*$ /notfound last;
    }
    image_filter resize $w $h;
    ...
}

location = /notfound {
    return 404;
}


Генератор миниатюрок из Nginx-а

Кстати, сейчас при отсутствии файла image_filter 404 ответ превращает в 415, кажется несколько нелогичным

Генератор миниатюрок из Nginx-а

Можно и так.
Просто у меня несколько location-ов в таком случае /path/to/images/ придётся указывать в каждом.

Генератор миниатюрок из Nginx-а

location-ов может быть больше одного, тогда придётся дублировать (один для image_filter resize, второй для crop, например). Кроме того, с $1 $2 были проблемы в location, поэтому я и вынес определение размеров наружу

Генератор миниатюрок из Nginx-а

Сервер приложений заддосить всё же проще. А тут нужен нетривиальный сценарий атаки + плюс довольно большое количество запросов.

Генератор миниатюрок из Nginx-а

Вариант с проксированием своего сервера node.js тоже рассматривался, но решили, что возможностей ngx_http_image_filter_module нам хватит, а если не хватит, то можно модуль дописать.

На самом деле большие возможности ImageMagick тут просто не нужны, нужен просто ресайз картинок, иногда ресайз с кропом, это модуль умеет.

Генератор миниатюрок из Nginx-а

Если будешь использовать proxy_store то, не будут

Генератор миниатюрок из Nginx-а

Можно сделать через proxy_store, можно поставить больше таймаут, это уже дело вкуса.
А можно радоваться тому, что неиспользуемые миниатюрки сами уничтожаться через сутки.
Всё зависит от того, чего мы хотим добиться

Django и часовые пояса

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

Django и часовые пояса

Если javascript отключен, то времена слетают, на это, конечно, можно забить.
Остаются вьюхи и email-ы.

А вы тереяете интерес к проекту после полугода работы над ним, после его запуска?

Интересность же может быть не только в идее. Может быть интересный новый сервис на старый проект, или технически интересная задача: новый компонент, хитрая оптимизация, прикручивание клёвой новой технологии для чего-либо из этого.

Django и часовые пояса

settings.TIME_ZONE по часовому поясу сервера, впрочем, это не так важно. В базе (PostgreSql) они хранятся в типе timestamp with timezone, т.е. UTC + часовой пояс, и база сама его переводит в текущий (для базы) пояс при выдаче

Django и часовые пояса

Тоже вариант. Пара недостатков:
— каждый раз передавать request не особо красиво
— request-а может просто не быть, если мы, например, выполняем что-то по крону
— если понадобиться работать во вьюхе, то придётся преобразовывать время вручную, то же с передачей в форму
— твой фильтр зависит от приложения, поэтому придётся его переписывать если ты, к примеру, станешь использовать другой профиль, захочешь определять время по ip или выбраному городу

Я-то хотел универсальный вариант, да и просто мне нравится немного магии :)

Django vs Rails: дилемма начинающего web-разработчика

Есть несколько вещей, которые ещё стоит учесть:
— у Django чертовски хорошая документация
— Ruby более гибкий, на мой взгляд, язык, чем python. Те же блоки кода в качестве аргументов — отличная вещь когда научишься ими пользоваться.
— Django состоит из отдельных (довольно толковых) компонентов связываемых удобным питоновым кодом
— Rails связывает компоненты скрытой магией, что может и само по себе сбивать с толку и затруднять возможность делать что-то нестандартное

Ну и в конце концов, выбери проект, который будешь делать, от него и пляши — выбирай, что удобнее.