Уменьшение изображений на стадии разработки
-
14 мая 2009 19:40
-
Комментарии
В этом посте, я хочу рассказать, о том как я избавился от одного побочного эффекта связанного с использованием модуля ngx_http_image_filter_module для nginx. Он заключался в том что во время разработки я не использую nginx+passenger и как следствие уменьшенные копии изображений не создаются.
Чтобы решить эту проблему, я завёл специальный контроллер, который будет выполнять роль модуля ngx_http_image_filter_module во время разработки и уменьшать изображения вместо него. Так выглядит созданный мной контроллер development_controller.rb:
require "RMagick"
class DevelopmentController < ApplicationController
def resize
image_file = File.join(RAILS_ROOT,
"public/attachment/file/#{params[:id]}/#{params[:file_name]}")
image = Magick::Image.read(image_file).first
image.resize_to_fit!(530, 480) if image.columns > 530
send_data(image.to_blob, :disposition => 'inline')
end
endЧтобы все запросы на уменьшенные копии изображений передавались ему, я добавил следующее правило в routes.rb
if RAILS_ENV == 'development'
map.connect "/attachment/file/:id/medium/:file_name",
:controller => 'development', :action => 'resize',
:file_name => /.*\.(jpg|jpeg|gif|png)/i
endЭто всё, что нужно сделать, для того чтобы получить во время разработки функциональность аналогичную той, что предоставляет модуль ngx_http_image_filter_module.
в формате RSS. Присоединяйся!
Никак не пойму, зачем все эти замуты с Nginx, если Paperclip умеет и аплоадить, и ресайзить изображения с какой угодно хитростью.
Опять же динамический ресайз будет работать только при небольших нагрузках. А send_data это еще затратнее, чем динамический ресайз. Тут вдвойне проигрыш.
Прелагаю не изобретать велосипед, а заюзать готовые решения. Rmagick это не готовое решение. Есть еще готовее ) И гораздо функциональнее, и временем проверенные. Вобщем Paperclip наше всё.
btw,
Rails.env.development? будет смотреться круче.
Вопрос понял, попробую объяснить свою точку зрения:
Надеюсь вы не будете спорить с тем что некоторые задачи имеют больше одного решения? Это как-раз одно из альтернативных решений. Изобретать велосипед - это значит создавать что-то когда уже есть абсолютно такое же решение. Если бы я стал писать свой аналог Paperclip, это был бы велосипед, но я не пишу аналог, я показываю как решить ту же проблему что и Paperclip, но другим путём. Чувствуете разницу?
Так же похоже вы невнимательно меня прочитали, я не предлагаю использовать описанный в посте подход в продакшене, потому как прекрасно понимаю что ресайз через Rails будет иметь немало недостатков. Поэтому проигрыша тут никакого нет.
Насчёт динамического ресайза да и в общее динамической обработки изображений. Да, действительно нагрузка на сервер возрастёт, но закон Мура всё ещё работает, а это означает что многие вещи которые когда-то в прошлом упирались в производительность компьютеров, сейчас вполне себе успешно работают и не кажутся чем-то необычным.
Так же учитывайте что кроме минусов у него есть и плюсы, например дизайнерам потребуются изображения размером 80x80, а есть только 50x50 или потребуется обработать исходные изображения, например добавить водяные знаки к уже имеющимся изображениям или даже убрать старые и добавить новые и т.п. Понятно что Paperclip здесь никак не поможет т.к. своё дело он уже сделал при загрузке изображения. Поэтому при подходе со статической генерацией изображений потребуется обработать всю базу изображений и добавить в неё новые изображений, тогда как при динамическом подходе потребуется добавить лишь одно правило которое делает нужные преобразования. Налицо большая гибкость в работе с изображениями.
Как обычно, я рекомендую, не придерживаться слепо одной только точки зрения (читай "Paperclip наше всё"), а руководствоваться здравым смыслом при решений задачи. Где-то действительно статический подход к обработки изображений будет лучше, а где-то динамический (или даже их совместное использование).