- InoReader.com
- InoReader.com/forum
- the RSS Subscription Extension (by Google) (a Chrome / Chromium browser extension) lets you add a subscription to your InoReader
Showing posts with label feed reading. Show all posts
Showing posts with label feed reading. Show all posts
Wednesday, July 3, 2013
InoReader is the best Google Reader replacement I came across
It resembles Google Reader really, really a lot.
Thursday, May 16, 2013
a few remarks Google Reader and its competitors
Google will shut down Google Reader on 2013-07-01.
I like(d) Firefox Sage a lot, but it does not synchronise between my various devices, so I really only consider web-based feed readers.
Competing web-based feed readers:
I like(d) Firefox Sage a lot, but it does not synchronise between my various devices, so I really only consider web-based feed readers.
Competing web-based feed readers:
- InoReader.com – looks best to me (I selected InoReader as my GR replacement); InoReader.com/forum
- feedly.com – at least one organisational level; comes for free w/o any restrictions
- NewsBlur.com – at least one organisational level; looks rather nice as well
- theoldreader – no organisational level at all
- netvibes.com – at least one organisational level; looks really great; free version has noticeable restrictions
www.google.com/reader/about : alternativeto.net/software/google-reader
But none of them is yet as nice as Google Reader:
But none of them is yet as nice as Google Reader:
- you can send articles from the "overview" to a blog (InoReader can do that as well), …
- …
Wednesday, May 15, 2013
Wednesday, March 27, 2013
The demise of Google Reader: Stability as a service
The demise of Google Reader: Stability as a service:
Om Malik’s brief post on the demise of Google Reader raises a good point: If we can’t trust Google to keep successful applications around, why should we bother trying to use their new applications, such as Google Keep?
Given the timing, the name is ironic. I’d definitely like an application similar to Evernote, but with search that actually worked well; I trust Google on search. But why should I use Keep if the chances are that Google is going to drop it a year or two from now?
In the larger scheme of things, Keep is small potatoes. Google is injuring themselves in ways that are potentially much more serious than the success or failure of one app. Google is working on the most ambitious re-envisioning of computing since the beginning of the PC era: moving absolutely everything to the cloud. Minimal local storage; local disk drives, whether solid state or rust-based, are the problem, not the solution. Projects like Google Fiber show that they’re interested in seeing that people have enough bandwidth so that they can get at their cloud storage fast enough so that they don’t notice that it isn’t local.
It’s a breath-taking vision, on many levels: I should be able to have access to all of my work, regardless of the device I’m using or where it’s located. A mobile phone shouldn’t be any different from a desktop. I may not want to write software on a mobile phone (I can’t imagine coding on those tiny touch keyboards), but I should be able to if I want to. And I should definitely be able to take a laptop into the hills and work transparently over a 4G network.
Furthermore, why should I worry about local storage? The most common cause for throwing a computer on the bone pile is disk drive failure. Granted, I keep machines around for a long time, so by the time the disk drive fails, it’s more than time for an upgrade. But local disks require backups; backups are a pain; and it’s all too common for something to go wrong when you’re doing a restore. I’d prefer to leave backups to a professional in a data center. For that matter, there are many things I’d rather leave to a data center ops group: malware detection, authentication, software updates, you name it. Most of the things that make computing a pain disappear when you move them to the cloud.
So I’ve written two paragraphs about what’s wonderful about Google’s vision. Here’s what sucks. How can I contemplate moving everything to the cloud, especially Google’s cloud, if services are going to flicker in and out of existence at the whim of Google’s management? That’s a non-starter. Google has scrapped services in the past, and though I’ve been sympathetic with the people who complained about the cancellation, they’ve been services that haven’t reached critical mass. You can’t say that about Google Reader. And if they’re willing to scrap Google Reader, why not Google Docs? I bet more people use Reader than Docs. What if they kill the Prediction API, and you rely on that? There are alternatives to Reader, there may be alternatives to Docs (though most of the ones I knew have died on the vine), but I don’t know of anything remotely like the Prediction API. I could go on with “what ifs” forever (Authentication API? Web Optimizer?), but you get the point.
If Google is serious about providing a platform that lets us move all of our computing to the cloud, they need to provide a stable platform. So far, the tools are great, but Google gets a #fail for stability. Google understands the Internet far better than its competitors, but they’re demonstrating that they don’t understand their users’ needs.
Om Malik’s brief post on the demise of Google Reader raises a good point: If we can’t trust Google to keep successful applications around, why should we bother trying to use their new applications, such as Google Keep?
Given the timing, the name is ironic. I’d definitely like an application similar to Evernote, but with search that actually worked well; I trust Google on search. But why should I use Keep if the chances are that Google is going to drop it a year or two from now?
In the larger scheme of things, Keep is small potatoes. Google is injuring themselves in ways that are potentially much more serious than the success or failure of one app. Google is working on the most ambitious re-envisioning of computing since the beginning of the PC era: moving absolutely everything to the cloud. Minimal local storage; local disk drives, whether solid state or rust-based, are the problem, not the solution. Projects like Google Fiber show that they’re interested in seeing that people have enough bandwidth so that they can get at their cloud storage fast enough so that they don’t notice that it isn’t local.
It’s a breath-taking vision, on many levels: I should be able to have access to all of my work, regardless of the device I’m using or where it’s located. A mobile phone shouldn’t be any different from a desktop. I may not want to write software on a mobile phone (I can’t imagine coding on those tiny touch keyboards), but I should be able to if I want to. And I should definitely be able to take a laptop into the hills and work transparently over a 4G network.
Furthermore, why should I worry about local storage? The most common cause for throwing a computer on the bone pile is disk drive failure. Granted, I keep machines around for a long time, so by the time the disk drive fails, it’s more than time for an upgrade. But local disks require backups; backups are a pain; and it’s all too common for something to go wrong when you’re doing a restore. I’d prefer to leave backups to a professional in a data center. For that matter, there are many things I’d rather leave to a data center ops group: malware detection, authentication, software updates, you name it. Most of the things that make computing a pain disappear when you move them to the cloud.
So I’ve written two paragraphs about what’s wonderful about Google’s vision. Here’s what sucks. How can I contemplate moving everything to the cloud, especially Google’s cloud, if services are going to flicker in and out of existence at the whim of Google’s management? That’s a non-starter. Google has scrapped services in the past, and though I’ve been sympathetic with the people who complained about the cancellation, they’ve been services that haven’t reached critical mass. You can’t say that about Google Reader. And if they’re willing to scrap Google Reader, why not Google Docs? I bet more people use Reader than Docs. What if they kill the Prediction API, and you rely on that? There are alternatives to Reader, there may be alternatives to Docs (though most of the ones I knew have died on the vine), but I don’t know of anything remotely like the Prediction API. I could go on with “what ifs” forever (Authentication API? Web Optimizer?), but you get the point.
If Google is serious about providing a platform that lets us move all of our computing to the cloud, they need to provide a stable platform. So far, the tools are great, but Google gets a #fail for stability. Google understands the Internet far better than its competitors, but they’re demonstrating that they don’t understand their users’ needs.
Saturday, March 16, 2013
NewsBlur – a service like Google Reader
NewsBlur
http://www.h-online.com/open/news/item/Google-Reader-to-close-down-1823206.html :
http://www.h-online.com/open/news/item/Google-Reader-to-close-down-1823206.html :
NewsBlur is free for up to 12 feeds and an unlimited Pro version is available from $1 a month. Currently however, the service is experiencing heavy loads and, at the time of writing, was barely usable.
Tuesday, January 24, 2012
syndication feeds for blogs on Blogger.com take CGI parameters
You can find the URL-s of the Atom and the RSS feeds for such a blog in its HTML:
Within the XML of an Atom feed you can find a node like this:
The href attribute looks rather interesting, it uses these CGI parameters:
Actually the href used the somehow internal URL of that blog, but apparently both "public" URL and internal URL seem rather interchangeable – trial and failure "proved" that. Furthermore these CGI parameters also work on the URL of the RSS feed, not just the Atom feed.
/html/head/link[@rel="alternate" and @type="application/atom+xml"]/html/head/link[@rel="alternate" and @type="application/rss+xml"]
Within the XML of an Atom feed you can find a node like this:
/feed/link[@rel="next"]
/feed/link[@rel="next" and type="application/atom+xml"]
Found 1 nodes:
-- NODE --
The href attribute looks rather interesting, it uses these CGI parameters:
- start-index
- max-results
Actually the href used the somehow internal URL of that blog, but apparently both "public" URL and internal URL seem rather interchangeable – trial and failure "proved" that. Furthermore these CGI parameters also work on the URL of the RSS feed, not just the Atom feed.
BTW: Both feed XML-s carry an element openSearch:totalResults, find it like this:
It tells you exactly, what it says, i.e. the number of total results.
So you may very well read blog feed XML-s in small chunks, until you reach their end. I assume, this is what Google Reader does e.g. . It shows you the most recent blog articles (resp. their stubs) initially, and extends the list, when it notices, you are scrolling "beyond the end".
/feed/openSearch:totalResult… for Atom resp. RSS.
/rss/channel/openSearch:totalResult
It tells you exactly, what it says, i.e. the number of total results.
So you may very well read blog feed XML-s in small chunks, until you reach their end. I assume, this is what Google Reader does e.g. . It shows you the most recent blog articles (resp. their stubs) initially, and extends the list, when it notices, you are scrolling "beyond the end".
Friday, January 20, 2012
how can Google Reader go further back in time on a Feedburner feed than the XML shows me?
If you use Google Reader for reading a feed on Google Feedburner, you can go back and back and back and … in time, but if you simply download the feed (as XML), the file is pretty finite and short.
- Q: How do they do that?
- Q: How do I get such a longer feed XML file myself? (I am more interested in this.)
Friday, October 14, 2011
Google Reader OPML export
www.google.com/reader
I was worried, whether I would ever be able to save my feed subscription list from Google Reader.
And yes, I am able to do that.
Settings > Import/Export > Export your subscriptions as an OPML file.
I did hack OPML files in the past, so that looks quite viable.
I was worried, whether I would ever be able to save my feed subscription list from Google Reader.
And yes, I am able to do that.
Settings > Import/Export > Export your subscriptions as an OPML file.
I did hack OPML files in the past, so that looks quite viable.
Subscribe to:
Posts (Atom)
