The GDPR as accidentally explained by people in the US - <AUTHOR> https://hroy.eu/posts/gdprExplainedByUS/ <comment><USER2> Main problem with GDPR criticism and press reporting about GDPR is that virtually all of it is based on second-hand knowledge and hearsay. I would really suggest to get the official PDF and read it. It is readable (for a legal text) and immediately clears up lots of common misconceptions like e.g. the collection/use confusion.

Pick your favourite language [https://eur-lex.europa.eu/legal- content/EN/TXT/?uri=CELEX%3A...](https://eur-lex.europa.eu/legal- content/EN/TXT/?uri=CELEX%3A32016R0679)

<comment><USER3> I had to study up on GDPR for a past job, and after reading the full thing several times over combined with reading various people's interpretations of it, I came away feeling like it was a generally sane piece of legislation that was overall reasonable about the trade-offs and requirements it imposed.

Since then I've heard many people complaining about the effort required to deal with or work around GDPR constraints, including in one case a data scientist complaining about needing to get consent to use certain data sources for something that wasn't the product being sold to the user. Frankly, I was happy about it, because that's _privacy working as expected._

<comment><USER4> This has been exactly my experience. As a data scientist (not a lawyer!) I had to ensure that some of our existing data processing pipelines complied with GDPR (and make sure we could comply with its reporting requirements.)

I found the Articles well-structured, easily understandable, and overall plainly reasonable. In my experience, those who complained about the 'bureaucratic overhead' of making their pipeline compliant were those who were in charge of processes that clearly violated the spirit of the law, trying to press them into the letter of the law somehow.

</comment></comment></comment><comment><USER5> This article is written very strangely. For example

> One last bit: Richard Stallman argues that "improving efficiency" of a > system must not be a justification for collecting personal data.

> Article 5(1) already provides that personal data must be "collected for > specified, explicit and legitimate purposes." Therefore, it seems that > Richard Stallman's interpretation of this principle means that "improving > efficiency" may never be considered legitimate. Do you agree

What is the author trying to say here? Its honestly confusing. Is he trying to say that Stallman's point about the law allowing broad collection of data is wrong? Or is he trying to say Stallman is being unreasonable in his demands of the law?

<comment><USER6> Improving efficiency could mean anything, efficiency of what? It's the thing being made efficient that needs to be evaluated for appropriateness, so I'm with Stallman on this (an infrequent but not unknown occurrence).

<comment><USER7> The problem with requirements to be explicit is that they just turn into dense legalese. You say "efficiency of what" thinking they're going to list a specific thing, but then they list every specific thing. Is it software or hardware? No, software and hardware. Is it efficiency in runtime performance or in user interface behavior? Both.

Asking animal, vegetable or mineral doesn't actually make it more specific if they can still get to "all of the above" by just listing every option individually.

<comment><USER6> That's easy. If the justification isn't clear, then the answer is No. It's their responsibility to provide a clear and valid justification.

</comment></comment></comment></comment><comment><USER8> I always chuckle when I see comments made. You can feel that they don't understand the concepts behind laws like the GDPR. Also they don't understand principles based regulation.

</comment><comment><USER9> Has gdpr been enforced at all since inception? Is there a public listing of cases and punishments?

<comment><USER10> Yes to both questions: [https://www.enforcementtracker.com/](https://www.enforcementtracker.com/)

</comment></comment><comment><AUTHOR> The full title is

"The GDPR as accidentally explained by people in the US who criticize the GDPR for its pitfalls, while calling for what's actually in the GDPR"

but HN doesn't allow titles to be that long.

<comment><USER11> I'd argue a better title would be "The EU GDPR _as understood_ by Americans".

The current title seems to imply an authoritative, true explanation of the GDPR by Americans, while the article is all about how the GDPR is frequently misunderstood on the other side of the pond.

<comment><USER12> Hi - author of the post here.

The points in the post are really about GDPR _basics_. I'm not actually trying to explain or interpret anything. Instead, I am mostly paraphrasing, if not merely quoting the GDPR directly (and linking to the authoritative source - check for yourself).

The more blatant example is probably the first one, about "data use" v. "data collection".

There's just no way that the statements about GDPR "missing the point of data collection" can be characterized as a misunderstanding of the text itself. The text has explicit references to data collection all over, including in the definition of the most important word, i.e. "processing".

So I think that, as these examples show, it's not really about misunderstanding on the other side of the Atlantic. I think it's more about baseless misconceptions and myths being thrown out here and there. Ask yourself: Why?

 _Edit: typos_

<comment><USER13> So I have asked myself: why? But after 10 minutes I didn't come to a conclusion :) so could you share what you're after or give me a hint? Are you suggesting there's an anti-EU/anti-GDPR/anti-whatever campaign of sorts going on that makes people biased, or, more realistically, an intent to discredit GDPR by US advertisers who fight against similar legislation in the US? That may very well be the case, but I haven't noticed on HN specifically where the pro-GDPR camp seems to be (slightly) in the majority if I'm not mistaken. Or maybe you're criticizing snake oil businesses selling GDPR compliance solutions which aren't (as discussed elsewhere in the thread), betting on people being too lazy to read the GDPR when the GDPR law text is quite understandable as you rightly point out? Genuinely don't understand the general direction of your suggestion.

<comment><USER14> > Are you suggesting there's an anti-EU/anti-GDPR/anti-whatever campaign of > sorts going on that makes people biased, or, more realistically, an intent > to discredit GDPR by US advertisers who fight against similar legislation in > the US?

I mean, in one sense, _obviously_. Most of the fearmongering around the GDPR comes from the ad industry (and to some extent from other impacted industries like the shadier parts of the debt collection industry, but they're much smaller and less noisy). I doubt there's an origanised conspiracy to discredit it as such, but most of the anti-GDPR talking points do ultimately come from the ad industry.

And this isn't that surprising, arguably. For most companies, the GDPR essentially means, at most, "your business model is fine, but your process is flawed; fix it". For large parts of the ad industry, it means "your business model is flawed; change it". Note that a lot of the ad industry complaints are around consent; either that it has to be asked for in the first place or that it's too hard to give accidentally. Well, yes, that's the point.

</comment></comment></comment></comment></comment><comment><USER15> This is kind of silly. The title implies "... by dumb Americans." Sure, GDPR applies to more than just EU citizens, but why would you expect Americans to know about it in the first place? It might be more interesting to here how EU citizens explain it, or how EU citizens explain driving on the opposite side of the road.

<comment><USER16> > It might be more interesting to here how EU citizens explain it, or how EU > citizens explain driving on the opposite side of the road.

There are only three countries remaining in the EU that drive on the left side of the road: Ireland, Cyprus, and Malta. A very small minority of EU residents could "explain" driving on the left side of the road, whatever that means.

<comment><USER17> .. and those are entirely down to the British influence.

<comment><USER10> Although to be fair Sweden drove on the left without British influence until other countries influenced them to change.

</comment></comment></comment></comment><comment><USER18> Weird article. After reading it I agree more with the points it's trying to refute.

You can't use the existence of a 1995 law to prove the GDPR doesn't have problems. The whole reason the GDPR got written was because the 1995 law was ineffective.

The GDPR adds new requirements on top of the 1995 law. Privacy advocates don't think these requirements help privacy much. Businesses claim that it makes it harder to do business (but they say that about any legislation). You can argue about who is right but neither side particularly likes the regulation.

The biggest group of people who do like the regulation seem to be EU citizens who want a reason to feel superior to Americans. It's unfortunate nationalism. We're all on the same side against the large corporations.

<comment><USER7> > Businesses claim that it makes it harder to do business (but they say that > about any legislation).

To be fair, it tends to be true of any legislation. Even if all you're doing is passing a law ordering them to do what they were already doing, now they've got to pay lawyers to tell them that and auditors on a recurring basis to make sure it continues to be true even if it would have regardless.

And then the cost of that gets passed on to customers and employees, because laws apply to everybody which means raising prices due to compliance costs isn't a competitive disadvantage when everybody does it. (Or they don't apply to everybody and give advantage to foreign competitors.)

The costs also disproportionately impact small businesses, because the compliance cost is a fixed amount whether you have a million dollars in revenue or a billion, so regulation is effectively the most regressive form of taxation. (Compare this to taxing Facebook and using the money to fund privacy-protecting open source technologies.)

<comment><USER19> +1 to all of this.

As someone who's been running small tech businesses in the UK for a while, I think it's also fair to say that the GDPR was unusually onerous even for government regulations. Over the past decade or more, only the VAT mess was comparable for anything coming out of the EU that I've been involved with. The similarities in those two cases are striking.

Each was meant to address a legitimate and well-established problem with how big businesses operate. Each also caused disproportionate expense and hassle for small businesses, even if those businesses weren't the intended targets and what they were doing was basically OK before.

Each had significant ambiguities that were either open to interpretation or missing key details, and so probably needed expert advice on compliance in many cases.

Each required businesses to change their record-keeping, documentation and processes for compliance, even if the substance afterwards was still much the same as before in each case.

Also, in each case enforcement seems unlikely for smaller businesses, so those who either didn't know about the new rules or wilfully ignored them gained an advantage over their competitors who were making a good faith effort to comply. I don't like good people being penalised just for trying to run their businesses legally and responsibly.

</comment></comment></comment><comment><USER20> > Time will tell how effective the GDPR is going to be [...] Nevertheless, we > should acknowledge the fact that EU law has got many of the foundational > principles around data protection right.

This post accidentally explains many Americans' issues with the GDPR. By focusing on intent and idealism to buttress justifications for the law's presence, proponents use righteousness as an excuse for heavy government interference. Almost everyone agrees with the ideals of data privacy. But recognizing reality, some advocate for not asking clearly ineffective institutions to police such things since often said technology laws and policing tend to hurt more than help. They also give a mandate for more government intrusion in technology (e.g. welcoming GDPR tacitly encourages the copyright directive) as policy makers can't help themselves. Rather, more measured approaches like education, consumer awareness, encouragement of alternatives, transparency requirements, and enforcement of existing statutes (fraud, personal info, etc) are leaped over.

Tech that people willingly trade info for (and arguably would do so regardless of awareness) is not analogous to food ingredients or medicine. You can't legislate every harm out of existence, and this is the fundamental difference in the two sides. One side is concerned with government oversight in these matters and where it leads, the other is not. Usually we'd say to each their own, yet we communicate on a global medium, so ideally we'd lean towards fewer restrictions (especially if you consider the legislative implementers on the American side).

<comment> vertex-four The way the EU usually works is that they say "we are concerned about X, Y and Z's effect on our citizens" to industry, and industry responds "we'll self- regulate to ensure X, Y and Z do not have the effect you're concerned about". If self-regulation doesn't work out, a directive is passed.

Industry, in this case, didn't even try to self-regulate, so a series of directives with gradually more teeth were passed over the last 20-odd years.

<comment><USER20> > If self-regulation doesn't work out, a directive is passed.

We can do better! Public education campaigns and support for alternatives for starters. The "they didn't fix the issues, so new laws will fix their issues" is myopic at the least, and potentially harmful if it doesn't fix the issues either.

<comment><USER21> What's myopic is expecting people to "do better" when they make more money (or even think they'll make more money) by doing worse.

<comment><USER20> Nobody expects that. It has become unfortunate that if you are not in favor for the GDPR as implemented, you must be against its principles and in favor of privacy-violating companies.</comment></comment></comment></comment></comment>


A Guide to Fast Page Loads - <AUTHOR> http://www.nateberkopec.com/2015/10/07/frontend-performance-chrome-timeline.html <comment><USER2> There's a lot of good advice here, but also some misinformation.

First of all, a script tag will block DOM construction, but in any sane modern browser will not block loading of subresources like stylesheets, because browsers speculatively parse the HTML and kick off those loads even while they're waiting for the script. So the advice to put CSS before JS is not necessarily good advice. In fact, if your script is not async it's actively _bad_ advice because while the CSS load will start even before the JS has loaded, the JS will NOT run until the CSS has loaded. So if you put your CSS link before your JS link and the JS is not async, the running of the JS will be blocked on the load of the CSS. If you revers the order, then the JS will run as soon as it's loaded, and the CSS will be loading in parallel with all of that anyway.

Second, making your script async will help with some things (like DOMContentLoaded firing earlier and perhaps getting something up in front of the user), but can hurt with other things (time to load event firing and getting the things the user will actually see up), because it can cause the browser to lay out the page once, and then lay it out _again_ when the script runs and messes with the DOM. So whether it makes sense to make a script async really depends on what the script does. If it's just loading a bunch of not- really-used library code, that's one thing, but if it modifies the page content that's a very different situation.

Third, the last bullet point about using DomContentLoaded instead of $(document).ready() makes no sense, at least for jQuery. jQuery fires $(document).ready() stuff off the DomContentLoaded event.

The key thing for making pages faster from my point of view is somewhat hidden in the article, but it's this:

> This isn't even that much JavaScript in web terms - 37kb gzipped.

Just send less script. A lot less. The less script you're sending, the less likely it is that your script is doing something dumb to make things slow.

[Disclaimer: I'm a browser engine developer, not a frontend or full-stack web developer.]

<comment><AUTHOR> > In fact, if your script is not async it's actively _bad_ advice because > while the CSS load will start even before the JS has loaded, the JS will NOT > run until the CSS has loaded. If you revers the order, then the JS will run > as soon as it's loaded, and the CSS will be loading in parallel with all of > that anyway.

Scripts without an async attribute will cause the browser to stop where it's at in the DOM and wait for the external script to download. The browser will not start downloading any stylesheets that come after the script tag until that's done. This is all straight from Google and can be verified in Chrome Timeline. [https://developers.google.com/speed/docs/insights/BlockingJS](https://developers.google.com/speed/docs/insights/BlockingJS)

> So if you put your CSS link before your JS link and the JS is not async, the > running of the JS will be blocked on the load of the CSS.

Downloading CSS isn't required to fire DomContentLoaded, so most browsers will download it in a non-blocking fashion. Chrome does not behave in the way in which you describe, which is shown plainly in the article. Again, this can be verified in Chrome Timeline.

All that said, I'm curious as to what browser engine you work when where what you said is the case - I don't doubt it, but you're not describing the way Chrome (and, I suspect, Webkit) works.

Right-o on the bit about DomContentLoaded, will fix.

<comment><USER3> There are two kinds of blocking that are easy to confuse. One is network: whether the browser will wait for a resource to _fetch_ before fetching another. The other is execution: whether the browser will wait for a resource to execute (which itself depends on fetching) before executing the next.

Script async controls the latter. WebKit (and consequently Chrome) have a "preload scanner" (you can Google for those words to find posts about it) that attempt to parallelize the former in all cases. That is to say, a <script> followed by a stylesheet should always fetch both in parallel. The "async" tag controls whether the browser waits for the script to finish loading and executing before rendering the rest of the page.

I think this is a relevant snippet of Chrome code:

[https://code.google.com/p/chromium/codesearch#chromium/src/t...](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp&q=preloadscanner&sq=package:chromium&l=364)

That's from the preload scanner, where it's deciding whether to fetch a URL referenced on the page. As far as I understand it this runs in parallel with any script execution blocking etc.

(Disclaimer: I worked on Chrome but never on this part.)

<comment><USER4> (Mostly agreeing, just adding some more)... I suppose theres 3 kinds of blocking really:

1\. Network blocking. Requests must wait until the previous one finished. Browsers in 2005 might have done this but not anymore. Even in terrible document.write() scenarios, browsers will still try to do additional work/requests.

2\. JS Execution blocking. The difference between [async] and [defer]. Browsers default to executing JS in order, which sucks if an early script takes forever to download. And layout/rendering is typically awaiting all this script to execute anyway.

3\. Render blocking. (Or technically, layout blocking). Can the browser try to display pixels before this script has finished downloading or executing? By default, it cannot, but an [async] attribute at least allows the browser to.

#2 and #3 definitely matter, with render blocking behavior usually being the most important. [async] and decreasing script request count are very good.

<comment><USER5> For #2 it's also worthwhile to remember that stylesheets block scripts, so it's not just scripts blocking other scripts.

</comment></comment></comment></comment></comment><comment><USER6> This guide is a comprehensive explanation of Chrome's Network timeline, but the optimisation recommendations are quite skewed towards the front-end. There's a missing piece on server configuration, no mention of CDNs or asset/domain sharding for connection concurrency, server-side or client-side caching. It also doesn't take into account HTTP/1 vs. SPDY & HTTP/2\. For example, loading JavaScript modules as individual files can improve performance for SPDY & HTTP/2, because changes in individual files don't expire the entire concatenated bundle. Here's a slide deck called "Yesterday's best practices are HTTP/2 anti-patterns", that re-examines some of Nate's advice: [https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD...](https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.p19)

<comment><AUTHOR> I wanted a guide that focused on the one thing all web developers have in common - the page construction process in the browser. We all use different servers, languages, etc.

HTTP2 will absolutely change a lot of how this works, you're right. I chose not to cover it as it won't be a real option for most developers until nginx supports it (still in alpha). The skills I'm teaching in the article re: the Timeline can still be applied when HTTP2 gains mass adoption, so you can test for yourself whether or not the recommendations in the article still make sense.

<comment><USER6> Okay. I'm pointing these out because it says Full-stack in the title.

Nginx servers can run SPDY until HTTP/2 is stable, or use an HTTP/2 capable proxy.

<comment><USER7> For those interested, the unstable (alpha) HTTP/2 element of NGINX is this patch for the 1.9.x mainline versions: [http://nginx.org/patches/http2/README.txt](http://nginx.org/patches/http2/README.txt)

</comment></comment></comment></comment><comment><USER8> Great technical details in this post. When speeding up page loads, I usually struggle with:

> You should have only one remote JS file and one remote CSS file.

I get this in theory, but it's difficult in practice. For example, this post has 7 CSS files and 13 JavaScript files. Also, combining all resources includes assets that aren't needed (CSS rules used on other pages), and also reduces the utility of public CDNs and browser caching.

<comment><AUTHOR> Ha, I should totally fix that. The site uses Jekyll, not Rails, which I'm used to getting the asset pipeline for free with!

Combining all the resources will include assets that aren't needed. Part of the reason I made the post about profiling with Timeline was so that you could test tradeoffs like this for yourself.

I don't know what you mean by reducing the utility of CDNs and caching though - surely having only one file actually increases the use of browser caching, since the browser will only make 1 request for CSS and serve the cached copy for every other page?

<comment><USER8> Agreed, it's all about tradeoffs.

On public CDNs- I mean public CDNs for common libraries (jQuery, Angular, Font Awesome) can improve page load time if a user already has the file. The more sites use the same public CDN, the more users benefit. But if a user doesn't have the file already, it's a loss. So, tradeoffs.

On caching- if you make one JS file and one CSS file for each page, then there is no caching between pages but only necessary info is downloaded for each page. You could make one JS/CSS file for your whole site, but then there are unused assets on each page, and it becomes more difficult to simplify CSS and could increase layout thrashing. Again, tradeoffs.

Really enjoying this discussion, thanks for taking the time to write this up. I have this debate in my head constantly.

<comment><AUTHOR> > On public CDNs- I mean public CDNs for common libraries (jQuery, Angular, > Font Awesome) can improve page load time if a user already has the file. The > more sites use the same public CDN, the more users benefit. But if a user > doesn't have the file already, it's a loss. So, tradeoffs.

Even this has a tradeoff - if, for example, the other JS on your page require JQuery, you can't make the CDN copy of JQuery use an "async" tag, because you can't be certain of the order the JS will execute. And if you're not using the async tag, the first load will suffer.

</comment></comment></comment></comment><comment><USER9> Pure HTML loads ludicrously fast these days—as in, well-nigh instantaneously. With a single CSS file, you can make it quite attractive. Eschew JavaScript unless you really, truly need it.

<comment><USER10> What website nowadays you do not ever truly need JS?

<comment><USER9> If you're displaying text, then you don't need JavaScript. If you're displaying images, then you don't need JavaScript. If you're displaying short animations, then in theory you don't need JavaScript (I don't know how widely support APNG is though).

If you're displaying movies, maybe you need JavaScript? I don't know if HTML5 video can work without JavaScript (it _ought_ to be able to, but lots of things which _ought_ to be _aren 't_).

If you're accepting user comments, you don't need JavaScript. Forms work just fine without it.

If you're accepting user votes, then you don't technically need JavaScript (but the experience will probably be better with it, unless you're smart).

Really, it's hard to see what one truly needs JavaScript _for_. Slowing down pages, sure. Destroying your readers' privacy, certainly. Getting root on your readers' computers, no doubt.

<comment><USER11> > Getting root on your readers' computers, no doubt.

Since when? The only JS privilege escalation is this Firefox vuln from 2008: [https://www.mozilla.org/en- US/security/advisories/mfsa2008-1...](https://www.mozilla.org/en- US/security/advisories/mfsa2008-14/)

<comment><USER5> Any RCE exploit can likely be combined with any other OS vulnerability to get privilege escalation.

</comment></comment></comment></comment></comment><comment><USER12> This is a useful guide, however there is one thing missing that will have an order of magnitude improvement over anything that is mentioned.

Use appcache (or service workers in newer browsers). Yes appcache is a douchebag, but its far simpler than going through all of these and will have a far bigger improvement

<comment><USER13> In my experience, appcache only improves _second_ loading time. You need all of these other techniques to improve _first_ loading time. 2nd time is much, much less important to optimize, because returning users have already gotten through the annoyance filter, know what they are in for, has at least subconsciously accepted the necessity of the load time they experienced the first time. It's nice they won't have to experience it a second time, but if first-time loading is very long, your second-time users are going to be much fewer.

I had written quite a bit here on the sorts of things that I do to make very short time-to-first-view sites, but basically the techniques all fall in place if you setup Google Analytics and use their Page Speed Suggestions. You should be able to get to 95% on mobile, 98% on desktop (I lose points on some 3rd party scripts I've included for order processing, so I can't get around it.). It will be a bit difficult your first time, but after that you will know what all the tricks are and future sites you will just make "right" the first time.

<comment><USER14> Confused; won't the second _user_ experience faster page load with appcache?

<comment><USER15> AppCache is client-side; it caches a certain set of URLs in your browser so that they are available with no HTTP request. It doesn't work until your browser has hit the page once, downloaded the cache manifest, and saved the files.

</comment></comment></comment></comment><comment><USER16> Udacity has some really awesome free courses from Google devs about this: Website Performance Optimization[1] and Browser Rendering Optimization[2]

[1]: [https://www.udacity.com/course/website-performance- optimizat...](https://www.udacity.com/course/website-performance-optimization --ud884)

[2]: [https://www.udacity.com/course/browser-rendering- optimizatio...](https://www.udacity.com/course/browser-rendering-optimization --ud860)

</comment><comment><USER17> I really recommend "High Performance Browser Networking" book by Ilya Grigorik, it digs deep into the topic of browser performance: [http://chimera.labs.oreilly.com/books/1230000000545/index.ht...](http://chimera.labs.oreilly.com/books/1230000000545/index.html)

</comment><comment><USER18> One thing that might be non-obvious is that async script, while not blocking `DOMContentLoaded`, blocks `load` event.

It means that if you have listeners to `load` event that are doing stuff, you may want to have the `load` event as fast as possible.

Also, until the load event is raised, browsers display a spinner instead of page's favicon.

Hence for non-critical third-party scripts, you may prefer to actually inject them _in JS in onload handler_ instead of putting them directly in HTML.

A semi-related issue is handling failures of external non-critical scripts (analytics blocked by adblock etc)

I wrote a draft of a blog article on the topic last week:

[https://gist.github.com/jakub-g/5286483ff5f29e8fdd9f](https://gist.github.com/jakub-g/5286483ff5f29e8fdd9f)

Context: We've faced an _insane_ page load time (70s+) due to external analytics script being slow to load (yeah, we should have been loading the app on DOMContentLoaded instead of onload).

<comment><USER4> Since `load` waits for all iframes and images, you typically don't want JS initialization to be dependent on it.

For non-critical third-party scripts, you might actually want to do something like doc.on('DOMContentLoaded', e => setTimeout(requestIdleCallback(init3rdparties), 2000));

<comment><USER18> Hi Paul, thanks for sharing the `requestIdleCallback`, I didn't know it, pretty interesting! Though since it's only in Chrome 47+, it will take a while for it to gain market adoption.

</comment></comment></comment><comment><USER19> Spending the last 6 weeks in East Africa has completely changed my perspective on web performance. And it's not just performance, it's reliability. Every request a page can't work without is another chance to fail.

React/Flux and the node ecosystem are more verbose than I'd like, but they might be onto something by rendering the initial content server-side.

<comment><USER4> For sure. Rendering JS apps server-side is pretty much mandatory from a performance perspective.

</comment></comment><comment><USER20> Another small advice, but less generic, could be to not include all css and js libs of bootstrap, that is modular. I'm mentioning bootstrap because it is the standard de-facto of many web apps.

Just spend 5 minutes selecting only the packages that you really use inside your webpage, you can drastically reduce css and js file size

<comment><USER21> Doesn't this force you to build it yourself from the less files?

<comment><USER20> yes but the compilation of boostrap from sass or less is very fast.

</comment></comment></comment><comment><USER22> This is damn helpful! Thanks for sharing. If you're interested in getting to know more about how other sites perform and how to use chrome devtools to address frontend performance issues, Google developer - Paul Lewis recently started a series on Youtube called Supercharged. Here's the first episode - [https://www.youtube.com/watch?v=obtCN3Goaw4](https://www.youtube.com/watch?v=obtCN3Goaw4)

<comment><AUTHOR> I am heavily indebted to Paul Lewis and Ilya Grigorik's writing, which provided much of the source material in this article.

Anyone interested in further reading on the topic should check out anything by those guys, they're the foremost in the field.

</comment></comment><comment><USER23> On a static HTML site with no scripts or external resources, I see 100ms of loading/painting in the beginning, then 3000ms of "idle" time at the end, which turns the flame graph into a pixel wide column. What is the point of that?

<comment><AUTHOR> Something is delaying the load event. You'll have to dig deeper to see what's holding it up - probably a network request for an external resource.

<comment><USER23> No resources. Happens on example.com, too, fwiw. Weird. Oh, well.

<comment><USER24> Double-check that you're disabling extensions.

</comment></comment></comment></comment><comment><USER25> I've had great success in the past doing one very simple thing: on first load send the client the exact html/css that must be loaded on their screen.

Once the page is loaded, use javascript to take over updates (using framework of choice).

It worked great in 2008, hopefully the modern javascript developers can now reinvent the wheel. It'll be a lot easier nowadays what with Node/V8 meaning you can use the same code...

</comment><comment><USER26> This is a really nicely put together article, and I'll even admit the animated gifs are funny, but damn if they don't make it impossible to focus on reading the text.

</comment><comment><USER27> Surely the first bit of advice in any post about analysing website performance should be: __USE WEBPAGETEST __

It gives you access to everything Chrome dev tools do, plus so much more:

      * speed index as a metric for the visual perception of performance
      * easy comparison of cached vs uncached results
      * operating on median metrics to ignore outliers
      * side-by-side video playback of compared results
      * different user agents
      * traffic-shaping
      * SPOF analysis
      * a scriptable API
      * custom metrics

I could go on. There's a lot of excellent performance tooling out there but WebPageTest is easily the most useful from my experience.

<comment><USER28> > It gives you access to everything Chrome dev tools do, plus so much more:

Can WebPageTest (I've never heard of this tool) reach pages that require authentication?

[http://www.webpagetest.org/](http://www.webpagetest.org/)

<comment><USER27> It can, using either basic auth or by scripting submission of login forms.

Probably obvious, but you should avoid doing it from one of the public instances. Building your own private instance is as easy as spinning up a prepared EC2 image, or if you have a couple of hours to fiddle about you can do it from scratch on any Windows machine. Details here:

[https://sites.google.com/a/webpagetest.org/docs/private- inst...](https://sites.google.com/a/webpagetest.org/docs/private-instances)

</comment></comment></comment><comment><USER29> I have been using AppTelemetry plugin for rough numbers on each phase of request. This is much better for performance tuning.

Do you have any tips for optimizing PHP, where server response times are poor to begin with? I've been trying to optimize a blog as proof-of-concept[1] but it has plateaued at 1.5s load time.

[1] [http://wpdemo.nestifyapp.com/](http://wpdemo.nestifyapp.com/)

<comment><USER30> You are probably not going to get decent response times with PHP, especially if you're using a framework. If you've already taken care of the basics (opcache, PHP7 or HHVM, WP-specific caching plugins, etc) you would have to settle for techniques such as nginx microcaching [1], which can drop your responses to around 10ms.

[1]: [https://thelastcicada.com/microcaching-with-nginx-for- wordpr...](https://thelastcicada.com/microcaching-with-nginx-for-wordpress)

<comment><USER29> Wow. Microcaching reduced response time from 25 ms to 3 ms. Thanks!

</comment></comment></comment><comment><USER31> Gratuitous plug, my startup, [https://rasterize.io](https://rasterize.io), will give you most of the information in the chrome timeline, for every single visitor to your site. It also analyzes the page and detects a lot of these warnings, and alert when you introduce things that slow the page down.

It's in beta, but contact me if you're interested.

</comment><comment><USER32> Any tips on how to handle site layouts that depend on the js that is asynchronously loaded via the async attribute? Seems like this can cause a flash of unstyled/unmodified html while that js is loaded and executed.

<comment><USER33> Use CSS to hide the unstyled content, and then JavaScript to remove that styling and display it. This will, of course, invoke the ire of those who browse with JavaScript disabled.

<comment><USER34> How I did it is begin with .no-js class and using Modernizr to remove the class so I can style element for .no-js .my-class -> visibility: visible and .my-class -> visibility: hidden then finally using JS to remove visibility css.

So if .no-js class is available (when browser disabled JS), .my-class element still visible.

If .no-js is not available (when browser enabled JS), .my-class element will be hidden and visible by your JS

See [http://stackoverflow.com/questions/6724515/what-is-the- purpo...](http://stackoverflow.com/questions/6724515/what-is-the-purpose-of- the-html-no-js-class).

</comment></comment></comment><comment><USER35> Could anyone explain like I'm 5 what "layout thrashing" is? As far as I understand, it's when the size of an element is set in the CSS, like

        div {
            width:100px;
        }

Then later in the CSS it's changed to

        div .biggerdiv {
            200px;
        }

Or maybe it's javascript that changes it:

        $('.biggerdiv').style('width:200px;');

but either way it's when an element has some size near the beginning of rendering, then as more information becomes available, it has to change size a few times.

Am I getting it?

<comment><USER36> Layout thrashing is when the browser layout engine does some work to render the page, but then something changes and it has to do it over again. A typical case is if you have a loop in javascript wherein you both read and write to the dom. For example, if you change the css style of an element and then afterwards try to read its position property. Because changing the style might have affected the position, the browser will have to render parts or whole of the page in order to give you that information. It's a very easy mistake to make and it's not obvious what you have done if you don't look for it.

And in the context of page load, it would be if the dom is changed in many different places (So yes, your example would probably cause layout thrashing).

</comment></comment><comment><USER37> Potentially dumb question from a backend dev:

Is there a way to get stats about page loading from Timeline, that could be used to automatically ensure that the load times are not creeping up, and breaking NFRs?

<comment><AUTHOR> Sure, check out the Navigation Timing API: [https://developer.mozilla.org/en- US/docs/Web/API/Navigation_...](https://developer.mozilla.org/en- US/docs/Web/API/Navigation_timing_API)

</comment></comment><comment><USER38> Could someone explain this paragraph? I feel like it is making a lot of assumptions or generalizations about the use of $(document).ready();. I do not follow what he is trying to say:

> Web developers (especially non-JavaScripters, like Rails devs) have an awful > habit of placing tons of code into $(document).ready(); or otherwise tying > Javascript to page load. This ends up causing heaps of unnecessary > Javascript to be executed on every page, further delaying page loads.

<comment><USER38> Nevermind, he explained this again more clearly in the TL;DR.

> Every time you're adding something to the document's being ready, you're > adding script execution that delays the completion of page loads. Look at > the Chrome Timeline's flamegraph when your load event fires - if it's long > and deep, you need to investigate how you can tie fewer events to the > document being ready.

</comment></comment><comment><USER39> Can someone explain his point about $(document).ready()? I don't understand how it is different from DomContentLoaded?

jQuery source for the ready function: [https://github.com/jquery/jquery/blob/c9cf250daafe806818da1d...](https://github.com/jquery/jquery/blob/c9cf250daafe806818da1dd207a88a8e94a4ad16/src/core/ready.js)

</comment><comment><USER40> Question about the 1 CSS/JS file rule.

If you have a 'My Account' section w/several unique rules (say 10k), which is best? A) One website CSS (main.css) and your users download the My Account rules even though they may never use them B) 2 CSS files are used for My Account (main.css and myaccount.css) C) 1 file under My Account that incorporates the main and section rules (main-plus-myaccount.css)?

<comment><USER41> In the case of 10 Kb files those approaches won't make any noticeable difference. But when you have large code bases consider how often changes would be made to them: in most cases it is sensible to split your files into two bundles — one for libraries or files that are not going to be updated any time soon, and the other for project-specific code, that is very likely to be tweaked in the course of the time following the release of the project. Thus you leverage caching and don't force the users to download the whole CSS or JS codebase every time you make some small adjustment.

</comment></comment><comment><USER42> "JS and CSS assets must be concatenated"

that is fine if you have a tiny little site. If you are a big company, each micro site will use a piece of the larger set of files. if one use a,js b.js and c.js, when you concatenate you just lost 100% of cache if the user clicks a link to a side of the site that only uses b.js and c.js

likewise, try to load, un-concatenated, common libs from widely used free CDNs.

</comment><comment><USER43> I like this guide, with the caveat that, if you are doing a single page web application, some of it gets turned upside down.

For instance, the "javascript will be loaded on every page load" part no longer applies. It will be loaded only once, and will fech whatever it needs from then on.

</comment><comment><USER44> Regarding layout-thrashing: if only there were a way to hint the dimensions of each element.

</comment><comment><USER45> Gifs in the sidebar, 10/10

<comment><USER46> Only the first cycle. After that they're 0/10.

</comment></comment><comment><USER10> The best explanation of the timeline tool I've ever found. Thank you!

</comment><comment><USER47> Very helpful stuff but I did go to The Verge and look under the timeline. Scripting was a fraction of 1% of the load time. Have they disabled it because of your article or am I missing something?

<comment><AUTHOR> Hmm, you must be. Here's my timeline for theverge.com: [http://imgur.com/SOpXFZc](http://imgur.com/SOpXFZc)

Steps: go to theverge.com, open Timeline. Hit CMD-SHIFT-R for hard refresh, which will automatically trigger timeline. Wait. When the load event fires, Timeline will stop recording.

<comment><USER47> Ouch - OK, now I got it. Yeah that's terrible. Scripting is double loading, rendering and painting combined.

</comment></comment></comment><comment><USER48> LOLZ @the layout thrashing gif! Nice post though, very informative.

</comment><comment><USER49> Thanks - a well-written article with some really helpful pointers.

</comment><comment><USER50> ...and if you do HTTP/2, you'll get even faster loads if you pretty much break all those rules (some notable exceptions).

<comment><AUTHOR> True, but that's a post for another day. We've still got another year or so until HTTP/2 gets mass adoption.

<comment><USER51> Except SPDY has been out for a while so why would anyone have been or continue to wait?

</comment></comment></comment><comment><USER52> >While I use New Relic's real user monitoring (RUM) to get a general idea of how my end-users are experiencing page load times, Chrome Timeline gives you a millisecond-by-millisecond breakdown of exactly what happens during any given web interaction.

New Relic does, too! Its a Pro feature called Session Traces.

</comment><comment><USER53> >47 requests, 7.474,76 KB, 4,68 s

That's on a 100Mbit connection.

</comment><comment><USER54> the page it's too slow to load... i waited solid 5 minutes... and... still... nothing... to... see...

</comment><comment><USER55> "bare-metal Node.js"

</comment><comment><USER56> That was awesome- thanks!

</comment><comment><USER57> Had to disable the font of the website, it's terrible for reading.

<comment><AUTHOR> I wish I could find a font everyone liked that isn't Helvetica :(

<comment><USER57> That's not the problem. When I view on a Apple device it looks good. I use Windows 10 at home and I just couldn't read it.

</comment></comment></comment><comment><USER58> Google just came out with the AMP project. It looks like google is encouraging publishers to join its initiative in the same way how it herded everyone to get "responsive". At the end of the day, good news for mobile web - [https://techbullets.com/](https://techbullets.com/)</comment>


B-players overprepare, A-players take the emotional risk - <AUTHOR> http://www.bnet.com/2422-13723_23-184854.html

<comment><USER2> Interesting topic. The risk of emotional failure is perhaps the most important reason why many talented people don't do startups.</comment>


Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08) - <AUTHOR> http://axonflux.com/building-and-scaling-a-startup <comment><USER2> That is a very good article.

I'd suggest absolutely everybody with a web page read up as much as they can about optimizing web page loading. It doesn't matter if you're Posterous or you run your 2,000 daily visitors off a 256 MB VPS which is _never_ under load, optimizing the page can result in 90% decreases in the user-perceptible time it takes to load the page. It doesn't matter if you slave over a hot memcache to save 200 ms off the database queries if your page then takes 7 seconds to render.

Shaving off two seconds, one second, half a second just prints money. Every time I do it I'm flabbergasted by how much it matters.

The HTTP cache control mentioned in the article is one excellent place to start. For the rest, Yahoo pretty much owns this field of research -- any of the presentations from the YSlow folks are worth your time.

[http://www.slideshare.net/natekoechley/high-performance- web-...](http://www.slideshare.net/natekoechley/high-performance-web- sites-2008)

I'm kind of a lightbox junkie and I've had some good results recently by the simple expedient of having the browser preload the image (e.g. <img src="foo.jpg" style="display: none;" />) prior to the actual user interaction which calls it to display. There are a billion similar site-specific tricks you can do in Javascript these days.

<comment><USER2> Oh, one more link while I'm at it:

[http://www.slideshare.net/stoyan/high-performance-web- pages-...](http://www.slideshare.net/stoyan/high-performance-web-pages-20-new- best-practices)

The presentation I cited in the parent is more motivational and less stuffed with "Here is a checklist of actionable steps that if you implement will make you more money for each one you do."

</comment></comment><comment><USER3> I hate when people tell me that Rails doesn't scale because I have scaled Rails and it has nothing to do with the framework.

The reason why websites can't scale is ALWAYS the DB. To fix the DB it is always master/slave, memcached, then sharding. For EVERY language.

Good article, sums up a lot of the tools I used to scale my stuff.

I'd like to add a little more.

1\. Turn on slow-query logging in your DB and tail -f the slow query log. Find slow queries and kill them in your code through indices or using several fast queries to make up for 1 long-one.

2\. Cache most reads. Both from application caching and memcached.

3\. Turn off associations, they don't play well with caching.

4\. If you're using memcached, don't use the plugins.

5\. If you're a serious startup, use Engine Yard, they're life savers.

<comment><USER4> Rails running on vanilla Ruby does have particular scaling issues due to the limitations of the Ruby garbage collector. You hit a GC cycle after every 8MB of allocation, which typically takes around 150ms to run, so can dominate the runtime of your requests. We've had 80% of the runtime in GC, even when you include database time.

This isn't necessarily a killer, but it means there's sometimes more work than you might like in scaling. There are patches to tune the garbage collector, and JRuby etc. may help, but ultimately you need to be much more aware of memory allocation than you might think.

<comment><USER3> That's an application bottleneck which is fixed by more application servers. This has no effect on scaling what-so-ever.

And by scaling here, we're talking about 1 M to 10 M, not 10,000 to 100,000.

</comment></comment></comment><comment><USER5> Pretty good run down. Actually, a very good run down.

Sphinx is cool, but there's no reason to be afraid of solr/lucene. It takes _very_ little java knowledge to get it up and running and it's very very, really, crazy fast. Like, hundreds of thousands of searches a day on millions of documents and it's totally stable. _knocks on wood_

Also, Passenger is indeed better than all this mongrel + god + tweaks they're talking about it. AboutUs.org (my employeer) is the largest site on Passenger (that we can find) and we've had 2 actual crashes in the last 6 months, and they were fixed with rebooting Apache.

<comment><USER6> From my experience (and I have used Sphinx, Lucene, Solr and Xapian in production) is that Lucene/Solr have a pretty bad perfomance compared to Sphinx or Xapian.

My Lucene setup began to throw deadlocks and memory exceptions pretty early on. Searching on "deadlock lucene" on Google yields 25000 results. I have later rewritten the system to Xapian where it has run without any problems.

For live updates I would recommend using Xapian. For fairly static indexes I would recommend Sphinx (as it's _really_ fast for both indexing and searching, but it does not support live index updates yet).

<comment><USER5> Really? What size of index/documents where you doing searches on?

We're doing live updating, probably close to 1 update per second.

</comment></comment></comment><comment><USER7> > You're only as fast as your slowest query....

Use HAProxy. Take the time to configure it correctly. It's absolutely the most stable and useful loadbalancer I've used. It also solves this issue by talking to your backends.

<comment><USER8> We use pen, which can be configured to avoid this issue as well. Just specify the maximum number of connections to be the same as the number of backend servers (via the -x option), and it will queue connections beyond that number and hand them to the first backend that frees up.

We've had zero issues with pen, it's been rock solid, but we're still looking at moving to Passenger at some point: seems like it will be more flexible and efficient than our current pack of mongrels.

<comment><USER7> I attempted to switch to pen when I was having issues with Perlbal. It was segfaulting under light load (light for me is heavy for most people) comparable to Perlbal, so I switched back. I can't say I reccomend it at all.

</comment></comment></comment><comment><USER9> _Sad town happens. 1 in 4 requests after Request A will go to port 8000, and all of those requests will wait in line as that mongrel chugs away at the slow request..._

I don't use Rails, or even Ruby at all if I can avoid it, so I'm sure I'm missing something obvious here, but... why in the world would anyone want to use a web server which can only handle one request at once?

<comment><USER10> Sorry, what's the platonic ideal you're suggesting as an alternative? There are threaded Ruby web servers, but, just like with Python, the interpreter is mostly giantlocked. The overwhelming majority of web apps out there are running under Apache, which just like Mongrel is preforking and queueing, not running everything simultaneously.

<comment><USER9> If you have N requests hitting Apache and one of them is slow, that one slow request will run in its own process while the fast requests are sent off to other processes. The fact that each _process_ only handles one request at once is irrelevant.

<comment><USER10> Uh, this is how Rails setups work too. You aren't talking directly to Mongrel.

<comment><USER9> Maybe I misunderstood the article -- it sounded to me like requests were being distributed between Mongrel processes _and queued on the individual processes_ rather than being queued centrally and only allocated to individual processes when a process is free (like Apache does).

<comment><USER11> The problem with Mongrel is that you allocate N mongrel instances at setup time. Apache, on the other hand, can dynamically allocate new processes (up to a limit) in order to meet increased demand. This is especially important for people like me, who host more than one site on a machine, and want to be able to handle load up to a certain point without fiddling with config files every time there is a spike in traffic.

</comment></comment></comment></comment></comment></comment><comment><USER12> Great post with obvious real world experience behind it.

I think it's a fantastic point that you should focus on optimizing your database before you start adding caching. If you can tune your DB with the right indexes and give it enough RAM to fit the whole dataset, you've got a great cache right there!

(BTW, I have been using PostgreSQL on my latest project. I'm impressed so far. It has a much query optimizer and better indexes than MySQL.)

I also like using Solr/acts_as_solr. I haven't used Sphinx but from what I've read about setting it up it sounds incredibly fiddly. Solr, by contrast, is quite simple.

<comment><USER13> Have recently switched from using Solr+acts_as_solr to Sphinx+Thinkinh Sphinx I have found quite the opposite. Thinking Sphinx is simpler than Solr and required no 'fiddling'.

I had to work around some problems in acts_as_solr, such as it's tendency to automatically update solr as soon as a DB record changed (regardless if no fields that solr is indexing have changed). Thinking Sphinx simply updates it's index in a batch process that is called by cron (and is super fast!). I highly recommend it.

</comment></comment><comment><USER14> Rails scales just fine - the problem is that it's just really expensive to do it.

Here's some of our learnings:

1\. Use query_trace to trace your DB calls and query_analyzer to automatically run EXPLAIN on each call:

<http://github.com/ntalbott/query_trace/tree/master> <http://github.com/jeberly/query-analyzer/tree/master>

2\. Use our patches to mongrel proc_title to troubleshoot slow queries: <http://asemanfar.com/Request-Queue-via-Mongrel-Proctitle>

3\. Don't use ActiveRecord.

4\. Don't use any link or url helpers in Rails.

5\. For that matter, don't use Rails. Rewrite your most hit components in something faster.

I love Ruby, but the simple truth of it is that we'd be saving a couple of engineer's worth of money if we weren't on Rails.

<comment><USER15> I dunno about saving a couple engineer's worth of money -- that's why Rails is massively viable in the first place.

You absolutely can iterate faster with fewer people and less wasted time.

Servers are cheap. People (salaries) are expensive.

(Well.. until servers become expensive due to straight up load/scale, that is.)

<comment><USER14> Right now we're estimating that our Rails premium = 4X the salary of a San Francisco engineer. But we do have a lot of servers.

</comment></comment></comment><comment><USER16> I don't know jack about Rails, but there is some good general advise here too. I would have liked to see some DB commentary that didn't choose MySQL as a foregone conclusion. I can't think of many instances where I would recommend it in general.

<comment><USER17> May I ask what you do use exactly? MySQL has always been my goto for simple db needs. What do you normally use and what's your "general" cases where you wouldn't use it?

<comment><USER16> For "simple [rdms] needs" I would recommend SQLite. For anything more, PostgreSQL. I find MySQL too buggy and it diverts from the SQL standard too often (or doesn't implement enough of it) for my tastes. A properly configured postgre install (granted, not exactly trivial) will perform at least as good if not better than MySQL and its advanced functionality is extremely mature and robust, unlike MySQL's which has largely been tacked on in the current major version (views, templates, triggers, etc.)

</comment></comment></comment><comment><USER10> Great article.

Background/deferred job processing has been immensely painful for us, and I have no idea what the accepted best job queue is. We're still stuck on backgroundrb, which is a nightmare. Nanite looks like overkill, and has too many deps.

<comment><USER15> Workling has worked well for us -- Rany Keddo is a phenomenal open source guy.

Tobi's deferred jobs also looked totally solid to me. That one's proven because it drives Shopify. We use his liquid plugin, which is also stellar.

That underlines a big issue with Rails dev even today -- its really hard to know what's good / what works, and what is just some weekend project for someone.

<comment><USER10> Found Tobi's delayed_job (not deferred) --- I think I like the design better than Workling; fewer moving parts, just a database backend end a rake script. The biggest problem we have with backgroundrb (which again: nightmare) is not really ever knowing the state of current running jobs.

<comment><USER18> yeah backgroundrb sucks, who wrote that shit? (me and i wish i never did)

</comment></comment></comment></comment><comment><USER19> Great post, you discovered a bunch of the gotchas faster than we did on our first rails site. I wish I would have had a post like that a year ago. Thanks

</comment><comment><USER20> Can someone shed some extra light about the point re: reducing the number of requests to the DB for a dynamic page. When left unoptimized, Rails (and a lot of other frameworks) often result in 100 DB queries for a page.

One obvious way around this is to ensure the DB joins are done correctly. But the article mentions batching/grouping up the requests. How does that work?

<comment><USER15> Check out the :include parameter to find method calls in the ActiveRecord documentation.

Say you have 30 blog posts, and your views reference associations to the blog post's owners. Well, views are dumb and if you call post.user on each one within a loop, you end up calling User.find 30 times.

But if you do Post.find(..., :include => [:user]), Rails will know to eager load all users -- and User.find never gets called 10 times.

</comment></comment><comment><USER21> Great article! BTW, I was wondering what are the testing strategies used and how did you guys ensured smooth integration of features?

<comment><USER15> Rspec, Cucumber, Integrity, and a custom end-to-end testing process that runs using the daemons gem that assures all critical aspects of the site runs at all times.</comment></comment>


Poorly-written software makes 100 million+ DTD requests/day to w3.org - <AUTHOR> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

<comment><USER2> Poorly written software and a poorly written spec! W3C is responsible too for using a silly namespace identifier.

</comment><comment><USER3> Whoa. Jaw drops</comment>


Banning Wi-Fi From Schools - <AUTHOR> http://www.theness.com/neurologicablog/?p=2215

<comment><USER2> I am always surprised by people's lack of critical thinking capabilities. I saw Michael Shermer (founder of Skeptic Magazine) speak at a conference recently. It was a little frightening how much data he has on the irrationality of our fellow man.

The thing that frightens me the most is the areas I personally exhibit irrationality in _that I don't know about_. I'm actually OK being irrational if I know I am (I can make decisions taking that into account), but I have little doubt there are places that I don't know, where I make stupid decisions.

In the meantime, we should all turn off all our electric devices, wrap our houses in faraday cages, filter all of our water, and wear respirators. Wouldn't want to be unsafe, now would we?

<comment><USER3> > wrap our houses in faraday cages

Hmm... I am concerned that the big solar flare might come one day and usher the world into a new dark age... or at least a victorian period of about 20 to 30 years.

<comment><USER4> You'll have to cut your access to your power supply and go on generator (anything outside the faraday cage risks frying anything electrical inside), you'd also have to disconnect any groundings to pipework. Long runs of copper will be inducted during a huge flare, so the ground/earthing connections can at best knock off all your breakers and your generator, but at worse can surge from ground->neutral (frequently connected as a double safety) and fry things that way (note: I only heard of this happen from a lightning strike, but we're talking end-of-civilization-solar-flare here so it's worth note).

If you need internet ensure it's connected _outside_ your faraday cage, run the Ethernet through a surge protector (with the modem or other devices power supply, which is essentially just for kicks at this point) and run the Ethernet inside the cage and connect it to a wireless router powered from outside. Connect all computers via wireless and your systems will be safe.

However, if everyone elses shit dies, your screwed as it is. You'll be one of the only people trying to connect to HN.

<comment><USER5> Well if people are going to worry about solar flares, they might as well figure on EMP (electromagnetic pulse) protection from high altitude nukes too. Energy levels can be very high, and the very short pulse risetime results in energy extending to at least the VHF range. That means relatively short conductors can function as efficient antennas, picking up considerable energy. Solar events are lower frequency, so energy from longer conductors such as power lines is the first thing to worry about there.

It is silly for those people to be worried about WiFi, but some just don't have a clue as to the differences between ionizing radiation and electromagnetic radiation (and the importance of power levels). But the same folks will gab with a cell phone against their heads...

</comment></comment></comment></comment><comment><USER6> It sounds to me like a psychogenic illness similar to the Tanganyika laughter epidemic:

<http://en.wikipedia.org/wiki/Tanganyika_laughter_epidemic>

It is extremely unlikely that wifi would make kids sick. These same kids probably get wifi exposure at home too, even if it is just spill over wifi signals from their neighbor's homes. The parents clearly don't know enough about psychology or electronics.

Chances are the parents are inadvertently encouraging psychosomatic symptoms in their impressionable children.

<comment><USER4> From what I've read the main behavioral changes are dropping a grade point, falling out with friends, misbehaving in school or increased truancy.

During my day (I'm 22) this was called "falling in with a bad crowd".

For the actual medical symptoms, these are so average run-of-the-mill symptoms that it shouldn't be randomly attributed to wifi. I know in my school my greatest cause of nausea was fresh paint, a stink bomb going off or bad food in the caf.

IMO these parents are ignoring the simplest and most obvious answer: their kids are being kids and their illnesses are them trying to skip school. I had my fair share of nausea when new games came out; I even had a bout of 'nausea' during college when I picked up the Firefly box set (I'm from the UK, never saw it on TV but had a mega-huge recommendation from someone I trusted), I watched 1/4 of the first episode before I called in sick.

</comment></comment><comment><USER7> Mold can and does actually, scientifically speaking, make people sick. Associating that with unmitigated bullshit like the WiFi idiots is just degrading.

</comment><comment><USER8> This is a bit tangential to the main point of the story, but I was a student at the school that was torn down the author mentioned. It's sort of an interesting story, you can read more about it at [1]. I think it was mostly politics, it took over 5 years from the initial temporary closing of the school for the new middle school to be built. In the winter of 2001 we got an extra 2 weeks during winter vacation because they discovered the chemicals in the ground and the new school wasn't built until 2006. Apparently the safety of the teachers and students wasn't as important as spending 3 years squabbling about where to build the new one.

[1] [http://www.nytimes.com/2001/01/14/nyregion/new-term-nears- to...](http://www.nytimes.com/2001/01/14/nyregion/new-term-nears-town-split- safety-middle-school-built-landfill.html)

</comment><comment><USER9> Happened in the UK, the same parents also overturned a ban on kids having cell phones.

Apparently it's vital for their safety that they keep a 1W 1.8Ghz transmitter glued to their head at all times, but it's lethal to have a 100mW 2.4Ghz transmitter in another room.

<comment><USER10> Not to mention all the 10-100 W 400-800 THz transmitters they have in all the rooms. Worryingly, there are two structures in children's skulls, near the brain, that are particularly sensitive to these frequencies!

And I expect the average child emits more electromagnetic radiation than a wifi transmitter. Children should obviously be banned from schools then.

<comment><USER11> To what Thz transmitters are you referring?

<comment><USER12> GP probably means high-bandwidth ones like these:

[https://www.storesonlinepro.com/files/1974975/uploaded/Phili...](https://www.storesonlinepro.com/files/1974975/uploaded/Philips%20Incandescent%20A-19%20Light%20Bulb.gif)

<comment><USER10> Yes, although in UK schools they tend to be the ones more like this: <http://www.tlc-direct.co.uk/Products/LAFL16.html>

</comment></comment></comment></comment></comment><comment><USER13> _"Some parents in the Barrie, Ont., area say their children are showing a host of symptoms ranging from headaches and dizziness to nausea and even racing heart rates."_

Maybe they're going through caffeine/sugar withdrawal away from home? I'd be interested to know what the rates of obesity are among these children and how much physical activity they get at school and at home. I don't think they should discount stress either -- from other kids, parents, etc.

</comment><comment><USER14> Even if the fear mongers are right and wifi microwave radiation is carcinogenic _(ok, no proof of that but let's just say there is for a moment)_ then banning wifi in schools is not going to stop other wifi radiation from entering the schools from neighboring buildings.

I love my mother dearly but she had the same concern at home when I suggested my parents get wifi a few years back. I pointed out that if I turned her laptop on she could already see that there were 4 wifi base stations emitting microwave radiation that was passing through her brain anyway. So not getting wifi wasn't going to stop any risks (if there were any).

</comment><comment><USER15> So...are the children suppose to live in the school and never leave? Because the second they step out the door they are bound to run into a few rogue hotspots.

Even out in the rural areas of the US, you can usually find a wi-fi signal.

</comment><comment><USER16> I remember seeing some research (with positive findings) that encoding techniques such as pulse-width modulation (PWM) create beats at ~10-20hz and can affect the brain. This was like 3 years ago. Has anyone read about this recently?

I want to know if i can iDose with my wifi...

<comment><USER17> I think that you are refering to binaural beats : <http://gnaural.sourceforge.net/>

You need a stereo headset to listen to this. There is a frequency in one ear and another one slightly off in the second ear. Your brain then merge the two sine waves and intepret both as a single, low frequency "beat" of the difference.

<comment><USER16> No, i'm saying that PWM-encoding data in microwaves produces low frequency beats in the final transmitted wave, similar to the frequency of binaural beats (~10-30hz alpha and beta brain wave range). I was joking that i could iDose with wifi in the same way as binaural beats. I'll try and find one of the papers.

<comment><USER16> <http://www.ncbi.nlm.nih.gov/pubmed/15787706>

</comment></comment></comment></comment><comment><USER18> I'm confused. What's the advantage to wifi in schools? Is it just saving money on wiring the school with ethernet? Are students being permitted to take laptops into school now?

I suppose the saving money argument is actually a pretty good one, but any new school will probably be wired anyway, so that should only apply to older construction.

<comment><USER19> I'm a teacher.

Couple of good things:

* We use laptops a lot in lessons, plus the kids can use their laptops/iPods/phones or whatever on the network as well.

* We can move round the room much more easily than when using the ethernet cables, useful when using dataloggers in Science.

* Useful for older parts of the school that aren't wired.

* Useful outside

<comment><USER18> Very interesting, thanks.

</comment></comment></comment><comment><USER20> So, these people are the ones who will eventually teach science and critical thinking to students?

</comment><comment><USER21> Can't wait for one big mesh (802.11s) to come standard on all devices - imagine a world where banning wifi and google/verizon cronyism are impossible (at least in metro areas).

</comment><comment><USER22> Well, I can understand it from at least a security perspective (usually inter- connected wifi points use horribly unsecure setups), but this is pretty cute, their reasoning.

</comment><comment><USER17> The solution is obviously to put every kid in a giant faraday cage</comment>


Tell HN: Enough of the Facebook Vitriole - <AUTHOR> I have had enough of the latest anti-Facebook vitriole. A lot of people want to see someone, preferably Zuck, drawn and quartered, but I don't. He has accepted responsibility for mistakes and has agreed to do more to protect its users. I believe him. I also believe he has earned a chance to redeem himself, considering the value that Facebook has created for society at little to no cost to its users.
Most of the Hacker News community has benefitted by Facebook, as users or through myriad successful open source projects. To take with both hands and to bite is unethical. It is wrong.
Facebook and Zuck aren't the only people who need to change. <comment><USER2> I believe in second chances truly but like it or not this has become the battleground for opt in privacy and free subscriptions where you pay with your data. Frankly, it doesn't matter who ends up as a casualty in this war as long as we win freedom and privacy at the end. Just my two cents.</comment>


Kevin Rose is a parasite (according to protesters) - <AUTHOR> http://instagram.com/p/mdW5tsQRJv/#

<comment><USER2> Items like this are making it less and less likely that I read HN. Is it of "deep intellectual interest"? No doubt it is to some, and I'm content to believe it has an affect beyond the microcosm that is SV, but I'm tired of reading this sort of thing.

I haven't flagged it, because it would seem that the wider HN community wants this sort of item here, but I don't want to read it, so I will be reading less. There was a time I would watch the "newest" page to upvote good stuff and flag the inappropriate. Of late it's making me feel grubby, so I won't be doing that much now.

<comment><USER3> I lost flagging privileges after I did it to 20 or so stories. All were more off-topic than this, one literally on the Chinese silk road from about 200 BC.

But I agree with you, that instagram posts like these are low-content, even though this issue itself is interesting.

I think HN needs a downvote button.

<comment><USER4> The Chinese silk road from 200 BC is perfectly on-topic for HN! We want more, not fewer, interesting pieces from off the beaten track.

Good historical posts are particularly welcome because they counteract the relentless addiction to novelty, which breeds shallowness.

</comment></comment></comment><comment><USER5> Anti-tech protesters have gathered around Kevin Rose's house (presumably in San Francisco) with a large banner. Kevin tweeted that he acknowledges the problems with housing here.

"Greetings Your neighbor at [redacted] a man named Kevin Rose, is a parasite. Perhaps not of you, but of us. This is why we are here: to reveal him for what he is.

As a partner venture capitalist at Google Ventures, Kevin directs the flow of capital from Google into the tech startup bubble that is destroying San Francisco. The start-ups that he funds bring the swarms of young entrepreneurs that have ravaged the landscapes of San Francisco and Oakland.

With each new tech corporation comes a wave of fresh techies, who on average earn four times more than a normal service worker. We are the ones who serve them coffee, deliver them food, suck their cocks, watch their kids, and mop their floors. Nearly all of them are just like Kevin Rose and we are tired of this miserable and untenable situation."</comment>


MongoDB will not prevent NoSQL injections in your Node.js app - <AUTHOR> https://blog.sqreen.io/mongodb-will-not-prevent-nosql-injections-in-your-node-js-app/?utm_content=buffer25729&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> "NoSQL means Not-injectable, right?" makes no sense for me. It doesnt matter which type of database technology you are using. As any other database there are security roles. No mongodb query should be executed as an admin. You can restrict that up to document level. You can even create read-only views. You should always validate you payload. Use e.g Joi [https://github.com/hapijs/joi](https://github.com/hapijs/joi). Someone who doesn't validate his payload and pass it up to the driver should not be surprised.

</comment><comment><USER3> This isn't injection at all. No commands other than the find are being performed. Little Bobby Tables (Little Bobby Collections?) will not have any luck here.

In addition to the fact that you can't execute arbitrary commands with this example, the example itself is flawed. If the programmer's intention was to exclude "secret projects" from all searches, then they should have written the query to do that. They didn't, and allowed multiple other ways of accessing those records.

Writing some code that does something different to what you intended it to do is not a NoSQL injection, it's just bad code.

<comment><USER3> To expand on this..

You could use $exists, $gt, $eq, $ne, $in, $nin, regex, and all kinds of other ways to query what you want.

If the programmer wanted to exclude "secret projects" the query should have had a form similar to

{ $and: [{ type: { $ne: 'secret projects' }}, <rest of query>] }

</comment></comment><comment><USER4> Every time I read these MongoDB articles, I question why RethinkDB didn't rise up.

<comment><USER5> We all ran back to Postgres and realized life wasn't so bad?

<comment><USER4> Meh, MySQL is by far the dominant in that sector. RethinkDB is exactly what I need for most of my projects, relational, real time, document storage.

<comment><USER6> By "that sector" you mean SQL databases as opposed to NoSQL? I'm finding Postgres' JSON column types to be very useful in working with NoSQL-y document structures.

<comment><USER4> I mean free "open source", SQL databases.

<comment><USER6> I'd argue that Postgres doesn't belong just in that sector, then, given that it can be used for many of the roles Mongo/Rethink are used in.

</comment></comment></comment></comment></comment></comment><comment><USER7> Noob question. I get that this is a problem and what it could do, but wouldn't doing simple checks and validations of any client input solve this problem?

<comment><USER8> As another poster replied: Yes, validation is one method to reduce the methods of attacking. Client side is essentially useless in these cases, since they can just bypass the gui by sending HTTP requests (which can then contain the db methods) from the command line.

What is needed is server side validation. Pretty much the same as client side, but most of the time a bit more robust. The problem is validating ALL the input. Like, creating this comment. Validation is really easy for this comment.

But what about something where you upload images? PDFs are well known attack vectors. So are SVGs. How can you be sure there's nothing hiding in those? It's possible. It just becomes increasingly difficult to cover each case.

<comment><USER9> I find it odd that in 2016 we don't have a better way of centralizing that type of logic better. I don't know of a single framework that will generate front end logic from annotations on a class and then run the logic against the same annotations on the server. Spring gets you half way. Not the rest.

\-- edit grammer --

</comment></comment></comment><comment><USER10> If you're letting users query against a collection using a fairly arbitrary filter, then not having something to ensure they are authorized to view (or update, etc.) the results is almost certainly a mistake. Also describing $gte as a "command" seems misleading; if you could use $where in embedded queries it would maybe be a different story, but since I don't think you can, this seems hyperbolic.</comment>


GitHire Swamped After Promising 5 Hire-Worthy Programmers for $1k - <AUTHOR> http://www.nytimes.com/2012/02/03/jobs/githire-a-headhunter-is-swamped-after-promising-5-hire-worthy-bay-area-programmers-for-1000.html?_r=1&scp=1&sq=githire&st=cse <comment><USER2> GitHire is the sleaziest, scammiest spam setup I've come across in a long time. It shocks me that it's treated with legitimacy by the New York Times. Additionally, it saddens me to see so many people uncritically praising the idea as if it was anything other than a spam house.

GitHire does nothing more than scrape GitHub profiles and spam users with unsolicited junk mail -- regardless of the users's qualifications or desire to be recruited. It's spray-and-pray spam and companies wishing to keep their respect among developers would do well to avoid them. Any company willing just resort to spam is neither a company I'd want to work for nor a company I'd wish to be a customer of.

<comment><USER3> Really interesting PR hack in play here. At first glance the article is published at NYT.com and that fact _will_ be milked endlessly. The really curious part is that the article is syndicated up from the SF-area nonprofit "Bay Citizen" [1].

Note to PR-hungry founders: Figure out which blogs are syndicated by the NYT and other big players and then pitch to them directly. They should be much more receptive audiences than first-party NYT staff.

[1] <http://www.baycitizen.org/about/>

<comment><USER4> It's not really syndication. The New York Times has partnerships with The Bay Citizen and several other regional news nonprofits to publish articles in their regional editions on Fridays and Sundays. The articles go through The New York Times's editorial process, not a completely separate process like the Associated Press.

In theory, The New York Times won't lend its imprimatur to articles it doesn't deem worthy, so I don't see why the newsroom that the reporter sits in is an issue.

<comment><USER5> There's a pretty big effort jump between writing an article and approving it for editing, in addition to writing involving you intently think about the story for a significant amount of time. This means that any ethical, financial, pr - related concerns are applied longer for the writer. NYT writers are highly motivated and competitive people, and would worry about even the occasional negative piece. Bay Citizen writers aren't held to the same requirements, since they're aren't viewed in the same critical way. Editors, since they simply have to review the piece and what gets on the page is whatever is the best to choose from, are a lot more likely to approve a piece.

<comment><USER4> _Editors, since they simply have to review the piece and what gets on the page is whatever is the best to choose from, are a lot more likely to approve a piece._

Your view of the role of an editor is incorrect. My observations of the newsroom I work in (as a developer) are quite different. My organization has a similar partnership with the New York Times, and some of our stories have made the front page of the national edition, not just the regional edition.

Your view of The New York Times's willingness to publish pieces that don't meet its standards are based on speculation.

</comment></comment></comment></comment></comment><comment><USER6> They were practically begging my co-workers and I to interview. They were offering $10 Amazon gift cards for an interview, which was just insulting. It wasn't even the amount; it turned what could have been a good fit into a cheap business transaction.

Here's how I saw it: If I invited you to dinner, it would be considered a nice gesture. But what if I offered you $10 to come to my house for dinner? It changes everything.

I feel bad for the company, who we blamed for the "stunt". Turns out, the company had no knowledge they were doing that.

<comment><USER7> Joel Spolsky on motivating factors:

> _But when you offer people money to do things that they wanted to do, > anyway, they suffer from something called the Overjustification Effect. "I > must be writing bug-free code because I like the money I get for it," they > think, and the extrinsic motivation displaces the intrinsic motivation. > Since extrinsic motivation is a much weaker effect, the net result is that > you've actually reduced their desire to do a good job. When you stop paying > the bonus, or when they decide they don't care that much about the money, > they no longer think that they care about bug free code._

<http://www.joelonsoftware.com/items/2006/08/09.html>

<comment><USER6> I think the awesome book Predictably Irrational does a better job of explaining it:

> What's going on here? Why does an offer for direct payment put such a damper > on the party? As Margaret Clark, Judson Mills, and Alan Fiske suggested a > long time ago, the answer is that we live simultaneously in two different > worlds- one where social norms prevail, and the other where market norms > make the rules. The social norms include the friendly requests that people > make of one another. Could you help me move this couch? Could you help me > change this tire? Social norms are wrapped up in our social nature and our > need for community. They are usually warm and fuzzy. Instant paybacks are > not required: you may help move your neighbor's couch, but this doesn't mean > he has to come right over and move yours. It's like opening a door for > someone: it provides pleasure for both of you, and reciprocity is not > immediately required.

> The second world, the one governed by market norms, is very different. > There's nothing warm and fuzzy about it. The exchanges are sharp- edged: > wages, prices, rents, interest, and costs- and- benefits. Such market > relationships are not necessarily evil or mean-in fact, they also include > self- reliance, inventiveness, and individualism-but they do imply > comparable benefits and prompt payments. When you are in the domain of > market norms, you get what you pay for-that's just the way it is.

<comment><USER7> Once you mentioned it, I realized I knew this was in Predictably Irrational. I've never read it, but I have heard it mentioned in this context.

I first heard of this through Joel, so I quickly found a citation from his blog. I know he's mentioned it repeatedly on the SO/SX podcasts as well, so it's likely the association was solidified there.

That said, your quote doesn't make the point I was trying to highlight. Specifically, I was trying to show that moving from intrinsic to extrinsic motivation is not only damaging, but also hard to reverse as well.

Thanks for the quote though. I've renewed my mental note to someday maybe finally get around to reading the book.

</comment></comment></comment></comment><comment><USER8> These guys are spammers, there is no way around it.

<http://lookfirst.com/2012/01/githirecom-is-spammer.html>

Here is my post about an HN post that they _deleted_ after people started ripping into them:

<http://lookfirst.com/2012/01/githire-spam-again.html>

Please make them go away. Mark all emails from them as spam. Do not buy their services. Do not respond to their emails.

<comment> X-Istence I was not even aware that they create profiles from my public data on Github, and the only way it seems to remove my profile is to log in using OAuth on Github.

That just seems even more sleazy.

<comment><USER8> Yea, I'm starting to get upset at Github for allowing them to continue. I've emailed email@example.com multiple times about this. One email said that they would take care of these guys and then all further support emails have been ignored.

Sadly, they are giving Github a bad name now too as it appears to me that they are supporting these guys by allowing them to continue.

</comment></comment></comment><comment><USER9> Seems like hype. This page <http://githire.com/job_board> shows only 19 job requests and only 3 intros made so far. Also if these intros are made by programmatically scraping emails on github, then they could be in some trouble for violating spam laws.

<comment><USER10> I would hope that, at minimum, they're respecting the hirable? flag on profiles. Their about page is full of marketing speak, but short on actual details. (I understand that they don't want to give away their "secret sauce," but is there really that much to it?)

Edit: Also, their algorithm seems pretty off - a search around me returns some candidates in the "top 10%" group who only have one repo and it's a fork of someone else's with a small bugfix. (Nothing wrong with that - I appreciate those who take the time to submit patches. But surely a single fix of a couple of lines shouldn't rocket someone into the top 10% of GitHub.)

<comment><USER11> They do not (or at least, did not) respect that flag nor do they (or did they previously, at least) respect an explicit opt-out of their service. Great that they're successful, but for a while there they were well on their way to pissing off the developers they so desperately need to actually make money.

</comment></comment></comment><comment><USER12> Shameless plug: our startup, Skills (<http://skillsapp.com>) is attacking the resume problem from a different angle. On one hand we don't do candidate sourcing (yet), on the other hand we don't spam potential hires.

The way our service works:

1\. You create a position. Right now we offer two kinds: Django and Frontend

2\. You get a link from us. Paste that link in your job board adverts, or anywhere you'd otherwise say "send your resumes to…"

3\. Candidates apply through the link, we crunch their data and produce a clean, concise report that helps you decide whether they're worth talking to, without wading through the resume keywordfest.

You can see a sample brief here: <http://skillsapp.com/sample/brief/>

Check us out, we're also just launched, and we're hungry for feedback.

</comment><comment><USER13> Sounds like businesses can smell a deal a mile away.

I thought normal recruiter practice was some percentages (10%, 20%?) of a hire's first year pay. So, like $10,000 to $20,000.

If you can get an interview with a potential employee for one _tenth_ of that... __and __you know these people are famous in some nerd circles (buying your company more geek cred)... it's a deal.

<comment><USER14> On the other hand, if it looks too good to be true then it probably is. See other comments.

<comment><USER13> Oh, I have no doubt. Many things are funny about Githire, including just how many coders are in the top 10-20% of Github users (including those with one repo and no activity).

</comment></comment></comment><comment><USER15> Seriously how badly are they using the gitHub API, or scraping. Because if I find my profile. (I'm not listed in my area "Edinburgh", even though people with a lower score are.) and on my profile the projects are so severely out of date it's embarrassing.

Update: In my opinion, even though its not for "Hiring", <http://coderwall.com> does a way better job. Perhaps they should up their game and do what gitHire is doing - but properly.

</comment><comment><USER3> The quote at the end made my hair stand on end:

 _"Top programmers are like a race car. Once you get them you don't want to lose them and you want to get as many as you can."_

<comment><USER16> yay im a commodity

gotta catch'em all zuck

<comment><USER17> even worse, you're treated as such by a large number of people who don't seem to understand how to properly invest in that type of commodity

</comment></comment></comment><comment><USER18> A snippet:

"Top programmers are like a race car," he said. "Once you get them you don't want to lose them and you want to get as many as you can."

It is a little off topic, but I think comments like this give me an idea of what it feels like to be objectified, like a woman might be in American media. I'm only now realizing that's why the "rock star" or "race car" label makes me feel so shitty. From Wikipedia:

"Some feminists and psychologists argue that such objectification can lead to negative psychological effects including depression and hopelessness, and can give women negative self-images because of the belief that their intelligence and competence are currently not being, or will never be, acknowledged by society."

Now, I know this is only my career and not my body, but in spite of myself I get intimidated by all these C-suites looking for such hyperbolically able and single-minded individuals I start worrying about if I can cut it. If I will be recognized for anything except my ability to program.

I'm not comparing this problem to objectification of women in scope, and I'm not saying this is all-consuming my life or anything. It is far from that, but something about the "race car" statement brought this into focus for me. I don't want to be collected like race cars or Pokemon by some dipshit.

This was not intended to troll, I just wanted to share my realisation about being compared to expensive/flashy stuff.

</comment><comment><USER19> This article is in the print edition of the New York Times with the headline " _A New Resource for Hiring Programmers Has Become Entirely Too Successful._ "

GitHire must have some good PR.

<comment><USER20> It may be all they have.

</comment></comment><comment><USER21> And this is surprising how? Great to hear they are being successful though. $200/lead is probably an order of magnitude too low though.

</comment><comment> X-Istence Did they get permission from Github to scrape their website for the content they have put up?

From the terms of service:

4\. You must not modify, adapt or hack the Service or modify another website so as to falsely imply that it is associated with the Service, GitHub, or any other GitHub service.

5\. You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, or access to the Service without the express written permission by GitHub.

Although I guess if the GitHire guys never used Github they aren't bound to those terms.

<comment><USER8> They are in clear violation of those terms. Github is knowingly allowing them to continue to use their services.

</comment></comment><comment><USER22> The NYTimes and the WashPost are probably gearing up to get Congress to raise the guest worker quotas again, after the election. They need a lot of "supply and demand and capital mobility don't work anymore" stories. Just raise wages and labor adjust to the incentives. Most of this new stuff is not a labor supply problem, it's a vision and management problem. "If I could just hire the best engineers for real cheap , then ...". yeah yeah right.

</comment><comment><USER23> I have no idea why companies that suddenly become wildly successful without press, start to go out and make themselves public, hence waking up every smart guy in the game. Keep a low profile and milk it, maan.

<comment><USER11> Perceived legitimacy. In the recruiting game, you need a leg up on the next 200 mindless email drones. Saying "We're so good the NY Times covered us!" goes a long way towards considering both sides of the transaction that you're worth the time.

</comment></comment><comment><USER24> Here is what I do not get:

1\. Recruiters expect me to spend my free-time at their disposal to use my dev contacts for them? My dev contacts remain my dev contacts because they know that if I ever turn over a contact to a 3rd party I do some review of the opportunity to see if its a scam or recruiter bs first and only turn over contacts to that 3rd party if they are a founder, cop-founder, or the actual ,manager the person will work under.

2\. To me relationships are formed over a good meal and a good drink, no offense to you HN'ers but that is what it comes down to. If someone wants to recruit me than consider taking me out for a meal. Its not necessarily the cost of the meal, its the fact that you took sometime to spend on forming a relationship with me.</comment>


An IDE Is Not Enough. - <AUTHOR> http://alarmingdevelopment.org/?p=680

<comment><USER2> I'd rather see people try to improve our tools than not. And yes, the academic argument against it is "we're hampered by our languages".

So we are. Nobody proposed _not_ working on new languages. But even if there was an entirely new language that made for fantastic IDEs ( _cough_ Smalltalk ;), we have an insanely large existing code base in "legacy" languages.

Until those are ported to those new languages (and I have a few piles of FORTRAN and COBOL code to say "that ain't gonna happen, ever"), _any_ improvement in our tooling is progress.

Yes, we'd all like a silver bullet that makes us 2x more productive. Until we have that, I propose we tackle our problems on all fronts, not just a single one.

(For the record, I'm extremely skeptical about those new IDEs and their success. We'll see what happens. I'll still throw a bit of money at it, just because I think _any_ kind of work on new tooling will result in new insights)</comment>


The Recruiter Said 'It's a Great Opportunity' – But It Wasn't - <AUTHOR> http://www.forbes.com/sites/lizryan/2016/12/28/the-recruiter-said-its-a-great-opportunity-but-it-wasnt/ <comment><USER2> Oh but it was -- a great opportunity for the recruiter to make a few mortgage payments, that is.

<comment><AUTHOR> Fair enough, the recruiter never specified who the "great" opportunity was for. Haha.</comment></comment>


Eric Brewer on Advancing Distributed Systems - <AUTHOR> http://basho.com/community/ricon2012_live/#live-content

<comment> mansoor-s Are this available as a recording anywhere? I seem to have missed it live.

<comment><USER2> They will be posted at some point they said.

</comment></comment><comment><USER3> Live in 20 minutes.</comment>