choonkeat

but upgrade guide says its ok "talk things through" on the issues page, so I posted my solution there

https://github.com/avh4/elm-upgrade/issues/44

sorry didn't see this reply. i'll copy-paste my reply http://blog.choonkeat.com/weblog/2015/10/file-uploads-2015.h... for posterity ;-)

If you're using an image server, you still need to do...

yes and we should move towards solving issues in the image server, not yet another client gem

File validations (most notably preventing big files)

big file upload can equally be prevented on image server as on a rails server, settings should be in the webserver fronting it.

validations are "easy" since you're only validating json attributes, but i guess as u mentioned, shrine has this benefit too.

Storing the file to image server (this still needs a background job)

even better than background job: we always direct upload from browser/client (regardless of whether we are using s3 or not).

Model attachment logic (all of the assignment/callback logic)

a client lib can do this for your rails app. and it isn't much https://github.com/choonkeat/a...

One problem that I always had with on-the-fly processing is, if you have a page with a lot of photos, and you want to change the URL so that they're processed differently, how will that page look when a first person visits it? I think it will be horrible, the user will have to wait for a really long time to actually see the images, which is not nice user experience.

we can still "pregenerate" after the author uploads his images, the browser just have to make the requests (not necessarily visible) and the image servers can cache those generated images for a long long time. then when the "first other person" view the page, those images are as fast as anything.

storing the generated image or not is still an image server's decision. my own implementation chose not to store because i find those generated files more trouble to carry around.

again, these are things for different image servers to iron out and one-up each other with.

Also, the "image server" strategy can be used only for images, so if you want to upload documents, audio or video, you'll need to use something else. What's nice about uploading gems is that they provide a general solution.

actually, there's nothing in an image server that makes it inherently image only. i'd say file servers provide as general a solution as those uploading gems

for example, attache server handles pdf uploads well and even renders the thumbnail when requested via <img src="">. the same applies for any other file types - the goal is actually to render thumbnails for everything, as per how your desktop renders the same files are thumbnails.

again, these are things for different image servers to one-up each other with.

While the Ruby community wasn’t looking, the rest of the world has moved on to having standalone servers to manage & process their file uploads.

Latest example: https://medium.com/medium-eng/the-stack-that-helped-medium-d...

Here's a take down of all approaches. https://www.slideshare.net/choonkeat/file-upload-2015

TLDR: forget shrine too, use an image server

having an image server with apis solves 80% of the problem.

having a client counterpart lib to ease you in solves the other 80% https://github.com/choonkeat/attache_rails

being able to host it yourself solves the last 20% https://github.com/choonkeat/attache

oh wow. with their trailer website lacking it, appletv wishlist feature as toothless, i really didn't think they'd bother with it in an app. thanks

can this finally be the app that let me surf trailers, click like and send me push notification when the movie is out ??

(or available on itunes or netflix)

but why?

great idea! but is it necessary ux to burden the human user to manually trigger unlock? form onfocus or page onload should be less intrusive and still serve the purpose

everyone-pays model works very well for everyone. since 2005. http://rssforward.com/

"Your phone wasn't able to record all of the movement. Please try again"

can't get past 2 walls. iphone 4s

timeline: like! i wish more news sites presents history in a straightforward manner colors: not so much; not meaning & some combi are hard to read; favicon/logo/color-scheme-based-on-logo will be more useful http: if the form method is "GET", then I can easily share or bookmark for updates later text: some body text will be nice

A public service announcement: There’s still a lot of pretty good programmers who don’t write tests… and programmers who write tests are not necessarily any good - http://blog.choonkeat.com/weblog/2012/06/tdd-for-those-who-d...

could start a bounty like http://groundswell.io/bounty-for/6-a-self-hosted-gmail