Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we keep GitHub fast

github.com

Post reply on HN
Print view View original

101–110 of 124 posts

Re: How we keep GitHub fast

#101

Post by teejae »

notJim wrote: post #52
chubot wrote: post #47

Earlier quoted context omitted.

EDIT: I did some spot checks with chrome developer tools on a project linked from their front page: https://github.com/rails/rails Chrome is reporting the code tab is taking 3.7 seconds to load. 22 HTTP requests. The Pull tab has over 100 HTTP requests. I don't consider anything over 1s to be fast. Even the initial HTML is taking more than 1.5 seconds on the Pull tab! I think you should aim for 200ms for the HTML, an…

Do you have an idea of a site that you consider fast? I just checked a few sites around the web, and 1.x seconds seems pretty average (I'm looking at the onload time, as that seems like a somewhat-maybe scientific way of looking at things.)

I think we at YouTube think our site loads pretty fast.

Re: How we keep GitHub fast

#102

Post by bertzzie »

thebigpicture wrote: post #100

Is "responsiveness" the same as "responsive design"?

I don't think it is. "Responsiveness" in this article's context is about how responsive the page is, as in how fast it renders and shown to the user.

"Responsive design", OTOH, is about a page that adapats to the user's screen resolution; eg: renders differently on 480x320 vs 1024x768, on the same code base. HTH.

Re: How we keep GitHub fast

#103

Post by travisjeffery »

eridius wrote: post #96
thornofmight wrote: post #61

Earlier quoted context omitted.

I just got finished reading his biography and I am nearly 100% sure he meant this literally.

Steve Jobs was a well-known woodcarver and carpenter. When he wasn't at Apple, he was usually found in his garage, finishing off a new wardrobe or a sturdy deck chair.

Source(s)? (More because I'm interested rather than doubting you)

Re: How we keep GitHub fast

#104

Post by idunno246 »

heydonovan wrote: post #41
aggronn wrote: post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

Ugh, this comment really gets under my skin. I'm so glad that GitHub has a nice looking back-end, especially if employees have to look at it all day. That's one of the reasons the company I work for utilizes Twitter Bootstrap, because not only does it reduce development time, but it looks good too. Also, it's just CSS. It doesn't take that long to swap out the values of some of the colors. Unfortunately, this is the…

I redid an admin tool from plain html to bootstrap. It actually provided less functionality, but because it was prettier people thought it did so much more.

Really, prettier makes it easy to consume the information you want to, which is just as important as getting that info on the screen.

Re: How we keep GitHub fast

#105

Post by scottschulthess »

aggronn wrote: post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

For designers on the team maybe this is just useful practice.

Re: How we keep GitHub fast

#106

Post by notatoad »

scottschulthess wrote: post #105
aggronn wrote: post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

For designers on the team maybe this is just useful practice.

Not just practice: designing for co-workers will give you the most extensive feedback you'll ever get. When the guy in the next office can shout at you very time the contrast is a little funny or the spacing is kind of ugly, those details make their way into the public-facing side of the project as well.

Re: How we keep GitHub fast

#107

Post by statictype »

thebigpicture wrote: post #99
kalid wrote: post #18

Earlier quoted context omitted.

"When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through." -Steve Jobs

But if you construct the chest so no one can verify what's used to make it, what's the point? If Apple's products are quality all the way through, why can't I easily open up my iPod/iPhone/iPad? If it's quality all the way through, why would you hide what's on the inside?

Part of it's high quality polish and finish is the lack of seams and protrusions and screws. This necessarily means something that's difficult to open up.

You can make an argument that they made the wrong trade-off between aesthetics and pragamatism, but for the trade-off they made, they executed well.

Re: How we keep GitHub fast

#109

Post by grandalf »

scotth wrote: post #92
grandalf wrote: post #26

Earlier quoted context omitted.

Github has so much raw talent on staff that such things are totally reasonable indulgences. Why would Kyle be happy working on it if it was going to be ugly. It's that drive for excellence that motivates the kind of people Github hires. I think it would be a major management mistake to force (or even urge) someone like Kyle to do things half ass.

It's not half-ass if you're achieving excellence by some other metric. I personally take pride in my ability to recognize tradeoffs. I encourage my peers to see things in the same light.

I'm that way too, nor am I a designer. My point was just that if you have one of the best UX designers working on something then the point is probably to have him/her optimize for functionality and design... otherwise it would have been fine to have someone work on it who was only skilled at the engineering aspect of the project.

Re: How we keep GitHub fast

#110

Post by elliotanderson »

NateLawson wrote: post #88
lazyjones wrote: post #59

Earlier quoted context omitted.

That's easy: googleapis.com and facebook.com use 1024 bit RSA keys, github uses 2048 bit. So the initial handshake is slower and the performance on your end is probably the main bottleneck. (by the way, RSA labs deprecated the use of 1024 bit keys in 2003(!), so one could say that googleapis and fb use snake oil rather than ssl ...)

Key size of 1024 vs. 2048 bits should not account for 225 ms of latency. Here's the result of "openssl speed rsa" on a mid-grade desktop computer. sign verify sign/s verify/s rsa 512 bits 0.000217s 0.000014s 4608.1 72363.4 rsa 1024 bits 0.000711s 0.000032s 1406.0 30788.2 rsa 2048 bits 0.003630s 0.000092s 275.5 10825.0 rsa 4096 bits 0.021180s 0.000299s 47.2 3349.2 In other words, the difference between 1024 and 2048 b…

They use HAProxy for load balancing which doesn't natively support SSL termination (yet...). There's probably an extra layer in there to handle that (pound/nginx maybe?) which would bump up the latency.
Post reply on HN