Хостинг картинок за полчаса

[denisemenov]

С инстаграммом не захотел коннектиться — iamshare.herokuapp.com/view/jngvqk/
В остальном очень удобный и функциональный сервис.
А есть какие-то аналогичные хостинги картинок, которые позволяют коннектиться к соцсетям и облачным хранилищам?

[homm]

Да, инстаграм с утра отдает плохие ответы даже собственному сайту :(

[homm]

Заработал.

[WaveCut]

Умер снова. Скорбим.

[MechanisM]

Uploadcare замечательный сервис которым можно пользоваться. Давно про него знаю уже и активно слежу.
А на вопрос про аналогичные сервисы — есть подобные загрузчики как Uploadcare, позволяющие коннектиться к сторонним сервисам как пример: www.filepicker.io/ для которого тоже есть различные библиотеки, в том числе и для django(django-filepicker).

[almirus]

Анимированные gif не заливаются?
Error
Can’t load image

[homm]

Вообще, заливаются, но после применения операций ресайза или кропа, анимация пропадет. Более того, анимации не будет даже по ссылке Full link, потому что там применяется операция от ручного кропа (/-/crop/500x374/0,0/ в адресе). Наверное надо сделать так, чтобы когда пользователь ничего не «откусил» в предварительном просмотре, отдавалась оригинальная картинка.

Что касается «Error Can’t load image», то тут что-то непонятное. Пришел один отчет об ошибке, скорее всего это ваша картинка, попробуем разобраться.

[nomoretears]

cl.ly/image/3h3E0D390Z2t — очень долго (больше минуты) обрабатывается большая картинка (4275х2404), чтобы показать ее превью. За это время сто раз скачать ее можно (1.8 мб). Имхо, нужно отказаться от порочной практике загрузки серверных мощностей на обработку для превью, и просто выгружать ее (или, что еще лучше, для небольших по разрешению фоток обрабатывать, а для больших — выкачивать).

А так вот — iamshare.herokuapp.com/view/xtfhob/ Но при клике на нее выходит «400: Bad Request At least one of dimensions should be less than 634».

[nomoretears]

К слову, простое и изящное решение для лоадера, подсмотренное у eviterra.com — писать, почему долго. Например, что-то про то, что «изображение ресайзится» или типа того.

[homm]

Рома! Есть хорошая новость и плохая. Хорошая: мы наконец-то пофиксили это в версии виджета 0.8.1.2 и на iamshare я обновил виджет. Плохая: я не учел, что на Хероку sqlite хранит данные в оперативной памяти и при обновлении вообще все загруженные сегодня картинки потерлись. Но я прочесал всю историю браузера, нашел твою оригинальную картинку и загрузил её снова: iamshare.herokuapp.com/view/exldtk/ Как видишь, ссылка Full link работает!

[Athari]

А теперь честно скажите, сколько времени вы потратили. А то это похоже на традиционное программистское «Да я за пять минут!» * ** *** **** *****

* Если бы у меня сразу была запущена среда разработки
** Если бы я не ошибся в вводе ни единого символа
*** Если бы всё скачиваемое сразу было на компьютере
**** Если бы я не занимался отладкой и тестированием
***** Если бы я не думал, что писать, а сразу знал каждый символ

[mrjj]

* если бы это не было прототипом вида hello world.
Разница между рабочим проектом массового использования и прототипом это несколько порядков.

[mrjj]

У меня волосы дыбом.

На живом проекте никогда не привязывайте типы полей к способу хранения файловой информации. Они должны переключаться по щелчку пальца строчкой конфига или галочкой в меню без изменения кода модели.

Если вам предлагают решение, где сделано так, то это либо глупость, либо сознательная диверсия, чтобы на живом проекте storage backend нельзя было безболезненно сменить за счет высокой связности архитектуры.

Единственное исключение — хранилища, i/o которых работает с значительной задержкой либо с просто большими по объему i/o транзакциями или их последовательностями (гиг передать). Для них должна быть своя логика и свой пул состояний, отличные от стандартной схемы Django.

Такую ситуацию, доставшуюся в наследство, можно развязать синхронизируя модель, зависящую от стороннего поставщика с моделью, набранной из стандартных классов. Даже такому уродцу будешь целовать ноги, если сторонняя служба ляжет или будет недоступна.

Генерация превьюх — тяжелая вычислительная операция (с еще одним i/o циклом, кстати), промежуточными состояниями и отказами и ее тоже нужо «отвязывать» чем выше, тем лучше. Там еще может кэш подоткнуться со временем, очереди. Посмотрите, как умные авторы sorl-thumbnail делают. Если решение не похоже на него — выкидывайте.

[homm]

Они должны переключаться по щелчку пальца строчкой конфига или галочкой в меню без изменения кода модели.

Я бы хотел посмотреть, как на живом проекте переключаются файловые хранилища по щелчку пальца без переноса самих файлов и без миграции данных.

Про генерацию превьюх у вас странные рассуждения. Вы уверены, что все правильно поняли? Генерация происходит на сервере uploadcare по параметрам в url. Взгляните еще раз на строчку:

<img align="left" src="{{ image.image.cdn_url }}-/stretch/off/-/resize/260x/">

[mrjj]

>Я бы хотел посмотреть, как на живом проекте переключаются файловые хранилища по щелчку пальца без переноса самих файлов и без миграции данных.
Перенос самих файлов, разумеется, нужен, если до этого они не синхронизировались. Все остальное можно переключать моментально, если хранилище описано в рамках storage API.

>Про генерацию превьюх у вас странные рассуждения. Вы уверены, что все правильно поняли? Генерация происходит на сервере uploadcare по параметрам в url. Взгляните еще раз на строчку:

И выше уже много сложностей и оговорок по поводу того, что они могут, а что нет. Как эта штука себя будет вести если, например, загрузить ленту из 50 картинок с немного измененным масштабом превьюх? Или на больших файлах: фото, сканах, скришотах?

[nikitay]

потрясающий, короткий и дельный guide.
естественно, безопасность и архитектуру можно еще долго дорабатывать, о чём сидетельствуют 100500 комментариев, но, как прототип — конечно же отличная работа.

[mrjj]

Да, для прототипа все просто замечательно и компактно, главное понимать, где он кончится.