JCB_K

Minor nitpick, it was Path who first started using the cover photo. Facebook did the same only a few months later, and then many other services followed.

So this is a location sharing app, and a founder/developer posts privately shared locations on Twitter? Seems like a good reason to avoid using it.

What he said is that he is "the exclusive rights holder for the artwork contained within Flat UI". Presumably he's referring to Flat UI the UI Kit, not Flat UI the general trend.

I'd say this service already exists... http://cl.ly/MZz7

phpsh[1] by Facebook is good. Ironically, it's written in Python.

[1] http://www.phpsh.org/

Nice app. Users could combine this with a proxy, so they can use files.yourdomain.com/file.html instead of dl.dropbox.com/s/longrandomstring/file.html. I've used this one for a while, which runs for free on App Engine: http://code.google.com/p/dropbprox/.

On the one hand I'm very excited by this; I see Marco as an interesting writer/speaker, when it comes to iOS development or when he geeks out about whatever gear he's recently bought. I also expect him to be a great editor, so I'd gladly pay money for a magazine put together by him.

But on the other hand...I'm really wondering why this needs to be an iOS app. Written content is perfect for publishing on the web, I really don't think you'll be running into any speed issues when you release this as a web magazine. And even if you would, why not make the content available both native and on the web?

I'm aware that Marco is an iOS developer, and that a lot of his readers (myself included) will have iOS devices, but for the sake of the open web I'm still slightly disappointed.

Maps.app allows external apps to integrate with it to provide transit data.

It's not dumbing down, it's simplifying. By designing mobile first, you force yourself to think about the priorities in your UX. You can still add all kind of things on top in the full web interface, but that's on top of the core experience.

Great hardware is worth a good amount of money.

Could use transition-delay. Supported in all browsers except IE.

from the article:

It's built into the normal iPhone texting application and turned on by default. When my Mom texts another Apple user, iMessage will automatically route her message over the Internet. She doesn't have to approve this, and honestly, probably won't even know the difference.

The problem with that approach is that he expects be extradited to the US as soon as he gets to Sweden. Oh and you might call it nitpicking, but he's not convicted of rape yet, let alone charged with it.

That's why I said there's better ways of getting a MacBook into your webpage. But my point still stands, :before and :after are very powerful.

No it doesn't really, it keeps your HTML clean. Sure, there's better ways of getting a MacBook into your webpage, but this definitely shows the power of the :before and :after selectors.

Funny that all 3 companies you mention are money-related, which is a tough nut to crack in most countries. There's so many rules and regulations which all differ from country to country that I think it's quite understandable for companies like these to focus on 1 country first.

BTW, obviously all startups handle money in some way, but for these 3 it's a bit more complicated, as they're providing financial services to third-parties. (Ebay+Kickstarter to sellers/buyers, Stripe to sellers.)

That'd really sucks if you're relying on them as a business owner, but it's also a lesson to avoid relying on products still in development.

I'd be interested to know what this policy change is though. I believe Visa didn't work on iZettle in the UK since launch.

offered money back to the sites

That's where the problem lies, they first took money from users, and then "offer" to pay it back. They should've done it the other way around, only charging money for sites which actually signed up to the service.

They've done a good job at making it sound like a great service for publishers, but when you think about it a bit more it's quite shady.

This is just goodwill-in-disguise. They've collected money on behalf of publishers, without consent, and now they realise that was a bad idea. They understand they obviously can't get away with keeping the money, but they don't want to invest the time into you know, actually contacting the domain owners.

Making a separate app is not a solution. Speeding up your main app is.

It seems like this is made by the team formerly known as Sofa. Both the person who posted it and the name in the screenshot used to work there.

I really don't see the point of separate apps. The main Facebook app, Facebook Messenger, Facebook Photos...what's next?

Anyone who can enlighten me why this would be a good strategy? Seems like unnecessary fragmentation to me.

When Cloudflare has a high-profile client, they'll often blog about it. It's a smart marketing technique, because they lift on the publicity around the client.

Anyone who needs to share a message really securely is not going to that via your service, however sincere your promises might be.

moondev assumes that someone who uses a VPS is more likely to use SSH/version control rather than FTP.

That's great, but let's get back on the topic of West-European countries, shall we? The Netherlands isn't Nordic by any stretch. Nor do they have awesome metal bands by the way.

Not sure why you're being downvoted, you've got some good points.

Maybe because you said definitely JavaScript, and the GP said he had javascript disabled, but your point still stands.

What do you mean? @Font-face is completely adopted by browsers.

Google wasn't first. Facebook wasn't first. They both make their money from consumers, and guess what? They're doing a pretty good job at it.

And from the author's viewpoint (Instagram is just "a few filters [...] a few sharing options") Instagram wasn't first either; Hipstamatic was doing the same thing way before them, with a different business model.

That's why you set the initial scale to 1.0 when you're designing a responsive website. This disables the default iOS behaviour to scale a website to fit within the screen.

<meta name="viewport" content="width=device-width; initial-scale=1.0">