ZaneClaes

I'm sorry, I think I misspoke. What I meant is: you're right. What we should have done, though, was link to a blog post for you to read, rather than the dev portal itself. It just wasn't realistic to build a mobile enabled dev portal, so we should have posted something mobile friendly instead.

Thanks!

Sure, we both cover social login and sharing. However, Streamified supports a whole bunch of news features, and a lot more social endpoints, which Singly doesn't begin to touch on.

Fair points, thanks. I'd have to discuss with the team if this is an option, ultimately. I can promise that if we ever did go away, I would certainly aim to opensource it (why not?) But as a company w/ investors, it's not a decision I can make myself right now ;)

Sorry, but this is a developer portal -- not a news source or blog -- and really isn't meant to be used on a mobile device. I acknowledge that this may not be the answer you're looking for, but we didn't design the site for mobile because what it needs to do isn't really appropriate (or feasible) on mobile -- eg, the API console.

I'm not following... how is this broken? The headers return a 302 code, pointing to the proper HTTPS site. If you click the link you pasted, your browser should properly redirect (tested in FF, Chrome).

Thanks!

The stack which is required for the Streamified API is really quite large, too. Between node, mongo, elasticsearch, and a few other pieces of software... plus a few dozen node modules and even some custom linux configuration, it's really not feasible to expect devs to install it on their own machines ;)

RSS is full of embedded HTML. It's practically impossible to make a good news reader without doing some heavy manipulation on it and trying to extract/modify ugly elements. We have a full blog post on the topic here: http://blog.streamified.com/post/45846467833/the-future-of-s...

There's a discussion below this one why it makes sense to have a single API for this, instead of open-sourcing the code. The benefits are numerous (we're hooking into many paid APIs and covering the costs, for example).

Hey mamcx,

Would you mind shooting me an email to Zane@Streamified.com so we can discuss?

And yes, you could easily manage many users' RSS feeds :)

Nice! That's where we started, then got carried away... very, very carried away ;) Hope you find it useful; we'd love to hear from you!

Thanks!

We should cover all major news sources. We have at least 250,000 different sources we're scraping, plus we also "crowdsource" news discovery. That is: organically (stream-discovered) content gets indexed as well.

Hope to hear from you! Zane@Streamified.com

Streamified, Inc.: Zane Claes and David Lee You're welcome to contact us directly @ zane@streamified.com and david@streamified.com

Thanks! Be sure to drop us a line if you want to dig a bit deeper into integration.

For social networks, we're proxying the APIs (essentially). For articles and news, we both aggregate organically discovered articles from streams, as well as scrape 250k+ RSS feeds and other news sources. So, articles are stored local to the server (which is why we have such a large collection of them), but sensitive social information is a pass-thru to the social network.

However, in both cases, we're doing lots of analysis on top of the data per our "normalization" philosophy.

Per our "whitelabeling" philosophy, Streamified actually uses your own app IDs (not ours). From Twitter's perspective, we're just acting as a middleman to help you use their API better; any blockage, then, would be a result of your implementation of their API (throttling, etc).

Our courtesy limit is 1k requests per day to the API. Beyond that, we're happy to discuss what makes sense, we obviously just need to prevent abuse.

Yes, our searching capacities include everything from categories to sentiment to tags to media... you name it. ElasticSearch powers our backend, which is powered by Lucene, so anything in an article can be searched. Check out the articles/search endpoint: https://streamified.me/developer/#endpoint=GET%20articles%2F...

Thanks! I'm one of the devs on the project; you can contact me directly at Zane@Streamified.com.

To your questions: one of the major benefits of the service is the "crowdsourced" aspect of it. That is: the more people using the same API, the more news articles get found and indexed. Furthermore, the API actually hooks into other paid APIs, so it actually wouldn't work very well for you to run it on your own servers unless you wanted to also pay for them. For all these reasons and more, we think that a hosted API is the best solution.

The name sounds like a bad euphemism @.@

zomg!

I have a propensity to think overly-meta. I'd delve deep into connecting disparate parts of the internet, fusing services together into an experience which eliminated a lot of the "service here, service there" paradigm we currently observe. This is really an extension of what I'm already working on in the social+news realm @ Streamified.com, but ultimately would be much larger in scope, incorporating learning algorithms and neural networks to ultimately transform the internet into a sort of persistant secondary-hive-mind accessible from anywhere.

Thanks! I'd been waiting on this for 1-2 years, figured it was about time ;)

When you get to the end, it explains that it uses net WPM (NOT Gross WPM), which is error-adjusted to create an "effective" WPM.

Actually, the best way to improve is to just keep going, without correcting -- but to keep typing the rest of the word correctly. Eg, if you know you typed the 2nd character incorrectly, just make sure you get the 3rd right.

True. But you're only cheating yourself ;)

Hahaha :) Re: copying... I'm not sure that there's really a necessary distinction between copying input and simply being able to type fast. In this scenario, yes, you're simply copying input; for that reason I added a 800 ms delay to allow the brain to process the word before the variable timer is enabled, so ultimately what's being tested is your ability to write what is in your brain already.

That said, I do acknowledge that WPM is not necessarily the best gauge of efficiency. I'm a programmer, and I'm not sure exactly how WPM relates to my work (I'd be curious to see a study) since much of what I type is "nonsense" words to begin with, and WPM is largely a function of your ability to habitually reproduce the same character sets (aka, common words in your given language).

The way it's coded, there are 2 conditions that move it forward: either pressing space, or the timer expiring. Pressing the space thus is not an error, but rather the condition that moves the text forward. Also, as I mentioned below, the timer gets faster as you get more words correct.

The original study used only a timer, and had the same frustration which you speak of here.

Updated the FF about 30min ago; try again now :)

The text moves forward a little faster than you are able to type; this is the principle of the OK Plateau -- you need to be forced to "try" to type faster. However, it is certainly uncomfortable! But, no pain, no gain.

Animations? No animations... perhaps it's slow javascript?

Each non-matching character counts as an error; but you can still recover. Eg, if you type "heloo" instead of "hello", it is only 1 error.

Yep, and not only does it automatically move -- it speeds up as it moves. Eg, as you get more words correct, the speed and which it moves forward increases.