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…
How we keep GitHub fast
111–120 of 124 posts
Re: How we keep GitHub fast
#112Earlier quoted context omitted.
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
#113Should 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
#114Should 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…
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.
Re: How we keep GitHub fast
#115Should 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 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.
Re: How we keep GitHub fast
#116Should 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 c…
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.
Re: How we keep GitHub fast
#117Earlier quoted context omitted.
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.
http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-hap...
Re: How we keep GitHub fast
#118Earlier quoted context omitted.
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.
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.
Re: How we keep GitHub fast
#119"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.
Re: How we keep GitHub fast
#120Earlier 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
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.
(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.)