JManga, a digital manga service created less than 2 years ago by 39 of the biggest publishers in Japan, is shutting down in a couple months. Most cloud services related fears became a reality when it was clear no refund or backups would be offered. Check out their “Urgent Message” for more details, but believe me when I say it can’t get any worse:
It is not possible to download manga from My Page. All digital manga content will no longer be viewable after May 30th 2013 at 11:59pm (US Pacific Time)
Everybody then wondered what would happen if ComiXology went down. And funnily enough, just the day before, ComiXology had experienced a massive blackout which left people unable to read any issues they didn’t have in their cache.
Rich Jonston from Bleeding Cool concludes:
This is the moment when the real winners are comic stores… and pirates.
As I said before, and as many others said before me: own your data. Cloud services are fine by me as long as there’s a way to easily backup my stuff on my file server, thank you very much.
After the infamous announcement that Google was shutting down Google Reader, there was a lot of debates around the use of online services, especially free ones, and whether we can trust a company to keep such services up indefinitely.
Of course, nothing can last “indefinitely”, and probably nothing will last until you die. You have to expect that Gmail, Facebook, iTunes, Amazon Kindle and any other service you’re currently using won’t last for more than, say, 20 years (and that’s being generous). You need to plan accordingly.
Marco Arment sums this up on his blog:
Always have one foot out the door. Be ready to go.
This isn’t cynical or pessimistic: it’s realistic, pragmatic, and responsible.
That’s what I’ve always tried to do. I choose programs, services and products that don’t take my data away from me. It makes it easier to switch to something else if I need/want to, and it future-proofs what I spend money on.
But that’s where it gets interesting, because Google Reader was pretty open to begin with. Google may have become this data hoarding and privacy raping monster over the years, but one thing they always had going for them was the Data Liberation initiative. With it, you effectively always had one foot out the door. You could, at any moment, download a list of all your subscriptions in an open, standardized format, along with a collection of all your stars, comments, and shares. You may be disrupted for a while because you would need to adapt to a new feed reader, but you could switch, just like you can switch text editors or operating systems.
What’s wrong with the Google Reader situtation has nothing to do with your data, or with using a free service (although that is an important subject too). What happened is that Google Reader became a lot more than a free online feed reader. It became a single choke point for virtually every feed reader or news aggregator in the world. Google is of course to blame for making it a collateral damage of their social-wannabe delusions, but we are equally to blame for letting all those programs like Flipboard, Pulse or NetNewsWire rely on a single service that was never really intended to be used that way. It’s understandable it ended up this way, because relying on Google Reader meant easier adoption for new users and not having to worry about complex problems like data storage, metadata syncing, and interoperability… but it doesn’t make it the right decision either. We are to blame because we were constantly asking for Google Reader support. It became a feature you couldn’t ship without.
The death of Google reader is not about losing a product we love – it’s about breaking an entire eco-system of products and workflows.
Hopefully, we’ll recover and things will be better, but it does bring up another debate: the one about how we rely so much on other single choke points like Twitter and Facebook. Ideally, everything should be federated, like email, but I tried looking at distributed alternatives, and they’re just not working well enough. If the links you share and photos you post are of any value to you, I’d suggest you start looking at data harvesting solutions. I know I am.
These past few months I’ve seen a fair number of articles about people who switched from iOS to Android. Most of those articles talk about the differences between the 2 operating systems, and how some of those differences proved to be significant enough for whoever was switching: multitasking, notifications, the so-called “open vs. closed”, etc. That’s fine, but these specific bullet point list vs. bullet point list comparisons seem to be missing the higher level view of what’s really going on: iOS is just not working the way it should anymore.
The past month has been pretty busy, between my next secret project, my day job, and of course fixing PieCrust bugs. But somehow among this chaos seems to be emerging a release candidate for PieCrust 1.0. And it’s only fitting that I announce this on Pi Day!
As always, for a complete list of changes, I’ll redirect you to the changelog. But for the highlights, please read on.
Big thanks go to the few people who contributed patches to the PieCrust code, and to the many who reported bugs and had the patience to help me fix them.
When I first decided to work on PieCrust, I settled with PHP as the language
– even though it mostly sucks – in an attempt to make it broadly available.
Anybody who runs a blog on Wordpress should be able to switch and enjoy the
perks of plain text data without needing to install and learn a whole new
That doesn’t mean PieCrust can’t also be used in the nerdiest ways possible. A
while ago we looked at how cool it is to update your website with Git or
Mercurial, and today we’ll look at how you can host it on Heroku, which
incidentally also supports Git-based deployment.
If you already know how Heroku works, then the only thing you need is to make
your app use the custom PieCrust buildpack. Skip to the end for a
few details about it.
For the rest, here’s a detailed guide for setting up your PieCrust blog on
Heroku, after the break.