brettcvz

Let us know if there are other backend libraries or plugins you'd like to see! And of course, pull requests are encouraged on the libraries

Ha I loved bbcat! 21st century tomagachi. That was another one of the really polished designs that stood out - couldn't remember the name

Definitely- we're revamping it right now, look for another lessons learned blog post soon

I love that we have to clarify this on days like today

Seems like a perfect use for filepicker.io

It's self-promoting, but actually it'd be really nice to be able to open files from dropbox/github and save the pdf's when their done. Then I could actually get work done on my chromebook

I posted this a month ago but it never reached the front page. tagx emailed me about it asking if he could post it and I said it was fine. More distribution is better, right?

We noticed that a lot of folks using Filepicker wanted features that Aviary had, and visa-versa, so as we move forward we'll be working together to make it even easier to integrate both APIs together. This is just the beginning

Do it! That would be awesome!

Looking at the source, looks like he piped it through http://secret-wildwood-1014.herokuapp.com/, which looks like it does basic image to ascii conversions when you give it a url. Not sure if he spun that up, but it's cool in that now the app can be made all in js

We're cranking out even more, let us know what you want to see next

Sorry, I agree probably not the best-written paragraph.

Essentially:

* There are distinct focus-areas on the business side, just as there are on the coding side

* Identifying the differences helps us figure out what to do, when, and how

It could be better, agreed, but I find the format much more conducive to this type of long-form post than Facebook.

Yeah... my bad. Definitely thought he was going to cut that out

Perhaps far down the line, for now it was just a quick hack exploring Filepicker.io and Handsontable

Yeah I didn't want to say "Excel" because it's no where near excel level. But it's still cool!

Major props to my friend David for making this. It's a mashup of Handsontable (https://github.com/warpech/jquery-handsontable) and Filepicker.io (https://www.filepicker.io/)

Huh - well my apologies for making an assumption. I suppose it depends on the role/size of company

Sounds like you work for a BigCorp

Neat idea - we were looking at doing http://www.usertesting.com/ for helping out with this

The point is, it's not just engineering resources that are valuable!

We have full native mobile SDKs as well for iOS and Android. Turk and Gdrive conversion are neat ideas - thanks!

Yup - drag-drop disappears on IE but the Cloud upload still works

Wow! Thank you - let us know if there is anything more we can do.

With one line of HTML, you can pull a photo from dropbox, convert and resize it, and dump it into your S3.

This. is. awesome. Super cool

HEAD requests?

We do read/write, re. lock would you want to prevent all reads? Do a 503 or just hang the connection until the lock is undone?

Can you elaborate on the security/permission issues? It's something we spend a lot of time thinking about, would love to learn more about your concerns and how we can address them.

I think there are two use cases for URLs as pointers, transient and persistent. In the transient case, you use the URL as a temporary representation, pass it around to the relevant hops, and then fetch it wherever the final resting place may be. In the persistent case (say you're building a web app where users upload content and you want a permanent link), there needs to be somewhere in the line that a service "guarantees" that the link will remain alive and true so that the resource it points to sticks around. So in our case, what we do is if the developer asks for a persistent link, we will take a snapshot of the content and persist it encrypted on our CDN for them, making sure the link stays alive

The central issue here is trust. If you trust the provider of the url to maintain the link, ensure that it stays alive and pointed to what you expect, then it's fine.

In the C caching pointers case, the issue is that the system makes no guarantees about the "live"-ness of any prior pointers, whereas on the web this is entirely possible and encouraged (See oft-cited post about "Cool URIs don't change)

Yes - my bad. To be fair, we support both, but PUT is the proper verb