How we keep GitHub fast(github.com)
github.com
How we keep GitHub fast
https://github.com/blog/1252-how-we-keep-github-fast
15 comments
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 look beautiful, different, yet transmit the same information.
Likewise, we've spent a ton of valuable time graphing and mining data from all over our stack; it's only natural that after that, we care about how we present that data. Like typography, it's hard because it's an arduous hunt for the aesthetics hidden behind information. But this hunt is what makes us human.
That's why we design beautiful graphs, just like we'd design a beautiful typeface. Not because we are GitHubbers, nor because we are designers, but because we are humans.
Life is too short to stare at ugly graphs. And yes, you should feel bad.
PS: we have no project managers at GitHub.
Likewise, we've spent a ton of valuable time graphing and mining data from all over our stack; it's only natural that after that, we care about how we present that data. Like typography, it's hard because it's an arduous hunt for the aesthetics hidden behind information. But this hunt is what makes us human.
That's why we design beautiful graphs, just like we'd design a beautiful typeface. Not because we are GitHubbers, nor because we are designers, but because we are humans.
Life is too short to stare at ugly graphs. And yes, you should feel bad.
PS: we have no project managers at GitHub.
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.
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.
I don't think its about pride and making it pretty - that is - maybe it's the reason, but it's not what brings success in that area.
I think it's because, when it looks good, it's easier to find the information, and it makes you want to look at it. It makes you want to work with it.
Now then again while I realize github has a huge, huge amount of things running at the same time, I do find github quite a bit slower than my "own" remote repos :P
I think it's because, when it looks good, it's easier to find the information, and it makes you want to look at it. It makes you want to work with it.
Now then again while I realize github has a huge, huge amount of things running at the same time, I do find github quite a bit slower than my "own" remote repos :P
Don't mind the haters that think twitter bootstrap is a good enough UI wrapper, those are some pretty sexy graphs.
As a developer I'm totally jealous of the ability to create simultaneously elegant and usable UI/UX, even when I used to try and just copy the CSS and structure right from the HTML source (I've since stopped) it was always missing that "je ne sais quois".
As a developer I'm totally jealous of the ability to create simultaneously elegant and usable UI/UX, even when I used to try and just copy the CSS and structure right from the HTML source (I've since stopped) it was always missing that "je ne sais quois".
"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
-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.
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.
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)
I believe it was sarcasm intended to show that just because Steve Jobs gives an example in a field he has no experience in doesn't mean you should take it literally.
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.
"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.
It's pretty universal.
We have some amazing antique Persian and Korean chests in the house. Hand carved and split grain matched fronts and maybe sides, but the backs are plain and/or rough hewn. These pre-date plywood, but the same goes - don't waste effort on parts that will never be seen, just build them to do their job.
We have some amazing antique Persian and Korean chests in the house. Hand carved and split grain matched fronts and maybe sides, but the backs are plain and/or rough hewn. These pre-date plywood, but the same goes - don't waste effort on parts that will never be seen, just build them to do their job.
Ikea uses particleboard (not plywood), and certainly not for its strength.
"shitboard" is what I've come to call it.
It's "strong enough" and very light to ship. That's the only reason.
It's not strong enough for a lot of tasks and is definitely not good quality. One water spill and throw it away as the laminate just peels off - even on the expensive stuff.
I've taken to buying second hand good quality furniture (which is usually available at the same price as the shitty Ikea stuff) and stripping and painting it.
It's "strong enough" and very light to ship. That's the only reason.
It's not strong enough for a lot of tasks and is definitely not good quality. One water spill and throw it away as the laminate just peels off - even on the expensive stuff.
I've taken to buying second hand good quality furniture (which is usually available at the same price as the shitty Ikea stuff) and stripping and painting it.
I'm not sure which way you meant that point. Ikea's furniture is notorious for being low-quality and easily broken, despite looking attractive.
True or not, I'm glad you made the point - if only as a counter against lazy Reductio ad Jobs thinking.
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
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
Perhaps a better analogy was made by (General Sir Peter de la Billiere I think) about UK troops patrolling in Helmand Province.
He said something like "Even when they think no-one is watching, no sargents, no generals, they still monitor their surroundings, check the garden walls as they pass. No-one is letting the monotinity reduce their awareness."
In short, if there is a job worth doing, its worth doing well.
He said something like "Even when they think no-one is watching, no sargents, no generals, they still monitor their surroundings, check the garden walls as they pass. No-one is letting the monotinity reduce their awareness."
In short, if there is a job worth doing, its worth doing well.
Doing your duty in the military is serious business, especially in a war zone with insurgents, everyone's life is on the line. So your quote isn't an apt analogy to furniture or software interfaces. Not all jobs are worth doing well, many are worth doing "well enough" given budget,time constraints and no lives at stake.
(Not to be too harsh, but I'm speaking from the experience of having been in the military and having spent years in the software industry.)
(Not to be too harsh, but I'm speaking from the experience of having been in the military and having spent years in the software industry.)
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?
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.
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.
Plenty of tools get by being ugly, but that's not the point. Github is killing it right now, and they're killing it by having a very well designed product that developers really like to use.
Thinking of your (team's) effort as a zero sum equation can get you in to trouble. Yes, you only have limited time and effort, but on the flip side, all the time you spend doing something, you're training. By building ugly things, you're training yourself to build... well... ugly things.
Thinking of your (team's) effort as a zero sum equation can get you in to trouble. Yes, you only have limited time and effort, but on the flip side, all the time you spend doing something, you're training. By building ugly things, you're training yourself to build... well... ugly things.
I very much agree. I'm a (grad student) statistician and most of my time is spent developing models, running simulations, etc.. But once I have all the results, I need to find a way to present them in a way that is both informative, and inviting.
So I had to learn how to make beautiful plots. I used to be terrible at it, but one of my supervisors was very strict about plots: he would literally refuse to read reports in which plots weren't perfect (even draft reports). So I learnt how to make great plots (using ggplot2 for those who know R). At first, it took me forever to make any plot. Now, I can make very good ones in seconds.
So yes, instead of thinking of zero sum games, think of it as training.
So I had to learn how to make beautiful plots. I used to be terrible at it, but one of my supervisors was very strict about plots: he would literally refuse to read reports in which plots weren't perfect (even draft reports). So I learnt how to make great plots (using ggplot2 for those who know R). At first, it took me forever to make any plot. Now, I can make very good ones in seconds.
So yes, instead of thinking of zero sum games, think of it as training.
Is any of your work available to the public?
I'd rather work for a product company like GitHub than, say, a consultancy building apps for many many clients, for reasons just like this. When you have a team working on one product that ships to millions of users, you've constructed a giant lever. As Spolsky put it, "Essentially, design adds value faster than it adds cost." [1]
Your developers' efforts create enough value (once spread across millions of customers) that you have plenty of resources left over to take care of every little detail. And some of those details may include tools that make your developers' lives easier. There is great value in well-designed abstractions like GitHub's dashboard: the human brain can only hold so many details at once. When 2 dozen little details are organized onto an internal dashboard, your developers' brains can visualize them and load them into working memory in an instant, freeing them to work on harder problems more quickly and with less detail juggling. This is very freeing and relaxing, and can even help developers see possibilities they couldn't see before.
You can't justify tools like this for every $50K Rails-App-in-a-Box, but companies like GitHub and Google certainly can.
[1] http://www.joelonsoftware.com/articles/HighNotes.html
Your developers' efforts create enough value (once spread across millions of customers) that you have plenty of resources left over to take care of every little detail. And some of those details may include tools that make your developers' lives easier. There is great value in well-designed abstractions like GitHub's dashboard: the human brain can only hold so many details at once. When 2 dozen little details are organized onto an internal dashboard, your developers' brains can visualize them and load them into working memory in an instant, freeing them to work on harder problems more quickly and with less detail juggling. This is very freeing and relaxing, and can even help developers see possibilities they couldn't see before.
You can't justify tools like this for every $50K Rails-App-in-a-Box, but companies like GitHub and Google certainly can.
[1] http://www.joelonsoftware.com/articles/HighNotes.html
Yes, you should. Whatever time was spent doing this is recouped a hundredfold by making this data so easily accessible to any engineer working on the project. I'd have killed to have this kind of stats at my fingertips, especially on projects where I don't have access to the production server to dig through the logs.
Yes, because part (actually most) of a project (and what you should be worried about managing) is the people who build it and people who use it. People are complex with many needs and desires above and beyond crapping out the cheapest product in the shortest time.
Should I feel bad knowing that ... someone wasted valuable time...
No, but you should feel bad for thinking "it looks pretty" ==> "someone spent a lot of time making it look that way."
In particular, what you need to consider is: maybe they didn't spend all that much time on the visuals. Maybe they were either just really experienced, and it took next to no effort to get it to look that way... or maybe they had next to no knowledge, but used a framework to make it look as if they did.
I find this is a very common mistake managers make, BTW: assuming they can estimate, in the blink of an eye, how long it took to get a certain feature or behavior of an app into existence, out of nothing (and quite often, getting this estimate off by an order of magnitude in one direction or the other).
No, but you should feel bad for thinking "it looks pretty" ==> "someone spent a lot of time making it look that way."
In particular, what you need to consider is: maybe they didn't spend all that much time on the visuals. Maybe they were either just really experienced, and it took next to no effort to get it to look that way... or maybe they had next to no knowledge, but used a framework to make it look as if they did.
I find this is a very common mistake managers make, BTW: assuming they can estimate, in the blink of an eye, how long it took to get a certain feature or behavior of an app into existence, out of nothing (and quite often, getting this estimate off by an order of magnitude in one direction or the other).
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.
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.
Really, prettier makes it easy to consume the information you want to, which is just as important as getting that info on the screen.
Why should internal tools be ugly? Well designed tools help people work better and more efficiently—putting a little bit of thought into them is not a waste of time.
It also instills a "just because only a few people will see this doesn't mean you can half-ass it" attitude.
And even if it doesn't result in higher productivity, it would be a often a good thing to do, because it makes the developers' work more pleasant.
You are focusing on the time needed to make this. That is only one part of the equation. The other part is the time spent using it.
If this is (and it seems likely) an internal tool that gets used a lot, pretty soon the time it took to make it a little bit prettier/user-friendlier will be repaid in multiples during the entire lifespan of this application.
If this is (and it seems likely) an internal tool that gets used a lot, pretty soon the time it took to make it a little bit prettier/user-friendlier will be repaid in multiples during the entire lifespan of this application.
Why is making it pretty a waste of time? And who says making it attractive took any more time than not making it attractive?
Check out Coda Hale's talk: "The Programming Ape". Well worth a watch, but jump to 24:15 or so if you want.
http://vimeo.com/40988625
http://vimeo.com/40988625
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.
This is a small example of why that is true.
Toward that end, I'd say it's a fantastic use of resources.
You know, I've been asked recently "what kind of company would you like to work for?". I had no answer then, just said that definitely not Google or Facebook.
Now I think GitHub might be that kind of company :)
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.
And I'm sure employees are happy if their admin interface is pleasant to look at and contributes to their productivity.
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.
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.
"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."
It's run by great developers, that's why. They understand the psychology of a great developer.
You have the wrong project manager and shouldn't be paid by the hour.
If the data is available, making it 'pretty' is trivial.
http://d3js.org/
http://twitter.github.com/bootstrap/
No need to waste your time, some people do....
If the data is available, making it 'pretty' is trivial.
http://d3js.org/
http://twitter.github.com/bootstrap/
No need to waste your time, some people do....
What part is gratuitously pretty? As a dashboard it looks pretty basic to me with an easy to look at color and lots of graphs to quickly figure out if there are any issues.
A couple of non-romantic justifications/reasons for ya :-)
* It may well have taken substantially less time than you think. Once an organisation has a structure in place for how the UX of a web app should run, and infrastructure in place for making sure things are coded up to that standard (standard templates, test suites, process, etc.) then these things can go together very quickly. I don't know how github runs it's UX/design side - but they seem like the sort of folk who'd streamline the heck out of the process.
* Wearing my UX hat - most of what you see isn't hard. It's basically having decent typography choices, decent vertical rhythm, good visual hierarchy. The icons look off-the-shelf from somewhere. This stuff doesn't actually cost any more time to do right the first time if you already know what you're doing (just like good DBAs automatically write normalised schema).
* With something like this - which is a mode switch between the "nice" stuff that your customers see and the stuff that you see as a developer - it's easier to keep everything nice rather than make the context-switch in development between nice/nasty.
* Wearing my ux-speaking-to-developers hat - think of it like technical debt. Yeah - maybe you could throw something together quickly that would do the job. But if you leave it in it has a knock on effect with everything you do next. It makes tweaking and extending stuff in the future more difficult. Keeping the UI clean, like keeping the code clean, may cost a little more up-front but will save you time in anything but the short term.
* Good UIs are more effective. Making the tools that the internal folk use to make the site better more effective seems like a good choice to be making.
* It may well have taken substantially less time than you think. Once an organisation has a structure in place for how the UX of a web app should run, and infrastructure in place for making sure things are coded up to that standard (standard templates, test suites, process, etc.) then these things can go together very quickly. I don't know how github runs it's UX/design side - but they seem like the sort of folk who'd streamline the heck out of the process.
* Wearing my UX hat - most of what you see isn't hard. It's basically having decent typography choices, decent vertical rhythm, good visual hierarchy. The icons look off-the-shelf from somewhere. This stuff doesn't actually cost any more time to do right the first time if you already know what you're doing (just like good DBAs automatically write normalised schema).
* With something like this - which is a mode switch between the "nice" stuff that your customers see and the stuff that you see as a developer - it's easier to keep everything nice rather than make the context-switch in development between nice/nasty.
* Wearing my ux-speaking-to-developers hat - think of it like technical debt. Yeah - maybe you could throw something together quickly that would do the job. But if you leave it in it has a knock on effect with everything you do next. It makes tweaking and extending stuff in the future more difficult. Keeping the UI clean, like keeping the code clean, may cost a little more up-front but will save you time in anything but the short term.
* Good UIs are more effective. Making the tools that the internal folk use to make the site better more effective seems like a good choice to be making.
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.
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.
I work for an agency, and I always find myself thinking that if we're content to settle for 2nd-rate tools for our own use, are we really in a position to say that what we're offering clients is 1st-rate?
It's easy to go overboard with making something pretty when it's in-house, but at the same time I genuinely find that I'm more productive when using pretty software. It's probably the INFP in me, but when something is slightly off I find it incredibly distracting.
In the case of the github dashboard images in this blog post, they do look a little designed but nothing that would take an experienced interface designer more than an hour or so. Time well spent if it makes the idealists in your team happier.
It's easy to go overboard with making something pretty when it's in-house, but at the same time I genuinely find that I'm more productive when using pretty software. It's probably the INFP in me, but when something is slightly off I find it incredibly distracting.
In the case of the github dashboard images in this blog post, they do look a little designed but nothing that would take an experienced interface designer more than an hour or so. Time well spent if it makes the idealists in your team happier.
I believe Peopleware said it best:
"Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness.
In the long run, market-based quality costs more. The lesson here is,
Quality, far beyond that required by the end user, is a means to higher productivity."
"Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness.
In the long run, market-based quality costs more. The lesson here is,
Quality, far beyond that required by the end user, is a means to higher productivity."
Sorry, but with respect if I ever had to work under someone who thinks like you I would probably have to quit my job. If I was your boss, I would probably have to fire you (as someone else said). I can only imagine you would happily run a restaurant which is kept immaculate up front, but the kitchen and employee conditions are a disgusting mess because "who gives a fuck?". Design is not just some pointless eye candy to make "pretty stuff", design is integral to usability. If you want efficient and happy employees and love their job and want to make their company succeed, don't skimp on important details. As well as anything else, when you give your employees the shitty stick constantly, don't be surprised when all this shit starts to creep into the customer facing experience. I suppose this would just be more "romantic" thinking though.
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.
- 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.
I could quibble with the three "extras" too :-) Assuming the data needs to come out in some format or another there would be some work in displaying it, and some work in getting it out and doing useful stuff with it. They're "different" not "extra".
In my experience designing things nicely doesn't really cost more than designing it badly. In both cases "design" is being done - it's just that in once case you have an expert involved.
In my experience designing things nicely doesn't really cost more than designing it badly. In both cases "design" is being done - it's just that in once case you have an expert involved.
If you were a project manager, I'd hope you wouldn't be imposing your personal tastes on a product.
I don't make products for me. I make them for my audience. The right question to ask isn't, "Do I care about how pretty this is?" It's, "What do my users care about?"
Consumer-focused products (and Github is certainly one of them) require much more investment in visual and interaction design than, say, in-house software. It's how many people judge quality, and having a pleasant experience matters to a substantial chunk of the audience. Github has absolutely made the right choice in keeping their interface a pleasure to work with.
I don't make products for me. I make them for my audience. The right question to ask isn't, "Do I care about how pretty this is?" It's, "What do my users care about?"
Consumer-focused products (and Github is certainly one of them) require much more investment in visual and interaction design than, say, in-house software. It's how many people judge quality, and having a pleasant experience matters to a substantial chunk of the audience. Github has absolutely made the right choice in keeping their interface a pleasure to work with.
You could raise the same argument about all the time they spend releasing open-source software, or producing the really great presentation slide decks that they do.
Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.
At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.
Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.
At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.
I see your point. But, if you don't care about what you are doing it will show. If you care and allow your developers to care about what they are doing, you will breed a culture that people want to be a part of. Sure it's lost money in the short term but that's short term thinking. It's better to let developers be happy and passionate about their work than to complain about the bottom line. In the long run you will extract far more value from a passionate dev over a burned out one.
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.
Considering those graphs are so similar to the ones on github's customer facing UI, my guess is common code.
An ugly add-on to their normal pages would look hackish and unimportant. If that number went up dramatically, it looks both less important (than if it was prettier) and less reliable (if they didn't bother formatting the number, did they really check its accuracy?)
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.
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.
Wow, you would instantly fire somebody for raising the question?
My goodness.
My goodness.
You're fired too.
[deleted]
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.
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 https://github.com/<username>/<repo>/network seems very sluggish to render
2. The API is slower than normal for HTTPS
Usage: $> time curl -i https://<site>/ For comparison (2nd request's):
* https://www.googleapis.com/ 187ms
* https://graph.facebook.com/ 175ms
* https://api.github.com/ 400-700ms
Not sure if anyone else noticed this
Just 2 performance concerns I've noticed:
1. The network graph https://github.com/<username>/<repo>/network seems very sluggish to render
2. The API is slower than normal for HTTPS
Usage: $> time curl -i https://<site>/ For comparison (2nd request's):
* https://www.googleapis.com/ 187ms
* https://graph.facebook.com/ 175ms
* https://api.github.com/ 400-700ms
Not sure if anyone else noticed this
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 ...)
(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.
Second, it has nothing to do with the "performance on your end" (the client).
The client side of SSL is limited to public key operations only (cert verification, encrypted the pre-master secret). These are 40x faster than private key ops, key length being constant. You're talking a difference of 60 microseconds on the client.
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
Second, it has nothing to do with the "performance on your end" (the client).
The client side of SSL is limited to public key operations only (cert verification, encrypted the pre-master secret). These are 40x faster than private key ops, key length being constant. You're talking a difference of 60 microseconds on the client.
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.
Exactly what does that have to do with the relation between RSA key sizes and hundreds of milliseconds of latency?
It does for three days. :)
http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-hap...
http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-hap...
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. ;)
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. ;)
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.
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.
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 most horsepower, yet also provide almost the lowest response time and very high throughput. How API requests are so different from "browser" requests, since I suspect both are powered by the same backend?
Sorry for my naivety.
- 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 most horsepower, yet also provide almost the lowest response time and very high throughput. How API requests are so different from "browser" requests, since I suspect both are powered by the same backend?
Sorry for my naivety.
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.
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.
Thanks for your answers, nice insight. Great job on the dashboard, its interface is really inspiring.
I still don't grasp how API can be so efficient while doing basically the same thing as the public-facing site minus probably the HTML rendering, which leads me to believe that rendering is damn resource-heavy in Rails.
I still don't grasp how API can be so efficient while doing basically the same thing as the public-facing site minus probably the HTML rendering, which leads me to believe that rendering is damn resource-heavy in Rails.
Keep in mind that a huge portion of our requests are rendering code. Syntax highlighted code. With line numbers.
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.
Upon further investigation, it's not just the API, it's the entire site.
A significant cause of the issue is their SSL implementation. Specifically it negotiates a new connection every time instead of resuming the session, eek!
http://security.stackexchange.com/questions/5511/ssl-session...
https://www.ssllabs.com/ssltest/analyze.html?d=github%2ecom&...
A significant cause of the issue is their SSL implementation. Specifically it negotiates a new connection every time instead of resuming the session, eek!
http://security.stackexchange.com/questions/5511/ssl-session...
https://www.ssllabs.com/ssltest/analyze.html?d=github%2ecom&...
Is this a problem with the default setup of Nginx out of the box, or has GitHub intentionally disabled session resumption?
Haven't tried the latest nginx install, but according to the wiki, ssl_session_cache controls this, and is set to 'none' by default.
http://wiki.nginx.org/HttpSslModule
As for Github, could just be a misconfiguration, or perhaps they had some more deliberate reason in mind.
Good news is I just received confirmation from one of the ops guys. He says they know about it, and are working on a fix. :)
http://wiki.nginx.org/HttpSslModule
As for Github, could just be a misconfiguration, or perhaps they had some more deliberate reason in mind.
Good news is I just received confirmation from one of the ops guys. He says they know about it, and are working on a fix. :)
Awesome, GitHub ops on it. :) Curious if there will be a speed improvement once they enable session resumption.
Any idea why the default in nginx is: none. Soft off: nginx says to a client that session can be resued, but nginx actually never reuses them. Seems like a bad default to not cache.
Any idea why the default in nginx is: none. Soft off: nginx says to a client that session can be resued, but nginx actually never reuses them. Seems like a bad default to not cache.
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.
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.
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.)
Most Google sites (less so lately since there is more Ajax), craigslist, reddit of 4 years ago, HN of 2 years ago. Basically all the bare-bones content-driven sites, since people tend to write JS and CSS in a way that makes the site at least 100% slower.
Amazon is pretty decent. Their full page loads are slow, but they concentrate on above-the-fold time which is OK. I don't use Facebook much, but I think they have pretty good latency.
I think Microsoft's new mail is pretty fast but I haven't used it much.
I would say 1.x seconds for initial HTML is average. And 3-4 seconds for the full page with all assets is average. Github is in the 3-4 seconds range for onload time.
So Github is not particularly bad -- it's just average. It's certainly not "fast".
I feel like Github's perceived latency is pretty bad. I think they end up showing spinners and redrawing various parts of page to try to hide latency, but it makes it seem janky to me.
Amazon is pretty decent. Their full page loads are slow, but they concentrate on above-the-fold time which is OK. I don't use Facebook much, but I think they have pretty good latency.
I think Microsoft's new mail is pretty fast but I haven't used it much.
I would say 1.x seconds for initial HTML is average. And 3-4 seconds for the full page with all assets is average. Github is in the 3-4 seconds range for onload time.
So Github is not particularly bad -- it's just average. It's certainly not "fast".
I feel like Github's perceived latency is pretty bad. I think they end up showing spinners and redrawing various parts of page to try to hide latency, but it makes it seem janky to me.
I think we at YouTube think our site loads pretty fast.
Strange, Github is blazing fast in my experience.
Bitbucket on the other hand is insanely slow, especially in the source browser. That said, I gladly tolerate it due to unlimited free private repos and a decent feature set.
Bitbucket on the other hand is insanely slow, especially in the source browser. That said, I gladly tolerate it due to unlimited free private repos and a decent feature set.
Wow, those are some of the nicest reporting tools I've ever seen. Usually any application that involves measuring metrics like page load, average response times and whatnot looks horrible. It might be a small thing, but wow the design of that dashboard is really nice.
Github are absolutely killing it right now.
Github are absolutely killing it right now.
The performance dashboard and mission control bar look amazing. Would be great if they could be open sourced. :)
Take a look at https://github.com/nesquena/query_reviewer (if you're using MySQL).
[deleted]
You can also take a look at Rack MiniProfiler http://samsaffron.com/archive/2012/07/12/miniprofiler-ruby-e...
This is how they keep an eye out for slow pages. This isn't how they keep the site fast. :(
I find myself saying this a lot, but the Github guys do really cool work and whenever I see something new from them, I just want to get home and code.
Reminds me of http://www.codinghorror.com/blog/2011/06/performance-is-a-fe... :
"The simple act of putting a render time in the upper right hand corner of every page we serve forced us to fix all our performance regressions and omissions. [...]
Most of the performance fixes were trivial, and even the ones that were not turned into fantastic opportunities to rearchitect and make things simpler and faster for all of our users."
Stackexchange open sourced their profiler at http://miniprofiler.com/ (.NET & Ruby)
The post provides some data showing how they improved their site performance over time where Github just states they have a strategy to use "powerful internal tools that expose and explain performance metrics". Guess it's just common sense now.
"The simple act of putting a render time in the upper right hand corner of every page we serve forced us to fix all our performance regressions and omissions. [...]
Most of the performance fixes were trivial, and even the ones that were not turned into fantastic opportunities to rearchitect and make things simpler and faster for all of our users."
Stackexchange open sourced their profiler at http://miniprofiler.com/ (.NET & Ruby)
The post provides some data showing how they improved their site performance over time where Github just states they have a strategy to use "powerful internal tools that expose and explain performance metrics". Guess it's just common sense now.
The mission control bar looks very familiar. Although I can't remember the name of it now, I seem to remember there being a debug bar of sorts that worked with merb/rails projects that had the same type of look. Anyone remember the name of it?
Edit:
I was thinking of FiveRuns Tune-Up toolbar.
Edit:
I was thinking of FiveRuns Tune-Up toolbar.
Maybe your thinking of the old FiveRuns Tune-Up app. I used that all the time when I was doing early rails projects. They got bought and shut down awhile ago but I found an old TechCrunch article on it.
http://techcrunch.com/2008/05/29/dont-debug-alone-with-fiver...
http://techcrunch.com/2008/05/29/dont-debug-alone-with-fiver...
I think it is (I remembered the black bar too).
It seems to be there (but not updated):
https://github.com/fiveruns/fiveruns_tuneup
It seems to be there (but not updated):
https://github.com/fiveruns/fiveruns_tuneup
That is indeed it. I had just found it too.
Rack Bug? https://github.com/brynary/rack-bug
It was not rack bug. I'm having trouble finding it. I think the company that released it was bought or closed shortly after.
Django debug toolbar?
Rack::Bug?
Now that Github is fast and beautiful, I personally hope they make it fast in Japan.
Is it me or the new feature that hasn't shipped they mentioned is the source code search input box next to the download button?
- Public repo search.
- Main search box says "Search or Type a Command"
- Heartbeat icon in main navigation.
- Compass icon in top right user navigation.
- Advanced search button is now an actual button.If so, that would be incredible. More than once I've found myself wanting to search a repository for a specific word or variable without downloading it and acking through it.
You can actually do that already. Just go to github.com/user/repo/search
So: https://github.com/rails/rails/search
So: https://github.com/rails/rails/search
I believe GitHub admins have that little search bar on every repo, while regular joes can only search private repos.
You can search the contents of public repos from the main search box (https://github.com/search has instructions on how), and the search bar on private repos is only intended as a workaround for the main search not working for them. I have no idea how it's taken them this long to figure out that the repo-specific search box is far more user-friendly and discoverable.
I thought it might be the "tags" panel - a way to organize your watched repos?
That's actually a list of git tags (http://learn.github.com/p/tagging.html), and they're on the current site, e.g. https://github.com/thoughtbot/factory_girl/tags
oops.. wishful thinking!
[deleted]
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.
"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.
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 10 minutes of actual focus) and think to myself: "If that were me, I'd feel like I was just goofing off"
Get the information there. Make sure its nice and and usable. This does more than that though, which is great. I personally just would feel like I was wasting time and energy worrying about picking a color scheme when I had other work to be done.
Third thought: I appreciate the romantic justifications mentioned in the replies. I think they're fairly superficial, but they are romantic, and thats fine. I think the real difference here (and the root of the disagreement) has to do with why I associate this with 'waste of time'. There is obviously opportunity cost of doing this. I expect people most in favor of this stuff are salaried and not really concerned with opportunity cost. If I were salaried, I wouldn't feel like I was doing something wrong by doing this work because I'd do in in addition to my other work. I'd stay late and do it because I enjoyed doing it. I don't have that luxury where there isn't much opportunity cost because I'm paid by the hour. I don't work over-time. I'm not going to spend an extra hour at work one day to take care of this, so if its going to get done, its going to have to be prioritized over my other work. If picking colors (however important it is) is the most important thing on my to-do list, I have a problem.
TLDR: I'm paid by the hour. Thats probably why I feel this way.