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

61–70 of 124 posts

Re: How we keep GitHub fast

#61

Post by thornofmight »

thisishugo wrote: post #28
stephengillie wrote: post #24

Earlier quoted context omitted.

That's not actually true. You'll use the plywood because it's stronger and because it's not seen. You get both the cost savings and increased structural stability, which will get you more customers.

That's not the point Steve Jobs was making. The point is: if you care about what you do, you'll do your best even when you don't have to. Because as far as you're concerned you do have to.

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

Re: How we keep GitHub fast

#62

Post by nikcub »

kalid wrote: post #18
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…

"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

NeXT went on to go broke and sell their factories for pennies on the dollar, becoming synonymous in silicon valley with excess where it isn't required

edit: for those that don't know, that jobs quote is in reference to why they put so much effort into their factories, which really were ridiculous.... jobs went on to just outsource everything after his return to apple

Re: How we keep GitHub fast

#63

Post by jlgreco »

bkbleikamp wrote: post #33
stephengillie wrote: post #24

Earlier quoted context omitted.

That's not actually true. You'll use the plywood because it's stronger and because it's not seen. You get both the cost savings and increased structural stability, which will get you more customers.

That's the difference between Ikea and a company like http://www.urbancase.com/ . Craftsmen don't think that way.

Ikea uses particleboard (not plywood), and certainly not for its strength.

Re: How we keep GitHub fast

#64

Post by apsurd »

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 me I see it as breeding a culture of passion. I'm sure there are tons of people who really want to work for GitHub.

This is a small example of why that is true.

Toward that end, I'd say it's a fantastic use of resources.

Re: How we keep GitHub fast

#65

Post by wamatt »

lazyjones wrote: post #59
wamatt wrote: post #31

Github is generally pretty nippy for me, and it's a pleasure to work with. Just 2 performance concerns I've noticed: 1. The network graph / /network" rel="nofollow">https://github.com/ / /network seems very sluggish to render 2. The API is slower than normal for HTTPS Usage: $> time curl -i /" rel="nofollow">https:// / For comparison (2nd request's): * https://www.googleapis.com/ 187ms * https://graph.facebook.com/ 1…

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 ...)

Good find!

Didn't realize Github were using 2048 bit keys. I would be interested in knowing what the actual performance differences are between key sizes, given RSA is used in the initial negotiation before symmetric SSL takes over.

>so one could say that googleapis and fb use snake oil rather than ssl ...)

Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might be a stretch. ;)

Re: How we keep GitHub fast

#66

Post by teyc »

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…

Let's have a look at how much marginal effort this takes:

- time spent thinking about what needs to be on the page (not extra)

- time spent thinking about what order the data should be displayed (not extra)

- time spent laying out the data (extra)

- time spent replacing the default font on the stylsheet (extra - minimal)

- time spent with getting graphs together (extra - but it is a skill. Once having done it, they could do this over and over)

Overall, I think the marginal time spent is well justified. Put it this way, your company probably hires cleaners to clean the office every day - that's a recurring cost. The cost sunk into a nicer design template gives the workers a nice working environment - that's significantly cheaper.

Re: How we keep GitHub fast

#67

Post by jaylevitt »

wamatt wrote: post #31

Github is generally pretty nippy for me, and it's a pleasure to work with. Just 2 performance concerns I've noticed: 1. The network graph / /network" rel="nofollow">https://github.com/ / /network seems very sluggish to render 2. The API is slower than normal for HTTPS Usage: $> time curl -i /" rel="nofollow">https:// / For comparison (2nd request's): * https://www.googleapis.com/ 187ms * https://graph.facebook.com/ 1…

The network graph fails to render at all most of the time I want it. I suspect it's heavily cached, takes a long time to initially compute, and I'm only looking at graphs to see if a seemingly-abandoned project got forked and picked up elsewhere - which means I'm never seeing the cached version.

It also is (or used to be) possible for a particular graph to get into a wedged state; github support can fix that if you report the repo, but it's often not worth the effort for me.

Re: How we keep GitHub fast

#68

Post by runejuhl »

wamatt wrote: post #65
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 ...)

Good find! Didn't realize Github were using 2048 bit keys. I would be interested in knowing what the actual performance differences are between key sizes, given RSA is used in the initial negotiation before symmetric SSL takes over. >so one could say that googleapis and fb use snake oil rather than ssl ...) Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might…

>Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might be a stretch. ;) It's no less snake oil just because every con man sells it...

Re: How we keep GitHub fast

#69

Post by runemadsen »

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…

Code, design, backend design, it all matters. If your code is shitty, your product is shitty. If your internal tools are badly designed, you can feel it on the frontend.

I'm amazed by how smart decisions Github make. They dare to focus on things that are not obvious important, but make a huge different for the employees. The employees in return make a world class product.

I really enjoyed this post, and it keeps me ever inspired to thrive for good design: Nn code and in graphics. On the backend and on the frontend.

Post reply on HN