One addition I would add would be to actually link to the service or their status page. If you are going to call them out if their service is down, at least give them something in return, i.e. discovery.
Well, we used to successfully dynamically stitch a JPEG onto the front or back or middle of a video to make a VOD have an unskippable ad regardless of target device. We did that back in the Windows Media (.wmv) days, haven't tried it with H.264. But this should be easier.
We use a similar principle to generate dynamic thumbnails. Our VOD hosting customers can call a video URL with a query string specifying time offset and size and we generate a JPEG thumbnail on the fly from the closest keyframe of the H.264 file, storing the thumbnails in an intermediate cache layer. Works great, and beats keeping a bazillion thumbs managed when the source media is changed or deleted.
Generating an ad should be no harder than that. Easier, I'd think, since most of our time is spent seeking to the keyframe of a 2 hour movie.
It's becoming more of an issue now that we are growing.
We have had conversations with the YouTube guys about this and they have asked us to use API's instead of directly scrapping pages.
Quora is currently rate limiting us a ton as well. We again have to directly reach out to them.
Most oEmbed endpoints aren't rate limited because they are generally not resource intensive. They are also meant to be used client side and therefore expect more traffic.
Embedly also does a fair amount of caching that reduces the number of calls that we have to make. This limits us, because we aren't a straight pass through, but helps us handle spikes of traffic.
It would be unusual to have non integer occurrences of words in the text. But given the question didn't specify how to round, both 21 and 22 could be valid answers even with only whole number counts of words. Round down gives 21, while round by half gives 22.
Interesting to see how few of the proposed answers used an HTML parsing library (simplistic matching of potentially unknown document syntaxes is a notoriously brittle approach), and surprised how few counted depth relative to the article tag.
Given embedly's business and the setup discussion, seems like a valid solution should work with any arbitrary HTML page containing an article tag and paragraphs within it, while many of the gist lists either counted P depths by hand (!) or assumed that one particular document.
If the <article> tag or the <div> by it or the <p> tags had had so much as a space before the closing angle bracket (and forget about classes or styles) most of them would have failed. For the most part, only the solutions pulling in an external parsing lib would have still worked. Python's lxml.soupparser comes to mind (or lxml.etree for this task), and was happy to see several similar libs invoked.
Interesting that you had to replace the document with a cleaned up one to get more successful answers.
We all need to give hat tips to the people that inspired us to be greater and try new things. We would not be here right now without Fred. I'll put his name in titles all day long just to adknowledge his contributions.
api.embed.ly will remain free, but it is a community resource. If someone is abusing it we will ask them to move over to Pro as to not effect the other users. We have not had to ask anyone to move over and don't see it happening in the near future.
Have you ever tried to make money on affilate links? In all honesty we make next to nothing from affiliating Amazon links. It's not even close to a viable business, we only do it because we don't like leaving money on the table.
I make about £3k per month off a site that I set up for my own amusement and time-wasting. 6 million page views per month, I'm only signed up to 4 affiliate schemes. Amazon pay the worst of all of them, that's true.
It's a side project, but for something that I only do out of love £3k per month is quite tidy.
Edit: I guess what I'm saying is that you could take skimlinks and knock them for six, and people would have a real benefit and reason to use embedly whereas skimlinks milk far too much and it's not even got a user benefit.
PS: Are you hiring remote workers? I know how to make this work ;)
Interesting, I guess we are doing it wrong. I see what you are saying about skimlinks, we have received this advice in the past. It's just not something we are looking into now.
We might be up for a commission based remote worker. :)
Hit me on email and I'll tell you more detail: david @ buro9.com
There are a couple of specifics to get right, mostly it's about giving a reason for webmasters to use it and what is massively under-estimated is that a lot of webmasters hang out places just like this and are asking for solutions to both embedding stuff and earning money.
We were profitable and growing.
Good comment though.