idan

Hi there. Designer of gist.io here.

The reasoning is more prosaic. I wanted a workhorse body serif that met the following criteria:

- Google web fonts. I love and use typekit, but gist.io sees a decent amount of traffic. I needed something unmetered in this case.

- A full four cuts: I don't control the content that people post, so I needed roman and italic cuts in both book and bold weights. This cut the selection of fonts available down to almost nothing. At the time, I didn't know about Poly, and Merriweather still doesn't have italics. [Edit: realized Poly doesn't have a bold weight either, so nevermind.]

The face isn't ideal, but it's grown on me the more I read it. Ideally, I'd love to license Process Type's Elena for use on gist.io.

Not knowing the details of jQuery 2.0's cruft removal, I wonder how much the performance gap is closed by a jQuery that doesn't need to deal with Really Old Browsers™.

http://gist.io/5378663 if you like your eyes or you're on a mobile device.

Fair enough. I indeed _haven't_ used rauth, just read the docs. And indeed, OAuthLib's requests shim is a bit rough in terms of tests and docs, but the OAuth1 use-case is quite solid—it doesn't do the dance for you, but every subsequent request is the bulk of the work (in my experience). For that application, the API's seem pretty similar to me—you can instantiate a requests session with a set OAuth auth object and make requests like "session.get(some_uri)" without the magical per-service mapping.

I guess I just feel like tying to one specific service is too specialized. Libraries like requests should be providing you with enough primitives to be flexible and enough abstraction to be "simple," though we clearly disagree on what constitutes the appropriate balance.

In one breath, you're complaining about a library's complexity in abstracting away an underlying mess, and in the next, you're praising a library that is complex and abstracts away some underlying mess.

It's not about stars. It's about the right architectural choice. Believe me when I say that we thought long and hard about the structure of OAuthLib, and it looks nothing at all like Java. When we started out, we were reacting to the mess that is/was python-oauth[2] and its class-based ridiculous. Like all real-world projects, after spending time with the spec and refactoring the parts which were common to the various signing flows, you end up with some real-world ugly.

Whoops, didn't notice the chronology.

All the same: OAuthLib and its libraries cover the exact use-case you've laid out, just in a fashion that has some architectural benefits on top of the usability goals. The simple "OAuth for Humans" thing you're reaching for exists—it's https://github.com/requests/requests-oauthlib. Kenneth and I hashed this interface out before we started out on OAuthLib, and thus far it's the only shim library for OAuthLib I know of (though it's pretty simple to write something equivalent which bridges OAuthLib's domain knowledge and any given HTTP request implementation). I even rewrote Requests' underlying auth implementation to make this sort of thing possible. And now you have:

oauth = OAuth1(client_key=key, client_secret=secret) r = requests.post(url=request_token_url, auth=oauth)

I don't see OAuth1 getting simpler than that, and the underlying signing logic is there for anybody to use in any context—as a provider, consumer, in a stubbing library—whatever!

I wish the author had contributed to existing efforts (https://github.com/idan/oauthlib) instead of rolling yet another OAuth implementation. We set out to build a robust, comprehensive, spec-complete OAuth signing logic library a year ago, and today it delivers what it says on the tin, thanks to a lot of work and a raft of dedicated contributors. We have support for all of the OAuth1 spec, and we're working towards OAuth2. The idea is to have one de-facto reference OAuth implementation for python instead of a few confusingly different choices, because the differences are really hard to spot for anybody who hasn't spent some time cuddling up with the RFC.

Doing OAuth signing logic correctly is pretty finicky. Requests is great, and we provide a shim layer for it, but it's silly to reimplement the underlying request signing logic for requests, urllib3 or what-have-you. And what happens when you need a server-side implementation for verifying signatures? It makes more sense to do the tricky logic in a separate, testable library than tying it to one representation of an HTTP request.

Having said all this, anybody willing to wade into this mess and write something is my kind of crazy. Respect.

Pretty please port this to iOS too. Please.

Please.

Please?

This is neat. Digging through the source to see how you're doing marker loading and clustering. One of the things I've been chewing on recently is making maps with many (>1000) markers behave smoothly. Seems like you've nailed it.

I have a precious "right" to complain to my government that monopolies are causing me to be underserved, especially since those same monopolies are often the beneficiaries of government assets (rights-of-way, spectrum, money from my taxes, etc. )

Don't see what is "morally" wrong about that.

I live in Israel, which passed strict regulations about contract term limits, number portability, service bundling, and even SIM locking (all devices must be sold unlocked by law). As a result, cellular service prices plunged due to competition here—not because they were regulated to be lower, but because they were regulated to compete vigorously.

More legible: http://gist.io/4568377

While these are certainly improvements that Instagram could make to improve their app, this article is more attitude than helpful critique. Absent the cruft, there is little substance here.

Unworthy of HN, IMO.

Same post, easier on the eyes (particularly on mobile): http://gist.io/4454814

Same in Israel, with the caveat that households which keep kosher often have two sinks side-by-side; one for meat and one for dairy.

I recently built a web-based tool for visualizing usage of Tel Aviv's municipal bicycle rental system using D3 and mapbox (warning, hebrew): http://telostats.com

Source is up at https://github.com/idan/telostats, janky though it may be. This was my first effort with geo and D3, and I'm a python person, so the JS is probably eight different kinds of terrible, but hopefully it's useful. There are a lot of examples like the OP's blogpost where D3 is used to render geometry, but very few that show you how to use D3 as an informational layer above an existing slippymap (which is what we did).

Zurb Foundation. (http://foundation.zurb.com)

Not sure if disgusted with creative grammar / neologisms.

If all of your content is in the slides and the slides are contentless, then the presenter has deeper problems.

The point here is that slides are for illustration. It is fine to have brief slides if they dont get in the way of the _presenting_.

Before the haters flag this like yesterday: read the damn post. There's a reason for the acerbic title, and it has absolutely zero to do with denigration of females.

It's the title of the article, and what—"Shit" is permissible but "Bitch" isn't?

There's some really good content here.

A fantastic deep-dive. If you want to know just how deep you can take the craft of presenting beautiful type, this is a great example.

Civility on HN. Faith in humanity, restored!

I don't know what search terms you used, but I got lost in a thicket of docs on generating and uploading entirely custom tilesets, which I was hoping not to have to do.

Thanks for the link, less so for the snark!

Neat.

How did you get google to serve up a white tileset? Or did you generate your own?

You're right, I could have done a better point of communicating your last paragraph.

The point of this piece was to serve as a rebuttal to the handwavy notion that design is purely subjective. Of course design has subjective aspects—humans are subjective creatures, and we design for them. You're spot on with the statement that professionals have the approaches and tools for evaluating design choices.

The little-league-ers, in my experience, rely on subjective statements ("It looks / it feels") more often than the ones who have depth. As a designer, my responsibility to my client is to be able to explain why my choice is in service of their business goals. More often than not, it sounds like a chain of justifications up the hierarchy of needs. Sometimes it's a conscious choice that is worse because something else has higher priority. It takes some practice to articulate, but there's rarely a choice that isn't related to your other choices, which are in turn related to your constraints. If you can't tie a choice to that chain, then it might just be that it doesn't matter, but more often than not it's a red flag that your choice isn't grounded in conscious thought about what makes your thing better.

I can convince you that this pattern of lit-up phosphors looks grabbable by knowing what artists have long known about shadow and lighting to give such elements affordance (http://en.wikipedia.org/wiki/Affordance)—an appearance of tactile actionability.

Cognition and perception are remarkably similar across cultures because vision and physiology are remarkably similar across cultures. There's some trickiness regarding cultural implications (for example, colors carrying different connotations across cultures). Navigating and using this shared language to meet your design goals is far more likely to succeed when you're aware of the considerations and use (or break) them consciously.

This doesn't mean that all design should trend towards skueomorphism—conventions enter into this process, but convention isn't a nebulous affair either. If your audience isn't particularly specialized, you can rely on them being familiar with the UI conventions of their operating system, to a greater or lesser degree. This means that people will likley try to resize boxes from the lower right if you draw something that looks "grippy" there, unless they're at home in a RTL locale, in which case they might reach for the lower-left first. If you're overlaying resize controls onto a box, how are you going to draw those controls? Will you draw them outside your content—does your environment even allow you to do that? If you're drawing them on top, how do you ensure that they are easy-to-target without obscuring too much of the content? How do you deal with people who have poor sight or other vision defects like colorblindness? What about audiences who might have trouble using a mouse, like the elderly? What if your application has to serve all of these audiences at once? How would you even go about testing the decisions you make?

Of course there's subjectivity in how to execute this, but I've just led you through a thicket of constraints that affect your ability to communicate affordance using nothing but the illusion of pixels on a screen. Knowing what parts are science, what parts are convention, and how to effectively meet your design goals requires an understanding of the discipline. _Objectively_, without science your pretty interface might be pretty, but it might be a shitty interface, and you won't know the difference?

I plan to do a followup post about design and objectivity: the fallacy that design can be reduced to an A/B testing formula.

I'm in too! @idangazit

Shame, we had a meetup group until exactly last week—which shut down for lack of use.

This.