Category: feed reading

E.g. Jenkins (the automation server) provides RSS feeds describing job build histories. Perfect means to survey build results, and an approach that comes with Jenkins out of the box, one that does not create and send e-mail messages — a rather stupid overhead.

I got the idea of using Outlook for feed reading, when I came across a recipe in the Jenkins literature describing how to read Jenkins feeds using Firefox. Just recently before I had noticed Outlook’s ability to read RSS feeds. “1 + 1 = 2”. In the corporate environment I worked in then it sounded rather natural to recommend Outlook to read those Jenkins build history feeds.

In one of my early cases Outlook / Exchange refused to load a specific Jenkins feed – but it accepted another one. What was wrong with one but not the other? I first suspected the Exchange server would not see the Jenkins server (“no network route”), which would result in a rather unspecific error message. I created a trouble ticket with the Exchange admin staff. They suggested I should connect to the server and I would get prompted for credentials. I did that before, I thought, but how would Outlook be able to prompt me for RSS feed credentials? I would need a browser for that. Alright, tried my favourite browser and there was a login form. But browsers do not share their cookie store with Outlook, right? All of them? Really? IE does, IE and Outlook share their cookie stores. Tried IE, and from then on Outlook was able to make use of the RSS feed URL in trouble (earlier). Lesson learned. And of course: I described my findings here.

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.

feedly.com

NewsBlur

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.