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

41–50 of 124 posts

Re: How we keep GitHub fast

#41

Post by heydonovan »

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 typical project manager response I've come to know.

Re: How we keep GitHub fast

#42

Post by didip »

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…

Broken window theory basically. Ugly internal tools feed into not-giving-shit attitude among employees.

And I'm sure employees are happy if their admin interface is pleasant to look at and contributes to their productivity.

Re: How we keep GitHub fast

#43

Post by femto113 »

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…

Other people are going to look at this page hundreds or thousands of times, often in moments of crisis, so investing in making it easy to read/understand is a no-brainer for positive ROI on time. As for "making it pretty", it's not like this is chock full of gradients and exotic fonts and custom background images--in fact there's no reason I can think of why simple, pure-CSS designs would take any longer to develop if they're pretty than if they are not.

Re: How we keep GitHub fast

#44

Post by majormajor »

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.

Craftsmen absolutely think about what's stronger and more durable, not just what's nicest looking (especially for non-visible parts!). I've got a few pieces of pretty decent antique furniture that's made its way down to me in my family (stuff made by craftsmen, not by mass production), and the hidden pieces aren't finished or styled to the same degree as the front ones. The purpose of the back and other non-visible parts is to hold stuff together, not to look nice. I would also point out, from your own link, the specs for their "the ledge":

"available with a solid domestic walnut top, sides and doors with a plywood bottom and low voc finish or painted mdf."

(Of course, these little details about what's "the right way to do it" are rather irrelevant to the greater point, which is that if you're the type to want to do things the right way, you're going to do things that way. Just don't hate on plywood, it has its uses (and feel free to come up with the programming equivalent!))

Edit -- some more notes on plywood: a sizable piece of plywood (like for the back of a chest of drawers or bookshelf) is going to be stronger (especially with regard to bending, IIRC) and vastly cheaper than a solid piece of wood since it only needs thin pieces of veneer with good grain for the outer layers. And IMO, it looks nicer than having several individual solid-wood boards jointed together in parallel.

Re: How we keep GitHub fast

#45

Post by kneath »

pestaa wrote: post #39

A couple of questions: - What does the top chart represent that blends into the background? - What is so costly about rendering pages for Googlebot that it takes almost twice as long as the average rendering time for public views? The throughput is especially interesting as it is less than 30% of its public equivalent. - What does 1 cpu unit equal to? - Also interesting to me is the fact that API requests require the…

The top chart is the throughput for the whole stack over the time period listed in the dropdown.

Googlebot tends toward the opposite of the pages we optimize for. For example, Googlebot is really interested in the 38,291th page of your history.

I think 1 CPU unit is a core, but I'm not sure. It's mostly interesting in terms of relative numbers.

And yes, both api and the web live in the same application servers.

Re: How we keep GitHub fast

#46

Post by chubot »

spullara wrote: post #38

Doesn't something have to be fast in order for it to be kept fast? My experience using the Github web frontend is one mostly of frustrating slowness, especially as of late.

Yeah I don't understand this at all. The main reason I don't use Github is because of the high latency. I really dislike their source browser -- it has really low information density and the animation clumsily hides latency.

Re: How we keep GitHub fast

#47

Post by chubot »

chubot wrote: post #46
spullara wrote: post #38

Doesn't something have to be fast in order for it to be kept fast? My experience using the Github web frontend is one mostly of frustrating slowness, especially as of late.

Yeah I don't understand this at all. The main reason I don't use Github is because of the high latency. I really dislike their source browser -- it has really low information density and the animation clumsily hides latency.

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, and maybe 1s total. This is many times slower.

Re: How we keep GitHub fast

#48

Post by kristianc »

stephengillie wrote: post #24
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

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.

True or not, I'm glad you made the point - if only as a counter against lazy Reductio ad Jobs thinking.

Re: How we keep GitHub fast

#49

Post by pnathan »

tanoku wrote: post #12
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…

It was done in-house. We really care about how our graphs look, because graphs represent information. It's like typography. Humans learned how to write 5000 years ago, and it took us a very long while until we mastered the art of transmitting information like that. Once we mastered it, however, we started caring about the way we present that information. For no specific reason, but we developed unique typefaces that…

This is something that coders should think about. A culture of quality drives looking for perfection at every level, whether it be code, typefaces, graphs, or network configuration.

Just 'cause there's non-code aspects doesn't mean they have freedom to be ugly when you're striving for excellence.

edit: English fail.

Re: How we keep GitHub fast

#50

Post by SeoxyS »

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 what it's worth, if you were working for me, you would be instantly fired.

This is exactly the kind of opinion that perpetuates the mass of low quality crap in the world. It's an example of cutting corners, and long-term, it ends up costing so much more than it saves.

Post reply on HN