josephscott

That is the theory. The real world however can be very messy. More than two years ago Khan Academy measured how this would work for them - http://engineering.khanacademy.org/posts/js-packaging-http2.... - here was their summary:

> The reality is not so rosy. Due to degraded compression performance, the size of the data download with individual source files ends up being higher than with packages, despite having achieved 'no wasted bytes'. Likewise, the promised download efficiency has yet to show up in the wild, at least for us. It seems that, for the moment at least, JavaScript packaging is here to stay.

My personal experience has been you have to confirm the theory of how HTTP/2 related changes will perform with actual measurements. I've seen some pages get faster in HTTP/2 by no longer bundling, and in other cases seen then become slower. So far the only way to know for sure is to measure the result.

I'm surprised to see webpagetest.org left out of the list of suggested tools.

Crunchbase[0] lists the previous funding total at $539.95M over 9 rounds. This would bring the total to $789.95M.

https://www.crunchbase.com/organization/slack#/entity

"airlines currently make a little money"

Your definition of "a little money" and mine are very different. The three largest US airlines ( American, Delta, and Southwest ) each had net incomes over $2 billion for 2016.

American: $2.6 B Delta: $4.3 B Southwest: $2.2 B

Even more fun, they have a minimum salary as well - http://basketball.realgm.com/nba/info/minimum_scale

And the blog post about this from Jeff Barr - https://aws.amazon.com/blogs/aws/now-open-aws-canada-central...

I like that FreeBSD dedicates a man page, HIER(7), on this topic - https://www.freebsd.org/cgi/man.cgi?query=hier - "layout of file systems"

Of the 30,699 shots, he missed 16,966 and made 13,731.

At the smallest level of performance it is nice to see that you can fail more often than you succeed and still be very successful over all.

Perhaps it would have better been described as 'The longest single confirmation process in history'. In terms of the whole replacement process, where it included candidates that were rejected, there have been times over 125 days ( as you mentioned ).

Raw data is available at http://www.senate.gov/pagelayout/reference/nominations/Nomin...

You are correct, I missed that one.

Eyeballing those charts it looks like @scottgonzales scores the best, followed by @cowboy.

<blockquote> Of course JSON has one (literally, one) tremendous advantage - it's human readable. </blockquote>

I was surprised he didn't mention ease of use inside JavaScript.

If you are searching for this in the app store, try searching for "Photo Find Ganotis". When I searched for "Photo Find" it matched like 1,500 apps, and gave up looking in those results.

Everyone at Automattic is remote, from the hiring page linked to in the list:

"Everyone works from their own home or office, and we’re spread out all over the world"

I did not know this before, very interesting.

Despite the easy access as a global variable, using document.getElementById() turns out to still be faster - http://jsperf.com/id-vs-class-vs-tag-selectors/328

"with just 25 servers"

This really needs to stop. Go to stackexchange.com and you'll find that more than half of the HTTP requests are to cdn.sstatic.net.

Looking up the IP addresses for cdn.sstatic.net returned five entries for me, all owned by CloudFlare. None of the CloudFlare servers that they are using seem to be in that 25 count.

Sure, these are all for static assets, that isn't the point. There are way more than 25 servers being used to serve the StackOverflow sites.

This is called spam and we certainly don't need more of it.

One of the big problems with doing 60 hours every week is that it leaves no buffer for emergencies. If normal weeks are roughly 40 hours, then when an emergency comes up you can usually make room to absorb that.

That means emergencies can't be every week.

Increasingly, young tech talent wants to live and work <strike>in cities.</strike> remotely.

The problem with using average for many performance stats is that it hides issues. There is a great paper on the topic - http://method-r.com/downloads/doc_details/44-thinking-clearl...

It is only about 13 pages, making it a quick but very informative read. I highly recommend it for anyone trying to measure performance, throughput, response time, efficiency, skew and load.

This is great news. Unfortunately downloading my Gmail content isn't listed as an option. I hope this isn't another case of Google App accounts not getting new features.

Space Monkey - http://www.spacemonkey.com/

Takes the distributed backup idea to the n-th degree.

The problem isn't distributed vs. centralized commits, it is infrequent and large commits vs. regular and smaller commits.

The fact that Subversion does that in one step, compared to two steps in Git doesn't really matter.

In some ways Git makes the problem of large, infrequent commits worse because of the ability to track local commits.

I'm not sure if he would qualify on the exact metrics mentioned, but certainly in the general sense: Fred Wilson, http://www.avc.com/

I wonder if this played into Ballmer leaving. Odd to have a massive re-org and massive purchase, only to have the CEO turn around and leave right afterwards.

Stating that one approach or the other is always the right way is the problem. Figure out which one works best for the type of site you are working on.

How your site will be used is often a high level indicator of which approach will provide a better experience for your users. Gmail for example, no public part of the site, not uncommon for users to leave it open in a tab all day. Often great for all Javascript approach.

Twitter on the opposite end. Lots of public facing pages, performance was worse when they required Javascript just to render 140 characters on the screen. This style of site is generally better off with a progressive enhancement approach.

I asked in the comments if Google has "100+ full-time engineers working on security and abuse and fraud". The implication from the article is that they do, but it doesn't actually say that they do.

Not sure why this is being covered again. The patent is from last year. There were plenty of articles about it back then, here is one - http://www.zdnet.com/apple-patent-could-remotely-disable-pro...

I was disappointed to see that they limit the password length to 30 characters. Perhaps one of the exercises should be to hash passwords that are longer than 30 characters.

Bcrypt will support up to 72 characters. If you are going to limit the password length I'd expect it to be something closer to 72 than to 30.

Spoken like someone who has never looked at any of the other stuff that Brett Slatkin has worked on. PubSubHubbub to name just one.