This is pretty hilariously written as if western media weren't up to the same thing. RT and BBC News occupy neighbouring channels on local TV, so over the past few weeks I've been entertaining myself by repeatedly flicking from one view to the other.
As for the BBC coverage, this is one of my favourites: http://i.imgur.com/vkFqM3Q.png . It's as if the Russians crossed the sea to invade the mainland of poor old Ukraine. Compare to this: http://i.imgur.com/BXsojhV.png , notice the magically disappearing expanse of water mostly segregating Ukraine from Crimea.
Except that it doesn't. While Crimea is a peninsula, surrounded on three sides by sea, there's only one major road from Crimea to the Ukraine, which runs through Krasnoperekopśk. This is because the Crimean border with Ukraine is mostly inlets lake and weirs, and there are just minor alternative bridges and roads.
Neither map is correct, that is the point I take from the parents comment.
I rarely do. When I have to (or want to) I ask a relative or a close friend of mine. Usually my brother. I think in the last ten year I haven't made more than ten online purchases.
So... Not owning a credit cart isn't (for the moment) an inconvenience for me because I rarely need to use one and if I have to I can find someone to help me with it.
I pay my bills via the online banking system my bank set up though. I use a card (one issued by my bank to each of its clients that allows me to pay for stuff IRL or to retrieve cash from ATMs) with a little calculator-like device that churns out temporary authentication codes. This system only works with my bank though ; I can't use it to buy from online vendors. But I don't think it qualifies as online purchases. It wouldn't let me buy hosting for instance :)
 there are some exceptions though. ie mobile company generates links that initiate a transaction I have to confirm via the calculator and by logging into my bank.
1. Note that there are no plans for postgres to implement a specialised UPSERT. The plan was/is to implement MERGE, which is a fair bit more generic (especially with the 2008 and 2011 extensions). In fact, TFA very specifically disagrees with this route in his conclusion.
2. IIRC the rule method does not work correctly for multiple-rows inserts including duplicates
> 1. Note that there are no plans for postgres to implement a specialised UPSERT. The plan was/is to implement MERGE, which is a fair bit more generic (especially with the 2008 and 2011 extensions). In fact, TFA very specifically disagrees with this route in his conclusion.
Does the SQL standard actually guarantee that a MERGE is atomic? After all the MERGE statement involves a subselect which seems to be about as concurrency safe as a SQLite replace insert which a join.
There is a patch for specialized UPSERT which was being actively developed very recently. I would not be surprised if it makes it into PostgreSQL 9.5. On the other hand there is currently no working being done on MERGE.
i wish they did have a feedback loop. i have a catch-all domain and an employee that was terminated with us left so now I get the barrage of emails to a general box for his LI account.
well he never updated his linkedin to a new email and you have to sign in to unsubscribe. well, i don't want to reset his password because i can see he still uses the LI and there is no way to stop these emails. seems like making it impossible to unsubscribe would violate CAN-SPAM.
DKIM is not a feedback loop. A feedback loop is when someone hits spam on one of your emails, the provider lets you know what message caused the user to hit spam. If you have a unique message id or something else in the email encoded in you can tell who it was and not send them any more emails.
As a recovering hardcore Joke Engine user, I suggest not getting too tied up on TOS minutia as arguments against App Engine when there are plenty technical reasons to avoid it like the plague, e.g.:
- Behavioural changes as a result of unannounced internal release process. Go to bed, wake in morning to app serving 500s (happened twice)
- Design flaw that ran so deep they had to redesign the datastore, insisting on people start migrating before they even had migration tools ready. Prior to that, at least one outage event required running the Google equivalent of fsck and leaving "/lost+found" folders in everyone's datastore (WTF?!?!? Not even once, dude!)
- Latency that varies according to the phase of the moon, and you're billed for it anyway.
- Continually changing architectural story around apps. Last year: Memcache is cheap, free, and shared! This year: Dedicated memcache, only $66/gb/month! 2 years ago: elasticly spun up processes! Last year: dedicated hardware thread, only $100/thread/month!
- Let's not forget the wild pricing changes depending on how much the App Engine team had packed in their crackpipes the night before
- Service characteristics you won't see on any other platform (e.g. DB query latency). So regardless of abstraction layers, your app inevitably ends up designed for a single platform
It's a platform that succeeds only at exposing users with RAM-sized datasets to planetary scale problems, all the while charged handsomely for the privilege of the self-delusion that some edge was gained through all the suffering. Seriously fuck all that. I could turn this into an essay but why bother.
My company hosts our app on GAE and I could not agree more with this. GAE is horrible. We are paying close to $1000/month and we could get better performance on a $5 Digital Ocean instance. $700 of that is "premier" support which is a joke. We're lucky just to get a response back. Not to mention they broke Python's debugger(PDB) a while back and it took them three month's to fix it.
My first thought was "Man, this would have made a nice hackathon project..." And now that I know it's not actually real, I'm wondering how hard it would be to set up a mobile app that allowed credit card donations to various political groups/campaigns, with included position list and search function... (but obviously not the "text a law" or similar functionality)