I wasn't thrilled with it out of the box, but stopped noticing it after a day. It definitely wouldn't be my choice, but it doesn't bother me much. I don't usually read PDFs on a tablet though.
which only exists (in a full form) for Android. I think they're just focusing on a fast read only implementation, with the tradeoff being fewer features.
Any examples of mobile being great for mid-longform text/code content? Github isn't an image site, and the type of content created on it is usually (not always) longer than 140 characters.
Its generating static files from MD files. That requires a server-side language of some type. The weird part is that it appears to use both Node and PHP.
I'm a Durham resident. The city as a whole does not have great accomodations for bikers on the roads. It has some great bike paths, but in places where that isn't an option you generally are on the road with cars and very little leeway to get out of the way.
Uh... you're not building very complex projects then :) Before you get defensive, consider something like Amazon.com as an easy extreme example. Or a banking website or non-trivial html5 based onlline game as less extreme ones. None of those are getting built in a day, and probably not without the use of libraries (though for something like amazon the libraries may be mostly proprietary/internal)
When companies make restrictions like that they almost always mean people in general with an upward limit on how many people to prevent abuse (a very generous 10 in this case)
I think Marco is saying this is good from an independent ios developers perspective, not necessarily from a users perspective. As somebody who makes his living as an independent app developer, I'm sure he's thrilled about this. Its undeniably an opportunity for independent developers who don't have to maintain an existing app. Whether its good for users or the ecosystem in general is a totally different discussion.
From Coffeescript's website: The golden rule of CoffeeScript is: "It's just JavaScript". There was nothing at all coffeescript specific about his examples, other than the syntax. The issues he pointed out were javascript issues discussed using coffeescript syntax.
You're assuming this is generally true. All we know is that it seems to be true for this one guys site/picture. Google has access to ALL of the data for this feature. They're in a much better position to make an informed decision on its value.
I've seen a bunch of these noJQuery posts lately, but they've always focused on selectors. I'm curious what these people use for Ajax. Do they use the (very verbose) native syntax? Or are there any nice lighter weight libraries that separate out Ajax functionality into a readable abstraction like jQuery does?
"our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there" That is nice anyway, as somebody who has to look at the sketchy fonts on chrome for windows every day.
The article starts with the primary assumption that programming is a commodity skill, then is astounded when the world doesn't back up his theory. Not exactly going to learn a lot like that.
I felt like the article did a good job of explaining the potential replacements, but failed to make a convincing case for why the perfomance benefits outweigh the simplicity of jQuery. There's a conversation to be had about balancing those two, but this post makes the implicit assumption that performance is king and never really addresses the tradeoffs between performance and simplicity/familiarity.
I think he's referencing the "built on an open source language" model, not saying that everybody will be emulating discourse. Its not immodest to say that you're switching to something that you believe is the future. Its not like he's claiming that he invented "open source languages" or was the first to claim that as the future of programming.
I think the author is missing part of the reason it runs through the servers. Along with storing the "read it later" actions, running it through their servers allows background checking and push notifications, which isn't possible for 3rd party email services on iOS otherwise (though I agree that a graceful fallback to checking gmail directly would be nice)