adeelk

FYI, Birman lives in Russia.

Wow, it’s great to see someone with an appreciation of soccer tactics on HN!

You can use `identity` instead of (fn [x] x).

Okay, it should be working now. Thanks again.

Thanks for letting us know, we’ll get back to you in a couple minutes.

I think in the whole client-side rendering debate, a lot of people miss the fact that there is a one-to-one correspondence between JSON and a certain subset of HTML, that can be illustrated by the following example:

    {"user": {"first_name": "David",
              "last_name":  "Hansson"}}
    
    <div class="user">
      <div class="first_name">David</div>
      <div class="last_name">Hansson</div>
    </div>

If, as 37signals basically seem to be doing, you restrict yourself to this subset of HTML and use CSS to do _all_ presentational styling, then honestly it’s all the same either way.

It’s not just client-side apps where you can consume your own API. It’s completely possibly to do the consumption on the server side.

Why only free books? Seems like an arbitrary constraint.

Could it just be that your taste has become more refined? Watch this interview with Ira Glass: http://kottke.org/11/04/your-taste-is-why-your-own-work-disa...

It looks like a buildpack describes how to detect and compile apps for a given language / framework. So you can use a custom buildpack if you want to use a framework that Heroku doesn’t support by default.

For what it’s worth, Clojure is a Lisp with namespaces: (string/lower-case yelling).

“Real-world requirements” don’t make code ugly. They just make the problem harder. Hard problems still have elegant solutions.

I don’t think the analogy from web design carries over, then, does it? You’re not using the word "responsive" with the same connotation.

I didn't understand the responsive design analogy. I assume it's not the operating system that the developer responds to, so what is it?

Pure mathematicians are always motivated by a problem, even if it isn't a "real world" problem.

See also [1], where Terence Tao suggests that 2 pi i may be even more fundamental than both 2 pi and pi, and [2] for some explanation on why.

[1] http://blog.computationalcomplexity.org/2007/08/is-pi-define...

[2] http://qchu.wordpress.com/2011/03/14/pi-is-still-wrong/

Make sure you show her Gauss’s trick for summing arithmetic series.

Ahem, “case-sensitive”?

Copy the files to your computer, make the changes, and copy them back?

I’m a Clojure user that switched from Python. We’re now using it at the startup I founded. So far it seems to have been a great decision.

I completely agree. I think this problem is rather pervasive in Django (it goes far beyond just the authentication system).

I think there’s a usability concern only when the dialog presented is in some way dependent on the main page, e.g. if it provides some information that requires the original context. If you’re just showing zoomed-in photographs from a gallery, for example, I don’t see a problem.

We’re still quite far from my example. The next and previous buttons are images instead of text, and I don’t want the close button or the caption above the image. If you still don’t get my point, you can try actually reproducing my example.

I’m referring to leakage in the other direction. Think of a lightbox library as a layer over JavaScript’s API. When working with a library you can either use the configuration options provided or just go back down a layer. The space spanned by the configuration options is inevitably smaller than the full space of possibilities you have when working at the JavaScript level, so it’s likely that you have to go back down to JavaScript anyway. That’s why I prefer working with libraries with less friction between the layers over those that try to anticipate a use case but are useless as soon as you need something different. As phzbOx mentioned the Django authentication system is another example.

Great, now how many more lines to move the arrows from the top of the image (as in http://jacklmoore.com/colorbox/example2/) to the sides of the window as in my example?

There are usability concerns that you should consider, but that doesn’t mean there are no appropriate use cases. Anyway, you don’t have a choice when it’s a feature a client asks for.

Every modal dialog plugin I’ve seen takes the following approach: try to anticipate the ways people will use it and provide configuration options accordingly. The problem is that as soon as you require anything the developer didn’t anticipate, the plugin becomes useless (or you start messing with the source). If you’ve read Spolsky’s essay, you’ll recognize this as a leaky abstraction.

Veneer tries to minimize leakiness by doing the absolute minimum while making it simple to add anything you need (as in my third example).

If you're not trolling, can you show me how to reproduce my third example in one line?

Yeah, I did mention the line count in the title but the real point is that it doesn’t come with extra features that you’ll have to customize anyway. For example, there are a million ways to present next and previous buttons when you’re showing a group of dialogs, and if you want to use a different way than the one your library comes with, it’s going to be frustrating. I looked at five or six different libraries before deciding that just putting buttons where required in the DOM and attaching onclick handlers would be a lot easier (see the third example).